先に結論:AI導入の変更後に担当者が変わる時は、操作手順だけでなく変更差分、現行の正本、確認者、例外と戻し先、再確認日の5項目を一枚へまとめます。次の担当者が通常・境界・停止を説明できない場合は、処理を進めず、前の担当者または責任者へ戻してください。
AIの設定や対象業務を変えた後は、変更した人には分かっている前提が、次の人には見えません。FAQは更新したのに社内チャットには古い答えが残っている、AIの出力を確認する人だけ変わった、例外の時にどの台帳へ戻るかが決まっていない。こうした小さなずれが、担当者交代の朝に同時に現れます。
引き継ぎを「資料を渡した」「アカウントを発行した」で終えると、次の人は古い成功例を現在のルールだと思って使います。この記事では、5項目の比較表、通常・境界・停止の分け方、6手順、引き継ぎチェックリスト、FAQを整理します。変更を社内へ知らせる前の準備は変更を周知する前の6項目、変更後の例外処理は例外を手動へ戻す6手順も参照してください。
引き継ぎで渡すのは操作方法ではなく判断の境界
操作方法は、どの画面を開き、どの欄へ入力するかを示します。一方、判断の引き継ぎは、どの条件なら進め、どの条件なら人へ戻すかを示します。AI導入では後者が抜けると、同じ操作をしていても担当者ごとに違う結果になります。
| 状態 | 次の担当者が確認すること | 扱い | 戻し先 |
|---|---|---|---|
| 通常 | 入力、対象範囲、確認者が正本と一致 | 決めた手順で進める | 現行手順・記録欄 |
| 境界 | 条件の一部が不明、変更の影響が読めない | 保留して確認する | 判断ログ・責任者 |
| 停止 | 顧客、契約、金額、機密、公開情報へ影響 | AI処理を止める | 手動手順・承認者 |
「前任者なら分かる」は、引き継ぎが未完了である合図です。次の人が迷うこと自体は問題ではありません。迷った時に保留する場所、確認を頼む相手、処理を戻す手順が残っていることが重要です。AIへ任せない業務の境界は使わない業務の決め方、停止後の再開条件は条件がそろった時だけ再開する方法で整理できます。
変更後の判断を引き継ぐ5項目
5項目は、長い引き継ぎ書を作るための分類ではありません。次の担当者が一件を見た時に、古い情報を使わずに現在の判断へ戻るための最小単位です。
| 項目 | 書く内容 | 空欄の時の扱い |
|---|---|---|
| 変更差分 | いつ、何を、なぜ変えたか。変更前後の違い | 現行と決めず保留 |
| 現行の正本 | 手順、FAQ、設定、判断ログのうち現在の参照先 | 責任者へ確認 |
| 確認者 | 通常の確認者、代理、承認者、停止を決める人 | 自動処理を進めない |
| 例外と戻し先 | 対象外の条件、手動手順、記録先、通知先 | 境界または停止 |
| 再確認日 | 次に見直す日、確認する変更イベント、担当者 | 期限を決めるまで完了にしない |
変更差分には、追加した機能だけでなく「変えなかった条件」も書きます。対象業務を広げていない、個人情報の入力は禁止のまま、最終承認は人が行う、といった不変条件があると、次の担当者が変更範囲を大きく解釈しません。現行の正本は一つに指し、チャットの説明は通知として扱います。
6手順で、次の担当者が一件を判断できる状態にする
- 引き継ぐ対象を一件に絞る:全業務の資料をまとめる前に、変更後に最初に迷った案件を選びます。対象業務、入力、出力、確認者を一行で書きます。
- 変更前後を並べる:旧手順、現在の手順、設定、FAQを並べ、追加・削除・担当者変更を分けます。更新日だけでなく、適用開始日も確認します。
- 正本を一つ指す:次の担当者が最初に開くURLや文書を決めます。複数の資料に同じ答えを書き直さず、差分と参照先を残します。
- 通常・境界・停止を例示する:実際の通常案件、迷った案件、止めた案件を一つずつ置きます。成功例だけでは、いつ人へ戻すかが伝わりません。
- 確認者と戻し先を照合する:担当者、代理確認者、承認者、停止を決める人を分け、例外時の手動台帳や判断ログを実際に開けるか確認します。
- 次の確認日を予約する:再確認日、見る変更イベント、更新担当を記録します。担当者交代、入力情報、顧客条件、AI設定の変更があれば、予定日を待たずに見直します。
この手順では、前任者が説明するだけで終わらせません。次の担当者に通常・境界・停止の三件を見せ、どこへ戻るかを指してもらいます。答えが違った時は、理解不足として責めるのではなく、正本や例外の記述が不足していると考えて直します。
判断ログを更新する合図はAI判断ログを更新する6つの合図、記録の保持や見直しはAI運用ログを手放す基準にも整理しています。引き継ぎ資料を増やす前に、何を正本へ戻すかを決めてください。
手順書・FAQ・判断ログの役割を混ぜない
変更後に起きたことを一つの引き継ぎ書へ詰め込むと、通常手順と個別の判断理由が混ざります。次の担当者が使う目的ごとに、記録先を分けると更新しやすくなります。
| 記録先 | 残すもの | 次回の見直し |
|---|---|---|
| 現行手順 | 通常処理、入力条件、確認、完了条件 | 業務や設定が変わった時 |
| FAQ | 繰り返す質問、適用範囲、例外の入口 | 同じ問い合わせが増えた時 |
| 判断ログ | 迷った理由、根拠、承認、停止、再開条件 | 担当者や判断条件が変わった時 |
チャットは、変更を知らせる入口としては便利です。しかし、通知だけで完了にすると、後から検索した人は最新の判断を見つけられません。チャットの決定を正本、FAQ、判断ログのいずれかへ戻し、通知には戻し先だけを残します。社内FAQへ変換できる迷いは判断ログをFAQへ戻す6手順が参考になります。
変更後の引き継ぎチェックリスト
- 変更日、適用開始日、変更理由、変更しなかった条件を記録した
- 変更前後の手順、設定、FAQの差分を確認した
- 次の担当者が最初に開く現行の正本を一つ指した
- 通常・境界・停止の実例を一件ずつ用意した
- 通常の確認者、代理確認者、承認者、停止を決める人を分けた
- 例外の条件、手動の戻し先、記録先、通知先を確認した
- 顧客、契約、金額、個人情報、公開情報への影響を見た
- チャットの決定を正本または判断ログへ戻した
- 次の担当者が三つの状態と戻し先を説明できた
- 再確認日、確認する変更イベント、更新担当を予約した
一つでも空欄があれば、引き継ぎを完了扱いにしません。特に正本、確認者、例外の戻し先がない場合は、次の担当者が善意で判断を補うことになります。処理を小さく保留し、責任者と一緒に空欄を埋めてから再開してください。引き継ぎ前に入力範囲を点検する方法は問い合わせを引き継ぐ前の情報整理、人の確認条件はAI業務フローの人間確認条件も役立ちます。
FAQ:AI導入の変更後に判断を引き継ぐ方法
AI導入の変更後、引き継ぎで最初に伝えることは何ですか?
変更差分と現行の正本を最初に伝えます。何が変わったか、どの資料が現行かが分からないまま操作手順だけ渡すと、古い判断が再利用されます。
担当者が判断できない案件はどう扱いますか?
境界案件として保留し、確認者と手動の戻し先を決めます。顧客、契約、金額、個人情報、公開情報に影響する場合や戻し先がない場合は処理を止めます。
引き継ぎメモはチャットだけでもよいですか?
チャットは通知に使えても正本にはしません。変更差分、判断理由、例外、再確認日を現行手順や判断ログへ戻し、次の担当者が検索できる場所を一つにします。
いつ引き継ぎが完了したと判断できますか?
次の担当者が通常・境界・停止の一件ずつを説明し、現行の正本、確認者、戻し先、再確認日を指せる状態です。読んだだけでなく、短い照合を行います。
無料診断で、変更後の判断が戻れる設計を確認する
AI導入の引き継ぎで大切なのは、資料を増やすことではありません。次の担当者が、現在の正本を見つけ、通常の処理を進め、境界で人へ戻り、停止後の再開条件を確認できることです。
Miraigentの無料診断(60秒)では、対象業務、入力情報、人間確認、例外、停止後の戻し先を整理できます。まず直近の変更を一件選び、5項目の空欄を埋めてください。担当者が変わっても判断が戻れる形になっていれば、AIの利用範囲を安全に小さく広げられます。
関連:変更を社内へ知らせる前の6項目 / 古い案内を正本へ戻す6手順 / 例外を手動へ戻す6手順 / 問い合わせが増えた時の5項目
