Azure StorageでData Lake Storage用のストレージアカウントを作成する場合、最初に確認すべき結論はシンプルです。Azure Data Lake Storageとして使うには、階層型名前空間（Hierarchical namespace / HNS）を有効にしたストレージアカウントを作成する必要があります。 対応するアカウント種別は主に「Standard general-purpose v2」と「Premium block blob」で、既存アカウントを使う場合はアップグレード可否や機能制限を事前に確認する必要があります。Microsoft Learnの該当ドキュメントでは、Data Lake Storage用アカウント作成時に選ぶべきアカウント種別と、作成画面のAdvancedタブで階層型名前空間を有効化する点が明示されています。 (Microsoft Learn)
この記事では、2026年5月時点の公式情報をもとに、Azure Storageの「Create a Storage Account for Data Lake Storage」で管理者・開発者が押さえるべき変更点、影響範囲、設定・移行・展開時の注意点を整理します。単に「HNSをオンにする」だけでなく、後から戻せない設定、既存Blob Storageからの移行、RBACとACL、ネットワーク・セキュリティ設定まで、実務で確認すべきポイントを解説します。
Azure StorageでData Lake Storage用アカウントを作る際の要点
Microsoft Learnの「Create a storage account to use with Azure Data Lake Storage」は、Azure StorageをAzure Data Lake Storageとして使うためのストレージアカウント作成手順を説明する公式ドキュメントです。内容自体は短いですが、設計上の重要点は大きく3つあります。
| 確認項目 | 要点 | 実務上の意味 |
|---|---|---|
| 階層型名前空間 | Data Lake Storage機能を使うにはHNSを有効化する | ディレクトリ単位の操作、ACL、分析基盤向けのファイルシステム的な扱いが可能になる |
| アカウント種別 | Standard general-purpose v2、Premium block blobが対象 | 汎用用途か、低レイテンシ・高トランザクション用途かで選ぶ |
| 既存アカウント | 既存Blob StorageにもData Lake Storage機能を追加できるが、アップグレードには注意が必要 | 本番環境では非本番で検証し、機能制限・停止計画を確認する |
Data Lake Storage機能は、Azure Blob Storage上に構築されたビッグデータ分析向けの機能です。HNSを有効にすると、オブジェクトを単なるフラットなBlob名として扱うのではなく、ディレクトリとサブディレクトリの階層として管理できます。 (Microsoft Learn)
何が変わるのか：単なる作成手順ではなく、設計判断が前倒しになる
今回の公式情報で特に重要なのは、Data Lake Storage用アカウントを作る際に、アカウント作成時点で判断すべき項目が明確になっていることです。
Azure Portalでストレージアカウントを作成する場合、Basicsタブでアカウント種別を選び、Advancedタブで「Enable hierarchical namespace」を有効化します。Standard general-purpose v2を作る場合はStandardを選択し、Premium block blobを作る場合はPremiumを選択したうえでPremium account typeにBlock blobsを指定します。 (Microsoft Learn)
ここで注意したいのは、HNSが単なる追加オプションではない点です。HNSを有効にしたアカウントは、Data Lake Storage向けのアクセス制御やディレクトリ操作に適した構成になります。一方で、すべてのBlob Storageワークロードに無条件で向いているわけではありません。Microsoftは、HNSを有効にした後はフラット名前空間に戻せないため、ワークロードの性質に応じて判断する必要があると説明しています。 (Microsoft Learn)
管理者が見るべき「変更点」の実務的な読み方
この更新は「新機能が突然追加された」というより、Data Lake Storage用のストレージアカウント作成で外してはいけない設定が整理されたものとして見るのが実務的です。
特に、これからデータ分析基盤、ETL、Spark、Synapse、Databricks、AI/ML用データレイクを作る場合は、通常のBlob Storageアカウントを流用するのではなく、最初からData Lake Storage用途としてアカウント種別とHNSを設計する必要があります。
逆に、画像配信、静的コンテンツ配信、単純なバックアップ保管など、ディレクトリ単位の高速な移動・リネームやPOSIXライクなアクセス制御を必要としない用途では、HNSを有効にしてもメリットが小さい場合があります。公式ドキュメントでも、バックアップや画像ストレージなど、オブジェクト構成を別の仕組みで管理するワークロードではHNSの恩恵を得にくい可能性が示されています。 (Microsoft Learn)
対象者：管理者、データ基盤担当、アプリ開発者が確認すべきこと
今回の内容は、Azureポータルでストレージアカウントを作る担当者だけでなく、データ基盤全体に関わる複数のロールに影響します。
| 対象者 | 確認すべきポイント | よくある失敗 |
|---|---|---|
| Azure管理者 | アカウント種別、リージョン、冗長性、ネットワーク、暗号化、HNS | 後からHNSの不可逆性や機能制限に気付く |
| データエンジニア | ディレクトリ構成、ACL、ETL処理、Sparkなどの分析基盤連携 | フォルダー設計が曖昧で権限管理が複雑化する |
| アプリ開発者 | Blob API、Data Lake API、認証方式、SDKの使い分け | Shared KeyやSAS前提でACL設計とずれる |
| セキュリティ担当 | Microsoft Entra ID、RBAC、ACL、匿名アクセス、TLS、ネットワーク制限 | ストレージキー依存が残り、最小権限にならない |
| 運用担当 | 監視、バックアップ、削除保護、コスト、移行手順 | 検証なしに既存アカウントをアップグレードする |
特に管理者と開発者の間で認識を合わせたいのは、ストレージアカウントは単なる保存先ではなく、権限・性能・コスト・移行難易度を左右する設計単位だという点です。
対応するストレージアカウント種別
Data Lake Storage機能を利用できる主なストレージアカウント種別は、公式ドキュメント上では次の2つです。
| アカウント種別 | 向いている用途 | 判断基準 |
|---|---|---|
| Standard general-purpose v2 | 一般的なデータレイク、分析、ETL、AI/MLデータ保管 | 迷ったら基本はこちら。冗長性やアクセス層の選択肢も広い |
| Premium block blob | 低レイテンシ、高トランザクション、小さいオブジェクトを大量に扱う処理 | 性能要件が明確で、コスト増を許容できる場合に検討 |
Microsoftのストレージアカウント概要では、Standard general-purpose v2はBlob、Azure Data Lake Storage、Queue、Table、Azure Filesを含む標準的なアカウント種別として説明されています。一方、Premium block blobは高いトランザクション率、小さいオブジェクト、安定した低レイテンシが必要なシナリオ向けとされています。 (Microsoft Learn)
実務では、最初からPremium block blobを選ぶよりも、次のように判断すると失敗しにくくなります。
| 判断項目 | Standard general-purpose v2を選びやすいケース | Premium block blobを検討するケース |
|---|---|---|
| 用途 | データレイク、分析基盤、ログ蓄積、ETL | 低レイテンシが要件に明記されている |
| データ量 | 大容量データを段階的に増やす | 小さいBlobへの高頻度アクセスが多い |
| コスト | コスト最適化を重視 | 性能優先で追加コストを許容 |
| 運用 | 汎用的なAzure Storage機能も使いたい | Blob中心で用途が明確 |
階層型名前空間（HNS）を有効にする意味
HNSは、Azure Data Lake StorageをData Lake Storageらしく使うための中核機能です。
通常のBlob Storageでは、raw/2026/05/file.parquet のような名前を付けても、実体としては「スラッシュを含むBlob名」です。見た目はフォルダー構造に見えても、オブジェクトストレージとしてはフラットに管理されます。
HNSを有効にすると、ディレクトリとファイルの階層構造を前提に扱えるようになります。これにより、ディレクトリ単位の移動、リネーム、削除、権限設定がビッグデータ分析ワークロードで扱いやすくなります。Microsoftは、HNSによってディレクトリ操作が単一の親ディレクトリエントリ更新として処理され、HiveやSparkなどが一時出力先をリネームする処理で特に効果があると説明しています。 (Microsoft Learn)
HNSを有効にすべきケース
次のような用途では、HNSを有効にしたData Lake Storageアカウントが適しています。
- Spark、Hive、Databricks、Synapseなどで大規模データを分析する
raw、staging、curatedのようにデータレイクの層を分けて管理する- ディレクトリ単位でアクセス権を分けたい
- ファイルシステムに近い操作感を前提にしたアプリやETLを使う
- AI/ML用に大規模データセットやモデル関連ファイルを整理して保存する
HNSを有効にしない方がよい場合もある
HNSは強力ですが、すべてのAzure Storage用途で必須ではありません。
たとえば、画像や動画を単純に配信する、アプリのバックアップファイルを保管する、Blob名をアプリ側DBで完全に管理している、といった用途では、HNSのメリットが限定的です。さらに、HNSを有効にすると一部機能のサポート状況が変わるため、既存のBlob Storage機能を多く使っている環境では事前確認が必要です。Microsoftの機能サポート表でも、HNS、NFS、SFTPの有効化によって機能サポートが変わることが説明されています。 (Microsoft Learn)
作成時に確認すべき設定
Data Lake Storage用のAzure Storageアカウントを作る際は、HNSだけを見て作成すると後で運用上の問題が出やすくなります。最低限、次の順番で確認しましょう。
| 手順 | 設定項目 | 確認内容 |
|---|---|---|
| 1 | サブスクリプション・リソースグループ | 課金、権限、管理単位に合っているか |
| 2 | リージョン | 利用する分析サービス、データ所在地、冗長性要件に合っているか |
| 3 | アカウント種別 | Standard general-purpose v2かPremium block blobか |
| 4 | 冗長性 | LRS、ZRS、GRS、RA-GRSなどを要件に合わせる |
| 5 | HNS | Data Lake Storage用途なら有効化する |
| 6 | ネットワーク | パブリックアクセス、特定VNet/IP、Private Endpointを決める |
| 7 | セキュリティ | HTTPS必須、匿名アクセス、ストレージキー利用可否を確認 |
| 8 | データ保護 | Blob soft delete、Container soft delete、バージョニング等を検討 |
| 9 | 権限設計 | Azure RBACとACLの役割分担を決める |
| 10 | IaC化 | Bicep、ARM Template、Terraform、Azure CLIなどで再現性を確保する |
Azure Storageの作成手順では、AdvancedタブにHNSの設定があり、Data Lake Storageワークロードで使う場合に階層型名前空間を構成すると説明されています。また、SecurityタブではHTTPS必須、匿名アクセス、ストレージアカウントキーアクセス、最小TLSバージョンなども設定できます。 (Microsoft Learn)
Azure Portal、CLI、IaCでの展開時の注意点
Data Lake Storage用ストレージアカウントは、Azure Portalだけでなく、Azure CLI、PowerShell、Bicep、ARM Template、Terraformなどでも作成できます。運用環境では、手作業のポータル作成よりもIaCで設定を固定する方が安全です。
Azure Portalで作る場合
Portalで作成する場合は、次の流れを意識します。
| 画面 | 操作 |
|---|---|
| Basics | サブスクリプション、リソースグループ、アカウント名、リージョン、性能、冗長性を設定 |
| Advanced | Data Lake Storageの「Enable hierarchical namespace」を有効化 |
| Networking | パブリックアクセス範囲、VNet、Private Endpointを設定 |
| Data protection | 削除保護、バージョン管理などを検討 |
| Security | HTTPS、TLS、匿名アクセス、キーアクセスなどを確認 |
| Review + create | 検証結果を確認して作成 |
ここでよくあるミスは、Storage account nameやリージョン、冗長性に気を取られて、AdvancedタブのHNSを有効化し忘れることです。後から既存アカウントをアップグレードできる場合もありますが、本番利用前提なら最初から正しく作る方が安全です。
Azure CLIで作る場合
Azure CLIでHNSを有効にしたストレージアカウントを作成する場合は、az storage account createで--enable-hierarchical-namespace trueを指定します。公式ドキュメントでは、階層型名前空間の作成にはAzure CLI 2.0.79以降が必要とされています。 (Microsoft Learn)
例としては、次のような考え方です。
az storage account create \
--name <storage-account-name> \
--resource-group <resource-group-name> \
--location japaneast \
--sku Standard_ZRS \
--kind StorageV2 \
--enable-hierarchical-namespace true \
--min-tls-version TLS1_2 \
--allow-blob-public-access false実際の環境では、リージョン、冗長性、ネットワーク制限、タグ、暗号化、Private Endpointなども合わせてテンプレート化することをおすすめします。
BicepやARM TemplateではHNSを明示する
BicepやARM Templateを使う場合は、ストレージアカウントのプロパティでHNSを有効にする必要があります。公式ドキュメントでも、Data Lake Storageを使う場合はBicepファイルでisHnsEnabledをtrueに設定する必要があると説明されています。 (Microsoft Learn)
IaCで特に注意したいのは、サンプルテンプレートをそのまま流用しないことです。サンプルは学習用であり、HNS、ネットワーク制限、暗号化、削除保護、タグ、診断設定などが本番要件に合っていないことがあります。
既存Blob Storageから移行する場合の注意点
既存のAzure Blob StorageアカウントにData Lake Storage機能を追加する場合は、HNSを有効化するアップグレードが必要です。ただし、このアップグレードは慎重に扱うべきです。
Microsoftは、既存アカウントのアップグレードは一方向であり、アップグレード後に元へ戻す方法はないため、非本番環境で検証することを推奨しています。 (Microsoft Learn)
移行前に確認すべき項目
| 確認項目 | 理由 | 対応 |
|---|---|---|
| 使用中のBlob機能 | HNS有効化後にサポート状況が変わる機能がある | 機能サポート表を確認する |
| Blobパス | 空のパスセグメントやスペースのみのセグメントがあると移行で問題になる | 事前に互換性のあるパスへコピーする |
| 書き込み処理 | アップグレード中の書き込みで失敗する可能性がある | アプリやサービスの書き込みを停止する |
| ページBlob | アップグレードできない要因になる | 事前に削除または別アカウントへ移す |
| 削除保護・不変ストレージ等 | アップグレードプロセスで一時的に無効化が必要な場合がある | 公式手順に沿って確認する |
| アプリ互換性 | Blob API前提のアプリが挙動差を受ける可能性がある | ステージング環境で検証する |
公式手順では、アップグレード準備として機能サポートの確認、Blobパスセグメントの命名確認、ストレージアカウントへの書き込み防止が挙げられています。また、Blob snapshots、encryption scopes、immutable storage、Blob soft delete、container soft deleteなどは、アップグレードプロセスではサポートされないため、必要に応じて無効化とクリーンアップ待ちが必要です。 (Microsoft Learn)
権限設計：RBACだけでなくACLも考える
Data Lake Storage用アカウントで重要になるのが、アクセス制御です。
Azure Data Lake Storageでは、Azure RBACとPOSIXライクなACLを組み合わせたアクセス制御モデルを利用できます。ACLはファイルやディレクトリに対して設定され、ユーザー、グループ、サービスプリンシパル、マネージドIDなどのセキュリティプリンシパルに権限を割り当てます。 (Microsoft Learn)
RBACとACLの使い分け
| 方式 | 主な役割 | 使いどころ |
|---|---|---|
| Azure RBAC | ストレージアカウント、コンテナーなど広い範囲の権限管理 | 管理者、データ基盤運用者、アプリの大枠権限 |
| ACL | ディレクトリ、ファイル単位の細かい権限管理 | 部門別フォルダー、データ層別、プロジェクト別のアクセス制御 |
たとえば、データレイクを次のように分ける場合を考えます。
/raw
/staging
/curated
/sandboxrawは取り込み担当のみ書き込み可能、curatedは分析者が読み取り可能、sandboxは開発チームが実験用に利用可能、というように、ディレクトリ単位で権限を設計できます。
ACL設計で失敗しやすいポイント
ACL設計でよくある失敗は、個人ユーザーに直接権限を付けることです。組織変更や退職、チーム異動があるたびにACLを修正する必要があり、運用負荷が高くなります。
基本は、Microsoft Entra IDのセキュリティグループを作成し、そのグループに対してACLを付与する設計が安全です。開発者、分析者、運用者、閲覧者などのロールをグループで分けると、メンバーの追加・削除だけで権限を管理しやすくなります。
また、ディレクトリをたどるにはExecute権限が必要です。公式ドキュメントでも、ACLだけで読み書き権限を与える場合、対象ファイルに至るルートフォルダーと各階層にExecute権限が必要と説明されています。 (Microsoft Learn)
セキュリティ設定で必ず見直すべき項目
Data Lake Storageは分析基盤の中核になりやすく、機密データや個人情報を含むデータセットを扱うこともあります。そのため、ストレージアカウント作成時点でセキュリティ設定を確認することが重要です。
| 設定 | 推奨される考え方 | 注意点 |
|---|---|---|
| Secure transfer | HTTPSを必須にする | 古いクライアントがある場合は事前検証 |
| 匿名アクセス | 原則無効化 | 公開用途とデータレイク用途を同居させない |
| Storage account key access | 可能ならMicrosoft Entra ID中心にする | キー共有は追跡性と最小権限の面で弱い |
| 最小TLSバージョン | 既定値や組織基準に合わせる | 古いTLS利用クライアントを洗い出す |
| Public network access | 必要最小限に制限 | Private Endpointや特定VNet/IPを検討 |
| Defender for Storage | リスクに応じて有効化を検討 | コストと検知要件を確認 |
Azure Storage作成画面のSecurityタブでは、REST API操作のセキュア転送、匿名アクセス、ストレージアカウントキーアクセス、Microsoft Entra承認、最小TLSバージョンなどを設定できます。Microsoftは匿名アクセスの無効化を最適なセキュリティのために推奨しています。 (Microsoft Learn)
機能サポートの差分を確認する
HNSを有効化すると、Blob Storageのすべての機能が同じように使えるとは限りません。
Microsoftの「Blob Storage feature support in Azure Storage accounts」では、Standard general-purpose v2やPremium block blobで、HNS、NFS、SFTPを有効化した場合の機能サポート状況が整理されています。たとえば、Standard general-purpose v2のHNS有効アカウントでは、Blob Storage APIs、Azure CLI、PowerShell、Blob events、soft deleteなどはサポートされていますが、Blob versioning、change feed、object replication、point-in-time restoreなどは表上で未サポートとして示されています。 (Microsoft Learn)
この点は、既存のBlob StorageをData Lake Storage化する場合に特に重要です。
機能確認が必要な代表例
| 機能 | 確認理由 |
|---|---|
| Blob versioning | 既存の復元・監査設計に影響する可能性がある |
| Change feed | イベント駆動処理や変更追跡に影響する可能性がある |
| Object replication | DRやリージョン間複製の設計に影響する |
| Point-in-time restore | 誤削除・破損時の復旧手段に影響する |
| SFTP / NFS | 認証方式やネットワーク、対応機能が変わる |
| Immutable storage | コンプライアンス要件に影響する可能性がある |
機能サポートは時期によって変わる可能性があります。設計時には、必ず最新のMicrosoft Learnの機能サポート表を確認してください。
データレイク構成の具体例
Data Lake Storage用ストレージアカウントを作成したら、最初にディレクトリ構成を決めておくと、権限管理と運用が安定します。
よく使われる構成例は次の通りです。
/raw
/sales
/customer
/log
/staging
/sales
/customer
/curated
/sales
/customer
/sandbox
/team-a
/team-b| 階層 | 目的 | 権限例 |
|---|---|---|
| raw | 取り込み直後のデータを保存 | 取り込み処理は書き込み可、分析者は原則読み取り不可 |
| staging | 加工途中のデータを保存 | データエンジニアが読み書き |
| curated | 分析・BI向けに整備済みデータを保存 | 分析者やBIツールが読み取り |
| sandbox | 検証・一時分析用 | チーム単位で限定的に読み書き |
この構成のポイントは、データの品質状態と権限境界を一致させることです。たとえば、rawに全員がアクセスできると、未加工データや機密情報が意図せず参照されるリスクがあります。一方、curatedだけを参照対象にすれば、BIや分析利用者に安定したデータを提供しやすくなります。
管理者向けチェックリスト
作成前に、次の項目を確認しておきましょう。
| チェック | 内容 |
|---|---|
| HNSを有効化する理由が明確か | 分析、ACL、ディレクトリ操作などの要件があるか |
| アカウント種別は適切か | Standard general-purpose v2かPremium block blobか |
| リージョンは適切か | 利用サービス、データ所在地、BCP要件と合うか |
| 冗長性は決まっているか | LRS、ZRS、GRS、RA-GRSなどを要件で選んだか |
| ネットワーク制限は設計済みか | Public access、VNet、Private Endpointを検討したか |
| 匿名アクセスを無効化するか | データレイク用途では原則無効化 |
| ストレージキー依存を避けるか | Microsoft Entra IDとRBAC/ACL中心にできるか |
| 削除保護を有効化するか | Blob soft delete、container soft deleteなどを確認 |
| 監視・ログを設定するか | Azure Monitor、診断設定、アラートを検討 |
| IaC化するか | 手作業ではなくテンプレートで再現できるか |
開発者向けチェックリスト
アプリやETLからData Lake Storageを使う場合は、次の観点を確認してください。
| チェック | 内容 |
|---|---|
| APIの前提 | Blob APIかData Lake Storage APIか |
| 認証方式 | Managed Identity、Service Principal、User Delegation SASなど |
| パス設計 | 空セグメントや不要なスペースを含まないか |
| 権限 | RBACだけでなくACLのExecute権限も考慮しているか |
| リトライ | 大量データ処理時の再試行、並列度、タイムアウトを設計したか |
| 一時出力 | Sparkなどの一時ディレクトリと最終出力先を分けたか |
| 環境差分 | dev、stg、prodで同じ構成を再現できるか |
特にManaged Identityを使う場合は、RBACで大枠の権限を付与しただけで終わらせず、対象ディレクトリのACLも確認してください。RBAC上は権限があるように見えても、ディレクトリ階層のExecute権限が不足してアクセスできない、というトラブルが起きやすいです。
よくあるトラブルと対策
| トラブル | 原因 | 対策 |
|---|---|---|
| Data Lake Storageとして使えない | HNSを有効化していない | 作成時のAdvancedタブ、または既存アカウントのアップグレードを確認 |
| 作成後にアカウント種別を変えたい | ストレージアカウント種別は作成後に変更できない | 新しいアカウントを作り、データをコピーする |
| ACLを設定したのにアクセスできない | 親ディレクトリのExecute権限不足 | ルートから対象までの各階層に必要権限を設定 |
| 移行検証で失敗する | 未サポート機能や不正なパスがある | 機能サポート表とアップグレード手順を確認 |
| コストが想定より高い | 冗長性、アクセス層、トランザクション、データ移動を考慮していない | 事前に料金計算とアクセスパターンを確認 |
| IaCで作った環境だけ動かない | isHnsEnabledやネットワーク、権限設定の漏れ | Portal作成値とテンプレート差分を確認 |
ストレージアカウント種別については、作成後に別の種別へ変更できないため、別種別へ移したい場合は新規アカウントを作成してデータをコピーする必要があります。 (Microsoft Learn)
既存環境への影響範囲
既存のAzure Storage環境に今回の内容が直接影響するかは、状況によって異なります。
| 環境 | 影響 |
|---|---|
| 新規にデータレイクを作る環境 | 最初からHNS有効、適切なアカウント種別で設計する必要がある |
| 既存Blob Storageをそのまま使っている環境 | Data Lake Storage化する場合はアップグレード検証が必要 |
| すでにHNS有効のADLS Gen2を使っている環境 | 作成手順よりも機能サポート、権限、運用設定の見直しが中心 |
| SFTP/NFSも使う環境 | HNSに加えて、各プロトコルの制限や認証方式を確認する必要がある |
| IaCで展開している環境 | テンプレートにHNS、TLS、匿名アクセス、ネットワーク設定が明示されているか確認 |
すでに本番環境でAzure Data Lake Storageを使っている場合、今回の情報だけで緊急の設定変更が必要になるとは限りません。ただし、新規展開テンプレートや標準手順書にHNS設定が明示されていない場合は、作成ミスを防ぐために更新しておくべきです。
次に取るべき行動
Data Lake Storage用のAzure Storageアカウントを作成・移行する前に、まずは次の3点を確認してください。
1つ目は、ワークロードが本当にHNSを必要としているかです。分析基盤、ディレクトリ単位の権限管理、大規模なリネーム・移動処理があるなら、HNSを有効にする価値があります。
2つ目は、アカウント種別と機能サポートです。基本はStandard general-purpose v2を検討し、低レイテンシや高トランザクションが明確な場合のみPremium block blobを検討します。既存Blob Storageを移行する場合は、機能サポート表とアップグレード手順を必ず確認してください。
3つ目は、作成後の運用設計です。HNSを有効にするだけでは、安全で使いやすいデータレイクにはなりません。RBACとACL、ネットワーク制限、匿名アクセス無効化、削除保護、監視、IaC化まで含めて設計することで、後からの手戻りを大きく減らせます。
Azure StorageでData Lake Storage用アカウントを作る際は、「作成できるか」ではなく「後から安全に運用できるか」を基準に設定を選びましょう。
コメント