公開2026.07.08更新2026.09.05 セキュリティ

フィッシングとは？手口の種類・見分け方と企業が取るべき組織的対策を解説

フィッシングとは、実在する企業や公的機関になりすましたメールやSMSで偽サイトへ誘い込み、IDとパスワードやカード番号を入力させて盗み取る攻撃です。読み方はそのまま「フィッシング」で、fishing（釣り）とsophisticated（洗練された）を掛けた造語とされます。手口はメールだけでなくSMS、電話、QRコードへ広がり、多要素認証をその場で突破する型まで現れました。この記事では、なりすましの仕組みと手口の種類、偽サイトの見分け方と踏んでしまったときの初動、そして企業が投資すべき対策の順序を、2026年時点の公表資料とDNS設定例つきで整理します。

まとめ｜フィッシング対策は個人の注意任せをやめ組織の防御で止める

フィッシングの被害は、利用者が「うっかりクリックした」個人の不注意に見えて、その多くは組織の設計で防げます。攻撃者は正規の差出人表記を偽装し、生成AIで自然な日本語を作り、本物と区別できない偽サイトを短時間で用意します。人の目視だけで見破り続けるのは前提として無理があり、対策の主軸は技術と運用の側に置くべきです。

企業がまず投資すべきは、高価な検知製品ではありません。自社ドメインのなりすましメールを受信側で弾く送信ドメイン認証（SPF・DKIM・DMARC）を正しく運用し、突破されても被害に至らないよう、SMSのワンタイムパスワードではなくパスキーなどフィッシング耐性のある多要素認証へ移すことです。従業員教育は必要ですが、年1回の訓練メールだけで完了とみなすのは失敗します。認証情報を1つ盗まれた瞬間に、ランサムウェア感染や情報漏洩へ連鎖する前提で、多層で受け止める設計に切り替えてください。

2026年時点の規模も押さえておきます。フィッシング対策協議会の2026年7月度フィッシング報告状況は、報告66,119件・フィッシングサイトURL43,267件・悪用ブランド101件でした（月次で増減します）。同協議会のフィッシング対策ガイドライン2026年度版は事業者向け10項目のうち9項目を必須に置いています。DMARCは2026年5月にRFC 9989として提案標準になり、パスキーの基盤仕様WebAuthn Level 3も2026年8月25日にW3C勧告となりました。数年前の手順書のまま運用しているなら見直し時期です。

フィッシングとは何か｜なりすましで認証情報を盗む攻撃の仕組み

言葉の意味と、攻撃者が何を狙っているかをまず押さえます。ここが曖昧だと、対策が「怪しいメールを開かない」という個人の心構えで止まってしまいます。

フィッシングの定義と名称の由来｜情報を釣り上げる攻撃という意味

フィッシング（phishing）は、信頼できる送信元を装って偽のWebサイトやフォームへ誘導し、認証情報や個人情報を入力させて詐取する行為です。銀行、カード会社、宅配業者、ECサイト、そして社内の情報システム部門まで、なりすましの対象は実在の組織全般に及びます。狙いはウイルスでファイルを壊すことではなく、正規の利用者になりすますための「鍵」、つまりIDとパスワードやカード情報そのものです。盗んだ認証情報で正規ルートからログインされるため、システム側からは正しい利用者の操作に見えてしまう点が厄介です。

攻撃者がフィッシングを多用する主な理由と企業の被害へ発展する経路

フィッシングが減らないのは、費用対効果が攻撃者に有利だからです。サーバーの脆弱性を突く攻撃と違い、人の判断の隙を突くため高度な技術がなくても成立します。偽サイトのひな型や送信基盤は闇市場で流通し、数万件のメールを一斉配信する元手も小さい。2026年7月分の月次報告では、報告全体の約68.6%が上位5ブランドに集中していました。金銭被害の側では、令和7年版警察白書が令和6年のインターネットバンキング不正送金を4,369件・約86億8,900万円とし、その多くを金融機関等を装ったフィッシングによるものとみています。個人の金銭被害にとどまらず、盗まれた社員アカウントが社内ネットワークへの侵入口になり、企業全体の被害へ発展する経路が現実の脅威です。

迷惑メール・スパムとの関係とフィッシングが手元に届くまでの経路

フィッシングの入口の多くは、無差別に大量配信される迷惑メールやSMSです。ばらまき型では、実在企業を装った文面に偽サイトのリンクを載せ、受信者の一部が反応することを見込みます。迷惑メール全般の手口と対策はスパムの手口と企業が取るべき対策を解説した記事で扱っていますが、フィッシングはその中でも「情報を盗む」目的に特化した悪質な一類型です。電話番号宛てのSMSや、SNSのダイレクトメッセージを配送経路にする例も増えています。

フィッシングの主な種類｜メール・SMS・音声から中間者型まで

フィッシングは配送経路と標的の絞り込み方で手口が分かれます。守り方も型ごとに変わるため、種類の把握が対策選定の前提です。代表的な型を、被害の起き方とあわせて整理します。

ばらまき型メールとSMSを悪用するスミッシングの主な手口と特徴

最も一般的なのが、メールを大量配信するばらまき型と、SMSを悪用するスミッシング（smishing）です。宅配便の不在通知、カード利用の確認、キャリア料金の未納通知などを装い、短縮URLや正規に似せたドメインへ誘導します。スマートフォンのSMSは表示領域が狭くURL全体を確認しにくいため、パソコンのメールより見破りにくいのが実情です。決済サービスをかたる例も多く、「paypay」など具体的なサービス名を含む偽メッセージが実際に出回っています。

電話をかけさせるビッシングとQRコードを悪用するクイッシング

文字のリンクだけがフィッシングの経路ではありません。ビッシング（vishing）は、メールやSMSで「至急お電話ください」と偽の窓口へ電話をかけさせ、口頭で暗証番号やワンタイムパスワードを聞き出します。クイッシング（quishing）は、メール本文やポスター、封書にQRコードを載せ、読み取らせて偽サイトへ飛ばす手口です。QRコードは人の目でリンク先を判別できず、メール防御製品のリンク検査も画像の中までは追いにくいため、対策の盲点になりやすい経路です。

特定の相手を狙うスピアフィッシングとBEC（ビジネスメール詐欺）

不特定多数ではなく、特定の個人や企業を狙い撃つのがスピアフィッシングです。事前に役職や取引関係を調べ上げ、本人が受け取って不自然でない文面を作り込みます。この標的型を経理・財務に向けて発展させたのがBEC（Business Email Compromise、ビジネスメール詐欺）で、取引先や自社役員になりすまして偽の口座へ送金させます。BECはマルウェアを使わず、正規のやり取りに割り込む形で成立するため、ウイルス対策製品では検知できません。1件あたりの被害額が大きく、企業にとっては金銭損失の直撃点です。音声や映像まで偽装して送金を促す型はディープフェイク詐欺の手口と検知・防御を扱った記事で扱っています。

多要素認証を実時間で突破する中間者型（リアルタイムフィッシング）

対策が進んだ今、攻撃側の主戦力になりつつあるのが中間者型、いわゆるリアルタイムフィッシングです。偽サイトが利用者と本物のサイトの間に立ち、入力されたIDとパスワード、さらにSMSやアプリで届くワンタイムパスワードまで、その場で本物のサイトへ中継します。利用者が正規の手順で認証を通したつもりでも、攻撃者が同時にログインを完了させ、セッションを乗っ取られる仕組みです。「多要素認証を入れたから安全」という思い込みが崩れるのがこの型で、後述するフィッシング耐性のある認証方式が防御の分かれ目になります。

偽サイトの見分け方とフィッシングに引っかかったときの初動対応の手順

技術で防ぎ切れなかったぶんは、人の見極めと事後対応で被害を抑えます。ここでは偽サイトを疑うチェック観点と、入力してしまった後にやるべきことを、順番も含めて示します。

偽サイトを疑う複数のチェック観点と鍵マークだけを過信しない理由

まず、メールやSMSのリンクからではなく、公式アプリやブックマークから正規サイトへアクセスする習慣が最大の防御です。そのうえで疑うべき観点を挙げます。

ドメイン名が正規のものと1文字違い（oを0、lを大文字のIに置換など）でないか
「アカウントを停止しました」「至急確認を」と、時間的な焦りをあおる文面でないか
差出人の表示名は正規でも、メールアドレスのドメインが無関係でないか
日本語が不自然、または逆に不自然さがなくても、送信元が本物と確認できているか

錠前（鍵マーク）が表示されていても安心はできません。無料の証明書で通信の暗号化だけを施した偽サイトが一般化しており、鍵マークは「通信が暗号化されている」ことしか保証しません。運営者が正規かどうかとは別の話です。生成AIで日本語の不自然さも消えつつあるため、文面の巧拙で判断する時代は終わりつつあります。従業員向けの心得は、フィッシング対策協議会の利用者向けフィッシング詐欺対策ガイドライン2026年度版を教材の下敷きに使えます。

フィッシングで情報を入力してしまったとき最初に取るべき初動対応

情報を入力してしまっても、動きが速ければ被害を止められます。慌てて放置するのが最悪手です。

入力したパスワードを、正規サイトへ正しくアクセスし直して即座に変更する
同じパスワードを使い回している他サービスも、すべて変更する
カード情報を入力したなら、カード会社へ連絡して利用停止・再発行を依頼する
不正ログインや身に覚えのない取引の履歴を確認する
企業アカウントなら、情報システム部門へ即報告し、当該アカウントを一時停止する

個人であれば、フィッシング対策協議会や警察の相談窓口へ情報提供する道もあります。社員が業務アカウントで被害に遭った場合は、本人を責めて報告を遅らせるより、早期申告を促す運用のほうが有効です。1つのアカウント侵害が全社的な情報漏洩の起点になり得るため、初動の速さが実害を左右します。

公的ガイドラインとIPAの脅威順位が示す2026年時点の必須要件

対策の優先順位を自社だけで決めきれないときは、公的な要件一覧を出発点にすると社内の議論が早く終わります。2026年6月1日公開のフィッシング対策ガイドライン2026年度版は、攻撃を計画・調達・構築・誘導・詐取・収益化の6行動に分けたうえで、事業者が実施すべき事項を10項目に整理し、うち9項目を必須（◎）に置きました。必須側は送信ドメイン認証への対応、メール送信ガイドラインの策定と遵守、SMSの国内直接接続と共通番号の利用、フィッシング耐性を持つ多要素認証の提供、アクセス履歴の参照機能、ドメイン名の管理継続、対応組織の編制、対応窓口の明記、利用者への啓発の9つです。推奨（〇）は発生監視体制の整備でした。消費者向けサービスを持つなら、この10項目を棚卸し表にして担当部署を割り当てるだけで抜けが見えます。

脅威全体での位置づけも見ておきます。IPAの情報セキュリティ10大脅威 2026は組織向けの1位をランサム攻撃、10位にビジネスメール詐欺とし、フィッシング単体は組織編の順位表に見えません。ただし1位も5位の標的型攻撃も入口は盗まれた認証情報やメールで、実務では地続きです。切り分けは標的型攻撃の手口と多層防御を解説した記事で扱っています。

企業が取るべきフィッシング対策の判断｜教育と技術的防御の優先順位

ここは投資判断が割れる論点ですが、立場を明確にします。結論から言えば、企業が最初に手を付けるべきは高価な検知製品ではなく、送信ドメイン認証の適正運用とフィッシング耐性のある認証への移行です。従業員教育はその土台の上に乗せるもので、順番を逆にすると費用をかけても穴が残ります。

送信ドメイン認証（SPF・DKIM・DMARC）で自社の偽装を弾く

自社をかたるフィッシングを減らす起点は、送信ドメイン認証です。SPFは送信を許可したサーバーを、DKIMは電子署名で改ざんの有無を、DMARCはこの2つの検証結果をもとに「認証に失敗したメールをどう扱うか（隔離・拒否）」を宣言します。監視だけの状態で放置せず、拒否のポリシーまで引き上げて初めて、自社ドメインのなりすましが受信側で弾かれます。Googleのメール送信者のガイドラインは2024年2月から、1日5,000件以上を送る送信者にSPFとDKIMの両方とDMARCを求めており、設定は「やっておくと良い」から前提条件へ変わりました。ポリシー値の意味と移行順序はnone・quarantine・rejectの差を解説した記事、2026年度版での強化点はガイドラインが示すDMARC強化を解説した記事で扱っています。

SMSワンタイムパスワードを見限りフィッシング耐性MFAへ移す判断

多要素認証を入れても、SMSやアプリのワンタイムパスワードは、前述の中間者型フィッシングで実時間で中継され突破されます。ここでの判断は明確です。金銭や個人情報を扱う認証は、SMS OTPを最終防衛線と見なさず、パスキー（FIDO2/WebAuthn）などフィッシング耐性のある方式へ移行してください。パスキーはアクセス先のドメインに認証情報が紐づくため、偽サイトでは原理的に成立せず、中間者型を無効化します。基盤仕様のWeb Authentication Level 3は2026年8月25日にW3C勧告となり、実装の土台としての不確かさは減りました。一度に置き換えるのが難しくても、被害の直撃点となる管理者権限や決済に関わる認証から切り替える順序が現実的です。認証方式の全体像は多要素認証（MFA）の実装方式と耐フィッシングMFAを解説した記事、二要素との用語整理は二段階認証との違いを解説した記事、実際の事案での検証例は講談社の個人情報流出における認証と検知の解説にあります。

従業員教育を年1回の訓練メール実施だけで終わらせない設計の要点

教育は要りますが、失敗パターンをはっきりさせておきます。年1回の標的型メール訓練を実施し、開封率を測って報告書にまとめた時点で「対策済み」とみなすのが、最も陥りやすい失敗です。訓練は開封してしまった人を罰する場ではなく、報告のしやすさと初動の速さを鍛える場に設計し直すべきです。「怪しいと思ったら即報告してよい」「報告したことは評価する」という文化と、報告窓口の即応体制がないと、中間者型のように巧妙な攻撃の前では訓練の効果が続きません。人の判断はいずれ突破される前提で、教育は「気づいて報告する速度」に目標を置くのが妥当です。

盗まれた認証情報をランサムウェア被害にまで連鎖させない多層防御

フィッシングを組織の脅威として見るなら、盗まれた1つのアカウントがどこまで被害を広げるかで設計します。攻撃者は盗んだ認証情報で社内へ侵入し、権限を広げてデータを持ち出し、最終段階でランサムウェアの仕組みと目的を解説した記事で扱うような暗号化・脅迫にまで至るのが典型的な流れです。この連鎖を断つには、認証を1点突破されても被害が横に広がらない多層の設計が要ります。境界防御を担うVPNの仕組みと企業導入の判断基準を解説した記事や、社内も無条件に信頼しないゼロトラストの考え方とNISTの7原則を解説した記事を組み合わせ、権限の最小化と通信の監視で被害範囲を封じ込めてください。自社のログイン画面や公開サーバーに突破口が残っていないかを実測するなら、脆弱性診断・セキュリティ診断で外形からの検査を挟み、出た指摘を認証基盤とネットワーク設計の改修計画へ落とす進め方が使えます。

送信ドメイン認証とパスキー移行の設定例｜DNSレコードと確認コマンド

ここからは実際に触る部分です。DNSに置くレコードと、設定できているかを自分で確かめるコマンドを、コピーして使える形で示します。

SPF・DKIM・DMARCのDNSレコードの書き方とRFC 9989での変更点

3種類のレコードは、いずれもDNSのTXTレコードとして公開します。監視から始める最小の形は次のとおりです。

example.com.                       IN TXT "v=spf1 include:_spf.example.com -all"
selector1._domainkey.example.com.  IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
_dmarc.example.com.                IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]; t=y"

DMARCは2026年5月にRFC 9989として提案標準になり、RFC 7489とRFC 9091を廃止しました。段階適用に使っていたpctタグは削除され、テスト運用の意思表示はtタグ（t=y）で行います。組織ドメインの判定もPublic Suffix List依存からDNSツリーウォークに変わり、サブドメインはspタグ、存在しないサブドメインはnpタグで個別に宣言できます。ruaは必須ではなくなりましたが、宛先を置けばp=noneのままでもレポートが届くため、移行期は残してください。

DMARCレポートで自社ドメインのなりすましを観測する運用の手順

レコードを置いたら、外部から引けているかをその場で確認します。

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT selector1._domainkey.example.com

返ってきた文字列が意図した内容と一致していれば、外から見えている宣言はそれです。次にruaへ届く集計レポートを読み、自社ドメインを名乗る送信元のうち認証を通っていないものを洗い出します。ここで見つかるのは攻撃者だけではありません。別部署が契約している配信サービスやSaaSの設定漏れが多く、拒否へ上げる前にこれを潰すのが本番です。1か月ほど実態を掴んでから、隔離、拒否へと引き上げ、最終形は次のようになります。

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1"

spとnpまで拒否にしておくと、使っていないサブドメインを名乗る偽装も受信側で落ちます。

パスキー導入でRP側が決める設定値と段階移行を進めるときの順序

パスキーはRP（利用側のサービス）が登録時のオプションで挙動を決めます。管理者向けや決済に使うなら、次の3つを固めてから実装に入ってください。

{
  "rp": { "id": "example.com", "name": "Example Corp" },
  "authenticatorSelection": {
    "residentKey": "required",
    "userVerification": "required"
  },
  "attestation": "none"
}

residentKeyをrequiredにするとクレデンシャルが認証器側に保存され、ユーザー名の入力なしで認証を始められます。userVerificationをrequiredにすれば生体か端末PINの確認が毎回入り、端末を盗まれた場合の悪用を抑えられます。rp.idは登録時のドメインに固定されるため、偽サイトは同じ値を提示できず、中間者型が原理的に成立しません。移行は全社一斉ではなく、管理者アカウント、決済権限、一般利用者の順に段階を切ってください。実装手順はWebAuthnでパスキー認証を実装する仕組みとRP実装の要点を扱った記事、パスワード廃止時の方式比較はパスワードレス認証の方式4分類と移行判断を扱った記事にまとめています。

よくある質問

フィッシングについて、検索で多く寄せられる疑問に簡潔に答えます。

フィッシング詐欺とフィッシングは同じ意味ですか？

ほぼ同じ意味で使われます。フィッシングは、なりすましで情報を盗む手口そのものを指す技術用語で、フィッシング詐欺はその手口による金銭・情報の被害を強調した言い方です。実務上はどちらも、偽メールや偽サイトで認証情報やカード情報を詐取する攻撃を指します。攻撃の仕組みを理解する目的なら「フィッシング」、被害の相談や対処を調べる目的なら「フィッシング詐欺」で検索されることが多い違いにとどまります。

フィッシングに引っかかったらどうすればいいですか？

まず入力したパスワードを正規サイトで即変更し、同じパスワードを使い回している他サービスも変更します。カード情報を入力した場合はカード会社へ連絡し、利用停止と再発行を依頼してください。不正利用の履歴を確認し、業務アカウントなら情報システム部門へ即報告してアカウントを一時停止します。放置せず、初動を速くすることが被害を最小限に抑える条件です。

フィッシングメールはどうやって見分ければよいですか？

メールやSMSのリンクからではなく、公式アプリやブックマークから正規サイトへアクセスするのが最も確実です。ドメインが1文字違いでないか、焦りをあおる文面でないか、差出人アドレスのドメインが正規かを確認します。鍵マーク（暗号化）は運営者が正規である保証にはなりません。生成AIで日本語の不自然さも消えつつあるため、文面の巧拙だけで判断しない前提が要ります。

多要素認証を設定していればフィッシングは防げますか？

完全には防げません。SMSやアプリのワンタイムパスワードは、中間者型（リアルタイムフィッシング）の偽サイトが実時間で本物へ中継し、突破される場合があります。より確実なのは、アクセス先のドメインに認証情報が紐づくパスキー（FIDO2/WebAuthn）などフィッシング耐性のある方式です。基盤仕様のWeb Authentication Level 3は2026年8月にW3C勧告となり、偽サイトでは原理的に認証が成立しません。

企業がまず取り組むべきフィッシング対策は何ですか？

送信ドメイン認証（SPF・DKIM・DMARC）を適正に運用し、自社をかたるなりすましメールを受信側で弾くことが起点です。フィッシング対策ガイドライン2026年度版も、送信ドメイン認証への対応とフィッシング耐性のある多要素認証の提供を必須9項目に含めています。あわせて、決済や管理者権限に関わる認証を耐フィッシング方式へ移してください。従業員教育はその土台の上に乗せるもので、気づいて即報告する速度を鍛える設計が要点になります。