G-gen の杉村です。当記事では、Google Cloud の AI エージェント向けネットワークセキュリティ機能である Agent Gateway について解説し、仕様の把握や設計時の考慮事項の検討に役立つ情報を提供します。 概要 Agent Gateway とは アーキテクチャ メリット 通信制御 概要 通信制御の対象 Identity-Aware Proxy（IAP） Model Armor セマンティックガバナンスポリシー Service Extensions デプロイと運用 エージェントへのルール適用（Gemini Enterprise app） エージェントへのルール適用（Agent Runtime） Agent Gateway の使用を強制 プロジェクト構成 ロギング ドライラン ゲートウェイ ゲートウェイとは 設定値 デプロイメントモード Identity-Aware Proxy（IAP） IAM ポリシーとは 設定値 設定イメージ セマンティックガバナンスポリシー 概要 ネットワーク要件 技術的な詳細 プロトコル 通信の暗号化と認証 概要 Agent Gateway とは Agent Gateway は、AI エージェントが行う通信についてセキュアな接続とガバナンスを提供する、Google Cloud のセキュリティ機能です。 なお Agent Gateway は、Google Cloud が提供する AI 開発・運用プラットフォームである Gemini Enterprise Agent Platform （以下、Agent Platform）のコンポーネントの1つです。 Agent Gateway は「ユーザーとエージェント」「エージェントとツール」「エージェントと他のエージェント」の間の通信など、エージェントが行うさまざまな通信の出入り口として機能します。 組織のセキュリティ管理者は Agent Gateway を使うことで、エージェントに対するセキュリティとガバナンスポリシーを強制することができます。具体的には、明示的に許可されていない外部の API や MCP サーバー、他のエージェント等に対するエージェントからのリクエストを一元的に防いだり、Model Armor によるトラフィックの検査を強制することができます。 参考 : Agent Gateway overview なお、Agent Gateway を含む、AI エージェント開発プラットフォームである Gemini Enterprise Agent Platform の全体像については、以下の記事を参照してください。 blog.g-gen.co.jp アーキテクチャ Agent Gateway は、以下のようなイメージで、エージェントの通信を制御します。 Agent Gateway のアーキテクチャ Agent Gateway を使用することで、Google Cloud にホストされた AI エージェントの通信を一元的に統制できます。例として、リスクのある外部 API や MCP サーバーなどへのアクセスを拒否したり、不必要な AI エージェント間の通信を制限したりすることができます。 メリット Agent Gateway の導入により、AI 開発者とインフラ管理者（セキュリティ管理者）の双方に利点があります。 AI 開発者にとっての利点は、複雑なネットワーク管理やセキュリティのオーバーヘッドを意識することなく、エージェントの開発に集中できることです。mTLS ハンドシェイクの自動処理や、MCP、Agent-to-Agent（A2A）、REST、gRPC などによる通信の制御をプラットフォーム側でシームレスに行うことができます。また Agent Gateway は Cloud Monitoring や Cloud Logging と統合されているため、Agent Gateway を介することでオブザーバビリティが向上し、エージェントの動作の把握に役立ちます。 インフラ管理者（セキュリティ管理者）にとっては、エージェントの通信や外部システムへのアクセスに対して、一元的なガバナンスを効かせられるメリットがあります。また Identity and Access Management（以下、IAM）を用いた最小権限の原則の適用や、Model Armor を用いたプロンプトインジェクション保護などの AI セキュリティガードレールを実装できます。またエージェントと Agent Gateway の間では、Agent Identity や mTLS といった技術により自動的にセキュアな通信が確立されます。 通信制御 概要 Agent Gateway は、ゲートウェイを通過するトラフィックに対して、以下の仕組みを適用することでエージェントの通信を制御します。 名称 説明 適用可能なゲートウェイ Identity-Aware Proxy（IAP） エージェントから他のエージェント、MCP サーバー、API エンドポイントへの呼び出し可否を制御 egress モードのみ Model Armor LLM への入出力（プロンプトとレスポンス）を検査して危険なコンテンツをブロック egress / ingress モード セマンティックガバナンスポリシー（SGP） 自然言語でルールを記述してエージェントのツール呼び出しや Agent Skills 呼び出しを制御 egress モードのみ Service Extensions カスタム認可エンジンをゲートウェイに統合 egress / ingress モード 参考 : Agent Gateway overview - Access control policies Agent Gateway を適切に設定すると、制御対象のエージェントの外部への通信や LLM とのデータ入出力がゲートウェイによってインターセプト（傍受）されて、上記の仕組みにルーティングされて評価され、その結果としてブロックされたりロギングされたりします。 それぞれ、egress / ingress モードのどちらのゲートウェイに適用できるかが決まっています。ゲートウェイのデプロイモードについては後述します。 なお、トラフィックがゲートウェイによって検査されるようにするためには、Agent Gateway を展開するだけでなく、 エージェント側にも設定が必要 です。既存および新規にデプロイされるエージェントが Agent Gateway を必ず経由するようにするためには、後述する組織のポリシーを設定する必要がある点に注意してください。 通信制御の対象 Agent Gateway が通信制御の対象にできるのは、以下の環境で動作するエージェントのみです。 Agent Runtime （旧称 Vertex AI Agent Runtime） Gemini Enterprise app 上記以外の環境にホストされているエージェントは、Agent Gateway による制御の対象外です。 参考 : Agent Gateway overview - Agent runtimes Agent Runtime にホストするエージェントの場合、Agent Gateway の制御対象とするには、以下の条件があります。 エージェントのデプロイ時にゲートウェイを明示的に指定している エージェントが Agent Identity を持っている 同一プロジェクトの同一リージョンでは同じ Agent Gateway（egress / ingress ごと）に紐づける Agent Runtime のエージェントについては、組織のポリシーを使うことで、必ず承認されたゲートウェイを指定しないとデプロイできないように統制可能です。 参考 : Route Agent Runtime traffic through Agent Gateway 参考 : Route Agent Runtime traffic through Agent Gateway - Restrict Agent Runtime to approved Agent Gateways Gemini Enterprise app のエージェントの場合、アプリの管理設定で、使用するゲートウェイを明示的に指定する必要があります。 参考 : Route Gemini Enterprise traffic through Agent Gateway Identity-Aware Proxy（IAP） Agent Gateway は Identity-Aware Proxy （以下、IAP）の仕組みを使って、エージェントから他のエージェント、MCP サーバー、API エンドポイントへの呼び出し可否を決定します。 IAP による通信制御が使用できるのは Agent-to-Anywhere（egress）モードのゲートウェイのみです。Client-to-Agent（ingress）、つまりエージェントに入ってくる通信を IAP で制御することはできません。よって、Agent Gateway を介さないエージェントの呼び出しについては、エージェント側の認証・認可やネットワーク制御で適切に担保する必要があります。 制御のルールは、 IAM ポリシー によって定義します。詳細は後述します。 Model Armor Model Armor は、Google Cloud が提供する LLM 用の保護機能であり、LLM へのインプット（プロンプト）と出力されるアウトプット（レスポンス）を検査するサービスです。ゲートウェイで Model Armor を有効化すると、ゲートウェイを通るプロンプトやレスポンスが検査されるようになります。 Model Armor についての詳細は以下の記事を参照してください。 blog.g-gen.co.jp セマンティックガバナンスポリシー セマンティックガバナンスポリシー （Semantic Governance Policy、以下 SGP）は、自然言語を使って定義するセキュリティポリシーです。エージェントのツール呼び出し時や Agent Skills の呼び出し時に評価され、ユーザーの意図と組織のルールの両方に合致しているかどうかがチェックされます。 SGP は自然言語で定義され、LLM によって評価されるため、動的にポリシーを適用できるのが特徴です。SGP についての詳細は後述します。 参考 : Configure semantic governance policies Service Extensions Service Extensions を使うことで、独自の認可エンジンやサードパーティのエンジンに認可を委任できます。日本語の Google Cloud コンソール上では「サービス拡張機能」などと表記されます。 Service Extensions はもともと、Cloud Load Balancing と Cloud CDN の機能拡張のためにリリースされた機能であり、軽量な処理を Rust、Go、C++ などの言語で記述してアドオンできるプラグイン機能です。そのうちの Authorization extensions と同じ基盤を用いているのが、Agent Gateway の Service Extensions 機能です。 参考 : Delegate authorization with Service Extensions 参考 : Cloud Load Balancing and Cloud CDN extensions overview なお Agent Gateway でゲートウェイを作成して IAP を有効化したり Model Armor を有効化すると、それぞれに対応した Service Extensions が自動的に作成されます。Agent Gateway のバックエンドでは、実質的にこの Service Extensions が動作していることがわかります。 ゲートウェイ詳細画面 デプロイと運用 エージェントへのルール適用（Gemini Enterprise app） Gemini Enterprise app のエージェントに Agent Gateway の統制を適用するには、アプリの管理設定において、明示的にゲートウェイを指定します。 使用するゲートウェイは、アプリの管理画面の「セキュリティ > 構成」画面から設定できます。 また、Discovery Engine サービスエージェントと呼ばれる特殊なサービスアカウントに、所定の権限を付与する必要がある点にも注意してください。詳細は公式ドキュメントを参照してください。 参考 : Route Gemini Enterprise traffic through Agent Gateway エージェントへのルール適用（Agent Runtime） Agent Runtime にホストするエージェントを Agent Gateway の制御対象とするには、以下の条件があります。 エージェントのデプロイ時にゲートウェイを明示的に指定する エージェントが Agent Identity を持っている 同一プロジェクトの同一リージョンでは同じ Agent Gateway（egress / ingress ごと）に紐づける なお、ゲートウェイを作成するより前に既にデプロイされていたエージェントについては、ゲートウェイを指定してデプロイし直す必要があります。 参考 : Route Agent Runtime traffic through Agent Gateway Agent Gateway の使用を強制 組織のポリシーのカスタム制約を使用すると、Agent Runtime にデプロイされるエージェントが特定のゲートウェイを必ず使用するように強制することができます。組織としての統制のため、全エージェントのトラフィックが必ず Agent Gateway を通過するようにするためには、以下のドキュメントを参考にして組織のポリシーのカスタム制約を設定してください。 参考 : Route Agent Runtime traffic through Agent Gateway - Restrict Agent Runtime to approved Agent Gateways これらにより、組織内で Agent Gateway の使用を強制し、エージェントの通信に統制を効かせることができます。 プロジェクト構成 Agent Gateway のゲートウェイと、制御対象の Agent Runtime エージェントは、 同一プロジェクト ・ 同一リージョン に存在している必要があります。Gemini Enterprise app を制御対象とする場合も同様に、Agent Gateway のゲートウェイと、Gemini Enterprise app のアプリは同じプロジェクト・対応するリージョンに存在している必要があります。 よって組織全体でエージェントに対する統一した統制ルールを設定し、それを単一チームで運用するには、例として以下のような構成が考えられます。 案1: エージェントは単一の Google Cloud プロジェクトにデプロイ（組織のポリシーで制御）する。このプロジェクトで管理チームによって Agent Gateway が管理されている。 案2: 開発者チームごとに Google Cloud プロジェクトを払い出す。エージェントはそれらのプロジェクト内に存在している。Agent Gateway は管理チームが IaC 等で管理し、各プロジェクトに展開する。 案1 の構成では、エージェントデプロイ用の権限を持ったサービスアカウントを開発者チームに借用させたり、あるいは開発者チームにデプロイ権限を付与する、または CI/CD パイプラインによる自動デプロイでゼロタッチな本番デプロイをさせる、などによって実現することが考えられます。 案1: ゲートウェイを中央管理 ロギング Agent Gateway を通過するトラフィックは、Cloud Logging によって記録されます。ログには以下のような情報が含まれます。 タイムスタンプ Agent Registry リソース名（呼び出し元エージェント、呼び出し先の MCP サーバーなど） MCP のメソッド名（tools/call など） アクセス制御を処理した Service Extensions 拡張機能の情報 このログは、設定ミス等のトラブルシューティングのほか、ドライランモードで動作させている場合のポリシー監査に役立ちます。 ログエントリは networkservices.googleapis.com/Gateway リソースタイプとして記録されます。ログエクスプローラで以下のようなクエリを実行することで、Agent Gateway が出力したログを抽出できます。 resource. type=" networkservices.googleapis.com/Gateway " 参考 : Monitor traffic through Agent Gateway ドライラン 既存のエージェント環境に Agent Gateway を適用する場合は、事前にドライランを行って設定が適切であることを確かめてから、ポリシーを実際に適用することが推奨されます。 ゲートウェイの「アクセス認可」設定を「監査のみ」に設定することで、ロギングのみが行われブロックは行われないように設定されます。トラフィックのログは、前述のとおり Cloud Logging で確認できます。 ゲートウェイ ゲートウェイとは ゲートウェイ （Gateway）は、Agent Gateway の管理単位です。Google Cloud プロジェクト内に作成します。ingress モードと egress モードがあり、プロジェクト内に複数作成できます。 参考 : Set up Agent Gateway 設定値 ゲートウェイの作成時には、以下のような設定値を指定します。 リージョン ゲートウェイを展開するリージョンを指定します。制御対象の Agent Runtime のエージェントと同じリージョンを指定する必要があります。制御対象が Gemini Enterprise app のエージェントであれば、Gemini Enterprise app のアプリを作成したリージョンに対応したリージョンを指定する必要があります。例として Gemini Enterprise app のアプリが global リージョンにあれば、ゲートウェイは us-central1 に配置する必要があります。 Agent Registry ゲートウェイが制御対象とする Agent Registry のレジストリを指定します。制御対象の Agent Runtime エージェントと同じリージョンのレジストリを指定します。対象レジストリはグローバルレジストリ、リージョンレジストリ、US マルチリージョンレジストリ、EU マルチリージョンレジストリのいずれかから選択する必要があり、 //agentregistry.googleapis.com/projects/my-project/locations/asia-northeast1 のようにプロジェクト ID とロケーションの組み合わせで表されます。 デプロイメントモード（管理対象アクセスパス） Google Cloud コンソール上は「管理対象アクセスパス」、公式ガイド上は「デプロイメントモード」と表記されています。Client-to-Agent（ingress）または Agent-to-Anywhere（egress）から選択します。作成するゲートウェイが、エージェントに入ってくる通信を制御するものなのか、エージェントから出ていく通信を制御するものなのか、を決定する設定値です。詳細は後述します。 アクセス認可 デプロイメントモードが「Agent-to-Anywhere（egress）」のときだけ指定可能です。「監査のみ」または「ポリシーを適用」から選択します。前者を指定した場合はドライランとなり、ログが記録されるのみで、実際のアクセス制御は適用されません。後者の場合は、実際に IAM を使用したアクセス制御が適用され、明示的な許可がされていない通信はブロックされます。まずは前者でテストを行い、ポリシーが適切であると確かめられたら後者に変更する運用が想定されます。 Model Armor Model Armor の使用有無と、使用するテンプレートを指定します。 デプロイメントモード Agent Gateway には2つの デプロイメントモード （Deployment modes）があります。デプロイメントモードは、ゲートウェイを作成するときに選択します。Google Cloud コンソール上では「管理対象アクセスパス」と表記されています。 Client-to-Agent（ingress） Agent-to-Anywhere（egress） なお Google Cloud コンソール上では、前者は 「クライアントからエージェントへ（内向き）」、後者は「エージェントから任意の宛先へ（外向き）」と表記されています。 図左寄りが ingress モード、右寄りが egress モード Client-to-Agent（ingress） Client-to-Agent（ingress）は、クライアント（Claude Code、Gemini CLI、Antigravity CLI など）からエージェントへの通信を保護するためのモードです。エージェントに入ってくる通信に対して Model Armor のルールなどを適用できます。 Agent-to-Anywhere（egress） Agent-to-Anywhere（egress）は、エージェントから外部のサーバー、他のエージェント、ツール、MCP サーバー、API などへの通信を保護するモードです。IAP と IAM ポリシーによる認可や、Model Armor による検査などが適用できます。 Identity-Aware Proxy（IAP） IAM ポリシーとは ゲートウェイを通るトラフィックは、Identity-Aware Proxy（IAP）により検査されます。このとき IAP は IAM ポリシー （IAM policies）を使ってトラフィックを評価します。デフォルトではすべてのトラフィックが拒否されますが、ポリシーで指定されたソースとターゲットに合致したトラフィックであれば、許可されます。 参考 : IAM policies overview 参考 : Create IAM agent policies Agent Gateway における IAM ポリシーの実体は、IAP リソースが持つ IAM 許可ポリシーです。この概念を正確に理解するには、Identity and Access Management（IAM）の基本的な仕組みと、許可ポリシーについての理解が必要です。以下の記事も参照してください。 参考 : Google CloudのIAMを徹底解説！ - G-gen Tech Blog 設定値 IAM ポリシーは「Google Cloud コンソールの Agent Platform > エージェント > Policies」画面や gcloud コマンドラインを使い、プロジェクト内に複数作成できます。IAM ポリシーには、以下のような設定値があります。 参考 : IAM policies overview ‐ Policy components 接続元エージェント（ソースエージェント） アクセスを許可する対象の、接続元エージェントです。ゲートウェイに紐づけられたすべてのエージェントを指定することもできますし、個々のエージェントを指定することもできます。 ターゲット ポリシーが認可する接続先（ターゲット）を定義する設定値です。ターゲットとしては、Agent Registry に登録されているエージェント、MCP サーバー、API エンドポイントを選択できます。また、特定の Agent Registry に所属するすべてのターゲットを許可することもできます。 条件（Condition） 通常の IAM 許可ポリシー同様、条件（Condition）を指定することもできます。ただし指定可能な条件には制限があります。詳細は公式ガイドを参照してください。 設定イメージ Google Cloud コンソールの設定画面では、以下のスクリーンショットの上部の赤枠がソースエージェント、下部の赤枠がターゲットを指します。 IAM エージェントポリシー作成画面 ターゲットの Agent Registry としては、 グローバルレジストリ とリージョンごとの リージョンレジストリ が選択できます。Agent Registry では、エージェントや MCP サーバー、API エンドポイントを登録する際に、登録先としてグローバルレジストリまたはリージョンレジストリが選択できるので、対象が登録されているレジストリを適切に選択する必要があります。 グローバルレジストリまたはリージョンレジストリ セマンティックガバナンスポリシー 概要 セマンティックガバナンスポリシー （Semantic Governance Policy、以下 SGP）は、自然言語を使って定義するセキュリティポリシーです。エージェントのツール呼び出し時に評価され、ユーザーの意図と組織のルールの両方に合致しているかどうかがチェックされます。 参考 : Configure semantic governance policies 例として、出張手配エージェントが、宿泊先の手配をするツールを呼び出すケースを考えます。ツールは宿泊先の予約 API を実行するものですが、呼び出しの際に SGP が評価され「2万円を超える金額の自動的な決裁は禁止する」というルールに抵触している場合は、事前の設定に応じてツールの呼び出しを中止するか、人間の承認を求めます。このように、内容によって動的にポリシーを適用できるのが SGP の特徴です。 また SGP は、Agent Skills のロードに関するエージェントの挙動も傍受して制御できます。エージェントが実行する list_skills 、 load_skill 、 run_skill_script ツールなどを傍受して、ポリシーを適用できます。 ネットワーク要件 SGP を Agent Gateway で有効化するには、VPC ネットワークやプロキシ専用サブネット、Cloud DNS のプライベート DNS ゾーン、Private Service Connect エンドポイントなど、追加のネットワークコンポーネントが必要です。 参考 : Configure semantic governance policies ‐ Configure SGP policies and the SGP engine 技術的な詳細 プロトコル Agent Gateway は、MCP、A2A プロトコル、REST、gRPC など、HTTP ベースのトラフィックをサポートします。通信のペイロードは暗号化されます。 なお、エージェントの開発に使用するフレームワークは問いません。Agent Development Kit（ADK）でも、LangChain など Google 以外から提供するフレームワークでも、Agent Gateway で制御できます。 参考 : Agent Gateway overview - Key benefits 通信の暗号化と認証 ゲートウェイとエージェントとの間の通信は、mTLS（相互 TLS）によって暗号化されており、また Agent Identity に基づいて Demonstrable Proof of Possession（DPoP）による所有権証明も行われます。 これにより、エージェントになりすましたリクエストが困難になり、セキュリティが確保されます。 参考 : Agent Gateway overview - Integration with the Agent Platform ecosystem 参考 : IAM policies overview - IAP and Context-Aware Access provide end-to-end security Agent Identity については以下の記事で詳細に解説されています。 blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

みなさん、こんにちは。ソリューションアーキテクトの戸塚です。今週も 週刊AWS をお届けします。 いよいよ、今週 6/25(木)、26(金) で AWS Summit Japan 2026 が幕張メッセで開催されます。私もブース対応や登壇を行いますので、現地で私を見たらぜひお声かけください。Builders Fair のコーナーで、VR ゴーグルと体にセンサーをつけて計測するパデルフォームのコーチングシステムを展示しています！詳細は こちら 。私が所属する Retail CPG でも Retail エリアがあり、私はスマートグラス、音声 AI を使った店舗業務改善のデモも担当しております。Retailブースエリアの紹介もこちらの ブログ を参照ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2026年6月15日週の主要なアップデート 6/15(月) AWS WAF が AI トラフィック収益化機能を発表 AWS WAF が Bot Control 機能の一部として AI traffic monetization を発表しました。この機能により、コンテンツ所有者やパブリッシャーは、AI ボットやエージェントがコンテンツや API にアクセスする際に、エッジで直接価格設定、計測、決済を行うことができます。x402 オープンプロトコルを使用した machine-to-machine 決済により、AI エージェントは自律的に支払いを行い、コンテンツにアクセスできます。決済は Coinbase の x402 Facilitator を通じて USDC (stablecoin) で処理され、CloudFront のすべてのエッジロケーションで利用可能です。追加料金はなく、標準の AWS WAF 料金のみが適用されます。 AWS DevOps Agent がカスタム SRE エージェントと MCP/A2A プロトコルに対応 AWS DevOps Agent は、カスタム SRE エージェント、bring-your-own sub-agents、MCP (Model Context Protocol) および A2A (Agent-to-Agent) プロトコル経由のヘッドレスアクセスに対応しました。これにより、チームは定期的な SRE ワークフローの自動化、他のエージェントとの接続による DevOps Agent の拡張、Kiro、Claude、その他のコーディングアシスタントなど既存ツールからの機能アクセスが可能になります。カスタム SRE エージェントでは、Agent Space 内でスケジュール実行されるエージェントを作成できます。また、チャット機能の強化、カスタマー定義ルールによるインシデントスキップ、メモリーと Git 管理スキルによる知識強化、タスク品質追跡用の人手ラベリングとカスタマーダッシュボードが追加されました。こちらは、5 つの新リージョンで追加対応されています。 Amazon CloudWatch Log Analytics を発表 Amazon CloudWatch は Log Analytics という統合コンソール体験を提供開始しました。これは CloudWatch Logs Insights (ログクエリと分析)、Live Tail (リアルタイムログストリーミング)、Contributor Insights (トップコントリビューター分析) を 1 つの画面に統合したものです。複数のタブで異なるクエリを同時実行でき、パターン分析、パラメータ付き保存クエリ、ファセット、自然言語クエリ生成、ビジュアライゼーションなどの既存機能もすべて利用できます。Log Analytics はデフォルトの体験となり、すべての商用 AWS リージョンで利用可能です。料金は基盤となる各機能 (Logs Insights クエリ、Live Tail、Contributor Insights) と同じです。 Amazon Bedrock AgentCore Memory が long-term memory に厳密に一貫したメタデータをサポート Amazon Bedrock AgentCore Memory の long-term memory に、メタデータの抽出タイプとして STRICTLY_CONSISTENT が追加されました。これにより、アプリケーションから直接設定したメタデータ値が LLM の推論を経ることなく、そのまま long-term memory レコードに記録されるようになります。この機能は、部署別のスコープ検索、コンプライアンス境界の管理、マルチテナント環境でのテナントごとの独立処理を実現します。戦略ごとに最大 3 個の STRICTLY_CONSISTENT キーを設定でき、semantic、user preference、episodic 戦略で利用可能です。 AWS Transform が技術負債の自動検出と修復を行う continuous modernization 機能を発表 AWS Transform は、エンタープライズのソフトウェアポートフォリオ全体で技術負債を自動的に検出・優先順位付け・修復する continuous modernization 機能 (プレビュー) を発表しました。数千のリポジトリを対象に、古い依存関係、非推奨フレームワーク、セキュリティ脆弱性を自動で修復し、プルリクエストを自動生成します。料金は $0.035 / エージェント分で、US East (N. Virginia) と Europe (Frankfurt) で利用可能です。GitHub、GitLab、Bitbucket と統合し、Kiro、Claude Code、Cursor などの agentic IDE から利用できます。 6/16(火) Amazon Quick が Adobe、Figma、WhatsApp など 16 の新しいコネクタで統合を拡大 Amazon Quick は 16 の新しいツールとの統合を開始しました。これにより、チームはデータ、分析、デザイン、コミュニケーションアプリからのインサイトに基づいて、コンテキストを切り替えることなくアクションを実行できるようになります。新しいコネクタには Adobe、Figma、WhatsApp、Snowflake などが含まれ、生産性、デザイン、分析、データインフラ、金融インテリジェンス、コマース、コミュニケーション領域をカバーします。チームは数分で新しいツールをワークスペースに追加し、Quick Flows、Chat、Spaces で既存の統合と組み合わせて利用できます。 AWS Blocks、アプリケーションバックエンドを構成するオープンソースフレームワーク (プレビュー) を発表 AWS は、インフラツールの学習を不要にするオープンソース TypeScript フレームワーク AWS Blocks のパブリックプレビューを発表しました。ローカル環境では AWS アカウント不要で Postgres、認証、リアルタイムメッセージングが動作し、本番デプロイ時もコード変更なしで AWS サービス上で実行できます。開発者は単一セッション内でデータベーステーブル、ユーザー認証、AI エージェント、ファイルアップロード、バックグラウンドジョブを追加し、フルスタックをローカルでテストした後、準備が整った段階で AWS にデプロイできます。料金は AWS Blocks 自体に追加費用はなく、使用した AWS サービスの料金のみが発生します。 Amazon S3 Vectors が類似性検索で最大 10,000 件の結果返却に対応 Amazon S3 Vectors の QueryVectors API が、1 回のクエリで最大 10,000 件の類似性検索結果を返却できるようになりました。これは以前の制限値 100 件から 100 倍の増加です。結果は複数ページに分割して返却され、最初のページから順次処理を開始できます。クエリごとに最初の 512 KB のデータ返却は無料で、超過分には $0.01/GB のデータ返却料金が適用されます。この改善により、リランキング、集約、重複排除などのマルチステージ検索パイプラインで、より包括的な候補セットを取得できるようになります。 6/17(水) Oracle Database@AWS が Oracle Autonomous AI Database Serverless に対応 Oracle Database@AWS が Oracle Autonomous AI Database Serverless (ADB-S) に対応しました。ADB-S は、Exadata インフラや VM クラスターのプロビジョニングが不要で、AWS Management Console、CLI、API から直接データベースを作成できる完全マネージド型 Oracle データベースサービスです。コンピュートとストレージが独立してスケールし、AI Transaction Processing、AI Lakehouse、AI JSON Database、Oracle APEX の 4 つのワークロードタイプに対応します。AWS Marketplace の公開オファーおよびプライベートオファーで利用可能で、BYOL (Bring Your Own License) と License Included の両方をサポートします。現時点では US East (N. Virginia) と US West (Oregon) リージョンで提供されています。 AWS Secrets Manager が Agent Toolkit for AWS に安全なシークレット処理スキルを導入 AWS Secrets Manager は、Agent Toolkit for AWS の aws-core プラグインの一部として、secret safety skill を提供開始しました。このスキルにより、開発者は AI コーディングエージェントのワークフロー内でシークレット値を LLM のコンテキストやセッションログに公開することなく使用できます。2 層アプローチ（スキルガイダンスと PreToolUse フック）により、プレーンテキストのシークレットがモデルコンテキスト、セッションログ、エージェントメモリに一切表示されなくなります。Claude Code、Codex、Cursor などのエージェントで利用可能で、Secrets Manager が提供されているすべての AWS リージョンで今すぐ使用できます。 Amazon Bedrock AgentCore harness が一般提供開始 Amazon Bedrock AgentCore のマネージドエージェントハーネス (harness) が一般提供を開始しました。エージェント開発において最も時間がかかるオーケストレーションループ、実行環境、ツール統合、メモリ管理を設定ファイルだけで定義できるようになり、数分でプロダクション対応のエージェントを構築できます。モデルはセッション途中でも切り替え可能で、ツールやスキルの追加も設定変更のみで対応します。harness 自体に追加料金はなく、利用した CPU やメモリなどのリソース分のみ課金されます。 Amazon Bedrock AgentCore のポリシーで Bedrock Guardrails をサポート AWS は Amazon Bedrock AgentCore のポリシー機能で Bedrock Guardrails のサポートを発表しました。これにより、本番環境で AI エージェントをスケールする際に、より深いセキュリティと安全性の制御が可能になります。AgentCore ポリシーは、AI エージェントが実行を許可されるアクションを制御する認可機能です。Guardrails は、プロンプトインジェクション攻撃や機密データの露出を含む、AI エージェントワークロードにおける主要なセキュリティおよび安全性リスクに対する防御を提供します。Guardrails は、許可されたすべてのエージェントアクションの出力と、ゲートウェイターゲット（ツール、エージェント、モデル）へのすべての呼び出しの入力をリアルタイムで評価し、ダウンストリームシステムに到達する前にプロンプトインジェクション攻撃、有害コンテンツ、機密情報の露出を検出してブロックします。 AWS Glue Data Catalog がビジネスコンテキストとセマンティック検索をサポート（プレビュー） AWS Glue Data Catalog に、ビジネスコンテキストの付与とセマンティック検索機能がプレビューとして追加されました。Glossary terms、custom metadata fields (Forms)、Skill assets の 3 つの仕組みでテーブルやカラムに業務的な意味を付与でき、新しい Search API で semantic meaning による検索が可能になります。Claude Code などの MCP 互換エージェントは、Agent Toolkit for AWS の aws-data-analytics plugin を使うことで、ほぼセットアップなしで Data Catalog にアクセスできます。現在、US East (N. Virginia、Ohio)、US West (Oregon)、Europe (Ireland) の 4 リージョンでプレビュー提供中です。 Amazon Bedrock AgentCore に継続的改善機能を追加、プロダクション環境のエージェントを最適化 AWS は Amazon Bedrock AgentCore に新しい最適化機能を追加し、プロダクション環境のトレースからエージェントを継続的に改善できるようになりました。この機能は「サイレント障害」（エラーを出さないが実際には失敗している動作）を検出し、データに基づいた修正案を生成し、統計的に検証します。Failure insights、Intent insights、Trajectory insights の 3 つの分析機能は本日 13 リージョンでプレビュー提供開始、Batch evaluation、Recommendations、A/B testing は本日 14 リージョンで一般提供開始されました。AgentCore Runtime、AWS Lambda、Amazon EKS、非 AWS 環境など、実行環境を問わず利用できます。 AWS DevOps Agent がリリース管理機能を追加 (プレビュー) AWS DevOps Agent がリリース管理機能のプレビューを開始しました。この機能は、コード変更のリリース準備状況を評価し、自律的なリリーステストを実行することで、本番環境へのコードデプロイを安全に行えるようにします。リリース準備レビューでは、内部標準からの逸脱、依存関係の影響、アクセス制御をチェックし、決定論的証明を使用してインフラ変更が AWS Well-Architected のベストプラクティスに準拠しているか検証します。リリーステストでは、Web および API ベースのアプリケーション向けにテスト計画を生成・実行し、回帰、UX の問題、統合の失敗を検出します。プレビュー期間中は US East (N. Virginia) リージョンで追加費用なしで利用できます。 6/18(木) Amazon GameLift Servers がコンテナフリートの新機能を追加 Amazon GameLift Servers は、コンテナフリートに 2 つの重要な機能強化を実施しました。1 つ目は、コンテナグループ定義で Linux capabilities をカスタマイズできるようになり、NET_RAW や SYS_PTRACE といった特殊な権限を付与できます。2 つ目は、新しい Server SDK API である ListContainersNetworkInfo() を追加し、同一インスタンス上で実行される全コンテナのネットワーク情報 (コンテナ名、ID、ローカル IP アドレス、コンテナグループタイプ) を取得できるようになりました。これにより、ゲームサーバーとメトリクス収集コンテナ、ログエージェント、キャッシュシステムなどの補助サービス間の自動サービス検出と通信が簡素化されます。 AWS Compute Optimizer が EBS ボリューム推奨で IOPS とスループットスパイクの可視性を強化 AWS Compute Optimizer は、Amazon EBS ボリュームのライトサイジング推奨を提供する際に、IOPS とスループットのスパイクに対する可視性を向上させました。新たに VolumeIOPSExceededCheck と VolumeThroughputExceededCheck という 2 つの CloudWatch メトリクスを分析対象に追加し、ワークロードがプロビジョニングされたパフォーマンスを超えて IOPS やスループットを要求したかどうかを 1 分単位で検出できるようになりました。この機能により、バースト性の高いワークロードにおいて、コストとパフォーマンスのバランスを取ったライトサイジング判断が可能になります。 それでは、また来週お会いしましょう！ 著者について 戸塚 智哉(Tomoya Tozuka) / @tottu22 飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。

2026年6月29日（月）、技術カンファレンス「Tech-Verse 2026」（以下、本カンファレンス）を、オンラインにて開催いたします。本カンファレンスは、LINEヤフーおよび海外法人を含むグルー...