MCPサーバを立てるだけではAIエージェントに使われない：及川卓也からエージェント時代の開発者たちへ（12）
「自分の作ったツールを、MCPサーバでAIエージェントから使えるようにしよう」。そう言われてきました。私も自作ツールにMCPサーバを付けています。ただ、用意しさえすれば使ってもらえる、というものでもないようです。決め手がどこにあるのかを、自分のサーバで確かめてみました。
私は自分のプロフィールサイトを公開しています。経歴と、書いたものと、登壇の記録を置いてあるだけの静的サイトです。このサイトがエージェントから使える状態になっているかどうかを、エージェントが送るであろうリクエストを自分で投げて確かめてみました。投げたのは次の5つです。
1つ目は「llms.txt」。サイトの案内をエージェント向けにまとめたテキストファイルで、トップに置きます。アクセス結果は404でした。
2つ目は「MCP Server Card」。「/.well-known/mcp/server-card.json」に置くJSONで、そのサイトがどんなMCPサーバを提供し、どのツールが使え、どこに接続してどう認証するのかを、接続する前にエージェントへ知らせるものです（ただし、まだ仕様提案中）。これも404。
3つ目は「API Catalog」。RFC 9727で決まっている「/.well-known/api-catalog」に、公開しているAPIの一覧と、仕様書やドキュメントへのリンクを置けます。エージェントが開発者向けポータルを読み回らずに済むようにするものです。やはり404。
4つ目は「Markdownのコンテントネゴシエーション」。同じURLに「Accept: text/markdown」というヘッダーを付けたリクエストが来たら、HTMLではなくMarkdownを返す仕組みです。装飾やナビゲーションのタグを読まされずに本文だけを渡せるので、Cloudflareの計測では最大80%のトークン削減になります。試したところ、整形済みのHTMLがそのまま返ってきました。
5つ目はrobots.txtです。AIのクローラーをどう扱うかを書ける場所ですが、ファイル自体がありません。拒否しているのではなく、方針を何も表明していない状態です。
5つとも同じでした。エージェントから見つけやすくする仕組みも、エージェントに読みやすく渡す仕組みも、エージェントに方針を示す仕組みも、用意していません。人間の読者に対しては自己紹介をしているものの、エージェントに対しては何も言っていないわけです。
これは実験でも何でもありません。サイトを作ったのは私で、どれも設定していないのは自分が一番よく知っていますから当たり前の結果です。ちょっとわざとらしかったですね。でもわざわざ順にお見せしたのは、自分も含め、私たちの多くが、おそらくほぼ何もしていないということを示してみたかったからです。
ドキュメントの66%は、エージェントが読んでいる
そもそも、エージェント向けの対応は、本当に必要なのでしょうか。
ドキュメントのホスティングを提供するMintlifyが2026年7月末に出した中間レポートによると、同社がホストするドキュメントへのアクセスのうち、エージェントによるものが66%を占めました。2026年1月には15.2%だったので、同社は半年で52ポイントの増加としています。さらに、機械向けだと分かる経路で来たアクセスのうち、HTMLではなくMarkdownのファイルを直接取りに来た比率が、2026年2月の25.1%から7月には54.4%に上がっています。母集団はMintlifyでホストされたドキュメントなので、そのまま一般化はできません。それでも、読み手の半分以上が人間ではなくなっている場所が、既に存在するということです。
それだけ来ているのなら、私のサイトのように何もしていないところは少数派なのだろうと思って調べました。しかし、結果は逆でした。Cloudflareが2026年4月17日に公開した実測があります。アクセス数の多い上位20万ドメインが、エージェントから使える状態かどうかを機械的に調べたものです。Markdownのコンテントネゴシエーションに対応していたのは3.9%、robots.txtにAI利用の方針を書いていたのは4%。MCP Server CardとAPI Catalogは、2つ合わせて全データセット中15サイト未満でした。20万のうち、15に届きません。私は大多数の側でした。少し安心しかけましたが、いやいや、みんなやっていないから自分もやらない、で済む話ではありません。読みに来ている相手は、もうそれだけいるのですから。
Geminiアプリが、私のMCPサーバに対応していなかった
プロフィールサイトとは別に、私にはエージェント向けの対応をしたものがあります。自分専用の個人ツールです。
私は自分の資産を管理するツールを作って使っています。個人用なこともあり、データはGoogleスプレッドシートに置き、残高や保有銘柄、配当の予定を入れてあります。作った時にMCPサーバも一緒に用意しました。エージェントから資産の状況を聞いたり、下書きを作らせたりしたかったからです。読み取りと書き込みで、ツールを11個用意しました。
実は最近、MCPサーバを自分で書くことが増えました。MCPでつなぎたくても、公式のものがない場合はもちろん、あっても欲しい機能が入っていないことがあるからです。以前なら、有志が公開している非公式のサーバ、いわゆる野良のサーバを探していました。今は探しません。中で何をしているか分からないものを自分のデータにつなぐのが怖いからです。認証情報をどう扱っているのか、送った内容がどこかへ出ていかないか、頼んでいない操作をしていないか。オープンソースとして公開されているなら、コードを全部読めば分かりますが、それなら自分で書いた方が早いです。
ところが、私が普段使っているAIアプリの一つであるGeminiアプリが、当時はMCPに対応していませんでした。Gemini CLIは対応していたのですが、気軽に使えるアプリの方はまだだったのです。せっかく作ったMCPサーバが、Geminiアプリからは呼べません。仕方なく、Geminiアプリには元のGoogleスプレッドシートを直接読ませることにしました。これで用は足りました。
なお、Geminiアプリでも、エージェント機能のGemini Sparkで2026年6月末から独自のMCPサーバへの対応が始まっています。
Claudeでも、同じことがコネクタ経由でできると、しばらくして気付きました。スプレッドシートを直接読ませれば、今の資産構成はどうなっているか、来月の配当はいくら入る予定か、といった私が知りたいことは、だいたい分かります。ちなみにClaudeのコネクタも、中身はMCPです。つまり、自作のMCPサーバを経由しなくても答えは返ってくるわけです。では、自分が作ったものはいったい何のためだったのか。
自分ではこう納得させていました。Googleドライブのコネクタは、ファイルを読むための汎用（はんよう）の仕組みです。中身が資産のデータだとは知らないので、解釈はモデル任せになります。自作のサーバなら、「配分を軸別に出す」といった機能を名前と説明で示せるので、狙って呼べる。その方がきめ細かい指示ができるはずだ、と。理屈としては、今もそう思っています。
ただ、トークンの使い方まで含めて、自分のやり方が本当に得だったのかどうかは、考えたことがありませんでした。それで、測ってみることにしました。
11個のツールでゼロトークン
私のMCPサーバは、何トークン消費しているのか。資産管理サーバだけをつないだ状態でClaude Codeの「/context」を打つと、MCP toolsの欄は「11 tools・0 tokens」でした。「loaded on-demand」、必要になったときだけ取りに行く、と出ています。
予想外でした。MCPサーバをつなぐというのは、ツールの定義がコンテキストに載ることだと思っていたからです。載っている以上、使っていようがいまいが、その分のトークンは減っている。ずっとそう信じていました。
なぜゼロなのか。Claude Codeのドキュメントを読むと、ツール検索が既定で有効となっており、セッション開始時に読み込むのはツール名とサーバの指示（instructions）だけだ、と書かれていました。引数スキーマは必要になるまで送りません。厳密にゼロではありませんが、桁が違います。この記事を読んでいる方も打ってみてください。0と出れば、お使いのクライアントは必要な分だけ取りに行く方式です。
もっとも、私の思い込みには根拠がありました。MCPの公式リポジトリを見に行くと、2026年5月28日に立てられたIssue #2808があります。本番で動かしている11個のツールの定義を数えた表が載っていて、重いもので1024トークン、軽いもので103トークン、合計は6807トークンでした。まさに私が思っていた通りの状態が、少し前まではあった模様です。
同じリポジトリの別のIssueには、MySQLのMCPサーバでツールが106個あり、初期化のたびに約5万4600トークンを送っている、という報告もあります。1つの環境に限った話ではありません。
私のサーバも、全部読み込む方式なら軽くはありません。定義をJSONにして数えると、11個で約1300トークンでした。しかも重い方から2つ、下書きの保有明細を更新するツールと価格や為替レートを登録するツールだけで495トークン、全体の4割近くを占めています。どちらも書き込み系で、引数が配列、その要素がまたオブジェクトなので、JSON Schemaでは配列の宣言、要素の型、中のプロパティ、それぞれの制約が入れ子で並びます。そして私は、下書きの更新も価格の登録も、めったに使いません。
この問題を解決したのは、MCPの仕様ではありませんでした。2026年7月にMCPは改訂されていますが、その主眼はセッション管理のステートレス化で、ツール定義がトークンを消費する問題には手が入っていません。そのため、現在は呼び出すクライアントの側で対応をしています。
ただし、どこまで対応しているかはクライアント次第です。AnthropicのTool Search Toolは消費するトークンを約7万7000から約8700へ減らしましたが、対応していないクライアントでは今も全部まとめて読み込みます。同じMCPサーバにつなぐ場合でも、クライアントによって消費はまるで違います。
解決したのはコストだけだった
少なくともClaude Codeのように、実際に使うタイミングで初めて読み込まれる環境であれば、トークン消費を最小限に抑えられます。では、これでMCPサーバを公開すれば使われるようになるかというと、そうではありません。使わないツールまで抱え込むコストは解消されましたが、選ばれるかどうかはまた別の問題だからです。
Tool Search Toolの仕様によると、エージェントは依頼ごとにツールを検索し、返されるのは既定で上位5件です。公式ドキュメントでも、常時読み込ませるツールは3〜5個に絞ることが推奨されています。全てのツールを並べていた頃はつなぎさえすれば候補には入っていました。今は、リクエストごとに5つの枠を争う形になっています。
さらに同文書では、選択可能なツールが30〜50個を超えると、最適なツールを選ぶ精度自体が低下するとも指摘されています。つまり、ツール数が増えるほど、自分のツールが選ばれる確率は下がっていくと考えられます。
競合となるのは他のMCPサーバだけではありません。モデル自体による直接処理も強力なライバルです。専用ツールを探して呼び出すより、生のデータを読み込んで解釈した方が早いと判断されれば、サーバは呼び出されません。私がClaudeにスプレッドシートを直接読み込ませて事足りてしまったのも、まさにこのケースでした。
そもそも私の11個のツールのうち、トークンの4割を占める2つは利用頻度が著しく低いものでした。こうして整理してみると、MCPサーバが実際に使われるかどうかを左右しているのは、トークン量ではないことが分かります。
lodashが減っていった理由
便利だから、とりあえず入れておく。私たちは既に、同じことをJavaScriptのライブラリで経験しています。
lodashは、配列やオブジェクトを扱うちょっとした処理を数百の関数にまとめたもので、一時期はJavaScriptのプロジェクトを開けばまず入っている、というくらい広く使われていました。ところが、そのうちの1つを使いたいだけでも、使わないものを含めて丸ごとバンドルに入ります。この重さを解決したのは、提供側ではなく利用側でした。バンドラーがtree shaking、つまり使われていないコードを落とす仕組みを備えたのです。Tool Search Toolと発想はほぼ同じです。
lodashが減っていった本当の理由は、重さではありませんでした。JavaScript自体が育ったからです。map、filter、reduce、分割代入。lodashに頼っていた処理の多くが、言語の標準機能で書けるようになりました。標準機能で置き換えられる関数を一覧にしたものが作られ、その通りに書き換えるための検査ツールまで用意されたほどです。
重かったから外れたのではありません。なくても済むようになったから、外れていったのです。
私のMCPサーバで起きているのも、まさに同じことです。作成した当時は、スプレッドシートをそのまま渡しても正しく解釈されないと考えていました。しかし現在では、データを渡せば十分に内容を解釈でき、実用上ほとんど困ることはありません。プログラミング言語の進化によってlodashが不要になったように、AIモデル自体が進化することで、専用ツールの必要性が薄れつつあります。
規格を待たずに提供側でできること
では、選ばれるために提供側でできることはあるのでしょうか。4つあると思っています。
1つ目は、名前と説明の書き方を変えることです。検索されるのは、ツール名、説明、引数名、引数の説明です。つまり説明文は、人に読ませるためのものから、検索に引っかかるためのものになりました。公式のドキュメントも、利用者がその作業をどう呼ぶかに合わせたキーワードを入れること、サーバごとに名前の頭をそろえて一度の検索でまとまって出るようにすることを勧めています。私の「配分を軸別に返す」は、自分には分かりやすくても、資産配分を知りたい人の言葉とは違っていました。
2つ目は、読み取りと書き込みをサーバごと分けて、書き込みの方は必要な時だけつなぐことです。常時つないでおける数には限りがあります。使う見込みのない機能を並べておくのは、自分の読み取りツールの邪魔をしているだけなのかもしれません。
3つ目は、書き込みを2段階に分けることです。何がどう変わるかを返すだけの手順と、それを実際に反映する手順に分割します。主目的は安全で、間違った書き込みを一度止められます。あわせて、常時つないでおくのは軽い方だけにできます。
4つ目は、説明文を削れるだけ削ることです。ただし削るのは長さであって、検索に引っかかる言葉ではありません。
経路の途中でも既定値は変わる
呼ばれるかどうかを決めているのは、利用側の枠だけではありません。エージェントが自分のサイトにたどり着く前に、経路の途中で断られることもあります。Cloudflareは2026年9月15日に既定値を変えます。無料プランで設定を触っていない広告付きのページは、その日を境に、エージェントからのアクセスを既定で断る側に回ります。管理画面のセキュリティ設定から、それより前に変えておけば適用されません。自分のサイトが呼ばれるかどうかは、自分の設定だけでは決まりません。
公開するかどうかと選ばれるかどうか
情報を読みやすく渡すことと、MCPサーバを公開すること。同じ「エージェント対応」でも、性質が違います。分けて考えた方がよさそうです。
情報を渡す側は、やることがはっきりしています。Markdownを返し、robots.txtに方針を書き、APIの在りかを示す。誰が読んでも同じだけ役に立ちますし、やった分だけ読まれやすくなります。
MCPサーバは違います。用意するかどうかは自分で決められますが、選ばれるかどうかは決められません。決めるのは、依頼のたびに検索する相手の側です。しかも競争相手は、他のサーバだけではありません。何もつながずに生のデータを読んで済ませる、というモデル自体の選択肢もあります。モデルが賢くなるほど、そちらが選ばれやすくなるのかもしれません。
だとすると、MCPサーバを用意する前に確かめておくべきことがあります。それは、生のデータを読ませるだけでは実現できないことをしているのかどうか、です。自分自身のMCPサーバについては、正直なところ、自信を持って「はい」とは言えません。MCPサーバ対応の判断は、そこから始まります。
Copyright © ITmedia, Inc. All Rights Reserved.