マネーフォワードの銀行連携はいつ復旧した？GitHub不正アクセス事案の全容と利用者がとるべき対応

2026年5月のGitHubへの不正アクセスを受けて停止していたマネーフォワードの銀行口座連携機能は、2026年6月5日午前10時50分にすべての金融機関との連携が再開され、銀行連携は完全復旧しました（停止開始の5月1日から約35日ぶり）。本記事では、「いつ復旧したのか」という最も知りたい点を最初に整理したうえで、何が起きたのか（GitHub不正アクセスの全容）、何が流出したのか（ビジネスカード370件）、連携が使えなかった間の対処、そして利用者が今からでも実施すべき自衛策までを、公式発表に基づいてまとめます。なお銀行以外の一部連携サービスには再開の目処が残るものもあるため、最新の連携状況は念のため公式サポートサイトでご確認ください。

まとめ：マネーフォワード連携復旧の要点（結論先出し）

• 復旧状況：銀行口座連携は2026年6月5日10:50に全行で再開＝銀行連携は完全復旧。5月12日から一部金融機関で順次再開し、約35日間かけて全行が復旧した（証券・マイル等の一部非銀行サービスは再開未定が残る場合あり）。
• 何が起きたか：2026年5月1日、グループが利用するGitHubの認証情報が漏洩し、第三者がリポジトリへ不正アクセスしてソースコード等をコピー。同日に銀行連携を予防的に一時停止した。
• 流出したもの：マネーフォワードビジネスカード370件（カード保持者名のアルファベットとカード番号下4桁）。カード番号全桁・有効期限・セキュリティコード（CVV）、本番データベースの顧客情報は流出が確認されていない。
• カード情報が漏れた理由：個人情報を含むファイルが更新作業の過程で本来の管理手順から外れ、誤ってGitHub上に保管されていたためと同社は説明している。
• 連携が止まっていた間：自動取得のみ停止で、過去データ閲覧・手動入力・分析機能は利用可能だった。法人はCSVインポートで記帳を継続できた。
• 今やるべき自衛策：マネーフォワードIDのパスワード変更（使い回しの解消）、二段階認証の有効化、ログイン履歴の確認、マネーフォワードを騙るフィッシングメールへの警戒。

以下では、復旧タイムライン・事案の原因・流出範囲・停止中と復旧後の実務対応・再発防止策までを順に詳しく解説します。

マネーフォワードの銀行連携はいつ復旧したか（停止から全再開までのタイムライン）

最も多く検索されている「いつ復旧するのか」という疑問は、2026年6月時点ではすでに解決しています。銀行口座連携は全金融機関で再開済みです。停止から完全復旧までの流れは次のとおりです。

停止は新規連携・更新・再連携のすべてが対象でしたが、提携金融機関ごとに安全性確認が完了した順に再開され、約35日間で全行が復旧しました。現在は通常どおり自動取得が利用できます。ただし、証券・マイレージ・暗号資産など銀行以外の一部連携サービスには再開の目処が立っていないものが残る場合があるため、対象の方は公式の最新案内を確認してください。万一、自分の連携先がまだ更新されない場合は、後述する再連携の手順を試してください。

何が起きたのか：GitHub認証情報の漏洩を起点とした不正アクセスの全容

本件は、コードの脆弱性ではなく「認証情報の漏洩」を起点としたインシデントです。マネーフォワードグループがソフトウェア開発・システム管理に利用しているGitHubの認証情報が第三者の手に渡り、それを用いて同社のリポジトリへ不正にアクセスされ、ソースコードを含む複数ファイルがコピーされました。同社は事象を検知後、不正アクセスの経路となった認証情報を直ちに無効化し、関連アカウントを遮断しています。

認証情報がどのように外部へ漏れたか（フィッシング、端末感染、委託先経由など）の根本原因は、第一報時点では特定の経路を断定せず継続調査とされました。ソースコードに含まれていた各種認証キーやパスワードについても、二次被害を防ぐため無効化と再発行が進められています。「github 原因」で調べる利用者が知りたいのは、攻撃がコードの欠陥ではなくアカウント認証情報の窃取から始まった点であり、これは正規アカウントが乗っ取られる近年のサプライチェーン型攻撃と同じ構図です。

何が流出したのか：ビジネスカード370件と「流出していない情報」の線引き

利用者にとって最重要の論点が「自分の情報が漏れたのか」です。第一報では、流出した可能性のある情報と、現時点で流出が確認されていない情報が明確に区別されました。

流出可能性のある370件は、グループ会社マネーフォワードケッサイが提供するビジネスカードの利用者情報です。これらのカード情報がGitHub上に存在した理由について同社は、個人情報を含むファイルがサービス更新作業の過程で本来の管理手順から外れ、誤ってリポジトリ上に保管されていたためと説明しています。つまりソースコードそのものではなく、本番データ由来のファイルが手順を逸脱してリポジトリに置かれていたことが、カード情報流出の直接の原因です。一方、決済の不正利用にはカード番号全桁・有効期限・CVVの組み合わせが必要であり、これらが未流出であることは被害拡大を抑える重要な要素です。370件の対象者にはメール等で個別連絡が行われる方針のため、連絡がなければ基本的に対象外と理解して差し支えありません。ただし「現時点で確認されていない」は「今後も絶対にない」と同義ではないため、明細やログイン履歴の確認は継続するのが安全です。

連携が使えなかった間の対処法（「使えない」「更新できない」と感じたとき）

停止期間中に「マネーフォワードが使えない」「明細が更新できない」と感じた方が多くいました。実際に止まっていたのは銀行の自動取得部分だけで、アプリ自体は次のように利用できました。復旧後に同様の症状が出た場合の切り分けにも役立ちます。

• 利用できた機能：取得済み取引の閲覧・検索・タグ編集、手動での取引入力、家計簿の集計やカテゴリ別分析、クラウド会計の仕訳入力・帳簿出力、ログインやパスワード変更・二段階認証設定。
• 個人ユーザーの代替策：各金融機関のネットバンキングで明細を確認し、手動入力で当面をしのぐ。
• 法人・個人事業主の代替策：金融機関のネットバンキングから明細CSVをダウンロードし、マネーフォワード クラウドへインポートして記帳を継続する。

手動入力やCSVインポートで対応した取引は、連携再開時に金融機関側から再取得されて二重計上になることがあります。識別用のタグを付けておくと、復旧後の照合・整理が容易になります（再連携後の具体的な確認手順は後述します）。

利用者が実施すべきパスワード変更・二段階認証などの自衛策

本件でマネーフォワードからの直接的な情報漏洩（本番DB）は確認されていませんが、不安を解消し将来のリスクを下げるために、この機会に基本的なアカウント防御を見直すことをおすすめします。

• パスワード変更：マネーフォワードIDのパスワードを、他サービスと重複しない固有の文字列（英大小・数字・記号を混在、12文字以上目安）に変更する。公式サイトへはブックマーク経由でアクセスする。
• 使い回しの解消：同じパスワードを他サービスでも使っている場合、金融系・メールから優先して個別化する。パスワードマネージャーでの一元管理が有効。
• 二段階認証の有効化：認証アプリ（ワンタイムパスワード）を基本に、復元用としてSMSを設定。対応サービスではパスキーの利用も検討する。
• ログイン履歴の確認：身に覚えのないアクセスがないかを点検し、「新しい環境からログインがありました」の通知メールを見落とさない設定にしておく。
• フィッシング警戒：事案報道の直後は便乗メールが増える。送信元ドメインとリンク先URLを検証し、メール内リンクからではなく公式サイトから操作する。

「パスワード変更のメールが来ない」という場合は、登録メールアドレスが古い、または迷惑メールフォルダに振り分けられている可能性があります。受信設定と登録アドレスを確認し、それでも届かないときは公式サポート窓口に問い合わせてください。

復旧後にマネーフォワード利用者が確認しておくべきこと

速報記事の多くは停止と復旧の事実までで終わりがちですが、利用者が本当に困るのは「全再開後に自分の環境で何を確認すべきか」です。連携が全行で再開した今、次の点をチェックしておくと取りこぼしを防げます。

• 連携の再設定：停止中に連携が切れた口座は、アプリの口座一覧から再連携（再認証）を実施する。新規連携・更新・再連携はいずれも利用可能に戻っている。
• 取引の二重計上チェック：停止期間に手動入力・CSVインポートした取引と、再開後に自動取得された取引が重複していないかを照合し、重複分を削除・統合する。
• 未反映期間の補完：停止中に自動取得されなかった期間の明細が、再開後に正しく遡って取得されているかを確認する。
• 仕訳ルールの確認（法人）：自動仕訳の勘定科目・取引先タグが正しく適用されているかを点検し、暫定運用で入れたルールを元に戻す。
• 個別連絡の確認：ビジネスカード利用者は、370件対象の個別連絡が届いていないかをメールで確認し、案内があればカード再発行等の手続きを進める。

なぜ銀行連携を止めたのか：スクレイピングとAPI連携の違いから読み解く

「直接の被害が確認されていないのに、なぜ連携をすべて止めたのか」という疑問には、金融サービス特有の事情があります。マネーフォワードの銀行連携は金融機関ごとにスクレイピング方式とAPI連携方式のいずれかで実現されており、利用者の口座情報という極めて機微なデータを扱います。

同社は追加被害を防ぐ措置を即時に講じたうえで、それでも提携金融機関との安全性確認を万全にするために連携を停止しました。わずかな疑念も残さず、確認の整った金融機関から順次再開するという判断は、短期の不便より長期の信頼を優先した金融サービス事業者として合理的な対応と評価できます。利用者側は連携方式を意識する必要は基本的になく、銀行連携は全行で復旧しています。

再発防止とSaaS事業者の教訓（過去のSMBC事案との違い）

本件は、開発インフラであるGitHubのアカウント認証情報が突破口になった点で、SaaS事業者全般に共通する教訓を含みます。2021年に話題となったSMBC系のソースコード流出が、受託エンジニア個人による持ち出しという「内部関係者起点」だったのに対し、本件は第三者による認証情報窃取という「外部攻撃起点」である点が構造的に異なります。前者は契約・教育・委託管理の問題、後者は認証情報管理と多要素認証の問題であり、対策の方向性も変わります。

外部攻撃起点のインシデントを防ぐ要点は、GitHubのパーソナルアクセストークンを最小権限・短期有効期限で管理し定期的に棚卸しすること、ソースコードや本番データ由来ファイルへのシークレット直書き・誤保管を避け検知の仕組みを導入すること、そして全メンバーへの多要素認証の必須化です。シークレットの混入検知にはGitHub Code Scanningとは？概要と基本的な仕組みを解説で触れられているSecret Scanning機能が役立ち、設定ファイルの安全な管理にはdotenvxとは｜.envを暗号化してGitで安全に管理する仕組み・使い方・移行手順のようなアプローチが有効です。正規アカウントや配布経路が突破される攻撃の広がりは、週1億DLのaxiosを襲ったサプライチェーン攻撃の全容と開発者が直面したリスクとも共通しており、利用者・事業者双方が守備範囲をサプライチェーン全体へ広げる必要があります。

よくある質問（FAQ）

マネーフォワードの銀行口座連携はいつ復旧しましたか？

2026年6月5日午前10時50分に、すべての金融機関との連携が再開され銀行連携は完全復旧しました。5月1日の停止開始から約35日ぶりで、5月12日以降は安全性確認の整った一部金融機関から順次再開されていました。現在は新規連携・更新・再連携のいずれも通常どおり利用できます。なお証券・マイル・暗号資産など銀行以外の一部連携サービスには再開未定のものが残る場合があるため、対象の方は公式の最新案内をご確認ください。

今回の情報漏洩で何が流出したのですか？

流出した可能性が確認されたのは、マネーフォワードビジネスカード370件分の「カード保持者名（アルファベット）」と「カード番号の下4桁」です。これは個人情報を含むファイルが本来の管理手順から外れて誤ってGitHub上に保管されていたことが原因と公表されています。カード番号の全桁・有効期限・セキュリティコード（CVV）、および本番データベースに格納された顧客の取引情報は、現時点で流出が確認されていません。対象者にはメール等で個別連絡が行われます。

連携が使えない間はどう対応すればよかったですか？

止まっていたのは自動取得だけで、過去データの閲覧や手動入力、集計・分析機能は利用できました。個人はネットバンキングで明細を確認して手動入力、法人は明細CSVをダウンロードしてマネーフォワード クラウドへインポートする方法で記帳を継続できました。復旧後に明細が更新されない場合は、口座の再連携を試してください。

パスワードは変更すべきですか？変更メールが届かない場合は？

本番データベースからの漏洩は確認されていませんが、念のためマネーフォワードIDのパスワード変更と二段階認証の有効化を推奨します。特に他サービスと同じパスワードを使い回している場合は優先して変更してください。変更手続きのメールが届かないときは、登録アドレスの誤りや迷惑メール振り分けが考えられるため、受信設定を確認し、解決しなければ公式サポートへ問い合わせます。

なぜマネーフォワードは銀行連携をすべて止めたのですか？

銀行連携は利用者の口座情報という機微なデータを扱うため、追加被害を防ぐ措置を講じたうえでも、提携金融機関との安全性確認を完了させるまで連携を停止する判断がとられました。わずかな疑念も残さず、確認が整った金融機関から順次再開する慎重な進め方で、最終的に6月5日に全行が復旧しています。

関連記事

• GitHub Code Scanningとは？概要と基本的な仕組みを解説
• dotenvxとは｜.envを暗号化してGitで安全に管理する仕組み・使い方・移行手順
• 週1億DLのaxiosを襲ったサプライチェーン攻撃の全容と開発者が直面したリスク