AIエージェントに任せるIssueは、小さく切るほどチーム開発で扱いやすかった

はじめに

AIコーディングエージェントをチーム開発で使うと、実装そのものはかなり速く進みます。

ただ、2025年に実際に使っていて感じたのは、AIに大きなIssueをそのまま渡すと、成果物よりも確認コストのほうが重くなることがある、ということでした。

この記事では、AIエージェントに任せるIssueをどう小さく切ると扱いやすかったかをまとめます。

大きなIssueを渡して困ったこと

最初は、人間に渡すのと同じ粒度でAIにも依頼していました。

設定画面の使い勝手を改善してください。
関連するUIと保存処理も必要に応じて直してください。

この依頼でも、AIはそれらしい変更を出してくれます。

でも、レビューする側から見ると、次のような問題が起きました。

• UI変更、状態管理、API呼び出し、文言修正が一つの差分に混ざる
• どこまでが必要な変更で、どこからがAIの判断なのか分かりにくい
• テストで確認する範囲が広がる
• レビューコメントが設計、実装、表現の話に散らばる

大きなIssueは、人間にとっても難しいです。

AIの場合は、その難しさが「速く大きな差分が出る」という形で表面化しました。

小さく切る基準

そこから、AIに渡す前にIssueを次の単位へ分けるようにしました。

## 1. 表示だけを変える

- ラベル文言を変更する
- 補足テキストを追加する
- 保存処理には触らない

## 2. 入力状態だけを整理する

- 未入力時のdisabled制御を追加する
- バリデーション文言は既存のものを使う
- API仕様は変えない

## 3. 保存後の挙動だけを直す

- 成功時の通知を出す
- 失敗時は既存エラー表示を維持する
- UIレイアウトは変えない

ポイントは、作業量で切るのではなく、レビュー観点で切ることです。

「30分で終わりそうか」よりも、「レビュー時に何を見ればよいかが一言で言えるか」を基準にしたほうが、チームでは扱いやすくなりました。

Issueに書くようにしたこと

小さく切ったIssueには、最低限これだけを書くようにしました。

## 目的

このIssueで改善したいこと

## やること

- 今回変更する範囲

## やらないこと

- 今回は触らない範囲

## 確認観点

- レビューで重点的に見ること
- 動作確認で見ること

特に効いたのは、やらないこと です。

AIは、関連していそうな箇所を広めに直そうとします。良い方向に働くこともありますが、チーム開発では差分の意図がぼやけます。

そのため、あらかじめ「今回は触らない」と書いておくと、AIの出力もレビューもかなり安定しました。

小さく切りすぎたときの問題

もちろん、細かくすればするほど良いわけではありません。

小さく切りすぎると、今度は次の問題が出ます。

• Issue間の依存関係が増える
• 同じファイルを何度も触る
• レビューやマージの回数が増える
• 全体として何を改善しているのか見えにくくなる

自分の場合は、次の条件を満たすくらいの粒度がちょうどよかったです。

• 1つのPRでレビュー観点が2つ以内
• 主要な変更ファイルが数個に収まる
• 動作確認の手順を短く書ける
• 失敗しても戻しやすい

このくらいにしておくと、AIの実装速度を活かしつつ、人間のレビュー負荷も抑えやすくなります。

AIに渡す前のチェック

Issueを作ったあと、AIに渡す前に次の3つだけ確認するようにしました。

- 何を変えるIssueか、一文で言えるか
- 何を変えないIssueか、明示されているか
- 完了条件をレビューする人が判断できるか

この3つが曖昧なまま依頼すると、AIは実装で空白を埋めます。

逆に、ここが書けていると、AIの出力が多少ずれても「どこがずれたのか」を指摘しやすくなります。

まとめ

AIエージェントに任せるIssueは、大きな目的をそのまま渡すよりも、レビューできる単位に切ったほうが扱いやすかったです。

大事なのは、AIを細かく管理することではありません。

人間があとから判断できる差分に保つことです。

実装を速くするだけなら、AIに広く任せるほうが楽に見えます。

でも、チーム開発では、速く作ることと同じくらい、速く確認できることが効いてきます。

Issueを小さく切るのは、そのための地味だけど効く準備だと思います。

関連記事

「Issueの切り方」を、AIエージェントが迷わないリポジトリ構造の設計として捉え直すと、もう一段やることが見えてきます。背景と合わせて読みたい記事を挙げます。

• 作業コンテキストの外部化など、AIが迷わない構造を4パターンで整理: AIが迷わないリポジトリ設計――agent legibility を実装に落とす4つのパターン（Growth Lab）
• 「速く作る」と同じくらい「速く確認できる」が効く理由: AI生産性のパラドックス：なぜ「速くなった」のにチケットが消えないのか（Growth Lab）