はじめに
前回の記事で、TBWの正体について説明しました。
それを踏まえて、この記事では、なぜTBWが使いかた（ワークロード）に依存するのか、TBWの値の大小を左右する要素は何なのかを説明し、SSDを選ぶ際におさえておくべき要素についてまとめます。
これらはすでに様々な方が指摘されてきた内容ですが、この記事では、「SSDの使いかたが寿命消費に与える影響」という視点からまとめます。
※注1：記事中で単に"TBW"と記載した場合は、「あるワークロードを用いて算出されたTBW」というワークロードを特定しない形での言及です。「TBWがワークロードに依存しない」という意味ではありません。
サマリ
-
SSDの寿命消費を緩やかにする「やさしい使いかた」の例
- 容量に十分余裕をもって使う
- 大サイズのシーケンシャルライト中心の書き込み
- SSD内のデータ管理単位に揃った書き込み
- 特定のデータに偏って集中したReadは行わない
- 動作温度は室温程度で変化も少ない
- 振動はない
- 十分に余裕を持った電源機構
- 手順を守って電源を切る
-
SSDの寿命消費を早める「やさしくない使いかた」の例
- 容量ぎりぎりで使う
- LBA空間の広い範囲にわたる小サイズのランダムライト中心の書き込み
- SSD内のデータ管理単位に揃わない書き込み
- 特定のデータに偏って集中したReadを行う
- 動作温度が高い、温度変化が大きい
- 振動が大きい
- 余裕のない電源機構
- 電源断手順を守らない
前回の振り返り：SSDの寿命を消費する要素
前回の記事で、SSDが搭載するNANDフラッシュメモリの（推定）寿命を消費する要素には、ホストから書き込まれたデータの一次書き込み以外にも複数存在することを説明しました。
図1：SSDが搭載するNANDフラッシュメモリの推定寿命と、その推定寿命を消費する要素（消費の様子はイメージ）
図1の通り、SSDの（推定）寿命をできるだけ多くホストから書き込まれたデータの一次書き込み（図1のE）で消費するには、その他の要素による寿命消費をできるだけ抑えれば良いということになります。
図1の記号を使って言い換えれば、AやBはしょうがないとして、C、D、Fによる寿命の消費をできるだけ抑えれば良い（＝TBWを大きくする）、ということになります。
そのような使いかたは「SSDにやさしい使いかた」と言えます。
逆に、図1のC、D、Fによる寿命の消費が増えるような使いかたは、ホストから書き込むことができるデータのサイズを減らしてしまう（＝TBWを小さくしてしまう）ことになります。
そのような使いかたは「SSDにやさしくない使いかた」と言えます。
図2：TBWを大きくする使いかたと小さくする使いかたのイメージ
「SSDにやさしくない使いかた」とは
前回の記事でも少し触れた通り、ホストから書き込むことができるデータのサイズを減らしてしまう（TBWを小さくしてしまう）使いかたの具体例は、以下のようなものです。
- SSD内の有効データサイズがSSD容量に対して多い状態で使い続ける
- 24時間稼働するサーバに設置して絶え間なくWriteアクセスする
- 24時間稼働し絶え間なくReadアクセスする
- 温度や振動に代表される動作環境がオフィスや家庭とは異なる場所で使用する
- 一回の通電時間（稼働時間）が短い機器（システム）に接続・内蔵する
そこで、それぞれのケースを見ながら、なぜこれらの使いかたがTBWを小さくしてしまうのかについて説明します。
「なぜこれらの使いかたがTBWを小さくしてしまうのか」がわかれば、その使いかたをしない、さらにはその使いかたとは逆の使いかたを考えることで「TBWを大きくする使いかた」がわかる、というわけです。
容量いっぱいいっぱいで使うのは寿命的にも性能的にもダメ！
＜ポイント：容量に十分な余裕をもって使うと、SSDにやさしく、性能も安定する＞
広く知られていますように、NANDフラッシュメモリはブロック単位で一旦Eraseしてからでないとデータを書き込めません。
そこで、SSDは、書き込み可能なブロックがなくなってしまう前にブロックを「再利用」することで新たに書き込み可能なブロックを作り出し、ストレージとしての機能を継続します。
この「新たに書き込み可能なブロックを作り出す」ために、再利用したいブロックに残っている「有効なデータ」をかき集めて別のブロックにコピーする処理が、いわゆるGarbage Collection (GC)です。
なお、「書き込み可能なブロック」は、良く「フリーブロック」と呼ばれます。この記事でも、この呼称を使用します。「フリーブロック」という呼称を使用すると、GCの目的は「フリーブロックを最低でも1つ作り出すこと」と言い換えることができます。
ここで具体例を示します。ここでは、ブロックサイズが16 MiBのNANDフラッシュメモリを搭載し、表記容量64 GB、搭載するNANDフラッシュメモリ容量64 GiBという、説明用の簡易的な例を使用します。
表記容量64 GBのSSDの、ホストからデータ記録可能なセクタ数は、1セクタを512バイトと仮定してJESD218[1]記載の計算方法を使用すると、21168 + 1953594 x 64 = 125045424セクタと求められます。
1セクタが512バイトですから、125045424セクタはおよそ59.6 GiBとなります。つまり、ユーザが記録可能な容量は約59.6 GiBです。
このユーザが使用可能な約59.6 GiBの容量に対して、容量の50%を使っている場合と、80%を使っている場合とで、GCの効率がどの程度変わるか、つまり「SSD容量に対する使用率が、GCの効率悪化、ひいては寿命の消費にどの程度影響を及ぼすのか」を実際に見積もってみます。
以下の図3は、ユーザが使用可能な容量に対して、その50%を使っている場合の様子です。
なお、図3では、有効データがすべてのブロックに一様に分散している状態を示しています。この状態を選択したのは、この状態がGCの効率が最も悪くなる（＝最悪値を見積もることができる）ためです。
※注2： SSDの内部状態が常にこの図3や図4のようになっているわけではありません。通常、ブロックが保持する有効データのサイズには偏りがあります。また、SSDが搭載するNANDフラッシュメモリの全てのブロックがユーザデータの記録に使用できるわけではありません。実際には管理情報を記録するためのブロックなどが必要です。この図3や図4はあくまで説明のための例です。
図3：GC処理イメージ（ユーザが使用可能な容量の50%を使用している場合）
この図3の例では、SSDに記録されている有効データのサイズは、ユーザが使用可能な容量の50%、つまり約29.8 GiBです。
SSDが搭載するNANDフラッシュメモリの総容量は64 GiBですから、比率で言えば、29.8 ÷ 64 = 0.465となり約46.5%です。
つまり、SSDが搭載するNANDフラッシュメモリの各ブロックは、ブロックサイズの約46.5%の有効データを保持していることになります。
この状況でGCを行う場合、コピー元として2つのブロックを選択し、その2つのブロック内の有効データを1つのブロックにコピーする、という処理を行います。
コピー元ブロック数の計算は、「無効データのサイズを合計して1ブロック分になるのに必要なブロック数を計算する」という方法で行います。まさに「ゴミ集め」ですね。
図3の例では、全てのブロックは有効データをブロックサイズの約46.5%だけ保持している、つまり、無効データのサイズはブロックサイズの約53.5%ですから、ブロックを2つ集めれば、無効データの合計サイズが1ブロックのサイズを上回ります。
実際には、有効データサイズがとても少ないブロックがあれば、そのブロックをコピー元として選択することで、GCの効率を改善することができます。
この図3では、実際にコピーしたデータのサイズはブロックサイズの46.5% × 2 = 94%、約14.9 MiBとなります。
次に、図3と同じユーザが使用可能な容量に対して、その80%を使っている場合の様子を、図4に示します。
図4：GC処理イメージ（ユーザが使用可能な容量の80%を使用している場合）
この図4の例では、SSDはユーザが使用可能な容量の80%、つまり約47.7 GiBの有効データを保持しています。
SSDが搭載するNANDフラッシュメモリの総容量に対する比率は、47.7 ÷ 64 = 0.745となり約74.5%です。
ここでも、図3と同じように、有効データがすべてのブロックに一様に分散している状態を仮定すると、SSDが搭載するNANDフラッシュメモリの各ブロックは、ブロックサイズの約74.5%の有効データを保持していることになります。
この状況でGCを行う場合、コピー元として4つのブロックを選択し、その4つのブロック内の有効データを3つのブロックにコピーすることで、フリーブロックを1つ作り出すという処理をしなければなりません。
なぜなら、図4の例では、各ブロック内の無効データのサイズは約25.5%ですから、ブロックを4つ集めないと無効データの合計サイズがブロックサイズを上回らないからです。
この結果、図4の例では、GCによる1回のコピー処理で約47.7 MiBのデータをNANDフラッシュメモリに書き込んでいます。
ここで、図3の例と図4の例を比較すると、GCによる1回のコピー処理におけるNANDフラッシュメモリへの書き込みデータサイズが約3.2倍になっています。
これは、図4のほうが図3よりも寿命の消費量が約3.2倍大きくなっていることを示しています。
図1や図2の記号を用いて言えば、Fによる寿命の消費量が3.2倍になるイメージです。
この差の原因は、図3と図4のたった一つの違い、つまりSSD容量に対する有効データのサイズ（＝使用率）です。
図3と図4では、有効データサイズの差は30%ですが、GCによる寿命消費量には3.2倍の差ができます。
このことから、SSDを使う時は、容量に余裕をもって使うべき、ということが言えます。
例えば、256 GBのSSDを使用する場合、有効データサイズが常時200 GBを超えるような状態で使用するよりも、有効データサイズが常時百数十GBになるように使用するほうが「SSDにやさしい使いかた」となり、寿命をより有効に使用できます。
なお、NANDフラッシュメモリのブロックサイズが同じ場合、特にSSDが搭載するNANDフラッシュメモリの容量（≒表記容量）が小さければ小さいほど、有効データサイズ（＝使用率）の差がGCの効率に与える影響が大きくなります。
したがって、SSDを選ぶ時は、できるだけ大きい容量のものを選ぶべきです。
例えば、格納する見込みのデータサイズが100 GBに満たないからといって、128 GBのSSDを選択するのではなく、256 GBのSSDを選択したほうが、はるかに「SSDをやさしく使う」ことができます。
さらに言えば、GCの効率が悪い（＝GCでコピーするデータサイズが大きい）とWriteの性能もReadの性能も大きく落ちます。
これは、GCによるコピー処理でNANDフラッシュメモリのバンド幅が大きく占有されてしまうからです。
コピー処理でNANDフラッシュメモリのバンド幅が占有されるのですから、ホストから発行されたWriteやRead処理に割り当てることができるバンド幅が小さくなることも自明です。
したがって、性能を高く保つためにも、SSDは、可能な限り容量に余裕をもって選択して使うのが良いということになります。
広いLBA空間にランダムライトし続けるのはダメ！
＜ポイント：以前より性能は向上したが、それでもランダムライトはどちらかと言えば苦手＞
2010年代に入ると、SSDの小サイズ（例：4 KiB）のランダムライト性能はそれまでと比較して大きく向上しました。
これは主に、ホストがデータの読み書きで指定するアドレスであるLogical Block Address (LBA)と、そのLBAの最新データが記録されているNANDフラッシュメモリのアドレスの、マッピング情報を管理する方式の変化によるものです。
具体的には、OS、特にWindows（のファイルシステム）がストレージの読み書きを行う際のデータサイズの大半が4 KiB程度の小サイズであるという特性[2]に基づいて、SSDが搭載するNANDフラッシュメモリを、その4 KiB程度の単位で分割し、記録されているデータとそのデータのLBAとのマッピング情報をその単位で管理する方法が主流となったことによります。
上記の管理方法は、NANDフラッシュメモリのページ単位で管理することから、「ページマッピング」とか「ページレベルマッピング」などと呼ばれます[3][4][5]。
それに対して、それまでの管理方法はNANDフラッシュメモリのブロック単位で管理することから、「ブロックマッピング」とか「ブロックレベルマッピング」などと呼ばれます。
また、これら2つの管理方法を組み合わせた「ハイブリッドマッピング」などと呼ばれる方法もあります。
このマッピング情報の管理方法の説明はそれだけで記事が複数本書けるボリュームですので、ここでは割愛させていただき、別記事で説明しようと思います。
話を元に戻します。
上記「ページマッピング」方式の導入によって、LBAがランダムかシーケンシャルかにかかわらず、小サイズの書き込みデータを効率良くNANDフラッシュメモリに記録して管理することができるようになりました。
この結果、ユーザデータのGCの効率が改善し、「ブロックマッピング」を採用した製品と比較して特にランダムライト性能が向上しました（注3）。
図1や図2の記号を用いると、Fの要素による寿命消費が小さくなりました。
しかし、ページマッピング方式を用いても、LBA空間の広い範囲にランダムライトをされるとGCの効率が悪くなります。
また、そのような状況では、ページマッピング方式のデメリットである、管理情報サイズの肥大化が寿命に影響を与えるようになります。
図1や図2の記号を用いると、Fの要素だけでなく、CとDの要素による寿命消費が無視できなくなってしまいます。
GCの効率が悪くなるということは、コピーするデータのサイズが増えるということになりますので、TBWが小さくなります。つまり、LBA空間の広い範囲に対する小サイズのランダムライトはSSDにやさしくない使いかた、となります。
一方、LBA空間に対するシーケンシャルライトであれば、GCの必要がほとんどないか、比較的効率良くGCを行うことができます。
HDDと比較した場合のランダムライト性能の高さ（レイテンシの短さ）は、SSDの特徴として挙げられることが多いです。
確かに、LBAに対するデータ記憶位置が基本的に固定されていてかつ物理機構が存在するHDDと比較すると、物理機構が存在しないSSDのランダムライト性能が高い（レイテンシが短い）ことは確かです。
しかし、速い（性能が高い）ことと、それが得意かどうか、さらにはそれがSSDにとってやさしい使いかたかどうかは別の話です。
注3：なお、「ページマッピング」をもってしても苦手な小サイズ書き込みのパターンはあります。例えば、ページマッピングの管理単位に「揃っていない(unaligned)」書き込みです。1セクタ512バイトのSSDにおいて、ページマッピングの管理単位が4 KiB（8セクタ）の場合、4 KiB未満の書き込みや、書き込みデータの先頭LBAが8で割り切れない場合、また書き込みデータの末尾LBAが8で割り切れない場合は、ページマッピングの管理単位に「揃っていない」書き込みとなります。このような書き込みかたは「SSDにやさしくない使いかた」です。
同じデータをReadし続けるのもダメ！
＜ポイント：特定のデータを頻繁にReadするワークロードは要注意＞
NANDフラッシュメモリにはRead Disturbという特性があります。
Read Disturbの詳しい説明は省略しますが、端的に言えば、NANDフラッシュメモリの同じ場所（メモリセル）をひたすらReadし続けると、そのメモリセルだけでなく周辺のメモリセルまで巻き込んで、データが化ける可能性があるということです。
SSD製品の中には、NANDフラッシュメモリのこの特性に対処するために、例えばブロック単位などでRead回数をチェックし、Read回数がある一定の回数を超えると、そのブロックの有効データを他のブロックにコピーする、などの処理を行っているものがあります。
この処理は、やらないに越したことはない処理で、図1や図2の記号で言えば主にFの要素に該当し、寿命の消費を増やしてしまう原因となります。
つまり、「SSDに記録した同一データを比較的短期間に非常に多い回数読み出すような使い方はNANDにやさしくない」ということになります。
問題となる頻度や回数は、NANDフラッシュメモリの特性（素性）やSSDの管理アルゴリズムに依存します。
ホスト側でこれに対処するためには、例えば、同じデータを異なるLBAに複数個書いておいて同じデータを読む場合でも交互に異なるLBAから読む、といった方法が考えられます。
SSDではないですが、PlayStation4向けのゲームソフトでは、HDDのシーク時間を嫌って、400個も複製されたデータがあったそうです[6]。目的は違いますが、発想は同じですね。
なお、昨今のSSDもしくはSSDを採用したストレージシステムには、重複排除(deduplication)と呼ばれる技術を採用した製品があります。この技術・機能は良く"dedup"と略され、日本語では「デデュープ」と呼ばれることが多いです。
この、重複排除を採用したSSDを使用する場合、Read Disturbに対して「同じデータを異なるLBAに複数個書いておく」という対処をしても無意味です。
なぜなら、同じデータを異なるLBAに複数個書いても、重複排除の機能が「このデータはあのLBAに書かれたデータと同じだ」と検出し、どちらのLBAでReadしても同じNANDのセルをReadしてしまうように最適化されてしまうからです。
重複排除機能は主にストレージの容量効率を上げる目的で導入される機能ですが、どのような仕組みでどのような処理をしているのかをきちんと把握しないと、思わぬ影響が出ることもあります。
温度や振動などの動作環境にも注意！
＜ポイント：温度以外の動作環境にも注意＞
PCIe Gen4をインターフェースとするSSDが登場し、マザーボードやM.2のSSDを購入するとヒートシンクがついてくるようになったこともあり、ハイエンドSSDの、動作による発熱への対処が必要になっていることについては、もはや説明するまでもないかと思います。
ただ、SSDの動作による発熱だけでなく、SSDが動作する環境温度も重要です。
SSDコントローラは一般的な半導体チップとしてあまりの高温には弱いですし、NANDフラッシュメモリは高温になるとデータ保持特性が落ちますので、高温での動作は避ける必要があります。
さらに温度については、「温度変化」にも注意が必要です。
NANDフラッシュメモリは、データを書き込んだ時の温度とデータを読み出した時の温度の差が大きいと、エラー率が上がります[7]。
したがって、SSDを使うときは、高温でなく、かつなるべく一定の温度（範囲）下で使うことが推奨されます。
動作環境という点では、振動にも注意が必要です。
良く「SSDは（HDDと比較して）可動部品がないから振動に強い！」と言われます。
確かに、NANDフラッシュメモリをはじめとした半導体部品には可動部はありませんが、SSDがコネクタを介して接続されている場合、このコネクタが厄介です。
コネクタが振動に弱い、もしくは、振動等による一時的な（瞬間的なものを含む）接続断に対してプロトコルが弱い場合、SSDもしくはSSDを搭載したシステムの設置場所の、振動等の環境要因が重要になります。
例えば、SATAは、接続断（リンクロスト）後の復帰方法が、「未完了だったコマンドはホストが再実行する」などと規定されているため、比較的耐性がある（ロバスト）と言えます。
一方、NVMeでは、ホストとSSD間のPCIeの接続が切れるなどして再接続した場合の復帰方法（未完了だったコマンドの処理方法など）が、記事執筆時点（2019年10月時点）では定められていません。
NVMeは、主にホスト側のメモリ（たいていはDRAM）を介してホストとSSDがコマンドやレスポンス、そしてデータのやり取りを行います。
したがって、一旦接続が切れると、そのメモリの状態とホストおよびSSDの状態の整合性を取り戻すことがとても難しいです。
これはそれぞれのインターフェース（プロトコル）が想定したユースケースに起因する設計の違いとも考えられます。
コネクタを採用しないNANDフラッシュメモリを搭載したストレージとしては、BGA形状の製品が存在します。
BGA形状の製品の場合、はんだの耐久性が振動に対する耐性を決定することになります。アンダーフィルを行うなど、必要に応じてはんだ接合部の強度を上げる対策を行う必要があります。
オフィスや家庭のような良く管理された（well managedな）環境で使用する機器（PC等）に使うSSDであれば大きな問題にはなりませんが、そのような環境でない場合、振動のような温度以外の動作環境にも注意を払う必要があります。
電源は、安定した電源を使い、手順を守って切らないとダメ！
＜ポイント：電源起因の不具合は、後からの修正が難しいことが多く、事前対策必須！＞
＜ポイント：手順を守らない電源断は、データ喪失につながるおそれがあります！＞
SSDに限った話ではなりませんが、電源も重要です。
例えば、SSDの電源を正しい手順で切らないと、その「ツケ」が「寿命が短くなる」という形で跳ね返ります。
プロトコルにもよりますが、例えばSATAではSTANDBYもしくはSTANDBY IMMEDIATEコマンドを発行して、そのコマンド完了の返答がSSDから届いてから電源を落とすべきです。
SSD側は、それらのコマンドを受領すると、電源が切られても問題ないように、SSDの内部状態を整合性がとれた状態に整えてから、コマンド完了の返答を返します。
それらの定められた（推奨された）方法以外で電源が切られると、SSDの内部状態が整合性がとれていない状態になり、次に電源が投入された時に、SSDの内部状態の整合性をとる（とり直す）処理を行います。
この処理の際に、例えば、電源が切られる直前に行った処理の内容をNANDフラッシュメモリの中のデータを読み出してチェックしたり、整合性がとれていない状態のデータを含むNANDフラッシュメモリのブロックの有効データを別のブロックに移動させるなど、NANDフラッシュメモリに対する読み書きが発生します。
このような処理によって、寿命が消費されてしまうのです。
このSSDの内部状態の整合性をとる処理は、製品にもよりますが、かなり長くなることがあります。特に、容量が大きい製品の場合、数十秒オーダーの時間がかかることもあります。
良く「SSDは速いからマシンの起動が速くなる」と言われますが、その恩恵にあずかるためには、手順を守って電源を切る必要があります。
つまり、「手順を守って電源を落とすのがSSDのやさしい使いかた」となります。
また、電源が不安定ですと、NANDフラッシュメモリに対する操作が不安定になります。
NANDフラッシュメモリは、コントローラとのインターフェースの電圧（1.2 Vや1.8 Vなど）と比較して、メモリセルの操作（Read、Program、Eraseのこと）には比較的高い電圧を必要とします。そのため、電源電圧の「揺れ」には敏感です。
製品によっては、そのわずかな電源電圧の揺れ（特に降下）を検出してNANDフラッシュメモリの不安定な動作を防止する機能を持つものもありますが、その機能をもってしても「被害の緩和」しかできません。
安定した電源を供給することは、なによりSSDにとってやさしい使いかたです。
なお、寿命とは直接の関係はありませんが、NVMeやSATAの場合、Volatile Write Cacheの設定を有効にした状態で、手順を守らずに電源を切ったり、電源が不安定でSSDが許容する電圧の範囲を逸脱した場合、Writeコマンドで転送したもののNANDフラッシュメモリに書き込まれていなかったデータが、最悪、失われます。
これは規格書に明記されている振る舞いです。
SATAが準拠する"ATA Command Set"の仕様書[8]の4.2.3節"Interactions with volatile caches"に、以下のような記載があります。
While processing write commands, as a result of using volatile write cache, there is a period of time during which the user data may be lost if:
a) an unexpected power removal occurs (see 4.2.2); or
b) a hardware failure occurs.
If an error occurs while the device is writing to the medium and that error is reported as a deferred error, then the device may invalidate cached user data. This invalidation may occur for data cached in both volatile and non-volatile caches.
If volatile write cache is enabled and the device processes:
a) a flush command;
b) a STANDBY IMMEDIATE command; or
c) a write stream command with the FLUSH bit set to one,
then all user data in volatile write cache becomes non-volatile before returning command completion without error.
したがって、SSDに対する電源は、安定した電源を使用し、かつ電源を切るときは定められた手順に沿うにこしたことはないのです。
おわりに
この記事では、SSDの使いかたを「寿命消費に与える影響」という視点からまとめ、SSDの「やさしい使いかた」と「やさしくない使いかた」をまとめました。
SSDの寿命に影響を与える「使いかた」は、この記事で説明したように多岐にわたりますが、今後SSDを選ぶ際にご参考になれば幸いです。
次の記事では、寿命からは一旦離れて、SSDを選ぶ際の別の指標のひとつである「SSDのデータアクセス性能」についてまとめたいと思います。
Reference
[1] JEDEC, "Solid-State Drive (SSD) Requirements and Endurance Test Method", JESD218B.01, March, 2016
[2] 麻生、花房、「SSDの仕組みと特徴」、Design Wave Magazine, no. 132, page 36, October, 2008
[3] Kim, et al., "A Space-efficient Flash Translate Layer for Compactflash Systems", IEEE Transactions on Consumer Electronics, vol. 48, no. 2, pp. 336-375, May, 2002
[4] Hu, el al., "Achieving page-mapping FTL performance at block-mapping FTL cost by hiding address translation", in proceedings of IEEE 26th Symposium on Mass Storage Systems and Technologies (MSST), May, 2010
[5] "A Summary on SSD & FTL"、2019年10月29日閲覧
[6] WIRED、「特報：見えてきた「プレイステーション 5」の姿──ソニーが世に問う新しいゲーム体験のすべて」、2019年10月9日（2019年10月25日閲覧）
[7] 福田、「福田昭のストレージ通信 Micronが考えるメモリシステムの将来（3）：SSDをクルマに載せる(1/2)」、2016年7月6日（2019年10月23日閲覧）
[8] T13 / International Committee for Information Technology Standards (INCITS), "ATA Command Set - 4 (ACS-4)", Revision 14, October 14, 2016
ライセンス表記
この記事はクリエイティブ・コモンズ 表示 - 継承 4.0 国際 ライセンスの下に提供されています。