外務省の不正アクセスと約3,600件の漏えい｜メールに残る個人情報を数えて減らす手順

外務省は2026年10月30日、外部とのやり取りが可能なネットワークが不正アクセスを受け、個人情報を含むメール等の一部が漏えいした可能性があると公表しました。対象はメールアドレスや氏名など約3,600件で、うち約900件は外務省員以外の人のものです。本記事では、公式発表に沿って検知から公表までの経過を確認したうえで、メールが漏えい元になったときに対象者をどう数えるか、認証情報の無効化で何が残るか、どの記録で攻撃者の閲覧範囲を確かめるかを、動くコードとコマンドで示します。侵入経路は公表されていないため、本記事でも推測はしません。

まとめ：外務省の不正アクセスで公表された事実と組織側が今やること

確定しているのは、2026年7月27日に外部とやり取りできるネットワークへの不正アクセスを検知し、直ちに遮断と認証情報の無効化を行ったこと、外部専門事業者との調査で個人情報が漏えいした可能性を確認したことです。機密性の高い情報を扱う閉域ネットワークは対象ではなく、旅券やたびレジの領事システムも別に構築されていて対象外でした。侵入の手口と使われていたメール製品は公表されていません。

取引先として外務省とメールをやり取りしていた企業は、外務省を名乗る不審な連絡に備えて従業員へ周知してください。自社のメール基盤については、漏えい時に対象者を数えられるか、認証情報の無効化で攻撃者の居残り経路まで塞げるか、メールの閲覧記録が残っているかの3点を先に確かめておくと、同じ事態での初動が速くなります。

公表内容を時系列で確認する｜7月27日の検知から10月30日の公表まで

7月27日の検知から遮断と認証情報の無効化までに行われた初動の中身

外務省の報道発表（令和8年10月30日）によると、本年7月27日に外部とのやり取りが可能なネットワークへの不正アクセスを検知し、直ちに不正アクセスの遮断や認証情報の無効化等の措置を取って、以降の不正アクセスを防止しました。その後、外部専門事業者の協力を得て調査を進め、個人情報が外部に漏えいした可能性があると確認しています。

発表文が「認証情報の無効化」と書いている点は、侵入に正規の認証情報が使われた可能性を示しますが、どの認証情報か、どう奪われたかは書かれていません。分かるのはここまでです。

約3,600件の内訳と外務省員以外の約900件が取引相手に広げる影響

漏えいした可能性がある個人情報は、メールアドレスや氏名など約3,600件で、このうち約900件は外務省員以外の人のものです。発表文は、ネットワーク上で取り扱っていた個人情報を含むメール等の一部が漏えいした可能性がある、としています。件数がメールに登場する人の数として数えられていることがうかがえます。

約900件の外部の人には、メールの送受信相手になった企業や団体の担当者が含まれると読めます。外務省は対象者を特定したうえで個別に連絡するとしており、二次被害は現時点で確認されていません。一方で、なりすましメールやフィッシングに悪用される可能性があるとして、外務省や外務省員を装った不審なメール、電話、SMSに注意するよう呼びかけています。外務省がパスワードなどの認証情報やクレジットカード情報をメールや電話で尋ねることはありません。手口の見分け方はフィッシング詐欺の仕組みと実装者向けの技術的対策で整理しています。

閉域ネットワークと領事システムを守った2系統分離が効いた範囲

外務省には、機密性の高い情報を外務省員の間だけでやり取りする閉域ネットワークと、外部とのやり取りが可能なネットワークの2系統があり、今回不正アクセスが確認されたのは後者です。念のため内容を確かめた結果、漏えいした可能性のある情報に機密性の高い情報は確認されなかったとしています。旅券やたびレジの情報を扱う領事システムも別に構築されており、対象外でした。

系統を分けていたことで、被害は外部と通信する側に閉じています。裏返せば、外部と通信する側に置いたメールに個人情報が含まれていれば、その分は分離の外にあるということです。閉域で守る情報と外部とやり取りする情報の線引きは、閉域網とVPN・専用線の違いを踏まえて決める必要があります。

検知から公表まで約3か月かかった対象者の調査と関係先への報告の段取り

検知の7月27日から公表の10月30日までは約3か月です。発表文は、外部専門事業者と調査を進めた結果として漏えいの可能性を確認したと書くのみで、公表時期の理由や個人情報保護委員会への報告の時期には触れていません。

民間事業者が同じ立場に立った場合、委員会への速報は発覚から概ね3〜5日以内、確報は30日以内（不正の目的によるものは60日以内）が目安です。対象者の特定が終わっていなくても、速報は分かっている範囲で出します。報告の要否と様式は個人情報保護委員会の漏えい等の対応とお役立ち資料で確認でき、手順の全体は個人情報保護委員会への報告義務でまとめています。

メールが漏えい元のとき対象者の特定が遅れる理由と数え方の実装

ヘッダ・本文・添付ファイルに散らばる個人情報と特定にかかる手間

データベースからの漏えいなら、対象者は行数として数えられます。メールの場合はそうはいきません。From・To・Ccのヘッダに並ぶ送受信相手、本文の署名や転記された連絡先、添付された名簿と、同じ人が何通にもまたがって何度も出てきます。重複を除いて1人として数え、自組織の人と外部の人に分けなければ、「約3,600件のうち外部が約900件」という形の数字は出せません。

特に手間がかかるのは添付ファイルです。Excelの名簿やPDFの申請書は、メールのヘッダを読むだけでは中身が分かりません。対象者の数を確定するまでに時間がかかるのは、この部分を人の目で確かめる工程が残るからです。

書き出したメールから対象者を数える標準ライブラリだけのPythonスクリプト

次のスクリプトは、調査対象のメールボックスから書き出した.emlファイルを読み、ヘッダと本文に出てくるメールアドレスを重複なしで集め、自組織のドメインと外部に分けて数えます。ヘッダの解析にはPython標準のemail.utils.getaddressesを使い、Python 3の標準ライブラリだけで動きます。count_people.pyとして保存してください。

import email, re, sys
from collections import Counter
from email import policy
from email.utils import getaddresses
from pathlib import Path

ADDR = re.compile(r"[\w.+-]+@[\w-]+(?:\.[\w-]+)+")
HEADERS = ("From", "To", "Cc", "Bcc", "Reply-To")

def scan(path):
    msg = email.message_from_bytes(path.read_bytes(), policy=policy.default)
    found, attach = set(), 0
    pairs = getaddresses([v for h in HEADERS for v in msg.get_all(h, [])])
    found |= {a.lower() for _, a in pairs if "@" in a}
    for part in msg.walk():
        if part.is_attachment():
            attach += 1
        elif part.get_content_type() == "text/plain":
            found |= {a.lower() for a in ADDR.findall(part.get_content())}
    return found, attach

root, internal = Path(sys.argv[1]), sys.argv[2].lower()
people, attachments, mails = set(), 0, 0
for p in root.rglob("*.eml"):
    addrs, n = scan(p)
    people |= addrs
    attachments += n
    mails += 1

inside = {a for a in people if a.endswith("@" + internal) or a.endswith("." + internal)}
outside = people - inside
print(f"mails={mails} unique={len(people)} internal={len(inside)} external={len(outside)} attachments={attachments}")
for dom, c in Counter(a.split("@")[1] for a in outside).most_common(5):
    print(f"  {dom}: {c}")

第1引数に.emlを置いたフォルダ、第2引数に自組織のドメインを渡します。example.jpなどの例示用ドメインで作った3通のメールで、2026年11月3日に実行した結果です（Python 3.14系）。

$ python count_people.py export agency.example.jp
mails=3 unique=6 internal=2 external=4 attachments=2
  partner.example.com: 2
  vendor.example.co.jp: 1
  univ.example.ac.jp: 1

実行結果の読み方と添付ファイルとmbox形式を別に扱う際の確認事項

unique が対象者の候補数、internal と external がその内訳です。外部のドメイン別の件数は、どの取引先に個別連絡が必要かの一覧になります。サブドメインも自組織として数えるため、本庁と出先でドメインが分かれている組織でも1回で集計できます。

attachments の数は、人の目で確かめる残りの量です。このスクリプトは添付ファイルの中身までは読みません。名簿や申請書が添付されていれば、そこに載った人は本文に出てこなくても対象者に入ります。氏名だけで書かれた人も数えられないため、件数の確定に必要なのは、「アドレスで機械的に数える」と「添付と本文の氏名を人が確かめる」の2段の確認です。書き出し形式が.emlでなくmboxの場合は、Python標準のmailboxモジュールのmailbox.mboxで1通ずつ取り出せば、同じscan関数に渡せます。

認証情報の無効化で止まるものと残るもの｜パスワード変更の先の点検

リフレッシュトークンとセッションCookieを失効させるGraph APIの呼び方

パスワードを変えても、すでに発行されたトークンで攻撃者がメールを読み続けられる場合があります。Microsoft 365を使っている組織なら、Microsoft Graphのuser: revokeSignInSessionsで、そのユーザーに発行されたすべてのリフレッシュトークンとブラウザーのセッションCookieを無効にできます。最小特権のアクセス許可はUser.RevokeSessions.Allです。

# Microsoft Graph PowerShell SDK の場合
Connect-MgGraph -Scopes "User.RevokeSessions.All"
Revoke-MgUserSignInSession -UserId $upn

# HTTP で呼ぶ場合（要求本文なし・成功時は 2xx）
POST https://graph.microsoft.com/v1.0/users/{id}/revokeSignInSessions

ドキュメントには注意点が2つ書かれています。取り消しが効くまでに数分の遅延があること、そして外部ユーザーはホームテナントでサインインするため、そのサインインセッションは取り消されないことです。取引先のゲストアカウントが関わる場合は、相手の組織にも失効を依頼する必要があります。トークンとセッションの寿命の設計はセッション管理の発行から失効までの実装で解説しています。

転送ルールとアプリ連携の同意に残る攻撃者の居残り経路と設定の点検

トークンを失効させても、攻撃者がメールボックスに仕掛けた受信トレイのルールは残ります。外部アドレスへの自動転送や、特定の差出人のメールを削除するルールがあれば、認証情報を変えた後も情報が流れ続ける状態です。Exchange OnlineではGet-InboxRuleでルールの一覧を取れます。

Get-InboxRule -Mailbox $upn |
  Where-Object { $_.ForwardTo -or $_.ForwardAsAttachmentTo -or $_.RedirectTo -or $_.DeleteMessage } |
  Format-List Name, Enabled, ForwardTo, ForwardAsAttachmentTo, RedirectTo, DeleteMessage

トークンの失効とパスワードの変更は、検知したらすぐに行います。そのうえで、ルールの一覧とアプリ連携の同意を同じ日のうちに確かめ、身に覚えのないものを消してください。失効だけで作業を終えると、攻撃者がアプリに与えた権限や転送ルールが残り、情報が外へ出る経路を見落とします。APIの側でトークンを失効させる設計はAPI不正アクセス対策の実装手順で扱っています。

監視の強化で見るべきメール閲覧の記録｜MailItemsAccessedの読み方

SyncとBindの違いと同期されたフォルダを丸ごと侵害とみなす扱い

漏えいの「可能性」を「確認」に近づけるには、攻撃者がどのメールを開いたかの記録が要ります。Exchange OnlineのMailItemsAccessedメールボックス監査アクションは、POP、IMAP、MAPI、EWS、Exchange ActiveSync、RESTのすべてのプロトコルでのメールへのアクセスを記録します。Office 365 E3/E5またはMicrosoft 365 E3/E5のライセンスを持つユーザーで既定で有効です。

記録には2種類あります。Bindは1通ずつのアクセスで、メッセージのInternetMessageIdが残ります。Syncはデスクトップ版Outlookがフォルダをまとめてダウンロードしたときの記録で、フォルダ単位にしか残りません。ドキュメントは、同期されたフォルダ内のメールはすべて侵害されたとみなす扱いを示しています。攻撃者が同期を使っていれば、対象者の数え方は「開いたメール」ではなく「フォルダ全体」が基準になります。

Search-UnifiedAuditLogで攻撃者のセッションだけを絞り込むコマンド

検索にはExchange Online PowerShellのSearch-UnifiedAuditLogを使います。期間と対象ユーザーを指定し、MailAccessTypeでSyncかBindかを分けて取り出します。

Search-UnifiedAuditLog -StartDate 07/20/2026 -EndDate 07/28/2026 -UserIds $upn `
  -Operations MailItemsAccessed -ResultSize 1000 |
  Where-Object { $_.AuditData -like '*"MailAccessType","Value":"Bind"*' } |
  Format-List CreationDate, UserIds, AuditData

同じアカウントでも、正規の利用者と攻撃者はClientIPAddress、ClientInfoString、SessionIdが違います。この3項目で攻撃者のセッションを特定し、そのセッションのBind記録に並んだInternetMessageIdを取り出せば、先のスクリプトに渡すメールの範囲を絞ることが可能です。記録が残っていない期間があれば、その期間のメールはすべて読まれた前提で数えます。ログの調べ方の基本は不正アクセスの調べ方とログの確認方法を参照してください。

外部と通信するネットワークに個人情報入りメールを残す設計の見直し基準

名簿や申請書をメールの添付で回している組織が保存方法を見直すべき条件

取引先や利用者の名簿、申請書、本人確認書類をメールの添付でやり取りしている組織は、保存の仕方を見直してください。メールボックスは外部と通信する側に置かれることが多く、一つのアカウントが破られるだけで、何年分もの添付が攻撃者の手に渡ります。今回のように閉域側を守れていても、外部とやり取りする側に溜まった個人情報は分離の外です。

見直しの中身は、受け取った名簿をメールから業務システムへ移して添付を消す運用、保存期間を決めて古いメールを自動で削除する設定、そしてMailItemsAccessedのような閲覧記録が残っているかの確認です。破られた後に何が読めるかを第三者の目で確かめたいときは、脆弱性診断・セキュリティ診断で、外部に開いた入口からメール基盤までの経路を含めて点検できます。

メールで個人情報を扱わない小規模組織で過剰になる場面と代わりの対策

社外とのメールが日程調整や見積もりのやり取りにとどまり、名簿や申請書を添付で受け取らない組織では、メールの保存期間を細かく設計したり、監査ログを毎日確かめたりする運用は過剰です。漏えいしても対象者は送受信相手のアドレスに限られ、先のスクリプトで数え切れます。

その場合に足りるのは、多要素認証の有効化と、外部アドレスへの自動転送を管理者設定で禁止しておくことの2点です。個人情報の添付を受け取り始めた時点で、前の項の見直しに切り替えます。

よくある質問

外務省の不正アクセスについて、取引先やメール基盤を運用する担当者から出やすい質問をまとめました。

パスポートやたびレジの情報は漏えいしていますか？

外務省は、漏えいしていないと説明しています。旅券やたびレジ等の情報を扱う領事システムは、不正アクセスを受けたネットワークとは別に構築されており、今回の対象ではありません。機密性の高い情報を扱う閉域ネットワークも対象外で、漏えいした可能性のある情報に機密性の高い情報が含まれていたことは確認されなかったとしています。

外務省とメールをやり取りしていた企業は何をすればよいですか？

外務省は対象者を特定したうえで個別に連絡するとしています。それまでの間は、外務省や外務省員を名乗るメール、電話、SMSのリンクや添付ファイルを開かず、認証情報を入力しないよう従業員に周知してください。外務省が認証情報やクレジットカード情報をメールや電話で尋ねることはありません。過去のやり取りの文面を引用した標的型メールが届く可能性も考えておきます。

侵入経路や使われていたメール製品は公表されていますか？

公表されていません。発表文が示しているのは、外部とのやり取りが可能なネットワークへの不正アクセスを検知し、遮断と認証情報の無効化を行ったことまでです。製品名が分からない以上、特定の製品の利用者だけが警戒すればよいと決めつけず、自社のメール基盤の認証方式、転送ルール、閲覧記録を一通り点検するのが確実です。

パスワードを変更すれば攻撃者は締め出せますか？

パスワード変更だけでは足りない場合があります。発行済みのリフレッシュトークンやセッションCookieが残っていれば、攻撃者はそれでメールを読み続けられます。Microsoft 365ならrevokeSignInSessionsでトークンを失効させ、受信トレイのルールとアプリ連携の同意も確かめてください。外部ユーザーのセッションは自組織から取り消せないため、相手の組織への依頼も必要です。

メールから漏えいした人数はどう数えればよいですか？

まず閲覧記録で攻撃者が触れたメールの範囲を決め、そのメールのヘッダと本文からメールアドレスを重複なしで集めて、自組織と外部に分けます。本記事のスクリプトはこの工程を自動化したものです。次に添付ファイルと、アドレスなしで氏名だけが書かれた箇所を人が確かめ、件数を確定させます。記録が無い期間のメールは、すべて読まれた前提で数えます。

関連記事

• デジタル庁GSSの不正アクセスと約24.6万件｜CVSS中のVPN脆弱性を何で優先するか：同じく省庁の基盤が狙われた事案で、侵入口の優先度判定を扱った記事
• 原子力研究開発機構の不正アクセスと身分証画像の漏えい｜研究支援サイトのファイル保管を点検する手順：公的機関でファイルの保管場所が被害範囲を決めた事例
• ブラストメール不正アクセス：345契約の配信先漏えいと、ピッコマ・エックスサーバーなど利用企業の公表、報告・通知の手順：メールの宛先情報が漏えいしたときの通知の段取り
• 個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務：漏えい時の報告の期限と様式
• 不正アクセスの調べ方｜ログの確認方法と痕跡を見つけるコマンド例：侵入の痕跡をログから探す基本