99% 復旧でも「完全復旧」と言わない理由 #

マネーフォワードが 2026 年 5 月 1 日に公表した GitHub への不正アクセス事件から、ちょうど 1 ヶ月。家計簿アプリ「マネーフォワード ME」やクラウドサービスの 銀行口座連携機能の再開率は 99% を超えた。それでも同社は「完全復旧」とは宣言しない。残った数行の進捗バーが、規制業界における breach recovery の本当のコストを浮かび上がらせている。

「最後の 1%」が動かない構造 #

止まっているのは技術ではなく 手続き だ。マネーフォワードは銀行法上の「電子決済等代行業者」として銀行 API に接続している。各金融機関と個別契約を結び、セキュリティ要件を満たしていることを 銀行側が認めて初めて 連携が再開する。GitHub から流出したソースコードに連携用クレデンシャルが含まれていないか、認証フローの再設計が必要かを、銀行ごとに独立して審査されているわけだ。一行が「OK」と判断しても隣の銀行が「もう少し追加資料を」と返せば、その口座を持つユーザの連携は止まったままになる。

ハッカー目線で見る「規制業界の復旧曲線」 #

インシデント対応訓練で語られる MTTR(平均復旧時間) は、技術的にシステムが動き出すまでの時間しか見ない。だが規制業界では コードが動いた瞬間がゴールではない。今回の件は、ソースコード漏洩というクラシックなサプライチェーン事故が、規制 API 経由のサービスで起きた場合の「動かないテール」を露骨に見せた。

開発者側の教訓もはっきりしている。連携先パートナーごとの審査負担を最小化したければ、(a) ソースコードに顧客クレデンシャルや接続情報を一切埋め込まない、(b) シークレットを Vault などへ完全分離して「リポジトリが流出しても被害ゼロ」を証明できる設計にしておく、(c) インシデント時に各パートナーへ提出する監査エビデンスをテンプレ化しておく — の三点だ。

逆に攻撃者目線では、規制業界の標的はソースコードを抜くだけで 「直接の損害が出る前に長期サービス停止」 を強制できる、という旨味がある。SaaS・フィンテック・医療 IT のような業種は、技術的な被害よりも 規制復旧コストのほうを脅迫材料にされる時代 にもう入っている。