マネーフォワード不正アクセスの全貌と、渦中のQ2決算を読む

「うちもマネーフォワードを使っているけれど、大丈夫なのだろうか」。 2026年5月に起きた不正アクセスのニュースを見て、そう感じたかもしれません。 実際、銀行の明細が取得できなくなるなどの影響が出ました。 しかし、結局何が漏れて、何が守られたのでしょうか。 不安なまま今に至るという方も多いはずです。

6月23日の詳細調査完了と、7月13日の第2四半期決算の開示により、事件の実態と業績への影響が事実として確認できるタイミングになりました。 本番データベースは無事だったのか。 そして、インシデントの渦中で会社はどう動いたのか。 事件の実態と決算の数字を重ねて読むことで、クラウド会計との付き合い方を整理します。

結局、何が漏れて何が守られたのか

設計図の金庫と本番データの違い

2026年5月1日の夕方、マネーフォワードは**GitHub**への不正アクセスを公表しました。 GitHubとは、世界中の開発会社が使っているソースコードの保管庫サービスです。 ソフトウェアの設計図をしまっておく金庫だと考えてください。 漏れたのはこの金庫の鍵であり、第三者に設計図の束をコピーされました。 公表と同時に、不正アクセスに使われた認証情報の無効化、ソースコード内のキーやパスワードの全面的な再発行が行われています。 金融機関とのAPI連携も一時停止され、警察と個人情報保護委員会への報告も済ませていました。 連携停止によって銀行明細が取れなくなり、実害を感じた利用者も多かったはずです。

ここで気になるのは、顧客データまで見られたのではないかという疑念でしょう。 しかし、GitHubにあるのはあくまで設計図であり、顧客データが入っている本番データベースとは別の場所です。 銀行に例えるなら、金庫室の図面が見られたのであって、金庫室そのものが開いたわけではありません。

370件の流出可能性と、守られた認証情報

とはいえ、設計図の中に大事なものを挟んでいなかったか。 6月23日に発表された詳細調査の完了報告が、その答えです。 漏れた可能性があるのは、マネーフォワード ビジネスカードの利用者370件に関する「カード保持者名のアルファベット表記」と「カード番号の下4桁」でした。 該当する370件については、すでに個別に連絡が行われています。 原因は外部からの高度な攻撃ではありません。 サービスの更新作業中に、個人情報を含むファイルが本来の管理手順から外れ、誤ってGitHub上に保管されていたという内部の手順ミスです。 事故の入り口は、高度なハッキングではなく設定ミスや手順ミスから開きます。

一方で、漏れていないと確認されたものもあります。 クレジットカードの全桁番号、有効期限、セキュリティコード、本番データベースの中の顧客情報、そして金融機関のログイン認証情報です。 本番データベースへの侵入や改ざんはなく、顧客資産への影響もありませんでした。 一番恐ろしい「銀行のパスワードが抜かれた」「口座のお金が動いた」という事態は起きていません。

渦中の決算書に現れた守りの投資

事件の影響を含んだ3ヶ月の業績

これだけの騒ぎになれば、解約が殺到して業績が落ち込むに違いない。 そう思うかもしれません。 ところが、7月13日に開示された第2四半期決算の数字は、その推測を裏切るものででした。

5月末締めの第2四半期売上高は143.2億円となり、前年同期比で40%のプラスを記録しています。 事件の影響をもろに含んだ3ヶ月で、この伸びです。 毎月入ってくる利用料を12倍して年間に換算したストック売上の体力である**SaaS ARR**も、476.7億円で前年同期比34%のプラスでした。 特に法人向けは36%伸びており、成長の主役が中堅や法人にシフトしています。

バックオフィスのシステムは業務の背骨に食い込むため、事件があったからといって明日から別のソフトへ乗り換えることは困難です。 この数字は、その実態を映しています。 利用者側からすれば、ある意味で人質に取られている状態とも言えます。 だからこそ、会社がセキュリティにどう投資するかが重要になります。

上方修正とセキュリティ強化の同時宣言

業績の強さ以上に目を引くのは、通期見通しのページです。 マネーフォワードは通期の売上高見通しを605億から623億円に上方修正しました。 そして同じページに、「セキュリティへの投資を強化」と明記しています。

セキュリティ投資はコストであり、通常は利益を押し下げます。 しかし今回は、売上の好調とコストコントロールによってそれを吸収しています。 本業の稼ぐ力を示す調整後**EBITDA**は22.8億円となり、利益率は前年同期比で約10ポイント改善しました。 守りにお金を使いながら業績を上げるという両立を、数字で証明した形です。 インシデントの後に発表される決算では、謝罪の言葉よりも「守りにいくら使うか」を見ます。 この視点は、他の会社の決算を読んだり、ベンダーを選定したりする際にも使える基準になります。

利用企業がとるべき自衛策

事故のときにどう振る舞うか

どこのクラウドなら絶対に安全か。 そう考えたくなるものの、内部の手順ミスを完全にゼロにすることは困難です。 問うべきは、事故が起きたときに被害を小さく閉じ込められる設計と、事実を正直に開示する体質があるかどうかです。 370件という具体的な数字を出し、段階的に情報を開示した対応は、その一つの指標になります。

自社側の鍵を締める

利用企業側にもできることはあります。 1つ目は、通知が来る状態を作ることです。 公式のお知らせやメールを、経理担当者が確実に受け取れるようにしておきます。 事件が起きたとき、知らないまま使い続けるのが最も危険です。

2つ目は、自社側の鍵を締めることです。 二段階認証を全員必須にし、退職者のアカウントはすぐに消します。 ベンダー側の事故を心配する前に、自社側の設定ミスから被害が起きる確率のほうがはるかに高いからです。

3つ目は、「やめる練習」よりも「任せ方の設計」をしておくことです。 定期的にデータのエクスポートを取っておけば、万一のときの選択肢を確保できます。 データの逃げ道を持つことで、システムへの依存リスクをコントロールします。

決算資料には、AIによる自律的な業務支援、いわゆるAIエージェント路線もはっきりと描かれていました。 バックオフィス向けのソフトウェアは、単に記録するツールから、自律的に働くツールへと移行していきます。 仕訳や請求の処理をAIが進めるようになれば、システムに渡すデータと権限はさらに増えます。 機能そのものよりも、今回のようなセキュリティへの対応力が、今後の選定基準になっていくはずです。 事件と決算をセットで見るべき理由は、ここにあります。

まとめ

• GitHubへの不正アクセスは内部の手順ミスが原因であり、ビジネスカード370件の氏名と下4桁が流出した可能性があります。
• 本番データベースや銀行認証情報の流出はなく、顧客資産への影響はありませんでした。
• 第2四半期の「SaaS ARR」は476.7億円に達し、セキュリティ投資の強化と通期業績の上方修正を同時に発表しています。
• 利用企業は、公式通知の確認、二段階認証の徹底、定期的なデータエクスポートによって自衛策を講じる必要があります。