マネーフォワードの銀行連携は危険？いつ復旧したかと不正アクセス事案の全容

マネーフォワードの銀行連携は、2026年5月1日にGitHubへの不正アクセスを受けて全面停止し、2026年6月5日10時50分にすべての銀行で再開しました（停止から約35日）。「銀行連携は危険か」という問いには、預ける情報の範囲で答えられます。API連携の銀行ではIDもパスワードも同社に渡らず、スクレイピングの銀行でもログイン情報は暗号化して別サーバに保管され、振込などに必要な情報は預けません。今回の事案でも、金融機関のログイン情報を格納する本番データベースへの侵害はないと同社は確認しています。本記事では、連携の仕組みから見た安全性、停止から復旧までの時系列、流出した情報の範囲、利用者が確認しておく点を、同社の公式発表とサポートサイトに基づいて整理します（2026年10月27日時点）。なお、2026年10月26日には外部サービス「Studio」経由で問い合わせフォームの入力データが流出した可能性も公表されましたが、これは銀行連携ともGitHub事案とも別の事案で、後半の章で切り分けます。

まとめ：マネーフォワードの銀行連携の安全性と復旧状況の要点

• 復旧状況：銀行口座連携は2026年6月5日10時50分に全行で再開。5月12日から準備の整った金融機関で順次再開していた。GitHub事案の最新の公式発表は6月23日の第四報で、10月27日時点で続報は出ていない。
• 連携は危険か：ほとんどの銀行はAPI連携で、同社はIDもパスワードも預からない。スクレイピングの銀行でも預かるのは閲覧用のログイン情報だけで、暗号化して家計データとは別のサーバに保管している。
• 事業者としての規律：同社は電子決済等代行業者（関東財務局長（電代）第3号）として各銀行と契約を結んでおり、連携で利用者に損害が出たときは同社が賠償・補償すると公表している。
• 流出した可能性のある情報：ビジネスカード370件（保持者名と番号下4桁）、顧客124名・取引先28名・従業員等2,300名の情報、単体では個人を特定できない固有識別子60,449名分。金融機関のログイン情報と家計・資産データは漏れていない。
• 10月26日の別事案：外部サービス「Studio」への不正アクセスで、グループの採用・コーポレート等のサイトの問い合わせフォーム入力データ計8,109件が流出した可能性がある。サービス本体と銀行連携への影響はない。
• 利用者の対応：同社は「パスワード変更等の対応をお願いする事項はない」としている。再開後は資産推移が遡って記録されないため、停止期間の推移は自分で修正する。
• 残るリスク：マネーフォワードIDそのものの乗っ取りにも備える必要がある。二段階認証かパスキーを設定し、新しい環境からのログイン通知メールを確認する。

マネーフォワードの銀行連携の危険性：預ける情報と賠償の仕組み

「銀行連携が危険か」は、連携のためにどの情報を誰に預けるかで決まります。マネーフォワード MEは金融機関ごとに2つの方式を使い分けており、預ける情報が方式で大きく違います。

銀行のAPI連携とスクレイピングで同社に預けるログイン情報の違い

同社サポートサイトの「金融機関のデータ管理とログイン情報はどうなっていますか」と「銀行を登録するために、セキュリティカードの内容を入力する必要があるのでしょうか」の記載を方式別に並べると次のとおりです。

API連携では、連携ボタンを押すと銀行のサイトへ移り、そこでログインして許可を出します。同社のヘルプは「暗証番号等を弊社でお預かりする仕組みではございません」と明記しています。スクレイピング方式は利用者のIDとパスワードを預かって代理でログインする仕組みですが、単独で資金移動に使えるログイン情報は原則として預からない方針です。同社は、金融機関のログイン情報はソースコードの一部ではなく、本番環境のデータベースに暗号化して保存していると説明しています。

同社は口座連携を、利用者の指示・同意に基づいて口座情報を取得し、サービス上に反映・表示する「アグリゲーションサービス」と位置づけています。同社のヘルプは銀行登録にセキュリティカードの入力は必要ないと明記しているため、連携画面で乱数表やセキュリティカードの番号を求められたら偽サイトを疑ってください。方式の一般的な違いはスクレイピングとは？クローリング・APIとの違いと実装・法務の判断を解説で、銀行側から見た外部連携の経路は金融のデータ連携｜行内3層と対外3経路の切り分けで解説しています。

電子決済等代行業の登録と銀行との契約が定める利用者への賠償の分担

銀行口座の情報を取得するサービスは、銀行法上の電子決済等代行業にあたります。同社サポートサイトは、銀行法改正により電子決済等代行業者は「各銀行と個別に契約を締結し、契約に従って、より安全な形でサービスを提供することが求められて」いると説明しています。株式会社マネーフォワードは2018年10月1日に登録を受けており、登録番号は「関東財務局長（電代）第3号」です（金融庁の電子決済等代行業者登録一覧で確認できます）。マネーフォワード MEの公式サイトからも、同社の電子決済等代行業に関する表示等へリンクされています。

同じページでは、銀行等との契約内容の一部が公表されています。利用者に関わるのは次の3点です。

• 損害の賠償：API接続またはスクレイピング接続で提供するサービスで利用者に損害が発生した場合、同社が利用者に賠償または補償する。銀行に原因があれば、同社は銀行へ求償できる場合がある。銀行の責任と考えられる一定の場合は、銀行が利用者に賠償することもある。
• 安全管理の義務：同社は、不正アクセスや情報漏えいを防ぐため、各銀行が求めるセキュリティ対策を行う。
• 銀行による停止：同社の利用者情報の取扱いや安全管理措置が不適切と判断した場合などに、銀行はAPI接続等を停止したり契約を解除したりできる。

利用者への賠償は原則として同社が受け持ち、銀行との責任の線引きは事業者同士で行う構造です。ただし賠償の具体的な範囲は、同社の利用規約と各銀行との契約内容に従います。

2026年の不正アクセスにおける本番データベースの侵害確認結果

今回の事案で侵入されたのは、開発に使うGitHubのリポジトリです。金融機関のログイン情報は本番データベースに暗号化して保存されており、同社は第二報で、本番データベースに格納された情報（金融機関等連携先のログインに必要な情報や家計・資産情報を含む）の漏えいや、本番環境への侵害・改ざんはないと確認しています。ただし、開発用のリポジトリと本番環境が分かれていたことが侵害を防いだ直接の理由かどうかは、公表内容だけでは判断できません。

一方で、個人データを含むファイルがリポジトリに保管されていたため、ビジネスカード370件などの情報が流出した可能性があると公表されました。銀行連携の仕組みは破られていませんが、事業者側の運用の穴は実際に突かれています。本番データベースへの侵害がなかったことは、今回の事案についての調査結果であり、銀行連携に危険がまったくないことの保証ではありません。利用するかどうかは、預ける情報の範囲に加えて、事業者側の情報管理と、停止時に連携が止まる影響も含めて判断してください。

利用者側に残るマネーフォワードIDの乗っ取りリスクと認証設定の対策

銀行連携の安全性とは別に、利用者のマネーフォワードIDそのものが乗っ取られるリスクにも備える必要があります。同社は2024年8月のマネーフォワード IDの管理に関する注意とお願いで、第三者がユーザーのアカウントを乗っ取って「マネーフォワード クラウド請求書」を不正利用した事象を公表しています（同社システムへの侵害は確認されていないとしています）。家計簿のアカウントが乗っ取られれば、連携している口座の残高や取引履歴を第三者に見られるおそれがあります。

公式の注意喚起や設定ガイドを踏まえ、利用者が確認する対策を次に整理します。認証やアプリロックは設定画面で見直し、ログイン通知は届いたメールの内容を確認します。

1. パスワードの使い回しをやめる：他サービスと同じパスワードなら、マネーフォワード ID専用のものに変える。
2. 二段階認証かパスキーを設定する：二段階認証は認証アプリのワンタイムパスワードを使う方式。二段階認証・パスキー・サービス連携でログインする場合は、2025年3月から対象が広がったメールの追加認証も発生しない。
3. ログイン通知メールを確認する：新しい環境からログインがあると「マネーフォワード ID 新しい環境からログインがありました」という件名のメールが届く。心当たりがなければすぐにパスワードを変える。
4. アプリにパスコードロックをかける：スマートフォンの紛失に備え、パスコードと指紋・顔認証のロックを有効にする。

二段階認証と多要素認証の違いは二段階認証とは？二要素認証・多要素認証との違いで、パスキーの仕組みはパスキー認証とは？仕組み・パスワードとの違いで解説しています。

マネーフォワードの銀行連携停止から全行復旧と確定報告までの時系列

「いつ復旧するのか」という疑問は、2026年6月5日の時点で解決しています。停止から確定報告までの公表は次のとおりです。

各日付の根拠は、同社の第一報、第二報、第三報、第四報と、追記が時系列で積み上がっているマネーフォワード ME サポートサイトの告知です。全行再開の時刻は、同サポートサイトの銀行口座連携再開の進捗についての最終更新（6月5日10時50分）で確認できます。

同社のお知らせ一覧では、第四報より後にGitHub事案の続報は出ていません（2026年10月27日に確認）。7月以降のお知らせは、サービスの提供終了・名称変更・料金改定などの別件で、10月26日のStudio経由の問い合わせフォーム流出の公表も本件とは別の事案です。

銀行以外の連携（証券・マイル・暗号資産など）の停止は、同社が常設している「システム対応中で口座連携が正常に行えていない金融関連サービスの一覧」で案内されます。この一覧には本件と無関係な理由の停止も載るため、掲載されているだけでは本件の影響と判断できません。自分の口座がエラーのままなら、マネーフォワードで連携できない・失敗するときの対処法で切り分けてください。

何が起きたのか：GitHub認証情報の漏えいから始まった不正アクセス

本件はコードの脆弱性ではなく、認証情報の漏えいが起点です。マネーフォワードグループがソフトウェア開発とシステム管理に使うGitHubの認証情報が第三者に渡り、リポジトリに含まれるソースコード等が閲覧・コピーされました。同社は検知後に経路となった認証情報を無効化してアクセスを遮断し、第二報の時点で全社的な認証情報の刷新を完了しています。

認証情報がどう漏れたか（フィッシング、端末のマルウェア感染、委託先経由など）は、第四報でも公表されていません。手がかりは第四報の再発防止策で、「本件の発端となった認証情報の漏えいへの対策として、業務端末におけるセキュリティ統制をさらに強化」し、認可外の外部サイトやクラウドサービスへのアクセスをシステム的に遮断する仕組みを構築したと書かれています。業務端末とWeb通信の側に手を入れたことは読み取れますが、経路を特定した記述ではありません。

流出した可能性のある情報：ビジネスカード370件と第四報の追加判明分

第一報の時点で判明していたのはビジネスカード370件だけでしたが、6月23日の第四報で精査が完了し、範囲が確定しました。

従業員・退職者の内訳は、名寄せ後で固有識別子373・氏名490・メール1,807・電話305です。カード番号の全桁・有効期限・セキュリティコードと、本番データベースの家計・資産情報は流出の対象に含まれていません。

件数が大きく見える60,449名分は、同社がユーザーを区別するための内部番号です。第四報のよくある質問では、氏名やメールアドレスは含まれず、番号単体から氏名や口座情報を特定することも外部から紐づけることもできない仕組みだと説明されています。それでも同社は法令に従って公表し、連絡先を把握している対象者にはメールで個別に案内済みです。

カード情報がGitHubにあった理由は、個人情報の取り扱いを伴うサービス更新作業の過程で、個人情報を含むファイルが本来の管理手順から外れて保管されていたためと説明されています。6月23日付で個人情報保護委員会と事業所管大臣への確定報告が提出され、同日時点で二次被害やそのおそれは確認されていません。速報と確報の2段階で求められる報告の制度は個人情報保護委員会への報告義務（速報3〜5日と確報30日の実務）で整理しています。

10月26日公表のStudio経由の問い合わせフォーム流出はGitHub事案とは別件

2026年10月26日、同社は外部サービス「Studio」への不正アクセスに伴う、お問い合わせフォームにおける個人データ流出の可能性に関してを公表しました。グループの一部Webサイトの制作に使っていたノーコードのサイト作成サービス「Studio」が不正アクセスを受け、そのサイトに置いた問い合わせフォームの入力データが流出した可能性がある、という内容です。5月のGitHub事案とは侵入された場所も原因も異なる別の事案で、銀行連携とも関係がありません。

Studio経由で入力情報が流出した可能性のあるフォームと会社別の件数

同社の公表では、対象はStudioで作ったサイトの問い合わせフォームに限られます。会社別の件数は次のとおりで、合計は8,109件です。

対象の項目は、フォームに入力された氏名・企業名・メールアドレス・電話番号・問い合わせ内容などです。採用選考への応募情報（履歴書や職務経歴書の内容、応募フォームの入力内容）は含まれないと明記されています。マネーフォワード MEやマネーフォワード クラウドといったサービス本体への影響や情報流出もありません。家計簿アプリに登録した口座情報や、銀行連携のログイン情報が漏れた事案ではない点を押さえておいてください。

Studio社が公表した不正アクセスの経緯と暗号化していたデータの扱い

経緯はStudio社の不正アクセスによる情報流出に関するお詫びとお願い（第一報）に書かれています。第三者が一部機能の脆弱性を悪用して同社のクラウド環境にアクセスしたのは2026年9月30日〜10月1日（日本時間・確認できている期間）で、同社は10月13日に社内調査で不正アクセスを確認し、10月14日までに脆弱性の修正と経路の遮断を終えました。外部からデータを取得できる状態は、この対処まで続いていたとされています。

Studio社は、フォームに送信された内容を暗号化して保存していたものの、復号に必要な鍵も同じ不正アクセスで読み出されたため、内容を知られた可能性があると説明しています。第三者が実際にデータを取得した事実は確認されていませんが、取得されたものとみなして対応しているとのことです。マネーフォワードは10月16日にStudio社から報告を受け、Studio上の問い合わせフォームをすべて停止して別システムへ切り替えました。10月26日から、対象者の登録メールアドレスへ順次個別に案内を送っています（いずれも10月27日時点の公表内容）。

フォームに入力した人が確認する案内と開発組織が見直す外部サービスの管理

銀行連携の利用者として何かを変更する必要はありません。採用サイトやコーポレートサイトの問い合わせフォームに入力した覚えがある人は、同社からの案内メールを確認し、本件に便乗した不審なメールや電話に注意してください。同社はメールや電話でパスワードや暗証番号を尋ねることはないとしています。漏れた可能性があるのは氏名・企業名・メールアドレス・電話番号の組み合わせなので、宛名や問い合わせ内容を引用して信用させる標的型メールが届いても不自然ではありません。

開発や情報システムを担う側にとって、2つの事案は対照的です。GitHub事案は自社の認証情報と開発リポジトリの管理が起点でした。Studio事案は自社の統制が及ばない外部SaaSが起点で、問い合わせフォームのような周辺の仕組みでも、委託先の鍵管理が破られれば暗号化は守りになりません。外部サービスに個人データを預けるなら、保存の要否（Studioではフォーム結果の保存を無効にできる）、保存期間と削除の運用、事故時に誰が本人へ通知するかを契約前に確かめておきます。委託先やSaaSを経由して被害が広がる攻撃の類型はサプライチェーン攻撃とは？起点別3類型と最新事例・対策の優先順位で整理しています。

銀行連携の全行停止の理由と各提携金融機関での確認に基づく順次再開の条件

直接の被害が確認されていない段階で全連携を止めた理由を、同社は「各提携金融機関との安全性の確認を万全なものとするため」と説明しています。再開には、同社の追加対策の完了と、各提携金融機関での最終確認の両方が必要でした（第二報）。

これは、前述の銀行との契約内容とも一致します。公表されている契約内容には、不正アクセスや情報流出の具体的な可能性を認識した場合に、銀行と同社が速やかに対策を講じたうえで協力して原因究明と対策を行うこと、同社の安全管理措置が不適切と判断した場合に銀行がAPI接続等を停止できることが定められています。連携は同社だけの判断で再開できるものではなく、銀行ごとに確認が済んだ順に戻る構造です。5月12日に一斉ではなく順次の再開となり、全行がそろうまで約35日かかったのはこのためと考えられます。

プレミアムサービスの購読期間延長は、停止していた5月1日〜5月12日にプレミアムサービスを利用していた人（無料お試し期間中を含む）が対象です。同社はこの中断を、利用規約上のサービス継続性保証の「使用不能時間」には当たらないとしたうえで、お詫びとして延長しています。対象者のうち、適用時点でプレミアムサービスを解約して無料会員に戻っている人は、システムの都合で期間を延長できないため、代替として15日間利用できるクーポンを登録メールアドレスに送るとしています。

銀行連携の停止中に使えた機能と復旧後に利用者が確認する資産推移と重複取引

停止期間中に止まっていたのは銀行明細の自動取得で、アプリ自体は使えました。取得済み取引の閲覧・検索、手動入力、集計・分析は利用でき、法人はネットバンキングの明細CSVをマネーフォワード クラウドへ取り込んで記帳を続けられました。

全行の再開後に確認しておく点は次のとおりです。優先度の高い順に並べています。

1. 資産推移の修正：同社は、連携が停止していた期間の資産推移は遡って自動で記録されないと案内している。グラフに欠けがあれば、サポートサイトの「推移の修正」の手順で補う。
2. 二重計上の照合：停止中に手入力・CSV取込した取引と、再開後に自動取得された取引が重複していないかを確かめる。同社は手入力と自動取得のデータは統合できないとしており、重複分は計算対象外にするか、手入力側を削除する。
3. 再連携：再開済みの金融機関でも再連携操作が必要な場合がある。紀陽銀行・佐賀銀行・京都中央信用金庫など、進捗ページで「再連携操作が必要です」と付記された金融機関は特に確認する。
4. 個別案内の確認：ビジネスカード利用者や取引先は、同社からのメール案内が届いていないかを確認する。

再連携は口座を削除せずに行います。口座を削除すると過去分を含めたデータが消えるため、エラーの種類ごとの直し方は前述の連携できないときの対処法を参照してください。

パスワード変更の必要性に関する同社の公式見解と利用者が任意で見直す範囲

同社は第二報（5月11日）で、本番データベースの漏えいや改ざんがなく、資産や認証に直接影響するものは確認されていないとして「現時点でパスワード変更等の対応をお願いする事項はございません」と明記しました。第四報のよくある質問でも、パスワード変更等の対応は必要ないと改めて回答しています。会社としてパスワード変更を求めてはいない、というのが公式の立場です。

そのうえで、事故に便乗したフィッシングにも注意してください。流出した可能性のあるメールアドレス（顧客24件・取引先23件）の持ち主は、マネーフォワードを名乗る標的型メールの宛先になりうる立場です。「確認のため再ログインを」といったメールのリンクは踏まず、ブックマークした公式サイトやアプリから操作してください。パスワードの使い回し解消と二段階認証は、前述の「利用者側に残るリスク」の手順で行えます。

同社の再発防止策の中身と開発組織が取り組む認証情報の統制と機密混入の検知

同社が公表した再発防止策は、第二報と第四報の2段階に分かれます。

開発組織が自社に持ち帰るなら、優先順位は「認証情報の統制」と「機密混入の検知」です。GitHubのアクセストークンは用途ごとに分け、fine-grained PATで対象リポジトリと有効期限を絞ります。作り分けと期限の考え方はGitHub PAT（Personal Access Token）とは？作成方法・classicとfine-grainedの違いを参照してください。混入の検知は、GitHub側のsecret scanning（公式ドキュメント）と、ローカルやCIで走らせるスキャナを組み合わせます。

次の例は、OSSのgitleaks（最新はv8.30.1）で、既存リポジトリの全履歴を走査する手順です。v8.19以降は detect ではなく git と dir のサブコマンドを使います。検出値をログに残さないよう --redact を付けます。

# 前提: gitleaks v8.19以降をインストール済み（macOS例: brew install gitleaks）
# リポジトリのルートで、ローカルに取得済みの全参照から辿れる履歴を走査する
# 浅いクローンや未取得のブランチは対象外。検出値を伏せ字にしてJSONに保存する
gitleaks git -v --redact --log-opts="--all" --report-path gitleaks-report.json .

# コミット前に作業ツリーだけを確認する（履歴を見ないので速い）
gitleaks dir -v --redact ./

gitleaksが拾うのはAPIキーやトークンの形をした文字列で、本件のような「顧客名やメールアドレスを含むファイル」は既定ルールでは検出されません。個人データの混入は、.gitignore で個人データの出力先を除外する（追跡済みファイルや過去の履歴には効かないため、既存の混入は別途調査・対処する）、本番データを開発端末へ持ち出す手順そのものを無くす、といった運用側の統制で塞ぐ必要があります。認証を固めても、リポジトリに本番データ由来のファイルが残っていれば、次に認証が破られたときに同じことが起きます。リポジトリに個人データを置く運用が一つでも残っているなら、トークンの棚卸しより先にそれを止めてください。

gitleaksの設定と誤検知の扱いはgitleaksとは？使い方・設定とBetterleaksへの移行判断で、CodeQLによる静的解析はGitHub Code Scanningとは？CodeQLの設定手順で、.envの暗号化管理はdotenvxで.envを暗号化してGitで管理する手順で解説しています。CI/CDにシークレット検出やブランチ保護を組み込む作業を社内だけで進めにくい場合は、DevOps・CI/CD導入支援で設計から伴走できます。

よくある質問

マネーフォワードの銀行連携と2026年の不正アクセスについて、検索の多い質問に2026年10月27日時点の公表内容で答えます。

マネーフォワードと銀行との連携は安全ですか？

ほとんどの銀行はAPI連携で、ログインは銀行側のサイトで行うため、同社はIDも暗証番号も預かりません。API連携に対応していない銀行では閲覧用のログイン情報を預かりますが、暗号化して家計データとは別のサーバに保管し、振込など資金移動に必要な情報は預かりません。同社は電子決済等代行業者（関東財務局長（電代）第3号）として各銀行と契約しており、連携で利用者に損害が出た場合は同社が賠償・補償すると公表しています。

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

2026年6月5日10時50分に、すべての銀行の連携が再開されました。5月1日の停止から約35日で、5月12日以降は最終確認と接続準備が済んだ金融機関から順次再開していました。本件による一時停止は解消しています。その後の個別の障害やメンテナンス、証券・マイルなど銀行以外の連携の状況は、サポートサイトの「システム対応中で口座連携が正常に行えていない金融関連サービスの一覧」で確認してください。

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

流出した可能性があると公表されたのは、ビジネスカード370件（保持者名アルファベット・番号下4桁）、顧客124名分（氏名またはメール）、取引先28名分、従業員・退職者2,300名分、単体では個人を特定できない顧客の固有識別子60,449名分です。カード番号の全桁・有効期限・セキュリティコードと、金融機関のログイン情報・家計・資産情報は流出していません。このほか2026年10月26日に、外部サービス「Studio」で作った採用・コーポレート等のサイトの問い合わせフォームについて、入力データ計8,109件が流出した可能性があると公表されました。こちらはGitHub事案とは別件で、マネーフォワード MEなどサービス本体の情報は含まれません。

パスワードは変更すべきですか？

同社は「現時点でパスワード変更等の対応をお願いする事項はございません」としており、会社として変更は求めていません。ただし他サービスと同じパスワードを使い回している場合は、マネーフォワード ID専用のものに変え、二段階認証かパスキーを設定しておくと乗っ取りへの備えになります。

停止していた期間の資産推移は自動で戻りますか？

戻りません。同社は、連携が停止していた期間の資産推移は遡って自動で記録されないと案内しており、利用者がサポートサイトの手順で推移を修正する必要があります。取引明細は再開後に可能な範囲で遡って取得されますが、取得対象期間を過ぎた履歴は反映されない場合があります。未反映分と、停止中に手入力した取引との二重計上を確認してください。

関連記事

• マネーフォワードで連携できない・失敗するときの対処法｜エラー別の原因と再連携のやり方
• スクレイピングとは？クローリング・APIとの違いと実装・法務の判断を解説
• 二段階認証とは？二要素認証・多要素認証との違いと企業の導入判断を解説
• GitHub PAT（Personal Access Token）とは？作成方法・classicとfine-grainedの違い・確認と失効
• gitleaksとは？使い方・設定とBetterleaksへの移行判断
• サプライチェーン攻撃とは？起点別3類型と最新事例・対策の優先順位