概要

• pi-ai と pi-agent-core の開発背景と設計思想の解説
• 複数LLMプロバイダ対応の 統一API を実現するための課題と工夫
• コンテキスト管理 や ツール呼び出し の具体的な実装例
• TUI（ターミナルUI） や最小限のコーディングエージェントCLIの開発
• 商用製品との比較や、個人開発ならではのシンプルさの追求

2025年のコーディングエージェント進化と「pi」シリーズ開発記

• ここ3年間、 LLMを活用したコーディング支援 を模索
  • ChatGPTへのコピペから始まり、Copilot、Cursor、Claude Code、Codex、Amp、Droid、opencodeなどを試用
• Claude Code 初期バージョンの シンプルさ が好み
  • 機能追加で複雑化し、 ワークフロー崩壊やUIのちらつき に不満
• 独自エージェント（例：Sitegeist）も複数開発
  • コンテキスト設計の重要性 を痛感
• 既存ハーネスの ブラックボックス化 や セッション記録の不透明さ に課題
• 自分用に必要最小限 のコーディングエージェント「pi」シリーズを開発決意

pi-aiとpi-agent-coreの設計哲学

• pi-ai ：複数LLMプロバイダ対応の 統一API を実現
  • Anthropic, OpenAI, Google, xAI, Groq, Cerebras, OpenRouterなどをサポート
  • ストリーミング・ツール呼び出し・コスト管理 などに対応
• pi-agent-core ：ツール実行・バリデーション・イベントストリーミングを管理
• pi-tui ：最小限のターミナルUIフレームワーク
  • 差分レンダリング・ちらつきの少ない出力・エディタやMarkdown表示など
• pi-coding-agent ：CLIで一連の機能を統合
  • セッション管理・カスタムツール・テーマ・プロジェクトコンテキスト対応
• 「不要なものは作らない」 というミニマリズム重視

LLM API統一の現実と課題

• 実質 4種類のAPI で主要LLMプロバイダを網羅可能
  • OpenAI Completions/Responses, Anthropic Messages, Google Generative AI
• 各プロバイダの 細かな仕様差 に個別対応が必要
  • 例：max_tokensのパラメータ名やシステムプロンプト対応の違い
• テストスイート で多様な入力やツール呼び出しを網羅的に検証
• トークン管理・コスト計算 はプロバイダごとにバラバラで完全な精度は困難
• Googleは ツールコールのストリーミング未対応

コンテキストハンドオフの実装

• セッション中に 異なるLLMプロバイダへ切り替え可能
  • 例：Anthropic→OpenAI→Googleと順に切り替え
  • 各プロバイダの「思考トレース」や特殊イベントを ベストエフォートで変換
• シリアライズ/デシリアライズ によるセッション保存・再開
• クロスプロバイダでの一貫性維持 に苦労しつつも、実用レベルで動作

マルチモデル世界への対応

• モデル情報を TypeScript型 として管理
  • OpenRouterやmodels.devから情報を自動生成
  • 自己ホスト型モデルや新規プロバイダ も簡単に追加可能
• リクエスト中断（abort）や部分的結果取得 に最初から対応
  • 生産環境統合やUIフィードバックに必須

ツール出力の構造化分割

• ツール実行結果を LLM用（テキスト/JSON） と UI表示用 に分割
  • UIでの表示最適化が容易
• 画像などの添付ファイル にも対応
• バリデーションやエラー処理 も自動化

まとめ

• 既存コーディングエージェント の複雑化・ブラックボックス化へのアンチテーゼ
• 個人用途に最適化 したシンプル・拡張性重視の設計
• pi-aiシリーズ は「自分が欲しい機能だけ」を徹底追求
• 開発者体験・透明性・UI拡張性 のバランス重視

---

このように、「pi」シリーズは 複数LLMプロバイダの統一的活用 と 個人開発者向けのシンプルな体験 を両立するための独自アプローチを実現しています。