AIコーディングエージェントを使い始めると、最初にぶつかるのは「何を任せればいいのか」という問題です。小さな修正なら自分で直したほうが早い。大きな機能を丸ごと任せると、差分が大きくなりすぎてレビューがつらい。便利そうなのに、いざ実務や個人開発に入れようとすると、使いどころが曖昧になりがちです。
この記事では、AIコーディングエージェントに任せるIssueの切り方を整理します。対象は、Codex、GitHub Copilot cloud agent、Cursor、Claude Codeなど、リポジトリを読み、計画を立て、コード変更やPR作成まで進めるタイプのAI開発支援ツールです。特定ツールの料金や細かな操作説明ではなく、「どう依頼すれば無駄なPRやレビュー負担を減らせるか」に絞ります。
結論から言うと、AIエージェントに渡すIssueは「小さく、検証しやすく、やらないことまで書く」のが大切です。これはAIに限らず、人間のチーム開発でも同じですが、AIエージェントでは特に効きます。なぜなら、AIは曖昧な依頼でも何かしら作業を進めてしまうからです。進める力があるぶん、依頼の境界線がぼやけていると、意図しない変更も増えます。
AIエージェントは「コード補完」から「作業委任」に近づいている
以前のAI開発支援は、エディタ内でコード候補を出す、関数を補完する、チャットで実装方針を聞く、といった使い方が中心でした。これは人間が手を動かしながら、横にAIがいる感覚です。
一方で、近年のAIコーディングエージェントは、もう少し「作業を渡す」形に近づいています。GitHubの公式ドキュメントでは、Copilot cloud agentがリポジトリを調査し、実装計画を作り、バグ修正、テストカバレッジ改善、ドキュメント更新、技術的負債への対応などを行えると説明されています。さらに、GitHub上でブランチを作り、変更し、PR作成前に人間がレビューや反復をできる流れも示されています。
Codexも同じく、単なるチャット相手ではなく、リポジトリを読んでファイル編集やコマンド実行を行う「作業者」として使えます。このブログ運用でも、調査メモ作成、記事本文のHTML化、WordPress下書き保存スクリプトの利用、保存後の確認などをCodexに任せています。ただし、公開、予約投稿、X投稿、Threads投稿のような外部公開操作は、人間確認を前提にルール化しています。
つまり、これからのAI活用では「プロンプトを上手く書く」だけでなく、「どの粒度の仕事を、どの条件で渡すか」が重要になります。これはIssue設計の話です。
AIエージェントに向かないIssueの特徴
AIエージェントに任せる前に、まず失敗しやすいIssueを見ておきます。よくあるのは、次のような依頼です。
- 目的が曖昧：「管理画面をいい感じに改善して」
- 変更範囲が広すぎる：「ブログ運用を全部自動化して」
- 完了条件がない：「使いやすくして」
- テストや確認方法がない：「問題なければOK」
- やらないことが書かれていない：「必要なら自由に変更して」
- 外部公開や認証情報の扱いが曖昧：「WordPressまで反映して」
人間の開発者なら、途中で「ここまでやっていいですか」と確認してくれるかもしれません。しかしAIエージェントは、与えられた文脈から推測して進めます。もちろん確認を求めることもありますが、曖昧なまま作業が広がるリスクは残ります。
AIエージェントによるPRの却下理由を分析した研究でも、実装が不完全だったり、アプローチが違ったり、CIやテストを通らなかったり、そもそも優先度が低かったりするケースが挙げられています。研究条件に依存するため数字だけを一般化するのは避けるべきですが、少なくとも「依頼の粒度」「制約」「検証方法」が弱いと、人間のレビュー負担が増えるという見方は実務感覚にも合います。
基本方針：小さく、検証しやすく、やらないことまで書く
AIエージェントに渡すIssueは、次の3つを満たすと扱いやすくなります。
1. 小さい
1つのIssueで、機能追加、UI改善、リファクタリング、テスト追加、ドキュメント更新を全部やらせると、差分が大きくなります。差分が大きくなるほど、人間のレビューは重くなります。AIに任せたはずなのに、最後の確認で時間を使いすぎる状態です。
まずは、「1つの目的」「1つの変更範囲」「1つの確認方法」に近づけます。たとえば、WordPress運用なら「下書き保存スクリプトにDryRun表示を追加する」「研究メモのチェック項目を1つ増やす」「X文案テンプレートにURLプレースホルダーを追加する」くらいの粒度です。
2. 検証しやすい
AIが作った変更を、人間がどう確認するかを書きます。テストコマンド、表示確認、ログ確認、APIのGET確認、ファイルの差分確認などです。Codexの公式マニュアルでも、再現手順や検証方法、lintやpre-commitの実行などを含めると出力品質が上がりやすいという趣旨の説明があります。
「動くようにして」ではなく、「このコマンドが成功すること」「このJSONにstatus=draftが返ること」「このファイルに3パターンの見出しがあること」のように書きます。AIにとっても、人間にとってもゴールが見えます。
3. やらないことまで書く
AIエージェントには、禁止事項も明示します。これはかなり重要です。たとえば、このブログ運用では、WordPress公開、予約投稿、X投稿、Threads投稿、秘密情報の直書きは禁止です。記事本文を作るタスクでも、公開操作には進ませません。
「やってほしいこと」だけを書くと、AIは周辺作業まで親切に進めようとすることがあります。だから「やらないこと」を書きます。たとえば、「既存の公開記事は変更しない」「新しいカテゴリは作らない」「本番DBには触らない」「APIキーを表示しない」「外部投稿は実行しない」といった形です。
AIエージェント向けIssueテンプレート
ここからは、実際に使えるIssueテンプレートです。毎回すべてを埋める必要はありませんが、AIに任せるタスクほど、空欄を減らすほうが安全です。
目的：
このIssueで達成したいことを1〜2文で書く。
背景：
なぜこの作業が必要か。関連する過去の不具合、運用ルール、ユーザーの困りごとを書く。
対象範囲：
今回触ってよい機能、画面、スクリプト、記事、ファイル範囲を書く。
変更してよいファイル：
- scripts/example.ps1
- docs/example.md
変更しないファイル：
- .env
- 公開済み記事
- 本番設定
やってほしいこと：
1. 具体的な作業1
2. 具体的な作業2
3. 確認用の出力やログを残す
やらないこと：
- 公開しない
- 予約投稿しない
- XやThreadsへ投稿しない
- 秘密情報を表示しない
- 関係ないリファクタリングをしない
確認方法：
- 実行するコマンド
- 確認するURL
- 期待する出力
完了条件：
- 何ができたら完了か
- 人間が何を見れば判断できるか
人間が最後に確認する点：
- 外部公開の有無
- 差分
- 表示
- セキュリティ
このテンプレートのポイントは、「変更しないファイル」と「やらないこと」を別にしている点です。AIに任せるときは、作業内容だけでなく、境界線をはっきりさせるほうがレビューしやすくなります。
WordPressブログ運用でのIssue例
このブログ運用を例にすると、AIエージェントに渡しやすいIssueは次のようになります。
目的：
WordPress下書き保存後の確認ログを見やすくする。
背景：
長文記事の保存では、本文保存、タグ更新、確認GETを分けている。
保存後にstatus、本文長、カテゴリ、タグ、featured_mediaをすぐ確認できるようにしたい。
対象範囲：
WordPress下書き保存スクリプトの出力だけ。
変更してよいファイル：
- scripts/save-wp-draft.ps1
- docs/wordpress-rest-api-save-flow.md
変更しないファイル：
- .env
- drafts/
- 公開済みWordPress記事
やってほしいこと：
1. 保存後確認のJSONにcontent_lengthとfeatured_mediaを含める。
2. docsに確認項目を追記する。
3. DryRun時の出力は壊さない。
やらないこと：
- WordPressへ公開しない。
- 予約投稿しない。
- XやThreadsへ投稿しない。
- .envの中身を表示しない。
確認方法：
powershell -ExecutionPolicy Bypass -File scripts/save-wp-draft.ps1 ... -DryRun
完了条件：
DryRunが成功し、変更内容がdocsに反映されている。
このくらい具体的に書くと、AIが作業しやすくなります。人間もレビュー時に「何を見ればよいか」が分かります。逆に、これを「WordPress保存を改善して」とだけ書くと、AIは本文保存方式、カテゴリ、タグ、画像、ログ、エラー処理など、いろいろな方向へ広げられます。
AGENTS.mdは毎回のIssueを軽くするために使う
毎回のIssueに全部のルールを書くのは大変です。そこで使えるのが、AGENTS.mdのようなプロジェクトルールです。Codexの公式マニュアルでは、Codexが作業前にAGENTS.mdを読み、グローバルな指示とプロジェクト固有の指示を組み合わせて扱う仕組みが説明されています。
このリポジトリでも、AGENTS.mdとdocs/runtime-rules.mdに、WordPressはdraftまで、公開しない、予約投稿しない、X投稿しない、秘密情報を直書きしない、といったルールを置いています。これにより、毎回のIssueでは「今回の個別タスク」に集中できます。
ただし、AGENTS.mdに書いたからといって、人間の確認が不要になるわけではありません。AIはルールを読んで作業しますが、最終的に外部公開や秘密情報、仕様変更が絡む部分は人間が確認するべきです。AGENTS.mdは安全装置であり、レビューの代わりではありません。
AIに任せやすいタスク、任せにくいタスク
AIエージェントに任せやすいのは、目的が明確で、確認方法があり、外部影響が小さいタスクです。
- ドキュメントの追記
- テンプレートの整備
- 小さなスクリプト修正
- ログ出力の改善
- テスト追加
- 既存パターンに沿ったリファクタリング
- 記事下書きのHTML整形
一方で、任せにくいのは、判断が大きいタスクです。
- 本番公開
- 認証情報や権限の変更
- 課金や料金が絡む設定
- 大幅な設計変更
- 顧客データや秘密情報を扱う作業
- 法務、税務、医療、安全性に関わる判断
AIエージェントは作業を進める力があります。だからこそ、任せる前に「これはAIに作業させてよい種類のタスクか」を見ます。AIに任せることと、人間が責任を持つことを分けるのが、実務導入ではいちばん大事です。
レビューするときに見るポイント
AIエージェントが作ったPRや差分を見るときは、コードの正しさだけでなく、依頼とのズレを見ます。おすすめは、次の順番です。
- Issueの目的に合っているか。
- 変更範囲が広がっていないか。
- やらないことを破っていないか。
- テストや確認方法が実行されているか。
- 秘密情報や外部公開につながる変更がないか。
- 人間が判断すべき仕様変更を勝手に決めていないか。
- コメントやドキュメントが実装と合っているか。
AIエージェントのPRは、見た目が整っていることがあります。説明も丁寧で、コミットメッセージも自然です。しかし、文章が自然だから正しいとは限りません。Issueで決めた完了条件に照らして、機械的に確認するほうが安全です。
AIエージェントは、Issueの切り方、リポジトリの整備、テストの有無、レビュー体制によって成果が変わります。ツール紹介をするなら、「導入前にIssueテンプレートとプロジェクトルールを整える」という流れに置くのが自然です。
このブログ運用で試したいこと
半農エンジニアラボの新しい方針では、当面「AI・SE仕事術」を最優先します。その方針に合わせるなら、このテーマはかなり相性がよいです。ブログ運用そのものが、AIエージェントに任せるタスクの実験場になっているからです。
今後試したいのは、次のような運用です。
- 記事案作成用Issueテンプレート
- WordPress下書き保存用Issueテンプレート
- 公開後SNS文案作成用Issueテンプレート
- 既存記事リライト用Issueテンプレート
- エラー復旧用Issueテンプレート
それぞれに「やらないこと」を明記します。記事案作成では本文を書かない。下書き保存では公開しない。SNS文案作成では投稿しない。リライトでは公開済み記事のURLや公開状態を勝手に変えない。エラー復旧では同じPOSTをすぐ繰り返さない。こうしたルールをIssueに入れると、AIに任せる範囲がはっきりします。
まとめ：AIに任せる前に、Issueを整える
AIコーディングエージェントは、コードを書く道具から、作業を委任する相手に近づいています。リポジトリを調べ、計画を立て、変更し、PRまで作れるようになるほど、依頼の出し方が重要になります。
AIに任せるIssueは、小さく、検証しやすく、やらないことまで書く。目的、背景、対象範囲、変更してよいファイル、変更しないファイル、確認方法、完了条件を明確にする。AGENTS.mdのような共通ルールで、毎回の依頼を軽くする。そして最後は、人間が差分、テスト、外部公開、秘密情報を確認する。
AIエージェントをうまく使う第一歩は、強いプロンプトを探すことではなく、良いIssueを切ることです。個人開発でも、WordPressブログ運用でも、この考え方はそのまま使えます。まずは次にAIへ依頼する作業を、テンプレートに沿って1つだけ小さく切ってみるところから始めてみましょう。
