クラウドコンピューティング on AIによる技術記事備忘録

東京が消し飛んでもシステムを復旧させるのか？──現場を凍りつかせる「BCPチェックシート」という名の茶番

Thu, 17 Sep 2026 23:32:10 +0900

イランによるAmazonのデータセンターへの攻撃により顧客データが永久に失われる - GIGAZINE

中東にあるクラウド事業者のデータセンターが物理的な軍事攻撃を受け、単一アベイラビリティーゾーンに配置されていたデータが恒久的に失われたという報せは、インフラエンジニアや企業のリスク管理部門に冷水を浴びせました。どれほど論理的に抽象化されていようと、クラウドの実体は特定の緯度と経度に固定されたコンクリートとシリコンの塊であり、不可逆な物理破壊の前には無力であるという冷厳な事実です。

しかし、このニュースに触れたとき、私たちが真に直面させられるのは技術的アーキテクチャの敗北だけではありません。日本の多くの大企業で機械的に配られ、現場のエンジニアが半ば虚無感とともに記入させられている「事業継続計画（BCP）チェックシート」の欺瞞こそが、白日の下に晒されたと言えます。

「基幹インフラだけが無傷」というSF的ご都合主義

教科書的なBCPやクラウドの設計論では、東京リージョン（ap-northeast-1）が被災した際の解として「米国バージニア州（us-east-1）などへのマルチリージョン・フェイルオーバー」が平然と語られます。アーキテクチャ図の上では、太平洋を跨ぐ矢印を一本引くだけで対策が完了したかのように見えます。

しかし、現実の物理世界を少しでも想像すれば、この前提がギャグの領域にあることは明白です。東京が物理的に瓦解するほどの軍事攻撃や巨大災害が発生したとき、なぜ房総半島や茨城沿岸にある海底ケーブル陸揚局（CLS）や、都心のインターネットエクスチェンジ（IX）、超高圧変電所だけが奇跡的に無傷で稼働し続けているのでしょうか。

大動脈である太平洋横断ケーブル網や中継施設への給電が落ちれば、海外リージョンへのデータハイウェイそのものが瞬時に遮断されます。配管が根元から爆破されているのに、蛇口の先の水質を議論しているようなものです。海外拠点でデータが無事であろうと、それを国内の誰も参照できず、操作もできない状態であれば、そのシステムは宇宙空間を漂う無人の人工衛星と何ら変わりません。

「この状況で仕事するわけないだろ」という正常な直感

さらに奇怪なのは、そうした極限状態においても「生身の担当者が平然と職務を遂行する」という前提がチェックシートの裏に忍ばされている点です。

東京が壊滅的な打撃を受け、明日また第2波の攻撃や激しい余震が来るかもしれないという状況下で、人間が真っ先に取るべき行動は一つしかありません。家族の安全を確保し、水と食料を抱えて、生存のために一刻も早く東京から脱出することです。

電気も水道も止まり、通信も途絶えた混乱の都市において、脱出の判断を数時間誤ることはそのまま死に直結します。そんな極限状態に置かれた生身の人間に対して、「担当サービスを他リージョンへ切り替えて持続性を担保できるか」と問うこと自体、破綻した状況認識と言うほかありません。

チェックシートを埋めながら多くのエンジニアが抱く「この状況で仕事するわけないだろ」という吐き捨てるような直感は、職責の放棄などではなく、生命を維持しようとする生物として最も健全で正確な現実認識です。

組織防衛のためのアリバイ工作と責任の所在

では、なぜこのような絵空事のチェックシートが、大企業では全サービスの担当者に向けて一律に強制されるのでしょうか。理由は極めてシンプルで、それが現場の危機管理のためではなく「組織のアリバイ作り」として運用されているからです。

経営陣やリスク管理部門の目的は、実際に国家機能が麻痺したときにサービスを復旧させることではありません。株主総会、監査法人、取引先に対して「当社は全社的にリスクを評価し、統制を図っています」と報告するためのエビデンス、すなわち「記入済みシートの束」を揃えることが自己目的化しています。

そしてこの構造の最も残酷な点は、想定外の破滅が起きた際の泥を現場に被せられる余地を残していることです。「事前に貴方がこの時間で復旧できると書きましたよね」という手続きを踏ませることで、管理側は免責され、破綻の責任は「現場の見通しの甘さ」へと矮小化されます。

欺瞞を捨て、本当の「生存」から逆算する

平時のビジネスやSaaSが提供する価値は、社会インフラと法秩序という巨大な土台が正常に維持されていて初めて成立する二次的な産物に過ぎません。

組織の体裁を保つための書類仕事に大人の対応として付き合うことは、サラリーマンとしての処世術かもしれません。しかし、心の奥底にある「世界が終わっているときに、会社のシステムを心配している場合ではない」という冷徹な感覚だけは手放してはなりません。

物理インフラが国家間の武力衝突や未曾有の大災害に巻き込まれたとき、真に問われるのはSaaSの可用性ではなく、私たち自身がいかに今日を生き延びるかという、剥き出しのサバイバルなのです。

サーバレスの夢の残骸

Sat, 12 Sep 2026 14:05:03 +0900

「AWS文学」と一次資料至上主義の病理

かつて多くのエンジニアが、AWSの膨大な公式ドキュメントをお経のように熱心に読み解き、そこに書かれた仕様を忠実に実装することを美徳としていた時代がありました。難解で重層的な修飾節が連なり、例外規定と免責条項が張り巡らされたその独特な文体は、いつしか「AWS文学」と揶揄されるようになりました。この読みづらさは偶然の産物ではなく、コンウェイの法則に従って細分化された組織構造、サービスごとに異なる文脈、そして障害発生時の免責を徹底しようとする法律文書に近い執筆スタイルが重なり合った必然の結果です。

本来、技術者が真に求めているのは「目の前のシステムをどう安全に動かすか」という具体的な設計判断や勘所です。しかし、プラットフォーマーが公式文書として提示するのは「仕様の完全な網羅と免責」にすぎません。それにもかかわらず、業界には「一次資料こそが絶対の正義である」という盲目的な信仰が定着しました。一次資料が保証するのはあくまで現行実装に対する法的な正確さであり、読者が目的を達成するための実用性とは本質的に無関係です。難解なドキュメントと格闘したサンクコストを正当化し、二次情報を軽視して門番のように振る舞う文化は、エンジニアリングを手段から知的なマウンティングの道具へと変質させていきました。

現場を経験したエンジニアであれば誰しも、「ドキュメント上で保証されている仕様」と「本番環境の物理レイヤーで現実に起きる挙動」の間に横たわる深い溝を知っています。結果整合性の遅延、隠れたクォータ制限、ネットワーク断に伴う見かけ上のエラーなど、仕様書の外側にこそ現実の泥沼があります。何を読み、何を読まないかという情報選定の段階からエンジニアの責任は始まっています。公式の言説を無批判に崇める姿勢は、巨大プラットフォーマーのブランド力に自らの野生と批評精神を明け渡した結果にほかなりませんでした。

クラウドへの屈服とアーキテクチャの複雑性の爆発

なぜあの時代、これほど多くのエンジニアや組織が思考停止に陥り、プラットフォームに従属していったのでしょうか。その背景には、抗いがたい時代の構造的圧力が存在していました。かつてのオンプレミス環境における深夜のデータセンター作業、突然死するハードウェア、調達に数ヶ月を要する見積もりといった運用地獄からの解放は、あまりにも強烈なカタルシスをもたらしました。その恩恵の大きさゆえに、多少の歪みや理不尽には目を瞑るという暗黙の取引が成立してしまったのです。

さらに、資産を持たない身軽さを求める経営層からの強力なトップダウンや、急速に膨張する業界で未経験者を即戦力化するための「認定資格」を中心とした教育の標準化が、この流れを加速させました。その結果、エンジニアリングの本質である泥臭い問題解決能力よりも、プラットフォーム固有のお作法をどれだけ記憶しているかが重宝される歪んだ土壌が完成しました。

こうして熱狂の中で迎えられたクラウドでしたが、システムの進化は新たな袋小路へと突き当たります。S3、DynamoDB、Lambda、SQSといったサービス群は、インフラの存在を忘れさせる圧倒的な未来を確かに予感させました。しかし、それらを組み合わせて巨大な業務システムを構築しようとした瞬間、アーキテクチャの複雑性の爆発という過酷な代償を支払うことになりました。

かつてモノリスの内部でメモリ上の関数呼び出しとして完結していた処理が、細切れのマイクロサービスやイベント駆動へと分解された結果、単なるデータの受け渡しがすべてネットワーク越しの分散トランザクションへと化しました。重複配信への対策、メッセージの順序制御、デッドレターキューの監視、そして数千行に及ぶ設定ファイル（IaC）の保守など、コードの行数を減らした代わりにインフラの接続点と失敗パターンが指数関数的に増大していったのです。

コンテナオーケストレーションという名の欺瞞

分散システムの複雑性に疲弊した業界が次に逃げ込んだのが、ECSやKubernetesをはじめとするコンテナオーケストレーションでした。しかし、それは解決策どころか、さらなる高額な固定費と運用の怪物を飼い慣らす選択にすぎませんでした。

コンテナオーケストレーションは、本質的にIaaS（仮想インフラ）のレイヤーにとどまるリソース占有型のモデルです。どれだけ軽量なコンテナを動かそうと、背後には24時間365日稼働し続ける仮想マシンやプロビジョニングされたリソースが存在します。そこにコントロールプレーンの維持費、高額なデータ転送料、監視エージェントのオーバーヘッド、そして安全マージンとして死蔵される大量の空きリソースが積み重なります。結果として、何も処理していなくても毎月莫大なプラットフォーム税が徴収される構造から抜け出せなくなりました。

現代の物理ハードウェアは目覚ましい進化を遂げています。コンテナ基盤に投じられる年間数百万円から数千万円規模のコストがあれば、最新のワークステーションやサーバー、堅牢なネットワーク機器を一式揃え、さらには物理的なオフィススペースの賃料を払ってもお釣りが来るという計算は、決して荒唐無稽な暴論ではありません。「可用性とスケーラビリティ」という美名のもとに仮想化レイヤーの上で自作PCごっこを繰り返す経済的な不条理に、多くの現場が直面しています。

果たせぬ夢だったサーバレスと、物理バイナリへの誇り

いま振り返るべきは、私たちがかつて信じた真のサーバレスアーキテクチャの思想とは何であったかという問いです。だからこそ、コンテナを裏で自動起動するだけの仕組みを「サーバレス」と呼ぶ昨今の風潮には、強い違和感を覚えざるを得ません。それは、かつての美しい思想に対するマーケティング的な簒奪でした。

本来のサーバレスが提示した革命とは、以下のような計算モデルの根本的な転換でした。

常駐（Daemon）からの解放リクエストを待ち受けるためにリソースを占有し続ける旧来のあり方を否定し、事象（Event）が発生したその刹那だけ実体化し、計算を終えたら跡形もなく虚空へ消え去るという儚くも無駄のないモデル。
因果関係の記述への純化ハードウェアのキャパシティに頭を悩ませるのではなく、世界で起きる変化に対して純粋関数をマッピングしていくという、プログラミングの原初的な快感への回帰。
ゼロの誠実さ動いていない時間には1円のコストも発生させないという、真の従量課金がもたらす透明で合理的な経済性。

DynamoDBやLambdaは、強烈なベンダーロックインと引き換えにこの思想を極限まで具現化した稀有な道具であり、その純粋な割り切りとコストパフォーマンスにおいて、今なお独自の輝きを放っています。しかし、その純粋な思想は、業界全体の複雑化と巨大なプラットフォームビジネスの波に呑み込まれ、果たせぬ夢として終わりました。

クラウドコンピューティング on AIによる技術記事 備忘録