Amazon Bedrock エージェントとプライベートサブネット内にあるシステムを連携させる方法

前提知識キーワード : Amazon Bedrock エージェント、アクショングループ、プライベート接続、パブリック接続

キーワードを見て「ちょっと知識が心配かも・・・。」という方向けに事前に学習いただくと良いリソースをご共有します。こちらも合わせてご覧いただくことでより本記事の理解が深まります。

Amazon Bedrock エージェント は Amazon Bedrock を用いてエージェントを開発・運用するためのマネージドサービスです。エージェント開発に必要な様々な機能 (前後処理・オーケストレーション・RAG 連携・ツール呼び出し・デバッグ・トレース・バージョニングなど) を提供しつつ Amazon Bedrock エージェント自体は無料であり、裏側で実行される基盤モデルの呼び出しなどに対して課金されます。AWS Lambda を始め様々な API を アクショングループ に設定することで生成 AI が使用するツールにすることができます。Amazon Bedrock エージェントについては以下の AWS BlackBelt を合わせてご覧いただけますと、エージェントの概要・導入検討・動作理解・運用監視に役立ちます。API 連携の機能であるアクショングループについても以下の動作理解編にて連携の仕組みを解説しており、開発・運用編にデモを交えてご紹介がありますので是非ご覧ください。

• Amazon Bedrock Agents 自律型 AI の実現に向けて: 検討編

• Amazon Bedrock Agents 自律型 AI の実現に向けて: 動作理解編

• Amazon Bedrock Agents 自律型 AI の実現に向けて: 開発・運用編

本記事をご覧の皆様は普段生成 AI アプリケーションの開発をされていて、もしかすると今日テーマとなっているプライベート接続について聞きなれないかもしれません。そこで簡単にパブリック接続とプライベート接続を解説したいと思います。

まず、パブリック接続についてです。パブリック接続はパブリック IP アドレスを使用して通信を行うことを指します。このように書くとパブリック接続はインターネットに必ず出ると思われるかもしれませんが、“パブリック IP アドレスを使用する場合、AWS でホストされているインスタンスとサービス間のすべての通信は AWS のプライベートネットワークを使用します。AWS ネットワークから発信され、AWS ネットワーク上の送信先を持つパケットは、AWS 中国リージョンとの間のトラフィックを除いて、AWS グローバルネットワークにとどまります。” (Amazon VPC FAQ)。本記事では接続元と接続先は共に AWS に閉じたパブリック接続を想定しています。

Amazon Bedrock エージェントをデフォルトの設定のまま呼び出す場合はパブリック接続になります。例えばパブリック接続を通じて以下から Amazon Bedrock エージェントを呼び出せます。

• AWS Lambda

• パブリックサブネットに配置された Amazon EC2, Amazon ECS

• NAT Gateway へのルーティングが設定されたパブリックサブネットに配置された Amazon EC2, Amazon ECS

次に、プライベート接続についてです。プライベート接続はプライベート IP アドレスを使用して通信を行うことを指します。例えば、Amazon Bedrock エージェントをプライベート接続で呼び出す場合には AWS PrivateLink を使用する必要があります。また、プライベートサブネットに配置された Amazon EC2 で実装された API を呼び出したい場合もプライベート接続になります。詳しくは本記事の中で取り扱います。

本記事では複数のお客様から頂戴した実際の質疑をデフォルメして一つのストーリーとしてご紹介します。ストーリーは以下のパターン 1 から応用編に向かって展開されます。プライベートサブネットにある API を利用する Amazon Bedrock エージェントをプライベート接続で呼び出す構成はパターン 3 で実現可能ですが、この記事を読んでくださっている Learn and Be Curious な開発者の方向けに、応用編としてリターンコントロール を使用する方法をご紹介します。アクショングループにリターンコントロールを設定する場合 AWS Lambda を設定する場合に比べて処理の流れが複雑になるため応用編としましたが、一度理解できれば応用の幅が広い機能ですので是非読んでみてください。

以下はそれぞれパターンの設定ポイントのまとめです。

パターン	エージェントの呼び出し	アクショングループ	連携先 API	設定のポイント
1	パブリック	AWS Lambda	AWS Lambda	アクショングループで AWS Lambda を選択する。
2	パブリック	AWS Lambda	プライベートサブネットに配置されたリソース	VPC リソースへのアクセス許可をした AWS Lambda をアクショングループに指定する。その AWS Lambda から連携先 API を呼び出す。
3	AWS PrivateLink	AWS Lambda	プライベートサブネットに配置されたリソース	パターン 2 に加え、Amazon Bedrock エージェントを PrivateLink 経由で呼び出す。
応用編	AWS PrivateLink	リターンコントロール	プライベートサブネットに配置されたリソース	パターン 3 をベースにアクショングループで AWS Lambda ではなくリターンコントロールを選択し、Agents Client からプライベート接続で連携先 API を呼び出す。

また、本記事におけるキャラクターは以下の通りです。

• 丁：お客様から Amazon Bedrock エージェントのアーキテクティングを依頼されているソリューションアーキテクト。ネットワークは得意だが、エージェントには少し敷居の高さを感じている。

• 中島：エージェントアプリケーションの開発経験があるソリューションアーキテクト。社内でいろんなエージェント開発の相談に乗っている。

長らくお待たせしました。それでは本編参りましょう !

丁「中島さん。最近エージェント開発の相談が増えてきたんですが、とりあえず早く始めたい場合ってネットワーキングどうするのが良いですか ? お客様は AWS Lambda で新しく機能を実装して、それをエージェントから呼び出したいそうです。」

中島「まずは PoC ですよね ? Amazon Bedrock エージェントを利用してパブリック接続で進めるのが一番早い方法だと思いますよ。」

丁「PoC 時点ではパブリック接続で OK だと聞いています。」

中島「それではアーキテクティングしてみましょう。Amazon Bedrock エージェントを呼び出す Agents Client は AWS Lambda に実装します。サーバーレスで実装できるから素早く PoC したい場合に向いていますね。AWS Lambda からパブリック接続で Amazon Bedrock エージェントを呼び出す場合はデフォルトの設定で OK です。今回連携先 API が AWS Lambda だから、Amazon Bedrock エージェントのアクショングループにその AWS Lambda を設定すればいいでしょう。」

丁「プライベート接続の要件がない場合はシンプルに AWS Lambda と Amazon Bedrock エージェントをパブリック接続 (図のA, B) で利用すればいいのですね。」

中島「その通りです。これが一番シンプルで早く始める方法だと思います。ちなみに、AWS Lambda には何を実装するのですか ?」

丁「お客様の業務用 API のスタブを実装するそうです。エージェント開発が初めてだから、まずは、エージェント自体が自分たちの業務 API を利用したとしたらどんな挙動をするのか実験するみたいですよ。」

丁はお客様へプライベート接続でのアーキテクチャをご紹介し、お客様も採択し PoC が開始されました。

丁「中島さん、前回相談したお客様が PoC を進めているのですが、次の段階に入って実際に業務に利用している API を使いたいらしいのですよね。」

中島「お客様の業務 API はどこに配置されているのですか ?」

丁「プライベートサブネットに配置された Amazon EC2 上に API が実装されています。」

中島「それはプライベート接続を意識しないといけないケースですね。それで、ネットワークの要件としてはお客様は何と仰ってるのですか ?」

丁「今回も PoC だし図の A と B は前回と同じパブリック接続で OK と聞いています。ただ、API がプライベートサブネット内にあるからどうしようかなと思っています。」

中島「なるほど。前回の実装を活かしつつプライベートサブネットにある API を Amazon Bedrock エージェントから呼ぶとよさそうですね。それではアーキテクティングしてみましょう。Agents Client の AWS Lambda、Amazon Bedrock エージェント、アクショングループに設定する AWS Lambda は前回と同じ構成で良さそうですね。一点、アクショングループの AWS Lambda に VPC リソースへのアクセスを許可 (以降 VPC Lambda と表記) して、そこから Amazon EC2 上の連携先 API を呼び出すように変更します。これで今回のお客様の要件を満たせるはずです。」

丁「たとえ、連携先 API がプライベートサブネット内にあっても Amazon Bedrock エージェントのアクショングループとしては AWS Lambda を指定するのは変わらないんですね。VPC Lambda にしても特に Amazon Bedrock エージェントのアクショングループに何か設定がいるわけじゃないってことですか。」

中島「その通りです。今回のお客様の場合、PoC の初期に AWS Lambda でスタブ実装して エージェントの挙動を検証されているから、移行もスムーズだと思いますよ。1 点注意としては VPC Lambda では Elastic Network Interface を作成する時間がかかるようになることがあります。これについてはこちらを確認してみてください。」

丁「良さそうですが、なんだか間に AWS Lambda を挟むのまどろっこしい気がしますね。AWS Lambda を介さず直接呼んだ方がシンプルじゃないですか ?」

中島「いいことに気づきましたね ! ただ、2025/4 月末現在、アクショングループから Amazon VPC 上のリソースを直接呼び出す機能はないのです。一応、リターンコントロール というアクショングループの機能を使う方法もあるんですが、ちょっと Agents Client の実装が複雑になるから今回は採用していません。」

丁はプライベートサブネットにある Amazon EC2 上の API を VPC Lambda から呼び出す方式を紹介し、お客様業務 API を利用する PoC が進みました。

丁「中島さん、前回相談したお客様が無事 PoC を完了しました ! これで晴れて本番導入の流れになったのですが、Amazon Bedrock エージェントをプライベート接続で呼び出す必要があるみたいなのです。」

中島「おめでとう、それは素晴らしいですね ! それで、エージェントをプライベート接続で呼び出したい理由を聞いてもいいですか ?」

丁「本番では Amazon VPC 内の Amazon EC2 に構築されている生成 AI アプリに組み込む形でエージェントを呼び出すことになったのです。今はエージェント機能がないのですが、生成 AI アプリ自体はすでに社内で展開されているらしいのです。そこに追加する形にしたいのだそうです。ただ、パブリックサブネットがないからプライベート接続で Amazon Bedrock エージェントを呼び出せないのです。」

中島「Agents Client がプライベートサブネット内の Amazon EC2 に実装されるってことですね。パブリックサブネットを追加して NAT Gateway へのルーティングを追加するのはセキュリティポリシー上難しいってことですね ?」

丁「念の為その案も提示してみたのですが、利用している VPC はパブリックサブネットをこれまで一度も入れていないらしくてお客様のセキュリティポリシー上難しいみたいです。あと NAT Gateway の料金も気になるみたいです。」

中島「なるほど、そうするとパブリック接続で Agents Client から Amazon Bedrock エージェントを呼び出すことはできないですね。それじゃあアーキテクティングしてみましょう。と言っても、今回はプライベートサブネット にある Amazon EC2 から AWS PrivateLink を使って Amazon Bedrock エージェントを呼び出すだけですね。こうすれば パブリックサブネットと NAT Gateway を追加しなくても Amazon Bedrock エージェントを呼び出せますよ。」

丁「Amazon Bedrock エージェントは AWS PrivateLink に対応してるんですね。今回のケースではAWS PrivateLink は NAT Gateway より料金が安いからお客様も受け入れてくれそうです。これで本番に組み込めます。Amazon Bedrock エージェントを AWS PrivateLink で呼び出す方法も一緒にお客様に説明しておきますね。」

中島「アーキテクチャの変更はそのくらいだと思いますが、Agents Client 側の実装は何か変える必要ありますか ?」

丁「今回 Agents Client は Python で実装されてるのですが、AWS PrivateLink を利用する場合は、boto3.client の endpoint_url に AWS PrivateLink の DNS 名を指定する必要があります。それ以外は変更不要ですね。」

丁はプライベートサブネット内の Amazon EC2 から PrivateLink 経由で Amazon Bedrock エージェントを呼び出す方式を紹介し、お客様も受け入れ本番導入に進みました。

丁が担当するお客様のエージェントが本番稼働してしばらく経ったある日のこと。

丁「中島さん、お久しぶりです。エージェントを本番導入したお客様覚えてますか ? あれからエージェント導入が他のシステムでも進んでいるのですが、ちょっとお客様から相談を受けていまして。」

中島「プライベートサブネットにある連携先 API を AWS Lambda を使わずに Amazon Bedrock エージェント から呼び出せないかって相談されたんじゃないですか ?」

丁「よく分かりましたね ! そうなんですよ。エージェント活用の拡大が見込まれるから、実装をテンプレート化することでエージェントをスムーズに展開する計画があるんです。パターン 3 をベースにテンプレート化する案が上がったのですが、連携先 API がプライベートサブネットにある場合に AWS Lambda を挟む構成が常にベターなのかって話になり・・・。今後の検討のために他の方式がないか相談されたんです。」

中島「なるほど。前にちょっと話したリターンコントロールって覚えてますか ?」

丁「プライベートサブネットに配置された API を Amazon Bedrock エージェントから呼ぶときに名前が出たのを覚えています。確か、実装が複雑になるとかであの時は使用しませんでしたね。」

中島「AWS Lambda を使わずに連携先 API を呼び出す際にはリターンコントロールで実現できます。リターンコントロールは基盤モデルの Tool Use と同様の仕組みですね。アクショングループで設定できることは AWS Lambda を選択した場合と一緒です。どの API を実行するのか ? どの引数で実行するのか ? などの情報を Agents Client に返して Agents Client 側で後続処理を実装するんですよ。」

丁「? ? ?」

中島「言葉だけだと難しいですよね。図を使って説明しましょう。1. ユーザリクエストを受けて、2. Agents Client から InvokeAgent すると、3., 4. Amazon Bedrock エージェントは使用すべき連携先 API をアクショングループに従って特定するのですが、それがリターンコントロールの設定だった場合、AWS Lambda を実行せずに、5. で Agents Client に処理を戻します。その時に、どのアクショングループのどの関数にどの引数を設定するのかといった情報が一緒に返ります。だから、6. でその情報を使って連携先 API を呼び出すことができるんです。7. で連携先 API から結果が返ってきたら、その結果を含めて、8. 再度 InvokeAgent を実行して最終回答が生成されるまでエージェントの処理を継続します。」

丁「なんだか、AWS Lambda と連携する時より難しそうですね・・・」

中島「そうですね。一見難しそうに見えますが、アクショングループに設定する AWS Lambda とリターンコントロールの違いを明確にするために模式化してみると以下の図の 4, 5 がポイントなんです。AWS Lambda が連携先 API を実行するか、Agents Client が連携先 API を実行するかですね。また、アクショングループで AWS Lambda を設定した場合は Agents Client は Amazon Bedrock エージェントにリクエストを投げて結果を受け取るだけ (2 と 7 のみ) で済むのに対し、リターンコントロールを設定した場合は Agents Client で 2 から 7 を制御する実装が必要になります。」

丁「ということは、リターンコントロールで連携先 API 呼び出しに必要な情報だけ受け取って、生成 AI アプリからプライベート接続でプライベートサブネットにある連携先 API を呼び出せばいいんですね。」

中島「その通りです ! それじゃあアーキテクティングしてみましょう。パターン 3 をベースに考えるとアクショングループで指定した AWS Lambda をリターンコントロールに変更します。そして、プライベートサブネット内の EC2 に実装されている生成 AI アプリにリターンコントロールで返ってきた後、つまり、先ほど模式化した図の “アクショングループにリターンコントロールを設定した場合” の 3. 以降を実装すると良いです。」

丁「今回、生成 AI アプリと連携先 API は別 VPC になっているから、VPC Peering や AWS Transit Gateway で繋いであげる必要がありますが、これでプライベート接続できますね。分かってみるとリターンコントロールって汎用性が高いですね。今回はプライベート接続のために使いましたが、Agents Client に処理が一度返せるから実質的にどんなアプリカスタマイズも可能ってことですよね。」

中島「そうですね。ただ、なんでもリターンコントロールに寄せてしまうと Agents Client の実装が肥大化するからソフトウェアアーキテクチャをしっかり考えないと後で困るかもしれません。あと、複数の Agents Client から呼び出されるエージェントにリターンコントロールを使用する場合は注意が必要ですね。」

丁「というと ?」

中島「AWS Lambda をアクショングループに設定した場合は、もし、連携先 API が増えてもアクショングループの変更だけで済みますが、リターンコントロールの場合は全ての Agents Client を変更する必要があります。」

丁「なるほど、複数の Agents Client が一つの Agent を共有するかも設計では大切なポイントなんですね。」

中島「その通りです ! 一方で、リターンコントロールの方が望ましい場合もあると思います。AWS Lambda 分のオーバーヘッドが性能原因になる場合はリターンコントロールで実装した方がいいかもしれません。また、AWS Lamba を呼ぶ際のパブリック接続がないから、お客様のセキュリティポリシーによってはリターンコントロールの方が合うという場合もありそうですね。あとは、AWS Lambda の制約に引っかかる場合、例えば処理時間が 15 分以上かかるという場合にもリターンコントロールが必要ですね。」

丁「アクショングループの AWS Lambda or リターンコントロールの選択をお客様にはどうおすすめすると良いですか ?」

中島「そうですね、パターン 3 のように AWS Lambda を使用する方法の方が Agents Client の実装が複雑でなくおすすめです。それで困りそうならリターンコントロールを導入していくと良い、とお伝えするとよさそうです。お客様の課題に合わせてより良いアーキテクチャを考えていきましょう。」

丁はリターンコントロールを利用する方式とメリット・デメリットをお客様に説明した。お客様はアクショングループに AWS Lambda を指定する場合と、リターンコントロールを指定する場合とでユースケースを整理し、テンプレート化がスタートしました。