guide

メールの開封確認とセキュリティ|何が渡り、何が残るのか

2026年9月9日 ・ Halict編集部

送った申し込みへの返信が読まれたのか分からないまま、次の連絡を出すかどうかで迷う。その場面で「メールの開封確認を付ければいい」と考える人は多いのですが、開封確認はセキュリティの観点で見ると、性質のまったく違う2つの仕組みが同じ言葉で呼ばれています。片方は相手の承認を取って動き、もう片方は相手に断らずに記録が残ります。この記事では、それぞれで何が相手に渡り、何が自分の手元に残るのかを分けて整理し、受付を回す立場としてどこまでやってよいのかを決められるところまで持っていきます。

開封確認と呼ばれているものは、性質の違う2つの仕組み

同じ「開封確認」でも、実際に動いている仕組みは2種類あります。ここを分けずに議論すると、社内の情報システム担当と話がまったくかみ合いません。

1つ目は、メールソフトに昔からある開封確認の機能です。送信するときに「開封確認を要求する」という指定を付けると、受け取った側のメールソフトが「送信者が開封確認を求めています。送信しますか」と尋ね、相手が承認したときだけ、開封した日時を書いた確認メールが返ってきます。相手が断れば何も返りません。仕組みとしては、相手の同意の上で成り立っています。

2つ目は、メール配信ツールで使われる開封のトラッキングです。本文のHTMLの中に、目に見えないほど小さい画像を1つ埋め込んでおき、その画像が受信側の画面で読み込まれたときに、配信側のサーバーへ読み込みの記録が残ります。この記録の有無を「開封」として数えます。受け取った側の画面には何も表示されず、承認を求める確認も出ません。相手は数えられていることに気づかないまま開封として計上されます。

セキュリティで問題になりやすいのは、圧倒的に2つ目です。1つ目は相手が拒否できるぶん、届いた側から見ても「そういう要求が来た」と分かります。2つ目は相手の操作を必要とせず、しかも読み込みの際に相手側の通信の情報がこちらのサーバーに渡ります。この違いを押さえないまま「開封率を見たい」と言うと、受付の窓口が知らないうちに、社外の人の行動記録を集める側に回ってしまいます。

この2つは、記録の残り方も違います。承認を求める方式で残るのは、相手から返ってきた1通のメールです。受信箱の中にあるので、探せば見つかりますし、消せば消えます。画像で数える方式で残るのは、配信を請け負っているサービスの側にある管理画面の記録です。こちらの受信箱には何も届かず、契約している間はサービス側に積み上がり続けます。どこに何が残っているのかを把握しにくいのは、後者のほうです。

用途もまるで違います。1つ目は、1通ごとに「この人に確かに届いたか」を確かめたい場面で使われます。2つ目は、何百通、何千通と送ったうちの何割が開かれたかという、全体の傾向を見る場面で使われます。1通ごとの確認に配信ツールを使うのも、大量配信に開封確認の要求を付けるのも、どちらも合っていません。

承認を求める方式で、相手に渡るもの、こちらに戻るもの

メールソフトの開封確認は、送るメールのヘッダに「開封したら、このアドレスに知らせてほしい」という指定を入れることで動きます。受け取った側のメールソフトがその指定を読み、相手に承認を尋ねます。

このとき相手に渡るのは、こちらのメールアドレスと、開封確認を求めているという事実です。相手のメールソフトの画面には「送信者が開封確認を求めています」という趣旨の表示が出ますから、こちらが確認を取ろうとしていることは相手に知られます。ここは隠せません。逆に言えば、隠す必要のない、正直な確認方法だとも言えます。

戻ってくるのは、開封した日時を書いた確認メールです。差出人は相手のアドレスで、本文には元のメールの件名や識別子が入ります。相手のメールソフトによっては、そのソフトの名前や版が確認メールのヘッダに入ることがあります。ただ、返ってくるのはあくまで相手が承認したときだけです。

そして、この方式には運用上の弱点がはっきりあります。返らないケースが多く、返っても意味が薄い場合があるという点です。Gmailのヘルプでは、開封確認が返らない条件と、返っても読まれたとは限らないことの両方が明記されています。

開封確認が届いても、必ずしも受信者がメールを読んだとは限りません。開封確認の動作は、受信者が使用しているメールシステムによって異なります。 出典: support.google.com

同じページには、Gmailの開封確認が仕事用または学校用のアカウントでのみ使えて、個人用のgmail.comのアカウントでは機能しないことも書かれています。応募者や問い合わせをしてくる人の多くは個人のアドレスを使いますから、受付の窓口で開封確認を付けても、そもそも返ってこない相手が相当な割合を占めることになります。この時点で、開封確認を返信管理の土台にするのは無理があります。

同じページには、開封確認が届かない条件として、次のような場面が挙げられています。グループのメーリングリストやエイリアス宛に送った場合、組織の管理者が開封確認の送信を制限している場合、受信者がリアルタイムで同期しないメールソフトを使っている場合、受信者がIMAPを使うメールソフトで返信して自動送信にならない場合です。ここに挙がっている条件は、どれも送る側では事前に判別できません。相手がどのアカウントの種類を使い、どの方式でメールを取っているかは、こちらからは見えないためです。

この点を運用に置き換えると、こうなります。開封確認が返ってきた件は「確かに承認された」と言えますが、返ってこない件については何も言えません。読んでいないのか、読んだが承認しなかったのか、そもそも仕組みが働かない環境なのか、区別が付かないからです。判断できるのは全体の一部だけで、残りは判断保留のまま残ります。受付の一覧の中に判断保留の列が増えていくだけなら、手間が増えて情報は増えていないことになります。

なお、承認を求める方式は「隠していない」という点で、相手との関係を壊しにくい方法ではあります。重要な通知を1通だけ送り、確かに受け取ってもらえたかを確かめたい場面では、選択肢として残ります。ただしその場合も、返ってこなかったときの手当てを先に決めておくことが前提になります。電話で確かめる、期限を切って再送する、別の連絡先に送る。この段取りが無いまま開封確認だけ付けても、返ってこない件の前で立ち止まるだけです。

画像で数える方式は、相手に断らずに記録が残る

トラッキング用の画像を使う方式では、受け取った人の画面がその画像を取りに来た瞬間に、配信側のサーバーへ通信が届きます。そのとき配信側に残るのは、おおよそ次のような情報です。

・その通信の接続元のIPアドレス ・使われたメールソフトやブラウザの種類を示す文字列 ・画像を読み込んだ時刻 ・どのメールのどの宛先に対する読み込みだったか

接続元のIPアドレスからは、大まかな地域や、法人の回線であれば組織の見当が付くことがあります。読み込みの時刻が並べば、その人が何時ごろにメールを見ているかという生活の型まで見えてきます。相手はこの記録に同意していませんし、記録が取られていること自体を知りません。

さらに、この方式は精度の面でも当てになりません。多くのメールソフトやサービスは、はじめから画像を自動では読み込まない設定になっています。読み込まなければ、開いていても開封として数えられません。逆に、迷惑メールの検査や画像を先に取得しておく仕組みが働く環境では、人が読んでいなくても読み込みが発生して、開封として数えられてしまいます。画像を代理のサーバー経由で取りに行く仕組みを持つサービスもあり、その場合に記録されるのは代理サーバー側の情報です。

読み込みの記録には、もう1つ厄介な性質があります。同じ人が同じメールを何度も開けば、そのたびに記録が増えます。転送されて別の人の画面で開かれても、記録は増えます。転送先が誰なのかは分かりませんから、記録の件数だけを見て「何人が読んだ」と数えることはできません。1件の送信に対して記録が3件付いていても、3人が読んだのか、1人が3回開いたのか、区別が付かないためです。

つまり、この方式で得られる数字は、母集団の大きな配信で傾向をつかむには使えても、特定の1人が読んだかどうかの判定には使えません。「あの人は読んだのに返事をくれない」という判断をこの記録に基づいて下すと、事実と違う前提で人を責めることになります。受付の窓口でこの誤解が起きると、催促の文面がきつくなり、相手との関係を無用に悪くします。

一斉配信と1通ずつの返信では、測る意味がまるで違う

開封の記録をめぐる議論が混乱するのは、目的の違う2つの使い方が同じ言葉で語られるためです。ここを分けると、どちらの方式が要るのか、あるいはどちらも要らないのかがはっきりします。

一斉配信での開封率は、母集団の傾向をつかむための数字です。件名を変えたら開かれ方がどう変わったか、送る時間帯で差が出るか、といった比較に使います。1件ごとの精度は低くてよく、同じ条件でそろえて比べることに意味があります。この用途であれば、画像を読み込まない人が一定の割合いても、比較の条件がそろっていれば傾向は読めます。

一方、受付の窓口が知りたいのは、傾向ではありません。「この応募者に返した書類の案内は届いたのか」「この問い合わせの回答は相手に見てもらえたのか」という、1件ごとの事実です。ここで必要なのは精度であって、傾向ではありません。そして先に見たとおり、どちらの方式も1件ごとの精度は保証できません。目的に対して、道具が合っていないのです。

この整理をしておくと、社内での話も進めやすくなります。広報や販売の部署が配信ツールで開封率を見ているからといって、受付の窓口が同じ数字を追う理由にはなりません。逆に、受付の窓口が開封確認を使わないと決めても、配信の効果測定が止まるわけではありません。用途が違うので、判断も別々にできます。

現場で起きがちなのが、配信ツールの契約が全社にあるからという理由で、受付の返信までそのツールから送ってしまう例です。そうすると、個別の返信にまでトラッキングの画像が入り、相手に断りなく記録を集めることになります。しかも1件ごとの精度は無いままです。得るものが少なく、説明の要る記録だけが増えます。受付の返信は、記録を取らない普通のメールとして送り、返したかどうかは受付側の台帳で管理するほうが、はるかにすっきりします。

受け取る側が開封確認を警戒する理由

受け取る側から見ると、開封確認は「こちらの動きを見られている」という感覚を伴います。承認を求める方式であれば断ればよいのですが、断ること自体が気まずいと感じる人もいます。だからこそ、組織として最初から返さない設定にしているところがあります。

企業や自治体では、外部から来た開封確認の要求に一律で応じない運用を取っていることがあります。理由はいくつかあります。開封確認を返すことは、そのアドレスが生きていて、実際に人が読んでいるという事実を外部に知らせる行為でもあるためです。迷惑メールの送信側は、生きているアドレスの一覧を欲しがります。開封確認や画像の読み込みは、それを渡す経路になり得ます。

同じ理由で、画像を自動で読み込まない設定は、いまではむしろ標準に近い扱いです。読み込まないことで、送信側に接続元の情報を渡さずに済みます。受け取る側にとっては、これは自衛です。送る側が「読み込んでもらえないと開封率が測れない」と困るのは、送る側の都合でしかありません。

受付の窓口として押さえておきたいのは、相手が警戒するのは仕組みそのものではなく、断りなく行われることだという点です。応募や問い合わせで個人情報を預けた相手から、知らないうちに行動を記録されていたと分かれば、その組織への信頼はまとめて崩れます。開封を測りたいなら、測っていることを隠さない形にするか、測るのをやめて別のやり方で返信の抜けを防ぐか、どちらかを選ぶことになります。

集めた開封の記録を、社内でどう扱うか

開封の記録を残すと決めたなら、その記録の置き場と、見られる人の範囲と、消す時期を先に決めておく必要があります。決めずに始めると、配信ツールの管理画面の中に何年分もの記録が積み上がり、退職した担当者のアカウントからも見える状態が残ります。

総務省の国民のためのサイバーセキュリティサイトは、フォームなどで情報を集める側の責任について、次のように書いています。

また、ホームページ開設者や企業において、アンケートサイトなどを用意している場合には、収集した情報の管理について責任があることを認識しなければなりません。特に、プライバシーに関する情報を収集する場合には、万全なサイバーセキュリティ体制のもとで管理する義務があるといえます。 出典: www.soumu.go.jp

集めると決めた以上は管理の責任が付いてくる、というのがここでの要点です。開封の記録は、メールアドレスと結び付いた形で残ります。氏名や応募内容と同じ場所に置かれるなら、他の応募情報と同じ厳しさで扱うことになります。

実務として決めておくべきことは、次の4点に絞れます。

・何を残すのか。開封の有無だけでよいのか、時刻や接続元まで残すのか ・誰が見られるのか。窓口の担当だけか、全社員が見られる場所に置いていないか ・いつ消すのか。募集の終了から何か月で削除するのか ・何のために使うのか。使い道を説明できない項目は、そもそも集めない

この4点は、紙1枚に書けます。書いて、窓口の担当が見える場所に貼っておくだけで、判断のばらつきがかなり減ります。逆に、書いていないものは守られません。担当が交代したときに引き継がれるのは、口頭の申し送りではなく、書いてあるものだけです。

置き場についても、決めておくと後が楽になります。配信ツールの管理画面の中だけに記録が残っている状態は、退職や異動のたびに見直しが要ります。契約を止めた瞬間に記録ごと消える、あるいは逆に消えずに残り続ける、というどちらも起こり得ます。受付の記録は受付の道具の中に置き、配信の記録は配信の道具の中に置くという分け方にしておくと、どちらを止めるときにも判断が単純になります。

権限の設計も、後回しにしないほうがよい部分です。応募や問い合わせの中身は、窓口の担当と、その件を実際に処理する人だけが見られれば足ります。全社員が見られる共有フォルダに書き出したファイルを置く運用は、便利さと引き換えに、範囲を説明できない状態を作ります。誰が見られるかを画面上で確かめられること自体が、道具に求める条件の1つになります。

なお、集めた記録が法律上どの区分に当たるのか、告知や同意がどこまで必要になるのかは、集める項目と使い方によって変わります。ここは記事の一般論で断定できる範囲を超えますので、所管の窓口や専門家に確かめてください。判断を保留したまま集め続けるのが、いちばん危ない状態です。

受け取る側として、開封確認の要求にどう向き合うか

ここまでは送る側の話でしたが、受付の窓口は同時に、外から開封確認を求められる側でもあります。取引先や応募者から開封確認の付いたメールが届いたとき、返すのか返さないのかを、その場の判断に任せていると、担当者ごとにばらつきます。

方針は3つに分かれます。一律で返さない、一律で返す、送信元によって判断する、の3つです。一律で返さないのが最も手堅く、担当者に判断を求めずに済みます。一律で返すのは相手に親切ですが、生きているアドレスであることを外部に知らせる面があります。送信元によって判断する形は理屈としては正しいものの、忙しい窓口で毎回判断させると必ず事故が起きます。実務では、一律で返さないと決めたうえで、必要な相手には本文で「拝受しました」と返す運用に落ち着くことが多いようです。

画像の自動読み込みについても、同じように方針を決めておきます。自動で読み込まない設定にしておけば、外部の送信者に接続元の情報を渡さずに済みます。読み込みたいときは、その1通だけ手動で表示すればよいだけです。表示が崩れて読みにくいという声が出ますが、受付の窓口に届くメールは文字が読めれば足りることがほとんどです。

もう1つ、担当者に伝えておきたいのは、開封確認の要求そのものが相手を装った手口で使われる場合があるという点です。開封確認を返すという操作を通じて、こちらのアドレスが生きていることと、返信の癖が相手に伝わります。心当たりのない送信元からの要求には応じない、という一線は、方針として明文化しておく価値があります。

開封の記録は、届いた証拠にはならない

セキュリティの話と並んで押さえておきたいのが、開封の記録は届いたことの証明にならないという点です。ここを取り違えると、記録があるのに事故が起きます。

メールは、送信側のサーバーから受信側のサーバーへ渡り、受け取った人がそこから取りに行くという形で届きます。総務省の解説でも、この経路が説明されています。

電子メールの送受信は、インターネット上の多くのメールサーバが連携することによって実現しています。 出典: www.soumu.go.jp

途中に複数の仕組みが挟まるということは、迷惑メールの判定で振り分けられる余地も、社内の規則で外部の画像が止められる余地もあるということです。開封の記録が付かないことは、届いていない証拠にも、読まれていない証拠にもなりません。

受付の現場で本当に困るのは、「読まれたかどうか」ではなく、「こちらが返したかどうか」が分からなくなることです。返したはずのものをもう一度返してしまう二重返信と、返したつもりで返していない返し忘れは、どちらも受信箱を目で追う運用から生まれます。開封の記録をいくら集めても、この2つは減りません。減らせるのは、1件ごとに担当と状態が付いていて、返していないものだけが残る形にしたときです。

開封を追わずに、返す責任を見える形にする

開封確認をやめると決めたとき、代わりに何を置けばよいのか。答えは、送った側の記録ではなく、受けた側の状態を持つことです。

受付の1件ごとに、次の3つが分かれば、開封の記録は要らなくなります。

・いまこの件を持っているのは誰か ・いまの状態はどこか。未対応か、確認中か、返信済みか ・最後に動いたのはいつか

この3つがあれば、返していないものだけを画面に残せます。誰も持っていない件が浮き上がり、何日も止まっている件が目に付きます。相手が読んだかどうかを推し量る必要がなくなり、こちらが返したかどうかという、確かめられる事実だけで運用が回ります。送信されたあとの道具がそろっているかどうかは、受付の窓口を選ぶときにいちばん効いてくる違いです。

この3つを持つのに、特別な道具が要るとは限りません。件数が少ないうちは、表計算ソフトに3列足すだけでも機能します。問題は件数が増えたときで、同じ表を2人が同時に開けない、行が増えて見落とす、誰が最後に触ったのか分からない、といった詰まり方をします。詰まりが出てから道具を探すより、詰まる前に何を持たせたいのかを言葉にしておくほうが、選ぶときに迷いません。

返事が来ないときの追いかけ方も変わります。開封の記録を見て「読んでいるのに返さない」と決めつけるのではなく、期限を決めて再送するという単純な運用にできます。応募の受付なら、書類の不足を知らせてから3営業日で返事が無ければもう一度送る、といった具合です。この形なら、相手を監視せずに済み、こちらの手続きとしても説明が付きます。

受付の道具を選ぶときに、セキュリティで見るところ

道具を入れ替える段になったとき、開封確認が付いているかどうかは判断の軸になりません。見るべきなのは、集めた情報がどこに置かれ、誰が見られ、いつ消えるのかという点です。

いま無料で使える道具で足りている場合は、無理に替える必要はありません。応募や問い合わせが月に数件で、担当も1人なら、受信箱と表計算ソフトで十分回ります。替える理由が出てくるのは、担当が2人以上になったときと、外部に見せられない情報が混ざり始めたときです。

比較の材料としては、いま使っている道具の公開されている仕様を先に確かめるのが早道です。回答をどこに保存するのか、ファイルの添付を受け取れるのか、誰にどこまで見せられるのかは、道具ごとに考え方が違います。Googleフォームとの比較では、回答を表計算ソフトで追うやり方が、どこまでなら無理なく続けられるのかを整理しています。ワードプレスにフォームを置いている場合は、送信された内容がサーバー側に残るのかどうかが分かれ目になりますので、Contact Form 7との比較が判断の材料になります。社内でマイクロソフトの環境を使っているなら、外部の人に登録を求めずに受け取れるかどうかをMicrosoft Formsとの比較で確かめておくとよいでしょう。

受け付ける中身によって、気を付ける場所も変わります。履歴書や職務経歴書が届く採用の応募受付では、見られる人を人事の担当だけに絞れるかどうかが最初の関門です。書類の点数が多くなる助成金・公募の受付では、提出物の欠けを申請者ごとに追えるかどうかが効きます。日々の問い合わせの受付なら、担当の割り当てと返信済みの印が同じ画面にあるかどうかで、返し忘れの起き方が変わります。

申し込みを受ける場面でも、確かめる点は変わります。定員や締切のあるイベントの申し込みでは、締め切ったあとに届いた分をどう扱うかを先に決めておかないと、当日になって食い違いが出ます。回を重ねる講座の受講申し込みでは、同じ人が複数回申し込むことがあるため、名寄せをどこでやるかが問題になります。予約の重なりが出やすい施設利用の申請や、継続の管理が要る会員の入会申し込み、機器の情報を受け取る修理・サポートの受付も、それぞれ残す情報の重みが違います。開封の記録より先に、これらの中身をどこに置くかを決めるほうが、事故の芽をつぶせます。

機能の並びだけでは決めきれないときは、できることで扱える範囲を確かめたうえで、動くところを見るで実際の画面を触ってみるのが確実です。費用の見当を付けるなら料金、運用の細かい疑問はよくある質問にまとまっています。開封を測るかどうかで悩む時間を、返す仕組みを整える時間に回したほうが、受付は確実に軽くなります。相手が読んだかどうかは最後まで確かめられませんが、こちらが返したかどうかは、決めさえすれば必ず確かめられるからです。

Q1. 開封確認を付ければ、相手が読んだかどうか確実に分かりますか?

分かりません。メールソフトの開封確認は相手が承認したときだけ返り、断られれば何も返りません。Gmailのヘルプでも、開封確認が届いても読まれたとは限らないと明記されています。画像で数える方式も、画像を読み込まない設定なら開封として数えられません。判定の根拠には使えないと考えてください。

Q2. 開封を測るために画像を埋め込むのは、法律上まずいのでしょうか?

集める項目と使い方によって扱いが変わるため、この記事で断定はできません。所管の窓口や専門家に確かめてください。実務として先に決めておくべきなのは、何を残し、誰が見られ、いつ消すかの3点です。使い道を説明できない項目は、そもそも集めないほうが安全です。

Q3. 個人のGmail宛に開封確認を送っても返ってこないのはなぜですか?

Gmailの開封確認は仕事用または学校用のアカウントでのみ利用でき、個人用のgmail.comのアカウントでは機能しないと公式ヘルプに記載があります。応募者や問い合わせをする人の多くは個人のアドレスを使うため、受付の窓口で開封確認を返信管理の土台にするのは現実的ではありません。

Q4. 開封確認をやめたら、返し忘れをどう防げばよいですか?

1件ごとに、担当者と状態と最終更新日の3つを持たせてください。返していないものだけが画面に残る形にすれば、誰も持っていない件と何日も止まっている件が自然に浮き上がります。相手が読んだかを推し量る必要がなくなり、こちらが返したかという確かめられる事実だけで回せます。

ガイド一覧へ

メールの開封確認とセキュリティ|何が渡り、何が残るのか|Halict