住宅省エネキャンペーン不正アクセス：2万3918人の漏えい範囲と事務局メールの見分け方

住宅省エネ2024キャンペーンの事務局を務める博報堂のシステムに外部から不正操作があり、補助金の申請に登録していた事業者の情報が漏えいした可能性があります。国土交通省・経済産業省・環境省が2026年10月20日に公表した速報値は23,918名（16,950事業者）です。本記事の前半では、公式発表で確認できる対象・項目・対象外の情報と、子育てエコホーム支援事業の手続きへの影響を整理しました。中盤は登録事業者と施主に向けて、事務局を名乗るメールや電話への対処をまとめています。後半は開発者向けに、事務局の送信元ドメインをDNSで実測した結果と、受信メールの真偽を判定するPythonスクリプト、年度を越えて事業者情報を持ち続ける申請システムの見直し方を示します。

まとめ：住宅省エネ2024キャンペーン不正アクセスで公表された範囲と当面の対応

漏えいの可能性があるのは、令和5〜6年度に実施された4事業の登録事業者の情報です。補助事業を利用した施主（消費者）の個人情報と、住宅省エネ2026キャンペーンなど他年度の登録事業者情報については、漏えいは確認されていないとされています。

登録事業者がいま行うのは、事務局を名乗るメールの送信元を確かめることと、IDやパスワード、口座情報を尋ねる連絡に応じないことの2つです。施主の側は、工事を頼んだ事業者の名前をかたる営業や、行政機関を装う電話に注意します。

公式発表で確かめる住宅省エネ2024キャンペーン不正アクセスの漏えい範囲と経緯

対象は令和5〜6年度の4事業に登録した23,918名・16,950事業者

国土交通省の10月20日の報道発表によると、不正操作を受けたのは、事務局の博報堂が補助金の申請を受け付けるために運営していたシステムです。住宅省エネ2024キャンペーン事務局のお知らせは、対象の事業を次の4つと示しています。

• 子育てエコホーム支援事業（国土交通省）
• 先進的窓リノベ2024事業（環境省）
• 給湯省エネ2024事業（経済産業省）
• 賃貸集合給湯省エネ2024事業（経済産業省）

23,918名という人数は速報値で、重複や追加の登録がないかを調べている段階です。3省が共同で進めたキャンペーンのため、問い合わせ先も事業ごとに3省に分かれています。

漏えいの可能性がある項目と、口座情報や施主の情報など対象外の範囲

漏えいの可能性があるとされた情報は、立場ごとに項目が違います。

統括アカウント担当者は、各社1名が登録する補助金の窓口役です。メールアドレスが漏れた可能性が最も具体的にあるのはこの担当者で、フィッシングの的になりやすい立場にあります。事務局は、補助金振込用の口座情報、代表者の電話番号・メールアドレス・住所、施主の個人情報は漏えいしていないとしています。

10月20日の公表から全システム停止と子育てエコホームの再開予定まで

事務局は被害の拡大を防ぐために全システムの機能を止めました。子育てエコホーム支援事業のお知らせでは、点検と再発防止策を終えたのち、完了実績報告の受付などに必要な機能に限って再開する予定です。共通ポータルと専用ポータルには点検期間中ログインできません。

原因や侵入の時期は公表されておらず、国土交通省は博報堂に原因の調査と再発防止の徹底を指示しました。本記事は10月24日に3つの公式ページを確認した時点の内容です。その時点で続報は出ていませんでした。

登録事業者と施主が確かめる事務局メールの真偽と不審な連絡への対処

事務局の送信元ドメイン2つと、事務局が尋ねないと明言した情報

事務局は10月20日、統括アカウントに登録されたメールアドレス宛てに、お詫びと注意喚起のメールを送りました。お知らせに載っている送信元のドメインはjutaku-shoene.jpです。個人情報の漏えいに関する問い合わせフォームへの返信は、別のドメインkosodate-ecohome2024.jpから届きます。

ドメインが2つあるため、見慣れない方を偽物と決めつけるのも、似た名前を本物と信じるのも危険です。事務局は、アカウントIDやパスワード、口座情報などを尋ねることはないと明言しています。これらを入力させるメールは、送信元がどちらに見えても開かずに削除し、事務局のお知らせに載っている電話番号へ確認してください。社内でまとめて注意を促すときの手口の整理はフィッシングの手口と見分け方が使えます。

施主に届く事業者名をかたる営業電話と、住まいるダイヤルの使い分け

施主の個人情報は漏えいが確認されていません。ただし事務局は、漏れた事業者名を使って住宅の所有者に不正な営業をかける手口や、行政機関や事務局を装う電話にも注意を呼びかけています。工事を頼んだ会社の名前で「補助金の追加手続き」を持ちかけられたら、手元の契約書にある番号へ自分からかけ直します。

消費者向けの相談先は、事務局の電話相談窓口と、住宅リフォーム・紛争処理支援センターの住まいるダイヤル（03-3556-5147）の2つです。補助金の手続きの真偽は事務局へ、業者とのトラブルや勧誘の相談は住まいるダイヤルへ、と分けると話が早く進みます。

子育てエコホームの完了報告の期限と、システム停止中に事業者が控える作業

子育てエコホーム支援事業の完了報告は、システムが止まっている間は提出も不備の訂正もできません。事務局は、不備訂正の期限を機能の点検後に改めて設定するとしています。一方で、11階以上の住宅の完了報告の提出期限（令和9年2月28日）は変わりません。

停止中に事業者ができるのは、提出書類を手元でそろえておくことに限られます。再開を知らせるメールが届いたときも、リンクからログインせず、ブックマークした公式サイトから入るほうが安全です。

事務局メールの真偽をDNSとAuthentication-Resultsで判定する手順

DNSで実測した送信元2ドメインのSPFとDMARC（p=quarantine）の意味

2つの送信元ドメインが送信ドメイン認証をどう設定しているかは、DNSで誰でも確かめられます。10月24日にGoogle Public DNSで取得した値は次のとおりです。同じ値をdigで引くコマンドと並べます。

# 送信を許可するサーバー（SPF）
dig +short TXT jutaku-shoene.jp
"v=spf1 include:amazonses.com include:webcas.net ~all"

# 認証に失敗したメールの扱い（DMARC）
dig +short TXT _dmarc.jutaku-shoene.jp
"v=DMARC1;p=quarantine;pct=100;fo=1"

# 問い合わせへの返信に使うドメイン
dig +short TXT kosodate-ecohome2024.jp
"v=spf1 include:amazonses.com ~all"
dig +short TXT _dmarc.kosodate-ecohome2024.jp
"v=DMARC1;p=quarantine;pct=100;fo=1"

両ドメインとも、送信元にAmazon SESを許可し、DMARCはp=quarantineです。RFC 9989の定義では、この方針はSPFとDKIMのどちらでも認証に合格しないメールを、受信側に迷惑メールとして扱うよう求めます。p=rejectと違って受信を拒否まではしないため、送信元を詐称したメールが迷惑メールフォルダに届く余地は残ります。迷惑メールフォルダにある「事務局」からのメールは、それだけで疑ってよい材料です。DMARCの方針の違いはDMARCの仕組みとレコードの書き方で解説しています。

PythonでAuthentication-Resultsを読み公式ドメインと照合する

受信したメールが本当にそのドメインから届いたかは、受信側のメールサーバーが付けるAuthentication-Resultsヘッダーに書かれています。書式を定めているのはRFC 8601という仕様です。メールソフトからメールを.eml形式で保存し、次のスクリプトに渡すと判定できます。

import re
import sys
from email import policy
from email.parser import BytesParser

# 事務局のお知らせ（2026年10月20日）に載っている送信元・返信元のドメイン
OFFICIAL = {"jutaku-shoene.jp", "kosodate-ecohome2024.jp"}

def check(path):
    with open(path, "rb") as f:
        msg = BytesParser(policy=policy.default).parse(f)
    sender = msg["From"].addresses[0].domain.lower() if msg["From"] else ""
    # 最上段の Authentication-Results が、最後に受け取った自社側サーバーの判定
    results = msg.get_all("Authentication-Results") or [""]
    top = str(results[0]).lower()
    dmarc = re.search(r"dmarc=(\w+)", top)
    header_from = re.search(r"header\.from=([\w.-]+)", top)
    print("From のドメイン :", sender or "(なし)")
    print("DMARC の判定    :", dmarc.group(1) if dmarc else "(記録なし)")
    ok = (sender in OFFICIAL and dmarc is not None and dmarc.group(1) == "pass"
          and header_from is not None and header_from.group(1) == sender)
    print("判定            :", "公式ドメインからの正規の送信" if ok else "要注意（開かずに窓口へ確認）")

if __name__ == "__main__":
    check(sys.argv[1])

python check_sender.py mail.emlのように実行します。読み込みにはPythonの標準モジュールemail.parserを使うので、追加のインストールは要りません。本記事ではPython 3.14.7で試験用のメール4通を判定させ、公式ドメインかつdmarc=passの1通だけが正規、似せたドメイン・dmarc=fail・ヘッダーなしの3通が要注意になることを確かめました。

似せたドメインはDMARCに合格する：完全一致で照合すべき理由と限界

DMARCが証明するのは「Fromに書かれたドメインの持ち主が送った」ことだけです。攻撃者がjutaku-shoene2024.comのような似たドメインを取得して自分で設定すれば、そのメールはdmarc=passになります。スクリプトがOFFICIALとの完全一致を条件にしているのはこのためです。

最上段のヘッダーだけを読むのにも理由があります。送信者は自分でAuthentication-Resultsを書き足せるため、下の段にある「pass」は信用できません。RFC 8601も、自分の管理するサーバーが付けたヘッダーだけを使うよう求めています。社外のサーバーを経由する転送設定があると最上段が別の判定になる場合があり、その環境ではヘッダーの付与元（mx.google.comなど先頭の名前）も確かめてください。

年度を越えて登録事業者情報を持ち続ける補助金申請システムの設計の見直し

終了した事業の登録データが2026年10月も同じシステムから取得できた構造

侵入の手口は公表されていません。公表から確かに読めるのは、令和5〜6年度の4事業の登録事業者情報が、2026年10月の時点でも同じシステムから取得できる状態にあった点です。子育てエコホーム支援事業には令和9年2月まで続く完了報告があり、システムを動かし続ける理由はありました。

ただ、手続きが残っているのは一部の案件です。受付を終えた窓リノベや給湯省エネの事業者情報まで、オンラインの機能から読める位置に置き続ける必要はありません。他年度の情報は漏えいが確認されていないとされており、年度で分ける設計がとられていた可能性があります。それなら同じ考え方を、年度の中の「受付中か、終了済みか」にも広げられます。使い終えたデータを消す設計は移行済み基盤に残る旧データの消去設計と退職者データを残さない人事システムの設計でも扱いました。

PostgreSQLの行単位セキュリティで受付中の案件だけをアプリに見せる

データベースがPostgreSQLなら、アプリが使うロールから見える行を、受付中の案件に紐づくものだけに絞れます。行単位セキュリティ（Row Security Policies）の例です。表名と列名は説明用のもので、事務局のシステムの構成ではありません。

-- アプリ用ロール portal_app からは、完了報告を受付中の案件の事業者だけを見せる
ALTER TABLE registered_business ENABLE ROW LEVEL SECURITY;

CREATE POLICY portal_open_cases ON registered_business
  FOR SELECT TO portal_app
  USING (program = 'kosodate_ecohome' AND report_status = 'open');

-- 受付を終えた事業の表は、アプリ用ロールから権限ごと外す
REVOKE ALL ON TABLE registered_business_mado_2024 FROM portal_app;
REVOKE ALL ON TABLE registered_business_kyuto_2024 FROM portal_app;

公式ドキュメントのとおり、行単位セキュリティは表の所有者、スーパーユーザー、BYPASSRLS属性を持つロールには効きません。アプリの接続ユーザーが表の所有者を兼ねていると、この設定は素通りになります。終了した事業の表はREVOKEでアプリから外し、集計や監査は別のロールで行います。上のSQLは本記事の環境では実行しておらず、PostgreSQL公式ドキュメントの構文に基づく記載です。

この設定で、アプリのロールを奪われても一度に読める範囲は受付中の案件に縮みます。侵入口そのものを塞ぐ認可やレート制限はAPI不正アクセス対策の実装手順を参照してください。

委託先が運用する公的システムで発注者が契約に書いておく点検項目

今回のシステムは、国の補助事業の事務を受託した事業者が運営していました。委託先のシステムで起きた事故でも、登録した事業者や施主から見れば窓口は発注者です。発注者が契約や仕様書に入れておくべき点検項目は、次の4つです。

1. 事業の受付が終わった時点で、オンラインの機能から読めるデータを縮める期日と方法
2. アプリの接続ユーザーと、表の所有者・管理者ユーザーを分けていることの証跡
3. 事業者の統括アカウントに多要素認証を求めるか、求めない場合の代わりの対策
4. 大量の閲覧や出力を検知したときに、誰がいつまでにシステムを止めるかの手順

実務で最初に確かめるのは1つ目です。終わった事業のデータが残っていても、平時の運用では何も困らないため、期日を書かない限り残り続けます。委託先の管理が論点になった例は口座番号を委託先に残さない設計で、公的システムでの不正アクセスの例はデジタル庁GSSの不正アクセスで取り上げました。申請受付システムの権限設計やデータの置き場所を外部の目で点検するなら、脆弱性診断・セキュリティ診断で相談できます。

よくある質問

住宅省エネ2024キャンペーンの不正アクセスについて、登録事業者や施主から出やすい質問をまとめました。

住宅省エネキャンペーンの不正アクセスで漏れた情報は何ですか？

漏えいの可能性があるのは、法人の代表者の氏名と肩書、個人事業主の氏名と住所、統括アカウント担当者の氏名・部署・役職と業務用の住所・電話番号・メールアドレスです。対象は令和5〜6年度の4事業の登録事業者で、速報値は23,918名（16,950事業者）です。口座情報は漏えいしていないとされています。

補助金を使って工事をした施主の個人情報も漏れましたか？

事務局と国土交通省の発表では、補助事業を利用した消費者（共同事業者）の個人情報の漏えいは、現時点で確認されていません。ただし工事をした事業者の名前は漏れた可能性があり、その名前をかたる営業や、事務局・行政機関を装う電話に注意が呼びかけられています。

事務局から届いたお詫びメールは本物ですか？

事務局は10月20日に、統括アカウントに登録されたメールアドレス宛てに、jutaku-shoene.jpのアドレスからお詫びと注意喚起を送ったとしています。送信元のドメインが完全に一致し、IDやパスワード、口座情報の入力を求めていないかを確かめてください。迷ったら公式サイトに載っている電話番号へ問い合わせるのが確実です。

住宅省エネ2026キャンペーンの申請にも影響がありますか？

事務局は、住宅省エネ2026キャンペーンなど他年度の同種事業について、登録事業者情報の漏えいは確認されていないとしています。2026年の事業のシステムの稼働状況については、今回の公表文に記載がありません。手続きの可否は、それぞれの事業の公式サイトのお知らせで確かめてください。

不正アクセスの原因は何ですか？

10月24日時点で、原因と詳細な被害状況は博報堂が調査中で、手口や侵入の時期は公表されていません。国土交通省は同社に原因の調査と再発防止の徹底を指示しています。委託先で起きた漏えいの報告の考え方は個人情報保護委員会への報告義務の実務と個人情報保護委員会の案内で確かめられます。

関連記事

• API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効：申請システムへの侵入口を塞ぐ対策
• PFUの不正アクセスと最大16万件の注文データ漏えい｜移行済みEC基盤に残る旧データの消去設計：使い終えたデータが残って漏れた別の事例
• デジタル庁GSSの不正アクセスと約24.6万件｜CVSS中のVPN脆弱性を何で優先するか：公的なシステムで起きた同時期の事例
• DMARCとは？仕組み・SPFやDKIMとの違い・レコードの書き方を解説【2026年版】：送信元ドメインの詐称を防ぐ仕組み
• 情報漏洩対策とは：原因別4類型の防ぎ方と発生時の報告義務【2026年10月版】：委託先経由を含む漏えいの防ぎ方