GitHubの公式ドキュメント更新「Remove Start/Stop section」でまず確認すべきなのは、Microsoft 365管理センターからFoundry系エージェントを開始・停止する手順を、社内手順書や運用Runbookに残したままにしていないかです。
今回の変更は、GitHub自体の機能変更というより、GitHub上のMicrosoftDocsリポジトリで管理されているMicrosoft 365関連ドキュメントの差分です。2026年4月29日のコミットでは、microsoft-365/admin/manage/agent-actions.md から「Start or Stop agents」セクションが削除されました。削除対象には、Azure AI Ownerロールへの昇格、Microsoft 365管理センター上のAll agentsから対象エージェントを選ぶ手順、Start/Stopが基盤となるAzureインフラに影響するという説明が含まれていました。(GitHub)
結論として、開発者、クラウド管理者、ソリューションアーキテクトは、Start/Stopを「Microsoft 365管理センター上の一般的なエージェント操作」として扱わず、対象エージェントの種類、操作場所、権限、影響範囲を切り分けて確認する必要があります。
GitHubの公式ドキュメント更新「Remove Start/Stop section」で何が変わったか
今回のコミットは、MicrosoftDocsの microsoft-365-docs リポジトリに対する更新です。対象ファイルは microsoft-365/admin/manage/agent-actions.md で、差分としては1ファイルから22行が削除され、追加行はありません。コミットメッセージは「Remove Start/Stop section」です。(GitHub)
削除されたセクションの内容は、単なる見出しの整理ではありません。元の記述では、管理者がFoundry agentsを統制するために、基盤となるMicrosoft Azureインフラを開始または停止できること、操作には Azure AI Owner ロールへの昇格が必要であること、Stop/Startは個別デプロイメントのコンピュートを割り当て解除またはプロビジョニングする操作であることが説明されていました。(GitHub)
現在のMicrosoft Learn上の該当ページでは、エージェントに対する操作として、Install、Uninstall、Block/Unblock、Delete、Assign new ownerなどが案内されています。一方で、該当ページ内に「Start or Stop agents」セクションは残っていません。ページの最終更新日は2026年4月30日と表示されています。(Microsoft Learn)
ここで重要なのは、Start/Stop機能そのものが完全に廃止されたと短絡的に判断しないことです。確認すべきなのは、「どの種類のエージェントに対して」「どの管理画面またはAPIで」「どの権限により」Start/Stop相当の操作ができるのか、という運用上の整理です。
まず見るべきポイントは「操作の意味」と「操作場所」の分離
Microsoft 365やMicrosoft Foundryまわりのエージェント管理では、似た言葉でも意味が大きく異なります。特にStart/Stop、Block/Unblock、Uninstall、Deleteを混同すると、可用性、コスト、権限、監査対応に影響します。
| 操作 | 主な意味 | 代表的な用途 | 注意点 |
|---|---|---|---|
| Start/Stop | 基盤リソースやデプロイメントの稼働状態を変える操作 | インフラレベルの停止、再開、コスト・リスク制御 | UIや対象エージェント種別により対応状況が異なるため、公式ドキュメントで再確認が必要 |
| Block/Unblock | 利用者からの利用可否を制御する操作 | 組織全体で一時的に使わせない、再開する | 基盤リソースを止める操作とは限らない |
| Uninstall | インストール済みエージェントを利用対象から外す操作 | 特定ユーザーやグループへの展開解除 | エージェントの実体削除とは別に考える |
| Delete | エージェントや関連データを削除する操作 | 廃止、完全削除 | 不可逆な操作として扱うべき |
| Assign new owner | 所有者を変更する操作 | 退職者・異動者が作成したエージェントの引き継ぎ | 対象となるエージェント種別に制限がある |
現在のMicrosoft 365管理センター向けドキュメントでは、Block/Unblockはエージェントの利用可能性に影響する操作として説明されています。たとえばAgent BuilderやCopilot Studioで作成したエージェントではMicrosoft 365 CopilotやOutlook、Teamsなどのホスト製品にも影響する一方、SharePointやMicrosoft Foundryで作成したエージェントについてはMicrosoft 365 Copilot Chatでの可用性に影響すると説明されています。(Microsoft Learn)
つまり、「ユーザーに使わせない」ことと「Azure側のコンピュートを止める」ことは別の判断です。障害対応やセキュリティ対応では、まず利用制御としてBlockを検討し、インフラ停止が必要な場合はFoundryやAzure側の権限・影響範囲を確認する、という順番が安全です。
運用影響が出やすいチーム
今回のようなドキュメント更新は、画面上のボタンが見えるかどうかだけの問題ではありません。社内手順、権限設計、監査証跡、インシデント対応フローに影響します。
開発者が確認すべき点
開発者は、自分たちが作成・公開しているエージェントがどの分類に入るかを確認する必要があります。Agent Builder、Copilot Studio、SharePoint、Microsoft Foundry、Agent applicationsでは、管理できる場所や操作できる範囲が異なる可能性があります。
特に、以前の手順書に「Microsoft 365管理センターのAll agentsからFoundry agentを選び、Start/Stopする」といった記載がある場合は要注意です。現在の公式差分では、その手順が削除されています。開発チームのRunbookや障害対応メモに同じ記述が残っているなら、実画面と最新ドキュメントで再検証してください。
実務では、次のように整理すると判断しやすくなります。
| 確認項目 | 見るべき内容 |
|---|---|
| エージェントの作成元 | Agent Builder、Copilot Studio、SharePoint、Foundry、独自登録など |
| 公開先 | Microsoft 365 Copilot、Teams、社内アプリ、API利用など |
| 停止したい理由 | セキュリティ、コスト、障害、検証終了、所有者不在 |
| 必要な操作 | Block、Uninstall、Delete、Start/Stop、所有者変更のどれか |
| 承認者 | アプリ所有者、Azureリソース所有者、Microsoft 365管理者、セキュリティ担当者 |
クラウド管理者が確認すべき点
クラウド管理者にとって最も重要なのは、Microsoft Entraの管理者権限とAzureリソースの操作権限を混同しないことです。関連するFoundryの管理ドキュメントでは、Microsoft Entra IDとAzureではアクセス制御の仕組みが分かれており、Azureリソースを確認・管理するにはAzure側のロール割り当てが必要だと説明されています。(Microsoft Learn)
削除されたStart/Stopセクションには、Azure AI Ownerロールへの昇格が必要という記述が含まれていました。(GitHub) そのため、社内の運用手順でPIM、Azure AI Owner、User Access Administrator、サブスクリプションスコープの権限昇格を扱っている場合は、最小権限と一時的な権限付与の考え方に沿って見直すべきです。
特に避けたいのは、次のような運用です。
| 避けたい運用 | 理由 |
|---|---|
| Start/Stopのために恒久的な高権限を付与する | 不要な権限が残り、監査・内部統制上のリスクになる |
| Microsoft 365管理者であればAzure側も操作できると考える | EntraとAzure RBACは別の権限制御であるため |
| 対象リソースの所有者確認なしに停止する | 複数チームや複数テナントに影響する可能性がある |
| Deleteを一時停止の代替として使う | 削除は復元できない影響を持つ場合がある |
関連ドキュメントでは、インフラレベルの介入ではリソース所有者と連携すること、必要なロールを狭いスコープで割り当てること、PIMを利用する場合は恒久的な割り当てではなく eligible assignment を検討することが示されています。(Microsoft Learn)
ソリューションアーキテクトが確認すべき点
ソリューションアーキテクトは、管理プレーンを分けて設計する必要があります。Microsoft Agent 365はAIエージェント向けのIT管理コントロールプレーンとして、ID、セキュリティ、ガバナンス、ライフサイクル管理を適用する役割を持ちます。レジストリでは、Microsoft FoundryやCopilot Studioで作成されたエージェント、管理者が登録したエージェント、テナント内で検出されたシャドーエージェントなどを扱うと説明されています。(Microsoft Learn)
一方、Foundry Control Planeは、サブスクリプション内の複数プロジェクトに分散するエージェントを一元的に管理・観測するための仕組みとして説明されています。エージェントのインベントリ、メタデータ、ヘルス指標、Application Insightsを使った観測などが関係します。(Microsoft Learn)
設計時は、次のように責務を分けると混乱しにくくなります。
| 管理領域 | 主な目的 | 主に関与する担当 |
|---|---|---|
| Microsoft 365管理センター | 組織内ユーザーへの展開、利用可否、所有者管理 | Microsoft 365管理者、IT管理者 |
| Microsoft Agent 365 | エージェントの可視化、ガバナンス、アクセス制御 | IT管理者、セキュリティ担当 |
| Microsoft Foundry / Foundry Control Plane | エージェント資産、稼働状態、観測、ライフサイクル操作 | 開発者、クラウド管理者 |
| Azure RBAC / PIM | リソース操作権限、昇格、監査 | クラウド管理者、IAM担当 |
| 社内Runbook | 障害・セキュリティ・廃止時の実行手順 | 運用チーム、SRE、管理者 |
今回の「Remove Start/Stop section」は、まさにこの責務分離を見直すきっかけになります。Microsoft 365管理センターを「すべてのエージェント操作を完結できる場所」として設計している場合は、改めて操作場所を定義し直すべきです。
Start/Stop削除後に確認すべき実務チェックリスト
社内でGitHub上のMicrosoftDocs差分を追っている場合、今回の更新は次の順で確認すると効率的です。
| 手順 | 作業内容 | 目的 |
|---|---|---|
| 1 | 社内ドキュメントで「Start or Stop agents」「Start/Stop」「Azure AI Owner」「Add Role」を検索する | 古い手順の残存確認 |
| 2 | 対象エージェントを作成元・公開先・所有者で分類する | 操作可能な画面と権限を切り分ける |
| 3 | 停止したい目的を整理する | Blockで足りるのか、インフラ停止が必要なのか判断する |
| 4 | Microsoft Learnの最新ページとGitHubコミット差分を照合する | 公式ドキュメント上の変更を根拠化する |
| 5 | 検証環境でUIと権限を確認する | 本番手順の失敗を防ぐ |
| 6 | Runbook、承認フロー、監査ログ取得手順を更新する | 実運用に反映する |
特に、緊急停止手順にStart/Stopを組み込んでいる場合は早めに見直してください。セキュリティインシデント時に「どの画面にボタンがあるはずか」を探す運用は危険です。あらかじめ対象エージェントごとに、Block、Uninstall、Delete、インフラ停止のどれを使うかを決めておく必要があります。
Block、Stop、Deleteをどう使い分けるか
エージェント運用で失敗しやすいのは、「止める」という言葉を1つの操作として扱ってしまうことです。実際には、目的によって選ぶ操作が変わります。
一時的に利用を止めたい場合
まず検討すべきはBlockです。利用者から見た可用性を制御したいだけなら、基盤リソースを停止するより安全な場合があります。たとえば、権限レビューが完了するまで一時的に社内ユーザーに使わせない、疑わしいエージェントを調査中に無効化する、といった場面です。
ただし、Blockは必ずしもAzure側のリソース停止やコスト停止を意味しません。コスト削減やリソース停止が目的なら、FoundryやAzure側の対象リソース、対応操作、権限を別途確認する必要があります。
基盤リソースを止めたい場合
Start/Stopは、単なる利用制御ではなくインフラレベルの操作として扱うべきです。削除されたセクションでも、Stop/Startは個別デプロイメントのコンピュートを割り当て解除またはプロビジョニングする操作であり、組織内での利用方法だけでなく基盤となるAzureインフラに影響すると説明されていました。(GitHub)
そのため、実行前には次を確認してください。
| 確認項目 | 理由 |
|---|---|
| 対象がAgent applicationなのかFoundry agentなのか | 対応する操作場所が変わる可能性がある |
| リソース所有者は誰か | 他チームの本番利用に影響する可能性がある |
| 停止中のユーザー影響は何か | Copilot、Teams、API利用などの影響を把握する |
| 再開手順は検証済みか | 停止できても復旧に失敗するリスクがある |
| 監査ログを残せるか | セキュリティ・内部統制対応に必要 |
完全に廃止したい場合
廃止目的ならDeleteを検討します。ただし、Deleteを一時停止の代わりに使ってはいけません。Microsoft 365管理センター向けドキュメントでは、Agent Builder agentの削除はMicrosoft 365のインベントリからの削除、関連ファイルの削除、SharePoint Embeddedコンテナーの削除を伴い、削除プロセスは不可逆と説明されています。また、削除後も最大24時間は一部ユーザーに表示される可能性があるものの、操作はできないとされています。(Microsoft Learn)
「しばらく使わない」「問題があるので調査したい」という理由だけでDeleteを選ぶと、復元や証跡確認で困る可能性があります。削除は、所有者、利用部門、セキュリティ、データ管理の合意を取ったうえで実施するのが安全です。
社内Runbookの書き換え例
今回の更新を受けて、社内資料では「画面操作の手順」だけでなく「判断ロジック」を明記することが重要です。
| 古い書き方 | 見直し後の書き方 |
|---|---|
| Microsoft 365管理センターでFoundry agentをStart/Stopする | 対象エージェントの種類を確認し、Microsoft 365管理センター、Foundry、Azure、APIのどこで操作すべきか判断する |
| Azure AI Ownerに昇格して操作する | 最小権限、対象スコープ、PIMの利用、所有者承認を確認してから必要な権限を付与する |
| 問題があるエージェントは停止する | 利用停止が目的ならBlock、基盤停止が目的ならStart/Stop相当、廃止ならDeleteを選ぶ |
| 所有者不在なら管理者が対応する | Agent Builder/Copilot Studioなど対象範囲を確認し、必要ならAssign new ownerを使う |
| 手順はドキュメント通りに実施する | GitHub差分、Microsoft Learnの最新更新日、実テナントのUI表示を確認してから実施する |
このように書き換えると、将来さらにUIやドキュメントが変わっても、運用担当者が誤操作しにくくなります。
技術意思決定者が押さえるべき判断基準
技術意思決定者にとって、今回の更新は「ドキュメントの一部削除」ではなく、AIエージェント運用のガバナンス成熟度を見直す材料です。
MicrosoftのAIエージェントガバナンス関連ドキュメントでは、エージェントはデータにアクセスし、アクションを実行し、委任された権限で動作するため、組織は存在把握、所有者確認、アクセス制限、動作観測、不適切な動作の停止ができる必要があると説明されています。(Microsoft Learn)
その観点では、次の3点を明文化しておくと実務に効きます。
| 判断基準 | 決めるべき内容 |
|---|---|
| 所有者責任 | エージェントの業務責任者、技術責任者、運用責任者を分ける |
| 停止責任 | 誰がBlock、Stop、Deleteを承認できるかを決める |
| 復旧責任 | 停止後に誰が検証し、どの条件で再開するかを決める |
AIエージェントは、従来のアプリケーションよりも「誰が作ったか」「どのデータに触れるか」「どの権限で何を実行するか」が見えにくくなりがちです。だからこそ、Start/Stopのようなライフサイクル操作は、画面上の操作手順ではなく、組織全体の統制プロセスとして設計する必要があります。
今回の更新でやるべきこと
GitHubの公式ドキュメント更新「Remove Start/Stop section」を確認したら、まず社内の手順書に古いStart/Stop手順が残っていないかを確認してください。特に、Microsoft 365管理センター、All agents、Foundry agents、Azure AI Owner、Add Roleといった語句が含まれる手順は見直し対象です。
次に、エージェントごとに「利用を止めたいのか」「インフラを止めたいのか」「完全に削除したいのか」を分類します。利用制御ならBlock、廃止ならDelete、基盤停止ならFoundryやAzure側の最新ドキュメントと権限を確認する、という形で判断を分けるのが安全です。
最後に、検証環境で実際のUI、権限、監査ログ、復旧手順を確認してから本番Runbookを更新しましょう。今回の変更は小さな差分に見えますが、AIエージェントを本番運用する組織にとっては、ライフサイクル管理と権限設計を見直すよいタイミングです。
コメント