この動画は、AnthropicのModel Context Protocol(MCP)に対する辛辣な批評である。MCPは当初、AIエージェントと外部システムを接続するための標準プロトコルとして提唱されたが、実装において深刻な問題を抱えている。最大の課題は、すべてのツール定義を事前にコンテキストウィンドウに読み込むことで、トークン消費が爆発的に増加し、モデルのパフォーマンスが低下することだ。Anthropic自身が最近のブログ記事で、MCPツールを直接呼び出すよりも、コードを書いてツールを呼び出す方が98.7%も効率的であると認めた。これは本質的に、MCPの設計思想そのものに欠陥があることを示している。動画では、Cloudflareの「コードモード」やTypeScriptベースの実装が、いかにMCPの問題を回避しているかを詳細に解説し、AI業界におけるハイプサイクルと、実際のエンジニアリングニーズとのギャップを浮き彫りにしている。
MCPに対する根本的な疑問
さあ、また別のMCPの動画をやる時が来ました。もし私のMCPに対する見解をご存じない方のために説明すると、これは私がAIがバブルであることを示す最高の例だと考えています。私はMCP関連の観測ツールを作っている会社の方が、実際にMCPで有用なものを作っている会社よりもはるかに多く知っています。新しいものに対してツールレイヤーを構築している人ばかりで、その新しいものを使った製品を構築している人がいないのを見たら、その新しいものはおそらくゴミだということが分かります。
ウェブ3が盛り上がっていた頃のことをまだ覚えています。私はウェブ3向けのOAuthを開発している会社を6社知っていましたが、それが存在することで恩恵を受ける可能性のある会社はたった1社でした。そして今、私たちはMCPと同じ状況にいます。ありがたいことに、人々はそれがかなりひどいものだという事実に気づき始めています。仕様自体がひどいとか、実装がひどいとかいうだけでなく、モデルもそれを使うのが下手なのです。
私は以前、Cloudflareのコードモードについて取り上げました。これは彼らがMCPが悪いと気づき、エージェントにこれらのものを呼び出すコードを書かせることで解決したというものでした。すべてを巨大なコンテキストの塊として詰め込んで、すべてをクソみたいに動かすのではなく、です。そして、この仕様を作った当の本人である私たちの友人Anthropicも、同じことに気づき始めているようです。なぜなら、彼らはちょうど新しい記事を書いたからです。「MCPでのコード実行、より効率的なエージェントの構築」というタイトルです。
この記事をどのように読むかによって、彼らがMCPは良いプロトコルではないと認めていると見ることができます。なぜなら、MCPはモデルをより愚かで悪くする大量のクソみたいなコンテキストを追加することを要求するからです。モデルはより多くのツールを与えられても賢くなりません。本当に良いツールの小さなサブセットを与えられた時に賢くなるのです。
そして、MCPはその考え方を奨励していません。MCPは500以上のツールをモデルに追加することを奨励し、その結果、何もクソみたいに機能しなくなります。でも、本当によく機能するものを知っていますか? 今日のスポンサーです。
効率的なデプロイの重要性
コードを書くことはこれまでになく簡単になりましたが、実際にそれをホスティングしてデプロイすることは、これまでになく面倒になっています。特に、常にクラウド間を移動していて、これらの新しい派手でクールでモダンなツールではあまりサポートされていないスタックを使っている場合はなおさらです。
でも、あなたを助けてくれる人がいます。Savala、この会社はホスティングを理解しています。私が思うことを伝えることもできますが、むしろ彼ら自身の顧客を引用したいと思います。Savalaを使えば、稼働時間やインフラ管理について心配する必要がなくなります。単純に動作します。もし今日新しいプロジェクトを始めるなら、最初からSavalaを選ぶでしょう。
それで、本当に高いんですよね? いいえ、違います。彼らにとって、Savalaを使うことは以前使っていたスタックよりも78%安いのです。そして、それを使い始めると理にかなっています。彼らはサーバーの立ち上げと停止を非常に簡単にしました。ここに私が現在Savalaにデプロイしているたくさんのサーバーがあります。新しいものを立ち上げ、GitHubにリンクし、デプロイ用のパイプラインを作成するのは非常に簡単です。データベースを立ち上げるのも超簡単です。
ここをクリックして、データベースを作成をクリックし、使いたいものを選択すれば、今度は私の他のすべてのものに直接接続されたデータセンターにデプロイされます。アプリケーションを見ると、さらにクールになります。これは私のSub Nerdsのプロダクションデプロイメントで、GitHubリポジトリにリンクされています。ほぼすべての人がそうすべきように、DDoS保護のためにCloudflareを前面に配置しています。
しかし、Cloudflareをもっと活用したい場合、例えばCDNとして使ったり、エッジでデータをキャッシュしたりしたい場合は、設定を開いて有効にします。これは、静的アセット用のCDNを有効にするための単一のクリックトグルです。このタイプのことをこれほど簡単にしたサービスは今まで使ったことがありません。デプロイについてストレスを感じるのに疲れていて、無料で50ドルのクレジットが欲しい場合は、今すぐsoy.link/savalaで入手してください。
Anthropicの驚くべき告白
私は実際にこれについて掘り下げるのが本当に楽しみです。なぜなら、私は密かに心の底でMCPのようなものが機能することを望んでいるからです。しかし、現在の実装は単に機能していません。私はまだその能力に感銘を受けたものに出会っていません。本当にクールなものはいくつかありますが、私の経験では実際に有用なものは一つもありません。
彼らがここでそれらを有用にすることに成功したかどうか見てみましょう。「MCPでのコード実行。より効率的なエージェントの構築」。直接的なツール呼び出しは、各定義と結果に対してコンテキストを消費します。エージェントは、ツールを呼び出すためにコードを書くことでより良くスケールします。MCPでどのように機能するかは次のとおりです。さあ、来ました。ありがとう、Anthropic、私がずっと正しかったことを認めてくれて。
関係のないものでシステムプロンプトを詰まらせるのは意味がありません。モデルがそれをうまく行うように訓練されるだけのデータが十分にないのです。彼らが何をうまくやるか知っていますか? たくさんの例があるからです。コードを書くことです。Anthropicのブログの公式記事でこの行を見るのは本当に面白いです。
彼らは自分たちの仕様が、彼らが構築しているもの、つまりAIモデルにとって機能しないことを認めているのです。面白すぎます。彼らが実際にこれをどのように実装したのか見てみましょう。興味があります。
MCPの根本的な設計上の欠陥
Model Context Protocolは、AIエージェントを外部システムに接続し、その過程でそれらをより愚かにするためのオープンスタンダードです。エージェントをツールやデータに接続することは、従来、各ペアリングごとにカスタム統合を必要とし、断片化と重複した努力を生み出し、真に接続されたシステムを拡張することを困難にしていました。
もしこの問題を解決しようとして、モデルを物事に接続するための汎用的なソリューションを作ろうとしているなら、おそらくそれらの接続レイヤーで必要なものを処理できることを確認したいでしょう。例えばOAuthのようなものです。MCPにはOAuthの概念がまったくないことを知っていましたか? まったくです。今では18の実装があります。なぜなら、MCPで適切なハンドシェイクを行う方法がないからです。
最善の方法は、署名されたパラメータのようなものを含むカスタムURLをハードコーディングして、それが機能するようにすることです。実際にクレイジーです。私はこの標準が本当に嫌いです。ああ、MCPは必要なものの3分の1を行う普遍的なプロトコルを提供します。開発者はエージェントにMCPを一度実装し、それから機能させるために5つの追加レイヤーを実装します。
そして、統合の全体的なエコシステムのロックを解除します。2024年11月にMCPをローンチして以来、採用は急速に進んでいます。有用なものを作ろうとしている人ではなく、あなたに何かを売ろうとしている人によってです。コミュニティは何千ものMCPサーバーを構築しました。SDKはすべての主要なプログラミング言語で利用可能であり、業界はエージェントをツールやデータに接続するための事実上の標準としてMCPを採用しました。そして、データを安全にアクセス可能にする方法のための数十の標準も実装しました。
今日、開発者は数十のMCPサーバーにまたがる何百または何千ものツールにアクセスできるエージェントを日常的に構築しています。しかし、接続されたツールの数が増えるにつれて、すべてのツール定義を事前にロードし、中間結果をコンテキストウィンドウを通じて渡すことは、エージェントを遅くし、コストを増加させます。それはまた、彼らをはるかに愚かにします。
なぜそれを見逃したのか不思議です。このブログでは、コード実行がどのようにエージェントがMCPサーバーとより効率的にやり取りできるようにするか、より少ないトークンを使用しながらより多くのツールを処理できるようにするかを探ります。ツールからの過度なトークン消費は、エージェントを効率的でなく、効果的でなくします。MCBの使用がスケールするにつれて、エージェントのコストとレイテンシを増加させる可能性のある2つの一般的なパターンがあります。
1つ目はツール定義によるコンテキストウィンドウの過負荷で、2つ目は中間ツール結果による追加トークンの消費です。まず、ツール定義の過負荷についてです。ほとんどのMCPクライアントは、すべてのツール定義を事前にコンテキストに直接ロードし、直接的なツール呼び出し構文を使用してそれらをモデルに公開します。
ほとんどというよりは、これはAnthropicのすべてのビルドを含みます。だから、そうです、これらのツール定義は次のようになるかもしれません。ここにツール定義があります。G Drive.get document。説明はGoogle Driveからドキュメントを取得します。パラメータはドキュメントIDで、これは取得するドキュメントのIDである必須の文字列です。フィールドもあり、これは返すべき特定のフィールドを指定するオプションの文字列です。これはタイトル、本文コンテンツ、メタデータ、権限などを含むドキュメントオブジェクトを返します。またはこのSalesforce更新レコード、オブジェクトタイプとレコードIDと追加しているデータがあり、確認付きの更新されたレコードオブジェクトを返します。クールなツールの説明がもっと占めています。
ここで1つ指摘したいのは、G Driveドキュメントの場合、これはすでにドキュメントIDを持っていることを要求します。そのドキュメントIDをどこで取得するのでしょうか? ユーザーがそれを渡すのでしょうか? いいえ。おそらく、探したいものを検索するために使用するMCP定義であるG drive.find documentツールがあります。そして、それを見つけたら、G Drive.get documentに渡すIDが手に入ります。そして今、あなたは何の理由もなく複数回の往復を行い、すべてをより困難で遅くし、たくさんのトークンを無駄にしました。なぜなら、ツールが多すぎるからです。
ツールの説明は、より多くのコンテキストウィンドウスペースを占有し、応答時間とコストを増加させます。エージェントが何千ものツールに接続されている場合、リクエストを読む前に数十万トークンを処理する必要があります。その通りです。そして2番目のポイントは、中間ツール結果が追加のトークンを消費するということです。
繰り返しになりますが、ここではドキュメントを取得してからSalesforceを更新しています。これに対してより面白い例が欲しいです。G drive.get documentの代わりに、G drive.find document content videos taxesをやってみましょう。これは、それを持っているかもしれないドキュメントの配列を返します。ドキュメント1、ドキュメント2、ドキュメント3などです。
次に、このコンテンツが欲しいので、さらに多くのツール呼び出しを行います。それはあなたにとって有用です。だから次に行うのは、これらのそれぞれに対してG drive.get documentを呼び出すことです。そして、これらのそれぞれはモデルに送信される追加のメッセージであり、それは完全に別個のリクエストであり、これらのそれぞれがコンテキストに追加されます。
だから、これがコンテキストウィンドウを20トークンとすると、これは追加の20で、このリクエストは40になります。なぜなら、以前のすべてを含める必要があるからです。これは60になります。以前のすべてを含める必要があります。これは80になります。非常に明確にするために、追加のツール呼び出しはすべて、以前のすべてのコンテキストを運んでいます。だから、ツールが呼び出されるたびに、全体の履歴が入力トークンとして再ヒットされています。
クレイジーです。非常に多くの無駄です。非常に多くのコンテキストを使用します。非常に多くのトークンとお金を燃やします。そして、入力用のキャッシングが適切に設定されていない場合、あなたは単に現金を燃やしているだけです。最悪です。こんなに悪い実装です。並列ツール呼び出しが必要です。これを防ぐためのより良いツール設計が必要です。
または、コードを書くこともできます。なぜなら、これがドキュメントを見つけるためのコードを書き、それからそれぞれに対してこれを行い、単一のツール呼び出しですべての結果を返すだけだった場合、それはずっと少ないクソです。Anthropic自身の言葉では、すべての中間結果はモデルを通過する必要があります。
コンテキスト効率の問題
この例では、完全な通話トランスクリプトが2回流れます。2時間の営業会議の場合、追加で50,000トークンを処理することを意味する可能性があります。さらに大きなドキュメントはコンテキストウィンドウの制限を超える可能性があり、それはフロー全体を完全に壊すでしょう。大きなドキュメントや複雑なデータ構造では、モデルはツール呼び出し間でデータをコピーする際に間違いを犯す可能性が高くなります。
ここに彼らの小さな図があります。この図はちょっとクソです。MCPクライアントはコンテキストウィンドウとして機能します。システムプロンプト、ツール定義、ユーザーメッセージがあります。ユーザーメッセージはモデルに行きます。モデルはアシスタントメッセージとツール呼び出しで応答します。
それからそのツール呼び出しを行い、結果を取得し、新しいメッセージを実行するためにモデルに送り返す必要があります。しかし、ここで見るべき部分があります。これがLLMに送信されているデータの量です。見てください、このデータで始まり、今ははるかに多くなっています。追加のツール呼び出しはすべて、LLMが処理しなければならない追加データを積み重ねており、それによってそれを遅くし、愚かにし、コストを増加させています。
MCPクライアントはツール定義をモデルのコンテキストウィンドウにロードし、各ツール呼び出しと結果が操作間でモデルを通過するメッセージループを調整します。その通りです、ツール呼び出しが応答するたびに、完全に新しいメッセージ生成、LMの完全に新しい実行を行います。素晴らしいです。
MCPでのコード実行はコンテキスト効率を改善します。エージェントのためのコード実行環境がより一般的になってきているので、解決策はMCPサーバーを直接的なツール呼び出しではなく、コードAPIとして提示することです。うわあ。コードを書くことが、必要なものの半分を持っていないクソみたいな汎用ラッピングレイヤーを作るよりも効果的であることが分かります。誰が思っただろうか?
エージェントはその後、MCPサーバーとやり取りするためのコードを書くことができます。このアプローチは両方の課題に対処します。エージェントは必要なツールのみをロードでき、結果をモデルに渡す前に実行環境でデータを処理できます。これを行うにはいくつかの方法があります。1つのアプローチは、接続されたMCPサーバーから利用可能なすべてのツールのファイルツリーを生成することです。ここにTypeScriptを使用した実装があります。
ここでも、実行したい可能性のあるさまざまなことがあるTypeScriptファイルがあり、これらすべてのもののタイプ定義があります。そして、モデルはこれらを任意のコードプロジェクトで行うように検索して、実行したいタスクを実行するために必要な特定のものを見つけることができます。各ツール呼び出しはファイルに対応しています。
ここにはクライアントからcallm MCPツールをドキュメント入力を取得するためのインターフェース、応答のためのインターフェース、そして関数としてのGoogle Driveがあります。上記のGoogle DriveからSalesforceへの例は、このコードになります。だから、その例を示すために、なぜなら私はそれをいじり回したからです。最初のツール呼び出しは、すべてのこのコンテンツを持つこのドキュメントを取得し、それからSalesforceのレコードを取得したデータで更新します。
代わりに、G DriveクライアントとSalesforceクライアントをインポートするコードを書き、トランスクリプトをG drive.get document呼び出しから待機したものとして定義し、それから入れます。これは読みにくいかもしれません。理由は何でもありません。わかります、理由は分かります。Anthropicはフロントエンドコードがあまり得意ではないので、彼らのブログには構文ハイライトがありません。
面白いです。とにかく、アイデアは分かるでしょう。これは単なるTypeScriptコードです。Pythonの人々にこの全体のエコシステムを定義させることがこの全体を破壊するつもりであることの証明として、MCPは仕様だと言いたいくらいです。本当にひどいです。MCPは非常にPython的な仕様です。それはシンプルでエレガントであろうとするあまり、肉を入れるのを忘れています。
TypeScriptははるかに妥協の少ない言語です。そして、それが私を含むTypeScript開発者がこれを採用しようとした時に、頭を壁に突っ込みたくなった理由です。そして今、私たちが引き継いで、これがコードとしてより良いだろうと示したところ、彼らは耳を傾けています。例がPythonではなくTypeScriptを使用している理由があります。
エージェントは、Google DriveやSalesforceのような利用可能なすべてのサーバーを見つけるために/serversディレクトリをリストアップし、それから必要な特定のツールファイル、例えばget document.tsやupdate record.tsを読んで各ツールのインターフェースを理解することで、ファイルシステムを探索してツールを発見します。これにより、エージェントは現在のタスクに必要な定義のみをロードできます。
これにより、トークン使用量が150,000トークンから2,000トークンに削減されました。時間とコストの節約は98.7%です。MCPが正しい標準であると主張できるのに、クソみたいなコードジェネレーションソリューションを代わりに行うことで無駄の99%を節約できるとは、どうしてそんなことができるのでしょうか。
これは私にとって非常に面白いです。MCPの作成者は、クソみたいなTypeScriptコードを書くことが、彼らが書いた仕様を使うよりも99%効果的であると私たちに言っているのです。これは私にとって非常に面白いです。ああ、彼らはCloudflareのことまでリンクしていることが分かります。それが彼らをこの認識に目覚めさせたのだと思います。
Cloudflareは同様の発見を公表し、MCPのコード実行をコードモードと呼んでいます。核心的な洞察は同じです。LMSはコードを書くのが得意であり、開発者はMCPサーバーとより効率的にやり取りするエージェントを構築するためにこの強みを利用すべきです。
MCPでのコード実行の利点
では、MCPでのコード実行の利点は何でしょうか? MCPでのコード実行により、エージェントはオンデマンドでツールをロードし、モデルに到達する前にデータをフィルタリングし、単一のステップで複雑なロジックを実行することで、コンテキストをより効率的に使用できるようになります。このアプローチには、セキュリティと状態管理の利点もあります。
例えば、ドキュメント全体をLLMにダンプしてから、Anthropic、Google、AWS、またはモデルをホスティングしている誰であれ、私たちの友人に送信する必要はありません。なぜなら、そのすべてがコードが実行されているサンドボックスの中で起こっているだけだからです。それは全体のドキュメントをロードするよりもはるかに良いです。
ここでこのドキュメントを取得してからSalesforceに送信していたことを思い出してください。これは、そのGoogle Driveドキュメントの全内容をコンテキストにロードする必要があり、モデルがそれをSalesforceに転送する際に何かをタイプミスしないことを願わなければならないことを意味します。または、単にコードを書くこともできます。
文字通り5行程度で変数を取得し、それをメモリに保持し、どこにでもホストされている可能性のあるモデルのコンテキストではなく、サンドボックスに保持し、それから更新したいものを更新できます。今、このドキュメントの内容はコンテキストの一部になることはありません。モデルによって見られることはありません。モデルがそれに触れていないからです。モデルはドキュメントの中に何があるかを知る必要はないからです。
それで何をすべきかを知る必要があるのです。それが全体のクソみたいなポイントです。プログレッシブディスクロージャーのような他の利点もあります。モデルはファイルシステムをナビゲートするのが得意です。ツールをファイルシステム上のコードとして提示することで、モデルはすべてを事前に読むのではなく、オンデマンドでツール定義を読むことができます。クレイジーなことに、MCPにはプログレッシブディスカバリーの概念がありませんでした。
必要な時にMCPを介してより多くのコンテキストを提供する方法はありませんでした。私は人々が、完了されるタスクに応じてどの異なるエージェントを使用するか、それらのサブエージェントのための異なるツールのサブセットを選択する別のモデルを持つような、クレイジーなことをしているのを見ました。仕様を使用可能にするための全体的なオーケストレーションレイヤーのクソです。
コードを書く方が簡単であることが分かります。クレイジーです。関連する定義を見つけるためにツールを検索するツールをサーバーに追加できます。例えば、上記で使用された仮想のSalesforceサーバーで作業する場合、エージェントはSalesforceを検索し、現在のタスクに必要なツールのみをロードします。
ツールを検索するツールに詳細レベルパラメータを含めることで、エージェントは必要な詳細レベルを選択できます。名前のみ、名前と説明、またはスキーマの完全な定義のように。これもエージェントがコンテキストを節約し、効率的にツールを見つけるのに役立ちます。
ここで私の友人のTreyについて少し指摘したいと思います。彼らはこれを修正したかもしれませんが、確信が持てず、確認する気もありません。しかし、私がそれで遊んでいて、出力の品質があまり良くないことに気づいた時、彼らのエージェントがアクセスできるツールを分析することにしました。彼らはソロに何が起こるかを決定するトップレベルのエージェントを持っており、それはコーディングと構築のための別個のエージェントを呼び出します。ソロコーディングエージェントとソロ開発ビルダーエージェントがあり、これらは独自のツールセットを持っており、彼らがアクセスできるツールは興味深いです。
ここでそれらのいくつかを見ることができます。これらがいくつあるか見えますか?これらのダッシュすべてを見てください。ソロコーディング環境エージェントには23のツールがあります。これには、ファイル管理関連のことを行うための7つの別個のツール、コマンドを実行するための3つ、そして私のお気に入り、Superbaseのための3つが含まれています。
私はSuperbaseを使っていません。アカウントすら持っていません。Superbaseで何も構築したことがありません。しかし、Treyを使用すると、送信するすべてのリクエストには、私が使用していないもののためのこのコンテキストが含まれています。ああ、これはひどいです。どうしてこんなところに行き着いて、すべてが大丈夫だと思ったのでしょうか?
これが、AIブラザーがソフトウェアを構築していないか、ソフトウェアの世界がどのように機能するかを理解していないことについて私が不平を言う時です。これが私が話していることです。これらのことはすべて明らかに間違っていて愚かです。見るだけで気づきます。そして、ありがたいことに、十分な数のエンジニアが今AIツールを使用しており、Cloudflareのようなこれらのことについて不平を言っています。
CloudflareはLLMとソフトウェア開発のどちらが得意だと思いますか? 彼らのダッシュボードをたくさん使っている場合、どちらなのか混乱するかもしれません。ダッシュボードは荒削りだからです。しかし、Cloudflareのインフラを使用したことがある場合、彼らがコードを書くのが得意であることを知っています。彼らがインフラとエンジニアリングが得意であることを知っています。彼らはこれを非常に人気のあるものとアイデアにしなければなりませんでした。
そして私は、Anthropicにこれらの事実を認識させるために、これらのことについてのビデオを作らなければなりませんでした。強い意見を持っているからです。では、ツールを使用したコンテキスト効率について話しましょう。
大規模なデータセットを扱う場合、エージェントは結果を返す前にコードでフィルタリングおよび変換できます。10,000行のスプレッドシートを取得する場合、give.get sheetは10,000行を返します。それらがすべてコンテキストにあった場合、頑張ってください。楽しんでください。または、それらがモデルに到達する前にコードで処理できます。保留中の注文は、ステータスが保留中の任意の行になります。
そして今、私たちはこれらすべてを持っています。クール。これらの人が本当に優れたエンジニアであることが分かりますか? JavaScriptで配列構文を使用してオブジェクトから選択している人を最後に見たのはいつか思い出せません。PythonがAnthropicの彼らの脳を腐らせました。とにかく、この例では、エージェントは以前の10,000行ではなく、5行だけを見る必要があります。
同様のパターンは、集計、複数のデータソース間の結合、またはコンテキストウィンドウを肥大化させることなく特定のフィールドを抽出するために機能します。Google DriveとSalesforceの2つの場所にデータがあり、両方に存在するすべての人を見つけたいと想像してください。
ツールを使用してモデルにそれを行うように依頼すると、Google Driveからすべてのデータを取得します。Salesforceからすべてのデータを取得し、それからそのすべてをコンテキストに入れて、干し草の中の針のように不正確な答えにたどり着きます。または、それを行うコードを書くこともできます。IDをマッチさせて、マッチするすべてを返します。当然、それははるかに良いです。
let found equals false。while not found、const messages equals await。Slack.get channel history。found equals messages summ.ext.includes deployment complete。if not found、await new promise set timeout R5000。非常に良いコードです。それは私を全く怖がらせません。このアプローチは、エージェントループ全体でMCPツール呼び出しとスリープコマンドを交互に実行するよりも効率的です。
さらに、実行される条件ツリーを書き出すことができることで、最初のトークンのレイテンシも節約されます。モデルがif文を評価するのを待つのではなく、エージェントはコード実行環境にこれを行わせることができます。ああ、そうです、クレイジーです。JavaScriptは遅いですが、実際にはLLMに100,000トークンを通過させて、うまくいけば正しい答えを推測させるよりも速いです。そしてクレイジーです。
これは誰にとっても意味がないことは分かっています。コードは決定論的です。だから、それがコードを書く時、50%の確率で幻覚を起こすことはありません。単にコードを書き、コードは単にそのことを行います。生成するトークンが多ければ多いほど、コンテキストにあるトークンが多ければ多いほど、扱う幻覚が多くなります。
JavaScriptは奇妙ですが、そもそもそれを設計するために発生しなければならなかった幻覚の量と同じくらい、物事を実行する際には比較的一貫性のある言語です。奇妙な文字列操作のことをしていない限り。そうです。それからプライバシー側があります。私は少し前にこれに触れました。
エージェントがMCPでコード実行を使用する場合、中間結果はデフォルトで実行環境に留まります。このようにして、エージェントは明示的にログまたは返すものだけを見ます。つまり、モデルと共有したくないデータは、モデルのコンテキストに入ることなく、ワークフローを通過できます。さらに機密性の高いワークロードの場合、エージェントハーネスは機密データを自動的にトークン化できます。
例えば、スプレッドシートから顧客の連絡先データをSalesforceにインポートする必要があると想像してください。エージェントはこのようなコードを書きます。ここでは、これらすべてに対してSalesforce更新レコード呼び出しがあります。これは非常に良いコードで、絶対にブロッキングしていなくて、本当に遅くなるつもりはありません。この記事のTypeScriptの品質は、それが構文ハイライトされていないという事実とほぼ同じくらい面白いです。
分かりました。クイズです、視聴者の皆さん。このコードがなぜ必要以上に遅いのでしょうか? 答えません。もう分かるはずです。MCPクライアントはデータを傍受し、モデルに到達する前にPIIをトークン化します。だから、ここでデータが返された時、私たちはすべてのデータを難読化します。
メール1、電話1、名前1、メール2、電話2、名前2のように変更します。そうすることで、それらを識別して両者間で物事を渡すことができますが、データはモデルをホスティングしている会社に届く必要がなくなります。当然です。はるかに良いです。考えてみれば、ここのTreyのようなツールを使用している場合、テーブル取得ツール、それはPIIを提供していません。なぜなら、それは存在するテーブルとその定義についてのデータだからです。
しかし、ここにデータベース内のすべてのデータにアクセスできるようにモデルに与えた行取得ツールがあった場合、そこにあるものはすべて仮想的にコンテキストに含まれる可能性があり、したがってAnthropicやOpenAIまたは他のホスティング元に送信される可能性があります。これはそれをしなくて済む最も簡単な方法です。データが別のMCPツール呼び出しで共有される場合、MCPクライアントでのルックアップを介してトークン解除できます。
実際のメールアドレス、電話番号、名前はGoogle SheetsからSalesforceに流れますが、モデルを通過することはありません。それにより、エージェントが誤って機密データをログに記録したり処理したりすることを防ぎます。これを使用して決定論的なセキュリティルールを定義し、データがどこからどこに流れることができるかを選択できます。素晴らしいです。
また、状態の永続性もあります。これはMCP状態で本当に厄介なことの1つです。LMSには状態がありません。データベースは単なる状態です。そこのギャップのバランスを取るには多くのクソが必要です。コードでは、状態はコード内に留まります。メモリにある限り、それは変更されていません。そして、将来のためにそこに留まりたい場合は、ファイルを書くことができ、今それがそこにあり、コンテキストにあることを心配する必要はありません。
だから、ここではSalesforceから取得したリードからこのCSVデータを書きます。ファイルに書き込み、後でそれを取得できます。素晴らしいです。エージェントは独自のコードを再利用可能な関数として永続化することもできます。エージェントがタスクのための動作するコードを開発したら、将来の使用のために実装を保存できます。だから、シートをCSVとして保存できるようにしたい場合、この関数を書いて保存し、今度はいつでも呼び出せるスキルとして持つことができます。
これは、スキルの概念、つまり特殊なタスクでパフォーマンスを向上させるための再利用可能な指示、スクリプト、リソースのフォルダーと密接に結びついています。これらの保存された関数にskill.mmdファイルを追加することで、モデルが時間の経過とともに参照して使用できる構造化されたスキルが作成されます。そして、これによりエージェントは、最も効果的に機能するために必要な足場を進化させながら、より高いレベルの能力のツールボックスを構築できます。
これはMCPを再発明していませんか? はっきりさせてください。このAPIがあるとしましょう。このAPIについてモデルに伝えることができますが、それをすべての単一のものに対して行う必要があります。だから、これを標準化したいのです。標準が必要です。だから、MCPツールを作成します。これには、このエンドポイントを呼び出すために必要なすべての定義と他のすべてのものが含まれます。
しかし、それから、ああいけない、ツールが多すぎることに気づきます。だから、これをSDKインターフェースSalesforceに変更するという非常に明白なことをします。これが私たちがここで話していることです、コードのことです。そして今、これを行ったところ、このコードは有用です。保存すべきです。そして今、このスキルSalesforceユーザーデータ取得があります。
そして、これらは文書化されるべきです。そして、skill.mdファイルを取得します。Salesforceユーザーデータ取得の使い方。そして、ほぼ始めた場所に戻ります。そして、このループがAIの世界で同じ15のものを何度も何度も再発明し続けることが無限に続かないと確信しています。それは絶対に起こらないでしょう。
これが皆が話している本当のエージェンティックループです。私は正気を失いそうです。そうですね、実際にこの点までは気に入っていました。コード実行は独自の複雑さを導入することに注意してください。エージェントが生成したコードを実行するには、適切なサンドボックス、リソース制限、監視を備えた安全な実行環境が必要です。
Daytonaがこのビデオのスポンサーかどうかは分かりません。後で判断します。しかし、Daytonaは私が知る限り、これを行う唯一の正気の方法です。この人たちはこれらのものをデプロイすることをはるかに簡単にしました。AIが生成したコードを安全に実行する安価な方法が欲しい場合は、Daytonaを使うだけです。彼らは私にこれを言うためにお金を払ってすらいません。
以前に払ってくれたかもしれません。これについては違います。私はこの人たちが好きです。彼らは一緒に働くのが本当に素晴らしいです。彼らは本当に楽しく、この側面をよく理解しています。私はこれを解決された問題と見なすことまで考えるでしょう。少なくとも、MCPよりもはるかに解決されています。
これらのインフラ要件は、運用上のオーバーヘッドとセキュリティ上の考慮事項を追加します。直接的なツール呼び出しはMCPでの直接的なツール呼び出しがセキュリティを持っていないため、これらを回避します。なぜなら、OAuthがないからです。コード実行の利点は、削減されたトークンコスト、低いレイテンシ、改善されたツールの構成です。これらの実装コストと比較検討されるべきです。
いいえ、これはクソみたいなでたらめです。これは絶対的なでたらめです。私が見たすべてのMCPの実装は、いくつかの環境変数を持つ基本的なクソみたいなサンドボックスよりもはるかに安全ではありません。これは妄想です。神様、この記事はこの行まで本当に良かったです。ここから下は崩壊しました。
MCPは基礎的なプロトコルを提供します。MCPは、エージェントが多くのツールやシステムに接続するための基礎的なプロトコルを提供します。しかし、あまりにも多くのサーバーが接続されると、ツール定義と結果が過度のトークンを消費し、エージェントの効率を低下させる可能性があります。
ここでのこれらの問題の多く、コンテキスト管理、ツールの構成、状態の永続性は新しいように感じますが、ソフトウェアエンジニアリングからの既知の解決策があります。コードエグゼキューションはこれらの確立されたパターンをエージェントに適用し、より効率的にMCPサーバーとやり取りするために使い慣れたプログラミング構造を使用させます。このアプローチを実装する場合は、あなたの発見をMCPコミュニティと共有することをお勧めします。
高い地位にいるエンジニアがもっと必要です。これが、LLMの人々に開発者として使用しなければならないものを作らせた時に起こることです。開発者が開発者が使用するものを定義すべきです。そして、それらにそれをさせないなら、結局彼らがずっと正しかったことに気づくでしょう。
結論
誰かがAIが開発者を置き換えるつもりだとあなたに言う時はいつでも、これを見せてください。私たちが大丈夫であるために必要なすべての証拠はこれだけです。これは、LLMに、そしてさらに重要なことに、LLMの人々にAPIを設計させた時に起こることです。非常に役に立たないものを手に入れ、その過程で全体の車輪を複数回再発明します。そして私はMCPを本当に使い続けるつもりはありません。
これがあなたが理由を理解するのに役立つことを願っています。皆さんがどう思うか教えてください。MCPツールをどのように実行しているか教えてください。それでは次回まで、平和を、オタクの皆さん。
コメント