AIエージェントの承認画面｜人が変更内容を確かめてから実行する
AIエージェントの承認画面は、差分・期限・再承認条件・実行時照合を一体で設計します。承認内容と実際の操作が一致するときだけ実行し、不一致なら更新後の差分を再承認へ戻します。
AIエージェントの承認画面で守るべき境界は、「人が確認した変更内容と、実行直前の内容が一致しているか」です。承認ボタンを押した事実だけに頼らず、承認対象の差分、承認の期限、変更後に再承認が必要となる条件、実行時の照合を一体で設計し、一致しない操作は実行しない状態にします。
ただし、画面に情報を増やせば安全になるわけではありません。実装責任者が先に決めるべきなのは、どの情報を「承認対象」として固定し、どの変化までなら同じ承認を使えるのかという境界です。
AIエージェントの承認画面は「差分への許可」を記録する
エージェントの提案文をそのまま表示して「承認」「却下」を並べても、承認者は実行される操作を特定できません。確認対象には、外部システムに渡される実行内容を置きます。画面には少なくとも、実行対象、操作、主要引数、影響範囲を、現在値と実行後の値の差分として示します。文章のもっともらしさは、この差分の代わりにはなりません。
たとえば顧客台帳を更新する操作なら、対象レコード、更新する項目、変更前後の値、連動して行われる操作まで承認対象に含めます。エージェントの説明文だけでは足りません。外部への連絡なら、宛先、送信内容、添付対象、送信に使う主体が確認対象です。一つの承認対象を基に、画面表示と実行時照合に必要な表現をそれぞれ作れば、表示用の要約と実行用データのずれを防げます。
2026年9月21日時点で、Google Cloudのエージェント設計パターンは、あらかじめ定めたチェックポイントでエージェントを停止し、外部システムを呼び出して人のレビューを待ち、承認・訂正・追加入力を受けてから処理を続けるhuman-in-the-loopパターンを説明しています。また、OWASPのTransaction Authorization Cheat Sheetは、取引上の重要なデータを利用者が識別・確認できることと、そのデータを承認過程で検証する原則を示しています。
この一般原則を実装へ落とすと、承認によって許可される範囲は、画面に表示された特定の操作です。エージェントに自由な実行権を渡す設計では、承認後に対象や引数を組み替えられ、画面で確認した意味が失われます。
承認判断表で実行条件を固定する
次の判断表は、上記の一般原則を基にした実務上の提案であり、原典所定の分類や義務ではありません。各操作について「誰に見せるか」だけでなく、「何が変われば承認を取り直すか」「実行時に何を比べるか」まで同じ行で決めます。
| 承認対象の差分 | 承認者と権限 | 有効期限 | 再承認条件 | 実行時照合 | 不一致時の動作 |
|---|---|---|---|---|---|
| 顧客台帳の対象レコード、更新項目、変更前後の値、連動操作 | 対象業務の変更権限を持つ担当者 | 業務側が定めた期限まで | 対象、更新項目、更新後の値、連動操作の変更 | 承認IDに結び付く対象と更新内容、期限、未使用状態 | 実行を止め、更新後の差分で再承認 |
| 外部連絡の宛先、本文、添付対象、送信主体 | 外部送信を許可できる担当者 | 承認時に確定した期限まで | 宛先、本文、添付対象、送信主体の変更 | 承認済みの送信内容と実行要求、期限、未使用状態 | 送信せず、新しい承認対象として登録 |
| 業務状態の遷移元、遷移先、対象、後続操作 | 状態変更を許可できる担当者 | 対象の状態が変わらず、期限内である間 | 現在状態、遷移先、対象、後続操作の変更 | 実行直前の現在状態と承認済み遷移、期限、未使用状態 | 状態遷移を行わず、最新状態から再生成 |
列を埋める順番も重要です。最初に「承認対象の差分」を固定し、次にその差分を判断できる承認者を割り当てます。その後、有効期限と再承認条件を決め、最後に同じ対象を機械的に照合できる形へ落とします。実行時照合に使えない説明だけが残る場合は、承認対象の定義がまだ曖昧です。
2026年9月21日時点で、NIST AI RMF Coreは、AIリスク管理に関する役割・責任・連絡経路を明確にし、人間とAIの構成および監督に関する役割と責任を定義して区別する方針・手順を示しています。この原則から、共通画面で誰にでも承認を許すのではなく、操作を判断する責任と権限を承認者に結び付ける必要があると判断できます。
期限切れと変更失効を同じ「未実行」として扱わない
承認レコードは、未承認、承認済み、期限切れ、変更失効、実行済みを区別します。これも出典の一般原則を基にした実務上の提案であり、原典所定の分類や義務ではありません。状態を分ける目的は、承認済みという一語だけを見て古い許可を再利用する事故を防ぐことです。表示を整理するだけで終わらせず、各状態で実行できるかを制御します。
期限切れは、承認対象が同じでも利用できる期間を過ぎた状態です。変更失効は、期限内であっても承認対象が変わった状態です。どちらも既存の承認では実行できませんが、理由を分けて残せば、何を再確認すべきかが明確になります。更新された差分を提示し、新しい承認IDで承認過程へ戻します。
OWASPは2026年9月21日時点で、承認中に取引データが変更された場合に、以前の承認データとchallengeを無効にするか、承認過程をリセットする方法を挙げています。また、承認資格情報をchallenge生成から承認完了までの限定された時間だけ有効にし、各操作ごとに一意にする原則も示しています。したがって、承認済みレコードの内容を書き換えて同じ承認を残す設計や、別の操作に承認を転用する設計は避けます。
再承認条件には、画面で見えた重要な差分をそのまま置きます。文面の体裁のように承認対象外と決めた変化まで無条件に失効させる必要はありません。一方、対象、操作、主要引数、影響範囲のいずれかが変わるなら、「少しの変更」として通さず、承認者が変更後の内容を見直せる状態へ戻します。
実行直前に承認内容と照合する
承認画面を整えても、実行経路が承認レコードを参照しなければ制御にはなりません。承認後から実行までの間に対象データが変わることや、別の要求が同じ承認IDを使おうとすることを前提に、最終ゲートをサーバー側へ置きます。
実行直前の処理は、出典の一般原則を基にした次の実務提案であり、原典所定の手順や義務ではありません。
- 実行時点の対象、操作、主要引数、影響範囲から、実行予定内容を再構成する。
- 承認IDに結び付けて保存した正規化済み内容、またはそのダイジェストと照合する。
- 承認レコードが承認済みで、期限内かつ未使用であることを確かめる。
- すべて一致した場合だけ実行し、承認レコードを実行済みにする。
- 一つでも不一致なら実行せず、新しい承認対象として差分を作り直す。
この手順の照合対象は、実行を特定できる正規化済み内容です。画面の表示文言そのものを比べる方法では、表記の違いに判定が左右されます。同じ意味のデータが並び順や表記だけで不一致にならないよう、正規化の規則も承認対象の設計と同時に固定します。ただし、正規化によって宛先や操作の違いまで消してはいけません。何を同一と見なすかは、判断表の再承認条件と矛盾させないことが必要です。
OWASPは2026年9月21日時点で、取引実行の直前に、その取引が利用者により適切に承認済みかを検証する、実行に結び付いた最終制御ゲートを置くことを示しています。変更時の承認失効、限定された有効期間、操作ごとの一意性と合わせれば、承認時だけでなく実行時にも同じ境界を検査する設計になります。
画面、台帳、実行ゲートを一つの仕様としてレビューする
実装レビューでは、承認画面の見た目、承認レコード、実行APIを別々に確認しません。画面に表示した差分が台帳に固定され、その同じ内容が実行直前に照合されるかを一本の流れとして追います。
- 画面には、判断表で定義した実行対象、操作、主要引数、影響範囲が差分で表示されるか。
- 承認者の役割と権限が、対象操作を判断する責任に結び付いているか。
- 承認レコードは期限切れ、変更失効、実行済みを区別し、操作ごとに一意か。
- 承認後に対象データが変わった場合、更新後の差分で再承認へ戻るか。
- 実行経路のすべてが最終ゲートを通り、不一致時に外部操作を行わないか。
この確認で一つでも答えられない項目があれば、承認ボタンを追加する前に判断表へ戻ります。AI導入全体の進め方を整理する場合はAI導入の進め方ガイド、検証段階から本番運用へ移す条件を整理する場合はAI PoCを本番運用につなげる進め方も合わせて確認できます。
AIエージェントの承認画面は、承認対象の差分を固定し、期限切れと内容変更で既存承認を失効させ、実行直前に同じ内容かを照合する境界です。人が一度介在したという記録だけでは、この役割を果たせません。自社で実行を許す条件は、判断表の各行について「表示した差分と実行予定内容が一致し、承認が期限内・未使用である」と言えるところまで具体化します。条件を満たせない操作は実行せず、更新後の差分を示して再承認へ戻すのが実装上の結論です。
FDE・AI実装ガイドへ戻る