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も同じく、単なるチャット相手ではなく、リポジトリを読んでファイル編集やコマンド実行を行う「作業者」として使えます。たとえば社内ツールの保守では、仕様確認、影響範囲の洗い出し、テスト追加、ドキュメント更新、レビュー前の自己点検などをAIエージェントに任せられます。ただし、本番反映、外部送信、削除、権限変更のような戻しにくい操作は、人間確認を前提にルール化しておく必要があります。
つまり、これからのAI活用では「プロンプトを上手く書く」だけでなく、「どの粒度の仕事を、どの条件で渡すか」が重要になります。これはIssue設計の話です。
AIエージェントに向かないIssueの特徴
AIエージェントに任せる前に、まず失敗しやすいIssueを見ておきます。よくあるのは、次のような依頼です。
- 目的が曖昧：「管理画面をいい感じに改善して」
- 変更範囲が広すぎる：「管理画面を全部作り直して」
- 完了条件がない：「使いやすくして」
- テストや確認方法がない：「問題なければOK」
- やらないことが書かれていない：「必要なら自由に変更して」
- 外部公開や認証情報の扱いが曖昧：「WordPressまで反映して」
人間の開発者なら、途中で「ここまでやっていいですか」と確認してくれるかもしれません。しかしAIエージェントは、与えられた文脈から推測して進めます。もちろん確認を求めることもありますが、曖昧なまま作業が広がるリスクは残ります。
AIエージェントによるPRの却下理由を分析した研究でも、実装が不完全だったり、アプローチが違ったり、CIやテストを通らなかったり、そもそも優先度が低かったりするケースが挙げられています。研究条件に依存するため数字だけを一般化するのは避けるべきですが、少なくとも「依頼の粒度」「制約」「検証方法」が弱いと、人間のレビュー負担が増えるという見方は実務感覚にも合います。
基本方針：小さく、検証しやすく、やらないことまで書く
AIエージェントに渡すIssueは、次の3つを満たすと扱いやすくなります。
1. 小さい
1つのIssueで、機能追加、UI改善、リファクタリング、テスト追加、ドキュメント更新を全部やらせると、差分が大きくなります。差分が大きくなるほど、人間のレビューは重くなります。AIに任せたはずなのに、最後の確認で時間を使いすぎる状態です。
まずは、「1つの目的」「1つの変更範囲」「1つの確認方法」に近づけます。たとえば、業務ツールなら「通知処理にDryRun表示を追加する」「仕様メモのチェック項目を1つ増やす」「PR説明テンプレートに確認手順を追加する」くらいの粒度です。
2. 検証しやすい
AIが作った変更を、人間がどう確認するかを書きます。テストコマンド、表示確認、ログ確認、APIのGET確認、ファイルの差分確認などです。Codexの公式マニュアルでも、再現手順や検証方法、lintやpre-commitの実行などを含めると出力品質が上がりやすいという趣旨の説明があります。
「動くようにして」ではなく、「このコマンドが成功すること」「このJSONにstatus=draftが返ること」「このファイルに3パターンの見出しがあること」のように書きます。AIにとっても、人間にとってもゴールが見えます。
3. やらないことまで書く
AIエージェントには、禁止事項も明示します。これはかなり重要です。たとえば、業務システムの保守では、本番反映、予約実行、外部送信、削除、秘密情報の直書きは禁止にしておくと安全です。ドキュメントを作るタスクでも、外部公開や本番操作には進ませません。
「やってほしいこと」だけを書くと、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に任せるときは、作業内容だけでなく、境界線をはっきりさせるほうがレビューしやすくなります。
業務ツール改善でのIssue例
例として、社内の問い合わせ管理ツールに「未対応チケットの通知を追加する」Issueを考えます。AIエージェントに頼むなら、目的、変更対象、やらないこと、確認方法を先に分けて書くとレビューしやすくなります。
- 目的：未対応チケットが一定時間残ったとき、担当者に通知する。
- 変更対象：通知判定のサービス層、既存テスト、設定値の説明。
- やらないこと：画面デザインの全面変更、権限設計の変更、本番通知の即時有効化。
- 確認方法：既存テスト、追加テスト、通知先をダミーにした動作確認。
このくらいまで切っておくと、AIが余計な範囲へ広げたときに止めやすくなります。Issueは命令文というより、レビュー基準を先に共有するための設計書に近いです。
AGENTS.mdは毎回のIssueを軽くするために使う
毎回のIssueに全部のルールを書くのは大変です。そこで使えるのが、AGENTS.mdのようなプロジェクトルールです。Codexの公式マニュアルでは、Codexが作業前にAGENTS.mdを読み、グローバルな指示とプロジェクト固有の指示を組み合わせて扱う仕組みが説明されています。
たとえば業務リポジトリでは、AGENTS.mdのようなルールファイルに、本番反映しない、削除しない、外部送信しない、秘密情報を直書きしない、といった条件を置けます。これにより、毎回のIssueでは「今回の個別タスク」に集中できます。
ただし、AGENTS.mdに書いたからといって、人間の確認が不要になるわけではありません。AIはルールを読んで作業しますが、最終的に外部公開や秘密情報、仕様変更が絡む部分は人間が確認するべきです。AGENTS.mdは安全装置であり、レビューの代わりではありません。
AIに任せやすいタスク、任せにくいタスク
AIエージェントに任せやすいのは、目的が明確で、確認方法があり、外部影響が小さいタスクです。
- ドキュメントの追記
- テンプレートの整備
- 小さなスクリプト修正
- ログ出力の改善
- テスト追加
- 既存パターンに沿ったリファクタリング
- 記事下書きのHTML整形
一方で、任せにくいのは、判断が大きいタスクです。
- 本番公開
- 認証情報や権限の変更
- 課金や料金が絡む設定
- 大幅な設計変更
- 顧客データや秘密情報を扱う作業
- 法務、税務、医療、安全性に関わる判断
AIエージェントは作業を進める力があります。だからこそ、任せる前に「これはAIに作業させてよい種類のタスクか」を見ます。AIに任せることと、人間が責任を持つことを分けるのが、実務導入ではいちばん大事です。
レビューするときに見るポイント
AIエージェントが作ったPRや差分を見るときは、コードの正しさだけでなく、依頼とのズレを見ます。おすすめは、次の順番です。
- Issueの目的に合っているか。
- 変更範囲が広がっていないか。
- やらないことを破っていないか。
- テストや確認方法が実行されているか。
- 秘密情報や外部公開につながる変更がないか。
- 人間が判断すべき仕様変更を勝手に決めていないか。
- コメントやドキュメントが実装と合っているか。
AIエージェントのPRは、見た目が整っていることがあります。説明も丁寧で、コミットメッセージも自然です。しかし、文章が自然だから正しいとは限りません。Issueで決めた完了条件に照らして、機械的に確認するほうが安全です。
AIエージェントは、Issueの切り方、リポジトリの整備、テストの有無、レビュー体制によって成果が変わります。ツール紹介をするなら、「導入前にIssueテンプレートとプロジェクトルールを整える」という流れに置くのが自然です。
小さな開発チームで試したいこと
この考え方を実務に寄せるなら、いきなり大きな機能を任せるより、定型的で確認しやすいIssueから始めるのが現実的です。
- 既存テストの不足を1ケースだけ補うIssue
- エラーメッセージを分かりやすくするIssue
- 設定値の説明をREADMEへ追記するIssue
- 小さなバグ修正と再現手順の整理Issue
- ログ出力を既存方針に合わせて見直すIssue
それぞれに「やらないこと」を明記します。画面仕様は変えない。本番データは触らない。新しい依存関係は追加しない。外部送信はしない。こうした停止線があるだけで、AIエージェントの作業はかなり扱いやすくなります。
まとめ：AIに任せる前に、Issueを整える
AIコーディングエージェントは、コードを書く道具から、作業を委任する相手に近づいています。リポジトリを調べ、計画を立て、変更し、PRまで作れるようになるほど、依頼の出し方が重要になります。
AIに任せるIssueは、小さく、検証しやすく、やらないことまで書く。目的、背景、対象範囲、変更してよいファイル、変更しないファイル、確認方法、完了条件を明確にする。AGENTS.mdのような共通ルールで、毎回の依頼を軽くする。そして最後は、人間が差分、テスト、外部公開、秘密情報を確認する。
AIエージェントをうまく使う第一歩は、強いプロンプトを探すことではなく、良いIssueを切ることです。個人開発でも、小さな業務ツールの保守でも、この考え方はそのまま使えます。まずは次にAIへ依頼する作業を、テンプレートに沿って1つだけ小さく切ってみるところから始めてみましょう。
