--- title: "Microsoft Sentinelとは？クラウドネイティブSIEM/SOARの仕組み・料金モデル・Defenderポータル統合を実装者目線で解説" url: "https://www.issoh.co.jp/tech/details/15647/" published: 2026-07-25 updated: 2026-10-12 categories: ["Azure"] publisher: "株式会社一創" --- # Microsoft Sentinelとは？クラウドネイティブSIEM/SOARの仕組み・料金モデル・Defenderポータル統合を実装者目線で解説 Microsoft Sentinelは、オンプレミスと複数のクラウドにまたがるログを1か所に集約し、AIと分析で脅威を検出し、自動化で対応まで進めるMicrosoft AzureのクラウドネイティブなSIEM／SOARサービスです。実装で最初に押さえるべきは、土台がAzure MonitorのLog Analyticsワークスペースであること、脅威検出（SIEM）と自動対応（SOAR）が一つのサービスに束ねられていること、そして料金がデータの取り込み量で決まることの3点になります。この記事では、定義から仕組み、データ収集・検出・調査・対応の各機能、従量課金とコミットメントレベルの料金モデル、2027年3月31日に予定されるAzure portal提供終了とDefenderポータルへの統合、そして「どんなシステムで採用し、どこでは別の選択にするか」の判断基準までを、2026年時点の公式ドキュメントに基づいて整理します。 ## まとめ：Microsoft Sentinelの要点と採用判断の分岐 Microsoft Sentinelは、各種ログを取り込んで相関分析し、脅威を検出してから対応までを一気通貫で回す「クラウド上のセキュリティ監視基盤」です。サーバーの構築や容量設計を自前で抱えず、Azure上のマネージドサービスとして始められる点が、従来型のオンプレミスSIEMとの大きな違いになります。運用設計の中心は、何をどのコネクタで取り込むか、どの分析ルールでアラートを出すか、そしてプレイブックでどこまで自動対応させるかの3点です。 採用が合理的なのは、Microsoft 365やAzure、Defender製品群を中心に使っていて、それらのログを横断で監視したい場合です。逆に、月間のログ取り込み量が読めないまま従量課金で始めるとコストが膨らみやすく、また既存のオンプレミスSIEMへの投資が大きい組織では移行の是非を慎重に見極める必要があります。自社システムにどの監視基盤が合うか迷う段階なら、クラウド全体の構成から相談できる開発会社に早めに当たると、後戻りの少ない設計にたどり着けます。 ## Microsoft Sentinelの仕組みとSIEM／SOARの位置づけ Sentinelを理解する近道は、SIEMとSOARという2つの役割と、その土台になっているLog Analyticsワークスペースを分けて捉えることです。まずこの3つの関係を押さえます。 ### クラウドネイティブSIEMとしての定義とオンプレミスSIEMとの違い SIEM（Security Information and Event Management）は、さまざまな機器やサービスのログを集約し、相関分析して脅威の兆候を見つける仕組みを指します。Sentinelはこれをクラウド上のマネージドサービスとして提供するため、保管容量やスケールの見積もりをAzure側に委ね、使った分だけ支払う形です。SIEM・EDR・XDR・SOARといった用語の関係を先に整理したい場合は、[SIEMの仕組みとEDR/XDR/SOARの違い・製品選定を解説した記事](/tech/details/13310/)を土台にすると、Sentinelがどの層を担う製品なのかが見取り図として掴めます。 ### SIEMとSOARを一つのサービスに束ねる統合的な設計という考え方 Sentinelは、脅威を「見つける」SIEMと、見つけた脅威に「対応する」SOARを同じサービス内で扱います。SOAR（Security Orchestration, Automation and Response）は、インシデント対応の定型作業を自動化・調整する役割で、Sentinelではプレイブックという形で実装する仕組みです。検出から対応までを別々のツールでつながずに済むため、アラートが出てからチケット起票や関係者への通知、初動の封じ込めまでを一連の流れで自動化できます。 ### Log Analyticsワークスペースを基盤とするデータ構造 Sentinelは単独で動くのではなく、Azure MonitorのLog Analyticsワークスペースを有効化する形で立ち上がります。取り込んだログはこのワークスペースにテーブルとして格納され、Azure Monitorの改ざん防止と不変性の仕組みを引き継ぐ構造です。つまりログの保存・検索の土台はLog Analytics、そこにセキュリティの分析・検出・対応の層を重ねるのがSentinel、という二層構造になっています。この関係を理解しておくと、後述する料金がなぜ「取り込み量」で決まるのかが腑に落ちます。 ## データ収集：多数のデータコネクタとASIMによるログデータの正規化 SIEMの価値は、何をどれだけ取り込めるかで決まります。Sentinelは多数のデータコネクタと正規化の仕組みで、雑多なログを分析可能な形にそろえます。 ### すぐに使える組み込みデータコネクタとカスタムでの独自接続の仕組み Sentinelには、Microsoft Entra IDやAzureアクティビティ、Azure Storageといった自社（Microsoft）ソース向けのコネクタが標準で用意され、多くはリアルタイムで連携します。Microsoft以外の製品についても、幅広いセキュリティ／アプリケーション製品のコネクタが提供されており、対応コネクタがないソースでも共通イベント形式（CEF）やSyslog、REST-APIでの接続が可能です。専用コネクタで賄えない場合は、独自のカスタムコネクタを作成する道も用意されています。 ### ASIMによるデータ正規化とスキーマ統一がもたらす分析のしやすさ 取り込むログは、機器やサービスごとに項目名も形式もばらばらです。Sentinelは、取り込み時とクエリ時の両方で正規化を行い、これらを統一されたビューへ変換します。この基盤が高度なセキュリティ情報モデル（ASIM）で、たとえば認証イベントやネットワークイベントを、ソースが違っても同じスキーマで扱えるのが特徴です。正規化がそろっているほど、後段の分析ルールを製品横断で書けるようになり、運用の手間が下がります。 ## 脅威検出：分析ルール・KQL・MITRE ATT&CK 集めたログから脅威を見つけ出すのが検出の層です。Sentinelは、組み込みの分析ルールとKusto照会言語（KQL）を軸に、誤検知を抑えながらアラートをインシデントへまとめます。 ### 分析ルールによるアラート生成からインシデントへの集約までの仕組み 分析ルールは、ログのパターンから脅威の兆候を拾ってアラートを生成する仕組みです。すぐに使える組み込みルールをそのまま適用することも、自社の環境に合わせて独自ルールを書くこともできます。Sentinelは、個々の低忠実度アラートを関連するエンティティ単位で束ね、調査すべきインシデントへとまとめ上げるのが分析ルールの役割です。これにより、アナリストが確認すべき対象の数を絞り込み、ノイズに埋もれるのを防ぎます。 ### KQL・MITRE ATT&CK・脅威インテリジェンス・UEBA 検出とハンティングの共通言語がKQLで、ログテーブルに対して柔軟な検索と集計を記述できます。生成された検出結果は、MITRE ATT&CKフレームワークの戦術・手法にマッピングされ、自組織のカバレッジのどこに穴があるかが一目で分かる仕組みです。加えて、多数の脅威インテリジェンスのソースを取り込んで悪意ある通信先や指標と突き合わせ、ユーザーやエンティティの振る舞い分析（UEBA）で普段と異なる挙動を異常として拾う仕組みも備えます。次の表に検出まわりの主な機能を整理します。 | 機能 | 役割 | 実装者の使いどころ | | ------- | --------- | ---------- | | 分析ルール | アラート生成と集約 | 組み込み＋独自ルール | | KQL | 検索・集計の言語 | 検出とハンティング | | MITRE対応 | 網羅範囲の可視化 | カバレッジ点検 | | UEBA | 異常挙動の検知 | 内部脅威の発見 | ## 調査と対応：インシデント調査・脅威ハンティング・プレイブック自動対応 検出の次は、深掘りする調査と、手を動かす対応です。Sentinelは対話的な調査ツールと、Azure Logic Appsに基づくプレイブックで、ここを支えます。 ### インシデント調査とアラート前のプロアクティブな脅威ハンティング インシデントの調査では、関係するユーザー・端末・IPといったエンティティを対話的なグラフ上でたどり、脅威の範囲と根本原因を絞り込めます。さらに、アラートが出る前の段階でも、MITREフレームワークに沿ったハンティングクエリで能動的に脅威を探し、有効なクエリはそのまま検出ルールへ昇格させられる仕組みです。機械学習や高度な可視化が必要な調査には、Azure Machine LearningのJupyterノートブックを組み合わせる方法も用意されています。 ### プレイブックによる自動対応とAzure Logic Appsとの関係 対応の自動化を担うのがプレイブックで、その実体はAzure Logic Appsのワークフローです。たとえば特定のインシデントが発生したら、ServiceNowやJiraでチケットを起票する、担当者へ通知する、といった一連の処理を自動で走らせます。プレイブックはオンデマンドでも自動化ルールによる自動トリガーでも実行でき、外部サービスとの連携も豊富なコネクタで賄えるのが強みです。ワークフローの土台となるLogic Apps自体の仕組みや料金を押さえたい場合は、[Azure Logic Appsの仕組みとConsumption/Standardの違い・採用判断を解説した記事](https://www.issoh.co.jp/tech/details/15523/)と合わせて読むと、プレイブックのコスト構造まで見通せます。 ## Microsoft Sentinelの料金モデルと無料試用・無料データソースの枠 Sentinelでつまずきやすいのが料金です。土台がLog Analyticsのため、費用は基本的にデータの取り込み量で決まります。ここを設計段階で見積もれるかどうかが、運用コストを左右します。 ### 従量課金とコミットメントレベルという2つの支払い方法の使い分け 分析レベルの支払いには、実際に格納したデータ量に応じて払う従量課金と、あらかじめ日次の取り込み容量を予約するコミットメントレベルの2通りがあります。コミットメントレベルは1日あたり100GBから設定でき、予約分に加えて超過分はその階層の割引適用レートで課金されるため、量が読める環境では従量課金より費用を抑えやすくなります（2026年時点）。引き上げはいつでも可能な一方、引き下げは31日ごとにしか行えないため、まず従量課金で実測し、傾向が見えてからコミットメントレベルへ切り替える進め方が現実的でしょう。コストの適正化には、ログの取捨選択とこの支払い方式の見極めが効きます。 ### 無料試用・無料データソースと低コストなデータレイク層という選択肢 導入初期の検証には無料枠が用意されています。Log AnalyticsワークスペースでSentinelを有効にすると、分析ログプランで取り込んだ最初の10GB/日が31日間無償になり、この枠はテナントあたり20ワークスペースまで適用されます（2026年時点）。加えて、AzureアクティビティログやMicrosoft 365監査ログ、Defender製品群のアラートなど、一部のデータソースは取り込みが無料です。長期保管や低価値の大量ログには、より低コストで保持できるデータレイク層への切り替えも選べます。次の表に主な料金要素を整理します。 | 要素 | 課金の考え方 | 実装者のねらい | | ---------- | ----------- | -------- | | 従量課金 | 取り込み量に比例 | 量が読めない初期 | | コミットメントレベル | 100GB/日から予約 | 量が安定した本番 | | 無料試用 | 10GB/日を31日間 | 導入前の検証 | | データレイク層 | 低コストの長期保持 | 規制対応の保管 | ## Defenderポータルへの統合とAzure portal提供終了 Sentinelを検討するうえで、いま見落とせないのが提供画面の移行です。運用の入口そのものが切り替わるため、導入時期によっては最初からDefenderポータル前提で設計すべき局面になります。 ### 2027年3月31日のAzure portal提供終了とUnified SOCへの一本化 Microsoftは、Microsoft Defenderポータル上でSentinelを一般提供しており、これはDefender XDRやE5ライセンスを持たない利用者も対象です。そして公式ドキュメントでは、2027年3月31日以降、SentinelはAzure portalでサポートされなくなり、Defenderポータルでのみ利用できるようになると案内されています。つまりSIEMのSentinelとXDRのDefenderが、統合セキュリティ操作（Unified SOC）の画面へ一本化される流れです。加えて2025年7月以降は、必要な権限を持つ新規利用者がSentinelを有効化すると、そのワークスペースは自動でDefenderポータルにもオンボードされる挙動になっています。これから新規に導入するなら、Defenderポータルを前提に運用設計を組むのが妥当な判断でしょう。 ### Microsoft Defender製品群との連携で広がる監視範囲 Sentinelは、Microsoft Defender XDRやDefender for Cloudなどのアラートを無料データソースとして取り込め、クラウド基盤の設定リスクまで含めて横断監視できます。クラウド構成のリスク可視化を担うCSPMとの関係を具体的に知りたい場合は、[Microsoft Defender CSPMの仕組みとクラウドセキュリティ管理を解説した記事](https://www.issoh.co.jp/tech/details/8045/)を併読すると、Sentinelが検出の受け皿として何を統合するのかが立体的に見えてくるはずです。監視で扱うログや資格情報の保管そのものには、[Azure Key Vaultによる機密の一元管理を解説した記事](https://www.issoh.co.jp/tech/details/15531/)のようなシークレット管理の設計も絡んできます。 ## Microsoft Sentinelを採用すべき場面と見送るべき場面 ここからは判断です。Sentinelは強力な一方で、真価を発揮する構成と、別の選択が妥当な状況がはっきり分かれます。要件から逆算し、条件付きで採否を言い切ります。 ### Microsoft Sentinelの採用が合理的になる実務上の条件 次のいずれかに該当するなら、Sentinelが第一候補になります。 - Microsoft 365やAzure、Defender製品群を中心に使っており、それらのログを横断監視したい - オンプレミスSIEMのサーバー構築や容量設計の運用負荷を、マネージドサービスへ移したい - 検出だけでなく、プレイブックで初動対応やチケット起票まで自動化したい - 取り込むログ量がある程度読め、コミットメントレベルで費用を計画的に抑えたい いずれもMicrosoft中心の環境ほど連携が効き、無料で取り込めるデータソースの多さがコスト面でも味方します。特に、検出から対応までを一つの基盤で回せる点が、少人数のセキュリティ体制ほど効いてきます。 ### Microsoft Sentinelを選ぶべきでない場面と検討の観点 一方で、次の状況ではSentinelをそのまま当てはめません。第一に、月間のログ取り込み量がまったく読めないまま従量課金で本番投入すると、費用が想定を超えて膨らむおそれがあるため、事前の量見積もりとデータの取捨選択が前提になります。第二に、既存のオンプレミスSIEMへの投資や運用ノウハウが大きい組織では、移行コストと得られる効果を天秤にかける判断が要ります。第三に、監視対象がAWSやGoogle Cloud中心で、Microsoft製品との連携がほとんどない構成なら、各クラウドのネイティブなセキュリティ基盤や他のSIEMも含めて比較したほうが、費用対効果を見極めやすいでしょう。第四に、Defenderポータルへの一本化が進む前提を踏まえ、導入時期に応じて運用画面をどちらに寄せるかを設計初期に決めておく必要があります。 ### 受託開発におけるセキュリティ監視基盤の設計の勘所と外注先への相談 実際のシステムでは、Sentinel単体ではなく、どのログをどのコネクタで取り込み、どの分析ルールで検出し、どこまでプレイブックで自動化するか、そして料金をどの支払い方式で抑えるかを一体で設計する必要があります。取り込み対象と保持期間の設計はそのまま費用に直結し、後からの作り直しには運用の組み替えが伴います。クラウド全体の構成やログ基盤まで含めて監視設計を固めておくほど、導入後の手戻りを避けられる設計です。Azureを含む[クラウドインフラの構築・移行の相談](https://www.issoh.co.jp/service/system/aws/)では、Sentinelを含むログ収集・検出・自動対応の設計から実装・運用までを一貫して支援できます。クラウド全体でどこまで自社が守るかの線引きは、[クラウドセキュリティのリスクと責任共有モデルを解説した記事](https://www.issoh.co.jp/column/details/13266/)も土台になります。 ## よくある質問 Microsoft Sentinelの実装検討でよく挙がる質問を、公式ドキュメントの仕様に沿って整理します。 ### Microsoft SentinelとSentinelOneは同じものですか？ 別の製品です。Microsoft SentinelはMicrosoftのクラウドネイティブSIEM／SOARで、各種ログを集約して脅威を検出・対応する監視基盤にあたります。一方のSentinelOneは別ベンダーのEDR（エンドポイント検出・対応）製品で、守るのは端末側です。名前が似ていますが役割も提供元も異なるため、SIEMを探しているのか端末防御を探しているのかで選ぶ対象が変わります。 ### Microsoft Sentinelの料金はどう決まりますか？ 基本的にはデータの取り込み量で決まります。支払い方法は、格納量に応じた従量課金と、日次容量を予約するコミットメントレベルの2通りです。コミットメントレベルは1日100GBから設定でき、量が安定していれば従量課金より費用を抑えやすくなります。導入初期は、10GB/日を31日間まで無償で試せる無料枠で実測してから、支払い方式を決める進め方が堅実でしょう。 ### SIEMとSOARは何が違いますか？ SIEMはログを集約・相関分析して脅威を「検出する」役割、SOARは検出後の対応を「自動化・調整する」役割です。Sentinelはこの両方を1サービスに束ねており、分析ルールで検出したインシデントに対し、プレイブックで通知や封じ込めを自動実行できます。両者と関連するEDR/XDRの位置づけは、SIEMの解説記事で全体像を確認できます。 ### Azure portalでのSentinelはいつまで使えますか？ 公式ドキュメントでは、2027年3月31日以降はAzure portalでのサポートが終了し、Defenderポータルでのみ利用できるようになると案内されています（2026年時点）。2025年7月以降の新規利用者は、有効化時にDefenderポータルへ自動でオンボードされる挙動になっているため、これから導入するならDefenderポータルを前提に運用設計を組むのが無難です。 ### オンプレミスのログもMicrosoft Sentinelで監視できますか？ できます。共通イベント形式（CEF）やSyslog、REST-APIを使えば、オンプレミスの機器やサービスのログもSentinelへ取り込む形が可能です。取り込んだデータは高度なセキュリティ情報モデル（ASIM）で正規化され、クラウドのログと同じ土俵で相関分析できます。ただし取り込み量に応じて費用が増えるため、監視に効くログを絞る設計が前提になります。 ## 関連記事 - [SIEMとは？仕組み・機能とEDR/XDR/SOARの違い・製品選定を実装視点で解説](/tech/details/13310/)：Sentinelがどの層を担うSIEM製品なのか、全体像から確認できます。 - [Microsoft Defender CSPMとは何か？クラウドセキュリティ管理の新潮流](https://www.issoh.co.jp/tech/details/8045/)：Sentinelが検出の受け皿として統合するDefender側の役割を押さえられます。 - [Azure Logic Appsとは？仕組み・ConsumptionとStandardの違い・料金と採用判断を実装者目線で解説](https://www.issoh.co.jp/tech/details/15523/)：Sentinelのプレイブックの実行基盤とコスト構造を確認できます。 - [Azure Key Vaultとは？シークレット・キー・証明書の一元管理とRBAC・Managed HSMの違いを実装者目線で解説](https://www.issoh.co.jp/tech/details/15531/)：監視で扱う資格情報の安全な保管先として組み合わせられます。 - [クラウドセキュリティとは？リスクと責任共有モデルから見た企業の守り方](https://www.issoh.co.jp/column/details/13266/)：Sentinelをどこまで自社で守るかの線引きの土台になります。 --- 出典: [Microsoft Sentinelとは？クラウドネイティブSIEM/SOARの仕組み・料金モデル・Defenderポータル統合を実装者目線で解説]()（株式会社一創）