
この記事のポイント
- AIでの自動化は、手順が決まっていて入力が文章で届く業務から始める。
- AIに任せる部分と従来の仕組みで処理する部分を分けて設計する。
- 一件の処理に識別番号と状態を持たせ、途中失敗と再実行で二重登録しない流れを確かめる。
請求書の内容を確認してシステムに入力する、問い合わせメールを読んで担当部署に振り分ける。こうした定型業務を、AIで自動化したいと考える方もいるでしょう。AIは、文章から要点を取り出す作業や、決まった形に整える作業に向いています。
一方で、AIの出力は毎回同じになるとは限らず、誤りが含まれることもあります。自動化の範囲や確認の仕組みを決めずに始めると、間違った処理に気づくのが遅れかねません。この記事では、定型業務をAIで自動化するときの考え方と進め方を、向く業務と向かない業務の見分け方から説明します。
AIによる 自動化とこれまでの 自動化の 違い
これまでの業務の自動化は、決められたルールどおりに処理する仕組みが中心でした。たとえば「この列の数値をあの表に転記する」といった、手順が完全に決まった作業です。こうした仕組みは、同じ入力に対して必ず同じ結果を返します。

AIを使った自動化では、形がそろっていない文章や書類も扱えます。メールの本文から依頼の内容を取り出す、取引先ごとに書式の違う請求書から金額を抜き出す、といった処理がその例です。その代わり、AIの出力には誤りや揺れが含まれることがあります。
そのため、AIを使う部分と従来のルールで処理する部分を分けて設計することが大切です。たとえば、請求書から金額を取り出すのはAIが担当し、合計の計算や入力先のシステムへの登録はルールで処理します。AIの役割を必要な部分に絞ると、誤りが起きる箇所を特定しやすくなります。
自動化に 向く 業務・ 向かない 業務
AIでの自動化に向くかどうかを判断する目安を、表にまとめました。
| 観点 | 向く業務 | 向かない業務 |
|---|---|---|
| 手順 | 手順が決まっていて、例外が少ない | 毎回判断の基準が変わる |
| 入力 | メールや書類など文章で届く | 情報が口頭や紙のメモに散らばっている |
| 誤りの影響 | 人が確認すれば修正できる | 誤りが金銭や安全に直結する |
| 件数 | 同じ作業が繰り返し発生する | 発生する頻度が低い |
| 結果の確認 | 正しいかどうかを人が判断しやすい | 正解を判断できる人がいない |
たとえば問い合わせメールの分類や、会議の記録からの議事録の下書き作成は、向く業務の例です。反対に、値引きの可否を決める判断のように状況によって基準が変わる業務は、AIに任せきりにするのは避けたほうがよいでしょう。そうした業務でも、判断に必要な情報を集めて整理する部分だけをAIに任せる方法はあります。
業務を 手順に 分解する
自動化を検討するときは、業務を細かい手順に分けて書き出すところから始めるのが基本です。たとえば請求書の処理なら、受け取り・読み取り・金額の確認・入力・報告といった手順に分けられます。
書き出した手順ごとに、AIに任せるか従来の仕組みで処理するか、人が行うかを決めます。すべてをAIに任せる必要はありません。手順を分けておけば、一部だけを先に自動化し、効果を確かめてから範囲を広げることもできます。業務の洗い出しの方法はAIで効率化できる業務の洗い出し方で詳しく説明しています。
この段階で、例外がどのくらいの頻度で起きるかも確認しておきましょう。書式の違う書類や記載が漏れている書類がどの程度あるかによって、自動化の設計は変わります。
例外と 確認の 仕組みを 決める
AIによる自動化で最も気をつけたいのが、例外の扱いです。AIが必要な項目を見つけられなかった場合や、結果がルールに合わない場合にどう処理するかを、先に決めておきます。たとえば、取り出した金額と合計が合わない場合は自動で処理を進めず、担当者へ回すといったルールです。

人の確認をどこに入れるかも大切な設計の一つです。社外へのメール送信やデータの更新のように、取り消しにくい処理の前には人の承認を入れましょう。承認の入れ方はAIの操作に人の承認を入れる設計で説明しています。
処理の記録を残すことも欠かせません。AIが何を入力として受け取り、どう処理したかが記録に残っていれば、誤りが見つかったときに原因を調べられます。
AIに渡す権限も、自動化する手順に必要な範囲に限っておくのが安全です。たとえば請求書の金額を取り出す手順なら、AIに必要なのは書類を読む権限だけでしょう。システムへの登録はルールで処理する仕組みに任せれば、AIが誤ってデータを書き換えることを防げます。
小さく 始めて 効果を 確かめる
自動化は、一つの業務の一部から始めるのが確実です。最初の期間は、AIの処理結果をすべて人が確認し、どのくらい正しく処理できているかを記録します。人が手作業で行った結果とAIの結果を並べて比べると、誤りの傾向が分かりやすくなります。
確認の結果、誤りが少なく安定していれば、確認の範囲を減らしたり対象の業務を広げたりしましょう。誤りが多い場合は、AIへの指示の書き方や、受け取る書類の形をそろえる工夫を検討します。業務の手順そのものを見直したほうが早い場合もあるでしょう。
効果を測るときは、作業時間だけでなく、確認や誤りの修正にかかる時間も含めて考えることが必要です。AIの利用料や仕組みの保守にかかる費用も合わせて比べると、自動化を続けるかどうかを判断しやすくなります。
問い合わせ メールを 振り分ける 具体例
架空の会社で、共通窓口に届くメールを「商品相談」「請求に関する確認」「保守依頼」に分類するとします。AIには本文から用件と候補部署を取り出させ、振り分け先の決定や担当者への通知は決めた手順で実行します。最初は外部への自動返信を含めない範囲で試します。
入力が「先月の請求書を再送してください。あわせて機器の不具合も相談したいです」なら、用件は二つです。どちらか一方に押し込まず、「複数用件」として窓口担当者へ戻すルールを用意します。一つの部署で完結するという前提を、すべてのメールに当てはめないためです。
| 工程 | 処理する担当 | 結果の例 |
|---|---|---|
| 受付 | システム | 受付番号を付け、未処理として保存 |
| 内容の整理 | AI | 用件、対象商品、不足情報を抽出 |
| 入力の検査 | システム | 必須項目と分類候補を確認 |
| 例外の判断 | 窓口担当者 | 複数用件や判断困難なメールを確認 |
| 振り分け | システム | 指定部署へ通知して処理状態を更新 |
AIの出力が決めた候補以外の部署名だった場合は、そのまま通知しません。分類の値を検査し、担当者が確認する状態に戻します。文章として自然でも、後の処理で使える値になっているとは限らないからです。
二重 処理と 途中 失敗を 先に 試す
自動化では、一回目が失敗したように見えても、途中まで実行されている場合があります。通知した直後に通信が切れた際、最初からやり直して同じ担当者へ何度も通知する、といった問題です。
そのため、受付番号ごとに「未処理」「確認待ち」「通知済み」などの状態を持たせる設計を検討します。再実行時は状態を確認し、完了済みの操作を重複して実行しないようにします。識別番号の付け方や記録の場所は、連携先の仕様に合わせて開発担当者が決めます。
試験では、同じメールを再度受け取った場合、分類後に通知が失敗した場合、担当者が手動で処理した後に自動処理が再開した場合を確認します。正常なメールが分類できるだけでなく、やり直しても同じ業務結果になるかを見ます。
最初は 現在の 処理と 並べて 比較する
初期の試験では、AIの分類結果を実際の担当者の判断と並べて記録します。すぐに自動振り分けを有効にする必要はありません。「請求関連に分類したが、実際は商品相談だった」など、どの組み合わせを取り違えるかを見ます。
分類の一致だけでなく、人が確認する件数と時間も記録します。例外扱いが多いなら、入力の種類を絞るか、分類を細かくしすぎていないかを見直します。すべてのメールを複雑に分類するより、まず明確な用件だけを処理する方法もあります。
処理を任せる範囲を広げる際は、対象のメールを追加するたびに同じ確認を行います。過去にうまくいった分類が、新しい条件を加えたことで変わっていないかも確認してください。
人へ 戻す 仕組みを 日常 業務に 合わせる
例外を一覧に出すだけでは、担当者が気づかず残ることがあります。誰が、いつ、どの画面で確認するかまで決めます。対応期限がある業務なら、確認待ちの件数と経過時間を見られるようにします。
担当者が処理を修正した理由は、次の改善材料になります。ただし、修正をそのまま無条件でAIの指示へ反映するのではなく、繰り返し起きる傾向を確認してからルールを見直します。例外の内容がばらばらなら、そこは人が扱う範囲として残す判断もできます。
まとめ
定型業務をAIで自動化するときは、AIが向いている部分と従来の仕組みで処理する部分を分けて設計するのが基本です。手順が決まっていて、文章で入力が届き、人が結果を確認しやすい業務は自動化に向いているといえます。業務を手順に分解し、例外の扱いと人の確認を最初に決めておくことが大切です。小さく始めて記録を見ながら、確認の範囲や対象の業務を調整していきましょう。
e-Grantsでは、AIを使える社内インフラの構築の中で、社内データとの連携や承認の仕組みづくりを支援しています。自動化したい業務の整理から相談したい場合は、AIを使える社内インフラの構築をご覧ください。


