AnthropicとOpenAIの両取り──AWSが選んだ中立プラットフォーマーの道

2024年から2025年にかけて、AWSには「AIで出遅れた」という評価がついて回っていました。自社にフロンティアモデルがなく、Amazon Novaの存在感は薄く、成長率ではMicrosoft AzureとGoogle Cloudに見劣りする。生成AIの主戦場はクラウド1位の座を守ってきたAWSの外側で動いている——そういう見方です。

ところが2026年に入って、この構図は数字の上で大きく崩れました。AWSの四半期成長率は5四半期連続で加速し、直近では前年同期比36.7%に達しています。同時にAWSは、出資先であるAnthropicと、競合Microsoftの牙城だったOpenAIの両方を抱え込むという、他社にはないポジションを手に入れました。

本記事の結論を先に述べます。AWSの強みは「自社でモデルを作れること」ではなく、「誰のモデルでも動かせるインフラと調達力を持つこと」に移りました。逆に弱点も明確で、最大の資産であるAnthropicが意図的にマルチクラウド化を進めており、AWSはもはや「Anthropicの独占的パートナー」ではありません。以下、財務・シリコン・モデル・エージェント・日本市場の順に、一次情報を軸に整理していきます。

本記事には2026年から2028年にかけての見通しに関する記述が含まれます。将来予測の部分は筆者の推定であり、精密な予測ではありません。事実として確認できた事項と、推定・見通しは文中で区別して記載しています。また、性能値や価格性能比のうちベンダー自身の発表に基づくものは、その旨を明記しています。数値はいずれも2026年8月時点で確認できたものです。

1. 数字で見る現在地——「AIで出遅れた」論の検証

まず財務から見ていきます。Amazonの2026年度第2四半期（4〜6月）決算で、AWSセグメントの売上は422億ドル、前年同期比36.7%増でした。営業利益は166億ドル、営業利益率は39.4%で、前年同期の32.9%から650ベーシスポイント改善しています。Andy Jassy CEOはこれを「18四半期ぶりの最速成長」と表現しました。

四半期	AWS売上	前年同期比	補足
2025年 第3四半期	—	20%	加速の起点
2025年 第4四半期	356億ドル	24%	営業利益125億ドル。年換算ランレート1,420億ドル
2026年 第1四半期	376億ドル	28%	バックログ3,640億ドル
2026年 第2四半期	422億ドル	36.7%	営業利益166億ドル・利益率39.4%。バックログ4,960億ドル、年換算ランレート1,690億ドル

注目すべきは契約残高（バックログ）です。第1四半期の3,640億ドルから第2四半期の4,960億ドルへ、1四半期で1,320億ドル積み増しました。AI事業と自社チップ事業は、それぞれ年換算250億ドル超のランレートに到達しています。

一方で、弱気材料も同じ決算に含まれています。Amazon全体の設備投資は2026年当初ガイダンスの約2,000億ドルから、7月30日の決算発表時に約2,200億ドルへ上方修正されました。理由としてメモリなど部材コストの上昇とAI需要が挙げられています。この重い投資の結果、トレーリング12か月のフリーキャッシュフローは約76億ドルのマイナスに転落しました。前年は182億ドルのプラスでしたから、反転の幅は小さくありません。

もうひとつ、決算を読むうえで注意すべき点があります。第2四半期の純利益には、非営業・税引前で534億ドルという巨額の「その他収益」が計上されており、その大半はAnthropicへの投資に対する時価評価益です。つまりAmazonの純利益はAnthropicの企業価値上昇によって大きく膨らんでおり、本業の収益力とは切り分けて評価する必要があります。この評価益は会計上の未実現利益であり、Anthropicの評価額が下がれば逆方向に振れます。

Jassyは2025年の株主書簡で「AIはバブルか、マージンとROICは魅力的か」という問いに対し「バブルではない、魅力的だ」という趣旨の回答を示しています。2025年に3.9GWのデータセンター容量を追加し、2027年末までに総電力容量を倍増させる計画も明言しました。ただし「2026年も2027年も、全需要を満たす容量には届かない」とも述べており、需要超過が続いている状況を強調しています。

2. 独自シリコン——Trainium3とProject Rainier

AWSのAI戦略で最も差別化が効いているのはシリコンです。re:Invent 2025で発表・一般提供が開始されたTrainium3は、AWSにとって初の3nmプロセスAIチップになります。Trn3 UltraServerは最大144チップを搭載し、AWSの公表値ではTrainium2 UltraServer比で演算性能最大4.4倍、メモリ帯域3.9倍、電力効率約40%改善とされています。なお、この性能値はいずれもAWS自身の発表に基づくもので、独立した第三者によるベンチマーク検証は本稿執筆時点では確認できていません。

Trainium2の事業規模は、2025年第4四半期時点でTrainiumとGravitonを合わせた年換算ランレートが100億ドル超、前年比で三桁成長という水準でした。2026年第2四半期には自社チップ事業単独で250億ドル超のランレートに達しています。AWSは対競合GPU比で30〜40%の価格性能優位を主張していますが、これも自社評価であり、比較条件の詳細は公開されていません。

大規模実証の場となったのがProject Rainierです。2025年10月29日にフル稼働し、米国内の複数データセンターに約50万基のTrainium2を展開、2025年末までに100万基超への拡張が進みました。中核はインディアナ州New Carlisleのデータセンター群で、AWSの当該サイトへの投資は総額約110億ドル規模とされています。Anthropicのモデル学習・推論に充てられており、旧世代比で5倍超の学習演算力を提供します。

競合の自社シリコンと並べると、AWSの立ち位置がはっきりします。

ベンダー	チップ	外部提供	主張・特記（いずれもベンダー自己申告値を含む）
AWS	Trainium3（3nm）	AWS内のみ	T2比で演算最大4.4倍。Anthropic経由で100万基規模の外部実証を持つ点が他社と異なる
Google	TPU v7 Ironwood	外販あり	4社のうち外部から直接調達できる唯一の存在。Anthropicが最大100万基を契約
Microsoft	Maia 200	自社利用のみ	前世代比30%の価格性能改善を主張。開発遅延を経て量産
Meta	MTIA	自社利用のみ	推論優先。短サイクルでの反復開発

この表で実務上いちばん重要なのは「外部提供」の列です。Trainium・Maia・MTIAはいずれも自社クラウド内でしか使えず、顧客から見れば「そのクラウドを選ぶこと」とセットになります。TPUだけがBroadcom経由で外部にも供給される構造で、Anthropicは実際にBroadcomから直接TPUを調達する形をとっています。AWSがTrainiumの価格性能を訴求するとき、それは同時にAWSへのロックインを意味する——この両面性は提案時に押さえておくべき点です。

なお、AWSはNVIDIA GPUの併用も継続しています。2025年中にP6-B200、P6e-GB200、P6e-GB300が順次一般提供となり、GB300搭載のP6e-GB300 UltraServersは2025年12月にGAとなりました。「Trainiumで置き換える」のではなく「Trainiumという選択肢を追加する」のが実態です。

3. Anthropicという両義的な資産

AWSのAI戦略を語るうえで避けて通れないのがAnthropicです。ここは「最大の資産」であると同時に「最大のリスク」でもある、という両義性を丁寧に見る必要があります。

まず数字を押さえます。Anthropicの年換算収益ランレートは、2025年末の約90億ドルから2026年2月に140億ドル、3月に190億ドル、4月に300億ドル、5月に470億ドル、そして7月末に650億ドル超へと駆け上がりました。1年前の約7倍です。同社は2026年6月にSECへ非公開でIPO申請を行っており、上場は2026年後半が見込まれています。この急拡大が、Amazonの決算に計上された巨額の評価益の源泉です。

問題は、Anthropicへの資本と計算資源の供給者がAWSだけではないことです。2026年4月、わずか4日間のあいだに次の2つの発表が並びました。

出資者	発表日	出資額	計算資源のコミットメント
Amazon	2026年4月20日	まず50億ドル、最大250億ドルまで追加（既存の累計80億ドルとは別枠）	AnthropicがAWSに10年で1,000億ドル超を支出、最大5GWの容量を確保
Google	2026年4月24日	まず100億ドル（評価額3,500億ドル）、業績目標達成で最大400億ドルまで	Google Cloudが5年で5GWを供給。Broadcom経由のTPU調達を含む三者契約の拡張

つまり金額ベースではGoogleのコミットメントのほうが大きいのが現状です。Anthropicは両社から合計10GW規模の計算資源を確保し、意図的にハードウェア中立を貫いています。GoogleのTPU契約規模については、公式には「数百億ドル規模（tens of billions）」という表現にとどまっており、一部で報じられた具体的な総額は本稿で一次情報まで辿れなかったため記載しません。

AWS側の資産価値が失われたわけではありません。Bedrock上でClaudeを利用する組織は10万社を超え、Project Rainierは実際に稼働しています。しかし「AnthropicはAWSの独占的パートナー」という2024年当時の物語はもう成立しません。ここは提案の場でも正確に伝えるべきポイントです。

見方を変えれば、世界最高水準のモデル2つ——ClaudeとGemini——が、それぞれTrainiumとTPUという非NVIDIAシリコンの上で動いている構図でもあります。NVIDIA一強に対する構造変化としては、こちらのほうが本質的かもしれません。

4. OpenAIの取り込み——Microsoft独占の終焉

2025年11月3日、AWSとOpenAIは7年・380億ドルのコンピュート契約を締結しました。そして2026年4月末、OpenAIとMicrosoftのクラウド独占契約が改定され、OpenAIモデルのBedrock展開への道が開きます。

時期	内容
2025年8月5日	オープンウェイトのgpt-oss-120b／20bがBedrockとSageMaker JumpStartで提供開始
2025年11月3日	AWS-OpenAIが7年・380億ドルのコンピュート契約を発表
2026年4月28日	パートナーシップ拡大を発表。OpenAIモデル・Codex等が限定プレビューで提供開始
2026年6月1日	GPT-5.5・GPT-5.4・CodexがBedrockでGA。価格はOpenAI直販レートと同一でAWSのマークアップなし、AWSの既存コミットメントを消化可能
2026年7月9日	GPT-5.6のSol／Terra／LunaがGA。3階層で能力とコストを使い分け可能に
2026年8月11日	サイバーセキュリティ特化のDaybreak Red／Blueが対象顧客向けに提供開始

実務的に効くのは価格と調達の設計です。BedrockのOpenAIモデルはOpenAI直販と同一価格で、AWSのEDPやSavings Plansのコミットメント消化に充当できます。さらに、すでにBedrockを使っている10万社超の組織は、新規ベンダーとの契約・請求経路・ガバナンスプロセスを増やさずにOpenAIモデルを使えるようになりました。日本企業のセキュリティ審査の実情を考えると、この「審査対象ベンダーを増やさない」という点は、性能比較以上に導入判断を左右することがあります。

なお技術的な制約もあります。BedrockのGPTモデルは当初Responses APIのみのサポートで、bedrock-mantleという専用エンドポイントを使う必要がありました。GPT-5.5の実効入力上限は272Kトークンです。移行を検討する際は、公式ドキュメントで現行の対応状況を確認してください。

5. Bedrockのモデル調達力とNovaの現在地

Bedrockの本質は「AWSのモデル」を売る場所ではなく、「あらゆるモデルを1つのAPI・IAM・課金で扱える場所」です。2026年時点のラインナップは、Anthropic（Claude）、OpenAI（GPT-5.5／5.6系、Codex、gpt-oss）、Meta Llama、Mistral、Cohere、AI21、Stability、DeepSeek、Qwenに加え、2026年3月にはGLM 5とMiniMax M2.5という中国系フロンティアモデルも追加されました。この品揃えの広さは3大クラウドの中で突出しています。

自社モデルのAmazon Novaについては、評価を分けて書く必要があります。re:Invent 2025で発表されたNova 2（Pro／Lite／Omni）は、前世代から大きく改善しました。第三者評価機関Artificial Analysisは、Nova 2について「以前のNovaモデルからの実質的なアップグレードで、特にエージェント能力に強みを示す」と評価しています。Nova 2 Omniはテキスト・画像・動画・音声を入力として扱えるネイティブなマルチモーダルモデルで、この構成を持つのはGemini系など少数です。

ただし、市場での実採用という観点では依然として存在感が薄いのが実情です。AWS自身のベンチマーク主張（Claude Sonnet 4.5やGPT-5.1に対し複数項目で同等以上）はありますが、これは自社評価であり、Bedrock上の実利用がClaude中心である構図は変わっていません。AWSは「自社モデルで勝つ」戦略を採っていない——この理解が正しいと考えます。Novaはコスト最適化用途の選択肢として位置づけるのが実務的です。

構造として3社を比較すると、戦略の違いが明確になります。

観点	AWS	Microsoft	Google
モデル戦略	マルチモデル（中立プラットフォーマー）	OpenAI依存が主軸、モデル中立へ拡大中	Gemini垂直統合
自社フロンティアモデル	なし（Novaは中位）	なし	あり（Gemini）
主要な外部依存	Anthropic（出資先）＋OpenAI（顧客）の両取り	OpenAI（RPOの相当部分を占めると報じられる）	自給自足＋AnthropicがTPU顧客
自社シリコンの外販	なし	なし	あり（TPU）
バックログの集中度	相対的に分散	OpenAIへの集中が指摘される	Anthropic向けの比重が上昇

6. エージェンティックAI——Q DeveloperからKiroへ

アプリケーション層では、2026年に大きな方針転換がありました。AWSは2026年4月30日、Amazon Q Developerの終息を公式に発表します。

• 2026年5月15日：Q Developerの新規サインアップ・新規サブスクリプション作成をブロック（既存契約への席追加は可能）
• 2026年5月29日：Q Developer ProからOpus 4.6を削除。最新のコーディングモデル（Opus 4.7等）はKiro専用に
• 2027年4月30日：IDEプラグインと有償サブスクリプションのサポート終了

影響範囲は限定されており、AWSマネジメントコンソール内のQ Developer、ドキュメント、モバイルアプリ、Slack／Teams統合は継続します。終了するのはVS Code・JetBrains・Eclipse・Visual Studioの各IDEプラグインと有償サブスクリプション、そしてコード変換機能（Javaバージョンアップ、.NET移植）です。

後継のKiroは、AWS自身が「スペック駆動開発のために一から構築したエージェンティック開発環境」と説明しています。プロンプトに逐次反応するのではなく、構造化された仕様（requirements・design・tasks）を先に生成し、それに基づいてコードベース全体の変更を計画・実装・検証する設計です。Specs、Hooks（ファイル保存やコミットをトリガとする自動処理）、Steering Files（プロジェクト規約でエージェントの挙動を制約する設定）が中核機能になります。Code OSSベースのためVS Code設定とOpen VSX拡張は引き継げますが、JetBrains・Eclipse・Visual Studioのネイティブプラグインには後継が用意されていません。

この点は日本のSI現場にとって無視できない摩擦です。JavaやC#／.NETを主軸とし、JetBrainsやVisual Studioを標準環境としている組織は、IDE標準そのものの見直しを迫られます。移行猶予は12か月ありますが、企業のセキュリティレビューと調達手続きを考えると、2026年度内に評価を始めておくのが現実的でしょう。あわせて、Q Developerのコード変換機能に依存したモダナイゼーション案件を抱えている場合、代替手段の確保が必要になります。

その他のエージェント関連では、Bedrock AgentCore（re:Invent 2025でGA、Policy／Memory／評価機能を追加）、業務横断のAmazon Quick（Microsoft 365、Google Workspace、Slack、Zoom等と連携するデスクトップアプリ）が柱になります。相互運用の面では、AgentCore・Kiro CLI・QuickがいずれもMCP（Model Context Protocol）に対応しており、AWSは独自プロトコルで囲い込む方向を採っていません。コンシューマ側では、買い物アシスタントのRufusや音声アシスタントのAlexa+がBedrock／Nova上で動いています。

7. 市場ポジション——成長率ではGoogle Cloudが上回る

シェアで見れば、2026年第1四半期時点でAWSが約28〜30%、Azureが約21〜25%、Google Cloudが約13〜14%です（Synergy Research系の集計。トラッカーにより数値に幅があります）。市場全体は四半期1,290億ドル規模で前年比約35%成長しています。

ただし成長率の絶対値では、Google Cloudが3社中最も高い水準にあります。2026年第1四半期に前年同期比63%増（200億ドル）、第2四半期には82%増（248億ドル）を記録しました。AWSの36.7%は「加速している」という点で評価すべき数字であって、「最も速い」わけではありません。もっとも、AWSは4倍以上大きい売上基盤の上でその成長率を出しているため、絶対額の増加ではAWSが依然として最大です。この2つの見方は両立します。

共通のボトルネックは電力です。AWSは2027年末までに電力容量を倍増させる計画ですが、Jassy自身が「全需要は満たせない」と認めています。この制約はどの事業者にも等しくかかっており、日本ではさらに厳しい形で現れます（次節）。

8. 日本市場——投資額で最大、ソブリンで劣後

日本におけるAWSの立ち位置は、「圧倒的な既存基盤」と「ソブリン領域での出遅れ」が同居する状態にあります。

投資額では、2024年1月に発表された2023〜2027年の2兆2,600億円（約149.6億ドル）が現行の基準です。2011〜2022年の累計1兆5,100億円と合わせると、2011〜2027年で約3兆7,700億円に達します。AWS自身の試算では、この投資が2023〜2027年の日本のGDPに5兆5,700億円貢献し、年平均3万500人以上の雇用を支えるとされています。2026年8月時点で、これを上回る新規の日本向け大型コミットは確認できていません。

2026年1月、AWSジャパンは新戦略「日本のために、社会のために、その先へ」を発表しました。白幡晶彦社長のもと、従来の「技術への投資」「人と社会への投資」に加えて「信頼性への投資」を新たな柱に掲げ、2つのリージョンの拡張計画も示しています。日本リージョンでのサービス開始から15年という節目に、公共・エンタープライズ領域を意識した打ち出しに舵を切った形です。

競合の日本投資と並べると、金額で最大なのはAWSですが、Microsoftが急速に差を詰めています。

ベンダー	投資額	対象期間	特記
AWS	2兆2,600億円（約149.6億ドル）	2023〜2027年	東京・大阪リージョン。2026年に2リージョンの拡張計画を発表
Microsoft	100億ドル（約1.6兆円）	2026〜2029年	2026年4月3日発表。既存DC増強と新設が中心。2030年までにAI人材100万人育成、国内SIer各社と連携
Oracle	80億ドル超	10年	ソフトバンク・NTTデータとのソブリンクラウド構築が軸

ただし、日本のデータセンター投資には資金では解けない制約があります。東京都心では電力会社からの給電開始まで5〜10年待ちという状況が生じており、大阪エリアでは2026年から4つの変電所のアップグレードに1,500億円以上が投じられる予定です。この制約を回避するため、MicrosoftとAWSはいずれも従来の「東京・大阪」二拠点体制から、北海道・九州・北陸を含む地域分散へと戦略を転換しつつあります。

ガバメントクラウドでは、AWSが圧倒的な実績を持ちます。デジタル庁が2026年2月27日に公表した移行状況データによれば、標準化対象の34,592システムのうち移行完了は13,283件（38.4%）です。早期移行団体463団体のうち300を超える自治体がAWSを採択しており、報道ベースでは利用中・利用決定済み自治体の9割超がAWSを選択しているとされています。「先行実績の多さ」と「国内SIerのAWS対応スキルの成熟」という循環が働いた結果です。

この構図に2026年3月27日、変化が入りました。さくらインターネットの「さくらのクラウド」が305項目の技術要件をすべて満たし、国産事業者として初めてガバメントクラウドの本番環境提供が可能になったのです。AWS、Google Cloud、Microsoft Azure、OCIに続く5番目で、外資4社独占が崩れた形になります。ただし本番実績の蓄積はこれからで、既存のノウハウの大部分がAWS環境を前提としている以上、短期でシェアが動く性質のものではありません。

一方、ソブリンクラウドではAWSは明確に劣後しています。AWSのEuropean Sovereign Cloudは2026年1月にドイツで一般提供が始まりましたが、これはEU専用であり、日本向けの専用ソブリンクラウドは提供されていません。日本ではISMAP認証を取得した東京・大阪リージョンで対応する形です。対して、ソフトバンクはOracle Alloy基盤の「Cloud PF Type A」を東日本2026年4月・西日本2026年10月に、NTTデータは「OpenCanvas Type-Oracle Alloy」を2025年12月に東日本リージョンで提供開始しており、「ソブリンクラウド」を明示的に構築しています。金融・公共でデータ主権が最優先される案件では、この差が直接効いてきます。

国産LLMの動きも押さえておく必要があります。経産省・NEDOのGENIACでは、AWSは第2期以降、複数サイクルにわたって計算資源提供者に選定されています（第4期は2026年6月キックオフでP6-B200等を提供）。ただしGENIACはAWS、Google Cloud、さくらインターネットなど複数事業者を採用しており、AWSの独占ではありません。モデル側では、NTTのtsuzumi 2、NECのcotomi、PFNのPLaMo、富士通のTakaneといった国産LLMが、金融・公共領域で純国産という訴求とともに存在感を高めています。デジタル庁の政府AI環境「源内」にも複数の国産モデルが採用されました。

日本企業のBedrock採用事例では、野村総合研究所がBedrock上のClaudeを用いて日本語文書分析を自動化し、複雑な文書のレビュー時間を50%削減したとする事例が公表されています（Anthropic公式の顧客事例に基づく数値であり、独立した検証は行われていません）。2026年にはBedrockのクロスリージョン推論でClaude系モデルの日本国内推論が可能になり、データ越境を懸念する金融・公共顧客への提案条件が改善しました。

9. 2026〜2028年の展望とリスク

ここからは筆者の推定を含む見通しです。確度の高い予測ではなく、シナリオとして読んでください。

強気シナリオ。AI事業と自社チップ事業がそれぞれ250億ドル超のランレートからさらに倍増し、TrainiumがAnthropic以外の大規模顧客でも実証されることでNVIDIA調達比率が下がり、粗利が改善する。Bedrockが「モデル中立ハブ」として企業の既定選択になり、営業利益率は高40%台で持続する。

中立シナリオ。成長率ではGoogle Cloudに劣後し続けるが、絶対額とバックログで首位を維持。Novaはコスト最適化用途で定着し、日本ではガバメントクラウドの牙城を守る。ソブリン領域はOracle陣営に譲る形が続く。

弱気シナリオ。AnthropicがTPUや自社調達にさらに傾斜し、AmazonのAnthropic評価益が剥落する。電力制約で需要を取りこぼす。AI投資の調整局面が来た場合、積み上がった有形固定資産の減価償却がフリーキャッシュフローを圧迫し続ける。

主要リスクを整理すると、次のようになります。

• Anthropic依存の両義性——最大の需要源かつ会計上の評価益源だが、マルチクラウド化とIPOによって関係の性質が変わる可能性がある
• 自社フロンティアモデルの不在——モデル供給者との交渉力に構造的な上限がある
• シリコンの囲い込み構造——Trainiumの価格性能はAWSを選ぶこととセットであり、TPU外販が価格圧力を生む
• 電力・グリッド制約——特に日本では東京圏の5〜10年待ちが投資サイクルと噛み合わない
• 日本のソブリン要件——専用ソブリンクラウドの不在が規制業種の案件で不利に働く
• キャッシュフローと減価償却——トレーリングFCFのマイナス転落が示すとおり、投資回収の時間軸は長い

日本のSIerやベンダーの立場から見た論点は3つに整理できます。第一に、Bedrockを「モデル中立ハブ」として提案の中核に据える価値が高まったこと。Claude、GPT-5.6系、gpt-oss、Novaを用途別に使い分けられ、しかも新規ベンダー審査を増やさずに済むという実務メリットは、日本企業の調達プロセスと相性が良いためです。第二に、データ主権が最優先の案件ではAWSが最適解とは限らないこと。ソブリンクラウドや国産LLMを含めた選択肢と並べて評価すべきです。第三に、Q Developer終息への対応が2026年度内の実務課題になること。特にJetBrains・Visual Studio前提の開発体制を持つ組織は、IDE標準の見直しを含めた計画が必要です。

継続的にモニタリングすべき指標としては、AWS四半期成長率とGoogle Cloud／Azureとの差、Novaの第三者評価における位置づけ、Anthropicの追加TPU傾斜とIPO動向、AWSジャパンの新規AI／ソブリン投資発表の有無、が挙げられます。

10. まとめ

AWSの「AI出遅れ論」は、2026年の財務数字によって少なくとも売上・利益率の面では反証されました。5四半期連続の成長加速、39.4%の営業利益率、4,960億ドルのバックログは、AIワークロードがAWS上で確実に増えていることを示しています。

ただし、勝ち方の構造は当初想定と違うものになりました。AWSは自社モデルで勝負しておらず、Anthropicに出資しつつOpenAIを顧客として迎え、両者のモデルを同じBedrock上で売るという中立プラットフォーマーの道を選んでいます。この立ち位置は、OpenAIに深く紐づくMicrosoftとも、Geminiを垂直統合するGoogleとも異なります。

弱点も構造的です。自社フロンティアモデルがないため、モデル供給者との関係が事業の前提を左右します。そのAnthropicは、Googleから金額ベースではAmazonを上回る出資コミットメントを受け、TPUで大規模な計算資源を確保しました。AWSにとってAnthropicは、いまも最大の資産であり、同時に最大の不確実性です。

日本市場では、投資額と既存実績で圧倒しながら、ソブリンクラウドという新しい競争軸では後手に回っています。ガバメントクラウドにおける9割超のシェアは強固ですが、さくらのクラウドの正式採択とOracle陣営のソブリン展開は、その前提が永続的ではないことを示しています。「AWSを使う／使わない」の二択ではなく、案件のデータ主権要件と業務特性に応じて、Bedrock経由のマルチモデル、ソブリンクラウド、国産LLMを組み合わせる設計が、これから数年の現実解になると考えます。

データの置き場所より、事業者の管轄——米中クラウドの外国法リスクを数字で見る

「データを国内リージョンに置いているから安心」——クラウド調達の議論でいまだによく聞くフレーズです。しかし米国のCLOUD Actが問題にしているのはデータの所在地ではなく、事業者がどの国の管轄に服しているかです。日本のデータセンターに保管されていても、事業者が米国の管轄下にある限り、米国の令状は及びます。同じ問いは中国資本のクラウドにも向けられます。日本国内にリージョンを持つ中国系事業者に対して、中国の国家情報法はどこまで及ぶのか。

この二つは「外国政府がデータを見にくるリスク」として同じ棚に並べられがちですが、リスクの構造はかなり違います。米国側は司法審査があり、件数が公表され、事業者が争う制度上の手段がある。中国側はそのいずれも公開情報からは確認できない。一方で発動の蓋然性という点では、米国のエンタープライズデータ開示は統計的に見て極めて少ない。構造と蓋然性を混ぜて議論すると、判断を誤ります。

結論を先に書きます。データ所在地（residency）ではなく管轄（jurisdiction）を基準に分類すること、機微度の高いデータには暗号鍵の自己管理を必須にすること、そして米中いずれの外国資本クラウドについても「完全に排除できる」という前提を置かないこと。これがデジタル庁のガイドラインの記述とも整合する、現時点で取りうる最も現実的な線です。以下、法の条文、透明性レポートの実数、日本政府の制度対応の順に根拠を示していきます。

本記事は2026年8月時点の公開情報に基づいています。FISA第702条の失効をはじめ、状況が流動的な論点を含みます。また記事後半には今後の見通しに関する記述がありますが、これは筆者の推定であり、精密な予測ではありません。法的評価が分かれている論点については、両論を併記しています。

1. CLOUD Actが可能にしていること

CLOUD Act（Clarifying Lawful Overseas Use of Data Act）は2018年3月23日、統合歳出法（Pub. L. 115-141）のDivision Vとして成立しました。1986年の通信記録保存法（Stored Communications Act, 18 U.S.C. §§2701-2712）を改正するもので、中核は新設された18 U.S.C. §2713です。

電子通信サービスまたはリモートコンピューティングサービスの提供者は、通信・記録その他の情報が米国内外いずれに所在するかにかかわらず、自己の占有・保管・支配（possession, custody, or control）の下にある顧客・加入者に関する通信内容および記録を保全・バックアップ・開示する義務を遵守しなければならない。（18 U.S.C. §2713、筆者訳）

ここに「データセンターの所在地」という概念は出てきません。米国と十分な接点を持つ事業者が支配下に置いているデータであれば、それが東京にあってもロンドンにあっても、米国の令状・召喚状の対象になります。この構造こそがリスクの本体であり、リージョン選択では動かせない部分です。

もっとも、事業者側に対抗手段がないわけではありません。18 U.S.C. §2703(h)は「国際礼譲（comity）」の分析を規定しており、対象顧客が米国人でなく、開示が米国と行政協定を締結した外国政府の法に抵触する場合、事業者は令状の取消を申し立てることができ、裁判所は米国と外国の利益を衡量します。ただし後述するとおり、この条項が実効的に働く前提には「行政協定を締結した外国」という限定がかかっています。

この立法の直接の引き金は、いわゆるMicrosoftアイルランド事件です。2013年12月、ニューヨーク南部地区の治安判事が麻薬取引捜査でSCAに基づく令状を発付し、Microsoftにダブリンのサーバーに保管された電子メールの開示を命じました。Microsoftは「米国の令状は国境を越えない、刑事共助条約（MLAT）を使うべきだ」として拒否し、第2巡回区控訴裁判所で勝訴。政府が上告し2018年2月27日に連邦最高裁で口頭弁論が行われましたが、その約1か月後にCLOUD Actが成立して争点が立法的に解決されたため、最高裁は2018年4月17日に本件を訴えの利益なし（moot）として下級審判決を破棄・差戻しました。つまりCLOUD Actは、政府が同事件で主張していた立場を議会が追認した立法です。

2. どれだけ発動されているのか——透明性レポートの実数

構造上のリスクと、実際の発動頻度は別の話です。Microsoftは半期ごとに法執行機関からの要求件数を公表しており、これが数少ない定量データになります。最新の2025年下半期（7〜12月）の数字を見てみます。

同期間、Microsoftが世界中の法執行機関から受け取った消費者向けサービスに関する要求は27,412件。これに対してエンタープライズ顧客（商用クラウドを50シート超購入している組織、またはAzureサブスクリプション契約者）に関する要求は190件にとどまります。同社は「年間数万件の法的要求のうち、エンタープライズ顧客データを求めるものは1%を大きく下回る」と説明しています。

項目（エンタープライズ顧客関連）	2024年下半期	2025年下半期（最新）
法執行要求の総数	173件	190件
却下・撤回・データ不存在・顧客への誘導	107件（62%）	96件（51%）
開示を強制されたもの	66件（38%）	94件（49%）
うちコンテンツデータの開示	26件（うち20件が米国法執行関連）	45件（うち31件が米国法執行関連）
うち非コンテンツデータの開示	40件	49件
越境開示（米国外保管の非米国エンタープライズ顧客のコンテンツを米国法執行機関へ）	5社分（いずれもEU/EFTA域外の顧客）	3社分（うち1社はEU/EFTA域内）
Azureのコンテンツデータ開示	なし	なし（商用・公共・教育のいずれも）

越境開示が半期あたり数社分という水準は、率直に言って少ない。ただしこれをもって「リスクは無視できる」と結論づけるのは早計です。三つ留保があります。

• 件数は事業者の自己申告である。独立した検証手段はありません。
• 秘匿命令の存在。Microsoftは2025年下半期、米国の法的要求の32%（1,823件、うち1,473件は連邦当局発）に顧客への通知を禁じる秘匿命令が付されていたと公表しています。件数は事後に集計されますが、当該顧客がその時点で知ることはできません。
• 消費者向けサービスでは桁が違う。同期間、米国法執行機関からの消費者データ要求は5,587件あり、そのうち115件は米国外に保管されたコンテンツを求める令状でした。CLOUD Actが日常的に使われていることは、この数字からわかります。

3. FISA第702条という別の経路

CLOUD Actの議論でしばしば混同されるのが、外国情報監視法（FISA）第702条です。両者は別制度で、リスクの性質も異なります。CLOUD Actは刑事捜査における令状・召喚状であり、裁判官による相当理由の審査を伴います。第702条は米国外にいる非米国人を対象とした外国情報の収集であり、個別の令状を要しません。日本の企業や個人にとって直接関係が深いのは、むしろ後者です。

この第702条は、2024年のRISAA（Reforming Intelligence and Securing America Act）で2年間再授権され、2026年4月20日が失効期限とされていました。以後、10日間・45日間といった短期延長が繰り返されましたが、下院が2026年6月11日に短期延長案を198対218で否決し、第702条は2026年6月12日深夜に失効しました。2008年の制定以来初めてのことです。

ただし失効＝収集停止ではありません。第702条の運用は外国情報監視裁判所（FISC）が承認する年次認証に基づいており、この認証は法律が失効しても有効期限まで存続します。FISCは2026年3月17日に認証を出しており、これにより収集は2027年3月頃まで法的に継続可能とされています。とはいえ、根拠法が失効した状態で事業者がどこまで応じるかについては法的な不確実性が指摘されており、本記事執筆時点で再授権は成立していません。

日本企業にとっての含意は単純です。米国資本クラウドの外国法リスクを評価するなら、CLOUD Actだけを見ていては不十分で、第702条の帰趨も監視対象に入れる必要がある、ということです。

4. 「ソブリンクラウド」は管轄を切り離せるか

欧州の主権要求に応えるかたちで、各メガクラウドはソブリン提供を打ち出しています。最も踏み込んだのがAWSで、AWS European Sovereign Cloud（ESC）が2026年1月15日に一般提供を開始しました。ドイツ・ブランデンブルク州の第一リージョンはグローバルAWSとは物理的にも論理的にも分離された独立パーティション（aws-eusc）で、IAM・課金・DNS・認証局も独立、運用はEU居住者に限定され、ドイツ法人を親会社とする専用のガバナンス構造が置かれています。投資額は78億ユーロ超とされ、ベルギー・オランダ・ポルトガルへのLocal Zone拡張も発表されています。トレードオフとして、提供サービス数がグローバルリージョンより少なく、開始時点でアベイラビリティゾーンは2つでした。

では、これでCLOUD Actの適用は排除されるのか。法的にはされません。AWS European Sovereign Cloud GmbHはAmazon.com, Inc.の100%子会社であり、この点は欧州のアナリストからも指摘されています。運用主体をEU居住者に限定し、法人をドイツ法の下に置いても、親会社が米国企業である限り「占有・保管・支配」の議論は残ります。

この論点を最も明確にしたのが、2025年6月10日のフランス上院での証言です。「公共調達とデジタル主権」調査委員会の宣誓聴取で、Microsoft Franceの公共渉外・法務ディレクターAnton Carniaux氏は、フランス市民のデータが仏当局の同意なく米当局に渡らないことを保証できるかと問われ、公式議事録上「保証はできない。ただし繰り返すが、そうした事態はこれまで一度も起きていない」と答えました。正当な根拠を欠く要求は拒否しており、欧州の企業・公共部門への発動事例はないと付言していますが、技術的措置と契約上の約束では米国法の適用そのものは排除できないことを、事業者自身が公の場で認めた形になります。

なお、Microsoftは自社FAQで、EU域内のサービスはアイルランド法人Microsoft Ireland Operations Limited（MIOL）が提供し、欧州のデータセンターはMIOLとその子会社が所有・賃借していると説明しています。法人の所在を欧州に置く構成は共通の設計思想です。

CLOUD Actの直接の適用とは別に、欧州の危機感を高めた出来事として、2025年に国際刑事裁判所（ICC）主任検察官が米国の制裁対象に指定された件があります。同氏のMicrosoftアカウントが遮断されたと報じられ（Microsoftはサービスの停止・中断を否定）、ICCは2025年10月31日、Microsoft Officeからドイツ製オープンソースの「OpenDesk」への移行を確認しました。データを読まれるリスクではなく、サービスを止められるリスク——可用性の側面が主権議論の中心に入ってきたのは、この時期からです。

5. 日米間の非対称性

CLOUD Actのもう一つの柱が18 U.S.C. §2523の行政協定（executive agreement）です。一定の人権・プライバシー基準を満たす外国政府と協定を結ぶことで、相互に事業者へ直接データを請求できるようにする枠組みで、従来のMLAT（司法省と裁判所の個別承認を要する、時間のかかる手続）を迂回します。

2026年8月時点で発効しているのは米英協定（2019年10月署名、2022年10月3日発効）と米豪協定（2021年12月15日署名、2024年1月30日発効）の二つだけです。Microsoftも自社の透明性レポートで、米国政府が協定を締結しているのは英国と豪州であり、カナダおよびEUとは交渉を公表している、と明記しています。いずれの協定も重大犯罪に限定され（豪州協定では3年以上の拘禁刑）、5年の有効期間を持ちます。

日本との協定は存在せず、公開情報上、交渉開始の事実も確認できません。日米間には2003年8月に署名され2006年に発効した刑事共助条約があり、日本の当局が米国事業者からデータを取得しようとすればこのMLAT経路になります。ここに構造的な非対称性があります。

• 米当局は、日本国内に保管されたデータでも、§2713により米国事業者へ直接請求できる。
• 日本の当局は、米国事業者へ直接請求する迅速な経路を持たず、MLATを経由するしかない。
• §2703(h)の礼譲条項が想定する「協定締結国の法との抵触」という抗弁も、協定がない以上、日本を対象としては働きにくい。

6. 日本政府はどう扱っているか

日本政府はこの問題を明示的に制度に書き込んでいます。デジタル社会推進標準ガイドラインDS-310「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」（2025年5月27日 デジタル社会推進会議幹事会改定）の3.2節は、次のように定めています。

クラウドの利用にあたっては、国内法以外の法令及び規制が適用されるリスクを評価し、情報が取扱われる場所及び契約に定める場所と準拠法・国際裁判管轄に留意する必要がある。（中略）政府情報システムが利用する場合、クラウドのデータセンタの設置場所に関しては、国内であることを基本とする。（DS-310 3.2節）

さらに踏み込んでいるのが、利用者データを国外クラウドに保管する場合の対策です。CRYPTREC暗号リスト掲載の暗号による暗号化を求めた上で、機密性によっては「利用者自身の暗号鍵によるデータの保護と鍵管理（BYOK等）を行い、クラウド（CSP）や監督権限を持った政府等が利用者データを判読不能とする措置を行うこと」と明記しています。「監督権限を持った政府等」——つまり外国政府による閲覧を、鍵管理によって無効化せよと政府自身が書いている。可用性についても、外国法令によるデータ域内保存義務等でリスクが予見される場合には「当該法令の効力の及ばない場所（国）にバックアップ等を保持する」よう求めています。

調達側の制度としてはISMAP（政府情報システムのためのセキュリティ評価制度）があり、政府調達は原則としてISMAP等クラウドサービスリスト登録サービスから選定されます。DS-310の3.1節は、サプライチェーン・リスクに注意を要する場合は「IT調達に係る国等の物品又は役務の調達方針及び調達手続きに関する申合せ」（平成30年12月10日関係省庁申合せ）に従って事前確認を行うことも求めています。この申合せが、後述する中央省庁での中国製通信機器の事実上の排除の根拠になっています。

ガバメントクラウドについては、長らくAWS・Azure・Google Cloud・Oracleの外資4社のみという状態が続きましたが、2023年11月に条件付きで採択されたさくらインターネットが約300項目の技術要件をすべて満たし、2026年3月27日に正式認定されました。国産事業者としては初、5番目の採択事業者となります。

民間側の主権対応としては、Oracleが提供するOracle Alloy（OCIと同一基盤をパートナーが自社データセンターで設置・運用する形態）を採用する事業者が複数あります。国内では富士通、NTTデータ、野村総合研究所などがこれを採用し、それぞれ自社ブランドのクラウドサービスを構築しています。日本オラクル自身も2025年7月、日本国内在住者のみで構成する「ジャパン・オペレーション・センター」を開設しました。運用要員の国籍・居住地まで管理対象に含めるという発想は、AWS ESCがEU居住者限定運用を掲げているのと同じ設計思想です。ただしこれらも、親会社の管轄という論点を法的に解消するものではない点は同様です。

7. 中国資本クラウドの日本国内展開

では中国資本のクラウドはどうか。まず事実関係として、日本国内に相当規模のインフラが存在します。

アリババクラウドは2016年に東京リージョンを開設しました。当初はソフトバンクとの合弁SBクラウドが運営していましたが、同社は2021年10月1日付でソフトバンクに吸収合併され消滅。現在はアリババクラウド・ジャパンサービス株式会社が国内事業を担っています。注目すべきは近年の拡張速度で、2026年3月に日本国内4か所目のデータセンターを開設し、その数か月後の2026年6月18日には5か所目を東京に開設。日本リージョンは5つのアベイラビリティゾーンで構成されるまでになりました。同時にAI開発プラットフォーム「Model Studio」の日本リージョン提供も始まっています。撤退どころか、AI需要を背景に日本での投資を加速させているのが実態です。

テンセントクラウドは東京に2ゾーンを持ち、2025年4月15日から16日にかけて、国内3拠点目のデータセンターを大阪に開設し大阪をリージョンとして設定すると発表しました（大阪リージョンのローンチ時期は2026年と説明されています）。日本法人はTencent Japan合同会社。同社カントリーマネージャーによれば顧客の約95%は日本国内のクライアントで、ゲーム・配信などエンターテインメント領域が約半分を占め、金融・小売分野も伸びているとのことです。

つまり「中国資本クラウドは日本ではほとんど使われていない」という前提は、事実に反します。少なくともゲーム・エンタメ・越境ECの領域では、実運用の基盤として定着しています。

8. 中国法の域外適用をめぐる二つの読み方

議論の中心にあるのが、2017年6月27日に可決され翌28日に施行された国家情報法（2018年改正）の第7条です。

いかなる組織及び国民も、法に基づき国家の情報活動を支持し、援助し、協力し、知り得た国家情報活動の秘密を守らなければならない。（国家情報法第7条、筆者訳）

この条文が中国企業の海外子会社にまで及ぶかについては、評価が割れています。

広く読む立場。スウェーデンの法律事務所Mannheimer Swartlingが2019年1月に公表した報告書は、国家情報法はすべての中国国民に適用され、中国企業グループの海外子会社も対象となりうる（親会社が同法の適用を受ける以上、国際公法の観点からは海外子会社にも管轄が及びうるし、親会社は子会社に対するガバナンス権限を持つ）と結論づけました。ただし同報告書自身が、これは英語版の客観的な読解と国際公法の原則に基づく分析であって、中国国内法体系の下での解釈ではないと明示的に留保しています。

限定的に読む立場。China Law Translate創設者のJeremy Daum氏は2024年、第7条が情報収集・共有への能動的な参加を求める趣旨であったかは全く明らかでないと指摘しています。同条には実効的な執行メカニズムがなく、罰則は情報活動が「妨害された」場合に限られ、その活動も「法に基づき」行われることが前提になっている、という読み方です。

重要なのは、この対立が公開情報だけでは決着しないという点です。中国資本クラウドには透明性レポートが存在しません。したがって「日本国内で開示事例が確認されていない」という事実は、事例が存在しないことの証明にはならず、確認する手段がないことを意味するにすぎません。米国資本クラウドについて件数を数えて議論できるのとは、そもそも土俵が違います。

関連する法制度としては、サイバーセキュリティ法（2017年）、データ安全法（2021年9月1日施行）、個人情報保護法（PIPL、2021年11月1日施行）があります。PIPLは域外適用条項を持ち、データの越境移転には安全評価・専門機関認証・標準契約のいずれかを要します。日本側から見ると、日本国内データの持ち出しを直接命じる規定というより、中国側の規制環境全体が国家の管理を前提に設計されている、という理解が実務的です。

9. 二つのリスクの構造比較

観点	米国資本クラウド	中国資本クラウド
主な根拠法	CLOUD Act（18 U.S.C. §2713）、SCA、FISA第702条	国家情報法、国家安全法、反スパイ法、サイバーセキュリティ法、データ安全法、PIPL
取得の主体	裁判官発付の令状・大陪審の召喚状（刑事）／FISC承認の認証（情報監視）	国家情報機関・公安機関
独立した司法審査	あり（刑事は相当理由の審査を伴う）	公開情報からは確認できない
透明性	半期ごとの件数公表が定着。越境開示件数も区分掲載	透明性レポートは存在しない
事業者による異議申立て	§2703(h)の礼譲分析、裁判所での争訟が制度上可能	実効的な手段は公開情報上確認できない
越境協定の枠組み	米英・米豪の行政協定が発効。加・EUと交渉中。日本とは未締結	相当する相互協定の枠組みなし
確認できる発動実績	2025年下半期の越境エンタープライズ開示は3社分（Microsoft）	公開情報上、日本での開示事例は確認できない（確認手段自体がない）
日本政府の扱い	ISMAP登録可、ガバメントクラウド採択。DS-310で外国法リスクを明示的に評価対象化	中央省庁は2018年の申合せで通信機器を事実上排除。自治体調達も認定制で限定する方針が報じられている
緩和策の効き方	鍵の自己管理は有効。ソブリン提供は運用・法人を分離するが、親会社の管轄は残る	運用主体とデータ所在で蓋然性は変わるが、透明性の欠如は技術では埋められない

日本政府の対中対応は、時系列で見ると一貫した方向を持っています。2018年12月の関係省庁申合せにより中央省庁・自衛隊のIT調達から中国製通信機器が事実上排除され、2024年5月17日には経済安全保障推進法の基幹インフラ事前審査制度が本格運用に入りました。そして2026年4月には、総務省が自治体のIT機器・サーバー・クラウド調達を政府認定品（経済産業省のJC-STARおよびISMAP）に限定する方針を固めたと報じられ、地方自治法関係の総務省令を改正のうえ2027年夏からの運用開始が見込まれています。JC-STARもISMAPも中国製品を認定していないため、事実上の排除になるという整理です。ハードウェアからクラウドへ、中央省庁から自治体へと、規制の網が段階的に広がってきたと見るのが自然でしょう。

10. 実務上の判断軸

以上を踏まえた実務的な整理です。順序が重要で、技術的対策から入ると必ず失敗します。

第一に、データを機微度で分類し、管轄をマッピングする。①一般業務データ、②個人情報・営業秘密、③基幹インフラ・国家安全保障に関わるもの、程度の粗い三分類で構いません。その上で各クラウド利用について「データ所在地」ではなく「運用主体の法人格と、その法人が服する管轄」を棚卸しします。ここで初めて、リージョン選択では動かせない部分が可視化されます。

第二に、機微度②③には暗号鍵の自己管理を標準化する。BYOK/HYOK、confidential computing、外部鍵管理サービスの利用です。判断軸は単純で、鍵を事業者が保持しているかどうか。事業者が復号できる構成である限り、令状は意味を持ちます。DS-310が「CSPや監督権限を持った政府等が利用者データを判読不能とする措置」と書いているのは、まさにこの点です。ただし同ガイドラインも、クラウド外で鍵を作成・保管・管理する場合は運用負荷と処理の複雑さが大幅に増すため導入前に十分な検討が必要だと注意喚起しています。実際、鍵の紛失は暗号化されたデータの永久喪失を意味します。

第三に、機微度③は管轄そのものを切り離す。国産クラウド、あるいは国内法人が国内要員で運用するソブリン提供を選択肢に入れます。政府・自治体関連業務では、2027年夏の自治体調達制限を先取りして認定制度（ISMAP、JC-STAR）への適合を要件化しておくのが安全です。

中国資本クラウドについては、機微度③には用いないというのが素直な結論になります。日本国内リージョンを使い、運用主体が日本法人であっても、透明性レポートが存在しない以上、リスクを定量的に評価できないからです。逆に言えば、中国向けEC・ゲーム配信のように業務上の必然性がある領域で機微度①のデータを扱う限りにおいて、これを一律に忌避する理由も薄い。用途で切り分ける話です。

判断を見直すべきトリガーとしては、日米CLOUD Act行政協定の交渉開始または締結、FISA第702条の再授権の帰趨（現在失効中で、FISCの認証は2027年3月頃まで）、メガクラウドの日本向けソブリン提供が非米国法人運営を実現するかどうか、あたりが挙げられます。いずれも制度の前提を動かす要素です。

まとめ

米国資本クラウドのCLOUD Actリスクは、構造としては不可避だが、エンタープライズ・非米国データに対する発動の蓋然性は統計的に低い。半期あたり数社分という越境開示の実績は、そのことを示しています。一方でその低さは事業者の自己申告に依存しており、秘匿命令の存在と、FISA第702条という別経路の不透明さがつきまといます。技術的措置と契約でCLOUD Actの適用を排除することはできない——これは事業者自身が公の場で認めた事実です。

中国資本クラウドのリスクは、蓋然性の高低以前に評価する手段が存在しないという設計上の問題を抱えています。国家情報法第7条の域外適用は法的評価が割れており、否定しきることも肯定しきることもできない。にもかかわらず日本国内には相当規模のインフラが存在し、拡張が続いています。「使われていないから問題にならない」という前提は成り立ちません。

結局のところ、外国資本クラウドの利用は「安全か危険か」の二択ではなく、どの管轄のどの制度に、どのデータを、どの緩和策を伴って預けるかという設計の問題です。日本政府自身がDS-310で、外国法リスクの評価、国内データセンターの原則、そして鍵の自己管理という三点を書き込んでいます。民間の実務も、そこから出発するのが筋が通っているように思います。

南海トラフ巨大地震はITシステムをどう襲うか──2025年新想定で読み解くクラウド・通信・BCPの防災設計

2025年3月31日、内閣府の南海トラフ巨大地震対策検討ワーキンググループが約13年ぶりに被害想定を全面改定した。最大クラスの地震が発生した場合、直接死は最大29万8000人、経済被害は約292兆円に達するという、日本社会がこれまで経験したことのない規模の災害想定である。

本稿では、この新想定を踏まえ、データセンター・クラウド基盤、通信インフラ、企業のBCP、政府系システムという4つの切り口から、南海トラフ巨大地震がITシステムに与える影響を整理する。エンジニア・IT企画担当者が自組織の防災設計を見直す際の参考になれば幸いである。

1. 2025年新被害想定の要点

新想定の最大の特徴は、2012〜2013年の前回想定から死者数（前回32万3000人→今回29万8000人、約1割減）が若干改善した一方で、経済被害額（前回約220兆円→今回約292兆円）は建設費高騰や被害評価手法の高精度化により大幅に増加した点である。また今回初めて、避難生活に伴う体調悪化等で生じる「災害関連死」を試算し、2万6000〜5万2000人という数字が示された。これは直接死とは別枠のカウントであり、両者を合算した報道も見られるため注意が必要である。

項目	2012〜2013年想定（前回）	2025年3月新想定
死者数（直接死・最大）	約32万3000人	約29万8000人
災害関連死	試算なし	2万6000〜5万2000人（今回初試算）
経済被害額	約220兆3000億円	約292兆3000億円
震度7の市町村数	143市町村	149市町村
停電（最大）	－	最大約2950万軒
断水（最大）	－	最大約3690万人

なお、南海トラフ地震の30年以内発生確率については、2025年1月時点で「80%程度」とされていたが、その後、政府の地震調査委員会が不確実性を考慮した見直しを行い、2025年9月には「60〜90%程度以上」（算出方法によっては「20〜50%」という幅も存在）という表現に改められている。ブログや資料で「80%」という数字を引用する際は、この見直しの経緯を併記するのが望ましい。

2. データセンター・クラウド基盤への影響

2-1. 東京圏・大阪圏への一極集中という構造的リスク

総務省・経済産業省の有識者会合資料によれば、国内データセンターはサーバー面積ベースで約150万平方メートル（東京ドーム約30個分）存在するが、その8割強が東京圏・大阪圏に集中しており、この傾向は今後も続く見込みとされている。資料によって関東6割強・関西2割強程度という内訳も示されており、合計すると8〜9割が東京・大阪の2大都市圏に偏っている状況である。

この一極集中の背景には、インターネットサービスプロバイダーが相互接続を行うIX（インターネットエクスチェンジ）拠点が東京・大手町と大阪・堂島に集中しているという事情がある。IX接続数は関東が7割前後、関西が2割前後を占めるとされ、通信の遅延（レイテンシ）を抑えるためにデータセンターもこの2拠点周辺に立地する構造が続いてきた。

ここで重要なのは、南海トラフの想定震源域が静岡から九州にかけての太平洋沿岸に広がっており、大阪圏はこの震源域にきわめて近いという点である。新想定でも大阪府内の広い範囲で震度6弱以上、沿岸部では津波被害が想定されている。つまり「東京と大阪の2拠点に分散していればBCP的に安全」という従来の発想は、南海トラフ地震に関しては必ずしも成立しない。東京は首都直下地震、大阪は南海トラフ地震という異なる災害リスクにそれぞれ晒されているが、南海トラフが「全割れ」パターンで発生した場合、大阪圏のリスクは東京圏よりも直接的に高くなる可能性がある。

2-2. 主要クラウド事業者のリージョン構成

事業者	国内リージョン構成	備考
AWS	東京・大阪	ガバメントクラウドでも東京・大阪に限定
Microsoft Azure	東日本（東京・埼玉）・西日本（大阪）	ガバメントクラウド認定
Google Cloud	東京・大阪	ガバメントクラウド認定
Oracle Cloud（OCI）	東京・大阪	ガバメントクラウド認定
FJcloud-V（富士通）	東日本4リージョン・西日本2リージョン	北米リージョン（us-east-1）は2025年9月30日にサービス提供終了、現在は国内6リージョン構成
さくらインターネット	石狩（北海道）・東京	2026年3月27日にガバメントクラウド正式認定。国産クラウドとして唯一かつ5番目の認定事業者

見ての通り、政府認定クラウドはAWS・Azure・Google Cloud・OCIの4社に加え、2026年3月27日にさくらインターネットの「さくらのクラウド」が正式認定を受け、5社体制となった。国産クラウドとしては唯一の存在であり、外資系4社が軒並み東京・大阪の2拠点構成であるのに対し、さくらインターネットは石狩（北海道）と東京という組み合わせを取っている点が構造的に異なる。

外資系4クラウドの東京・大阪2拠点構成は、通信遅延やデータ主権要件を満たす現実的な選択ではあるが、前述の通り大阪が南海トラフの震源域に近接している以上、「東京・大阪の2リージョン運用＝広域災害対策として十分」とは言い切れない構造である。その意味で、震源域から遠い石狩を含むさくらインターネットの構成は、南海トラフ地震という単一災害シナリオに対する耐性という観点では、外資系4社の東京・大阪構成よりもむしろ有利に働く可能性がある点は付記しておきたい（ただし、石狩・東京の組み合わせは首都直下地震と北海道地震という別の複合リスクを内包する点には留意が必要である）。

2-3. ガバメントクラウドの地理分散要件

この課題は政府側も認識しており、デジタル庁が公表しているガバメントクラウド調達仕様書（令和8年度募集分）には、データセンターは地理的に離れた日本国内の複数の地域（例えば、関東と関西、北海道と関東、関西と九州など）に設置するなど、大規模地震や電力供給障害を想定した災害対策を講じることという要件が明記されている。「関東と関西」だけでなく「北海道と関東」「関西と九州」という組み合わせも例示されている点は重要で、南海トラフの震源域から離れた北海道・九州を含めた分散が政府調達レベルでは想定され始めていることを示している。

実際の事例として、ガバメントクラウド先行事業に採択された神戸市では、東京リージョンと大阪リージョンの間でDR環境を構築した例が報告されている。ただし、これも本質的には「東京・大阪の2点間分散」であり、南海トラフの全割れシナリオに対する耐性という観点では、北海道・九州など震源域から十分離れた第三のリージョンを組み合わせる設計が今後より重要になると考えられる。

3. 通信インフラへの影響

3-1. 海底ケーブル陸揚局の太平洋側集中

総務省資料によれば、国際海底ケーブルの陸揚局は約5割が関東（房総半島・北茨城）、約3割が関西（志摩半島）に集中している。志摩半島は三重県、まさに南海トラフの想定震源域の直上に位置する。南海トラフ地震で志摩半島周辺の陸揚局が被災した場合、国際通信の分岐点としての機能が損なわれるリスクがあり、国内のインターネット接続全体への波及も懸念される。政府はこのリスクを踏まえ、国際海底ケーブルの多ルート化や陸揚局の分散を「デジタル田園都市国家インフラ整備計画」の一環として進めている。

3-2. 過去の大規模災害から見える通信インフラの限界

東日本大震災（2011年）では、非常用電源の枯渇等により通信各社合計で約2万9000の基地局が停波した。復旧には約1カ月半を要し、4月末時点でようやく福島第一原発周辺の対応困難エリアを除きほぼ復旧した。音声通話については輻輳対策としてNTTドコモ・KDDI・ソフトバンクの主要3社が最大70〜95%の通信規制を実施している。

北海道胆振東部地震（2018年）では、日本初となる全域停電（ブラックアウト）が発生し、約6500基地局が停波、停電は最大295万戸に及んだ。北海道電力の全域停電は約64時間後まで続いた。この際、さくらインターネットの石狩データセンターは非常用発電機で稼働を継続したものの、商用電源喪失を検知して非常用電源へ切り替える制御回路が正常に作動せず、一部ゾーンのサーバーが約5時間停止するというトラブルも発生している。自家発電設備を備えていても、切替機構そのものの信頼性検証（実負荷試験等）が欠かせないことを示す実例といえる。

両震災に共通する教訓は、①非常用電源の燃料備蓄量（東日本大震災当時は基地局の電源容量が不足し長時間停電に耐えられなかった）、②電源切替機構の信頼性、③通信規制による輻輳回避と業務影響の両立、の3点に集約される。NECや富士通のデータセンターが胆振東部地震で72時間分の燃料備蓄により無停止運用を実現した実績は、南海トラフ地震のような広域・長期停電（新想定では電柱被害による停電復旧に1〜2週間を要すると想定）に対しては、72時間備蓄でも不十分となり得ることを示唆している。燃料の追加供給契約や自治体・自衛隊との連携も含めた計画が必要である。

4. 企業のBCP・事業継続への影響

新想定では、停電の復旧について、需給バランスに起因するものは数日で復旧する一方、電柱等の設備被害による停電は復旧までに約1〜2週間を要するとされている。断水についても、東海3県で復旧率95%に達するまで約8週間かかるとの想定である。IT部門がBCPを検討する上では、「停電=数日で復旧する」という楽観的な前提ではなく、地域によっては1〜2週間規模の長期停電・断水を前提とした計画が必要になる。

また、南海トラフ沿岸には製造業・小売業が集積しており、新想定でも生産・サービス低下に伴う被害は45兆4000億円と見積もられている。サプライチェーンの寸断は、直接被災していない地域の企業にとっても、部材調達・物流の停止という形でIT基盤以外の側面からも事業継続に影響を与える点に留意したい。

5. 政府系システムへの影響

政府は2025年度末までに地方自治体の基幹システムをガバメントクラウドへ移行する方針を掲げてきたが、令和7年12月末時点で標準化対象約3万4592システムのうち特定移行支援システムに該当する見込みは約26%にとどまっており、移行は依然として進行中の段階にある。南海トラフ地震が今後30年以内に高い確率で発生し得ることを踏まえると、移行完了前の過渡期における自治体システムの災害耐性（オンプレミス環境の耐震性、ガバメントクラウドへの接続経路の冗長性等）も論点となる。

ガバメントクラウドの調達仕様書に明記された地理分散要件（前述）は、今後の自治体システム設計における重要な指針になる。特に、東京・大阪の2点間DRだけでなく、震源域から離れた北海道・九州を組み合わせた構成が推奨される方向性がうかがえる。

6. IT視点での対策の方向性

• 3拠点以上への地理分散：東京・大阪の2リージョン運用に加え、震源域から離れた北海道・九州リージョンを組み合わせた3-2-1的なバックアップ設計を検討する。
• 長期停電を前提とした電源設計：72時間の自家発電備蓄を基本としつつ、新想定が示す1〜2週間規模の停電復旧期間を踏まえ、追加燃料供給契約や複数系統からの調達を確保する。
• 電源切替機構の実負荷試験：胆振東部地震の教訓として、UPS・自家発電への自動切替回路そのものの定期的な実負荷試験を行う。
• RPO/RTOの数値化と定期的な検証：「クラウドだから大丈夫」という前提を避け、復旧目標時点（RPO）・目標時間（RTO）を具体的な数値で定義し、実際のフェイルオーバー訓練で検証する。
• 通信手段の多重化：衛星通信（Starlink等）や複数キャリア回線の併用により、特定地域の基地局・海底ケーブル陸揚局の被災に備える。

まとめ

2025年の新被害想定は、死者数こそ微減したものの、経済被害額の増加や災害関連死の新規試算など、南海トラフ巨大地震の深刻さを改めて示すものとなった。ITシステムの観点で特に注意すべきは、国内データセンターの8割強、そして政府認定クラウドのうち外資系4社の国内リージョンが東京・大阪の2拠点に集中している一方、大阪が南海トラフの震源域にきわめて近いという構造的な脆弱性である。2026年3月に正式認定された国産唯一のさくらインターネットが石狩・東京という異なる組み合わせを取っている点は、分散の選択肢として注目に値する。ガバメントクラウドの調達仕様に見られるように、政府側でも北海道・九州を含めた分散の重要性が認識され始めている。「東京・大阪2拠点分散＝十分な災害対策」という従来の常識を見直し、震源域から十分離れた第三・第四の拠点を組み込んだ設計へと移行することが、今後のIT防災における重要な論点になるだろう。

参考文献・出典

• 内閣府 南海トラフ巨大地震対策検討ワーキンググループ「南海トラフ巨大地震 最大クラス地震における被害想定について」（2025年3月31日）
• 内閣府 中央防災会議「南海トラフ巨大地震対策について（報告書）」（令和7年3月）
• 総務省・経済産業省「デジタルインフラ（DC等）整備に関する有識者会合」事務局説明資料（2024年5月）
• 内閣官房 GX実現に向けた専門家ワーキンググループ（第8回）「データセンター等のデジタルインフラ整備の現状と課題について」（2024年10月）
• デジタル庁「デジタル庁におけるガバメントクラウド等の整備のためのクラウドサービスの提供－令和8年度募集－調達仕様書」
• 総務省北海道総合通信局「平成30年北海道胆振東部地震・ブラックアウト 通信・放送の被害状況と当局の対応」（2019年1月）
• 参議院 総務委員会調査室「東日本大震災における情報通信分野の主な取組」
• さくらインターネット「石狩データセンター10周年－挑戦の軌跡－」
• 日経クロステック「データセンターと通信への影響、北海道地震で生かされた経験」
• さくらインターネット株式会社「令和5年度および令和8年度 ガバメントクラウドサービス提供事業者に採択」（2026年3月27日）
• ITmedia NEWS「さくらインターネットのクラウドサービス、ガバメントクラウド正式認定 技術要件満たす」（2026年3月27日）
• FJcloud-V「北米リージョン(us-east-1)の提供終了について」

Amazon EVS（Amazon Elastic VMware Service）完全解説

Amazon EVS（Amazon Elastic VMware Service）完全解説

VMware on AWS後継の本命か？競合との徹底比較 ― インフラエンジニア向け技術解説（2026年6月時点）

⚡ TL;DR
Amazon EVSは2025年8月5日にGAした、VCF（VMware Cloud Foundation）を顧客自身のVPC内・EC2ベアメタル上でセルフマネージドで動かすAWSネイティブサービス。東京リージョン（ap-northeast-1）はGAから対応。最小4ホスト・最大32ホスト（2026年5月に16→32に拡張）、BYOLのVCFライセンスが必須。VMC on AWS「再販終了」後の実質的な移行先だが、パッチ・アップグレード・障害ホスト交換は顧客責任という点がVMCとの最大の違い。東京4ホスト最小構成でのAWS側コストはオンデマンドで約$40,600/月（VCFライセンス別途）。

1. Amazon EVSとは

Amazon Elastic VMware Service（Amazon EVS）は、AWSがVMware Cloud Foundation（VCF）を顧客のAmazon VPC内に自動デプロイし、EC2ベアメタルインスタンス（i4i.metal等）上でそのまま動かすためのAWSネイティブサービスだ。AWSがインフラプロビジョニングとハードウェア管理を担い、顧客はESXi・vCenter・NSX・SDDC Managerへのフルルート権限を持ちながらVMwareワークロードを運用できる。

沿革を整理すると、AWS × VMware（現Broadcom）の協業は2016年に始まり、フルマネージドの「VMware Cloud on AWS（VMC）」として展開されてきた。しかし2024年2月のBroadcomによるVMware買収後のライセンス改定、2024年4月30日のAWSによるVMC再販終了を経て、2024年末のre:Invent 2024でAWSがEVSを発表。2025年6月9日にパブリックプレビュー（東京含む5リージョン）、同年8月5日に一般提供（GA）を開始した。GA対応リージョンは米国東部（バージニア北部・オハイオ）、米国西部（オレゴン）、アジアパシフィック（東京）、欧州（フランクフルト・アイルランド）の6リージョン。その後2025年11月にムンバイ・シドニー・カナダ中部・パリに拡張されている。

AWSによるVMware移行戦略の位置づけ
EVSはAWSが「プリミティブなサービス（ビルディングブロック）」と位置づけており、顧客がVMwareワークロードをそのままAWSで動かす最速経路として提供される。AWSには他にAWS Transform（エージェント型AI移行）、Application Migration Service（MGN）、コンテナ化（ECS/EKS）など複数の移行経路があるが、EVSは「再プラットフォーム・リファクタリング不要」の選択肢だ。

2. アーキテクチャと技術仕様

SDDC構成（Consolidated Architecture）

EVSはVCFの「Consolidated（統合）アーキテクチャ」を採用する。これは管理コンポーネントとワークロードVMを単一クラスタ上に同居させるモデルで、自動デプロイされる管理コンポーネントは以下の通りだ。

• vCenter Server（1台）
• SDDC Manager（1台）
• NSX Manager（3台クラスタ構成）
• NSX Edge（2台、Active/Standby）
• Cloud Builder（デプロイ完了後に自動削除）

これらの管理VMはvSphereリソースプールで分離されるが、ワークロードVMと同一ESXiホスト上で動作する。VCFのSeparated Architecture（管理ドメインとワークロードドメインを物理分離）はEVSでは現時点で非対応。

ネットワーク構成

EVSのネットワークは2層構造だ。外側はAmazon VPC（アンダーレイ）、内側はNSXオーバーレイ（T0/T1ゲートウェイ）。T0ゲートウェイがVPC Route Server Endpointとの間でeBGPピアリングを確立し、NSXオーバーレイのCIDRをVPCルートテーブルにアドバタイズする仕組み。EVS環境ごとに2つのVPC Route Server Endpointが必須。

構成上の制約として、T0ゲートウェイは1環境あたり1台のみ、シングルAZ構成のみ（マルチAZ非対応）という点は設計で重要な検討事項となる。オンプレミスとの接続はTransit Gateway経由のDirect Connect（Transit VIF）またはSite-to-Site VPN（TGWアタッチメント）が必要で、Direct Connect Private VIFやVGWベースVPN、VPCピアリングは非対応。

ストレージ

プライマリストレージはvSAN（ローカルNVMeインスタンスストア）。i4i.metalでは1ホストあたり約20.5 TiB rawのvSANキャパシティが使用可能（vSAN圧縮・重複排除有効時の実効容量はワークロード依存）。インスタンスストアはEphemeralであるため、VCFコマンドを経ずにEC2インスタンスを停止・終了するとデータを失う。外部ストレージとしてAmazon FSx for NetApp ONTAP（NFS/iSCSI）やPure Cloud Block Storeが対応している。

デプロイ所要時間はAWSコンソールのガイド付きワークフローまたはCLI/CloudFormationから約3時間で完了する。

⚠️ 注意：VMCから移行時に失われる機能
VMC on AWSで利用できた vDefend Advanced Threat Protection と VMware Live Cyber Recovery はEVSでは現時点で非対応。vSphere HA/DRSはセルフマネージドでの構成が必要。EDRS（Elastic DRS）もEVSでは使用不可。

3. 最小構成・最大構成（東京リージョン）

項目	i4i.metal（GA当初）	i7i.metal-24xl（追加）	東京リージョン対応
vCPU数	128 vCPU（64物理コア×HT）	96 vCPU（48物理コア×HT）	両タイプ対応
メモリ	1,024 GiB	768 GiB	―
ローカルNVMe	30 TB（vSAN: 約20.5 TiB raw/host）	約22.5 TiB raw/host	―
ネットワーク	75 Gbps	200 Gbps超	―
CPU世代	第3世代 Intel Xeon (Ice Lake) 3.5 GHz	第5世代 Intel Xeon Scalable (Emerald Rapids)	―
最小ホスト数	4ホスト固定（環境作成時）	4ホスト固定（環境作成時）	4ホスト〜（キャパシティ予約推奨）
最大ホスト数	32ホスト（※1）	32ホスト（※1）	クォータ引き上げリクエスト必要
VCFライセンス要件	最低256コア（4ホスト×64物理コア）	4ホスト×コア数分	BYOL必須（Broadcom購入）

（※1）2026年5月19日付けAWS What's NewにてGA当初の上限16から32へ倍増。サービスクォータ引き上げリクエストが必要。

その他の前提条件

• AWSサポートプラン：Business Support以上が必須（環境作成失敗条件）。なお2027年1月以降、Business Supportは廃止予定でBusiness Support+（$29/月〜）が実質最低基準に移行する。
• VPC：最小/22のCIDRブロック、Route Server Endpoint×2（それぞれ専用ピア）が必要。IPv6は現時点で非対応。
• 対応VCFバージョン：5.2.1、5.2.2（2026年6月時点）。VCF 9は現時点で非対応。
• デプロイ所要時間：約3時間（コンソールまたはCLI/CloudFormation）。

4. 最小構成で動くワークロードVM数の比較

インフラエンジニアがサービス選定で最も気にするポイントの一つが「最小構成でどれだけのVMを動かせるか」だ。各サービスの最小構成におけるワークロードVM稼働数の推計を以下の前提で比較する。

推計前提条件
標準VM：2 vCPU / 8 GiB RAM / 100 GiB diskの小中規模汎用VM想定。管理コンポーネント消費分（VCF: 約24 vCPU・200 GiB、Nutanix CVM: ノードあたり12 vCPU・32 GiB等）を控除。vSphere HAの1ノード分フェイルオーバー予約（25%相当）を控除。CPUオーバーコミット比は2:1適用。VDI（1 vCPU/4 GiB）は約2倍、DBサーバー（8 vCPU/32 GiB）は約1/4が目安。

サービス	最小ノード数・仕様	総vCPU / 総RAM	推計ワークロードVM数	制約要因・特記
Amazon EVS	4 × i4i.metal 128 vCPU / 1,024 GiB	512 vCPU 4,096 GiB	200〜400 VM	最小4ノードのため他サービスより容量大。HAで1ノード分（1,024 GiB）確保。RAM制約が支配的。vSAN容量は十分（FTT=1で約50 TiB usable）。
Azure VMware Solution	3 × AV36 36コア / 576 GiB	216 vCPU 1,728 GiB	70〜150 VM	Microsoft管理コンポーネントが46 GHz CPU・171 GiB RAMを予約（3ノード中の約50%に相当）。RAM・CPUともに制約。HA1ノード分を除くと実効容量は小さい。
Google GCVE	3 × ve1-standard-72 72 vCPU / 768 GiB	216 vCPU 2,304 GiB	100〜200 VM	AVS AV36よりメモリ1ノードあたり192 GiB多い（768 vs 576 GiB）。フルマネージドのためHA予約がGoogle任せで透明度低め。
Oracle OCVS	3 × BM.DenseIO.E4.128 128 OCPU / 2,048 GiB	384 OCPU 6,144 GiB	200〜500 VM	最大RAMを誇る構成。旧DenseIO2.52（52 OCPU/768 GiB）では80〜170 VM程度。標準shapeはOCI Block Storageを使いvSAN不要。東京リージョン（ap-tokyo-1）はOCVSの対応状況を個別確認要。
NC2 on AWS （Nutanix）	3 × i4i.metal 128 vCPU / 1,024 GiB	384 vCPU 3,072 GiB	150〜300 VM	CVM（Controller VM）がノードあたり12 vCPU・32 GiB消費。最小3ノード。最大28ノード（7 placement group対応リージョン）。ハイパーバイザはAHV（ESXiではない）。

※ 推計値。実際のVM数はVMサイズ・CPUオーバーコミット率・ワークロード特性・vSAN利用可能容量によって大きく変動する。VDI（1 vCPU/4 GiB）なら約2倍、DBサーバー（8 vCPU/32 GiB）なら約1/4が目安。

📌 重要な注意点：最小ノード数の差
EVSは最小4ノード、他のサービスは最小3ノードという構造差がある。EVSの「200〜400 VM」はこの1ノード多い構成に起因する部分が大きい。同じ3ノードに換算すると3×i4i.metalで約150〜300 VM相当になり、NC2（AHV）と同程度の容量になる点に注意。

5. VMware Cloud on AWS（VMC）との比較

比較項目	Amazon EVS	VMware Cloud on AWS（VMC）
サービスモデル	セルフマネージド（AWSネイティブサービス）	フルマネージド（Broadcom運営）
デプロイ先	顧客自身のVPC内	Broadcom管理SDDC（顧客VPC外）
vCenter/ESXi管理権限	フルルート権限あり（VIB導入等の自由度高い）	Broadcomが管理、顧客は限定アクセス
パッチ・アップグレード責任	顧客（またはパートナー）責任	Broadcom責任
障害ホスト交換	顧客責任（AWSに連絡し交換手続き）	Broadcom責任
ライセンスモデル	BYOL必須（VCFポータビリティ）	Broadcom直販サブスクリプション（ライセンス込み）
最小ホスト数	4ホスト	2ホスト〜（i3.metal）
EDRS（弾力的リソーシング）	非対応（セルフ管理必要）	対応
vDefend ATP	現時点で非対応	対応
AWSからの販売	AWSが提供（AWSアカウント直結）	2024年4月30日にAWS再販終了・Broadcom直販のみ

VMC→EVS移行パス：VMware HCXを使ってVMC on AWS→EVSへのvMotion/Bulk/RAV移行が公式サポートされている。VMC GovCloudのEOLなども背景にあり、VMC利用中で将来不透明感を感じている組織にとってEVSは最も自然な移行先だ。EVSデプロイ時にHCXのプライベート接続方式（Direct Connect または Public Internet）を一度選択すると変更不可な点に注意。

6. NC2 on AWS（Nutanix）との比較

NC2 on AWSとEVSは「AWSベアメタル上でオンプレの仮想化環境をそのままクラウドに持ち込む」という方向性は共通しているが、ハイパーバイザと用途が根本的に異なる。

比較項目	Amazon EVS	NC2 on AWS（Nutanix）
ハイパーバイザ	VMware ESXi	Nutanix AHV（VMware非依存）
管理ツール	vCenter / SDDC Manager / NSX	Prism Central / Prism Element
ストレージ	vSAN（ローカルNVMe）＋外部（FSx等）	Nutanix DSF（CVM管理）＋EBSストレージ拡張可
最小ノード	4ノード	3ノード（2ノードは非対応）
最大ノード	32ノード/環境	28ノード/クラスタ（7 placement group対応リージョン）
利用可能インスタンス	i4i.metal、i7i.metal-24xl	i3.metal、i3en.metal、i4i.metal、i7ie/i7i.metal-24xl/48xl、z1d.metal等
VMware移行ツール	HCX（vMotion/Bulk/RAV）	Nutanix Move（ESXi→AHV変換が必要）
クラスタHibernate	非対応	対応（S3退避でコスト最適化可）
位置づけ	VMware継続（スキル・ライセンス・ツール維持）	VMware脱却（AHVへのハイパーバイザ変換）

判断軸：VMwareからの移行時にESXi・vCenter・NSXのスキルとライセンスを維持したければEVS。Nutanixをオンプレで採用中・採用予定であればNC2。VMwareから完全脱却してコスト削減を狙うならNC2（ただしNutanix Moveでのハイパーバイザ変換工数が発生）。

7. 競合サービス比較（AVS / GCVE / OCVS）

比較項目	Amazon EVS	Azure VMware Solution（AVS）	Google Cloud VMware Engine（GCVE）	Oracle Cloud VMware Solution（OCVS）
管理モデル	セルフマネージド	マネージド寄り（Microsoft管理）	フルマネージド（Google管理）	顧客フルアクセス型（EVSに最も近い）
最小ノード	4ノード	3ノード	1ノード（PoC）/ 3ノード（本番）	1ノード（dev）/ 3ノード（本番）
最大ノード/クラスタ	32ノード/環境	96ノード/プライベートクラウド（最大12クラスタ×最大16ノード）	64ノード（全クラスタ合計）	64ノード/クラスタ（最大15クラスタ）
マルチAZ	非対応（シングルAZのみ）	Stretched Cluster対応（マルチAZ）	Stretched Cluster対応（マルチゾーン）	フォルトドメイン単位（シングルAD）
VCFライセンス	BYOL必須	2025年11月以降新規ノードはBYOL基本	Google包含（ライセンス込み）	Oracle包含またはBYOL（移行フェーズ依存）
HCX	対応（HCX Advanced/Enterprise）	HCX Advanced 包含	HCX 包含	HCX 包含
東京/日本リージョン	ap-northeast-1（東京）対応済み	Japan East（東日本）対応	asia-northeast1（東京）対応	ap-tokyo-1（東京）対応状況は要確認
デプロイ時間	約3時間	約3〜4時間	約30〜60分（高速プロビジョニング）	約2〜4時間

各サービスの特徴整理

• AVS（Azure）：Azureエコシステム（Azure NetApp Files、Azure Elastic SAN等）との統合が強み。Stretched Clusterでマルチ可用性ゾーンに対応できる点がEVSと異なる大きな差別化。マネージド寄りのため運用負荷は低め。
• GCVE（Google）：フルマネージドで運用負荷が最も低い。1ノードから試せる柔軟性と30〜60分の高速プロビジョニングが評価される。ve2世代（128 vCPU/2TB RAM）への世代交代が進行中。
• OCVS（Oracle）：ESXiルートアクセスでEVSに最も近い運用モデル。OCI Block Storage（外部ストレージ）との組み合わせで「コンピュートとストレージの独立スケーリング」が可能という独自性を持つ。46以上のグローバルリージョンで最大のカバレッジ。

8. コスト・ライセンス（東京リージョン試算）

AWS側料金の構成（3要素）

1. EC2インスタンス料金（i4i.metal）：オンデマンド・1年/3年 Savings Plan（ISP）・予約で割引選択可
2. EVSコントロールプレーン：$0.92/usage-hour（ホスト数×時間）
3. VPC Route Server Endpoint：$0.20/endpoint-hour（2 endpoint必須、標準料金の73%割引適用後）

東京リージョン（4×i4i.metal、730時間/月）試算

料金タイプ	EC2（i4i.metal×4）	EVSコントロールプレーン	Route Server（×2）	合計/月（AWS課金のみ）
オンデマンド	$12.883/hr × 4 × 730h ≒ $37,618	$0.92 × 4 × 730h ≒ $2,686	$0.20 × 2 × 730h ≒ $292	約 $40,600 /月
3年 ISP（推計）	≒ $17,377	≒ $2,686	≒ $292	約 $20,355 /月

※ EC2 i4i.metalの東京オンデマンド単価はサードパーティ価格情報ベース。3年ISPは米国比から推計した参考値。正確な見積もりはAWS Pricing Calculator（ap-northeast-1）で実施のこと。VCFライセンスコスト（Broadcom別途購入）は含まず。

Broadcom VCFライセンスについて

• BYOL（ライセンスポータビリティ）必須：VCFサブスクリプション＋ポータビリティ権が必要（2023年12月13日以降購入のVCF 5.1+に付帯）。
• 最低コア要件：256コア（4×i4i.metal の初期デプロイ分）＋vSAN 110 TiB容量ライセンス。
• 課金単位：物理コア単位（16コア/CPU最小）。かつて2025年4月に追加された「72コア/インスタンス最小」の要件は後に撤回された模様（契約時に最新条件を要確認）。
• クラウドプロバイダー経由ライセンスにポータビリティ権なし：パブリッククラウドプロバイダー経由で取得したライセンスはポータビリティ対象外。
• Windows Serverライセンス：EVSを通じてVM単位での取得が可能（$0.046/vCPU-hour）。

9. 移行シナリオ（VMware from ― HCX活用）

EVSはVMware HCX（VCF Operations HCX）を公式サポートする。HCXはデフォルトではEVS環境にインストールされておらず、EVSデプロイ後に別途構成が必要。

接続方式（デプロイ時に一度のみ選択・変更不可）

• プライベート接続：Direct Connect（Transit VIF + Direct Connect Gateway + Transit Gateway）またはSite-to-Site VPN（TGW VPNアタッチメント）経由。本番・大規模移行に推奨。
• パブリックインターネット接続：IPAMで公開IP割当、隔離されたHCX用パブリックVLANサブネットが必要。帯域幅制約に注意（WAN最適化機能HCX-WOの活用を推奨）。

主な移行パターン

• オンプレVMware → EVS：HCXサイトペア設定→Service Mesh作成→vMotion/Bulk/RAV移行。IPアドレス変更不要、運用ランブック変更不要で移行可能。
• VMC on AWS → EVS：HCXプライベート接続（Transit Gateway経由）でVMC→EVS間のvMotion移行。
• DR用途（EVSをDRサイトに）：本番オンプレ/クラウド→EVSをDRターゲットとしてHCX RAVで非同期レプリケーション。

HCXの主な移行タイプ：Cold Migration、vMotion（無停止・単一VM）、Bulk Migration、Replication Assisted vMotion（RAV：並列・スケジュール・無停止）、OS Assisted Migration（非vSphere）、L2 Network Extension（IP変更不要）。

10. 強みと弱みまとめ

✅ 強み

• VMwareスキル・ツール・ランブック維持のまま移行可能
• 顧客VPC内デプロイで200以上のAWSサービスと同一VPC内で直結
• ESXi/vCenter/NSX/SDDC Managerへのフルルート権限（VIBインストール等も可能）
• 約3時間でVCF環境が自動展開
• HCXによるIP変更不要のシームレス移行
• VCFライセンスポータビリティでBroadcom投資を活用
• Kyndryl・DXC・富士ソフト等のパートナーマネージドサービスで運用負荷を外出し可能
• 2026年5月以降、最大32ホスト/環境に拡張（当初16）

❌ 弱みと制約

• セルフマネージド：ESXi/vSAN/NSXのパッチ・アップグレード・障害ホスト交換が顧客責任
• シングルAZのみ：マルチAZ（Stretched Cluster）非対応
• VCF 9非対応（2026年6月時点）：5.2.1/5.2.2のみ
• 最小4ホスト：競合（3ホスト〜）より参入コストが高い
• T0ゲートウェイは1環境あたり1台のみ
• vDefend Advanced Threat Protectionが現時点で非対応
• Business Support（最低）以上が必須（2027年以降はBusiness Support+以上）
• BroadcomのVCFライセンスを別途調達する必要があり、ライセンスコストが不確定
• 接続方式（プライベート/パブリック）はデプロイ時の一度きりの選択で後から変更不可

11. まとめ ― 評価・選定の推奨ステップ

Amazon EVSは「VMware資産・スキルをそのまま維持しながらAWSクラウドの恩恵を受ける」という課題に対して2025年8月にGAした現実解だ。VMC on AWSの再販終了後を睨んだ選択肢として、特に大規模なVMwareデータセンター撤退・DR強化・段階的モダナイゼーションを検討している組織に刺さるサービスといえる。

一方で、セルフマネージドゆえの運用負荷（パッチ・アップグレード）、最小4ホストという参入コスト、VCF 9非対応、シングルAZ制約という限界点も明確だ。これらを踏まえた評価フローは以下になる。

評価・判断フロー
① VMwareを継続するか脱却するか → 脱却ならNC2（AHV）またはAWSネイティブ移行（MGN等）を検討
② マルチAZ（Stretched Cluster）が必須か → 必須ならAVS（Azure）またはGCVEを検討
③ 最小3ノードで十分か → 3ノードで十分ならAVS/GCVE/OCVSが有利
④ VCF 9が早期に必要か → 必要なら2026年時点でEVSは非対応のため待機またはオンプレVCFを維持
⑤ セルフマネージドの運用負荷を自社で吸収できるか → できない場合はKyndryl・DXC・富士ソフト等のパートナーマネージドを前提に検討
⑥ 3年コミットが可能なワークロードがあるか → あればSavings Planで東京でも月額$20,000台（4ホスト、AWS課金のみ）まで削減可能

本記事で修正・更新した主な情報（ファクトチェック結果）
・最大ホスト数：16ホスト → 32ホストに修正（2026年5月What's New確認）
・パブリックプレビュー開始：2025年6月9日（東京含む5リージョン）確認
・サポートプラン：Business Support以上（最低要件）を公式ドキュメントで確認。2027年1月以降はBusiness Support+が実質最低基準となる予定。
・EVSで現時点非対応機能（vDefend ATP、VMware Live Cyber Recovery）を追記
・NC2最大ノード数（28ノード/クラスタ）を追記
・AVSの管理コンポーネント予約（46 GHz CPU / 171.88 GiB RAM）に基づくVM数試算を追記

本記事は2026年6月時点の公開情報（AWS公式ドキュメント・What's New・各クラウドベンダー公式資料）に基づいています。料金・仕様・対応リージョンは変更されることがあるため、最新情報はAWS Pricing Calculator・各サービス公式ページで確認してください。

マネージドAI推論プラットフォーム徹底比較：Amazon Bedrock / Azure AI Foundry / Google Vertex AI / OCI Generative AI（2025〜2026年6月版）

クラウド上で生成AIを本番利用する際、インフラ運用を意識せずに多様なLLMを呼び出せる「マネージドAI推論プラットフォーム」の重要性が急速に高まっている。2026年6月時点で主要プレイヤーとなっているのが、Amazon Bedrock・Azure AI Foundry・Google Vertex AI・OCI Generative AIの4サービスだ。本記事では、対応モデル・料金・日本リージョン/主権AI対応・RAG/エージェント機能・セキュリティ・市場シェアの6軸で徹底比較する。

1. サービス概要と位置づけ

まず4サービスの基本的な立ち位置を整理する。いずれも「APIを叩けば複数のLLMを呼び出せるマネージドサービス」という点では共通だが、強みの方向性は大きく異なる。

項目	Amazon Bedrock	Azure AI Foundry	Google Vertex AI	OCI Generative AI
提供元	Amazon Web Services	Microsoft	Google Cloud	Oracle Cloud Infrastructure
最大の強み	モデルの幅・AWSエコシステム統合・JP Geo推論	OpenAI最新モデルへの最速アクセス・M365統合	Gemini自社モデル・MLOps・BigQuery統合	Oracle DB統合・コスト・ZDR・ソブリンAI
主な対象ユーザー	AWS中心の企業・金融・公共	Microsoft/Azure中心・Office利用企業	GCP利用企業・データサイエンス重視	Oracle DB資産保有・コスト重視・規制業界
旧名称/統合経緯	—（2023年4月GA）	旧Azure AI Studio + Azure OpenAI Serviceを統合（2024年）	2026年Cloud NextでGemini Enterprise Agent Platformへ統合	—（2024年1月US GA、同年12月大阪提供開始）

2. 対応モデル・LLMラインナップ

モデルの選択肢はサービスの根幹だ。4社の提供モデルを比較する。

カテゴリ	Amazon Bedrock	Azure AI Foundry	Google Vertex AI	OCI Generative AI
自社ファーストパーティ	Amazon Nova（Micro/Lite/Pro/Premier）	OpenAI GPT-5.1/GPT-4o/o系/Phi-4シリーズ（Microsoft独占契約）	Gemini 2.5 Pro/Flash/Flash-Lite、Gemini 3.x系、Imagen、Veo	なし（マルチプロバイダー特化）
Anthropic Claude	Opus 4.6/4.7、Sonnet 4.5/4.6、Haiku 4.5（東京・大阪）	Claude系はModel Catalog経由で一部提供	Model GardenでClaude Opus/Sonnet/Haikuを一級市民として提供	非対応（2026年6月時点）
Meta Llama	Llama 3.3 70B、Llama 4系	Llama 3系	Model GardenでLlama対応	Llama 3.3/4 Maverick/Scout（大阪で提供）
Cohere	Command R+	一部提供	Model Garden経由	Command A（256Kコンテキスト）、Command A Vision/Reasoning（大阪）
xAI Grok	—	Grok系をModel Catalog経由で提供	—	Grok 4系（OCI DCでホスト、大阪対応）
OpenAI gpt-oss（オープンウェイト）	2025年9月〜。ただし東京での日本国内限定提供は未確認。	gpt-5.1など最新クローズドモデルが主力	—	gpt-oss-120b/20b（大阪でGA、2025年12月〜）。OpenAI互換APIキーで接続可能
Mistral	Large 2、Ministral 3B等	各種Mistralモデル	Model Garden経由	一部提供
総モデル数	15社以上のプロバイダー	11,000以上（コミュニティ含む）	200以上（Model Garden）	十数モデル（厳選型）

⚠️ 注意：Azure AI FoundryでのOpenAIモデルは「Microsoft FoundryモデルとしてAzureが販売」する形態と「パートナー・コミュニティモデル」に分かれる。最新GPT系は前者（Azure直販）、その他はModel Catalog経由。モデルのリージョン提供状況は頻繁に変わるため、本番採用前に公式ドキュメントを要確認。

3. 料金・コスト構造

代表的なモデルの料金（2026年6月時点、オンデマンド、100万トークンあたりUSD）を比較する。なお料金は頻繁に変動するため、本番採用前は各社公式ページで最新値を必ず確認すること。

モデル	入力（$）	出力（$）	経由サービス	備考
Claude Sonnet 4.5/4.6	$3.00	$15.00	Bedrock / Vertex AI	200K超は2倍料金。JP Geo使用時は+10%（Bedrock）
Claude Opus 4.6/4.7	$5.00	$25.00	Bedrock	JP Geo（日本国内限定）は未対応。グローバルCRISのみ
Claude Haiku 4.5	$1.00	$5.00	Bedrock / Vertex AI	JP Geo対応（Sonnet 4.5と同様）
Gemini 2.5 Pro	$1.25（200K以下）/ $2.50（200K超）	$10.00（200K以下）/ $15.00（200K超）	Vertex AI	推論トークンも出力として課金される点に注意
Gemini 2.5 Flash	$0.30	$2.50	Vertex AI / Gemini API	—
Gemini 2.5 Flash-Lite	$0.10	$0.40	Vertex AI / Gemini API	主要モデルで最安値クラス
Gemini 3.5 Flash（新）	$1.50	$9.00	Vertex AI / Gemini API	2026年5月19日リリース。コーディング・エージェント性能改善
GPT-4o	$2.50	$10.00	Azure AI Foundry	Global Standard料金。Data Zone/Standardは異なる場合あり
GPT-4.1	$2.00	$8.00	Azure AI Foundry	1Mトークンコンテキスト。GPT-4oより若干安価
Amazon Nova Pro	$0.80	$3.20	Bedrock	AWS自社モデル。マルチモーダル対応
Amazon Nova Micro	$0.035	$0.14	Bedrock	全主要プロバイダー中最安値クラス
Llama 3.3 70B（Bedrock）	$0.72	$0.72	Bedrock	入出力均一料金
OCI gpt-oss-120b	約$0.15	—	OCI Generative AI（大阪）	※二次情報。公式価格ページで要確認
OCI Cohere Command（旧世代）	文字課金（1文字=1トランザクション）	—	OCI Generative AI	新モデルはトークン課金に移行中

💡 コスト最適化のポイント：バッチ推論は各社50%割引。プロンプトキャッシュはBedrock/Vertexで最大90%削減。OCI gpt-ossは大阪リージョンでOpenAI互換APIキーを使えば、ベースURLを変えるだけでアクセス可能（2026年1月〜）。プロビジョンドスループット（Bedrock）・PTU（Azure）は月150〜200Mトークン超で損益分岐となる場合が多い。

4. 日本リージョン・主権AI対応

日本の金融・公共・製造業では「データを国内処理する」要件が重要だ。各社の対応状況を詳細に確認する。

項目	Amazon Bedrock	Azure AI Foundry	Google Vertex AI	OCI Generative AI
日本リージョン	東京（ap-northeast-1）/ 大阪（ap-northeast-3）	東日本（Japan East）	東京・大阪リージョンあり	大阪（Japan Central）のみ。東京はGenerative AI未提供
日本国内推論完結	JP Geo CRIS対応（Claude Sonnet 4.5・Haiku 4.5のみ）。東京↔大阪のみでルーティング。Opus系は国内限定未対応	Japan Data Zoneなし。最新モデルはGlobal Standard（全世界ルーティング）またはData Zone（EU/US）経由が多い	「ML Processing in Japan」を訴求。Gemini世代によって日本リージョン未対応のケースあり（要確認）	大阪でOCIホストモデル（gpt-oss/Llama/Grok/Cohere）は国内完結。ただし大阪のGemini 2.5 Pro/Flashは外部呼び出し（Google Asia Pacific経由）で国内完結ではない
ISMAP登録	✅ 登録済み（2021年3月〜、更新継続）	✅ Azure OpenAI Service ISMAP登録済み（2024年2月）	✅ Vertex AI ISMAP登録済み	✅ OCI ISMAP登録済み（2021年6月）
ガバメントクラウド	✅ 採択済み（令和4年度〜）	✅ 採択済み（令和4年度〜）	✅ 採択済み（令和4年度〜）	✅ 採択済み（令和4年度〜）
主権AI・ソブリンクラウド	JP Geo CRISがデータレジデンシー要件に対応。SCP/IAMで国内強制可能	日本向けソブリン構成は非公式。Azure Sovereignは特定国向け	国内処理完結を訴求するが、モデル世代ごとに要確認	ZDR（ゼロデータ保持）エンドポイント、専用AIクラスタ、富士通・NTTデータとのOracle Alloyソブリンクラウドで差別化
日本向け投資	2027年までに2.26兆円を東京・大阪インフラに投資予定（2024年1月発表）	日本でのデータセンター拡張継続中	東京・大阪リージョン継続強化	富士通・NTTデータ・NRI・SoftBank・NS SolutionsとOracle Alloy展開中

⚠️ ファクトチェック重要注意：BedrockのJP Geo（日本国内クロスリージョン推論）はClaude Sonnet 4.5・Haiku 4.5のみ対応（2026年6月時点）。Claude Opus 4.7は東京リージョンで利用可能だが、JP Geo（日本国内限定ルーティング）は未対応で、グローバルCRISまたはシングルリージョン利用となる。また、OCI大阪でのGemini 2.5 Pro/Flashは推論がGoogleのAsia Pacific設備で処理されるため、日本国内完結とはならない点に注意が必要。

5. RAG・エージェント機能

単なるLLM呼び出しを超えた「RAG構築」「エージェント」「ワークフロー自動化」機能が各社の差別化点になっている。

機能カテゴリ	Amazon Bedrock	Azure AI Foundry	Google Vertex AI	OCI Generative AI
RAG・ナレッジベース	Knowledge Bases（Managed/Self-managed）。S3 Vectorsでベクトルストアコスト最大90%削減	Foundry IQ（SharePoint/Fabric/Bing grounding）、Azure AI Search統合	RAG Engine（GA）、Vertex AI Search（現Agent Search）、Vector Search	ベクトル検索、NL2SQL（SQL Search）、OCI Responses APIのFile Search
エージェント機能	Bedrock AgentCore（Runtime/Gateway/Memory/Identity/Browser/Code Interpreter）、Bedrock Flows	Foundry Agent Service、Microsoft Agent Framework（2025年12月〜）	Agent Builder（ADK＋Agent Engine）、100以上のコネクタ	OCI Generative AI Agents（大阪：2025年4月〜）、ホスト型エージェント
MCP対応	✅ AgentCore Gateway経由でMCP対応	✅ 1,400以上のMCP対応ツール、Toolbox（MCP互換エンドポイント）	✅ MCP対応（A2Aプロトコルも提唱・Linux Foundationへ寄贈）	✅ OCI Responses APIのMCP Calling対応
マルチエージェント・A2A	✅ A2A対応、LangChain/CrewAI/LlamaIndex/Strands統合	✅ A2A対応、Entra Agent ID（エージェントID管理）	✅ A2Aプロトコル（Googleが提唱）	マルチエージェント構成可能だがA2A対応は限定的（要確認）
OpenAI互換API	—（独自SDK/API）	✅ Azure OpenAI Service互換	—（独自SDK）	✅ OCI Generative AI APIキー（2026年1月〜）でOpenAI互換、ベースURL変更だけで移行可能

6. セキュリティ・コンプライアンス

項目	Amazon Bedrock	Azure AI Foundry	Google Vertex AI	OCI Generative AI
認証・認可	IAM、PrivateLink（VPCエンドポイント）	Entra ID/RBAC、Private Networking（BYO VNet）	IAM、VPC Service Controls	IAM、専用AIクラスタ（テナンシー専有GPU）
プロンプト保護・ガードレール	Bedrock Guardrails（コンテンツフィルタ・PII・プロンプトインジェクション対策・Automated Reasoning checks）	Content Safety、Azure AI Guardrails（XPIA対策含む）、Purview連携	Model Armor（プロンプトインジェクション対策）、Content filters	OCI Guardrails、ZDRエンドポイント
主要認証	SOC2、ISO 27001/27017/27018、HIPAA、GDPR、CSA STAR Level 2、FedRAMP High（GovCloud）	SOC2、ISO、HIPAA、HITRUST、FedRAMP High	SOC2、ISO 27001、HIPAA、FedRAMP High（2025年3月取得）	SOC2、ISO、PCI DSS、FISC安全対策基準、3省ガイドライン、政府統一基準、FedRAMP
ISMAP	✅（157サービス、東京・大阪含む）	✅（Azure OpenAI Service）	✅	✅（2021年6月〜）
学習データ利用	デフォルトでモデル学習に使用しない	デフォルトでモデル学習に使用しない	有償API利用時はモデル改善に使用しない	ZDRエンドポイント利用でデータ保持ゼロ

💡 ISMAP生成AIの重要動向（2026年1月）：ISMAPポータルが「生成AIサービスに関する留意点」を公表。Bedrock・Vertex AI・Azure OpenAI等の開発基盤がISMAP登録対象範囲に含まれていれば、その上で動く個々のLLMモデル（Claudeなど）は個別のISMAP登録が不要と整理された。政府機関が生成AIを調達しやすくなった点で、エンタープライズ向けに大きな意味を持つ。

7. 市場シェア・普及状況

クラウドインフラ市場（IaaS+PaaS）のシェアは、Synergy Research Group 2025年Q3時点でAWS 29%、Microsoft Azure 20%、Google Cloud 13%（上位3社で約62%）。生成AI市場の成長率はGartner予測で2025年に+76.4%（支出$644B）に達するとされる。エンタープライズAI推論プラットフォームは「Bedrock（モデル幅）」「Azure（OpenAI深度＋Microsoft統合）」「Vertex（ML/MLOps＋BigQuery）」の三つ巴で、OCIはOracle DB統合・コスト・主権AIで独自ポジションを確立している。

日本国内では、ソニーグループがBedrock AgentCoreで全社Agenticプラットフォームを構築、ベネッセ・パナソニックコネクト・宮崎銀行等がAzure OpenAIを採用、みずほ銀行はOracle Autonomous AI Databaseを共通データベース基盤に採用するなど、各社に有力な採用事例がある。

8. 選定推奨：どのサービスを選ぶべきか

こんな要件なら	推奨サービス	理由
AWS中心の企業 ＋ 日本国内データ完結必須（金融・公共）	Amazon Bedrock	JP Geo CRIS（Claude Sonnet 4.5/Haiku 4.5）でデータが東京↔大阪のみ。IAM/SCPでリージョン強制可能
Microsoft 365/Azure中心 ＋ OpenAI最新モデルを優先利用	Azure AI Foundry	GPT-5.1等の最速アクセス。ただしJapan Data Zoneなし。データレジデンシー要件がある場合は処理ロケーションを事前検証すること
Google Cloud/BigQuery中心 ＋ MLOps・データパイプライン重視	Vertex AI	FedRAMP High取得済み（2025年3月）、BigQuery・Workbench・Data Catalogとのシームレスな統合。Gemini日本リージョン対応状況は世代ごとに要確認
Oracle DB資産活用 ＋ OSS系モデルを大阪で完結 ＋ コスト最優先	OCI Generative AI	gpt-oss/Llama/Grokを大阪でホスト、ZDRエンドポイント、OpenAI互換APIキーで移行容易。Gemini系はGoogle外部呼び出しのため国内完結要件には不適
ソブリンAI・日本専用クラウド要件（Oracle Alloy）	OCI Generative AI ＋ Oracle Alloy	富士通Alloy（NRI/Fujitsu/NTT Data/SoftBank/NS Solutions）でソブリン要件を満たしたAI推論が可能

まとめ

4サービスはいずれもISMAP登録・ガバメントクラウド採択済みで「政府・金融が使えない」サービスはない。選定の実質的な差は次の3点に集約される。

① 使いたいモデル：GPT-5.x系を最速で使いたい → Azure AI Foundry一択。Claude・LlamaをAWSエコシステムで使いたい → Bedrock。Gemini自社モデルを使いたい → Vertex AI。gpt-ossを大阪でOSSとして使いたい → OCI。

② データレジデンシー要件の厳しさ：「推論処理も日本国内のみ」という最厳格要件 → BedrockのJP Geo CRISかOCI大阪（OCIホストモデル限定）。AzureとVertexはリージョン内処理を保証しにくいケースがある。

③ 既存クラウド資産：多くの企業にとって「今使っているクラウドのAI推論サービス」が最初の選択肢になることが多い。マルチクラウド戦略では、モデルごとに使い分ける「ベストモデル選択」アプローチも現実的だ。

※本記事は2026年6月時点の公式ドキュメント・二次情報に基づく。モデルラインナップ・料金・リージョン対応は週次で変動するため、本番採用前に各社公式ページで最新情報を必ず確認すること。OCI Generative AIの一部料金は動的読み込みのため二次情報に依拠している箇所があり要確認。