承認した後に条件が変わったら。AI業務の対象版・有効期限・実行時権限を照合する

編集部の実務提案

承認済みなのに、承認した内容ではない

AIが作った資料を確認し、送ってよいと承認した。ところが、送信待ちの間に添付が差し替わり、宛先も更新された。画面には承認済みと出ているが、人が見た内容と実際に送る内容が同じかは分からない。承認者と時刻だけの記録では、この違いを説明できない。長く待つジョブほど、実行までの間に条件が変わる可能性を扱う必要がある。

ここで保存したいのは、承認した時点の状態である。操作、対象、資料の版、実行先、金額など、判断に関わった条件の組合せを残す。後からその状態を読み、今回の実行が同じ範囲にあるかを照合する。単にボタンを押したという履歴より、何を認めたかが分かる記録を目指す。

本稿は承認を増やすための記事ではない。既に認められた範囲で進められる仕事と、条件が変わって別の判断が必要な仕事を分ける。毎回最初から同じ説明を求める運用では、確認が形骸化しやすい。変わった部分と変わっていない部分を示し、必要な判断だけを具体的に残す。

以下の対象版、期限、状態遷移、架空ケース、試験例は編集部の設計提案である。すべての業務に共通する有効時間や承認人数を決めるものではない。対外送信、データ変更、公開など、自社が扱う操作の影響に合わせて方針を決める。既存の契約や権限を、この表だけで変更してよいと解釈しない。

編集部の実務提案

認可の一次情報と、人の承認の役割を分ける

OWASPは、原則として拒否する設計と、すべてのリクエストで正しく権限を検証することを推奨している[1]。これは、以前に一度通った操作なら以後も無条件に許可する、という考え方とは異なる。承認履歴があっても、現在その対象へその操作を行えるかは確認する必要がある。

GitHubの環境保護にはrequired reviewersや自己承認を防ぐ設定があり、候補のうち一人の承認で進行できる仕組みや、利用条件が説明されている[2]。複数人を候補へ入れたことを、全員の賛成が必要な状態と読み違えない。実際に使う設定と、社内が求める判断の条件を照合する。

この二つの資料から、一般のAI業務に承認の版固定や有効期限が自動で備わるとは言えない。認可は、その主体が今その操作を行えるかという確認であり、人の承認は、特定の内容を実行してよいという判断を記録する。一つの仕組みに見えても、答える問いが違う。

実装では、承認が有効であること、対象が一致すること、現在の実行権限があることを別の条件として扱う。どれか一つが揃っただけで残りを省略しない。一方、すべてが揃い内容も変わっていないなら、同じ質問を人へ繰り返す必要があるかを方針で考える。技術上の再確認と、人へ新しく判断を求めることを区別する。

公式機能へ依存する部分には、原典、確認日、実際の設定を残す。社内の承認方針には、決定者と適用範囲を残す。外部の機能が変わったときと、業務の条件が変わったときで、見直す場所を分けられる。機能名だけで自社の承認契約を説明したことにしない。

編集部の実務提案

手順1：承認対象を、操作と条件の組合せにする

最初に、何を承認したかを一つの表示へまとめる。操作の種類、対象の識別子、実行先、関係する資料の版、重要なパラメータを含める。メールの例なら本文だけでなく、宛先や添付のどの版まで確認したかが問題になる。資料の表示名が同じでも、内容が変わるなら同じ対象として扱わない。

金額や件数の上限を条件にする場合は、その範囲と単位を残す。特定の一件を認めたのか、一定の範囲で複数回の処理を認めたのかも区別する。単一の承認済みフラグに押し込めると、回数や対象の境界が見えない。どこまでなら同じ判断で進められるかを、業務の責任者と決める。

対象が他システムのデータなら、そのシステムの識別子や版を使えるか確認する。ファイル名だけ、画面のタイトルだけに依存すると、同じ名前の別内容を読み違えやすい。取得した時点と、その後変更されたかを確認する方法を分ける。提供元に版の情報がない場合は、その限界を前提として設計する。

承認者には、実行後の影響が分かる表示を用意する。専門的な識別子だけを並べるのではなく、誰へ何が起きるかを読めるようにする。内部では正確な識別を保ち、画面では人が理解できる説明へ結びつける。表示の説明と実行パラメータが別々に更新されないことも確認したい。

承認対象を固定した後は、元の依頼と切り離さない。依頼者、目的、担当、対象の状態がどこから来たかを追えるようにする。個人情報や秘密をすべて承認画面へコピーする必要はない。判断に必要な情報と、後で照合するための識別情報を選び、閲覧できる相手を限定する。

編集部の実務提案

手順2：人が見た版と、機械が照合する版をそろえる

人がプレビューを見て承認した後に、裏側で最新のデータを取り直すと、別の内容が実行される可能性がある。承認した版を実行へ渡すか、実行時に同じ版であることを照合する設計が必要だ。プレビューのURLが変わっていないことだけで、内容が変わっていないと見なさない。

ハッシュを使う場合も、何を計算の対象に含めたかを定義する。本文だけを含め、宛先や添付を含めなければ、本文が同じまま送信条件が変わることを見落とす。並べ替えや文字表記を揃える処理も、意味を変えない範囲で決める。計算値が一致したことと、人が必要な項目を確認したことは別の条件である。

人向けの表示には、承認対象の版を見分ける短い識別を付ける方法がある。どの版を開いているかが分かれば、更新後の画面を以前のものと取り違えにくい。重要な変更があった場合は、古い状態と新しい状態の差分を示す。毎回全文を読み直す負担だけを増やすのでなく、判断が変わり得る点を見つけられるようにする。

VERSAROCへ相談する際は、プレビュー、承認、実行がどのシステムに分かれているかを整理するとよい。いま人が何を見ており、実行側がどこから値を取得するかが分かれば、版の対応が切れる箇所を確認できる。承認ボタンの追加だけでなく、表示と実行条件が一致するまでを実装範囲に含めたい。

変更履歴は、古い版を無制限に誰でも見られる状態にする意味ではない。保持する目的と範囲、機密情報の扱いは別に設計する。必要な担当者が、承認した対象と実行した対象の一致を確認できる状態を目指す。記録量を増やすことより、何を照合できるかが明確であることが重要だ。

編集部の実務提案

手順3：承認時の役割と、現在の権限を分ける

承認した時点では担当者だった人が、実行時には担当を外れていることがある。履歴には当時の役割を残し、現在の権限は実行時の正規情報で確認する。過去に承認できたという事実だけを、今もその対象へ操作できる証拠にしない。組織変更や担当交代がある業務では、この二つがずれる可能性を扱う。

人が承認する権限と、実際に処理を実行するサービスの権限も分ける。承認者が正しくても、実行先の環境や資格情報が別の対象へ向いている場合、操作の条件は一致していない。どのtenant、どの環境、どの資源へ作用するかを照合する。表示名が似ている本番と検証環境を同じものとして扱わない。

権限情報が確認できないときは、以前の結果を無条件に再利用して許可する設計にしない。業務上、どこまで待つか、どこで停止し、誰が確認するかを決める。確認できないことと、権限がないと確定したことは状態として区別できるが、いずれも確認なしの実行へ自動的に進める理由にはならない。

一方、現在も正当な権限があり、承認対象と有効期間も変わっていない場合に、毎回人へ同じ承認を求めるかは方針次第である。技術上の認可を再確認した記録と、人が新しく判断した記録を分ける。これにより、必要な権限確認を保ちながら、変更のない仕事の無用な往復を減らせる。

権限変更の試験では、承認前、承認後、実行直前、再開時という時点を分ける。どの時点の情報を使っているかを確認し、古い画面を開いたままでも実行側が現在の条件を見ているかを見る。画面のボタンを隠すことだけで、実行APIの制御を確認したことにしない。

編集部の実務提案

手順4：有効期間と、実行の開始条件を決める

承認に有効期間を置く場合は、いつからいつ未満か、どの時点で判定するかを決める。受付した時刻、キューへ入った時刻、外部へ実行する直前の時刻は違う。待ち行列へ期限内に入ったから、何日後でも実行してよいとは限らない。承認の目的に合う判定点を業務側と合意する。

短い期限なら安全、長い期限なら危険という単純な設定にはしない。変わりやすい対象と、長期に固定される対象では必要な条件が違う。有効期間に加えて、対象版や上限、実行先の一致を確認する。期限内でも意味が変わっていれば同じ承認で進められない場合があり、期限だけでは内容の一致を保証できない。

時刻は、実行側の基準とタイムゾーンを統一して記録する。利用者の端末時計だけへ依存すると、時計の違いで判定が変わる可能性がある。期限ちょうどの扱いも明示し、画面の丸めた表示と実際の判定精度が食い違わないようにする。人が読める時刻と、内部の正確な値を対応させる。

期限切れの表示では、何が失効したかを説明する。対象の内容が変わったのか、時間条件だけが切れたのか、現在の権限も確認できないのかを分ける。次に必要な行動が、同じ内容の確認、差分の判断、担当者の変更のどれかで変わる。単なるエラー表示だけで、利用者へ何度もボタンを押させない。

方針を後から変更する場合は、既に承認済みの仕事へどの規則を適用するかを決める。過去の承認の期限を、設定値の更新だけで延ばす運用にしない。新しい方針へ移行するなら、対象と判断者、適用時点を残す。承認の履歴と、現在の設定の履歴が結びついていることが重要だ。

編集部の実務提案

手順5：変更を、再確認が必要な意味で分類する

すべての更新を一律に承認やり直しへすると、軽微な表示修正でも業務が止まりやすい。逆に、更新をすべて許せば別内容が実行される。操作の意味へ影響する項目と、表示だけの項目を方針で分ける。ただし、表示だけと呼ぶ変更が人の判断へ影響していないかも確認したい。

宛先、実行先、金額、件数、対象資料の版は、判断の範囲を変え得る代表例である。どの変更なら同じ範囲かは、業務で定めた条件による。上限内なら自由とする場合も、上限の単位や対象が一致している必要がある。単に数字が小さくなったから無条件に同じ承認でよい、と一般化しない。

変更の前後は、人が意味を読める形で表示する。長い技術的な差分だけでなく、受取人が増えた、対象期間が変わった、添付が新版になったという要約を出す方法がある。ただし要約だけが古いまま残らないよう、実際のパラメータと同じ版から作る。要約と元の確認内容へ戻れる導線を持つ。

影響が判定できない変更は、勝手に軽微と分類しない。停止して確認する条件、担当者、説明に必要な情報を決める。すべてをAIの自信の数字だけで通す設計ではなく、何が同じなら実行範囲内かという明示的な条件を持つ。未確認の変更を、人が承認済みという旗の下へ隠さない。

編集部の実務提案

手順6：照合してから実行する間の変更も扱う

実行直前に版を確認しても、その後に別の処理が対象を更新する可能性がある。確認と更新が別々の操作なら、その間の変更をどう扱うかが問題になる。内部の状態では、期待する版や状態に一致する場合だけ実行権を確保する、という条件付きの遷移を検討する。読んだ後で無条件に書く流れへしない。

実行権を確保した記録と、実際の外部操作の結果は別に残す。内部で一度だけ確保できても、外部サービスまで同じ意味の原子性があるとは限らない。相手のAPIが条件付き更新や重複識別に対応するなら、その仕様を確認して使う。対応していない部分は、結果照合や手動確認が必要な境界として残す。

複数の担当者やジョブが同時に実行しようとする場合も、同じ承認を無制限に消費できる状態へしない。一回限りの操作なら、その利用状態を共有の台帳で制御する。範囲内で繰り返す操作なら、残りの回数や範囲を同じ判断へ含める。個別のプロセスの記憶だけでは、別の実行者との競合を説明しにくい。

処理が中断したときは、どこまで確保され、どこから結果が不明かを残す。実行中の印が消えないからと、元の記録を削除して再開しない。調査と再開の手順を定め、外部の結果を確認できる識別子を保持する。内部状態を直せたことと、外部で何も起きていないことを同じ確認にしない。

編集部の実務提案

手順7：長いジョブは、外部へ作用する段階を区切る

長いAI業務では、資料の取得、分析、下書き、承認、送信が別の時刻に進むことがある。分析を始めてよいことと、後日その結果を外へ送ってよいことは同じ条件とは限らない。どの段階で外部へ作用するかを整理し、その直前に必要な条件を確認する。待ち時間の長さだけでなく、操作の意味で区切る。

途中まで作った下書きを保持することは、次の送信まで承認済みだという意味ではない。入力資料が変わった場合、分析をやり直す必要があるか、説明を更新すればよいかを別に判断する。完成した文章が同じでも、参照した資料や対象が違えば、業務上の前提が変わる場合がある。結果と根拠の版をつなぐ。

再開では、保存した状態を読み、現在の権限、対象、有効条件を照合する。内容が変わっていなければ同じ範囲で進める設計もできるが、未確認の部分を過去の承認で埋めない。確認を何度したかより、何をどの時点で確認したかを残す。処理の進捗と、実行できる範囲を別に見せる。

利用者への通知では、「作成済み」「実行待ち」「再確認が必要」「結果照合中」を分けると次の行動が分かりやすい。すべてを処理中という表示へまとめると、待つべきか、判断すべきか、再送を避けるべきかが伝わらない。状態名は内部の実装用語そのままではなく、業務上何ができるかに合わせて説明する。

編集部の実務提案

架空ケースA：宛先が増えた承認済みメール

Aさんは顧客へ送る資料を確認し、一つの送信を承認した。送信待ちの間に、担当者が宛先へ別の組織を加えたとする。本文が同じでも、情報を渡す範囲は変わっている。本文の版だけを照合する実装では、この変化を見落とす。承認時に人が見た宛先と、実行パラメータの宛先を対応させる必要がある。

このケースでは、変更が元の承認範囲に含まれるかを方針で確認し、含まれないなら差分を示して判断へ戻す。以前の承認をそのまま新しい送信へ移さない。添付も更新されたなら、宛先の変更だけを要約して終わらせず、関係する資料の版も示す。何が変わったかを一つの確認対象として読めるようにする。

再確認後の実行では、新しく判断された対象と一致することを照合する。古いブラウザの画面から操作した場合や、別の担当者が同時に変更した場合も試験したい。正しい画面を一度開けたことだけで、実行の対象が固定された証拠にはならない。画面の版と実行の版をつなぐ。

送信済みか分からない時点で変更が起きた場合は、まず結果を照合する。新しい宛先で承認し直したことを、元の送信がなかった証拠にしない。新旧のどちらが実行されたか不明なまま追加送信を作ると、情報共有の範囲と回数の両方が読めなくなる。承認の判断と配送の事実を別に確認する。

編集部の実務提案

架空ケースB：担当を外れた人の承認が残っている

Bさんが承認した後、担当者が交代し、Bさんの当該操作の権限が失効したとする。台帳の承認履歴は事実として残るが、実行時に誰のどの権限で進むかを確認する必要がある。過去の履歴を消すことと、現在の実行を止めることは違う。履歴の保全と現在の認可を両立させる。

担当交代の手順には、待機中の仕事の確認を入れる。承認済み、実行中、結果不明、再確認待ちを分け、新しい担当者がどこから関わるかを明示する。担当名だけを置き換えると、誰が何を判断したかが失われる。過去の判断者と、これから確認する担当者を別に残す。

必要な再確認が完了するまで、進捗のために古い資格情報へ戻して実行しない。現在の正規の権限情報で対象を確認する。確認先が一時的に利用できないなら、その状態を記録し、業務が決めた待機や連絡の手順へ進む。権限の不確かさを、画面上の承認済みという表示で上書きしない。

VERSAROCへの相談では、担当者台帳、承認履歴、実行サービスの権限がどこで管理されているかを整理したい。組織変更のたびに手作業で追っている場合、待機中ジョブの一覧や再確認の導線を含めて設計できる。既存の記録を保持し、誰がどの段階を担当するかが追える仕組みを対象にする。

編集部の実務提案

架空ケースC：数日待ったジョブの資料が新版になった

Cさんはある資料を基にした処理を承認し、ジョブが数日待機した。その間に元資料が新版になった場合、最新を使うことが常に望ましいとは限らない。承認したのは旧版の内容だった可能性がある。一方、旧版で実行しては業務の目的を満たさない場合もあるため、どの版を使うべきかを方針として確認する。

実行時に最新資料を無条件に取り直す設計では、承認時の前提とずれることがある。版を固定して進める、変更を検知して止める、影響を確認して新しい依頼へする、といった選択を明示する。利用者へは、古い版の承認があることと、現在の資料で実行できることを別の状態として見せる。

同じ文章が出力されたとしても、入力の版が変わった事実は残す。AIの結果が似ているから前提の変更を無視してよいとは限らない。どの根拠で作った結果かを後で説明する必要がある業務では、参照した資料と結果を結びつける。出力のハッシュだけで承認範囲を定義しない。

このケースの試験では、承認後に元資料だけを更新し、期待した停止や再確認へ進むかを見る。さらに、処理中に更新された場合も、どの版を採用したかが混ざらないことを確認する。資料名を変えず中身だけ変える例も用意すると、表示名への依存が見つけやすい。変更を見つけた記録と、新たな判断を別に残す。

編集部の実務提案

結果不明は、承認の取り直しで解決しない

実行を依頼した後、応答が失われた場合、承認が残っているかどうかだけでは再送を決められない。相手側で操作が完了している可能性がある。内部の失敗表示を、外部で何も起きていない証拠にしない。元の操作識別子と外部参照を使い、結果を照合する段階へ移す。

人が再度承認したことも、元の結果を確定するものではない。新しい判断が認める範囲と、既に起きた事実は別である。一回限りの送信や変更なら、結果が確認できるまで同じ副作用を追加しない方針を検討する。確認できない場合の手動対応や連絡先を、実装と一緒に決める。

台帳には、承認対象、実行権の確保、外部依頼、確認できた結果を分ける。失敗として再開する場合も、どこで失敗したかを示す。実行前の検証失敗なら副作用はまだない可能性があるが、外部へ出した後の通信失敗では判断が違う。単一のエラーへまとめない。

利用者の画面では、再送ボタンを押せる状態と、照合を待つ状態を区別する。待つ理由と確認先が分かれば、焦って別の依頼を作る行動を減らす設計につながる。ただし、問い合わせや操作を完全に減らせると保証するものではない。未確認を正確に伝え、担当者が次の確認を進められる状態を作る。

編集部の実務提案

受入試験は、承認後の変更を一つずつ入れる

通常の承認から実行までが通る試験に加え、宛先だけ、資料版だけ、金額だけ、権限だけ、時刻だけを変える試験を用意する。複数条件を同時に変える前に、それぞれの判定が正しいかを見る。どの変更で進み、どの変更で停止し、何を人へ示すかを期待結果へ含める。

同じ承認へ二つの実行者が同時に来る場合、古い画面から操作する場合、実行権を確保した直後に処理が落ちる場合も確認する。内部で一度だけ進めたことと、外部で副作用が一度だけだったことを別に確かめる。外部まで確認できない部分があるなら、その範囲を未検証として報告する。

有効期限の直前、ちょうど、直後も試す。表示を分単位に丸めても、内部では秒や端数で判定する場合があるため、境界を共有する。時計の条件を変更した試験で、対象版や実行先まで勝手に変わっていないかも見る。正しく停止したとき、利用者へ理由と次の行動が伝わることを確認したい。

試験データは架空の宛先や資料で構成できる。本番の秘密や機密文書をコピーする必要はない。承認の意味を検証する例と、実際の連携先で必要な確認は分け、許可された範囲で行う。合格の報告では、通った条件、保留した条件、運用で確認する境界を明示する。

編集部の実務提案

運用へ渡すのは、停止理由と次の確認先

運用担当者には、状態名だけでなく、止まった理由と次に何を確認するかを渡す。期限切れ、対象変更、権限確認不能、結果不明では、再開の手順が違う。すべてを管理者へ連絡という一文へまとめると、判断の責任と必要な情報が見えなくなる。誰がどの範囲を確認するかを具体化する。

承認方針を変更できる担当者と、個別の仕事を再開できる担当者も分けて考える。運用上の都合で全体の期限や条件を緩める前に、その変更が既存の承認へどう影響するかを確認する。個別の例外対応が必要なら、例外の対象と判断を記録する。全体設定を変えて一件だけ通す方法では、影響範囲が広がりやすい。

VERSAROCへ実装を相談する場合は、依頼、プレビュー、承認、待機、実行、結果照合の流れを一枚にまとめるとよい。現在どこが手作業で、どこに版や権限の対応がないかを整理する。既存の履歴を保持し、必要な段階から接続する範囲を決める。未確認の実績や完全な安全性を約束する記事ではない。

成果物の確認には、画面の完成だけでなく、変更時に止まる理由が説明できること、変わっていない仕事が適切に進むこと、結果不明を照合できることを含める。承認を増やした数より、どの判断を人が残し、どこを仕組みへ任せられたかが分かる状態を目指す。運用へ渡せる設計は、その境界を言葉と記録で示せる。

編集部の実務提案

次の一歩は、承認後に一項目だけ変えてみること

最初の設計確認では、架空の依頼を一件作り、何を人が見て承認したかを保存する。その後、宛先や資料版など一項目だけを変え、実行側が違いを見つけるかを確かめる。画面に承認済みと残っていても、範囲外の変更を正しく扱えるかを見る。正規の実行を行う前に、小さな例で意味を共有する。

次に、内容を変えずに権限や時刻を変え、別の理由で止まる条件を確認する。最後に、外部操作後の応答不明や同時実行を加える。すべてを一度に作り込むより、対象の一致、現在の権限、実行結果という三つの境界を順に確認する方が、どこを修正すべきかが見えやすい。

承認は、過去に人が判断した重要な記録である。その価値を保つには、別の内容へ使い回さず、当時の状態を現在の操作へ結びつける必要がある。現在の認可も、過去の承認も、どちらか一方で代わりにしない。変更のない範囲を進め、変更した範囲を適切な判断へ戻す仕組みにする。