00:00:00AIにおける最も重要な要素の一つであったMCPプロトコルですが、
00:00:036ヶ月後には私たちにとって大きな問題となってしまいました。
00:00:06当初、人々はローカルで2、3台のMCPサーバーを動かす程度でしたが、MCPはそれ以上に大きく進化しました。
00:00:13今や文字通り何百ものMCPサーバーを何千ものツールと共に同時に動かしており、それが大きな問題となっています。
00:00:20ご存知の通り、Cloudflareが最初にこの問題に気づき、Claudeもこれに関する研究論文を発表して追随しました。
00:00:26しかしDockerはこれに対する解決策を考案し、
00:00:29MCPの全く新しい利用方法を提案することで、
00:00:31MCPの最も重要な問題の一つを解決しました。
00:00:34それはダイナミックモードで、
00:00:36これにより多くのトークンを節約し、
00:00:38エージェントを高速化し、
00:00:39私個人としても非常に楽しみにしている全く新しい種類の自動化を実現できます。
00:00:43Dockerはこれに関する記事を公開し、
00:00:45その中でエージェントの環境をハードコーディングするのをやめるよう、
00:00:48基本的に私たちに促しています。
00:00:50では、それはどういう意味でしょうか？
00:00:51まず第一に、どのMCPサーバーを実際に信頼すればいいのか？
00:00:542つ目は、もしかしたら使わないかもしれないツール定義でコンテキストを埋め尽くすのをどう避けるかです。
00:01:00例えば、1000個のツールを持っていたとしても、1回のチャットで使うのは2、3個だけかもしれません。
00:01:053つ目は、エージェントがこれらのツールを効率的かつ自律的に発見し、設定し、使用するにはどうすればいいか？
00:01:12しかし、
00:01:12私が皆さんに注目してほしいのは2つ目の点、
00:01:14つまり、
00:01:14もしかしたら使わないかもしれないツール定義でコンテキストを埋め尽くすのをどう避けるか、
00:01:18という問題です。
00:01:19例えば、1000個のツールを持っていたとしても、1回のチャットで使うのは2、3個だけかもしれません。
00:01:23Anthropicもこれに関する記事を公開しており、
00:01:27以前の動画で取り上げたところ、
00:01:28実装を望む人々から非常に良い反応をいただきました。
00:01:32そしてDockerは実際にこれを実装しました。
00:01:34さらに進む前に知っておいてほしいのは、
00:01:36Dockerがこのためのインフラ全体を、
00:01:38それが問題になるずっと前から構築していたということです。
00:01:41そのためには、
00:01:42彼らのMCPカタログについて知る必要があります。そこには、
00:01:45実際に信頼できる検証済みのMCPサーバーがリストされています。
00:01:48接続は非常に簡単で、Dockerでここに接続するだけです。
00:01:52例えば、
00:01:52私はここにNotionを接続しました。今、
00:01:552つのサーバーがあるのがわかりますね。私のMCPクライアント（ほとんどの場合Claudeコード）はDockerにのみ接続し、
00:02:01Dockerが私のすべてのMCPサーバーを基本的に管理します。
00:02:04これにより、どのMCPサーバーを実際に信頼すればいいのかという最初の問題が完全に解決されます。
00:02:09さて、
00:02:10エージェントがこれらのMCPを動的に使用できるようにするため、
00:02:14彼らはMCPゲートウェイを実装しました。これには、
00:02:17カタログ内のMCPサーバーを自律的に利用するための組み込みツールがすでに備わっています。
00:02:22したがって、
00:02:23基本的に何が起こるかというと、
00:02:251つのMCPだけを接続すれば、
00:02:26このMCPがカタログ内でどのツールに接続されているかのすべてのコンテキストを持つことになります。
00:02:31私は2つに接続していますが、
00:02:32どのツール定義を実際にコンテキストウィンドウに持ってくるべきかを知っています。そのため、
00:02:36コンテキストウィンドウが肥大化することはありません。
00:02:39これを実際に機能させるために、
00:02:40彼らはMCP find、
00:02:41add、
00:02:42removeといった新しいツールを追加しました。これらは基本的に、
00:02:45カタログ内のMCPサーバーを名前や説明で検索するものです。
00:02:48そして、それらを正しく追加する方法を皆さんにご案内します。
00:02:51例えば、私はここでGitHub MCPを使っています。そして、興味深いリポジトリを検索したいと伝えています。
00:02:57どのようなリポジトリかを指定した後、
00:02:59ツール自体を直接呼び出すのではなく、
00:03:02Docker MCPサーバーを使用します。そしてDocker MCPサーバーが正しい情報でツールを呼び出し、
00:03:08当然すべての結果を返します。ここで一つ注目してほしいのですが、
00:03:12LLMはリポジトリに関するすべてを返しています。リンク、
00:03:16スター数、
00:03:16説明、
00:03:17さらにはこれらのリポジトリが投稿された日付まで知っています。
00:03:21これは今後重要なことになりますので、覚えておいてください。
00:03:25さて、
00:03:26ダイナミックツール選択に移りましょう。これがこの記事の最も重要な部分であり、
00:03:30MCPサーバーの新しい使い方について話したときに言及していたのはこのことです。
00:03:35Claudeの記事を再び参照すると、
00:03:37Claudeや他のAIエージェントがどのようにしてより多くのトークンを使用するかについて述べられています。一つはコンテキストウィンドウ内のツール定義、
00:03:45もう一つは中間ツール結果です。これは、
00:03:47MCPツール呼び出しから実際に返される生のデータについて話しています。GitHubツールを使って検索したこれらすべての詳細がコンテキストウィンドウに返されました。そのため、
00:03:57Claudeはリポジトリのあらゆる詳細を知っている一方で、
00:04:00私はリポジトリの説明とリンクだけを求めていました。このようにして、
00:04:04私の場合は、
00:04:04コンテキストウィンドウ全体が実際に埋まるまでに、
00:04:07わずか数回のツール呼び出し、
00:04:09おそらく20回程度のツール呼び出ししかかかりませんでした。これは、
00:04:12MCPゲートウェイプロジェクトで改善された点の一つで、
00:04:15実際に役立つツールのみを提供します。例えば、
00:04:18私の場合、
00:04:19コンテキストを節約する一つの方法は、
00:04:21このGitHub MCPに含まれる他の40個のツールではなく、
00:04:24検索リポジトリツールだけを提供することです。なぜなら、
00:04:27このセッションでは検索リポジトリツールだけを使いたいからです。しかし、
00:04:31このようにツールを選択し始めると、
00:04:33新たな可能性も開かれます。そして、
00:04:35それがコードモードへとつながります。Cloudflareは基本的に、
00:04:39私たちがMCPを間違った方法で使っていたこと、
00:04:41そしてそれが本来の方法ではないことを概説しました。そして、
00:04:44Dockerがこの新しいソリューションを最初に実装したのです。私はこれをたくさん試してみましたが、
00:04:50その実行結果には本当に驚かされました。彼らは、
00:04:53エージェントがMCPツールを使って直接コーディングできるようにすることで、
00:04:57つまりツールを取り込んでコードとして実装することで、
00:05:00ツールを全く新しい方法で使うことができるコードモードツールをエージェントに提供できると述べています。では、
00:05:06コードモードは何をするのでしょうか？それは、
00:05:08他のMCPツールを呼び出すことができるJavaScript対応ツールを作成します。これは非常にシンプルに見えるかもしれませんが、
00:05:15これからお見せする例で、
00:05:17この点が明確になることを願っています。さて、
00:05:19実装に入る前に、
00:05:20他にも考慮すべき点があります。まず、
00:05:22これはエージェントによって書かれたコードなので、
00:05:25当然テストされておらず、
00:05:26安全ではありません。そのため、
00:05:28Dockerはこれをサンドボックスで実行することを計画しています。そして、
00:05:32彼らはすでにDockerコンテナを提供しているので、
00:05:35これは彼らにとって非常に簡単なことでした。このアプローチは3つの主要な利点をもたらします。まず第一に、
00:05:40完全に安全であることです。それがサンドボックス化の主な利点だからです。システムに実際の損害を与えることはありません。次に、
00:05:47私たちが話してきたトークンとツールの効率性があります。使用するツールはリクエストごとにモデルに送信する必要がなく、
00:05:54モデルは新しいコードモードツールを一つ知っているだけで済みます。コードモードがない場合、
00:05:59例えば3つのツールだけを使用し、
00:06:00それを繰り返し実行していると、
00:06:02実際に使用している3つのツールと一緒に、
00:06:04他の47個のツールのコンテキストも送信されます。しかし、
00:06:07コードモードでは、
00:06:08エージェントは実際に使用する必要があるツールだけを使って、
00:06:12カスタムの「analyze my repos」ツールを作成します。そして、
00:06:16毎回その一つのコードモードツールを参照するだけです。このようにして、
00:06:20実際に使用する必要のないツールを送信しないことで、
00:06:22他のすべてのコンテキストを節約します。そして、
00:06:25状態の永続性もあります。これは、
00:06:27これらのツール呼び出し間でデータがどのように保存されるかをボリュームが管理するものです。そして、
00:06:32それらは実際にモデルに送信されません。これの非常に簡単な例は、
00:06:36データ処理パイプラインです。データセットをダウンロードしたいとしましょう。データセットはダウンロードされて返されますが、
00:06:42実際にはボリュームに保存され、
00:06:44モデルはダウンロードが成功したことだけを知ります。モデルが5ギガバイトのデータで溢れることはありません。次に、
00:06:50最初の10,
00:06:51000行を処理したい場合、
00:06:53モデルはデータが保存されているボリュームから読み取り、
00:06:56実際の要約を返すことができます。このようにして、
00:06:58最終結果、
00:06:59要約、
00:06:59エラーメッセージ、
00:07:00質問への回答など、
00:07:01モデルに送られるべきデータのみがモデルに転送され、
00:07:04コンテキストウィンドウはクリーンな状態を保ちます。
00:07:07さて、
00:07:08私がこれらのGitHubリポジトリを検索していた理由は、
00:07:10自分の動画で紹介できる新しいオープンソースツールを発見するためです。普段は、
00:07:14find GitHub repoツールを使って複数の呼び出しを実行し、
00:07:17ツールを検索するために異なるキーワードを入力するだけです。そこで、
00:07:20これをClaudeコードに提示したところ、
00:07:22私が与えるキーワードに基づいてリポジトリを検索する単一のツールに、
00:07:25それらすべての異なるツール呼び出しを結合してくれました。コードモードなしでも、
00:07:29Dockerが実際に複数のクエリを実行しているのがわかります。そして、
00:07:32それが私が修正したかった点です。作成されたツールは「multi search repos」と呼ばれていました。
00:07:37ツールを作成した後、
00:07:38MCP execツールを使って実際に実行しました。6つの異なるキーワードで検索することで、
00:07:44基本的に29個のユニークなリポジトリを教えてくれましたが、
00:07:47結果は応答とターミナルに直接返され、
00:07:49すべての結果がコンテキストウィンドウ内に返されていることを意味していました。これを修正するために、
00:07:54すべてをファイルに書き込み、
00:07:56モデルはリポジトリの説明だけを取得するように伝えました。スター数やその他の情報は不要です。すると、
00:08:02ツールが変更され、
00:08:03それらの結果すべてが私のリポジトリ内のテキストファイルに書き込まれました。これにより、
00:08:08特定のリポジトリについて何か調べたい場合、
00:08:10そのテキストファイルを参照することでできるようになりました。今、
00:08:14私が実装してほしいことが一つあります。それは、
00:08:16このツールを保存して再利用する方法です。現状では、
00:08:19手動でファイルとして保存するしかありません。その後、
00:08:22Notion MCPを検索するように依頼しました。接続後、
00:08:25テキストファイルを使う代わりに、
00:08:27GitHubの検索結果を直接Notionに出力するツールを作成できるか尋ねました。そして、
00:08:32再びコードモードを使って、
00:08:34実際に結果をNotionに貼り付けることができる「GitHub to Notion」ツールを作成してくれました。
00:08:40それを実行した後、
00:08:41基本的にいくつかの小さな問題を修正する必要がありました。しかし、
00:08:45本質的には、
00:08:45今ではNotionにこのデータベースがあります。基本的にハードコードされているので、
00:08:50私がどんなクエリを提供しても、
00:08:51それはこのデータベースに異なるフィールドに従って結果を入力してくれます。
00:08:55そして日付も含まれるので、
00:08:56簡単にフィルタリングして、
00:08:58実際に欲しい結果だけを検索できます。モデルは一度に取得するGitHubリポジトリの名前と説明だけを知ります。それ以外の情報は何も取得しませんが、
00:09:06残りの情報はすべてここに保存されます。正直なところ、
00:09:08このカタログをざっと見るだけでも、
00:09:10これらの素晴らしいワークフローを作成するために連携できるMCPのアイデアが少なくとも一つは得られるでしょう。同時に、
00:09:17トークンを節約し、
00:09:18自身のAIエージェントのパフォーマンスを維持できます。これらを始めるのは正直かなり簡単です。Dockerのバージョンを更新する必要があります。しかし、
00:09:26まだ持っていない場合は、
00:09:27ベータ機能で無効になっている可能性があります。そのため、
00:09:30このDocker MCPツールキットが有効になっていることを確認してください。
00:09:34それ以外では、
00:09:35カタログがあり、
00:09:36これらの新機能はデフォルトで有効になっています。ですから、
00:09:39クライアントを接続するだけで、
00:09:41すぐに使い始めることができます。これでこの動画は終わりです。チャンネルをサポートし、
00:09:45このような動画を制作し続けるのを手伝っていただけるなら、
00:09:49下のスーパーサンクスボタンをご利用ください。いつもご視聴ありがとうございます。また次回の動画でお会いしましょう。