Microsoft Sentinelで分析ルールやハンティングクエリを増やしていくと、「誰がどこで変更したのか」「本番ワークスペースに同じ内容をどう反映するのか」がすぐに課題になります。2026年4月22日に更新された公式ドキュメントでは、Microsoft SentinelのカスタムコンテンツをGitHubまたはAzure DevOpsのリポジトリ接続で管理し、CI/CDに乗せて展開する考え方が改めて整理されています。(Microsoft Learn)
結論から言うと、Microsoft Sentinelのリポジトリ接続は、分析ルール・自動化ルール・ハンティングクエリ・パーサー・プレイブック・ワークブックを「Content as Code」として管理したい組織に向いています。特に、複数ワークスペースを運用するsecurity admins、identity teams、compliance teamsは、ポータル上で個別編集する運用から、リポジトリを正本にする運用へ切り替えることで、変更管理・監査・展開ミスの削減を進めやすくなります。(Microsoft Learn)
Microsoft Sentinelのリポジトリ接続とは
Microsoft Sentinelのリポジトリ接続は、外部のソース管理リポジトリに保存したカスタムコンテンツを、Microsoft Sentinelワークスペースへ自動展開するための機能です。公式ドキュメントでは、外部リポジトリからカスタムSentinelコンテンツをCI/CDでデプロイ・管理でき、ワークスペースごとの手作業による更新や展開を減らせる機能として説明されています。(Microsoft Learn)
ここで重要なのは、単に「GitHubやAzure DevOpsからファイルを読み込める」機能ではない点です。リポジトリ接続を使うと、Microsoft Sentinelのカスタムコンテンツをコードとして扱えます。つまり、変更履歴、レビュー、ブランチ運用、承認フロー、ロールバックといったDevOpsの考え方を、セキュリティ運用コンテンツにも適用できます。
対象になるカスタムコンテンツは次のとおりです。(Microsoft Learn)
| 対象コンテンツ | 実務での利用例 |
|---|---|
| Analytics rules | 不審なサインイン、権限昇格、マルウェア検知などの分析ルールを管理する |
| Automation rules | インシデントの自動割り当て、タグ付け、優先度変更などを標準化する |
| Hunting queries | 脅威ハンティング用KQLをチームで管理する |
| Parsers | ログソースごとのパーサーを共通化する |
| Playbooks | Logic Appsベースの対応自動化を展開する |
| Workbooks | SOCダッシュボードや監査用ビューを複数環境へ展開する |
実務上のポイントは、リポジトリ側の更新がMicrosoft Sentinelワークスペースへ同期され、ポータル側で行った変更を上書きする可能性があることです。公式ドキュメントでも、接続されたワークスペースではリポジトリがカスタムコンテンツの「single source of truth」になると説明されています。(Microsoft Learn)
2026年4月更新で押さえるべきポイント
今回の更新で読むべきポイントは、「新機能が1つ追加された」というより、リポジトリ接続を本番運用に組み込むための前提条件・制限・移行期限が明確に整理されている点です。特に次の項目は、既存環境の棚卸し対象になります。
| 確認項目 | 2026年4月時点での要点 | 影響を受けやすいチーム |
|---|---|---|
| 対応リポジトリ | GitHubとAzure DevOpsのみ対応 | SOC、DevSecOps |
| 権限 | GitHubはCollaborator、Azure DevOpsはProject Administratorが必要 | security admins、platform teams |
| ワークスペース側権限 | Sentinelワークスペースを含むリソースグループのOwnerロールが必要 | Azure管理者 |
| 接続数 | 1つのMicrosoft Sentinelワークスペースにつき最大5つのリポジトリ接続 | 複数チームで運用する組織 |
| テンプレート形式 | BicepまたはARMテンプレートをサポートし、MicrosoftはBicepを推奨 | IaC担当、クラウド基盤担当 |
| API移行 | 古いAPIバージョンは2026年6月から非サポートとなり、2026年6月15日までに指定バージョンへ移行が必要 | 自動化・運用ツール担当 |
公式ドキュメントでは、GitHubとAzure DevOpsのみがサポートされること、GitHub ActionsまたはAzure DevOps Pipelinesを有効にする必要があること、Azure DevOps接続はMicrosoft Sentinelワークスペースと同一テナントである必要があることが示されています。(Microsoft Learn)
また、1ワークスペースあたりのリポジトリ接続は現在5つまでです。チームごとに別リポジトリを接続する設計を考えている場合は、「検知ルール」「自動化」「可視化」などで分けすぎると上限に当たりやすくなります。(Microsoft Learn)
リポジトリ接続が向いているケース、向いていないケース
Microsoft Sentinelのリポジトリ接続は便利ですが、すべての組織で最初から導入すべき機能ではありません。導入判断では、コンテンツの量よりも「変更管理の必要性」を基準にすると失敗しにくくなります。
| 判断軸 | 向いているケース | 慎重に進めたいケース |
|---|---|---|
| ワークスペース数 | 開発・検証・本番、地域別、事業部別など複数ある | 単一ワークスペースで変更頻度が低い |
| 変更管理 | Pull Requestレビューや承認フローを使いたい | SOC担当者がポータルで即時変更する文化が強い |
| 監査対応 | 変更履歴、承認者、反映タイミングを説明する必要がある | 監査要件がまだ明確でない |
| コンテンツ標準化 | グローバル共通ルールを各リージョンへ展開したい | ローカル環境ごとの個別調整が多い |
| 自動化成熟度 | GitHub ActionsやAzure DevOps Pipelinesの運用経験がある | CI/CD基盤の管理者がいない |
たとえば、グローバル企業で各国のSOCがMicrosoft Sentinelを利用している場合、共通の分析ルールをリポジトリで管理し、国・地域ごとのパラメーターだけを分けて展開できます。一方、単一ワークスペースで少数の分析ルールしかない環境では、まずエクスポート手順やレビュー手順を整えてから段階的に導入した方が安全です。
既存運用で最初に確認すべきこと
すでにMicrosoft Sentinelを運用している場合、いきなりリポジトリ接続を作成するのではなく、現在のカスタムコンテンツを棚卸しすることが重要です。特に分析ルールは、ポータルで臨時修正されていることが多く、リポジトリ化した瞬間に「正しいはずのルール」が上書きされる可能性があります。
最初に確認する項目は次のとおりです。
| 確認項目 | 見るべきポイント | 放置した場合のリスク |
|---|---|---|
| 分析ルールの所有者 | ルールごとに担当チームが明確か | 変更時に承認者が分からない |
| ポータル上の手動変更 | 一時的な無効化、しきい値変更、KQL修正があるか | リポジトリ展開時に意図せず上書きされる |
| 環境差分 | dev/test/prodでルール内容が違うか | 本番だけの例外設定が失われる |
| パラメーター | ワークスペースID、Logic Apps接続、メール宛先などが環境依存か | 別環境への展開で失敗する |
| 監査要件 | 変更履歴や承認ログを保存する必要があるか | コンプライアンス説明が難しくなる |
公式ドキュメントでも、接続後はリポジトリに保存された内容がMicrosoft Sentinelへ展開されるため、編集はMicrosoft Sentinelポータルではなくリポジトリ側で行うことが推奨されています。ポータル側で編集した場合は、次回展開で上書きされないよう、リポジトリへエクスポートする必要があります。(Microsoft Learn)
GitHubとAzure DevOpsのどちらを選ぶべきか
Microsoft Sentinelのリポジトリ接続では、GitHubとAzure DevOpsがサポートされています。どちらを選ぶかは、好みではなく既存のID管理、監査、開発プロセスとの相性で決めるべきです。
| 比較項目 | GitHub | Azure DevOps |
|---|---|---|
| 向いている組織 | GitHub EnterpriseやGitHub Actionsを標準利用している組織 | Azure DevOps Repos/Pipelinesを標準利用している組織 |
| 権限要件 | リポジトリへのCollaboratorアクセスが必要 | Project Administratorアクセスが必要 |
| 実行基盤 | GitHub Actions | Azure DevOps Pipelines |
| テナント条件 | Microsoft Sentinelアプリの認可が必要 | Sentinelワークスペースと同一テナントの接続が必要 |
| 運用上の注意 | Actionsの権限設定、ブランチ保護、PRレビューを整える | サービス接続、Pipeline権限、プロジェクト管理者権限を整える |
すでに開発部門がGitHubを使っていて、セキュリティチームもPull Requestレビューに参加できるならGitHubが自然です。一方、Azure管理や監査フローがAzure DevOps中心なら、Azure DevOpsの方が権限設計を一本化しやすいでしょう。
BicepとARMテンプレートの使い分け
Microsoft Sentinel repositoriesでは、BicepファイルとARMテンプレートによるコンテンツ展開がサポートされています。公式ドキュメントでは、AzureリソースやMicrosoft Sentinelコンテンツを記述しやすい理由からBicepが推奨されています。(Microsoft Learn)
ただし、既存環境からBicepへ移行する場合は注意が必要です。公式ドキュメントでは、2024年11月1日より前に作成されたリポジトリ接続でBicepファイルを使うには、接続の削除と再作成が必要とされています。また、ARM JSONをBicepへデコンパイルする際、Bicepではidプロパティがサポートされないため、分析ルールのエクスポートテンプレートに含まれるidを削除する必要があります。(Microsoft Learn)
実務では、次のように使い分けると整理しやすくなります。
| 状況 | おすすめ |
|---|---|
| 新規にSentinelコンテンツをコード管理する | Bicepを基本にする |
| 既存のARMテンプレートが多い | まずARMのままリポジトリ管理し、段階的にBicepへ移行する |
| 複数ワークスペースへ展開する | BicepまたはJSONパラメーターファイルを使い、環境差分を分離する |
| エクスポートした分析ルールをBicep化する | idプロパティなど非対応項目を確認してからデプロイする |
Bicep化は「読みやすくなる」だけでなく、レビューしやすくなる点も重要です。セキュリティ管理者がKQLやルール条件を確認し、クラウド基盤担当がパラメーターやリソース定義を確認する、といった分担がしやすくなります。
Smart deploymentsで何が改善されるのか
Smart deploymentsは、接続されたリポジトリ内の変更ファイルを追跡し、前回展開以降に変更されていないコンテンツの再デプロイを避ける機能です。公式ドキュメントでは、.sentinelフォルダー内のCSVファイルを使ってコミットごとの差分を監査し、変更されていないファイルを再展開しないことで、展開性能を改善し、分析ルールの動的スケジュールがリセットされるような不要な影響を防ぐと説明されています。(Microsoft Learn)
この機能は、新規作成された接続では既定で有効です。すべてのコンテンツを毎回再展開したい場合は、ワークフローまたはパイプラインを変更してSmart deploymentsを無効化できます。(Microsoft Learn)
実務では、基本的にSmart deploymentsは有効のままにするのが無難です。無効化を検討するのは、次のようなケースに限られます。
| ケース | Smart deploymentsの扱い |
|---|---|
| 通常の分析ルール更新 | 有効のまま運用する |
| 大量の既存コンテンツを初回展開する | 有効のままでよいが、展開ログを確認する |
| テンプレート全体を再適用して環境差分をリセットしたい | 一時的な無効化を検討する |
| パラメーターや依存関係の変更を広範囲に反映したい | 対象範囲を確認し、必要なら再展開を設計する |
Smart deploymentsを無効化すると、関係するコンテンツが毎回再展開されるため、展開時間の増加や意図しない上書きのリスクが高まります。監査やトラブルシューティング目的で無効化する場合も、恒久的な設定にせず、変更理由をPull Requestや運用記録に残しておくべきです。
デプロイのカスタマイズでできること
Microsoft Sentinelのリポジトリ接続は、作成したら終わりではありません。GitHub ActionsやAzure DevOps Pipelinesの設定を調整することで、展開タイミングや展開対象を制御できます。
公式ドキュメントでは、ワークフローまたはパイプラインのカスタマイズによって、異なるデプロイトリガーの設定、特定ルートフォルダーからの展開、定期実行、複数イベントの組み合わせ、Smart deploymentsの無効化などが可能とされています。(Microsoft Learn)
特に実務で役立つのは、フォルダー単位の展開です。たとえば、次のようにリポジトリを分けると、チームごとの責任範囲が明確になります。
SentinelContent/
AnalyticsRules/
Identity/
Endpoint/
CloudApps/
HuntingQueries/
Parsers/
Playbooks/
Workbooks/
Parameters/IdentityチームはAnalyticsRules/Identity/配下のルールをレビューし、SOCチームはハンティングクエリとワークブックを管理する、といった分担が可能です。ただし、GitHubとAzure DevOpsのどちらでも、トリガーパスとデプロイパスのディレクトリを一致させる必要があります。公式ドキュメントでも、この点は重要事項として示されています。(Microsoft Learn)
複数ワークスペース運用ではパラメーターファイルが重要
グローバル環境や複数事業部でMicrosoft Sentinelを使う場合、同じ分析ルールでもワークスペースID、リージョン、通知先、対象ログソース、Logic Apps接続などが異なります。これらをテンプレート本体に直接書き込むと、環境ごとにファイルが増え、レビューも保守も難しくなります。
公式ドキュメントでは、インライン値ではなくBicepパラメーターファイルまたはJSONパラメーターファイルを使い、Microsoft Sentinelコンテンツファイルへマッピングすることで、複数ワークスペースへの展開をスケールしやすくすると説明されています。(Microsoft Learn)
パラメーターファイルの優先順位は、sentinel-deployment.configでのマッピング、ワークスペースID付きパラメーターファイル、既定パラメーターファイルの順に評価されます。優先順位が決まった後は、残りのマッピングは無視されます。(Microsoft Learn)
| 方法 | ファイル例 | 向いているケース |
|---|---|---|
sentinel-deployment.configで明示マッピング | sentinel-deployment.config | 複数ワークスペースを厳密に管理したい |
| ワークスペースID付きパラメーター | .<WorkspaceID>.bicepparam、.parameters-<WorkspaceID>.json | 環境ごとの差分をファイル名で分けたい |
| 既定パラメーター | .bicepparam、.parameters.json | 単一環境または共通値が多い環境 |
複数ワークスペース運用では、最初からsentinel-deployment.configを使う設計がおすすめです。理由は、どのコンテンツにどのパラメーターファイルが対応するかを明示できるためです。監査対応でも、設定根拠を説明しやすくなります。
API管理をしている組織は2026年6月15日までの確認が必須
今回の更新で特に見落とせないのが、APIバージョンに関する注意です。公式ドキュメントでは、Microsoft Sentinel repositoriesで使われる古いAPIバージョンは2026年6月からサポートされなくなり、リポジトリ接続をAPIで作成・管理している場合は、サービス中断を避けるため2026年6月15日までに2025-09-01、2025-06-01、または2025-07-01-previewへ移行するよう案内されています。既存のリポジトリ接続自体は影響を受けないとされています。(Microsoft Learn)
Microsoft LearnのREST APIページでも、Source ControlおよびSource ControlsのAPI Versionとして2025-09-01が表示されています。Source Controlにはリポジトリメタデータ一覧取得、Source Controlsには作成・削除・取得・一覧取得の操作が用意されています。(Microsoft Learn)
確認すべき対象は、Azure Portalから手動で接続しているチームよりも、Terraform、Azure CLI、PowerShell、自社運用ツール、GitHub Actions、Azure DevOps PipelinesなどからAPIを呼び出しているチームです。
| 確認対象 | チェック内容 |
|---|---|
| 自動化スクリプト | APIバージョンが古い固定値になっていないか |
| CI/CDパイプライン | Sentinelリポジトリ接続の作成・更新処理があるか |
| 運用ツール | Source Control関連APIを呼び出していないか |
| 権限設定 | 新バージョン移行後も必要なロールで実行できるか |
| 変更計画 | 2026年6月15日より前に検証・本番反映できるか |
この確認はsecurity adminsだけで完結しないことが多いです。実装を担当したDevOpsチーム、Azure基盤チーム、ID管理チームと一緒に、API呼び出し箇所を洗い出してください。
Microsoft Defenderポータル移行も同時に見ておく
Microsoft SentinelをAzureポータル中心で運用している組織は、リポジトリ接続の見直しとあわせてMicrosoft Defenderポータルへの移行計画も確認しておくべきです。公式ドキュメントでは、2027年3月31日以降、Microsoft SentinelはAzureポータルでサポートされず、Microsoft Defenderポータルでのみ利用可能になると案内されています。また、2025年7月以降、多くの新規顧客はDefenderポータルへ自動的にオンボード・リダイレクトされるとされています。(Microsoft Learn)
これは、リポジトリ接続そのものの設定だけでなく、運用手順書、教育資料、監査証跡の取得方法にも影響します。たとえば、手順書に「Azure Portal > Microsoft Sentinel > Content management > Repositories」と書いてある場合、Defenderポータル側のナビゲーションも併記しておく必要があります。
導入手順の実務フロー
Microsoft Sentinelのリポジトリ接続を安全に導入するなら、次の順序で進めると手戻りを減らせます。
| 手順 | 作業内容 | 成果物 |
|---|---|---|
| 事前棚卸し | 既存の分析ルール、クエリ、プレイブック、ワークブックを一覧化する | コンテンツ台帳 |
| 正本の決定 | ポータル管理からリポジトリ管理へ移す対象を決める | 管理対象リスト |
| 権限確認 | GitHub/Azure DevOpsとAzure側の必要権限を確認する | 権限チェック表 |
| リポジトリ設計 | フォルダー構成、命名規則、ブランチ戦略を決める | リポジトリ設計書 |
| テンプレート化 | BicepまたはARMテンプレートへ整理する | IaCファイル |
| パラメーター分離 | 環境差分をパラメーターファイルへ切り出す | .bicepparamまたはJSON |
| 接続作成 | SentinelのRepositoriesから接続を作成する | リポジトリ接続 |
| 検証展開 | 検証ワークスペースへ展開し、ログと差分を確認する | 検証結果 |
| 本番反映 | 承認済みPRから本番ワークスペースへ展開する | 本番展開ログ |
| 運用定着 | ポータル直接編集を原則禁止し、変更フローを周知する | 運用ルール |
公式手順では、Microsoft SentinelのContent managementからRepositoriesを選択し、GitHubまたはAzure DevOpsを認可して、リポジトリ、ブランチ、コンテンツタイプを選び、接続を作成します。接続後は、新しいワークフローまたはパイプラインがリポジトリに生成され、保存されたコンテンツがMicrosoft Sentinelワークスペースへ展開されます。(Microsoft Learn)
失敗しやすいポイントと対策
リポジトリ接続の失敗は、技術的なエラーだけでなく、運用ルールの曖昧さからも発生します。導入前に次の落とし穴を潰しておきましょう。
| 失敗しやすいポイント | 何が起きるか | 対策 |
|---|---|---|
| ポータル編集を続けてしまう | 次回デプロイで変更が上書きされる | 編集場所をリポジトリに統一し、例外時は必ずエクスポートする |
| 権限を個人アカウントに依存する | 担当者異動や退職で接続管理が止まる | 管理用グループ、サービス接続、権限レビューを整備する |
| 接続数上限を考えず分割する | 1ワークスペース5接続の上限に近づく | チーム別ではなくコンテンツ管理単位で設計する |
| パラメーターをテンプレートに直書きする | 環境差分が増えて保守不能になる | パラメーターファイルとsentinel-deployment.configを使う |
| Smart deploymentsを安易に無効化する | 不要な再展開が増え、上書きリスクが上がる | 原則有効、無効化は目的と期間を明記する |
Bicep移行時にidを残す | デプロイ時にエラーになる可能性がある | ARMからBicep化する際に非対応プロパティを確認する |
| APIバージョンを放置する | 2026年6月以降に自動化が失敗する可能性がある | 2026年6月15日より前に対象APIへ移行する |
特に注意したいのは、「リポジトリ接続を導入したのに、緊急対応時だけポータルで直す」運用です。緊急対応自体は現場では起こり得ますが、その変更をリポジトリへ戻さなければ、次回デプロイで消える可能性があります。例外運用を禁止するよりも、「緊急変更後24時間以内にリポジトリへ反映する」などのルールを決めておく方が現実的です。
security admins、identity teams、compliance teams別の見るべき観点
同じMicrosoft Sentinel repositoriesでも、チームによって見るべきポイントは異なります。
security adminsが見るべきポイント
security adminsは、検知品質と運用安定性を優先して確認します。分析ルールのKQL、しきい値、インシデント生成条件、MITRE ATT&CKマッピング、抑制設定などが、レビューなしに本番反映されない仕組みを作ることが重要です。
おすすめは、Pull Requestテンプレートに次の確認項目を入れることです。
- 変更対象のルール名
- 変更理由
- 影響するデータソース
- 想定されるアラート増減
- 検証ワークスペースでの実行結果
- ロールバック方法identity teamsが見るべきポイント
identity teamsは、Microsoft Entra ID関連の検知ルールやサインインログ、条件付きアクセス、特権ID操作に関するルールを重点的に確認します。Identity系のルールは誤検知が多いとSOCの負荷が上がり、逆に条件が緩いと侵害兆候を見逃す可能性があります。
たとえば、管理者ロール付与、MFA設定変更、リスクの高いサインインなどは、グローバル共通ルールと国・地域別の例外を分けて管理すると運用しやすくなります。
compliance teamsが見るべきポイント
compliance teamsは、変更履歴、承認者、展開日時、影響範囲を追跡できるかを確認します。リポジトリ接続を使うと、Pull Request、コミット履歴、パイプラインログを監査証跡として活用しやすくなります。
ただし、監査で使うには、リポジトリの命名規則、ブランチ保護、レビュー必須設定、ログ保管期間なども合わせて整える必要があります。単にリポジトリへ置いただけでは、監査対応が自動的に完成するわけではありません。
まず実施すべきアクション
2026年4月更新を踏まえると、Microsoft Sentinelを運用している組織が最初に取るべき行動は明確です。
まず、カスタムコンテンツを棚卸しし、リポジトリ管理へ移す対象を決めてください。次に、GitHubまたはAzure DevOpsのどちらを正本にするかを決め、権限、ブランチ保護、レビュー手順を整備します。すでにAPIでリポジトリ接続を管理している場合は、2026年6月15日までにAPIバージョンを確認し、必要に応じて2025-09-01、2025-06-01、2025-07-01-previewへ移行します。(Microsoft Learn)
Microsoft Sentinel repositoriesは、単なる便利機能ではなく、セキュリティ運用コンテンツをコードとして管理するための土台です。ポータル上の属人的な変更から、レビュー可能で再現性のある運用へ移すことで、SOC運用、ID管理、コンプライアンス対応を同じ変更管理プロセスに乗せられます。まずは検証ワークスペースで1つの分析ルールをリポジトリ化し、展開ログ、上書き挙動、承認フローを確認するところから始めるのが現実的です。
コメント