こんにちは、株式会社TIMEWELLの濱本です。2026年5月1日、マネーフォワード社が「GitHubへの不正アクセス」を公表しました[^1]。ソースコードを管理するサービスから、個人データが流出した可能性がある。この一報を見て、私は真っ先に自社の開発環境のことを考えました。GitHubを使っている会社なら、他人事ではいられないはずです。
最初に断っておきます。この記事は、同社の落ち度を詮索するものではありません。同社は第一報から詳細調査の完了報告まで、複数回にわたって自主的に情報を開示し、Q&A形式で利用者の疑問にも答え続けました[^4]。この透明性は、日本企業のインシデント対応として率直に評価されるべきだと私は思っています。公表された事実が詳細だからこそ、私たちは多くを学べる。だからこの記事のテーマは「同社の何が悪かったか」ではなく、「公表された事実から、GitHubを使うすべての企業が何を学ぶか」です。
何が公表されたのか。時系列と数字で整理する
まず事実関係を、同社の公式発表に沿って整理します。ここに書くのはすべて公表ベースの情報で、公表されていないことは「公表されていない」と明記します。
2026年5月1日の第一報によれば、同社がソフトウェア開発とシステム管理に利用しているGitHubの認証情報が漏えいし、これを用いた第三者による不正アクセスが発生、GitHub内のリポジトリ（ソースコードやファイルの保管庫）がコピーされたことが判明しました[^1]。同社は不正アクセス経路となった認証情報の無効化とアカウント遮断を行い、ソースコード内の認証キーやパスワードの無効化と再発行を進めるとともに、銀行口座連携機能を一時停止しています[^1]。利用者への影響が読み切れない段階で機能停止に踏み切る判断は、簡単なようでいて重い決断です。
第一報の時点で公表されたのは、マネーフォワード ビジネスカード利用者370件分のカード保持者名（アルファベット）とカード番号の下4桁が流出した可能性でした。カード番号の全桁、有効期限、セキュリティコードの流出は確認されていないと明記されています[^1]。5月11日の第二報では調査の進捗と銀行口座連携の再開に向けた経過が報告され[^2]、機能は順次再開されていきました[^5]。
そして6月23日の第四報で、詳細調査の完了が報告されます。流出した可能性のある個人データは、顧客の氏名またはメールアドレス124名分、取引先の情報28名分、従業員（退職者含む）の情報2,300名分、そして顧客の固有識別子60,449名分でした[^3]。固有識別子とは、システムが内部でユーザーを区別するための管理番号のことで、同社はここに氏名やメールアドレスなどの個人情報は含まれないと説明しています。重要なのは、お客さま情報を格納する本番データベースへの不正アクセスや本番環境からの情報漏えい、個人情報の不正利用による被害は一切確認されていないという点です[^3]。流出の可能性はGitHub上のリポジトリに含まれていた情報に限定され、二次被害も確認されていません。同社は個人情報保護委員会と事業所管大臣への確定報告も提出済みです[^3]。
一方で、認証情報がどのような経路で漏えいしたのか、その詳細は公表されていません[^4]。報道各社も公表内容を超える原因分析はしておらず[^7][^8][^9]、私たちも憶測でそれを埋めるべきではないでしょう。この記事で扱う「流出のメカニズム」は、あくまで一般論として書きます。自社の開発体制がこの種のリスクにどれだけ備えられているか、感覚ではなく項目で確かめたい方は、AI導入準備度の無料診断のようなツールで足元を棚卸ししてみるのも一つの入り口です。
AIセキュリティ研修を、本気で
OWASP・NIST・ISO 42001・経産省ガイドライン全準拠の2日間集中講座。経営層と現場で分けて受講できます。
そもそも、なぜ開発リポジトリに個人データが存在しうるのか
ここからは一般論です。マネーフォワード社の事案がこうだったという話ではなく、開発の現場一般で、なぜソースコードの保管庫に個人データが紛れ込みうるのかという構造の話をします。なお同社のサポートページのQ&Aでは、リポジトリに個人情報が含まれていた経緯について、本来の管理手順の外で誤ってアップロードされたものだったという趣旨の説明がなされています[^4][^6]。手順は整備されていても、例外がすり抜ける。これはどの組織にも起こりうることです。
最初に思い浮かぶのはテストデータです。不具合の調査では「本番と同じデータで再現したい」という誘惑が常にあります。ダミーデータでは再現しない不具合が、実データなら一発で再現する。急いでいるエンジニアが本番データの一部をCSVで抜き出し、再現用スクリプトと一緒にリポジトリへコミットする。悪意はどこにもないのに、リポジトリに氏名やメールアドレスが残ります。
次にログです。エラーログやデバッグログには、処理対象のデータがそのまま出力されることがあります。障害対応でログファイルを共有し、それがリポジトリの調査用ディレクトリに置かれたまま忘れられる。設定ファイルも典型で、データベースの接続情報やAPIキーといったシークレット（秘密情報）が、環境変数に置くべきところをコードに直書きされてしまうケースは、GitHubが公式にシークレットスキャン機能を提供するほどありふれた問題です[^10]。ほかにも、マーケティング分析用のデータ抽出、開発環境のシードデータ、サポート対応の添付ファイル。個人データがリポジトリへ流れ込む水路は、思っている以上に多い。
ここで強調したいのは、これが「だらしない会社だけの問題」ではないことです。コードレビューはコードの品質を見る場であって、データの混入を検知する仕組みではありません。しかもGitの怖いところは履歴です。ファイルを削除するコミットを積んでも、過去のコミットにはデータが残り続けます。リポジトリがコピーされるということは、現在のファイルだけでなく、履歴ごと持っていかれるということです。「昔消したから大丈夫」は、Gitの世界では通用しません。
認証情報の漏えいから流出に至る、典型的な経路
では、その保管庫の鍵はどう漏れるのか。これも一般論として、典型的な経路を押さえておきます。
現在のGitHubへのアクセスは、パスワードそのものよりも、アクセストークン（プログラムやツールがAPIを呼ぶための鍵文字列）を介することが多くなっています。このトークンが厄介で、開発者の端末の設定ファイルやCI/CD（ビルドとデプロイの自動化基盤）の環境変数、時にはチャットの履歴にまで散らばりがちです。攻撃者の側から見ると、狙い目はサーバーではなく開発者の端末になります。情報窃取型マルウェア、いわゆるインフォスティーラーが端末内のトークンやブラウザの認証情報をまとめて吸い上げる手口は、IPAの情報セキュリティ10大脅威でも常連となっている攻撃類型の入り口です[^12]。フィッシングで開発者のアカウントを直接奪う手口や、公開リポジトリへ誤ってコミットされたトークンが収集される経路もあります。
そして、鍵さえ手に入れば、その後の動きは静かです。リポジトリのクローン（複製）は正規のAPI操作なので、不正な侵入の痕跡が残りにくい。大量のダウンロードを異常として検知する仕組みを自前で用意していなければ、正規ユーザーの日常操作と区別がつきません。ここが本番データベースへの侵入と違うところで、派手な攻撃ではなく、正しい鍵による正しい操作として流出が進みます。
だからこそ、トークンの権限設計が生命線になります。GitHubは権限を細かく絞れるfine-grained personal access tokenと有効期限の設定を提供しており、公式ドキュメントでも最小権限と短い有効期限を推奨しています[^11]。全リポジトリを読める無期限のトークンが1本漏れるのと、特定リポジトリだけ読める30日期限のトークンが漏れるのとでは、被害の桁が変わります。漏れない前提ではなく、漏れたときに被害がどこまで広がるかで設計する。これが実務の考え方です。
AI時代、このリスクはどう増幅するのか
ここからが、2026年にこの事案を考える意味だと私は思っています。開発の現場には、AIコーディングエージェントが急速に入り込みました。Claude CodeやGitHub Copilotのようなツールがコードを書き、テストを回し、プルリクエストまで作る。生産性は確かに上がりました。ただ、セキュリティの観点で見ると、リスクの増幅装置が3つ増えています。
1つ目は、権限の集中です。AIエージェントに仕事をさせるには、リポジトリへのアクセストークンを渡す必要があります。人間なら「このリポジトリだけ触る」と自然に範囲が絞られますが、エージェントには利便性のために広い権限を与えがちです。エージェントが動く端末やCI環境が侵害されれば、そこにあるトークンごと奪われる。エージェントの認証情報と設定ファイルの守り方はClaude Codeに.envを読ませないシークレット漏洩対策で詳しく書いたとおり、除外設定と権限の絞り込みを明示的にやらない限り、AIは目の前のファイルを何でも読みます。
2つ目は、データの流れの複雑化です。AIエージェントは外部のWebページやドキュメントを読み込みながら動きます。そこに悪意ある指示が仕込まれていれば、エージェント自身が加害の道具になりえます。外部コンテンツ経由でAIに意図しない動作をさせる間接プロンプトインジェクションは、EchoLeakの脆弱性解説で扱ったように、すでに理論上の話ではありません。OWASPもLLMアプリケーションのリスクの筆頭にプロンプトインジェクションを挙げています[^13]。開発リポジトリに個人データが残っている状態でAIエージェントに広い権限を渡すことは、この2つのリスクを掛け算することを意味します。
3つ目は、サプライチェーンです。AIが提案するパッケージ名を疑わずにインストールする文化が広がると、存在しないパッケージ名を悪用するslopsquattingのような攻撃の成功率が上がります。開発ツール自体が攻撃対象になった事例はAIサプライチェーン攻撃の解説記事でも書きました。開発環境は今や、コードとデータとAIと外部ツールが交差する結節点であり、そこの防御レベルが会社全体の防御レベルを規定しつつあります。
私自身は、この流れを悲観していません。AIを閉め出すのではなく、AIに渡す権限とデータを設計する時代になった、と捉えています。弊社がエンタープライズAI基盤のZEROCKをAWS国内サーバーで運用し、ナレッジコントロールと監査ログを標準で備える設計にしているのも同じ思想です。誰がどの情報にアクセスできるかを制御し、操作の記録を残す。AIに仕事を任せる前提条件は、突き詰めればこの2つに帰着します。
明日から自社でチェックすべきこと
一般論と増幅要因を踏まえて、自社で確認すべきことを実務の順番で挙げます。全部を一度にやる必要はありません。上から順に、まず現状を知ることから始めてください。
| 優先度 | チェック項目 | 具体的な確認方法 |
|---|---|---|
| 高 | リポジトリ内の個人データ・シークレットの棚卸し | シークレットスキャン（gitleaks等やGitHub標準機能）を全リポジトリと過去履歴に実行[^10] |
| 高 | アクセストークンの権限と有効期限 | 無期限・全リポジトリ権限のトークンを洗い出し、fine-grained型と短期限へ移行[^11] |
| 高 | 二要素認証と端末の統制 | GitHub組織で2FAを必須化。開発端末のEDR・マルウェア対策の適用状況を確認 |
| 中 | テストデータの実データ排除 | 本番データの持ち出しルールを明文化し、マスキング済みデータか合成データに置き換え |
| 中 | プッシュ時のブロック設定 | シークレットを含むコミットを拒否するpush protectionやpre-commitフックの導入[^10] |
| 中 | AIエージェントの権限設計 | エージェントに渡すトークンの範囲、読ませないファイルの除外設定、実行コマンドの許可リスト |
| 低 | 異常検知とログ | リポジトリの大量クローンなど異常操作のアラート設定、監査ログの保全期間の確認 |
| 低 | インシデント対応と開示の準備 | 発覚から公表・当局報告までの手順書と責任者を事前に決めておく |
表の使い方について少し補足します。最初の3項目は「鍵とデータの現在地を知る」ためのもので、ツールを回せば今週中にでも着手できます。棚卸しの結果、過去の履歴に個人データが見つかることは珍しくありません。見つかったら履歴の書き換えと、そのデータに紐づく認証情報の無効化まで行う必要があります。中段の3項目は運用の設計なので、開発チームとの合意形成に時間をかけてください。特にテストデータの実データ排除は、エンジニアの「再現できないと直せない」という切実な事情とぶつかります。禁止だけでは形骸化するので、マスキング済みデータを簡単に払い出せる仕組みとセットで導入するのが現実的です。
最後の開示準備は後回しにされがちですが、私はここにこそ今回の学びがあると思っています。マネーフォワード社の対応が評価に値するのは、事故を防いだからではなく、事故の後に何をどの順番で開示するかが組織として機能していたからです。第一報での機能停止の判断、Q&Aでの丁寧な説明、確定報告までの一貫した情報開示[^1][^3][^4]。この動きは、その場の思いつきでは絶対にできません。
まとめ。透明な開示は、業界全体への貢献になる
事実の骨格をもう一度だけ確認します。公表されたのは、GitHubの認証情報漏えいによる不正アクセスとリポジトリのコピー、そして限定された範囲の個人データが流出した可能性です。本番環境への侵害と二次被害は確認されていません[^3]。認証情報漏えいの詳細な経路は公表されておらず、この記事で書いた流出メカニズムはすべて一般論です。
私がこの事案から受け取った最大の教訓は、開発環境は本番環境と同じ真剣さで守るべき時代になった、ということです。データベースの防御に投資してきた企業は多い。しかしリポジトリには、コードだけでなく、テストデータやログや設定という形でデータの影が残ります。そこへAIエージェントという新しい住人が加わり、権限とデータの交差点はさらに混み合っています。詳細を公表してくれた企業がいるおかげで、私たちは自社の点検項目を具体化できる。透明な開示は業界全体への貢献であり、受け取った側の責務は、詮索ではなく自社の点検です。
まずは先ほどのチェックリストの上から3つ、今週のうちに現状を確認してみてください。自社のAI活用と開発体制のセキュリティ設計を相談したいという方は、個別相談からお声がけいただければ、状況を伺ったうえで一緒に考えます。
参考
本記事の事実関係は、マネーフォワード社の公式発表（第一報から第四報およびサポートページ）を柱とし、報道は補助的な確認のために参照しています。
[^1]: 『GitHub』への不正アクセス発生に関するお知らせとお詫び（第一報） — 株式会社マネーフォワード — 2026年5月1日 [^2]: 『GitHub』への不正アクセスに関する調査進捗および銀行口座連携再開に向けた経過のご報告（第二報） — 株式会社マネーフォワード — 2026年5月11日 [^3]: GitHubへの不正アクセスに関する詳細調査の完了およびセキュリティ対策強化のお知らせ（第四報） — 株式会社マネーフォワード — 2026年6月23日 [^4]: 【重要】「GitHub」への不正アクセス発生に関するお知らせとお詫び（2026年6月23日追記） — マネーフォワード クラウドサービス全般サポート [^5]: 『GitHub』への不正アクセス発生および銀行口座連携機能の一時停止に関するお知らせ — マネーフォワード MEサポートサイト [^6]: 『GitHub』への不正アクセス発生および銀行口座連携機能の一時停止に関するご質問と回答 — マネーフォワード MEサポートサイト [^7]: マネーフォワードが利用する「GitHub」への不正アクセス、流出した可能性が判明した個人データの詳細公表（報道・補助的参照） — ScanNetSecurity — 2026年7月7日 [^8]: マネーフォワード、GitHubへの不正アクセスでビジネスカード情報370件・ソースコード流出の可能性（報道・補助的参照） — セキュリティ対策Lab [^9]: マネーフォワード、不正アクセス調査完了（報道・補助的参照） — セキュリティ対策Lab [^10]: シークレットスキャンについて — GitHub Docs [^11]: 個人用アクセストークンの管理 — GitHub Docs [^12]: 情報セキュリティ10大脅威 — 独立行政法人情報処理推進機構（IPA） [^13]: OWASP Top 10 for Large Language Model Applications — OWASP GenAI Security Project