Microsoft Teamsの「slash commands for agents」は、ユーザーがチャットやチャネルの入力欄で / を入力し、エージェントやアプリの機能をすばやく呼び出せるようにする更新です。結論から言うと、これは単なるショートカット追加ではありません。Teams上のAIエージェント、Copilot連携アプリ、業務アプリを「会話の流れの中で見つけて使う」ための新しい操作パターンです。
一方で、ユーザーにとって使いやすい機能ほど、管理者と開発者には設計上の責任が増えます。特に確認すべきなのは、どのエージェントを表示させるか、誰が使えるか、プライベートな応答と公開メッセージをどう分けるか、そしてマニフェストや権限設定をどう管理するかです。Microsoft Learnでは、この機能はTeamsのpublic developer previewで提供されるものとして説明されています。(Microsoft Learn)
Microsoft TeamsのAI/Copilot更新で何が変わるのか
今回のポイントは、Teamsのエージェントやアプリを「探して開く」体験から、「入力欄で呼び出す」体験へ近づけていることです。
従来、Teamsで業務アプリやボットを使う場合、ユーザーはアプリを追加する、チャットでメンションする、メッセージ拡張機能を探す、といった操作が必要でした。slash commands for agentsでは、空のメッセージ作成ボックスで / を入力すると候補が表示され、対応するエージェントやコマンドを選べます。Microsoftの説明では、Teamsのスラッシュコマンドは会話の入力欄から操作を実行するテキストベースのショートカットであり、アプリやエージェントが独自のコマンドをこの候補リストに追加できるようになります。(Microsoft Learn)
たとえば、以下のような使い方が想定できます。
| 利用シーン | ユーザー操作の例 | 期待される効果 |
|---|---|---|
| 会議後の確認 | /Summarize を選び、要約対象を入力する | 会話の流れを止めずに要約を依頼できる |
| 個人タスク作成 | /Follow up から自分用の次アクションを作る | チャネルに不要な依頼を流さず個人タスク化できる |
| 設定確認 | /Settings で自分の通知や連携設定を確認する | アプリ画面へ移動せずに設定へ到達できる |
| 下書き作成 | /Draft を選び、返信文や案内文を作る | チームに公開する前に個人で内容を確認できる |
管理者目線では、これは「Teams内に新しい入口が増える」変更です。ユーザーはアプリストアや固定アプリを見に行かなくても、入力欄からエージェント機能に到達できます。そのため、アプリの許可、エージェントの導入範囲、プレビュー利用者、データ取り扱いの確認を後回しにすると、意図しない部門で先に利用が広がる可能性があります。
slash commands for agentsとは
slash commands for agentsは、Teams上のエージェントやアプリが、名前付きコマンドをTeamsの入力欄に表示できるようにする仕組みです。Microsoft Learnでは、主に次の3種類が説明されています。(Microsoft Learn)
| 種類 | 内容 | 管理・開発上の注意点 |
|---|---|---|
| Targeted messaging | エージェント名をスラッシュコマンドとして呼び出し、ユーザーとエージェントが個別にやり取りする | プライベートなやり取りの扱いを明確にする |
| Agent slash commands | エージェントが登録した名前付きコマンドを候補に表示する | コマンド名、説明文、応答の公開範囲を設計する |
| Message extension slash commands | アクション型メッセージ拡張機能をスラッシュコマンドから起動する | タスクモジュールやダイアログ起動時の権限とUXを確認する |
重要なのは、スラッシュコマンドが「ユーザーに見つけてもらいやすい入口」になる点です。アプリをインストールしただけでは使われない、メンション方法が分からない、コマンド一覧を覚えられない、といったTeamsアプリ導入時のつまずきを減らせます。
ただし、見つけやすくなるほど、不要なコマンドや似た名前のコマンドも目に入りやすくなります。開発者は、コマンドを増やす前に「頻繁に使う操作か」「入力欄から呼び出す必然性があるか」「結果が個人向けかチーム向けか」を判断する必要があります。
影響範囲：ユーザー、管理者、開発者で見るべきポイント
slash commands for agentsの影響は、Teamsを使う一般ユーザーだけでなく、Teams管理者、アプリ開発者、セキュリティ・コンプライアンス担当にも及びます。
| 対象 | 主な影響 | 先に確認すべきこと |
|---|---|---|
| 一般ユーザー | / からエージェントやアプリ機能を発見しやすくなる | どのコマンドが個人向けで、どれがチームに公開されるか |
| Teams管理者 | 利用可能なエージェントやアプリの統制が重要になる | Teams管理センターでの許可、ブロック、利用者割り当て |
| 開発者 | マニフェスト設定とメッセージ処理の実装が必要になる | supportsTargetedMessages、commandLists、triggers の設計 |
| セキュリティ担当 | AIエージェント経由のデータ送信や応答範囲を確認する必要がある | アプリの認証、データ利用、監査、保持ポリシー |
| ヘルプデスク | 「表示されない」「反応しない」「誰に見えているか分からない」問い合わせが増える可能性 | 対象ユーザー、プレビュー設定、アプリ許可状態の切り分け手順 |
特に注意したいのは、Teamsの入力欄が業務の起点になっている組織です。チャット、チャネル、会議チャットの入力欄にコマンド候補が出ることで、エージェントの利用は自然に増えます。これは定着面ではメリットですが、ガバナンス面では「入口が増えた」と考えるべきです。
管理者が確認すべきTeams設定
管理者が最初に見るべきなのは、個別コマンドの中身ではなく「どのアプリやエージェントを誰に使わせるか」です。
Microsoft Teams管理センターでは、組織で利用できるエージェントやアプリを確認し、許可・ブロック、ユーザーやグループ単位の割り当て、カスタムアプリの扱いなどを管理します。Microsoft Learnでは、Teams管理センターの「Manage apps」ページから、組織内で利用可能なエージェントやアプリを管理できると説明されています。(Microsoft Learn)
Teams管理センターで確認する項目
| 確認項目 | 見る場所の例 | 判断基準 |
|---|---|---|
| 対象アプリ・エージェントが許可されているか | Teams apps > Manage apps | 業務利用を認めるアプリだけを許可する |
| 利用対象者が適切か | App centric management | 全社展開か、特定部門・検証グループ限定かを決める |
| サードパーティアプリの扱い | Org-wide app settings | 既定で許可するか、承認制にするかを決める |
| カスタムアプリのアップロード | Setup policies / custom app settings | 開発者・検証者だけに限定する |
| プレビュー機能の利用者 | Teams update policies | 本番利用者ではなく検証ユーザーに絞る |
| アプリの固定表示 | Setup policies | よく使うアプリのみ固定し、過剰な露出を避ける |
Microsoftは、Teams管理センターでアプリやエージェントを確認し、組織全体またはアプリ単位で可用性を制御できると説明しています。また、2025年4月以降、テナントはapp centric managementへ自動移行される流れが示されています。(Microsoft Learn)
App centric managementで利用範囲を絞る
app centric managementでは、アプリごとに「全員」「特定ユーザーまたはグループ」「誰にも利用させない」といった利用可否を管理できます。Microsoft Learnでは、この方式が従来のアプリ権限ポリシーを置き換えるものとして説明されており、アプリやCopilotエージェントをユーザーやグループ単位で制御できます。(Microsoft Learn)
slash commands for agentsを検証する場合、いきなり全社公開するのではなく、以下のように段階を分けると安全です。
| フェーズ | 対象 | 目的 |
|---|---|---|
| 技術検証 | 開発者、Teams管理者 | コマンド表示、マニフェスト、対象クライアントの確認 |
| 業務検証 | 情シス、DX推進、特定部門の代表者 | 実際の業務フローで使えるか確認 |
| 制限付き展開 | 対象部門またはパイロットグループ | 問い合わせ、誤操作、データ取り扱いの確認 |
| 本番展開 | 全社または対象部門 | 利用ルールとサポート手順を整えたうえで展開 |
ポイントは、「便利だから全員に出す」のではなく、「入力欄に出してよいほど成熟した機能か」で判断することです。
Public developer previewの扱いに注意する
slash commands for agentsは、Microsoft Learn上でpublic developer previewとして案内されています。プレビュー機能は、正式提供前に変更される可能性があり、Microsoftのpublic developer preview説明でも、本番アプリケーションで使うべきではない旨が示されています。(Microsoft Learn)
管理者は、検証環境と本番環境を明確に分ける必要があります。特に、次のような運用は避けるべきです。
- 全社ユーザーにプレビュー機能を有効化する
- 本番業務の重要フローをプレビュー機能だけに依存させる
- コマンドの表示・非表示を確認しないまま社内告知する
- プレビュー時のマニフェスト仕様を固定前提で開発計画に組み込む
TeamsのPublic previewは、Teams update policiesで制御できます。Microsoft Learnでは、管理者が「Show Teams preview features」を設定し、ユーザーがプレビュー機能を使えるかを管理できると説明されています。(Microsoft Learn)
検証時は、以下のように切り分けると運用しやすくなります。
| 環境 | 推奨設定 |
|---|---|
| 開発者テナント | developer previewとカスタムアプリアップロードを許可 |
| 社内検証グループ | 必要最小限のユーザーにPublic previewを許可 |
| 本番全社 | 正式提供までは原則オフ、または限定展開 |
| 重要部門 | セキュリティレビュー後に個別判断 |
開発者が確認すべきマニフェストと実装ポイント
slash commands for agentsは、Teamsクライアント側に候補を表示するための設定と、エージェント側で実際に処理する実装の両方が必要です。Microsoft Learnでは、対象のエージェントやアプリのマニフェストでスラッシュコマンドを設定すると説明されています。(Microsoft Learn)
Agent slash commandsの基本設計
エージェントのスラッシュコマンドでは、マニフェストの bots[].commandLists[] にコマンドを定義します。Microsoftの例では、supportsTargetedMessages を true にし、triggers に slash を指定したコマンドリストを設定しています。(Microsoft Learn)
設計時に見るべき項目は次の通りです。
| 項目 | 確認内容 |
|---|---|
supportsTargetedMessages | エージェントがtargeted messageを受信できる設定になっているか |
scopes | personal、team、groupChatのどこで使わせるか |
triggers | mention と slash のどちらで起動させるか |
title | ユーザーが迷わず選べる短い名前になっているか |
description | 何が起きるか、追加入力が必要か分かる説明になっているか |
| メッセージハンドラー | 受信したメッセージをコマンドとして解釈し、適切に処理できるか |
ここで失敗しやすいのは、「コマンドを表示しただけで機能が完成した」と考えてしまうことです。Microsoft Learnでも、agent slash commandsの設定はTeamsクライアントに表示するためのものであり、実際の処理はエージェントのメッセージハンドラー側で実装する必要があると説明されています。(Microsoft Learn)
Message extension slash commandsの注意点
メッセージ拡張機能をスラッシュコマンドとして出す場合は、composeExtensions[].commands[] の triggers に slash を指定します。Microsoft Learnでは、アクション型のメッセージ拡張機能をスラッシュコマンドとして表示できる一方、検索型メッセージ拡張機能はコマンドとして公開できないと説明されています。(Microsoft Learn)
つまり、既存のメッセージ拡張機能をそのまま全部スラッシュ化できるわけではありません。ユーザーが入力欄から起動して自然なもの、たとえば「申請フォームを開く」「チケット作成ダイアログを開く」「定型タスクを登録する」といったアクション型の機能が向いています。
Targeted messagingとの関係を理解する
slash commands for agentsを安全に使ううえで最も重要なのが、targeted messagingとの関係です。
targeted messagingは、チャネル、グループチャット、会議チャットの文脈の中で、ユーザーとエージェントが1対1でやり取りできる仕組みです。Microsoft Learnでは、targeted messagesはグループ会話内に表示されるものの、送信者と単一の受信者だけが見られるプライベートな1対1メッセージとして説明されています。(Microsoft Learn)
たとえば、チームのチャネルで議論中に、ユーザーがエージェントへ個人的に「この議論を要約して」と依頼できます。その依頼や応答は、他のメンバーに見せずに確認できます。内容をチームに共有したい場合は、ユーザーの確認を挟んで公開メッセージとして出す設計が望ましいです。
プライベート応答と公開応答の判断基準
| 状況 | 推奨される応答 |
|---|---|
| ユーザー個人の状態、タスク、設定に関する内容 | targeted messageで個別応答 |
| チーム全体に関係する一般情報 | 公開メッセージ |
| 生成AIによる下書きや要約 | まず個別応答し、ユーザー承認後に公開 |
| 機密情報や個人情報を含む可能性がある内容 | 個別応答、または出力を制限 |
| チャネル全員への通知が必要な処理結果 | 公開前に内容を明示し、必要なら確認を挟む |
Microsoft Learnでも、targeted requestには原則としてtargeted responseを返すべきであり、公開メッセージはチーム全体に有益で、個人情報を含まない場合に使うべきだと説明されています。(Microsoft Learn)
管理者向け：展開前チェックリスト
slash commands for agentsを導入する前に、管理者は次のチェックを行うとトラブルを減らせます。
| チェック項目 | 確認内容 | 未確認時のリスク |
|---|---|---|
| 対象アプリの許可状態 | Teams管理センターでAllowedになっているか | ユーザーに表示されない、または使えない |
| 利用対象者 | 全社、部門、検証グループのどれか | 不要なユーザーにコマンドが見える |
| プレビュー設定 | Public preview / developer previewの対象者 | 本番ユーザーに未確定機能が出る |
| カスタムアプリアップロード | 開発者だけが可能か | 未レビューのアプリが展開される |
| データ取り扱い | アプリのプライバシーポリシー、認証、保存先 | 機密情報が外部サービスに送信される |
| 応答の公開範囲 | 個別応答と公開応答の仕様 | 意図せずチャネルに情報が出る |
| サポート窓口 | 問い合わせ先、切り分け手順 | ヘルプデスクが対応できない |
| 利用ルール | 使ってよい情報、禁止情報、共有手順 | 生成AIや外部アプリの誤利用が増える |
特に社外ユーザーやゲストを含む会議・チャットでは注意が必要です。Teamsアプリは外部参加者とのやり取りでデータポリシーの扱いが複雑になる場合があります。管理者は、社外共有が多い部門から先に確認するとよいでしょう。
開発者向け：コマンド設計で失敗しないための基準
スラッシュコマンドは、増やせば便利になるわけではありません。候補が増えすぎると、ユーザーは選べなくなります。
開発者は、コマンド化する前に次の基準で絞り込みましょう。
| 判断基準 | コマンド化に向く例 | コマンド化に向かない例 |
|---|---|---|
| 頻度 | 毎日・毎週使う操作 | 年に数回しか使わない設定 |
| 明確さ | /help、/draft、/review のように目的が明確 | 名前だけでは何が起きるか分からない |
| 入力の短さ | 追加で1〜2文入れれば実行できる | 長い条件指定や複雑なフォーム入力が必要 |
| 個人性 | 自分用の要約、設定、下書き | チーム全体の承認が必要な処理 |
| 安全性 | 失敗しても取り消しや確認ができる | 即時に外部送信、削除、課金が発生する |
Microsoft Learnでは、スラッシュコマンドは短く、行動を表す名前にし、人気のあるコマンドには短縮名や別名を検討し、説明文を明確にすることが推奨されています。(Microsoft Learn)
コマンド名と説明文の具体例
| 悪い例 | 改善例 | 理由 |
|---|---|---|
/process | /create-ticket | 何を処理するのか分かる |
/ai | /summarize-thread | AIという手段ではなく目的を示す |
/send | /draft-reply | いきなり送信される誤解を避ける |
/config | /settings | 一般ユーザーに伝わりやすい |
/review | /review-document | 対象が分かる |
日本語環境では、英語コマンドと日本語説明文の組み合わせも検討できます。たとえば、コマンド名は /draft、説明文は「返信文の下書きを作成します」のようにすると、入力しやすさと理解しやすさを両立できます。
安全な利用ルールを社内にどう伝えるか
slash commands for agentsは、ユーザーが自然に使い始めやすい機能です。だからこそ、社内説明では「便利です」だけでなく、「何を入力してよいか」「結果は誰に見えるか」を明確に伝える必要があります。
社内向けには、次のような短いルールが効果的です。
| 伝える内容 | 社内説明の例 |
|---|---|
| 入力してよい情報 | 「社外秘・個人情報・顧客情報を含む内容は、承認済みエージェント以外に入力しないでください」 |
| 応答の見え方 | 「個別表示の応答でも、組織の保持ポリシー対象になる場合があります」 |
| 公開前確認 | 「AIが作成した文章は、チャネルに共有する前に内容を確認してください」 |
| 使えない場合 | 「コマンドが表示されない場合は、対象アプリの許可状態またはプレビュー設定を確認してください」 |
| 問い合わせ先 | 「業務アプリの不具合はアプリ担当、表示や権限はTeams管理担当へ連絡してください」 |
「Only you can see this message」と表示されるような個別メッセージでも、完全に記録対象外になると誤解させないことが重要です。Microsoft Learnでは、targeted messagesは24時間後にTeamsクライアントから削除される一方、組織の保持要件に従って安全なストレージに保持される可能性があると説明されています。(Microsoft Learn)
移行・展開時に起きやすいトラブルと対処
コマンドが表示されない
まず確認すべきなのは、対象アプリやエージェントがその会話にインストールされているか、対象ユーザーに許可されているか、そしてプレビュー条件を満たしているかです。
特にdeveloper preview機能を含むアプリでは、開発者側のテナント設定やカスタムアプリアップロードの許可が影響します。Microsoft Learnでは、developer previewを有効にするには、開発者テナントでカスタムアプリのアップロードを有効にする必要があると説明されています。(Microsoft Learn)
コマンドは表示されるが、期待どおり動かない
この場合は、マニフェストだけでなく、エージェント側のメッセージ処理を確認します。スラッシュコマンドは候補表示と入力補助を提供しますが、実際に「このメッセージはどのコマンドか」を解釈して処理するのはエージェント側です。
確認すべきポイントは次の通りです。
- 受信メッセージ内のコマンド名を正しく判定しているか
slashとmentionの両方に対応する場合、処理を分けているか- targeted messageとして受けた場合に、公開応答へ切り替えていないか
- 入力不足時に、ユーザーへ追加情報を求める設計になっているか
- エラー時にチャネル全体へ不要なエラーを流していないか
個別のつもりがチームに見える不安がある
この問題は、技術だけでなくUXの問題でもあります。ユーザーに「これはあなたにだけ表示されています」「この内容をチャネルに共有しますか」といった明確な文言を出すことで、誤解を減らせます。
開発者は、公開メッセージへ変換する場合に必ず確認を挟む設計を検討してください。Microsoft Learnでも、targeted messageを公開共有したい場合は、suggested actionsでユーザーの承認を求め、承認後に公開メッセージとして再送する考え方が示されています。(Microsoft Learn)
実務でのおすすめ展開パターン
最も安全で効果が出やすいのは、「個人向け・低リスク・高頻度」のコマンドから始めることです。
たとえば、最初の展開では以下のようなコマンドが向いています。
| 優先度 | コマンド例 | 理由 |
|---|---|---|
| 高 | ヘルプ表示、設定確認、個人用タスク作成 | 誤公開リスクが低く、利用頻度が高い |
| 中 | 要約、下書き、レビュー | 効果は大きいが、情報取り扱いルールが必要 |
| 低 | 外部送信、申請承認、データ更新 | 誤操作時の影響が大きく、確認フローが必須 |
AIエージェントやCopilot連携を前提にする場合も、最初から「自動で実行する」方向に寄せすぎないことが重要です。まずは、ユーザーが結果を確認し、必要に応じて共有・送信・登録する形にすると、安全性と受容性のバランスが取りやすくなります。
管理者と開発者が今すぐやるべきこと
slash commands for agentsは、Microsoft Teamsのエージェント利用を広げるうえで強力な入口になります。ユーザーは / を入力するだけで候補を見つけられるため、アプリの定着には大きな効果があります。一方で、権限、表示範囲、プライバシー、プレビュー利用、マニフェスト実装を整理しないまま展開すると、問い合わせや誤利用が増えやすくなります。
まず管理者は、Teams管理センターで対象アプリやエージェントの許可状態、利用者割り当て、プレビュー設定、カスタムアプリアップロードの範囲を確認してください。開発者は、supportsTargetedMessages、commandLists、triggers の設計に加え、受信メッセージの処理、個別応答と公開応答の切り替え、エラー時の挙動を実装レベルで確認する必要があります。
導入の第一歩は、全社展開ではなく小さな検証です。よく使う個人向けコマンドから始め、利用ログや問い合わせを見ながら、対象部門とコマンド数を広げていくのが現実的です。Teamsの入力欄は、今後さらにエージェント操作の入口になっていきます。今のうちに「誰に、何を、どこまで使わせるか」を決めておくことが、AI/Copilot時代のTeamsガバナンスでは欠かせません。
コメント