MCPは分散システムから得た貴重な教訓を無視している

2025年8月9日原文(julsimon.medium.com)

概要

Model Context Protocol (MCP) はAIツール連携の標準化を目指すが、 分散システムの歴史的教訓 を無視。 運用面の堅牢性 よりも 導入の容易さ を重視し、企業利用で致命的な欠陥を露呈。 型安全性・認証・トレーシング・コスト管理 など基礎機能が欠落。 エコシステム断片化 と 後付けの機能追加 が混乱を助長。 本番運用での大規模障害リスク と 運用コストの増大。

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

MCP は「AIのUSB-C」として 簡単な導入 をアピール
分散システム で40年培われた 必須機能 を軽視
本番運用 での 型安全性・エラー処理・認証 等が不十分
AIブーム による 過剰な期待 と 実装の未熟さ の乖離
企業の本番導入 で 重大な障害 や データ破損 のリスク

過去プロトコルの教訓とMCPの見落とし

UNIX RPC/XDR ： 異機種間の型保証 と IDLによる事前検証
- MCPは スキーマレスJSON で 型不整合 を見逃しやすい
- 金融・医療・製造 での データ誤解釈 リスク
CORBA ： 多言語間の一貫性と例外伝播
- MCPは 各言語実装がバラバラ で 互換性・バグ対応 が困難
REST ： ステートレス性・キャッシュ・明確な操作意味
- MCPは 状態管理が曖昧 で リトライやスケーリングが困難
SOAP ： 機械可読な契約・セキュリティ・一貫したエラー処理
- MCPは WSDLのような契約管理がなく、 認証も後付け
gRPC ： 分散トレーシング・双方向ストリーミング・デッドライン
- MCPは 片方向ストリーミングのみ、 トレースや期限伝播なし
- エラー分類も貧弱 で 運用トラブル時の特定が困難

「サードパーティライブラリで補完」問題

MCP推進者 は「このライブラリを使えば解決」と主張
- 認証・トレーシング・IDL生成 が 外部依存
プロトコル標準化の本質 を損なうエコシステム断片化
企業運用 では
- ライブラリ選定・保守・相互運用性 の課題
- セキュリティ監査や教育コスト の増大
- gRPCやREST のような 一体型標準 との対比

MCPのパッチワーク的進化と運用リスク

2025–03–26改訂 で OAuth・ツール属性・セッション管理 等を追加
- これらは 後付けの欠陥補修 に過ぎない
read-only/destructive 属性追加も 設計思想の後退
認証未実装でリリース された経緯は 企業要件の誤認
本番障害後の後追い実装 が続く

デバッグ・コスト管理・運用上の致命的ギャップ

分散トレーシング非対応 で 障害調査が数日規模
コスト帰属情報なし で AI利用料の部門別分析が不可能
- AWSやGoogle Cloud のような 詳細なコスト管理 が不可
サービスディスカバリ・バージョン管理・パフォーマンス も未整備
- ダイナミックなスケーリングやフェイルオーバー に非対応
- スキーマバージョン管理なし で ツール更新時の互換性リスク
- JSONのオーバーヘッド で 高負荷時に性能劣化

まとめ：MCP採用時の注意点

導入の容易さ と 運用堅牢性 はトレードオフ
分散システムの歴史的教訓 を無視した設計は 本番障害の温床
企業利用 には 型安全・認証・トレーシング・コスト管理 などの 基礎機能 が必須
外部ライブラリ依存 による 断片化と運用負担増
本番導入前に、 要件に合致するか慎重な評価 が必要

Hackerたちの意見

これを三回読んだんだけど…OpenAIが先月のAPI使用料で5万ドル請求した時、どの部門のMCPツールがそのコストを生んだか分かる？どの特定のツールの呼び出し？どの個々のユーザーやユースケース？…AIに関しては、ほとんどのことが追いつくのに時間がかかってる感じだね。とはいえ、私の考えとしては、特定の技術は早い段階で理解するには大きすぎると思うんだ。ウェブフレームワークやブロックチェーンとか…最終的にはそのギャップは縮まっていくんだろうね。AIについては、ここで君が言ってるように、アイデアや注意を共有し続けるしかないよね。今の時代は本当に面白いね。

CORBAは1991年に登場して、もう一つの重要な洞察を持っていたんだ。異種環境では、各言語で「プロトコルを実装する」だけじゃダメだってこと。OMG IDLはC++、Java、Pythonなどで一貫したバインディングを生成して、サーバーが投げたC++の例外がJavaクライアントで正しくキャッチされるようにしてた。生成されたバインディングは、すべての言語が同じインターフェースを見れるようにして、微妙なシリアル化の違いを防いでた。そう、CORBAは本当に成功だったよね。

└

寛大に考えれば、商業的に成功しなかったプロジェクトを見て、その技術的な素晴らしさを評価することもできるよね。

└

そうそう、現代のJSON中心のAPIの風景は、CORBAとSOAPの失敗に対する反応として生まれたんだ。CORBAの教訓を忘れたわけじゃなくて、むしろ拒否したんだよね。

└

CORBAは多くのことをうまくやってた。でも、残念ながら80年代後半のテレコムネットワークとOOPのハイプが混ざり合った子供だったから、ネットワークが透明で信頼できて対称的だという核心的な前提が組み込まれちゃったんだ。だから、一台のマシンでオブジェクトを作って、別のマシンにその参照を渡しても、すべてがうまくいくはずだった。でも、実際の世界ではタイムアウトやリトライ、混雑したネットワーク、クラッシュするコンピュータがあるから、そんなことは起こらないんだよね。あ、CORBAのC++バインディングはSTLが標準化される前に設計されてたから、もう最悪だった。他の言語の方がマシだったよ。

└

俺はCORBAがかなり使われてて、効果的だったところで働いたことがあるけど、成功の理由は上級ソフトウェアエンジニアの一人が直接CORBAに関わってたからだと思う。

└

1998年にCORBAを使ってAT&Tに応募したけど、それが最後にCORBAに出会った時だと思う。それ以外はJDKのダウンロードを遅くするくらいだった。結局その仕事は取れなかった。面接官の一人が同時実行コードを書くように言って、私の答えが気に入らなかったけど、彼のコードにはレースコンディションがあって、彼が間違っていることを納得させられなかった。彼は特定の命令でプリエンプションが発生しないこと（またはマルチプロセッシングが起こらないこと）に頼っていた。私がその仕事をしている間に、Javaメモリモデルの本当の欠陥が明らかになって、彼の答えは非常に間違っていて、私の答えは少しだけ正しかった。

誰かがMCPが必要な理由を、単にSwaggerやProtoをサポートするのではなく、明確で簡潔に説明してくれたらいいのに。

└

MCPは新しいんだよね。

└

OpenAPI（またはその前のSwagger）やProto（これがprotobufを指してると思うけど）は、MCPがやってることをカバーしてないよ。JSON-RPCを使う代わりにそれらの上にレイヤーを重ねることもできたけど、JSON-RPCが基盤としてより良い理由は見当たらないな。（SwaggerにはMCPのローカルユースケースに合わないコミュニケーションの前提があるし、protobufはコミュニケーションを全くカバーしてないから、その上にレイヤーを重ねるには追加の考慮が必要になる。）もしSwaggerやprotobufでJSON-RPCを置き換えるなら、基本的に既存のMCP仕様全体が必要だし、その変更に伴うギャップや複雑さをカバーするための追加の資料も必要になるよ。

└

MCPはストリーミングレスポンスをサポートしてる。ポーリングとセッション状態で実装できるけど、それは効率的じゃないハックだね。

SOAPは冗長だけど、MCPが理解していないことを理解していた。残念ながら、当時は誰もSOAPを理解していなかったよ。（追加の文脈：レガシーSOAPシステムの維持について。SOAPに関しては良いことは何も言えないし、誰のロールモデルにもなるべきじゃない。）

Hacker Newsで議論の続きを見る

ハクソク