app-marketplace-review

アプリマーケットプレイスのレビュー

B2B SaaS アプリマーケットプレイスを運営するプラットフォームチームのマーケットプレイス信頼性アドバイザーとして、どのサードパーティ製アプリを受け入れるか、その判断を後から再検討するきっかけは何か、どのような場合にアプリを削除するかを決める運営者側のプロセスを設計してください。成果物は、チームが担当でき、後から読む人が反証できるレビュー・プロセスの設計文書です。単発のチェックリストではありません。というのも、2024〜2026年に記録された大規模なマーケットプレイスのインシデントはどれも、悪意のある初回申請ではなく、アップデートチャネルや侵害されたパブリッシャーアカウントを経由して発生しているからです。

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

インタビュー

提案を始める前に、次の質問をしてください。1回のメッセージにつき質問は1つです。選択肢がある場合は複数選択式にしてください。回答によって、以下のメニューのどれに進むかが変わります。

1. 現在、レビュー・プロセスはどの段階ですか？（a）ローンチ前で、ゼロから設計中（b）マーケットプレイスは運用中で、レビューは場当たり的（c）正式なプロセスは存在するが、インシデントを受けて見直し中（d）正式なプロセスは存在するが、規模拡大や摩擦への対応のために見直し中。
2. 掲載アプリが最大限の権限を付与された場合、どのようなデータにアクセスできますか？（a）公開データまたはメタデータのみ（b）業務記録の読み取りアクセス。CRM、ファイル、チケット、メッセージなど（c）業務記録の読み書きアクセス（d）規制対象データ。健康、金融、個人データなど、法的責任につながる可能性のあるもの。この回答は、他のどの回答よりもレビューの深さを左右します。
3. 現在と12か月後の申請量を教えてください。月あたりの新規アプリ数とアップデート数。規模が大きくなると、レビューコストの大半をアップデートが占めます。
4. 承認後、アップデートはどのように顧客に届きますか？（a）インストール済みのテナントに自動で適用される（b）各顧客の管理者が明示的にアップグレードする。自動適用の場合、パブリッシュチャネルの強化が他のすべてに優先します。
5. マーケットプレイス戦略では、どのキュレーション段階を選びましたか？オープン、認定ティアを設けたハイブリッド、単一の厳格な審査、またはパートナーシップを通じた審査。このプロセスはその決定を実施するものであり、決定自体をやり直すものではありません（samber/developer-platform-skills@connector-marketplace-strategy を参照）。
6. 現在、誰がどのようなツールを使ってレビューしていますか？専任のセキュリティエンジニア、他業務と兼任のプロダクトエンジニア、または担当者なし。既存の SAST／DAST／シークレットスキャンの有無も教えてください。
7. マーケットプレイスは、EU に拠点を置くビジネスユーザーにもサービスを提供していますか？EU のプラットフォーム対ビジネス（P2B）規則では、掲載に関する判断に対する仲裁を求める権利がユーザーに認められています。そのため、不服申し立ての経路の段階が変わります。
8. このプロセスをいつまでに稼働させる必要がありますか？厳格な期限がありますか、それとも期限は未定ですか？
9. これは一度限りの成果ですか（ローンチを可能にする、特定の大企業との取引要件を満たすなど）、それとも複利的に価値が高まる資産ですか（価値を増す信頼プログラムなど）？
10. 労力の上限はどの程度ですか？週あたりのレビュー担当者の作業時間、自動化のためのエンジニアリング工数、開発者に負担をかけることへの許容度を教えてください。

質問8〜10があるのは、以下のメニューが、効果が出るまでの期間、持続性、必要な労力によって大きく分かれるためです。

• 厳格な期限がある場合（質問8）、方針文書としてすぐに導入できる段階が優先されます。
• 複利的な価値を求める場合（質問9）、自動化と認定ティアが優先されます。
• レビュー担当者の作業時間に厳しい上限がある場合（質問10）、一部の構成は優先度が下がるのではなく、選択肢から除外されます。

データの機密性

審査の厳格さは、アプリがアクセスできるデータの機密性に基づいて決めます。マーケットプレイスの市場、規模、歴史には基づきません。

• ビジネスデータまたは規制対象データにアクセスする：最も厳しい審査が必要です。たとえば、Salesforceでは複数週間にわたる必須のセキュリティ審査、Google Workspaceでは制限付きスコープに対するサードパーティのCASA監査が必要です。
• 消費者向けに近い、スコープが狭い、またはサンドボックス化されている（Slack、Chrome、Shopify）：機能面での審査を軽くし、公開後のスキャンを行います。

各アプリに許可するデータアクセスの最大範囲（質問2）に応じて審査の深さを段階分けし、その結果を受け入れてください。消費者向けに近いマーケットプレイスでも、アプリが制限付きスコープを持つなら、メタデータのみを読み取るB2Bマーケットプレイスより厳しく審査すべきです。プラットフォーム間の比較：references/platform-review-benchmarks.md。

ワークフロー

1. 設計の前提条件を決めます。データ機密性の段階、ボリューム予測、伝播モデル、戦略から引き継いだキュレーションの段階です。
2. 審査パイプラインの形（手順3の選択肢）と、機密性の段階ごとの審査の深さを選びます。
3. 受け入れ審査を定義します。権限監査、データアクセス審査、セキュリティテスト、機能審査のそれぞれに、自動化または人手による審査のどちらかを明記します。
4. 客観的な条件に基づいて、更新時の再審査ポリシーを設定します。
5. 公開チャネルを強化します。
6. 異議申し立ての手順を設計します。
7. 取り消しと承認後の適用措置を段階的に定めます。
8. 測定方法を設定し、「測定」のゲートに照らして文書を確認します。

この順序でセクションごとに文書を作成し、次のセクションに進む前に、各セクションをユーザーに確認してもらいます。

• 手順2で誤った機密性の段階分けに気づいた場合：修正は容易です。
• 手順7で誤った機密性の段階分けに気づいた場合：その間に作成したすべての内容を書き直すことになります。

1. 審査パイプラインの形

4つの形を効率の高い順に示します。ここでの効率とは、審査担当者の1時間あたりに検出できるリスクを指します。

• 審査担当者の申請1件あたりの作業量（多い順）：単一の厳格なゲート > 迅速審査パス付きの段階的ゲート > 2段階の審査 > 機能面のみの審査
• 購入者への信頼のシグナル：単一の厳格なゲート > 2段階の審査 > 迅速審査パス付きの段階的ゲート > 機能面のみの審査
• 効率：迅速審査パス付きの段階的ゲート > 2段階の審査 > 機能面のみの審査 > 単一の厳格なゲート

信頼と効率の順序が逆転するのは、一律の厳格な基準では、申請1件あたりに審査コストを最大限かける一方、すべての購入者に同じ保証を提供するためです。これに対し、迅速審査パスや段階的な審査では、「掲載済み」が保証する内容は「認定済み」よりも少なくなります。

• デフォルトの段階：単一の厳格なゲート — すべての申請が、完全性、コンプライアンス、スコープの最小化を含むセキュリティテスト、機能審査から成る一つの完全な基準を通過します（公開済みの審査パイプラインに基づく、SalesforceやZoomの形式です）。申請数が少なく、審査担当者の対応能力が制約要因でない場合、または質問2の答えが（c）／（d）となる場合に適しています。後者は一般的なB2B SaaSのケースで、未認定でも掲載される段階を設けると、問題が起きた際に責任を問われるのを待つような状態になります。

• 更新数の増加によって審査コストが制約要因になったら、客観的な条件に基づく迅速審査パス付きの段階的ゲートに移行します。

  • 新しいアプリとメジャーバージョンは完全な審査を行います。
  • 客観的に軽微な更新は、即時またはほぼ即時に審査を通過させます。
  • 迅速審査パスで省略する項目を補うため、継続的な自動スキャンを実施します。

  Atlassianの形式は、変更リスクに応じて審査コストを調整するベンチマーク対象のマーケットプレイスで唯一の例です。Atlassianの承認ガイドラインによると、新しいアプリとメジャーバージョンは5～10営業日、軽微なクラウド更新はセキュリティチェックを省略して即時に審査を通過します。

• 最小限の選択肢：2段階のラダー - 掲載の最低基準と、定量的なゲートを設けた任意の認定ティア（HubSpot 型）です。参入時の摩擦が最も少なく、実質的な信頼バッジも得られますが、品質の最低基準が損なわれます。「掲載」の基準がほとんどないに等しいためです。質問2の答えが（a）を超えている場合など、アプリの品質ではなく開発者の導入時の摩擦が主要なリスクとなる場合に限って推奨してください。そのようなケースはまれです。

• 機能のみの審査（自動フィードバックに加え、機能と対象範囲を人が確認し、セキュリティスキャンは必須にしない方式。Slack が公開している形）は、大規模なプロセス内のメタデータのみのティアには適切な深さですが、アプリがビジネスデータを扱うようになった段階では、マーケットプレイス全体に適用する方式としては適切ではありません。

• 削除対象であり、格下げ先ではありません：審査なしのレジストリ。 審査プロセスを求める運営者は、この方式をすでに除外しています。また、この方式が意味するゲートのない公開チャネルは、2025年に npm ワームが侵入したまさにその場所です（references/update-channel-hardening.md）。

• 段階ではなく、積み重ねるもの：エンタープライズ向けの強化信頼ティア - セキュリティ、信頼性、サポートの取り組みを毎年再検証するティア（Atlassian Cloud Fortified / Microsoft 365 Certification 型）を、既存のいずれかの基本ゲートに重ね、エンタープライズ顧客を獲得できるようにします。基本ゲートの有効性が確認できた後に追加し、基本ゲートの代わりにはしないでください。基準、テストキット、更新および認定取り消しの段階は、samber/developer-platform-skills@connector-certification-program で設計されています。

どの段階を選ぶ場合も、自動の事前スクリーニング、その後に人がトリアージする形で運用してください。これは、ベンチマークを実施した4つの運営者が独立にたどり着いたパターンです。

• チケットの振り分け： 重大および高リスクの検出結果のみを自動でチケット化します。人に回すのは、判断が必要なケースと、真に曖昧な唯一のシグナル分類だけにします（Atlassian は、誤検知を抑えるため、Ecoscanner のドキュメントによると、シークレットスキャンの検出結果のみを人による検証に回します）。
• 実施頻度： 低コストのチェックは毎日、高コストのバージョンごとのチェックはリリース時に、時間のかかるチェックは毎月実施します。
• 開発者向け事前チェックツール： 提出前に、審査担当者自身が使うツールを開発者に提供します。Microsoft は提出前に検証テストケースを再実行し、Salesforce は分析ツールによるスキャンの自己実施を義務付けています。自己スクリーニングは初回審査の不合格率に直接対処します（Salesforce のエコシステムでは、初回提出の約半数が不合格になると報告されています。これは、ISV コンサルタント会社 Aquiva Labs が伝えた Salesforce 自身の推定値です）。

この順位付けは標準設定であり、以下の選択肢もすべて絶対的なものではありません。質問2、3、5への回答と、チームがすでに保有する資産を踏まえて順位を見直してください。

• 既存の SAST パイプラインがある：自動化を1段階上げます。
• コンプライアンスの影響を受ける業種：量にかかわらず、厳格なゲートを維持します。

後続の各選択肢も、そのセクションに記載された回答を踏まえて順位を見直してください。どのインタビュー回答によって、どの段階が変わったのかを明記してください。

2. 権限とデータアクセスの監査

審査プロセスの構成にかかわらず、受け入れ審査で確認する内容は次のとおりです。

• スコープごとに明示された、最小化ルール： アプリが要求するスコープは、機能に必要なものだけに限定し、それ以上は求めません（Atlassian が定めるセキュリティ要件）。スコープごとに明示して運用します。
  • 高リスクのスコープでは、意図の申告ではなく、必要性の実証 が求められます（Shopify の番号付き要件では、read_all_orders を要求する場合、デフォルトの期間を超える注文履歴が必要な理由を示す必要があります）。
  • スコープの分類と付与側の設計については、samber/developer-platform-skills@oauth2-provider-design を参照してください。
  • この審査の目的は、アプリが実際に使う以上の権限を求めていないかを確認することです。
• 客観的な審査ティア引き上げの条件： 制限付きスコープ（メールボックス、ファイル、CRM の読み取り・書き込み）を要求する場合、または顧客データへの書き込みアクセスを求める場合、アプリを次の審査ティアに引き上げます。開発者が提出前に自己評価できるよう、この条件を明記します。
• 許可後のデータアクセスの審査： 同意後にデータがどこへ送られるか、つまり外部エンドポイント、サブプロセッサー、保持期間を確認します。シークレットの取り扱いに関する禁止事項も明示します。ソースリポジトリ、URL 文字列、ログには絶対に含めてはいけません（Atlassian がこれらのアンチパターンを明示しているのは、実際に確認されたためです）。
• 審査担当者が用いる 5 つの検証手法（Shopify が公開している方法論で、そのまま活用できます）：
  1. 禁止パターンを対象としたコードベースのスキャン。
  2. 設定とマニフェストの検査。
  3. UI/UX の検証。
  4. OAuth、課金、インストールのフローの追跡。
  5. 申告された機能に照らしたスコープの必要性の評価。

プラットフォームごとのチェックリスト、SLA、これらのプロセス内で使用するスキャンベンダーの一覧については、references/platform-review-benchmarks.md を参照してください。

3. 更新時の再レビュー方針

プラットフォーム間の違いが最も顕著で、悪用されたのもここです。意図的に選択してください。優先順位順に3段階あります。

• 負担（レビュアーと開発者の負担、重い順）：定期的な期限切れ時の再レビュー > 無条件の再認証 > 客観的な軽微更新の迅速処理
• 更新チャネルの脆弱性への対処：無条件の再認証 == 継続的なスキャンを伴う客観的な迅速処理 > 定期的な期限切れのみ
• 効率：客観的な迅速処理 > 無条件の再認証 > 定期的な期限切れ

==となるのは、どちらもリスクのある変更をすべて再検査するためです。一方はすべてを低コストで再確認し、もう一方は客観的なリスク要因に該当する場合にのみ完全なレビューを実施し、それ以外をスキャンでカバーします。定期的な期限切れだけでは、サイクルの間に数か月分の未レビュー更新が残ります。

• デフォルトの段階：客観的な軽微更新の迅速処理。 通常のバージョン更新では再承認を省略します。客観的な基準（Atlassian が公開しているトリガー一覧）に該当する場合にのみ、完全な再レビューを再実施します。

  • 新しい OAuth スコープ。
  • 新しい外部エンドポイント。
  • データ処理の変更。
  • 料金モデルの変更。
  • 新しいアプリ種別。

  客観的であるとは、開発者が提出前に自己評価できることを意味します。すべてのリリースで自動スキャンを実施してください。そうしなければ、迅速処理が隙間になります。

• 無条件の再認証に引き上げるのは、低コストを維持できる決定論的な自動テストスイートがすでにある場合です。Microsoft Teams は認証後の変更ごとに再認証を行い、テストレポートが24営業時間以内に提出されるからこそ、実行可能な状態を保っています（Microsoft Learn）。

• 優先度の低い選択肢：定期的な期限切れ — コードに変更がなくても、承認が期限切れとなり再レビューが実施されます（Salesforce の期限付き承認、Google の年次 CASA 再検証）。レビュー対象となる変更単位あたりの負担が最も大きいため、効率性の観点では常に劣ります。ただし、更新を一度もリリースしないアプリのドリフトを検出できるのは、この段階だけです。デフォルトの段階に対する年1回の最低基準として、制限付きスコープの階層にのみ適用してください。

• 降格ではなく削除：制約上、採用できない2つの方式。

  • _主観的な_トリガー（「大幅な変更」など、定義されていないもの）では、開発者は自己評価できず、いつの間にか再提出されなくなります。
  • _ゲートなしで即時に自動反映される_更新は、2024～2026年の主要なインシデントすべてで使われたことが記録されているチャネルです（references/update-channel-hardening.md）。

  プラットフォーム間のトリガーの詳細：references/rereview-and-appeal-policies.md。

4. 公開チャネルの強化

記録されている2024〜2026年のインシデントは、いずれも侵害された公開者の認証情報か、保護されていない更新チャネルを悪用していました。フィッシングで公開者のOAuthグラントを奪い、侵害されたChrome拡張機能を配信した事例、自己複製するnpmワーム、窃取した公開者の認証情報を使って拡散するエディター拡張機能ワームです。悪意のある初回投稿も依然として発生しています。エディターマーケットプレイスへのなりすまし投稿は、インストール数が一桁のうちに数時間で削除されました。しかし、被害の大きかったインシデントで、そこから始まったものはありません。

各インシデントの出典はreferences/update-channel-hardening.mdに記載しています。どのインシデントによって審査プロセスが実際に変更されたか、また、どのような帰属が憶測に当たるかも含まれています。初回審査をさらに強化する前に、コードを顧客に届けるチャネルを強化してください。優先順位順の5つの対策は次のとおりです。

• 労力（大きい順）：インストール時に署名済みアーティファクトを強制 > OIDCによる信頼された公開 > 配布保留 > 有効期間の短い公開トークン > フィッシング耐性のある公開者向け2FA

• 効率：フィッシング耐性のある公開者向け2FA > 有効期間の短い公開トークン > 配布保留 > OIDCによる信頼された公開 > インストール時に署名済みアーティファクトを強制

• 基本対策：公開者アカウントでのフィッシング耐性のある（FIDO）2FAと、有効期間が短くスコープを限定した公開トークンの併用（2025年のワームの発生後にnpmの運営元が導入したモデルです。デフォルトは7日、トークンの有効期間は最大90日です。出典：GitHub公式ブログ）。実際に悪用された認証情報窃取の経路を塞ぎます。

• 配布保留： 更新の審査完了から自動配布まで24〜48時間の保留期間を設け、その期間内にキルスイッチを使えるようにし、セキュリティ修正には迅速化の経路を用意します。質問4への回答が「自動配布」の場合は、必須対策に格上げしてください。こうした保留の欠如こそ、ゲートのないストアに関してサードパーティのサプライチェーン分析で指摘されている、記録済みのギャップです。

• OIDCによる信頼された公開をCI/CDに導入し、長期有効な認証情報を完全に置き換えます。トークン管理だけでは統制できないほど公開者が増えたら、この対策を推奨してください。

• 優先度を下げる対策：インストール時に署名済みアーティファクトを強制。 運営元とクライアント双方で最も多くのエンジニアリング作業が必要となるため、効率を基準とした優先順位では常に最下位になります。しかし、公開パイプラインが完全に侵害されても有効な唯一の対策です。クライアントが自動更新コードを実行する場合（拡張機能型のランタイムなど）には、この対策を推奨してください。これを導入しているベンチマーク対象の運営元は、インストール時に署名を検証しています（出典：Microsoftのマーケットプレイスセキュリティブログ）。

これらの対策は重ねて適用してください。1つだけに頼ってはいけません。独立系の研究者は2025年、ベンチマーク対象のマーケットプレイスが公開していた対策を実際に回避できることを実証しました（Wiz、Mazin Ahmed）。公開されている対策にも、実環境ではギャップがあります。

5. 異議申し立ての経路

異議申し立ての経路を設けるかどうかは、意図的な設計上の選択です。ベンチマーク対象の8つのマーケットプレイスのうち6つは、修正して再提出する方法以外に何も提供していません（references/rereview-and-appeal-policies.md）。4段階を、次の順位で示します。

• 労力（降順）：ダッシュボードに統合された異議申し立て > 人による審査が定められた異議申し立て > エスカレーション窓口 > 修正して再提出する方法のみ

• 開発者の手間と規制上のリスクの軽減：ダッシュボードに統合された異議申し立て > 人による審査が定められた異議申し立て > エスカレーション窓口 > 修正して再提出する方法のみ

• 効率性：人による審査が定められた異議申し立て > ダッシュボードに統合された異議申し立て > エスカレーション窓口 > 修正して再提出する方法のみ

• 標準の段階：対応期限を明示した、人による審査が定められた異議申し立て。再提出とは明確に区別します。元の決定を下していない人が案件を審査する、担当者が明確なプロセスです（Shopifyはこの保証を文書で明示しています）。導入にかかる費用はわずかです。文書化された窓口、決定の独立性に関するルール、対応期限の約束を用意します。どの段階を採用する場合でも必要な前提条件は、却下のたびに違反したポリシーを具体的に示すことです。そうしなければ、異議申し立てで反論する対象がありません。

• 修正して再提出する方法のみが許容されるのは、ローンチ前で件数がごく少ない場合に限ります。これを選ぶ場合は、より上位の段階に移行する日付を文書に記載してください。

• エスカレーション窓口やオフィスアワー（パートナーが指摘事項について話し合うセキュリティポータル、コンプライアンス上の懸念を伝える窓口）はガイダンスであり、決定に対する独立した再審査ではありません。決して異議申し立てと呼ばないでください。

• 不足している選択肢：ダッシュボードに統合された異議申し立て。却下画面に異議申し立てボタンを設け、違反内容を事前入力し、対応期限を明示して人が審査する方式です（Chrome Web Storeのモデルです。開発者からは、対応に1～2週間かかるとの報告があります）。構築の労力は最大ですが、ボタンと事前入力の実装は、それを支える人による審査に比べれば小規模です。そのため、効率性では定められた異議申し立てにのみ劣り、再審査を何も行わないエスカレーション窓口は上回ります。EUを対象とするマーケットプレイス（P2Bの調停リスクがある場合）、または異議申し立て件数が増え、専用ツールが必要になった場合は、この方式に移行します。

6. 承認後の取り消しと執行

承認後のセキュリティは、一度きりの審査ではなく、継続的なプログラムです。次の4点を記載します。

1. 深刻度別の執行段階を設け、各段階に担当者と開発者への通知期間を定めます。

   1. 問題の指摘。
   2. 深刻度に応じた修正期限。
   3. リスティングの非表示。
   4. 新規インストールの停止。
   5. トークンの取り消し／キルスイッチ。
   6. リスティングの削除と、影響を受ける顧客への通知。

   これらの段階に効率性の順位を設けていないのは意図的です。どの段階を適用するかは、運営者の労力予算ではなく、深刻度と開発者の対応によって決まります。適用する段階のないルールは、ポリシーではなく単なる希望です。

2. 段階的な執行につながる、継続的な問題発見の窓口を設けます。各パートナーにセキュリティ連絡先を義務付け、インシデント報告窓口を用意し、内部スキャン、情報開示プログラム、そしてプログラムの成熟に応じてバグバウンティを通じて脆弱性を発見します。ベンチマーク対象の運営者のうち、最も透明性の高い事業者は、この3つすべてを同時に実施しています。

3. 単一アプリの却下とは別に、パブリッシャー単位で段階的に執行します。品質の低い提出を繰り返す、または応答しない提出者には、パートナー単位で段階的な措置を適用します（Shopifyは、対応されない審査のやり取りが繰り返されると、パートナーを停止します）。問題のあるアプリと悪意のあるパブリッシャーは、別の問題です。

4. すでに掲載されているアプリに適用する新要件には、周知期間を設けます。ベンチマーク対象での基準は、新要件の発効までに少なくとも6か月の猶予を設けることです（AtlassianのCloud Fortifiedプログラムのドキュメント）。十分な猶予のない遡及的なルール変更は、審査プログラムが築こうとしているパートナーからの信頼を損ないます。

失敗パターン

• 正面の入口を守り、裏口を開けたままにする。 初回は厳重に審査しても、更新に審査を設けない場合、2024～2026年に見られたインシデントのパターンそのものです。対策：ステップ1を深める前に、ステップ3～4に取り組みます。
• 主観的な再審査のトリガー。 「大幅な変更」は、各自で判断できないため、再提出されないまま形骸化していきます。対策：客観的なトリガーのリストを用意します。
• インシデントの原因を審査に過剰に帰属させる。 サードパーティ製アプリの侵害が、必ずしも審査の失敗とは限りません。運営者自身が明言している場合にのみ、因果関係のあるプロセス変更を主張します（references/update-channel-hardening.mdに実務上のルールが記載されています）。審査で防げなかったインシデントを受けて審査のゲートを再設計しても、労力を誤った対策に費やすことになります。
• 件数が増えても審査の深さを一律に保つ。 審査担当者の負荷が制約になった後も単一の厳格なゲートを維持すると、数週間に及ぶ滞留と開発者の離脱を招きます。SLA のないマーケットプレイスに関するベンチマークでは、まさにこうした不満が各マーケットプレイスのフォーラムで寄せられています。
• トリアージ設計のない自動化。 すべてをスキャンしてチケットを作成すると、審査担当者がさばききれなくなります。重大度がクリティカルまたは高のものだけを自動でチケット化し、本当に判断が難しいシグナルの種類だけを人に回します。
• 実質的には再提出である異議申し立て。 オフィスアワーを異議申し立てと呼ぶと信頼を損ない、EU 向けマーケットプレイスでは P2B に関するリスクも解消されません。

測定

審査プロセスの設計には業界標準の合格基準がないため、まず設計文書のゲートを自分で設定します。次の4項目すべてを満たすまで反復します。

1. すべての審査ティアに、開発者が自分で判断できる客観的なエスカレーションのトリガーがある。
2. 「軽微な更新」が客観的な基準で定義されている。新しいスコープ、外部エンドポイントの追加、データ取り扱いの変更がないこと。
3. すべての措置段階に、担当者、通知期間、および措置を発動する証拠が明記されている。
4. 公開チャネルに少なくともデフォルトの管理措置段階が適用されており、更新が自動的に反映される場合は、反映を保留する措置も適用されている。

運用開始後の KPI：

• 初回審査の承認率（ベンチマークとなる最低ライン：最も厳格なゲートでは、初回提出の約半数が不合格になるという Aquiva Labs 経由の Salesforce の推定値）。
• 公開済み SLA に対する初回判断までの時間。
• 迅速審査で承認される更新の割合。
• 異議申し立てが覆る割合。
• 四半期ごとの承認後のセキュリティ上の指摘件数、および SLA に対する修正までの時間。
• 自動スキャンの誤検知率（誤検知が増えると、審査担当者は気づかないうちにスキャナーを無視するようになります）。

ハーネスに永続メモリがある場合は、選択したパイプラインの構成、機密性ティアのトリガー、「軽微な更新」の定義、各メニューの措置段階とその昇格条件を記録します。オンボーディング、掲載、収益化の実行時には、これらの判断を引き継ぎ、再度確認する必要がないようにします。

呼び出し例

• 「来四半期に CRM のアプリマーケットプレイスを立ち上げます。サードパーティ製アプリのセキュリティ審査プロセスを設計してください。」
• 「アプリの審査に6週間かかり、パートナーが激怒しています。更新チャネルを再び無防備にせず、どこに迅速審査を導入できますか？」
• 「インストール済みのアプリが自動更新を通じて顧客データを漏えいさせました。同じことが起きないよう、再審査と失効のポリシーを書き直してください。」

参考資料

• references/platform-review-benchmarks.md - 8 つのプラットフォームの比較：パイプラインの構成、SLA、審査チェックリスト、審査チームの設計、具体的なスキャンベンダー。
• references/update-channel-hardening.md - 出典を明記した 2024～2026 年のインシデント（確認済みのプロセス変更と、変更元が明らかでないものを区別）と、公開チャネルの詳細な制御項目。
• references/rereview-and-appeal-policies.md - プラットフォームごとの再審査のトリガーと異議申し立ての段階、および客観的なトリガーと主観的なトリガーの対比。

同じコレクションの関連項目：

• samber/developer-platform-skills@connector-marketplace-strategy - このプロセスで適用するキュレーションの段階を選定します。マーケットプレイスの厳格さが未決の場合は、先に実行してください。
• samber/developer-platform-skills@oauth2-provider-design - スコープの分類と、同意を付与する側を担当します。このスキルの権限監査では、その分類に照らしてアプリを確認します。
• samber/developer-platform-skills@partner-app-onboarding - ここで設計する審査を通過する提出者の流れです。ドキュメント、サンドボックスのテナンシー、認定手順を扱います。
• samber/developer-platform-skills@app-marketplace-listing-standards - リスティングコンテンツのルールと、コンテンツ品質を理由とする却下を扱います。掲載可否はこちらで判断し、バッジ表示はあちらで扱います。
• samber/developer-platform-skills@app-marketplace-monetization-model - 課金と収益分配の仕組みを扱います。決済モデルの変更はここで再審査のトリガーとなり、その設計はあちらで扱います。
• samber/developer-platform-skills@app-marketplace-launch-marketing - 審査済みのコホートとして売り出すローンチおよびプロモーションプログラムです。ここで設計する審査を通じて、その主張が真実になります。そのため、審査が実施されていないマーケットプレイスがそのように謳うことはできません。