ほとんどのエンタープライズAIのパイロットは、同じ場所で停滞します。
モデルの性能は十分で、ユースケースも明確で、APIも接続されています。それにもかかわらず、エージェントは一貫した動作をしません。正しいアクションを選ぶこともあれば、そうでないこともあり、その挙動は説明も再現も難しいものです。
チームは数週間にわたり、プロンプトの調整やモデルの変更、温度設定の最適化に取り組みます。挙動は一時的に改善しますが、再び悪化します。そして最終的に、ある疑問が浮かびます。それは「これは本当に本番環境で使えるのか」という問いです。
多くの場合、その答えは否です。そして原因はモデルではありません。
モデルが利用しているツールの設計にあります。
25以上のMCPサーバー構築から得た知見
過去1年間で、Workatoはエンタープライズシステム向けに25以上の事前構築済みMCPサーバーを開発・提供してきました。Salesforce、Workday、GitHub、Zendesk、Gmail、Slackなどが含まれます。これらは単に機能的に正しいだけでなく、あらゆるAIエージェントがそのまま本番環境で利用できるレベルの信頼性を備えている必要がありました。
このプロセスを通じて、一貫した設計原則が明らかになりました。うまく機能したサーバーはこれらの原則を満たしており、初期のうまくいかなかった設計は、それらに違反していました。その多くは一見すると問題がないように見える、微妙な設計上の違いでした。
これらの原則は「How We MCP」という4部構成のシリーズとして整理されています。本記事では、その要点と、エンタープライズにおいてMCPを評価・活用する際に何を意味するのかをまとめています。
核となる考え方：実行ではなく推論のために設計する
多くの開発者は、MCPサーバーをAPIと同じように設計します。表面的には似ているため、それは自然な発想です。ツールはエンドポイントに似ており、パラメータはリクエストボディ、レスポンスはAPIの出力のように見えます。
しかし、決定的な違いがあります。それは利用者です。
APIは開発者によって利用されます。開発者はドキュメントを読み、エッジケースを理解し、エラー処理を実装し、ロジックで挙動を制御します。不明点があれば調査します。
一方でLLMにはそれができません。与えられた情報だけがすべてです。ツール名、説明、パラメータ、出力。それらに明示されていないことは存在しないのと同じです。そして曖昧さがある場合、モデルは適切に失敗するのではなく推測します。この推測こそが、エンタープライズにおける信頼性を損なう原因です。
多くのチームが見落としているのはここです。MCPサーバーは実行インターフェースではありません。推論インターフェースです。この違いが設計の前提を根本から変えます。
4つの設計原則
25以上のサーバー開発を通じて、本番環境での信頼性を実現するために不可欠な4つの原則が明らかになりました。
Clarity over completeness
すべてを公開したくなるのは自然なことです。しかし複数の類似ツールが存在すると、モデルは確率的に選択することになります。Anthropicの検証では、大規模で曖昧なツールセットに対してClaude Opus 4のツール選択精度は約49%にとどまりました。必要なのはモデルの改善ではなく、明確で限定されたツール設計です。
Cohesion over convenience
1つのシステムのすべての機能を単一サーバーにまとめることは効率的に見えますが、信頼性の問題を引き起こします。複数のワークフローを扱うと解釈の曖昧さが生まれます。特定の役割と目的に特化したサーバー設計が、この問題を解消します。
Explicitness over inference
開発者にとって明白な前提は、モデルには見えません。副作用、制約、前提条件を明示しなければ、モデルは推測します。明記されていないものは存在しないのと同じです。
Determinism over cleverness
文脈に応じて出力が変わる「賢い」ツールは魅力的に見えますが、信頼性を損ないます。同じ入力に対して異なる出力が返ると、モデルは安定した期待値を持てません。特にマルチステップのワークフローでは破綻します。変化は許容されますが、隠れた変化は許容されません。
エンタープライズにおける評価基準
MCPベースのAIソリューションを評価する際には、これらの原則が基準となります。
サーバーが既存APIをそのまま移植したものか、特定のユースケースと役割に基づいて設計されているかを確認する必要があります。ツール説明がエッジケースや失敗時の挙動を適切に扱っているか、出力が構造化されているか、それとも解釈が必要な生データかも重要なポイントです。
デモが機能することと、本番環境で安定して動作することの差は、これらの設計にあります。
事前構築されたサーバーは、このギャップを大幅に縮めます。WorkatoのMCPサーバーは、Verified User Access、ツール単位のRBAC、監査ログ、クロスシステムのオーケストレーションを前提に設計されており、エンタープライズ要件に対応しています。
結論
AIエージェントの信頼性は、それが利用するツールの設計に依存します。開発者ではなくLLMのために設計することが、パイロットで終わるプロジェクトと本番環境で稼働するシステムを分ける要因です。
私たちはこれらの知見を4部構成のフィールドガイドとしてまとめました。設計の基本原則から具体的なツール設計まで、実践的な内容を網羅しています。