Security Copilot を導入するなら、今いちばん先に確認すべきなのは Azure の設定ではなく、自社が Microsoft 365 E5 による自動有効化の対象かどうか です。2026年4月上旬に更新された Microsoft Learn のオンボーディング関連ドキュメントでは、導入フローが「E5 で自動プロビジョニングされる組織」と「SCU を手動で用意する組織」に明確に分かれました。E5 対象なら 30 日前通知の後にテナントへ自動準備され、非E5なら SCU の手動プロビジョニングが必要です。 (Microsoft Learn)
今回の更新が実務に効くのは、入門ガイドが単なる初期設定手順ではなく、ライセンス判定、容量モデル、権限、データ設定、導入後のプロンプトやエージェント活用までを一続きのオンボーディングとして見せ始めた点です。いまの Security Copilot オンボーディングは、「入れる」ことより「どう安全に使い始めるか」に重心が移っています。 (Microsoft Learn)
今回の入門ガイド更新で見える変化
総合ガイド本体の最終更新は 2026年4月7日で、E5 自動プロビジョニング解説と Microsoft 365 E5 inclusion の解説ページは 4月9日に更新されています。4月上旬の更新をまとめて見ると、Microsoft はオンボーディングの入口を「何を設定するか」ではなく「どの顧客区分に当てはまるか」へ明確に寄せています。 (Microsoft Learn)
総合ガイドは Step 1 で customer category を判定し、Step 2 で E5 included と non-E5 に進路を分岐します。さらに Next steps ではナビゲーション、プロンプト、エージェント、プラグイン、コネクタ、プロンプトブックまで案内しており、導入後の使い始め方までが正式にオンボーディングの範囲に入っています。これは、製品が単体ポータル中心から、既存の業務フローへ組み込む前提へ進んだことを示す構成です。 (Microsoft Learn)
まず確認すべきは E5 inclusion の対象かどうか
| 確認項目 | Microsoft 365 E5 included 組織 | 非E5組織 |
|---|---|---|
| 導入の起点 | テナント有効化後に自動プロビジョニング | 手動で SCU を準備 |
| Azure 側の初期作業 | 原則不要 | Azure サブスクリプションと容量作成が必要 |
| 容量モデル | 月次の inclusion capacity | provisioned / overage capacity |
| 請求の考え方 | テナント共有の月次 SCU バケット。UI の金額表示は請求ではない | provisioned は時間単位、overage は利用量ベース |
| 最初に見る場所 | Microsoft 365 管理センターの通知、各製品内バナー、Security Copilot ポータル | Security Copilot ポータル、または Azure ポータル |
※表は公式オンボーディング ガイド、E5 inclusion 解説、SCU 容量ガイドをもとに整理しています。 (Microsoft Learn)
E5 組織で大事なのは、「ライセンスを持っている」ことと「すでにテナントで有効化された」ことは同じではない という点です。Microsoft は 30 日前通知の後にテナントを自動プロビジョニングし、確認は Microsoft 365 管理センターの通知、または Defender、Purview、Entra、Intune、Security Copilot ポータルのバナーで行えます。Rollout は 2025年11月18日に開始され、2026年4月時点でも段階展開の説明が続いています。 (Microsoft Learn)
有効化された E5 テナントには tenant-wide の Default Security Copilot Capacity が自動作成されます。これは既定の workspace と一緒に作られ、時間課金ではなく月次の inclusion capacity として扱われ、UI 上のコスト表示は参考値であって請求額ではありません。E5 の included capacity は 1,000 paid user license ごとに月 400 SCUs、最大 10,000 SCUs です。すでに手動で capacity を持っている既存ユーザーは、Microsoft も削除を推奨していません。 (Microsoft Learn)
一方、非E5組織は今も manual onboarding が前提です。Azure サブスクリプションが必要で、Security Copilot ポータルからのセットアップが推奨ルートです。最小 1 SCU、最大 100 SCUs を購入でき、Microsoft は introductory exploration として 3 SCUs + unlimited overage を推奨しています。Azure から capacity を作る方法もありますが、この場合は capacity を workspace にひも付ける前でも、作成した時点で課金が始まる点に注意が必要です。 (Microsoft Learn)
実務で失敗しやすいポイント
ライセンス確認前に容量設計へ進む
Microsoft は、E5 ライセンス状況を確認する前にオンボーディングを始めないよう明記しています。理由はシンプルで、E5 対象かどうかで手順も、容量購入の必要性も変わるからです。E5 対象なのに先に Azure で設計を始めると、不要な検討や誤請求リスクを抱えやすくなります。 (Microsoft Learn)
SCU をひとつの単位感覚で扱う
SCU は同じ “SCU” でも、E5 inclusion は月次バケット、provisioned は時間単位、overage は利用量ベース です。ここを混同すると、「使っていないのに高い」「月末に急に止まった」といった認識ズレが起きやすくなります。特に provisioned capacity は時間ブロック単位で計算され、未使用分は繰り越されません。 (Microsoft Learn)
Copilot の権限と実データの権限を混同する
Security Copilot の owner / contributor は、あくまで Copilot プラットフォームの機能権限 です。これだけでは Defender、Intune、Sentinel、Purview などの実データには触れられず、各サービス側の Entra RBAC や Azure RBAC も別途必要です。Copilot を使わせたいからといって Security Administrator を安易に配るのは危険で、Microsoft も最小権限と security group ベースの運用を推奨しています。 (Microsoft Learn)
なお、新しい Security Copilot インスタンスでは contributor access の既定が Recommended Microsoft Security roles になっており、Everyone を広く付ける初期方式は見直し方向です。古い環境で Everyone ベースの権限が残っているなら、いまが整理のタイミングです。 (Microsoft Learn)
自動有効化されたらエージェントも勝手に動くと思う
ここも誤解しやすい点です。Security Copilot のエージェントは自動有効化ではなく、個別セットアップが必要 です。エージェントごとに identity の選択やパラメーター設定が必要で、場合によっては Global Administrator の同意が求められます。E5 で platform が使えるようになっても、運用自動化は別工程だと考えた方が安全です。 (Microsoft Learn)
自動プロビジョニングでも確認したい設定
| 設定項目 | 既定・仕様 | 管理者が見るポイント |
|---|---|---|
| Customer Data の保存場所 | 既定 workspace では Entra geography。ADR 利用時は ADR で選択した地域 | データ所在地要件に合うか |
| データ共有設定 | 自動プロビジョニングでは OFF | 検証・改善目的でどこまで許可するか |
| Microsoft 365 service data へのアクセス | ON | Purview などとの連携を使うか。OFF だと活用範囲が狭くなる |
| Audit logging | Purview 連携で保存。多くのケースで有効化後 24 時間以内にログ利用可能 | 監査・追跡要件がある組織は早めに有効化 |
| Usage monitoring | Owner が利用可能。最大 90 日分を確認可能 | 実利用を見て SCU と対象ワークフローを調整 |
※表は自動プロビジョニング、Owner settings、Usage monitoring、Privacy 関連ドキュメントをもとに整理しています。 (Microsoft Learn)
特に見落としやすいのが、Microsoft 365 service data へのアクセスを切ると Purview などとの連携価値が大きく落ちる 点です。逆に、監査や規制要件が強い組織は Purview への audit logging を早めに有効化しておくと、後から「いつ誰が何をしたか追えない」を防げます。 (Microsoft Learn)
オンボーディング後は「プロンプト → 利用監視 → エージェント」の順が安全
Microsoft の Next steps も、まずプロンプトやプロンプトブック、ワークフロー探索を案内しています。実務でも、導入直後にエージェントを大量展開するより、先に役割別のプロンプトで現場に慣れてもらい、usage monitoring で実際の SCU 消費と利用部門を見てから、自動化対象をエージェントに寄せる方が失敗しにくいです。 (Microsoft Learn)
最初の一歩は役割別のプロンプトから始める
Security Copilot には、ホーム画面からすぐ使える ready-made prompts / promptbooks が用意されており、CISO、SOC analyst、threat intel analyst、IT administrator といった役割や、関連プラグインで絞り込めます。最初は「インシデント要約」「調査支援」「既知の運用フローの時短」のように、結果を人がレビューしやすい用途から始めると定着しやすいです。 (Microsoft Learn)
次に、感覚ではなく usage monitoring で見る
usage monitoring dashboard では、provisioned / overage の使用量だけでなく、どのプラグインが使われたか、誰がセッションを開始したかまで追えます。フィルターやエクスポートもでき、最大 90 日分を見られるので、「なんとなく重い」「思ったより使われていない」を数字で判断できます。 (Microsoft Learn)
エージェントは高頻度・反復業務から絞る
Microsoft が高価値例として挙げているのは、ユーザー申告のフィッシング トリアージ、アラート トリアージ、アクセス レビュー、脆弱性対応などです。どれも件数が多く、担当者の判断を補助しやすい領域です。最初から全部を狙うのではなく、件数が多い・判断基準がある・効果測定しやすい 業務を 1 つ選ぶのが現実的です。 (Microsoft Learn)
製品成熟に伴ってオンボーディングはどう変わったか
現在の公式情報では、Security Copilot は standalone portal だけでなく Defender、Entra、Intune、Purview などの embedded experiences に広がり、administrators、end users、developers を前提に、エージェント、プラグイン、コネクタ、プロンプトブックを組み合わせる前提で説明されています。さらに workspaces により、チームや地域、業務単位で access、capacity、plugins、promptbooks を切り分けられるようになっています。 (Microsoft Learn)
その結果、オンボーディングの重心も「最初に買ってつなぐ」から、「どのワークフローに、どの権限・workspace・capacity で流し込むか」へ変化しています。今回の入門ガイド更新は、製品の成熟を機能一覧ではなく、導入の入口そのもので表現し始めたものだと見ると分かりやすいです。 (Microsoft Learn)
いま担当者がやるべきこと
- Microsoft 365 管理センターと、Defender、Purview、Entra、Intune、Security Copilot ポータルで enablement 通知を確認する。E5 を持っていても、テナント有効化前に manual onboarding へ進まないことが重要です。 (Microsoft Learn)
- E5 対象なら、Default Security Copilot Capacity と owner settings を確認し、データ共有、Microsoft 365 service data access、audit logging の方針を決める。 (Microsoft Learn)
- 非E5 なら、Security Copilot ポータル経由で 3 SCUs + overage の初期設計をたたき台にし、usage dashboard で見直す前提で始める。Azure 先行作成は課金開始タイミングを理解してから選ぶべきです。 (Microsoft Learn)
- 権限は個人ではなく security group で付与し、Copilot role と各製品の RBAC を分けて設計する。Global Administrator を常用しない。 (Microsoft Learn)
- 最初のユースケースは 1 つに絞る。フィッシング トリアージ、インシデント要約、アクセス レビュー、脆弱性対応のような、件数が多く効果測定しやすい業務から始める。 (Microsoft Learn)
今回の Security Copilot 入門ガイド更新が示しているのは、オンボーディングの主語が「製品」から「組織運用」へ移った、ということです。最初に E5 inclusion の有無を判定し、次に roles と owner settings を整え、最後に 1 つの具体的なワークフローで使い始める。この順番で進めれば、遠回りしにくく、Security Copilot の価値も見えやすくなります。 (Microsoft Learn)
コメント