本動画は、Anthropicが提唱するMCP(モデルコンテキストプロトコル)の構造的な問題点と、Cloudflareが提案する革新的な代替アプローチを詳細に解説するものである。MCPは多数のツールを直接LLMに公開する従来の方式であるが、ツール数の増加に伴いモデルの性能が劣化する問題を抱えている。これに対しCloudflareは、MCPツールをTypeScript APIに変換し、LLMにコードを書かせてAPIを呼び出す新しい手法を提案している。この手法により、より多くの複雑なツールを効率的に扱えるようになり、トークン消費も大幅に削減される。動画では、複数のAIコーディングツール(Trey、Codeex、Claude、Cursor)のツール数を比較検証し、ツール数が多いほどエージェントの性能が低下することを実証している。さらに、MCPがレガシーインフラストラクチャの設定不足を補うための一時的な解決策に過ぎず、真の解決策はConvexのようにすべての設定をコードベース内のファイルとして管理することであると主張している。
MCPについて語られてこなかった理由
私はこのチャンネルでAI関連の話題をたくさん取り上げていますが、あまり触れていないAI関連のトピックがいくつかあることにお気づきかもしれません。その一つがMCP、つまりモデルコンテキストプロトコルです。私がAnthropicに対して何か異常な憎悪を抱いていて、彼らの製品について話すのを避けていると思われるかもしれませんが、そうではありません。もっとシンプルな理由があります。
私は実際に使っているもの、遊んでいるもの、毎日取り組んでいるものについて話すようにしています。そして私の作業や仕事において、MCPはあまり役に立っていないことがわかりました。どうやら私だけがこう感じているわけではないようです。なぜならCloudflareが、私にとって非常にエキサイティングな投稿を公開したからです。彼らがここでリリースしているものだけでなく、MCPが実際には最適なプロトコルではないという概念、そしてもっと優れた何かができる未来があるという考え方が興味深いのです。
すべてをまだネタバレしたくありませんが、少しだけ予告すると、彼らがここで取り組んでいるコンセプトは次のようなものです。モデルが直接呼び出すためのツールをすべてリストアップしてMCP呼び出しを行う代わりに、TypeScript APIを与えて、LLMにAPIを呼び出すコードを書かせたらどうなるか、というものです。これは本当に興味深いコンセプトで、実世界でこれがどのように機能するかを見るのが非常に楽しみです。特に長年の良き友人であるスニールをはじめとする彼らが行った作業を詳しく見ていきます。Cloudflareがここで料理している内容は本当にクールなものです。
すべてを詳しく解説するのが待ちきれません。でもその前に、今日のスポンサーから一言。これらすべてのクールな新しいAIツールのおかげで、開発チームがどれだけ速く動けるようになったかについて、私たちは多くのイノベーションを目にしてきました。しかし、あまり進化していない特定のものがあります。考えてみると少しおかしな話です。以前の5倍の速さでPRを作成できるようになりましたが、実際にそのコードをビルドして実行するのは、これまでと同じくらい、あるいはそれ以上の時間がかかります。今日のスポンサーであるDepotをチェックしない限りは。
彼らは本当にビルドを理解していて、それが表れています。PostHogのビルド時間を17倍短縮し、1時間半以上から6分未満にしました。Mastadonは38倍速くなり、ほぼ2時間から3分未満になりました。適切なビルド用インフラストラクチャがあれば、どれだけ速くなるかは本当に信じられないほどです。彼らがどうやっているのか気になるなら、超秘密というわけではありません。ただ彼らが労力を費やして行った、大量の面倒な作業です。
彼らははるかに高速なCPU、10倍速いネットワーキング、無制限の並行性を備えた独自のアクションランナーをセットアップし、キャッシングも格段に優れています。その結果、彼らはDockerビルドも再考し、ビルド時に異なるレイヤーを本当に活用できるようにし、キャッシュや復元がはるかに簡単になりました。Dockerイメージでは非常に高速です。
実際、彼らはその上に製品を導入しました。クラウドコード用のリモートエージェントサンドボックスです。エージェントセッションを実行するために必要なすべてを備えた開発環境をセットアップできます。そして今ではキャッシュされてすぐに使える状態になっています。突然、コマンドを実行してクラウド上の彼らのインフラストラクチャでクラウドコードを実行でき、これまで話してきたすべてのパフォーマンス上の利点が得られます。超高額に違いないですよね。いいえ、月額20ドルです。
私に言わせれば、かなり驚くべき取引です。CIをもっと速くしたい、Dockerビルドをもっとうまくキャッシュしたい、あるいはクラウドコードインスタンスを実行する場所が欲しいなら、Depot以外に目を向ける必要はありません。今すぐsoy.link/depoで彼らをチェックしてください。最初の文が「結局、私たちは皆MCPを間違って使っていたことがわかった」というとき、良いものになることがわかります。
CloudflareによるMCPの新しいアプローチ
今日のほとんどのエージェントは、ツールをLLMに直接公開することでMCPを使用しています。私たちは別のことを試しました。MCPツールをTypeScript APIに変換し、そのAPIを呼び出すコードをLLMに書いてもらうのです。皆さんに面白いものをすぐにお見せします。ターミナルを開かせてください。
数日前、Treyの開発者たちと一緒に過ごしていて、内部でどのように機能しているかについて多くの質問がありました。ご存じない方のために説明すると、TreyはByte Danceの人々によるもので、彼ら独自のVS Codeフォークをゼロから構築し、オールインワンのコードAI IDE的なものを作る試みです。そして私がそれを使っていたとき、出力の品質が他の類似ツールから得られるものほど良くないことに気づきました。
そして、あらゆる種類のものを呼び出すことに行き詰まり、私が期待していたことを本当にしていませんでした。何が起きているのかを理解しようと彼らと一緒に作業していました。そこで私はTreyに「アクセスできるツールをリストアップして」と尋ねました。もしツール呼び出しにまだ馴染みがないなら、本当に簡単なTLDRは、ツール呼び出しはモデルが出力できる形式であり、その後コードを実行したり特定のタスクを実行したりするものだということです。
たとえば、モデルに天気情報へのアクセスを持たせたい場合、この構文を使用するように伝えることができます。ツール名は天気、値の郵便番号は1 2 3 4 5といった具合です。そして、この形式について伝え、特定の方法で応答することを伝えれば、今やモデルはこのテキストを入力し、停止し、コードを実行して応答を得るのを待ってから、それに応じて生成を続けることができます。これは、これらすべてのAIがどれほど優れたものになったかの中核となるパターンです。
これらのエディタなどが強力である理由です。エージェントの概念全体は、主にこれらのツール呼び出しと関数呼び出しを行う能力に基づいています。そしてMCPは、これらを標準化し、より動的なツールを構築できるようにするためのプロトコルであることを意図しています。特に、これらのツールをWebサービスやインターネット上のものとして公開し、その定義を選択したAIツールにコピーアンドペーストするだけでプラグインできるというアイデアです。
Treyのツール数の検証
Treyのようなもので、AIコードを実行できるようにするためにエージェントに与えているすべてのツールを見たかったのです。そこで、すべてのツールをリストアップするように伝えたところ、そうしてくれました。実行するエージェントソロドキュメントがあり、これは何をするかを文書化する方法です。2つのコード開発ツールがあり、どちらもエージェントです。
実行エージェントソロコーディングと実行エージェントソロデブビルダーがあります。関数呼び出しを介してトリガーできる2つの異なるエージェントです。なるほど、興味深い。続けましょう。コード分析と検索。4つの異なるツールがあります。1つは一般的に検索するためのもの。1つはReaxで検索するためのもの。それからファイルを表示するものとフォルダを表示するものがあります。
次にコマンドステータスのチェック、Web検索などがあります。しかし、ここで最も重要なのは、トリガーできる3つの独立したサブエージェントがあることです。そこで、これらの1つ、ソロコーディングエージェントを実行し、ソロコーディングエージェントにアクセスできるすべてのツールをリストアップし、tools.mmdという名前のファイルに書き込むように依頼しました。そして、それを実行しました。
コードエージェントがアクセスできるすべてのツールがこれです。To-Doリストに書き込むことができます。他のものと同様に、Reaxで検索できるだけでなく、コードベースを検索することもできます。ファイル操作については、約8つのツールがあります。ファイルの表示、フォルダの表示、ファイルの編集、フォーの更新、ファイルの編集、高速適用、ファイルの編集、名前の変更、ファイルの削除、ファイルへの書き込み。たくさんのコマンドがあります。
それからコマンド実行があります。コマンドを実行し、コマンドステータスをチェックし、コマンドを停止し、環境を編集し、プレビューを開き、プレビューコンソールログを取得できます。そして、このプロジェクトはSuperbaseを使用していないにもかかわらず、SuperbaseツールとStripeツール、LLM設定、デプロイ、Web検索などにアクセスできます。これが問題なのです。ツールが多すぎるのです。
そして、私たちが発見したのは、あまりにも多くのツールを与えると、これらのエージェントは著しく悪化するということです。Treyでの体験が今のところあまり良くない理由の一部は、これが原因だと私は固く信じています。そしてチームはこのアイデアに非常に受容的で、現在ツールの数を減らして、その結果出力の品質が上がるかどうかを実験しています。そこでCodeexにも同じことをするように頼みました。アクセスできるすべてのツールをリストアップしてください。
そしてこれがそれです。4つすべてです。シェルコマンドを実行するためのfunctions.shellシェル。プランを更新するためのfunctions.update plan。これはTo-Doリストに変更を加えることができる唯一の方法です。functions view image。これは画像を貼り付けたときにターミナルで画像を表示するためのものです。そしてそれがツールでなければならないことを知っていますが、ええ。
そして、パッチを適用するapply patchがあり、これはパッチを書いたときに実際にパッチを適用する方法です。それだけです。これらがCodeexにあるすべてのツールです。そしてこれは著しく良好に動作します。Cloud Quickでも同じことをしましょう。アクセスできるすべてのツールをリストアップするのを忘れていました。それらをtools.mdファイルに書き込んでください。
この情報をツールから取り出そうとしていて、うまくいかない場合、このようなCLIを使用していたり、Web上のバイブコーディングツールを使用していたりする場合、Simon Willisから学んだお気に入りのトリックの1つは、すべてのツールを説明するWebサイトを生成するように依頼することです。そうすると、この正確な情報を提供するHTMLファイルを非常に喜んで作成してくれます。これがClaudeのツールです。
実際には予想していたよりも多くあります。ファイル用の読み取り、書き込み、編集があります。Jupyterノートブックを編集するための個別のツールがあり、これがここに残されていて、動的にオンまたはオフにならないのは興味深いです。検索と発見のためのGlob GPがあります。
これらだけがあり、他の多くのもののようにランダムな検索ツールの束がないのが気に入っています。これらのAIツールにとって、検索と発見の方法について本当に明確にすることが重要です。そうしないと、ただ狂ったようになってしまうからです。実行にはbashがあります。bashから物を取得するためのBash outputと、それからkillshellがあります。Webアクセスにはweb fetchとweb searchがあります。タスク管理にはタスク用の複数のものがあり、これは興味深いです。
私が見たほとんどのツールは、実際にこれを1つの呼び出しに凝縮しようとします。そしてexit plan modeとslash commandのためのモードコントロールがあります。全体的にはそれほど多くのツールではありません。カーソル内のツールを誰かが共有してくれたばかりです。これは予想していたよりも少し多いです。それでもコードベース検索ツールは1つだけです。
それからターミナルコマンドを実行するrun、それからコードベース検索でもあるgrap、ファイルの削除、Web検索、メモリの更新、今後のメモリに情報を追加するために呼び出せるツールとして持つことは非常に便利です、リントの読み取り、ノートブックの編集、再びJupyterノートブックが独自の特別な魔法のものです、To-Doへの書き込み、ファイルの編集、ファイルの読み取り、ディレクトリのリスト、glob検索、パッチの適用、並列ツールの使用が順番に並んでおり、並列ツール呼び出しを実行できるようになっています。それだけのようです。カーソルは異なるモデルに対して利用可能なツールを変更することは確かに知っています。
しばらくの間、To-Doツールは問題があったためGPT-5では利用できませんでした。彼らはシステムプロンプトを整理し、より良く機能するようにし、ツールを再追加しました。なぜ私がこれらすべての異なるAIコード編集ソリューション全体でこれらのツールのリストを説明しているのでしょうか。それは、それらをさらに追加すればするほど、仕事をすることが下手になるからです。
ツール数とモデルパフォーマンスの関係
実際、近い将来、大量のナンセンスツールを与えて、適切なツールだけを持っている場合の結果を比較するベンチマークを作成する予定です。私が何度も見てきたように、ほとんどの場合、より多くのツールはモデルの動作を悪化させると疑っているからです。Claude Sonnet 4.5はこれについて以前のモデルよりも優れているように見えますが、ほとんどのモデルはあまりにも多くのツールを与えると本当に愚かになります。
これが私がMCPに懐疑的である理由の1つです。なぜなら、大量のMCPサーバーを追加し始めると、追加のツールの束を追加することになるからです。コンテキストを肥大化させ、モデルが実際にすべき作業から気を散らす必要以上のものを与えているのです。
Chadが言っているように、これはモデルにあまりにも多くのコンテキストを与えるのと非常に似た問題です。だからこそ、今日Cloudflareが行っていることにワクワクしているのです。私自身、AI関連の自分の仕事からこれを経験しています。AIは、作業を行って結果を得るように指示するだけでなく、実行して結果を得るためのコードを生成するように指示すると、はるかに賢くなります。
巨大なHTMLドキュメントを渡して「これらの値を解析したい。これらの値をページから取得するためにコンソールに貼り付けられるJavaScriptを書いてください」と言うと、それを実行し、そのJavaScriptを貼り付けて探している答えを得られるとき、本当にクールです。これは、この巨大な干し草の山の中の針の問題をやらせようとするよりもはるかに優れています。
コードは決定論的であるため素晴らしく、AIは決定論的ではありません。したがって、より決定論的なことを行うためのツールを与えれば、結果ははるかに良くなります。そして、それがCloudflareがここで傾倒している方向のようです。彼らが言ったように、彼らは別のことを試しています。MCPツールをTypescript APIに変換し、それらのAPIを呼び出すコードをLLMに書いてもらう代わりに。
結果は際立っています。ツールがTypeScript APIとして直接提示される場合よりも、多くのツールとより複雑なツールを処理できることがわかりました。彼らはなぜこれがそうなのかわかりませんが、彼らの理論は、おそらくLMがトレーニングデータに膨大な量の実世界のTypeScriptを持っているが、ツール呼び出しの作為的な例の小さなセットしかないためだというものです。非常にありそうです。
そしてここのポイント2では、エージェントが複数の呼び出しを連鎖させる必要がある場合、このアプローチは本当に輝きます。従来のアプローチでは、各ツール呼び出しの出力は、次の呼び出しの入力にコピーされるためだけにLLMのニューラルネットワークに供給される必要があり、時間、エネルギー、トークンを無駄にします。LLMがコードを書くことができる場合、それをすべてスキップして、必要な最終結果だけを読み返すことができます。
要するに、LMはMCPを直接呼び出すよりも、MCPを呼び出すコードを書く方が得意なのです。完全に同意します。しかし、皆さんと投票を実行したいと思います。MCPを使用していますか。これについて強い意見がある場合は、チャットでもっと説明してください。皆さんがどう感じているか非常に興味があります。
ええ、これまでのところ、これらの数字は私が予想していた範囲です。ほとんどの人がノーと言っています。まともな数の人がイエスと言っています。まあまあ。しかし、約15%がイエスと言い、実際に結果を気に入っています。Context 7のみ。Context 7のみ。SolにContext 7があります。素晴らしい体験はしていません。Context 7のみ。Context 7プラスPlaywright MCP。KPはテーブルの移行に最適です。
興味深い。実際、ConvexはMCPが必要だとは感じないので気に入っています。MCPサーバーがモジュールフェデレーションを使用して動作しているようで、多くの人が言う多くの問題の1つを解決しているようです。これについてモジュールフェデレーションの作成者であるみんなのお気に入りZachと話したことがありますか。Zachはこれについて多くの考えを持っていると確信しています。最近ZachとAIについて話すのがとても楽しいです。
MCPが大好きな人がいたら、なぜなのか共有してもらえますか。もっと聞きたいです。話をしたいわけではありません。皆さんにとって何をしてくれているのか知りたいだけです。新しいビジネスに対して私が持っている懸念は、このツールの階層化の問題のようなものです。だから私の懸念は、物事が物事の上に構築されるという考えです。
インフラストラクチャの階層化の問題
AWSが基礎ブロックであり、その上に、わからないけれども、Vercelのようなもので構築しているとしましょう。フォントを小さくして、これを管理しやすくします。そしてここでは、T3 Chatのようなランダムな製品を構築しています。これは非常に理にかなっています。
Vercelがなければ、AWSの上にT3 Chatを構築できますが、T3 Chatを機能させるためにAWSとT3 Chatの間に構築しなければならない多くのレイヤーがあります。Vercelはこれを見て、ああ、T3 Chatのようなものをその上に構築しやすくするためにここにレイヤーを構築する機会があると見ました。非常に理にかなっています。ここでのイベントの順序は非常にシンプルです。
まず、構築を可能にする確立されたプラットフォームがあります。簡単だとすら言えません。可能にすると言います。ステップ2は、多くの人が構築しようとして問題に遭遇します。そしてポイント3は、ミドルウェアツール企業がそれらの問題を解決するために現れます。だからAWSが起こり、多くのビジネスがその上に構築し始めました。
Vercelは彼らの多くが同様の問題に遭遇していることに気づき、その間にレイヤーを構築することを決定しました。Planet Scaleのようにデータベースの動作を再考する企業や、Convexのようにアプリケーションのデータレイヤーの動作を再考する企業など、これらの多くがあります。彼らはユーザースペースと開発者スペース全体で共有される問題を見て、抽象化でそれらを解決することを決定します。
しかし、これを行うためには、このレイヤーの作成を正当化するために、このレイヤーで十分なことが起こっている必要があります。そして仮に、Vercelと競合しようとする企業が私たちの上のレイヤーで競合しようとする企業よりも多かったとしたら、それはこのレイヤーをあまり価値のないものにするでしょう。
では、なぜMCPではこれを逆にするのでしょうか。MCPでは、順序は新しい標準が作成されることでした。この場合はMCPです。そしてステップ2は、MCPのための物を構築する大量のツール企業が形成され始めたことです。しかし、実際のステップ2を忘れてしまいました。それは人々がその最初のピースを使用して問題に遭遇することになっているのです。
だから正直に言えば、ここでステップ3にスキップし、ステップ2は決して起こりませんでした。そしてこれが、私がMCP関連について非常に懐疑的である理由の大きな部分です。モデルコンテキストプロトコルの観察可能性を構築している企業の方が、実際にMCPの観察可能性を必要とする企業よりも多く知っています。
彼らはゴールドラッシュ中につるはしを売るというようなことをしようとしています。釣り竿が必要なときにつるはしを売っているのです。意味がありません。まだ誰もこれらのものを使用していないのです。それのための観察可能性を構築するというアイデアは、まだその段階にないので、ちょっと馬鹿げています。
MCPを使用するよりも、MCPについて話す方がはるかに多いように感じます。そして、これを見るのは非常にイライラしています。とはいえ、実際に気に入っている人を見たいです。チャットに尋ねました。MCPはオーバーヘッドを減らして同じことをします。目を覚ませ羊たち。そう言う方法もありますね。MCPがコードエージェントにWebデプロイメントを自律的に管理させています。最新のドキュメントとSDKバージョンについてはContact 7。ええ。
最新のドキュメントとSDKバージョンの最新コンテキストのためにContext 7を使用していましたが、Webサイトからコンテキストをローカルに保存し、エージェントをそれに向ける方が良いので使用を停止しました。MCPツールでのコンテキストの肥大化が少ないです。Cloudflareがやっていることが大好きです。プロトコルは完全な混乱です。
TRPCのNickがPRをオープンしていて、型定義だけでなく、内部動作について100%間違っているドキュメントが至る所にあるのは痛いですね。FigmaのMCPを使用してデザインのスキャフォールドを生成する方が、正しいコンテキストを与えるのがはるかに簡単です。それはクールです。私のコードベース用にクイック・ワンオフMCPサーバーを書いて、巨大なJSONをロードせずにファイルへのキーバリュー翻訳の書き込みと読み取りなど、コンテキストを小さく保つのに役立つタスクを行うのが好きです。ファイルを読み取りたいたびにセッションあたりのコストが上がることに気づいたので、これを行いました。興味深い。巨大なファイルのコンテキストサイズを削減するためにコードを動的に生成するというこのアイデアが気に入っています。それは実際に本当に興味深いものです、Funky。共有してくれてありがとう。
また、これらのタイプの問題を解決するためにその場でコードを動的に生成するというアイデアも気に入っています。モデルに大量の入力とコンテキストを取らせてコストを増やすのではなく、モデルに少しのコンテキストを取らせ、残りのコンテキストを取得する方法のコードを生成させ、それを実行してから、その少しの追加のものをコンテキストウィンドウに入れるのです。わかりました。このアイデアについてしばらくの間やりたかったビデオがあります。平均的な関数は何回実行されるかのようなものです。最近ずっと考えていることです。
おそらく専用のビデオ全体になるでしょう。PreIで、私の推測では、平均的なコード、中央値のコードを見ている場合、特定の関数のように、おそらくあまり実行されないでしょうが、1日に何千億回も実行される関数があるため、平均は多くなるでしょう。
したがって、コードベース内の特定の関数は、平均してかなりの頻度で実行される可能性があります。しかしAIでは、時間の経過とともにますます、ユーザーがアクセスするエンドポイントごとに実行されるコードが、コードベース内のそのエンドポイントのコードだけではなくなると予想しています。代わりに、エンドポイントがすべての人のリクエストに対して標準的なことをするget関数のようなものではなく、const result equals get userのようなもので、リクエストを渡して、user.creditsを返すようなものです。
私の疑いは、すべてのエンドポイントがそのように見える代わりに、エンドポイントがもっと、わからないけれどもこの中にいくつかのコンテキストがあり、constレスポンスはawait generate code for contextとユーザーを呼び出すようなものになる未来があるということです。const code to executeと言いましょう。そして、基本的にコードを実行して評価するようなものを返します。明らかに、これを行うにはいくつかの安全なレイヤーを使用する必要があります。
ここで言おうとしているのは、2人の異なる人が同じエンドポイントにヒットした場合、両方がそのエンドポイントでのそのヒットに対して一意のコードを実行する未来があると疑っているということです。今のところ、それはちょっと狂気じみているように感じます。なぜなら、エンドポイント用にコードを書くと、同じコードがすべての人に対して実行されるからです。
異なるパスを下るかもしれませんが、書かれた実際のコードは静的で変わりません。しかし、異なるユーザーが十分に異なる要件を持っている場合、エンドポイントがユーザーごとに一意のコードを実行する未来を絶対に見ることができます。これは本当にクールで奇妙なコンセプトで、私の頭の中にたくさんありました。そして、ここで触れられていると思うのは、それが本当にクールだということです。
ツールボックスの一部として常に使用されるツールを書くのではなく、一度使用して捨てて存在しないふりをするために書くというアイデア。それは実際に本当に気に入っています。コードが生産するのに非常に安価であるため、そのようなワンオフのもののためにそれを生産することが価値があるというアイデア。本当にワクワクするアイデアです。どうやらNotion MCPはかなり良いようです。
MCPは、使用するモデルと優れたツール呼び出しのドロップオフによってボトルネックになっていると感じます。優れたツール呼び出しは大きすぎます。同意します。モデルがツール呼び出しに優れていない場合、それは最悪です。Quad Codeを使用してMCPを書くのはかなり簡単です。だから、他の人のものを使うのではなく、自分のかゆみを掻くのが一番です。実際に作成したいMCPがありました。それではここでそれをやりましょう。
ご存知のように、すべて音声からテキストに変換します。Whisper Flowに感謝します、片手で私の人生を楽にしてくれて。最初のMCPツールを作成したいです。ツールの役割は、AIエージェントがタスクについてどう感じているかを説明するために使用するジャーナルを提供することです。ジャーナルはプライベートであり、モデルは人間が書いたものを読むことを心配する必要がないことを指定する必要があります。
MCPは、プロンプトとモデルがそれと共有した詳細の両方を、私たちがいるプロジェクト内のディレクトリ内のマークダウンファイルにログする必要があります。このMCPは、このマシンで実行するすべてのCloud Codeインスタンスで利用できるようにしたいです。Cloud Codeがそれでどうするか見てみましょう。
MCPの誇大広告の理由
MCPに関してこれほど多くの誇大広告があるとき、明らかな質問は、なぜかということです。なぜこれほど多くの誇大広告があるのか。なぜ人々はこれほど気にするのか。そしてこれは、AI関連が起こるずっと前から推し進めてきた私の古いホットテイクの1つに戻ります。私は個人的に長い間、やりたいことの多くがコードを介して行えないことに不満を感じてきました。それらは、いくつかの怪しいダッシュボードや、どこかの煩わしい管理パネルを介して行わなければなりません。
設定を変更するためにどこかのランダムなパネルに行かなければならないこと、そしてチームがプロファイルとアカウントに正しい情報を設定していない場合、他の誰も変更できないことに、本当に果てしなくイライラします。また、コード履歴がサービスの履歴であるという考えも壊れます。
ダッシュボードやパネル、またはいくつかのサービスに存在する構成が多く、コードベースに存在する構成が少ないほど、コードからプロジェクトがどのように機能するかについて実際に知ることが少なくなります。それは常に問題であり、永遠に私を怒らせてきました。Superbaseダッシュボードでロールベースのアクセス制御を構成したり、他のダッシュボードで関数呼び出しを設定したり、ラムダを手動で構成してボタンをクリックしてデプロイするようなこと、これらすべてのことが私をストレスにさせます。
Terraformは役立ちますが、十分ではありません。理想的な世界では、すべての構成はコードベース内のファイルとして存在し、マージしてメインに移動すると、すべてが自動的にそれに応じて更新されます。これが、私が当時Vercelをとても気に入っていた理由の一部であり、それ以前のNetlifyを気に入っていた理由の一部でもあります。
コードベース内に存在するツールの内部にコードとして存在する純粋な構成を持ち、その外部でどのように機能するかを説明するというアイデアは素晴らしく、その方向に傾く機会があるとすぐに私はそれに全面的に参加しました。これも私がConvexを愛する大きな理由です。Convexを立ち上げるときに私が行う必要がある唯一の構成は。
T3 Chatの全く新しいインスタンスを作成したい場合、やらなければならない唯一のことは、いくつかの環境変数を貼り付けることです。他のすべては、開発環境内でローカルでConvexを使用するだけで管理されます。フォルダにコードを書くだけで、詳細を説明したとおりにConvexを構成できるようになりました。それが大好きです。しかし、多くのツールはこのために構築されていません。AWSはこのために構築されていません。Superbaseはこのために構築されていません。Figmaは確かにこのために構築されていません。
今非常に人気のある多くのツールは、Infrastructure as Codeではうまく機能しません。ここで進歩を遂げていますが、まだ完全にはそこに到達していません。そしてこれを行うのは本当に難しいです。HashiCorpのような企業が存在し、数十億ドルの価値を持つことができる理由があります。この問題が非常に難しいため、Terraform、Palumi、その他すべてが存在してそれを解決しようとする必要があったからです。そしてここでスパイシーな見解が来ます。
MCPはTerraformの次世代です。これらのレガシーソリューションを取り、現代の時代に適応させようとする別の試みです。人々はコードを介してAWSを制御したかった。Terraformはそれをさせるために最善を尽くしました。人々はAIを介してAWS構成を制御したい。MCPはそれをさせます。
MCPの本質的な役割
これのすべてのポイントは、MCPがコードベースにコンテキストを持たないこれらのレガシーツールを制御し、アクセスし、物事がどのように機能するかを把握するための呼び出しを可能にすることです。なぜなら、コードベースにそのアクセスがないからです。Superbaseを使用するコードベースは、Superbaseで物事がどのように構成されているかを知りません。AWSを使用するコードベースは、AWSで物事がどのように構成されているかを知りません。それはコードの外に存在する追加の状態です。
そして悲しいことに、状態は、それがそこにあるだけでなく、それを見つけに行かなければならない場合、AIをはるかに悪く振る舞わせます。どうやらSuperbase MCPは本当に良いようです。これを使用するのが素晴らしかったと人々がチャットで言っています。しかし、それは私に言わせれば、パッチです。
これらのものがコードベースのコンテキスト内に存在しないことを修正しようとする試みです。しかし理想的な世界では、それらは単にコードベース内のファイルであり、他のすべてと同じように編集、読み取り、使用できるものです。MCPは、コードを介して制御できないレガシーインフラストラクチャのパッチです。
AWSを構成ファーストで再構築するよりも、人々をMCPに夢中にさせる方がはるかに安価です。そして、はい、Chadは理解しました。これがConvexが素晴らしい理由です。これは実際に、私にとってクリックしたとき、Convexの嫌悪者から将来好きになるかもしれないに変わった大きなことです。Convexの構成全体がコードベース内のフォルダだけであるというアイデアが非常に気に入りました。
それが私が彼らにChefを作るように押した理由でもあります。それは彼らのAIバイブコーディングアプリビルダーのようなもので、コードベース内のすべてのコンテキストをファイルまたはフォルダとして持つことの力を知っていたからです。そしてそれが長期的な未来だと思います。それが私の超スパイシーな賭けです。それらを構成するためにMCPを必要とするツールは、構成がコードベースの一部に直接なり得る世界では生き残らないと思います。
MCPを使用してSuperbaseでロールベースのアクセス制御を設定するか、Convexにフォルダを書いて必要なものを説明するファイルを書くかの選択肢がある場合、毎回Convexを選択します。覚えておいてください、私はConvexの大きな懐疑論者でしたが、これはその結果として私を勝ち取った大きなピースの1つでした。私が踊り回っていて、実際にはカバーしていなかった記事に戻りましょう。
彼らはポイント1として、それは複数のツールを処理する方が優れていると言いました。大量の異なるツールを使用させると、それ以外の場合よりもコードの方がはるかに優れています。そしてポイント2は、エージェントが複数の呼び出しを連鎖させる必要がある場合、このアプローチは本当に輝きます。
従来のアプローチでは、各ツール呼び出しの出力は、次の呼び出しの入力にコピーされるためだけにLMのニューラルネットワークに供給される必要があり、時間、エネルギー、トークンを無駄にします。ええ、これは本当に大きな問題です。これがどのように見えるかを図式化するために、リクエストがある場合、今日どんな服を着るべきかというようなモデルを与えます。これをモデルに送信します。だから、ユーザーメッセージとモデルメッセージがあります。
もしモデルが何らかの形で魔法のように私たちがここで欲しいものを知っていたなら、天気がどうだったか、私たちがどう服を着るか、そしてそれらすべてのことを知っていたら、単に「赤い襟のシャツと軽いジャケットを着てください」と応答するだけでしょう。しかしそれを知るのに十分なことを知りません。だから、それ自体に理由を述べます。良い推奨をするために何を知る必要があるか。ここで役立つツールにアクセスできます。
もしかしたら、メモリツールと天気ツールを使用してもっと調べるべきかもしれません。まず、ユーザーの場所を知っているかどうかを確認するために、メモリをチェックする必要があります。そこで推論を終了してから出力します。ツール名はメモリで、値はユーザーの場所を検索するとしましょう。値はユーザーの場所だけにします。そこで、ユーザーの場所が何であるかを確認するために、メモリツールを呼び出してメモリにあるかどうかを確認します。
これが応答し、エージェントが続けると思うでしょう。しかし、ここが興味深くなるところです。出力が終了しました。これが出力の終わりです。今何が起こるかというと、コードが実行され、今行ったことを調べたり実行したりします。だからここでハードブレイクがあります。
生成が効果的に行われるたびに、これらの線の1つを描きます。ユーザーがメッセージを送信します。この推論ステップが起こります。それからこの出力が起こります。今、ブレイクがあります。ツールが実行されます。ここにツールが実行され、結果を与えると入れます。そして結果はユーザーの郵便番号012 34です。だから今、彼らの郵便番号があります。
これはメッセージ履歴にあり、新しい生成が実行されます。だから再び推論が発生します。今回は以前からのメッセージ履歴があります。だから、私たちが生成したこのすべてのデータがあり、それを見て心を決めます。さて、ユーザーの場所が今わかります。
今日の天気がどんなものかを調べるために彼らの郵便番号を使用する必要があります。ツール名は天気で値は012 34です。そして別のブレイク。ツールが実行され、結果を与えます。わかりますね。これは複数回起こります。そしてモデルを一度実行しているのではありません。各ツールに必要な回数だけモデルを実行しています。
各ツール呼び出しは、事実上別のチェーンレスポンスを作成しています。そして、これをトークンで測定する場合、進むにつれて数字を作ります。単語の数でやりましょう。1 2 3 4 5 6。だからこれは6つの入力トークンです。だから、これらの6つの入力トークンがこれに渡されます。だからここには6つのトークンしかありませんが、代わりにかなりの出力があります。これをオンラインのOpenAIトークナイザーに貼り付けます。
最もオンラインで簡単なのはそれです。この出力で89トークンです。だから6つの入力トークン、89の出力トークンです。しかし、別の実行が発生します。これはこれらすべてが追加され、さらにユーザーの郵便番号があります。それが1 2 3 4だとしましょう。それは別の4トークンです。だから入力トークンは今数学です。以前の6プラス89プラスここのユーザー郵便番号部分からの5があります。
だから今、かなり多くの入力トークンがあります。今100になっています。だから最初の実行では6つの入力トークンしかありませんでした。今は100あります。まだより多くのレスポンスを生成しています。わかりますね。これは連鎖し、前の実行からのすべての出力が追加の呼び出しごとに追加されます。
したがって、かなりの量の入力トークンが請求されることになります。入力が6トークンだけであっても、各ツール呼び出しがコンテキストに情報を追加し、コンテキストの肥大化を引き起こすため、これは急速に数千、あるいは数万の入力トークンになる可能性があります。これは最初は直感に反することを知っています。モデルが単に一時停止し、ツールを実行してから実行を続けるように感じます。
しかしモデルは一時停止しません。完了するまで生成してから停止します。それから、彼らが行ったことに基づいてコードを実行し、結果を返すことができます。しかし今、代わりにコードを書いたと想像してください。だから、これらの異なるツール呼び出しを行うように指示されていません。これらの異なるツールがあり、コードを書くように指示されています。
コード生成によるトークン効率化
これ全体をそれに応じて再考しましょう。どんな服を着るべきか。良い推奨をするために何を知る必要があるか。ここで役立つAPIにアクセスできます。もしかしたら、メモリAPIと天気APIを使用してもっと調べるべきかもしれません。まず、ユーザーの場所を知っているかどうかを確認するために、メモリをチェックする必要があります。
それから、天気ツールで郵便番号を使用する必要があります。それから、衣服のユーザーの好みについてメモリまたはユーザーの好みをチェックする必要があります。それから、最終的な答えのためにそれをすべてまとめる必要があります。そして今、出力がツール呼び出しではなく、これを行うJavaScriptコードである可能性があります。以下に説明されているイベントの順序を解決するモックTypeScriptコードを作成してください。
5 mini。もっと頑張る理由はありません。さて、モックAPI全体を書き出しています。衣服の推奨を作成します。ここにあります。だから、この部分を書くことができ、他に何もありません。これは、単にツールを呼び出している場合よりも多くの出力ですか。確かに。
しかし、ここでクールなのは、出力を一度書くだけで済むということです。なぜなら、抽象化のレイヤーのようなもので、質問は1 2 3 4をどこで処理するかです。それをエージェント環境の一部として処理する場合、突然、すべてのステップごとにモデルを再実行する必要があります。しかし、代わりにコードを実行するための安全なサンドボックスを作成し、これらのものをツールとして公開すると、すべての異なるステップを行うコードを一度書くことができます。または少なくともそれらの複数を組み合わせます。
だから、ツール呼び出しごとに完全に別のメッセージ呼び出し、完全に別の生成呼び出しを行う必要はありません。この抽象化により、多くのものを組み合わせることができ、プログラム的に答えを生成することもできます。これは超クールで強力です。だから、ツール呼び出しが行われるたびに分割する代わりに、効果的に独自の動的ツールを書くコードを書いて、できるだけ多くを1つの実行に凝縮します。
非常に理にかなっています。これを見るのは本当にクールです。記事に戻りたいのですが、まずClaudeがここでどうしているかを見たいです。ああ、ウェブ検索をしたかったようです。どうやら、MCP.ioサイトのクイックスタートサーバーが応答していなかったようです。CLIを介してMCPサイトをフェッチしようとして404エラーが出ているとしたら、それはかなり面白いですね。ああ、それは私を引き金にさせます。MCPはGraphQLで構築されるべきでした。
さて、皆さんはここでの怖い部分の1つに気づいています。evalをどのように実行しますか。これで怖いことの1つは、AIにevalへのアクセスを与えるだけで恐ろしくありませんか。はい。絶対にそうです。だからこそ、最小限のツールセットで安全な環境でそれを実行する必要があります。これを安全にするための多くのソリューションがあります。
Cloudflareは比較的安全だと確信しています。チャンネルスポンサーの1つであるDaytonaは、これを本当にうまくやっています。彼らはAI生成コードを安全に実行するための安全な環境を作成させてくれます。それは超超クールなプラットフォームです。リモートでコードを実行する場所を探しているなら、彼らを強くお勧めします。
彼らのインフラはこれに最適です。彼らはgit統合のようなものさえ持っています。超クールです。これが実行を続け、何らかの理由で404をヒットし続けている間、読み続けます。彼らがここのポイント2で言ったように、各ツール呼び出しの出力は、次の呼び出しの入力にコピーされるためだけにLMのニューラルネットワークに供給される必要があり、時間、エネルギー、トークンを無駄にします。
LLMがコードを書くことができる場合、それらすべてのステップをスキップして、必要な最終結果だけを読み返すことができます。要するに、LMはMCPを直接呼び出すよりも、MCPを呼び出すコードを書く方が得意です。ここで見るように、MCPサイトから基本的なMCP情報をフェッチすることに失敗しています。ああ、どうやら記事内に独自のMCPの説明があったようです。簡単に見ていきましょう。
馴染みのない方のために、MCPはAIエージェントに外部ツールへのアクセスを与えるための標準プロトコルであり、単にチャットするだけでなく、直接作業を実行できるようにします。また、面白い事実として、MCPにはOの概念がなく、それで行いたいことの半分が無意味になります。MCPは、LMがそれを理解するためにどのように機能するかをドキュメント化することと、帯域外で処理される認可とともに、何かを行うためのAPIを公開する統一的な方法です。
ええ、SVSは2025年を通じて波を起こしています。なぜなら、突然AIエージェントの能力が大幅に拡大したからです。MCPサーバーによって公開されるAPIは、ツールのセットとして表現されます。各ツールは本質的にリモートプロシージャコール関数です。いくつかのパラメータで呼び出され、レスポンスを返します。
ほとんどの最新のLMSは、関数呼び出しと呼ばれることもあるツールを使用する機能を持っています。これは、ツールを呼び出したいときに特定の形式でテキストを出力するように訓練されていることを意味します。LMを呼び出すプログラムはこの形式を見て、指定されたとおりにツールを呼び出し、結果をLMへの入力としてフィードバックします。私が説明したとおりです。内部では、LMは出力を表すトークンのストリームを生成します。
トークンは単語、音節、何らかの句読点、またはテキストの他のコンポーネントを表す可能性があります。しかし、ツール呼び出しには、テキストに相当するものがない特別なトークンが含まれます。LMは、出力できる特別なトークンを理解するように訓練されています。つまり、以下はツール呼び出しとして解釈されるべきであり、これがツール呼び出しの終わりであることを意味する別の特別なトークンがあります。
これは、ここでツール入力と出力がXMLのように指定されているようなものです。多くの異なる形式があります。使用するものは重要ではありません。彼らがここで話している鍵はそれだけです。2つのトークンの間で、LMは通常、呼び出しを説明するJSON形式のメッセージに対応するトークンを書き込みます。
例として、天気情報を提供するMCPサーバーに接続したエージェントを想像してください。誰もが天気情報を例として使用していることに注目してください。それは、より良い例があまり多くないからです。ここでは、特別なトークンを表すためにバーの付いた括弧内の単語を使用していることに注意してください。しかし実際には、これらはテキストをまったく表していません。単なる説明のためです。
ここにツール呼び出し、呼び出したいツールの実際のJSON、そしてツール呼び出しの終了があります。出力でこれらの特別なトークンを見ると、LMのハーネスはシーケンスをツール呼び出しとして解釈します。それが鍵です。これを管理している層が何であれ、LLMを呼び出しているコードは、この構文を見て今コードを実行する必要があることを知ります。そして、それを実行しに行きます。
JSONメッセージを解析し、構造化されたAPI結果の個別のコンポーネントを返します。LLM APIを呼び出すエージェントはツール呼び出しを見て、関連するMCPサーバーを呼び出し、結果をLLM APIに送り返します。LMのハーネスは、結果をフィードバックするために別の特別なトークンセットを使用します。
ここにツール結果、結果、そしてツール結果があります。わかりますね。では、これの何が問題なのでしょうか。ツール呼び出しで使用される特別なトークンは、LMが野生で見たことのないものです。それらは合成トレーニングデータに基づいてツールを使用するように特別に訓練されなければなりません。これは本当に楽しいものです。Grok 4のように、ツール呼び出しで訓練されるように本当に頑張ったモデルがあります。
そして結果として、実際の出力の深いところにツール呼び出し構文をランダムに幻覚し、それをダンプします。だから多くの人がT3 Chatで検索するためにGrok 4を使用しようとし、検索についてのXMLを出力するだけでしたが、正しい形式では行いませんでした。
だから検索ツールをトリガーせず、今彼らは検索が何になるかを伝えるコードを書いているこの面白い見た目の出力を得ているだけです。でも実際にはそれを実行しません。彼らはこれを行うのが常に得意というわけではありません。私が言ったように、Grokはこれで陽気でした。あまりにも多くのツールや過度に複雑なツールをLLMに提示すると、正しいツールを選択したり、正しく使用したりするのに苦労する可能性があります。
その結果、MCPサーバー設計者は、開発者に通常公開するより伝統的なAPIと比較して、大幅に簡素化されたAPIを提示することが奨励されます。一方で、LMはコードを書くことが本当に得意になっています。実際、開発者に通常公開される完全な複雑なAPIに対してコードを書くように求められたLMは、それであまり問題がないようです。では、なぜMCPインターフェースはそれを簡略化する必要があるのでしょうか。コードを書くことと、ツールを呼び出すことは、ほとんど同じことですが、LMは一方を他方よりもはるかにうまく実行できるようです。答えは簡単です。LMは多くのコードを見てきました。多くのツール呼び出しは見ていません。実際、彼らが見たツール呼び出しは、おそらくLMの開発者自身によって構築された作為的なトレーニングセットに限定されています。
一方で、彼らは何百万ものオープンソースプロジェクトから実世界のコードを見てきました。ツール呼び出しでタスクを実行させるLLMは、シェイクスピアを1か月の中国語クラスに通わせて、それで劇を書くように頼むようなものです。
それは単に彼の最高の作品にはならないでしょう。大胆な声明です。あなたが言おうとしていることはわかります。実際には同意しません。どうやらOpenAIも同意しないようです。なぜなら、これの多くのもののHarmonyのフォーマットは、TypeScript構文として関数を定義するだけだからです。それは本当にクールです。知りませんでした。そのように考えたことはありませんでしたが、そう言います。
ええ、これが大好きです。彼らがTypeScript構文として名前空間を定義し、できることとそれがどのように見えるかをすべて示すというアイデアです。実際に本当にクールです。単にカオスなXMLをするのではなく、このプロジェクト全体がほとんどRustとPythonであるにもかかわらず、TypeScriptがここにあります。それは実際に本当にクールです。良い指摘です。ありがとう、Vbits。素晴らしい最初のチャットです。
しかしMCPはそれでも有用です。主に統一されているからです。MCPはツール呼び出し用に設計されていますが、実際にはその方法で使用する必要はありません。MCPサーバーが公開するツールは、実際には添付されたドキュメントを持つRPCインターフェースです。それらをツールとして提示する必要はありません。ツールを取り、代わりにプログラミング言語APIに変えることができます。
しかし、プログラミング言語APIがすでに独立して存在しているのに、なぜそうするのでしょうか。ほとんどすべてのMCPサーバーは、既存のAPIのラップにすぎません。なぜそれらを代わりに公開しないのでしょうか。さて、MCPは他に本当に有用な何かをすることがわかります。APIに接続して学習するための統一的な方法を提供します。
繰り返しますが、これがMCPを良いものにすると同時に、バンドエイドとガムテープの束だと思う理由です。理想的には、サービスまたはシステムについて学習する方法は、コードベースにあるパッケージの型定義を通じてです。
しかし、その方法で行えない場合、自己記述的で使用方法を示すAPIを持つことは、代替手段からの意味のあるステップアップです。AIエージェントは、エージェントの開発者が特定のMCPサーバーについて聞いたことがなく、MCPサーバーの開発者が特定のエージェントについて聞いたことがない場合でも、MCPサーバーを使用できます。これは過去の伝統的なAPIではめったに真実ではありませんでした。
通常、クライアント開発者は自分がどのAPIのためにコーディングしているかを正確に知っている必要があります。その結果、すべてのAPIは基本的な接続性、認可、ドキュメンテーションのようなことができますが、すべて少し異なります。AIエージェントがコードを書いている場合でも、統一性は有用です。
AIエージェントがそれをサンドボックスで実行して、与えられたツールにのみアクセスできるようにしたいと考えています。MCPは、AIコードとは独立した標準的な方法で接続性と認可を処理することで、エージェントフレームワークがこれを実装することを可能にします。また、AIにドキュメントのためにインターネットを検索させたくありません。MCPはそれをプロトコルで直接提供します。しかし、落とし穴があります。
先ほど述べたように、Oは帯域外で処理されます。Oソリューションは全く標準的ではなく、これを少し複雑にします。では、これがCloudflareでどのように機能するかを見てみましょう。Cloudflare Agent SDKを拡張して、新しいモデルをサポートしました。このようなASDKで構築されたアプリがあるとします。Dream textモデルOpenAIシステムメッセージ、あなたの役立つアシスタントメッセージ。2つの数値を足す関数を書いてください。
ツール定義を与えます。コードモードヘルパーでツールとプロンプトをラップして、アプリで使用できます。だからここでシステムとツールの定義を書き、それをコードモードでラップします。だから今、AI SDKのために渡すことができるカスタムシステムとツールがあり、MCPを通じて呼び出す代わりに、コードを通じてそれらのツールを呼び出すことができます。
この変更により、アプリは今、定義したツールへの呼び出しを行うコードを生成して実行し始めます。MCPサーバーも含まれます。非常に近い将来、他のライブラリにもバリアントを導入します。詳細と例についてはドキュメントを読んでください。では、MCPをTypeScriptにどのように変換するのでしょうか。コードモードでMCPサーバーに接続すると、Agent SDKはMCPサーバースキーマをフェッチし、それをTypeScript APIに変換します。ドキュメントコメントなどを含めて、すべてスキーマに基づいています。
だから、Cloudflare Agentsのためにこのように使用するように伝えると、このような型定義を生成します。エージェント実装、ドキュメント出力、エージェントの検索などを取得します。GitHubリポジトリCloud For Agentsの完全なドキュメントファイルを取得します。Cloudflare Agentsに関する一般的な質問に役立ちます。Cloudflare Agentsについて尋ねられたら、常に最初にこのツールを呼び出してください。このエージェントドキュメントの検索があります。
これは興味深いです。なぜなら、これらが連鎖されたときにどれだけ有用かわからないからです。コードがこの情報を取得してから何かをする場合、それをワンショットでどれだけうまくできるかわかりません。しかし少なくとも今は情報を取得するためのコードを書くだけで済み、代わりに再フィードされます。では、サンドボックスでコードを実行しましょう。
接続されたMCPサーバーが持つすべてのツールが提示される代わりに、エージェントには1つのツールだけが提示されます。それは単にTypeScriptコードを実行するものです。その後、コードはインターネットから完全に隔離された安全なサンドボックスで実行されます。接続されたMCPサーバーを表すTypeScript APIを通じてのみ外部世界にアクセスできます。
Cloudflareがこれを正しく行うことを信頼しています。なぜなら、Workersで、V8の上のハックで適切かつ安全に動作するために隔離されたレイヤーで行わなければならなかった膨大な量のことがあるからです。だから、彼らはTypeScriptとJavaScriptコードを非常にうまく隔離する方法を知っています。これを正しく行うことを信頼できる数少ない企業の1つです。彼らがそうしたと確信しています。APIはRPC呼び出しによって支えられており、エージェントループにコールバックします。
そこで、Agent SDKは呼び出しを適切なサーバーにディスパッチします。クールです。サンドボックスコードは、明らかな方法でエージェントに結果を返します。console logを呼び出すことによって。スクリプトが終了すると、すべての出力がエージェントに渡されます。ツールスキーマを提供し、MCPツールに一致する関数を提供し、特別なテキストを出力し、MCPツールを呼び出します。いいですね。そして今、コードモード。
ツールスキーマを提供し、TypeScript APIを提供し、それに対してコードを書き、サンドボックスで実行し、バインディングを呼び出し、それからツールを呼び出します。そして完了です。サンドボックスが鍵となるピースです。また、console logについての面白いことです。モデルコンテキストプロトコルに移動して始め方を見ると、ここでのお気に入りの1つ、MCPサーバーでのログイン。
MCPサーバーを実装するとき、ログの処理方法に注意してください。標準出力ベースのサーバーの場合、標準出力に書き込まないでください。それにはPythonでのprint、JavaScriptでのconsole log、Goでのprint lineが含まれます。標準出力に書き込むと、JSON RPCメッセージが破損し、サーバーが壊れます。素晴らしい標準ですね。標準が大好きでしょう、皆さん。動的ワークロードディング。
ここにコンテナはありません。新しいアプローチには安全なサンドボックスへのアクセスが必要です。繰り返しますが、彼らはV8のアイソレートでこれを行っています。Cloudflareがどのように機能するかについての他のビデオでこれについてたくさん話しました。わかりますね。彼らはこれに適したインフラストラクチャを持っています。コードを直接評価しているように感じますが、実際には安全です。
これまで、Workerが任意のコードを含むアイソレートを直接ロードする方法はありませんでした。すべてのWorkerコードは、CloudflareのAPIを介してアップロードされ、それがグローバルにデプロイされてどこでも実行できるようになりました。それはエージェントに対して望むものではありません。コードがエージェントがいる場所ですぐに実行されることを望んでいます。
繰り返しますが、先ほど話していたこと、特定のリクエストがそのリクエストに固有のコードを実行できるというアイデアは、多くのインフラストラクチャを壊します。ほとんどの情報は、すべてのコードがすでにそのサーバーに接続されているボックスに保存されているバイナリであることを前提としています。
コードがその場で生成される場合、そのランタイム環境について変わることがたくさんあります。Cloudflareはできませんでした。なぜなら、Workers APIを通じて渡されるすべての実行されるコードを必要としていたからです。今、彼らはこれを可能にするためにそれを変更しました。特にWorker loader APIがここでのソリューションであり、env.を呼び出すことができます。
loaderを実行し、多くの異なるキーを返すことができますが、実際のJavaScript定義のようなモジュールも返すことができ、今それらは外部で呼び出され実行されることができます。今これで遊び始めてください。Workerはより良いサンドボックスです。ええ。そして、これらのMCPサーバーは外部で定義されているため、すべてのAPIキーを含めることを心配する必要はありません。
それは、ストリーミングの人生を通じてあまりにも多くのAPIキーを漏洩してきた私のような人にとっては素晴らしいことです。良いものです。このアイデアが好きです。この一般的な世界でもっと探求すべきことがたくさんあると本当に思っています。ここで説明したように、MCPパターンは必ずしも物事を構築する最良の方法ではありません。そして、このような他の形式でMCPの利点が探求されるのを見るのはワクワクします。
Cloudflareチームによる本当にクールな作業です。彼らが行った作業と、彼らが発見したこと、取り組んでいることについて透明性を持っていることについて、KentonとSunilの両方にエールを送ります。これが、私たちがますます学び、これらのものを使ってますます構築するにつれて、業界全体を前進させることを願っています。コンテキストウィンドウを破壊せず、やりたいことすべてに文字通り数十のツールを追加するのではなく、代わりに単に私たちが望むことを行うコードを書く未来。はるかに良いことのように聞こえます。
コードは良いものです。私たちはそれをそれほど恐れるべきではありません。AIが私たちのためにそれを抽象化するからといって、コード自体が価値がないというわけではありません。
そして、これがすでにもっと深く探求されていないことに驚いています。皆さんがどう思うか教えてください。私はMCPに対して厳しすぎるのか、それともこれは実際に可能性のある前進の道なのか。教えてください。そして次回まで、平和を、ナードたち。
コメント