AIエージェント導入は「何ができるか」ではなく「何を任せるか」で判断する

「AIエージェント 何ができる」と検索を重ね、導入事例や業界別の活用例には一通り目を通した。それでも、社内の意思決定の場で「で、うちは結局、何から始めるのか」と問われたとき、具体像が浮かばないまま言葉に詰まってしまう。そのような体験をした方もいらっしゃるかと思います。

本記事では、AIエージェントの概要・できることを記載したうえで、AIエージェントを、これまでの企業システム導入の3つの時代(カスタム開発・SaaS・AIエージェント)の中での位置づけを整理し、AIエージェントは「何ができる」という視点から「何を任せるか」の視点に切り替える必要がある、ということを解説していきます。

AIエージェントでできること

AIエージェントとは

AIエージェントは、業務の目的や目標を伝えると、そこに至るまでの手順を自ら組み立てて、社内のシステムやデータを操作しながら自律的にタスクを進めていくAIです。

計画立案から実行、結果の評価、次の手の選択までを、一度の指示から進められる点に特徴があります。

生成AIとの違い

生成AIとの違いを一言で表すなら、「応答型」か「行動型」かです。

生成AIが「人間の問いかけに答える」ことを役割とするのに対し、AIエージェントは「人間から与えられた目標を達成するために自ら動く」ことを役割とします。

たとえば「会議の内容をまとめてチームに共有しておいて」という目標を渡すと、データの取得・要約・共有までをAIエージェントは自分で段取りして実行します。
人間の作業の1つを補助するのではなく、業務の一連の流れそのものを引き受ける点が決定的に異なります。

AIエージェントの活用例

AIエージェントは、業務単位で明確な目的が設計できる領域から、業種を問わず活用が広がりつつあります。

顧客対応の自動化としては、コールセンターの一次対応や、問い合わせ内容からの回答案生成、必要な部署への引き継ぎまでを担う運用が挙げられます。

地方銀行の融資関連問い合わせ、通販事業の返品受付、SaaS事業のカスタマーサポートのように、社内データベースを参照しながら顧客ごとの状況に応じた対応が必要な業務が、代表的な対象領域です。

このほかにも、業務の一連の手順が明確で、判断のルールを言葉に落とせる業務であれば、AIエージェント化の対象になります。

AIエージェントは定型業務を自動化できるが、導入はまず自社の業務を見つめることから始まる

「AIエージェント 何ができる」で検索した結果に並ぶ記事の多くは、業界別の活用例集か、機能の列挙か、海外と国内の先行大手の導入事例です。
どの記事も読みごたえはあり、概念整理にも役立ちます。

しかし、検索を始めた人の問いは別のところにあります。
「うちの業務でどう動くのか」「何から手を付ければよいのか」です。

機能の列挙は、この問いに直接答えてくれません。
「営業リスト作成ができる」「問い合わせ一次対応ができる」と書かれていても、自社の営業フローのどこに当てはまるのか、自社の問い合わせ業務のどの工程をAIに任せるのかが判断できない限り、社内会議の議題にはなりません。
読み終えても具体像にならないのは、提供されている情報の粒度と、必要な判断の粒度がずれているからです。

ずれを解消する一番の近道は、検索キーワードを置き換えることです。
「AIエージェントは何ができるか」ではなく、「自社のどの業務をAIエージェントに任せるか」。

問いの主語を「AI」から「自社業務」に置き換えるだけで、検討に必要な情報の集め方も、社内で交わすべき会話の中身も変わります。

なぜ「何ができるか」の発想が抜けにくいのか。
背景には、企業システム導入の歴史と関係する理由があります。

企業システム導入の3つの時代——カスタム開発・SaaS・AIエージェント

業務システムの導入のかたちは、これまでに3つの時代を経てきました。
自社業務に合わせて作る時代、規格化されたサービスに業務を合わせる時代、そしてAIが業務に合わせて動く時代です。

AIエージェントが今どんな位置にいるのかを理解するには、この3つの時代の違いを順に押さえておく必要があります。

カスタム開発の時代——自社業務に合わせて作る

1990年代以前、業務システムは自社専用に作るのが基本でした。
会計、人事、受発注、生産管理。いずれも自社の業務手順に沿った仕様で設計され、ベンダーに発注して数千万円規模の費用と数か月以上の期間をかけて構築されました。

自由度は高く、現場の独自ルールも反映できる代わりに、コストと時間の負担は重く、保守や仕様変更も発注に依存する状態が続きました。

1990年代中頃からは、ERPと呼ばれる業務統合パッケージが普及し始めます。
情報システムの調達は「自社で作る」から「市販品を買う」へ徐々に移り、自社業務に合わせる設計の比重は少しずつ下がっていきます(クラウドコンピューティングの歴史)。

SaaSの時代——サービスに業務を合わせる

業務システム導入の次の転機が、SaaSの登場でした。
1999年にMarc Benioff氏らが立ち上げたSalesforceが、CRMをブラウザ越しのサブスクリプションサービスとして提供し始めたところから、本格的なSaaS時代が始まりました(After 20 years of Salesforce — TechCrunch)。

同社が掲げた「No Software」というキャンペーンは、自社サーバーに重いソフトをインストールする時代の終わりを宣言する象徴でもありました。

日本国内では2018年あたりが「SaaS元年」と呼ばれることが多く、その後、業務領域ごとに国産SaaSが次々に立ち上がりました。

富士キメラ総研の調査によれば、SaaSなどクラウド提供形態の伸長を背景に、2025年度には法人向けソフトウェア市場全体が前年度比10%以上の伸長で3兆円を超える見通しとされています(日経クロステック報道)。

SaaSの普及とともに定着したのが、「業務をシステムに合わせる」という原則です。
標準機能の範囲で運用設計を組み、過度なカスタマイズは避ける。
これが、SaaS時代の導入プロジェクトの基本姿勢になりました(日経クロステック「カスタマイズのわな」)。

低コストでスピーディに導入できる代わりに、企業側が自社業務をサービスの形に寄せていく。「サービスに合わせる」やり方が、ここ十数年のSaaS導入プロジェクトの標準になりました。

AIエージェントの時代——業務にAIが合わせる

そして近年、これまでにない選択肢が業務システムに加わってきました。
LLM(大規模言語モデルと呼ばれる、人間の言葉を扱えるAIの中核モデル)の登場により、ソフトウェアが業務の文脈を理解し、判断や操作の一部を担えるようになってきたためです。

ここで、用語を一つ整理しておきます。
ChatGPTやClaudeを単体で使うようなケース、つまりチャット画面で問いに答える生成AIと、本記事で扱うAIエージェントは、別の枠組みとして区別する必要があります。
生成AIは「人の問いに答えるツール」、AIエージェントは「業務の中で目的に向けて動く担い手」と整理すると、両者の役割の違いがはっきりします。

AIエージェントは、与えられた目的に向けて自ら計画を立て、社内のデータや外部のシステムを操作しながら、結果を見て次の手を選ぶAIシステムを指します。

動かし方としては、社内ツール連携や社内データの参照をしながら、業務の中で自律的に進めていく形になります。
たとえば、顧客からの問い合わせ内容を読み取って、社内の顧客データベースを参照し、過去の類似案件を踏まえた回答案を組み立て、必要に応じて担当部署にメールを下書きするまでを、一度の指示で進められる、というイメージです。

この動き方は、SaaSのように「あらかじめ用意された機能」を選んで使うのとは性質が違います。
自社の業務手順・例外パターン・判断基準をAIに教え込み、AI側がそれに合わせて動く構造のため、これまでカスタム開発でしか実現できなかった「業務にシステムを合わせる」やり方を、SaaSに近いスピードと費用で取り組める段階に入ってきた、と整理できます。

カスタム開発時代の自由度と、SaaS時代の低コスト・スピードの両方を、同時に手にできる選択肢が現れた、というのが今の局面です。

「機能を選ぶ」と「業務を任せる」——SaaS発想とAIエージェント発想の頭の中の違い

SaaS導入の頭の中——機能カタログを眺めて選ぶ

SaaSの選定プロセスでは、まず候補となる製品の機能リストを集め、自社が必要とする機能との重なり具合を見ます。

次に、価格・サポート・既存システムとの連携可否を比較し、契約後はSaaSの仕様に沿って業務フローを組み直します。
判断者が答えるべき問いは「どの機能を選ぶか」。検討の出発点は市場にある機能カタログになります。

この発想がもたらすメリットは、選定スピードと予測可能性です。
比較対象が機能と価格に絞られるため、社内稟議も通しやすく、導入後の運用イメージも比較的明確です。

一方でデメリットも明らかで、自社固有の業務手順は、標準機能の枠に収まる範囲でしか反映できません。

AIエージェント導入の頭の中——業務を棚卸しして任せる範囲を決める

AIエージェント導入の検討は、機能カタログを眺めるところから始まりません。
出発点は、自社業務の棚卸しです。

どの業務に、どの程度の手間と時間がかかっていて、判断のルールはどう決まっていて、例外はどれくらい起きるのか。
これらを業務単位で整理して初めて、「この業務のうち、この部分をAIに任せ、ここは人が握る」という設計が成り立ちます。

判断者が答えるべき問いは「どの業務を、どう任せるか」。検討の出発点は自社業務の現状になります。

整理すると、両者の発想の違いは次の表のようになります。

このように、SaaSとAIエージェントでは、判断のために動かす情報の種類が根本から違います。
AIエージェントの導入判断は、機能のメニューから選ぶ作業ではなく、自社業務の現状をどう描き、何を任せるかを決める作業です。

AIエージェント導入で、DX・AI推進担当が押さえるべき5段階の判断軸

ここまでで、AIエージェントの導入判断は機能選びでは決まらないこと、判断の起点が自社業務にあることを確認しました。
続いて、その判断を実際にどう進めるかを5段階で整理します。

DXや業務改善のプロジェクトでは、As-is(現状把握)・To-be(理想の状態)・実装方法の設計・実装・効果測定という5段階のフレームが、業務改革を進める担当者にとってなじみのある語彙です。
AIエージェントの導入判断も、この5段階に沿って進めることで、SaaS型の「機能カタログから選ぶ」順序ではなく、業務改善プロジェクトと地続きの判断として進められます。

1. As-is(現状把握)——自社業務を業務単位で並べる

最初の段階は、機能ではなく業務の棚卸しです。
自社にはどんな業務が、どんな手順と頻度で動いているのかを業務単位で整理します。

業務単位の粒度は、「決まった結果を出すために繰り返している一連の手順」と捉えると分かりやすくなります。

たとえば、求人広告文の作成は「掲載案件の情報を受け取り、ターゲットに合わせた訴求軸を組み立て、媒体ごとに原稿を書き分けて、最後に校正する」までで一つの業務単位です。

ローン関連の証明書発行受付であれば、「顧客からの電話を受け、依頼内容を確認し、本人確認のための情報を聴取し、申請を受理する」までが一つの業務単位になります。

把握しておきたい情報は、業務にかかる総時間、関わる担当者の人数とスキル、判断のルールが明文化されているか、例外パターンがどの程度の頻度で発生するか、業務で扱うデータがどこにあるか、の5点を目安に整理します。

ここを飛ばすと、「AIエージェントで何ができるか」のリストから逆引きしてしまい、結局はSaaS型の機能選定に戻ってしまいます。

2. To-be(理想の状態)——任せた後に業務がどう変わるかを言語化する

棚卸しした業務のうち、AIに任せる候補を1つ選んだら、次は「任せた後に業務がどう変わるか」を言語化します。
ここで気をつけたいのは、コスト削減や時間削減だけで設計しないことです。

ヒューマンリソシアの事例では、AIエージェント基盤「つなぎAI」の導入により、年間約4,800時間の業務削減効果に加えて、「従来、担当者の経験やスキルに依存していた品質の安定化」が成果として公式に明示されています(ヒューマンホールディングス公式)。
量的な削減と、質的な底上げが並列に置かれている点に注目したいところです。

横浜銀行の事例でも、応対時間の5割削減という量的な効果と並んで、繁忙期の「つながらない」課題を解消して顧客の利便性を上げる、という顧客接点の改善が公式発表で説明されています(モビルス公式プレス)。

AIエージェントの導入効果は、件数や時間だけでは捉えきれず、業務全体・顧客接点・担当者の余白に及ぶ性質を持っています。

To-beを描くときには、コスト削減と並べて、業務の質、担当者の余白の使い方、関係者(顧客や現場)への影響まで言葉にしておきます。
「AIで自動化する」ではなく「業務全体がどう変わるか」を設計する意識が、後工程の効果測定にもそのまま生きてきます。

3. To-beになるための実装方法の設計——人とAIの分担と任せ方の段階を決める

To-beが設計できたら、それを実現する実装方法を定義・設計します。
ここでの問いは、業務の中のどこを人が握り、どこをAIに任せるか、です。

業務の中には、ルールが明確で繰り返し起きる部分と、例外的な判断や人の解釈が必要な部分があります。前者はAIに任せやすく、後者は人が握ったほうが品質と顧客体験が安定します。

先ほどの横浜銀行の事例では、ローン関連の証明書発行受付について、顧客が曖昧な答え方をしてもAIが登録情報から候補を提示して聞き取りを進め、申請完了までを担います。
AIで完結しないケースだけオペレーターが折り返し確認に入り、最終的な証明書発行の処理は本部の担当者が担う、という分担で実装されています(モビルス公式プレス)。

ヒューマンリソシアでも、ペルソナ設定から訴求軸の組み立てとテキスト生成までの「創造的な作業」をAIが担い、媒体ごとの転記など定型作業はRPA(ロボティック・プロセス・オートメーション、定型作業を自動化するソフトウェア)が処理する役割分担になっています(ヒューマンホールディングス公式)。

もう1つの設計テーマが、任せ方の段階です。
AIエージェントへの任せ方は、いきなり完全自動化に進む必要はなく、3つの段階を踏むのが現実的です。

第1段階は提案型で、AIが下書きや候補を作り、人が確認・修正してから採用する形です。

第2段階は監視型で、AIが実行まで担い、人は結果を点検します。

第3段階は自律型で、AIが実行と判断を担い、人は例外時にだけ介入します。

段階を上げる条件は、「成果が安定していること」と「例外パターンが見えていること」の2点に絞れます。

Anthropic社も公式記事の中で、「最も単純な構成から始め、明らかな改善があるときだけ複雑さを増やす」と推奨しており、設計原則として「シンプルさを保つ」「計画ステップの透明性を担保する」の2つを並べています(Anthropic公式)。

最初から段階3を狙うのではなく、段階1から始め、運用の中で段階を上げていくのが基本姿勢になります。

4. 実装——小さく始め、運用で段階を上げる

実装段階で意識しておきたいのは、いきなり業務全体を任せないこと、最初の運用は計画通りに動かない前提で組むこと、の2点です。

業務単位で限定して始めると、想定外の例外パターンや、運用上の調整が必要な箇所が早く見えてきます。
プロンプトの調整、AIに渡す業務マニュアルの追加、社内ツールとの接続範囲の拡張、人が介入すべきタイミングの再設計。
これらの調整は、机上の設計だけでは出てこず、運用しながら積み上げるしかありません。

注意点としては、最初から先行大手の事例の「業務全体」を真似ようとしないことが挙げられます。
先行大手の事例は、複数の業務単位を組み合わせた最終形であることが多く、出発点の業務単位を一つに絞らないと、PoCで止まってしまう恐れが高くなります。

5. 実装後の効果測定——「業務がどう変わったか」で見る

実装が動き始めたら、効果を測ります。
ここでの注意は、件数や時間削減だけを成果指標にしないことです。

評価軸として置きたいのは、業務にかかる総時間、担当者のスキル依存度の変化、例外対応に費やす人の時間、担当者の余白の使い方、顧客や現場への影響、の5つを目安にします。

効果測定の結果は、次の意思決定に直結します。
成果が安定しているなら、任せ方の段階を上げる。
別業務への展開が見えてきたなら、新しい業務の棚卸しに進む。
期待した効果が出ていないなら、To-beの設定そのものを見直す。

5段階は一方通行ではなく、効果測定をきっかけに行き来する循環のフレームとして使うことを想定しています。

まとめ——AIエージェント導入は「何ができるか」ではなく「何を任せるか」で判断する

ここまで、AIエージェント導入の判断を、機能カタログから選ぶSaaS型の発想ではなく、自社業務を起点に「何を任せるか」を決める発想で進めるという視点から整理してきました。
最後に、本記事で示した内容を振り返ります。

企業システム導入には、3つの時代がありました。
自社業務に合わせて作るカスタム開発の時代、規格化されたサービスに業務を合わせるSaaSの時代、そしてAIが業務に合わせて動くAIエージェントの時代です。
AIエージェントは、カスタム開発時代の自由度とSaaS時代の低コスト・スピードを同時に手にできる選択肢として、業務システムの世界に加わってきました。

この新しい局面では、SaaSのように機能カタログを眺めて選ぶ発想だけでは判断ができません。
自社業務を業務単位で棚卸ししたうえで、どの業務をAIに任せ、人とどう分担し、どの段階で任せ、どう評価するかを決めることが、判断の土台になります。

本記事では、業務改善プロジェクトでなじみのある5段階のフレーム(As-is・To-be・実装方法の設計・実装・効果測定)に沿って、それぞれの段階で押さえる判断軸を整理しました。

「何ができるか」を問い続けても具体像は結ばず、「何を任せるか」と問い直したときに初めて、判断のための情報が集まり始めます。
社内で議論を始めるときも、製品紹介から入るのではなく、自社業務の棚卸しから始めるのが、結果としてもっとも近い道筋ではないかと考えています。