みずほ証券さんの誤発注と、それに関連する東証さんのシステム不具合について。
具体的にはどういうことが発生したのか、について、東証さんからのコメントが出ています。

投資家及び関係の皆様へ
-12月8日のジェイコム(株)株式の注文取消処理に係る株式・CB売買システムの不具合について-
http://www.tse.or.jp/news/200512/051211_a.html

まず、冒頭で、

同銘柄の当日の株価変動等の直接の原因は、みずほ証券による大量の誤発注でありますが、同証券による注文取消の指示が、当取引所において受け付けられなかった点につきましては、当取引所システムの不具合によるものであることが判明いたしました。

として、取引所システムの不具合が原因であることを認めてらっしゃいます。
取引所と証券会社の契約では、かなりの部分が「免責事項」になってい（ると思われ）ます。今回に限らず、従来より株式の取引量の増加で取引所のシステムが火を噴きそうな状況が続いてきてたわけですが、みずほ証券さんも、当然、今回の誤発注をしてから気づいて取り消しまたは訂正の処理を入れたでしょうから、それにも関わらず、そういう（誰のせいか特定しにくい）「単なる」遅延によって取消が遅れて約定したとすると、（多少、東証側のシステムが重かったにせよ）、東証さんの責任を問うことは難しいだろうなあ、と想像しておりました。し、実際、完全なシステムダウンの場合などを除き、取引所取引について、東証さんのシステム不具合の責任が問われた、というケースはあまり聞きません。
それが、あっさりと東証さん側が非を認めたというのが、かなり意外な感じがしたわけですが。
以下、発表文を見ていきますと、「経緯」として、

午前９時２７分、ジェイコム株式に対し、みずほ証券が６１万円で１株の売注文を、１円で６１万株として発注いたしました。その際、同銘柄は６７万２千円の特別買気配を表示中でしたが、当該売注文により約定成立要件が整い、売買が成立しました。ただし、今回の売注文が大量で初値成立後にも残っていたため、残存分は初値決定により設定された呼値の制限値幅の下限である５７万２千円の売注文として登録され（詳細は後述いたします）、大量の買注文と間断なく順次約定していくこととなりました。その過程で、みずほ証券から当該注文に対する取消注文が発注されましたが、そのような例外的状況において生ずる不具合が売買システムに存在したため、取消しができずにその後も連続対当により約定が順次成立することとなりました。

としています。（最初の誤発注の時間は記載されてますが、肝心な取消注文の到着時刻や、それまでに約定した株数に関する開示がありません。）
より詳細には、

新規上場銘柄の初値が決定した際には、当該初値を基準として同銘柄の呼値の制限値幅が設定されますが、この制限値幅を超える注文は、売買取引制度上、制限値段の注文とみなされます（以下「みなし処理」といいます。）。本事象は、このみなし処理が行われた注文に対する取消・変更処理の不具合であることが判明いたしました。
具体的には、ジェイコム株式について、特別買気配６７万２千円が表示されている状態で午前９時２７分に１円の売注文が発注され、初値６７万２千円が決定いたしましたが、これにより呼値の制限値幅（上下１０万円）が設定されました。この１円の売注文が大量で初値決定以降もなお残っていたため、みなし処理により呼値の制限値幅の下限である５７万２千円の売注文として登録され、この後、６７万２千円から順次買注文を消化する形で、約定を繰り返しつつ、値段が下落していくこととなりました。
このような状況下でみずほ証券による注文の取消しが複数回にわたって行われましたが、当該注文が発注された時点で板状態が対当中（約定処理中）であった場合に、対象注文が取消されないという不具合が発生いたしました。これは、みなし処理がなされ、それに対当する注文が存在する場合に生ずる不具合です。

と説明されています。
つまり、普通でも、そこそこ大きい注文に対して、その一部だけが約定する「内出来」のケースはよくあるわけで、その場合でも後から送った訂正・取消の電文はちゃんと効いていたんでしょうから（でなかったら、とっくに問題になっているハズ）、そういう単純な問題ではない、と。どうも、文中でいう「みなし処理」として、１円の売り注文が値幅制限下限いっぱいの５７万２千円の売り注文と東証側で自動的にみなすケースの場合に、こうした不具合が発生するということのようです。
「今後の対応」として、

本事象は、当取引所に直接新規上場する銘柄の場合で、かつ、今回のケースのように、特別買気配が表示中に気配の差引数量を超え、初値決定後も売注文が残るほどの大量の注文がみなし処理の対象となるような値段で発注されたような場合に発生する事象であることから、（以下略）

と、「当取引所に直接新規上場する銘柄の場合」で、反対注文の板の量に対して「大量」であり、しかも「みなし処理の対象」となる、という特殊な組み合わせのケースにしか発生しない現象だった、ということのようです。
つまり、こうしたシステムを作るときに、そういったケースも想定して「テスト」を行ってれば防げた・・・と言うのは簡単ですが、システムというのは複雑化し高度化してくると、そのケースの組み合わせの数は爆発的に増加するわけで、今回のような、通常では出てくるわけのないケースをどこまで想定してテストしていないといけなかったのか（重過失となるのか）、というのは、非常に難しい問題かと思います。
（上記の発表文だけ見ると、単なるロジックのチェックだけで防げたようにも見えますが、実際には、システムの稼働状況、リソースの消費状況などと複合して発生するエラーもあるわけで・・・。）
今回の場合、「結果」だけ見れば、これを約定させちゃうのは一般の人の目にも明らかにヘンだろうと思えるわけですが（つまり、結果としての損害賠償義務が発生するかどうかはともかく）、システムを構築する「プロセス」として、事前にこういうケースをすべて確実に潰せるしくみを構築できるのか？ 特に、金融のシステムというのは、何か「ゆがみ」が発生すると、そこをめがけてあっという間に数百億円規模の金が動いてしまうわけなので、大変に恐ろしいわけです。
監査法人の粉飾見逃しや、今問題になっている建築の耐震強度偽装の問題と同じく、ここでも、根底には、チェックのクオリティとそれにかけるコストとのバランスの問題があるかと思います。
「チェックを厳重にしろ」というのは簡単ですが、コストを倍増させてしまうようなチェックでは経済活動自体がストップしてしまいますし、一方、問題が次々に発生するようなチェックでは、チェックのしくみ自体の存在価値の問題になっちゃうわけで・・・・・難しいですね・・・。
（ではまた。）