1. はじめに
こんにちは！
AIエージェントにブラウザを持たせると、調査、情報収集、フォーム入力、外部 SaaS の操作まで一気に自動化できます。
ただ、その瞬間に出てくるのが、
「このエージェント、どこまで外に出して大丈夫？」
という問題です。
AWS が 2026年4月2日に公開した記事では、Amazon Bedrock AgentCore Browser をプライベートサブネットに置き、外向き通信を AWS Network Firewall に通して、許可したドメインだけへアクセスさせる構成が紹介されています。判定には、HTTPS なら TLS SNI、HTTP なら Host ヘッダーが使われます。
さらに AgentCore Browser 自体も、隔離されたコンテナ環境で動作し、Live View、CloudTrail logging、Session replay などの観測機能を持っています。
つまり今回は、単に「外に出さない」ではなく、安全に出して、後から追えるようにする 話です。
要するに今回は、
AIブラウザにインターネットを渡す
ではなく
AIブラウザに、通行証つきのインターネットを渡す
という設計です。
2. 先にざっくり整理すると
| 層 | 役割 | ひとことで言うと |
|---|---|---|
| AgentCore Browser | エージェント用の隔離ブラウザ実行環境 | AIが使う安全なリモートブラウザ |
| AWS Network Firewall | ドメイン単位の出口制御 | 門番 |
| CloudWatch / Session replay | ブロックや挙動の確認 | 後から追える仕組み |
この3つがそろうことで、「見せる」「止める」「振り返る」 がセットで回るようになります。
3. まずは全体像
この構成のポイントは、Browser に直接インターネットを見せないことです。
元記事でも、private subnet / public subnet / firewall subnet を分け、複数の route table で往復トラフィックを対称に通す構成になっています。戻り通信まで Firewall を通す設計なので、「行きだけ検査して帰りは素通り」という事故を避けやすくなります。
ここでの発想はかなりシンプルです。
- Browser は閉じた部屋に置く
- 外に出る通信は必ず関所を通す
- 関所では「どこへ行くのか」を見て通すか止めるか決める
AIエージェントのネットワーク設計を考えるとき、まずこの絵を頭に入れておくと理解しやすいです。
4. なぜドメイン制御が必要なのか
理由はシンプルで、AIエージェントは便利になるほど 意図しないサイトに行くリスク も増えるからです。AWS の記事では、規制業界におけるネットワーク分離と監査、マルチテナント SaaS における顧客別ポリシー、そして prompt injection による想定外サイトへの誘導リスクが背景として挙げられています。
つまり、プロンプトで何を言われても、
「そもそも到達できない場所」を作っておく
のが第一防衛線です。
これは人間のブラウザ操作でも大事ですが、AIエージェントだとさらに重要です。
なぜなら、AI は「うっかり」よりも「素直に言われた通り行ってしまう」からです。
5. どうやって判定するのか
ここで重要なのは、判定対象が IP アドレスではなくドメイン名 だという点です。
AWS Network Firewall の domain list rule groups は、HTTPS では TLS SNI、HTTP では Host ヘッダーを見て判定します。.example.com のように先頭に . を付けると、ルートドメインとサブドメインをまとめて扱えます。さらに Allow を使うと、指定に一致しない同種トラフィックは deny 側に回るため、allowlist 的な運用を作りやすいです。
つまりこの仕組みは、ざっくり言うと
「その通信がどの IP に行くか」ではなく、
「その通信がどのサイト名を名乗っているか」
を見ているわけです。
この違いは、後で出てくる「この構成の限界」にもつながります。
6. 実装で外せないポイント
6-1. allowlist は「主役」だけでなく「脇役」まで考える
Allowlist を作るとき、つい docs.aws.amazon.com や wikipedia.org のようなメインドメインだけを入れたくなります。
ただ実際には、ページ描画に CDN のドメインが必要になることがあります。AWS の記事でも、docs.aws.amazon.com の表示には awsstatic.com や cloudfront.net が関係するケースがあると説明されています。
つまり、
「ページ本体は許可したのに、なんか崩れる」
というときは、アプリが悪いのではなく 静的アセットの配信元が足りていない ことがあります。
Web は、思った以上に「本体以外」でできています。
6-2. aws:drop_established を使う
ここはかなり重要です。
Firewall policy のデフォルト動作には aws:drop_established を使う必要があります。理由は、SNI を見るには TCP ハンドシェイク完了後まで通信を進める必要があるからです。aws:drop_strict だと SYN の時点で止まってしまい、SNI 判定の前に落ちます。
感覚的には、
-
aws:drop_established
→ 「入口までは開けて、名札を見てから止める」 -
aws:drop_strict
→ 「名札を見る前に門を閉める」
という違いです。
今回の仕組みは「名札を見る」ことが本質なので、ここを間違えると設計そのものが成立しません。
6-3. .amazonaws.com は便利だけど、けっこう広い
AWS サービスにアクセスする必要がある場合、元記事では .amazonaws.com を allowlist に入れるか、代わりに VPC Endpoints を使う方法が案内されています。
ただし .amazonaws.com はかなり広く、公開 S3 バケット、API Gateway、Lambda Function URL なども含み得るため、厳密に絞りたい場合は VPC Endpoints で閉域化した方がコントロールしやすいです。
ここは実務でかなり大事です。
「AWS だから安全」 ではなく、
「AWS 上にも公開エンドポイントはたくさんある」
と考える方が正確です。
6-4. AgentCore 側は VPC の前提条件もある
AgentCore の VPC 接続は、各リージョンでサポートされる Availability Zone が決まっており、非対応 AZ のサブネットを指定すると作成に失敗します。さらに、ネットワークインターフェース管理のために AWSServiceRoleForBedrockAgentCoreNetwork というサービスリンクロールが使われます。プライベートサブネットからインターネットへ出すなら、NAT Gateway も必要です。
つまりこの構成は、
「Firewall だけ作れば終わり」ではなく、
「Browser を正しく VPC に住まわせる」ところからが本番です。
7. ハマりどころ早見表
| 症状 | よくある原因 | 見るポイント |
|---|---|---|
| 許可したサイトが崩れて表示される | CDN ドメイン未許可 |
awsstatic.com / cloudfront.net などを追加 |
| 許可したのに繋がらない | ルール反映待ち | Firewall の sync 状態が IN_SYNC か確認 |
| 許可サイトで 403 が返る | 宛先側の bot detection | CloudWatch ALERT に block が出ているか切り分け |
| マルチ VPC だと効きが怪しい | HOME_NET 未設定 | spoke VPC の CIDR を含める |
| 作成時点で失敗する | 非対応 AZ のサブネット | 対応 AZ ID を確認 |
| 片道だけ通って戻りが不安定 | 対称ルーティング不足 | IGW ingress route table を含めて確認 |
このあたりは元記事と AWS ドキュメントにかなり丁寧に書かれているので、実装時はここをチェックリストにしておくとかなり事故が減ります。
8. この構成、万能ではありません
ここも大事です。
この構成はとても有用ですが、万能ではありません。
AWS の記事でも、SNI ベースのドメインフィルタリングは defense in depth の第一層だと位置づけられています。SNI/Host を見る方式なので、暗号化されたリクエスト本文やレスポンス本文までは見えません。DNS レベルの制御が必要なら Route 53 Resolver DNS Firewall、HTTPS の中身まで見たいなら TLS inspection と Suricata ルールの追加が候補になります。
言い換えると、この仕組みは
「門番」には強いけど、
「荷物検査」まではやっていない
ということです。
また、Network Firewall のドメイン判定は SNI / Host ヘッダーを使うため、IP アドレスそのものを見ているわけではありません。高セキュリティ環境では、ドメイン制御だけで完結させず、DNS や IP ルールも重ねる方が現実的です。
9. どんなケースに向いているか
この構成が特にハマるのは、次のようなケースです。
- 社内リサーチエージェントを、信頼済みサイトだけに限定したい
- 顧客ごとに allowlist / denylist を切り替えたい SaaS を作りたい
- 監査ログつきで AI ブラウジングを運用したい
- prompt injection による外部サイト誘導リスクを下げたい
特に 「自由にブラウズさせたい」 よりも、
「アクセス先を設計したい」 企業利用に向いています。
10. まとめ
今回のポイントをまとめると、こんな感じです。
- AgentCore Browser を private subnet に置く
- 外向き通信は NAT Gateway と AWS Network Firewall を必ず通す
- Firewall は TLS SNI / HTTP Host でドメインを判定する
- Allowlist で「行っていい場所」だけを定義する
- CloudWatch や Session replay で、後から挙動を追えるようにする
- ただし、DNS 制御や本文 inspection が必要なら別レイヤーを足す
AIエージェントの実運用では、モデル精度やプロンプト設計ももちろん大事です。
でも、それと同じくらい大事なのが、
「そのエージェントを、どこまでネットワーク的に信用するか」
です。
今回の AWS 記事は、その問いに対してかなり実務的な答えをくれる内容でした。
AI にブラウザを渡すなら、まずはここから考えるのがよさそうです。