App Store の新しい年齢別レーティングに答え直す — 複数アプリで実際に変わった項目とつまずき

ある朝、いつものように軽微な修正をまとめてアップデートを申請しようとしたところ、App Store Connect の画面が先へ進みませんでした。「年齢別レーティングの質問に回答してください」という案内が、運用中のアプリすべてに一斉に出ていたのです。

締め切りは 2026 年 1 月 31 日。回答を終えるまで、以降のアップデートは提出できない仕組みでした。壁紙という穏やかなジャンルのアプリでも例外ではありません。個人開発で複数のアプリを並行して運用している身としては、地味ですが避けて通れない関門でした。

そのとき実際に手を動かして気づいたことを、順を追って書き残しておきます。Rork や Rork Max で公開したアプリでも通る道ですので、これから初めてストアに出す方の下調べにもなれば幸いです。

まず変わったのはレーティングの区分そのもの

これまでの 4+ / 9+ / 12+ / 17+ という区分が見直され、より細かい段階に置き換わりました。12+ と 17+ が姿を消し、代わりに 13+・16+・18+ が加わっています。

見落としやすいのは、既存アプリのレーティングが自動で再判定され、こちらが何もしないうちにストア表示が変わっていた点です。私の場合、以前 4+ だったアプリが 4+ のまま残っていたものもあれば、再判定を挟むまで表示が保留になっていたものもありました。申請前に、各アプリの現在のレーティングをストアと App Store Connect の両方で見比べておくことをおすすめします。

増えたのは4つの質問カテゴリ

今回の更新の中心は、区分の名前ではなく、質問の中身が増えたことです。すべてのアプリに対して、次の4カテゴリの新しい設問が必須になりました。

穏やかな内容のアプリでも、油断すると評価が上がってしまうのは「機能（Capabilities）」の欄でした。ここでは、アプリが持つ機能のうちユーザー生成コンテンツや外部ウェブの表示、そして AI アシスタントやチャット機能が、どのくらいの頻度でセンシティブな内容に触れうるかを申告します。

たとえば設定画面から利用規約のウェブページを開くだけの実装でも、「ウェブコンテンツを表示する」に広めに答えると、想定より高い区分に寄ることがあります。実際に触れうる範囲を、機能単位で一つずつ確認する必要がありました。

Apple は、AI アシスタントやチャット機能を含むすべての機能が、センシティブな内容の出現頻度にどう影響するかを開発者自身が考慮するよう求めています。生成 AI をアプリに組み込む場面が増えている今、ここは以前より丁寧に答えるべき項目になったと感じます。

「最低年齢を自分で引き上げられる」新しい余地

今回の更新で加わったもう一つの要素が、Apple が算出したレーティングよりも高い最低年齢を、開発者側で設定できるようになったことです。

これは、アプリの規約が Apple の判定より高い年齢を要件にしている場合に使います。質問へ回答したあと、App Store Connect の「App 情報」からより高い区分を選べます。

私自身は壁紙アプリで引き上げる必要はありませんでしたが、コミュニティ機能や課金前提のサービスを持つアプリでは、規約と表示レーティングを一致させる意味で有効な選択肢だと思います。

アプリ内のコントロールは「実装」で裏づける

「アプリ内のコントロール」や「機能」の回答は、口頭の宣言ではなく、実際の実装と揃っている必要があります。ユーザー生成コンテンツを扱うなら、通報・ブロックといった保護の仕組みを備えたうえで、その旨を回答するのが筋です。

Rork や Rork Max で作ったアプリでも考え方は同じです。React Native / Expo で最小限の通報導線を用意するなら、次のような形が出発点になります。

// 投稿を通報・ブロックする最小の導線
// 「アプリ内のコントロールがある」と回答する場合の裏づけになる
import { useState } from "react";
import { Alert } from "react-native";
 
async function reportContent(itemId: string, reason: string) {
  const res = await fetch("https://YOUR_API_HOST/api/reports", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ itemId, reason, at: new Date().toISOString() }),
  });
  if (!res.ok) throw new Error("report_failed");
}
 
export function useModeration() {
  const [blocked, setBlocked] = useState<string[]>([]);
 
  async function onReport(itemId: string) {
    try {
      await reportContent(itemId, "inappropriate");
      Alert.alert("受け付けました", "24時間以内に確認いたします。");
    } catch {
      Alert.alert("送信に失敗しました", "時間をおいて再度お試しください。");
    }
  }
 
  function onBlock(userId: string) {
    setBlocked((prev) => (prev.includes(userId) ? prev : [...prev, userId]));
  }
 
  return { blocked, onReport, onBlock };
}

大切なのは、機能の宣言と実装が一致していることです。通報導線がないのに「コントロールあり」と答えると、審査で齟齬が生まれます。逆に、備えているのに申告し忘れると、本来より高い区分になりかねません。

なお、ユーザーの年齢を扱う場合は、誕生日を集めずに年齢帯だけを受け取る Declared Age Range API が別に用意されています。レーティングの申告とユーザー側の年齢確認は目的が異なりますので、混同しないよう切り分けておくと整理しやすくなります。

私が実際にたどった手順

複数アプリを一つずつ確認したときの流れを、そのまま残しておきます。

一本ずつ進めると、同じ構成のアプリでも回答が微妙に違うことに気づきます。ウェブ表示の有無、外部リンクの数、課金の種類。細部の違いが、そのまま最終的な区分に効いてきました。

気づいたこと

作業を終えて残ったのは、「レーティングは一度きりの設定ではなく、機能が増えるたびに見直す運用対象になった」という手応えです。

AI チャットやユーザー投稿のような機能を後から足したとき、レーティングへの影響を意識するかどうかで、審査での摩擦がだいぶ変わります。機能を追加する PR のチェックリストに、「レーティング設問への影響」を一行加えておくと、次回の申請がずいぶん楽になりました。

次に新しいアプリを出すときは、公開直前ではなく、機能を設計する段階でこの4カテゴリを見返すつもりです。小さな下準備ですが、締め切り直前に慌てずに済む効き目がありました。実装の参考になれば幸いです。お読みいただき、ありがとうございました。