第2章 AIに任せる仕事、任せない仕事
この章で扱う能力
この章では、AIエージェントに任せるべき仕事と、任せてはいけない仕事を切り分ける。読者は、自分の業務を「入力」「処理」「判断」「出力」「承認」に分解し、操作選択や低リスクの定型判定をどこまで委任するかを、ROIとリスクの両面で評価できるようになる。
この章の結論は次のとおりである。
AI導入の第一歩は、プロンプトを書くことではない。
任せる仕事を選ぶことである。
AIに向くのは、反復性があり、文脈を渡せて、出力を検証でき、
失敗しても人間が修正できる作業である。
通常ソフトウェア、ルール、固定ワークフロー、生成AI支援で目的を満たせるなら、
AIエージェントより単純な方式を選ぶ。
AIに丸投げしてはいけないのは、顧客影響、法務責任、金銭処理、
人事判断、本番環境変更、個人情報、不可逆操作、対人責任を伴う高影響の判断・承認である。
AI活用は、業務全体を「自動化できるか」と見ると失敗しやすい。業務を小さな作業単位に分解すると、一部はAIに任せられ、一部は人間が判断すべきだと分かる。この切り分けができると、AI活用は安全に始められる。
本書全体における位置づけ
| 項目 | 内容 |
|---|---|
| 設計層 | Work |
| 目的 | AIを使う対象業務を選び、ROIとリスクで分類する。 |
| 主な成果物 | AI適用判断シート |
| 参照 | Artifact Index、付録A: 成果物テンプレート集、Troubleshooting Flow |
第2章は、本書の6層フレームワークにおける Work 層である。ここで扱う問いは単純である。
どの仕事にAIを使うのか。
どの仕事には使わないのか。
使うとしても、どこまで任せるのか。
この問いに答えずに第3章の Request Contract へ進むと、うまく依頼文を書けても、そもそも不適切な業務にAIを使うことになる。
なぜ必要か
AIエージェント導入の失敗は、プロンプトが下手だから起きるだけではない。そもそもAIに任せるべきではない仕事を選んでいる場合がある。
AIに向く仕事は、一定のパターンがあり、必要なコンテキストを渡せて、成果物を検証でき、失敗しても人間が修正できる仕事である。一方、AIに丸投げしてはいけない仕事は、不可逆な操作、法的・倫理的責任、顧客影響、人事評価、金銭処理、本番環境変更などを伴う仕事である。
重要なのは、業務全体を一括で「AI化できるか」と考えないことである。
たとえば「顧客問い合わせ対応」は、全体をAI化するにはリスクが高い。しかし、分解するとAIに任せられる作業が見える。
| 作業 | AI適用 |
|---|---|
| 問い合わせ種別を分類する | 向いている |
| FAQ候補を検索する | 向いている |
| 回答案を下書きする | 向いている。ただしレビュー必須 |
| 契約上の責任を判断する | 人間 |
| 顧客へ送信する | 人間承認必須 |
| 障害補償を約束する | AIに任せない |
AI適用の単位は、業務名ではなく作業単位である。
業務を5つに分ける
AI適用を考えるときは、業務を次の5要素に分ける。
| 要素 | 内容 | AI適用の考え方 |
|---|---|---|
| 入力 | 問い合わせ、資料、ログ、データ、会話 | 構造化、分類、要約に向く |
| 処理 | 調査、比較、下書き、変換、抽出 | AIに向く場合が多い |
| 判断 | 分類、推奨、採用、棄却、優先順位、リスク許容 | 低リスクの定型判定だけ基準付きで委任し、高影響・例外は人間が判断する |
| 出力 | メール、レポート、コード、チケット、提案書 | 下書きはAI、確定は人間 |
| 承認 | 顧客送信、本番反映、契約、支払い | 人間承認を必須にする |
AI化すべき対象は、業務全体ではなく、業務の中の「入力整理」「処理」「下書き」「候補生成」「レビュー補助」であることが多い。
5分解の使い方
1つの業務を選んだら、次の順で分解する。
1. 入力は何か
2. どの処理が繰り返し発生しているか
3. どの判断に責任が伴うか
4. どの出力が外部影響を持つか
5. どの承認が必要か
この分解により、AIに任せる範囲が明確になる。
解決方式を選ぶゲート
AIに向く作業を見つけても、直ちにAIエージェントへ実装してはいけない。目的を満たす最も単純で決定的な方式を優先する。非AI方式の採用は失敗ではなく、設計上の正常な判定結果である。
| 方式 | 向いている条件 | 例 | 追加で必要になる管理 |
|---|---|---|---|
| 通常ソフトウェア | 入力、計算、出力を厳密に定義できる | 集計、検索、CRUD、形式検証 | 通常のテスト、監視 |
| ルールベース自動化 | 条件と処理を列挙でき、例外が少ない | 閾値通知、必須項目検査、定型振り分け | ルール版管理、例外処理 |
| 固定ワークフロー | 手順と分岐は決まっているが、複数工程をつなぐ必要がある | 受付→分類→下書き→承認 | 状態管理、再実行、承認、ログ |
| 生成AI支援 | 非構造情報の要約・抽出・生成が必要だが、1回の依頼または固定工程で足りる | 要約、回答案、比較表の下書き | 出力評価、根拠確認、レビュー |
| AIエージェント | 状況に応じて経路・ツール・再試行を選び、複数ステップを進める必要がある | 動的な調査、複数システムをまたぐ例外処理 | 評価、権限、HITL、トレース、停止条件、コスト上限 |
次の順に判定し、最初に目的を満たす方式を採用候補にする。
1. 厳密な入出力を通常ソフトウェアで実装できるか。
2. 条件と処理をルールとして列挙できるか。
3. 固定した手順と分岐で完了できるか。
4. 単発または固定工程内の生成AI支援で十分か。
5. 状況依存の経路・ツール選択と複数ステップ実行が本当に必要か。
AIエージェントを選ぶ場合は、非決定性、モデル・API費用、評価データ、権限管理、セキュリティ、HITL、観測性、障害時復旧という追加コストを上回る便益が必要である。「AIを使える」ことは、「AIエージェントにすべき」ことを意味しない。
AIに向く仕事
AIに向く仕事には共通点がある。単に「文章を書く仕事」や「調査する仕事」が向いているという話ではない。検証可能で、前提を渡せて、レビューできることが重要である。
1. 情報整理
- 長い議事録の要約
- 顧客問い合わせの分類
- 仕様書から制約を抽出
- 障害ログの時系列整理
- 会議メモから決定事項と未決事項を分ける
- 複数資料から重複や矛盾を見つける
情報整理は、AI適用の初期対象として適している。理由は、外部影響が小さく、出力を人間が確認しやすいからである。
2. 下書き作成
- 顧客返信案
- 社内報告文
- 提案書の骨子
- チケット本文
- ADRの初稿
- FAQの初稿
- レビュー依頼文
下書き作成はAIに向く。ただし、下書きと確定版を混同してはいけない。AIが作った文面は、原則として人間レビュー後に使う。
3. 比較・分類
- 競合比較
- ツール選定表
- リスク分類
- 問い合わせ種別分類
- 顧客要望のカテゴリ分け
- 障害原因候補の分類
比較・分類では、分類軸を人間が与えることが重要である。AIに分類軸から任せる場合も、結果を人間がレビューする。
4. レビュー補助
- 文書の曖昧表現検出
- コードレビュー観点の洗い出し
- セキュリティチェックリストとの照合
- 契約書や規程の注意点抽出
- 顧客向け文面のリスク表現チェック
- FAQと回答案の不一致確認
レビュー補助では、AIは見落としを減らすために使う。AIレビューを通ったことは、人間レビューの代替ではない。
5. 実験補助
- 仮説の分解
- A/Bテスト案の作成
- ユーザーインタビュー質問案
- 失敗レビューの論点整理
- 小さな検証手順の設計
- やめる条件の候補生成
AIは、既存業務の効率化だけでなく、試行回数を増やすためにも使える。完璧な計画を作るより、小さな実験を増やす方が有効な場面がある。
6. 内部向けの変換作業
- Markdownから表形式への変換
- チケットから週次報告への変換
- 議事録からタスク一覧への変換
- 仕様書からテスト観点への変換
- 障害ログから時系列表への変換
変換作業は、入力と出力の対応を確認しやすい。初期導入の候補にしやすい。
AIに向く仕事の判定軸
AIに向くかどうかは、次の観点で判断する。
| 判定軸 | AIに向きやすい状態 | AIに向きにくい状態 |
|---|---|---|
| 反復性 | 同じような作業が頻繁にある | 毎回まったく違う |
| 検証可能性 | 出力を人間が確認できる | 正誤を判定しにくい |
| コンテキスト提供 | 必要情報を渡せる | 暗黙知が多く、言語化されていない |
| 失敗時影響 | 修正できる | 顧客、法務、本番環境に直撃する |
| 可逆性 | やり直せる | 取り消し困難 |
| データ感度 | 公開情報、社内限定情報 | 個人情報、認証情報、機密情報 |
| 権限 | 参照・下書きで済む | 書き込み、削除、送信が必要 |
| レビュー負荷 | 人間が短時間で確認できる | レビューの方が重い |
| 成果物明確性 | 出力形式を定義できる | 成果物が曖昧 |
| 改善可能性 | 失敗ログを次回改善に使える | 失敗理由が追えない |
すべてを満たす必要はない。ただし、検証可能性、失敗時影響、権限、データ感度は特に重要である。
実証研究を仕事選定へ使う
AIの生産性効果を固定値として扱ってはいけない。2026年7月11日時点の公開研究では、タスク、熟練度、利用時点、測定方法によって正負の結果が分かれている。
| 研究の種類 | 本書での読み方 |
|---|---|
| 顧客サポートのフィールド研究 | 平均的な改善だけでなく、熟練度による差を確認する |
| ソフトウェア開発の複数フィールド実験 | 完了タスクなどの実測指標を、対象組織と期間の条件付きで解釈する |
| 熟練OSS開発者の無作為化比較 | AI利用で実測時間が悪化した結果と、参加者の自己認識との差を分ける |
| 人間・AI協働のメタ分析 | 人間とAIを組み合わせれば常に相乗効果が出るとは仮定しない |
| 知識労働の境界を扱う研究 | 似た業務でもAIが得意な範囲と不得意な範囲が混在すると考える |
外部研究の平均値をROIへそのまま転記しない。自社の対象タスク、熟練度、品質、所要時間、レビュー工数を基準線と比較する。自己申告の速さや満足度と、実測時間、完了数、品質を別の指標として記録する。負の結果、選択バイアス、利用ツールの変化、追試時点の違いも残す。
参照軸は SRC-NBER-GENAI-WORK、SRC-MS-DEV-PRODUCTIVITY、SRC-METR-DEV-PRODUCTIVITY、SRC-METR-UPLIFT-UPDATE、SRC-HUMAN-AI-META、SRC-HBS-JAGGED-FRONTIER である。単一研究から普遍的な効果を断定しない。
AIに丸投げしてはいけない仕事
AIを使うこと自体が禁止ではない。禁止すべきなのは、AIに最終判断や不可逆操作を任せることである。
| 領域 | 丸投げ禁止の理由 | 可能な使い方 |
|---|---|---|
| 顧客送信 | 誤送信、誤表現、契約影響 | 下書き、確認観点、FAQ候補 |
| 契約・法務判断 | 法的責任、解釈誤り | 論点整理、確認事項抽出 |
| 採用・人事評価 | 公平性、説明責任、個人影響 | 面接メモ整理、評価観点の補助 |
| 価格決定 | 収益、顧客影響、競争戦略 | 比較表、シミュレーション補助 |
| 本番環境変更 | 障害、データ損失、サービス停止 | 手順案、リスク洗い出し |
| 個人情報処理 | プライバシー、法令、契約 | 匿名化後の分類補助 |
| 支払い・購買 | 金銭的損害、承認逸脱 | 稟議文案、比較資料 |
| セキュリティ設定変更 | 権限破壊、情報漏洩 | 設定案、レビュー観点 |
| 医療・金融・安全に関わる判断 | 人身、財産、規制への影響 | 情報整理、確認項目作成 |
| 対人関係の最終対応 | 信頼、関係性、責任 | 会話準備、論点整理 |
AIへの委任を、補助、整理、候補生成、下書きだけに固定する必要はない。明文化した基準、検証可能性、低い失敗影響、停止条件がそろえば、定型分類や許可済み操作を自動実行できる。ただし、高影響・不可逆・例外的な業務判断、承認、対人責任、リスク受容は人間と組織が扱う。
ROIとリスクで分類する
AI適用候補は、ROIとリスクの2軸で分類する。
| 分類 | 内容 | 方針 |
|---|---|---|
| 高ROI・低リスク | 作業量が多く、顧客影響や機密リスクが低い | 最初に導入する |
| 高ROI・高リスク | 効果は大きいが事故影響も大きい | 承認、ログ、段階導入が必要 |
| 低ROI・低リスク | 効果は小さいが安全 | 学習用・小実験向き |
| 低ROI・高リスク | 効果が小さくリスクが高い | 原則やらない |
最初に狙うべきは、高ROI・低リスクの業務である。典型例は、社内文書要約、議事録整理、問い合わせ分類、FAQ下書き、内部レビュー補助である。
ROIは生成時間だけで測らない
AI導入の効果を、AIが出力するまでの時間だけで測ると誤る。実際には、次のコストを含める必要がある。
AI導入効果
= 従来作業時間
- AI実行時間
- レビュー時間
- 修正時間
- 承認時間
- 失敗時の手戻り
- テンプレート・コンテキスト維持コスト
- ガバナンス・ログ確認コスト
AIが10分で下書きを作っても、人間レビューに2時間かかるなら、ROIは高くない。逆に、AIの出力に修正が必要でも、従来よりレビューしやすい構造になっていればROIが高い場合もある。
リスクは事故発生確率だけで見ない
リスクは、単に「間違う可能性」ではない。次のように見る。
リスク
= 情報感度
× 外部影響
× 権限の強さ
× 不可逆性
× 判断の不確実性
× 観測しにくさ
たとえば、AIが社内メモを要約して間違える場合、影響は限定的である。しかし、AIが顧客へ誤った障害原因を送信する場合、影響は大きい。AIが本番DBを書き換える場合は、さらにリスクが高い。
AI適用の段階を分ける
AI適用は、いきなり完全自動化を目指さない。段階を分ける。
| 段階 | AIの役割 | 人間の役割 | 例 |
|---|---|---|---|
| Level 1: Assist | 個人作業の補助 | 全面レビュー | 要約、下書き |
| Level 2: Draft | 成果物候補を作る | 修正・承認 | 回答案、比較表 |
| Level 3: Recommend | 選択肢と理由を出す | 採否判断 | 優先度候補、リスク分類 |
| Level 4: Act with approval | 承認後に実行する | 承認・監視 | チケット更新、PR作成 |
| Level 5: Act within guardrails | 低リスク範囲で自動実行 | 例外監視 | 内部タグ付け、定型分類 |
多くの組織では、まず Level 1〜2 から始めるべきである。Level 4〜5 に進むには、権限設計、ログ、評価、承認、停止条件が必要になる。
仕事選定の手順
手順は次の4段階に統一する。
- 上位成果物、対象、入力、責任者を確認する。
- 許可範囲、禁止事項、受け入れ条件、停止・エスカレーション条件を定義する。
- 低リスクな最小単位で実行し、途中成果物と判断経路を記録する。
- 結果をレビュー・評価し、権限、教材、評価ケース、改善バックログへ戻す。
章固有の項目は前後の表と付録Aを使う。
典型的な失敗
失敗1: 「全部AIで自動化」を目標にする
業務全体を自動化しようとすると、判断、承認、例外処理、責任境界が曖昧になる。最初は、業務の一部だけをAI化する方が成功しやすい。
正しい目標は「問い合わせ対応を全部AI化する」ではない。たとえば「問い合わせ分類と回答案作成をAIで支援し、送信前レビューを必須にする」である。
失敗2: 効果だけ見てリスクを見ない
AIで大幅に時間短縮できる業務ほど、顧客影響や法務影響が大きいことがある。効果が大きいことは、即導入の理由ではない。リスク設計の必要性を示すだけである。
失敗3: 人間のレビュー工数を見積もらない
AIが下書きを作っても、レビューに時間がかかりすぎるならROIは下がる。AI導入効果は、生成時間ではなく、レビュー、修正、承認、再実行を含めて測る。
設計原則
原則1: 高頻度・低リスク・検証可能な作業から始める
最初のAI活用対象は、社内向け、反復的、レビュー可能、失敗しても修正できる作業にする。
原則2: 下書きと確定を分ける
AIが作るのは、原則として下書きである。確定版にするには、人間レビューと必要な承認を通す。
原則3: 説明責任を伴う承認とリスク受容をAIに移さない
AIは判断材料を生成できるだけでなく、明文化した基準に従う低リスクの分類や操作選択も実行できる。高影響・例外・曖昧な採用や棄却、外部送信、契約判断、承認、リスク受容は人間と組織が担う。
原則4: レビュー工数を含めてROIを見る
AI導入の効果は、生成時間ではなく、レビュー、修正、承認、失敗時対応を含めて測る。
原則5: データ感度とツール権限を先に確認する
個人情報、顧客情報、認証情報、機密情報を扱う場合は、AI利用可否、外部送信可否、ログ保存範囲を確認する。ツール権限は必要最小限にする。
原則6: 小さく試し、やめる条件を持つ
AI活用は、最初から恒久運用にしない。小実験として始め、成功条件と失敗条件を決める。
原則7: 成功例だけでなく、不採用例も残す
AI活用で重要なのは、何を導入したかだけではない。何を導入しなかったか、何をやめたかも組織知にする。
原則8: 目的を満たす最も単純な方式を選ぶ
自律性は目的ではない。通常ソフトウェア、ルール、固定ワークフロー、生成AI支援の順に検討し、状況依存の経路・ツール選択が必要な場合だけAIエージェントを選ぶ。
実務ケース: 競合調査
ITDO Cloud Services が、法人向けバックアップサービスの価格改定を検討している。営業チームは、競合5社の機能、価格、対象顧客、強み、弱みを比較したい。
この業務を5要素に分解する。
| 要素 | 内容 | AIに任せるか |
|---|---|---|
| 入力 | 競合サイト、公開資料、比較記事、社内営業メモ | 公開情報の整理は可。社内営業メモは機密区分を確認 |
| 処理 | 機能、価格体系、対象顧客、強み、弱みの比較表作成 | 可 |
| 判断 | 自社価格を上げるか、据え置くか | 人間 |
| 出力 | 経営会議向け資料、要確認事項リスト | AIは下書き。人間が編集 |
| 承認 | 価格改定、顧客向け説明、営業資料公開 | 経営・営業責任者が承認 |
このケースでは、AIの主な役割は、情報整理、比較表作成、未確認事項の抽出である。価格決定そのものはAIに任せない。
AI適用判断
| 項目 | 評価 |
|---|---|
| 反復性 | 中。価格改定や競合調査のたびに発生する |
| 検証可能性 | 中。公開情報は出典確認できるが、価格や仕様は変わりやすい |
| コンテキスト提供 | 高。対象市場、比較軸、出力形式を明示できる |
| 失敗時影響 | 中。内部資料なら修正可能。外部公開なら高リスク |
| データ感度 | 低〜中。公開情報中心。社内営業メモを使う場合は注意 |
| 権限 | 参照・下書きで十分 |
| レビュー負荷 | 中。出典確認が必要 |
| 初期方針 | AIで比較表と要確認事項を作成し、人間が出典と判断を確認する |
この業務は、高ROI・中リスクに分類できる。最初の実験としては適している。ただし、外部公開資料や価格改定判断に直結させる場合は、人間レビューと承認が必要である。
解決方式の判定
初期方式は、承認済みURLの取得と比較表作成を固定ワークフローにし、非構造な説明文の抽出と下書きだけ生成AIで支援する。対象サイトや調査経路を状況に応じて拡張する必要が確認されるまでは、AIエージェントを採用しない。
作成する成果物: AI適用判断シート
AI適用判断シートの目的、責任境界、採否判断は前節までで定義した。記入時は 付録A: 成果物テンプレート集 の必須項目を使い、完成後は Artifact Index から後続成果物へ接続する。
チェックリスト
AI適用候補を選ぶ前に、次を確認する。
- 業務全体ではなく、AIに任せる作業単位へ分解したか
- 入力、処理、判断、出力、承認を分けたか
- 通常ソフトウェア、ルール、固定ワークフロー、生成AI支援、AIエージェントを比較したか
- 目的を満たす最も単純な方式を選び、非AI方式も正常な選択肢として扱ったか
- AIエージェントを選ぶ場合、状況依存の経路・ツール選択が必要な理由と追加コストを記録したか
- AIへ委任する操作選択・定型判定と、人間が扱う高影響・例外判断を明確にしたか
- Accountable Ownerと承認者を決めたか
- 顧客影響、法務影響、個人情報、本番環境影響、金銭影響を確認したか
- AI出力のレビュー工数を見積もったか
- 初回導入を高ROI・低リスク、または高ROI・中リスクの小実験に絞ったか
- 外部送信や不可逆操作をAI単独で実行しない設計にしたか
- 成功条件、失敗条件、やめる条件を決めたか
- 責任者を決めたか
関連するチェックリストは 付録B: チェックリスト集 を参照する。
演習
本章で扱った主要成果物を、自分の低リスクな業務1件について作成する。入力、受け入れ条件、人間が担う判断、停止条件を明記し、第三者が再現・レビューできれば合格とする。
章の受け入れ基準
読了時は、本章の主要成果物を第三者が再現・レビューできる状態にする。章別の正本は Chapter Acceptance Criteria を参照する。
関連書籍への接続
- 根拠確認や調査プロセスは『根拠で進める開発仕事術』へ接続する。
- Issue化、作業分割、完了判定は『チケット駆動の仕事術』へ接続する。
- 技術実装を伴う場合は『AIエージェント実践: Prompt / Context / Harness Engineering』へ接続する。
- AI時代の責任境界や判断設計は『AI時代のプロフェッショナルITエンジニアの思考法』へ接続する。
Source Notes
この章では、特定業界の法規制や社内規程の詳細には踏み込まない。固定手順ではなく状況に応じて経路・ツールを選ぶエージェントの定義には SRC-OPENAI-AGENTS と SRC-ANTHROPIC-TRUSTWORTHY-AGENTS を参照軸として用いる。実証研究は測定方法、対象者、時点、研究限界を併記し、自己申告と実測を区別する。金融、医療、人事、教育、公共、重要インフラ、個人情報を扱う業務では、自社の法務、セキュリティ、コンプライアンス担当と確認する。AIツールのデータ保持条件、外部送信条件、ログ保存条件も製品ごとに変わるため、実導入時には公式情報と社内規程を確認する。
まとめ
AI導入の第一歩は、プロンプトを書くことではなく、任せる仕事と解決方式を選ぶことである。通常ソフトウェアや固定ワークフローで目的を満たせるなら、それを採用する。AIエージェントは、状況依存の経路・ツール選択が必要で、追加の評価・権限・観測性コストを便益が上回る場合に選ぶ。高影響・例外判断、承認、リスク受容、説明責任は人間と組織に残す。
次章では、選んだ作業をAIに正しく依頼するための Request Contract を扱う。第2章で仕事を選び、第3章で依頼を仕様化し、第4章でコンテキストを渡す。この順序を守ることで、AI活用は偶然の成功ではなく、再現可能な仕事の型になる。