AIに全部渡しても、回答はよくならない。必要な情報だけを渡す「コンテキストエンジニアリング」

コンテキストエンジニアリングとは、現在の判断に必要な情報を記録し、選び、圧縮し、分離しながら、推論に使える状態を維持する技術です。

AIへ渡す資料は、多ければ多いほどよいわけではありません。

必要な情報が古い資料や長い実行ログに埋もれれば、コンテキストウィンドウに収まっていても判断を誤ることがあります。

この記事では、何を最初から渡し、何を必要になってから取り出し、何を次の仕事へ残すかを判断できるところまで説明します。

AIエンジニアリングシリーズ

この記事は、次のような業務を想定しています。

• Notion、Google Drive、社内WikiをAIに参照させている
• RAGを導入したが、回答の根拠や精度が安定しない
• 長い会話になると、最初に決めた条件が抜ける
• 古い資料と新しい資料のどちらを優先したか分からない
• 毎回同じプロフィールや業務ルールを入力している
• AIエージェントへ、前回の状態や失敗を引き継ぎたい

読了後は、問題の原因が依頼文にあるのか、判断材料にあるのかを切り分けられます。

RAG、メモリ、ファイル、会話履歴の使い分けと、AIへ渡す情報の品質も点検できるようになります。

プロンプトを直しても回答が改善しない

AIの回答がズレたとき、僕はまずプロンプトを直していました。

「もっと具体的に書いて」

「この資料を優先して」

「前回と同じ形式で返して」

役割、制約、出力形式を足せば直ることもあります。

しかし、判断に必要な資料が渡っていない場合や、古い資料が混ざっている場合は、依頼文だけを直しても改善しません。

大量のHTMLを扱うプロジェクトで、僕はページ本文を丸ごとAIへ渡していた時期があります。

入力は増えましたが、重要な箇所がどれかを示していなかったため、抽出結果は安定しませんでした。

原因はモデルへの頼み方より、判断材料の出し方にありました。

問題の場所は、次の三つの質問で切り分けられます。

依頼の意味を取り違えているなら、プロンプトエンジニアリングを見直します。

依頼は理解しているのに根拠や前提が欠けているなら、直す対象はコンテキストです。

コンテキストエンジニアリングの対象範囲

AIが応答を作るときに参照できる情報のまとまりが、コンテキストです。

会話本文だけでなく、システム指示、取得した資料、ツールの説明と結果、途中の状態もコンテキストに入ります。

Anthropicの整理では、コンテキストをモデルが応答を生成するときに含まれるトークン全体として扱っています。

実務では、コンテキストを作業机として考えると分けやすくなります。

AI                 = 作業者
プロンプト         = 今回の依頼
コンテキスト       = 作業机に出ている情報
ファイルとDB       = 元資料を置く書庫
検索とRAG          = 書庫から候補を探す手段

作業机に資料がなければ、AIは業務固有の根拠に基づいて判断できません。

一方、書庫の中身を全部載せると、今回使う資料が埋もれます。

推論時のコンテキストには、主に次の情報が現れます。

この表には、プロンプトやツールも含まれます。

ただし、四つの記事では設計上の問いを分けています。

コンテキストの記事は「推論時に何を見せるか」を扱い、ツールの権限や検証の強制はハーネスエンジニアリングへ渡します。

コンテキストは容量ではなく注意予算

モデルが一度に受け取れるトークン数の上限が、コンテキストウィンドウです。

上限が広くても、入力したすべての情報が同じ重みで使われるわけではありません。

そこで本記事では、判断に使ってほしい情報を置ける余地を注意予算と呼びます。

注意予算は、製品が示す正式な容量ではありません。

関連する事実、制約、例、ツール結果を、判断しやすい位置と量で渡すための実務上の考え方です。

大量の入力が判断を難しくする理由は、情報が長いからだけではありません。

• 今回の仕事と関係のない資料が、関連資料と同じ場所に並ぶ
• 古い仕様と新しい仕様が、優先順位なしで混ざる
• 同じ事実を言い換えた文章が何度も現れる
• 長いツール出力が、目的や完了条件を遠ざける
• 途中の推測が、確認済みの事実と区別されない

この状態では、モデルはどれを優先すべきか追加で推測することになります。

コンテキストに収まることと、判断に使いやすいことは別です。

たとえば記事を編集する仕事なら、過去の全チャットを渡す必要はありません。

原稿、想定読者、記事の役割、確認済みの情報源、守る表現ルールが最初にあれば作業を始められます。

詳しい根拠や過去の事例は、必要になった時点で元資料から取得します。

入力を減らすこと自体が目的ではありません。

判断に必要な情報の欠落を防ぎながら、競合する情報と不要な情報を下げることが目的です。

書く、選ぶ、圧縮する、分ける

LangChainの整理は、コンテキストを扱う操作をWrite、Select、Compress、Isolateの四つに分けています。

日本語では、書く、選ぶ、圧縮する、分けると捉えれば十分です。

書く

次の仕事でも必要な状態は、会話の外へ記録します。

僕が残すのは、現在の目的、決定事項、未解決の問題、失敗した方法、元資料への参照です。

state/current-task.md
state/decision-log.md
reports/audit.json

生ログや会話全文を、そのまま長期メモリへ積み上げるわけではありません。

再利用する判断と、再取得できる事実を残します。

何を次回へ残すかはコンテキストの設計です。

保存先と書き込み権限はハーネスが決め、どの評価後に更新するかはループが決めます。

選ぶ

今回の判断を変える情報だけを、書庫から作業机へ移します。

選ぶときは、関連度だけでなく、更新日、情報源、対象範囲も確認します。

悪い例:
検索上位の社内資料を、更新日を見ずにすべて渡す

よい例:
今回の質問に関係する資料を選び、
更新日、出典、関係する理由を添える

検索順位が高いことは、正しさや新しさを保証しません。

候補を見つける工程と、推論に渡す工程を分けます。

圧縮する

長い会話やツール出力から、次の判断に必要な情報を取り出します。

圧縮後にも残すのは、決定、根拠、未解決事項、失敗理由、次の操作です。

圧縮前:
長いエラーログと試行錯誤の会話

圧縮後:
エラーの種類
失敗した操作
確認済みの原因
未確認の仮説
次に試すこと
生ログの保存先

Manusの実装記事は、本文を外してもURLやファイルパスを残し、あとから復元できる圧縮を紹介しています。

要約だけを正本にすると、要約時に落とした事実を確認できません。

元資料を残し、圧縮した情報から戻れるようにします。

分ける

広い仕事を、異なるコンテキストを持つ作業へ分割します。

調査役には検索結果と引用の確認を任せ、執筆役には確認済みの論点と構成を渡す方法が一例です。

ただし、作業を分ければ精度が上がるわけではありません。

受け渡す形式が決まっていないと、担当ごとに前提や用語がズレます。

分ける前に、成果物、根拠の示し方、未解決事項の扱いを決めます。

RAG、メモリ、ファイル、会話履歴の役割

RAG、メモリ、ファイル、会話履歴は、どれも情報を扱いますが、同じ仕組みではありません。

RAGは、外部の書庫から質問に関係する候補を検索し、推論時のコンテキストへ加える仕組みです。

メモリは、次の仕事でも使う判断、選好、状態を保存し、必要な場面で取り出す仕組みです。

ファイルとDBは、元資料、大きなデータ、実行状態を置く保存先です。

会話履歴は、現在のやり取りと直近の判断をつなぐ記録です。

RAGはコンテキストエンジニアリングの全部ではありません。

検索で見つけた断片へ、出典、更新日、文書内の位置、質問との関係を付けて初めて、判断材料として扱いやすくなります。

AnthropicのContextual Retrievalは、断片へ文書全体の中での位置づけを短く加えてから検索する方法です。

断片だけでは意味が曖昧になる資料で使える考え方です。

必要な時点で情報を取り出す

最初にすべてを渡さず、必要になった情報だけを順に取得する方法が段階的取得です。

エージェントへは、書庫の全文より先に、どこを探せるかが分かる索引を渡します。

僕は、次の順番を基本にしています。

1. 今回の目的、制約、完了条件を確認する。
2. 利用できる文書の一覧と更新情報を見る。
3. 質問に関係する語句や見出しで候補を探す。
4. 候補の該当セクションだけを読む。
5. 判断に足りなければ、元の文書へ戻る。
6. 回答へ使った出典を残す。

各段階で、次へ進む理由を明確にします。

候補一覧だけで判断できなければ本文を開き、本文内の断片だけでは意味が決まらなければ上位の見出しまで読みます。

取得結果も、モデルが読み違えにくい形へ整えます。

{
  "title": "資料名",
  "section": "該当見出し",
  "updated_at": "2026-07-11",
  "source": "元資料のURLまたはファイルパス",
  "relevance": "今回の判断に関係する理由",
  "content": "必要な範囲の本文"
}

全文を返すlist_allより、検索条件と件数上限を持つsearchの方が、必要な候補へ到達しやすくなります。

ただし、検索結果を狭めすぎると、例外や反証を落とします。

見落としの損失が大きい仕事では、最初は再現率を優先して候補を出し、そのあとに関連度と信頼度で絞ります。

鮮度、出典、競合する情報を保つ

検索に当たった資料が、現在も正しいとは限りません。

情報には本文と一緒に、少なくとも更新日、出典、対象範囲を持たせます。

新しい資料が常に正しいわけではありません。

正式な仕様書より新しい会議メモがあっても、そのメモが承認済みとは限らないからです。

競合する情報があるときは、黙って一つに混ぜません。

次の順番で扱います。

1. 正本として決められた資料を確認する。
2. 対象期間とバージョンをそろえる。
3. 一次情報と二次情報を分ける。
4. 差分を明示し、解消できなければ未確定として残す。
5. 判断権限を持つ人へ確認する。

価格、法令、製品仕様、運用状態のように変わりやすい情報は、保存済みの要約だけで答えません。

元資料を再取得し、取得日を回答へ残します。

逆に、変更されない決定の履歴は上書きせず、決定時点と変更理由を残します。

実例で見る個人コンテキスト基盤

僕は、自分の経歴、編集方針、事業知識、文章のスタイルを、必要なときだけAIへ渡すためにmycontext-mcpを作りました。

NotionとローカルのMarkdownを同期し、読み取り専用のMCPサーバーから必要な範囲を取得する仕組みです。

公開可能な構成は、mycontext-publicに置いています。

構成は、書庫、索引、取得、引用の四段階に分かれます。

NotionとMarkdown
        ↓ 同期
クラウドDB
  ├── 文書の原文
  ├── 見出し単位のセクション
  └── 更新情報と出典
        ↓ 読み取り専用MCP
AIクライアント
  ├── 一覧
  ├── 検索
  ├── 必要なセクションの取得
  └── 元資料の参照

書き込む側と読む側を分ける

NotionとMarkdownからDBへ同期する処理と、AIからの検索へ答える処理を分けています。

読む側を読み取り専用にすることで、AIが原典を書き換える経路を持たずに済みます。

データを更新する責任と、今回必要な情報を取得する責任も分かれます。

文書とセクションを分ける

文書の原文を残したまま、見出し単位のセクションを検索対象にします。

検索は細かい単位の方が候補を見つけやすい一方、判断には前後の文脈が必要なことがあります。

そのため、該当する小見出しだけで意味が決まらなければ、上位見出しの範囲まで取得します。

同期状態を先に確認する

検索前に、DBへ接続できるか、想定した文書が同期されているか、更新が止まっていないかを確認します。

同期に失敗したまま検索すると、「見つからない」のか「保存されていない」のかを区別できません。

必要な情報だけを読む

記事を編集するときは、まず記事の役割に関係する文書を検索します。

本文のスタイルが必要なときだけ書き方の資料を取得し、事業判断が必要なら事業知識の資料を取得します。

Notion全体や過去の会話全文を、最初から読み込ませることはしません。

この仕組みで改善したのは、AIに覚えさせる量ではありません。

どれが元資料で、いつ同期され、今回どこを読ませたかを追えるようになったことです。

コンテキスト品質を評価する

コンテキストを増減したあと、文章の印象だけで良し悪しを決めると、改善と偶然を区別できません。

今回の判断に使える状態かを測る性質が、コンテキスト品質です。

僕は、次の六項目で点検します。

同じタスクへ、全資料を渡した場合と段階的に取得した場合を比較すると、設計の差を確認できます。

比較するときは、出力の好みだけでなく、次の結果を記録します。

• 必須条件を満たしたか
• 引用した内容が出典と一致したか
• 古い情報を使わなかったか
• 根拠のない主張を増やさなかったか
• 必要な情報を取得できたか
• 不要な資料を判断へ混ぜなかったか

情報が足りない場合に、推測で埋めず「確認できない」と返せるかも評価します。

取得を止める条件も必要です。

必須条件を判断でき、主要な主張へ出典を付けられ、未解決の競合を明示できたら、今回の取得は終了です。

不足が残るなら検索を続け、権限や元資料がなく確認できないなら人間へ戻します。

FAQ

コンテキストエンジニアリングとプロンプトエンジニアリングは何が違いますか

プロンプトエンジニアリングは、一回の依頼で目的、入力、制約、出力形式、成功条件をどう伝えるかを扱います。

コンテキストエンジニアリングは、その依頼を判断するために何を読ませ、何を省き、いつ取得するかを扱います。

依頼の意味が曖昧ならプロンプトを直し、判断材料が欠けているならコンテキストを直します。

コンテキストウィンドウが広ければ情報整理は不要ですか

不要にはなりません。

容量が広くても、古い情報、競合する情報、不要なツール出力が混ざれば、優先順位の推測が増えるからです。

広いウィンドウは、多くの情報を入れられる上限であり、必要な情報を自動で選ぶ仕組みではありません。

RAGはコンテキストエンジニアリングと同じですか

同じではありません。

RAGは、外部の書庫から関連候補を検索する方法です。

取得した断片へ出典や更新日を付け、どれを推論へ渡すか決める仕事まで含めてコンテキストエンジニアリングです。

会話履歴と長期メモリはどう分けますか

会話履歴には、現在の作業で必要な直近の流れを残します。

長期メモリには、別のセッションでも再利用する決定、選好、状態を残します。

原文や監査記録は、どちらにも閉じ込めず、ファイルやDBを正本にします。

情報を圧縮すると事実が失われませんか

圧縮では、一部の情報が落ちます。

そのため、圧縮した要約だけを正本にせず、元のURL、ファイルパス、文書IDを残します。

判断に必要な事実が要約から落ちたとき、原文へ戻れる構成にします。

古い資料と新しい資料が矛盾するときはどうしますか

更新日だけで決めず、正本、対象期間、承認状態を確認します。

どちらが有効か決められない場合は、差分を隠さず未確定として示します。

価格や製品仕様のように変わる情報は、回答前に一次情報を再取得します。

情報選択チェックリスト

AIへ資料を渡す前に、次のチェックリストを使えます。

## 今回の判断
- [ ] AIが判断する問いを一文で書いた
- [ ] 完了条件を決めた

## 最初から渡す情報
- [ ] 必須の事実だけを選んだ
- [ ] 固定ルールと今回だけの条件を分けた
- [ ] 不要な会話履歴と生ログを外した

## 鮮度と出典
- [ ] 更新日と対象期間を確認した
- [ ] 一次情報または正本を特定した
- [ ] 元のURL、ファイルパス、文書IDを残した
- [ ] 競合する情報を明示した

## 段階的取得
- [ ] 候補一覧から始める
- [ ] 必要なセクションだけを読む
- [ ] 足りないときだけ原文へ戻る

## 次回へ残す情報
- [ ] 決定と未解決事項を記録した
- [ ] 失敗した方法と理由を記録した
- [ ] 圧縮前の原文へ戻れる

この点検で、情報を毎回手作業で選ぶ負担が大きいと分かったら、索引、検索、同期確認を小さな仕組みへ移します。

社内文書や業務知識をAIが安全に参照できる形へ整えたい場合は、お問い合わせからご相談ください。

判断材料がそろったあと、AIへ安全にツールを使わせ、結果を検証する段階はハーネスエンジニアリングで扱っています。

検証結果を受けて次の行動を選び、継続作業を止める段階はループエンジニアリングへ進みます。

情報元

• Effective context engineering for AI agents | Anthropic
• Context Engineering | LangChain
• Context Engineering for AI Agents: Lessons from Building Manus | Manus
• Contextual Retrieval | Anthropic
• mycontext-public | GitHub

更新履歴

2026年7月18日に、4つのAIエンジニアリングの役割分担、注意予算、段階的取得、鮮度と出典、品質評価、FAQ、情報選択チェックリストを追加しました。

実装の詳細と未検証の数値は、ピラーの役割から外れるため本文から分離しました。