AIコーディングエージェントといえば、最近は Codex や Claude Code がかなり強力です。
実際、
- コードを読む
- ファイルを編集する
- コマンドを実行する
- テストする
- Gitを操作する
- プロジェクト固有のルールを読み込む
といったことは、すでに普通にできます。
Claude Codeであれば CLAUDE.md、Codexでもプロジェクト固有の指示や設定を与えることで、かなり自分たちの環境に寄せることができます。
では、
CodexやClaude Codeがあるのに、なぜPi AgentのようなAgent Harnessが必要なのか？
という疑問が出てきます。
結論からいうと、
Pi Agentは「より賢いCoding Agent」ではなく、「自分たち専用のAgentを作るための基盤」だからです。
この記事では、その違いを実例ベースで整理します。
まず結論
かなり単純化すると、次の違いです。
Claude Code / Codex
↓
完成されたCoding Agentを使う
Pi Agent
↓
Coding Agentそのものを作る
普通に開発するだけなら、Claude CodeやCodexで十分です。
むしろ、その方が楽です。
一方で、
- Agentの動作フローそのものを制御したい
- 複数のLLMを使い分けたい
- 独自Toolを強く制限したい
- 社内システムにAgentを組み込みたい
- 自社独自のAI開発基盤を作りたい
という話になると、Pi AgentのようなAgent Harnessが効いてきます。
Agent Harnessとは何か
まず、Pi Agentを理解するうえで重要なのが、
Agent Harness
という考え方です。
普通のLLMは、ざっくり言うと次のように動きます。
ユーザー
↓
プロンプト
↓
LLM
↓
回答
Coding Agentでは、ここにTool実行が加わります。
ユーザー
↓
LLM
↓
Tool Calling
↓
read / write / edit / bash
↓
実行結果
↓
LLM
↓
次の処理
つまり、
考える
↓
ファイルを読む
↓
修正する
↓
コマンドを実行する
↓
結果を見る
↓
さらに修正する
というループを回します。
この、
- LLMを呼び出す
- Toolを実行する
- 状態を管理する
- Contextを管理する
- Agent Loopを回す
といった部分を担当するのがAgent Harnessです。
Claude CodeやCodexにも当然この仕組みがあります。
違いは、
そのHarnessを誰が管理しているか
です。
Claude CodeでもCLAUDE.mdでカスタマイズできる
ここは非常に重要です。
「Piなら自社ルールを書ける」という説明だけでは、Piを使う理由にはなりません。
Claude Codeでも CLAUDE.md に、
# Coding Rules
- ControllerにValidationを書かない
- LaravelではFormRequestを使う
- 本番DBではALTER TABLEを実行しない
- 修正後はphp artisan testを実行する
- phpstanとpintも確認する
と書けます。
さらに、
- Skills
- Hooks
- Subagents
- MCP
- Permissions
などを組み合わせれば、かなり高度なカスタマイズができます。
そのため、
自社ルールを覚えさせたい
程度であれば、わざわざPi Agentを導入する必要性は高くありません。
ここはかなり重要なポイントです。
Pi Agentの違いは「Agent自体をプログラムできる」こと
Claude Codeでは、基本的に、
Claude Code
├── Agent Loop
├── Context管理
├── Tool実行
├── Permission
├── Subagent
└── その他の内部処理
という完成されたAgentの上で、
CLAUDE.md
Skills
Hooks
MCP
を使ってカスタマイズします。
一方、Pi Agentの場合は、
Agent Runtime
↓
自分でAgentを構成する
という思想に近くなります。
つまり、
Claude Code
=
Agentを設定する
のに対して、
Pi Agent
=
Agentを実装する
という違いです。
実例1：DB操作を確実に制限したい
例えば、本番DBをAIに調査させたいとします。
ただし、次の制約があります。
許可
- SELECT
- SHOW
- EXPLAIN
禁止
- INSERT
- UPDATE
- DELETE
- ALTER
- DROP
Claude Codeでも、CLAUDE.md に、
本番DBではUPDATE、DELETE、ALTER、DROPを実行しないこと
と書けます。
さらにHooksや権限管理を組み合わせることで、かなり安全にできます。
ただ、Pi Agentならさらに下のレイヤーで、
LLM
↓
Production DB Tool
↓
SQL Parser
↓
許可されたSQLだけ実行
というTool自体を作れます。
例えば概念的には、
if (!["SELECT", "SHOW", "EXPLAIN"].includes(command)) {
throw new Error("Production DBでは実行できません");
}
とします。
すると、
SELECT
→ OK
EXPLAIN
→ OK
UPDATE
→ Tool側で拒否
DROP
→ Tool側で拒否
となります。
ここで重要なのは、
AIに「やるな」とお願いしているのではなく、そもそも実行できない
という点です。
企業システムでは、この差はかなり大きいです。
実例2：障害調査フローをAgent化する
例えばユーザーから、
サイトが重いので調査して
と依頼されたとします。
通常のCoding Agentなら、
nginxを確認
↓
PHP-FPMを確認
↓
DBを確認
とAIが判断して進めます。
しかし実際の運用では、調査フローが決まっていることがあります。
例えば、
1. nginx access.log
2. nginx error.log
3. PHP-FPM slowlog
4. CPU / Memory
5. Disk I/O
6. MariaDB PROCESSLIST
7. slow.log
8. replication delay
9. AWS CloudWatch
10. 原因候補をまとめる
というRunbookがあるとします。
Pi Agentなら、このRunbook自体をプログラムできます。
Incident Agent
│
├─ Nginx Agent
│
├─ PHP Agent
│
├─ Database Agent
│
└─ AWS Agent
↓
Review Agent
↓
Incident Report
ユーザーは、
サイトが重い
と入力するだけ。
内部では、
CPU正常
↓
nginx正常
↓
PHP-FPM正常
↓
DBでLOCK WAIT検出
↓
slow query特定
↓
原因候補作成
と決められたフローで動きます。
これは単なるCoding Agentというより、
Runbookを実行するAIシステム
です。
実例3：複数のAIモデルを使い分けたい
Claude Codeの場合、基本的にはClaudeが中心です。
CodexならOpenAIモデルが中心になります。
一方、自社Agentでは、
設計
→ Claude
実装
→ GPT
大量ログ解析
→ Gemini
社内機密処理
→ Local LLM
のように使い分けたい場合があります。
イメージとしては、
Main Agent
│
┌─────────────┼─────────────┐
↓ ↓ ↓
Claude GPT Gemini
設計担当 実装担当 ログ解析
Pi AgentのようにHarnessを自分で持っていれば、
モデルとAgent Runtimeを分離できます。
つまり、
自社Agent
│
├─ Claude
├─ GPT
├─ Gemini
└─ Local LLM
という構成にできます。
これは「どのモデルが一番強いか」という話ではありません。
タスクによって最適なモデルを選択する
という設計ができます。
実例4：専門Agentを組み合わせる
例えばLaravelの新機能を実装するとします。
依頼は、
口コミ機能を追加して
だけです。
普通のAgentなら、1つのAgentが、
設計
DB設計
実装
Security
テスト
まで担当します。
Pi Agentなら役割を分けることができます。
Main Agent
│
┌───────────────┼───────────────┐
↓ ↓ ↓
Laravel Agent Database Agent Security Agent
│ │ │
API設計 schema設計 認可
Controller index CSRF
Service EXPLAIN XSS
│ │ │
└───────────────┼───────────────┘
↓
Review Agent
例えばDatabase Agentには、
- MariaDBの設計のみ担当
- EXPLAINを必ず確認
- index候補を提示
- Production DDLは禁止
というルールを持たせます。
Security Agentには、
- Auth
- Authorization
- CSRF
- XSS
- SQL Injection
だけを重点的にチェックさせます。
最後にReview Agentが、
Laravel Agent
Database Agent
Security Agent
の結果を統合します。
これは、
AIを開発組織のように構成する
という考え方です。
実例5：社内システムにAIを組み込みたい
ここがPi AgentのようなHarnessを使う、かなり大きな理由です。
Claude Codeは基本的に、
Developer
↓
Claude Code
↓
Repository
という開発者向けツールです。
一方で、自社管理画面に、
障害調査開始
というボタンを作りたいとします。
例えば、
----------------------------
障害調査
対象:
www.example.com
[ 調査開始 ]
----------------------------
ボタンを押すと、
nginx確認
↓
PHP-FPM確認
↓
MariaDB確認
↓
AWS確認
↓
AIによる原因分析
を実行します。
結果を、
CPU
正常
Memory
正常
nginx
異常なし
MariaDB
LOCK WAITを検出
原因候補
m_staffをJOINしているSQL
改善候補
INDEX追加を検討
のように社内画面に表示する。
こうなると、Claude Codeを使うというより、
Agent自体を自社システムの機能として実装する
という話になります。
Pi Agentが得意なのはこの領域です。
ではClaude CodeやCodexではできないのか？
ここは誤解しやすいところです。
答えは、
かなりのことができます。
Claude Codeには、
- CLAUDE.md
- Hooks
- Skills
- Subagents
- MCP
- Permissions
などがあります。
Codexもプロジェクト固有の設定やToolを利用できます。
そのため、
Claude Codeではできない
↓
だからPiを使う
という話ではありません。
むしろ、
Claude Codeでもできる
ケースはかなり多いです。
違いは、
どこまでを自分たちの責任範囲にしたいか
です。
比較するとこうなる
| 項目 | Claude Code / Codex | Pi Agent |
|---|---|---|
| すぐ使える | ◎ | △ |
| コード修正 | ◎ | ◎ |
| Shell実行 | ◎ | ◎ |
| プロジェクトルール | ◎ | ◎ |
| Skills | ◎ | ◎ |
| Subagent | ◎ | ○〜◎ |
| Agent Runtimeの改造 | △ | ◎ |
| Toolそのものの設計 | ○ | ◎ |
| 独自Workflow | ○ | ◎ |
| 複数LLM | △ | ◎ |
| 自社システムへの組込み | △ | ◎ |
| Agent製品の開発 | △ | ◎ |
| メンテナンスコスト | 低 | 高 |
Pi Agentを使わない方がいいケース
正直、かなり多いです。
例えば、
Laravelのバグを直したい
Reactのコードを書きたい
SQLを最適化したい
Dockerfileを修正したい
Terraformを書きたい
という用途であれば、
Claude CodeやCodexを使った方が簡単です。
Pi Agentを使うと、
Agent Loop
Tool設計
LLM Provider
権限制御
Context管理
Logging
Error Handling
Observability
などを自分たちで考える必要が出てきます。
つまり、
自由度の代わりに保守コストを引き受ける
ことになります。
Pi Agentが必要になる境界
では、どのタイミングでPi Agentが候補になるのか。
個人的には、次のような状況です。
毎回AIに同じ手順を指示している
例えば、
1. Issueを確認
2. branchを作成
3. Laravelを修正
4. Migration確認
5. Test
6. PHPStan
7. Pint
8. Security Check
9. Review
10. Pull Request作成
を毎回やっている。
これなら、
/implement ISSUE-1234
だけで全部動くAgentを作る価値があります。
また、
Claude Codeを使う人によって品質が違う
という問題にも対応できます。
人によって、
Aさん
「テストまでお願いします」
Bさん
「Securityも確認してください」
Cさん
「Migrationのrollbackも確認してください」
となるところを、
Company Agent
として標準化する。
すると、
誰が使っても
設計
↓
実装
↓
Test
↓
Security
↓
Review
という流れになります。
一番分かりやすい例え
Claude CodeやCodexは、
優秀な外部エンジニア
に近いです。
あなた
↓
「この機能を作って」
↓
AI
↓
実装
非常に優秀です。
一方、Pi Agentは、
AIエンジニアを作るためのフレームワーク
に近いです。
自社ルール
+
業務フロー
+
権限制御
+
Tool
+
複数LLM
+
専門Agent
を組み合わせます。
さらにWeb開発で例えるなら、
Claude Code / Codex
=
完成されたSaaS
に対して、
Pi Agent
=
Agent開発用Framework
です。
CLAUDE.mdとPi Agentの違い
この比較も分かりやすいと思います。
CLAUDE.md は、
Claude Codeを
自分たちの環境に合わせる
ためのものです。
一方、Pi Agentは、
自分たちのAgentを作る
ためのものです。
かなり乱暴に言えば、
CLAUDE.md
=
Claude Codeを自社向けに教育する
のに対して、
Pi Agent
=
自社版Claude Codeを作る
という違いです。
まとめ
CodexやClaude Codeがある現在、
単純にAIコーディングをしたいだけなら、Pi Agentは必要ありません。
Claude CodeやCodexはすでに十分強力です。
Pi Agentが必要になるのは、
AIにコードを書いてもらいたい
から、
AIを使った開発システムそのものを作りたい
に目的が変わったときです。
整理すると、
Codex / Claude Code
「AI Agentを使う」
に対して、
Pi Agent
「AI Agentを作る」
という違いがあります。
Agent Harnessを自分で持つことで、
- 独自Tool
- 独自権限制御
- 独自Workflow
- 複数Agent
- 複数LLM
- 社内システムへの組込み
まで自由に設計できます。
その代わり、
- 開発
- 保守
- セキュリティ
- Context管理
- Tool管理
も自分たちの責任になります。
そのため、
Claude CodeよりPi Agentの方が優れている
という話ではありません。
用途が違います。
最終的には、
Coding Agentを使いたい
→ Claude Code / Codex
Coding Agentを作りたい
→ Pi Agent
くらいで考えると、かなり分かりやすいと思います。
個人的には、Pi Agentの価値は「AIの性能」ではなく、
Agentの働き方そのものをソフトウェアとして設計できること
にあると思います。