マネーフォワード事例が示すGitHub管理の課題 ”うっかりアップロード”をどう防ぐか：企業に求められる3層対策
2026年5月、マネーフォワードはGitHubへの不正アクセスにより情報漏えいが発生した可能性があると公表した。機密情報の入力という点では開発ツールも対策が必要だ。では、どのような対策が必要なのか。
生成AIへの機密情報入力による情報漏えいは、情報システム部門（情シス）担当者の間でも広く問題視されるようになってきた。実際、サイバーセキュリティクラウドが2026年5月に公開した調査では、生成AI利用者の約35％が「ヒヤリとした経験がある」と回答している。
情報漏えいのリスクは生成AIだけに潜んでいるわけではない。開発現場では、GitHubをはじめとするコード管理ツールへの「うっかりアップロード」が、同様の問題を引き起こしている。どちらも業務効率化のために外部サービスへ情報を送信する行為であり、管理が不十分であれば機密情報や認証情報が社外へ流出するリスクを抱えている。
2026年5月にマネーフォワードが公表したGitHub関連のインシデントは、そのリスクを改めて浮き彫りにした事例の1つだ。
本稿はこの事例を手掛かりに、開発ツールへの情報アップロードが持つリスクの実態と、企業が取るべき対策を整理する。
マネーフォワード事例から見える“取るべき対策”
2026年5月1日、マネーフォワードは開発・システム管理に利用しているGitHubにおいて第三者による不正アクセスが発生したことを公表した。
GitHubのリポジトリがコピーされ、ソースコードやリポジトリ内ファイルに含まれていた個人情報の一部が流出した可能性があるという内容だ。対象となった個人情報には、グループ会社が提供するビジネスカードのカード保持者名（アルファベット）とカード番号下4桁が含まれていた。
なぜリポジトリに個人情報が入っていたのか
GitHubは主にソースコードや開発関連ファイルを管理するためのツールであり、本来は個人情報を保管することを目的としたサービスではない。
マネーフォワードは公表資料の中で、個人情報を取り扱うサービスの更新作業を進める過程で、本来の管理手順から外れたファイルがGitHub上に保管されていたとしている。
つまり、悪意ある行為によるものではなく、通常業務の中で発生した手順ミスや管理上の問題が背景にあった。
開発作業と個人情報の取り扱いが交差する場面は、多くの企業で日常的に発生している。その意味で、この事例は決して特殊なケースではない。
認証情報の管理が不正アクセスの入口になった
今回のインシデントでは、GitHubへのアクセスに利用される認証情報が漏えいし、不正アクセスにつながった可能性が指摘されている。
発覚後、マネーフォワードは認証情報の無効化やアカウント遮断に加え、ソースコード内に含まれる認証キーやパスワードの再発行を実施した。
GitHubでは個人のアクセストークンを利用した認証が広く使われているが、組織のリソースを管理する場合は権限設計が重要になる。
必要以上に強い権限が付与されていないか。退職者や異動者のトークンが放置されていないか。こうした管理が不十分な場合、認証情報が漏えいした際の被害範囲は大きくなる。
インシデント後の影響はサービス全体に波及した
今回のインシデントでは、安全性確認のために金融機関との連携機能が一時停止された。
ユーザーに直接影響する機能停止にまで発展したことは、情報漏えいインシデントが事業継続に与える影響の大きさを示している。
さらに、ソースコードの流出は次の攻撃の足掛かりにもなり得る。システム構成や利用ライブラリ、処理フローなどの情報が把握されることで、攻撃者が脆弱性を探索しやすくなるからだ。
GitHubに「上げてよい情報」「ダメな情報」はどう考えるべきか
マネーフォワードの事例を受け、「GitHubには何をアップロードしてよいのか」を改めて整理する必要がある。
単に「GitHubへのアップロードに注意」と呼び掛けるだけでは十分ではない。なぜ危険なのか、どこまで許容されるのかを明確にすることが重要だ。
アップロードしてよい情報
基本的な判断基準は「流出した場合に実害が発生するかどうか」である。
個人情報や認証情報を含まない純粋なソースコード、開発用のダミーデータやモックデータは、一般的にはアップロード可能な範囲に含まれる。
アップロードしてはいけない情報
代表例として以下が挙げられる。
- 個人情報を含むCSVファイルやログデータ
- APIキー、アクセストークン、パスワードなどの認証情報
- .envファイル（環境設定ファイル）
- 本番データベースの接続情報
- 内部IPアドレスや詳細なインフラ構成情報
- 匿名化されていない本番データ
特に認証情報は、開発者本人も気付かないまま混入するケースが少なくない。
アップロードしてしまうと何が起きるか
公開リポジトリに認証情報を含むファイルをアップロードすると、その情報は短時間で第三者に発見され、悪用される可能性が高い。
クラウドサービスへの不正アクセスや高額なクラウド利用料金の発生につながる事例も報告されている。
また、ファイルを削除してもコミット履歴には情報が残るため、単純な削除だけでは対処できない。
一方、非公開リポジトリは公開リポジトリより安全性は高い。しかし、認証情報の漏えいや権限管理の不備が発生した場合、情報流出を完全に防げるわけではない。
企業が取るべき対策を3層で考える
ルール層
まず必要なのは、「何を上げてはいけないか」を具体化することだ。
「個人情報はNG」ではなく、「.envファイルはNG」「実在する個人情報を含むCSVはNG」といった形で明文化する必要がある。
技術層
GitHubのSecret ScanningやPush Protectionなどの機能を活用し、認証情報の混入を技術的に防ぐことが重要だ。
また、最小権限の原則に基づいたアクセス管理や、レビュー体制の整備も有効な対策となる。
文化層
GitHubへの誤アップロードや認証情報の混入は、早期発見と迅速な報告によって被害を抑えられる場合が多い。
しかし、報告しづらい組織では問題が表面化しないまま放置される。
ヒヤリハットを共有し、失敗から学べる文化を育てることも重要な対策の一つだ。
まとめ
今回のマネーフォワードの事例が示したのは、情報漏えいのリスクが高度な攻撃だけで発生するわけではないという事実だ。
生成AIへの入力管理と、GitHubなどの開発ツールへのアップロード管理は、一見別の問題に見えて本質的には同じ課題を抱えている。
重要なのは、「何をどこへ送信してよいのか」という基準を明確にし、ルール・技術・文化の3層で管理することだ。
まずは、自社のGitHubや類似ツールにどのような情報が保管されているのかを確認するところから始めてみてはいかがだろうか。
Copyright © ITmedia, Inc. All Rights Reserved.