GitFlow・GitHub Flow・Trunk Basedの使い分け｜一人+AIエージェント2体のGit運用で決めたこと

Gitのブランチ戦略の解説記事は世の中に山ほどあって、だいたい「チーム規模別のおすすめ表」で終わる。ただ、自分の環境はその表のどこにも載っていない。開発しているのは自分一人だが、リポジトリにコミットするのは自分だけではない。Claude CodeとCodex CLIという2種類のAIコーディングエージェントが、同じリポジトリで作業を引き継ぎながらコミットしていく体制で、複数リポジトリを回している。

2026年の今、個人開発でもこの構成は珍しくなくなってきたと思う。だからこの記事は、GitFlow・GitHub Flow・Trunk Basedの教科書的な比較を一応押さえたうえで、「一人+エージェント複数」で実際にどれを選んだか、そして戦略の図には出てこない場所で事故った話を書く。

前提整理: 3つのワークフローはどう違うか

まず候補になる3つを、自分が選ぶときに見た観点で整理しておく。

GitFlowは2010年にVincent Driessenが提唱した体系で、main / develop / feature/* / release/* / hotfix/* の5種類のブランチを使い分ける。リリース周期が固定されていて、複数バージョンを並行サポートする必要があるプロダクト（パッケージソフトやエンタープライズ向け）だと今でも合理的。逆に言うと、常に最新版だけをデプロイするWebサービスにはブランチが多すぎる。

GitHub Flowは「mainを常にデプロイ可能に保ち、変更はすべてブランチ+Pull Request経由」というシンプルな型。継続的デプロイと相性が良く、PRがレビューとCIの関所になる。関所が機能するには「レビューする他人」がいることが前提になる。

Trunk Based Developmentは長命ブランチを避けて、数時間〜1日でmain（trunk）にマージし続けるスタイル。コンフリクトが構造的に起きにくい代わりに、壊れたコードが即trunkに入るので、自動テストとFeature Flagの整備が前提になる。

GitFlow      : main + develop + feature + release + hotfix（5種）
GitHub Flow  : main + feature（PRが関所）
Trunk Based  : ほぼmainのみ（テストとFlagが関所）

教科書はここで「チーム規模で選べ」と言うのだが、自分のケースでは規模の軸がそもそも役に立たなかった。

自分の結論: 一人+エージェントなら実質Trunk Based。ただし前提は満たしていない

このブログを含む自分のリポジトリは、masterブランチ1本で、featureブランチをほぼ切らない。自分もエージェントもmasterに直接コミットする。PRも立てない。分類するなら（PRなしの）Trunk Basedが一番近い。

GitFlowを選ばなかった理由は単純で、並行リリースが存在しないから。ブログとブラウザツールのサイトにrelease/1.2.0ブランチを作っても、儀式が増えるだけで守られるものがない。

GitHub Flowを選ばなかった理由の方が本質的だと思っていて、PRという関所は、承認する他人がいないと機能しない。一人でPRを立てて一人でApproveするのは、手間だけ払ってレビューの実質がない状態になる。エージェントのコミットを点検したいなら、PRを挟むよりも、コミット前に別のエージェント（読み取り専用のレビュー役）にdiffを読ませる方が自分の運用には合っていた。実際、このブログ自体をClaude Codeで作って運用している話に書いたとおり、規約と検証をエージェント側に整備する方向に投資している。

正直に書いておくと、Trunk Basedの教科書的な前提（高いテストカバレッジ、Feature Flag）は満たしていない。それでも回っているのは、ブログやブラウザツールが「壊れたらすぐ直してデプロイし直せばいい」性質のものだからだ。決済や他人のデータを扱うサービスで同じことをやるつもりはない。前提を満たさずにtrunk直コミットが成立するのは、失敗のコストが低いプロダクトに限る。

事故ったのはブランチ戦略ではなく「どのクローンが正か」だった

で、ここからが本題に近い。この体制で実際に起きた事故は、GitFlowかGitHub Flowかという話とは全然関係ない場所で起きた。

うちには記事を自動生成してコミット・pushするボットがいる（cronで毎朝動く。ちなみにcron式を書くとき用にcron式ジェネレータを自作した）。あるときリポジトリの置き場所を移設したのだが、ボットの設定が旧い場所にある古いクローンを向いたままだった。

結果どうなるかというと、ボットは毎朝、旧クローンからコミットして同じリモートにpushする。自分とエージェントが作業している新しいクローンは、毎朝勝手にbehindになる。さらにビルドとデプロイもそれぞれの場所から走るので、二重デプロイの競合が続いた。リポジトリ自体は壊れていないし、ブランチ戦略にも違反していない。それでも運用としては毎日事故っている状態だった。

原因を一言にすると、「同じリモートに複数のクローンからpushするとき、どのクローンが正か・作業開始前に必ずpullするか」を決めていなかったこと。人間一人なら「クローンは1つ」が暗黙に成立するので、この問題は表面化しない。自動化ボットやAIエージェントが増えた瞬間に、「pushする主体が複数いる」というチーム開発の問題が、一人開発に戻ってくる。

直し方は地味で、ボットの生成先を作業リポジトリに一本化し、「正のクローンはここ。旧側は読むだけ」と規約ファイルに明文化した。ブランチ図を描き直すことは一度もなかった。

エージェントと共有している運用ルール

この事故以降、ブランチ戦略よりも「人間とAIが同じルールで動くための明文化」に寄せている。実際に決めて回しているのはこのあたりだ。

作業ログへの追記を引き継ぎの唯一の手段にする。 2種類のエージェントは互いのメモリを読めないので、共有のWORKLOGファイルに「やったこと・コミットハッシュ・次の人への注意」を追記してからセッションを終える決まりにした。「隠れた状態を作らない」が原則で、片方だけが知っている事実を残さない。git履歴は「何を変えたか」は語るが「なぜ・次に何をすべきか」は語らないので、ログは別に要る。

コミットメッセージは日本語で簡潔に統一。 これは好みの問題に見えて、エージェント運用だと実利がある。エージェントは既存の履歴を読んで文体を合わせるので、履歴が統一されているほど、新しいコミットも勝手に揃う。逆に履歴が英日混在だと出力もブレる。

force pushは原則禁止。やる場合は理由をログに残す。 複数の主体がpushする環境でhistoryを書き換えると、他の全クローンが壊れる。旧クローン事故を経験した後だと、この禁止の重みがよくわかる。

秘密情報(.env、APIキー)は絶対コミットしない。 エージェントに「デプロイして」と頼むと、認証情報の扱いまで任せることになる。だから規約ファイルに禁止事項として明記し、.gitignoreを先に整備しておく。

# 共有規約ファイルにある実際の類いの記述
- コミットメッセージは日本語で簡潔に（既存の履歴に合わせる）
- force push は原則禁止。やる場合は理由を WORKLOG に残す
- 秘密情報(.env, APIキー)は絶対コミットしない
- 正のクローンは作業用ディレクトリ配下の1つだけ。旧側は読むだけで触らない

気づいたのは、これはチーム開発で「新メンバー向けにワークフローをドキュメント化しましょう」と言われてきたことと同じだということ。AIエージェントは毎セッションが新メンバーみたいなものなので、暗黙知が一切通用しない。ドキュメント化のリターンが人間チームより早く、確実に返ってくる。

それでも使い分けを聞かれたら

最後に、自分の経験の範囲で使い分けをまとめるとこうなる。

• 複数バージョンの並行サポートや固定リリース周期がある → GitFlow。ブランチの多さは複雑さではなく、並行リリースという複雑さの受け皿。それが無いなら選ぶ理由もない
• レビューする他人がいて、継続的にデプロイする → GitHub Flow。PRが関所として機能する最小構成
• テストとFlagの整備に投資できる成熟チーム → Trunk Based
• 一人+AIエージェント/自動化ボット → trunk直コミットで足りる。ただしブランチ戦略の代わりに、「正のクローンはどれか」「push前にpullするか」「force pushの扱い」「引き継ぎログ」を先に明文化する

自分の実感として、一人開発+エージェントの環境で効くのはブランチの形ではなく、pushする全主体（人間もAIもボットも）が同じ規約ファイルを読んで動くことだった。ブランチ戦略の名前は、その規約の中の1項目でしかない。