Amazon Redshift は、パッチ 198 以降、新しい Python UDF の作成をサポートしなくなります。既存の Python UDF は、2026 年 6 月 30 日まで引き続き機能します。詳細については、[ブログ記事](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/)を参照してください。 # 保存データのサイズを削減するための列圧縮 *圧縮*は、データの保存時にそのサイズを小さくする列レベルのオペレーションです。圧縮によってストレージスペースが節約され、ストレージから読み込まれるデータのサイズが小さくなり、ディスク I/O の量が減少するので、クエリパフォーマンスが向上します。 ENCODE AUTO は、テーブルのデフォルトです。テーブルが ENCODE AUTO に設定されると、Amazon Redshift は、テーブル内のすべての列の圧縮エンコードを自動的に管理します。詳細については、「[CREATE TABLE](r_CREATE_TABLE_NEW.md)」および「[ALTER TABLE](r_ALTER_TABLE.md)」を参照してください。 ただし、テーブル内のいずれかの列に圧縮エンコードを指定すると、テーブルは ENCODE AUTO に設定されなくなります。Amazon Redshift は、テーブルにあるすべての列の圧縮エンコードを自動的に管理しないようになりました。 テーブルを作成するときに、テーブルの列に圧縮タイプまたは*エンコード*を手動で適用できます。または、COPY コマンドを使用すると、自動的に圧縮を分析および適用できます。詳細については、「[COPY による圧縮エンコードの選択](c_best-practices-use-auto-compression.md)」を参照してください。自動圧縮の適用の詳細については、「[自動圧縮ありでテーブルをロードする](c_Loading_tables_auto_compress.md)」を参照してください。 **注記** COPY コマンドを使用して自動圧縮を適用することを強くお勧めします。 新しいテーブルが別のテーブルと同じデータ特性を共有している場合は、圧縮エンコードを手動で適用することを選択できます。または、自動圧縮時に適用される圧縮エンコードがデータにとって最適ではないことがテストで判明した場合は、ユーザーが管理することもできます。圧縮エンコードを手動で適用する場合は、すでに入力されているテーブルに対して [ANALYZE COMPRESSION](r_ANALYZE_COMPRESSION.md) コマンドを再実行し、その結果を使用して圧縮エンコードを選択することができます。 圧縮を手動で適用するには、CREATE TABLE ステートメントの一部として個々の列に対して圧縮エンコードを指定します。構文は次のとおりです。 ``` CREATE TABLE table_name (column_name data_type ENCODE encoding-type)[, ...] ``` ここで、*encoding-type* には次のセクションのキーワード表から選択します。 例えば、次のステートメントは 2 列のテーブル PRODUCT を作成します。データがテーブルにロードされるときに、PRODUCT\$1ID 列は圧縮されませんが、PRODUCT\$1NAME 列はバイトディクショナリエンコード (BYTEDICT) を使用して圧縮されます。 ``` create table product( product_id int encode raw, product_name char(20) encode bytedict); ``` ALTER TABLE コマンドを使用して列をテーブルに追加する際には、列のエンコードを指定できます。 ``` ALTER TABLE table-name ADD [ COLUMN ] column_name column_type ENCODE encoding-type ``` **Topics** + [圧縮エンコード](c_Compression_encodings.md) + [圧縮エンコードのテスト](t_Verifying_data_compression.md) # 圧縮エンコード *圧縮エンコード*は、行がテーブルに追加されるときにデータ値の列に適用される圧縮のタイプを指定します。 ENCODE AUTO は、テーブルのデフォルトです。テーブルが ENCODE AUTO に設定されると、Amazon Redshift は、テーブル内のすべての列の圧縮エンコードを自動的に管理します。詳細については、「[CREATE TABLE](r_CREATE_TABLE_NEW.md)」および「[ALTER TABLE](r_ALTER_TABLE.md)」を参照してください。 ただし、テーブル内のいずれかの列に圧縮エンコードを指定すると、テーブルは ENCODE AUTO に設定されなくなります。Amazon Redshift は、テーブルにあるすべての列の圧縮エンコードを自動的に管理しないようになりました。 CREATE TABLE を使用すると、テーブル内の列の圧縮エンコードを指定するとき、ENCODE AUTO は無効です。ENCODE AUTO が無効なとき、Amazon Redshift は、ユーザーが ENCODE タイプを指定していない列について、次のように圧縮エンコードを自動的に割り当てます。 + ソートキーとして定義されている列には、RAW 圧縮が割り当てられます。 + BOOLEAN、REAL、または DOUBLE PRECISION データ型として定義されている列には、RAW 圧縮が割り当てられます。 + SMALLINT、INTEGER、BIGINT、DECIMAL、DATE、TIMESTAMP、または TIMESTAMPTZ データ型として定義された列には AZ64 圧縮が割り当てられます。 + CHAR または VARCHAR データ型として定義された列には、LZO 圧縮が割り当てられます。 テーブルのエンコードは、作成後に ALTER TABLE を使用して変更できます。ALTER TABLE を使用して ENCODE AUTO を無効にした場合、Amazon Redshift は列の圧縮エンコードを自動的に管理しなくなります。すべての列の圧縮エンコードタイプは、ユーザーが変更するか、ENCODE AUTO を再び有効にするまで、ENCODE AUTO を無効にしたときの圧縮エンコードタイプのままです。 Amazon Redshift は、以下の圧縮エンコーディングをサポートしています。 ------ #### [ Raw ] Raw エンコードは、ソートキー、および BOOLEAN、REAL、または DOUBLE PRECISION データ型として定義された列として指定された列のエンコードのデフォルトです。raw エンコードでは、データは非圧縮の raw 形式で格納されます。 ------ #### [ AZ64 ] AZ64 は、高い圧縮率とクエリ処理能力の改善を実現するために Amazon によって設計された独自の圧縮エンコードアルゴリズムです。Z64 アルゴリズムは、より小さなデータ値のグループを圧縮し、並列処理に SIMD (Single Instruction Multiple Data) 命令を使用します。AZ64 を使用すると、数値、日付、および時刻データ型のストレージを大幅に節約し、高いパフォーマンスを実現できます。 次のデータ型の CREATE TABLE および ALTER TABLE ステートメントを使用して列を定義する場合、AZ64 を圧縮エンコードとして使用できます。 + SMALLINT + INTEGER + BIGINT + DECIMAL + DATE + TIMESTAMP + TIMESTAMPTZ ------ #### [ Byte-dictionary ] バイトディクショナリエンコードでは、ディスク上の列値のブロックごとに、一意の値の個別のディクショナリが作成されます (Amazon Redshift のディスクブロックは 1 MB を占有します。) ディクショナリには、元のデータ値のインデックスとして格納されている最大 256 個の 1 バイト値が含まれます。単一のブロックに 256 個を超える値が格納されている場合は、余分な値が非圧縮の raw 形式でブロックに書き込まれます。ディスクブロックごとに、このプロセスが繰り返されます。 このエンコードは、低カーディナリティ文字列の列に対して非常に効果的です。このエンコードは、列のデータドメインが一意の値 256 個未満である場合に最適です。 BYTEDICT でエンコードされた文字列データ型 (CHAR と VARCHAR) の列の場合、Amazon Redshift は圧縮されたデータを直接処理するベクタースキャンと述語評価を実行します。これらのスキャンでは、ハードウェア固有の単一命令複数データ (SIMD) 命令が使用されて、並列処理が行われます。これにより、文字列列のスキャンが大幅に加速されます。バイトディクショナリエンコードは、CHAR/VARCHAR 列に長い文字列が含まれる場合に特にスペース効率が高まります。 テーブルに、CHAR(30) データ型の COUNTRY 列があるとします。データがロードされると、Amazon Redshift はディクショナリを作成し、COUNTRY 列にインデックス値を入力します。ディクショナリには、インデックス作成された一意の値が含まれ、テーブル自体には、対応する値の 1 バイトのサブスクリプトのみが含まれます。 **注記** 固定長文字の列には末尾の空白が格納されます。したがって CHAR(30) 列では、バイトディクショナリエンコードを使用すると、圧縮値ごとに 29 バイトのストレージが節約されます。 次の表は、COUNTRY 列のディクショナリを示しています。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/redshift/latest/dg/c_Compression_encodings.html) 次の表は、COUNTRY 列の値を示しています。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/redshift/latest/dg/c_Compression_encodings.html) この例の合計圧縮サイズは、次のように計算されます。ディクショナリに 6 つの異なるエントリが格納され (6 \$1 30 = 180)、テーブルに 10 個の 1 バイト圧縮値が含まれて、合計 190 バイトとなります。 ------ #### [ Delta ] デルタエンコードは、日時列にとって非常に有用です。 デルタエンコードは、列内の連続する値間の差を記録することにより、データを圧縮します。この差は、ディスク上の列値の各ブロックに対する個別のディクショナリに記録されます (Amazon Redshift のディスクブロックは 1 MB を占有します。) 例えば、列に 1 から 10 までの 10 個の整数が順番に含まれているとします。最初の値は 4 バイトの整数 (\$1 1 バイトのフラグ) として保存されます。次の 9 つはそれぞれ値 1 のバイトとして保存され、前の値より 1 大きいことを示します。 デルタエンコードには、次の 2 つのバージョンがあります。 + 差を 1 バイト値 (8 ビット整数) として記録する DELTA + 差を 2 バイト値 (16 ビット整数) として記録する DELTA32K 1 バイトを使用して列内のほとんどの値を圧縮できる場合は、1 バイトの変形が非常に効果的です。しかし、最悪の場合、デルタがより大きいと、このエンコードは非圧縮データを保存する場合よりも多少効果が低くなる可能性もあります。16 ビットバージョンにも同様の論理が当てはまります。 2 つの値間の差が 1 バイトの範囲 (DELTA) または 2 バイトの範囲 (DELTA32K) を超える場合は、先頭に 1 バイトのフラグが付けられて元の完全な値が格納されます。1 バイトの範囲は -127～127、2 バイトの範囲は -32K～32K です。 次の表は、デルタエンコードが数値列に対してどのように機能するかを示しています。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/redshift/latest/dg/c_Compression_encodings.html) ------ #### [ LZO ] LZO エンコードは、非常に高い圧縮率と良好なパフォーマンスを実現します。LZO エンコードは、非常に長い文字列を格納する CHAR 列および VARCHAR 列に対して使用すると特に効果的です。製品説明、ユーザーコメント、JSON 文字列などの自由形式テキストに適しています。 ------ #### [ Mostly ] Mostly エンコードは、列のデータ型が、格納された大部分の値で必要なサイズより大きい場合に有用です。このタイプの列に Mostly エンコードを指定して、列内の大部分の値を、より小さい標準ストレージサイズに圧縮することができます。圧縮できない残りの値は、raw 形式で格納されます。例えば、INT2 列などの 16 ビット列を 8 ビットストレージに圧縮できます。 一般的に、Mostly エンコードは次のデータ型に対して使用します。 + SMALLINT/INT2 (16 ビット) + INTEGER/INT (32 ビット) + BIGINT/INT8 (64 ビット) + DECIMAL/NUMERIC (64 ビット) 列のデータ型のサイズに見合う Mostly エンコードの適切なバージョンを選択します。例えば、16 ビット整数列として定義された列に MOSTLY8 を適用します。MOSTLY16 を 16 ビットデータ型の列に適用したり、MOSTLY32 を 32 ビットデータ型の列に適用したりすることはできません。 列内の比較的多くの値を圧縮できない場合、Mostly エンコードは非圧縮の場合よりも効果が低くなります。これらのエンコードの 1 つを列に適用する前に、確認してください。現在ロードしようとしている (そして今後ロードする可能性が高い) 値の*ほとんど*は、次のテーブルに示す範囲に収まるはずです。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/redshift/latest/dg/c_Compression_encodings.html) **注記** 10 進値では、値が範囲内にあるかどうかを判断する場合に小数点を無視します。例えば、1,234.56 は 123,456 として扱われ、MOSTLY32 列で圧縮できます。 例えば、VENUE テーブルの VENUEID 列が raw 整数列として定義されている場合は、その値が 4 バイトのストレージを消費することを意味します。しかし、列の値の現在の範囲は **0**～**309** です。したがって、VENUEID に対して MOSTLY16 エンコードを使用してこのテーブルを再作成および再ロードすると、その列の各値のストレージが 2 バイトに減少します。 別のテーブルで参照される VENUEID 値のほとんどが 0～127 の範囲内にある場合、その外部キー列を MOSTLY8 としてエンコードすることは妥当と言えます。選択を行う前に、参照テーブルデータに対していくつかのクエリを実行して、ほとんどの値が 8 ビット、16 ビット、または 32 ビットの範囲内にあるかどうかを確認する必要があります。 次の表は、MOSTLY8、MOSTLY16、および MOSTLY32 エンコードが使用される場合の特定の数値の圧縮サイズを示しています。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/redshift/latest/dg/c_Compression_encodings.html) ------ #### [ Run length ] ランレングスエンコードは、連続して繰り返される値を、値と連続発生数 (実行の長さ) から成るトークンに置き換えます。ディスク上の列値のブロックごとに、一意の値の個別のディクショナリが作成されます (Amazon Redshift のディスクブロックは 1 MB を占有します。) このエンコードは、データ値が連続して頻繁に繰り返されるテーブル (例えば、テーブルがこれらの値でソートされる場合) に最も適しています。 例えば、大きなディメンションテーブルの列に、予測どおりに小さなドメイン (10 個未満の可能な値を持つ COLOR 列など) があるとします。これらの値は、データがソートされていない場合でも、テーブル全体で長いシーケンスに分類される可能性があります。 ソートキーとして指定された列に、ランレングスエンコードを適用することは推奨されません。範囲が制限されたスキャンは、ブロックに同様の数の行が含まれる場合にパフォーマンスが向上します。ソートキー列が、同じクエリ内の他の列よりもかなり高度に圧縮される場合、範囲が制限されたスキャンはパフォーマンスが低下する可能性があります。 次の表は、COLOR 列の例を使用して、ランレングスエンコードがどのように機能するかを示しています。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/redshift/latest/dg/c_Compression_encodings.html) ------ #### [ Text255 and Text32k ] text255 および text32k エンコードは、同じ単語が頻繁に出現する VARCHAR 列を圧縮する場合に有用です。ディスク上の列値のブロックごとに、一意の単語の個別のディクショナリが作成されます (Amazon Redshift のディスクブロックは 1 MB を占有します。) ディクショナリには、列内の最初の 245 個の一意の単語が含まれます。これらの単語は、ディスク上で、245 個の値の 1 つを表す 1 バイトインデックス値に置き換えられ、ディクショナリに表されていないすべての単語は非圧縮で格納されます。このプロセスは、1 MB のディスクブロックごとに繰り返されます。インデックス作成された単語が列内に頻繁に出現する場合、列の圧縮率は非常に高くなります。 text32k エンコードでも原理は同じですが、各ブロックのディクショナリは特定数の単語をキャプチャすることはありません。代わりにディクショナリは、結合されたエントリが、32K から多少のオーバーヘッドを減算した長さに達するまで、検出した一意の各単語のインデックスを作成します。インデックス値は 2 バイトで格納されます。 例えば、VENUE テーブルの VENUENAME 列を考えてみます。この列には **Arena**、**Center**、**Theatre** などの単語が繰り返し出現し、text255 圧縮が適用された場合、各ブロックに出現する最初の 245 個の単語内にこれらが含まれると考えられます。その場合、この列は圧縮の利点を利用できます。その場合、これらの単語が出現するたびに 1 バイトのストレージ (それぞれ 5、6、または 7 バイトではなく) を占めるにすぎないのが理由です。 ------ #### [ ZSTD ] Zstandard (ZSTD) エンコードは、多様なデータセット間で非常にパフォーマンスのいい高圧縮比率を提供します。ZSTD は、製品説明、ユーザーのコメント、ログ、JSON 文字列など、長さがさまざまな文字列を保存する CHAR および VARCHAR 列に対して、特に効果を発揮します。一部のアルゴリズム (デルタエンコードや Mostly エンコードなど) では非圧縮時よりもストレージスペースの使用量が増える場合がありますが、ZSTD ではディスク使用量が増えることはありません。 ZSTD は、SMALLINT、INTEGER、BIGINT、DECIMAL、REAL、DOUBLE PRECISION、BOOLEAN、CHAR、VARCHAR、DATE、TIMESTAMP、および TIMESTAMPTZ データ型をサポートします。 ------ 次の表は、サポートされる圧縮エンコード、およびエンコードをサポートするデータ型を示しています。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/redshift/latest/dg/c_Compression_encodings.html) # 圧縮エンコードのテスト 列のエンコードを手動で指定する場合は、データに対してさまざまなエンコードをテストできます。 **注記** できる限り COPY コマンドを使用してデータをロードし、データに基づいて最適なエンコードを COPY コマンドが選択できるようにすることをお勧めします。または、[ANALYZE COMPRESSION](r_ANALYZE_COMPRESSION.md) コマンドを使用して、既存のデータに対して提案されるエンコードを表示できます。自動圧縮の適用の詳細については、「[自動圧縮ありでテーブルをロードする](c_Loading_tables_auto_compress.md)」を参照してください。 データ圧縮の有意義なテストを実行するには、多数の行が必要になります。この例では、2 つのテーブル VENUE と LISTING から選択を行うステートメントを使用して、テーブルを作成し行を挿入します。通常は 2 つのテーブルを結合する WHERE 句は省略します。その結果、VENUE テーブルの*各*行が LISTING テーブルの*すべての*行に結合されて、合計 3200 万以上の行になります。これはデカルト結合と呼ばれ、通常はお勧めしません。ただし、この目的においては、多数の行を作成する便利な方法です。テストするデータを含む既存のテーブルがある場合は、このステップをスキップできます。 サンプルデータを含むテーブルを作成したら、7 列のテーブルを作成します。それぞれ異なる圧縮エンコード (raw、bytedict、lzo、run length、text255、text32k、および zstd) が適用されます。最初のテーブルからデータを選択する INSERT コマンドを実行することにより、各列に全く同じデータを入力します。 圧縮エンコードをテストするには、以下を実行します。 1. (オプション) 最初に、デカルト結合を使用して、多数の行を含むテーブルを作成します。既存のテーブルをテストする場合は、このステップをスキップします。 ``` create table cartesian_venue( venueid smallint not null distkey sortkey, venuename varchar(100), venuecity varchar(30), venuestate char(2), venueseats integer); insert into cartesian_venue select venueid, venuename, venuecity, venuestate, venueseats from venue, listing; ``` 1. 次に、比較する各エンコードを含むテーブルを作成します。 ``` create table encodingvenue ( venueraw varchar(100) encode raw, venuebytedict varchar(100) encode bytedict, venuelzo varchar(100) encode lzo, venuerunlength varchar(100) encode runlength, venuetext255 varchar(100) encode text255, venuetext32k varchar(100) encode text32k, venuezstd varchar(100) encode zstd); ``` 1. INSERT ステートメントを SELECT 句とともに使用して、すべての列に同じデータを挿入します。 ``` insert into encodingvenue select venuename as venueraw, venuename as venuebytedict, venuename as venuelzo, venuename as venuerunlength, venuename as venuetext32k, venuename as venuetext255, venuename as venuezstd from cartesian_venue; ``` 1. 新しいテーブルの行数を確認します。 ``` select count(*) from encodingvenue count ---------- 38884394 (1 row) ``` 1. [STV\$1BLOCKLIST](r_STV_BLOCKLIST.md) システムテーブルをクエリ処理して、各列で使用される 1 MB のディスクブロックの数と比較します。 MAX 集計関数が、各列のブロックの最高数を返します。STV\$1BLOCKLIST テーブルには、3 つのシステム生成列の詳細が含まれます。この例では、WHERE 句で `col < 6` を使用して、システム生成列を除外します。 ``` select col, max(blocknum) from stv_blocklist b, stv_tbl_perm p where (b.tbl=p.id) and name ='encodingvenue' and col < 7 group by name, col order by col; ``` クエリは次の結果を返します。列には 0 から始まる番号が付けられています。クラスターの設定方法によっては結果の数が異なる場合がありますが、相対的なサイズは同様のものになります。このデータセットについては、2 列目の BYTEDICT エンコードから、最良の結果が得られました。このアプローチの圧縮比は 20:1 よりも優れています。LZO および ZSTD エンコードからも良好な結果が得られました。もちろん、異なるデータセットからは異なる結果が得られます。より長い文字列が列に含まれる場合は、LZO から最良の圧縮結果が得られることが多くなります。 ``` col | max -----+----- 0 | 203 1 | 10 2 | 22 3 | 204 4 | 56 5 | 72 6 | 20 (7 rows) ``` 既存のテーブルにデータが存在する場合は、[ANALYZE COMPRESSION](r_ANALYZE_COMPRESSION.md) コマンドを使用して、テーブルに対して提案されるエンコードを表示できます。例えば、次の例は、3800 万行を含む VENUE テーブル CARTESIAN\$1VENUE のコピーに対して推奨されるエンコードを示しています。ANALYZE COMPRESSION により VENUENAME 列には LZO エンコードが推奨されています。ANALYZE COMPRESSION は減少率を含む複数の要素に基づいて最適な圧縮を選択します。この特定のケースでは、BYTEDICT の方がより圧縮できますが、LZO でも 90 パーセントを超える圧縮になります。 ``` analyze compression cartesian_venue; Table | Column | Encoding | Est_reduction_pct ---------------+------------+----------+------------------ reallybigvenue | venueid | lzo | 97.54 reallybigvenue | venuename | lzo | 91.71 reallybigvenue | venuecity | lzo | 96.01 reallybigvenue | venuestate | lzo | 97.68 reallybigvenue | venueseats | lzo | 98.21 ``` ## 例 次の例は、さまざまなデータ型の列を含む CUSTOMER テーブルを作成します。この CREATE TABLE ステートメントは、これらの列に対する圧縮エンコードの数ある可能な組み合わせの 1 つを示しています。 ``` create table customer( custkey int encode delta, custname varchar(30) encode raw, gender varchar(7) encode text255, address varchar(200) encode text255, city varchar(30) encode text255, state char(2) encode raw, zipcode char(5) encode bytedict, start_date date encode delta32k); ``` 次の表は、CUSTOMER テーブルに対して選択された列エンコードを示し、それぞれの選択内容について説明しています。 | 列 | データ型 | エンコード | 説明 | | --- | --- | --- | --- | | CUSTKEY | int | delta | CUSTKEY は、連続した一意の整数値から成ります。差は 1 バイトとなるので、DELTA を選択するのが適切です。 | | CUSTNAME | varCHAR(30) | raw | CUSTNAME には、繰り返し値がほとんどない大きなドメインがあります。いずれの圧縮エンコードも効果的でないと考えられます。 | | GENDER | varchar(7) | text255 | GENDER は、多数の繰り返し値を含む非常に小さなドメインです。同じ単語が繰り返し出現する VARCHAR 列には、text255 が適しています。 | | ADDRESS | varchar(200) | text255 | ADDRESS は大きなドメインですが、Street、Avenue、North、South など、繰り返しの単語が多数含まれます。同じ単語が繰り返し出現する VARCHAR 列を圧縮するには、text255 と text32k が有用です。列が短いので、text255 を選択するのが適切です。 | | CITY | varCHAR(30) | text255 | CITY は、いくつかの繰り返し値を含む大きなドメインです。特定の市の名前が、他の市の名前よりもかなり頻繁に使用されます。ADDRESS と同じ理由により、text255 を選択するのが適切です。 | | STATE | char(2) | raw | 米国では、STATE は 50 個の 2 文字値の正確なドメインです。bytedict エンコードによって多少圧縮されるものの、列サイズが 2 文字のみであるため、データの解凍時のオーバーヘッドを考慮すると圧縮する必要はそれほどないと考えられます。 | | ZIPCODE | char(5) | bytedict | ZIPCODE は、50,000 個未満の一意の値を含む既知のドメインです。特定の郵便番号が、他の郵便番号よりもかなり頻繁に出現します。bytedict エンコードは、数に制限のある一意の値が列に含まれる場合に非常に効果的です。 | | START\$1DATE | date | delta32k | デルタエンコードは、特に行が日付順にロードされる場合に、日時列にとって非常に有用です。 |