コンテストに出すために、提出要件をまとめたドキュメントを自分で作りました。要件を1つずつ書き出して、対応状況を並べた、ごく普通の管理表です。

そこに誤りが3件ありました。

そして、その資料を信じて判断していたので、間違いに気づいたのは一次情報（公式ルール）を直接読んだときでした。

誤り1: 別のアプリの設計が混入していた

資料にはこう書いてありました。

案A（無料トライアル）: 既にプレミアムに3日間のトライアルを設定済み

これを前提に、「審査員は無料でプレミアムを試せる」と整理していました。

設定されていませんでした。

根拠として引かれていたのは、別のアプリ（行列予測アプリ）の課金設計でした。3本を並行で作っていたので、資料を書くときに混ざったのです。

確認方法は2つあって、どちらも数分でした。

# 1. コードを検索する
grep -rniE "トライアル|trial|introductory|無料期間" lib/
# → 0件。ペイウォールにトライアル表示のロジックすら無い

2つ目はPlay Consoleの画面です。定期購入の商品一覧で、「特典」欄が – になっていました。 Playの現行モデルでは、無料トライアルは「特典（offer）」として基本プランに紐づけます。特典が空＝トライアル未設定で確定です。月額・年額の両方で確認しました。

「設定済み」と書いてある資料を読む時間で、実物を見れば終わっていました。

誤り2と3: 動画の尺と、スクリーンショットの解像度

同じ資料に、あと2件ありました。

  • 動画の尺の記載が、実際の要件と違っていた
  • スクリーンショットの解像度が 1179×2556 と書かれていた

2つ目は、iPhone 15 Proの解像度です。Google Playの規定は「長辺は短辺の2倍を超えないこと」なので、2556 ÷ 1179 = 2.168 で規定違反。App Storeの要件と取り違えたまま、指示書に残っていました。

3件のうち2件は、他のプラットフォーム・他のアプリのものが混ざった誤りです。 複数のプロジェクトを並行で回していると、この種の混入が起きます。

そして本命: 誰も日付を見ていなかった

いちばん重かったのはこれです。

審査員に配るプロモコードは、既に発行済みでした。数量2,000、有効期限は2026年9月30日まで。「準備済み」として管理表のチェックが埋まっていました。

公式ルールを直接読みに行って、こう書いてありました。

Judging Period:
  Thursday, October 1, 2026 – Tuesday, October 13, 2026

審査期間は10/1から。コードの終了日は9/30。重なる日が1日もありません。

コードは存在していて、数量も足りていて、正しく公開されていて、そして絶対に使えませんでした。

ついでに分かった、もっと重要なこと

同じ公式ルールを読んでいて、もう2つ発見がありました。

1つ目。要件の原文はこうです。

the app must either offer a free trial or the Entrant must include a promo code for judges to unlock the in-app purchase and test all premium features

「トライアルまたはプロモコード」。どちらか片方でよい。自作の資料では、両方を用意する前提の書き方になっていました。

2つ目。これが効きました。

Judges are not required to test the Project and may choose to judge based solely on the text description, images, and video provided in the Submission.

審査員は、アプリを触らない選択もできます。 説明文・画像・動画だけで判断してもよい、と明記されている。

アクセス手段の提供は必須要件なので用意はします。ただし、優先順位が変わりました。 「審査員が試せるように」課金バグを直すのではなく、「本番公開して実ユーザーに課金させる以上、直すのは当然」という位置づけに変える。そしてデモ動画と説明文の完成度に時間を割く。

要件を満たすことと、評価されることは別の作業でした。

なぜ気づけなかったか

理由ははっきりしています。資料が、実物と同じ見た目をしていたからです。

管理表には要件が並び、対応状況の欄が埋まり、根拠へのリンクも張ってある。よくできた資料ほど、実物を見に行く動機が消えます。 「調べた結果がここにある」という前提で読むので、調べ直す発想が出てこない。

しかも、この資料を書いたのは自分たちです。外部の情報なら疑うのに、自分で作った要約は疑いませんでした。

決めたこと

要件の判断は、必ず一次情報に当たる。 社内資料は「どこを見るか」の索引としてだけ使う。

具体的には、資料の各行に出典URLと確認日を書くようにしました。

- 動画は2分以内 （出典: https://... / 確認日 2026-08-15）

確認日が古い行は、その行を根拠に判断してはいけないという合図になります。

そして、「済み」のチェックには日付を含める。 「プロモコード発行済み」ではなく「プロモコード発行済み（有効期間 8/17〜2027/1/31）」。期間を書く欄があれば、審査期間と突き合わせる動機が生まれます。

教訓

要約は、要約された時点の理解でしか正しくありません。

自分の資料が間違っていたことより怖かったのは、それが正しいかを確かめる仕組みが無かったことです。3件の誤りは、どれも数分で検証できるものでした。検証していなかったのは、検証する必要があると誰も思わなかったからです。

いま自分の管理表には、「確認日」の列があります。

同じく「確認していれば数分で終わった」系の話として、審査員がアプリを開けなかった件と規約ページが全部404になっていた件を書いています。ストア公開でつまずく箇所は全部まとめてあります。