Google Play ターゲットAPI 36 の期限：2026年8月31日に変わること

Google は Play ストアのターゲットAPIの下限を年に一度引き上げており、2026年は API 36 の周期です。分かりにくいのは数字ではありません。「ターゲットAPIレベルの要件」という1つの名前の下に、実は2つのルールが同居していることが分かりにくさの正体です。片方は何をアップロードできるかを決め、もう片方はそれより低い基準で、すでに公開されているアプリを誰がインストールできるかを決めます。この疑問で上位に出るページのほとんどが両者を混ぜてしまっており、その結果、作り直す必要のなかったアプリを作り直したり、本当は重要だった Play Console の警告を見過ごしたりすることになります。

この記事では2つを切り分け、端末タイプごとの数字を示し、そのうえで8月になると実際に当社の問い合わせ窓口へ届く質問に答えます。テスター12人が14日間連続で参加するクローズドテスト（closed testing）が半ばまで進んだアプリはどうなるのか、という質問です。PrimeTestLab はデベロッパーに代わってそのテスト側を担っているため、この日程の衝突を日常的に見ています。当該セクションの内容は、サービスを使う場合でも自分でテスターを集める場合でも同じように当てはまります。以下の日付とレベルはすべて2026年8月9日に Google 自身のページで確認しており、Google が実際には文書化していない事柄は、それらしい推測で埋めずにその旨を明示しています。

1文で分かるルール

2026年8月31日から、一般的なスマートフォン、タブレット、折りたたみ端末、Android Auto 向けのアプリを Google Play に提出するには、Android 16、API レベル 36 以上をターゲットにする必要があります。まったく新しいアプリでも、公開済みアプリの更新でも同じです。この1文でほとんどの読者の状況は説明できます。例外と、手を加えないアプリに適用される別のより低い基準が、この記事の残りのテーマです。

名前は1つ、ルールは2つ

Google は「ターゲットAPIレベルの要件」という表現を、まったく挙動の違う2つのものに使っています。この2つを分けて理解しておくことが、このページでできる最も価値のあることです。

つまり、更新の予定がないまま API 35 で静かに動いているアプリは、ルール2の観点では8月31日時点で要件を満たしており、何かをリリースしようとした瞬間にルール1の観点で要件を満たさなくなります。これは矛盾ではなく設計です。Google はストアに残るものの基準よりも、ストアに新しく入るものの基準を速く引き上げています。

Google が正確に定義している3つの言葉

このポリシーは3つの用語に依存しており、それぞれの意味が、あなたがどちらのルールの下にいるかを決めます。

• 新規アプリ：「まだ Google Play で公開されていない」アプリです。あるパッケージ名の最初のアップロードを指します。
• 既存アプリ：すでに Google Play で公開されているアプリです。
• アプリの更新：現在のバージョンを置き換えるために審査へ提出する、既存アプリの新しいバージョンです。更新は掲載のルールではなく提出のルールで判断されます。

端末タイプ別の要件

「Android アプリ」は1行では表せません。スマートフォン、タブレット、折りたたみ端末、Android Auto はAPI 36まで上がります。Wear OS と Android Automotive OS はAPI 35で止まります。Android TV と Android XR はAPI 34で止まります。更新しないアプリの基準はさらに低く、下の切り替えで2つの組を行き来できます。

Android Auto は Android Automotive OS ではありません

この2つの名前は毎年、開発者の時間を実際に奪っています。Android Auto はスマートフォンのアプリを車載画面に映すもので、アプリ自体はスマートフォン向けアプリなのでスマートフォンのルール、つまり API 36 に従います。Android Automotive OS は車両そのもので動く OS で、ターゲットが低い例外として名指しされている1つです。こちらは API 35 です。メディアや地図のアプリを両方に出す場合は、高いほうが必要になります。

自分のアプリは対象？ 3つの質問に答えてください

8月31日があなたの問題かどうかは3つで決まります。これから何をするのか、どの端末タイプ向けに公開しているのか、そして現在のビルドが実際に何をターゲットにしているのかです。下のツールは Google が公開している基準をその組み合わせに当てはめ、2つのルールのどちらの下にいるかを示します。

判定に問題なしと出た場合でも、最後の期限前チェックリストには目を通してください。「ソースではターゲット 36 になっている」と「Google が評価した成果物が 36 を宣言している」は別の主張だからです。この周期でいちばんよくある思い込みは、アップロードしたバンドルではなく Gradle ファイルを読んで安心してしまうことです。

8月31日に間に合わないと実際に起きること

どちらのルールの下にいるかで結果は2つに分かれます。基準を下回るビルドをアップロードしようとすると、その提出は要件を満たしません。公開済みのアプリを掲載基準より下のままそのままにしておくと、そのアプリがターゲットとするより新しい Android バージョンを搭載した端末の新規ユーザーからは検索とインストールができなくなります。どちらも削除ではありません。

アップロードしようとした場合

この結果が何にひも付いているかに注目してください。アップロードという行為です。カレンダーだけでは、すでに公開されているビルドには何も起きません。だからこそ、9月1日には何の問題もなかったアプリが、バグ修正をリリースすると決めただけで9月2日にはブロックされる、ということが起こります。

公開済みアプリを基準より下のまま置いた場合

競合ページが「アプリが消える」と書いている部分ですが、重要な点で誤りです。Google の表現は、アプリが特定のユーザー層から「検索されなくなる」というものです。具体的には次のとおりです。

• より新しい端末の新規ユーザーは利用できなくなります。ユーザーの端末がアプリのターゲットより高い Android バージョンを実行している場合、Google Play はそのユーザーにアプリを表示せず、インストールもしません。
• より古い端末の新規ユーザーには影響ありません。アプリのターゲットと同じか、それより低い API レベルの端末であれば、引き続きアプリを受け取れます。
• すでにインストールしたユーザーには影響ありません。一度インストールした人は、対応する Android バージョンであれば引き続き検索、再インストール、利用ができます。
• ディープリンクは事実を伝えます。条件に合わないより新しい端末で Play ストアのリンクを開いたユーザーには、このアプリが「古いバージョンの Android 向けに作られている」旨が表示されます。

起きないこと

毎年8月になると、このポリシーは Google のサポートフォーラムで同じ4つの不安を生みます。そのどれも、ターゲットAPIレベルのページが説明している内容ではありません。

API 36 をターゲットにすると古い端末のサポートは切れますか

それだけで切れることはありません。targetSdk はアプリがどの Android 動作レベル向けに作られ、テストされたかを宣言します。minSdk はアプリをインストールできる最も古い Android バージョンを決めます。2つは別々の数字で、ターゲットを 36 に上げても最小値がつられて上がることはありません。コードと更新した依存関係の互換性が保てる限り、アプリはその最小値までの古い Android バージョンを引き続きサポートできます。

周期ごとに最も大きな不安を生むのがこの誤解です。開発者が「Android 16 をターゲットにする必要がある」を読み、「Android 16 でしか動かない」という意味だと受け取り、Google が自分のリーチできる端末の大半を消し去ったと結論づけてしまいます。下で最小値を動かして、実際に何が変わるのかご確認ください。

3つの数字と、Google Play が見ているもの

いまアプリがクローズドテスト中の場合

新しい個人用デベロッパーアカウントでテスター12人、14日間連続の必須クローズドテストを回している場合、期限はその期間のちょうど真ん中に落ちてきます。安全な進め方は、8月31日より前に API 36 のビルドを同じクローズドトラックへ入れておき、すべてのテスターをオプトインの状態に保ち、期限のせいでトラックを変えたりテスターを集め直したりしなくて済むようにすることです。

Google のターゲットAPIのページと Google のクローズドテストのページは、別々のチームが別々の目的で書いた文書であり、どちらも相手側に触れていません。そこに本当の空白が生まれるので、正直なやり方は、文書化されている領域がどこで終わるのかを正確にお見せすることです。

確認できること

• 該当する新しい個人アカウントは、製品版へのアクセスを申請する前に、14日以上連続でオプトインしているテスター12人以上を対象にクローズドテストを実施する必要があります。これは2023年11月13日以降に作成した個人アカウントに適用されます。確認済み
• Google のデベロッパー向けドキュメントは、アップロードされた APK が Play のターゲットAPI要件を満たす必要があるとしており、テストトラックの例外は公開していません。この記述はテスト専用ではなくトラックを問わない書き方なので、期限後にクローズドトラックへ新しくアップロードするビルドは API 36 が必要だという前提で計画してください。これは強い推論であって、テストトラックについて文書化されたルールではありません。一部確認
• Google 自身の案内は、問題を修正しながらクローズドテスト中のアプリを更新し続けることを勧めており、対象期間を固定された1つの成果物ではなくテスターのオプトインの継続を基準に定義しています。確認済み
• 内部テストは上限がテスター100人で、資格要件を満たすクローズドテストの代わりにはなりません。確認済み

Google が文書化していないこと

答えが分からない以上、正しい戦略は答えを当てにいくことではありません。期限より前に要件を満たすビルドをトラックに置いておき、その問い自体を意味のないものにすることです。どちらの結果になっても安全ですし、古い成果物がそのまま動き続けたとしても損はありません。

どちらに転んでも安全な手順

1. 同じクローズドトラックと同じテスターグループを維持する

   API 36 のビルドのために新しいトラックを作らず、オプトイン中のテスターを外さないでください。Google が数える14日間の継続はテスターがオプトインを保っているかどうかの話なので、守るべき資産はその参加名簿です。

2. API 36 は期限当日ではなく、その前にビルドしてテストする

   移行を独立した作業として扱い、専用のテスト工程を用意してください。画面端まで広がるレイアウトの崩れを8月30日に見つける日と、8月10日に見つける日はまるで違います。

3. 既存のクローズドトラックへ versionCode を上げてアップロードする

   既存のバンドルを置き換えるバンドルは、必ず versionCode を上げる必要があります。Google は対象期間をテスターのオプトインの継続を基準に定義し、テスト中も問題を修正し続けることを明示的に勧めていますが、あらゆるビルド差し替えの状況を網羅する絶対的な保証は公開していません。同じトラックと同じオプトイン中のテスターを保ち、アップロード後に Play Console のカウンターを確認してください。今回が最初の周期なら、テスト中の更新の仕組み全体を読んでおく価値があります。

4. リリースが実際にテスターへ届いたか確認する

   公開されたリリースと届いたリリースは同じではありません。クローズドのリリースが実際に配信中か、versionCode が上がっているか、オプトイン名簿のテスターが更新を見られるかを確認してください。

5. 処理完了後にポリシーの状況を再確認する

   バンドルの処理に時間を置いてから、アプリのポリシーの状況ページをもう一度開いてください。ターゲットAPIの警告が残っている場合は、手当たり次第にリリースを削除するのではなく切り分けリストを進めてください。

6. 移行が本当に間に合わないときだけ期限延長を申請する

   延長は2026年11月1日までの時間を確保するもので、影響を受けるアプリごとに申請します。技術作業を止める理由にはなりません。

2026年11月1日までの期限延長を申請する方法

影響を受けるデベロッパーは、2026年11月1日まで配信を維持できる期限延長を申請できます。申請はアプリごとで、そのアプリの Play Console のポリシー警告から始めます。Google はこれを自動、保証付き、恒久的な免除とは説明していないため、申請中も移行は進めてください。

Google Play Console · 実際のスクリーンショット クリックで拡大

1. Play Console で対象のアプリを開く

   期限延長はアカウント単位ではなくアプリ単位です。複数のアプリを公開している場合は、影響を受けるアプリごとにこの手順を繰り返すことになります。

   確認済み
2. ポリシーの状況へ移動する

   Google が要件未達と判断したアプリにだけターゲットAPIの問題が表示されます。すでに要件を満たしているアプリには、延長する対象も見つけるべきフォームもありません。

   確認済み
3. ターゲットAPIの警告または問題の詳細を開く

   上のスクリーンショットに写っている問題のタイトルは App must target Android 16 (API level 36) or higher です。文言はアプリごと、また展開の段階によって変わる可能性があるため、保証された共通の文字列ではなく、実際のアカウント1件で確認された表示として受け取ってください。

   確認済み
4. 問題の画面または通知にある期限延長のリンクをたどる

   Google は影響を受けるデベロッパーの一部を、問題のパネルではなくアプリの通知経由で誘導します。選択肢がないと判断する前に、両方をご確認ください。

   確認済み
5. 求められた情報を送信する

   Google は公開ヘルプページに正確な質問項目を掲載していないため、どこかで見かけた「こう聞かれる」という一覧は未確認の情報として扱ってください。実際の移行計画に基づいてお答えいただければ十分です。

   一部確認
6. 2026年11月1日を最終期限として扱う

   期限延長は日付を動かすだけで、要件をなくすものではありません。8月31日までに終わらなかった作業は、11月1日までには終わっている必要があります。

   確認済み
7. 申請中も移行を進める

   Google の表現のどこにも承認を約束する箇所はありません。まだ受け取っていない期限延長を前提に計画を立てることが、この周期で最も高くつく思い込みです。

   一部確認

もう1点、覚えておくと役に立つ区別があります。Google は期限延長の注記を API 36 の要件に付けており、本文ではたいてい延長を既存アプリの配信を保つ仕組みとして説明しています。新規アプリ、更新、既存アプリのすべての組み合わせを同じ精度で説明しているわけではありません。予定している特定のアップロードまで延長がカバーすると考える前に、ご自身のアプリの警告が何をカバーすると書いているかをお読みください。

アプリを API 36 に上げる手順

手順は4つです。API 36 の SDK を入れ、compileSdk と targetSdk を 36 に上げ、その過程で壊れる依存関係を更新し、Android 16 の動作変更をテストします。数字を変えるのは1行の修正です。アプリが問題なく動くと示すことが本当の移行作業です。

手順1：Android 16 の SDK を入れる

Android Studio を開き、SDK Manager から API レベル 36 用の Android SDK Platform を、現行の 36.x.x ビルドツールと一緒にインストールしてください。プラットフォームが入っていないと、compileSdk を上げたときに、自分のした作業とは無関係に見えるビルドエラーが出るだけになります。

手順2：ビルドでレベルを上げる

ご自身のスタックを選んでください。ファイルのパスと具体的な行は違っても、目的地は同じです。アップロードするバンドルの中のマニフェストがターゲット 36 を宣言していることです。

android {
    compileSdk = 36

    defaultConfig {
        applicationId = "com.example.app"
        minSdk = 24
        targetSdk = 36
        versionCode = 2
        versionName = "1.0.1"
    }
}

android {
    compileSdk 36

    defaultConfig {
        applicationId "com.example.app"
        minSdkVersion 24
        targetSdkVersion 36
        versionCode 2
        versionName "1.0.1"
    }
}

android {
    compileSdk = flutter.compileSdkVersion
    compileSdk = 36

    defaultConfig {
        targetSdk = flutter.targetSdkVersion
        targetSdk = 36
    }
}

buildscript {
    ext {
        buildToolsVersion = "36.0.0"
        minSdkVersion = 24
        compileSdkVersion = 36
        targetSdkVersion = 36
    }
}

ext {
    minSdkVersion = 24
    compileSdkVersion = 36
    targetSdkVersion = 36
}

手順3：依存関係とフレームワークのツールを更新する

コンパイルレベルを上げると、古い依存関係が壊れます。Android Gradle Plugin、Gradle 本体、Kotlin、AndroidX のライブラリ、Google Play services、そしてネイティブコードを含む広告や分析の SDK にまで手が及ぶとお考えください。この記事はあえて「正しいバージョン」を書きません。互換のあるバージョンは毎週変わり、ここに固定した一覧は2週間もすれば読者を誤らせるからです。移行するその日に、ご自身のフレームワークの最新リリースノートから取ってください。

手順4：ビルド、アップロード、成果物の確認

• 署名済みの Android App Bundle を生成し、versionCode を上げてください。
• デバッグビルドではなくリリースの成果物をテストしてください。コード圧縮とリソース圧縮は、デバッグビルドが隠していた問題を表に出します。
• 目的のトラックにアップロードし、その成果物がターゲットAPIレベル 36 を報告することを Play Console で確認してください。
• 処理が終わったら、有効なトラックをすべて見直し、ポリシーの状況を開き直してください。

API 36 をリリースする前にテストする Android 16 の動作

API 36 をターゲットにすると、Android 16 の端末でアプリに Android 16 の動作が有効になります。優先度の高い項目は、画面端まで広げるレイアウト、予測型「戻る」、大画面での向きの自由度、健康関連の権限、固定間隔のスケジューリング、テキストレイアウトです。下で当てはまるものを選ぶと、一般論ではなくご自身のアプリ向けのテスト一覧が出ます。

画面端まで広げるレイアウトと予測型「戻る」：影響範囲が最も広い2つ

画面端まで広げるレイアウトは、アプリが特殊な API を使っていなくても引っかかるため影響範囲が広くなります。Android 16 では、API 36 をターゲットにするアプリは従来の除外用の属性を使えなくなるので、システムバーが場所を空けてくれる前提だったコンテンツがその下に潜り込みます。症状は見た目の問題に見えますが、主要なボタンがジェスチャーバーの下に隠れてタップできなくなった瞬間から実害になります。

予測型「戻る」も同じくらい影響範囲が広い項目です。アプリが従来方式の「戻る」処理を登録している場合、ターゲット 36 で予測型「戻る」が既定で有効になったあと、その経路が以前どおりには呼ばれない可能性があります。モーダル、WebView、未保存の入力があるフォーム、終了直前の最後の画面まで、あらゆる階層から「戻る」をテストしてください。

ターゲット 36 の共通の破壊要因ではないもの

16 KB ページサイズの要件はどうなりますか

別の要件、別の日付、同じアプリ群です。ターゲットAPIの期限は、マニフェストが宣言するレベルの話です。16 KB ページサイズの要件は、ネイティブライブラリがメモリページ 16 KB の端末で動作するかどうかの話です。Google の現行の案内は、16 KB に対応していない対象アプリの更新をリリースできなくなる日付として2027年2月1日を示しています。

• 対象：Google の要件は、64ビットの Google Play 対象端末で API 35 以上をターゲットにするアプリに適用されます。そのうち、ネイティブの .so ライブラリを直接または SDK 経由で同梱しているアプリが、明示的なリビルドとアライメントの作業を要する可能性が高い側です。アプリが Kotlin や Java だけで書かれているなら概ねすでに互換ですが、決めつけずにテストしておく価値はあります。
• そうではないもの：2026年8月31日のターゲットAPI期限の一部ではなく、片方を満たしたからといってもう片方を満たすわけでもありません。
• 同時に来る理由：今月ターゲットレベルを上げる人はどのみちリビルドすることになり、そのときにページサイズの問題が表面化します。この時期の重なりが、2つを混同させる原因です。

アプリがネイティブライブラリを同梱している場合は、ページサイズの確認を API 36 のビルドに土壇場で押し込むのではなく、専用のテスト工程を持つ独立した作業として扱ってください。2つの変更はビルドの別々の部分に触れており、両方を同時にデバッグすることこそ、1週間の移行が3週間になる道筋です。

API 36 をアップロードしたのに警告が残っています

たいていは3つのどれかです。バンドルの処理がまだ終わっておらずポリシーの状況が更新されていない、より古い成果物が別の有効なトラックに残っている、あるいはプロジェクトは 36 でもアップロードした成果物が実際には 36 を宣言していない、のいずれかです。順に見ていってください。リリースの削除から始めてはいけません。

いま開発者が報告している問題のタイトルは Your app must target Android 16 (API level 36) or higher で、Play Console の画面どおり英語です。Google はすべてのアップロード経路について標準のエラー文言の全文を公開したことがないため、ネット上で見つかる正確な文言は、これも含めて公式ではなく観測された事例として扱ってください。

ある習慣を1つ持つだけで、この種の問題はほぼ恒久的に片付きます。アップロードのたびに、Play Console の成果物からターゲットAPIレベルを読み返し、versionCode の隣に書き留めておくことです。10秒で済み、「直したはずなのに」という種類の問題がまるごと1週間から消えます。

期限前チェックリスト

実際に起きる順で14項目です。最後の4つが飛ばされやすく、そして警告が消えるかどうかを決めるのもその4つです。

この期限で PrimeTestLab が担う範囲

境界をはっきりさせておきます。当社はお客様のコードを移行しません。targetSdk を上げ、依存関係を更新し、Android 16 の動作変更を直す作業はお客様のビルドの領域で、この記事がその部分に対する当社の貢献のすべてです。当社が担うのは衝突しているもう半分、新しい個人アカウントが製品版にたどり着くために必要な実機の実際のテスター12人による14日間連続のオプトインです。

問題は時期が重なることです。2026年8月に初めて公開する人は、互いに無関係な難しい作業を同じ期間に2つ求められます。API 36 のビルドを出すことと、資格要件を満たすクローズドテストを2週間続けることです。ビルドは解ける技術課題です。実在する12人を集め、実機で14日間オプトインの状態に保つことのほうが、静かに1か月を食いつぶす側です。

クローズドテストを自分でやる場合と任せる場合

今月の進め方の順番

2つの課題を同時に抱えている場合は、順番にではなく並行で進めてください。クローズドテストは今すぐ始めてください。その14日間は圧縮できないカレンダー上の時間だからです。そして API 36 の移行はその横で進めます。準備ができたら、要件を満たすビルドを同じクローズドトラックへ、versionCode を上げ、同じテスターがオプトインしたままの状態で入れてください。そうすれば、期限とテスト期間が同じ2週間を奪い合わずに済みます。

よくある質問

まとめ

2026年8月9日時点のポリシーのスナップショットです。Google はこれらのページを予告なく変更するため、日付を根拠に何かを決める前に、上の一次情報をご確認ください。この記事は8月31日の直後と2026年11月1日以降に、あらためて確認する予定です。