MCPは、分散システムで得られた40年分の教訓を軽視している

 (medium.com/@julsimon)
3 ポイント 投稿者 GN⁺ 2025-08-10 | 1件のコメント | WhatsAppで共有
  • MCP（Model Context Protocol） はAIツール統合の標準化を掲げる一方、40年間で蓄積された分散システムとRPCのベストプラクティスを無視するという問題がある
  • その結果、エンタープライズ環境では運用の信頼性、型安全性、セキュリティ、観測可能性、コスト管理などの中核機能が欠落してしまう
  • MCPは必須機能を外部ライブラリに依存するだけでなく、プロトコルの断片化と統合の複雑化、監査・セキュリティ管理の負担を生む
  • 分散トレース、スキーマのバージョン管理、サービスディスカバリ、パフォーマンス最適化など、主要な運用要件が依然不足している
  • MCPの早期導入は、AIブームを追い風にしてエンタープライズに深刻な障害、運用リスク、重複開発、不要なコスト発生を招く危険がある

MCPのシンプルさが招くリスク

MCP（Model Context Protocol）はAIツール間の統合を「AI分野のUSB-C」と標榜し、導入障壁を下げるシンプルさを強調している。しかし、このシンプルさは逆に40年間にわたり分散システムで蓄積された教訓を無視しており、実運用環境では致命的な機能欠陥を引き起こす。MCPを現在導入する企業は、本質的に必要なRPCシステム機能が欠けた基盤の上にシステムを構築していることになる。

現実と期待の危険なギャップ

MCPの提唱者はこのプロトコルをproduction-readyインフラとして紹介しているが、実際の設計思想は開発便宜に偏り、運用の堅牢性が不足している。短期間でAIツールを接続できる一方、数百万件規模で実際のビジネスに活用されると致命的な脆弱性が露呈する。AIへの過剰な市場期待により、アーキテクチャの成熟を経ることなく導入が先行し、結果として運用失敗に至るリスクが高い。

40年の歴史で繰り返される失敗

  • **UNIX RPC（1982年）では、32ビット整数のような異種システム間データ互換を実現するためにXDR（External Data Representation）およびIDL（Interface Definition Language）**を導入し、ビルド時に型不一致エラーを検出していた。
    MCPはこの経験を無視し、スキーマのないJSONと任意性の高いヒントのみを提供する。実行時に型エラーが発生し、AIが誤った日付を生成したり、金融・ヘルスケア・製造などの実務現場で致命的なデータ変換エラーや品質問題につながる可能性がある

  • CORBA（1991年）は複数言語間で同一インターフェースを保証するためにOMG IDLを使用していた。MCPでは各言語が別々に実装されるため、シリアライズ方式やエラー処理などで言語・ライブラリごとの一貫性がなく、統合の悪夢を招く

  • REST（2000年）はステートレス構造、HTTP verbベースの意味明確化、キャッシュヘッダなどで、大規模なスケーラビリティと信頼性を確保した
    MCPはstateful/statelessの区別が曖昧で、キャッシュ・標準リクエスト意味の区別・idempotencyサポートがない。サーバー拡張、リトライ、ロードバランシングが極めて難しい

  • SOAP/WSDLは強力な機械可読契約、容易な自動化、セキュリティ拡張性を備えていた
    MCPは単純なJSONスキーマのみを提供し、機械可読な契約、コード自動生成、型安全性、セキュリティ監査などの機能が欠如している。OAuth 2.1も後になってHTTP転送時にのみ追加され、stdioは環境変数に依存するなどセキュリティ統制も不十分

  • gRPC（2016年）は観測可能性、分散トレース、双方向ストリーミング、デッドライン、構造化エラーコードを内蔵で提供
    MCPはEvent形式の一方向ストリーミングのみをサポートし、複雑な相互作用の実装には非効率である。トレースコンテキスト、デッドライン、エラー分類などの必須要素が不足している

「このライブラリだけ使え」という危険

MCPは重大な欠陥が指摘されるたびに、サードパーティライブラリ追加（例：mcp-oauth-wrapper, mcp-tracing-extension, mcp-schema-generator）を回答として提示する。しかし、これはプロトコルの本質的な失敗点である。主要機能が外部に分散されるほど断片化、非一貫性、保守・セキュリティ・連携責任の分散の問題が深刻化する。
エンタープライズでは数か月以内に標準化・監査・統合負担が拡大し、開発者教育や外部依存も異常に高くなる。

追加入れで積み重ねられる暫定パッチ

MCPの2025-03-26版は、運用環境で後から発見された欠陥を後付けで追加したパッチノートと同じだ。OAuth、セッション管理、ツール属性（annotation）、進行状況通知などは、最初から必須だった機能を後から追加しただけにすぎない。
ツール属性の区別なども初期には欠け、セキュリティ認証も当初は不要と見なされていた。これは、エンタープライズ要件に対する本質的理解が不足していることを示している。

デバッグの悪夢と運用トレース不能

gRPC環境では、分散トレースとトレースIDにより、迅速で一貫したデバッグが可能
一方、MCPはリクエスト間の相関IDが存在しない、ログフォーマットの不一致、独自実装要求などによりデバッグ・エラー追跡に数日を要する
運用・ビジネスの観点でもコスト配分と使用量管理（ヘッダ、トークンカウント、クォータ等）が不可能。
クラウド環境では、基本的な機能がMCPではそもそも提供されないため、AI使用コストと責任所在の追跡がほぼ不可能

なお残る主要な運用上の問題点

  • サービスディスカバリの欠如により、可用性・マルチリージョン拡張・無停止更新が不可能
  • ツールごとのスキーマバージョン管理の欠如により、ツール更新時に予告なしでクライアント全体が壊れるリスクが常に残る
  • パフォーマンスの限界: JSONオーバーヘッド、接続プーリングの欠如、バイナリプロトコル・圧縮などの不足、プロセス単位通信方式など旧世代のパターンの反復

エンタープライズ適用時の深刻なリスク

AIが実際の収益・安全・品質責任領域（金融、医療、製造、カスタマーサポートなど）に入り始めると、MCP導入の危険性は高まる
長年構築してきた堅牢な統合パターンを捨て、セキュリティ・監査・型安全性・運用安定性を後付けで暫定補完することになる
試験レベルのプロトタイプで「速く作って壊す」戦略は、重要なサービスに致命的な結果をもたらす

改善の方向性と長期的要件

  • 短期: プロトコル内蔵レベルで型安全性、分散トレース（相関ID）、権限付与、標準監査フォーマット、ツールごとの独立したスキーマバージョン管理が必須
  • 運用側面: サービスディスカバリ、接続プール、バイナリ送信、デッドライン、標準化されたエラー・リトライポリシーなどが求められる
  • 長期: 双方向ストリーミング、内蔵クォータ・コスト管理、SLA enforcement、ワークフローオーケストレーションなどエンタープライズ級機能の追加が必要

結論

MCPのシンプル志向な設計は、実験的・短期のAIツール統合には適しているが、エンタープライズ級の運用環境では致命的に運用リスクと運用コストにつながる
AIブームに便乗して導入が前倒しされることで、セキュリティ・観測可能性・運用安定性といった必須機能を後から追加する暫定的対応が繰り返されている。
結果として、プロトコルが防ごうとした断片化と重複開発が、逆にMCP上で再現される危険がある
AI産業は40年分の分散システム発展史を無視して、既に解決された問題を再度経験するか、歴史から学ぶかの分かれ道に立っている
このままでは導入失敗、セキュリティ欠陥、運用悪夢が繰り返され、そのコストは全責任をエンタープライズが負うことになる

関連記事

1件のコメント

 
GN⁺ 2025-08-10
Hacker Newsのコメント

  • 最初はタイトルだけ見て、典型的なセキュリティー・ショーの話だと思っていました。ところが読んでみると、かなり示唆に富んでいると感じました。特に目立ったのはこの点です。MCPはこの教訓を無視して、スキーマを持たないJSONに対して型に対する厳密でないヒントを使っており、型検証が実行時に行われるか、そもそも行われないことがあります。たとえばAIツールがISO-8601タイムスタンプを期待していたのにUnixエポック値を受け取ると、モデルは適切に失敗せず、あり得ない日付を作り出せてしまう可能性があります。こうしたことが金融サービスでは、AIが数字を誤って解釈し誤った小数点精度で取引を実行してしまう原因になり、ヘルスケアでは患者データの型変換が誤って誤った処方量が推奨されることにつながる可能性があります。製造業では、センサーデータがJSONシリアライズ処理で精度を失い、品質管理の問題に発展することがあります。LLMを毎日扱っている立場からすると、この問題は実際に頻繁に見られます。今後、どこかのMCP導入システムで大事件が起き、事故記録を読むと、MCPサーバーが異常なデータを出力し、LLMがそれを受け取って的外れな幻覚出力をし、その結果が連鎖してさらに大きな問題に発展するという状況が想像できます。人為的なミス、例外処理のないLLMの特性（幻覚発生）、そしてスタートアップが新サービスを急いで出す文化まで、すべてが組み合わされれば新しい種類のバグが生まれるのは避けられません。そしてこの問題が起きると、TwitterユーザーはAGIが核発射コードをハッキングすると延々と騒ぐことでしょう。その場面もかなり面白いと想像します

    • 正直に言うと、2023年以前は『スター・トレック』に出てくる技術的なバグやエラーはあまりにも作り事に見え、実際に起こることはないと思っていました。しかしLLMの登場以降、そういうことが実際に起こり得ると感じています。LLM統合がいったいエンジニアリングとどのような関係にあるのか分からず、会社全体のインフラを外部制御に任せることがどれほど合理的か疑問です。さらに再現性の欠如も考えると、「なんとなく動けばいい」がエンジニアリングと言える状況ではありません

    • 著者の批判がよく理解できません。MCPはJSON Schemaをサポートしているため、サーバー応答は必ずそのスキーマに従う必要があります。たとえばISO-8601タイムスタンプを要求するスキーマなのにサーバーがUnixエポックを送ると、明らかなプロトコル違反です。記事ではMCPがJSON Schemaをサポートしながら型安全なクライアントを生成できないと主張していますが、すでに数多くのJSON Schemaコードジェネレーターが存在するため、これは事実と異なります

    • すでにPEBKAC（ユーザーのミス）は存在しますが、LLMはそれを自動化するほどです

    • 医療分野でデータ型変換の誤りが処方の間違いを招く可能性について、実際に医療テレメトリーの仕事をしていた経験があり、タイムスタンプを正しくパースすることの重要性を痛感しました。おそらく、ユニットテストを最初に書いた理由もこれが原因だったのでしょう。NTPがない状況でも、ヘッダのタイムスタンプを再計算して補正したことがあります。こうした対策は、事故レビューや医療過失責任の問題が背景にありました。たとえば、心停止直前に薬を投与された時間と、その後に投与された時間の差で命が分かれることがあります。最近の英国ポストの事例のように、1つのデータエラーで人生が壊れることがあり、医療データでは1分の差が世界をひっくり返すことがあります

    • MCPの目的は転送とコンテキスト管理です。つまり、スキーマ定義と検証のような適切なインターフェース実装の責任は利用者側にあります。これは「HTTPがJSON検証をサポートしていない」という批判と似ています。もっと言えば当たり前のことです

  • MCPが『AI界のUSB-C』になるつもりだとしても、皮肉にもこれはMCPの成功より、USB-Cの欠点を示す事例だと思います。USB-Cはほぼすべて接続できるが、標準への準拠が散漫なため、MCPの一貫性のないJSONパースやプロトコル不遵守と同じです。複数種類のUSB-Cケーブルが存在する現実のように、見た目はユニバーサルでも実際は極めて複雑な状況が隠れています。むしろ、明確に分離されたAPIやプロトコルの方が良いと思います

    • USB-Cの失敗が極端に露出した例は、Appleが最新のM4 Mac miniからUSB-Aポートをなくしたことから始まりました。見た目は同じでも、実際にはまったく異なる性能を持つポートがあり、ユーザーは製品発表時とは違って後から知ることになります。以前はApple Siliconデスクトップ/ラップトップのUSB-Cはすべて40Gbps Thunderboltだと期待できましたが、今では一部がUSB3 10Gbpsです。どのポートがどちらかは、仕様書を直接確認するか小さなアイコンを見る必要があります。もしUSB-Aポートをいくつか残しておけば、10Gbpsという制限を明確に示せたでしょうが、逆にUSB-Cブランド価値をさらに薄めただけです。結局、ほとんどのUSB-CデバイスでもUSB-Aに変換するアダプタを使って接続し、USB-Cバージョンは高価で希少である上、品質もあまり良くありません。それでも、ハイプとファンダムが実用性や使いやすさを上回る世界です

    • 正直、あのライン（USB-C＝ユニバーサルだが実態は不透明）を見て大笑いしました。目標達成、というわけです

  • SOAPについて『冗長だがMCPが知らない何かを理解している』という評価を聞きますが、現実にはSOAP自体もあまり理解されていませんでした。実際、レガシーSOAPシステムの保守作業をしている身として、SOAPを褒めることは一切ありません。誰もが手本にできる存在ではないと思っています

    • 実際、SOAPは凄まじい惨事でした。シンプルにすべき概念をどうしてこんなに複雑にしたのか不思議です。XMLが複雑だっただけでなく、WSDLやマルチHTTPパートなど、定義が不明瞭な基準、他の言語との相互運用性が保証されない点（例：.NETサーバーとJavaクライアントでSOAPを使った経験など）までありました。流行が過ぎると人は良い点だけを覚えますが、私はむしろ1か月SOAPを使うより、50年間スキーマなしJSON API開発をすることを選ぶでしょう。個人的にはprotobufやcapnpの方がずっと良いと思っています

    • REST（実際にはJSON-RPC）やGraphQLはまだSOAPとSOAが提供していた機能を追いつこうとしていると思います。新技術が出るたびに良いところまで捨ててしまうのは残念です

    • 『Simple』という言葉が入ったプロトコルは、常にシンプルではありませんでした。もうすぐSMCPのようなプロトコルを見る予感があります

    • 非常に面白く、かつ正確なSOAP説明リンクを共有します https://harmful.cat-v.org/software/xml/soap/simple。自分はXMLベースの技術が好きで、特にXML Schemaの型の組み合わせと検証機能は今でも群を抜いていると思います。しかしSOAPはなぜか巨大な怪物になったように感じます。必要だったのは単純なリモート呼び出し仕様だけだったのに、すべてを定義しすぎて、結局どれもきちんと扱えない仕様になってしまいました。SOAPは多様な転送プロトコルのサポート（SOAP over emailまで）、複数種のRPC、UDDIなどの自己記述RPCまでサポートすると言いますが、実際の重要実装は認証、キャッシュ、HTTPレスポンスコードなどがすべて利用者の責任でした

    • 皮肉なことに、SOAPを生涯拒絶するきっかけになったのは当時聞いたSOAP技術のプレゼンテーションでした。まったく同じ言語間ではそれなりに動いていましたが、言語が違うと最悪でした。MicrosoftがSOAPをそこまで好んだ理由もそこにあると思います

  • CORBAは1991年に「異種環境では単純に各言語ごとにプロトコルを実装するだけではいけない」という洞察を持って登場し、OMG IDLが複数言語で同一バインディングを生成してインターフェースの一貫性とシリアライズ問題を防いだ点は正しいです。ただ、本当に成功した事例だったのかは疑問です

    • 現在のJSON中心API環境は、CORBAとSOAPの失敗への反動として現れたものです。CORBAの教訓を忘れなかったというより、意図的に拒絶したと見なせます

    • CORBAを非常にうまく活用していた現場で働いた経験があります。恐らく成功した理由は、チーム内にCORBA開発経験が豊富なシニアエンジニアがいたからだと思います

    • 1998年にAT&TのCORBAを使う職場に応募したのが当時最後の経験でした（その後はJDKのダウンロードを遅くする以外見たことがありません）。当時、面接官は私が書いた並行処理コードが気に入らないと言い、代替案には競合条件があるにもかかわらず説得できませんでした。後にJava Memory Modelの問題で、実際には私の答えのほうが正しかったという結論になりました

    • CORBAは多くの点で優れていましたが、80年代後半の従来型テレコムネットワークとOOPブームの産物でした。したがって、ネットワークは透過的で信頼でき、対称的であるという根本的な前提が埋め込まれていました。実際の現場では、タイムアウト、リトライ、ネットワーク混雑、システムクラッシュがあり、そうではありません。特にCORBA C++バインディングはSTL登場前だったため極めてひどく、他の言語側の方がむしろ良かったです

    • 技術的には優れているが商業的には失敗したプロジェクトでも、その優秀さを十分認めることはできます

  • MCP議論で見落とされている『MCPが正しく学んだ核心的教訓』は、むしろ高度な機能が複雑性を生み、ほとんどの現場がシンプルなものを選ぶことになるという点です。だからJSON over HTTPが主流になったのでしょう。大手テック企業でもgRPCのような高機能シリアライゼーションプロトコルへの移行は何年もかかり、その途中で何度も失敗することがあります。MCPの本来の役割は、シンプルなJSON API契約を標準化し、LLM向けトークンやツール呼び出しスタイル生成などを簡単にすることだと考えています

    • HTTP blobsが何か気になります。結局JSONがXMLに勝利した理由を言いたかったように思えます

  • MCPは完璧ではありませんが、数十年のRPC史で複雑性が導入と活用を最も難しくしたという教訓は、XMLに対するJSONの台頭と同じくらいしっかり学んでいます。SOAPはシステム間相互運用性のために過度に複雑で、XMLとスキーマもあまりにも冗長でした。CORBAはライブラリとフレームワークが複雑で、当時の最新言語では忌避対象でした。gRPCは速いが可読性が低く、マッピングが必要です。今日のRPCの骨格はRESTとJSONです。前述した標準は周縁化されるか、gRPCだけが極端な高性能要求に限定されて残っています。RESTとJSONが主流となった背景にはこの単純さの勝利があり、MCPもこの流れに沿って設計された結果だと言えます

  • 良い意見がたくさんありました。私たちはMCPを誤解していると思います。より重要なのは、産業全体でAgentが何であるか、そして今後どこへ向かうかについての誤解と方向性のズレです。多くのウェブプラットフォームでは、Agentがネットワーク分散インフラに埋め込まれると信じ、コンテナ内のすべてのAgentをサービスメッシュ経由でMCPに接続することを目標にしています。私見では、こうした『ウェブネイティブなAgentやSDK/フレームワークはサーバーアプリケーションのようにデプロイされるべき』という主張は誤りで、それらはAgentではなく、進化の初期段階ですらない。真のAgentハーネスはFrontier Labsなどごく少数の提供者しか作れず、最終的には個人向け（例：自分のデスクトップにClaude Desktop用MCPサーバー1台）へ向かうでしょう。MCPサーバーは本来このようなシングルインスタンスおよびハーネス向けです

    • MCPの問題はエンタープライズ向けに不適切に設計されていることではなく、LLMを間違った場所で使うことの方が大きいです。たとえば金融サービスでAIが小数点精度エラーで取引を実行すること自体は、プロトコルの問題ではなく、制約のないLLMに取引を任せることの問題です。また、LLMが日付フォーマットを誤解して幻覚値を吐き出す状況も、そうしたクリティカル環境にLLMを投入すること自体の問題です

  • 誰かMCPがなぜSwaggerやprotoより必要なのかを明確に説明してほしいです

    • OpenAPI(Swagger)やProto(protobuf)は、それぞれMCPの役割を全部カバーできません。理論的にはこの上にMCPを載せることも可能でしたが、MCPのローカル利用ケースにはSwaggerの通信方式の前提が合わず、protobufは元々通信プロトコルを含まないため追加設計が必要です。JSON-RPCを置き換えても、結局MCP仕様のほとんどを維持する必要があり、むしろ複雑になってしまいます

    • MCPは新しい技術です

    • MCPはストリーミングレスポンスをサポートします。ポーリングやセッションstateで実装することもできますが、それは非効率な近道に過ぎません

  • OpenAIが先月のAPI利用で$50,000請求された時、どの部署のMCPツールがそのコストを引き起こしたのか、どの個別ツール呼び出しやユーザー、ユースケースだったのか区別できない状況です。AI技術の多くはあとから問題に追いつく格好になっています。しかしウェブフレームワークやブロックチェーンと同様に、技術が巨大すぎると初期段階で完璧に全てを把握することはできません。差は最終的に徐々に縮まります。AIでも引き続きアイデアと危機意識を共有しなければならない点には同意します。現在は本当に興味深い時代です

  • より良い設計と十分に良い設計のどちらかを選ぶとき、私は常に「十分に良い」方が勝つと思っています。Multics対Unix、XMLベースSOAP対JSONベースREST、XHTMLの失敗、JavaScriptそのものなど、例は挙げ続けられます。だから人は毎回「より良い」を再実装し、問題が表面化すると応急処置であてにならない修繕をしながら生きる運命だと覚悟しました

    • これはよく知られたWorse is Better現象の繰り返しです（https://en.m.wikipedia.org/wiki/…

    • xforms 2.0のために1分の黙祷が必要です。私たちが生きていたかもしれなかった世界: きちんと動作するウェブフォーム検証、マイクロデータ...