Azure Storage Explorer v1.40.0 がリリースされました

ブログ エントリ内にアフィリエイト広告が含まれています

2025/09/26 に Azure Storage Explorer v1.40.0 がリリースされました。

このブログ エントリでは、Azure Storage Explorer v1.40.0 のリリース ノート (英語) の内容を日本語に意訳してまとめています。

スポンサーリンク

Azure Storage Explorer v1.40.0 について (意訳)

September 2025 (Version 1.40.0, build 20250925.27)

Storage Explorer バージョン 1.40.0 にようこそ。このリリースでは、ファイル共有とテーブルの新しい機能を追加しました。クローズされたすべての問題の詳細なリストは、issue ページを確認してください。

NFS File Shares

Storage Explorer で NFS ファイル共有の操作をサポートするようになりました。また、Premium ファイル ストレージ アカウントにアクセスできる場合、それらのアカウントで NFS ファイル共有を管理できるようになりました。

このリリースでは、Storage Explorer は次の操作をサポートしています :

  • NFS ファイル共有を作成します。新しいファイル共有名を入力すると、Storage Explorer で SMB ファイル共有と NFS ファイル共有のどちらを作成するかどうかの確認があります。
  • ストレージ アカウント間で NFS ファイル共有をコピー&ペーストします。
  • NFS ファイル共有スナップショットを作成/管理/削除します。
  • NFS ファイル共有間でファイルとフォルダーをコピー&ペーストします。NFS と SMB、SMB と NFS、NFS と Blob、Blob と NFS 間転送は、今後のリリースで利用可能になる予定です。
  • NFS ファイル共有へアップロード/ダウンロードします (Linux のみ、Windows および macOS のサポートは今後のリリースで提供予定です)。

NFSの変更を反映するため、「譲渡」→「情報の保持」および「譲渡」→「アクセス許可の保持」の設定をアップデートしました。NFSファイル共有からアップロード/ダウンロードを行う際、これらの設定を有効にすることを推奨します。これにより、ファイルのダウンロード時に所有権に関する問題が発生するのを防止することができます。

NFS ファイル共有からダウンロードする場合、AzCopy はローカル ファイルの所有権を NFS ファイル共有内のファイルの所有権と一致させるように変更しようとします。Linux ユーザーが所有者でない場合はエラーが発生する可能性があります。所有権関連のエラーを回避するには、Storage Explorer で使用される AzCopy コマンドをコピーし、sudo を使用してコマンドラインから直接実行します。

Azure は NFS ファイル共有のサポートを継続しています。プラットフォームの機能がさらに充実するにつれ、NFS サポートも引き続き改善します。

Table インポート/エクスポートに対する JSON サポート

Storage Explorer は、JSON 形式でのテーブル データのインポートとエクスポートのオプションをサポートするようになりました。JSON は CSV よりも開発者のワークフローに適しています。

JSON フォーマット

期待される JSON 形式について、"payload format for table service operations" に類似しています :

[
  {
    "PartitionKey": "p1",
    "RowKey": "r1",
    "Value1": "1",
    "Value1@type": "Int32",
    "Value2": "1.4",
    "Value2@type": "Edm.Double",
    "Value3": "true",
    "Value3@odata.type": "Boolean",
    "Value4": "example",
    "Value4@type": "Edm.String"
  },
  {
    "PartitionKey": "p1",
    "RowKey": "r2",
    "Value1": "2",
    "Value2": "1.5"
  }
]

型注釈はオプションであり、@type もしくは @odata.type サフィックスを用いて表現することができます。型の値には Edm. プレフィックスを含めることが可能です。

データ損失を防止するため、Storage Explorer ではすべての値が JSON 文字列として表現されることを想定しています。これにより、大きな Int64 値や特定の Double 値などの数値を解析する際の精度エラーを回避します。

Storage Explorer は型注釈なしでもデータ型推測可能ですが、型を明確に特定できない状況もあります。例えば、"123" は Int32 もしくは Int64 である可能性があり、"Jane" は Binary もしくは String である可能性があります。そのため、可能な限り型注釈を付与することを推奨します。

型アノテーションをスキーマとして使用する

テーブルのインポートが改善され、スキーマに準拠したデータをより適切に処理できるようになりました。

Azure テーブルは本質的にスキーマレスです。つまり、テーブル内のすべてのエンティティが同じデータ型の同じプロパティセットを持つことは保証されません。しかし、ユーザーはスキーマを用いてデータをモデル化することがよくあります。そのような場合、インポート/エクスポート ファイル内のすべてのエンティティに対する型注釈は不要になります。

このバージョンでは、最初のエンティティの型注釈のみをエクスポートするオプションを追加しました。このオプションにより、重要な型情報を保持しながらエクスポート ファイルのサイズを削減可能です。

Storage Explorer は、最初のエンティティにのみ型注釈が付けられたファイルを活用できます。インポート ファイルを選択すると、インポート ダイアログで最初のいくつかのエンティティがサンプリングされ、各プロパティに最適な型が決定されます。"注釈のないプロパティ値の型を推測する" オプションを無効にすることで、Storage Explorer はファイル内の最初のエンティティの型注釈に基づいてプロパティの型を選択します。

型のサンプリングは必ずしも期待どおりに機能するとは限らないため、その点はご注意ください。サンプリングされたデータが最初のエンティティの型注釈と一致しない場合、もしくは複数のエンティティに型注釈が存在する場合、Storage Explorer は異なる型を選択することがあります。これにより、インポート中に型関連のエラーが発生する可能性があります。データが適切にフォーマットされていること、およびすべての値の型が明確に判別できることを必ず確認してください。

多要素認証の執行

すべての作成/更新/削除操作において、多要素認証 (MFA) がまもなく必要になります。サービスの中断を避けるため、ユーザー アカウントで MFA が有効になっていることを確認するか、管理者に確認する必要があります。MFA が有効になると、Storage Explorer へのサインインが再度必要になる場合があります。

詳細な情報は、"Planning for mandatory multifactor authentication for Azure and other admin portals" を参照してください。

スポンサーリンク

関連サイト

コメント

タイトルとURLをコピーしました