Microsoft Sentinelのコードレスコネクタを確認している管理者がまず押さえるべき結論は、2026年4月時点の公式ドキュメントでは、Codeless Connector Framework（CCF）を使った「管理された取り込み方式」として、DCR/DCE、ARMテンプレート、機密情報保護、検証手順までをセットで設計することが重要になっているという点です。英語版の Microsoft Learn「Create a codeless connector for Microsoft Sentinel」は2026年4月22日に更新されており、CCFでMicrosoft Sentinelにカスタムデータを取り込む流れを、データコネクタ構築、ARMテンプレート作成、デプロイ、接続・取り込み開始の順に整理しています。(Microsoft Learn)
特にsecurity admins、identity teams、compliance teamsにとって重要なのは、「コードを書かずに済む」という表面的なメリットだけではありません。実務では、ログソースのAPI仕様、認証方式、ページング、出力スキーマ、データ保管要件、資格情報の扱いを事前に詰めなければ、接続できても検知や監査に使えるデータになりません。この記事では、2026年4月更新時点の公式情報をもとに、Microsoft Sentinel コードレスコネクタの確認ポイントと、導入前に見るべき判断基準を実務向けに整理します。
Microsoft Sentinelの最新動向: Create a codeless connector for Microsoft Sentinelで何が変わったか
今回確認すべきポイントは、単なる「手順ページの更新」ではなく、Microsoft Sentinelのデータ取り込みをCCF中心で設計する際の前提が明確になっていることです。
CCFは、パートナー、上級ユーザー、開発者がMicrosoft Sentinelへデータを取り込むためのカスタムコネクタを作成する仕組みです。CCFで作成したコネクタは完全SaaS型で、追加サービスのインストールを必要とせず、正常性監視とMicrosoft Sentinel側のサポートも含まれると説明されています。(Microsoft Learn)
一方で、「コードレス」は「設計不要」という意味ではありません。むしろ、従来よりもARMテンプレート、DCR、DCE、Log Analyticsテーブル、接続ルールの整合性が重要になります。公式ドキュメントでは、CCFデータコネクタを構築するために、出力テーブル定義、Data Collection Rule（DCR）、データコネクタUI、データコネクタ接続ルールの4要素が必要だと整理されています。(Microsoft Learn)
| 確認ポイント | 実務上の意味 |
|---|---|
| CCFベースの構成 | Azure Functionsや独自中継サーバーを前提にせず、Microsoft Sentinel側の管理された仕組みで取り込みを設計する |
| DCR/DCEの重視 | どのデータを、どう変換し、どのテーブルに送るかを取り込み段階で決める |
| UIと接続構成の分離 | 1つのコネクタUIから複数接続を扱う設計がしやすくなる |
| 認証・ページング対応の確認 | APIキー、OAuth、ページング方式など、ログソース側のAPI仕様を事前に検証する |
| ARMテンプレート化 | 検証環境、本番環境、複数ワークスペース展開で再現性を持たせる |
なお、Microsoft SentinelのCodeless Connector Platform（CCP）は、2025年6月にCodeless Connector Framework（CCF）へ名称変更されています。旧称のCCPで社内資料や過去ブログを検索している場合は、2026年時点ではCCFという名称で読み替えるのが実務上のポイントです。(Microsoft Learn)
2026年4月更新で押さえたい実務ポイント
Microsoft Learnの対象ページはチェンジログ形式ではありません。そのため、記事作成や社内共有では「差分の断定」ではなく、2026年4月22日時点の公式記載から、運用者が確認すべきポイントとして整理するのが安全です。
レガシー版ではなく現在のCCFを前提にする
公式ドキュメントでは、初期版のCCFは2022年1月に発表されたものの、その後プラットフォームが改善され、レガシーリリースは推奨されないと説明されています。現在のCCFでは、認証とページングのサポート改善、標準DCRのサポート、UIと接続構成の分離が主な改善点として挙げられています。(Microsoft Learn)
既存の社内手順が古いCCP/CCF前提で書かれている場合は、次の観点で見直してください。
- DCRを使った取り込み設計になっているか
- UI定義と接続ルールを分けて管理しているか
- 複数接続を想定した命名規則になっているか
- 古いAPIバージョンや旧テンプレートをそのまま使っていないか
- Content Hub向けのソリューション化を見据えた構造になっているか
特にグローバル企業では、地域別、事業部別、テナント別に同じSaaSログを複数接続するケースがあります。UIと接続構成を分離できる点は、単一のデータソースを複数条件で取り込む設計に向いています。
DCRとDCEを最初に設計する
CCFでよくある失敗は、API接続の確認を先に進め、あとからテーブルや変換を考えることです。公式ドキュメントでは、DCEはDCRの要件であり、Microsoft SentinelワークスペースにデプロイされたDCRは同じDCEを使用すると説明されています。また、DCRは収集するデータ、変換方法、送信先を定義します。(Microsoft Learn)
実務では、以下の順番で考えると手戻りを減らせます。
| 順序 | 確認する内容 | 失敗しやすい例 |
|---|---|---|
| 1 | 取り込みたいログの目的 | 「全部取り込む」と決めてコストやノイズが増える |
| 2 | 出力先テーブル | 標準テーブルに寄せられるのにカスタムテーブルを乱立する |
| 3 | スキーマ | 重要なフィールドがstring扱いになり、検索や集計がしづらい |
| 4 | DCRの変換 | 不要フィールドの削除や正規化を後回しにする |
| 5 | DCEとリージョン | ワークスペースやDCRとの整合性を確認せずデプロイする |
たとえば、ID管理SaaSのログを取り込む場合、UserPrincipalName、SourceIP、EventType、Result、RiskLevelのような調査に使うフィールドを最初に決めます。監査目的なら保持すべき原文フィールドも必要ですが、検知目的ならKQLで扱いやすい名前と型に整えることが重要です。
CCFコネクタを作る前に確認すべき前提条件
CCFの構築前には、ログソースがMicrosoft Sentinelとどのように接続されるかを理解する必要があります。公式ドキュメントでは、HTTPリクエストとレスポンスの構造、認証方式、ページング方式を調査し、Data Connector APIリファレンスでサポートを確認するよう案内しています。たとえば、証明書で署名されたトークンが必要なデータソースは、APIリファレンス上で証明書認証がサポートされていないことを確認すべき例として挙げられています。(Microsoft Learn)
API仕様で見るべき項目
| 項目 | 確認内容 | 判断基準 |
|---|---|---|
| 認証方式 | APIキー、Basic、OAuth 2.0など | CCFの接続ルールで表現できるか |
| ページング | Link header、token、offsetなど | 次ページ取得を安定して定義できるか |
| レート制限 | QPS、日次制限、429応答 | Sentinel側のポーリング間隔で制限を超えないか |
| 時刻指定 | since/until、createdAfterなど | 差分取得と重複排除ができるか |
| レスポンス形式 | JSON配列、ネスト、イベントパス | JSONPathや変換で目的テーブルに落とせるか |
| エラー応答 | 401、403、429、5xx | リトライや再認証の設計が必要か |
ここを確認せずにARMテンプレートを書き始めると、接続後に「一部のログしか入らない」「ページングで2ページ目以降が取れない」「認証トークン更新で止まる」といった問題が起きやすくなります。
APIテストはローカルかつ安全な環境で行う
公式ドキュメントでは、Visual Studio Code、PowerShell Invoke-RestMethod、Microsoft EdgeのNetwork Console、Bruno、curlなどのAPIテストツールが例示されています。同時に、資格情報、シークレット、アクセストークン、APIキーなどを扱う場合は、クラウド同期せず、オンラインアカウントへのサインインを必要としない、安全なツールを使うよう注意喚起されています。(Microsoft Learn)
セキュリティ管理者とID管理チームは、検証時点から以下をルール化しておくと安全です。
- APIキーやClient Secretをチャット、チケット、ソースコードに貼らない
- APIテストコレクションをクラウド同期しない
- 検証用アカウントに本番管理者権限を付与しない
- ログソース側で読み取り専用の権限を使う
- 検証後は不要なトークンやシークレットを失効させる
CCFの構成要素を実務目線で理解する
Microsoft Sentinelのコードレスコネクタは、1つのJSONを書けば終わるものではありません。公式ドキュメントでは、最終的なARMテンプレートに組み込むため、各コンポーネントのJSONを作成・検証する流れになっています。(Microsoft Learn)
出力テーブル定義
データが標準のLog Analyticsテーブルにのみ取り込まれる場合、カスタムテーブル作成は不要です。標準テーブルの例として、CommonSecurityLogやASimDnsActivityLogsが挙げられています。一方、標準スキーマに合わない場合は、すべてをカスタムテーブルに入れるか、一部をカスタムテーブルに入れて、準拠するデータを標準テーブルへ分割する選択肢があります。(Microsoft Learn)
実務では、次の判断が重要です。
| 判断 | 向いているケース |
|---|---|
| 標準テーブルへ取り込む | ASIMや既存の検知ルール、ブック、ハンティングクエリで再利用したい |
| カスタムテーブルへ取り込む | 独自SaaSや業務アプリの固有フィールドが多い |
| 標準テーブルとカスタムテーブルに分割 | ファイルイベントは標準テーブル、製品独自アラートはカスタムテーブルなど、用途が分かれる |
カスタムテーブルを作る場合は、テーブル名に_CLサフィックスを付ける点にも注意が必要です。公式ドキュメントでも、プログラム的にカスタムテーブルを作成する場合は_CLを手動で追加するよう説明されています。(Microsoft Learn)
Data Collection Rule（DCR）
DCRは、Azure Monitorでデータ収集プロセスを定義する中核です。どのデータを集め、どう変換し、どこへ送るかを定義します。公式ドキュメントでは、データコネクタごとにDCRは1つだけデプロイされ、DCRには同じリージョンのDCEが必要だと説明されています。(Microsoft Learn)
DCRの設計では、次のようなKQL変換を想定します。
source
| where eventType == "Alert"
| project
TimeGenerated = ts,
SourceIP = srcIp,
DestIP = destIp,
Message = message,
Priority = priorityこのように、APIから返る生データをそのまま保存するのではなく、調査や検知に使いやすい列名へ整えることが大切です。変換を後回しにすると、アナリストが毎回クエリ内で補正する必要があり、運用負荷が増えます。
データコネクタUI
データコネクタUIは、Microsoft Sentinelのデータコネクタギャラリーに表示される画面です。公式ドキュメントでは、各データコネクタにUI定義は1つだけで、APIポーリングコネクタのkindは常にCustomizable、connectivityCriteriaはhasDataConnectorsに設定すると説明されています。(Microsoft Learn)
UI設計では、利用者が迷わない説明が重要です。たとえば、以下のような項目を明確にします。
- 必要な権限
- 入力するドメイン名やテナントID
- APIキーやClient Secretの取得場所
- 接続後に確認すべきテーブル名
- データ反映までの目安
- 切断時にログソース側で失効すべき資格情報
グローバル展開では、英語UIを前提にしつつ、社内Runbookでは日本語、英語、必要に応じて現地語で補足するのが現実的です。
データ接続ルール
2026年4月時点の公式ドキュメントでは、CCFデータコネクタの接続ルールとして、RestApiPoller、GCP、StorageAccountBlobContainerの3種類が説明されています。RestApiPollerはページング、認可、リクエスト/レスポンスのペイロードをカスタマイズでき、GCPはGoogle Cloud Platform向けにページングやレスポンス構成を自動化し、StorageAccountBlobContainerはAzure Storage Blobからの取り込みに使います。(Microsoft Learn)
| 種類 | 向いているデータソース |
|---|---|
RestApiPoller | REST APIでイベントを取得するSaaS、ID基盤、セキュリティ製品 |
GCP | Google Cloud Platformのログソース |
StorageAccountBlobContainer | Azure Storage Blobに蓄積されたログ |
SaaSログの多くはRestApiPollerの候補になります。ただし、APIが特殊な署名方式、複雑なセッション管理、独自の非同期ジョブ取得を必要とする場合は、CCFだけで表現できるかを事前に検証してください。
CCF PullとCCF Pushの使い分け
「Create a codeless connector for Microsoft Sentinel」は、実質的にポーリング型のCCF、つまりCCF Pullの設計に関するページとして扱われています。関連する公式ガイドでは、CCF Push connectorsはプレビューとして説明され、従来のポーリング型とは異なり、アプリケーション側がイベント発生時にMicrosoft Sentinelへデータを送信できる方式とされています。(Microsoft Learn)
| 条件 | 選びやすい方式 | 理由 |
|---|---|---|
| ログソースがREST APIを公開している | CCF Pull | Sentinel側が定期的にAPIをポーリングできる |
| イベントをリアルタイムに送りたい | CCF Push | アプリケーション側から発生時に送信できる |
| 公開APIを用意したくない | CCF Push | Sentinelが外部APIをポーリングする前提を避けられる |
| ページングや認証が標準的 | CCF Pull | RestApiPollerで定義しやすい |
| データ送信側でバッチ制御したい | CCF Push | アプリケーション側で送信タイミングを制御できる |
注意したいのは、Push型はプレビュー扱いである点です。正式な本番標準として採用する場合は、組織のプレビュー機能利用ポリシー、監査要件、障害時の責任分界を確認してください。CCF Pullで安定運用できるログソースはPullを優先し、アプリケーション側から能動的に送る必要があるケースでPushを検討するのが現実的です。
機密情報をARMテンプレートに残さない
CCFの導入で特に重要なのが、資格情報の扱いです。公式ドキュメントでは、認証方式にかかわらず、ARMテンプレートからCCFへ資格情報を渡す際に、読み取り可能な機密オブジェクトをデプロイ履歴に残さないことを目的として、securestringを使用する手順が示されています。(Microsoft Learn)
たとえば、APIキーやClient Secretを通常のstringで定義すると、テンプレートやデプロイ履歴、レビュー資料に露出するリスクがあります。実務では、最低限以下を守るべきです。
| 項目 | 推奨 |
|---|---|
| APIキー | securestringで入力する |
| Client Secret | ソースコードやARMテンプレートに直書きしない |
| OAuth設定 | テスト用と本番用を分ける |
| 権限 | 読み取りに必要な最小権限にする |
| ローテーション | シークレットの更新手順をRunbook化する |
また、公式ドキュメントでは、ARMテンプレート内でパラメーターを使う箇所に[[parameters('Password')]のような二重の開始ブラケットを使う例が示されています。これは入力ミスではなく、テンプレート式をエスケープするための構文です。(Microsoft Learn)
この構文を知らないと、レビュー時に「余分な[がある」と誤って修正してしまうことがあります。CCFのARMテンプレートをレビューするチームには、エスケープ構文も含めて共有しておきましょう。
デプロイ前後のチェックリスト
公式ドキュメントでは、コードレスコネクタをカスタムテンプレートとしてデプロイし、接続後にデータコネクタギャラリー、DCRリソース、Log Analyticsワークスペースのカスタムテーブルを確認する流れが示されています。また、データの取り込み開始が見えるまで最大30分かかる場合があるとも説明されています。(Microsoft Learn)
デプロイ前に確認すること
| チェック項目 | 確認内容 |
|---|---|
| API接続 | テストツールで認証、ページング、時刻指定を確認したか |
| テーブル設計 | 標準テーブルかカスタムテーブルか決めたか |
| DCR | 変換KQLと出力ストリームが一致しているか |
| DCE | ワークスペース、DCR、リージョンの整合性があるか |
| ARMテンプレート | JSON構文、依存関係、APIバージョンを確認したか |
| 資格情報 | securestringで扱っているか |
| 命名規則 | 複数環境・複数接続で衝突しないか |
デプロイ後に確認すること
まず、Microsoft Sentinelのデータコネクタギャラリーに対象コネクタが表示されるか確認します。次に、接続に必要な認証情報を入力し、接続状態を確認します。正常に接続されると、DCRとカスタムテーブルが作成されるため、リソースグループとLog Analyticsワークスペースの両方を確認します。
ログ確認では、次のようなKQLを使います。
YourCustomTable_CL
| summarize LastIngested=max(TimeGenerated), Count=count()取り込み直後に結果が出ない場合でも、すぐに失敗と判断しないでください。公式ドキュメントでは、データの取り込み開始確認まで最大30分かかる場合があるとされています。(Microsoft Learn)
ネットワーク分離があるログソースではScubaサービスタグを確認する
ログソース側でネットワーク分離やIP許可リストを使っている場合、CCFが使用するパブリックIPアドレスの許可が必要になることがあります。公式ドキュメントでは、CCF向けのサービスタグとしてScubaが示されており、現在のIP範囲はService Tag Discovery APIで確認するよう案内されています。(Microsoft Learn)
この点は見落とされやすいポイントです。APIキーやOAuth設定が正しくても、ログソース側のファイアウォールでブロックされれば、接続や取り込みは失敗します。特に金融、医療、公共系の環境では、事前にネットワークチームと以下を確認してください。
- ログソースのAPIエンドポイントが外部から到達可能か
- IP許可リストが必要か
Scubaサービスタグの範囲をどう運用管理するか- 変更時の承認フローは誰が持つか
- 接続失敗時にログソース側で拒否ログを確認できるか
security admins、identity teams、compliance teamsの役割分担
CCFコネクタは、セキュリティ運用だけで完結しません。実務では、少なくともsecurity admins、identity teams、compliance teamsが連携する必要があります。
| チーム | 主な確認ポイント | 成果物 |
|---|---|---|
| security admins | 取り込むログ、検知ルール、テーブル設計、KQL変換 | コネクタ設計書、DCR、検証クエリ |
| identity teams | OAuth、APIキー、最小権限、シークレット管理 | 権限設計、資格情報発行・ローテーション手順 |
| compliance teams | データ所在地、保持期間、監査証跡、個人情報の扱い | データ分類、保持ポリシー、監査観点の承認 |
Microsoft Sentinelのデータ所在地については、Raw dataは関連付けられたLog Analyticsワークスペースと同じリージョンに保存され、Defender portalにオンボードされている場合は、処理済みデータや構成データがMicrosoft Defender XDRのリージョンで保存・処理される可能性があると説明されています。グローバル展開では、ワークスペースのリージョン選定とDefender portal利用時のデータ処理範囲を、コンプライアンス部門と確認しておくべきです。(Microsoft Learn)
Defender portal移行も見据えておく
Microsoft SentinelはDefender portalで一般提供されており、Microsoft Learnの最新情報では、2027年3月31日以降、Azure portalではMicrosoft Sentinelがサポートされず、Defender portalのみで利用可能になると案内されています。(Microsoft Learn)
そのため、2026年時点で新しいCCFコネクタを設計するなら、Azure portalだけで操作手順を固定しない方が安全です。社内Runbookには、少なくとも以下を含めておくと移行時の混乱を抑えられます。
- Defender portalでのデータコネクタ確認場所
- Log Analyticsワークスペース側の確認手順
- DCR、DCE、テーブルなどAzureリソース側の確認手順
- Sentinel運用担当とAzure基盤担当の責任分界
- Defender portal移行後に再確認する権限とロール
特に多国籍企業では、リージョンやテナントごとにポータル移行の進み具合が異なることがあります。新規コネクタは、将来のDefender portal運用を前提にドキュメント化しておくのが現実的です。
よくある失敗と回避策
API接続だけ成功して満足してしまう
APIテストで200 OKが返っても、Microsoft Sentinelで使えるログになっているとは限りません。ページング、時刻条件、重複、欠落、フィールド型まで確認してください。
カスタムテーブルを細かく作りすぎる
製品別、イベント別にテーブルを増やしすぎると、クエリや検知ルールの管理が複雑になります。標準テーブルに寄せられるログは標準化し、独自性が高いものだけカスタムテーブルにする方が運用しやすくなります。
機密情報を検証資料に残す
APIキーやClient Secretをスクリーンショット、手順書、チケットに残すと、後から回収が難しくなります。検証段階からsecurestring、Key Vault、シークレットローテーションを前提にしてください。
DCRの変換を後回しにする
「まず取り込んでから整える」という進め方は、初期検証では楽ですが、本番運用ではKQLの複雑化や検知品質の低下につながります。最初に検知・調査・監査で必要な列を決めてからDCRを設計しましょう。
ネットワーク許可を忘れる
ログソースがIP制限をしている場合、認証情報が正しくても接続に失敗します。CCFで使われるScubaサービスタグを確認し、ネットワークチームと許可リスト運用を決めておく必要があります。(Microsoft Learn)
導入判断の実務フロー
Microsoft Sentinel コードレスコネクタを検討する場合は、次の順番で進めると失敗しにくくなります。
| フェーズ | 実施内容 |
|---|---|
| 要件整理 | 何の検知・調査・監査に使うログかを決める |
| API調査 | 認証、ページング、レート制限、時刻条件を確認する |
| スキーマ設計 | 標準テーブルかカスタムテーブルかを決める |
| DCR設計 | 変換KQL、出力ストリーム、DCEを設計する |
| UI設計 | 管理者が入力する値、説明、接続ボタンを設計する |
| 接続ルール作成 | RestApiPollerなど適切なkindで接続を定義する |
| ARMテンプレート化 | 再現可能な形でパッケージ化する |
| 検証 | 接続、取り込み、テーブル、KQL、検知ルールを確認する |
| 運用化 | 監視、資格情報更新、障害対応、変更管理をRunbook化する |
コードレスコネクタは、開発工数を削減するための仕組みであると同時に、取り込み設計を標準化するための仕組みでもあります。最初の設計段階でsecurity admins、identity teams、compliance teamsが合意しておけば、後から「ログは入っているが監査に使えない」「検知ルールに必要な列がない」「資格情報の更新手順がない」といった問題を避けやすくなります。
まとめ: まずはログソースのAPI仕様とDCR設計から始める
2026年4月更新時点の「Create a codeless connector for Microsoft Sentinel」を読むうえで最も重要なのは、CCFを単なるノーコード機能として見るのではなく、Microsoft Sentinelへのデータ取り込みを標準化する設計フレームワークとして扱うことです。
最初にやるべきことは、ARMテンプレートを書くことではありません。まず、ログソースのAPI仕様、認証方式、ページング、取得対象イベント、出力スキーマ、DCRでの変換方針を整理してください。そのうえで、Pull型のCCFで足りるのか、Push型を検討すべきなのか、あるいは別方式が必要なのかを判断します。
特に本番導入では、次の3点を先に固めると成功しやすくなります。
- どのログを何の検知・調査・監査に使うのか
- どのテーブルに、どの列名と型で保存するのか
- 資格情報、ネットワーク許可、データ所在地を誰が承認・運用するのか
Microsoft Sentinelのコードレスコネクタは、うまく設計すれば、SaaSやクラウドサービスのログ取り込みを再現性高く展開できます。まずは1つのログソースを選び、検証環境でAPIテスト、DCR設計、テーブル確認、KQL検証まで小さく通すところから始めるのが現実的です。
コメント