本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「システムアーキテクチャ」カテゴリ第3弾として、クラウドベンダーの選び方を解説する記事です。
「とりあえずAWSで」の一言が10年先の人材採用・月額コスト・障害対応・法規制対応まで決めます。AWS／Azure／Google Cloud は退出コストが最も高い部類の選定で、後からの移行はシステム全体の作り直しと同義です。本記事では3大ベンダーの強み弱み・世界シェア・主要サービス比較・規模/業種別推奨を解説します。
このカテゴリの他の記事
どこにインフラを預けるか
クラウドベンダーは、インターネット越しにサーバー・ストレージ・DB・アプリ基盤を貸してくれる事業者です。代表格はAWS・Azure・Google Cloudの3社で、3社で世界クラウド市場の約7割を占めています。どのベンダーを選ぶかが、その後の技術スタック・人材戦略・コスト構造を10年単位で決めることになります。
ベンダー選定は一度決めたら変えにくい、という特徴があります。運用を始めると数百のサービスが絡み合い、他ベンダーへの移行はほぼ不可能になります。これがベンダーロックインと呼ばれる現象です。
「いつでも移行できるようにしておく」という抽象化は、ほぼ例外なく過剰設計で終わります。ロックインは避けるものではなく、受け入れて深く使い込むものと考えるのが、2026年時点の現実的な姿勢です。
ベンダー選定は一度決めたら変えにくい。ロックイン前提で慎重に判断するのが定石です。
Amazon Web Services（AWS）
AWS（Amazon Web Services）は、Amazonが2006年3月に開始した、クラウドコンピューティングの先駆けです。世界シェア第1位を2026年に入っても守り続けており、元々はAmazonが内部のEC運用で作った仕組みを外に公開したもの。技術的な信頼性と規模感が圧倒的です。
| 強み | 弱み |
|---|---|
| サービス数が250種類超で最大 | サービスが多すぎて専門知識が必要 |
| コミュニティ・情報・ツールが豊富 | 料金体系が複雑でコスト管理が難しい |
| リージョン数が最多で障害に強い | サポート費用が高い |
| 技術者を比較的集めやすい | UIが独特で慣れが必要 |
情報量・採用実績・技術者の集めやすさ、どれを取っても競合を上回ります。選んで後悔する確率が最も低い選択肢で、「指名なきプロジェクトはまずAWSから疑う」のが定石です。反面、サービス数の多さが学習コストの壁になるという副作用もあります。
AWSの強みは「デファクトスタンダードであること」そのものです。書籍・ブログ・StackOverflowの記事数、GitHub上のTerraformモジュールの数、新卒〜中途のAWS経験者の数。どれも2位のAzureに2〜3倍の差をつけています。AI時代になってこの情報量の差がさらに効き、AIが吐くAWSコードの精度が他ベンダーより一段高い、という状況が生まれています。
新規案件の第一候補はAWS。逸脱するなら理由を書き出せるときだけ、というスタンスが合理的です。
Microsoft Azure
Microsoft Azure は、Microsoftが2010年2月に開始した、エンタープライズに強いクラウドです。世界シェア第2位で、AWSに迫る勢いが止まりません。
| 強み | 弱み |
|---|---|
| Microsoft製品との連携が簡単 | AWS/GCPと比べて操作性が悪い部分あり |
| サービス数200超・Azure Arc等ハイブリッド対応 | Windows以外への対応が後手気味 |
| エンタープライズ契約・認証系が充実 | 新機能の展開がAWSより遅い傾向 |
| 金融・官公庁向けコンプライアンス対応が強力 | 個人向けの使いやすさはイマイチ |
Office 365 / Microsoft 365 を使っている企業にとって、Azureは管理を一元化できる本命です。Active Directory（Microsoftの統合認証基盤）を軸にした SSO（Single Sign-On、1度のログインで複数サービスを利用できる仕組み）や権限管理がシームレスに動き、多くの大企業がAzureを選ぶ直接の理由になっています。金融・医療・官公庁のように厳格なコンプライアンス要件がある業種でも強い選択肢です。
Azureの2023年以降の急成長の背景には、OpenAI との独占提携があります。ChatGPT / GPT-4 / GPT-5 系のモデルをAzure OpenAI Service 経由で企業向けに提供していることで、「生成AIを業務に組み込むならAzure」という新しい市場を獲得しました。これは AWS Bedrock・GCP Vertex AI でも対応が進んでいますが、OpenAI系モデルの独占権は2026年時点でもAzureの強みとして残っています。
Microsoft製品中心の企業・コンプライアンス重視業界ではAzureが本命です。
Google Cloud（GCP）
Google Cloud（GCP）は、Googleが2008年4月に開始した、3大クラウドの3番手です。YouTube・Gmail・検索エンジン等、Google自身のインフラを外部公開したのが始まりです。コンテナ・Kubernetes・AI/ML の領域で圧倒的な技術的リードを持ちます。
| 強み | 弱み |
|---|---|
| Googleサービス（YouTube/Maps等）との連携 | サービス数は150前後で最少 |
| Kubernetes・コンテナ技術に強い | サービス廃止・変更が比較的多い |
| BigQuery・Gemini等のAI系が充実 | 大規模導入事例が少ない |
| 継続割引でコストが安くなりやすい | 技術者の採用難度が高め |
Kubernetes は元々Googleが開発したコンテナオーケストレーション技術で、本家本元のGKE（Google Kubernetes Engine）は業界最高峰の完成度です。BigQuery や Gemini のようなAI・データ分析系は、他ベンダーが追従できない水準にあります。
一方で「サービスを平気で畳む」という歴史的悪評があり、長期運用の安心感では一歩譲ります。Google Cloud IoT Core の廃止（2022年発表、2023年サービス終了）や Google Reader、Hangouts、Inbox、Wave といった消費者向けサービスの相次ぐ終了は、企業側に「Googleは気が向かなくなれば畳む」という疑念を残しました。機能比較では互角でも、この「性格」の違いは長期運用で効いてきます。
データ分析・AI・Kubernetes中心のプロジェクトでは最有力。ただし長期運用の不安は別枠で評価する必要があります。
世界シェア比較
2025年第3四半期の世界クラウド市場シェアは次の通りです。3社合計で全体の約7割を占め、「3強時代」が続いています。
pie showData
title 世界クラウド市場シェア (2025 Q3)
"AWS" : 29
"Azure" : 25
"Google Cloud" : 13
"その他 (Alibaba/Oracle/IBM等)" : 33| ベンダー | シェア | 傾向 |
|---|---|---|
| AWS | 約29% | 横ばい・首位堅持 |
| Azure | 約25% | 継続的に成長・AWSに迫る |
| Google Cloud | 約13% | 成長中・AI分野で存在感 |
Azureの追い上げが目立つ背景は、Microsoft 365 経由の既存顧客のクラウド移行です。加えて OpenAI（ChatGPT）との提携で、生成AI活用を重視する企業のAzure採用が伸びています。GCPはAI領域での存在感を武器にシェアを伸ばしていますが、2位との差は依然として大きい状況です。
主要サービス比較
3大クラウドの主要サービスは、名称が違っても機能はほぼ同等です。「各ベンダーが競合機能を揃えに行く」力学が働くため、基本的なシステム構築に必要な機能はどこも揃っています。
コンピュート・ストレージ
| カテゴリ | AWS | Azure | GCP |
|---|---|---|---|
| 仮想マシン | EC2 | Virtual Machines | Compute Engine |
| コンテナ管理 | ECS / EKS | AKS | GKE |
| サーバーレス | Lambda | Azure Functions | Cloud Functions |
| オブジェクトストレージ | S3 | Blob Storage | Cloud Storage |
「AWSのほうが機能が多い」という印象は、ニッチ領域での話です。基本機能は3社ともカバー済みで、差が出るのは「機械学習ならGCP、ID管理ならAzure、総合力ならAWS」という住み分けです。
データベース・CDN・AI
| カテゴリ | AWS | Azure | GCP |
|---|---|---|---|
| マネージドDB | RDS | Azure SQL | Cloud SQL |
| NoSQL | DynamoDB | Cosmos DB | Firestore / Bigtable |
| CDN | CloudFront | Azure CDN | Cloud CDN |
| AI / ML | SageMaker / Bedrock | Azure AI / OpenAI Service | Vertex AI / Gemini |
NoSQLでは、AWSのDynamoDBが安定運用・大規模実績で頭ひとつ抜けています。AzureのCosmos DBはマルチモデル対応（ドキュメント・グラフ・キーバリュー等）、GCPのFirestoreはモバイルアプリ連携が強みです。
基本機能はどこも揃います。差は個別サービスの完成度と相性です。
選定基準
クラウドベンダー選定に「絶対の正解」はありません。どのベンダーでも必要な機能は十分以上に揃っているからです。だから自社の技術資産や制約条件との相性で決める。これに尽きます。
| 状況 | 推奨ベンダー |
|---|---|
| 特にこだわりや制限がない | AWS（最も無難） |
| Microsoft系製品を多数使っている | Azure |
| コンプライアンス厳格（金融・官公庁） | Azure（認証系が充実） |
| Google系サービス連携が必要 | GCP |
| データ分析・AIを重視 | GCP（BigQuery・Gemini） |
| Kubernetes中心に組みたい | GCP（GKE） |
新規スタートアップ・個人開発なら、情報量・無料枠・技術者確保のしやすさからAWSが最も無難です。一方、AI活用を前面に出すならGCP、既存Microsoft基盤と統合ならAzure、と明確な理由があれば他を選ぶ価値があります。
組織規模×業種別の推奨
「なんとなくAWS」で始めると、Microsoft基盤中心の企業や GCP の BigQuery が刺さる領域で後悔します。規模と業種の交差で見るのが筋の良い判定方法です。
| 状況 | 組織規模 | 推奨ベンダー | 理由 |
|---|---|---|---|
| 新規 Web SaaS（BtoB/BtoC） | 〜100人 | AWS | 情報量・マネージド充実・採用容易 |
| Microsoft 365 中核の大企業 | 1,000人〜 | Azure | Entra ID・AD連携・Office・Teams統合 |
| データ分析・AI中核 | 規模不問 | GCP | BigQuery・Gemini・Vertex AI |
| 金融・保険（基幹系） | 大企業 | AWS or Azure（FISC認定取得済み） | コンプライアンス認定 |
| 官公庁・自治体 | ― | ガバメントクラウド認定ベンダー | 政府調達の前提 |
| Kubernetes 中核 | 〜中規模 | GCP（GKE） | Kubernetes 本家の完成度 |
| 既に数年 AWS で運用中 | ― | AWS 継続 | 移行コストが高すぎて合理化しない |
判定は現状vs将来5年の両面で行います。既存が強くMicrosoft 365 依存の企業で新規Azureを避けるのは筋が悪く、AWSの情報量優位で選ぶ価値がある場面でも既存基盤との統合コストで逆転します。
機能差で選ぶ時代は終わりました。「既存資産との親和性」が最も強い軸です。
日本国内のクラウド
3大ベンダー以外にも、国産クラウドや特化型クラウドが存在します。データ主権（日本国内のデータは国内で保管）や円建て課金の需要から、一定の市場を形成しています。
| ベンダー | 特徴 |
|---|---|
| さくらインターネット | 国産・金額が明瞭・政府統計利用 |
| IDCFrontier | 国産・ソフトバンク系 |
| Oracle Cloud | 無料枠が太い・Oracle DB互換性 |
| Alibaba Cloud | 中国市場対応に強い |
官公庁・自治体では「ガバメントクラウド」認定を受けたAWS・Azure・GCP・Oracle・さくらが採用可能で、クラウド選定に政策的な側面が乗るようになりました。
特殊要件がない限り3大クラウドで十分です。国産は「日本国内データ保管」要件で選ぶものになります。
マルチクラウドは有効か
「ベンダーロックイン回避」のためにマルチクラウドを考えるケースはありますが、実務では運用複雑化のデメリットが大きく、安易には勧められないです。有効な場面は以下のような明確な理由がある時だけです。
- 規制要件で特定データを特定ベンダーに置けない
- M&A後でシステムが別ベンダーに散在
- 特定AI機能（GCPのGemini等）を一部だけ使いたい
- BCP要件でベンダー障害時の可用性を担保したい
「なんとなくロックイン嫌だから」でマルチクラウドを選ぶと、両方の専門家を雇う必要があり、コストと運用難度が跳ね上がります。メインベンダーに寄せるほうが圧倒的に効率的です。
マルチクラウドは明確な必要性がある時だけ。デフォルトではしません。
ベンダー移行・ロックイン脱出の鬼門
「いつでも他に移れる抽象化」を目指すと、ほぼ確実に失敗します。移行はベンダー固有の独自機能に絡んだ瞬間、想定の3倍のコストになります。
| 禁じ手 | なぜダメか |
|---|---|
| 「将来の移行に備えて」抽象化レイヤを自作 | 抽象化コードの保守負荷の方が高くつき、結局移行もしない。典型的な過剰設計 |
| ベンダー固有マネージドサービス（DynamoDB / BigQuery / Cosmos DB）を中核に置いた状態で移行計画を立てる | データモデルごと書き換えになる。コードの書き直しどころか設計のやり直しが発生 |
| 移行を一気に切り替える（ビッグバン移行） | 問題発生時に戻る場所がない。並行稼働3〜6ヶ月が最低ライン |
| データ移行量の見積もりを怠る | 数TB〜数PBのデータ転送料（egress）だけで数百万〜数千万円 |
| IAM・権限設計を後回しで移行開始 | ベンダーごとに権限モデルが違い、移行中に権限ズレで事故多発 |
移行判断は「移行コスト > 3年間のロックインコスト」を数値で出してから着手するのが鉄則です。AI時代は「AIが別ベンダー用コードを書ける」ため、人力移行より楽になる部分はありますが、データ移送とマネージド機能の置き換えは依然として重い作業です。
ロックインは避けるより受け入れる。抽象化で逃げられる部分は実は少ないです。
AI時代の視点
AI駆動開発が前提になると、ベンダー選定の軸は「AIがどれだけそのベンダーを知っているか」に重心が移ります。
AWSは情報量・公式ドキュメント・サンプルコードが圧倒的で、AIが吐く Terraform や CDK の精度が最も高い。Azure・GCPも情報量は十分ですが、ニッチな国産・中堅ベンダーはAIの学習データが薄く、生成コードが動かない・存在しないAPIを呼ぶ（ハルシネーション、AIが事実でないものをもっともらしく生成する現象）事故が起きやすいです。
| AI時代に有利 | AI時代に不利 |
|---|---|
| AWS（情報量・サンプル最多） | 国産・マイナークラウド（学習データ不足） |
| Terraform/CDK対応が厚い | 独自管理コンソールのみ |
| APIが成熟・ドキュメントが豊富 | 非公開仕様・口頭伝承ノウハウ |
| マルチリージョン展開がコード化可 | 手動構築前提の古い設計 |
ロックインの課題はAIでも解消されません。他ベンダーへの移行は依然として大工事で、「最初の選定の重さは変わらない」ここは過信しないことが大事です。
AI時代は「AIが熟知しているベンダー」が勝ちます。AWSの優位はさらに広がる方向です。
「捨てられる」という恐怖（業界事例）
Google Cloud IoT Core の廃止は、2022年8月に発表され2023年8月にサービス終了しました。本番環境で使っていた企業には大きな衝撃で、移行先の選定と書き換えが突発的に発生しました。Googleは Reader・Hangouts・Inbox・Wave と消費者向けサービスも次々畳んできた歴史があり、企業側には「Googleは気が向かなくなれば畳む」という疑念が消えない、という声がよく聞かれます。
AWSは「一度出したサービスは基本的に畳まない」という姿勢を強く打ち出しており、この差は長期運用の安心感で効いてきます。機能比較ではほぼ互角でも、「10年後に同じサービスが存在しているか」という視点を入れると景色が変わる、と示唆する事例です。GCPのサービス選定で「これ5年後に残っているか」を無視できなくなったのは、この IoT Core 廃止の衝撃がきっかけでした。
ベンダー選定は機能表だけでなく、そのベンダーの「性格」まで見るべき、という教訓が残っています。機能は似通っていても、企業文化と運営姿勢の違いは厳然と存在します。
クラウド選定は「機能」ではなく「性格」を選ぶ判断。畳む会社か、畳まない会社か、です。
決めるべきこと — あなたのプロジェクトでの答えは？
以下の項目について、あなたのプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
- メインのクラウドベンダー（AWS / Azure / GCP）
- リージョン選定（東京・大阪・海外）
- 既存システムとの連携要件
- コンプライアンス要件（金融・医療・官公庁）
- マルチクラウドの採用可否
- 国内データ主権の必要性
- 技術者確保の実現性
よくある失敗
- 「機能最多だからAWS」でMicrosoft基盤企業と不整合 ― 既存環境を見ずに選ぶと、統合コストで吹き飛ぶ。Azureが正解だったケース
- 最初から複雑なマルチクラウド ― 運用チームが疲弊し、管理不能に。典型的なやってはいけない選択
- コスト試算を軽視 ― 実運用で想定の数倍の請求が来て予算オーバー
- ベンダー変更を想定した抽象化 ― 過剰設計で開発速度が落ち、結局ベンダー移行もしない無駄
- リージョンを米国・欧州にして法令違反 ― 個人情報を国内保管義務のある業種で問題化
最終的な判断の仕方
ベンダー選定は、技術的な正解よりも「既存資産と将来ロックインのバランス」で決まります。3社とも基本機能は揃っており、機能差で選ぶ段階はとっくに過ぎました。
いま効くのは、既存基盤との親和性（Microsoft 365 ならAzure、Google Workspace ならGCP）と、社内で技術者を採用・育成できる層の厚み。この2点です。
ロックインは避けるより、前提として受け入れるほうが健全です。「いつでも移行できる抽象化」は過剰設計になりやすく、現実には移行もしません。1つに寄せたほうが運用もAIとの相性も良くなります。
AI駆動開発の観点でも、情報量が世界最大のAWSが生成精度で一歩リードしており、特別な理由がない限りAWSから疑うのが鉄板です。
選定の優先順位をまとめると次の通りです。
- 既存資産との親和性（Microsoft基盤／Google基盤／なし）を確認
- 技術者の採用・育成が現実的なベンダーに絞る（AWSが最も有利）
- AIが熟知しているかを最後の差別化軸に
- マルチクラウドは明確な理由がある時だけ
「1つに寄せる勇気」が、運用コストとAI生産性を両立させます。抽象化は最小限にとどめます。
まとめ
本記事はクラウドベンダーの選び方を、3大ベンダーの強み・規模/業種別の推奨・ロックインの捉え方・AI時代の判断軸まで含めて解説しました。如何だったでしょうか。
機能差で選ぶ時代は終わり、既存資産との親和性とAIの情報量で決まる時代になりました。新規・無指定ならAWS、Microsoft基盤ならAzure、AI/データならGCP。1つに寄せて深く使い込むのが2026年の現実解です。
次回はクラウドベンダーを決めた後の重要な選定、「実行環境」（VM・コンテナ・サーバーレス・Wasm）について解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（8/89）