Piを手元で動かす——システムプロンプト1,000トークン未満でも、エージェントは動く

ふむふむ。AIエージェントの話を聞いていると、「何でもできる」がどんどん当たり前になっていくんですよね。ブラウザも開けて、ファイルも読めて、サブエージェントまで呼べて——機能が増えるのは嬉しいけれど、ちょっと待って。その裏側では、context windowという限られた作業台に、説明書がどんどん積み上げられていませんか。

今週見つけたのは、そこに真っ向から逆張りするプロジェクトでした。Pi（パイ）です。Mario Zechner氏（GitHub: @badlogic）がpi-monoモノレポで公開している、MITライセンスのオープンソースなターミナル用コーディングハーネスで、FlaskとJinja2の作者として知られるArmin Ronacher氏も日常的に使っている pi-mono のプロジェクトなんです。

ここが面白いところで、Piのシステムプロンプトは1,000トークン未満。比較されるClaude CodeやOpenCodeではおよそ10,000トークンと言われるので、桁が一つ違います。しかも標準で搭載しているツールは、read・write・edit・bashのたった4つ。それだけで成り立つのか、ちょっと疑いました。迷探偵チカちゃん、出動です。

なぜ少なくて済むのか——「lazy skills」という発想

Piの立仮定はシンプルで、「frontierモデルはすでにエージェントの振る舞いをRLで訓練済みだから、長大な説明書は冗長」というものです。Zechner氏は自らのブログで「10,000トークンのシステムプロンプトは必要ない」と書いています。

じゃあ、4つのツールに入りきらない能力はどうするのか。ここにPiの核心があります。

• Skills: 各能力は「1行の説明」だけが常時コンテキストに置かれる（メニュー）
• 本体の詳しい手順書やツール定義は、そのスキルが実際に呼ばれたときだけロードされる（レシピ）
• 使い終われば手順書はコンテキストから離れる

つまり**「できることのリスト」は安く持ち回り、「やり方」は必要なときにだけ呼ぶ**。料理で言えば、献立とレシピの分離ですね。お店に全部のレシピ本を積まなくても、メニューを見てから厨房に取りに行けばいい。

さらに、足りない能力はプラグインマーケットに探しに行かず、エージェント自身にTypeScript拡張を書かせるのがPiの流儀です。writeとbashがあるので、ランタイムでツールを自作して、その場で使える。チカちゃん的には、この「上限は同梱品ではなく自作できるもの」という設計が一番面白いところでした。

手元で動かす——実際にやった手順

ここからが本題です。チカちゃんが踏んだ順番で書いていきます。

1. インストールはnpm一発

Piの公式READMEにある方法はこれだけです。

npm install -g @mariozechner/pi-coding-agent

依存も環境変数もいきなりは求められません。初回起動時にモデルプロバイダのログイン（OAuth）かAPIキーの設定を聞かれます。

2. 起動して、話しかける

pi

これでTUIが立ち上がります。デフォルトのまま read / write / edit / bash を与えられたモデルと対話します。まずは小さいタスクから——「このリポジトリのテストランナーが何か教えて」みたいな読み取り系から始めるのが安全です。

3. 好みに合わせて広げる

エディタで / を打つとコマンドが出てきます。よく使うものをいくつか。

• /model — モデルの切り替え
• /resume — 過去セッションの再開
• /tree — セッション内の任意の時点にジャンプ
• /compact — コンテキストの手動圧縮
• /export [file] — セッションをHTMLで書き出し

そして拡張はこの4か所に置けます。プロジェクト単位なら .pi/、自分全体なら ~/.pi/agent/ 以下です。

• Skills: ~/.pi/agent/skills/ や .pi/skills/ など
• Prompt Templates: /templatename で展開される定型文
• Extensions: TypeScriptで書く本格的なツール・コマンド登録
• Themes: 見た目はホットリロードされます

カスタマイズの入口は AGENTS.md です。プロジェクト直下に置けばそのプロジェクトに、~ 側に置けば全域に効きます。Piは「自分のワークフローにPiを合わせる」方針を明言していて、ほかのツールが内蔵している機能も、拡張やSkillsで自分で組み立てる設計なんです。

ここで一回、疑ってみましょう

便利に見える話には反対側もあります。Piの前提は「強いモデルがいれば薄い説明書で足りる」ですが、ワーキングメモリが弱いモデルだと、重いシステムプロンプトこそが信頼性を支えていることがあります。Zechner氏自身もBenchmarkの結果と併せて、最小プロンプトが万能ではない可能性には触れています。

もうひとつは「拡張を自分で書く」方向性です。楽しいけれど、これは裏を返せば整備コストがユーザー側に来るということでもあります。丸ごと使わせてもらって「困ったら直す」ステップを、人によっては重いと感じるかもしれません。

それでも——Piが問いを投げているのは本質的なところなんですよね。「agentの性能は、説明書の厚さで決まるのか？」。Piは「いや、決まらない」という賭けを実際に動かして示した。＝「ツールは厚く積むほど強くなる」という常識が、実はモデルの進化で崩れ始めているのかもしれない、という問いに繋がります。

まとめ——作業台の片付けは、モデルが進化した現代の技

4つのツールと1,000トークン未満のプロンプト。Piは「少なさ」を削ぎ落としではなく、contextに本題のための余白を残す設計として提示します。使ってみると、「これ、他のエージェントが当たり前に積んでいたものって、自分は何個使っていたんだろう」という、ちょっとした気づきが残りました。

これって、人間の作業環境も同じじゃない？ 机に便利グッズを積むほど捗るなら、最高に片付いた机が最高に捗るはずです。でも、意外とそうでもない。モデルが賢くなるほど、ハーネスは「教える」から「広げる」へと役割が変わりそう。この問いは、チカちゃんの哲学冒険譚でも大事にしている、AIと人間の関係のテーマにそのまま繋がります。

今日の話も、その入口のひとつでした。

参考URL

• Pi (pi-mono / badlogic) → https://github.com/badlogic/pi-mono
• What I learned building an opinionated and minimal coding agent (Mario Zechner) → https://mariozechner.at/posts/2025-11-30-pi-coding-agent/
• @mariozechner/pi-coding-agent (npm) → https://www.npmjs.com/package/@mariozechner/pi-coding-agent