Play Console の「ポリシー ステータス」を6本分まとめて開いたのは、8月に入ってからでした。警告が出ているアプリと、何も出ていないアプリが混在していて、最初はどちらが正しい状態なのか分からなくなりました。
調べていくうちに、8月31日という一つの日付に、性質の違う条件が二重に重なっていることに気づきました。この二つを一つの締切として読んでしまうと、必要のない作業に時間を使うか、逆に手遅れになるかのどちらかになります。
8月31日に重なっている条件は、二つあります
Play Console ヘルプの記述を分解すると、次のようになります。
条件 対象 必要な target API 満たさないとどうなるか
提出の条件 新規アプリ/アプリ更新 36 (Android 16)以上そもそも提出できない
配信の条件 公開済みの既存アプリ 35 (Android 15)以上アプリより新しい OS の端末で、新規ユーザーに見つけてもらえなくなる
つまり、既に API 35 で公開しているアプリは、8月31日を過ぎてもストアから消えません。消えるのは「更新を出す道」のほうです。次のバージョンを出そうとした時点で、36 が要求されます。
私自身が最初に取り違えていたのはここでした。「8月31日までに 36 にしないとアプリが消える」という前提で焦っていたのですが、6本のうち配信そのものが危ういのは、35 に達していないものだけでした。危機の所在が変わると、優先順位も変わります。
なお Wear OS と Android Automotive OS は 35 以上、Android TV と Android XR は 34 以上と、フォームファクタごとに要求値が違います。ウォッチ向けのターゲットを持っている場合は、同じ数字で考えないほうが安全です。
延長フォームは、警告を受けたアプリにしか出てきません
延長申請について、実務上いちばん誤解しやすいのがこの点です。
Play Console ヘルプには、延長フォームは「ポリシーに準拠していないアプリのみ」がポリシー警告と通知を受け取り、その警告または問題の詳細ページから利用できる、と書かれています。アカウント全体に「延長申請」というボタンが常設されるわけではありません。
ここから、実務的には次の三つが導けます。
警告が出ていないアプリには、延長フォームは出てきません。 準拠しているので不要、というのが Google 側の整理です。準拠しているつもりで待っていると、いつまでもフォームは現れません
延長が守るのは「配信」であって「提出」ではありません。 延長を取っても、target API 36 未満のバンドルで更新を出せるようになるわけではありません。11月1日までの猶予は、あくまで全ユーザーへの配信を続けるためのものです
フォームの提供時期は Google 側の裁量です。 ヘルプには「今年後半に Play Console で利用できるようになる」と書かれており、現時点で開けるとは限りません
私はこの3番目を、計画の前提から外すことを勧めます。延長を前提に計画を立てると、フォームが開くまで自分の手番が来ません。フォームが出ないまま8月31日を迎える可能性を、計画に織り込んでおくべきだと考えています。
まず、更新を出す予定があるかどうかで仕分けます
条件が二つある以上、判断の入口も二つです。私は6本を次の順に仕分けました。
手順1: 各アプリの実効 target API を確認する
ソースの build.gradle や app.config.js に書いてある値ではなく、実際にストアに上がっているバンドルの値を見ます。Expo の場合、config plugin やライブラリ側の設定が最終的な値を書き換えていることがあり、リポジトリの記述と一致しない場合があります。この確認手順についてはRork のプロジェクトで targetSdkVersion 36 を通すまでに直した3か所 で扱っています。
手順2: 「今後6か月以内に更新を出すか」を決める
ここが実質的な分岐点です。バグ修正であれ機能追加であれ、更新を出す予定があるなら、36 への引き上げは避けられません。8月31日は関係なく、次のリリースの前提条件になります。
手順3: 分岐に応じて期限を割り当てる
現在の target 更新の予定 実質的な期限 やること
36 以上 あり/なし なし 対応不要
35 あり 次のリリースまで 36 へ引き上げる。8月31日に追われる必要はない
35 なし なし 配信は継続される。当面は放置してよい
34 以下 あり 8月31日 最優先。36 で提出し切る
34 以下 なし 8月31日(緩和可) 新規ユーザー向けの配信が制限される。延長申請の対象
6本のうち、本当に8月31日を締切として扱う必要があったのは、この表でいう4行目に当たるものだけでした。残りは「次のリリースまでに直す」で足りる、というのが仕分けの結論です。
提出の締切日は、段階公開のリードタイムから逆算します
「8月31日までに提出すればよい」と考えると、段階公開を使っている場合に足をすくわれます。
私は Android の壁紙アプリを更新するとき、5% → 25% → 50% → 100% の順で公開範囲を広げています。各段階で Crash-free users が 99.7% を下回らないこと、ANR が 0.20% 未満に収まっていることを確認してから次へ進みます。指標が安定するには最低でも1日、判断に迷う変化があればもう1日を見ます。
ここに審査待ちの時間が加わります。審査は数時間で終わることもあれば、数日かかることもあり、締切直前は混み合う想定でいるほうが安全です。
個人開発では、この種の逆算を毎回頭の中でやろうとして間違えます。私は小さな関数に落として、判断の前に必ず一度実行することにしています。
// 段階公開を完了させたい日から、バンドル提出の期限日を逆算する
// 実運用の前提: 各段階で指標を1日観察し、審査には余裕を持って3日を見込む
/**
* @param {string} targetDateIso 100% 到達を終えたい日 (例: "2026-08-31")
* @param {number[]} stages 段階公開の各段で観察する日数
* @param {number} reviewDays 審査に見込む日数
* @returns {{submitBy: string, totalDays: number}}
*/
function submissionDeadline ( targetDateIso , stages = [ 1 , 1 , 1 , 1 ], reviewDays = 3 ) {
const observationDays = stages. reduce (( sum , d ) => sum + d, 0 );
const totalDays = observationDays + reviewDays;
const target = new Date ( `${ targetDateIso }T00:00:00+09:00` );
const submit = new Date (target. getTime () - totalDays * 24 * 60 * 60 * 1000 );
// JST の日付文字列に戻す
const submitBy = new Intl. DateTimeFormat ( 'sv-SE' , {
timeZone: 'Asia/Tokyo' ,
}). format (submit);
return { submitBy, totalDays };
}
console. log ( submissionDeadline ( '2026-08-31' ));
// => { submitBy: '2026-08-24', totalDays: 7 }
// 慎重に見るアプリは観察日数を増やす
console. log ( submissionDeadline ( '2026-08-31' , [ 2 , 1 , 1 , 1 ], 4 ));
// => { submitBy: '2026-08-22', totalDays: 9 }
出力を見て、8月24日という日付に少し驚きました。締切の1週間前です。複数本を同時に走らせるなら、さらに前倒しになります。段階公開の観察日数は自分で決めた値なので、ここを詰めれば締切は後ろに動かせます。ただし観察を削るということは、クラッシュを抱えたまま100%へ進める確率を上げるということでもあります。
一つ補足しておくと、提出の要件は提出時点で判定されます。8月31日より前に 36 のバンドルを提出できていれば、段階公開が9月にまたがること自体は問題になりません。逆算が要るのは「引き上げ作業が間に合わなかったときに、次に何を捨てるか」を先に決めておくためです。
複数本を一覧で仕分けるスクリプト
6本を Play Console で1つずつ開くのは、確認のたびに数十分かかります。Google Play Developer API のトラック情報を使うと、公開中のバージョンを一覧にできます。
// 各アプリの production トラックにある versionCode を一覧する
// 事前に service account の JSON キーを用意し、
// Play Console 側で「リリースを管理」権限を付与しておきます
import { google } from 'googleapis' ;
const PACKAGES = [
'net.dolice.beautifulwallpapers' ,
'net.dolice.ukiyoe' ,
];
async function listProductionVersions () {
const auth = new google.auth. GoogleAuth ({
keyFile: process.env. PLAY_SERVICE_ACCOUNT_JSON , // 例: ./play-service-account.json
scopes: [ 'https://www.googleapis.com/auth/androidpublisher' ],
});
const publisher = google. androidpublisher ({ version: 'v3' , auth });
const rows = [];
for ( const packageName of PACKAGES ) {
// 編集セッションを開かないとトラック情報は読めません
const { data : edit } = await publisher.edits. insert ({ packageName });
try {
const { data } = await publisher.edits.tracks. get ({
packageName,
editId: edit.id,
track: 'production' ,
});
const active = (data.releases ?? []). filter (( r ) => r.status !== 'draft' );
for ( const release of active) {
rows. push ({
packageName,
status: release.status, // completed / inProgress など
fraction: release.userFraction ?? 1 , // 段階公開中なら 0.05 等
versionCodes: (release.versionCodes ?? []). join ( ',' ),
});
}
} finally {
// 編集セッションは必ず破棄する。放置すると次回の insert が競合します
await publisher.edits. delete ({ packageName, editId: edit.id });
}
}
console. table (rows);
}
listProductionVersions (). catch (( err ) => {
console. error ( '取得に失敗しました:' , err.message);
process.exitCode = 1 ;
});
finally で編集セッションを破棄している箇所は、実際に一度詰まった部分です。破棄を忘れたまま同じパッケージで edits.insert を繰り返すと、開きっぱなしのセッションが残ります。エラーメッセージからは原因が読み取りにくく、権限の問題かと疑って時間を使いました。
注意点として、この API が返すのは versionCode であって targetSdkVersion ではありません。target の実測値は手元のバンドルから確認する必要があります。それでも「どのアプリが段階公開の途中で止まっているか」「最後の更新はいつのバージョンか」が一覧になるだけで、仕分けの速度はかなり変わります。
更新を出さないという選択肢を、最初から外さないでください
個人開発で複数本を運用していると、すべてを最新に保ち続けることが目的化しがちです。今回の仕分けで、私が意識的に残したのはこの選択肢でした。
Play Console ヘルプによれば、既にインストールしているユーザーは影響を受けず、再インストールも従来どおり可能です。制限がかかるのは、アプリの target より新しい OS を載せた端末の、新規ユーザーだけです。
新規インストールが月に数十件しかないアプリで、36 への引き上げに数日かかるなら、その数日を別のアプリに使うほうが合理的な場面はあります。判断材料はクラッシュ率や収益ではなく、そのアプリの新規インストールが今どこから来ているか、です。この見方は新規インストールが止まる4か国を、6本のアプリの流入比率で確かめました で使った切り口と同じで、対象が国から OS バージョンに変わっただけとも言えます。
もちろん、更新を止めれば脆弱性の修正も止まります。永久に放置してよいという話ではありません。「今月やらない」と「やらない」を分けて考える、という意味です。
今日決めておくとよいこと
Rork や Expo で生成したプロジェクトは、テンプレート側の target がそのまま残っていることがあります。生成してすぐ提出する運用ほど、この値を見る習慣が抜けやすいと感じています。段階公開そのものの組み立て方はRork アプリの段階的リリース戦略 にまとめてあります。
まず手元のアプリを一つ選び、ストアに上がっているバンドルの実効 target を確認してみてください。そのうえで「次の更新をいつ出すか」を紙に書けば、8月31日が自分にとっての締切なのかどうかは、その場で決まります。
期限に追われる時期ほど、条件を分解するだけで肩の荷が下りることがあります。同じように6本を抱えている方の判断が、少しでも軽くなれば嬉しく思います。お読みいただきありがとうございました。