2026年7月9日、AppleはApp Store Connectの年齢レーティング質問票にソーシャルメディア機能の質問を追加しました。Appleの公式発表では、2026年9月から新規アプリ、アップデート、代替配信用の公証申請で回答が必要になると説明されています。

症状：アプリの分類名だけを見て「はい」「いいえ」を選び、提出直前に機能との不一致が見つかる。
最速の解決策：公開フィード、コメント、再投稿、推薦、検索など、UGCを広げる実機能を確認し、9月前に質問票、コード、提出記録を三重に確定させます。

対象になるチーム

2026年9月以降にiOS、iPadOS、macOSアプリを提出する独立開発者、プロダクト責任者、App Store運用担当者向けです。特に、コミュニティ、コメント、公開投稿、年齢制限を実装している場合は、単なるメタデータ更新として扱わないでください。

この記事は法律判断ではありません。Appleが公開している年齢レーティング、Time Allowances、Declared Age Range APIの仕様をもとに、製品機能と申告内容を照合するための運用手順です。

まず機能の実態を分類する

App Store 年齢レーティング質問票 2026では、アプリの主カテゴリを根拠に回答してはいけません。Appleは、ソーシャルメディア機能を「UGCをソーシャルフィードなどで再配布、拡散、交流する能力」と説明しています。年齢レーティングの定義では、いいね、コメント、リアクション、再投稿、検索、発見機能などが例として挙げられています。

次の3つに分けると、判断が速くなります。

  • 完全に機能がないケース
    端末内だけで動く計算ツール、単方向のコンテンツ閲覧、利用者ごとに分離された非公開ワークスペースです。公開投稿、コメント、共有、推薦がなければ、ソーシャルメディア機能とは別に判定します。
  • UGCはあるが、拡散機能が限定されるケース
    画像、文章、音声などのユーザー投稿を保存するだけで、他の利用者へ広く表示しない構成です。ただし、検索、公開プロフィール、一覧表示、管理者によるおすすめ掲載があると、単なる保存機能とは言い切れません。
  • 公開フィードや交流機能があるケース
    投稿が多数の利用者に表示され、コメント、いいね、返信、再投稿、推薦、検索によって見つかりやすくなる構成です。ここでは、アプリ名や「教育」「仕事」などの主カテゴリではなく、実際の情報の流れを根拠に申告します。

AppleのTime Allowancesにおける「Social Media」は、App Storeでアプリを見つけるための主カテゴリとは別の分類です。App Store Connectで「ソーシャル」以外を選んでいても、アプリ内にソーシャルメディア能力があれば、その機能を基準に確認します。

情報流のないアプリを切り分ける

純粋なツール型アプリでも、古い機能や段階的公開が残っていると回答を誤ります。申告前には、本番環境で次の場所を確認してください。

  • コメント欄、レビュー、公開返信が残っていないか
  • 投稿を全利用者へ表示する一覧やタイムラインがないか
  • 共有リンクから第三者の投稿を閲覧できないか
  • いいね、リアクション、保存数、閲覧数が表示されないか
  • 推薦アルゴリズムや管理者ピックアップが動いていないか
  • SDKやWebView経由で、旧版のコミュニティ機能が表示されないか
  • 地域、アカウント種別、Feature Flagによって機能範囲が変わらないか

ここでは、質問票の回答を先に決めないでください。まず「現在オンラインで有効な機能一覧」を保存します。画面キャプチャ、APIレスポンスの例、リリースノート、Feature Flagの設定、対象ビルド番号を一つの申告資料にまとめると、プロダクト担当者と審査対応担当者が同じ根拠を確認できます。

App Store Connectの年齢レーティングはアプリ情報として管理され、複数プラットフォームにまたがって適用されます。App情報の公式説明でも、年齢レーティングはアプリ単位で設定され、全プラットフォームに適用されるとされています。

UGCとソーシャル機能を分けて確認する

UGCとソーシャルメディア機能は同じ意味ではありません。ユーザーが文章や画像を作れるだけなら、まずUGCの有無を確認します。そこから他の利用者へ広く見せる、目立たせる、反応させる仕組みが加わると、ソーシャルメディア能力の判定が必要になります。

たとえば、次のようなケースです。

  • レビューを本人と運営だけが確認する
    公開範囲が限定され、他の利用者による反応や検索がなければ、公開ソーシャルフィードとは異なる可能性があります。
  • レビューを全員に公開し、役に立った順で並べる
    内容を広く配布し、ランキングや推薦で目立たせるため、ソーシャルメディア能力に該当し得ます。
  • コミュニティ投稿を検索でき、返信やリアクションができる
    UGCの発見と交流が組み合わさるため、質問票では「投稿があるか」だけでなく、投稿がどのように拡散されるかを確認します。
  • 投稿はあるが、本人の端末内だけで表示する
    他者への再配布、拡散、交流がなければ、同じ名前の機能でも判断は変わります。

ソーシャルメディア機能を含めると、iOS 27、iPadOS 27、macOS 27以降のTime Allowancesで、ソーシャルメディア分類に関係します。また、Appleは該当機能があるアプリの商品ページに新しいソーシャルメディアのコンテンツ表示が出ると説明しています。13歳未満に機能を無効化している場合の扱いも別途確認が必要です。Time Allowancesと質問追加の発表

13歳未満の機能ゲートを検証する

「13歳未満にはソーシャル機能を使わせない」を選ぶ場合、質問票の回答だけでは不十分です。アプリが年齢範囲を受け取り、その結果に応じて情報流、投稿共有、コメント、リアクションなどを止める必要があります。

Declared Age Range APIは正確な生年月日を取得するAPIではありません。利用者または保護者が申告した年齢範囲を受け取り、年齢に応じた体験を分けるための仕組みです。Appleの公式ドキュメントでは、com.apple.developer.declared-age-rangeエンタイトルメントを有効にして利用すると説明されています。Declared Age Range APIの公式仕様

最低限、次の分岐を実装テストしてください。

  • 13歳未満：公開フィード、コメント、投稿共有を表示しない
  • 13歳：境界値で機能が有効になるか確認する
  • 13歳から15歳：年齢範囲の上下限を正しく処理する
  • 16歳から17歳：保護者設定や地域条件による差を確認する
  • 年齢情報の共有拒否：安全側の既定値になるか確認する
  • 保護者の同意撤回：すでに開いている画面や保存済みセッションも制限されるか確認する

AppleのSandbox文書では、13歳未満、13歳から15歳、16歳から17歳、18歳以上などのテストケースが用意されています。APIが返す下限、上限、年齢範囲の申告状態を記録し、アプリ側の機能ゲート結果と並べて保存してください。Sandboxでの年齢保証テスト

複数プラットフォームと代替配信をそろえる

iPhone版ではソーシャル機能を閉じていても、iPad版やMac版で公開フィードを提供している場合があります。アプリの年齢レーティングはプラットフォーム単位ではなくアプリ単位で扱われるため、最も機能が少ない版を代表にしてはいけません。

確認対象はApp Store版だけではありません。Appleは2026年9月から、代替配信向けの公証申請でも質問への回答が必要になると案内しています。Web経由の配信、Mac向けの別ビルド、地域限定機能を含め、同じBundle IDやアプリ記録に紐づく機能差を洗い出してください。

たとえば、iOSでは公開投稿を無効にし、macOSではキーボード操作を理由に公開コミュニティを有効にしている場合、低機能側の回答をそのまま全体へ適用するのは危険です。製品、審査運用、開発の3担当で、配信先ごとの機能一覧を突き合わせてください。

FAQで提出判断を固定する

App Store年齢質問の対応時期

Appleの公開情報では、質問への回答は2026年7月9日から確認・入力でき、提出時の必須化は2026年9月からとされています。ただし、2026年8月14日時点で具体的な開始日は公開されていません。9月に新バージョンを出す予定なら、回答を保存した状態でリリース候補を作っておく方が安全です。

コメント機能とソーシャルメディア能力

コメント機能の名称だけで決めないでください。公開コメントが検索され、返信され、推薦され、他の利用者へ広がる構成なら、Appleのソーシャルメディアの定義に近づきます。反対に、本人と運営だけが確認する問い合わせ欄なら、公開情報流とは分けて整理できます。

13歳未満の情報流制限

13歳未満に情報流を見せない設計では、年齢範囲を判定した後に、画面表示だけでなくAPI、通知、ディープリンク、キャッシュ済み投稿も確認します。ログアウト後の再認証、アカウント切り替え、保護者の同意撤回も含め、制限が抜けないかを確認してください。

年齢レーティングと審査への影響

質問票の回答は、Appleが年齢レーティングを生成する材料です。回答とオンライン上の機能が食い違うと、商品ページの表示、Time Allowancesの分類、審査時の説明に不整合が出ます。現在のレーティングを維持できるかは、単に旧回答を引き継げるかではなく、最新機能と回答が一致しているかで判断します。

Declared Age Range APIの検証範囲

Sandboxでは年齢範囲と保護者状態を切り替え、各結果を再現できます。lowerBound、upperBound、ageRangeDeclarationを保存し、どの値でソーシャル機能を閉じたかを記録してください。macOSでも年齢範囲を取得できる一方、年齢保証が常に必要になるとは限らないため、プラットフォームごとの挙動を公式文書で確認します。

提出前の三重チェック

最後は、担当者の記憶ではなく、チェック項目として残します。

  • [ ] App Store Connectで新しい年齢レーティング質問に回答し、保存状態を確認した
  • [ ] 回答時点の対象ビルド番号、リリースノート、画面キャプチャを保存した
  • [ ] 公開フィード、コメント、返信、再投稿、推薦、検索の有無を本番設定で確認した
  • [ ] iOS、iPadOS、macOSで機能差を一覧化した
  • [ ] 13歳未満、境界年齢、年齢情報の共有拒否を実機またはSandboxで確認した
  • [ ] 保護者による同意撤回後に、既存セッションとディープリンクが制限されることを確認した
  • [ ] 年齢レーティングの表示と商品ページのメタデータを確認した
  • [ ] 代替配信用の公証申請に使うビルドでも、同じ機能条件を確認した
  • [ ] プロダクト責任者と開発責任者が、回答と実装の一致を記録した
  • [ ] 2026年9月の提出担当者、コード担当者、最終承認者を決めた

主力MacでベータOS、複数のXcode、Sandboxアカウントを切り替えると、署名設定、キーチェーン、テストデータが混ざります。専用のMacを用意する方法もありますが、短期の適合性確認だけなら、作業期間に合わせたクラウドMac環境の方が本番環境を汚しにくいケースがあります。

Macの選択肢を比較する場合は、まずMACCOMEのMac環境案内で利用形態を確認し、固定の検証機が必要ならMac miniのレンタル選択肢も候補に入れてください。地域や提供条件は、申込み前に最新情報を確認してください。

9月前に決める運用方針

この対応で重要なのは、質問票の入力作業を運用担当者だけに渡さないことです。プロダクト担当者は実際の情報流を確認し、開発担当者は年齢ゲートとSandbox結果を確認し、提出担当者はApp Store Connectの保存状態を確認します。

現在の方法が「運用担当者が分類名だけで回答する」「主力Macにベータ環境を直接入れる」「iOS版だけを確認してMac版を見ない」状態なら、機能差、環境汚染、証跡不足が弱点になります。2026年9月からの提出に備えるなら、質問票、コード、提出記録を別々に管理せず、一つのリリース判定にまとめてください。

主力Macを止めずにXcodeやSandboxを分離したい場合は、Macを使った隔離テスト環境の考え方を確認してから、専用機を長期運用するか、プロジェクト期間だけMACCOMEのMac環境を使うかを決めるのが現実的です。今回は質問票の回答だけでなく、提出時に説明できるテスト記録まで残すことが、最も早いリスク低減になります。

最後に、Appleの公開ページは9月の具体的な開始日や今後の仕様変更を更新する可能性があります。提出前にはApp Store Connectのリリースノート、年齢レーティング定義、Declared Age Range API、Sandbox文書を再確認してください。

最終更新：2026年8月14日。情報はApple Developer News、App Store Connectヘルプ、年齢レーティング定義、Declared Age Range APIおよびSandbox公式文書を確認しています。