Googleログインの実装方法｜OAuthクライアント作成・同意画面・One Tap導入まで【事業者向け】

Googleログインの実装とは、Google CloudでOAuthクライアントを作成し、自社サイトにGoogleアカウントでのログインを組み込むことです。本記事は、自社サイトにGoogleログインを導入する事業者・開発者向けに、設定の手順と公開までの確認事項を解説します。

ソーシャルログインの基本（仕組み・メリットとデメリット・選び方）はソーシャルログインとはで解説しています。

利用者としてのGoogleログインの仕組みはGoogleログインとは、会員の識別や名寄せなど設計でつまずきやすい点はGoogleログインの実装とつまずきやすい5つの箇所で解説しています。

結論：設定は4段階。公開前に「テスト」から「本番環境」へ切り替える

Googleログインの設定は、Google Cloudの管理画面「Google Auth Platform」で行います。作業は次の4段階です。

Googleの管理画面は名称や配置が変わることがあります。作業の直前に公式ドキュメントで最新の手順を確認してください。

段階1：プロジェクトを作り、同意画面を設定する

Google Cloudでプロジェクトを作成し、Google Auth Platformで同意画面の情報を登録します。同意画面は、利用者が初めてログインするときに「どのアプリに、どの情報を渡すか」を示す画面です。

• ブランディング……アプリ名、ロゴ、サポート用メール、ホームページ・プライバシーポリシー・利用規約のURL、承認済みドメイン
• 対象……ユーザーの種類（外部／内部）と公開ステータス、テストユーザー
• データアクセス……アプリが求めるスコープ（取得する情報の範囲）

ユーザーの種類：一般向けサイトは「外部」

「内部」は、自社のGoogle Workspace組織に所属するアカウントだけに利用を限る設定です。一般の利用者が使う会員サイトでは「外部」を選びます。

公開ステータス：「テスト」のままでは一般公開できない

作成直後は「テスト」の状態で、ログインできるのは登録したテストユーザー（最大100人）だけです。テスト中の許可は同意から7日で失効します。公開前に「アプリを公開」で「本番環境」へ切り替えてください。

審査：ログインだけなら重い審査は不要

ログインに使う基本的なスコープ（openid・email・profile）は、機密性の低いスコープに分類されます。これだけを使う場合、アプリの審査（確認）は必須ではありません。

ただし、同意画面にアプリ名とロゴを表示するには、「ブランドの確認」という簡易な確認を受ける必要があります。ホームページやプライバシーポリシーが公開されていること、登録したドメインを所有していることなどが確認されるため、サイトの公開ページを先に用意しておくと手戻りがありません。

Googleカレンダーなど他のサービスのデータを使うスコープを追加すると、より厳しい審査の対象になります。ログインが目的なら、必要最小限のスコープに留めてください。

段階2：OAuthクライアントを作成する

Google Auth Platformの「クライアント」で「クライアントを作成」を選び、種類に「ウェブ アプリケーション」を指定します。登録する項目は次の2つです。

作成するとクライアントIDが発行されます。サーバー側で認可コードを使う方式ではクライアントシークレットも使います。

2025年6月以降に作成したクライアントでは、クライアントシークレットは作成時にしか表示・ダウンロードできません。その場で安全な場所に保管してください。また、6か月間使われていないクライアントは自動的に削除されます。検証用のクライアントを放置していると、使おうとしたときに消えていることがあります。

取得できる情報

ログインが成功すると、Googleが署名したIDトークン（JWT）を受け取ります。主な項目は次のとおりです。

Googleも、識別にはメールアドレスではなくsubを使うよう明記しています。取得できる情報と使い方の詳細はソーシャルログインで取得できる情報も参照してください。

段階3：Google Identity Servicesで組み込む

ウェブサイトへの組み込みには、Googleが提供するJavaScriptのライブラリGoogle Identity Servicesを使います。主な表示方法は次の3つです。

設置は、HTMLに専用の属性を書く方法と、JavaScriptで初期化して表示する方法があります。どちらも、ログインが成功するとIDトークンがJavaScriptの関数か、指定した自社のログイン用URLに渡されます。

受け取ったIDトークンは、必ずサーバー側で検証します。確認するのは次の4点です。

1. Googleの公開鍵で署名が正しいか
2. aud（宛先）が自社のクライアントIDと一致するか
3. iss（発行元）がGoogleか
4. exp（有効期限）が切れていないか

多くの言語でGoogleが検証用のライブラリを提供しています。自前で書くより、これを使うほうが安全です。

ブラウザの変化への対応（FedCM）

ブラウザのサードパーティCookie制限に合わせ、Google Identity ServicesはFedCMというブラウザ標準の仕組みへの移行を進めています。新規に実装する場合は、公式ガイドに沿ってFedCMを有効にしておくと、後からの改修を減らせます。FedCMを有効にすると、One Tapの表示状態を判定する一部の関数が使えなくなるなど挙動が変わるため、移行ガイドで変更点を確認してください。

段階4：テストと公開

注意点

• ボタンの見た目……Googleのブランドガイドラインに沿ったボタンを使う。独自のデザインに作り替えない
• スコープは最小限に……ログインに不要な情報を求めると、審査が重くなり、同意画面で離脱も起きやすくなる
• 管理者アカウント……Google Cloudのプロジェクトは、担当者個人ではなく会社で管理するアカウントで作る。退職で設定を変更できなくなる事故を防げる
• 既存会員との紐づけ……メールアドレスの一致だけで自動的に統合しない（ソーシャルログインのアカウント統合）

Google以外のSNSも合わせて導入する場合の手順と期間は、ソーシャルログインの導入手順と期間で解説しています。

よくある質問

Googleログインの導入に費用はかかりますか？

Googleログインの仕組み自体に、Googleへの利用料はかかりません。費用になるのは、自社で実装・保守する開発の工数か、ログインの仕組みを外部のサービスで用意する場合の利用料です。

審査にはどれくらいかかりますか？

ログインに必要な基本的なスコープだけなら、重い審査は必須ではありません。同意画面にアプリ名とロゴを出すためのブランドの確認は、公開ページの準備が整っていればスムーズに進みやすくなります。期間は案件によって違うため、公開日から逆算して早めに申請してください。

One Tapとログインボタンは両方入れるべきですか？

役割が違うため、併用が一般的です。ログイン画面にはボタンを置き、記事ページなどログイン画面以外にOne Tapを出すと、ログインの機会を増やせます。

スマホアプリでも同じ設定を使えますか？

使えません。iOSやAndroidのアプリでは、アプリの種類ごとに別のOAuthクライアントを作成し、各OS向けの方法で実装します。アプリに埋め込んだWebViewの中でGoogleのログイン画面を開く方式は、Googleのポリシーで認められていません。

Login Plus について

Login Plusは、Googleを含む6つのソーシャルログイン（Apple・Facebook・Google・X（旧Twitter）・Yahoo! JAPAN・LINE）とパスキーに1つの実装で対応できるサービスです。

• Google One Tapに対応
• 各SNSへの申請手順書を契約企業に無償で提供
• 各SNSの仕様変更にはLogin Plus側で対応
• 取得した情報をフォームへ自動入力するフォームアシスト機能
• 導入はプロバイダ申請から約2か月でリリース（導入の流れ）

Googleログインを含むソーシャルログインの導入のご相談は、資料請求またはお問い合わせからどうぞ。