AIを活用する業務フローを考えるとき、最初は「問い合わせを受けたら回答案を作る」「申請が届いたら内容を確認する」といった通常の流れに目が向きやすいものです。しかし、実際の業務では、すべての案件が同じ手順で進むわけではありません。金額が一定額を超える場合、重要な顧客に関する場合、緊急性が高い場合など、事前に定義した判定基準に応じて対応を変える場面があります。さらに、判断材料が不足している案件や、担当者による確認が望ましい案件もあります。このセクションでは、こうした場面を「AIの条件分岐」「AIの例外処理」「エスカレーション」という業務設計の視点から整理します。

AIの条件分岐とは何か

AI導入における条件分岐とは、業務に入ってきた情報や案件の性質に応じて、その後の処理経路を切り替えることです。難しいシステム設定から考える必要はありません。まずは、現在の業務で担当者が行っている「この場合はこちらへ回す」「この内容なら通常どおり進める」という判断を、見える形にすることから始めます。

前回までに、AIが動き出すきっかけである「トリガー」と、その後にAIが行う「アクション」を分けて整理しました。たとえば、「問い合わせフォームが送信された」がトリガーであり、「問い合わせ内容を分類し、回答案を作成する」がアクションです。

ただし、問い合わせ内容によっては、同じアクションをそのまま実行しない方がよい場合があります。一般的な質問であれば回答案の下書きまで進められる一方、契約変更やクレームなどは、事前に定めた手順に従って担当者へ引き継ぐ方が運用しやすいでしょう。この「条件に応じて進む道を変える」という部分が、AIの条件分岐です。

AIの役割は下書き・要約・分類を基本にする

初期のAI導入では、AIの役割を、回答文の下書き、案件の要約、内容分類、確認事項の抽出などに限定すると、社内で役割分担を説明しやすくなります。特に、顧客への対外送信、契約条件の確定、返金や補償の決定、重要案件の最終判断は、人が行う設計を基本として検討します。

たとえば、AIが回答案を作成する場合でも、そのまま顧客へ自動送信するとは限りません。「AIが下書きを作成し、担当者が内容と参照情報を確認したうえで送信する」という流れにすれば、AIの処理範囲と担当者の責任範囲を分けられます。

通常処理だけでは業務を表しきれない

業務マニュアルやフロー図を作るときは、代表的な流れを中心にまとめることが一般的です。問い合わせ対応であれば、次のような流れが考えられます。

1. 問い合わせを受け付ける
2. 問い合わせ内容を確認する
3. 回答案を作成する
4. 担当者が確認して回答する
5. 対応履歴を記録する

この流れは基本形として分かりやすい一方、実務では「回答前に責任者の確認が必要な内容」「担当部署が異なる内容」「判断に必要な情報が不足している内容」も含まれます。通常処理だけをもとにAI導入を考えると、こうした案件が入ってきたときに、AIや現場担当者が次の行動を判断しにくくなります。

そこで、通常の流れを作った後に、「途中で対応が変わる条件はないか」「そのまま進めない案件はないか」「判断できない場合はどうするか」を確認します。最初からすべての例外を洗い出す必要はありません。まずは、発生頻度が高いもの、影響が比較的大きいもの、現場が迷いやすいものから整理すると、検討を進めやすくなります。

条件分岐に使われる代表的な判定基準

条件分岐の基準は、業種や部門によって異なります。ただし、事業会社の業務では、金額、重要度、顧客区分、緊急度、内容分類、情報の充足度などが判定基準として使われることがあります。

実際の運用では、担当者の感覚だけに頼らず、事前に定義した判定基準に基づいて処理を分けることが大切です。次の表は、その整理例です。

たとえば、担当者が「これは重要案件だ」と感じていても、その理由が明文化されていなければ、AIワークフローの条件として扱いにくくなります。その場合は、「指定された顧客区分に該当する」「契約解除に関する内容を含む」「回答期限が当日中である」など、現場で確認できる表現へ置き換えます。

すべてを数値や固定語句だけで判定できるとは限りません。複数の意味に解釈できる案件や、基準への該当が明確でない案件は、保留または要確認として人へ引き継ぐ方法もあります。

個人情報を含む案件はAI処理の前に振り分ける

問い合わせ対応では、氏名、住所、電話番号、メールアドレス、顧客番号、契約情報などの個人情報が含まれることがあります。健康状態、障害、病歴など、要配慮個人情報に該当し得る内容や、社内で特に慎重な取扱いを定めている情報が含まれる場合もあります。

このような情報を扱う場合は、AIが分類や要約を行った後で例外として処理するのではなく、AIへ渡す前の段階で振り分けることが大切です。利用するAIサービスの契約条件、データ利用条件、保存の有無、学習利用の有無、処理場所、アクセス権限などを確認し、社内のプライバシーポリシーや情報管理ルールと整合する方法を選びます。

選択肢1：マスキングしてからAIへ渡す

マスキングとは、AIによる処理に必要のない氏名、住所、電話番号、顧客番号などを削除したり、別の記号へ置き換えたりすることです。たとえば、「山田太郎様」を「顧客A」、「東京都○○区」を「居住地域」と置き換え、問い合わせ内容の分類に必要な部分だけをAIへ渡します。

自動マスキングを採用する場合でも、置き換え漏れや、文脈から個人を推測できる可能性を考慮します。処理対象を必要最小限に限定できているか、再識別につながる情報が残っていないかを確認することが大切です。

選択肢2：AIを通さず担当者へ迂回する

個人情報や慎重な取扱いが必要な内容を適切に分離できない場合は、AIによる分類や要約を行わず、権限を持つ担当者へ直接引き継ぐ設計が考えられます。この方法では、受付システム側の判定、専用フォーム、顧客による申告、特定項目の入力有無などを使って処理経路を分けます。

たとえば、「個人情報を含む相談はこちら」という専用窓口を設ける、特定の入力欄が使用された場合はAI処理を迂回する、ファイルが添付された場合は担当者確認を先行させる、といった方法があります。

取得・閲覧・保存は必要最小限にする

個人情報を扱う業務では、AIを利用するかどうかにかかわらず、誰が、何の目的で、どの情報を閲覧するかを整理します。必要最小限の取得・閲覧に限定し、アクセス権限、保存場所、保存期間、削除方法、対応履歴の記録方法などを決めておくと、社内で説明しやすくなります。

詳細な法務判断、セキュリティ要件、プライバシーポリシーの見直し、契約上の確認については、第6章のリスク管理で改めて扱います。このセクションでは、少なくとも「AIに渡す前に保護・振り分けを行う」という設計上の入口を押さえておきましょう。

AIの例外処理をどう設計するか

AIの例外処理とは、通常の業務フローではそのまま扱えない案件が発生したときに、処理を止める、別の手順へ切り替える、担当者へ引き継ぐといった対応を行うことです。

「例外」という言葉から、非常に珍しい事態を想像するかもしれません。しかし、業務設計における例外には、日常的に発生する軽微なものも含まれます。入力漏れ、分類できない問い合わせ、添付資料の不足、担当部署が不明な案件なども、通常処理から外れるという意味では例外です。

本セクションでは、例外処理を「要確認」と「保留」に分けます。要確認は、案件の内容は把握できるものの、人による判断や承認が必要な状態です。保留は、情報不足、分類不能、処理可否の未確認などにより、現時点では判断を進められない状態です。

例外処理は「止める」だけではない

例外処理には、次のような対応パターンがあります。案件の性質に応じて、複数を組み合わせることもできます。

• 処理を一時停止する：人による確認が終わるまで、回答送信や登録確定を行わない。
• 担当者へ通知する：確認が必要な理由、関連情報、期限などを担当者へ伝える。
• 別の手順へ切り替える：通常の回答作成ではなく、専用窓口や専門部署への引き継ぎを行う。
• 追加情報を求める：不足項目を整理し、顧客や社内担当者へ確認を依頼する。
• AI処理を迂回する：情報の取扱条件を満たさない場合は、AIへ入力せず担当者へ渡す。
• 記録を残す：分岐結果、引き継ぎ理由、担当者、対応状況などを記録する。

どの対応を選ぶかは、案件の影響、処理期限、担当者の役割、現在の承認ルールなどを踏まえて考えます。すべての例外を同じ担当者へ送ると、確認が集中することがあります。例外の種類ごとに引き継ぎ先を分けると、運用しやすくなる場合があります。

AIが判断に迷うケースを用意しておく

条件分岐を設計するときに見落とされやすいのが、どの条件にも明確に当てはまらないケースです。AIが一般質問とクレームのどちらに分類するか迷う場合や、入力情報が少なく分類できない場合などが該当します。

このような案件に対して、AIに無理に一つの結論を選ばせる必要はありません。「分類不能」「判断材料不足」「複数分類に該当」「情報の取扱可否が未確認」といった状態を保留として認め、追加確認または人手判定へ切り替えます。

判断に迷う場合の扱いを決めるには、次の点を整理します。

• どのような状態を「要確認」または「保留」とみなすか
• AIは下書きや要約まで行うのか、処理を開始しないのか
• 誰が人手判定を行うのか
• 担当者へどの情報を渡すのか
• 不足情報を誰が、どの方法で確認するのか
• いつまでに判断または回答する必要があるのか

技術的な確信度の設定などは、具体的なシステムを選ぶ段階で検討できます。このセクションでは、まず業務上の考え方として、「判断できない場合に進む経路」を用意することが重要です。

AIワークフローを設計する4つの手順

条件分岐と例外処理は、現在の業務を完全に文書化してからでなければ考えられないものではありません。まずは代表的な業務を一つ選び、次の4つの手順で整理してみましょう。

実務例：問い合わせ対応の条件分岐

AIエスカレーションでは何を引き継ぐか

AIエスカレーションとは、AIだけで処理を続けず、権限や知識を持つ担当者へ案件を引き継ぐことです。引き継ぎ先だけを決めるのではなく、担当者が次の行動を取りやすいように、判断に必要な情報と対応状況をまとめて渡します。

たとえば、クレームを担当者へ引き継ぐ場合、「クレームの可能性があります」という通知だけでは、担当者は元の問い合わせを開き、履歴を探し、対応期限を確認する必要があります。

一方で、次のような情報がまとまっていれば、初動を取りやすくなります。

• 問い合わせ内容の要約
• 要確認または保留とした理由
• 権限上参照できる顧客区分や契約状況
• 過去の対応履歴
• 回答期限や緊急度
• AIが作成した下書きと参照資料
• 既読・未読、確認中などの対応状況
• 次に対応する担当者、期限、具体的なアクション

ただし、引き継ぎ情報を増やしすぎると、かえって確認しにくくなることもあります。担当者が判断するために必要な情報を中心にまとめ、個人情報については閲覧権限と利用目的に応じて表示範囲を限定します。

人による確認後にどこから再開するか

例外案件を担当者へ引き継いだ後の流れも、あらかじめ確認しておきましょう。人が確認した後、担当者自身が最後まで処理するのか、確認結果をもとにAIワークフローへ戻すのかによって、運用方法が変わります。

たとえば、AIが作成した回答案を担当者が修正・承認した後、業務システムが送信と履歴登録を行う設計も考えられます。一方、契約変更のように個別判断が多い案件では、引き継ぎ後の処理を担当者が行う方法もあります。

重要なのは、引き継ぎを「AIの処理が終わる場所」とだけ考えないことです。業務全体として、案件が完了するまでの流れを確認します。

条件分岐を具体化するための整理項目

条件分岐は、文章だけで検討するよりも、一定の項目に沿って表にすると関係者間で確認しやすくなります。次のような項目を使い、代表的な分岐から整理してみましょう。

条件を文章にするときは、「重要な場合」「問題がある場合」のような抽象的な表現だけで終わらせず、現場で判別するための手掛かりも添えます。

たとえば、「重要な顧客の場合」ではなく、「社内システム上の重要顧客区分に該当する場合」「担当営業が設定されている法人顧客の場合」とすると、関係者が同じ基準を共有しやすくなります。

一方で、すべてを厳密な条件に置き換えられないこともあります。その場合は、曖昧な案件を保留または要確認へ回し、運用しながら具体例を蓄積します。最初から完璧に決める必要はありません。

よくあるつまずき

通常処理を作り込み、例外処理が後回しになる

AI導入の検討では、正常に処理できる場面を中心に試行するため、通常処理が詳しくなる一方で、例外処理が「その他は担当者へ」の一文でまとめられることがあります。

この状態では、どの案件を誰へ引き継ぐかが分からず、運用開始後に確認が集中する可能性があります。通常処理の設計と並行して、少なくとも発生頻度が高い例外、影響が大きい例外、情報不足時の保留処理を整理しておくと、社内で説明しやすくなります。

判定基準が担当者の感覚だけで表現されている

「難しい問い合わせ」「重要な案件」「急ぎの依頼」といった表現は、人によって解釈が異なる場合があります。現在の業務では担当者の経験で補えていても、AIワークフローへ組み込む際には、判断の手掛かりを具体化する必要があります。

たとえば、「急ぎ」を「回答希望日が当日」「サービスが利用できない」「契約上の期限が近い」などに分けて考えます。数値や項目にできない部分は、要確認として人が判断する条件に残しても構いません。

AIへ入力した後で個人情報の有無を確認する

AIによる分類や要約が終わった後に個人情報を検出しても、すでに外部サービスへ情報が送信されている可能性があります。個人情報などの取扱区分は、AI処理の前段階で確認する設計が基本です。

マスキングしてから利用するのか、AI処理を迂回するのか、利用が認められた環境だけで処理するのかを、社内ルールと利用サービスの条件に合わせて整理します。

例外案件をすべて同じ担当者へ送る

例外案件の引き継ぎ先を一人にまとめると、責任の所在は分かりやすくなります。ただし、件数が増えたときに確認が集中し、処理が滞ることがあります。

クレームはサポート責任者、契約変更は契約担当、情報の取扱確認は管理部門というように、例外の種類ごとに役割を分けられるか確認してみましょう。最終責任者と、実際に一次確認する担当者を分ける方法もあります。

引き継いだ後の処理が決まっていない

AIから人へ通知するところまで設計されていても、その後の確認方法や完了条件が決まっていない場合があります。通知を受けた担当者が「どこまで対応すればよいか」「元のワークフローへ戻す必要があるか」を判断できないと、案件が途中で止まりやすくなります。

引き継ぎ先、担当者が行う判断、既読・対応状況、次回アクション、期限、処理の再開地点までを一続きの業務として確認すると、運用時の迷いを減らせます。

まれな例外を最初からすべて洗い出そうとする

業務には多くの例外があるため、すべてを事前に整理しようとすると検討が進みにくくなることがあります。まずは、過去に何度か発生しているケース、担当者が判断に迷いやすいケース、影響が比較的大きいケースに絞って整理してみましょう。

導入後に例外の発生内容を記録し、一定期間ごとに判定基準を追加・修正する方法もあります。条件分岐は一度決めて終わりではなく、運用実績をもとに見直す対象です。

経営者・責任者向けの確認ポイント

経営者や部門責任者は、個々の条件設定を細かく確認するだけでなく、AIと人の役割分担が組織の方針に合っているかを確認することが大切です。

• 最終判断と対外送信の責任者が明確か
  AIは下書き・要約・分類に限定し、契約、返金、補償、重要案件の判断や対外送信を誰が行うか確認します。
• 影響が大きい案件を人が確認できるか
  金額、顧客関係、事業継続、対外説明などに関係する案件について、どの段階で責任者へ引き継ぐかを確認します。
• 個人情報をAI処理前に振り分けられるか
  マスキング、AI処理の迂回、利用環境の限定など、社内ルールに合った処理経路があるか確認します。
• 必要最小限の取得・閲覧になっているか
  誰が、何の目的で、どの情報を閲覧できるかを整理し、保存期間や削除方法も確認します。
• エスカレーション先に対応余力があるか
  例外案件の件数を見込み、特定の担当者や部門に負担が集中しないか確認します。
• 案件の現在地と次回アクションを追跡できるか
  既読、対応中、保留、承認済みなどの状況と、誰が何をいつまでに行うかを確認できるようにします。
• 判定基準を定期的に見直す担当が決まっているか
  現場の運用実績や例外件数をもとに、分岐基準を更新する役割と時期を決めます。

条件分岐や例外処理は、現場の手順だけでなく、承認権限、情報管理、責任分担にも関係します。そのため、現場担当者だけで決めるのではなく、必要に応じて経営層、部門責任者、法務、情報システム、情報セキュリティなどの関係者と確認しながら進めます。

具体的なリスク評価、AI利用ガイドライン、セキュリティ、法務上の対応については、第6章で改めて扱います。この段階では、影響が大きい案件を人へつなぐ流れと、AI処理前に情報を保護する入口があるかを確認しておきましょう。

AI導入支援者としての着眼点

AI導入コンサルタントや社内推進担当者が業務をヒアリングする際は、通常処理だけでなく、「担当者が判断を止める場面」「別の権限者へ確認する場面」「情報の取扱いを理由に処理経路を変える場面」に注目します。

業務担当者は例外対応を経験的に行っていることが多く、最初の説明では出てこない場合があります。「例外はありますか」とだけ尋ねるより、具体的な場面を聞く方が、実務上の条件を確認しやすくなります。

ヒアリングでは、例外の有無だけでなく、発生頻度と影響の大きさも確認します。毎日発生する入力不足と、年に数回の重要案件では、設計上の優先順位や引き継ぎ方法が異なるためです。

また、現場から聞いた判定基準が社内規程や責任者の認識と一致しているかも確認します。担当者ごとに異なる運用がある場合は、AI導入の前提として、どの手順を標準とするかを関係者で整理します。

支援者がすぐに条件を決めるのではなく、現場が何を根拠に判断しているか、どの情報をどこまで扱えるか、誰が最終責任を持つかを言葉にし、関係者が合意できる形に整えることが大切です。

ミニチェックリスト

自社のAIワークフローに条件分岐と例外処理を組み込む際は、次の項目を確認してみましょう。

• 現在の通常処理を、受付から完了まで可視化している。
• 事前に定義した判定基準に基づき、通常処理・要確認・保留を分けている。
• AIの役割を下書き・要約・分類などに限定し、最終判断者を決めている。
• 個人情報をAI処理前にマスキングまたは迂回する方法を決めている。
• 影響が大きい案件や判定不能案件を人へ引き継ぐ経路がある。
• 引き継ぎ時に案件概要、理由、期限、対応状況、次回アクションを共有できる。
• 取得・閲覧・保存を必要最小限にし、権限と保存期間を整理している。

まとめ