Teams ストアにアプリを発行する
アプリをMicrosoft Teams内のMicrosoft Teams ストアに直接発行し、世界中の何百万人ものユーザーにアクセスできます。 アプリが Teams ストアにも表示されている場合は、潜在的な顧客にすぐにアクセスできます。
Teams ストアに発行されたアプリは、Microsoft 365 アプリとソリューション の公式マーケットプレースである Microsoft コマーシャル マーケットプレースにも自動的に一覧表示されます。
Teams アプリを Teams ストアに発行する方法に関する次のビデオでは、アプリの発行プロセスに関連する手順について説明します。
公開プロセスを理解する
アプリが運用環境の準備ができている場合は、Teams ストアに一覧表示するプロセスを開始できます。
ヒント
提出前の手順に厳密に従うことで、Microsoft がアプリの公開を承認する可能性が高くなります。
Teams ストアの検証ガイドラインを確認して、 アプリが Teams アプリと Teams ストアの標準を満たしていることを確認します。
自動テストの実行、テスト ノートのコンパイル、Teams ストアの登録情報の作成など、レビュー プロセスの迅速化に役立つその他の重要なタスクを含む、Teams ストアの申請を準備します。
パートナー センターからアプリを送信します。
送信に失敗した場合は、Microsoft に直接連絡して問題を解決し、アプリを再送信してください。
アプリを送信した後、何を期待しますか?
機能とエクスペリエンスの詳細なテスト
アプリは公開審査を行うチームによって徹底的にレビューされ、Microsoft Commercial Marketplace の認定ポリシーに準拠していることを確認します。 詳細な機能とユーザー エクスペリエンスのテスト、使いやすさチェック、メタデータ チェックに重点を置きます。 アプリの検証は、デスクトップ、Web、およびモバイル クライアント間で実行されます。 提出後の 24 時間勤務で詳細なテスト レポートを提供できるよう努めます。
コンシェルジュ サービスによるアプリ公開の案内
アプリで問題が発生しない場合は、アプリが承認され、Teams ストアに発行されます。 一方、問題が存在する場合は、エラーの詳細を含む自動検証レポートをパートナー センターから受け取ります。 アプリを Teams ストアに正常に発行し、このプロセスをガイドするために、検証チームは、次の情報を含む、当社のコンシェルジュ サービス teamsubm@microsoft.com からパーソナライズされた電子メールを送信します。
すべての問題のサマリー
ポリシー リンクと分類に関するエラーまたは問題の詳細:
修正する必要がある: 問題は、アプリの承認前に修正する必要があります。
適切な修正: 問題はアプリのエクスペリエンスを向上させるための推奨事項であり、アプリの承認後に問題を修正できます。
ブロッカー: これらの問題により、審査チームはアプリの機能をこれ以上テストできないので、検証を続けるために解決する必要があります。
クエリ: クエリを共有して、アプリに関連する特定の質問への回答を得ることができます。
書面による指示またはビデオ形式で問題を再現する手順。
ガイダンス ドキュメントへのリンクを使用して、報告された問題を修正するための推奨事項。
問題のリストを確認したら、報告されたすべての問題を修正し、更新されたアプリ パッケージをメールで共有して、審査チームがアプリを徹底的に再検証できるようにします。 報告された問題に関連するクエリがある場合は、 teamsubm@microsoft.comの検証チームにお問い合わせください。
アプリに残っている問題や回帰の問題が発生した場合、検証チームは更新された検証レポートを共有します。 アプリにブロッカーが含まれている場合、ブロッカーが解決された後にアプリが検証されると、新しい問題が報告されることがあります。 審査チームは、修正の展開後のアプリのリグレッションの問題にも気付くことがあります。 バグで構成されるアプリのすべての問題を終了し、Teams ストアへの発行を承認するには、いくつかの再送信が必要です。
報告されたすべての問題が閉じられ、最終的な申請がパートナー センターで行われた後、検証チームはアプリを承認して発行します。 Teams ストアでアプリを使用できるようにするには、少なくとも 1 営業日を許可します。
アプリの使用状況を分析する
アプリが承認されて発行されたら、パートナー センターの Teams アプリ使用状況レポート でアプリの使用状況を追跡できます。 メトリックには、月間、日単位、週単位のアクティブ ユーザー、リテンション期間と強度のグラフが含まれており、チャーンと使用量の頻度を追跡できます。
新しく公開されたアプリのデータがレポートに表示されるまでに約 1 週間かかります。
迅速に承認を得てアプリを公開するヒント
設計フェーズ中
アプリのライフ サイクル (設計フェーズ) の早い段階で Teams ストアの検証ガイドライン を確認し、Teams ストアの要件に合わせてアプリをビルドすることを確認します。 これらのガイドラインに従ってアプリをビルドすると、Teams ストア ポリシーに準拠していないことによる手直しが防止されます。
アプリ提出の前に
事前に余裕をもってパートナー センター アカウントを作成します。 パートナー センター アカウントで問題が発生した場合は、サポート チケットを作成します。
Teams ストアの検証ガイドラインをもう一度確認して、アプリが Teams ストアの要件と一致していることを確認します。 レビューにより、アプリで観察される問題の数が減り、その結果、アプリの承認にかかる時間が短縮されます。
アプリをテストして再テストします。
Teams 開発者ポータルを使用してアプリ パッケージを検証し、パッケージ エラーを特定して修正します。
アプリの提出前にアプリを徹底的に自己テストして、Teams ストア ポリシーに準拠していることを確認します。 Teams でカスタム アプリをアップロードし、アプリのエンド ツー エンド ユーザー フローをテストします。 機能が期待どおりに機能し、リンクが壊れていないこと、ユーザー エクスペリエンスがブロックされていないこと、制限事項が明確に強調されていることを確認してください。
デスクトップ、Web、モバイル クライアント間でアプリをテストします。 アプリがさまざまなフォーム ファクターで応答することを確認します。
アプリ提出の準備をするときは、チェックリストに従い、提出パッケージの一部として次の詳細を含めます。
徹底的に検証されたアプリ パッケージ。
アプリの機能をテストするための管理者および非管理者のユーザー資格情報 (アプリがプレミアム サブスクリプション モデルを提供している場合)。
アプリの機能とサポートされているシナリオの詳細を説明するテスト手順。
アプリの機能にアクセスするためにさらに構成が必要な場合は、手順を設定します。 または、アプリで複雑な構成が必要な場合は、プロビジョニングされたデモ テナントに管理者アクセスを提供して、公開審査を行うチームが構成手順をスキップできるようにすることもできます。
アプリの主要なユーザー フローを示すデモ ビデオをリンクすることをお勧めします。
アプリ提出を投稿する
検証レポートを確認したら、検証レポートに関連するすべてのクエリを含む電子メール スレッドに返信するか、報告された問題を解決するために追加のサポートが必要な場合は、返信します。
アプリが承認されるまで、報告された問題を解決するのに十分な開発者帯域幅があることを確認してください。
さらにテストするためにアプリ パッケージを共有する前に、コンシェルジェ サービス teamsubm@microsoft.comによって報告されたすべての問題が解決されていることを確認します。 これにより、アプリの検証に必要な反復回数を減らし、その結果、アプリの承認にかかる時間を短縮できます。
検証プロセス中にアプリの機能を変更しないようにします。これにより、新しい問題が検出され、アプリの承認にかかる時間が長くなる可能性があります。
SaaS オファーにリンクされたアプリを公開するための迅速な承認に関するその他のヒント
設計フェーズ中
アプリのライフ サイクル (設計フェーズ) の早い段階で 、リンクされた SaaS オファーで公開されたアプリに固有の Teams ストア検証ガイドライン を確認して、 SaaS オファーにリンクされた Teams アプリに適用される Teams ストアの要件と Microsoft Commercial Marketplace ポリシーに合わせてアプリを構築することを確認します。 これらのガイドラインに従ってアプリをビルドすると、Teams ストア ポリシーへの準拠が不一貫性のため、再作業が防止されます。
アプリ提出の前に
アプリの提出を準備するときは、次の詳細を確認します。
アプリは、AppSource のライブ (既に公開されている) SaaS オファーにリンクされており、価格情報を含む少なくとも 1 つのプランがあります。
アプリ マニフェスト (以前は Teams アプリ マニフェスト) の
subscriptionOfferの詳細については、publisherId.offerId形式で正しく説明しました。リンクされた SaaS オファーが、 SaaS 価格モデルに割り当てられたライセンスをサポートするように設計されていることを確認する必要があります。
テスト手順またはセットアップ手順を含めるか、アプリの機能とサポートされているシナリオの詳細を示すデモ ビデオへのリンク、およびテスターが SaaS ポータル ワークフローを簡単に理解できるようにするための追加情報を含めます。
検証のために SaaS オファーにリンクされたアプリを送信する前に、エンド ツー エンドの購入とライセンス管理ワークフローを徹底的に 自己テスト する必要があります。次の詳細を確認してください。
管理者ユーザーと非管理者ユーザーの両方が注文を行い、サブスクリプションの購入を確認できます。 購入者は、Microsoft 管理 センターで [今すぐセットアップ] を選択することで、SaaS アプリケーションのランディング ページに移動できます。 購入者が SaaS アプリケーションでサブスクリプションをアクティブ化および構成できることをテストして確認します。 SaaS アプリケーションでのメッセージングは、購入者の道のりについて十分かつ明確な情報を提供する必要があります。
Microsoft 管理センターの [サブスクリプションの管理] セクションには、テスト ユーザーによって提供されたサブスクリプションの正しい詳細が表示されます。 サブスクリプションの状態、ライセンスの数、およびその他の詳細は正確である必要があります。
ライセンス ワークフローの購入と削除は期待どおりに機能しています。 購入者が Microsoft 管理センターからライセンスの数を増やすことができることを確認します。 SaaS アプリケーションのライセンス数と割り当てが、それぞれのライセンスと適切な担当者を反映していることを確認してください。 また、SaaS アプリケーションがユーザーからライセンスを取得する方法を提供していることを確認します。 ライセンスの削除後、残りの割り当てとカウントが SaaS アプリケーションにそのまま残り、正しい詳細が Microsoft 管理センターに反映されていることを確認します。
サブスクリプションのキャンセルは期待どおりに機能しています。 購入者はサブスクリプションをキャンセルできます。 Microsoft 管理 センターと SaaS アプリケーションのキャンセル後に、正しいサブスクリプションの状態が反映されているかどうかを確認します。 キャンセルが成功した後、購入者がサブスクリプションにアクセスできなくなったことを確認します。
サブスクリプションの再購入はシームレスです。 アクティブなサブスクリプションをキャンセルした後、購入者がサブスクリプションを再購入できることを確認するために徹底的にテストします。
購入者は、サブスクライブしたプランを変更できます。 プランが変更された後、ユーザーはアップグレードまたはダウングレードされたプラン機能にアクセスできます。
SaaS アプリケーションには、ライセンス管理機能が含まれています。 購入者は、使用可能なライセンスをユーザーに割り当て、変更、および再割り当てできる必要があります。 購入者がライセンスを管理するためにユーザーを追加または削除できるかどうかを確認します。
最小ライセンス購入フローと一括ライセンス購入フローの両方が期待どおりに機能していることをテストして確認する必要があります。
ライセンスが割り当てられているユーザーが、プランのリストに記載されている正確な購入済みプランの機能にアクセスできるようにする必要があります。
Teams ストアの検索エクスペリエンス
アプリが Teams ストアに発行されると、ユーザーは Teams の左側のウィンドウから [アプリ ] アイコンに移動してアプリを見つけることができます。 ユーザーは、左上隅の検索ボックスを使用するか、カテゴリ別に参照して、特定のアプリまたはプログラムに Teams のバージョンがあるかどうかを確認できます。
Teams では、ユーザー入力を appName、発行元名、短い説明、長い説明、アプリ マニフェストまたはパートナー センターの特定のキーワードとカテゴリ名の間で開発者が提供するフィールドと照合することで、インテリジェントな検索エクスペリエンスを提供します。 検索結果には、ユーザーの指定した文字に最も近いアプリが表示されます。
トレーニング モジュール
| トレーニング名 | 説明 |
|---|---|
| Microsoft Teams ストアで Teams アプリを発行する | このトレーニング モジュールでは、アプリを Teams ストアに発行する方法について説明します。 主にアプリの検証プロセスに焦点を当てています。 |
関連項目
Platform Docs