【海外の反応】コーディングAI「Pi」がMCP拒否から一転、賛否割れる
姉妹サイトの新着
コーディングエージェント「Pi」の開発チームが、かつて「MCPは不要」としていた方針を転換し、新機能「Codemode」とあわせてMCP対応を打ち出す記事を公開した。これがHacker Newsで話題になり、「Piにも無駄な機能が増えてきた」という失望の声がある一方、「エンタープライズ連携ではMCPがほぼ標準になっている」「LLMに直接シェルを渡す方が危険」といった擁護論も相次いだ。あわせて競合プロトコルのACPや、Piの拡張版「oh-my-pi」といったツールの名前も挙がり、AIコーディングツールの設計思想を巡る議論に発展した。
Pi.dev:「MCPはいらないと言ったのに」
出典: earendil.com / 元記事はこちら
https://github.com/rcarmo/memento を試してみて。自分は主にCodexを使ってるからClaudeでのテスターが欲しい。試して動かない部分をissueに書いてくれるとありがたい…
まさにそれだけど、それの何が問題なのか分からない。API+ドキュメントが1つのURLにまとまってるのは自分にとっては利点。新しい名前がつくのも納得
エンタープライズの連携だと、それは選択肢にすら入らない。その領域ではMCPがほぼ制覇してる
https://github.com/rcarmo/memento でアップロード用に何個か力技の回避策を入れた。出回ってるドラフト仕様もあるけど、エンタープライズのMCPでの一般的なやり方は「帯域外」で処理して、ストレージのハンドルやURLをMCPツールに渡し、MCPサーバー側が「安全に」インポートする形みたい
Piを使ってる人はだいたい知ってると思う。MCPは「Model Context Protocol」の略で、モデルがAPIやサービスに接続できるようにする、逆に言えばそうしたAPIやサービスをLLMやエージェントから使えるように公開するためのプロトコル。https://modelcontextprotocol.io/docs/2026-07-28/getting-star…
普通のAPIと同じだけど、ドキュメントが最初から組み込まれてるってだけ
1. 最初の段落に参照とリンクがちゃんとある
2. たぶんあなたはこの記事の想定読者じゃない
一体どうしてこの記事がタイトルに答えてないと言えるのか。文字通り最初の段落で記事全体を実質「ネタバレ」してて、そこで答えは出てる。その後は、以前はXだったのが今はYになった理由の裏付けが続くだけ
この記事の著者です。PRをAIに読ませてそれを説明させるのは良い考えだとは思わない。それだと元の情報源ではなく、二次的な要約のさらに要約を読むことになるから。もし説明できていないなら、もっとちゃんと説明できるように頑張らないとですね 🙂
まあ人によるとは思う。参考までに、自分は今日それをやってみたら、changelogや記事を読むよりCodemodeが何なのかよく理解できた気がする
「Codemodeについてこれだけ話しておいて、それが何なのか説明する価値はありそうだ」
同意。自分はMCPを一切使ってないけど、あれは良い判断だったと思う。逆によく使っているACP(https://agentclientprotocol.com/get-started/introduction)についても、いずれ同じようにネイティブサポートを追加してくれるといいな
自分も同じことをした。それに、ツールの進化があまりに速いから、来週には廃れてるかもしれない特定のツールに時間を無駄にしたくない。だから今動くならそれを使うし、そうでなければ別のものを選ぶ
oh-my-piはPiのフォークで、この手の機能をいろいろ追加してる。https://github.com/can1357/oh-my-pi まだあまり試してないから、どれくらいちゃんと動くかは保証できないけど
自分の感想では、非常によく動く。最近はこれしか使ってない。以前は主にpiとcodex、あとzedやvscode、JetBrains系IDEに組み込まれてるものを使ってた。あと関係ない話かもしれないけど、vimのキーバインドにも対応してる
他サイトの新着
Piはパーミッションモデルすらサポートしてない。かなり素のままで、基本的に全部自分でカスタマイズすることが前提になってる
…でも、しばらく使っていると、最初は必要だと思っていた余計な機能のほとんどを忘れてしまったりする。自分はまさにそうなって、それ以来振り返らずに満足してPiを使い続けてる(気になる人は https://a.l3x.in/ai へ)
「通常、LLMが複数の操作を組み合わせたいなら、そのための完璧な道具がある。bash、あるいは他のOSシェルだ」
多くのシナリオ、例えばチャットインターフェースのようにハーネスをサーバー側で動かす場合、OSシェルへのアクセスを公開したくはない。巨大なセキュリティ攻撃面になるから
/usr/bin全部を渡さなくてもLLMにbashを与えることはできる。それは何十年も前から簡単に解決されてる問題
適切なセキュリティ機構を設定したクラウド製品ベースのオーケストレーションには、シェルアクセスはなく、正規のネットワーク経由でしか通信すべきではない。シェルアクセスのないrootlessな不変コンテナか、WebAPIだけを接点にする複数ベンダーのSaaS製品、という形になる
MCPは「自前主義(NIH)」で作られた非標準版のOpenAPIみたいなもの
サブエージェント機能があるハーネスで、何かおすすめはある?
補足:MCP操作を連結することについての自分の率直なメモはここ:https://github.com/rcarmo/umcp/blob/main/docs/CHAINING.md
記事にも書いた通り、Codemodeについては今後もっと詳しく書く予定です。この記事は、ある意味「誰もが気づいているのに触れられていなかった問題」に向き合うために必要なものでした
この話題の背景と論点
MCP(Model Context Protocol)は、AIエージェントが外部のAPIやサービスに接続するための標準化プロトコルで、賛否はありつつも急速に普及してきた。スレでは「MCPはAPIを機械可読な形でドキュメント化しただけ」という技術的な批判がある一方、「エンタープライズの連携では既にMCPが事実上の標準になっている」という指摘もあり、理屈の是非と実際の普及状況にはズレがある。また、複数のツール呼び出しをコードとして組み立てる「Codemode」はHuggingFaceのsmolagentsに似た発想だと指摘されており、毎ターンJSONでツールを呼ぶ方式より効率的だとされる。LLMにOSシェルを直接渡すか、MCPのような構造化された接点を使わせるかは、利便性とセキュリティのトレードオフとして根強い論点になっている。なお、Zedが開発する競合プロトコルACPや、Piの拡張版「oh-my-pi」といった周辺ツールの名前も複数挙がった。
※本記事は5ch(Hacker News)スレッド「Pi.dev: You Said No MCP」より抜粋・要約して構成しています。
まだコメントはありません。