Codex のタスクを書く際の粒度は？
Codex（GitHub Copilot または GitHub Copilot Workspace など）を活用して開発タスクを扱う場合、「タスクの粒度」はAIによるコード生成の品質・効率性に大きく影響します。
なので、どの程度の粒度にすれば、機嫌よく動作してくれるか ChatGPT に聞いてみました。
ChatGPT 曰く：
Codex では 1つの機能や目的にフォーカスしたタスク が最も適しています。
これは「関数一つを書く」より少し大きく、「アプリ全体を作る」より小さい単位です。
| 分類 | 粒度（推奨） | 例 | コメント |
|---|---|---|---|
| メジャーバージョンアップ | ❌ 粗すぎる | 「.NET 8 に全体を移行」 | サブタスクに分解すべき |
| モジュール追加 | ✅ 適切 | 「ログイン機能の追加」 | 認証処理 + UI連携など複数関数含む |
| UI変更 | ✅ 適切〜やや細かめ | 「ユーザ設定画面にダークモードトグルを追加」 | 単一機能でも画面をまたぐ場合は丁度よい |
| バグ修正 | ⚠️ 細かすぎることもある | 「特定条件下でnull参照が発生」 | 複数バグをまとめて「例外処理の強化」などにするのが望ましいことも |
| リファクタリング | ✅ 適切 | 「StudentController の依存性注入対応」 | コード全体の構造改善に向く |
| テスト追加 | ✅ 適切 | 「LoginService のユニットテストを作成」 | コードの範囲が限定されていて明確 |
ステップ1: ゴールを明確に
「このタスクの完了条件は何か？誰が見ても分かるか？」を基準にする。
例：
❌ 「画面を整理」 → 抽象的すぎる
✅ 「ユーザー一覧にソート機能を追加する」
ステップ2: 時間で考える（作業時間ベース）
| 粒度 | 対象作業の目安時間 | コメント |
|---|---|---|
| ✅ 適切 | 30分〜2時間 | 1〜2個の主な関数・画面・ユースケースに対応 |
| ⚠️ 細かい | 5〜15分 | バグ修正はまとめるか、Issueコメントベースで管理 |
| ❌ 粗すぎ | 1日以上 | 複数タスクに分割しないとCodexのコンテキストが追いつかない |
💡 Codex との相性を高めるために
- ファイルや関数のスコープを限定するとCodexは精度を上げやすい。
- "○○をする関数を作成して" という明確な指示文にすると反応が良い。
- コードコメントや TODO リストを用意してから呼び出すと成功率が上がる。
まとめ
適切な粒度としては「1つのユースケース」または「1モジュール」「1画面」単位が理想で、あまり大規模な改修だと把握しきれずに適切な回答が出しにくくなるようです。
時間でいうと、30分〜2時間で完結するものが最適で、それ以下だと小さすぎ、それ以上だと大きすぎる、という感じだそうです。