Sapporo 2026 : Grid Connect Rendezvous
Google Cloud Quick Start
最初に押さえておきたい Google Cloud の基礎知識
@sinmetal
Developers Expert for Cloud
Agenda
今日話すこと
Project
まずは Project を作るところから
- Google Cloud では何をするにしても Project を作成し、この中にリソースを置いていく
- Project は手軽に作れるので、環境ごとに作るのが基本
チームで開発する時は「個人ごとの Project」を作ることも多い
Project
Project の識別子と分けるメリット
Project ID
自分で決める一意の識別子全世界で一意。CLI コマンドや設定ファイルで最も頻繁に利用する。
Project Number
自動採番される数字Google Cloud により自動で割り当てられる。内部識別やデフォルト SA 名に登場。
Project Name
好きな名前（識別子ではない）重複可能。※sinmetal は「逆にややこしい」ので付けたことがない。
課金
誰の・どの環境のコストかが Project 単位で一目瞭然。
IAM
権限を環境や人ごとに分離。事故を防いで管理しやすい。
Audit Log
操作ログが混ざらず、監査やインシデント調査が容易。
Quota
上限も Project 単位。dev の暴走が prod を巻き込まない。
Billing
お金の見方と可視化
- Google Cloud Console でそのまま確認できる
- BigQuery に Export して、自分が見やすいように加工して見ることも多い
- 可視化は
datastudio.google.comが無料＆簡単で便利 - 今は AI に指示して HTML ダッシュボードを作るのも良い選択肢
Billing Export の定番
日次・サービス別・ラベル別に集計しておくと、「急に増えたコストは何か」がすぐ分かる。個人開発でも最初に確認する癖を付けておくと安心。
Billing
予算アラートと上限設定 (Spend Cap)
Billing Budget & Alert
Billing Account に月額料金のアラートを設定可能。
⚠️ 注意: Alert が鳴るだけで自動停止はされない！リアルタイム反映ではないため、1 アクションでのコスト急増にも注意。
Spend Cap Budgets（予算上限）
一部プロダクトで予算超過時に新規リクエストを遮断。
⚠️ 注意: 既存の処理は継続される。長時間ジョブは超過後も動くため、ハードリミットなら余裕を持った値に設定。
Region & Zone
Region（リージョン）の選び方
Region はデータセンターが存在する物理的な場所を表す。各 Region 内に複数の Zone（独立した設備）が存在。
🇯🇵 日本国内の 2 つの Region
- 日本国内のユーザーに対して 超低レイテンシ
- 国内のデータ主権・コンプライアンス要件に対応
- 本番システムの東西冗長（Tokyo + Osaka）構成も可能
🇺🇸 日本以外でよく使う: us-central1
- 新機能が最速リリース: 最新の AI モデルや新機能はまず us-central1 から提供されることが多い
- 料金が 2〜3 割安い: 東京（asia-northeast1）と比べて各種リソースが安価！
- ネットワーク遅延を無視できるバッチや、検証用途に最適
Region & Zone
Quota（割り当て）の 2 つの側面
リソース数や API リクエスト数の上限。上限に当たると Quota Error が返る。https://docs.cloud.google.com/docs/quotas/overview
① Google 側のリソース保護
特定ユーザがデータセンターを占有するのを防ぐ。
「5000兆円あっても DC は占有できない」
→ 我々からは上限引き上げ申請を行うことが多い。
② ユーザ自身の使いすぎ抑制
無限ループや設計ミスによる支払額爆発を防止。
事故防止のために自分自身で制限をかける
→ 我々が上限を引き下げて設定することが多い。
BigQuery での定番 Quota: 無料枠（月 1TiB）が便利だが、スケーラビリティが高すぎて「1PB 読んで！」にも即応えて課金爆発する。そのため 1 日のクエリ読み込み Quota を引き下げて制限をかける！
IAM
Identity and Access Management
誰が・何に対して・何をできるかを決める仕組み。
基本ロール（大昔から）
editor
viewer
最近の呼び方へ
writer
reader
理想は最小権限。しかし個人開発なら最初は Project Level で雑に付けても大丈夫！
IAM / Service Account
Service Account
- Project の中に作れるアプリケーション用のアカウント
- 権限の分割や Quota の把握のためにアカウントを分けて運用する
# 自作する Service Account の例
api-server@devfest-sapporo-prod.iam.gserviceaccount.com
batch-worker@devfest-sapporo-prod.iam.gserviceaccount.com最初から存在する Service Account（デフォルト / マネージド）
{PROJECT_NUMBER}-compute@developer.gserviceaccount.com
champions-build@{PROJECT_ID}.iam.gserviceaccount.com
ここでも Project Number と Project ID が実際に使い分けられている！
IAM / ADC
Application Default Credentials
Client Library で Google API を実行する時に、認証を自動的に行なってくれる仕組み。
Google Cloud 上
metadata server から OAuth2 token を自動取得。鍵ファイルをサーバーに置く必要はない。
local 開発環境
gcloud auth login --update-adc を実行すれば、己の Google Account の認証情報を取得してくれる。
$ gcloud auth login --update-adc動かした後を見る道具
Logging
ログの収集・検索。勝手に出してくれるものも多く、真っ先に見る。
Monitoring
メトリクスとアラート。異常検知やパフォーマンス監視の入口。
Trace
リクエストの分散トレース。どこで時間を使っているかを可視化。
Profiler
CPU / メモリ消費をコード単位で特定するプロファイラ。
よく見る（手軽・自動）
Logging と Monitoring は出力が簡単・勝手に出るので日常的に確認。
必要に応じて導入
Trace と Profiler はアプリ側への組み込みが必要。深掘りしたい時に導入。
Compute
コンピュートサービスの全体像
App Engine
PaaS (Web)Google Cloud 最古の Product。今も現役だが UPDATE は控えめ。
Compute Engine
IaaS (VM)仮想マシン (VM) サービス。OS レベルから自由に構成したい時に利用。
Cloud Run
Serverless ContainerContainer を起動するサービス。午後のハンズオンで扱うのはこれ！
GKE
KubernetesGoogle Kubernetes Engine。大規模・複雑なコンテナクラスタの運用基盤。
Google Cloud の Compute 各プロダクトには無料枠が用意されている！まずは Cloud Run から始めるのがおすすめ！
Compute / Cloud Run
Cloud Run の 4 つのモード
Instance のライフサイクルが異なる。ユースケースに合わせて最適なモードを選ぼう。
Service
最ポピュラーHTTP Request を受け取り Response を返す Web API 向け。一問一答。リクエスト数に合わせて 0〜N 台へ自動スケール増減。
Instance
常時起動HTTP Request/Response を受けるが、指定台数のマシンを常時起動。LLM Agent など長時間同一マシンで処理する用途向け。
Job
バッチ・完遂終了何かしらの Task を実行し、完遂すれば終了する。定期実行バッチやデータマイグレーションに最適。
Work Pools
キュー・非同期常駐一定台数のマシンを起動し続ける。Pub/Sub やキューから届く非同期タスクを処理し続けるために誕生。
Storage
ストレージ & データベース
Cloud Storage Object Storage
ファイルの保存に利用。Cloud Run は永続ディスクを持たず終了時に消えるため、ファイルの受け渡しはこれを使う。
Cloud SQL マネージド RDBMS
MySQL, PostgreSQL 等のマネージド。中身は GCE に DB を入れた構成で、機能としては MySQL や PostgreSQL がそのまま提供される。
Firestore Key-Value Store
Instance 概念がなく RW 課金。毎日無料枠あり。モードや Edition が複数あり（次スライド参照）。午後に扱うのはこれ！
Cloud Spanner 分散型 RDBMS
Google 内部 DB。全文検索や Spanner Queue など連携が強力。ただし「絶対分散する」ため分散 DB の知識が必要。
AlloyDB Cloud-Native
PostgreSQL 互換の高速 DB。Primary と Read Replica の定番構成だが、コンピュートとストレージが分離されている。
Bigtable Key-Value Store
かなり巨大な Instance を起動。IoT センサーやアクセスログのような大量の INSERT（書き込み）がある大規模向け。
Storage / Cloud Firestore
Cloud Firestore のモードと Edition
Instance 概念がなく RW 課金で毎日無料枠あり！モードや Edition が複数あってちょっとややこしい。
Native Mode
Standard Edition
午後に扱うのはこれ！
基本となるドキュメント指向 KVS。まずはここから始めるのが標準的で最も扱いやすい。
Native Mode
Enterprise Edition
複雑なクエリ対応
集計、算術演算、配列、セット、型変換、データの結合など複雑なクエリにも対応（少し単価高め）。
MongoDB
互換モード
MongoDB API
MongoDB のインターフェースで利用可能。既存の MongoDB アプリケーションの移行に最適。
Datastore
Mode
旧来システム互換
昔からある Cloud Datastore 互換。大規模スケールや既存システム資産の継続運用向け。
💡 午後のハンズオン: 最もポピュラーで扱いやすい Native Mode Standard Edition を使います！
Data & Analytics / BigQuery
BigQuery: みんなが使うサーバーレス分析基盤
Google Cloud を使う人なら全員使うくらいみんな使う。アドホックなクエリに適したサーバーレス DWH。
🔗 豊富なサービス連携
Billing Export、Logging Sink、Cloud Trace Export など、Observability をはじめとしたサービスで連携できる機能が非常に豊富。
⚡ Instance・Index 不要
Instance もなく Index の作成も不要。SQL を書くのが面倒でも、Gemini に頼んで書いてもらえば OK。
🎁 毎月 1 TiB のクエリ無料枠
料金はクエリ時に読み込んだデータ量に応じた従量課金（毎月 1 TiB 無料）。
ストレージ料金も $0.023 / 1 GiB-month 程度。
💬 sinmetal の体験談:
「10 年ほど BigQuery を使っているが、個人としては 800 円くらいしか払ってないのではなかろうか？」
⚠️ Quota 設定（スライド 8 参照）: スケーラビリティが高く大量のデータもすぐ読み込んでしまうため、使いすぎを防ぐには Quota でクエリ上限を引き下げて設定することが多い。
Workshop / Setup
午後の WorkShop に向けて最初のセットアップを行いましょう！
① Google Cloud Project のセットアップ
午後のハンズオンをスムーズに開始できるよう、手順に沿って Google Cloud の Project をセットアップしましょう。
Setup ガイド (GitHub)
Project 作成から必要な API の有効化まで詳しく解説されています。
💡 必要な API（Cloud Run Admin API, Firestore API など）の有効化も忘れずに行いましょう！
② 料金・無料枠のチェック
利用前に無料枠や見積もりツールを確認しておくと安心です。
無料枠一覧（Free Cloud Features）
各プロダクトごとの毎月の無料枠詳細を確認できます。
Pricing Calculator（見積もり計算ツール）
構成に応じた月額費用の概算シミュレーションが可能です。
午後のハンズオンをスムーズに開始できるよう、お昼休みや休憩時間に Project を準備しておきましょう！
Appendix / CLI & Tooling
Antigravity CLI with gcloud SDK
MCP だけでなく、機能が多い gcloud CLI や REST API の直接実行も便利。
🛠️ gcloud CLI と REST API の活用
WorkShop では Antigravity 2.0 と IDE を使用しますが、Antigravity CLI も便利です。
Antigravity 2.0 は MCP で Google Cloud とやり取りしますが、MCP Server がすべてのことができるわけではありません。gcloud CLI の方が長年開発され続けているので機能が多いです。
Terminal なら REST API を直接 curl で呼ぶことも可能。Google APIs Explorer も整備されており、手動だと面倒な API Body 組み立ても Gemini に頼めばすぐやってくれます。
🔍 実践ユースケース: ログ解析
Antigravity CLI に「Cloud Run アプリのログを見て Error の原因を探って」と指示すれば、gcloud logging を使って調べてくれます。
⚠️ 注意: Token 消費
ログの量が多いと Input Token を結構消費するので注意が必要です。
Appendix / Architecture
Firebase Hosting と Cloud Run の合わせ技
静的コンテンツは Firebase Hosting で配信し、動的な処理だけ Cloud Run へ送る組み合わせ。
⚡ 静的コンテンツの配信
HTML や CSS など Static なコンテンツを Cloud Run から配信するのはあまり効率がよくありません。フロントに CDN のようなサービスを置くことで効率よくできます。
ここで紹介するのが Firebase Hosting です。Static なコンテンツをホストしてくれますが、これだけだと動的な部分を処理できません。
🔀 Cloud Run への Rewrites 機能
Firebase Hosting には 任意の path を Cloud Run に rewrites する機能 があります。
"rewrites": [ {
"source": "/api/**",
"run": { "serviceId": "backend-service", "region": "asia-northeast1" }
} ]
この機能を使えば、/api/* だけ Cloud Run に送り、Static なコンテンツは Firebase Hosting で、Dynamic なコンテンツは Cloud Run で処理することができます。
Appendix / Security & Auth
認証がしたい時に便利な Identity-Aware Proxy
社内限定や特定メンバー向けのサイトを作る時、設定だけで Google ログインを実装できる仕組み。
🔐 アプリ側の認証実装が不要
限られたメンバーや社内メンバー限定に公開したい Web サイトに最適。IAP を設定するだけで Google Account でのログイン画面と認証 を Cloud 側が肩代わりしてくれます。
アプリケーション側には認証通過後のリクエストのみが到達。誰で認証されているかは Header から簡単に取得できます。
👥 柔軟なアクセス制御とサービス分離
IAP を通過するには、対象リソースの roles/iap.httpsResourceAccessor 権限が必要。
全員がアクセスできる
public-service と、管理者専用の admin-service を分け、admin-service にだけ IAP をかけるといった分離も簡単！
Appendix / Architecture
非同期処理を使いこなす
タスクを分割し、必要なリソースごとに別マシンへ渡す・必要な時だけマシンを使う設計が重要！
Cloud Tasks
Push 型 / 個別タスク管理Cloud Run Service と最も相性が良く、Push で HTTP リクエストを送ってくれるのでとっつきやすい。
- Rate 指定: 秒間リクエスト流量の上限を制御可能
- 可視化: Queue の中に溜まっている Task を確認・管理可能
- 遅延実行: 「○分後に実行」のスケジューリングも容易
Cloud Pub/Sub
Pull & Push 型 / 大規模メッセージング大量のイベント配信・メッセージングの基盤。Pull 型配信を活用したい場合に最適。
- バッチまとめ処理: Task をある程度まとめて一括処理したい時
- 常駐ワーカー: 同一マシンインスタンスで処理し続けたい時
- ファンアウト: 1 つのイベントを複数システムへ並列配信
💡 非同期処理を使いこなせば、分散処理でタスク処理時間を短縮したり、Spot VM を使って安く大量タスクを処理できます！
Appendix / Hands-on Idea
まずは Cloud Tasks を使ってみよう
「ゲストハウスの予約完了メール送信」を題材に、非同期処理の威力を体験する。
❌ リクエスト内で同期処理する場合
ユーザーのリクエスト:
「予約リクエスト」→「DB 登録」→「メール送信（外部 API）」→「レスポンス」
メール送信処理に時間がかかると、ユーザー側の登録完了・画面表示が待たされてしまう。外部メール API の一時障害で予約自体がエラーになるリスクも。
⭕ Cloud Tasks で非同期化する場合
ユーザーのリクエスト:
「予約リクエスト」→「DB 登録」+ Cloud Tasks に Task Add → 即レスポンス！⚡
リクエスト内ではタスクをキューに入れるだけなので一瞬で完了！後から Cloud Tasks がバックグラウンドで Push してメール送信処理を実行。
💡 手軽に試すコツ:
実際にメール送信を実装するのは面倒なので、最初は Cloud Run 側でログ出力（log.Println("Send mail to guest")）する程度にしておくのが楽でおすすめ！
Appendix / Observability & Logging
構造化ロギングで同じ Request のログをまとめる
TraceID を活用して Cloud Run へのリクエストとコンテナログを紐づけ、リクエスト単位で集約する。
⚠️ 単純な JSON 出力では集約されない
stdout や stderr に単純に JSON を出力しただけでは、並行する複数リクエストのログが混在し、Request 単位でログを集約することができません。
💡 そこで便利なのが TraceID:
Cloud Trace の仕組みの一部ですが、分散トレースだけでなく Log をリクエストごとに束ねる ためにも使えます。
Cloud Logging 画面で親リクエストの配下に各ログがネスト表示されるため、調査効率が劇的に上がります。
🔑 Header から TraceID を取得して付与
Cloud Run への Request には X-Cloud-Trace-Context ヘッダーが付いており、ここに TraceID が入っています。
X-Cloud-Trace-Context: 105445aa7843bc8bf206b120001000/1;o=1
// 2. ログ出力時に trace key にセットして出力
{
"severity": "INFO",
"message": "ゲストハウス予約完了",
"logging.googleapis.com/trace":
"projects/PROJECT_ID/traces/TRACE_ID"
}
ログ出力時に trace key に TraceID を入れると Trace とログが紐づき、Request 毎にまとまります。
DevFest Sapporo 2026: Grid Connect Rendezvous | Google Cloud Quick Start