フィッシングメールの見分け方 ─ 開かずに確認する手順と報告例

「怪しいかどうか」ではなく、確認する順番を決める

フィッシングメールは、請求書や配送通知などを装い、ログイン、支払い、添付の開封、アプリへの権限付与を促す。自然な日本語や見慣れたロゴだけでは正規と判定できない。まず操作を止め、メール内リンクではなく、普段使う公式アプリや登録済みの連絡先で依頼の事実を確認する。

だから、見分け方の中心は「違和感を感じるセンス」ではなく、開く前、押す前、入力する前に確認する順番を固定することにある。焦っているときほど、人は本文の内容に引っ張られる。チェック項目を先に持っておく方が安全だ。

この記事は判断の背景を解説し、フィッシング確認チェックリストでは確認項目を端末内に保存・印刷・コピーできる。チェックを通過しても安全の保証ではない。

---

まず見るのは本文ではなく「送信元」と「要求内容」

本文を読む前に、送信元と要求内容を見る。ここで不自然なら、リンクや添付ファイルを開かずに止まる。

確認する場所	見るポイント	危険な例
表示名	実在企業名だけで安心しない	「Microsoft サポート」だが差出人ドメインが無関係
メールアドレス	既知の公式ドメイン、取引先ドメインと一致するか	公式が example.com なのに差出人が [email protected]（予約ドメインによる説明例）
要求内容	ログイン、支払い、添付開封、MFA再設定を急がせていないか	「本日中に確認しないとアカウント停止」
宛名	自分の氏名や契約情報が自然に入っているか	「お客様各位」だけで高リスク操作を求める
文脈	直近の取引、申請、社内依頼とつながるか	使っていないサービスの請求書や共有通知

特に「急がせる」「秘密にさせる」「普段と違う方法で処理させる」文面は注意したい。攻撃者は、技術よりも人の判断速度を狙う。迷ったら本文を読み込む前に、公式アプリやブックマークから同じ通知が出ているか確認する。

請求書の振込先変更や臨時の送金依頼は、リンクを開かなくても被害につながる。振込先変更メールの確認方法とBECの初動対応では、送金状況別の対応、既知の連絡先への確認、支払い再開条件を整理している。

---

URLは「表示文字」ではなく実際のリンク先を見る

本文には「https://example.com」と表示されていても、実際のリンク先が別ドメインになっている場合がある。表示文字と移動先は別に確認する。

PCではリンクにマウスを乗せたときの移動先表示を参考にできる。スマホでは長押しがページのプレビュー読み込みにつながる場合があるため、確認のために無理に操作しない。移動先を開かずに確認できない場合は、公式アプリなど別経路を使う。以下は予約ドメインを使った説明例であり、実際のサイトへアクセスする必要はない。

URLの形	判断
https://example.com/login	example.com 配下。ただしドメイン一致だけで依頼の正当性は保証されない
https://login.example.com/	example.com のサブドメイン。見慣れた単語だけで判断しない
https://login.example.net/	example.com とは別のドメイン
https://example.com.security-check.example.net/	管理主体を判断する基準は右側の example.net。左側の example.com ではない
短縮URL	遷移先が見えないため、業務メールでは避けたい

FTCの案内も、知っている相手からの連絡に見える場合でも、メール記載の連絡先ではなく既知の電話番号やサイトで確認するよう勧めている。実在アカウントが悪用された場合もあるため、正しい差出人・ドメインは必要な確認材料であって安全証明ではない。

---

添付ファイルとQRコードは「別経路で確認」する

請求書、見積書、配送ラベル、議事録、共有資料を装った添付ファイルは、業務で開きやすい。特に、送信者が取引先名や社内名を名乗っていると、確認せずに開いてしまう。

添付ファイルで確認するのは、拡張子だけではない。送信の文脈、ファイル名、圧縮ファイルの有無、パスワード付きZIPかどうか、普段の取引方法と合っているかを見る。

対象	止まるべきサイン
Officeファイル	マクロ有効化や外部コンテンツ有効化を求める
PDF	ログインや別ファイルのダウンロードへ誘導する
ZIP / 7z	中身が見えにくく、検査や確認を回避しやすい
HTML添付	ブラウザで開かせて偽ログイン画面を表示できる
QRコード	スマホへ誘導し、PC側のメール防御を迂回しやすい

QRコード付きメールは、PCで受け取ったメールをスマホで開かせる点が厄介だ。会社PCのセキュリティ製品やメールゲートウェイを避け、個人端末のブラウザでログインさせようとする。QRコードを読み取る前に、公式アプリや公式サイトに同じ通知があるかを確認した方がよい。

---

ログイン画面に進んでしまったら、入力せず別経路へ戻る

リンクを押してしまっても、入力前ならまだ止まれる。ログイン画面で確認すべきことは、URL、証明書の有無だけでは足りない。最近はHTTPS化された偽サイトも珍しくないため、「鍵マークがあるから安全」とは言えない。

ログインを試して正体を確かめない。メール内リンクから開いた画面では入力・承認を止め、ブックマークや普段使っている公式アプリから入り直す。ファイルを開いた、パスワードを入力した、MFAを承認した場合は、操作内容別の初動対応へ進む。

MFAは方式で性質が異なる。入力するワンタイムコードと、WebAuthnを使うパスキーを同じ扱いにしない。NIST SP 800-63B-4では、WebAuthnの認証先ドメインへの結び付けをフィッシング耐性の仕組みとして説明している。一方、強い認証でも、利用者が不適切なアプリに権限を許可する問題までは解消しない。認証と権限同意は別に確認する。

---

SaaS時代は「許可する」ボタンにも注意する

フィッシングは、IDとパスワードを盗むだけではない。Microsoft 365、Google Workspace、Slack、Notion、GitHubのようなSaaSでは、外部アプリへのアクセス許可を求める画面が出ることがある。

ここで危険なのは、正規のログイン画面を通ったあとに、悪意あるアプリへ権限を渡してしまうパターンだ。OAuth同意フィッシング はその典型で、MFAを破らなくてもメールやファイルへのアクセス権を奪える場合がある。

同意画面では、次を確認する。

確認項目	見るべきこと
アプリ名	業務で使う正規アプリか
発行者	組織が承認した提供者か。確認済み表示だけを安全の保証にしない
要求権限	メール・ファイル読取や継続アクセスが、その業務に本当に必要か
同意範囲	自分だけか、組織全体に影響するか
依頼経路	上司や情シスから事前案内があったか

「ログインしてください」ではなく「このアプリに許可してください」と出たら、通常のメール訓練とは別の判断が必要になる。会社アカウントなら、自己判断で許可せず管理者へ確認する方が安全だ。

---

会社で迷ったときの報告テンプレート

社員教育で大切なのは、「怪しいメールを見抜け」と言うことではなく、迷ったときに報告しやすくすることだ。報告先が分からない、怒られそう、忙しいから後回しにする。こうした心理が、発見を遅らせる。

社内で使うなら、次のテンプレートで十分だ。

件名: フィッシング疑いメールの確認依頼

受信日時:
差出人表示名:
差出人メールアドレス:
件名:
押していないリンク:
開いていない添付ファイル:
自分が行った操作:
気になった点:

重要なのは、「押したかどうか」「入力したかどうか」を正直に書ける空気を作ることだ。押した人を責めると、次から報告が遅れる。組織防御では、早い報告の方が完璧な判断より価値がある。

もし入力・承認してしまった場合は、メールを削除して終わりにしない。操作内容に応じ、管理者がパスワード変更、セッション無効化、認証方法の点検、アプリ同意の撤回などを判断する。MFA再登録や全アカウント停止を一律に行うのではなく、社内手順と影響に合わせる。原本メールの提出方法は社内窓口に確認し、公開の解析サービスへ機密情報を送らない。

---

個人でできる対策は「入口を減らす」こと

個人利用では、すべてのメールを完璧に判定するより、危険な入口を減らす方が現実的だ。

まず、重要サービスはブックマークや公式アプリから開く。メール内リンクからログインしない。次に、パスワードマネージャーでサービスごとに異なるパスワードを使う。最後に、MFAやパスキーを有効にする。

対策	期待できる効果
メールリンクからログインしない	偽サイトへ誘導されても入力を防ぎやすい
パスワードを使い回さない	1つ漏れても連鎖被害を抑えやすい
MFA / パスキーを使う	パスワードだけの不正ログインを防ぎやすい
OSとブラウザを更新する	既知脆弱性を悪用されにくくする
公式アプリから通知を確認する	偽メールと正規通知を切り分けやすい

個人セキュリティ のレッスンでは、パスワード管理、MFA、HTTPS、パスキーを順番に確認できる。フィッシング対策だけを単独で覚えるより、普段のログイン習慣ごと変えた方が長続きする。

---

最終チェックリスト：押す前に30秒だけ止まる

迷ったら、次のチェックを上から順に見る。全部を毎回完璧に見る必要はないが、ログイン、支払い、添付ファイル、SaaS許可が絡むメールでは必ず止まる。

チェック	確認する材料（安全の保証ではない）
送信元ドメイン	公式・取引先・社内の正しいドメインである
要求内容	急な支払い、ログイン、MFA再設定、添付開封ではない
URL	表示文字ではなく実リンク先が公式ドメインである
添付ファイル	事前に予期していたファイルで、形式も自然である
QRコード	公式アプリや公式サイトでも同じ通知を確認できる
ログイン画面	アドレスバー、パスワードマネージャー、画面遷移に違和感がない
SaaS同意画面	アプリ名、発行者、要求権限を説明できる
報告先	迷った場合に確認できる社内窓口や公式問い合わせ先がある

このチェックで1つでも説明できない項目があれば、押さない。自分で判断しきれないことは失敗ではない。確認先へ回すことが、フィッシング対策の一部だ。

---

まとめ：見分ける力より、止まる仕組みを持つ

フィッシングメールの見分け方は、文章の違和感探しだけでは不十分だ。送信元や要求内容を確認しつつ、重要な操作は既知の公式入口へ切り替える。判断できなければ、添付を開いたりログインを試したりせず報告する。

今日から変えるなら、重要サービスはメールリンクから開かず、ブックマークや公式アプリから確認する。会社では、迷ったメールを報告しやすいテンプレートを用意する。学習としては、フィッシングとソーシャルエンジニアリング を読み、用語クイズ で確認し、関連する AIフィッシング や OAuth同意フィッシング へ進むと理解がつながる。心当たりのないリセット通知に特化して確認したい場合は、パスワードリセットメールの確認方法と初動対応 も使える。ヘルプデスク側の本人確認やMFA再登録の受け付け方は、ヘルプデスクを狙うMFAリセット依頼の初動対応 を合わせて確認したい。

実際の受信メールを確認するときは、フィッシング確認チェックリスト で送信元、要求内容、URL、添付、操作履歴を順に確認し、必要に応じて印刷・コピーして報告へつなげられる。

公式情報・参考情報

2026年10月4日に以下の一次情報を確認した。チェックリストと報告例はCyberLens編集部が防御・教育用に整理したもので、被害がないことを証明する診断ではない。

• FTC: How To Recognize and Avoid Phishing Scams — 既知の別経路からの確認、疑わしいメールへの対応。
• NIST SP 800-63B-4: Phishing Resistance — WebAuthnの認証先との結び付け。
• Microsoft: Protect against consent phishing — アプリへの権限同意に対する防御。