Azure MonitorでHTTP Data Collector APIを使ってカスタムログを送信している場合は、Logs Ingestion APIへの移行対応が必要です。2026年9月14日に突然データ送信が停止するわけではありませんが、同日で旧APIのサポートが終了する予定です。TLS 1.2に対応した既存クライアントの取り込みは継続すると案内されているものの、機能改善や長期的な互換性を期待して使い続けるべき状態ではありません。(Microsoft Learn)
注意したいのは、移行が単なる送信先URLの変更ではないことです。認証方式は共有キーからMicrosoft Entra IDベースへ、データの定義とルーティングはデータ収集ルール（DCR）へ変わります。さらに、1回のAPI呼び出し上限が30MBから1MBになるため、既存の送信処理によってはバッチ分割や再試行制御の作り直しが必要です。
本記事は、2026年7月8日日本時間に確認したMicrosoft公式情報を基にしています。Microsoft Learnのページメタデータ上の更新日は2026年7月7日で、GitHub上でも同日付の更新履歴が確認できます。(GitHub)
まず確認：自社に移行対応が必要か
最初に、現在の構成が移行対象かどうかを確認しましょう。
| 現在の構成 | 対応要否 | 最初に確認すること |
|---|---|---|
| HTTP Data Collector APIをアプリやスクリプトから直接呼び出している | 必要 | 送信元、対象テーブル、送信量、共有キーの利用箇所 |
.ods.opinsights.azure.com/api/logs にPOSTしている | 必要 | API呼び出しを行うコードやミドルウェア |
Authorization: SharedKey や Log-Type ヘッダーを使用している | 必要 | 共有キーを保管している設定、Key Vault、CI/CD変数 |
| Logs Ingestion APIとDCRをすでに使用している | 原則不要 | 1MB制限、DCRのスキーマ、権限設定が適切か |
| 別部門やSaaS製品が対象テーブルへ送信している | 要調査 | 実際のデータ送信元と製品側の対応状況 |
| 旧テーブルをKQLで参照しているだけ | 送信側次第 | テーブル名や列名が移行後も維持されるか |
| MMA／Log Analyticsエージェント由来のクラシックテーブルがある | 別対応が先 | Azure Monitor Agentへの移行状況 |
| Microsoft Sentinelのコネクタがデータを送信している | 要調査 | 新旧コネクタ、テーブル名、分析ルールへの影響 |
HTTP Data Collector APIは、ワークスペースID、共有キー、Log-Typeなどを使ってLog Analyticsへデータを送信する旧方式です。Logs Ingestion APIをすでに利用している場合、今回の旧API移行を改めて行う必要はありません。ただし、DCRや送信上限を含む現行仕様に沿っているかは確認しておく必要があります。(Microsoft Learn)
2026年7月の公式更新で何が明確になったのか
2026年9月14日は「即時停止日」ではなくサポート終了日
Microsoftは、HTTP Data Collector APIのサポートを2026年9月14日に終了する予定と案内しています。
一方、TLS要件を満たす既存クライアントについては、サポート終了後もデータ取り込みが継続するとされています。そのため、9月14日を境に全リクエストが拒否されると考えるのは正確ではありません。
ただし、これは移行しなくてよいという意味ではありません。旧APIは重要なセキュリティ修正を除き、今後の機能拡張や改善を期待できない状態になります。障害や仕様変更が起きてから対応するのではなく、サポート期間内に移行と検証を完了させるのが安全です。(Microsoft Learn)
TLS 1.2以上への対応はすでに必須
旧バージョンのTLSを使った接続は、2026年3月1日以降サポートされていません。HTTP Data Collector APIを一時的に継続利用する場合でも、クライアントがTLS 1.2以上で接続できることを確認する必要があります。(Microsoft Learn)
特に、古いWindows Server、更新されていない.NET Framework、旧Javaランタイム、レガシーなネットワーク機器から送信している場合は注意が必要です。アプリケーションコードだけでなく、OS、ランタイム、プロキシ、TLS終端装置まで含めて確認します。
旧APIの送信上限は30MB、新APIは1MB
2026年7月の更新では、HTTP Data Collector APIの1回のPOST上限が30MBであることが明確化されました。Logs Ingestion APIの上限は、圧縮の有無にかかわらず1回あたり1MBです。(GitHub)
この差は移行作業で特に影響が大きいポイントです。旧APIで数MBから数十MBのJSONをまとめて送っている処理は、そのままでは移行できません。レコード単位でバッチを分割し、必要に応じて並列送信や再試行を実装する必要があります。
HTTP Data Collector APIとLogs Ingestion APIの仕様差
両APIの違いを、実装への影響が大きい項目に絞って整理すると次のようになります。(Microsoft Learn)
| 比較項目 | HTTP Data Collector API | Logs Ingestion API |
|---|---|---|
| 認証 | ワークスペースIDと共有キーによるHMAC署名 | Microsoft Entra IDのアクセストークン |
| 権限の単位 | 実質的にワークスペース共有キー単位 | DCRに対するRBAC |
| 送信先 | ワークスペース固有のAPIエンドポイント | DCRの直接エンドポイント、またはDCE |
| APIの構成 | Log-TypeなどのHTTPヘッダーで指定 | DCRのストリーム、変換、送信先で定義 |
| テーブルスキーマ | データに応じて列が追加される旧来の動作 | テーブルとDCRで事前にスキーマを定義 |
| 1リクエストの上限 | 30MB | 1MB |
| 1フィールドの上限 | 32KB | 64KB |
| データ変換 | 基本的になし | DCRのKQL変換を利用可能 |
| タイムスタンプ | time-generated-fieldヘッダー | DCR変換などでTimeGeneratedへマッピング |
| Private Link | Azure Monitor Private Link Scopeに非対応 | Private Link利用時はDCEを使用 |
| 送信先の変更 | 送信コード側の変更が必要になりやすい | DCR側でテーブルや処理を変更可能 |
| スキーマ変更への追従 | 入力に応じて旧テーブルが変化しやすい | DCRとテーブルの明示的な変更が必要 |
認証は共有キーからDCR単位のRBACへ変わる
HTTP Data Collector APIでは、ワークスペースの共有キーを使って署名を生成します。共有キーを取得できる利用者やアプリは、そのワークスペースへデータを送信できるため、細かな権限分離が難しい方式です。
Logs Ingestion APIでは、Microsoft Entra IDで認証したIDに対し、対象DCRへの送信権限を割り当てます。送信アプリごとにDCRを分ければ、アクセス可能なデータフローを限定しやすくなります。
移行時は、URLやヘッダーの変更だけでなく、次の作業が必要です。
- アプリ登録またはマネージドIDの用意
- DCRへのRBAC割り当て
- アクセストークン取得処理の実装
- 共有キーによる署名生成処理の削除
- シークレットや証明書の更新・ローテーション設計
本番環境でクライアントシークレットを使う場合は、有効期限切れを防ぐ更新手順が必要です。可能な構成では、マネージドIDや証明書を検討すると、長期運用時のシークレット管理を減らせます。(Microsoft Learn)
DCRがスキーマとデータフローの中心になる
Logs Ingestion APIでは、送信データの入力スキーマをDCRのstreamDeclarationsに定義します。その後、dataFlowsで変換処理と送信先テーブルを関連付けます。
送信元のJSONと最終的なテーブルスキーマを完全に一致させる必要はありません。DCRのtransformKqlを使えば、列名変更、型変換、不要列の削除、固定値の付与などが可能です。ただし、変換後の出力は送信先テーブルのスキーマと一致させる必要があります。(Microsoft Learn)
例えば、送信元が次のJSONを出力しているとします。
[
{
"event_time": "2026-07-08T10:00:00Z",
"host": "web-01",
"status_code": 500
}
]送信元を大きく変更せず、DCRで次のように変換できます。
source
| project
TimeGenerated = todatetime(event_time),
Computer = tostring(host),
StatusCode = toint(status_code)この方式なら、既存アプリのJSON形式を維持しながら、Log Analytics側の列名を標準化できます。
「複数の送信先」には制約がある
DCRを使うと、同じ入力ストリームから同一ワークスペース内の複数テーブルへデータを送る構成を作れます。
ただし、1つのストリームを同じDCRから複数のLog Analyticsワークスペースへ送ることはできません。複数ワークスペースへ送りたい場合は、ワークスペースごとにDCRを分ける必要があります。(Microsoft Learn)
既存実装との互換性はどこまで保てるか
API呼び出し部分には互換性がない
HTTP Data Collector APIとLogs Ingestion APIには、呼び出しレベルの互換性がありません。
旧APIでは、次のようなURLやヘッダーを使用します。
https://<WorkspaceID>.ods.opinsights.azure.com/api/logs?api-version=2016-04-01
Authorization: SharedKey <WorkspaceID>:<Signature>
Log-Type: <LogTypeName>Logs Ingestion APIでは、DCRのエンドポイント、DCRの不変ID、ストリーム名を含むURLを使用します。
<Endpoint>/dataCollectionRules/<DCR-Immutable-ID>/streams/<Stream-Name>?api-version=2023-01-01
Authorization: Bearer <Access-Token>
Content-Type: application/jsonそのため、次の部分は作り直しが必要です。
- 認証処理
- URLの組み立て
- HTTPヘッダー
- 1MB単位のバッチ分割
- 429や一時障害に対する再試行
- DCRに合わせたJSON生成
- エラーレスポンスの監視
テーブル名とKQLは維持できる場合がある
既存のクラシックカスタムテーブルをインプレースで移行すれば、同じテーブル名を引き続き利用できます。既存のKQL、アラート、ブック、ダッシュボードへの影響を抑えたい場合に有効です。
列名も維持できます。送信元のフィールド名が既存列と異なる場合は、DCRの変換で既存列へマッピングできます。
ただし、テーブルの移行は元に戻せません。移行後に問題が見つかっても、クラシックテーブルへロールバックする操作は用意されていないため、事前検証が必要です。(Microsoft Learn)
テーブル移行後も旧APIを使う場合はスキーマを変更しない
テーブルを新しい方式へ移行した後も、既存列に対するHTTP Data Collector APIの書き込みは一時的に継続できます。
ただし、この並行運用中にAzureポータルやTables APIから列を追加・変更すると、旧APIからの取り込みが停止する可能性があります。新しい列を追加したい場合は、Logs Ingestion API側だけで扱い、DCRのstreamDeclarationsも合わせて更新します。(Microsoft Learn)
つまり、次のような順序は避ける必要があります。
- テーブルだけを新方式へ移行する
- 送信元は旧APIのまま残す
- ポータルからテーブルに新しい列を追加する
- 旧APIの取り込みが失敗する
テーブル移行と送信元移行を別日に実施する場合は、その期間を「スキーマ凍結期間」として扱うのが安全です。
入力スキーマの自動追従は期待できない
旧APIでは、送信JSONに新しいフィールドが現れると、テーブルに列が追加される動作が使われてきました。
Logs Ingestion APIでは、入力データが変わってもテーブルやDCRのスキーマは自動更新されません。新しいフィールドを取り込みたい場合は、原則として次の両方を変更します。
- 送信先テーブルのスキーマ
- DCRの
streamDeclarationsと必要な変換
外部サービスのログなど、予告なくフィールドが増える可能性があるデータでは、頻繁に変わる部分をdynamic型の列へまとめる設計も検討できます。ただし、検索頻度の高いフィールドまでdynamicにすると、クエリが複雑になりやすいため、固定列との使い分けが必要です。
GUIDはDCR上でstringとして定義する
Azure Monitor Logsでは、GUIDは文字列として保存されます。DCRのストリーム宣言にもGUID型はないため、GUID形式のデータはstringとして定義します。
移行時にGUID列を専用の型へ変更する必要はありません。誤って別の型を指定すると、変換エラーや取り込み失敗の原因になります。(Microsoft Learn)
Logs Ingestion APIの導入条件
移行前に必要なリソースと権限を整理しておきましょう。(Microsoft Learn)
| 項目 | 必要な内容 | 確認ポイント |
|---|---|---|
| Log Analyticsワークスペース | 送信先ワークスペース | テーブルを作成・変更できるか |
| カスタムテーブル | 原則として末尾が_CLのテーブル | 列名、列型、TimeGeneratedを確認 |
| DCR | 入力スキーマ、変換、送信先を定義 | ストリーム名、変換結果、テーブルを確認 |
| エンドポイント | DCR直接エンドポイントまたはDCE | Private Link利用時はDCEが必要 |
| 送信用ID | アプリ登録、サービスプリンシパル、マネージドIDなど | トークン取得方法と有効期限 |
| 実行時権限 | DCRに対する送信権限 | Monitoring Metrics Publisherなど |
| 構築時権限 | DCR、DCE、テーブルを作成・変更する権限 | 作業担当者のRBACを確認 |
| ネットワーク | Azure Monitorエンドポイントへの接続 | プロキシ、FW、Private Link、DNSを確認 |
構築時と送信時では必要な権限が異なる
環境を作成する担当者には、DCRやDCE、テーブルを作成する権限が必要です。代表的な操作権限は次のとおりです。
| 操作 | 主な権限 |
|---|---|
| DCEの作成 | Microsoft.Insights/dataCollectionEndpoints/write |
| DCRの作成・変更 | Microsoft.Insights/dataCollectionRules/write |
| テーブルの移行 | Microsoft.OperationalInsights/workspaces/tables/migrate/action |
| テーブルの作成・変更 | Microsoft.OperationalInsights/workspaces/tables/write |
| Logs Ingestion APIへの送信 | DCRに対するMicrosoft.Insights/Telemetry/Write |
送信アプリにワークスペース全体のContributor権限を与える必要はありません。DCRに対してMonitoring Metrics Publisherロールを割り当てる方法が、権限を限定しやすい構成です。(Microsoft Learn)
DCEが必要かを判断する
Logs Ingestion APIでは、次のいずれかをエンドポイントとして使用します。
- DCRに組み込まれたLogs Ingestionエンドポイント
- Data Collection Endpoint（DCE）
DCRの直接エンドポイントを利用できる場合、DCEは必須ではありません。ただし、Azure Monitor Private Linkを利用する場合はDCEが必要です。
また、2024年3月31日より前に作成されたDCRには、直接取り込み用エンドポイントが含まれていない場合があります。既存DCRへ後から直接エンドポイントだけを追加することはできないため、新しいDCRを作成する必要があります。(Microsoft Learn)
DCEを使用する場合は、DCRおよび送信先Log Analyticsワークスペースとのリージョン関係も確認します。Private Link環境では、DNSとネットワーク経路を含めて非本番環境から接続試験を行ってください。(Microsoft Learn)
移行方式は「インプレース」と「並行テーブル」から選ぶ
既存テーブルの移行方法には、大きく分けて2つの選択肢があります。
| 比較項目 | 既存テーブルをインプレース移行 | 新テーブルを並行作成 |
|---|---|---|
| テーブル名 | 維持できる | 変更が必要 |
| 既存KQLへの影響 | 抑えやすい | クエリの更新が必要 |
| ロールバック | できない | 旧テーブルへ戻しやすい |
| 新旧データの比較 | 工夫が必要 | 比較しやすい |
| 切り替え方法 | 一括切り替え向き | 段階移行向き |
| スキーマ変更 | 並行運用中は特に注意 | 比較的自由 |
| 向いている環境 | スキーマが安定している環境 | 重要システム、複雑な変換、変更の多いログ |
インプレース移行が向いているケース
次の条件がそろっている場合は、既存テーブルを移行する方法が適しています。
- 多数のKQLやアラートが既存テーブル名を参照している
- テーブルの列構成が安定している
- 送信元を短期間で一斉に切り替えられる
- 非本番環境で同等の移行試験ができる
- ロールバックできないことを許容できる
新テーブルへの並行移行が向いているケース
次の条件では、新しいテーブルを作って並行送信する方法が安全です。
- 監視やセキュリティ検知に利用する重要ログ
- フィールド名や型を整理したい
- 複数の送信元を段階的に移行する
- データ件数や変換結果を長期間比較したい
- Microsoft Sentinelの分析ルールやコンテンツへの影響が大きい
- 送信データのスキーマが頻繁に変わる
新テーブル方式では、クエリやダッシュボードの変更が必要です。一方、旧経路を残したまま新経路を検証できるため、データ欠損を避けやすくなります。
実務で進める移行手順
旧APIの利用箇所を検索する
ソースコード、PowerShell、Azure Functions、Logic Apps、CI/CD変数、設定ファイルを対象に、次の文字列を検索します。
ods.opinsights.azure.com/api/logs
api-version=2016-04-01
Authorization: SharedKey
Log-Type
time-generated-fieldライブラリや共通基盤にAPI呼び出しが隠れている場合もあります。アプリ名だけで判断せず、ネットワークログ、Key Vaultのシークレット名、Azure Functionsのアプリ設定も確認してください。
調査結果は次のような一覧にします。
| 項目 | 記録内容 |
|---|---|
| 送信元 | アプリ、サーバー、Function、SaaS製品 |
| 管理者 | 担当チーム、ベンダー |
| 対象ワークスペース | ワークスペース名とリソースID |
| 対象テーブル | 現在の*_CLテーブル |
| 送信頻度 | 常時、1分ごと、日次など |
| 最大送信サイズ | 通常値、ピーク値 |
| 認証情報 | 共有キーの保管場所 |
| 下流依存 | KQL、アラート、ブック、Sentinel |
| 移行方式 | インプレース、並行テーブル |
| 切り替え予定 | 開発、検証、本番の日程 |
共有キーをローテーションする前に、同じキーを使う別の送信元がないことを確認します。1つの送信元だけを移行した直後にワークスペースキーを再生成すると、未移行のシステムが停止する可能性があります。
クラシックテーブルを洗い出す
Azureポータルでは、テーブルの種類が「Custom table (classic)」になっているものを確認します。
Azure CLIを使う場合は、次のコマンドでクラシックテーブルを抽出できます。
az monitor log-analytics workspace table list \
--resource-group <RESOURCE_GROUP> \
--workspace-name <WORKSPACE_NAME> \
--query "[?schema.tableSubType=='Classic'].{Name:name,SubType:schema.tableSubType}" \
-o table過去データのSourceSystem列がRestAPIであれば、HTTP Data Collector APIから取り込まれた可能性が高いと判断できます。旧APIで作られた列には、文字列の_s、数値の_d、日時の_tなどの接尾辞が付いている場合があります。(Microsoft Learn)
ただし、クラシックテーブルだからといって、すべてがHTTP Data Collector API由来とは限りません。MMAや旧Log Analyticsエージェントのカスタムフィールドを使っている場合は、先にAzure Monitor Agentへ移行します。エージェント移行前にテーブルを変換すると、旧カスタムフィールドへの新規データ取り込みが止まる可能性があります。(Microsoft Learn)
送信データの実態を採取する
DCRを設計する前に、実際の送信JSONを複数パターン保存します。
最低限、次のデータを含めます。
- 正常時の一般的なレコード
- エラー時にだけ現れるフィールド
- nullを含むレコード
- 空文字列を含むレコード
- 最大長に近いフィールド
- 文字コードや改行を含む文字列
- 日付形式が異なるレコード
- 数値と文字列が混在する可能性のあるフィールド
- 送信量が最大になる時間帯のバッチ
1件のサンプルだけでDCRを作ると、通常時には存在しないフィールドや型の揺れを見落とします。少なくとも通常時と障害時の両方を確認してください。
テーブル、DCR、認証を作成する
新テーブル方式では、送信先となるカスタムテーブルを先に作成します。テーブル名は原則として_CLで終わる名前にします。
次にDCRへ次の内容を定義します。
- 入力ストリーム名
- 入力JSONの列名と型
transformKql- 送信先ワークスペース
- 送信先テーブル
- 必要に応じてDCE
送信用のサービスプリンシパルまたはマネージドIDには、対象DCRへの送信権限を割り当てます。
DCRの列名には命名規則があります。列名は英字で始め、英数字とアンダースコアを使い、最大45文字に収めます。予約済みの列名もあるため、既存スキーマをそのまま転記する前に確認が必要です。(Microsoft Learn)
既存テーブルを移行する
インプレース方式を選ぶ場合は、事前テストと影響確認を終えてからテーブルを移行します。
Azure CLIでは、次のコマンドを使用します。
az monitor log-analytics workspace table migrate \
--resource-group <RESOURCE_GROUP> \
--workspace-name <WORKSPACE_NAME> \
--table-name <TABLE_NAME>PowerShellではInvoke-AzOperationalInsightsMigrateTableを利用できます。REST APIから実行する方法もあります。(Microsoft Learn)
この操作は元に戻せません。実行前に、対象テーブル、送信元、依存するクエリ、移行後のDCRを相互確認してください。
旧経路と新経路を比較してから切り替える
可能であれば、一定期間は同じログを旧テーブルと新テーブルへ送信し、次の項目を比較します。
- レコード件数
- 欠損率
- 重複件数
TimeGenerated- 主要フィールドの値
- 型変換結果
- 取り込み遅延
- 1日あたりの取り込み量
- 変換によって削除されたデータ
- アラートや分析ルールの発火結果
件数だけが一致していても、タイムスタンプや型が誤っている場合があります。重要な識別子を数件抽出し、旧テーブルと新テーブルで値を突き合わせてください。
テスト時に注意すべきポイント
HTTP 204だけで移行成功と判断しない
Logs Ingestion APIへの送信が成功すると、通常はHTTP 204が返ります。しかし、HTTP 204はリクエストが受け付けられたことを示すものであり、期待した列へ正しく保存されたことまで保証する確認方法ではありません。
送信後は、実際にLog Analyticsでクエリを実行し、レコードと各列の値を確認します。テーブルやスキーマの作成直後は、ポータルへの反映や初回データの表示に時間がかかる場合があります。(Microsoft Learn)
1MB制限を境界値で試験する
Logs Ingestion APIの1MB制限は、圧縮を使っても回避できません。非本番環境では、次のケースを試験します。
| テストケース | 確認内容 |
|---|---|
| 小さな単一レコード | 基本的な認証とDCRの動作 |
| 通常サイズのバッチ | 通常運用時の処理時間 |
| 1MBに近いバッチ | 分割ロジックの境界 |
| 1MBを超えるバッチ | 413などを検知して分割できるか |
| 64KBに近いフィールド | 長いメッセージの保存状態 |
| 64KBを超えるフィールド | 切り捨てや欠損を監視できるか |
バッチ分割では、JSON本体だけでなく、配列記号、カンマ、エスケープ後の文字列を含めた実際の送信バイト数を基準にします。文字数だけで判定すると、日本語や絵文字を含むデータでサイズ計算を誤ることがあります。
429への再試行を実装する
Logs Ingestion APIには、DCR単位のスループットとリクエスト数の制限があります。現行のサービス制限では、DCRあたり毎分2GB、毎分12,000リクエストが示されています。制限値は更新される可能性があるため、固定値だけを前提にした設計は避けてください。(Microsoft Learn)
429が返った場合は、レスポンスのRetry-Afterに従って再試行します。再試行処理には、指数バックオフとジッターを加えると、複数クライアントが同時に再送する集中を抑えられます。
無制限に再試行すると、障害時に送信キューが増え続けます。次の項目も設計しておきます。
- 最大再試行回数
- 再試行の総時間
- 送信失敗データの退避先
- デッドレター処理
- 監視メトリック
- 運用担当者への通知条件
403はDCRの権限を確認する
HTTP 403が返る場合は、ワークスペースではなく対象DCRへの権限割り当てを確認します。
RBACの変更は反映まで時間がかかることがあります。権限を付与した直後に403が返った場合は、対象DCR、プリンシパルID、ロールのスコープが正しいことを確認したうえで、反映を待って再試行します。(Microsoft Learn)
よくある誤りは次のとおりです。
- 別のDCRへロールを割り当てている
- アプリ登録のオブジェクトIDとクライアントIDを取り違えている
- トークンの対象リソースが誤っている
- DCRの不変IDではなくAzureリソースIDをURLへ入れている
- テナントが異なる
- 古いトークンを再利用している
スキーマの型揺れを試験する
同じフィールドに数値と文字列が混在するログでは、正常データだけを試しても不十分です。
例えば、通常時は次の値が送られるとします。
{
"status_code": 500
}障害時に次の形式になる可能性があります。
{
"status_code": "unknown"
}DCRでtoint(status_code)を実行すると、変換できない値がnullになる可能性があります。エラー値を失いたくない場合は、元の文字列を別列へ残す設計が必要です。
source
| extend StatusCodeRaw = tostring(status_code)
| extend StatusCode = toint(status_code)テストでは、null、空文字列、0、負数、極端に大きい値、不正な日時を意図的に送信し、期待する結果になるか確認します。
TimeGeneratedのマッピングを確認する
送信時刻ではなくイベント発生時刻を検索に使う場合は、元データの日時をTimeGeneratedへ正しくマッピングします。
確認すべき点は次のとおりです。
- UTCかローカル時刻か
- タイムゾーン情報を含むか
- ミリ秒以下の精度が必要か
- 不正な日時をどう扱うか
- 遅延到着データを許容するか
- 未来時刻のレコードをどう扱うか
Auxiliaryプランのテーブルでは、1回のAPI呼び出しに含まれるTimeGeneratedの時間範囲にも制約があります。広い期間のデータをまとめて再送する場合は、時間帯ごとにバッチを分けてください。(Microsoft Learn)
新旧テーブルをKQLで比較する
並行テーブル方式では、次のようなKQLで取り込み件数と時間範囲を比較できます。
union withsource=TableName OldTable_CL, NewTable_CL
| where TimeGenerated > ago(30m)
| summarize
Records = count(),
FirstSeen = min(TimeGenerated),
LastSeen = max(TimeGenerated)
by TableNameこのクエリで件数が一致しても、重複や列値の違いは分かりません。実際のスキーマにあるイベントID、端末ID、トランザクションIDなどを使い、レコード単位の比較も行います。
Microsoft Sentinelでは検知ロジックまで確認する
Microsoft Sentinelで対象ログを使っている場合、データが新テーブルに入っただけでは移行完了とはいえません。
次の依存関係を確認します。
- 分析ルール
- ハンティングクエリ
- ワークブック
- オートメーションルール
- プレイブック
- パーサー
- ASIM関連コンテンツ
- Content Hubから導入したソリューション
- 外部SIEMへのエクスポート
旧Azure Functionsベースのコネクタと新しいCCFベースのコネクタが併存する場合もあります。テーブル名やスキーマが変わると、分析ルールがエラーにならなくても検知件数がゼロになる可能性があります。切り替え後は、既知のテストイベントを発生させ、検知から通知まで確認してください。(Microsoft Learn)
移行で失敗しやすいポイント
サポート終了後も動くため対応を先送りする
旧APIの取り込みが継続すると案内されていても、将来の停止時期や追加制約が保証されているわけではありません。ベンダーや担当者との調整が必要な環境ほど、早めに検証を始めるべきです。
テーブルだけを移行して送信元を残す
テーブル移行はAPI移行そのものではありません。DCR、認証、送信コード、バッチ分割まで完了して初めて移行できます。
旧APIの30MBバッチをそのまま送る
Logs Ingestion APIでは1MBを超えるリクエストを送信できません。旧APIのバッチ処理を流用する場合は、実際のUTF-8バイト数で分割してください。
DCRを作成しただけで送信できると考える
送信用IDには、対象DCRへの実行時権限が必要です。DCRを作成した利用者の権限が送信アプリへ自動的に引き継がれるわけではありません。
古いDCRに直接エンドポイントがあると思い込む
古いDCRにはLogs Ingestion用の直接エンドポイントがない場合があります。DCEを使うか、新しいDCRを作成します。
テーブルを変更してDCRを更新しない
テーブルへ列を追加しても、DCRの入力スキーマは自動更新されません。streamDeclarations、変換、出力スキーマを一体で管理してください。
送信成功だけを確認して下流を確認しない
データがテーブルへ入っても、KQL、アラート、ダッシュボード、Sentinelの検知が正しく動くとは限りません。移行完了条件には下流機能の試験も含めます。
まとめ：最初に行うべき5つの対応
HTTP Data Collector APIからLogs Ingestion APIへの移行では、APIのURLだけでなく、認証、スキーマ管理、データ変換、送信サイズ、権限設計が変わります。既存の取り込みが2026年9月14日以降も継続するとされていても、サポート終了後まで旧APIへ依存し続ける構成は避けるべきです。
まず、次の5項目を進めてください。
- コードと設定から
ods.opinsights.azure.com/api/logs、SharedKey、Log-Typeを検索する - クラシックテーブルと実際のデータ送信元を対応付ける
- インプレース移行と並行テーブル移行のどちらを採用するか決める
- 非本番環境でDCR、認証、1MB分割、型変換を検証する
- KQL、アラート、ブック、Microsoft Sentinelを含めて切り替え計画を作る
特に重要なのは、「テーブルの移行」と「送信処理の移行」を別の作業として管理することです。送信元、DCR、テーブル、下流の監視処理を一つのデータフローとして棚卸しすれば、データ欠損や検知漏れを防ぎながら移行できます。
コメント