Opinion

WIRED誌が報じた「AIデータセンター投資が生む、米国経済の新たなひずみ」という記事は、現代のゴールドラッシュとも言えるAIブームの影の部分に光を当てています。しかし、この問題を真に理解するためには、映画『マネー・ショート』で知られる投資家マイケル・バーリー氏の警告を読み解く必要があります。 バーリー氏の主張が正しければ、ハイパースケーラー各社は、将来的に巨額のネガティブ要因を財務諸表内に抱え込んでいることになります。これは、会計上の処理が 「技術的な現実」 と乖離した結果生じる、避けられない 「時限爆弾」 とも言えるものです。 💣 会計上の「時限爆弾」：減損損失のメカニズム なぜ、巨額の投資が将来の損失に変わりうるのでしょうか。その鍵は 「減価償却」 と 「技術の陳腐化」 のズレにあります。 現在、多くのハイパースケーラーは、AIの学習や推論に使われるGPUサーバーの耐用年数を 「6年」 として設定し、その期間で費用を分割計上（減価償却）しています。しかし、AIチップの性能は2年未満で倍増するのが現実です。 このギャップが、将来の 「減損損失」 という形で爆発するリスクを内包しています。 graph TD subgraph 会計上の世界 A[GPUサーバーを120億円で取得] --> B{耐用年数を6年に設定}; B --> C[毎年20億円ずつ費用計上]; C --> D[3年後の帳簿価額: 60億円]; end subgraph 技術的な現実 E[2年後に次世代GPUが登場] --> F[旧世代GPUの性能が相対的に低下]; F --> G[市場価値と収益性が急落]; G --> H[3年後の経済的価値: 10億円]; end subgraph 減損損失の発生 D & H --> I{帳簿価額 > 経済的価値}; I --> J[差額の50億円を「特別損失」として一括計上]; end style A fill:#f9f,stroke:#333,stroke-width:2px style J fill:#ff9999,stroke:#333,stroke-width:4px GPU資産は巨額であるため、この減損損失は単なる費用ではなく、 巨額の「特別損失」 として損益計算書に計上されます。その結果、その期の利益（EPS）は大きく押し下げられ、株価に深刻な影響を与える可能性があります。 バーリー氏の主張は、この 「会計上の先送り」 が、AIブームのピークが過ぎ去った後、業界全体で一斉に発現するというシステミックなリスクを指摘しているのです。 ...

2025年10月30日、「世界初！暗号領域の情報が読み取れるSuicaビューア公開」という衝撃的な発表がX（旧Twitter）で大きな注目を集めました。しかし、このニュースに触れた多くのセキュリティ専門家は、その内容以前に、発表を行った企業の姿勢に強い懸念を抱いたのではないでしょうか。 問題となっているのは、アンノウン・テクノロジーズ株式会社です。同社は過去にもFeliCaの脆弱性を発見し、7月に関係機関へ報告したものの、修正が完了する前の8月に共同通信の取材に応じて未公開の脆弱性情報を公表し、物議を醸しました。これを受けて9月には経済産業省が、情報処理推進機構（IPA）と連携し、脆弱性情報の取り扱いに関する注意喚起を改めて行う事態にまで発展しています。 脆弱性を発見された方は、受付機関であるIPAへの届出を行っていただき、正当な理由がない限り脆弱性関連情報を第三者に開示せず、正当な理由により開示が必要である場合も事前にIPAに相談いただくようお願いいたします。 今回の発表は、こうした経緯を無視するどころか、さらに問題を深刻化させるものです。本稿では、なぜこの企業の行動が「ブラックハット的」と批判されるのか、その論点を整理し、セキュリティ企業に求められるべき倫理とは何かを考察します。 論点1: 無視された「責任ある開示」の原則 セキュリティの世界には、**「責任ある開示（Coordinated Vulnerability Disclosure, CVD）」**という、発見した脆弱性を扱うための世界共通の倫理規範が存在します。これは、脆弱性の発見者、製品開発者（ベンダー）、そして調整機関（日本ではIPA）が連携し、修正パッチが一般に提供されるタイミングで情報を公開するという、社会全体の安全性を最大化するための協調的なプロセスです。 アンノウン・テクノロジーズ社の行動は、この大原則を完全に踏みにじるものです。修正前に情報を公開することは、悪意ある第三者に攻撃のヒントを与えることに他ならず、ユーザーを無用な危険に晒す行為です。経済産業省が指摘する「正当な理由」とは、既に大規模な攻撃が発生しており、注意喚起が急務であるといった「今そこにある危機」に限定されるべきです。それ以外の理由でExploit（攻撃コード）に類する情報を公開することは、無責任の誹りを免れません。 実際、CEOがビューアに書き込み機能を付けていない、理由として「絶対残高を書き換える奴が出るので禁止してある」としていますが、経験上、読み込み系の機能があれば、ある程度、そこから、書き込みの機能を類推するのは可能です。つまり、コードの悪用可能性は十分認識しているはずです。そのような、状態で責任を負えるでしょうか？ ステップ 善意の技術者（正規のCVDプロトコル） アンノウン・テクノロジーズの行動（逸脱パターン） ① 発見・報告 脆弱性関連情報を発見後、まず中立機関であるIPAに届出し、情報を秘匿する。 脆弱性関連情報を発見後、IPAに届け出た後、あるいは前に情報を保持する。 ② 調整・通知 IPAはJPCERT/CCに通知。JPCERT/CCは秘密裏に製品開発者（ベンダー）を特定し、対策を依頼する。 このプロセスを尊重せず、秘密裏に行われている調整の途中で動く。 ③ 修正期間 製品開発者が対策パッチを作成する間、発見者は情報を第三者に漏らさない（非開示義務）。 この修正期間中に、一般メディア（共同通信）やSNS（X）へ情報を開示・宣言する。 ④ 公表 修正パッチが利用可能になったことを確認した上で、発見者・調整機関・ベンダーが同時に情報を公表する。 修正が完了する前に情報を公表し、社会的な混乱とベンダーの緊急対応を誘発する。 ⑤ 目的 社会全体のリスクを最小化し、ユーザーの安全を最優先する。 技術的なアテンション（注目）とビジネス上の宣伝効果を最優先する（と見なされる）。 論点2: 社会インフラを揺るがす無責任な行為 FeliCaは単なるICカード技術ではありません。日本の交通や決済を支える 極めて重要な社会インフラ の一部です。その根幹技術の信頼性を一方的に毀損する行為は、技術的な興味やビジネス上の利益をはるかに超えた、重大な社会的責任を伴います。 今回の件で、ソニーや関連事業者は、本来不要であったはずの緊急対応や調査に多大なリソースを割かざるを得なくなりました。こうしたコストは、巡り巡ってサービス利用料や製品価格に転嫁され、最終的には社会全体が負担することになります。技術的な脆弱性以上に、セキュリティコミュニティの信頼関係を破壊し、社会に無用な混乱とコストをもたらした「迷惑」は計り知れません。 論点3: 信頼を損なうFUDマーケティング 「世界初！」「衝撃的な発表」といった扇情的な言葉は、冷静かつ客観的であるべきセキュリティの報告には不要なものです。むしろ、こうした表現は、顧客の不安や恐怖を煽り、自社のサービスを売り込む FUD（Fear, Uncertainty, and Doubt）マーケティング の典型的な手法と見られても仕方ありません。CEOがXで「世界初！」と宣言した行為そのものがどう見てもアテンション中毒です。 真に顧客の安全を考えるプロフェッショナルは、いたずらに恐怖を煽るのではなく、静かにリスクを分析し、着実な対策を提示することで信頼を得ます。すべての行動が 「アテンション（注目）を獲得し、それをセールスに繋げる」 という短絡的な目的に集約されているように見える姿勢は、長期的な信頼関係を基礎とするセキュリティビジネスの倫理観とは相容れないものです。 論点4: 信頼性の根幹を揺るがす経営実態 さらに、同社の信頼性に疑問符を付けるのが、その経営実態です。 衝撃の事実①：資本金1万円 サイバーセキュリティは、顧客の事業継続に直結する極めて重要な領域です。その責任を担う企業が、事業継続性や万が一の際の補償能力を全く感じさせない資本金額であることは、事業へのコミットメントを疑わざるを得ません。 衝撃の事実②：バーチャルオフィス 登記上の住所である「東京都千代田区九段南」は、調査の結果、**コワーキングスペースの住所貸し（バーチャルオフィス）**であることが確認されています。物理的な拠点の有無が問題なのではありません。高度な機密情報を扱うセキュリティ企業が、その実態を曖昧にしかねないサービスを利用しているという事実が、顧客の信頼を損なうのです。 これらは、高度な専門企業を装う 「見栄（外見）」と「実態（資金力と責任感）」 の深刻な乖離を示しており、組織としての信頼性を根底から揺るがすものです。 結論: 我々は何を基準に専門家を選ぶべきか アンノウン・テクノロジーズ社の一連の行動は、IT業界に身を置く者として、レッドラインを越えています。これは、技術力さえあれば何をしても許されるという、危険な前例になりかねません。 企業や個人がセキュリティの専門家やパートナーを選ぶ際には、その技術力だけでなく、高い倫理観、社会に対する責任感、そしてそれを裏付ける安定した経営基盤 を持っているかどうかを、これまで以上に厳しく見極める必要があります。今回の事例は、その重要性を改めて我々に突きつける、重い教訓と言えるでしょう。

はじめに 2025/10/20のAWSの大規模障害から、2日目の朝が過ぎ、色々と見えてきました。ITmediaの記事によれば、原因や経緯は以下のように説明されています。 AWSによれば、今回の障害は「リージョンのDynamoDBサービス（注：AWSのデータベースサービス）エンドポイントのDNS解決の問題」が原因だったという。同社は20日午後6時ごろに問題を解決したものの、今度はDynamoDBに依存するEC2インスタンスの起動システムに問題が発生。対応するうちにトラフィックを分散する「Network Load Balancer」にも問題が生じ、再びDynamoDBなど複数サービスに影響したため、EC2インスタンスの起動など一部サービスの操作を一時的に抑制して復旧に当たったとしている。 DNSのSPoF化 とはいえ、この事実はかなりな、ナンセンスさを内包しています。本来、DNSは冗長な権威サーバー群によって提供され、キャッシュも活用されるため、単一のサーバーやソフトウェアがダウンしてもシステム全体は生き残るように設計されています。しかし、AWSの報告は、DynamoDBというクリティカルな内部サービスのDNS解決が、特定の脆弱なコンポーネントに集中し、それが停止することで、誰も住所を見つけられない状態、すなわち　「内部の単一障害点（SPOF）」　になっていたことを示しています。 認証基盤への影響の軽視 DynamoDBの停止は、IAMなど認証基盤の裏側にも影響しました。この認証基盤がDNSに依存していた、あるいはDNSが停止した時のフェイルオーバー（切り替え）の仕組みが不十分だったこともナンセンスです。 AWSは、 「誰がアクセスしているか」 という最も重要な制御システムを、DNSという単一障害のリスクから十分に隔離できていなかったことになります。 復旧時の二次災害（NLBの問題） さらにナンセンスなのは、DNS問題を解決した後、今度はNLB（Network Load Balancer）の設計が、回復したDynamoDBへのリトライ・ストームに耐えきれず、再びサービスに影響を与えた点です。 これは、AWSのエンジニアが 「自社のトラフィック分散機構が、自社のサービスから発生する負荷（リトライ）で崩壊する」 という最悪のシナリオを十分に想定できていなかったことを示唆しています。 秘伝のたれ：文書化されない知識の蔓延 今回のAWS大規模障害、特に 「内部DNSの設計ミス」と「DynamoDBとNLBの連鎖崩壊」という「話にならなすぎる」原因は、巨大なクラウドインフラ内部に「文書化されていない秘伝のたれ（Undocumented Tribal Knowledge）」 が横行していることの、動かぬ証拠です。「秘伝のたれ」とは、特定のエンジニアやチームだけが知っている、システムの機能に不可欠だが公式には文書化されていない知識、調整、あるいは非標準的な設定を指します。 実際に、The Registerの記事に目を覆いたくなるような記述があります。 “It’s always DNS” is a long-standing sysadmin saw, and with good reason: a disproportionate number of outages are at their heart DNS issues. And so today, as AWS is still repairing its downed cloud as this article goes to press, it becomes clear that the culprit is once again DNS. But if you or I know this, AWS certainly does. ...

2025年10月、Googleはついに、長年推進してきた「プライバシーサンドボックス（Privacy Sandbox）」に関連する技術の大部分を廃止し、今後はそのブランド名も使用しないことを発表しました。これは、プライバシー保護と広告ビジネスの両立を目指した壮大な実験の事実上の終焉を意味します。そして、ウェブの世界に長年君臨してきたサードパーティクッキー（3rd Party Cookie）の廃止計画も、これにより白紙に戻されることになりました。 なぜサードパーティクッキーは問題だったのか サードパーティクッキーがなぜプライバシー上の問題とされてきたか、その仕組みはサイトを横断したユーザー追跡を可能にする点にあります。ユーザーがあるサイトを訪れた際に、そのサイトに埋め込まれた第三者（広告配信サーバーなど）が発行するクッキーがブラウザに保存されます。そして、ユーザーが別のサイトを訪問した際にも、同じ第三者のコンテンツが埋め込まれていれば、以前保存されたクッキーが読み取られ、結果として「同じユーザーが複数のサイトを閲覧している」ことが特定できてしまいます。 graph TD subgraph "ユーザーのブラウザ" A[Browser] end subgraph "ウェブサイトA" B(primary-site.com) D{埋め込み広告} end subgraph "ウェブサイトB" G(another-site.com) H{埋め込み広告} end subgraph "第三者（広告サーバー）" E[ad-tracker.com] I[Cookieを照合] end A -- "1. primary-site.comにアクセス" --> B B -- "2. 広告をリクエスト" --> D D -- "3. ad-tracker.comにリクエスト" --> E E -- "4. 追跡用Cookieを発行" --> A A -- "5. another-site.comにアクセス" --> G G -- "6. 広告をリクエスト" --> H H -- "7. 保存済みのCookieを送信" --> I I -- "8. 同一ユーザーと特定" --> J((サイト横断追跡が成立)) style J fill:#fcc,stroke:#333 AppleのSafari (ITP) やMozillaのFirefox (ETP) は、かなり早い段階からこのような追跡を防ぐための機能強化を進めてきました。しかし、ブラウザ市場で圧倒的なシェアを持つGoogle Chromeの動向が、業界全体の趨勢を決める最大の要因として注目され続けていたのです。 ...

クラウドサービス、特にAmazon Web Services (AWS) は、現代のデジタル社会に不可欠な基盤です。しかし、その巨大で複雑なシステムは、時として私たちの想像を超える形で障害を発生させ、ビジネスや社会活動に深刻な影響を及ぼします。 2025年10月20日、AWSは再び大規模な障害に見舞われ、多くのサービスが長時間にわたり停止しました。 この出来事は、クラウドへの依存が深化する現代社会において、そのリスクといかに向き合うべきかという課題を改めて浮き彫りにしました。 本記事では、この直近の障害も念頭に置きつつ、特にインパクトが大きかった過去のAWS東京リージョンでの障害を振り返り、そこから得られる教訓を深く掘り下げます。単なるインシデント報告の要約ではなく、これらの経験がクラウド時代のシステム設計やリスク管理に何を問いかけているのかを考察します。 2019年8月 AWS東京リージョン大規模障害：冷却バグがMulti-AZを破った日 2019年8月23日、AWS東京リージョン（ap-northeast-1）で発生した大規模障害は、多くの開発者やインフラ技術者にとって「Multi-AZ構成は万能ではない」という厳しい現実を突きつけました。 発生事象と原因 2019年8月23日午後、東京リージョンの一つのアベイラビリティゾーン（AZ）で、多数のEC2サーバーとそれに付随するEBSボリュームが利用不能に陥りました。 AWSの公式発表によると、原因はデータセンターの冷却制御システムにあったバグでした。このバグにより冷却機能が低下し、サーバー群がオーバーヒート（過熱）を防ぐために自動的にシャットダウンしたのです。これは単一AZ内で発生した物理的な設備の問題でした。 影響：デジタルからフィジカルへ この障害は、ソーシャルゲームから企業の基幹システムまで、幅広いサービスに影響を与えました。特に注目すべきは、その影響がデジタル空間に留まらなかった点です。 物理世界への衝撃：ドコモ・バイクシェアの事例 象徴的だったのが、ドコモ・バイクシェアのサービス停止です。AWS上で稼働していた認証・管理システムが停止した結果、以下の連鎖反応が起きました。 認証・制御システムの停止: 自転車の貸し出しや返却を管理するシステムが機能不全に。 物理的な行動の阻害: ユーザーがアプリで解錠操作をしても、システムからの「解錠コマンド」が自転車のスマートロックに届かない。 社会インフラの麻痺: 結果として、多くのユーザーが自転車を借りることも、利用中の自転車を返却することもできなくなり、移動手段が絶たれるという物理的な影響が発生しました。 この事例は、クラウドがスマートロック、IoTデバイス、モビリティといった物理世界と連携するサービスにおいて、いかに重要な生命線となっているかを痛感させるものでした。 教訓：Multi-AZ神話の崩壊 この障害から得られる最大の教訓は、Multi-AZ構成への過信は禁物であるという点です。なぜ単一AZの障害が、AZをまたいで冗長化していたはずの多くのシステムに影響を与えたのでしょうか。 制御プレーンへの依存: EC2インスタンスの起動や停止、EBSの着脱などを管理する「制御プレーン」の一部は、複数のAZにまたがって共通で稼働しているコンポーネントが存在します。障害が発生したAZの制御機能に問題が波及し、正常なAZの操作にも影響が出た可能性が指摘されています。 不完全な冗長化設計: アプリケーションが、意識しないうちに特定のAZのリソース（例：特定のEBSボリュームやNATゲートウェイ）に依存しているケースがありました。障害が発生したAZのリソースを掴んだまま離さなかったり、フェイルオーバーの仕組みが正しく機能しなかったりした結果、サービス全体が停止しました。 この障害は、インフラ層の冗長化だけでなく、**アプリケーション自身が障害を検知し、自律的に回復する能力（フォールトトレランス）**がいかに重要であるかを浮き彫りにしました。 2021年9月 AWS Direct Connect障害：ネットワークの要が引き起こした連鎖的停止 2021年9月2日の早朝に発生した障害は、企業のオンプレミス環境とAWSを繋ぐ専用線サービス「AWS Direct Connect」が震源地となりました。 発生事象と影響 この障害により、Direct Connectを利用していた多くの企業で、オンプレミス環境とAWS間の通信が不能になりました。 金融機関への打撃: 三菱UFJ銀行やみずほ銀行などで、インターネットバンキングやスマートフォンアプリ、一部ATMが利用できなくなるなど、深刻な影響が出ました。 社会インフラの麻痺: 航空会社の国内線チェックインシステムや、企業の基幹業務（貨物追跡、受発注システムなど）が停止し、経済活動に広範囲な影響を及ぼしました。 教訓：オンプレミスとの接続点のリスク Direct Connectは、安定した広帯域の通信を実現する一方で、障害発生時には**単一障害点（Single Point of Failure）**になり得るというリスクを露呈しました。 この障害からの教訓は、クラウドと外部環境を接続するネットワーク経路の重要性です。対策としては、複数のDirect Connect接続による冗長化や、バックアップとしてのVPN接続を準備しておくことが不可欠となります。 まとめ：過去の障害から学ぶ、これからのクラウド戦略 AWSの過去の障害は、私たちに多くの重要な教訓を与えてくれます。 障害は「起こるもの」と心得る: 100%の可用性を保証するクラウドは存在しません。障害発生を前提としたシステム設計、運用体制、そして組織文化を構築することが最も重要です。 設計原則の再点検: Multi-AZ/Multi-Region: 本当にアプリケーションレベルでAZ障害を乗り越えられる設計になっているか？ フォールトトレランス: サーキットブレーカー、適切なリトライ、フォールバック処理など、アプリケーション自身が回復する仕組みは十分か？ 依存関係の最小化: 特定のコンポーネントやサービスへの依存が、予期せぬボトルネックになっていないか？ 来るべき日に備える: 障害は必ずまた起こります。その日に備え、障害の迅速な検知、原因の切り分け、そして顧客や関係者への透明性のあるコミュニケーション計画を準備しておくことが、信頼を繋ぎ止める鍵となります。 クラウドの恩恵を最大限に享受するためには、そのリスクを正しく理解し、過去の失敗から学び、より堅牢で回復力のあるシステムを構築し続ける努力が不可欠です。