guide

HTMLメールの開封確認はどういう仕組みか|数えられるものと数えられないもの

2026年9月7日 ・ Halict編集部

html メール 開封 確認 仕組みを調べる人が本当に知りたいのは、たいてい2つです。相手が読んだかどうかを本当に把握できるのか、そしてその数字をどこまで信じてよいのかです。結論から書くと、開封を数える仕組みには性質のまったく違う2種類があり、どちらも「読んだ」を正確には表しません。仕組みを理解しておくと、届いていないのか読まれていないのかを取り違えて、相手に無用な催促を送る事故を避けられます。

開封確認と呼ばれているものは2種類ある

同じ「開封確認」という言葉で、まったく別の2つの仕組みが語られています。ここを分けないまま調べると、ある記事には「相手に気づかれずに測れる」と書いてあり、別の記事には「相手が拒否できる」と書いてあって、話が噛み合いません。両方とも正しく、指しているものが違うだけです。

1つ目は、メールの中に画像を1枚仕込んで、その画像が読み込まれたことをもって開封と数える方法です。メール配信サービスやマーケティングの道具が出す「開封率」は、ほぼすべてこの仕組みです。受信した側には何も表示されず、確認を求められることもありません。HTMLメールでしか使えません。

2つ目は、メールのヘッダに「読んだら知らせてください」という依頼を書いておく方法です。これは電子メールの規格として定められているもので、受け取った人のメールソフトが、送り主に通知を返すかどうかを決めます。ビジネスメールで「開封確認をつける」と言うとき、多くの場合こちらを指します。相手の画面に確認のダイアログが出るため、送ったことが相手に分かります。

この2つは、測れる範囲も、精度も、相手への見え方も違います。片方は数字を集める道具で、もう片方は1通ごとの確認を頼む道具です。以下、それぞれの仕組みを順に見ていきます。応募や問い合わせの受付でこの話が出るのは、たいてい「返信を読んでもらえているか分からない」という場面です。受付のやり取りをどう追うかという観点は、問い合わせの受付にまとまっています。

画像を1枚読み込ませて数える

HTMLメールは、ウェブページと同じように、外部にある画像を参照して表示します。本文に書かれているのは画像そのものではなく、画像の置き場所を指すURLです。受信側のメールソフトがそのURLに取りにいったとき、画像を置いているサーバー側には記録が残ります。いつ、どのアドレス宛のメールに埋め込んだ画像が取りにこられたか、という記録です。

開封の計測は、この性質を使っています。宛先1人ごとに違うURLを割り当てた、目に見えないほど小さい画像を本文の末尾あたりに入れておく。その画像が取りにこられたら、そのメールは表示されたと判断する。仕組みとしてはこれだけです。1ピクセル四方の透明な画像がよく使われるため、トラッキングピクセルと呼ばれます。

ここで押さえておくべきなのは、記録されているのは「画像が取りにこられたこと」であって、「人が本文を読んだこと」ではないという点です。この2つは重なる部分が多いだけで、同じものではありません。プレビュー画面に一瞬映っただけでも画像は読み込まれます。逆に、じっくり読んでいても画像を表示しない設定なら記録は残りません。

同じ理由で、開封の時刻も実際に読んだ時刻とは限りません。受信箱を上から順に流し見しているときにプレビューに入っただけの時刻が記録されることもあれば、あとで検索して見返したときの読み込みが2回目として記録されることもあります。配信直後に開封が集中し、その後にぱたりと止まるという形の記録が出たとき、それは受け取った人の読み方の傾向というより、受信環境の側の挙動を見ていることのほうが多いと考えたほうが実態に近くなります。時刻をもとに「この時間帯に送ると読まれやすい」と結論を出す前に、記録の性質を疑う手順を挟んでください。

さらに、この方法はHTMLメールでしか成立しません。テキストだけのメールには画像を埋め込む場所がないため、開封を数える手段がありません。相手の受信環境によっては、HTMLメールで送っても本文がテキストとして表示されることがあり、その場合も画像は読み込まれません。取引先の環境が古い場合や、セキュリティの方針でHTMLメールをテキストに変換している組織では、開封は永遠に0件のままになります。送っていない、届いていない、読まれていないのどれでもなく、単に測れないという状態です。

画像を止める設定が受信側にある

計測が成り立つ前提は、受信側が画像を自動で読み込むことです。この前提は、いまでは当たり前ではありません。

多くのメールソフトに、外部の画像を自動で表示しない設定があります。Gmailの場合、画像の設定として「外部画像を表示する前に確認する」を選べます。この設定にしていると、画像は自動で読み込まれず、本文の上に確認の表示が出ます。利用者が明示的に表示を選ばない限り、送り主のサーバーには何も届きません。

企業の環境では、管理者側の方針で画像の自動表示を止めている場合もあります。金融機関や自治体のように、外部からの通信を厳しく管理している組織では、この設定が既定になっていることが珍しくありません。つまり、開封が記録されない層が構造的に存在します。開封率が20%という数字を見たとき、残りの80%が読んでいないと考えるのは誤りです。読んでいないのか、画像を止めているのか、テキストで表示しているのかは、この数字からは分かりません。

受付の現場でこれが問題になるのは、催促を出す判断をするときです。開封されていないから届いていないのだろうと考えて再送すると、実際には読んでいた相手に同じ内容が2通届きます。応募者や問い合わせ主から見ると、こちらの管理が雑に映ります。開封の記録は、催促を出すかどうかの根拠には向きません。

受信側が先に全部読み込んでしまう場合

画像を止める方向とは逆に、受信側が先に全部読み込んでしまう仕組みもあります。こちらのほうが、計測にとっては影響が大きいものです。

Appleのメールプライバシー保護は、まさにこの動きをします。公式の説明には次のように書かれています。

Mail Privacy Protection hides your IP address so senders can't link it to your other online activity or determine your exact location. It also prevents senders from seeing if you've opened the email they sent you. 出典: support.apple.com

送り主から見えるのは、実際に本文を開いた瞬間ではなく、受信した時点で行われた読み込みです。IPアドレスも隠されるため、どこで開いたかも分かりません。開いていない人の分まで開封として記録され、開いた時刻も本当の時刻ではない、という状態になります。

この保護は、iPhoneやMacの標準のメールアプリで使われています。日本ではiPhoneの利用者が多いため、影響を受ける割合は小さくありません。開封率が急に跳ね上がった、あるいは開封の時刻が配信直後に集中している、という現象を見たことがあるなら、この仕組みが働いている可能性があります。

ここまでを整理すると、画像による計測は2方向から歪んでいます。画像を止めている層は数えられず、先に読み込む層は実際より多く数えられます。どちらも受信側の設定で決まるため、送り主にはどちらがどれだけ混ざっているか分かりません。この数字を、1人の相手が読んだかどうかの判断に使うのは無理があります。

Gmailが画像を間に入って取りにいく

もう1つ、計測の精度に効いてくる仕組みがあります。Gmailは、メールに含まれる画像をそのまま受信者の端末に取りにいかせるのではなく、いったん自社の側で扱ってから表示します。Googleの日本語ヘルプには、この仕組みの効果として次のように書かれています。

送信者が画像の読み込みを利用して、ユーザーのパソコンや所在地に関する情報を入手することはできません。 出典: support.google.com

送り主のサーバーから見えるのは、受信者本人の環境ではありません。そのため、開封したのがパソコンなのかスマートフォンなのか、どの地域から開いたのか、といった情報の信頼性は下がります。配信の道具が出す「デバイス別の開封率」や「地域別の開封率」を、そのまま実態として読むのは危険だということです。

なお、この仕組みは開封の計測そのものを止めるわけではありません。読み込みは行われるので、開封としての記録は残ります。止まるのは、そこに付随する環境の情報のほうです。仕組みごとに、何が止まって何が残るのかは違います。まとめて「トラッキングは効かない」と考えるのも、「開封率は正確だ」と考えるのも、どちらも実態からずれます。

もう一方の仕組みは相手の許可がいる

ここからは2つ目の仕組み、ヘッダで通知を依頼する方式です。電子メールの規格として文書化されていて、通知そのものはMDNと呼ばれます。規格の本文には、この依頼の性質がはっきり書かれています。

The presence of a Disposition-Notification-To header field in a message is merely a request for an MDN. The recipients' user agents are always free to silently ignore such a request. 出典: rfc-editor.org

依頼にすぎず、受け取った側のソフトはその依頼を黙って無視してよい、と規格そのものが定めています。さらに同じ文書には、この通知が読まれたことの証明にはならないという趣旨の記述もあります。「MDNs cannot be relied upon as a guarantee that a message was or was not seen by the recipient.」という一文です。規格の側が、証拠として使えないと明言しているわけです。

実際の動きとしては、開封確認を求めるメールを受け取ると、多くのメールソフトで確認のダイアログが出ます。相手はここで送るか送らないかを選びます。Outlookのサポート文書には「In Outlook, the message recipient can decline to send read receipts.」と書かれ、続けて「There is no way to force a recipient to send a read receipt.」とあります。強制する手段はない、と明記されています。

この方式のもう1つの特徴は、送ったことが相手に伝わることです。画像による計測は受信者に何も見せませんが、こちらは確認のダイアログという形で相手の作業を止めます。ビジネスの相手に対して使うと、催促されていると受け取られることがあります。使いどころは、期限のある書類の受け渡しなど、確認が取れることに双方の利益がある場面に限られます。

サービスごとに使える条件が違う

開封確認の依頼は、どのメールサービスでも使えるわけではありません。ここは条件がはっきり分かれています。

Gmailの場合、公式ヘルプには「Read receipts are only available to work or school accounts. They don't work with personal Gmail (@gmail.com) accounts.」と書かれています。仕事や学校のアカウント、つまりGoogle Workspaceの契約がある場合にだけ使える機能で、個人の無料のアカウントでは使えません。さらに管理者側の設定で、開封確認の送信そのものを許可しない、あるいは自分のドメイン宛にだけ許可する、といった制限をかけられます。

同じ公式ヘルプには「To receive a read receipt in your inbox, the recipient of your email may need to approve it first.」ともあり、受け取る側の承認が要る場合があることが書かれています。加えて「You won't get a read receipt if: You send a message to a group mailing list or alias.」という制限もあります。問い合わせ窓口のように、共有のアドレスやエイリアスで運用している宛先には、そもそも開封確認が返りません。採用や問い合わせの窓口はまさにこの形で運用されていることが多く、実務では効かない場面が目立ちます。

Appleの標準のメールアプリについては、開封確認を送る、あるいは求める機能が設定として用意されているという記載は、公開資料では確認できませんでした。機能が無いという意味ではなく、公開されている案内の中に見当たらないという意味です。相手のメール環境が分からない状態で開封確認に頼ると、返ってこないことのほうが多くなります。返ってこないことを「無視された」と読み違えると、関係を損ねます。

開封という数字を何に使うか

ここまでの仕組みを踏まえると、開封の数字が向いている用途と、向いていない用途がはっきりします。

向いているのは、同じ条件で送った複数の配信を比べることです。件名を変えた2通を、同じ相手の集団に、同じ時間帯に送る。両方に同じ歪みが乗るので、差だけは意味を持ちます。件名Aの開封が18%、件名Bが24%なら、Bのほうが目を引いたと判断してよい。歪みは絶対値を壊しますが、比較の向きまでは壊しません。

向いていないのは、1人の相手について読んだかどうかを判断することです。開封が付いていないから読んでいない、という推論は成立しません。画像を止めているだけかもしれず、テキストで表示されただけかもしれません。逆に開封が付いていても、受信側が自動で読み込んだだけかもしれません。個人に対する判断材料としては、根拠が弱すぎます。

もう1つ、開封を追いかけること自体が目的化しやすい点にも注意が要ります。受付の実務で本当に知りたいのは「読んだか」ではなく「返事が来たか」「次の手続きに進んだか」です。応募者に書類の案内を送ったなら、知りたいのは提出があったかどうかです。開封の有無を眺めている時間があるなら、期限までに提出のない人へ声をかけるほうが、はるかに結果に近づきます。

道具が違えば開封の定義も違う

もう1つ、数字を比べるときに落とし穴があります。開封という言葉の定義が、道具によって同じではないことです。

同じ人が同じメールを3回開いた場合、開封を3と数えるか1と数えるかは、道具の設計で決まります。前者は延べの回数、後者は開いた人の数です。同じ配信でも、どちらで集計しているかによって数字が変わります。配信の道具を乗り換えた直後に開封率が跳ねた、あるいは落ちたという話の多くは、配信の中身ではなく、この定義の違いが原因です。

分母の取り方も揃っていません。送った総数で割るのか、届いた数、つまりエラーで戻った分を除いた数で割るのかで、同じ配信の開封率が数ポイント変わります。宛先の状態が悪いリストほど、この差は大きくなります。古い名簿に一斉に送ったときの開封率が、他の配信と比べて不自然に低く出るのは、多くの場合ここが原因です。

したがって、別々の道具が出した開封率を横に並べて比べることには意味がありません。世の中で言われている「業種別の開封率の目安」も、集計の定義が揃っていない数字の平均なので、自社の数字が高いか低いかの判断には使いにくいものです。比べてよいのは、同じ道具の中で、同じ定義で集計した自分たちの過去の配信だけです。この前提を置いたうえで、件名や配信時刻を変えた差を見ていくのが、開封という数字の唯一まともな使い道になります。

届いたかどうかは、開封とは別の記録で分かる

開封が付かないときに最初に疑うべきなのは、読まれていないことではなく、そもそも届いていない可能性です。この2つは別の記録で確かめます。

届いたかどうかは、配信側に残るエラーの記録で分かります。宛先が存在しない、受信箱の容量が上限に達している、受信側のサーバーが一時的に受け付けなかった、といった理由で戻ってきた場合、送った側にその情報が返ります。恒久的な失敗と一時的な失敗は扱いが違い、前者は宛先そのものを直さないと何度送っても届きません。後者は時間をおいて再送されます。開封の記録をいくら眺めても、この区別は付きません。

もう1つ、届いてはいるが迷惑メールに入っている状態があります。この場合、配信側にはエラーが残らず、開封だけが付かない形になります。外形上は「読まれていない」と同じに見えるため、いちばん厄介です。フォームの控えメールでも同じことが起きます。Googleの公式ヘルプは、回答のコピーについて「In certain circumstances, responders may not receive the expected response receipts due to spam filters or other counter-abuse measures.」と、迷惑メール対策で届かない場合があることを明記しています。自動で送る控えは、この経路で落ちることを前提に設計するのが安全です。

受付の実務としては、順番を決めておくと迷いません。まず配信のエラー記録を見る。エラーが無ければ、迷惑メールに入っている可能性を疑って、別の連絡手段があるかを確認する。ここまで確かめたうえで、はじめて読まれていない可能性を考える。開封の数字を最初に見にいくと、この順番が崩れて、届いていない相手に「ご確認ください」と催促を重ねることになります。

開封を測ること自体をどう受け止められるか

技術的にできることと、やってよいことは別です。開封の計測は、受け取った側から見れば、自分が読んだ事実が相手に伝わっているということです。この点をどう扱うかは、送る相手との関係で変わります。

一斉配信のメールマガジンや案内であれば、開封の集計を取ること自体はごく一般的に行われています。配信の道具に標準で備わっている機能であり、受け取る側もある程度は想定しています。一方で、1対1のやり取り、たとえば応募者への連絡や取引先への返信に、相手に知らせないまま計測を仕込むのは、関係の性質が変わります。あとから分かったときに、監視されていたと受け取られる可能性があります。

法律面については、扱う情報の種類や利用目的によって考え方が変わるため、ここで断定はできません。個人情報の取り扱いに関わる判断が必要な場合は、所管の窓口や専門家に確かめてください。実務的な線引きとしては、一斉配信の集計として使うのか、個人を特定して行動を追うのかで分けて考えるのが分かりやすい整理です。

受け付けの現場での判断としては、開封を測るかどうかより、測った数字を何に使うかを先に決めるほうが大事です。件名の良し悪しを判断するために集計として使うのなら、個人の記録として保持し続ける必要はありません。逆に、個別の催促の根拠にしようとしているなら、そもそも精度が足りていないので、別の方法を探すべきだという話に戻ります。

1通ごとの確認が本当に要る場面

ここまで開封確認の限界を並べましたが、使うべき場面が無いわけではありません。相手に確認のダイアログが出ることを承知のうえで、それでも使う価値がある場面があります。

典型は、期限のある書類の受け渡しです。契約書の案、見積の有効期限、締切のある提出物。この種の連絡では、確認が取れることが双方の利益になります。相手も、読んだことを伝えておいたほうが後の話が早いと分かっているので、確認を返すことに抵抗がありません。

逆に向かないのは、日常のやり取りに一律で付けることです。毎回ダイアログが出れば、相手の作業を毎回止めることになります。しかも規格の側は、この通知が読まれた証拠にはならないと明言しています。「MDNs do not provide non-repudiation with proof of delivery」という記述がそれです。証拠として使えないものを、相手の手を止めてまで集める意味は薄いということになります。

現実的な代替は、確認が要る連絡には、本文の中で明示的に返事を求めることです。「お手数ですが、確認された旨を一言ご返信ください」と書くほうが、開封確認の依頼より確実に返ってきます。返事が来れば、それは相手が読んだうえで意思を示した記録になります。仕組みで自動的に取ろうとするより、人に頼むほうが精度が高い場面は、実務にはいくつもあります。

開封の代わりに見るべきもの

受付の現場で開封率を気にする理由をたどると、多くは「こちらの連絡が相手に届いて、次に進んでいるかを知りたい」という一点に行き着きます。この目的なら、開封より確実に測れるものがあります。

1つは、送った内容の中に置いた行き先です。案内の中に、日程を選ぶ画面や、書類を出す画面へのリンクを1つ置いておく。そこが押されたかどうかは、画像の読み込みと違って、受信側の設定でほとんど左右されません。押した人は確実に読んでいます。押していない人が読んでいないとは限りませんが、少なくとも「進んでいない人」の一覧としては正確です。

もう1つは、こちら側の対応の記録です。誰がいつ返信したか、その相手からいつ返事が来たか、いま止まっているのは相手の番かこちらの番か。これが1か所に並んでいれば、開封の数字を見なくても、追いかけるべき相手が分かります。受付の道具を選ぶときに効いてくるのは、実は開封の計測ができるかどうかではなく、送信されたあとの道具がそろっているかどうかのほうです。1件ごとに担当と状況が残る形になっていれば、開封に頼る必要がそもそも減ります。

道具を比べるときの見方も変わります。フォームを作る機能だけで比べると差が出にくいので、Googleフォームとの比較のように、送信されたあとの扱いまで含めて並べた表を見るほうが判断が早くなります。同じ観点で軽量な仕組みと比べたい場合は、Contact Form 7との比較に、自前のサイトに埋め込む形との違いがまとまっています。実際にどう見えるかは、できること動くところを見るで確認できます。

採用の受付では、この違いがそのまま応募者の体験に出ます。案内を送ったあと、返事が来ていない人を確実に拾えるかどうかで、辞退の数が変わります。採用の応募受付には、応募から選考までの間に止まりやすい場所と、そこで何を記録しておくかが書かれています。開封率という1つの数字に判断を預けるより、止まっている案件が見える状態を作るほうが、結果として催促の回数は減ります。導入を考えるときのよくある疑問はよくある質問に、費用の考え方は料金にまとまっています。

Q1. テキストメールでも開封確認はできますか?

画像を使う計測はできません。仕組みとして、本文に埋め込んだ画像が読み込まれたことを開封として数えるため、画像を持たないテキストメールでは記録が残りません。ヘッダで通知を依頼する方式であれば、形式にかかわらず使えます。ただしこちらは受け取った側が返すかどうかを選べるため、返ってこないことのほうが多くなります。

Q2. 開封率が低いのは、メールが届いていないからですか?

そうとは限りません。受信側が外部の画像を自動で表示しない設定にしている場合、開いていても記録は残りません。逆に、受信した時点で自動的に読み込む仕組みが働いていると、開いていなくても開封として数えられます。届いているかどうかは、開封ではなく配信側のエラー記録で確認してください。

Q3. 開封確認を送ると相手に気づかれますか?

方式によります。ヘッダで通知を依頼する方式では、多くのメールソフトで確認のダイアログが表示されるため、相手に伝わります。Outlookのサポート文書は、受信者が送信を断れること、強制する手段は無いことを明記しています。画像による計測は相手の画面に何も表示されませんが、開封の有無を個人の判断材料にするには精度が足りません。

Q4. 開封率はどこまで信じてよい数字ですか?

同じ条件で送った配信どうしを比べる用途なら使えます。件名や送信時刻を変えた場合の差は、歪みが両方に乗るため比較として意味を持ちます。一方で、1人の相手が読んだかどうかの判断には向きません。絶対値としての開封率は、受信側の設定によって上下するため、実際に読んだ人の割合とは一致しません。

ガイド一覧へ

HTMLメールの開封確認はどういう仕組みか|数えられるものと数えられないもの|Halict