QIRIN ランサムウェア、サプライチェーン、そして経営の再定義

日本を代表する飲料メーカーであるアサヒグループホールディングス（以下、アサヒGHD）が、ランサムウェアによる大規模なサイバー攻撃を受けた。国内の業務システムが麻痺し、製造・出荷・顧客対応などの中核業務が停止。影響は同社の枠を超え、流通業界、競合他社、さらには年末商戦にまで波及した。

この事件は、単なるITトラブルではない。デジタル化が進む中で、企業の根幹を揺るがす「経営リスク」としてのサイバー攻撃の現実を突きつけた象徴的な事例である。

アサヒGHDが攻撃を受けたのは9月29日午前7時。システム障害を確認した同社は即座に調査を開始し、同日中に捜査当局へ報告。国内グループ各社の受注・出荷業務、コールセンター業務が停止し、主要工場の稼働も一時停止された。

翌30日には配送遅延が発生し、株価も下落。10月1日には新製品12品の発売延期が発表され、2日にはセブンイレブンやファミリーマートのPB飲料出荷が一部停止。飲食店では他社銘柄への切り替えが進み、キリンやサントリーなど競合他社にも代替発注が殺到。結果として、これらの企業も出荷制限を余儀なくされるなど、業界全体に波及する影響が生じた。

攻撃を仕掛けたのはロシア系とされるハッカー集団「QIRIN（キーリン）」。ダークウエーブ上で犯行声明を公表、アサヒGHDの財務情報や事業計画書、従業員の個人情報など少なくとも、ファイル数約9300件、総容量27GBのデータが盗まれたと主張している。

トレンドマイクロのシニアスペシャリスト、成田直翔（なりた・なおと）氏は次のように語る。

「キーリンは2025年に最も活発なランサムウェアグループとされ、年間800件以上の被害組織を攻撃者が運営する『リークサイト』と呼ばれるウェブサイトに掲載しています。RaaS（Ransomware-as-a-Service）モデルを採用し、開発者（オペレーター）と実行犯（アフィリエイト）を分業化し、端末の言語設定がロシア語だと作動しない設計で、ロシア国内での摘発を回避しています」

RaaSとは、ランサムウェア攻撃を“サービス化”したサイバー犯罪のビジネスモデル。技術力のない攻撃者でも、開発済みのツールを使って容易に攻撃を仕掛けられる。その基本構造は、開発者がランサムウェア本体や攻撃用インフラを構築し、実行犯がそのツールを使って攻撃を実行、身代金が支払われると、開発者とアフィリエイトで報酬を分け合うという仕組みだ。

日本ではこれまでにも宇都宮セントラルクリニック（最大30万人分の医療情報）、日産子会社（Creative Box、4TBの3Dデザイン・社内文書）、丸菱HD（外国人労働者の在留カード含む353GB）、原田工業（約942GBの設計図・契約書・社員情報）などが狙われた。

Qilin型ランサムウェアの侵入経路と攻撃ライフサイクル

キーリンはアサヒGHDにどのように侵入したのだろうか。

侵入の経路についてアサヒGHDは、まだ正式に公表してはない。ただ一般的にランサムウェアは、RDP（Remote Desktop Protocol、遠隔操作）やVPN（Virtual Private Network、仮想プライベートネットワーク）の脆弱性、フィッシングによる認証情報の窃取、アクセスブローカー（企業への侵入口を売っているサイバー犯罪者）からの初期アクセス購入などが用いられる。

侵入後は組織内のユーザーや端末をまとめて管理するAD（Active Directory）を乗っ取り、ネットワーク全体に横展開。暗号化前にデータを窃取し、「復号（暗号化された情報を、元の状態に戻す処理）のための身代金＋情報公開による脅し」の二重恐喝を行う。

「例えば、ある社員のパソコンが最初の侵入口となり、そこから攻撃者は社内ネットワークに入り込みます。侵入後は、ネットワーク内を探索しながら、管理者権限を持つアカウント、特に『アクティブディレクトリ』と呼ばれるシステムの中枢にアクセスできるアカウントを狙っていきます。そして、もしその管理者権限を手に入れることができれば、攻撃者はその権限を使って、社内のパソコンやサーバー、システム全体に一気にアクセスできるようになります。そこから一斉に、これらの端末やシステムを暗号化してしまうのです。ただし、暗号化の前に、攻撃者は重要なデータをこっそり外部に持ち出しておきます。そして暗号化が完了した後、『あなたたちのデータはすでに盗んである。もし私たちの要求に応じなければ、その情報を公開する』といった脅迫を行います。つまり、単にデータを使えなくするだけでなく、『盗んだ情報を暴露するぞ』と二重に脅してくるのが最近の手口です」（成田氏）

ハッカーは暗号化したデータを元に戻す（復号する）ことが技術的には可能だ。ただし、それには「復号鍵」が必要であり、通常は身代金が要求されることになる。では身代金を支払えば、ハッカーはデータを復号してくれるのだろうか。

「もし身代金を支払わなかった場合、リークサイトに盗まれた情報がそのまま公開されてしまいます。逆に、指定された期限内に支払えば、その情報は公開されず、暗号化されたシステムも復旧されると攻撃者は主張しています。ただし、実際には『支払ったのに、金額が足りないからもっと払え』と追加の要求をしてきたり、支払ったにもかかわらず暗号化を解除してくれなかったり、あるいは情報が結局リークされてしまったり、といったケースも少なくありません。結局のところ、相手は犯罪者なので、交渉自体が信用できるものではなく、非常にリスクが高いというのが現実です」（成田氏）

単一企業の被害がサプライチェーン全体に波及

では実際にサイバー攻撃を受けると、どのような被害があるのだろうか。

アサヒGHDは異常を検知した直後に国内の全業務システムを遮断。商品受注・出荷業務の全面停止、国内30工場の生産停止、コールセンターやお客様相談窓口の閉鎖、社外メールの受信不可、新商品発表会やイベントの中止など、広範な業務停止が発生した。復旧は段階的に進行し、紙と電話による手作業で業務継続を図ったが、完全復旧には至っていない。

この業務停止は、単一企業の問題ではなく、サプライチェーン全体の脆弱性を露呈した。セブンイレブンやファミリーマートなどのPB商品が出荷停止となり、イオンでは通販ギフトの販売が一時停止。松屋フーズでは一部店舗で欠品が発生し、福岡ソフトバンクホークスの日本シリーズ優勝祝賀会では「ビールかけ」が中止され、シャンパンファイトに変更された。

「最近の企業システムは、社内だけでなく取引先とも複雑につながっています。こうした中で、ランサムウェア攻撃が起きると、たった一つのシステムが止まるだけで、連携している他のシステムまで使えなくなってしまうことがあります。たとえば、物流拠点を運営している会社が攻撃されると、その会社に業務を委託している企業も、荷物が動かせなくなったり、納品が遅れたりして、事業が止まってしまいます。こうした影響は『ドミノ倒し』のように広がっていきます。つまり、自社だけを守っていても、取引先や委託先が攻撃されれば、自社も被害を受ける可能性が高いのです」（成田氏）

中でも注意しなければならないのがサプライチェーンに連なる中小企業だという。中小企業の中には、大企業の業務を支える重要な役割を担っている会社がある。こうした中小企業がランサムウェアの被害を受けて事業が止まってしまうと、その影響は大企業にも及び、ビジネス全体が止まってしまう可能性がある。

「たとえば、小島プレス工業という企業がランサムウェアの攻撃を受けて事業が停止した際、トヨタの工場が丸一日稼働できなくなったという事例があります。トヨタ自身が攻撃されたわけではないが、サプライチェーンの一社が被害を受けただけで、大企業にも大きな影響が出てしまうのです」（成田氏）

情報漏洩による取引先への二次被害

問題は想定されているサプライチェーン内だけにとどまらない。思いもかけないようなところにもその波紋は広がる。

「最近のサプライチェーン被害は、これまで想定されていなかったような広がり方をしていると感じています。たとえば、アサヒGHDがサイバー攻撃を受けて業務が一時停止したことで、サントリーやキリンといった大手飲料メーカーも、予定していたキャンペーンを見送らざるを得なくなりました。これらの企業は本来、競合関係にありますが、共通の委託先が被害を受けたことで、競合同士が同時に影響を受けるという事態が起きたのです。このように、一社の被害が業界全体に波及する構造になってきており、もはや『自社だけ守ればよい』という時代ではありません。しかし、こうした被害は事前に予測するのが難しく、完全に備えるのは非常にハードルが高いと感じています。だからこそ、サプライチェーン全体でのリスク共有と連携した対策がますます重要になっていると思います」（成田氏）

上述のようにランサムウェアの被害を受けると、自社の業務が止まるだけでなく、取引先にも深刻な影響が及ぶ。社内システムに保存されていた取引先の情報が攻撃者に盗まれ、その情報が外部に流出する可能性も生まれてくる。

そのため、単なる情報漏洩にとどまらず、取引先の信用や業務にも直接的なダメージを与えることになるため、取引先から「自社の情報が漏れたことで損害を受けた」として、損害賠償を請求されるリスクも生じる。特に、契約書の中で情報管理の責任が明記されていた場合や、個人情報保護法などの法令に違反していると判断された場合には、法的な責任を問われる可能性が高くなる。

「ランサムウェアの被害は業務だけの問題ではなく、取引先との信頼関係や契約上の責任にも関わる重大なリスクを含んでいるのです。だからこそ、日頃から情報管理体制を整え、万が一の事態に備えておくことが重要です」（成田氏）

復旧の決め手はバックアップ

実際にサイバー攻撃に遭った場合、どのくらいの期間で復旧することができるのだろうか。復旧のスピードは、暗号化されたシステムやデータの範囲、被害の規模によって大きく左右される。

「ランサムウェアによって暗号化されたファイルは基本的に元に戻せません。そのため、バックアップから復元するか、あるいはシステムを一から作り直すしかない。早く復旧できるかどうかは、『バックアップを取っているか』、『それをどれだけ早く適用できるか』にかかっています。しかもバックアップといっても、単にデータだけでなく、システム全体のバックアップが必要です。たとえば名古屋港のケースでは、数日で復旧できており、非常に模範的な事例といえます。一方で、KADOKAWAのように数ヶ月も業務が停止したケースもあります」（成田氏）

つまり、復旧の度合いは、バックアップの可用性と実効性、システムの複雑性と相互接続の度合い、感染範囲の特定と再感染防止策の徹底に左右される。名古屋港の場合は、接続されているシステムの範囲が比較的限定されていたため、復旧が早く進んだと考えられる。

一方でKADOKAWAのケースでは、システムがあまりにも肥大化していたため、バックアップの復元が困難だったことから、最終的にはすべてを一から再構築することになった。こうしたケースは決して珍しくなく、特に大企業の場合、バックアップの適用よりも再構築の方が早いと判断されることも少なくない。アサヒGHDにようにシステムが非常に大規模になると、バックアップの適用自体が困難になる。

「企業のセキュリティ対策は、もはや自社だけの問題ではありません。現在求められているのは、サプライチェーン全体をどう守るかという視点です。サプライチェーンのどこかにセキュリティの脆弱性があれば、自社も被害を受ける可能性がある。だから全体としての防御力を高めることが不可欠なのです。特に、サプライチェーンの上位層に位置する企業は、関連企業に対してセキュリティガイドラインを策定・提示し、調達基準の中に『セキュリティ対策の有無』を明示する責任があります。また、中小企業であっても、海外企業への納入などグローバルな取引を行っている場合には、セキュリティ対策を講じなければ、将来的にサプライチェーンに参加できなくなる可能性も出てきます」（成田氏）

今後の対策としては、サプライチェーン全体のセキュリティガイドラインと調達要件の策定に加え、RDPやVPN、ネットワーク機器の脆弱性スキャンとパッチ適用の運用化が求められる。また、オフラインで改ざんできないようなバックアップを行うことと、サイバー攻撃などを想定した定期的なリストア訓練の実施も重要だ。さらに、フォレンジック調査（デジタル版の鑑識調査）や初動対応マニュアルの整備、経営層向けのサイバーレジリエンス訓練（サイバー危機への対応力を鍛える訓練）とBCP（事業継続計画）との統合も、今後のセキュリティ強化に欠かせない要素となる。 「アサヒGHDの事件は、セキュリティが単なるITの問題ではなく、経営そのものの問題であることを明確に示しました。企業経営においては、セキュリティを『コスト』としてではなく、『事業継続の前提』として捉える必要があります。サプライチェーン全体の防御を自社の防御と位置づけ、復旧能力、すなわちサイバーレジリエンスを競争力の源泉として捉えることが、今後の企業戦略において不可欠なのではないでしょうか」（成田氏）

The language of value in the modern enterprise has fundamentally changed. In boardrooms around the world, the conversation is dominated by new vocabulary: “AI-driven growth,” “speed to market,” “product innovation,” and the relentless pursuit of the “competitive advantage.” Yet, for many security leaders, the language they use to define their own value remains stuck in the past. It’s a dialect of blocked threats and patched vulnerabilities that feels increasingly disconnected from the core mission of the business.

This failure unequivocally stems from the models we use, rather than from a lack of intent. For decades, the return on a security investment was measured with the simple, defensive math of a cost center. This old model fails to capture the immense and often hidden value that a modern security posture contributes to the business. Now, we have a new economy — one where artificial intelligence (“AI”) is the primary engine of innovation and the cloud is the factory floor.

It’s time to reassess the calculus and explore a new economic framework, one that redefines security’s worth not by the incidents it prevents but by the business momentum it creates.

Calculating the true cost of disruption

For years, the quantifiable risk of a breach was a straightforward calculation of regulatory fines, customer notification costs, and credit monitoring services. These are still real costs, but they represent a fraction of the true financial impact in an AI-driven enterprise. The most significant danger isn’t isolated to loss of data. It’s the disruption of the intelligent systems that now form the central nervous system of the business.

Consider a global logistics company whose entire supply chain is orchestrated by an AI platform. A breach-like model poisoning compromises this system and acts as a catastrophic failure of the business itself. The true cost is the value of every delayed shipment, every broken supplier commitment, and the permanent loss of customer trust.

In this new reality, the most important metric becomes the cost of disruption avoidance. A modern, AI-powered security platform that can autonomously detect and neutralize a threat before it halts operations is both a defensive tool and a direct guarantor of revenue and business continuity.

Security as an accelerator — and an innovator

The second and, perhaps, most powerful shift in this new economic model is the reframing of security from a necessary defensive brake to a strategic accelerator. In the past, security was often seen as a gate, a checkpoint that slowed down development in the name of safety. Today, the opposite is true: A mature, unified security platform is one of the most effective tools for increasing the velocity of innovation.

Consider a financial services firm that’s racing to deploy a dozen new AI-powered financial models in a single year. In a traditional, fragmented security environment, each new model might require a six-week, manual security review — a process that would kill any hope of meeting their business goals. A modern, automated security platform that is woven into the development lifecycle can reduce that review process to a matter of days or even hours. It allows developers to innovate with confidence, knowing that security is an enabling partner, clearing the path for progress. This is a direct, quantifiable contribution to the company’s ability to compete and win.

Paying down the past: The value of a clean slate

Many organizations are silently being dragged down by a hidden liability: decades of accumulated “security debt.” This immense, unspoken risk is created by a patchwork of disconnected point products, inconsistent policies across different cloud environments, and the constant operational tax of managing dozens of disparate tools. It increases the attack surface and slows down the entire organization.

Moving to a single, unified security platform is akin to refinancing this debt. It provides a clean slate, a consistent and manageable foundation upon which to build the future. The value here is in the dramatic simplification of operations and the reduction of long-term risk, beyond just the savings on licensing costs. Consolidating from dozens of security tools to a single platform can dramatically cut an organization’s mean time to respond to a threat. It pays down an organization’s security debt and frees up its most valuable resources to focus on innovation.

Let’s speak a different language

These three concepts — the cost of disruption avoided, the velocity of innovation, and the reduction of security debt — form the pillars of a new, business-centric language for security leaders. They provide a holistic framework for calculating the true value of a modern security platform in a way that resonates with C-suite priorities.

Strategies, mandates, and action items for the modern CISO have evolved. Protecting the enterprise? Yes, of course. That is the first priority. But the new imperatives should also be to prove, in clear financial and operational terms, how security accelerates the business. Mastering this new economic language is the most essential step forward in this AI-driven world.

Curious about what else Helmut has to say? Check out his other articles on Perspectives.

現実には、膨大な計算資源を稼働させるための電力供給、高密度な半導体が発する熱を処理する冷却技術、そしてそれらを支える半導体と部材のサプライチェーンという、極めて物理的かつ重厚なインフラの問題が浮き彫りになりつつある。これらは地政学的なリスクや国家のエネルギー政策とも複雑に絡み合い、企業の戦略に無視できない影響を与え始めている。本稿では、AIデータセンターをめぐる電力、冷却、サプライチェーンという「物理的な壁」の実態を詳細に俯瞰し、この構造変化が日本企業のIT戦略や経営判断に対してどのような問いを突きつけているのかを深く掘り下げていく。

マクロ経済を揺るがす「AIの暴食」と電力インフラの限界点

かつてデータセンターの電力消費は、企業のコスト管理の一項目に過ぎなかったが、現在では国家レベルのエネルギー需給を左右するマクロ経済の主要論点へと変貌を遂げている。国際エネルギー機関（IEA）が発表した衝撃的な分析によれば、2024年の時点で世界のデータセンターは約415TWh（テラワット時）もの電力を消費しており、これは世界全体の電力需要の約1.5パーセントに相当する規模である。さらに深刻なのはその増加スピードであり、直近5年間を見てもデータセンターの電力消費は年率約12パーセントという驚異的なペースで増加し続けている。これは他の産業分野や家庭用需要の伸び率を遥かに凌駕する数値であり、デジタル化の進展とAIの普及がいかにエネルギー集約的なプロセスであるかを物語っている。

IEAの「Energy and AI」レポートにおける予測はさらに衝撃的である。AIによる計算需要が現在のペースで拡大し続ければ、2030年までにデータセンターの電力消費は現在の倍以上となる945TWh前後に達し、世界の電力需要の約3パーセント近くを占める可能性があると警鐘を鳴らしている。別の視点からの試算では、この消費規模は現在の日本一国が消費する総電力量に匹敵するとも言われており、たった一つの産業セクターが主要先進国レベルの電力を飲み込むという、前代未聞の事態が現実味を帯びているのである。また、欧州委員会も同様の危機感を抱いており、EU域内のデータセンター電力消費が2030年には2024年比で約1.6倍に達するというシナリオを提示している。その背景には、クラウドコンピューティングや動画ストリーミングの定着に加え、生成AIの学習および推論フェーズにおける膨大なワークロードが、将来の電力需要を牽引する最大のドライバーになるという明確な見通しがある。

このように、データセンターにおける電力消費の議論は、もはや一企業のIT予算の枠を超え、国家のエネルギー安全保障や脱炭素戦略と密接にリンクするようになっている。データセンターが集中する地域では、送配電網の容量不足である「系統制約」が深刻化しており、新規のデータセンター建設が電力供給の許可待ちで数年遅れるといった事態も世界各地で発生している。また、膨れ上がる電力需要は、各国が掲げるカーボンニュートラル目標との整合性を危うくする要因ともなり得る。再生可能エネルギーの供給が追いつかない場合、化石燃料による発電を維持せざるを得なくなるからだ。したがって、政府や規制当局は、データセンター誘致と電源開発、そして送電網の増強をセットで計画せざるを得ない状況に追い込まれており、AIインフラ論とは本質的に、限られた電力リソースを他の産業や家庭とどう配分するかという、社会的な調整問題へと発展しているのである。

高密度化する「熱」との戦いが招くファシリティのパラダイム転換

電力供給の問題と表裏一体の関係にあるのが、AIサーバーが発する猛烈な「熱」をいかに処理するかという冷却の課題である。GPU（画像処理半導体）を搭載したAIサーバーの高性能化は、計算能力の向上をもたらすと同時に、単位面積あたりの電力密度と排熱量を劇的に押し上げている。従来の企業の基幹システムやWebサーバーを収容する一般的なデータセンターでは、サーバーラック1本あたりの消費電力は5から10kW（キロワット）程度が標準的であり、部屋全体に冷気を循環させる従来型の空冷方式で十分に冷却が可能であった。しかし、生成AIの学習や推論に用いられるハイエンドのGPUサーバーをフル搭載したラックでは、1ラックあたりの消費電力が50kWを超え、場合によっては100kWに迫るケースも珍しくなくなっている。

これほどの高密度環境になると、空気による熱交換だけでは物理的に冷却が追いつかなくなる。空気を媒体とする冷却には熱容量の限界があり、ファンを高速回転させれば騒音が爆音となり、風量そのものがサーバー機器を物理的に振動させてしまうリスクすら生じるからだ。そこで注目されているのが、水や特殊な冷媒を用いる「液冷技術」である。調査会社TrendForceの分析によれば、AIデータセンターにおける液冷システムの採用率は、2024年時点の約14パーセントから、2025年には30パーセントを超えて急拡大すると予測されている。現状では世界全体のサーバー市場で見れば依然として空冷が主流ではあるものの、最先端のAI計算基盤においては、液冷への移行が不可逆的なトレンドとなりつつある。

液冷へのシフトは、単にエアコンを高性能なものに買い替えるといったレベルの話ではない。データセンターの設計思想そのものを根本から覆すパラダイム転換を意味するからだ。たとえば、チップに直接冷却プレートを密着させる「ダイレクトチップ冷却」や、サーバーごと絶縁性のある液体に沈める「浸漬冷却（イマージョンクーリング）」といった方式を導入するには、建物内の配管設備、床の耐荷重、電源供給のレイアウトなどをすべて見直す必要がある。従来型の5kWラックを前提とした既存のデータセンターに、後付けで100kW級のAIラックを大量に導入することは極めて困難であり、AI専用の新たな施設を建設するか、大規模な改修を行う必要に迫られる。また、冷却効率を示す指標であるPUE（Power Usage Effectiveness）の改善は、運用コストの削減だけでなく、環境負荷低減の観点からも至上命題となっている。AIインフラを語る際、どうしてもモデルのパラメータ数やGPUのスペックに目が奪われがちだが、それらを安定稼働させるための冷却インフラという物理層の制約こそが、今後のデータセンターの競争力を決定づける最大の要因になりつつあるのである。

偏在するサプライチェーンと地政学リスクが突きつける戦略的選択

AIインフラ構築のボトルネックは、電力や冷却といったファシリティ面だけにとどまらない。計算処理の中核を担うGPUやAIアクセラレータ、そしてデータの高速転送を支えるHBM（広帯域メモリ）など、半導体サプライチェーンの極端な偏在と集中もまた、深刻な制約要因となっている。NVIDIAの2024年度決算において、データセンター事業の売上が前年比217パーセント増という驚異的な伸びを記録したことは記憶に新しいが、これは世界中の資金と需要が、特定の企業の特定の製品に殺到したことを端的に示している。IoT Analyticsの市場レポートによれば、データセンター関連の設備・インフラ支出は2024年時点で約2900億ドル規模に達し、2030年には年間1兆ドル前後にまで膨張すると予測されているが、この巨額の投資マネーの多くは、限られたサプライヤーへと流れ込んでいるのが実情だ。

問題は、最先端のAI半導体を製造できるファウンドリや、HBMのような特殊メモリを量産できるメーカーが世界に数社しか存在しないという事実である。TSMCやSamsung、SK Hynixといった主要プレイヤーの生産能力はすでに逼迫しており、工場の新設やラインの増強には巨額の投資と数年単位の時間が必要となる。さらに、サーバー筐体、電源ユニット、冷却用のポンプや特殊配管といった周辺機器に至るまで、グローバルなサプライチェーンは複雑に絡み合っており、その結節点のどこか一つでも滞れば、全体の納期が遅延する構造になっている。ここに米中対立をはじめとする地政学的な緊張や、各国の輸出管理規制、データローカライゼーション（データの国内保存義務）といった政治的な要素が加わることで、AIインフラの調達は単なる購買業務ではなく、高度なリスク管理と国家戦略の読み解きが必要な領域へと変質している。

日本国内に目を転じても、事態は切迫している。2025年のジャパン・エナジー・サミットで共有された報告によれば、日本のデータセンター向け電力需要は総需要の約2パーセントを占めるに至っており、2030年には約5パーセントへ倍増する見込みである。特に東京圏には10GW（ギガワット）規模という巨大なデータセンター建設計画のパイプラインが存在し、これは地域のピーク電力需要の約17パーセントにも相当する。送電網の増強が追いつかなければ、計画の一部は実現不可能となるか、北海道や九州といった再生可能エネルギーのポテンシャルが高い地方への分散を余儀なくされるだろう。

こうした状況下で、企業のCIOやIT部門は難しい舵取りを迫られている。企画段階から電力消費と冷却コストを織り込んだリアリティのあるAI活用計画を策定すること、クラウド選定において単に機能や価格だけでなく、そのリージョンが依存する電源構成や地政学リスクを考慮に入れた「ポートフォリオ」を組むこと、そしてサプライチェーンの混乱を見越して調達戦略を多重化すること。これらが今後のIT戦略における必須の要件となる。AIインフラを巡る議論を「サーバー室の中」の技術論から引き剥がし、エネルギー政策や国際情勢という「サーバー室の外側」の現実と接続して捉え直す視座こそが、これからの経営層には求められているのである。

The morning of Monday, Oct 20, 2025, I went to my healthcare provider’s portal to pay a bill. This was my experience:

Upon calling my provider to pay over the phone, they were unable to take my payment as their internal systems were also down, leaving us customers hanging with no direction on how to proceed.

My healthcare provider’s SaaS was completely functional; however, their integrated payment vendor, which is reliant on AWS infrastructure, apparently has ineffective redundancies. So, the 10/20/2025 AWS outage resulted in a most unfortunate experience for any customer or employee hoping to utilize this important capability while hindering my healthcare organization from receiving revenue.

Who is to blame? AWS? The payment vendor? Ultimately, my healthcare provider is responsible for their customers’ (and employees’) inability to interact with their services. A cloud outage is not in the same acts-of-nature class as hurricanes, earthquakes, tornadoes, etc., but we do treat them as such and that is simply wrong because these outages can be mitigated.

This is a clear and far too common industry-wide epidemic: poor adoption and execution of cloud computing resilience, resulting in unreliable critical services to both customers and employees.

As reported directly by AWS’ Summary of the Amazon DynamoDB Service Disruption in Northern Virginia (US-EAST-1) Region, a latent race condition in DynamoDB’s DNS management system led to an empty DNS record for the US-EAST regional endpoint, causing resolution failures affecting both customer and internal AWS service connections. This adversely affected the following services: Lambda, ECS, EKS, Fargate, Amazon Connect, STS, IAM Console Sign-In and Redshift.

On 10/29/2024, Microsoft 365 (m365.cloud.microsoft or portal.office.com) experienced an outage due to the rollout of an impacting code change. This affected Microsoft 365 admin center, Entra, Purview, Defender, Power Apps, Intune and add-ins & network connectivity in Outlook. This is all documented by Microsoft in Users may have experienced issues when accessing m365.cloud.microsoft or portal.office.com.

Both of these recent outages required vendors to halt automated processes and manually navigate recovery to bring affected systems back to an operational state. Let’s face it: Cloud providers are not magical and are subject to the same recovery patterns as any enterprise.

Outages are a reality of any system or platform and affect literally every organization. Hence:

Your cloud provider is a single point of failure!

Corporate infrastructure strategies vary from total dependence on provider vendors to actively taking ownership and architecting necessary redundancies for critical systems. When underlying provider outages occur, it is often a catalyst to revisit enterprise resilience strategy, even if you are not directly affected.

When examining an enterprise’s fault-tolerant architectures (which rarely even exist), it may be a good time to instead consider fault avoidance architectures. The latter kicks in when bad happens and the former actively monitors triggers to avoid bad.

This type of introspective examination is too often overlooked, as it is far easier for enterprises to fall into believing the many myths that govern their IT strategy and operations, especially when it comes to Cloud.

Unpacking the myths

Myth #1 – A single cloud provider reduces complexity

Vendors will place every kind of study and incentive in front of enterprise leadership to back the fallacy that locking into their platform is in the best interests of their company. Let’s be clear: It is always in the best interests of the vendor. This concept is then passed down from leadership to engineers who are encouraged to believe what their leadership tells them, and we get into a situation where thousands upon thousands of companies are under the control of a single vendor. Scary, right?

When it comes to multi-zonal resilience, app-cross-region resilience, blast-radius reduction, and resilient app patterns, there is additional complexity. Knowing that these approaches have dependencies on complex fine-tuned cloud infrastructures means there is no easy button.

Myth #2 – Cloud platform component defaults are generally a good starting point

Relying on easy-button best practices is what gets enterprises into trouble. The responsibility of an IT cloud infrastructure team is to work with solution architects and engineers to fine-tune their designs to optimize efficiencies, resilience and performance while controlling costs. Cloud vendor default configurations are necessary as they set a functional starting point, but they should never be trusted as a sound design. In fact, they can produce unnecessarily large loads on default regions when left unchecked. The AWS US-East-1 region is historically the most affected region when it comes to outages, and yet so many critical enterprise systems run exclusively in that region.

Vendor plug-and-play architectures must be scrutinized before going into production.

A responsible architecture governance practice should have a policy to avoid known outage-prone regions and single-point-of-failure configurations. These should be vetted in the architecture review board before ever going to production.

Myth #3 – My cloud provider/vendor will take care of me

Service level agreements (SLA) are paid out service credits tied to the cost of the affected service, not cash refunds. They generally start at 10% of service charges, never resulting losses. Your enterprise will literally get pennies back on dollars lost.

The July 2024 CloudStrike outage cost CloudStrike around $75M + $60M they paid out in service credits. This pales an order of magnitude when compared to just one customer, Delta Airlines, which lost $500M net. Parametrix Insurance’s detailed analysis estimates the total direct financial loss facing the US Fortune 500 companies is $5.4B. CloudStrike literally paid pennies on the dollar for their error, so an enterprise’s reliance on a vendor must be managed knowing this reality.

The 11/18/2025 Cloudflare outage, with its 20% hold on global web traffic, equally affected hundreds of millions of accounts, including major systems like X (Twitter), OpenAI/ChatGPT, Google’s Gemini, Perplexity AI, Spotify, Canva and even all three cloud providers. This heightens how a single vendor/platform dependency is a real threat to business continuity.

Enterprises must protect themselves because their vendors won’t.

Future purchase and contract negotiations should pivot toward SLA penalties that are based on enterprise losses over enterprise service costs. Unfortunately, this will drive service costs higher, but it builds in better financial protection when reliant on systems outside of your control.

Myth #4 – Multi-cloud is too expensive and too demanding

To mitigate the impact of regional cloud outages, enterprises that adopt multi-cloud architectures that prioritize resilience, portability, and failover orchestration find additional benefits when they are implemented with a mindset of fault avoidance and cost/performance optimization. This means multiple triggers govern where workloads run, resulting in optimal efficiencies.

This needs to be a priority effort backed by the C-Suite and requires a culture shift to succeed; hence, multi-cloud deployments are exceedingly rare. Still, those who have done this reap benefits well beyond resilience (e.g., large orgs like Walmart, Goldman Sachs, General Electric and BMW as well as SMBs like FirstDigital, Visma and Assorted Data Protection).

The NIST Cloud Federation Reference Architecture (NIST Special Publication 500-332) is a great document to establish a baseline grounding of these concepts.

• Active-active resilience is a pattern for mission-critical apps (e.g., financial trading, healthcare, e-commerce checkout). It maximizes resilience and availability, but at a higher cost due to duplicated infrastructure and complex synchronization. This pattern lends itself best toward fault avoidance with all the goodness of proactive efficiency and optimization triggers.
• Active-passive failover is a pattern where a primary cloud handles all traffic, and a secondary cloud is on standby. It provides disaster recovery without the full cost of active-active, but will introduce some downtime and requires a robust replication strategy. It clearly is only a fault-tolerant approach.
• Cloud bursting is a pattern where applications run primarily in one cloud but “burst” into another during demand spikes, providing elastic scalability without over-provisioning. It can also provide a good degree of fault tolerance.
• Workload partitioning (best-of-breed placement) is a pattern where different workloads are assigned to the cloud provider best suited for them. It greatly optimizes performance, compliance, and cost by leveraging provider strengths, but will not be fully fault-tolerant.

Myth #5 – Cloud has failed. It’s time to get out

This is a recurring theme each time there is a major cloud outage, often tied equally to a cost comparison between on-premises vs. cloud (yes, cloud almost always costs more). The reality is that while there is true value to cloud in the overall infrastructure strategy, there also is value in prioritizing an investment in infrastructure choices, leveraging sensible hybrid strategies. Two effective strategic architectures are based on edge and Kubernetes. Edge reduces blast radius, while Kubernetes provides portable resilience across providers. Both are recommended when aligned with workload architecture and operational maturity.

• Edge-integrated resilience extends workloads to the edge while maintaining synchronization with central clouds. Local edge nodes can continue operations even if cloud connectivity is disrupted, then reconcile state once reconnected. In addition to adding a moderate level of resiliency, it also benefits from ultra-low latency for real-time processing (e.g., IoT, manufacturing robotics, autonomous vehicles). This approach is often found in factory, retail store, and branch office use cases.
• Kubernetes-orchestrated resilience is a cloud-agnostic orchestration layer that can be leveraged locally and across multiple providers. In addition to a prominent level of resilience, this type of service mesh (e.g., Istio, Linkerd) adds traffic routing and failover capabilities that reduce vendor lock-in. Overall, it is a foundational enabler for multi-cloud, giving enterprises a consistent control plane across providers and on-premises.

Calls to action

There are two major enterprise IT leadership bias camps: Build and Buy. Both play a factor in every enterprise.

The reference architecture patterns shared above address Build bias workloads, which include integrations with Buy workloads.

Buy bias workloads are too often subject to vendor-defined SLAs discussed above, which are terribly limiting to 10-100% credits for charges based on the duration of an outage as penalties. Realistically, that really is not going to change; however, SaaS quality over the past 20 years has increased substantially:

This becomes the new bar and offers a great measure an enterprise can leverage for both themself and their vendors:

The 1-9 Challenge: Every SaaS vendor, integrator and internal enterprise solution should provide one “9” better than their underlying individual hosting platforms alone.

For example, when each cloud vendor provides a 99.9% SLA for a given service, leveraging an active-active multi-cloud architecture raises that SLA well beyond 99.99%.

Take control of your critical services first and leverage these patterns as a baseline for net-new initiatives moving forward, making high resilience your new norm.

Bottom line: the enterprise is always responsible for its own resiliency. It’s time to own this and take control!

This article was made possible by our partnership with the IASA Chief Architect Forum. The CAF’s purpose is to test, challenge and support the art and science of Business Technology Architecture and its evolution over time as well as grow the influence and leadership of chief architects both inside and outside the profession. The CAF is a leadership community of the IASA, the leading non-profit professional association for business technology architects.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

La automoción vive un momento decisivo. A los retos de la electrificación, los nuevos modelos comerciales o las crecientes exigencias regulatorias ―principalmente, en materia de sostenibilidad― se suma una modernización tecnológica que avanza con paso firme. La digitalización y la IA han dejado de ser herramientas accesorias: hoy son una parte esencial del modelo de negocio del concesionario.

El cambio ya se percibe en el día a día de estos centros. La mayoría de los directivos del sector considera que la IA será clave para el futuro de sus empresas, y más del 80% de los concesionarios la utiliza o tiene planes inmediatos para integrar soluciones basadas en ella.

Punto de venta y centro tecnológico

Los concesionarios han experimentado una evolución extraordinaria en poco tiempo. Hoy, conviven en ellos herramientas de gestión avanzadas, modelos analíticos, automatización y procesos digitales que antes parecían impensables. No se trata de un ajuste superficial, sino de una forma completamente nueva y diferencial de organizar y gestionar el negocio.

Los resultados refuerzan esta transformación: aquellos concesionarios que han incorporado el uso de la IA han visto crecer sus ingresos; muchos de ellos, con incrementos de facturación de un 20% a 30%, y algunos incluso por encima de ese porcentaje.

Todo ello demuestra que la digitalización no es un recurso añadido. Es un elemento que potencia ―en algunos casos, multiplica― la capacidad competitiva del concesionario.

Ámbitos de cambio

Buena parte del impacto de esta particular revolución tecnológica se concentra en tres áreas:

• Eficiencia operativa: la automatización está permitiendo agilizar trámites, reducir errores y dedicar más tiempo a tareas con mayor valor. En algunos concesionarios, la eficiencia comercial ha aumentado hasta un 70% u 80% gracias a soluciones digitales de nueva generación.

• Ventas más precisas y personalizadas: la IA ayuda a identificar qué clientes tienen más probabilidad de comprar y qué mensajes funcionan mejor con cada perfil. Las mejoras en conversión superan el 20% en algunos casos, y hay asesores que han logrado entre un 15% y un 25% de ventas adicionales al año gracias a estas herramientas.

• Nuevo enfoque en posventa: la tecnología permite anticipar necesidades de mantenimiento, organizar mejor la carga del taller y gestionar con más precisión los recambios. La posventa sigue siendo uno de los pilares de la rentabilidad y todo lo que contribuya a optimizarla supone una ventaja clara.

Rentabilidad y generación de empleo

Los concesionarios han trabajado históricamente con márgenes muy ajustados. Hoy, las proyecciones apuntan a que la implantación de IA podría llevar a duplicar la rentabilidad neta de aquí a cinco años, pasando del 1,3% actual a niveles cercanos al 3% en un escenario de transformación avanzada. Pero no bastará con adoptar nuevas herramientas. Hacen falta datos de calidad, integración entre sistemas, nuevas capacidades internas y una estrategia clara. La oportunidad, eso sí, está ahí.

También es importante subrayar que la IA no está destinada a desplazar al factor humano del concesionario. Lo que hace es transformar funciones. Algunas tareas administrativas irán perdiendo peso, pero surgirán otras relacionadas con el análisis de datos, la automatización o la gestión de nuevas tecnologías. Si se orienta bien esta transición, el sector podría generar hasta 10.000 empleos netos de aquí a 2030. El empleo no desaparece: se transforma.

Una oportunidad para España

España cuenta con una red de concesionarios sólida y bien implantada en todo el territorio. La digitalización abre la puerta a reforzar ese modelo y hacerlo más competitivo, eficiente y sostenible. La IA permitirá operar con datos en tiempo real, personalizar la relación con el cliente, planificar mejor el taller, optimizar los recambios y mejorar toda la experiencia digital, desde el interés inicial hasta la posventa. No se trata solo de incorporar más software: se trata de repensar el modelo para adaptarlo a una movilidad que cambia a gran velocidad.

En conclusión, la modernización tecnológica ya está transformando el sector. La pregunta es quién sabrá aprovecharla mejor. En Faconauto, defendemos que esta transición debe afrontarse con visión y ambición. Los concesionarios que combinen innovación, datos y talento humano serán los que marquen la pauta en la nueva movilidad. La tecnología potencia el valor humano del concesionario, no lo sustituye.

La automoción entra en una nueva etapa. La oportunidad de liderarla está en nuestras manos.

>

医療データ規制は「多層構造」で理解する

日本の医療データ規制を理解しようとするとき、多くの人がまず条文や個別の法律名から入ろうとします。しかし、実務で本当に重要なのは、「どのレイヤーのルールが自分たちのシーンに効いているのか」を把握することです。最下層にあるのは、個人情報保護法に代表される横断的なプライバシー法制であり、その上に医療分野固有の法律が乗り、そのさらに上にガイドラインや倫理指針が積み上がり、最上層に具体的なシステムやプロジェクトが立ち上がっていく、というイメージを持つと整理しやすくなります。

最もベースになるのが、個人情報保護法です。医療データは、同法上「要配慮個人情報」に分類され、取得・利用・第三者提供のいずれについても、通常の個人情報より厳格なルールが課されています。診療という一次利用の範囲では比較的自由度が高い一方で、研究やAI開発、製薬企業によるリアルワールドデータ活用といった二次利用に踏み込むと、一気に法的な要件が重くなるのが特徴です。

その上に位置づけられるのが、次世代医療基盤法や医療法、医療保険関連法令といった医療分野固有の法律群です。特に次世代医療基盤法は、匿名加工・仮名加工という加工概念を軸に、医療データをオプトアウト方式で集約し、研究・産業利用に供するための枠組みを用意しています。この法律は、個人情報保護法の特例法として設計されており、「同意に基づく個別の第三者提供」とは別のルートを整備した点で、大きな意味を持ちます。

さらにその上には、厚生労働省の「医療情報システムの安全管理に関するガイドライン」や、医療・介護分野の個人情報取扱いガイダンス、研究倫理指針など、行政機関が出すソフトローが存在します。これらは法律そのものではありませんが、実務上は「守らなければならない準則」として機能しており、医療機関のシステム更新やクラウド移行、AI導入プロジェクトを進める際の事実上のチェックリストになっています。

そして最上層には、全国医療情報プラットフォームや電子処方箋、オンライン資格確認、保険者や自治体が構築する各種データベースといった具体的な医療DXプロジェクトが位置づけられます。これらは、それぞれ個別の実施要綱や仕様書を伴っていますが、根本では先述の法律とガイドラインに依拠して設計されています。医療現場の情報システム担当者やベンダー、スタートアップにとっては、この「多層構造」を頭に入れたうえで、自分たちの座標を確認することが欠かせません。

一次利用と二次利用でがらりと変わる法的ハードル

医療データの法規制を考えるうえで、もう一つ重要な視点が「一次利用」と「二次利用」の違いです。一次利用とは、診療や看護、診療報酬請求、医療安全など、患者に対して医療サービスを提供するために必要な範囲での利用を指します。これらについては、患者が医療機関を受診した時点で、暗黙の前提として情報利用が認められていると解されており、個別に細かい同意を求めなくても、カルテへの記載や情報共有が行われています。

これに対し、二次利用とは、診療そのものを超えた目的、例えば研究や新規サービス開発、製薬企業のリアルワールドエビデンス創出、AIモデルの学習、保険商品の開発などを目的としたデータ活用を指します。この領域では、個人情報保護法上の同意要件が前面に出てくるほか、研究倫理指針や各種ガイドラインの適用も受けるため、法的ハードルが一気に高くなります。

ここで登場するのが、次世代医療基盤法に基づく匿名加工・仮名加工の仕組みです。この仕組みは、患者一人ひとりから個別に同意を集めなくても、一定の条件のもとで大規模な医療データを利活用できるようにするための「専用レーン」として設計されています。認定事業者というフィルターを通し、厳格な安全管理とオプトアウトによる権利保障を組み合わせることで、個人情報保護とデータ利活用の両立を図ろうとする発想です。

とはいえ、現場では一次利用と二次利用の境界が必ずしも明確ではありません。医療の質向上や院内業務改善を目的としたデータ分析は、一次利用と解釈される余地もあれば、研究に近いと見なされて倫理審査や同意が求められる場合もあります。そのため、実務では、目的の具体的な内容と、結果の外部公表・論文化の有無、外部企業の関与の度合いなどを丁寧に整理しながら、どの法的枠組みのもとで進めるのかを判断することが重要になります。

医療DX時代に高まる「統合的なコンプライアンス設計」の必要性

医療DXが進展するにつれ、個々のシステムやプロジェクトを個別に見ているだけでは済まない時代になりつつあります。電子カルテ、地域医療連携ネットワーク、オンライン資格確認システム、電子処方箋、健診データベース、介護保険の情報システムなどが相互に接続されていくと、データは一つのシステムの内側にとどまらず、ライフコース全体をまたいで流通するようになっていきます。

このとき、単に「法律に違反していないか」をチェックするだけでは十分とは言えません。さまざまなシステムを横断して、アクセス権限やログ管理、再識別のリスク評価、AIモデル学習への二次利用の範囲などを統合的に設計しなければ、どこかで漏えいや不適切利用が起こった際に、責任の所在が曖昧になったり、患者の信頼を一気に損なう可能性があります。厚生労働省の医療情報システム安全管理ガイドライン第6.0版が、経営層と情報システム担当者の双方に対する要件を詳細に示しているのは、まさにこの「統合ガバナンス」の必要性を意識しているからです。

今後、日本の医療データ法規制は、デジタル化とデータ活用の加速に合わせて、さらに改正やガイドラインの更新が続いていくと考えられます。その変化を追いかけるためには、個々の条文だけを覚えるのではなく、「多層構造」「一次利用と二次利用の境界」「統合コンプライアンス」という三つの視点を持ちながら、全体像を押さえておくことが重要になっていくでしょう。

マルチエージェントとは何か

マルチエージェントシステムとは、複数のエージェントが同一のゴールに向かって協調したり、時には競合したりしながら振る舞うシステムを指します。LLMの文脈では、たとえばリサーチ専門のエージェント、プランニング専門のエージェント、文章生成に長けたエージェント、品質チェックを行うエージェントなどが、それぞれの役割を持ってやり取りを行う形が典型例です。

なぜわざわざ一体の巨大なエージェントではなく、複数に分けるのでしょうか。理由のひとつは、モジュール性と責任分担の明確化です。役割ごとにエージェントを分けることで、特定の役割のプロンプトやツール構成、評価指標を個別に最適化できます。問題が起きたときにも、「リサーチエージェントの検索戦略がおかしいのか」「レビューエージェントの基準が厳しすぎるのか」といった切り分けがしやすくなります。

もうひとつの理由は、異なるモデルや設定を柔軟に組み合わせられることです。高速だがやや精度の低いモデルをブレインストーミングに使い、高性能だが高コストのモデルを最終判断や重要な文書の生成に使うといった工夫も、マルチエージェント構成であれば自然に実現できます。人間のチームで、ジュニアとシニアが役割を分担するのに近いイメージです。

役割分担とコミュニケーション設計

マルチエージェントを実用的に機能させるには、役割分担とコミュニケーションの設計が重要になります。まず役割分担については、人間の組織設計と同様に、タスクを分解し、どの部分をどのエージェントが得意とするかを整理するところから始まります。典型的なパターンとしては、情報収集、要約と構造化、プランニング、生成、レビューといったフェーズごとにエージェントを分ける方法があります。

コミュニケーション設計では、エージェント同士がどのような形式でメッセージをやり取りするかが鍵になります。自然言語で会話させることもできますが、その場合、会話が冗長になったり、話が脱線したりするリスクがあります。より制御しやすくするためには、メッセージのフォーマットをあらかじめ定義し、エージェント間で受け渡す情報を構造化することが有効です。たとえば、「現在のタスク」「前提条件」「制約」「期待される出力形式」といった項目を必ず含むようにし、それを基盤として各エージェントが自分の仕事を進めるように設計します。

さらに、全体を統括する「オーケストレーター役」のエージェントを置くこともよく行われます。オーケストレーターは、ユーザーからの依頼を受け取り、タスクを分解して各エージェントに割り振り、途中の成果物を統合し、必要に応じて再度タスクを再配分します。この構造は、プロジェクトマネージャーがチームメンバーに仕事を振りながら進捗を管理する姿に似ています。

利点と課題、そして現実的な導入ステップ

マルチエージェントシステムの利点は、モジュール性と柔軟性だけではありません。複数のエージェントが異なる観点からタスクに取り組むことで、アイデアの多様性やエラー検出能力が高まることも期待できます。たとえば、生成エージェントが作った文書を、別のエージェントが批判的にレビューし、論理の飛躍や事実誤認を指摘するといった構造です。これは、人間の組織で「ダブルチェック」や「クロスレビュー」を行うのに近い安全装置として機能します。

一方で、課題も少なくありません。まず、エージェント同士のやり取りが増えるため、全体の処理時間やコストが膨らみやすくなります。また、会話が無駄に長くなり、本筋から逸れてしまうこともあります。この問題に対処するには、メッセージの制限やタイムアウトの設定、各エージェントの目的と終了条件を明確にすることが必要です。

さらに、ユーザーから見たときに「誰が何をしているのか」が分かりにくくなるリスクもあります。複数のエージェントが裏側でやり取りをしているとしても、ユーザーインターフェース上はできるだけシンプルに保ち、「今はリサーチ担当が情報を集めています」「これからレビュー担当がチェックします」といった程度の説明にとどめる方が、理解しやすいことが多いでしょう。

現実的な導入ステップとしては、最初から多くのエージェントを用意するのではなく、単一エージェントで運用しているシステムの中から、明らかに役割を分けた方がよい部分を切り出すところから始めるのがよいと考えられます。たとえば、品質チェックのロジックが複雑になってきた場合、それを独立したレビューエージェントに任せるように変更する、といった具合です。こうして少しずつ役割を分割し、エージェント間のやり取りを設計していくことで、マルチエージェントへの移行コストを抑えつつ、徐々に「AIチーム」としての振る舞いを育てていくことができます。

マルチエージェントシステムは、まだ試行錯誤の多いフロンティアですが、人間の組織やチームワークのメタファーを活かせる分野でもあります。どのような役割を持つエージェントを、どのようなルールで協調させるか。その設計は、技術的課題であると同時に、組織デザインやマネジメントの知見とも深くつながるテーマだと言えるでしょう。