2026年5月、マネーフォワードのGitHubが不正アクセスされた
2026年5月1日、マネーフォワードがGitHubへの不正アクセス発生を公表しました(公式プレスリリース(第一報))。東証プライム上場のフィンテック企業で起きたこの事件は、「うちは大丈夫」と思っているすべての開発チームに対する警告です。
この記事では、事件の概要を整理した上で、同じ事故を起こさないためにエンジニアが今すぐ確認すべきポイントをまとめます。
何が起きた? ― 事件の概要
時系列で整理します。
- マネーフォワードが開発で利用していたGitHubの認証情報(アクセストークン等)が何らかの経路で漏洩
- 第三者がその認証情報を使い、GitHubに「正規ユーザー」としてアクセス
- リポジトリがコピーされ、ソースコードが流出
- リポジトリ内のファイルに含まれていた個人情報370件(マネーフォワード ビジネスカードの保持者名・カード番号下4桁)も流出の可能性
- 安全確認のため、銀行口座連携機能を一時停止
GitHub自体に脆弱性があったわけではありません。正しい鍵を持った人間が正面から入った形です。クレジットカード番号の全桁・有効期限・CVVの流出は確認されておらず、本番データベースからの漏洩もないとされています。
なぜ被害が拡大した? ― 2つの根本原因
この事件で注目すべきは、ソースコードが漏れただけでなく個人情報まで流出した点です。根本原因は2つあります。
原因1:認証情報(トークン)の漏洩
GitHubのアクセストークンやSSHキーが外部に漏れたことが、不正アクセスの起点です。トークンの漏洩経路としてよくあるパターンは以下の通り。
- ソースコードやコミット履歴にトークンをハードコードしてしまった
.envファイルを.gitignoreに入れ忘れてpushした- CI/CDの設定ファイルやログに認証情報が含まれていた
- 開発者のローカル端末やクラウドサービス経由での漏洩
マネーフォワードの詳細な漏洩経路は調査中とされていますが、いずれにしても「トークン1つで全リポジトリにアクセスできてしまう」状態だったことが被害を大きくしました。
原因2:リポジトリ内に個人情報が混入していた
マネーフォワードの公式発表によると、「個人情報の取り扱いを伴うサービスの更新作業を行う過程で、個人情報が含まれたファイルが本来の管理手順から外れ、誤ってGitHub上に保管されていた」とのこと。
つまり、本来ならデータベースやセキュアなストレージにあるべき個人情報が、CSVやテストデータなどの形でリポジトリに入り込んでいた。ソースコードが漏れるだけなら「ロジックの解析リスク」で済むところが、個人情報の混入によってインシデントの深刻度が一段上がったわけです。
自分のプロジェクトは大丈夫? 今すぐ確認すべき3つのこと
「うちは小規模だから関係ない」は通用しません。むしろ小規模チームほど、セキュリティの仕組み化が後回しになりがちです。以下の3点を今すぐ確認してください。
確認1:リポジトリに認証情報が含まれていないか
現在のコードだけでなく、コミット履歴全体を検索する必要があります。過去に一度でもpushされた認証情報は、そのコミットを削除しても履歴に残っています。
# コミット履歴から機密情報を検索
git log -p --all -S 'AKIA' # AWSアクセスキー
git log -p --all -S 'sk-' # OpenAI APIキー
git log -p --all -S 'ghp_' # GitHub Personal Access Token
git log -p --all -S 'password' # パスワード文字列
# より網羅的にチェックするなら gitleaks を使う
brew install gitleaks
gitleaks detect --source . --verbosegitleaksはコミット履歴を含めて認証情報をスキャンしてくれるツールです。CI/CDに組み込めば、pushのたびに自動チェックできます。
確認2:リポジトリに個人情報・本番データが混入していないか
マネーフォワードの事件で最も学ぶべきポイントがここです。以下のようなファイルがリポジトリに入っていないか確認してください。
- 本番データのCSVエクスポート(テストや検証用に置いたまま忘れている)
- 個人情報を含むテストデータ(ダミーではなくリアルデータを使っている)
- データ移行スクリプトに埋め込まれた実データ
- ログファイルやデバッグ出力に含まれる個人情報
# リポジトリ内のCSV/SQLファイルを確認
find . -name "*.csv" -o -name "*.sql" -o -name "*.dump" | head -20
# .gitignoreで除外されているか確認
cat .gitignore | grep -E "\.csv|\.sql|\.dump|data/"
# 大きなファイルが紛れていないか(本番データは大きいことが多い)
git ls-files | xargs ls -la 2>/dev/null | sort -k5 -rn | head -10確認3:GitHubのアクセス権限が最小限になっているか
トークンが漏れても被害を最小化するには、権限の最小化が重要です。
- Personal Access Token(PAT)のスコープを絞る:
repo全権限ではなく、必要なリポジトリ・操作だけに限定する。Fine-grained tokenを使えばリポジトリ単位で制限可能 - Organizationの2FA(二要素認証)を必須化:メンバー全員に2FAを義務付ける
- 退職者・離脱メンバーのアクセス権を即時削除:定期的な棚卸しをルーティン化する
- Deploy Keyを活用:CI/CDからのアクセスは、リポジトリごとの読み取り専用Deploy Keyにする
再発防止のための仕組み化
「気をつけよう」では事故は防げません。仕組みで防ぐのが鉄則です。
pre-commitフックで機密情報の混入を防ぐ
コミット前に自動でチェックを走らせれば、うっかりpushを防げます。
# .pre-commit-config.yaml
repos:
- repo: https://github.com/gitleaks/gitleaks
rev: v8.18.0
hooks:
- id: gitleaks# pre-commitのインストールと有効化
pip install pre-commit
pre-commit installこれでgit commitのたびにgitleaksが走り、認証情報が含まれていたらコミットがブロックされます。
GitHub Secret Scanningを有効化する
GitHub自体にもSecret Scanning機能があり、push時に既知のトークンパターンを検出してアラートを出してくれます。GitHub Organizationの設定から有効化できるので、まだの場合は今すぐオンにしましょう(GitHub Secret Scanning公式ドキュメント)。
.gitignoreの徹底とテンプレート化
プロジェクト初期に.gitignoreを正しく設定するだけで、多くの混入事故を防げます。
# .gitignore に必ず含めるべき項目
.env
.env.*
*.csv
*.sql
*.dump
*.sqlite
*.pem
*.key
credentials/
secrets/
data/GitHubセキュリティをさらに強化する関連記事
今回の事件を他人事にしないために、GitHub運用のセキュリティ知識を固めておきましょう。
GitHubセキュリティ・開発フロー
- 「それ、上げちゃダメ!」GitHub管理で絶対守るべきセキュリティルールと対処法 – .gitignoreの設定、2FA、アクセス権限管理など、今回の事件で問われた基本が網羅されています
- システム開発を成功させるために知っておきたい「GitHub」の基本 – 非エンジニアのクライアント向けにもGitHubのセキュリティ構造を説明できるようになります
- リリース前に必ず確認!バイブコーディング&非エンジニア向けWebアプリ安全チェックリスト – .envファイルの漏洩チェックやAPI認証情報の管理など、リリース前に必ず確認すべき項目集
CI/CD・インフラ運用
- AWS CLIで開発が爆速になる!セットアップからCloudWatch・Lambda活用まで実用コマンド付き – AWSの認証情報管理のベストプラクティスも含まれています
- IaC(Infrastructure as Code)とは?インフラをコードで管理する3つのメリット – インフラ設定をコード化する際のシークレット管理の考え方
まとめ:「ソースコード管理=セキュリティ」の時代
本記事のポイントを整理します。
- 事件の概要:GitHub認証情報の漏洩 → 第三者がリポジトリをコピー → ソースコード+個人情報370件が流出の可能性
- 根本原因は2つ:認証トークンの漏洩と、リポジトリ内への個人情報の混入
- 今すぐ確認すべき3点:①認証情報がコミット履歴に含まれていないか ②個人情報・本番データがリポジトリにないか ③アクセス権限が最小限か
- 仕組みで防ぐ:gitleaks + pre-commitフック、GitHub Secret Scanning、.gitignoreの徹底
マネーフォワードほどの規模の企業でも、「個人情報がリポジトリに紛れ込んでいた」という人的ミスが起きています。GitHub自体のセキュリティは堅牢でも、使う側の管理が甘ければ「正しい鍵で正面から入られる」。これは規模を問わず、すべての開発チームに当てはまるリスクです。
この記事を読んだら、まずgitleaks detectを自分のリポジトリで実行してみてください。何も出なければ安心、何か出たら今日中に対処。それだけで、同じ事故に巻き込まれる確率は大幅に下がります。
