クラウドインフラの選び方完全ガイド｜AWS・Azure・GCPの使い分けとインフラ設計の判断基準

「クラウドに移行したいけど、どのクラウドを選べばいいか分からない」「AWS、Azure、GCPという名前は知っているが、自社に何が合うのか見当がつかない」という声を、システム開発の発注を検討している企業の担当者からよく聞きます。

クラウドインフラの選定は、技術的な判断を伴うため「開発会社に丸投げすればいい」と考えてしまいがちです。しかし、インフラ要件を発注者側がある程度理解して指定しておかないと、後から「想定よりコストがかかっている」「プロバイダーを変えたくても変えられない」という状況に陥るリスクがあります。

かといって、インフラエンジニアと同じ知識を身につける必要はありません。発注者に求められるのは、「可用性・セキュリティ・コスト上限」という3つの軸で要件を定義できること、そしてその要件をRFP（提案依頼書）に書けることです。

本記事では、中小企業のIT担当者やプロジェクトオーナーが「クラウドインフラの選定について、社内で説明できる・発注できる」レベルになることを目標に、以下の内容を解説します。

• 発注者が決めるべき範囲と開発会社に委ねてよい範囲
• AWS・Azure・GCPの特徴と用途別の選び方
• コスト試算の考え方と想定外コストの防止策
• セキュリティ・可用性の要件定義方法
• RFPに書くべきインフラ選定チェックリスト

クラウドインフラ選定で「発注者がやること」「開発会社に任せること」の線引き

クラウドインフラの選定を検討するとき、最初に明確にしておきたいのが「発注者の役割」です。技術的な専門知識がないと、すべてを開発会社に判断してもらいたくなりますが、それには落とし穴があります。

発注者が決めるべき3つのインフラ要件

クラウドインフラの選定において、発注者が自ら定義すべき要件は次の3つです。

1. 可用性要件（どの程度止まってはいけないか）

システムがどの程度の稼働率で動き続ける必要があるかを決めます。「24時間365日止まってはいけない」のか「業務時間内に動けば十分」なのかによって、インフラ構成とコストが大きく変わります。

例えば、外部向けのECサービスや予約システムであれば99.9%以上の稼働率が求められますが、社内の業務ツールであれば99.5%でも運用できる場合があります。

2. セキュリティ・コンプライアンス要件（何を守らなければならないか）

個人情報保護法（APPI）への対応、業界固有の規制（医療・金融等）、社内情報セキュリティポリシーとの整合など、守るべき要件を事前に整理しておく必要があります。「クラウドは安全」という認識は誤りで、セキュリティ設定の多くは利用者側の責任で行います（詳しくは後述の「共有責任モデル」参照）。

3. コスト上限・課金方式の指定

月額いくらまでなら許容できるか、また変動費型（使った分だけ課金）と固定費型のどちらが自社の予算管理に合うかを事前に決めておきます。クラウドは「安くなる」と言われますが、設計や運用を誤ると従来のオンプレミスより高くなることもあります。

開発会社に委ねてよい範囲と確認すべき質問

以下の項目は、技術的な専門知識が必要なため、開発会社に判断を委ねて問題ありません。

• 具体的なインスタンスタイプ・スペックの選定
• ネットワーク設計（VPC・サブネット・セキュリティグループ）
• データベース構成（マネージドDBサービスの選定等）
• CI/CD・デプロイメントパイプラインの設計
• IaC（Infrastructure as Code）の実装

一方で、以下の質問は発注者として開発会社に確認すべき重要事項です。

• 「選定したクラウドプロバイダーの理由を教えてください」
• 「今後別のプロバイダーに移行する可能性を考慮した設計ですか？」
• 「コスト最適化の方針（リザーブドインスタンス活用等）はどのように考えていますか？」
• 「月額コストの上限超過時に通知する仕組みはありますか？」

AWS・Azure・GCP の特徴と「向いている用途」早見表

3大クラウドプロバイダーにはそれぞれ得意とする領域があります。技術的な機能の細かい差異よりも「どのケースに向いているか」という観点で整理します。

AWS（アマゾン ウェブ サービス）― 「とりあえずこれ」が成立する汎用性

AWSは世界最大のシェア（2025年時点で約29%）を持つクラウドプロバイダーです。240以上のサービスを提供しており、ほぼすべてのユースケースに対応できる汎用性の高さが最大の特徴です。

向いているケース:

• 特定の要件がなく、実績のある標準的な選択肢を選びたい
• 開発会社・エンジニアの知識・事例が豊富な環境を優先したい
• 日本でのサポート・サービス事例が充実していることを重視したい

注意点: サービス数が多いため、設定ミスのリスクも高くなります。適切な権限管理と監視体制が必要です。

Azure（マイクロソフト）― Microsoft 365 環境と相性抜群

Azureは、MicrosoftのクラウドサービスとしてMicrosoft 365（旧Office 365）やMicrosoft Entra ID（旧Azure AD）と緊密に統合されています。

向いているケース:

• すでにMicrosoft 365・Teamsを全社導入している
• Active DirectoryベースのID管理を継続したい
• Windowsサーバー環境をそのままクラウドに移行したい
• ERP（SAP・Dynamicsなど）との連携を検討している

注意点: Microsoft製品との親和性が高い反面、Google WorkspaceやSlackなどAzure以外のツールと組み合わせる場合は追加の設定が必要になることがあります。

GCP（Google Cloud）― AI・データ分析・コンテナに強い

GCPは、GoogleがYouTubeや検索エンジンの運用で培ったインフラ技術を基盤にしています。特にAI・機械学習、ビッグデータ分析、Kubernetesを中心としたコンテナ運用に強みを持ちます。

向いているケース:

• AI・機械学習機能を活用したいシステム開発
• 大量データの分析基盤（BigQuery等）が必要
• Kubernetes（コンテナオーケストレーション）を中心とした設計
• Google Workspace（Gmail・Googleドライブ等）を使用している

注意点: 日本国内でのシェアはAWS・Azureより小さく、日本語の公式ドキュメントや事例が相対的に少ない場合があります。

用途別おすすめクラウド早見表

用途・状況	おすすめ	理由
新規Webサービス・スマホアプリ	AWS	実績豊富、エンジニアの知識が多い
既存のMicrosoft環境との連携	Azure	Active Directory・Microsoft 365との統合が容易
AI・機械学習機能の活用	GCP	AI/MLサービスが充実（Vertex AI等）
大量データの分析基盤	GCP	BigQueryが業界標準に近い地位
EC・予約システム（大規模）	AWS	運用実績・可用性設計の事例が豊富
社内業務システムのクラウド移行	Azure or AWS	要件に応じて選定。Microsoftアカウント連携重視ならAzure
コンテナ中心のアーキテクチャ	GCP or AWS	GCPはKubernetes（GKE）が強力。AWSはEKS/ECSの事例も多い

SCROLL→

クラウドインフラのコスト試算方法と「想定外のコスト膨張」を防ぐ方法

「クラウドにすれば安くなる」という話を聞いて移行を検討しているとすれば、少し注意が必要です。クラウドは適切に設計・運用すればコスト効率が高まりますが、設計を誤ると従来のオンプレミスより高額になることもあります。

クラウドの3大コスト要素（コンピューティング・ストレージ・ネットワーク）

クラウドのコストは主に以下の3つの要素で構成されます。

1. コンピューティング（サーバー処理）コスト

アプリケーションを動かすサーバー（仮想マシン）の費用です。AWSではEC2、AzureではVirtual Machines、GCPではCompute Engineと呼ばれます。CPUコア数・メモリ量・利用時間によって料金が変わります。

2. ストレージコスト

データを保存する費用です。データベース・ファイル保存・バックアップなどが含まれます。保存量（GB/TB）に応じた課金が基本です。

3. ネットワーク（データ転送）コスト

クラウド外部へのデータ転送時に発生する費用です。「インターネットへの転送」「リージョン間転送」などが有料になります。動画ストリーミングや大量ファイルダウンロードが発生するサービスでは、このコストが想定外に膨らむケースがあります。

主要クラウド料金の目安（東京リージョン基準）

以下は参考として一般的な料金目安です。実際の料金は変動するため、AWSの料金計算ツールや各社の公式見積もりサービスで試算することを推奨します。

AWS 東京リージョン（オンデマンド料金・2025年参考）

インスタンスタイプ	vCPU	メモリ	時間料金（目安）	月額料金（目安）
t3.small	2	2GB	約$0.026	約3,000〜4,000円
t3.medium	2	4GB	約$0.053	約5,000〜7,000円
t3.large	2	8GB	約$0.106	約10,000〜13,000円

SCROLL→

※料金は為替レートや割引オプション（リザーブドインスタンス等）によって大きく変動します。また、上記はEC2（コンピューティング）の費用のみで、ストレージ・データベース・ネットワーク費用は別途加算されます。

コスト削減オプション:

• リザーブドインスタンス: 1年または3年契約で最大72%の割引
• Savings Plans: 柔軟な使用量コミットメントによる割引
• スポットインスタンス: 余剰リソースを安価に活用（中断リスクあり）

想定外コストが発生する3つのパターンと防止策

実際に起こりやすい「想定外コスト」のパターンを紹介します。

パターン1: データ転送費用の見落とし

クラウド内へのデータ転送（インバウンド）は無料ですが、外部への転送（アウトバウンド）は有料です。動画配信や大量のAPI呼び出しが発生するサービスでは、このデータ転送費用が大きくなる場合があります。

対策: 設計段階でデータ転送量を見積もり、CDN（コンテンツデリバリーネットワーク）の活用を検討する。

パターン2: 開発・テスト環境の放置

開発環境や検証環境を起動したまま忘れてしまうと、使っていないにもかかわらず課金が続きます。特に複数の開発者が関わるプロジェクトでは管理が難しくなります。

対策: 月次でのコスト確認体制を構築し、不要なリソースを定期的に削除するルールを設ける。コスト上限アラートを設定しておくことも有効です。

パターン3: 最適でないインスタンスタイプの選定

「余裕を持って大きいスペックを選んでおけば安心」という考えでオーバースペックのサーバーを選ぶと、リソースを無駄にした状態で課金が続きます。

対策: 初期は小さめのインスタンスから始めて実際の使用量を計測し、スケールアップ・スケールアウトで対応する方針を開発会社に確認しておく。

セキュリティ・可用性の要件定義方法

クラウドを使えばセキュリティが自動的に担保されると思っている方も多いですが、これは誤解です。クラウドプロバイダーと利用者の間には「共有責任モデル」という考え方があり、セキュリティの責任を分担します。

クラウドの共有責任モデル―プロバイダーが担う範囲 vs 利用者が担う範囲

共有責任モデルとは、クラウドのセキュリティ対策においてプロバイダーと利用者がそれぞれ担当する範囲を明確にするための考え方です。

クラウドプロバイダーが担う範囲（"of" the cloud）:

• 物理的なデータセンターのセキュリティ
• ハードウェア・ネットワーク機器の保護
• クラウド基盤ソフトウェアの脆弱性対応

利用者が担う範囲（"in" the cloud）:

• アクセス権限・IAMの設定
• データの暗号化設定
• アプリケーションレベルのセキュリティ設定
• セキュリティパッチの適用（IaaSの場合）

つまり、「クラウドに移行した」からといってセキュリティのすべてがクラウドプロバイダーに委ねられるわけではありません。アクセス権限の設定ミスや暗号化設定の漏れは利用者側の責任になります。

RFPには「共有責任モデルに基づくセキュリティ設定の責任分担を明確にすること」という要件を含めることを推奨します。

可用性要件の決め方（業種・重要度別の目安）

可用性（Availability）とは、システムが稼働している時間の割合を示します。一般的に「99.9%」「99.99%」という表現で示され、この差がダウンタイム（停止時間）に大きく影響します。

稼働率	年間ダウンタイム	適用例
99%	約87.6時間/年	内部ツール（非リアルタイム）
99.5%	約43.8時間/年	社内業務システム
99.9%	約8.7時間/年	一般的なWebサービス・ECサイト
99.95%	約4.4時間/年	決済・予約システム
99.99%	約0.9時間/年	金融・医療・インフラ系

SCROLL→

「高い稼働率」を求めるほど、冗長化設計が必要になりコストが上がります。発注者として「このシステムがどの程度の停止時間まで許容できるか」を事業部と相談した上で決定してください。

RFPに記載すべきセキュリティ要件のテンプレート

以下をRFPのセキュリティ要件セクションに記載することを推奨します。

マルチクラウド・ハイブリッドクラウドの選択基準

クラウド移行を検討していると「マルチクラウド」や「ハイブリッドクラウド」という言葉に出会うことがあります。これらの概念を整理した上で、中小企業にとって現実的な選択肢を考えます。

マルチクラウドが「必要になる時」と「不要な時」の判断基準

マルチクラウドとは、AWS・Azure・GCPなど複数のクラウドプロバイダーを同時に利用する構成です。

マルチクラウドが有効なケース:

• 特定のクラウドへのロックインリスクを回避したい大企業
• 各プロバイダーの得意分野を使い分けたい場合（例: AIはGCP、本番環境はAWS）
• 規制要件で特定の地域・プロバイダーを使い分ける必要がある場合

中小企業に向かないケース（初期段階）:

• 運用コスト・管理負荷が単一クラウドの2〜3倍になる
• インフラ担当者のスキルセットが不足しがち
• コスト最適化より運用の複雑さが先に問題になる

中小企業や新規サービス開発では、まずシングルクラウドで開始し、事業拡大に応じて段階的に検討するアプローチが現実的です。

ハイブリッドクラウドを検討すべきケース（既存オンプレとの併用）

ハイブリッドクラウドとは、既存のオンプレミス環境とクラウド環境を組み合わせて使う構成です。

検討すべきケース:

• 既存の基幹システムをすぐにクラウド移行できないが、新規機能はクラウドで開発したい
• 機密性の高いデータはオンプレ保管、一般的なデータはクラウド保管という方針
• リース期間満了まで既存サーバーを使いながら段階的に移行したい

注意点: ハイブリッドクラウドは、オンプレミスとクラウド間のネットワーク接続（専用線・VPN）の費用が別途発生します。また、運用の複雑さも増すため、移行計画の策定は慎重に行ってください。

インフラ選定チェックリスト―RFPに書くべき6項目

最後に、発注者がRFPにインフラ要件を記載するための実用的なチェックリストをご紹介します。このチェックリストを活用することで、開発会社への発注時に「インフラ要件の指定漏れ」を防ぐことができます。

チェックリスト: RFPに記載すべきインフラ選定要件

1. 対象ユーザー数・アクセス数の見込み

インフラ設計の基礎となるトラフィック情報を明記します。

記載例:

2. 可用性要件（稼働率・RTO/RPO）

求められる稼働率と障害発生時の復旧目標を明記します。

記載例:

※RTO（Recovery Time Objective）: 障害から復旧するまでの目標時間 ※RPO（Recovery Point Objective）: データをどの時点まで復旧できればよいかの目標

3. セキュリティ・コンプライアンス要件

守るべき法令・規制・社内ポリシーを明記します。

記載例:

4. クラウドプロバイダーの指定または選定委任

プロバイダーを発注者側で指定するか、開発会社に判断を委ねるかを明記します。

記載例:

5. コスト上限・課金方式の指定

予算上限と課金方式への要望を明記します。

記載例:

6. 運用・監視体制の要件

システム稼働後の運用・監視の体制について要件を明記します。

記載例:

これら6項目をRFPに含めることで、開発会社から受け取る見積書や提案書の内容を比較・評価しやすくなります。また、「なぜこのクラウドを選んだのか」という選定理由も提案書に記載を求めることで、開発会社の技術力と説明責任を確認できます。

まとめ: 発注者として「判断できる状態」になることが大切

クラウドインフラの選定において、発注者がすべての技術的判断を行う必要はありません。しかし、「可用性・セキュリティ・コスト」という3つの軸での要件定義は、発注者が担うべき重要な役割です。

この記事で解説した内容をまとめると以下のとおりです。

• AWS・Azure・GCPの選び方: 用途・既存環境・重視する機能によって選択する。迷ったらAWSが無難
• コスト管理: データ転送コスト・開発環境の放置・オーバースペックの3大コスト膨張パターンに注意
• セキュリティ: 共有責任モデルを理解し、利用者側の設定責任をRFPに明記する
• 可用性: 事業影響度からダウンタイム許容時間を決め、稼働率要件として指定する
• チェックリスト: RFPに6項目のインフラ選定要件を記載し、開発会社に判断根拠を求める

秋霜堂株式会社では、AWS・GCPを活用したシステム開発を複数手がけており、Terraform（IaC）による構成管理を標準採用しています。「インフラ要件の整理段階からサポートしてほしい」「RFPの作成を手伝ってほしい」という方は、お気軽にご相談ください。

※ 本記事の料金情報は2026年4月時点の参考値です。実際の料金は為替レートや各社の価格改定により変動します。最新情報は各クラウドプロバイダーの公式サイトでご確認ください。

秋霜堂株式会社について

秋霜堂は、Web開発・AI活用・業務システム開発を手がけるシステム開発会社です。要件定義から設計・開発・運用まで一貫してご支援しています。

システム開発のご相談や、自社課題に合った技術的アプローチについてお悩みの方は、お気軽にお問い合わせください。