AIエージェントで自動化できる業務20選｜部門・用途別にできることを解説

更新日

2026年7月29日

確認時点

2026年7月29日時点

「AIエージェントで何ができるのか」を調べると、抽象的な説明か、他社の成功事例のどちらかが出てきます。自社のどの業務を任せられるのかは、そこからは読み取れません。判断に必要なのは、業務ごとに「何を入れると、何が返ってきて、人間はどこを確認するのか」がわかることです。AIエージェントは情報を生成するだけでなく、CRMやチケット管理、会計、メール、カレンダー、開発環境へ接続し、複数の作業を順番に実行できます。

検討の初期に繰り返し出る疑問を7つに絞り、それぞれ1行の答えを添えました。判断の分かれ目になりやすい順に並べています。

疑問	短い答え
生成AIチャットとの違いは何か	チャットは回答を作り、エージェントは外部システムを操作して結果を記録します
RPAとの違いは何か	RPAは決められた手順を実行し、エージェントは状況に応じて手順を選びます
どの部門から始めるべきか	繰り返し発生し、完了条件が明確で、失敗しても戻せる業務からです
全部自動化できるのか	できません。例外が大半を占める業務と最終判断は人間が担います
任せてはいけない業務は何か	送信、契約、決済、削除、採用や人事評価の最終決定です
何を測れば効果がわかるのか	作業時間だけでなく、人間の介入なしで完了した割合を測ります
どうやって候補を絞るのか	事業効果、実現性、データ、リスク、測定可能性の5点で採点します

※ 業務は一般的な形に整理したものです。特定の製品で同じことが実現できることを示すものではありません。

まず、AIエージェントができることの全体像を4つの動作に分けて整理します。

本記事は、業務を一般的な形に整理したものです。実在企業の社名や導入成果はAIエージェントの活用事例をまとめた記事で扱っています。仕組みの詳細を確認したい場合はAIエージェントの仕組みを解説した記事をご覧ください。

AIエージェントができることは「調べる・判断する・操作する・記録する」

できることを機能名で覚えても、自社の業務に当てはめられません。動作の型で捉えると、任せられる範囲が判断しやすくなります。先に、本記事で繰り返し出てくる用語を整理します。

GLOSSARY

この記事で使う用語

PoC

本番導入の前に、限定した範囲で実現性と効果を検証する工程

最小権限

業務に必要な操作だけを許可し、それ以外は実行できない状態にする設計

エスカレーション

自動処理では対応できない案件を、担当者や上位者へ引き継ぐこと

不可逆な操作

送信、決済、削除のように、実行した後に取り消せない操作

完了条件

その業務が終わったと判断するための基準。曖昧なままでは自動化できない

承認者

エージェントの出力を確認し、実行を許可する責任を持つ人

FEATURES

AIエージェントの4つの動作

1

調べる

社内文書、CRM、Web、ログなどから必要な情報を集めて整理する

2

判断する

集めた情報を基準に照らし、分類や優先順位付け、次の手順の選択を行う

3

操作する

CRMの更新、チケットの作成、メールの下書き、コードの変更など外部システムへ働きかける

4

記録する

実行した内容と結果を残し、次の判断や人間の確認に使えるようにする

この4つのうち、従来のツールと決定的に違うのは3番目です。回答を返すところで止まらず、システムを操作して状態を変えます。だからこそ権限の設計が必要になります。

生成AIチャットは回答を作る

生成AIチャットの役割は、質問に対して文章や表を生成することです。調べた内容をまとめる、文案を作る、要約する作業には向いています。

一方で、生成した内容を実際のシステムへ登録する工程は人間が行います。作業の起点と終点に人間が立つ構造です。

RPAは決められた手順を実行する

RPAは、あらかじめ定義した手順を正確に繰り返します。同じ画面、同じ項目、同じ順序で処理する業務では安定して動きます。

弱点は例外への対応です。条件分岐を事前に書き出す必要があるため、取引先ごとに扱いが微妙に違う業務では設定が膨らみます。

AIエージェントは状況に応じて手順を選び実行する

AIエージェントは、目標を渡すと手順を自分で組み立てます。必要な情報を集め、判断し、外部システムを操作し、結果を記録するところまでを一続きで行います。

観点	生成AIチャット	RPA	AIエージェント
主な出力	文章、要約、表	画面操作の実行	判断と操作の連続実行
手順の決め方	人間が指示	事前に定義	状況に応じて選ぶ
例外への対応	人間が判断	分岐を事前定義	条件を判断して処理
外部システムの操作	行わない	行う	行う
実行結果の記録	人間が転記	ログとして残る	記録して次に使う

※ 自社の業務がどの型に当てはまるかで、導入すべき仕組みが変わります。

表のとおり、3つは競合するものではありません。定型部分をRPAに任せ、判断が必要な部分をエージェントが担い、文案作成はチャットで済ませる、という組み合わせも成立します。

重要な操作には人間の承認を入れる

自律性を上げるほど、人間が介入する機会は減ります。減らした分をどこで補うかを決めないまま導入すると、想定外の操作に気づくのが結果を見たあとになります。

承認を入れる基準は単純です。取り消せない操作、金銭が動く操作、社外へ出ていく操作の3つには、実行前の確認を挟んでください。

営業部門でできること4選

営業は、情報収集と記録の工数が大きく、かつシステムをまたぐ作業が多い部門です。CRM、メール、カレンダー、会議ツールに分散した情報を横断できると効果が出やすくなります。

番号	業務	主な成果物	人間が確認する点
1	見込み顧客の調査とリスト作成	営業リスト、優先順位	個人情報、スコアの根拠
2	商談前の情報収集とアジェンダ作成	商談ブリーフ、質問リスト	事実関係、機密情報
3	提案書・メール・フォローの作成	提案書ドラフト、メール下書き	金額、契約条件、送信
4	商談後の議事録とCRM更新	議事録、CRM更新、タスク	決定事項、受注確度

※ 接続先や成果物は一般的な例です。自社の環境に合わせて読み替えてください。

4業務のうち、最初に試しやすいのは4番です。商談後の記録は発生頻度が高く、失敗しても取り返しがつき、削減された時間が実感しやすいためです。

1. 見込み顧客の調査・リスト作成・優先順位付け

ターゲット条件と既存顧客データを渡すと、企業情報を収集し、CRMと照合してニーズを分類し、優先度をつけたリストを返します。接続先はWeb、CRM、企業データベース、ニュースです。

人間が確認すべきは、個人情報の取り扱い、対象企業として妥当かどうか、そしてスコアの根拠です。優先度の数字だけを受け取っても、なぜその順位なのかを説明できなければ営業現場では使われません。

2. 商談前の情報収集・アジェンダ作成

顧客名と過去の商談履歴を渡すと、企業ニュース、決算情報、過去のメール、CRMの記録を要約し、想定質問を含むアジェンダを作ります。

確認すべきは事実関係と、社外へ出せない機密情報が混ざっていないかです。推測を断定として書いてしまう失敗が起きやすいため、根拠のない記述が含まれていないかを見てください。

3. 提案書・メール・フォローアップの作成

商談メモと商品資料から提案の骨子を作り、顧客ごとの文章、フォロー案、次回日程の候補までを用意します。ドキュメント、スライド、メール、カレンダーへ接続します。

ここは承認を挟むべき領域です。金額と契約条件は誤りが直接損失につながり、送信は取り消せません。下書きの作成までを任せ、送信は人間が行う構成にしてください。

4. 商談後の議事録・CRM更新・タスク登録

会議の音声または文字起こしから、決定事項、課題、担当者、期限を抽出し、CRMの更新案とタスクを作ります。会議ツール、CRM、タスク管理ツールへ接続します。

確認するのは決定事項の正確さ、受注確度の判断、そして顧客へ共有する内容です。受注確度をエージェントに決めさせると、予測の精度ではなく責任の所在が問題になります。

マーケティング部門でできること3選

調査と集計の比重が高く、扱うデータの出所が多い部門です。出典管理を仕組みに組み込めるかどうかが、成果物をそのまま使えるかを左右します。

番号	業務	主な成果物	人間が確認する点
5	市場・競合・顧客ニーズの調査	調査レポート、競合比較	出典、更新日、推測と事実の区別
6	コンテンツ企画・制作・公開管理	企画、構成、原稿、更新タスク	事実、独自性、著作権、公開
7	広告・キャンペーンの集計と改善案	日次レポート、アラート、改善案	予算変更、配信停止、因果関係

※ 広告データやアクセス解析への接続は、権限設定を先に決めてください。

3業務のうち、7番は日次で発生するため効果が積み上がります。一方で予算に直結するため、変更の実行は人間が行う設計が前提です。

5. 市場・競合・顧客ニーズの調査

調査テーマと競合名を渡すと、Web、公開資料、SNSを調べ、論点を分類して出典付きの要約を返します。

確認すべきは出典と更新日です。古い情報が現在の状況として書かれる、推測が事実として書かれる、という2つが典型的な失敗です。出典が付いていない記述は使わない、という運用ルールを先に決めてください。

6. コンテンツ企画・制作・公開管理

ペルソナ、キーワード、編集方針、過去記事を渡すと、検索意図の整理、企画、構成、下書き、校正、入稿準備、既存記事の更新候補までを進めます。Search Console、CMS、ドキュメント、タスク管理へ接続します。

人間が確認するのは、事実の正確さ、独自性、著作権、そして公開の判断です。公開の実行は人間が行ってください。 誤りを含んだ記事の公開は、取り下げても検索エンジンやSNSに残ります。

7. 広告・キャンペーンの集計・分析・改善案

広告データ、アクセス解析、CRM、予算情報を横断して集計し、異常を検知し、セグメント別の分析と改善案を作ります。

確認すべきは予算変更と配信停止の判断、そして因果関係の解釈です。数値の相関を因果として説明する誤りが起きやすいため、改善案の根拠を人間が読める形で出させてください。

カスタマーサポートでできること3選

問い合わせの分類から回答、記録までが一連の流れになっており、エージェントの動作と相性がよい領域です。ただし顧客と直接つながるため、誤りの影響が外部へ出ます。

番号	業務	主な成果物	人間が確認する点
8	問い合わせの分類・回答案作成・自動応答	分類、回答案、自動返信	返金、解約、クレーム、法的問題
9	オペレーター向けナレッジ検索と対応提案	回答根拠、推奨手順、確認項目	適用条件、最新の規約
10	チケット更新・エスカレーション・フォロー	担当割当、エスカレーション、タスク	重大障害、返金・補償、最終説明

※ 自動応答の対象は、低リスクな問い合わせに限定してください。

3業務のなかで導入の難易度が低いのは9番です。顧客へ直接出力せず、オペレーターの手元で使う構成なので、誤りが外部へ出ません。

8. 問い合わせの分類・回答案作成・自動応答

メール、チャット、フォームから届いた問い合わせについて、意図と緊急度を分類し、FAQを検索して回答案を作ります。低リスクな問い合わせには自動で応答する構成も取れます。

自動応答の対象から外すのは、返金、解約、クレーム、法的または安全上の問題を含む問い合わせです。自動応答の範囲は「間違えても謝罪で済む内容」に限定してください。

9. オペレーター向けナレッジ検索・次の対応提案

顧客の質問、契約や購入の履歴、過去の対応履歴を参照し、関連マニュアルを検索して類似事例を抽出し、次に確認すべき項目を提示します。

確認すべきは適用条件と最新の規約です。過去の対応履歴を根拠にすると、規約改定前のルールを案内してしまう失敗が起きます。参照する文書のバージョン管理を先に整えてください。

10. チケット更新・エスカレーション・対応後フォロー

問い合わせ内容とSLAをもとに担当を判定し、優先度を設定してチケットを更新し、期限を管理してフォローメールを準備します。

重大障害、返金や補償、顧客への最終説明は人間が担います。エスカレーションの判定基準をエージェントに任せる場合、判定を誤ったときに気づける通知の仕組みを併せて用意してください。

顧客対応は自動応答の範囲設計がそのまま品質に出るため、導入前に「間違えても謝罪で済む内容」の線引きを文章にしておいてください。

バックオフィスでできること4選

書類の突き合わせと照合が多く、判断基準を文章化しやすい業務が並びます。金銭と契約に直結するため、承認設計の比重がもっとも大きい部門です。

番号	業務	主な成果物	人間が確認する点
11	請求書・領収書・経費データの確認と登録	登録データ、差異一覧、承認依頼	支払い、税区分、高額・例外申請
12	契約書・規程・申請書の確認支援	差分表、リスク候補、確認事項	法的判断、契約締結、例外承認
13	購買候補の調査・見積比較・発注フロー	比較表、推奨候補、稟議ドラフト	取引先決定、金額、発注、利益相反
14	会議設定・議事録・決定事項・タスク管理	会議招待、議事録、タスク	決定事項、担当者、社外共有内容

※ 支払いと契約締結の実行は人間が担う前提で設計してください。

4業務のうち14番は、部門を問わず発生するため横展開しやすい候補です。11番から13番は金銭が動くため、承認の設計を先に固めてください。

11. 請求書・領収書・経費データの確認と登録

請求書や領収書を読み取って項目を抽出し、発注や契約と照合して重複と異常を検知し、会計システムへの登録案を作ります。

人間が確認するのは支払いの実行、税区分の判断、そして高額または例外的な申請です。読み取りと照合まではエージェント、支払いの承認は人間、という線引きが基本形になります。

12. 契約書・規程・申請書の確認支援

契約書案と自社のひな形を比較して条項の差分を出し、抜け漏れを指摘し、社内基準と照合して確認すべき質問を作ります。

ここで扱えるのは確認の支援までです。法的な判断、契約の締結、例外の承認はいずれも人間が行います。差分表を法務チェックの代わりにしないでください。

13. 購買候補の調査・見積比較・発注フロー

購買要件と予算を渡すと、候補を収集し、条件の異なる見積書を比較できる形に正規化して差異を抽出し、稟議のドラフトまで作ります。

確認すべきは取引先の決定、金額、発注の実行、そして利益相反です。比較表の作成は任せられますが、どこと取引するかの判断は人間の領域です。

14. 会議設定・議事録・決定事項・タスク管理

参加者とカレンダーから日程を調整し、アジェンダを作り、会議後は議事録から担当と期限を抽出してリマインドまで設定します。

確認するのは決定事項の正確さ、担当者の割り当て、社外へ共有する内容です。議事録の誤りは、後から「そんな話はしていない」という認識のずれを生みます。

人事部門でできること3選

規程の検索と手続きの管理には向く一方、評価と採否の判断は任せられません。この線引きがもっとも明確な部門です。

番号	業務	主な成果物	人間が確認する点
15	求人票作成・候補者情報整理・面接準備	求人票、候補者サマリー、面接資料	採否、評価、バイアス、個人情報
16	入社手続き・オンボーディング・研修支援	入社タスク、研修計画、進捗アラート	権限、労務手続き、研修完了
17	従業員からの社内問い合わせ・申請案内	回答、申請リンク、エスカレーション	個別の労務判断、例外、健康情報

※ 採否と評価の最終決定は人間が行う前提で設計してください。

3業務のうち17番は、対象が社内の従業員で、参照する文書が規程に限定されるため、精度を管理しやすい候補です。

15. 求人票作成・候補者情報整理・面接準備

採用要件と職務内容から求人票のドラフトを作り、応募書類の情報を整理し、面接の質問と日程を用意します。

人間が確認するのは採否、評価、バイアスの有無、個人情報の取り扱いです。候補者の絞り込みや評価をエージェントに委ねると、判断根拠を説明できなくなります。 情報整理までを任せ、評価は人間が行ってください。

16. 入社手続き・オンボーディング・研修支援

入社日、職種、所属、必要な権限をもとに手続きの一覧を作り、アカウント申請を進め、研修計画を立てて進捗を確認します。

確認すべきは付与する権限、労務手続きの適正さ、研修の完了判定です。権限の申請を自動化する場合、付与の承認は必ず人間が行う構成にしてください。

17. 従業員からの社内問い合わせ・申請案内

就業規則、福利厚生、経費や休暇の規程を検索し、条件付きの回答を返して申請方法を案内し、必要に応じて担当部署へ転送します。

確認すべきは個別の労務判断、例外の扱い、そして健康や懲戒、評価に関する情報です。これらは個人の事情に踏み込むため、エージェントには回答させず担当者へつなぐ設計にしてください。

IT・開発・データ部門でできること3選

ログや構造化データを扱うため、判断基準を明確にしやすい領域です。一方で本番環境への変更が絡むと、影響範囲が一気に広がります。

番号	業務	主な成果物	人間が確認する点
18	ITヘルプデスク・障害切り分け・アカウント申請	解決手順、チケット、申請	管理者権限、アカウント発行、本番変更
19	コード作成・テスト・レビュー・修正支援	コード、テスト、PR、変更説明	設計、セキュリティ、マージ、デプロイ
20	データ収集・クレンジング・分析・レポート作成	データセット、グラフ、レポート	指標定義、因果関係、個人情報

※ 本番環境への反映は人間の承認を通す前提で設計してください。

3業務のうち18番は、問い合わせの多くが既知の症状に該当するため、ナレッジ検索の効果が出やすい候補です。

18. ITヘルプデスク・障害切り分け・アカウント申請

問い合わせ内容、端末情報、ログから問題を分類し、ナレッジを検索して診断し、チケットと申請案を作ります。

人間が確認するのは管理者権限の付与、アカウントの発行、インシデントの判定、本番環境の変更です。診断と手順の提示までを任せ、実行は人間が行う構成が基本になります。

19. コード作成・テスト・レビュー・修正支援

Issueと要件、リポジトリ、コーディング規約を渡すと、タスクを分解してコードを書き、テストを実行し、修正してプルリクエストを作り、レビュー指摘まで出します。

確認すべきは設計の妥当性、セキュリティ、レビュー、マージ、本番デプロイです。マージとデプロイは人間の承認を通してください。 テストが通ることは、設計が正しいことを意味しません。

20. データ収集・クレンジング・分析・レポート作成

データベースやCSV、BIツールから必要なデータを集め、欠損と異常を確認し、集計と分析を行って可視化し、異常があればアラートを出します。

確認すべきは指標の定義、因果関係の解釈、個人情報の扱いです。同じ「売上」でも部門ごとに定義が違うことがあるため、指標の定義を先に固めてから任せてください。

経営・業務管理は分析結果を横断的に使う

経営管理そのものは、独立した業務として切り出すより、他部門の成果を横断的に使う形が現実的です。20番のデータ分析で作った土台を、経営の視点で読み替える使い方になります。

KPIを定点観測し、異常を担当者へ通知する

複数部門の指標を定期的に集計し、閾値を超えた項目を担当者へ通知します。定点観測は発生頻度が高く、人が毎回同じ作業をするため、任せる価値があります。

通知の設計で重要なのは、誰に届くかです。全員に届く通知は誰も見なくなります。

複数部門の情報をまとめて経営レポートを作る

営業、マーケティング、サポート、バックオフィスの数値をまとめ、レポートのドラフトを作ります。部門ごとに散らばった集計を1つの形式へ揃える作業に向いています。

ここで注意したいのは、部門ごとの指標定義のずれです。定義が揃っていない数値を並べると、比較できない表ができあがります。

予測・改善案を提示し、人間が意思決定する

過去の推移から予測を出し、改善の候補を提示するところまでは任せられます。ただし経営判断そのものは人間が行います。

編集部としては、予測の数値を根拠として使う前に、その予測がどのデータのどの期間から出たのかを説明させることをおすすめします。説明できない予測は判断材料になりません。

AIエージェントに向いている業務・向いていない業務

20業務のなかから自社の候補を選ぶ前に、業務そのものの性質を確認してください。任せられるかどうかは、業務の内容ではなく条件で決まります。

＋向いている業務の条件

• 繰り返し発生する
• 複数システムをまたぐ
• 入力と完了条件が明確である
• 判断基準を文章化できる
• 失敗しても停止・修正できる
• 人間の確認を途中に入れられる
• 作業量を測定できる

−向いていない業務の条件

• 目的と完了条件が曖昧である
• データが不足または矛盾している
• 例外が処理の大半を占める
• 一度の誤りで重大な損失が出る
• 法律・医療・採用・人事の最終判断である
• 不可逆な操作を無承認で実行する
• 責任者が決まっていない

判断基準を文章化できるかが分かれ目になる

向いている条件のうち、実務でもっとも効くのは4番目です。担当者が経験で判断している業務は、基準を書き出す作業から始まります。

基準が書けない状態でエージェントを入れると、期待と違う出力が返ってきます。そのとき原因が製品の性能なのか基準の不在なのかを切り分けられません。手順が標準化されていない業務は、先に手順を書き出すほうが早く進みます。

例外が大半を占める業務は対象から外す

向いていない条件のうち、判断を誤りやすいのは3番目です。件数が多い業務は自動化の候補に見えますが、そのうち8割が例外処理であれば、確認の手間が増えるだけになります。

まず1か月分の処理を数え、標準処理と例外の比率を出してください。標準処理が過半を占めていなければ、別の業務を選ぶほうが確実です。

責任者が決まっていない業務は着手しない

自社で試す業務を選ぶ5つの基準

20業務のなかから最初の候補を選ぶには、5つの観点で採点する方法が実用的です。感覚で選ぶと、社内の合意が取りにくくなります。

○最初の候補にしてよい業務

• 社外へ出力が出ない
• 既存システムへ読み取りだけで接続できる
• 同じ処理が週に何度も発生する
• 担当者が工数を答えられる

×今回は候補から外す業務

• 顧客や取引先へ直接届く出力を含む
• 接続先の仕様が社内で把握できていない
• 月に数件しか発生しない
• 担当者が業務を掛け持ちで回している

採点表で候補を並べる

各業務を次の5項目で採点し、合計点の高いものから3件を選んでください。

評価項目	1点	3点	5点
事業効果	小さい	中程度	大きい
実現性	低い	条件付き	高い
データ	不足	一部整備	整備済み
リスク	高い	管理可能	低い
測定	困難	一部可能	明確

※ 判断列を自社の条件で上書きしてお使いください。合計25点満点です。

表のうち、点が伸びにくいのは「データ」です。整備済みと判断できる業務は多くありません。一部整備の段階でも着手はできますが、その場合は精度の期待値を下げて評価してください。

利用者が必要としているかを軽視しない

3番目の基準は見落とされがちです。技術的に実現できて効果も測れる業務でも、現場が必要としていなければ使われません。

編集部としては、候補を決める前に実際の担当者へ「この作業に毎週どれだけ時間を使っているか」を聞くことをおすすめします。工数の実感がない業務を自動化しても、成果として認識されません。

導入時に確認するシステムと権限

エージェントに外部システムへの接続を許可する段階から、設計の重心が権限へ移ります。ここを後から追加すると、要件定義のやり直しになります。

参照だけか、更新・送信まで行うか決める

最初に決めるのは接続の性質です。読み取りのみの接続と、書き込みや送信を伴う接続では、失敗したときの影響がまったく違います。

読み取りだけで成立する業務は、権限設計が簡単になります。まずこの範囲で試し、必要になった段階で書き込みを許可する進め方が安全です。

FEATURES

接続の3段階と設計の重さ

1

参照のみ

データを読むだけ。誤っても元に戻せるため、最初の検証に向く

2

更新まで

社内データを書き換える。差分の記録と切り戻し手順が必要になる

3

送信まで

社外へ出る、または金銭が動く。実行前の人間の承認が前提になる

最小権限と実行できる操作を設定する

必要な範囲を超えた権限を渡さないでください。フォルダ単位、テーブル単位、操作単位で絞り込み、許可した操作以外は実行できない状態にします。

人間の承認が必要な操作を決める

承認を挟む操作を業務単位で列挙してください。判断の基準は、取り消せるかどうか、金銭が動くかどうか、社外へ出るかどうかの3点です。

実行ログ・アラート・停止方法を用意する

個人情報・機密情報の保存と学習利用を確認する

投入したデータがどこに保存され、どれだけの期間残り、モデルの学習に使われるかを確認してください。あわせて、データ処理契約を締結できるかも確認事項になります。

AIエージェントの効果を測るKPI

作業時間の削減だけを見ると、効果を過大に評価します。人間が確認と修正に使った時間を含めて測ってください。

KPI	測定例	測るタイミング
作業時間	1件あたりの処理時間	導入前と導入後
完了率	人間の介入なしで完了した割合	導入後、週次
修正時間	成果物を人間が直す時間	導入後、週次
エラー率	誤分類、誤更新、誤回答の件数	導入後、継続
対応速度	初回応答と解決までの時間	導入前と導入後
コスト	1件あたりのAPI・利用料	導入後、月次
利用率	対象者が継続して使っている割合	導入後、月次
事業成果	商談数、CV、解約、障害件数など	導入後、四半期

※ 導入前の値を記録していないと比較できません。着手前に測定してください。

8つのうち、もっとも重要なのは「完了率」と「修正時間」の組み合わせです。作業時間が短くなっても、修正に同じだけ時間がかかっていれば効果は出ていません。

＋導入前に測ることで得られるもの

• 効果を数字で社内に説明できる
• 想定より効果が薄い業務を早く見切れる
• PoCの合否基準を事前に決められる
• 他部門へ展開するときの見積もりに使える

−測らずに始めた場合に起きること

• 効果の議論が体感の話に終始する
• 本番導入の承認を得る材料が揃わない
• 改善したのか悪化したのか判別できない
• 同じ業務で再検証しても比較できない

導入前の値を測らずに始めない

比較の基準がないと、効果の議論が印象論になります。着手前に、対象業務の1件あたり処理時間、月間の件数、現在のエラー件数の3つを記録してください。

数回分の実測でも十分です。正確な平均値より、比較できる基準があることが重要です。

利用率が落ちたら設計を見直す

導入直後は使われても、数週間で利用が止まる例があります。原因は精度ではなく、確認の手間が現場の許容範囲を超えていることが多いです。

利用率を月次で見て、下がっているようであれば承認の粒度を見直してください。

AIエージェント導入を進める6ステップ

いきなり本番業務へ入れると、うまくいかなかったときに原因を特定できません。次の6ステップで進めてください。

1

20業務から候補を3件選ぶ

STEP1

この記事の採点表で各業務を5項目で採点し、合計点の高いものから3件を選びます。1件だけに絞ると比較対象がなくなり、選択の妥当性を評価できません。

2

現在の工数・件数・エラー率を測る

STEP2

対象業務の1件あたり処理時間、月間の件数、現在のエラー件数を記録します。数回分の実測で構いません。この記録がないと、後で効果を証明できません。

3

入力・完了・禁止操作を定義する

STEP3

何を渡すか、どうなったら完了とするか、そして何をさせないかを文章にします。禁止操作の例は、本番データの削除、社外へのメール送信、決済、契約変更です。

4

同じ業務でPoCを実施する

STEP4

3件の候補について、同じ条件でPoCを行います。業務ごとに条件を変えると、結果の差が業務の差なのか条件の差なのか判別できません。

5

精度・工数・費用・リスクを評価する

STEP5

完了率、修正時間、エラー率、1件あたりのコストを並べて評価します。作業時間の削減だけで判断しないでください。

6

本番導入・改善・他部門展開を判断する

STEP6

評価結果をもとに、本番導入、条件を変えて再検証、中止のいずれかを選びます。他部門への展開は、1つの業務で安定してから検討してください。

よくある質問

検討の途中でつまずきやすい点を、8つの質問にまとめました。

FAQ

AIエージェントでできることに関するよくある質問

Q.AIエージェントは何でも自動化できますか？−

A.

できません。向いているのは、繰り返し発生し、入力と完了条件が明確で、失敗しても停止・修正できる業務です。目的が曖昧な業務、例外ばかりの業務、失敗の影響が大きすぎる業務は対象から外してください。法律、医療、採用、人事評価の最終判断も人間が担います。

Q.生成AIやChatGPTとの違いは何ですか？+

Q.RPAとの違いは何ですか？+

Q.最初に自動化すべき業務は何ですか？+

Q.AIエージェントに任せてはいけない業務は何ですか？+

Q.実際の企業ではどのように使われていますか？+

Q.どのサービスを使えばよいですか？+

Q.自社専用のエージェントを作るにはどうしますか？+

できることではなく、任せる業務の条件から選ぶ

AIエージェントで何ができるかを調べても、自社で使えるかどうかは決まりません。決めるのは業務の条件です。繰り返し発生するか、完了条件が明確か、判断基準を文章化できるか、失敗しても戻せるか、そして責任者が決まっているか。この5点を満たす業務から始めれば、20業務のどれであっても検証は進みます。

次に取るべき行動は1つです。この記事の採点表で20業務を採点し、合計点の高い3件について、現在の工数と件数を測ってください。 測定した数字があれば、社内の合意も本番導入の判断も進みます。