前回の記事では我々が使っているチャットエージェント自体が隠蔽されたマルチエージェントだったことを解説しました。そのマルチエージェントシステムにおけるRAGの文脈で本当に語られるべきは、ベクトルデータベースやグラフデータベースを用いた、体系化された知識の注入です。
Web検索という手段は、多くの場合、LLMが正しいコンテキスト（文脈）を保持・参照できなかった結果、やむを得ず外部に答えを求めるという「事後的な手段」です。つまり、あらかじめ用意されたデータ構造から必要な情報を引き出し、プロンプトに注入するRAGこそが、能動的なコンテキストエンジニアリングの本質的なアプローチと言えます。しかし、ここでも後述の問題により手放しで歓迎出来るものでないことを知るべきです。
1. 専門家（LLM）と助手（RAG）：二つのアテンションが引き起こす連携の課題
RAGがデータベースから取り出した知識は、ユーザーの質問や会話履歴と同じく「テキスト」としてプロンプトに注入され、LLMのコンテキストウィンドウに入ります。このプロセスは、LLMを 「専門家」 、RAGを 「助手」 と見立てることで、より深く理解できます。そして、問題の本質は、両者の連携における情報の「質」と「構造」の差にあります。
助手の仕事：検索に特化したアテンション
まず、「助手」であるRAGが仕事を始めます。ユーザーの質問を受け取ると、RAGのクエリエンコーダー（埋め込みモデル）が最初のアテンションを働かせます。ここでの目的は、質問の意図を「検索に最適な形に要約」 することです。
重要なのは、このエンコーダーが採用するアテンション機構は、あくまでテキストを検索用のベクトル（数値表現）に変換するためのものであり、回答を生成するLLM本体のアテンション機構とは目的も構造も異なる、独立したものであるという点です。この要約されたクエリを元に、ベクトルデータベースを検索し、関連性の高い情報（チャンク）を探し出します。
専門家の仕事：生成に特化したアテンション
次に、助手が探してきた「関連情報」が、元の質問や会話履歴と共に「専門家」であるLLMのコンテキストウィンドウに渡されます。LLMの中核であるトランスフォーマーのアテンション機構は、ここで初めて機能します。専門家の仕事は、コンテキストウィンドウ内の全トークン（元の質問、会話履歴、そして助手から渡された資料）の相互関係を$O(n^2)$のコストをかけて計算し、すべてを統合して一貫性のある回答を生成することです。
連携の課題：「外部資料」の統合コストとチャンク欠落
ここで、専門家と助手の連携における課題が、より明確な形で現れます。
RAGによって注入された知識は、専門家から見れば文脈から切り離された「外部資料」の断片（チャンク） です。会話の文脈や質問が持つ元々の論理的な連続性（強いエッジ）とは異なり、この外部資料は本筋との繋がりが弱い（弱いエッジ）可能性があります。
専門家（LLM）は、この外部資料を自身の推論の中核に組み込むために、追加の労力（アテンション）を払わなければなりません。もし、助手が持ってきた資料の関連性が低かったり、会話の流れが強力すぎたりすると、専門家は「この資料は今の議論には関係ないな」と判断し、その情報を事実上無視してしまうことがあります。これが 「チャンク欠落」 と呼ばれる現象の一側面です。
特に、検索された情報がプロンプトの中間（例えば、質問と会話履歴の間）に挿入された場合、LLMがその情報を無視しやすくなる 「Lost in the Middle (LiM)」 という問題も指摘されており、これはチャンク欠落が起こる具体的な一因となります。
なお、Lost in the MiddleはRAGに限らず、長いプロンプト全体で発生し得るアテンション機構の特性による問題です。RAGのチャンクは特にこの影響を受けやすく、適切な制御が必要です。目的の異なる二段階の独立したアテンションプロセスを経ることで、情報の連携に齟齬が生じるリスクがある、という点に注意を払う必要があります。
2. フローチャートとDSL化による「優秀な助手」の育成
この連携の課題を解決する最良の方法が、助手の能力を高め、専門家との連携を密にする回路的な設計です。
回路指向設計とDSL化
LLMを単なる「文章生成専門家」として使うのではなく、複雑なタスクの解決プロセスをフローチャート（回路） として設計します。これは、「助手」の動きを高度化し、ドメイン固有言語（DSL: Domain Specific Language） を通じて専門家への指示を明確にする試みです。
- 知識注入の「タイミング」と「構造」の制御: ただ資料を渡すのではなく、「専門家、このステップではこのデータベースのこのチャンクを参照せよ」といった明確な指示（DSL）を与えることで、専門家のアテンションを意図的に誘導します。これは、優秀な助手が資料の重要箇所に付箋を貼って渡すようなものです。
- マルチエージェントへの進化: これは、前回の記事の結論で触れた「チャットエージェントが隠蔽しているマルチエージェント」を、能動的に活用する行為に他なりません。各ステップを専門のエージェント（知識参照エージェント、要約エージェントなど）に分解し、外部知識の利用をシステム側で厳密に制御することで、助手の能力を飛躍的に向上させます。
このフローチャートを使った回路指向設計こそが、RAGによる知識注入を単なる「資料提供」から、予測可能で信頼性の高い「共同作業」 へと昇華させるための鍵となります。
3. 非対話モード：「助手」がいない状況でのコンテキスト設計
gemini-cliの非対話モードでLLMを利用する様な場合、会話履歴は保持できず、永続的なデータベース接続（助手）もシステム側で提供されていないという制約に直面します。この環境では、ユーザー自身がツールを提供するか、超優秀な助手として振る舞い、短期的・高密度なコンテキストを設計する必要性がより強まります。
⚠️ ただし、このモードでもWeb検索やファイル検索といったツール連携は可能です。しかし、Web検索は体系化されていない知識を取り込むため、RAGが目指す「永続的な知識の構造化と注入」とは異なり、コンテキストの流れを不安定にする要素にもなり得ます。
ここでは、この不安定要素を避けつつ、専門家（LLM）に確実な知識を与えるためのアプローチ、つまり限られたスペース（コンテキストウィンドウ）に「ちょうどいいサイズのボール（コンテキスト）」を収めるネット（グラフ） の設計に焦点を当てます。
- ネットの密度（ノードと強いエッジ）: 助手がいないため、プロンプト内で知識間の関係性（エッジ）と重要な情報（ノード）をユーザー自身が高密度に記述することが不可欠です。
-
「回路指向設計」によるコンテキストの構造化: 外部データベースは持てなくても、以前の記事で提唱したフローチャートを使った回路指向設計の概念を応用し、知識をナレッジグラフ（ノードとエッジ）としてプロンプト内で再現します。このナレッジグラフの基本単位こそがトリプル形式（主語-述語-目的語） です。
- 我々は、「
規約-は必須とする-スネークケース」「関数名-は動詞で始まる-べきである」といったトリプル（強いエッジ）を高密度な表現でプロンプトに凝縮します。 - これにより、専門家（LLM）は限られたトークン内で、決定論的にアテンションを集中すべき構造化されたルールを明確に受け取り、回路の動作原理をプロンプト内で再現します。
- 我々は、「
これは、LLMという高価な椅子（VRAM）を奪い合う中で、与えられたトークン数というリソースを最大限に活用し、情報の密度を高めるという、プロンプトエンジニアリングの究極的な形と言えます。
結論: RAGという「助手」をどう育てるか
RAGは、LLMという専門家の短期記憶の限界を克服し、知識の永続化を実現する強力な 「助手」 です。しかし、専門家が持つアテンション機構との連携に課題が生じるという技術的な事実を忘れてはなりません。
gemini-cliのような非対話モードでグラフデータベースの恩恵を受けたい場合は、自前でデータベースを用意し、その検索結果を、推論のステップやツールの使用を制御する DSL的な命令 の下でプロンプトに注入するという「能動的なマルチエージェント運用（＝超優秀な助手の自作）」が必要です。
うまく設計・育成できれば、RAGは永続的な知識を瞬時に引き出す最高のパートナーになります。しかし、助手の能力が低く、関連性の薄い情報を多量に渡してしまうと、逆に専門家の推論を妨害する足手纏いになるリスクも内在します。コンテキストエンジニアリングにおけるRAGの本質は、このリスクとリターンを見極め、専門家と助手の連携（知識の構造と注入）をシステム側で緻密に制御することにあるのです。