AI導入の対象を考えるとき、最初に製品やツールを比べると、解決したい業務上の問題が曖昧なまま話が進みがちです。まずは日々の仕事を観察し、繰り返し発生する負担と、間違いが起きたときの影響を整理しましょう。候補を選ぶ基準は、AIに向いているかだけではありません。現状を測れるか、現場が試せるか、例外時に安全に戻れるかも含めて考えます。
AIを探す前に、業務の流れを一枚にする
業務の全体像をつかむには、「誰が、何を受け取り、何を判断し、何を作り、次に誰へ渡すか」を順に書き出します。担当者への聞き取りでは、通常の手順だけでなく、情報が足りないとき、内容が食い違うとき、急ぎの依頼が来たときの対応も確認してください。例外の処理が担当者の経験に依存しているなら、それ自体が改善を検討する大切な発見です。
たとえば、依頼メールの内容を一覧表へ転記する業務なら、メールの受信、必要項目の確認、表への入力、元メールとの照合、次の担当者への連絡までを分けて記録します。「転記」とひとまとめにせず、どこで待ち時間や修正が発生しているかを見つけられる粒度にするのがポイントです。
工程ごとに、使う媒体も記録しましょう。メールからExcelへ、紙の申請書から社内システムへと情報が移る箇所は、入力の重複や見落としが起きやすい部分です。処理件数、所要時間、確認や修正の回数も、可能な範囲で現状値として残します。担当者の記憶だけに頼らず、繁忙期と通常期の違いも確認すると、改善の優先順位を考えやすくなります。
最初の候補を見つける7つの確認軸
次の問いは、候補を一律の点数で順位付けするためのものではありません。業務の負担、実現しやすさ、失敗時の影響を並べ、何を先に確かめるべきかを話し合うための視点です。頻度が高くても、例外が多く影響が大きい仕事なら、人の確認を含む慎重な検証が必要です。
1. どのくらいの頻度で発生するか
毎日何度も行う業務か、月末だけの作業かで、改善の優先度は変わります。頻度だけで決めず、対象件数や繁忙期の偏りも記録しましょう。
2. 一件あたり、どれだけ時間がかかるか
入力時間だけでなく、内容の確認、差し戻し、転記後の照合まで含めて見ます。短い作業でも件数が多ければ負担が大きいことがあります。
3. 手順や判断はどれほど標準化されているか
担当者ごとに判断基準が違う業務は、先にルールや例外条件を言葉にする必要があります。手順がそろっている部分と、経験に頼る部分を分けてください。
4. 入力データは扱いやすい状態か
情報がメール本文、Excel、紙、画像などに分散していないか、表記ゆれや記入漏れがどの程度あるかを確かめます。入力の質が不安定なら、データの整え方も検討対象です。
5. 例外はどれくらいあり、誤りの影響は何か
例外が少ないかどうかだけでなく、間違った場合に金額、納期、安全、顧客対応へどのような影響があるかを考えます。影響が大きい業務では、人の確認や承認を省かない設計が重要です。
6. 現場の人が検証に参加できるか
実際に作業する人が、通常ケースと困るケースを示し、出力を評価できる体制があるか確認します。忙しい時期を避けるなど、検証に必要な時間も事前に相談しましょう。
7. 効果を比べるための現状値を取れるか
導入前の処理時間、確認・修正の時間、件数や誤りの傾向を記録できるかが判断の土台になります。測定条件があいまいだと、導入後の変化を正しく比較できません。
たとえば、定型的な入力が毎日発生し、元データも比較的そろっていて、作業時間や修正件数を記録できる業務は、限定的な検証の候補になりやすいでしょう。一方、件数が少なく判断の影響が大きい業務は、無人化を急ぐより、検索や下書き作成など人を補助する範囲から考える方法があります。
AI・RPA・OCR・既存機能を比べる
技術の名前から対象業務を探すのではなく、作業の中身を「決まったルールで処理できる部分」と「文脈や人の判断が必要な部分」に分けて考えます。単純な転記のために複雑な仕組みを追加する必要はないかもしれません。既存システムの標準機能や、入力ルールの見直しだけで解決する場合もあります。
既存システムの機能・ルール化
処理条件が明確で、入力形式をそろえられる場合にまず確認したい選択肢です。重複入力を減らせる標準機能や、手順の統一で対応できるかを見ます。
RPAなどの定型操作
決まった画面操作や繰り返し作業の自動化が候補になります。画面や手順が変わった際の保守、途中で止まった場合の検知と復旧も考えておきます。
OCRなどの文字読み取り
紙や画像から文字・項目を取り出す工程で検討します。帳票の種類、印字や手書きの状態、読み取りにくい入力を人が確認する方法が、実用性を左右します。
生成AIなどの文章処理
文章の要約、分類、下書きなど、形式が一定でない情報を扱う場面が候補です。出力が常に正しいとは限らないため、入力できる情報の範囲と人の確認方法を決めます。
一つの業務に複数の方法を組み合わせることもあります。たとえば、メールから必要情報を抽出しても、金額や取引条件の判断は担当者が行う設計です。どの方法でも、導入後の保守、例外処理、利用環境との適合性を含めて比較し、まずは小さな範囲で確かめます。
小さな検証範囲を決める
初回の検証では、対象部署、業務工程、期間、データの種類を絞ります。たとえば「すべての依頼を自動処理する」ではなく、「一つの部署で、決めた形式の依頼を対象に、必要項目の抽出を補助する」といった具合に、どこまでを試すのかを説明できる形にします。実際のデータを使う場合は、情報の取り扱いと利用環境を事前に確認してください。
開始前に、検証で答えたい問いと判断条件を決めておきましょう。どの程度の時間短縮を目指すのか、どの種類の誤りなら許容できないのか、どのような場合に人へ引き継ぐのかを関係者で共有します。想定外の入力や処理停止が起きたときに検証を中断できる条件も必要です。
検証前にそろえておきたいこと
- 対象とする業務・部署・データの範囲
- 導入前の処理条件と、比較する期間
- 成功とみなす条件、見直し・中止の条件
- 例外が起きた際の確認担当と手作業への戻し方
導入前後を比べる指標
作業時間だけを見ると、処理自体は速くなっても、確認や修正に別の時間がかかっていることを見落とします。入力、処理、確認、修正、例外対応をできる範囲で分けて記録し、同じ条件で導入前後を比べてください。通常ケースだけでなく、入力不足、表記ゆれ、重複、読み取りにくいデータなども含めて確認すると、運用上の課題が見えます。
- 作業負荷：処理時間に加え、確認・修正・手動復帰にかかった時間。
- 品質：出力の正確さ、修正の発生状況、見落としが後工程へ与えた影響。
- 例外：自動処理できなかった件数と、担当者が判断・対応するための負担。
- 使いやすさ：現場で手順を理解できるか、無理なく利用を続けられるか。
指標の数値だけでなく、対象件数や入力データの条件、検証期間も一緒に記録します。処理が速くなっても、誤りの影響が許容できないなら、そのまま範囲を広げるべきではありません。PoCの評価項目や結果のまとめ方は、AIのPoCで何を測るかを解説したガイドでも詳しく紹介しています。
現場で続く運用にする
自動化した後も、人が確認する箇所と担当者を明確にしておきます。出力が不完全な場合、想定外の形式が届いた場合、処理が止まった場合に、誰が気づき、どう判断し、どの手順で手作業へ戻すのかを決めておけば、現場が安心して試しやすくなります。確認結果や修正理由を残す仕組みも、次の改善に役立ちます。
検証後は、当初の基準と実際の結果を照らし合わせます。条件を満たし、例外対応や保守の方法も明確なら対象拡大を検討できます。結果が不十分なら、入力ルールや対象範囲を見直して再検証する、別の方法を選ぶ、あるいは見送る判断も選択肢です。検証を続けること自体を目的にせず、業務上の負担とリスクに照らして決めましょう。
候補業務を、検証できる計画へ
どの工程を変えるのか、必要なデータや例外は何か、何を測るのかを整理すると、AIを使うかどうかも含めて現実的に検討できます。
業務候補の整理方法を見る次に読む・相談する
この記事は一般的な検討手順を解説するもので、個別業務への適用可否は業務内容や利用環境によって異なります。