銀行残高は無事なのに、なぜ止めた？マネーフォワード不正アクセスに学ぶサイバー防衛

●この記事のポイント
2026年5月、マネーフォワードのGitHub認証情報が漏洩。ソースコードと370件の個人情報が流出した可能性があり、銀行API連携を即時停止した。本番DBへの侵害はなく、5月12日から順次再開。攻撃者がAIで脆弱性を自動探索する時代に、企業の開発環境（サプライチェーン）が新たな標的となっている実態と防衛策を解説する。

　5月1日、フィンテック大手マネーフォワードが異例の発表を行った。同社グループがシステム開発に使用するソースコード管理サービス「GitHub」の認証情報が漏洩し、第三者による不正アクセスが発生したというものだ。攻撃者はリポジトリ（プログラムの保管庫）にアクセスしてコピーしており、マネーフォワードビジネスカードに関わる370件のカード保持者名（アルファベット）とカード番号下4桁が流出した可能性が確認された。

　ユーザーをもっとも戸惑わせたのは、それに伴う銀行API連携の即時停止だった。「残高照会もできない」「資産管理が止まった」という声がSNSを駆け巡ったが、同社は「本番データベースに格納されたお客さま情報の漏えいや、本件に起因する情報の不正利用等の被害がないことを確認している」と発表した。顧客の資産そのものは無事だったのだ。

　では、なぜ銀行連携を止める必要があったのか。その答えは、攻撃者が何を盗んだかを理解することで初めて腑に落ちる。

●目次

• 「金庫の中身」より「設計図」のほうが価値がある
• 「開発環境のセキュリティ」という構造的盲点
• 「止める」という判断の重さ
• 自社の「設計図」を守るための4つの実践

「金庫の中身」より「設計図」のほうが価値がある

　現代のサイバー攻撃において、攻撃者のターゲットはシフトしている。銀行の金庫に例えるなら、金庫の中身（顧客データ）を直接狙うよりも、金庫の設計図や建物の見取り図（ソースコード）を入手する方が、より多様な攻撃の糸口を与えてくれる。

　設計図を持つ者は、どこにどんな鍵がかかっているか、どこに構造的な弱点があるかを知ることができる。ソースコードがあれば、システムの認証ロジックや外部APIとの接続仕様を解析できる。銀行との連携を止める必要があったのは、「今は直接の被害がなくても、設計図を解析された先に二次攻撃が来るリスクがある」という判断からに他ならない。

　この攻撃を仕掛けたとされるのが、ハッカーグループ「TeamPCP」だ。同グループはGitHubの内部リポジトリ4000件超を窃盗したとダークウェブ上で主張しており、「盗んだデータを500万ドル以上で売却する、合意がなければ全データを公開する」と宣言している。TeamPCPはサプライチェーン攻撃を繰り返しているグループとして知られており、2026年5月末までに日本ではマネーフォワードのほかCAMPFIREでもGitHub経由のインシデントが発生している。

「開発環境のセキュリティ」という構造的盲点

　なぜ認証情報が漏洩し、なぜソースコードのリポジトリに個人情報が含まれていたのか。マネーフォワードは5月3日の第二報で「個人情報の取り扱いを伴うサービスの更新作業を行う過程で、個人情報が含まれたファイルが本来の管理手順から外れ、誤ってGitHub上に保管されていた」と説明した。典型的なヒューマンエラーだ。

　このエラーが生まれる背景に、企業のセキュリティ投資の「非対称性」がある。多くの企業では、顧客データが格納される本番環境には厳格な管理体制が敷かれている一方、開発者が日々コードを書き、プッシュし、レビューし合う開発環境のセキュリティ水準は相対的に低くなりがちだ。開発の速度を優先するあまり、「どこから誰がアクセスしているか」「リポジトリに機密情報が混入していないか」の確認が形骸化しやすい。