SBI証券は2026年10月14日、FXの株券担保サービスでシステム障害が起き、779口座で本来は不要だったロスカット(強制決済)が執行されたと公表しました。担保として預かる有価証券の評価額が反映されず、預けた保証金が実際より少なく計算されたことが原因です。外部からの不正アクセスではなく、個人情報や資産情報の流出も起きていないとしています。
情シスの視点で見ると、この事故は「委託先のさらに先で起きた作業ミスを、システムで検知して止められなかった」という、他社にも通じる教訓を含みます。公式発表から、起きたことと学べることを整理します。
何が起きたのか
障害が起きたのは「FX株券担保サービス」です。FX(外国為替証拠金取引)の担保として株式などを預けられる仕組みで、その担保の評価額(代用評価額)が、2026年10月12日の取引開始時から反映されなくなりました。
評価額が反映されないと、保証金が実際より少なく見えます。その結果、一部の口座で「保証金が足りない」と誤って判定され、本来は決済されるはずのなかったポジションが強制的に決済(ロスカット)されました。影響は779口座です。復旧は10月13日の午前4時から5時30分の臨時メンテナンスで行われ、評価額が正しく反映される状態に戻されました。
SBI証券の誤ロスカットの経緯・原因と情シスの学び(編集部作成)作成: 編集部 / もとの資料: 情シスのミカタ編集部
なぜ起き、なぜ検知できなかったのか
SBI証券は、FXサービスのシステム運営をSBIリクイディティ・マーケットに委託し、その運用業務の一部は、さらに外部の株式会社インターネットイニシアティブ(IIJ)に再委託していました。公式発表によると、直接の原因は、この再委託先の運用担当者による作業の誤りでした。
2026年10月10日未明、担保の評価に使うファイルの到着が予定より遅れた際、担当者が別の処理と取り違え、本来やり直すべき取り込みをやり直しませんでした。そのため、担保の情報と株価の終値の情報が取り込まれず、評価額が反映されない状態になりました。これらのファイルは同日1時25分までに配置されており、正しい手順で再実行していれば取り込めたとされています。
見逃せないのは、検知の仕組みがなかった点です。SBI証券は、処理に必要なファイルがすべて揃っていることを確認しないまま後続の処理が進む設計・運用だったため、作業の誤りが起きてもこれを検知して止められなかった、と説明しています。
影響する会社・しない会社
直接の影響を受けたのは、SBI証券のFX株券担保サービスを使い、誤ってロスカットされた779口座の利用者です。SBI証券は、意向を確認したうえで、障害がなかった場合の状態に戻すこと(ポジションの復元)を基本に対応するとしています。誤ロスカット後に取引・入出金・振替指示をしていない407口座は復元済みで、その後に取引などをした372口座などは個別に対応しています。
一方、情シスの教訓として「自社に関わる」のは、ITの運用を外部に委託している会社や、バッチ処理・データ連携で自動処理を回している会社です。委託の有無にかかわらず、前提となるファイルやデータが揃う前に次の処理が進む作りになっていれば、同じ落とし穴があります。逆に、今回の金融特有の仕組み(代用評価額やロスカット)そのものは、多くの一般企業には直接は関係しません。関係するのは「手順の誤りを検知して止められるか」という、処理設計の一般的な論点です。
情シスが今日やること
- 委託先・再委託先の確認: 自社の重要な処理を委託している場合、その先(再委託先)まで含めて、作業手順が明文化され、守られているかを確かめます。契約や委託先管理の範囲に、再委託先が入っているかも点検します
- 前提チェックの有無: 自社やベンダーのバッチ処理・データ連携で、「必要な入力ファイルやデータがすべて揃ってから次へ進む」確認が組み込まれているかを確かめます。揃っていなければ処理を止める作りが基本です
- 異常の検知と通知: 想定外の状態(ファイル不足、件数の急変など)を検知して、処理を止める・担当へ知らせる仕組みがあるかを確認します
- 復旧と連絡の段取り: 障害時に、影響範囲の特定、暫定の停止、利用者への案内までの段取りを、あらかじめ決めておきます。SBI証券も再発防止策として、委託先管理の強化と、障害時の情報提供体制の整備を挙げています
委託していても、最終的に説明責任を負うのは自社です。「誰がやるか」だけでなく「誤っても止まる仕組みがあるか」まで、委託の先を確かめておくことが、同じ事故を防ぐ近道になります。
