2026-09-21 追記: 記事を見直しました

実測値や効果の記述に、観測の範囲（私の環境・計測方法）を明記しました

示した根拠の範囲を超えていた断定表現を、事実に合わせて弱めました

本文に混入していた内部向けの語・不要な記号を取り除きました

内容の骨子は変えていません。

「AIに仕事を奪われる」という議論は、実際にAIへ仕事を渡してみないと解像度が上がりません。

私はClaude Codeで12部門のAIエージェント体制を組み、個人事業の庶務を体感で9割ほど自動化しました。運用コストは執筆時点・私の使用量で月$200程度です。半年ほど回してみて、どの仕事はきれいにAIへ渡せて、どの仕事は最後まで自分（＝意思決定する人間）の手に残ったか が、リストとしてはっきり見えてきました。

この記事は「AIがすごい」でも「人にしかできないことがある（キリッ）」でもなく、実運用で分かった委譲の境界線を、具体的なタスク単位で列挙する 記事です。キャリアの方向づけの材料にしてもらえればと思います。

前提：どんな「AI組織」を運用しているか

まず環境を明確にしておきます。特別なフレームワークは使っていません。

構成: Claude Code + Markdown + シェルスクリプト
体制: 秘書エージェント（ルーティング担当）＋部門エージェント（開発・経理・広報などの役割別）
定義ファイル: 各エージェントに「ペルソナ」「担当範囲」「禁止事項」をMarkdownで記述
コスト: 月$200（Claude Codeの上位プラン）のみ
筆者: IT業界10年以上、本業SIer × 副業で法人を運用

一人のAIに全部を頼むのではなく、役割別に分割しているのがポイントです。実際、以前は一つのエージェントに全業務を任せていたのですが、コンテキストが肥大化して応答が遅くなり、的外れな回答が増えていました。役割別に分割して秘書エージェントがルーティングする構成に変えたところ、各エージェントの応答精度も処理速度も目に見えて上がりました（同じ依頼を投げたときの比較で、評価セットを用意した計測はしていません）。人間の組織設計と同じで、「一人に全部」より「適材適所」が圧倒的に効きます。

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の情報を取得して」と自然言語で頼むだけで呼び出しが完了するようになり、同じ作業を手でやっていた頃と比べて、私の作業時間は8割ほど短くなりました（ストップウォッチでの厳密な計測ではなく、作業ログの比較です）。

人に残った仕事（一覧）

一方で、いくら仕組みを整えても最後まで私（意思決定者）の手に残った仕事があります。こちらの方がキャリアを考える上では重要です。

残った仕事	なぜ渡せないか
判断	複数の妥当な選択肢から一つを選ぶ責任は委譲できない
承認	外部影響のある実行を止める最後のゲート
責任	結果が失敗したときに引き受ける主体は人間
対人調整	相手の感情・立場・信頼関係を踏まえた交渉
問いの設定	「何を解くべきか」を決めるのは人間

一番痛感したのが承認の重み。エージェントにメール送信や外部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に渡せない」と感じている仕事は何ですか？ぜひコメントで教えてください。

関連記事