本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「システムアーキテクチャ」カテゴリ第3弾として、クラウドベンダーの選び方を解説する記事です。
「とりあえずAWSで」の一言が10年先の人材採用・月額コスト・障害対応・法規制対応まで決めます。AWS／Azure／Google Cloudは退出コストが最も高い部類の選定で、後からの移行はシステム全体の作り直しと同義です。
本記事のテーマについてさらに詳しく知りたい方は『AWSの基本・仕組み・重要用語が全部わかる教科書』も参考にしてみてください。
この記事の結論
- 新規・無指定ならAWS、Microsoft基盤ならAzure、AI・データ重視ならGCP
- 1つに寄せて深く使い込む（中途半端なマルチクラウドが最悪）
- ロックイン回避より既存資産との親和性とAI情報量で決める
この記事を読む前に
本記事はサーバーやネットワークといったインフラ寄りの用語が多めに登場します。IT用語にあまり馴染みがない方は、基礎編の「サーバーとクラウドの基本」と「Webサービスが動く仕組み」を先に読んでおくと格段に分かりやすくなると思います。また、読んでいて分からない用語が出てきたときは用語集で調べながら読み進められます。
そもそもクラウドベンダーとは何か
クラウドベンダーとは、ざっくり言えば「サーバーやデータベースをインターネット越しに貸してくれる会社」です。
賃貸マンションの管理会社を想像してください。自分で土地を買ってビルを建てる（オンプレミス）代わりに、管理会社が用意した部屋（サーバー）を借り、光熱費（従量課金）を払って使います。部屋の間取り変更（設定変更）はある程度自由ですが、ビル自体のルール（ベンダー仕様）には従う必要があります。代表格はAWS・Azure・Google Cloudの3社で、この3社で世界クラウド市場の約7割を占めています。
なぜベンダー選定が重要なのか
もしベンダー選定を軽く考えたらどうなるか。運用を始めると数百のサービスが絡み合い、他ベンダーへの移行はほぼ不可能になります。これがベンダーロックインと呼ばれる現象です。ベンダー選定は、その後の技術スタック・人材戦略・コスト構造を10年単位で決める判断です。
そして「いつでも移行できるようにしておく」という抽象化は、ほぼ例外なく過剰設計で終わります。ロックインは避けるものではなく、受け入れて深く使い込むものと考えるのが2026年時点の現実的な姿勢です。だからこそ、最初の選定に価値があります。
3大ベンダーの性格
2025年第3四半期の世界シェアはAWS約29%・Azure約25%・Google Cloud約13%で、3社合計で全体の約7割を占める「3強時代」が続いています。基本機能は3社とも揃っているため、差が出るのは個別サービスの完成度と「性格」です。
AWS ― 選んで後悔する確率が最も低い
AWSは2006年開始のクラウドの先駆けで、世界シェア首位を守り続けています。強みは「デファクトスタンダードであること」そのものです。書籍・ブログ・StackOverflowの記事数、GitHub上のTerraformモジュールの数、AWS経験者の数──どれも2位のAzureに2〜3倍の差をつけています。AI時代になってこの情報量の差がさらに効き、AIが吐くAWSコードの精度が他ベンダーより一段高い状況が生まれています。反面、250超のサービス数と複雑な料金体系が学習コストの壁になります。「指名なきプロジェクトはまずAWSから疑う」のが定石です。
Azure ― Microsoft基盤の企業の本命
Microsoft Azureは世界シェア第2位で、Office 365 / Microsoft 365を使っている企業にとって管理を一元化できる本命です。Active Directory（Entra ID）を軸にしたSSO・権限管理がシームレスに動き、金融・官公庁向けのコンプライアンス認定も充実しています。2023年以降の急成長の背景にはOpenAIとの独占提携があり、GPT系モデルをAzure OpenAI Service経由で企業向けに提供できることが、生成AI活用を重視する企業の採用を後押ししています。
Google Cloud ― AI・データ・Kubernetesの技術的リード
Google Cloud（GCP）は3番手ですが、BigQuery・GeminiなどのAI・データ分析系と、本家本元のGKE（Kubernetes）で他が追従できない水準を持ちます。継続割引でコストも安くなりやすい一方、「サービスを平気で畳む」という歴史的悪評があり（後述のIoT Core廃止等）、長期運用の安心感では一歩譲ります。機能比較では互角でも、この性格の違いは長期運用で効いてきます。
主要サービスの対応表
名称が違っても機能はほぼ同等です。基本構築に必要な機能はどこも揃っています。
| カテゴリ | AWS | Azure | GCP |
|---|---|---|---|
| 仮想マシン | EC2 | Virtual Machines | Compute Engine |
| コンテナ管理 | ECS / EKS | AKS | GKE |
| サーバーレス | Lambda | Functions | Cloud Functions |
| オブジェクトストレージ | S3 | Blob Storage | Cloud Storage |
| マネージドDB / NoSQL | RDS / DynamoDB | Azure SQL / Cosmos DB | Cloud SQL / Firestore |
| AI / ML | SageMaker / Bedrock | OpenAI Service | Vertex AI / Gemini |
なお3大ベンダー以外にも、さくらインターネット等の国産クラウド（データ主権・円建て課金）、無料枠が太いOracle Cloud、中国市場向けのAlibaba Cloudがありますが、特殊要件がない限り3大クラウドで十分です。官公庁・自治体は「ガバメントクラウド」認定ベンダー（AWS・Azure・GCP・Oracle・さくら）からの選定が前提になります。
どう選べばいいのか ― 規模別の3シナリオ
選定に「絶対の正解」はありません。どのベンダーでも必要な機能は揃っているため、自社の技術資産や制約条件との相性で決めます。
個人開発・スタートアップなら ― 情報量でAWS
情報量・無料枠・技術者確保のしやすさから、AWSが最も無難だと思います。AIに書かせたときの生成精度も最も高いので、少人数での立ち上げ速度に直結してくれます。AIプロダクトでBigQueryやGeminiを中核に据えるならGCPを選ぶ価値もありますが、「なんとなく」でAWS以外を選ぶ理由はほぼないでしょう。
中小SaaSなら ― 1つに寄せて深く使い込む
新規Web SaaSならAWSが第一候補です。重要なのはベンダーの選択そのものより「1つに寄せて深く使い込む」ことで、マネージドサービスを遠慮なく活用し、IaCで全構成をコード化します。データ分析が事業の中核ならGCP（BigQuery）も有力ですが、その場合も「分析だけGCP」の安易な2社併用は運用負荷を先に見積もってから判断します。
大企業なら ― 既存資産との親和性が最強の軸
Microsoft 365中核の企業ならAzureです。Entra ID・AD連携・Teams統合の統合コスト削減が、AWSの情報量優位を逆転させます。金融・保険の基幹系はFISC対応実績のあるAWSかAzure、官公庁はガバメントクラウド認定ベンダーが前提です。そして既に数年AWSで運用中なら、移行コストが高すぎるためAWS継続が合理的です。判定は現状と将来5年の両面で行います。機能差で選ぶ時代は終わり、既存資産との親和性が最も強い軸になりました。
なお「ベンダーロックイン回避」目的のマルチクラウドは、規制要件・M&A後のシステム散在・特定AI機能の部分利用・BCP要件といった明確な理由がある時だけ有効です。「なんとなくロックインが嫌」で選ぶと、両方の専門家を雇う必要が生じてコストと運用難度が倍増します。
AI判断軸 ― AIがそのベンダーを知っているか
AI駆動開発が前提になると、ベンダー選定の軸は「AIがどれだけそのベンダーを知っているか」に重心が移ります。
AIの学習データ量がベンダー間で大きく異なる
AIにTerraformコードを書かせた場合、AWSリソースの生成精度はAzure・GCPより明らかに高いです。GitHub上の公開リポジトリにおけるAWS関連コードの絶対量が3〜5倍あるためです。「VPC+ALB+ECS Fargateの構成をTerraformで書いて」と指示するとAWSなら一発でほぼ動くコードが出ますが、同等の構成をAzureで書かせるとパラメータの組み合わせミスや非推奨APIの利用が混ざる頻度が高くなります。ニッチな国産・中堅ベンダーはさらに学習データが薄く、存在しないAPIを呼ぶハルシネーション事故が起きやすくなります。
ロックインの意味がAI時代に変わった
従来のロックイン議論は「移行先に技術的に移せるか」が焦点でした。AI時代では「AIが移行先のベンダーを正確に書けるか」が新しいリスク軸になります。AWSからGCPへの移行でAIにTerraformの書き換えを任せることは技術的に可能ですが、GCP固有のIAM設計（Workload Identity Federation等）のベストプラクティスは学習データが少なく、移行後の運用品質が落ちるリスクがあります。
やってはいけないこと
「いつでも他に移れる抽象化」を目指すと、ほぼ確実に失敗します。特に危険な5つに絞ります。
| 禁じ手 | なぜダメか → どうするか |
|---|---|
| 「将来の移行に備えて」抽象化レイヤを自作 | 抽象化コードの保守負荷の方が高くつき、結局移行もしない → ロックインを受け入れて深く使う |
| 既存基盤と不整合なベンダーを機能で選ぶ | Microsoft基盤の企業がAWSを選ぶと統合コストで吹き飛ぶ → 既存資産との親和性を先に見る |
| ビッグバン移行 | 問題発生時に戻る場所がない → 並行稼働3〜6ヶ月を最低ラインにする |
| データ移行量の見積もりを怠る | 数TB〜数PBの転送料（egress）だけで数百万〜数千万円 → 移行判断の前に試算する |
| コスト試算を軽視して本番移行 | 実運用で想定の数倍の請求になる → egress・NAT・EIPの隠れコストまで含めて見積もる |
移行判断は「移行コスト > 3年間のロックインコスト」を数値で出してから着手するのが鉄則です。
筆者メモ ― 「捨てられる」という恐怖
Google Cloud IoT Coreの廃止は、2022年8月に発表され2023年8月にサービス終了しました。本番環境で使っていた企業には大きな衝撃で、移行先の選定と書き換えが突発的に発生しました。GoogleはReader・Hangouts・Inboxと消費者向けサービスも次々畳んできた歴史があり、企業側には「Googleは気が向かなくなれば畳む」という疑念が消えない、という声がよく聞かれます。
対照的にAWSは「一度出したサービスは基本的に畳まない」という姿勢を強く打ち出しており、この差は長期運用の安心感で効いてきます。ベンダー選定は機能表だけでなく、「10年後に同じサービスが存在しているか」という運営姿勢まで見るべき、という教訓を残した事例です。
決めるべきこと — 自分のプロジェクトでの答えは？
以下の項目について、自分のプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
- メインのクラウドベンダー（AWS / Azure / GCP）
- リージョン選定（東京・大阪・海外）
- 既存システムとの連携要件
- コンプライアンス要件（金融・医療・官公庁）
- マルチクラウドの採用可否
- 国内データ主権の必要性
- 技術者確保の実現性
言語化した答えはADRとして残します。書き方の具体例は以下の記事で解説しています。
この記事に関連する記事
まとめ
本記事はクラウドベンダーの選び方を、3大ベンダーの強み・規模/業種別の推奨・ロックインの捉え方・AI時代の判断軸まで含めて解説しました。如何だったでしょうか。
機能差で選ぶ時代は終わり、既存資産との親和性とAIの情報量で決まる時代になりました。新規・無指定ならAWS、Microsoft基盤ならAzure、AI/データならGCP。1つに寄せて深く使い込むのが2026年の現実解です。
次回はクラウドベンダーを決めた後の重要な選定、「実行環境」（VM・コンテナ・サーバーレス・Wasm）について解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は AWS グローバルインフラストラクチャ も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（14/95）