Pi coding agentとは｜MCPに頼らず拡張できるTUIハーネス

Claude Code や Codex CLI といった coding agent CLI を業務に組み込むエンジニアが増える一方で、「パーミッションのポップアップが煩わしい」「MCP サーバがコンテキスト予算を食い潰す」「自社のワークフローに合わせて拡張したいが、フォークして本体を書き換えるのは避けたい」といった不満も蓄積してきました。

そこに登場したのが、TUI ライブラリ作者としても知られる Mario Zechner 氏率いる Earendil Inc. の「Pi Agent Harness / Pi coding agent」です。GitHub 上ではリポジトリ earendil-works/pi として公開されており、本記事執筆時点で 7 万を超えるスターを集める活発なプロジェクトになっています。

とはいえ Pi は「Claude Code の代替」として単純に置き換えられるプロダクトではなく、設計思想・拡張機構・想定ユースケースがかなり尖ったツールです。「MCP を採用しない」「permission popup を持たない」といった選択には理由があり、その理由を理解せずに導入すると想定外の運用課題に直面します。

本記事では Pi coding agent とは何かを、公式サイト・公式ドキュメント・作者ブログ・README を一次情報として整理します。設計思想 → 主要機能 → 導入手順の勘所 → Claude Code / Codex CLI / OpenCode との使い分け → 本番導入前に必ず確認すべき注意点、という順番で読み進めることで、自分のユースケースに Pi を試すべきかを判断できる材料をひと通り揃えられる構成にしました。なお本記事は動作検証を行わず、公式情報のドキュメントベースで整理しています。実行結果を保証するものではないため、実際の挙動は必ず公式ドキュメントと最新版で確認してください。

Pi coding agentとは何か

Pi coding agent は、earendil-works/pi リポジトリで開発されている OSS の TUI コーディングエージェントです。単なる CLI ツールではなく、公式サイト（pi.dev）でも「AI agent toolkit」と説明されている通り、LLM 呼び出し・エージェントランタイム・TUI レンダリング・coding agent CLI がひとつのモノレポにまとまった構成になっています。

まずはリポジトリの基本情報から確認します。本記事執筆時点（2026 年 7 月時点、gh api /repos/earendil-works/pi 取得値）で、以下のとおり公開・活発なプロジェクトです。

archived=false かつ fork=false であり、独立プロジェクトとして日次で更新が入っていることが確認できます。フォーク版でもアーカイブ済みでもないため、記事執筆時点では現役のプロジェクトとして扱えます。

Pi Agent Harnessの位置づけ

Pi の README で最初に強調されるのは「AI agent toolkit」という言い回しです。Anthropic の Claude Code や OpenAI の Codex CLI が「特定モデルに最適化された単一 CLI」であるのに対し、Pi は 4 つのパッケージから成るツールキットです。coding agent CLI はその中の 1 パッケージに過ぎず、他の 3 パッケージは「LLM プロバイダ統合層」「エージェントランタイム」「TUI ライブラリ」として単独でも利用できる形で切り出されています。

この構成は、「Pi 本体をフォークしなくても、自分のアプリケーションに coding agent 相当の仕組みを組み込める」という設計意図に直結しています。公式サイトに掲げられている "Adapt Pi to your workflows, not the other way around." という一文にも、この方針は端的に表れています（pi.dev）。

モノレポを構成する4つのパッケージ

README の "All Packages" セクションに記載されているとおり、Pi は次の 4 パッケージで構成されています。

「coding agent CLI」として認知されている Pi は、正確にはこの @earendil-works/pi-coding-agent パッケージを指します。一方、社内サービスに coding agent 相当の機能を組み込みたい場合は @earendil-works/pi-agent-core を直接ライブラリとして使う選択肢もあり、この分離が Pi をツールキットたらしめている核になっています。

開発体制とライセンス

Pi は Earendil Inc. がスポンサーとなる OSS で、主要な開発者は libGDX や TUI ライブラリ実装で知られる Mario Zechner 氏です。ライセンスは MIT で、ビジネス利用にも十分な自由度があります。前掲のとおりスター数 78,954・フォーク数 9,705 と、GitHub 上の外部関心度も相応に高い水準です。

コミュニティチャネルとして 公式 Discord も提供されており、公式のフィードバック窓口が用意されています。

Pi coding agentが掲げる設計思想

Pi を評価する上で最も重要なのは「なぜこの機能があって、あの機能がないか」という選択の背景を理解することです。公式サイトのキャッチコピーと公式ドキュメント、そして作者ブログには、Pi の設計思想を象徴するフレーズがいくつも登場します。

「There are many agent harnesses—but this one is yours」— 拡張前提の設計

公式サイト（pi.dev）のトップに掲げられているのは "There are many agent harnesses—but this one is yours" というフレーズです。Pi は「万人向けのオピニオン付き既製品」を目指しておらず、「自分のワークフローに合わせて harness を作り替える人」を想定しています。

同じく公式サイトには "Adapt Pi to your workflows, not the other way around." という短い一文も置かれており（pi.dev）、ユーザ側のワークフローを Pi に合わせるのではなく、Pi をユーザ側に寄せるという方針が明示されています。この考え方は、後述する Extensions / Skills / Prompt Templates / Themes という 4 種の拡張ポイントに直結しています。

MCPを採用しなかった理由

Pi は Model Context Protocol（MCP）をあえて採用していません。この判断の背景を語ったのが、作者による What if you don't need MCP at all? というブログ記事です。要点は以下の 3 つです。

1. MCP サーバはツール定義でコンテキストを大量に消費する。作者は「Playwright MCP has 21 tools using 13.7k tokens (6.8% of Claude's context)」「Chrome DevTools MCP has 26 tools using 18.0k tokens (9.0%)」と具体的な数値を挙げている（What if you don't need MCP at all?）
2. MCP の出力はエージェントコンテキストを通じて次のツール呼び出しに渡す必要があり、単純な合成（Unix パイプのように別ツールへ流し込む）が難しい。作者は "any output has to go through your agent's context. You can kind of fix this by using sub-agents, but then you rope in all the issues that sub-agents come with" と述べている
3. 既存 MCP サーバの挙動を変えたければソースコードの理解が必要で、拡張コストが高い

その代替として作者が提示したのが「Bash スクリプト + 薄い Extension」の組み合わせで、実例として同じ用途を「225 tokens」の README 相当で置き換えたと報告しています。この考え方が、Pi が MCP ではなく Extensions（TypeScript）と Bash 実行を第一級のプリミティブに据えている理由です。

意図的に非採用の4つの機能

Pi は次の 4 つを「機能ではなくプリミティブから作れる領域」と位置づけ、コア実装から意図的に外しています。

• MCP（Model Context Protocol）
• Sub agents
• Permission popups
• Plan mode

これらが必要なユースケースでは、ユーザ側が Extension として実装するか、他ツールに委譲することが前提になります。裏を返せば、これらが「デフォルトで付いてくること」を Pi に期待して導入すると、後述の Permission 対策のように追加の運用設計が必要になります。

Pi coding agentの主要機能

Pi の主要機能は「拡張前提の最小コア」という思想に沿って設計されています。ここでは、Pi の中核を理解する上で押さえておきたい 5 つの機能領域を公式ドキュメントベースで整理します。

4つの実行モード

Pi coding agent には 4 つの実行モードがあり、対話用途と自動化用途の両方をカバーします（Pi Docs（Latest））。

RPC モードと SDK モードは、CI/CD への組み込みや社内スクリプトから coding agent を呼び出すシナリオを想定した設計になっています。「対話型 CLI のみが必要」というユースケースにとどまらず、社内自動化のバックエンドとしても使える点が Pi の実務的な差別化ポイントです。

ツリー型セッションとfork・share

Pi のセッションは JSONL 形式で保存され、ツリー構造で管理されます。過去の任意地点から分岐して別の探索を試すといった使い方が想定されており、/tree・/fork・/share・/compact などのスラッシュコマンドが提供されます。

• /tree: 過去メッセージのツリー表示と分岐先の選択
• /fork: 特定メッセージから新規セッションを派生
• /share: セッションを GitHub Gist にプライベート共有
• /compact: 長いセッションを要約（コンテキスト上限接近時は自動でも走る）

「ある地点まで戻って別の方針を試す」といった探索的な使い方が想定されており、これは linear なセッションだけを扱う多くの CLI とは異なる特徴です。

Extensions（TypeScriptでツール・コマンド・イベントを追加）

Pi の拡張ポイントの中心は Extensions です。TypeScript ファイル 1 つで、スラッシュコマンド・LLM ツール・ライフサイクルイベントを追加できます。ファイル配置は次のとおりです（Extensions ドキュメント）。

• グローバル: ~/.pi/agent/extensions/*.ts または ~/.pi/agent/extensions/*/index.ts
• プロジェクト: .pi/extensions/*.ts または .pi/extensions/*/index.ts

プロジェクトローカルの Extension は、プロジェクトが trust された後にのみロードされます。この "Project-local .pi/extensions entries load only after the project is trusted." という制約は、任意のリポジトリを開いた瞬間に任意のコードが走らないための重要なガードです（Extensions ドキュメント）。

公式ドキュメントに掲載されている最小の Extension 例のうち、記事の説明に必要な session_start イベントと hello コマンドの登録部分を抜粋します（Extensions ドキュメント より、import { Type } from "typebox" のインポート文・pi.on("tool_call", ...) のイベントハンドラ・pi.registerTool({...}) のツール登録ブロックは省略。全体像はリンク先を参照）。

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

export default function (pi: ExtensionAPI) {
  pi.on("session_start", async (_event, ctx) => {
    ctx.ui.notify("Extension loaded!", "info");
  });
  // ... (pi.on("tool_call", ...) と pi.registerTool({...}) を省略)
  pi.registerCommand("hello", {
    description: "Say hello",
    handler: async (args, ctx) => {
      ctx.ui.notify(`Hello ${args || "world"}!`, "info");
    },
  });
}

pi.on(event, handler) で session_start / tool_call / tool_result / input / before_agent_start などのイベントを購読でき、pi.registerCommand() でスラッシュコマンド、pi.registerTool() で LLM が呼び出せるツールを追加できます。テストは pi -e ./extension.ts のように単発ロードで実行可能です。

Skills（SKILL.mdベースの自己完結パッケージ）

Extensions がランタイムの挙動を変える仕組みなのに対し、Skills は「特定の作業に特化した自己完結パッケージ」を追加する仕組みです。フロントマター付きの SKILL.md と、必要なスクリプト・アセットで構成されます（Skills ドキュメント）。

• 配置: ~/.pi/agent/skills/（グローバル）または .pi/skills/（プロジェクト）
• 明示ロード: /skill:name コマンド
• フロントマター必須項目: name（64 文字以下、小文字＋数字＋ハイフン）、description（1024 文字以下、「何をするか」と「いつ使うか」の両方を含める）

Extensions と Skills の違いは、Extensions が「TypeScript でランタイム挙動を書き換える」もの、Skills が「あるタスクを再現するためのプロンプト・スクリプト・データを 1 パッケージに束ねた」ものと整理すると分かりやすい構成です。

15+ プロバイダ対応とセッション中モデル切替

Pi は特定のモデルベンダに依存せず、15 種類以上のプロバイダに対応します。README には Anthropic / OpenAI / Google / Azure / AWS Bedrock / Mistral / Groq / Cerebras / xAI / Hugging Face / Kimi For Coding / MiniMax / NVIDIA NIM / OpenRouter / Ollama / DeepSeek / llama.cpp などが挙げられており、セッション中のモデル切替も可能です。

認証は /login コマンド（一部プロバイダはサブスクリプションログインに対応）または ANTHROPIC_API_KEY などの環境変数で行います。プロバイダ横断で 1 つの CLI に統一したい、あるいは OSS モデル（Ollama や llama.cpp）を主軸にしたいユーザにとっては大きな利点です。

なお、公式ドキュメントでは Pi がデフォルトで LLM に提供するツールを "By default, pi gives the model four tools: read, write, edit, and bash." と説明しています（Pi Docs Quickstart）。それ以外のツールは Extensions か Skills として追加する設計です。

Pi coding agentの導入と最初の一歩

ここからは、公式ドキュメントに記載されている導入ステップを引用ベースで整理します。本記事では動作検証を行っていないため、実行結果の保証はできません。実際のインストール時は必ず公式 Quickstart と npm パッケージページ を参照してください。

npmでのインストール

公式 Quickstart に掲載されているグローバルインストール例は次のとおりです（Pi Docs Quickstart より引用）。

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

--ignore-scripts フラグが付いている点に注目してください。Pi はサプライチェーンハードニングの一環として、後述のとおりインストール時のライフサイクルスクリプト実行を明示的に制限する運用を推奨しています。README では pnpm・Bun 経由のインストールも案内されていますが、具体的なコマンド表記はディストリビューション更新で変わる可能性があるため、npm パッケージページ の最新表記を確認してください。

プロバイダの認証設定

インストール後、プロジェクトディレクトリで pi コマンドを実行して起動します。認証には次の 2 通りが用意されています（Pi Docs Quickstart）。

• サブスクリプションログイン: /login コマンドから Claude Pro/Max・ChatGPT Plus/Pro・GitHub Copilot などのビルトインプロバイダを選択
• API キー: ANTHROPIC_API_KEY などの環境変数を設定した上で pi を起動

サブスクリプションログインは対応プロバイダが限られるため、業務利用では API キーを SSM や Vault で配布する運用のほうが管理しやすい場面もあります。

プロジェクトローカル設定と.pi/ディレクトリ

Pi はプロジェクトごとに .pi/ ディレクトリを持ち、Extensions や Skills をプロジェクトローカルで配置できます。前掲のとおり、.pi/extensions/ のロードは「プロジェクトが trust された後」に限定されるため、git clone した見知らぬリポジトリを開いても直ちに任意コード実行が走ることはありません。

また、モデルへの指示は AGENTS.md としてプロジェクトルートに配置します。Claude Code の CLAUDE.md に相当するファイルで、AGENTS.md はプロジェクト固有のコンテキスト・命名規約・実行コマンドなどを書き込む用途に使います（Pi Docs Quickstart）。

Claude Code / Codex CLI / OpenCodeとの違い

Pi を採用すべきかは、ほかの主要 CLI ハーネスとの位置関係を見て初めて判断できます。ここでは公式情報ベースで確認できる差分を、4 つの軸で整理します。

設計哲学の比較

• Claude Code（anthropics/claude-code）: Anthropic 純正、Claude モデル専用、MCP ネイティブ、CLAUDE.md によるプロジェクト指示、ビルトインパーミッション UI と opinionated な UX
• Codex CLI（openai/codex）: OpenAI 純正、cloud sandbox + local の 2 モード、マルチモーダル入力対応
• OpenCode（sst/opencode）: model-agnostic な OSS、機能豊富な「機能セット」型
• Pi（earendil-works/pi）: 最小コア + Extensions / Skills / Prompt Templates / Themes による拡張前提設計

「盛り込み型」と「最小コア + 拡張型」という設計思想の違いは、日常的に触れるコマンド数やコンテキスト消費量に直結します。

拡張機構の比較

Pi が Extensions で狙っているのは「MCP よりコンテキスト効率が高く、フォーク不要で追加でき、Bash と合成可能」な拡張レイヤです。前掲の Zechner ブログの主張と合致します。

プロバイダとコスト構造の比較

Claude Code は Claude モデル専用のため、Anthropic Max サブスクリプションを持つユーザにはコスト効率が高い選択肢です。一方 Pi は 15+ プロバイダ対応で、OpenAI / Google / OSS モデルを主軸とするユーザには柔軟性で優位ですが、thoughts.jock.pl の 2026 年サーベイ が指摘するとおり、Anthropic Max サブスクリプションを third-party harness に持ち込めない都合で、Claude Max ユーザが Pi を経由すると実質「二重課金」になる問題があります。この点は Pi 側で解決できる範囲を超えており、コスト構造として認識しておく必要があります。

どのユーザがPiを選ぶべきか

以上を踏まえた Pi のスイートスポットは、公式情報とサードパーティ評価から次のように整理できます。

• Claude Max サブスクリプションに依存しない環境（GPT / Gemini / open-weight モデル / 自動化ユースケース）
• 社内ワークフローに合わせて harness を拡張したいが、フォークで本体を書き換えたくないユーザ
• RPC / SDK モードで CI/CD や社内スクリプトから coding agent を呼び出したいエンジニア
• MCP のトークン肥大に問題意識があり、Bash + 薄い Extension で完結させたいユーザ
• サプライチェーンハードニングを重視するチーム（後述）

逆に、Claude モデルへの依存度が高い・パーミッション UI が業務要件として必要・「箱を開けたらすぐ使える opinionated な体験」が欲しい、というユーザは Claude Code 側にとどまるほうが摩擦が少ない選択肢です。

Pi coding agentを本番導入する前に確認したい注意点

Pi は魅力的な設計思想を持つ一方、業務投入前に必ず理解しておくべき運用上のクセがあります。ここでは特に見落とされがちな 3 点を整理します。

Permission systemが無いことへの対策

Pi は README・公式ドキュメントで「起動ユーザ・プロセスの権限で動作する」ことを明示しています。公式ドキュメントには "Pi runs with all permissions by default, but in some cases, you will want to have more control over what directories Pi can write to and which accesses it has." と記載されており、パーミッション制御は containerization に委譲される設計です（Pi Docs Containerization）。

隔離が必要な場合は、公式が次の 3 パターンを提示しています。

パーミッション UI 相当の安全策を Pi 自体は提供しないため、業務環境では上記のいずれかを合わせて構成する前提で導入計画を組む必要があります。

Anthropic Maxサブスクリプションの二重課金問題

前掲の thoughts.jock.pl の 2026 年サーベイ は、Pi を「Coding tool + primitives harness」として肯定的に評価しつつも、Claude Max サブスクリプションを third-party harness に持ち込めない都合で二重課金になる点を Pi の主要な弱点として指摘しています。これは Pi 側の実装で解決できる問題ではなく、Anthropic のサブスクリプション設計に起因する制約です。

Claude Max を主軸にしているチームが Pi に乗り換える場合、API 従量課金への切り替えを含めたコスト再設計が必要になります。この観点は「乗り換えで得られる拡張性」と「増えるランニングコスト」のトレードオフとして事前に評価すべきポイントです。

サプライチェーンハードニングと運用制約

Pi は OSS の中でもサプライチェーンハードニングに積極的で、README に以下の運用が明記されています。

• 直接依存は exact version でピン留め、内部 workspace パッケージのみ range を許容
• .npmrc に save-exact=true と min-release-age=2（同日リリース依存を避ける）を設定
• package-lock.json を dependency ground truth とする pre-commit ガード
• 配布 CLI に npm-shrinkwrap.json を同梱し、transitive dep もピン
• CI は npm ci --ignore-scripts + npm audit signatures
• ライフサイクルスクリプトは明示 allowlist

セキュリティ観点では強い設計ですが、副作用として「lockfile の差分ガード」「新しい依存の追加審査」など、コントリビュートや社内フォーク運用時の手続きが増えます。前述のインストール例で --ignore-scripts が付いていたのも、この方針の延長です。導入前に、自社の依存管理ポリシーと擦り合わせておくと運用の摩擦を減らせます。

まとめ — Pi coding agent は誰のためのツールか

Pi coding agent は「MCP を持たない」「permission popup を持たない」「plan mode を持たない」ことを意図的に選んだ、最小コアと拡張性を軸にした TUI コーディングハーネスです。TypeScript Extensions と Skills、そして Bash を第一級のプリミティブに据えることで、フォーク不要でユーザが harness そのものを組み替えられる点が最大の特徴でした。

一方で、Anthropic Max サブスクリプションを併用しているユーザには二重課金問題、パーミッション UI が不要な代わりに containerization 3 パターンを組み合わせる運用設計、サプライチェーンハードニングによる依存管理の手続き増加、といった実運用上の注意点も明確に存在します。

以上を踏まえて、Pi を試すべきユーザ像をまとめると次のとおりです。

• 既存 coding agent CLI に慣れているが、独自ワークフローに合わせて harness を拡張したいエンジニア
• OpenAI / Google / OSS モデルを主軸にしたいユーザ
• RPC / SDK モードで CI/CD や社内自動化に coding agent を組み込みたい開発チーム
• MCP のトークン肥大に問題意識を持ち、Bash + 薄い Extension で完結させたいユーザ

逆に、Claude Max サブスクを最大活用したい・パーミッション UI や plan mode が業務要件として必要・opinionated な体験を優先したいユーザは、Claude Code 側にとどまるほうが自然な選択肢です。

まずは Pi 公式サイト と earendil-works/pi の README、そして 公式ドキュメント に目を通し、自分のユースケースが Pi の設計思想と噛み合うかを確認するところから始めるのが、失敗の少ない評価順序です。