partner-app-onboarding

パートナーアプリのオンボーディング

あなたはプラットフォームプログラムの設計者です。ユーザーの B2B SaaS プラットフォームで、パートナー開発者が「パートナーとして登録」してから「初めてアプリを審査に提出する」までの道のりを設計してください。

この道のりでは、次の内容を扱います。

• 登録時のゲート
• 開発者アカウントとサンドボックスのプロビジョニング
• 教育と認定の方針
• サポートチャネル
• パートナーがどこで滞るかを示すファネルの計測

出力は、プラットフォームチームが実装し、効果を測定できるオンボーディング設計です。

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

インタビュー

何かを提案する前に質問してください。1 回のメッセージにつき 1 問とし、選択肢がある場合は選択式にしてください。回答によって、以下の各メニューで選ぶ段階が決まります。

1. パートナーは何を構築しますか？（a）マーケットプレイスアプリ（b）共通の顧客向けのプライベートなインテグレーション（c）両方。
2. 現状はどうなっていますか？（a）プログラムはなく、ゼロから設計中（b）登録の仕組みはあるが、その後の道のりは場当たり的（c）一連の道のりがすでに稼働しており、見直し中。
3. 熟練した開発者が、あなたのプラットフォームで最初に動作するアプリを作るにはどれくらいかかりますか？数時間／数日／数週間から数か月。これはゲート選択を左右する最も重要な指標です。
4. パートナーアプリが扱うデータの機微性はどの程度ですか（規制上のリスク、顧客の信頼に関わるリスク）？高／中／低。
5. パートナーはどのような人たちですか？（a）主に個人開発者や小規模チーム（b）主にあなたのプラットフォームを通じて販売する商用 ISV（c）混在。
6. 継続的に確保できるサポート体制はどの程度ですか。ドキュメント担当者、コミュニティモデレーター、パートナーマネージャーの人員などを教えてください。
7. 道のりはいつまでに稼働させる必要がありますか。厳格な期限がありますか。それとも期限は未定ですか。
8. 目標は一度きりの成功ですか（すでに構築を待っている特定のパートナーがいる）、それとも継続的に成長する資産ですか（開発者エコシステムを拡大する）。
9. 労力の上限はどの程度ですか。プロビジョニング自動化のエンジニアリング工数、教育コンテンツの予算、サポート人員数を教えてください。

質問 7～9 への回答に応じて、以下のメニューの優先順位を変更します。

• 厳格な期限がある場合、労力の少ない段階（自分で用意するアカウントのサンドボックス、ドキュメントとフォーラムによるサポート）が優先されます
• 継続的な成長を目指す場合、時間のかかる段階（資格認定を伴う教育、コミュニティプログラム）が優先されます
• 労力の上限を超える段階は、優先度を下げるのではなく、選択肢から完全に除外します

ワークフロー

1. 道のりのステージを整理し、ステージモデルを選びます。
2. 登録時のゲートを選びます。
3. サンドボックスのテナントと認証情報のプロビジョニングを設計します。
4. 教育と認定の方針を定めます。
5. サポートチャネルの段階構成を作ります。
6. 商用面の判断は後半に配置します。
7. ファネルを計測します。

各ステップの選択について、次のステップに進む前にユーザーの確認を得てください。後続の各ステップはすべて、ステップ 2 で選んだゲートを前提とします。

1. 道のりを整理する

個々のステージを設計する前に、道のりを明確な名称のステージとして書き出してください。名前のないステージには担当者も指標も割り当てられません。参照可能なモデルが 2 つあり、どちらもプラットフォームの公式資料に記載されています。

• Atlassian のオンボーディングガイド：Plan、Build、Launch、Grow の 4 段階モデル
• Salesforce の ISV 向け 7 マイルストーンの道のり

これらを採用、調整、または置き換えてください。ただし、ステージには名前を付けてください。

プラットフォームの主要な 5 つのエコシステムのうち 4 つで確認された、構造上の重要なルールがあります（プラットフォームの公式資料に基づく情報です。references/platform-archetypes.md を参照）。「開発を始める」ことと「承認を得る」ことを切り離してください。アカウント、サンドボックス、認証情報は即時かつ無料でプロビジョニングします。人による審査は、エンドユーザーを実際に保護するアプリ提出時のゲートに集中させます。

2. 登録ゲート

優先順位を付けた3段階です：

• 労力（多い順）：申請審査付き登録 > 契約分離型登録 > セルフサービス登録

• 信頼性と制御（高い順）：申請審査付き登録 > 契約分離型登録 > セルフサービス登録

• コンプライアンスコスト（高い順）：申請審査付き登録 > 契約分離型登録 > セルフサービス登録

  • 審査付きゲートでは、会社単位の契約への双方の署名と、応募者ごとの入会判断の記録が必要です。また、登録済みパートナーを除外するには契約を解除する必要があります。
  • 販売者向けの経路ではKYC/KYBの本人確認データが追加されるため、プライバシーとデータレジデンシーの審査が適用されます。ただし、対象は販売を選択したパートナーのみで、いつでも元に戻せます。
  • クリック承諾型のプログラム契約は、法務部門の承認が1回必要ですが、パートナーごとの承認は不要です。

• 効率性：セルフサービス登録 > 契約分離型登録 > 申請審査付き登録

• デフォルトの段階：セルフサービス登録。 フォームとプログラム契約へのチェックボックスだけを設け、人的な審査は介在させません。調査対象となった5つのエコシステムのうち4つが採用している登録方式です（プラットフォームの公開情報に基づく）。登録時に審査へ費やす時間はすべて、パートナーが審査に値する成果を何も生み出す前に消費されます。

• 販売者がプラットフォームを通じて取引する場合は、契約分離型登録に引き上げます。 誰もが制限なく開発できる状態を維持したまま、販売を行うための別の認証済み販売者向け経路を追加します。販売者向けの経路では、契約への署名とKYC/KYBによる本人確認を求め、制限するのは販売のみで、開発は制限しません。これは、Atlassianが2025年のマーケットプレイスセキュリティ更新で正式に定めた方式です（プラットフォームの公開情報に基づく）。

• 利用が少ない選択肢：申請審査付き登録 — あらゆるアクセスを許可する前に、人がすべてのパートナー申請を審査します（Salesforceの方式では、数日間にわたる審査があり、会社単位の契約への同意が完了するまで、すべてのユーザーがブロックされます。プラットフォームの公開情報に基づく）。登録済みパートナー1社あたりの信頼性は最も高い一方、応募者が増えるたびにコストも増えるため、効率性の比較では常に最下位になります。それでも、次のいずれかに当てはまる場合は、この方式を選択します。

  • 質問3への回答が数週間から数か月の場合：環境モデルが複雑で、ガイダンスのないパートナーは失敗するため、公開前の段階的な支援にかかる追加コストが正当化されます。
  • 質問4への回答から、データアクセスを許可する前に、誰が開発しているのかを把握する必要がある場合

このスキルで示す順位はすべてデフォルトであり、絶対的なルールではありません。それぞれを質問3〜5や、ユーザーについて把握しているその他の情報に照らして順位を見直し、どの回答によってどの段階が移動したのかを説明してください。

登録段階については、別途注意が必要です。調査対象となった5つのプラットフォームのうち4つでは、「登録段階」による制限は何もなく、実際のパートナーランクは公開後の実績に応じて決まります（プラットフォームの公開情報に基づく）。階層の深さについては、samber/developer-platform-skills@connector-marketplace-strategyを参照してください。

段階的な登録ラダーを独自に作らないでください。Salesforceの公開前のRegistered → Exploration → Buildという段階構成は、同社の開発の複雑さに基づく、公開情報で確認できる例外であり、標準として模倣するものではありません。

3. プロビジョニング

審査後ではなく、登録時にサンドボックスのテナントと認証情報を付与します。優先順位を付けた3段階です。

• 労力（多い順）：production-mirror sandboxes > instant dedicated dev tenancy > own-account-as-sandbox
• 再現性とパートナー体験（高い順）：production-mirror sandboxes > instant dedicated dev tenancy > own-account-as-sandbox
• 効率：own-account-as-sandbox == instant dedicated dev tenancy > production-mirror sandboxes

この==は本物です。own-account はほぼゼロの労力で得られるものが少なく、専用テナントはより多くの労力でより多くのものを得られます。比率は同程度です。この選択を左右するのは比率ではなく、質問4です。

• デフォルトの段階：instant dedicated dev tenancy - 登録時に作成される、無料の開発用インスタンス、ストア、またはアカウントです。期限はなく、支払い情報も不要です（Shopify と Atlassian の形式で、プラットフォームのドキュメントにも記載されています）。これが、インフラとして「開発と承認を切り離す」方法です。

• パートナーの操作が実際のテナント内で安全かつ元に戻せる場合は、own-account-as-sandbox に段階を下げます - パートナー自身のワークスペースをテスト環境として兼用し、登録から数分後には最初のアプリをそこで実行できます（Slack CLI の形式で、プラットフォームのドキュメントにも記載されています）。プラットフォーム側の労力はほぼゼロです。アプリが金銭、取り消せない操作、または他のテナントのデータに触れるようになったら、この段階を削除します。下位に残すのではなく、削除してください。安全でない選択肢を保留状態で残すと、範囲にいつの間にか再び含まれてしまいます。

• 利用が限られる選択肢：production-mirror sandboxes - 現実的なデータと規模を備えた、高忠実度のレプリカです。忠実度は最も高い一方、構築と従量管理の負担が最も大きいため、効率を比較するたびにこの段階は不利になります。情報源となる各プラットフォームでは、利用が制限されています（プラットフォームのドキュメントに記載）：

  • Slack はプロビジョニング済みのエンタープライズサンドボックスにクォータを設けています
  • HubSpot は production-mirror sandboxes を有料プランに限定しています

  パートナーのアプリを本番環境に近い動作で検証しなければならない場合に、優先度を上げます。たとえば、エンタープライズ向けのアプリやデータ量の多いインテグレーションが該当します。

分離アーキテクチャ、テスト用キーのプレフィックス、テスト用の特別な値、本番環境への移行方法は、samber/developer-platform-skills@api-test-mode-design の対象です。このステップで決めるのは、テナントをいつ付与し、どのような形式にするかであり、サンドボックスをどのように分離するかではありません。

4. 教育と認定の方針

3段階を順位付けします。

• 労力（多い順）：mandatory pre-submission certification > credentialed education loop > optional parallel track

• 初回提出の品質（高い順）：mandatory pre-submission certification > credentialed education loop > optional parallel track

• 効率：optional parallel track > credentialed education loop > mandatory pre-submission certification

• デフォルトの段階：任意の並行トラック。 初日からコースやドキュメントを利用でき、何かの必須条件にはなりません。これは調査対象の5つのエコシステムすべてに共通する方針です。認定を初回提出の条件とするものはありません（プラットフォームのドキュメントで確認済み）。品質を担保するのはレビューのゲートであり、教育はパートナーがより早く審査を通過できるよう支援するためにあります。

• パートナーの信頼性が購入者向けの訴求要素となる場合は、認定付きの教育ループに引き上げます。名称があり、提示可能な認定資格（Shopify AcademyのVerified Skillsパス、AtlassianのForge Fundamentals認定、HubSpot Academyの「Learn. Build. Certify. Repeat.」ループ。いずれもプラットフォームのドキュメントで確認済み）を提供します。ただし必須条件とはせず、一度取得して終わりではなく継続的に更新します。

• 避けるべき選択肢：提出前の必須認定。 パートナーごとの初回提出の品質は最も高く、摩擦も最大で、効率では毎回最下位です。また、大手マーケットプレイスで標準的に採用されている例はありません。提出前バリデーターがすでに存在しているにもかかわらず、初回レビューの不合格率が約30～40％を超えた状態で推移し（業界標準ではなく、各組織が独自に設定する値です）、さらに失敗分析から原因がドキュメント不足ではなくパートナーの知識不足にあると分かった場合にのみ、採用を検討します。

認定の壁に注意してください。認定制度が存在していても、ローンチ後の利用資格基準を満たす必要がある場合（HubSpotでは、認定の申請が可能になるまでに、掲載期間が6か月以上で、有効インストール数が60以上必要です。プラットフォームのドキュメントで確認済み）、パートナーはオンボーディングが完了したと思った後にその壁に気付きます。どの方針を採る場合も、ローンチ後の基準はすべてオンボーディングドキュメント内に明記し、パートナーが条件に達した時点で初めて伝えることがないようにしてください。

5. サポートチャネル

これらの段階は積み重ねていくもので、それぞれが前の段階に追加され、置き換わることはありません。

• 労力（多い順）：named partner managers > office hours > real-time community chat > docs + community forum

• 問題解決力（高い順）：named partner managers > office hours > real-time community chat > docs + community forum

• 効率：docs + community forum > real-time community chat > office hours > named partner managers

• デフォルトの段階：ドキュメントとセルフサービス型コミュニティフォーラム。 回答は蓄積され、スレッドに回答するたびに、次のパートナーからの問い合わせを減らせます。

• 同じ質問が繰り返し集まるようになったら、リアルタイムのコミュニティチャット（および定期的なタウンホール）を追加します。調査対象の中で最も大規模なセルフサービスプログラムでは、35,000人以上のパートナーが参加するチャットコミュニティを運営しています（プラットフォームのドキュメントで確認済み）。

• レビューゲートや複雑な環境モデルなど、繰り返し発生する難しい手順について、同業者ではなくプラットフォームエンジニアの回答が必要な質問が出てきたら、オフィスアワーを追加します（Salesforceは、隔週のパートナー向けオフィスアワーに加え、ケースベースのセキュリティレビュー向けオフィスアワーを実施しています。プラットフォームのドキュメントで確認済み）。 samber/developer-relations-skills@developer-office-hours-program を使って、時間枠、担当のローテーション、対象範囲を示すカードなど、プログラム自体を設計してください。

• 避けるべき選択肢：専任のパートナーマネージャー。 問題解決力は最も高いものの、人員数に応じてしか拡大できず、効率では毎回最下位です。質問5への回答が商用ISVに当てはまる場合は、そのセグメントに限って導入します。プラットフォームのドキュメントで確認済みのパターンでは、商用パートナーに専任マネージャーを割り当て、個々の開発者全員には割り当てません。

6. 商業上の判断は後回しにする

• 収益化モデルの選択は登録時ではなく、ローンチ段階まで先送りしてください。プラットフォームのドキュメントに記載されたパターンでは、掲載直前の最後の確認項目として「無料／プラットフォーム経由の有料／ベンダー経由の有料」を尋ねています。まだ開発していないアプリの価格をパートナーに決めさせると、適当に回答され、フォームへの不満を招きます。
• 基本的なプログラム契約を超える商業契約についても同様です。販売契約や流通契約は初回掲載時に結びます（これはステップ2の契約分割の項目です）。売上報告義務は初回販売時に設定します。
• ローンチ後のパフォーマンスティアや注目枠への掲載は、samber/developer-platform-skills@connector-marketplace-strategyの対象です。オンボーディングドキュメントからパートナーを案内しますが、参加開始までの手順には含めないでください。

7. ファネルを計測する

マーケットプレイスはパートナーのオンボーディングに関するコンバージョン数値を社内情報として扱うため、初日から次の4つのチェックポイントを自分で計測してください。

1. サインアップ → サンドボックス／認証情報の提供
2. 認証情報の提供 → 最初の API 呼び出し
3. 最初の API 呼び出し → 最初のアプリの申請
4. 申請 → 承認

主要指標である「最初のアプリ申請までの時間」は、実質的に自分で定義する指標です。名前の付いた指標はその前後にあります。前には「最初の API 呼び出しまでの時間」、後には「最初の取引までの時間」があります。報告する際は、自分で定義した指標であることを明記してください。定義、関連する既存のフレームワーク、根拠となる情報は、references/funnel-metrics-and-benchmarks.mdにあります。

実務上のしきい値は次のとおりです。それぞれの根拠は、同ファイルに記載されています。

• 上記のチェックポイント2が約10分を超える場合 → 何よりも先にオンボーディングの障壁を解消します。マーケットプレイスのパートナーデータではなく、一般的な開発者向けツールのファネルから得られた離脱のエビデンスでは、最初の API 呼び出しより前に最大の離脱が発生しています。
• 初回レビューの不合格率が約30～40％を超える場合 → 教育の必須化を検討する前に、申請前バリデーターを構築します（独自に設定するしきい値です）。
• 最初のアプリ申請までの時間がレビュー所要時間を大幅に上回る場合 → ボトルネックはレビュー担当チームではなく、ドキュメントと支援体制にあります。

最初の四半期を基準値として、その後も各チェックポイントのコンバージョンが四半期ごとに改善するまで一連の流れを見直してください。絶対的な合格基準は設けず、推移を計測します。

ハーネスに永続メモリがある場合は、選択した参加開始条件、提供レベル、認定方針、サポート段階、および各レベルの昇格条件を記録してください。以降の実行（レビュープロセスの設計、掲載基準、ティアの設定）では、これらの選択を引き継ぎ、再度尋ねないようにします。

失敗パターン

• 審査ゲートの先にあるサンドボックス。 構築は承認されたものの、テストできないパートナーは、その間に気づかれないまま離脱します。対策：登録時にプロビジョニングします（ステップ3）。5つのプラットフォームのうち4つがこの方式を採用しているのは、この問題がどこでも起きるためです。
• 誰も必要としない段階的な参入ラダー。 リリース前の段階モデルを、初めてのアプリまで数時間のプラットフォームにそのまま当てはめても、案内としての価値はなく、摩擦が増えるだけです。対策：ステップ2のデフォルトを率直に適用します。実際のほとんどのプログラムでは、参入ティアによって何かが制限されることはありません。
• 登録時に求められる収益化の回答。 事前の価格設定フォームは、ノイズを集め、まだ検討中のパートナーを遠ざけます。対策：ステップ6のとおり、商業上の決定はリリース時に行います。
• リリース後に待ち受ける隠れた壁。 審査の申請資格や認定に、インストール数や参加期間のしきい値が設けられていると（いずれもプラットフォームのドキュメントに記載されています。マーケットプレイスの審査開始にはアクティブなインストールが5件以上必要、認定には6か月と60件のインストールが必要）、すべて完了したと思った後でパートナーを行き詰まらせます。対策：しきい値をすべてオンボーディング資料で開示します。
• 審査ゲートでの不意打ち。 パートナーは初めて却下されてから要件を知ります。調査対象の2つのプラットフォームでは、開発者コミュニティのスレッドで、却下が2～3回繰り返され、UI 規格、データプライバシーのウェブフック、請求コンプライアンスに集中していると報告されています（開発者コミュニティからの報告）。対策：オンボーディング資料に審査チェックリストを掲載し、提出前のバリデーターを提供します。
• 門番としての認定。 コースの修了を提出条件にしても、アプリの品質ではなく、ファネルの離脱を完結させるだけです。対策：ステップ4のデフォルトに従い、品質は審査で担保し、教育は並行して行います。
• 測定されないファネル。 4つのチェックポイントがなければ、「パートナーは登録するが、何もリリースされない」原因を診断できません。対策：最初に停滞が起きてからではなく、リリース前にステップ7を実施します。

呼び出し例

• 「CRM プラットフォーム向けの開発者プログラムを開始します。パートナー登録から最初のアプリ提出までの流れを設計してください。」
• 「パートナーは登録するものの、何も提出しません。オンボーディングを監査して、どこで停滞しているのか、まず何を改善すべきかを特定してください。」
• 「パートナー登録は Salesforce のように申請審査制にすべきですか、それとも Shopify のようにセルフサービスにすべきですか。また、サンドボックスのテナンシーはいつプロビジョニングすべきですか？」

参考資料

• references/platform-archetypes.md - 各プラットフォームのオンボーディングを、参入ゲート、プロビジョニング、教育、サポート、審査段階の形状という5つの類型で説明しています。
• references/funnel-metrics-and-benchmarks.md - 指標の定義、関連する既存のフレームワーク、審査段階の所要期間、離脱の根拠、しきい値について説明しています。

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

• samber/developer-platform-skills@app-marketplace-listing-standards - 提出時にパートナーが満たす、掲載コンテンツの基準です。
• samber/developer-platform-skills@app-marketplace-monetization-model - この流れで後半に行う商業上の決定に関わる、販売者契約、手数料、支払いの仕組みです。
• samber/developer-platform-skills@developer-portal-design - この一連の流れを支えるドキュメントとポータルの画面です。
• samber/developer-platform-skills@integration-partnership-strategy - オンボーディングの前段階で、そもそもどのパートナーに働きかけるかを扱います。
• samber/developer-platform-skills@app-marketplace-launch-marketing - 創設パートナーの募集とプロモーションを扱います。この一連の流れは、募集したパートナーがその後たどるものであり、リリース日が、ここでのプロビジョニングとサポートの段階を完了すべき期限になります。

関連する別コレクション：

• samber/developer-relations-skills@developer-certification-program - ここで認定付きの教育ループを選択した後、そのパートナーエンジニア資格自体（試験形式、試験監督、更新、検証）を設計します。