活用事例を自社に当てるための2つの見方

活用事例をいくつ集めても、そのままでは自社の計画になりません。同じ請求書処理でも、届く経路や承認の権限が違えば任せられる範囲が変わります。事例を読むときは、どの業務にも当てられる見方を1つ持っておくと、他社の例を自社の条件へ読み替えられます。

見方は、業務を工程に分けたうえで、工程ごとに次の2つを確かめる形です。

  • 出力が社外に出るか。 出るなら、下書きまでを任せて、送信するかどうかは人が決めます
  • 正しさを別のデータと突き合わせて確かめられるか。 確かめられるなら、条件を満たしたものは自動で通せます

この2つで分かれた結果が、以下の一覧の「任せる工程」と「人が残す判断」にあたります。判断そのものは部門ではなく業務の性質(定型か、判断を含むか、件数が多いか)で決まります。経理でも人が判断する業務はありますし、法務でも機械で確かめられる工程はあります。

工程ごとに任せる範囲を決める2つの分かれ道 業務を工程に分け、出力が社外に出る工程は下書きまでを任せて人が送信を決める。社外に出ない工程は、正しさを別のデータで確かめられるなら条件を満たしたものを自動で通し、確かめられないならAIが候補を出して人が選ぶ。 機械が処理する 人が判断する 分かれ道 1つの業務を工程に分ける その工程の出力は 社外に出るか 下書きまでを任せる 文面と宛先は人が確定 正しさを別のデータと 突き合わせて確かめられるか 条件を満たすものは通す 合わなかったものだけ人へ 候補を出し、人が選ぶ 選んだ結果を記録に残す 出る 出ない できる できない
工程を「社外に出るか」と「別のデータで確かめられるか」の2点で分けると、自動で通せる範囲と人が確定させる範囲が同じ基準で決まります。

以下では特定の企業名ではなく、業務ごとに任せられる範囲の型として10件を整理し、そのあとで部門別の見取り図を置きます。着手の順序や見積の考え方はAIエージェント開発の進め方にまとめています。

任せる工程と人が残す工程

多くの業務は、次の6工程に分解できます。前半の機械的な処理は任せやすく、後半の確定に近い工程は人が残す形が実務では続きます。

業務の6工程と、任せる範囲の切り分け 受け取る、読み取る、照合する、判定する、確認する、反映するの6工程を並べ、前の4工程を機械が処理する範囲、後の2工程を人が判断する範囲として色分けした図 受け取る メール・共有 読み取る 項目の抽出 照合する 台帳・履歴と 判定する 規程に沿うか 確認する 例外を見る 反映する 人が押す AIエージェントに任せる範囲 人が判断する範囲 件数が多く判定の基準が文書になっている業務は、左の4工程を任せやすい 金額の確定と社外への通知は、件数が増えても人が押す形が残る
6工程のうち、左の4工程が任せやすく、確定に近い2工程は人が残す。

AIエージェントの活用事例10選

業務別に、任せている工程と人が残している判断を並べます。件数の多さと判定基準の明文化の度合いで、着手しやすさが変わります。

業務 任せる工程 人が残す判断 着手しやすさ
請求書の受領から会計システムへの反映 受け取り、項目の抽出、発注データとの照合 支払の確定、差異が出た明細の扱い 高い(件数が多く、書式は違っても項目が同じ)
経費精算のチェック 領収書の読み取り、規程との突き合わせ、違反候補の抽出 例外の承認、規程の解釈が分かれる申請 高い(規程が判定の根拠になる)
契約書の一次レビュー 条項の抽出、自社の基準との差分の指摘 交渉方針、リスクを取るかの判断 中(基準の文書化が前提)
受発注メールの処理 発注内容の抽出、管理表と納期スケジュールへの反映 在庫と納期の最終回答、例外的な依頼 中(取引先ごとの書式差が出る)
見積書の取り込みと価格の比較 明細のデータ化、過去価格との比較 発注先の決定、価格交渉 中(紙とPDFが混在しやすい)
議事録からのタスク起票 決定事項と持ち帰りの切り分け、課題管理ツールへの起票 担当者と期限の確定、優先順位 高い(入力が録音と文字起こしにそろう)
社内問い合わせへの回答 社内文書の検索、回答の下書き 制度の解釈、前例のない相談 中(文書の整備状況で結果が変わる)
商談メモのCRMへの入力 項目の切り出し、CRMの該当欄への転記 案件の見込み度、次のアクション 高い(入力の型が決まっている)
提案書の下書き 定型の章の作成、過去案件からの引用 提案の方針、価格と体制の記載 中(章ごとに任せる範囲が違う)
書類選考 募集要件との突き合わせ、確認事項の抽出 合否、評価が分かれる経歴の判断 中(判定基準の合意が必要)

以下、それぞれについて任せる範囲と詰まる箇所を見ていきます。

請求書の受領から会計システムへの反映

任せる工程 受け取り、項目の抽出、発注データとの照合
人が残す判断 支払の確定、差異が出た明細の扱い

発行元ごとに書式が違っても、抽出する項目は取引先名、金額、税区分、支払期日とほぼ共通します。そのため書式差はデータ化の段階で吸収でき、発注データとの照合まで任せられます。詰まるのは、月次の締めに間に合わせる部分です。処理が遅れて締めに乗らないと、担当者は元の手入力へ戻ります。設計の順序は発行元ごとに書式が違う請求書をAIで取り込むにまとめています。

経費精算のチェック

任せる工程 領収書の読み取り、規程との突き合わせ、違反候補の抽出
人が残す判断 例外の承認、規程の解釈が分かれる申請

判定の根拠が社内規程という文書になっているため、任せられる範囲が明確な業務です。上限額の超過、宛名の不備、重複申請のような機械的な判定は精度が出ます。詰まるのは、規程に書かれていない慣習で運用されてきた部分です。この部分は自動化の前に文書化が必要になります。詳細は経費精算のチェックをAIで自動化するを参照してください。

契約書の一次レビュー

任せる工程 条項の抽出、自社の基準との差分の指摘
人が残す判断 交渉方針、リスクを取るかの判断

自社の契約基準が文書になっていれば、条項ごとの差分の指摘まで任せられます。法務が読む前に論点が一覧になるため、確認の順序が決まります。詰まるのは、基準が担当者の頭の中にある場合です。指摘の粒度が定まらず、出力を毎回読み直すことになります。進め方は契約書レビューをAIでで扱っています。

受発注メールの処理

任せる工程 発注内容の抽出、管理表と納期スケジュールへの反映
人が残す判断 在庫と納期の最終回答、例外的な依頼

メール本文と添付の書式が取引先ごとに違うため、抽出の設計に手間がかかります。反面、件数が多く、転記のミスが納期の遅れに直結する業務なので、効果は出やすいです。詰まるのは、電話や口頭での変更依頼が混ざる場合です。記録に残らない依頼があると、管理表と実態がずれます。設計は受発注業務をAIで自動化するにまとめています。

見積書の取り込みと価格の比較

任せる工程 明細のデータ化、過去価格との比較
人が残す判断 発注先の決定、価格交渉

明細の粒度が業者ごとに違うため、比較できる形にそろえる部分が中心の作業になります。同じ品目が別の名称で書かれることが多く、名称の対応表を作る工程が必要です。詰まるのは、紙とPDFが混在する場合の読み取り精度です。詳しくは見積書の取り込みをAIで自動化するを参照してください。

議事録からのタスク起票

任せる工程 決定事項と持ち帰りの切り分け、課題管理ツールへの起票
人が残す判断 担当者と期限の確定、優先順位

入力が録音と文字起こしにそろうため、着手しやすい業務です。決定事項と検討中の話題を切り分ける精度が実用に足りるかは、会議の進め方に依存します。詰まるのは、担当者が明示されないまま終わる議題です。この場合は起票までを任せ、担当と期限は会議の場で埋める運用にします。手順は議事録をAIでタスク化するにまとめています。

社内問い合わせへの回答

任せる工程 社内文書の検索、回答の下書き
人が残す判断 制度の解釈、前例のない相談

問い合わせの多くは既存の社内文書に答えがあるため、検索と下書きの作成で対応できます。結果を左右するのは文書の整備状況です。古い規程と新しい規程が両方残っていると、どちらを根拠にしたか分からない回答が出ます。着手前に、参照する文書の範囲と更新の担当を決めます。設計は社内問い合わせ対応をAIで自動化するで扱っています。

商談メモのCRMへの入力

任せる工程 項目の切り出し、CRMの該当欄への転記
人が残す判断 案件の見込み度、次のアクション

入力する欄が決まっているため、転記の精度は出やすい業務です。営業担当の作業が入力から確認へ変わることで、記録の粒度がそろいます。詰まるのは、CRMの必須項目が多く、メモに書かれていない情報を埋められない場合です。項目の見直しと同時に進めます。対応できるCRMの条件は商談メモの入力をAIで自動化するにまとめています。

提案書の下書き

任せる工程 定型の章の作成、過去案件からの引用
人が残す判断 提案の方針、価格と体制の記載

会社紹介や進め方のような定型の章は下書きが埋まりますが、提案の方針と価格は人が書く部分です。章ごとに任せる範囲が違うため、テンプレートの側で線を引いておくと迷いが減ります。詰まるのは、過去案件の資料が個人のフォルダに散っている場合です。引用元を集める作業が先に必要になります。線引きは提案書作成をAIで自動化するを参照してください。

書類選考

任せる工程 募集要件との突き合わせ、確認事項の抽出
人が残す判断 合否、評価が分かれる経歴の判断

要件との突き合わせと、面接で聞くべき点の抽出までを任せる形が実務で取られます。合否そのものを任せない設計にするのは、説明責任が採用側に残るためです。詰まるのは、募集要件が「コミュニケーション能力」のような曖昧な言葉で書かれている場合です。要件の書き直しから始まります。線引きは書類選考をAIで自動化するにまとめています。

部門別の見取り図

同じ業務でも所属によって呼び方が変わるため、部門から探せる形でも並べます。部門名で分けているのは探しやすくするためで、任せられる範囲は上の2つの見方で決まります。

部門 主な対象業務 任せる工程 人が確定させること
経理・財務 請求書の取り込み、インボイスの確認、仕訳と支払データの作成、電子帳簿保存法への対応、経費精算、見積書の取り込み 抽出と検算、規程やマスタとの照合 検算が合わないもの、税区分、支払の承認
法務・契約 契約書の一次レビュー、契約台帳と更新期限の管理、社内の利用ルールの整備 自社基準との差分の抽出、期限の計算 修正案の採否、交渉方針、締結の可否
人事・労務 候補者ソーシング、書類選考、労務の社内問い合わせ、社内でのAI活用の育成 探す、そろえる、比べられる形にする 合否、声をかける相手、評価と登用
情報システム 社内ヘルプデスク、社内文書の検索、業務システムの内製、外部AIサービスの審査 一次回答、履歴の分類、仕様の下書き 権限とアカウント、通す・止めるの判断
営業・カスタマーサポート 商談メモのCRM入力、提案書の作成、一次返信と日程調整、受発注メールの処理、議事録のタスク化、広告レポート 項目の抽出と転記、下書きの作成 送信の可否、確度と金額、変化の理由

経理・財務は照合の相手が社内にある

届く書類の様式が発行元ごとに違い、確認する内容は毎回ほぼ同じ、という業務が集まっています。明細の合計と請求合計が一致するか、税率ごとの対象額から計算した税額が記載と合うか、同じ請求書番号が過去に登録されていないか。こうした照合は機械で行えるため、任せる範囲を広げやすい部門です。人の確認は、照合で合わなかったものと、金額が一定額を超えるものに絞れます。

一方で、自社の会計処理の方針に依存する判断は残します。税区分の割り当て、適格請求書として扱えるかの判定、規程の解釈が分かれる経費。ここは候補を示して人が選ぶ形にします。読み取りの方式はAI-OCRと生成AIの違いで比べています。

法務・契約は差分の抽出と期限の計算に絞る

件数は経理より少なく、1件あたりの影響は大きい業務です。一次レビューは読む時間ではなく見落としを減らす工程として置きます。自社の契約基準を条項単位で書き出しておけば、そこからの差分は機械的に出せます。

締結後の管理は、抽出よりも期限の計算が効きます。自動更新条項の見落としは、契約書を読めていないから起きるのではなく、期限が誰の手元にも表示されていないから起きます。台帳に日付を保存するのではなく、契約期間と通知期間から毎日計算して通知する構成にします。

人事・労務は落とす判断を人に残す

ソーシングと書類選考は同じ「候補を絞る」業務ですが、任せる範囲の理由が違います。ソーシングは母集団を広げる工程で、機械が漏れなく集めた分だけ人の選択肢が増えます。書類選考は絞る工程なので、機械が落としたものは人の目に入りません。前者は範囲を広げやすく、後者は落とす判断を人に残す、という分け方になります。

問い合わせ対応は、回答そのものより「どれを人へ回すか」の設計が要点です。規程に書いてある内容は一次回答で返せますが、個別の事情が絡む相談は担当者へ渡します。回した記録を残しておくと、規程に書き足すべき箇所が分かります。

情報システムは精度より先に権限を決める

社内文書検索で先に決めるのは、精度ではなく権限です。誰がどの文書を見られるかを検索の仕組み側で持たないと、回答に本来見えない内容が混ざります。参照させる文書の範囲を決め、出典を必ず表示させる形にしてから、精度の話に進みます。

外部AIサービスの審査は、技術の判断で止まるより、確認する項目が事業部側と共有されていないことで止まる場合が多くあります。情シスが確認する項目を先に公開し、事業部が埋める欄を用意しておくと、審査へ回ってから追加の質問で往復する回数が減ります。進め方は生成AIサービスのセキュリティ審査をどう通すかで扱っています。

営業・カスタマーサポートは送るものを下書きまでにする

社外への出力が多い部門です。送るものは下書きまでを任せ、送信するかどうかは人が決める形が基本になります。社内に残る記録の作成は、自動で通せる範囲が広くなります。

レポートは、数値を並べる部分と理由を書く部分を分けます。集計と比較、変化した指標の抽出までは機械で毎回同じ手順で行えます。なぜ変化したかは、実施した施策や外部の事情を知っている人が書く部分です。ここを機械に書かせると、もっともらしいだけの説明が残ります。

社外へ出る文面を扱う業務では、下書きの質を上げるより、送信前に何を見るかを決めておくほうが効きます。宛先、金額や納期の記載、前回のやり取りとの矛盾。この3点を確認する画面を用意しておくと、下書きを使い続けられます。

部門をまたいで共通して残る作業

どの部門の業務でも、自動化の設計から外れやすく、外すと運用に乗らない作業があります。

共通して残る作業 決めておくこと 決めていないと起きること
処理できなかったものの差し戻し 戻し先(社内か社外か)と回答期限、滞留の通知 止まったものが期限の直前に出てくる
人が直した内容の記録 直した箇所と理由の保存、判定条件への反映の手順 同じ直しが毎回発生し、確認の負担が減らない
参照する文書やマスタの更新 更新の担当と頻度、古い情報の扱い 出力の形は変わらないまま、内容だけ古くなる
権限と操作の記録 誰が承認できるか、何を残すか 監査や社内審査の段階で公開を止められる
効果の測り方 着手前の件数と処理時間の実測、比べる定義 導入したかどうかしか報告できない

このうち効果の測り方は、着手前に測っておかないと後から作れません。何をどう測るかはAI導入の効果測定と効果検証で扱っています。

事例に共通する条件

10件を並べると、任せやすい業務の条件が3つに整理できます。

条件 満たしている業務 満たしていない場合に起きること
月あたりの件数が多い 請求書、経費精算、商談メモ、議事録 効果が測れるまでに時間がかかり、判断が付かないまま検証が終わる
判定の基準が文書になっている 経費精算(規程)、書類選考(募集要件)、契約書(自社基準) 基準の文書化が先に必要になり、想定した期間で終わらない
入力の形がそろっている 議事録(録音)、商談メモ、社内問い合わせ 読み取りの設計に工数が集中し、判定まで届かない

3つすべてを満たす業務から始めると、1件目で結果が出ます。2つしか満たさない業務でも進められますが、足りない条件を埋める作業を計画に入れます。

成果が出ない形

事例を集めていると、うまくいかない形にも共通点が見えます。

  • 確認の工程が二重になっている … AIの出力を人が全件見直す運用のままだと、作業は減りません。全件確認を外す条件を最初に決めます
  • 例外の引き取り先が決まっていない … 処理できない入力が来たときの担当が未定だと、その場で止まって滞留します
  • 効果を測る記録が実施前にない … 導入前の処理時間と件数を記録していないと、変化を示せません
  • 対象業務が広すぎる … 「経理業務の効率化」の単位では、どの工程を任せたか説明できず、成否も判定できません

このうち全件確認については、外す判断の材料が必要です。同じ入力に対する出力が一定期間ぶれないことを記録で確かめてから、確認の範囲を狭めます。判断の基準はAI導入の効果測定と効果検証で扱っています。

着手の順番の決め方

一覧を見ると候補が複数挙がりますが、同時に始めても受け入れ側の人手が足りず、確認待ちが積み上がります。順番を決めます。

判断の材料は3つあります。年間の手作業時間(件数×1件あたりの時間)、正しさを機械で確かめられるか出力が社外に出るかです。手作業時間が大きく、機械で確かめる手段があり、出力が社内に留まる業務が最初の候補になります。上の一覧では、請求書や見積書の取り込み、経費精算のチェック、議事録のタスク化、CRMの入力がこの条件に近い位置にあります。

決めた後の進め方は、次の順序にします。

  • 対象業務を1つに絞る … 件数、判定基準の明文化、入力の形の3条件で候補を並べ、最も条件を満たすものを選ぶ
  • 6工程のどこまでを任せるか決める … 確定に近い工程は人に残す前提で線を引く
  • 実施前の状態を記録する … 1件あたりの処理時間と月間件数、現在の手順を書き出しておく
  • 例外の引き取り先を決める … 処理できない入力が来たときに誰へ回すかを、運用開始前に決める
  • 既製ツールで足りるかを確かめる … 判定に社内固有の基準が入るかで分かれます。判断の手順はAIエージェントは自作か既製ツールかにまとめています

最初の1件は、効果の大きさより判定のしやすさで選びます。結果が判定できれば、2件目以降の投資判断が社内で通ります。自社の業務を整理する段階なら業務の棚卸しをAIで進める、候補の絞り込みと最初は外したほうがよい業務の見分け方は生成AI内製化の最初の1業務の選び方にまとめています。

まとめ:活用事例の読み方と使い方

  • 事例は成果の数字ではなく、任せた工程と人が残した判断で読む
  • 工程ごとに「出力が社外に出るか」「正しさを別のデータで確かめられるか」の2点で任せる範囲が決まる
  • 業務は受け取り、読み取り、照合、判定、確認、反映の6工程に分解でき、前半4工程が任せやすい
  • 任せやすい業務の条件は、件数が多い、判定基準が文書になっている、入力の形がそろっているの3つ
  • 経理・財務は照合の相手が社内にあるため範囲を広げやすく、法務・契約は差分の抽出と期限の計算に絞る
  • 人事・労務は母集団を広げる工程は任せられるが、落とす判断は人に残す。情報システムは精度より先に権限を決める
  • 営業・カスタマーサポートは社外へ出る文面を下書きまでにし、社内に残る記録の作成から広げる
  • どの部門でも、差し戻しの経路、人が直した記録の反映、効果の測り方は設計に含める
  • 着手の順番は、年間の手作業時間、機械で確かめられるか、社外に出るかの3点で決める

Augueでは、この一覧に挙げた書類の取り込みから社内問い合わせ、営業側の記録作成まで、業務ごとにAIエージェントの開発と社内で運用できる形への引き継ぎに対応しています。自社のどの業務が最初の候補になるかを整理したい方は、是非ご相談ください。

関連する記事

まずは現状をお聞かせください

弊社では具体的な要件が固まっていない段階でも、無料相談で現状をお聞きしていますので、お困りの際はご相談ください。

無料相談を予約する →

よくある質問

事例のうち、最初に手を付けるならどれですか?

月あたりの件数が多く、判定の基準が文書になっている業務から選びます。この記事の10件では、請求書の取り込みと経費精算のチェックが該当しやすく、規程や過去の処理履歴が判定の根拠になります。逆に、担当者ごとに判断が分かれる業務は、基準を文書にする作業から始まるため、1件目には向きません。

複数の部門で同時に進められますか?

並行させる本数は、開発の速さではなく受け入れ側の人数で決まります。1つの業務を本番で回すには、判定条件を決める担当と、例外を見て直す担当が要ります。この2役を出せる部門の数が上限です。多くの場合、最初は1業務、動きが安定してから2〜3業務を重ねる形になります。工程だけ先に並行させても、確認へ回る件数が積み上がって止まります。

部門ごとに作ると、似たものを何度も作ることになりませんか?

書類を読み取る部分、社内文書を検索する部分、承認へ回す部分は部門をまたいで使い回せます。逆に、判定条件と例外の扱いは部門ごとに違うため共通化できません。2本目以降は、読み取りや検索を共通の部品として置き、その上に部門固有の判定を載せる構成にすると、作り直しの範囲が判定条件だけに収まります。

人が確認する工程は、いつまで残すべきですか?

誤りが出たときの影響が金額や社外への通知に及ぶ工程は、残したままにします。件数の多さで自動化の範囲を広げても、送信と支払、社外への回答の確定は人が押す形が実務では続きます。確認を外す判断は、同じ入力に対する出力が一定期間ぶれないことを記録で確かめてからにします。

既製のツールで足りる事例と、作る必要がある事例の違いは何ですか?

判定の基準が社内固有かどうかで分かれます。読み取りと転記が中心の業務は既製ツールが対応している範囲に収まりやすく、自社の規程や取引先ごとの例外を判定に含める業務は、その部分を作ることになります。見分ける手順は自作と既製ツールを比べた記事にまとめています。

効果はどれくらいの期間で出ますか?

一律の期間は出せません。件数と例外の多さで変わるためです。判断できる材料は、着手前に測った1件あたりの処理時間と月間件数、そして着手後に自動で通った割合と人の確認へ回った件数です。この2組を同じ定義で比べれば、期間の見込みは自社の数字から出せます。他社の期間をそのまま当てても計画の根拠になりません。

現場が使わなくなる場合、何が原因になりやすいですか?

例外の行き先が決まっていないことと、直した内容が次に反映されないことが多く挙がります。処理できなかったものの戻し先と期限が無いと、担当者は結局全件を自分で見ます。人が直した箇所を記録して判定条件へ戻す手順を運用に含めておくと、同じ直しが繰り返されなくなり、使い続ける理由が残ります。