AIはどの業務に渡してよいのか¶

業務適用設計者の判断基準¶

対象 / ポイント

対象: AI導入のPoCを任されたが、どの業務から始めるべきか迷っているエンジニア、テックリード、業務改善担当者。

ポイント:

AI導入の最初の仕事は、使うことではなく、渡してよい業務を切ること
判断密度、入力の安定性、例外の多さ、事故コストを見る
PoCは「1業務・1出力・1評価者・小さな件数」まで絞る

シリーズ

第0回: AI時代、価値はどこへ移るのか
第1回（この記事）: AIはどの業務に渡してよいのか

AIは文章を作れる。だから、すべての文書業務に入れればよい。

そう考えると、たいてい失敗する。

契約書の要約、障害報告の一次整理、問い合わせ返信の下書き、営業週報の集約。どれも「文章を扱う業務」だが、AIに渡してよい条件はまったく違う。

この記事の問いは、AIをどの業務に入れてよく、どの業務にはまだ入れない方がよいのか、である。

できる業務と、渡してよい業務は違う¶

AI導入で最初に見るべきなのは、モデルが何をできるかではない。その業務をAIに渡したとき、誰が、何を、どこまで確認できるかである。

たとえば、社内会議の要約はAIに渡しやすい。入力は議事録や文字起こしで、出力は要約であり、読み手は元情報と照合できる。多少の表現ズレがあっても、被害は比較的小さい。

一方で、顧客への最終回答や法務判断は違う。出力がそのまま外部に出れば、誤りは信用、契約、責任の問題になる。同じ「文章生成」でも、業務の重さが違う。

ここで必要なのは、AIの得意不得意ではなく、業務の性質を見る目である。

強い人は、業務の何を見ているのか¶

AIを業務に入れる人は、まず作業時間ではなく、判断の位置を見る。

時間がかかっている業務は、たしかに候補になる。しかし、時間がかかる理由が「単純な転記」なのか、「熟練者の判断」なのかで、扱いは変わる。前者はAI化しやすいが、後者は補助にとどめた方がよい場合が多い。

見る観点は、まず4つでよい。

判断密度: 出力にどれだけ人間判断が含まれるか
入力の安定性: 毎回似た形式で情報が入るか
例外の多さ: 通常パターンから外れるケースがどれだけあるか
事故コスト: 失敗したとき、誰にどこまで影響し、どれだけ戻しにくいか

McKinseyは、生成AIで価値を出す組織では、単にツールを配るだけでなく、業務の採用・拡張・KPIに踏み込む実践が重要だと整理している¹。これは、AI導入が「使う人を増やす話」ではなく、業務の流れそのものを見直す話であることを示している。

NIST AI RMF Core も、AIリスク管理では business context や、AIが支援する具体的な task / method を明確にすることを求めている²。つまり、業務の性質を先に見ることは、導入論だけでなくリスク管理の入口でもある。

業務は4つに分けると見通しがよくなる¶

業務適用設計では、業務をAI化するかどうかの二択にしない。 4つに分けると、議論がかなり楽になる。

先ほどの4観点は、この分類にそのまま効く。判断密度が低く、入力が安定し、失敗しても確認しやすい業務は「AIに渡す」候補になる。判断密度が高い、または入力が不安定な業務は、まず「AIで補助する」候補として見る。事故コストが大きく、評価条件も未整備なら、人間に残すか、今は触らない。

分類	一言ルール	例
AIに渡す	出力の確認が容易	週次報告の集約、FAQ更新案
AIで補助する	判断は人間に残す	障害報告の要点抽出、問い合わせ分類
人間に残す	誤りの責任が重い	契約判断、顧客への最終回答
今は触らない	入力や評価条件が未整備	部門横断の例外処理、未整備データ

重要なのは、「AIに渡す」だけが成功ではないことだ。

AIで補助するだけでも、業務は十分に軽くなる。たとえば問い合わせ対応では、返信文そのものをAIに任せなくても、過去履歴の要約、カテゴリ分類、関連FAQ候補の提示だけで、人間の判断時間は短くなる。

実務では、4列のホワイトボードを作るだけでもよい。候補業務を付箋で並べ、判断密度、入力の安定性、例外、事故コストを見ながら移動させる。この作業をすると、「AIに向くか」ではなく「どこまで渡せるか」の会話になる。

たとえば、問い合わせ対応をそのままAI化すると考えると広すぎる。しかし「問い合わせの一次分類」に絞ると、見え方が変わる。判断密度は中程度で、入力はある程度安定し、例外はあるが、出力を人間が確認しやすい。この場合、最初から最終返信まで渡すのではなく、分類候補と根拠の提示から始めるのが自然である。

観点	一次分類で見ること	判断
判断密度	カテゴリ選択は必要だが、最終判断ではない	AI補助に向く
入力の安定性	問い合わせ文、件名、過去対応履歴がある	試しやすい
例外の多さ	苦情、法務、解約などは分岐が必要	例外ラベルを作る
事故コスト	誤分類しても人間確認で戻せる	小さく試せる

このように、業務全体ではなく、業務の中のどの出力を切り出すかを見る。そこまで落とすと、PoC候補はかなり現実的になる。

Anthropicは、AIシステムを作るときは、まず可能な限りシンプルな解決策から始め、必要なときだけ複雑さを増やすべきだと述べている³。業務適用でも同じである。いきなり自律エージェント化する前に、まず「材料を整える」「下書きを作る」「候補を出す」から始めた方がよい。

flowchart TD
    A[対象業務を見る] --> B{判断密度は高いか}
    B -- 低い --> C{入力は安定しているか}
    C -- はい --> D{例外は多いか}
    D -- 少ない --> E[AIに渡す候補]
    D -- 多い --> F[AIで補助する候補<br/>例外検知と人間確認]
    C -- いいえ --> G[AIで補助する候補<br/>入力整備から始める]
    B -- 高い --> H{事故コストは大きいか}
    H -- 小さい --> I[AIで補助する候補<br/>判断材料を整える]
    H -- 大きい --> J[人間に残す / 今は触らない]

このフローは正解表ではない。ただ、PoC候補を選ぶ会議で、感覚論を減らすための補助線になる。

同じ「AIで補助する」でも、中身は複数ある。判断密度が高い業務では、AIは判断材料を整える役になる。入力が不安定な業務では、AIを使う前に入力を整える工程が必要になる。例外が多い業務では、AIに通常処理を任せる前に、例外を検知して人間へ戻す設計が必要になる。同じ箱に見えても、設計すべきものは違う。

PoCはどう切るべきか¶

PoCは、大きく始めるほど失敗しやすい。

「営業部のレポート業務をAI化する」では広すぎる。営業部には週報、商談メモ、顧客別サマリ、売上予測、上長報告がある。それぞれ入力も責任も違う。

最初は、1業務、1出力、1評価者、小さな件数まで絞る。

1業務: 問い合わせ分類だけを見る
1出力: カテゴリ名と根拠だけを出す
1評価者: 業務に詳しい人が合否を見る
小さな件数: 過去20〜50件で試す

ただし、小さく切ることは、本番化を考えなくてよい意味ではない。 PoCで見るべきなのは、単発の精度だけではない。件数を増やしたときに例外が増えないか、確認者の負荷が増えすぎないか、承認や権限の壁に当たらないか。小さいPoCは、本番で詰まりそうな条件を早く見つけるために切る。

OpenAIの企業向けレポートでは、同社のEnterprise利用において、Projects や Custom GPTs のような構造化された反復ワークフローの利用が伸びているとされている⁴。これは「Custom GPTsが一般企業の標準になった」意味ではない。大事なのは、AI活用が単発のチャットから、繰り返せる業務単位へ移っている点である。

Microsoft Copilot Studio も、AI agents と workflows を組み合わせて業務プロセスを自動化する方向を打ち出している⁵。ベンダー名は違っても、論点は同じだ。 AIは単発の回答より、繰り返せる業務の単位で設計され始めている。

PoCも同じだ。「すごい出力が出たか」ではなく、「同じ条件で繰り返したときに、人間が評価できるか」を見る。

AIで下がるもの、それでも下がらないもの¶

この層でAIが下げるのは、主に下書き、集約、変換、候補出しのコストである。

週次報告を集める。長い障害報告から論点を抜く。問い合わせをカテゴリに分ける。 FAQ更新案を作る。こうした作業は、入力と出力の型が見えればAIに渡しやすい。

ただし、業務の線引きは下がらない。同じ下書きでも、社内FAQの更新案と顧客への最終回答では扱いが違う。同じ分類でも、社内タグ付けと法務リスクの判定では事故コストが違う。

どの業務を対象にし、どこまでをAIに渡し、どの水準なら「使える」と判断するか。これは、業務適用設計の仕事である。

AIで実行が軽くなるほど、対象を切る判断の重みは増す。

この層で強い人は何を見ているか¶

業務適用設計で強い人は、AIの出力だけを見ない。業務の流れ、判断の位置、事故コスト、評価できる最小単位を見る。

さらに重要なのは、AI化の可否ではなく順序を見ることだ。最初に選ぶべきなのは、最も効果が大きい業務とは限らない。最も安全に失敗でき、評価しやすく、次に広げやすい業務である。

強い人は、こう言える。

「この業務はAIに渡してよい」「これは下書きまでにする」「これは人間に残す」「これは今は触らない」

この線引きができると、AI導入の議論は変わる。「AIを使うべきか」ではなく、「どの条件なら安全に試せるか」になる。小さく失敗できる業務から始める人ほど、結果的に大きく展開しやすい。

次に問題になるのは、複数人で使ったときの整合性である。 1人なら「この業務は下書きまで」と決めれば済む。しかしチームでは、人によって分類基準、命名、責務、レビュー基準がずれる。業務の線引きを共有できなければ、AI活用は速くなるほど散らかる。次は、チーム設計の話になる。