マネーフォワードの話をしつつ、見解を述べる
※本記事は広告を含みます
ゴールデンウィーク中に世間を賑わせたマネーフォワードの情報漏洩。筆者もいちおうエンジニアの端くれなので、わりとこのニュースについて追ったりしています。今回はこのニュースの概要を見つつ、所見を述べていければと思います。
なにが起こったのか
第一報について
2026年5月1日、マネーフォワードから不正アクセスのお知らせというインシデントの速報が出されました。
『GitHub』への不正アクセス発生に関するお知らせとお詫び（第一報）：https://corp.moneyforward.com/news/info/20260501-mf-press-1/
結構ネット上でも話題となっていたので、たとえゴールデンウィーク中であっても耳にした方は多かったのではないでしょうか。特にマネーフォワードは資産を便利に管理できるアプリです。ここの漏洩ということでユーザーはいつも以上に敏感になる案件なのは間違いありません。
しかも、第一報の時点で
『マネーフォワード ビジネスカード』に関わる370件の「カード保持者名（アルファベット）」および「カード番号の下4桁」
が漏洩した可能性があると報告されています。
こうなってしまうとユーザーとしては「他にも漏れているんじゃ。。」となってしまう訳ですよね。そしてなによりエンジニアが引っかかってしまったのが以下の一文です。
現時点において、ソースコードおよび、リポジトリに含まれていたファイル内に記載されていた個人情報の一部が流出した可能性があることを確認しております。
「いや、GitHubに個人情報をアップロードするんじゃないよ！」ってのが大勢の見解ですよね。これについては筆者も同様の意見です。特にマネーフォワードが預かる情報は基本的に漏洩した際の影響がとても大きいので、ここは特に慎重になるべき部分でしょう。ある程度叩かれてしまうのは致し方ないと思います。
そこから少し経ってどうなっているか
そして2026年5月11日、この記事を書いている日にも速報が公開されています。というのも、マネーフォワードはこの事件以降、各銀行口座などとの連携が止まっていました。ここに関しては推測ですが、APIを提供している銀行各社から待ったがかかっているのだと思います。これが起因で特定の銀行のみ口座情報が漏洩してしまった、とかなったら目も当てられないですしね。二次災害が起こるリスクを鑑みたら、銀行側が慎重になるのはごく当たり前のことです。
で、本日以下のリリースがありました。
銀行口座等との連携機能の再開に向けて必要な技術的確認および追加対策を進めております。 当社の追加対策等の完了と各提携金融機関様における最終確認を踏まえ、順次再開する予定です。
そう、具体的な予定はなにもありません！マネーフォワードくらい対向先の多いシステムであればそれはそうなんですが、このリリースについても火に油を注ぐ感じになっているのが現在の状況です。
筆者の見解とかもろもろ
ここからは上記を踏まえて、筆者が好き勝手語るコーナーです！先に言っておきますが、基本的にマネーフォワードへのディスはないです。悪いのはこの社会だ！！（嘘ですごめんなさい）
リリースが出るのに時間がかかっている&進展があるように見えない
正直なところ、GW真っただ中の5/1にリリースしたのは、それだけでかなり信用に値する企業だなというイメージを個人的には持っています。もちろん社員もゴールデンウィーク中でしょうし、通常営業日と比べて障害対応の体制が取りづらいのは間違いありません。その中で速報を出したのは、企業としてこの漏洩を重く見ている何よりの証拠であると思います。
なのですが、現状は第一報以降あまり進展がないように見受けられます。今年のゴールデンウィークは最大12連休、つまり昨日まではゴールデンウィークにできるので、ここまで進展がなかったのかも知れません。しかし、世間的にはゴールデンウィークが終わっている人が多いわけです。少し早めに業務に戻ったユーザーからしてみると、どうしても遅いと感じてしまいますよね。
第一報をゴールデンウィーク中に出すのであれば、ゴールデンウィーク明けにはある程度の進展を発表できる状態にしておいた方がハレーションは少なかったはず。対向先との調整は難しかったかも知れませんが、事象の深堀については社内でできたのではないかなあ。
クレ非保持化ルール的にもグレーなのでは？
非保持化の公式ルールとしては
- カード番号（全桁）
- 有効期限
- カード名義人
- CVV（セキュリティコード）
は非保持、非通過に関する項目です。
基本的にはカード番号 + αが「カード情報」という枠組みであり、この双方がセットで保持、通過しなければ問題はない、というルールです。（解釈が難しい部分ではあります。間違っていたらごめんなさい）
p12あたりに「カード情報」のとらえ方があります：https://www.j-credit.or.jp/security/pdf/Creditcardsecurityguidelines_5.0_published.pdf?a8=4%3FSORT_ITEM
という訳で、今回のマネーフォワードが漏洩した「カード保持者名（アルファベット）」および「カード番号の下4桁」という情報はルール上問題ないようにも見えます。
しかし、たとえカード番号がフル桁でなくとも、トークン化されていない情報がサーバー上に通過してしまっているのは微妙な状態と言わざるを得ません。（ちなみにトークン化というのはカード番号を特定できないよう、他社システムを用いてわけわからん文字列に変換することを言います）
確かにカード番号を特定できるわけではないものの、16桁のうち4文字はマッチングしてしまっているんですよね。んでそれに加えカード名義人がセットになってるので、みようによっては非保持化ルールにも抵触してしまうのでは？というのが筆者の見解です。グレーであるなら踏まないようにする、が安全なので、ここがトークンであればこんな大事にならない、なんなら別に公開もしなかったんでしょうね。ルール上はOKなはずなので。
てか、何に使うんだろう今回漏れた情報は。ちょっと用途が分からないかも。
運用ルールの徹底をどこまでできるか
今回は
- GitHubの認証情報が漏れてしまった
- GitHubに機密情報が混入してしまった
の2軸が良くなかった点です。
このうち、機密情報の混入については機械的にどうにかなる部分な気がしています。GitHubにはSecret Scanningという特定サービスの権限情報をチェックできる機能が存在します。また、カスタムパターンで独自にチェックを仕込むことも可能です。今回の件を決め打ちするのであれば、
**** **** **** 1234
とかに対してパターンを組み込むことができるはずです。もちろん上げないようにするルール、意識づけも必要ですが、最後の砦は機械に任せるのが良いと思います。
逆に認証情報の漏洩についてはかなり難しい問題な気がしています。どんなに仕組化したところで、漏洩したかどうかを検知する術はないんですよね、だいたいの場合は気づくのは破られちゃった後という。今回のもそうですよね。なので、個人的には、最後の砦をいかに強固にするかが重要であると思っています。エ
いずれにしても
- エンジニアの意識改革、ルールの徹底
- 最悪のケースを守る仕組みづくり、機械化
はシステム運用する際に検討べき最重要事項の一つと言えるでしょう。
たぶんレビュアー不足、特にセキュリティ周りは難しい
これは完全に自分の経験ベースなのですが、現場レイヤに寄ればよるほど、それをレビューできる人材が減っていきます。日本の管理職は技術的な部分のレビューは得意でないことが多いです。なので、基本的には中堅クラスがこのレビューを担う訳ですが、そのクラスでもこういった構成の管理をレビューするのは難しいというのが所感です。
今回の事象についてはまだ分かりやすいですし、議論の余地がある気がしていますが、恐らく具体的な改善案を示すことができるレビュワーはそこまで多くないと思っています。
筆者が今まで置かれてきた環境がおかしいのかも知れませんが、少なくとも近年はアプリケーションロジックだけでなく、セキュリティ周りも意識したレビューが必要になってきてきます。大変ですが、結局こういう部分があるからエンジニアは一生勉強みたいに言われるんですよね。みんながんばれ。
まとめ
今回のインシデントはかなりセンセーショナルな事案になってしまったかと思います。個人的なまとめとして、以下の3点を置いておきます。
- よりセキュリティ意識が求められる時代
- 漏洩対策の仕組化 → 機械化が急務
- レビューイだけでなくレビュアーのスキルも重要 → ずっと勉強かも
AIの進歩で一つ一つを突き詰めなくてもよくなってきてはいますが、結局人間のキャパは今も昔も変わりません。エンジニアとかクッソ難しいので、誰か一人に頼らずみんなで分業しよう！
最後に
AIの普及によって、より属人化が進んでいくような気がして草ｱ！いや笑えないか。
