はじめに
「AI にコードを書かせたいが、どこから始めればいいかわからない」——そんな悩みをよく聞きます。 GitHub Issue を唯一のタスク起点 として、AI エージェントが Issue を読んで自律的に実装・テスト・PR 作成まで進める仕組みを構築しました。本記事ではその全体像と、実際に動かすための設定を紹介します。GitHub上でGithub Copilotを使用しているユーザ向けです。
全体の考え方
人間の開発者と同じようにタスクを与える——これがこの仕組みの根本にある考え方です。
新しいメンバーに仕事を依頼するとき、口頭でふんわり伝えるのではなく、背景・やること・やらないこと・完了条件を整理して渡しますよね。AI に対しても同じです。チケット駆動開発・スプリントバックログ・受入条件（DoD）といった、チームが人間に対して使ってきた開発プロセスをそのまま AI に当てはめます。
「すべての開発タスクは GitHub Issue を起点とする」
Issue に「何をしてほしいか」「何をしてほしくないか」「完了の定義」を明確に書き、AI はその Issue を読んで作業します。進捗は Issue にコメントとして記録され、人間が承認すべき判断点（仕様の解釈・PR のマージ等）では AI が自動で停止してコメントを残して待機します。
つまり AI は「高速で動く開発メンバーの一員」として扱います。特別なプロンプトを工夫するのではなく、チームの開発プロセスを整備することが AI 活用の品質を決めます。
役割の整理
| 役割 | 主体 | 主な責務 |
|---|---|---|
| 指示者 | 開発者（人間） | Issue 起票・受入条件の設定・最終承認 |
| 実行者 | 司令塔エージェント（AI） | Issue に基づく実装・進捗報告・不明点の質問 |
| レビュアー | 開発者（人間） | 設計妥当性・品質・セキュリティの検証 |
この 3 役割を成立させるために、.github/ 配下に以下の設定ファイル群を整備します。
.github/
├── ISSUE_TEMPLATE/ ← 指示者が Issue を書くための雛形（種別ごと）
├── agents/ ← 司令塔エージェント：Issue を読んで種別判定→prompts を順番に自走実行する頭脳
├── prompts/
│ ├── （手順計画） ← Issue 起票・着手アプローチの策定・仕様確認
│ └── （作業手順書） ← 実装・テスト・品質確認など各ステップの手順（/コマンドで呼び出し）
├── skills/ ← 複数の prompt から共通利用される小単位の手順
└── instructions/ ← AI が常時参照するコーディング規約・行動原則
指示者は Issue を書くだけ、司令塔エージェントはそれを読んで agents → prompts → skills の順に処理を進め、レビュアーは PR を確認してマージ判断をする——という分業が .github/ の構成として実装されています。
司令塔エージェント：process-issue-handler
Issue ライフサイクル全体を管理する中枢エージェントです。このエージェントが持つ論理的な役割は次の6つです。
- 起票と計画: 指示者の要望を受けて種別を判定し、Issue テンプレートに沿った本文を組み立てる。同時に手順計画プロンプトを使って「何をどの順番でやるか」を Issue 本文に書き込み、作業計画を確定させる
- 状況判断と実行: 現在のブランチ名・Issue 番号・コメント履歴から「起票が必要か」「新規着手か」「再開か」を自動判定し、適切なシナリオへ分岐して実行
-
手順の保証: 種別ラベル（
type:*）に対応する作業シーケンスを唯一の正として管理し、必須ステップの省略や順序の逸脱を設計レベルで禁止する - スコープの番人: 各ステップで Issue 本文と作業内容を照合し、Issue に書かれていない変更・推測による補完・手順外の作業を検知したら即座に自走を中断して人間に確認を求める
- コンテキストの継承: Issue 本文（実装方針・処理プラン・設計判断）と中断コメントを再読することで、AI セッションをまたいでも作業状態を復元できる
- 作業ログ: 各ステップの完了時に Issue へ進捗コメントを投稿し、処理プランのチェックリストを更新する。仕様変更・設計判断・スコープ外の発見もその場で Issue に記録することで、「なぜそう実装したか」を後から追跡できる状態を維持する。蓄積された記録は今後のプロセス改善にも活用できる。
手順計画プロンプト
タスクの種別ごとに、AI が最初に参照する「作業計画を立てるためのプロンプト」を用意します。Issue を読んで何をどの順番でやるかを AI に示す設計図にあたります。
種別ごとに手順計画プロンプトを作成し、対応する Issue テンプレートとセットで整備するのがポイントです。
| 種別 | 手順の例 |
|---|---|
| 実装（feature） | 設計書の確認 → テスト項目作成 → 実装 → 単体テスト → 設計書との整合性確認 |
| バグ対応（fix） | 再現確認 → 原因特定 → 修正 → 再発防止テスト追加 → 動作確認 |
| 設計書修正（design） | 変更箇所の洗い出し → 影響範囲の確認 → ドキュメント更新 → レビュー |
| レビュー対応（review） | 指摘内容の整理 → 修正方針の確認 → 対応実施 → 返信コメント投稿 |
手順の粒度は「1ステップ = 1つの判断・1つの成果物」が目安です。細かすぎると管理コストが上がり、粗すぎると AI が迷います。
作業手順書プロンプト
手順計画の各ステップに対応して、「そのステップで何をどうやるか」を記述したプロンプトを用意します。手順計画が「目次」なら、作業手順書は各章の「本文」です。
各プロンプトには、作業内容だけでなく確認すべき観点も明記します。
- 実装ステップなら: 既存コードのパターンに合わせているか、スコープ外の変更が混入していないか
- テストステップなら: 正常系・異常系・境界値が網羅されているか、テストデータは適切か
- 品質確認ステップなら: 型チェック・Lint・ビルドがすべて通過しているか
1 プロンプト = 1 目的に絞ることで、AI が迷わず実行でき、どのステップで止まったかも追跡しやすくなります。
skills と instructions
skills は複数のプロンプトから共通利用される小単位の手順書です。「gitブランチを作る」「コミットメッセージを整形する」「GitHub に Issue コメントを投稿する」といった繰り返し登場する操作を切り出して再利用します。
instructions は AI が常時参照するコーディング規約・行動原則です。「既存のコードスタイルに従う」「推測で実装しない」「スコープ外の変更をしない」といったチーム固有のルールをここに集約します。
どちらもプロジェクトの実態に合わせて随時追加・更新していくものです。最初から完璧に揃える必要はなく、AI が迷ったり手戻りが発生した箇所を起点に少しずつ整備するのが現実的です。
実際の動き
ここまでの登場人物と設定ファイル群が、1 つのタスクの中でどう連動するかを追います。機能追加（type:feature）を例にします。
Step 1｜指示者が AI とともに Issue を起票する
指示者（開発者）が要望や課題を自然文で AI に伝えると、AI が種別を判定して ISSUE_TEMPLATE に沿った Issue 本文を組み立てます。「やってほしくないこと」や「受入条件」の抜け漏れも AI が指摘するため、指示者は内容を確認・承認するだけで質の高い Issue が起票できます。
起票はテンプレートへの記入だけではありません。手順計画プロンプトを使って「どの順番で何を行うか」という作業計画も同時に Issue 本文へ書き込まれます。これにより Step 2 以降の自走開始時点で AI はすでに全体の手順を把握した状態になります。
タイトル: ログイン画面にパスワード再設定リンクを追加する
種別: type:feature
やってほしいこと:
ログインフォームの下部に「パスワードをお忘れの方はこちら」リンクを追加する
やってほしくないこと:
パスワード再設定画面の実装（別 Issue とする）
受入条件:
- [ ] ログイン画面にリンクが表示される
- [ ] リンク先は /password-reset に遷移する
- [ ] 型チェック・テストが通過する
Step 2｜司令塔エージェントが状況を判定して自走を開始する
指示者が Issue の内容を確認・承認した後、司令塔エージェントに実行を指示します。
/process-issue-handler #128
司令塔エージェントは「状況判断」の役割により、Issue 番号と現在ブランチから「新規着手」と判定。作業ブランチを自動作成し、type:feature に対応する手順計画プロンプトを読み込んで自走を開始します。
Step 3｜司令塔エージェントが作業手順書プロンプトを 1 つずつ実行する
司令塔エージェントの「手順の保証」により、手順計画プロンプトに定義された順番で作業手順書プロンプトが実行されます。「作業ログ」の役割により、各ステップの完了時に Issue へ進捗コメントが自動投稿されます。
[完了] 設計書・関連ファイルの確認
[完了] 着手アプローチを Issue に記録
↑ 指示者が確認・承認（ここで人間が介入）
[完了] テストケース設計
[完了] 実装（TDD）
[完了] 単体テスト
[完了] 品質チェック（型・Lint・ビルド）
[完了] PR 作成
↑ レビュアーへバトンタッチ（マージは人間が判断）
「スコープの番人」の役割により、仕様が曖昧な箇所・Issue に書かれていない変更が必要な場面では司令塔エージェントが自動停止し、指示者に Issue コメントで確認を求めます。
Step 4｜レビュアーが PR をレビューしてマージする
レビュアーが PR を確認し、問題なければマージします。マージ判断は常に人間が行います。Issue のクローズも受け入れ確認後に指示者が手動で行います。
中断・再開
作業を途中で止めるときは司令塔エージェントに「中断する」と伝えます。司令塔エージェントが進捗・残作業・次のアクションを Issue にコメントして待機します。
再開は新しいセッションで引数なしの 1 コマンドです。
/process-issue-handler
司令塔エージェントの「コンテキストの継承」が働き、現在ブランチから Issue 番号を検出して Issue 本文を再読。中断した作業手順書プロンプトの続きから自走を再開します。
良かったこと・課題
良かったこと
開発速度の向上
Issue を書けば実装・テスト・PR 作成まで AI が自走するため、単純な機能追加や定型的な修正では人間の手が関わる時間を大幅に削減できます。並行して複数 Issue を走らせることも可能です。
意思決定の記録が自動で残る
AI は仕様の確認・設計判断・変更履歴をすべて Issue にコメントとして記録します。後から「なぜこう実装したか」を追跡でき、チームの知識がコードに閉じず Issue に蓄積されます。
この記録はプロセス改善にも活用できます。「どの種別で手戻りが多いか」「どのステップで AI が頻繁に停止するか」「受入条件の不備がどのパターンで起きやすいか」といった傾向が Issue のコメント履歴から読み取れます。振り返り（/process-retrospective）でその知見を instructions や Issue テンプレートに反映することで、次の Issue から AI の精度が上がる PDCA サイクルが回ります。
一貫したプロセスの強制
テストケース設計・品質チェックなど省略しがちな工程を「必須・スキップ不可」として設計に組み込むことで、開発者ごとのばらつきをなくせます。
セッションをまたいだ作業継続
Issue 本文が引継ぎ書として機能するため、AI セッションが切れても再開コマンド 1 つでコンテキストを復元して続きから始められます。途中で仕様変更に気づいたときも割り込み対応することができます。
課題
Issue 記述品質への依存
AI の作業品質は Issue の書き方に強く依存します。受入条件が曖昧だと AI が推測で進んでしまい、手戻りが発生します。Issue テンプレートの整備と記述習慣の定着に一定のコストがかかります。
セットアップと継続的な改良コスト
agents / prompts / skills / instructions といったファイル群の初期整備に加え、運用を続ける中で「AI が迷った箇所」「手戻りが発生したパターン」をもとに prompts や instructions を随時改善していく必要があります。導入して終わりではなく、開発プロセスそのものを育てていく継続的な取り組みです。
想定外の逸脱への対処
AI が停止ポイントで立ち止まる設計でも、判断が難しいグレーゾーンでは不意に作業を進めてしまうことがあります。レビューで差分全体を確認する習慣は引き続き必要です。
プロセスの標準化スキルが求められる
このアプローチの品質は、チームがどれだけ「再現性のある手順」を言語化できるかに比例します。手順計画プロンプトや作業手順書プロンプトに曖昧さが残ると AI の動きもぶれます。「うまくいったやり方」を prompts に落とし込み、チーム全体で共有できる形に標準化する力が問われます。これはソフトウェア開発に限らず、業務プロセス設計の本質的なスキルでもあります。
まとめ
- 今まで、人が行ってきたように、AI駆動開発を行えるので、簡単にどんなプロジェクトだろうと基本的に始められました。
- たまに？、よく？、AIは勘違いをします。極端に視野が狭くなるときがあります。原因を聞いても、よくわからないいいわけです。改良方法を聞けば案も出してくれるので、もぐらたたき状態ではあるが、信頼性はあがっていきます。
- 業務アプリケーションを作ったノウハウをきちんと、プロセス定義することが重要です。AIにまけるな。
- AI に任せる範囲を「Issue に書いてあること」に限定するだけで、スコープクリープやハルシネーションが減りました。まずは Issue テンプレートの整備から始めてみることをお勧めします。