この記事は AIと共同で執筆しました。
はじめに
AIエージェントを使ったソフトウェア開発が急速に普及しています。Claude Code、Codex、Cursorなど、AIが直接コードを書いてくれる時代になりました。
しかし、実際にAI開発を本格運用してみると、こんな壁にぶつかりませんか？
- セッションが切れるたびにAIが文脈を忘れる
- AIが何を考えてそのコードを書いたのか分からない
- 自分しか作業を引き継げない（属人化）
- 複数人開発で手戻りが頻発する
私はこれらの課題を 「Issue駆動開発」 という手法で解決し、実際のプロジェクトで運用してきました。そして2026年3月、OpenAIが発表した Symphony が、まさに同じ思想のフレームワークとして登場しました。
本記事では、Issue駆動開発の概念・ワークフロー・実績と、OpenAI Symphonyとの共通点について解説します。
🤔 AI開発の「見えない課題」
AIにコードを書かせること自体は簡単です。問題は チームで継続的にAI開発を回す ときに発生します。
セッションの断絶
AIとの会話はセッション単位です。チャットを閉じたら、AIはそれまでの会話を全て忘れます。次のセッションでは一から説明し直す必要があり、コンテキストの再構築に膨大なトークンを消費します。
ブラックボックス化
「AIが動くコードを出してくれたけど、なぜこの実装なのか分からない」──これは個人開発なら許容できますが、チーム開発では致命的です。レビューも引き継ぎもできません。
属人化の深刻化
AIとの会話履歴は、そのセッションを持つ個人にしか見えません。担当者が離脱したら、途中経過も意思決定の理由も全て失われます。これは従来の属人化より深刻です。
品質管理の困難さ
AIの出力を検証せずにマージするのは危険ですが、各ステップで何をどう判断したのかが残っていなければ、適切なレビューすらできません。
💡 Issue駆動開発とは
Issue駆動開発は、AIとの全ての対話をIssue（GitHub Issue / GitLab Issue）に集約する開発手法です。
核となるアイデアはシンプルです。
AIとの会話を全てIssueに書き出す。Issueを設計書として活用する。
従来のAI開発フロー
開発者 → AIチャット → コード生成 → マージ
↑ 会話は消える ↑ 経緯不明
Issue駆動開発フロー
Issue作成（目的・ゴール明記）
↓
AIがIssueを読み、修正方針をコメント
↓
人間がレビュー・承認
↓
AIが実装
↓
人間がローカルで動作確認、結果をIssueにコメント
↓
AIがMRを作成
↓
人間が最終レビュー → マージ
各ステップの結果は 必ずIssue上に記録 され、人間のレビューが各段階で介在 します。
🔧 Issue駆動開発の3つの柱
1. Issueを「設計書」にする
Issueは単なるタスク管理ツールではありません。Issue駆動開発では、Issueを ミニマムな設計書 として活用します。
Issueに含める情報：
- 修正の目的（ゴール）
- 現状の問題点
- 期待する動作
- AIが提案した修正方針（AIによるコメント）
- 人間からのフィードバック（方針への修正指示）
- 実装の途中経過と確認結果
こうすることで、Issueを読むだけで「何を」「なぜ」「どう」修正したかが把握でき、人間でもAIでも作業を引き継げる状態 を作ります。
2. セッションの外部化
AIのセッションが切れても、Issueに全ての経緯が残っています。
これにより：
- AIツールの切り替えが可能：Claudeのプラン上限に達したら、Geminiに切り替えて同じIssueの続きから作業できる
- 担当者の交代が可能：開発者が一時的に離脱しても、他の人がIssueを読んで引き継げる
- 過去の意思決定を追跡可能：「なぜこの実装にしたのか」がIssueのコメント履歴で分かる
これは AIの属人化すら解消 します。特定のAIツールに依存しない、ポータブルな開発記録がIssue上に蓄積されます。
3. 人間によるゲートレビュー
ワークフローの各ステップ間には、必ず 人間のレビュー が入ります。
AIが修正方針を提案 → 人間が承認 → AIが実装 → 人間が動作確認 → AIがMR作成 → 人間が最終レビュー
このゲートレビュー機構により、AIの暴走を防ぎつつ、AIの生産性を最大限に活かせます。
🏗️ ワークフローの実際
ここでは、実際のGitHub Issueを使ってワークフローを見ていきます。
Step 1：Issueの作成
まず、対応したいタスクをIssueとして起票します。目的・現状・期待する動作・受け入れ条件を明記します。
Issue起票時点。「概要」「現状」「期待する動作」「受け入れ条件」が構造化されて記載されている
Step 2：AIによる修正方針の提案
IssueのURLをAIエージェントに渡すと、AIがコードベースを調査し、修正対象ファイル・修正方針・影響範囲を具体的にIssueへコメントします。
AIが修正対象ファイル・方針・影響範囲を自動でコメント。人間はこれをレビューするだけでよい
Step 3〜4：人間によるレビュー → AIが方針更新・実装
人間がレビューし、修正指示をIssue上でフィードバック。AIはそれを反映して実装を完了します。
人間が「表示位置をプロフィールセクションの一番上に」と指示 → AIが方針を更新して実装完了。この意思決定の経緯がIssue上に残る
ここが重要です。 従来ならチャットで伝えて消えてしまう指示が、Issue上に残ることで、なぜ表示位置が変わったのかという意思決定の記録になります。
Step 5：動作確認・MR作成
人間がローカルで動作確認し、結果をIssueにコメント。最終的にAIがPull Requestを作成し、人間がレビュー後マージします。
動作確認の結果がチェックリスト形式でIssueに記録される。全ステップの記録が1つのIssueに集約されている
👥 複数エージェントでの運用
Issue駆動開発は、複数のAIエージェントを同時に稼働させる場合にその真価を発揮します。
Git Worktreeによるブランチ分離
1つのプロジェクトディレクトリで複数エージェントが作業すると、リポジトリ上で競合が発生します。これを Git Worktree で解決します。
project/
├── main/ # メインブランチ
├── worktree-issue-1/ # エージェントA：Issue #1 を担当
├── worktree-issue-2/ # エージェントB：Issue #2 を担当
├── worktree-issue-3/ # エージェントC：Issue #3 を担当
└── worktree-issue-4/ # エージェントD：Issue #4 を担当
各エージェントが独立したワークツリーで作業するため、ブランチの競合なく並列開発が可能です。
コンテキストの最適化
複数エージェントを動かすとトークン消費が増大します。対策として：
- 初期コンテキストは最小限に：システム設定ファイルには必要なスキルの参照のみを記述し、不要な情報でトークンを消費しない
- Issueにコンテキストを集約：AIが読むべき情報はIssueに集約されているため、毎回ゼロから説明する必要がない
🎼 OpenAI「Symphony」との共通点
2026年3月5日、OpenAIがオープンソースフレームワーク 「Symphony」 を公開しました。Symphonyの設計思想は、Issue駆動開発と驚くほど一致しています。
| 概念 | Issue駆動開発（本手法） | OpenAI Symphony |
|---|---|---|
| 起点 | GitHub/GitLab Issue | Linear Issue（Ready for Agent状態） |
| ワークスペース分離 | Git Worktreeで各Issue専用のディレクトリ | Sandbox Isolationで各Issue専用の環境 |
| エージェント設定 | Claude MD / ワークフロースキル | WORKFLOW.md（リポジトリ内の設定ファイル） |
| 品質保証 | 各ステップで人間のゲートレビュー | Proof of Work（CI、テスト、ウォークスルー） |
| 成果物 | Merge Request / Pull Request | Pull Request |
| 複数エージェント | Git Worktree + エージェントチーム | BEAM VMの並行プロセスで数百エージェント管理 |
共通する核心思想
- Issueが全ての起点：チャットではなく、Issue（チケット）が作業の起点であり記録の場所
- ワークスペースの分離：各Issueごとに独立した環境を作り、エージェント間の干渉を防ぐ
- 検証可能な成果：AIの出力を無条件に信用せず、検証プロセスを組み込む
- エージェント設定のコード管理：エージェントへの指示をリポジトリ内のファイルとして管理し、バージョン管理する
OpenAIはこれを 「ハーネスエンジニアリング」（AIエージェントを確実に生産的にするためのインフラ・制約・フィードバックループを設計する規律）と呼んでいます。
私がこの手法を実践し始めたのは2025年後半からですが、OpenAIが同じ結論に至りフレームワークとして公開したことは、Issue駆動開発がAIエージェント時代の標準的な開発手法になり得ることの裏付けだと考えています。
📈 実績と効果
ベトナム人チームでの実践
海外チーム（ベトナム人エンジニア）との開発で、Issue駆動開発を導入しました。
導入前の課題：
- Issueの内容が薄い（「これやります」としか書かれない）
- 言語の壁により、設計意図の共有が不十分
- 手戻りが頻発
導入後の効果：
- AIが修正方針をIssueに詳細に記載するため、言語の壁を超えた意思疎通が実現
- 各ステップでレビューが入るため、手戻りが大幅に減少
- Issue上に全ての経過が残るため、チーム全員が状況を把握可能
複数エージェント同時稼働
最大5つのAIエージェントを同時稼働させ、複数のIssueを並列で対応。夜中にIssueを一斉に割り当て、翌朝には全てのIssueが対応済みという運用も実現しています。
個人開発から組織開発へ
AI開発で成果を出すだけなら個人でも可能です。しかし 組織として再現性のあるAI開発を実現する ためには、Issue駆動開発のようなフレームワークが不可欠です。
属人化を解消し、誰でも──プログラミング経験の少ないSEやPMでも──AIを活用した開発に参加できる環境を作ること。それがIssue駆動開発の目指すゴールです。
🔮 今後の展望
- Issue駆動開発の手法をさらに体系化し、誰でも実践できるガイドラインを整備
- OpenAI Symphonyのようなフレームワークとの連携・統合を検討
- 書籍化による手法の普及
- 複数エージェントの協調動作をさらに洗練させ、より大規模なプロジェクトへ適用
📝 まとめ
Issue駆動開発は、AI開発における以下の課題を体系的に解決する手法です。
| 課題 | 解決策 |
|---|---|
| セッションの断絶 | AIとの全対話をIssueに外部化 |
| ブラックボックス化 | 修正方針・意思決定をIssue上に記録 |
| 属人化 | Issue上に全経過を残し、AIツールも人も交代可能 |
| 品質管理 | 各ステップにゲートレビューを設置 |
| 複数エージェント管理 | Git Worktreeでワークスペース分離 |
OpenAIが Symphony で示したように、Issueを起点としたエージェント駆動開発はAI時代の標準的なワークフローになりつつあります。
重要なのはツールやフレームワークそのものではなく、「AIとの対話を構造化し、検証可能な形で記録する」 という考え方です。この考え方さえ理解すれば、どのAIツールを使っていても、すぐにIssue駆動開発を始められます。
まずは1つのIssueを立てて、AIとのやり取りを全てそこに書き出すことから始めてみてください。
参考リンク：