この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。
Firebase公式ドキュメントを確認し、Web・モバイルアプリへ「ユーザーが誰かを確認するログイン機能」を組み込むFirebase Authenticationを整理します。Google Cloud IAMの権限管理とは目的が違う点も説明します。
情報確認基準日: 2026-09-19
まず一言でいうと
Firebase Authenticationは、アプリへユーザーのサインイン機能を追加するサービスです。メールアドレスとパスワード、電話番号、Googleなどの外部IDプロバイダ、匿名認証など複数の方法をSDKから利用できます。
認証（Authentication）は「この利用者は誰かを確かめること」です。IAMのような「Cloud管理者が何を操作できるか」という管理とは分けて考えます。
Google全体での位置づけ
| 観点 | Firebase Authentication |
|---|---|
| 大分類 | Firebase / アプリ開発 / Identity |
| 大きな目的 | Web・モバイルアプリへ安全なユーザーサインインを組み込む |
| パーツ | アプリの入口でユーザーIDを確立する認証層 |
| 一緒に使うもの | Cloud Firestore、Realtime Database、Firebase Hosting、App Check |
| 主な利用者 | アプリ利用者、開発者、サービス運用者 |
sequenceDiagram participant U as 利用者 participant A as Web/モバイルアプリ participant F as Firebase Authentication participant D as Firestore等 U->>A: サインイン A->>F: 認証要求 F-->>A: 認証済みユーザー情報 A->>D: 認証状態を使ってデータ要求 D-->>A: Security Rules等に基づく結果
何ができる？
Firebase Authenticationは、パスワード、電話番号、GoogleなどのFederated Identity Provider（外部のIDサービスを使うログイン）をサポートします。匿名ユーザーとして開始し、後から通常アカウントへ移行する設計も可能です。
SDKとUIライブラリが用意されているため、認証サーバーをすべて自作するよりアプリ機能へ組み込みやすくなります。ただしログイン画面を付ければセキュリティ設計が終わるわけではありません。
利用者別の実務例
一般利用者・事務職
サービス利用時に「Googleでログイン」「メールでログイン」などを見ることがあります。その裏側で、アプリがユーザーごとのデータを安全に分けるための本人確認に使えます。
IT管理者・サービス運用者
どのSign-in providerを許可するか、MFA（多要素認証）が必要か、ログや利用者管理をどう行うかを検討します。企業要件ではIdentity Platformへのアップグレードで追加機能が必要になる場合もあるため、現行料金・機能を公式ページで確認します。
開発者
Web、Android、iOS、FlutterなどのSDKを使ってサインイン状態を取得し、Firestore等のSecurity Rulesと組み合わせてユーザー別アクセスを制御します。
IAMやService Accountとは何が違う？
| 仕組み | 主に「誰」を認証・制御する？ | 代表用途 |
|---|---|---|
| Firebase Authentication | アプリのエンドユーザー | ログイン、ユーザー別データ |
| Google Cloud IAM | 管理者・開発者・ワークロード等 | Cloudリソースの操作権限 |
| Service Account | アプリや自動処理などの非人間主体 | サーバー間・自動処理の認証 |
この3つを同じ「Googleのログイン」と考えると設計を誤りやすくなります。
Microsoft経験者はどう理解する？
Microsoft側ではアプリ向け顧客ID基盤と比較したくなりますが、製品体系・料金・管理モデルは完全には一致しません。「アプリのエンドユーザーを認証する部品」という役割を先に揃えてから、Microsoft Entra External ID等の現行機能と要件別に比較します。
Firebase Project・API・料金
Firebase AuthenticationはFirebase Projectの一部として利用します。利用する認証方式や規模、Identity Platformへのアップグレードなどで条件が変わるため、固定料金を記事だけで覚えず公式料金ページを確認します。電話番号認証などは特に地域・料金・制限の最新情報を確認してください。
セキュリティ
クライアント側で「ログイン済み」と表示するだけでアクセス制御を完結させない。
Firestore等ではSecurity Rulesを適切に設定する。
管理用秘密鍵やService Account JSONをWeb/モバイルアプリへ埋め込まない。
APIキーをprivate keyと同じものだと誤解せず、Firebase公式のAPI keyの扱いと各APIの制限を確認する。
本番ユーザーのメールアドレスやtokenを公開GitHubやテストデータへ保存しない。
安全に試す
最初はFirebase Consoleで検証用Projectを作り、公式のAuthentication導入手順を読み、テスト用ユーザーだけで動作確認します。
コードを書く前に次の3点を確認すると安全です。
どのSign-in providerを有効にするか。
認証後にアクセスさせるデータは何か。
Firestore等のSecurity Rulesは未認証ユーザーをどう扱うか。
成功条件は「ログイン画面が出る」だけではなく、ログイン後のユーザー識別とデータアクセス制御が意図通りになることです。1か所変えるなら、検証環境で認証済み/未認証の2状態を切り替え、アクセス結果が変わるか確認します。
Google公式情報
次に何をすればよい？
検証用Firebase Projectで利用したいSign-in providerを1種類だけ選び、公式Quickstartに沿ってテストユーザーで確認します。同時に、認証後に使うFirestore等のSecurity Rulesも設計してください。
Papanda TRY：ログイン状態をブラウザカードで見る
実credentialを使わず、signed-out→provider選択→signed-inという状態遷移をJavaScriptで再現します。Firebase Authenticationが「UIそのもの」ではなく認証backend/SDKを提供することを理解する教材にします。
結局どういうサービス？
Firebase Authenticationは、アプリの利用者が誰かを確認し、ユーザーごとの体験やデータアクセスにつなげる認証部品です。Cloud管理者向けIAMとは役割が違います。最初は検証Projectとテストユーザーで、認証前後のアクセス差まで確認するのが安全です。
