はじめに

こんにちは！Acsim 開発チームの笹沢です。

AI 駆動開発の浸透でコードの生産量は飛躍的に増えました。一方、人間がレビューに割ける時間は変わらないため、レビュー待ちで PR がスタックする場面が以前より増えていきました。

私たちのチームでは「人間のレビューを必須とするもの」と「AI レビューで OK とするもの」を線引きし、セルフマージ制度として日々の開発に組み込みました。直近では PR の 約 8 割が人間レビューを介さずにマージできています。マージまでのリードタイムも短縮されています。

この記事では、セルフマージ制度の設計と運用上の工夫、導入後の変化を紹介します。AI レビューが十分使えるレベルになった今、自チームのレビュー運用を見直したい方の参考になれば嬉しいです。

すべての PR に人間レビューは必要か

最近の AI レビューはコード品質の担保という意味では十分使えるレベルにあります。ビジネス観点やそもそも論への弱さはあるものの、ロジックや実装の細かいチェックは AI に任せて問題ないと感じる場面が増えてきました。

それでもチームでは「最低 1 人から Approve をもらう」というルールを長く運用していました。結果として、数時間待った末に nits1 レベルのコメントを受け、修正してまた再依頼する、という効率の悪い時間の使い方が多々ありました。すぐレビューをするように努力しても、このリードタイムを短くするには限界があります。

そもそも、すべての PR で人間レビューを必須にする必要があるのでしょうか。人間にしか持ち得ないコンテキストやドメイン知識を要する判断、たとえばコアの設計や手戻りの大きい意思決定では、人間のレビューに大きな価値があります。一方で、簡単にやり直しが効く判断であれば、人間をボトルネックにせずスピード感を持ってリリースし、早く価値検証に回した方が得策です（特に我々のようなスタートアップにとっては）。

One-Way Door / Two-Way Door という考え方

この「やり直しが効くかどうか」を、Acsim では One-Way Door / Two-Way Door という言葉で扱っています。Amazon の創業者 Jeff Bezos が株主への手紙で示した意思決定の分類で2、戻れない決定（One-Way Door）は慎重に、戻れる決定（Two-Way Door）は速く、というシンプルな指針です。

たとえば、やり直しが効かない代表例はデータベース設計です。やり直すにはスキーママイグレーションが必要で、データマイグレーションの段取りやオンライン適用の検証など工数がかかります。一方で、フロントエンドの UI 変更、API スキーマの改修などは、少ない工数で方針を変えられます。アプリケーション横断的なアーキテクチャやプロダクトの深い部分まで組み込まれているライブラリ選定を除けば、ほとんどの設計判断は後戻りできるのです。

ここまで考えると、PR の大半は実は Two-Way Door であり、人間レビューを必須にしている合理的な理由はないのではないか、という仮説に行き着きます。実際に運用してみないと答え合わせはできないので、次章ではこの仮説を仕組みに落とし込んだ施策を紹介します。

セルフマージを仕組みに落とし込む

セルフマージガイドラインの策定

One-Way か Two-Way かの判断軸を形式知とするために「セルフマージガイドライン」を策定しました。判定の軸は一行で済みます。

セルフマージしてよいかは 「その変更は容易にやり直せるか」 で決まる。

とはいえ、この一行だけだと現場で迷うケースが多いので、「人間レビュー必須」となる対象を 2 種類に分けて具体的に列挙しました。

1. 特定領域の変更（パスで指定）

revert しても被害が残る、または元に戻せない領域です。たとえば以下を挙げています。

  • DB スキーマ・マイグレーション（カラム削除や型変更はデータ消失を伴い、本番適用後の DDL ロールバックも難しい）
  • RLS ポリシー（設定ミスが即座に全テナントへ波及しセキュリティインシデントに繋がる）
  • 認証・認可（認証バイパスやセッション漏洩は revert しても被害が残る）
  • インフラ（IaC）／CI/CD のデプロイ系ワークフロー
  • AI 基盤設定、リリース制御、依存関係の Major アップデート

2. アプリケーション全体に波及する変更（性質で指定）

特定パスに紐付かないものの、チームが依存し始めると切り替えコストが跳ね上がる種類の変更です。

  • 基盤ライブラリの追加・置換（フレームワーク、ORM、AI 基盤、認証基盤など）
  • マネージドサービスの追加・変更
  • ミドルウェア構成・エラーハンドリング戦略・ロギング基盤などの横断的関心事
  • モノレポ構成の変更

例外として、Design Docs・ADR・コーディング規約などの「チーム合意を伴うドキュメント」は、One-Way Door ではないものの人間レビュー必須にしています。意思決定の記録として後から参照されるため、合意形成プロセスを経ない更新を避ける狙いです。

上記に該当しないものは Two-Way Door とみなしてセルフマージ可。判断に迷ったら人間レビューを選ぶ、というデフォルトを安全側に置いています。

Claude Code Action による自動判定

ガイドラインを整備しても、PR ごとに開発者が毎回読み返して判定するのは現実的ではありません。判定にコストがかかる仕組みは結局使われなくなるので、判定そのものを自動化することにしました。

PR を作成したタイミングで Claude Code Action3 にガイドラインと差分を読み込ませ、セルフマージ可能かどうかをコメントで投稿させています。結果は「セルフマージ可」「人間レビュー必須」のどちらかで、根拠になったガイドラインの該当項目もあわせて提示されます。

実際の判定コメントは次のような形で投稿されます。Two-Way Door な変更にはセルフマージ可、One-Way Door に該当する変更には人間レビュー必須として、それぞれ理由と該当ファイルが提示されます。

セルフマージ可人間レビュー必須
Claude Code Action による「セルフマージ可」判定コメントの例Claude Code Action による「人間レビュー必須」判定コメントの例

PR 作成者もレビュアーも、「なぜセルフマージしてよいのか」「なぜ人間レビューが要るのか」をその場で把握できます。

判定が誤っていると感じたときは、PR 作成者がコメントで反論したり、ガイドライン自体を更新したりできるようにしています。Claude Code Action の判定はあくまで判断の拠り所で、最終決定はしないという位置付けです。

効果

セルフマージ運用を開始してから 2 週間が経ちました。導入前と比較して、リードタイムとセルフマージ率の両面で変化が出てきています。

セルフマージ判定: 約 8 割が人間レビュー不要

運用開始後の 2 週間にマージされた PR について、Claude Code Action の判定結果を集計したところ、159 件のうち 80%（127 件）が「セルフマージ可」 でした。

区分件数割合
セルフマージ可12780%
人間レビュー必須3220%

ガイドライン策定の段階で「2/3 くらいはセルフマージ可能だろう」と見込んでいたので、おおむね想定どおりの比率でした。これだけの PR で人間レビューの待ち時間を取り払えたのは、それだけチームの時間効率を引き上げられたということでもあります。

リードタイム: p90 が 132〜316h → 92h に短縮

リードタイムは中央値で見ると週ごとの揺らぎが大きいため、より安定した p90（9 割の PR がそれ以下に収まるリードタイム）と 24h 以内マージ率 を見てみます。

指標運用前（過去 13 週）運用後（直近週）
p90 リードタイム132〜316h92h
24h 以内マージ率48〜68%77%

p90 は過去 13 週で 132〜316h のレンジだったところ、直近週は 92h まで下がりました。24h 以内マージ率も 48〜68% から 77% に達しています。中央値も直近週は 1.7h と、ほとんどの PR が同日中にマージされる状態に近づいてきました。

ただしリードタイムは PR の粒度などに左右されますし、運用 2 週間時点の数字なので参考程度になります。それでも、レビュー待ちで止まる場面が減ったのは確かな実感としてあります。

トレードオフへの備え

セルフマージにもトレードオフはあります。意図しない方向に機能要件がブレる、他の作業とコンフリクトする、Biz チームとの調整が漏れる、といったリスクです。リスクを引き受けてでも、得られる効率改善のほうが大きいと考えていますが、もちろん野放しにしてよい理由にはなりません。リスクを抑えるために、以下の施策もセットで進めています。

Design Doc での事前合意

Acsim には、新規機能開発を始めるときに必ず Design Doc を書く文化があります。セルフマージ開始後は、Design Doc に機能要件だけでなく技術的な設計もまとめて書き、ビジネス要求とエンジニアリング判断の両方を 1 PR でレビューできるようにしました。ここはもちろん人間レビュー必須です。

  • ビジネス要求 → PO から Approve 必須
  • エンジニアリング判断 → Dev メンバーから Approve 必須

ここでしっかりすり合わせておけば、以後の開発のほとんどをセルフマージだけで進められます。Why と What、そして How の概略を握れているので、要件や実装方針がブレるリスクを小さくできます。

ドキュメントの剪定

AI レビューの精度はチームのドキュメント品質に強く依存します。Acsim では docs ディレクトリに大量のマークダウンが蓄積されていて、AI 自身がドキュメントを書くようになってから 1 ファイル 1000 行近くに達するものも出てきていました。こうしたドキュメントは人間にとっても AI にとっても扱いづらく、AI レビューが誤った前提で動く原因にもなります。

そこでドキュメンテーションガイドラインを策定し、違反ドキュメントを洗い出す Agent Skills でリポジトリ全体を継続的に剪定する仕組みを整えました。AI レビューを増やす前に足場を整えるイメージです。ガイドラインの中身や Agent Skills は、別の機会に書ければと思います。

AI レビューのさらなる拡張

足場が整ったところで AI レビューを増やしました。すでに Devin Review、CodeRabbit、Copilot は使っていましたが、これに加えて Claude Code Action によるコードレビューも追加しています。既存のサービスと違って、プロンプトを細かく指定できる点と、Sub Agent を並列に動かして観点を独立して増やせる点が気に入っています。

ただし、AI レビューが増えすぎたり的外れなコメントが続いたりすると、開発者が疲弊して AI レビューをスルーしてマージするようになってしまいます。これを避けるため、AI レビューの精度や指摘傾向を継続的に観測して改善するループも合わせて設計中です。

まとめ

人間レビュー必須のルールは、コードを人間が書いていた時代に作られたものです。AI が PR を量産する今、そのままにしておくとレビュー待ちが新しいボトルネックになります。

Acsim では One-Way Door / Two-Way Door の考え方で AI と人間のレビューを線引きし、判定を Claude Code Action に任せました。結果、PR の約 8 割が人間レビューを介さずにマージできるようになり、p90 リードタイムも過去 13 週のレンジと比べて約 30〜70% 短縮しました。レビュー待ちの時間が減った分、開発者はどんどん次のタスクに着手できるようになっています。

AI 駆動開発の中では、開発プロセスのあらゆる前提が問い直し対象になります。Acsim でもまだ手をつけられていない領域が残っているので、引き続き仕組みのアップデートを続けていく予定です。

Footnotes

  1. "nitpick"（重箱の隅）の略。コードレビューで使われる慣用表現で、命名や小さなフォーマットなど些末な指摘を指す。マージブロックではないという含意を持つことが多い（参考: Conventional Comments）。 ↩

  2. Jeff Bezos の 2015 年株主への手紙で示された意思決定フレーム。戻れない決定（One-Way Door）はじっくり、戻れる決定（Two-Way Door）は速く、という使い分けを提唱している。 ↩

  3. GitHub Actions 上で Claude を動かすための Anthropic 公式アクション（anthropics/claude-code-action）。リポジトリのファイルやガイドラインを読ませた上でコメント・レビュー・コード生成を行わせられる。 ↩