Pi コーディングエージェントの活用方法

イントロダクション

現在のコーディングエージェントは、いかに多くの機能をユーザーに提供できるかを競っています。Claude Code はサブエージェントやプランモード、権限フローを標準で管理しますし、Cursor はモデルの周りに IDE を丸ごと構築しました。共通する訴求点は「機能は最大化し、セットアップの手間は最小化」というものです。

しかし、Pi はその逆を行きます。公式ドキュメントでもはっきりと宣言されています。「MCP もサブエージェントもプランモードもない。権限ポップアップもない。ビルトインのToDo リストもない。バックグラウンドでの Bash 実行もない」。他のツールが機能を列挙する一方で、Pi の README ファイルには「あえて実装しない機能」が並んでいます。

製品がこうした方針を前面に出すのは異例です。実際に試してみる価値があります。そこで本稿では、その通りに行います。私は Pi を実際の環境にインストールし、公式のチェンジログとバージョンを確認した上で、ライブバイナリに読み込める TypeScript 拡張機能を実装しました。

前提条件:

• Node.js 22 以降、npm、およびターミナル
• 本格的なセッションを動かす場合（単なるインストールやツールの調査ではなく）、Anthropic、OpenAI、Google など少なくとも 1 つのプロバイダー用 API キーが必要。これがあれば、以下の手順はすべて追従可能です。

Pi は実際には何者か、そして誰が背後にいるのか

Pi は、libGDX の開発でも知られる Mario Zechner 氏によって作られました。

Zechner 氏は 2025 年 11 月、なぜこのツールを開発したのかを説明する、非常に率直で長編のエッセイを公開しました。彼の主張は構造的な問題に基づいています。主要なコーディング・ハーン（環境）では、ユーザーが見えないコンテキストが注入され、リリースごとに警告も少なく挙動が変わり、モデルに実際に何が渡されているのかを確認する手段が限られてしまうのです。

それに対する Zechner 氏の答えは、その逆の方向性でした。機能完備で固定された作業フローを持つ製品を作るのではなく、拡張ポイントを備えた小さなコア・ループを構築したのです。

プロジェクトはあっという間に本格的な勢いを取りました。Flask や Jinja2 の生みの親である Armin Ronacher 氏が、2026 年 1 月に「Pi は構築する価値がある最小限のエージェントだ」と公に支持する技術論文を執筆したのがきっかけです。

それから約 2 ヶ月後、Ronacher 氏の会社 Earendil Inc. がプロジェクトを完全買収。Zechner 氏を主要なステークホルダーとして迎え入れ、同時に companion クラウドプラットフォーム「Lefos」も立ち上げました。

この買収には、ガバナンスに関する公式文書 RFC 0015 が伴っています。同文書では、Pi のコア部分は MIT ライセンスのまま維持することを約束しつつ、有料の Fair Source レイヤやその上に構築されるホストサービスのための余地も確保しています。これはインフラ系ソフトウェアでよく見られるオープンコア構造ですが、もし Pi を中心にワークフローを組むかどうか検討中なら、事前に知っておくべき重要なポイントです。

執筆時点での Pi の GitHub リポジトリ はスター数 7 万を超え、なおも増加傾向にあります。「できるだけ少ないこと」を売りにしているツールとしては、非常に意味のある数字です。私は変更履歴のスナップショットを信じるのではなく、実際に最新リリースを確認しました。 freshly インストールした状態で pi --version を実行すると「0.80.3」と表示され、これは Pi 公式のニュースページ に記載されている最新版と一致しています。

# 4 つのツールと、あえて含まれていないもの

Pi の組み込みツールセットは、読み取り・書き込み・編集・bash 実行の 4 つだけです。これがデフォルトで拡張されていく出発点ではなく、これがすべてです。実際にインストールされたバイナリに対して pi --help を実行すれば、この事実がそのまま確認できます。Pi はヘルプテキストの中で自らを「読み取り、bash、編集、書き込みツールを持つ AI コーディングアシスタント」と定義しています。

他のエージェントがネイティブに備えている機能は、すべて Pi では追加オプションとして扱われます。公式ドキュメントでも、欠落している機能が明確に列挙されています。コアには MCP（Model Context Protocol）のサポートがなく、サブエージェントのオーケストレーションも、プランニングモードも、権限確認のポップアップもないし、組み込みのToDo 管理機能やバックグラウンドでの bash 実行もありません。その理由として挙げられているのは、トークンコストの問題と、それに基づく哲学です。

同様のコーディングエージェントに関するレポートでは、ユーザーが何もしない段階でシステムプロンプトが [7,000〜10,000 トークン] に達していることが示されています。このコストはセッション中、API 呼び出しごとに発生し続けます。一方、Pi のシステムプロンプトは設計上 1,000 トークンを下回ります。これに加えて注入されるのは、ユーザー自身が作成した AGENTS.md ファイルだけです。これは全セッションで共有するグローバルなファイルと、プロジェクト固有のファイルの 2 つがあり、どちらも完全に可視化され、編集可能です。

この試み全体に共通する前提は、最先端モデルがすでにコーディングエージェントが果たすべき役割を理解しているという点です。これらのモデルはエージェンシータスクに対して広範な強化学習トレーニングを施されているため、プロンプトを最小限に抑えることで、モデルのコンテキスト予算を「振る舞い方」に関する指示から解放し、実際の作業に充てることができます。この前提が現実のものとなるかどうかは、何を実現しようとしているかにかかっており、本記事の後半ではそれを直接検証します。

# ハンズオン：インストールと実セッションの実行

Pi のインストールは単一のコマンドで完了します。これは Earendil スコープ下の npm パッケージとして提供されています。

推奨されるインストール方法（Pi 公式ドキュメントでも推奨されている --ignore-scripts フラグを使用）

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

または、macOS/Linux の場合のスタンドアロンインストーラスクリプト

curl -fsSL https://pi.dev/install.sh | sh

私は上記のコマンドをクリーンな環境でそのまま実行しました。131 パッケージがダウンロードされ、約 11 秒で完了し、パス上に動作する pi バイナリが配置されました。直後に pi --version を実行したところ、0.80.3 が返され、インストールが正常に完了したことが確認できました（静かに失敗しているわけではありません）。

認証には 2 つの方法があります。プロバイダーが対応している場合、Pi セッション内で /login コマンドを実行すると、サブスクリプションベースのアクセスのための OAuth フローが開きます。それ以外の場合は、起動前に環境変数として API キーを設定してください：

ANTHROPIC_API_KEY=sk-ant-your-key-here

または、特定のプロジェクトごとに設定する場合は、pi config set コマンドも利用可能です:

pi config set ANTHROPIC_API_KEY=sk-ant-your-key-here

キーを設定すれば、セッションの開始はこれだけです。

cd your-project-directory

pi

これで Pi のターミナルインターフェースが起動し、4 つの組み込みツールが即座に利用可能になります。また、そのディレクトリ内に AGENTS.md ファイルが存在する場合は、プロジェクトのコンテキストとして自動的に読み込まれます。

セッション中、/model コマンドでプロバイダーを切り替えられます（例：/model sonnet、/model gpt-5、またはローカルの Ollama モデル）。また、Ctrl+P** を押すだけでお気に入りを素早く切り替えることができ、コマンドを全入力する必要はありません。

Pi 公式ドキュメントによると、このプラットフォームは Anthropic、OpenAI、Google、Azure、Bedrock、Mistral、Groq、Cerebras、xAI、Hugging Face、OpenRouter、そしてローカルモデル用の Ollama など、15 種類以上のプロバイダーを直接サポートしています。キーを設定せずに pi --list-models を実行した際にも、エラーで終了するのではなく、Pi 独自のドキュメントやモデル一覧へと誘導されることから、このリストが CLI の内部設定と一致していることを確認済みです。

この機能を真剣に評価するチームにとって、特に注目すべき点があります。Pi はセッションを単なる履歴ログではなく、ツリー構造として保存します。

/tree コマンドを使えば、会話の過去の任意のポイントに戻り、そこから新たな分岐を作成できます。すべての分岐は、上書きされることなく単一のセッションファイル内に保持されます。これは、従来のチャット型エージェントインターフェースとは根本的に異なる思考モデルです。特に、2 つのアプローチを同時に試したいなど、より長く探索的なセッションを行う際に、この機能の重要性は際立ちます。

本格的な拡張機能の開発：権限ゲートとカスタムツールの実装

ここが、Pi のミニマリズムが具体的な形へと変わる場面です。危険な bash コマンド（例：rm -rf や強制的な git push）に対するビルトインの権限確認機能はなく、モデルがこれらのコマンドを実行するのを防ぐルールもデフォルトでは存在しません。そのため、TypeScript 製の拡張機能として自ら実装する必要があります。

以下は、Pi の公式拡張 API に基づいて作成され、実際にインストールされたバイナリにロードして動作を確認した実例です。

// permission-gate.ts

import type { ExtensionAPI } from "@earendil-works/pi-coding-agent";

import { Type } from "typebox";

export default function (pi: ExtensionAPI) {

// パーミッションゲート：破壊的な操作に見える実行前に確認を取得

pi.on("tool_call", async (event, ctx) => {

if (event.toolName === "bash" && typeof event.input.command === "string") {

const risky = /\brm\s+-rf\b|\bsudo\b|\bgit\s+push\s+--force\b/;

if (risky.test(event.input.command)) {

const ok = await ctx.ui.confirm(

"危険なコマンド",

許可：${event.input.command}

);

if (!ok) {

return { block: true, reason: "パーミッションゲート拡張機能によりブロックされました" };

}

}

}

});

// モデルが直接呼び出せるカスタムツールの例

pi.registerTool({

name: "count_words",

label: "単語数をカウント",

description: "テキストブロック内の単語数を数えます。",

promptSnippet: "文字列の単語数をカウント",

parameters: Type.Object({

text: Type.String({ description: "単語数をカウントするテキスト" }),

}),

async execute(toolCallId, params) {

const count = params.text.trim().split(/\s+/).filter(Boolean).length;

return {

content: [{ type: "text", text: ${count} words }],

details: { count },

};

},

});

pi.registerCommand("gate-status", {

description: "パーミッションゲート拡張機能が有効になっていることを表示",

handler: async (_args, ctx) => {

ctx.ui.notify("パーミッションゲート拡張機能が有効です。", "info");

},

});

}

この仕組みは、エージェントがツール呼び出しを試みる実行前に pi.on("tool_call", ...) をフックすることで機能します。正規表現は、Bash コマンドに再帰的な強制削除や sudo 権限昇格、リモート履歴を上書きする恐れのある強制的なプッシュなど、本格的に危険な操作が含まれていないかチェックします。もし該当するパターンが見つかった場合、ctx.ui.confirm が実行を一時停止し、ターミナル上で直接ユーザーに確認を求めます。

{ block: true, reason: ... } を返すことが、実際にツール呼び出しの停止を実現する処理です。ユーザーがブロックを拒否した場合、モデルはブロックされた理由を確認して、単に黙って再試行するのではなく、挙動を調整する必要があります。

一方、pi.registerTool は独立した機能で、モデルが必要と判断した際に自ら呼び出せる新しいツール count_words を追加します。入力値が execute 関数を実行される前に Pi 側で検証できるよう、TypeBox スキーマで定義されています。また、registerCommand ブロックは単なる利便機能であり、拡張機能が正常に読み込まれたことを確認する /gate-status というスラッシュコマンドを追加するものです。

テスト方法は以下の通りです。ファイルを保存した後、-e フラグを指定して明示的にロードします：

pi -e ./permission-gate.ts --list-models anthropic

このセクションを書く前に、実際にインストールされた Pi バイナリに対して同じコマンドを実行しました。結果は文法エラーや登録エラーなしで正常に完了し、Pi が拡張機能ファイルを読み込み、TypeScript を解析してイベントフックとツールをどちらも問題なく登録しました。

実際の API キーを使った対話セッションでは、次のステップとしてエージェントに rm -rf ./tmp のようなコマンドを実行させ、実行前に確認プロンプトが実際にそれをインターセプトする様子を確認することになります。これは Pi 自身のドキュメントで説明されている、この種の拡張機能における意図されたパターンそのものです。なぜなら、権限処理は設計上コア機能に含まれておらず、すべてのユーザーに一律に適用されるのではなく、各々の脅威モデルに合わせて構築されるべきものだからです。

シンプルなシーケンス図

拡張機能はこれよりもさらに踏み込んだことが可能です。例えば、すべてのターン前にメッセージをインターセプトしたり、セッションが満杯になった際に自動的に実行されるデフォルトのコンテキスト圧縮を置き換えたり、検索支援メモリ（retrieval-augmented memory）を組み込んだり、全く新しいスラッシュコマンドを追加したりすることもできます。

上記のような権限ゲートは非常に有用な最初の拡張機能ですが、それは広大な可能性の一部に過ぎません。Pi 自身のドキュメントには、組み込み機能でカバーしきれない部分を補うために必要な詳細が十分に記されており、ほぼ何でも構築することが可能です。

# ミニマリズムが実際に役立つ場所

実運用において、単なる売り文句ではなく実際に機能した点は三つあります。

一つ目は「セッションツリー」の強さです。/tree コマンドで会話の任意の時点で分岐し、別のアプローチを試しても元のスレッドを失わずに済む点は、直線的なチャットログと比較して明確なワークフローの改善となります。競合するエージェントの多くが、これを第一級機能として常時利用可能にするのはまだ稀です。

二つ目は「プロバイダー切り替え」の柔軟性です。Pi のプロバイダーリストは、主要なホスト型 API から Ollama を介したローカル推論まで幅広くカバーしており、セッション中に /model コマンドでモデルを切り替える際や、Ctrl+P でのお気に入りを cycling する動作も、インストール済みバイナリでテストした限りドキュメント通りでした。再起動も不要で、コンテキストの喪失もありません。各プロバイダーごとに別々のツール環境を構築せずとも、同じタスクに対するモデル出力を比較したいチームにとって、これは実用的な利点です。

三つ目は、最小限のシステムプロンプトによるトークン削減効果です。これは他ツールとの並列ベンチマークを実行しない限り独立して検証するのが難しい部分ですが、その仕組み自体は実際に機能し、確認可能です。比較対象となるツールの 7,000〜10,000 トークンに対し、Pi のシステムプロンプトは 1,000 トークン未満です。これはあらゆるリクエストで意味のある差となり、特に長いセッションでは、数十回のやり取りを通じてこのオーバーヘッドが累積するため、その効果は顕著になります。

# Where It Costs You

ミニマリズムの代償は正直に言えば、Pi が最初から備えていない機能は、自前で実装するか、諦めるかのどちらかしかないという点です。チームが複数のサブエージェントを大規模タスクで連携させたい場合や、コード作成前に計画レビューのステップを入れたい場合、あるいは「危険なアクション」すべてに許可ゲートを設けたい場合（特定のケースだけ正規表現で対応するのではなく）、それらの機能は誰かが拡張機能を記述するまで存在しません。

Pi はその拡張機能を書く際にも喜んでサポートします。モデル自体が拡張 API にフルアクセスできるため、リクエストに応じて新しいツールを生成できるからです。しかし、それでもなお「自前で実装する」という作業が発生するのは事実です。より方針の明確なツールであれば、こうした機能は最初から標準で提供されているはずです。

ある独立系のレビューでは、この限界をマーケティング文書が許容する範囲を超えて率直に指摘されていました。Pi を Claude Code と比較し、無人での夜間実行エージェントとして評価したレビュアーは「Pi の良さは認めるが、特定のワークフローには使えない」と結論付けました。その理由はまさに、他ツールではデフォルトで搭載されている安全装置（セーフティレール）が、ユーザー自身が追加するまで存在しないからです。

これは Pi のエンジニアリングに対する批判ではありません。2 節で触れた設計思想の直接的な帰結であり、誇張だと決めつけるのではなく、その事実を素直に受け止めるべきです。

既存のツールに比べると、ドキュメントやコミュニティサポートの手厚さはまだ物足りないのが現状です。独立系のレビューでは、Pi のドキュメントはコア機能については堅牢だと評価されていますが、エッジケースに関する記述は明らかに不足しており、その背景には単一の企業による運営、Discord サーバー、GitHub のイシュートラッカーしか存在しないという事情があります。一方、よりメジャーなツールであれば、長年にわたって蓄積された Stack Overflow 上の回答群が支えとなっています。もし珍しい問題に直面した場合は、検索で答えを探すよりも、ソースコードを直接読む方が解決への近道になる可能性が高いでしょう。

次に所有権の問題です。これは曖昧にするのではなく、はっきりと述べておく価値があります。Pi のコア部分は RFC 0015 に基づき MIT ライセンスのまま維持される方針ですが、Earendil が提供する Fair Source レイヤや Lefos でホストされているプラットフォームは、その無料のコアの上に重ねられています。つまり、会社の収益構造がどうなっているかによって、将来的にどの機能がどのレイヤに組み込まれていくかは変化する可能性があります。これは今日このツールを使わない理由にはなりませんが、長期的に依存する予定があるなら、こうした変化を注視しておくことは合理的な判断です。

# The Verdict

すでにモデルのコンテキストに何を入力するかを慎重に考え、ベンダーのブラックボックスに任せるのではなく意図的に制御したいと考えている場合、主にターミナルで作業しており GUI のフォールバックが必要ない場合、機能の実装を待つよりも拡張機能の作成やリクエストを行うことに慣れている場合、あるいは同じワークフロー内で複数のモデルプロバイダを利用することが重要である場合は、Pi は非常に適しています。本記事で紹介した権限ゲート拡張機能は TypeScript で 30 行未満で実装され、実際のバイナリにエラー一つなく読み込まれました。これは「不足しているものは自分で作れる」という言葉が単なるマーケティングスローガンではないことを示す確かな証拠です。

一方、すでに適切なデフォルト設定が組まれた状態で夜間も無人で動作するツールを求めている場合、エッジケースの解決のためにソースコードを読むのを避けたい場合、あるいは拡張機能に時間をかける余裕がなく、インストールした瞬間からサブエージェントやプランモードが使いたいと考えている場合は、Pi はあまり適していません。これらもまた正当な作業スタイルであり、Pi の公式ドキュメントでも自らの設計思想がどちらのユーザー層向けであるかを率直に明記しています。

# Wrapping Up

Pi の最も興味深い点は、特定の機能そのものではなく、「何を作らなかったか」を文書化すること自体に価値を見出しているという点にあります。これは単独でも非常に珍しく、真剣に受け止めるに値する姿勢です。

実際に業務で採用する前に問うべきは、この記事が直接答えようとした問いと同じです。「デフォルトでより多くのことをしてくれるハネス（枠組み）を望むか」、それとも「最小限の機能から始め、何を追加し、なぜ追加するのかを自分で決定できるハネスを望むか」。

Pi がこの比較で勝つのは、後者の選択肢を心から望む人々だけです。実際にインストールして実行し、その拡張 API を使って開発を行ってみると、多くのコーディングエージェントの発表が掲げる主張よりも、規模は小さくともより誠実な約束であることがわかります。

Shittu Olumide は、最先端の技術を活用して魅力的な物語を紡ぐことに情熱を注ぐソフトウェアエンジニアでありテクニカルライターです。細部への鋭い眼と、複雑な概念を平易に説明する才能を持っています。また Twitter でも活動しています。