Microsoft Teams documentation update: [Doc Improvement][Agents Toolkit update – PR5][5001299] は、Teams の会議・チャット機能そのものの変更ではなく、Microsoft 365 Agents Toolkit を使った Teams アプリ／エージェント開発手順のドキュメント更新として見るべき内容です。結論から言うと、一般ユーザーや Teams 管理センターの日常設定にすぐ影響する更新ではありません。影響を受けやすいのは、appPackage/manifest.json、aad.template.json、m365agents.yml、m365agents.local.yml を使って Teams アプリ、メッセージ拡張機能、個人用タブ、SSO 対応アプリを開発・検証している開発者と運用担当者です。
本稿執筆時点で、対象の GitHub PR は Draft 状態で、main ブランチへ 36 コミットをマージする候補として表示されています。2026年5月5日にも複数のコミットが追加され、その後 5月6日・5月7日にも更新が続いているため、社内手順書を更新する際は「公開済みの最終仕様」ではなく「反映予定またはレビュー中のドキュメント改善」として扱うのが安全です。(GitHub)
この更新でまず確認すべきこと
今回の Microsoft Teams documentation update で重要なのは、機能追加の有無よりも、Teams Toolkit から Microsoft 365 Agents Toolkit への用語・手順の整理と、アプリマニフェスト／Microsoft Entra マニフェストの検証手順がどう案内されるかです。
| 確認項目 | 変更の読み取り方 | 実務での対応 |
|---|---|---|
| 更新の性格 | ドキュメント改善。Teams サービス自体の仕様変更とは別に扱う | Teams 管理センター設定を急いで変更しない |
| 主な対象 | Microsoft 365 Agents Toolkit、Microsoft 365 app manifest、Microsoft Entra manifest | 開発チームの手順書・CI 検証コマンドを確認する |
| 影響が大きい人 | Teams アプリ／エージェント開発者、DevOps 担当、SSO・Graph 権限を扱う担当者 | manifest.json と aad.template.json の扱いを再確認する |
| 影響が小さい人 | Teams の一般利用者、会議・チャット機能だけを管理する担当者 | 通常利用では対応不要 |
| 注意点 | PR は Draft であり、Microsoft Learn の公開ページとは差が出る可能性がある | 最終反映後に公式ページと差分を再確認する |
PR の変更対象には、m365-apps 配下のメッセージ拡張機能・個人用タブの記事、toolkit 配下の Microsoft Entra マニフェスト記事と app manifest カスタマイズ記事、さらに複数のスクリーンショット画像が含まれています。(GitHub)
何が変わるのか：Teams アプリから「エージェントまたはアプリ」へ表現が広がる
差分の中心は、従来の「Teams app」寄りの表現を、Microsoft 365 Agents Toolkit の文脈に合わせて「agent or app」へ広げることです。たとえば、アプリマニフェストの記事ではタイトルが「Customize Microsoft 365 App Manifest in Agents Toolkit」に変わり、説明文も「app」だけでなく「agent or app」を検証・更新する内容へ修正されています。(GitHub)
これは単なる言い換えに見えますが、実務上は重要です。Microsoft Teams アプリ開発は、従来のタブ・ボット・メッセージ拡張機能だけでなく、Microsoft 365 Copilot やエージェント開発の流れと接続されやすくなっています。そのため、社内ドキュメントで「Teams Toolkit」「Teams app」だけを前提にしている場合、今後の公式ドキュメントとの表記ズレが増える可能性があります。
特に、次のような表現は見直し候補です。
- 「Teams Toolkit」だけで説明している箇所
- 「Teams app manifest」とだけ書いている箇所
- 「Teams: Validate Application」など古いコマンドパレット名だけを記載している箇所
- Teams アプリと Microsoft Entra アプリのマニフェストを混同している箇所
app manifest 周りで確認すべき変更点
Microsoft 365 app manifest の説明では、既定のマニフェストファイルが appPackage/manifest.json にあり、env/.env.dev や env/.env.local などの環境変数ファイルを使って ${{XX_XX}} 形式の値を解決する流れが整理されています。PR 側では、ローカル環境・リモート環境のプレビュー、appPackage/build 配下に生成される zip パッケージやプレビューマニフェストの説明も維持されています。(GitHub)
実務では、次の3点を優先して確認してください。
m365agents.yml の manifestPath を確認する
独自の manifest.json を使っているプロジェクトでは、m365agents.yml と m365agents.local.yml に指定している manifestPath が正しいか確認します。たとえば、テンプレートを test/test.json に置いている場合、zip パッケージ生成時の入力元が想定と違うと、古いマニフェストがビルドされる可能性があります。
確認する場所の例です。
- uses: teamsApp/zipAppPackage
with:
manifestPath: ./test/test.json
outputZipPath: ./appPackage/build/appPackage.${{TEAMSFX_ENV}}.zip
outputJsonPath: ./appPackage/build/manifest.${{TEAMSFX_ENV}}.json.env の不足で検証に失敗しないか確認する
PR では、MissingEnvironmentVariablesError の説明も整理されています。これは、manifest.json に指定された環境変数を Agents Toolkit が見つけられない場合に起きるエラーです。対処としては、Provision を実行する、F5 でローカルデバッグして環境変数を生成する、または .env.xx を手動で更新する流れが示されています。(GitHub)
開発チームでは、次のような変数不足が起きやすいです。
| よくある不足 | 起きやすい場面 | 対応 |
|---|---|---|
AAD_APP_CLIENT_ID | SSO 対応や Entra アプリ連携を追加した直後 | Provision またはローカルデバッグを実行する |
TEAMS_APP_ID | 新しい環境を作った直後 | m365agents.yml の出力先と .env を確認する |
| 独自に追加した説明文変数 | アプリ説明を .env から差し込む場合 | すべての環境の .env に同じキーを追加する |
| ファイルパス変数 | file() 関数で長文説明を外部ファイル化した場合 | 相対パスの基準と CI 実行ディレクトリを確認する |
file() 関数を使う場合は Toolkit のバージョンを確認する
PR の本文では、Agents Toolkit 5.10 以降で file 関数を使い、長い説明文や複数行の説明文を別ファイルに分けられる旨が説明されています。たとえば、description.full に $[file('description.txt')] を指定する形です。(GitHub)
これはアプリ説明文を多言語化したり、レビューしやすく分割したりする場面で便利です。ただし、古い Toolkit や CI 環境で同じ構文が扱えるとは限らないため、チーム全員の拡張機能・CLI バージョンをそろえてから使うべきです。
検証手順は「スキーマ検証」と「パッケージ検証」を分けて考える
PR では、見出しが「Validate your app」から「Validate your agent or app」へ変わり、ツリービューまたはコマンドパレットから Validate Application を実行する流れが整理されています。コマンドパレット名も Microsoft 365 Agents Toolkit の文脈に合わせて「Microsoft 365 Agents: Validate Application」として示されています。(GitHub)
検証は、次の2段階に分けて考えると失敗を減らせます。
| 検証 | 目的 | 使う場面 |
|---|---|---|
| マニフェストスキーマ検証 | manifest.json の構造や必須項目を確認する | 開発中、PR 作成前、環境変数を追加した後 |
| アプリパッケージ検証 | zip 化されたアプリパッケージを検証ルールで確認する | Teams へアップロードする前、公開申請前 |
PR の記事内では、例として次のコマンドが示されています。
atk validate --manifest-path <YOUR-PATH-TO-MANIFEST>atk validate --app-package-file-path <YOUR-PATH-TO-APP-PACKAGE>一方で、Microsoft 365 Agents Toolkit CLI のリファレンスでは、atk validate のパラメーターとして --manifest-file や --package-file なども案内されています。CI/CD に組み込む場合は、記事のサンプルをそのまま固定せず、実際に使っている CLI で atk validate -h を実行し、インストール済みバージョンの引数名を確認してください。(Microsoft Learn)
関連ドキュメントへの影響：メッセージ拡張機能と個人用タブも確認対象
今回の PR では、メッセージ拡張機能と個人用タブの記事にある検証リンクも更新されています。具体的には、validate-your-app へのリンクが validate-your-agent-or-app に変わっています。(GitHub)
これは小さな変更に見えますが、社内 Wiki や教育資料で Microsoft Learn のアンカーリンクを直接貼っている場合、リンク切れや意図しない場所への遷移が起きる可能性があります。特に、次のような資料は確認しておくとよいでしょう。
- Teams メッセージ拡張機能の開発手順書
- Teams 個人用タブのマニフェスト更新手順
- 新人向けの Teams アプリ開発チュートリアル
- CI で
atk validateを実行する手順書 - Microsoft Learn の見出しアンカーへ直接リンクしている社内ドキュメント
Microsoft Entra manifest の変更で見るべきポイント
Microsoft Entra manifest の記事では、Microsoft 365 Agents Toolkit が Microsoft Entra アプリをマニフェストファイルを基準に管理するという説明が強調されています。PR 側では、Teams application だけでなく Teams agent or app という表現に寄せられています。(GitHub)
ここで混同しやすいのは、Teams app manifest と Microsoft Entra manifest は役割が違うという点です。
| ファイル | 主な役割 | よくある確認項目 |
|---|---|---|
appPackage/manifest.json | Teams にアプリやエージェントをどう統合するかを定義 | アプリ名、説明、タブ、ボット、メッセージ拡張、アイコン |
aad.template.json | Microsoft Entra アプリ登録の設定を定義 | API 権限、リダイレクト URI、事前承認済みアプリ、SSO 関連設定 |
.env.local / .env.dev | 環境ごとの値を保持 | アプリ ID、クライアント ID、ドメイン、エンドポイント |
Microsoft Entra manifest では、追加の API 権限が必要な場合に requiredResourceAccess を更新します。PR の記事では、Microsoft Graph と Office 365 SharePoint Online については人間が読める名前を使える一方、その他の API では UUID を使う必要があると説明されています。(GitHub)
また、redirectUris は認証後にトークンなどを返す URL として使われます。ローカルデバッグ、dev 環境、本番環境で URL が違う場合、web、spa、publicClient のどこに設定すべきかを確認してください。設定ミスがあると、Teams 上ではアプリが表示されても、サインインや Graph API 呼び出しで失敗することがあります。
移行や設定確認が必要なケース
今回の更新だけを理由に、すべての Teams 環境で移行作業が必要になるわけではありません。ただし、次の条件に当てはまる場合は、早めに確認したほうが安全です。
| 状況 | 対応優先度 | 確認すること |
|---|---|---|
| Teams Toolkit 時代の手順書を使い続けている | 高 | Microsoft 365 Agents Toolkit 前提の名称・コマンドに更新する |
| SSO 対応タブやボットを開発している | 高 | aad.template.json、AAD_APP_CLIENT_ID、redirectUris を確認する |
| メッセージ拡張機能や個人用タブを保守している | 中 | 検証リンク、マニフェスト更新手順、サンプルコマンドを確認する |
CI で atk validate を実行している | 高 | CLI バージョンと引数名を固定し、atk validate -h の結果を記録する |
| Developer Portal で手動編集している | 中 | ローカルマニフェストからの更新で上書きされる設定がないか確認する |
| Teams の会議・チャット運用だけを担当している | 低 | 通常は対応不要。開発チームから依頼があった場合のみ確認する |
特に注意したいのは、Developer Portal や Azure portal で手作業で直した設定です。マニフェストをソースオブトゥルースとして扱う運用では、ローカルのテンプレートや .env が正しくないと、手動修正した内容が次回更新時に戻ることがあります。Microsoft Entra manifest の記事でも、開発ライフサイクルの各段階で Entra アプリが作成・再利用・更新される流れが説明されています。(GitHub)
実務での確認手順
更新内容を追うだけでなく、実際のプロジェクトで次の順に確認すると、作業漏れを減らせます。
まず PR と公開ページの状態を確認する
対象 PR は Draft のため、GitHub の差分と Microsoft Learn の公開ページが一致しない可能性があります。公開中の Learn ページでは、app manifest カスタマイズ記事の最終更新が 2025年5月19日として表示されており、PR の 2026年更新候補とは状態が異なります。(Microsoft Learn)
社内手順書を更新する場合は、次の順で確認してください。
- GitHub PR が Draft から変更されたか確認する
- Microsoft Learn の該当ページに反映されたか確認する
- 自社で使っている Agents Toolkit 拡張機能と CLI のバージョンを確認する
- サンプルコマンドを実行環境で検証してから手順書へ反映する
プロジェクト内のマニフェスト関連ファイルを洗い出す
次のファイルがあるプロジェクトは、今回の更新の影響を受けやすいです。
appPackage/manifest.json
appPackage/build/
aad.template.json
aad.local.json
aad.dev.json
m365agents.yml
m365agents.local.yml
env/.env.local
env/.env.devmanifest.json だけを見ても不十分です。Teams アプリとしての表示や機能は appPackage/manifest.json にありますが、SSO、Graph 権限、リダイレクト URI などは Microsoft Entra 側の設定と結び付きます。
ローカルと dev の両方でプレビューする
F5 によるローカルデバッグ、または Provision によるリモート環境向けのプレビューを実行し、appPackage/build 配下に想定した zip と manifest が出力されるか確認します。PR 側の説明では、ローカル環境とリモート環境のプレビューマニフェストが appPackage/build 配下に生成される流れが示されています。(GitHub)
確認するポイントは次のとおりです。
manifest.local.jsonにローカル用 URL が入っているかmanifest.dev.jsonに dev 環境の URL や ID が入っているか- zip パッケージにアイコンや manifest が含まれているか
- アプリ説明文に
${{...}}が残っていないか description.fullを外部ファイル化している場合、内容が正しく展開されているか
検証結果を PR レビューに組み込む
Teams アプリやエージェントの開発では、マニフェスト変更が見た目だけでなく認証・権限・インストール可否に影響します。PR レビューでは、コード差分だけでなく次の確認結果も添えると安全です。
| レビュー項目 | 確認内容 |
|---|---|
| スキーマ検証 | manifest.json がスキーマに適合しているか |
| パッケージ検証 | zip 化後のアプリパッケージが検証ルールに通るか |
| 環境変数 | .env.local と .env.dev に必要なキーがあるか |
| Entra 権限 | requiredResourceAccess が最小権限になっているか |
| リダイレクト URI | ローカル・dev・本番で URL が混ざっていないか |
| 手動設定との差分 | Developer Portal や Azure portal の手動変更を上書きしないか |
失敗しやすいポイント
今回のドキュメント更新を追ううえで、特に失敗しやすいのは次の3つです。
PR の内容をすぐ本番手順として扱ってしまう
Draft PR は、レビュー中の内容です。画面キャプチャやコマンド名が更新されていても、公開ページ・実際の拡張機能・CLI の挙動と完全に一致するとは限りません。社内手順へ反映する場合は、「反映予定の変更」と「すでに公開済みの手順」を分けて記録してください。
Teams app manifest と Microsoft Entra manifest を同じものとして扱う
Teams 側の manifest.json は、Teams にアプリをどう見せるかを定義します。一方、Microsoft Entra manifest は認証、権限、リダイレクト URI などを扱います。SSO の不具合では、Teams 側のマニフェストだけ見ても原因が分からないことがあります。
CLI サンプルを CI にそのまま貼り付ける
ドキュメント内のサンプルと CLI リファレンスで引数表記が異なる場合があります。CI では atk validate -h の結果を確認し、使っているバージョンで通るコマンドを固定してください。特に複数チームで Agents Toolkit のバージョンが混在している場合、ローカルでは成功するのに CI で失敗するケースが起きやすくなります。
今回の更新から取るべき次のアクション
Microsoft Teams documentation update: [Doc Improvement][Agents Toolkit update – PR5][5001299] は、Teams 利用者向けの大きな機能変更ではなく、Teams アプリ／エージェント開発者向けのドキュメント整備として捉えるのが適切です。まずは、対象 PR の反映状況を確認し、社内手順書で「Teams Toolkit」「Teams app」だけに依存した表記を使っていないか見直してください。
開発チームは、appPackage/manifest.json、aad.template.json、m365agents.yml、.env の関係を再点検し、スキーマ検証とパッケージ検証を PR レビューや CI に組み込むのが現実的な対応です。管理者側は、すぐに Teams 管理センターの設定を変更する必要はありませんが、アプリ公開・承認・SSO 設定を扱う場合は、Developer Portal と Microsoft Entra 側の設定がマニフェスト更新で上書きされないかを確認しておきましょう。
コメント