前回、香港国際空港でClaude CodeもCodexも使えなかった話を書いた。
そのとき「Bedrock経由なら通るのか実際に調べてみた」という節で、AWS公式ドキュメントの記述だけを根拠に推測を書いて終わっていた。
8/23、帰りの便でまた香港国際空港に立ち寄る機会があったので、今度は実際にBedrockのPlaygroundで東京・バージニア北部・シンガポール・台北の4リージョンを叩いてみた。
やったこと
香港国際空港のWi-Fiに接続した状態で、Amazon Bedrockのコンソールにサインインし、Playgroundから各リージョンのモデルに「テスト」と送るだけの単純な検証。
請求先住所は東京の自宅に設定してある。
なお、もっと検証したかったが、時間の制約上最低限の検証にとどまっている。
結果
| 対象 | 東京 | バージニア北部 | シンガポール | 台北 |
|---|---|---|---|---|
| Anthropic Claude系(Haiku 4.5 / Sonnet 5 / Opus 4.5) | ブロック | (別エラーで未確認) | ブロック | ブロック |
| OpenAI GPT-5.6系(プロプライエタリ) | ブロック | — | ブロック | — |
| gpt-oss-120b(OpenAIのオープンウェイト) | 成功 | — | — | — |
| Kimi K2.5(Moonshot AI) | 成功 | — | — | — |
| Nova Pro(Amazon自社モデル) | — | — | — | 成功 |
| platform.claude.com(Anthropic直営ドメイン) | 白紙 | 白紙 | — | — |
バージニア北部とシンガポールでClaude Sonnet 5を叩いたときは「The provided model identifier is invalid」というエラーが返ってきた。
これは地域ブロックとは別種のエラーで、単にそのリージョンでそのモデルIDが無効というだけの話。
地域ブロックの本体は「Access to Anthropic models is not allowed from unsupported countries, regions, or territories」という文言のValidationExceptionで、こちらはAWS公式ドキュメント(re:Post)に載っている文言とそのまま一致している。
OpenAIモデルにも同種のエラーがあり、こちらは「Access to OpenAI models is not allowed from unsupported countries, regions, or territories」という文言で、OpenAI公式のsupported-countriesページに誘導される。つまりBedrock経由でも、AnthropicとOpenAIそれぞれのモデル提供元が定めた地域制限がそのまま乗ってくる。
請求先住所が東京でも弾かれた
これが今回の検証でいちばんはっきりした点。前回の記事では「Bedrockの地域判定はAWSアカウントの請求先住所によるものか、接続元IPのリアルタイム判定によるものか分からない」と書いた。
今回使ったAWSアカウントの請求先住所は東京の自宅に設定してある。
それでも香港のWi-Fiから接続した瞬間、Anthropicモデルは一貫して弾かれた。
つまり、Bedrockも接続元のネットワークロケーションを見ているということだろう。
請求先住所さえサポート対象国にしておけば安全、という単純な話ではなかった。
リージョンを変えても無駄だった
東京・シンガポール・台北のいずれでも、Anthropicモデルは同じ理由で一貫してブロックされた。
前回の記事で「リージョン選択は地域制限の判定軸ではなく、アカウントの所在地登録が本質」と書いたが、正確には所在地登録だけでも足りず、接続元も見られている。
どのリージョンを選ぶかは今回の問題を回避する手段にはならない。
ブロックされるのはプロプライエタリモデルだけ
今回の検証でもうひとつはっきりしたのが、ブロックの対象がきれいに分かれていたこと。
- Anthropic Claude系(Haiku 4.5、Sonnet 5、Opus 4.5)→ 全滅
- OpenAI GPT-5.6系(プロプライエタリなホスト型モデル)→ 全滅
- OpenAIのgpt-oss-120b(オープンウェイトモデル)→ 東京で普通に応答が返ってきた
- Kimi K2.5(Moonshot AI)→ 東京で普通に応答が返ってきた。「Kimiとして正常に動作しています」という自己紹介まで返してきた
- Nova Pro(Amazon自社モデル)→ 台北で普通に応答が返ってきた
同じBedrock上に並んでいても、モデルの提供形態によって扱いがまったく違う。
AnthropicとOpenAIが自社のクローズドモデルに課している地域制限は、モデルの重みが公開されているオープンウェイト系や、Amazonが自前でホストしているモデル、中国発のモデルには及ばない。
前回の記事で「中華系AIは米国の輸出管理規制の対象外だから制限がない」と書いた予測が、Kimi K2.5の実測でそのまま裏付けられた形になる。
platform.claude.comが東京でもバージニア北部でも白紙になった
もうひとつ気になったのが、AWSマネジメントコンソール内の「Claude on Bedrock」からリンクされているplatform.claude.com/partner-loginというページ。ここは東京リージョンを見ていてもバージニア北部リージョンを見ていても、香港のWi-Fiからだと真っ白なまま何も表示されなかった。
Bedrockのリージョン設定を変えてもこのページの挙動が変わらないということは、これはBedrock側の地域判定とは別に、platform.claude.comというAnthropic直営ドメイン自体が香港IPを弾いている可能性が高い。
前回の記事で紹介した「Claude Code CLIをBedrockバックエンドに設定していても、テレメトリやoauth関連の通信が裏で直接api.anthropic.comに飛ぶことがある」という話(openclaw/openclaw#30672)と地続きの現象だと思う。Bedrock経由だからといって、Anthropicのドメインへの依存を完全に断ち切れているわけではないらしい。
なお、途中でBedrockコンソール自体が「Something went wrong. Try reloading the page」というエラーで一度落ちた場面もあった。これは地域ブロックのエラー文言とは違う一般的なエラーだったので、地域制限が原因なのか単なる一時的な不調だったのかは切り分けられていない。
まとめ
香港空港からの実測で分かったのは、次の3点。
- Bedrock経由でも、Anthropic・OpenAIそれぞれのプロプライエタリモデルには接続元ベースの地域ブロックがそのまま乗る。
請求先住所がサポート対象国でも回避できない - リージョンを東京・シンガポール・台北のどれに変えても結果は同じ。
リージョン選択は回避策にならない - ブロックされるのはクローズドなプロプライエタリモデルだけで、オープンウェイトモデル(gpt-oss)、Amazon自社モデル(Nova)、中華系モデル(Kimi)は無傷
前回「誰か実測したら教えてほしい」と書いたら、まさか自分が同じ空港に戻ってきて実測することになるとは思わなかった。
次に香港を経由することがあれば、今度はus-west-2あたりも試してみたい。
最後まで読んでいただきありがとうございました。