Anthropicが提供するモデルコンテキストプロトコル(MCP)は、当初から深刻な設計上の欠陥を抱えている。MCPはツール定義を常にコンテキストに含める必要があり、数万トークンもの無駄なデータがすべてのリクエストで送信される。これによりモデルは遅く、高コストで、かつ精度が低下する。Anthropicはこの問題に対処するため、ツール検索機能、プログラマティックツール呼び出し、ツール使用例という3つの新機能を導入した。しかしこれらは根本的な設計ミスに対する応急処置に過ぎず、複雑さを増すばかりである。特にプログラマティックツール呼び出しでコードを介してツールを実行する手法は理にかなっているが、MCPという標準自体が本質的に欠陥を抱えている現実は変わらない。結果として、単純なツール呼び出しを実現するために、データ、MCPサーバー、定義、検索、サンドボックス環境、Pythonコードという多層構造が生まれ、開発者にとっては悪夢のような複雑性となっている。
MCPの根本的な問題点
私はできるだけ、バズワード的で煩わしく、あまり価値を感じないことについては話さないようにしています。だからこそ、モデルコンテキストプロトコル、つまり皆さんがご存知のMCPについての動画は1本しか作っていません。私はこの標準にそれほど価値を見出していないんです。そしてそれが引き起こす多くの問題も見えています。
だからこそ、MCPがいかにひどいか、そしてAnthropicがそれに同意し始めているという動画を作ったわけです。その動画は予想以上に良いパフォーマンスを見せました。そしてどうやら私だけがそう感じているわけではないようです。なぜならAnthropicは3倍の力を注いでいるからです。彼らはClaudeの開発者プラットフォームに新しい高度なツール使用機能を導入したばかりです。
通常、「高度」という言葉は、何かをより複雑に、詳細に、あるいは高機能にすることを意味しますが、この場合の「高度」は、それを何とか動作させようとしていることを意味しているようです。これはMCP内に存在するすべての問題から、現在提案されている奇妙な回避策、そしてAnthropicがエンジニアリングについてどう考えてきたか、あるいはあまり考えてこなかったかについて、楽しい深掘りになるでしょう。
そしてこれは、ステータスコード200としてエラーを送信することを好む企業であり、それによって数十社、いや数百社もの企業の実装を破壊してきました。ですから、彼らのこれらのエンジニアリング施策の実装は、きっと良いものになるでしょう。そうですよね。きっと。この件で誰かが私のセラピー代を払わなければならなくなりそうです。では、今日のスポンサーから短いメッセージを聞きましょう。
スポンサーメッセージ
AIが私たちの開発ワークフローのどこに適合するかについて、多くの良い議論があります。エディター内にあるのが良いのか。チケットのトリアージに使うのが良いのか。コードをすべて書き直してもらうのが良いのか。これらすべてについて議論できますが、議論の余地がないものが1つあります。AIはコードレビューにおいて信じられないほど優れているということです。
何に取り組んでいるか、どう構築しているかは関係ありません。時々そのコードをAIにチェックさせて、変更が意味をなしているか確認させないなら、自分の時間だけでなく、同僚の時間も大量に無駄にしているのです。同僚にとって不公平です。まだレビューしていないランダムなPRを送りつけて、人間があなたが見逃したすべてのことを指摘し、長い往復のループを経なければならないなんて。あるいは、Grapileを使えばいいんです。
本気で言っていますが、AIコードレビューは私のチーム運営の方法を変えました。PRを提出して、すぐに修正すべき小さなことをいくつか指摘してもらい、チームメイトに迷惑をかける前にそれらの変更を行えるという事実が、私をはるかに一緒に働きやすい人間にしてくれました。
PRをレビューして、誰でも気づくべき3つのランダムな小さなことに気づいたけれど、コードをレビューされている人がもう寝ている、という経験が何回ありますか。翌日まで待たなければならず、ループ全体を繰り返さなければなりません。その結果、コードレビューが実際の変更よりも長くかかることが非常に多いのです。
人間がレビューしたがらず、ただそこに置かれているPRがどれだけあるか考えてみてください。Grapileのようなツールがあなたのためにスムーズにしてくれると、人間によるレビューははるかにスムーズになります。どんな感じか見てみたいなら、私のオープンソースリポジトリをチェックしてください。
すべてで使っています。さて、ここにGrapileがこのPRに残したレビューがあります。SnitchBench AI SDKを最新バージョンに移行し、他にもたくさんのランダムな変更を行っているところです。変更内容の要約を残してくれます。信頼度スコアを提供してくれますが、これが大好きになりました。もう4未満だとマージしません。そしてこれが私を多くのトラブルから救ってくれました。
各ファイルごとに信頼度スコアを残してくれます。これは非常に役立ちます。なぜなら、indexというファイルが信頼度に欠ける場所だと分かるからです。他はすべて問題ありません。そしてこれは、正直なところ自分で気づきたかったことを指摘してくれたものです。
AIコード関連の動画を撮影しているときに、楽しいやり取りがありました。というのも、これを見せてくれて、その結果このフィードバックから何かを学んだからです。ワンクリックでCursorで修正できるボタンまで提供してくれて、変更を行うためのプロンプトがすでに入力された状態でCursorに連れて行ってくれます。見てください。PRのブランチにも切り替えてくれます。すごくクールです。
Grapileは多くの時間を費やすものではありません。GitHubの中に存在していて、他に何もする必要がないのです。GitHubでコードレビューをしていてGrapileを使っていないなら、試してみてください。きっと驚くと思います。今すぐsoyv.link/grapileでチェックしてください。
Anthropicの新機能発表
Claude開発者プラットフォームに高度なツール使用機能を導入します。彼らはClaudeがツールを動的に発見し、学習し、実行できる3つのベータ機能を追加しています。これが鍵です。動的に発見し、学習し、実行するということです。
MCPには多くの問題があります。最大の問題の1つは、すべてのMCPツールをコンテキスト、つまりシステムプロンプトのようなものに追加しなければならないことです。モデルに「これがあなたができることすべてと、その方法です」と伝えなければなりません。
これは、たくさんのツールを渡していることに気づくまでは問題なさそうに聞こえます。例えば、数万行のコンテキストを持つSupabase MCPを使用していて、その使用方法を説明しているとします。そして、フロントエンドの変更を依頼します。Supabaseに触れる必要も、Supabaseについて何も知る必要もありません。
しかし今や、実行ループ内のすべてのステップ、すべてのプロンプト、すべての往復で、数万トークンの関連性のない内容が含まれることになります。ツールを使用していないときにはツールは必要ないのに、常にそこにあるのです。
辞書を想像してください。この辞書を使って物事を見つけます。単語を見つけたいとします。理想的には、正しい最初の文字を持つセクションにざっくり飛べて、どれくらい近いか確認し、目的の場所にすぐ行けるはずです。MCPは実質的に、最初のページの最初の単語からすべての定義を読まなければならないようにすることで機能します。
そして目的の場所に到達した後も、辞書の残りを読み続けなければなりません。それから戻ってきて「これがその単語の定義です」と言えるのです。狂っています。辞書内のすべての単語を、何かするたびに毎回読まなければならないのです。
そして読み終わる頃には、そもそも何のためにそこにいたのか見失っている可能性が高いです。LLMも同じことをするのが大好きです。エージェントに実行しているタスクに必要のないMCPコンテキストをすべて詰め込むと、より高価で、遅く、そして愚かになります。すべてMCPサポートという名目の下で。素晴らしい。
Anthropicの解決策
では、Anthropicはこれらの問題をどう解決しようとしているのでしょうか。AIエージェントの未来は、モデルが何十万ものツールとシームレスに連携するものです。Git操作、ファイル操作、パッケージマネージャー、テストフレームワーク、デプロイメントパイプラインを統合するIDEアシスタント。
Slack、GitHub、Google Docs、Jira、企業データベース、そして数十のMCPサーバーを同時に接続する運用コーディネーター。効果的なエージェントを構築するには、すべてのツール定義を最初からコンテキストに詰め込むことなく、無制限のツールライブラリで動作する必要があります。繰り返しますが、これが問題です。
エージェントにツールを与えると、エージェントはそのツールの定義をコンテキスト内に持っていなければ使用できません。しかし今、それは必要ないときにもただそこにあるのです。MCPでコード実行を使用することについての私たちのブログ記事では、ツールの結果と定義が、エージェントがリクエストを読み始める前に5万トークン以上を消費することがあると説明しました。
エージェントは必要に応じてツールを発見してロードし、現在のタスクに関連するものだけを保持すべきです。そうです。まさにその通りです。これを行うにはさまざまな方法があります。
何人かの人々が実験しているのを見たものの1つは、各ステップ間で安価で高速な大規模コンテキストモデルを実行し、ステップが何をするかを識別して「このステップにはこれらのツールが必要だ」と言うというアイデアです。
そして、その特定のターンのために、手元のタスクに基づいて適切なツールでシステムプロンプトを動的に調整します。ターンに馴染みがない場合に説明すると、エージェントでツール呼び出しが発生するとき、実行を一時停止してから継続しているわけではありません。ツールが実行されると、エージェントは終了し、モデルは結果を完了しています。
ツールが実行され、メッセージ履歴に別のデータを追加し、新しいメッセージを送信すると、それが履歴に含まれます。理にかなっています。メッセージを送信し、応答を受け取り、それから別のことを尋ねるとき、明らかに全履歴を含むことになりますが、ツールは実質的に各ステップの間で人として機能しています。
ツールが完了すると、それを履歴に追加し、全履歴が再びモデルで実行されます。これがツール呼び出しの仕組みです。コードベース内のファイルを更新するというリクエストを行うと、ファイルを見つけるツール呼び出しを行います。変更方法をGoogle検索か何かで調べるツール呼び出しを行います。
そしてファイルを編集する別のツール呼び出しを行います。モデルはそのリクエスト中に3つのリクエストを行いました。1つのメッセージしか送信していないかもしれませんが、全履歴を3回送信しており、追加されるたびにはるかに多くのコンテキストがありました。
しかし、この巨大なツール定義が最初にあると、その全ツール定義がこれらすべての後続リクエストに含まれることになります。ユーザーからの1つのプロンプトにつき、何百、いや何千ものこれらが発生することがあります。恐ろしいことです。
大量のコンテキストを無駄にします。大量のお金を無駄にします。大量の時間を無駄にします。そして、履歴に無用な情報があるため、モデルを愚かにします。では、どう解決するのでしょうか。
私が見た人々が行っている実験は、これらの各ステップで、小さなモデルが見て次に何が起こるかを確認し、そのサブピースのシステムプロンプトを調整して正しいツールを含めるというものです。クールに見えます。
コード実行によるアプローチ
また、モデルがループ中に正しいツールを渡されるのではなく、モデルがループの一部としてツールを見つけられる発見という、Anthropicが反対方向に進んでいるようにも見えます。これらすべてについての私の以前の動画で、MCPのコード実行について話しましたが、これは実際かなりクールだと思います。
エージェントに、これらすべてを含むSDKを、最初の大量の言葉によるコンテキストとしてではなくコードとして与えると、物事を実行するコードを著しく良く書くことができます。エージェントはコードからツールを呼び出す能力が必要です。
自然言語のツール呼び出しを使用する場合、各呼び出しには完全な推論パスが必要で、中間結果が有用かどうかに関係なくコンテキストに積み上がります。ここにコンテキストがあります。
システムプロンプト、ツール定義、ユーザーメッセージがあります。ここからモデルに行きます。追加のテキスト、つまりあなたが見ることができるメッセージと、実行すべきツール呼び出しの両方で応答します。ツール呼び出しは、この場合MCPサーバーであるハーネスで実行されます。
それがコンテキストウィンドウ、履歴に追加され、その全履歴がモデルに送り返されます。以前言っていたことですが、システムプロンプト、ツール定義、ユーザーメッセージがすべて送信されます。アシスタントメッセージとツールリクエストで応答します。結果が入ってきて、それからこれらすべて、これまでの履歴の全体がモデルに送り返されて新しい応答を生成します。
ここで2つの連続したリクエストを行う必要がある場合を想像してください。ユーザーのIDを調べ、それからそのユーザーのためにデータベース内の何かを更新する別のツール呼び出しを行う必要があります。今や、これらを実行するために、前のものよりもさらに多くの履歴を持つ2つの完全なターンを行う必要があります。
しかし、IDでユーザーを調べてからデータベースを更新するTypeScriptを書けるなら、2回や20回や200回ではなく、1回のツール呼び出しで実行できます。これが、コード実行が理にかなっている理由です。なぜなら、ツール呼び出しの結果で何をすべきか正確に分かっている場合、それを行うために全履歴を送信する必要がないはずだからです。
レストランを想像してください。あなたはキッチンを運営する人です。料理のためにゆで卵が必要です。誰かに卵を茹でるよう伝えることができ、彼らはまだ殻に入ったゆで卵の山を持って現れます。まだ何にも使えません。それからあなたは以前に起こったことすべて、すべてのステップを再び言います。
レシピのすべての指示を与え、それから「さて、そのすべてを知ったので、殻を取ってください」と言います。最初にゆで卵を手に入れる指示を与えたとき、戻ってくる前に殻も取り除くよう伝えていたらどうでしょう。今や、はるかに少ない往復で、これらすべてをブロックしているはるかに少ない無駄があります。
これらのモデルがどれほど愚かか思い出すと、これらのことをすでにもっと良く行っていないのは狂っています。しかし、彼らはコードを書くのは得意です。この例の中では、Googleから正しいシートを取得し、欲しいものをフィルタリングし、そして欲しいデータだけを与えるようなことができます。
ツールからのすべてのデータで応答する代わりに、コードでフィルタリングして、コンテキストに入る無駄を少なくすることができます。次のステップを実行するために複数の往復を要求する代わりに、すべてを1回のパスで実行できます。LLMではなくコードでこれを行うのは本当に理にかなっています。
2行のコードで済むデータをフィルタリングするためにLLMを使っているなら、あなたはMCPにはまりすぎていて助けが必要です。コードを実行させてください。これらのことに本当に優れています。ありがたいことに、Anthropic、Cloudflare、そして私全員が、コードからツールを呼び出すことが大部分の時間においてはるかに理にかなっていることに同意しています。
Cloudflare、Anthropic、そして私全員が何かに同意するのは珍しいことです。だから、これは有用な背景情報だと思います。コードは、ループや条件分岐、基本的なフィルタのようなデータ変換といったオーケストレーションロジックに自然に適合します。
エージェントには、手元のタスクに基づいてコード実行と推論の間を選択する柔軟性が必要です。分かります。エージェントはまた、スキーマ定義だけでなく、例から正しいツールの使用法を学ぶ必要があります。
JSONスキーマは構造的に有効なものを定義しますが、使用パターン、オプションのパラメータをいつ含めるか、どの組み合わせが意味をなすか、APIがどのような規約を期待しているかを表現することはできません。そして彼らは3つの新機能をリリースしています。
ツール検索ツール、これは史上最も面白い名前です。それからプログラマティックツール呼び出しツールがあり、これによりClaudeはコンテキスト実行環境でツールを呼び出すことができ、モデルのコンテキストウィンドウへの影響を減らします。これは以前話していたことです。コードを実行させましょう。彼らは独自のサンドボックスを構築しているようです。
以前、私はDaytonaを推奨しました。だから、任意のプラットフォームで任意のエージェントに対してこれを自分で設定できます。これらの環境の1つでコードを実行する独自の方法を設定したいなら、Daytonaが圧倒的に最も簡単で信頼性があります。彼らはスポンサーですが、実際に本当に気に入っています。
そして、私のチャンネルマネージャーで仲間のYouTuberであるBenが、たくさんのことに彼らを使っているのを知っています。この動画のスポンサーになるかもしれません。分かりません。撮影時にはスポンサーが誰になるか分からないので。
それからツール使用例があり、特定のツールを効果的に使用する方法を示すための普遍的な標準を提供します。Anthropicからの普遍的な標準はこれまで本当に良い実績がありますからね。彼らはMCPに誰も本番環境で使用したことのないO標準を使用し、誰もそれを実装する方法を知らないので移行しています。なぜなら、それがひどいからです。ええ、素晴らしい。
だから、彼らは正しいツールを見つけて含めないようにすることができるようにしました。モデルが全く行わずにツールを実行し、モデルが間違えないように例を用意しました。これらはすべて、悪い標準へのダクトテープのように感じますが、これらを有用にするなら、クールです。より有用になるでしょう。
内部テストでは、これらの機能が従来のツール使用パターンでは不可能だったものを構築するのに役立つことが分かりました。例えば、Cloud for Excelはプログラマティックツール呼び出しを使用して、モデルのコンテキストウィンドウを過負荷にすることなく、何千行もあるスプレッドシートを読み書きします。
ええ、当然です。私たちの経験に基づいて、これらの機能はClaudeで構築できるものの新しい可能性を開くと信じています。どうやらこのパズルゲームを解けるようです。次のセクションはツール検索についてです。彼らはここで明確な課題を定義しています。
ツール検索の仕組み
ツール定義は重要なコンテキストを提供しますが、より多くのサーバーが接続されると、これらのトークンが積み重なる可能性があります。また、MCPが実質的に完全なサーバーを必要とすることがどれほど狂っているか話せますか。MCPのものをサーバーレスで実行したいですか。頑張ってください。楽しんでください。
それは、実行中の任意の時点で使用でき、両者間で正確な履歴を共有できるステートフルな長い接続を想定しています。MCP標準は、サーバー側での実装が本当にひどいです。だからこそ、最もクールなMCPのものの多くは、エディターが接続してランダムなbashコマンドを実行できるようにするために、コンピューター上でPythonでバックグラウンドプロセスを実行する必要があるのです。環境を呼び出すことができません。
何かをするには既存の環境への接続が必要なのです。興味深い標準です。では、いくつかのツールを持つ基本的なセットアップを考えてみましょう。GitHubサーバーに35のツール、Slackサーバーに11、Sentryサーバーに5、Grafanaに5、Splunkに2があります。
これら58のツールは、会話が始まる前に55,000トークンを消費します。Jiraのようなサーバーを追加すると、それだけで17,000トークンを使用し、すぐに100Kトークンのオーバーヘッドに近づきます。そして、ツール定義が最大134Kトークンを消費するのを見てきました。
これは200kトークンのコンテキストウィンドウを持つモデルです。新しいものは100万ありますが、そのように使用するとはるかに愚かになります。トークンコストは唯一の問題ですらありません。
最も一般的な失敗は、間違ったツール選択と不正なパラメータです。特にツールが似た名前を持つ場合、notification send userとnotification send channelのように。ええ、つまり、モデルがwork treeという単語を別のものに幻覚したために正しいディレクトリに切り替えられないような愚かなことさえ見たことがあります。
私の実行の1つでwork tが起こったと思います。ディレクトリの名前を思い違いしたために正しいディレクトリに切り替えられなかったのです。十分に似た名前のものを与えると、すべてが非常に速く崩壊し、最終的にモデルは諦めて愚かなことをします。
GPT-5.1についての私の動画で、codeexで彼らのハーネスと一緒に使おうとしていたとき、edit fileツールを全く使わずにreaxを書いてbash経由でPerlで実行することでファイルを定期的に編集していました。何ですって。そう。では、彼らの解決策はこうです。
すべてのツール定義を最初にロードする代わりに、ツール検索ツールはオンデマンドでツールを発見します。Claudeは現在のタスクに実際に必要なツールだけを見ます。従来であれば、これらすべてのツールで大量のコンテキストを肥大化させていましたが、ツール検索セットアップでは、これのために発見した正しいツールだけを含めます。
この例では、ツール使用量が85%削減され、完全なツールライブラリへのアクセスを維持しています。内部テストでは、大規模なツールライブラリで作業する際のMCP評価で大幅な精度向上が示されました。Opus 4は49%から74%に改善しました。50%の改善です。
そしてOpus 4.5は79.5%になりました。なぜなら、彼らはモデルをツールの肥大化に対処するように訓練しているからです。それがあまりにもひどくなったので。Opus 4から4.5は50%から79.5%でした。しかし、ツール定義から半分のツールを削除するだけで、Opus 4をツール呼び出しにおいてOpus 4.5とほぼ同等に良くすることができました。
そして4.5でさえ、ツール検索ツールがセットアップされると88.1%まで大幅な改善を見ました。実際にどう機能するのでしょうか。すべてのツール定義をAPIに提供しますが、defer loading trueでツールをマークします。これにより、オンデマンドで発見可能になります。
遅延ツールは最初にClaudeのコンテキストにロードされません。Claudeはツール検索ツール自体と、defer loading falseを持つツールだけを見ます。だから、常にアクセスできるようにしたいツールがあるなら、まだそれができます。
Claudeが特定の機能を必要とするとき、関連するツールを検索します。ツール検索ツールは、Claudeのコンテキスト内で完全な定義に展開される一致するツールへの参照を返します。
ClaudeがGitHubとやり取りする必要がある場合、GitHubを検索し、GitHub create pull requestとlist issuesだけがロードされます。Slack、Jira、Google Driveからの50以上の他のツールはロードされません。
今やClaudeは完全なツールライブラリにアクセスでき、実際に必要なツールのトークンコストだけを支払います。これはプロンプトキャッシングを壊しません。これは実際良い指摘です。私の以前の提案であるモデルを間に挟むというのは、プロンプトキャッシングを壊すでしょう。
トークンの山をモデルに与えるとき、次に最も可能性が高い場所を見つけるために、それらを実質的にベクトル化しなければなりません。なぜなら、これらすべては自動補完だからです。たくさんのトークンがあるとき、それがあなたの履歴です。
次の最も可能性の高いトークンは、履歴が変わると変わります。それがすべての仕組みです。そして、コンテキスト内のすべてのものに基づいてそれを計算しなければなりません。この例では、これが初期コンテキストです。システムプロンプト、ツール定義、ユーザーメッセージ。これらすべてがLLMに送信されて実行されます。それから戻ってきます。
アシスタントメッセージ、ツール呼び出し、ツールの実際の呼び出しを行い、結果を得て、それからこれらすべてのデータをモデルに再び送り返して、次のメッセージ、次のステップ、いわば次のターンができるようにします。
なぜ、この部分を計算したばかりなのに、これをすべて再計算しなければならないのでしょうか。なぜ、コンテキストが構築された後のトークンを指す方法のようなものを説明するために使いたい用語であるベクトル化や何であれを再計算しなければならないのでしょうか。なぜ、すでにこの部分を計算したのに全体を再計算しなければならないのでしょうか。
ここでキャッシングが登場します。最初のトークンからある地点までキャッシュでき、より多くのものを追加するときにその部分を再計算する必要がありません。これは従来のAIチャットに本当に便利です。なぜなら、メッセージを送信して応答を得て、それから別のことを尋ねる場合、システムプロンプトやすべてを含む以前のすべてを再計算する必要がなく、新しいメッセージ以降だけを計算すればいいからです。
これはモデルプロバイダーにとってはるかに安価になり、だから彼らはキャッシュにヒットしたときに従来のトークン化に対して大幅な割引を提供するのです。OpenAIとGeminiは両方とも自動的に良いキャッシングをしてくれるので、物事が著しく安価になります。Anthropicは手動で行わせます。
しかし、ここには別の問題があります。上から下に計算しているので、この部分をキャッシュしてこの部分を安くしたいのですが、ここに到達したら、はるか上のシステムプロンプトも変更しました。チェーンの上流での変更はキャッシュを破壊します。
キャッシュはエントリからキャッシュエンティティの終わりまで静的でなければなりません。最初で何かを変更すると、キャッシュ全体が死にます。だから、利用可能なツールに基づいてシステムプロンプトを動的に編集している場合、すべてが崩壊し、本当に速く崩壊します。
では、どう解決するのでしょうか。新しいツールの導入がキャッシュを壊すことなくどう許可するのでしょうか。Anthropicのソリューションは、Claudeがメッセージ履歴内でそれらを検索した後、最初の定義の一部としてではなく、コンテキストとして追加されるように見えます。システムプロンプトとコーディアル定義はキャッシュ可能なままです。
クールに聞こえますが、ハイジャックするのが非常に簡単な可能性もあります。なぜなら、システムプロンプトは通常このエージェントのコードベースで定義されているからです。そして履歴の残りは、ユーザーが何かをするとき、またはエージェントが何かをするときにプログラム的に行われます。
私は、履歴に偽のツールや既知のツールの悪い定義を追加して、悪意のある方法でツールを呼び出させるプロンプトインジェクションの多くの可能性を見ています。
シンタックスハイライトのない実装例がここにあります。Anthropicがコードに本当に優れているので、ツール検索ツールが含まれています。Type tool search tool reax。動画に楽しい飲酒ゲームを追加したいなら、これがそれに違いありません。私がtoolという単語を言うたびにショットを飲んでください。病院でお会いしましょう。このペースだと私がおそらく先に着くでしょう。
だから今、ツールにdefer loadingをマークできます。そうすれば、検索されるまで含まれません。そしてMCPサーバーについては、特定の高使用ツールをロードしたまま、サーバー全体のロードを遅延させることができます。あのタブの折り返しを見てください。ここでの美しいフォーマットです。
Cloud開発者プラットフォームは、すぐに使えるReactベースとBM25ベースの検索ツールを提供しています。カスタム検索ツールを実装することもできます。ツールを検索するツールのためのカスタム検索ツールを実装できます。
soy.runが私のチャットに楽しい研究を投下しました。これは昨年からのものです。敵対的インジェクションを通じたLMツール呼び出しの操作。ああ、これはさらに悪化するでしょう。あなたがツールが好きだと聞いたので、ツールをあなたのツールに入れて、ツールでツールを生成しながらツールを聞けるようにしました。
toolという単語はこのページに196回出現します。では、いつツール検索ツールを使うべきでしょうか。あらゆるアーキテクチャの決定と同様に、ツール検索ツールを有効にすることにはトレードオフが伴います。機能はツール呼び出しの前に検索ステップを追加します。
だから、コンテキストの節約と精度の向上が追加のレイテンシを上回るとき、最良の投資収益を提供します。コード実行ソリューションのクールなところは、何かを実行するために発生しなければならないバックエンドの往復回数を減らすことです。
ここでは1つ増やしています。ツールを調べてから物事を実行しなければならないので、追加のターンを1つ追加しており、これは全履歴が往復することを意味します。しかし、8,000トークンのコンテキストウィンドウがあり、それを8,500トークンで再実行しなければならない場合、それでもそうでなければ必要だったであろう50,000から100,000トークンのコンテキストウィンドウよりはるかに少ないです。
だから、ツール定義が10k以上のトークンを使用している場合、ツール選択の精度問題が発生している場合、複数のサーバーを持つMCPパワーシステムを構築している場合、または10以上のツールが利用可能な場合に使用してください。
小さなツールライブラリではそれほど有益ではありません。10未満のツールは今や小さいのです。なんてこった。すべてのツールがすべてのセッションで頻繁に使用され、ツール定義がコンパクトである場合、これらは使用しない場合です。クールです。
プログラマティックツール呼び出し
それからプログラマティックツール呼び出しがあります。これは以前の動画で議論したもので、ツールを実行するコードを書けるというものです。なぜなら、LMは任意の構文のマッチングをして奇妙な推論をしようとするよりも、コードを書く方がはるかに優れているからです。分かりますよね。
ワークフローがより複雑になると、従来のツール呼び出しは2つの基本的な問題を生み出します。1つ目は、中間結果からのコンテキスト汚染です。Claudeに10メガのログファイルを分析するよう伝えると、必要なくてもファイル全体をコンテキストに入れてしまいます。
しかし、それを解析するコードを書くよう伝えると、数行だけを取り込むので、著しく良くなります。複数のテーブルにわたって顧客データを取得する場合、関連性に関係なくすべてのレコードがコンテキストに蓄積されます。
繰り返しますが、サービスのすべての管理者ユーザーを見つけたい場合、これらのMCPの多くの動作方法は、すべてのユーザーを取得し、リスト全体をメモリ、履歴にロードし、それから干し草の山の中の針のように正しいものを見つけることです。
あるいは、コードを実行して探している特定のものをフィルタリングでき、この場合はtype equals adminのユーザーで、履歴全体ではなくその5人のユーザーだけを返すことができます。Kent Doddsはすでに私たちより先を行っていて、今年のかなり前、7月以前にこれについての記事を持っています。それは同じ核心的な前提、動的ツール発見です。
これはプログラマティック実行のものより前ですが、私はそちらを好みます。しかし、MCPに実際に取り組んでいる少数の人々は、このずっと前からこの問題を認識していました。Anthropicは、いつものように遅いです。
ところで、プログラマティックツール呼び出しに戻ります。従来のツール呼び出しワークフローをより複雑にするもう1つの部分は、推論のオーバーヘッドと手動合成です。各ツール呼び出しには完全なモデル推論パスが必要です。
結果を受け取った後、Claudeはデータを目で見て関連情報を抽出し、ピースがどのように組み合わさるかを推論し、すべて自然言語処理を通じて次に何をすべきかを決定しなければなりません。5つのツールワークフローは、5つの推論パスに加えて、Claudeが各結果を解析し、値を比較し、結論を合成することを意味します。
これは遅くエラーが発生しやすい両方です。控えめに言って、チューン、トークン指向オブジェクト記法を覚えていますか。みんなが嫌っていて私が擁護したものです。このページの最もクールな部分の1つは、モデルごとの精度ベンチで、彼らがモデルに巨大なデータの山を渡して物事を見つけるよう求めるものです。
そして、GPT nanoがtuneで90.9%にヒットしているのを見るのはクールです。これはJSON compactと同じですが、CSVやYAML、特にXMLに切り替えると、正しいものを得る可能性が下がります。しかし、最良のケースでさえ、5 nano上のtuneでは90.9%の精度で大規模データセットの正しいデータを見つけます。
つまり、約10%の失敗率があるということです。10%の失敗率がないものを知っていますか。filter arrayです。filter user user ID equals何かは、このテストでの最良のケースよりも著しく信頼性が高いでしょう。これが得意ではないものを知っていますか。Anthropicのモデルです。
Haiku 4.5での最良のケース、これははるかに高価なモデルで5 Nanoよりもはるかに新しいモデルですが、彼らの最良のケースは59.8%です。大量のデータでの40%のルックアップ失敗率です。
モデルにデータのすべて選択バージョンを与えて、それから正しいものを見つけようとフィルタリングしようとすると、成功しません。なぜなら、モデルはかなり愚かだからです。これが彼らがClaudeコードソリューションのようなものに全面的に取り組んだ理由です。なぜなら、彼らは正しいものを識別するために与えられたコンテキストを持つモデルを信頼できないからです。
探しているものを見つけに行くコマンドを書く方がはるかに優れています。これらのモデルは大量のコンテキストでうまく動作しません。だから、Anthropicがついにそのコンテキストを減らそうとしているのは非常に理にかなっています。
では、彼らの解決策は何でしょうか。プログラマティックツール呼び出しにより、Claudeは個別のAPI往復ではなく、コードを通じてツールをオーケストレーションできます。Claudeがツールを1つずつ要求し、各結果がコンテキストに返される代わりに、Claudeは複数のツールを呼び出し、出力を処理し、実際にコンテキストウィンドウに戻る情報を制御できるコードを書きます。
これは、データを調べているツールとデータを更新しているツールがあるツールをチェーンしている場合だけでなく、Claudeに戻るものを減らすためだけにも有用です。Claudeにどのユーザーが管理者かを尋ね、すべてのユーザーを見つけるルックアップツールがある場合、すべてのユーザーを引き込み、そのすべてのデータを取得してから、その中の管理者を干し草の山の中の針として見つけるために最善を尽くします。
しかし、コード実行を与えると、すべてのユーザーを取得する同じリクエストを実行してから、コンテキストに戻す前にクイックフィルタを行い、大量のトークン、大量のお金を節約し、その10%の失敗率、またはhaikuの場合40%の失敗率をゼロに減らすことができます。
考えてみてください。これらのモデルが最良のケースで10%のルックアップ失敗率、最悪のケースで50%を持っているというのは、考えてみるとかなり狂っています。そして、ちょっとしたコードを書くか、モデルにコードを書いて実行させることで、その失敗率をゼロに減らすことができます。
コードを書かせると、モデルはとても賢くなります。そして、業界としてこれをついに認めていることが嬉しいです。Claudeはコードを書くのが得意です。そして、自然言語のツール呼び出しではなくPythonでオーケストレーションロジックを表現させることで、より信頼性が高く正確な制御フローが得られます。
ああ、彼らはCloudflareをコピーするのをやめて独自の方法でやっています。Cloudflareをコピーしていたとき、彼らはTypeScriptも使っていました。これには本当に良いです。今彼らはPythonを使っています。これにはそれほど良くありません。
今年初めにTencentによってAutoCode Benchmarkという非常に面白い研究が発表されました。そして、ここで本当にクールな部分の1つは、異なる環境で異なるモデルがどれほど良いかを比較していることです。これが本当に楽しくなる準備はできていますか。Opus 4.1のパフォーマンスを見てみましょう。
Pythonで42.3、Vanilla.jsで42.9、TypeScriptで47.7を得ました。だから、Anthropicが本当にモデルをコードでこれらのことを行うのに優れたものにしたいなら、本当に簡単な解決策があります。すべてをPythonでやるのをやめてください。
とにかく、このチャートと、そこから学べるすべての楽しいことについて、非常に近い将来たくさん話すことになるでしょう。彼らには「いつ使うか」というセクションがあり、大量のデータの処理、3つ以上の依存ツール呼び出しを伴う複数ステップのワークフローの実行、Claudeがそれらを見る前にツール結果のフィルタリング、ソート、変換、中間データがClaudeの推論に影響を与えるべきではないタスクの処理、または多くのアイテムにわたる並列操作の実行などが挙げられています。
単純なツール呼び出しの呼び出しを行う場合、Claudeがすべての中間結果を見て推論すべきタスクに取り組んでいる場合、または小さな応答の迅速なルックアップを実行している場合には、それほど有用ではありません。その通りです。
そして今、ツール使用例があります。スキーマを与えるだけでなく、モデルにツールの使用方法を実際に示します。MCPを何とかするための最後のピース、つまりOを行う良い方法と、すべての単一のツール接続のためにサーバーを実行する必要がない遅延実行環境以外のものです。
JSONスキーマは構造、型、必須フィールド、許可される列挙などを定義するのに優れていますが、使用パターン、オプションのパラメータをいつ含めるか、どの組み合わせが意味をなすか、APIがどのような規約を期待しているかを表現することはできません。
サポートチケットAPIがあります。これは文字列としてのタイトルで、low、medium、high、criticalの列挙としての優先度、アイテムの配列であるラベル、これらすべての追加ピースを持つレポーターです。クールです。
スキーマは何が有効かを定義しますが、重要な質問には答えません。due dateはこの形式、より伝統的なテキスト形式、またはUTCタイムスタンプを使用すべきでしょうか。ID規約についてはどうでしょうか。レポーターはUUIDですか、それともユーザープレフィックスを持つ何か、またはただのランダムな数字ですか。
いつClaudeはレポーター連絡先のようなネストされた構造を埋めるべきでしょうか。escalation levelとescalation layersは優先度とどう関係していますか。これらの曖昧さは、不正なツール呼び出しと一貫性のないパラメータ使用につながる可能性があります。
彼らの解決策であるツール使用例は、ツール定義に直接サンプルのツール呼び出しを提供できるようにします。スキーマだけに頼る代わりに、具体的な使用パターンをClaudeに示します。JSONが実際に新しいプログラミング言語になりつつあります。素晴らしい。
入力スキーマがあります。それから入力例があります。これらはコンテキストのない例、ただの例です。だからこれは形式に一致するいくつかの入力です。結果の形がどのようになるかさえ示していません。文字通り、ここでできる有効なツール呼び出しがあり、これが有用だと思いました。これはちょっと悲しいです。
彼らの内部テストでは、ツール使用例が複雑なパラメータ処理での精度を72%から90%に改善しました。もしかしたらコードを書くことに戻るべきかもしれません。すべてが間違いのように感じ始めています。
これは、有効なJSONが正しい使用を意味しない複雑なネストされた構造、多くのオプションパラメータを持つツール、ドメイン固有の規約を持つAPI、例がどれを使用するかを明確にする類似のツールに適しています。
ここにベストプラクティスセクションがあります。これのどれだけが私を怒らせるか見てみましょう。実世界のアクションを取るエージェントを構築することは、規模、複雑さ、精度をすべて同時に扱うことを意味します。これら3つの機能は、ツール使用ワークフローの異なるボトルネックを解決するために連携します。
効果的に機能を階層化する方法は次のとおりです。機能を戦略的に階層化します。すべてのエージェントが特定のタスクに3つの機能すべてを使用する必要があるわけではありません。最大のボトルネックから始めます。
ツール定義からのコンテキストの肥大化がある場合は、検索ツールを使用します。コンテキストを汚染している大きな中間結果がある場合は、プログラマティックツール呼び出しを行います。パラメータの形式が間違っているエラーがある場合は、ツール使用例を使用します。
この集中的なアプローチにより、前もって複雑さを追加するのではなく、エージェントのパフォーマンスを制限している特定の制約に対処できます。AIで構築することは、コードで物事を構築するよりも急速に複雑になっています。これはちょっと狂っています。
JSエコシステムがどれほど複雑かについて二度と批判を受けることはないでしょう。LLMに簡単にAPIリクエストをさせることさえできないのに。これは非常に狂っています。私たちは、結果が機能する何かであることを期待して、ますます多くのバンドエイドとテープの層を重ねているだけです。
必要に応じて追加機能を階層化します。それらは補完的です。どうやってプログラマティックツール呼び出しが、元のJSON形式でのみ存在するツール使用例と補完的なのでしょうか。これら2つは補完的ではなく、矛盾しています。
そして、検索ツールとプログラマティックツール呼び出しはどう互いを補完するのでしょうか。これは、ツールを適切に使用するコードを書くためにコードベースを読んでタイプ定義を見つけるものです。これは、LLMがツールを実行する自然言語の方法を見つけられるようにするものです。
代わりに、ツール検索とツール使用例が補完的であることは分かりますが、プログラマティックツール呼び出しはそれらの代替手段です。そして今、エンジニアにさらなる挑戦を与えます。ご存知のように、エンジニアは物事の命名が本当に得意です。彼らがさらに得意なことを知っていますか。簡潔なコピーライティングです。
エンジニアは文章を書くのがとても上手です。なぜ彼らがコードを書いているのか分かりません。散文を書けばいいのに。彼らはとてもエレガントで賢く、賢明です。本当に愚かだったら言うことです。エンジニアは文章を書くのがとても下手なので、コードをある程度知っていて、人とある程度うまくやれることをキャリアにすることに専念する分野全体があるのです。
コードで10点満点中4点、社交性で10点満点中4点で、コードで10点満点中10点よりも多くのお金を稼ぐことができます。なぜなら、それは本質的に社交性で10点満点中2点が最良であることを意味するからです。
だから、これらのエンジニアにLLMにとって簡潔で記述的な定義を書かせましょう。きっとうまくいくでしょう。これらのエンジニアは全員、自分たちのツールに本当に良い定義を書くでしょう。明らかに、私は発狂するでしょう。
さらに良いのは、これらの開発者全員がタブで説明を補完することです。LLMに彼らのために書かせるつもりで、それはすべてを良くするのではなく悪くするでしょう。素晴らしいことになるでしょう。
これは実際合理的な指摘です。なぜなら、どのツールにアクセスできるか、できないかが分からないからです。存在すると思う3つの異なるものを検索してそれらが存在しない場合、困ります。だから、Claudeが何が利用可能かを知るようにシステムプロンプトのガイダンスを追加することが重要です。
何層深くまで来たか分かりますか。私はこれを図式化する必要があります。発狂しそうです。LMにアクセスさせたいデータがあります。だからこのデータがあります。
LMはそれにアクセスする必要があります。では、どうしますか。前にAPIを置き、curlリクエストをさせますが、そうはしていません。MCPをやっています。だから、このデータにMCPを通じてアクセスします。しかし、MCPは定義です。サーバーが必要です。だから、データは今やMCPサーバーを介して公開され、MCP定義があります。
MCP定義は、どのような形式を取るかを記述するJSONスキーマです。今、そこに例やその他のものを追加できますが、同じレイヤーに存在するので、ここに並べて置きます。しかし今、そのレイヤーを通じてアクセスしていないので、関係ありません。ツールを検索しています。
そして、これがマルチステップのものであることが判明しました。だから、プログラマティック実行を行うつもりです。サンドボックスVM環境があり、それからPythonコードがあります。ここでオペレーティングシステムと階層を再発明しました。冗談でしょう。これが通過しなければならないすべてのレイヤーです。どうやってここに来たのでしょうか。なぜ今ここにいるのでしょうか。発狂しそうです。
そして、ragが間違いだと思っていました。悪化し続けるでしょう。物事が思い通りに動作しないときはいつでも、レイヤーを追加し続けるだけです。ああ、忘れていました。ツール定義をコンテキストから取り出したので、これをシステムプロンプトに追加しなければなりません。だから、今ツールについてヒントを与えるシステムプロンプトが必要です。これが私たちのレイヤーです。
もう一度、どうやってここに来たのでしょうか。TypeScriptがJavaScriptにコンパイルされ、それがV8で実行され、それがC++で書かれているという別の仮想化された言語になる言語で作業しているという批判を二度と受けることはないでしょう。そこにはそれよりも少ないレイヤーしかありません。基本的なツール呼び出しにあるよりも少ないのです。
ああ、これは陽気です。プログラマティックツール呼び出しの場合、MCPの一部として返却形式の標準がないため、私の理解する限りでは、MCP定義は出力がどのように見えるかを教えてくれません。プログラマティックツール呼び出しを行っているとき、そのreturnステートメントを自分で書かなければなりません。
MCBによって実際に何が返されるかをモデルに伝えなければなりません。タイプ定義が書きやすいので、TypeScriptではこれは問題ありません。しかし、彼らがこれに推奨しているように見える言語であるPythonとJSでは、分からないでしょう。だから、それをモデルのために書かなければなりません。
MCPの一部としてオプションの出力スキーマがありますが、誰も使用しているのを見たことがありません。なぜなら、LLMでは、出力の形式が何であるか気にする人がいるでしょうか。それは単にコンテキストに詰め込まれるだけです。
とにかく、発狂しそうです。彼らの記載されているソースの1つはLLMVMです。これは、大規模言語モデルとローカルPythonツールおよびヘルパーを使用してタスクを推論し実行するCLIベースの生産性ツールです。文字通り、今レイヤーの上にレイヤーを追加しています。
なんてことだ、AI code kingがチャットに現れました。これらのブログのほとんどは、MCPの肥大化したツール呼び出しのためだけに書かれています。Anthropicは新しい問題を作り出し、今その問題を修正しています。ACPはMCPよりもはるかに優れたプロトコルです。AnthropicはZedと待機プロトコルの方法から何かを学ぶべきです。
正直なところ、AnthropicはZedを買収すべきだと思います。これは業界で最良の連携の1つだと思います。彼らは非常に多くのことで助けることができます。Zedチームと彼らがどう運営しているかが本当に好きです。
Zedで働いている人々の多くがここにたむろしています。彼らとは信じられないほど素晴らしい交流しかしていません。このコンピューターにエディターさえインストールしていないにもかかわらずです。Zedチームは素晴らしいです。彼らは開発者と良いソフトウェアと開発者体験を非常に深く理解しています。
Anthropicの開発者の頭脳に存在するすべての穴を埋めてくれます。この点を繰り返し強調しないようにしていますが、Zedはこんなことは絶対にしなかったでしょう。これが飛ぶことを許さなかったでしょう。
では、今記事の終わりです。つまり、終わりですよね。そうですよね。エージェントスキルの紹介。Claudeは今、特定のタスクをどのように実行するかを改善するためにスキルを使用できます。発狂する前にこれを終わらせます。
いつものように皆さんありがとうございました。願わくば、ここで何か有用なものを見つけてください。そうでなければ、申し訳ありません。どう思うか教えてください。それでは次回まで、平和を、オタクたち。
コメント