確認・統制・評価を組み込む

17-1確認の流れを組み込む

第4章の3つの型（入口・関所・事後）で、みなもと家電の窓口の確認を設計しました。

型	どこで	誰が（何が）	何を確かめるか
入口	フォームの送信時	システム	型番の選択、購入店の選択（オンラインストア／量販店）が入っているか。足りなければお客様に入力を求める
入口	AIに渡す前	システム	氏名・電話番号などを伏せ字にしたか
関所	担当者が開いたとき	担当者	種類の判定が正しいか（違えば直す）
関所	送信の前	担当者（全件）	回答案の確認の観点（下記）
関所	送信の前	リーダー	安全案件、返金・無償修理・苦情に当たるもの
事後	毎週	リーダー	「その他」に分類されたもの全件と、他の種類から無作為に50件の分類の正しさ。安全案件の見逃しがないか

回答案の確認の観点

担当者が回答案を確かめるときの観点を、5つに絞りました（第4章 4-4）。画面には回答案の横に根拠の資料の該当箇所が表示され、照らし合わせて確かめられるようにします。

1. 根拠：回答案の内容が、示された根拠の箇所と一致しているか
2. 商品：お客様の商品（型番）に合った説明か
3. 条件：期間・金額・手続きが方針と規定どおりか
4. 約束：返金・交換・無償修理など、権限のない約束をしていないか
5. 求め：お客様が求めていることに答えているか

5つのうち、特に「約束」は1つでも誤るとお客様との間で大きな問題になるため、画面で目立つように表示します。

17-2人に回す流れを決める

第4章のエスカレーションの5つの決めごとを、案件の種類ごとに決めました。

条件	回す先	添える情報	期限	戻し方
安全案件（照合またはAIの検知）	リーダーと品質保証部（リーダー不在時は窓口の副担当）	該当する文の抜き出し、型番、購入日	30分以内に一次連絡。品質保証部が対応方針を当日中に決める	対応方針を記録。安全案件でなかった場合はリーダーが理由を記録して戻す
資料に記載なし・食い違いあり	担当者が調べ、分からなければリーダー	AIが「記載なし」とした理由	当日中にリーダーへ	回答を回答集に追加する候補として記録
返金・無償修理・特別対応	リーダー（1万円を超える返金は課長）	AIの下調べのまとめ、方針の該当箇所	翌営業日中	判断と理由を判断例として記録
苦情・感情的な問い合わせ	リーダー	これまでのやり取り	当日中	対応を記録
修理センター・品質保証部への確認	各部署の受付担当（問い合わせ管理システムで依頼）	問い合わせ内容、確認したいこと	翌営業日中（第15章で取り決めた期限）	回答を回答集に追加する候補として記録

どの流れにも「戻し方」として、人の判断を回答集や判断例に加える候補として記録することを入れています。こうすることで、AIが答えられない質問が少しずつ減っていきます（第7章 7-4）。

17-3権限と記録を決める

第10章のチェックリストに沿って、統制を設計しました。

項目	決めたこと
権限	AIは、問い合わせ管理システムで「種類」「回答案」「根拠」「記録の要約」の欄に書き込める。送信はできない。販売管理・修理受付システムは読むだけ。お客様の情報（マスタ）は変更できない
アカウント	AI専用のアカウントを作り、担当者のアカウントと区別する
職務分掌	返金は、窓口が経理部に依頼し、経理部が自部署のシステムで承認・処理する。窓口のAIも担当者も、返金の実行はできない
承認	リーダーの承認画面では、安全案件・返金・苦情を分けて表示し、一括承認はできないようにする
状態の権限	表16-3のとおり。送信と、安全案件を外すのは人だけ
ログ	AIの入力（伏せ字後）・出力・根拠・指示の版、担当者の修正内容、承認者を、問い合わせの記録と同じ期間残す
変更管理	指示と回答集の変更は、業務改善担当が案を作り、リーダーが承認する。指示の変更とAIの版の変更は、例題集で測り直してから使う
悪用への備え	問い合わせ本文の中の指示に従わないことを指示に明記（第16章）。返金先の口座の変更依頼は、メールでは受け付けず、登録済みの電話番号に確認する

17-4評価計画を立てる

第11章のテンプレートで、評価計画を立てました。

例題集

過去3か月の問い合わせから、次の構成で200件の例題集を作りました。正解（正しい種類、安全案件かどうか）は担当者2名で付け、食い違った12件については種類分けの基準表を見直しました。

種類	件数	うち境目の案件
使い方	50件	15件（故障か使い方の誤りか迷うもの など）
配送・注文	40件	10件
故障・修理	40件	10件
返品・返金	30件	10件（初期不良か、お客様都合か など）
その他	20件	5件
安全案件	20件	10件（決めた言葉を含まない表現のもの）

回答案の評価用には、このうち使い方と配送・注文から50件を選び、第11章の採点表（根拠・必要な事項・約束の範囲・言葉づかい）で2人が採点することにしました。例題集の200件は、AIが参照する判断例とは分けて管理します（第11章 11-4）。

合格ライン（測る前に決めたもの）

対象	試行を始める条件	任せ方を上げる条件
安全案件の検知（照合＋AI）	例題の安全案件20件で見逃し0件。空振りは30件以下	上げない（常に人が判断）
種類分け	正確さ90%以上	運用で95%以上が4週続いたらレベル3
回答案	採点表で合格（合計6点以上、かつ0点なし）が7割以上。「約束の範囲」の0点は0件	使い方の質問で合格9割以上が3か月続いたら、自動回答の検討を始める

比べる基準として、同じ例題集を担当者3名にも処理してもらいました。種類分けの正確さは、人の平均で93%でした。AIに人以上の完璧さを求めないための、大事な物差しです（第11章 11-5）。

17-5小さく試す計画

例題集で合格ラインを満たしたことを確かめたうえで、いきなり全員で使い始めるのではなく、範囲を限って試すことにしました（第19章）。

試行メンバーと、これまでの手順のメンバーを並べて比べることで、効果がAIによるものか、時期や問い合わせの傾向によるものかを見分けやすくなります。

17-6止まったときの手順

第12章の決めごとに沿って、止まったときの手順を決めました。

何が止まったか	代わりの手順	切り替えの判断
安全案件のAI検知	システムの照合は続け、加えてリーダーが新着を1時間ごとに目視	止まったと分かった時点ですぐ（リーダー）
種類分け	これまでどおりリーダーが朝・昼・夕に割り振る	受信後30分たっても分類されないものが10件を超えたら（リーダー）
回答案	担当者が回答集を見て回答を書く（統合した回答集なので、以前より速い）	担当者の判断で個別に

代わりの手順の文書は、問い合わせ管理システムのトップに掲示します。また、新人の研修では、AIを使わずに回答集から回答を書く練習を必ず行い、手作業で回せる技能を保ちます。

17-7事前の振り返りで、最後の点検

試行を始める前に、関係者8名で第13章の「事前の振り返り」を行いました。「6か月後、この取り組みは失敗に終わった。なぜか」という問いに出てきた理由のうち、起きやすく影響の大きいものを3つ選び、予防策を加えました。

出てきた失敗の理由	パターン	加えた予防策
新商品が出たのに回答集が更新されず、AIが古い情報で答えた	7. 知識が古くなる	商品企画部の発売前チェックリストに「窓口の回答集の更新依頼」を加えてもらう
担当者が回答案を信じすぎて、確認せずに送った	10. 確認が形だけになる	確認の観点の画面表示に加え、毎週の事後確認で「そのまま送られた回答案」から10件を抜き取って点検する
業務改善担当が異動し、指示の意図が分からなくなった	14. 作った人しか分からない	設計書一式を問い合わせ管理システムの共有の場所に置き、指示の持ち主をリーダーにする

17-8できあがった設計書一式

第14章から第17章までで、次の設計書がそろいました。どれも、第1・2部で学んだ型を当てはめて作ったものです。

設計書	章	使った型
業務分解表・判断基準・例外一覧・課題の整理	第14章	第2章
要件メモ（成功の物差し・やらないこと・非機能・AI特有の要件）	第15章	第5・12章
任せ分け表	第15章	第3章
データの一覧・項目定義表・状態と権限	第16章	第6章
知識の棚卸し・返品の方針	第16章	第7章
型の選択・AIへの指示・渡す情報	第16章	第7・8章
確認の流れ・人に回す流れ	第17章	第4章
権限と記録	第17章	第10章
評価計画・試行計画・止まったときの手順	第17章	第11・12・19章

振り返ると、最初の依頼は「AIで自動回答したい」でした。設計を通して、実際に取り組むことは「回答集の一本化」「他部署との受け渡しの見直し」「根拠付きの回答案と人の確認」「安全案件の二重の検知」となり、自動回答は実績を積んだ先の次の段階に位置づけられました。依頼の言葉と、本当に取り組むべきことは、設計を経て初めて分かります。

この設計書一式を、どうやってシステム部門やベンダーに伝え、実際の仕組みにしていくか。それが第4部のテーマです。