AIエージェント時代のPR中心開発を見直す運用設計

なぜPR中心の流れが詰まり始めたのか

GitHub中心の開発は、ブランチ作成、PR、CI、レビュー、マージの順で進む。LLMエージェントもこの流れに組み込まれ、コード作成からCI実行まで担えるようになった。だが、短い指示から機能全体を作れるなら、人間のレビュー待ちが新たな待ち行列になり得る。

詰まるのは実装だけではない。GitHub、CI、レビュー、セキュリティスキャン、デプロイが直列につながる。営業、サポート、マーケティングまでコードに関わる場面では、すべての変更を同じPR手順に流す設計がチームの処理能力を削る。GitHub is the wrong shape for this new worldは、その前提を問い直している。

隔離環境で判定根拠をそろえる

PRを廃止する必要はない。PRはすべての作業の受付ではなく、統合判断を残す場へ戻せばよい。エージェントにはタスクごとの隔離環境で、指定したリポジトリ状態、依存関係、権限だけを渡す。

見るべき対象はコミット差分だけではない。隔離環境でテストした成果物、実行ログ、変更理由をそろえれば、レビュー担当者は手元で再現する作業を省ける。人が確認すべきなのは、何が変わったかだけでなく、どの条件で安全と判定したかである。

委任は「検証」と「取り消し」で分ける

自律性を一律に上げるのは危険だ。PostHogはタスクを検証のしやすさと取り消しやすさで分け、ユニットテストや統合テストのような決定論的チェックを即時フィードバックに使う。拒否リストのキーワードを含むPRは、承認エージェント「StampHog」が人間へ回す。How much can you delegate to agents?

小規模チームなら、コメント追加、文字列の列挙型への置換、SDKへの展開など、テストで結果を確かめやすい変更から自動化する。権限変更、データ移行、コアロジックの置換は、人間が設計を握る。変更はドライランを既定にし、認証情報の範囲を絞り、フィーチャーフラグの背後に置く。

人間の承認を残す場所を絞る

実行環境ごとに「自動マージ可」「承認必須」「実行禁止」をポリシーとして定義する。自動マージ可には、隔離環境でのテスト成功、変更範囲の上限、ロールバックできる成果物を条件に置く。外部公開、権限、データ構造、課金に触れる変更は承認必須にする。

RustでSQLパーサーを書き直したPostHogの事例では、本番のシャドーモードと段階的な切り替えで安全を確認した。大きな変更ほど、PR上の一回の承認に賭けず、本番へ届く前後に検証地点を増やす設計が合う。

まとめ

AI駆動開発では、PR数を増やすより、タスクを隔離し、成果物・検証結果・ロールバック手段を渡す運用へ切り替えたい。次の自動化候補は、「テストで正否を決められるか」「失敗しても戻せるか」で選ぶ。この2点を満たさない変更は、人間の判断を残すべきだ。