MENU

Microsoft Sentinel ASIMパーサーをVS CodeとCopilot CLIで生成・検証する手順

Azure

独自ログ向けのASIMパーサーを正しいスキーマで作成し、Log Analytics上で検証してAzure-SentinelリポジトリへのPR素材まで整えるには、Microsoftが公開した「ASIM Parser Creation Agentic Experience」を利用するのが効率的です。2026年7月時点では、Microsoft SentinelのVS Code拡張機能またはGitHub Copilot CLIから共通のAgent Skillsを呼び出し、要件収集、KQL生成、検証、修正、任意のワークスペース展開、PRパッケージ化までを一連の流れで進められます。(TECHCOMMUNITY.MICROSOFT.COM)

ただし、Copilotが生成したKQLをそのまま本番採用する仕組みではありません。Azure-SentinelリポジトリのREADMEでも、Agent Skillsは作成を高速化するものであり、セキュリティレビューや本番ガバナンスの代替ではないと説明されています。最終的には、フィールドマッピング、列の型、列挙値、フィルター動作、Git差分を人が確認する必要があります。(GitHub)

この記事では、環境準備からparameterless parserとparameterized parserの生成、ASimSchemaTesterとASimDataTesterによる検証、Log Analyticsへの展開、Azure-Sentinel向けPRパッケージの作成までを、実務で迷いやすい点も含めて解説します。

ITtripTOOLS
その「面倒」、無料で解決。 ITtripがつくる、6つの道具。 無料ツール一覧へ すべて無料・追加課金なし
先頭0を守るCSV編集こわさないCSV PDFに直接書き込みかけるPDF 写真＋説明をPDFに写レポ スマホ⇄PCで共有コピペ便 · 文章・写真 みんなの日程を調整日程Fit 匿名質問・投票を集めるKOEQ
目次

まず押さえるべき結論：ASIMパーサーは2種類作成する

ASIM Parser Creation Agentic Experienceでは、基本的に次の2種類のソース固有パーサーを作成します。

種類主な役割生成ファイル名
parameterless parserソースログをASIMスキーマへ正規化する基本パーサーASim<Schema><Vendor><Product>.kql
parameterized parser時刻、IPアドレス、ホスト名などのフィルターパラメーターを受け取り、処理対象を早い段階で絞り込むパーサーvim<Schema><Vendor><Product>.kql

最初にparameterless parserを作成してスキーマとデータを検証し、その成果物を基にparameterized parserを生成します。parameterized parserには、対象ASIMスキーマで定義されているフィルターパラメーターを追加し、通常のスキーマ・データ検証に加えてフィルター動作もテストします。(Microsoft Learn)

parameterless parserは「引数が一切ない」とは限らない

ASIMにおけるparameterless parserは、スキーマ固有の検索フィルターパラメーターを持たないパーサーを意味します。Agent Skillの仕様では、parameterless parserにも次の運用用パラメーターが含まれることがあります。

  • disabled: bool = false
  • pack: bool = false。ただし、AdditionalFieldsを使用するときのみ

そのため、ASim...ファイルに関数引数が記述されていても、直ちに生成ミスとは判断できません。disabledはパーサーを無効化するため、packは不要なAdditionalFieldsの生成コストを抑えるための引数です。(GitHub)

ローカルファイル名と組み込みパーサー名を混同しない

作成時のローカルファイルはASim...とvim...という名前です。一方、Microsoft Sentinelの組み込みASIMパーサーでは、フィルター対応パーサーに_Im_、パラメーターなしの互換パーサーに_ASim_という命名体系が使われます。

つまり、次の3つは別の概念です。

  • ローカルで編集する.kqlファイル名
  • Log Analyticsへ展開する保存済み関数のエイリアス
  • Microsoft Sentinelに組み込まれたASIMパーサー名

命名を取り違えると、PR内のParserNameやEquivalentBuiltInParser、統合パーサーへの追加内容を誤るため注意してください。(Microsoft Learn)

ASIM Parser Creation Agentic Experienceで自動化される範囲

中心となるのは、asim-parser-creator-orchestratorというオーケストレータースキルです。オーケストレーターが、目的別に分割されたスキルを順番に呼び出します。

Agent Skill処理内容
asim-parser-user-prompterソースドキュメント、テーブル名、Workspace ID、対象スキーマを収集
asim-parser-create-parserparameterless parserを生成
asim-parser-validatorスキーマ検証とデータ検証を実行
asim-parser-create-parameter-parserparameterized parserを生成
asim-parser-filter-validatorフィルターパラメーターを検証
asim-parser-la-deployerLog Analyticsへ展開
asim-parser-github-pr-packagerAzure-Sentinel向けPR素材を生成
log-analytics-workspace-queryerワークスペースに対してKQLを実行

VS Code拡張機能とGitHub Copilot CLIでは、同じASIM Agent Skillsと同じオーケストレーションが使われます。違いは主に操作画面であり、生成・検証フローそのものは共通です。(Microsoft Learn)

公式上の位置づけ

Agent SkillsはAzure-Sentinelリポジトリで公開され、Microsoft Learnにも実行手順が掲載されています。一方、生成物にはKQL、ARMテンプレート、サンプルデータ、Git変更が含まれるため、運用環境へ反映する前に必ず人がレビューしてください。

実行前に準備するもの

必要な環境

公式手順では、次の環境が必要です。

  • 有効なMicrosoft Sentinelワークスペース
  • Log Analyticsワークスペースへのクエリアクセス
  • PowerShell 7
  • Azure CLI
  • Azure-Sentinelリポジトリのローカルクローン
  • PRを提出する場合はAzure-Sentinelリポジトリのフォーク
  • GitHub Copilot CLI、またはMicrosoft Sentinel for Visual Studio Code拡張機能
  • Gitによるブランチ作成、コミット、プッシュができる環境

Log Analyticsへパーサーを展開する場合は、クエリ権限だけでなく、対象リソースグループへARMデプロイを実行できる権限も必要です。(Microsoft Learn)

Azureの認証状態を確認する

PowerShell 7を開き、使用するテナントとサブスクリプションでAzure CLIへサインインします。

az login
az account show

複数のサブスクリプションを利用している場合は、対象を明示的に切り替えます。

az account list -o table
az account set --subscription "<Subscription ID>"
az account show

オーケストレーターも最初にaz account showを実行します。認証されていない場合は、後続のテーブル確認、データサンプリング、検証、展開を開始できません。(GitHub)

Workspace IDを確認する

ここで必要なWorkspace IDは、Log AnalyticsワークスペースのcustomerIdとして取得できるGUIDです。ARMリソースIDと混同しないようにしてください。

az monitor log-analytics workspace list `
  --query "[].{Name:name,ResourceGroup:resourceGroup,WorkspaceId:customerId,Location:location}" `
  -o table

複数のワークスペースがある場合は、ソーステーブルが実際に存在するワークスペースを選びます。Agent Skillは受け取ったWorkspace IDとテーブル名を使ってクエリを実行し、入力が正しいか検証します。(GitHub)

Azure-Sentinelリポジトリをフォークしてクローンする

PR提出を予定している場合は、Azure-Sentinelを自分のGitHubアカウントへフォークしてからクローンします。

git clone https://github.com/<GitHubユーザー名>/Azure-Sentinel.git
cd Azure-Sentinel

git remote add upstream https://github.com/Azure/Azure-Sentinel.git
git remote -v

既にクローン済みの場合も、originが自分のフォーク、upstreamがMicrosoftの公開リポジトリを指しているか確認してください。

git remote -v
git fetch upstream
git remote set-head upstream -a

Agent SkillはPRパッケージ化の前に、ローカルリポジトリとプッシュ可能なGitリモートが存在するか確認します。(Microsoft Learn)

Agentへ渡す4つの入力情報

生成を始める前に、次の情報を用意します。

入力情報内容確認ポイント
ソースドキュメントベンダー公式のログ仕様、フィールド仕様、イベント形式イベント種別、列挙値、日時形式が分かるか
ソーステーブル名Microsoft Sentinelに取り込まれたテーブル実際にデータが入っているか
Workspace IDLog AnalyticsワークスペースのGUIDARMリソースIDではないか
対象ASIMスキーマ正規化先のASIMスキーマ1テーブルに複数種類のイベントが混在していないか

ASIMパーサーの品質は、入力するログの代表性に大きく左右されます。正常・失敗、許可・拒否、異なるユーザー名形式、ホスト名形式、ID形式など、正規化条件が変わるログを含めることが重要です。(Microsoft Learn)

1つのテーブルが複数スキーマに該当する場合

例えば、1つのカスタムテーブルに認証イベントと監査イベントが混在している場合、無理に1つのASIMパーサーへまとめない方が安全です。

次の単位に分割します。

  • 対象ASIMスキーマごと
  • ログ形式ごと
  • 製品またはイベントファミリーごと

ASIMの手動開発手順でも、ソースに関連するスキーマごとにparameterless parserとfiltering parserを作成することが示されています。(Microsoft Learn)

VS CodeとGitHub Copilot CLIのどちらを使うか

実行方法向いているケース特徴
Microsoft Sentinel VS Code extension生成されたKQLやYAMLを画面上で確認しながら進めたいファイル編集、差分確認、Copilot Chatを同じ画面で操作できる
GitHub Copilot CLIPowerShellとGitを中心に作業したいリポジトリのルートから対話セッションを開始できる

どちらを選んでもAgent Skillsの処理内容は同じです。最初の検証ではVS Code、繰り返し作業やターミナル中心の環境ではCopilot CLIが扱いやすいでしょう。(Microsoft Learn)

Microsoft Sentinel VS Code extensionから開始する手順

拡張機能をインストールする

VS Codeの拡張機能画面で「Microsoft Sentinel」を検索し、Microsoft提供の拡張機能をインストールします。

拡張機能では、ASIMパーサーの作成だけでなく、Microsoft Sentinelのデータレイク探索、ノートブック、カスタムグラフ、コネクター開発なども扱えます。ASIMパーサーでは、Copilot Chatから組み込みAgent Skillsを呼び出します。([Visual Studio Marketplace][9])

クローンしたリポジトリを開く

VS Codeで自分のAzure-Sentinelフォークを開きます。

code .

Microsoft Sentinelへアクセスするアカウントで拡張機能へサインインし、Copilot Chatが利用できることも確認します。組織でGitHub CopilotのモデルやAgent機能が制限されている場合は、管理ポリシーも確認してください。

Copilot Chatから生成を依頼する

現行の公式手順では、利用可能であればClaude Sonnet 4.6以降またはClaude Opus 4.6以降が推奨されています。これは必須条件ではありませんが、複雑なKQLマッピングを扱うため、利用できる中で高性能なモデルを選ぶ方が安全です。(Microsoft Learn)

最小の開始プロンプトは次のとおりです。

Create an ASIM parser for me.

必要な情報を最初からまとめて渡す場合は、次の形式が実用的です。

Use the asim-parser-creator-orchestrator skill.

Create an ASIM parser with the following requirements:

Source documentation:
<ベンダー公式ドキュメント>

Source table:
<テーブル名>

Log Analytics workspace ID:
<Workspace ID>

Target ASIM schema:
<スキーマ名>

Event vendor:
<ベンダー名>

Event product:
<製品名>

Create and validate both the parameterless parser and the parameterized parser.
After validation, deploy both parsers to the test workspace and package the changes for an Azure-Sentinel pull request.

GitHub Copilot CLIから開始する手順

Azure-SentinelリポジトリのREADMEでは、Copilot CLIのインストール例として次のコマンドが案内されています。インストール方法は更新される可能性があるため、実行時にはGitHubの現行ドキュメントも確認してください。(GitHub)

npm install -g @github/copilot

PowerShell 7でAzure-Sentinelリポジトリのルートへ移動し、Copilot CLIを起動します。

cd <Azure-Sentinelのローカルパス>
copilot

リポジトリのルートで起動すると、リポジトリ内のSkillsが事前に読み込まれます。ASIM Skillsが表示されない場合は、セッション内で次を実行します。

/skills list
/skills add .github/skills/

モデルを選択してから、生成を依頼します。

/model
Create an ASIM parser for me.

より確実にオーケストレーターを呼びたい場合は、次のようにスキル名を明示します。

Use the asim-parser-creator-orchestrator skill to create a new ASIM parser.

Copilot CLIの公式フローでは、PowerShell 7、リポジトリルートからの起動、必要に応じた/skills add、モデル選択、作成プロンプトの順で進めます。(Microsoft Learn)

独自ログ向けASIMパーサーを生成・検証する手順

要件を収集して対象スキーマを確定する

オーケストレーターは、最初に次の内容を確認します。

  1. Azure CLIにサインインしているか
  2. Workspace IDが有効か
  3. ソーステーブルが存在するか
  4. テーブルへクエリを実行できるか
  5. ソースログがどのASIMスキーマに該当するか
  6. EventVendorとEventProductをどの名称にするか

対象スキーマをAgent任せにせず、候補を人が確認することが重要です。ファイアウォール製品であっても、すべてのログがNetworkSessionとは限りません。DNSログはDns、WebプロキシログはWebSession、管理操作ログはAuditEventに該当する場合があります。

スキーマを誤ると、必須フィールド不足、列挙値不一致、フィルターパラメーター不整合が大量に発生します。5回の修正ループを超えてエラーが残る場合は、KQLの細かな修正より先に対象スキーマを再確認してください。(GitHub)

parameterless parserを生成する

asim-parser-create-parserは、Log Analytics上のソーステーブルに対して次の処理を行います。

  • getschemaで列名とデータ型を取得
  • 行数を確認
  • 最大2,000行をサンプリング
  • 主要列の値や形式を分析
  • ソース列をASIMフィールドへマッピング
  • KQL構文エラーがないか実行確認
  • ASim<Schema><Vendor><Product>.kqlとして保存

Microsoft Learnの現行フローでは、サンプルデータを基にsplit、parse-kv、parseなどの比較的高性能な演算子を使って初期パーサーを構築すると説明されています。(Microsoft Learn)

生成されたKQLで確認するポイント

AgentがKQLを生成した後は、少なくとも次の項目を確認します。

Filter、Parse、Mapの順になっているか

パーサーは、概ね次の順序で処理されている必要があります。

Filter → Parse → Map / Prepare fields

対象外のレコードを先に除外し、残ったデータだけを解析してASIMフィールドへ変換します。文字列を解析してからフィルターすると、不要な行にも重い処理がかかります。(GitHub)

元の物理列で早期フィルターしているか

Syslogや共有カスタムテーブルでは、異なる製品やイベント種別が混在することがあります。解析前に、製品名、イベントID、ログ種別などのネイティブ列を使って対象行を絞り込みます。

固定された時間範囲をparameterless parserへ直接埋め込むのは避けます。時刻条件は、呼び出し元クエリまたはparameterized parserのstarttime、endtimeなどで制御します。(Microsoft Learn)

正規表現へ依存しすぎていないか

Agent Skillでは、主に次の優先順位で解析演算子を選ぶよう定義されています。

  1. split
  2. parse-kv
  3. parse_csv
  4. parseまたはparse-where
  5. extract_all
  6. extract
  7. parse_json
  8. parse_xml

ログ形式に適した演算子を選び、単純な区切り文字ログを複雑な正規表現で解析していないか確認してください。(GitHub)

マッピングと値の正規化が分離されているか

直接的な列名変更にはproject-rename、計算値や正規化値の生成にはextendを使うと、処理意図が明確になります。

元ログの値をそのままASIMの列挙型フィールドへ入れるのではなく、caseやiffを使って許可された値へ変換します。元の値を残す必要がある場合は、EventOriginalResultDetailsなどの原値保持用フィールドを使用します。(GitHub)

最終出力をprojectで固定しているか

未使用列を削除するためにproject-awayを多用すると、ソーステーブルに新しい列が追加された際、意図しない列が残る可能性があります。Agent Skillでは、最終出力をprojectで明示することが推奨されています。

また、出力にはソーステーブルを示すType列が必要です。(GitHub)

ASimSchemaTesterでスキーマを検証する

parameterless parserの生成後、asim-parser-validatorがASimSchemaTesterを実行します。主な検証対象は次のとおりです。

  • 必須列が存在するか
  • 列名がASIMスキーマと一致するか
  • データ型が一致するか
  • 必要なエイリアスが存在するか
  • ASIMに定義されていない余分な列が残っていないか

テスト関数がワークスペースに存在しない場合、Agent SkillはASimSchemaTesterとASimDataTesterのARMテンプレートを取得し、対象ワークスペースへ展開してから検証します。(GitHub)

スキーマ検証結果の判断基準

重要度意味対応
(0) Error必須列不足、型不一致、必須エイリアス不足など次工程へ進む前に修正
(1) Warning推奨フィールド不足などソースに値があれば修正。値がなければ理由を記録
(2) Info任意フィールド不足、余分な未正規化列など余分な列は修正。任意フィールド不足は必要に応じて許容

extra unnormalized columnが出た場合は、単なる情報メッセージとして放置せず、最終projectから余分な列を除外します。その他の任意フィールドや任意エイリアスに関するInfoは、ソースに値が存在しなければ無理に生成する必要はありません。(GitHub)

ASimDataTesterで値を検証する

スキーマが正しくても、各列の値が正規化ルールに違反している可能性があります。ASimDataTesterでは、最大1,000行程度を対象に次の内容を検証します。

  • 列挙値がASIMで許可された値か
  • IPアドレス列に有効なIPアドレスが入っているか
  • 日時、数値、文字列などの型と形式が適切か
  • 正規化値と元データの対応が妥当か

例えば、ソースログの結果がallowed、blocked、droppedであっても、対象ASIMフィールドが要求する値へ変換しなければData Testerでエラーになります。値を無理に定数化するのではなく、ベンダー仕様を確認したうえで変換規則を作成してください。(GitHub)

修正と再検証を繰り返す

オーケストレーターは、次のサイクルを繰り返します。

  1. 検証エラーを分析
  2. .kqlファイルを修正
  3. ASimSchemaTesterを再実行
  4. ASimDataTesterを再実行
  5. Errorレベルが残っていないか確認

終了条件は、両方の検証で(0) Errorが0件になることです。5回修正してもErrorが残る場合、Agentは自動修正を止め、残存エラーを人へ提示します。(GitHub)

5回を超えて自動修正を続けるより、次を再確認した方が早く解決できます。

  • 対象ASIMスキーマが正しいか
  • ソースドキュメントが現行バージョンか
  • 代表的なログが不足していないか
  • 必須フィールドに対応する情報が本当に存在するか
  • 1つのパーサーへ複数のイベント種別を詰め込んでいないか

parameterized parserを生成する

parameterless parserが検証を通過すると、asim-parser-create-parameter-parserが次のファイルを生成します。

vim<Schema><Vendor><Product>.kql

このパーサーには、対象スキーマで定義されたフィルターパラメーターが追加されます。代表例は次のとおりです。

  • 開始日時と終了日時
  • 送信元または宛先IPアドレス
  • ホスト名
  • ユーザー名
  • イベント種別
  • 複数値を受け取るdynamic型パラメーター
  • 前方一致用のプレフィックスパラメーター

実際の引数はASIMスキーマごとに異なります。別スキーマのparameterized parserから引数をコピーせず、対象スキーマの現行定義に合わせてください。(GitHub)

生成後は、parameterized parserに対してもASimSchemaTesterとASimDataTesterを実行します。パラメーター追加によって出力列の型や値が変わっていないことを確認するためです。

フィルターパラメーターを検証する

asim-parser-filter-validatorはPowerShell 7とAzure CLIを使い、関数シグネチャに定義された各フィルターを検証します。

主なテスト内容は次のとおりです。

  • disabled=trueで0行になるか
  • disabled=falseでデータが返るか
  • 日時条件で対象行が適切に減るか
  • 実在する文字列や数値で絞り込めるか
  • 存在しない値で0行になるか
  • *_has_anyや*_has_allなどの複数値条件が動くか
  • プレフィックス条件が正しく機能するか

フィルターテストは、単にKQLが実行できるかではなく、引数が実際に結果へ反映されているかを確認します。(GitHub)

フィルターテスト失敗を許容できるケース

次の場合は、パーサー不具合ではなくテストデータの制約で失敗することがあります。

  • 対象フィールドが設計上1種類の定数値しか持たない
  • テスト対象期間に十分な異なる値が存在しない
  • ASIMスキーマ側に既知の例外が定義されている
  • 直近2日間に対象テーブルのデータがない

ただし、「データが少ないから」という理由だけで一括して無視してはいけません。失敗したパラメーターごとに、定数値、データ不足、スキーマ例外のどれに該当するかを記録します。(GitHub)

Log Analyticsへパーサーを展開する

両方のパーサーが検証を通過した後、オーケストレーターから展開を選択できます。

asim-parser-la-deployerは、KQLをARMテンプレートへ埋め込むため、次の文字をエスケープします。

  • バックスラッシュ
  • ダブルクォート
  • 改行
  • タブ

その後、次の形式のコマンドでARMデプロイを実行します。

az deployment group create `
  --resource-group "<Resource Group>" `
  --template-file "<ARMテンプレート>" `
  --parameters Workspace="<Workspace Name>" WorkspaceRegion="<Location>"

parameterless parserとparameterized parserは保存済み関数として個別に展開されます。展開後は、それぞれの関数を直接呼び出して結果を確認します。(GitHub)

ASim<Schema><Vendor><Product>()
| take 10
vim<Schema><Vendor><Product>()
| take 10

実際の関数引数は生成されたシグネチャに合わせてください。

展開しただけでは統合パーサーに自動参加しない場合がある

個別パーサーが正常に動作しても、既存の統合パーサーから自動的に呼び出されるとは限りません。

次の2点を分けて確認します。

  1. 作成したソース固有パーサーを直接呼び出せるか
  2. 対象スキーマの統合パーサーを呼び出したときにも、新しいログが含まれるか

ASIMの手動開発フローでは、個別パーサーの展開後に、関連する統合パーサーへ新しいパーサーを追加する工程が別途示されています。PRパッケージ化では統合パーサーのYAMLも更新されますが、個別ワークスペースへの展開では、必要に応じてカスタム統合パーサーの構成も確認してください。(Microsoft Learn)

一時ARMテンプレートを残し続けない

展開用ARMテンプレートにはKQL全文が埋め込まれます。不要になった一時ファイルは削除し、ソース管理へ含める必要がある正式な成果物だけを残します。

トークン、パスワード、APIキーをCopilot Chatへ貼り付けないことも重要です。認証情報はターミナルや安全な資格情報管理機能から入力してください。(GitHub)

Azure-Sentinel向けPRをパッケージ化する

PR化を選択すると、asim-parser-github-pr-packagerがローカル.kqlファイルをそのまま提出するのではなく、Azure-Sentinelリポジトリの構成に合わせて複数の成果物へ変換します。

作成・更新される主なファイル

成果物主な配置先
parameterless parserのYAMLParsers/ASim/Parsers/
parameterized parserのYAMLParsers/ASim/Parsers/
各パーサーのCHANGELOGParsers/ASim/CHANGELOG/
統合パーサーの更新Parsers/ASim/Parsers/
統合パーサーのCHANGELOG更新Parsers/ASim/CHANGELOG/
カスタムテーブル定義.script/tests/KqlvalidationsTests/CustomTables/
匿名化されたサンプルデータSample Data/ASIM/
生成されたARMテンプレートリポジトリ内の対応する生成先

PRパッケージには、単体パーサーだけでなく、統合パーサーへの追加、CHANGELOG、テスト用テーブル定義、サンプルデータ、ARMテンプレート生成まで含まれます。(GitHub)

作業ブランチを作成する

Agent Skillでは、次のような命名形式が使われます。

asim/<schema>-<vendor>-<product>

例は次のとおりです。

asim/networksession-contoso-edgefirewall

最新のupstream既定ブランチから作成します。

git fetch upstream
git remote set-head upstream -a
git switch -c asim/networksession-contoso-edgefirewall upstream/HEAD

既にAgentがブランチを作成している場合は、新しいブランチを重ねて作らず、現在の状態を確認してください。

git branch --show-current
git status

YAMLのスキーマ参照を確認する

パーサーYAMLのスキーマ参照には、任意のMicrosoft Learn URLを貼り付けるのではなく、リポジトリ内の次のテストコードに定義された正確なSchemaTitleとSchemaLinkを使います。

.script/tests/asimParsersTest/VerifyASimParserTemplate.py

Agent Skillは、スキーマ固有のaka.msリンクを使用するよう明示しています。リンクやSchemaTitleが違うと、内容が正しくてもリポジトリの自動検証に失敗する可能性があります。(GitHub)

カスタムテーブル定義を追加する

ソーステーブルが次のディレクトリに存在しない場合は、KQL検証用のテーブルスキーマJSONを作成します。

.script/tests/KqlvalidationsTests/CustomTables/

JSONにはソーステーブルの列名と型を定義します。

{
  "Name": "VendorLogs_CL",
  "Properties": [
    {
      "name": "TimeGenerated",
      "type": "datetime"
    },
    {
      "name": "RawData",
      "type": "string"
    }
  ]
}

列名と型は、実際のテーブルに対してgetschemaを実行した結果と一致させます。

サンプルデータを作成する

PRパッケージでは、次の形式でCSVを作成します。

<EventVendor>_<EventProduct>_<ASIMSchema>_IngestedLogs.csv

配置先は次のとおりです。

Sample Data/ASIM/

Agent Skillでは10行のサンプルを生成し、ソーステーブルに存在する全列を含めるよう定義されています。列挙値を解析するパーサーでは、主要な分岐を通る値も含めます。(GitHub)

サンプルデータには、次の情報を入れないでください。

  • 実在するユーザー名
  • 実在するメールアドレス
  • 実在するホスト名
  • 実在組織を特定できるドメイン
  • 本物の外部IPアドレス
  • トークンやシークレット
  • インシデント固有の識別情報

検証に必要な構造と値の種類は維持しつつ、内容は合成データへ置き換えます。

ARMテンプレートを生成する

リポジトリのルートで、次のPowerShellスクリプトを実行します。

.\.script\kqlFuncYaml2Arm.ps1

このスクリプトにより、追加したパーサーと更新した統合パーサーのARMテンプレートが生成されます。Agent Skillでは、スクリプト実行によって既存ファイルが削除されていないことも確認するよう定義されています。(GitHub)

実行後は、意図しない大量変更がないか確認します。

git status
git diff --stat
git diff --check

PR提出前に差分をレビューする

最低限、次を確認します。

git status
git diff --check
git diff

特に確認すべき内容は次のとおりです。

  • 2種類のパーサーYAMLがあるか
  • EventVendorとEventProductの表記が一致しているか
  • parser versionとLastUpdatedが更新されているか
  • 統合パーサーへ正しい関数呼び出しが追加されているか
  • parameterized parserへ必要な引数が渡されているか
  • CHANGELOGが更新されているか
  • カスタムテーブルの列名と型が正しいか
  • サンプルCSVが匿名化されているか
  • ARM生成後に無関係なファイルが削除されていないか
  • 一時的な展開用ファイルや実ログが混入していないか

ブランチをプッシュしてPRを作成する

PR packagerは、ローカルブランチへのファイル追加とコミットまでを中心に処理します。GitHubの認証状態やリモート権限によっては、リモートへのプッシュとPR作成を手動で行う必要があります。

git push -u origin asim/networksession-contoso-edgefirewall

GitHubのWeb画面からAzure-SentinelリポジトリへのPRを作成するか、GitHub CLIを利用できる場合はgh pr createを使用します。

gh pr create `
  --repo Azure/Azure-Sentinel `
  --head "<GitHubユーザー名>:asim/networksession-contoso-edgefirewall" `
  --fill

提出先のベースブランチは、実行時点のAzure-Sentinelリポジトリの既定ブランチを確認して選択してください。

検証結果を受け入れる判断基準

すべての警告をゼロにすることが正解とは限りません。一方で、Errorを残したままPRへ進むべきでもありません。

必ず修正するもの

  • (0) Error
  • 必須フィールドの不足
  • 列名またはデータ型の不一致
  • 許可されていない列挙値
  • IPアドレスなどの形式不正
  • 余分な未正規化列
  • disabledなど主要フィルターが機能しない
  • KQL構文エラー
  • 実際のログと明らかに異なるマッピング

根拠を記録したうえで許容できるもの

  • ソースに存在しない推奨フィールド
  • ソースに存在しない任意フィールド
  • テスト期間に異なる値が不足しているフィルターテスト
  • 設計上、常に単一値となるフィールドの絞り込みテスト
  • ASIMスキーマで明示された既知の例外

許容するWarningやフィルターテスト失敗は、最終サマリーレポートとPR説明に理由を残します。Agentの最終レポートにも、受け入れたWarning、フィールドマッピング、生成ファイル、展開・PR状況が含まれます。(GitHub)

よくある失敗と対処方法

症状主な原因対処
az account showが失敗するAzure CLI未認証az loginを実行
ワークスペースが見つからないWorkspace IDの取り違え、テナント・サブスクリプション違いcustomerIdとaz account showを再確認
ソーステーブルを照会できないテーブル名の誤り、権限不足、データ未投入Logs画面で直接take 10を実行
5回修正してもErrorが残る対象スキーマまたはマッピングが不適切スキーマ選択と必須フィールドを手動確認
Data Testerで列挙値エラーベンダー値をそのまま出力しているcaseや参照表でASIM値へ正規化
IPアドレス形式エラーポート番号や文字列が混在IP部分を分離し、不正値を空値へ処理
Filter Validatorでデータなし直近のテスト期間にログがないテストログを投入するか期間・データ状態を確認
ARMデプロイが失敗するKQLの引用符、改行、バックスラッシュのエスケープ不備ARMテンプレート内の文字列を再生成
展開後に0行になるdisabledの既定値、ソーステーブル、フィルター条件の誤り個別関数を引数なしで直接確認
Git pushが拒否されるフォークへの権限不足、リモート設定の誤りgit remote -vと認証状態を確認
PRのCIが失敗するYAML形式、SchemaLink、テーブル定義、生成ARMの不整合CIログとリポジトリ内テスト定義を照合

Azure-SentinelのREADMEでも、認証、Workspace ID、ARMエスケープ、5回後の検証エラー、Git権限、展開後の0行といった問題が代表的なトラブルとして挙げられています。(GitHub)

本番投入前のチェックリスト

次の条件をすべて満たしてから、本番ワークスペースへの反映やPR提出へ進みます。

  • ASimSchemaTesterのErrorが0件
  • ASimDataTesterのErrorが0件
  • parameterized parserのフィルターテストが成功
  • 許容したWarningとテスト例外に理由がある
  • ソース列からASIMフィールドへのマッピングを人が確認済み
  • 正常、失敗、拒否など主要なログパターンを検証済み
  • parameterless parserとparameterized parserの両方を直接実行済み
  • 必要に応じて統合パーサーからも新しいログを確認済み
  • サンプルCSVが完全に匿名化されている
  • 秘密情報がCopilot Chat、KQL、YAML、ARM、Git履歴に含まれていない
  • git diff --checkでエラーがない
  • ARM生成後の変更内容に意図しない削除がない
  • PRの自動テスト結果を確認済み

まとめ：生成よりも「検証と差分確認」が重要

Microsoft SentinelのASIM Parser Creation Agentic Experienceを使うと、独自ログ向けASIMパーサーの作成を次の流れで進められます。

  1. ソースドキュメント、テーブル名、Workspace ID、ASIMスキーマを準備する
  2. VS CodeまたはGitHub Copilot CLIからオーケストレーターを起動する
  3. ASim<Schema><Vendor><Product>.kqlを生成する
  4. ASimSchemaTesterとASimDataTesterで検証する
  5. Errorがなくなるまで最大5回の修正ループを実行する
  6. vim<Schema><Vendor><Product>.kqlを生成する
  7. スキーマ・データ検証に加えてフィルターパラメーターを検証する
  8. テスト用Log Analyticsワークスペースへ展開する
  9. YAML、CHANGELOG、統合パーサー、サンプルデータ、ARMテンプレートをPR用にパッケージ化する
  10. Git差分とCI結果を人が確認してPRを提出する

最初に行うべきことは、対象ログの公式ドキュメントと、代表的なログが入ったテスト用ワークスペースを準備することです。そのうえで、両パーサーのErrorが0件になり、フィルター動作とGit差分を確認できるまでPR提出へ進まない運用にすると、Agentによる高速化とASIMパーサーの品質を両立できます。
[9]: https://marketplace.visualstudio.com/items?itemName=ms-security.ms-sentinel “
Microsoft Sentinel – Visual Studio Marketplace
“

Azure
Log Analytics Microsoft Sentinel KQL GitHub Copilot ASIM

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次