AWS Summit Japan 2026から見る、AIエージェントのセキュリティ・ガバナンス

1. はじめに

生成AIやAIエージェントの活用が広がる中で、最近は「AIエージェントをどう作るか」だけでなく、AIエージェントをどう安全に業務へ組み込むかが重要なテーマになってきています。

従来の生成AIセキュリティでは、プロンプトインジェクション、ハルシネーション、不適切な出力、機密情報の漏えいといった、モデルの入出力に関する論点が中心でした。

しかし、AIエージェントでは状況が少し変わります。

AIエージェントは、単に回答を生成するだけではありません。外部APIを呼び出し、SaaSにアクセスし、データベースを検索し、チケットを作成し、場合によっては業務システムに対して操作を行います。

つまり、AIエージェントのセキュリティ・ガバナンスでは、「AIが何を答えるか」だけでなく、「AIが何を実行できるか」を制御することが重要になります。

AWS Summit Japan 2026の各セッションを見ても、AIエージェントの本番運用に向けて、ID、認可、権限委任、ツール制御、データ分離、Responsible AI、監査、可観測性、Human-in-the-loopといった論点が多く扱われていました。

本記事では、AWS Summit Japan 2026のAWSセッションをもとに、AIエージェントにおけるセキュリティ・ガバナンスのトレンドを整理します。

2. 対象としたセッション

今回、AIエージェントのセキュリティ・ガバナンス観点で参考になると感じたAWSセッションは以下です。

セッションID	セッション名	本記事での位置付け
SEC353	エージェンティック AI アプリのセキュリティ・UX・開発速度を同時に実現	AgentCore Identity、認証・認可、権限委任
AIM344	Amazon Bedrock AgentCore による堅牢な SaaS データエージェントの設計	データエージェント、多層防御、テナント分離
AIM345	AI エージェント時代における責任ある AI（Responsible AI）のベストプラクティスと実践例	Responsible AI、Guardrails、ガバナンス
SEC351	インテリジェント運用：AI エージェントによるセキュリティ運用の効率化	セキュリティ運用、SOC/CSIRT、Human-in-the-loop
CNS317	AI Agent のオブザーバビリティ実践	生成AI・AIエージェントの可観測性
SEC230	経済安保が求めるデジタル主権 ― 重要インフラの AI とデータを AWS で守る	データ主権、運用主権、重要インフラ
AIM342	本番運用を見据えた AI エージェント - Amazon Bedrock AgentCore を活用したベストプラクティス	本番運用、評価、可観測性、ガードレール

3. AIエージェントのセキュリティ・ガバナンスで考えること

AIエージェントのセキュリティ・ガバナンスは、単に「危険な回答を出さないようにする」ことではありません。

AIエージェントが、誰の代理で、どの権限で、どのツールを使い、どのデータにアクセスし、どの操作を実行したのかを、設計時に制御し、運用時に観測し、監査時に説明できるようにすることが重要です。

整理すると、以下のような観点が必要になります。

観点	考えるべきこと
ID・認証	誰がエージェントを呼び出しているのか
認可・権限委任	エージェントは誰の代理で、どの範囲まで操作してよいのか
ツール制御	どのツールを、どの条件で実行してよいのか
データ分離	ユーザー、組織、テナントの境界をどう強制するのか
Guardrails / Policy	不適切な入出力や禁止操作をどの層で止めるのか
Human-in-the-loop	どの操作に人間の確認・承認を挟むのか
Observability	入力、出力、ツール呼び出し、判断、エラーをどう追跡するのか
監査	誰が、いつ、何を実行したかを後から説明できるか
ガバナンス	組織として、どのユースケースを許可し、どのリスクを受容するのか

AIエージェントが業務システムに接続されるほど、これらの論点は重要になります。

特に、AIエージェントが社内API、SaaS、データベース、ナレッジベース、メール、チケット管理、ワークフローなどにアクセスする場合、モデルやプロンプトだけで安全性を担保するのは難しくなります。

そのため、AIエージェントのセキュリティ・ガバナンスでは、LLMの振る舞いだけでなく、ID、API、ツール、データ、監査、運用プロセスまで含めて設計する必要があります。

4. AWS Summit Japan 2026から見るAIエージェントのセキュリティ・ガバナンスのトレンド

ここからは、AWS Summit Japan 2026の各セッションをもとに、AIエージェントのセキュリティ・ガバナンスのトレンドを整理します。

今回のセッション群を見ると、AIエージェントのセキュリティは「入力・出力を安全にする」段階から、AIエージェントの行動、権限、データアクセス、運用プロセスを統制する段階へ広がっていると感じます。

4.1 「回答の安全性」から「行動の安全性」へ

従来の生成AIセキュリティでは、主に以下のような観点が中心でした。

• 不適切な回答を出さないこと
• ハルシネーションを抑えること
• 機密情報や個人情報を出力しないこと
• プロンプトインジェクションを防ぐこと
• 業務外トピックに回答しないこと

これらは、AIエージェント時代にも引き続き重要です。

しかし、AIエージェントでは、それだけでは不十分です。AIエージェントは外部APIやツールを呼び出し、業務システムに対して実際の操作を行う可能性があります。

出典：AWS Summit Japan 2026 AIM345「AI エージェント時代における責任ある AI（Responsible AI）のベストプラクティスと実践例」

そのため、以下のような問いが重要になります。

• このエージェントは誰の代理で動いているのか
• どのデータにアクセスしてよいのか
• どのツールを実行してよいのか
• どの操作は人間の承認が必要なのか
• 実行結果を後から追跡できるのか
• 想定外の操作を止められるのか

つまり、AIエージェントのセキュリティは、回答の安全性だけでなく、行動の安全性を扱う必要があります。

この観点で、AgentCore Identity、AgentCore Policy、AgentCore Gateway、AgentCore Observability、AgentCore Evaluations、Amazon Bedrock Guardrailsなどの役割が重要になります。

4.2 「誰の代理で何をするか」を制御する

AIエージェントが業務システムやSaaSにアクセスする場合、重要になるのがIDとアクセス制御です。

SEC353では、AIエージェントを組織全体で活用する際の課題として、主に以下の3点が整理されています。

観点	課題
セキュリティ	エージェントに必要最小限の権限だけを安全に委任したい
UX	ユーザーに毎回同意を求めず、自然に使える体験にしたい
開発速度	認証・認可やトークン管理を個別実装せず、素早く本番適用したい

たとえば、営業支援エージェントがCRM、財務システム、メールにアクセスして会議準備を支援するケースを考えます。

このとき、単に「エージェントがシステムにアクセスできる」だけでは不十分です。

• 誰がエージェントを呼び出しているのか
• そのユーザーはそのエージェントを利用してよいのか
• エージェントは誰の代理で外部サービスにアクセスするのか
• どのツールに、どの範囲の権限を渡すのか
• 誰が何に同意し、何が実行されたのかを後から追えるのか

こうした論点を支えるのが、Amazon Bedrock AgentCore Identity です。

出典：AWS Summit Japan 2026 SEC353「エージェンティック AI アプリのセキュリティ・UX・開発速度を同時に実現」

AgentCore Identityは、大きく Inbound Auth と Outbound Auth の2つで整理できます。

観点	役割
Inbound Auth	エージェントを呼び出すユーザーやアプリケーションを検証する
Outbound Auth	エージェントがユーザーの代理で外部サービスへアクセスするための認証情報を扱う

Inbound Authでは、既存のIdPが発行したトークンを検証し、ユーザーやグループなどの情報をもとに、エージェントを実行してよいかを判断できます。

Outbound Authでは、外部サービスへの初回アクセス時にユーザーの同意を取得し、その後はToken Vaultに保存されたトークンを利用することで、毎回同意を求めずにアクセスできます。

AIエージェントの本番化では、モデルやプロンプトだけでなく、誰が、誰の代理で、どのリソースに、どの権限でアクセスするのかを設計する必要があります。

AgentCore Identityは、そのための認証、権限委任、トークン管理、監査を支える中核機能と捉えることができます。

4.3 プロンプトだけに頼らない多層防御が必要になる

AIM344では、SaaSデータエージェントの設計において、データエージェントを4つのレイヤーで守る考え方が紹介されています。

出典：AWS Summit Japan 2026 AIM344「Amazon Bedrock AgentCore による堅牢な SaaS データエージェントの設計」

レイヤー	主な論点
LLM層	入出力、プロンプト、ガードレール
呼び出し層	ユーザーやテナントの実行コンテキスト
ツール層	ツール呼び出し、パラメータ検証、業務ロジック
リソース層	DB、ナレッジベース、メモリ、ストレージへのアクセス制御

データエージェントでは、ユーザーの自然言語に応じてデータを取得・分析します。

従来のBIのように、あらかじめ定義されたSQLやダッシュボードだけを使う構成と比べると、柔軟に分析できる一方で、リスクも大きくなります。

たとえば、以下のようなリスクが考えられます。

• PIIや機密情報の漏えい
• ユーザーや組織をまたいだ不適切なデータ参照
• 業務外トピックへの応答
• 非効率なクエリの実行
• プロンプトインジェクション
• LLMが生成するSQLを制御できないこと
• ツール呼び出しの認可がLLM任せになること

特に、マルチテナントSaaSでは注意が必要です。

ここでいうテナント越境とは、本来はA社のユーザーがA社のデータだけを参照すべきところ、AIエージェントが誤ってB社のデータまで取得・回答してしまうようなケースを指します。

重要なのは、LLMに「tenant_idをWHERE句に入れて」と指示するだけでは、テナント分離の保証にはならないという点です。

テナントIDやユーザーIDのような重要な制御情報は、LLMの推論に任せるのではなく、JWTなどの実行コンテキストから機械的に取得し、ツール層やリソース層へ伝搬する必要があります。

AIエージェントのセキュリティは、プロンプトやガードレールだけで完結するものではありません。ID、ツール、API、データベース、ストレージまで含めた多層防御が必要になります。

4.4 Responsible AIは開発プロセスに組み込む

AIエージェントのガバナンスでは、Responsible AIの観点も重要です。

AIM345では、AIエージェント時代のResponsible AIのベストプラクティスとして、ガードレールの適用、洞察の取得、組織としての対応・防止といった考え方が整理されています。

ここで重要なのは、Responsible AIを「最後にチェックする項目」として扱うのではなく、開発・運用プロセスに最初から組み込むことです。

出典：AWS Summit Japan 2026 AIM345「AI エージェント時代における責任ある AI（Responsible AI）のベストプラクティスと実践例」

AIエージェント開発では、以下のような項目を仕様として明確にしておく必要があります。

• 扱ってよい業務範囲
• 扱ってはいけないトピック
• 使用してよいツール
• 出力してはいけない情報
• 人間承認が必要な操作
• 評価すべき安全性指標
• リリース前に満たすべき基準
• 問題発生時の停止・ロールバック方法

たとえば、社内問い合わせ対応エージェントであれば、回答してよい業務範囲、参照してよいナレッジ、個人情報や機密情報の扱い、回答できない場合の返し方を定義する必要があります。

また、営業支援エージェントやデータ分析エージェントであれば、どのSaaSやデータベースへアクセスしてよいのか、どの操作に人間承認を挟むのかを定義する必要があります。

つまり、Responsible AIは理念や方針だけではなく、仕様、評価、リリース基準、運用ルールに落とし込むべき実装上の要件になっていくと考えられます。

4.5 Guardrails、Policy、Human-in-the-loopを役割分担する

AIエージェントの安全性を高めるためには、GuardrailsやPolicy、Human-in-the-loopを適切に使い分けることが重要です。

AIM345では、Amazon Bedrock Guardrailsによって、ハルシネーションやPII漏えいを抑制し、問題の検知や対応に役立つ洞察を得る例が紹介されています。

一方で、Guardrailsだけですべてを守ることはできません。たとえば、不適切な入力・出力を抑制することと、危険なツール実行を止めること、テナント境界を強制すること、人間承認を挟むことは、それぞれ異なるレイヤーの制御です。

出典：AWS Summit Japan 2026 AIM345「AI エージェント時代における責任ある AI（Responsible AI）のベストプラクティスと実践例」

整理すると、以下のような役割分担が考えられます。

制御対象	主な制御手段
不適切な入力・出力	Amazon Bedrock Guardrails
ハルシネーションや根拠のない回答	Guardrails、RAG設計、評価
PIIや機密情報の出力	Guardrails、出力サニタイズ、データ層制御
業務外トピック	Guardrails、Policy、システムプロンプト
危険なツール実行	AgentCore Policy、AgentCore Gateway、アプリケーション側の制御
テナント境界	JWT、IAM、RLS、メタデータフィルタ、namespace
重要操作	Human-in-the-loop、承認ワークフロー
監査証跡	Observability、CloudTrail、CloudWatch、アプリケーションログ

重要なのは、Guardrails、Policy、Human-in-the-loopを単独で考えるのではなく、役割を分けて組み合わせることです。

たとえば、以下のような考え方ができます。

• モデルへの入力・出力はGuardrailsで制御する
• ツールやAPIの実行可否はPolicyやGatewayで制御する
• データ境界はIAM、RLS、メタデータフィルタなどシステム側で強制する
• 重要な業務判断や取り消しが難しい操作は人間承認を挟む
• 実行内容はObservabilityや監査ログで後から追えるようにする

AIエージェントのセキュリティでは、Guardrails、Policy、データ層の制御、人間承認を組み合わせ、複数のレイヤーで守る設計が重要になります。

4.6 可観測性と監査証跡が本番運用の前提になる

AIエージェントは、従来のアプリケーションよりも挙動が変動しやすい領域です。

同じような入力でも、選択するツール、実行順序、回答内容が変わる可能性があります。そのため、本番運用では、実行内容を後から追跡できることが重要です。

CNS317では、生成AIやAIエージェントにおけるオブザーバビリティとして、ログ、メトリクス、トレースの重要性が整理されています。

出典：AWS Summit Japan 2026 CNS317「AI Agent のオブザーバビリティ実践」

AIエージェントでは、少なくとも以下のような情報を追跡できるようにしたいです。

• ユーザーが何を入力したか
• どのエージェントが呼び出されたか
• どのツールを選択したか
• どのAPIやデータにアクセスしたか
• ツール呼び出しの結果はどうだったか
• どのような最終回答を返したか
• GuardrailsやPolicyに抵触したか
• 人間が承認したか
• エラーやタイムアウトが発生したか

これらを追跡できなければ、問題が起きた際の原因調査、品質改善、監査対応が難しくなります。

また、AIM342でも、AIエージェントを本番運用するうえで、オブザーバビリティを初日から設定することがベストプラクティスとして示されています。

AIエージェントを安全に運用するには、実行前の制御だけでなく、実行後に説明・検証できる証跡が重要になります。

4.7 セキュリティ運用でもAIエージェントは補助役として使う

SEC351では、AIエージェントによるセキュリティ運用の効率化が扱われています。

出典：AWS Summit Japan 2026 SEC351「インテリジェント運用：AI エージェントによるセキュリティ運用の効率化」

セキュリティ運用では、以下のような課題があります。

• どのように取り組めばよいのか全体像が分からない
• セキュリティ運用体制の強化が思うように進まない
• 大量のログやアラートにどう対処すればよいか分からない
• 限られたリソースで素早く対応し、ビジネス影響を最小化したい

AIエージェントを活用すると、Amazon GuardDuty、AWS Security Hub、AWS CloudTrail、Amazon Detective、Amazon Inspector、AWS Configなどの情報をもとに、調査、分析、トリアージ、対応案の整理を支援できます。

たとえば、以下のような用途が考えられます。

• AWS環境のセキュリティチェック
• WAFルールの分析・最適化
• GuardDuty検出結果の調査
• CloudTrailログをもとにした原因分析
• Security Hubの検出結果の優先順位付け
• インシデント対応手順の作成支援
• 修復手順の候補提示

ただし、ここでも重要なのは、AIにすべてを任せるのではなく、人間が判断することです。

AIエージェントは、膨大なログや検出結果から論点を整理し、対応案を提示することは得意です。一方で、実際に本番環境へ変更を加える、通信を遮断する、権限を剥奪する、外部へ通知するといった判断は、業務影響を踏まえて人間が確認すべきです。

セキュリティ運用におけるAIエージェントは、SOC/CSIRTを置き換えるものではなく、調査や判断材料の整理を支援する補助役として使うのが現実的だと感じます。

4.8 重要インフラや規制業界ではデジタル主権も論点になる

SEC230では、重要インフラのAIとデータをAWSで守る観点として、デジタル主権が扱われています。

出典：AWS Summit Japan 2026 SEC230「経済安保が求めるデジタル主権 ― 重要インフラの AI とデータを AWS で守る」

デジタル主権とは、国家や組織が、自らのデジタルデータ、システム、インフラについて、「誰が」「どこで」「どのように」管理・運用するかを自律的に決定・統制できる状態を指します。

AIエージェントが重要インフラや規制業界のデータにアクセスする場合、アプリケーションレベルの権限制御だけでは不十分です。

以下のような観点も含めて設計する必要があります。

• データの保管場所
• リージョン選択
• 暗号化
• アクセス制御
• 運用者アクセス
• 監査証跡
• レジリエンス
• 第三者検証
• AIの判断・行動範囲

特に、金融、公共、医療、重要インフラなどの領域では、AIエージェントがどのデータにアクセスできるかだけでなく、データがどこに保管され、誰が運用でき、どのように監査できるかまで含めて考える必要があります。

AIエージェントのセキュリティ・ガバナンスは、アプリケーションやモデルの安全性だけでなく、データ主権、運用主権、レジリエンス、透明性まで含めたテーマになっていくと考えられます。

5. まとめ

AWS Summit Japan 2026の各セッションをAIエージェントのセキュリティ・ガバナンス観点で見ると、AIエージェントは「安全に回答する」段階から、安全に行動する段階へ進みつつあると感じました。

今回整理したポイントをまとめると、以下のようになります。

• AIエージェントでは、回答の安全性だけでなく、行動の安全性が重要になる
• ID、認可、権限委任、監査証跡が本番エージェントの中核になる
• プロンプトだけに頼らず、LLM層、呼び出し層、ツール層、リソース層で多層防御する必要がある
• Responsible AIは方針ではなく、仕様、評価、リリース基準、運用ルールに組み込むものになる
• Guardrails、Policy、Human-in-the-loop、データ層制御は役割を分けて設計する
• 可観測性と監査証跡がないAIエージェントは、本番運用しづらい
• セキュリティ運用にAIエージェントを使う場合も、人間の判断と承認が重要になる
• 重要インフラや規制業界では、データ主権や運用主権まで含めたガバナンスが必要になる

一方で、最初からすべてのセキュリティ対策を完璧に作り込むのは難しいと思います。

まずは、業務上のユースケースを明確にし、AIエージェントに任せる範囲と、人間が判断する範囲を分けることが重要です。

たとえば、情報検索、要約、候補提示、定型的なチェック、対応案の整理はAIエージェントに任せやすい領域です。一方で、外部送信、権限変更、本番環境への変更、取り消しが難しい処理、法務・コンプライアンスに関わる判断などは、人による確認や承認を挟む設計が必要になります。

AIエージェントのセキュリティは、単に「危険な回答を出さないようにする」ことではありません。

AIエージェントが、誰の代理で、どの権限で、どのツールを使い、どのデータにアクセスし、どの操作を行ったのかを、設計時に制御し、運用時に観測し、監査時に説明できるようにすることが重要です。

今後、AIエージェントを業務に組み込むうえでは、モデルやプロンプトだけでなく、ID、認可、ツール制御、データ分離、Guardrails、Policy、Observability、Human-in-the-loopを含めた、総合的なセキュリティ・ガバナンス設計がますます重要になってくると考えます。