2026年5月20日に更新された「Microsoft Azure documentation update: fix: Kusto Ingest package release」は、Azure Data Explorer（Kusto）そのものの機能変更ではなく、Go SDKリポジトリ Azure/azure-kusto-go における Kusto Ingestパッケージのリリース処理を正しく動かすための修正 です。具体的には、azkustoingest モジュールのタグが作成されたときにもGitHub Releaseが走るよう、リリース用ワークフローが修正されました。(GitHub)
そのため、Azure Data Explorerの管理画面で今すぐ設定変更が必要になる更新ではありません。ただし、GoでKustoへのデータ取り込みを実装している開発チーム、SDKの更新をCI/CDで自動化しているチーム、社内Go Proxyや依存関係スキャンを使っている組織は、azkustoingest のリリース検知・バージョン固定・テスト手順を確認しておくべきです。
今回の更新は「Kusto Ingestのリリース経路」を直す変更
今回のPRは、fix: Kusto Ingest package release という名称で、Azure公式の azure-kusto-go リポジトリにマージされています。対象ファイルは .github/workflows/release.yml で、アプリケーションコードやAzure Data Explorerのサービス設定ではなく、GitHub Actionsのリリースワークフローが変更されています。(GitHub)
Kusto Go SDKは、GoからAzure Data Explorerに対してクエリ、管理コマンド、データ取り込みを行うためのライブラリです。Microsoft Learnでも、Kusto Go Client libraryはGoを使ってデータベースへのクエリ、制御、取り込みを行うためのSDKだと説明されています。(Microsoft Learn)
今回の対象に近いのは、取り込み機能を担う azkustoingest パッケージです。azkustoingest はAzure Data Explorerクラスターへのデータ取り込み用クライアントで、キュー取り込み、ストリーミング取り込み、マネージド取り込みのほか、ローカルファイル、Azure Blob Storage URL、ストリーム、io.Reader からの取り込みを扱えます。(Go Packages)
何が変わったのか
今回の変更点を実務目線で整理すると、中心は「azkustodata だけでなく azkustoingest のタグでもリリース処理を起動できるようになったこと」です。
| 項目 | 変更前 | 変更後 | 実務上の意味 |
|---|---|---|---|
| リリーストリガー | azkustodata/** タグが中心 | azkustodata/** に加えて azkustoingest/** タグを追加 | Kusto Ingestモジュールのタグ作成時にもリリース処理が走る |
| ジョブ構成 | 単一の build ジョブ | build-data と build-ingest に分割 | Data用とIngest用のリリース処理を分けて管理できる |
| タグ判定 | Dataモジュール向けの条件 | refs/tags/azkustodata/ と refs/tags/azkustoingest/ を個別判定 | 誤ったモジュール向けにリリース処理が走りにくくなる |
TAG_PREFIX_REGEX | azkustodata/v | Dataは azkustodata/v、Ingestは azkustoingest/v | GitHub Release作成時のタグ接頭辞を各モジュールに合わせられる |
| Go Proxy反映 | Data側で実行 | Ingest側でも実行 | 新しいIngestモジュール版がGoの依存関係解決で見つかりやすくなる |
PRの差分では、on.push.tags に azkustoingest/** が追加され、build-ingest ジョブが新設されています。build-ingest は refs/tags/azkustoingest/ で始まるタグに対して動作し、TAG_PREFIX_REGEX に azkustoingest/v を指定しています。(GitHub)
Added、Changed、Fixed、Removed、Securityで見る今回の内容
Added
今回追加されたのは、アプリケーションAPIではなくリリースワークフロー上の設定です。
azkustoingest/** というタグパターンがGitHub Actionsのトリガーに追加されました。これにより、azkustoingest/v1.2.2 のようなIngestモジュール用タグが作成された場合にも、リリース処理の対象になります。(GitHub)
開発者にとって重要なのは、azkustodata と azkustoingest が同じリポジトリ内にあっても、リリース単位としては別モジュールとして扱われる点です。依存関係管理ツールや社内ドキュメントで「azure-kusto-go」とだけ記載している場合は、Data用なのかIngest用なのかを明確にしておくと、更新漏れを防げます。
Changed
既存の build ジョブは、Data用の build-data とIngest用の build-ingest に分けられました。Data側は refs/tags/azkustodata/、Ingest側は refs/tags/azkustoingest/ で始まるタグに反応します。(GitHub)
これは単なる名前変更ではなく、マルチモジュール構成のリポジトリでリリース対象を正しく分離するための変更です。Goのプロジェクトで依存関係を更新する場合、azkustodata のバージョンだけを確認しても、azkustoingest の更新を把握できない可能性があります。
Fixed
修正されたのは、Kusto Ingestパッケージのリリースが正しく扱われるためのワークフローです。PR上でも、Copilotのレビュー概要として「azkustoingest モジュールのタグ付けで自動GitHub Releaseを起動できるようにする」と説明されています。(GitHub)
注意したいのは、この「Fixed」がAzure Data Explorerの取り込み処理そのもののバグ修正を直接意味するわけではない点です。今回のPRはリリース経路の修正です。実際のSDK機能や不具合修正の内容は、対象バージョンのリリースノートやCHANGELOGで確認する必要があります。
たとえば azkustoingest/v1.2.2 では、キュー取り込み時の圧縮メタデータ処理、GZIPソースのサイズ推定、MSAL Goの更新などが記載されています。圧縮ファイルを取り込んでいる環境や、ソブリンクラウドを利用する環境では、このような実際のパッケージ変更点も合わせて確認すべきです。(GitHub)
Removed
今回のPRでは、利用者向けAPI、SDK機能、Azure Data Explorerの設定項目が削除されたとは示されていません。
そのため、今回のリリースワークフロー修正だけを理由に、既存コードのimport文、Kustoクラスター設定、取り込み先テーブル、マッピング定義を削除・変更する必要はありません。
ただし、古いSDKから新しい azkustoingest 系のモジュールへ移行する場合は別です。azure-kusto-go のCHANGELOGでは、v1.0.0でメインモジュールが azkustodata と azkustoingest に分割され、Go最小バージョンやクライアント生成方法にも破壊的変更があったことが記載されています。既に古い kusto/ingest 系のコードを使っている場合は、今回のPRとは別に移行計画が必要です。(GitHub)
Security
今回のPRは、セキュリティ脆弱性の修正として告知されたものではありません。Security に該当する利用者向けの緊急対応も示されていません。
一方で、リリースワークフローはソフトウェアサプライチェーンに関わる領域です。自社で同様のGitHub Actionsを運用している場合は、外部ActionやDockerベースのリリースツールをどのように固定しているか、リリースに使う GITHUB_TOKEN の権限が過剰でないか、タグ作成権限を誰が持っているかを確認しておくと安全です。
今回のワークフローでも、contents: write などリリース作成に必要な権限が設定され、Go Proxyへの反映用Actionが使われています。自社のフォークや参考実装に取り込む場合は、組織のセキュリティ基準に合わせてActionのバージョン固定や権限の最小化を検討してください。(GitHub)
影響を受ける対象者
今回の更新は、すべてのAzure利用者に影響するものではありません。影響が大きいのは、Azure Data Explorerへのデータ取り込みをGoで実装しているチームです。
| 対象者 | 影響度 | 確認すべきこと |
|---|---|---|
Goで azkustoingest を使っている開発者 | 高 | go.mod の依存バージョン、更新テスト、取り込み処理の回帰確認 |
| Azure Data Explorerのデータ基盤管理者 | 中 | 取り込み方式、権限、テーブルマッピング、監視項目 |
| CI/CD・DevOps担当者 | 中 | GitHub Release監視、DependabotやRenovateの検知条件、社内Go Proxyの更新 |
azkustodata だけを使うクエリ実装者 | 低 | Ingestモジュールを使っていなければ直接影響は限定的 |
| .NET、Java、Python、Node.js SDK利用者 | 低 | 今回のPRはGo SDKリポジトリのワークフロー修正であり、他言語SDKの変更ではない |
特に注意したいのは、アプリケーションがKustoへ「問い合わせるだけ」なのか、「データを取り込む」のかの違いです。前者は主に azkustodata、後者は azkustoingest が関係します。ログ、メトリック、IoTデータ、CSV/JSONファイルなどをAzure Data Explorerへ投入しているGoアプリは、今回の確認対象に入ります。
管理者と開発者がまず確認すべきこと
go.mod で利用中のモジュールを確認する
最初に、対象アプリケーションが azkustoingest を使っているか確認します。
go list -m all | grep azure-kusto-gogithub.com/Azure/azure-kusto-go/azkustoingest が表示される場合は、Kusto Ingestパッケージを利用しています。次に、更新可能なバージョンを確認します。
go list -m -u github.com/Azure/azure-kusto-go/azkustoingestバージョンを上げる場合は、いきなり本番環境へ反映せず、ステージング環境で取り込みテストを行ってください。
go get github.com/Azure/azure-kusto-go/[email protected]
go mod tidy
go test ./...azkustodata も同時に使っている場合は、両方のバージョン関係を確認します。片方だけを更新すると、認証、接続文字列、型定義、内部依存関係の差でビルドやテストに失敗することがあります。
GitHub Releaseやタグ監視の条件を見直す
CI/CDでGitHub Releaseを監視している場合は、azkustodata/v だけでなく azkustoingest/v も対象に含める必要があります。
依存関係更新ツールを使っている場合は、以下を確認してください。
| 確認項目 | 見落とした場合のリスク |
|---|---|
azkustoingest のタグを監視対象にしているか | Ingestパッケージの更新を検知できない |
go.mod のモジュールパスを正しく認識しているか | Data用とIngest用を混同する |
@latest に頼らずバージョンを固定しているか | 意図しないタイミングで本番ビルドが変わる |
| 社内Go Proxyが新バージョンを取得できるか | ローカルでは成功し、CIでは失敗する |
| リリースノートをレビューする運用があるか | 圧縮、認証、取り込み方式の変更を見逃す |
Goの依存関係は、GitHubのタグ、Go Proxy、チェックサムデータベース、社内キャッシュのどこかで詰まることがあります。特に閉域環境や社内Proxyを使っている組織では、GitHub Releaseが作成されただけでは社内ビルドがすぐに新バージョンを解決できない場合があります。
取り込み方式ごとのテスト観点を分ける
azkustoingest は複数の取り込み方式を扱います。更新確認では、単にビルドが通るかだけでなく、自社で使っている取り込み方式ごとに確認内容を分けることが重要です。
| 取り込み方式 | テスト観点 |
|---|---|
| キュー取り込み | Blob URL、ファイル拡張子、圧縮形式、取り込み完了までの遅延、失敗時の再試行 |
| ストリーミング取り込み | 低レイテンシ要件、クラスター側の有効化、テーブルまたはDBのポリシー |
| マネージド取り込み | エンドポイント補正、既定DB・テーブル、認証方式 |
FromReader / ストリーム | Writerのクローズ、タイムアウト、メモリ使用量、部分失敗時のログ |
| Azure Blob Storageからの取り込み | SAS、有効期限、ネットワーク制限、ファイルサイズ、マッピング |
Microsoft Learnでは、ストリーミング取り込みは低レイテンシが必要な場合に有効ですが、1テーブルあたりのデータ流量が大きい場合はキュー取り込みを検討するよう説明されています。また、ストリーミング取り込みを使うにはクラスターで機能を有効化し、対象テーブルまたはデータベースにポリシーを定義する必要があります。(Microsoft Learn)
移行・展開時に注意すべきポイント
今回の更新だけでAzure側の設定変更は不要
今回のPRはGitHub Actionsのリリース処理に関する修正です。Azure PortalでAzure Data Explorerクラスターの設定を変更したり、取り込みポリシーを作り直したりする必要はありません。
ただし、SDKバージョンを更新する場合は、アプリケーション側の影響を確認してください。特に、圧縮ファイルの取り込み、CompressionType の指定、GZIPファイル、ソブリンクラウド向け認証を使っている場合は、対象バージョンのCHANGELOGを読んだうえでテストするのが安全です。azkustoingest/v1.2.2 では、圧縮メタデータ処理やGZIPソースのサイズ推定、MSAL Goの更新が記載されています。(GitHub)
古いコードからの移行は「今回のPR」と切り分ける
古い github.com/Azure/azure-kusto-go/kusto/ingest 系のコードを使っている場合、今回のリリースワークフロー修正だけを見て移行可否を判断しないでください。
v1.0.0以降の azure-kusto-go では、メインモジュールが azkustodata と azkustoingest に分割され、取り込みクライアントの構築方法も KustoConnectionStringBuilder を使う形に変わっています。これは今回のPRより大きな移行ポイントです。(GitHub)
移行時は、次の順序で進めると失敗しにくくなります。
| 手順 | 作業内容 | 確認ポイント |
|---|---|---|
| 1 | 現在のimportパスを棚卸しする | 古い kusto/ingest と新しい azkustoingest が混在していないか |
| 2 | go.mod の依存を確認する | azkustodata と azkustoingest のバージョン |
| 3 | 認証方式を確認する | サービスプリンシパル、マネージドID、Azure CLI認証のどれを使うか |
| 4 | 取り込み方式ごとのテストを作る | ファイル、Blob、Reader、ストリーミングのどれを使うか |
| 5 | ステージングで実データに近い投入テストを行う | 圧縮、マッピング、失敗時ログ、再試行 |
| 6 | 本番反映後に取り込み遅延と失敗件数を監視する | ADX側の失敗、アプリログ、CI/CDログ |
.ingest into コマンドとSDK取り込みを混同しない
Azure Data Explorerには、KQLの .ingest into コマンドでクラウドストレージからデータを取り込む方法もあります。ただし、Microsoft Learnでは、この方法は探索やプロトタイプ作成向けであり、運用環境や大量データのシナリオでは使用しないよう注意されています。(Microsoft Learn)
本番運用でGoアプリから継続的にデータを投入する場合は、azkustoingest のキュー取り込みやストリーミング取り込みを使い、失敗時の再試行、監視、権限、マッピングをアプリケーション設計に組み込むべきです。
インジェストプロパティのばらつきに注意する
データ取り込みでは、フォーマット、マッピング、タグ、圧縮、作成時刻などのインジェストプロパティが重要です。Microsoft Learnでは、キュー取り込みデータはインジェストプロパティを使ってバッチ処理され、使用するマッピングプロパティが異なるほど断片化が増えてパフォーマンスが低下する可能性があると説明されています。(Microsoft Learn)
SDK更新後のテストでは、以下のような「見た目は小さいが本番で効く」差分を確認してください。
| 観点 | 確認例 |
|---|---|
| フォーマット | CSV、JSON、Parquetなど、実際の形式と指定が一致しているか |
| マッピング | IngestionMappingRef の名前が環境ごとにずれていないか |
| 圧縮 | .gz ファイル、明示的な CompressionType、拡張子判定が期待通りか |
| タグ | ingest-by タグや重複防止に使うタグが変わっていないか |
| サイズ推定 | GZIPなど圧縮データで分割・バッチングに影響が出ていないか |
| 失敗時ログ | 取り込み失敗がアプリログとADX側の状態確認で追えるか |
よくある誤解と失敗しやすいポイント
「Azure Data Explorerのサービス仕様が変わった」と誤解する
今回の更新は、Azure Data Explorerのクラスター設定やKustoの取り込み仕様を変更するものではありません。変更対象は azure-kusto-go リポジトリのリリースワークフローです。
そのため、クラスターのスケール、ストリーミング取り込みの有効化、テーブルスキーマ、マッピング定義を急いで変更する必要はありません。対応すべきなのは、主にSDK利用側の依存関係管理とリリース検知です。
azkustodata の更新だけを見てしまう
同じ azure-kusto-go リポジトリにあるため、azkustodata のリリースだけを見て「Go SDKは最新」と判断しがちです。しかし、取り込み処理を使っている場合は azkustoingest のリリースも別に確認する必要があります。
特に、Dependabot、Renovate、社内ポータル、脆弱性スキャナーがモジュール単位の更新を正しく認識しているか確認してください。
本番で @latest 相当の更新をしてしまう
本番ビルドで暗黙に最新バージョンへ上がる構成は避けるべきです。Goでは go.mod と go.sum による固定が基本ですが、CIのスクリプトやDockerfile内で go get ...@latest を実行していると、意図せずSDKが更新されることがあります。
安全な運用では、次の流れを徹底します。
go get github.com/Azure/azure-kusto-go/[email protected]
go mod tidy
go test ./...その後、ステージング環境で実際の取り込みを検証し、問題がなければ本番へ展開します。
圧縮ファイルの取り込みを軽く見てしまう
azkustoingest/v1.2.2 のCHANGELOGには、キュー取り込みの圧縮メタデータ処理やGZIPソースのサイズ推定に関する修正が含まれています。(GitHub)
ログ基盤では、転送量削減のためにGZIP圧縮されたCSVやJSONをBlob Storageへ置き、そこからKustoへ取り込む構成がよくあります。この場合、ファイル拡張子、明示的な圧縮指定、RawDataSize、マッピングの組み合わせで挙動が変わる可能性があります。
更新後は、少なくとも次の3パターンをテストしてください。
| パターン | テスト内容 |
|---|---|
| 非圧縮ファイル | 従来通り取り込めるか |
.gz 拡張子付きファイル | 圧縮形式が正しく認識されるか |
| 明示的に圧縮タイプを指定する処理 | 拡張子より設定値が期待通り優先されるか |
実務での対応チェックリスト
今回の更新に対して、管理者と開発者が行うべき確認をまとめると次の通りです。
| チェック項目 | 担当 | 優先度 |
|---|---|---|
Goアプリが azkustoingest を使っているか確認する | 開発者 | 高 |
go.mod と go.sum の依存バージョンを確認する | 開発者 | 高 |
azkustoingest/v タグをリリース監視対象に含める | DevOps | 高 |
| ステージングで取り込みテストを実行する | 開発者 | 高 |
| 圧縮ファイル、Blob、Readerなど実運用パターンで検証する | 開発者 | 高 |
| Azure Data Explorer側の権限、テーブル、マッピングを再確認する | 管理者 | 中 |
| 社内Go Proxyや依存関係スキャナーの検知状況を確認する | DevOps | 中 |
| 古いSDKからの移行が必要か切り分ける | 開発者 | 中 |
| GitHub Actionsをフォークしている場合はワークフロー差分を反映する | DevOps | 中 |
| リリース用Actionのバージョン固定と権限を見直す | セキュリティ担当 | 中 |
まとめ：コード変更よりも、リリース検知と依存関係管理を確認する
今回の「fix: Kusto Ingest package release」は、Azure Data Explorerの取り込み機能そのものを変更する更新ではなく、Go SDKの azkustoingest パッケージを正しくリリースするためのGitHub Actions修正です。利用者側で直ちにAzure設定を変更する必要はありません。
一方で、GoでKusto Ingestを使っているチームにとっては、リリースが検知しやすくなる重要な変更です。まず go.mod を確認し、azkustoingest のバージョン、CI/CDのタグ監視、社内Go Proxy、ステージングでの取り込みテストを点検してください。
次に取るべき行動は明確です。自社アプリが azkustoingest を使っているかを確認し、使っている場合はリリースノートを読んだうえで、圧縮ファイル、Blob Storage、ストリーミング、認証方式など実運用に近い条件で回帰テストを行いましょう。これにより、SDK更新のメリットを受けつつ、データ取り込み基盤の安定性を保てます。
コメント