0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@kai_kou(甲斐 甲)

Pi入門 — 70kスター、たった4ツールで動くAIコーディングエージェントの設計思想

0
Posted at

はじめに

Claude Code・Codex CLI・Gemini CLI…と並んで、OSSのAIコーディングエージェントが乱立している2026年。その中で異彩を放っているのが Pi（earendil-works/pi、旧 badlogic/pi-mono）です。GitHubで 70.7kスター を集めながら、コア設計は驚くほどミニマル。デフォルトで有効なネイティブツールはたった4つ、システムプロンプトは1,000トークン未満という「引き算の設計」で作られています1。

この記事では、Piを実際にインストールして動かしながら、その最小主義アーキテクチャがどう成立しているのかを解説します。

この記事で学べること

  • Piが「デフォルト4ツールだけ」でどこまでのことをやらせているか
  • システムプロンプトを1,000トークン未満に抑える設計テクニック（Skills遅延読み込み）
  • 実際にインストールして --list-models を叩いたときに見えたこと
  • Claude Code・Codex CLIなど他のエージェントとの設計思想の違い

対象読者

  • CLI型AIコーディングエージェントの内部構造に興味がある方
  • 自作エージェントのシステムプロンプト設計で「肥大化」に悩んでいる方
  • Claude Code以外のOSSエージェントを試してみたい方

前提環境

  • OS: Linux（macOS/Windowsでも動作）
  • Node.js: v22.x
  • パッケージマネージャ: npm

TL;DR

  • Piは デフォルトで有効なネイティブツールを read / write / edit / bash の4つ に絞り込んだCLI型コーディングエージェント（grep / find / lsなどは必要に応じて追加できるオプション扱い）
  • システムプロンプトは173行・約6.08KB（1,000トークン未満）2。他の主要エージェントが数千〜数万トークンのプロンプトを持つのとは対照的
  • 追加機能は「Skills」という遅延読み込み方式のプラグインで供給する。呼び出されるまでプロンプトに1行しか乗らない
  • Anthropic・OpenAI・Google・Amazon Bedrockなど30以上のプロバイダーに対応するが、実際に動く環境では APIキーが検出されたプロバイダーのモデルだけ が動的に一覧化される
  • MITライセンス。開発者はMario Zechner。2026年4月にEarendil Inc.へ参加し、同社にはFlaskの作者として知られるArmin Ronacherも携わっている3

背景・課題

多くのAIコーディングエージェントは、機能を足すたびにシステムプロンプトが膨らんでいきます。ツールの説明、注意書き、エッジケースの指示……これらは全て毎ターンのコンテキストに乗り、トークンコストと推論レイテンシを押し上げます。

Piの設計思想はこの逆を行きます。「最初から機能を絞り、必要なものだけをその場で読み込ませる」 ことで、常駐コストを最小化しているのです。

やったこと

ステップ1: インストール

READMEに従い、npmでグローバルインストールします4。

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

実行すると131パッケージが追加され、7秒ほどで完了しました。シェルスクリプト経由のインストールも用意されています。

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

インストール後、バージョンを確認します。

pi --version
# => 0.80.6

ステップ2: CLIの基本構造を確認する

pi --help を叩くと、Piがどんな設計思想で作られているかがオプション一覧からも透けて見えます。

pi --help

抜粋すると、以下のようなフラグが並びます。

--no-tools, -nt          全てのツールを無効化（組み込み・拡張とも）
--no-builtin-tools, -nbt 組み込みツールだけ無効化（拡張ツールは維持）
--tools, -t <tools>      有効化するツール名のホワイトリスト
--exclude-tools, -xt     無効化するツール名のブラックリスト
--skill <path>           スキルファイル/ディレクトリを読み込む
--no-skills, -ns         スキル探索・読み込みを無効化
--thinking <level>       off/minimal/low/medium/high/xhigh/max

--no-tools や --tools のようにツールの有効/無効を細かく制御できる設計自体が、「ツールは最初から絞り込む対象である」という思想の表れです。多機能を前提に「不要な機能を消す」設計ではなく、最初から機能ゼロを基準に「必要な機能を足す」設計になっています。

ステップ3: システムプロンプトの中身を確認する

Piのシステムプロンプトはソースコードで公開されています2。src/core/system-prompt.ts を見ると、以下の構成であることがわかります。

  • ネイティブツール（read / bash / edit / write）の説明
  • ガイドライン（7〜8項目程度）
  • Piドキュメントへの参照パス
  • プロジェクトコンテキスト（AGENTS.md / CLAUDE.md があれば）
  • 現在日時・作業ディレクトリ

ファイル自体は173行・約6.08KBですが、TypeScriptのテンプレート構文やコメントを除いた実際にモデルへ渡されるテキスト量は1,000トークンを切ります。Claude Code・Codex CLIのシステムプロンプトが数千〜数万トークン規模になりがちなことを踏まえると、この薄さは際立ちます。

なぜここまで削れるのか。 答えは「Skills」システムにあります。

ステップ4: Skills — フラクショナルプロンプトという発想

Piの拡張機能（Skills）は、Anthropicが提唱する Agent Skills 標準に準拠したオンデマンドの機能パッケージです4。ポイントは読み込みタイミングにあります。

  • 通常時: 各Skillはシステムプロンプトに 1行のサマリーだけ を追加する
  • 呼び出し時: /skill:name で明示的に呼ぶか、Piがタスク内容から自動検出したときだけ、Skillのフル内容（指示・ツールスキーマ）が展開される

これはJavaScriptの遅延ロード（lazy loading）と同じ発想です。「使うかもしれない機能」を全部常駐させず、「使うと決まった機能」だけをその場でロードする。Skillを10個インストールしても、システムプロンプトへの常駐コストは10行程度に抑えられます。

# スキルを指定して起動する例
pi --skill ./my-skill "このプロジェクトのテストを実行して"

# スキル探索自体を無効化する
pi --no-skills "シンプルなタスクだけやらせたい場合"

ステップ5: 対応モデルを一覧してみる

READMEには「Anthropic・OpenAI・Google・GitHub Copilot・DeepSeek・Mistral・Groqなど30以上のプロバイダーに対応」と書かれています4。実際に --list-models を叩いてみます。

pi --list-models

provider        model                                  context  max-out  thinking  images
amazon-bedrock  amazon.nova-2-lite-v1:0                128K     4.1K     yes       yes
amazon-bedrock  anthropic.claude-opus-4-8               1M       128K     yes       yes
...

この検証環境では 167モデル・3プロバイダー（amazon-bedrock / google / openai） が一覧に出ました。READMEの「30以上のプロバイダー対応」という数字とは一致しません。

ハマりポイント

ポイント1: 「対応プロバイダー数」と「一覧に出るプロバイダー数」は別物

READMEの「30以上のプロバイダー対応」は静的な対応能力を指しており、--list-models が動的に表示するのは その実行環境で認証情報（APIキーや環境変数）が検出できたプロバイダーのモデルだけ です。Anthropic・OpenAIの個別APIキーが未設定の検証環境では、環境側のブローカー経由で解決可能な3プロバイダー分だけが表示されました。

注意: READMEの対応プロバイダー数を鵜呑みにして「このプロバイダーも使えるはず」と決め打ちせず、まず pi --list-models で実際に使えるモデルを確認したほうが安全です。

ポイント2: 初回実行で設定ディレクトリが自動生成される

pi コマンドを一度でも実行すると、~/.pi/agent/settings.json を格納するディレクトリが自動生成されます。pi config コマンドで、このグローバル設定と、プロジェクトローカルの .pi/settings.json をTUIで切り替えながら編集できます。

pi config       # グローバル設定（~/.pi/agent/settings.json）
pi config -l    # プロジェクトローカル設定（.pi/settings.json）

著者視点の発見ポイント

実際にインストールして触ってみると、READMEやブログ記事だけでは分からなかった発見が2つありました。

1つ目は、--help のオプション設計そのものがドキュメントになっている点です。--no-tools / --no-builtin-tools / --tools / --exclude-tools という4段階の粒度でツールを制御できる設計から、「まず全部オフにできることを保証し、そこに必要な分だけ足す」という思想が一目で読み取れました。多くのエージェントは「便利機能を足していって、あとから制限フラグを追加する」順序で進化しますが、Piは逆順で設計されている印象を受けます。

2つ目は、--list-models の挙動です。READMEの「30以上のプロバイダー対応」という説明文だけを読むと、インストール直後から全プロバイダーのモデルが使えるように誤解しがちですが、実際にはAPIキー/認証情報が解決できたプロバイダーのモデルしか一覧に出ません。ドキュメントの「対応能力」と、手元の環境で「今すぐ使える範囲」は別のレイヤーであることを、コマンドを叩いて初めて実感しました。この手のギャップは、静的なREADMEを読むだけでは気づきにくく、実際に手を動かして初めて可視化される類のものです。

まとめ

  • Piはデフォルトのネイティブツール4つ（grep/find/lsは追加オプション）・システムプロンプト1,000トークン未満という「引き算の設計」でOSSコーディングエージェントとして70.7kスターを獲得している
  • 追加機能はSkillsという遅延読み込み方式のプラグインで供給し、システムプロンプトの常駐コストを最小化している
  • --list-models のような一覧コマンドは、ドキュメント上の「対応能力」と実行環境での「今使える範囲」が異なることを示してくれる。実際に動かして確認する価値がある
  • Claude CodeやCodex CLIのようなフル機能型エージェントとは対照的な設計思想であり、「エージェントのシステムプロンプトはどこまで削れるか」を考える上で参考になる実装

今後は実際のAPIキーを使ってPiでコーディングタスクをこなし、Skillsを自作してみる検証も試してみたいと思います。

参考リンク

  1. earendil-works/pi (badlogic/pi-mono) — GitHub（2026年7月9日時点で70.7k stars） ↩

  2. system-prompt.ts — GitHub ↩ ↩2

  3. Pi Agent Creator Joins Earendil ↩

  4. Pi Coding Agent README ↩ ↩2 ↩3

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?