期待値で鯨になる

米国株・ETF・投資信託で資産を育てる合理主義投資ブログ。低コストという名の餌で巨大な鯨へ育てる観測日記。

マネフォGitHub流出事件の全貌|銀行だけ止まって証券は平気な謎をユーザーが解説する【2026年6月更新】

2026年5月1日、マネーフォワードがGitHubへの不正アクセスによる情報流出を公表した。

銀行連携が停止し、ビジネスカード情報370件が流出した可能性があるという内容だ。私はマネーフォワードMEにSBI証券・moomoo証券・楽天証券・住信SBIネット銀行・楽天銀行を全部ぶち込んでいるので、他人事ではない。

そして気づいた。銀行は止まっているのに、証券の明細は普通に更新されている。

この非対称さが気持ち悪くて、調べてしまった。

この記事でわかること
① 何が流出したのか(事実の整理)
② なぜ銀行だけ止まって証券は止まらないのか(法律の構造)
③ APIキーとは何で、なぜ危険視されたのか
④ マネーフォワードMEユーザーが今すべきこと

マネーフォワード ロゴ

マネーフォワードGitHub不正アクセス事件とは?何が起きたのか

まず事実を整理する。落ち着け、私。

マネーフォワードはソフトウェア開発にGitHub(コードの保管庫サービス)を使っている。そのGitHubにアクセスするための認証情報が漏えいし、第三者がリポジトリ(ソースコードの格納場所)をまるごとコピーして持ち去った。

設計図ごと盗まれた、という状況だ。

項目 内容
発覚・公表日 2026年5月1日
攻撃の経路 GitHub認証情報が漏えい → 第三者が不正ログイン
流出したもの ソースコード+ビジネスカード情報370件
流出した個人情報 カード保持者名(アルファベット)+カード番号の下4桁
流出していないもの カード番号全桁・有効期限・CVV・本番DB・銀行ログイン情報
現時点の実被害 確認されていない(5月7日時点)

流出した個人情報はグループ会社「マネーフォワードケッサイ」が提供するビジネスカード保持者の370件のみで、一般的な家計簿ユーザーのデータが直接抜かれたわけではない。本番データベースへの侵入も確認されていない。

「370件しか流出してないなら大したことない」は少し待ってほしい。ソースコードの流出は、カード情報の流出とは別次元のリスクがある。それは後述する。

技術者集団としての信頼崩壊|GitHubの扱いも知らないのかという問題

事実関係を整理した上で、少し毒を吐かせてほしい。

今回の問題には、大きく分けて二つの「あり得ない」が存在する。

一つ目は、流出したリポジトリの中にAPIキーやパスワードがハードコードされていたこと。ソースコードに認証情報を直書きするのは、セキュリティの世界では10年以上前から「やってはいけないこと」の筆頭に挙げられている。新卒エンジニアの研修資料にすら載っている禁じ手だ。それを、上場企業のフィンテックサービスがやっていた。

二つ目は、本来リポジトリに入れてはいけないビジネスカード保持者の個人情報ファイルが含まれていたこと。テストや更新作業の過程で紛れ込んだのか、経緯は不明だが、顧客の実データをソースコードと同じ場所に置くという発想自体が、データ管理の基本を理解していないことを示している。

この二つが同時に起きている意味
うっかりミスでは済まない。APIキーのハードコードも、個人情報ファイルの混入も、どちらもやってはいけないと知っていれば防げる凡ミスだ。二つ重なっているということは、組織としてのコードレビューやセキュリティチェックが機能していなかった可能性を示唆する。

マネーフォワードは金融データを扱うフィンテック企業だ。ユーザーが預けているのは家計簿のデータではなく、銀行・証券・クレジットカードへのアクセス権に近い何かだ。そのサービスを支える技術者集団が自分たちのコードとデータを適切に管理できな」という事実は、バグ修正とは次元の違う問題になる。

バグは直せる。レッテルは直せない。「あそこはGitHubの扱いも知らないのか」という評価は、パッチをあてるようには消えない。採用にも、金融機関との提携交渉にも、ジワジワと効いてくる類のダメージだ。

それでも私がマネーフォワードをやめない理由は単純だ。私はビジネスカードの保持者ではないため、今回の個人情報流出の対象外だ。実害がない以上、感情的にサービスを切る合理的な根拠がない。便利なものは便利である。自分が被害者でないときの人間の判断は、だいたいこんなものだ。

銀行連携だけ停止した理由とは?証券は止まらない法的根拠

最初の疑問に戻る。SBI証券も楽天証券も事件後も普通に残高が更新されている。なのに銀行だけ止まっている。技術的に何か違うのか。

結論から言うと、これは技術の問題ではなく法律の問題だ。

銀行連携には改正銀行法上の安全確認義務がある

2018年に施行された改正銀行法によって、マネーフォワードのような家計簿サービスが銀行と連携する場合、電子決済等代行業者として登録し、各銀行と正式な接続契約を結ぶことが義務付けられた。そしてその契約には、セキュリティ事故が発生した際の安全確認プロセスが伴う。

この法律が適用されるのは銀行・信用金庫・信用組合など銀行法の対象機関に限られる。証券会社は銀行法ではなく金融商品取引法の管轄であり、電子決済等代行の規制対象外だ。

要するにこういうことだ
銀行連携 → 改正銀行法の管理下 → 事故発生時に契約に基づく安全確認義務が発生 → 確認完了まで止めなければならない
証券連携 → 金融商品取引法の管轄 → 同様の義務規定なし → 止める法的根拠がない

つまり証券が動いているのは安全だからではない。止める法的トリガーが引かれていないからという可能性が高い。これを知ったとき、少し背筋が伸びた。

証券が動いているのを見て安心していた自分に、少しだけ反省している。法律の管轄が違うだけで、リスクの大小とは別の話だ。

APIキーとは何か?なぜ銀行連携停止につながったのか

もう一つの核心がある。ソースコードが漏れただけで、なぜ銀行連携の停止にまで発展したのか。

ソースコードの中に銀行への合鍵が埋め込まれていた

マネーフォワードが発覚後に取った対応の中に「ソースコードに含まれる各種認証キー・パスワードの無効化と再発行」という一文がある。これが全てを物語っている。

APIキーとは、銀行のシステムに接続するための合鍵だ。本来この合鍵は、ソースコードとは切り離して専用の金庫(シークレット管理サービス)に保管するのが鉄則とされている。ところが今回、その合鍵がソースコードの中に直接書き込まれていた可能性が高い。設計図の中に合鍵を挟んでいたようなもので、設計図を盗まれれば合鍵も一緒に持っていかれる。

APIキーを持った攻撃者は正規ユーザーとして銀行システムにアクセスできる。銀行側は正しい合鍵を持った人間が来れば扉を開ける。だからまず止める以外の選択肢がなかった。

ソースコード流出が怖い本当の理由
カード情報流出は「今すぐ使われるリスク」。ソースコード流出は「システムの弱点を解析されて、将来もっと大きな攻撃に使われるリスク」。フィンテック企業にとって、後者は中長期的に深刻な問題になりうる。

マネーフォワードMEユーザーが今すべき対応方法は?

当事者として整理する。焦りは不要だが、無視も違う。

①二要素認証(MFA)を今すぐ設定する

最優先でやれ。パスワード単体の認証は、認証情報が漏えいした瞬間に無力だ。SMS認証や認証アプリを使ったMFAを有効にすれば、パスワードが漏れても不正ログインのリスクを大幅に下げられる。設定5分でリスクが激減するなら、費用対効果は圧倒的だ。

②ビジネスカード利用者かどうかを確認する

今回の個人情報流出対象は法人向け「マネーフォワードビジネスカード」保持者370件のみ。個人の家計簿ユーザーはほぼ無関係と思っていい。該当する場合は個別メールが届くとされているので、受信ボックスを確認しよう。

③銀行連携の再開は公式アナウンスを待つ

5月7日時点でまだ停止継続中だ。各提携金融機関との安全確認が完了次第、順次再開される予定とのことで、再開状況はサポートサイトで随時更新されている。この機会にCSVの手動インポートを覚えておくと、次回の緊急時に慌てずに済む。私は慌てた。

【2026年6月追記】6月5日をもって、すべての金融機関との口座連携機能の再開が完了した。停止開始から約5週間での全面復旧となる。プレミアムサービス利用者には、停止期間(5月1日〜12日)分として購読期間15日間の延長が適用されている。

銀行連携の再開状況の確認先
マネーフォワード MEサポートサイト内「システム対応中で口座連携が正常に行えていない金融関連サービスの一覧」が随時更新されている。金融機関ごとに再開時期が異なるため、自分が使っている銀行の状況を個別に確認するのが確実だ。

フィンテックサービスの情報集約リスクとは?投資家が知るべき構造問題

私はSBI証券・moomoo証券・楽天証券・住信SBIネット銀行・楽天銀行をマネーフォワードMEに集約している。便利なのは間違いない。ただ今回の事件は、その利便性の裏側にある構造的リスクを可視化した。

フィンテックサービスを使うということは、全資産情報への入口を一箇所に集約するということでもある。その入口を守るセキュリティが揺らいだとき、影響範囲もまた一箇所に集約される。集約している資産の中身は2026年6月のポートフォリオで公開している。

発覚後の対応は素早く、銀行連携停止の判断も電子決済等代行業者としての義務に沿ったものだった。信頼を失ったとまでは言えない水準の対応だ。ただ、信頼を積み上げたとも言い難い。技術的な凡ミスが重なって起きた事件は、対応の速さで帳消しにはならない。

それでも私はやめない。今のところ実害がなく、代替サービスへの移行が手間だからだ。これが合理的判断なのか、単なる面倒くさがりなのかは、自分でも判断がついていない。

まとめ|マネーフォワードGitHub流出事件でユーザーが確認すべきこと

【事件の概要】
・2026年5月1日公表。GitHub認証情報が漏えいし第三者が不正アクセス
・ソースコードとビジネスカード情報370件(氏名+カード番号下4桁)が流出の可能性
・カード番号全桁・有効期限・CVV・本番DB・家計資産情報の漏えいは確認されていない(5月7日時点)

【銀行だけ停止・証券は継続の理由】
・銀行連携は改正銀行法(電子決済等代行業)の規制対象で、安全確認が法的義務
・証券連携は金融商品取引法管轄で同様の義務規定なし
・「証券が安全だから動いている」わけではない点に注意

【APIキーが問題になった理由】
・ソースコード内に銀行連携用の認証キーが直接埋め込まれていた可能性
・APIキーが流出すると攻撃者が正規ユーザーとして銀行システムにアクセスできる
・個人情報ファイルもリポジトリ内に混入しており、データ管理の問題も露呈した

【今すぐやること】
① マネーフォワードに二要素認証(MFA)を設定する
② ビジネスカード利用者かどうかメールで確認する
③ 銀行連携は2026年6月5日に全金融機関で再開完了済み(停止期間約5週間)