Azure Files の変更フィード (プレビュー)

Azure Filesの変更フィードは、Azureファイル共有内のファイルやディレクトリの変更の、持続的で順序付けられた、不変かつ読み取り専用のログを提供します。アプリケーションはストリーミングモードやバッチモードでフィードを処理し、共有全体を繰り返しスキャンすることなく変更を特定できます。

Azure Filesの変更フィードを使って、以下のソリューションを構築しましょう:

インクリメンタルバックアップと災害復旧を実行してください。
検索インデックス、キャッシュ、またはカタログを維持しましょう。
データを別のストアまたはオンプレミスのファイルシステムに同期します。
ファイルやディレクトリの変更を監査・分析します。
変更されたコンテンツを処理するパイプラインを動かしましょう。

Note

プレビューへのアクセスはサブスクリプションごとに有効になります。プレビューサインアップフォームに記入してください:プレビューに登録:Azure Files Change Feed。

チームは承認済みのサブスクリプションに対してプレビューを有効にし、機能が利用可能になった際に連絡します。プレビューアクセスが許可されてからのみAzure Filesの変更フィードを有効にすることができます。

Important

この機能は現在プレビューの段階です。ベータ版、プレビュー版、または他の方法で一般公開されていない Azure の機能に適用される法的条件については、Microsoft Azure プレビューの追加利用規約を参照してください。

変更フィードのしくみ

変更フィードの有効化は2ステップの操作です。まず、ストレージアカウントでその機能を有効にしてください。その後、追跡したい各ファイル共有で変更フィードを有効にします。この範囲は、アカウント全体で一度だけ有効にするBlob Storageの変更フィードとは異なります。

追跡されたシェアのすべてのサポートデータやメタデータの変更は、追記専用のApache Avroログにイベントとして記録されます。サービスは各共有のログを同じストレージアカウント内のシステムブロブコンテナに保存します。

チェンジフィードの特徴は以下の通りです:

秩序付けられたものと不変なもの: イベントは セグメントと呼ばれる時間窓にまとめられます。セグメントが確定した後は変更されないため、読み取りは繰り返し可能で、コンシューマーは保存した位置から再開できます。
非同期: イベントは、それを生成した操作が完了した直後に利用可能になります。フィードの変更は同期通知の仕組みではありません。
再開可能: 消費者は継続トークンを永続化し、中断後に再開できます。
設定可能な保持: サービスは共有に設定された保持期間の終了後に自動的にイベントを削除します。
独立した消費者: 各アプリケーションはログを独立して読み取り、ログに対してチェックポイントを個別に記録します。

ログは変更フィードを有効にした後に始まります。サービスは変更フィードを有効にする前やフィードが無効になっている間に行われた変更を記録しません。

機能のサポート

Item	プレビューのサポート
課金モデル	標準的な従量課金
Premium ファイル共有	サポートしていません
プロトコルを共有	SMBおよびFile REST API
追跡された操作	SMBおよびFile REST API上で行われたデータおよびメタデータの変更
最小ファイルサービスバージョン	`2026-02-06`
最低管理 API バージョン	`2026-04-01`
クライアントライブラリ	.NET `Azure.Storage.Files.Shares.ChangeFeed`プレリリースパッケージ

変更フィードの有効化と設定

変更フィードの構成は管理プレーンを使用します。 File REST API、SMB、NFSを通じて変更フィードの有効化、無効化、再構成はできません。データプレーンは現在の設定とログの位置を報告し、利用者がフィードを見つけることができます。

ストレージアカウントを作成する際は、データ保護 タブで ファイル変更フィード を有効にしてください。既存のファイル共有で変更フィードを設定する際にも、アカウント機能を有効にすることができます。

以下の管理リクエストを送信し、ストレージアカウントを更新する権限を持つアクセストークンを添えて送信してください:

PATCH https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>?api-version=2026-04-01
Authorization: Bearer <access-token>
Content-Type: application/json

{
  "properties": {
    "enableFilesChangeFeed": true
  }
}

このプロパティを有効にすると、サービスはアカウント上でBlob Storageエンドポイントをプロビジョニングします。なぜなら、変更フィードログをブロブとして保存するためです。

Azure Portal
REST API

PATCH https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>/fileServices/default/shares/<file-share>?api-version=2026-04-01
Authorization: Bearer <access-token>
Content-Type: application/json

{
  "properties": {
    "changeFeedEnabled": true,
    "changeFeedRetentionInDays": 7
  }
}

保持を指定せずに変更フィードを有効にすると、デフォルトは7日間になります。有効な保持期間は1日から365日までです。保持率を上げても、サービスがすでに削除したレコードは復元されません。

構成を確認する

クライアントは、「ファイルサービスバージョン 2026-02-06 以降で共有プロパティの取得」を呼び出すことでログを確認できます:

GET https://<storage-account>.file.core.windows.net/<file-share>?restype=share
x-ms-version: 2026-02-06
Authorization: Bearer <access-token>

この応答には、次のヘッダーが含まれています:

x-ms-file-enable-change-feed: True
x-ms-file-change-feed-retention-in-days: 7
x-ms-file-blob-container-for-xfiles-change-feed: $fileschangefeed-<GUID>

これらの値は共有スナップショットでは返されません。変更フィードが一度も構成されたことのない共有は、false と 0 を報告します。

変更フィードを無効にする

Azure portal でストレージアカウントを開きます。
データストレージで ファイル共有 を選択し、その後ファイル共有を選択します。
概要ページ、プロパティ>機能ステータスの下、「変更フィード」の横にあるステータスを選択してください。
変更フィードを有効にする をクリアします。
保存を選択します。

変更フィードを無効にすると、システムは新しいイベントの記録を停止します。既存の記録は保存期間が満了するまで閲覧可能です。

アカウント機能をオフにするには、 enableFilesChangeFeed を falseに設定してください。アカウント内のどのシェアにも変更フィードデータがある限り、アカウント機能性を無効にすることはできません。リクエストはFilesChangeFeedContainersExistで失敗します。すべての共有で変更フィードを無効にし、保持ログデータの期限が切れるのを待ちましょう。

変更フィードを使用する

変更フィードを読み取る推奨の方法は、.NET クライアントライブラリを使用することです。クライアントはログ発見、セグメントの順序付け、最後の消費可能なウォーターマーク、Avroのデシリアライズ、リセット検出、再開可能読み取りを処理します。

プレリリースパッケージをインストールしてください:

dotnet add package Azure.Storage.Files.Shares.ChangeFeed --prerelease

既存の ShareClientからクライアントを作成し、利用可能なイベントを列挙します:

using Azure.Identity;
using Azure.Storage.Files.Shares;
using Azure.Storage.Files.Shares.ChangeFeed;

var serviceUri = new Uri("https://<storage-account>.file.core.windows.net");
var shareClient = new ShareServiceClient(serviceUri, new DefaultAzureCredential())
    .GetShareClient("<file-share>");

ShareChangeFeedClient changeFeedClient =
    shareClient.GetShareChangeFeedClient();

await foreach (ShareChangeFeedEvent change in changeFeedClient.GetChangesAsync())
{
    Console.WriteLine(
        $"{change.EventTime:o} {change.Reason} {change.EventData.FullFilePath}");
}

クライアントは次のメソッドを提供します:

最後の消費可能なウォーターマークまでのすべてのイベントを列挙してください。
制限された時間範囲を読み取る。
継続トークンから再開。
2つのシェアスナップショット間の変化を列挙します。
ログの最新の完全で安全なポイントを取得しましょう。
スナップショットメタデータが最終化されているか確認してください。

継続トークンで再開

長時間実行されるコンシューマーの場合、ページごとに列挙し、ページ全体を正常に処理した後にのみ継続トークンを永続化します。

string? continuationToken = LoadCheckpoint();

await foreach (Page<ShareChangeFeedEvent> page in
    changeFeedClient.GetChangesAsync(continuationToken).AsPages())
{
    foreach (ShareChangeFeedEvent change in page.Values)
    {
        Process(change);
    }

    SaveCheckpoint(page.ContinuationToken);
}

継続トークンは、それを発行したストレージアカウントに関連付けられます。保存したトークンは GetChanges や GetChangesBetweenSnapshotsに渡し、 AsPagesには渡さないでください。

ログを直接読んでみてください

変化フィードクライアントライブラリを持たない言語では、Blob Storageクライアントライブラリでシステムコンテナを読み取ることができます:

Get Share Propertiesに連絡し、 x-ms-file-blob-container-for-xfiles-change-feedのコンテナ名を読み上げてください。
meta/reset-latest.jsonを読み、新しいリセット識別子がないか確認してください。
meta/segments.jsonを読んで、lastConsumableの透かしに注目してください。
透かしまでの各セグメントについて、その meta.json ファイルを読み、その状態が Finalized であることを確認しましょう。
chunkFilePathsが挙げたAvroのブロブを読んでみてください。
記録を処理し、チェックポイントをウィンドウの終わりまで進めてください。

Warning

システムコンテナはサービスによって管理されます。内容は読み取り専用として扱いましょう。これらのコンテナ内のオブジェクトを書き込んだり、修正したり、削除したりしないでください。パスを構築したりウィンドウ長をハードコーディングする代わりに、セグメントのメタデータからセグメントの長さやログ位置を読み取ること。

各共有は「$fileschangefeed-<GUID>」という名前のコンテナを使用します。アカウントレベルの $fileschangefeedsys コンテナはサービス用途に予約されており、顧客の認証情報ではアクセスできません。

変更イベント記録

各Avroの記録は1つの変更点を記述しています。現在のスキーマバージョンは 0です。

Field	Description
`SchemaVersion`	レコードスキーマのバージョン。フィールドを名前で読み、認識されていないフィールドは無視してください。
`Reason`	変更を説明するコード。
`Protocol`	変化をもたらしたプロトコル: `Smb`、 `Rest`、または `Unknown`。
`EventTime`	変更が行われたUTC時間。
`Id`	操作の相関識別子。
`Cvnt`	変更時点のシェアのコンテナバージョン番号。
`Data.FileId`	ファイルやディレクトリの安定識別子。
`Data.ParentFileId`	親ディレクトリのID。
`Data.NewParentFileId`	名前変更や移動のための目的地親ID
`Data.Etag`	変更後のエンティティタグ。
`Data.FileName`	ディレクトリパスを含まないアイテム名
`Data.FullFilePath`	変更時点のシェアルートに対するパス。
`Data.NewFullFilePath`	名前変更や移動のための宛先パス。
`Data.IsDirectory`	項目がディレクトリかどうかを示します。
`Data.Identity`	予約済みの識別子フィールド。これらのフィールドは現在のプレビューでは表示されません。
`Data.Initiator`	イニシエーターフィールドは予約済みです。このフィールドは現在のプレビューでは表示されません。

利用できない文字列値は N/Aとして出力されます。 NewParentFileId と NewFullFilePath は、イベントが名前変更やムーブでない場合は空のままです。両方の形式を値なしとして扱ってください。

理由コードの変更

理由コードには以下の値が含まれます:

Protocol	理由コード
SMB	`SmbCreate`、 `SmbRename`、 `SmbDelete`、 `SmbWrite`、 `SmbExtend`、 `SmbCreateTruncate`、 `SetInfo`、 `SetSecurityInfo`
REST	`RestCreate`、 `RestRename`、 `RestDelete`、 `RestWrite`、 `RestCreateTruncate`、 `RestSetInfo`、 `RestSetSecurityInfo`、 `SyncCopyFile`、 `AsyncCopyFile`
Service	`RESET`、`ControlEvent`、`UnknownEventType`

リストは時間とともに増えていくことがあります。コンシューマーが認識できない理由コードを無視するように設計します。 ControlEventやUnknownEventType記録は無視しましょう。

リセットイベントの処理

リセットはログが以前の履歴と連続しなくなる境界を示します。境界前の記録が欠落していたり、共有に反映されなくなった変更を記述している場合があります。境界以降の記録は完全で、共有と一致しています。

リセットは、顧客管理の予定外フェイルオーバー後や、サービスがアカウントの変更追跡を再開したときに発生することがあります。サービスは、インバンド RESET レコードとして、また meta/resets/下のマーカーブロブとしてリセットを報告します。

meta/reset-latest.jsonポインタは最新のリセットマーカーを示します:

{
    "schemaVersion": 1,
    "latestResetId": "9f2c1c6e-4c0a-4d1e-9d6b-2b7a4c1e83f0",
    "latestResetFileTime": 134288352000000000,
    "latestResetTimeUtc": "2026-07-18T08:00:00.000Z",
    "accountName": "mystorageaccount",
    "containerName": "myshare",
    "reason": "CustomerManagedUnplannedFailover",
    "latestMarkerPath": "meta/resets/00134288352000000000.json"
}

リセットされたことのないシェアのポインタは存在しません。 404応答はリセットなしとみなしましょう。 latestResetIdを使って新しい境界を検出し、latestMarkerPathを使ってその不変マーカーを読み取る。

コンシューマーが新しいリセット識別子を検出した場合:

インクリメンタル処理を停止し、リセット前に発行されたチェックポイントを破棄してください。
リセット識別子とリセット時間を記録します。
共有全体または新しい共有スナップショットを列挙してベースラインを再設定します。
リセット境界から増分処理を再開してください。

Important

リセット前後の記録を完全な履歴として扱ってはいけません。バックアップおよびレプリケーションワークロードはリセット後に完全な列挙を行う必要があります。

クライアントライブラリは、設定されたShareChangeFeedResetEventに応じて、ShareChangeFeedResetPolicyをスローするか、ShareChangeFeedResetExceptionを返すことができます。境界読み取りはリセットするとデフォルトで失敗します。オープンエンドリードはデフォルトでリセットイベントを順序通りに返します。

すべてのイベントにはコンテナのバージョン番号が含まれています。シェアスナップショットが取得されると、フィードはスナップショットをコンテナバージョンとそのバウンディングログウィンドウにマッピングするメタデータを書き込みます。

GetSnapshotStatusで終了スナップショットが確定したことを確認し、その後GetChangesBetweenSnapshotsで2つのスナップショット間のイベントを列挙します。スナップショットスコープクエリは継続トークンをサポートします。

Blob Storageの変更フィードとの違い

Azure Filesの変更フィードは、Blob Storageの変更フィードのコンテナレイアウト、Avroエンコーディング、セグメントモデル、そして最後に使用可能なウォーターマークを使用しています。以下の表は主な違いを示しています。

特徴	Blob Storage 変更フィード	Azure Files change feed
Scope	アカウントごとに一度有効にすると、すべてのコンテナに適用されます。	アカウントで有効化し、その後各シェアで有効化します。
ログの場所	アカウントごとに1つの `$blobchangefeed` コンテナ。	共有ごとに `$fileschangefeed-<GUID>` コンテナー 1 つ。
ログ検出	よく知られたコンテナ名を使っています。	Get Share Propertiesから返されるコンテナ名を使用します。
アイテム識別	ブロブの名前を使っています。リネームは、コピーしてから削除する操作です。	安定したファイル ID と親 ID を使用しています。リネームや移動はファイルIDを保持します。
Hierarchy	ブロブ名には `/`を含めることができますが、ディレクトリは独立したリソースではありません。	ディレクトリリソースとディレクトリイベントを含みます。
スナップショット統合	スナップショットスコープの変更列挙は公開しません。	スナップショットスコープクエリにはコンテナバージョン番号とスナップショットメタデータを使用します。
プロトコルの割り当て	適用されません。	SMBまたはREST上で変更があったかどうかを特定します。
不連続	リセットマーカーは表示しません。	フェイルオーバーと追跡リセットの境界を特定するためにリセットマーカーを使用します。

価格と請求

サービスは変更フィードデータを同じストレージアカウント内のブロブとして保存します。請求システムは、保存されたログデータと読み取りリクエストに対して、適用されるBlob Storage料金で料金を請求します。保持期間と変更量はストレージコストとトランザクションコストに直接影響します。 Azure Filesの請求モデルに関する詳細は「Azure Files の課金について理解する」をご覧ください。

プレビューの制限事項

変更フィードは、プレビューの承認を受けたサブスクリプションでのみ利用可能です。
プレミアムファイル共有やNFS操作はサポートされていません。
設定は管理プレーンを使用し、File REST API、SMB、または NFS 経由では利用できません。
共有スナップショットでは設定が返されず、スナップショットやソフト削除された共有にも設定できません。
イベントは非同期であり、フィードが有効である間に行われた変更のみが記録されます。
識別フィールドとイニシエーターフィールドは入力されていません。
消費者は未知のフィールドや理由コードを許容し、リセットにも対応しなければなりません。
非同期コピーはコピーが開始されたときにイベントを発生させますが、終了時には発生しません。
既存のファイルを置き換えるリネームでは、置き換えられたファイルを特定しません。

次のステップ

フィードバック

このページはお役に立ちましたか?

最終更新: 2026-10-17