定義と結論
AIへ渡す最小コンテキストとは、目的を達成するために必要な仕様、制約、関係コード、再現情報、期待する出力だけを選んだ入力です。「短ければよい」ではなく、判断に必要な情報は残し、無関係または共有禁止の情報を除きます。
結論は、最初に目的と変更範囲を示し、必要性を説明できる情報だけを段階的に追加することです。リポジトリ全体やログ全量を最初から渡しても、正確性は保証されず、重要な条件が埋もれ、機密情報の露出面が広がります。
なぜ必要か
AIは渡された文脈から回答しますが、情報量が多いほど必ず理解が深くなるわけではありません。似た関数、古い実装、生成物、無関係な設定が混ざると、どれを正しい契約として扱うか曖昧になります。一方、エラー文の一行だけでは、環境や期待動作を推測するしかありません。
最小化は精度、安全性、レビュー可能性の三つに効きます。必要な文脈を選ぶ作業そのものが、問題の範囲と分かっていない前提を明らかにします。
登場人物と対象
- 質問者・依頼者: 目的、制約、共有可能範囲を決める
- AIシステム: 入力、接続ツール、取得した資料をもとに出力する
- データ所有者: コード、顧客情報、契約文書の共有可否を決める
- レビュアー: 文脈が十分か、不要な情報がないかを確認する
- セキュリティ担当: 保持設定、権限、監査、漏えい時の対応を設計する
対象はプロンプト本文だけではありません。添付ファイル、IDEが自動取得するファイル、検索結果、ターミナル出力、MCPやコネクタで参照する外部データもコンテキストです。
文脈を選ぶ流れ
1. 目的と出力を一文にする
「このエラーを直して」ではなく、「Node.js 22でテストが失敗する原因候補を特定し、変更せず確認手順を示す」とします。実装、説明、レビューのどれを求めるかも分けます。
2. 必須の契約を集める
期待結果、実際の結果、再現手順、対象バージョン、関係する型やインターフェース、変更してよいファイルを選びます。エラーは要約だけでなく、秘密を除いた原文を含めます。
3. データを分類し伏せる
公開、社内限定、個人情報、認証情報、契約上共有禁止に分類します。tokenや秘密鍵は値を置換するだけでなく、可能なら該当行自体を入力経路から除きます。
Authorization: Bearer ***REDACTED***
DATABASE_URL=***REDACTED***
4. 最小の関係範囲を渡す
エラー箇所だけでなく、直接の呼び出し元と入力を作る場所は必要な場合があります。逆に、ビルド成果物、依存ディレクトリ、無関係なテストは除きます。
5. 不足を質問させ段階追加する
「確定できない前提と、次に必要な情報を列挙してください」と依頼します。追加するたびに目的との関係と共有可否を見直します。
比較と主要パターン
| 入力パターン | 長所 | 問題 |
|---|---|---|
| エラー一行だけ | 速く入力できる | 環境と期待をAIが推測する |
| リポジトリ全体 | 探索候補は多い | ノイズ、露出、古い情報が増える |
| 最小コードだけ | 焦点を絞れる | 呼び出し元の契約を落とす場合がある |
| 目的＋契約＋関係経路 | 判断根拠を追いやすい | 選別に事前調査が必要 |
| 段階的な追加 | 必要性を確認しやすい | 各段階で立ち止まる運用が必要 |
「最小」はファイル数ではなく、正しい判断に必要な意味が欠けていない最小集合です。
具体例: APIの401調査
悪い依頼は、CookieやAuthorizationを含むHAR全体とサーバー設定をそのまま添付し、「直して」と書くものです。秘密情報を露出させるうえ、どの操作が失敗したか分かりません。
良い依頼では、ログイン後の特定APIだけが401になること、期待は200であること、再現手順、ブラウザとサーバーの構成、Request URL・method・status、秘密を除いた関連ヘッダー、認証middlewareの関係部分を示します。変更前に原因候補と追加確認を求めます。
Cookie値そのものは不要です。Cookie名、属性、送信されたかどうかが判断材料なら、その構造だけを残します。個人のメールアドレスは再現用の架空値へ置換し、置換したことを明記します。
よくある誤解
多く渡せば幻覚が減るとは限りません。矛盾する情報や古い例が増えれば、誤った前提を選ぶ可能性があります。
伏字にすれば何でも共有可能でもありません。コードやログの組み合わせから顧客や内部構成を推測できる場合があります。契約と組織ルールが優先です。
コンテキストを減らすと説明も短くなるわけではありません。入力を選別しても、出力へ根拠、不確実性、確認方法を求められます。
注意点とベストプラクティス
.env、秘密鍵、token、Cookieの値を入力しない- 個人情報は削除または承認済みの再現用データへ置換する
- 自動取得対象、除外設定、接続ツールの権限も確認する
- 目的、非目的、変更可能範囲を先頭へ置く
- versionと公式資料を明示し、古い前提を混ぜない
- コードの省略箇所を示し、存在しない文脈を推測させない
- 会話が長くなったら決定事項と未決事項を再整理する
秘密情報を貼った後に「忘れて」と依頼することは、入力しなかった状態の代わりにはなりません。 誤入力時の報告、失効、削除依頼など組織の手順に従います。
デバッグと確認方法
ケーススタディ: 一つのバリデーション修正を依頼する
注文フォームの郵便番号判定だけを直したい時、リポジトリ全体を渡すのは過剰で、「正規表現を直して」だけでは不足です。前者は無関係な顧客データや設定を混ぜる危険があり、後者は対象形式、既存テスト、変更禁止範囲が分からず、AIが海外住所まで拒否する可能性があります。
良い文脈は、失敗している入力例、期待結果、対象関数と呼び出し元、関連テスト、国内注文にだけ適用するという制約、変更してよいファイルを含みます。その上で、最初は関数とテストだけを渡し、型や仕様が不明だと回答された時だけ定義元を追加します。判断の順序は、目的を一文にする、受け入れ条件を列挙する、必要な依存を入口からたどる、秘密と無関係な履歴を除く、出力形式を指定する、です。全文を貼る前に「この判断に必要な事実か」を一項目ずつ問います。
観測するのはプロンプトの長さだけではありません。最初の回答で正しいファイルを変更できた割合、AIが置いた仮定の数、追加質問の内容、無関係な変更、テストで見つかった仕様逸脱を記録します。情報不足による誤りが続けば仕様例を追加し、無関係な改稿が増えれば変更範囲を狭めます。少ない文脈で一発回答を得ることより、必要な不確実性が質問として表面化し、検証可能な差分になることが成功条件です。
回答がずれたら、情報を無制限に追加する前に、AIがどの前提を置いたかを確認します。目的、実行環境、期待と実際、対象バージョンのどれが不足しているかを一つずつ補います。回答内のAPIや設定は公式資料とローカルのversionで検証します。
入力前には、秘密らしい文字列、個人情報、無関係なファイルがないか見直します。入力後は、提案が指定範囲に収まり、根拠が渡した資料へ結び付いているかを確認します。不足情報を正直に質問する回答は、根拠なく断定する回答より安全です。
まとめ
最小コンテキストは、情報を単に削ることではなく、目的に必要な意味だけを安全に選ぶ設計です。目的、契約、再現、関係経路、期待出力を渡し、不足は段階的に追加します。入力経路全体の権限と機密性を確認し、AIの出力は公式資料と実行結果で検証します。
参考リソース
- OWASP Top 10 for LLM Applications
- NIST AI Risk Management Framework
- GitHub Docs: Content exclusion for GitHub Copilot
