私は業務でAWS・Azure・Google Cloudの三つを使っています。スペック表の比較は世の中にあふれているので、この記事では「実際に使うとどう感じるか」という肌感を中心に、クラウドコンピューティングの現在地を一枚にまとめます。オンプレの時代から何が変わったのか、国内のリージョンと官公庁での利用、三社でまるで違うアカウントの考え方、主要サービスの対応表、そして条件別の選び方までを整理してみます。
オンプレの時代 — 買って、置いて、守る
かつて、サーバーは「置くもの」でした。ホスティングのためにデータセンターへサーバーマシンを運び込んだり、オフィスの一角にサーバーを立てたり。マシンが届いたらキッティングです。OSを入れ、ミドルウェアを選定して構成を組み、監視を仕込んで、ようやくアプリケーションの土台ができる。買って、置いて、組んで、守る。それがシステムの始め方でした。
運用も物理の世界です。定期的な再起動、ディスクやファンの様子見、空調の心配。大きな障害でなくても、ちょこちょこと気にすることが多かった。固定IPアドレスひとつ取るにも、回線事業者と契約を交わし、申し込みから利用開始まで日数がかかりました。つまり、何かを用意することは、すべて「調達」であり「契約」だったのです。
クラウドで変わったこと — 「契約」が「操作」になった
クラウドがもたらした変化を一言でいうと、これだと思っています。調達が「契約」から「操作」に変わった。サーバーもIPアドレスもストレージも、かつては書類と日数が必要だったものが、いまは画面のボタンです。固定IPは数クリックで確保できます。私にとって一番のありがたみは、インフラ構築からの解放でした。サーバーのキッティングも、OSレベルの監視の仕込みも、ミドルウェアの構成を考える作業も、マネージドサービスを選べば「そもそもやらなくていいこと」になります。
もうひとつの変化は「任せる範囲」を選べるようになったことです。ハードウェアだけ任せるIaaS、実行環境まで任せるPaaS、アプリケーションごと任せるSaaS。オンプレを左端に置くと、右へ行くほど任せる範囲が広がる一本のスライダーになっています。どこまで任せ、どこから自分で受け持つのか。この線引きは「責任共有モデル」と呼ばれ、クラウドを使ううえでの共通の前提になっています。
ただし、心配ごとがなくなったわけではありません。種類が変わりました。オンプレの心配は「アクセスが集中したらサーバーが落ちる」。クラウドの心配は「トータルコストが不明瞭」。簡単だからという安心の裏には従量課金やサービス単位での課金が発生します。
国内で使える主要なクラウドと「リージョン」
業務利用で名前が挙がる主要どころは、AmazonのAWS、MicrosoftのAzure、GoogleのGoogle Cloud(旧称GCP)の三つです。そして国産勢として、さくらインターネットの「さくらのクラウド」があります。
クラウドを選ぶとき、意外と大事なのがリージョンです。リージョンとは、そのクラウドのデータセンター群がどこにあるか、つまり「データを置く場所」のこと。主要三社はいずれも国内に2つのリージョンを持っています(2026年8月現在)。AWSとGoogle Cloudは東京と大阪、Azureは東日本と西日本という名前です。データを国内に置けること、そして東西2拠点で災害対策の構成が組めること。この2点は、日本で業務システムを載せるときの安心材料になっています。
官公庁も使う時代 — ガバメントクラウド
「クラウドに大事なデータを置いて大丈夫なのか」という質問は、いまでもよく聞きます。ひとつの答えになるのが、政府の動きです。国や自治体の情報システムの共通基盤として、デジタル庁が「ガバメントクラウド」を整備しており、審査を通ったクラウドサービスだけが採択されます。
2026年8月22日現在で採択されているのは、AWSとGoogle Cloud(2021年度)、AzureとOracle Cloud(2022年度)、そして国産の「さくらのクラウド」の5サービスです。さくらは2023年に条件付きで採択されたあと、2026年3月に305項目の技術要件すべての適合が確認され、国産クラウドとして初めて正式認定されました。行政のシステムがクラウドに載る時代です。「クラウドだから不安」という段階は、もう過ぎたと言っていいと思います。
アカウントの考え方が、そもそも違う
ここからが実務の肌感です。三つのクラウドを触りはじめて最初に面食らうのは、個々のサービスの違いではなく、アカウントとリソース管理の考え方の違いだと思います。
| AWS | Azure | Google Cloud | |
|---|---|---|---|
| リソースのスコープ | アカウント | テナント → サブスクリプション → リソースグループの三層 | プロジェクト |
| 案件や環境の分け方 | アカウントごと分ける(Organizationsで束ねる) | サブスクリプションやリソースグループで分ける | プロジェクトを分ける |
| 課金単位 | アカウント | サブスクリプション | プロジェクト |
AWSは「アカウント」がリソースのスコープそのもので、案件や環境を分けたければアカウントごと分けるのが定石です。Google Cloudは、ログインは個人のGoogleアカウントで行い、リソースは「プロジェクト」という単位に入れます。Azureは組織を表す「テナント」の下に契約単位の「サブスクリプション」があり、さらに「リソースグループ」で束ねる三層構造。Microsoft 365と地続きの、組織文化の設計です。
同じ「仮想マシンを1台立てる」でも、その1台がどのスコープに属するかの考え方が三社三様。ひとつ目のクラウドに慣れてから二つ目を触ると、たいていここで迷子になります。逆に言えば、この違いさえ頭に入れば、二つ目からはずいぶん楽になります。
主要サービスの対応表 — 同じ用途で、名前が違う
もうひとつ、二つ目のクラウドで戸惑うのが「あの機能、こっちでは何て名前?」です。よく使う用途について、三社の対応を並べておきます。
| 用途 | AWS | Azure | Google Cloud |
|---|---|---|---|
| 仮想マシン(IaaS) | EC2 | Virtual Machines | Compute Engine |
| アプリ実行(PaaS) | Elastic Beanstalk | App Service | App Engine / Cloud Run |
| サーバーレス関数 | Lambda | Azure Functions | Cloud Run functions(旧 Cloud Functions) |
| 非同期メッセージング | SQS / SNS | Service Bus | Pub/Sub / Cloud Tasks |
| オブジェクトストレージ | S3 | Blob Storage | Cloud Storage |
| リレーショナルDB | RDS | Azure SQL Database | Cloud SQL |
| NoSQL DB | DynamoDB | Cosmos DB | Firestore |
なお、SaaSは特定のクラウドの1サービスというより、Microsoft 365 や Google Workspace のように完成品として使う層の話なので、この表からは外しています。名前は違っても役割はほぼ対応しているので、ひとつのクラウドで覚えた概念は、この表を頼りにほかへ持ち運べます。
生成AIのサービスも、三社三様
いまのクラウド選びで無視できないのが、生成AIまわりです。ここも三社で構図がはっきり分かれています。モデルの名前は数ヶ月単位で入れ替わるので、個別のバージョンではなく「どういう立ち位置か」で覚えるのがおすすめです。なお、この節のサービス名と構成は2026年8月22日現在のものです。
| AWS | Azure | Google Cloud | |
|---|---|---|---|
| AI開発プラットフォーム | Amazon Bedrock(機械学習基盤はSageMaker) | Microsoft Foundry(旧 Azure AI Foundry) | Vertex AI |
| モデルの品ぞろえ | Claude・Llama・Mistral・自社のNovaなど多数を選べる「モデル非依存」型 | OpenAIのGPT系が本命。一番近い場所で使える | 自社のGemini系が主役。Model Garden経由でClaudeなども |
| エージェント開発 | Bedrock AgentCore | Foundry Agent Service | Vertex AI Agent Builder(ADK + Agent Engine) |
| エージェントの実行権限 | IAMロール | マネージドID | サービスアカウント |
構図を一言でいうと、AzureはOpenAIとの距離の近さ、AWSはモデルを選べる品ぞろえ、Googleは自社モデルGeminiと基盤の一体感が持ち味です。エージェントを組むための開発基盤も、2025年のうちに三社とも正式提供が出揃いました。
実務で効いてくるのが、表の最後の行です。エージェントにクラウドの操作をさせるとき、「誰の権限で動くのか」を決める仕組みが三社で違います。Google Cloudではサービスアカウントという専用のIDにIAM権限を持たせて動かすのが基本で、AWSならIAMロール、AzureならマネージドIDが同じ役割を担います。人間のアカウントを貸すのではなく、エージェント専用のIDに必要最小限の権限だけを渡す。AIに仕事を任せる時代の安全運用は、この設計から始まります。
どれを選ぶか — 条件別の向き不向き
「結局どれがいいのか」とよく聞かれますが、正直に言えばどれも一長一短で、絶対の正解はありません。実務での決め手は性能表ではなく、いま手元にあるものとの地続きさであることが多いです。条件別に整理するとこうなります。
| こういう条件なら | 向いているのは | 理由 |
|---|---|---|
| 会社がMicrosoft 365 / Entra IDを使っている | Azure | 社内のIDと権限管理を地続きで持ち込める |
| データ分析が主目的・Googleサービスとの連携が軸 | Google Cloud | BigQueryを筆頭に分析系がそろっている |
| サービスの品ぞろえと情報量で困りたくない | AWS | 利用実績が厚く、日本語の情報・教材・事例が最多クラス |
| 行政系の要件・国内事業者を重視したい | さくら等の国産 | ガバメントクラウド正式認定という後ろ盾 |
| 特定の条件がまだない・まず学びたい | AWS | つまずいたときに答えを見つけやすい |
そして先ほどの対応表のとおり、概念の大半は持ち運べます。最初のひとつをどれにしても、その経験が無駄になることはありません。
三つとも、AIとCLIで同じように操作できる
そして最近は、クラウドの操作もAIを使うのが当たり前になってきました。三社にはそれぞれ公式のコマンドラインツール(CLI)があります。AWSは aws、Azureは az、Google Cloudは gcloud。かつては人がリファレンスを引きながら操作するものでしたが、いまはClaude CodeのようなコーディングエージェントにCLIをまかせて、人が対話で操作できるようになりました。
「今月の利用料金をサービス別にまとめて」「使っていないリソースを洗い出して」と頼めば、エージェントがCLIを叩いて結果を整理してくれます。三社で設定コンソール画面はバラバラでも、操作の入り口はCLIに揃っている。だからこそ、AIという同じ道具で三つのクラウドを横断できるわけです。もちろん、実行する前に「何をするつもりか」を説明させて、判断は人間がする。一つ間違えると環境ごと壊してしまうリスクはあります。この使い方は、今後掘り下げていきたいテーマです。
まとめ
オンプレからクラウドへの変化は「契約から操作へ」。国内には東京・大阪にリージョンを持つ主要三社と、正式認定された国産クラウドがあり、行政のシステムもその上で動いています。三社は似ているようで、アカウントの考え方が違い、同じ用途のサービスが別の名前で並んでいます。多くの場合、慣れ親しんだクラウドを選ぶのが最適です。
サーバーを担いでデータセンターへ運んだ時代から、ボタンひとつで世界中に配置できる時代へ。そして次は、そのボタン操作自体をAIに頼む時代が始まっています。
出典・参考: さくらインターネット ニュースリリース(2026-03-27・ガバメントクラウド正式採択)/NEC「ガバメントクラウドとはなにか」/ITmedia NEWS(2026-03-27)/AWS: Amazon Bedrock AgentCore一般提供開始(2025-10)/Microsoft Learn: Foundry Agent Service/Google Cloud: Agent Development Kit(Vertex AI Agent Builder)/Google Cloud公式ブログ: Cloud FunctionsはCloud Run functionsへ(2024-08)
