RAG、MCP、Function Calling、Tool Use、AIエージェントは、すべて生成AIの業務活用で頻出する言葉ですが、同じものではありません。混同すると、必要以上に複雑な構成を作ったり、逆に安全性に必要な層を抜かしたりします。本稿では「読む」「呼び出す」「つなぐ」「進める」という役割に分けて整理します。
更新日：2026年9月17日。 AIエージェント関連の仕様・製品・料金・提供地域は短期間で変わるため、本稿では考え方と実装判断を中心に整理します。
まず一言で整理する
| 用語 | 一言で言うと | 主な役割 |
|---|---|---|
| RAG | 必要な情報を取り出して回答へ渡す | 社内文書・DBを根拠として参照 |
| Function Calling / Tool Use | 決められた機能を構造化して呼ぶ | 検索、計算、登録、送信など |
| MCP | AIと外部ツールをつなぐ共通接続方式 | ツールやリソースを標準化して公開 |
| AIエージェント | 目的に向かって複数工程を進める | 計画、判断、ツール利用、再試行、完了判定 |
RAGは「知識を追加する」のではなく「必要な根拠を都度取り出す」
RAGは、モデルへ会社のすべての情報を再学習させる方式ではありません。質問に関係する文書やデータを検索し、その一部をモデルへ渡して回答させます。規程、マニュアル、FAQ、製品資料、議事録など、更新される情報を扱いやすいのが利点です。
ただし、検索結果が間違っていれば回答も悪くなります。文書分割、メタデータ、検索方式、権限、更新同期、引用表示を設計します。AIエージェントの前にRAG品質が悪ければ、エージェントは間違った前提で行動するため、検索品質の評価は独立して行う必要があります。
Function Callingは「AIが勝手にAPIを叩く」のではない
Function Callingは、利用可能な関数の名前、説明、引数の形式をモデルへ提示し、モデルが「この関数をこの引数で呼ぶべき」と構造化して返す仕組みです。実際に実行するのはアプリケーション側です。
この分離が安全設計に役立ちます。モデルが削除関数を選んでも、アプリ側で権限を再確認し、承認がなければ実行しない、といった制御ができます。ツールの説明は短く明確にし、似た機能を大量に並べない方が選択精度を上げやすくなります。
MCPは接続の標準化を狙う
MCPは、AIクライアントごとに個別API連携を作り直す負担を減らし、ツール、リソース、プロンプトなどを共通の形式で公開する考え方です。AIエージェントにとっては、社内外の機能へ到達するための接続層になります。
標準化は便利ですが、「接続できる」ことと「アクセスを許可する」ことは別です。MCPサーバーで公開するツールを絞り、認証・認可を実装し、ユーザーやエージェントごとに利用可能範囲を制御します。特に書き込み系ツールは、読み取りと分ける設計が重要です。
AIエージェントは上位の実行ループ
AIエージェントは、RAGで調べ、必要ならツールを呼び、結果を見て次の行動を決め、完了条件まで繰り返す実行ループです。したがって、RAGやMCPを使わないAIエージェントも存在しますし、AIエージェントを使わずにRAGだけ実装することもあります。
「最新の売上状況を分析して経営会議資料を作る」を例にすると、データ取得はSQLツール、過去資料はRAG、ファイル保存はDrive連携、グラフ作成はコード実行、最終承認は人、といった複数機能をAIエージェントがつなげます。
企業でよくある3つの構成
1. RAGだけ
社内FAQ、規程検索、技術文書検索など。回答根拠が必要だが、外部システムへ操作しない場合に向きます。
2. RAG＋ツール呼び出し
顧客情報を読み、回答案を作り、CRMへ下書きを保存するなど、限定された操作を追加する構成です。多くの業務ではこの段階で十分な効果が出ます。
3. AIエージェント＋MCP＋複数ツール
調査、判断、複数システム操作、再試行が必要な長い業務向けです。自由度が高いほど評価・監査・権限設計も強くします。
「全部入り」にしないための判断基準
- 情報検索だけなら、まずRAG
- 一つの決まったAPI操作ならFunction Calling
- 複数AIクライアントから共通ツールを使うならMCPを検討
- 工程分岐や再試行が必要ならAIエージェント
- 複数役割を分ける合理的な理由がある時だけマルチエージェント
構成は複雑になるほど保守コストも増えます。最初から「AIエージェント基盤」を作るのではなく、業務要件に必要な最小構成から始めます。
品質評価は層ごとに分ける
| 層 | 評価例 |
|---|---|
| 検索 | 正しい文書が上位に出るか |
| モデル回答 | 根拠に沿った回答か |
| ツール選択 | 正しい関数を選んだか |
| 引数 | ID、金額、日付を正しく渡したか |
| ワークフロー | 順序と分岐が正しいか |
| 最終結果 | 業務目的を達成したか |
| 安全 | 権限外操作や漏えいがないか |
最終成功率だけでは、どこを直せばよいか分かりません。RAG、ツール、モデル、ワークフローを別々に測ると改善速度が上がります。
実務でさらに深掘りする
4つの概念を同じ階層で比較しない
RAG、Function Calling、MCP、AIエージェントは競合製品のように比較されがちですが、役割の階層が違います。RAGは主に知識取得、Function Callingはモデルから関数を呼ぶ仕組み、MCPはAIクライアントとデータ・ツールを標準化して接続する仕組み、AIエージェントは目的達成のためにそれらを組み合わせて工程を進める実行主体です。
したがって「MCPとRAGのどちらが良いか」ではなく、「この業務では情報検索が必要か、操作が必要か、複数クライアントから共通接続したいか、複数工程を自律的に進める必要があるか」と問い直します。
RAGを強くするのはモデルより文書運用
企業RAGでは、文書を投入した時点で終わりではありません。改訂番号、公開日、部署、製品、顧客、機密区分などのメタデータを付け、最新版だけを優先し、廃止文書を除外できる仕組みが重要です。検索結果に根拠URLや文書IDを付け、利用者が確認できるようにします。
検索精度の評価では、回答文章より前に「必要な文書が上位に取得できたか」を測ります。検索が失敗しているのにプロンプトだけを調整しても改善しません。
Function CallingはAPI契約の品質が重要
Function Callingでは、関数名、説明、引数名、型、必須項目、列挙値を明確にします。「顧客を更新する」のような広い関数より、「顧客の担当部署を仮更新する」「見積候補を作成する」のように操作目的を絞ると誤実行を減らせます。
AIが生成した引数は必ずサーバー側でも検証します。金額の上限、存在するIDか、日付形式、権限、二重実行防止などは、モデルではなくAPI側で確定的にチェックします。
MCP導入で確認する境界
- MCPサーバーは誰が運営し、どこで動くか
- どのresources・tools・promptsを公開するか
- 認証トークンの対象サービスとスコープは正しいか
- AIクライアントごとに利用権限を分けられるか
- ツール入力をサーバー側で再検証しているか
- 外部MCPサーバーのログ・通信先を確認したか
- サーバー更新時の互換性と再評価手順があるか
MCPは接続を容易にしますが、接続先の安全性まで自動的に保証するものではありません。標準化で接続数が増えるほど、登録・所有者管理・監査が重要になります。
具体例：営業提案AIエージェント
営業提案を例にすると、RAGで過去事例やサービス資料を検索し、CRM取得関数で顧客情報を読み、必要な場合はMCP経由でDriveや社内ツールへ接続します。AIエージェントは、調査→不足確認→提案骨子→根拠整理→CRMへの下書き保存という工程を管理します。最終的な価格と顧客への送信は人が承認します。
このように各技術の役割を分けると、障害時の切り分けも容易です。検索が悪いのか、ツールの引数が悪いのか、ワークフローの分岐が悪いのかを個別に測れます。
選定の簡易フローチャートを文章で整理
- 必要な情報が社内文書にあるだけならRAGから開始
- 既存システムの決まった操作が必要ならFunction Calling/APIを追加
- 複数AIクライアントから同じ接続を再利用したいならMCPを検討
- 条件分岐・再試行・複数工程を任せたいならAIエージェント化
- 役割分担や並列化に明確な利点がある時だけマルチエージェント化
複雑な構成は最後に追加します。最小構成で評価可能な状態を作る方が、本番導入へ到達しやすくなります。
よくある質問
RAGだけでAIエージェントと言えるか
RAGは情報取得の仕組みであり、それだけで複数工程を自律的に実行するわけではありません。ただし製品によって「エージェント」という言葉の範囲は異なります。実務では名称より、検索だけなのか、ツールを選び、状態を持ち、複数工程を完了まで進めるのかを確認する方が重要です。
MCPを使えばAPI開発は不要になるか
既存MCPサーバーで必要な機能が提供されていれば接続作業を減らせますが、業務固有の認証・検証・権限は残ります。MCPは接続の共通作法であり、業務ロジックや安全性を自動で作るものではありません。必要に応じて独自サーバーや既存APIのラッパーを実装します。
Function CallingとMCPはどちらを選ぶべきか
単一アプリ内で数個のAPIを確実に呼ぶだけならFunction Callingで十分な場合があります。複数のAIクライアントから同じデータ・ツールを再利用したい、標準化した接続層を作りたい場合はMCPが候補です。両者は併用でき、MCPで公開されたツールをモデルがツール呼び出しする構成もあります。
RAGの検索精度が悪い時はモデルを変えるべきか
まず検索結果を確認します。必要文書が取得できていないなら、チャンク、メタデータ、検索方式、フィルター、文書整備を改善します。必要文書が取れているのに回答が悪い場合に、プロンプトやモデルを見直します。検索と生成を分離して評価することが近道です。
業務システムへの書き込みはどこで検証するか
モデルが生成した引数をそのまま実行せず、APIやツール側で型、範囲、権限、重複、業務ルールを再検証します。AIが「正しいはず」と判断しても、サーバー側の確定的な制約を越えられない設計にします。重要操作はさらに人の承認を加えます。
最初の構成はどうすればよいか
一つの情報源、一つの読み取りツール、一つの明確な完了条件から始めるのが安全です。評価が安定したら、書き込み、複数ツール、長期状態を順に追加します。最初からRAG・MCP・マルチエージェントを全部入れると、失敗原因を切り分けにくくなります。
導入判断をより確実にする追加論点
アーキテクチャ選定で残すべき記録
なぜRAGを使うのか、なぜMCPが必要なのか、なぜAIエージェント化するのかを、製品名ではなく要件で記録します。例えば「複数クライアントから同じ社内検索を再利用するためMCP」「問い合わせ内容に応じて3種類のAPIを選び複数工程を進めるためエージェント」と説明できる形です。
この記録があると、将来別製品へ移行する時に、何を維持し、何を捨てられるか判断しやすくなります。技術選定の理由を残すこと自体がベンダーロックイン対策になります。
障害対応を層別に設計する
RAG検索が失敗した時、MCP接続が切れた時、APIが429を返した時、モデルが不正な引数を作った時では対応が異なります。すべてを「AIエラー」にまとめず、各層のエラーコードと再試行条件を定義します。
再試行しても意味がない入力不足や権限エラーは、人へ明確な理由を返します。一時的なネットワーク障害だけを限定回数再試行し、無限ループと費用増加を防ぎます。
接続技術を増やす前に共通データ定義を整える
顧客ID、商品コード、部署名、日付、金額など基本データの意味がシステムごとに違うと、AIエージェントが接続できても誤更新が起きます。ツールの入力・出力で共通のIDとスキーマを定義し、名称の表記揺れを吸収します。
AIは曖昧さを補完してしまうため、マスタデータの不整合が見えにくくなる場合があります。接続の前提となるデータ品質を測ることもAIエージェント導入の重要な工程です。
参照した一次情報・海外情報
本稿は、単一記事の翻訳転載ではなく、複数の一次情報・公式ドキュメントを照合し、日本企業の導入判断に必要な観点へ再構成したオリジナル解説です。各仕様は更新されるため、実装時はリンク先の最新版をご確認ください。
- A practical guide to building agents（EN）
- 腾讯云智能体开发平台 使用流程（ZH）
- 低代码创建Agent快速入门（ZH）
- وثائق إطار عمل العامل（AR）
AIエージェント導入を、構想だけで終わらせないために
AIエージェントは、モデル選定だけでは成果が決まりません。対象業務の分解、データ接続、権限、評価、現場運用までを一つの設計として扱う必要があります。Accomplirでは、AI導入、RAG、MCP、FDE人材、業務自動化を分断せず、実際に使われ続ける状態まで支援します。
AIエージェント・AI導入について無料相談する / FDE人材の発注・育成を見る / MCP導入の考え方を見る / RAG構築の考え方を見る