この動画は、ZedのAentic Engineeringシリーズの第2回として、フルタイム講師のKent C. DodsがModel Context Protocol（MCP）について詳しく解説する内容である。MCPは、AI応用が様々なサービスと統合するための標準的な通信プロトコルであり、まさに映画アイアンマンのJarvisのようなAIアシスタントを実現する技術として注目されている。Kent氏は、現在のAIアシスタント（Siri、Alexa等）が抱える統合の課題を解決し、真のユニバーサルAIアシスタントを構築するためのMCPの重要性を、実際のデモンストレーションを交えながら説明している。
MCPの基礎とJarvisの実現
皆さん、ようこそ。これはZedのAentic Engineeringシリーズの第2回です。私は素晴らしいKent C. Dodsと一緒にお送りします。Kentさん、自己紹介をしていただけますか。
はい、皆さんこんにちは。ここにいられることを本当に嬉しく思います。お招きいただき、ありがとうございます。私はフルタイムの講師で、自分が興味を持っていることを人々に教えています。現在は特にAI、具体的にはMCPに焦点を当てています。私はユタ州に住んでおり、ここでの生活を愛しています。
素晴らしいですね。あなたがMCPとは何かについて、私たちが共通の理解レベルを持てるような予備的な資料をお持ちだと理解しています。その後、もう少し詳しく話し合い、フォローアップの質問をしたり、聴衆からの質問を受けたりできればと思います。
はい、それは良いアイデアですね。それでは画面を共有して、始めましょう。
画面が見えていると思いますので、これを簡単に説明していきます。これらのスライドに基づいた本格的な完全版の講演がありますので、後でご覧いただけますが、今回は簡潔に進めていきます。実際、どのくらい時間がありましたっけ。
全体で45分から1時間程度で、Q&Aなども含めてですね。
はい、では実際にこれらのスライドの適切なバージョンをお見せして、デモなども含めて行えますね。
私は人々が次の段階のユーザーインタラクションのためのソフトウェア開発を始めるのを支援したいと思っています。特に、この講演のタイトルは「MCPを使ってAIがあなたのアプリとインターフェースできるようにする」ですが、少し長いタイトルだと思うので、基本的にはJarvisに物事を実行させるということです。
Jarvisとは何か
では、Jarvisとは何でしょうか。これがその疑問です。この動画をただ見るつもりはありませんが、アイアンマンを見たことがあれば、Jarvisはトニー・スタークが使用するアシスタントで、彼が何をしていても支援してくれることを知っているでしょう。このシーンでは、彼は犯罪現場を評価し、原因を突き止めようとしており、Jarvisは本当にクールなホログラフィック映像などを作成して、トニーがその中を歩き回り、ジェスチャーや音声で体験できるようにしています。そこで多くのことが起こっており、明らかにAIが中核的な要素として、さまざまなエリアからのデータセットを取得し、興味深い方法でまとめて、トニーが異なる方法でそれを見ることができるようにしています。正直なところ、それはそれほど遠い話ではありません。
このクリップでJarvisが行っていることを挙げてみましょう。この1分間のクリップだけで、彼は異なるデータセットからデータベースをコンパイルしています。FBIやCIAのデータセットからコンパイルすることは望ましくないかもしれませんが、技術的な理由ではなく法的な理由でしょう。またShieldは、うまくいけば架空の機関ですが、実在しないことを願います。実在することを望むのかもしれませんが、わかりません。
オンデマンドでUIを生成し、ホログラムはできないかもしれませんが、確実にオンデマンドでUIを生成でき、それはますます向上しています。記録にアクセスし、それらを関連付け、さらには飛行計画を作成することも行っています。これは常にエージェントの典型的な例として挙げられます。「ああ、この場所への飛行機を予約します」というものです。正直なところ、これは少し使い古された例だと思います。私たちは皆、その例に飽きていますが、彼は実際にそのクリップでそれを行っています。
Jarvisは多くのことができますが、私の疑問は、このクリップでJarvisが行ったことで、私たちにできないことは何かということです。Jarvisが行うことで、私たちができないことは何でしょうか。
私は、かなり強い但し書き付きで何もないと言えると思います。先ほど言ったように、ホログラフィックUIはおそらくできませんし、FBIのデータセットにアクセスすべきではないでしょうが、Jarvisがトニー・スタークのために行うことのほとんどすべてを、私たちは技術的に行うことができます。
なぜ私たちは皆Jarvisを持っていないのか
では、私の疑問は、なぜ私たちは皆、自分のJarvisをまだ持っていないのかということです。なぜ私は話しかけるデバイスを持つことができないのでしょうか。そのデバイス、またはその音声は私と一緒に移動し、使用しているデバイスに関係なく、その能力は私と共にあります。車の中、家の中、コンピューター上、電話上、そして恐らく私の目に、つまり眼鏡の中にもあります。アイアンマンスーツは持っていないかもしれませんが、それは私たちとどこにでもあり、私たちの周りで起こっているすべてのコンテキストを持っています。
技術があるなら、なぜそれを持っていないのでしょうか。実際、私たちは長い間それを実現しようとしてきました。私は集合的な「私たち」と言っていますが、実際に私自身がこれを試みたことはありませんが、Home AssistantやSiri、Bixby、Alexaなど、さまざまなものがあり、私たちはすべてのことを実行できるこのアシスタントを構築しようとしてきました。
既存のアシスタントが失敗した理由
では、なぜこれらは失敗したのでしょうか。Siriについてその質問に答えられたらと思います。Siriがなぜそんなにひどいのか理解したいと思います。信じられないほど悪いです。
本当の気持ちを教えてください。実際に驚いているのは、Siriと数回言ったのに、私の電話がまだ反応していないことです。通常は反応するのですが。実際、Androidを持っていた時は、「OK Cool」のような設定でこんな風に言うと、「OK Cool、次に進みましょう」と言って、私の電話は常にOK Googleと言っていると思っていました。
つまり、技術のその側面についてはまだ少し進歩の余地があるようですが、これは必ずしも技術的な制限ではありません。Jarvisから私たちを実際に妨げているのは統合です。私たちが想像できるあらゆることは、統合を構築するのが本当に困難です。
確かに、カレンダーとの統合を構築することはできます。大きなカレンダープロバイダーの1つを使用している場合は、メールとの統合を構築できます。大きなメールプロバイダーの1つを使用している場合は、これらすべては非常に限定的で、これらの統合から本当に有用なものを得るには、これらの大きな集中型サービスの1つを使用している必要があります。
その理由は、使用している可能性のあるすべてのサービスに対して統合を構築する能力がないからです。使用しているサービスの中には、小さな地元の会社のようなものもあるかもしれません。あなたの市の自治体もあるかもしれません。あなたの市のウェブサイトがあり、子どもの誕生日パーティーのために公園のパビリオンを予約できます。Googleがそのための統合を書くと思いますか。いいえ。
標準化の欠如という問題
代わりに彼らが行うのは、「わかりました、私たちのものと独自の統合を作る方法を提供します」と言うことです。では、私の市の開発者（おそらく一人で、パートタイムでしか開発しない人）がApple、Google、Amazon、Microsoftとの統合を構築することを期待するのでしょうか。いいえ、彼らはそれをしません。彼らは「ウェブサイトを使ってください。他にやることがあります」と言うでしょう。
これらの統合に関する標準化の欠如は両側で大きな問題です。Googleは世界のすべての可能な統合を構築することはできませんし、それらの個人もすべての他の部分との統合を構築することはできません。その上、私は毎日子どもの誕生日のためにパビリオンのような場所を予約するわけではないので、その統合を構築したり、とにかく自分でそれを配線したりする時間を取ることはありません。
また、これらの機能の動的な発見可能性もあり、それは残念です。私はこれらすべてのものと動的に統合できるAIロボットを持ちたいと思います。チーム同士が話し合う必要なく、私たちには通信の標準が必要です。
Model Context Protocolの登場
それがModel Context Protocolです。Model Context Protocolは、クライアントが仕様のクライアント側を実装し、サーバーが仕様のサーバー側を実装すれば、これらのAIアプリケーションがこれらのサービスと統合できると述べています。これで私たちは話すことができ、これはウェブサイトが機能する方法と非常に似ています。
ウェブブラウザのように、ブラウザであるクライアントがあり、HTMLで応答するHTTPサーバーであるサーバーがあります。Google Chromeチームは、それを機能させるためにBob’s Chocolate Factoryチームと話す必要はありません。Bob’s Chocolate Factoryチームは仕様に準拠したHTMLを提供するサーバーを作り、ChromeはそのHTMLを解析してリクエストを行い、すべてが機能します。彼らは互いに通信する必要はありません。
これがMCPがAIエージェントに対して行うことであり、私がこれに興奮している理由です。これで、これらすべてのサービスを接続し、「ロンドンへの旅行を作りたい」のような複雑なプロンプトを持つことができる実際のJarvisを作る能力があることを意味します。
Deltaと話して私のフライトをスケジュールし、London Undergroundと話して地下鉄に乗るためのチケットを入手し、学校関連のことなのでCanvasに行き、「ああ、そうだ、旅行することをクレジットカードに伝えて、彼らがそれに備えられるようにする必要がある」など、単一のユースケースを取って、これらすべての異なるサービスを使用できます。通常、私はこれらすべてのサービスのウェブサイトに行く必要がありますが、今は私のエージェントにそれを行わせることができます。
多くの人は「エージェントにブラウザを使わせればいいじゃないか。ウェブサイトは既に存在するのだから」と言うでしょう。確かにそれはできますし、しばらくの間はそのようになると思いますが、それを行うのは非常に非効率的です。このテキストプロトコルを介してコミュニケーションする方がはるかに高速です。
「Open API仕様などのREST APIのリストを教えてください」と言うかもしれませんが、それは本当に悪いアイデアでしょう。LLMを使ったことがあれば、それらがいかに非決定論的であるかを知っているでしょう。代わりに、私たちは効果的にエージェント用のウェブサイトまたはユーザーエクスペリエンスを作り、それがModel Context Protocolが可能にすることです。
MCPの歴史と発展
物事の歴史を少し詳しく見てみましょう。数年前にChatGPTが登場し、それはLLMの最初の非常に人気のあるホストアプリケーションでした。私たちは長い間LLMを持っていました。オタクな人々は何年も何年もLLMに質問をして応答を得て、テキストを生成させることができていました。しかし、これは任意のテキストを与えることができ、トークンを生成し、あなたの質問に答えることができるかのような一般的なアプリケーションを初めて持った時でした。常に正しいとは限りませんでしたが、非常にクールでした。
問題は、それが何もできなかったことです。実際に仕事を完了させる必要がある場合、すべてのコンテキストをツールに持ち込んで、「これが私のコードベースです」や「これが私が以前に書いたエッセイの例です。このような箇条書きで新しいものを書いてください」などと言う必要がありました。そして、必要なことを実行するためにコンテキストを取り出す必要がありました。
そして、ホストアプリケーションがツールを作成し、それと統合し始めるフェーズ2に入ります。ホストアプリケーションとLLMの間には何らかの特注プロトコルがあります。LLMは単にトークンを生成しているだけですが、ホストは「追加のコンテキストが必要な場合は教えてください。Googleを検索して答えを探し、より多くのコンテキストを提供します」と言います。そこでこれらのツールを構築しますが、ここでも同じ問題に直面しています。確かに何かはできますが、これらの統合には時間がかかりすぎるため、十分なことはできません。
ChatGPTは「わかりました、カスタムGPTのようなものを作り、人々がこれらのカスタムGPTを構築できるようにします」と言いました。しかし、それも同じ問題で、囲い込みガーデンです。私の市は公園でパビリオンを予約できるようにカスタムGPTを構築するつもりはありません。
では、人々がこれらのLLMをラップして、自分のアプリケーション用の小さなチャットボットを作ったらどうでしょうか。私のアプリケーションにはRAGなどがあるので、実際にこのチャットボットをアプリケーションで活用できます。それも良いのですが、それはあなたのアプリケーションのコンテキストでのみ有用です。
ユーザーとして、私はまだこれらのチャットボットのそれぞれに行き、最後のチャットボットからのコンテキストでそれをロードし、物事を与えて、そのコンテキストを次のものに持っていく必要があります。私はそれをしたくありません。私が話しかける単一のJarvisが欲しいです。それは私が知る必要があることすべてを知っており、「行け」と言うと、すべてと統合できます。
フェーズ3：標準の確立
私たちは十分なことができず、標準が必要です。それがフェーズ3でした。11月にAnthropicが現れて、「私たちの大規模言語モデルにコンテキストを提供する機能があります。これをオープンソースにし、良いガバナンスモデルを持ちます。現在、それを定義中であり、より広いコミュニティからの貢献を受け入れ、誰でも使用でき、誰でも構築できるオープンスタンダードにします」と言いました。
それ以来、非常に多くの人々、非常に多くの企業がこれを採用しています。クライアントはまだすべて準備ができているわけではありませんが、時間の経過とともにますます準備が整ってきています。私は3月末に参加し、その後の数週間で、Microsoftがオペレーティングシステムでのネイティブサポートを発表しました。これは本当に驚異的です。GoogleがChatGPTサポートを発表し、Amazonが仕様に多大な貢献をし、MicrosoftはVS Codeのサポートを含めて仕様への多大な貢献を行い、ZedはMCPをサポートし、誰もがMCPに夢中になっています。本当に素晴らしく、非常にエキサイティングです。
その理由は、これが誰でも書くことができるオープンスタンダードだからです。そこにはギャップがあるかもしれませんが、基盤には亀裂や問題はありません。だから私たちはこの上に構築して、本当に素晴らしい体験を作ることができ、Jarvisを構築することができます。
MCPのアーキテクチャ
アーキテクチャをもう少し深く見てみましょう。MCPはクライアントとサーバーで構成されています。ホストアプリケーションは、通信する必要がある各サーバーに対してクライアントを起動し、サービスプロバイダー側にあるサーバーは、さまざまなツールの呼び出しなどを管理します。ホストアプリケーションは「LLMさん、こういうことをする必要がある場合、実際にそのアクションを実行できます」と言い、MCPプロトコルを通じてそれを行います。これが基本的なアイデアです。
実際のデモンストレーション
実際にそれがどのようなものかの小さな例をお見せしましょう。これは4月の時点のもので、それ以来さらに良くなっており、一貫して改善され続けています。今は本当にエキサイティングな時期です。
ここで私はロンドンにいて、このデモを作りたかったので、「娘との旅行について日記エントリを書いてください。デバイスから私の位置と天気を取得し、創造的なストーリーを作ってください」と言いました。通常、日記エントリを書く場合は自分で書くでしょうが、LLMにやらせてみましょう。
ここで最初に「わかりました、あなたの位置を取得する必要があります」と決定し、私のデバイスの位置を取得するためにこのツールを使用することを承認するかどうかを尋ねています。私は自分のデバイスを使用して現在のデバイスの現在位置を決定するlocationator MCPサーバーを作成しました。これは既にインストールされており、LLMはこれが呼び出すことができるツールであることを知っており、このモーダルを使用すべきだと判断しました。
このモーダルは、このエージェントのヒューマン・イン・ザ・ループと呼ばれるものです。今のところ、特に少し戻りますが、トニーがJarvisと話しているのを見ると、Jarvisは通常、特定のことを行っても良いかどうかトニーに尋ねていません。彼はただそれを行います。「このミサイルを発射しますか」と言う例もあるかもしれませんが、一般的には…
そうですね、リチャード、すみません。つまり、FBIデータベースで物事を調べることに許可は必要ないですよね。
はい、確かに。しかし実際のところ、これらのAIアシスタントは時間の経過とともに私たちの好みを学習でき、「ああ、あなたはこのツールを使用することを好む。あなたは以前にこれを行ったことがある。これで問題ない」と理解できます。彼らは私たちが誰であるかなどをすべて学習できますが、現在はそこまで至っていません。そのため、何かを行う際は毎回許可を求めてくるでしょう。私はそれで良いと思いますし、実際に「このチャットで許可」と言えば、一般的にもそれを使い続けるでしょう。
これのユーザーエクスペリエンスは、大幅な改善が必要な分野の1つですが、特に現在、これに対する信頼度が低い状況では、これらを承認し、ヒューマン・イン・ザ・ループを持つことは本当に良いことだと思います。
ここで私は「はい、先に進んで、私の位置を取得することを許可します」と言います。私は文字通りあなたに私の位置を取得するよう求めたのですから、そうしてください。これは私の自宅住所ではありません。これがライブではなくビデオをお見せする理由の一部です。これは実際に私が今年初めにロンドンにいた時のもので、私のホテルです。私がロンドンにいた時にどこにいたかを正確に見つけることができます。
そこから「わかりました、現在の場所で天気を知りたいと思うので、現在の場所での天気を取得する別のサービスに行きます」と言います。AIアシスタントを、あなたが雇った人間のアシスタントのように考えたいと思います。人間のアシスタントに同じプロンプトを与えると、彼らはその場所の天気を知る必要があるので、現在の位置を教えてくれるサービスに行くでしょう。現在の位置を知っているかもしれませんが、その位置での天気を知る必要があるので、サービスに行って現在の位置を取得するように想像してください。
素晴らしいです。今、そのサービスから得た情報を取って、この他のサービスに入力するつもりです。それは非常にクールで、その能力があることです。これは私の現在の位置で天気を取得する完全に異なるサーバーです。これは私がCloudflareでホストしていたサーバーで、基本的にAccu Weatherのプロキシです。経度緯度を取り、現在の天気を決定します。
今、クライアント、またはむしろアプリケーション、Claudeは私がどこにいるかを知り、そこで起こっている天気を知っています。そして「わかりました、あなたは日記エントリを書きたいと言い、私たちはepic miサーバーでそれを行う能力があります」と言うでしょう。
epic miサーバーは私が作成したもので、基本的にMCPを通じてのみアクセス可能なアプリケーションです。認証、認可、登録など、すべてがMCPサーバーを通じて行われます。ここで私のメールアドレスで認証を行い、「はい、私たちはあなたのメールにトークンを送信しました」と言います。
当時は私はこれをローカルで実行していたので、コンソールにログアウトしただけで、そのトークンを取得して提供します。実際、近い将来、メール用のMCPサーバーがあることを予想しているので、自動的にチェックしてくれるでしょう。メールを開いたり、そのトークンを取得したりする必要はありません。「ああ、そのメールを受け取りました。これをここに入れさせてください」のようになるでしょう。
トークンを検証し、これは実際に仕様に組み込まれており、認証機能があり、OAuthを使用してクライアントが確認され、使用しているクライアントがあなたに結び付けられており、あなたが誰であるかを知っています。したがって、データを関連付けることができ、この場合は日記エントリを作成してデータベースに保存できます。
日記エントリを作成し、「タグを追加したいと言っているので、データベースで利用可能なタグを見てみましょう」と言います。そして、いくつかのタグを作成し、それらを日記エントリに適用します。これはすべて非常にクールで、そして私は「このエントリを見せてもらえますか」と言います。
これを見せたかった理由は、確かにget entryツールからそれを取得できますが、ここでの応答を見てください。将来的には、エンドユーザーに応答を見せることは実際には必要ないと思います。それは必要ではないと思いますが、現在は信頼が低く、まだ物事を理解しようとしているところなので有用ですが、ここでの応答はタイトル、コンテンツを含むJSONの塊で、私のLLMはそれを次のトークンを生成するためのコンテキストとして使用します。
おそらくそれらのトークンは、日記エントリを見せてほしいと言ったので、日記エントリが言っていることと正確に同じになるでしょう。しかし、エントリを要約してほしいと言ったかもしれませんし、最も重要なポイントをハイライトしてほしいと言ったかもしれません。
エントリ全体を見せると言いますが、興味深いのは、それを表示する最も適切な方法は、これにH1を与えて、これを異なる段落として配置し、それに関するメタデータを取って、それを下部に配置することだと決定したことです。LLMがこれからカードを作る、素敵なUIを作る、見栄えを良くすることを決定するかもしれないと想像できます。
さらに一歩進んで、これがソーシャルメディアMCPサーバーで、私が投稿をしており、誰かが日本語で何かを投稿し、「私の友人が何について共有したのか」と私が言うとします。それは私に戻ってきて、私が日本語を話さないことを知っているので、私のために翻訳してくれます。LLMが機能する方法であるため、そのすべてが統合されているだけです。非常にクールな体験です。
そして私はそれを削除してロックアウトするよう求め、それで終わりです。
必ずしも未来のユーザーインタラクションがチャットベースだとは思いません。必ずしも大きなスレッドのやり取りを見るとは思いません。個々の会話を持ちたいとは思いません。むしろ、いつでもただ何かを言うと、それが私が話していることを知っており、そのすべてについて教えてくれる方がいいでしょう。
そのユーザーエクスペリエンスが何であるかは完全に確信していませんが、Carson Grossがここにいたら、確実にハイパーメディアが答えだと言うでしょう。
それは本当ですね。それがその一部かもしれませんが、最終的に私の指針はJarvisです。トニーがJarvisを使用するのはどのようなものかです。それは素晴らしいです。アイアンマンスーツは欲しくありませんが、まあ、分からない、武器がなければかなりクールに見えるかもしれませんが、私はJarvisが欲しいです。今これを行う技術があると思うので、人々にこのことを教えることに焦点を当てています。
クライアントとサーバーの現状
ここにクライアントがあります。ZedもMCPクライアントとしてご紹介いただき、ありがとうございます。多くのクライアントは開発者ツールで、もちろんそれは開発者がこのようなものに本当に関与しているからです。私たちはそれを構築している人たちです。私たち自身のためのソリューションを構築するつもりです。
しかし、開発者だけを対象としていない非常に重要なプレイヤーもいくつかあります。サーバー側では、必ずしも開発者向けでもないこれらのツールがたくさんあります。PayPalがサーバーを持っているのは本当にクールだと思います。彼らは本当に初期の段階でした。Shopifyのように、LLMと会話することを想像できますか。「姪の誕生日パーティーに何を着ればいいか分からない、これがテーマです。アイデアをください」と言うと、アイデアをくれて、ShopifyやShopアプリなどで製品も見せてくれます。慣れ親しんだチャットインターフェースから、または慣れ親しんだアシスタントから離れることなく、すべてが行われます。
他の人についてはわかりませんが、ChatGPTが昨年本当に良くなって以来、Googleを使用する回数は10分の1になりました。Googleで検索することはほとんどありません。情報が必要な場合は、AIアシスタントに行きます。これが私が本当に興奮していることです。
興味がある方は、Epic AI Proをチェックしてください。この件についてより深く人々に教えるためのワークショップなどを開催していますが、今日もこれらすべてを構築する実際のコードをかなり深く見せることを喜んで行います。
以上です。これが私の小さなプレゼンテーションです。最後にこれらすべてを確認してください。
開発者向けMCPの活用方法
素晴らしいですね。本当にポイントを理解させてくれました。私たちは皆、潜在的な可能性を理解できますし、実際にJSONなどを見せてくれて、クライアントとサーバーとの間で実際に何がやり取りされているかを見ることができます。
開発者のユースケースに焦点を当ててみましょう。それが現在の私たちの聴衆ですから。私が思い浮かべることの1つは、現在のMCPの現代的な使用を2つのカテゴリーに分けることができるということです。
1つは、多くの人が使用している人気のあるMCPサーバーです。しばらくの間Puppeteerが人気だったことを知っていますし、それに代わってPlaywrightがあると思います。私はウェブ開発ゲームから少し離れているので、それについては遅れていますが、そのようなものです。
2番目のユースケースは、作業していることに特化した独自のMCPサーバーを構築したい場合です。私にとってZedで即座に思い浮かぶ例は、ZedはすべてRustで書かれているため、VS Codeフォークではなく、内部でウェブ技術を使用していないので、現在、Zedで作業している時にAIエージェントに「inspect elementのようなことをしてデバッグを支援して」と言う能力がありません。
私たちは独自のカスタムinspect element相当のものを構築しましたが、もちろんAIエージェントは誰もそのようなものが存在することを知りません。Zedを開発している時にPlaywright型の体験を自分たちに提供したい場合、MCPサーバーは非常に明白なカスタムな方法のように思えます。これが2番目のユースケースで、プロジェクトに特化したものです。
3番目のユースケースは、実際に外部使用のためのMCPサーバーを開発したい場合です。これはJarvisのユースケースのようなもので、自分たちの内部生産性のために独自のものを構築するのではなく、むしろエンドユーザーが実際にこれを介して私たちのサービスに接続する場合です。
私たちは時間があるので、これらすべてについて話せると思います。人々が知っておくべきMCPサーバーから始めましょう。あなたが遭遇した、人々が本当に好む、または広く使用されている、または少し外れた道にあるかもしれないが、もっと多くの人が知るべきものについて教えてください。
実際のところ、私は現在、多くの人ほどMCPのユーザーではありません。私の主な焦点は独自のMCPサーバーの構築にあったので、自分で構築したいくつかのものがあり、ニッチなユースケースですが、興味深いと思います。
しかし、人々が知っておくべきものの1つは確実にContext-7で、特にJavaScript開発者であればです。実際、JavaScript以外のライブラリ用のドキュメントもあるかもしれませんが、Context-7のようなLLMの大きな問題の1つは、訓練データに限定されていることです。
少し戻りますが、MCPのクールなことの1つは、目を細めるとRAGのようなものだということです。
RAGを定義していただけますか。
RAGはRetrieval Augmented Generationの略語で、情報を取得し、その情報に基づいて生成されるものを拡張することです。実際に、コンテキストやコードなどをチャットに入れて、それについて質問をする時、あなた自身がそれを行っています。情報を取得し、その情報に基づいて生成されるものを拡張しているのです。
RAGの技術的定義が何であるか、何が真のRAGとしてカウントされるかについては人々の間で意見の相違がありますが、基本的なアイデアは、追加のコンテキストに基づいて生成されるものを拡張することです。
問題の1つは、モデルがライブラリの古いバージョンで訓練されていることです。新しいバージョンのライブラリがある場合、生成されるコードは古くなり、それは良くありません。Context-7には2つのツールがあります。1つは、与えられたプロンプトに対して最も適切なライブラリを検索するツールで、もう1つは、あなたが持っているバージョンとクエリに基づいて、そのライブラリの最も適切なドキュメントを検索するツールです。
大きなライブラリのほとんどは、コンテキストに含めたいよりも多くのドキュメントを持っているからです。コンテキストを与えすぎると、LLMは混乱してしまいます。彼らは効果的に、これらすべてのライブラリのベクトル化されたデータベースを作成しています。これは本当に良いものです。私はそれをよく使用します。
それはクールですね。前回のエピソードでは、Mitchell Hashimotoと同じ種類のことについて話しましたが、プログラミング言語のコンテキストでした。彼はZigと多くのことを行っており、Zigはトレーニングセットでは他のものほどよく表現されていません。私はRockという言語に取り組んでいて、LLMの利益のために言語がどのように機能するかの説明である、コピーペーストできるものがあります。Context-7で同じ基本原理で何かを完全に行うことができるようです。ライブラリではなく言語ですが、トレーニングセットにないもの、またはトレーニングセットが古いものについてモデルに理解を与えるという同じ基本原理ですね。
はい、必要なコンテキストを取得することに非常に役立ちます。LLMを自分のアプリケーション用のチャットボットでラップしている人々は、おそらく自分のもののベクトル化されたデータベースを持っているでしょう。彼らは独自のカスタムサーバーを構築するためにまったく同じことを使用でき、LLMが検索クエリを提供し、そのクエリに最も適したコンテキストを返すサーバーツールを持つことができます。これは本当に良いものです。
メモリを管理するものもあります。Jarvisの本当にクールなことの1つは、それがあなたについて物事を覚えており、あなたの好みなどを知っているということです。実際には使用していません。まだ試していません。super memory MCPと呼ばれていると思います。これです。これは本当に良いと人々に言われています。あなたが誰であるか、何に興味があるか、さまざまなサーバーでのあなたの好みなどをすべて覚えてくれます。
それからPlaywright MCPサーバーがあり、ブラウザを制御できます。現在、ほとんどのウェブサイトにはMCPがありませんので、接続することができません。実際にPlaywright MCPを使用して、「このウェブサイトに移動して、これを実行して」などと指示することができます。Playwrightをエンドツーエンドテストに使用している場合は、自動化されたテストの作成も支援できます。これは私が少し使用したもので、非常にクールです。
よりニッチなものの1つは、ワークショップアプリ用のMCPサーバーがあることです。人々が私のワークショップを受講する時、カスタム構築のワークショップアプリケーション体験があります。実際に見せた方が良いでしょう。
これは、AIアシスタントにワークショップの教材についてクイズを出させるデモです。MCPサーバーは、クイズを出したい最も関連性の高いものを取得し、実際にLLMが使用するプロンプトを持っており、教材を本当に理解していることを確認するのに役立つ方法でクイズを出します。これは非常にクールですが、そのものは少しニッチです。確実にお試しください。
カスタムMCPサーバーの構築体験
これは実際に、MCPサーバーの2番目のカテゴリーである、あなた自身のユースケースに特化したかなりニッチなもの、への良いセグエです。私が言ったように、Zedではこれをやっていませんが、確実に独自のinspect element相当のことを行うMCPサーバーをセットアップして、私たち独自のカスタムRustコードベース用の独自のPlaywrightを構築することができます。
そのようなことを人々がやっているという興味深い話を聞いたことがありますか。どのように進んだか、何がうまくいったか、うまくいかなかったか、内部カスタム開発でMCPを行う人々について？
実際、現在人々が構築しているMCPサーバーの大部分は、具体的にそのためのものだと思います。彼らは自分自身のために非常にカスタマイズされたものです。私も自分自身のために、作成しているコンテンツの評価を支援するものなどがあります。それは実際にかなり一般的です。
正直なところ、私は実際にMCPをウェブサイトの代替として考えています。ウェブサイトのようなものがあります。時々、それは文字通り1つのことしかしない、1つの目的のウェブサイトです。おそらくまったく同じことを行うMCPサーバーを持つことができます。また、消費者向けのもの、あなたの会社の内部ツール、すべてがMCPでできることと非常に良い並行性があります。
実際、「MCPが会社でどのように役立つか、私にとって何が有用か」と考えている場合は、現在行っているプロセスを見てください。それらのプロセスには、おそらくウェブサイトが関連付けられています。ボタンやリンクがあり、それらすべてがMCPで表現でき、LLMにそれを行うよう指示すると、それを実行できます。もし速くなくても、少なくともあなたのためにそれを行えるので、あなたは他のことができます。
それは興味深い心理的なモデルです。元々のハイパーテキストについてのウェブのことを考えると、それが何だったかというと、「この情報がすべてあり、以前は紙に印刷されたシートの形だった。これを特定の構造化された方法で配置して、インターネット経由で配信できるようにしたらどうか」というものでした。
同じことのようなもので、同じ情報があるが、HTMLに配置する代わりに、Hypertext Transfer Protocolではなく、Model Context Protocolという、この異なるプロトコルを使用してこの他の方法でまとめたらどうかということです。そうすれば、より有用な方法でアクセスできるようになります。その類推が気に入りました。
あなたが先ほど与えた類推も思い出しました。「モデルがツールを使用するよう求める時、技術的にはターミナルツールを使ってすべてを行うことができる。ファイルを編集するためにsedなどを使用できるが、その目的のために設計されたツールがある場合の方がはるかに優れている」ということです。同じように、確かにウェブサイトに行くことも、いくつかのAPIを単純にヒットすることもできますが、実際に時間をかけて、または誰かが時間をかけて実際の統合を構築する場合、すべてがはるかにうまくいくでしょう。
はい、それは抽象化のレイヤーと何も新しいことも違うこともありません。ゼロと1でほぼ何でもできますが、アセンブリははるかに良く、Cはそれよりもはるかに簡単です。これらの抽象化のレイヤーを重ねて、より多くの人にとってよりアプローチしやすくします。私はそれが本当にエキサイティングだと思います。
採用マインドセットの転換
少しマインドセットについて話しましょう。新世代のツールについて私が気づいたことの1つは、まず何が存在するかを知らないという段階があり、それから認識があり、これは本当にクールで潜在的な可能性に興奮するという段階に移行し、ある時点で「実際にこれで何かを構築できる。これを棚から取って開いて、いじり回すことができる」とより具体的に考える段階に移行することです。
企業や組織、さらには個人が、MCPは他の人がやることで、棚からのものを使うかもしれないが、多分そうしないかもしれないという考えから、「いや、実際にこれは私のツールボックスにある。カスタムMCPサーバーを構築して、この問題を永遠に解決できる」という考えに移行するマインドセットを採用することについて、成功事例や戦略を見たことがありますか。
これは常に挑戦のようです。特に私のように業界に長くいると、ワークフローを開発し、それが改善されるとしても新しいものを学ぶ時間を取りたくないようです。しばらくの間は遅くなることがわかっているからです。
私がついに適切なスノーボードレッスンを受けた時に同じ問題がありました。多くの悪い習慣を忘れなければならず、新しいことを学び始めるまではしばらくスノーボードが下手になりました。
そのようなことをする人々を得るためには、ギアを変更して「自分のMCPサーバーを構築してみよう」と言うのに十分に説得力のある理由が必要です。そのワークフローを試してみて、そのワークフローに強制的に切り替える必要があります。
現在、Zedを開くことができ、「この変数のすべてのインスタンスを他のものに置き換えたい」と言うことができます。現在、そのためのワークフローは、エディターの組み込み機能のようなものです。LLMにそれを行わせることもできます。お金がかかり、おそらく時間がかかるでしょう。もしかしたら、「その変数を変更するなら、これも変更することが実際に理にかなっている」と言って、より良くなるかもしれません。
少し良くなる可能性がありますが、ネットはおそらく悪化するでしょう。しかし、MCPとLLMでの作業のこのワークフローを本当にクールにしているのは、その1つのタスクだけでなく、これらのタスクを一緒に連鎖させることができることです。そこでエージェントに入り、エージェントがどのように継続し、最後に求めたことからのコンテキストに基づいて物事を改善し続けることができるかです。
私はまた、あなたが私に求めたいこともここで行い、ここでこれを行いたいということも知っています。人々がここでの価値を見るのが難しい理由の一部だと思います。「自然言語を使って友人にお金を送ることができました」と見ますが、「ウェブサイトがあり、ウェブサイトに行ってその方法でできる。それは難しくない」のようです。
しかし、「友人にお金を送り、カレンダーで時間をスケジュールし、遅れることを知らせるテキストを送る」など、これらすべてを一緒に行うことができれば、これらすべてを一緒に行うと、もう少し理にかなってくると思います。
すべてがMCPサーバーである必要があるとは思いません。すべてがそのワークフローに変換される必要があるわけではありませんが、タスクを実行するためにLLMを使用すればするほど、MCPサーバーを持っていることを願うようになるでしょう。それは、その1つの環境にもっと長く留まることができることを意味するからです。
MCPサーバー設計のベストプラクティス
それは非常に理にかなっています。あなたが言ったことに暗黙的に含まれているのは、MCPからより良い結果を得る方法があるようだということです。その1つは、ウェブサイトに配置するものを取ってMCPifyするのではなく、エージェントがこれを使用し、多段階のワークフローの一部として、ループで物事を行い、他のソースや他のMCPサーバーからデータを組み込むことを考えることです。
実際に、MCPサーバーをナイーブな方法でやるのではなく、つまり既に持っているものを取ってこのプロトコルを周りに配置するのではなく、さらに良くする方法について、コツやヒント、避けることができる失敗モード、またはMCPサーバーをさらに良くする方法はありますか。
MCP サーバーの構築に必要なことを学び始める時に人々が最初に考えることの1つは、「LLMが呼び出すことができるこれらのツールがあります。既にHTTP APIであるOpen APIのようなものがあり、基本的にLLMからそのAPIへのリクエストをホットポテト的に送るだけです。Open API からMCPサーバーを生成するツールがあったらどうでしょう」ということです。ほとんどの人がすぐにそこに行くでしょう。
その問題は様々ありますが、これらのアシスタントを可能な限り人間として考えるべきです。人間がどのように相互作用するかが、LLMまたはアシスタントが私たちのものを使用するのを支援したい方法です。
人間にすべてのAPIスペックのページと、すべてのJSONに対する小さな入力を与えたら、人間はおそらくあなたのデータベースを台無しにするでしょう。ほとんどの場合、ウェブアプリケーションを考えている場合、単一のボタンクリック、フォーム送信のようなものは、多数のAPI呼び出しを含み、それらは正しい順序で呼び出されなければならず、1つからのデータが他のデータに入る必要があり、LLMはそれを正しく理解できません。
それは非決定論的であり、Jarvisレベルのスマートさを持っていたとしても、任意のAPI呼び出しが発生するためにAPIを開放したいかどうかはまだ確信できません。
MCPサーバーの全体のAPIをツールとして手渡すことについて考えたくないので、実際に行いたいことに関するヒントとして、ウェブサイトを見て、そこにあるボタンを見て、「使用例は何か、誰かがこのページに移動してそれをクリックして、その情報を取ってそこに配置する時に達成しようとしているワークフローは何か」と考えることです。
正直なところ、ウェブサイトは実際にユーザーにあなたのものをどのように使用してほしいかを知るのにかなり良いです。なぜなら、共通のワークフローをボタンやウィザードのようなものに変えるからです。ウェブサイトが設計された方法を見て、それらのユースケースをツールに変換してください。
私のデモで見たように、エントリを取得するget entryツールのような低レベルのツールがいくつかあります。CRUDに関連するものがいくつかありますが、それをウェブサイトに変換する場合、エントリを表示するページがあるので、そのようなことをするのは理にかなっています。
また、add tag to entryツールもありました。それは、人々が行うことを期待する特定のワークフローのようなものです。
それに関連するもう一つの部分は、サーバーを構築する時、ツールの名前と説明、入力の説明、そのようなものであるテキストの文字列があることです。応答も同様です。これらの文字列を通して、誰と話しているかを学び、理解することは本当に役立ちます。
時々、あなたが書いているテキストを見ることになるのは、ツールの名前、ツールの説明、入力の説明、応答のようなLLMになります。これらはすべてLLMに向けられ、LLMはそれを使用して、ユーザーのクエリに対してあなたのツールが適切かどうかを判断します。
しかし、ツールのタイトルのようなもの、時には入力の説明、動的プロンプトの説明（これはMCPのもう一つの機能です）さえ、これらはユーザー向けになります。一部のものは実際にはホストアプリケーション向けでもあります。ChatGPTやClaude、Zedのようなホストアプリケーションが使用する構造化された出力があります。
別のヒントは、どのコンテキストでテキストを入力しているかを理解し、そのテキストの聴衆が誰であるかを理解することです。特にツールの説明では、ユーザーを代表する他の人と話していることを知り、その人と話して、「ユーザーがこれを行いたい場合、このツールを使用すべきです」と言うことです。
一般的なプロンプトエンジニアリングのヒントとして、一般的に人間はこれがより得意で、私の経験ではLLMも、コンテキストよりも結論を最初に与える方が良いです。「私のコードはすべてここにあります。下部で、それで何をしたいかを言います」とするのではなく、「これで何をしたいか」から始めて、「今、コードはこちらです」としてください。コードを処理する時、または私たちの脳がコードを処理する時、最終的な目標が何であるかを知っていれば、特定のものを探すのがはるかに簡単です。
MCPの機能の1つであるプロンプトがあり、特定のワークフローに適切なツールを使用するようLLMを導くのに役立ちます。そのコンテキストでは、基本的にプロンプトエンジニア、または今はコンテキストエンジニアだと思います。
外部向けMCPサーバーの開発
時間が少なくなってきたので、第3のカテゴリーについて少し聞きたいと思いました。あなたがMCPを開発していて、目標が実際に組織外の誰かに使用してもらうことだとしましょう。これは、あなたが使用するアプリケーション用にカスタムでオーダーメイドではなく、他の人があなたのアプリケーションを使用するためのカスタムでオーダーメイドです。これがまだ初期段階であることを最初に述べたと思いますが、人々はこれをやっているのでしょうか。これをどのくらいの頻度で人々がやっているのか、人々が今すぐやり始めるべきことなのかわからないですか。
はい、先ほど見せたように、あなたが慣れ親しんでいる企業からのサーバーが既にあります。聴衆に依存しますが、聴衆が開発者であれば、絶対にMCPサーバーで作業すべきです。開発者はそれを理解し、愛しています。
聴衆が生産性のようなビジネスではなく、ビジネスユーザーのような場合、MCPサーバーを持つべきでもあります。Claudeはそれをサポートしており、彼らはそれを統合と呼んでいます。ChatGPTはそれを接続と呼んでいます。Geminiが何と呼んでいるかはわかりません。
しかし、これらは現在誰もが使用しているツールに組み込まれています。通常の消費者がいる場合、通常の消費者がこれらのものを使い始めているという大きな急増があったかどうかはわかりません。現在、Claudeのような各サービスには、統合やそれらが何と呼んでいるものを使用できるために有料サブスクリプションが必要だと思います。
多くの人がChatGPTやClaudeの有料サブスクリプションを持っていると思うので、それはあなたのユーザーにアンケートを送るようなことになるでしょう。彼らがこれらのツールを使用しているかどうかを調べてください。
また、今後12〜18か月で、ユーザーはこれらのAIアシスタントアプリケーションに行くために可能な限りブラウザから逃げていると思います。あなたは彼らがそこにいる時にそこにいたいのです。電話用のアクセサリーを販売している場合、彼らがChatGPTに「私のiPhoneのケースが必要です」と尋ねた時にそこにいたいのです。番号が何かさえ覚えていませんが、ChatGPTが「ああ、このMCPサーバーを使わせてもらいます」となるようにそこにいたいのです。
現在、MCPサーバーは意図的に設定およびインストールする必要があり、私はそれが嫌いです。将来はそのようになるとは思いません。人間に何かをしてもらうよう頼む場合のようになると思います。彼らは今はChatGPTに行くかもしれませんが、検索エンジンに行き、最も適切なツールを見つけて、それを使用するでしょう。将来もそのようになると思います。
仕様で現在、MCPサーバーを発見する方法についても議論されているので、将来的にはそうなるでしょう。ユーザーがそこにいる時に、あなたのものを準備しておきたいだけでなく、質の高いサーバーを構築する経験レベルも重要です。これも競争優位性になると思うからです。
それは理にかなっています。ウェブサーバーを発見するのと同じ方法で、MCPサーバーを発見することが問題であり、現在それが多くの方法で解決されているのと同じように。
学習リソースとワークショップ
最後に、人々がより詳しく学べる場所について教えてください。詳細が欲しい場合はどこに行けばよいですか。
EpicAI.proにこれらすべてのものがあります。多くの異なる投稿があります。現在、基礎ワークショップの次のワークショップを準備中ですが、高度なワークショップにも取り組んでいます。現在、2日間のワークショップになる可能性があるという問題に直面しているので、それをどのようにスケジュールするかを理解しようとしています。
しかし、MCPの基礎の根本に本当に入りたい場合は、これは始めるのに本当に素晴らしい場所です。EpicAI.proをチェックしてください。
素晴らしいです。Kent、本当にありがとうございました。これらすべての時間とコンテキスト（意図的な駄洒落）に感謝します。ここには明るい未来があり、また刺激的な現在があると思います。私たち全員が学ぶのを手伝ってくれて、本当にありがとうございました。
コメント