生成AIを業務で使い始めると、最初はうまくいったように見えます。
問い合わせ返信の下書きが早くなる。
議事録の要約がすぐ出る。
FAQ案がたくさん作れる。
社内メモのたたき台も整う。
ここまでは、いい感じです。
ただ、しばらく運用すると、必ずこういう場面が出てきます。
「この問い合わせは、いつもの流れと少し違う」
「このお客様には、先に確認しないといけない条件がある」
「AIの出力は自然だけど、そのまま送るのは危ない」
「担当者によって、止める人と進める人が分かれている」
いわゆる例外対応です。
前回、生成AIの確認レビュー後は、修正理由を改善ログに残す で、AIの出力を直した理由を次回の改善へ戻すことを書きました。
今回は、その改善ログの中でも特に大事な「例外」をどう扱うかの話です。
例外が出るたびに、担当者の勘でなんとかする。
詳しい人に毎回聞く。
責任者が全部見る。
こうなると、生成AI活用は広がりません。
AIを使って省力化したはずなのに、例外のたびに人が集まって会議になる。
それ、効率化というより、確認会の新設です。なんでやねん案件です。
総務省・経済産業省の AI事業者ガイドライン第1.2版 でも、AI活用に関わる体制やリスク対応は、継続的に見直す前提で整理されています。
IPAの AI利用者のためのセキュリティ豆知識 でも、AI利用者や管理者が最低限の対策を理解し、利用ケースの広がりに合わせて更新していく考え方が示されています。
また、中小機構の 中小企業のAI等利活用に係る実態調査 では、AI導入の目的として業務効率化や作業時間短縮への期待が大きく扱われています。
ただ、効率化は「例外がない業務」だけで起きるものではありません。
むしろ、小さな会社の業務は例外だらけです。
お客様ごとの事情。
納期の都合。
契約前後の違い。
社内で確認すべき情報。
外へ出してよい言葉、出してはいけない言葉。
ここを毎回その場の判断に戻していると、AI活用は担当者依存になります。
生成AIの例外対応は、担当者の勘を否定するためではなく、勘で止めた理由を次の人も使える形にするためにあります。
今日は、小さな会社やひとり社長が、生成AIの例外対応を担当者任せにしないために、分岐表として整理する方法をまとめます。
例外対応は、AIの失敗ではなく業務の分かれ道として見る
生成AIの出力が想定どおりに進まないと、つい「AIが失敗した」と考えたくなります。
もちろん、AIが間違えることはあります。
事実が違う。
言い切りすぎる。
社内事情を勝手に補う。
文脈を取り違える。
これは確認が必要です。
ただ、実務で起きる例外のすべてが、AIの失敗とは限りません。
むしろ多くは、業務側に分かれ道があるだけです。
たとえば、問い合わせ返信の下書きをAIに作ってもらうとします。
通常の問い合わせなら、そのまま返信案を整えればいい。
でも、次のような場合は違います。
- 金額が絡む
- 契約前の個別条件がある
- 既存顧客からの相談で、過去の経緯が関係する
- 断り方を間違えると関係性に響く
- 個人情報や社内情報が含まれている
この場合、AIの文章力だけの問題ではありません。
業務として、次にどこへ進めるかを決める必要があります。
つまり例外対応は、AIの採点ではなく業務判断です。
「このまま進める」
「いったん止める」
「別の人に確認する」
「お客様へ追加で質問する」
「今回はAIを使わず、人が書く」
こういう分かれ道を決める場面です。
ここをAIの失敗扱いにすると、話がぼやけます。
「もっと良いプロンプトにしよう」
「もっと賢いAIを使おう」
「担当者がちゃんと見よう」
そういう方向に行きがちです。
もちろんプロンプト改善も大事です。
でも、例外が業務の分かれ道なら、必要なのはプロンプトだけではありません。
分岐表です。
どんな条件なら進めるか。
どんな条件なら止めるか。
誰に確認するか。
確認後にどこへ戻すか。
この分岐を小さく書いておくと、担当者の負担が減ります。
生成AIの自動化実験後は、プロンプトより業務手順を直す でも書いたように、AI活用はプロンプトだけでは安定しません。
入力、出力、確認者、止める条件、戻し方。
これらが業務手順としてつながって、ようやく運用になります。
例外対応は、その中でも「止める条件」と「戻し方」を見えるようにする作業です。
最初から完璧なルールにする必要はありません。
まずは、よく出る例外を3つだけ拾います。
問い合わせ返信なら、金額、納期、個人情報。
採用文面なら、条件、差別的な表現、未確定情報。
議事録なら、発言者不明、決定事項、社外秘。
自社の業務で、毎回迷うものからでいいです。
例外は、なくすものではありません。
分かれ道として見えるようにするものです。
最初に分けるのは、進める、止める、確認するの3つでいい
分岐表というと、難しく聞こえるかもしれません。
条件がたくさん並んだ業務フロー。
責任者ごとの承認ルート。
リスク分類。
例外コード。
そういうものを想像すると、小さな会社では始めにくくなります。
でも、生成AI活用の初期に必要な分岐は、もっとシンプルでいいです。
最初は3つだけです。
進める。
止める。
確認する。
この3つに分けます。
進めるのは、通常どおりAIの出力を使ってよいケースです。
たとえば、社内メモの要約。
公開前に人が読むブログのたたき台。
社外に出さないアイデア整理。
個人情報や金額がなく、判断も軽いもの。
こういうものは、担当者が確認して進められます。
止めるのは、その場でAI活用を続けない方がいいケースです。
たとえば、契約条件が未確定なのにAIが断定している。
個人情報や社外秘が出力に混ざっている。
お客様への説明として責任が重い。
事実確認ができない情報を使っている。
こういうときは、いったん止めます。
止めることは、失敗ではありません。
むしろ運用として正常です。
危ないまま進めないためのブレーキです。
確認するのは、担当者だけで判断しない方がいいケースです。
たとえば、金額の調整が必要。
既存顧客との過去の約束が関係する。
表現を弱めるべきか、はっきり伝えるべきか迷う。
クレームや解約につながる可能性がある。
この場合、担当者が全部背負う必要はありません。
確認者や責任者へ渡します。
ここで大事なのは、3つの分岐を「担当者の性格」で決めないことです。
慎重な人は全部止める。
勢いのある人は全部進める。
詳しい人だけが確認する。
こうなると、運用が人に寄ります。
分岐表は、その差を減らすためにあります。
たとえば、問い合わせ返信ならこうです。
- 個別条件なし、一般的な案内だけなら進める
- 契約、金額、納期をAIが断定したら止める
- 既存顧客やクレームの可能性があれば確認する
これくらいで十分です。
文章としてきれいに整っていなくても構いません。
現場が見て、次に何をするか分かることの方が大事です。
生成AIの例外対応では、判断の言葉を短くするほど使いやすくなります。
進める。
止める。
確認する。
まずはこの3つです。
分岐表には、条件、判断者、次の行動だけを書けばいい
分岐表を作るとき、項目を増やしすぎると続きません。
業務名。
発生日。
重要度。
リスク分類。
AIツール名。
プロンプト。
出力全文。
修正内容。
判断者。
承認者。
対応期限。
再発防止策。
全部あった方が安心に見えます。
でも、最初からここまで書こうとすると、分岐表を書くための仕事が増えます。
小さな会社で大事なのは、使える最小形にすることです。
僕なら、最初は3項目にします。
条件。
判断者。
次の行動。
この3つです。
条件は、どんなときにその分岐へ入るかです。
「金額をAIが断定している」
「お客様ごとの事情が入っている」
「公開前の情報が含まれている」
「事実確認が必要な外部情報を使っている」
「社内の約束と違う表現になっている」
判断者は、誰が決めるかです。
担当者でよいのか。
確認者へ渡すのか。
責任者へ渡すのか。
外部の専門家へ確認するのか。
ここを決めます。
次の行動は、実際に何をするかです。
そのまま整えて使う。
お客様へ追加質問する。
AI出力を破棄して人が書く。
プロンプトへ条件を追加する。
改善ログへ残す。
月次レビューで扱う。
この3つがあれば、かなり動けます。
逆に、この3つがないと、例外対応は会話に戻ります。
「これ、どうしますか」
「前はどうしてましたっけ」
「誰に聞けばいいですか」
「とりあえず今回は人が直します」
これが毎回起きます。
分岐表は、細かい正解表ではありません。
迷ったときの入口です。
たとえば、問い合わせ返信のAI活用なら、最初の分岐表はこんな粒度で十分です。
- 条件：金額や納期をAIが断定している
- 判断者：責任者
- 次の行動：返信前に条件確認へ戻す
- 条件：お客様の個別事情が含まれている
- 判断者：担当者と確認者
- 次の行動：過去のやり取りを確認してから返信案を直す
- 条件：一般的な案内だけで個人情報がない
- 判断者：担当者
- 次の行動：表現だけ整えて進める
このくらいなら、1枚の表で作れます。
スプレッドシートでも、Notionでも、共有ドキュメントでもいいです。
大事なのは、立派な管理画面を作ることではありません。
担当者が迷ったときに、次の一手が分かることです。
生成AIの確認者は、専門家より業務の違和感に気づける人から育てる でも書いたように、確認者はAIの正解を当てる人ではありません。
業務として出してよいかを見極める人です。
分岐表は、その確認者を助ける道具です。
「これは自分で進めていい」
「これは止める」
「これは責任者へ渡す」
この判断を、少し軽くしてくれます。
例外が出たら、プロンプトより先に入力条件を見直す
生成AIで例外が出ると、すぐプロンプトを直したくなります。
「もっと丁寧に書いて」
「もっと短くして」
「金額は断定しないで」
「お客様に寄り添って」
たしかに、プロンプト修正で改善することもあります。
でも、例外対応では、プロンプトより先に見た方がいい場所があります。
入力条件です。
AIに渡す前の情報が足りているか。
判断に必要な前提が入っているか。
使ってよい情報と、使ってはいけない情報が分かれているか。
出力してほしい範囲が決まっているか。
ここが曖昧なままプロンプトだけ直しても、次回また迷います。
たとえば、AIに問い合わせ返信を書かせるとします。
プロンプトには「丁寧に返信してください」と書いてある。
でも、入力には次の情報が入っていない。
- 初回問い合わせなのか
- 既存顧客なのか
- 料金を出してよい段階なのか
- 納期を約束してよいのか
- まず聞くべき条件があるのか
これでは、AIはそれっぽく埋めます。
そして担当者が見て、「なんか違う」となります。
このとき、プロンプトへ「なんか違わないように」と書いても解決しません。
なんか違う、は業務条件が足りないサインです。
先に入力項目を直した方がいいです。
問い合わせ返信なら、AIに渡す前にこう分けます。
- 問い合わせ種別
- 初回か既存顧客か
- 金額回答の可否
- 納期回答の可否
- 追加確認が必要な条件
- 社外に出してはいけない情報
これがあれば、AIの出力はかなり安定します。
そして例外が出たときも、分岐表に戻しやすくなります。
「金額回答の可否が未入力なら止める」
「既存顧客で過去経緯があるなら確認者へ渡す」
「追加確認が必要な条件があるなら、お客様への質問文を作る」
こういう分岐にできます。
プロンプトは、魔法の呪文ではありません。
業務条件をAIへ渡すための器です。
器に入れる材料が足りなければ、出力もぶれます。
だから、例外が出たときは順番が大事です。
まず入力条件を見る。
次に分岐表を見る。
最後にプロンプトを直す。
この順番です。
プロンプトだけを直していると、担当者の頭の中にある前提がいつまでも外に出ません。
「このお客様は先にヒアリング」
「この条件なら金額は出さない」
「この言い方はうちでは使わない」
こういう判断こそ、分岐表や入力項目に戻した方がいいです。
AI内製化で大事なのは、担当者の勘を消すことではありません。
担当者の勘が働いた場所を、次回の入力条件へ戻すことです。
確認者が迷う例外は、責任者へ渡す基準まで決める
例外対応でいちばん危ないのは、確認者が一人で抱え込むことです。
AIの出力を見て、なんとなく危ない気がする。
でも、どこまで直せばいいか分からない。
責任者へ聞くほどでもない気がする。
でも、そのまま出すのもこわい。
この状態が続くと、確認者が疲れます。
そして、AI活用そのものが重くなります。
確認者は、すべての例外を解決する人ではありません。
止めるべきものを止める。
自分で判断できる範囲を進める。
重いものは責任者へ渡す。
この役割分担が必要です。
だから分岐表には、責任者へ渡す基準も入れます。
たとえば、次のようなものです。
- 金額、契約、納期を新しく約束する
- クレームや解約につながる可能性がある
- 個人情報や機密情報の扱いに迷う
- 法律、医療、税務、労務など専門判断が必要
- 社外へ公開すると信用に影響する
- 過去の約束と違う可能性がある
このあたりは、確認者だけで抱えなくていいです。
責任者へ渡します。
大事なのは、「不安なら聞いて」だけで終わらせないことです。
不安なら聞いて、は優しいようで曖昧です。
何が不安なら聞くのか。
誰に聞くのか。
どの状態で止めるのか。
どこまで担当者が直してから渡すのか。
ここが決まっていないと、確認者は迷います。
分岐表では、渡す基準を具体的にします。
「金額をAIが書いたら責任者確認」
「契約条件に触れたら送信前に確認」
「個人情報が含まれる場合は、AI出力を保存せず、人が確認」
「クレーム可能性がある場合は、返信案ではなく事実整理だけAIに作らせる」
このくらいまで書くと、確認者は動きやすくなります。
また、責任者側にもメリットがあります。
何でもかんでも上がってくるのではなく、基準に沿った例外だけが来ます。
すると、責任者は判断に集中できます。
確認者も、自分が見ればいい範囲と、渡していい範囲が分かります。
AI活用を広げるとき、確認者を増やすだけでは足りません。
確認者が迷ったときの逃げ道を作ることが大事です。
逃げ道というと後ろ向きに聞こえるかもしれませんが、業務ではかなり大事です。
迷ったら止めてよい。
重いものは渡してよい。
判断できないことを判断したふりにしない。
この設計があると、AI活用は無理なく続きます。
1週間に一度、例外を1つだけ通常手順へ戻す
分岐表は、作って終わりではありません。
むしろ、運用しながら育てるものです。
最初の分岐表は、だいたい粗いです。
抜けもあります。
表現も曖昧です。
想定外も出ます。
それで大丈夫です。
最初から完璧な分岐表を作ろうとすると、始まりません。
大事なのは、例外が出たあとに、1つだけ通常手順へ戻すことです。
たとえば、1週間AIを使ってみる。
問い合わせ返信、議事録、FAQ作成、社内メモ整理。
その中で、例外が5件出たとします。
この5件を全部直そうとすると重いです。
だから、まず1つ選びます。
一番よく出たもの。
一番時間を取られたもの。
一番危なかったもの。
一番次も起きそうなもの。
どれか1つでいいです。
そして、その例外を通常手順へ戻します。
たとえば、問い合わせ返信で「金額をAIが断定してしまう」がよく起きたなら、次のように直します。
- 入力項目に「金額回答の可否」を追加する
- 分岐表に「金額を断定したら責任者確認」を入れる
- プロンプトに「金額は条件確認後に扱う」と書く
- 確認チェックに「金額、納期、契約条件」を入れる
これで、次回の同じ例外は少し減ります。
完全になくならなくてもいいです。
少し早く気づける。
少し止めやすくなる。
少し責任者へ渡しやすくなる。
それで十分です。
生成AIの内製化は、一気に完成させるものではありません。
小さな例外を、少しずつ通常手順へ戻していくことです。
生成AIの改善タスクは、月次レビュー後に1つだけ実行する でも書いたように、改善はたくさん並べるより、1つ実行する方が前に進みます。
分岐表も同じです。
例外を集める。
1つ選ぶ。
入力条件、分岐表、プロンプト、確認チェックのどこかを直す。
次の1週間でまた見る。
この繰り返しです。
すると、担当者の勘で止めていたものが、少しずつ会社の手順になります。
確認者だけが知っていた違和感が、他の人にも見えるようになります。
責任者に聞くべきものと、担当者が進めてよいものが分かれてきます。
AI活用は、派手な自動化だけではありません。
むしろ、こういう地味な分岐の整理が、社内に残る力になります。
最後に、今日の話をまとめます。
- 例外対応は、AIの失敗ではなく業務の分かれ道として見る
- 最初の分岐は、進める、止める、確認するの3つでいい
- 分岐表には、条件、判断者、次の行動だけを書く
- 例外が出たら、プロンプトより先に入力条件を見る
- 確認者が迷うものは、責任者へ渡す基準を決める
- 1週間に一度、例外を1つだけ通常手順へ戻す
生成AIを業務に入れると、例外は必ず出ます。
例外が出ること自体は、悪いことではありません。
むしろ、業務の分かれ道が見えたということです。
その分かれ道を、担当者の頭の中だけに残すか。
分岐表として、次の人も使える形にするか。
ここで、AI活用の定着度が変わります。
カタチ舎では、小さな会社やひとり社長向けに、生成AIの業務棚卸し、入力項目の整理、確認者設計、例外対応の分岐表づくりまで一緒に整理しています。
AIを入れたけれど、例外のたびに手が止まっている。
担当者の勘に頼りすぎていて、他の人へ広げにくい。
そんな状態なら、まずは1つの業務だけで大丈夫です。
お問い合わせ から、今のAI活用で止まりやすい場面を教えてください。
分岐表にするところから、一緒にカタチにしていきます。
Author
村上龍平
カタチ舎代表。言葉、生成AI活用、資料・Web制作を行き来しながら、事業の考えを届く形へ整理しています。