はじめに
2026年8月14日、Amazon Bedrock AgentCore GatewayのマネージドWeb Search Toolが東京リージョン(ap-northeast-1)でも使えるようになりました。
以前から「AI驚き屋発見器」というアプリでこのツールを使っており、待望のリージョン追加です。
ただ、待っていたのはリージョンが増えることより
「これで日本語のクエリはちゃんと日本語で返ってくるのか」
という点でした。
今までus-east-1でこのツールを使っていて、日本語で聞いても日本語の結果は返ってきていたのですが、それがus-east-1固有の挙動なのか、それとも東京リージョンでも同じなのかは実際に試すまで分かりません。
速報として、実機で確認した内容をまとめます。
私の場合はたまたま日本語の精度に問題がなかっただけかもしれません。
日本語の精度に難ありとする声もあがってきておりました。
検証の前提
すでに本番で動いている構成はこちらです。
- 構成: Next.js (Vercel) + Strands Agent (AgentCore Runtime) + AgentCore Gateway + Web Searchコネクタ
- Gateway:
ai-hype-checker-gw-rfmipak2bb(us-east-1、AWS_IAM認可) - 検索呼び出し:
agent/tools/web_search.pyがSigV4署名付きでMCPのtools/callを直接POSTする自前実装
本番のGatewayをTokyoに引っ越すのはさすがに大がかりなので、検証専用のGatewayを東京リージョンに新規で立てて、既存のus-east-1と横に並べて同じクエリを投げる形にしました。
検証用リソースを作る
まず、既存のus-east-1のGatewayロールの設定を確認します。
$ aws iam get-role --role-name ai-hype-checker-gateway-role --query 'Role.AssumeRolePolicyDocument'
trust policyのSourceArnがarn:aws:bedrock-agentcore:us-east-1:...にリージョン固定されていたので、この本番ロールをそのまま流用せず、ap-northeast-1向けの信頼ポリシーを持つ検証専用ロールを別に作りました。
中身は既存ロールの設定をそのままリージョンだけ東京に差し替えたものです。
Gateway自体もCLIから素直に作成できました。
$ aws bedrock-agentcore-control create-gateway \
--region ap-northeast-1 \
--name "ai-hype-checker-gw-tokyo-test" \
--role-arn "arn:aws:iam::<account>:role/ai-hype-checker-gw-tokyo-test-role" \
--protocol-type MCP \
--authorizer-type AWS_IAM
続けてWeb Searchコネクタのターゲットも追加します。
$ aws bedrock-agentcore-control create-gateway-target \
--region ap-northeast-1 \
--gateway-identifier ai-hype-checker-gw-tokyo-test-gc66l0pwzo \
--name "web-search-tool" \
--target-configuration '{"mcp":{"connector":{"source":{"connectorId":"web-search"},...}}}' \
--credential-provider-configurations '[{"credentialProviderType":"GATEWAY_IAM_ROLE"}]'
どちらも数秒でREADYになりました。
この時点で、東京リージョンでWeb Search Toolが正式に使えることは確認できたことになります。
同じ日本語クエリを両方に投げてみる
既存のweb_search.pyのSigV4署名ロジックをそのまま流用し、Gateway URLとリージョンだけ切り替えられる比較スクリプトを書きました。
日本語クエリを3種類用意して、us-east-1と東京の両方に投げます。
- 「AWS re:Invent 2026 発表内容」
- 「円安 原因 2026」
- 「東京の天気」
結果はこのようになりました(上位3件の一部を抜粋)。
「円安 原因 2026」の例だと、us-east-1側の1件目はSBI証券の記事、東京側の1件目はエデンレッドジャパンの物価高解説記事で、上位の並び順には多少ゆれがありました。
ただし2件目・3件目はどちらのリージョンでもダイヤモンド・オンラインの記事とgaitame.comの記事で完全に一致していて、日本語ドメインの記事が普通にヒットしている点は変わりません。
「東京の天気」のクエリでは、ウェザーニューズ・weather.com・tenki.jpという顔ぶれ自体が両リージョンで同じで、順位が入れ替わっている程度でした。
また、タイトルも本文もちゃんと日本語で返ってきていて、リージョンによって英語優先になったり文字化けしたりするようなことはありませんでした。
特別なパラメータで言語を指定しているわけでもなく、日本語のクエリ文字列をそのまま渡しているだけなので、そもそも言語対応はクエリの言語から自動で判定されているようです。
レイテンシは3クエリの平均でus-east-1が約1.1秒、東京が約0.6秒でした。
東京から呼んでいる分、往復のネットワーク遅延が単純に縮んだのだと思われます。
分かったこと
日本語対応そのものは、最初からus-east-1で使っていた時点ですでに機能していて、東京リージョンに来たことで新しくできるようになったわけではありませんでした。
今回リージョンが増えたことの実質的なメリットは、日本から呼ぶ場合のレイテンシが縮むという一点に集約されそうです。
0.5秒前後の差を「体感できるほどの差」と見るかどうかは用途次第で、AI驚き屋発見器のようにユーザーが結果を待つUIでは地味に効いてくる可能性があります。
検証に使った東京リージョンのGateway・Gatewayターゲット・IAMロールは、確認が終わった時点ですべて削除しました。
「テスト用に立てたリソースを本番にそのまま持ち込まない」という当たり前の後片付けです。
おわりに
今回はあくまで日本語クエリの言語対応とレイテンシに絞った速報で、東京リージョンへの本番移行を決めたわけではありません。
ただ、待たされていた東京リージョンが来て、しかも日本語対応が最初から効いていたと分かったのは素直に嬉しい結果でした。
最後まで読んでいただきありがとうございました。