GitHub Issueを用いたチケットドリブンとClaude Codeマルチエージェント体制のメモ
※ まだメモ書きです
🤖 コンテキスト引継ぎの重要ポイント
- 異なるディレクトリで会話した内容は、同じコンソールで作業しても–continueで引き継がれない
- 逆にプロセスが異なろうが、同じディレクトリで会話したら–continueで引き継がれる
-> ディレクトリが同じかどうかがキモ
ブランチ作成の前提
- 親Issue:子Issue = 1:* ( 1つのイシューから0-*の子Issueが作られる。）
- Issue(親Issue、子Issueとも):PR = 1:* ( 1つのイシューから複数のPR（プルリクエスト）が作られる）
- PR:branch = 1:1 1つのPRに1つの作業ブランチ
- branch:agent = 1:1 1つのブランチに1つの担当エージェント
- Issue:agent = 1:1 1つのIssueに1つの担当エージェント
また、エージェントの役割の違いは、git worktree add を使って全部ブランチで表現する。
従って、例えばこういうタスク分解がなされ、かつ、各Issueに管理エージェント、各PRにワーカーエージェントが対応してそれぞれ作業を進めることになった場合、
- 親Issue: API公開
- 子Issue1: インフラ作る
- PR1: 要件定義
- PR2: 設計
- PR3: コーディング
- 子Issue2: コード作る
- PR4: 要件定義
- PR5: 設計
- PR6: コーディング
- 子Issue3: デプロイパイプライン作る
- PR7: 要件定義
- PR8: 設計
- PR9: コーディング
- 子Issue1: インフラ作る
エージェント数と同じだけ必要になるので、13ブランチ必要になる。
ブランチ名
暫定的に
- Issueは
feature/<parent_issue_id>とスラッシュ区切りで表す。ただし親Issueがある場合はfeature/<parent_issue_id>/<child_issue_id>とする。なお直上の親Issueだけ書き、その上のIssue以降を書いてはならない。 - PRはfeature/<issue_id>/<child_issue_id>/<work_name>のようにIssueのブランチ名に/文字列を加えて表す
とする。またそれとは別にmain(本番用)やdevelopment(開発環境用)、hotfix/X(超急ぎのバグフィックス)などがありえるが、その辺は各流儀に合わせる方向で。
例えばこのようになる。
feature/9 # 親Issue: API公開
feature/9/10 # 子Issue1: インフラ作る
feature/9/10/requirements # 要件定義
feature/9/10/design # 設計
feature/9/10/implementation # 実装
feature/9/11 # 子Issue2: コード作る
feature/9/11/requirements
feature/9/11/design
feature/9/11/implementation
feature/9/12 # 子Issue3: デプロイパイプライン作る
feature/9/12/requirements
feature/9/12/design
feature/9/12/implementation
マージ戦略
紐づくブランチにマージする。いきなりmainやdevelopmentに直マージはしない。
基本的な流れ:
- PR1, PR2, PR3 → 子Issue1ブランチへマージ
- PR4, PR5, PR6 → 子Issue2ブランチへマージ
- PR7, PR8, PR9 → 子Issue3ブランチへマージ
- 子Issue1, 子Issue2, 子Issue3 → 親Issueブランチへマージ
- 親Issue → mainブランチへマージ
この戦略のメリット:
- 各Issueで作業の完成度を確認できる
- 段階的な統合テストが可能
- 問題があった場合の切り戻しが容易
- Issueブランチが実際の統合作業を担う意味を持つ
PRのApproveは人間が行うので、そこをエージェントが自動化する必要はない。
実際の作業フロー
イシュー（課題・要求）
├── PR #1 → フィーチャーブランチA → エージェントA
├── PR #2 → フィーチャーブランチB → エージェントB
└── PR #3 → フィーチャーブランチC → エージェントC
エージェント体制
オーケストレーション体制
リーダーエージェント（管理者）
- イシューの要件と各フィーチャーブランチの作業内容の整合性チェック
- 各PRのレビューと統合判断
ワーカーエージェント（実作業者）
- 個別のフィーチャーブランチでの実装作業
- 割り当てられたタスクの完了
専門化されたエージェント体制
単一のエージェントが全ての作業を担当するのではなく、役割に応じて専門化されたエージェントを配置する
- それぞれ専用に特化したCLAUDE.mdで設定
- 検索するドキュメントも変わってくる
- MCP構成も専用になる？ 紛らわしいMCPを複数搭載すると取り違えそう
Terraform業務 エージェントチーム構成案
- 要件定義エージェント：要件の分析と整理を担当
- 設計エージェント：システム設計を担当
- コーディングエージェント：実装作業を担当
GitHub Issueを用いたチケットドリブンとClaude Codeマルチエージェント体制のメモ https://www.tricrow.com/claude-code/multi-agent.html
