結論
Broken Functionalityを理由とする審査落ちとは、提出したリリースがクラッシュした、強制終了した、フリーズした、またはその他の異常な動作をしたと、Googleの審査担当者が判断したことを意味します。Google自身が挙げる例は、インストールできないアプリ、インストールはできても読み込まれないアプリ、読み込まれても応答しないアプリです。これはリリースに対するポリシー上の判定であり、製品版へのアクセスの拒否ではありません。またGoogleは、審査落ちそのものはデベロッパーアカウントの評価に影響しないと述べています。Playが配信するビルドで問題を再現し、審査担当者がログイン情報（Sign-in details、旧称App access）でログインできることを確認し、影響を受けるすべてのトラックで修正してから、修正したリリースを審査に送信してください。再審査請求は、判定が誤りだったと示せる場合に限って行います。
2026年10月16日時点の情報です。このページのルールはすべて、その日にGoogle PlayのポリシーページとPlay Consoleヘルプで確認し、使用している箇所にリンクを付けています。以下で引用するデベロッパーの報告は、2026年にデベロッパーが目にした内容の証拠であり、Googleがそのアプリを診断した結果ではありません。また、原因のランキングを裏付ける公開データがないため、原因の順位付けはしていません。
この記事は、Broken Functionalityポリシーに基づくリリースの審査落ちを扱います。クローズドテストの後にGoogleが製品版へのアクセスを認めなかった場合や、追加のテストが必要だと言われた場合は、対処法の異なる別の判定です。代わりにGoogle Playで追加のテストが必要と言われたときの対処法とクローズドテストの申請が却下される理由をお読みください。
この記事の内容
Google PlayのBroken Functionalityとはどういう意味ですか？
GoogleのFunctionality, Content, and User Experience（機能、コンテンツ、ユーザーエクスペリエンス）ポリシーにある2つのセクションの1つです。もう一方のセクションであるLimited Functionality and Contentは、目的が乏しすぎるアプリを対象とします。Broken Functionalityは、提出された状態で動作しないアプリを対象とします。
クラッシュ、強制終了、フリーズ、その他の異常な動作をするアプリは許可されません。
Googleはこの一文の下に、よくある違反の例を3つ挙げています。インストールできないアプリ、インストールはできても読み込まれないアプリ、読み込まれても応答しないアプリです。これは確認すべき3つの場所と読み替えてください。ビルドをインストールできない、真っ白な画面や終わらない読み込み画面が表示される、操作をタップしても何も起きない。審査担当者がこのどれに当たっても、同じ通知が届く可能性があります。
古いヘルプのリンクやフォーラムのスレッドでは、今もMinimum Functionalityという名前を見かけることがあります。現在のポリシーのセクション名はLimited Functionality and Contentで、静的なテキストやPDFだけのアプリ、コンテンツが非常に少ないアプリ、何もしないように作られたアプリを対象とします。通知はどちらのセクションを挙げることもあり、対処法も異なるため、何かを変更する前に、通知がどちらを挙げているかを読んでください。
互いに混同されやすい4つの判定
| 判定 | 内容 | 最初にやること |
|---|---|---|
| Broken Functionality | 内容提出したリリースが、審査担当者の環境でクラッシュした、フリーズした、読み込まれなかった、または応答しなかった。 | 最初にやることPlayが配信するビルドで再現し、影響を受けるすべてのトラックで修正して、再提出する。 |
| Limited Functionality and Content | 内容アプリは動くが、アプリ固有の目的やコンテンツが少なすぎる。 | 最初にやること実質的な機能を追加する。バグ修正だけではこの判定には対応できません。 |
| ログイン情報がない、または機能しない | 内容審査担当者が、ログイン、会員登録、ペイウォール、ワンタイムコード、地域チェックを通過できなかった。 | 最初にやることApp content（アプリのコンテンツ）でログイン情報を更新し、その変更を審査に送信する。 |
| 製品版へのアクセスが許可されない | 内容クローズドテストの後、Googleがアプリには追加のテストが必要、または製品版の準備ができていないと判断した。 | 最初にやることコードレベルの通知がない別のプロセスです。追加のテストが必要な場合を参照してください。 |
何が壊れていたかを、Googleはどこで示していますか？
まず、措置の通知メールとPlay ConsoleのPolicy status（ポリシーステータス）ページを確認してください。この2つで、ポリシー名と対象のリリースがわかります。またGoogleによると、Policy statusには利用可能な追加情報も表示されます。スクリーンショット、端末の詳細、スタックトレースは約束されていないため、それを待たないでください。
Play Consoleを開き、アプリを選んでPolicy status（ポリシーステータス）ページを開きます。コードに手を付ける前に、4つのことを書き留めてください。挙げられたポリシーのセクション、審査されたバージョンコードとトラック、日付、添付された証拠です。メールとPlay Consoleの通知も確認してください。リリースがどのポリシーに違反したかをGoogleが述べるのは、そこだからです。
2026年の通知の実例
全員に同じ文面で届くBroken Functionalityのメールは存在せず、それを正確なテンプレートとして掲載しているページは推測で書いています。2026年に通知を公開したデベロッパーたちの報告では、詳しさにかなりの差があります。
- 「Broken Functionality: Unresponsive UI elements」（応答しないUI要素）という通知ラベル。2026年9月2日に、初回のデータ同期中にオフラインの再試行画面を表示するアプリのデベロッパーが投稿したものです（Play Consoleヘルプコミュニティ）。
- 「For example, your app does not open or load.」（例：アプリが開かない、または読み込まれない）という審査担当者の例。2026年6月に、タイトル画面は実際に読み込まれていたゲームのデベロッパーが引用したものです。投稿者は後に、Androidの戻るボタンでゲームを終了する方法を変えたあと、ゲームが公開されたと報告しています。
- 2026年8月にあるデベロッパーが、「Broken functionality」という2語だけで、ほかに何も書かれていなかったと説明した通知。
これらはデベロッパーが転載した抜粋であり、真正性が確認されたGoogleのメールではなく、それぞれが1件の事例にすぎません。届く可能性のある情報の詳しさの幅を示すものであって、あなたの通知に何が書かれるか、あなたのアプリがなぜ不合格になったかを示すものではありません。
通知の内容があいまいな場合
挙げられたポリシーは、診断ではなく再現すべき症状として扱ってください。次のセクションの5つのチェックは、それぞれが不具合の潜む別の場所を除外できるように並べています。
Broken Functionalityで審査落ちしたら、最初に何を確認すべきですか？
Googleが審査したリリースそのものに対して、5つのチェックを行います。並び順は、除外するのが簡単なものから難しいものへの順です。各原因の発生頻度を示す公開データはないため、頻度順ではありません。
5つのチェックを順番に
デバッグビルドではなく、Playが配信するビルドをインストールする
アプリを一度も実行したことのないGoogleアカウントでログインしたクリーンな端末に、テストトラックからインストールし、審査担当者と同じように開いてください。Google Playは配信するビルドにアプリ署名鍵で署名します（Play アプリ署名を使用する）。そのため、Googleログイン、Maps、パッケージ名とSHA-1で制限したAPIキーなど、証明書のフィンガープリントを確認するサービスは、デバッグビルドでは動いてもストア配信ビルドでは失敗することがあります。2025年には、あるデベロッパーが、リリース版でだけ起きる不具合の原因を、製品版のマニフェストにインターネット権限が抜けていたことだと突き止めています。
審査担当者が中に入れることを確認する
アプリの一部でも、ログイン、会員登録、位置情報、その他の制限の後ろにある場合、Googleはアクセスに必要な情報の提供を求めています。ログイン情報（Sign-in details、旧称App access）に、今日時点で有効で、どの国からでも、ワンタイムコードなしで使える認証情報が入っているか確認してください。詳しくは次のセクションで説明します。
自分のネットワークの外からバックエンドをテストする
審査担当者のネットワークからサーバーに接続できないと、ログイン画面やデータ画面は失敗します。2026年には、ログインコードのリクエストを誤ってブロックしていたファイアウォールのルールが原因だったと突き止めたデベロッパーや、ログイン画面に証明書の信頼エラーが表示されたと報告したデベロッパーがいます。モバイルデータと別のネットワークでテストし、サーバーが地域でトラフィックを制限している場合は別の国からもテストしてください。
見えている操作をすべてタップし、空の画面をすべて開く
すべてのボタンとリンクは、適切なコンテンツで応答する必要があります。Play ConsoleヘルプコミュニティにあるGoogle自身のBroken Functionalityのチェックリストには、「適切な免責事項やエラーメッセージのない、空のページや何も表示されないページがアプリにないことを確認してください」と書かれています。何もしないボタンを出荷するのではなく未完成の機能は取り除き、ストアの掲載情報でうたっている機能がビルドで実際にすべて動くことを確認してください。保存したアイテムがまだないなど、正当に空になるリストには、理由を説明する一文と次の操作を用意します。画面のどこかをタップして続行するなど、ナビゲーションが一般的でない場合は、初めてのユーザーでも見落とさない目に見える手がかりを加えてください。
起動、戻る操作、Playにすでにあるレポートを確認する
アプリをコールドスタートで開き、画面を回転させ、バックグラウンドに送ってから戻し、すべての画面で戻るボタンを押してください。次に、審査されたバージョンのリリース前レポートとAndroid Vitalsを読みます。そこに記録されたクラッシュは手に入る中で最も強い証拠です。一方で、問題のないレポートにも限界があり、それは2つ後のセクションで説明します。
Googleの審査担当者にログイン情報を伝えるには？
Play Consoleで、Policy and programs（ポリシーとプログラム）、App content（アプリのコンテンツ）、Sign-in details（ログイン情報）の順に進みます。このセクションは以前App accessと呼ばれていたため、古い記事や一部の翻訳版ヘルプページでは今もその名前が使われています。
アプリの全体または一部が、ログイン認証情報、ログイン情報、会員登録、位置情報、その他の認証方法によって制限されている場合は、アプリにアクセスするために必要なすべての情報を提供する必要があります。
手順を追加または更新する
- Play Consoleを開き、App content（アプリのコンテンツ）ページに移動します（Policy and programs > App content）。
- Sign-in details（ログイン情報）でStartを選択します。以前に手順を追加したことがある場合はManageを選択します。
- + Add new instructionsを選択し、アクセスに必要な情報を入力します。ワンタイムパスワード、多要素認証、3つ以上の入力欄があるログインなど、一般的でないものはAny other instructions欄に書いてください。
- 変更を保存します。手順は最大5セットまで追加できます。
- Publishing overview（公開の概要）に移動し、Changes ready to send for reviewの中から該当の変更を見つけてSend for review（審査に送信）を選択します。保存しただけでは何も提出されません。
有効なアクセスと見なされる条件
GoogleのPlay Consoleの要件は、「Google Playがアプリを審査するために必要な、有効なデモアカウント、ログイン情報、その他すべてのリソースを提供する」ことを求めています。Googleのログイン情報の要件は、その意味を次のように具体的に示しています。
- 有効で繰り返し使えるアカウントであること。1回限りの招待や、審査中に期限が切れる試用版ではいけません。
- ワンタイムコードや2段階認証を通過できる認証情報であること。審査担当者は、あなたが電話や受信トレイに送るコードを受け取れないためです。
- アプリが地域で制限している場合はどの場所からでも使えるアクセスであること。また、審査担当者が確認する必要のある有料機能や制限付き機能に、課金なしで完全にアクセスできること。
- 情報が英語で書かれ、常に最新に保たれていること。パスワードを変更したりテスト用アカウントを削除したりした場合は、その日のうちにログイン情報を更新してください。
- QRコードやバーコードなど、テキスト以外のものがログインに必要な場合は、その静的URLを生成してログイン情報に追加してください。ユーザー自身にPINを設定させるアプリや、ソーシャルログインを使うアプリでは、審査担当者がどうすれば通過できるかを手順の中で説明してください。
アクセス情報の不足と、ログインの不具合は別物です
通知がログイン情報（Sign-in details）を挙げている場合、アクセス情報を修正して審査に送信するまでは、コードをどう変えても役に立ちません。認証情報に問題がなく、ログインそのものが失敗した場合は、Broken Functionalityの問題であり、確認すべきは前述のバックエンドのチェックです。
自分の端末では動き、Googleからスクリーンショットも届いていない場合は？
その場合、失敗した環境はあなたの端末ではありません。何かを決める前に、ストア配信ビルドを使い、クリーンな端末と別のネットワークで再現を試み、Play Consoleがそのリリースについてすでに持っている2つのレポートを読んでください。
リリース前レポート
Test and release > Testing > Pre-launch report（リリース前レポート）にあります。Googleは、App BundleまたはAPK をアップロードすると、処理能力の範囲内で、テスト端末でアプリを実行して自動的に生成します。クロールが実際にどの画面まで到達したかを確認してください。ログイン画面で止まっていれば、アプリの残りの部分は一度も見ていません。Googleは知っておくべき制限も挙げています。「認証情報を自動的に入力できるのは、標準のAndroidウィジェットを使用しているAndroidアプリのみです。」（リリース前レポートを使用して問題を特定する）。問題のないレポートは証拠であって、合格ではありません。Googleは審査前チェックについても同じことを述べています。「すべての審査前チェックに合格しても、正式なアプリ審査プロセスに合格することが保証されるわけではありません」。
Android Vitals
Monitor and improve > Android vitals > Crashes and ANRs（クラッシュとANR）にあります。Googleがこのデータを収集するのは、使用状況と診断データの共有にオプトインしたユーザーからだけです（Android Vitalsで技術的な品質を監視する）。そのため、小規模なテスト中の新しいアプリでは何も表示されないこともあります。Vitalsのページが空でも、アプリが一度もクラッシュしなかったことの証明にはなりません。
実機を使う実在の人
クローズドテストは、一般公開の前にこの種の問題を見つけるためにあります。さまざまなスマートフォン、Androidバージョン、ネットワークを使うテスターは、審査担当者がたどり着く画面にたどり着き、そのフィードバックで不具合の場所がわかります。これは欠陥の発見と修正に役立ちますが、Googleがアプリを審査する方法を変えるものではありません。トラックそのものの基本が必要な場合は、Google Playのクローズドテストの仕組みをご覧ください。
修正して再提出すべきか、再審査請求すべきか？
不具合を再現できるか、もっともらしい原因が見つかった場合は、修正して再提出します。挙げられた指摘が誤りだという証拠がある場合は、再審査請求します。同じビルドを変更せずに再提出することは絶対に避けてください。Googleは、違反を修正するまで審査落ちしたアプリを再公開しないようデベロッパーに求めています。
修正、明確化、再審査請求のどれ？
通知とご自身のテストについて、3つの質問に答えてください。選んだ内容がこのページの外に送られることはありません。
質問に答えると、おすすめの対応が表示されます。不具合を再現できない場合は、3つ目の質問で決まります。
修正してから、すべてのトラックで再提出する
修正して再提出再現できる不具合があるのは、最も有利な状況です。修正し、ストア配信ビルドで修正をテストしてから、以下の再提出の手順に従い、ポリシーに準拠していないバンドルがどのトラックにも有効なまま残らないようにしてください。
判断する前にストア配信ビルドをテストする
まずテストデバッグビルドは、審査担当者が実行したものではありません。新しいアカウントを使ったクリーンな端末に、自分で管理していないネットワーク経由でテストトラックからインストールし、5つのチェックを行ってください。判断するのはその後です。
ログイン情報を修正してから、審査に送信する
アクセスの修正ワンタイムコードを回避できる、繰り返し使える認証情報で手順を更新して保存し、Publishing overview（公開の概要）から変更を審査に送信してください。Googleによると、これはポリシーサポートチームに連絡したり返答を待ったりせずに行えます。
修正だけでなく、目的を加える
作り直しLimited Functionality and Contentは、アプリがどれだけのことをするかに関する判定です。再提出の前に、アプリ固有の実質的な機能やコンテンツを追加してください。安定性の修正では、この指摘には対応できません。
仕様をはっきり伝えてから判断する
明確化オフライン画面、空の状態、一般的でないジェスチャーが意図したものであっても、審査担当者は壊れていると受け取ることがあります。目に見える手がかり、説明、次の操作を加えてください。証拠を添えて再審査請求することもできますが、画面をわかりやすくすれば、次の審査担当者の疑いもなくなります。
証拠を添えて再審査請求する
再審査請求ストア配信ビルドをクリーンな端末と別のネットワークでテストし、問題は見つかりませんでした。バージョンコード、端末とAndroidバージョン、正確な手順、通知が挙げている操作フローの画面録画を添えて、1回だけ再審査請求してください。
修正したリリースを再提出する
Googleの再提出の手順は、新しいバージョンコードをアップロードするだけではありません。
- メールと通知に書かれたポリシーを読み、ほかのポリシーに対してもアプリを確認してください。Googleは、さらなる違反があればさらなる措置につながる可能性があると警告しています。
- 製品版だけでなく、対象のバージョンを含むすべてのリリースの種類を更新します。オープンテスト、クローズドテスト、内部テストのトラックも含みます。
- 修正したApp Bundleをアップロードし、ポリシーに準拠していないものを無効にします。Googleは、無効にしないと再提出は失敗し、公開中のバージョンが削除される可能性があると警告しています。
- 影響を受ける各トラックで、Manage track（トラックを管理）とCreate new release（新しいリリースを作成）を選択し、修正したバンドルを追加し（または違反したバンドルを含む下書きを破棄し）、ポリシーに準拠していないバージョンがNot included（含まれていない）に表示されていることを確認します。
- 保存し、Review release（リリースのレビュー）を選択して、公開します。
その後、変更は処理待ちになります。Googleによると、「処理には数時間から最大7日間（例外的なケースではそれ以上）かかることがあります」（アプリの変更を審査、公開するタイミングを管理する）。
修正したのに、警告が残っている
修正したバージョンが公開されているのにPolicy statusに問題が表示されたままの場合は、警告に書かれたバージョンコードとトラックを、現在有効になっているものと比べてください。テストトラックに残ったポリシー非準拠のバンドルが、最初に除外すべき原因です。新しいバージョンを出しても、すべての措置の項目が自動的に解消されるわけではありません。すべて一致している場合は、バージョンコード、影響を受けるトラック、以前のケース番号があればそれを添えて、Play Consoleサポートに問い合わせてください。
判定に対して再審査請求する
Googleは、自らが誤りを犯し、アプリがポリシーに違反していないと判断した場合、アプリを復元します。再審査請求するには、措置の通知メールの指示に従うか、Googleの再審査請求フォームを使用してください。再審査請求は措置1件につき1回まで送信でき（ポリシー違反と再審査請求の管理）、Googleは中国語、英語、日本語、韓国語で再審査請求に回答します。Googleは再審査請求の回答期間を公表しておらず、デベロッパーの報告でも再審査請求への回答とその後のリリース審査が混在しているため、日付を当てにせずに計画してください。
再審査請求は、不満ではなく証拠として書いてください。審査されたバージョンコード、テストした端末とAndroidバージョン、正確な手順、通知が挙げている操作フローの画面録画、そして変更した点があればその内容です。
Broken Functionalityの審査落ちは、アカウントやクローズドテストに悪影響がありますか？
審査落ちそのものは、デベロッパーアカウントの評価に影響しません。ただし、審査落ちが繰り返されると停止につながることがあり、停止は違反警告（ストライク）として数えられるため、再提出の前に修正してください。審査落ちが実施中のクローズドテストにどう影響するかは、文書化されていません。
Googleの措置の手続きのページは、その違いを次のように説明しています。
- 「審査落ち（却下）は、Google Play デベロッパーアカウントの評価には影響しません。」
- 「既存のアプリのアップデートが却下された場合、アップデート前に公開されていたアプリのバージョンは引き続きGoogle Playで入手できます。」
- 「停止は、悪質なポリシー違反や複数のポリシー違反のほか、アプリの却下や削除が繰り返された結果として行われることがあります。」
Googleは、何回までの審査落ちなら安全かという数字を公表していません。同じ不具合のまま再提出することは、まさに3つ目の文が述べているパターンです。
14日間のクローズドテストはどうなる？
Googleのテスト要件は、2023年11月13日より後に作成された個人用デベロッパーアカウントに対し、製品版へのアクセスを申請する前に、12人以上のテスターが14日以上連続でオプトインしていることを求めています。クローズドテストのトラックのリリースがポリシーで審査落ちした場合に、その期間がリセットされるのか、一時停止するのか、維持されるのかについては述べておらず、どちらかを断言するフォーラムの主張は推測です。確認できるのは、テスターが利用できる承認済みのリリースがトラックにまだあるかどうかと、ダッシュボードに製品版へのアクセスについて何が表示されているかです。修正している間もテスターのオプトインを維持し、ダッシュボードの表示が変わった場合は、ご自身のケースについてPlay Consoleサポートに問い合わせてください。ルールそのものは14日間連続の意味で説明しています。
WebViewアプリやTWAアプリは、壊れているとして審査落ちしますか？
技術そのものが理由になることはありません。GoogleはAndroidアプリ向けにTrusted Web ActivityとWebViewの両方を文書化しており、このアーキテクチャを禁止するポリシーはありません。問われるのは、アプリが動作するか、十分な目的があるか、そしてウェブサイトをラップする権利があるかです。
主な目的が、ウェブサイトへのアフィリエイトトラフィックの誘導や、ウェブサイトの所有者や管理者の許可を得ずにウェブサイトのWebViewを提供することであるアプリは許可されません。
ウェブベースのアプリでも、Broken Functionalityのチェックはほかのアプリと同じです。クリーンインストールからアプリ内でサイトが読み込まれること、オフライン状態やエラー状態がその理由を説明すること、すべてのリンクがどこかにつながることが必要です。アプリの大半がウェブサイトを薄く表示するだけなら、より大きなリスクはLimited Functionality and Contentのセクションです。TWAからWebViewへ、またはその逆に切り替えるだけで審査落ちが解消されることは示されていません。
次の審査の前に、PrimeTestLabはどう役立ちますか？
私たちがあなたのコードを修正したり、Googleの判定を変えたりすることはできません。私たちが提供するのはテストの側面です。実機を使う実在の人が、あなたのクローズドテストを通じてアプリを使うので、上で挙げたような問題が、審査担当者に見つかる前にそのフィードバックに現れます。
PrimeTestLabは、Android 7～17にわたる実機を使う実在のテスター12人以上をご用意し、14日間すべてにわたってオプトインを維持します。テストは4～6時間で開始します。これまでに12,100+件のアプリで、120+か国のテスターによる管理型テストを実施してきました。
自分で行うテストか、管理型テストか
| 作業 | 自分で行う場合 | PrimeTestLabの場合 |
|---|---|---|
| テスター集め | 自分で行う場合友人、グループ、フォーラム。たいてい似たような端末 | PrimeTestLabの場合実機を使う実在のテスターを、あなたのアプリに割り当て |
| 端末とAndroidバージョンの幅 | 自分で行う場合協力者が持っている端末次第 | PrimeTestLabの場合Android 7～17にわたる端末 |
| 日々の利用とフィードバック | 自分で行う場合相手の善意次第 | PrimeTestLabの場合テスターがアプリを使い、壊れた箇所を報告 |
| 12人のオプトインを14日間維持 | 自分で行う場合離脱者を自分で追いかける | PrimeTestLabの場合離脱者は補充され、人数が維持される |
| コードと通知への対応 | 自分で行う場合あなた | PrimeTestLabの場合引き続きあなた。テスターが見つけた内容は私たちが報告 |
| Googleの判定 | 自分で行う場合Google | PrimeTestLabの場合引き続きGoogle。承認を約束できる人はいません |
PrimeTestLabのテストをすべて終えた後もGoogleが製品版へのアクセスを許可しなかった場合は、無料再テストまたは全額返金をお選びいただけます。詳しくは返金と無料再テストのポリシーをご覧ください。これはテスト要件に関するもので、コードに対するポリシー上の審査落ちは対象外です。プランは$19.99からで、チェックアウト時に別途サービス手数料5%（最低$1.50）がかかります。Googleの1回限りの登録料（US$25）は別途必要です。プランの比較は料金ページでご覧ください。
よくある質問
Google PlayのBroken Functionalityポリシーとは何ですか？
Google PlayのFunctionality, Content, and User Experience（機能、コンテンツ、ユーザーエクスペリエンス）ポリシーの1セクションです。Googleは、クラッシュ、強制終了、フリーズ、その他の異常な動作をするアプリを許可しておらず、よくある違反として、インストールできないアプリ、インストールはできても読み込まれないアプリ、読み込まれても応答しないアプリを挙げています。
Broken FunctionalityとMinimum Functionalityは同じですか？
いいえ。Minimum Functionalityは、Googleが現在Limited Functionality and Contentと呼んでいるものの旧称で、目的やコンテンツが少なすぎるアプリが対象です。Broken Functionalityは、提出された状態で動作しないアプリが対象です。どちらも同じポリシーの中にありますが、必要な対処法は異なります。
Google Playの審査用のデモ認証情報はどこに追加しますか？
Play Consoleで、Policy and programs（ポリシーとプログラム）、App content（アプリのコンテンツ）、Sign-in details（ログイン情報、旧称App access）の順に進みます。StartまたはManageを選択し、手順を追加して保存してから、Publishing overview（公開の概要）ページで変更を審査に送信します。認証情報は繰り返し使えるもので、電話に届くワンタイムコードに依存してはいけません。
審査落ちは、デベロッパーアカウントの違反警告（ストライク）として数えられますか？
Googleによると、審査落ちはデベロッパーアカウントの評価に影響しません。停止は違反警告として数えられ、Googleはアプリの却下や削除の繰り返しを停止の理由の1つに挙げているため、再提出の前に指摘された問題を修正してください。
修正したアプリを再提出した後、審査にはどのくらいかかりますか？
Googleによると、アプリの変更の処理には数時間から最大7日間、例外的なケースではそれ以上かかることがあります。これは修正したリリースの審査についてです。再審査請求の回答期間は、Googleは公表していません。
Broken Functionalityの審査落ちに対して再審査請求はできますか？
はい、判定が誤りだと考える場合はできます。措置の通知メールの指示に従うか、Googleの再審査請求フォームを使用してください。再審査請求は措置1件につき1回まで送信できるため、審査されたバージョンコード、テストした端末と手順、通知が挙げている操作フローの録画を含めてください。
Broken Functionalityの審査落ちで、14日間のクローズドテストはリセットされますか？
Googleはその点を文書化していません。Googleの要件は、製品版へのアクセスを申請する前に、12人以上のテスターが14日以上連続でオプトインしていることです。リリースを修正している間もテスターのオプトインを維持し、ダッシュボードを確認して、申請資格が変わった場合はPlay Consoleサポートに問い合わせてください。
自分の端末では動くのに、なぜアプリが審査落ちしたのですか？
あなたの端末が再現しているのは、1つのビルド、1つのアカウント、1組のデータ、1つのネットワークだけです。Playが配信するリリースを新しいアカウントでクリーンな端末にインストールし、コンテンツが空の状態とネットワークリクエストが失敗した状態をテストしてください。アプリ署名鍵で署名されたストア配信ビルドは、デバッグビルドが動く環境でも失敗することがあるため、審査担当者がインストールしたビルドをテストしてください。
アプリでGoogleログインやワンタイムコードを使っています。審査担当者には何を渡せばよいですか？
Googleは、繰り返し使え、どの場所からでも機能し、ワンタイムパスワードや2段階認証を回避できるログイン情報を求めています。有料機能も含めて、制限されたすべての機能にたどり着けるテスト用アカウントと手順を審査担当者に渡してください。そのうえで、提供した情報そのものを自分でテストしてください。一般ユーザーがコードを受け取る方法を説明するだけでは、有効なアクセスになりません。
Googleからスクリーンショットもクラッシュログも届きません。どうすればよいですか？
Policy statusと措置の通知メールで、対象のバージョンとGoogleが追加した詳細を確認してください。次に、提出したリリースで主要な操作の流れを再現し、自分で動画とログを記録します。Android Vitalsのページやリリース前レポートに問題がなくても、審査担当者の環境ですべての画面とバックエンドのリクエストが動作したことの証明にはなりません。
TWAアプリやWebViewアプリは自動的に審査落ちしますか？
いいえ。Googleはどちらの技術も文書化しており、それらを禁止するポリシーはありません。Googleが制限しているのは、所有者の許可なくウェブサイトをラップするアプリと、機能やコンテンツが少なすぎるアプリです。ログイン、ナビゲーション、ネットワークのエラーなど、実際の不具合を診断してください。ラッパーを一方から他方へ切り替えることは、文書化された解決策ではありません。
まとめ
まとめ
Broken Functionalityの審査落ちは、Googleが審査したリリースが動作しなかったことを示しています。クラッシュした、フリーズした、読み込まれなかった、または応答しなかった、ということです。通知がどのポリシーを挙げているかを読み、Playが配信するビルドで再現し、審査担当者がログイン情報（Sign-in details）でログインできることを確認し、自分のネットワークの外からバックエンドをテストし、すべての操作と空の画面がその状態を説明するようにしてください。影響を受けるすべてのトラックで修正し、修正したリリースを審査に送信します。再審査請求は、判定が誤りだった証拠がある場合に限って行います。審査落ちそのものは違反警告ではありませんが、修正しないまま再提出を繰り返すと、違反警告につながることがあります。
次の審査担当者より先に、実機を使う実在の人に壊れた画面を見つけてもらいたいなら、あなたがアプリを修正している間、PrimeTestLabがクローズドテストの側を担います。
Googleの公式ドキュメント
このページで変わる可能性があること
- Play Consoleの表示名は変わります。Sign-in details（ログイン情報）は最近までApp accessと呼ばれており、一部の翻訳版ヘルプページでは今も旧名称が使われています。
- 通知の文面はテンプレートとして公開されておらず、ケースによって異なります。ここに挙げた例よりも、ご自身に届いたメールとPolicy statusページを信頼してください。
- ポリシー上の審査落ちが実施中のクローズドテストにどう影響するかを、Googleは文書化していません。Googleがルールを公表した場合は、このページもそれに合わせて更新します。
情報源の確認日：2026年10月16日。