話題のMCP Web 2.0 2.0の幕開けか？
引用元：https://news.ycombinator.com/item?id=44073785
MCPがエンタープライズ向けだって見逃してる人が多いね。LLMはなんでも翻訳できるから、バラバラのシステムをつなぐのに超便利なんだ。だからB2B SaaSでMCPサーバー導入が進んでる。社内でもAPIの構造や制限をどう変えるか話し合ってるよ。プロトコルが”エンタープライズ向け”じゃなくても、記事の通り重要じゃないんだ。スタンダードの歴史見ても、ダメでも広まることあるしね。
MCPって結局、長い接続（たいていWebsocket）経由のRPCだろ。俺はRPCの方が楽だと思う理由は二つ。１．RESTのPUTかPOSTかで揉めなくて済む。REST verbで結構時間無駄にしたしね。２．LLMがRESTの意味を理解する必要ない。RPCメソッド見て、いけそうなコールするだけ。たぶん、これだけだよ。
MPC（たぶんMCPだよね）はリモート機能への標準的なアクセス方法だけじゃないんだ。Discoverabilityも提供する。クライアント（LLM）がサーバーにどんな機能があるか聞けて、どう使うか理解できるってこと。
まあ、でもそれについても既存の選択肢はあるでしょ。インターネットにはDNSレコード（A, MX, SRV, TXTとか）で調べられるし、Webには/.well-knownってAPI仕様とか置いとく場所もある。MCPの主な違いは、stream-oriented communicationとDiscoverabilityが一緒になってるとこだな。
つまり、あんたはドメインごとに違う解決策があるって言ってるだけだろ。クライアント発見の普遍的な方法なんてないし、今あるのはそのドメインに特化してるんだよ。
LLMのすごいとこは、普遍的なクライアント発見方法なんていらないってこと。既存のAPIがSwagger/OpenAPIとかのスキーマ情報出してれば、LLMが勝手に使い方理解できるはず。MCPみたいな新しい普遍標準が必要ってのは、LLM以前の古い考え方に見えるな。
APIがすでにスキーマ情報公開してる数えきれない標準をサポートしてたら
MCPでうまくやってるか知らんけど、もし依存する読み込みのためにモデルで余分なラウンドトリップがあると、コンテキスト全体を再処理したり、キャッシュ階層に保存したりしなきゃいけない。システムRAMにキャッシュするほど短くないと、数百GBものSSD書き込み耐久性を燃やす可能性もある。
ソフトウェアをつなげて作る上で大事なのは、AIに魔法みたいに任せて、色んなものを適当にごちゃ混ぜにさせようと抵抗すること。ＯＮＥつのはっきり定義された契約（仕様）を持つべきなんだ。今のLLMのレベルでも、この原則に異論はないはず。
あー、いいじゃん最高。俺の金融システムにAIの幻覚付きAPIが必要だって？
.well-knownを「ドメインにすごい固有」って言うのは正確じゃないと思うよ．
少なくともhttpサーバーに限られてるよね．ドメイン固有のルール含めるともっとそうだよ．
rpcプロトコルでは結構ある話じゃない？例えばxml-rpcのシステム名前空間とか．
restかな？まともなrestのapiシステムは発見できるように設計されてると思うよ．
restは設計の考え方であってプロトコルじゃないんだ．だから外部スキーマ（openapiとか）とか自己文書化で発見可能にできるけど，必ずあるわけじゃないし，外部スキーマの方には標準の発見方法がないんだ（openapi-specificationのissue 724とか2128見て）．
そうそう，うちで本番運用してるmcpサーバーはこれ対応してるんだ．うまくいくとマジ最高だよ．でももっと頻繁にうまくいくようにするには結構やることあるけどね！
＞mcpはたんにrpcを長い接続（だいたいwebsocket）でやってるだけ
僕の印象ではmcpはsseを使ってて，websocketじゃないのがエンタープライズ向けじゃない理由だと思ってたんだ．サーバーで状態持たないといけないからスケールしにくいんだよね．websocketに変えたの？
https://raz.sh/blog/2025-05-02_a_critical_look_at_mcp
「変えた」んじゃなくて，オプションにはなったみたいだよ https://modelcontextprotocol.io/specification/2025-03-26/bas…
ステートレスじゃないって話だけど，声を聞いてsseにもセッション持たせるようにしたらしい https://modelcontextprotocol.io/specification/2025-03-26/bas…
「たんにrpc」じゃないよ．mcpサーバーツールの応答はllmがすぐ使えるコンテキストになるはずなんだ．普通のapiやrpcは他のソフトが使うように設計されてる．既存apiをそのままつなぐと，llmがいらない詳細だらけのコンテキストになっちゃうんだ．
僕はrpcにベクトル検索とか埋め込みモデル組み合わせてaiが使えるコンテンツ作ってるんだ．これってmcpって言う？
これってSwaggerの拡張版で、APIをちゃんと文書化してLLMが使えるようにするだけじゃないの？他の魔法はないみたい。Pythonのdoc stringみたいなLLM用の追加フィールドで代用できそうだよ。
これ、めっちゃ金稼ぎになるね。データ要求の度にLLM通すのに金かかるんだもん。
将来、安く問い合わせできるスキーマをエンドポイント同士で交渉する、みたいなことにはならないし。
RESTとかOpenAPIがあるじゃん。それだけでもう自己発見とかできるし。
MCP提供する奴らは、どうせ良いAPI持ってるだろうしね。
SDKなんていらない、APIドキュメント出してる。
パッケージや関数なんていらない、必要な時に自分でコード書けばいい。
コンパイラなんていらない、コンピューターはアセンブリ分かってる。
これ、使い道が違うよ。MCPはAPIをLLMに教えるだけじゃなくて、APIをカプセル化・単純化して、LLMが毎回ゼロから手探りで理解しなくて済むようにするものなんだよ。
OpenAPIのスペックって、LLMがAPIを理解するのに必要なこと全部提供してるよね。機能を維持したままLLMのために単純化できるなら、アプリケーションにまた新しい入り口作るんじゃなくて、API自体を単純化しちゃえばいいんじゃない？
TikTok見てる時間より長く座って、ちゃんとAPI設計しなくて済むように、ってだけなのかな？
自己発見はできるけど問題はAPIリスト化じゃない、難しいのはオーケストレーションだよ。VMサービスで例えるね。「USのVMをEUに半分のCPU/RAMでコピーするには？」って聞かれたら、APIスペック見せて手順を言う？でもそういう一発APIはないし、コードは書きたくない。3ヶ月後にはスナップショット不可のVMだったり、サイズ無効だったりして壊れるかも。MCPならAPIを「正しく」オーケストレーションして、隅々までチェックしてくれるはず。失敗しても「AIでも無理だったわ」って言える。人間が失敗して「素人かよ」って言われるのと違って。
価値は、社内ウェブサイトのMCPを拡張して、必要なデータを取ってこれることだね。
認証とかサービスコールとかワークフローの設定をいちいちやる気が起きない、無数のシステムをスクリプト化できるんだ。
MCPは新しい権限いらない、自分がウェブサイトにアクセスできる権限だけでいいんだよ。
全く同感。大企業には9時から5時まで素晴らしい仕事をして、次の日まで仕事のこと忘れたいエンジニアがいっぱいいるよ。
勤務時間中に社員から最大限引き出すのを望まないビジネスなんてある？
＞昔の偏屈なUnix野郎がスペック書いてた時代と比べて
これがセマンティックウェブ失敗の一因だよ。XMLのeXtensibleに寄りすぎた。XSLとかXHTMLとかXSDとか多すぎ疲れたんだ。当時必要なのは単純な交換フォーマット（JSONがはまった）。でもXMLの時代が来たと思う。LLMは構造化テキスト（MarkdownとXML特に）と相性いい。でもMCPはモデルが間違ってる。「プル」じゃなくて「プッシュ」でコンテキストをモデルに与えるべきだ。
＞「プル」じゃなくて「プッシュ」でコンテキストをモデルに与えるべきだ。
インターンに解決させたいケースでどうやるの？前もって情報知ってるなら自分で解決するでしょ。
MCPの価値は「代わりにクエリ実行して、15個の情報源つなぎ合わせる方法を学ばなくて済む」ってとこじゃないかな。
あなたの反論、よく分かんないな。コンテキストを知るのが、問題の解決策を知るのと一緒って言いたいみたいだけど？
例えばね、放射線スキャンで癌があるか判断するコンテキストは、スキャンの内容そのものだよね。
ここでモードは二つあるんだ。一つは「LLM、この患者のスキャンに癌があるか教えて」って言って、LLMがMCP呼び出しで患者のレポートを読むモード。
もう一つは「LLM、これが患者の放射線スキャンだよ、癌の兆候があるか教えてくれる？」って言うモード。
最初の例が俺が「pull」モデルって呼んでるやつで、二つ目が「push」モデルって呼んでるやつだよ。
もっとコメントを表示（1）
上で言ってたエンタープライズの糊付け役って話が、これがpullモデルである理由だよ。
君のpushモデルでは、五つあるバックエンドのどれかからスキャンを探しに行って、必要なアクセス手続きを全部踏んで、実際にファイルを自分で手動で処理する責任が君にあるんだ。
pullモデルでは、各バックエンドが一度だけサーバーを実装して、LLMが一度だけそれぞれに接続するから、全部とやり取りするための単一のフローで済むんだよ。
多くのオフィス仕事では、コンテキストを知るのが、目の前の問題の解決策を知るのとほとんど一緒だね。
その例、面白そうだね。俺は社会人になってずっとオフィスだけど、思いつかないなあ。
子供の頃やった logic puzzles を思い出すよ。パズルの醍醐味は、必要な情報は全部提供されてて、deductionで解くのが楽しいってところだよね。Sudokuも同じ。
少なくとも、君が言う型にはまらない問題はたくさんあるし、MCPはそれらを解決する正しい方法じゃないって言いたいね。
俺が提案してるLLMのモデルが、多くの人の期待と違うのが面白いね。情報の data-lake を渡してLLMが勝手に推論するんじゃなく、俺たちがコンテキストを手作りしてLLMが推論するんだ。
役立つ推論には、関連コンテキストの手作りが重要なんだろうね。LLMでコード書く経験から、コンテキスト選びがすごく大事だと分かったよ。LLMは適切な質問をするのは苦手だけど、役立つ情報を俺たちが与えればうまくやってくれることが多いんだ。
Semantic Webが失敗した主な理由は、誰も Semantic Web が何なのか、何に役立つのかすら説明できないことだと思うな。
結局、なんかデータ交換することに関する、一般的なバズワードの集まりでしかないんだ。
うわ、それならすごい成熟した職場で働いてたんだね。もし [Google Drive, Confluence, Airtable, GitHub wiki, Aliceが使ってたあの非推奨のやつとか…] のどれに Slack で言ってた Project Frazlebaz の参照があったか、すぐ分かったんだとしたら。
最後は… 昨日？ 先週？ もしかして今日だったかな、時間があいまいすぎてさ。
広告をどう詰め込むか分かんなかったから失敗したんだよ。
そんなに難しかったかな？ただデータ提供するんじゃなくて、データを機械が index できる「semantic tags」付きで提供するんだよ。
結局、今 LLMで解決できるような「fuzzy-search」の問題を解決するために作られたんだ。「find me a website which sells home goods」みたいなのは、marketplace として分類され、さらに home goods を売ってるってタグがあれば対応できたはず。
本当の問題は、これには cohesive ontology が必要ってことだと思うな。自分のメモやブックマークの tagging に本気でハマったことあるなら、それがどれだけ大変か分かるはずだよ。
俺たち（つまりユーザー）がソースと質問を提供して、LLMが答えを提供するんだよ。
コンテキストって概念全体が、技術的な制約から来る incidental complexity で、ユーザーが気にするべきことじゃないし、まして自分で手作りする必要なんて絶対ないはずだ。
XMLタグってLLMにはすごく合うんだよね。でもさ、ほとんどただのxmlタグじゃん。nobody™ はLLMにちゃんとしたXML宣言（”？xml version=”1.0” encoding=”UTF-8”？”みたいなやつ）付きのXMLを食わせたりしてないし、名前空間とかXSLT、XMLスキーマとかも使ってない。ただのSGMLっぽいアドホックなタグの集まりだよ。
＞ コンテキストをモデルに「プル」させる指示より、モデルに「プッシュ」すべきだと信じてるんだ。
モデルってコンテキストの容量がめちゃくちゃ限られてて、それが主なボトルネックの一つなんだよね。だから、その情報をできるだけ最適化（最小化）するのが大事。モデルが必要だと判断したものをプルさせる方が、その制約を満たしやすくなるってわけ。
そうそう、セマンティックウェブの最大の問題は、世界をどう表現するか合意しなきゃいけないこと。概念は何？どう関連してるの？みたいな。こういうセマンティックネットワークの研究は計算言語学の自然言語処理でずっとやってきたけど、マジでめんどくさい。例えば、80年代のフランスのMinitelユーザーは、「私の犬が病気」みたいな文章でイエローページから獣医を探せた。すごい技術だけど、そんなに役に立たなかったし、見つけにくかった。
LLMは、こういう概念間の関係性を自動で見つけて「いい感じ」にしてくれるって約束してる。うまくいくときもあるし、ダメなときもあるけどね…
でもさ、それって回答の質に劇的な差を生むと思うんだ。どうやってLLM（あるいはLLMの連携）は、それが何かわかってないのに、全ての役立つコンテキストを手に入れるんだろう？
（たぶんそれはMCPの仕組みで明らかになってるのかな？俺はまだたまにLLMで半分の関数を書かせるレベルなんだ）
それがMCPでどう解決されるのか、俺には分かんないんだよね。LLMはどこを探せばいいか、どうやって知るんだろう？ただslack／jira／airtableみたいなAPI（あるいは一連のAPI）を使えるようにしただけじゃ、コンテキストが魔法のように現れたり、それを見つけるための正しい検索呪文が出てくるわけじゃない。
LLMはまだ、どのツール内で検索するか、どんな検索語／ツールを選ぶのが正しいか、なんかを自分で判断しなきゃいけないんだ。データプロバイダーのセットに100万個のドキュメントがあって、LLMのコンテキストに収まるのが1000個だけなら、そのフィルタリングはどこかで起こってるんだよ。
どこにデータがあるか知らなくても、LLMが魔法のように知ってるっていうこの考え方が、俺にはすごく分かりにくいんだ。
＞ それが必要だと判断したもの
これこそ俺が提案してることだよ。モデルが必要なものを自分で判断するのに頼るのは、利用可能なコンテキストの一番良い使い方じゃないかもね。俺たちがモデルに「これ絶対必要だよ」って情報を与える方が良いのかもしれない。
興味深い考察だね。俺は最近XML／XSLTにちょっと夢中になってるんだ。JSONのマクロ展開言語（代入、置換、条件分岐、カスタム関数呼び出しのための4つのマクロタグだけ）を開発してて、XSLTを再発明してることに気づいたんだけど、本当に欲しかったのはXPathだった。グラフ上を前後に行き来できる走査方法を記述する方法で、マジで素晴らしい仕様なんだ。それで見つけたのがbasex [0] で、任意のXMLドキュメントをXPathやXQueryでクエリ可能なデータベースに引き込めるんだ。
俺的には、ハルシネーションなしでデータセットへの信頼できる自然言語インターフェースを作る最善の方法は、システムプロンプトにXMLスキーマを渡して、データ取得のためのクエリを書かせることだと思うんだ。
[0] https：／／basex.org／
それは誰も使いたがらなかったから失敗したんだよ。誰も魅力的な製品を作らなかったし、誰もデータを作成したがらなかったし、誰かが作っても誰も使う気にならなかった。殺されたんじゃなくて、役に立つ目的がなかったから最初から始まらなかったんだ。
それでも、それは損失のある送信を許容するフォーマットで、LLMの曖昧な取り込みとよく合うと思うんだ。閉じタグの冗長性は、LLMが集中し続けるのを助ける特徴だよ。
趣味でXMLをデータソースとして使うこともあるんだけど，最終的にやめちゃうのは構文の細かいとこが面倒だからなんだよね．＜＞の類を超えたすごく大きな仕様で，全ての状況に対応しようとしてるから，「普通のテキスト編集」はすごく直感的じゃなくなる．例えばこの段落みたいなのを入力しても，互換モードでパースはされるかもしれないけど，validじゃなかったりする．データ交換フォーマットとしてとか，それに合わせて作られたアプリに入れるならもっと使えるけどね．LLMなら絶対理解に苦労しないだろうし，それは良いことだ．昔の課題の多くは，時間がないプログラマーが，複雑な仕様を blunt instrument みたいに扱って，機能を突っ込もうとしたことから生まれたんだ．「XML？ regexでいけるっしょ．」ってのを，3つの違うプログラムで3人の違う開発者がやったら，そりゃもう大変なことになる．
個人的に本当に欲しいのはBBCodeっていうフォーマットに行き着いたんだ．あれは色々なことのソースフォーマットとして素晴らしいよ．これも基本は＜＞だけど，適切な量の構造と柔軟性があって，汎用フロントエンド構文として使える．初期の実装は「regexで対応」だったけど，何十年もの battle-testing を経て，今じゃもっと洗練されたパーサーも出てきてるしね．
90年代後半に図書館の本でXMLとXSLTを習ったの覚えてるわ．面白かったけど，使い道がなくて．当時は大したデータも扱ってなかったし，全部趣味の勉強だったんだ．それから何十年も経つけど，XMLを触ったのはせいぜい3回かな？1回は思い出したくないSalesforce連携で，他の時はクライアントの単発案件で，XMLに入ってるデータをWordPressに入れる必要があった時だけ．
＞コンテキストはモデルに「プル」させる方法を指示するより，「プッシュ」すべきだと信じてる
MCPの「Resources」[0]があなたが探してるものだと思うよ．
[0]: https://modelcontextprotocol.io/docs/concepts/resources#reso…
それ俺も気づいたけど，追加トークンが多くても別に問題ないと思うよ．XMLの名前空間とかfancyな機能全部使うとメチャクチャになるけど，使わなきゃ良いだけ．単純なタグ構造だけでも，plain textよりパワフルなパイプライン作れるんだから．
LLMにDBまるごとのコンテキスト与えるのはどうかなー．必要ない情報がノイズになって，特に小さいモデルだと推論を邪魔する可能性があるよ．
俺が言ってるのは，ユーザーがLLMのコンテキストサイズをはるかに超えるデータについて質問したい状況ね．データへのアクセス（MCPサーバーとかRAGサーバーとか）と質問／プロンプトだけ渡せば，後はLLMが全部やる責任があるって話．
conjであったこのトーク，マジ面白かったよ．RDFとかsemantic webがやっとニッチを見つけたのかもって話．
https://youtu.be/OxzUjpihIH4?si=DRSp1n9u56iGbZFZ
MCPは単なるパラメータ付き関数呼び出しだよ．プッシュ型かプル型かは，実装する人が決められる．プッシュ型はスキャンを入力としてmcp呼び出しに渡す．プル型はmcp呼び出しの中でプルする．どっちが良いとか悪いとかじゃなくて，状況次第だね．
俺の経験だと，こういうのこそLLMが得意で速いんだよ．実際の仕事であった話ね．BI devとして，foreign keyゼロのデータレイクにある1000以上のテーブルのERPから，入荷商品の数をどうやって出すか知りたかった．stock movements系のテーブルから取るんだろうなとは思ったけど，どうjoinするかも分からず，どの行やフィールドを見れば良いかも全く．ERPのコンサルに聞くと同時に，Cursorに「このクエリに入荷数のカウントを追加して」って超基本的なお願いをした．Cursorは instantly でもっともらしい答えをくれたけど，合ってるか確信持てなかった．数日後コンサルから回答来たら，Cursorのコードと全く同じだったんだ．Cursorはコンサルが考えてなかった edge case まで考えてくれた．マジで驚いたよ！CursorがそのERPのコードを知ってるのか，それとも十分なリサーチクエリを走らせて見つけ出したのか分からないけど，とにかく正解だった．コンテキストとして渡したのは，カウントを追加したいクエリとERPの名前だけ．だから，MCPみたいなのなら，絶対プル型が正しいと思う．LLMにコンテキストを探すハードな作業をやらせれば良いんだ．
「MCPの台頭が，AIの人気で他のプラットフォームもLLMが制御するだけでなく，あらゆる目的でプログラマブルになる希望を与える」って？
俺は逆だと思うね．MCPはsemantic webと同じ理由で失敗する運命だよ．だって，データが囲い込みされてないと誰も儲からないから．AI検索（sorry，deep-researchとか）も，もっと良い方法で解決できたんじゃないかと思うわ．レストランがメニューをメタデータ形式で公開してくれれば，誰でもpython scriptで「Texasで一番安いタコス探して」とかできたはずなのに，現実はデータの人工的な壁で囲い込みして，それをAI（データセンター全部使って）で突破しようとしてる．マクロに見ると，ただただバカげてる．
普通の人が読めるテキストが”人工的な壁”とか言うのは違うね。それが世界の自然な形だよ。レストランがメニューをメタデータ形式で公開する義務の方がよっぽど人工的な壁だ。新しいNLPツールのすごいところはそこだよ。レストランのオーナーがJSON学んだり、JSON作るソフト買ったりする必要ないんだ。データをそのまま使える。便利なツール作る費用もほぼゼロ。精度は落ちるだろうけど、人間の言葉ってそんなもんだしね。
＞MCPはSemantic Webと同じ理由で失敗すると思う、オープンすぎると誰も金稼げないからね。MCPで”ロックダウン”するやり方ってあるのかな？認証の仕組みがあって、呼び出し元に「このユーザーはこのツールにはアクセスできるけど、これらにはまだダメ」って伝えられたら、フリーミアムサービスにできるかも。
もっとコメントを表示（2）
＞MCPがSemantic Webと同じ理由で失敗するっていう意見に同意。MCPはrobots.txtの進化版みたいだけど、結局は”使わせるためにリソース教えて”ってこと。90年代のエージェントブームがダメになったのは、相手の機械でコード動かした時の信用問題。エージェント間の情報非対称性をなくしたら社会が機能停止する。
皮肉な見方もあるけど、未来はまだ決まってない。顧客操作に使われるAIじゃなく、ユーザーのためのAIエージェントをビジネスサービスに使わせる方向もある。Gemini/ChatGPTで広告なしで情報探したり、ダークパターンなしで買い物したりできるようになるかも。これを維持するには、ユーザー中心のエージェントをSaaSやオープンソースで広めるべき。このコミュニティが未来を決める鍵。楽観的に行こう！
2010年代初めはHATEOASが夢だったんだけど、API使うのを楽にするはずが、swagger yaml作る以外は結局全然ダメだったね。でも、HATEOASって名付けたやつが、ある意味失敗するように仕向けたんだと思うわ。
”こっちが使うためにリソース教えて”って言うけど、結局やりたいのは”使われた”時にお金になるリソースを提供することでしょ。
普通のテキストメニューで十分だったよね。
つまりさ、もしAIエージェントがウェブ使うの中心になったら、ウェブのコンテンツは人間じゃなくて、そのエージェントを操作する方にシフトするだけなんだよ。今もAIは”マーケティング”情報やSEOに影響されてる。マーケターも対策済み。楽観的な面もあるけど、消費者市場の根本的な力学は変わらないよ。
そうだよ。MCPはREST APIと同じ認証仕組みが使えるから、サービス公開も同じやり方でできるよ。違うのは、ユーザーがAPIクライアントを作る代わりに、LLMが代わりにAPIを呼んでくれること。だから、RESTサービスを他のLLMワークフローに組み込めるんだ。
無料でオープンなAPI出したって誰も金稼げないってだけじゃないんだ。そういうAPI動かすには、 basically、無限のリソースが必要になるってことだよ。MCPはAIエージェントが殺到して問題を悪化させるだけ。唯一安定するのはRPCの従量課金。Web 2.0 APIよりは、エージェント運営元が支払い窓口になるからマシ。コストはサブスクに含まれるのが一番良さそう。
本当にそうかな？ LLMにログインとかbearer tokenとかどうやって渡すの？
その未来像では、エージェント向けにマーケティングされるようになるのは絶対そうだよね。それは素晴らしい。その世界では、エージェントがノイズをふるいにかける。それを一番うまくやったやつが勝つんだ。エンドユーザー体験は均一で快適になる。それはパーソナルセクレタリーとカスタマーサービス担当者と話す違いみたいなもの。後者を我慢する必要なんて誰にもない。
プレーンテキストで価格比較みたいなのってどうやるの？
semantic web失敗の理由は、メタデータ作成の手間と、フルテキスト検索やLLMの方が効率的だからだよ。みんな時間ないし、関連情報は人それぞれ違うから標準メタデータは難しい。ArbitraryなサイトをスクレイピングしてLLM使う方が安くて簡単。
ちゃんと見てなかったんだけど。MCPベースのAPIでなんでみんな金儲けできないの？プロバイダーがAPIキーとか支払いとか要求できないの？
MCPの人気は今のAIバブルによる副次的な効果だと思うな—AIでできるおしゃれなことの一つだ。もしデータを標準形式で利用可能にすることに”簡単な”価値があるなら、相互運用可能なエンドポイント（例えばschema.orgとか一般的なオントロジーを使うやつ、特別な魔法のSDKがいつも必要なカスタム形式じゃなくてね）の採用がもっと進んでただろうよ。
xAIの例みたいに、大手はデータ囲い込みしてる。”データは私のもの、お前たちのものじゃない”ってね。MCPが注目されてるのは、OpenAIとかAnthropicみたいなLLM専業勢が価値を高めるのに使えるからかも。AIインテグレーター（Googleとか）が強くなるにつれて、MCPは消えていくんじゃないかな。
semantic webって実際誰が何に使ってるの？Googleがschema.orgをサポートしてるけど、あれはGoogleのAPIって感じだし、Googleのテスターでさえ有効なスキーマに文句言うことがある。まだ存在しないアプリケーションのために、どうやってマークアップしてテストすればいいの？よくわかんないな。
”ロックダウンされてないと儲からない”じゃなくて”既存大手はオープンになると儲けにくい”だね。消費者が価値を得るなら、MCP周りに挑戦者が出てくる。最初はオープンでスタートアップに有利、大手はジレンマ。新しい波が堀を築くと閉じるだろうけど、ウェブみたいに、全体としては以前よりオープンになるかも。
データを簡単に利用可能にする方法はあるよ。何百年も前から存在してる、プレーンテキストってやつ。今はコンピュータがプレーンテキストで作業できるツールがある。特定のニッチ以外では、オントロジーなんて自己満足プロジェクトだ。
”自分のためのデータ、お前のためのデータではない”って言うのはまさにその通り。広告モデルになってからコンシューマーテックはAPIを閉鎖して相互運用性を妨げてきた。Web 2.0はその典型で、連絡先すら自由にならないし、Googleも非標準ブラウザを拒否する。
これは技術じゃなくビジネスモデルの問題なんだ。敵対的で、MCPが良くてもコンシューマーアプリでは広まらないよ。広告で稼ぐ限り無料APIは提供されないから。
そうだね。
”HTTP”自体で儲けた会社はあんまりないけど、それを採用することでめっちゃ儲けた人や会社はいっぱいいるよ。
”世界の性質だ”っていうのは、資本主義の性質だよ。
メニューをメタデータで公開するのはレストランにとって有益で、それをやらない唯一の障壁はツールへのアクセスだ。
ソフトウェアを買うとかツール作るコストとか、君が挙げるハードルは自然現象じゃないって。
もちろんできるよ、MCPはLLM向けのAPIインターフェースになるさ。
記事の筆者たちはAPIが閉鎖的なことにイライラしてるんだろうけど、俺は批判に賛成できないな。
Web 2.0は大成功だったと思うよ。
APIがほぼ無かった世界から、主要サイトのほとんどがAPIを提供するようになったんだから、それは大きな進歩だよ。
セマンティックウェブ批判のコメントで言うのは変かもだけど、レストランがメタデータ公開するのを止めるものはないし、やるインセンティブもある。
WordPressプラグインもschema.org対応多いから、PDF以外なら既に公開してるかも。
ロックダウンはCloudflareのせいだろうね。それが君のPythonのアイデアをダメにするよ。
俺が見る限り、MCPはAPIのバージョン2みたいなもんだね。
簡単に組み合わせられるなら有用でニッチじゃないし、会話型っていう次のUIの構成要素になるだろう。
Web 2.0への言及がネガティブ反応を引き起こしてるかもだけど、MCP単体は有用だし、ソフトウェアとのインタラクション方法を（分野全体を）ディスラプトする可能性があるよ。
セマンティックウェブの問題は”無限のメタデータ作る時間がない”ってことだったのに同意。
ツールリングの問題もあって、開発者との距離はまだある。
でも、あの膨大なメタデータをカタログ化するのに、俺たちLLMっていう強力なツールを発明したみたいだね。
MCPはウェブをオープンにする手段だって説明されてるけど、実際は、もしウェブが本当にオープンだったらできるイケてることのデモを作るための手段にすぎないよ。
MCPはまたあれの繰り返しだけど、前より考えられてないね。
新しいものなんて全部古いんだよ。
