生成AIとの開発で肝心なのは「どこまで任せて、どこで人が締めるか」です。変更は下書き→リハーサル→本番と進み、検査と人の承認を必ず通ります。
- 保存はこまめに軽く、検査は節目に一度だけ
- 本番への反映は、必ず人が承認して決める
- 危ない操作は、人が書いた手順書で禁じてある
生成AIに任せて、壊れないの？
コードの多くを生成AIが書く時代になりました。頼りになる一方で、もし間違った変更がそのまま公開されたら…という不安も残ります。スピードと安全を、どう両立すればよいのでしょうか。
答えは、人間のチームが長年磨いてきた Git の「段階を踏む」仕組みにあります。生成AIにもこの段取りをそのまま守らせ、大事な判断だけを人に残す — その組み立てを見ていきます。
まず、全体の流れをつかむ
各工程・分岐・レーンをクリックすると、その仕組みの説明がここに表示されます。
この図をテキストで読む
業務フロー図「生成AIに任せた変更が、本番に届くまで」。レーン4本、工程9個。 【レーン（担当）】（左から右） - あなた: 依頼と判断 - 生成AI: Claude Code・実装と手続き - リハーサル: 本番の一歩手前の段階 - 本番: 利用者が使う場所 【工程】（上から下へ。担当 → 工程名） ── フェーズ: つくる ── 1. あなた: 作りたいことを伝える〔開始・終了〕 2. 生成AI: 専用の作業ブランチを用意（本番から分けた下書き） 3. 生成AI: 実装して、こまめに保存（保存は何度でも） ── フェーズ: たしかめる ── 4. 生成AI: 出発前の検査に合格?〔分岐〕（生成AIの二重レビュー） はい → リハーサルへ統合 いいえ → 指摘を直して再挑戦 5. 生成AI: 指摘を直して再挑戦〔開始・終了〕（多くは生成AIが修正） 6. リハーサル: リハーサルへ統合 ── フェーズ: とどける ── 7. あなた: 確かめて、本番に出す?〔分岐〕（最後の判断は人） はい → 人の承認で本番へ公開 いいえ → 下書きに戻って続き 8. 本番: 人の承認で本番へ公開〔開始・終了〕（ここだけは必ず人が決める） 9. あなた: 下書きに戻って続き〔開始・終了〕
検査のタイミングで、何が変わる?
各セルをクリックすると、その意味や詳しい説明がここに表示されます。
この図をテキストで読む
比較表。2列 × 4行。 【列】 1. 保存のたびに検査（こまめに毎回） 2. 節目にまとめて検査（この記事の方式） 【比較】（観点ごとに） ■ 開発のテンポ - 保存のたびに検査: 毎回、検査待ちが入る - 節目にまとめて検査: 保存は数秒で完了 ■ 指摘の質 - 保存のたびに検査: 断片しか見えない / 書きかけへの指摘はノイズに - 節目にまとめて検査: 変更全体を通して見る / つながりまで確認できる ■ 手間と費用 - 保存のたびに検査: 回数分だけ積み上がる - 節目にまとめて検査: 節目の一度で済む ■ 抜け道への強さ - 保存のたびに検査: 近道が素通りしがち - 節目にまとめて検査: 近道でも検査は省略なし 【観点】 - 毎回検査で見る: 保存のたびに検査 - 節目検査で見る: 節目にまとめて検査
この形に落ち着くまで
- 1
毎回検査から乗り換えた
はじめから今の形だったわけではありません。保存のたびに検査を回す運用を実際に試し、その重さを経験してから、節目に一度へ乗り換えました。
- 2
Git の基本形の一歩先
開発基礎の「Git / GitHub」の記事では、合流した変更がそのまま本番へ届く基本形を描きました。この記事はその手前にリハーサルの段を一つ挟んだ、生成AIと組むための運用形です。
秘密は Git に乗せない
パスワードや接続情報の入ったファイルは、保存の前に生成AIが点検し、疑わしければ人に確認します。一度でも履歴に混ざると、消したつもりでも痕跡が残るためです。この決まりも、人が書いた手順書に組み込まれています。
押さえておきたい用語
- コミット
- 作業の区切りごとの保存。正式には commit。こまめに積むほど、戻れる地点が増えます。
- レビューゲート
- リハーサルに入る手前の検査。生成AIが変更全体を点検し、重大な指摘が残る間は通しません。
- ステージング環境
- 本番そっくりに用意したリハーサル用の場。正式には staging。本番より先にここで確かめます。
- プルリクエスト
- 「この変更を取り込んでほしい」という提案書。正式には Pull Request（PR）。差分と経緯が記録に残ります。
- ワークツリー
- 作業スペースをもう一つ用意して並行作業する仕組み。正式には worktree。作業中のものを壊さず別件を進められます。
ここから先へ
この解説とつながりのあるページ