Microsoft SentinelでSOCがメール、電話、社内通報、外部システムなどから受け取った情報を調査対象にしたい場合は、Azureポータル上でインシデントを手動作成できます。結論として、2026年5月14日に更新された公式情報では、AzureポータルとLogic Appsによる手動作成はプレビュー、Microsoft Sentinel APIによる作成は一般提供という位置づけです。さらに重要なのは、Microsoft SentinelのAzureポータル提供が2027年3月31日以降サポートされなくなり、Microsoft Defenderポータルへの移行が前提になる点です。(Microsoft Learn)
この機能は、ログやアラートとしてMicrosoft Sentinelに取り込まれていない事象でも、SOCの正式な調査案件として管理できるようにするものです。ただし、手動作成したインシデントは初期状態ではアラートやエンティティを含まないため、通常の検知ルール由来のインシデントと同じ感覚で運用すると、調査漏れやDefenderポータル側での見落としにつながります。(Microsoft Learn)
Microsoft Defender運用で押さえるべき手動インシデント作成の要点
Microsoft Defenderポータルへの統合が進む中で、この機能を見るときのポイントは「インシデントを作れるか」だけではありません。実務上は、どのポータルで見えるのか、どのロールが必要か、既存の自動化やチケット連携に影響が出るかを確認する必要があります。
| 確認項目 | 公式情報での扱い | 実務上の影響 |
|---|---|---|
| Azureポータルでの手動作成 | プレビュー | 仕様変更の可能性を考慮し、運用手順に例外対応を残す |
| Logic Appsでの作成 | プレビュー | フォーム受付や共有メールボックス連携に使えるが、本番運用では監視と失敗時の再実行設計が必要 |
| Microsoft Sentinel APIでの作成 | 一般提供 | 外部SOCシステムやチケットシステムとの連携に向く |
| Defenderポータル移行後の同期 | 手動作成インシデントはDefenderポータルに同期されない | 統合インシデントキューだけを見ているSOCでは見落とす可能性がある |
| Azureポータルの今後 | 2027年3月31日以降、AzureポータルでのMicrosoft Sentinelはサポート終了予定 | Defenderポータル前提の運用設計へ移行が必要 |
Microsoft SentinelはMicrosoft Defenderポータル上でSIEM、SOAR、XDRなどを統合する方向に進んでいます。Defenderポータルでは複数製品のインシデントキューを統合して扱える一方、AzureポータルやAPIで作成した手動インシデントがDefenderポータルに同期されない点は、手動受付を使うSOCほど注意が必要です。(Microsoft Learn)
手動インシデント作成はどんな場面で使うべきか
手動インシデント作成は、検知ルールの代替ではなく、ログ化されていない情報を調査プロセスに乗せるための機能です。自動検知では拾えないが、SOCとして記録・調査・対応履歴を残すべき事象に向いています。
従業員や外部窓口から報告された不審事象
たとえば、従業員が「社名をかたるSMSを個人スマートフォンで受け取った」とSOCに連絡したケースです。個人端末のSMSは組織のログ基盤に取り込まれていないことが多く、通常のMicrosoft Sentinelアラートとしては発生しません。
それでも、社名を悪用したフィッシングキャンペーンの可能性がある場合は、インシデントとして登録し、影響範囲の確認、社内注意喚起、証跡の保管、対応履歴の記録を行う価値があります。Microsoftの公式情報でも、Microsoft Sentinelに取り込まれていない外部情報やログに残っていない事象を調査対象にする用途が示されています。(Microsoft Learn)
Sentinelに接続していない外部システムのイベント
一部のSaaS、オンプレミス機器、社内申請システム、委託先の監視基盤など、まだMicrosoft Sentinelにログ連携していないシステムから重要な通知が届く場合があります。
このようなイベントをメールやチケットだけで管理すると、後から「誰が対応したか」「どの証跡を確認したか」「ほかのアラートと関連したか」を追跡しにくくなります。インシデントとして作成しておくことで、SOCの標準プロセスに乗せやすくなります。
脅威ハンティング中に見つけた別件の兆候
ハンティング中に、本来の調査テーマとは別の不審な通信、アカウント挙動、設定変更の痕跡を見つけることがあります。この場合、既存インシデントに無理に含めるより、別インシデントとして手動作成したほうが調査範囲を明確にできます。
判断基準は、「その事象に独立した調査責任者、深刻度、対応履歴が必要か」です。必要であれば手動インシデント化し、不要であればメモ、ブックマーク、既存チケットで十分な場合もあります。
Azureポータルで手動インシデントを作成する基本手順
Azureポータルで作成する場合は、Microsoft Sentinelのワークスペースを開き、Incidents画面から「Create incident」を選択して作成します。公式情報では、この操作は「Create incident (Preview)」として案内されています。(Microsoft Learn)
| 手順 | 操作 | 実務での注意点 |
|---|---|---|
| 1 | Microsoft Sentinelで対象ワークスペースを選択 | 複数ワークスペース運用では、誤ったワークスペースに作成しないよう確認する |
| 2 | Incidents画面を開く | 既存インシデントと重複していないか先に検索する |
| 3 | Create incidentを選択 | Azureポータル上の手動作成はプレビュー機能であることを理解して使う |
| 4 | タイトル、説明、深刻度、ステータスなどを入力 | 後から検索・引き継ぎできる粒度で書く |
| 5 | Createを選択 | Closedで作成した場合、既定フィルターでは一覧に表示されない可能性がある |
作成後は、通常のインシデントと同じように詳細画面を開き、所有者やステータスの変更、ブックマーク追加などを行えます。一方で、手動作成したインシデントは最初からアラートやエンティティを持っているわけではありません。必要に応じて、既存アラートとの関連付けを別途行う必要があります。(Microsoft Learn)
入力項目は「後で調査できるか」を基準に決める
手動インシデントは、作成時の入力品質がそのまま調査品質に影響します。とりあえず作るだけでは、後から見たアナリストが状況を理解できません。
| 項目 | 必須/任意 | 入力の考え方 |
|---|---|---|
| Title | 必須 | 報告経路、対象、疑いの内容が分かる名前にする |
| Description | 任意 | 発生時刻、報告者、情報源、関係するユーザー・端末・URL・IP、初動対応を記録する |
| Severity | 必須 | 影響範囲と緊急度に基づいて選ぶ。既定値に流されない |
| Status | 必須 | 初動待ちならNew、調査中ならActive、記録目的ならClosedも検討する |
| Owner | 任意 | 放置を防ぐため、可能な限り担当者またはグループを割り当てる |
| Tags | 任意 | 受付経路、キャンペーン名、調査分類などを付ける |
公式情報では、Descriptionは最大5000文字、Severityは既定でMedium、Statusは既定でNewとされています。また、Closedで作成したインシデントは、一覧の既定フィルターがNewまたはActiveのみを表示するため、フィルターを変更しないと見つからない場合があります。(Microsoft Learn)
タイトルの付け方の例
悪い例は「不審メール」「調査依頼」「確認お願いします」のような、対象や状況が分からないタイトルです。インシデントキューで並んだときに判断できず、重複登録も起きやすくなります。
実務では、次のような形式にすると扱いやすくなります。
[受付経路] [対象] [疑いの内容] [日付]
例としては、次のようなタイトルが考えられます。
[社員報告] 社名悪用SMSフィッシング疑い 2026-05-14[外部連絡] 取引先メールアカウント侵害疑い[Hunting] 未承認クラウドストレージへの大量通信疑い
タイトルは検索性を重視し、詳細な背景はDescriptionに書きます。Titleにすべてを詰め込むと、一覧画面で読みにくくなります。
必要な権限とロール
手動インシデント作成では、方法によって必要なロールが異なります。管理者は、機能を有効にする前にSOCメンバー、運用自動化担当、外部連携担当の権限を分けて確認してください。
| 作成方法 | 必要なロール |
|---|---|
| Azureポータル | Microsoft Sentinel Responder または Microsoft Sentinel Contributor |
| Microsoft Sentinel API | Microsoft Sentinel Responder または Microsoft Sentinel Contributor |
| Azure Logic Apps | 上記に加えて、既存Playbookを使う場合はMicrosoft Sentinel Playbook Operator、新規Logic Appを作る場合はLogic App Contributor |
| インシデント削除 | Microsoft Sentinel Contributor |
削除にMicrosoft Sentinel Contributorが必要な点は見落としやすいポイントです。誤登録を訂正する運用を考える場合でも、誰に削除権限を持たせるかは慎重に決める必要があります。安易にContributorを広く付与すると、分析ルールや自動化設定への変更権限も広がり、運用リスクが高まります。(Microsoft Learn)
Logic AppsとAPIを使うべきケース
Azureポータルでの手動作成は、単発のSOC対応には向いています。一方で、同じ受付パターンが繰り返される場合は、Logic AppsやAPIを使った自動化を検討する価値があります。
Logic Appsが向いているケース
Logic Appsは、Microsoft Forms、共有メールボックス、チケット受付などからインシデントを作成する運用に向いています。公式情報でも、Microsoft SentinelコネクタのCreate incidentアクションや、Microsoft Form、共有メールボックスを使ったサンプルPlaybookテンプレートが示されています。(Microsoft Learn)
たとえば、社内の「不審メール報告フォーム」に投稿があったら、以下のように処理できます。
| フォーム項目 | インシデント項目への反映例 |
|---|---|
| 報告者 | Descriptionに記録 |
| 不審メールの受信日時 | Descriptionに記録 |
| 件名・送信元 | TitleまたはDescriptionに記録 |
| 添付URL・IP | Descriptionに記録し、後続調査でエンティティやアラートと関連付ける |
| 緊急度 | Severityの初期値判定に利用 |
ただし、Logic Appsで作成したインシデントもAzureポータル/Logic Appsの手動作成扱いになります。Defenderポータル移行後の可視性を前提に、SOCがどの画面を日常監視するかを決めておく必要があります。
APIが向いているケース
Microsoft Sentinel APIは、外部SOC基盤、チケットシステム、独自ポータルからインシデントを作成・更新・取得・削除する用途に向いています。公式情報では、Incidents操作グループを使ってインシデントの作成、更新、取得、一覧、削除ができるとされています。(Microsoft Learn)
API連携を設計する場合は、少なくとも次の点を確認してください。
| 確認項目 | 理由 |
|---|---|
| incidentIdの採番ルール | 外部システムとの重複や再送時の上書きを避けるため |
| SeverityとStatusのマッピング | チケット側の優先度とSentinel側の深刻度が一致しないことがあるため |
| Ownerの扱い | ユーザーまたはグループ割り当ての失敗時に放置されないようにするため |
| 再送・失敗時の処理 | API失敗時に同じインシデントが重複作成されるのを防ぐため |
| Defenderポータルとの関係 | 手動/API作成インシデントがDefenderポータルに同期されないため |
Defenderポータルの統合インシデントやアラートを扱う自動化では、Microsoft Graph REST APIの利用が推奨される場面があります。一方、Microsoft Sentinelの分析ルールや自動化ルールなどSentinelリソースに対する操作では、Microsoft Sentinel APIが引き続き使われます。既存のSecurityInsights API連携は、Defenderポータル移行後にレスポンス内容や条件判定の見直しが必要になる場合があります。(Microsoft Learn)
Defenderポータル移行時に見落としやすい影響
Microsoft SentinelをMicrosoft Defenderポータルにオンボードすると、SOCの見え方が変わります。Defenderポータルは、Microsoft Defender XDRやMicrosoft Sentinelなどの信号を統合し、単一のインシデントキューで調査しやすくする構成です。(Microsoft Learn)
しかし、手動作成インシデントについては注意が必要です。公式情報では、Microsoft SentinelをDefenderポータルにオンボードした後、Azureポータル、Logic Apps、APIで手動作成されたインシデントはDefenderポータルに同期されないとされています。つまり、Defenderポータルの統合キューだけを見ていると、SOCが手動登録した案件を見落とす可能性があります。(Microsoft Learn)
影響を受けやすい運用
| 運用 | 起こり得る問題 | 対応策 |
|---|---|---|
| 社内通報をForms経由でSentinelインシデント化している | Defenderポータルの統合キューに出ず、担当者が気づかない | 受付チームがAzureポータル/API側の確認手順を維持する |
| ServiceNowなど外部チケットと連携している | インシデントURLや説明項目の扱いが変わる可能性がある | Defender移行後のAPIレスポンスとフィールドマッピングを再確認する |
| 自動化ルールでインシデントタイトルを条件にしている | Defender側の相関処理でインシデント名が変わる可能性がある | タイトルではなく分析ルール名やタグを条件にする |
| Playbookを手動実行している | Defenderポータルで一部の手動実行がサポートされない場合がある | 実行方法と代替手順をRunbookに明記する |
| 複数ワークスペースでXDRデータを扱っている | 期待したワークスペースで自動化が動かない可能性がある | プライマリワークスペースと自動化ルールの配置を確認する |
Defenderポータル移行後は、インシデントのプロバイダー名、アラート相関、インシデント統合、APIフィールド、自動化ルールの条件などが変わる可能性があります。特に、既存の自動化が「インシデント名」「Descriptionフィールド」「ProviderName」などに依存している場合は、移行前に検証環境で動作確認するべきです。(Microsoft Learn)
手動作成インシデントで失敗しやすいポイント
アラートやエンティティが最初から入っていると思い込む
手動作成したインシデントには、初期状態ではアラートもエンティティも含まれません。Alertsタブは空になり、Entitiesタブも空のままです。エンティティを直接追加することも、現時点ではサポートされていません。既存アラートを関連付けた場合、そのアラートに含まれるエンティティが表示されます。(Microsoft Learn)
これは実務上かなり重要です。たとえば、DescriptionにURLやIPアドレスを書いただけでは、通常のエンティティベース調査やタイムライン分析に自動的につながるわけではありません。必要に応じて、関連するアラートを追加する、ブックマークを使う、ハンティング結果を記録するなどの補助作業が必要です。
Closedで作成したインシデントを見失う
記録目的でClosedステータスのインシデントを作成するケースがあります。この場合、既定のインシデントキューフィルターがNewとActiveのみを表示していると、作成したインシデントが見えません。作成に失敗したと勘違いし、重複作成してしまうことがあります。(Microsoft Learn)
Closedで登録する運用を許可するなら、手順書に「作成後にClosedも表示するフィルターへ切り替えて確認する」と明記しておきましょう。
タグ設計を決めずに使い始める
Tagsは便利ですが、自由入力のため表記ゆれが起きやすい項目です。たとえば、同じ意味でも「phishing」「フィッシング」「Phishing」「sms-phish」のように分かれると、後から集計できません。
最初に、最低限のタグルールを決めておくと運用しやすくなります。
| 用途 | タグ例 |
|---|---|
| 受付経路 | employee-report, shared-mailbox, microsoft-form |
| 事象分類 | phishing, suspicious-login, data-leak |
| 調査起点 | hunting, external-intel, partner-report |
| 優先対応 | executive-impact, active-campaign, customer-impact |
タグは多すぎると逆に使われなくなります。最初は受付経路と事象分類だけに絞り、運用が定着してから増やすのがおすすめです。
既存インシデントとの重複を確認しない
手動作成前に、同じユーザー、同じURL、同じ送信元、同じ端末に関する既存インシデントがないか確認してください。重複して作ると、証跡やコメントが分散し、対応状況が分からなくなります。
重複しそうな場合は、次の順に判断します。
| 判断 | 対応 |
|---|---|
| 既存インシデントと同じ攻撃キャンペーン | 既存インシデントに情報を追記する |
| 既存インシデントと関連するが調査責任者が異なる | 既存インシデントを参照しつつ別インシデントを作る |
| 完全に別事象 | 新規インシデントを作る |
| 判断できない | 仮作成せず、既存インシデントの所有者に確認する |
関連するアラートをインシデントに追加する機能もあります。公式情報では、手動または自動で既存インシデントにアラートを追加・削除でき、手動作成インシデントにアラートを追加してカスタム相関に使う例も示されています。ただし、1つのインシデントに含められるアラート数には上限があるため、大規模キャンペーンでは分割方針も必要です。(Microsoft Learn)
管理者が確認すべき設定
管理者は、機能そのものよりも「SOCの運用に組み込めるか」を確認してください。特に、Microsoft Defenderポータルへの移行を進めている組織では、手動作成したインシデントの監視場所を明確にすることが重要です。
| 確認項目 | チェック内容 |
|---|---|
| ポータル運用 | AzureポータルとDefenderポータルのどちらを日常監視するか決めているか |
| 移行計画 | 2027年3月31日以降のAzureポータル非サポートを前提に計画しているか |
| ロール | Responder、Contributor、Playbook Operator、Logic App Contributorの付与範囲が適切か |
| 削除権限 | 誤登録の削除を誰が行うか決まっているか |
| フィルター | Closedインシデントを確認する手順があるか |
| タグ | 受付経路や事象分類のタグ命名ルールがあるか |
| 手動受付 | 電話、メール、Forms、チケットなどの入口が整理されているか |
| 既存インシデント確認 | 新規作成前に重複確認する手順があるか |
| Defender移行後の可視性 | 手動作成インシデントがDefenderポータルに同期されない点をSOCが理解しているか |
開発者・自動化担当が確認すべきポイント
開発者や自動化担当は、APIやLogic Appsで作成できることだけでなく、失敗時の挙動、二重登録、フィールドマッピング、Defenderポータル移行後の差分を確認してください。
| 確認項目 | 実装時の注意点 |
|---|---|
| 冪等性 | 同じ受付データを再送したときに重複インシデントを作らない |
| 入力値検証 | TitleやDescriptionに空値、過剰な文字列、機密情報が入らないようにする |
| Severity変換 | 外部チケットの優先度をSentinelのSeverityへ機械的に変換しすぎない |
| Owner設定 | 担当者が見つからない場合のフォールバックグループを決める |
| Tags設定 | 表記ゆれを避けるため、選択式またはマッピング式にする |
| APIレスポンス | Defender移行後に利用フィールドが変わらないか検証する |
| エラー処理 | API失敗時の再試行、通知、手動復旧手順を用意する |
| 監査性 | 誰が、どの受付情報をもとに、いつ作成したかをDescriptionや外部ログに残す |
Defenderポータル移行後は、Microsoft Defender XDRの相関エンジンがインシデント統合に関与します。そのため、自動化条件をインシデントタイトルに強く依存させるのは避け、分析ルール名、タグ、受付経路など、運用上コントロールしやすい条件を使うほうが安全です。(Microsoft Learn)
実務で使える運用例
社員からSMSフィッシング報告を受けた場合
社員から「会社名をかたるSMSが届いた」とSOCにメールが来た場合、次のように処理します。
| 項目 | 入力例 |
|---|---|
| Title | [社員報告] 社名悪用SMSフィッシング疑い 2026-05-14 |
| Description | 報告者、受信日時、SMS本文の要約、URL、送信元番号、報告経路、初動対応を記録 |
| Severity | 複数報告がある、認証情報入力ページがある、役員や多数社員に影響する場合は高めに設定 |
| Status | 初動調査前ならNew、調査開始済みならActive |
| Owner | フィッシング対応担当またはSOC一次対応グループ |
| Tags | employee-report, sms-phishing, brand-abuse |
この時点では、インシデントにアラートやエンティティは入りません。URLクリック、プロキシログ、メールログ、Defender for Endpointの端末挙動などから関連アラートが見つかった場合は、インシデントに関連付けて調査範囲を広げます。
共有メールボックスへの通報を自動受付する場合
社内に「[email protected]」のような共有メールボックスがあり、不審メールや不審アクセスの報告が集まる場合は、Logic Appsで受付を自動化できます。
運用イメージは次の通りです。
| 処理 | 内容 |
|---|---|
| 受信 | 共有メールボックスに通報が届く |
| 抽出 | 件名、本文、送信者、添付情報を取得 |
| 判定 | 件名や本文からフィッシング、マルウェア、不審ログインなどを分類 |
| 作成 | Microsoft Sentinelにインシデントを作成 |
| 通知 | TeamsやメールでSOCに通知 |
| 記録 | 外部チケット番号や受付IDをDescriptionまたはタグに残す |
この構成は便利ですが、自動作成されたインシデントがDefenderポータルに同期されない点を前提に、SOCの監視手順を分けておく必要があります。Defenderポータルだけを見て対応するチームと、Azureポータル/API側の手動受付を扱うチームが分断されると、対応漏れが起きます。
導入前に決めておくべき運用ルール
手動インシデント作成は、自由度が高い分、ルールなしで使うと品質がばらつきます。導入前に、次の項目を最低限決めておきましょう。
| ルール | 決める内容 |
|---|---|
| 作成基準 | どのレベルの通報・外部情報をインシデント化するか |
| 命名規則 | Titleの形式、日付、受付経路の書き方 |
| Descriptionテンプレート | 報告者、発生時刻、対象、証跡、初動対応、関連チケット番号 |
| Severity基準 | Low、Medium、High、Informationalの判断基準 |
| Owner割り当て | 業務時間内、夜間休日、専門チームへの引き継ぎ方法 |
| Tags | 受付経路、事象分類、キャンペーン識別子 |
| 重複確認 | 作成前に検索する項目 |
| Defender移行後の確認場所 | Azureポータル/API側の手動インシデントを誰が見るか |
| 自動化の失敗時対応 | Logic AppsやAPI失敗時の通知先と手動復旧手順 |
特に、Severity基準は曖昧にしないことが重要です。すべてMediumで作る運用にすると、優先順位が付かなくなります。逆に、少しでも不審ならHighにすると、アラート疲れが起きます。影響範囲、悪用可能性、進行中かどうか、機密情報への関与を基準に段階化してください。
まず取るべき対応
Microsoft Sentinelで手動インシデント作成を使う組織は、まず現在のSOC運用を棚卸ししてください。社員通報、外部システム通知、ハンティング結果、チケット連携のうち、どれをMicrosoft Sentinelのインシデントとして扱うべきかを決めることが出発点です。
次に、Azureポータル、Logic Apps、APIのどれで作成するかを用途別に分けます。単発対応はAzureポータル、定型受付はLogic Apps、外部システム連携はAPIが基本です。そのうえで、Microsoft Defenderポータル移行後に手動作成インシデントが同期されない点をSOCの手順に反映します。
最後に、Title、Description、Severity、Status、Owner、Tagsの入力ルールを作り、既存インシデント確認とアラート関連付けの手順を定めてください。手動インシデント作成は、検知できなかった事象を拾うための補助機能ではなく、SOCが「人から受け取った重要情報」を正式な調査プロセスに乗せるための実務的な仕組みです。
コメント