Pi：自らツールを書く、ミニマルで自己拡張するコーディングエージェント

👁️ — 回閲覧

Pi はオープンソースのターミナル型コーディングエージェントで、1,000 トークン未満のシステムプロンプトと 4 つのコアツール（Read、Write、Edit、Bash）を中心に構築されている。組み込み機能を出荷する代わりに、必要に応じて自身の TypeScript 拡張を書く。MIT ライセンス、v0.78.1（2026 年 6 月 4 日）。

npm install -g --ignore-scripts @earendil-works/pi-coding-agent

Pi とは

Pi はオープンソースのコマンドライン型コーディングエージェントであり、2026 年の多くのハーネスとは逆の賭けに出ている。大きなシステムプロンプトと数十個の同梱ツールの代わりに、およそ 1,000 トークン未満のシステムプロンプトと、わずか 4 つのコアツール——Read、Write、Edit、Bash——だけを出荷する。サイト上の謳い文句は率直だ。「エージェントのハーネスは数多くあるが、これはあなたのものだ。」

このプロジェクトは Mario Zechner の作品として始まり、現在は Earendil Inc. のもとで開発されており、Armin Ronacher（Flask と Jinja2 の作者）からの貢献もある。コードは MIT ライセンスのもと badlogic/pi-mono モノレポにあり、@earendil-works/pi-coding-agent として npm に公開されている。本稿執筆時点での最新リリースは v0.78.1 で、2026 年 6 月 4 日にタグ付けされており、5 月を通して速いリリースペース（v0.75 から v0.78）であった。

差別化要因：自らの能力を構築する

決定的な特徴は自己拡張である。ある能力が存在しなければ、それを構築するよう Pi に頼むと、新しいツールと指示を公開する TypeScript 拡張モジュールを書き、それを呼び出せるようになる。これにより、ベースコンテキストを小さく保ちつつ、対象範囲をプロジェクトごとに拡げられる。リポジトリは再利用可能な部品にもきれいに分割されている。プロバイダ非依存の LLM レイヤー（@earendil-works/pi-ai）、エージェントランタイム（@earendil-works/pi-agent-core）、ターミナル UI ライブラリ（@earendil-works/pi-tui）、そしてコーディングエージェント CLI 本体である。

Pi は 4 つの動作モード——対話型、print/JSON、RPC、そして SDK——に加えて、ツリー構造のセッション履歴と 15 以上のプロバイダ統合を掲げている。最近のリリースは、自動化指向のツールとしての実務的な側面を示している。v0.77.0 では Claude Opus 4.8 のサポート、ツールを選択的に無効化する --exclude-tools、そしてヘッドレスログイン向けのデバイスコード認証が追加された。v0.78.0 では --name による名前付き起動セッションと、OSC 8 ハイパーリンクによるクリック可能なファイルパスが追加された。v0.78.1 ではプロバイダのカバレッジが拡大された。

比較

始め方

npm でグローバルにインストールする（--ignore-scripts フラグが文書化された形式である）か、インストールスクリプトを使う。

npm install -g --ignore-scripts @earendil-works/pi-coding-agent
# or
curl -fsSL https://pi.dev/install.sh | sh

そしてリポジトリ内で pi を実行し、ギャップにぶつかったら、プラグインマーケットプレイスに手を伸ばすのではなく、足りないツールを構築するよう頼めばよい。

実務者向けの注記

ミニマルなプロンプトのアプローチは、トークン予算と再現性を重視するなら最も魅力的だ。小さなベースコンテキストはモデルを操る隠れた指示が少ないことを意味し、プロジェクトごとの拡張は diff を取ってコミットできる、検査可能な TypeScript である。トレードオフは、エージェントがその後に自ら実行するコードを書くことを信頼している点にある——--ignore-scripts インストールフラグと、文書化されたコンテナ化の経路は、メンテナーがあなたにそれをサンドボックス化することを期待しているというシグナルである。生成された拡張は他の依存関係と同様に扱うこと。Bash アクセス権で実行される前に、それらをレビューすること。

あまり考慮されていない論点

興味深い長期的な問いは、「エージェントが自らツールを書く」ことが、耐久性のある共有可能な能力を生むのか、それともプロジェクトをまたいでほぼ重複する使い捨ての拡張が乱立するのか、という点である。各リポジトリが自身のツールセットを成長させられるようにするハーネスは、プラグインエコシステムのキュレーションという問題を、断片化という問題と交換している——5 つのプロジェクトがそれぞれ、わずかに異なる「テストを実行して失敗を要約する」ツールを再発明しかねない。このモデルで勝つチームはおそらく、エージェントが書いた拡張をファーストクラスのソースコードとして扱う者たちだろう。すなわち、バージョン管理し、レビューし、毎回ゼロから再生成するのではなく、共有された社内ライブラリへと昇格させるのである。