Google CloudとAWSの違いと考察

はじめに

こんにちは、20倍くらいに薄めたハイボールにはまっているGIクラウドのスペランカーYoshioです。お酒は好きなんだけど、アルコールがちょっと苦手。甘いお酒も苦手だから、低アルコールの缶チューハイもNG。日本酒バーのマスターにそんな話をしたら、『天明　さらさら純米』というアルコール度数低め(と言っても11.5%)な日本酒を勧めてもらって感謝カンゲキ雨嵐。本当にアルコール感が少ないのよ。

さて、弊社はGoogle Cloudを推奨する立場ですが、AWSを全く使わないわけではありません。僕自身も久しぶりにAWSを使う機会があり、懐かしさを感じながら作業しました。そこで感じたのは、AWSは良くも悪くも「Webエンジニア的」すぎるという点です。Google Cloudを使う場合はモデリングのように抽象的なところから始めるのに対して、AWSは具体的なサービスを自由度高く組み合わせてシステムを構築していくためか、自然と意識が「どう実装するか」という手段に向かいやすいのです。この「実装に意識が向かいやすい」という特性は、まず動くものを作るというフットワークの軽さを得られる反面、エンジニアにとっては手を動かした分だけ「仕事をした感」を得やすいという側面があります。一方で、発注側もかけたコストに対して目に見える進捗や「動くモノ」を求める傾向があります。これは、お互いに表層的な満足感を得やすい構造になりやすく、成果に対して慎重になる必要がありそうです。

この、僕が直観したAWSの「実装に意識が向かいやすい」という特性の正体は何なのか、対するGoogle Cloudの特性は何なのか。そして、AWSを使うにあたっての僕の懸念はいかに解消すべきなのか。その謎を解明すべく、我々はアマゾンの奥地へ向かった――。

1. 二つのクラウド、その哲学の源流

調査を進めるうちに、僕の感じた「Webエンジニア的」という感覚の正体は、両社の成り立ちと、それによって育まれた根源的な「哲学」の違いにあることが分かってきました。AWSとGoogle Cloudが提供する体験の差は、単なる機能の優劣ではなく、それぞれが何を中核事業とし、どのような課題を解決するためにイノベーションを進めてきたかの必然的な結果ということです。

1.1 AWS：インフラ部品を供給する「ビルディングブロック」哲学

AWSの哲学は、その誕生の物語に集約されています。Amazonは、絶え間ないトラフィックの増大とサービス拡大という課題に直面し、その巨大なインフラを効率的に運用するため、徹底的にコンポーネント化された、信頼性の高い内製システムを構築しました。AWSは、このスケーリング問題を解決するために生み出されたインフラ部品（ビルディングブロック）を、外部の顧客にも提供するという発想から生まれました。

2006年にサービスが開始された当初、提供されたのはAmazon S3（ストレージ）とEC2（仮想サーバー）でした。これらはITインフラにおける最も根源的な「部品」そのものです。この歴史的経緯が、AWSの基本姿勢を決定づけました。すなわち、個別の強力なコンポーネントを提供し、ユーザーに「想像できるものなら何でも自由に発明し、構築する自由」を与えることです。

ジェフ・ベゾスが出したとされる、インターフェイス公開義務化の社内指令 (Bezos API mandate)に端を発したこのアプローチにより、各サービスは独立して機能し、APIを通じて連携します。これにより、ユーザーは最適なサービスを自由に選択し、組み合わせることが可能になりました。それは同時に、サービス間の連携や統合の責任がユーザー側に委ねられることも意味します。AmazonのLPの筆頭「顧客へのこだわり（Customer Obsession）」が、開発者（顧客）に特定の方法を押し付けず、ツール選択の最大限の自由と責任を与えるという形で表れているとも言えます。

1.2 Google Cloud：完成された基盤を提供する「プラットフォーム」哲学

一方、Google Cloudの哲学は、Googleが誇る検索エンジンやデータ解析基盤といった、高度に抽象化された世界規模の「サービス」を外部に提供することから発展しました。その歴史はPaaS（Platform as a Service）から始まっており、開発者がインフラの管理から解放され、ビジネスロジックに集中できる環境を提供することを最優先に考えています。

AWSがIaaS（Infrastructure as a Service）から始まったのとは対照的に、Googleが2008年に発表した最初の主要なクラウドサービスはGoogle App Engine (GAE) でした。GAEは、開発者がサーバー管理を一切意識することなく、アプリケーションをデプロイし、トラフィックの増大に応じて自動でスケールさせることを目的としたPaaSです。これは、インフラを可能な限り抽象化し、開発者の生産性を高めるというGoogle Cloudの根源的な思想を明確に示しています。

BigQueryやVertex AIといったサービスは、単なるインフラの部品ではありません。それらは、Googleが長年の知見を凝縮して作り上げた、強力でマネージドな「プラットフォーム」そのものです。目指すのは、開発者がインフラの複雑さを意識することなく、「何をしたいか（What）」の実現に集中できる環境を整えることです。

この哲学の違いは、両社が当初想定していた「顧客」像の違いからも生まれています。AWSの初期ターゲットは、オンプレミス環境の管理に慣れた「インフラエンジニア」や「システム管理者」でした。EC2やVPCといったサービスは、彼らが慣れ親しんだサーバーやネットワークといった概念で語りかけ、クラウド上でも同様のきめ細やかな制御を提供することを目指しました。対照的に、Google App Engineの初期ターゲットは、インフラ管理をしたくない「アプリケーション開発者」でした。

2. アーキテクチャに現れる哲学の違い

この哲学の違いは、具体的なサービスアーキテクチャの隅々にまで浸透しています。ここでは、IaaS、PaaS/サーバーレスという主要なレイヤーで、その違いがどのように現れているかを見ていきましょう。

2.1 IaaSレイヤー：制御のAWS vs 抽象化のGoogle Cloud

クラウドの根幹をなすIaaSレイヤーでは、哲学の違いが最も顕著です。

比較項目	AWS(EC2/VPC/S3)	Google Cloud(GCE/VPC/GCS)	設計思想の違い
ネットワークの基本単位	リージョン中心。 VPCはリージョンに閉じており、サブネットは単一のアベイラビリティゾーンに紐づく。	グローバル中心。 VPCはグローバルリソースであり、サブネットはリージョン単位（複数のゾーンにまたがる）。	AWSは物理的な境界をユーザーに意識させ、明示的な設計を求める。Google Cloudはそれを抽象化し、グローバルな視点を提供する。
設定の思想	明示的な設定。 ユーザーがルートテーブル、ゲートウェイ等を一つひとつ設定・接続する必要がある。	賢明なデフォルト。 多くの設定が自動化されており、「すぐに使える」状態を目指す。	AWSはユーザーに完全な制御権と責任を委ねる。Google Cloudは複雑さを隠蔽し、一般的なユースケースを簡素化する。
エコシステム	独立したサービスの集合体。 各サービスがAPIを通じて連携する「疎結合」モデル。	統合されたプラットフォーム。 サービス間の連携がよりシームレスになるよう設計された「密結合」モデル。	AWSは組み合わせの自由度を最大化する。Google Cloudは開発体験の一貫性と生産性を最大化する。

この表が示すように、AWSはユーザーにインフラの構成要素を一つひとつ手渡し、「YOU、やっちゃいなよ」と語りかけます。一方、Google Cloudはプラットフォームをお膳立てし、「いいんだね、やっちゃって」と宣言するのです。

2.2 PaaS/サーバーレスレイヤー：開発者体験への直接的な影響

より抽象度の高いPaaSやサーバーレスのレイヤーでは、この違いは開発者の日々のワークフローや「Hello, World!」までの時間に直接的な影響を与えます。

コンテナの抽象化 (AWS Fargate vs. Google Cloud Run)

AWS Fargateは、コンテナ向けのサーバーレス「コンピュートエンジン」です。サーバー管理は不要になりますが、ユーザーは依然としてVPC、ロードバランサー、タスク定義といった周辺のエコシステムを設定する必要があります。これは、EC2というビルディングブロックをコンテナ用に抽象化したもの、と捉えることができます。

Google Cloud Runは、コンテナイメージから最小限の設定で、それこそユースケース次第では単一のコマンドでサービスの公開が可能なほどに抽象化されています。開発者はインフラをほとんど意識することなく、コード（コンテナ）をデプロイすることに集中できます。

BaaS (Backend as a Service) (AWS Amplify vs. Google Firebase)

AWS Amplifyは、認証（Cognito）やデータベース（DynamoDB）といった既存のAWSビルディングブロックを組み合わせてバックエンドを構築するための「ツールとサービス」群です。効果的に使うには、背後にある各AWSサービスへの理解が求められます。

一方で、Google CloudのFirebaseは、独自の認証、リアルタイムデータベース、関数などを内包する、より「自己完結したオールインワンのプラットフォーム」です。広範なGoogle Cloudエコシステムの知識がなくとも、迅速に開発を始めることができます。

ここでも、AWSは「既存の部品をどう組み合わせるか」と促すのに対し、Google Cloudは「抽象化されたプラットフォームにいかにはめ込むか」を考えさせます。

3. 「手段の目的化」という罠の構造

さて、ここからが本題です。なぜAWSの「ビルディングブロック」哲学が、「表層的な満足感」や「手段の目的化」という罠につながりやすいのでしょうか。その答えは、技術的な特性と、それを利用する人間の心理、そしてプロジェクト管理の力学が組み合わさることで生まれる構造的な問題にあります。

3.1 「仕事をした感」の正体

エンジニアは複雑なシステムを巧みに組み合わせ、問題を解決することに「知的な喜びと達成感」を感じる生き物です。AWSのビルディングブロックを一つひとつ設定し、VPCを設計し、IAMポリシーを記述し、それらが意図通りに連携して動作した時、具体的で測定可能な成果が目の前に現れ、強い満足感、すなわち「仕事をした感」が生まれます。

AWSの粒度の細かさは、この「実装の労力」を非常に可視化しやすいものにします。プロジェクト計画は、「VPCの設定」「IAMロールの展開」「EC2インスタンスのデプロイ」といった具体的な技術タスクで埋め尽くされます。これらのタスクを一つひとつ完了させていくことは、明確な進捗として認識され、エンジニアのモチベーションを高めます。

3.2 発注者との共犯関係

一方で、発注者側も、プロジェクトの最終的なビジネス成果（例：売上向上、コスト削減）が不確実であったり、測定が困難であったりする場合、投資に対して「動くモノ」が目に見える形で出来上がっていく過程を求めがちです。複雑なアーキテクチャ図や、完成したインフラ設定の報告書は、支払ったコストが正しく使われていることの具体的な証拠として機能し、安心材料となります。

この 「実装の進捗を実感したいエンジニア」 と 「目に見える成果で安心したい発注者」 の思惑が一致した時、禁断の扉「手段の目的化」が開かれます。プロジェクトの関係者全員が、実装タスクの完了という共通の満足感を得ることに集中し、重力に魂を引かれる人類のように、いつの間にかビジネスの成功ではなく仕様通りに構築することに引き寄せられます。コンサルティングやSIビジネスとの相性が非常に良いのも頷けます。

これは誰か一人が悪いわけではなく、AWSの「ビルディングブロック」という特性と、プロジェクトにおける人間の心理が組み合わさることで生まれやすい「構造的な問題」です。AWSを使ったプロジェクトが陥りやすいだけであって、AWS固有の問題ではありません。Google Cloudを使っても無視はできない、プロジェクト自体が抱える問題です。

4. クラウドを戦略的に使いこなすために

では、この「実装に意識が向かいやすい」というAWSの特性を理解した上で、僕たちはどのようにクラウドと向き合えばよいのでしょうか。僕は言えるのは、「プロジェクトの目的やチームの特性に応じて、最適な哲学を選択し、その特性を意識的にマネジメントする」という何の面白みもない回答だけです。銀の弾丸はありません。少なくとも、「お宅のIAMは相変わらずですな」とか、「お前んちのドキュメントはウォーリーを探せを参考に書かれたのかい？」とか言って、けなし合う必要はありません。

今ではAWSも抽象化を意識したサービスを展開しており、Google Cloudもきめ細やかな制御を提供しようと努めています。しかしながら、両者の根底にある哲学と重心は、依然として明確に異なっています。最終的に、どちらのクラウドを選ぶべきかは、プロジェクトの性質によって決まってくるでしょう。

「ビルディングブロック哲学」（AWS）が適しているケース

• 独自の要件を持つプロジェクト： 定義済みのプラットフォームには収まらない、非標準的なアーキテクチャを構築するために、最大限の制御と柔軟性が必要な場合。
• 深いインフラ専門知識を持つチーム： 経験豊富なシステムエンジニアが在籍し、そのきめ細やかな制御能力を活かして、高度なコスト最適化やパフォーマンスチューニングを行える場合。
• 既存のエコシステム： 既に組織がAWSに深く投資しており、その広範なサービス群との連携が不可欠な場合。

「統合プラットフォーム哲学」（Google Cloud）が適しているケース

• 市場投入までの時間を最優先するプロジェクト： 製品や機能を可能な限り迅速にユーザーの元へ届けることが至上命題であるスタートアップや新規事業。
• アプリケーション/データロジックに集中したいチーム： チームの中核的な能力がアプリケーション開発やデータサイエンスにあり、インフラ管理の負荷を最小限に抑えたい場合。
• クラウドネイティブな開発： モダンなコンテナベースまたはサーバーレスのアプリケーションを、思想が反映されたプラットフォーム上で効率的に開発したい場合。

エンジニアの成長戦略

こうやって俯瞰してみると、エンジニアに求められる知見もAWSとGoogle Cloudで異なることが分かります。

• AWSエンジニア：アンチパターンをどれだけ知っているか。
• Google Cloudエンジニア：ベストプラクティスをどれだけ知っているか。

クラウドエンジニアとしてどう経験の積んでいくか、成長戦略の参考になれば幸いです。ちなみに、活動の場所をAWSからGoogle Cloudに移した僕からすると、逆は大変そうだなという感覚を持っています。

まとめ

AWSが提供する自由さは、プロダクトへの責任と表裏一体です。AWSのビルディングブロックは、クラウドエンジニアにとっては効果的な道具になり得ますが、目的を見失えばただの複雑な部品の山にもなり得ます。対するGoogle Cloudは、目的地まで迷いにくい高速道路を提供してくれる一方で、その道から外れたい時に感じる不便さからは逃れられません。

僕たちソフトウェアエンジニアの仕事は、単にコードを書き、システムを構築することではありません。技術という手段を用いて、ビジネスや社会の課題を解決することです。それを忘れず、各プラットフォームの哲学を理解して使い分けていきたいですね。

アマゾンの密林から出てこれないんじゃないかと思いながら書いていたのですが、なんとか脱出できてよかった。