Microsoft Sentinel の「Deploy custom content from your repository (Preview)」で最初に押さえるべき結論は、分析ルールやハンティングクエリなどのカスタムコンテンツを、ポータル上で個別編集するのではなく、GitHub または Azure DevOps のリポジトリを起点に管理・展開できるようにする機能だという点です。
2026年4月22日に更新された Microsoft 公式ドキュメントでは、この機能が Microsoft Sentinel の Azure portal と Microsoft Defender portal の両方に適用される一方、Microsoft Sentinel Repositories は引き続きプレビュー機能として扱われています。あわせて、Azure portal での Microsoft Sentinel サポートは 2027年3月31日以降終了し、Microsoft Defender portal へ移行する方針も明記されています。(Microsoft Learn)
つまり今回の更新ポイントは、単なる「リポジトリ連携手順」ではありません。セキュリティ管理者、ID管理チーム、コンプライアンス担当者が、Sentinel の検知ロジックや自動化ルールを Content as Code / Detections as Code として扱うための運用設計を見直すタイミングです。
Microsoft Sentinelの最新動向: Deploy custom content from your repository (Preview)で何が変わったか
Microsoft Sentinel の「Deploy custom content from your repository」は、Microsoft Sentinel ワークスペースと外部ソース管理リポジトリを接続し、リポジトリ内のカスタムコンテンツをワークスペースへ自動展開する仕組みです。Microsoft 公式ドキュメントでは、GitHub または Azure DevOps のリポジトリと Microsoft Sentinel を接続し、Sentinel 外で更新したコンテンツをワークスペースへ自動展開できると説明されています。(Microsoft Learn)
2026年4月版として実務上注目したいのは、次の3点です。
| 観点 | 2026年4月時点で押さえるポイント | 実務での判断基準 |
|---|---|---|
| 管理方式 | Sentinel ポータルで直接編集する運用から、リポジトリを正とする運用へ寄せる | 変更履歴・レビュー・承認が必要な検知ルールはリポジトリ管理に向く |
| 接続先 | 対応する外部リポジトリは GitHub と Azure DevOps | 既存の DevSecOps 基盤に合わせて選ぶ |
| ポータル戦略 | Azure portal から Microsoft Defender portal への移行計画が必要 | 2027年3月31日までに運用手順書・教育・権限設計を見直す |
特にグローバル展開している組織では、地域別・事業部別・規制別に Microsoft Sentinel ワークスペースを分けているケースがあります。その場合、各ワークスペースで個別にルールを編集すると、検知品質や監査証跡にばらつきが出やすくなります。リポジトリ連携を使えば、変更の起点を GitHub または Azure DevOps に集約し、レビュー済みのカスタムコンテンツだけを展開する設計に近づけます。
この機能でできること
Microsoft Sentinel Repositories では、外部リポジトリから複数種類のカスタムコンテンツを展開できます。Microsoft 公式ドキュメントでは、Analytics rules、Automation rules、Hunting queries、Parsers、Playbooks、Workbooks が対象として挙げられています。(Microsoft Learn)
| コンテンツ種別 | 主な活用シーン | 注意点 |
|---|---|---|
| Analytics rules | 検知ルールをコードとして管理し、Pull Request でレビューする | 本番投入前に KQL、しきい値、抑制条件を検証する |
| Automation rules | インシデントの自動分類、割り当て、抑制を標準化する | 誤った自動化は調査漏れにつながるため、段階的に展開する |
| Hunting queries | 脅威ハンティング用クエリをチームで共有する | クエリの目的、対象ログ、想定結果をコメントやREADMEに残す |
| Parsers | ASIM などの正規化やログ解釈を共通化する | Parser 変更は複数ルールに影響しやすいため影響範囲を確認する |
| Playbooks | Logic Apps ベースの対応処理を展開する | 接続情報、マネージドID、権限、環境差分を考慮する |
| Workbooks | 監視ダッシュボードやレポートを標準化する | 地域名、ワークスペースID、データ保持条件などをパラメータ化する |
リポジトリ接続を作成すると、新しい GitHub workflow または Azure DevOps pipeline が生成され、リポジトリに保存されたコンテンツが Microsoft Sentinel ワークスペースへ展開されます。展開状況は GitHub Actions または Azure DevOps Pipelines のログで確認できます。(Microsoft Learn)
従来の手動管理とリポジトリ管理の違い
Microsoft Sentinel のカスタムコンテンツは、ポータルから直接作成・編集することもできます。しかし、複数人・複数ワークスペース・監査要件ありの環境では、手動管理だけでは限界が出ます。
| 比較項目 | ポータルで直接編集 | リポジトリから展開 |
|---|---|---|
| 変更履歴 | ポータル上の履歴や個別メモに依存しやすい | Git のコミット履歴で追跡しやすい |
| レビュー | 口頭確認やチケット運用になりやすい | Pull Request / Merge Request でレビューできる |
| 複数ワークスペース展開 | 手作業が増え、差分が発生しやすい | 同じテンプレートを複数環境へ展開しやすい |
| 緊急修正 | すぐ変更できるが統制が弱い | ブランチ戦略次第で統制とスピードを両立できる |
| 監査対応 | 「誰が、何を、なぜ変えたか」を補足資料で説明しがち | コミット、PR、承認、展開ログを証跡にしやすい |
| 失敗時の切り戻し | 手作業で戻す必要がある | 過去コミットへの戻しや再展開を検討しやすい |
重要なのは、リポジトリ管理にすると「ポータルで編集できなくなる」わけではない点です。ただし、Microsoft は接続済みリポジトリに保存されたコンテンツについて、基本的にリポジトリ側で編集することを推奨しています。Sentinel ポータル側で編集した場合、次回のリポジトリ展開で上書きされる可能性があるためです。(Microsoft Learn)
導入前に確認すべき前提条件
Microsoft Sentinel のリポジトリ展開は便利ですが、権限と接続条件を満たしていないと途中で詰まります。導入前に、セキュリティ管理者だけでなく、ID管理チーム、DevOps 管理者、クラウド基盤チームを巻き込んで確認しておきましょう。
| 確認項目 | 必要な条件 | つまずきやすいポイント |
|---|---|---|
| Sentinel 側の権限 | Microsoft Sentinel ワークスペースを含むリソースグループの Owner ロール | Sentinel Contributor だけでは接続作成に不足する場合がある |
| GitHub | リポジトリへの Collaborator アクセス、GitHub Actions の有効化 | 個人アカウントで接続すると退職・異動時に運用リスクが出る |
| Azure DevOps | Project Administrator アクセス、Pipelines の有効化 | Azure DevOps 接続は Sentinel ワークスペースと同じテナントである必要がある |
| ID条件 | 接続作成に使うアカウントはホームテナントであること | B2B ゲストや委任アクセスはサポート対象外 |
| コンテンツ形式 | 展開対象ファイルがサポート形式であること | Bicep / ARM テンプレートの構造不備で展開に失敗する |
Microsoft 公式ドキュメントでは、GitHub と Azure DevOps の接続条件、Actions / Pipelines の有効化、ホームテナントのアカウント利用、B2B ゲストや委任アクセスがサポートされないことが前提条件として示されています。(Microsoft Learn)
また、Microsoft Sentinel Repositories は、各 Microsoft Sentinel ワークスペースにつき最大5つのリポジトリ接続に制限されています。Azure リソースグループのデプロイ履歴にも上限があるため、大量のテンプレート展開を行う環境では設計段階で接続数と展開頻度を見積もる必要があります。(Microsoft Learn)
実装の基本手順
導入時は、いきなり本番ワークスペースへ接続するより、検証用ワークスペースで一連の流れを確認してから展開範囲を広げるのが安全です。
リポジトリ構成を先に決める
最初に決めるべきなのは、ファイルをどこに置くかです。おすすめは、コンテンツ種別ごとにフォルダーを分け、README で用途や展開先を明記する構成です。
例として、次のような構成にすると運用しやすくなります。
sentinel-content/
analytics-rules/
automation-rules/
hunting-queries/
parsers/
playbooks/
workbooks/
parameters/
docs/検知ルールだけを先にリポジトリ管理したい場合は、analytics-rules/ から始めると影響範囲を限定できます。Playbooks や Workbooks は環境差分が出やすいため、後から段階的に追加する方が失敗しにくいです。
Microsoft Sentinelからリポジトリ接続を作成する
Microsoft Sentinel の Repositories 画面から接続を作成し、ソース管理先として GitHub または Azure DevOps を選びます。接続時には、リポジトリ、ブランチ、展開する Content Types を選択します。Microsoft 公式手順では、Microsoft Defender portal では「Microsoft Sentinel > Content management > Repositories」から操作する流れが示されています。(Microsoft Learn)
本番運用では、接続先ブランチを main や production に限定し、直接 push を禁止する設計が有効です。検知ルールの変更は Pull Request を必須にし、最低1名以上のセキュリティレビューを通してからマージする形にすると、誤検知や過検知の増加を抑えやすくなります。
展開ログを確認する
接続作成後は、GitHub Actions または Azure DevOps Pipelines に生成された workflow / pipeline を確認します。GitHub では Actions タブの .yaml ファイル、Azure DevOps では Pipelines タブから展開ログやエラーメッセージを確認できます。(Microsoft Learn)
初回展開で確認すべきポイントは次のとおりです。
- 想定した Content Types だけが展開されているか
- 本番ワークスペースではなく検証先に展開されているか
- Analytics rules が有効化されるタイミングに問題がないか
- Playbooks の接続・権限・パラメータが環境に合っているか
- エラー時に誰が確認するかが決まっているか
Smart deploymentsを理解しておく
Microsoft Sentinel Repositories では、Smart deployments が新しい接続で既定有効になっています。これは、接続済みリポジトリ内の変更を追跡し、前回以降に変更されていないコンテンツの再展開を避ける仕組みです。Microsoft 公式ドキュメントでは、展開性能の改善に加え、分析ルールの動的スケジュールがリセットされるような未変更コンテンツへの影響を避ける効果も説明されています。(Microsoft Learn)
実務では、Smart deployments を安易に無効化しない方がよいでしょう。すべてのコンテンツを毎回再展開すると、展開時間が伸びるだけでなく、意図しない設定リセットの確認範囲も広がります。
一方で、全件再展開が必要な場面もあります。たとえば、共通パラメータの設計を大きく変えた場合や、リポジトリ構造を整理した直後です。その場合は、GitHub workflow の smartDeployment、または Azure DevOps pipeline の ScriptArguments で設定を変更できます。Microsoft 公式ドキュメントでは、smartDeployment を true から false に変更すると、以後の展開で関連コンテンツを再展開する動作になると説明されています。(Microsoft Learn)
複数ワークスペース運用ではパラメータ設計が重要
グローバル企業や MSSP では、同じ検知ロジックを複数の Microsoft Sentinel ワークスペースへ展開しつつ、ワークスペースID、リージョン、通知先、Playbook 接続情報などは環境ごとに変えたいケースがあります。
この場合、Bicep や ARM テンプレートに値を直書きするのではなく、パラメータファイルを使う設計が向いています。Microsoft 公式ドキュメントでは、Bicep パラメータファイルや JSON パラメータファイルを使い、対象コンテンツファイルにマッピングする方法が説明されています。(Microsoft Learn)
特に重要なのは、sentinel-deployment.config の活用です。この設定ファイルでは、優先的に展開するコンテンツ、展開対象から除外するコンテンツ、パラメータファイルのマッピングを管理できます。大規模環境では、次のような使い方が現実的です。
| やりたいこと | 使う設定 | 実務例 |
|---|---|---|
| 重要な検知ルールを先に展開したい | prioritizedcontentfiles | 重大インシデント対応用の Analytics rule を優先展開 |
| 検証中のルールを本番に出したくない | excludecontentfiles | PoC 用クエリや未承認 Playbook を除外 |
| ワークスペースごとに値を変えたい | parameterfilemappings | 日本、米国、欧州のワークスペースで通知先やIDを切り替える |
パス指定では、Windows のようなバックスラッシュではなく、スラッシュを使う必要があります。小さな点ですが、CI/CD の失敗原因になりやすいので、リポジトリ内の命名規則として明文化しておくと安全です。(Microsoft Learn)
失敗しやすいポイントと回避策
リポジトリ展開は強力ですが、導入直後に起こりやすいトラブルがあります。特に本番環境では、次の点を事前に確認してください。
| 失敗しやすいポイント | 起きること | 回避策 |
|---|---|---|
| Sentinel ポータルで直接編集する | 次回のリポジトリ展開で変更が上書きされる | 変更は原則リポジトリで行う。緊急編集時は必ずリポジトリへ反映する |
| リポジトリからファイルを削除するだけで済ませる | Sentinel ワークスペース側のコンテンツは削除されない | リポジトリと Sentinel の両方から削除する |
| 同じリポジトリ・同じブランチを重複接続しようとする | 同一ワークスペース内では重複接続を作成できない | 接続一覧とブランチ設計を事前に棚卸しする |
| Parsers と Hunting queries の関係を理解していない | 選択した Content Type 以外も展開されるように見える場合がある | Saved Searches API を使うコンテンツの扱いを確認する |
| 古い接続のまま Bicep を使う | Bicep 展開で想定外の問題が起きる可能性がある | 2024年11月1日より前に作成した接続は再作成を検討する |
| API管理のバージョン移行を後回しにする | 2026年6月以降にサービス影響が出る可能性がある | 2026年6月15日までに対象 API バージョンへ移行する |
リポジトリからコンテンツを削除しても、Microsoft Sentinel ワークスペース内のコンテンツは自動削除されません。リポジトリ接続を削除した場合も、過去に展開されたコンテンツはワークスペースに残ります。削除作業では、リポジトリ側と Sentinel 側の両方を確認する必要があります。(Microsoft Learn)
また、2024年11月1日より前に作成されたリポジトリ接続で Bicep ファイルを使う場合、接続の削除と再作成が必要とされています。Bicep では id プロパティをサポートしない点も注意が必要です。(Microsoft Learn)
security admins、identity teams、compliance teamsが見るべき観点
この更新は、SOC やクラウド管理者だけの話ではありません。Microsoft Sentinel の検知・調査・自動化を組織全体で統制するため、関係チームごとに見るべきポイントが異なります。
security adminsが見るべきポイント
セキュリティ管理者は、Analytics rules と Automation rules の変更管理を優先して整備しましょう。検知ロジックは、ほんの小さな KQL 条件の変更でも、アラート量や検知漏れに直結します。
実務では、次のルールを決めておくと安定します。
- 本番用ブランチへの直接 push を禁止する
- Analytics rule の変更は Pull Request レビュー必須にする
- 変更理由、想定されるアラート量、ロールバック手順を PR に記載する
- 新規ルールは検証ワークスペースで一定期間観察してから本番化する
- 無効化・削除もレビュー対象にする
特にアラート疲れを防ぐには、「有効なルールを増やす」だけでは不十分です。検知ルールごとに、誰が一次対応するのか、どのログを確認するのか、どの条件ならクローズできるのかまでセットで管理する必要があります。
identity teamsが見るべきポイント
ID管理チームは、Entra ID 関連のサインインログ、特権操作、条件付きアクセスに関する検知ロジックが、組織のID運用ルールと矛盾していないかを確認する役割を担います。
たとえば、海外からのサインイン検知を強化する場合、グローバル拠点や出張者、VPN、業務委託先のアクセス実態を知らないままルールを本番化すると、誤検知が急増します。リポジトリ管理にすれば、セキュリティチームだけでなく ID管理チームも Pull Request のレビューに参加しやすくなります。
compliance teamsが見るべきポイント
コンプライアンス担当者にとっての価値は、変更証跡を残しやすいことです。誰が、いつ、どの検知ルールや自動化を変更し、誰が承認したのかを、Git の履歴や CI/CD ログと組み合わせて確認できます。
ただし、リポジトリ管理を導入しただけで監査要件を満たせるわけではありません。証跡として使うには、ブランチ保護、レビュー必須化、権限分離、ログ保持、チケットとの紐付けを運用ルールとして定める必要があります。
Azure portalからDefender portalへの移行も同時に進める
Microsoft Sentinel の運用では、リポジトリ展開だけでなくポータル移行も重要です。Microsoft 公式ドキュメントでは、2027年3月31日以降、Microsoft Sentinel は Azure portal でサポートされず、Microsoft Defender portal のみで利用可能になると案内されています。(Microsoft Learn)
そのため、2026年4月時点で新しく運用設計を見直すなら、Azure portal 前提の手順書を増やすのではなく、Microsoft Defender portal 前提で整備する方が将来の手戻りを減らせます。
見直すべき項目は次のとおりです。
- 運用手順書の画面遷移
- SOC 担当者向けトレーニング資料
- 権限ロールとアクセス申請フロー
- インシデント対応時のエスカレーション手順
- Repositories、Content management、Automation 関連の操作手順
- 監査・証跡取得のスクリーンショットやログ取得方法
移行は単なる画面変更ではありません。Microsoft Defender XDR との統合運用を意識し、インシデント、アラート、ID、エンドポイント、クラウドログを横断して扱う前提で手順を再設計することが重要です。
APIでリポジトリ接続を管理している場合の注意点
Microsoft Sentinel Repositories を API で作成・管理している組織は、2026年6月の API バージョン移行に注意が必要です。Microsoft 公式ドキュメントでは、古い API バージョンは 2026年6月以降サポートされなくなり、API でリポジトリ接続を作成・管理している場合は、2026年6月15日までに 2025-09-01、2025-06-01、または 2025-07-01-preview へ移行するよう案内されています。既存のリポジトリ接続自体は影響を受けないとされています。(Microsoft Learn)
この点は、IaC や社内ポータルから Sentinel リポジトリ接続を自動作成している組織ほど重要です。対象になりやすいのは、次のような運用です。
- 新規ワークスペース作成時にリポジトリ接続も自動作成している
- Azure REST API を使って Source Control / Source Controls を操作している
- 複数テナント・複数リージョン向けに Sentinel 環境をテンプレート展開している
- MSSP として顧客ごとに標準 Sentinel 構成を自動展開している
確認すべきことはシンプルです。リポジトリ接続を作るスクリプト、Terraform 以外の独自ツール、PowerShell、Azure CLI、REST API 呼び出しを棚卸しし、使用している API バージョンを確認してください。該当する場合は、検証環境で新バージョンに切り替え、接続作成・削除・再作成・展開ログ確認までテストしておきましょう。
導入時のおすすめ運用モデル
実務では、最初からすべての Sentinel コンテンツをコード化しようとすると失敗しやすくなります。おすすめは、重要度と影響範囲に応じて段階的に進める方法です。
最初はAnalytics rulesから始める
最も効果が出やすいのは Analytics rules です。検知品質、変更履歴、承認フローの重要度が高く、リポジトリ管理のメリットが分かりやすいからです。
最初のスコープは、次のように絞るとよいでしょう。
- 既に本番で使っている重要ルールを10〜20件選ぶ
- ルールごとに所有チームを決める
- README に検知目的、想定インシデント、調査手順を記載する
- 本番展開前に検証ワークスペースへ展開する
- 1〜2回の変更サイクルを回してから対象を増やす
次にParsersとHunting queriesを整理する
Parser は複数の検知ルールやハンティングクエリに影響します。先にルールだけを整備し、後から Parser を変えると影響範囲の調査が難しくなることがあります。
そのため、Analytics rules の運用が安定したら、Parsers と Hunting queries を整理しましょう。命名規則、説明文、対象ログ、想定するスキーマを揃えると、SOC アナリストが調査時に迷いにくくなります。
PlaybooksとAutomation rulesは慎重に展開する
Automation rules や Playbooks は、インシデント処理を自動化するため効果が大きい一方、誤設定の影響も大きい領域です。たとえば、重要インシデントを自動でクローズしてしまう、誤った担当者へ割り当てる、外部通知を過剰に送るといった問題が起こり得ます。
本番化する前に、次の条件を満たしているか確認してください。
- 自動化の対象インシデント条件が明確である
- 例外条件が定義されている
- Playbook 実行に必要な権限が最小限である
- 失敗時の通知先が決まっている
- 手動実行と自動実行の違いを運用担当者が理解している
今すぐ確認すべきチェックリスト
2026年4月の更新を受けて、既存の Microsoft Sentinel 環境では次の項目を確認してください。
| チェック項目 | 確認内容 |
|---|---|
| リポジトリ接続の有無 | どのワークスペースが GitHub / Azure DevOps と接続されているか |
| 接続作成日 | Bicep 利用時、2024年11月1日より前の接続がないか |
| 管理対象コンテンツ | Analytics rules、Automation rules、Hunting queries、Parsers、Playbooks、Workbooks のどれを展開しているか |
| 編集ルール | Sentinel ポータルで直接編集していないか |
| 削除手順 | リポジトリ削除だけで Sentinel 側に残っていないか |
| Smart deployments | 既定有効のままか、意図的に無効化しているか |
| API利用 | リポジトリ接続を API で作成・管理していないか |
| ポータル移行 | Defender portal 前提の手順書に更新しているか |
| 監査証跡 | PR、承認、展開ログ、チケットが紐付いているか |
このチェックリストで問題が見つかった場合、まずは本番影響の小さい検証ワークスペースでリポジトリ接続を再現し、展開ログ、ロールバック手順、権限不足時のエラーを確認してから本番へ反映してください。
まとめ
Microsoft Sentinel の「Deploy custom content from your repository (Preview)」は、Sentinel のカスタムコンテンツを GitHub または Azure DevOps で管理し、CI/CD の流れでワークスペースへ展開するための重要な機能です。単に作業を自動化するだけでなく、検知ルールのレビュー、変更履歴、承認、監査証跡を整える土台になります。
2026年4月時点で特に重要なのは、プレビュー機能であることを踏まえて段階導入すること、Azure portal から Microsoft Defender portal への移行を見据えること、Bicep・Smart deployments・API バージョン移行の注意点を見落とさないことです。
まずは、既存の Analytics rules を棚卸しし、重要ルールからリポジトリ管理へ移す計画を立てましょう。次に、検証ワークスペースで GitHub または Azure DevOps との接続を作成し、展開ログとロールバック手順を確認します。そのうえで、ID管理チームやコンプライアンス担当者もレビューに参加できる Pull Request 運用へ移行すると、Microsoft Sentinel の運用品質を着実に高められます。
コメント