フォームを常時SSLにしたほうがよい、という話は何度も目にしているはずです。ただ、受付を回している立場から本当に知りたいのは、暗号化すると具体的に何が守られて、何は守られないままなのか、という線引きのほうです。
ここが曖昧なままだと、アドレス欄に鍵マークが出た時点で安心してしまい、そのすぐ後ろにある本当に漏れやすい場所を素通りすることになります。応募者から預かった書類が誰でも開ける共有リンクに置かれていても、通知メールが個人のスマホへ自動転送されていても、フォームの鍵マークは何ひとつ変わりません。
この記事では、通信の暗号化が守っている範囲を先に確定させ、そのうえで暗号化の外側にある範囲を並べます。埋め込みで別ドメインが混ざったときに回答者の画面で何が起きるのかも含めて、答える人が見るべき合図を整理します。
常時SSLが前提になった経緯と、フォームの入口で起きていること
常時SSLという言い方は、サイトの一部ではなくすべてのページを暗号化された通信で配る、という運用を指します。以前は、問い合わせフォームと決済のページだけを暗号化して、それ以外の紹介ページは暗号化しないという構成が普通でした。いまその構成が推奨されないのは、暗号化されていないページから暗号化されたページへ移る途中に、書き換えを差し込む余地が残るからです。
この変化は数年かけて起きたものではなく、ブラウザの表示が変わった時点で一気に実務へ降りてきました。設定を変えていないのに、ある日を境に問い合わせが減った、という相談が窓口の担当者から出てくるのはこの時期です。サイトの中身は何も変わっていないのに、回答者の画面だけが変わっていました。
ブラウザの表示が「安全です」から「保護されていません」に変わった
主要なブラウザは2018年ごろから、暗号化されていないページで入力欄に文字が入ると、アドレス欄に「保護されていません」という警告を出すようになりました。それまでは暗号化されたページに鍵マークを足す形でしたが、この時点で発想が逆になっています。暗号化されているのが当たり前で、されていないほうに警告を出す、という形です。
受付の現場で効いてくるのはここです。入力を始めた瞬間に警告が出るということは、名前や電話番号を打ち込もうとしている、まさにその手を止める位置に警告が出るということになります。応募や問い合わせは、書き始めるまでの心理的な段差が一番高いところです。そこへ「保護されていません」という文字が出れば、慎重な人ほど手を止めます。
しかも、この警告が出ていることに運営側は気づきにくい構造があります。自分が普段見ているのは管理画面と、社内から開くいつものページです。回答者が実際にたどる経路、たとえば検索結果から募集ページを開き、そこから申し込み欄へ進む流れを、警告の出方まで含めて確認する機会はほとんどありません。9割以上のページが暗号化されているいまの環境では、暗号化されていないページのほうが異物として目立ちます。
検索や広告の側からも暗号化が前提になった
検索エンジンは、暗号化されているかどうかを評価の要素のひとつとして扱うと公表しています。ただし、これを単独で大きな効果があるものと考えるのは実態と合いません。順位の要素としての重みは限定的で、暗号化したから急に上がるという性質のものではないというのが、公開されている説明の趣旨です。
それより実務で効くのは、暗号化されていないページが、そもそも他の仕組みから弾かれ始めていることです。広告の審査、外部サービスからの読み込み、決済の連携、SNSでの共有時のプレビュー生成といった場面で、暗号化されていないURLは扱いが悪くなります。ひとつひとつは小さな不都合ですが、募集を出すたびにどこかで引っかかる状態になります。
もうひとつ見落とされやすいのが、社内のネットワークやセキュリティ製品の側です。暗号化されていないページへの入力を遮断する設定になっている企業は珍しくありません。BtoBの問い合わせを受けている場合、相手企業の環境で入力欄がそもそも表示されない、という事態が起こり得ます。この場合、相手からは何の連絡も来ません。届かなかったことにすら気づけない種類の取りこぼしです。
それでも鍵マークは「安全の証明」ではない
ここから先が、この記事の本題です。鍵マークは、そのページを運営している組織が信頼できることを示すものではありません。運営者が個人情報を適切に扱うと約束したことを示すものでもありません。示しているのは、いま開いている画面と、そのURLのドメインの間の通信が暗号化されていて、途中で読まれたり書き換えられたりしていない、ということだけです。
この区別が曖昧なまま「SSLに対応しているので安全です」と案内文に書いてしまうと、後から困ります。何かあったときに、その一文が「安全だと言われたから入力した」という主張の根拠として持ち出されるからです。書くのであれば、通信の暗号化について書いていることが分かる形にします。
暗号化を導入すること自体は正しい判断です。ただし、それは入口の一段目を閉めただけであって、その先に何段あるのかを把握しておく必要があります。次の章から、守っている範囲と守っていない範囲を具体的に分けます。
通信の暗号化が実際に守っているもの
まず、暗号化がきちんと守ってくれる範囲を確定させます。ここを過小評価する必要はありません。守っている範囲は明確で、しかも重要です。
技術的にはSSLという呼び名は古いもので、いま実際に動いているのはTLSという仕組みです。ただ、証明書の販売や設定画面ではいまもSSLという言い方が広く使われているので、この記事でも通じる範囲で並べて扱います。重要なのは名前ではなく、この仕組みが何を保証しているかです。
途中の経路で中身を読まれない
回答者が入力した名前、電話番号、メールアドレス、志望動機の文章。これらは送信ボタンを押した瞬間に、回答者の端末からフォームのサーバーまで、いくつもの装置を経由して運ばれます。自宅の無線ルーター、契約している回線事業者の設備、途中の通信網、そして受け側のサーバーが置かれているデータセンターの機器。
暗号化されていない場合、この経路上のどこかで通信をのぞける立場にいる者は、内容をそのまま読めます。カフェや空港の共用無線につないでいる回答者がいれば、同じ無線につないでいる者が内容を取得できる状況が成立します。暗号化は、この経路上での盗み見を実質的に不可能にします。守っている範囲としては、これが一番大きい部分です。
応募の受付のように、履歴書に準じる情報を扱う入口では、この一点だけでも暗号化を必須と考えるべき理由になります。氏名と生年月日と連絡先が同時に流れる通信を、暗号化せずに公開の回線へ出す運用は、いまの水準では成り立ちません。
途中で中身を書き換えられない
暗号化が守っているもうひとつは、書き換えです。読めないだけでなく、途中で内容を差し替えられたら分かる仕組みになっています。
これが効くのは、送信するときより、むしろ受け取るときです。回答者のブラウザがフォームのページを読み込むとき、暗号化されていなければ、途中の経路で中身に別のものを混ぜ込めます。実際に起きてきたのは広告の差し込みですが、同じ仕組みで、送信先の設定を書き換えることも理屈のうえでは可能になります。入力欄はそのままに、送信先だけを別のサーバーに変えられたら、回答者にも運営側にも気づく手段がありません。
常時SSLが「全ページを暗号化する」という形で推奨されているのは、この経路にあります。フォームのページだけ暗号化していても、そこへ誘導している募集ページが暗号化されていなければ、募集ページのリンク先を書き換えるだけで別のフォームへ飛ばせてしまいます。入口だけ固くしても、そこへ至る廊下が空いていれば意味がありません。
つないだ先のドメインが名乗り通りである
3つめが証明書の役割です。証明書は、いま接続している相手が、確かにそのドメイン名の持ち主であることを、第三者である認証局が確認したという記録です。似たドメインを取って見た目をそっくりに作ったページは、そのドメイン自体の証明書しか取得できないので、本物のドメイン名では名乗れません。
ここで押さえておきたいのは、証明書が確認しているのは1つのこと、つまり「そのドメインを支配しているか」だけである場合が多い、という点です。ドメインの支配だけを確認して発行される種類の証明書では、運営者が誰なのか、実在する組織なのか、信頼できる相手なのかは一切確認されていません。無料で発行できる証明書が広く普及したことは全体としては良い変化ですが、鍵マークの意味が「ドメインの持ち主であることの確認」まで軽くなったことも同時に起きています。
組織の実在まで確認する種類の証明書も存在します。ただし、実在確認の結果はブラウザのアドレス欄にほとんど表示されなくなりました。証明書の詳細を開けば発行対象の組織名を見られますが、回答者がそこまで確認することは期待できません。つまり、証明書の種類を上げても、回答者の画面に見える差はほぼ無い、という前提で運用を組む必要があります。
暗号化が守らないもの
ここからが、抜け落ちやすい側です。通信の暗号化は、届くまでの区間を守る仕組みです。届いたあとには一切関与しません。
届いたあとの取り扱いは、暗号化の範囲外
送信が完了した瞬間、暗号化の役目は終わります。そこから先、その回答がどのデータベースに保存され、誰が見られる状態になり、どこへ通知として飛び、どの端末にダウンロードされるのかは、通信の暗号化とはまったく別の話です。
そして、実際に情報が外に出る事故の多くは、この後段で起きます。回答の一覧を書き出したCSVを、確認のために個人のメールアドレスへ送る。応募者の履歴書を、共有リンクを作って社外の面接官に渡す。そのリンクを閉じ忘れる。表計算ソフトの共有設定を「リンクを知っている全員」にしたまま放置する。どれも通信は暗号化されています。それでも情報は出ていきます。
法律の側は、通信の話ではなく、この取り扱いの側を求めています。
個人情報取扱事業者は、その取り扱う個人データの漏えい、滅失又は毀損の防止その他の個人データの安全管理のために必要かつ適切な措置を講じなければならない。 出典: www.ppc.go.jp
ここで求められているのは「必要かつ適切な措置」であって、通信の暗号化はその一部にすぎません。誰がその情報を見られるのか、いつまで持つのか、退職した担当者の権限をどう外すのか。こうした運用の設計まで含めて問われます。自分の受付が具体的にどこまで対応する必要があるのかは、扱っている情報の中身によって変わるので、判断に迷う部分は所管の窓口や専門家に確かめてください。
相手が信用できる運営者かどうかは分からない
鍵マークが出ている偽サイトは普通に存在します。ドメインを取得して証明書を発行するだけなので、偽サイトを作る側にとって鍵マークを付ける手間はほぼありません。むしろ、警告が出ると疑われるので、偽サイトほど暗号化されています。
これは受付をする側にとっても他人事ではありません。よく聞くのは、募集の案内を装って応募者に別のフォームを入力させる手口の相談です。案内メールのリンク先が、本物と一文字違いのドメインになっている。そのページも当然暗号化されているので、回答者の画面には鍵マークが出ます。
対策は技術ではなく案内の側にあります。募集の入口は1つに絞り、そのURLを公式ページに明記する。案内メールでは、リンクだけでなく正しいドメイン名を文字でも書いておく。回答者から「このURLは本物か」と問い合わせが来たときに、即答できる状態にしておく。この3点で、たいていの混乱は防げます。
入力の途中で外へ出ていく分は別の話
フォームのページには、フォーム本体以外のものが一緒に読み込まれていることがあります。アクセス解析、広告の計測、チャットの窓口、フォントの読み込み。これらはそれぞれ別のドメインへ通信します。
フォームの送信そのものが暗号化されていても、こうした付随する仕組みが何をどこへ送っているかは、鍵マークからは分かりません。入力欄に打ち込んだ内容がそのまま外部の計測へ流れる作りになっている例も報告されています。特に、入力の途中経過を記録する種類の仕組みを入れている場合は、何を記録対象から外しているかを確認する必要があります。
個人情報を扱う入口では、そのページに載せる外部の仕組みを最小限にしておくのが無難です。計測や広告の仕組みは、募集ページ側に置けば足りることが多く、入力の画面まで持ち込む必要はありません。
埋め込みで別ドメインが混ざるときの見え方
ここが、常時SSLの話で一番説明が足りていない部分です。自分のサイトを全ページ暗号化したとしても、フォームを外部のサービスから埋め込んでいる場合、回答者の画面では複数のドメインが同時に動いています。
自社ページの中に別ドメインのフォームを置いた場合
外部のフォームをiframeで埋め込んでいるとき、アドレス欄に表示されているのは自社のドメインです。鍵マークも自社のページに対して出ています。ところが、その枠の中で動いているのは提供元のドメインのページであり、入力内容は提供元のサーバーへ送信されます。
回答者から見ると、これは見えません。自社のドメインで、自社の鍵マークが出ているページに入力しているように見えます。実際には、入力した個人情報は自社ではなく提供元の管理下に入ります。この構造自体は問題ではなく、フォームサービスを使うということはそういうことです。問題になるのは、この事実を案内していない場合です。
個人情報の利用目的や委託先について記載するとき、「入力内容は当社のサーバーへ送信されます」と書いていると、実態と食い違います。外部のサービスを使っている場合は、その旨と、預けた情報がどう扱われるのかを説明できる状態にしておく必要があります。回答者から質問されたときに答えられるかどうかが、そのまま準備の度合いを表します。
混在コンテンツで鍵が消える、あるいは表示自体が止まる
暗号化されたページの中に、暗号化されていない読み込みが混ざることを混在コンテンツと呼びます。ページ本体はHTTPSなのに、その中で読み込んでいる画像やJSがHTTPになっている状態です。
現在のブラウザは、この状態に対してかなり厳しく動きます。JSやCSSのように、ページの動きを変えられる種類のものが暗号化されずに読み込まれている場合、ブラウザは読み込み自体を止めます。画像のような表示だけのものは、自動的に暗号化された通信へ切り替えを試み、それでも駄目なら止めます。
受付の現場で何が起きるかというと、フォームが表示されない、送信ボタンを押しても何も起こらない、という形で現れます。しかも、この不具合は運営側の環境では再現しないことがあります。ブラウザの設定や拡張機能の差で挙動が変わるためです。「一部の人だけ送信できない」という相談が来たら、まずこの混在コンテンツを疑うのが早道です。開発者向けの画面を開けば、止められた読み込みが警告として出ています。
古いサイトに後からフォームを埋め込むときは、この事故が特に起きやすくなります。テーマやプラグインの中に、暗号化されていないURLが直接書き込まれたまま残っているためです。サイト全体を暗号化に移したときに、この書き換えが漏れている箇所が、フォームを置いた瞬間に表面化します。
送信ボタンを押した先が別ドメインになる形
埋め込まずに、自社サイトにはリンクだけを置き、押すと提供元のフォームページへ移動する形もあります。この場合、回答者は移動した時点でアドレス欄のドメインが変わったことを目にします。
慎重な回答者ほど、ここで一度止まります。募集要項を読んでいたドメインと、いま入力しようとしているドメインが違うからです。両方とも暗号化されていて、両方に鍵マークが出ていても、名前が違うという事実は残ります。
これを不利と考えて埋め込みを選ぶ判断もありますが、案内の書き方で解消できる部分も大きくなります。募集ページに「応募フォームは外部のサービスを使用しています。移動先のドメインは次のとおりです」と一行書いておくだけで、止まる人はかなり減ります。独自ドメインを割り当てられるサービスであれば、移動先を自社ドメインのサブドメインに揃える方法もあります。どちらを選ぶにしても、回答者が画面で見る変化を先に説明しておく、という考え方は同じです。
受付の担当が実際に見るべき合図
ここまでを踏まえて、答える立場の人が具体的に何を確認すればよいかを整理します。技術の設定を自分でやる必要はありません。見るべきなのは、回答者の画面に出ているものです。
回答者と同じ経路を、一度だけ最後までたどる
一番確実な確認方法は、募集の告知を見た人と同じ順番でページを開き、実際に入力して送信まで済ませることです。社内のブックマークから管理画面に入るのではなく、検索結果や案内メールのリンクから入ります。
見る場所は4つです。募集ページを開いた時点でアドレス欄に警告が出ていないか。入力欄をクリックした瞬間に表示が変わらないか。入力の途中でドメインが変わる場面があるか、あるならその変化を事前に説明しているか。送信したあとに完了の表示が出て、回答者に控えが届くか。
これをスマートフォンでも一度やります。画面の幅が狭いブラウザではアドレス欄の表示が省略され、警告の出方も変わります。応募や申し込みの多くはスマートフォンから来るので、この確認を飛ばすと、多数派の見え方を知らないまま運用することになります。
証明書の有効期限と、更新が自動で回っているか
証明書には有効期限があります。本記事の執筆時点では、業界の取り決めにより最長でも398日までとされており、実際にはもっと短い運用が主流です。無料で発行できるものは90日で切れる設計になっており、自動更新の仕組みとセットで使う前提になっています。
期限が切れると、回答者の画面には赤い警告の全画面が出ます。「この接続ではプライバシーが保護されません」という種類の画面で、続行するには目立たないリンクを押す必要があります。この状態になったフォームに入力する人はまずいません。募集期間の途中でこれが起きれば、その日から応募がゼロになります。
現場では、担当者の交代と重なったときに事故になりやすいと言われています。更新の通知メールが退職した担当者のアドレスに届いていて、誰も見ていなかった、という形です。確認しておくべきは、更新が自動で回っているか、通知の宛先が現在の担当に向いているか、そして期限切れが起きたときに気づける仕組みがあるか。この3つだけで、この種の事故はほぼ防げます。
回答者に説明できる言葉を持っているか
問い合わせや応募の受付をしていると、「入力した情報はどう扱われますか」という質問が来ます。頻繁ではありませんが、来たときに答えられないと、その一件は確実に失われます。
用意しておくべきなのは、通信が暗号化されていること、預かった情報を誰が見るのか、いつまで保管するのか、外部のサービスを使っている場合はその旨、この4点を平易な言葉で説明した文章です。専門用語を並べる必要はありません。むしろ、「SSLで暗号化しているので安全です」とだけ答えるのは避けるべきです。範囲を超えた説明になっているうえ、聞いている側が本当に知りたい「誰が見るのか」に答えていません。
答える人がこの説明を持っていると、受付の質そのものが変わります。回答者の不安が具体的に何なのかを聞き取れるようになり、必要以上の項目を集めていたことに気づく機会にもなります。
通信より先に穴が空きやすい、送信されたあとの経路
暗号化を整えたあとに残る課題は、ほぼすべてが送信されたあとの経路にあります。ここが整理されていないと、入口だけ固い状態になります。
通知メールと、その転送
多くのフォームは、回答があると担当者へ通知メールを送ります。この通知の本文に、回答の中身がそのまま載っている設定になっていることがあります。氏名、電話番号、住所、相談内容。それがメールとして、担当者の受信箱に残り続けます。
問題は転送です。外出が多い担当者が、会社のアドレスから個人のスマートフォンのアドレスへ自動転送を設定している。担当が複数いるので、共有のアドレスへ一度受けてから各自へ転送している。こうした経路が加わるたびに、個人情報のコピーが増えます。退職時にその受信箱をどうするのかまで決めている組織は多くありません。
現実的な対処は、通知メールに中身を載せないことです。「新しい応募が1件届きました」とだけ書いて、内容は管理画面で見る形にします。これだけで、メールという追いかけにくい経路に個人情報が流れ出るのを止められます。送信されたあとの道具がそろっているフォームであれば、通知の中身を減らしても運用が回ります。逆に、通知メールが唯一の受け皿になっている状態では、中身を減らすと仕事にならないので減らせません。
表計算ソフトへの書き出しと共有リンク
回答を表計算ソフトに書き出して管理している場合、その表の共有設定が実質的な公開範囲になります。ここが最も見落とされます。
よくあるのは、面接の日程を調整するために外部の面接官へ表を共有し、そのまま設定を戻さない形です。あるいは、一時的に「リンクを知っている全員が閲覧可」にして、共有した相手が別の誰かにそのリンクを渡す形です。フォームの通信をどれだけ厳重にしても、この一手で範囲は無制限になります。
判断の目安として、100件を超えたあたりから表での管理は破綻し始めると言われています。列が増え、担当ごとにフィルタが変わり、誰がいつ触ったのかが追えなくなります。この段階になると、権限の管理も同時に崩れます。表を配るのではなく、必要な人に必要な範囲だけ見せる形へ移す判断が必要になります。
添付ファイルの受け渡し
応募書類や見積書のように、ファイルを受け取る受付では、そのファイルの置き場所が問題になります。フォームの提供元に保管されている場合は、そのURLを知っていれば誰でも開けるのかどうかを確認してください。推測しにくい長い文字列のURLになっていても、URLを知っている人は開けます。共有した相手が転送すれば、そこから先は追えません。
ファイルの受け渡しは、通信の暗号化がまったく守っていない領域です。ここを整えるほうが、証明書の種類を上げるよりはるかに効果があります。誰がダウンロードしたかが残るか、保管期間を過ぎたら消えるか、担当者を外れた人の権限が消えるか。確認すべきはこの3点です。
受付の型ごとに、通信以外のどこが弱くなるか
暗号化は全部の受付に等しく必要ですが、その先で弱くなる場所は受付の型によって変わります。ここでは、届いたあとの経路がどこで詰まりやすいかを型ごとに整理します。
応募の受付は、履歴書や職務経歴書という形で、まとまった個人情報が一度に届く入口です。通信の暗号化は当然として、その書類を誰が開けるのか、面接官へどう渡すのか、不採用になった人の書類をいつ消すのかまで決まっていないと、実質的に守れていません。受付から書類の確認、連絡までを同じ画面で追う流れは採用の応募受付にまとめています。
助成金や公募の受付は、提出書類の不備を差し戻して再提出させる往復が発生します。この往復がメールで行われると、同じ書類の複数の版が受信箱に散らばります。どれが最新かが分からなくなり、審査の途中で古い版を見てしまう事故が起きます。要件の確認から差し戻しまでを含む受付の設計は助成金・公募の受付で整理しています。
問い合わせの受付では、返信の経路そのものが弱点になります。誰が返したのかが表に残らなければ、二重返信と返し忘れは必ず起きます。二重返信は、相手に「管理されていない」と伝わる合図でもあります。担当の決め方と返信の記録の残し方は問い合わせの受付にまとめています。
イベントや講座の申し込みは、当日までに複数回の連絡が発生します。参加者の名簿を作って全員へ一斉に案内を出すとき、宛先の設定を誤ると参加者どうしにアドレスが見えます。これは通信の話ではなく操作の話ですが、実務での発生頻度は高いほうです。定員や繰り上げまで含めた流れはイベントの申し込みと講座の受講申し込みにそれぞれ書いています。
施設の利用申請や修理の受付では、申請の内容と対応の状態を突き合わせる必要があります。届いた申請が未着手なのか、確認中なのか、可否を返したのかが分からないと、催促の連絡に即答できません。日程の調整まで含む形は施設利用の申請、受付から対応の完了までを追う形は修理・サポートの受付にまとめています。会費の案内と本人確認まで続く入会の受付は会員の入会申し込みが近い形です。
いま使っている道具を変えるかどうかを考えている場合は、暗号化されているかどうかで比べても差は出ません。主要なフォームサービスはどれも暗号化された通信で提供されているからです。比べるべきなのは、届いたあとに誰が何を見られるか、その権限をどう絞れるか、記録が残るかのほうです。表計算ソフトで回答を追う形からの移行を考えているならGoogleフォームとの比較が、サイトに組み込んだフォームから通知メールで受けている形ならContact Form 7との比較が、社内のアカウント基盤で運用している形ならMicrosoft Formsとの比較が、それぞれ判断の材料になります。どの記事も、まずいまの道具で足りる場合を先に書いています。
受付の状態を残す、担当を割り当てる、対応の履歴を追う、といった機能がどこまであるかはできることに一覧があります。文章で読むより実際の画面を見たほうが早い部分は動くところを見るで確認できます。費用の考え方は料金に、導入前に多い疑問はよくある質問にまとめています。
最後に順序を確認しておきます。通信の暗号化は、やっていなければ話が始まらない前提であり、いまはほぼ自動で満たされる条件になりました。判断のエネルギーを使うべきなのは、その先です。誰が見られるのか、記録が残るのか、担当が変わったときに権限が正しく移るのか。鍵マークは、そこには何も答えてくれません。答えるのは、受け付けたあとをどう回すかを決めた人だけです。
Q1. フォームのページだけをSSLにすれば十分ではありませんか？
不十分です。フォームへ誘導している募集ページが暗号化されていないと、そのページのリンク先を途中の経路で書き換えられる余地が残ります。入力の画面だけを固めても、そこへ至る経路が空いていれば意味がありません。サイト全体を暗号化する常時SSLが推奨されているのはこの理由によります。
Q2. 鍵マークが出ていれば、そのフォームは安全だと言えますか？
言えません。鍵マークが示しているのは、画面とそのドメインの間の通信が暗号化されていて、途中で読まれたり書き換えられたりしていないことだけです。運営者が信頼できるか、届いたあとの情報が適切に扱われるかは含まれません。偽サイトにも鍵マークは普通に付きます。
Q3. 外部のフォームを埋め込むと、入力内容はどこへ送られますか？
埋め込んだ提供元のサーバーへ送られます。アドレス欄には自社のドメインが表示されているため回答者からは見えませんが、実際の管理下は提供元です。個人情報の取り扱いを案内するときは、外部サービスを使っている旨を書ける状態にしておいてください。
Q4. 証明書の有効期限が切れると何が起きますか？
回答者の画面に赤い警告の全画面が表示され、続行するには目立たないリンクを押す必要が生じます。この状態で入力を続ける人はほとんどいないため、募集期間中に起きれば応募が止まります。自動更新が回っているか、通知の宛先が現在の担当になっているかを確認してください。