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

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

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

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

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

MCPは新しいんだよね。

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

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

「シンプル」という言葉が含まれるプロトコルは、実際には全然シンプルじゃないってことが分かったよ。だから、SMCPが出てくるのを待ってるんだ…。

これ、めっちゃ面白いけど的確なSOAPの説明だね: https://harmful.cat-v.org/software/xml/soap/simple それに、実際XMLベースの技術は好きなんだ。XMLスキーマは、複数のドキュメントタイプのフォーマットを構成して検証する能力において、今でも比類がないよ。でも、SOAPは本当に無駄に厄介だった。リモートコールのためのシンプルな仕様の代わりに、すべてと何も説明しない仕様になっちゃった。SOAPはあらゆるトランスポートプロトコルをサポートしてたし（SOAP over email？もちろん！）、リモートハンドルを使ったRPC（CORBAみたいに）、通常のRPC、自己記述型RPC（UDDI！）などもあった。でも、何もかもがそのままでは動かなくて、認証やキャッシング、HTTPレスポンスコードの相互運用性、その他の「つまらない」細かい部分は読者の課題として放置されてたんだよね。

いいこと言いたいことがたくさんあるよ。特にREST（実際にはJSON-RPC）やGraphQLは、SOAPやSOAのエコシステムがすでに持っていた機能に追いつこうとしているように見えるから。残念ながら、新しい技術サイクルが来ると、良い部分も含めてすべてが捨てられちゃうんだよね。

同意する。実際、SOAPは大失敗だった。シンプルなはずの概念をこんなにも複雑にしてしまったのは驚きだよ。XMLですら、WSDLのような曖昧な標準の世界や、マルチパートHTTPの奇妙な使い方のせいで、思った以上に複雑になってしまったし、結局何の意味もなかった。なぜなら、ある言語で書かれたSOAPサーバーが他の言語のクライアントと互換性があるとは限らなかったから。（具体的に何が問題だったかは覚えてないけど、.NETで動いてるSOAP APIをJavaクライアントから使おうとして問題にぶつかったことがある。これは結構いい例だと思う！）流行が過ぎると人々はすぐに物事を美化し始めるよね。辛い記憶がまだ新しいのに、新しいものがどれだけ愚かかを嘆く。俺はスキーマレスなJSON APIのファンじゃないけど（protobufやcapnpの方がずっと好きな変わり者なんだ）、SOAPに再度向き合うのに1ヶ月かかるより、スキーマレスなJSON APIの作業を50年やる方がマシだと思う。

メモリ制限のあるデバイスでSOAPレスポンスをパースするのは、どれだけ人生が悲惨になり得るかを知るための楽しい実験だよ。

皮肉なことに、SOAPを完全に嫌いになったのはSOAPに関する技術プレゼンテーションだった。一般的には、両端が同じプログラミング言語で書かれているときはうまく機能したけど、そうでないときは最悪だった。MicrosoftがSOAPをそんなに好きだったのも納得だね。

でも、これってMCPの作者がエージェントに合理的なエラーを返して、JSONを修正して再度呼び出すように頼むべきなんじゃないの？

もうPEBKAC（問題は椅子とキーボードの間に存在する）って言葉があるよね。LLMは基本的にPEBKACを自動化してるんだ。

著者のこの批判が理解できない。MCPはJSON Schemaをサポートしてるし、サーバーのレスポンスはそのスキーマに従わなきゃいけない。もしスキーマがISO-8601のタイムスタンプを要求してるのに（例えば、スキーマで「date」フォーマットを指定してる場合）、サーバーがUnixエポックのタイムスタンプを送ったら、それはプロトコルに違反してることになる。著者は後でMCPがJSON Schemaをサポートしてると言いながら、「型安全なクライアントを生成できない」とも主張してる。これは明らかに間違いで、JSON Schemaのコードジェネレーターはたくさん存在するよ。

こう言ってみよう：2023年以前は、スタートレックの技術のバグやグリッチは完全に作り話だと思ってた。LLM以降は、まさにその通りになると確信してる。LLMの統合がエンジニアリングと何の関係があるのか、なぜ会社のインフラを外部の管理に任せるのが理にかなっているのか、もうわからない。しかも、全てのステップで再現性が欠けてるのはほんの表面をなぞってるだけだ。「なんとなく動く」ってのはエンジニアリングじゃないよ。

MCPは輸送とコンテキスト管理に焦点を当てていて、ユーザーがインターフェースを適切に実装する責任を免除するわけじゃない（つまり、スキーマを定義してスキーマバリデーションをすること）。これは「HTTPはJSONバリデーションをしない」と言ってるようなもので、まあ、そうだよね。

医療分野では、患者データタイプが不適切に強制されることがあり、間違った投薬量の推奨につながる可能性があります。変わったかもしれないけど、あまり変わってないと思う。若い頃に医療テレメトリーの仕事をしていて、タイムスタンプを正しく解析することがどれほど重要かを徹底的に教えられた。初めてユニットテストを書いた時のことをうっすらと覚えているけど（テストフレームワークなしでね）。NTPがないことを考慮して、タイムスタンプから時間を再計算したこともあった。メッセージヘッダーもそうだったし、理由はインシデントレビューや医療過誤のケースだった。心臓発作が始まる3秒前に投与された薬と、患者がクラッシュした後の8秒後に投与された薬では、全然違う状況だよね。最近、イギリスの郵便サービスで悪いデータがどれほど人の命を奪うかを見たし、医療データでは1分が天と地の差になる。

これを繰り返してるよね。デスクトップOSが登場したとき、ハードウェアリソースが不足してたから、全てのデスクトップOS（DOS、Windows、MacOS）はUnixからの教訓を忘れちゃった：マルチユーザー、協調マルチタスクなど。10年後、PCハードウェアは90年代のワークステーションよりも速くなったのに、まだ80年代には意味がなくなった制限だらけのOSに縛られてる。スマートフォンが登場したときも、ゴールドラッシュがあってハードウェアリソースが不足してたから、OS（iOS、Android）もまた教訓を忘れた。10年後、モバイルハードウェアは00年代のデスクトップハードウェアよりも速くなったのに、まだ00年代の間違いに縛られてる。AIも基本的に同じことをやってる。すごく頭のいい20代や30代の人たちがリードしてるけど、彼らはWindowsが最初にリリースされたときには生まれてすらいなかった。私たちの分野は、注意欠陥のティーンエイジャーたちのカスケードの下で運命づけられてる： https://www.jwz.org/doc/cadt.html （リンクをコピペしてね）。すべてがゴールドラッシュで、誰も数十年にわたるオランダの都市インフラ設計をやってない。これがすべてアメリカ主導だから、長期計画は忌避されるのも納得だよね。

AIを使い始めて数ヶ月経つけど、取引を実行させたり、X線機械の投与量を設定させるのはまだ全然信用できないな。でも、スタートアップは始まるものだから、やらせておけばいいよ。

私にとって、この記事は企業環境の外で時間を過ごしたことがない人たちの頭の中にだけ存在する、いろんな作り話の問題についての無駄話だった。いくつかの文脈では意味がある「予防的」なアイデアが、別の文脈では誤用されてる。型検証についての話は間違ってる。クライアント側の検証は必要ないよ。信頼できないAPIをツールとして使うべきじゃないし、LLMの出力形式についての指示を追加することもできる。MCPが問題じゃない。問題は人々が間違ったツールを使っているか、プロンプトが悪いことだよ。MCPツールの形式が気に入らないなら、LLMにフォーマットの指示を与えたくないなら、正しい形式でデータを出力する自分のMCPサービスを作ればいい。クライアント側で強制する必要はないよ。

USB-Cの失敗の集大成は、Appleが最新のM4 Mac miniからUSB-Aポートを取り除いたことだと思う。まったく同じデバイスの同じポートが、今や全然違う機能を持っていて、ユーザーにはその違いが分かりにくい。発売日から数ヶ月経った今、最初の盛り上がりの後にね。以前は、Apple SiliconのデスクトップやノートパソコンのUSB-Cポートは、USB4 40Gbps Thunderboltで、何にでも使えると思ってたのに。今では、USB3 10Gbpsのものもある。どれがどれか、スペックや小さなアイコンを見ないと分からないのかな？Appleは、10Gbpsの制限を示すために自己文書化されたUSB-Aポートを選ぶこともできたはず（便利なことに、USB-Aは正確に10Gbpsに制限されているから、少し余分な「低速」ポートを低コストで持つのにぴったり）なのに、代わりにUSB-Cブランドをさらに薄めることにした。まさに純粋な革新だね！結局、ほとんどのUSBメモリやキーボード、マウスはUSB-Aポートが必要だから、ユーザーはUSB-CからUSB-Aのアダプタを使わざるを得ないし、USB-CのキーボードやマウスでもUSB-Cを使ってるのにね。（でも、もちろん、これらのデバイスのUSB-Cバージョンに2倍以上の金額を払うことができるから、USB-CのバリエーションがUSB-Aよりも少ないか劣っているのは、ハイプや熱狂が実用性や使いやすさよりも重要な時代には関係ないことだよね。）

その一文を読んで、思わず笑っちゃったよ。ミッション達成って感じかな？

HTTPブロブって何？JSONがXMLの代わりに勝った理由ってことかな？

その通り。問題はMCPが企業向けに設計が悪いわけじゃなくて、LLMが適切でない用途に使われていることだよ。> 金融サービスでは、取引AIが数値の型を誤解して、間違った小数点精度で取引を実行する可能性がある。もしガードレールなしでLLMに取引を実行させてるなら、どんなプロトコルを使ってもそれは爆弾みたいなもんだよ。> AIツールがISO-8601のタイムスタンプを期待してUnixエポックを受け取ると、モデルはクリーンに失敗する代わりに日付を幻覚するかもしれない。もし幻覚した日付のせいでプロセスが壊れたら、LLMを使うべきじゃない。

何を言ってるのかよくわからない。ステートレスRPC、キャッシュ制御、クライアント側の型付け、トレーシング/可視性、双方向ストリーミングは、最小限のトイプロジェクトを除いて、現代のウェブに非常に関連があると思う。真剣なエンジニアリング組織のプロジェクトに関してはなおさら。> 著者は、MCPツールの使用結果が直接LLMにフィードされることを期待しているようだが、これがまさにMCPの目的じゃないの？私が出会ったほとんどのツールは、他のソースからのコンテキストを直接LLMにフィードするためのものだよ。これがプロトコルの最も一般的なユースケースだと思う。