AIによるIssue駆動を再設計してみた。人間のエージェントをシームレスに繋ぐ自動的Issue解決

導入

「自律型エージェントに実装を任せたい。けれど、待ち時間や確認の往復で意外と進まない」

この課題に対して、私たちは 人間と実装エージェントの間にオーケストレーターを置く三層構造 を採用しました。
狙いは、実装作業の自動化だけではありません。
文脈の補完、判断の振り分け、並列実行の制御 をオーケストレーターに集約することです。

この記事では、次の呼び方で統一します。

• オーケストレーター: ユーザと実装エージェントの間に立つ進行管理役
• 実装エージェント: 実際にコード変更・テスト・PR作成を行うAI（Devin）

この構成にすると、次の3点が効いてきます。

• ユーザは最終判断に集中できる
• 実装エージェントの自律実行を止めにくくなる
• Issue分割と並列実行を回しやすくなる

Issue処理に関わる三層構造

ユーザ（入力者）

• どのIssueを処理するか決める
• AIの変更を適用するか最終判断する

オーケストレーター（Orchestrator）

• LLM（Claude Sonnet 4.6）を利用
• Toolでユーザと実装エージェントのやり取りを仲介・最適化
• 実装エージェントへ渡す前に必要情報を整理する

実装エージェント（Devin）

• 実装担当
• コード改修、テスト、PR作成を実行
• 基本はオーケストレーターとやり取りし、ユーザとは直接対話しない

図1: 三層構造

実際の流れ

1. ユーザがIssueベースで改修を依頼
2. オーケストレーターがIssueを取得し、実装エージェント向けの指示情報を整理
3. 実装エージェントを起動して実装開始
4. 実装エージェントから質問が来たら、オーケストレーターが処理
5. ユーザ判断が必要な論点だけをユーザに確認し、回答を実装エージェントへ返す
6. 実装エージェントがPRを作成
7. オーケストレーターが一次レビューし、最後にユーザがマージ判断

図2: 単一Issueの実行フロー

この構成で良かった点

• ユーザが渡したコンテキストをオーケストレーターが補完できる
• 実装エージェントの待ち時間をユーザの待ち時間に直結させにくい
• 窓口がオーケストレーターに集約され、並列実行の管理がしやすい
• 人間待ちを減らし、全体のスループットを上げやすい

Issueベースの複数実行

1. GitHub Issueを読み込む
2. 影響範囲と対象リポジトリを把握して実装エージェントへ委譲
3. 実装エージェントが一次調査を実施
4. 「このまま進めるか / Issue分割するか」をLLMが判定
5. 分割が必要なら新規Issueを発行
6. 新規Issueを別の実装エージェントに渡して並列実行

図3: Issue分割と並列実行

Issue処理パイプライン

実際の処理は、次の順で進みます。

1. 実行ユーザでIssueを自動アサイン（他アサイン済みなら停止）
2. 事前ルールで「小さいIssue」かどうかを判定
3. 小さいIssueは調査をスキップして即実装
4. 小さくないIssueは、まず「コード変更なしの調査」だけ実施
5. 調査結果をもとに、LLMで実行計画を作成（タスク、依存関係、作業指示、対象リポジトリ）
6. タスク1件は単発実行、複数は依存関係つき並列実行
7. 完了後に親Issueへ結果コメント（ステータスとPRリンク）

図4: Issue処理の詳細フロー

システム全体として伝えるとよいポイント

1. 自動化しているのは「実装」だけではない

このシステムの肝は、AIにコードを書かせることだけではなく、
誰にいつ判断を返すか をオーケストレーターが制御する点です。

• 小タスクは即実装へ
• 大タスクは調査→分解→並列へ
• 人間判断が必要な論点だけを返す

2. 進捗可視化（会話とセッションのひも付け）

CLI/Slackの会話と実装エージェントのセッション対応をDBで管理しています。
そのため「どの指示で、どのセッションが動いたか」を追跡できます。

• スレッド単位で会話を復元
• 管理中セッションの状態を横断取得
• 経過時間、PR、消費量をまとめて確認

3. 長時間運用のための文脈圧縮

会話が長くなったときは、古い履歴を要約して最新ターンを残します。
トークン上限に近づいても、会話の継続性を保ちやすくなります。

4. 失敗時の挙動を明確にしている

並列実行では、依存先が失敗した場合に後続を自動スキップします。
また、exit / error / suspended を終端状態として扱い、監視ループを単純化しています。

5. 制約を先に公開する

運用記事では、制約も先に書くと実践的です。
たとえばプランによっては実装エージェントAPIの一部操作に制限があります。
その場合の代替フロー（一覧取得による状態確認など）も併記すると伝わりやすくなります。

まとめ

オーケストレーターを挟むと、
「自律型エージェントの実装力」と「人間の意思決定」を衝突させずに接続できます。

Issue駆動で導入するなら、次の順序が有効です。

• まず単一Issueフローを安定化
• 次にIssue分割ルールを定義
• 最後に並列実行を段階的に増やす

この順序だと、品質を落とさずに開発スループットを上げやすくなります。