AIでアプリ開発をするときのブランチ運用を現役エンジニアが実演解説

この記事では、現役エンジニアのぼくがふだんやっているブランチ運用の流れを、実際にWebコンテンツ分析アプリを作りながら解説します。

適切なブランチ運用を理解すると、AIのアプリ開発をより効率的に進められるようになります。

今回は、AIで要件定義書と作業計画を作った前回の記事の続きです。なので、すでに要件定義と実装計画はできている前提で話を進めます。

動画で見たい方はこちら。

計画書のPR1をAIに対応させる

前回作った計画書のplan.mdでは、アプリの開発を13本のPRに分けました。さっそくPR1に対応してもらいます。

Claude Codeを開き、モデルをOpus 5.5、思考レベルを「最大」にします。アプリのフォルダを開いたら、入力欄に@を入力し、候補から計画書のplan.mdを選びます。

続けて、「PR1対応して」と指示します。

@plan.md のPR1対応して

作業報告では、AIが独自に決めたところを注意深く読む

Claudeの作業が終わったら、まずは作業報告で作業の概要を確認します。特に「主な判断」や「手元に影響する変更」のように、AIが独自に決めたところは注意深く読みます。

今回は、特に問題はありませんでした。

PRの説明欄で分からない言葉は、AIに質問して理解する

次に、GitHubでPRを開きます。PRの説明欄にも作業内容が書かれているので、目を通します。

アプリ開発の初心者なら、説明欄にあるmiseとは何か、「CIがPRで走る」とはどういう意味かなど、分からないことをAIに一通り質問して理解しましょう。

AIの作業内容を理解していないと、その作業が適切かどうかも判断できないからです。

PRの差分で、AIが修正したファイルを確認する

説明欄に問題がなければ、PRの「Files changed」タブで差分を見ます。差分には、今回の作業でAIがしたすべての修正が含まれます。

ソースコードは、コメントを中心にざっと読み、おかしなところがないかを確認します。設定ファイルはアプリによって最適な内容が異なるので、ここでは主なファイルの役割だけを紹介します。

.github/workflowsのYAMLは、GitHubでプログラムを実行する設定ファイル

最初の差分のci.ymlは、GitHub上でプログラムを実行するための設定ファイルです。プロジェクトの.github/workflowsフォルダにYAMLファイルを置くと、GitHubでプログラムが自動実行されるようになります。

このGitHubでプログラムを動かす機能を、GitHub Actionsと呼びます。ci.ymlの主な設定は次のとおりです。

• on：実行条件。今回はPRの作成時と更新時
• permissions：権限。今回はreadで、読み取りのみ許可
• cancel-in-progress: true：実行中に新しいプッシュがあると、前の実行を取り消す設定
• steps：必要なツールのインストールと、テストの一括実行

このように、実行したいプログラムの設定をYAMLファイルとして.github/workflowsに置くと、GitHub Actionsが実行されるようになります。

フォーマッターが、ファイルの書き方を自動でそろえる

次のファイルでは、見出しの前に空行が1行追加されています。これはフォーマッターによる修正です。

フォーマッターとは、ファイルの中身を決まったルールに従って整えるツールです。今回の空行は、Markdownの見出しの前には必ず空行を入れるというルールによるものです。

フォーマッターは他にも、

• "と'のどちらを使うのか
• スペースは半角を使うのかタブを使うのか
• コードの末尾には;を付けるのか

などのファイルの書き方のルールを一律で決め、自動整形してくれます。

これで、AIも人も、ファイルの細かい書き方を整える作業から解放されます。今回作っているアプリでは、代表的なフォーマッターのPrettierを使っています。Prettierは無料で使えるツールです。

.gitignoreには、Gitで管理しないファイルを書く

.gitignoreには、Gitで管理したくないファイルを書きます。たとえば、履歴管理の意味がないものや機密情報ファイルなどです。

具体的には、以下のようなファイルを.gitignoreに設定します。

• Macが自動で作るファイル
• プログラムやツールの実体
• APIキーなどの機密情報
• ログファイル

AGENTS.mdには、AI向けにプロジェクトの説明を書く

AGENTS.mdは、AIエージェント向けにプロジェクトの説明を書くファイルです。今回は、何のアプリか、どこにどんな資料があるか、開発で使うツールが書かれていました。

Claude Codeが読むCLAUDE.mdには、AGENTS.mdを読み込む1行だけが書かれています。

こうすることで、Claude Codeでも、それ以外のAIエージェントでも同じ設定ファイルを使えます。

GitHub Actionsでテストを自動実行すれば、バグにすぐ気づける

ci.ymlが追加されたので、今回の作業のPRでもGitHub Actionsが動いています。実行結果は、PRの画面の下のほうで確認できます。

今回は、テストが1分で成功していました。エラーがあれば、ここに×が表示されます。

PRでテストが自動で実行されるようにしておけば、AIがバグを作ってもGitHub Actionsがエラーになるので、すぐに気づけます。

GitHub Actionsの料金は、パブリックリポジトリなら無料です。プライベートリポジトリでも、月2,000分まで無料で使えます。

2,000分を超えて使うには、従量課金か有料プランへの切り替えが必要です。どちらもしなければ、次の請求期間が始まるまで実行できません。

問題がなければマージし、パソコンにも取り込む

差分を一通り確認して問題がなければ、PRの画面の下にある「Merge pull request」を押し、続けて「Confirm merge」を押してmainにマージします。

マージしたブランチはもう不要なので、「Delete branch」を押して削除します。リポジトリの設定で、マージ後にブランチを自動で削除することもできます。

最後に、マージしたmainの内容をgit pullでパソコンにも取り込みます。Claude Codeに、PR1の作業をした会話で次のように指示しても同じことができます。

mainにマージしてpullして

ブランチは、本番用・開発用・作業用に分ける

今回は、Claude Codeが自分でmainから作業用のブランチを切って作業しました。ですが、ぼくはブランチを本番用・開発用・作業用に分けて運用しています。

そこで押さえておきたいのが、GitHubのデフォルトブランチです。デフォルトブランチは、GitHubで標準の参照先になるブランチです。

例えば、リポジトリを開くと、デフォルトブランチが選ばれた状態で表示されます。PRを作るときも、マージ先として最初にデフォルトブランチが設定されます。

そのため、普段最もよく使うブランチをデフォルトブランチにするのが一般的です。ぼくの普段のブランチ運用は、次のとおりです。

• main：本番用ブランチ
• develop：開発用ブランチ。デフォルトブランチにする
• 作業用ブランチ：常にdevelopから切り、作業のたびにdevelopへマージ

本番環境に変更を反映したいときだけ、developからmainへまとめてマージします。

ブランチ運用の仕組みは、指示1つでAIに作らせる

このブランチ運用の仕組みも、Claude Codeに作らせます。Claudeアプリで新しい会話に切り替え、思考レベルを再び「最大」にして、次の指示を貼り付けました。

ブランチ運用を見直す。デフォルトブランチをdevelopとし、ふだんはdevelopから作業用ブランチを切って作業する。mainへのマージを本番反映とし、本番反映は任意のタイミングで行う。ブランチ名を受け取り、デフォルトブランチの最新から作業ブランチのworktreeを作成し、リモートにも反映するスクリプトを用意して。環境変数などのgit管理外のファイルは各worktreeから共有フォルダを参照する。またworktree削除のスクリプトも作成して。スクリプトは削除対象を受け取り、ブランチのマージ、削除、worktreeの削除をする

指示には、ブランチ運用のルールに加えて、2つのスクリプトの作成を入れています。

• worktreeの作成スクリプト：AIに複数の作業を並列で任せるため
• worktreeの削除スクリプト：ブランチのマージ・削除とworktreeの削除をまとめて実行

Git worktreeは、1つのリポジトリで、ブランチごとに作業フォルダを分ける仕組みです。作業フォルダが分かれるので、複数のAIに同時に作業させても、お互いの作業がぶつかりません。

ただし、環境変数を書いた.envなどのGit管理外のファイルは、新しいworktreeには入りません。そこで、1か所の共有フォルダにまとめ、各worktreeから参照させています。

このブランチ運用も、最初は以前紹介したgrill-with-docsで、AIと壁打ちしながら決めました。今は使いやすいブランチ運用を言語化できるので、まとめて指示しています。

なお、worktreeはClaudeアプリの標準機能でも作れます。入力欄の上にある「ワークツリー」にチェックを入れて指示すると、Claude Codeがworktreeを作って作業します。

ぼくはworktree作成時に、データベースの作成などの他の処理もさせたいので自作スクリプトを使っています。

ブランチ運用の作業も、作業報告とPRを確認してからマージする

ブランチ運用の作業もClaudeが終えたら、PR1と同じように作業報告を確認します。今回は、Claude Codeが自分でスクリプトをテストし、確認中に見つけた不具合も修正していました。

PRでも、作業内容と差分に目を通します。新しいブランチ運用に合わせて、このPRのマージ先はdevelopになっていました。問題がなかったので、developにマージして作業完了です。

AIの推奨タスクは、Issueにしてから新しい会話で対応する

ブランチ運用の作業中、Claude Codeは別のリポジトリの不具合を見つけ、推奨タスクとして出してくれました。推奨タスクは、今の作業の範囲外で直す価値があるものに、AIが気付いたときに出す提案です。

推奨タスクが出たら、ぼくはいつも次のように指示して、GitHubのIssueにしてもらいます。

推奨タスクはIssueを切って

Issueは、GitHubのシンプルなタスク管理機能で、無料プランでも使えます。リポジトリ画面の上部にある「Issues」を開くと、作ったIssueが一覧に並びます。

Issueには、タイトルや問題、対応内容などをMarkdownで書けます。

IssueをAIに対応させるときは、Issueのリンクをコピーして、Claude Codeなどに次のように指示するだけです。

以下のIssueに対応して
{IssueのURL}

Issueにしておけば、新しい会話に切り替えてから対応させられます。なお、推奨タスクのカードにある「ワークツリーで開始」を押して、worktreeを作成したうえで新しい会話で対応させることもできます。

まとめの前に、お知らせを。

公式LINEの友だち追加特典で、無料30分相談を受付中。オンライン（顔出し不要）で、AI活用のお困りごとに答えます。

友だち追加後、「相談」と送ると予約リンクが届きます。余裕がなくなったら締め切るので、お早めにどうぞ。

はたらクラフト公式LINELINElin.ee

無料メルマガで実務で使えるAI活用を毎日配信中。1分で登録できます。

超実践AI論Substacktaichiaiworker.substack.com

まとめ：AIの作業はPRで確認して取り込み、ブランチは3つに分ける

この記事の要点は次の6つです。

• AIの作業は、作業報告・PRの説明欄・差分を確認してから取り込む
• 分からない言葉はAIに質問し、作業内容を理解してから判断する
• PRでGitHub Actionsのテストを自動実行すれば、AIのバグにすぐ気づける
• ブランチはmainを本番用、developをデフォルトの開発用にし、作業用はdevelopから切る
• 並列作業には、worktreeの作成・削除スクリプトを用意する
• AIの推奨タスクは、Issueにしてから新しい会話で対応する

あなたもぜひ、今回解説したブランチ運用を試してみてください。AIに複数の作業を並列で任せ、より効率的に仕事を進められるはずです。

以下の記事では、引き続きアプリを作りながら、コードをきれいに保つリンター・フォーマッターや、セキュリティ周りの対応について解説しています。

（後日公開予定）