2026.05.22 06:00
2026.05.21 17:53
●この記事のポイント
2026年5月、マネーフォワードのGitHub認証情報が漏洩。ソースコードと370件の個人情報が流出した可能性があり、銀行API連携を即時停止した。本番DBへの侵害はなく、5月12日から順次再開。攻撃者がAIで脆弱性を自動探索する時代に、企業の開発環境（サプライチェーン）が新たな標的となっている実態と防衛策を解説する。
5月1日、フィンテック大手マネーフォワードが異例の発表を行った。同社グループがシステム開発に使用するソースコード管理サービス「GitHub」の認証情報が漏洩し、第三者による不正アクセスが発生したというものだ。攻撃者はリポジトリ（プログラムの保管庫）にアクセスしてコピーしており、マネーフォワードビジネスカードに関わる370件のカード保持者名（アルファベット）とカード番号下4桁が流出した可能性が確認された。
ユーザーをもっとも戸惑わせたのは、それに伴う銀行API連携の即時停止だった。「残高照会もできない」「資産管理が止まった」という声がSNSを駆け巡ったが、同社は「本番データベースに格納されたお客さま情報の漏えいや、本件に起因する情報の不正利用等の被害がないことを確認している」と発表した。顧客の資産そのものは無事だったのだ。
では、なぜ銀行連携を止める必要があったのか。その答えは、攻撃者が何を盗んだかを理解することで初めて腑に落ちる。
●目次
「金庫の中身」より「設計図」のほうが価値がある
現代のサイバー攻撃において、攻撃者のターゲットはシフトしている。銀行の金庫に例えるなら、金庫の中身（顧客データ）を直接狙うよりも、金庫の設計図や建物の見取り図（ソースコード）を入手する方が、より多様な攻撃の糸口を与えてくれる。
設計図を持つ者は、どこにどんな鍵がかかっているか、どこに構造的な弱点があるかを知ることができる。ソースコードがあれば、システムの認証ロジックや外部APIとの接続仕様を解析できる。銀行との連携を止める必要があったのは、「今は直接の被害がなくても、設計図を解析された先に二次攻撃が来るリスクがある」という判断からに他ならない。
この攻撃を仕掛けたとされるのが、ハッカーグループ「TeamPCP」だ。同グループはGitHubの内部リポジトリ4000件超を窃盗したとダークウェブ上で主張しており、「盗んだデータを500万ドル以上で売却する、合意がなければ全データを公開する」と宣言している。TeamPCPはサプライチェーン攻撃を繰り返しているグループとして知られており、2026年5月末までに日本ではマネーフォワードのほかCAMPFIREでもGitHub経由のインシデントが発生している。
「開発環境のセキュリティ」という構造的盲点
なぜ認証情報が漏洩し、なぜソースコードのリポジトリに個人情報が含まれていたのか。マネーフォワードは5月3日の第二報で「個人情報の取り扱いを伴うサービスの更新作業を行う過程で、個人情報が含まれたファイルが本来の管理手順から外れ、誤ってGitHub上に保管されていた」と説明した。典型的なヒューマンエラーだ。
このエラーが生まれる背景に、企業のセキュリティ投資の「非対称性」がある。多くの企業では、顧客データが格納される本番環境には厳格な管理体制が敷かれている一方、開発者が日々コードを書き、プッシュし、レビューし合う開発環境のセキュリティ水準は相対的に低くなりがちだ。開発の速度を優先するあまり、「どこから誰がアクセスしているか」「リポジトリに機密情報が混入していないか」の確認が形骸化しやすい。
「本番環境のセキュリティに数億円を投じても、開発者がテスト用トークンをうっかりコミットした瞬間にリスクが生まれる。SSDLC（セキュリティを組み込んだソフトウェア開発ライフサイクル）を開発プロセスの文化として根づかせることが急務です」（サイバーセキュリティコンサルタントの新實傑氏）
さらに、AI技術の普及はこの構造的問題を加速させている。攻撃者はAIを使い、業務文脈に溶け込んだ精巧なフィッシングメールを大量生成できる。また、大量のソースコードを取得した後は、AIに脆弱性の検索や埋め込まれた認証情報の抽出を命じることで、人間の何倍もの速度で解析が進む。
「ゼロデイ脆弱性の発見にかかる時間が、AIツールの活用によって従来の数週間から数時間単位に短縮されているケースが報告されています。攻撃と防御の非対称性は今後ますます拡大するでしょう」（同）
「止める」という判断の重さ
今回の対応で評価すべきは、マネーフォワードが侵害の確定を待たずに予防的措置を即日実行した点だ。
同社は「各提携金融機関との安全性の確認を万全なものとするため、銀行口座連携機能を一時的に停止する」と表明し、安全確認が完了次第、連携を再開できるよう対応を進めるとした。実際、5月12日から順次再開を始め、5月15日までに三井住友銀行、三菱UFJ銀行、みずほ銀行といったメガバンク各行や、ソニー銀行、住信SBIネット銀行、楽天銀行、ゆうちょ銀行、全国のJAバンクなどとの連携が再開された。5月20日には、停止期間中にプレミアムサービスを利用していたユーザーに対し、継続期間を15日間延長する補償策も発表された。
この一連の対応は「インシデント前提の設計（レジリエンス）」の実践例として読み解ける。完全な防御は存在しないという前提に立ち、侵害が拡大する前にサービスを遮断できる構造が機能した。また、利便性を一時的に損なってでも安全を優先する経営判断を即日下せたことは、有事の意思決定フローが事前に整備されていた証左でもある。
「被害範囲の確定を待って公表するのではなく、不確実な段階でも迅速に開示し、予防的に動いた姿勢は評価に値します。こうした透明性こそが、長期的な信頼構築の基盤になる」（同）
自社の「設計図」を守るための4つの実践
今回の事案を踏まえ、企業がすぐに着手できる対策を整理する。
（1）シークレット・スキャンの自動化： ソースコードにパスワードやAPIキーが含まれていないかをAIが自動検知し、コミット前にブロックする機能をGitHubは標準提供している。まず「有効化されているか」を確認することから始めたい。
（2）最小権限の原則（Least Privilege）の徹底： 一人のアカウントが侵害されても、会社全体のリポジトリが閲覧・コピーされないよう権限をエリア分けする。「全員が全リポジトリにアクセスできる」状態は開発効率は高いが、リスクも高い。
（3）MFAとIPアドレス制限の組み合わせ： IDとパスワードだけに頼る時代は完全に終わった。多要素認証（MFA）に加え、接続元ネットワークを制御するIPアドレス制限を組み合わせることで、認証情報が漏洩しても不正アクセスを阻止できる確率を高められる。
（4）開発者教育と机上演習（TTX）の定期実施： フィッシング耐性は知識だけでなく、疑似攻撃を実際に体験することで養われる。インシデント発生時の対応フローをチームで訓練しておくことが、「止める」判断のスピードに直結する。
今回の事案は、一企業の失態として片づけられない。GitHubを利用して開発を行うあらゆるIT企業が、本質的に同じリスクを抱えている。
経営層やビジネスパーソンに問いたいのはシンプルなことだ。「自社の開発環境のセキュリティ状況を、あなたはどれだけ把握しているか」。本番環境の守りを固めると同時に、その設計図を管理する開発環境の安全を、エンジニア任せにせず経営レベルの課題として捉え直すこと。それが今、企業価値を守るもっとも確実な盾となる。
（文＝BUSINESS JOURNAL編集部、協力＝新實傑／サイバーセキュリティコンサルタント）
RANKING
RELATED POSTS
ニューアングル
