スイスチーズモデルをご存知でしょうか。複雑なシステムがどのように失敗するかを説明する際によく登場するモデルです。図で表すと、だいたいこんな感じになります。

考え方はシンプルです。何重もの安全対策があったとしても――何枚ものチーズのスライスのように――それぞれの層には必ず穴があります。通常は、ある層の穴は前後の層の穴のない部分によって塞がれています（例えば、シフトをパーキングに入れなければキーが抜けないようになっていたり、サイドブレーキをかけたまま走り出そうとすると車が警告音を鳴らしたりするように）。しかし時折、たまたま穴と穴が一直線に並んでしまい、大きな惨事につながることがあるのです。

このモデルは過去の事故の分析や将来の事故の防止に使われています。支持する人もいれば、批判する人もいます。その応用について語るのが難しいのは、よく引き合いに出される事例がどれも凄惨だからです。私自身、本の中でTherac-25について書きましたが、あの章のリサーチも執筆も本当に気が重い作業でした。他によく挙げられるケーススタディも同じように陰惨なものばかりです。チェルノブイリ、チャレンジャー号爆発事故、テネリフェ空港ジャンボ機衝突事故、ディープウォーター・ホライズン爆発事故などです。

それでも私がこのモデルを紹介したいと思ったのは、私の中ではUIデザインにも当てはまると考えていて、小さなディテールが積み重なって全体にどう影響するかを考える際に役立つことがあるからです。

この第1回では、まずはより伝統的な例から始めましょう。といっても、そこまで悲惨ではない例です。金融サービスとトレーディングを手がけるナイト・キャピタル・グループ（Knight Capital Group）の物語です。事故の概要については、ヘンリコ・ドルフィングによる要約を引用します。

2012年8月1日の朝、ナイト・キャピタル・グループはいつも通りの取引日を迎えるべくシステムを稼働させました。しかし数分のうちに、同社は意図しない大量の注文を米国株式市場に送り込み始め、数十銘柄にわたって高値で買い、安値で売るという、経済合理性のないパターンを繰り返し、通常の制御では止めることができませんでした。当初は異常な市場動向に見えたものが、たちまち米国最大級のマーケットメーカーの内部で起きたシステム全体の障害へと発展し、アルゴリズムはトレーダーにもエンジニアにもリアルタイムでは完全には理解できない動きを見せたのです。[…]

問題が特定され、システムが停止されたのは約45分後のことでしたが、その時までにナイト社は154銘柄で400万件以上の約定を発生させ、約3億9700万株におよぶ取引を行い、数十億ドル相当のポジションを抱え、4億6000万ドル以上の損失を出していました[…]. この出来事の規模は財務的なものにとどまらず、構造的なものでもありました。たった一度のデプロイの失敗が、米国株式取引の大きなシェアを担うシステム全体に波及したのです。[…]

何が起きたのか、順を追って見ていきましょう。

ずっと以前、同社は取引の一部を自動化するためにPower Pegと呼ばれるごくありふれた機能を作っていました。この機能は、必要な取引がすべて完了すると実行を停止させる、共通のリミッターを使っていました。数年間使われた後、この機能は2003年に非推奨となり、使われなくなりました。しかし重要なことに、コード自体は実際には削除されませんでした。

2003年から2012年のどこかの時点で、リミッターの機能がアップグレードされ、古いコードはそれと互換性がなくなりました。本番環境にあるすべてのコードは新しいリミッターを使うように書き換えられましたが、すでに非推奨で使われていなかったPower Pegだけは書き換えられませんでした。

2012年、同社は自動取引のための新しいプログラムの開発を始めました。その開発者たちは、かつてPower Pegを有効にしていたのと同じソフトウェアフラグを再利用することにしました。当時、古いコードが残っていることは知られていましたが、新しいプログラムがそのコードを上書きするはずなので、再利用されたフラグは新しいコードだけを呼び出すだろうと考えられていたのです。

2012年7月、新しいコードが完成し、同社はPower Pegを上書きする形で全サーバーへのインストールを開始しました。8台すべてのサーバーに新しいコードを展開する予定でしたが、手違いにより7台にしか展開されませんでした。

誰もそのミスに気づきませんでした。

ここまで来れば、全体像が見えてきたのではないでしょうか。ここまで読み進める中で、段落を追うごとに顔をしかめてきた方も多いのではないかと思います。

8月1日、新機能のフラグがオンになりました。7台のサーバーでは何の問題もありませんでしたが、残りの1台では、そのフラグが眠っていた古いコードを呼び覚まし、即座に実行が始まりました。古いコードは新しいリミッターと互換性がなかったため、制限がかかることはなく、1時間足らずで数百万件の取引へと雪崩を打ち、甚大な付随的被害をもたらしました。その後、同社が4億ドル以上を失ったというニュースに対する市場の反応により、同社自身の株価も急落したのです。

そういえば、まだ触れていませんでしたが、この障害は会社を破綻させました（正確には合併に至ったのですが、これはナイト・キャピタル・グループが事実上破綻しかけた後の体面を保つための措置だったように見えます）。

これはスイスチーズモデルとどう関係するのでしょうか。5枚のチーズにそれぞれ5つの穴が空いていたと考えることができます。

• 古いコードを実際に削除しなかったこと
• 同じフラグを再利用したこと
• 8台すべてのサーバーにデプロイしなかったこと
• デプロイを誰かがダブルチェックする手順がなかったこと
• 通常のリミッターが機能しなかった際に、暴走したプロセスを自動で検知し（そしておそらく自動で停止させる）仕組みがなかったこと

このモデルで重要なのは、これらのどれか一つだけを見れば客観的には小さなミスであり、他の層によって防がれていたはずだということです。実際のところ、これらのうち4つまでが重なっても、惨事には至らなかったはずなのです。

しかし今回は、5つのミスが完璧に一直線に並んでしまったのです。

この種の事故を分析する際、連鎖の中のたった一つの出来事――今回で言えばコードを8台のサーバーに正しく展開しなかったシステム管理者――に責任を負わせることがよくあります。しかしそれは主に、私たちが個人の主体性にまつわる物語を好み、システムの物語を理解することを不得手としているからです（『スタートレック』ですらボーグ・クイーンを登場させました）。

この事故は後に「ナイトメア（Knightmare）」と呼ばれるようになりました。次回以降では、私たちにとってより身近なシステムの例をさらに紹介していきます。