これまでの「基礎」シリーズでは、「コンピュータはどう動くのか：ファインマンの超高速書類整理係」と「コンピュータは0と1をどうやって文字や画像に変えるのか」を通じて、コンピュータが命令を実行する仕組みと、情報を保存された値として表す方法を見てきた。その情報を別のコンピュータへ届けるには、別の問題を解かなければならない。二つの機械はメモリを共有せず、直接つながっているとも限らない。ファインマンの書類整理係なら、近くに保存された情報は番号の付いた引き出しを開けば取り出せる。しかし遠くのコンピュータにある情報を得るには、要求を送って返事を待つ必要がある。二つ目の引き出しを開くというより、別の事務所に手紙を書いて返信を待つことに近い。コンピュータの処理は先へ進める状態でも、答えが届くまでには長い時間がかかる場合がある。
インターネットは、異なる組織が運営するネットワークをつなぎ、このようなやり取りを可能にしている。情報は端末が最初につながったネットワークから複数のネットワークを通り、応答できるサービスへ届く。返事は、別の接続の連なりをたどって戻ることもある。この経路と、答えを用意するシステムの両方を理解すると、場所によって接続体験が異なる理由、要求が遅くなる理由、無関係に見えるサービスが同時に停止する理由が見えてくる。
端末から広いネットワークへ
スマートフォンやノートパソコンなどの端末は、まず Wi-Fi、携帯電話網、ケーブルなどを通じて身近なネットワークに接続する。そこから近くのネットワーク機器が通信をより広いネットワークへ転送する。家庭や職場では、通常、インターネットサービスプロバイダー（ISP）が外部のインターネットへの接続を提供し、携帯回線では通信事業者のネットワークが同様の役割を果たす。事業者はほかのネットワークと通信を受け渡せるため、二つの端末を専用の物理回線で直接結ばなくても、組織や長い距離をまたいだ通信が成立する。
インターネットがこの規模で動くのは、多くの通信が同じ回線や機器を利用できるからだ。ビデオ通話、メッセージ、ファイルのダウンロード、サービスへの要求は、途中のネットワークの一部を共有し、その利用可能な容量を使うことがある。それぞれの通信を送り分けるため、インターネットプロトコル（IP）は宛先アドレスを提供し、ルーターはそのアドレスを基に次の転送先を選ぶ。一つのサービスが複数のアドレスを持つ場合も、一つのアドレスの背後に複数の機械がある場合もある。アドレスがあれば宛先へ送れるが、それだけで一つの物理的な経路や特定の機械が決まるわけではない。
サービス名からアドレスを探す
アプリが example.com のような名前を持つサービスへ接続するには、通常、そのネットワークアドレスが必要になる。ドメインネームシステム（DNS）は、手紙を送る前に事務所の住所を調べるように、名前からアドレスを探す仕組みだ。端末にすでにアドレスが保存されていることもあれば、DNS リゾルバーに問い合わせることもある。リゾルバーはキャッシュされた答えを返すか、別のネームサーバーへ問い合わせる。名前に関する情報は多くのシステムに分散しており、世界共通の一冊の住所録に集められているわけではない。一つのサービスに有効なアドレスが複数あり、時間とともに変わることもある。
必要な答えがキャッシュになければ、アドレスの検索に追加のネットワーク通信が必要になり、アプリが本来の要求を送る前に時間がかかる。名前を解決できないと、宛先のシステム自体は正常でも、名前によるアクセスが失敗することがある。ただし、アドレスが見つかっても通信経路はまだ決まっていない。アプリがそのアドレスに向けて通信を送ると、途中のルーターがそれぞれの経路情報を基に次の接続先を選ぶ。名前の検索は経路を決めず、サービスから返事が来ることも保証しない。
ネットワークは情報をどう転送するか
宛先のアドレスが分かると、通信は端末のローカルゲートウェイから始まる。通常はルーターがこの役割を担う。ゲートウェイは別のルーターへデータを転送し、次のルーターは宛先アドレスと自分の経路情報を使って接続先を選ぶ。この連なりは複数の組織が運営するネットワークを横断することがある。地域のプロバイダーが別の通信事業者へ通信を渡し、その事業者が宛先のネットワークへ運ぶ場合もある。各ルーターはその地点で転送先を決める。すべての要求について旅程全体を指示する中央の管制室は存在しない。出発地も最終的な宛先も異なる通信が、途中の回線を一部共有することもある。
ルーターから次のルーターへ進む一段階を、ネットワークではホップ（hop）と呼ぶ。ホップ数が多いというだけでは、通信が遅いとは言えない。実際の距離、利用可能な回線、混雑、応答するシステムの場所も関係する。ネットワーク同士は、どの宛先にどの隣接ネットワークを通じて到達できるかという情報を交換している。回線やネットワークが停止すると、その情報が変わり、利用できる代替経路があり、事業者の方針も許す場合には別の道へ切り替わることがある。経路情報の更新には時間がかかることがあり、代わりの道がない宛先もある。要求が無事に到達しても、返事が戻るときに同じルーターを通るとは限らない。
答えはどこから来て、なぜ時間がかかるのか
要求が宛先のサービスを支える基盤に届いても、そこから何らかのシステムが答えを用意しなければならない。保存された情報を読み出し、計算し、権限を確認し、記録を更新するといった処理が必要になる。サービスの提供組織が機械を自社運用することも、ホスティング事業者に依存することもある。したがって、ネットワークの経路が正常であっても、すぐに答えが返るとは限らない。要求が届いた後に、ソフトウェアやストレージなどのシステムが遅くなり、過負荷、設定ミス、停止に陥ることもある。公開されている画像やファイルでも、内容が変わっていないものを毎回同じ遠方の機械に取りに行けば、時間とネットワーク容量を無駄にする。
適したコンテンツは、複数の場所にコピーを置ける。コンテンツ配信ネットワーク（CDN）は、元の提供元であるオリジン（origin）に毎回連絡する代わりに、キャッシュにあるコピーから一部の要求に答えられる。適切なコピーがないときは、別のキャッシュやオリジンからコンテンツを取得してから応答する必要がある。一方、ログイン、保存データの変更、最新情報の取得などには、その場で新たな処理が必要になる場合がある。保存、処理、配信を担当するシステムがそれぞれ別の組織に属していても、外部からは一つのサービスに見えることがある。用意された答えはネットワークを通って要求元の端末へ戻り、端末がその内容を解釈する。
同じサービスでも、ある場所では速く、別の場所では遅く感じられる。一方の利用者は接続のよいネットワークを通ってサーバーや近くの CDN 拠点へ到達できても、別の利用者の要求は長く混雑した回線や遠回りの経路を通ることがある。ネットワーク遅延（レイテンシ）は、ネットワーク内の移動に費やされる時間を指し、要求を送る時間と返事が戻る時間の両方が待ち時間に影響する。そのため、地理的に最も近いサーバーが、通信上も最も速く届くサーバーとは限らない。途中のルーターの数は経路の手掛かりにはなるが、実際の往復にかかる時間の代わりにはならない。適切な DNS のキャッシュがない場合は、要求の開始前に名前の検索だけでさらに待つこともある。
処理にかかる時間はネットワーク内の移動だけではない。応答するシステムはストレージを読み、結果を生成し、キャッシュにないデータを取りに行き、ほかのサービスを待つかもしれない。大量のデータを高速で送れる接続でも、こうした処理の遅れまでは取り除けない。返事が遅すぎたり届かなかったりすれば、アプリはタイムアウトを報告し、設計によっては再試行する。情報をどこに保存し、どこで処理するかは、速さだけでなく、要求を成功させるためにどのシステムが動いていなければならないかも左右する。複数のサービスが同じ基盤に依存していると、その影響は特に大きくなる。
なぜ複数のサービスが同時に停止するのか
通販サイト、銀行アプリ、動画サービスは所有者も目的も異なるのに、同じ基盤の一部に依存していることがある。Amazon Web Services、Microsoft Azure、Google Cloud などは計算処理やストレージを提供し、Cloudflare、Akamai、Amazon CloudFront はコンテンツ配信やその他のネットワークサービスを提供する。こうした分類には重なりもあり、各社は多数の異なるコンポーネントを運用している。そのため、同じ事業者の名前が出てきただけでは、共通の技術的依存関係も特定の障害の原因も証明できない。重要なのは、各サービスがある操作を実行するときに、具体的にどのコンポーネントを必要とするかだ。
単一障害点（single point of failure、SPoF）とは、ある操作に不可欠で、有効な代替手段がない構成要素を指す。物理的に一台の機械である必要はない。何千台ものコンピュータで動くプラットフォームでも、本人確認、設定、保存情報へのアクセスに単一の論理システムが必要な場合がある。そのシステムが停止すれば、正常なままの機械でも要求を完了できなくなる。拠点を地理的に分散させる効果は、重要な依存先が十分に独立している場合に限られる。複数のデータセンターが一つの制御サービスに頼ることもあれば、同じ事業者を使う複数のアプリが別々のコンポーネントを利用し、一部は障害の影響を受けないこともある。復旧力を決めるのは機械や拠点の数ではなく、設計がどのような障害に耐えられるかだ。
障害が起きる層が違っても、利用者に見える現象はよく似る。接続元のネットワークが、正常に動いているサービスへの経路を失うことがある。名前解決、ホスティング、配信の基盤が停止する場合も、ネットワーク自体は正常なのに個別のアプリが故障する場合もある。複数の組織に同時に影響が出たなら共通の依存先が疑われるが、それだけでは故障した部品を特定できない。
2026年10月20日、電源に関わる事象によって Google Cloud のロンドンリージョンのサービスが混乱した。同じ頃、Revolut、Lloyds、HSBC の利用者は銀行サービスへのアクセスに問題があると報告した。Google の暫定的な事故報告では、一つのデータセンターのゾーンが使用できなくなった結果、作業負荷が残りの基盤に移される一方、リージョン内の一部のシステムが停止したゾーンの構成要素に依存していたため、ほかのサービスにも影響が及んだと説明されている。Reuters は Revolut の障害と Google Cloud の事故に関連があると報じたが、各金融機関に影響した具体的な技術上の障害経路が公に確定したわけではない。
このような事故は、機械の台数や代替経路を増やすだけでは不十分な理由も示している。別のネットワーク経路では故障したアプリを直せず、すべてのサーバーが同じ制御システムに依存していれば台数を増やしても役に立たない。予備の仕組みは、問題となる依存先が実際に失われた後でも使える場合に初めて意味を持つ。信頼性を評価する際には、どの構成要素が使えなくなっても、サービスに期待される操作を続けられるかが重要になる。
ニュースアプリは記事をどう受け取るか
ニュースアプリは、ソフトウェアの設計によって障害の及ぶ範囲が変わることを具体的に示す。アプリは複数の出版社や報道機関から記事を直接取得し、必要に応じて各提供元へ個別に接続できる。一つの提供元が使えなくなっても、ほかの提供元への取得経路が機能していれば、そちらからの要求は成功し得る。ただし、それぞれが完全に独立しているとは限らない。名前解決、ホスティング、配信の基盤を共有している場合もある。それでも、すべての提供元の新着記事を取得するために必要となる、追加の単一の遠隔サービスをアプリが設けたわけではない。
別の方式では、中央のプラットフォームが複数の提供元から記事を集め、アプリへ届ける。プラットフォーム自体に多数のサーバーと拠点があっても、アプリに新しい記事を取得する別経路がなければ、その中央サービスが表示されるすべての情報源に共通する必須の依存先になる。出版社が通常どおり稼働していても、プラットフォームの障害によって新着記事が届かなくなることがある。二つの方式の画面は読者にはほぼ同じに見えるかもしれないが、次の要求が成功するために必要なシステムは異なる。
どちらの方式で障害が起きても、端末にすでに保存されている記事は読めるかもしれない。ただし、新しい記事を取得できるとは限らない。配信方式は、情報をどの事業者が取り扱うかにも影響する。暗号化は一般に、通信がネットワークを通過する間の内容を保護し、経路上の無関係な運営者が読める情報を制限する。一方、中央の配信プラットフォームが接続を終端したり内容を処理したりするなら、そのプラットフォームは配信するデータを読める可能性がある。通信中の暗号化だけでは、プラットフォームが信頼できるか、提供情報が正確かは分からない。この違いは、画面からは見えなくても、サービスの可用性とデータの取り扱いの双方に関わる。
要するに
インターネットの利用には、端末からの接続が正常であること以上の条件が必要だ。役に立つ返事が一つ届くまでには、異なる組織が運営するネットワークを通る経路と、実際に答えを提供できる複数のシステムが関わる。遅延はその両方で生じ、障害の影響は不可欠な依存関係に沿って広がる。設計が最も重要になるのは、むしろ外から見えにくい部分だ。複数の組織が一つの重要な部品に依存することも、一つのアプリが独立した情報源を一つの依存先にまとめてしまうこともある。答えが実際にどこから来て、何がその到着を妨げるかを理解すれば、無関係に見える停止を捉えやすくなり、システム設計を判断する手掛かりも増える。
知っておきたい用語
| 番号 | 用語 | 意味 |
|---|---|---|
| 1 | インターネットサービスプロバイダー（ISP） | より広いインターネットへの接続を提供する事業者。 |
| 2 | インターネットプロトコル（IP） | ネットワークをまたいで情報を宛先へ運ぶためのアドレス体系。 |
| 3 | コンテンツ配信ネットワーク（CDN） | 元の情報源へ毎回接続せず、異なる場所から適切なコンテンツのコピーを提供できる。 |
| 4 | 単一障害点（SPoF） | ある操作に不可欠で、有効な代わりがない構成要素。停止するとその操作も止まる。 |
| 5 | ドメインネームシステム（DNS） | example.com のような名前に対応するアドレスを探す仕組み。通信経路は決めない。 |
参考資料
- Google Cloud Service Health（2026年10月22日）。10月20日の europe-west2 リージョン障害に関する暫定報告。 ↗
- Reuters（2026年10月21日）。「Europe's financial regulators query Google over cloud outage that hit banks」。 ↗
- Synergy Research Group（2026年7月30日）。「Q2 Cloud Market Passes $143 Billion; Highest Growth Rate in Eight Years」。2026年第2四半期の世界のクラウドインフラサービス売上高シェアは Amazon 28％、Microsoft 20％、Google 15％。 ↗
- W3Techs（2026年10月22日閲覧）。「Usage statistics and market shares of reverse proxy services for websites」。Cloudflare、Amazon CloudFront、Fastly、Akamai などのサービスが観測対象のウェブサイトで使われる割合を測ったもので、CDN の売上高シェアや通信量のシェアではない。 ↗