「GitHub documentation update: Remove Start/Stop section 2」でまず確認すべき結論は、GitHub本体の機能変更ではなく、GitHub上のMicrosoftDocsリポジトリにあるMicrosoft 365管理者向けドキュメントの整理だという点です。
2026年4月29日付のコミットでは、agent-actions.md から Microsoft Foundry agents の「Start/Stop」に関する案内が削除されています。ただし、これだけを見て「Start/Stop機能が廃止された」と判断するのは早計です。運用担当者は、Microsoft 365 admin center上の一般的なエージェント管理操作と、Foundry Control Planeのインフラ操作を分けて確認する必要があります。(GitHub)
GitHub documentation update: Remove Start/Stop section 2で何が変わったか
この更新は、MicrosoftDocsの microsoft-365-docs リポジトリ内にある microsoft-365/admin/manage/agent-actions.md への変更です。コミットメッセージは「Remove Start/Stop section 2」で、差分としては1ファイル、2行削除、追加なしです。削除されたのは、Agent actions一覧にあった「Start/Stop」項目で、Foundry agentsの基盤となるAzureインフラを開始または停止する操作として説明されていた部分です。(GitHub)
| 確認項目 | 内容 |
|---|---|
| 更新対象 | MicrosoftDocs / microsoft-365-docs |
| 対象ファイル | microsoft-365/admin/manage/agent-actions.md |
| 変更内容 | Agent actions一覧からStart/Stop項目を削除 |
| 差分規模 | 1ファイル変更、0追加、2削除 |
| 注意点 | GitHubの機能変更ではなく、Microsoft 365関連ドキュメントの更新 |
現行のMicrosoft Learnページでは、Microsoft 365 admin centerのエージェント管理操作として、Install / Uninstall、Block / Unblock、Delete、Assign a new owner、Publish to store、Reject submissionなどが案内されています。一方で、Start/Stopはこの一覧には含まれていません。(Microsoft Learn)
この更新を「機能廃止」と読まないほうがよい理由
今回の差分は、製品コードやAPI仕様の変更ではなく、ドキュメント内の項目削除です。そのため、運用判断では「Start/Stopという操作が完全になくなった」と断定するのではなく、どの画面、どのリソース種別、どの権限で使える操作なのかが整理されたと見るのが実務的です。
特に重要なのは、Microsoft 365 admin centerの「エージェントの可視性や利用可否を管理する操作」と、Foundry Control Planeの「Azureリソースやコンピュートに影響するインフラ操作」は性質が違うことです。Microsoftの別ドキュメントでは、Microsoft 365 admin centerやTeams admin centerのBlock操作はTeamsやMicrosoft 365 Copilot上の可視性に影響し、基盤Azureリソースやコンピュートには影響しないと説明されています。一方、Foundry Control PlaneのStop / Startはデプロイ単位でコンピュートを割り当て解除またはプロビジョニングし、Teams、Microsoft 365 Copilot、Foundry、APIなど複数チャネルに影響します。(Microsoft Learn)
運用担当者が確認すべき影響範囲
このドキュメント更新で見直すべきなのは、主に社内の運用手順書、管理者向け教育資料、自動化スクリプト、権限設計です。特に「Microsoft 365 admin centerでStart/Stopできる」と書いている手順がある場合は、対象がFoundry agent applicationなのか、通常のMicrosoft 365 Copilotエージェント管理なのかを切り分ける必要があります。
| 確認対象 | 見直すべきポイント | 放置した場合のリスク |
|---|---|---|
| 社内Runbook | Start/Stopをどの画面で実行すると書いているか | 管理者が存在しないボタンを探して対応が遅れる |
| 権限設計 | Microsoft 365管理権限とAzure RBACを混同していないか | 操作できるはずの担当者が実際には停止できない |
| 障害対応手順 | Block、Stop、Deleteの使い分けが明記されているか | 一時停止で済む場面で削除してしまう |
| コスト管理 | Compute停止の責任者と承認経路が決まっているか | Foundry側のリソース消費を止められない |
| 監査対応 | 操作ログをMicrosoft 365側とAzure側のどちらで確認するか | 監査証跡の確認先を誤る |
Start/Stop、Block/Unblock、Deleteの違いを整理する
AIエージェント運用で失敗しやすいのは、似たような管理操作を同じ意味で扱ってしまうことです。特にStart/Stop、Block/Unblock、Deleteは影響範囲が異なります。
| 操作 | 主な意味 | 使う場面 | 注意点 |
|---|---|---|---|
| Start / Stop | Foundry側のデプロイや基盤インフラを開始・停止する | コスト抑制、重大な不具合、セキュリティ上の緊急停止 | 影響が全チャネルに及ぶ可能性がある |
| Block / Unblock | ユーザーが特定チャネルからエージェントを使えないようにする | Microsoft 365 CopilotやTeamsでの一時的な利用制御 | 基盤インフラが止まるとは限らない |
| Delete | エージェントや関連データを削除する | 廃止済みエージェントの整理 | 復元できない可能性が高く、最終手段にすべき |
| Assign new owner | 所有者不在または運用継続が必要なエージェントの管理者を変更する | 退職、異動、組織変更 | 旧所有者のアクセス権が変わるため事前確認が必要 |
Foundry Control Planeでは、Stopするとエージェントに関連するインフラが停止され、Stopped状態に移行します。ただし、既存の実行中処理を終了する操作ではないと説明されています。Startは停止後の再開操作です。(Microsoft Learn)
また、Deleteは特に慎重に扱う必要があります。Microsoft 365 admin centerのドキュメントでは、Agent Builderで作成したエージェントの削除はインベントリからの削除、関連ファイルの削除、SharePoint Embeddedコンテナーの削除を伴い、削除処理は不可逆で、反映に最大24時間かかる場合があると説明されています。(Microsoft Learn)
Microsoft 365 admin centerとFoundry Control Planeを切り分ける
今回の更新で最も大事なのは、「Microsoft 365 admin centerに表示される操作」と「Foundry Control Planeで実行するインフラ操作」を混同しないことです。
Microsoftの管理者向け説明では、Foundry agent applicationについてはMicrosoft 365 admin centerのレジストリエントリからStart / Stopできる場合がある一方、Foundry agentそのものはMicrosoft 365 admin center上ではStart / Stop対象ではなく、別インターフェースの利用が必要と整理されています。さらに、Stop / Startボタンの表示は、対象がagent applicationであることや必要な権限を持っていることに依存します。(Microsoft Learn)
実務では、次のように判断すると混乱を避けられます。
| 判断軸 | 確認すること |
|---|---|
| 対象リソース | Foundry agentか、Foundry agent applicationか |
| 管理画面 | Microsoft 365 admin centerか、Foundry portalか、Azure portalか |
| 操作目的 | ユーザーから見えなくしたいのか、基盤インフラを止めたいのか |
| 影響範囲 | Microsoft 365 Copilot / Teamsだけか、APIやFoundry利用も含むか |
| 権限 | Microsoft 365管理者権限だけで足りるか、Azure RBACが必要か |
開発者が確認すべき点
開発者は、エージェントの公開状態とIDの変化を確認してください。Foundryでは、エージェントを公開するとAgent Applicationリソースが作成され、呼び出しURL、認証ポリシー、専用のEntra agent identityなどが付与されます。公開後は、開発時に使っていたプロジェクト共有IDとは異なるIDになるため、必要なRBAC権限を再付与しないとツール呼び出しが認可エラーになる可能性があります。(Microsoft Learn)
開発チームが行うべき確認は次の通りです。
- 公開済みエージェントと未公開エージェントを分けて一覧化する。
- Agent Applicationとして公開されているものを特定する。
- 公開後のEntra agent identityに必要なRBACが付いているか確認する。
- Stop / Startを前提にしたテスト手順が、正しいリソース種別を対象にしているか見直す。
- API経由で呼び出している場合、停止時にどのようなエラーや応答になるかを検証する。
特に本番環境では、「Microsoft 365 Copilotから見えない」状態と「APIからも呼び出せない」状態は別物として設計してください。
クラウド管理者が確認すべき点
クラウド管理者は、コスト、権限、監査ログの観点から影響を確認します。Start/Stopは単なる表示制御ではなく、Foundry側のコンピュートやAzureリソースに関係する可能性があります。そのため、Microsoft 365の管理ロールだけで完結する運用と考えると、緊急時に停止できないことがあります。
確認すべきポイントは次の通りです。
| 項目 | 確認内容 |
|---|---|
| Azure RBAC | 対象リソースに対するOwner、Contributor、Azure AI関連ロールの割り当て |
| PIM | 特権ロールを一時的に有効化する手順 |
| リソース所有者 | Foundry project、agent application、関連リソースグループの責任者 |
| 監査ログ | Microsoft 365側、Azure Activity Log、Application Insightsの確認先 |
| コスト影響 | Stop対象のデプロイと、停止しても残るリソース費用の切り分け |
重大なセキュリティインシデントでは先に停止する判断が必要な場合がありますが、通常の不具合やコスト超過では、リソース所有者と調整してから対応するほうが安全です。Microsoftの管理者向け説明でも、状況に応じてリソース所有者との調整を推奨しています。(Microsoft Learn)
ソリューションアーキテクトが見直すべき設計観点
ソリューションアーキテクトは、エージェントのライフサイクル管理を「チャネル管理」「実行基盤管理」「ID・権限管理」の3層で設計し直すとよいでしょう。
| 設計レイヤー | 代表的な論点 | 設計上の判断基準 |
|---|---|---|
| チャネル管理 | Copilot、Teams、Outlookなどで見せるか | ユーザー影響を最小限に抑えたい場合はBlock/Unblockを優先 |
| 実行基盤管理 | FoundryやAzure上のデプロイを動かすか | コストや安全性を制御したい場合はStop/Startを検討 |
| ID・権限管理 | 誰が呼び出せるか、どのリソースにアクセスできるか | 公開後のAgent Application単位でRBACを確認 |
| 廃止管理 | エージェントを残すか削除するか | 再開可能性があるならDeleteではなくStopを優先 |
この切り分けをしておくと、障害対応時に「利用者から隠すだけでよいのか」「インフラごと止めるべきか」「恒久的に削除してよいのか」を短時間で判断できます。
移行準備として進める具体的な手順
ドキュメント更新を受けて、すぐに大規模な移行を始める必要はありません。まずは、既存手順が誤解を生まない状態になっているかを点検します。
エージェント棚卸しを行う
管理対象のエージェントを一覧化し、少なくとも次の項目を記録します。
| 項目 | 記録例 |
|---|---|
| エージェント名 | 社内FAQエージェント、営業支援エージェントなど |
| 作成元 | Agent Builder、Copilot Studio、SharePoint、Foundryなど |
| 公開状態 | 未公開、公開済み、Agent Application化済み |
| 利用チャネル | Microsoft 365 Copilot、Teams、APIなど |
| 所有者 | 部門、担当者、代替担当者 |
| 緊急時の操作 | Block、Stop、Deleteのどれを使うか |
Runbookの表現を修正する
「Microsoft 365 admin centerでStart/Stopする」といった曖昧な表現は避けます。代わりに、次のように書き換えます。
| 変更前 | 変更後 |
|---|---|
| エージェントを停止する | Microsoft 365 Copilot上の利用を止める場合はBlock。Foundryの基盤実行を止める場合は対象がAgent Applicationか確認してStopを実行する。 |
| 問題があればDeleteする | 復旧可能性がある場合はStopまたはBlockを優先し、Deleteは廃止承認後に実行する。 |
| 管理センターで操作する | 操作対象に応じてMicrosoft 365 admin center、Foundry portal、Azure portal、REST APIを選択する。 |
非本番または低リスク対象で操作を検証する
Start/StopやBlock/Unblockは、影響範囲を文章で理解するだけでは不十分です。検証環境または影響の小さいエージェントで、次の動作を確認してください。
- BlockしたときにCopilotやTeamsからどう見えるか。
- StopしたときにAPI呼び出しや既存ワークフローがどう失敗するか。
- Start後に正常復帰するまでの時間。
- 操作ログがどこに残るか。
- 権限不足の場合、管理者画面にどのような表示が出るか。
この検証結果をRunbookに反映しておくと、障害時の初動が大きく改善します。
よくある誤解と正しい見方
GitHubの機能が変わったという意味ではない
今回の「GitHub documentation update」は、GitHub上で管理されているMicrosoftDocsのコミットです。GitHub Actions、GitHub Copilot、GitHub EnterpriseなどのGitHub製品機能が変更されたという意味ではありません。
Start/Stopが完全に消えたとは限らない
削除されたのは、Microsoft 365 admin centerのAgent actionsドキュメント内にあったStart/Stop項目です。Foundry Control PlaneやFoundry agent applicationの文脈では、Start/Stopが別途説明されています。したがって、対象リソースと操作画面を確認して判断する必要があります。(Microsoft Learn)
BlockとStopは同じではない
Blockは主にユーザーからの利用や特定チャネルでのアクセスを止める操作です。Stopは基盤インフラやデプロイに影響する操作です。ユーザー影響を限定したいならBlock、コストや安全性の理由で実行基盤を止めたいならStopを検討します。
Deleteを停止代わりに使わない
Deleteは復旧できない影響を伴う可能性があります。MicrosoftのFoundry関連ドキュメントでも、削除より停止を優先し、Deleteは最終手段として扱う考え方が示されています。(Microsoft Learn)
この記事を読んだ後に取るべき行動
GitHubの公式ドキュメント更新「Remove Start/Stop section 2」を確認したら、まず社内の運用資料に「Microsoft 365 admin centerでStart/Stopする」といった曖昧な記述がないかを点検してください。次に、管理対象エージェントをFoundry agent、Foundry agent application、Agent Builder、Copilot Studioなどに分類し、Block、Stop、Deleteの使い分けをRunbookに明記します。
今回の更新で重要なのは、単に削除された2行を追うことではありません。エージェント管理がMicrosoft 365の表示制御、Foundryの実行基盤、Azure RBACの権限管理にまたがることを前提に、運用手順を現実の管理画面と権限に合わせて更新することです。まずは影響の小さいエージェントを1つ選び、BlockとStopの挙動、ログ、復旧手順を検証するところから始めると安全です。
コメント