2026年10月2日、AWSはAmazon BedrockのAgentCore Gatewayにおいて、プライベート認証局（CA）が署名したTLS証明書への対応を発表しました。対象となるのは、Model Context Protocol（MCP）サーバー、OpenAPI、HTTPプロキシ（passthrough）の各ターゲットです。これまでパブリックCAの証明書を基本としていた構成に対し、社内ネットワークで独自に発行・管理している証明書を使ったAPIとも直接通信できるようになりました。

この更新により、VPC内のプライベートエンドポイントへ接続する際、中間にApplication Load Balancer（ALB）を配置して証明書を終端させる構成が必須ではなくなりました。社内の既存業務APIをAIエージェントのツールとして組み込む選択肢が広がる一方で、接続の前提や証明書の運用サイクルには注意すべき仕様が含まれています。AWSの公式ドキュメントであるConfigure Amazon Bedrock AgentCore Gateway VPC Egress for Gateway Targetsに記載された技術要件をもとに、接続設計と運用上の勘所を整理します。

中間のALBを必須としない接続と、VPC Latticeの前提

今回の機能追加では、PEM形式のCA証明書をAmazon S3またはAWS Secrets Managerに保存し、ターゲット作成時や更新時にその場所を参照情報として指定します。AgentCore Gatewayは指定された場所からCA証明書を取得・検証し、暗号化して保持した上で、接続先ターゲットに対するアウトバウンドTLS通信の信頼の基点（トラストアンカー）として利用する仕組みです。APIリクエスト自体に証明書の本文を含める必要はありません。

ただし、プライベートCAを登録するには前提条件があります。本機能はAgentCore GatewayとAmazon VPC Latticeの両方が利用可能なリージョンで提供されており、ターゲットがAmazon VPC Latticeを利用したプライベートエンドポイント（privateEndpoint）として構成されている必要があります。VPC Latticeのリソースはマネージドとセルフマネージドの双方が対象です。なお、中間のALBが必須ではなくなったとはいえ、既存のALBで提供されているルーティング機能やセキュリティ制御の役割もあるため、すべての既存ALBを一律に撤去できるわけではありません。現在のネットワーク構成や役割に応じた判断が求められます。

非同期で行われる証明書検証とステータスの確認

ターゲットの設定時には、証明書の検証挙動を把握しておく必要があります。S3 URIやシークレットARNの形式チェックなど一部の検証は即時に行われますが、証明書自体の検証は大部分が非同期で実行される仕様です。

Gatewayは設定リクエストを受け付けた後、ターゲットのバックグラウンド処理の中で証明書を検証します。検証に成功するとターゲットは「READY」状態となってトラフィックの受信が可能になりますが、証明書の期限切れや形式の不一致、ファイルサイズの超過（証明書チェーンを含め最大16KB）などがあると、作成時は「FAILED」、更新時は「UPDATE_UNSUCCESSFUL」となります。エラー理由はstatusReasonsフィールドに記録されるため、APIの呼び出し成功だけで判断せず、ターゲットのステータス遷移を確認する検証手順が必要です。

失効確認の非対応と、最長15分の既存接続への反映

運用面で特に注意が必要なのが、証明書の失効確認と更新反映のタイミングです。AgentCore GatewayはCRL（証明書失効リスト）やOCSP（Online Certificate Status Protocol）による失効確認を行いません。対象のプライベートCAにつながり、有効期限内であり、ホスト名が一致していれば、認証局側で失効された証明書であっても期限切れまで信頼を継続します。

失効した証明書への信頼を止めるには、UpdateGatewayTargetを呼び出して失効した証明書を含まない、またはその証明書にチェーンしない新しいCA証明書へ置き換えるか、登録を解除してパブリックCA信頼に戻す明示的な操作が必要です。さらに、証明書を更新または削除した場合でも、すでに確立されている既存の接続（in-flight connections）には最大900秒（15分）の間、以前の証明書や信頼情報が再利用される可能性があります。新規の接続には即座に新しい証明書が使われますが、即時遮断が求められるセキュリティ要件がある場合は、この反映時間を前提にした設計が必要です。

また、証明書の有効期限切れが発生すると、新たなTLSハンドシェイクが完了できなくなりターゲットは呼び出し不能になります。ただし、有効期間内に確立された既存の接続は、接続寿命（最大900秒／15分）が尽きるまでは期限切れ後もリクエストを処理し続ける可能性があります。接続がリサイクルされて新規ハンドシェイクが行われる段階で通信不能となるため、期限到来と同時にすべての接続が直ちに遮断されるわけではありません。AWSでは、設定されたCA内の最短残日数を記録するCloudWatchメトリクス「EarliestCertificateDaysToExpiry」を監視し、値がゼロに近づいた段階で通知するアラームを作成することを推奨しています。

社内APIとの連携を検討する具体的なステップ

たとえば、社内の基幹システムで管理されている「受注照会API」を、問い合わせ対応を行う社内AIエージェントに参照させたいケースを考えます。このAPIがVPC内でプライベートCA証明書を使って稼働している場合、今回の機能を活用して直接連携を試作する余地が生まれます。

最初に取り組む範囲としては、書き込みや更新を伴う操作は避け、影響範囲を限定できる参照専用のAPIに対象を絞るのが安全です。まずは対象APIの配置や使われている証明書の発行元、更新周期、担当チームの確認から進めます。あわせて、AIエージェントにどこまでの情報項目を渡してよいかという業務上の認可ルールを整理します。なお、privateEndpointを利用するターゲットでは、GatewayにインターセプターLambdaを構成する場合を除き、インバウンド認可に認証なし（NO_AUTH）を設定できない点にも留意が必要です。

その上で、検証環境を構築し、証明書登録後のREADY状態への遷移、通信の成立、さらには証明書の更新テストを実施します。更新リクエスト後に新規接続と既存接続がどのように振る舞うかを実際に確認しておくことで、本番導入後の運用リスクを低減できます。

既存システムの改修とAI連携の進め方

社内の業務APIをAIエージェントへ安全につなぐにあたっては、Gatewayの設定のみで対応できるか、あるいはOpenAPI定義の作成やデータ取得の制限、アクセス権限の制御といった周辺システムの改修が必要になるかは、既存APIの仕様や選択する接続方式によって異なります。

デノフでは、デノフのサービス案内にある通り、Webサイトや社内業務システムの設計・開発・運用保守から、AIを活用する業務の整理や導入支援までを一貫して手がけています。どの社内データをAIに参照させるべきかの業務整理から、既存システムの接続方式の検討、小さく始める試作環境の設計まで、自社の状況に合わせた進め方をご検討の際はデノフへの相談窓口よりお問い合わせください。