Microsoft Teamsの「Welcome」は、Teamsの画面に表示される新しい歓迎メッセージではなく、Teams SDKでエージェントやアプリを作るための公式ガイドの入口です。2026年5月15日に更新された公式情報では、Teams Developer CLIを使ったクイックスタート、Bot登録、TypeScript・C#・Pythonでの実装、AIエージェントやメッセージ拡張など、開発の始め方が整理されています。管理者が最初に確認すべきポイントは、カスタムアプリのアップロード許可、サイドロード、公開範囲、既存アプリへの影響です。開発者は、CLIがPreview扱いである点、Node.js 20以降やHTTPSトンネルが必要な点、資格情報の管理方法を押さえておきましょう。Microsoft LearnのWelcomeページは、Teams SDKを「認証、イベントルーティング、Teams固有の処理を肩代わりするパッケージ群」と位置付けています。(Microsoft Learn)
Microsoft Teamsの「Welcome」はTeams SDK開発の新しい入口
今回の「Welcome」は、Microsoft Teamsの一般ユーザー向け機能変更ではありません。会議、チャット、チャネル、通知などのTeams利用画面が変わるというより、Teams上で動くアプリやエージェントを開発する人向けに、Teams SDKの始め方をまとめた公式ドキュメントです。
公式ページでは、Teams SDKを使って以下のような機能を構築できると整理されています。
| 作れるもの | 主な用途 | 確認したい担当者 |
|---|---|---|
| AI-powered agents | Teams内で動くAIエージェント、業務支援Bot | 開発者、AI活用担当 |
| Message extensions | メッセージ作成欄や既存メッセージから情報検索・操作を行う機能 | 開発者、業務アプリ担当 |
| Embedded web apps | Teams内に組み込むWebアプリ | Web開発者、社内アプリ担当 |
| Adaptive Cards | Teams上で入力・確認・承認を行うカードUI | 開発者、ワークフロー設計者 |
| Dialogs | ユーザー入力を受け付ける対話画面 | 開発者 |
| Microsoft Graph連携 | ユーザー、予定表、ファイルなどMicrosoft 365データとの連携 | 開発者、管理者 |
Welcomeページでは、Teams SDKがAIエージェント、メッセージ拡張、埋め込みWebアプリ、Adaptive Cards、dialogs、Microsoft Graph統合などをTypeScript、C#、Pythonで扱えることが示されています。(GitHub)
何が変わるのか：開発手順がTeams Developer CLI中心に整理された
最も大きなポイントは、Teams SDKの始め方がTeams Developer CLIを使う流れとして明確になったことです。公式情報では、最短ルートとしてTeams Developer CLIが紹介され、アプリ登録、Bot登録、Teamsへのサイドロード、最初のBot作成へ進む流れが示されています。なお、Teams Developer CLIは公式ページ上でPreviewとして扱われています。(Microsoft Learn)
実務上は、次のように理解すると分かりやすいです。
| 従来ありがちな進め方 | Welcome後に意識したい進め方 |
|---|---|
| Azureポータル、Teams管理センター、マニフェスト、Bot設定を個別に調べながら進める | Teams Developer CLIを起点に、登録・資格情報生成・サイドロードまで一連の流れで確認する |
| まずサンプルコードをコピーしてから設定で詰まる | 先にテナントのサイドロード可否、HTTPSトンネル、エンドポイントを確認する |
| 言語別に情報を探し直す | TypeScript、C#、Pythonのいずれかを選んでクイックスタートに進む |
| Teamsアプリ開発とAIエージェント開発を別物として扱う | Teams SDK上でエージェント、Bot、カード、Graph連携を組み合わせる |
つまり、変更点は「新機能が強制的に有効になる」というより、Teamsアプリ開発の推奨導線が、SDKとCLIを中心に再整理されたと捉えるのが適切です。
影響範囲：一般ユーザーより管理者・開発者への影響が大きい
今回のWelcome更新による影響は、Teamsを日常的に使う一般ユーザーより、アプリを作る側・許可する側に出やすいです。
管理者への影響
Teams管理者は、開発者がTeams SDKのクイックスタートを試そうとしたときに、サイドロードやカスタムアプリの設定で止まる可能性を見込んでおく必要があります。
公式クイックスタートでは、前提条件としてNode.js 20以降、カスタムアプリのアップロードが有効なMicrosoft 365アカウント、ローカルサーバーに接続するための公開HTTPSトンネルが挙げられています。(Microsoft Learn)
特に重要なのは、teams statusでSideloading: enabledが表示される必要がある点です。disabledの場合は、テナント管理者がカスタムアプリのアップロードを有効化する必要があります。(Microsoft Learn)
開発者への影響
開発者は、Teams SDKのクイックスタートを使うことで、Botの登録、資格情報の出力、Teamsへのインストールリンク取得までを短い手順で確認できます。一方で、CLI、トンネル、資格情報、Teams管理ポリシーのどれかが未設定だと、サンプルが動かない原因になります。
特にローカル開発では、Teamsのサーバーがlocalhostに直接アクセスできないため、DevTunnelsやngrokなどの公開HTTPSトンネルを用意する必要があります。公式手順でも、Botインフラ登録の前にトンネルを開始し、https://<tunnel-host>/api/messagesのようなエンドポイントを指定する流れが示されています。 (GitHub)
既存のTeamsアプリへの影響
既存のTeamsアプリが直ちに動かなくなると断定できる情報は、今回のWelcomeページには示されていません。したがって、既存アプリの本番運用では、急いでSDKへ移行するというより、新規開発や検証環境からTeams SDKの開発導線を試すのが現実的です。
ただし、社内で独自のTeamsアプリを公開している場合は、管理センター側のカスタムアプリ設定、アプリ権限ポリシー、更新手順は改めて確認しておくべきです。Microsoftの管理者向け情報では、カスタムアプリの利用やアップロードを組織全体設定、アプリセットアップポリシー、アプリ権限ポリシー、チーム単位の設定で制御できると説明されています。(Microsoft Learn)
管理者が確認すべき設定
Teams SDKのWelcomeに沿って開発を進める場合、管理者は「開発者が試せる環境」と「本番配布の統制」を分けて考える必要があります。
| 確認項目 | 見る場所・設定 | 判断基準 |
|---|---|---|
| カスタムアプリの利用可否 | Teams管理センターの組織全体アプリ設定 | 全社で許可するか、検証ユーザーのみに限定するか |
| サイドロード可否 | アプリセットアップポリシー、対象ユーザーへの割り当て | 開発者・検証担当だけに許可するのが安全 |
| チーム単位のアップロード可否 | チームのメンバー権限 | 特定チームでのみ検証する場合に確認 |
| 公開範囲 | アプリ権限ポリシー | 一部部門、開発チーム、全社のどこまで使わせるか |
| アプリ更新手順 | Teams管理センターのアプリ詳細 | 新バージョンのアップロード時に既存ポリシーが維持されるか |
| 削除・停止手順 | Teams管理センターのアプリ管理 | 問題発生時に誰が停止判断をするか |
管理者向けドキュメントでは、管理者がTeams管理センターからカスタムアプリをアップロードでき、アップロード後は数時間で組織内ユーザーが利用可能になる場合があると説明されています。また、カスタムアプリを更新する場合は新しいバージョンをアップロードし、既存バージョンに適用されていたポリシーは更新後のアプリにも引き続き有効とされています。(Microsoft Learn)
実務では、最初から全社に許可するのではなく、次のような段階的な運用が安全です。
| フェーズ | 対象 | 管理のポイント |
|---|---|---|
| 検証 | 開発者、IT管理者 | サイドロードを限定許可し、テストテナントまたは限定チームで試す |
| パイロット | 業務部門の少人数 | アプリ権限ポリシーで対象者を絞る |
| 本番展開 | 対象部門または全社 | アプリ登録情報、所有者、更新手順、問い合わせ先を明確にする |
| 運用 | 管理者、開発者、セキュリティ担当 | 監査、バージョン更新、不要アプリ削除を定期的に行う |
開発者が確認すべきクイックスタート手順
Teams SDKのWelcomeでは、開発の入口として「Register your app」と「Build your first bot」が示されています。実際に試す場合は、次の流れで確認すると失敗しにくくなります。
| 手順 | 作業内容 | つまずきやすい点 |
|---|---|---|
| 事前確認 | Node.js 20以降、Microsoft 365アカウント、サイドロード許可、HTTPSトンネルを用意 | テナント側でサイドロードが無効 |
| CLIインストール | npm install -g @microsoft/teams.cli@previewを実行 | Preview版であるため、本番標準化は慎重に判断 |
| ログイン | teams login、teams statusを実行 | Sideloading: disabledで先に進めない |
| プロジェクト作成 | TypeScript、C#、Pythonのいずれかでスキャフォールド | C#は生成されるディレクトリ構造に注意 |
| Bot登録 | teams app createでエンドポイントを指定 | ローカルホストではなく公開HTTPS URLが必要 |
| 実行 | npm run dev、dotnet run、python src/main.pyなど | ポート、トンネル、資格情報の不一致 |
| Teamsへ追加 | インストールリンクから追加 | ブラウザのサインインアカウント違い |
公式クイックスタートでは、CLIのインストール、ログイン、プロジェクト作成、Botインフラ登録、エージェント実行、Teamsへのインストールという順番が示されています。teams app createではTeams App IDやインストールリンクが出力され、資格情報は環境ファイルなどに書き込まれます。(GitHub)
TypeScript・C#・Pythonでの違い
Welcomeページでは、Teams SDKの対象言語としてTypeScript、C#、Pythonが示されています。最初に選ぶ言語は、社内の開発体制や既存システムとの相性で決めるのが現実的です。
| 言語 | 向いているケース | 注意点 |
|---|---|---|
| TypeScript | Webアプリ、Node.js、フロントエンド資産と組み合わせたい場合 | Node.jsやnpmパッケージ管理に慣れているチーム向け |
| C# | .NET、Azure、社内業務システムと連携したい場合 | 生成されるソリューション・プロジェクト構造を確認 |
| Python | AI、データ処理、プロトタイプ開発と組み合わせたい場合 | 本番運用では依存関係、実行環境、非同期処理を整理 |
公式の「Build your first bot」では、TypeScriptはAppを作成してapp.on('message', ...)でメッセージを処理し、C#はbuilder.AddTeams()やteams.OnMessage(...)を使い、PythonはApp()と@app.on_messageなどでメッセージを処理する例が示されています。(GitHub)
選定の基準は「サンプルが短いか」ではなく、次の3点です。
- 社内で保守できる言語か
- Microsoft 365や既存APIとの連携を作りやすいか
- 本番環境で監視、ログ、認証、秘密情報管理を整えられるか
特にAIエージェント用途では、Pythonが魅力的に見えることがあります。ただし、Teamsアプリとして公開する以上、プロンプトやモデルだけでなく、Teams側のイベント処理、ユーザー認証、権限、エラー応答も設計対象になります。
AIエージェントとメッセージ拡張で確認すべき違い
Welcomeでは、Teams SDKで作れるものとしてAI-powered agentsとmessage extensionsが挙げられています。どちらもTeams上の業務効率化に使えますが、目的は異なります。
| 種類 | 使いどころ | 例 |
|---|---|---|
| AIエージェント | 会話を通じてユーザーの依頼を処理する | 社内規程検索、問い合わせ一次対応、会議内容の整理 |
| メッセージ拡張 | メッセージ作成欄や既存メッセージから情報検索・操作する | 顧客情報検索、チケット起票、商品情報カード挿入 |
| Adaptive Cards | 情報をカード形式で表示し、入力や承認を受ける | 稟議承認、申請フォーム、作業依頼 |
| Dialogs | まとまった入力画面を出す | 予約、登録、詳細条件入力 |
AI関連の公式ページでは、Teams SDKのAIパッケージはLLMを使うアプリを作りやすくするためのもので、Promptが状態管理や関数定義、モデル呼び出しを扱い、ModelがLLMとの入出力を担当すると説明されています。一方で、AIパッケージの利用は必須ではなく、モデルを直接使う選択も可能とされています。(Microsoft Learn)
メッセージ拡張については、Teams SDKがサポートするのはBot-based message extensionsのみです。API-based message extensionsはTeamsがOpenAPI仕様に基づいて直接問い合わせる形式で、追加アプリの構築・保守が不要な一方、カスタマイズ性は低いと説明されています。(Microsoft Learn)
実務では、次のように選ぶと判断しやすくなります。
| 要件 | 選びやすい方式 |
|---|---|
| ユーザーと自然文でやり取りしたい | AIエージェント、Bot |
| メッセージ作成時に社内データを検索して挿入したい | メッセージ拡張 |
| 承認・確認・入力をカードで完結させたい | Adaptive Cards |
| 外部APIとの複雑な処理や条件分岐が多い | Bot-based message extensionまたはエージェント |
| 既存APIをTeamsから直接検索したい | API-based message extensionも検討 |
移行・展開で失敗しやすいポイント
Teams SDKのWelcomeを見てすぐに開発を始める前に、次の失敗パターンを避けることが重要です。
サイドロード許可を全社に広げすぎる
検証のためにカスタムアプリのアップロードを許可する場合でも、最初から全社に開放すると、未検証アプリが広がるリスクがあります。管理者向けドキュメントでは、組織全体設定、アプリセットアップポリシー、チーム単位設定の組み合わせで、誰がカスタムアプリをアップロードできるかを制御できるとされています。(Microsoft Learn)
おすすめは、開発者用のポリシーを別に作り、対象ユーザーだけに割り当てる方法です。
ローカル開発のHTTPSトンネルを本番のように扱う
クイックスタートではDevTunnelsやngrokのような公開HTTPSトンネルを使いますが、これは検証のための構成です。本番では、Azure App Service、Azure Functions、コンテナ基盤など、運用監視できる公開エンドポイントを使うべきです。
また、トンネルURLが変わる場合は、Botのエンドポイント設定との不一致が起きやすくなります。Teams側から応答が来ないときは、まずURL、パス、ポート、証明書、トンネルの稼働状態を確認しましょう。
資格情報をリポジトリに入れてしまう
teams app createでは資格情報が.envやappsettings.jsonなどに書き込まれる場合があります。これらをそのままGitにコミットすると、Client SecretやTenant IDなどの情報が漏れるリスクがあります。
開発チームでは、少なくとも次を徹底してください。
.envを.gitignoreに入れるappsettings.Development.jsonと本番設定を分ける- シークレットはAzure Key Vaultなどの安全な保管先を使う
- 誤ってコミットした場合は、削除だけでなくシークレットをローテーションする
PreviewのCLIを本番標準に組み込む前に検証しない
Teams Developer CLIはWelcomeページ上でPreviewとして紹介されています。Previewのツールは、機能やコマンド体系が変わる可能性があります。本番のCI/CDや運用手順に組み込む場合は、バージョン固定、検証環境での再現性、失敗時の代替手順を用意しておきましょう。
既存アプリ更新時に利用者影響を確認しない
Teams管理センターではカスタムアプリを新しいバージョンへ更新できますが、実際の運用では、アプリの権限、マニフェスト、Botエンドポイント、Graph権限、ユーザーへの通知を確認する必要があります。公式情報では、更新後も既存ポリシーは引き続き有効とされていますが、アプリ自体の挙動や要求権限が変わる場合は、利用者影響の確認が欠かせません。(Microsoft Learn)
管理者と開発者のチェックリスト
Teams SDKのWelcomeを起点に検証を始める場合は、次のチェックリストを使うと抜け漏れを減らせます。
| 担当 | チェック項目 | 完了の目安 |
|---|---|---|
| 管理者 | 検証用ユーザーにカスタムアプリのアップロードを許可したか | teams statusでサイドロード有効を確認できる |
| 管理者 | 本番展開時の公開範囲を決めたか | アプリ権限ポリシーで対象者を制御できる |
| 管理者 | 不要アプリの削除手順を確認したか | Teams管理センターで削除・停止できる担当者が明確 |
| 開発者 | Node.js 20以降など前提条件を満たしたか | CLIインストールとバージョン確認が完了 |
| 開発者 | HTTPSトンネルを用意したか | Teamsから到達可能なURLを指定できる |
| 開発者 | 資格情報の保管方法を決めたか | .envやシークレットをGit管理しない |
| 開発者 | TypeScript・C#・Pythonの選定理由を明確にしたか | 保守できる言語でプロジェクトを開始 |
| 開発者 | Botの基本応答を確認したか | Teams上でメッセージ送信と応答を確認 |
| 開発者・管理者 | 本番移行手順を決めたか | 検証、パイロット、本番の段階が分かれている |
まず何をすべきか
今回のMicrosoft Teamsの「Welcome」は、Teams SDKでアプリやエージェントを作るための公式な出発点です。一般ユーザー向けのTeams機能変更ではなく、開発者と管理者がTeamsアプリ開発の標準的な進め方を見直すきっかけと考えるとよいでしょう。
最初にやるべきことは、次の3つです。
1つ目は、管理者がサイドロードとカスタムアプリの設定を確認することです。開発者だけでTeams SDKを試そうとしても、テナント側で許可されていなければ進めません。
2つ目は、開発者がTeams Developer CLIのクイックスタートを検証環境で試すことです。Node.js 20以降、HTTPSトンネル、資格情報の管理を含めて、手順を社内向けに再現できる形にします。
3つ目は、本番展開の前に公開範囲、更新手順、削除手順、問い合わせ先を決めることです。AIエージェントやメッセージ拡張は便利ですが、Teams上で業務データに触れる可能性があるため、開発スピードだけでなく運用統制も同時に設計する必要があります。
Teams SDKのWelcomeを読むだけで終わらせず、まずは限定ユーザーでクイックスタートを動かし、管理ポリシーと開発手順の両方を社内標準に落とし込むことが、今回の更新を実務に活かす最短ルートです。
コメント