ここまでで、モデルを呼んで応答を得るところまで来ました。でも、単発のチャットだけでは「賢いオウム」で止まってしまいます。実務で本当に欲しいのは、自分で必要なツールを使って作業を進める「エージェント」と、自社のデータに基づいて正確に答える「RAG」の2つです。この記事で、その両方の土台を押さえます。
「エージェント」って言葉はよく聞くけど、普通のチャットと何が違うの？ あと社内文書に基づいて答えさせたいんだけど、それがRAG？
この記事は Azure AI Foundry シリーズの第4回として、エージェントと RAGを次の流れで整理します。
- Foundry Agent Service の概念（モデル + 指示 + ツール + スレッド）を理解している
- スレッド / メッセージ / 実行（Run）の会話モデルを理解している
- ツール（関数呼び出し / コードインタープリター / ナレッジ）を付与できる
- マルチエージェント（Connected Agents）を理解している
- RAG（グラウンディング / embedding / On Your Data / プロンプトフロー）を理解している
Foundry Agent Service｜モデル + 指示 + ツール + 記憶
エージェントとは、モデル（頭脳）に「指示（役割）」「ツール（手足）」「スレッド（記憶）」を組み合わせて、自分で必要なツールを呼びながらタスクを進める存在です。Foundry Agent Service は、これをマネージドで構築・ホストしてくれます。
普通のチャットとの違いは、「自分で道具を使えるかどうか」です。普通のチャットは、聞かれたことに知識だけで答えます。エージェントは、「その質問に答えるには社内DBを検索すべきだ」「計算が必要だからコードを実行しよう」と判断してツールを呼び、その結果を踏まえて答えます。
エージェント ＝
モデル（gpt-4o などの頭脳）
＋ 指示（システムメッセージ：役割・制約）
＋ ツール（関数 / コード実行 / ナレッジ検索）
＋ スレッド（会話の記憶）
ユーザー「先月の売上を集計して」
→ エージェントが「関数ツールでDBを叩く」と判断
→ 結果を受け取って自然言語で回答嬉しいのは、これがマネージドサービスである点です。会話状態の保持やツール呼び出しのオーケストレーションを自前で実装せず、Foundry に任せられます。
【ここが説明できればOK①】
「エージェントはモデル + 指示 + ツール + スレッド。普通のチャットと違い、自分でツールを呼んでタスクを進める。Agent Service がマネージドでホストする」——これを言えればOKです。
スレッド / メッセージ / 実行（Run）｜会話のライフサイクル
エージェントを扱うと必ず出てくるのが、スレッド・メッセージ・実行（Run）という3つの言葉です。これは会話の「単位」を表します。
| 用語 | 役割 | たとえ |
|---|---|---|
| スレッド | 会話履歴（メッセージの列）を保持する入れ物 | 1本のチャットルーム |
| メッセージ | ユーザー／エージェントの各発言 | 吹き出し1つ1つ |
| 実行（Run） | スレッドに対してエージェントを走らせる1回の処理 | 「送信」を押して返事が返るまで |
流れはこうです。スレッドを作り → ユーザーメッセージを追加 → Run を実行。Run の途中でエージェントが「ツールを使いたい」と判断したら、ツール呼び出しが挟まり、その結果を踏まえて最終応答が返ります。スレッドが会話を覚えているので、文脈を引き継いだ多ターンの対話が成立します。
【ここが説明できればOK②】
「スレッド（会話の入れ物）にメッセージを追加し、Run でエージェントを実行。Run の中でツール呼び出しが挟まり、文脈を保った多ターン対話ができる」——これを言えればOKです。
ツール｜エージェントに手足を持たせる
エージェントの強さは、付与するツールで決まります。代表的な3種類を押さえましょう。
- 関数呼び出し（Function calling）：自分で用意した関数（社内 API・DB クエリなど）のスキーマを渡すと、モデルが「この引数で呼んで」と要求してくる。結果を返すとそれを踏まえて回答。外部システムと繋ぐ王道。
- コードインタープリター：サンドボックス内で Python を実行。集計・グラフ生成・ファイル処理など「計算が必要な仕事」を任せられる。
- ナレッジ（File Search / AI Search）：アップロードしたファイルや AI Search のインデックスを検索し、根拠のある回答を返す。次節の RAG と地続き。
「社内 DB を叩きたい → 関数呼び出し」「数値集計・グラフ → コードインタープリター」「文書に基づいて答える → ナレッジ」。やりたいことからツールを逆引きできるようにしておくと設計が速いです。
【ここが説明できればOK③】
「関数呼び出し＝外部システム連携、コードインタープリター＝計算・集計、ナレッジ＝文書検索。やりたいことからツールを逆引きして付与する」——これを言えればOKです。
マルチエージェント（Connected Agents）｜役割分担で協調させる
1体のエージェントに何でも詰め込むと、指示が肥大化して精度が落ちます。そこで登場するのがマルチエージェント（Connected Agents）です。
発想は「会社の組織図」に近いです。オーケストレーター役のエージェントが受付となり、内容に応じて専門エージェント（経理担当・検索担当・要約担当…）に仕事を振り、結果をまとめて返します。各エージェントを小さく専門特化させることで、全体の精度と保守性が上がります。
オーケストレーター（受付・司令塔）
├─→ 検索エージェント（社内文書を探す）
├─→ 集計エージェント（数値をまとめる）
└─→ 要約エージェント（最終回答を整える）
→ 1体に詰め込まず、専門ごとに分けて協調させる【ここが説明できればOK④】
「Connected Agents は、オーケストレーターが専門エージェントに仕事を振って協調させる構成。1体に詰め込まず小さく専門特化させると精度が上がる」——これを言えればOKです。
RAG｜自社データに基づいて答えさせる
最後に、実務で最も需要が高いRAG（Retrieval-Augmented Generation）です。モデルは「学習時点の一般知識」しか持っていないので、社内規程や最新の製品情報は知りません。それを補うのが RAG です。
RAG とは、質問に関連する文書を検索して取り出し、それをプロンプトに差し込んで（グラウンディング）、根拠のある回答を生成する手法です。ハルシネーション（もっともらしい嘘）を大きく減らせます。
仕組みの中核はembedding（ベクトル化）とベクトル検索です。文書を text-embedding モデルで数値ベクトルに変換して AI Search に格納しておき、質問もベクトル化して「意味が近い文書」を取り出します。キーワード一致では拾えない「言い回しの違う関連文書」まで見つけられるのが強みです。
【事前準備】
社内文書 → embedding でベクトル化 → AI Search に格納
【質問時】
質問 → ベクトル化 → AI Search で類似文書を検索
→ 取り出した文書をプロンプトに差し込む（グラウンディング）
→ モデルが「根拠付き・引用付き」で回答Foundry では、この RAG を組む道具立てが揃っています。
- On Your Data：AI Search などをデータソースに接続するだけで、引用付きで自社データに答える構成をローコードで作れる。まず試すならこれ。
- プロンプトフロー：検索 → 整形 → LLM 呼び出しといった処理をノードのグラフとして組み、バリアントを比較しながら評価・デプロイできる。作り込む段階で有効。
「まず On Your Data で最短で動かす→精度を詰める段階でプロンプトフローに移す」。この二段構えが実務の定石だよ！
【ここが説明できればOK⑤】
「RAG は関連文書を検索してプロンプトに差し込み根拠付き回答を作る手法。embedding でベクトル化し AI Search で検索。On Your Data で最短、プロンプトフローで作り込む」——これを言えればOKです。
まとめ
- エージェント＝モデル + 指示 + ツール + スレッド。自分でツールを呼んで進める
- スレッド / メッセージ / Runで多ターン対話のライフサイクルを回す
- ツールは関数呼び出し / コードインタープリター / ナレッジを用途で逆引き
- Connected Agentsで専門特化のエージェントを協調させる
- RAGは embedding + AI Search で検索し、On Your Data / プロンプトフローで構築
ここまでで「動くもの」は作れます。でも本番に出す前に必ずやるべきなのが「品質と安全性の確認」です。第5回では、応答を定量採点する評価（Evaluation）と、有害な入出力を防ぐ責任ある AI（コンテンツフィルター）を整理します。
