AIで業務を速くする前に——自動化に向く状態をどう見極めるか

白地に細い線で描かれた、地面のライン上に置かれた歯車と、その下に広がる波紋のモノクロイラスト

AI導入 · 2026-08-03 · 8分

「AIを入れたのに、想定したほど現場が楽にならなかった」。その原因はAI側にも業務側にもあり得ます。切り分けたうえで、業務の側をどう見極めるかを考えます。

「AIを入れたら、確認や修正がむしろ増え、想定したほど現場が楽にならなかった」という相談を受けることがあります。

原因は一つではありません。

モデルやシステムの精度・安定性が業務要件に届いていない場合もあれば、AIを入れる前から、手順、判断基準、例外処理、参照情報が曖昧だったことが影響している場合もあります。

重要なのは、どちらか一方に原因を決めつけず、AI側と業務側の問題を切り分けることです。

本稿では後者に焦点を当て、「その業務は自動化に向く状態になっているか」を考えます。

私たちは、業務の目的と要求水準を整理したうえで、候補となるモデルやシステムを実際の事例で試し、その結果を見ながら任せる範囲を調整しています。

業務整理を終えてから技術を選ぶのでも、技術を先に決めて業務を合わせるのでもなく、両者を往復しながら詰めていくためです。

自動化は、業務の曖昧さも拡大し得る

私たちが重視している考え方の一つに、「悪い業務を自動化すると、悪い業務が速くなるだけ」というものがあります。

ここでいう「悪い業務」とは、現場や担当者を否定する言葉ではありません。

目的、手順、判断基準、例外処理、責任の所在など、自動化に必要な前提が十分に整理されていない状態を指します。

自動化は、業務の良い部分だけを選んで速くしてくれるわけではありません。

渡された情報や定められた手順に矛盾や曖昧さが残っていれば、その部分も処理件数とともに広がる可能性があります。

例えば、見積の作成で、担当者ごとに確認する項目や例外時の扱いが少しずつ異なっているとします。

AIによって下書きの作成時間が短くなっても、何を正しい見積とするかが揃っていなければ、人による確認や差し戻しが増えることがあります。

この場合、モデルの性能だけを上げても、判断基準の不一致は解消しません。

一方で、AIの導入によって、それまで見えにくかった違いが表面化することもあります。

どこで差し戻しが起きたか、どの条件で担当者の判断が分かれたかを記録できれば、業務を見直す材料になります。

ただし、確認や監視の仕組みがなければ、誤った処理が増えるまで問題に気づきにくくなる可能性もあります。

表面化するかどうかは自動化の副産物ではなく、記録と監視をどう設計したかによって決まる、というのが私たちの理解です。

自動化前には見えにくい三つの問題

長く続いてきた業務ほど、現在のやり方が前提として受け入れられ、問題が見えにくくなります。

自動化の前に確認したいのは、主に次の三点です。

一つ目は、その業務を続ける目的が今も残っているかです。

過去のトラブルや一時的な制度変更への対応として追加された工程が、理由を確認されないまま残っていることがあります。

自動化を検討する前に、その工程自体を廃止できないか、別の工程とまとめられないかを確認する余地があります。

二つ目は、判断基準と例外処理が共有されているかです。

例えば、同じ種類の案件でも、担当者によって承認が必要かどうかの判断が分かれ、例外の扱いが共有されていないことがあります。

担当者ごとに結果が違う場合、それが顧客や案件に応じた意図的な違いなのか、単なるばらつきなのかを区別する必要があります。

すべてを一つのルールへ統一する必要はありませんが、少なくとも、何が標準で何が例外なのかは説明できる状態が望まれます。

三つ目は、参照情報と更新責任が決まっているかです。

正式な手順書とは別に、日常的な例外対応がチャットや口頭で共有されており、どの情報を正とするかが決まっていない、という状態は珍しくありません。

料金、商品情報、社内手順、対応方針などが複数の場所に分散していると、AIシステムだけでなく、人の判断も不安定になります。

どの情報を正とし、変更があったときに誰が更新するかまで決めておく必要があります。

頻度が高いだけで、自動化の対象を選ばない

毎日何度も発生する業務は、負担が見えやすく、自動化による効果も出やすい候補です。

ただし、頻度が高いことと、自動化に向いていることは同じではありません。

私たちは以前、最初の対象を選ぶ物差しとして「発生する頻度」と「間違えたときの影響の大きさ」の2軸を挙げました。

本稿の観点を加えるなら、そこに次の二つを足して四つで見ることになります。

  • どれくらいの頻度と処理量があるか
  • 間違えた場合の影響はどの程度か
  • 結果の良し悪しを判定できるか
  • 判断基準や参照情報がどの程度安定しているか

頻度が高く、結果を判定しやすく、失敗時の影響を限定できる業務は、初期の自動化に向いています。

反対に、頻度が高くても、判断基準が揃っておらず、誤りを発見しにくい業務は、まずAIによる支援や限定的な試行から始める方が安全です。

自動化の前に確認したい七つの問い

自動化を検討する際には、次の問いを叩き台として使えます。

これは正しい設計を示すものではなく、あくまで一例です。

項目の粒度や優先順位は、業務の性質や規模、規制の有無に応じて各社が定めるものです。

  1. この業務が生み出す成果は何か。それは今も必要か — 過去の事情で残っているだけの工程や、重複作業になっていないかを確認する
  2. 入力、出力、参照すべき情報を説明できるか — どの情報を受け取り、何を作り、どの資料を正とするかを整理する
  3. 判断基準と、許容できるばらつきが共有されているか — 担当者による違いが、意図されたものか、未整理のばらつきかを区別する
  4. 例外が起きたとき、どの時点で人へ渡すか — 承認、差し戻し、追加確認が必要になる条件を具体化する
  5. 間違いをどう検知し、止め、元の運用へ戻すか — 処理速度だけでなく、監視と復旧の方法も決める
  6. 手順や参照情報を誰が更新するか — 更新担当と見直しの時期が決まっていない情報は、運用後に古くなりやすい
  7. 候補となるAIシステムは、実際の業務例で必要な水準を満たせるか — 公開ベンチマークだけでなく、自社の入力、専門用語、参照情報、出力形式を使って確認する

七つ目については、「精度」という言葉のまま置いておかず、業務ごとの合格条件に分けておくと判断しやすくなります。

  • 必須の情報を漏らさないか
  • 事実と異なる内容を加えないか
  • 指定した形式を守れるか
  • 人への引き継ぎ条件を守れるか
  • 同種の入力に対して品質が大きくぶれないか

処理時間、コスト、セキュリティ要件も、この段階で併せて確認します。

すべてに完璧な答えを用意する必要はありません。

ただし、入力と出力、判断基準、失敗時の検知方法がほとんど説明できない状態であれば、いきなり全面自動化するより、対象範囲を狭めるか、人の判断を残した形から始める方が現実的です。

自動化は二択ではない

AIを使うか使わないか、全面自動化するか人が行うか、という二択で考える必要はありません。

業務の状態に応じて、次の四つの選択肢を使い分けられます。

  • やめる — 目的を失った工程や重複作業を廃止する
  • 整える — 判断基準、参照情報、例外処理を整理する
  • 支援させる — AIが下書きや分類を行い、人が判断する
  • 自動実行させる — 条件が安定した範囲だけAIが完結し、例外は人へ渡す

一つの業務全体を同じ方式にする必要もありません。

情報収集は自動化し、判断は人に残す。

定型案件だけ自動処理し、例外案件は担当者へ渡す。

このように工程ごとに分けた方が、現実の業務に合わせやすくなります。

候補となるモデルの性能も、この選択に影響します。

必要な水準に届かなければ支援にとどめ、実例で安定した結果を確認できた範囲から自動実行へ広げる、という進め方ができます。

先ほどの「整える」は、自動化の前段としてだけでなく、それ自体が独立した選択肢でもあります。

判断基準を揃えたことで、そもそも自動化しなくても十分に速くなる業務は実際にあります。

完璧になるまで待つ必要はない

ここまでの内容は、業務を完全に整えてからでなければAIを使ってはいけない、という意味ではありません。

最初から業務全体を作り直そうとすると、検討だけが長引き、実際のデータを得られなくなります。

大掛かりな業務改革から始める必要があるとは限りません。

まずは代表的な一件について、入力、手順、判断、例外、出力を書き出すだけでも、曖昧な部分は見つけやすくなります。

ただし、複数の部署や既存システムをまたぐ業務では、承認の構造や権限関係まで含めた、より広い見直しが必要になる場合もあります。

着手する範囲としては、影響範囲の小さい一工程を選び、過去の実例を使って試すところからで十分です。

その際、「必須の情報が揃っているか」「事実と異なる内容がないか」「どの条件なら人へ渡すか」といった合格基準を先に決めておきます。

運用後は、AIの出力をそのまま評価するだけでなく、人による修正率、差し戻しの理由、例外として引き継いだ件数、処理時間なども確認します。

結果を見ながら、モデルやシステムを調整するのか、参照情報を直すのか、業務の手順自体を変えるのかを切り分けます。

業務設計と技術検証は、前後に分かれた別々の工程ではありません。

小さく試し、結果を見て双方を直す循環として進めるものだと私たちは考えています。

まとめ

AI導入がうまくいかない原因は、モデルの精度だけでも、業務設計だけでも説明できません。

性能が業務要件に届いていないAIを、業務整理だけで補うことはできません。

一方で、判断基準や参照情報が曖昧な業務を、モデルの性能だけで安定させることも困難です。

自動化に着手する前には、業務の目的、入力と出力、判断基準、例外処理、更新責任、失敗時の検知方法を確認する。

そのうえで、候補となるAIシステムを実際の業務例で試し、支援にとどめるのか、条件付きで自動化するのかを決める。

自動化の選択肢は、やめる・整える・支援させる・自動実行させるの四つです。

どれを選ぶかは業務の状態によって変わり、一つの業務の中でも工程ごとに違ってかまいません。

この短い点検を挟むことで、導入後の手戻りを減らし、任せられる範囲をより安全に広げやすくなると考えています。

記事一覧へ戻る