AIエージェントの開発と運用において重要な役割を果たすAnthropicのMCP（Model Context Protocol）とGoogleのADK（Agent Development Kit）について、それぞれの役割の違いや連携方法を詳しく解説する動画である。これらは競合するものではなく、外部接続と内部構築という異なる課題を解決するために補完し合う関係であることを分かりやすく解き明かしている。
AIエージェント開発における2つの大きな課題
最近、AIエージェントやさまざまなプロトコルの話を本当によく耳にしますよね。
ですから、自分のAIエージェントにMCPを使うべきなのか、ADKを使うべきなのか、あるいは両方必要なのか、それともどちらも不要なのかと悩んでいるなら、それはあなただけではありません。
そうですね、それに、MCPとは何かを再び検索し始める前に、この動画を見れば一発で解決しますよ。
その通りです。
今回は、Model Context ProtocolとAgent Development Kitについて徹底的に解説していきます。
これらが実際に何を行うのか、どう違うのか、いくつかのユースケース、そして通常どのような場合にどちらを選ぶべきかをお話しします。
ネタバレをしてしまうと、これらは別に競合しているわけではないのですが、それについては後ほど詳しく説明しますね。
ちょっと待ってください、ネタバレは禁止ですよ。
すみません、すみません、ではさっそく細かく見ていきましょう。
まずは、私たちが今生きている現状から始めてみましょう。
というのも、単なるチャットボットではなく、実際にタスクを実行できるAIエージェントが、今まさに大きな注目を集めているからです。
ええ、本当にものすごい盛り上がりですよね。
その通りです。
そして開発者としてこれらを作り始めると、すぐに2つの大きな疑問にぶつかります。
まず1つ目は、自分のエージェントを外部のツールやデータとどのように通信させるか。
そして2つ目は、そのエージェントを実際にどのように構築し、オーケストレーション（統合管理）するか、という点です。
ええ、つまり全く異なる2つの問題ということですね。
そして、まさにそこで登場するのがMCPとADKなのです。
MCPによる外部接続の標準化
Anthropicが開発したオープン標準であるModel Context Protocol、略してMCPは、最初の疑問に答えてくれるものです。
これはすべて接続性に関するものです。
LLMに対して、APIやデータベース、ファイルなどへのアクセスを、クリーンで再利用可能な形でどのように提供するかという課題を解決します。
その通りです。
そして、Googleが提供するAgent Development Kit、つまりADKは、2つ目の疑問に関するものです。
エージェントを実際にどのように構築し、どのように構造化して実行するかという点に特化しています。
しかし、例えばエンジニアや開発者のチームのように、複数のエージェントを連携させて運用したい場合はどうでしょう。
これらすべてのエージェントをどのように構造化して、うまくオーケストレーションすればいいのでしょうか。
確かに、それは重要な疑問ですね。
私はこのように考えています。
MCPは、LLMエージェントが外部の世界とどのように会話するかという話です。
そしてADKは、エージェントそのものを構築するためのフレームワークです。
では、Model Context Protocolについてもう少し深く掘り下げてみましょう。
というのも、MCPが登場する前は、構築しているLLMやエージェントが、質問に答えるために必要なさまざまなリソースにアクセスさせたい場合、
例えば、Postgresなどのデータベースにアクセスしたり、最新の情報を探すためにウェブをスクレイピングしたり、あるいはディレクトリやファイルシステム上のファイルを読み込んだりする必要がありました。
そのたびに、毎回カスタムのインテグレーションコードを書かなければならなかったのです。
私がそのインテグレーションを書くかもしれませんし、他の誰かが書くかもしれません、そして別の組織も、これらの異なるソースからデータを取得するためだけに、みんな同じことをしていたのです。
ええ、カスタムの接着剤のようなコードですよね、これでは作業がちっとも進まないと思いませんか。
楽しい作業ですよね。
いいえ、全然違います。
ですが、MCPがしたことは、このインターフェースを標準化し、プロトコルを定義することでした。
つまり、AIエージェントやLLMのホストといったクライアントが、これらの異なるタイプのサーバーとどのように通信するかという一連のルールを定義したのです。
これによって、エージェントが質問に答えたりタスクを実行したりするために必要なツールやデータを、サーバー側が適切に公開できるようになります。
MCPの通信の仕組みと3つの要素
なるほど、ではMCPのホストとMCPのサーバーはどのように通信しているのですか。
何か独自の秘密の言語でもあるのでしょうか。
実は、そこまで秘密というわけでもないのです。
なぜなら、MCPが使用するメッセージ形式はJSON RPCだからです。
これは、実行されているホストエージェントやLLMと、MCPサーバーの間でやり取りされる、ほとんどプレーンテキストのようなものです。
ただし、実際のサーバーがどこで動作しているかによって異なります。
例えば、ローカルマシン上でMCPサーバーを実行している場合、
ファイルシステムにアクセスするIDEプラグインや、GitHubにアクセスするデスクトップアプリケーションのようなものです。
この場合は、標準入出力を使ってデータを双方向に処理・受け渡しします。
一方、リモートサーバーを使ってウェブ上でこれを行う場合は、
ストリーミング対応のHTTPを使用し、認証トークンなどを用いてホストとサーバーが確かに正しく双方向で通信していることを認証しながら情報を渡すことになります。
素晴らしいですね。
つまりMCPサーバーは、ツールの周りを囲む小さなラッパーのようなものですね。
一度書いてしまえば、MCPに対応しているどんなクライアントからでも利用できるようになります。
その通りです。
そして、MCPには主に3つの基本要素があります。
まず1つ目は、今お話ししていたようなツールです。
これらは、ウェブを検索する、あるいはこのSQLクエリを実行する、といったLLMが呼び出すことのできる関数です。
次に、リソースもあります。
リソースとは、LLMが読み取ることのできるもので、ファイルやドキュメント、内部および外部のデータベースなどがこれに該当します。
そして最後に、MCPにはプロンプトの機能も含まれています。
これは、事前に構築されたプロンプトのテンプレートをサーバー側に公開して利用できるようにするもので、毎回プロンプトを書き直す必要がなくなります。
モデルに依存しない再利用性とエコシステム
なるほど、ではアプリケーションの構築に使用しているモデルを切り替えたり、あるいは完全に新しいモデルを構築したりした場合はどうなるのですか。
それは素晴らしい質問ですね。
実は、それはまったく問題になりません。
なぜなら、これらのインテグレーションを毎回作り直しているわけではないので、同じMCPサーバーをそのまま再利用できるからです。
それこそがMCPが大きな時間短縮になる理由です。
データソースと通信するために、カスタムのインテグレーション構築に何時間も費やす必要はありません。
ただプラグインのように接続するだけで使えます。
いいですね。
ええ、そして開発者がMCPを本当に高く評価している理由は、モデルに依存しない、つまりモデルアグノスティックである点だと思います。
Claude、GPT、Gemini、あるいはローカルモデルなど、何を使っているかは関係ありません。
そのモデルがMCPを話すことができれば、そのまま動作します。
まさにその通りです。
そしてエコシステムは非常に急速に拡大しています。
実際に、皆さんが毎日使っているGitHubやSlack、Google Drive、データベースとしてのPostgres、Jira、Figmaなど、多くのリソースに対応したMCPサーバーがすでに存在しています。
コミュニティがこれらを構築しているため、リストは増え続けています。
ADKが提供するエージェントの構造化
さて、ツールが解決し、いくつかのMCPサーバーが稼働したところで、次は実際にエージェントを構築する必要があります。
そこで登場するのがADKです。
ADKは、AIエージェントを構築するためのオープンソースのPythonフレームワークであり、具体的には構造を提供してくれます。
なるほど、それはとても興味深いですね。
AIエージェントの構造を持つとは、具体的にどういう意味ですか。
根本的な部分として、ADKは実際のソフトウェアを構造化するのと同じように、エージェントを整理することを強制します。
内部的には、いくつかの主要なビルディングブロックを持っています。
それらは、エージェント、ツール、メモリ、イベント、そしてランナーです。
予測可能でテスト可能なシステムを構築するために必要な、すべての基本要素が揃っています。
それは素晴らしいですね。
では、実際の運用ではどのような形になるのでしょうか。
ええ、まずはエージェントそのものから見ていきましょう。
ADKにおいて、エージェントは単にプロンプトが与えられたLLMというわけではなく、定義された実行単位です。
つまり、モデルを持ち、一連の指示を持ち、使用を許可されたツールを持ち、そして制御された推論ループを持っています。
さらに、ADKはさまざまなタイプのエージェントを提供してくれます。
推論のための、より柔軟なLLM駆動型のエージェントもあれば、決定論的なワークフローエージェントもあります。
厳密な制御を行いたい場合には、シーケンシャル（順次）、パラレル（並列）、ループ（反復）といった形にできます。
そして、独自のカスタムエージェントを作成する柔軟性も備わっています。
それは本当に素晴らしいですね。
ADKを使えば、モデルに判断を任せる状況と、毎回これらのステップを正確に順番通りに実行する必要がある状況を、使い分けることができるわけですね。
まさにその通りです。
そして舞台裏では、ユーザーからのクエリをランナーが受け取り、それをエージェントに渡します。
エージェントが応答、つまりツールの呼び出し要求や報告すべき状態の変化を生成すると、一度処理を戻してランナーに渡します。
ランナーはエージェントによって生成された更新を処理し、それを上位に送ることができます。
予測可能な挙動と状態管理
めちゃくちゃかっこいいですね。
ということは、ランナーがこれらのツールを実行し、その変更をエージェントのセッション状態全体にコミットする、ということですよね。
ええ、まさにその通りです。
このループの中では、エージェントは処理を戻すたびに一時停止されるため、エージェントが次に何が起こるかを確認する前に、ランナーが結果を処理するための完全な制御権を持つことになります。
これこそが、その場しのぎのエージェントコードよりも、ADKを使った方がデバッグや挙動の追跡をはるかに容易にしている理由です。
それはよく分かります、納得です。
私は予測可能な挙動が好きですが、これまでのエージェントは必ずしもそれを提供してくれませんでしたからね。
ええ、だからこそADKは適切なセッション状態とメモリも提供してくれるのです。
状態（ステート）は短期的なものです。
これは、単一の会話内でのワーキングメモリです。
そしてメモリは長期的なもので、ユーザーの好みなど、セッションをまたいでエージェントが記憶している内容です。
外部のものに関しては、ADKを使用することで、エージェントがツールを使ってコードを実行したり、APIを呼び出したり、あるいは他のエージェントをツールとして使用したりすることができます。
最高ですね。
ADKは、このフレームワーク全体を提供してくれるわけですね。
構造、状態、オーケストレーション、デバッグ、すべてが揃っています。
ええ、かなり素晴らしいものです。
そして、それこそがADKの強みです。
ADKは単にLLMに何かをやらせるだけのものではありません。
信頼性の高いマルチエージェントアーキテクチャを構築するための、フルスタックなシステムなのです。
マルチエージェントシステムとMCPとの連携
そうですね、ADKは、ルートとなるオーケストレーターエージェントが専門化されたサブエージェントにサブタスクを委任するような、マルチエージェントシステムに最適だと聞いています。
つまり、1つの汎用的なエージェントを置く代わりに、調査エージェント、執筆エージェント、検証エージェントといった、それぞれのユースケースに専門化された異なる個別の役割を持たせて連携させることができ、ADKは最初からさまざまなタイプのエージェントをサポートしています。
ええ、その通りです。
先ほどお話ししたような、古典的な思考と行動のループであるLLMエージェントもありますが、ワークフローエージェントもあります。
これは順次、並列、およびループベースのエージェントです。
特定のステップを順番に実行する必要があることが事前に分かっている場合は、その構造をモデルの判断に委ねるのではなく、ハードコーディングすることができます。
これは信頼性を高める上で非常に大きなメリットです。
必ずしも必要ではないLLMの意思決定を減らし、問題を解決して必要な処理を行うためのカスタムワークフローを構築する能力を高めることができます。
ええ、まさにその通りです。
そしてADKは複数のモデルバックエンドをサポートしているため、特定のモデルにロックインされることもありません。
さらに素晴らしいのは、ADKがインテグレーションレイヤーにおいて、ツールのフレームワークに依存しないという点です。
つまりどういうことかというと。
そう、MCPサーバーとも連携できるということです。
任意のMCPサーバーを、ADKエージェントのツールソースとしてプラグインのように組み込むことができます。
実際のシナリオにおける役割分担
では、これをより具体的にするために、MCPかADKのどちらを使うべきか、実際のシナリオで考えてみましょう。
状況による、というのが正解だとは思いますが、それだと動画としてはつまらないですよね。
確かにそうですね。
では、自分のリポジトリを検索し、ファイルを開き、テストを実行し、発生した問題のデバッグを支援してくれる、自分専用のコーディングアシスタントを構築したとしましょう。
最初の質問ですが、エージェントのロジック、つまりメモリ、ツールの使用、推論、そして必然的に状況を悪化させてしまったときの再試行などを、実際にどのように構築しますか。
ええ、そこはADKの領域ですね。
エージェントの挙動がどうあるべきか、例えばどのようにリポジトリを検索するか、いつテストを実行するか、そして避けられない失敗にどう反応すべきかを定義することになります。
同意します、そしてADKはエージェントの認知部分を構造化するのに役立ちます。
これには、計画、ツールのオーケストレーション、そしてデバッグの過程で誤って本番環境のデータベースを削除してしまわないようにするためのガードレールなどが含まれます。
ええ、それは本当に悪夢のような話ですね。
本当にそうですよ。
しかし、今度はそのアシスタントが、そのリポジトリ、テストランナー、そして課題トラッカーへの標準化されたアクセスを必要としているとしましょう。
そこがMCPの出番です。
MCPは、モデルやエージェントがそれらの外部ツールと一貫した方法で通信できるように、標準化を支援してくれます。
それがプロトコルレイヤーの役割です。
なるほど、いいですね。
つまり、ADKはエージェントが何をすべきかを定義し、MCPはエージェントが外部の世界と通信しながら、それらを実際にどのように行うかを定義するわけですね。
異なるレイヤーですが、お互いを補完し合う役割を持っています。
ライバル同士ではないのですね。
ええ、動画のタイトルの中だけの話です。
まあ、アルゴリズムが少し対立の構図を求めていたということで、理解してください。
では、まとめとして、AIエージェントを構築していると、MCPとADKの両方について耳にすることが多くなるでしょう。
その名前に惑わされないでください。
いいですね。
なぜなら、MCPは接続性の問題を解決し、ADKはオーケストレーションの問題を解決するからです。
これらは補完的なものであり、競合相手ではありません。
ええ、そして本当の問いは、どちらを使うべきかではなく、自分が今どんな問題を解決しようとしているのか、ということです。
この動画が、必要な背景知識を提供するものになっていれば幸いです。
上手いこと言いましたね。
狙いは分かりましたよ。
ベタですが、今回だけは許しましょう。
気に入ってくれましたか。
もしもっと聞きたいのであれば、まだまだ引き出しはありますよ。
では、それは次の動画のために取っておくというのはどうでしょう。
分かりました、頑張ってみたのですが。
挑戦は認めます、ですが、もし皆さんがADK、MCP、あるいはその両方を使っているなら、ぜひ下のコメント欄で教えてください。
そして、この動画がこれら2つの概念をようやく理解する手助けになったなら、ぜひ高評価ボタンを押し、このようなコンテンツをもっと見逃さないためにチャンネル登録をお願いします。
コメント