まず業務を小さな処理に分ける
「問い合わせ対応を自動化する」のように業務全体で考えると、どこに判断が必要なのかが見えにくくなります。まず、情報を受け取る、内容を判定する、記録へ転記する、担当者へ通知する、承認する、といった処理単位に分解します。
それぞれについて、担当者が経験や文脈をもとに考えているのか、決められた条件に従っているのかを確かめます。例外の種類、判断に使う情報、間違えた場合の影響も書き添えると、仕組みを選ぶ前に整えるべき手順が分かります。

ルール自動化とAIは、得意な処理が違う
条件が明確で、入力と結果を確かめやすい処理なら、既存ツールの機能やルールベースの自動化で十分なことがあります。たとえば、必須項目の確認、決まった条件での転記、期限が近づいたときの通知などです。AIを加えると仕組みの確認箇所が増える場合もあるため、まず現行ツールや手順変更で解決できないかを比べます。
一方、同じ内容でも表現が異なる文章の分類や、非定型文書から確認候補を拾う処理では、AIが候補を作る方法を検討できます。ただし、候補は正解とは限りません。担当者が元の文章や資料と照合できること、誤りや判断保留を人に戻せることが重要です。
| 方式 | 検討しやすい処理 | 先に確かめること |
|---|---|---|
| ルール・既存機能 | 条件が安定した計算、転記、必須項目確認、期限通知 | 条件と例外を明文化できるか。変更時に誰が直すか。 |
| AIの候補提示 | 表現の異なる文章の分類、要点整理、文書からの項目候補抽出 | 出力を元情報と照合できるか。誤りを発見し、修正できるか。 |
| 人の判断 | 影響が大きい決定、曖昧な例外、背景知識が必要な判断 | 判断に必要な情報と、相談・承認先が明確か。 |
これは一般的な切り分けの例です。実際の適性は、業務の条件、情報の扱い、誤りの影響、使っているツールによって変わります。
組み合わせるなら、境界と戻し先を決める
AIに判断を丸ごと任せるのではなく、AIは分類や要約の候補を提示し、ルールは必須項目や形式を確認し、担当者が必要な結果を承認する、と役割を分けられます。たとえば問い合わせの一次整理なら、AIが分類候補を出し、必須情報の有無をルールで確かめ、迷う内容や不足情報を担当者へ返す流れが考えられます。
「自信が低い」「必要な情報がない」「想定外の形式」といった場合に、処理を止めるのか、手動で続けるのか、誰に知らせるのかをあらかじめ決めます。誤った結果が後工程に進んだときの影響が大きい業務ほど、人が確認する地点、差し戻し方法、記録の残し方を丁寧に設計してください。
方式を決める前に確認したいこと
- 例外が起きたとき、通常の流れから安全に外せるか
- 担当者が出力を原資料と照合し、必要なら修正できるか
- 入力する情報と、利用するサービスの条件を確認できているか
- 手順やツールが変わったとき、修正・テストする人が決まっているか
導入のしやすさだけでなく、保守負担も比べる
選択肢を比べるときは、初期の作業だけでなく、条件変更への対応、出力の確認、エラー時の調査、担当者への引き継ぎも含めて考えます。設定を直せる人が限られる、確認に必要な元資料へアクセスできない、といった状態では、導入後の運用が難しくなります。
まずは一つの処理を対象に、現状の手順と例外を記録し、候補方式と人の確認点を並べてみてください。AIを使わない方法も含めて比較し、試行する場合には評価の観点と中止・手動切替の条件を決めます。業務候補の整理には AI業務適性診断、ルールとAIを含む流れの設計には 定型業務のスマート自動化 も参考にできます。
実務で使える確認ツール
候補業務を一つ選び、次の欄を処理ごとに埋めてみてください。空欄や「場合による」が多い箇所は、先に手順や判断基準を整理する合図です。
| 処理 | ルールで可能? | AIを検討? | 人の確認・例外時の対応 |
|---|---|---|---|
| 入力 | 条件・例外: | 候補を作る必要: | 確認者・差し戻し先: |
| 判定 | 条件・例外: | 候補を作る必要: | 確認者・差し戻し先: |
| 転記 | 条件・例外: | 候補を作る必要: | 確認者・差し戻し先: |
| 通知・承認 | 条件・例外: | 候補を作る必要: | 確認者・差し戻し先: |