Vertex AIの東京リージョンで何が使えるのか｜エンドポイントとデータレジデンシーの実際

こんにちは、株式会社TIMEWELLの濱本です。

先日、国内リージョンでLLMを動かすという記事で、クラウド各社の公式ドキュメントを読み比べました。公開したあとで一番反応が多かったのが、Google Cloudの「エンドポイントはデータレジデンシーもリージョン内でのML処理も保証しない」という一文です。「では東京リージョンを指定する意味はどこにあるのか」という質問を、複数の方からいただきました。

もっともな疑問だと思います。そこで今回は対象をGoogle Cloudだけに絞り、東京（asia-northeast1）で実際に何が呼べるのか、日本国内での処理がどこまで確約されているのかを、公式ドキュメントの原文に当たって整理しました。

先に結論を書きます。この2つは一致しません。東京のエンドポイントで呼べるモデルの一覧と、日本でのML処理が確約されるモデルの一覧は、別のページにある別の表で、中身がずれています。前者だけを見て「東京で使えるから国内で処理されている」と社内説明をすると、監査や委託先審査で崩れます。ずれの中身まで含めて、以下に書きます。

本文の内容は2026年9月6日に取得した公式ドキュメントに基づきます。モデルの提供状況は動きますので、実際の検討では必ず最新版を確認してください。自社の体制がどこまで整っているかを先に把握したい方には、AI活用レディネスの無料診断を用意しています。

東京エンドポイントで呼べるのは、7つのモデルだけ

本題に入る前に、ひとつ前提を共有しておきます。ドキュメントを開こうとして戸惑った方もいるかもしれませんが、製品名が変わりました。従来の /vertex-ai/generative-ai/docs/learn/locations にアクセスすると、HTTP 301で /gemini-enterprise-agent-platform/resources/locations へ転送されます。転送先のページ表題は「Deployments and endpoints」です。改称表には「Vertex AI Platform」が「Gemini Enterprise Agent Platform」に、「Generative AI on Vertex AI」が「Generative AI on Gemini Enterprise Agent Platform」に、「Vertex AI API」が「Gemini Enterprise Agent Platform API」になったことが並んでいます¹。社内規程やアーキテクチャ図に旧名が残っている場合、この対応表を見ながら読み替える必要があります。

そのロケーション文書のアジア太平洋の表を見ていきます。列はムンバイ（asia-south1）、シンガポール（asia-southeast1）、香港（asia-east2）、台湾（asia-east1）、東京（asia-northeast1）、シドニー（australia-southeast1）、ソウル（asia-northeast3）の7つです。Googleモデルの行は全部で37あり、そのうち東京の列に対応印が立つのは7件でした²。

具体的には、Gemini 3.5 Flash、Gemini 2.5 Pro、Gemini 2.5 Flashの3つに、Virtual Try-On、そして埋め込み系のgemini-embedding-001、Embeddings for Text、Embeddings for Multimodalです。Geminiのテキストモデルは3つ、埋め込みが3つ、画像系のユーティリティが1つ。これで打ち止めです。

裏返すと、残る30行はすべて東京では提供されていません³。Geminiの新しい系列であるGemini 3.8 Flash、3.7 Flash、3.6 Flash、3.5 Flash-Lite、3.1 Flash-Lite、3.1 Proのプレビュー、3 Flashのプレビュー、Omni系。画像生成の3 Pro Image、3.1 Flash Image、3.1 Flash-Lite Image、2.5 Flash Image。2.5 Flash-Liteと、Live APIのネイティブ音声。動画のVeo 3系はすべて。音声認識のChirp 2および3と、音声合成のTTS系もすべて。埋め込みの次世代であるGemini Embedding 2も入っていません。

ここで注意したいのは、これが東京だけの事情ではないという点です。たとえばGemini 3.8 Flashは、アジア太平洋の7リージョンすべてで空欄でした。Veo 3系の5行とTTSの3行も、7リージョン全部で空です。Chirp 2と3の4行にいたっては、アジア太平洋ではシンガポールにしか印がありません。つまり「東京が冷遇されている」という話ではなく、新しいモデルほど限られた場所に集約して運用されているという構図です。

GPUの供給には制約があり、需要の密度も地域で違います。最新モデルを世界中のリージョンへ薄く広げるより、まとまった場所で運用するほうが安定して速く出せる。提供側の判断としては合理的ですし、実際その判断のおかげで新しいモデルが早く世に出ているという側面もあります。ただ利用者側から見ると、東京を指定した瞬間に選べるモデルが7つになる、という制約が残ります。この制約は誰かの怠慢ではなく、構造として存在しているものだと捉えたほうが、対策を立てやすいと思います。

日本でML処理が確約されるのは、別の表にある8項目

ここからが、この記事で一番書きたかった部分です。

「東京で呼べるモデル」の表とは別に、データレジデンシーの文書があり、そこにML processingに関する別の表が置かれています⁴。この表は、どのモデルのどの構成について、どの法域内でML処理が行われることが確約されているかを示すものです。列は米国やEUのマルチリージョンを含めて13あり、行は27。その中に日本（asia-northeast1）の列があります。

日本の列に印が立つのは、次の8項目でした⁵。Gemini 3.5 Flash、Gemini 2.5 Flashの128kコンテキスト構成、Gemini 2.5 Proの64kコンテキスト構成、Chirp 3のTranscription、Chirp 3のHD Voices、Chirp 3のInstant Custom Voice、そしてEmbeddings for Textのうちtext-embedding-004とtext-multilingual-embedding-002。この8つです。

前の節で挙げた7モデルと、見比べてみてください。数も中身も違います。

コンテキスト長で線が引かれている

まず目を引くのは、モデル単位ではなくコンテキスト長単位で線が引かれていることです。Gemini 2.5 Flashは128k構成には日本の印がありますが、1M構成には印がありません。1M構成に印が立っているのは米国、EU、ブラジル、シンガポールだけです。Gemini 2.5 Proも同じで、64k構成には日本の印があり、1M構成にはありません。こちらは米国、EU、ブラジルの3つだけです。

これは実装に直結する話です。同じモデルIDを呼んでいても、長いコンテキストを投げる構成にした途端、日本国内でのML処理確約の対象から外れる可能性がある、ということになります。長大な社内文書をまとめて投げる設計は、性能面では自然な選択ですが、レジデンシーの観点では別の判断が要ります。モデルを選んだ時点で確認を終わらせず、コンテキスト長の構成まで含めて表と突き合わせる必要があります。

2つの表は、こうずれている

2つの表を突き合わせると、次の3つのグループに分かれます。

第一に、東京で呼べて日本のML処理確約もあるもの。Gemini 3.5 Flash、Gemini 2.5 Flashの128k構成、Gemini 2.5 Proの64k構成、Embeddings for Textのtext-embedding-004とtext-multilingual-embedding-002です。ここが実質的に「東京だけで完結する」と説明できる範囲になります。

第二に、東京で呼べるのに日本のML処理確約がないもの。gemini-embedding-001とEmbeddings for Multimodalは、ML processingの表では米国とEUのマルチリージョンにしか印がありません。Virtual Try-Onにいたっては、データレジデンシーの表に行自体が存在しません。埋め込みは検索基盤やRAGの土台になる処理で、社内文書の中身がそのまま通る場所です。ここが確約の外にあることは、設計上けっこう効きます。

第三に、逆のパターンもあります。Chirp 3の3項目は日本のML処理確約の対象に入っていますが、ロケーション文書のアジア太平洋の表では東京に印がありません。先ほど触れたとおり、アジア太平洋で印があるのはシンガポールだけです。確約はあるのに東京のエンドポイントからは呼べない、という状態です。

保存データについては話が単純です。文書には「顧客が選んだロケーションに保存されたデータは、その顧客のリクエストがどのAgent Platformエンドポイントを呼んだかとは独立に、そのロケーションに留まる」と書かれています。別の箇所でも、カスタムモデルの重みやメタデータのような保存物は、どのエンドポイントでモデルを呼んだかにかかわらず、選んだGoogle Cloudのロケーションに物理的に保存され続ける、と説明されています⁶。保存と処理は別の話として整理されている、と読むのが正確です。

エンドポイントの書き分けと、ページ冒頭に置かれた但し書き

ではエンドポイントそのものは、どう区別されているのか。ロケーション文書には、リージョン指定のエンドポイントとグローバルエンドポイントの2つの書き方が示されています⁷。

リージョン指定の場合は https://{LOCATION}-aiplatform.googleapis.com/v1/projects/{PROJECT}/locations/{LOCATION}/publishers/google/models/{MODEL_ID}:generateContent の形になります。東京なら asia-northeast1-aiplatform.googleapis.com です。グローバルの場合は https://aiplatform.googleapis.com/v1/projects/{PROJECT}/locations/global/publishers/google/models/{MODEL_ID}:generateContent となり、ホスト名にリージョンの接頭辞が付きません。ドキュメントには「グローバルエンドポイントを使うときは、https://${GOOGLE_CLOUD_LOCATION}-aiplatform.googleapis.com を前置したサービスエンドポイントの代わりに、こちらを使う」と書かれています。

グローバルエンドポイントの位置づけについては、こう説明されています⁸。

Selecting a global endpoint for your requests can improve overall availability while reducing resource exhausted (429) errors. Don't use the global endpoint if you have ML processing requirements, because you can't control or know which region your ML processing requests are sent to when a request is made.

可用性が上がり、リソース枯渇による429エラーが減る。運用していると429は本当に厄介なので、この利点は小さくありません。ただし後半で、ML processingの要件がある場合は使うなと明言し、その理由として、リクエスト時にどのリージョンへ処理が送られるかを制御することも把握することもできない点を挙げています。制御できないだけでなく「把握もできない」と書かれているのが重要で、事後に監査へ提出する記録も作れない、ということになります。

そしてもうひとつ、位置に意味がある注記があります。ロケーション文書の本文構造を確認すると、記事本体の冒頭に導入の段落が3つ置かれ、その直後、最初のH2見出しよりも前に、次のImportant注記が入っています⁹。

Important: Endpoints don't guarantee data residency or in-region ML processing.

置かれている場所からして、これは特定のモデルや特定のリージョンに紐づいた但し書きではありません。導入段落の直後、最初の見出しの前という位置は、この後に続くすべてのリージョン表に係る総括的な注意書きだと読むのが自然です。エンドポイントの選択それ自体は、データレジデンシーもリージョン内でのML処理も保証しません。詳しくはデータレジデンシーの文書を見てほしい、という導線です。この一文を読み飛ばして表だけを見ると、冒頭に書いた誤解がそのまま社内資料に載ります。

グローバルエンドポイントでできないこと

機能面の制約もあります。同じ文書には、グローバルエンドポイント利用時に使えない機能として、チューニング、AnthropicおよびOpenMaaSモデルのバッチ予測、RAGコーパスの3つが挙げられています¹⁰。RAGについては、コーパスが使えないだけでリクエスト自体はサポートされる、という書き分けがされています。またProvisioned Throughputとの併用は、Gemini 3.8 Flashから2.5 Flash-Liteまでの15モデルに限られると、折りたたみの表で示されています。

可用性を取ってグローバルへ寄せると、これらが落ちる。逆にチューニングやRAGコーパスを使う構成なら、そもそもグローバルエンドポイントは選べません。可用性と機能とレジデンシーが三すくみになっている、というのが実態に近い表現だと思います。

法域を指定できるエンドポイントは、米国とEUにしかない

処理の場所を法域単位で縛りたい、というニーズには専用の仕組みが用意されています。管轄マルチリージョンエンドポイントです。ドキュメントには「マルチリージョンエンドポイントは、サービスによるCustomer Dataの機械学習処理が、米国や欧州連合といった特定の法域の境界内に留まることを保証できるようにするものだ」と書かれています¹¹。

要件から見ると、これがまさに欲しい機能です。ところが提供されているホスト名の表には2行しかありません。米国が us で https://aiplatform.us.rep.googleapis.com、欧州連合が eu で https://aiplatform.eu.rep.googleapis.com。この2行で終わりです。RESTのサンプルコードにも、ロケーションは us か eu でなければならないという注記が付いています。日本向けはもちろん、アジア向けの管轄エンドポイントも存在しません。

つまり日本のユーザーが取れる選択肢は、東京のリージョン指定エンドポイントを使うところまでです。ML processingの節では、ロケーショナルエンドポイントについて、当該リージョンが属する広域のマルチリージョンまたは国の法域内に処理を留めると説明されており、グローバルエンドポイントについては地域の分離もデータレジデンシーの保証も提供しないと書かれています⁴。同じ節には、EUのマルチリージョンには英国とスイスが含まれないというNoteや、米国マルチリージョン対応が明示されていないモデルはDoD IL5のコミットメントを満たさないというImportantも添えられています。ロケーショナルエンドポイントでもGDPRやHIPAAといった標準的な要件は満たせるが、DoD IL5やITARには管轄エンドポイントの利用が推奨される、という整理です。

もうひとつ、ネットワーク設計に効く記述があります。管轄マルチリージョンエンドポイントはPrivate Google Accessに対応していません¹²。対応していないだけでなく、Private Google Accessで接続しようとすると接続性の問題やSSL/TLSハンドシェイクのエラー、証明書の不一致の警告が起きうると明記されています。プライベート接続を確立するには、リージョナルなGoogle API向けのPrivate Service Connectエンドポイントを構成する必要があります。閉域構成を前提にしている企業ほど、管轄エンドポイントへの移行は設計変更を伴います。日本の場合はそもそも管轄エンドポイントが無いので直接の影響はありませんが、グローバル展開する企業が米国やEUの拠点で使う場合には、先に確認しておきたい項目です。

パートナーモデルとオープンモデルは、東京にひとつもない

ここまでGoogleのモデルを見てきましたが、Vertex AIの魅力のひとつは、他社のモデルを同じ基盤から呼べることです。Anthropic、Mistral、xAIといったパートナーモデルと、各種のオープンモデルが、同じAPIの下に並んでいます。

アジア太平洋のパートナーモデル表は26行あり、内訳はAnthropic Claudeが16行、Mistralが6行、Grokが4行です。この26行すべてについて、東京の列は空でした¹³。対応印が立っているのは、シンガポールの8行と台湾の2行の、合わせて10セルだけです。シンガポールの8行はClaude Sonnet 5、Claude Opus 5、Claude Fable 5、Claude Opus 4.6、Claude Opus 4.5、Claude Sonnet 4.6、Claude Sonnet 4.5、Claude 3 Haiku。台湾の2行はClaude Haiku 4.5とClaude Sonnet 4です。MistralとGrokは、アジア太平洋のどのリージョンにも印がありません。

オープンモデルの表は15行で、こちらも東京の列は全行が空です。ひとつ補足しておくと、この表にはDeepseek modelsという見出し行が置かれていますが、その下に実際のモデル行は1件もありません。「表に列挙されているが東京では使えない」というより、アジア太平洋の表では配下のモデルが示されていない状態です。細かい話ですが、社内資料に転記するときに事実がずれやすい箇所なので書いておきます。

さらに構造的な話として、データレジデンシー文書のパートナーモデル表とオープンモデル表には、そもそも日本の列が存在しません⁵。パートナーモデル表の列は米国とEUのマルチリージョン、ベルギー、オランダ、シンガポール、台湾、グローバル。オープンモデル表の列は米国とEUのマルチリージョン、シンガポール、グローバルです。Googleモデルの表には日本の列があるのに、パートナーとオープンの表には無い。ここが意味するのは、Claude、Mistral、Grok、各種オープンウェイトについては、日本でのML処理確約が現時点では構造的に用意されていない、ということです。「今は東京に無いが、いずれ来るだろう」と待つ話ではなく、確約の枠組み自体が別建てになっている、と理解したほうがよいと思います。

この事実は、モデル選定の自由度をそのまま制約します。国内処理を要件に据えると、選べるのはGoogleモデルの一部だけになります。逆に、モデルの多様性を優先するなら、処理場所についての説明を別の形で用意しなければなりません。私たちがZEROCKでエンタープライズ向けの構成を設計するときも、この二者択一を最初に確定させるところから始めます。どちらが正しいという話ではなく、先に決めておかないと後から設計をやり直すことになるからです。

何を確認し、何を組織ポリシーで塞ぐか

最後に、実務でどう扱うかを書きます。

グローバルエンドポイントを使わせたくない場合、組織ポリシーで塞ぐ手段があります。制約IDは constraints/gcp.restrictEndpointUsage です¹⁴。この制約は拒否リスト方式で、明示的に拒否されていないサポート対象サービスのAPIエンドポイントへのリクエストは許可される、と説明されています。対象サービスの一覧には「Generative AI on Gemini Enterprise Agent Platform」が含まれ、グローバルAPIエンドポイントとして aiplatform.googleapis.com、ロケーショナルAPIエンドポイントとして asia-northeast1-aiplatform.googleapis.com を含む一覧が示されています。したがって、グローバルを拒否して東京のロケーショナルだけを許可する運用は、技術的に可能です。

ただし同じページに、見落とせない一文があります。「Restrict Endpoint Usage制約を含む組織ポリシーは、データレジデンシーのコミットメントではない」と明記されているのです。グローバルなエンドポイント一般についても、これらのエンドポイントは地域の分離もデータレジデンシーのコンプライアンスも提供しない、と書かれています。組織ポリシーはあくまで意図しない呼び出しを止める仕組みであって、処理場所の約束ではありません。この線引きは、監査で説明するときに効いてきます。ポリシーを入れたことをもって要件充足の根拠にすると、そこを突かれます。

そのうえで、私が確認する順番を書いておきます。まずロケーション文書の表で、使いたいモデルが東京で提供されているかを見ます。次にデータレジデンシー文書のML processing表で、そのモデルに日本の印があるかを見ます。この2つが揃って初めて「東京だけで完結する」と言えます。3番目に、コンテキスト長の構成が印の付いている側かどうかを確認します。4番目に、実装コードのホスト名を確認し、SDKの既定値でグローバルへ飛んでいないかを見ます。5番目に、組織ポリシーでグローバルを塞ぎます。そして最後に、それでも残る前提と限界を文書に残します。

順番を逆にすると、たいてい破綻します。組織ポリシーを先に入れて安心し、あとからモデルの表を見て「そもそも東京には無かった」と気づく。これは実際によくある流れです。

確認すべきは「東京で呼べるか」ではなく、「東京で呼べて、かつ日本での処理が確約されているか」の2段構えです。 そしてこの2つが一致していない以上、片方だけで判断すると必ずどこかで齟齬が出ます。Googleがこれを分かりにくくしているわけではなく、両方とも公式ドキュメントに明記されています。読む側が、2枚の表を突き合わせる手間をかけるかどうかの問題です。

私自身は、この構造を悲観していません。むしろ、確約の範囲がモデル単位・コンテキスト長単位まで細かく公開されていること自体が、他ではなかなか得られない情報だと思っています。困るのは、情報が無いことではなく、情報があるのに読まれないまま「東京にしたので大丈夫です」という一行が社内を通ってしまうことのほうです。自社の要件がどこまでを求めているのか、いま動いている構成がその範囲に入っているのか。この2つを一度突き合わせてみると、次に決めるべきことがはっきりします。構成の相談があれば、個別相談からお声がけください。

Footnotes

1. Google Cloud「Vertex AI name changes」Gemini Enterprise Agent Platform ドキュメント（ページ表示 Last updated 2026-09-02 UTC）。「With the introduction of Gemini Enterprise Agent Platform, some Vertex AI products and features have been renamed. The following table lists the previous and new names.」および改称表の各行は同ドキュメントによる。旧URL /vertex-ai/generative-ai/docs/learn/locations から /gemini-enterprise-agent-platform/resources/locations への転送（HTTP 301）は2026年9月6日に実測。 https://docs.cloud.google.com/gemini-enterprise-agent-platform/vertex-ai-name-changes ↩

2. Google Cloud「Deployments and endpoints」Gemini Enterprise Agent Platform ドキュメント、Asia Pacific の表（ページ表示 Last updated 2026-09-03 UTC）。Googleモデル37行のうち Tokyo (asia-northeast1) 列に対応印が立つ7件は、2026年9月6日に同ページのHTMLを取得して全行を照合した。表のヘッダはMumbai (asia-south1)、Singapore (asia-southeast1)、Hong Kong (asia-east2)、Taiwan (asia-east1)、Tokyo (asia-northeast1)、Sydney (australia-southeast1)、Seoul (asia-northeast3)。 https://docs.cloud.google.com/gemini-enterprise-agent-platform/resources/locations#asia-pacific ↩

3. 同上、Asia Pacific の表。東京列が空の30行、および Gemini 3.8 Flash がアジア太平洋7リージョンすべてで空であること、Veo 3系5行とTTS系3行が同7リージョンすべてで空であること、Chirp 2および3の4行がシンガポールのみ対応であることは、いずれも2026年9月6日の取得時点のセル単位の照合による。 https://docs.cloud.google.com/gemini-enterprise-agent-platform/resources/locations#asia-pacific ↩

4. Google Cloud「Data residency」Gemini Enterprise Agent Platform ドキュメント、「2. ML processing (in-use)」節（ページ表示 Last updated 2026-09-02 UTC）。「The geographic location of this processing is determined by your choice of endpoint」以下、ロケーショナルエンドポイントとグローバルエンドポイントの各記述、EUマルチリージョンに英国およびスイスが含まれない旨のNote、「Models not explicitly listed as supporting US multi-regions don't meet DoD IL5 commitments」のImportant、ロケーショナルエンドポイントとGDPR・HIPAA・DoD IL5・ITARの関係についての記述は同節による。 https://docs.cloud.google.com/gemini-enterprise-agent-platform/resources/data-residency#ml-processing ↩ ↩²

5. 同「Data residency」、Googleモデルの ML processing 表。27行13列のうち Japan (asia-northeast1) 列に印が立つ8項目、Gemini 2.5 Flash の128k構成と1M構成の差（1MはUS・EU・Brazil・Singaporeのみ）、Gemini 2.5 Pro の64k構成と1M構成の差（1MはUS・EU・Brazilのみ）、およびパートナーモデル表とオープンモデル表に Japan 列が存在しないことは、2026年9月6日の取得時点の全セル照合による。パートナーモデル表の列はUS/EUマルチリージョン、Belgium、Netherlands、Singapore、Taiwan、Global。オープンモデル表の列はUS/EUマルチリージョン、Singapore、Global。 https://docs.cloud.google.com/gemini-enterprise-agent-platform/resources/data-residency#ml-processing-google-models ↩ ↩²

6. 同「Data residency」。「Data stored at rest in the customer selected location remains at rest in that location, independent of the Agent Platform endpoint called by that customer's request.」（導入部）および「When you store data on Agent Platform (such as custom model weights or metadata), it remains physically stored in the specific Google Cloud location you chose. This residency is maintained regardless of which endpoint you use to call the model.」（「1. Data-at-rest (storage)」節）による。 https://docs.cloud.google.com/gemini-enterprise-agent-platform/resources/data-residency ↩

7. 同「Deployments and endpoints」、「Specify an endpoint」節のRESTタブ。リージョン指定エンドポイントとグローバルエンドポイントのURL形式、および「When using the global endpoint, use https://aiplatform.googleapis.com/v1/projects/${GOOGLE_CLOUD_PROJECT}/locations/global/publishers/google/models/${MODEL_ID}:generateContent instead of a service endpoint prepended with https://${GOOGLE_CLOUD_LOCATION}-aiplatform.googleapis.com.」の注記は同節による。 https://docs.cloud.google.com/gemini-enterprise-agent-platform/resources/locations#specify_an_endpoint ↩

8. 同「Deployments and endpoints」、「Global endpoint」節。「Selecting a global endpoint for your requests can improve overall availability while reducing resource exhausted (429) errors. Don't use the global endpoint if you have ML processing requirements, because you can't control or know which region your ML processing requests are sent to when a request is made.」による。 https://docs.cloud.google.com/gemini-enterprise-agent-platform/resources/locations#global-endpoint ↩

9. 同「Deployments and endpoints」。「Important: Endpoints don't guarantee data residency or in-region ML processing. For information about data residency, see Data residency.」の注記は、記事本文の導入段落（3つ）の直後、最初のH2見出し「Specify an endpoint」より前に置かれている。掲載位置は2026年9月6日にページのDOM構造を確認した。 https://docs.cloud.google.com/gemini-enterprise-agent-platform/resources/locations ↩

10. 同「Deployments and endpoints」、「Limitations」節。「The following capabilities are not available when using the global endpoint: Tuning / Batch prediction for Anthropic and OpenMaaS models / Retrieval-augmented generation (RAG) corpus (RAG requests are supported)」および「Usage of the global endpoint with Provisioned Throughput is available only for the following models」に続く折りたたみ表（Gemini 3.8 Flash から Gemini 2.5 Flash-Lite までの15モデル）による。 https://docs.cloud.google.com/gemini-enterprise-agent-platform/resources/locations#limitations ↩

11. 同「Deployments and endpoints」、「Multi-region endpoints」節。「Multi-region endpoints allow you to ensure that machine learning processing of Customer Data by the service stays within a specific jurisdictional boundary, such as the United States or the European Union.」およびホスト名表の2行（United States / us / https://aiplatform.us.rep.googleapis.com、European Union / eu / https://aiplatform.eu.rep.googleapis.com）、RESTサンプル中の「GOOGLE_CLOUD_LOCATION="..." # Must be 'us' or 'eu'」による。 https://docs.cloud.google.com/gemini-enterprise-agent-platform/resources/locations#multi-region_endpoints ↩

12. 同「Deployments and endpoints」、「Private connectivity to multi-region endpoints」節。「Private Google Access isn't supported for multi-region endpoints. If you attempt to connect to a multi-region endpoint using Private Google Access, you might experience connectivity issues, SSL/TLS handshake errors, or certificate mismatch warnings. To establish private connectivity to multi-region endpoints, you must configure Private Service Connect endpoints for regional Google APIs.」による。 https://docs.cloud.google.com/gemini-enterprise-agent-platform/resources/locations#multi-region_endpoints ↩

13. 同「Deployments and endpoints」、Asia Pacific のパートナーモデル表およびオープンモデル表。パートナーモデル26行（Anthropic Claude 16行、Mistral 6行、Grok 4行）とオープンモデル15行のいずれもTokyo列が全行空であること、対応印がSingaporeの8行とTaiwanの2行の計10セルであること、オープンモデル表の「Deepseek models」が見出し行のみで配下のモデル行を持たないことは、2026年9月6日の取得時点の全セル照合による。 https://docs.cloud.google.com/gemini-enterprise-agent-platform/resources/locations#genai-partner-models ↩

14. Google Cloud「Restrict Endpoint Usage」（2026年9月6日取得。同ページに更新日の表示は確認できなかった）。制約ID constraints/gcp.restrictEndpointUsage、「The Restrict Endpoint Usage constraint is set using a denylist, allowing requests to any supported services' API endpoints that are not explicitly denied.」、「Organization policies that contain the Restrict Endpoint Usage constraint are not data residency commitments.」、対象サービスに「Generative AI on Gemini Enterprise Agent Platform」が含まれること、グローバルAPIエンドポイント aiplatform.googleapis.com とロケーショナルAPIエンドポイント asia-northeast1-aiplatform.googleapis.com の記載、およびグローバルエンドポイント一般についての「these endpoints don't provide any regional isolation or data residency compliance」の記述は同ページによる。 https://docs.cloud.google.com/docs/security/compliance/restrict-endpoint-usage ↩