AIツール利用中の情報漏洩、他人事ではない！今すぐガイドラインを整備すべき理由（マネーフォワードのケース）

（本記事は、プライバシーマーク（Pマーク）・ISMS取得コンサルティングで業界トップクラス・業界トップクラスの実績を持つ株式会社UPFが執筆・監修しています。）

2026年5月1日、家計管理・クラウド会計サービスで国内トップクラスの知名度を誇るマネーフォワードが、GitHub（ギットハブ）への不正アクセス被害を公表しました。
ソフトウェア開発に使っていたGitHubの認証情報が漏えいし、第三者に不正アクセスされてしまったのです。

流出した可能性があるのは、グループ会社のクレジットカード「マネーフォワード ビジネスカード」に関わる370件分のカード保持者名（アルファベット）とカード番号の下4桁。
銀行口座との連携機能も、安全確認のため一時停止を余儀なくされました。

「GitHubってエンジニアが使うやつでしょ？うちには関係ない」
そう思った方、少し待ってください。これは単なるシステム障害の話ではありません。

今回の事案で弁護士が指摘した核心がとても示唆に富んでいます。

「GitHubのような技術者が使う開発環境は、個人情報が扱われる場所として見過ごされがちだ」
つまり、「ここは個人情報とは関係ない場所だ」という思い込みが盲点を生んだということです。

これは他のAIツールでも全く同じことが言えます。
ChatGPTや生成AIに顧客情報を含む文章をそのまま貼り付けていませんか？
社内の機密情報を含むデータを、AIに「要約して」と投げていませんか？
便利だからと、業務上の個人情報をAIのプロンプトに流し込んでいませんか？

「AIに話しかけているだけだから大丈夫」という感覚は、「GitHubはエンジニアのものだから大丈夫」という感覚と、本質的に同じ危うさをはらんでいます。

マネーフォワードは日本屈指のフィンテック企業です。
セキュリティへの意識は、一般的な中小企業より格段に高いはずです。
それでも今回の事案は起きました。

調査の結果わかったのは、「個人情報の含まれたファイルが、本来の管理手順から外れて誤ってGitHub上に保管されていた」という事実でした。
ルールはあった。でも現場で徹底されていなかった。
大きな組織になるほど、「どこかで誰かが例外処理をしている」リスクは高まります。

しかし、これは大企業だけの話でしょうか。
むしろ中小企業こそ、「ルールを作る前にみんなが使い始めてしまっている」という状況が起きやすいのではないでしょうか。

法的なリスクも見逃せません。
個人情報漏えいが発生した場合、企業には個人情報保護委員会への報告（速報は3〜5日以内）、本人への通知、被害拡大防止措置、事実関係の調査・原因究明、再発防止策の策定と実施——これらが最低限の義務として課されます。

さらに、「対策が不十分だった」と判断された場合は安全管理措置義務違反となり、損害賠償リスクも発生します。
免責条項があっても、重過失があれば機能しません。
刑事・民事両面でのリスクがある。それがAI・デジタルツールを使った情報漏えい事故の現実です。

ただし、AIツールの利用ガイドラインを整備することは、単なる「事故を防ぐための守り」ではありません。
「当社ではAI利用に関するガイドラインを整備しています」と言えるだけで、特に情報管理を重視する業種・企業との取引において、大きな差別化になります。
官公庁や大手企業との取引において、情報セキュリティ管理体制の整備が実質的な審査項目となるケースも増えています。
AIガイドラインの有無も、近い将来そのチェックリストに入ってくることは間違いないでしょう。

また、「AIを使っていいのか悪いのかわからない」という状態は、社員に不必要なストレスを与えます。
明確なルールがあれば、安心して業務でAIを活用でき、生産性向上にも直結します。

業種・業態・規模を問わず、AIを使わないという選択肢は現実的ではないと私は考えています。
経営管理、営業資料の作成、顧客対応、採用活動——気づけば業務のあちこちにAIが入り込んでいます。
それ自体は素晴らしいことです。

問題は、そのスピードに「ルール作り」が追いついていないことです。
マネーフォワードの件は、「セキュリティ意識の高い大企業でさえ、管理の形骸化でこうなる」という事実を突きつけています。
この流れは、これからますます大きくなる一方です。

だからこそ、早めのガイドライン整備を強くお勧めします。
「うちはまだ小さいから」「うちはIT企業じゃないから」——そういった理由は、残念ながら法的にも取引先にも、免責の理由にはなりません。

もし「何から手をつければいいかわからない」とお感じでしたら、まずはお気軽にご相談ください。
我々UPFでは、現在多くの企業、特に代表者様からのお問合せを多く戴いております。まずは一緒に整理するところから始めさせていただいております。

ソースコード管理におけるISMS上の管理策

GitHubなどのソースコード管理サービスは、開発効率を高める一方で、認証情報（APIキー、アクセストークン、パスワード等）がリポジトリ内に誤ってコミットされてしまうという事故が後を絶ちません。ISMS（ISO/IEC 27001）の管理策では、こうした開発環境も「情報資産」の一部として扱い、アクセス権限の最小化、認証情報の適切な管理（コード内への直接記述の禁止、シークレット管理ツールの利用など）、外部への公開範囲の定期的な確認といった対策を求めています。

また、リポジトリへのアクセス権限は、退職者や異動者が発生した際に速やかに見直す運用が欠かせません。開発環境は専門性が高く、情報セキュリティ部門から見えにくい領域になりやすいため、定期的な棚卸しや、開発チームと情報セキュリティ担当者との連携体制を整えておくことが、こうした事故の再発防止につながります。

AIツール利用における入力データの管理

AIツールを業務で利用する場合、開発環境に限らず、チャット形式のAIツールに入力する情報についても同様の注意が必要です。顧客情報や未公開の技術情報をAIツールに入力してしまうと、意図せず外部のサーバーに情報が送信され、事業者側のログとして保持される可能性があります。利用するAIツールが入力データを学習に利用する設定になっていないかを確認し、必要に応じて法人向けプランやオプトアウト設定を活用することが基本的な対策となります。

従業員一人ひとりがこうしたリスクを正しく理解できるよう、定期的な社内教育を行うことも、ガイドラインを実効性のあるものにする上で欠かせない要素です。

よくある質問（FAQ）