AWS Quick の Smart Approvals: 必要なところに人の監督を

本記事は 2026 年 11 月 4 日 に公開された「Smart Approvals in AWS Quick: Human oversight where it matters」を翻訳したものです。

AI エージェントが担う仕事が増えるなかで、セキュリティリーダーは人による監督をどう保てばよいのでしょうか。エージェントが取れるアクションは権限で決まりますが、許可されたアクションでも人の判断が必要な場合があります。すべての手順で承認を求めるのが最も安全に思えるかもしれません。しかし、複数の手順からなるタスクでは、定型的なアクションでも確認を何度も求められることがあります。セキュリティ警告に関する研究では、警告が繰り返されると注意力や順守の度合いが下がることがあると示されています。求められるのは承認を増やすことではなく、人のレビューが必要な判断に注意力を残しておくことです。

AWS Quick の Smart Approvals は、既存の制御の範囲内で対象のアクションをレビューすることで、この課題に対処します。提案された各アクションをユーザーの依頼と照らし合わせて評価し、自動で承認するか、ユーザーに戻してレビューしてもらうかを決めます。その際、追加の権限を与えることも、必須になっている人の承認を省くこともありません。どのアクションを必ず人に回すかは、引き続きセキュリティリーダーが決められます。そのうえで Smart Approvals は、定型的な作業での不要な中断を減らすよう設計されています。

図 1: 対象になるかどうかはポリシーで決まる。Smart Approvals は対象のアクションを承認するか、ユーザーに戻してレビューを求める。ポリシーで拒否されたアクションはブロックされたまま

境界を決めるのはポリシー

Quick は自動レビューの前に、提案された各アクションを Custom Permissions、Quick Guardrails、コネクタのアクション権限、ユーザーの設定と照らし合わせて評価します。拒否されたアクションは拒否されたままで、人の承認が必須のアクションも引き続き承認が必要です。Smart Approvals を有効にしている場合、アクションが対象になるのは、ユーザーの設定が「Ask each time」で、ほかに人による承認を求める制御がない場合のみです。コネクタのアクション権限はコネクタの作成時に設定するもので、特定のアクションに人の承認を必須にできます。

管理者は Custom Permissions で、誰が Smart Approvals を利用できるかを決めます。Smart Approvals はデフォルトでオンですが、デフォルト拒否を有効にしたプロファイルでは明示的に許可する必要があります。ユーザーが自分で Smart Approvals をオフにすることもできます。この選択は、会話にもスケジュール実行にも適用されます。オフにすると、本来なら自動レビューの対象になるアクションにもユーザーの承認が必要になります。管理者がアカウントレベルの設定で、そのユーザーの Smart Approvals を再びオンにすることはできません。

対象となるアクションのレビューのしくみ

Smart Approvals は、分類器と呼ぶ別のモデルを利用し、対象のアクションを、ユーザーの依頼と、範囲を限った会話の内容に照らして評価します。分類器は、アクションが何をするか、データがどこに送られるか、誰に影響するかを考慮します。接続したソースから集めた人物と業務上のつながりを含む、ユーザーのナレッジグラフを参照することもできます。ナレッジグラフを利用すると、受信者がユーザーの指揮命令系統にいるかどうかなど、受信者とユーザーの関係を把握できます。ナレッジグラフの参照はお客様の Quick アカウント内で完結します。Quick は、ナレッジグラフのデータを含め、分類器がレビューした内容をモデルの学習やサービスの改善に利用しません。

依頼に合ったアクションでも、人によるレビューが必要な場合があります。たとえば、組織の外や、ユーザーの指揮命令系統にいる上級幹部に内容を送る、アクセス権を変更する、レコードを削除する、支払いを開始する、といったアクションです。挙げた例がすべてではなく、分類器は周辺の文脈も考慮します。アクションをユーザーの依頼と照らし合わせてレビューすることは、間接的なプロンプトインジェクションへの対策にもなります。間接的なプロンプトインジェクションとは、取得したコンテンツに含まれる指示でエージェントの行動を変えようとする攻撃です。Quick は、エージェントと分類器の両方に、そうしたコンテンツを指示ではなく情報として扱うよう指示しています。それでもモデルによるレビューは間違えることがあります。機密データを移すアクションなど、必ず人の承認が必要なアクションは、コネクタのアクション権限で承認を必須にしてください。

分類器は判断を担い、権限サービスは権限の適用を担います。自動承認はそれぞれ 1 回限りで、レビューされたアクションとパラメーターそのもののみに適用され、継続的な権限は与えません。Quick は会話の中で自動承認にラベルを付けます。分類器が承認しなかったアクションはユーザーに戻ります。タイムアウトなどのレビューの失敗も同じく戻り、自動承認になることはありません。こうした適用の境界によって、承認で許される範囲は限られます。ただし、境界があるからといって、分類器の判断が正しかったことまで保証されるわけではありません。

アクションが依頼を超えるとき

あるアカウントマネージャーが Quick に、チームのアカウントメモと前四半期のメールをもとに、AnyCompany 向けに四半期ビジネスレビューの資料を作るよう頼みます。続けて、名前を挙げた 2 人の同僚にその資料を送るよう Quick に頼みます。送信が自動レビューの対象だとすると、Smart Approvals は提案された送信アクションを、アカウントマネージャーの依頼と、利用できる会話の内容に照らして評価します。

ここで、アカウントメモに、この資料を約 2,000 人の営業全員向けの配布リストにも送るべきだと書かれていたとします。そうなると、送信先が本人の指定した受信者を超えて広がります。そのため、Smart Approvals はこの送信アクションを本人に戻してレビューを求めるよう設計されており、本人はその時点で送信を取りやめることができます。元の受信者への送信の承認を、より広い送信先に使い回すことはできません。

監査の証跡と調査

Quick の権限サービスは、Smart Approvals に関連する権限の更新を、お客様のアカウントの AWS CloudTrail に記録します。各イベントには、ユーザー、コネクタ、アクション、時刻が含まれ、リクエストが Smart Approvals に関連するものだという印が付きます。この印は、権限サービスが付与を受け入れたことや、アクションが実行されたことを示すものではありません。Quick は、コネクタのアクション権限による拒否を含む権限チェックの判定結果と、ユーザーの Smart Approvals 設定の変更も記録します。

調査担当者は、これらのイベントをユーザーと時刻で突き合わせ、CloudTrail にあるほかの Quick のアクティビティや、Amazon CloudWatch Logs に配信されるログと関連付けられます。チャットログには、ユーザーの依頼、システムの応答、会話の内容が記録されます。エージェントのメタデータログには、エージェントへの変更が記録されます。アクションが完了したかどうかは、送信したメールや更新したチケットなど、アクションの対象システム側の記録で確かめられます。これらを組み合わせると、承認を実行の証拠とみなすことなく、何が起きたかを再現できます。CloudTrail のイベント履歴が保持するのは 90 日分のイベントのみなので、より長い期間を調査する場合に備えて証跡を設定してください。チャットログには機密情報が含まれることがあるため、アクセスを制限し、CloudWatch Logs のデータ保護ポリシーで機密データをマスクすることも検討してください。

始め方

Smart Approvals はデフォルトでオンになっているため、まず人による承認が必要なアクションがコネクタのアクション権限で設定されているかを確認します。調査に備えて、CloudTrail の証跡と、チャットログとエージェントのメタデータログの CloudWatch Logs への配信を設定します。チャットログに記録されるのは配信を設定した後のアクティビティのみなので、それより前の承認には会話の内容が残りません。承認の要件とログの設定が済んだら、Custom Permissions で Smart Approvals の利用を、特定のワークフローに取り組むパイロットチームに絞ります。ほかのチームに広げるのはその後です。

パイロットの前に、成功の基準を決めておきます。基準は、定型的なアクションでは確認が減り、影響の大きいアクションは引き続き人に戻ってレビューされることです。パイロット中は自動承認の一部をサンプルとして確認し、組織の外に内容を送る、ドキュメントの記述をもとに受信者を追加する、といった影響の大きいケースをテストします。そうしたケースがユーザーに戻ってくることを確かめてください。また、チームが各アクションを承認から実行まで追跡できることも確かめてください。結果がこれらの基準を満たした場合にのみ、ほかのチームやワークフローに広げ、アクションやポリシーが変わったら見直します。

監督がうまく機能しているかは、エージェントが承認を求める回数ではなく、影響の大きい判断を人が握り続けているかで測ります。セキュリティリーダーにとって、Smart Approvals を広げる根拠はパイロットで得た証拠であるべきです。確認が減ることに価値があるのは、説明責任を弱めずに注意力を保てる場合です。

設定手順は、Quick ユーザーガイドのガバナンスのセクションにある Smart Approvals をご覧ください。

著者について

翻訳は Solutions Architect の 守田 凜々佳 が担当しました。