クラウドサービス入門：AWS/GCP/Azure を「事業上の意思決定」として読み解く

クラウド選定は「どのサービスが技術的に優れているか」という問いではありません。コスト構造・ベンダー依存リスク・採用市場という3つの事業変数を同時に決定する経営判断です。「うちはAWSを使っています」という一文が、スタートアップの財務モデルや買収時のリスク評価に直接影響します。

M&A担当者やVCキャピタリストがクラウド選定を評価できる軸を持っているかどうかで、技術DDの精度が大きく変わります。本稿では3大クラウドの本質的な違いを整理し、投資・買収判断で問うべき視点を提供します。

なぜクラウド選定が事業判断なのか

エンジニアの目には「どのサービスを使うか」という技術選択に見えますが、経営・投資の観点では3つの事業変数に直結します。

1. コスト構造の固定化

クラウドの利用料はプロダクトの規模に連動して増加します。ユーザーが増えれば計算リソース・ストレージ・通信費用が増えます。この構造は、損益分岐点をクラウドコスト込みで考える必要を生みます。スタートアップのユニットエコノミクス評価において、クラウドコストは「売上原価（COGS）」に計上されるケースが多く、粗利率に直接影響します。

2. ベンダー固有サービスへの依存

クラウドは汎用的なサーバーリソース（EC2/GCE/VM）だけでなく、マネージドサービス（データベース・キュー・AIサービス・認証）を提供します。これらを利用するほど移行コストが高まります。「3ヶ月でAWSから別のクラウドに移れるか」という問いに「不可能ではないが数億円規模のリエンジニアリングが必要」となる構造が生まれます。

3. 採用市場の方向性

エンジニアのスキルセットはクラウドに紐づきます。「AWS経験者」「GCP認定資格保有者」という採用要件は、利用クラウドが決まることで初めて意味を持ちます。日本国内のエンジニア市場では、AWSの経験者母集団が最も大きく、GCP・Azureがそれに続きます。クラウドを変更することは、採用市場の前提を変えることでもあります。

3大クラウドの本質的な違い

	AWS	GCP	Azure
市場シェア（概算）	約33%	約11%	約22%
設計思想	サービスの幅と実績	エンジニアリングの洗練さ	Microsoft エコシステム統合
最大の強み	最多サービス数・実績・採用市場	AI/ML・データ基盤・Kubernetes	企業向けITとの親和性・コンプライアンス
採用市場（日本）	◎ 最大	○ 中規模	○ 中規模（エンプラ寄り）
コスト傾向	機能の多さで高コストになりやすい	計算コストは競争力がある	エンタープライズ契約で有利になりやすい
典型的な選択理由	「まずここから始める」デファクト	AI/ML機能を使いたい・GKEが優れている	Office365/Active Directory との統合

AWS：デファクトスタンダードであることの意味

AWSはAmazonが2006年に公開し、クラウドコンピューティングという概念を事実上定義したサービスです。現在200以上のサービスを持ち、これが最大の強みであり、複雑さの源泉でもあります。

「AWSを使っている」という事実が投資判断で持つ意味は2つあります。まず、採用市場で最も多くのエンジニアが経験を持つため、チーム拡張がしやすいという点です。次に、インターネット上のドキュメント・コミュニティが最も豊富なため、問題解決にかかる時間が短い傾向があります。

一方、リスクは「マネージドサービスの乱用」です。AWSはDynamoDB（独自データベース）・SQS（メッセージキュー）・Kinesis（ストリーミング）など、他クラウドに同等物があっても移行コストの高いサービスを多数持ちます。利用サービスが増えるほどAWS依存が深まり、将来の交渉力（価格交渉・SLAの見直し）が弱まります。

GCP：Googleの技術力とエコシステムの狭さ

GCPは「Googleが内部で使っている技術を外部に提供する」という方向性を持ちます。Kubernetes（コンテナ管理のデファクト標準）・BigQuery（大規模データ分析）・Google CloudのMLプラットフォームはいずれも業界をリードするサービスです。

特にAI/ML機能においては、GCPの優位性は明確です。Googleが開発したTensorFlowとの統合・TPU（AI専用チップ）へのアクセス・Google CloudのML基盤の成熟度は、AI機能をプロダクトの核心に置くスタートアップには強い選択肢になります。

弱点は採用市場の狭さとサービス廃止リスクです。Googleは過去にGoogle+・Google Wave・Google Stadia等、多くのプロダクトを廃止してきた経緯があります。GCP上のサービス（特にマネージドサービス）も同様のリスクが皆無ではありません。

Azure：エンタープライズITとの接続

Azureは企業ITの文脈で最も強みを持ちます。Microsoft Entra ID（旧 Azure Active Directory・社内認証の標準）との統合、Office 365・Teams・SharePointとのシームレスな接続、そして日本を含む多くの企業がすでにMicrosoftと契約関係にある事実が後押しします。

エンタープライズ向けBtoBサービスを構築するスタートアップが「顧客のIT部門に採用してもらうために」Azureを選ぶ判断は事業的に合理的です。コンプライアンス認証の豊富さ（HIPAA・SOC2・ISO27001等）も、規制業界向けプロダクトでは評価されます。

一方、スタートアップのエコシステム（OSSコミュニティ・YCカラムのスタートアップ等）ではAWSが主流であり、Azureを選ぶ技術コミュニティは相対的に狭いです。BtoCサービスやエンジニア文化の強いスタートアップではAWS・GCPが選ばれやすい傾向があります。

ロックインリスクの現実的な評価

「クラウドに依存するのはリスクだ」という主張はよく聞きますが、実態はより複雑です。ロックインには段階があります。

図1：クラウドロックインの4段階（依存度は高→低の順）

実際のロックインリスク評価で問うべきは「移行コスト」ではなく「移行する必要が生じる確率と影響」です。中小スタートアップにとって、価格が2倍になってもAWSから移行するより増加分を吸収する方が安上がりなケースは少なくありません。ロックインを「悪」と断定せず、依存コストを意識した上で選択しているかが問題の本質です。

データ転送コスト（Egress）の見落とし

多くのスタートアップが見落としているのが、クラウド間のデータ転送費用です。3大クラウドはいずれもデータの「入り口（Ingress）」は無料ですが、「出口（Egress）」には費用がかかります。大量のデータを扱うプロダクト（動画・画像・ログ分析）では、クラウドコスト全体の見積もりに対してEgress分として10〜15%程度を上乗せして概算するのが実務的な目安です。

投資先がデータ集約型のビジネスモデルを持つ場合、クラウドのEgressコスト構造を確認することが財務モデルの精度に直結します。

マルチクラウド戦略の実態

「特定のクラウドへの依存を避けるためにマルチクラウドを採用する」という考え方は聞こえは良いですが、現実はより複雑です。複雑さの源泉は主に4点あります。第1に、2つのクラウドを並行管理するにはそれぞれの専門知識を持つエンジニアが必要で採用・育成コストが増します。第2に、デプロイパイプライン・監視・IaC・コスト管理のツールチェーンがすべて二重化され、運用負荷が単純に倍になります。第3に、クラウド間のデータ転送は双方向にEgressコストが発生し、かえってコストが増大するケースがあります。第4に、1つのクラウドへの集中利用で得られるボリューム割引（コミットメント契約）の恩恵を受けにくくなります。

マルチクラウドが有効に機能するケースは限られます。まず、地域ごとに規制要件が異なり特定のクラウドをリージョンごとに使い分ける必要がある場合です。次に、特定の機能（例：AI/MLはGCP、エンタープライズ統合はAzure）を目的別に使い分ける場合です。最後に、大企業がM&Aで別のクラウド基盤を持つ会社を吸収した結果、意図せずマルチクラウドになる場合です。

スタートアップがリスク分散目的でマルチクラウドを採用することは、多くの場合この4つのコストを同時に引き受けることになります。 限られたリソースで戦うスタートアップには、1つのクラウドに集中した方が合理的なケースが大半です。

「マルチクラウドです」という言葉を聞いたとき、それが戦略的な判断か、意思決定の先送りや過去の遺物かを判断することが重要です。

投資・買収時のクラウド評価チェックリスト

コスト構造の評価

クラウドコストが売上・ARRに占める割合はいくらか？ — SaaSビジネスでは通常10〜25%が目安。それを超える場合はコスト構造の課題があります
収益増加に対するクラウドコストの増加率（スケール特性）はどうか？ — 理想は収益が2倍になってもクラウドコストは1.5倍に収まる設計。コストが線形以上に増加する場合は要確認です
コスト最適化の取り組みがあるか？ — リザーブドインスタンス・スポットインスタンス・Saving Plansの活用状況、不要リソースの定期整理

依存度の評価

主要なデータはエクスポート可能な形式で保存されているか？ — クラウド固有の圧縮フォーマットや暗号化スキームへの依存を確認します
マネージドサービスの利用範囲はどこまでか？ — 汎用的なOSSで代替できるものを使っているか、固有サービスへの依存が深いかを評価します
Egressコストの見積もりがあるか？ — データ量が増えたときの転送費用を把握しているかを確認します

運用体制の評価

クラウドの専門知識を持つエンジニアは何人いるか？ — 1人しか知らない状態はバスファクター（属人化リスク）として評価すべき点です
Infrastructure as Code（IaC）が整備されているか？ — Terraform・CloudFormation等でインフラがコードで管理されているかを確認します。属人化の防止と再現性の指標になります
マルチリージョン構成になっているか？ — 単一リージョン障害で全サービスが止まるリスクがないかを評価します

まとめ：クラウド選択を「戦略の可読性」として読む

クラウド選択の評価で最終的に問うべきは「なぜそのクラウドを選んだか」の説明責任です。事業の特性（AI中心ならGCP、エンタープライズ顧客との親和性ならAzure、エコシステムの広さを取るならAWS）と整合した理由があれば、どのクラウドでも問題ありません。

問題なのは「なんとなく使っている」「創業CTOが知っていたから」という説明しかできない場合です。クラウド選択の合理性が語れないということは、技術戦略全体の可読性が低い状態を示している可能性があります。

投資・買収後の統合（PMI）においても、クラウド構成の把握は初期アセスメントの重要な一部です。クラウドを正確に読めることは、財務・リスク・採用の総合評価能力に直結します。

クラウドと並んでプロダクトの技術基盤を決定するのが言語選択です。プログラミング言語の選び方：投資家・経営者のための言語マップでは、Python・TypeScript・Go・Rust等を事業判断の軸で整理しています。

クラウドの評価を含む技術DDの全体的なフレームワークは技術デューデリジェンスの全体像と7つの評価軸で解説しています。買収後の技術リスクについては投資後に発覚しがちな技術リスク10選も合わせてご覧ください。

Tied株式会社では、VC・事業会社のM&A担当者向けに技術デューデリジェンス支援を提供しています。クラウド戦略の評価を含む技術DDの詳細は投資家向けサービスページをご覧いただくか、お問い合わせからご相談ください。