この記事について
Google API を使う新規サービスで、sensitive scope を使ったために Google OAuth 審査が必要になり、それを開発の最後に回した結果、リリース予定日の5日前にようやく承認が下りた——という失敗談です。
結果的には間に合いましたが、かなりギリギリでした。
こんな人に向けた記事です。
- これから Google API（特に GA4 など sensitive scope を含むもの）を使って、外部公開するサービスを作る人
- 「OAuth 審査なんて、実装が終わってから申請すればいいでしょ」と思っている人（過去の私です）
読み終わると、OAuth 審査をいつ・誰のタスクとして・何を揃えて進めるべきかが分かり、リリース直前の冷や汗を避けられます。
結論を先に書きます。
リリースに致命的な影響があり、かつ自分だけでは日程をコントロールできないものは、「作業タスク」ではなく「リリースリスク」として、開発初日に存在を確認しておくべきだった。
Google OAuth 審査は、まさにこれでした。
そもそも Google OAuth 審査とは
知っている人は読み飛ばしてください。ただ、当時の私は「言葉だけ知っていて、中身を見ていなかった」のが敗因だったので、ここから書きます。
Google API でユーザーのデータにアクセスするとき、OAuth でユーザーから許可をもらいます。アプリがどの範囲のデータに触りたいかを scope で指定し、その scope は機微度で 3 段階に分かれます。
| 分類 | 例 | 外部公開前の審査 |
|---|---|---|
| 非機密（non-sensitive） | メールアドレス、プロフィール | 原則不要 |
| sensitive scope | Analytics、Calendar など | 必要（ブランディング確認＋スコープ審査） |
| restricted scope | Gmail本文、Drive全体 など | 必要（上記＋第三者セキュリティ審査が要る場合も） |
今回のプロジェクトでは、GA4 のデータをアプリ内に表示するために読み取り用の scope を使っていました。
https://www.googleapis.com/auth/analytics.readonly
これが sensitive scope に該当したため、外部ユーザーに公開する前に Google OAuth 審査を通す必要がありました。
ここまでは、調べればすぐ分かります。問題は「いつ・誰のタスクとして」やるかでした。
何が起きたか（時系列）
公開予定日から逆算すると、こういう流れでした。
| 時期 | 起きたこと |
|---|---|
| 公開予定日の18日前 | Google の審査フォームを入力し始める。ここでサービスのホームページが必要だと初めて気づく |
| 15日前 | 急ぎで用意した簡易版ホームページで、ブランディングの自動確認を通す |
| 13日前 | data access の申請を提出、Google からの返信待ちに入る |
| 10日前 | Google から最初の返信。ホームページが簡易すぎること、ロゴ周りの表示崩れを指摘される |
| 9日前 | 制作担当に急ぎ対応してもらい、完成版ホームページを用意して再返信 |
| 5日前 | 承認メール |
正直、承認が来るまでは諦めかけていました。
- もし指摘がもう1つ来ていたら
- もしホームページ修正にもう少しかかっていたら
- もし返信待ちが数日伸びていたら
リリース予定日に間に合わなかった可能性は十分ありました。
敗因1：申請フォームに入って初めて、必要なものが具体化する
最初の私は、Google のドキュメントやサポートページを読んで「だいたいこういう流れね」と理解したつもりでした。
でも本当に見るべきだったのは、Google Cloud の実際の申請画面でした。フォームに入ると、必要なものが一気に具体化します。
- アプリ名
- アプリのロゴ
- サポートメール
- プライバシーポリシー
- サービスのホームページ（ログイン前に外部ユーザーが見られる紹介ページ）
- 承認済みドメイン
- 利用する scope の説明（なぜその scope が必要か）
- scope の使い方を示すデモ動画
- 指摘が来たときに対応する時間
見れば分かるものもありますが、見ないと分からないものほど、リリース直前に見つかると重い。 これが教訓その1です。
敗因2：ホームページは「自分でコードを書けば終わるタスク」ではなかった
特に大きかったのが、サービスのホームページです。
ここでいうホームページは、ログイン後のアプリ画面ではなく、ログインせずに外部ユーザーが見られるサービス紹介ページのこと。しかも、ただ存在すればいいわけではなく、アプリ名・ロゴ・サービス内容・プライバシーポリシーへのリンクが Google 側で確認できる状態である必要があります。
ここで詰まりました。私の会社では、この種の公開ページは開発チームではなく、広報・マーケに近い別チームの担当だったのです。
個人開発や小さなチームなら開発者が作ることもあると思います。あくまで「今回のうちの体制では」という話です。ただ、そのページが誰の担当で、どのスケジュールで動くのかを最初に確認しておくべきだった点は、体制を問わず共通の教訓だと思います。
つまり、これは「自分が残業すれば終わる」タスクではありませんでした。コードはできているのに、審査に必要なページが揃わない——この状態は自分の手元では解決できません。
敗因の本質：自分の作業量で前倒しできないものほど、最初に見るべきだった
コードの問題なら、よくない働き方ではありますが、最悪は自分の作業量である程度前に進められます。バグを直す、設定を変える、デプロイし直す——手元で動かせます。
でも、外部審査は違います。提出したら返信を待つしかない。指摘が来たら修正して再提出。内容によっては他部署に依頼が要る。作業時間を増やせば前倒しできる、という種類のタスクではありません。
だからこそ後半に置くべきではなかった。むしろ逆で、自分の作業量だけでは前倒しできないものほど、最初に確認すべきでした。これが教訓その2です。
「審査が通っていないだけ」では済まない
最初は「最悪、審査が少し遅れるだけでしょ」と思っていました。でも外部ユーザー向けのサービスでは、それでは済みません。
審査が通っていない状態では、OAuth 同意画面に「このアプリは Google で確認されていません」という警告が表示される可能性があります。さらに、利用できる外部ユーザー数に制限がかかる可能性もあります。
社内検証ならまだしも、商用サービスとして外に出すなら、これはかなり重い。ログイン直後に大きな警告が出れば、ユーザーは「このサービス大丈夫か？」と不安になります。
機能が動くかどうかと、ユーザーが安心して使えるかは別問題。 ここで、OAuth 審査は「設定作業」ではなく「リリース品質の一部」だと気づきました。これが教訓その3です。
一般化：開発タスクとリリースタスクは分けて管理する
今回の反省は OAuth 審査そのものより、もっと根っこにありました。開発タスクとリリースタスクを混同していたことです。
| 開発タスク | リリースタスク | |
|---|---|---|
| 目的 | プロダクトの機能を作る | 外部に出せる状態にする |
| 例 | API・画面・DB・認証・テスト・デプロイ | 外部審査・紹介ページ・プライバシーポリシー・ドメイン・デモ動画・他部署調整 |
| コントロール | 多くは自分の手元で進められる | 他者・外部審査・返信待ち・公開タイミングに依存しがち |
同じプロジェクトの中にありますが、性質がまったく違います。
リリースに致命的な影響があり、かつ自分だけでは日程をコントロールできないものは、「あとでやる作業」ではなく「最初にリスクを確認する対象」として扱う。 これが今回の一番の学びです。
次に同じことをやるなら：開発初日に見るチェックリスト
次に Google API を使うプロジェクトをやるなら、コードを書く前にこれを確認します。
- どの Google API / scope を使うか
- その scope は sensitive か restricted か（その scope は本当に最小限か）
- 外部公開前に OAuth 審査が必要か
- OAuth 同意画面・申請フォームで何を求められるか（実際に画面に入って確認する）
- サービス紹介ページは必要か／それは誰が作るのか
- ロゴ・アプリ名・プライバシーポリシーは揃うか
- デモ動画は誰が録画し、どこにアップするか
- 指摘が来たら誰が対応するか
- リリース予定日から逆算して、審査待ちの時間を確保できているか
全部を初日に終わらせる必要はありません。でも、初日に「存在を知っている」必要はありました。知らないリスクは、計画に入れられないからです。
まとめ
- Google OAuth 審査は、最後に申請する作業ではなかった。sensitive / restricted scope を使う可能性があるなら、開発初期に申請フォームを見に行くべきだった。
- 審査が通っていないと「確認されていません」警告やユーザー数制限が出るため、これはリリース品質の一部。
- より一般化すると——リリースに致命的な影響があり、自分だけでは日程をコントロールできないものは、作業タスクではなくリリースリスクとして扱う。
エンジニアはどうしてもコードの中の問題（API がつながらない、ビルドが落ちる）ばかり見てしまいます。でも商用サービスを外に出すとき、ブロッカーはコードの外にもあります。外部審査、他部署の制作物、ドメイン、プライバシーポリシー、デモ動画、返信待ち。そしてそういうものほど、自分の努力だけでは前倒しできない。
次に同じプロジェクトをやるなら、私はコードを書く前に、まず OAuth 同意画面と申請フォームを見に行きます。そこで初めて「何を作れば完成か」ではなく「何が揃わないとリリースできないか」が見えるからです。
補足・参考
この記事は OAuth 審査の完全な手順書ではありません。審査要件や画面仕様は変わるので、実際に申請する場合は必ず公式ドキュメントを確認してください。