このシリーズでは、AIエージェントを開発工程に入れる方法を書いてきました。
最後に、導入の判断基準をまとめます。
どの作業から始めるべきか。
どこまで任せてよいか。
まだ任せない方がよい作業は何か。
チームで使うなら、何を先に整えるべきか。
AIエージェントは、使うだけなら簡単です。
難しいのは、日常の仕事に入れることです。
最初に任せるべき仕事
最初から重要な本番作業を任せる必要はありません。
最初に向いているのは、失敗しても戻しやすく、成果物を人間が確認しやすい仕事です。
たとえば、
- 既存リポジトリの read-only 調査
- 入口ファイルの整理
- 既存テストの調査
- docs の要約
- issue の整理
- PR説明文の下書き
- review checklist の作成
- failing test の候補作成
- エラーログの時系列整理
- バグ報告の整形
これらは、agent が間違えても人間が直しやすい。
しかも、すぐ役に立ちます。
最初から「機能を丸ごと作って」ではなく、「人間が判断しやすい材料を作って」から始める。
これが一番安定します。
4段階で考える
任せ方は、4段階に分けます。
Level 1: 読ませる
Level 2: 下書きさせる
Level 3: 限定して変更させる
Level 4: 承認付きで外部状態を変える
Level 1 は read-only です。
調査、要約、入口探し、ログ整理。
Level 2 は draft です。
PRコメント案、仕様書案、修正計画、runbook 案。
Level 3 は limited write です。
指定ファイルだけ変更、テストだけ追加、docs だけ更新。
Level 4 は approval required です。
外部サービスへの投稿、ticket 更新、PR作成、staging 操作。
最初は Level 1 と Level 2 だけで十分です。
慣れてから Level 3。
Level 4 は最後です。
任せてよい作業の条件
AIエージェントに任せやすい作業には、条件があります。
- 目的が明確
- 変更範囲が小さい
- 既存パターンがある
- テストで確認できる
- rollback しやすい
- review しやすい
- secret / PII を扱わない
- 本番状態を変えない
この条件に多く当てはまるほど、任せやすいです。
例：
- 文言修正
- docs 更新
- 小さなUI修正
- テスト追加
- 既存パターンに沿ったAPI修正
- lint / type error の局所修正
- 既存ログの整理
逆に、条件から外れるほど慎重にします。
まだ任せない方がいい作業
次の作業は、最初から任せない方がいいです。
- production deploy
- production DB write
- user data delete
- billing 変更
- 権限変更
- 認証設計の大きな変更
- 暗号化、鍵管理、secret rotation
- legal / compliance 判断
- 大きなDB migration
- 仕様が固まっていない大規模改修
これらは、agent が役に立たないという意味ではありません。
直接実行させない方がいい、という意味です。
任せるなら、材料作りにします。
deploy checklist を作る。
migration risk を整理する。
権限変更の影響範囲を洗い出す。
仕様の未決定点を列挙する。
review 観点を作る。
rollback plan を作る。
最後の判断と実行は、人間か既存の承認フローに残します。
導入は「便利そうな作業」から始めない
AIエージェント導入で失敗しやすいのは、便利そうなところから始めることです。
大きな機能を丸ごと作らせよう。
溜まったissueを全部処理させよう。
テスト不足の箇所を一気に直させよう。
気持ちは分かります。
でも、最初にやるには大きすぎます。
導入初期に見るべきなのは、便利さより管理しやすさです。
小さい
戻せる
見られる
測れる
繰り返せる
この5つを満たす作業から始めます。
最初の2週間でやること
チームで始めるなら、最初の2週間はこれで十分です。
1. AGENTS.mdを作る
最低限でいいです。
## Commands
- test:
- typecheck:
- lint:
## Boundaries
- secret を読まない
- production DB に触らない
- package追加は確認
- migration は確認
## Workflow
- 実装前にPlanを出す
- Bug fix 前に再現条件を出す
- 修正後に関連テストを実行する
2. read-only調査から始める
最初のタスクは、実装ではなく調査にします。
この機能の入口と既存テストを調べてください。
まだ変更しないでください。
3. 小さなテスト追加を任せる
次に、テストだけ追加します。
このバグを再現する failing test だけ追加してください。
実装は変更しないでください。
4. 小さな修正を任せる
対象ファイルを限定します。
この2ファイルだけ変更してください。
refactor はしないでください。
5. review checklistを作る
毎回見るものを固定します。
- 変更範囲は広すぎないか
- テストを消していないか
- 権限、DB、課金に触っていないか
- 既存パターンに沿っているか
これで十分に始められます。
成功指標を決める
導入の効果は、「AIを何回使ったか」では見ません。
見るべきなのは、仕事が安定したかです。
たとえば、
- 調査時間が短くなったか
- review の入口が分かりやすくなったか
- failing test が増えたか
- 同じ指摘が減ったか
- PRの変更範囲が小さくなったか
- AGENTS.md / checklist が育っているか
- incident runbook が増えているか
- 人間が判断すべき点が明確になったか
速さだけを見ない方がいいです。
速く雑になるなら、導入としては失敗です。
速く、見やすく、戻しやすくなる。
ここを見ます。
コストを見る
AIエージェントにはコストがあります。
利用料金だけではありません。
- review コスト
- 失敗時の戻しコスト
- context を整えるコスト
- tool 権限管理のコスト
- テスト整備のコスト
- team rule を保守するコスト
これを見ないと、「生成は速いが後処理が重い」状態になります。
導入初期は、次を記録します。
Task:
Agent used:
Human time saved:
Human review time:
Tests added:
Rollback needed:
What to improve next:
ざっくりでいいです。
記録があると、どの作業に向いているか見えてきます。
人間が持つべき仕事
AIエージェントを入れても、人間の仕事は残ります。
むしろ、はっきりします。
人間が持つべきもの：
- 目的
- 優先順位
- 許容リスク
- ユーザー体験の判断
- 仕様の決定
- 本番反映の承認
- セキュリティと権限の線引き
- やらない判断
agent に向いているもの：
- 調査
- 下書き
- 再現
- 小さな実装
- テスト追加
- 差分整理
- checklist 作成
- runbook 更新案
この分担ができると、agent はかなり強い味方になります。
逆に、人間の判断まで曖昧なまま agent に投げると、結果も曖昧になります。
事故時の戻し方を決める
導入前に、事故時の戻し方も決めます。
## Rollback Policy
- agent の変更は必ず diff で review する。
- 大きな変更は1PRにまとめない。
- production 操作は agent に直接させない。
- 外部tool使用はログを残す。
- 問題が出たら、変更を revert する前に原因を記録する。
- 再発防止は AGENTS.md / checklist / test に戻す。
事故をゼロにすることはできません。
でも、戻しやすくすることはできます。
戻しやすい作業から任せる。
これが導入の基本です。
よくある失敗
よくある失敗を挙げます。
1. いきなり大きな仕事を任せる
最初から大規模改修を任せると、review が詰まります。
小さく始めます。
2. AGENTS.mdがない
毎回同じ注意をチャットで書くことになります。
最低限のルールだけでも置きます。
3. reviewしない
AIが書いたから速い、で merge すると危ないです。
diff review、test、境界確認を入れます。
4. tool権限を広げすぎる
read-only と write を分けないと、外部状態が変わります。
最初は read-only。
5. 成功を速度だけで見る
生成速度だけを見ると、レビュー負債に気づきません。
見やすさ、戻しやすさ、再発防止まで見ます。
導入判断表
最後に、任せ方の判断表です。
| 作業 | 任せ方 |
|---|---|
| 既存コード調査 | 任せてよい。read-only |
| docs 要約 | 任せてよい。確認は必要 |
| issue 整理 | 任せてよい。外部更新は draft |
| failing test 作成 | 任せてよい。review 必須 |
| 小さな bug fix | 限定して任せる |
| UI小修正 | 限定して任せる。画面review必須 |
| 大規模refactor | 分割して一部だけ |
| DB migration | 調査と案まで |
| 認証・権限変更 | 調査とreview観点まで |
| production deploy | 任せない |
| user data delete | 任せない |
| billing変更 | 任せない |
| PR merge | 人間承認 |
まとめ
AIエージェント導入は、モデル選びだけでは決まりません。
どの仕事から始めるか。
どこまで任せるか。
どこで止めるか。
どう review するか。
何を次回に戻すか。
ここで決まります。
最初は read-only と draft から始める。
小さな変更だけ任せる。
review と test を通す。
外部toolは権限を分ける。
失敗したらルール、checklist、test、runbook に戻す。
AIエージェントは、全部を任せる相手ではありません。
人間が判断しやすい材料を作り、小さな作業を進め、学びを次回へ返す作業者です。
この距離感で使うと、開発の流れはかなり変わります。
速くなるだけではありません。
調査、実装、review、再発防止が、少しずつ同じ流れに乗っていきます。