作りたいアイデアはメモ帳にたまっていくのに、実際に形になるのはほんの数個ですよね。この記事では、アイデアメモ1枚をエージェントが終えられるIssueに分解し、1つずつ任せて検証まで終えるAIエージェントのワークフローを整理しました。アイデアメモの例、分解用の指示文、完成したIssueの形まで、そのまま真似して使えるようにまとめています。
以前は、企画エージェントや開発エージェントのように役割を分けた組織図を作り、フォルダを監視するパイプラインを組もうとしていました。その設計は実際には動きませんでした。理由はAIエージェント自動化の事例4つ、対話ではなく目標を任せるにまとめています。この記事は、そのあとに切り替えたやり方です。
役割の組織図ではなく、4つのステップの流れで考える#
エージェントに肩書きを付けることより大事なのは、仕事がどの文書を通って終わるのかです。流れは4ステップで十分です。
| ステップ | 誰が | 残るもの |
|---|---|---|
| 1. アイデア | 自分 | アイデアメモ1枚 |
| 2. 分解 | 自分 + エージェント（対話） | 完了条件付きのIssue |
| 3. 実行 | エージェント（Issueを1つずつ） | ブランチとPR |
| 4. 検証 | テスト + 自分 | マージされたコード |
人が担うのは、何をなぜ作るかを決めることと、終わったかを確かめることです。分解の下書きと実装はエージェントが担います。記憶は対話ではなく、メモ、Issue、gitに残します。
ステップ1：アイデアメモには「なぜ」と「やらないこと」を書く#
アイデアメモは短くて構いません。ただ、3つは必ず入れます。たとえばアプリにソーシャルログインを付けたいなら、こう書きます。
# ソーシャルログインの導入
## やりたいこと
カカオとAppleのログインをアプリに付けたい。
## なぜ
ユーザーがもっと手軽に登録できるようにしたい。
## やらないこと
- 今回は既存のメールアカウントとソーシャルアカウントを統合しない
- Googleログインは次回にするカカオ（Kakao）は韓国で最も使われているメッセンジャーで、日本でいえばLINEログインにあたります。
- やりたいこと — 何を作るかを1〜2文で書きます。
- なぜ — エージェントがあいまいな箇所で判断する基準になります。これがないと、エージェントはいちばんそれらしい方向に推測します。
- やらないこと — 範囲を区切ります。エージェントは頼んでいないことまで親切にやってしまうことが多いからです。
どう作るかは書かなくて大丈夫です。それは次のステップでエージェントと一緒に決めます。
ステップ2：AIエージェントと対話しながらIssueに分解する#
分解は自動で回すより、対話でやるほうが向いています。アイデアをどの単位に分けるかは判断が多い作業なので、エージェントが下書きを出し、人がすぐ直すほうが速いからです。継続的に回る自動化ループでも、仕様だけはまず対話で作っておくことが多いです。
Claude CodeやCodexのようなコーディングエージェントに、アイデアメモと一緒にこんな指示文を渡します。
添付したアイデアメモをIssueの下書きに分解して。
- Issue 1つは、PR 1つで終わる大きさに分ける。
- Issueごとに目標、文脈、完了条件、検証方法、やらないことを書く。
- 完了条件は「できる／できない」で確認できる文で書く。
- 完了条件が書けないなら、さらに細かく分解する。
- 文脈には元のアイデアメモへのリンクを入れる。
- まだIssueは作らず、下書きだけ見せる。最後の1行が大事です。下書きを読んで直すこの瞬間が、人が介入するいちばん安いポイントです。ここであいまいなIssueを取り除いておけば、あとで成果物をつかんで直す時間が大きく減ります。
完了条件付きのIssueはこんな形になる#
上のアイデアなら、画面の作業とサーバーの作業に分かれるでしょう。画面側のIssueはこんな形になります。
# カカオログインUIの実装
## 目標
ログイン画面からカカオアカウントでログインを始められるようにする。
## 文脈
- アイデアメモ：ideas/social-login.md
- サーバー連携は別のIssueで行う
## 完了条件
- ログイン画面にカカオログインボタンが表示される
- ボタンを押すとカカオの認証画面に遷移する
## 検証方法
- ログイン画面のテストを追加して通す
- 実行画面のスクリーンショットをPRに添付する
## やらないこと
- 既存のメールログイン画面のレイアウトは変えないこのIssue本文の構成は、ObsidianのノートをAIエージェントの作業指示書として使うで使っていた目標、文脈、完了条件、やらないことの構成に、検証方法を加えたものです。文脈にアイデアメモのリンクを残しておけば、Issueがいくつに分かれても、どのアイデアから生まれたのかを逆にたどれます。
任せる前に確認すること#
- 完了条件は確認できる文になっているか？
- PR 1つで終わる大きさか？
- 任せたあとに付け足すべきことが残っていないか？
3つ目が意外と大事です。GitHub Copilotは、Issueを割り当てられたあとに付いたコメントを見られないと公式ドキュメントに書かれています。伝えたいことは、任せる前にIssue本文にすべて書いておく必要があります。
ステップ3：Issueを1つずつエージェントに任せる#
Issueが準備できたら、実行はすでに使っているツールの上で行えば大丈夫です。フォルダ監視や割り当てエンジンを新しく作る必要はありません。
- GitHub Issue — Assigneesに Copilot を指定するか、Issueのコメントで
@claudeをメンションすると、エージェントがブランチを作って作業し、PRで返してくれます。 - Issueトラッカー型のツール — Multicaのようなツールでは、Issueをエージェントに割り当てて実行します。
- 自分のPCで直接 — コーディングエージェントにIssue本文をそのまま渡して実行します。
どれを選んでも原則は同じです。一度にIssueは1つだけ任せます。一度にたくさん頼むと、エージェントが途中でコンテキストを使い切り、作りかけのまま終わりがちです。
複数のIssueを自分のPCで同時に回したいなら、Git Worktree（ワークツリー）を使います。ワークツリーは、同じリポジトリをブランチごとに別フォルダへ取り出して使えるGitの機能です。エージェントごとにフォルダが分かれるので、お互いのファイルを上書きしません。
ステップ4：終わったかどうかはエージェントの言葉ではなく検証で判断する#
エージェントが「終わりました」と言っても、そのまま信じてはいけません。Issueに書いた検証方法が判断基準です。
- 自動検証 — テスト、静的解析、型チェックが、間違った結果を先にはじきます。CIに組み込めば、PRごとに自動で回ります。
- 人のレビュー — PRで完了条件を1つずつ照らし合わせ、スクリーンショットや実行結果を確認してからマージします。
- 同じミスが繰り返されたら指示ファイルを直す — リポジトリの
CLAUDE.mdのようなルールファイルに1行足せば、次のIssueからは同じミスが減ります。
Issueがすべてマージされたら、アイデアメモに「完了」とPRのリンクを残します。そうすれば、アイデアメモ1枚が何をなぜ作り、どこで確認できるかまで含んだ記録になります。
自動化は、繰り返す仕事にだけあとから付ける#
最初から、アイデアを入れれば勝手に回るパイプラインを作りたくなりますよね。でも、自動化ツールそのものを管理するコストは思った以上に大きいです。次の順で小さく始めてみてください。
- アイデアメモを1つ、上の形式で書きます。
- エージェントと対話してIssueの下書きを受け取り、自分で読んで直します。
- Issueを1つエージェントに任せ、検証方法どおりに確認してからマージします。
- 同じ種類の仕事が繰り返し発生するときだけ、予約実行やMulticaのAutopilotsのような機能でその仕事を自動化します。
アイデアを最後まで形にするのは、自動化の量ではない#
アイデアを実際の成果物につなげたのは、大がかりなエージェントの組織ではありませんでした。完了条件が書かれたIssueと、検証で終わりを判断する習慣でした。この2つがあれば、一人でも、エージェント1つでも、アイデアがコードまでたどり着きます。
頭の中にだけあったアイデアを1つ、今日メモに書き、エージェントからIssueの下書きをもらうところから始めてみてください。
He who has imagination without learning has wings but no feet.
— Joseph Joubert
