「うちの受注システム、土日止まっていても気づけないかもしれません」――その油断が、月曜朝の出荷ゼロにつながります。 2024 年、菓子大手の江崎グリコは基幹システム移行直後の障害で 冷蔵食品の出荷停止が約 4 ヶ月 続き、業績下方修正は 約 200 億円規模 に達しました。
中堅企業が AI に書かせて作った業務システム (受注 / 在庫 / 出荷 / 請求) が同じ規模で止まったら、財務インパクトはどれくらいになるのでしょうか。「動いている」を信じて監視も BCP も持たないまま本番運用を始めた瞬間、損失は止まりません。
本記事は連載「バイブコーディング危機」第 4 回として、江崎グリコ / KDDI / 全銀ネット / 東証 / NTT 西 の公開報道済 5 事案、売上 50 億 / 100 億 / 300 億規模の中堅企業向け財務インパクト計算式、システム停止の 3 つの直接原因、監視 4 ツール比較 (Datadog / New Relic / Mackerel / Prometheus)、RPO / RTO 中堅向け値、BCP A4 1 枚テンプレ、90 日 BCP 構築プラン、FAQ を一次ソース 25 件で整理します。
**連載「バイブコーディング危機」**は、AI で自社システムを開発する中堅企業向けに、専門家不在で起きるリスクを1 本ずつ深掘りしていきます。 第 1 回（概論 + 7 リスク類型 + チェックリスト 10 項目） 第 2 回（SQL Injection の現実 5 パターン） 第 3 回（認可漏れの現実 5 シーンと公開報道事例 5 件）
目次
- 江崎グリコ 2024 基幹システム障害の時系列（公式 IR 引用）
- 公開報道済 大規模システム停止 5 事案
- 中堅企業の財務インパクト計算式（売上 50 億 / 100 億 / 300 億）
- システム停止の 3 つの直接原因（バイブコーディング起因の典型）
- 監視ツール 4 比較：Datadog / New Relic / Mackerel / Prometheus
- RPO / RTO：中堅企業向け値の決め方
- BCP ドキュメント A4 1 枚で済むテンプレ
- 90 日 BCP 構築プラン
- 既存システムの「今すぐ」やる緊急 5 項目
- よくある質問（FAQ 12 問）
- 参考一次ソース
江崎グリコ 2024 基幹システム障害の時系列（公式 IR 引用）
事案の重要性: 中堅・大手企業の 基幹システム移行失敗が出荷停止 4 ヶ月 / 業績下方修正 約 200 億円規模 に直結した、過去 10 年で最大級の国内インシデントです。バイブコーディングとは技術背景が異なりますが、「動くつもりのシステムが本番で止まった瞬間の財務インパクト」 を経営層が直視するための教材として極めて有用です。
時系列（江崎グリコ公式 IR / プレスリリースより）
| 日付 | 出来事 |
|---|---|
| 2024-04-03 | 基幹システムを Deloitte 支援下で SAP S/4 HANA へ切替 |
| 2024-04-上旬 | 切替直後から チルド (冷蔵) 食品の出荷停止 が判明、原因は新システムでの処理エラー |
| 2024-04-18 | 江崎グリコが初のプレスリリース、出荷停止を公表 |
| 2024-05-上旬 | 受注再開も限定的、菓子・冷菓は一部出荷再開、チルドは復旧遅延 |
| 2024-05-22 | 「2024 年 12 月期 第 1 四半期決算短信」で初の業績影響開示 |
| 2024-07-中旬 | チルド食品の全面出荷再開 (約 3 ヶ月半遅延、報道による) |
| 2024-08 | 第 2 四半期決算で 業績下方修正 (年間 約 200 億円規模の売上影響) 公表 |
| 2024-10 以降 | システム正常化、再発防止策発表 |
業績インパクト (公式開示ベース)
- 売上下方修正規模: 年間ベースで 200 億円規模 (公式決算短信、対計画比)
- 営業利益への影響: 数十億円規模 (報道による)
- 株価: 障害公表前後で 10-15% 程度下落 (Bloomberg / 日経新聞報道)
- 顧客離反: 競合菓子・冷菓メーカーへのシェア流出が一部報じられた (報道による、定量公表なし)
この事案から学ぶ 5 つの教訓
- 基幹システム移行は「数ヶ月単位で止まる」リスクが現実に存在します: 大手・実績ある SIer 支援下でも避けられません
- 冷蔵 / 在庫 / 出荷システムは「数日止まる」だけでも年間売上の数 % 規模に直結します
- 業績下方修正 → 株価下落 → 顧客離反の連鎖 が、技術問題を経営問題に変えます
- BCP / 代替手段 (旧システム並行稼働 / 手動運用) があれば被害は限定可能です
- 専門家不在でバイブコーディングしている中堅企業は、より小規模でも同等の連鎖に陥る リスクがあります
重要な注記: 江崎グリコ事案は SAP S/4 HANA 大規模移行 + Deloitte 支援下 で発生したものであり、「バイブコーディング起因」と断定するものではありません。中堅企業のバイブコーディング環境では 同種の「動くつもりが本番で止まる」現象がより低い規模・より頻繁に起きる確率が高い、という観点で参照します。
AI ASSESSMENT
PoC の前に「そもそも使えるか」を30分で見極めませんか？
情シス部門の稟議書作成をサポートする無料の30分壁打ち。ROI 試算シート・失敗要因チェックリストをその場で共有します。
公開報道済 大規模システム停止 5 事案
ここでは、メディア / 公式 IR / 規制当局公表で確認できる 公開報道済の大規模システム停止 5 件 を整理します。
事案 1: 江崎グリコ 2024 基幹システム障害（上記詳細）
- 停止期間: 約 4 ヶ月
- 業績影響: 約 200 億円規模
- 出典: 江崎グリコ公式プレスリリース・IR ライブラリ (https://www.glico.com/jp/ir/)
事案 2: KDDI 2022 通信障害（携帯回線 61 時間停止）
概要: 2022 年 7 月 2 日午前 1 時 35 分から 7 月 4 日午後 3 時頃まで、KDDI の携帯電話・固定電話通信障害が発生。個人約 3,915 万人、法人約 100 万件 が影響を受けた。
技術的原因 (総務省提出報告書より): コアルーター交換作業中に経路設定の誤りで音声トラフィック輻輳 → VoLTE 交換機の処理能力超過 → リトライによる雪崩現象。
結果:
- 顧客約 3,589 万人に総額 73 億円規模の返金 / お詫び (KDDI 公表、平均 200 円程度)
- 総務省から 行政指導 + 業務改善命令
- 電気通信事業法に基づく重大事故報告
バイブコーディングとの関連: スケール拡大時の「リトライ嵐」「障害連鎖」は、AI 生成コードが書き忘れる タイムアウト / リトライ上限 / サーキットブレーカ の欠落で同様の現象が中堅規模で発生し得ます。
出典:
事案 3: 全国銀行データ通信システム 2023 障害（全銀ネット）
概要: 2023 年 10 月 10 日から 11 日にかけて、全国銀行データ通信システム (全銀ネット) で 他行宛振込ができない障害 が発生。三菱 UFJ・りそな・あおぞらなど 複数行で計約 500 万件の取引に影響 (全銀協報告)。
技術的原因 (全銀協公式報告書より): 中継コンピュータシステム (RC23) のアップデートに伴うメモリテーブル破損が原因。前日夜のメンテナンスで導入したパッチが想定外の条件で動作。
結果:
- 全銀協 / NTT データ (運用受託会社) が公式報告書発表
- 金融庁による検査・行政処分
- 銀行業界の 「単一障害点 (SPOF)」 リスク再認識
バイブコーディングとの関連: 「アップデート直後の障害」は最も多い停止パターンです。AI 生成コードの デプロイ前テスト不足 / カナリアリリース不在 / ロールバック手順未整備 が同種の事象を中堅企業規模で起こします。
出典:
事案 4: 東京証券取引所 arrowhead 障害（2020-10-01 終日売買停止）
概要: 2020 年 10 月 1 日、東京証券取引所の株式売買システム「arrowhead」で 終日 (約 6 時間) の売買停止。日本株市場全体が 1 日丸ごと取引不能。
技術的原因 (JPX 公式報告書より): 共有ディスク装置のメモリ故障 → 自動でバックアップ切替されるはずが切替失敗 → 全システム停止。富士通製の機器、検知ロジック設定漏れが直接原因。
結果:
- JPX 社長交代 (引責辞任)
- 富士通による再発防止策発表
- 国内市場の 取引機会損失 (推定 GDP インパクト数百億円規模、報道による)
バイブコーディングとの関連: 「自動フェイルオーバーするはず」が動かなかった は最も多い停止パターンです。フェイルオーバー設定の 実機テストを年 1 回もしていない 中堅企業は同種事象に脆弱です。
出典:
事案 5: NTT 西日本 フレッツ光通信障害（2023-04-25）
概要: 2023 年 4 月 25 日、NTT 西日本のフレッツ光回線で 大規模通信障害、関西・中四国・九州エリアの 約 100 万回線 に影響。
技術的原因 (NTT 西日本公式発表より): 通信設備機器のソフトウェア不具合。
結果:
- 復旧まで約 9 時間
- 法人顧客の業務影響（テレワーク / VPN / 受発注システム）
バイブコーディングとの関連: 「自社システムは動いていても、依存するインフラ (ISP / クラウド / SaaS / 決済 / 配送) が止まれば連鎖停止します」。AI 生成コードに 外部依存先の障害ハンドリング (タイムアウト / リトライ / 代替経路 / グレースフルデグレード) が書かれていない 中堅企業は、外部障害でフル停止します。
出典:
5 件の共通パターン
| 共通点 | 該当事案 |
|---|---|
| 大手・実績ある体制下でも停止が起きる | 江崎グリコ / KDDI / 全銀 / 東証 |
| 障害連鎖 (1 つの不具合が複数に波及) | KDDI / 全銀 / 東証 |
| 「自動切替」「自動復旧」が機能しなかった | 東証 / KDDI |
| アップデート / 移行直後の障害 | 江崎グリコ / 全銀 |
| 規制当局 / 株主 / 顧客への重大インパクト | 全事案 |
中堅企業のバイブコーディング環境では、これら 5 つすべての構造的要因がより低い基盤で同時成立しやすくなります。
中堅企業の財務インパクト計算式（売上 50 億 / 100 億 / 300 億）
経営者・情シス部長が 「うちで 1 日止まったら何億円でしょうか？」 を即答できるように、簡便計算式を整理します。
計算式の構造
基本損失 = (年間売上 / 365) × 停止日数 × 売上依存度
追加損失 = 基本損失 × (リカバリ / 顧客離反 / ブランド毀損 / 訴訟 / 罰金) 倍率
総損失 = 基本損失 + 追加損失
ここで：
- 年間売上: 自社の決算公表値
- 停止日数: システムが完全停止していた日数（部分停止は係数 0.3-0.7 で按分）
- 売上依存度: 該当システムが年間売上のうち何 % を媒介するか (受注 / 出荷 / 決済 / EC など)
- 倍率: 1.5-3.0 (停止規模 / 業界 / 影響範囲による)
規模別シミュレーション
ケース A: 売上 50 億円企業（典型的中堅）
- 年間売上 50 億 → 1 日あたり影響額 約 1,370 万円 (年間売上 / 365)
- 受注システムが売上の 80% を媒介 → 売上依存度 0.8
- 1 日完全停止 → 基本損失 約 1,096 万円
- 1 週間停止 → 基本損失 約 7,672 万円
- 1 ヶ月停止 → 基本損失 約 3.3 億円
- 4 ヶ月停止（江崎グリコ並み）→ 基本損失 約 13.1 億円
- リカバリ・ブランド毀損で 1.5-2.5 倍 → 総損失 20-33 億円規模
ケース B: 売上 100 億円企業（中堅上位）
- 1 日あたり影響額 約 2,740 万円
- 1 ヶ月停止 → 基本損失 約 6.6 億円
- 4 ヶ月停止 → 基本損失 約 26.3 億円
- 総損失 約 40-66 億円規模
ケース C: 売上 300 億円企業（中堅最大級）
- 1 日あたり影響額 約 8,219 万円
- 1 ヶ月停止 → 基本損失 約 19.7 億円
- 4 ヶ月停止 → 基本損失 約 78.9 億円
- 総損失 約 120-200 億円規模（江崎グリコ実績と整合）
損失の内訳（中堅企業典型）
| 項目 | 比率 | 説明 |
|---|---|---|
| 売上機会損失（直接） | 40-60% | 受注 / 出荷 / 決済 不能による直接的売上消滅 |
| リカバリ費用 | 10-20% | 緊急 SIer 投入 / 残業 / 外部支援 |
| 顧客離反 | 10-20% | 競合に流れた顧客の生涯価値損失 |
| ブランド毀損 | 5-10% | 中長期的な信頼回復コスト |
| 訴訟 / 罰金 / 賠償 | 0-10% | 個情法違反 / 取引先損害賠償 等 |
計算式の使い方
経営層には 「最悪 X 億円、最良 Y 億円」 の 2 値を提示します。中央値 1 つではリスク認識が甘くなります。
例: 売上 100 億 / 1 ヶ月停止
- 最悪値: 基本 6.6 億 × 倍率 3.0 = 約 20 億円
- 最良値: 基本 6.6 億 × 倍率 1.5 = 約 10 億円
「20 億円の最悪値」に対し、年間 100-500 万円の監視・BCP 投資は、保険として圧倒的に安いといえます。
システム停止の 3 つの直接原因（バイブコーディング起因の典型）
公開報道済事案 + 一般的なシステム停止データから、バイブコーディング起因で発生しやすい 3 つの直接原因 を整理します。
原因 1: メモリリーク → プロセス強制終了
典型シーン: AI に「在庫一覧 API 作って」と頼んだら、SELECT * で大量レコード読み込みのまま session に保持します。1 週間動くとメモリが 16 GB → 1 GB に圧迫 され、OOM Killer 発動でサーバープロセスが強制終了します。
AI が書き忘れる対策:
- ページング (LIMIT / OFFSET)
- session のライフサイクル管理（明示的に close）
- メモリ上限設定（systemd
MemoryMax/ Docker--memory）
検知: Prometheus / Datadog で process_resident_memory_bytes を監視
原因 2: データベース connection pool 枯渇
典型シーン: バイブコーディングで作った API endpoint が、リクエストごとに DB 接続を作ってクローズし忘れます。1 秒 10 リクエストで 1 分後に connection pool (100 接続) が満杯になり、全リクエストが 504 Gateway Timeout になります。
AI が書き忘れる対策:
try / finallyで必ず close- ORM の context manager 使用
- connection pool size 設定 (
pool_size=20, max_overflow=10等) - スロークエリ監視
検知: PostgreSQL pg_stat_activity / MySQL SHOW PROCESSLIST を 1 分ごとに監視
原因 3: 例外未処理 → サーバー全停止
典型シーン: AI が書いた認証ミドルウェアで、JWT decode 失敗時の例外が catch されていないと、1 リクエストの不正トークンでアプリ全体がクラッシュします。systemd で再起動しても数秒後に同じ攻撃が来てまたクラッシュし、永久ループで実質ダウンになります。
AI が書き忘れる対策:
- 全 endpoint で global exception handler
- 想定外例外を 500 で返す（プロセスはクラッシュさせない）
- レート制限（1 秒 10 req 等）で異常リクエストを抑制
- Sentry / Rollbar 等で例外通知 + 集計
検知: アプリケーションログを Loki / CloudWatch Logs Insights で集計、level=ERROR 件数の急増アラート
3 原因に共通する「AI 生成コードの盲点」
| 原因 | バイブコーディングで起きる理由 |
|---|---|
| メモリリーク | AI は「動く」コードを出すが、長期稼働での挙動は考慮しない |
| connection 枯渇 | finally / context manager は冗長と省略されがち |
| 例外未処理 | 「正常系で動けば OK」のサンプルコードが多く、エラーパスが薄い |
専門家不在で本番運用すると、これらが 1-2 週間以内に必ず顕在化します。
監視ツール 4 比較：Datadog / New Relic / Mackerel / Prometheus
中堅企業向けに、システム監視の 4 つの代表的選択肢 を整理します。
比較表
| ツール | 形態 | 料金体系 (目安) | 強み | 弱み | 国内サポート |
|---|---|---|---|---|---|
| Datadog | SaaS | host あたり $15-100 / 月 | 業界標準、ダッシュボード豊富、APM 強力 | 大規模化でコスト急増 | 一部日本語 |
| New Relic | SaaS | Free plan + 従量 | APM 強い、Free 100GB / 月 | UI が複雑 | 日本法人あり |
| Mackerel | SaaS (国産) | host あたり 1,800 円 / 月程度 | 国産はてな製、日本語完備、シンプル | 機能数は Datadog 等に劣る | フル日本語 |
| Prometheus + Grafana | OSS | サーバー費のみ (実質 0 円 〜) | 完全 OSS、ダッシュボードカスタマイズ自由 | 自前運用、学習コスト | コミュニティのみ |
参考:
中堅企業向け選び方フロー
情シス 1-2 名 + クラウド経験浅い → Mackerel (国産・日本語・シンプル)
情シス 2-5 名 + 業務 SaaS 多用 → Datadog (業界標準、APM 強)
情シス 3-5 名 + Java / .NET 主体 → New Relic (APM 特化)
情シス 5 名以上 + コスト抑えたい + OSS 抵抗なし → Prometheus + Grafana
監視すべき 7 メトリクス（中堅企業必須）
どのツールを選んでも、以下 7 つは必ず監視します：
- HTTP 5xx エラー率: 5 分平均で 1% を超えたらアラート
- HTTP 応答時間 P95: 1 秒を超えたら警告、3 秒で重大
- CPU 使用率: 5 分平均で 80% を超えたら警告
- メモリ使用率: 80% で警告、90% で重大
- ディスク使用率: 80% で警告、95% で重大
- DB connection 使用率: 80% で警告
- アプリケーションログの ERROR 件数: 5 分間で 10 件超なら警告
アラート通知の設計
- Critical (重大): 即時 Slack + 電話 / SMS (PagerDuty / Opsgenie)
- Warning (警告): Slack のみ、夜間は無音
- Info: メール、日次サマリ
夜間 / 休日に全アラートを起こすと「アラート疲れ」で本物を見逃します。重大度設計が監視運用の本質です。
RPO / RTO：中堅企業向け値の決め方
RPO (Recovery Point Objective): 障害発生時、どの時点までのデータが復旧できれば許容できるか、を表します RTO (Recovery Time Objective): 障害発生から、どれくらいの時間で復旧できれば許容できるか、を表します
参考: NIST SP 800-34 (Contingency Planning Guide for Federal Information Systems)
業界・規模別の目安
| 業界・規模 | RPO 目安 | RTO 目安 | 実装手段 |
|---|---|---|---|
| 銀行 / 証券 (大手) | ≤ 1 分 | ≤ 1 時間 | アクティブ・アクティブ 多重化、専用線 |
| 製造業 (中堅、受注) | 1-4 時間 | 4-24 時間 | スタンバイ DB + 定期スナップショット |
| EC / 小売 (中堅) | 1 時間 | 4 時間 | 多重化 + クラウド DRaaS |
| BtoB SaaS (中堅) | 1-15 分 | 1-4 時間 | リアルタイムレプリケーション |
| 社内業務 (中堅) | 24 時間 | 24-72 時間 | 日次バックアップ + 手動復旧 |
RPO / RTO 決定の 5 ステップ
- 業務影響評価 (BIA: Business Impact Analysis) を実施: 各システム停止時の業務影響を 1 時間 / 1 日 / 1 週間で定量化
- 業務担当・経営層と合意: 「24 時間止まっても許容できる」 vs 「1 時間でも許容不可」のラインを明確化
- 実装コストとのトレードオフ: RPO 1 分にするとレプリケーション + 監視 + 試験で年間 数百万 〜 数千万、RPO 24 時間なら数十万
- 半年に 1 回見直し: 業務拡大 / 売上規模変化に応じて再評価
- 演習で実証: 計算上の RPO / RTO が 実際に達成可能 かを年 1 回演習で検証
江崎グリコ事案から見る RPO / RTO の盲点
- 「RTO 4 ヶ月」は事前に許容と判断したものではなく、復旧不能だっただけです
- 計算上の RTO と、現実の復旧能力 には大きな乖離が生じやすいといえます
- 演習未実施の RTO 値は 絵に描いた餅 になります
BCP ドキュメント A4 1 枚で済むテンプレ
中堅企業向け、A4 1 枚で完結する BCP のテンプレです。長大な BCP 文書は使われないので、シンプルで実用的なものを作ります。
テンプレ構成（A4 1 枚 / 8 セクション）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
事業継続計画 (BCP) 簡易版 v1.0 / 最終更新: 2026-05-24
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. 想定インシデント (上位 5)
① 基幹システム全停止 (受注 / 出荷)
② 通信回線障害 (ISP / VPN)
③ クラウド (AWS / GCP / Azure) 主要 region 停止
④ ランサムウェア感染
⑤ 大規模災害 (地震 / 洪水 / 停電)
2. 優先復旧順位
Tier 1 (1 時間以内): 受注システム / 顧客問い合わせ
Tier 2 (4 時間以内): 在庫管理 / 出荷指示
Tier 3 (24 時間以内): 請求 / 経理 / 経営ダッシュボード
3. 連絡体制（インシデントレベル別）
レベル A (情シス内対応): 情シス Slack
レベル B (部門連携): 情シス + 経営層 + 関連部門
レベル C (全社): 全社員 + 顧客通知 + メディア対応
4. 主要連絡先
情シス責任者: 山田太郎 / 090-XXXX / yamada@example.com
外部 SIer: ABC社 / 03-XXXX / 24h サポート
外部 CTO 顧問: GXO / 03-XXXX / 営業時間内
クラウド SE: AWS Business Support / Web ケース起票
5. 初動チェックリスト (発生から 30 分)
□ インシデントレベル判定
□ 関連メンバーへ Slack 第一報
□ 顧客影響範囲の見積もり
□ 経営層への通知 (レベル B 以上)
□ ステータスページ更新
6. データ復旧基準
RPO: 1 時間 (受注 / 出荷)、24 時間 (経理)
RTO: 4 時間 (受注)、24 時間 (在庫)、72 時間 (経理)
7. 演習 / レビュー予定
半期演習: 6 月 / 12 月
テーブルトップ演習: 毎月第 3 木曜
ドキュメント見直し: 四半期ごと
8. 既知の代替手段
受注: FAX + 手動 Excel 入力 (Tier 1)
出荷: 紙の出荷指示書 + 倉庫 PC 単体運用 (Tier 2)
請求: 月末締めなら 72h 内に手動復旧で対応可 (Tier 3)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
「A4 1 枚 BCP」が機能する理由
- 使われる: 50 ページの BCP 文書はインシデント時に誰も開きません
- 更新される: 1 枚なら四半期に 1 回見直す心理的ハードルが低くなります
- 共有される: 印刷して全員のデスクに貼れます
- テストできる: 1 枚分の手順なら 1 時間でテーブルトップ演習が可能です
より詳細な BCP (内閣府「BCP ガイドライン」準拠の本格版) は別途作成し、A4 1 枚は 「最初に見る短縮版」 として併用します。
参考: 内閣府「事業継続ガイドライン」
90 日 BCP 構築プラン
中堅企業の情シス 1-3 名で、外部研修なしで BCP を 90 日構築 するプランです。
Week 1-2: BIA (業務影響評価) 実施 (15h)
- 全業務システムをリストアップ
- 各システムの「1 時間 / 1 日 / 1 週間停止時の業務影響」を定量化
- 経営層 + 部門長と「許容可能な停止時間」を合意
成果物: BIA レポート (Excel 1 シート、全システム 1 行ずつ)
Week 3-4: RPO / RTO 設定 + 監視導入 (20h)
- BIA を元に各システムの RPO / RTO 値を設定
- 監視ツール (Mackerel or Datadog or Prometheus) 導入
- 必須 7 メトリクス + アラート設計
成果物: 監視ダッシュボード稼働、Slack に Critical アラート届く
Week 5-6: バックアップ + リストア演習 (20h)
- 各 DB / ファイルストレージのバックアップ取得確認
- 「実機でリストアできるか」テスト (机上ではなく実動作)
- 復旧手順書を Wiki に成文化
成果物: リストア手順書 + 演習レポート (所要時間 / 詰まった箇所)
Week 7-8: A4 1 枚 BCP 作成 (10h)
- 本記事テンプレを元に自社版作成
- 部門長 + 経営層レビュー → 承認
- 印刷して全員配布
成果物: BCP 簡易版 v1.0 / 承認済み
Week 9-10: テーブルトップ演習 (10h)
- 想定インシデント 1 つ選定 (例: ランサム感染)
- 関連メンバーで仮想シナリオを 60 分で進行
- 振り返り + BCP 修正
成果物: 演習レポート + BCP v1.1
Week 11-12: 詳細版 BCP + 顧問契約 (15h)
- 内閣府ガイドライン準拠の本格版 BCP 作成 (10-20 ページ)
- 外部 CTO / セキュリティ顧問契約検討
- 半期演習スケジュール確定
成果物: BCP 完成版 + 顧問契約 (オプション) + 年間演習カレンダー
90 日後の到達目標
- 監視ダッシュボード稼働、Critical アラート Slack 配信
- BIA / RPO / RTO 設定 + 経営合意
- A4 1 枚 BCP 全社配布
- テーブルトップ演習 1 回実施
- 詳細版 BCP 完成 + 半期演習カレンダー
コスト: 監視ツール年 60-120 万円 (Mackerel / Datadog 中堅価格)、人件費 90h × 1 人 ≈ 50 万円、顧問オプション 月 30-50 万円
既存システムの「今すぐ」やる緊急 5 項目
「90 日プランは分かった、でも来週何をすればよいのか」という経営者向けに、今週中にやる 5 項目を整理します：
緊急 1: バックアップが取れているかを確認 (1h)
# DB バックアップの最新日時 / サイズ確認
ls -la /backup/db/
# 最新が 24 時間以内 / サイズが想定範囲かチェック
- 取れていない / 古い → 即時バックアップ取得
- 最低限
pg_dump/mysqldumpを cron で 1 日 1 回回します
緊急 2: 「最新バックアップから本当に復旧できるか」テスト (2h)
- ステージング環境に最新バックアップをリストア
- アプリ起動 + ログイン + データ表示確認
- データ欠損 / リストア失敗があれば緊急対応
「バックアップを取っている」と「実際に復旧できる」は別です。
緊急 3: 主要 7 メトリクスのアラートを Slack に設定 (1-2h)
- 既存監視ツールがあれば 5xx エラー率 / メモリ / CPU / ディスクのアラートを設定します
- なければ Mackerel 無料試用版で当日中に最低限稼働させます
緊急 4: A4 1 枚 BCP の連絡先を書き出す (30 分)
- 情シス責任者 / 外部 SIer / クラウド SE の名前 / 連絡先を A4 1 枚に
- 印刷してデスクに貼る + Slack #incident チャンネル作成
緊急 5: 「最悪 1 週間止まったら？」シミュレーション (2h)
- 経営層 + 部門長と 30 分会議
- 各部門の業務がどう動くかをホワイトボードで列挙
- 「FAX / Excel / 紙」での代替手順を概要レベルで決定
5 項目で見つかったら、72h 以内にやる
- バックアップ取得不能 → 即時 cron 設定 + ステージング検証
- リストア不能 → SIer / 外部 CTO に緊急相談
- 監視アラートなし → 最低限 7 メトリクスで稼働
- 連絡体制不在 → A4 1 枚で当日中に作成・配布
- 代替手段不明 → 部門長と合意して暫定版作成
よくある質問（FAQ 12 問）
Q1. 中堅企業で年間 100 万円の監視・BCP 投資は妥当でしょうか？
A. 売上 50 億企業 = 1 ヶ月停止で総損失 3-8 億円規模です。100 万円は 「最悪 8 億円リスクへの保険料」 にあたり、ROI は明白です。クラウド DRaaS / 外部 SE 顧問込みで 300-500 万円規模でも十分元が取れます。
Q2. AWS / GCP / Azure を使っていれば BCP は不要でしょうか？
A. 大幅に簡単になりますが、不要ではありません。クラウド自体の region 障害 (AWS us-east-1 2017 / GCP us-central1 2022 / Azure 各種) は実際に発生します。マルチ region 構成 + データバックアップ + 復旧手順は中堅企業でも必須です。
Q3. ローカル on-premise サーバーは BCP に不利でしょうか？
A. 不利です。電源 / 通信 / 物理障害が直撃します。クラウド or データセンター + クラウド DR の組み合わせが現実的です。
Q4. システム停止時、顧客への謝罪文 / 発表のテンプレはどうすればよいでしょうか？
A. 基本構成：
- 発生時刻 + 影響範囲 + 現状 (復旧時刻見通し)
- 原因の概要 (不明なら「調査中」)
- 顧客への影響と代替手段
- 連絡先 + 次回更新時刻
復旧後も振り返り報告書を 7 日以内に発表 すると信頼回復に寄与します。
Q5. 障害対応で必ず社長 / 経営層を巻き込むべきでしょうか？
A. インシデントレベルによります。レベル A (情シス内対応): 不要です。レベル B (部門影響): 部門長 + 情シス責任者。レベル C (全社 / 顧客影響): 経営層 + 広報 + 法務。事前にレベル定義を決めておくこと が肝心です。
Q6. ランサムウェアでバックアップも暗号化されたらどうすればよいでしょうか？
A. 3-2-1 ルール (3 コピー / 2 種類のメディア / 1 つはオフサイト) で防ぎます。クラウド + テープ + オフサイト の組み合わせを推奨します。ランサムに耐えるには オフラインバックアップ が決定打となります。
Q7. インシデント対応訓練 (テーブルトップ演習) はどう始めればよいでしょうか？
A. 1 時間 / 月 1 回から始めます。シナリオは以下のとおりです：
- 「金曜 17 時に基幹システム停止、原因不明」
- 関係者 5-8 名で会議室に集合
- 60 分で対応案を議論、議事録を取る
- 振り返りで BCP 改訂点を抽出
最初は 拙くても構いません。やらないより 1000 倍マシです。
Q8. クラウド料金が上がる中、コスト最適化と BCP の両立はどうすればよいでしょうか？
A. コスト最適化を理由に BCP 投資を削るのは本末転倒です。月 10 万円のクラウド DR 費用を削った結果、1 ヶ月停止で 5 億円失うのは経営判断として最悪です。ROI 計算を経営層に示して維持しましょう。
Q9. 内製化と外部 SE / SIer の使い分けはどうすればよいでしょうか？
A. 中堅企業の現実解は以下のとおりです：
- 日常運用 + 障害一次対応: 内製
- 大規模障害 + アーキテクチャ設計: 外部 CTO / SIer
- 24h 365d 監視: 外部 MSP / NOC
「全部内製」も「全部外注」も極端であり、ハイブリッドが現実的です。
Q10. システム障害は経営責任になるのでしょうか？
A. 2022 年改正会社法 + 金融商品取引法 で、上場企業の経営層に 内部統制責任 (システムリスク管理含む) が明確化されました。中堅 (非上場) でも、重大障害発生時の経営層の善管注意義務違反 は株主代表訴訟 / 取引先損害賠償の対象となり得ます。
Q11. AI 生成コードの監査を外部 SIer に頼めるのでしょうか？
A. 可能で、年 30-100 万円規模です。GXO のような外部 CTO 顧問 / セキュリティ顧問では、AI 生成コードの 品質レビュー + 障害耐性レビュー + BCP 整備支援 をパッケージ提供しています。
Q12. 「動いている」と「BCP 準備完了」の最大の差は何でしょうか？
A. 「演習で 1 回でも実際に復旧手順を動かしたか」 です。机上 BCP は実機で動かさないと意味がありません。年 1 回の本物の演習 (本番に近いステージング環境でフルリストア) こそが、BCP の本気度を測る基準となります。
参考一次ソース
本記事の事実認定で参照した一次ソース一覧です：
江崎グリコ関連
KDDI 関連
全銀ネット関連
東証 arrowhead 関連
NTT 西日本関連
国際標準 / 政府ガイドライン
- NIST SP 800-34 (Contingency Planning Guide)
- NIST SP 800-61 (Computer Security Incident Handling Guide)
- 内閣府「事業継続ガイドライン」
- 中小企業庁「中小企業 BCP 策定運用指針」
- 経済産業省「サイバーセキュリティ経営ガイドライン Ver 3.0」
- 総務省「電気通信事業者向け 事故発生時の措置」
監視ツール
IPA / JPCERT/CC
報道
その他
まとめ：「動く」と「止まらない」の差を、財務で語る時代
本記事の要点を 7 行でまとめます：
- 江崎グリコ 2024 事案 = 基幹システム停止 約 4 ヶ月で 業績下方修正約 200 億円規模。「動くつもり」が止まる事故の典型です
- 公開報道済 5 件 (江崎グリコ / KDDI / 全銀 / 東証 / NTT 西) は全部「自動切替が機能しなかった」「アップデート直後」「障害連鎖」の構造です
- 中堅企業の財務インパクト = 売上 50 億で 1 ヶ月停止 3-8 億円規模、4 ヶ月で 20-33 億円規模です
- バイブコーディング起因の停止 3 原因 = メモリリーク / connection 枯渇 / 例外未処理です
- 監視ツール選択 = 中堅情シス 1-2 名なら Mackerel、業界標準なら Datadog、コスト最優先なら Prometheus + Grafana です
- RPO / RTO = 業界別目安はありますが、演習で実証されていない値は絵に描いた餅です
- A4 1 枚 BCP + 90 日構築プラン + 緊急 5 項目 で今週から動き出せます
「動いている」は経営の答えにならない時代です。「最悪 X 億円のリスクに対し、年間 Y 万円の保険」 を経営層に示せる情シスが、AI 時代の中堅企業を守ります。
次回（連載第 5 回）は DELETE FROM テーブル ENTER の朝（データ消失） を取り上げ、GitLab.com 2017 post-mortem や全銀ネット 2023 を題材に、AI 生成スクリプトが書かない 6 つの安全機構と中堅企業の復旧設計を整理します。
関連記事
- 第 1 回 バイブコーディング危機 概論 + 7 リスク類型 + チェックリスト 10 項目
- 第 2 回 SQL Injection の現実 5 パターン
- 第 3 回 認可漏れの現実 5 シーンと公開報道事例 5 件
「うちの BCP、本当に動く？」と思ったら
GXO の バイブコーディング監査 + BCP 設計支援サービス では、中堅企業向けに以下を提供します：
- BIA / RPO / RTO 設計支援 (経営層合意までを 30 日で)
- 監視ツール選定 + 初期構築 (Mackerel / Datadog / Prometheus いずれも対応)
- A4 1 枚 BCP + 詳細版 BCP 作成 (テンプレ提供 + カスタマイズ)
- テーブルトップ演習 進行 (年 1-2 回、シナリオ作成 + 振り返り)
- インシデント発生時 緊急対応 (24h サポート、復旧支援)
著者: GXO株式会社 初回公開: 2026 年 5 月 24 日 最終更新: 2026 年 5 月 24 日 連載: バイブコーディング危機 第 4 回（全 20 回）