Cursor pstackで月2500件のPRを完遂！AI自動開発の実践基盤

• 事実：Cursor等を活用し月2,500件のPR生成・マージを実現するAI開発基盤「pstack」の手法が公開された。
• 技術：Playbook・Principle・Skillの役割分離とコンテキスト動的読み込みによりLLMのハルシネーションを防止。
• 影響：単なるコード自動生成から「自動検証・TDD主導のガードレール構築」へ開発者の役割シフトが不可欠となる。

深夜の障害対応で、AIが吐き出した一見完璧に見えるコードを鵜呑みにしてデプロイし、本番環境のデータベースをデッドロックさせた苦い記憶はないだろうか。近年のClaude 3.5 SonnetやCursorなどの圧倒的なコード生成性能に歓喜する一方で、我々現場のシニアエンジニアが日々直面しているのは、「大量に生成されるが、どこか抜け落ちのあるコードのレビュー地獄」という生々しい課題だ。AIエージェントが数分で書いてくる数百行のコードに対して、人間が1時間かけて差分を追いかけ、潜在的なバグを探し回る――これでは開発体験の向上どころか、レビュー負担の肥大化によって開発プロセス全体が不全に陥ってしまう。

こうした現場の悲鳴に対する決定的な解となるのが、Webエンジニアのkaito氏によって提唱された「pstack」の思想である。ソース記事で明かされた「月2,500件のPull Request（PR）」という桁外れの数値は、AIの生成スピードを自慢するための無意味な指標（ヴァニティ・メトリクス）ではない。エージェントを自律的に走らせた結果として自然に積み上がった「環境の副産物」に過ぎないのだ。そして、この膨大なPR数を支える根本的な哲学こそが、「信頼するのは、エージェントではなく成果物である」という強烈な人間不信――ならぬ「AIエージェント不信」の徹底である。

多くの開発チームが犯す最大の過ちは、LLMのプロンプトエンジニアリングを工夫して「最初から100点満点のコードを出力させよう」と試みることだ。しかし、確率論で動作する大規模言語モデル（LLM）に対して完全性を求めること自体が筋違いである。pstackが提示するのは、AIエージェントがどのようなコードを書いてこようと、それを機械的にかつ再現可能な形で評価・検証し、振る舞いの正しさを担保する「実行可能なガードレール」をリポジトリ内に構築するというアプローチだ。エージェントの頭脳ではなく、テストスイートと自動検証環境という物理的な事実のみを信用する。この割り切りこそが、自律型AIエージェント時代における開発基盤構築の真の出発点だと私は強く確信している。

AIエージェント（特にCursorやGrok Botなど）に長時間の複雑なタスクを委任した際、コンテキストウィンドウが過去の試行錯誤や無駄なファイル読み込みで溢れ返り、最終的に前言撤回や無限ループに陥る現象を誰しも経験したことがあるはずだ。スパゲッティ化されたプロンプトと膨大なコードベースの挟み撃ちにより、AIのIQは急激に低下する。pstackはこの「コンテキストの爆発」を阻止するために、役割を明確に分担したモジュール設計を採用している。

具体的には、タスクの進め方を定義する「Playbook」、思考と意思決定の基準を与える「Principle」、そして特定の作業を実行・評価する具象能力である「Skill」の3つに構造化されている。さらに、リクエストの入口として「/poteto-mode」と呼ばれるRouterが機能し、依頼内容に応じて必要なコンテキストだけを動的に選択してLLMの記憶に読み込ませる仕組みを持つ。システム全体の構成要素とその役割は以下の通りだ。

我々エンジニアがマイクロサービスやモジュール化で依存関係を密結合から疎結合へと整理するように、LLMに与える指示体系もまた「疎結合」でなければならない。pstackは、コンテキスト全体を常にプロンプトに突っ込むような野蛮なアプローチを捨て、必要な時に必要なモジュールだけをオンデマンドで注入する設計を徹底している。これによって、長時間におよぶ複雑なリファクタリングや機能追加であっても、AIエージェントがコンテキストの渦に溺れることなく、最後まで再現性高くタスクを完遂することが可能になるのだ。

いくらフレームワークが整っていても、AIエージェントが自由にコードを改変すれば、既存の境界やアーキテクチャは一瞬で崩壊する。特にTypeScriptを用いたWeb開発において、型定義を`any`で逃げたり、不必要なコメントを大量に残したり、責務の境界を無視してモジュール間の依存関係をぐちゃぐちゃにするような「AI特有の雑な改変」は日常茶飯事だ。pstackはこの課題に対し、厳格な「23の原則（Principle）」と「TDD（テスト駆動開発）」の融合という極めて決定論的な解決策を叩きつけている。

pstackのPrincipleは、Core（作業の進め方10原則）、Architecture（境界と依存の設計6原則）、Verification（挙動検証4原則）、Delegation（委任と並列化2原則）、Meta（仕組み自体の改善原則）という合計23の原則で構成されている。これらは抽象的な理念ではなく、「変更が壊しうる領域を事前に特定せよ」「実際の挙動で確かめよ」といった、AIの暴走を抑え込むための具体的な行動規範だ。さらに、TypeScriptの16のコード品質規則をSkillとして定義することで、スタイルや型安全性を自動的に判定させる仕組みを組み込んでいる。

そして最も評価すべきは、修正作業において「【TDD】修正前に失敗するテストで確かめる」プロセスを徹底させている点だ。AIエージェントにコードを直させる前に、まず「現在のバグを再現し、確実に失敗するテストコード」を書かせる。そのテストが赤（失敗）になることを実環境で確認して初めて、AIに本体コードの修正を許可するのだ。テストが緑（成功）に変わった瞬間にのみ、そのPRは「検証済み」として人間または自動マージのラインに乗る。

これはまさに、確率論的に動作する不確実なAI（LLM）の出力を、決定論的である単体テスト・結合テストという「物理法則」で包み込む高度なサイバネティクス（制御工学）のパターンに他ならない。README with Grill 駆動開発（RGDD）といったユニークな検証手法を含め、思考のプロセスとその客観的証拠（エビデンス）をリポジトリ内に残し続けるアプローチこそが、月2,500件ものPRを品質を落とさずに処理できる理由なのだ。

pstackが描く未来のソフトウェア開発像は、我々エンジニアに対して非常に重く、本質的な問いを投げかけている。AIがコードを書き、AIが並列で複数の設計案を提示し、AIがPRを作成する世界において、人間である我々の役割とは一体何なのだろうか？ 単にAIが生成したコードの誤りを指摘する「下請けレビュアー」に甘んじるのか、それともエージェントが正しく自律駆動するための「検証基盤（ハーネス）のアーキテクト」へ進化するのか、その踏み絵が今まさに突きつけられている。

もしあなたが自社の現場でAIエージェントの導入に苦戦しているなら、明日から取るべき実践的な処方箋は明確だ。まずはAIにコードを書かせることを諦め、「自分のアプリケーションを自動で起動し、挙動を検証するスキル（Skill）」をスクリプト化することから始めるべきである。自動化されたテストスイート、再現可能なE2E環境、厳格な型チェックとリント。これらの「検証の土台」が存在しないリポジトリにいくらCursorやClaudeを投入したところで、吐き出されるのは技術負債の山でしかない。

「コードを書く時間」がゼロに近づいていく時代において、ソフトウェアエンジニアの真の価値は、コードそのものではなく「何が正しい振る舞いであるか」を厳密に定義し、それをAIが検証できる形に落とし込む設計力へとシフトしている。pstackが示したアプローチは、単なるツールキットの紹介にとどまらない。AIエージェントと人間が真の対等性をもってプロダクトを作り上げるための、新時代の「ソフトウェア工学の原典」として機能していくはずだ。我々はこの波に乗り、自らの開発基盤を再構築する準備ができているだろうか？