はじめに
2026年11月6日の午後、東海・北陸から西の地域にある128の信用金庫で、窓口やATM、インターネットバンキングなどの取引ができなくなりました。原因は、信用金庫が共同で使う基幹システムの運営拠点「しんきん共同センター（西日本センター）」にある機器の故障と説明されています。サイバー攻撃ではないとのことです。
ここ最近は不正アクセスによる情報漏えいのニュースが続いていましたが、今回は「止まる」タイプの事故です。そして、多くの会社が同じシステムを共同で使っているところで起きました。SaaSやクラウド、業界の共同システムを使う事業会社にとって、他人事ではありません。
この記事では、まず事実関係を整理します。そのうえで、発注側を支援するコンサルタントの立場から、「自社だけでは直せないシステムが止まったときに困らないよう、何を決めておくか」を考えます。
何が起きたのか
信金中央金庫やしんきん共同センターの発表を伝えた報道と、利用している信用金庫のお知らせ（倉吉信用金庫、2026年11月6日）をもとに整理すると、概要は次のとおりです。
- 発生：2026年11月6日（金）午後1時30分ごろ、しんきん共同センター（西日本センター）でオンライン障害が発生した
- 影響範囲：このシステムを使う東海・北陸地区や西日本地区の128信用金庫。東日本の信用金庫は通常どおりだった
- 止まった取引：窓口の端末、振込などの為替、ATM（コンビニATMを含む）、インターネットバンキングなど
- 復旧：同日夕方にATMでの入出金など一部が再開し、午後7時5分にすべての取引ができるようになった。止まっていた時間はおよそ5時間半
- 原因：基幹系システムで使っている機器の故障と説明されている。サイバー攻撃などの外部からの不正アクセスによるものとの報告はなく、詳しい原因は調査中
- 影響の残り：倉吉信用金庫は、遅れていた他の金融機関あての振込は翌営業日の11月9日（月）に入金になると案内している
報道によると、営業店では締めの作業ができず、役職者が復旧まで待機したケースもあったようです。各信用金庫は、信用金庫以外の金融機関を使うよう呼びかけました。
なお、11月7日時点では、故障した機器が何だったのか、予備の機器（冗長構成）があったのか、あったならなぜ切り替わらなかったのかといった点は公表されていません。この記事でも、そこは推測で断定しないようにします。
なぜ「機器の故障」で広い範囲が止まるのか
一般論として、基幹システムの重要な機器は二重化されているのが普通です。それでも大きな停止が起きるのは、次のような理由が多いと感じています。
- 共同化で影響が大きくなる：コストを下げるために多くの組織で1つの基盤を共同で使うと、その基盤の1か所の故障が、全利用者の同時停止につながる
- 「切り替わるはず」が試されていない：予備の機器があっても、実際に切り替える訓練をしていないと、本番で想定どおりに動かないことがある
- ネットワーク機器や記憶装置は見落とされやすい：アプリやサーバーに比べて、通信機器やストレージの故障を想定した手順が薄くなりがち
- 利用者側は「中」が見えない：共同システムやSaaSを使う側は、構成や運用の中身を知らないまま、「止まらないもの」と思い込みやすい
最後の点が、発注側にとって一番大事です。共同利用のシステムでは、構成を自社で選ぶことはできません。できるのは、「どう止まるのか」を事前に知ることと、「止まったときに自社がどう動くか」を決めておくことです。
発注側コンサルタントならこう考える
1. 契約前に「止まり方」を確認する
稼働率の数字だけでなく、次のような点を提供側に確認しておきます。
- 予備の機器や予備の拠点への切り替えは、自動か手動か。切り替えにかかる目安の時間はどれくらいか
- 切り替えの訓練を、どのくらいの頻度で、本番に近い形で行っているか
- 障害が起きたとき、利用者への第一報は何分以内に、どの手段で届くか
SLA（サービスの品質の約束）で押さえるべき数字は、ベンダーとのSLAで何を数値で握っておくべきかの記事でも整理しています。共同利用のシステムでは個社ごとの交渉は難しいことが多いですが、「聞いて記録に残しておく」だけでも、次の判断材料になります。
2. 自社側のBCPに「代わりの手段」を書く
提供側の復旧を待つしかない時間に、自社の業務をどう回すかは、自社にしか決められません。業務ごとに次の3つを決めておきます。
- 止まったら何で代わりにするか：手作業の受付、別の銀行口座や決済手段、紙の記録など
- どれくらい止まったら切り替えるか：「30分で判断、2時間で代わりの手段に切り替え」のように、時間で決める
- 後から何を戻すか：手作業で受け付けた分の入力、締め処理のやり直し、遅れた振込の確認など
今回のように、締めの作業ができず職員が待機するケースは、どの業種でも起こります。「待つ人」と「代わりの手段を動かす人」を分けて決めておくと、現場の混乱が小さくなります。
3. お客さまへの連絡を先に用意する
障害の第一報は、原因がわからない段階で出すことになります。「何が使えないか」「代わりに何が使えるか」「次の連絡はいつか」の3点を入れた文面のひな形を、あらかじめ用意しておきます。今回、各信用金庫は「他の金融機関の利用を」と呼びかけました。代わりの手段を案内できるかどうかで、お客さまの受け止め方は大きく変わります。
4. 障害報告書を「受け取るだけ」にしない
後日、提供側から報告が出たら、発注側として次の点を確認します。
- 直接の原因（どの機器がどう壊れたか）だけでなく、「なぜ予備の仕組みで止まらずに済まなかったのか」まで書かれているか
- 再発防止策に、切り替え訓練や監視の見直しなど、仕組みの変更が入っているか
- 同じ構成の別の拠点や、ほかの機器にも同じ弱点がないか確認したか
報告書を読んで疑問を返すことは、提供側を責めるためではなく、次に止まったときの影響を小さくするためです。
5. 「同じ基盤に頼っているもの」を棚卸しする
自社の業務が、どのSaaS、どのクラウド、どの共同システムに頼っているかを一覧にします。1つの基盤が止まると複数の業務が同時に止まる、という組み合わせが見つかれば、そこがBCPで優先して手当てすべき場所です。情シスが把握していない部門導入のSaaSも、この機会に洗い出しておきたいところです。
明日からできること
- 自社の基幹業務が頼っている外部の共同システム・SaaSを一覧にする
- 主要な提供先に「切り替え方式・訓練の頻度・第一報の時間」を問い合わせて記録する
- 業務ごとに「何で代わりにするか」「何分で切り替えるか」をBCPに書き足す
- 障害時のお客さま・社内向け連絡文のひな形を作る
- 年に1回、提供先が止まった想定で机上訓練をする
まとめ
11月6日の信用金庫の障害は、機器の故障という「どこでも起こりうる原因」で、128の信用金庫の取引が約5時間半止まった事例でした。詳しい原因はまだ調査中ですが、共同で使う仕組みは、効率がよい分、止まったときの影響も一斉に広がります。
発注側にできるのは、提供側の「止まり方」を事前に知ること、そして止まったときの自社の動き方を決めておくことです。「止まらないはず」ではなく「止まったらどうするか」から考える。それが、自分では直せないシステムと付き合うための基本だと考えています。
参考
- 倉吉信用金庫「オンライン障害の復旧について」（2026年11月6日）
- 時事ドットコム「128信金でATM利用できず 西日本地域、システム障害で」（2026年11月6日）
- リスク対策.com「信金のシステム障害、完全復旧＝西日本地域、機器の故障が原因」（2026年11月6日）
- 日本経済新聞「西日本128信金でATM・窓口が一時取引できず 午後7時過ぎに復旧」（2026年11月6日）
- ニッキンONLINE「しんきん共同センターでオンライン障害 東海・西日本などの加盟信金で取引停止」（2026年11月6日）
- ビジネス＋IT（Yahoo!ニュース）「西日本の128信金が6時間近く停止、原因は通信機器の故障 サイバー攻撃ではないと説明」（2026年11月7日）
執筆者プロフィール：SIer（元請け）とITコンサルファーム（発注側支援）、両方の立場でプロジェクトに従事（通算9年）。要件定義からベンダーマネジメントまで一貫して対応し、基幹システム刷新・DX推進プロジェクトに多数従事。
コメント