AIエージェント時代、エンジニアに残る5つの仕事——「コードを書く」から「AIを監督する」へ
AIエージェントが実装やレビューを担うようになり、エンジニアの仕事は変わり始めている。
これから問われるのは、仕事を割り振り、権限を絞り、成果の採否を決める力だ。
コードを書く速さではなく、AIを監督する力が実績になる。
実際のAI駆動開発をもとに、人間に残る5つの仕事を整理する。
この記事は AIエージェント時代、エンジニアに残る5つの仕事——コード生成の次へ のダイジェスト版です。
権限設計で実際にやらかした実例や、状態を会話の外に出す設計の詳細は、上記の完全版をどうぞ。
AIコーディングの次に来る「AIを監督する仕事」
生成AIによる開発というと、プロンプトからコードを生成する姿を想像しやすい。
小さな開発なら、この流れだけで完結することもある。
しかし、実際のプロジェクトは、一つの指示と一つの回答では終わらない。
仕様を整理し、既存コードを調査し、実装後にレビューし、テストし、影響範囲を確認して公開する。
開発には、目的の異なる複数の工程がある。
これらを一つのAIへ任せると、実装者とレビュー担当が同じになる。
自分で採用した前提を、自分で正しいと判断する構造だ。
そこで必要になるのが、AIをコード生成ツールではなく、役割を持った作業者として扱う考え方だ。
調査を担当するAI、実装を担当するAI、レビューを担当するAI。
それぞれへ異なる仕事を任せ、人間が全体を管理する。
ただし、最初から複数のAIを使う必要はない。
一つのAIを使う場合でも、調査・実装・レビューの工程を分けるだけで考え方は変わる。
重要なのは、AIの数ではない。
何を任せるのか。
どこで成果を確認するのか。
誰が最終判断を行うのか。
この境界を設計することが、AIを監督する仕事だ。
AIエージェントを監督する、5つの仕事
1. ゴールと完了条件を決める
最初の仕事は、AIへ指示を書くことではない。
今回の作業を、どの状態で完了とするかを決めることだ。
「ログイン機能を改善する」「画面を使いやすくする」。
この粒度では、AIがどこまで作業すればよいか判断しにくい。
改善できる場所を探し続けることもできる。
その結果、作業は広がり続ける。
必要なのは、実行可能な完了条件だ。
「ログイン失敗時の表示を修正する」「既存の認証方式は変更しない」「今回の変更だけを元に戻せる単位にする」。
ここまで決まれば、AIは作業の境界を判断しやすくなる。
どこまでを今回の仕事とするのか。
何を別の仕事として切り離すのか。
この境界を決めるのは、人間の仕事だ。
AIは作業を掘り下げるのは得意だが、事業や利用者の状況を知らなければ、どこで終えるべきかまでは判断できない。
2. 仕事を分解し、適切な役割へ割り振る
二つ目は、作業を分解して役割を割り振ることだ。
一つのAIへ調査・設計・実装・レビュー・公開判断をすべて任せることもできる。
しかし、それでは判断の独立性が失われる。
実装を担当したAIは、自分が採用した設計を前提にレビューする。
実装時に見落とした前提を、レビューでも見落とす可能性がある。
そのため、実装とレビューは分ける。
一つのAIしか使わない場合でも、会話を工程ごとに分ける方法はある。
実装前の前提をいったん閉じる。
完成した差分を、新しい視点で読み直させる。
重要なのは、AIを増やすことではない。判断の衝突を避ける形で、役割を分けることだ。
AIへ仕事を割り振る能力とは、並列実行の技術ではない。
誰に何を任せ、どの成果を次の工程へ渡し、どこから人間が判断するのか。
その流れを設計する能力だ。
3. 実行権限を段階的に渡す
三つ目は、AIへどこまでの実行権限を渡すかを決めることだ。
ここが、他ではあまり語られない独自の勘所になる。
AIが技術的に実行できることと、実行を許可されたことは異なる。
いまのAIツールは、指示すればファイルを書き換え、コマンドを実行し、外部へ変更を反映できる。
できるからといって、最初から全部を許可する理由にはならない。
この境界を曖昧にしたまま作業を任せて、何度も痛い目を見ている。
重要な決め事を書いたMarkdownファイルを、整理の一環として消された。
デプロイに失敗し、公開中のサービスを壊した。
なかでも分かりやすかったのが、技術スタックを勝手に選ばれた件だ。
許可した覚えのないライブラリと外部サービスが、実装の過程で組み込まれていた。
コードは動いていた。
問題が見えたのは、挙動テストの段階だ。
その外部サービスは、利用量が一定を超えると課金が必要だった。
技術選定と同時に、費用の発生する契約先まで決まりかけていた。
ここで起きたのは、実装の誤りではない。
選定の権限を渡した覚えがないのに、選定が進んでいたことだ。
技術的な誤りなら、レビューで見つかる。しかし、権限の逸脱はコードを読んでも見つからない。
「これは許可していない」と知っているのは、人間の側だけだからだ。
だからこそ、渡す権限はあらかじめ段階に分けておきたい。
| 段階 | 失敗したときの戻しやすさ |
|---|---|
| 調査だけを任せる | 読み直せば済む |
| ファイルの編集を許可する | 変更を戻せば済む |
| 変更の保存・共有まで許可する | 影響が広がる |
| 公開環境・利用者データへ触れる | 簡単には戻せない |
権限は、仕事の段階に合わせて広げる。
まず調査だけを任せる。
方針を確認してから編集を許可する。
検証結果を見てから公開判断へ進む。
これは、AIを信用していないからではない。誤りが起きたときに取り返せるかどうかで線を引いているからだ。
事故が起きたときに責任を負うのは、権限を渡した側だ。
▶ 権限設計で実際にやらかした実例や、状態を会話の外に出す設計の詳細はこちら → AIエージェント時代、エンジニアに残る5つの仕事
4. レビュー結果を採用・保留・却下する
四つ目は、AIが出した指摘をそのまま正解にしないことだ。
複数のAIへレビューを依頼すると、多くの指摘が集まる。
不具合の可能性、テスト不足、設計上の懸念、将来の拡張案。
指摘が多いほど、レビューの品質が高いように見える。
しかし、すべてを修正すればよいわけではない。
上がってきた指摘に対して、三つ問う。
現在の目的に対して、正しい提案か。
遠回りになるとしても、将来の保守運用まで含めれば実行すべきか。
いまのサービス規模に対して、過剰設計になっていないか。
この三つの問いを通した結果を、採用・保留・却下へ振り分ける。
| 判断 | 対象 |
|---|---|
| 採用 | 今回の目的に直接関わる。壊れる可能性、利用者への影響、保守負担を確実に下げるもの |
| 保留 | 指摘としては妥当だが今回の作業ではない。記録し、別の作業として切り直す |
| 却下 | 今回の目的や事実に合わない。現仕様では発生しない問題、過剰設計、対処済みのもの |
AIの指摘をすべて追加すると、変更範囲が広がり続ける。
反対に、都合の悪い指摘をすべて却下すれば、レビューを分けた意味がない。
却下する場合は、理由を残す。理由のない却下は、後から見れば見落としと区別がつかない。
必要なのは、指摘の数ではなく、採否の根拠だ。
なお、最終的な公開や完了の判断は、レビューを行ったAIへ任せない。
AIは判断材料を提供する。
その総括を結論にするかは、プロジェクト全体を見る人間が決める。
5. 続行・中断・再設計を判断する
五つ目は、作業をそのまま続けてよいか判断することだ。
AIは、与えられた仕事を前へ進めようとする。
安全性を重視すれば、追加の確認を提案する。
品質を重視すれば、さらにレビューを増やす。
それぞれの提案には合理性がある。
しかし、局所的に正しい作業を続けた結果、プロジェクト全体が遅れることもある。
確認とレビューを細かく分けすぎ、作業をいったん中断したことがある。
必要だったのは、安全性を捨てる判断ではない。
サービス規模とリスクに見合う確認だけを残し、工程を組み直す判断だった。
AIを監督する仕事は、AIを動かし続けることではない。
もっともらしい手順で進んでいても、本来の目的から外れていれば中断する。
前提が変わったら、古い作業計画を見直す。
続ける判断だけでなく、疑い、中断し、見直す判断も人間の仕事だ。
AIへ仕事を任せる前に決める5つのこと
ここまでの5つは、体制づくりの話に聞こえるかもしれない。
しかし、実際には一つのタスク単位へ落とし込める。
まずは、一つの作業について次の5点を決めればよい。
- 今回解決する問題は何か
- どの状態になれば完了か
- AIへ任せない範囲はどこか
- 誰が、どの観点で成果を確認するか
- どの状態になったら中断するか
画面の不具合を修正する場合なら、こうなる。
- 目的：特定の操作でエラー表示が消えない問題を修正する
- 完了条件：原因となる状態管理を修正し、対象操作のテストを通す
- 任せない範囲：画面全体の設計やAPI仕様は変更しない
- 確認方法：自動テストに加え、実際の画面操作で確認する
- 中断条件：認証やデータ構造の変更が必要だと判明した場合は、別の作業として切り直す
複雑な管理方法を導入する前に、目的と境界を言葉にする。
それが、AIを監督する最初の一歩になる。
AI時代の上流工程は「指示を出すこと」ではない
AIを監督する仕事は、従来の上流工程と似ている。
目的を整理し、仕事を分解し、担当を決め、成果を確認し、リスクと進行を管理する。
しかし、AIには人間と異なる特徴がある。
休まず作業を続けられる。
もっともらしい形で、誤った前提を補完することもある。
依頼された範囲を、善意で広げることもある。
そのため、単に指示を出すだけでは足りない。
AIが参照する情報を管理し、実行できる権限を制限し、別の視点から成果を検証し、必要なら作業を中断する。
ここまで含めて、AI時代の上流工程になる。
そして問題は、この監督の判断が、記録しなければ残らないことだ。
完成した機能は後からでも思い出せる。
しかし、どの権限を渡さなかったか、どの指摘を却下したか、どこで中断したかは、その場で書き留めなければ消える。
スキルシートを読む側にいた経験から言えば、評価が動くのは、動かしたAIの数ではなくこの判断のほうだ。
Skillsheet-Port なら、案件を担当工程・期間・技術ごとにフォームへ入力していくので、監督側の判断も記憶が新しいうちに積める。
AI構成補助を使えば、「この判断、どう書けば伝わるか」を壁打ちできる。
まとめ
- AIエージェントが実装を担っても、人間の仕事はなくならない。位置が「コードを書く」から「AIを監督する」へ変わる
- 監督の5つの仕事：①ゴールと完了条件を決める ②仕事を分解し役割へ割り振る ③実行権限を段階的に渡す ④レビュー結果を採用・保留・却下する ⑤続行・中断・再設計を判断する
- 特に③が独自。権限の逸脱はコードを読んでも見つからない。段階を分けて渡す
- ④は指摘の数ではなく採否の根拠。却下理由も残す
- 大規模な仕組みは不要。1タスクにつき5点（問題/完了/任せない範囲/確認/中断条件）を決める
- 評価が動くのは、動かしたAIの数ではなく判断の記録
複数のAIを動かすこと自体は、難しくなくなっていく。
その成果を一つのプロジェクトへ統合し、安全に完了させること。
そこに、AIエージェント時代のエンジニアの価値が残る。
▶ 完全版ガイドはこちら → AIエージェント時代、エンジニアに残る5つの仕事——コード生成の次へ
▶ 無料でスキルシートを作ってみる → https://www.skillsheet-port.com/