マネーフォワード6.3万人分の情報流出、原因はGitHubに置いた個人情報

家計簿アプリ「マネーフォワード ME」や会計ソフト「マネーフォワード クラウド」で知られるマネーフォワードが、最大6万2901人分の個人情報が流出した可能性があると2026年6月23日に発表しました。5月1日に公表したソースコード管理サービス「GitHub（ギットハブ）」への不正アクセスについて、調査が完了し、流出の規模が確定したものです。

ただし、この一件でいちばん大事なのは数字よりも「どこが破られ、どこは守られたか」です。攻撃者が入ったのは、利用者の家計簿や会計データが入っている本番のシステムではありません。開発で使うソースコードの保管場所（GitHubのリポジトリ）でした。本番のデータベースへの侵入はなく、お金が動いたり家計簿が覗かれたりといった二次被害も確認されていません。それでも個人情報が漏れたのは、本来そこに置いてはいけない個人情報が、手違いでソースコードと一緒に置かれていたからです。

「玄関と金庫はしっかり守っていたのに、裏口の物置に大事な書類のコピーを置きっぱなしにしていた」。今回の構造を一言でいえばそうなります。本記事では、何がどれだけ漏れたのか、そしてどんな穴を突かれたのかを一次情報で整理し、同じ失敗を避けるために開発の現場が何をすべきかまで掘り下げます。マネーフォワードに関する今後の続報も、この記事に追記して追いかけます。

何が、どれだけ流出した可能性があるのか

6月23日の調査完了で確定した「流出した可能性のある個人データ」は、合計6万2901人分です。多くを占めるのは、利用者を社内で区別するための管理番号で、ログインに使うIDやパスワードとは別物です。内訳は次の通りです。

数のうえでは管理番号（6万449人分）が大半ですが、これはそれ単体では個人を特定できない社内用の番号とされています。一方で、従業員2300人分には氏名・メール・電話まで含まれ、こちらのほうが内容としては重い情報です。ビジネスカードについては、カード番号の全桁・有効期限・セキュリティコードは含まれておらず、保持者名（アルファベット）と下4桁にとどまります。つまり「カードがすぐ不正利用される」たぐいの漏れ方ではありません。

突かれたのは「ソフトの欠陥」ではなく「開発のプロセス」だった

気になるのは「どんな脆弱性を突かれたのか」です。結論から言うと、今回は世間でよく聞くソフトウェアの欠陥（CVE番号が付くような穴）ではありません。突かれたのは、人とプロセスの隙でした。順に見ていきます。

① 入口：GitHubの認証情報が漏れた

発端は、マネーフォワードがソフト開発で使っていたGitHubの認証情報（ログインのための鍵）が漏れたことです。第三者がこの鍵を悪用してリポジトリ（ソースコードの保管場所）に入り込み、中身をコピーしました。GitHubは世界中の開発者が使うソースコード管理サービスで、ここに会社のコードの正本が集まります。その鍵が外に出れば、コードごと持ち去られます。

② 被害を広げた原因：個人情報がソースコードに紛れ込んでいた

鍵が漏れてコードがコピーされただけなら、被害は「ソースコードの流出」で済んだはずでした。ところが、本来は置いてはいけない個人情報を含むファイルが、正規の管理手順から外れて誤ってGitHub上に保管されていたのです。マネーフォワード自身も、なぜGitHubに個人情報が含まれていたのかを5月の段階で説明しています。つまり「ソースコードの流出」が「個人情報の流出」に化けたのは、この混入があったからです。

③ 防げたはずの一線：無料の検知機能が使われていなかった

セキュリティに詳しいエンジニアからは、GitHubが無料で提供する「Secret Scanning（シークレット・スキャニング）」——鍵やパスワードがうっかりコードに混じっていないかを自動で見張る機能——が有効化されていなかった、という指摘が出ています。テストに使うデータは必ず匿名化・マスキングする、機微なファイルは .gitignore で最初から対象外にする、といった基本も徹底されていれば、混入そのものを防げた可能性があります。派手なゼロデイ攻撃ではなく、地味だが最も多い「秘密情報とPIIをうっかりソースに置く」事故——それが今回の正体です。

同じ構図は、当サイトでも繰り返し見てきました。阿波銀行が放置されたテスト環境から2万7千件を漏らした件は、まさに「開発・テスト側に置いた顧客データが守りの外にあった」例です。認証サーバーから秘密鍵が露出したCloud Foundryの件や、Claude Codeのソースコード51万行が流出した件とも、「コードや鍵の管理がそのまま被害の大きさを決める」という点で地続きです。

なぜ「本番は無事」なのに情報が流出したのか

ここからは事実をふまえた筆者の見方です。今回いちばん示唆的なのは、守りの重心が本番環境に寄っていて、開発環境が手薄だったという構造です。

多くの会社は、利用者のデータが入っている本番システムをいちばん厳重に守ります。ファイアウォール、多要素認証、監視——お金や個人情報に直結するからです。マネーフォワードもそこは守り切り、本番データベースへの侵入は起きませんでした。ところが、攻撃者が選んだのは正面の金庫ではなく、開発という"裏側"でした。ソースコードの保管場所は、本番ほど厳重に見張られていないことが多く、そこに個人情報が紛れていれば、本番を一切触らずに情報を持ち去れてしまいます。

設備工事の世界に「天井裏の配管」という言葉があります。普段は誰も見ない、表からは見えない部分です。見えないからこそ手を抜くと、10年後に水漏れの原因になる。ソフト開発のソースコード管理は、まさにこの天井裏です。本番という"表"を磨くだけでなく、開発という"裏"に何が通っているかを把握できているか——今回の件は、その一点を多くの企業に突きつけています。家計簿から企業会計までを一手に預かるマネーフォワードのような会社であればなおさら、裏側の整備は本番と同じ重さで問われます。

これまでの経緯（時系列）

5月1日の第一報から、6月23日の規模確定までの流れを整理します。カードは左右に切り替えられます。

← スワイプで移動

いま分かっていること・まだ分からないこと

マネーフォワードの利用者が、いまやるべきこと

まず落ち着いて受け止めて大丈夫です。本番データベースは侵害されておらず、家計簿データや銀行口座、ログイン用のパスワードが盗まれたという発表ではありません。とはいえ、念のための備えはしておく価値があります。

開発の現場が学べること——同じ穴を塞ぐ実践

今回の本質は「秘密情報やPII（個人を特定できる情報）が、うっかりソースコード管理に紛れ込む」事故です。これは特定の1社の話ではなく、ソフトを作るあらゆる組織で起こり得ます。再発を防ぐために効く対策を、優先度の高い順に挙げます。

依存パッケージやソースコード管理まわりのリスクを継続的に洗い出す仕組みを持っておくと、こうした「開発の裏側」の穴に素早く気づけます。当サイトでもOSSのサプライチェーンを点検する仕組みを整理しています。GitHub経由の侵害という意味では、外部委託先から侵入されたCrunchyrollの680万人流出や、プロバイダ各社へ波及したKDDIのメール最大1422万件漏えいとも、「自社の本丸の外側にある弱点が突かれる」という共通点があります。

よくある質問

マネーフォワード インシデント年表

本記事は、マネーフォワードに関するセキュリティ・サービス関連のインシデントを継続して追う記事です。新たな動きがあれば、ここに追記していきます。

参照元

• ・マネーフォワード公式 - 『GitHub』への不正アクセス発生に関するお知らせとお詫び（第一報）
• ・マネーフォワード公式 - 調査進捗および銀行口座連携再開に向けた経過のご報告（第二報）
• ・ITmedia NEWS - マネフォへの不正アクセス、約6.3万件流出した可能性 調査完了で規模確定
• ・ITmedia NEWS - マネーフォワード「なぜGitHubに個人情報が含まれていたか」を説明
• ・INTERNET Watch - 新たに顧客や従業員の個人データ流出の可能性を確認、調査を完了
• ・時事通信（Yahoo!ニュース）- マネーフォワード、約6.3万人分の情報流出
• ・マネーフォワード ME サポート - 銀行口座連携の一時停止・順次再開のお知らせ