はじめに
「Cloud RunでWebサービスを作りたいんだけど、OAuthって必須なの？」
「Firebase Authって何が違うの？」
「Secret Managerはどこで使うの？」
Google Cloudを使い始めると、こういった疑問にぶつかることがあります。
正直なところ、私も最初はこれらの関係性がよく分かりませんでした。公式ドキュメントを読んでも、それぞれの説明はあるものの「で、結局どう組み合わせるの？」という部分がモヤモヤしたままで。
この記事では、OAuth、Firebase Auth、Cloud Run、Artifact Registry、Secret Managerの5つのサービス・概念について、「たとえ話」と「Mermaid図」を使って、エンジニアでなくても直感的に理解できるよう整理していきます。
読み終わる頃には「あ、そういう関係だったのか」とスッキリしていただけると思います。
この記事の対象読者
- Google Cloudを使い始めた開発者
- Cloud RunでWebサービスを構築しようとしている方
- OAuth、Firebase Auth、Secret Managerの関係性がわからずモヤモヤしている方
- 非エンジニアだが、これらの技術の概要を理解したい方
結論から：Cloud RunにOAuthは必須ではない
まず結論を先にお伝えします。
Cloud RunでWebサービスを動かす際、Google Cloud OAuthは必ずしも必須ではありません。
「作りたいサービスが何をしたいか」によって、必要かどうかが決まります。
具体的には以下の通りです。
OAuthが「不要」なケース
- 誰でも見られる公開サイト：ブログ、ランディングページ、コーポレートサイトなど
- 独自のログイン機能を作る場合：メールアドレスとパスワードだけで管理する独自の仕組みをイチから作る場合
- 外部の認証サービスを使う場合：Auth0やLINEログインなど、Google以外の認証だけを使う場合
OAuthが「必要」になるケース
- 「Googleアカウントでログイン」ボタンを付けたい
- 特定のユーザー（社内など）だけに限定公開したい
- ユーザーのGoogleデータを操作したい（カレンダーに予定を入れる、ドライブにファイルを保存するなど）
では、ここから各サービスの詳細と関係性を解説していきます。
全体像のイメージマップ
まずは、それぞれのサービスがどのような役割でつながっているかを図にしました。
この図を見ると、各サービスの役割分担がなんとなく見えてきませんか？
それでは、一つずつ詳しく見ていきましょう。
1. OAuth とは？ ── デジタルな「合鍵（入館証）」
一言で言うと
OAuthは、パスワードを渡さずに、特定のデータや機能へのアクセス権を安全に受け渡しする仕組み（認可） のことです。
たとえ話で理解する
マンションに住んでいるとして、友人に「私の部屋のクローゼットにある本を取ってきてほしい」とお願いする場面を想像してください。
このとき、マンションのマスターキーを渡すのは危険ですよね。友人が悪意を持っていなくても、そのカギをなくしたり、他の部屋にも入れてしまったりするリスクがあります。
OAuthは、「クローゼットの本を取る」という目的だけに使える、期限付きの合鍵を発行する仕組みです。
| 現実世界 | OAuth |
|---|---|
| マスターキー | パスワード |
| 期限付きの合鍵 | アクセストークン |
| 「クローゼットだけ」という制限 | スコープ（権限の範囲） |
| 合鍵の期限切れ | トークンの有効期限 |
OAuthが解決する問題
OAuthがなかった時代、アプリがユーザーのデータ（たとえばGoogleカレンダー）にアクセスするには、ユーザーのGoogleパスワードをアプリに教える必要がありました。
これには以下の問題がありました。
- なりすましリスク：アプリがパスワードを知っているので、何でもできてしまう
- 漏洩リスク：アプリがパスワードを保存するので、そこから漏洩する可能性がある
- 解除の難しさ：連携を解除するにはパスワードを変更するしかない
OAuthはこれらの問題を解決しました。
- なりすまし防止：アプリがユーザーのパスワードを持たない
- 権限の限定：「メールは読めるが、削除はできない」といった細かい設定が可能
- 連携の解除：ユーザーがいつでもGoogleの設定から連携を解除できる
OAuth 2.0 の基本的なフロー
このフローで重要なのは、ユーザーのパスワードがアプリに一切渡っていないという点です。
2. Firebase Auth とは？ ── 笑顔の「受付係」
一言で言うと
Firebase Authは、ユーザー認証を簡単に実装できるサービスです。OAuthという「仕組み」を使いやすくパッケージ化した「完成品」とも言えます。
OAuthとの違い
ここが混乱しやすいポイントなので、整理しておきます。
| 項目 | OAuth | Firebase Auth |
|---|---|---|
| 役割 | 認可のプロトコル・規格 | ユーザー認証を管理するサービス |
| 難易度 | 実装やトークン管理が複雑 | SDKで簡単に実装できる |
| 関係性 | 「部品」 | 「完成品」 |
Firebase Authは、内部でGoogle CloudのOAuthを 「利用している」 関係です。
Firebase Authの「Googleログイン」機能を使うと、背後でGoogle Cloud OAuthのフローが走り、Firebaseがそれを使いやすくラップしてくれます。
Firebase Authが対応する認証方法
Firebase Authは「認証のデパート」のようなもので、さまざまなログイン手段を提供しています。
補足：LINEログインについて
LINEログインはFirebase Authのネイティブ対応プロバイダには含まれていません。LINEログインを実装する場合は、Custom Auth（カスタムトークン認証）またはOpenID Connect（OIDC）プロバイダを使用して連携する必要があります。詳細はFirebase公式ブログの解説を参照してください。
OAuthが必要なログイン方法と不要なログイン方法
| ログイン方法 | たとえ話 | OAuthを使う？ |
|---|---|---|
| メール・パスワード | その店専用の「スタンプカード」を作る | 不要 |
| 電話番号（SMS認証） | 店から届く確認コードで入店 | 不要 |
| 匿名ログイン | 一時的なゲストとして利用 | 不要 |
| Googleログイン | 他社発行の「パスポート」を提示する | 必要 |
| LINEログイン※ | 他社発行の「運転免許証」を提示する | 必要 |
※LINEログインはFirebase Authのネイティブプロバイダではなく、Custom AuthまたはOIDC経由での実装が必要です。
つまり、「Firebase Authを使う ＝ OAuthが必須」ではありません。
どの「ログイン手段」を選ぶかによって、OAuthを使うかどうかが決まります。
Firebase Authの価値
Firebase Authを使うと、以下の「面倒なこと」をすべて丸投げできます。
- パスワードの管理：自分でパスワードをデータベースに保存するのは漏洩リスクがある。Firebaseに任せれば、自社でパスワードを持たなくて済む
- 確認メールの送信：「パスワードを忘れた方へ」のメールや本人確認メールを自動で送ってくれる
- SNS連携の簡単さ：Googleだけでなく、後から「LINEログインも追加したい」となったとき、設定ひとつで増やせる
3. Cloud Run とは？ ── 変幻自在な「厨房（調理場）」
一言で言うと
Cloud Runは、アプリのプログラム（コンテナ）を動かす場所です。
たとえ話で理解する
レストランの厨房をイメージしてください。
- お客さんが来ない時間帯は、調理台を片付けて休憩
- ランチタイムで混み始めたら、調理台を増やして対応
- ディナーが終わったら、また片付けてお休み
Cloud Runは、このような「必要な時だけ動いて、使わない時はお休み」という働き方をします。これを 「サーバーレス」 と呼びます。
Cloud Runの特徴
| 特徴 | 説明 |
|---|---|
| 自動スケーリング | リクエストが増えると自動でインスタンスを増やす |
| ゼロスケール | リクエストがないときは0インスタンスになる（課金も止まる） |
| コンテナベース | Dockerコンテナをそのままデプロイできる |
| 言語自由 | Python、Node.js、Go、Javaなど何でもOK |
Cloud RunとOAuthの関係
Cloud Runを運用する際、OAuthは主に以下の3つのシーンで登場します。
シーン1：Google APIを叩くとき
Cloud Run上のプログラムからGoogle Drive、BigQuery、Google Sheetsなどを操作したい場合、OAuthの仕組みを使って認証を行います。
シーン2：サービス間通信
Cloud Runから別のCloud RunやCloud Functionsを呼び出す際、GoogleがIDトークン（OAuth/OIDCの一種）をヘッダーに付与して「正当な呼び出し元であること」を証明します。
シーン3：エンドユーザーのログイン
「社内限定のWebアプリ」をCloud Runで作りたい場合、Identity-Aware Proxy（IAP）などを使ってGoogleアカウントでのログインを必須にできます。
4. Artifact Registry とは？ ── レシピを保管する「冷蔵庫・棚」
一言で言うと
Artifact Registryは、コンテナイメージ（アプリの実行ファイル）を保管・管理する場所です。
たとえ話で理解する
Cloud Runが「厨房」だとすると、Artifact Registryは 「レシピ（料理の手順書）を保管しておく冷蔵庫や棚」 です。
厨房で料理を作るには、まずレシピが必要ですよね。Artifact Registryにレシピ（コンテナイメージ）を保管しておき、Cloud Runがそれを取り出して「料理」を作る（アプリを実行する）という流れです。
なぜArtifact Registryが必要なのか？
Cloud Runはコンテナベースのサービスです。つまり、アプリケーションを「コンテナイメージ」という形式でパッケージ化して、それをCloud Runにデプロイします。
そのコンテナイメージを保管する場所が必要で、それがArtifact Registryです。
Artifact Registryの特徴
| 特徴 | 説明 |
|---|---|
| 複数形式に対応 | Dockerイメージだけでなく、npm、Maven、Pythonパッケージなども保管可能 |
| IAMによるアクセス制御 | 誰がイメージを読み書きできるかを細かく制御 |
| 脆弱性スキャン | Artifact Analysisと連携して、イメージの脆弱性を自動検出 |
| リージョン選択 | 日本リージョン（asia-northeast1）など、近い場所に保管してデプロイを高速化 |
Container Registryとの違い
以前はContainer Registry（gcr.io）が使われていましたが、現在はArtifact Registryが推奨されています。
| 項目 | Container Registry（旧） | Artifact Registry（新） |
|---|---|---|
| 状態 | 非推奨 | 推奨 |
| 対応形式 | Dockerのみ | Docker、npm、Maven、Python など |
| アクセス制御 | バケット単位 | リポジトリ単位で細かく設定可能 |
| URL形式 | gcr.io/PROJECT_ID/IMAGE |
REGION-docker.pkg.dev/PROJECT_ID/REPO/IMAGE |
Cloud Runでの使い方
Cloud Runにデプロイする際、Artifact Registryのイメージを指定します。
# イメージをビルドしてArtifact Registryにプッシュ
gcloud builds submit --tag asia-northeast1-docker.pkg.dev/PROJECT_ID/my-repo/my-app:v1
# Cloud Runにデプロイ
gcloud run deploy my-service \
--image asia-northeast1-docker.pkg.dev/PROJECT_ID/my-repo/my-app:v1 \
--region asia-northeast1
ソースコードから直接デプロイする場合、Cloud Runが自動的にcloud-run-source-deployというリポジトリを作成してイメージを保管してくれるので、明示的にArtifact Registryを意識しなくても使えます。
5. Secret Manager とは？ ── 絶対に破られない「金庫」
一言で言うと
Secret Managerは、OAuthの合鍵を作るための「マスターキー」や、外部サービスのパスワードなどを保管する保管庫です。
なぜ必要なのか？
OAuthを利用するには、 「クライアントID」 と 「クライアントシークレット」 という2つの鍵が必要になります。特に「シークレット」はパスワードと同じくらい重要な機密情報です。
Cloud Runの環境変数やソースコードに「クライアントシークレット」を直接書き込むのは 非常に危険 です。
- GitHubに誤ってプッシュしてしまう可能性
- ログに出力されてしまう可能性
- 他の開発者の目に触れる可能性
Secret Managerを使えば、これらのリスクを最小限に抑えられます。
Secret Managerの使い方
Cloud RunでSecret Managerのシークレットを使う方法は2つあります。
| 方法 | 特徴 | おすすめ用途 |
|---|---|---|
| 環境変数として渡す | インスタンス起動時に値が解決される | 起動時に必要な設定値 |
| ボリュームとしてマウント | ファイルとして読み込み、常に最新の値を取得 | ローテーションが必要なシークレット |
参考：Cloud Run での Secret Manager のシークレットの使用
6. 5つのサービスの関係性まとめ
ここまでの内容を整理しましょう。
関係性の図解
一言で表現すると
| サービス | 一言で言うと | たとえ話 |
|---|---|---|
| OAuth | 権限を安全に渡すための仕組み | デジタルな「合鍵（入館証）」 |
| Firebase Auth | OAuthを使いやすくパッケージ化したログイン管理ツール | 笑顔の「受付係」 |
| Cloud Run | アプリを動かす実行環境 | 変幻自在な「厨房（調理場）」 |
| Artifact Registry | コンテナイメージを保管する倉庫 | レシピを保管する「冷蔵庫・棚」 |
| Secret Manager | 機密情報を保管する金庫 | 絶対に破られない「金庫」 |
7. 判断フローチャート：あなたのケースでは何が必要？
自分のプロジェクトで何が必要かを判断するためのフローチャートを用意しました。
ここが混乱ポイント！「サービスアカウント」との違い
エンジニアの方がよく「OAuthが必須かな？」と迷う理由に、 「サービスアカウント」 との混同があります。
| 種類 | 主役（誰が許可を得るか） | 特徴 |
|---|---|---|
| OAuth | エンドユーザー（一般のお客さん） | 「私のGoogleカレンダーの中身を見てもいいよ」とユーザーが許可する |
| サービスアカウント | プログラム自身（Cloud Run本体） | 「このCloud Runは、Google Cloudのデータベースを読み書きしてもいいよ」と管理者が許可する |
つまり、Cloud RunでGoogle CloudのFirestoreなどを使うだけなら、OAuthの設定は不要です。「サービスアカウント」という「プログラム専用の身分証」をCloud Runに持たせるだけで済みます。
8. 具体的な設定フロー
ここからは、実際にCloud RunでOAuthを使う場合の設定フローを解説します。
ステップ 1：アプリの「身分証」を作る（OAuth 同意画面）
まず、Googleに対して「これは私のアプリです」という情報を登録します。
やること
- Google Cloud Console → 「APIとサービス」→「OAuth 同意画面」
- アプリ名、サポートメールアドレス、ロゴなどを登録
理由
ユーザーがログインしようとした時に「〇〇アプリがあなたの名前にアクセスしようとしています」と表示される画面を作るためです。
ステップ 2：秘密の「合鍵」を発行する（認証情報）
次に、プログラムがGoogleの機能（API）を使うための鍵を発行します。
やること
- Google Cloud Console → 「APIとサービス」→「認証情報」
- 「OAuth クライアント ID」と「クライアント シークレット」を発行
理由
これがプログラムにとっての「パスワード」になります。
ステップ 3：鍵を「金庫」に隠す（Secret Manager）
発行した「クライアントシークレット」は絶対に外部に漏らしてはいけません。
やること
- Google Cloud Console → 「Secret Manager」
- 「シークレットを作成」をクリック
- 名前（例：
google-client-secret）を入力 - シークレット値にクライアントシークレットを貼り付け
- 「シークレットを作成」
理由
プログラムの中に直接鍵を書くと、誰かにコードを見られた際に盗まれるリスクがあるため、Googleの最強の金庫に預けます。
ステップ 4：厨房（Cloud Run）から金庫を開けられるようにする
Cloud Runが動き出した時に、自動で金庫から鍵を取り出せるように設定します。
やること
-
Cloud Runに「金庫を開ける権限」を与える
- IAM → Cloud Runのサービスアカウントに「Secret Manager のシークレット アクセサー」ロールを付与
-
設定画面で「環境変数」としてSecret Managerの値を紐付ける
- Cloud Run → サービスを選択 → 「変数とシークレット」タブ
- 「シークレットを参照」から、作成したシークレットを選択
gcloudコマンドで設定する場合
gcloud run services update my-service \
--update-secrets=CLIENT_SECRET=google-client-secret:latest \
--region=asia-northeast1
設定の全体像
9. Firebase Authを使う場合の追加フロー
もし「一般ユーザーにログインさせたい」場合は、上記に加えてFirebaseコンソールでの作業が加わります。
ステップ 1：Firebaseプロジェクトの作成
- Firebase Console にアクセス
- 「プロジェクトを追加」→ 既存のGoogle Cloudプロジェクトを選択
ステップ 2：認証方法を有効化
- Firebase Console → 「Authentication」→「Sign-in method」
- 使いたい認証方法（Google、メール/パスワードなど）をオンに
ステップ 3：SDKの導入
フロントエンド（Web/モバイルアプリ）にFirebase SDKを導入します。
// Firebase の初期化
import { initializeApp } from "firebase/app";
import { getAuth, signInWithPopup, GoogleAuthProvider } from "firebase/auth";
const firebaseConfig = {
apiKey: "YOUR_API_KEY",
authDomain: "your-project.firebaseapp.com",
projectId: "your-project",
};
const app = initializeApp(firebaseConfig);
const auth = getAuth(app);
// Googleログインの実行
const provider = new GoogleAuthProvider();
signInWithPopup(auth, provider)
.then((result) => {
console.log(`${result.user.displayName} がログインしました`);
})
.catch((error) => {
console.error("ログインエラー:", error);
});
ステップ 4：Cloud RunでIDトークンを検証
Cloud Run側では、Firebase Admin SDKを使ってIDトークンを検証します。
# Python の例
from firebase_admin import auth, credentials, initialize_app
# Firebase Admin SDK の初期化
cred = credentials.ApplicationDefault()
initialize_app(cred)
def verify_token(id_token):
try:
decoded_token = auth.verify_id_token(id_token)
uid = decoded_token['uid']
return uid
except Exception as e:
print(f"トークン検証エラー: {e}")
return None
Cloud Run × Firebase Auth の連携フロー
10. シナリオ例：社内の自動注文システム
ここまでの内容を踏まえて、具体的なシナリオを見てみましょう。
「社員がGoogleログインして、ボタンを押すとスプレッドシートに注文が記録されるアプリ」 を作る場合。
この例では、5つのサービスすべてが連携しています。
| 役割 | 担当サービス |
|---|---|
| 社員の本人確認 | Firebase Auth |
| アプリの実行 | Cloud Run |
| アプリのイメージを保管 | Artifact Registry |
| スプレッドシートの鍵を保管 | Secret Manager |
| 外部サービス（Sheets）との連携 | OAuth |
11. よくある質問
Q1. Firebase AuthとOAuth、どっちを使えばいい？
回答：用途によります。
- 自分のアプリに「ログイン機能」をつけたい → Firebase Auth
- アプリが「GoogleのAPI」を操作したい → OAuth クライアントの設定が必要
両方必要な場合もあります（例：ログインしたユーザーのGoogleカレンダーに予定を追加する場合）。
Q2. Secret Managerは必須？環境変数じゃダメ？
回答：技術的には環境変数でも動きますが、Secret Managerを使うべきです。
理由：
- 環境変数はCloud Runの設定画面で誰でも見られる
- ソースコードにハードコーディングする誘惑に負けやすい
- Secret Managerなら監査ログも残る
Q3. Cloud Runを公開するだけならOAuthは不要？
回答：その通りです。
誰でもアクセスできる公開サイト（ブログ、LPなど）であれば、OAuthの設定は一切不要です。
Q4. 社内限定にしたい場合は？
回答：Identity-Aware Proxy（IAP）を使うのが最も簡単です。
IAPを設定すると、Cloud Runへのアクセス時に自動でGoogleログインが要求され、許可されたユーザーだけがアクセスできるようになります。
参考：Cloud Run に Identity-Aware Proxy を設定する
12. 【補足】Gemini API を使う場合の OAuth
Cloud Run で Gemini（AI）を使ったチャットアプリなどを作る場合、「OAuth が必要かどうか」は、API の種類とアプリの目的によって決まります。
結論から言うと、 「一般的なチャットアプリを作るだけなら、OAuth 設定は不要（または自動）」 ですが、 「ユーザーの Google ドライブを読み取らせたい」 といった場合には必須になります。
パターンA：AI Studio（APIキー）を使う場合
個人開発やプロトタイプで一番多いパターンです。
| 項目 | 内容 |
|---|---|
| OAuth は必要？ | 不要 |
| 使うもの | API キー |
| 仕組み | Google AI Studio で発行した「API キー」をプログラムに書き込む（または Secret Manager に隠す）だけで Gemini と通信できる |
| 向いている用途 | とにかく早く作りたい、誰でも使えるチャットを作りたい |
パターンB：Vertex AI（Google Cloud）を使う場合
ビジネスや本番環境で、Google Cloud の機能として Gemini を使うパターンです。
| 項目 | 内容 |
|---|---|
| OAuth は必要？ | 意識しなくてOK（自動） |
| 使うもの | サービスアカウント |
| 仕組み | Cloud Run に「Vertex AI を使っていいよ」という権限（サービスアカウント）を持たせるだけで通信できる。裏側では Google の認証システム（OAuth 的な仕組み）が動いているが、複雑な設定画面（OAuth 同意画面など）を触る必要はない |
| 向いている用途 | 企業のシステム、セキュリティを重視する本番アプリ |
パターンC：「ユーザーの私物」を AI に見せる場合
これが OAuth が必須 になる唯一のパターンです。
| 項目 | 内容 |
|---|---|
| OAuth は必要？ | 必須 |
| 用途例 | ユーザーの Google カレンダーを見て AI に予定を調整させる、ユーザーの Google ドライブにある PDF を AI に要約させる |
| 理由 | アプリ（Cloud Run）が「他人のプライベートな領域」に立ち入るため、ユーザー本人から「このアプリに私のデータを渡していいですよ」という OAuth の承認（同意画面）を得る必要がある |
Firebase Auth との関係性（チャットアプリの場合）
AI チャットアプリを作る際、Firebase Auth は 「チャット履歴の保存」 のために使われます。
| 機能 | 役割 | Firebase Auth の必要性 |
|---|---|---|
| AIの返答 | Gemini API が担当 | 不要 |
| 履歴の保存 | 「Aさんの過去の発言」を覚える | 必須（誰が誰か特定するため） |
| ログイン | Googleアカウントで楽にログインさせる | 必須（ここで裏側のOAuthが動く） |
結局、何を準備すればいい？
-
ログインさせたいか？
- はい → Firebase Auth を使おう
-
ユーザーの Google データ（メールやファイル）を AI に扱わせたいか？
- はい → Google Cloud OAuth の設定をしっかりやろう
- いいえ → OAuth 設定はスキップして API キー か サービスアカウント で行こう
-
鍵の管理はどうする？
- API キーや鍵ファイルは Secret Manager に隠して、Cloud Run に読み込ませよう
13. まとめ
最後に、この記事の要点を整理します。
各サービスの役割
| サービス | 役割 | 必須度 |
|---|---|---|
| OAuth | 権限を安全に渡すための「仕組み」 | Googleログインや外部API連携時のみ |
| Firebase Auth | OAuthをラップした「ログイン管理ツール」 | 一般ユーザー向けログイン機能が必要な場合 |
| Cloud Run | アプリを動かす「実行環境」 | Webサービスを動かすなら必須 |
| Artifact Registry | コンテナイメージを保管する「倉庫」 | Cloud Runを使うなら必須（自動作成も可） |
| Secret Manager | 機密情報を保管する「金庫」 | 機密情報を扱うなら強く推奨 |
判断の基準
- 一般公開するだけのサイト → OAuth、Firebase Auth は考えなくてOK
- 「Googleログイン」をつけたい → Firebase Auth（内部でOAuthを使う）
- 社内限定にしたい → IAP または Firebase Auth
- ユーザーのGoogleデータを操作したい → OAuth が必須
- 機密情報を扱う → Secret Manager を使う
- コンテナイメージを管理したい → Artifact Registry を使う
この記事で伝えたかったこと
Google Cloudの認証周りは複雑に見えますが、「誰が」「何を」「どこで」使いたいのかを整理すれば、必要なサービスは自ずと決まります。
- 誰が：エンドユーザー？プログラム自身？
- 何を：ログイン機能？外部API？内部データベース？
- どこで：公開サイト？社内限定？
この3つの軸で考えると、迷いが減るはずです。
参考資料
- OAuth 2.0 を使用して Google API にアクセスする
- Cloud Run のユーザー認証
- Firebase Authentication
- Artifact Registry の概要
- Cloud Run でシークレットを構成する
- Secret Manager の概要
- Gemini API vs Vertex AI の違い
- Vertex AI での認証
この記事が、Google Cloudの認証周りで迷っている方の参考になれば幸いです。
質問やフィードバックがあれば、コメントでお知らせください。