最終更新日: 2026-07-28
AIへ接続するサービスを増やせば、使える能力は増えます。でも、接続数と賢さは同じではありません。仕事を始める前から大量のツール定義を読ませると、ユーザーの依頼、会話履歴、判断材料に使える文脈が狭くなるからです。
FORMLOVAのソースを静的に測ると、MCPの共通指示、ツール説明、入力項目の説明だけで110,220文字、4文字を1トークンとする概算で約27,555トークンありました。これはライブクライアントの消費量ではなく、JSON Schemaの構造部分も除いた下限寄りの値です。
この記事では、MCPフォームの一般的な定義ではなく、「大規模なツール群を、いつモデルの文脈へ入れるか」を扱います。MCPフォーム全体の入口はMCPフォームサービスまとめ、作成後の運用レイヤーを設計する理由はMCPフォームサービスとはに分けています。
先に結論 -- 問題は接続数ではなく、先に見せる定義量です
MCP公式ドキュメントは、MCPをAIアプリケーションと外部システムをつなぐオープン標準と説明しています。つながること自体には価値があります。カレンダー、文書、CRM、フォームへ同じAIクライアントから届けば、会話を実際の仕事へ進められます。
ただし、MCPは接続しただけでツール定義を軽くする規格ではありません。
MCPサーバーはtools/listで利用可能なツールとスキーマを返します。その一覧から、どの定義をいつモデルへ渡すかはホスト側の設計です。数個なら全件を先に見せても問題になりにくいでしょう。数百、数千へ増えると、先読みそのものが文脈コストになります。
したがって、見るべき数字は「何サービス接続したか」だけではありません。
接続できる能力
先にモデルへ見せる定義
実行時に必要な情報
人が承認する操作
この4つを分ける必要があります。
FORMLOVAで測った静的な文脈コスト
FORMLOVAは、フォーム作成、回答管理、メール、分析、ワークフロー、LINE連携など、公開140ツールを26カテゴリで提供しています。人が目的から始めやすいように、公式Workflowも50件用意しています。
一方、ソース上の静的計測では141ツールを数えます。公開数との差分1件は、内部の会話トレース記録に使うrecord_conversation_traceです。公開ツール数140と、内部の登録・健康診断対象141を混ぜてはいけません。
2026年7月28日にnpm run mcp:token-footprintで測った結果は次の通りです。
| 静的計測の対象 | 文字数 | 4文字/tokenの概算 |
|---|---|---|
| MCP INSTRUCTIONS | 34,072 | 8,518 tokens |
| ツールdescription（内部141件） | 54,330 | 13,583 tokens |
Zodの.describe() | 21,818 | 5,455 tokens |
| 合計 | 110,220 | 27,555 tokens |
この表は、クライアントへ届く実際のJSONをtokenizerで測ったものではありません。ソース内の文字列を数え、4文字で1トークンと概算した静的測定です。JSON Schemaのプロパティ名、型、enum、必須項目、外側のJSON構造は含みません。文字列として評価できなかった.describe()も2箇所あります。
そのため「FORMLOVAを接続すると必ず27,555トークン使う」とは言えません。ホストによってinstructionsの扱い、スキーマ変換、キャッシュ、注入範囲、tokenizerが違うからです。
言えるのは、140ツール規模では、説明文だけでも無視できない量になるということです。そして、実際の転送コストはこの計測より大きくなる可能性があります。
MCPのTools、Resources、Promptsは制御主体が違います
大規模な接続を整理するときは、MCPの機能を一つの「全部モデルへ渡す箱」と考えない方が分かりやすくなります。
MCPのServer conceptsでは、3つの主要機能を次のように分けています。
| 機能 | 役割 | 主な制御主体 |
|---|---|---|
| Tools | モデルが呼び出す操作 | model-controlled |
| Resources | アプリケーションが選んで文脈へ入れるデータ | application-controlled |
| Prompts | ユーザーが明示的に選ぶテンプレート | user-controlled |
この分担は、文脈配分のヒントになります。
Resourcesは、アプリケーションが必要な部分を選び、検索し、文脈へ入れられます。Promptsは、ユーザーが目的に合うものを選べます。Toolsも「利用可能であること」と「全定義を常時モデルへ見せること」を分けられます。
FORMLOVAの50件の公式Workflowは、MCPプロトコルのツール検索そのものではありません。業務目的から使い方を見つけるためのプロダクト上のカタログです。Workflow Placeからレシピを見つける方法で人の選び方を助けますが、ホストがモデルへ注入するツール定義を自動で減らす機能ではありません。
MCPとツール検索は、同じものではありません
ここが一番大切です。
FORMLOVAのMCPサーバーは、現時点でサーバー側のsearch_toolsを実装していません。tools/listは公開140ツールを返します。そこから全件をモデルへ入れるか、必要な定義だけを遅れて入れるかは、接続先のホストが決めます。
MCP公式のClient Best Practicesも、この責任をホスト側の課題として説明しています。ホストは通常通りtools/listで定義を取得しつつ、最初から全件をモデルへ注入せず、軽量な検索手段を渡し、必要になった定義だけを読み込めます。公式文書では、これをprogressive discoveryと呼んでいます。
よく使われる形は3段階です。
- Catalog: 名前と短い説明から候補を探す
- Inspect: 候補ツールだけ完全な入力スキーマを読む
- Execute: 選んだツールを呼び出し、必要な承認を挟む
サーバー側の責任は、検索されても意味が伝わる名前、説明、スキーマ、権限境界を提供することです。ホスト側の責任は、現在の依頼、利用者の権限、利用可能な文脈量に合わせて、モデルへ見せる範囲を決めることです。
ツールを隠せばよいわけでもありません。公開、送信、削除などの重要操作が検索から漏れれば、仕事は完了しません。常時見せる少数の中核ツール、検索対象にする長い裾野、実行前に人へ戻す操作を分ける設計が必要です。
50以上のツールで85%削減した例は、他社の社内テストです
段階的発見の効果を示す一次資料として、AnthropicのAdvanced Tool Useがあります。
同社の例では、50以上のMCPツールをすべて先読みする構成で、仕事を始める前の文脈消費が約77K tokensでした。Tool Search Toolを使う構成では約8.7K tokensとなり、85%削減したと報告しています。
ただし、これはAnthropicの構成と社内テストです。FORMLOVAで同じ削減率を確認した結果ではありません。
FORMLOVAの約27,555 tokensは、ソース文字列を4文字/tokenで換算した下限寄りの静的値です。Anthropicの77Kと8.7Kは、同社のツール検索構成で測った総文脈消費です。対象、tokenizer、システムプロンプト、スキーマ、ホスト実装が違うため、数字を直接比較して「FORMLOVAでも85%減る」とは言えません。
参考にできるのは割合ではなく、方法です。
全件を取得できる状態は維持する
全件を最初からモデルへ入れない
依頼に合う候補だけを探す
完全な定義は必要になった時点で読む
この順番なら、能力を捨てずに文脈を守れます。
2026-07-28版は、まだ「公開候補（RC）」です
文脈配分と、プロトコルの状態管理も分けて考える必要があります。
MCP公式ブログは2026-07-28版を、ステートレスなコア、Extensions、Tasks、認可強化などを含む公開候補（RC）として案内しています。2026年7月28日現在、公式GitHub Releasesでもpre-releaseであり、stableは2025-11-25です。
ステートレスなコアは、接続状態を暗黙のセッションへ抱え込まず、通常のHTTP基盤でルーティング、キャッシュ、追跡をしやすくする変更です。「AIが忘れるようになる」という意味ではありません。フォームの下書き、認証、業務の進行状態は、アプリケーション側で明示的に管理する必要があります。
そして、ステートレス化だけでツール定義が自動的に絞られるわけでもありません。tools/listをキャッシュしやすくすることと、その全定義をモデルへ注入することは別の判断です。
大規模MCPで先に決めたい6つのこと
140ツールを作った経験から、機能追加の前に確認したい項目は6つあります。
| 判断 | 確認すること |
|---|---|
| 測る | instructions、description、入力スキーマを別々に測る |
| 閾値を持つ | 文脈ウィンドウの何%を超えたら段階的発見へ切り替えるか |
| 検索前に絞る | 利用者の権限、プラン、環境で呼べないツールを候補から外す |
| 中核を残す | 認証確認、状態確認、検索など頻出の少数は常時見せる |
| 承認を分ける | 読む操作と、送信・公開・削除など外部影響のある操作を分ける |
| ライブで検証する | token量だけでなく選択精度、遅延、失敗時の回復も実クライアントで測る |
カテゴリ分けやWorkflowは、人とモデルが目的を見つける助けになります。でも、それだけで文脈コストは下がりません。最終的には、ホストで段階的発見を実装し、実際のクライアントで測る必要があります。
AIの知性は、接続数より文脈の配分で変わります
MCPは2025年12月、Linux Foundationが設立したAgentic AI Foundationの創設プロジェクトの一つになりました。共通基盤として広がれば、AIが利用できるサービスとツールはさらに増えます。
だからこそ、「全部つなぐ」と「全部読ませる」を同じにしないことが大切です。
FORMLOVAに140の公開ツールがあることは、フォーム運用へ届く能力の広さを示します。AIがその能力を正しく使えるかは、別の設計問題です。必要なときに、必要な定義だけを見つけ、危険な操作では人へ戻す。機能数が実務の価値へ変わるのは、その経路が整ったときです。
MCPの価値は、AIへ無制限に情報を押し込むことではありません。外部世界へ届く能力を保ちながら、今の仕事に必要な文脈を配分できることです。
参考にした一次資料
- Model Context Protocol: What is MCP?
- Model Context Protocol: Understanding MCP servers
- Model Context Protocol: Client Best Practices
- Anthropic: Introducing advanced tool use
- Model Context Protocol Blog: The 2026-07-28 MCP Specification Release Candidate
- Model Context Protocol GitHub Releases
- Linux Foundation: Agentic AI Foundationの設立
接続ガイド: FORMLOVAをMCPクライアントに接続する
執筆・確認情報
この記事はFORMLOVAの開発者が、2026年7月28日時点のdocs/SPEC.md、MCPツール登録ソース、静的計測スクリプト、MCPとAnthropicの公式一次資料を照合して執筆しました。公開数は140ツール・26カテゴリ、公式Workflowは50件です。内部計測の141件にはrecord_conversation_traceが含まれます。静的計測値はライブMCPクライアントの課金量、入力token数、精度改善を示すものではありません。MCP 2026-07-28版は現時点で公開候補（RC）であり、stableは2025-11-25です。
