Microsoft Teamsの「Slash commands for apps」は、チャットやチャネルの投稿作成ボックスで / を入力し、Teamsアプリやエージェント、ワークフローを直接呼び出せるようにする機能です。ポイントは、Teams上でアプリを探して開くのではなく、会話を書いている場所からそのまま業務アクションを起動できるようになることです。
Microsoft 365 Roadmap ID 495002として公開されている公式情報では、対象サービスはMicrosoft Teams、状態は「In development」、一般提供予定は2026年7月、対象クラウドはWorldwide、対象プラットフォームはDesktopとMacとされています。(Microsoft) 管理者はTeamsアプリの利用ポリシーや公開範囲、開発者はアプリやエージェントがスラッシュコマンド経由で呼び出されたときのユーザー体験を確認しておく必要があります。
Microsoft TeamsのSlash commands for appsで何が変わるのか
Slash commands for appsは、Teamsのチャットやチャネルにある投稿作成欄から、アプリ連携をより短い操作で実行できるようにする変更です。
従来、Teamsでアプリを使う場合は、アプリを開く、タブに移動する、メッセージ拡張機能を探す、ボットにメンションする、といった操作が必要になることがありました。今回の機能では、ユーザーが入力欄で / を打つことを起点に、アプリ、エージェント、ワークフローなどを呼び出せるようになります。
公式の説明では、Teamsのチャットとチャネルのcompose boxから、好みのアプリと直接対話できるようになり、/ を入力してApps and Agentsとの対話やワークフローの呼び出しなどを開始できるとされています。(Microsoft)
つまり、変更の本質は「新しいアプリ画面が増えること」ではありません。Teamsの入力欄が、メッセージを書く場所であると同時に、業務アプリを起動する入口にもなることです。
公式ロードマップで確認できる基本情報
現時点で公式ロードマップから確認できる情報は、次のとおりです。
| 項目 | 内容 |
|---|---|
| Roadmap ID | 495002 |
| 機能名 | Microsoft Teams: Slash commands for apps |
| 対象サービス | Microsoft Teams |
| 状態 | In development |
| 一般提供予定 | 2026年7月 |
| リリースリング | General Availability、Targeted Release |
| 対象プラットフォーム | Desktop、Mac |
| 対象クラウド | Worldwide（Standard Multi-Tenant） |
| 作成日 | 2025年6月2日 |
| 更新日 | 2026年5月14日 UTC |
ロードマップ上の更新日時は2026年5月14日 UTCです。日本時間では2026年5月15日に相当するため、日本国内で確認する場合は「2026年5月15日更新の情報」として扱うのが自然です。(Microsoft)
ただし、Microsoft 365 Roadmapの情報はリリース時期や対象範囲が変更される可能性があります。導入計画を立てる際は、一般提供予定の月だけで判断せず、Microsoft 365管理センターのメッセージセンターやTeams管理センターの設定状況もあわせて確認してください。
想定される利用シーン
Slash commands for appsが使えるようになると、Teams上の作業導線は大きく短縮されます。特に、チャットやチャネルで会話しながら業務処理を進める組織では効果が出やすい機能です。
チャット中にワークフローを起動する
たとえば、上司とのチャットで「この内容を申請に回してください」と言われた場合、ユーザーは別画面を開かずにTeamsの入力欄で / から関連するワークフローを呼び出せるようになる可能性があります。
想定される操作例は次のようなものです。
| 業務シーン | 従来の操作 | Slash commands for apps導入後のイメージ |
|---|---|---|
| 承認依頼 | 承認アプリやPower Automateの画面を開く | チャット入力欄から承認フローを呼び出す |
| タスク登録 | Plannerや外部タスク管理ツールを開く | 会話の流れでタスク作成コマンドを実行する |
| 顧客情報確認 | CRMや業務アプリに移動する | チャネル投稿欄から関連アプリを呼び出す |
| 社内問い合わせ | FAQボットやナレッジベースを探す | / からエージェントを起動して質問する |
重要なのは、Teamsが単なるコミュニケーションツールではなく、業務アプリの操作ハブとしてさらに使いやすくなる点です。
チャネル投稿の文脈を保ったままアプリを使う
チャネルでは、特定のプロジェクトや部署、顧客、障害対応など、文脈が明確な会話が行われます。そこでアプリやワークフローを直接呼び出せるようになると、「どの会話に紐づく操作なのか」が分かりやすくなります。
たとえば、障害対応チャネルでインシデント管理アプリを呼び出す、営業チャネルで顧客管理アプリを起動する、開発チャネルでチケット作成ワークフローを実行する、といった使い方が考えられます。
これは、単にクリック数を減らすだけではありません。会話の文脈を保ったまま処理できるため、入力ミスや二重登録、情報の取り違えを減らす効果も期待できます。
影響を受ける対象者
Slash commands for appsは、Teamsを利用する一般ユーザーだけでなく、Teams管理者、Microsoft 365管理者、アプリ開発者、業務部門の運用担当者にも影響します。
| 対象者 | 主な影響 | 確認すべきこと |
|---|---|---|
| 一般ユーザー | / からアプリやワークフローを呼び出せるようになる | どのアプリが利用可能か、誤操作時の扱い |
| Teams管理者 | アプリ利用範囲やポリシー管理の重要性が増す | Teamsアプリの許可、ブロック、ピン留め、ポリシー |
| Microsoft 365管理者 | 展開時期や対象環境の確認が必要 | メッセージセンター、ロードマップ、対象クラウド |
| 開発者 | アプリが入力欄から呼び出される導線を考慮する必要がある | コマンド名、応答内容、権限、エラー時のUX |
| セキュリティ担当者 | ユーザーがアプリをより簡単に起動できる | 外部アプリ、データ送信、監査、DLPとの整合性 |
| 業務部門の責任者 | 現場の業務フローがTeams起点に変わる | 申請、承認、通知、問い合わせ対応の見直し |
特に注意したいのは、便利になるほど「使ってよいアプリ」と「使ってはいけないアプリ」の境界が曖昧になりやすいことです。管理者は、機能が一般提供されてから慌てて制御するのではなく、事前にTeamsアプリの棚卸しを進めておくべきです。
管理者が確認すべき設定と準備
Slash commands for appsの導入に向けて、管理者が最初に見るべきなのは「どのアプリをTeams上で利用可能にしているか」です。
Teamsアプリの許可・ブロック設定を確認する
Teams管理センターでは、組織内で利用できるアプリを管理できます。Slash commands for appsによってアプリの呼び出し口が増える場合、現在許可しているアプリが本当に業務上必要かを確認しておく必要があります。
確認すべき観点は次のとおりです。
| 確認項目 | 判断基準 |
|---|---|
| Microsoft提供アプリ | 業務で使う機能か、既存ポリシーと矛盾しないか |
| サードパーティアプリ | 提供元、データの取り扱い、利用部門、契約状況を確認する |
| カスタムアプリ | 所有者、保守担当、認証方式、利用対象者を明確にする |
| 使われていないアプリ | 不要であればブロックまたは利用範囲を制限する |
| 試験導入中のアプリ | 本番利用と検証利用をポリシーで分ける |
「Teamsに入っているアプリはすべて安全」と考えるのは危険です。特に外部サービスと連携するアプリは、どのデータがどこに送信されるのかを確認しておく必要があります。
アプリ権限ポリシーを見直す
Slash commands for appsは、入力欄からアプリを呼び出しやすくする機能です。そのため、ユーザー単位、グループ単位でのアプリ権限ポリシーがより重要になります。
たとえば、全社員が利用してよいアプリ、営業部門だけが使うCRM連携アプリ、開発部門だけが使うチケット管理アプリ、管理部門だけが使う承認アプリは、同じポリシーで管理すべきではありません。
実務では、次のように分けると運用しやすくなります。
| ポリシー例 | 対象 | 運用方針 |
|---|---|---|
| 標準ユーザー向け | 全社員 | 最小限の業務共通アプリのみ許可 |
| 部門別ユーザー向け | 営業、開発、人事など | 部門業務に必要なアプリを追加 |
| 検証ユーザー向け | 情シス、先行利用者 | 新機能や新アプリを先行検証 |
| 制限ユーザー向け | 外部共有が多い部門など | 外部連携アプリを厳しく制限 |
全社一律で許可するのではなく、「誰が、どの文脈で、どのアプリを呼び出す必要があるか」で設計することが重要です。
Targeted Releaseの対象ユーザーを整理する
公式情報では、リリースリングにGeneral AvailabilityとTargeted Releaseが含まれています。(Microsoft) Targeted Releaseを利用している組織では、本番展開前に一部ユーザーが先行して機能を利用できる可能性があります。
先行展開の対象者は、単にIT部門だけに限定しないほうがよい場合があります。実際にTeamsで業務アプリをよく使う部門を含めることで、現場で起きやすい混乱を早めに把握できます。
おすすめの先行確認メンバーは次の組み合わせです。
| 役割 | 選ぶ理由 |
|---|---|
| Teams管理者 | 設定やポリシーへの影響を確認できる |
| セキュリティ担当者 | データ送信や外部アプリ利用のリスクを確認できる |
| 業務部門の代表者 | 実際の利用シーンで使いやすさを判断できる |
| ヘルプデスク担当者 | 問い合わせ内容や説明文の不足を把握できる |
| 社内アプリ開発者 | カスタムアプリ側の対応要否を判断できる |
先行検証では、「機能が使えるか」だけでなく、「どのアプリが候補に表示されるか」「ユーザーが誤って実行しやすい操作はないか」「説明なしで使えるか」を確認してください。
開発者が確認すべきポイント
Teamsアプリやエージェント、ワークフローを提供している開発者は、Slash commands for appsによってユーザーとの接点が変わる可能性があります。
コマンド名は短く、誤解されにくくする
スラッシュコマンドは、入力欄で素早く呼び出されることが前提です。長すぎる名称や似た名称が多いコマンドは、ユーザーに選ばれにくくなります。
良いコマンド名の条件は次のとおりです。
| 観点 | 良い例 | 避けたい例 |
|---|---|---|
| 短さ | /approve、/task | /create-new-approval-request-for-department |
| 意味の明確さ | /incident、/customer | /run、/start1 |
| 業務との一致 | /expense、/ticket | 社内略語だけのコマンド |
| 誤操作の少なさ | 実行前に確認を出す | 入力直後に重要処理を確定する |
日本語圏の組織では、英語の短いコマンド名に加えて、説明文や候補表示の文言を日本語で分かりやすく整えることも重要です。コマンド自体は短く、説明は具体的にするのが使いやすい設計です。
呼び出し後の応答を「次の行動」まで設計する
スラッシュコマンドでアプリを呼び出した後、ユーザーが何をすればよいのか分からないと、利用は定着しません。
たとえば、承認ワークフローを起動する場合は、単に「承認アプリを開きました」と表示するだけでは不十分です。次に入力すべき項目、送信前の確認、キャンセル方法、エラー時の再試行方法まで分かるようにする必要があります。
実務で使いやすい応答は、次のような流れです。
| ステップ | 表示・動作の例 |
|---|---|
| コマンド実行 | /approve を入力 |
| 目的確認 | 「承認依頼を作成します。対象ファイルまたは説明を入力してください」 |
| 入力補助 | 必須項目、任意項目、入力例を表示 |
| 送信前確認 | 「この内容で申請しますか？」を表示 |
| 完了通知 | 申請番号、承認者、ステータス確認リンクを表示 |
| 失敗時 | 原因と再実行方法を簡潔に表示 |
特に業務アプリでは、失敗時のメッセージが重要です。「エラーが発生しました」だけでは、ユーザーはヘルプデスクに問い合わせるしかありません。権限不足、入力不足、接続エラー、対象データなしなど、原因が分かる表現にしてください。
権限と認証の流れを確認する
Slash commands for appsでアプリが呼び出しやすくなると、ユーザーは「Teams上で見えたものは使える」と感じやすくなります。しかし実際には、アプリ側の認証、外部サービスの権限、Microsoft Entra IDの条件付きアクセスなどが関係する場合があります。
開発者は、次のケースを事前にテストしておくべきです。
| ケース | 確認内容 |
|---|---|
| 初回利用ユーザー | サインインや同意画面が分かりやすいか |
| 権限がないユーザー | 使えない理由と申請方法を表示できるか |
| 外部ゲストユーザー | 利用可否が組織ポリシーと一致しているか |
| モバイル利用者 | 対象外の場合に混乱しない案内が出るか |
| 条件付きアクセス対象者 | 認証エラー時の表示が適切か |
公式情報では対象プラットフォームがDesktopとMacとされているため、少なくとも現時点のロードマップ情報だけでモバイル対応を前提にした展開計画を立てるべきではありません。(Microsoft)
展開前に確認したいチェックリスト
一般提供が近づいたら、管理者と開発者は次の項目を確認してください。
| 確認項目 | 管理者 | 開発者 |
|---|---|---|
| Microsoft 365 Roadmapとメッセージセンターの更新確認 | ○ | ○ |
| 対象ユーザーと対象部門の整理 | ○ | |
| Teamsアプリの許可・ブロック設定 | ○ | |
| アプリ権限ポリシーの見直し | ○ | |
| サードパーティアプリの棚卸し | ○ | |
| カスタムアプリの動作確認 | ○ | ○ |
| コマンド名と説明文の確認 | ○ | |
| 初回認証・権限不足時の表示確認 | ○ | |
| ヘルプデスク向けFAQの作成 | ○ | ○ |
| 社内周知文の作成 | ○ |
このチェックリストで特に優先度が高いのは、アプリ権限ポリシーとカスタムアプリの動作確認です。Slash commands for appsはユーザー体験を改善する機能ですが、管理されていないアプリが呼び出しやすくなると、情報管理上のリスクも高まります。
移行・展開時に起きやすい失敗
Slash commands for appsは便利な機能ですが、準備なしに展開すると混乱が起きる可能性があります。特に次の失敗に注意してください。
使えるアプリが多すぎてユーザーが迷う
Teamsに多数のアプリを許可している環境では、/ から表示される候補が増えすぎる可能性があります。候補が多すぎると、ユーザーは目的のアプリを見つけにくくなります。
対策は、全社で必要なアプリと部門固有のアプリを分けることです。利用頻度の低いアプリや検証用アプリを全社に公開したままにしないようにしましょう。
コマンド名が社内用語に偏りすぎる
開発チームや情シスだけが分かる略語をコマンド名にすると、一般ユーザーには使いにくくなります。
たとえば、経費精算を社内で「EXR」と呼んでいる場合でも、ユーザー向けには「expense」や「経費精算」と分かる説明を用意したほうが定着しやすくなります。略語は運用側には便利ですが、新入社員や異動者、派遣社員には伝わりにくいことがあります。
権限不足の案内が不親切
ユーザーがコマンドを実行した後に「権限がありません」とだけ表示されると、問い合わせが増えます。特に、部門限定アプリや外部サービス連携アプリでは、誰に申請すればよいのかを明示することが重要です。
良い案内の例は、「このアプリは営業部門向けです。利用が必要な場合は、Teamsアプリ利用申請フォームから申請してください」のように、理由と次の行動をセットで示す表現です。
ヘルプデスクが新機能を知らない
ユーザーに先に機能が見え、ヘルプデスクが後から知る状態は避けるべきです。問い合わせ対応が遅れるだけでなく、「情シスに聞いても分からない」という不信感につながります。
展開前に、最低限次の内容をヘルプデスクへ共有してください。
| 共有内容 | 目的 |
|---|---|
| 機能の概要 | 問い合わせの背景を理解する |
| 対象ユーザー | 利用できる人・できない人を判断する |
| よくある質問 | 一次対応を早くする |
| 既知の制限 | 不具合と仕様を切り分ける |
| エスカレーション先 | アプリ別の担当者へつなぐ |
社内周知で伝えるべき内容
ユーザー向けの周知では、機能説明を長く書くよりも、「いつ、どこで、何ができるか」を簡潔に伝えることが大切です。
社内アナウンスには、次の要素を入れると実用的です。
| 項目 | 書く内容 |
|---|---|
| 変更内容 | Teamsのチャットやチャネルの入力欄で / からアプリを呼び出せる |
| 開始時期 | 自社テナントでの展開予定日または確認中であること |
| 対象者 | 全社員、特定部門、先行利用者など |
| 利用例 | 承認、タスク作成、問い合わせ、ワークフロー起動など |
| 注意点 | 表示されるアプリは権限やポリシーにより異なる |
| 問い合わせ先 | ヘルプデスク、Teams管理者、アプリ担当者 |
周知文の例は次のとおりです。
Microsoft Teamsのチャットおよびチャネルの入力欄で
/を入力すると、利用可能なアプリやワークフローを呼び出せる機能が順次利用可能になる予定です。表示されるアプリは、所属部門や権限によって異なります。業務で利用するアプリが表示されない場合や、実行時にエラーが出る場合は、ヘルプデスクまでお問い合わせください。
この程度の短い説明でも、ユーザーは「何が変わるのか」「困ったらどうするのか」を理解できます。
今後の確認ポイント
Slash commands for appsは、2026年7月の一般提供予定とされていますが、ロードマップ情報は変更される可能性があります。管理者は一度確認して終わりではなく、展開前後で継続的に状態を追う必要があります。
特に確認すべきポイントは次の3つです。
まず、Microsoft 365管理センターのメッセージセンターで、自社テナントへの展開通知が出ていないか確認します。ロードマップは全体予定、メッセージセンターは自社環境に近い通知として扱うと整理しやすくなります。
次に、Teams管理センターでアプリの許可設定とポリシーを確認します。スラッシュコマンドで呼び出せるようになる前に、不要なアプリや管理者不明のカスタムアプリを整理しておくと安全です。
最後に、業務部門と一緒に利用シーンを決めます。便利そうだから全社展開するのではなく、承認、問い合わせ、タスク登録、顧客対応など、どの業務で効果を出すのかを決めてから周知すると定着しやすくなります。
まとめ：Slash commands for appsはTeamsの入力欄を業務アプリの入口に変える機能
Microsoft TeamsのSlash commands for appsは、チャットやチャネルの投稿作成ボックスから、アプリ、エージェント、ワークフローを直接呼び出せるようにする機能です。公式ロードマップでは、状態はIn development、一般提供予定は2026年7月、対象はDesktopとMac、Worldwide環境とされています。(Microsoft)
管理者が今やるべきことは、Teamsアプリの棚卸し、アプリ権限ポリシーの見直し、先行検証ユーザーの選定です。開発者は、コマンド名、応答メッセージ、認証、権限不足時の案内を確認しておきましょう。
この機能は、ユーザーの操作を短縮するだけでなく、Teams上の会話から業務アクションへ自然につなげるための重要な導線になります。まずは自社で利用しているTeamsアプリを一覧化し、「全社で使うもの」「部門限定で使うもの」「停止または見直すもの」に分けるところから始めるのが現実的です。
コメント