2026年6月15日までに見直す、SentinelリポジトリAPIとコンテンツ管理

2026年4月20日 07:30

それはAPI更改ではなく、SecOpsの“信頼の源泉”を作り直す話だ

2026年6月15日は、Sentinelの小さなAPI更改日ではありません。
この日までに問われるのは、自社のSOCが何を「製品標準コンテンツ」として扱い、何を「自社カスタム」としてGitで管理し、どの変更をどのAPIで回し、どこまでをDefenderポータル前提に揃えるのかという、運用の土台そのものです。Microsoftは2026年3月の新機能案内で、Microsoft Sentinel Repositoriesの一般提供開始と、古い Source Control / Source Controls APIバージョンのサポート終了を並べて告知しています。しかもSentinelの新機能ページ自体が「過去6か月間にリリースされた機能」を扱うものですが、その短い期間だけでも、UEBA動作レイヤーのGA、AIを使ったプレイブック生成、Defenderポータル側のUEBAウィジェット、Azureポータル廃止に向けた移行告知、Repositories GAと、運用面に効く変更が立て続けに入っています。つまり今回は、SDKの差し替えではなく、SecOpsの前提が動いている時期に、リポジトリとコンテンツ管理を据え直す話です。

しかも、Sentinel単体で閉じる話でもありません。Microsoft Defenderポータルの統合セキュリティ操作は、Defender XDR、Microsoft Sentinelなどを組み合わせ、体制管理と検出・対応を一元ビューで扱う方向へ明確に進んでいます。Defender for Cloudも、Defender XDRポータルと統合されて、クラウドの体制管理とSOC運用を同じ面で見せる設計です。要するに、コンテンツ管理の設計を誤ると、検出ロジックだけでなく、クラウド姿勢管理、インシデント運用、監査提出まで巻き込んでズレる時代に入っています。

山崎行政書士事務所が掲げる「クラウド法務 × Azure現場伴走」が、まさにこの論点に刺さります。事務所サイトでも、要件定義〜運用の技術面と契約・文書整備の法務面を一体で支え、Azure案件と契約の「曖昧さ」を技術・運用・法務をまたいで潰すと明示しています。さらに「クラウド法務×Azure技術支援とは何か」の記事でも、現場で本当に事故を起こすのは、責任分界が運用で曖昧になり、ログはあるのに提出できる証跡にならず、RPO/RTOや契約条項と運用が接続していない“翻訳不全”だと整理しています。今回のテーマは、まさにその翻訳不全が表面化する領域です。

1. まず押さえるべきは、「6月15日問題」は新規接続APIの問題だということ

Microsoftの2026年3月の案内では、2026年6月15日から、Microsoft Sentinelリポジトリで使われる古いAPIバージョンがサポートされなくなり、影響を受ける Source Control と Source Controls のREST API要求は失敗するとされています。ただし、ここで重要なのは、古いAPIで作成済みの既存リポジトリ接続そのものは影響を受けず、リポジトリは引き続き動作するという点です。つまり、止まるのは「既存の同期」より、自動化で接続を新規作成・更新・管理している制御面です。IaC、CLIラッパー、PowerShell、自社ポータル、委託先の運用スクリプトがここに乗っているなら、6月の事故は静かに起きます。

さらに面倒なのは、Microsoftの日本語公式文書の中で、締切の表現にズレがあることです。2026年3月の新機能ページは、サポート終了を2026年6月15日と書きつつ、必要なアクションとしては2026年6月1日より前に 2025-09-01、2025-06-01、2025-07-01-preview へ移行するよう求めています。一方、リポジトリ管理の記事は、2026年6月15日より前に同じバージョンへ移行するよう案内しています。私はこういうとき、文書上の最終日ではなく、5月末を内部締切にします。Microsoft自身の案内に6月1日基準がある以上、「6月14日に切替えればよい」は運用として甘いからです。

しかも、その新機能ページをよく読むと、さらに実務的な違和感があります。影響を受けるプレビュー版の一覧には 2025-07-01-preview が含まれている一方、推奨バージョンにも 2025-07-01-preview が挙がっています。この表記どおりに受け取るなら、推奨に含まれるプレビュー版が、同じ案内の中で廃止対象にも見えるわけです。だから、よほどプレビューでしか必要な機能がないのでなければ、私は修正先を**安定版の 2025-09-01 か 2025-06-01**に寄せます。ここは単なる趣味ではなく、Microsoft文書の読み合わせから導く保守的な設計判断です。

影響対象の安定版も、古いものが残っています。新機能ページでは、安定版として 2023-11-01、2024-03-01、2024-09-01、2025-03-01 が廃止対象に入っています。つまり、「うちはプレビュー使っていないから関係ない」は成立しません。古い安定版で止めている自作ツールこそ、今回の締切で落ちる可能性があります。SentinelのSource Control周りを自作しているチームほど、まずRESTのapi-versionを棚卸しすべきです。

2. 本当に怖いのは、APIバージョンより“管理実態が見えていない”こと

ここで実務の核心に入ります。
2025-09-01 の Source Controls - Create スキーマを見ると、repositoryAccess の種別として OAuth、PAT、App があり、さらに servicePrincipal.credentialsExpireOn や workloadIdentityFederation のメタデータも持っています。つまり、6月の棚卸しは「api-version を置換したか」だけでは不十分で、その接続が OAuth なのか、PAT なのか、GitHub App なのか、サービスプリンシパルの資格情報に有効期限があるのか、ワークロードIDフェデレーション前提なのかまで見なければ、本当の運用リスクは減りません。

しかも、このスキーマで非常に重要なのが、repositoryAccess が書き込み専用で、ユーザーには返されないという点です。これは地味ですが重い仕様です。つまり、後からGETして「この接続はPATだったっけ、OAuthだったっけ」と回収しようとしても、接続資格情報の中身は読み返せない前提で設計されています。要するに、接続情報はAzure上に“ある”のではなく、自社の台帳やIaC定義や運用設計書で持っていなければ、管理できないのです。クラウド法務の目線でいえば、ここは典型的な「動いているが説明できない」状態の温床です。

この論点は、山崎行政書士事務所の問題意識とも完全に重なります。事務所サイトでは、Azureの現場支援として、設計・構成・運用設計・ドキュメントまで落とし込み、KQLやスクリプトレビューも含めて品質を上げるとしています。リポジトリ接続の認証モデル、資格情報の期限、ワークロードIDフェデレーション前提、委託先がどの権限でどこに接続しているか――こういうものは、技術と文書の両方で持っていなければ事故後に説明できない領域です。

3. 接続要件を読むと、実は“権限設計”の話だと分かる

Sentinelリポジトリの計画要件も、かなり実務的です。Microsoftは、接続先としてGitHub と Azure DevOps のみをサポートし、GitHubではコラボレーター権限、Azure DevOpsではプロジェクト管理者権限を求めています。さらに、GitHubではActions有効化、Azure DevOpsではPipelines有効化、Azure DevOps接続はSentinelワークスペースと同じテナントに存在する必要があると明記しています。そして、リポジトリ接続の作成には、ワークスペースを含むリソースグループの Owner ロールが必要です。つまり、これは単なるDevOps接続ではなく、GitとAzureの両方にまたがる強めの権限設計です。

この要件を読むと、委託先やSOCベンダーを絡めたときに、契約と統制の論点が一気に出てきます。GitHub側のコラボレーター権限、Azure DevOpsの管理権、Azureのリソースグループ Owner、Actions/Pipelines 有効化権限――これらを誰に、何の根拠で、どの期間だけ渡すのか。山崎行政書士事務所の「委託先の特権アクセス」記事が指摘するように、外部が強権限を持つ正当性は、事故のときに技術論ではなく統制不備として信用事故化しやすい。Sentinelリポジトリは便利ですが、便利だからこそ、権限付与の正当性を文書化しておかないと危ないのです。

さらにスケール制約も見落としやすい。Microsoftは、1ワークスペースあたり最大5つのリポジトリ接続、そして1リソースグループあたりデプロイ履歴800件の制限を示しています。テンプレートデプロイが多い環境では DeploymentQuotaExceeded の可能性があるとも案内しています。つまり、MSSP型や部門横断型で「ワークスペース1つに全部寄せて、リポジトリをいくらでも足す」設計は、そのままでは伸びません。コンテンツ境界とワークスペース境界をどう切るかは、6月対応と同時に見直すべきです。

4. Repositoriesは便利だが、“ポータル編集文化”と相性が悪い

ここがいちばん本質です。
Microsoft Sentinel Repositories は、外部ソース管理リポジトリから分析ルール、オートメーションルール、ハンティングクエリ、パーサー、プレイブック、Workbookをデプロイできます。そしてMicrosoftは、リポジトリ側で行った更新はワークスペースへ同期され、ポータル上で加えた変更を上書きする、つまりRepositoriesが単一の信頼のソースになるとはっきり書いています。言い換えると、Repositoriesを使うなら、「とりあえず本番ポータルでルールを直す」文化は終わりです。

これを理解せずにリポジトリ接続だけ増やすと、現場は必ず荒れます。
アナリストはポータルでルールを一時修正したつもりでも、次の同期で消える。運用チームはGit側を正としたつもりでも、SOC側はポータルを正だと思っている。監査では「今の正しいルール定義はどれか」で止まる。だから私は、6月15日対応の本丸はAPI差し替えではなく、“OOTBはContent Hub、自社カスタムはRepositories、ポータル直接編集は例外”という運用宣言を出すことだと思っています。これは技術の話であると同時に、変更管理ルールの話です。

しかも、RepositoriesはBicep/ARMまわりでも罠があります。Microsoftは、2024年11月1日より前に作成した接続でBicepを使うには、接続を削除して再作成する必要があるとしています。また、Bicepでは id プロパティがサポートされないため、ARM JSONを逆コンパイルした場合に不要な id を消す必要があります。さらに、Repositories経由でデプロイした分析ルールのクロスワークスペースクエリは、ターゲットワークスペースが接続済みワークスペースと同じリソースグループ内にある場合のみ使えます。MSSPや複数RG運用では、ここで引っかかります。

一方で、ちゃんと使えばかなり強い。
Smart Deploy は既定で有効で、.sentinel フォルダー内のCSVを使って変更ファイルを追跡し、前回から変わっていないコンテンツの再デプロイを避けます。Microsoftは、これによってパフォーマンスが上がるだけでなく、分析ルールの動的スケジュールのリセットのような、未変更コンテンツの改ざん的な再適用を防ぐと説明しています。ワークスペース別にルートフォルダーを分ける、トリガーを変える、定期実行にする、除外・優先・パラメーターファイル指定を使う、といったカスタマイズも可能です。つまり、6月対応の先には、“Gitに置くだけ”ではない継続運用の設計があります。

5. OOTBはContent Hub、自社カスタムはRepositories。ここを混ぜない

Microsoftのコンテンツ管理設計は、実はかなり明快です。
Content Hub は、すぐに使えるコンテンツを一元的に検出・インストール・更新管理するための場所で、ソリューションとスタンドアロン項目を扱います。ここには各コンテンツのサポートモデルも表示され、Microsoft管理、パートナー管理、コミュニティ管理の違いが見えます。一方で、カスタムコンテンツは Repositories ページから更新を管理するというのがMicrosoftの整理です。つまり、OOTBとカスタムは最初から別管理です。ここを混ぜている限り、責任分界も変更責任も濁ります。

しかもContent Hubの役割は、単なるギャラリーではありません。Microsoftは、Content Hubを「新しいコンテンツの検索」と「既にインストール済みソリューションの管理」の最適な方法と位置付けています。Defenderポータルでも Microsoft Sentinel > Content 管理 > Content ハブという独立メニューに置かれており、Repositories も同じく Microsoft Sentinel > Content 管理 > リポジトリに分かれています。つまり、ポータルの画面配置自体が、“標準コンテンツ運用”と“自社コンテンツ運用”を分けろと言っているのです。

この分け方は、Defender for Cloud連携でも効いてきます。
Defender for Cloud は Defender XDR と統合され、Defender for Cloud のインシデントは XDR 側へ統合されます。さらに、Defender for Cloud アラートとインシデントは XDR の統合APIや高度なハンティングにも広がっています。そのうえでMicrosoftは、Defender XDRインシデントを統合し、かつDefender for Cloudアラートを取り込んでいる Sentinel 顧客は、重複を避けるために、Content Hub から入手できる Microsoft Defender for Cloud ソリューションに含まれる「テナントベースの Defender for Cloud データコネクタ」を構成する必要があると案内しています。つまり、Content Hubの管理は「便利そうだから」ではなく、重複インシデントを出さないための設計でもあります。

6. Defenderポータル移行は、UI変更ではなくAPI戦略の変更でもある

ここで、SentinelのDefenderポータル移行を別論点にしないことが大切です。
Microsoftの現行ドキュメントでは、2027年3月31日以降、Microsoft SentinelはAzureポータルでのサポートが終了し、Defenderポータルのみで利用可能になります。だから、6月15日のRepositories API見直しをAzureポータル前提のまま片付けるのは、設計として短命です。今やるべきなのは、**“6月対応を、そのままDefenderポータル移行準備に接続する”**ことです。

幸い、すべてが壊れるわけではありません。Microsoftは、Defenderポータルでも分析ルールの作成・更新・管理は、ウィザード、Repositories、Microsoft Sentinel APIを使う形で引き続き利用できるとしています。つまり、Sentinelリソースそのものの管理、たとえば分析ルールや自動化ルールやRepositoriesは、基本的にこれまでの延長で考えられます。ここが、今回の6月対応を「無駄にならない投資」にできるポイントです。

ただし、インシデントとアラートの自動化は別です。
Defenderポータル統合後、Microsoftはインシデント、アラート、高度なハンティングなどは Microsoft Graph REST API v1.0 を使うことを推奨しています。Microsoft Sentinel API は分析ルールや自動化ルールなどのSentinelリソースに対するアクションを引き続きサポートしますが、インシデントを SecurityInsights API で触り続ける場合は応答本文の変更に備えて自動化条件を更新すべきだとされています。つまり、今回の棚卸しでは Source Control / Source Controls だけでなく、既存SOARやチケット連携が incident/alert をどのAPIで取っているかも同時に見ないと、移行後に別の場所で落ちます。

実際、Defenderポータル移行時には、インシデント運用で細かな差分が出ます。
Microsoftは、自動化ルールで使うインシデントプロバイダー条件が削除されること、Defenderポータルにオンボード後は SecurityIncident テーブルに説明フィールドが含まれなくなること、そのため説明フィールドを条件にしている自動化ルールや外部チケット連携は更新が必要だと案内しています。Sentinelのリポジトリ管理を整えても、オンボード後の自動化条件が古いままなら運用は壊れます。ここを同じ変更票で扱うのが、設計として正しいです。

権限も同じです。
Microsoft Defender統合RBACをSentinelに対して有効化した後は、DefenderポータルでSentinel権限を管理すべきで、ワークスペースに対して統合RBACがアクティブになった後にAzureポータル側でアクセス許可を変えると、同期エラーが起こる可能性があると公式に書かれています。つまり、コンテンツ管理の移行は、GitとAPIだけでなく、権限の変更窓口をどちらに固定するかまで決める必要があります。

7. Defender for Cloudは、“提出できるSecOps”を強くする

ここからが、クラウド法務の視点でいちばん重要です。
Defender for Cloud は、今や単独製品として見るより、Defenderポータルの中で、姿勢管理・コンプライアンス・クラウドアラートをSecOpsへ渡す供給源として見た方が正確です。Microsoftは、Defender for Cloud が Defender XDR と統合され、すべての Defender for Cloud インシデントが XDR に統合されること、統合APIで他システムへエクスポートできること、さらに高度なハンティングでクラウドリソース・デバイス・IDを1つのクエリで追えることを説明しています。つまり、Sentinelのコンテンツ管理を見直すなら、Defender for Cloud から何がどこへ流れ、どこで相関されるかも一緒に設計すべきです。

そのうえで、規制コンプライアンスの見え方もかなり強くなっています。
Defender for Cloud の規制コンプライアンスダッシュボードでは、自動、手動、共有責任を含む要件を管理でき、手動評価には構成証明と証拠の添付があり、PDFレポートや監査レポートのダウンロード、さらに Event Hubs や Log Analytics への継続的エクスポートまで用意されています。ただし共有責任ビューはAzureにのみ対応です。ここは重要で、マルチクラウドやArcを含めた全社説明では、Defender for Cloud の画面をそのまま提出するだけでは足りず、自社で“どこまでがMicrosoft管理で、どこからが自社・委託先責任か”を補足する文書が必要です。

しかもこの半年で、可視化の前提自体が広がっています。
Defender for Cloud は 2025年11月に Microsoft Cloud Security Benchmark v2 をプレビュー公開し、リスク・脅威ベースのガイダンス、拡張されたAzure Policy測定、AIワークロード向け制御を規制コンプライアンスダッシュボードで追えるようにしました。2025年7月には DORA、EU AI法、k-ISMS-P、CIS Azure Foundations Benchmark v3.0 が追加され、2026年3月には AWS/GCP マルチクラウドカバレッジ拡張で約150の新しい推奨事項が追加され、既存フレームワークに取り込まれることで、マルチクラウド全体のコンプライアンス評価がより完全になっています。つまり、“姿勢管理の見える化”は今も拡張中であり、Sentinelのコンテンツ管理も、それに耐えるRACIと提出物を持たないと弱いままです。

8. Arcは“ハイブリッドの例外”ではなく、統合SecOpsの入口だ

Arcも同じです。
Azure Arc 対応サーバーは、Azure外でホストされる物理サーバーや仮想マシンをAzureリソースとして扱えるようにします。しかも、登録時に選ぶリージョンには保存データの場所が絡み、インスタンスメタデータとしてOS名・OSバージョン・FQDN・Connected Machine Agentバージョンなどがそのリージョンに格納されます。したがって、Arcは単に「オンプレも見えるようにする」ためのスイッチではなく、データ所在地、提出説明、監査対応まで含めた管理境界の話です。

SecOps設計として見ると、ArcではまずAzure Monitor Agent (AMA) をどう扱うかが要点です。Microsoftは、Arc対応サーバーで Azure Monitor Agent が必要になるケースとして、Azure Monitorの分析やアラート、Microsoft Defender for Cloud または Microsoft Sentinel を使ったAzureでのセキュリティ監視、インベントリ収集や変更追跡を挙げています。ArcサーバーをSentinelへオンボードする手順でも、AMAとLog Analyticsワークスペースが前提で、Arc対応サーバーからセキュリティ関連イベントの収集を開始できると説明しています。つまり、ハイブリッドのログ収集面では、AMAは今も重要です。

一方で、防御面は少し違います。
Defender for Servers の現行説明では、Log AnalyticsエージェントとAMAは、プランのほとんどの機能でサポートされなくなり、代わりにエージェントレススキャンと Defender for Endpoint 統合が主要機能を担う方向へ移っています。つまり、Arcを含むハイブリッドSecOpsでは、ログを運ぶ面と、保護機能を提供する面を分けて設計する必要があるのです。Sentinel取り込みのためにAMAを整備することと、Defender for Servers の保護モデルを旧エージェント前提で考えないことは、別の論点です。ここを混ぜると、運用設計も費用設計も崩れます。

しかもArc自体も、静的な基盤ではありません。
2026年3月更新の Connected Machine Agent リリースノートでは、最低限必要なTLS暗号スイートの適用、管理者特権が必要な azcmagent コマンドでの HIMDS パイプ所有者確認など、セキュリティとバグ修正が継続しています。つまり、Arcは「一度つないだら終わり」ではなく、エージェント自体のライフサイクルがSecOpsの継続課題です。Sentinelのコンテンツ管理だけGitで近代化しても、ArcエージェントやAMAの状態が古ければ、ハイブリッド面の信頼性は落ちます。

9. では、2026年6月15日までに何を見直すべきか

私なら、今回の見直しは6本の台帳で切ります。
第一に、API呼び出し台帳。 Source Control / Source Controls を呼ぶ自作ツール、GitHub Actions、Azure DevOps Pipelines、PowerShell、Terraform外部呼び出し、委託先バッチを洗い出し、api-version を 2025-09-01 か 2025-06-01 へ寄せる。プレビューにしかない機能が必要な場合だけ、その理由を残して 2025-07-01-preview を使う。この台帳がないと、6月以降に「一部の接続だけ作れない」が発生します。

第二に、接続認証台帳です。
接続ごとに GitHub / Azure DevOps、OAuth / PAT / App、サービスプリンシパルの有効期限、ワークロードIDフェデレーション有無、接続作成者、所有チーム、委託先関与を残す。repositoryAccess が書き込み専用で後から読み返せない以上、この台帳は“あった方がよい”ではなく必須です。ここに期限管理を入れておけば、6月対応と同時に将来の証明書失効事故もかなり減らせます。

第三に、コンテンツ権威台帳です。
どのルールやクエリが Content Hub 起源なのか、どれが Repositories 管理のカスタムなのか、ポータル直接編集が許される例外はあるのか。MicrosoftはOOTB更新はContent Hub、カスタム更新はRepositoriesと分け、Repositoriesを単一の信頼のソースとしています。だからここを決めずに6月対応を終えると、技術的には更新できても、変更管理としては未成熟なままです。

第四に、Defenderポータル移行差分台帳です。
インシデントとアラートを Graph に寄せる自動化、SecurityInsights API応答差分の確認、説明フィールド依存の自動化ルール、インシデントプロバイダー条件の見直し、URBAC の有効化有無、権限変更窓口のDefender側固定。この台帳を作れば、6月のAPI更改を、2027年3月31日のAzureポータル終了へ自然につなげられます。

第五に、Defender for Cloud 連携台帳です。
Defender XDR統合済みか、SentinelでのDefender for Cloudデータコネクタはどう構成するか、重複アラート回避はどうするか、規制コンプライアンスの証拠添付・PDF・継続エクスポートをどの提出先向けに使うか。これを整理しないと、SecOpsと監査対応が別々に走り始めます。

第六に、Arc / ハイブリッド監視台帳です。
Arc登録済み範囲、AMA配布状況、Azure Policyによる自動展開、Defender for Servers のプラン状態、エージェントレススキャン/MDE統合、Arcエージェント更新責任、リージョン選定理由。オンプレや他クラウドをSecOpsへ入れるなら、ここを曖昧にすると「クラウド側は見えるが、ハイブリッドは運用依存」の状態が続きます。

10. 結論

2026年6月15日までに見直すべきものは、SentinelリポジトリAPIの文字列だけではありません。
Gitを正にするのか、ポータルを正にするのか。
OOTBをContent Hubで回すのか、カスタムをRepositoriesで固定するのか。
インシデント自動化をGraphへ寄せるのか、古いSecurityInsights依存を引きずるのか。
Defender for Cloudの姿勢管理と、Arcのハイブリッド監視を、提出できる形にするのか。
この判断を先送りすると、6月のAPI対応は終わっても、SOC運用は古いまま残ります。

山崎行政書士事務所のクラウド法務×Azure技術支援が刺さるのは、まさにこの局面です。事務所サイトが示すとおり、要件定義から運用、KQL・スクリプトレビュー、契約・文書整備までを一つの流れで扱えるなら、今回の見直しは「API更改作業」ではなく、SecOpsの責任分界、変更管理、監査提出、委託先統制までつながる設計変更にできます。6月15日までに終わらせるべきなのは更新作業ではありません。“どのコンテンツを、誰が、どの権限で、どの証跡を残して運用するか”を言い切れる状態です。そこまで行って初めて、このテーマはnoteで刺さるだけでなく、現場でも効く記事になります。

本稿は一般的な情報提供です。個別案件の法的評価や紛争性のある論点は、事実関係・契約・適用法令に応じた個別整理が前提です。行政書士としての関与は、非紛争の範囲で、SOW、RACI、変更管理票、証跡目録、監査・提出向け説明資料などの整備支援が中心になります。