問い合わせフォームのスパム対策|誤判定と受付の流れを確認する手順
- こんな方へ
- 自社のホームページの問い合わせフォームに売り込みや機械的な送信が増えて対策を見直したい、対策を入れたら相談が減った気がする、「送ったのに返事がない」と言われた、設定を社外に任せていて中身が分からない、という小さな会社・店舗の担当者と責任者
- 日付
- 初版
この記事の結論
問い合わせフォームの迷惑な送信への対策は、迷惑な送信の件数だけで見直しの成否を決めず、1回の送信の試みを受付IDや観測IDで1件として、送信の試み・受付・通知・人の確認のどこまで確かめられたかを記録します。正規・迷惑・判定保留という判定の軸と、未確認・確認中・対応決定・引継ぎ済という業務の状態を別の欄にし、仕組みが止めたものを迷惑と確定しません。設定は一度に一つだけ変えて変更票に版・承認・反映の観測・止める条件を残し、同じ条件で7日間と28日間を比べます。見えない地点は0ではなく未取得と書き、件数が少なければ判断を保留します。
この記事で確認できること
- フォーム経由の送信と直接のメールの分け方、送信の試み・受付・通知・人の確認の4つの地点の棚卸し、見直す前に残す基準の版・対象期間・観測の限界
- 自動の判定と人の確認の書き分け、判定の軸と業務の状態、誤判定を疑う手がかりと断定しない書き方、担当と設定を変えられる人の境界、許可された試験と再現票、試験の観点、一度に一つの変更と変更票、止める条件
- 判定保留・担当不在・確認不能の扱い、復旧の判断と過去の送信、架空の4つの事業の例、受付・判定の票と観測票、7日間・28日間の比べ方と未取得、登録不要の20項目の点検表と空欄の2つの票
結論:止まった地点と、判定した人を分けて記録する
問い合わせフォームに売り込みや機械的な送信が増えると、迷惑な送信を防ぐ仕組みを足したり、判定を厳しくしたりしたくなります。ところが、見直しの後に「迷惑な送信が減った」ことだけを見ていると、本当に相談したかった人の送信まで止まっていても気付けません。相談が来ない日が続いても、それが「相談がなかった」のか「送れなかった」のか「届いたのに誰も見ていない」のかを、後から区別できなくなります。
この記事が答える問いは1つです。自社フォームの迷惑な送信への対策を見直すとき、正規の相談が誤って止められていないかと、送信から担当の確認までのどこで止まったかを、担当の間でどう確かめて引き継ぐか。 答えを先にまとめると、次の4つです。
- 1件は「1回の送信の試み」とし、受付が記録した受付IDか、試験や報告で付けた観測IDで呼ぶ。同じ人の再試行や重複は、別の欄で印を付ける。個人ごとの行動は追わない
- 「送信の試み」「受付(保存・記録)」「通知」「人の確認」の4つの地点を分け、どこまで確かめられたかを書く。見えない地点の件数は0にせず、未取得と書く
- 「正規・迷惑・判定保留」という判定の軸と、「未確認・確認中・対応決定・引継ぎ済」という業務の状態を、別の欄にする。どちらも、この記事で編集部が提案する区分です
- 判定の仕組みや設定は、一度に一つだけ変える。変えた人・日時・版・証拠を変更票に残し、同じ条件で7日間と28日間を見比べる。迷惑な送信の件数だけでは成果と言わず、正規の受付・誤判定の疑い・不明を分けて並べる
この記事が向いている方
小さな会社や店舗で、自社のホームページの問い合わせフォームを管理している担当者と、その見直しを決める責任者を想定しています。迷惑な送信が増えて困っている、仕組みを入れたら相談が減った気がする、「送ったのに返事がない」と言われた、制作会社や社外の担当に設定を任せていて中身が分からない、といった状況です。
先にお伝えしておくこと
この記事の地点の分け方、判定の軸と業務の状態、票、点検表は、Akatsuki編集部の実務提案です。特定の会社で効果を測った結果ではなく、迷惑な送信を確実に止めることや、誤判定がなくなることを約束するものではありません。文中の会社・件数・日付は、すべて説明のための架空の例と仮の値です。公式の説明は第3節に短くまとめ、それ以外の部分には【編集部の提案】と書き分けています。
既刊の記事との分担と、この記事で扱わないこと
フォームそのものの使いやすさ、つまり入力項目、エラーの伝え方、スマホでの入力、確認の画面、完了の表示を、問い合わせが届くまでの7つの地点で点検する手順は、既刊の問い合わせフォームを改善する手順|入力項目・エラー・スマホから受付まで20項目で点検でまとめています。その記事では、迷惑な送信を防ぐ仕組みの設定の詳しい手順を範囲の外としています。
この記事は、その隣にある「迷惑な送信への対策を見直すときの、確かめ方と引継ぎ」だけを扱います。既刊の記事を先に読んでいなくても使えるように書いていますが、入力項目やエラーの文言を直したくなったら、既刊の記事の点検表に戻ってください。
| 確かめたいこと | 扱う記事 |
|---|---|
| 入力項目・エラー・スマホでの入力・完了の表示 | 既刊の記事(フォームの改善) |
| 迷惑な送信への対策を見直すときの、地点の分け方と誤判定の疑い | この記事 |
| 判定の軸・業務の状態・変更票・同じ条件での見比べ | この記事 |
| 届いた相談に誰が返信し、どう引き継ぐか | 既刊の返信管理の記事(第9節で案内) |
この記事で扱わないこと
次のことは扱いません。フォームや判定の仕組みのプログラムの書き方、迷惑な送信を行う側の手口や、仕組みをすり抜ける方法、仕組みを使うための鍵や管理の権限を新しく取る手順、防ぐ仕組みやプラグインの比較と料金、個人情報や通信に関わる法令に適合しているかの判断、情報が漏れたなどの事故への対応、特定の製品の記録(ログ)を解析する操作です。これらは、フォームの仕組みや契約、提供元の説明によって大きく違い、記事の手順だけで正しく再現できないためです。
また、見直しのために実際の問い合わせ窓口へ本物の相談を送ること、他社のフォームへ送ることもしません。試験の送信は、自社で許可を取ったうえで、印を付けて行います(第10節)。
公式の説明の短い要約と、この記事の提案の境界
迷惑な送信を見分ける仕組みには多くの種類があり、提供元ごとに説明が違います。ここでは、代表的な2つの提供元の公式の説明から、見直しの考え方に関わる点だけを短くまとめます。どちらかを使うことを勧めるものではなく、仕組みの選び方や設定の手順も扱いません。確認日は2026年10月24日で、どちらのページも公開日の記載はありません。
【公式情報】reCAPTCHAの評価(出典1)では、トークンが有効か、操作の名前(action)が想定と合うかを、スコアとは別に確かめます。スコアは操作のリスクの程度を示す判断材料で、対応はサイトの事情に合わせて決めます。試験の環境や導入して間もない時期は、長く運用した本番と値が異なる場合があります(最終更新2026年10月23日)。
【公式情報】Validate the token(出典2)では、Turnstileの導入にはサーバーの側でのSiteverifyによる検証が必須で、画面の部品だけでは足りないとしています。トークンは発行から5分間有効で、検証は1回だけです。(最終更新2026年10月22日)
ここから先は編集部の提案です
上の要約から言えるのは、トークンの検証とスコアは別で、スコアはリスクの判断材料にとどまるということまでです。どの値なら止めるべきか、何件止まれば効果があったか、誤判定がどのくらい起きるかは、公式の説明からは決まりません。
そこで第4節から先は、どの仕組みを使っていても共通に使える、見直しの記録の付け方を提案します。仕組みに固有の条件は、この節の要約だけを参照し、後の節では繰り返しません。設定を変える担当者は、変える日に提供元の最新の説明を開き直してください。説明は更新や移行で変わることがあります。
フォーム経由の送信と、メールアドレスへの直接の送信を分ける
迷惑な送信と一口に言っても、入ってくる経路は1つではありません。フォームの画面から送られたものと、サイトに載せたメールアドレスへ直接送られたものは、通る仕組みも、止まる地点も違います。見直しの前に、まずこの2つを分けて観測します。
| 経路 | 通る仕組み | 観測する場所の例 | この記事での扱い |
|---|---|---|---|
| フォームの画面から送る | フォームの判定・受付の記録・通知 | 受付の記録、通知の受信箱 | 主な対象 |
| 載せたメールアドレスへ直接送る | メールの受信の仕組みと、迷惑メールの振り分け | 受信箱と迷惑メールのフォルダー | 件数を別の列に分けるだけ |
| 電話・対面・他のサービスのメッセージ | フォームとは別 | 各窓口の記録 | 対象外。混ぜて数えない |
フォームの判定を厳しくしたのに迷惑な送信が減らないとき、その送信が実はメールアドレスへの直接の送信だった、ということがあります。逆に、通知のメールが迷惑メールのフォルダーに入って担当が気付かないのは、フォームの判定ではなく、受信の側の振り分けの問題です。経路と地点を分けずに「迷惑な送信」としてまとめると、どこを直すべきかが分からなくなります。
経路を見分けられないときの扱い
担当の受信箱だけを見ていると、フォームから来た通知なのか、直接のメールなのかを見分けにくい場合があります。そのときは無理に推測せず、「経路不明」という列を作って数えます。経路不明の件数が多ければ、通知の件名に決まった語を入れる、受付の記録と突き合わせる、といった、見分けるための準備を先に進めます。準備を誰がいつ進めるかは、第9節の担当の境界で決めます。
直接のメールを数えるときの注意
【編集部の提案】載せたメールアドレスへの直接の送信は、フォームの判定を通りません。そのため、フォームの見直しの前後で比べる表には入れず、別の列で件数だけを残します。迷惑メールのフォルダーに入ったものを数えるかどうかも、期間の前後でそろえます。前の期間は受信箱だけ、後の期間は迷惑メールのフォルダーも含めて数えると、件数が増えたように見えてしまいます。
また、直接のメールの迷惑な送信が多いからといって、フォームの判定を厳しくしても効果は見込めません。経路が違えば、見直す相手も違います。メールの受信の仕組みの設定は、この記事の範囲の外です。
いまの流れを棚卸しする:送信の試み・受付・通知・人の確認
見直しの出発点は、いまの流れがどうなっているかを書き出すことです。フォームから送られた1回の試みは、次の4つの地点を通ります。
| 地点 | 起きること | 確かめられる場所の例 | 見えないことが多いもの |
|---|---|---|---|
| A 送信の試み | 問い合わせる人が送信を押す | 試験の送信、本人からの報告 | 試みの総数 |
| B 受付 | サーバーが受け取り、保存・記録する | 受付の記録、管理の画面 | 受付の前に止まった試み |
| C 通知 | 担当の受信箱やチャットへ知らせが届く | 担当の受信箱、通知の記録 | 振り分けで見えない知らせ |
| D 人の確認 | 担当が開き、判定と次の対応を決める | 業務の記録、返信の記録 | 開いたが記録しなかった確認 |
【編集部の提案】大事なのは、地点Aの「送信の試み」は、ほとんどの場合すべては数えられないという点です。受付の前で止まった試みは、受付の記録に残らないことがあります。問い合わせた人が報告してくれない限り、止まったことすら分かりません。ですから、受付の記録の件数を「問い合わせようとした人の数」と読み替えてはいけません。
棚卸しで書くこと
いまの流れについて、次のことを1枚に書き出します。
- フォームの判定の仕組みが何か(仕組みの名前と、誰が入れたか。分からなければ「不明」)
- 判定で止まった送信がどこへ行くか(拒否されて画面に何か出る、保留の置き場所に入る、受付はされるが印が付く、など)
- 受付の記録がどこにあり、誰が見られるか
- 通知の宛先、件名、振り分けの決まり
- 担当が受付の記録と通知のどちらを見て判定しているか
書けない項目は、空欄のままにせず「不明」と書きます。不明の項目は、見直しを始める前に誰が調べるかを決めます。不明のまま設定を変えると、どの地点に影響したかを後から追えません。
棚卸しの記入例
次は、架空の事業で書いた棚卸しの例です。分からない項目が残っていても、書き出すことで調べる順番が決まります。
| 項目 | 記入 | 次に調べること |
|---|---|---|
| 判定の仕組み | 制作会社が入れた。名前は不明 | 制作会社に名前と入れた日を聞く |
| 止まった送信の行き先 | 画面に「送信できませんでした」と出る。記録に残るかは不明 | 試験で確かめる許可を取る |
| 受付の記録 | 管理の画面にある。見られるのは代表だけ | 受付の担当も見られるかを相談する |
| 通知 | 共有の受信箱へ。件名は毎回同じ | 件名に経路の語を入れられるか聞く |
| 担当が見ているもの | 通知だけ。受付の記録は見ていない | 週に1回、受付の記録と照らし合わせる |
この例では、担当が通知しか見ていないため、地点Bにあって地点Cに届かなかった送信には誰も気付けません。照らし合わせる頻度を決めるだけでも、見えない範囲は狭くなります。
見直す前に、基準の版・対象期間・観測できる範囲を書く
見直しの前と後を比べるには、「前」がどういう状態だったかを書き残しておく必要があります。変えた後で思い出そうとしても、どの設定がいつから有効だったのかは、たいてい曖昧になります。
| 欄 | 書くこと | 書き方の例(架空) |
|---|---|---|
| 基準の版 | いまの判定の仕組みと設定に付ける名前 | 版1(10月1日時点の設定) |
| 版の中身 | 何をどう判定しているかの要点 | 判定で止まったものは保留の置き場所へ |
| 対象期間 | 比べる期間の始まりと終わり | 変更日の前の28日間 |
| 対象の経路 | フォームか、直接のメールか | フォームだけ |
| 見える地点 | A〜Dのうち、件数を確かめられる地点 | B・C・D(Aは試験と報告だけ) |
| 見えない地点 | 件数を確かめられない地点と、その理由 | A(受付の前に止まった試みは残らない) |
| 記録の置き場所 | 受付の記録・通知・業務の記録の場所 | 受付の管理の画面、共有の受信箱、業務の表 |
観測の限界を先に書く
【編集部の提案】「見えない地点」の欄は、空欄にしないでください。たとえば、判定で拒否された試みが記録に残らない仕組みなら、「拒否された試みの件数は取得できない」と書きます。この1行があるだけで、後で「拒否が0件だった」という誤った読み方を防げます。0件と未取得は、意味がまったく違います。
基準の期間に、サイトの作り直しや広告の開始、季節の繁忙期などが重なっている場合も、この欄の下に書いておきます。比べる2つの期間で条件が違えば、件数の差が見直しの結果なのか、ほかの変化の結果なのかを分けられません。条件の違いを消すことはできなくても、書いておけば判断を保留する根拠になります。
設定の画面を写すとき
基準の版を残すために設定の画面を画像で残す場合、鍵や秘密の値、管理の権限に関わる情報が写り込まないようにします。必要なのは「どういう判定をしていたか」の要点で、鍵の値ではありません。写り込んでしまった画像は共有の場所に置かず、設定の責任者に扱いを相談してください。
自動の判定と、人の確認を分ける
迷惑な送信への対策の多くは、仕組みが自動で判定し、その結果で受け付ける・止める・印を付けるといった扱いを分けます。一方、受付の後で担当が中身を読み、「これは正規の相談だ」「これは売り込みだ」と決めるのは人の確認です。この2つは、同じ「判定」という言葉で呼ばれがちですが、記録では分けます。
| 区分 | 誰が決めるか | 記録する欄 | 書かないこと |
|---|---|---|---|
| 自動の判定 | 仕組み | 仕組みの扱い(受付・保留・拒否など) | 人の判定で上書きしない |
| 人の確認 | 担当 | 判定の軸(正規・迷惑・判定保留) | 仕組みの扱いを判定の軸に写さない |
| 業務の状態 | 担当 | 未確認・確認中・対応決定・引継ぎ済 | 判定の軸と混ぜない |
判定の軸と業務の状態
【編集部の提案】判定の軸は「その送信が何だったか」、業務の状態は「その送信への作業がどこまで進んだか」です。この記事では、次のように決めることを提案します。
- 判定の軸:正規(相談として受け止めるもの)/迷惑(売り込みや機械的な送信と担当が判断したもの)/判定保留(読んでも決めきれないもの)
- 業務の状態:未確認(まだ誰も開いていない)/確認中(開いたが判定や対応が決まっていない)/対応決定(返信する・しないなど次の対応が決まった)/引継ぎ済(返信などの担当へ渡した)
たとえば「判定保留で、確認中」「正規で、引継ぎ済」のように、2つの欄を組み合わせて書きます。判定の軸が空欄の行は未判定として数え、0件や迷惑には含めません。
判定保留を置く理由
判定の軸を正規と迷惑の2つだけにすると、担当は迷った送信をどちらかへ寄せてしまいます。営業の案内に見えるが実際に取引の相談かもしれない、本文が短すぎて何の相談か分からない、といった送信は珍しくありません。判定保留という逃げ場を作っておくと、迷ったものが迷ったまま記録に残り、後で別の人が読み直せます。判定保留の件数が多いことは、判定の決まりを見直す手がかりにもなります。
仕組みが止めたものを、迷惑と確定しない
仕組みが拒否したり保留にしたりした送信を、そのまま「迷惑」と数えないでください。仕組みの扱いは、人がまだ確かめていない途中の結果です。拒否された試みが記録に残らない場合は、中身を誰も見ていないので、迷惑だったとも正規だったとも言えません。「拒否が増えた=迷惑な送信をたくさん防げた」「拒否された中に有効な案件はなかった」という読み方は、どちらも根拠がありません。
正規の相談が誤って止められたかもしれない手がかり
誤判定は、それ自体を直接見ることが難しいものです。止められた本人が別の経路で連絡してくれない限り、記録に何も残らないことがあります。そこで、誤判定を「疑う手がかり」を決めておき、手がかりが出たら確かめる、という順にします。
| 手がかり | 考えられること(断定しない) | 次に確かめること |
|---|---|---|
| 電話やSNSで「フォームから送れなかった」と言われた | 地点Aで止まった可能性 | 日時・端末・画面の文言を聞き、観測票に書く |
| 「送ったのに返事がない」と言われた | 地点B・C・Dのどこかで止まった可能性 | 受付の記録にあるかを先に確かめる |
| 保留の置き場所に、名前や具体的な相談内容がある送信が入っている | 自動の判定が厳しすぎる可能性 | 人が読み、判定の軸を書く |
| 変更の後に、正規の受付が減ったように見える | 判定の変更の影響、または別の要因 | 同じ条件の期間で比べる(第17節) |
| 特定の端末や回線からの報告が続く | その環境だけで止まる可能性 | 許可された試験で再現を試す(第10節) |
断定しない書き方
【編集部の提案】手がかりが1つ出ただけで、「仕組みが誤判定した」と書かないでください。本人が送信を押し忘れた、通知が迷惑メールのフォルダーに入った、担当が見落とした、なども同じ見え方をします。観測票には「誤判定の疑い」とだけ書き、確かめた地点と、確かめられなかった地点を分けて記録します。止まった地点が分かっても、それだけでは原因も誤判定も確定しません。確定と書けるのは、正規の相談と同じ条件だと確かめた試験の結果や、変更の前後の記録・判定の記録との照合によって、仕組みが原因だと確認できた範囲だけです。再現できなくても、記録の照合で原因が分かる場合はあります。確認できなければ、疑いのまま残します。
本人から聞き取るときは、相談の中身や個人の情報を記録に写す必要はありません。日時の幅、使った端末の種類、画面に出た文言、どこまで進んだか、で足ります。聞き取りでは、次のような質問を使います。
- 送ったのは、だいたい何日の何時ごろでしたか
- パソコンとスマホのどちらで送りましたか
- 送信を押した後、画面に何と出ましたか。覚えている範囲で構いません
- 完了の画面や、自動の返信のメールは見ましたか
- 何回か送り直しましたか
答えが「覚えていない」でも、そのまま書きます。推測で補うと、再現の試験の条件を誤ります。
止められた本人への連絡
報告をくれた人には、別の確かな経路で相談を受け付けたことを先に伝えます。仕組みの調子や誤判定の有無を説明する必要はありません。原因の調べは、相談への対応とは別の作業として、担当の間で進めます。
担当と、設定を変えられる人の境界
迷惑な送信への対策では、「設定を変えられる人」と「届いた相談を判定する人」が別であることが多く、ここが引継ぎの切れ目になります。制作会社や社外の担当が仕組みを入れ、社内の担当が受信箱を見ている、という形はよくあります。
| 役割 | 主にすること | 変えてよい範囲 | 変えないこと |
|---|---|---|---|
| 受付の担当 | 届いた送信を開き、判定の軸と業務の状態を書く | 業務の記録 | 判定の仕組みの設定 |
| 設定の担当 | 判定の仕組みの設定を変え、版を上げる | 変更票で承認された設定だけ | 業務の記録の判定の軸 |
| 責任者 | 変更を承認し、止める・戻すを決める | 変更の承認、試験の許可 | 設定と承認は原則として別の人にする(難しい場合は下の「1人で兼ねる場合」) |
| 社外の担当 | 契約の範囲で設定や点検をする | 依頼された範囲 | 依頼のない変更、権限の追加 |
権限と鍵の扱い
【編集部の提案】見直しのために、新しく管理の権限を作ったり、鍵を発行したりする必要が出たら、その場で進めず、責任者の判断に回します。権限や鍵は、誰が持っているかを一覧にしておき、退職や契約の終了のときに外す人を決めておきます。権限の追加や鍵の取り扱いの手順は提供元や契約で違うため、この記事では扱いません。
1人で兼ねる場合
小さな会社では、設定の担当と受付の担当、責任者が同じ人であることも珍しくありません。そのときは、変更票を書いた日と承認した日を別にする、変更の翌日に自分で試験をして結果を書く、など、時間を空けて自分の作業を見直す工夫をします。ただし、時間を空けた自分の見直しは、別の人による確認と同じではありません。変更票には「同じ人が確認」と書き、別の人に見てもらえる機会ができたら、その人に確かめてもらいます。この記事で「別の人が確かめる」と書いた箇所は、1人のときはこの扱いに読み替えてください。
社外の担当と先に決めておくこと
制作会社や保守の会社が設定を受け持つ場合は、変更のたびに受け取るもの(変更前と変更後の版、変えた内容の要点、反映の日時)と、変更を頼む窓口を先に決めます。「迷惑な送信が多いので何とかしてほしい」とだけ頼むと、何をどう変えたかが記録に残らないことがあります。頼むときは、観測票や受付の記録のどの行を見てほしいかを、受付IDや観測IDで伝えます。
届いた相談に誰が返信し、未完了の相談をどう引き継ぐかは、問い合わせの返信漏れを防ぐ管理手順|担当・期限・引き継ぎを20項目で点検で扱っています。この記事の「引継ぎ済」は、そちらの手順へ渡した時点を指します。
再現票と、許可された試験の準備
誤判定の疑いや、通知が届かない疑いを確かめるには、同じ条件で再現を試す必要があります。ただし、試験の送信を実際の相談と混ぜない、本物の個人の情報を使わない、社外のサービスへ送らない、の3つを守ります。
試験の前に決めること
- 試験の許可:誰が許可し、どの期間に何回まで送ってよいか
- 試験の印:件名や本文の決まった位置に入れる印(例:「試験・10月24日・観測ID T-01」)
- 架空の値:氏名・電話番号・メールアドレスに使う、実在しない試験用の値。メールアドレスは自社が管理している試験用の受信箱だけを使う
- 受け取る人:試験の送信が届いたら、誰が受付の記録と受信箱を確かめるか
- 後始末:試験の送信を業務の集計から外す方法と、記録を残す期間
【編集部の提案】外部の人の受信箱や、契約していないサービスへ試験の送信を出してはいけません。試験の結果、迷惑と判定された記録が残っても、それは試験の印で外せるようにしておきます。
| 欄 | 書くこと |
|---|---|
| 観測ID | 試験ごとに付ける番号(例:T-01) |
| 日時と担当 | 送った日時、送った人、確かめた人 |
| 環境 | 端末の種類、画面の大きさ、回線の種類 |
| 操作 | 入力した内容の長さ、戻る・再試行などの操作 |
| 地点A | 画面に出た文言(そのまま写す) |
| 地点B | 受付の記録にあるか、受付ID |
| 地点C | 通知が届いたか、届いた場所 |
| 地点D | 誰が開いたか、判定の軸 |
| 版 | 試験したときの判定の仕組みの版 |
見えなかった地点は「未確認」と書き、確かめなかった理由を添えます。
試験の回数と時間帯
【編集部の提案】試験は、1回の見直しで観点ごとに1〜2回を目安にし、必要以上に送りません。試験の送信が多いと、受付の担当の手間が増え、集計から外す作業も増えます。時間帯は、受付の担当がすぐに確かめられる業務の時間にします。夜間や休日に送ると、通知が届いたかを確かめる人がいないため、地点Cと地点Dを確かめられません。
試験の観点:PC・スマホ・長文・戻る・再試行・障害
再現の試験は、思いつくまま送るのではなく、観点を決めて1つずつ行います。正規の相談が止まりやすいのは、問い合わせる人が普段どおりに操作したのに、仕組みの想定から外れたときです。
| 観点 | 試すこと | 確かめる地点 |
|---|---|---|
| パソコン | 普段使われる画面の大きさで、最後まで送る | A〜D |
| スマホ | 縦の画面で、文字の入力と送信を押す操作 | A〜D |
| 長い本文 | 相談の経緯を長めに書いた本文を送る | A・B(本文が切れていないか) |
| 戻る | 確認の画面から戻って直し、もう一度送る | A・B(受付が1件か2件か) |
| 時間をおく | 途中で時間をおいてから送る | A(画面の文言) |
| 再試行 | 止まった後にもう一度送る | A・B(重複の印) |
| 回線の切り替え | 送信の直前に回線が切り替わる状況 | A(画面の文言) |
| 通知の障害 | 許可された試験の環境や試験専用の宛先で、通知が届かない状況を再現する | B・C |
時間をおく試験と再試行
表の2つの観点は、どちらも正規の相談でよく起きる操作です。仕組みに固有の条件は第3節の2つの要約を参照し、ここでは「画面に何が出たか」と「受付に何件残ったか」だけを記録します。画面の文言がない、または「もう一度お試しください」とだけ出て、どうすればよいか分からない場合は、問い合わせる人が途中でやめる原因になります。
重複と再試行の印
【編集部の提案】同じ人が続けて送ったように見える受付が2件あっても、片方を消さずに両方の受付IDを残し、「重複の疑い」の印を付けます。印を付けるのは、本文や送られた時刻が近いなど、記録から見える範囲だけです。同じ人かどうかを確かめるために、個人ごとの行動を追ったり、別の記録と照らし合わせたりはしません。数えるときは、受付の件数と、印のない受付だけを数えた補助の件数を並べます。印の付いた行をすべて除いた数なので、重複を1件にまとめた数ではありません。
試験の結果の書き方
結果は「通った」「止まった」の一言で終えず、地点ごとに書きます。たとえば、スマホで確認の画面から戻って送った試験なら、「地点A:完了の画面が出た。地点B:受付IDが2件(R-2001・R-2002)。地点C:通知は2通。地点D:受付の担当が2件とも開いた」のように書きます。この結果からは、戻る操作で受付が二重になることが分かり、重複の印の付け方を決める材料になります。止まった試験も同じように、どの地点まで確かめられたかを書きます。
障害を試すときの注意
実際の相談の通知の宛先を止める、本番の仕組みを止める、外部へ実際に送る、といった試験は、この手順の対象外です。通知が届かない状況は、責任者が許可した試験の環境や試験専用の宛先で再現し、第10節の決まりの範囲で確かめます。試験の環境を変えた場合も、元へ戻した人と日時を記録します。
一度に一つだけ変え、反映と証拠を残し、止める条件を決める
判定の仕組みの設定を見直すときは、変えるものを一度に一つにします。判定の厳しさと通知の宛先を同じ日に変えると、正規の受付が減ったときに、どちらの影響かが分かりません。
変更票
【編集部の提案】1回の変更ごとに、変更票を1枚書きます。
| 欄 | 書くこと |
|---|---|
| 変更の番号と版 | 変更前の版と、変更後の版の名前 |
| 変える理由 | 観測票や再現票のどの記録が根拠か |
| 変える内容 | 何をどう変えるか(鍵や秘密の値は書かない) |
| 依頼した人・承認した人 | 名前と日時 |
| 変えた人と反映の日時 | 実際に設定を変えた人と、反映された日時 |
| 反映の観測 | 試験で反映を確かめた人・日時・結果(原則は別の人。1人のときは第9節) |
| 止める条件 | どうなったら元の版へ戻すか |
| 振り返りの日 | 7日後と28日後の日付と、見る人 |
版の名前の付け方
版の名前は、番号と日付を組み合わせた短いものにします(例:版2・10月24日)。「厳しめ」「新しい設定」のような言葉だけの名前は、次の変更で意味が変わってしまいます。版の中身は変更票の「変える内容」の欄に書き、名前には中身を入れません。
変更票の記入例
| 欄 | 記入 |
|---|---|
| 変更の番号と版 | 変更3。版1から版2・10月24日へ |
| 変える理由 | 版1(判定で止まった送信は拒否され、記録に残らない)の期間に、電話で「フォームから送れなかった」という報告が2件(観測ID M-02・M-03)。誤判定かどうかは断定できていない |
| 変える内容 | 責任者が許可した範囲で、判定で止まった送信を拒否せず保留の置き場所へ入れる扱いに変える(この扱いを選べるかは仕組みによって違う) |
| 依頼した人・承認した人 | 受付の担当が10月22日に依頼、責任者が10月23日に承認 |
| 変えた人と反映の日時 | 設定の担当が10月24日10時に変更 |
| 反映の観測 | 受付の担当が10月24日14時に試験の観測ID T-05で確かめた |
| 止める条件 | 正規の相談が送れないという報告が1件でも届いたら版1へ戻す |
| 振り返りの日 | 11月1日と11月22日、受付の担当と責任者 |
この例では、反映を確かめた10月24日の翌日、10月25日から数えます。7日間は10月31日まで、28日間は11月21日までで、振り返りはそれぞれ期間が終わった翌日に行います。10月24日は境目の日として、どちらの期間にも入れません。
反映と観測を分ける
「設定を変えた」と「変更が効いている」は別のことです。設定の担当が保存した日時と、試験で反映を確かめた日時を、別の欄に書きます。確かめるのは原則として別の人で、1人のときは第9節の扱いにします。反映を確かめていない期間の件数は、変更前・変更後のどちらにも入れず、境目の期間として分けておきます。
止める条件
変更の前に、どうなったら元の版へ戻すかを決めます。たとえば「正規の相談が送れないという報告が、確かな経路で1件でも届いた」「試験の送信が受付まで届かなかった」などです。件数の割合で決める場合も、少ない件数で判断しないよう、何件以上を見てから判断するかを一緒に書きます。条件に当たったら、原因が分かる前でも、責任者の判断で元の版へ戻します。
判定保留・担当不在・確認できないときと、別の相談の経路
見直しの途中では、決めきれない送信、担当がいない日、記録を確かめられない状況が必ず出てきます。そのときの扱いを先に決めておくと、迷惑か正規かを急いで決める必要がなくなります。
判定保留を置いておける期間
判定保留の送信は、誰がいつまでに見直すかを書きます。期限を過ぎても決まらない場合は、責任者が判断します。判定保留のまま返信が遅れると、正規の相談だった場合に相手を待たせることになるため、保留の中に具体的な相談らしい内容があれば、判定より先に返信の担当へ渡すことも考えます。
担当が不在のとき
受付の担当が休みの日に、誰が保留の置き場所と通知を見るかを決めておきます。見る人がいない日は、その日の送信を「未確認」として残し、翌営業日に最初に確かめます。不在の間の件数を、後で0件と書き換えないでください。
長い休業や繁忙期の前に
年末年始などの長い休業の前には、休業中に届いた送信を誰がいつ確かめるかを決めておきます。休業中は判定の仕組みの設定を変えないことも、決まりの1つにできます。変えた直後に何か起きても、確かめる人がいないためです。繁忙期も同じで、確認の手が足りない時期に見直しを重ねないようにします。
記録を確かめられないとき
仕組みの管理の画面に入れない、記録の期間が過ぎて消えた、など、確かめられない状況もあります。そのときは「確認不能」とその理由を観測票に書き、推測で件数を埋めません。
別の相談の経路を案内する
【編集部の提案】フォームが止まっている疑いがあるときに備えて、フォームの近くや完了の画面に、別の相談の経路を載せておきます。載せるのは、実際に受ける人が決まっている電話番号やメールアドレスだけにします。受ける人がいない窓口や、返事の時期を約束できない窓口は載せません。案内を変えたら、変更票と同じように、変えた人と日時を残します。
復旧の判断と、過去の送信の扱い
止める条件に当たって元の版へ戻した後、または通知の障害が直った後には、止まっていた間の送信をどう扱うかを決める必要があります。ここは、現場の担当が1人で決めないことが大切です。
復旧したと言える条件
【編集部の提案】復旧は、設定を戻したことではなく、試験の送信が地点Dまで届いたことを確かめた時点とします。確かめるのは原則として別の人で、1人のときは第9節の扱いにします。確かめた人と日時を変更票に書き、それまでの期間は「影響があったかもしれない期間」として残します。
過去の送信の扱い
止まっていた間に保留の置き場所に入った送信や、通知が届かなかった受付をどう扱うかは、責任者が決めます。担当がその場で、まとめて再送したり、迷惑として消したりしないでください。再送すると同じ相談が二重に届き、消すと後から確かめられなくなります。
| 状況 | 現場の担当がすること | 責任者が決めること |
|---|---|---|
| 保留の置き場所に残っている | 件数と期間を書き、中身を人が読み、判定の軸を書く | 正規のものへの連絡の要否と順番 |
| 受付はあるが通知が届いていない | 受付IDの一覧を作る | 誰がいつ返信するか |
| 記録に残っていない | 観測票に「件数不明」と書く | 案内の掲示の要否 |
| 消してよいか分からない | 消さずに残す | 残す期間と、消す判断 |
返信が大きく遅れた相手への連絡の文面や、連絡するかどうかは、相談の内容や事業によって違います。決めた内容と、決めた人・日時を記録に残してください。
復旧の後に振り返ること
【編集部の提案】復旧した後は、影響があったかもしれない期間の始まりと終わり、その間の受付の件数と観測票の件数、責任者が決めた過去の送信の扱いを、1枚にまとめます。同じことが次に起きたとき、どの手がかりで気付けたか、気付くまでに何日かかったかが分かれば、止める条件や見る頻度を直す材料になります。誰の作業が原因だったかを責める記録にはしません。
架空の4つの事業で見る見直しの進め方
ここまでの手順を、4つの架空の事業に当てはめてみます。件数や日付はすべて説明のための仮の値で、実在の事業の数字や業種の平均ではありません。
| 事業 | 気付いたこと | 最初に確かめたこと | 決めたこと |
|---|---|---|---|
| 地域の印刷会社 | 売り込みの送信が増え、担当が相談を見落としかけた | 受付の記録と通知の件数が合っているか | 通知の件名に決まった語を入れ、経路を分けて数える |
| 小さな設計事務所 | 判定を厳しくした後、相談が来なくなった気がする | 基準の版と比べる期間がそろっているか | 判断を保留し、28日間を待ってから比べる |
| 自動車の整備工場 | 電話で「フォームが送れない」と2回言われた | 同じ端末の種類で再現するか | 観測票に書き、許可を取って試験を行う |
| 料理教室 | 社外の担当が設定を変えたが、中身が分からない | 変更票があるか、版の名前があるか | 変更票を作り直し、承認の欄を足す |
例から分かること
4つの事業で共通しているのは、最初に設定を変えずに、記録と地点を確かめている点です。印刷会社は、迷惑な送信が増えたこと自体より、経路が混ざって数えられないことを先に直しました。設計事務所は、相談が来ない理由を急いで決めず、期間をそろえることを優先しました。
整備工場の例では、2回の報告だけで「仕組みの誤判定」と決めず、再現の試験を待っています。2回とも同じ端末の種類だったという手がかりは、試験の観点を絞る助けになります。料理教室の例は、設定の中身を知らないこと自体を問題と捉え、変更票と承認の欄を作り直した例です。
事業によって変わること
相談の件数が少ない事業ほど、1件の誤判定の重みが大きくなります。月に数件しか相談がない事業では、7日間の比較で判断するのは早すぎることが多く、28日間でも判断を保留する場合があります。反対に、売り込みの送信が多い事業では、担当の確認の手間が見直しの理由になることもあります。どちらの場合も、正規の受付・誤判定の疑い・不明を分けて記録する点は変わりません。
受付ID・試行と重複・判定の軸・業務の状態の票
記録は、受付の記録に残った送信の票と、受付の記録に残らなかった試みの観測票の2つに分けます。同じ表に混ぜると、ID のない行の件数を数えようとして、数字を作ってしまうためです。
受付・判定の票
【編集部の提案】受付の記録に残った送信は、受付IDで1行にします。1行は1回の送信の試みで、個人ではありません。
| 欄 | 書くこと | 空欄のときの扱い |
|---|---|---|
| 受付ID | 受付の記録が付けた番号 | この票には書かない(観測票へ) |
| 受け付けた日時 | 受付の記録の日時 | 未取得 |
| 経路 | フォーム・直接のメール・経路不明 | 経路不明 |
| 版 | そのときの判定の仕組みの版 | 未取得 |
| 仕組みの扱い | 受付・保留・印付きなど | 未取得 |
| 再試行・重複 | 重複の疑いがあれば、もう一方の受付ID | 印なし |
| 通知 | 通知を確かめた日時と場所 | 未確認 |
| 判定の軸 | 正規・迷惑・判定保留 | 未判定 |
| 業務の状態 | 未確認・確認中・対応決定・引継ぎ済 | 未確認 |
| 次の担当と確認日 | 次に見る人と日付 | 責任者が決める |
観測票
受付の記録に残っていない試みは、観測票に書きます。本人からの報告や試験の結果がこれに当たります。観測票の行には受付IDがないため、観測IDを付けます。
観測票の件数は「報告や試験で分かった数」であって、止まった試みの総数ではありません。集計の表に並べるときも、受付の件数とは別の行にし、「件数不明」の注記を付けます。
票の記入例
| 受付ID | 経路と版 | 再試行・重複 | 判定の軸 | 業務の状態 |
|---|---|---|---|---|
| R-1031 | フォーム・版2 | 印なし | 正規 | 引継ぎ済 |
| R-1032 | フォーム・版2 | R-1033と重複の疑い | 判定保留 | 確認中 |
| R-1033 | フォーム・版2 | R-1032と重複の疑い | 判定保留 | 確認中 |
| R-1034 | 経路不明・版2 | 印なし | 未判定 | 未確認 |
R-1032とR-1033は、本文と時刻が近いため重複の疑いの印を付けていますが、どちらも消していません。R-1034は経路が分からないため、経路不明として残しています。判定の軸が決まっていないので、迷惑にも正規にも数えません。
3つの区分を混ぜない
業務の状態、判定の軸、有効な相談かどうかは、それぞれ別の時点・別の人の判断です。「引継ぎ済だから正規」「正規だから有効な相談」とは限りません。正規と判定した相談でも、対象外の地域だった、すでに解決していた、などで有効な相談に数えないことがあります。有効な相談かどうかの判断は、第18節で案内する記事の手順に任せ、この票には書きません。
同じ条件で7日間・28日間を比べる:分母と未取得
変更の後は、同じ条件で期間を区切って比べます。この記事では、反映を確かめた日の翌日から数えて7日間と28日間を見ることを提案します。28日間は7日間を含む累計で、7日間の後に別の28日間を足すのではありません。
比べる前にそろえること
- 期間の長さ:変更後の7日間は変更前の7日間と、変更後の28日間は変更前の28日間と比べる。7日間の件数を4倍して28日間と比べない
- 条件:曜日の並び、経路、版、試験の送信の除外をそろえる
- 分母:受付IDのある行だけを数える。観測票の件数は分母に入れない
- 境目:反映を確かめていない期間は、どちらにも入れない
- 経路:フォームと直接のメールを分ける
- 未取得:判定の軸が空欄の行は「未判定」として残す
集計の例
次の表は、架空の事業で、判定の仕組みを版1から版2へ変えた場合の仮の値です。受付IDのある行だけを、判定の軸ごとに数えています。この例では変更前の7日間を別に集計しておらず未取得のため、変更後7日間の列は件数の確かめだけに使い、変更前の28日間とは比べません。比べるのは同じ長さの28日間どうしです。
| 判定の軸 | 版1・変更前28日間 | 版2・変更後7日間 | 版2・変更後28日間 |
|---|---|---|---|
| 正規 | 13 | 4 | 14 |
| 迷惑 | 118 | 15 | 70 |
| 判定保留 | 4 | 2 | 5 |
| 未判定 | 5 | 2 | 7 |
| 受付の合計 | 140 | 23 | 96 |
同じ版2の28日間について、受付の後の地点と、受付の記録に残らない報告を別に数えます。
| 区分 | 件数 |
|---|---|
| 通知を確かめた受付 | 90 |
| 通知を確かめられない受付 | 6 |
| 受付の合計 | 96 |
このほか、同じ28日間に「フォームから送れなかった」という報告が2件、観測票にあります。これは本人が知らせてくれた数で、受付の前で止まった試みの総数ではなく、総数の推計にも使いません。重複の疑いの印が付いた受付は2件で、印のない受付だけを数えた補助の集計は94件です。94件は印の付いた2件をどちらも除いた数で、重複を1件にまとめた数ではありません。
この例の読み方
【編集部の提案】迷惑と判定した受付は118件から70件に減っています。ただし、これだけで「見直しは成功した」とは言えません。同じ長さの28日間どうしで比べると、正規の受付は13件と14件でほぼ変わらず、件数が少ないため、正規の相談が止まっていないとも、増えたとも判断できません。未判定は5件から7件に増えており、担当の確認が追い付いていない可能性があります。通知を確かめられない受付が6件あり、観測票には送れなかったという報告が2件あります。
この例での判断は、「迷惑な送信の受付は減ったが、誤判定の有無は判断を保留する。通知の6件と報告の2件を先に確かめる」となります。件数が少ない事業では、28日間でも判断を保留して構いません。
計測の数字との照合
アクセス解析の計測で数えた送信の件数と、受付の記録の件数は、計測の仕組みが違うため一致しないことがあります。両者を照らし合わせる手順は、GA4の問い合わせコンバージョンが受付件数と合わないときに確かめる順番で扱っています。この記事の集計では、受付の記録を基準にし、計測の数字は参考の列として別に並べます。
有効な相談の判断と、サイトや運用の改善は既刊の記事へ
迷惑な送信への対策の見直しは、「正規の相談が地点Dまで届いているか」を確かめるところまでです。届いた相談が、事業として受けられる有効な相談かどうかは、別の判断になります。
有効な相談かどうかは別の記録で
正規と判定した相談の中にも、対象外のサービスへの質問や、すでに解決した問い合わせが含まれます。どれを有効な相談として数えるかの決め方は、事業の担当と責任者が決めることで、迷惑な送信への対策の担当が決めることではありません。有効・対象外・未判定を分けて数える手順は、広告の問い合わせの質が低いとき|有効・対象外・未判定を分ける手順で扱っています。広告から来た相談でなくても、区分の考え方は参考になります。
見直しの後に出てきた課題の行き先
見直しを進めると、迷惑な送信とは関係のない課題が見つかることがあります。
- 入力の途中でやめる人が多そう、エラーの文言が分かりにくい:第2節で紹介した既刊のフォームの改善の記事の点検表へ
- 届いた相談への返信が遅れる、担当の交代で止まる:第9節で紹介した返信管理の記事へ
- 計測の件数と受付の件数が合わない:第17節で紹介した計測の記事へ
見直しを一区切りにする条件
見直しは、続けようと思えばいつまでも続けられます。【編集部の提案】次の3つがそろったら、一区切りとして責任者に報告し、次の振り返りの日だけを決めておきます。1つ目は、28日間の振り返りで止める条件に当たらなかったこと。2つ目は、観測票の報告と通知を確かめられない受付について、止まった地点と扱いが決まったこと。3つ目は、判定保留と未判定が、決めた期限の中で人に読まれていることです。迷惑な送信の件数が目標まで減ったかどうかは、区切りの条件に入れません。
【編集部の提案】これらの課題を、迷惑な送信への対策の変更票に混ぜないでください。一度に一つだけ変えるという決まりが崩れ、どの変更の効果かが分からなくなります。別の課題として書き出し、担当と期限を決めて、それぞれの手順で進めます。
登録なしで使える20項目の点検表と、空欄の2つの票
ここまでの内容を、20項目の点検表にまとめます。登録や入力の送信は要りません。印刷するか、表計算のシートに写して使ってください。当てはまらない番号から、右の列の次の一手を進めます。
| 番号 | 確かめること | 確かめ方 | 当てはまらないときの次の一手 |
|---|---|---|---|
| 1 | 1件を1回の送信の試みとし、個人ごとに追っていない | 票の1行の単位を見る | 受付IDで1行にする |
| 2 | フォームと直接のメールを分けて数えている | 経路の欄を見る | 経路不明の列を作る |
| 3 | 送信の試み・受付・通知・人の確認の4つの地点を分けた | 棚卸しの1枚を見る | 地点ごとに確かめる場所を書く |
| 4 | 判定で止まった送信の行き先が分かる | 棚卸しを見る | 不明と書き、調べる人を決める |
| 5 | 基準の版と対象期間を書いた | 基準の表を見る | 版の名前と期間を書く |
| 6 | 見えない地点と、その理由を書いた | 基準の表を見る | 未取得の理由を書く |
| 7 | 自動の判定と人の確認を別の欄にしている | 票の欄を見る | 仕組みの扱いの欄を足す |
| 8 | 判定の軸と業務の状態を別の欄にしている | 票の欄を見る | 2つの欄に分ける |
| 9 | 仕組みが止めたものを迷惑と確定していない | 集計の表を見る | 人が読むまで判定の軸を空欄にする |
| 10 | 誤判定を疑う手がかりを決めている | 手がかりの表を見る | 報告の受け方を決める |
| 11 | 設定を変えられる人と承認する人が決まっている | 役割の表を見る | 責任者を決める |
| 12 | 権限と鍵を持つ人の一覧がある | 一覧を見る | 責任者が一覧を作る |
| 13 | 試験の許可・印・架空の値を決めた | 再現票を見る | 許可を取り、印を決める |
| 14 | PC・スマホ・戻る・再試行などの観点で試した | 再現票を見る | 観点を1つ選んで試す |
| 15 | 重複の疑いを消さずに印で残している | 票を見る | 両方の受付IDを残す |
| 16 | 一度に一つだけ変え、変更票を書いた | 変更票を見る | 変更を分ける |
| 17 | 反映の観測と止める条件を書いた | 変更票を見る | 観測した人(1人のときはその旨)と条件を書く |
| 18 | 担当の不在と確認不能のときの扱いを決めた | 決まりを見る | 見る人と記録の書き方を決める |
| 19 | 実際に受ける人がいる別の相談の経路を載せている | フォームの近くを見る | 受ける人を決めてから載せる |
| 20 | 同じ条件で7日間・28日間を比べ、未取得を0にしていない | 集計の表を見る | 期間と分母をそろえ直す |
点検表の使い方
【編集部の提案】最初は、受付の担当と設定の担当の2人で、1から20まで一通り確かめます。当てはまらない番号が多いときは、3・6・8・16の順に直します。地点と見えない範囲、判定の軸と業務の状態、変更票の3つがそろえば、残りの番号は見直しを進めながら直していけます。
空欄の受付・判定の票
受付IDのある送信を1行ずつ書く票です。1行目の「受付ID」の欄から書き始めます。判定の軸が決まらないときは空欄にせず「未判定」と書きます。
| 受付ID | 日時・経路・版 | 通知 | 判定の軸 | 業務の状態 | 次の担当と確認日 |
|---|---|---|---|---|---|
| 受付ID:__ | 日時:__ 経路:__ 版:__ | __ | __ | __ | __ |
| 受付ID:__ | 日時:__ 経路:__ 版:__ | __ | __ | __ | __ |
| 受付ID:__ | 日時:__ 経路:__ 版:__ | __ | __ | __ | __ |
空欄の変更票・観測票
1回の変更と、受付の記録に残らない試みの観測をまとめる票です。鍵や秘密の値、問い合わせた人の個人の情報は書かないでください。
| 欄 | 書くこと | 記入 |
|---|---|---|
| 変更の番号:__ | 変更前の版と変更後の版 | __ |
| 変える理由 | 根拠にした観測IDや受付ID | __ |
| 承認した人と日時 | 責任者の名前と日時 | __ |
| 反映と観測 | 変えた人と日時、確かめた人と日時(同じ人ならその旨) | __ |
| 止める条件 | 元の版へ戻す条件 | __ |
| 観測ID:__ | 報告や試験の日時、環境、画面の文言 | __ |
| 観測で見えた地点 | A〜Dのどこまで確かめたか、件数不明の注記 | __ |
| 振り返りの日 | 7日後・28日後の日付と見る人 | __ |
問い合わせの受付と確認の担当を整理したいとき
Akatsukiのホームページ制作では、見学・相談へ進みやすい入口を、問い合わせまでの導線から設計します。
よくある質問と、今日1つ見直すこと
迷惑な送信が減れば、見直しは成功ですか
それだけでは判断できません。正規の受付・誤判定の疑い・不明を分けて並べ、正規の相談が地点Dまで届いているかを確かめてから判断します。件数が少なければ、判断を保留して構いません。
判定を厳しくしたら、相談が減った気がします
まず、比べる期間の長さと分母がそろっているかを確かめます。そのうえで、止める条件に当たっているかを見ます。当たっていれば、原因が分かる前でも、責任者の判断で元の版へ戻します。
仕組みが拒否した送信の中身を見たいのですが
拒否された試みが記録に残るかどうかは、仕組みや設定によって違います。残らない場合は、件数も中身も分からないものとして観測票に「件数不明」と書きます。記録を残すための設定の変更は、変更票を書いて責任者の承認を取ってから行います。
社外の担当が設定を変えてくれました。何を受け取ればよいですか
変更票の欄、つまり変更前と変更後の版、変えた内容の要点、反映の日時、止める条件を受け取ります。鍵や秘密の値は受け取る必要がありません。反映の観測は、社外の担当とは別の人が試験で確かめます。
試験の送信が迷惑と判定されました
試験の印を付けていれば、集計から外せます。試験の送信が迷惑と判定されたことは、正規の相談も同じように止まるかもしれない手がかりの1つとして、再現票に残します。架空の値の書き方を変えて試す場合も、本物の個人の情報は使いません。
通知が迷惑メールのフォルダーに入っていました
それはフォームの判定ではなく、受信の側の振り分けで止まった例です。地点Bには届き、地点Cで見えなくなっています。受付IDの一覧と照らし合わせ、見落とした受付がないかを先に確かめます。振り分けの設定はフォームの見直しとは別の変更として、別の変更票に書きます。
保留の置き場所を毎日見る時間がありません
見る頻度を決め、その頻度で見ていることを記録します。毎日でなくても、決めた曜日に見ていれば、未確認の期間がどれだけあったかが分かります。保留の件数が増え続けるようなら、判定の決まりを見直す手がかりになります。
小さな会社で、担当が1人しかいません
すべての欄を毎日埋める必要はありません。まず、受付IDのある行の判定の軸と業務の状態だけを書き、変更をするときだけ変更票を書きます。承認と観測は、時間を空けて自分で見直す形でも構いません。
今日1つ見直すこと
【編集部の提案】今日は、第5節の棚卸しの1枚だけを書いてください。判定で止まった送信がどこへ行くのか、受付の記録がどこにあり誰が見られるのかが分かれば、次に確かめることが決まります。分からない項目は「不明」と書き、誰がいつ調べるかを決めるところまでで十分です。
迷惑な送信への対策は、一度決めれば終わりではなく、送られ方や事業の変化に合わせて見直しが続きます。そのたびに、地点と判定と状態を分けて記録しておけば、担当が替わっても同じ条件で比べられます。問い合わせの導線全体の見直しは、ガイドの問い合わせを増やすWeb改善ガイドにもまとめています。
今日やること
- 判定で止まった送信がどこへ行くか、受付の記録がどこにあり誰が見られるか、通知の宛先と担当が見ているものを1枚に書き出し、分からない項目は「不明」と書く
- 受付IDのある送信を1行ずつにして、判定の軸(正規・迷惑・判定保留)と業務の状態(未確認・確認中・対応決定・引継ぎ済)を別の欄に書く
- 設定を変えるときは一度に一つにして変更票を書き、反映を試験で確かめた日(確かめるのは原則として別の人。1人のときはその旨を書く)の翌日から7日間・28日間の振り返りの日を決める
出典・編集方針
- この記事の4つの地点の分け方、判定の軸と業務の状態の名前、受付・判定の票と観測票、変更票、再現票、試験の観点、止める条件の決め方、7日間・28日間の比べ方、20項目の点検表と空欄の票は、Akatsuki編集部の実務提案です。特定の会社で効果を測った結果ではなく、迷惑な送信を確実に止めることや、誤判定がなくなることを約束するものではありません。
- 4つの事業(地域の印刷会社、小さな設計事務所、自動車の整備工場、料理教室)の例、受付IDや観測ID、日付・件数、記入例は、説明のために作った架空の例と仮の値です。実在の会社の事例や数字ではなく、業種の平均でもありません。
- 冒頭の画像は生成AIで作成したイメージで、実在の会社の画面や記録ではありません。本文中の図版3点は、Akatsuki編集部が文字と図形で作成した説明図です。
- 本文の出典番号は下の一次情報に対応し、確認日と最終更新日は出典欄に記載しています。
- プログラムの書き方、製品の比較や料金、法令への適合の判断は扱っていません。
一次情報(外部サイト)
- 出典1:reCAPTCHAの評価(Google Cloud)(外部サイト)原題 Interpret assessments for websites(短く表示)。公開日の記載なし、最終更新2026年10月23日(UTC)、2026年10月24日確認
- 出典2:Validate the token(Cloudflare)(外部サイト)公開日の記載なし、最終更新2026年10月22日、2026年10月24日確認
記事の作り方と訂正の方針は編集方針にまとめています。
次に読む
関連する支援:ホームページ制作
制作の内容と進め方は、ホームページ制作のページで説明しています。