← 一覧へ
AIコーディング & エージェント深掘り2026.06.127分で読めます

AIエージェント導入の判断基準──任せていい仕事、まだ任せない仕事

この記事の読み方
このシリーズでは、AIエージェントを開発工程に入れる方法を書いてきました。

このシリーズでは、AIエージェントを開発工程に入れる方法を書いてきました。

最後に、導入の判断基準をまとめます。

どの作業から始めるべきか。
どこまで任せてよいか。
まだ任せない方がよい作業は何か。
チームで使うなら、何を先に整えるべきか。

AIエージェントは、使うだけなら簡単です。

難しいのは、日常の仕事に入れることです。

最初に任せるべき仕事

最初から重要な本番作業を任せる必要はありません。

最初に向いているのは、失敗しても戻しやすく、成果物を人間が確認しやすい仕事です。

たとえば、

これらは、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 を扱わない
- 本番状態を変えない

この条件に多く当てはまるほど、任せやすいです。

例：

逆に、条件から外れるほど慎重にします。

まだ任せない方がいい作業

次の作業は、最初から任せない方がいいです。

これらは、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を何回使ったか」では見ません。

見るべきなのは、仕事が安定したかです。

たとえば、

速さだけを見ない方がいいです。

速く雑になるなら、導入としては失敗です。

速く、見やすく、戻しやすくなる。

ここを見ます。

コストを見る

AIエージェントにはコストがあります。

利用料金だけではありません。

これを見ないと、「生成は速いが後処理が重い」状態になります。

導入初期は、次を記録します。

Task:
Agent used:
Human time saved:
Human review time:
Tests added:
Rollback needed:
What to improve next:

ざっくりでいいです。

記録があると、どの作業に向いているか見えてきます。

人間が持つべき仕事

AIエージェントを入れても、人間の仕事は残ります。

むしろ、はっきりします。

人間が持つべきもの：

agent に向いているもの：

この分担ができると、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、再発防止が、少しずつ同じ流れに乗っていきます。

関連記事

← 一覧へ