実践知識 · 01
修正から公開まで、GitとAIの開発フロー
「直したはずなのに、画面が変わらない」。そんなときは、変更を保存した場所と、アプリを動かす場所を分けて考えましょう。
5SLABのAI開発ルールを使うチーム向け ·
まず、公開までの流れをつかむ
保存、mainへの統合、ステージへの反映、画面の確認、本番公開は別の段階です。細かな操作をAIへ任せても、どこまで進めたかを確認します。
この図をテキストで読む
ステップ図「保存から本番公開までの5段階」。5ステップ。 【手順】（順番に） 1. 保存する（AIがcommit・PRを準備） 2. mainへ統合（/git land） 3. ステージへ反映（manual / auto） 4. 画面を確認（人が動きを確かめる） 5. 本番へ公開（/git release）
mainと本番は、別の場所
ブランチは変更履歴を分けて管理するためのもの。実行環境はアプリを実際に動かす場所です。mainはチームの変更を集めるブランチで、ステージ（stg）や本番（prod）とは役割が違います。
GitHubはソースコードと変更履歴をチームで共有する場所です。Gitの履歴やブランチは手元にもあります。この記事のmainは、GitHubで共有しているmainを指します。
GitHub Actionsは、検査や配備の手順を自動で実行する仕組みです。選んだ版からアプリの完成品を作り、実行環境へ届ける操作をデプロイと呼びます。ブランチを作るだけでは、動くアプリやデータベースは増えません。
ステージという名前のブランチは必要？
この運用では作りません。mainのどの版を、どの実行環境で動かすかを選びます。
公開する版と、次回に残す変更を一望する
この図は、Google Cloud上にステージと本番を置く一例です。機能追加の内容は説明用の架空例です。mainへ検索、入力チェック、CSV出力、通知の順で変更を取り込みます。各箱は、その変更までを取り込んだアプリ全体の版です。追加した部分だけを表しているわけではありません。
この図をテキストで読む
構成図「mainは先へ進めても、確認した版だけを公開する」。ブロック8個、つながり7本。 枠: GitHub｜変更を管理する世界（ブロック5個）、Google Cloud｜アプリを動かす世界、ステージ（stg）（ブロック1個）、本番（prod）（ブロック2個）。 【ブロック】 - 公開中の版: いままでの機能 - 検索追加: 以前の機能＋検索 - 入力チェック追加: 検索を含む／対象 - CSV出力追加: 次回の確認・公開へ - 通知追加: 最新main／次回へ - 入力チェックまで: 検索も含む／確認済み - 公開中の版: 公開前の本番 - 入力チェックまで: 同じ完成品／公開後 【図の符号】緑の淡い塗り=効果・良い点
ステージで検索と入力チェックを含む版を確認している間に、mainではCSV出力や通知の追加を進められます。本番へ公開するのは、ステージで確認した入力チェックまでの完成品です。後から追加したCSV出力と通知は、次回の確認・公開に残します。
PR（プルリクエスト）は、変更を見てもらいmainへ取り込むための提案です。小さな変更を1つのPRにまとめると追いやすくなります。ただしPRとコミットは必ず1対1ではありません。履歴に含まれていても、後の修正で機能が変わることはあります。
作業の準備はAIに任せる
5SLABの作業ルールが入ったプロジェクトでは、「検索機能を追加して」と依頼すれば、AIが現在の作業を確認し、原則として作業ブランチと専用フォルダ（worktree）を用意します。/git startを毎回入力する必要はありません。Git単体の自動機能ではなく、AIがルールに従って行う準備です。
この図をテキストで読む
ステップ図「「検索機能を追加して」から始める」。3ステップ。 【手順】（順番に） 1. やりたいことを伝える（人が目的と範囲を決める） 2. 作業場所を分ける（AIがブランチとworktreeを準備） 3. 修正を見て取り込む（レビュー・検査後にmainへ）
同じ作業の続きでは既存の作業場所を使います。mainしかなく未編集のプロジェクトでは、同じフォルダで作業ブランチへ切り替える場合もあります。worktreeはファイルの作業場所を分けるもので、ステージや本番を複製する操作ではありません。
作業をはっきり指定したいときは/git startや/git worktreeを使えます。保存・push・PR作成をまとめる/git commit、レビューと検査を経てmainへ取り込む/git landもあります。まとめて依頼すれば細かなコマンドを一つずつ入力する必要はありませんが、確認や検査の工程は残ります。
ステージへ進むタイミング
manual｜その都度、反映を決める
manualでは、mainへの統合後にAIがステージ未反映の変更を案内します。配備対象があれば、その都度反映するかを確認し、承認後に/git deploy stgでActionsを起動します。先に「ステージまで反映して」と依頼していれば、同じ確認を繰り返しません。
auto｜mainへの統合と連動する
autoでは、配備対象の変更がmainへ入るとActionsがステージへ反映します。AIはその結果を確認します。どちらのモードでも、本番公開は確認済みの版を選んで明示的に行います。
方式はプロジェクトごとに設定します。新規の標準とUniversalはmanualです。既存プロジェクトの方式は更新時に引き継ぎます。5件や24時間は確認を勧める目安であり、定期配備の予約ではありません。
今の方式を知りたいとき
AIに「このプロジェクトのステージ反映は手動？ 自動？」と聞けば確認できます。設定はプロジェクト内の.github/deploy-policy.jsonに保存され、/deploy modeで確認・変更します。
実際にアプリを届けるのは誰？
manualでは手元のAIが反映の要求を送り、autoではmainの更新が起点になります。実際の検査・ビルド・配備を行うのはGitHub Actionsです。開始と結果を配備記録へ残し、動いているアプリの版と照合します。
この図をテキストで読む
構成図「AIが要求し、Actionsがアプリを届けて記録する」。ブロック4個、つながり3本。 枠: GitHub｜自動処理と記録（ブロック2個）、Google Cloud（ブロック1個）。 【ブロック】 - 反映のきっかけ: 依頼／main更新 - GitHub Actions: 検査・ビルド・配備 - 動いているアプリ: ステージ・本番 - 配備の記録: どの版・どの完成品か
どこまで届いたかを確かめる
統合済み、配備済み、人が確認済みは別の状態です。mainに入っただけでは画面が変わったとはいえません。Actionsが成功し、実行環境と配備記録が一致して初めて反映を確認できます。その上で、人が画面や業務の動きを確かめます。
- 統合済み
- 配備済み
- 人が確認済み
AIは変更履歴の番号（SHA）、完成品の指紋（digest）、ステージの確認対象を固定する候補IDを照合します。mainの最新位置が進んでも、選んだ完成品の記録は別に残ります。検査や記録に失敗した場合は、確認済みとして公開しません。
公開前：ステージ待ち2件、本番待ち2件
図の本番公開前なら、ステージ待ちはCSV出力と通知の2件、本番待ちは検索と入力チェックの2件です。配備へ影響する変更を対象に数え、PRのない直接変更は別に表示します。記録を取得できない状態を0件とは表示しません。
確認した完成品を本番へ
ステージで確認した候補と公開内容をAIが示し、人が本番への反映を依頼します。/git releaseは確認した完成品を作り直さずに本番へ届けます。公開依頼を受けた後で、対象を勝手に最新mainへ差し替えません。
- 1
どの版か確かめる
AIが候補と変更内容を提示。「検索と入力チェックまでの版」で合っているか確認します。
- 2
ステージで動きを見る
検索結果や入力ミスの扱いなど、実際の使い方で試します。
- 3
本番への反映を頼む
「この確認済みの版を本番へ反映して」と依頼。公開後の動作も確認します。
データや設定までは同じにならない
同じ完成品を使っても、ステージと本番ではデータや接続設定が違います。本番反映後にも動作を確認します。この仕組みの保証は対応するアプリ配備経路が対象で、別の配備経路や管理者の直接操作まで自動で保証するものではありません。
迷ったときの頼み方
依頼では「どこまで進めたいか」を添えると、AIと認識を合わせやすくなります。相談だけ、修正とPRまで、ステージで確認するところまで、本番への公開までを区別して伝えます。
- 1
変更を相談したい
「入力ミスを減らしたい。まず方法を相談させて」
- 2
修正内容を見たい
「入力チェックを追加して、PRまで作って」
- 3
動く画面で確認したい
「レビューしてmainへ取り込み、ステージまで反映して」
- 4
確認した版を公開したい
「この確認済み候補を、本番へ反映して」
公開後に戻したくなったら
公開後に問題が見つかった場合は、AIに影響と戻せる版を確認させます。/git rollbackは過去の確認済み候補へ戻す専用操作です。コードを戻しても、データベースの変更や入力データが自動で元に戻るわけではありません。
まず覚えるのは、変更の管理とアプリの公開が別の段階だということ。AIには「何を変えるか」と「どこまで進めるか」を伝えましょう。