この記事について

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 審査の完全な手順書ではありません。審査要件や画面仕様は変わるので、実際に申請する場合は必ず公式ドキュメントを確認してください。