GitHubの公式ドキュメント更新「erikre-agents-11341543a7」で最初に押さえるべき点は、GitHubそのものの新機能追加ではなく、GitHub上の MicrosoftDocs/microsoft-365-docs リポジトリで公開された、Microsoft 365 管理センターのエージェント管理ドキュメント更新だということです。
2026年4月30日相当の更新では、エージェントの作成・公開・更新・却下・インスタンス管理に関する説明が整理されました。特に実務上は、社内手順書のリンク、管理画面のメニュー名、Agent Storeへの公開フロー、ZIPパッケージによる更新、AI teammateのインスタンス管理を確認する必要があります。公式コミットでは6ファイルが変更され、24行の追加と151行の削除、create-agent-instances.md の削除が確認できます。(GitHub)
GitHubの公式ドキュメント更新「erikre-agents-11341543a7」で何が変わったか
今回の更新は、GitHub上の MicrosoftDocs 系リポジトリに対するドキュメント差分です。そのため、API仕様やGitHub Actions、GitHub Enterpriseの機能変更として読むのではなく、Microsoft 365 管理センターでのエージェント管理手順がどう整理されたかを見るのが正しい読み方です。
主な変更点を実務目線で整理すると、次のようになります。
| 確認領域 | ドキュメント上の変更 | 実務で確認すべきこと |
|---|---|---|
| エージェントインスタンス作成 | create-agent-instances.md が削除され、参照先が「Manage agent instances」側へ寄せられた | 社内Wiki、運用Runbook、研修資料に古いURLや「Create AI agent instances」前提の手順が残っていないか確認する |
| Agent actions | Requested agent向けの Publish to store と Reject submission がアクションとして追加された | 承認者が「公開」と「却下」をどの基準で判断するか、レビュー項目を明文化する |
| Agent details | Update in store がアクションとして追加され、Agent instancesタブの説明も整理された | 既存エージェント更新時のZIPファイル、バージョン、承認証跡の扱いを確認する |
| Agent Registry | カスタムエージェント追加手順の入口が Upload custom agent ではなく Add agent として説明された | 画面キャプチャ、ヘルプデスク回答、社内申請フォームの文言を更新する |
| Agent Requests | 公開ウィザードで、ユーザー選択、ポリシーテンプレート、権限確認を行う流れが明確化された | 本番公開前に小規模グループで検証し、権限承認の責任者を決める |
Microsoft Learn側の該当ページも2026年4月30日に更新されており、Agent requests、Agent details、Agent Registry、Agent instances関連の説明が反映されています。(Microsoft Learn)
まず確認すべき仕様ポイント
ドキュメント更新だけで機能廃止と断定しない
create-agent-instances.md の削除は重要ですが、これだけで「エージェントインスタンス作成機能が廃止された」と断定するのは危険です。今回の差分では、作成専用ページが削除され、インスタンス管理の説明が別ページへ集約されたと読むのが自然です。
実務では、次の3点をセットで確認してください。
| 確認対象 | 見るべき内容 |
|---|---|
| GitHubの差分 | 削除されたページ、追加されたアクション、変更されたメニュー名 |
| Microsoft Learnの現行ページ | 現在の公式手順、最終更新日、ページ内リンク |
| 自社テナントの管理画面 | 実際に表示されるメニュー、権限、対象ユーザー、利用可能な機能 |
特に大企業や複数テナントを運用している組織では、ドキュメントの更新と管理画面への反映タイミングが完全に一致しないことがあります。記事や手順書を更新する際は、「公式ドキュメントではこうなっている」だけでなく、自社テナントでの表示も確認してから公開するのが安全です。
Agent Storeへの公開と却下は承認フローとして扱う
今回の更新で目立つのは、Requested agentに対する Publish to store と Reject submission の整理です。Microsoft Learnでは、Requested agentに対して選べる主要アクションとして、Agent Storeへ公開する Publish to store と、組織で利用可能にしない Reject submission が説明されています。公開ウィザードでは、対象ユーザー、保護ポリシー、必要な権限の確認が含まれます。(Microsoft Learn)
ここで重要なのは、公開を単なる「承認ボタン」として扱わないことです。エージェントは、データソース、カスタムアクション、外部接続、ユーザー権限に関わる可能性があります。公開前のレビューでは、少なくとも次の観点を確認してください。
| レビュー項目 | 確認する内容 |
|---|---|
| 利用目的 | 業務上の必要性が明確か。重複する既存エージェントがないか |
| 対象ユーザー | 全社公開が必要か、特定部門・検証グループで足りるか |
| データソース | OneDrive、SharePoint、Graphコネクタなど、参照先が業務上妥当か |
| 権限 | 管理者同意が必要な権限を誰が確認するか |
| 保護ポリシー | 既存テンプレート、既定テンプレート、カスタムテンプレートのどれを使うか |
| 監査 | 誰が申請し、誰が承認し、いつ公開したか記録できるか |
開発者は「動くかどうか」を見がちですが、管理者は「誰が使えるか」「何にアクセスできるか」「問題発生時に止められるか」を見ます。この視点の違いを承認プロセスに組み込むことが、Agent Store運用の失敗を減らします。
Update in storeはZIPパッケージ運用とセットで確認する
Agent detailsの説明では、既存のAgent Store上のエージェントをZIPパケットファイルで更新する Update in store が追加されています。Microsoft LearnのAgent detailsページでも、Update in storeは「提供されたZIPパケットファイルに基づいてAgent Store内の既存エージェントを更新する」アクションとして説明されています。(Microsoft Learn)
一方、Agent Registryでは、エージェントをアップロードするにはZIPパケットファイルが必要であり、ZIPにはマニフェスト、構成ファイル、アイコン、ブランディング、埋め込みナレッジファイルなどが含まれると説明されています。管理センターでの手順も Agents > All agents > Add agent に更新されています。(Microsoft Learn)
この変更で見直すべきなのは、更新作業そのものよりも「更新前後の管理」です。
| 場面 | 確認ポイント |
|---|---|
| 更新前 | ZIPの作成元、バージョン、変更内容、承認者を記録する |
| 更新中 | 対象エージェントを間違えないよう、名前・発行者・バージョンを照合する |
| 更新後 | 対象ユーザー、権限、ポリシー、動作確認結果を記録する |
| 障害時 | 旧版へ戻せるか、再アップロードが必要か、利用者へどう通知するかを決めておく |
特に複数の開発チームがエージェントを作成している環境では、「最新版のZIPはどれか」「誰が公開してよいか」が曖昧になりやすいです。Gitリポジトリ、チケット、変更申請、管理センターで同じバージョン番号を使うと、運用時の取り違えを防げます。
Agent instancesはAI teammate前提で整理する
Agent detailsの更新では、Agent instancesタブについて「Agent RegistryでAI teammateとしてタグ付けされたエージェントを選択した場合に表示される」と説明されています。AI teammate agentsは、組織が1つ以上のエージェントインスタンスを作成できるエージェントテンプレートとして扱われます。(Microsoft Learn)
また、Manage agent instancesページでは、管理者がAgent RegistryからAI teammateタグ付きエージェントを確認し、Instancesタブでインスタンス一覧を表示できること、個別設定、セキュリティ・コンプライアンス確認、ライセンス割り当てなどを管理できることが説明されています。(Microsoft Learn)
このため、社内手順では「すべてのエージェントにインスタンス管理タブがある」と書かない方が安全です。次のように分けて説明すると、問い合わせを減らせます。
| エージェントの種類 | 手順書での書き方 |
|---|---|
| 通常のカスタムエージェント | Agent detailsで利用者、権限、データソース、公開状態を確認する |
| AI teammateタグ付きエージェント | Instancesタブでインスタンス単位の状態、ライセンス、ブロック、削除を確認する |
| タブが表示されない場合 | エージェントの機能、タグ、テナント状態、管理者ロールを確認する |
「画面にタブがない」という問い合わせは、機能不具合ではなく、対象エージェントの種類や権限による表示差であることが多いです。手順書には、タブが表示される条件を明記しておきましょう。
運用影響：誰が何を確認すべきか
今回のGitHub公式ドキュメント更新は、開発者だけでなく、クラウド管理者、ソリューションアーキテクト、技術意思決定者にも影響します。直接のシステム停止を示す更新ではありませんが、管理画面の導線や承認フローを扱うため、社内運用にずれが出やすい内容です。
| 役割 | 確認すべきこと | 具体的なアクション |
|---|---|---|
| 開発者 | ZIPパッケージ、マニフェスト、更新申請の扱い | 更新版ZIPにバージョン番号を付け、変更内容をチケットに残す |
| クラウド管理者 | Agent Store公開、却下、更新、インスタンス管理 | 管理センターで実際のメニュー名と権限を確認する |
| ソリューションアーキテクト | エージェントの利用範囲、データアクセス、連携設計 | 全社公開か部門公開かを設計書に明記する |
| セキュリティ担当 | 権限、データソース、監査、削除時の影響 | 承認前チェックリストを作り、証跡を保存する |
| 技術意思決定者 | 導入判断、リスク許容度、段階展開 | 検証グループから始め、本番展開の判断基準を決める |
| サポート担当 | 利用者向け案内、FAQ、画面キャプチャ | 「Upload custom agent」など古い表現を「Add agent」に置き換える |
Microsoft Learnでは、Data & toolsの確認についてAI AdministratorまたはGlobal Administratorがアクセスできる一方、Global Administratorは高権限ロールであり、緊急時などに限定して使うべきと説明されています。運用設計では、最小権限の原則を前提にAI Administrator中心で作業を分担するのが現実的です。(Microsoft Learn)
移行準備として実施したい確認手順
この更新を受けて、すぐに全社展開の手順を変更する必要はありません。ただし、古いドキュメントや画面名に依存した運用は早めに修正すべきです。特に、Microsoft 365 CopilotやAgent Storeを本番運用している組織は、次の順番で確認すると効率的です。
| 手順 | 作業内容 | 完了基準 |
|---|---|---|
| 1 | GitHubの差分を確認する | 削除されたページ、追加されたアクション、変更された文言を把握している |
| 2 | 社内ドキュメントを検索する | create-agent-instances.md、Upload custom agent、古い画面名が残っていない |
| 3 | Microsoft Learnの現行ページを確認する | 2026年4月30日更新後のAgent details、Agent requests、Agent Registryを参照している |
| 4 | 自社テナントで画面を確認する | Agents > All agents配下のRegistry、Requests、Add agent、Instancesの表示を確認している |
| 5 | 小規模グループで公開テストする | Publish to store、ポリシーテンプレート、権限確認、対象ユーザー指定を検証している |
| 6 | 更新手順をテストする | Update in storeで使うZIP、承認者、変更履歴、ロールバック方針を確認している |
| 7 | インスタンス管理を確認する | AI teammateタグ付きエージェントで、Instancesタブ、ブロック、削除、ライセンス処理を確認している |
| 8 | サポート文言を更新する | 管理者向けFAQ、利用者向け案内、ヘルプデスク回答が現行手順に合っている |
Agent requestsページでは、Pending review、Pending update、Pending activateの3種類のリクエストが説明されています。特にPending updateでは、開発者が既存エージェントの更新を公開した場合、承認されるまで前のバージョンが利用者に提供され続けると説明されています。更新申請のレビュー体制を決める際は、この点を前提にしてください。(Microsoft Learn)
失敗しやすいポイント
「ドキュメント削除＝機能削除」と早合点する
今回のように、専用ページが削除されると「機能がなくなったのでは」と判断したくなります。しかし、公式差分を見る限り、インスタンス管理の説明はManage agent instances側へ整理されています。実際の運用判断では、GitHub差分、Microsoft Learn、管理センター画面の3つを照合してください。
古い画面名のまま社内手順を残す
Agent Registryのアップロード手順では、入口の表現が Upload custom agent から Add agent に変わっています。利用者や管理者向けの手順書に古い文言が残っていると、「画面にボタンがない」という問い合わせにつながります。画面キャプチャだけでなく、本文、FAQ、研修スライド、申請フォームの選択肢も見直しましょう。
公開範囲とインストール範囲を混同する
Agent detailsでは、エージェントの可用性とインストール設定が分けて説明されています。公開対象は「誰が見つけてインストールできるか」、インストール対象は「誰に事前インストールされるか」に関わります。公開範囲と自動インストール範囲を混同すると、想定外のユーザーにエージェントが表示されたり、逆に必要なユーザーが使えなかったりします。(Microsoft Learn)
権限確認を最後の形式チェックにしてしまう
公開ウィザードでは権限確認が含まれますが、承認直前に初めて権限を見る運用は危険です。データソース、カスタムアクション、外部接続があるエージェントは、設計段階でセキュリティ担当や管理者に共有しておくべきです。公開直前に差し戻しになると、開発チームと業務部門の両方に手戻りが発生します。
インスタンス削除後のライセンス処理を忘れる
Manage agent instancesページでは、インスタンス削除時に所有者への通知、インスタンスに紐づくMicrosoft 365ライセンスの削除または再割り当て、30日後の完全削除などが説明されています。インスタンスを消すだけで完了とせず、ライセンス、監査ログ、関係者通知まで含めて運用手順に入れてください。(Microsoft Learn)
実務で使える確認チェックリスト
以下のチェックリストを使うと、今回のGitHub公式ドキュメント更新を社内運用に反映しやすくなります。
| チェック項目 | 確認 |
|---|---|
| GitHubのコミット「erikre-agents-11341543a7」の差分を確認した | □ |
create-agent-instances.md への古いリンクを社内資料から削除・修正した | □ |
| 「Upload custom agent」という古い文言を「Add agent」に更新した | □ |
| Agent StoreへのPublish to storeとReject submissionの判断基準を決めた | □ |
| Pending review、Pending update、Pending activateの扱いを運用手順に反映した | □ |
| Update in storeで使うZIPの作成元、管理者、承認者を決めた | □ |
| 公開対象ユーザーと事前インストール対象ユーザーを分けて設計した | □ |
| AI teammateタグ付きエージェントのInstancesタブを確認した | □ |
| インスタンス削除時の通知、ライセンス処理、監査ログ確認を手順化した | □ |
| ヘルプデスク向けFAQと画面キャプチャを現行画面に合わせて更新した | □ |
今回の更新をどう扱うべきか
GitHubの公式ドキュメント更新「erikre-agents-11341543a7」は、GitHub製品そのものの変更情報としてではなく、Microsoft 365 管理センターにおけるエージェント管理ドキュメントの整理として読むべき更新です。
特に確認すべき点は、create-agent-instances.md の削除、Agent Storeへの公開・却下フロー、Update in store、Add agentへの文言変更、AI teammateのインスタンス管理です。すでにMicrosoft 365 CopilotやAgent Store関連の運用を始めている組織では、社内手順書、管理者Runbook、承認フロー、ZIPパッケージ管理、利用者向けFAQを見直してください。
次に取るべき行動は明確です。まず自社資料に古いリンクや画面名が残っていないかを検索し、次に管理センターで実際の表示を確認し、最後に小規模な検証グループでPublish to store、Update in store、Agent instances管理をテストします。ドキュメント更新を単なる情報収集で終わらせず、運用のズレを早めに直すことが、エージェント管理の安全性と展開スピードを両立させる近道です。
コメント