誰も測定していない品質ギャップ

ソフトウェアではすべてを測定する。コードカバレッジ。レスポンスレイテンシ。エラー率。アップタイム。バンドルサイズ。Lighthouseスコア。

しかしMCPサーバー——AIエージェントが世界と対話するために依存するツール——については何も測定していない。

MCPツールの説明が十分かどうかの基準がない。スキーマの完全性のベンチマークがない。何もない。

これはドキュメント、テスト、モニタリングなしでREST APIを出荷するようなものだ。APIでは絶対にしない。MCPサーバーでは毎日やっている。

誰もMCP品質を測定しない理由は、障害モードが微妙だからだ。MCPツールの設計が悪くても、LLMはクラッシュしない。エラーを投げない。ただ...時々間違える。

ユーザーが「先月の請求書を全部見つけて」と聞いて、LLMが間違ったツールを呼ぶ。ユーザーは間違った答えを見てAIを責める。「MCPサーバーのツール説明が曖昧かもしれない」とは決して思わない。

これが品質問題をこれほど陰険にしている。症状は拡散している。AIの限界のように見え、ツール設計の問題には見えない。

数千のMCPサーバーを分析した結果、LLMがツールを正しく使うかどうかを予測する6つの次元を特定した。

説明の品質。スキーマの精度。命名の明確さ。重複の検出。エラー処理。パラメータの複雑さ。

各次元は独立して測定可能。合わせると、驚くべき精度でLLMの成功率を予測する。

測定だけでは改善につながらなければ無意味だ。品質スコアリングの力はスコアではない——それに伴う具体的で実行可能なフィードバックだ。

「説明品質は62/100です」はまあまあ興味深い。「search_documentsツールの説明がレスポンス形式を指定していないため、LLMが23%の確率で間違ったフィールドを要求しています——これがより良い説明です」は変革的だ。

最高の品質システムは測定するだけでなく——修正する。温度計とエアコンの違いだ。

MCP品質について直感に反すること：現在の基準が非常に低いため、控えめな改善でさえ大きな差別化を生む。

平均的なMCPサーバーが60/100で、あなたのが85/100なら、LLMはあなたのツールで劇的に成功する。ユーザーはなぜかわからないまま、あなたの統合を選ぶ——「なんかうまくいく」から。

MCP品質はAI時代のLighthouseスコアだ。今測定を始めるチームは、すべてのユーザーインタラクションで複利的に増す優位性を持つ。

ギャップはそこにある。問題は誰が最初に埋めるかだ。