1. 「くも」の 中身は、どんな 場所?
1. 「雲」の正体は、電力とネットワークを備えた建物
1. リージョン・AZ・データセンター ── 「1棟」とは限らない
クラウドの 会社の せつめいには、「ゾーン」と いう ことばが 出て きます。ゾーンは、データセンターの まとまりの ことです[1]。
データセンターは、たくさんの 機械が 入った 建物です。ゾーンは、1つの データセンターの ときも ありますし、もっと 多い ときも あります[1]。だから、「ゾーン= 建物 1つ」とは かぎりません。
くもと いう 名前に だまされそうですが、データは 地上の 建物の 中に あります。
クラウドという名前から、空のどこかにデータが浮かんでいるように思えます。けれど事業者の説明を読むと、実体は、データセンターという建物の中のサーバー(コンピューター)です。
AWSは「アベイラビリティーゾーン(AZ)」を、ほかのAZから電力やネットワークを切り離した、1つ以上のデータセンターと説明しています。リージョン(地域)は、このAZを3つ以上集めたものです[1]。ここで大事なのは、AZ=建物1棟とは限らないことです。
Azureも、可用性ゾーンを、電源・冷却・ネットワークが分けられた独立のデータセンターの集まりと説明しています[2]。呼び名は事業者ごとに違っても、「場所を1か所にしない」という考え方が並んでいます。
2. 大事な データは、いくつもの 場所に 入れる ことが ある
2. 預けたデータは、複数の建物に複製されることがある
2. 冗長化された保存 ── 「9が11個」の耐久性
クラウドの 会社は、大事な データを 1つの 建物だけには おかない ことが あります。サービスに よって ちがいます。たとえば AWSの ある 保存の しかたでは、少なくとも 3つの ゾーンに、同じ データの コピーを のこします[4]。
大事な ノートを コピーして、学校と 家と おばあちゃんの 家に おく ような ものです。どこかで 火事が あっても、ほかの 場所に のこります。ただし 本当は、コピーは 会社の しくみが 自動で やって くれます。
この 保存の しかたでは、1年の うちに データが なくなる ことが とても 少なく なるように 作った、と せつめいされて います。「9」が 11こ ならぶ 数字で 表します。ただし、これは 作るときの 目安で、ぜったいに なくならない という 意味では ありません[4]。
複数の建物に置くかどうかは、サービスや設定で違います。たとえばAWSのS3という保存サービスの標準的なクラスは、リージョン内の少なくとも3つのAZにまたがり、複数の装置に同じデータを保存します[4]。大事なノートをコピーして、学校と家と祖父母の家に置いておくようなものです。ただし本当は、コピーは事業者の仕組みが自動で行います。
設計上の耐久性は、1年間で99.999999999%、つまり9が11個並ぶ数字です[4]。100から引くと、1年で失われる割合は0.000000001%で、1000億分の1にあたります。仮に1000万個のデータを預けたとして、計算上は1万年に1個ほどです。
これは設計上の値です。保存範囲が1つのAZだけのクラスもあるため、全部のサービスが同じ守り方ではありません[4]。
AWSのS3の標準的なストレージクラスは、リージョン内の最低3つのAZにまたがり、複数のデバイスにオブジェクトを冗長して保存する。設計上の耐久性は年間99.999999999%(9が11個)とされる[4]。
100−99.999999999=0.000000001(%)で、割合にすると1000億分の1である。1000万個のオブジェクトを預ければ、1年あたりの期待損失は1000万×1000億分の1=1万分の1個で、およそ1万年に1個という計算になる。これは設計上の値であり、実績や保証を示す数字ではない。
耐久性の設計値はストレージクラスごとに異なり、保存範囲が1つのAZのみのクラスもある。同じ事業者でも、全サービスが3か所以上に置かれるわけではないので、一般化はできない[4]。
3. 建物は、ちかすぎても とおすぎても こまる
3. ゾーンは、近すぎず遠すぎない距離に置かれる
3. 距離のトレードオフ ── 低遅延と災害耐性、事業者ごとの差
ゾーンどうしは、たがいに 少し はなれて いて、100キロメートルより 近い ところに あります[1]。ちかい ほど、データを やりとりする 時間が みじかく なります。
でも、ちかすぎると、1つの 大雨や、でんきが とまる ことで、いっしょに こまって しまいます。だから ゾーンは、さいがいを わけられる くらいには はなれて います。リージョンを いくつも つかう ときは、はなれる ほど、大きな さいがいに 強く なります。その かわり、通信の おくれは 大きく なります[2]。
ちかい ほうが いいのか、とおい ほうが いいのか。どちらも 大事で、その あいだで 会社は 場所を 決めて います。
Azureの説明は、ゾーン同士の距離を「低遅延で結べるほど近く、嵐や停電などの障害を分けられるほど離れている」と述べています。複数のリージョンを使うときは、距離が長いほど大きな自然災害からの回復性が高くなる一方、遅延は増える、とも書いています[2]。
AWSは、AZを互いに数キロ以上離しつつ、すべて100km以内に置くと説明します[1]。ゾーンは、障害を分けられる距離を保ちつつ、通信の遅れが大きくなりすぎない範囲に置かれているようです。その折り合いのつけ方が、こうした数字に表れているように見えます。距離が長いほど災害に強いという話は、複数のリージョンを使う場合のものです。
ただし、作りは一様ではありません。Googleの英語の説明ページによると、リージョンは通常3つ以上のゾーンでできていますが、大阪などは、3つのゾーンが1〜2か所の物理データセンターの中にあり、拡張中とされています[3]。事業者や時期で違うので、「どこも同じ」と考えないほうが安全です。
Azureは、ゾーン間の物理距離を「低遅延ネットワークを提供できるほど近く、嵐や停電などの障害を分離できるほど離れている」ものと説明する。複数リージョンの使用では、距離が長いほど大規模な自然災害への回復性が高い一方、遅延が増える[2]。
AWSはAZ同士を互いに数キロ以上離しつつ、すべて100km以内に置く[1]。これは、遅延を抑える近さと、障害を分ける遠さの間で置き場所を決めた構成に見えるが、その意図はAWSの説明ページ自体には書かれていない。
構造も一様ではない。Google Cloudの英語ページ(2026年9月に確認)は、リージョンは通常3つ以上のゾーン、つまり3つ以上の物理データセンターでできているとしつつ、ストックホルム・メキシコ・大阪・モントリオールは、3つのゾーンが1〜2か所の物理データセンター内にあり、少なくとも3か所への拡張中と説明する[3]。リージョンの作りは事業者と時期で違うので、他の例に一般化しない。
4. 日本では、東京の まわりに 多い
4. 国内のデータセンターは、東京圏に約6割
4. 立地の偏り ── 関東61.1%と、IX・海底ケーブル陸揚局の数字
では、日本では どこに あるのでしょう。国の しりょう(2024年10月)に よると、日本の データセンターの 6割くらいは 東京の まわり、2割くらいは 大阪の まわりに あります[5]。北海道は 2パーセント、九州は 3パーセントほどです。
どうして 東京の まわりに 多いのでしょう。しりょうは、通信の おくれが 少ない ことと、行きやすい ことを あげて います[5]。インターネットの 線が 集まる 場所も、東京と 大阪の あたりに 多い ようです。
インターネットの 線が 集まって いる 場所に 近い ほうが、はやく つながります。
内閣官房のウェブサイトに載っている総務省の資料(2024年10月)によると、国内のデータセンターの約6割が関東(東京圏だけで57%)に、約2割が関西に集まっています。地域別では、関東61.1%、関西24.3%、九州2.8%、北海道2.0%です[5]。関東は北海道の約30倍にあたります。
理由として資料が挙げるのは、レイテンシー(通信の遅れ)と交通アクセスです[5]。インターネットの相互接続点(IX)の接続数は関東74.2%・関西24.2%、国際海底ケーブルの陸揚局は関東53.7%・関西26.8%で、通信の要所も同じ地域に偏っています[5]。
不動産サービス会社JLLの解説は、通信事業者どうしがつながる拠点が東京と大阪にあることや、特別高圧の電力が使えること、水害などの自然災害を避けやすいことを、立地の条件に挙げています[7]。ただし、これは二次資料です。
一方、バックアップ用や地元企業の需要のために、地方にも小型のデータセンターが多数あります[5]。
総務省の資料(2024年10月、内閣官房のGX実現に向けた専門家WGの資料3)によると、国内のデータセンターの約6割が関東(うち東京圏で57%)、約2割が関西にある。地域別では関東61.1%、関西24.3%、九州2.8%、北海道2.0%で、関東は北海道の約30倍(61.1÷2.0≒30.6)にあたる[5]。
資料は、関東に置かれる理由としてレイテンシーと交通アクセスを挙げる。また、IX(ネットワークの相互接続点)の接続数は関東74.2%・関西24.2%、国際海底ケーブルの陸揚局は関東53.7%・関西26.8%で、通信の要所も同じ地域に偏る[5]。
JLLの記事は、経産省の2021年4月調査の引用として、東京圏と大阪圏に80%が集中するとし、理由に、ISPの相互接続拠点が東京の大手町と大阪の堂島に集中していることを挙げ、立地条件に特別高圧電力・通信遅延の少なさ・自然災害を避けられることを挙げる[7]。JLLは二次資料で、経産省の原文は確認していない。
集中の割合は資料ごとに、年も対象範囲も違う(関東約6割は2024年の資料、東京圏と大阪圏の合計80%はJLLが紹介する2021年調査の数字)ので、混ぜて比べない。他方、バックアップ用や地場企業の需要のため、地方には小型のデータセンターが多数ある[5]。
5. 北海道にも、ふやす わけ
5. 集中のリスクと、北海道・石狩の例
5. 分散立地の政策 ── 第3・第4の中核拠点と石狩の外気冷房
東京の まわりと 大阪の まわりが、いっしょに 大きな 地震で こまると、日本じゅうの 通信に 大きな えいきょうが 出る かもしれません。国は、そう 考えて います[6]。
そこで 国は、2022年6月に、東京の まわりでは ない 7か所の データセンターを 助ける ことに 決めました。北海道や 九州に、新しい 大きな 場所を 作る 考えも あります[6]。
北海道の いしかり市には、2011年に できた データセンターが あります。外の つめたい 空気で 機械を ひやします。市の しょうかいには、ふつうの 町の データセンターと くらべて、電気を やく4割 少なく できる と あります[8]。
ただし、これは 1つの 建物の 数字で、ほかの 場所には あてはまりません。
総務省の計画(2023年4月)は、データセンターの6割ほどが東京圏に集中していること、東京圏や大阪圏が大震災で被災すると全国規模で通信に多大な影響が出るおそれがあることを述べ、分散立地が求められるとします[6]。背景として、2011年の東日本大震災で太平洋側の海底ケーブルの多くが切断されたことも挙げています[6]。
国は、2022年6月に、東京圏以外の7か所のデータセンター整備への支援を決めました。方針は、当面は東京・大阪から離れ、再生可能エネルギーの可能性や海底ケーブルを陸揚げできる可能性のある北海道や九州で、第3・第4の中核拠点をつくることです[6]。
北海道の石狩市には、2011年11月15日に開所したデータセンターがあります。北海道の冷たい外気でサーバー室を冷やす「外気冷房」を使い、市の紹介ページは、一般的な都市型データセンターと比べて消費電力を約4割減らせるとしています[8]。事業者は、大規模地震の影響を受けにくい地域であることも理由に挙げます[9]。
約4割は「都市型との比較」という条件つきの、市の紹介の数字です。他の施設に当てはめることはできません。
総務省『デジタル田園都市国家インフラ整備計画(改訂版)』(2023年4月)は、データセンターの6割程度が東京圏に一極集中し、近年は第2の中核拠点として大阪圏への投資が増えているが、両圏が大震災で被災すれば全国規模で通信環境に多大な影響が生じうるとして、分散立地が求められると述べる。背景として、2011年の東日本大震災で太平洋側の海底ケーブルの多くが切断され、陸揚局が房総半島に集中している点にも触れる[6]。
政策面では、令和3年度補正予算で東京圏以外にデジタルインフラを整備する民間事業者への補助金を設け、2022年6月に東京圏以外の7か所のデータセンター整備への支援を決めた。整備方針は、10数か所の地方拠点を5年程度で整備し、当面は東京・大阪から離れ、再生可能エネルギーの可能性や海底ケーブルの陸揚げの可能性がある北海道や九州で、東京・大阪を補完・代替する第3・第4の中核拠点を促進する、というものである[6]。
北海道の例が、さくらインターネットの石狩データセンター(北海道石狩市、2011年11月15日開所)である。北海道の冷涼な外気でサーバー室を冷やす外気冷房方式で、石狩市の紹介ページは、一般的な都市型データセンターと比較して消費電力を約4割削減としている[8]。事業者の説明では、活断層がなく大規模地震の影響を受けにくいこと、津波・液状化のリスクが低いことも立地の理由とされる[9]。
約4割は、都市型との比較という条件つきの、市と事業者の紹介値であり、他社・他施設には一般化できない。事業者ページ自体には削減率の数字はない。
6. データを おく 場所を 決めるのは、だれ?
6. 東と西に置く工夫と、置き場所を決める人
6. 東西2拠点の構成と、所在地を決める主体 ── 利用者の選択と国の基準
東京と 大阪に 1つずつ リージョンを 作った 会社の れいが あります。東京は 2011年3月2日、大阪は 10年後の 同じ 日に 開かれました[10]。はなれて いるので、一方が 大きな さいがいでも、もう 一方で つづけやすい と ニュースで つたえられました[10]。
どこに データを おくかは、使う 人が えらべる ことが 多いと せつめいされて います[11]。ただし、えらべるのは サービスごとで、れいがいが ないかは 決まりを 読まないと わかりません。
国の きじゅんも あります。市や 町の 仕事の データを あつかう クラウドには、データセンターを 日本の 中に おく ことを もとめて います。東日本と 西日本に 分けて つなぐ ことも もとめて います[12]。
東京と大阪の2拠点を使う例があります。AWSの東京リージョンは2011年3月2日、大阪リージョンは10年後の同じ日に開かれました。大阪は3つのAZで構成され、両者は直線で約400km離れているため、2拠点で災害対策を組みやすいと報じられました[10]。約400kmは報道の数字で、事業者の公式ページでは確認していません。
AWSやGoogle Cloudの一部のサービスでは、どのリージョンにデータを置くかを利用者が選べます。AWSは、利用者のデータを保存するリージョンは利用者が選び、同意なく選ばれたリージョンの外へ移動したり複製したりしないと説明しています[11]。Google Cloudも、対象サービスで特定のデータ所在地を設定できると説明しています[3]。ただし「選べる」のはサービスごとで、バックアップや運用データなどの例外の有無は、それぞれの規約で確かめる必要があります。
国の基準もあります。デジタル庁の、自治体のシステム向けの基準(2022年10月)は、クラウド事業者に、データセンターを日本国内に置くこと、情報資産は指示がない限り国内で保管すること、障害時の退避先も原則国内とすることを求め、接続サービスには東日本と西日本それぞれから独立した接続を求めています[12]。これは自治体システムの調達の基準で、民間サービス全般の法律上の義務ではありません。
AWSの東京リージョンは2011年3月2日、大阪リージョンは10年後の同日に開設された。大阪は3つのAZで構成され、東京と大阪は直線で約400km離れており、2つのリージョンで災害対策構成を組みやすい、と報じられた[10]。約400kmは報道の記述で、AWSの公式ページでは確認していない。ここでは特定企業の例の1つとして扱う。
データ所在地を決める主体の1つは、利用者である。AWSは、カスタマーコンテンツを保存するリージョンは利用者が選び、AWSは利用者の同意なく、選択されたリージョンの外へコンテンツを移動もレプリケートもしないと説明する[11]。Google Cloudも、対象サービスで特定のデータ所在地を設定できるとし[3]、Azureはリージョンが属する地域(geography)をデータ所在地の境界として扱う[2]。ただし、選択できるのはサービスごとであり、バックアップ・サポート・運用データなどの例外の有無は、各サービスの規約で確認が必要である。
もう1つの主体が、国の基準である。デジタル庁『地方公共団体情報システムのガバメントクラウドの利用に関する基準(第1.0版)』(2022年10月)は、クラウド事業者の要件として、データセンターの物理的所在地を日本国内とし、情報資産はデジタル庁が指示しない限り国内に保管し、障害時の退避先も原則国内とする。接続サービスには、東日本エリアと西日本エリアそれぞれの独立した接続を求める[12]。
これは自治体システム向けの調達基準であって、日本のクラウド全般や民間サービスの法律上の義務ではない。東と西の2拠点で備える考え方は、事業者の例(大阪リージョン)と国の基準のどちらにも見られる。
7. じぶんでも しらべて みたく なったら
7. 自分でも調べてみたくなったら
7. 自分でも調べてみたくなったら
ためして みよう。地図帳の 日本地図を ひらいて、東京、大阪、北海道の いしかり市を さがします。もし データセンターを 2つ おくなら、どこと どこに しますか。ちかくに おく いい ところと、はなれて おく いい ところを、1つずつ 考えて みましょう。
おうちの 人や 先生にも、「どこが いい?」と 聞いて みると、ちがう 考えが 出るかも しれません。
日本地図を開いて、東京、大阪、北海道の石狩市、九州を探してみましょう。データセンターを2か所置くなら、どこと、どこにしますか。近くに置くよさと、離して置くよさを、1つずつ考えます。
もう少し調べたくなったら、家の人や先生に、いま使っているクラウドのサービスの名前を聞いてみてください。その会社の日本語の説明ページで、データの保存場所について何と書いてあるかを探します。書き方は会社ごとに違います。
しらべた もとの じょうほう
参考にした情報源
参考にした情報源と、その使い方
出典について:AWS・Microsoft Azure・Google Cloudの公式説明、総務省・内閣官房・デジタル庁の資料、石狩市とさくらインターネットの紹介ページ、不動産サービス会社JLLの記事、IT系ニュースサイトPublickeyの記事を使った。何に使ったかは、各項目の最後に書いている。数字は、記事を書いた時点(2026年9月)の資料による。
- AWS「AWS グローバルインフラストラクチャ(リージョンとアベイラビリティーゾーン)」。 https://aws.amazon.com/jp/about-aws/global-infrastructure/regions_az/ (AZの定義、リージョンの構成、AZ間の距離について)
- Microsoft Learn「Azure リージョンとは」。 https://learn.microsoft.com/ja-jp/azure/reliability/regions-overview (可用性ゾーンの構成、距離と遅延・回復性の関係、地域(geography)について)
- Google Cloud「Cloud locations(リージョンとゾーン)」(英語ページ)。 https://cloud.google.com/about/locations (ゾーンとリージョンの構成、大阪などの例外、データ所在地の設定について)
- Amazon S3 ユーザーガイド「データの耐久性」。 https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/DataDurability.html (複数のAZにまたがる保存と、耐久性の設計値について)
- 総務省 総合通信基盤局「データセンター等のデジタルインフラ整備の現状と課題」(GX実現に向けた専門家WG 資料3、2024年10月)。 https://www.cas.go.jp/jp/seisaku/gx_jikkou_kaigi/senmonka_wg/dai8/siryou3.pdf (国内データセンターの地域別の割合、IX・陸揚局の割合、集中の理由について)
- 総務省「デジタル田園都市国家インフラ整備計画(改訂版)」(令和5年4月)。 https://www.soumu.go.jp/main_content/000877891.pdf (東京圏への集中、分散立地の必要性、地方拠点の整備方針、海底ケーブルの被災について)
- JLL「国内回帰に舵を切るデータセンター立地場所」。 https://www.jll.com/ja-jp/insights/location-of-data-centers-moving-onshore (東京圏・大阪圏への集中の理由と立地条件について。二次資料)
- 石狩市「データセンターの立地(企業誘致)」ページ。 https://www.city.ishikari.hokkaido.jp/sangyo/yuchi/1002892.html (石狩データセンターの開所日、外気冷房、約4割の消費電力削減について)
- さくらインターネット「石狩データセンター」。 https://datacenter.sakura.ad.jp/location/ishikari/ (立地の理由の説明について)
- Publickey「AWS大阪リージョン正式オープン」。 https://www.publickey1.jp/blog/21/aws3.html (東京・大阪リージョンの開設日と、2拠点での災害対策について。報道記事)
- AWS「データプライバシーFAQ」。 https://aws.amazon.com/jp/compliance/data-privacy-faq/ (データを保存するリージョンを利用者が選ぶことについて)
- デジタル庁「地方公共団体情報システムのガバメントクラウドの利用に関する基準(第1.0版)」(2022年10月)。 https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/c58162cb-92e5-4a43-9ad5-095b7c45100c/3013abc6/20221007_policies_local_governments_outline_04.pdf (自治体システム向けの、データセンターの所在地と接続についての要件)
なおした ところ
更新履歴
更新履歴(改版の記録)
- 初版を公開。
このサイトでは、公開した記事の本文は原則として書き直しません。誤りが見つかったときや、内容が古くなったときだけ手を入れ、その理由をこの欄に残します。