AI coding agent に投げるタスクは小さすぎても大きすぎても高くつく

最近の coding agent は、もう「エディタで賢く補完してくれるもの」だけではなくなっています。

issue を渡す。agent が branch を切る。実装する。PR を出す。人間は diff とテスト結果を見る。

この流れになると、見ないといけないものが変わります。モデルが賢いかどうかより、どの粒度の仕事を投げると review できる PR になるかの方がだいぶ重要です。

雑に投げると、agent の作業時間より人間の review 時間の方が高くつきます。

agent のコストは token だけではない

usage-based billing の話が出てくると、つい「何 token 使ったか」「いくらかかったか」に目が行きます。もちろんそれも大事です。

でも frontend repo で実際にしんどいのは、たいていその後です。

• PR が大きすぎて読む気がなくなる
• 目的と関係ない component まで変わっている
• UI はそれっぽく動くが、どこを確認すればいいかわからない
• やり直しを頼むたびに diff が別方向へ広がる
• 結局、人間が巻き取って直す

これは課金とは別のコストです。review queue の詰まり、再実行、rollback、動作確認。そこまで含めて agent task のコストだと思った方がよいです。

小さすぎる task も意外と高い

agent には小さい仕事を渡せば安全、という感覚があります。半分正しいです。変更範囲が狭ければ review は楽になります。

ただし、小さすぎる task は固定費に負けます。

たとえばこれです。

button の margin を 4px だけ詰めて

人間なら 30 秒で直せるかもしれません。でも agent に渡すと、毎回こういう固定費が乗ります。

• repo を読む
• 該当 file を探す
• branch / diff を作る
• test や lint を必要に応じて回す
• PR description を書く
• 人間が diff を確認する

この固定費があるので、1px 修正、文言 1 個、import 整理だけを全部 agent queue に積むと、逆に遅くなります。

小さい task が向くのは、成功条件が明確で、同じ型を何度も繰り返す場合です。

全フォームの submit button に disabled 中の aria-busy を追加する。
対象は app 配下の form component のみ。
copy、routing、validation schema は変えない。

これは小さいけれど、agent に渡す価値があります。探索と反復があるからです。

大きすぎる task は review queue を壊す

逆に、こういう依頼はかなり危ない。

dashboard を使いやすくして

agent はたぶん何かを作ってくれます。layout を変える。card を分ける。色を調整する。state の持ち方まで変えるかもしれない。

問題は、PR が出たあとです。

frontend の変更は広がりやすいです。

• component
• route
• state
• CSS
• copy
• test
• mock data
• asset

これが一つの PR に混ざると、review する人間は「正しいか」ではなく「何が起きたか」から読み解くことになります。これは高い。

大きい task を投げたいなら、実装まで一気にやらせるより、最初に分解させた方が扱いやすいです。

まず dashboard 改善の調査だけしてください。
実装はしない。
現在の component 構成、状態管理、視覚的に詰まっている箇所、分割できる作業単位をまとめてください。

その後で、1 PR ずつ切る。

Task 1: KPI cards の mobile overflow だけ直す
Task 2: chart tooltip の currency format だけ直す
Task 3: empty state copy と icon だけ差し替える

agent に任せる単位は、agent が理解できる単位ではなく、人間が短時間で確認して戻せる単位にした方がよいです。

ちょうどいい task contract

自分なら、agent に投げる task は次の条件を見ます。

• 目的が 1 文で言える
• 触ってよい file / 触らない file がだいたい決まっている
• 成功条件を command や screenshot で確認できる
• 失敗したら branch ごと捨てられる
• review comment が 2 往復しても論点が増えすぎない

たとえば、frontend repo ならこのくらいが扱いやすいです。

Task:
- Fix the mobile header overflow on `/pricing`.
- Touch only header/navigation components and related CSS.
- Preserve desktop layout.
- Validate with Playwright screenshot at 390px and 1280px.
- Do not change copy or routing.

ポイントは「何をするか」だけではありません。

「何をしないか」と「どう確認するか」まで書くことです。

agent は良くも悪くも親切です。余白を直してと言ったら、ついでに見た目を整えることがあります。人間なら空気で止まるところを、agent は repo 全体の改善として解釈することがある。

だから、禁止事項を明示します。

Do not:
- change package.json
- change route structure
- rewrite shared Button component
- update unrelated tests

これを書くだけで、review の焦点がかなり絞れます。

最初に見るのは画面ではなく diff

UI task でも、最初に見るのは画面より diff でいいと思っています。

git diff --stat
git diff -- app components
git diff -- package.json pnpm-lock.yaml

header overflow の修正なのに package.json が変わっていたら、まず止めます。dependency が本当に必要なら説明できるはずです。説明できないなら、たぶん余計な変更です。

git diff --stat は雑に見えて便利です。

 app/components/Header.tsx      |  18 ++++++---
 app/components/NavMenu.tsx     |  12 ++++--
 app/styles/navigation.css      |  24 ++++++++++--
 package.json                   |   1 +
 pnpm-lock.yaml                 | 340 +++++++++++++++++++++++++++++

この diff なら、まず lockfile を疑います。

逆に、こういう diff なら review に入りやすい。

 app/components/Header.tsx      | 18 ++++++++++----
 app/components/NavMenu.tsx     | 12 ++++++---
 app/styles/navigation.css      | 24 +++++++++++++-----

範囲が task contract と合っているからです。

UI 変更は screenshot を成功条件に入れる

frontend の task は、test が通っても UI が壊れていることがあります。

なので、UI 変更を agent に投げるなら viewport を指定した方がよいです。

Validate:
- /pricing at 390x844
- /pricing at 1280x800
- header menu can open and close
- no horizontal scroll on mobile

Playwright があるなら、最低限これくらいの spec を追加させてもいいです。

import { expect, test } from "@playwright/test";

test("pricing header does not overflow on mobile", async ({ page }) => {
  await page.setViewportSize({ width: 390, height: 844 });
  await page.goto("/pricing");

  await expect(page.getByRole("banner")).toBeVisible();
  await expect(page.locator("body")).not.toHaveCSS("overflow-x", "scroll");
});

実際には overflow-x の検出は project ごとに調整が必要です。そこは雑でいい。大事なのは、agent と人間が同じ画面を見られる状態にすることです。

次の依頼も楽になります。

前回追加した pricing header の mobile check が通る範囲で、
menu button の tap target だけ 44px にしてください。

こうなると、agent は作業しやすいし、人間も止めやすい。

「失敗したら捨てられる」単位にする

agent task の良し悪しは、成功時より失敗時に出ます。

良い task は、失敗したときに branch ごと捨てられます。

git switch main
git branch -D agent/pricing-header-overflow

これで済むなら安いです。

悪い task は、失敗した branch から使えそうな変更だけ拾うことになります。

• この CSS は使える
• でも component 分割は戻したい
• test は参考になる
• copy は勝手に変わっている
• lockfile は不要

こうなると、もう agent に任せた意味が薄い。人間が merge conflict と選別をやっています。

だから task は「実装できるか」より「捨てられるか」で切るのが実務的です。

agent queue として見る

Copilot、Codex、Claude Code の比較は面白いです。どれが速いか、どれが repo を読めるか、どれが自然な diff を出すか。

でも、非同期 agent の本質は IDE 比較だけでは見えません。

実際に運用すると、問題は queue になります。

• どの task を先に投げるか
• どの PR から review するか
• どこで stop するか
• 失敗した task を再実行するか、捨てるか
• 同じ area に複数 agent を触らせないか

ここを決めないと、agent は動いているのに人間が詰まります。

自分なら、frontend repo の agent queue はこう分けます。

Good:
- scoped bug fix with known route
- repeated mechanical migration
- test addition for existing behavior
- small UI correction with screenshot target
- docs update tied to changed behavior

Risky:
- vague redesign
- cross-cutting state refactor
- dependency upgrade plus UI fix
- "make it cleaner" style cleanup
- performance improvement without baseline

特に dependency upgrade plus UI fix は分けた方がいいです。失敗したときに原因が読めなくなります。

task template

最後に、自分が使うならこの形にします。

Goal:
- Fix mobile overflow in the pricing header.

Allowed scope:
- app/components/Header.tsx
- app/components/NavMenu.tsx
- app/styles/navigation.css

Do not change:
- package.json
- routes
- copy
- shared Button component

Validation:
- pnpm test
- pnpm exec playwright test pricing
- screenshot /pricing at 390x844 and 1280x800

Review notes:
- Explain changed files.
- List anything you could not validate.
- Stop if the fix requires changing shared layout primitives.

この Stop if がけっこう効きます。

agent にも「ここから先は勝手に進まないでいい」と伝えた方がいい。人間の開発でも同じです。調査してみたら思ったより大きい問題だった、ということは普通にあります。

そのときに無理やり PR を完成させるより、止まって報告してくれる方が助かります。

まとめ

agent に任せる仕事は、小さいほど安全というわけではありません。

小さすぎる task は固定費に負けます。大きすぎる task は review queue を壊します。

ちょうどいい粒度は、agent が実装できる単位ではなく、人間が短時間で確認して、だめなら branch ごと捨てられる単位です。

AI coding agent を開発フローに入れるなら、prompt の上手さだけでは足りません。task contract、diff の見方、screenshot の成功条件、stop rule。ここまで含めて設計した方が、たぶん長く使えます。

Source notes

• GitHub Copilot coding agent docs: issue から branch / PR まで進む非同期 agent workflow の前提確認。
• GitHub Copilot usage-based billing note: agent 利用を「無料の補完」ではなく、使用量と運用コストを持つ作業として見るための背景。
• OpenAI Codex and Claude Code docs: repo、task、diff、validation をまたぐ coding agent の作業面を把握するための補助線。