7月14日、Towards Data Scienceが「Agentic RAG: Let the Agent Search」と題した記事を公開した。OpenAI Agents SDKを使い、エージェントが自律的に検索・読取・判断を繰り返すAgentic RAGの実装を、ポリシーQ&Aエージェントというケーススタディで丁寧に解説している。「類似度検索が正しい根拠を拾えない」「チャンク境界で文脈が失われる」という従来RAGの古傷に、エージェント設計の視点から真正面から切り込んだ内容だ。
従来のRAGが抱える構造的な問題
多くのRAGアプリは「チャンク化 → 埋め込み → 検索 → 回答生成」という定番のパイプラインで組まれる。一見きれいだが、実運用ではすぐに破綻する。類似度検索は「似た表現」を拾うが「有用なチャンク」を拾うとは限らない。正しい根拠がランキング下位に埋もれることもある。重要なコンテキストがチャンク境界で分断されることもある。
こうした問題への回答がAgentic RAGだ。モデルが検索し、読み、「証拠が十分か」を自分で判断し、必要なら再検索する。ベクトル埋め込みすら必要ないケースもある。
Agentic RAGはここ数年で急速に注目を集めているアーキテクチャパターンであり、LangGraphやLlamaIndexといったフレームワークも独自のAgentic RAG実装を提供している。本記事が採用するOpenAI Agents SDKはそれらと比べてツール定義・トレースの仕組みがシンプルで、「エージェントがどう動くか」を透明に観察しやすい点が特徴的だ。※編集部の考察
ポリシーQ&Aエージェントの実装
記事では、社内規程ドキュメントを対象にしたポリシーRAGエージェントをケーススタディとして構築している。
ドキュメント構成
6つの合成ポリシー文書（すべてMarkdown）を用意している。意図的に「1つの質問への答えが複数ドキュメントにまたがる」設計になっている点がポイントだ。
travel_policy.md：出張の基本ルール（2025年3月施行）approval_matrix.md：承認レベルの定義（2025年7月施行）conference_guidelines.md：外部イベント参加ルール（2025年5月施行）policy_updates_2026.md：2026年版の更新内容（2026年1月施行）remote_work_policy.md：リモートワークルール（2026年2月施行）faq.md：よくある質問への非公式回答（2025年9月施行）
エージェントの定義
OpenAI Agents SDKを使い、エージェントの定義はシンプルだ：
from agents import Agent
agent = Agent(
name="Policy research assistant",
instructions=INSTRUCTIONS,
model="gpt-4o",
tools=[list_docs, search_docs, read_doc],
)
※元記事のモデル名表記をそのまま反映している。元記事で異なる表記がある場合は原文を参照されたい。
エージェントが使えるツールは3つに限定されている：
list_docs — ドキュメント一覧を返す（本文は含まない）。エージェントが「何があるか」を把握するための入口。
search_docs — キーワードによるトークンオーバーラップで段落チャンクを検索し、上位3件のスニペットを返す。ここでは意図的にベクトル埋め込みを使っていない。
@function_tool
def search_docs(query: str) -> list[dict]:
"""Search policy documents and return the top three short snippets."""
query_tokens = tokenize(query)
scored = []
for chunk in chunks:
score = len(query_tokens & chunk["tokens"])
if score:
scored.append((score, chunk))
scored.sort(key=lambda item: item[0], reverse=True)
...
read_doc — ファイル名を指定して1ドキュメントを全文取得する。
この3ツール構成は意図的にミニマルに設計されている。ツールを絞ることで、エージェントの判断ループが追いやすくなり、どのドキュメントをなぜ読んだかのトレースが明確になる。複雑な実装から始めるのではなく「最低限のツールで何ができるか」を検証する姿勢が、実装全体を通じて一貫している。
実際のエージェント動作トレース
テストした質問は以下のとおり：
「ベルリンの学会に参加予定。主催者指定のホテルがあるが、通常の上限を超える宿泊費がかかる。そのホテルを予約できるか？予約前にどんな承認が必要か？」
エージェントの動きをresult.new_itemsから追うと、以下のループが確認できる：
search_docs("conference hotel")/search_docs("hotel cap approval")などで検索list_docs()でドキュメント一覧を確認read_doc("conference_guidelines.md")/read_doc("travel_policy.md")/read_doc("approval_matrix.md")/read_doc("policy_updates_2026.md")を順次読み取り- 最終回答を生成
回答は正確で、conference_guidelines.mdから「業務上の合理的理由があれば上限超えのホテルを予約可能」、approval_matrix.mdとpolicy_updates_2026.mdから承認条件を引用していた。1つの質問に対して4ドキュメントを横断して根拠を収集したことになる。このトレースこそがAgentic RAGの本質を示している。従来のRAGであれば類似度の高いチャンクを数件返して終わりだが、エージェントは「まだ根拠が足りない」と判断して読み取り対象を自分で拡張した。
完全な実装コードはGitHubリポジトリで公開されている。
実用化前に答えるべき5つの問い
記事の後半は、実際にAgentic RAGをプロダクションで使う際の設計判断を5つの問いとして整理している。実装のシンプルさとは対照的に、ここでの議論は設計の本質に踏み込んでいる。
Q1: エージェントにどこまでの権限を与えるか？
ツールを厳密に限定すれば制御・テスト・監査がしやすい。シェルやファイルシステムへのフルアクセスを与えれば柔軟性は上がるが、挙動の予測が難しくなる。まずはツール限定から始めるべきだという立場が明示されており、本記事の3ツール構成はその実践例そのものだ。
Q2: 生テキストだけを検索対象にするか？
ドキュメントメタデータ、サマリー、ドキュメント間リンク、知識グラフといった「知識レイヤー」を生テキストの上に重ねることで検索を補助できる。エージェントが参照できる情報の質を上げることが、回答精度の向上に直結する。
Q3: 埋め込みは不要か？
Agentic RAGであっても埋め込みベースの検索を「エージェントが呼び出せるツール」として実装することは有効だ。純粋なキーワード検索よりも意味的な近さを捉えやすい場合がある。埋め込みは「ツールの実装手段の一つ」として位置づけられる。本記事ではあえて埋め込みを使わない構成を選んでいるが、それはアーキテクチャの核心を見えやすくするための選択であり、本番環境では用途に応じて組み合わせる判断が求められる。
Q4: 1つのエージェントですべてをカバーすべきか？
タスクが複雑化すれば、プランナー・リトリーバー・ライターのように役割分担したマルチエージェント構成が選択肢になる。ただし協調の複雑さが増すため、単一エージェントより必ずしも優れるとは限らず、実験的な検証が重要だとしている。
Q5: 常にAgentic RAGを使うべきか？
「トレンドだから使う」という判断は避けるべきで、レイテンシ・トークンコスト・挙動の予測困難さといったコストが伴う。まずシンプルな実装で始め、反復的な検索が実際に必要な場合にのみエージェントループを追加するのが推奨されている。この問いが最後に置かれているのは示唆的だ。Agentic RAGは強力だが、使いどころを誤れば複雑さとコストだけが増す。
詳細はAgentic RAG: Let the Agent Searchを参照していただきたい。
