
全 1538 件 (Zenn で絞り込み) · 2 / 77 ページ


Claude Code などのAIツールでコード生成を行う際、単純に実装指示を出すだけでは不十分であり、コンテキスト設計・段階的な指示・検証プロセス設計が必須である。実務で安全に活用するには、生成されたコードの品質確認、既存設計との整合性確認、テスト実行、例外処理検証まで含めたプロセス全体の設計が必要。

Claude CodeのBashツールが「unexpected EOF while looking for matching quote」エラーで全コマンド即死する障害が発生。作者が3度の発生を通じて特定した原因はセッション内部の汚染であり、再インストール不要で「新しいチャット」を開くことで復旧可能。ファイル・設定・アプリはいずれも無罪で、セッションランタイムの再開ではなく破棄が必須の対応。


5つのLLM(Kimi K3、GLM-5.2、DeepSeek-V4-Pro、GPT-5.6 Sol、Claude Sonnet 5)に同じプロンプトを渡して、約400行のPythonスクリプトをコードレビューさせた比較実験。最も安価なDeepSeekが、最も重要な2つのバグについて「問題なし」と誤った断定を下し、単純なコスト効率指標だけでモデルを選ぶことの危険性を実証した。

Claude Code のプロジェクトメモリは ~/.claude/projects/<プロジェクト名>/memory/ 配下に保存され、セッション開始時は MEMORY.md のみ読み込まれる。古い・矛盾した情報が蓄積しやすいため、著者は純正の /consolidate-memory スキルの限界を踏まえて、ユーザー合意を取りながら安全に棚卸しする自作スキル memory-inventory を開発した。削除ではなく _archive/ への退避で可逆性を保つ設計。


独学エンジニアが7種類のAIモデルに落ちものパズル課題を実行させ、同じ採点プログラムで比較。Claude Opus 5・Gemini 3.7 Flash・GPT-OSS など複数環境で計測した結果、Gemini 3.7 Flash が前世代比で約35%性能向上し、環境依存性が最小限であることを確認。実験設計の穴(モデルが繰り返し同じ答えを見ていた事例)も発見。

Claude Code の effort 設定は「Claude の賢さ」ではなく「作業に使える時間」を制御するもの。設定を最大にすると関係ない情報を集めすぎて本題がぼやけ、かえって質が落ちる。指示を具体的にし、effort は medium か high から試すのが効果的。


Zenn の著者が、MCP サーバのツール説明文(description)と実際の動作を意図的に食い違わせる「Tool Poisoning」を検証。メモ管理 MCP サーバを自作し、説明文や関数名を偽装した場合に Claude がどう振る舞うかを実験。MCP の基本概念と実装方法も解説。


Opus 5 で effort を xhigh から medium に下げたら出力品質が上がった。thinking がデフォルト ON になり budget_tokens が廃止され、effort の役割そのものが変わった。effort は品質の下限を決めるのではなく、プロンプト品質を増幅する係数になり、仕様が薄いまま effort を上げると推測が増えて品質が低下する。


Claude Code の拡張機能群(CLAUDE.md、skills、MCP、subagents、hooks、dynamic workflows など)を「解決すべき問題」の観点から分類・体系化したマップを提供。機能の仕組み(モデル選択、コンテキスト管理、外部接続、スケーリング)の詳細を理解することで、ワークフロー上のどのペインポイントにどの機能を適用すべきかが判断できるようになる。


AWS Security Hub MCP App が Claude Desktop で利用可能になった。ローカルで動作する read-only MCP サーバーで、複数の AWS アカウントにわたるセキュリティ Findings を数分で相関分析でき、エスカレーション対応・顧客報告資料作成・CVE トリアージの根拠づけなど 6 つの実務活用シーンが想定される。従来は複数の AWS コンソール画面を横断していた分析が 1-2 ターンの会話で完結する。


