Security CopilotのSecurity Compute Unit（SCU）使用量管理でまず押さえるべき結論は、SCUは「使った後に請求を眺めるもの」ではなく、管理者が日常的に監視し、上限接近時の対応ルールまで決めておくべき運用項目だという点です。Microsoft Learnの公式情報では、Security Copilotの使用量監視ダッシュボードで、プロビジョニング済みSCU、超過SCU、利用ユーザー、プラグイン、呼び出し元エクスペリエンス、手動・自動実行の種別などを確認できることが整理されています。ダッシュボードは最大90日分のデータを扱えるため、導入直後の利用傾向把握や、SOC業務・自動化処理・エージェント展開後の容量見直しに使えます。(Microsoft Learn)
特に管理者が確認すべきなのは、誰が、どの機能から、どのプラグインを使って、どれだけSCUを消費しているかです。Security Copilotは単体ポータルだけでなく、Microsoft Defender XDRなどの組み込みエクスペリエンス、Azure Logic Apps、Microsoft製またはパートナー製エージェントからもSCUを消費します。利用範囲が広がるほど、プロンプト利用だけを見ていると実態を見誤るため、利用ログの見方と容量調整の手順を事前に整えておく必要があります。(Microsoft Learn)
Microsoftの公式情報で整理されたポイント
2026年6月上旬に更新された「Manage security compute unit usage in Security Copilot」では、Security CopilotのSCU使用量をどう監視し、容量上限に近づいたときにどう対応するかが、管理者向けに具体化されています。Microsoft Learn上では米国表記で2026年6月4日が最終更新日として表示されています。(Microsoft Learn)
今回のポイントは、単なる「使用量グラフの見方」ではありません。実務上は、次の4つを確認する更新と捉えると分かりやすくなります。
| 確認ポイント | 管理者が見るべき内容 | 実務上の意味 |
|---|---|---|
| 使用量の可視化 | SCUの消費量、利用者、プラグイン、実行元 | コスト増・容量不足の原因を特定しやすくなる |
| フィルターとエクスポート | ユーザー、プラグイン、カテゴリ、種類などで絞り込み | Excelで月次レビューや部門別分析ができる |
| 上限接近・超過時の挙動 | 上限に近づくと通知、100%到達時はエラー表示 | 調査中の業務停止を避けるための事前対応が必要 |
| 容量変更と削除 | AzureポータルまたはSecurity CopilotポータルでSCUを変更 | 権限、反映時間、削除時の不可逆性を確認する必要がある |
Security Copilotをすでに運用している組織では、まず「どのチームがどの機能でSCUを使っているか」を棚卸ししてください。これから導入する組織では、PoCや初期展開の段階から使用量監視ダッシュボードを運用に組み込むべきです。
Security Compute Unit（SCU）とは何か
SCUは、Microsoft Security Copilotのワークロードを実行するためのコンピューティング容量を表す単位です。単体ポータルでのチャット、組み込み型のCopilot機能、Microsoft製エージェント、パートナー製エージェント、その他のSecurity Copilot機能を使うとSCUが消費されます。(Microsoft Learn)
たとえば、SOCアナリストがMicrosoft Defender XDR上でインシデント要約を実行する場合、これは「Security Copilotポータルを開いていないからSCUを使っていない」という扱いにはなりません。Security Copilotの機能が裏側で使われていれば、組み込みエクスペリエンス経由でもSCU消費の対象になります。
SCUを理解するための基本分類
| 種類 | 概要 | 向いているケース |
|---|---|---|
| プロビジョニング済み容量 | 事前に確保するSCU容量 | 利用量が安定している組織、定常的なSOC運用 |
| 超過容量 | プロビジョニング済み容量を超えた場合に使う追加容量 | インシデント急増時、調査集中時、エージェント利用拡大時 |
| Microsoft 365 E5/E7の包含容量 | 対象顧客に自動作成される既定のSecurity Copilot容量 | Microsoft 365 E5/E7を利用する組織 |
プロビジョニング済み容量は、事前に確保した分を基準に使うモデルです。Microsoft Learnでは、最小1 SCUからプロビジョニングでき、容量は固定の1時間単位で更新され、未使用分は次の時間に繰り越されないと説明されています。(Microsoft Learn)
一方、超過容量は想定外の利用増に備える仕組みです。上限を設定することも、無制限に設定することもできます。ただし、無制限にすると業務停止のリスクは下がる反面、想定外の消費が発生する可能性があります。管理者は「業務継続を優先するのか」「予算上限を厳密に守るのか」を先に決めておく必要があります。(Microsoft Learn)
使用量監視ダッシュボードで確認できる内容
Security Copilotの使用量監視ダッシュボードは、Copilot所有者がSecurity Copilotポータルから確認できます。手順は、Security Copilotにサインインし、HomeメニューからOwner settingsへ進み、Usage monitoringを選択します。ダッシュボードでは、Microsoft Security Copilotワークロードが一定期間に消費したSCU量を確認できます。(Microsoft Learn)
ダッシュボードで特に重要なのは、単なる合計値ではなく「消費の内訳」です。SCU使用量が増えた場合、次のように原因を切り分けます。
| ダッシュボード項目 | 見るべき理由 | 確認例 |
|---|---|---|
| Units used | セッション単位のSCU消費量を確認する | 特定のプロンプトブックだけ消費が大きい |
| Initiated by | 実行ユーザーを確認する | 一部ユーザーが検証用途で大量利用している |
| Category | Prompt、Promptbook、Agentのどれかを確認する | エージェント導入後に消費傾向が変わった |
| Type | Manual ActionかAutomated Actionかを確認する | Logic Appsやスケジュール実行が原因になっている |
| Copilot experience | 単体ポータル、組み込み、Logic Appsなど実行元を確認する | Defender XDR上の利用が多い |
| Plugin used | 使用プラグインを確認する | Microsoft EntraやMicrosoft Defender XDRの利用が集中している |
| Status | SCUが使用された状態を確認する | 利用可能容量を使い切っていないか確認する |
Microsoft Learnでは、カテゴリとしてPrompt、Promptbook、Agentが示されています。Promptは単一のプロンプト、Promptbookは複数のプロンプトを呼び出すセッション、Agentは目的達成のために環境を認識し、判断し、結果を生成する計算主体として説明されています。(Microsoft Learn)
この分類は、管理者にとって非常に重要です。たとえば、利用量が増えている原因がPromptであれば、ユーザー教育やプロンプト設計の見直しが効果的です。Promptbookが原因なら、実行頻度や対象範囲を見直します。Agentが原因なら、自動実行の条件、対象データ、稼働時間、権限範囲を確認する必要があります。
フィルターとエクスポートの実務的な使い方
使用量監視ダッシュボードでは、Copilot experience、Users、Plugins used、Type、Categoryでフィルターできます。Microsoft Learnでは、現時点でフィルターはテーブルにのみ適用され、棒グラフには適用されない点も注意事項として示されています。(Microsoft Learn)
この仕様を知らないと、グラフを見て「フィルター後の数字だ」と誤解する可能性があります。実務では、フィルター適用後のテーブルを確認し、必要に応じてExcelにエクスポートして分析する流れが安全です。
目的別のフィルター活用例
| 目的 | 使うフィルター | 判断ポイント |
|---|---|---|
| 部門・担当者別の利用状況を知りたい | Users | 特定ユーザーに利用が偏っていないか |
| 自動化による消費を把握したい | Type | Automated Actionの比率が高すぎないか |
| エージェント利用の影響を見たい | Category | Agentカテゴリの増加が容量を圧迫していないか |
| 組み込み機能の利用を見たい | Copilot experience | Defender XDRやLogic Apps経由の利用が多くないか |
| プラグイン別の傾向を見たい | Plugins used | 特定プラグインが高頻度で呼び出されていないか |
日次運用では、すべてを細かく見る必要はありません。まずは「直近24時間」「過去7日」「過去30日」の3つの期間で、SCU消費が急増した日と、その日のユーザー・カテゴリ・プラグインを確認します。
月次レビューでは、Excelエクスポートを使って、チーム別、機能別、手動・自動別に集計するとよいでしょう。Microsoft Learnでは、ダッシュボード右上のExportボタンからExcelファイルとして使用量データをエクスポートできるとされています。(Microsoft Learn)
影響範囲：誰が対応すべきか
Security CopilotのSCU管理は、単にセキュリティ担当者だけの作業ではありません。容量、権限、請求、データ利用、自動化が関係するため、複数の担当者で役割分担する必要があります。
| 担当者 | 主な確認項目 | 対応例 |
|---|---|---|
| Security Copilot所有者 | 使用量監視、利用傾向、ダッシュボード確認 | 毎週のSCUレビュー、過剰利用の検知 |
| Azure容量所有者・共同作成者 | SCUの増減、超過容量、課金影響 | プロビジョニング済みSCUや超過SCUの調整 |
| SOC管理者 | アナリスト業務への影響 | 上限到達時の代替手順、重要インシデント時の優先順位設定 |
| Microsoft 365管理者 | E5/E7包含容量、通知、既定ロール | Microsoft 365管理センターの通知確認 |
| 開発者・自動化担当 | Logic Apps、API、エージェント、プロンプトブック | 自動実行頻度、対象範囲、失敗時リトライの見直し |
| 財務・ライセンス担当 | 月次費用、超過利用、契約形態 | 予算上限、利用部門への配賦ルール策定 |
特に注意したいのは、開発者や自動化担当が作成したLogic Appsやエージェントです。人間がプロンプトを入力する手動利用と違い、自動化処理は気づかないうちに実行回数が増えることがあります。テスト環境で作ったワークフローを本番データに接続したままにする、失敗時のリトライが多すぎる、スケジュール実行の頻度が高すぎる、といった設定はSCU消費を押し上げる典型例です。
上限に近づいたとき・超過したときの挙動
Microsoft Learnでは、組織の使用量が上限に近づくと、プロンプト送信時に通知が表示されると説明されています。上限に近い状態では、Azure容量所有者または共同作成者に連絡してSCUを増やすか、プロンプト数を制限することで中断を避ける必要があります。(Microsoft Learn)
さらに、プロビジョニング済みSCUと超過SCUを使い切った場合、アナリストは「組織内の使用量が高いためCopilotが要求に応答できない」という趣旨のエラーを確認し、その時点では追加のプロンプトを送信できなくなります。Microsoft Learnでは、容量が100%に到達した場合にこのエラー表示が出るとされています。(Microsoft Learn)
上限接近時に決めておくべき対応ルール
| 状況 | その場の対応 | 事前に決めるべきこと |
|---|---|---|
| 上限接近の通知が出た | 不要なプロンプト、検証実行、自動処理を一時停止 | 誰がSCU増加を判断するか |
| 調査中に通知が出た | 重要インシデント対応を優先し、低優先度タスクを止める | SOC内の利用優先順位 |
| 100%到達でエラーになった | Azure容量所有者・共同作成者へ連絡 | 緊急時の連絡先と承認フロー |
| 毎週同じ時間帯に逼迫する | 定期処理や自動化スケジュールを見直す | バッチ処理と人手調査の時間分散 |
実務では、上限到達後に初めて連絡先を探す運用は危険です。SOCの調査中にSecurity Copilotが使えなくなると、インシデント要約、アラート分析、修復支援などの作業が遅れる可能性があります。事前に「誰が容量を増やせるのか」「休日・夜間はどうするのか」「上限接近時に止める自動処理は何か」を運用手順書に明記しておきましょう。
SCU容量を変更する手順と権限
プロビジョニング済みSCUと超過SCUは、AzureポータルまたはSecurity Copilotポータルから更新できます。Microsoft Learnでは、Azureポータルでの変更にはAzure capacity ownerまたはcontributorが必要で、Security Copilotポータルでの変更にはAzure capacity ownerまたはcontributorであり、かつSecurity Copilot ownerであることが必要とされています。(Microsoft Learn)
容量変更は、Security CopilotポータルのOwner settingsページからSecurity compute unitsまたはNumber of overage unitsのChangeを選ぶ方法と、使用量ダッシュボードのChange unitsから変更する方法があります。変更時には、Azureでの請求情報を確認するためのView billing in Azureも利用できます。(Microsoft Learn)
容量変更前のチェックリスト
| チェック項目 | 理由 |
|---|---|
| 変更する担当者に必要なロールがあるか | 権限不足だと緊急時に変更できない |
| プロビジョニング済みSCUと超過SCUのどちらを変えるか | 定常利用増なのか、一時的なピーク対策なのかで判断が変わる |
| 変更後の概算月額コストを確認したか | SCU数を増減すると見積もりコストも変わる |
| 反映までの時間を見込んでいるか | Microsoft Learnでは容量調整の反映は30分以内が目安とされている |
| 自動化処理の実行タイミングを確認したか | 容量増加だけでなく、消費側の制御も必要 |
| 変更履歴を残す運用にしているか | 月次レビューや監査時に説明しやすくなる |
Microsoft Learnでは、ユーザーは容量調整が30分以内に反映されることを期待できると記載されています。ただし、実務では「即時に必ず反映される」と決めつけず、重要作業の直前ではなく、余裕を持って変更する運用が安全です。(Microsoft Learn)
開発者・自動化担当が注意すべきポイント
Security CopilotのSCU管理は、管理ポータルを見る担当者だけの問題ではありません。Logic Apps、API、プロンプトブック、カスタムエージェントを扱う開発者は、SCU消費を設計段階から考慮する必要があります。
特に注意すべきなのは、次の3つです。
| 注意点 | 失敗例 | 対策 |
|---|---|---|
| 自動実行の頻度 | 5分ごとの実行で想定以上にSCUを消費する | 本当に必要な頻度に落とし、イベント駆動も検討する |
| 対象データの範囲 | 毎回全インシデントや全アラートを対象にする | 期間、重大度、ステータスで絞り込む |
| リトライ設計 | エラー時に短時間で大量再実行される | リトライ回数、待機時間、失敗時停止条件を設定する |
たとえば、Microsoft Defender XDRのインシデント要約を自動化する場合、「すべてのインシデントを対象にする」のではなく、「重大度がHigh以上」「未割り当て」「直近1時間以内に作成」などの条件を設けると、SCU消費を抑えながら業務価値を維持できます。
また、Promptbookは便利ですが、複数のプロンプトを連続実行する性質があります。1回の実行単位では小さく見えても、複数ユーザーが頻繁に使うとSCU消費が大きくなることがあります。開発者は、プロンプトブックごとの想定実行回数、対象データ量、利用者数を見積もってから展開するべきです。
Microsoft 365 E5/E7利用組織が確認すべきこと
Microsoft 365 E5/E7の対象顧客には、Security Copilotの包含容量が用意されています。Microsoft Learnでは、Microsoft 365 E5/E7顧客に対して、1,000有償ユーザーライセンスごとに月400 SCU、最大月10,000 SCUが追加費用なしで提供されると説明されています。ライセンス数が1,000未満の場合もユーザー数に応じてスケールします。(Microsoft Learn)
ただし、これは「容量管理が不要になる」という意味ではありません。包含容量は月次でリセットされ、未使用分は繰り越されません。また、既定のSecurity Copilot Capacityはテナント全体で共有され、変更できない容量として説明されています。(Microsoft Learn)
E5/E7組織の確認ポイント
| 確認項目 | 内容 |
|---|---|
| テナントが有効化対象か | Microsoft 365管理センターの通知や各製品内バナーを確認する |
| 既定容量が作成されているか | Default Security Copilot Capacityの有無を確認する |
| 月次SCUの消費ペース | 月初・月中・月末の消費傾向を見る |
| 既存のプロビジョニング済み容量 | すでにSecurity Copilotを利用している場合、すぐ削除しない |
| データ共有設定 | Microsoft 365サービスデータへのアクセス設定を確認する |
| エージェント展開状況 | 自動有効化されるわけではないため、必要なエージェントを計画的に展開する |
既存のSecurity Copilot顧客で、すでにプロビジョニング済み容量を持っている場合、Microsoft Learnでは、Microsoft 365 E5/E7の包含対象になったからといって既存容量を削除しないことが推奨されています。(Microsoft Learn)
この点は移行時に重要です。包含容量が利用できるようになった直後に既存容量を削除すると、利用パターンや対象機能によっては想定外の制限に当たる可能性があります。まずは30日程度、既存容量と包含容量の利用状況を観察し、実際の消費量、ピーク時間帯、エージェント利用の有無を確認してから見直すのが現実的です。
削除・オフボード時の注意点
Security Copilotからオフボードするには、プロビジョニング済み容量の削除が必要です。Microsoft Learnでは、この操作には少なくともSecurity Administratorロールが必要とされています。また、容量と内部データの削除は恒久的な操作であり、元に戻せないと警告されています。(Microsoft Learn)
削除は、Owner settingsページまたはUsage monitoringページから行えます。具体的には、Security Copilotにサインインし、Owner settingsまたはUsage monitoringへ移動し、unitsセクションでChangeを選び、メニューからDelete the capacityを実行します。(Microsoft Learn)
削除前には、必ず次の点を確認してください。
| 削除前の確認 | 理由 |
|---|---|
| 使用量データのエクスポートが必要か | 削除後に内部データを戻せないため |
| SOC運用でSecurity Copilotを使っていないか | 現場の業務停止を防ぐため |
| 組み込み機能やLogic Appsが依存していないか | 自動化の失敗を防ぐため |
| Microsoft 365 E5/E7包含容量との関係を確認したか | 既存容量を誤って削除しないため |
| 関係者の承認を得たか | 復旧できない操作のため |
特に、ダッシュボードのエクスポートだけで十分か、追加のSecurity Copilotデータエクスポートが必要かを確認してください。Microsoft Learnでは、Security CopilotデータのエクスポートにはSecurity Copilotサポートへの連絡が必要とされています。(Microsoft Learn)
GA・パブリックプレビュー・プライベートプレビューの課金扱い
SCU消費を管理するうえで、機能のリリース段階も確認が必要です。Microsoft Learnでは、GA（一般提供）とPublic previewはSCU課金対象、Private previewは課金対象外と整理されています。(Microsoft Learn)
ここで注意したいのは、プレビューだから無料とは限らない点です。Public previewの機能を検証目的で大人数に展開すると、想定以上にSCUを消費する可能性があります。検証時は、対象ユーザー、期間、利用目的、最大実行回数を決めてから開始しましょう。
プレビュー機能を展開する前の判断基準
| 判断項目 | 推奨対応 |
|---|---|
| Public previewかPrivate previewか | Public previewはSCU消費対象として計画に入れる |
| 検証ユーザー数 | 最初は少人数に限定する |
| 検証期間 | 開始日と終了日を決める |
| 使用量レビュー | 24時間後、7日後、終了時に確認する |
| 本番展開条件 | SCU消費、業務効果、精度、運用負荷で判断する |
プレビュー機能は早期に価値を得られる一方で、運用管理が甘いと「誰が何を検証しているか分からない」状態になりがちです。SCU使用量ダッシュボードのCategoryやPlugin usedを使い、検証対象の利用を追跡できるようにしておくと安全です。
管理者が最初に実施すべき確認手順
Security CopilotのSCU使用量管理を始めるなら、次の順番で確認すると無駄がありません。
| 手順 | 作業 | 確認ポイント |
|---|---|---|
| 1 | Security CopilotポータルでUsage monitoringを開く | 最大90日分の使用量傾向を確認する |
| 2 | 直近24時間・7日・30日の消費量を見る | 急増日やピーク時間帯を特定する |
| 3 | Users、Category、Typeで絞り込む | 手動利用か自動処理かを切り分ける |
| 4 | Plugin usedとCopilot experienceを見る | どの製品・機能から消費しているか確認する |
| 5 | Excelにエクスポートする | 月次レビューや部門別分析に使う |
| 6 | 容量上限時の連絡先を決める | Azure容量所有者・共同作成者への連絡ルートを明確にする |
| 7 | プロビジョニング済みSCUと超過SCUを見直す | 定常利用とピーク対策を分けて判断する |
| 8 | 自動化・エージェントの実行条件を確認する | 不要な定期実行や過剰リトライを減らす |
最初から完璧な容量設計を目指す必要はありません。まずは30日間の実績を取り、どの利用パターンがSCUを消費しているかを可視化します。そのうえで、定常利用に必要なプロビジョニング済みSCUと、ピーク対応用の超過SCUを分けて設計すると、コストと可用性のバランスを取りやすくなります。
よくある失敗と回避策
使用量が増えた原因を「ユーザーの使いすぎ」と決めつける
SCU消費は、手動プロンプトだけでなく、Promptbook、Agent、Logic Apps、組み込み機能からも発生します。特定ユーザーの利用が多く見えても、実際にはそのユーザーが所有する自動化処理が定期実行されている場合があります。
回避策は、UsersだけでなくTypeとCategoryを必ず組み合わせて見ることです。Manual Actionが多いのか、Automated Actionが多いのかを切り分けるだけで、対応策は大きく変わります。
超過容量を無制限にして放置する
超過容量は業務停止を避けるうえで有効ですが、上限管理なしで使うと予算管理が難しくなります。特に自動化処理やエージェントを展開している環境では、想定外の消費が発生する可能性があります。
回避策は、最初は上限付きで運用し、月次レビューで必要に応じて見直すことです。重要インシデント対応を優先する組織では、緊急時のみ上限を引き上げる承認フローを作ると現実的です。
容量変更の権限者が限定されすぎている
SCU上限に到達したとき、容量を変更できる担当者が不在だと、アナリストがSecurity Copilotを使えない時間が発生します。
回避策は、Azure capacity ownerまたはcontributor、Security Copilot ownerの役割を整理し、平日・夜間・休日の連絡先を決めておくことです。最小権限の原則は守りつつ、緊急時に誰も変更できない状態は避けるべきです。
既存容量をすぐ削除してしまう
Microsoft 365 E5/E7の包含容量が利用できるようになった組織で、既存のプロビジョニング済み容量をすぐ削除するのは危険です。Microsoft Learnでは、既存のSecurity Copilot顧客に対して、以前にプロビジョニングした容量を削除しないことが推奨されています。(Microsoft Learn)
回避策は、包含容量が有効になった後も一定期間は実績を確認し、ピーク時の消費、エージェント利用、組み込み機能の利用状況を見てから容量設計を見直すことです。
実務での運用ルール例
Security CopilotのSCU管理は、ダッシュボードを見られるだけでは不十分です。次のような運用ルールを決めておくと、管理が属人化しにくくなります。
| 項目 | ルール例 |
|---|---|
| 日次確認 | SOCリーダーが前日のSCU消費と上限接近通知の有無を確認 |
| 週次確認 | Security Copilot所有者がユーザー別・カテゴリ別・プラグイン別にレビュー |
| 月次確認 | Azure容量所有者、財務担当、SOC管理者で容量と費用を見直し |
| 自動化の新規展開 | Logic Appsやエージェントは本番展開前にSCU影響をレビュー |
| 緊急時対応 | 上限接近時は低優先度の自動処理を停止し、重要インシデント対応を優先 |
| 変更管理 | SCU増減、超過上限変更、容量削除はチケットに記録 |
| 削除判断 | 容量削除前にデータエクスポート、依存機能、承認を確認 |
このルールは大企業だけでなく、中小規模の組織でも有効です。利用者が少ない段階ほど、「誰でも自由に使えるが、誰も管理していない」状態になりやすいためです。
まず確認すべき次のアクション
Security CopilotのSCU使用量管理で、管理者が今すぐ行うべきことは明確です。まずUsage monitoringを開き、直近30日間のSCU消費を確認します。次に、Users、Category、Type、Plugins usedで内訳を見ます。そのうえで、プロビジョニング済みSCUと超過SCUの設定、容量変更権限、上限到達時の連絡フロー、自動化処理の実行条件を確認してください。
特に、Microsoft Defender XDRなどの組み込み機能、Logic Apps、エージェントを使っている組織では、プロンプト利用だけを見ても実態は分かりません。SCUは、Security Copilotの利用拡大に合わせて自然に増える運用コストです。だからこそ、ダッシュボードで可視化し、Excelで分析し、容量と自動化設計を定期的に見直すことが重要です。
Security Copilotを安定して使うための第一歩は、SCUを「請求単位」ではなく「セキュリティ運用のキャパシティ」として扱うことです。今日の確認作業として、Usage monitoringを開き、過去30日間で最もSCUを消費した日、ユーザー、カテゴリ、プラグインを特定するところから始めましょう。
コメント