コンテキストエンジニアリング実装ガイド｜RAG・MCP・メモリをどう組み合わせるか

目次

---

1. コンテキストエンジニアリングは「文脈の設計図」を作る仕事

AIエージェントの精度を上げようとすると、多くの企業は最初にモデル選定やプロンプト改善へ目が向きます。もちろんモデル性能と指示文は重要です。しかし、実務でエージェントを動かすと、失敗の原因は「モデルが賢くない」ことより、判断に必要な文脈が足りない、または余計な文脈が混ざりすぎていることにある場合が少なくありません。

たとえば、社内AIに「この問い合わせに回答して」と依頼したとします。正しく答えるには、問い合わせ本文だけでなく、顧客の契約状況、最新のFAQ、過去の対応履歴、社内ルール、回答してよい範囲、送信前に人間承認が必要かどうかまで必要になります。逆に、過去の無関係な会話、古いFAQ、権限外の文書、長すぎるツール実行ログが同じコンテキストに入ると、AIは判断を誤りやすくなります。

コンテキストエンジニアリングとは、こうした情報を場当たり的に詰め込むのではなく、AIがその瞬間に必要とする文脈を、必要な粒度で、安全に渡すための設計です。プロンプトを書く技術というより、RAG、MCP、会話メモリ、業務システム、ツール実行結果、監査ログを組み合わせて、エージェントの判断環境を作る仕事だと考えると分かりやすくなります。

この記事では、既存の「コンテキストエンジニアリングとは？」という入門から一歩進み、実装時に何をRAGで取るのか、何をMCPでつなぐのか、何をメモリとして残すのか、ツール結果をどこまで次の推論に渡すのかを整理します。

2. RAGだけではエージェントの文脈は足りない

社内AIの文脈設計というと、まずRAGを思い浮かべる方が多いはずです。RAGは、社内文書やFAQ、設計書、議事録、問い合わせ履歴などを検索し、回答生成時に参照させる仕組みです。モデル単体の知識に頼らず、社内の最新情報を使える点で非常に有効です。

ただし、AIエージェントの実装では、RAGだけでは足りない場面が増えます。RAGが得意なのは「関連する文書を探して読む」ことです。一方で、エージェントが業務を進めるには、現在のユーザー権限、操作対象の最新状態、外部APIの実行結果、前回までの作業メモ、途中で失敗したツール呼び出し、承認待ちの状態なども必要になります。これらは単純な文書検索だけでは扱いにくい文脈です。

よくある失敗は、RAGにあらゆる情報を入れようとすることです。FAQも、顧客情報も、操作ログも、会話履歴も、ツール結果も、すべてベクトル検索に寄せてしまう。PoCでは動いているように見えますが、本番では情報の鮮度、権限、更新頻度、検索ノイズの問題が出ます。

たとえば、契約ステータスのように常に最新値が必要な情報は、RAGに取り込んだ古い文書から探すより、MCPやAPI経由で業務システムから取得した方が安全です。ユーザーの好みや前回の作業方針のように継続的に使う情報は、検索インデックスではなくメモリとして管理した方が扱いやすい場合があります。長いツール実行ログは、そのまま次の推論に渡すのではなく、必要な事実だけに圧縮する方が精度とコストの両面で有利です。

RAGは重要な部品ですが、コンテキストエンジニアリング全体から見ると「文書知識を取り出す層」です。エージェントの文脈設計では、RAG以外の文脈ソースも分けて考える必要があります。

3. RAG・MCP・メモリ・ツール結果の役割を分ける

コンテキスト設計で最初に決めるべきなのは、情報の置き場所です。AIに渡す情報はすべて同じように見えますが、実務では性質が違います。更新頻度、権限、必要なタイミング、監査の必要性、再利用性が異なるためです。

RAGに向いているのは、規程、FAQ、設計書、マニュアル、過去のナレッジのように、文書として検索できる情報です。検索結果には文書ID、更新日、公開範囲、引用元の見出しなどのメタデータを付けると、回答の根拠確認や権限チェックがしやすくなります。

MCPや外部ツールに向いているのは、今その場で取得すべき情報や、操作を伴う処理です。顧客DBを検索する、チケットを作る、Gitの差分を読む、CIログを取る、ブラウザで画面を確認する、といった処理は、静的なRAGよりツール連携で扱う方が自然です。MCPを使う場合は、Resources、Tools、Promptsを分け、読むだけの情報と実行する操作を混ぜないことが重要です。

メモリに向いているのは、会話をまたいで保持したい方針や状態です。ユーザーの部署、好む出力形式、プロジェクトの前提、過去に決めた設計方針などが該当します。ただし、メモリは便利な反面、古い情報が残るリスクもあります。何を保存するか、誰が更新できるか、いつ無効にするかを決めないと、AIが過去の前提に引きずられます。

ツール結果は、エージェントが作業中に得た観測情報です。検索結果、APIレスポンス、テスト結果、ログ抜粋、ブラウザ操作の結果などが含まれます。これらをすべて会話履歴に積み上げると、コンテキストが肥大化します。実装では、次の判断に必要な結果だけを残し、詳細ログは監査用ストレージに逃がす設計が必要です。

この役割分担ができていると、AIエージェントの実装はかなり安定します。逆に、すべてをプロンプトに貼る、すべてをRAGへ入れる、すべてを会話履歴に残すという設計は、短期的には簡単でも長期運用では破綻しやすくなります。

4. 実装時に決めるべき5つの設計ポイント

コンテキストエンジニアリングを実装に落とすときは、まず「どの情報をAIに渡すか」ではなく、「いつ、誰に、どの粒度で渡すか」を決めます。ここを曖昧にしたまま作ると、RAGやMCPの技術選定が正しくても、実務では使いにくいシステムになります。

1. 初期コンテキストと実行時コンテキストを分ける

初期コンテキストは、エージェントがタスク開始時に必ず知っておくべき情報です。役割、禁止事項、回答形式、業務ルール、利用できるツールの概要などが含まれます。一方、実行時コンテキストは、作業の途中で必要になったときだけ取得する情報です。チケット詳細、顧客情報、該当FAQ、テストログなどが該当します。

初期コンテキストに何でも入れると、モデルは毎回大量の前提を読みながら作業することになります。これはコストが増えるだけでなく、重要な指示が埋もれる原因にもなります。最初に渡すのは作業のルールと判断軸に絞り、業務データは必要になった時点でRAGやMCPから取得するのが現実的です。

2. RAGの検索結果は「多く取る」より「使える形にする」

RAGの検索精度を上げようとして、取得件数を増やす設計があります。しかし、AIに渡す文書が増えるほど、関係の薄い情報や古い情報も混ざります。重要なのは件数ではなく、検索結果をAIが判断しやすい形に整えることです。

実務では、検索結果ごとに文書タイトル、更新日、部門、公開範囲、該当箇所、信頼度、類似度、引用IDを添えると扱いやすくなります。AIには本文だけでなく、「この情報がどこから来たか」「どの程度新しいか」「誰向けの文書か」を一緒に渡します。これにより、古いFAQと最新マニュアルが競合したときに、どちらを優先すべきか判断しやすくなります。

3. MCPツールは業務の意味に近い単位で設計する

MCPやFunction Callingでツールを公開するとき、既存APIをそのままAIに見せると扱いづらくなります。人間の開発者向けAPIは、AIが業務文脈の中で安全に選ぶには粒度が細かすぎたり、名前が抽象的すぎたりします。

たとえば、CRMの update_customer をそのまま公開するより、顧客メモの下書きを作成する、承認済みの対応履歴を追加する、契約ステータスを読み取る のように、読み取り、下書き、更新を分けます。AIが使うツール説明文には、できることだけでなく、できないことも書きます。契約金額は変更しない、外部送信はしない、削除操作は扱わない、といった制約は、ツール選択の精度と安全性に直結します。

4. メモリは「保存する価値」と「期限」を決める

長期メモリは、エージェントを便利にします。毎回同じ前提を説明しなくても、プロジェクトの文脈やユーザーの好みを踏まえた対応ができます。しかし、企業システムではメモリに何を残すかを慎重に決める必要があります。

保存してよいのは、将来の作業品質を明確に上げる情報です。たとえば、プロジェクトの命名規則、レビュー観点、顧客ごとの回答トーン、定例レポートの形式などです。一方、個人情報、秘密情報、一時的な作業メモ、古くなりやすい業務状態は、保存対象から外すか、期限付きにします。メモリは増やすほど便利になるのではなく、正しく更新されている範囲で価値を持ちます。

5. ツール結果は圧縮してから次の推論に戻す

AIエージェントは、検索、API呼び出し、テスト実行、ブラウザ操作などを繰り返します。この結果をすべて会話履歴に残すと、コンテキストがすぐに膨らみます。長いログや大量の検索結果が残ると、モデルが重要な情報を見落としやすくなります。

実装では、ツール結果を「監査用の詳細ログ」と「次の推論に渡す要約」に分けます。たとえば、テストログ全体は保存しておき、AIには失敗したテスト名、エラーメッセージ、関連ファイル、再実行結果だけを渡す。ブラウザ操作の詳細履歴は保存し、AIには現在画面の状態と失敗理由だけを渡す。こうした圧縮は、精度だけでなく推論コストにも効きます。

5. コンテキスト汚染を防ぐ評価とログ設計

コンテキストエンジニアリングで見落とされやすいのが、評価です。RAGを導入した、MCPでツールをつないだ、メモリを持たせた、というだけでは、良い文脈設計になっているかは分かりません。むしろ、文脈を増やしたことで誤回答が増えることもあります。

コンテキスト汚染とは、不要な情報、古い情報、権限外の情報、誤ったツール結果が推論に混ざり、AIの判断を悪化させる状態です。人間でも、判断材料が多すぎたり、古い資料と新しい資料が混在したりすると迷います。AIも同じで、コンテキストが増えれば必ず賢くなるわけではありません。

評価では、最終回答だけでなく、途中でどの文書を検索したか、どのツールを呼んだか、どの結果を次の推論に渡したかを記録します。回答が間違っていた場合、モデルの問題なのか、検索結果が悪かったのか、ツール説明が曖昧だったのか、メモリが古かったのかを切り分けられるようにします。

現場で使いやすい評価観点は次の5つです。

この評価を回すには、ログ設計が欠かせません。ユーザーの入力、検索クエリ、検索結果ID、ツール名、ツール引数、実行結果、要約後のコンテキスト、最終回答、エラー、承認者を追えるようにします。すべてをプロンプトに残す必要はありませんが、監査と改善のためには外部ログとして残すべきです。

特に企業向けAIでは、文脈設計とガバナンスは分けられません。どの情報をAIに渡したかを説明できなければ、誤回答や情報漏洩が起きたときに原因を追えません。AIエージェントの品質改善は、プロンプトの書き換えだけではなく、文脈の取得、選択、圧縮、破棄のログを見ながら進める作業になります。

6. 導入前チェックリスト

コンテキストエンジニアリングを社内AIやAIエージェントに組み込む前に、次の項目を確認しておくと実装の迷いが減ります。

• 初期コンテキストに入れる情報と、実行時に取得する情報を分けている
• RAG対象文書に更新日、所有者、公開範囲、文書IDを付けている
• MCPやツール連携で、読み取り、下書き、更新、送信を分けている
• ツール説明文に、できることと禁止事項を書いている
• メモリに保存する情報、保存しない情報、期限付きで消す情報を決めている
• 長いツール結果をそのまま推論に戻さず、必要な事実だけに圧縮している
• 検索結果、ツール呼び出し、要約後コンテキスト、最終回答をログで追える
• 権限外情報や古い情報が回答に混ざっていないか評価できる
• モデルやツールを変更したときに、同じ評価セットで再確認できる

このチェックリストは、最初から大規模な基盤を作るためのものではありません。小さな社内FAQエージェントでも、開発支援エージェントでも、文脈の入口と出口を決めておくことが重要です。後から直すより、最初に「何をAIに見せるか」を設計しておく方が、本番化はずっと楽になります。

7. まとめ

コンテキストエンジニアリングは、プロンプトを長くする技術ではありません。AIエージェントが正しく判断できるように、RAG、MCP、メモリ、ツール結果、ログを組み合わせ、必要な文脈だけを必要なタイミングで渡す設計です。

RAGは文書知識を取り出すために使い、MCPやツールは最新状態の取得や業務操作に使う。メモリは継続的に価値がある前提だけを残し、ツール結果は次の判断に必要な形へ圧縮する。この役割分担ができると、AIエージェントは単なるチャットではなく、業務の流れに沿って安定して動くシステムに近づきます。

OpenBridgeでは、RAG、MCPサーバー設計、AIエージェント開発、ローカルAI、監査ログ設計まで含めて、企業向けAIシステムの導入を支援しています。社内AIの精度が安定しない、エージェントが途中で文脈を見失う、RAGとツール連携の設計に迷っている場合は、モデル選定の前にコンテキスト設計を見直すことをおすすめします。