２：システム障害・事故の事後対応例
　　JR東　2005年12月25日の羽越本線砂越〜北余目間第2最上川鉄橋付近における特急「いなほ14号」脱線事故　広報例
　　　�@当面の対応について　（2006年1月17日）［PDF/80KB］
　　　�A対策の実施状況と今後の取り組み　（2006年12月20日）［PDF/86KB］
　　　�B対策の実施状況について （2007年12月18日現在）［PDF/139KB］
　　　�C対策の実施状況について （2008年4月1日現在）［PDF/67KB］

その１　金融分野のシステム事故とその主要因　・概要

特集

『増加する金融ＩＴ訴訟』：技術的側面よりも義務違反や不法行為が争点　・・・・　　　　　　　　　　　　　　　　　週刊「金融財政事情」誌　2008年11月17日号掲載
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　多摩大学総合リスク研究所　総合リスク・マネジメント研究センター　稲垣　直樹


日本ではこれまでシステム事故処理は当事者間の話し合いで解決することがほとんどで、裁判沙汰まで発展することは稀であった。しかし、最近ではシステム事象に起因する民事訴訟（以下、ＩＴ訴訟）の増加が目立ち、金融機関も例外ではなくなっている。本稿ではＩＴ訴訟の特徴や事案における争点、訴訟に潜む要因について概観する。


バグの顕在化や想定外のトランザクション

システム統合時の障害やコンピュータの誤動作、ソフトウエア／プログラムの不具合などに起因する事故が増えている。
システム事故といった場合、広義の解釈では、個人情報保護やセキュリティ関連あるいは行員の不正利用といったものも含まれるが、ソフトウエアにからむ事案では、プログラム作成段階では現われないバグの顕在化や想定外の取引トランザクションなど、従来の知見では制御困難な事故が目立つ。

２００８年に発生したシステム障害^{_{（資料１）}}をみると、要件定義段階やプロジェクト推進途中、またシステム運用フェーズの事故と多岐にわたっている。資料２では、金融界のＩＴ訴訟において、判決文や鑑定意見書・証拠物から示唆に富むものを抽出した。
システム事故がいきなり裁判沙汰になることは少ない。多くの場合、たとえ事故や見込み違いが表面化したとしても、プログラム製造業者やベンダーとの請負契約や準委任契約で双方が係わっていることもあり、訴訟までには至らないケースが大半だ。当事者相互の信頼性レベルが自社の許容度を超えた場合のみ、第三者に判定を仰ぐことになる。

おもに損害賠償請求の形をとるＩＴ訴訟は、たとえば、ソフトウエア／プログラムに関する事故であると、
　　　�@プログラム瑕疵（バグ）がどの段階で組み込まれたか、
　　　�A複層に接続されたコンピュータ全体での相互関係に起因する非機能要因か、
　　　�B当時の技術レベルで予見・予知されることなのか（蓋然性があるか）、
　　　�C人間の誤操作などが争点となる。

そもそも「プログラム」に対する法的解釈は定まっていない。製造物責任法の対象からプログラムははずされているが、これは「バグのまったくないプログラムはまず存在しない」という社会通念をより所としていることによるものだろう（ＩＴ訴訟ではこれを前提においている事案が多い）。

裁判進行は、一般の民事事件と同様の流れになる。いうまでもないが、事案がシステム技術に起因するため、金融業務および情報技術に強い弁護士に任せるのが良策である。業務の特徴や背景、プログラム構造および事故原因を理解するまでに初期段階で時間を要する。さらに事故事実に基づき法的な裏付けをするのは容易な作業ではない。調停や和解の道もあるが、解決まで何年もかかる例が多い。たとえば、システムのロジック自体が事故の原因とされ、コンピュータを実際に稼働して判決に至ったケースでは五年以上の歳月を要した（注）。

そこまで日数を費やしても、最後まで技術的な納得性は得られにくいことから、争点が純粋な技術問題ではなく、むしろ契約・合意の形態（義務論）やベンダー側のプロジェクトマネジメント義務・協力義務・履行補助義務といった点で争うことで方向性がみえてくる訴訟が多い。ＩＴ訴訟では、法的なルールが整備されていない現状――システム事故に対する民訴法の未整備や法曹界におけるＩＴ専門分野向け人材不足――から、なかなか司法の便益を受けにくいという現実があるようだ。

システム的原因が争点になるケースは少ない

　金融機関のＩＴ訴訟は、類型化できるまでの判例数には至っていないものの、過去判例から、
　　　�@債務不履行、
　　　�A瑕疵担保責任、
　　　�B不法行為、
　　　�C製造物責任、
　　　�D商品の説明責任やガバナンス上の説明責任、
　　　�E義務違反・善管注意義務（最近は受託業務の「仕事完成義務」の視点も注目されている）――
の六つの側面でとらえることができる。

金融機関は、システム案件を子会社や外部ベンダーに委託する場合が多く、民法上の「契約」形式をとる。この場合、瑕疵担保責任の契約は一年以内に限定されるので、瑕疵担保期間の伸長を合意しておくことが望まれる。
同様に、金融機関はシステム開発規模や業務内容から「現行システムライフ」を見通して交渉する必要がある。瑕疵担保期間が終了した段階でのシステム障害は、損害賠償請求権の行使ができないため、不法行為に基づく損害賠償請求となる。つまり、瑕疵がベンダーの過失に基づくものであることを立証する必要がでてくるが、その作業は、弁護士任せにできるものではなく、現場に多大な労力を強いることになる。

日本のＩＴ訴訟では、プログラムの不具合が原因で被害が拡大したような場合のシステムの非機能問題（プログラムの機能定義にない想定外の事象の顕在化）や、ヒューマンエラーがなぜ組み込まれたか、なぜ受入れテスト段階でエラーが摘出されなかったかなどの技術的原因そのものは訴訟の争点になりにくい。
また、
現状では当り前のように使われているシステム技術に、実は限界が表われている問題（印影の転写技術の高度化を駆使した犯罪に、金融機関の本人確認や印鑑照合が裏をかかれるケースなど）に関する裁判でも、犯罪手法が高度化し技術面との齟齬に直接答えられないでいる。法的にその事実が盗用行為で、どのように使われたかの視点で義務や不法行為面からの争点もみられる。
　一方、コンピュータの振る舞いや想定外の事故は、直接目にみえないだけに、文章化を必要とする起訴状や答弁書作成段階で多大な努力を要する。とくに一般顧客が起こす裁判の場合、コンピュータ事故の事実認定が容易ではないことに加えて、顧客は金融機関側のコンピュータ状況がわからないという情報力格差が大きいために、立証段階で困難を極めることが多い。

（注）東京地平16･12･22平成10年(ﾜ）第２３８７１号：請負契約で納入したプログラムの内在する瑕疵は、委託側の仕様問題か、修正作業範囲かが争点となった事件。約五年間の裁判の末、プログラムに欠陥があると認められた。

このページの先頭へ

その２　金融分野のシステム事故とその主要因　　最近のシステム事故

本表は、信頼性が高度に要求されている「銀行系のシステム障害」を中心に抽出したが、傾向は掴め、それなりの対策は実施されている事を願って、この一覧は閉鎖する。以降、行政当局が配出した事案を中心にする。

また、業界横断的な視点とIT事故を予防する視点からのマーケット現状を調査する。Webでの発表はある程度の母数が収集出来てからにする。

このページの先頭へ


その３　金融分野のシステム事故とその主要因　　銀行が係わるIT訴訟

このページの先頭へ

その３：システム事故に係わる金融庁行政指導
　2010/2/12　SBI証券に業務改善命令に合わせ、日本証券業協会に業界全体で事故再発防止に取り組むよう異例の要請を配出。
　2010/2/19　アリコジャパンのカード情報流出に対し、業務改善命令を近日配出予定。内部管理体制の不備を指摘。

このページの先頭へ



　　　ここから「IT's-Preventionの杜」のTopへ
　　　　　　　　　　 Copyright　© 1996-2014 by JA2ANX Naoki Inagaki.  this HP all pages is ISSN 2187-5049