AI エージェントが効く業務、
5つのパターン。

「AI エージェントを導入したが、本番運用で使われていない」— こうした状態に陥る企業は珍しくありません。原因は技術選定やモデルの精度よりも、その業務が AI に向いているかどうかを見極めないまま導入していることにあります。本稿では、AI エージェントが成果を出しやすい業務を5つのパターンに分け、それぞれの見極め方をまとめます。実装でつまずきやすい点や PoC 設計の原則については、別稿「PoC で終わらせない — 本番運用に届ける7つの設計原則」で整理しています。

1. AI エージェントが効く業務の3つの条件

本稿でいう AI エージェントとは、指示を受けて情報を調べ、判断し、必要に応じて他のシステムの操作まで担う AI のことです。5つのパターンに入る前に、そもそも AI エージェントが効く業務に共通する3つの条件を確認しておきます。この条件を満たさない業務に AI を導入すると、コストが膨らむか、使われずに終わります。

1.1 業務の手順を言葉で説明できるか

業務の手順が文書になっている、あるいは「人に教えられる」程度には言葉にできることが前提です。AI に任せるには、何を渡して何を返してほしいかを、文章や表の形で決められなければなりません。職人芸のように言葉にできない手順の業務は、そもそも向きません。

1.2 文脈に応じた判断が必要か

判断ルールが完全に固定されているなら、RPA やスクリプトで十分です。AI エージェントが価値を出すのは、ルールでは書き切れないケースが多く、文脈に応じた判断が必要な業務です。

1.3 人手がボトルネックになっているか

業務量に対して人手が足りていない、あるいは品質のばらつきが問題になっている業務に効きます。人手がボトルネックになっていない業務に AI を導入しても、投資対効果（ROI）が見えにくくなります。「人間を置き換える」のではなく、「人手では回しきれない部分を補う」のが正しい使い方です。

2. 業務パターンを1枚の表で比べる

AI エージェントが効く業務を5つのパターンに分類します。各パターンに向く業務、向いているかの目安、実装の難しさ、月次コストの大小を、次の表に並べます。

3. パターンごとの向き・不向き

表だけでは見えない、各パターンの特性と落とし穴を1つずつ取り上げます。

3.1 リサーチ系 — 情報収集と要約

複数の情報源から情報を集め、要約して整理する業務です。LLM（大規模言語モデル）がもっとも得意とする領域で、最初の PoC として成功しやすいパターンです。ただし、参照元データの品質が低い場合や、情報を最新に保つことが難しい場合は、うまく機能しません。

リサーチ系は、本番運用で「使われない」リスクが意外に高い領域です。出力先（Slack の朝会への自動投稿、メールの定期配信など）まで設計しないと、せっかくの結果を誰も見ません。Kmetric の AI エージェント開発では、結果を誰にどう届けるかという出力先の設計まで、開発範囲に含めることを標準にしています。

3.2 定型系 — 形式の決まった作業の自動化

入力の形式は決まっているものの、中身は案件ごとに異なる業務です。たとえば、RPA で70%まで自動化できていた業務を、AI で90%以上に引き上げる、といった使い方です。ただし、AI でも処理しきれない例外がおおむね30%を超えると、例外処理の手間が膨らみ、運用が回らなくなります。そのため、出力の品質と例外の割合を自動で測る仕組み（出力品質の自動評価）を初日から組み込み、例外がこの水準を超えていないかを常に確認します。詳細は別稿「PoC で終わらせない — 本番運用に届ける7つの設計原則」でまとめています。

3.3 判断系 — 与信・リスク評価

過去の判断履歴から傾向を学ばせ、新しい案件に当てはめて判断する業務です。AI が大きな価値を出しやすい一方で、規制対応と説明責任が課題になります。医療や金融のように判断の理由を説明する責任がある領域では、AI の判断をそのまま採用することはできません。判断系は AI 単独で完結させず、AI の確信度が低いケースは必ず人間に回す設計にします。「全自動化」を目指すと、AI の精度の限界がそのまま業務品質の限界になり、頓挫しやすくなります。

3.4 対話系 — 顧客対応・社内 FAQ

人間との対話を継続的に行う業務です。LLM の会話能力を活かせる一方で、感情のこもった問い合わせへの対応が難しい点に注意が必要です。コールセンターを全自動化しようとして炎上した例は少なくありません。一次対応は AI、二次対応は人間という組み合わせが現実的です。

3.5 連携系 — システム間のワークフロー

複数のシステムの間で、人が手作業でデータを転記している業務です。AI が他のシステムを直接操作する使い方で、技術的にはもっとも複雑です。連携先システムの仕様が頻繁に変わる場合は向きません。プロダクト本体への組み込みを検討する場合は、別稿「既存プロダクトに AI 機能を載せる前に決めるべき5つのこと — データ・コスト・UX・セキュリティ・運用」も併せてご参照ください。

4. 導入後につまずき、立て直した3つのケース

現場でよく見られる典型的なケースを3つ取り上げます。いずれも、パターンの選び方や設計でつまずき、途中で立て直した例です。

4.1 コールセンターを対話系で全自動化 → 炎上

「コスト削減のため、対応を全自動化する」方針で対話系を立ち上げたケースです。クレーム対応で AI が形式的な回答を繰り返し、SNS で炎上しました。立て直しでは、FAQ の一次対応だけを AI が担い、感情を含む案件はすぐに人間へ引き継ぐ形に組み替えました。その結果、顧客満足度（CSAT）はかえって向上しました。

4.2 経費精算を定型系で導入 → 例外で破綻 → 判断系を追加

経費精算を定型系として導入し、当初は工数をおよそ半分に減らせたケースです。しかし、AI でも処理しきれない例外が30%を超え、例外処理の保守コストが、自動化した通常処理のコストを上回ってしまいました。そこで、例外案件の判断を受け持つ別のエージェントを判断系として追加し、二段構えの仕組みにしました。これにより、安定して運用できるようになりました。

4.3 営業リサーチの効果が見えず → 出力先を変えて定着

競合や顧客の調査を、リサーチ系のエージェントで自動化したケースです。技術的には成功したものの、出力が共有の Notion に蓄積されるだけで、誰も見ない状態に陥りました。Slack 上の朝会の冒頭に自動投稿する形に変えたところ、営業担当者全員が目を通す習慣が定着しました。技術ではなく、出力先の設計が成否を決めた例です。

5. 発注前に確認したい8つの質問

自社の業務が AI エージェントに向いているかを判断するための8つの質問です。

1. その業務の手順は文書になっているか、あるいは文書にできるか？
2. ルールでは書き切れず、文脈に応じた判断が必要か？
3. 現状、人手がボトルネックになっているか？
4. 業務量は年間1,000件以上あるか？
5. 過去の判断データ・FAQ・履歴は蓄積されているか？
6. AI でも処理しきれず人手に回る例外は30%未満か？
7. 規制対応や説明責任がどこまで求められるかを把握できているか？
8. 出力先（誰が・どこで・どう使うか）は設計できているか？

5つ以上が Yes であれば、いずれかのパターンで導入を検討する価値が十分にあります。Yes が4つ以下の場合は、AI エージェントより先に、業務改善・RPA・外注で解決できないかを確かめてください。

同じ見極めを5つの質問で点数化する AI 適合診断（1〜2分・登録不要）も用意しています。対象業務の適合度と、次に取るべき対応を、その場で確認できます。