App Storeのソーシャルメディア申告項目と、その代償

App Store Connect APIにある2つのBoolean値が、9月から始まる提出要件のすべてを背負っています。socialMediaとsocialMediaAgeRestrictedです。¹ 後者を選ぶと、entitlementの追加、APIの導入、そしてアプリ内の挙動の分岐という代償が生じます。

Appleがこの要件を発表したのは2026年6月8日でした。「2026年9月より、App Storeへの新バージョンやアップデートの提出、および代替アプリマーケットプレイスでの配信に向けた公証（Notarization）にあたっては、アプリまたはゲームにソーシャルメディア機能が含まれるかどうかを申告することが必須となります」² そして7月9日、Appleは質問票の変更を実際に反映し、それまでの数週間の使い方を左右する一文を添えました。「本日より、これらの質問を確認して回答できます」³

TL;DR

• 申告項目はApp Store Connectで現在すでに利用可能で、2026年9月に必須化されます。つまり「回答できる」時点と「必須になる」時点の差は、締め切りに追われるためではなく、判断を固めるために使える猶予です。²³
• Appleは「ソーシャルメディア機能」を4か所で定義していますが、そのうち3つと1つで範囲が食い違います。6月版はフィードを「多数のユーザーへ可視的にコンテンツを広める」ものに限定していますが、7月版はこの限定句を丸ごと落としています。²³⁴
• App Store Connect APIは、この回答を書き込み可能な2つのBoolean値として公開しつつ、userGeneratedContentとmessagingAndChatを別々の質問・別々のレーティング下限として維持しています。ソーシャルメディアは名称変更ではなく、新しい軸なのです。¹⁴
• 13歳未満のソーシャルメディア区分から外れるには、条件が1つではなく3つあります。Appleのニュース記事はDeclared Age Range APIに言及するにとどまりますが、App Store Connectヘルプはさらに、13歳未満のユーザーには一切アクセスさせないこと、そして「年齢に適したUGCのみが配信される」ことを加えています。²⁴
• Declared Age Range APIが提供されるのはiOS、iPadOS、Mac Catalyst、macOSだけで、ほかのプラットフォームにはありません。⁵ tvOS、visionOS、watchOSのアプリも9月には同じ質問に答える必要がありますが、除外規定を満たすための文書化された手段が、そのプラットフォームには存在しないのです。

このサイクルで唯一、カレンダーが引き金を引く変更

今サイクルで扱ってきた破壊的変更は、どれもこちらが動くまで待ってくれます。起動画面の必須化はiOS 27.0 SDKに対してビルドした時点で発動します。@StateマクロはXcode 27でプロジェクトを開いた時点。On Demand Resourcesの非推奨化が起こすのはコンパイラ警告だけで、無視し続けることもできます。ツールチェーンに手をつけなければ、どれも自分のところには来ません。

ところがソーシャルメディアの申告は、放っておいても向こうからやってきます。Appleがこれを特定の月と、どのみち行っていた行為に結びつけたからです。1行のバグ修正も機能リリースと同じ提出パイプラインを通り、9月からはそのパイプラインがこの質問を投げてきます。

適用範囲は狭く、正確に読む価値があります。対象は「App Storeへの新バージョンまたはアップデート」と「代替アプリマーケットプレイスでの配信に向けた公証」です。² 7月の告知も「App Storeへの新規アプリまたはアップデート」「代替配信のための公証への提出」と、同じ組み合わせを繰り返しています。³ どちらの告知にもSDKのバージョン、デプロイメントターゲット、プラットフォームへの言及はありません。すでに公開中のアプリはそのまま販売され続けます。関門が置かれているのは、次の提出の入口なのです。

回答によって支払うことになるのは、保護者が上限を設定できる区分への配置です。Time Allowancesは今秋、Ask to Browse、Schedules、刷新されたスクリーンタイムとともに登場し、保護者に「エンターテインメント、ゲーム、ソーシャルメディアを含むカテゴリ全体で、子どもがアプリに費やす時間をより柔軟に管理する方法」を提供します。出発点となるのは年齢に応じたガイダンスです。¹⁶ エンターテインメントとゲームへの配置はApp Store Connectのカテゴリに従いますが、ソーシャルメディアへの配置は質問票の回答だけで決まり、「App Store Connectで選択したカテゴリに関係なく」適用されます。² フィードを備えたパズルゲームは、プロダクトページの表示が何であれ、保護者が真っ先に制限をかける区分に着地するわけです。

Appleは用語を定義している。ただし定義は揺れている

ポリシー関連の質問でありがちな失敗は、定義されていない言葉を推測で埋めることです。Appleは定義を公開しており、その分だけ推測の余地は狭まります。ただし、その定義は4回公開され、それぞれ境界が違うのです。

6月版は包括的な書き方をしています。「これには、ソーシャルフィードまたは類似の発見手段を通じて、多数のユーザーへ可視的にコンテンツを広める形でユーザー生成コンテンツを再配信、増幅、またはそれに対して操作する機能が含まれます」²

7月版は定義文らしく、しかも短くなっています。「ソーシャルメディア機能とは、ソーシャルフィードまたは類似の発見手段を通じて、ユーザー生成コンテンツを再配信、増幅、またはそれに対して操作する機能と定義されます」³ 多数のユーザーへ可視的に広めるという限定句が消えています。

App Store Connectヘルプに載っているのが最も長い版で、限定句を残したうえで例を加えています。「ソーシャルフィードまたは類似の発見手段を通じて、多数のユーザーへ可視的にコンテンツを広める形で行われる、ユーザー生成コンテンツの再配信、増幅、または操作。次のようなものが含まれる場合があります。ユーザーによる再投稿、いいね、コメント、リアクション、あるいはソーシャルフィード、コミュニティ、検索、その他の共有・発見ツールを通じてユーザー生成コンテンツをより目立たせる行為」⁴

4つのうち3つは、広範かつ可視的な拡散を要件としています。1つはそうではありません。境界線上にあるアプリにとって、この差が答えを決めます。私はヘルプページを基準とみなします。質問票がそこへリンクしており、ニュース記事は時とともに古くなるからです。ただし、そう読むのは私の推論であって、Appleの指示ではありません。「含まれる場合があります」という書き方も重要です。Appleは例を挙げているだけで、集合を閉じていません。列挙された5つの動詞のどれにも似ていない機能が該当する余地は残っています。

境界を鮮明にしてくれるのは、この記述子が並んでいる顔ぶれです。Appleはユーザー生成コンテンツを「アプリの意図されたユーザー体験の構成要素として、ユーザーが作成したコンテンツを広く配信すること」と別途定義し、メッセージとチャットもまた別に、ユーザーが「アプリ内の機能を通じて相互に直接コミュニケーションできる」ことと定義しています。⁴ App Store Connect APIはこの区別をそのまま保持し、userGeneratedContent、messagingAndChat、socialMediaを独立した3つのBoolean値として持っています。¹

レーティングの差はさらに鮮明です。ユーザー生成コンテンツもメッセージも、Appleの4+の定義に含まれています。一方、ソーシャルメディアが最初に現れるのは13+です。⁴ ユーザーのコンテンツを預かり、ユーザー同士がメッセージを送り合えるアプリでも、4+のままでいられます。そこに、同じコンテンツを見知らぬ他人へ増幅するフィードを加えた途端、下限が9歳分跳ね上がるのです。ソーシャルメディア関連の記述子はいずれもOS 26以降のレーティング体系にしか存在せず、それ以前のOSバージョン向けのAppleの表には、どのレーティングにもソーシャルメディアの項目がありません。⁴

項目には今日から回答できる

質問票の変更がすでに反映されていることは、Appleの3つの資料から確認できます。この記事全体の実務的な要点はここにあります。

7月9日のAppleの告知は、質問票に「アプリのソーシャルメディア機能に関する質問が追加されました」と述べ、すぐに回答するよう促しています。³ App Store Connect APIはsocialMediaを「アプリにソーシャルメディア機能が含まれるかどうかを示すBoolean値」、socialMediaAgeRestrictedを「アプリのソーシャルメディア機能に年齢制限があるかどうかを示すBoolean値」として文書化しています。¹ Appleが公開しているOpenAPI仕様でも、どちらも書き込み可能かつnull許容のBoolean値として記載されています。¹ これらはageAssuranceの隣に並んでいます。ageAssuranceは以前の質問票刷新でAppleが追加したもので、その定義には該当する仕組みの一つとして「declared age range API」が挙げられています。⁴¹⁵ つまり除外規定を採用すると、この定義の内側にも入ることになります。私にはこれは、放置してよい話ではなく、あらためて確認すべき2つ目の質問に見えます。

提出作業を自動化している人は、今のうちに形を把握しておくべきです。申告内容はGET /v1/appInfos/{id}/ageRatingDeclarationで読み取り、PATCH /v1/ageRatingDeclarations/{id}で書き込み、fields[ageRatingDeclarations]パラメータにはどちらのBoolean値も渡せます。¹ 年齢レーティングのペイロードを手作業で組み立てているパイプラインは、通らなくなる日が来るまでは通り続けるのです。

7月になって初めて明らかになった帰結が一つあります。「これらの機能を持つアプリは、App Storeのプロダクトページに新しいソーシャルメディアのコンテンツ記述子が表示されます」³ 「はい」と答えることは、保護者向け管理機能の区分だけでなく、ストア掲載そのものを変えるということです。

ですから今週のうちに質問票を開き、App Store Connectが算出するレーティングを確認してください。回答しても提出するまでは何も確定しません。そして締め切りは、すでに済ませた判断へと姿を変えます。

除外規定の条件は1つではなく3つ

Appleのニュース記事は、13歳未満向けの経路をまるでAPIを1回呼ぶだけの話のように読ませます。「アプリまたはゲームにソーシャルメディア機能が含まれるが、13歳未満のユーザーに対しては無効化されていると申告した場合、13歳未満のユーザー向けのソーシャルメディアのTime Allowanceカテゴリには含まれません……また、ユーザーの年齢範囲を確認するために、少なくともDeclared Age Range APIを使用する必要があります」²

App Store Connectヘルプは、同じ記述子を3つの要件として提示しています。「13歳未満のユーザーはソーシャルメディア機能にアクセスできない。少なくとも、ソーシャルメディア機能を有効にする前にDeclared Age Range APIを呼び出してユーザーの年齢範囲を確認している。年齢に適したUGCのみが配信される」⁴

誰も引用しないのが3番目の文です。「年齢に適したUGCのみが配信される」というのは、対応するAPIもなければ、公開された閾値もなく、実行できるテストもない、モデレーションの義務です。Appleは「年齢に適した」の定義も、配信の仕組みも示していません。年齢確認を導入したうえで、12歳の子どもにフィルタなしの同じフィードを届けているチームは、ヘルプページの文面に照らせば3条件のうち1つしか満たしていないことになります。

除外規定で何が手に入らないのかにも注意が必要です。Apple自身の文はこう続きます。そうしたアプリも「13歳以上のユーザーに対してはソーシャルメディアのカテゴリに残ります」² 免除の対象は13歳未満のユーザーだけなので、14歳の子どもは保護者がソーシャルメディアに設定した上限をそのまま受けることになります。

レーティングの表には、私には解消できない矛盾があります。Appleのニュース記事は、制限付きの選択肢を選んだ場合は「年齢レーティング質問票への回答全体」がレーティングを決め、「13+より低いレーティングになる可能性があります」と述べています。² ところがAppleのグローバル表は、「ソーシャルメディア」と「13歳未満のユーザーに対してソーシャルメディアを無効化」の両方をCapabilitiesの13+に並べており、地域別の表でもオーストラリアで16+、ブラジルでA16、韓国で15+、ベトナムで16+と、両者を同じ位置に置いています。⁴ 記述子が下限を定めるという他の行と同じ読み方をすれば、制限付きの選択肢もやはり13+の下限に見えます。Appleはこの矛盾をどこでも整理していませんし、App Store Connectの算出ロジックがどちらの文書に従っているのかを私が当てにいくつもりもありません。実際の質問票でこの選択肢を選び、算出されたレーティングを読み、どちらの文書よりもその算出結果を信じてください。

申告項目をアプリの内側まで追う

除外規定を採る場合を考えてみましょう。XcodeでターゲットのDeclared Age Rangeの機能（Capability）を有効にすると、com.apple.developer.declared-age-range entitlementが追加されます。「アプリが人の年齢範囲を要求できるかどうかを示すBoolean値」です。⁶ そのうえで、必要な閾値を指定してAPIを呼び出します。SwiftUIでは環境アクションとして提供されます。⁵

Appleはこのアクションに、呼び出し場所のルールを添えています。「ユーザーの操作に応じて」使うこと。Apple自身のサンプルでも、呼び出しはボタンの裏に置かれています。⁵ このリクエストはシステムシートを表示することがあるため、.taskやonAppearから発火させると、まだ何も求めていない相手にいきなり許可を尋ねることになります。制限対象の画面に入るタップに紐づけましょう。

import SwiftUI
import DeclaredAgeRange

@available(iOS 26.0, *)
struct SocialFeedGate: View {
    @Environment(\.requestAgeRange) private var requestAgeRange
    @State private var feedEnabled = false
    @State private var checking = false

    var body: some View {
        if feedEnabled {
            FeedView()
        } else {
            Button("Open community feed") {
                checking = true
                Task {
                    feedEnabled = await resolveGate()
                    checking = false
                }
            }
            .disabled(checking)
        }
    }

    private func resolveGate() async -> Bool {
        guard let response = try? await requestAgeRange(ageGates: 13) else {
            return false          // AgeRangeService.Error: your default, not Apple's
        }
        guard case let .sharing(ageRange) = response else {
            return false          // .declinedSharing
        }
        guard let lowerBound = ageRange.lowerBound else {
            return false          // nil lower bound means below your lowest gate
        }
        return lowerBound >= 13
    }
}

このコードの中で、年齢確認が機能するかどうかを決めるポイントが4つあります。

閾値は最大3つまで。 どちらのオーバーロードも閾値は3つで打ち止めです。SwiftUIのアクションはcallAsFunction(ageGates threshold1: Int, _ threshold2: Int? = nil, _ threshold3: Int? = nil)、UIKitのメソッドはこれに表示元のアンカーが加わるだけです。⁷ 区分は最大4つが上限になります。Appleのルール向けに13、オーストラリアの法律向けに16が必要なら、何も設計しないうちに4つのうち3つを使い切っている計算です。

下限がnilなのはエラーではなく答え。 AgeRange.lowerBoundとupperBoundはどちらもInt?で、Appleはnilの場合をはっきり書いています。「この値がnilの場合、その人の年齢範囲は指定した最も低い年齢を下回っており、最低年齢要件を満たしていないことを示します」⁸ 楽観的にアンラップするコードは、まさに守るべき対象に対して判定を反転させてしまいます。

共有の拒否は実在する分岐であり、その扱いをAppleは示していない。 AgeRangeService.Responseは.sharing(range:)と.declinedSharingを持ちます。⁹ 一部の規制地域では「システムが自動的にその人の年齢範囲を提供」し、ユーザーは「共有を拒否できません」。規制のない地域では「その人が拒否した場合、declinedSharingレスポンスを受け取ります」¹⁰ 拒否は、プライバシーを重んじる成人と見分けがつきません。13歳未満とみなせば大人を締め出し、成人とみなせば閉じると約束した扉を開けてしまいます。既定の挙動はAppleではなく作り手に委ねられています。私なら安全側に倒し、そのことを画面上で明示します。

指定した閾値はあくまで参考値。 システムは「その人の所在地および適用される規制に基づき、指定した年齢の閾値を上書きする年齢範囲を返す場合があります」。現地の規制が特定の閾値を要求する場合、「返される年齢範囲は、指定した閾値の境界ではなく規制上の要件を反映します」⁷ 返り値が要求どおりだと決めつけたコードは、最も規制の厳しい地域から真っ先に壊れます。

もう一つ、設計に織り込むべき挙動があります。これは問い合わせを生むだろうと私は見ています。Appleは回答をキャッシュするのです。「ある人の年齢が新しい範囲に入った場合（たとえば13歳になったとき）、APIは当初の申告から1年が経過するまで、以前の範囲を返し続けます」¹⁰ 月曜に13歳になった子どもが、その後何か月も13歳未満として扱われ得るということです。解決策はユーザー自身がたどる設定の経路で、自分の名前、個人情報、Age Range for Appsの順に進みます。¹⁰ 13歳を基準にしているアプリは、この案内を自前のUIに載せる必要があります。そうしなければ誰も見つけられないからです。

設計時に押さえておくべき細かい点が2つあります。isEligibleForAgeFeaturesは、その人が年齢確認を要求する地域にいるかどうかを返します。macOSでは「その人またはデバイスに対してシステムがAge Assuranceを必要としないためfalseを返す」ので、MacアプリはrequestAgeRangeを直接呼ぶことになります。¹¹ もう一つ、年齢がどのように設定されたかを伝えるAgeRangeDeclarationは、すでに変遷を経ています。26.2では本人と保護者それぞれについて支払い方法、政府発行IDなどを区別する6つのケースがありましたが、26.5では単一のconfirmedケースに集約されました。¹² どの方法で確認されたのかを問い合わせても、現在のAPIはもう答えてくれません。

そしてプラットフォームの下限があります。これは可用性のメタデータには書かれていますが、文章の形ではどこにも書かれていません。Declared Age Rangeが公開しているのはiOS 26.0、iPadOS 26.0、Mac Catalyst 26.0、macOS 26.0だけで、tvOSの行もvisionOSの行もwatchOSの行もありません。⁵ Time Allowancesも同じ系列に、つまり「iOS 27、iPadOS 27、macOS 27以降」に載りますが、申告要件のほうにはプラットフォームの限定が一切ありません。²³ つまりソーシャルフィードを備えたtvOSやvisionOSのアプリは、9月に回答する義務を負いながら、除外規定が文書上求める最低条件を満たせません。そこには、条件が名指ししているAPI自体が存在しないからです。この食い違いを意図的な免除ではなく抜けと読むのは私の推論で、Appleはどちらとも公表していません。

自分の8本のアプリは何を申告するのか

他人のコードについて書く前に、自分のところを調べました。Xcodeプロジェクト8本、Swiftファイル491本です。¹³ CKShare、UICloudSharingController、共有または公開のCloudKitデータベース、GameKit、Declared Age Rangeのシンボルは、どれも1件も含まれていません。この8本の中に、ある人のコンテンツを別の人へ渡すアプリは一つもないわけです。4本には該当しそうな画面すら存在しません。残る4本には、慎重な人なら判断に迷うかもしれない部分があり、それは考え方を声に出して整理する価値のある3種類に分かれます。

Get Bananasには共有の買い物リストがあるが、この「共有」は言葉の印象より狭い。 このアプリはiCloudのubiquityコンテナにJSONドキュメントを書き込み、iPhone、Apple Watch、Macから読み戻します。com.apple.developer.icloud-servicesにはCloudDocumentsが設定されており、プロジェクト内にCloudKitの共有機能は一切ありません。¹³ 共有されているのは1人のデバイス間であって、人と人の間ではないので、再配信は起きませんし、広める相手となる2人目のユーザーも存在しません。答えが変わるのは、家族での共同編集のためにCKShareを入れる日です。しかもその時点で該当するのはソーシャルメディアではなくユーザー生成コンテンツでしょう。2人の買い物リストにはフィードも発見の場もないからです。注視すべき線はもっと先にあります。共有リストに公開テンプレートのギャラリーといいねが加われば、それは手順の多いフィードにほかなりません。

3本のアプリは共有シートを出すが、共有シートはソーシャル機能ではない。 Get Bananas、Water、ResumeGeniのiOSアプリはいずれもUIActivityViewControllerをラップし、ユーザー自身のコンテンツを選んだ先のアプリへ渡します。¹³ コンテンツはメッセージやメールへ出ていき、私のアプリが制御する画面には戻ってきません。Appleの定義が要件としているのは「ソーシャルフィードまたは類似の発見手段を通じた」再配信であり、システムの共有シートはそれに当たりません。⁴ この理屈はApp Storeのかなりの部分に当てはまります。書き出しは公開ではないのです。

Watch Connectivityはメッセージ機能に見えて、そうではない。 Get BananasとRepsはどちらもWCSessionを使いますが、これが動かすのは同一人物のiPhoneとApple Watchの間のデータです。一方、Appleのメッセージとチャットの記述子は「ユーザーが相互に直接コミュニケーションできる」ことを要件としています。⁴¹³ ここでは両端に同じ1人が座っています。

この「該当なし」という結果には一般化できる部分があり、そこが借用する価値のあるところです。この8本はいずれも、作った本人のためにコンテンツを保存し、同じ本人に見せ返しているだけです。質問票が尋ねているのはまったく別のことです。あなたのアプリは、ある人のコンテンツを、拡散する仕組みを通じて他人の目の前に置くのか。トラッカー、タイマー、学習ツールは、ポリシーの読み込みではなくアーキテクチャによって「いいえ」と答えます。考えなければならないのは、ユーザーが互いの成果物を目にする画面を持つアプリのほうです。

デプロイメントターゲットも最初に確認すべきもう一つの数字です。iOSターゲットを持つ7本のうち6本はiOS 26.0以降ですが、Ace Citizenshipは一部のターゲットで17.0と17.5のままです。¹³ 26.0未満ではAPIをそもそも呼べないため、除外規定は選択肢から外れ、正確な答えは素の申告だけになります。

プラットフォームの空白も同じ調査で表面化し、しかもバージョンの問題より広い範囲に及びます。8本のうち4本がSUPPORTED_PLATFORMSにxros xrsimulatorを宣言しています。Reps、Return、Water、Yawaraです。Repsはさらにappletvos appletvsimulatorを加え、独立したwatchos watchsimulatorターゲットも持っています。ReturnとBanana ListにもwatchOSターゲットがあります。¹³ Declared Age Rangeが可用性を公開しているのはiOS 26.0、iPadOS 26.0、Mac Catalyst 26.0、macOS 26.0で、tvOS、visionOS、watchOSの行はありません。⁵ これらのターゲットはいずれも9月の申告義務を負い、そのどれであっても「はい」と答えた時点で除外規定は手の届かない場所へ行きます。除外規定が依存するAPIが、そこには提供されていないからです。

調べ方について一つ注意を。最初の走査で私はここを間違えました。XROS_DEPLOYMENT_TARGETは、visionOS向けの出力先をまったく持たないプロジェクトにも現れます。Xcodeがこの設定を構成に無条件で書き込むからです。ResumeGeniはXROS_DEPLOYMENT_TARGET = 26.2を持ちながら、ビルド対象はiphoneos iphonesimulatorだけです。¹³ デプロイメントターゲットのキーではなくSUPPORTED_PLATFORMSを読んでください。そうしないと、出荷してもいないプラットフォームまで数えてしまいます。

技術の話ではなくなる地点

AppleはDeclared Age Rangeのドキュメントに、二度読む価値のある但し書きを添えています。このデータは「エンドユーザー本人、またはその親権者もしくは保護者が申告した情報に基づく」ものであり、「アプリに適用され得る関連法令の遵守を確保する責任は、すべて開発者にあります」¹⁴

この一文が、本稿が立ち止まる線を引いています。Appleの質問票が生み出すのはレーティングとTime Allowanceの区分であって、法令遵守ではありません。オーストラリアでは2025年12月10日から、一定のソーシャルメディアプラットフォームに16歳未満のアカウント保有を防ぐ義務が課されており、この法律に関するAppleのガイダンスは、Declared Age Range APIを5つの手段のうちの1つとして挙げています。¹⁵ 質問票と法律は、重なりはしても揃いません。一方は13歳を、他方は16歳を問い、こちらが使える閾値は3つしかないのです。

あなたのアプリが特定の法律の下でソーシャルメディアプラットフォームに当たるかどうかは、その法域の弁護士に尋ねる問いです。Appleの質問票の意味でソーシャルメディア機能を持つかどうかは、あなた自身の問いであり、Appleが公開した定義に照らして今日答えられます。

FAQ

ソーシャルメディアの質問は、今App Store Connectで回答できますか

はい。Appleの2026年7月9日の告知は、質問票に「アプリのソーシャルメディア機能に関する質問が追加されました」、そして「本日より、これらの質問を確認して回答できます」と述べています。³ App Store Connect APIも独立にこれを裏づけており、socialMediaとsocialMediaAgeRestrictedをAgeRatingDeclarationリソースの属性として文書化しています。どちらもPATCH /v1/ageRatingDeclarations/{id}で書き込み可能です。¹ 今答えても確定はしません。回答が拘束力を持つのは提出時であり、2026年9月というのは、回答なしでは提出できなくなる時点のことです。²

Appleは「ソーシャルメディア機能」を定義していますか

はい、4か所で、しかも2通りの範囲で定義しています。最も詳しいのはApp Store Connectヘルプで、「ソーシャルフィードまたは類似の発見手段を通じて、多数のユーザーへ可視的にコンテンツを広める形で行われる、ユーザー生成コンテンツの再配信、増幅、または操作」を要件とし、再投稿、いいね、コメント、リアクション、可視性を高める行為を例として挙げています。⁴ 6月版は同じ限定句を含み、7月版はそれを落としています。²³ 例は網羅的ではなく例示にすぎないため、最終的に自分のアプリを分類するのは自分自身です。私ならヘルプページを基準に判断します。

自分のアプリにはユーザー生成コンテンツがあります。これは自動的にソーシャルメディアになりますか

いいえ。Appleは両者を、定義もレーティングへの影響も別々の質問として扱っています。ユーザー生成コンテンツは「アプリの意図されたユーザー体験の構成要素として、ユーザーが作成したコンテンツを広く配信すること」を指し、Appleの4+の定義に含まれます。⁴ ソーシャルメディアはフィードまたは同等の発見手段を通じた再配信、増幅、操作を要件とし、最初に現れるのは13+です。⁴ APIもこの区別を反映し、userGeneratedContentとsocialMediaを独立したBoolean値として持っています。¹ 本人にしか見えないコンテンツを作るアプリは、そのどちらでもありません。

13歳未満向けの選択肢を選ぶと、実際には何を実装することになりますか

3つあり、APIに関わるのはそのうち2番目だけです。App Store Connectヘルプが求めているのは、13歳未満のユーザーがソーシャルメディア機能にアクセスできないこと、「少なくとも、ソーシャルメディア機能を有効にする前にDeclared Age Range APIを呼び出してユーザーの年齢範囲を確認している」こと、そして「年齢に適したUGCのみが配信される」ことです。⁴ したがってcom.apple.developer.declared-age-range entitlementを追加し、ソーシャルな画面が現れる前に閾値の一つに13を含めてrequestAgeRangeを呼び、Appleが定義していない拒否のケースも含めてレスポンスで分岐させ、そのうえで別途、未成年へ配信するコンテンツを年齢に適した内容に保つことになります。⁵⁶ APIの閾値は3つが上限で、しかも申告から1年が経つまで年齢範囲をキャッシュするため、13歳になったユーザーは設定を更新するまで、それより下として扱われ続けます。⁷¹⁰

押さえておきたい要点

iOS開発者へ - 9月ではなく今週、質問票に答えてください。項目はすでに公開されており、回答が拘束力を持つのは提出時だけです。算出されたレーティングを読めば、どちらの告知でもきれいに解決されていない13+の問題に決着がつきます。³⁴ - 13歳未満向けの除外規定を選ぶなら、APIを1回呼ぶ話ではなく3つの条件として見積もり、拒否時の分岐を意識して書いてください。.declinedSharingはプライバシーを重んじる成人と見分けがつかず、どちらに倒すべきかAppleは何も示していません。⁴⁹

tvOS、visionOS、watchOSに関わるチームへ - 計画を立てる前に可用性を確認してください。Declared Age RangeはiOS、iPadOS、Mac Catalyst、macOSの行しか公開していません。つまり、除外規定が文書上求める最低条件はあなたのプラットフォームでは使えない一方で、9月の申告義務は変わらず提出に適用されます。²⁵ - 同じ空白は、理由は違えどiOS 26.0未満のターゲットすべてを捉えます。APIがなければ除外規定もなく、正確な答えは素の申告だけになります。⁵

リリース管理者へ - 今サイクルの他の変更とは違い、この件は日付が引き金だと考えてください。起動画面のキーと@Stateマクロは、自分で制御できるSDKとツールチェーンによって発火します。9月に発火するのは、どのみち行っていた提出のほうです。² - 回答はプロダクトページの担当者にも回してください。ソーシャルメディア機能を申告すると、App Storeの掲載にソーシャルメディアのコンテンツ記述子が追加されます。Appleがこれを明かしたのは7月になってからです。³

27サイクルの変更は、何が引き金を引くかによって整理され続けています。ビルド設定、ツールチェーン、コンパイラ警告、そして今回はカレンダーです。同じサイクルの中で最も強制力が弱く、しかし移行の負担が最も大きい非推奨化については、On Demand ResourcesとBackground Assetsの代償をご覧ください。シリーズ全体の入口はApple Ecosystemシリーズです。

参考文献