エンタープライズの基幹システムや業務アプリケーションを保守している開発チームにとって、プルリクエスト（コードの変更内容をレビューしてもらうための提案単位、以下PR）のレビュー待ちは昔からの悩みの種です。コーディングエージェント（コード生成から実行・修正までを自律的にこなすAIツール）がコードを書く時間よりレビュー待ちの時間のほうが長い、という逆転現象が起きているチームもあるのではないでしょうか。
今回扱うのは、AIコーディングツールを開発するAmp社が実践している「トランクベース開発」という手法です。PRを介さず、エンジニアもエージェントも直接メインブランチにコードを push（反映）する運用で、それでもSOC 2（米国の情報セキュリティ監査基準）の認証を取得しています。基幹システムや金融・医療系の業務システムでレビュープロセスの重さに悩んでいる方に、判断材料を整理しました。
トランクベース開発とは何か、何が変わったのか
トランクベース開発は、全員が1つの共有ブランチ（trunk、多くのGitリポジトリではmainブランチ）に、1日1回以上の頻度で小さな変更を統合していく開発モデルです。長期間残る機能ブランチを作らず、変更をこまめに本流に合流させる点が特徴です。
従来のトランクベース開発では、数時間だけ生きる短命ブランチを作り、簡単なレビューを経てmainに取り込む運用が一般的でした。最も純粋な形では、ブランチすら作らずmainに直接commitし、CI（コードのビルドとテストを自動実行する仕組み）が壊れた変更を検知する運用になります。
コーディングエージェントは、この運用をさらに極端な形に押し進めます。エージェントが1セッションでコードを書き、テストし、デプロイまで終えられるなら、人間の承認を1日待つPRは、着想から本番反映までの間で最も遅いボトルネックになります。CI活用やテスト自動化の著書を持つPaul Duvall氏は、ポッドキャスト「The Agentic Review」で「誰かのレビューを待つというPRの仕組み自体が、ずっと問題だった」と述べています。コーディングエージェントがPRの待ち行列を生んだわけではなく、無視できないほど長くしただけだ、という指摘です。
Ampの事例、SOC 2を満たす4つの統制
Ampはコーディングエージェント製品を、自社のエージェントを使って開発しています。同社のWill Dollman氏は社内ノート「That's not SOC 2 compliant」で、PRを使わない運用は「最初のコミットから意図的な選択だった」と説明しています。
SOC 2監査が始まった際、監査人はPRの代わりに何があるのかを問いました。Dollman氏の要約は明快です。「SOC 2はPRを要求していない。リスクについて考えることを要求している」。SOC 2が依拠するTrust Services Criteria（信頼性の評価基準）は、変更が「authorized（認可され）、tested（テストされ）、approved（承認され）、recorded（記録される）」ことを求めており、Ampはこの4要素それぞれに対応する統制を用意しました。
具体的には次の4つです。
- 制限付きpush権限: mainへのpush権限を業務上の役割に応じて付与し、誰がいつ変更できるかを明確にする
- 署名付きcommit: GitHubでmainへの検証済み署名を強制し、commitの作成者を保証する
- 自動CI: すべての変更に対してテスト・インフラ検査・セキュリティ検査を実行し、「問題のある変更はmainをブロックする」
- 監査証跡: commitをそのコードを書いたAmpのエージェントスレッド（対話履歴）に紐づけ、commitからデプロイまでの経路をCI/CDに記録する
ただしDollman氏自身、この統制リストに「コードレビューは含まれていない」と明言しています。Hacker Newsのスレッドでは「レビューの証拠なしにどうやって承認を証明するのか」という技術的な疑問が上がり、Amp側のエンジニアは「commitを読んで、お互いに話すだけだ」と回答しています。
Ampの創業に関わるQuinn Slack氏は、2026年10月のカンファレンスで「Ampはコードレビューを一度もしたことがない」「エージェントスレッドが実質的にPRの代わりになる」と発言しています。他のチームへの助言としては、まずPRの20%でレビューを省略し、リスクスコアリング（変更のリスクを点数化して優先度を判断する手法）から始めることを挙げています。
業務システム開発での比較と、レビューはどこに消えたのか
ThoughtworksのCTOであるRachel Laycock氏は、別の角度から同じ問題を扱っています。すべての変更を検査するのではなく、判断の基準を早い段階に組み込み、例外時だけレビューする「review by exception」の考え方です。
これは業務システム開発の文脈で馴染みのある発想と重なります。日本の金融・社会インフラ系の開発現場では、変更管理プロセスとして「影響度の低い変更は簡略承認、影響度の高い変更は多段階承認」という段階的な統制が以前から使われています。トランクベース開発とコーディングエージェントの組み合わせは、この考え方をコード変更そのものに適用した形といえます。
整理すると、レビューは消えたのではなく、5つの場所に分散しています。pushする前のエージェントの自己検証、CIというゲート、エージェントスレッドへのトレース、デプロイ後のロールアウト監視、そして基幹部分（load-bearing code、システムを支える重要なコード）を持つ担当者によるオーナーシップです。
| 統制の観点 | 従来のPRレビュー | Amp型のトランクベース運用 |
|---|---|---|
| 承認の証拠 | 人間の承認コメント | CI通過とcommit署名 |
| 変更の妥当性確認 | レビュアーの目視 | テスト・静的解析・エージェントの自己検証 |
| 経緯の追跡 | PRのコメント履歴 | エージェントスレッドとの紐づけ |
| 問題発生時の対応 | マージ前に差し戻し | デプロイ後のロールアウト監視と修正 |
AI向けのコードレビューツールを提供するQodoのような製品は、この「push前の自己検証」の部分に人間相当のレビューを組み込むアプローチを取っています。エージェントのローカルな変更をmainと比較し、PRで使うのと同じレビューエンジンでチェックしたうえで、チーム独自のコーディング規約をエージェントに事前に渡す仕組みです。トランクベース開発を採用してもレビュー工程自体をゼロにするのではなく、人間からエージェントの前段に移す選択肢として参考になります。
今日から確認できること
この運用を自社の業務システムに取り入れるかどうかは、SOC 2やISMSなど準拠が必要な基準の要求事項を、PRという手段ではなく目的に分解して読み直すところから始まります。
具体的には、社内のセキュリティ基準や監査要件のドキュメントを開き、「コードレビューを実施すること」という条文が本当にあるのか、それとも「変更が認可・テスト・承認・記録されていること」という目的ベースの記述なのかを確認してください。後者であれば、PR以外の統制で満たせる余地があります。
CI環境についても、現状のパイプラインが「壊れた変更をブロックする」レベルまで到達しているかを点検する価値があります。テストカバレッジ、静的解析、セキュリティスキャンのうち、どれが必須ゲートになっていてどれが任意実行かを洗い出すのが第一歩です。
コーディングエージェントを導入しているなら、エージェントが生成したcommitとその対話履歴（プロンプトやスレッド）を紐づけて記録できているかも確認ポイントです。紐づけができていなければ、障害発生時に「なぜこの変更が入ったか」を追跡する手段がなくなります。
まとめ
トランクベース開発とコーディングエージェントの組み合わせは、レビューをなくす話ではなく、レビューの実施場所を変える話として捉えるのが実態に近いといえます。
基幹システムや業務システムを抱えるチームであれば、まず自社の準拠基準がPRという「手段」を要求しているのか、認可・テスト・承認・記録という「目的」を要求しているのかを読み直すところから始められます。
その上で、push前のエージェント自己検証、CIゲートの厳格さ、変更とエージェントスレッドの紐づけ、デプロイ後の監視体制、重要コードのオーナーシップという5つの観点それぞれで、現状どこまでカバーできているかを棚卸ししてみてください。すべてをいきなり無人化するのではなく、リスクの低い変更から段階的にレビュー省略を試す、というAmp側の助言も現実的な出発点になります。