目次
記事の公開、顧客へのメール送信、古いデータの削除。AIエージェントが実行できる仕事が増えると、「人が承認するから大丈夫」という説明を見かけます。ですが、その承認は、どの内容とどの操作に対するものなのでしょうか。
情報確認日：2026年10月15日。本記事はOWASPのAIエージェントと取引認可の資料を参考にした設計解説です。新しい侵害事件を報告するものではありません。記事公開などへの適用例、記録項目、検証手順は本サイトからの提案です。
スポンサーリンク
接続の許可と、一回の実行の許可を分ける
サービスへ接続する同意は、使える機能の範囲を決めるものです。一方、「この文章をこのサイトへ今公開する」という承認は、一つの操作の内容に関係します。最初に接続を許可したことを、後から変化するすべての操作内容への承認と取り違えないようにします。
自動化を依頼する場合も、毎回必ず人がボタンを押す方式だけが選択肢ではありません。利用者が継続的な自動公開を明示的に許可したなら、その範囲をサーバーのルールへ落とし込みます。対象サイト、記事種別、件数、公開条件などが、許可の境界になります。
重要なのは、承認の頻度より、何を許可したかを後から説明できることです。人の都度確認と、事前に定めた自動実行の方針では、保存する根拠が違います。どちらも、モデルが自分で書いた「承認済み」という文章だけを実行の根拠にしません。
確認画面と実行時の内容がずれる問題
説明用に、AIが記事Aのプレビューを見せ、利用者が公開を承認する構成を考えます。承認後に本文やリンクが変更されても、最初の許可をそのまま使えるなら、確認した内容と公開した内容が違ってしまいます。
同じ問題は、宛先、金額、削除対象、添付資料にも起きます。「メール送信を許可した」だけでは、宛先や本文を自由に変更してよいとは限りません。確認時点と使用時点の間に変化がある問題は、実行するAIの賢さではなく、アプリの状態管理として考えます。
OWASPのTransaction Authorization資料は、確認対象のデータが途中で変えられる問題と、その場合に認可をやり直す考え方を扱っています。金融取引の資料ですが、以下ではその原則をWeb公開などの操作へ適用する方法を提案します。 根拠資料：OWASP：AI Agent Security Cheat Sheet。 根拠資料：OWASP：Transaction Authorization Cheat Sheet。
スポンサーリンク
承認する内容を、サーバー側で固定する
記事公開なら、投稿ID、本文、タイトル、出典リンク、カテゴリー、画像、公開日時を一つの確認対象として扱います。保存済みの版や内容のハッシュを承認記録に結び付け、実行直前に同じ状態かを再確認する構成が考えられます。
ハッシュは、内容の変化を検出するための道具です。それ自体が、承認者の正当性や公開内容の正確さを保証するわけではありません。サーバーが保存内容から計算し、利用者・操作・有効期限と結び付ける必要があります。AIが提示した値を無条件に信用しません。
また、どこまでを同一とみなすかも決めます。段落の空白だけの変更と、URLや宛先の変更は業務上の意味が違います。ただし、複雑な例外を増やすほど見落としやすくなるため、最初は変更があれば再確認する単純な規則から検証することを提案します。
実行直前の権限を、もう一度確認する
承認時に権限があっても、その後に担当者が外れたり、接続が停止されたりする場合があります。実行時には、対象がまだ存在するか、現在の利用者が操作できるか、公開方針が有効かを確認します。昔の承認記録だけで、現在の禁止を上書きしません。 根拠資料：OWASP：REST Security Cheat Sheet。
WordPressなら、投稿状態や現在の権限の変化にも注意します。下書きを公開する承認を得た後に、他の編集者が本文を変えた、投稿を非公開にしたといった場合です。承認した版を確認できなければ、別の内容を推測で公開するのでなく、停止して理由を返します。
事前に自動化の方針を許可する場合は、その方針の版も対象です。許可条件が狭くなった後に、古いキューへ積まれた仕事が古い条件で実行されないかを確認します。権限と作業内容の両方が、実行時の検査対象になります。
スポンサーリンク
再送と二重実行を分けて考える
通信が途切れると、クライアントには失敗と見えても、サーバー側で操作が完了していることがあります。そのまま同じ仕事を繰り返せば、記事の重複、メールの二重送信、料金処理の重複につながります。送信ボタンを無効にするだけでは、サーバーの二重実行は防げません。
本サイトでは、依頼ごとに一意の識別子を付け、同じ依頼と同じ内容の再送には元の結果を返す設計を提案します。同じ識別子で内容が変わったら拒否します。これは冪等性と呼ばれる性質を実現するための一つの方法です。
複数の処理が同時に来る場合も考えます。完了記録を確認してから実行するだけでは、双方が未実行と判断する可能性があります。データベースの一意制約や状態遷移を使い、実行を引き受けた処理を一つに決めることが必要です。単純なメモリー上の旗だけに依存しません。
承認には期限と、変更できない対象を持たせる
短い確認のための承認が、数日後の別の実行へ流用されないようにします。期限、対象、操作、引数、承認者を記録し、使用済みの許可を別の操作へ使わない設計にします。継続的な自動化の方針は、こうした一回限りの許可とは別に管理します。
期限の値は用途に合わせて決めます。急ぐ業務だからといって無期限にするのではなく、時間がたった場合に再取得する仕組みを用意します。失効後に古い画面を再送したとき、内容を作り直して勝手に実行しないことも確認します。
公開予約では、予約を登録したときと、実際に公開されるときに時間差があります。予約後の編集や取消をどこで扱うかを決めてください。すべての製品で同じ動作ではないため、CMSの予約処理と自作の承認処理の境界を、利用する環境で検証します。
確認画面は、実行の差分を読める形にする
「実行してよいですか」という文だけでは、利用者は判断できません。操作名、対象、外部へ出る情報、公開範囲、取り消せる部分を具体的に示します。まとめて実行する場合は件数と対象一覧を用意し、一部だけ除外できるかも業務に応じて検討します。
AIの説明だけでなく、保存済みの値を表示することを提案します。モデルが「Aへ送ります」と述べていても、実際の引数がBになっていれば確認の意味がありません。プレビュー表示と実行処理が、同じ保存データを参照していることが重要です。
承認疲れも考慮します。毎回似た警告を出すだけでは、詳細を読まずに進む運用になりがちです。低リスクの定型操作と、対象変更や権限拡大を伴う操作を分け、判断が必要な差分を明確にする方が、形式的なクリックの回数を増やすより有効です。
一括操作の途中で止まった場合を先に決める
十件の記事公開のうち六件で止まったとき、すべてを失敗と表示すると、再実行で重複を起こしやすくなります。本サイトでは、仕事全体のIDと各対象の結果を持ち、完了・拒否・未実行・結果不明を対象ごとに返す方法を提案します。利用者が承認した一覧と、その結果の一覧を対応させることが大切です。
すべてを一つのトランザクションで戻せるとは限りません。外部サービスが関わる場合、後から補正できる範囲と、取り消せない範囲を区別します。途中で止まった仕事を再開するときも、最初の方針と現在の権限を確認し、未実行の対象だけへ進みます。件数だけを見て、どれが公開されたかを推測する実装は避けます。
スポンサーリンク
確認対象の表示そのものを保護する
承認する文章が別のHTMLやスクリプトを実行してしまうなら、確認画面の信頼も損なわれます。本サイトでは、対象のプレビューを安全な表示経路で作り、承認ボタンの周囲へ外部文書が自由に操作部品を挿入できない構成を提案します。見せる内容と押せる操作を、アプリ側が制御します。
通知メールから承認画面へ進む場合も、リンクを開いただけで実行を確定しない設計が考えられます。リンクの自動確認や誤操作を含めて、何が実行の意思表示になるかを明確にします。個別の認証方式に沿った実装を選び、秘密付きURLの全文をアクセスログや問い合わせへ複製しない運用も確認してください。
停止・復旧・監査まで含めて設計する
処理を途中で止める場合、実行済みの操作と未実行の操作を区別します。すでに外部へ送ったメールや公開された内容は、完全に回収できるとは限りません。取り消せる操作でも、閲覧や複製までなかったことにできると説明しないでください。
記録には、依頼ID、承認根拠、対象の版、実行結果、外部サービスの結果IDなどを残します。本文や認証情報の全文を無条件に監査ログへ入れないことも必要です。事故時に、何を許可して何が起きたかを照合できる範囲を決めます。
- 承認後の本文・宛先変更で、古い許可が使えないこと。
- 同時に同じ依頼を送っても、実行が一度になること。
- 権限取消と期限切れを、実行直前に検知すること。
- 外部の成功応答を失っても、再読取で結果を確認できること。
- 停止した仕事を再開するとき、未実行の対象だけを扱うこと。
テストは検証用の投稿、架空の宛先、戻せる操作で行います。AIが正しい説明をしたかだけでなく、サーバーへ実際に保存された値と外部へ出た結果を確認してください。承認を具体的な内容と結び付けることが、AIへ仕事を任せるための実装上の土台になります。
スポンサーリンク
