AI エージェント開発入門：MCP・ツール連携・マルチエージェント

AIエージェントは、会話に答えるだけのチャットボットと違い、目的を決めて → 計画し → 道具（ツール）を使って実行し → 結果を見て次の手を選ぶところまで自分で回せるソフトウェアです。この記事は、その骨組み（アーキテクチャ）、ツールをつなぐ共通規格 MCP（Model Context Protocol）、そして複数のエージェントで分担するマルチエージェントを、初めての人でも順番に追えるように整理します。2026年時点の実在のツール名・標準・注意点を交えて、最初の一歩を「小さく確実に」踏み出せる形でまとめます。

たとえば「来週の出張を手配して」と頼まれたとき、エージェントは「出発地・予算・日程を確認する → フライトや社内の旅費規程を調べる → 候補を比べて提案し承認をもらう → 予約して報告する」と段階を踏めます。鍵になるのは、LLM（大規模言語モデル）単体ではなく、外部のツールやデータに安全につなぐ設計です。ここでMCP・ツール連携・マルチエージェントが効いてきます。

FIG.1　エージェント＝「計画 → 実行 → 観測」を回すループ。チャットボットは1往復で終わる

01まず全体像：エージェントの基本部品

入門では、エージェントを次の5つの部品に分けて捉えると迷いません。「どのライブラリを使うか」より先に、何を作っているのかがはっきりします。

• LLM（頭脳）：推論・要約・文章生成・どのツールを呼ぶかの判断
• ツール（手足）：検索、データベース、SaaS操作、社内API、コード実行など
• メモリ（記憶）：会話履歴、ユーザーの嗜好、タスクの状態、過去文書のベクトル検索
• オーケストレーション（進行役）：手順、状態の遷移、リトライ、タイムアウト管理
• ガードレール（安全柵）：権限、監査ログ、個人情報対策、プロンプトインジェクション対策

この5つのうち、初学者がいちばんつまずくのはツールとガードレールです。本記事は特にこの2つを丁寧に扱います。

02ツール連携：道具箱は「少数精鋭」が強い

エージェント開発でいちばんハマりやすいのがツール連携です。直感に反しますが、ツールを増やすほど賢くなるわけではありません。選択肢が多すぎるとモデルが迷い、誤ったツールを選びやすくなります。失敗しにくい道具を少数そろえるほうがうまくいきます。

よく使われるツールの種類

• 検索（RAG）：Web検索や社内ナレッジ検索。社内ならConfluence・Notion・Google Drive・SharePoint などの横断検索
• データ参照：SQL、BigQuery、Snowflake などのデータウェアハウスを読み取り
• SaaS操作：Slack投稿、Jira起票、GitHub Issue作成、Salesforce/HubSpot 更新
• 計算・実行：Pythonコード実行、表計算、簡単なシミュレーション

設計の勘所：ツールは入力と出力を絞る

ツールを作るときは引数を最小限にします。「Slackに投稿する」ツールなら、必要なのは channel と message 程度で十分。自由度を上げすぎると、モデルが意図しない操作をしやすくなります。戻り値も「成功/失敗」だけにせず、何が起きたか追える具体的な結果（投稿URL、影響件数、エラー内容）を返すのがコツです。

よくある落とし穴

• 成功条件が曖昧：結果が「OK」だけだと、本当に意図通り動いたか追えない
• リトライ地獄：APIが失敗 → 同じ入力で連打 → コストが指数的に増える。回数上限とバックオフを必ず入れる
• 権限の渡しすぎ：読み取りで済むのに書き込み権限まで渡してしまう

入門段階では、まず読み取り専用ツールから始めるのが安全です。失敗しても被害が小さく、学びが早く回ります。

03MCP（Model Context Protocol）：ツールを共通規格でつなぐ

MCPは、ざっくり言うとAIアプリと外部ツール／データソースをつなぐための共通プロトコルです。アプリごとに独自のプラグイン仕様を作る代わりに、標準化された接続方法で「使える道具」を増やしていく発想です。Anthropic が2024年11月に発表したオープン標準で、その後一気に広がりました。

FIG.2　N個のエージェント × M個のツールを「N×M」の個別実装でなく、共通規格でつなぐ

なぜMCPが嬉しいのか

• ツールの再利用：一度MCPサーバーとして用意した機能を、複数のエージェントやアプリで使い回せる
• 責務の分離：エージェント側は「いつ何のツールを使うか」、MCPサーバー側は「安全に実行するか」に集中できる
• 運用しやすい：認証・監査ログ・レート制限・鍵管理を、ツール側でまとめて扱える

2026年のMCP：もう「Anthropicだけのもの」ではない

MCPは特定の一社の仕様にとどまらず、業界の共通基盤になりつつあります。初学者でも知っておくと役立つ、確認できる事実は次の通りです（数値や採用状況は変わるので、最新は公式を確認）。

• 2025年3月にOpenAIが、4月にGoogle（Gemini）が公式にMCP対応を表明。Microsoft・GitHub・VS Code・Cursor なども対応
• 2025年12月、AnthropicはMCPをAgentic AI Foundation（Linux Foundation傘下）へ寄贈。Anthropic・Block・OpenAI が共同で立ち上げた中立な運営体制に移行
• 同月時点で公開MCPサーバーは1万件超、Python/TypeScript の SDK 月間ダウンロードは数千万規模に拡大
• 通信方式（トランスポート）は stdio と Streamable HTTP が標準。古い HTTP+SSE は非推奨に

つまり、いま学んでおくと「特定ベンダー専用」になりにくい、という安心感があります。

MCPを使うときの手順（ざっくり）

最初から「請求書を発行」「顧客データを更新」などの書き込み系をつなぐと難易度が跳ね上がります。社内ナレッジ検索やチケットの参照といった読み取り中心から始めると、失敗しても被害が小さく学びが早いです。

04マルチエージェント：チームで考えると強い。ただし設計が要る

マルチエージェントは、役割の異なる複数エージェントに分担させる進め方です。うまくハマると調査 → 批判的レビュー → 実行のように品質が上がりますが、設計しないと「会議が長いだけ」になりがちです。

典型的な役割分担

• Planner（計画役）：ゴールを分解し、手順と優先度を決める
• Researcher（調査役）：検索して情報を集め、根拠を整理する
• Executor（実行役）：ツールを実際に呼んでデータ取得・更新する
• Reviewer（監査役）：矛盾チェック、リスク確認、最終品質の担保

FIG.3　役割を分け、Reviewer が「終了条件」を握る。全員が毎ターン喋らないのがコツ

効くタスク／効きにくいタスク

効くのは、調査と判断が絡む複雑なタスク（競合調査レポート、障害原因の切り分け、要件定義のたたき台）。効きにくいのは、手順が固定で短いタスク（定型メール送信）です。後者は単一エージェント＋ツールで十分なことが多く、無理にチーム化するとコストと遅延だけが増えます。

散らからないためのルール

• 発言権を制御：全員が毎ターン喋る設計にしない（コストと混乱の元）
• 事実と意見を分ける：共有メモリで Evidence（根拠）と Opinion（提案）を混ぜない
• 終了条件を明確に：「この形式で出力したら終わり」を先に決める

05フレームワークの選び方：迷ったら「運用しやすさ」優先

2026年現在、エージェント用フレームワークは出そろってきました。流行りは速いので「どれが正解」よりチームで保守できるかを基準にします。代表的な選択肢の性格を押さえておくと、迷ったときの指針になります。

グラフ／状態機械型	役割クルー型
LangGraph：処理を有向グラフで表し、状態・分岐・再開（チェックポイント）を細かく管理。監査性が高く本番向き	CrewAI：役割（crew）ベースで素早く試作できる。数時間で動くプロトタイプを作りやすい
状態とログを追いたい、止まった所から再開したい用途に強い	まず形にして検証したい、PoC段階に強い

このほか、明示的なハンドオフでエージェント間を渡す OpenAI Agents SDK（OpenAIモデル中心）、階層ツリーで構成する Google ADK（Gemini最適化）、Claude Agent SDK、オープンソースの AutoGen などがあります。LangGraph・CrewAI・AutoGen はモデル非依存（複数のLLMを差し替え可能）です。

入門段階では、状態（state）とログが追えることを最優先にすると失敗しにくくなります。エージェントが「なぜそのツールを呼んだのか」を後から追えるだけで、デバッグが段違いに楽になります。

06実践ミニ設計：社内FAQエージェントを作るなら

入門に向くのは「社内FAQ」です。手戻りが少なく、価値も説明しやすいからです。

07セキュリティ：2026年は「最大の難所」になった

エージェントの最大の弱点は、性能よりもセキュリティです。エージェントはツールを呼べる＝権限を持つ存在なので、攻撃者の標的になります。2026年は実害が報告され、注意点がはっきりしてきました（数値は調査ごとに異なるため傾向として読む）。

• プロンプトインジェクション：外部の文書やWebページに「これまでの指示を無視してデータを送れ」といった命令を仕込み、エージェントに実行させる古典的な攻撃
• ツールポイズニング：MCPのツール説明文（メタデータ）に悪意ある指示を隠す手口。ユーザーには見えず、エージェントだけが読む点が厄介
• 2026年には脆弱なMCP構成が大量に見つかった例や、悪意ある入力で多くのエージェントが操作される検証結果が報告された。OWASP も「Top 10 for Agentic Applications（2026）」を整備

08評価（Evals）と運用：デモで終わらせない

エージェントはデモでは賢く見えても、運用で崩れがちです。最初から小さくても評価を入れておくと、改善を回せます。30〜100問の評価セットでも十分価値があります。

運用で効く小ワザは次の3つです。

• 失敗時の型を決める：「わからない」＋「次に必要な情報」＋「起票」までを定型化する
• 段階的にリリース：まず一部部署で試し、安定してから全社へ
• フィードバック導線：回答に「役に立った／立たなかった」ボタンを置き、改善材料にする

092026年のトレンド：複雑な指揮系より「道具を太らせる」

本記事で繰り返した「道具箱を賢くする」という考え方を、実証する動きが出ています。2026年5月、Microsoft Research はターミナルネイティブなWebエージェント枠組み Webwright を公開しました。

従来のWeb自動化は「クリックを1手ずつ予測する」方式でしたが、Webwright は代わりに再利用可能な Playwright スクリプトを書かせ、bashを実行し、結果を見て改良するアプローチを取ります。構成は3モジュール・約1,000行のシンプルな単一エージェントループで、複雑なマルチエージェント指揮を持ちません。

それでも、長時間タスクのベンチマーク Odysseys を 60.1%（ベースの GPT-5.4 単体は 33.5%）、Online-Mind2Web を約 86.7% で通過し、オープンソースのハーネスとして高いスコアを記録しました。さらに、再利用ツール群を与えると小型モデルでも難タスクをこなせることが示されています。

複雑なオーケストレーションより、ツール側（再利用できるスクリプト）を太らせるほうが効くことがある。

これは初学者にとって心強い知らせです。最初から豪華なマルチエージェントを組まなくても、確実に動く道具をていねいに積むだけで、十分に実用的なエージェントが作れるということだからです。

10まとめ：小さく作って、ツールを丁寧につなぐ

AIエージェント開発は、最初から万能秘書を目指すより、狭い業務に特化したエージェントを作り、ツール連携を堅くしていくのが近道です。MCPのような共通規格は、道具を増やしながらも運用を壊さないための強い味方になります。マルチエージェントは魅力的ですが、役割と終了条件を設計して「チームが機能する状態」にしてはじめて効きます。

次の一歩としては、社内FAQや定例レポート作成のような題材で、検索ツール＋起票ツールの2本立て、読み取り中心、人の承認つき——という最小構成から始めてみてください。小さくても「ちゃんと動く」体験ができれば、そこから一気に広がります。