8月に Play Console のポリシー ステータスを一通り見直したとき、「延長」という言葉を、私は少し甘く受け取っておりました。期限が後ろへ伸びたのだから、更新もそのぶん後ろでよい、と。
今日が10月24日で、延長期限の11月1日まで8日です。8日あれば足りそうに見えますが、数え方を一つ間違えると、期限の日に更新を出しても間に合いません。そこで、期限日ではなく「提出の最終日」から逆に数える方法を書き残します。
11月1日に、何が決まる日なのか
Google Play のヘルプには、新しいアプリと更新は8月31日までに Android 16（API レベル 36）を対象にする必要がある、と書かれています。あわせて、更新に時間が必要な場合は11月1日までの延長を申請できる、とあります。
ここで読み違えやすいのが、延長の中身です。延長されるのは「いまのアプリを、これまでどおり全ユーザーに配り続けられる期間」であり、その後に更新を出すときは API 36 以上が必須になります。
一方、更新を出さないアプリは、API 35 以上であれば新規ユーザーに出続けます。API 35 を下回ると、新しい Android を載せた端末の新規ユーザーには出なくなります。すでに入れている方は、そのまま使えます。
期限の日付は一つでも、数えるべき日付は「更新を出す日」のほうです。
提出の最終日は、期限の10日ほど前になります
更新を出してから皆さまの端末に届くまでには、三つの時間が挟まります。審査、段階公開、そして差し戻しが1回あった場合の余裕です。
| 区間 | 私の仮置き | 置き換え方 |
|---|---|---|
| 審査 | 3日 | 自分の直近の更新で、提出から承認までにかかった日数 |
| 段階公開 | 4日 | 100% にするまでに自分が置く日数 |
| 余裕 | 2日 | 差し戻し1回ぶん |
この仮置きだと、合計は9日です。11月1日から9日戻すと10月23日になります。つまり今日の時点で、すでに1日過ぎていることになります。
数字は人によって違います。自分の数字に置き換えるために、日数計算を短いスクリプトにしました。手元の Python 3 で動かして確かめております。
#!/usr/bin/env python3
"""延長期限から逆算して、更新を出す最終日を日付で出す。"""
import sys
from datetime import date, timedelta
DEADLINE = date(2026, 11, 1) # 延長期限（Play ヘルプの記載）
REVIEW_DAYS = 3 # 審査の見込み。自分の過去実績に置き換える
ROLLOUT_DAYS = 4 # 段階公開で 100% にするまでの日数
BUFFER_DAYS = 2 # 差し戻し1回ぶんの余裕
def back_calc(today: date) -> None:
left = (DEADLINE - today).days
submit_by = DEADLINE - timedelta(days=REVIEW_DAYS + ROLLOUT_DAYS + BUFFER_DAYS)
print(f"期限まであと {left} 日")
print(f"審査 {REVIEW_DAYS} 日 + 公開 {ROLLOUT_DAYS} 日 + 余裕 {BUFFER_DAYS} 日 → 提出の最終日 {submit_by}")
if today > submit_by:
print(f"提出の最終日を {(today - submit_by).days} 日過ぎています。段階公開の日数を見直すか、更新の中身を絞るか、先に決めてください。")
else:
print(f"提出まで {(submit_by - today).days} 日あります。")
if __name__ == "__main__":
back_calc(date.fromisoformat(sys.argv[1]) if len(sys.argv) > 1 else date.today())python3 deadline_backcalc.py 2026-10-24 と打つと、「期限まであと 8 日」「提出の最終日 2026-10-23」「1 日過ぎています」と出ます。日付を 2026-10-20 に変えると「提出まで 3 日あります」に変わります。
段階公開の日数は、短くしてよい場合と、短くしたくない場合があります。クラッシュが出たら止められる余地を残すのが段階公開の目的ですので、日数だけを削る前に、何を守りたいのかを先に決めておくのがよいと思います。
8日しかないときに、確かめる3点
数え直した結果、間に合いそうにないと分かったときは、慌てて提出する前に次の3点を順に確かめます。
- そのアプリは、延長の対象か。 ヘルプには、延長を申請できるのは警告や通知を受けた対象のアプリだと読める記述があります。Play Console のポリシー ステータスで、自分のアプリに警告が出ているかを見ます。社内向けの非公開アプリは、そもそも対象外とされています。
- 更新を出す必要が本当にあるか。 機能追加の予定がないアプリなら、API 35 を保ったまま更新を出さない選択肢も残ります。この場合に失うのは、新しい端末の新規ユーザーです。既存のユーザーには影響しないとヘルプに書かれています。
- API 36 に上げるとき、どこを直す必要があるか。 上げた直後に出やすい挙動の違いは、別の記事に実機で見た箇所をまとめました。target API 36 を通すまでに直した3か所 に書いています。
3点とも、判断の材料はアプリごとに違います。壁紙アプリのように更新が少ないものと、広告や課金に触れるものを同じ順番で扱わないことが、私の線引きです。
数える前に、アプリごとの状態を一行ずつ書き出します
複数のアプリを運用していると、どれが「延長を待っている」状態で、どれが「すでに API 36 を通した」状態なのか、頭の中では混ざってしまいます。私は日数を計算する前に、アプリごとに次の3つだけをメモに書き出します。
- いまの targetSdkVersion（Play Console の警告の有無もあわせて）
- 次に更新を出す予定の日と、その更新の中身
- 延長を申請したか、しなくてよいと判断したか
この3つが埋まらないアプリは、日数を数える段階にまだ来ておりません。逆に、更新の予定がないアプリは、メモの時点で「出さない」と決まるものがほとんどでした。8日という残りは、全部のアプリに使う時間ではなく、更新が必要なアプリだけに使う時間なのだと思います。
確認できていないこと
ヘルプの記載では、延長の申請フォームは「今年の後半に」Play Console へ提供される、とありました。私が読んだ時点では、フォームそのものの画面は確認できておりません。画面の名前や場所は、ご自身の Play Console でお確かめください。
また、審査の日数は公式に保証された数字ではありません。この記事の「3日」は私の仮置きで、実績に置き換えて使う前提です。
今日やることは、1つです
まず、自分のアプリの「提出の最終日」を、スクリプトで日付にしてみてください。その日付が今日より後なら、そのまま進めます。過ぎていたら、上の3点の順に確かめます。
提出の最終日だけは、毎回、期限日より先に手帳へ書いておくようにしています。