Microsoft DefenderポータルでMicrosoft Sentinelを運用している管理者がまず押さえるべき結論は、「Deploy custom content from your repository」は、カスタム検出ルールやプレイブックなどをGitHubまたはAzure DevOpsのリポジトリで管理し、Microsoft Sentinelワークスペースへ自動展開するためのContent as Code機能だという点です。2026年5月更新では、従来のプレビュー前提だった記述が整理され、Defenderポータル移行を見据えたCI/CD運用として確認すべき重要度が高まっています。リポジトリを正しく設計しないと、ポータル上の手作業変更が上書きされたり、削除したつもりのコンテンツがワークスペースに残ったりするため、導入前に権限・ブランチ・展開対象・移行時期を明確にしておくことが重要です。(Microsoft Learn)
2026年5月更新で押さえるべきポイント
今回の公式情報は、Microsoft DefenderポータルでMicrosoft Sentinelを扱う組織にとって、単なる手順書ではありません。GitHubやAzure DevOpsを使って、分析ルール、オートメーションルール、ハンティングクエリ、パーサー、プレイブック、ワークブックをコードとして管理する運用方針を示す内容です。対象は「Microsoft Sentinel in the Microsoft Defender portal」と「Microsoft Sentinel in the Azure portal」の両方ですが、AzureポータルでのMicrosoft Sentinelサポート終了予定を考えると、今後はDefenderポータル側での確認が中心になります。(Microsoft Learn)
特に注目すべき変更は、GitHub上の公式ドキュメント履歴で「Preview」表記が外され、関連するCI/CDドキュメントも更新された点です。コミット履歴では、2026年5月11日に「Update Sentinel CI-CD docs for GA and preview skills」という更新が行われ、Deploy custom content from your repository (Preview) から Deploy custom content from your repository へ変更されています。日本時間で2026年5月12日前後に更新情報として確認する場合も、実務上は「プレビュー扱いの注意書きが外れた機能」として読み解くのが自然です。(GitHub)
ただし、「プレビュー表記が消えた＝すべての組織で無条件に本番適用してよい」という意味ではありません。リポジトリ接続、展開パイプライン、権限、Bicep対応、APIバージョン、Defenderポータル移行の影響を確認したうえで、段階的に本番ワークスペースへ適用するのが安全です。
「Deploy custom content from your repository」でできること
この機能を使うと、Microsoft Sentinelのカスタムコンテンツを外部リポジトリに置き、リポジトリへの変更をワークスペースへ自動展開できます。つまり、セキュリティ運用でよく起こる「誰が、いつ、どの検出ルールを変えたのか分からない」という問題を、Gitの履歴とCI/CDで管理しやすくなります。(Microsoft Learn)
対応する主なコンテンツは次のとおりです。
| 展開できるコンテンツ | 実務での使いどころ |
|---|---|
| Analytics rules | 不審なサインイン、マルウェア検知、権限昇格などの検出ルールを標準化する |
| Automation rules | インシデント作成後の分類、タグ付け、通知などを自動化する |
| Hunting queries | SOCチームが使う調査用KQLを共有・更新する |
| Parsers | ログ形式を整え、複数ワークスペースで再利用する |
| Playbooks | Logic Appsベースの対応フローをコードとして展開する |
| Workbooks | 可視化ダッシュボードを複数環境へ展開する |
この機能の本質は、リポジトリを「正」として扱うことです。公式ドキュメントでも、接続されたリポジトリ内の更新はMicrosoft Sentinelワークスペースへ同期され、ポータル上で行った変更を上書きする可能性があると説明されています。運用ルールとしては、検出ルールやプレイブックを変更する担当者をGitHubまたはAzure DevOps側に寄せ、Microsoft Sentinelポータルでの直接編集は例外扱いにするべきです。(Microsoft Learn)
影響範囲はMicrosoft Defenderポータル上のSentinel運用
この更新は、Microsoft Defender全体のすべての機能に直接影響するものではありません。影響の中心は、Microsoft DefenderポータルでMicrosoft Sentinelを使い、カスタムコンテンツをリポジトリから展開する管理者・SOCエンジニア・検出ルール開発者です。
特に影響を受けやすいのは、次のような組織です。
| 対象 | 確認すべき理由 |
|---|---|
| 複数のMicrosoft Sentinelワークスペースを運用している組織 | ルールやワークブックを手作業で複製していると差分管理が難しくなる |
| GitHubまたはAzure DevOpsで検出ルールを管理したいSOC | Pull Request、レビュー、履歴管理を検出ルール運用に組み込める |
| Azureポータル中心でSentinelを使っている管理者 | 2027年3月31日以降、SentinelはAzureポータルでサポートされず、Defenderポータルのみで利用される予定 |
| BicepまたはARMテンプレートでSentinelコンテンツを管理している開発者 | 接続作成日やテンプレート構造によって展開時の注意点がある |
| APIでリポジトリ接続を作成・管理しているチーム | 2026年6月以降、古いAPIバージョンのサポート終了が案内されている |
Microsoftは、2027年3月31日以降、Microsoft SentinelはAzureポータルではサポートされず、Microsoft Defenderポータルのみで利用されると案内しています。また、2025年7月以降、多くの新規顧客はDefenderポータルへ自動的にオンボードおよびリダイレクトされるとされています。したがって、リポジトリ展開を始めるなら、Azureポータル前提ではなく、Defenderポータルでの操作場所や権限設計を前提にしたほうが現実的です。(Microsoft Learn)
管理者が最初に確認すべき前提条件
リポジトリ接続を作成するには、Microsoft Sentinelワークスペースを含むリソースグループでOwnerロールが必要です。また、接続に使うアカウントはホームテナントのアカウントである必要があり、B2Bゲストアカウントや委任アクセスはサポートされていません。外部ベンダーやMSSPに設定作業を依頼している場合、この条件でつまずきやすいため、作業アカウントを事前に確認してください。(Microsoft Learn)
GitHubを使う場合は、リポジトリへのCollaboratorアクセスとGitHub Actionsの有効化が必要です。Azure DevOpsを使う場合は、対象リポジトリへのProject Administratorアクセス、Pipelinesの有効化、OAuthによるサードパーティアプリケーションアクセス、さらにMicrosoft Sentinelワークスペースと同じテナント内のAzure DevOps接続が必要です。(Microsoft Learn)
| 確認項目 | GitHub | Azure DevOps |
|---|---|---|
| リポジトリ連携の対応 | 対応 | 対応 |
| 必要なリポジトリ権限 | Collaborator | Project Administrator |
| CI/CD機能 | GitHub Actions | Azure Pipelines |
| OAuth/アプリ連携 | Azure-Sentinelアプリのインストールが必要 | サードパーティアプリケーションアクセスの有効化が必要 |
| テナント条件 | ホームテナントのアカウントが必要 | ワークスペースと同じテナントの接続が必要 |
実務では、最初から本番用ブランチを接続するのではなく、検証用ワークスペースと検証用ブランチで接続を作成し、展開ログ・上書き動作・削除動作を確認してから本番へ広げるのがおすすめです。
リポジトリ接続の基本手順
Defenderポータルで操作する場合は、Microsoft Sentinel > Content management > Repositories からリポジトリ接続を作成します。Azureポータルを使う場合は、Microsoft Sentinelの Content management > Repositories から操作しますが、今後の移行を考えるとDefenderポータル側の導線に慣れておくべきです。(Microsoft Learn)
接続作成の流れは、おおむね次のとおりです。
| 手順 | 作業内容 | 失敗しやすいポイント |
|---|---|---|
| 1 | GitHubまたはAzure DevOpsに正しいアカウントでサインインする | ブラウザに別アカウントの認証情報が残っている |
| 2 | Repositories画面で新しい接続を追加する | 接続名が曖昧で、後から環境やブランチを判別できない |
| 3 | Source ControlでGitHubまたはAzure DevOpsを選ぶ | 組織のポリシーでOAuthやActions/Pipelinesが無効になっている |
| 4 | リポジトリ、ブランチ、Content Typesを選択する | 展開対象の種類を誤り、必要なコンテンツが展開されない |
| 5 | 接続を作成し、生成されたworkflowまたはpipelineを確認する | 作成後の展開ログを確認せず、エラーに気付かない |
同一のMicrosoft Sentinelワークスペース内では、同じリポジトリと同じブランチの重複接続は作成できません。複数環境に分ける場合は、ブランチ戦略、フォルダー構成、ワークスペースごとの接続名をあらかじめ決めておくと運用が安定します。(Microsoft Learn)
Content Types選択で注意すべきこと
接続作成時には、展開するContent Typesを選びます。ここで注意したいのは、パーサーとハンティングクエリの扱いです。公式情報では、パーサーとハンティングクエリはいずれもSaved Searches APIを使うため、片方を選んだ場合でもブランチ内にもう一方のコンテンツがあると両方が展開されると説明されています。一方、それ以外のコンテンツタイプは、選択した種類のみが展開されます。(Microsoft Learn)
たとえば、ハンティングクエリだけを展開するつもりでリポジトリにパーサーも入れていると、想定以上の変更がワークスペースに反映される可能性があります。検出ルール、パーサー、ワークブックを同じブランチに置く場合は、フォルダー構成と展開対象を明確にし、初回展開前に「何がデプロイされるか」をレビューしてください。
Smart deploymentsは基本的に有効のまま使う
リポジトリ接続を作成すると、GitHubではworkflow、Azure DevOpsではpipelineが生成されます。既定のworkflowは、前回の展開以降に変更されたコンテンツのみを展開します。これはSmart deploymentsと呼ばれる仕組みで、新しい接続では既定で有効です。変更されていない分析ルールまで毎回再展開しないため、展開時間の短縮や不要な設定リセットの抑制に役立ちます。(Microsoft Learn)
ただし、全コンテンツを毎回再展開したいケースもあります。たとえば、検証環境を本番相当にリセットしたい場合や、パラメータファイルの参照関係を大きく変えた場合です。その場合はworkflowまたはpipeline内のsmartDeploymentをfalseに変更できます。ただし、変更後は関連コンテンツが再展開されるため、本番環境では差分と影響範囲を事前に確認してください。(Microsoft Learn)
BicepとARMテンプレートの確認ポイント
Microsoft Sentinel repositoriesでは、BicepファイルまたはAzure Resource Managerテンプレートとして保存したコンテンツを展開できます。公式ドキュメントではBicepの利用が推奨されていますが、Bicepを使う場合は接続の作成時期に注意が必要です。2024年11月1日より前に作成されたリポジトリ接続でBicepファイルを使うには、接続を削除して再作成する必要があります。(Microsoft Learn)
また、ARM JSONをBicepに変換する場合、Bicepファイルはidプロパティをサポートしません。Microsoft Sentinelからエクスポートした分析ルールテンプレートにidが含まれている場合は、変換後に削除する必要があります。加えて、クロスワークスペースクエリを使う分析ルールは、リポジトリ接続先のワークスペースと宛先ワークスペースが同じリソースグループにある場合のみ利用できるとされています。(Microsoft Learn)
| 確認項目 | 判断基準 |
|---|---|
| 既存接続の作成日 | 2024年11月1日より前なら、Bicep利用時に再作成を検討する |
| テンプレート形式 | 新規作成はBicep、既存資産はARMテンプレートから段階的に移行する |
idプロパティ | Bicep化した分析ルールに残っていないか確認する |
| クロスワークスペースクエリ | 宛先ワークスペースが同じリソースグループか確認する |
| パラメータ管理 | ワークスペースごとの差分はパラメータファイルで分離する |
編集・削除・接続解除で起こりやすいトラブル
リポジトリ接続後に最も起こりやすい失敗は、Microsoft Sentinelポータル上で直接編集してしまうことです。公式ドキュメントでは、接続されたリポジトリに保存されているコンテンツはリポジトリ側で編集することが推奨されています。ポータルで編集した場合、次回のリポジトリ展開で変更が上書きされる可能性があるため、どうしてもポータルで修正した場合は、リポジトリへエクスポートして差分を取り込む必要があります。(Microsoft Learn)
削除時にも注意が必要です。リポジトリからコンテンツを削除しても、Microsoft Sentinelワークスペース内のコンテンツは自動的には削除されません。不要な分析ルールやワークブックを完全に消すには、リポジトリとMicrosoft Sentinelワークスペースの両方で削除する必要があります。リポジトリ由来のコンテンツを見つけやすくするには、Source nameなどでフィルターできる運用にしておくと便利です。(Microsoft Learn)
接続解除後も、過去に展開されたコンテンツはMicrosoft Sentinelワークスペースに残ります。一方、接続解除後にリポジトリへ追加されたコンテンツは展開されません。GitHub側のAzure-Sentinelアプリを削除する場合は、先にMicrosoft SentinelのRepositories画面で関連接続を削除し、workflowが残っていないか確認してください。(Microsoft Learn)
Defenderポータル移行と合わせて確認したいこと
Microsoft SentinelをMicrosoft Defenderポータルへ移行しても、既存のデータ収集アーキテクチャやLog Analyticsの基本的な取り込みパイプライン、データスキーマは維持されると説明されています。ただし、Defenderポータルでは一部のコネクタ表示やインシデント相関、アラートの扱いが変わるため、リポジトリ展開だけを確認して終わりにしないことが重要です。(Microsoft Learn)
たとえば、DefenderポータルではMicrosoft SentinelのWorkspace Managerが利用できないため、複数ワークスペースへの構成配布には、リポジトリからのContent as Code展開やマルチテナントポータルの利用が代替策として案内されています。複数テナント・複数ワークスペースを管理している企業やMSSPでは、この点を移行計画に含めるべきです。(Microsoft Learn)
また、分析ルールはDefenderポータルでも作成・更新・管理できますが、インシデント相関やアラートグルーピングはDefender XDR側のエンジンが関与します。インシデント名を条件にした自動化ルールや、インシデント作成をオフにした「アラートのみ」のルールを使っている場合は、移行後の表示や自動化の挙動を検証しておく必要があります。(Microsoft Learn)
APIと上限値も見落とさない
Microsoft Sentinel repositoriesには、ワークスペースあたり最大5つのリポジトリ接続という制限があります。また、Azureリソースグループのデプロイ履歴は800件に制限されており、テンプレート展開が多い環境ではDeployment QuotaExceededエラーが発生する可能性があります。検出ルールを頻繁に更新するチームでは、展開頻度とリソースグループの設計も確認しておきましょう。(Microsoft Learn)
APIでリポジトリ接続を作成・管理している場合は、さらに注意が必要です。公式ドキュメントでは、2026年6月以降、Microsoft Sentinel repositoriesで使われる古いAPIバージョンはサポートされなくなると案内されており、サービス中断を避けるため、2026年6月15日までに2025-09-01、2025-06-01、または2025-07-01-previewへ移行するよう記載されています。既存のリポジトリ接続自体は影響を受けないとされていますが、APIベースの自動化を組んでいる場合は早めに棚卸ししてください。(Microsoft Learn)
本番展開前のチェックリスト
リポジトリ接続を本番ワークスペースへ適用する前に、次の項目を確認してください。
| チェック項目 | 確認内容 |
|---|---|
| 権限 | 作業者がリソースグループOwnerを持ち、ホームテナントのアカウントで作業しているか |
| リポジトリ | GitHubまたはAzure DevOpsのどちらを使うか、組織ポリシーでActions/Pipelinesが許可されているか |
| ブランチ戦略 | 本番、検証、開発のブランチまたはフォルダーを分けているか |
| Content Types | パーサーとハンティングクエリの同時展開リスクを把握しているか |
| 変更管理 | ポータル直接編集を禁止または例外管理しているか |
| 削除運用 | リポジトリ削除とワークスペース削除を別作業として扱っているか |
| Bicep対応 | 古い接続の再作成、idプロパティ削除、パラメータ管理を確認したか |
| 展開ログ | GitHub ActionsまたはAzure Pipelinesでエラーを確認できる体制があるか |
| Defender移行 | 2027年3月31日以降のAzureポータル非サポートを前提にした運用へ移しているか |
| API | 古いAPIバージョンを使った自動化が残っていないか |
小規模なSOCであれば、まず分析ルールだけを検証用ワークスペースに展開し、問題がなければハンティングクエリ、ワークブック、プレイブックへ対象を広げると安全です。大規模環境では、リポジトリ構成を「共通コンテンツ」「環境別パラメータ」「テナント別差分」に分け、Pull RequestレビューでKQL、アラート件数、運用影響を確認する流れを作ると管理しやすくなります。
まず取るべき対応
Microsoft DefenderポータルでMicrosoft Sentinelを使っている組織は、最初に「現在どのコンテンツを手作業で管理しているか」を棚卸ししてください。分析ルール、ハンティングクエリ、パーサー、プレイブック、ワークブックが担当者ごとに個別管理されている場合、リポジトリ展開へ移行する価値があります。
次に、検証用のMicrosoft SentinelワークスペースとGitHubまたはAzure DevOpsリポジトリを用意し、1つのブランチから少数のコンテンツを展開します。展開ログ、上書き動作、削除時の残存、Smart deploymentsの動作を確認したうえで、本番ワークスペースへ展開範囲を広げるのが現実的です。
今回の「Deploy custom content from your repository」は、Microsoft Sentinelのカスタムコンテンツを単に自動展開する機能ではなく、Defenderポータル時代のセキュリティ運用をコード化するための土台です。AzureポータルからDefenderポータルへの移行期限、Bicep対応、APIバージョン、リポジトリを唯一の正とする運用ルールを合わせて整備すれば、検出ルールの品質管理と複数環境への展開を大きく改善できます。
コメント