AWS・Azure・Google Cloud、業務で使うとこう違う

3つのクラウドコンピューティング — AWS・Azure・Google Cloud クラウド

私は業務で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 ServiceGoogle Cloud: Agent Development Kit(Vertex AI Agent Builder)Google Cloud公式ブログ: Cloud FunctionsはCloud Run functionsへ(2024-08)

タイトルとURLをコピーしました