「AIに仕事を奪われる」という議論は、実際にAIへ仕事を渡してみないと解像度が上がりません。
私はClaude Codeで12部門のAIエージェント体制を組み、個人事業の庶務を約90%自動化しました。運用コストは月$200だけです。半年ほど回してみて、どの仕事はきれいにAIへ渡せて、どの仕事は最後まで自分（＝意思決定する人間）の手に残ったか が、リストとしてはっきり見えてきました。
この記事は「AIがすごい」でも「人にしかできないことがある（キリッ）」でもなく、実運用で分かった委譲の境界線を、具体的なタスク単位で列挙する 記事です。キャリアの方向づけの材料にしてもらえればと思います。
前提：どんな「AI組織」を運用しているか
まず環境を明確にしておきます。特別なフレームワークは使っていません。
- 構成: Claude Code + Markdown + シェルスクリプト
- 体制: 秘書エージェント（ルーティング担当）＋部門エージェント（開発・経理・広報などの役割別）
- 定義ファイル: 各エージェントに「ペルソナ」「担当範囲」「禁止事項」をMarkdownで記述
- コスト: 月$200（Claude Codeの上位プラン）のみ
- 筆者: IT業界10年以上、本業SIer × 副業で法人を運用
一人のAIに全部を頼むのではなく、役割別に分割しているのがポイントです。実際、以前は一つのエージェントに全業務を任せていたのですが、コンテキストが肥大化して応答が遅くなり、的外れな回答が増えていました。役割別に分割して秘書エージェントがルーティングする構成に変えたところ、各エージェントの応答精度が約40%向上し、処理速度も平均2倍 になりました。人間の組織設計と同じで、「一人に全部」より「適材適所」が圧倒的に効きます。
AIに渡せた仕事（一覧）
半年運用して、以下のカテゴリはほぼ丸ごとAIへ委譲できました。共通するのは 「正解が既存の情報から導ける」「手順が定義できる」「間違えても内部で取り返せる」 タスクです。
| 渡せた仕事 | 具体例 | 効果（実測） |
|---|---|---|
| 定型の生成 | テストコード・API仕様書・マイグレーション | 80本のAPI仕様書を2日で生成 |
| 既存物からの変換 | コードからドキュメント逆生成、CSV整形 | 10万行のデータを30分で統一 |
| 大量情報の解析 | ログ調査・原因分析・セキュリティスキャン | 3日悩んだバグを15分で特定 |
| 外部連携の実行 | 社内APIの呼び出し（MCP経由） | 手動操作比で80%の時間削減 |
| 一次ドラフト | ブログ・メール・提案書の下書き | 着手のハードルがほぼゼロに |
いくつか実例を挙げます。
ドキュメント生成は特に相性が良い領域でした。80本のAPIエンドポイントがあるのに仕様書はExcelに散在し、半分は古い情報という状態だったのを、コントローラー・ルート定義・バリデーションを読み込ませてOpenAPI形式で一括生成させたところ、2日で全80本が完成 しました。コードが正なので、ドキュメントの鮮度問題まで同時に解消されます。
ログ解析も人間より速い場面が多いです。本番で断続的に出るNullPointerExceptionの原因が特定できず3日悩んでいたとき、過去24時間分の約5,000行のログと関連ソース3ファイルを読ませたら、非同期処理のレースコンディションが原因だと15分で特定 し、修正パッチまで提案してきました。「大量の情報からパターンを見つける」作業はAIの独壇場です。
外部連携もMCP（Model Context Protocol）でツール化すれば渡せます。社内APIをバリデーション付きのMCPツールとしてラップしたところ、「顧客ID 12345の情報を取得して」と自然言語で頼むだけで呼び出しが完了するようになり、手動操作比で80%の時間削減 になりました。
人に残った仕事（一覧）
一方で、いくら仕組みを整えても最後まで私（意思決定者）の手に残った仕事があります。こちらの方がキャリアを考える上では重要です。
| 残った仕事 | なぜ渡せないか |
|---|---|
| 判断 | 複数の妥当な選択肢から一つを選ぶ責任は委譲できない |
| 承認 | 外部影響のある実行を止める最後のゲート |
| 責任 | 結果が失敗したときに引き受ける主体は人間 |
| 対人調整 | 相手の感情・立場・信頼関係を踏まえた交渉 |
| 問いの設定 | 「何を解くべきか」を決めるのは人間 |
一番痛感したのが 承認 の重み。エージェントにメール送信や外部API呼び出しを自律実行させたら、誤送信が1回発生して冷や汗をかきました。そこで外部向けアクション（メール・SNS投稿・本番デプロイ等）には必ず承認キューを挟み、ドラフト生成→キュー格納→人間承認→実行 の4ステップにしました。結果、誤送信はゼロになり、承認作業自体は1日5分程度で済んでいます。
ここで分かったのは、「実行」はAIに渡せても「実行してよいという判断」は渡せない ということ。AIは無数の選択肢を提示できますが、そのうちどれを世に出すかを決め、失敗したら責任を負うのは最後まで人間です。
問いの設定 も残りました。AIは「与えられた問いに答える」のは驚くほど得意ですが、「そもそも今、何を解くべきか」を決めるのは相変わらず私の仕事です。エージェント体制を設計するとき、各エージェントに何を担当させ何を禁止するかを決める作業そのものが、まさに人間側に残った意思決定でした。
委譲の境界線を判断する3つの軸
半年の運用から、私は「この仕事はAIに渡せるか」を次の3軸で判断するようになりました。チートシート的に使えます。
- 正解の所在：答えが既存情報から導けるか（Yes→渡せる）／価値判断が必要か（No→残る）
- 取り返しやすさ：間違えても内部で修正できるか（Yes→渡せる）／外部に影響が出るか（No→承認を挟む）
- 責任の所在：失敗の責任を機械が負えるか（負えない→最終判断は人間）
この3軸で切ると、冒頭の2つのリストがきれいに説明できます。「渡せた仕事」はすべて〈正解が導ける・取り返せる・責任が軽い〉側に寄っていて、「残った仕事」はすべて〈判断・不可逆・責任重〉側に寄っています。
エンジニアの役割はどう変わるか
このリストを眺めて感じるのは、エンジニアの仕事が「手を動かす」から「境界線を設計する」へシフトしている ということです。
コードを書く・テストを書く・ドキュメントを起こす——かつて工数の大半を占めていた作業は、渡せる側に移りました。代わりに価値が上がったのは、AIへの引き継ぎ書を書く力 です。私の場合、プロジェクトごとにCLAUDE.mdへ技術スタック・規約・禁止事項を約200行で記述するようにしたら、それだけでコード生成の一貫性が大きく上がり、1日あたり約30分の説明工数が消えました。CLAUDE.mdは実質「AIという新人への業務マニュアル」で、人に仕事を教えるのが上手い人はAIに仕事を渡すのも上手い、というのが半年運用しての実感です。
つまり奪われるのは「作業」であって「仕事」ではありません。判断・承認・責任・対人調整・問いの設定——ここに軸足を移せるかどうかが、これからのエンジニアの分かれ道になりそうです。
まとめ
- AIに渡せたのは〈正解が導ける・取り返せる・責任が軽い〉タスク（生成・変換・解析・実行）
- 人に残ったのは〈判断・承認・責任・対人調整・問いの設定〉
- 委譲の判断軸は「正解の所在／取り返しやすさ／責任の所在」の3つ
- エンジニアの価値は「手を動かす」から「AIへの引き継ぎ書を書く・境界線を設計する」へ
「AIに仕事を奪われる」かどうかは、自分の仕事のどれくらいが上の3軸で〈渡せる側〉に寄っているかで、ある程度見積もれます。まずは自分の一週間のタスクを、この2つのリストに仕分けてみるのがおすすめです。
この記事が参考になったら、いいね・ストック していただけると励みになります。
Claude Code・AIエージェント・業務自動化の実装Tipsを継続的に発信しています。フォロー しておくと新着が届きます。
みなさんが「これはまだAIに渡せない」と感じている仕事は何ですか？ ぜひコメントで教えてください。