Pi Coding Agent：実務ワークフローのための柔軟なAIツール構築

はじめに

コードは決して無料ではありません。これは、Piの作成者であるMario Zechner氏が2026年のAI支援開発の現状について議論する際に掲げる中心的な主張です。エージェントは膨大な量のコードを迅速に生成できますが、そのコードがもたらす結果は最終的に開発者に降りかかります。Piが存在するのは、Zechner氏が既存のコーディングエージェントでは自身のワークフローに適合しないと感じ、適応させるのではなく、自分自身に適応するツールを構築したためです。

本稿では、なぜ機能の速度よりもワークフローの安定性が重要なのか、燃え尽きることなくコーディングエージェントとどのように連携すべきか、そしてなぜ業界が30年前の過ちである「仕様駆動開発」を繰り返している可能性があるのかについて解説します。

Piが存在する理由：安定性よりもワークフローの柔軟性を

Claude Codeが最初にリリースされたとき、Zechner氏は満足していました。しかし時間が経つにつれ、ツールの高頻度なリリースサイクルが問題となりました。Claude Codeは1日に1〜3回のアップデートが行われ、リリースごとにツール定義、システムプロンプト、基礎となる挙動が変更されます。カスタムプロンプトテンプレートやスラッシュコマンド、ワークフロー記述を構築している者にとって、こうした目に見えない変更は破壊的な影響をもたらします。

モデルのバージョンは同じであっても、モデル自体が日によって異なる挙動を示すように感じられました。Zechner氏はこれを、モデルの応答を形作るインフラやシステムプロンプトといった「ハーネス（harness）」の変更に起因するものだと考えています。ハーネスの変更が出力品質に与える影響をテストすることは、決定論的な測定方法が存在しないため困難です。その結果、Zechner氏のような開発者はツールの挙動を一貫して信頼できなくなり、その周囲にカスタムワークフローを構築するという目的が損なわれてしまいます。

Piはこのフラストレーションから生まれました。これは、ユーザーが制約に適応するのではなく、ワークフローに合わせて自らを修正できる、最小限で拡張性の高いコーディングエージェントです。基礎となるアーキテクチャはLLMプロバイダーを抽象化し、ターミナルユーザーインターフェースライブラリを含み、一般的なエージェントループの抽象化を提供します。しかし、決定的な違いは「制御」にあります。Zechner氏は設計を自ら決定し、ベンダーのリリースサイクルを待つことなく変更できるのです。

Piの実際の仕組み：並列処理と手動レビュー

Zechner氏のPiを用いた日常的なワークフローは、体系的かつ意図的にローテクなものです。彼はエージェントの軍団を並列で走らせることはしません。代わりに、トラッカーから異なるIssueを分析する複数のセッションをキューに入れ、それぞれをレビューして反復するという、原始的なアプローチをとっています。

バグ修正や機能実装の場合、プロセスはIssueの説明から始まります。Zechner氏は、「関連情報をすべて取得し、Issue内の分析は無視し、達成したい目標に基づいて独自の分析を行うこと」というカスタムプロンプトテンプレートを添えて、エージェントにIssueを渡します。この分析ステップにはIssueあたり約5分かかります。彼は次のIssueのために2つ目のセッションを開き、さらに3つ目を開くことで、並列の前処理パイプラインを作成します。

エージェントがIssueの分析を終えると、Zechner氏は提案をレビューし、自身でコードを確認し、必要に応じて手動で問題を再現します。彼はエージェントをラバーダック（思考のパートナー）として使い、実装アプローチに納得がいくまで対話を続けます。エージェントに実装を指示する頃には、コンテキストには十分なガードレールが含まれており、エージェントはどのインターフェースを修正し、どのモジュールに触れ、テストがどのように機能すべきかを正確に把握しています。

実装にはさらに10〜30分かかります。エージェントが完了を通知すると、Zechner氏はdiffビューアを開き、個々の行にフィードバックを注釈として追加します。彼が完了をクリックすると、フィードバックが自動的にエージェントに反映され、コードが良好になるまで反復が続きます。コアとなるメカニズムについては、人間相手のときと同様にすべての変更をレビューします。その他の部分については、詳細な検査なしで承認します。

このワークフローが機能するのは、Zechner氏がコードベースにおいて10年以上の経験を持っているからです。彼は何が機能し、何が機能しないかを知っています。経験の浅い開発者やその経験がない人にとっては、このアプローチは異なり、かつリスクを伴うものになるでしょう。

仕様駆動開発の現実

業界は30年前の過ちを繰り返しています。ウォーターフォール開発は何十年も前に非効率であることが証明されていましたが、AIエージェントの登場により、私たちは「ハイパー・ウォーターフォール」へと逆戻りしています。詳細な仕様を書き、エージェントに実装させるという手法です。唯一の違いは、今や仕様すら自分で書かず、エージェントに「バイブス（雰囲気）」でプロンプトを送り、非常に詳細な仕様を書かせ、それを別のエージェントが実装している点です。

問題は根本的です。完全な仕様書は、本質的にプログラムそのものです。自然言語の散文で仕様を書くと、必ず隙間が生まれます。エージェントはその隙間を、インターネット上の20年分のコードから学習したパターン（その多くはゴミのようなコードです）で埋めます。その結果、バイブスでコーディングされたようなコードベースが出来上がります。なぜなら、実際にそうだからです。

これに対する反論として、コードは今や安価であり、反復も高速であるという意見があります。以前はウォーターフォール型の仕様実装に数ヶ月かかっていたものが、今では1日で済むかもしれません。手動でテストを繰り返すことも可能です。しかし、Zechner氏はこれが本番環境のソフトウェアで実際に機能するという証拠をまだ見ていません。彼は、最終的に開発者がすべてが壊れていることに気づき、夜中に目を覚ますことになるのではないかと危惧しています。

とはいえ、エージェント駆動開発が理にかなっている制約条件も存在します。BunのZigからRustへの書き換えが成功したのは、プロジェクトに広範なテストスイートがあったからです。エージェントはある程度、自身の作業を検証できました。そのようなケースでは、こうしたツールは真に有用です。しかし、ほとんどのソフトウェアにとって、このアプローチはリスクが高いものです。

大規模なオープンソース管理：クランカー問題

エージェントが登場する前、成功しているオープンソースプロジェクトでも、プルリクエストは週に1〜2件程度でした。現在、Piには1日50〜60件のプルリクエストが届きます。すべてエージェント（Zechner氏はこれらを「クランカー」と呼んでいます）によるものです。各PRにはハリー・ポッターの本のような説明があり、10から1,000ものファイル変更が含まれています。

デフォルトの対応は、エージェントが生成したすべてのPRをゴミと見なして自動クローズすることです。しかし、Zechner氏は解決策を見つけました。まず、自分の言葉で、画面1枚分以内の長さで、何をしたいのか、なぜそうしたいのかを説明するIssueを書くよう求めることです。Issueの内容が良ければ承認し、その後にPRを送ってもらいます。これにより、相手が人間であり、問題を理解し、解決策を理解していることが証明されます。

承認されると、意味のあるPRが届くようになります。クランカーによるPRは姿を消します。Issueは依然として殺到しますが、Zechner氏は手動でトリアージを行います。彼は1日30〜60件のクローズされたIssueに目を通し、どれが正当でどれがゴミかを識別します。前回のトリアージでは、50件のIssueのうち2件だけが生き残りました。ほとんどがノイズであるとすぐに判断できるため、これにかかる時間は約30分です。

OpenClawのような規模のプロジェクトでは、この手動アプローチは機能しません。Peter Steinberger氏のトークン消費量は月間130万ドルに達しましたが、その一因は、その規模でIssueやPRのフィルタリングを自動化するには高度なインフラが必要だからです。Zechner氏は類似のIssueをクラスタリングする可視化ツールを書きましたが、それさえも十分ではありませんでした。ボリュームが桁違いに大きいのです。

ローカル推論と小型モデルの未来

Zechner氏は、コンシューマー向けハードウェアで高性能なAIモデルをローカルで実行することに楽観的です。コーディングエージェントを実行するスマートフォンをマイクロコントローラーとして使用するロボットプロジェクトでは、Gemma 4やQwen 3.6といった、より小さなMixture-of-Expertsモデルを使用しています。これらはモーターやカメラ制御を行うチャットボットには十分すぎるほどで、かつ高速です。

このセットアップは手頃な価格です。Parakeetによる音声認識には約10GBのユニファイドメモリが必要です。Qwen TTSによる音声合成にはさらに10GB。Qwen 3.6には4GB。合計で14GBのユニファイドメモリがmacOSや、Windows上の同等のNVIDIA環境で必要となります。これは世界中の全員とは言わないまでも、多くの人にとって手の届く範囲です。

DeepMindのDenise Asaves氏は、現在の巨大モデルはすべてのパラメータを必要とせず、出力品質を大きく損なうことなく、はるかに小さなモデルに蒸留できると示唆しています。Zechner氏の希望は、特定のタスクのために専門モデルをトレーニングするのではなく、大きなモデルを、ほとんどの能力を保持したまま小さなモデルに蒸留する未来が来ることです。RedisのAntirez氏は、DeepSeek V4用のカスタム推論エンジン「ds4」の開発を開始しており、128GBのノートPCで実行しています。これは非常に高性能なモデルであり、Zechner氏がPiで扱うIssueの60〜70パーセントを処理できる可能性があります。

コードのコストと技術の規律

Zechner氏は、エージェントを介して1週間で50万行のコードを生成する人々を見てきました。結果は常に同じで、悲惨なものです。コードは決して無料ではありません。なぜなら、その結果は最終的に自分に降りかかるからです。今、どれだけ多くのコードがあっても良いと考えているなら、あなたは単に報いを受けるのを先延ばしにしているだけです。

ソフトウェア開発における真のボトルネックは、タイピング速度やコード生成ではありません。思考し、設計し、ソリューション空間を探索することです。エージェントはそのフェーズでは真に有用です。複数のエージェントに異なるアプローチを探索させ、結果をより早く確認することができます。しかし、その探索結果は自動的に再利用可能なものではありません。それを理解し、リファクタリングし、維持する必要があります。

Zechner氏にとって、エージェントによる最大の生産性向上は、仕事の非同期性にあります。エージェントにタスクを与え、会議に行き、戻ってきたら結果が出ているという状態です。しかし、10個のエージェントを並列で走らせれば出力が10倍になるとは考えていません。コンテキストスイッチだけでも疲弊します。彼は月に1〜2回、1日で30のIssueを処理したことがありますが、その後は脳がヘトヘトになりました。

彼が最も価値を置いているのはコラボレーションの側面です。エージェントをペアプログラミングのパートナーとして、質問を投げかけ、選択肢を提案させ、コードを説明させることは、思考のための自転車のようなものです。一人で座っているよりも問題を深く考える助けになります。しかし、それには規律が必要です。すべてを機械に委ねてはいけません。そうするたびに、何もかもがうまくいかなくなり、すべてが崩壊して泣きを見る羽目になるからです。

Piのリファクタリング：未来のための構築

Piには歴史的な負債が蓄積しています。一部はZechner氏がエージェントを使い始める前のものですが、堅牢です。HTMLエクスポートのような他の部分は、彼自身一度も見たことがなく、レンダリングさえできればどうでもいいと考えています。一部はバイブスでコーディングされています。

リファクタリングにはいくつかの目標があります。第一に、既存の拡張機能を壊すことなく、Webやネイティブなど、他のユーザーインターフェースへ容易に展開すること。第二に、リモート機能の実現。1台のマシンでPiセッションを実行し、別のマシンから適切な耐久性と可観測性を持って接続すること。第三に、PiのSDKをbashが動くローカルコンピュータだけでなく、Cloudflare WorkersやVercelなどの環境にデプロイ可能にすることです。

Zechner氏は、伝統的な意味での安定性を重視していないため、メインブランチでリファクタリングを行っています。LLMプロバイダーと通信する最下層のパッケージから始めて、少しずつ進めています。コーディングエージェント自体はこれまでと同じように見え、動作しますが、基礎となるインフラはすべてクリーンで再利用可能なものになります。彼はこのフェーズを1〜2週間で終え、その後数週間かけて、サーバーサイドとUIサイドのコンポーネントを持つ新しい拡張メカニズムに取り組む予定です。

なぜPiはデフォルトでYOLOモードで実行されるのか

Piはコードを実行する前に許可を求めません。これは意図的なものです。YOLOモードは危険であり、自分で考えるべきだと伝えることで、Zechner氏は実際に人々にセキュリティについて考えさせています。彼はユーザー自身の中にセキュリティ意識を芽生えさせ、自身の環境でエージェントによる作業をどのように保護するかを決定してほしいと考えています。

その答えは通常、コンテナ化です。エージェントにコンピュータを壊されたくないのであれば、エージェントやそれが使用するツール（ファイルの読み書き、bashなど）をコンテナ化すればよいのです。それが問題を解決します。しかし、Zechner氏がユーザーの代わりにそれを決めることはできません。Anthropicのサンドボックスやbubble wrapをバンドルすることもできますが、これらは不完全な解決策です。特定のインフラ制約があるエンタープライズ環境では、組み込みのサンドボックスが全く機能しない可能性があるからです。

Claude Codeに存在するのは、ほとんどが「セキュリティの劇場（見せかけのセキュリティ）」です。Claude Codeは現在、自動モードでbashコマンドを実行する前に、そのコマンドが安全かどうかをLLMに尋ねます。Zechner氏はそれが良いとは考えていません。LLMはコマンドが安全かどうかを確実に判断することはできず、パターンに基づいて推測することしかできないからです。

結論

Piは異なる哲学を体現しています。開発者が所有し修正できるツールを構築することであり、開発者を所有するツールを構築することではありません。Piの成功は機能やベンチマークで測定されるのではなく、Zechner氏が小さなチームを維持し、コーディングからロボット工学、ローカル推論に至るまで、エージェントによる作業の応用を探求し続けられるかどうかで測られます。

より広範な教訓は、ワークフローは誇大広告よりも重要であるということです。安定性、予測可能性、そしてツールをカスタマイズできる能力は、最新の機能よりも価値があります。そして、コードは決して無料ではありません。あなたの行動の結果は、最終的にあなた自身に降りかかるのです。