承認 UX for High-impact AI Actions

影響の大きなAI操作の承認画面は、AIの提案を人が読み、実行対象・範囲・結果を理解したうえで、特定の操作だけを許可または拒否する入口である。単に「実行しますか」と表示するだけでは、何を承認したかを特定できない。承認対象、承認者の権限、実際に実行した内容を結び付ける必要がある。以下の画面・状態設計は本稿の提案であり、特定製品が一式を保証するという意味ではない。

例として、エージェントが共有フォルダの文書を社外へ送る場面を考える。承認者が知るべきなのは、モデルの長い思考説明ではなく、送信先、実ファイル、情報区分、送信主体、利用目的、送信後に取り消せる範囲である。要約だけが正しくても、実際の宛先や添付が違えば承認は成立しない。人が判断する情報と実行引数を同じ操作定義から生成する。

件数が多い場合は、総数と重要な差分を先に示し、対象一覧を確認可能にする。一覧の一部を省略したまま全件を承認させない。不可逆な操作と可逆な操作、別の権限が必要な操作を一つの「すべて承認」にまとめるなら、その単位を業務上説明できる必要がある。

画面を開いた後に、金額、宛先、対象ファイル、権限、実行環境が変わる場合がある。承認時の操作定義を版またはハッシュで固定し、実行直前に一致を確認する。変更があれば差分を再提示し、再承認する。自然言語の「承認しました」という文字列を、後から生成し直した操作の包括的許可にしない。

承認者は提案を作った本人とは限らない。現在の認証、対象資源に対する承認権限、職務分離、代理承認の有効期限をサーバー側で確認する。承認画面を表示できることと、その操作を許可できることは別である。期限切れ、権限失効、すでに取消し・実行済みの操作への決定を受け付けない。

承認、拒否、修正依頼、保留を区別する。修正依頼は新しい操作候補へつなぎ、元の許可を引き継がない。保留は実行許可ではなく、期限到来時の既定動作を停止・取消し・引継ぎから決める。返信がないことを承認へ変換するなら、それは別の業務ルールとして明示的に設計すべきであり、承認UIの暗黙動作にしない。

人へのメール送信成功は、読了や承認の証拠ではない。推奨する状態は、提案保存、確認待ち、決定記録、実行許可の検証、実行中、結果確認、完了または取消しである。通知の配達状態を別に記録し、配達不能なら担当経路へ戻す。画面には現在状態を表示し、二重クリックや古いタブからの再送を同じ操作IDへ集約する。

AWS Step Functionsは、task tokenの返却を待つcallbackパターンを提供する。ただし対応する統合とStandard／Expressの違いがあり、待機できること自体は承認者の正当性や業務上の許可を証明しない。[S1] コールバックを受けたアプリ側で、操作ID、決定、主体、期限を照合する必要がある。通知URLを持っていることだけを、無制限の権限と扱わない。

LangGraphのinterruptは状態を保存して外部入力を待ち、再開時には該当ノードの先頭から処理が再実行される。資料は、interrupt前の副作用の冪等性や処理の分離を求めている。[S2] したがって「承認前に停止する関数を置いた」ことだけで、操作が一度だけ実行されるとは判断できない。

実利用の反証として、Issue #9106には並列interruptを含むsubgraphの再開で完了済みの処理が再実行されるという報告がある。[S3] 報告対象の構成・版に限定して読み、現行全版の欠陥とはしない。本稿の設計上は、承認の消費状態、実行の冪等性キー、外部結果の照合を持たせ、再開・再試行・プロセス再起動の境界を実使用版で試験する。

特に、外部APIの応答が途切れた場合は「失敗した」とは限らない。送信や発注が完了した後に応答だけ失われると、そのまま再実行して二重操作になる。実行結果を外部IDで照合し、成否不明の状態を区別する。承認を受け直すことだけでは二重実行は防げない。

すべての低影響操作へ同じ警告を出すと、承認が習慣的なクリックになる。操作の影響に応じて、事前に許可された範囲で自動実行するもの、要点を確認するもの、独立した承認者が必要なものを分類する。分類の根拠と上限は業務側で定め、AIが自分の提案を低リスクへ書き換えて承認を回避できないようにする。

拒否ボタンを隠す、承認を既定選択する、根拠のない確信度で判断を誘導する、といった設計は避ける。承認者が根拠文書へ移動でき、未確認点が読めることを優先する。画面の見やすさは必要だが、認可や操作照合の代替ではない。逆に、技術上のハッシュや内部エラーだけを画面へ並べても、人が影響を判断できなければ目的を果たさない。

検証には、画面表示後の対象変更、失効した権限、別テナント、期限切れ、拒否、二重クリック、再開・再試行、通知不能、外部成否不明を含める。人の判断については、代表的な誤操作や差分を発見できるかも確認する。承認率や処理速度だけを成功指標にしない。

承認者が誤る可能性は残る。人を挟むことは責任の移動だけではなく、対象を理解できる情報、判断権限、作業時間、実行を止める制御を用意して初めて意味を持つ。承認記録があっても、操作の適法性・妥当性や完全な安全を一括で保証しない。

• 対象業務、操作分類、承認者・代理権限、失効条件、外部APIの冪等性と復旧方法は未取得。
• 実UIの理解度・アクセシビリティ、通知、認可、再開、二重実行、結果照合の試験はNOT_RUN。
• 先行Luna完成本文は確認できず、旧所在調査のprovenanceを保持する新候補である。

「特定の操作と条件を人が確認し、その決定と実行内容を照合する承認経路を設計する」。一方、「人が押せば安全」「通知したので承認済み」「一度承認すれば変更後も許可」「interruptがあるので副作用は一度だけ」とはしない。

2026-10-22に一次資料を確認。画面項目・状態・試験案は本稿の設計提案。

• [S1] AWS Step Functions Integration Patterns, Wait for Callback: https://docs.aws.amazon.com/step-functions/latest/dg/connect-to-resource.html （待機パターンとworkflow種別の境界）
• [S2] LangGraph Interrupts, Rules／Side effects: https://docs.langchain.com/oss/python/langgraph/interrupts （停止・再開と副作用）
• [S3] langchain-ai/langgraph Issue #9106: https://github.com/langchain-ai/langgraph/issues/9106 （2026-09-29の並列再開の報告。修正・適用版は別途照合）
• 歴史的所在記録: Doc 1Vd0BP7G2UyPDRQs_-8dPvTgQ78Tk6kcVGuMJjqNdr84、tab=t.0:21984–23383、ARTIFACT_INDEX!260。所在地の記録を完成記事の代替にしていない。