PRレビュー〜本番デプロイまで全自動にしてみた結果

PR本記事はアフィリエイト広告(プロモーション)を含みます。紹介する商品・サービスの選定基準や体験談は編集部の見解に基づきます。

この記事を読むと何ができるようになるか

コードの変更(プルリクエスト)を、実装からテスト確認・公開可否判定・本番反映まで自動でつなげる仕組みの全体像がわかります
「どこまで自動化してよくて、どこから人の判断を挟むべきか」という線引きの考え方が具体的にわかります
自分の開発環境でも今日から試せる、レビュー観点・打ち切りルールのプロンプト例が3つ手に入ります

「AIにコードを書かせるところまでは自動化できたけれど、その先のレビューや公開作業はやっぱり自分でやっている」という方は多いのではないでしょうか。この記事では、当社が実際に運用している「実装→テスト確認→公開可否判定→本番反映」までを連続して自動で進める仕組みと、途中で必ず人の判断に戻す条件を、包み隠さず紹介します。

そもそもの悩み: レビュー待ちが自動化のボトルネックになる

AIにコードの実装を任せられるようになると、次にボトルネックになるのはたいてい「レビュー待ち」の工程です。

実装自体は早く終わるのに、レビューする人の手が空くまで反映が止まってしまう
かといって「テストが通ったら即マージ」にしてしまうと、事実確認は済んでいても「本当に公開してよいか」という別の観点が抜け落ちる
逆に人がすべてのプルリクエストを毎回目視確認していると、件数が増えるほど確認そのものが渋滞する

つまり、実装を自動化しただけでは、レビュー以降の工程がそのままボトルネックとして残ってしまうのです。

💡 ポイント: 「レビューを省略する」のではなく、「レビューの中身(事実確認と公開可否判定)を役割ごとに分けて、判定基準を先に明文化しておく」ことが、レビュー待ちを自動でつなげるための土台になります。

当社が実際に採用している全体の流れ(図解)

①実装(開発担当)
      │ 変更をまとめてプルリクエストを作成
      ▼
②品質確認(動作確認・テスト実行)
      │ 実際にコード・テストを動かして合否を判定
      ▼
③公開可否判定(GO/NO-GO判定)
      │
   ┌──┴──┐
   ▼        ▼
  GO      NO-GO
   │        │
承認→マージ  具体的な指摘つきで差し戻し
   │        │
本番デプロイ  同じ指摘を踏まえて再修正
             │
       再度「品質確認」へ戻る
       (同じ案件で3回連続NO-GOなら
        自動ループを止めて人に報告)

②(品質確認)と③(公開可否判定)を同じ役割にまとめず、あえて分けているのがポイントです。②は「実際に動くか、テストが通るか」という事実確認に専念し、③は「ブランド・リスク・戦略の観点で公開してよいか」を判定します。この二段階チェックの考え方自体は、以前の記事「「品質管理部」と「レビュー部」を分けたら公開ミスがどう減ったか」でも紹介しましたが、今回はこれをコード開発のプルリクエスト運用に特化させ、GOが出たあとの「承認→マージ→本番デプロイ」までを連続して自動で行うところまで踏み込んでいます。

どこまで自動にして、どこから人が判断するか

当社では、「ドラフト作成・分析・レビューまで」は各担当の判断で進めますが、「実際に外部へ影響する行為(公開・デプロイ・送信など)」は、GOサインが出ていても、原則として人に最終確認を取ってから実行する、という一線を基本ルールにしています。

ただし、このルールには例外があります。定型化され繰り返し発生するフローについては、人が明示的に「この範囲は都度確認なしで自動運転してよい」と指示した場合に限り、その範囲を自動運転に切り替えてよい、という運用です。今回紹介しているPRレビュー〜本番デプロイのループは、まさにこの「明示的に自動運転を許可された定型フロー」に該当します。つまり、

品質確認担当→公開可否判定担当という自動レビューの実行
判定結果(GO/NO-GOの理由)をプルリクエスト上にコメントとして残すこと
GOの場合、承認・マージ・本番デプロイまでを実行すること

は、都度の確認を待たずに連続して実行してよいことになっています。一方で、この自動運転の対象は「あらかじめ範囲が明確な繰り返し作業」に限られ、事業の方向性そのものに関わるような大きな意思決定は対象外です。

⚠️ 注意: 「自動でやってよい」と「人の確認を一切挟まない」はイコールではありません。自動運転に切り替えるかどうかの判断自体は、必ず最初に人が明示的に指示したときだけ発生する、という前提を崩さないようにしています。

GO/NO-GOの判定基準と「打ち切りルール」

判定担当がNO-GOと判断した場合は、具体的な修正点を明記したうえで実装担当に差し戻します。差し戻しを受けた担当は、指摘を踏まえて同じ変更のまま修正し、再び品質確認の工程に戻します。この流れ自体は、通常のレビューサイクルと同じです。

ポイントは、このループを無限に繰り返さないという点です。

判定担当がNO-GOと判定したら、具体的な修正点を明記して差し戻す
差し戻しを受けた担当は、指摘を踏まえて同じ変更のまま修正する
修正後、再び品質確認→公開可否判定のチェックに戻す
同じ変更(同じプルリクエスト)で判定が3回連続してNO-GOになった場合は、自動的な修正ループをいったん止め、なぜ通らないのかの指摘内容を要約したうえで人に報告し、判断を仰ぐ

この4番目のルールが、今回のPR自動化ループの一番の要です。

なぜ「3回」で打ち切るのか

同じ指摘が1回や2回で終わるのは、実装の細かい見落としとしてよくあることです。しかし、同じような指摘が3回連続して続くということは、単純な修正ミスというより、そもそもの設計・前提条件・要件の理解に構造的なズレがある可能性が高いと考えられます。

このとき自動ループをそのまま回し続けてしまうと、次のようなリスクがあります。

表面的な修正を繰り返すだけで、根本的な問題が解決しないまま時間だけが過ぎる
「AI同士のやり取りだけで解決しようとする」ことで、本来は人が判断すべき設計上の意思決定が先送りにされる

そこで、3回という区切りを設けることで、「このあたりで一度立ち止まって、人の目で全体を見直したほうがよい」というサインとして扱っています。打ち切り時に人へ報告する内容も、「何が・何回・どう指摘されたか」を要約したものにし、ゼロから経緯を追わなくても状況を把握できるようにしています。

💡 ポイント: 打ち切りの回数(何回連続でNO-GOになったら止めるか)に絶対の正解はありません。まずは3回のように具体的な数字を決めて運用してみて、多すぎる・少なすぎると感じたら調整する、という進め方で十分です。

GOの場合: 承認・マージ・本番デプロイまでを自動で実行する

判定がGOになった場合は、以下の流れを連続して実行します。

プルリクエストを承認する
変更を取り込む(マージする)
本番環境への反映手順を実行し、実際に反映する

これらは前述の「明示的に許可された定型フロー」に含まれるため、都度の確認を待たずに連続して実行します。ここまで踏み込むことで、「レビューは自動化できたが、マージとデプロイだけは結局人が手動でやっている」という中途半端な自動化を避けられます。

なぜ「デプロイの失敗時のロールバック」だけは自動化の対象外にしているか

一方で、あえて自動化の範囲に含めていないものもあります。それが「本番反映後に異常が起きた場合の、自動的な切り戻し(ロールバック)」です。

デプロイ後の異常には、単純に「直前の状態に戻せばよい」だけでは済まないケースが含まれます。データの更新を伴う変更が途中まで進んでいたり、複数の変更が絡み合っていたりすると、機械的に「1つ前の状態に戻す」という判断だけでは、かえって状況を悪化させる可能性があるためです。そのため、異常を検知した場合は自動で元に戻す処理を実行せず、まず人に状況を報告してから、どう対応するかの方針を決める、という設計にしています。

⚠️ 注意: 「ここまでは自動化してよい」という範囲を決めるときは、「うまくいったときの後始末」だけでなく「失敗したときの後始末」も自動化してよい範囲かどうかを、別に検討することをおすすめします。同じ工程の中でも、片方だけ自動化し、もう片方は人の判断を残す、という組み合わせは十分にありえます。

自分の開発でも試せるプロンプト例(3つ)

サブエージェントのような仕組みがなくても、GitHubのプルリクエスト機能と、普段使っているAIチャットを組み合わせるだけで、近い運用を再現できます。

プロンプト例(レビュー担当の役割・観点を定義してもらう場合):

これから、プルリクエストの内容を確認する「レビュー担当」の
役割定義を作成します。以下の条件を満たすたたき台を作ってください。
・確認してほしい観点: 実際に動くか、既存の挙動を壊していないか、
 セキュリティ上の懸念がないか
・判定は必ず最後に「GO」か「NO-GO」を明記させる
・NO-GOの場合は、修正すべき点を箇条書きで具体的に挙げさせる

プロンプト例(NO-GOの差し戻しコメントを書いてもらう場合):

以下のプルリクエストの変更内容について、NO-GOと判定した理由と、
具体的な修正点を、実装した本人が読んですぐ対応に移れるように
簡潔にまとめてください。

変更内容の概要: [ここに変更内容を書く]
指摘したい点: [気づいた問題点を書く]

プロンプト例(打ち切りルールを自分の運用に合わせて言語化する場合):

以下の運用について、「何回連続でNO-GOが続いたら、
自動的な修正ループを止めて人に判断を仰ぐべきか」を
整理してください。あわせて、人に報告するときに
最低限伝えるべき内容も箇条書きにしてください。

現在の運用: [差し戻し→修正→再確認の流れを書く]
重視したいこと: 効率と、構造的な問題を見逃さないことの両立

💡 ポイント: レビュー担当のプロンプトには、「見てほしいこと」だけでなく「判定は必ずGO/NO-GOで明記させる」という出力形式まで指定しておくと、あとで人が読み返すときの負担がぐっと減ります。

まずはここから: 最初の一歩

サブエージェントのような複雑な仕組みを一から作らなくても、次のような身近な一歩から始められます。

まだ使ったことがなければ、GitHubで無料アカウントを作成し、自分のコードを保管するリポジトリを1つ用意する
GitHub CLI(gh)公式サイトから、コマンドラインでプルリクエストの作成・確認ができるツールをインストールする(GUI操作で進めたい場合はこの手順は省略しても構いません)
上記の「レビュー担当の役割・観点を定義してもらう」プロンプトを使い、自分用のレビュー観点をチャットに設定する
実際に小さな変更でプルリクエストを1つ作り、そのレビュー担当チャットに変更内容を貼り付けて判定してもらう
慣れてきたら、「NO-GOが何回続いたら自分に報告させるか」というルールも決め、機械的に流されすぎない仕組みに育てていく

使用例: 個人でツールを開発している中野さんのケース

副業で小さな業務効率化ツールを開発している中野さんの例です。中野さんは、AIにコードの実装を任せられるようになった一方で、「レビューを自分でやると結局後回しになり、変更が溜まってしまう」という悩みを抱えていました。

まず「レビュー担当の役割・観点を定義してもらう」プロンプトを使い、自分専用のレビュー担当チャットを用意しました
実装が終わるたびに、変更内容をレビュー担当チャットに貼り付け、GO/NO-GOの判定をもらう習慣にしました
NO-GOが出た場合は、指摘に沿って修正し、再度同じチャットで確認する、というループを回すようにしました
「同じような指摘が3回続いたら、いったん手を止めて自分で設計を見直す」というルールを自分なりに決め、機械的な修正の繰り返しに時間を使いすぎないようにしました
GOが出た変更だけを、実際に自分の手でマージ・反映するようにしました(反映作業自体は中野さん自身が行っています)

中野さんいわく、「レビュー担当を別チャットに分けただけで、『自分のコードだから大丈夫だろう』という甘い判定を防ぎやすくなった感覚がある」とのことでした(これは中野さんの体感であり、当社が効果を計測した数値ではありません)。

Before/After比較

項目	自動化前	GO/NO-GOループを導入後
レビューのタイミング	人の手が空くまで反映が止まりがちだった	実装が終わった時点ですぐ判定にかけられる
差し戻しの基準	「なんとなく気になる」で止まることがあった	具体的な指摘つきで差し戻される
止まりどころ	際限なく修正を繰り返してしまうことがあった	3回連続NO-GOで一度立ち止まるルールがある
失敗時の後始末	その都度手動で対応していた	ロールバックは意図的に自動化せず、必ず人に報告してから対応する

※上記は当社の運用における設計の整理であり、開発スピードの向上率などを厳密に計測して比較したものではありません。

気をつけたいこと

GO/NO-GOの判定基準は、最初から完璧なものを作ろうとせず、実際に運用しながら「見落としが多い観点」を追加していくくらいの気持ちで十分です
打ち切りルール(何回連続NO-GOで止めるか)は、プロジェクトの重要度やチームの状況によって適切な回数が変わります。まずは具体的な数字を1つ決めて、多すぎる・少なすぎると感じたら調整してください
「公開可否の判定が自動化されている」ことと「本番反映後のトラブル対応まで自動化してよい」ことは別問題です。うまくいったときの処理と、失敗したときの処理は、それぞれ別に自動化の範囲を検討することをおすすめします

⚠️ 注意: 本記事で紹介した仕組みは、あくまで「あらかじめ範囲を明確にした定型フローの自動化」です。事業の方向性に関わるような大きな意思決定や、影響範囲が読みきれない変更まで、同じ感覚で自動運転の対象を広げることはおすすめしません。

よくある質問

Q. 個人開発でも同じ仕組みは作れますか? 作れます。本記事で紹介したように、専用のサブエージェントがなくても、普段使っているAIチャットを「レビュー担当」として役割分担し、プルリクエストの変更内容を貼り付けて判定してもらうだけでも、近い効果が期待できます。

Q. 打ち切りの回数は3回が正解ですか? 絶対の正解ではありません。当社では3回という基準を採用していますが、プロジェクトの性質やチームの規模によって適切な回数は変わります。まずは具体的な数字を決めて運用し、様子を見ながら調整することをおすすめします。

Q. 本番デプロイまで自動化するのは怖くないですか? 何でも自動化してよいわけではありません。当社では「あらかじめ範囲が明確な繰り返しフロー」に限定し、かつ失敗時のロールバックは意図的に自動化の対象外にすることで、リスクとのバランスを取っています。自動化する範囲と、人の判断を残す範囲を、最初にはっきり線引きしておくことが重要です。

まとめ

実装の自動化だけでなく、その先のレビュー・公開可否判定・本番反映までを連続してつなげることで、レビュー待ちのボトルネックを解消できます。ポイントは、「品質確認」と「公開可否判定」を役割ごとに分けること、GO/NO-GOの判定基準をあらかじめ明文化すること、そして同じ指摘が3回連続したら自動ループを止めて人に判断を戻すこと、失敗時のロールバックはあえて自動化せず人の判断を残すことです。まずは自分の開発環境でも、レビュー担当のチャットを1つ用意し、小さな変更から判定させてみることから始めてみてください。