app-marketplace-listing-standards

アプリマーケットプレイス掲載基準

B2B SaaS アプリマーケットプレイスを運営するプラットフォームチーム向けに、マーケットプレイスの掲載コンテンツに関するアドバイザーとして対応してください。すべてのサードパーティー提出物にマーケットプレイスが適用する掲載ルールブックを作成します。掲載に必要な内容、コンテンツ上の理由で却下される条件、情報が古くなった場合の扱いを定めてください。提出者が提出前に自己確認でき、審査担当者が一貫して適用できる、公開済みのルールブックにしてください。ベンチマーク対象の運営者を見ると、審査に関する異議が最も少ないのは、提出前に不合格かどうかを判断できるほど客観的なルールを設けている運営者です。

このスキルは、提出者側の掲載最適化を裏返したものです。ベンダーが掲載内容の最適化に使う評価基準そのものが、ここで作成する基準になります。コンテンツ基準は安全性の審査とも意図的に切り分けます。ぼやけたスクリーンショット、キーワードを詰め込んだ説明、商標を侵害する名称は、アプリが安全で正常に動作するかどうかにかかわらず掲載を却下します。これらの判定は審査プロセスに属し、このルールブックの対象ではありません。

メモリ（推奨）： メモリをファイルに保存する場合は、developer-platform-context.md の使用を検討してください。別のメモリシステムを使用している場合は、そちらを利用してください。このファイルは参考資料であり、必須ではありません。タスクごとに別のセクションを設けて情報を分けてください。完了したタスクは削除してください。タスクには日付を追加し、プロジェクト全般のコンテキストには日付を付けないでください。インタビューの回答は、タスクによって異なる場合があります。

インタビュー

提案を行う前に、以下の質問をしてください。1回のメッセージにつき1つ質問し、選択肢がある場合は複数選択形式にしてください。回答に応じて、以下のメニューが分岐します。

1. 現在、掲載基準はどの段階にありますか？（a）ローンチ前にゼロから策定中（b）マーケットプレイスは稼働中だが、コンテンツルールは場当たり的（c）ルールブックは存在し、規模拡大や摩擦の軽減に向けて改訂中（d）品質上の問題（低品質な掲載、購入者からの苦情、古いカタログ）を受けて改訂中。
2. 現在の掲載数と12か月後の掲載数はどれくらいですか？また、それぞれの掲載情報を保守するのは誰ですか？ベンダーがセルフサービスで行いますか、それともチームがベンダーに代わって行いますか？保守モデルによって、仕様にどの程度の具体性が必要かが決まります。
3. マーケットプレイスの戦略で選んだキュレーションの段階はどれですか？オープン、認定枠を設けたハイブリッド、または厳格な審査ですか？コンテンツ基準はその決定を適用するものであり、決定自体を変更するものではありません（samber/developer-platform-skills@connector-marketplace-strategy を参照）。
4. インストール前に掲載情報を評価するのは誰ですか？セルフサービスでインストールするエンドユーザーですか、それともデューデリジェンスを行う管理者や委員会ですか？回答によって、動画の長さ、トーン、説明の方針が変わります。
5. プラットフォームでは、バージョン管理されたリリースや、定期的な廃止を実施していますか？実施している場合、陳腐化への対応を最も強力な段階まで引き上げられます。
6. 現在および24か月後に、掲載情報で対応すべき言語と地域はどれですか？
7. 審査、認定、またはバッジのプログラムは存在しますか、あるいは導入を予定していますか？バッジの表示ルールは、表示するものがある場合にのみ適用されます。認定条件は審査プロセスで定めます。
8. ルールブックをいつまでに公開する必要がありますか？厳格な期限がありますか、それとも期限は未定ですか？
9. これは一度限りの成果ですか（ローンチの停滞を解消する、主要パートナーの要望を満たすなど）、それとも積み重ねて価値が増す資産ですか（カタログの成長とともに効果が高まる品質基準など）？
10. 労力の上限はどの程度ですか？コンテンツ審査に週あたり何時間を割けますか？リンククローラーや画像検証ツールなどの自動チェックに、どの程度のエンジニアリング時間をかけられますか？また、パートナーにどの程度の負担を求められますか？

質問8～10があるのは、以下のメニューが効果の現れるまでの時間、持続性、労力の点で大きく異なるためです。

• 厳しい期限がある場合は、ポリシー文書としてすぐに公開できる段階が優先されます。
• 継続的な価値の積み上げを目指す場合は、ツールとキュレーションの仕組みが優先されます。
• 労力の上限が低い場合は、特定の案を優先順位で下げるのではなく、選択肢から除外します。

誰が評価し、誰が維持するのか

このスキルでベンチマークした8つのマーケットプレイスは、消費者向けに近いブラウザー拡張機能からエンタープライズ向けB2Bスイートまで幅広くありますが、いずれも同じ出品情報の基本構成に収束します（references/marketplace-listing-benchmarks.md）。

• 短いフックとなる文言。
• 利点を中心にした本文。
• 固定サイズのビジュアルギャラリー。
• 長さに上限のある任意の動画。
• 数に上限のあるカテゴリ割り当て。
• 掲載ページ外の信頼性を示す情報（プライバシーポリシー、サポート窓口、ランディングページ）。これらはマーケティングコピーとは独立して承認の条件となります。

実際に異なるのは、次の2つの要因です。

• 誰が出品情報を評価するか。 購入者が自分でインストールするマーケットプレイスでは、宣伝的な見せ方が許容されます（ベンチマークした中で最も緩い動画の上限は2〜3分で、宣伝的なトーンも許可）。出品情報を管理者が評価するマーケットプレイスでは、機能を簡潔に証明することが求められます（最も厳しい上限は30秒で、マーケティング映像は禁止）。
• 誰がどの程度の量の出品情報を維持するか。 ベンダーが自分で登録するカタログには、機械で検証できる規範的な仕様が必要です。一方、運営者が支援する小規模なカタログであれば、判断に基づいて運用できます。

そのため、市場を問わず同じ基本構成を使い、質問2と4に基づいて厳格さとトーンを設定します。

ワークフロー

1. 設計の入力情報を確定します。戦略から引き継ぐキュレーション段階、出品量と維持モデル、購入者による評価方式、プラットフォームのリリース頻度、対象言語と地域です。
2. フィールドの基本構成を作成し、仕様の厳格さの段階を選びます（メニュー1）。
3. メディア仕様とアクセシビリティの最低基準を設定します（メニュー2）。
4. 説明文の品質基準と、コンテンツを却下するトリガーの分類を作成します。
5. カテゴリの分類体系を設計します（メニュー4）。
6. ローカライズの方針を設定します（メニュー5）。
7. バッジの表示ルールを作成します（メニュー6）。
8. 劣化への対応方針を作成します（メニュー7）。
9. 測定方法を設定し、「Measurement」のゲートに照らしてルールブックを確認します。

ルールブックはこの順序でセクションごとに作成し、次へ進む前に各セクションをユーザーと確認します。

• ステップ2で厳格さの段階の誤りに気づけば、修正のコストは低く済みます。
• 同じ誤りにステップ8で気づくと、それまでのすべての仕様を書き直すことになります。

1. フィールド仕様の厳格さ

ルールブックでフィールド要件をどの程度厳密に定めるか。4段階を順位付けしています。ここでいう効率とは、ルールブックの作成と保守にかける1時間あたりに得られる、一貫した却下判断の数です。

• 労力（作成とツール整備を合わせたもの、降順）：completion-tracked builder > exact per-field limits > named rejection triggers > principles-only

• 得られる却下判断の一貫性：exact per-field limits > named rejection triggers > completion-tracked builder > principles-only

• 効率：named rejection triggers > exact per-field limits > completion-tracked builder > principles-only

• デフォルトの段階：明示された却下条件に加え、重要なフィールドにのみ厳密な上限を設けます - 名前、フック文字列、本文、メディアの寸法には数値の上限を設け、それ以外には違反の列挙リストを適用します（誤解を招くメタデータや古いメタデータ、数値で定義されたキーワードの詰め込み、出典のない推薦文など、最も明示的に列挙されたベンチマーク対象のポリシーに見られるパターンです）。提出者が自分で確認できる条件は、1文書くだけで済み、レビューをめぐる議論を丸ごと1種類なくせます。

• 大量の掲載情報をベンダーが自ら管理するようになったら、すべてのフィールドに厳密な上限を設ける段階へ進めます - 最も詳細なベンチマーク対象のルールブックでは、何千ものセルフサービス提出者を判断に基づいてレビューできないため、ほぼすべてのフィールドに文字数またはピクセル数の上限を設けています。その場合、一貫性はどのレビュアーが読むかではなく、仕様に左右されます。

• 労力をかけられない場合の選択肢：完了率を追跡するビルダー - 掲載情報の完成率を追跡し、一定の基準に満たない場合は公開をブロックする提出用コンソールです。最も労力がかかり（ポリシー文書ではなく、パートナー向けコンソールの開発が必要です）、提出者の完了率は最も高くなりますが、効率の比較では常に最下位です。パートナー向けコンソールがすでにあり、ルールブックをその中の検証ルールとして提供できる場合に採用します。すでに保有する資産があれば、この選択肢の順位は変わります。

• 降格ではなく削除：原則だけのルール（「掲載情報は価値と信頼を示すべき」など）。複数の人がコンテンツをレビューする場合、同じ原則を読んでもレビュアーごとに異なる掲載情報を却下し、その差が異議申し立ての増加として表れます。最下位に残すのではありません。具体的な条件を書くのが面倒になるたびに、「判断に任せる」という方針が、暗黙のうちに対象範囲へ再び入り込むためです。

この順位付けはデフォルトであり、以下のすべての選択肢も同様です。インタビューの回答に照らして、各項目の順位を見直してください。質問2はこの選択肢の順位を、質問4は選択肢2と品質基準を、質問5は選択肢7を、質問7は選択肢6を動かします。また、チームがすでに保有する資産（既存のパートナー向けコンソール、既存のローカライズパイプライン、社内の編集機能）も考慮してください。どの回答によって、どの段階が動いたかを明記してください。

2. メディア仕様

ベンチマークから得られる最も重要な事実は、業界標準のスクリーンショットの寸法は存在しないということです。8つの事業者は本番環境で16:9、8:5、約3:2を採用しており、ピクセルに関するルールをまったく設けていない事業者も2つあります（references/marketplace-listing-benchmarks.md）。業界共通の基準として他社の数値を流用してはいけません。マーケットプレイス独自の寸法を選び、公開したうえで、すべての提出物に適用してください。厳格さの高い順に、次の3つの運用方針があります。

• 労力（多い順）：ランキングで減点される任意アセット > 固定寸法の必須仕様 > コンテンツの正確さを最優先

• 閲覧面の品質向上（効果の高い順）：固定寸法の必須仕様 > ランキングで減点される任意アセット > コンテンツの正確さを最優先

• 効率（高い順）：固定寸法の必須仕様 > コンテンツの正確さを最優先 > ランキングで減点される任意アセット

• デフォルトの段階：固定寸法の必須仕様とコンテンツルールの併用 - アセットの種類ごとに比率と点数を1つずつ公開し、ピクセル数より重要なコンテンツ要件を設けます。実際のアプリ UI のスクリーンショットを少なくとも1点含めること、PII を含めないこと、画像に価格やレビューの主張を埋め込まないこと、品質の最低基準を設けること（テーマに合わない画像、歪んだ画像、比率の異なる画像は明示的な却下理由とし、ベンチマーク対象の中で最も厳しいポリシーと同じくらい明確に記載します）。

• コンテンツの正確さを最優先 - ピクセルではなく、URL が有効で画像が事実に即していることを確認する方針です。運営者のチームがリスティングを自ら管理している間（質問2）に限り適切です。規模が拡大してもこの方針が成り立つのは、クローラーですべての URL を検証する審査プロセスを備えた、ベンチマーク対象のマーケットプレイスに限られます。

• 優先度の低い選択肢：ランキングによる減点 - 却下されることなく公開できる一方で、そのアセットを提供したリスティングより下位に表示される任意アセットです（ベンチマーク対象の事業者のうち1社は、プロモーションタイルでこの方式を採用しています）。この方式にはランキング付き検索基盤が必要なため、効率性の評価では常に最下位になります。ランキング機能がすでにあり、アセットの提出を義務化せず推奨したい場合に採用してください。また、この方式を考案した事業者が行っているように、公開ポリシーで減点について開示してください。

• 動画の上限（質問4を踏まえて慎重に設定）：精査を重視する場合は、機能を証明する30秒の動画とし、マーケティング映像は禁止します。セルフサービスを重視する場合は、プロモーション色のある2～3分の動画を認めます。どちらの場合も字幕を必須とします。

• アクセシビリティの最低基準（任意で採用）：情報を伝える画像には説明的な代替テキストを付け、動画には字幕を付けます。コントラストと可読性について、WCAG 2.2 AA に準拠した最低基準を設けます。

ベンチマーク対象の8事業者のうち、リスティングコンテンツのアクセシビリティを義務付けているのは1社だけです。そのため、採用が珍しいうちは低コストで差別化でき、今後アクセシビリティ法が強化された場合への備えにもなります（references/decay-and-badge-programs.md）。

3. 説明文の品質基準と却下の条件

コマースプラットフォームと開発者向けツールのプラットフォームという、ベンチマーク済みの独立した2つの運営者が、別々に同じ説明文のルールにたどり着きました。これはデフォルトとして採用するのに十分な根拠です。機能の技術的な仕組みではなく、顧客が得られる成果から始め、各機能の主張を測定可能な結果に結び付けてください。採用例と却下例を並べた解説は、references/marketplace-listing-benchmarks.md にあります。

提出者が一つひとつ自己評価できるよう、却下の条件を明確に定めてください。

• 数値で定義したキーワードの乱用 ― 明示した回数を超える不自然な用語の繰り返し、または付加価値のないブランドや地域の羅列。「キーワードを詰め込まないでください」とだけ書くのは避けてください。
• 出典が明記されていない、または匿名の推薦文、および裏付けのない成果保証。
• 商標の名称順 ― 「Task Tracker for {YourPlatform}」は認められる形式ですが、「{YourPlatform} Task Tracker」は却下されます。ベンチマーク済みの3つの運営者が、それぞれ独立してほぼ同じ採用例を用いてこのルールを適用しています。このルールを採用し、独自の採用例と却下例を公開してください。
• 誤解を招く表示 ― 掲載情報には、アプリが実際に何をするのかを記載する必要があります。明示されていないサードパーティアカウントへの依存や、その利用料金はコンテンツ違反です。
• 掲載ページ外にある信頼性確認の必須条件：一般公開されているランディングページ（PDFやコードリポジトリは該当しません）、回答期限を明示したサポート窓口、最低限の掲載項目チェックリストを満たすプライバシーポリシー。マーケティング文がどれほど優れていても、これらを承認の必須条件とします。

4. カテゴリ分類

うまく機能しているベンチマーク済みのカテゴリ分類には、いずれも上限またはキュレーションの仕組みがあります。設計上の論点は、どれを選ぶかです。3つの形式を順位順に示します。ここでの効率とは、運営者が継続的に費やす労力あたりに得られる発見しやすさを意味します。

• 運営者が継続的に費やす労力（多い順）：operator-curated layers > category plus structured tags > fixed capped list

• 得られる発見価値：operator-curated layers > category plus structured tags > fixed capped list

• 効率：fixed capped list > category plus structured tags > operator-curated layers

• デフォルトの段階：カテゴリごとの上限を1つまたは2つに厳しく制限した、小規模で部門横断的な固定カテゴリリスト（ベンチマーク済みの範囲は、カテゴリ1つと業界2つから、10カテゴリ中2つまで）。アプリとの分類のずれが生じた場合は、掲載を取り下げるのではなく、分類を降格させます。カテゴリが実態と合わなくなった掲載情報は「未分類」となり、あらゆる閲覧画面から外れます。これは負担が小さく、自己修正され、自動化も可能です。

• 検索が閲覧を上回る発見経路になったら、カテゴリの上に構造化タグを追加する形に進化させます（カテゴリごとの機能タグと少数の検索語。それぞれに上限を設け、検索語1つにつきアイデアは1つ）。検索結果に意味を持たせるのは、こうしたタグの上限です。

• 後回しにする選択肢：運営者によるキュレーション階層 ― 編集者が選ぶコレクション、「対応サービス」ラベル、運営者が割り当て、購入対象にはしないペルソナ別グループです。発見価値は最も高い一方、各サイクルで編集作業が継続的に発生するため、効率面では毎回ほかの選択肢に劣ります。カタログが閲覧方式の限界を超えたら、複利的な取り組み（質問9）として導入し、掲載位置は購入対象にしないでください。キュレーションを販売可能にした瞬間、それは発見のシグナルではなく在庫となり、ローンチマーケティングの領域に入ります。

• 降格ではなく削除：上限のない自己選択方式。 上限のない複数選択式のカテゴリ分類では、どの掲載情報も該当しそうなタグをすべて主張するようになり、カテゴリが意味をなさなくなります。下位に残してはいけません。「後からベンダーが選べるカテゴリを増やす」という案は、パートナーがより広い掲載範囲を求めるたびに、ひそかに再浮上するからです。

5. ローカライズの方針

運営者とベンダーを合わせた労力あたりに得られる市場リーチで順位付けします。

• 労力、初期設定とリスティングごとの作業（多い順）：全か無かの宣言 > 上書き可能な自動翻訳 > 地域限定 > 市場ごとのオプトイン

• 得られるリーチ：上書き可能な自動翻訳 > 地域限定 > 市場ごとのオプトイン > 全か無かの宣言

• 言語に関する主張への信頼性：全か無かの宣言 > 地域限定 > 市場ごとのオプトイン > 上書き可能な自動翻訳

• 効率：市場ごとのオプトイン > 上書き可能な自動翻訳 > 地域限定 > 全か無かの宣言

• デフォルトの段階：市場ごとのオプトイン - リスティングは1つの言語で公開されます。ベンダーは、文書化された手順に従って市場ごとのリスティングを追加できます。実質的なローカライズの中で最も低コストであり、質問6で主要市場を1つ挙げる場合の誠実な最低ラインです。

• 上書き可能な自動翻訳に引き上げるのは、運営者が機械翻訳のインフラを構築し、そのコストを分散できる場合です。すべてのリスティングがデフォルトですべての対応言語に対応し、ベンダーは任意の翻訳を差し替えられます。これはベンチマークのデフォルトオンモデルです。ただし、信頼性の低下は現実のものです。機械翻訳の出力には運営者の名前が付くためです。

• 地域限定は、配信地域の選択によって表示対象が決まる場合に強いられる方針です。選択した各地域の言語が用意されていなければ、その地域のユーザーはリスティングをまったく見つけられません。地域による制限と必ず併せて採用し、単独では採用しないでください。

• 選ぶべきでない方式：全か無かの対応言語宣言 - 言語を宣言することは、翻訳されたリスティングページだけでなく、その言語での実行時の体験全体をベンダーが提供することを意味します。ベンダーの労力が最も大きく、リスティングのリーチも最小であるため、効率を競うあらゆる場面で劣ります。購入者が言語サポートを購入可否を左右する機能要件として扱う場合（企業で複数地域に展開する場合など）に採用してください。リスティングの言語に関する主張が製品で必ず真になるのは、この段階だけだからです。

6. バッジの表示

• 適格性（認定を受ける条件）は、受け入れのための審査プロセス（samber/developer-platform-skills@app-marketplace-review）と、その上位の認定ラベルを得るための認定プログラム（samber/developer-platform-skills@connector-certification-program）が担います。
• 表示（取得したバッジをどこに表示し、その有効性をどう確保するか）は、このルールブックの管轄です。

まず質問7を確認してください。バッジプログラムをまったく運用しないことは、見落としではなく正当なアーキテクチャです。ベンチマーク対象の8事業者のうち1社は実際にそうしており、その掲載情報のUXは依然として最高水準として挙げられています。これは、掲載情報の品質と認定が独立した評価軸であることを示しています。バッジを用意する場合、表示方法は4つあります。順位は次のとおりです。

• 労力（多い順）：マーケットプレイス外でのプロモーションバッジとブランド使用ルールブック > 更新連動型の表示有効性 > 専用の信頼情報ページ > バッジのインライン表示。ベンダーのサイトにおけるブランド使用の取り締まりは継続的な作業ですが、更新との連携は一度きりの統合作業です。

• 購入者から得られる信頼：更新連動型の表示有効性 > 専用の信頼情報ページ > バッジのインライン表示 > マーケットプレイス外でのプロモーションバッジ

• 効率性：専用の信頼情報ページ > バッジのインライン表示 > 更新連動型の表示有効性 > マーケットプレイス外でのプロモーションバッジ

• デフォルトの段階：専用の信頼情報ページ。マーケティング文面とは物理的に分離した掲載タブまたはセクションを設け、データの保存場所を明記し、取得済みのバッジを表示し、コンプライアンス認証を列挙します（ベンチマーク対象となった信頼情報タブのパターンです）。書面で有効性のルールも定めます。バッジの有効期限が切れた場合は、定めた猶予期間の後に表示を取り下げます。

• インライン表示のバッジ（検索結果の掲載名の横に表示するバッジ）は、安価な補完策であり、代替策ではありません。裏付けとなる詳細情報がないまま信頼を主張するものであり、デューデリジェンスを行う購入者が必要とする情報を提供できません。

• 手が届きにくい選択肢：更新連動型の表示有効性の自動化。バッジの表示を審査プログラムの適格性データに連携し、バッジの有効期限が切れた場合（再認証に失敗した場合や、しきい値を満たさなくなった場合）に、人手を介さずに表示が消えるようにします。掲載ページ上の表示方法の中では最も労力がかかりますが、表示中のバッジが常に最新であることを保証できる唯一の方法です。そのため、効率性では信頼情報ページやインライン表示に劣ります。バッジに数値で定めた失効可能なしきい値を設ける段階になったら導入してください。この方式を採用しているベンチマーク対象の認定制度では、定期的な更新サイクルが運用されています。

• マーケットプレイス外でのプロモーションバッジ（ベンダーが自社サイトに「Xで利用可能」と埋め込むもの）は、マーケットプレイス上での信頼ではなく、マーケティングのリーチを広げるものです。提供する場合は、ブランド使用ルールブックも用意してください。提供された形式をそのまま使うこと、最小限のクリアスペースを設けること、競合するバッジと同等のサイズにすること、リンクを必ず掲載することを定めます。ベンチマーク対象のバッジ仕様のうち、最も詳細なものがまさにこのルールブックです。

どの段階を選ぶにしても、絶対に守るべきルールが1つあります。**外部機関による掲載品質の認証を取得していると主張したり、そう受け取られる表現をしたりしないこと。**調査したところ、業界内にはマーケットプレイスの掲載品質を認証するISO、IAB、または同等の外部機関は見つかりませんでした。実在するプログラムはすべて運営事業者独自のものです。誠実な位置づけは、要素ごとに分けて、自社のものとして明示することです（references/decay-and-badge-programs.md）。

• アクセシビリティにはWCAGを使用します。
• セキュリティには、広く認知されたセキュリティ認証を使用します。
• コンテンツには、自社で公開した評価基準を使用します。

7. 失効への対応

アプリが変更されても掲載内容が更新されなければ、掲載内容は自然に古くなります。ベンチマーク対象の運営者はそれぞれ異なる方法で対応しており、明確な数値で更新頻度を定めて公開している運営者はいません。「N か月ごとに更新しなければ削除」とする明示的なルールがあるのは、隣接するエコシステムのみです（references/decay-and-badge-programs.md）。5 つの仕組みを順位付けすると、次のとおりです。

• 運営者の負担（高い順）：バージョン最新性の徹底 > 自動削除を伴うカレンダーに基づく更新頻度 > ポリシー違反として扱う > 古さに応じた評価引き下げ > 裁量によるモニタリング
• 確保できる鮮度：バージョン最新性の徹底 > 自動削除を伴うカレンダーに基づく更新頻度 > ポリシー違反として扱う == 古さに応じた評価引き下げ > 裁量によるモニタリング
• 効率性：古さに応じた評価引き下げ > ポリシー違反として扱う > 自動削除を伴うカレンダーに基づく更新頻度 > バージョン最新性の徹底 > 裁量によるモニタリング

==となるのは、どちらの仕組みもレビューの機会に気づいたときにのみ古さを検出するためです。違いは結果（削除のリスクか、ブラウジング時の評価引き下げか）であり、検出方法ではありません。そして、どちらの仕組みで確保できる鮮度を左右するのも検出です。

• 効率性のリーダーであり、ほかのどの仕組みを実行していても常に土台となるもの：古さに応じた評価引き下げ（メニュー 4 の分類なしのペナルティ）— 自動化でき、自己修正型で、掲載削除をめぐる争いもありません。結果は削除のリスクではなくブラウジング時の評価引き下げなので、ポリシーに取って代わるのではなく、ポリシーの下支えとして機能します。
• デフォルトの段階：この評価引き下げに、カレンダーに基づく確認を伴うポリシー違反の扱いを加えます。 「掲載内容が古いこと」を、公開ポリシーに明示的な違反事項として定め、拒否できるようにします（ベンチマーク対象の運営者 2 社が実施）。そのうえで、運営者側で独自に設定した頻度でレビューを実施します。自社のリリースサイクルに合わせ、外部から義務付けられていなくても、隣接するエコシステムの「12 か月後に自動削除」という基準を、内部で許容する鮮度 SLA の最悪ケースとして扱います。
• 見送られている選択肢：バージョン最新性の徹底 — サポート対象外のプラットフォームバージョンを対象とする新規掲載は即時に拒否し、既存の掲載については再認証時に最新状態であることを求め、明示された移行期間も設けます。ベンチマーク全体で最も体系的な仕組みである一方、最も負担が大きい仕組みでもあります。プラットフォームのリリースにバージョンが付与され、非推奨化が適切に管理されていることが前提だからです。質問 5 の答えが「はい」になった時点で、すぐにこの仕組みへ移行してください。そうすれば、リリースサイクルによって鮮度の検出を追加の負担なく行えます。
• 裁量によるモニタリング — 公開された発動条件なしに継続的にコンプライアンスを監視する仕組みです。これは選択肢ではなく最低限の対応です。運営者がポリシーを定めていないときに行うのが、この仕組みだからです。
• 削除対象であり、降格ではありません：鮮度維持の仕組みとしての料金。 ベンチマーク対象の運営者 1 社は年間掲載料を請求していますが、それによって更新されるのは掲載内容ではなく、掲載に対する課金関係です。古いスクリーンショットに違反する内容を、料金が阻止することはありません。掲載料は収益設計の一部であり、収益化モデルに属します。「料金で古さに対応する」という項目をこのメニューに残すと、内容をまったく確認していないのに、ルールブック上は失効への対応が済んでいると思い込むことになりかねません。

どの段階を選ぶ場合でも、すでに掲載されているアプリに新しいコンテンツ要件を適用する際は、発効前に告知期間を設ける必要があります。告知期間のない遡及的なルール変更は、この標準が築こうとしているパートナーとの信頼を損ないます。

失敗パターン

• ベンダーのピクセル数を業界標準として借用する。 そのような標準はありません。実運用では3種類の寸法が共存しています。対策：アセットの種類ごとに独自の寸法を選び、公開します。
• 上限のない分類体系。 どの掲載項目もあらゆるタグを主張し、ブラウズ画面での識別力が失われます。対策：メニュー4で選んだ、厳格な上限または運営者が選定するレイヤーを設けます。
• 外部の掲載品質認証を主張する。 認証機関は存在しないため、その主張はよくても検証不可能です。対策：メニュー6の構成的な位置付けを使います。
• 一度レビューしたら、その後は放置する。 劣化の仕組みがないまま一度承認された掲載項目は、購入者が先に気付くまでアプリの実態と乖離していきます。対策：最低限、メニュー7のデフォルト段階を採用します。
• 複数のレビュアーがいるのに、原則だけでルールを定める。 拒否判断に一貫性がなくなり、異議申し立てが増え、提出者はルールブックではなくレビュアーに合わせるようになります。対策：メニュー1の削除に関する論拠を採用します。
• セキュリティレビューに範囲を拡大する。 ルールブックに、レビュー工程で扱うべき権限監査や再レビューのトリガーを盛り込み始めると、両者が乖離して矛盾します。対策：コンテンツのトリガーは安全性とは独立して発動します。境界を保ち、相互参照を設けます。
• 非公開のランキングペナルティ。 任意のアセットを省略した掲載項目の順位をひそかに下げると、発覚した際に恣意的だと受け取られます。対策：ランキングでペナルティを課すなら、ベンチマーク対象の運営者と同様に、それを公開します。

測定

まず、ルールブックのゲートを設定します。基準は独自に定め、その旨を明記してください。掲載ルールブックについて業界共通の合格基準はなく、参考にできる外部認証機関もありません。以下の5項目をすべて満たすまで改善を続けます。

1. 必須項目のすべてに、提出者が提出前に自分で確認できる、客観的な却下基準がある。
2. ビジュアルアセットの種類ごとに、公開されている寸法が1つだけである。
3. 分類体系に、掲載項目ごとの厳格な上限、運営者が選定するレイヤー、またはその両方がある。
4. すべての掲載項目に、担当者と明記された結果を伴う劣化のトリガーがある。
5. 表示可能なバッジすべてに、表示場所と有効性のルールがある。

運用開始後のKPI：

• コンテンツの初回承認率。
• 掲載項目の完了率。
• 鮮度SLAを超えて古くなったカタログの割合。
• 却下理由の分布（「コンテンツが不明確」の割合が増えている場合、提出者側の問題ではなく、仕様の曖昧さを示しています）。
• 掲載内容の充実度に対するレビュー所要時間。ベンチマーク対象の運営者の1社は、掲載内容が明確であればレビューが短縮されると明言しているため、その相関関係を計測する価値があります。

掲載からインストールへの転換率に関するベンチマークは、ベンダーがマーケティング目的で報告した数値に限られます。方向性の参考にはなりますが、目標として約束できるものではありません（references/decay-and-badge-programs.md）。

ハーネスに永続メモリがある場合は、以下を記録します。

• 選択した仕様の厳格さの段階。
• 公開したメディアの寸法。
• 分類体系の上限。
• 鮮度SLA。
• 各メニューの段階と、その段階を引き上げる条件。

レビュー、オンボーディング、ローンチマーケティングの実行では、これらの判断を引き継ぎ、再度確認しないようにします。

呼び出し例

• 「来四半期、アプリのマーケットプレイスをサードパーティベンダーに公開します。掲載要件のページを作成してください。」
• 「マーケットプレイスの掲載項目の半数で、スクリーンショットが古く、サポートリンクが切れています。カタログの半分を削除せずに、この問題を解決する陳腐化ポリシーを設計してください。」
• 「パートナーが掲載の却下に繰り返し異議を申し立てています。場当たり的なコンテンツレビューを、パートナー自身が照合できる客観的な評価基準に変えてください。」