【解説】なぜマネーフォワードは炎上しているのか

2026年5月1日のゴールデンウィーク中、家計管理アプリとして広く知られる「マネーフォワード ME」などを運営する株式会社マネーフォワードが、GitHubへの不正アクセスによる情報流出の可能性を公表した。発表直後からXのタイムラインは騒然となり、「銀行口座が危ない」「すぐ解約する」といった声が相次いだ。なぜこれほどの炎上に発展したのか。批判が広がった構造的な背景を読み解いていく。

5/12 19:00現在以下のAPIが再開しました。(順不同)

• 三井住友銀行【個人口座】
• 三井住友銀行【法人口座】
• 三井住友カード(SMBC ID)
• 三井住友カード(VpassID)
• SMBC信託銀行プレスティア
• SMBCプラチナカード三井住友トラストカード
• 三菱UFJ銀行【法人口座】
• 三菱UFJ銀行【個人口座】
• 西日本シティ銀行【法人口座】
• 西日本シティ銀行【個人口座】
• 鳥取銀行【個人口座】
• 鳥取銀行【法人口座】
• 栃木銀行【法人(個人事業主)口座】
• 西京銀行【法人口座】
• 大分銀行【法人口座】
• 大分銀行【個人口座】
• 横浜信用金庫【法人口座】
• 横浜信用金庫【個人口座】
• 滋賀銀行【法人口座】
• 北海道銀行【法人口座】
• 北海道銀行【個人口座】
• ソニー銀行【個人口座】
• かぞくのおさいふGMOあおぞらネット銀行【法人口座】
• GMOあおぞらネット銀行【個人口座】
• 静岡中央銀行【個人口座】
• 滋賀銀行【個人口座】
• auじぶん銀行【個人口座】
• 栃木銀行【個人口座】
• 中国銀行【法人口座】
• 中国銀行【個人口座】
• 西京銀行【個人口座】
• 住信SBIネット銀行【法人口座】
• 住信SBIネット銀行【個人口座】

https://r.itfis.net/VfHSd

※r.itfisはITFIS公式の短縮URLです。Javascriptが有効の場合のみリダイレクトします。

何が起きたのか

マネーフォワードが公表した内容によれば、同社がソフトウェア開発に利用しているGitHubの認証情報が漏えいし、それを悪用した第三者による不正アクセスが発生した。その結果、GitHubのリポジトリ（プログラムの保管庫）がコピーされ、ソースコードを含む複数のファイルが流出した可能性があるという。

直接的な被害として確認されたのは、マネーフォワードケッサイ株式会社が提供する「マネーフォワード ビジネスカード」に関わる個人情報370件だ。流出した可能性があるのは、カード保持者名（アルファベット表記）とカード番号の下4桁に限定されるとしている。クレジットカード番号の全桁や有効期限、セキュリティコード（CVV）については流出が確認されていないと説明した。

同社はこの事態を受け、マネーフォワード MEおよびマネーフォワード クラウドなどに搭載されている銀行口座連携機能を一時停止した。新規連携・更新・再連携のすべてが停止対象となり、日常的にこの機能を利用していたユーザーには実害が生じた。

その後、5月11日に公表された第二報では、本番データベースの漏えいや侵害は確認されなかったこと、本件に起因する不正利用の被害も現時点では発生していないことが報告されている。ただし銀行口座連携の再開時期は、同日時点でまだ確定していない。

なぜGitHubに個人情報が入っていたのか

多くのユーザーが素朴に感じた疑問が「なぜソースコード管理サービスに個人情報が入っていたのか」という点だ。

マネーフォワードのサポートページに掲載されたFAQによれば、通常はGitHub上のソースコードに個人情報を入力することはないという。しかし今回は、個人情報の取り扱いを伴うサービスの更新作業を進める過程で、個人情報が含まれたファイルが本来の管理手順から外れ、誤ってGitHub上に保管されていたことが原因だとしている。

つまり、設計上の問題ではなく、運用上のミスによってデータが誤って混入したということになる。これは技術的には「ヒューマンエラーによるシークレットリーク」に分類されうる事象だ。ただし同社はその経緯の詳細については記事執筆時点で公表しておらず、調査を継続中としている。

「認証キーの再発行」という一文が火に油を注いだ

炎上の規模を大きくした要因として、第一報に含まれていたある一文が注目されている。

マネーフォワードが5月1日に公表した第一報には、「ソースコードに含まれる各種認証キー・パスワードの無効化と再発行の実施（概ね完了）」という記述があった。

この一文自体の対応内容は、セキュリティインシデントの文脈では標準的なものだ。認証情報が漏えいした可能性がある場合、それを速やかに無効化して再発行するのは適切な手順といえる。しかし、この記述を読んだエンジニアや情報セキュリティに詳しい読者の一部は、別の問題を読み取った。

ソースコードの中に認証キーやパスワードが含まれていたということは、いわゆる「クレデンシャルのハードコーディング」が行われていた可能性を示唆するからだ。ハードコーディングとは、本来は環境変数や専用の秘密管理システムで管理すべき認証情報を、ソースコード中に直接埋め込んでしまう実装手法を指す。これはセキュリティの基本的なルールとして避けるべきとされており、特に金融サービスを運営する企業としては問題視されやすい指摘だ。

もっとも、マネーフォワードはこの点について詳細な説明を公開していない。そのため「ハードコーディングがあった」と断定できる情報はなく、あくまでも疑念が先行した形だ。しかし事実として、この記述がきっかけで「管理が甘かったのではないか」という評価へと世論が傾き、単なるセキュリティ事故の報告が「やるべきことをやっていなかった」という批判に変わっていった。

金融情報を扱う企業だからこそ信頼の毀損が大きい

炎上の背景には、マネーフォワードというサービスの特性そのものが深く関わっている。

マネーフォワード MEは、銀行口座・証券口座・クレジットカード・ローンなど、あらゆる金融情報を一箇所に集約して管理するサービスだ。家計を「見える化」する利便性の高さから国内で広く普及しており、ユーザー数は数百万規模に及ぶ。このサービスの本質は、ユーザーが自身の最も重要なプライバシーデータの一つである金融情報を、企業に「丸ごと預ける」という信頼関係の上に成り立っている。

その信頼の根幹を担う会社がGitHubへの不正アクセスを受けたという事実は、多くのユーザーに根本的な不安をもたらした。第一報に「本番データベースからの情報漏えいは確認されていない」と明記されていたにもかかわらず、「自分の口座が抜かれたのではないか」と感じたユーザーが相次いだのは、サービスの性質ゆえの反応といえる。

加えて、銀行口座連携機能の一時停止という措置は、ユーザーにとってはサービスが事実上使えなくなるという直接的な影響をもたらした。利便性を信じてサービスを利用してきたユーザーが、突然その機能を失うという体験は、怒りや不安を可視化させやすい。

対応の評価は二分

一方で、マネーフォワードの初動対応を一定程度評価する見方もある。

ゴールデンウィーク中の金曜日夕方に発覚し、同日中に公式発表・銀行連携停止・認証情報の無効化という複数の対応を実行したことは、かつての日本企業のインシデント対応と比較すれば、速度面では評価できるという意見が情報セキュリティ関係者の間から出た。過去には、セキュリティインシデントを数か月間公表しないまま、外部から指摘されて初めて認めるという事例が国内外に多数存在する。その文脈で見れば、同日中に開示したこと自体は最低限の水準を満たしているという判断もある。

しかしこうした「擁護」的な意見は、Xでは大きな反響を呼ばなかった。怒りや不安を含む投稿のほうがエンゲージメントを集めやすいSNSの構造上、冷静な評価は埋もれやすく、批判的な声が増幅されやすい環境があった。

また、「迅速な対応は評価できるが、ソースコードに個人情報が入っていたという構造的な問題は別の話だ」という整理をするアカウントが多くの共感を集めたことも注目に値する。つまり対応の速さへの評価と、そもそもの管理体制への批判は別々に論じられるべきだという観点だ。これは炎上の感情的な側面と、技術的・組織的な問題提起を区別して考える上で重要な視点といえる。

現代のSaaSに内在するリスク構造

今回の事件を単なる管理ミスとして片付けることには限界がある。現代のデジタルサービスが抱えるリスク構造の問題として捉える視点も重要だ。

GitHubを使ったソースコード管理は、今日のほぼすべてのソフトウェア企業が採用している標準的な開発手法だ。マネーフォワードに限らず、あらゆるSaaS企業がGitHub、AWS、各種外部APIなど、複数の外部サービスに依存して成り立っている。ユーザーはその会社と直接契約しているが、実際にはその背後に連なる数多くの外部サービスのセキュリティにも依存している。

GitHubのリポジトリを標的にした認証情報のスキャン攻撃は、今に始まったことではなく、常態化した脅威として以前から存在していた。過去の調査ではGitHub上に年間数百万件規模の認証情報が誤ってコミットされているという報告もあり、マネーフォワードの事案はこうした攻撃の波のなかで発生した事例の一つとも解釈できる。

ただしそうした業界構造の問題をもってしても、金融情報という高度にセンシティブなデータを預かる事業者としての責任が軽減されるわけではない。特に本件では、個人情報が通常あるべき管理手順を外れてGitHub上に保管されていたという運用上の問題が明確に存在しており、その点についての説明と再発防止策の具体化が、ユーザーの信頼回復には不可欠だ。

今後の焦点

記事執筆時点（2026年5月12日）において、マネーフォワードの調査は継続中だ。銀行口座連携の再開時期は未定で、GitHubリポジトリに含まれていた個人情報の全容も引き続き調査されている。

今後の焦点は大きく三点に絞られる。まず、GitHubリポジトリへの侵入を許した認証情報漏えいの具体的な経路が明らかになるかどうか。次に、ソースコードに認証情報が含まれていた経緯と、それがハードコーディングによるものかどうかの説明があるかどうか。そして、銀行口座連携という主要機能の再開がいつ実現し、その際にどの程度の再発防止策が示されるかだ。

マネーフォワードに対する信頼の回復は、今後の続報の質と頻度にかかっているといえる。炎上の熱量と、実際のリスクの大きさを冷静に区別しながら、続く情報開示を注視する姿勢が求められる。

2026年5月1日のゴールデンウィーク中、家計管理アプリとして広く知られる「マネーフォワード ME」などを運営する株式会社マネーフォワードが、GitHubへの不正アクセスによる情報流出の可能性を公表した。発表直後からXのタイムラインは騒然となり、「銀行口座が危ない」「すぐ解約する」といった声が相次いだ。なぜこれほどの炎上に発展したのか。事件の概要を整理しながら、批判が広がった構造的な背景を読み解いていく。

何が起きたのか

マネーフォワードが公表した内容によれば、同社がソフトウェア開発に利用しているGitHubの認証情報が漏えいし、それを悪用した第三者による不正アクセスが発生した。その結果、GitHubのリポジトリ（プログラムの保管庫）がコピーされ、ソースコードを含む複数のファイルが流出した可能性があるという。

直接的な被害として確認されたのは、マネーフォワードケッサイ株式会社が提供する「マネーフォワード ビジネスカード」に関わる個人情報370件だ。流出した可能性があるのは、カード保持者名（アルファベット表記）とカード番号の下4桁に限定されるとしている。クレジットカード番号の全桁や有効期限、セキュリティコード（CVV）については流出が確認されていないと説明した。

同社はこの事態を受け、マネーフォワード MEおよびマネーフォワード クラウドなどに搭載されている銀行口座連携機能を一時停止した。新規連携・更新・再連携のすべてが停止対象となり、日常的にこの機能を利用していたユーザーには実害が生じた。

その後、5月11日に公表された第二報では、本番データベースの漏えいや侵害は確認されなかったこと、本件に起因する不正利用の被害も現時点では発生していないことが報告されている。ただし銀行口座連携の再開時期は、同日時点でまだ確定していない。

なぜGitHubに個人情報が入っていたのか

多くのユーザーが素朴に感じた疑問が「なぜソースコード管理サービスに個人情報が入っていたのか」という点だ。

マネーフォワードのサポートページに掲載されたFAQによれば、通常はGitHub上のソースコードに個人情報を入力することはないという。しかし今回は、個人情報の取り扱いを伴うサービスの更新作業を進める過程で、個人情報が含まれたファイルが本来の管理手順から外れ、誤ってGitHub上に保管されていたことが原因だとしている。

つまり、設計上の問題ではなく、運用上のミスによってデータが誤って混入したということになる。これは技術的には「ヒューマンエラーによるシークレットリーク」に分類されうる事象だ。ただし同社はその経緯の詳細については記事執筆時点で公表しておらず、調査を継続中としている。

「認証キーの再発行」という一文が火に油を注いだ

炎上の規模を大きくした要因として、第一報に含まれていたある一文が注目されている。

マネーフォワードが5月1日に公表した第一報には、「ソースコードに含まれる各種認証キー・パスワードの無効化と再発行の実施（概ね完了）」という記述があった。

この一文自体の対応内容は、セキュリティインシデントの文脈では標準的なものだ。認証情報が漏えいした可能性がある場合、それを速やかに無効化して再発行するのは適切な手順といえる。しかし、この記述を読んだエンジニアや情報セキュリティに詳しい読者の一部は、別の問題を読み取った。

ソースコードの中に認証キーやパスワードが含まれていたということは、いわゆる「クレデンシャルのハードコーディング」が行われていた可能性を示唆するからだ。ハードコーディングとは、本来は環境変数や専用の秘密管理システムで管理すべき認証情報を、ソースコード中に直接埋め込んでしまう実装手法を指す。これはセキュリティの基本的なルールとして避けるべきとされており、特に金融サービスを運営する企業としては問題視されやすい指摘だ。

もっとも、マネーフォワードはこの点について詳細な説明を公開していない。そのため「ハードコーディングがあった」と断定できる情報はなく、あくまでも疑念が先行した形だ。しかし事実として、この記述がきっかけで「管理が甘かったのではないか」という評価へと世論が傾き、単なるセキュリティ事故の報告が「やるべきことをやっていなかった」という批判に変わっていった。

金融情報を扱う企業だからこそ信頼の毀損が大きい

炎上の背景には、マネーフォワードというサービスの特性そのものが深く関わっている。

マネーフォワード MEは、銀行口座・証券口座・クレジットカード・ローンなど、あらゆる金融情報を一箇所に集約して管理するサービスだ。家計を「見える化」する利便性の高さから国内で広く普及しており、ユーザー数は数百万規模に及ぶ。このサービスの本質は、ユーザーが自身の最も重要なプライバシーデータの一つである金融情報を、企業に「丸ごと預ける」という信頼関係の上に成り立っている。

その信頼の根幹を担う会社がGitHubへの不正アクセスを受けたという事実は、多くのユーザーに根本的な不安をもたらした。第一報に「本番データベースからの情報漏えいは確認されていない」と明記されていたにもかかわらず、「自分の口座が抜かれたのではないか」と感じたユーザーが相次いだのは、サービスの性質ゆえの反応といえる。

加えて、銀行口座連携機能の一時停止という措置は、ユーザーにとってはサービスが事実上使えなくなるという直接的な影響をもたらした。利便性を信じてサービスを利用してきたユーザーが、突然その機能を失うという体験は、怒りや不安を可視化させやすい。

一方で、マネーフォワードの初動対応を一定程度評価する見方もある。

ゴールデンウィーク中の金曜日夕方に発覚し、同日中に公式発表・銀行連携停止・認証情報の無効化という複数の対応を実行したことは、かつての日本企業のインシデント対応と比較すれば、速度面では評価できるという意見が情報セキュリティ関係者の間から出た。過去には、セキュリティインシデントを数か月間公表しないまま、外部から指摘されて初めて認めるという事例が国内外に多数存在する。その文脈で見れば、同日中に開示したこと自体は最低限の水準を満たしているという判断もある。

しかしこうした「擁護」的な意見は、Xでは大きな反響を呼ばなかった。怒りや不安を含む投稿のほうがエンゲージメントを集めやすいSNSの構造上、冷静な評価は埋もれやすく、批判的な声が増幅されやすい環境があった。

また、「迅速な対応は評価できるが、ソースコードに個人情報が入っていたという構造的な問題は別の話だ」という整理をするアカウントが多くの共感を集めたことも注目に値する。つまり対応の速さへの評価と、そもそもの管理体制への批判は別々に論じられるべきだという観点だ。これは炎上の感情的な側面と、技術的・組織的な問題提起を区別して考える上で重要な視点といえる。

現代のSaaSに内在するリスク構造

今回の事件を単なる管理ミスとして片付けることには限界がある。現代のデジタルサービスが抱えるリスク構造の問題として捉える視点も重要だ。

GitHubを使ったソースコード管理は、今日のほぼすべてのソフトウェア企業が採用している標準的な開発手法だ。マネーフォワードに限らず、あらゆるSaaS企業がGitHub、AWS、各種外部APIなど、複数の外部サービスに依存して成り立っている。ユーザーはその会社と直接契約しているが、実際にはその背後に連なる数多くの外部サービスのセキュリティにも依存している。

GitHubのリポジトリを標的にした認証情報のスキャン攻撃は、今に始まったことではなく、常態化した脅威として以前から存在していた。過去の調査ではGitHub上に年間数百万件規模の認証情報が誤ってコミットされているという報告もあり、マネーフォワードの事案はこうした攻撃の波のなかで発生した事例の一つとも解釈できる。

ただしそうした業界構造の問題をもってしても、金融情報という高度にセンシティブなデータを預かる事業者としての責任が軽減されるわけではない。特に本件では、個人情報が通常あるべき管理手順を外れてGitHub上に保管されていたという運用上の問題が明確に存在しており、その点についての説明と再発防止策の具体化が、ユーザーの信頼回復には不可欠だ。

マネーフォワードの調査は継続中だ。銀行口座連携の再開時期は未定で、GitHubリポジトリに含まれていた個人情報の全容も引き続き調査されている。

今後の焦点は大きく三点に絞られる。まず、GitHubリポジトリへの侵入を許した認証情報漏えいの具体的な経路が明らかになるかどうか。次に、ソースコードに認証情報が含まれていた経緯と、それがハードコーディングによるものかどうかの説明があるかどうか。そして、銀行口座連携という主要機能の再開がいつ実現し、その際にどの程度の再発防止策が示されるかだ。

マネーフォワードに対する信頼の回復は、今後の続報の質と頻度にかかっているといえる。炎上の熱量と、実際のリスクの大きさを冷静に区別しながら、続く情報開示を注視する姿勢が求められる。

https://corp.moneyforward.com/news/info/20260501-mf-press-1
https://corp.moneyforward.com/news/info/20260511-mf-press-1