次の方法で共有


Teams ストア検証ガイドライン

これらのガイドラインに従って、アプリが Microsoft Teams Store 申請プロセスに合格する可能性が高くなります。 Teams 固有のガイドラインは、Microsoft コマーシャル マーケットプレース認定ポリシーを補完するものであり、新機能やユーザー フィードバック、ビジネス ルールの変更を反映して頻繁に更新されています。

注:

  • 一部のガイドラインは、アプリに適用できない場合があります。 たとえば、アプリにボットが含まれていない場合は、ボット関連のガイドラインを無視することができます。
  • これらのガイドラインを Microsoft の商用認定ポリシーに相互参照し、検証プロセスで発生した合格または不合格のシナリオの例を示す「やるべきこと」と「やってはいけないこと」を追加しました。
  • 特定のガイドラインは[ 修正が必要] としてマークされています。 アプリの申請がこれらの必須のガイドラインを満たしていない場合は、Microsoft から改善のための手順を示すエラー レポートが送信されます。 アプリの申請は、問題を修正した後にのみ Teams ストアの検証に合格します。
  • その他のガイドラインは、 修正に適したとマークされています。 理想的なユーザー エクスペリエンスを得るには、問題を修正することをお勧めしますが、問題を解決しないことを選択した場合、アプリの申請は Teams ストアでの発行をブロックされません。

価値提案

このセクションは 、Microsoft の商用認定ポリシー番号 1140.1 に沿っており、オファーの価値提案に関するMicrosoft Teams アプリの開発者に対してより多くのガイダンスを提供します。

アプリは、ユーザーが繰り返し使用する機能ワークフローを完了できるようにすることで、ユーザーに価値を提供する必要があります。 次のセクションを展開して、価値提案の詳細を確認します。

タブ

タブは、既存の Web サイトをホストする以上の価値を提供するものである必要があります。 [修正する必要があります]

図は、チーム内のチャネル メンバーにとって重要なワークフローを持つアプリの例を示しています。

グラフィックは、戻るオプションのない I フレーム内の Web サイト全体を含むアプリの例を示しています。


通知ボット 通知は、次の場合に Teams で値を提供します。
  1. 投稿されたカードやテキストにより十分な情報が提供されており、ユーザーが追加で操作する必要がない。
  2. 投稿されたカードやテキストが、ユーザーがアクションを起こすべきか、あるいはTeams 外部のリンクを開いて詳細を確認すべきかを判断するのに十分なプレビュー情報が提供されている。

などのコンテンツを含む通知のみを提供するアプリ。 新しい通知 または クリックして表示し、他のすべてのユーザーが Teams 内で重要な価値を提供しないように Teams の外部に移動するようにユーザーに要求します。

スクリーンショットは、プレビューで情報が不十分な通知のみの例を示しています。


メッセージ拡張機能

[修正する必要があります]

検索ベースのメッセージ拡張機能により構成されるアプリは、コンテキストの切り替えなしでコンテキストに沿った会話が可能なカードを共有することで、ユーザーに価値を提供します。

検索ベースのメッセージ拡張機能専用アプリの検証に合格するには、ユーザー エクスペリエンスが壊れないようにするためのベースラインとして、以下の項目が必要です。 メッセージ拡張機能を介して共有されるカードは、次の場合に Teams に価値を提供します。

  1. 投稿されたカードにより十分な情報が提供され、ユーザーが追加で操作する必要がない。

  2. 投稿されたカードが、ユーザーがアクションを起こしたり、Teams 外部のリンクを開いて詳細を表示ことを決定するのに十分なプレビュー情報を提供している。

    validation-search-base-messaging-ext-adequete-info

    validation-search-base-messaging-ext-inadequete-info


リンク解除

リンク展開のみが提供されるアプリでは、Teams 内で十分な価値が提供されません。 アプリがリンク解除のみをサポートし、他の機能がない場合は、アプリでより多くのワークフローを構築することを検討してください。


先頭に戻る

アプリ名

[修正する必要があります]

このセクションは、Microsoft の商用認定ポリシー番号 1140.1.1 に沿っており、開発者にアプリの名前付けに関するより多くのガイダンスを提供します。

詳細を知るために展開する

アプリの名前は、ユーザーが Teams ストアでアプリを検出する方法において重要な役割を果たします。 次のガイドラインを使用してアプリの名前を指定します。

  • 名前には、ユーザーに関連する用語を含める必要があります。 [修正する必要があります]

  • 開発者の名前を普通名詞の接頭辞または接尾辞として含める。 たとえば、タスクではなく Contoso タスクがこれにあたります。 [修正する必要があります]

  • Teams やその他の Microsoft 製品の名前 (Excel、PowerPoint、Word、OneDrive、SharePoint、OneNote、Azure、Surface、Xbox など) ブランド提携や共同販売を誤って示す可能性のあるので使用することはできません。 Microsoft ソフトウェア、製品、およびサービスの参照に関する詳細については、「Microsoft の商標およびブランドに関するガイドライン」を参照してください。 [修正する必要があります]

  • Teams ストアまたはコマーシャル マーケットプレースの他のオファーに一覧表示されているアプリの名前をコピーしないでください。 [修正する必要があります]

  • 卑猥な言葉や軽蔑的な言葉を含んではいけません。 また、人種的または文化的に区別されない言語を含めることはできません。 [修正する必要があります]

  • 一意である必要があります。 アプリ (Contoso) が Teams ストアと Microsoft AppSource に一覧表示されていて、Contoso Mexico などの地域に固有の別のアプリを一覧表示する場合、申請は次の条件を満たす必要があります。

    • タイトル、メタデータ、最初の応答アプリ エクスペリエンス、ヘルプ セクションでアプリの地域固有の機能を呼び出します。 たとえば、タイトルは「Contoso Mexico」でなければなりません。 アプリのタイトルは、エンド ユーザーの混乱を避けるために、既存のアプリと同じ開発者を明確に区別する必要があります。 [修正する必要があります]
    • パートナー センターでアプリ パッケージをアップロードする場合は、[可用性] セクションでアプリが使用できる適切な市場を選択します。 [修正する必要があります]
  • アプリ名は、チャット、連絡先、予定表、通話、ファイル、アクティビティ、Teams、ヘルプなどの主要な Teams 機能を使用しないでください。 アプリ名は、左側のナビゲーションで[チャット]、[連絡先]、[予定表]、[通話]、[ファイル]、[アクティビティ]、[Teams]、[ヘルプ] のいずれかに短縮されません。 [修正する必要があります]

  • アプリが Microsoft との公式パートナーシップの一部である場合は、アプリの名前を最初に持ってくる必要があります。 たとえば、"Contoso コネクタ Microsoft Teams 用" などです。

  • アプリ名には、Microsoft または Microsoft 製品への参照を含めることはできません。 アプリが Microsoft と公式に提携している場合を除き、アプリ名で Teams または Microsoft を使用しないでください。 公式パートナーである場合、Microsoft を言及する前にアプリ名を先に持ってくる必要があります。 たとえば、"Contoso コネクタ Microsoft Teams 用" などです。 [修正する必要があります]

  • 命名の際には、Microsoft 製品をかっこ内に入れないでください。 [修正する必要があります]

  • 開発者名は、アプリ マニフェスト (以前は Teams アプリ マニフェスト) と AppSource で同じである必要があります。 [修正する必要があります]

  • 申請されるアプリ マニフェストは、運用マニフェストである必要があります。 したがって、アプリ名は、アプリが実稼働前アプリであることを示すべきではありません。 たとえば、アプリ名にベータ、開発、プレビュー、UAT などの単語を含めることはできません。 [修正する必要があります]

  • アプリ マニフェストと AppSource のアプリ名が一致している必要があります。 [修正する必要があります]

ヒント

アプリが公式の Microsoft 1P オファリングである場合を除き、アプリ名、開発者名、アプリ アイコン、AppSource のスクリーンショット、ビデオ、簡単な説明、Web サイトなど、Teams ストアと AppSource でのアプリのブランド化は、Microsoft の公式オファリングでない限り、公式の Microsoft オファリングを偽装しないでください。

重複するアプリ

  • 同じ機能を提供する同じ開発者のアプリは、プライバシー コンプライアンス要件で、政府のクラウドをサポートするために個別のアプリ一覧または個別のアプリ一覧が必要でない限り、アプリの一覧を共有する必要があります。 ビジネス ロジックに組み込み、1 つのリストのみを発行する必要があります。 [修正する必要があります]

    • 複数のリージョンのサポート要件を満たすには、ビジネス ロジックに組み込み、1 つのリストのみを発行する必要があります。

    ロジックで行われたリージョン要件の渡されたシナリオを示すスクリーンショット。

    • オンプレミスとクラウドのデプロイに関する複数のエンドポイント要件を満たすには、ビジネス ロジックに組み込み、1 つのリストのみを発行する必要があります。

職場での消費に適していること

[修正する必要があります]

このセクションは、Microsoft 商用認定ポリシー番号 1140.1.2100.8100.10 に沿ったものであり、開発者に職場に適したアプリを構築するための追加のガイダンスを提供します。

詳細を知るために展開する

アプリ コンテンツは、職場での一般的な消費に適したものであり、コマーシャル マーケットプレースの認証ポリシーに一覧表示されたすべての制限事項に従う必要があります。 宗教、政治、ギャンブル、長時間の娯楽などに関するコンテンツは禁止されています。 [修正する必要があります]

アプリは、グループのコラボレーションを可能にするもの、個人の生産性を向上させるもの、またはその両方である必要があります。 チームの結束や交流を目的としたアプリでは、コラボレーションが促進され、複数の参加者が利用できるように設計されている必要があります。 アプリは、セッションあたり 60 分を超えるかなりの時間の投資を必要としたり、生産性に影響を与えたりしてはなりません。 [修正する必要があります]

コンテンツ アグリゲーター アプリには、ユーザーが問題や不適切なコンテンツをアプリの発行元に報告するためのメカニズムが必要です。 [修正する必要があります]

問題を報告するコンテンツ アグリゲーター アプリの渡されたシナリオを示すスクリーンショット。

類似したプラットフォームやサービス

[修正する必要があります]

このセクションは、Microsoft 商用認定ポリシー番号 1140.1.3 に沿ったものです。

アプリ内では、Teams のエクスペリエンスが占有的である必要があります。アプリ コンテンツやアプリのメタデータには、他の同様のチャットベースのコラボレーション プラットフォームやサービスから取られた、名前、アイコン、またはイメージを含めてはいけません。ただし、アプリが特定の相互運用性を提供している場合はその限りではありません。

機能名

ボタンやその他の UI テキストのアプリ機能名では、Teams やその他の Microsoft 製品用に予約された用語を使用しないでください。 たとえば、会議の開始通話の開始チャットの開始は、Microsoft Teams のMicrosoftで使用されている機能名です。 必要に応じて、アプリ名を挿入してください (たとえば、"Contoso 会議の開始" としてください)。

認証

[修正する必要があります]

このセクションは、Microsoft 商用認定ポリシー番号 1140.1.4 に沿ったものであり、外部サービスを使用したそれらのアプリの認証に関して、開発者にガイダンスを提供します。

アプリ認証を実装する方法の詳細については、「Teams での認証」を参照してください。

詳細を知るために展開する

外部サービスを使用した認証

アプリが外部サービスを使用してユーザーを認証する場合は、以下のガイドラインに従ってください。

  • サインイン、サインアウト、サインアップのエクスペリエンス:

    • 外部アカウントまたはサービスに依存するアプリでは、シンプルでわかりやすいサインイン、サインアウト、およびサインアップ エクスペリエンスを提供する必要があります。 [修正する必要があります]
    • ユーザーがサインアウトする場合は、アプリからのみサインアウトし、Teams にはサインインしたままにする必要があります。 [修正する必要があります]
    • 外部アカウントやサービスに依存するアプリは、新しいユーザーがサインアップしたり、アプリ発行元に連絡してサービスの詳細を確認したり、サービスにアクセスしたりするための方法を提供する必要があります。 それらの方法は、アプリのマニフェスト、AppSource の詳細な説明、およびアプリの初回実行時エクスペリエンス (ボットのようこそメッセージ、タブのセットアップないしは構成ページ) から利用できる必要があります。 [修正する必要があります]
    • テナント管理者によるワンタイム セットアップが必要であるアプリでは、(他のテナント ユーザーがアプリをインストールして使用する前に) テナント管理者に対する依存関係を記述してそれが適用される形にアプリを構成しておく必要があります。 依存関係は、アプリのマニフェスト、AppSource の長い説明、すべての最初の実行エクスペリエンスのタッチポイント (ボットウェルカム メッセージ、タブセットアップ、または構成ページ)、ボットの応答の一部として必要と見なされるヘルプ テキスト、拡張機能の作成、または静的タブ コンテンツで呼び出す必要があります。 [修正する必要があります]
  • コンテンツ共有エクスペリエンス: Teams チャネルでコンテンツを共有するために外部サービスを使用した認証を必要とするアプリは、外部サービスでその機能がサポートされている場合、コンテンツを切断または共有解除する方法をヘルプ ドキュメント (または同様のリソース) で明示する必要があります。 これは、コンテンツの共有を解除する機能が、Teams アプリに存在する必要があるということではありません。

オーディオ

  • アプリの主な目的が音楽を聴く場合は、アプリに固有のエンド ツー エンド ワークフローを含む少なくとも 1 つのコラボレーション スコープをサポートする必要があります。 たとえば、プレイリストの共有、プレイリストの構成またはピン留め、音楽の同期的なリッスンなどです。 [修正する必要があります]

  • Teams でユーザーが音楽を聴かせる主な目的で公開されたアプリは、共同作業による共同リスニング エクスペリエンスを含めるのが推奨されます。 [修正に適しています]

セキュリティ

このセクションは、Microsoft 商用認定ポリシー番号 1140.3 に沿ったものです。

先頭に戻る

財務情報

[修正する必要があります]

このセクションは Microsoft 商用認定ポリシー番号 1140.3.1 に沿ったもので、Teams インターフェイス内の財務情報の送信に関するガイダンスを提供し、Teams アプリのモバイル (Android および iOS) バージョンでの制限付き支払いのシナリオを開発者に対して示します。

詳細を知るために展開する

アプリは、Teams インターフェイス内で支払いを行い、ボット インターフェイスを介してユーザーに財務情報を送信するようにユーザーに要求してはなりません。 [修正する必要があります]

validation-financial-info

ユーザーがアプリの使用に同意する前に、使用条件、プライバシー ポリシー、プロファイル ページ、Web サイトなどで開示を行った場合に限り、安全な外部決済サービスにリンクすることができます。 [修正する必要があります]

一般ポリシー番号 100.10 の不適切なコンテンツで禁止されている商品やサービスについて、アプリを介して購入できるようにしてはいけません。 [修正する必要があります]

iOS 版または Android 版 Teams で実行するアプリは、以下のガイドラインを遵守する必要があります。

  • アプリには、他のコンテンツ、アプリ、またはアドインを購入するために、有料バージョンまたはオンライン ストアにユーザーをアップセルすることを目的とするアプリ内購入、試用版、または UI を含めることはできません。[修正する必要があります]

    validation-financial-info-in-app-purchase

    validation-online-store

  • アプリでアカウントが必要な場合、ユーザーは無料でアカウントにサインアップできます。 無料版または無料アカウントという用語の使用は禁止されています。 [修正する必要があります]

  • アカウントを無期限にアクティブにするか、期間限定にするかを決めることができます。 アカウントの有効期限が切れると、アプリに支払いを必要とすることを示す UI、テキスト、またはリンクを表示しないようにする必要があります。 [修正する必要があります]

  • アプリのプライバシー ポリシーと使用条件には、商用の UI またはストアへのリンクがないことが必要です。 [修正する必要があります]

ボット

[修正する必要があります]

このセクションは、Microsoft コマーシャル マーケットプレース ポリシー 番号 1140.3.2 に沿ったものです。

詳細を知るために展開する

Microsoft Azure Bot Service を使用するアプリ (ボットやメッセージ拡張機能など) の場合、Microsoft オンライン サービスの使用条件で定義されているすべての要件に従う必要があります。

ボットを介してファイルをアップロードする場合は、必ずボットからユーザーに許可を求め、確認メッセージを表示しなければなりません。

validation-bot-confirmation

外部ドメイン

[修正する必要があります]

このセクションは 、Microsoft コマーシャル マーケットプレース ポリシー番号 1140.3.3 に沿っており、アプリ マニフェスト プロパティでの制限付きドメインの使用に関する開発者ガイダンスを validDomains 提供します。

詳細を知るために展開する

組織の制御外のドメイン (ワイルドカードなど) やトンネリング サービスをアプリのドメイン構成に含めないでください。 例外は次のとおりです。

  • アプリが SharePoint に依存している場合は、{teamSiteDomain} コンテキスト プロパティを使用して、関連するルート SharePoint サイトを有効なドメインとして含めることができます。 [修正する必要があります]

  • .com.in org などの最上位ドメインを有効なドメインとして使用しないでください。 [修正する必要があります]

  • .onmicrosoft.com またはonmicrosoft のコントロール下にない有効なドメインとして使用しないでください。 ただし、ドメインにワイルドカードが含まれている場合でも、サイト がコントロール下にある有効なドメインとして yoursite.com を使用できます。 [修正する必要があります]

  • アプリが Microsoft Power Platform 上に構築された PowerApp の場合は、apps.powerapps.com を有効なドメインとして含め、アプリが Teams 内でアクセスおよび機能できるようにする必要があります。

  • 申請用に宣言された外部ドメインには、URL を含めてはいけません。 たとえば、www または https です。 [修正する必要があります]

  • アプリで Azure Bot Serviceの OAuthCard を使用している場合は、有効なドメインとして token.botframework.com を含める必要があります。そうしないと、[サインイン] ボタンが機能しません。 このドメイン名ではワイルドカードを使用できないため、 .botframework.com を宣言しないでください。 [修正する必要があります]

  • OpenAPI URL はパートナーの管理下にある必要があります。

  • 次の外部ドメインは許可されません: [修正する必要があります]

    • *.azurewebsites.net
    • *.azureedge.com
    • *.microsoft.com
    • *.microsoftonline.com
    • *.onmicrosoft.com
    • go.microsoft.com
    • teams.microsoft.com

ワイルドカード (*) を使用する場合は、次の規則が適用されます。

  • サブドメイン セグメントにワイルドカードが含まれている場合は、セグメント内の唯一の文字である必要があります。
  • ワイルドカード セグメントの前のセグメントもワイルドカード セグメントである必要があります。

たとえば、 *.*.domain.com は有効ですが、 foo.*.myteam.domain.com は無効です。

機密コンテンツ

[修正する必要があります]

アプリは、クレジット カード、財務支払いの詳細、正常性、連絡先トレース、その他の個人を特定できる情報 (PII) などの機密データを、コンテンツを表示する意図のない対象ユーザーに投稿しないでください。

ユーザーのマシンや環境にファイルや実行ファイル (.exe) をダウンロードする場合は、その前にユーザーに警告しなければなりません。

一般的な機能とパフォーマンス

このセクションは、Microsoft コマーシャル マーケットプレース ポリシー 番号 1140.4 に沿ったものです。

  • 管理者と既存のユーザーの両方に対して、進め方ガイダンスが必須です。 サインアップ、開始、お問い合わせ、ヘルプ リンク、または電子メールへのハイパーリンクとして、進め方ガイダンスを追加できます。
  • アプリの機能でアカウントの依存関係や制限事項を呼び出す必要はありませんが、アプリ マニフェストの長い説明と AppSource アプリの一覧の両方に追加する必要があります。
  • 新しいユーザーのテナント管理者に対する依存関係を呼び出す必要があります。 依存関係がない場合は、サインアップの提供、お問い合わせ、リンクの開始、メールの送信が必須です。

先頭に戻る

外部機能の起動

[修正する必要があります]

主要なユーザー シナリオでは、アプリでユーザーを Teams から取り出すことはできません。 アプリのコンテンツと操作は、ボット、アダプティブ カード、タブ、ダイアログ (TeamsJS v1.x のタスク モジュールと呼ばれます) などの Teams 機能内で行う必要があります。

注:

、などのtel:mailto:webex:プロトコルを使用したディープ リンクを介して Teams アプリからネイティブ エクスペリエンスにユーザーをリダイレクトするには、 メソッドを呼び出window.openすか、 でアンカー タグtarget="_blank"を使用して、新しいウィンドウでディープ リンクを起動します。

詳細を知るために展開する
  • ユーザーがTeams の範囲内に留まり、外部のサイトやアプリにリンクを介して移動しないようにします。 外部の機能を利用する必要があるシナリオの場合は、その機能の利用を開始する許可をユーザーから明示的に得る必要があります。 [修正する必要があります]

  • 外部の機能を開始するボタンの名前は、その操作によりユーザーが Teams から離れることが明確にわかるようなものである必要があります。 たとえば、「Contoso.com への移動はこちら」や「Contoso.com で表示」といった例が考えられます。 [修正する必要があります]

  • ポップアウト アイコンを追加して、ユーザーが Teams の外部で移動していることをユーザーに知らせます。 リンクの右側にあるポップアップ アイコン を使用できます。 [修正する必要があります]

  • ポップアウト アイコンを追加できない場合は、次のいずれかのオプションを実装して、Teams の外部に移動されていることをユーザーに知らせることができます: [修正する必要があります]

    • アダプティブ カードに、[ユーザーがこのアプリを使用して問い合わせ] を選択すると、ユーザーが Teams の外部に移動することを示すメモを追加します。
    • スポット ダイアログを追加します。

互換性

[修正する必要があります]

アプリは、以下のオペレーティング システムやブラウザーの最新バージョンで完全に機能する必要があります。

  • Microsoft Windows
  • macOS
  • Microsoft Edge
  • Google Chrome
  • iOS
  • Android

アプリは、サポートされていないブラウザーやオペレーティング システムに関しては、穏当な表現でエラー メッセージを表示する必要があります。

応答時間

[修正する必要があります]

Teams アプリは、妥当な期間内に応答するか、読み込みまたは入力インジケーターまたはメッセージまたは警告を表示する必要があります。

  • タブは、2 秒以内に反応するか、読み込みメッセージや警告を表示する必要があります。 [修正する必要があります]
  • ボットは、ユーザーのコマンドに対して 2 秒以内に応答するか、入力インジケーターを表示する必要があります。 [修正する必要があります]
  • メッセージ拡張機能は、ユーザーのコマンドに対して 2 秒以内に応答する必要があります。 [修正する必要があります]
  • 通知は、ユーザーのアクションから 2 秒以内に表示される必要があります。 [修正する必要があります]

人工知能を搭載したアプリ

Microsoft RAI ToolkitHAX Toolkit Project など、イノベーションのあらゆる段階で責任ある人工知能 (AI) プラクティスを支援するように設計されたリソースについて説明します。

このセクションは、 AI で生成されたコンテンツを含むアプリの Microsoft コマーシャル マーケットプレース ポリシー、顔認識機能を使用したアプリの Microsoft コマーシャル マーケットプレース ポリシーに沿っています。

AI によって生成されたコンテンツを含むアプリ

  • アプリは、 100.10 に記載されている既存のコマーシャル マーケットプレース ポリシーと一致する不適切、有害、または不快な AI 生成コンテンツを生成、含める、またはアクセスを提供してはなりません。 [修正する必要があります]

    • 次のいずれかを使用することを検討してください。
      • Teams AI ライブラリ、Teams 中心のインターフェイスを使用して、GPT ベースの共通言語モデルとユーザー 意図エンジンを使用します。 [修正に適しています]
      • モデレーション フックの使用。モデレーション API を使用してボットの応答を調整するために使用できます。 [修正に適しています]
      • 会話スイープ機能を追加します。これは、会話を監視し、会話が迷子になったときに介入するのに役立ちます。 [修正に適しています]
  • アプリは、アプリ ユーザーが次のいずれかのメカニズムによって不適切、有害、または不快なコンテンツを開発者に報告するためのメカニズムを提供する必要があります: [修正する必要があります]

    • メール ID やポータルへのリンクを含むアプリの説明で、問題をログに記録します。
    • 不適切なコンテンツへの特定の参照と共に問題をログに記録するアプリ メカニズム。
  • 報告された懸念事項に対してタイムリーに対処する必要があります。 [修正する必要があります]

  • 顧客がポリシー 100.1.3 と一致するオファーを取得し、アプリ内機能の一部として情報を確認するようにユーザーに求める前に、アプリで AI 機能を明確に記述する必要があります。 [修正する必要があります]。

    Ai 機能の説明を示すスクリーンショット。

顔認識機能を使用したアプリ

注:

このカテゴリのアプリは、Microsoft の責任ある AI 原則に準拠するための追加のレビューを受ける場合があります。

  • アプリでは、顔認識機能を使用して、米国の警察によって使用される個人を識別することはできません。 [修正する必要があります]
  • 顔認識または感情推論テクノロジを利用するアプリの場合は、アプリの説明で、これらの各機能の目立つタグまたは表示を指定する必要があります。 [修正する必要があります]
    • 顔の表情や顔の動きを使用して、怒り、嫌悪感、幸福、悲しみ、驚き、恐怖、または人の感情的な状態を説明するために一般的に使用されるその他の用語などの感情的な状態を推測するアプリは、レビューに基づいて制限できます。
    • 笑顔や上げアイブロウなど、個々の顔の要素のみを検出して分類するための表情と動きの使用が許可されています。 重要な違いは、視覚信号としての表情や動きの検出と、感情状態の推論の違いです。

アプリ パッケージと Teams ストアの登録情報

[修正する必要があります]

アプリケーション パッケージは、正しく書式設定され、すべての必要な情報とコンポーネントが含まれている必要があります。

ヒント

  • 提供されたテスト アカウントまたはテスト環境が永続的に有効であることを確認する必要があります。つまり、アプリがコマーシャル マーケットプレースにでライブになるまでです。

  • 公開されたアプリを検証するために、次のようなテスト手順が明記されている必要があります。

    • アプリが外部アカウントに依存する認証を使用している場合は、 テスト アカウントを構成する手順を明記する。
    • Teams 内で実行されるコア ワークフローにおける期待されるアプリの動作について概略を記述する。
    • アプリの詳細な説明や関連資料に記載されている機能、特徴、成果物に関する制限、条件、例外について明確に説明する
    • アプリを検証するテスターが考慮すべきあらゆる考慮事項を強調する
    • テストを支援するために、テスト アカウントにダミー データを事前に設定する
    • テスト アカウントを提供する場合は、サード パーティの統合を有効にしてください。

先頭に戻る

アプリ マニフェスト

[修正する必要があります]

アプリ マニフェストは、アプリの構成を定義します。

  • アプリ マニフェストは、パブリックにリリースされたアプリ マニフェスト スキーマに準拠している必要があります。 詳細については、「 アプリ マニフェスト リファレンス」を参照してください。 アプリ マニフェストのプレビュー バージョンを使用してアプリを送信しないでください。
  • アプリにボットやメッセージ拡張機能が含まれている場合、アプリ マニフェストの詳細は、ボット名、ロゴ、プライバシー ポリシーのリンク、サービス使用条件のリンクなど、Bot Framework のメタデータと一致している必要があります。
  • アプリで認証にMicrosoft Entra IDを使用する場合は、アプリ マニフェストに Microsoft Entra アプリケーション (クライアント) ID を含めます。 詳細については、 アプリ マニフェスト リファレンスに関するページを参照してください。

最新のアプリ マニフェスト スキーマの使用

  • アプリでシングル サインオン (SSO) を使用する場合は、ユーザー認証のためにアプリ マニフェストでMicrosoft Entra IDを宣言する必要があります。 [修正する必要があります]

  • パブリックにリリースされたアプリ マニフェスト スキーマを使用する必要があります。 アプリ マニフェスト スキーマ 1.10 以降のパブリック バージョンを使用するようにアプリ パッケージを更新できます。 [修正する必要があります]

  • アプリの更新プログラムを申請する場合は、アプリのバージョン番号のみを増やします。 更新されたアプリのアプリ ID は、発行されたアプリのアプリ ID と一致する必要があります。 [修正する必要があります]

  • アプリ パッケージ内に追加のファイルが存在することは許容されません。 [修正する必要があります]

  • バージョン番号は、アプリ マニフェスト ファイル スキーマと追加の言語アプリ マニフェスト スキーマで同じである必要があります。 [修正する必要があります]

  • アプリをローカライズするには、アプリ マニフェスト スキーマ バージョン 1.5 以降を使用する必要があります。 manifest.json ファイルでアプリ スキーマ バージョン 1.5 以降を使用するには、$schema 属性を 1.5 以降に更新します。 manifestVersion プロパティを $schema バージョン (この場合は 1.5) に更新します。 [修正する必要があります]

  • 既存の機能を追加、更新、または削除する場合、アプリ マニフェストまたはパートナー センターのメタデータを追加または削除する場合は、アプリのバージョン番号を増やし、検証のためにパートナー センター アカウントに新しいアプリ マニフェストを送信する必要があります。 [修正する必要があります]

  • バージョン文字列は、セマンティック バージョン管理仕様 (SemVer) 標準 (MAJOR.MINOR.PATCH) に従う必要があります。 [修正する必要があります]

  • アプリで管理者が Teams 管理センターでアクセス許可を確認し、同意を付与する必要がある場合は、アプリ マニフェストで宣言 webapplicationinfo する必要があります。 アプリ マニフェストで宣言されていない場合 webapplicationinfo は、Teams 管理センターのアプリの [アクセス許可] ページが として表示されます [修正する必要があります]

  • Teams アプリ認定の一環として、アプリ マニフェストの運用バージョンを申請する必要があります。 [修正する必要があります]

  • Microsoft Cloud Partner Program ID (CCP ID) (以前は Microsoft Partner Network (MPN ID) と呼ばれる) をアプリ マニフェストで宣言することをお勧めします。 CCP ID は、アプリをビルドするパートナー organizationを識別するのに役立ちます。 [修正に適しています]

  • アプリ マニフェストで宣言されたスコープやコンテキストは、アプリ内で表示する必要があります。 [修正する必要があります]

アプリのアイコン

[修正する必要があります]

アイコンは、Teams ストアを閲覧するときに表示されるメイン要素の 1 つです。

詳細を知るために展開する

アイコンは、アプリのブランドや目的を伝えるとともに、以下の要件を満たす必要があります。

  • アプリの一覧に送信されるアプリの色とアウトライン アイコンが一致している必要があります。 [修正する必要があります]

    色アイコンとアウトライン アイコンが同じであることを示すスクリーンショット。

    色のアイコンとアウトライン アイコンが同じではないことを示すスクリーンショット。

  • アプリ パッケージには、カラー アイコンおよびアウトライン アイコンという、2 つのアプリ アイコンの PNG ファイルを含める必要があります。 [修正する必要があります]

  • パートナー センター アカウントのアプリのマーケットプレース リストの一部としてアップロードされたマーケットプレース アイコンは、アプリ パッケージに用意されている色アイコンと一致する必要があります。 [修正する必要があります]

  • カラー アイコンの解像度は 192x192 ピクセルである必要があります。 アイコン記号の配色は自由ですが、無地または完全に透明な正方形の背景に配置する必要があります。 [修正する必要があります]

  • アイコンのアウトライン バージョンは、次のシナリオで表示されます。

    • アプリが使用中で、Teams の左側のアプリ バーにホストされているとき。
    • ユーザーがアプリのメッセージ拡張をピン留めするとき。
  • アウトライン アイコンの解像度は 32x32 ピクセルです。透明な背景、または白地に透明な背景が使用できます。 アイコンには、シンボルの周囲に余分なパディングを含めることはできません。 [修正する必要があります]

  • ご使用のアプリ パッケージには、適切なサイズと書式設定されたアイコンが含まれる必要があります。 アイコンは、Teams ストアの登録情報メタデータの情報と一致している必要があります。 [修正する必要があります]

詳細については、「アイコンのガイドライン」を参照してください。

アプリの説明

アプリの短い説明と詳しい説明が備わっている必要があります。 アプリの説明は、Teams ストアでのアプリの検出可能性を向上させるのに役立ちます。 アプリ構成とパートナー センターでの説明が同じである必要があります。

図は、Teams アプリでの適切なアプリの説明の例を示しています。

図は、アプリの説明が不十分な場合に失敗したシナリオを示しています。



詳細を知るために展開する

説明は、別のブランド (Microsoft 所有またはそれ以外の場合) を直接または提案によってデロゲートしてはなりません。 説明に、実証できない要求が含まれていないことを確認します。 たとえば、「効率が 200% 向上することを保証します」という記述は不適切です。

  • アプリの説明に比較マーケティング情報を含めることはできません。 たとえば、競合するオファーやマーケットプレースを参照するタグやその他のメタデータを含む、オファーの一覧で競合他社のロゴや商標を使用しないでください。 [修正する必要があります]

    図は、アプリの説明に比較マーケティング情報が含まれる例を示しています。

  • ハイパーリンクの連絡先の詳細、概要、ヘルプ、またはアプリの説明へのサインアップ。 [修正に適しています]

    図は、アプリの説明にハイパーリンクされた連絡先の詳細の例を示しています。

    図は、アプリの説明にハイパーリンクされていない連絡先の詳細の例を示しています。

  • アプリの説明は、目的の対象ユーザーを特定し、その一意かつ明確な価値を簡単かつ明確に説明し、サポートされている Microsoft 製品やその他のソフトウェアを特定し、その使用に必要な前提条件や要件を含める必要があります。 顧客がオファーを取得する前に、リストおよび関連資料に記載されているように、機能、機能、成果物に関する制限事項、条件、または例外を明確に記述する必要があります。 宣言する機能は、アプリのコア機能と説明に関連している必要があります。 [修正する必要があります]

  • アプリ名を更新する場合は、アプリ マニフェスト、AppSource、および該当する場所のオファー メタデータで、古いアプリ名を新しいアプリ名に置き換えます。 [修正する必要があります]

  • 制限事項とアカウントの依存関係は、マニフェスト アプリの説明、AppSource、およびパートナー センターで呼び出す必要があります。 例:

    • エンタープライズ アカウント
    • 有料サブスクリプション
    • 別のライセンスまたはアカウント
    • 言語
    • 公衆交換電話網 (PSTN) プロバイダー
    • リージョンの依存関係
    • 翻訳者またはライブ エージェントを予約するためのリード タイム
    • ロールベースの機能
    • ネイティブ アプリへの依存関係

    図は、アプリの説明で呼び出される制限の例を示しています。

    図は、アプリの説明で呼び出されない制限の例を示しています。

  • アプリが特定のリージョンまたは地理的な場所でサポートされている場合は、そのオファーのアプリマニフェスト、パートナー センター、AppSource のアプリの説明でその特定のリージョンの依存関係を呼び出す必要があります。

  • Teams を参照する必要がある場合は、アプリの内容の最初の参照先を Microsoft Teams と記述します。 後の参照は、Teams と短縮することができます。 [修正する必要があります]

    図は、アプリの説明で Teams への正しい参照の例を示しています。

    図は、アプリの説明で Teams への不適切な参照の例を示しています。

簡潔な説明

短い説明は、アプリの価値提案を強調し、対象ユーザーに向けられる簡潔な概要である必要があります。

すべきこと:

  • 簡潔な説明を、 1 文で表現する。
  • 最も重要な情報を最初に説明する。
  • 顧客が検索すると考えられるキーワードを含める。
  • 使用可能な文字制限を効率的に使用する。 たとえば、アプリ名を繰り返さない。

してはいけないこと

[修正に適しています]

簡潔な説明の中にアプリという言葉を使用する。

詳しい説明

長い説明では、アプリの価値提案、主要な対象ユーザー、ターゲット 業界を強調した魅力的なストーリーを提供する必要があります。 説明は 4,000 文字までですが、約 1,000 文字の簡潔な説明を使用することをお勧めします。

すべきこと:

  • Markdown を使用して説明を書式設定する。

  • ユーザーに対して、積極的かつ直接的な表現を使用する (たとえば、「... が可能です」)。

  • アプリを使用する利点を強調するための主な利点を一覧表示します。 最大 3 つの利点を追加します。

  • Teams でアプリの重要な価値提案を追加します。

  • 機能を箇条書きにする (一読で理解できるようになる)。

  • 一覧や関連資料には、ユーザーがアプリをインストールする前に確認できるように、制限事項、特徴、機能に関する条件ないしは例外、成果物の内訳を明確に記載する。 一覧に記載されるコアの機能は、Teams の機能に関連していなければならない。

  • 説明が、Teams アプリ内で利用可能な機能と一致している。 Teams アプリ外でのワークフローについての言及は限定的なものに留められ、かつ記述される場合も Teams アプリの機能と明確に区別して記述されている必要がある。

  • ヘルプやサポートへのリンクを含める。

  • Office 365 ではなく Microsoft 365 と表記する。

  • アプリが Teams (または Microsoft 365) と連携する方法について説明する際には、次のような表現を使用する。

    • ... は Microsoft Teams と連携します。
    • ... が Microsoft Teams と連携しています。
    • ... が Microsoft Teams 内で〇〇しています。
    • ... が Microsoft Teams に対して〇〇しています。
    • ... が Microsoft Teams に組み込まれています。
    • ... が ... 向けにビルド
    • ... が ... 向けに開発
    • .. 用のデザインです...

してはいけないこと:

[修正する必要があります]

  • 500 文字を超える。

  • Microsoft の省略形として MSMSFT を使用する。

    図は、アプリの説明で Microsoft を MS または MSFT と初回に略している例を示しています。

    アプリの説明で Microsoft を MS または MSFT と初回に略していない例を示しています。

  • アプリが Microsoft の提供物であるかのように記述する。たとえば、Microsoft のスローガンやタグラインを使用する。

    図は、アプリの説明で Microsoft オファリングを示さない方法の例を示しています。

    Microsoft のスローガンとタグラインを使用せずにアプリの説明を記述する方法の例を示す図。

  • Microsoft の認定パートナーでないにもかかわらず、以下のような表現を使用する。

    • ... は ... の認定〇〇です
    • ... は ... を装備しています
  • 入力ミス、文法エラーが含まれている。

  • アプリ マニフェスト全体または AppSource の長い説明またはアプリ コンテンツ全体を不必要に大文字にします。

    図は、エラーのないアプリの詳細説明の例を示しています。

    図は、入力ミスとエラーを含むアプリの詳細説明の例を示しています。

  • AppSource へのリンクを含める。

    図は、アプリの詳細説明の AppSource へのリンクを含む失敗シナリオの例を示しています。

  • 検証されていない主張を事実として記述する。 たとえば、「ベストです」、「トップです」、「〇〇にランク付けされています」といった表現を使用する (ただし、根拠ある事実である場合は、その限りではない)。

  • マーケットプレース上の他のオファーと比較する。

正確で簡潔で有益な短い説明と長い説明を作成する方法のガイダンスについては、 アプリの説明を記述するためのチェックリストに関するページを参照してください。

スクリーンショット

スクリーンショットは、アプリ名、アイコン、説明を補完するために、アプリの視覚的なプレビューを提供します。



詳細を知るために展開する

次のことを覚えておいてください。

  • スクリーンショットは、1 つの一覧につき 5 枚まで設定できます。
  • サポートされているファイルの種類は、PNG、JPEG、GIF です。
  • 解像度は 1366x768 ピクセルである必要があります。
  • 最大サイズは 1,024KB です。

すべきこと:

  • アプリの機能に焦点を当てます。 たとえば、ユーザーがボットと通信する方法などです。

  • アプリを正確に表現するコンテンツを含めます。

  • 賢明な表現を使用する。

  • スクリーンショットには、ブランドを反映する色で縁取りを加え、マーケティング コンテンツを含める。

  • 鮮明で読みやすいテキストを含む高解像度のスクリーンショットを使用します。 [修正する必要があります]

  • 少なくとも 1 つのスクリーンショットは、モバイル デバイスでのアプリの機能を示している必要があります。 [修正する必要があります]

    スクリーンショットは、モバイル デバイスでのアプリ機能の成功したシナリオを示しています。

  • スクリーンショットは、1 つの一覧につき 5 枚まで設定できます。 アプリの一覧には、少なくとも 3 つのスクリーンショットと最大 5 つのスクリーンショットが必要です。 [修正する必要があります]

  • エンドユーザーの利益のために、アプリの実際の UI を正確に示すモックアップを使用します。 スクリーンショットでは、アプリに関連し、アプリに関連するアプリの実際の UI またはシナリオを正確に示す必要があります。 [修正する必要があります]

    スクリーンショットは、スクリーンショットで使用される補足コンテンツの失敗したシナリオを示しています。

    アプリの実際の UI のスクリーンショットの失敗したシナリオを示すスクリーンショット。

  • アプリの機能または Teams との統合を示す必要があります。 [修正する必要があります]

    アプリの機能または統合の失敗したシナリオを示すスクリーンショット。

  • 指定されたスクリーンショットは、MS、MSFT、またはMS TeamsとしてMicrosoft Teamsを誤って参照しないでください。 [修正する必要があります]

  • Teams アプリが Microsoft 365 クライアント (Microsoft 365、Outlook、Microsoft Teams) 全体で拡張可能な場合、提供されるスクリーンショットは、他の Microsoft 365 クライアントのアプリ機能を示している必要があります。 [修正する必要があります]

    MS 365 クライアントでの Teams アプリ機能の成功したシナリオを示すスクリーンショット。

  • ユーザーがアプリの機能を明確に理解できるように、スクリーンショットにキャプションを指定する必要があります。 [修正する必要があります]

    アプリ機能に対するユーザーの注意の渡されたシナリオを示すスクリーンショット。

  • アプリが機能としてタブをサポートしている場合、アプリの一覧の Teams タブのコンテキストでアプリを示すスクリーンショットには、チームのクロムが含まれている必要があります。 [修正する必要があります]

    スクリーンショットは、タブ機能のスクリーンショットの渡されたシナリオを示しています。

してはいけないこと:

  • Teams 外でアプリが使用されている場面など、アプリの実際の UI を正確に反映していないモックアップを含める。

    Teams の関連のないアプリ機能が失敗したシナリオを示すスクリーンショット。

ビデオ

アプリの一覧のビデオは、ユーザーがアプリを使用する必要がある理由を伝える最も効果的な方法の 1 つです。 アプリの価値を提供する YouTube または Vimeo ビデオ URL を追加できます。 また、ベスト プラクティスとして、アプリのデモまたはシナリオのチュートリアルを提供するビデオを追加することをお勧めします。 [修正に適しています]

パートナー センター アカウントでアプリの一覧の一部としてビデオを送信する場合は、次の条件を満たしていることを確認します。

  • ビデオは短く、明確で魅力的で、良質である必要があります。

  • このビデオでは、アプリを設定して使用する方法を示す必要があります。

  • ビデオは物語形式である必要があります。

  • ビデオの期間は、値ビデオの場合は 60 ~ 90 秒以内で、チュートリアル ビデオの推奨期間は 3 ~ 5 分です。 [修正に適しています]

  • アプリの一覧でビデオ リンクを送信する前に、YouTube または Vimeo アカウントの設定から広告をオフにする必要があります。 [修正する必要があります]

  • ビデオでは、Teams 内でのアプリの機能と統合を強調する必要があります。 [修正する必要があります]

  • ビデオは機能リンクとして利用できる必要があります。 [修正する必要があります]

  • 動画は、YouTube と https://youtu.be/:idhttps://vimeo.com/:id Vimeo の形式https://www.youtube.com/watch?v=:idである必要があります。

    スクリーンショットは、パートナー センターでのアプリの一覧の一部として送信されたビデオの失敗したシナリオを示しています。

  • ビデオは、アプリの詳細 (Teams ストアと管理 センター) および AppSource ページのスクリーンショットまたはビデオ カルーセルの最初の位置に表示できます。 [修正に適しています]

  • デモまたはシナリオのチュートリアルに関するビデオは、アプリを昇格させるのではなく、ユーザーを教育することを意図している必要があります。

アプリ値のビデオまたはチュートリアル ビデオを作成するための条件の詳細については、 ビデオを作成するためのチェックリストを参照してください。



プライバシー ポリシー

[修正する必要があります]

Teams アプリに特化した特定のポリシーも、すべてのサービスを対象とした全体的なポリシーも、プライバシー ポリシーとして指定できます。

  • 汎用のプライバシー ポリシー テンプレートを使用する場合は、サービス、アプリケーション、またはプライバシー ポリシーの範囲内のプラットフォームへの参照を追加する必要があります。 サービス、アプリケーション、プラットフォームへの参照が含まれている場合は、範囲内に Teams アプリを指定する必要はありません。 アプリ検証プロセスでは、これらの参照が解釈され、Teams アプリが他のサービスや Web サイトと共に含まれます。
  • ユーザー データ ストレージ、保持、および削除の処理方法を含める必要があります。 データ保護のためのセキュリティ制御について説明する必要があります。
  • 連絡先情報を含める必要があります。
  • 壊れている URL や、ベータ版やステージング用の URL を含んではいけません。
  • AppSource へのリンクを含めてはいけません。
  • プライバシー ポリシーには、認証を必要とせずにアクセスできなければなりません。
  • コマース UI またはストア リンクを含めてはいけません。
  • アプリ マニフェストと AppSource に同じリンクが必要です。

使用条件

[修正する必要があります]

次のガイドラインに沿って使用条件を記述します。

  • 提供するサービスに適用できる具体的なものである必要があります。
  • 独自のドメインでホストされている必要があります。
  • セキュリティで保護された (HTTPS) リンクが必要です。
  • 使用条件へのアクセスは、認証が必要なものであってはいけません。
  • アプリ マニフェストと AppSource に同じリンクが必要です。

[修正する必要があります]

アプリのサポート URL は、認証を必要としない必要があります。 たとえば、ユーザーはサインインせずにユーザーに連絡できる必要があります。

詳細を知るために展開する

サポート URL には、連絡先の詳細や、ユーザーがサポート チケットを発行するための方法を含める必要があります。 たとえば、サポート URL が GitHub でホストされている場合、GitHub ページは所有権下になければならず、ユーザーがサポート チケットを発行するには、連絡先の詳細や転送方法を含める必要があります。

validation-support-links-auth

ローカリゼーション

[修正する必要があります]

  • アプリがローカリゼーションを提供する場合、アプリ パッケージには、Teams の言語設定に基づいて表示される言語の翻訳ファイルを含める必要があります。 ファイルは、Teams のローカリゼーション スキーマに準拠している必要があります。 詳細については、「Teams のローカリゼーション スキーマ」を参照してください。 [修正する必要があります]

  • アプリ メタデータ コンテンツは、en-us とその他のローカライズ言語と同じである必要があります。 [修正する必要があります]

  • サポートされている言語は、AppSource アプリの説明に表示する必要があります。 たとえば、このアプリは X (X= ローカライズされた言語) で使用できます。 [修正する必要があります]

  • ユーザーのクライアント設定が追加の言語と一致しない場合、既定の言語が最終的なフォールバック言語として使用されます。 アプリケーションでサポートされている正しい既定の言語でlocalizationInfo プロパティを更新します。 [修正する必要があります]

  • アプリケーションで localizationInfo サポートされている適切な既定の言語でプロパティを更新するか、アプリ マニフェストとパートナー センターの長い短い説明のローカライズされたコンテンツを追加します。 [修正する必要があります]

SaaS オファーに関連付けられたアプリ

このセクションは、Microsoft コマーシャル マーケットプレース ポリシー 番号 1140.5 に沿ったものです。 サービスとしてのソフトウェア (SaaS) オファーにリンクされた Teams アプリを構築する場合は、これらのガイドラインに準拠していることを確認してください。

全般
  • ISV は、同じテナント内の複数のユーザー (サブスクライバー) が自身のサブスクリプションを管理し、テナント内のユーザーにライセンスを割り当てる機能をサポートする必要があります。
  • このプランは、SaaS プランに関連付けられた Teams アプリの技術的要件をすべて満たす必要があります。
  • SaaS プランに関連付けられた Teams アプリは、サービスとしての 1000 個のソフトウェア (SaaS)で定義されたすべての要件を満たす必要があります。
  • subscriptionOffer アプリ マニフェスト ファイルに記載されている詳細が正しい必要があります。 アプリ マニフェストで、値 publisherId.offerId を使用してノード subscriptionOffer を追加または更新します。 たとえば、発行元 ID が contoso1234 で、オファー ID が offer01 である場合、アプリ マニフェストで指定する値は contoso1234.offer01 である必要があります。
  • Teams アプリへのリンクされた SaaS オファーは AppSource に公開されている必要があり、プレビュー オファーは Teams ストアの承認には受け付けられません。

オファーのメタデータ
  • オファーメタデータは、アプリ マニフェスト、AppSource の Teams アプリリスト、AppSource の SaaS オファーで一致する必要があります。
  • Teams アプリと SaaS プランは、同じ発行元または開発者によるものでなければなりません。 アプリ マニフェストで参照される SaaS オファーは、Teams アプリがコマーシャル マーケットプレースに送信されるのと同じ発行元に属している必要があります。
  • 申請したオファーが SaaS オファーにリンクされた Teams アプリである場合は、プラン一覧の [パートナー センター製品セットアップ] セクションで [追加購入] に対して [はい。製品には、サービスの購入や追加のアプリ内購入の提供が必要です] を選択する必要があります。
  • プランの説明と価格の詳細は、ユーザーがプラン一覧を明確に理解するために十分な情報を提供する必要があります。
  • 追加のサービスへの制限事項、依存関係や、提供される機能の例外は、プランの説明で正確に呼び出す必要があります。
  • SaaS プランにリンクされた Teams アプリは、ユーザーごとに割り当てられたライセンスをサポートするように設計されています。 状況によっては、SaaSオファーが他の方法で構築される場合や、専用の購入フローが用意されている場合もあります。 それぞれの方法や購入フローに関しては、アプリのメタデータおよびサブスクリプション プランの詳細の中で、明確に説明されている必要があります。
  • SaaS オファーでは、購入フローのすべての該当する状態にあるすべてのユーザーに向けて、メッセージとガイダンスが提供される必要があります。

SaaS プランのホーム ページとライセンス管理
  • サブスクライバーに製品の使用方法を紹介します。

  • サブスクライバーへのライセンスの割り当てを許可します。

  • FAQ、ナレッジベース、メール アドレスなど、さまざまな方法で問題のサポートに取り組む方法を提供します。

  • ユーザーを検証して、他のユーザー経由でライセンスが割り当てられていないか確認します。

  • ライセンスの割り当て後にユーザーに通知します。

  • アプリを Teams に追加して使い始める方法を、Teams チャット ボットやメールでユーザーに案内します。

  • SaaS アプリで Microsoft ライセンス管理を使用する場合は、ISV のランディング ページでアプリ サブスクリプションが確認された後、ユーザーを Teams の Microsoft ライセンス管理にリダイレクトして、配信停止を回避し、ユーザーが Teams 内でライセンスを管理できるようにする必要があります。


ユーザビリティと機能の内容
  • ライセンスの購入と割り当てが正常に行われたら、次の情報が提供される必要があります。
    • ユーザーがサブスクライブしたプランの機能にアクセスする方法
    • ユーザーに対して提供される、サブスクリプション プランの付加価値と主要なメリット
    • Teams アプリから、SaaS アプリケーションのホーム ページへのリンクを提供し、サブスクライバーが将来にわたってライセンスを管理できるようにします。

SaaS アプリケーションの構成とテスト

テスト目的でのアプリのセットアップが複雑な場合は、エンドツーエンドの機能ドキュメント、関連付けられた SaaS の構成手順、ライセンスとユーザー管理の手順を「構成用メモ」の一部として提供します。

ヒント

アプリやライセンス管理の仕組みを説明したビデオを追加して、チームのテストをサポートすることができます。

先頭に戻る

タブ

このセクションは、Microsoft コマーシャル マーケットプレース ポリシー 番号 1140.4.2 に沿ったものです。 アプリにタブが含まれている場合は、以下のガイドラインに従っていることを確認してください。

ヒント

高品質なアプリ エクスペリエンスを作成するための詳細については、「Teams タブ デザインのガイドライン」を参照してください。


セットアップ
  • タブ設定 は、 新しいユーザーを停止してはなりません。 アクションやワークフローを完了するためのメッセージを提供します。 [修正する必要があります]

    図は、セットアップ時にデッドエンドがあるタブの例を示しています。

  • Teams の外部でコンテンツを作成し、Teams に戻ってピン留めするには、ユーザーが Teams 内のタブ構成エクスペリエンスを離れる必要はありません。 タブ構成画面の範囲内で、構成の値と方法が説明される必要があります。 [修正する必要があります]

    validation-tabs-set-up-profile-name

  • タブ構成画面は、Web サイト全体を埋め込むべきではありません。 構成エクスペリエンスに焦点を当て続けます。 たとえば、ユーザーがチャネルでプロジェクトを構成できるプロジェクト管理アプリを作成する場合は、タブ構成画面に焦点を当て、ユーザーがチャネルで構成するアプリからプロジェクトを選択できるようにします。 [修正する必要があります]

    validation-tabs-setup-configuration-exp

    validation-tabs-set-up-configuration-screen

  • ユーザーがタブの構成中に URL を入力する必要があるアプリでは、次の操作を行う必要があります:

    • ユーザーが URL を取得または生成するための適切な転送ガイダンスを提供します。 [修正する必要があります]

    • アプリの説明に従って、アプリの機能に関連する URL または適切な URL を確認します。 [修正する必要があります]

      ユーザーが URL を生成する方法を示すタブ構成の例を示すスクリーンショット。

      ユーザーが URL を生成する方法のないタブ構成の例を示すスクリーンショット。

  • ユーザーがサポート要件について連絡できるように、プレーン テキストではなく、構成画面の連絡先情報にハイパーリンクを設定します。 [修正する必要があります]

  • シームレスな初回実行ユーザー エクスペリエンスを実現するには、構成画面でサポート URL またはメールにハイパーリンクを設定することをお勧めします。 [修正に適しています]


ビュー
  • サインイン画面領域では、大きなロゴを使用しないでください。 [修正する必要があります]

    validation-views-app-login

  • 複数のタブに分割して表示することで、コンテンツはシンプルになります。

    val-views-multiple-tabs

  • タブでは、ヘッダーが重複しないようにする必要があります。 タブ フレームワークではすでにアプリ アイコンとアプリ名が表示されているため、I-frame​​ から重複するロゴを削除します。 [修正に適しています]

    ヘッダーとロゴが重複しないタブの例を示す図。

    ヘッダーとロゴが重複するタブの例を示す図。


ナビゲーション

ナビゲーションに関するガイドラインは次のとおりです。

  • タブでは、プライマリ Teams ナビゲーションと競合するナビゲーションを提供しないでください。 タブに左側のナビゲーションを指定する場合は、アイコンまたは積み上げテキストを含むアイコンのみを含めることはできません。 積み上げテキストを含むアイコンを表示するオプションを使用して折りたたみ可能なレールにすることはできません (Teams ナビゲーション バーを模倣しています)。 インライン テキストやテキストのみを持つアイコンを含めるか、タブ左レールの代わりにハンバーガー メニューを使用します。 [修正する必要があります]

    Fluent UI コンポーネントの BasicAdvanced を使用してアプリをデザインしてください。

    図は、主要な Teams ナビゲーションと競合しないタブ内のナビゲーションの例を示しています。

    図は、Teams のプライマリ ナビゲーションと競合する左側のナビゲーション レールの例を示しています。

  • タブの左側のレールにナビゲーション コンポーネントのないツール バーがある場合、ツールバーは Teams の左ナビゲーションから 20 ピクセル間隔のままにする必要があります。 [修正する必要があります]

    validation-nav-spacing-between-toolbar

  • タブの第 2 ページと第 3 ページは、メイン タブ領域のレベル 2 (L2) ビューとレベル 3 (L3) ビューで開く必要があります。このビューは階層リンクまたは左ナビゲーションを介して移動されます。 次のコンポーネントを使用して、タブ内のナビゲーションを支援することもできます。

    • 戻るボタン

    • ページ ヘッダー

    • ハンバーガー メニュー

      複数のナビゲーション レベルを持つ会議中ダイアログの例を示すスクリーンショット。

  • タブ内のディープ リンクは、外部 Web ページではなく Teams 内にリンクする必要があります。 たとえば、ダイアログや他のタブなどです。 [修正する必要があります]

    validation-nav-view-button-not-linked-static-tab

  • タブでは、ユーザーがコア アプリ エクスペリエンスのために Teams の外部を移動できないようにする必要があります。 一方、コア エクスペリエンス以外のワークフローに対しては、タブから Teams の外部にリダイレクトさせることができます。 たとえば、サポート チケットを発生する場合などです。 [修正する必要があります]

    validation-nav-core-workflow-within-configuration

    validation-nav-core-workflow-redirects-outside

  • 会議中のタブに水平スクロールを表示しないでください。[修正する必要があります]

  • アプリで使用される会議内ダイアログでは、水平スクロールを許可しないでください。 頻繁に使用してはなければなりません。簡素でかつタスク指向性のあるシナリオに対してのみ使用してください。 会議内ダイアログの I-frame の幅を、サポートされているサイズ範囲内で指定して、さまざまなシナリオに対応できます。 [修正する必要があります]

  • アプリで使用されるダイアログでは、水平スクロールを許可しないでください。 ダイアログを使用すると、横スクロールを必要とせずに、さまざまなサイズを選択してコンテンツの応答性を高めることができるようになりました。 必要に応じて、Stageview (Web コンテンツを表示するための全画面表示 UI コンポーネント) を使用して、水平スクロールなしでワークフローを完了できます。 [修正する必要があります]

  • タブが固定 UI 要素を持つ無限のキャンバスを使用しない限り、タブ全体がスクロール可能な場合、任意のスコープ内の個人用チャット、チャネル、会議内の詳細タブのタブに存在する水平スクロールは許可されません。 [修正する必要があります]

    図は、水平スクロールが許可されているモバイルのすべてのシナリオの例を示しています。

    かんばんボードでの水平スクロールの例を示す図。

    図は、多数のコンポーネントを含むリスト ビューの例を示しています。

    図は、無限キャンバスと固定ボードを含むホワイトボードでの水平スクロールの例を示しています。

    図は、リスト ビューでの水平スクロールの例を示しています。

  • ユーザーには、以前の作業状態に移動するオプションが必要です。 [修正する必要があります]

     使用可能な戻るボタン オプションを示すスクリーンショット。

    [戻る] ボタン オプションが使用できないという失敗したシナリオを示すスクリーンショット。

  • アダプティブ カードの水平スクロールは、Teams に存在してはなりません。 [修正する必要があります]

  • タブのナビゲーションに使用される下部レールは、Teams ネイティブ モバイル アプリナビゲーションと競合してはなりません。 [修正する必要があります]

    図は、Teams ネイティブ モバイル アプリ ナビゲーションと競合するタブの例を示しています。


ユーザビリティ
  • コンテンツをタブ内で切り捨てたり重複させたりしないでください。[修正する必要があります]

    validation-usability-content-truncations

  • ユーザーはタブで最後の操作を元に戻すことができる必要があります。[修正する必要があります]

  • 個人用コンテキストのタブには、アプリの共有インスタンスからのコンテンツを集約して表示させる場合があります。 たとえば、かんばんカードを使用してプロジェクトにコメントを付加する機能を提供する、構成可能タブを含んだ「プロジェクト管理アプリ」の場合、集約されたコンテンツを個人用アプリに表示させる必要があります。 [修正に適しています]

  • タブは Teams テーマに対応するものである必要があります。 ユーザーがテーマを変更すると、アプリのテーマにもその選択が反映される必要があります。 [修正に適しています]

    グラフィックは、Teams のテーマに対応するタブの例を示しています。

    図は、Teams のテーマに対応しない Tab の例を示しています。

  • タブには、Teams のフォント、入力ランプ、カラー パレット、グリッド システム、モーション、声のトーンなど、Teams スタイルのコンポーネントを可能な限り使用する必要があります。 詳細については、「タブ デザイン ガイドライン」を参照してください。 [修正に適しています]

    ネイティブ Teams フォントではなく Calibri フォントを含むタブの例を示すスクリーンショット。

  • アプリの機能で設定の変更が必要な場合は、[ 設定] タブを含めます。[修正が適切]

  • タブは、ページ内ナビゲーション、ダイアログの配置や使用方法、情報階層など、Teams の対話型デザインに沿ったものである必要があります。 詳細については、「Microsoft Teams Fluent UI キット」を参照してください。 [修正に適しています]

  • タブ エクスペリエンスは、モバイル (Android と iOS) で完全にレスポンシブでなければなりません。 [修正する必要があります]

    ヒント

    • 個人用タブと一緒に個人用ボットを設定します。
    • ユーザーが自分の個人用タブからコンテンツを共有できるようにします。
  • タブには、タブ内のワークフローを完全に妨げる、または妨げる要素を含めることはできません。たとえば、最小化できないタブ内のボットなどです。 [修正する必要があります]

    図は、タブ内のワークフローを妨げる要素を含むタブの例を示しています。

  • Tab には機能が壊れていない必要があります。 オファーは、使用可能なソフトウェア ソリューションである必要があり、リストやその他の関連資料で説明されているように、機能、成果物を提供する必要があります。 [修正する必要があります]

  • タブにフッターが含まれている場合は、アプリ機能に関係のないリンクをすべてフッターから削除してください。 [修正する必要があります]


スコープの選択
  • 構成可能なタブのランディング ページ内のコンテンツは、個々の用途にスコープを設定し、 個人用タスクマイ ダッシュボードなどの個人用コンテンツを含めないようにする必要があります。 [修正する必要があります]

    図は、個人用タスクやマイ ダッシュボードなどの個人用スコープを持つ構成可能なタブ内のコンテンツの例を示しています。

  • 構成エクスペリエンスが完了したら、ランディング ページにチーム全体のコラボレーション ビューが表示される必要があります。 [修正する必要があります]

  • 作業効率や職場の生産性向上のために、アプリ内で個人スコープのビューを提供するには、個人向けアプリへのディープ リンクを使用して表示を絞り込むか、または構成可能タブ内の L2 ないしは L3 のビューに移動します。その際、ランディング ページはコンテキストごとに、すべてのユーザーに対して同じ状態に保ちます。 [修正する必要があります]

  • 構成可能タブのランディング ページのコンテンツは、コンテキストごとに、すべてのチャネル メンバーに対して同じでなければいけません。 [修正する必要があります]

    図は、すべてのメンバーでコンテキストが異なる構成可能なタブのランディング ページのコンテンツの例を示しています。

  • 構成可能タブの機能は、十分に絞り込まれたものでなければなりません。 [修正する必要があります]

    validation-usability-configurable-nested-tab


先頭に戻る

ボット

このセクションは、Microsoft コマーシャル マーケットプレース ポリシー 番号 1140.4.3 に沿ったものです。

アプリにボットが含まれている場合は、以下のガイドラインに従っていることを確認してください。

ヒント

高品質なアプリ エクスペリエンスを作成するための詳細については、「Teams ボット デザインのガイドライン」を参照してください。


ボット デザイン ガイドライン
  • Teams アプリは、Teams ボットのデザイン ガイドラインに従う必要があります。

  • ワークフローでユーザーが反復的なタスクを実行する場合に、複数ターンボットの応答を回避するには、ダイアログを実装する必要があります。 たとえば、ダイアログを使用して、複数ターンの会話を使用する代わりに、名前、生年月日、場所、および指定を繰り返しキャプチャします。 [修正する必要があります]

  • アプリ内の壊れたリンク、応答、またはワークフローを修正する必要があります。 [修正する必要があります]


ボット コマンド

ユーザー入力を分析し、ユーザーの意図を予測することは困難です。 ボット コマンドでは、ボットが理解できる単語または語句のセットをユーザーに提供します。

  • HiHelloHelp などの汎用的なコマンドを含め、ボットがサポートするすべてのコマンドが正しく動作する必要があります。 [修正する必要があります]

    図は、汎用コマンドに応答するボットの例を示しています。

    図は、汎用コマンドに応答しないボットの例を示しています。

  • ボット コマンドはユーザーをデッド エンドに導く必要はありません。コマンドは常に前進する方法を提供する必要があります。 [修正する必要があります]

    validation-bot-commands-dead-end

  • アプリ マニフェストのセクションに items.commands.title 少なくとも 1 つの有効なボット コマンドを一覧表示し、ボット コマンドとその使用方法をユーザーにわかりやすくするための適切な説明を追加する必要があります。 アプリ マニフェスト画面のセクションに commandLists 表示されているボット コマンドは、ボット コマンド メニューに事前入力されたコマンドとして表示され、新しいユーザーがボットと対話する方法を提供します。 [修正に適しています]

  • ボットの応答には、Microsoft 製品の公式画像やアバターを含めることはできません。 アプリで独自の資産を使用します。 アプリでの Microsoft 製品イメージの使用は許可されません。 使用許諾契約書 (EULA)、コンテンツに付随するライセンス条項、または「Microsoft の商標およびブランド ガイドライン」に明示的なアクセス許可が付与されている場合にのみ、Microsoft の著作権で保護された製品イメージをコピー、変更、配布、表示、ライセンス、または販売することができます。 [修正する必要があります]

  • ボットは、継続的な読み込みインジケーターを表示せずに、ユーザー コマンドに応答する必要があります。 [修正する必要があります]

  • ボット ヘルプ コマンドの応答では、ユーザーを Teams の外部にリダイレクトしないでください。 ボット ヘルプ コマンドの応答では、Teams アプリ内のキャンバスにユーザーをリダイレクトしたり、アダプティブ カードで転送応答を提供したりできます。 [修正する必要があります]

    図は、Teams の外部でユーザーをリダイレクトするボット応答の例を示しています。

  • ボットは、入力が無関係または不適切な場合でも、常にユーザー入力に対して有効な応答を提供する必要があります。 [修正する必要があります]

    図は、不適切なボット コマンドに対する有効な応答の例を示しています。

    図は、不適切なボット コマンドに対する無効な応答の例を示しています。

  • スラッシュ (/) などの特殊文字は、ボット コマンドの先頭に付けてはいけません。 [修正する必要があります]

    図は、ボット コマンドに特殊文字のプレフィックスが付いている失敗したシナリオの例を示しています。

  • ボットは、無効なユーザー コマンドに対して有効な応答を提供する必要があります。 ユーザーが無効なボット コマンドを送信した場合、ボットはユーザーを停止したり、エラーを表示したりしてはなりません。 [修正する必要があります]

    図は、無効なコマンドに対してボットが解決策を提示する例です。

    図は、ボットが有効で無効なコマンドに対して同じ応答を送信する失敗シナリオの例を示しています。

  • ボットの機能は、ボットがインストールされているスコープに関連している必要があり、ボットはインストールされたスコープに値を指定する必要があります。 [修正する必要があります]

  • ボットに重複するコマンドを含めることはできません。 [修正する必要があります]

  • ボットは、ユーザー コマンドに応答した後に入力インジケーターを表示する必要はありませんが、ユーザー コマンドへの応答中に入力インジケーターを表示できます。 [修正する必要があります]

  • ボットは、小文字または大文字で入力された ヘルプ コマンドに対して、ユーザーに先に進方法を示したり、ボットの使用に関連するヘルプ コンテンツにアクセスできるような有効な応答を提供する必要があります。 ボットは、ユーザーがアプリにログオンしていない場合でも、有効な応答を提供する必要があります。 [修正する必要があります]

    図は、小文字または大文字のコマンドに有効な応答を提供しないボットの例を示しています。

    図は、ユーザーがアプリにログオンしていない場合に有効な応答がないボットの例を示しています。

  • ボットは、ヘルプ コマンドに対して有効な応答を提供する必要があります。

    図は、ヘルプ コマンドに有効な応答を送信するボットの例を示しています。

  • モバイルでのボットの応答は、エンド ユーザーのボットの使用を妨げるデータの切り捨てなしで応答性が高く、目的のワークフローを完了する必要があります。 [修正する必要があります]

    図は、モバイルで切り捨てずにボット メッセージの例を示しています。

    図は、モバイルでのボット メッセージの切り捨ての例を示しています。

  • ボット応答アダプティブ カード内のすべてのリンクは、応答性が高い必要があります。 ユーザーを Teams プラットフォームの外部に移動するリンクには、ボットの応答動作設定ボタンに "..で表示" または "..する方法" などの明確なリダイレクト テキスト、またはボットの応答メッセージ本文に適切なリダイレクト テキストが示されている必要があります。 [修正する必要があります]

    図は、リダイレクトを含むボット応答動作設定ボタンの例を示しています。

  • デザイン上、ボットが応答しないか、ユーザー コマンドをサポートしていない場合、ボットはユーザーに通知することを目的とした 1 つの方法です。 アプリ マニフェストで true に設定 isNotificationOnly する必要があります。 [修正する必要があります]

    図は、アプリ マニフェストで通知専用プロパティが true に設定されている例を示しています。

    図は、ユーザーのメッセージに応答しないボットのみの通知の例を示しています。

  • モバイル プラットフォームでは、ボットのユーザー エクスペリエンスを壊すべきではありません。 ボットは、モバイルで完全な応答性がある必要があります。 [修正する必要があります]

ヒント

個人用ボットの場合は、[ヘルプ] タブを設けて、ボットにより可能となる機能について詳しく説明します。


ボットの初回実行ユーザー エクスペリエンス
  • 個人用スコープ内のボットは、常にウェルカム メッセージを送信するか、プロンプト スターターを提供する必要があります。 [修正する必要があります]

    プロンプト スターターを使用している場合は、次のガイドラインが満たされていることを確認します。

    プロンプト スターターは、ユーザーがボットとの会話を開始するのに役立ちます。 プロンプト スターターを有効にするには、 commands アプリ マニフェストのプロパティを定義する必要があります。

    • ボットは、ユーザーがアプリの価値提案について知り得るコマンドを少なくとも 1 つ提供する必要があります。 [修正する必要があります]
    • プロンプト スターターまたはコマンドは機能し、応答を返す必要があります。 [修正する必要があります]
    • コマンドの説明は一貫性があり、コマンドの値を明確に伝える必要があります。 [修正する必要があります]
    • プロンプト スターターまたはコマンドは、アプリの機能に関連している必要があります。 [修正する必要があります]
    • ボットには、少なくとも 3 つの一意のプロンプト スターターまたはコマンドが必要です。 [修正に適しています]

    アプリからウェルカム メッセージが送信される場合は、次のガイドラインが満たされていることを確認します。

    • アプリに複雑な構成フローがある場合 (エンタープライズ ライセンスが必要な場合、または直感的なサインアップ フローがない場合)、そのようなアプリのボットは、初回実行時にウェルカム メッセージを送信するときに、常に構成関連情報を含める必要があります。

      最適なエクスペリエンスを得るために、ウェルカム メッセージには、ボットがユーザーに提供する価値、チャネルにボットをインストールしたユーザー、ボットを構成する方法、およびサポートされているすべてのボット コマンドの簡単な説明が含まれる必要があります。 ボタン付きのアダプティブ カードを使用してウェルカム メッセージを表示すると、より使いやすくなります。 詳細については、「ボットのウェルカム メッセージをトリガーする方法」を参照してください。 アプリの構成フローが複雑でない場合、ボットの初回実行時にウェルカム メッセージを表示させることは選択になります。 ただし、ウェルカム メッセージを表示させる場合は、ウェルカム メッセージのガイドラインに従う必要があります。

      図は、ボットに複雑な構成ワークフローがあるときにウェルカム メッセージを送信するボットの例を示しています。

      図は、ボットに複雑な構成ワークフローがある場合にウェルカム メッセージを送信しないボットの例を示しています。

  • チャネルやチャットでのボットのウェルカム メッセージは、初回実行時には省略可能であり、特にボットが個人用に利用でき、同様のアクションを実行する場合は省略できます。 ボットは、ユーザーに個別にウェルカム メッセージを送信しないでください ( スパムと見なされます)。 メッセージには、ボットを追加したユーザーもメンションしなければなりません。

    validation-bot-welcome-message-not-trigger

    validation-bot-wel-message-trigger

  • ウェルカム メッセージは、ユーザーの配信停止を行ってはいけません。 ウェルカム メッセージには、ボットがユーザーに提供する価値、チャネルにボットをインストールしたユーザー、ボットを構成する方法、およびサポートされているすべてのボット コマンドの簡単な説明が含まれる必要があります。 ボタン付きのアダプティブ カードを使用してウェルカム メッセージを表示すると、より使いやすくなります。 [修正する必要があります]

    図は、ウェルカム メッセージでボットがユーザーに前に進む方法がない失敗シナリオの例を示しています。

    図は、ユーザーがタスクを完了するための明確な方法を持つボットのウェルカム メッセージの例を示しています。

  • チャネルまたはグループ チャットスコープにインストールされたボットは、1:1 チャットですべてのチーム メンバーにプロアクティブなウェルカム メッセージを送信してはなりません。 [修正する必要があります]

    図は、すべてのチーム メンバーにプロアクティブなウェルカム メッセージを送信するボットの例を示しています。

  • 通知専用ボットは、メッセージにボットの構成を完了するための重要な情報がメッセージに含まれている場合、または通知がトリガーされるシナリオを明確にする場合にのみ、チャネルでプロアクティブなウェルカム メッセージを送信できます。 [修正する必要があります]

  • チャネルまたはグループ チャットスコープにインストールされたボットは、チャネルまたはグループ チャットのすべてのユーザーとは無関係なプロアクティブ メッセージ (ウェルカム メッセージだけでなく) を送信しないでください。代わりに、1:1 チャットを超えてプロアクティブ メッセージをユーザーに送信する必要があります。 [修正する必要があります]

  • チャネルまたはグループ チャット スコープにインストールされているボットでは、ユーザーが個々のワークフローを開始できないようにする必要があります。 ボットは、ユーザーと 1 対 1 のチャットで個々のワークフローを完了する必要があります。 [修正する必要があります]

  • ボットのウェルカム メッセージでは、インストールされているスコープでのボットの使用に関する制限事項を明確に呼び出す必要があります。 [修正する必要があります]

    図は、ボットのウェルカム メッセージでのアプリの制限の例を示しています。

    図は、ウェルカム メッセージでアプリの制限のないボットの例を示しています。

  • ウェルカム メッセージは、個人用スコープでアプリのインストール時に自動トリガーする必要があります。 ボットが個人用スコープでウェルカム メッセージを送信しない場合、ユーザーはデッドエンドになります。 アプリに複雑な構成ワークフローが含まれていない場合は、開発者がチャネルまたはグループ チャット スコープでウェルカム メッセージをトリガーすることは省略可能です。 [修正する必要があります]

    図は、個人用スコープでウェルカム メッセージを自動的に送信しないボットの例を示しています。

  • ウェルカム メッセージは、ボットのインストール時に 1 回だけトリガーする必要があります。 ウェルカム メッセージは、ユーザーがヘルプ コマンドを呼び出すたびにトリガーされるべきではありません。 ユーザーがボットに関連するヘルプにアクセスする方法を含めるために、ヘルプ コマンドの応答に焦点を当てる必要があります。 [修正する必要があります]

  • ウェルカム メッセージは、すべてのボット コマンドでトリガーされるべきではありません。 これはスパムと見なされます。 [修正する必要があります]

    図は、任意のコマンドのウェルカム メッセージをトリガーするボットの例を示しています。

  • ウェルカム メッセージ コンテンツは、アプリの詳細説明とインストール スコープに記載されているボットのワークフローに関連している必要があります。 ウェルカム メッセージには、ボットがユーザーに提供する価値、チャネルにボットをインストールしたユーザー、ボットを構成する方法、およびサポートされているすべてのボット コマンドの簡単な説明を含める必要があります。 [修正する必要があります]

  • ボットは、アプリのインストール時にトリガーされたときに、複数のウェルカム メッセージを送信しないでください。 [修正する必要があります]

    図は、アプリのインストール時に複数のウェルカム メッセージをトリガーするボットの例を示しています。

  • ウェルカム メッセージのアプリ名は、アプリ マニフェストのアプリ名と一致している必要があります。 [修正する必要があります]

    ウェルカム メッセージのアプリ名とアプリ マニフェストのアプリ名が一致しない例を示す図。

  • ウェルカム メッセージでは、アプリが特定の相互運用性を提供しない限り、競合他社のチャット ベースのコラボレーション プラットフォーム名を表示しないでください。

  • ウェルカム メッセージは、ユーザーを別の Teams アプリにリダイレクトしないようにする必要があります。代わりに、ウェルカム メッセージはユーザーを微調整して最初のタスクを完了し、アプリでサポートされているすべてのボット コマンドを簡単に説明する必要があります。 [修正する必要があります]

  • ウェルカム メッセージには、AppSource を含むアプリ マーケットプレースへのリンクを含めることはできません。 [修正する必要があります]

  • アプリに管理者主導のインストールが必要な複雑な構成ワークフローがあり、直感的ですぐに利用できるサインアップ フローがない場合、またはユーザーが Teams エクスペリエンスの外部で構成手順を完了して戻す必要がある場合、ボットはインストール後にチームまたはグループ チャット スコープでプロアクティブなウェルカム メッセージを送信する必要があります。 [修正する必要があります]

  • ボットがチャネルでウェルカム メッセージを送信する場合は、ユーザーに個別に送信しないでください (スパムと見なされます)。 メッセージには、ボットを追加したユーザーもメンションしなければなりません。 [修正に適しています]

ヒント

個別のユーザーへのウェルカム メッセージでは、カルーセル ツアーを使用してボットやその他のアプリ機能の概要を効果的に伝えることにより、ユーザーにボット コマンドを試すように促すことができます。 たとえば、「タスクを作成する」などです。


ボット メッセージのスパム化

ボットは、短時間で複数のメッセージを送信することで、ユーザーをスパムしないようにする必要があります。

  • チャネルやチャットでのボットメッセージ: 複数の投稿を同時に行うことはスパム行為となるので避けてください。 1 つの記事を作成し、同じスレッドに返信してください。 [修正する必要があります]

    validation-bot-message-spam-one-message

    validation-bot-message-spam-multiple-message

  • 個人用アプリでのボット メッセージ:

    • 短時間のうちに複数のメッセージを送信しないでください。 [修正する必要があります]

      図は、複数のメッセージを連続して送信するボットの例を示しています。

    • 情報が完結した 1 件のメッセージを送信してください。 [修正する必要があります]

    • 単一のワークフローの反復を複数の会話にまたがって実行することは避けてください。 [修正する必要があります]

    • フォーム (またはダイアログ) を使用して、ユーザーから一度にすべての入力を収集します。 [修正する必要があります]

    • 自然言語処理 (NLP) ベースの会話型チャットボットを利用すれば、マルチターンの会話により話し合いの進行が促進され、ワークフローを完了させることができます。

      validation-bot-message-using-task-module

      図は、複数ターン メッセージを使用して 1 つの会話を完了するボットの例を示しています。

  • ウェルカム メッセージ: 一定の間隔で同じウェルカム メッセージを繰り返してはいけません。 たとえば、チームに新しいメンバーが加わったとき、他のメンバーにウェルカム メッセージを送ることは、スパム行為とみなされます。 新しいメンバーへのメッセージは個人的に送信してください。 [修正する必要があります]


ボット通知

ボット通知には、ボットに定義された範囲 (チーム、チャット、個人用) に関連するコンテンツを含める必要があります。 [修正する必要があります]

validation-bot-notification-relevant

validation-bot-notification-not-relevant


ボットとアダプティブ カード

アダプティブ カードは、ボット メッセージを表示するのに最適な方法です。 カードは簡素なものに限定してください。アクションは最大 6 つまでとします。 より多くのコンテンツを表示するには、ダイアログまたはタブの使用を検討してください。

カードの詳細については、以下を参照してください。

ボット エクスペリエンスは、モバイル上でレスポンシブ対応でなければなりません。 ボットの応答では、可能な限り、ワークフローを前に進める方法が提供されている必要があります。 ボットはレスポンシブ対応であり、かつ失敗時には適切なエラー メッセージが表示されなければなりません。 コラボレーション中のトリガーに基づいて、個人スコープからユーザーに対して送信されるボット メッセージからは、(メッセージの発信元を含む) コンテキスト情報が提供される必要があります。


通知専用ボット

通知専用ボットによって構成されたアプリでは、コア アプリまたはバックエンドの特定のトリガーまたはイベントによってユーザーへの通知がトリガーされ、それによりユーザーに価値が提供されます。 たとえば、営業チームに対して、新しい潜在顧客や見込み客がフォローアップのために通知されてリストに追加される場合などがその例となります。 高品質の通知専用ボットは、ワークフローの完了やアラートなど、特定のイベント完了時にユーザーに定期的に通知します。

ヒント

投稿されたカード内に表示される情報を見直し、ユーザーが選択できる基本的なアクションのすべてが、Teams から離れることなく利用できるような形で提供されていることを確認してください (適用される機能の複雑さに関わらず)。


ボット メタデータ情報
  • アプリ マニフェスト内のボット情報 (ボット名、ロゴ、プライバシー リンク、サービス利用規約のリンク) は、Bot Framework メタデータと一致している必要があります。 [修正する必要があります]

  • アプリ マニフェストのボット ID が、アプリの最新の Teams ストア公開バージョンのボット ID と一致していることを確認します。 アプリの更新でボット ID を変更すると、アプリの既存ユーザーのボットに対するすべてのユーザー操作履歴が永続的に失われ、新しいボット ID で新しい会話チェーンが開始されます。 [修正する必要があります]

  • アプリ名、メタデータ、ボットのウェルカム メッセージ、またはボットの応答に対する変更は、新しい名前で更新する必要があります。 [修正する必要があります]

  • ボットウェルカム メッセージまたはボット応答のアプリ名は、アプリ マニフェストのアプリ名と一致する必要があります。 [修正する必要があります]


コラボレーション スコープ内のボット
  • チーム固有のトリガーに対して 1 対 1 のチャットとしてユーザーにプロアクティブな通知を送信するためのチーム名簿を取得するための、チャネルまたはグループ チャット スコープでのボットのインストールは許可されません。 たとえば、出会い系アプリなどです。 [修正する必要があります]

  • チャネルまたはグループ チャット内のボットは、1 対 1 のチャットとしてユーザーにプロアクティブな通知を送信するためのメッセージまたは投稿を取得するためにのみ使用されます。 [修正する必要があります]

  • コラボレーション スコープにインストールされたボットは、コラボレーション スコープにユーザー値を提供する必要があります。 [修正する必要があります]

先頭に戻る

メッセージ拡張機能

このセクションは、Microsoft コマーシャル マーケットプレース ポリシー 番号 1140.4.4 に沿ったものです。

アプリにメッセージ拡張機能が含まれている場合は、これらのガイドラインに従っていることを確認します。

ヒント

高品質なアプリ エクスペリエンスを作成するための詳細については、「Teams メッセージ拡張機能デザインのガイドライン」を参照してください。


メッセージング拡張機能のデザインのガイドライン
  • Teams アプリがメッセージング拡張機能を使用している場合、アプリは メッセージング拡張機能のデザイン ガイドラインに従う必要があります。

    図は、拡張機能のガイドラインを満たしていないアプリの例を示しています。

  • メッセージング拡張機能は、会話から離れることなく、アプリのコンテンツを挿入したり、メッセージに対して操作したりするためのショートカットです。 操作を効果的に完了できるようメッセージング拡張機能をシンプルに保ち、必要なコンポーネントのみを表示します。 完全な Web サイトは、メッセージング拡張機能内で I フレーム化しないでください。 [修正する必要があります]

  • メッセージング拡張機能のアダプティブ カードのプレビュー イメージは、正しく読み込まれる必要があります。 [修正する必要があります]

    図は、アダプティブ カードでのプレビュー 画像の読み込みの例を示しています。

    図は、アダプティブ カードに読み込まれていないプレビュー イメージを示しています。

  • メッセージング拡張機能の応答カードには、エンド ユーザーの混乱を避けるためにアプリ アイコンが含まれている必要があります。 [修正する必要があります]

  • アプリの機能が壊れていない必要があります。 アプリは、ユーザーがメッセージング拡張機能でワークフローを完了できないように、またはユーザーをブロックする必要があります。 [修正する必要があります]

  • メッセージング拡張機能は、グループ チャットとチャネル スコープで意図したとおりに応答するか、機能する必要があります。 [修正する必要があります]

  • ユーザーがメッセージング拡張機能からサインインまたはサインアウトする方法を含める必要があります。 [修正する必要があります]

  • OpenAPI URL を使用するメッセージ拡張機能は、API 呼び出しでリダイレクトを提供してはなりません。 実際の API 呼び出しは、ルート ドメインの同じドメインまたはサブドメインから提供する必要があります。


操作ベースのメッセージ拡張機能のアクション コマンド

操作ベースのメッセージ拡張機能では、以下のことを行う必要があります。

  • ユーザーがサインインなどの中間的な手順を行うことなく、メッセージに対するアクションを起こせるようにする。

    validation-messaging-extension-no-intermediate-steps

    validation-messaging-extension-intermediate-steps-available

  • メッセージ コンテキストを次の作業状態に渡す。 [修正する必要があります]

    validation-messaging-extension-app-passes-messages

    validation-messaging-extension-app-doesnot-pass-messages

  • アプリ内のチャット メッセージ、チャネルへの投稿、アクションの呼び出しによってトリガーされるアクション コマンドの名前には、一般動詞による表記だけではなく、ホスト アプリの名前も含めます。 たとえば、[会議を開始] ではなく [Skype 会議を開始]、[ファイルをアップロード] ではなく [DocuSign にファイルをアップロード] とします。 [修正に適しています]

    図は、アクション コマンドのホスト アプリ名の例を示しています。

    図は、アクション コマンドのジェネリック動詞の例を示しています。

  • メッセージ アクションを呼び出すと、ユーザーはワークフローを完了できる必要があります。 メッセージ アクションを意図したとおりに機能させるために、エラー、空白の応答、または継続的な読み込みインジケーターは存在してはなりません。 [修正する必要があります]

    図は、ボットがアクション コマンドを呼び出すときの継続的な読み込みインジケーターの例を示しています。

  • 重複するアクション コマンドは存在してはなりません。 [修正する必要があります]

  • メッセージ アクションでは、ユーザーが無効な応答なしで意図したとおりにワークフローを完了できるようにする必要があります。 [修正する必要があります]

  • アクションベースのメッセージング拡張機能のみを持つアプリは、次の終了状態である必要があります。

    • メッセージ拡張機能が呼び出されるコンテキストで、またはユーザー シナリオに基づいて 1 対 1 ボット チャットで、関連するアクションを通知として投稿します。 [修正する必要があります]

    • 実行されたアクションに基づいて、ユーザーがカードを他のユーザーと共有できるようにします。 これは、アプリがサイレント アクションを実行しないようにするためです。 たとえば、チケットはチャネル内のメッセージに基づいて作成されますが、アプリは通知を送信しないか、チケットの作成後にチケットの詳細を共有するようにユーザーに要求する方法を提供しません。 [修正する必要があります]


プレビュー リンク (リンク展開)

[修正する必要があります]

  • アプリがアプリ マニフェストで プロパティをsupportsAnonymizedPayloads宣言していて、ユーザーがアプリをインストールしていない場合、アプリ リンクの展開を解除し、カードが選択された後にアプリの追加ダイアログを表示する必要があります。 [修正する必要があります]

  • メッセージ拡張機能では、認識されたリンクが Teams の作成ボックスでプレビューされます。 制御外のドメイン (絶対 URL、ワイルドカードのいずれについても) を追加してはいけません。 たとえば、yourapp.onmicrosoft.com は有効ですが、*.onmicrosoft.com は無効です。 トップレベルの ドメインも禁止です。 たとえば、*.com および *.org が禁止となります。 [修正する必要があります]

  • アプリは、アプリ マニフェストのリンク展開セクションで messageHandler 、アプリ発行元の直接所有権の下にあるもののみを宣言する必要があります。 [修正する必要があります] を含*.botframework.com.めることはできません


検索コマンド
  • 検索ベースのメッセージ拡張機能では、ユーザーが効果的に検索できるようなテキストが用意されている必要があります。 [修正する必要があります]

    図は、ユーザーが効果的に検索できるようにするヘルプ テキストを含むメッセージ拡張機能の例を示しています。

    図は、ユーザーが効果的に検索できるようにするヘルプ テキストのないメッセージ拡張機能の例を示しています。

  • @mention 実行可能ファイルは、明確で、理解しやすく、読みやすいものである必要があります。

    validation-search-commands-unclear-executable

先頭に戻る

ダイアログ

[修正する必要があります]

このセクションは、Microsoft コマーシャル マーケットプレース ポリシー 番号 1140.4.5 に沿ったものです。

詳細を知るために展開する

ダイアログ (TeamsJS v1.x ではタスク モジュールと呼ばれます) には、アイコンと、関連付けられているアプリの短い名前を含める必要があります。 ダイアログでは、アプリ全体を埋め込む必要はありません。また、特定のアクションを完了するために必要なコンポーネントのみが表示されます。

詳細については、「 Teams ダイアログの設計ガイドライン」を参照してください。

validation-task-module-displays-component

validation-task-module-embed-app

ヒント

高品質なアプリ エクスペリエンスを作成するための詳細については、「Teams タスク モジュール デザインのガイドライン」を参照してください。

先頭に戻る

ミーディング拡張機能

このセクションは、Microsoft コマーシャル マーケットプレース ポリシー 番号 1140.4.6 に沿ったものです。

ヒント

高品質なアプリ エクスペリエンスを作成するための詳細については、「Teams ミーティング拡張機能デザインのガイドライン」を参照してください。


会議拡張機能のデザイン ガイドライン
  • Teams アプリは、会議拡張機能のデザイン ガイドラインに従う必要があります。

  • 会議中アプリのエクスペリエンスでは、会議中のタブ、ダイアログボックス、会議中のステージへの共有機能を使って、会議中に参加者を惹きつけることができます。 アプリで Teams 会議拡張機能がサポートされている場合は、Teams 会議エクスペリエンスに合わせて応答性の高い会議内エクスペリエンスを提供する必要があります。 [修正する必要があります]

  • 会議機能拡張アプリは、Teams 会議エクスペリエンスに合わせて応答性の高い会議内エクスペリエンスを提供する必要があります。 会議内エクスペリエンスは、会議の拡張性をサポートする Teams アプリでは必須ですが、会議前および会議後のエクスペリエンスは必須ではありません。 [修正する必要があります]

    • 会議前のエクスペリエンスにおいてユーザーは、検索して見つかった会議アプリを追加できます。 またユーザーは、会議前のタスク (会議の参加者に対してアンケートを実施する機能など) を利用することもできます。 アプリが会議前のエクスペリエンスを提供する場合は、会議のワークフローに関連するものでなければなりません。

    • 会議後のアプリ エクスペリエンスでは、ユーザーは、投票されたアンケート結果、フィードバック、その他のアプリ コンテンツなど、会議の結果を表示できます。 アプリが会議後のエクスペリエンスを提供する場合は、会議のワークフローに関連するものでなければなりません。

    • 会議中のアプリ エクスペリエンスでは、会議中に会議参加者を積極的に関与させ、すべての出席者の会議エクスペリエンスを強化できます。 アプリのコア ユーザー ワークフローを完了するために、出席者を Teams 会議の外に出すことはできません。

    図は、主要なアプリ機能を完了するために Teams の外部にユーザーをリダイレクトする会議内エクスペリエンスの例を示しています。

  • アプリによって、Teams のカスタムの Together モード シーン以上の価値が提供されなければなりません。 [修正する必要があります]

  • Teams モバイルでの会議に対してアプリを有効にするには、アプリ マニフェストで、 および meetingDetailsTabmeetingSidePanelmeetingChatTabconfigurableTabsのスコープとして をコンテキスト プロパティとして宣言groupChatする必要があります。 [修正する必要があります]

  • 会議キャンバスは、会議出席者を停止してはなりません。 会議キャンバスには、地域固有の依存関係などのアプリの制限に対する正常なエラー メッセージを表示する必要があります。 [修正する必要があります]

  • 会議出席者が混乱しないよう会議キャンバスのヘッダーに正しいアプリ名を表示する必要があります。 [修正する必要があります]

  • ユーザーが会議拡張機能からサインアウトまたはログアウトするためのオプションを含める必要があります。 [修正する必要があります]

  • モバイル プラットフォームの会議タブには、関連するワークフローが含まれている必要があります。 会議タブに空白のページを表示しないでください。[修正する必要があります]

  • 会議ステージは、焦点を絞った直感的な共同作業参加キャンバスです。 会議ステージでは、完全な Web サイト エクスペリエンスを埋め込む必要はありません。 [修正する必要があります]

  • アプリは、ユーザーを停止させたり、会議シナリオでワークフローの完了をブロックしたりする継続的な読み込み画面、エラー、または壊れた機能を表示してはなりません。 [修正する必要があります]

    図は、アプリ内の連続読み込み画面の例を示しています。

  • 会議の開始時に、アプリで新しい Teams インスタンスを開く必要はありません。 会議キャンバスは、リアルタイムコラボレーションを促進する Teams 機能の拡張機能であり、新しい会議は常にアクティブな Teams インスタンス内で開く必要があります。 [修正する必要があります]

  • 会議アプリは、競合他社のチャット ベースのプラットフォームにリダイレクトすることなく、Microsoft Teams プラットフォーム内でワークフローを完了する必要があります。 [修正する必要があります]

    図は、競合他社のチャット ベースのプラットフォームにリダイレクトするアプリの例を示しています。

  • アプリがロールベースのビューをサポートしていて、すべての参加者が特定のワークフローを使用できない場合は、アプリが開催者のビュー用であることを示すタブとサイドパネルの参加者に適切なメッセージングを実装し、出席者が会議ノート、アクション アイテム、および更新議題を受け取る方法の詳細を提供することをお勧めします。 [修正する必要があります]

    図は、ロールベースのビューの参加者にとって先に進む方法のないアプリの例を示しています。


会議前後のエクスペリエンス
  • 会議前後の画面は、一般的なタブ デザイン ガイドラインに準拠している必要があります。 詳細については、「Teams デザイン ガイドライン」を参照してください。 [修正する必要があります]

  • 複数の項目を表示する場合に、タブのレイアウトが整理されている必要があります。 たとえば、10 件を超える投票またはアンケートについては、「レイアウトの例」を参照してください。 [修正する必要があります]

  • アプリでアンケートや投票の結果がエクスポートされた場合に、「結果が正常にダウンロードされました」と表示してユーザーに通知する必要があります。 [修正する必要があります]

    図は、タブ デザイン ガイドラインに従っていないタブの例を示しています。


会議中のエクスペリエンス
  • アプリは、会議中のみダーク テーマを使用する必要があります。 詳細については、「Teams デザイン ガイドライン」を参照してください。 [修正する必要があります]

  • 会議中にアプリ アイコンにカーソルを合わせると、ツールヒントにアプリ名が表示される必要があります。 [修正する必要があります]

    validation-in-meeting-exp-display-app-names

  • メッセージ拡張機能は、会議中も会議以外のときと同じように機能する必要があります。 [修正する必要があります]


会議中のタブ
  • レスポンシブ対応である必要があります。 [修正する必要があります]

  • パディングとコンポーネントのサイズを一定に保つ必要があります。 [修正する必要があります]

  • 複数のレベルのナビゲーションがある場合は、戻るボタンが必要です。 [修正する必要があります]

    図は、[戻る] ボタンが表示されている例を示しています。

    図は、[戻る] ボタンが存在しない例を示しています。

  • 閉じるボタンが複数あってはいけません。 タブを閉じるには組み込みのヘッダー ボタンが既に存在するため、ユーザーが混乱する可能性があります。[修正する必要があります]

  • 水平スクロールを使用しないでください。 [修正する必要があります]

    図は、垂直スクロールを含む会議内タブの例を示しています。

    図は、水平スクロールを含む会議内タブの例を示しています。


会議中のダイアログ
  • 頻繁に使用してはなければなりません。簡素でかつタスク指向性のあるシナリオに対してのみ使用してください。 [修正する必要があります]

  • コンテンツは 1 列に表示されていなければなりません。また、複数のナビゲーション レベルがあってはなりません。 [修正する必要があります]

    図は、会議内ダイアログの単一列レイアウトの例を示しています。

    図は、会議内ダイアログの複数の列レイアウトの例を示しています。

  • ダイアログを使用しないでください。 [修正する必要があります]

  • 会議ステージの中心に位置合わせする必要があります。 [修正する必要があります]

    図は、会議中のダイアログが会議ステージの中心と一致しない例を示しています。

  • ユーザーがボタンを選択したり、アクションを実行したりした後に閉じる必要があります。 [修正する必要があります]

  • 一緒モード: シーン構築エクスペリエンスに関する次のベスト プラクティスを考慮してください: [修正する必要があります]

    • 画像はすべて PNG 形式で作成します。
    • すべてのイメージをまとめる最終的なパッケージは、1920x1080 の解像度を超えてはなりません。 解像度は偶数です。 この解像度は、シーンを正常に表示するための必要条件です。
    • シーンの最大サイズは 10 MB です。
    • 各画像の最大サイズは 5 MB です。 シーンは、複数の画像のコレクションです。 制限は、個々の画像に対するものです。
    • 必要に応じて [透明] を選択します。 このチェック ボックスは、画像が選択されている場合に右パネルで使用できます。 シーン内で重なり合っている画像には、画像が重なっていることを示すために、「Transparent」とマークする必要があります。

共有会議ステージ

shareAppContentToStage API を使用するには、正しい RSC アクセス許可を宣言する必要があります。 アプリ マニフェストで、 プロパティを構成する authorization 必要があります。 フィールドのように プロパティを name および type プロパティとしてDelegatedMeetingStage.Write.ChatresourceSpecific更新します。 [修正する必要があります]

Shared meeting stage 機能は、Teams のデスクトップ アプリからのみ起動できます。 ただし、Shared meeting stage の使用エクスペリエンスは、モバイル デバイスで表示する場合にも問題なく使用可能である必要があります。 [修正する必要があります]

先頭に戻る

Connector

  1. コネクタ名は、アプリ内およびアプリ マニフェスト内のアプリ名と同じである必要があります。

    アプリとアプリ マニフェストの間のアプリ名の不一致を示すスクリーンショット。

  2. コネクタの構成中にエラーが発生してはいけません。

    ユーザーがコネクタを構成している間のエラーを示すスクリーンショット。

通知

このセクションは、Microsoft コマーシャル マーケットプレース ポリシー 番号 1140.4.7 に沿ったものです。

アプリで Microsoft Graph によって提供されるアクティビティ フィード API を使用する場合は、次のガイドラインに従っていることを確認します。

ヒント

アプリが通知シナリオをサポートしている場合、たとえば 1 日または 1 か月後など、長い間隔の後に通知がトリガーされます。 確認のために送信する前に、バックグラウンドでこのような通知をトリガーして通知をテストしてください。



通知デザイン ガイドライン
  • Teams アプリは 、アクティビティ フィード通知のデザイン ガイドラインに従う必要があります。

  • ユーザーが Teams アクティビティ フィードで通知を選択した後、無関係、不適切、応答しない、または壊れたワークフローを存在させてはいけません。 アクティビティ フィード通知を選択した後、ユーザーがワークフローを完了できないようにする必要があります。 [修正する必要があります]

  • エンドユーザーが混乱することなく通知のソースまたはトリガーを理解できるように、アクティビティ フィード通知にアプリの名前を含めます。 [修正する必要があります]

  • アプリは、アプリの長い説明、アプリの最初の実行エクスペリエンス、およびアプリ マニフェストで宣言されている activityTypes シナリオで説明されているすべての通知シナリオの通知をトリガーする必要があります。 [修正する必要があります]

  • 通知は、ユーザーのアクションから 5 秒以内に表示される必要があります。 [修正する必要があります]

  • 通知の制限 (ある場合) は、アプリの詳細説明またはアプリの最初の実行エクスペリエンスで呼び出す必要があります。 [修正する必要があります]


全般
  • アプリ構成で指定されたすべての通知トリガーが動作する必要があります。 [修正する必要があります]
  • 通知は、アプリにおいて構成されているすべての言語についてローカライズされていなければなりません。 [修正する必要があります]
  • 通知は、ユーザーのアクションから 5 秒以内に表示される必要があります。 [修正する必要があります]
  • 通知は、アプリが互換性のあるすべてのプラットフォームでサポートされている言語に従ってローカライズする必要があります。 [修正する必要があります]

アバター
  • 通知のアバターは、アプリのカラー アイコンと一致している必要があります。 [修正する必要があります]
  • ユーザーによってトリガーされた通知には、そのユーザーのアバターが表示されなければなりません。 [修正する必要があります]

スパム
  • アプリは、1 分あたり 10 件を超える通知をユーザーに送信しないでください。 [修正する必要があります]
  • ボットとアクティビティ フィードは、重複する通知をトリガーしてはなりません。 [修正する必要があります]
  • 通知は、ユーザーに何らかの価値を提供するものである必要があります。些細なイベントや無関係なイベントに使用してはいけません。 [修正する必要があります]

ナビゲーションとレイアウト
  • 通知は、Teams アクティビティ フィードのレイアウトとエクスペリエンスに関するガイドラインに準拠する必要があります。 [修正する必要があります]
  • 通知を選択したユーザーは、Teams 内の関連コンテンツに誘導されなければなりません。 [修正する必要があります]

先頭に戻る

Microsoft 365 アプリ コンプライアンス プログラム

このセクションは、Microsoft コマーシャル マーケットプレース ポリシー 番号 1140.6 に沿ったものです。

詳細を知るために展開する

Microsoft 365 アプリ コンプライアンス プログラムは、アプリに関するセキュリティおよびコンプライアンス情報を評価することにより、組織がリスクを評価し管理することを目的としています。 アプリを Teams ストアに発行する場合は、プログラムの次のレベルを完了する必要があります。

  • 発行元の検証: 管理者とエンド ユーザーが、Microsoft ID プラットフォームを利用するアプリの開発者の信頼性について理解する上で役立ちます。 完了すると、Microsoft Entra同意ダイアログやその他の画面に、青い検証済みバッジが表示されます。 詳細については、「アプリを発行元確認済みとしてマークする」を参照してください。 [修正する必要があります]

    図は、Microsoft Entra同意ダイアログの青い検証済みバッジの例を示しています。

  • 発行元の構成証明: 潜在的な顧客がアプリの使用を適切な情報に基づいて判断できるように、一般的な情報、データの取り扱い、セキュリティとコンプライアンスに関する情報を共有するプロセス。 [修正に適しています]

以前に一覧表示されていないアプリの場合、アプリが Teams ストアで使用できるようになるまで、パブリッシャー構成証明を完了することはできません。 既に一覧表示されているアプリを更新する場合は、アプリの最新バージョンを送信する前に Publisher 構成証明 を完了してください。

先頭に戻る

広告

このセクションは、Microsoft 商用マーケットプレース ポリシー 番号 1140.7 に沿ったものです。

動的広告、バナー広告、メッセージ内の広告など、アプリで広告を表示することはできません。 [修正する必要があります]

図は、Teams での広告の失敗シナリオの例を示しています。

先頭に戻る

暗号通貨ベースのアプリ

アプリが配布されるすべての法律への準拠を示す必要があります(アプリの場合: [修正する必要があります]

  • アプリ内での暗号化トランザクションまたは転送を容易する場合。

  • 暗号通貨関連のコンテンツを促進する場合。

  • ユーザーが保存されている暗号通貨を保存またはアクセスできるようにする場合。

  • ユーザーが Teams プラットフォームの外部で暗号通貨ベースのトランザクションまたは転送を完了することを奨励または有効にする場合。

  • 暗号通貨トークンのマイニングを奨励または促進する場合。

  • Initial Coin Offerings へのユーザー参加を容易にする場合。

  • タスクを完了するための暗号通貨トークンでユーザーに報酬を与えたりインセンティブを与えたりする場合。

Microsoft の内部レビュー後、コンプライアンス デモが十分であれば、Microsoft はアプリの認定をさらに進める可能性があります。 コンプライアンスデモが不十分な場合、Microsoft はアプリの認定を続行しない決定を通知します。

先頭に戻る

アプリの機能

  • アプリ内のワークフローまたはコンテンツは、スコープに関連付けられている必要があります。 [修正する必要があります]
  • すべてのアプリ機能が機能している必要があり、AppSource またはアプリ マニフェストの長い説明で説明されているように正常に動作する必要があります。 [修正する必要があります]
  • アプリは、ユーザーの環境でファイルまたは実行可能ファイルをダウンロードする前に、常にユーザーに通知する必要があります。 テキストベースまたはその他の方法で、ユーザーのアクションに応じてファイルまたは実行ファイルがダウンロードされることをユーザーに明示するアクションへの呼び出し (CTA) は、アプリ内で許可されています。 [修正する必要があります]
  • リージョンの依存関係を持つアプリは、サポートされていないリージョンで使用しようとすると、該当するすべての機能で正常なエラー メッセージをユーザーに通知する必要があります。 [修正する必要があります]

先頭に戻る

モバイル エクスペリエンス

  • モバイル アドインは無料である必要があります。 アップセル、オンライン ストア、またはその他の支払い要求を促進するアプリ内コンテンツやリンクは必要ありません。 アプリに必要なアカウントには使用料金はかからず、期限が限られている場合は、支払う必要があることを示すコンテンツを含めてはいけません。 [修正する必要があります]

    図は、支払いを求めるモバイル アドインの例を示しています。

  • "無料"、"無料試用版"、または "無料で試す" という単語は、制限や考慮なしにデスクトップまたは Web アプリのエクスペリエンスで使用できます。

  • 試用版またはアプリのアップグレードというコンテキストでプレーンテキストとして "無料" という単語は、モバイルで使用できます。

  • 支払い情報や価格情報のないランディング ページにつながるリンクを使用して、試用版またはアプリのアップグレードのコンテキストで "無料" という単語は、モバイルで使用できます。 モバイルでは、アプリが "有料" であるを通知するプレーンテキストは、モバイルで使用できます。

  • 試用版またはアプリのアップグレードのコンテキストで "無料" という単語をプレーンテキストとして使用し、価格の詳細に関連付けることはできません。 [修正する必要があります]

  • 試用版またはアプリのアップグレードのコンテキストで "無料" という単語を使用し、モバイルでの価格情報や支払いの詳細を含むランディング ページにつながるリンクに関連付けることはできません。 [修正する必要があります]

  • 画像、テキスト、リンクなど、あらゆる形式のモバイルでの価格の詳細は使えません。 モバイルでの "プランの表示" などの CTA は使えません。 プランに関して価格の詳細情報はないが、連絡先リンクまたはメールのある情報は、モバイルでは許可されていません。 連絡先の詳細がリンクされているテキスト、または有料アップグレードに関連するテキストは、モバイルでは許可されません。 物理的な商品の支払はモバイルで許可されています。 たとえば、アプリでタクシーを予約するための支払いを行うことができます。 [修正する必要があります]

    図は、モバイルでの価格詳細の例を示しています。

  • アプリ内のデジタル商品の支払は、モバイルでは許可されません。 [修正する必要があります]

    図は、モバイルでのデジタル商品の支払いの例を示しています。

  • Teams アプリは、適切なクロスデバイス モバイル エクスペリエンスを提供する必要があります。 [修正する必要があります]

  • モバイルでサポートされていない機能は、ユーザーを停止させず、該当する場合は正常なエラー メッセージを提供する必要があります。 [修正する必要があります]

先頭に戻る

Microsoft 365 クライアント全体で拡張されたアプリ

全般

  • Microsoft 365 クライアント全体で Teams アプリを拡張することを目的としたアプリでは、スキーマ バージョン 1.13 以降を使用する必要があります。

  • アプリのサポート URL には、Microsoft 365 クライアント全体で拡張可能な Teams アプリに関連するコンテンツが含まれている必要があり、1 つのクライアントのみを呼び出す必要があります。

  • アプリの説明で、Microsoft 365 クライアント全体で拡張可能な Teams アプリに関連する参照を指定する必要があります。

  • Teams アプリが Microsoft 365 クライアント全体で拡張可能な場合は、アプリの開始、サインイン、サインアップ、サインアウト、ヘルプ ページ、または転送メッセージで提供されるコンテンツが、すべてのクライアントを呼び出す必要があります。

互換性

Microsoft 365 クライアント全体で拡張可能な Teams アプリは、Microsoft Edge および Google Chrome クライアントの最新バージョンで完全に応答性が高く機能している必要があります。 ユーザーは、次の個人用タブまたはメッセージ拡張機能を呼び出して引き続き使用できる必要があります。

  • Outlook for Windows および Web。
  • デスクトップ、Web、Android 上の Microsoft 365。
  • デスクトップと Web 上のMicrosoft Teams。
  • Android と iOS のMicrosoft Teams。

モバイル エクスペリエンス

ユーザーは、モバイル上の Microsoft 365 クライアント内のアクション ポップアップ メニューからアプリを起動できる必要があります。 アプリ名は、アクション バーに正しく表示する必要があります。 [修正する必要があります]

アクションポップアップからのアプリ起動

ユーザーは、モバイル上の Microsoft 365 クライアント内の複数の静的タブを正常に起動して切り替えることができる必要があります。 タブが正しく読み込まれている必要があります。 3 つ以上の静的タブがある場合は、[ その 他] セクションの下に残りのタブを表示する必要があります。 [修正する必要があります]

マルチ タブ エクスペリエンス

アプリで SSO を使用する場合は、ユーザーを正常に認証する必要があります。 SSO を使用すると、ユーザーは 1 つの資格情報セットを使用して複数の独立したソフトウェア システムにサインインできます。 ユーザーは、異なる資格情報を使用して認証することなく、必要なすべてのアプリケーションにアクセスできます。 [修正する必要があります]

アプリ認証

ユーザーがモバイル上の Microsoft 365 クライアント内で切り替えまたはログアウトされた場合、アプリはユーザー アカウント インスタンスを終了する必要があります。 [修正する必要があります]

アカウントの切り替えとログアウトのエクスペリエンス

  • ユーザーは、以前の作業状態に戻ることができる必要があります。 ユーザーがルート ページ上にある場合、バック ナビゲーションはモバイル上の Microsoft 365 クライアント内のアプリ インスタンスを終了する必要があります。 [修正する必要があります]

  • ワークフローへのディープ リンクをサポートするアプリは、ユーザーを適切なランディング ページ エクスペリエンスにリダイレクトできる必要があります。 [修正する必要があります]

タブ ナビゲーション

  • 進行状況インジケーターは、アプリが読み込まれているときに表示され、アプリが読み込まれた後に自動的に閉じる必要があります。 [修正する必要があります]

  • アプリがインコヒーレントまたは壊れたネットワーク、タイムアウト、認証エラーなどのインスタンスで読み込みに失敗した場合は、エラー画面が表示される必要があります。 [修正する必要があります]

先頭に戻る

Microsoft 365 Copilotのプラグインとして拡張可能な Teams アプリ

プラグインは LLM 動作を操作してはならない

アプリ、パラメーター、およびコマンドの簡単な説明には、次を含めてはなりません。

  1. インストラクション フレーズ。 たとえば、ユーザーが X と言った場合、無視、削除、リセット、新しい指示、太字で回答する、何も印刷しないなどです。
  2. 詳細、花、またはマーケティング言語。
  3. #1驚くべきまたは最適ななどの最上級の要求。
  4. URL、絵文字、または非表示文字 (16 進数、バイナリ、型破りな記号など)。
  5. 文法と句読点のエラー。

ユーザーの認識

アプリの長い説明では、次の内容を明確に呼び出す必要があります。

  • アプリとMicrosoft 365 Copilotの互換性。 たとえば、Microsoft 365 Copilotで Contoso を使用して、タスクを検索して要約します。

  • ユーザーがMicrosoft 365 Copilotでメッセージ拡張プラグインを使用する方法を少なくとも 1 つのプロンプトで指定します。 たとえば、今週 Contoso で割り当てられた優先度の高いチケットは何ですか。

    Microsoft 365 Copilotのプラグインとしてのメッセージ拡張機能の使用に関するサンプル プロンプトの例を示すパス シナリオを示すスクリーンショット。

    スクリーンショットは、Microsoft 365 Copilotのプラグインとしてのメッセージ拡張機能の使用に関するサンプル プロンプトの例のない失敗シナリオを示しています。

応答品質

  • アダプティブ カード応答 Microsoft 365 Copilotの必須フィールドには、情報タイトルと、少なくとも 2 つの追加の有用なフィールド (変更日、作成者、状態、フラグなど) が含まれている必要があります。 プレビューとコンテンツの両方が 1 つの応答の一部である必要があります。

    スクリーンショットは、プレビューとコンテンツを同じ応答に含むMicrosoft 365 Copilotの応答を示すサンプル アプリの例を示しています。

  • Microsoft 365 Copilot応答のアダプティブ カードには、少なくとも 1 つのアクション ボタンが必要です。

  • 応答アダプティブ カードに存在するアクション ボタンMicrosoft 365 Copilot機能している必要があります。

    アダプティブ カード応答の情報タイトル、追加のユーザー フィールド、アクション ボタンの例を示すスクリーンショット。

  • Microsoft 365 Copilotは正確に応答する必要があり、ユーザーが 1 つのパラメーターを指定してプロンプトを出したときにエラーを表示しないようにする必要があります。

  • Microsoft 365 Copilotは正確に応答する必要があり、ユーザーが複数のパラメーターを指定してプロンプトを出したときにエラーが表示されない必要があります。

  • Microsoft 365 Copilotは正確に応答する必要があり、ユーザーがフォローアップを求められたときにエラーが表示されない必要があります。

  • メッセージ拡張機能には、Microsoft 365 Copilotでのユーザー エクスペリエンスを強化するために、少なくとも 2 つのパラメーターが含まれている必要があります。

先頭に戻る

次の手順

関連項目