AIが受付票を変えたか分からない？提案・承認・保存結果を分ける記録

修理受付の担当者が、AIの「受付票の担当部門を保守へ変更する」という案を確かめる場面です。人がその案を承認したか、ツールが操作を受け付けたか、保存先の値がどうなったかを追えなければ、次の担当者へ完了とは渡せません。

ここでいう「操作の受付」は、変更の要求に対する応答です。「保存結果」は、保存先にある対象の記録を別の読取で確かめた状態です。この記事では二つの別々の受付票を例に、この違いと記録の設計を説明します。以下は架空の記録で、実際のAI操作・承認・保存試験の結果ではありません。

AIで生成した架空の写真です。

表紙の原寸画像を開く

AIの説明と、保存先の受付票を分けて確かめる

「保守へ変更する」という提案は、変更済みの記録ではありません。人がその案を承認した場合も、承認は頼んでよい範囲を示すもので、操作が成功した証拠にはなりません。ツールが要求を受け付けた後も、保存先の状態を確認する段階が残ります。

この違いを一つの「完了」欄へまとめると、提案しかないのか、承認後に操作したのか、保存結果まで確かめたのかが読めなくなります。後から別の担当者が同じ仕事をたどれるように、それぞれの出来事と、その根拠になった記録を結びます。

読み直すのは、同じ返事ではなく保存先の対象記録

この記事の「再読」は、変更の要求とは別の読取として、対象システム側の受付票を確かめることです。どの票の、どの版（変更を頼んだ時点の内容）を読み、担当部門がどう記録されているかを確認します。AIの完了メッセージを読み返すだけでは、この確認はできません。

使う画面やAPI、変更が反映されるまでの条件、読取に必要な権限はシステム担当と決めます。本稿は、どの製品にも同じ記録機能や即時反映が備わると扱いません。記録を設計することと、実際の機能を設定・試験することも別の仕事です。

受付票Aは承認未確認、受付票Bは保存結果が未確認

二例は別の受付票です。Aを直した結果がBという関係ではありません。同じ「保守へ変更する」という提案でも、人の承認、操作の試み、受付応答、保存先の再読を順に見ると、今言えることが違います。

AIの提案と実際に保存された状態は、どこで分けて確かめるのでしょうか。図では、同じ項目に並ぶAとBの値と、まだ未確認の箇所を見てください。「承認あり」や「受付」から、保存成功へ飛ばして読まないことが要点です。

図のPC原寸画像を開く図のスマートフォン原寸画像を開く

Aは提案があるだけで、人の承認が確認できません。この原票では操作を実行していないため、変更の依頼を保留します。ただし、原票にない保存先の最終状態まで「変更なし」と補うことはしません。

Bは承認があり、操作を試みたという設定です。そこにある返り値は受付応答だけなので、まだ「保守へ保存された」とは言えません。次は保存先の対象票を読み直し、依頼した変更と一致するかを確かめる担当へ渡します。どちらの例にも、その再読結果はまだありません。

一件を追うために、操作ID・対象・版をつなぐ

同じ受付票には、後から別の変更が入ることもあります。受付票の番号だけ、あるいはAIとの会話だけを残すと、どの依頼に対する承認や応答だったかを取り違えます。一件の変更を追う識別子と、対象票・依頼時の版を対応させておく必要があります。

次の項目は、この仕事に合わせて決めるための設計案です。AとBの原票には操作ID・票番号・版・時刻・判断者名の実値はありません。この記事で新しい値を埋めて、実行記録を作ったことにはしません。

同じ操作を結ぶ手掛かり

操作IDと、対象票の識別子・依頼時の版を結びます。提案、承認、受付応答、再読結果から同じ対象へ戻れるようにします。

提案と、人の判断

変えたい項目と変更案、その案を確認した人、承認した範囲、判断時刻と対象版を残します。承認があっても、別の票や新しい版への変更まで許可されたとは扱いません。

操作の試みと、受付応答

実行主体、試みた操作、受付応答とその時刻を残します。元の返り値を参照できるようにしつつ、機密を含む引数や本文を無制限に複写しません。

保存先から読み直した結果

読んだ対象と版、確認時刻、保存先の値、期待した変更と一致したかを残します。読めなかった理由や、まだ確認していないことも区別します。

次の確認を受け持つ人

不足した確認、確認する担当、引き継いだ時点を残します。保存先の状態が読めない場合に、誰が調べるかを空欄のままにしません。

操作の後に保存先を読み直し、判断を更新する

Bで次に必要なのは、受付応答をもう一度眺めることではなく、依頼した対象票の現在の記録を確かめることです。対象と版が合っているか、期待した変更を照合できるかを読みます。どこまでを保存確認とするかは、業務責任者とシステム担当で決めてください。

期待した変更が読めた場合も、確認した範囲を書く

今後、正しい対象と版を読み、担当部門が期待した値と一致すると確認できた場合は、その読取結果と確認時刻を残します。「その時点のその記録を確認した」という範囲です。関連する顧客連絡や、修理作業全体まで終わったという意味には広げません。この架空のBには、その確認結果はまだありません。

違う値・違う版・読めない状態なら、確認待ちを残す

読んだ対象が違う、依頼した版と対応しない、期待した値が見つからない場合は、何を確認できなかったかを残します。直ちに保存失敗や原因を断定せず、同じ操作の記録と対象票をシステム担当へ渡します。記録を読めない状態も、保存されていないという結果にはしません。

確認前に同じ変更を重ねるのではなく、次の操作を担当者と決めます。時間切れが起きた場合の具体的な照合・再開判断は、受付の時間切れと二重登録を分けて確かめる方法で扱っています。時間切れのときは関連稿の照合手順を確認し、通常の運用では一件ごとの記録を残して、後から同じ操作をたどれる状態にします。

残す情報と、閲覧・保存の条件を先に決める

調べ直せるようにするためでも、顧客情報や認証情報、会話全文を何でも記録へ貼り付ける必要はありません。対象をたどる識別子、必要な変更内容の要約、権限を持つ人だけが参照できる元記録への対応など、目的に必要な範囲を決めます。

OWASPの「Data to exclude」も、認証用の秘密や機微情報の扱いを分ける参考になります。記録を読む人の権限、変更・削除が分かる仕組み、保存する期間は、業務と社内の条件に合わせて記録管理の担当と決めます。この記事から一律の保存年数や監査適合を認定しません。

誰が判断し、誰へ連絡するかを明確にする考え方には、NIST AI RMF CoreのGOVERN 2.1も参考になります。参照ページは1.0（2023）の内容で、改訂中と表示されています。任意のリスク管理枠組みであり、日本の法的義務や、この例の必須欄数を決めるものではありません。（公式資料は2026年10月21日確認。）

「どこまで確認できたか」を、担当者へ渡す

業務責任者には、どの変更案・対象・版について承認を確認するかを渡します。システム担当には、操作の試みと受付応答、保存先を読んだか、どの値がまだ不明かを渡します。記録管理の担当には、誰が閲覧でき、何をどこへいつまで残すかを相談します。これらは役割の分け方の案で、A/Bで実際の担当者が決まった記録ではありません。

Aの引継ぎなら「承認が未確認で、この操作は未実行。承認範囲を確認するまで変更を保留」と言えます。Bなら「承認と操作の試みはある設定だが、受付応答のみ。保存先の再読と最終状態は未確認。対象票と操作記録をシステム担当へ渡す」と分けます。「AIが処理済みと言った」だけで次の担当者へ渡すより、何を調べるかが具体的になります。

利用できる資料やAIの条件は社内利用ガイドライン、月ごとの利用と仕事の成果はAI導入のKPI、利用料と停止設定・請求は費用が想定を超えたときの確認で扱う別の判断です。今回の操作記録がそろっても、それらの条件や成果まで確認済みにはなりません。

まとめ：提案・承認・受付・保存を別々に残す

AIが受付票を変えたかを確かめるには、AIの提案、人の承認、操作の受付応答、保存先から読み直した結果を、同じ操作と対象の版につないで残します。承認だけ、受付応答だけで、保存済みや仕事全体の完了へ進めないことが要点です。

最初に行うことは、いま追いたい変更を一件選び、「承認した範囲」「操作を試みた記録」「保存先を読んだ結果」のどこまでが残っているかを担当者と確かめることです。空いている部分を推測で埋めず、確認する人と次の行動を決めてください。