コンテキスト設計の原則

Lesson 3 で学んだ通り、AIの注意力は均等ではありません。 この偏りを理解した上で、コンテキストを「判断」「分類」「適用」「確認」の順に設計する方法を学びます。 目的は、AI に必要な情報だけを渡して成果物の品質を安定させることです。

「以前はすべてをコンテキストに詰め込んでいました。今は慎重に選んでいます。」

そのマインドセットの転換—「何を渡せるか」から「何を渡すべきか」へ—が、 平凡な結果と優れた結果の違いです。コンテキスト設計とは、含めるすべての情報に対して 意図的であることです。

本当に考えるべき問い

何かをコンテキストに追加する前に、自分に問いかけてください： 「Claude がこの特定のタスクを完了するためにこれが必要か？」

「いつか役に立つかも」や「これは関連がありそう」ではありません。 今、この正確なタスクのために Claude がそれを必要としているでしょうか？ 答えが明確な「はい」でなければ、除外してください。

判断フレームワーク

含める可能性のあるすべてを3つのカテゴリに分類しましょう：

ケース別の判断例

タスク	必須	役立つ	ノイズ
バグ修正	エラーログ、該当関数	呼び出し元、型定義	無関係なモジュール
新機能追加	要件、既存インターフェース	類似機能の実装例	別機能のテストコード
コードレビュー	diff、コーディング規約	変更理由の説明	変更されていないファイル

実践的なガイドライン

1. 最小限から始めて、必要に応じて追加。 まずは必須だけを渡します。Claude が質問したら、その範囲だけ追加します。 例えば「エラーログと該当関数だけ」を先に渡します。
2. 大きなファイルは要約する。 2,000行を貼る代わりに構造だけ説明します。 例えば「このファイルは User モデルで、関連関数は 145 行目の authenticate() です。」
3. すべてではなく構造を渡す。 バグ修正には壊れた関数と直接の依存関係だけを渡します。 新機能にはインターフェース定義と類似機能の例を1つ渡します。 例えば「該当関数 + 呼び出し元2つ + 期待する入出力」を先に渡します。
4. 関心を分離する。 認証に取り組んでいるなら課金コードは除外します。 API に取り組んでいるならフロントエンドは除外します。 例えば「API のエラー時に UI は後回し」と決めて切り分けます。

チェックリスト

プロンプトを送信する前に、これを確認してください：

• このタスクに不可欠な情報から順に並んでいますか？
• 「念のため」を削っても成立しますか？
• 判断に迷う情報は「役立つ」に留めていますか？
• 同じことを短く言い換えられますか？