Pi.dev: あなたは「MCP」を拒否しました

元記事: 2026年9月30日原文(earendil.com)

概要

Pi は以前まで MCP をサポートしていなかったが、現在はコア機能として統合
MCP の進化とPi側のニーズの変化が統合の主な理由
Codemode の導入でツール連携や柔軟な拡張が可能に
MCPの課題も依然残るが、今後の改善のため積極的に関与
Jev などの新しいツールとの連携例も紹介

PiにおけるMCPサポートの変遷

かつて pi.dev では「PiはMCPをサポートしない」と明言
PodcastやMarioの投稿でも MCP に対する否定的な意見
現在は Piアップグレード でMCPがコア機能としてサポート
背景には MCP自体の進化 と、Pi側の要件の変化

なぜMCPがコア機能になったのか

世界は静的でなく、MCPも変化 を続けた事実
Piは 拡張エコシステム が充実しており、MCPも本来は拡張として運用可能
- 以前はMCP拡張として存在
コア機能化の理由は、 MCPの変更が他機能にも有用 であったため
例：MCPの改善により Jev の利用も容易に
PiとMCPの共通点： インタプリタ型サンドボックス の必要性

MCPの現在の課題

MCPの最大の課題は「合成の難しさ」
codemode導入で一部解決したが、完全ではない
問題の本質は MCPサーバーやハーネスの設計 にあり
多くのMCPサーバーは ツールをコンテキストに流し込むだけ の設計
OpenAPI的なツール発見と構造化データ返却 が理想像
Pi上のMCPは JavaScriptサンドボックス経由でツールを公開

Codemodeとは何か

Codemode はツール呼び出しを調整・統合する オーケストレーション機構
ハーネス上で動作し、 エージェントがツール呼び出し順序を柔軟に制御 可能
JavaScriptでツールを組み合わせて利用
セッションの状態は ファイルシステムではなくトランスクリプト上 で管理
小型JavaScriptは WASMバイナリ として安全に実行可能
Piでは MCP有効時に自動ロード、または手動追加も可能

CodemodeとMCPの連携例

例： typesafe/jev を使い、issue tracker上の「最もフラストレーションの高いコメント投稿者」を分析
- Linear MCPからオープンissueを取得
- Jevで各スレッドのトーンを分類
- 結果をCodemode上で集計・保存
実際のコード例も紹介、 効率的な分析作業 を実現
Jevの評価結果：167件中156件が中立、11件が軽度のフラストレーション

今後の展望

MCP は改善余地が残るが、 Pi開発陣が積極的に関与 し、より良い仕組みを目指す姿勢
CodemodeやJev など新しい発想・技術との連携を強化
世界の変化に応じてPiも進化 し続ける方針

まとめ

MCPのコア統合 は、Piの柔軟性と将来性を高める判断
Codemode によるツール連携が新たな可能性を提供
今後もPiは状況に応じて進化・改善 を継続

提供: ハクソク · 要約更新: 2026年9月30日

AIによる日本語要約です。内容は原文とあわせてご確認ください。

Hacker Newsの議論を読む

Hackerたちの意見

MCPに対する彼らの消極的な姿勢は理解できるけど、/何か/がないよりはマシだよね。著者が指摘している理由で最適ではないけど、USB-Cもそうだし、NVMEもHDMIもそう。これらの技術は欠点があっても、広く互換性があって使いやすいからこそ成功してるんだ。だからMCPはどこにでもある。パフォーマンスや堅牢性、一貫性がないかもしれないけど、時間が経てば良くなるはず。今の広範なMCPエコシステムがあった方が、7つや8つの異なる「最適な」接続方法よりずっといいと思う。

└

同意するよ。私自身はMCPを使ってないけど、いい判断だと思う。彼らが同じようにして、最終的にはACPのネイティブサポートを追加してくれることを願ってる（https://agentclientprotocol.com/get-started/introduction）。実は、私は結構使ってるんだ。

サブエージェントのサポートが必要っていうのも同じ気持ちだな。これはかなり基盤的なものに感じる。賢いモデルが複数のより単純なモデルを動かして、同じ賢いモデルを使って敵対的レビューのためにサブエージェントを使うっていうのは、かなり一般的なパターンになると思う。個人的には、Piがそのほとんどをプラグインとして持っているのがちょっと混乱した。Eclipseがどれだけごちゃごちゃしていたかを覚えているから、あまりにも多くのプラグインがゆるく組み合わさっていたのを思い出して、OpenCodeにしたんだ。これでほとんどのニーズが満たされるからね。年を取ってきたせいかもしれないけど、IDEやデスクトップ環境もストックに近いものになってきた。

└

でも、MCPみたいにどうしても追加したり回避したりできないものもあるよね。他のことは、ただ組み合わせることでできるけど。サブエージェントのように、piや他のハーネスにユーザープロンプトやシステムプロンプトを使って新しい呼び出しを開始させることができる。正確なコマンドを共有すれば、piや他のハーネスは標準のUnixプログラムを使ってサブエージェントの簡易版を実行するよ。

└

私も同じことをしたよ。ツールがすごく早く進化するから、特定のものに時間を無駄にしたくないんだ。来週にはもう古くなっているかもしれないしね。だから、今動くならそれを使うし、ダメなら他のものを選ぶ。

└

ハハ、私には全く逆だよ :D。Claude Codeでは、すべてのサブエージェントの機能を無効にして、Bash、Edit、Write、WebSearch以外のほとんどのツールを無効にしたんだ。WebFetchは、自分のツールに置き換えたけど、サブエージェントを使うと結果がいつも悪くなるから、要約しないものにした。必要なコンテキストが欠けているし、弱いモデルは要約が下手だからね。システムプロンプトも、自分のものに置き換えたけど、トークンをかなり削減できたよ。エージェントにはもう10k以上のシステムプロンプトは必要ない。

└

oh-my-piはPiのフォークで、これらの機能をたくさん追加してるよ。https://github.com/can1357/oh-my-pi でも、あまり試してないから、どれくらいうまく動くかは保証できないな。

└

実は、これが私がPiを選んだ主な理由なんだ。特定のタスクのためにサブエージェントを生成する拡張機能を作ったこともあるよ。特に、コンテキストをクリーンに保ちたいときや、安いモデルに仕事をオフロードしたいときにね。そのおかげで、どのサブタスクにどのモデルが使われているかをしっかり把握できるんだ。Claude Codeは私の好みには合わないな。Piの特徴が少なくてカスタマイズ性が高いっていう哲学は、私の働き方にすごく合ってる。

PiがMCPをサポートしてないなんて知らなかった！新しいユーザーで、ちょうどいじり始めたところなんだ。ツールを整えていて、データベースのMCPを動かそうとしたんだけど（振り返ってみると、ちょっと大変だったな - でも、あれは自分がその接続を構築・維持する責任があると思ってたからかも）。もう一つ振り返ると、「No MCP」が彼らのフロントページの最初のアイコンに見えるんだよね - どうして見逃したのか分からない。これを読んで驚いたよ！

└

Piは権限モデルすらサポートしてないんだ。すごく基本的なもので、ほとんどすべてをカスタマイズすることが求められるよ。

このcodemodeが何なのか、まだ混乱してる。モデルはbashや他の典型的なUnixツールをうまく連携させるように訓練されてる。あまりにも上手くて、ちょっと不気味なくらいだよ。なんでこの能力を活用しないようにする必要があるの？単にシェルを直接使わせたくないっていう権限管理の問題なのかな？

└

それについては書くつもりだよ。codemodeはbashとは違う問題を解決するもので、bashはエージェントが特定のツールを実行するための手段なんだ。codemodeはLLMがハーネスレベルのツールを調整するための方法だよ。今これが起こっている理由は、ラボのモデルがますますこのように訓練されているから。例えば、Codexのレスポンスライトでは、並列ツール呼び出しを行うためにcodemodeが必要なんだ。

Hacker Newsで議論の続きを見る