Intent-System を試す→
提案

Git-AI-Flow

AI オーケストレーション時代に向けたブランチ運用の提案です。Git-Flow と同じ形を踏襲しつつ、各ブランチの担い手を入れ替えます。

提案 · 3 章のうち 2 章目↑ 概要に戻る
  1. 01Harness から Compass へ
  2. 02Git-AI-Flow
  3. 03Intent Storming

新しい flow が必要な理由

Git-Flow も GitHub-Flow も、人間の開発者が無理なく回せる速度を前提に設計されていました。コードを書くのも、PR をレビューするのも人間が中心で、システム全体の速度は人間の処理能力で律速されます。ところが AI オーケストレーション時代になると、その「人間の処理能力」が律速要因ではなくなります。自律エージェントは、人間が昼食を取っている間に 10 件の PR を開くことができます。

Git-AI-Flow は、AI の作業速度と人間の監督の間に緩衝地帯 (バッファ) を置きます。エージェントは長寿命の ai-develop ブランチで継続的に作業し、人間は自分の都合の良いタイミングで、選んだ状態を main に昇格させます。

形

長寿命ブランチを 2 つ持ちます。main は人間が承認済みで、本番にデプロイ可能な状態です。ai-develop はエージェントが管理し、継続的に更新されます。短命の feature/* ブランチは ai-develop から派生させます。人間は任意のタイミングで ai-develop をレビューし、選んだ状態を main に昇格させます。

main          ●─────────●──────────●─────────●  (human-promoted)
                       ▲          ▲
                       │ promote  │ promote
ai-develop    ●─●─●─●─●●─●─●─●─●─●●─●─●─●  (agent-driven)
                  ▲       ▲       ▲       ▲
                  agent   agent   agent   agent

ai-develop の上を流れるのはプロンプトの羅列ではなく、意図ツリーからコンパイルされた GitHub Issue です。各 Issue は関連する意図のスライス（アーキテクチャ・契約・UI パターン）を受け継ぐので、AI 支援開発で最もレバレッジの効くスキル「分かりやすい Issue を書く」ことが実際に効いてきます。エージェントは文脈が揃った状態で実装を進められ、main への昇格時の人間レビューは PR を個人の好みではなく意図のスライスと比較する、というかたちで安定します。

main への昇格 ── ai-develop からの経路

大規模なコードベースや、すでにリリース済みのプロジェクトでは、経路は次のようになります。エージェントは ai-develop で実装を進めます。任意のタイミングで AI レビュアーが実装・Issue・Intent ツリーを横断して読み、変更が意図を守っているかを判定します。そのレビューを通過し、人間が最終承認を出した時点で、ai-develop の選んだ地点を main にマージします。main は構造上つねに「人間が承認済みで本番デプロイ可能」な状態に保たれ、エージェント速度の振れは ai-develop が引き受けます。

バグ報告は Intent-Bug Issue として起票される

リリース後、現実の側からは欠陥・エッジケース・想定外の振る舞いといった信号が戻ってきます。これらはひとつずつ Intent-Bug という Issue として起票され、同じループに戻されます。トリアージで問うのは、Intent Tree ページにも書いた 2 択です ── これは実装バグ（意図は正しい、コードが守れていない）か、それとも意図の漏れ（意図が何も言っていない、実装者が独自判断、結果が望むものではなかった）か。実装バグは ai-develop 上でエージェントが修正し、変わらない意図スライスとの照合でレビューを通り、main へ昇格します。意図の漏れの場合は、まずツリーを昇格させ（clarification → canonical）、その鋭くなった意図が修正を駆動します。どちらの場合も、Intent-Bug は同じエージェント主体の修正ループを通り、同じ人間承認の昇格経路で main に出ていきます。

bug report (from production)
   │
   ▼
Intent-Bug issue                実装リポジトリで起票
   │
   ▼
Intent ツリーに照らしてトリアージ
   │     ┌─────────────────────────────┐
   ├─────▶ 実装バグ ── ai-develop で修正
   │     │
   └─────▶ 意図の漏れ ── まずツリーを昇格、その後で修正
              │
              ▼
        ai-develop (エージェント修正ループ)
              │
              ▼
        AI レビュー ── 実装・Issue・Intent ツリーを横断
              │
              ▼
        人間の最終承認 → main に昇格

既存 flow との比較

観点Git-FlowGitHub-FlowGit-AI-Flow
長寿命ブランチmain + developmainmain + ai-develop
develop の作業者人間n/aエージェント
リリース頻度スケジュールされたリリース連続デプロイ人間が昇格を承認
レビュアー各 PR で人間各 PR で人間ai-develop はエージェント、昇格時に人間
ボトルネックリリース調整レビュアーの稼働昇格頻度

Git-AI-Flow が適さないケース

  • AI を autocomplete (Copilot 型) としてのみ使い、すべての PR を人間が書いている場合。
  • すでに trunk-based development で満足できているチーム。
  • 1 人の開発者が自分の PR を自分でレビューしている場合。

表記

タイトルや本文では Git-AI-Flow (大文字始まり、3 単語ハイフン区切り) で統一します。コードやコマンドの文脈では小文字 git-ai-flow も許容します。推奨するブランチ名は ai-develop ですが、組織内の慣習に合わせて変更しても構いません。重要なのは役割分離であって、名前自体ではありません。

Intent-System を試す→