Salesforce の資料請求フォーム、失敗しても「受け付けました」と出る

11月11日の会議で、自分は「全部 pass」と言った。資料請求フォームから届く案内メールが、「本当にその会社から来たメールか」の確認（3種類ある）を全部通っている、という意味だ。会議のあとで見直すと、その pass は本番とは違う差出人での結果だった。案内メールは会社のアドレスではなく、Salesforce が代わりに使う仮のアドレスから届いていた。会社のアドレスから送って通るかは、まだ誰も試していない。

ある会社（約90名）のサイトのリニューアルで、資料請求のフォームを作り直している。入力された内容は Salesforce（営業が商談を管理しているサービス）に「リード」（見込み客の記録）として入る。請求した人には資料のダウンロード案内が、営業には通知が自動で届く。Salesforce の側は標準機能だけで、プログラムは書いていない（フォームの画面は HTML で作った）。会議ではこれを試験環境で動かして見せ、営業の側の責任者からは「必要な機能は満たしている」と言われた。

同じ日に、もう1つ自分の記録を訂正した。形式が不正なメールアドレスでは「リードは作られない」と書いていたが、作られていた。2つの訂正から言えることは1つだ。「テストは通った」と聞いたら、何で試したか・失敗の側を試したか・失敗したら誰が気づくかの3つを聞き返す。自分の報告にも同じことを聞く。本番の設定はまだ変えていない。事実は2026年11月11日の時点のもので、設定の名前は後半の「担当者向け」にまとめた。

▼何が起きたか：会議で「全部 pass」と言った。届いたメールの差出人は、会社のアドレスではなかった

メールには、受け取る側が「このメールは本当にその会社から来たか」を確かめる仕組みがある（送信ドメイン認証。3種類ある）。これが通らないと、迷惑メールのフォルダに入りやすくなる。資料請求の案内メールが迷惑メールに入れば、請求した人は「資料が来ない」と思うだけで、たいていは問い合わせもしてこない。

会議では、試験で届いた案内メールについて、この確認が3種類とも pass だと言った。会議の準備メモにも、差出人は会社のアドレスだと書いていた。

実際は違った。試験環境（本番のデータに触れずに試すための、本番とは別の Salesforce）から届いた案内メールの差出人は、会社のアドレスではなく、Salesforce が代わりに使う仮のアドレスだった。pass は「その仮のアドレスから正しく送られた」という意味で、「会社のアドレスから正しく送られた」という意味ではない。

気づきにくい理由もあった。差出人の表示名は、会社名のままだった。Salesforce は仮のアドレスに切り替えても、表示名と返信先はそのまま残す（Salesforce の説明。担当者向けで補足）。受信箱の一覧では、いつもの会社からのメールに見える。アドレスの欄まで開かないと分からない。

なぜ仮のアドレスになったか。会社のアドレスで送るには、Salesforce の側で「このドメイン（メールアドレスの @ より後ろ）はこの会社のもの」と確かめる準備（ドメインの確認と、メールに付ける署名の鍵）が要る。本番ではこの準備が済んでいるが、試験環境には署名の鍵がなかった。Salesforce には、確かめられていないアドレスの代わりに仮のアドレスで送る設定があり、最初からオンになっている。だからメールは止まらずに届き、エラーも出ない。

では本番は大丈夫か。本番の Salesforce は会社のドメインの確認と署名の鍵が済んでいるので、会社のアドレスで送られ、確認も通る見込みだ。ただし、本番から実際に送って確かめるのはまだだ。

自分の誤りは、その pass が「どのアドレスについての結果か」を見ないまま、pass という文字だけで言ったことだ。会議のあとに作った資料でも、差出人の行を「未確認（本番のテストで確認）」に書き直した。

▼原因：試験環境は本番の複製ではない。黙って違っていたのが4つ、1つは本番に持ち越す

試験環境は本番の設定を写したものだが、メールと安全のための初期値は本番と違う。今回は4つ違っていた。どれも「止まる」か「別の形で動く」だけで、試験環境はエラーとは言ってこなかった。

違い	試験環境で起きたこと	本番では
1. 案内メールの差出人	前の節のとおり。仮のアドレスで届いた	会社のアドレスで送る準備は済んでいる（送って確かめるのはまだ）
2. ロボット確認（「私はロボットではありません」のチェック）	新しく作った試験環境では、最初から「必須」になっていた。確認の鍵がないまま送ると、リードは作られないのに、返事は成功と同じだった。試験のため、試験環境だけオフにした	今はオフ。公開前にオンにする
3. メールを送る範囲	初期値は「仕組みが出すメール（パスワードの再設定など）だけ」。「すべてのメール」に変えて送り直したら、資料の案内メールが届いた（11月9日）	「すべてのメール」
4. 社員のメールアドレス	試験環境を作ると、社員のアドレスは届かない形に書き換わる。フォームから入るリードの「作成者」が前任者のままで、そのアドレスが届かない形だったため、営業への通知が最初の4件とも届かなかった。作成者を自分に変えたら届いた（11月10日）	作成者は前任者のまま

2と3は、試験環境の初期値が本番と違ったという話だ。どちらも何も言わずに止まった。

4だけは、試験環境の中の話で終わらない。営業への通知は、リードの作成者を差出人にして届く。試験環境でも、作成者を自分に変えたあとは、通知の差出人が自分の名前になった。そして本番の作成者も、前任者のまま残っている。変えなければ、公開後の営業への通知は、前任者を差出人にして出ることになる。本番で前任者のアカウントから通知が届くかは、まだ試していない。前任者の設定が、誰にも気づかれないまま仕組みの真ん中に残っていた形だ。作成者を誰にするかは、会社に決めてもらう項目に入れた。

4つとも、試験環境は何も言ってこない。だから「届いた」「通った」という報告には、どの環境で、どの差出人・どの作成者で試したかが一緒に要る。

▼もう1つの訂正：失敗の側を試したら、「作られない」と書いたものが作られていた

会議では、正常に動く場合だけでなく、エラーのときにどうなるかも資料にしてほしいと言われた。そこで会議のあと、わざと不正な内容を試験環境に直接送る試験をした。

最初の記録には「形式が不正なメールアドレスでは、リードは作られない」と書いた。確かめ直すと、リードは作られていた。営業への通知も届いた。届け先がないので、請求した人への案内メールだけが届かない。

つまり、メールアドレスの形式を確かめているのは、利用者の画面（ブラウザ）の側だけで、Salesforce の側は確かめていなかった。ふつうに入力する人は、画面で止まる。画面を通らずに直接送られたもの（いたずらや、プログラムからの送信）は、今の本番の設定（ロボット確認がオフ）ならそのままリードになる。ロボット確認を必須にすれば、確認を通っていない直接の送信はリードにならない。鍵がないとリードが作られないことは、試験環境で確かめた。

同じ試験で分かったことは、ほかに4つある。

• ▶ 会社名・氏名が空でも作られる：「[未指定]」と入ったリードができる
• ▶ 長すぎる名前は切り詰めて入る：120文字で送ると、80文字で作られた
• ▶ 送り先の設定が違うと、何も作られない：フォームに書く「どの会社の Salesforce か」の番号を変えて送ると、リードも通知も何も出なかった
• ▶ 資料名を書き換えて送ると、案内メールは出ない：リードはできる。案内メールのリンクは Salesforce の側に固定してあり、決まった資料名と一致しないと送らない作りにした

成功の側だけを試していたら、「何が止まるか」は思い込みのまま残っていた。自分の「作られない」がそれだった。失敗の側を試して初めて、守っているのが画面だけだと分かった。

▼一番の注意：Salesforce の側で失敗しても「受け付けました」と出る。13通りのうち3つは誰も気づかない

このフォームは、Salesforce の側で失敗しても、利用者の画面に「資料請求を受け付けました」と出る。フォームが壊れているのではない。入力内容をサイトに通さず、Salesforce に直接送る作りにしたので、そうなる。

理由は2段ある。まず、Salesforce は、リードを作れたかどうかをフォームに知らせてこない。試験環境で、ロボット確認で止まってリードが作られなかったときも、返事は成功と同じだった。そもそもこの作りのフォームは、送り先から返ってきた中身を読めない。だからフォームは、送った時点で完了を出す作りにした（送信が終わるか、5秒たったら完了の表示に切り替える）。利用者の画面だけを見ても、成功か失敗かは分からない。

そこで、起こりうる失敗を13通り書き出し、それぞれに「誰が気づくか」を付けた。

誰が気づくか	起きること
営業（リードができて、通知が届く）	必須の欄が空のまま届く／メールアドレスの形式が不正／資料名が書き換えられている／同じ人が2回送る／いたずらの大量送信（5つ）
請求した人（案内メールが来ない）	アドレスの打ち間違い、迷惑メールのフォルダに入った（1つ）
ほかの人・仕組み	Salesforce の障害（Salesforce の障害情報で分かる）／1日の受付の上限を超える（作成者に知らせが届く）／サイトそのものの障害（制作会社）／長すぎる入力の切り詰め（対応は要らない）（4つ）
誰も気づかない	① フォームの送り先の設定を間違えた（何も作られない） ② ロボット確認の設定を間違えた（何も作られない） ③ 営業への通知が届かない（宛先や作成者の設定の間違い。試験環境では、作成者のアドレスが届かない形で、4件とも届かなかった）（3つ）

誰も気づかない3つには共通点がある。請求した人の画面には「受け付けました」が出る。営業には何も届かない。①と②は、Salesforce に記録すら残らない。③はリードが残るが、通知が来ないので誰も見に行かない。請求が届いていないのに、「最近、請求が少ないね」で終わりかねない。

だから、対処はフォームの中ではなく、運用の側に置いた。

• ▶ 公開前に、本番で1件ずつ送って確かめる：資料ごとに、ロボット確認をオンにした状態で。リードができ、案内メールと営業への通知の両方が届くところまで見る
• ▶ 公開後は、週に1回リードの件数を見る：通知が届かなくなったときの予備になる。見る人を決めておく
• ▶ 請求した人が気づけるようにしておく：完了の画面に「届かない場合は迷惑メールのフォルダをご確認ください」と書き、案内メールには問い合わせ先を書く

フォームの試験で一番怖いのは、エラーが出ることではない。成功に見えて、何も届いていないことだ。だから13通りに「誰が気づくか」を付けた。「誰も気づかない」の行が空でないなら、そこを埋めるのはフォームではなく、件数を見る人だ。

▼判断の分かれ目：「テストは通った」と聞いたら聞き返す3つ。自分の報告にも当てた

ここまでの話を、制作会社や担当者に聞ける形にすると、次の3つになる。

聞くのは、「通った」と言った人を責めるためではない。通った範囲を言葉にするためだ。「全部 pass」と言った自分も、どこまでが通ったのかを言えていなかった。だから、この3つを自分の報告にも当てた。

自分の報告に当てはめた：確認済みと見込みを分けた

会議で頼まれた資料は、データの流れ・エラーのときの動き・セキュリティの観点の3つにして、Excel で作った。中身より大事にしたのは、すべての行に「どこまで確かめたか」を付けたことだ。

区分	意味
確認済み	試験環境で実際に試した
確認中	試したが、結果の一部をまだ確かめている
未確認	まだ試していない。Salesforce の説明などからの見込み
要決定	会社に決めてもらうこと

資料の頭には、確かめたのは試験環境だけで、本番の Salesforce とサイトの実物ではまだ試していない、と書いた。「確認済み」も、試験環境での確認済みだ。資料の一番の役目は、読む人が「何が確かめ済みで、何が見込みか」を区別できることだ。全部に「OK」と書いた表は、また「全部 pass」を生む。

制作会社への依頼に当てはめた：「テスト用」と先に書き、本番と違う点を並べた

サイトの実物の上でフォームが動くかは、サイトを作っている制作会社に試してもらう。そのためのテスト用のフォームと、貼り方のメモを用意した（渡すのはこれからだ）。メモには、まず「テスト用」であることと、本番と違う点を書いた。

• ▶ 送り先は試験環境。本番のデータには入らない
• ▶ 案内メールの差出人は、Salesforce の仮のアドレスになる。本番は会社のアドレスの予定
• ▶ 案内メールの資料のリンクは仮のもの

確かめてほしいことは、6つに絞った。

#	確かめてほしいこと
1	フォームが崩れずに出るか（パソコンとスマートフォン）
2	必須の欄を空のまま送ると、エラーの表示が出るか
3	全部入れて送ると、「資料請求を受け付けました」が出るか
4	入れたメールアドレスに、資料の案内メールが届くか
5	プライバシーポリシーのリンクが開くか
6	入力した内容が、サイトの側に送られていないか（送り先が Salesforce だけか）

6番目は「何で試したか」の実例だ。このフォームは、入力された内容をサイトを作るサービス（Wix）に渡さず、利用者のブラウザから Salesforce に直接送る作りにしてある。ただ、サイトの実物の上で通信を見て確かめたことは、まだない。だから、実物の上で通信を見てもらう。届いたかどうかは、送った日時と会社名を教えてもらえれば、こちらで Salesforce を見て確かめる。

本番用のフォームは、まだ渡さない

本番用のフォームは、テストの確認が済んでから別に渡す。テスト用との違いは、送り先とロボット確認の有無の2つだけにする予定だ。違いを2つに絞っておけば、テストの結果のうち、どこまでが本番に持ち越せるかを言える。逆に言えば、ロボット確認はテスト用では試せない。だから本番の設定を入れたあと、サイトの実物でもう一度試す。

▼かかった期間：試験環境を作ってから会議まで6日。訂正は会議の当日

日付	やったこと
11月5日	本番の設定を読み取りだけで調べる。試験環境を作って設定を入れ、送ってリードが作られることを確かめる
11月9日	メールを送る範囲を変えて、資料の案内メールが届く
11月10日	作成者を変えて、営業への通知が届く。会議用の見本のページ（サイトと同じ制限の枠に埋め込んだもの）から送っても動いた
11月11日	会議で見せる。会議のあと、失敗の側の試験、2つの訂正、資料3つ、制作会社向けのテスト用フォーム

11月5日から10日の間に試験環境で直したのは、前の節の違いのうち2〜4の3つだ（ロボット確認、メールを送る範囲、作成者）。どれもエラーは出ず、「作られない」「届かない」ところから原因をたどった。1つ目の差出人だけは、会議のあとまで気づかなかった。本番の設定は、会社の回答が揃えば1〜2時間で入れられる見込みだ。試験環境と同じ設定をファイルで持っているので、それを本番に入れ、本番用に変える値だけ直す。

▼まだやっていないこと

• ▶ 本番からの送信：会社のアドレスで送って、確認が3種類とも通るか。「全部 pass」の本当の確認はこれだ
• ▶ サイトの実物での試験：制作会社に頼む。テスト用のフォームは用意した
• ▶ ロボット確認の設定：鍵を作る会社のアカウントが決まってから。間違えると「送れたように見えて届かない」ので、公開前に実物で必ず試す
• ▶ 会社に決めてもらうこと（9つ）：営業への通知の宛先／通知に入力内容を全部載せるか／案内メールの差出人／作成者／ロボット確認の鍵を作るアカウント／プライバシーポリシーへの同意を記録に残すか／資料の置き場所／リードを見られる人の範囲／古いリードの扱い
• ▶ 資料のリンクの差し替え：案内メールのリンクは仮。新しいサイトでの置き場所が決まったら差し替える

▼まとめ：自分の会社で確かめること

サイトのフォームを作り直している、または作り直したばかりなら、担当者や制作会社に次のことを聞いておくとよい。

• ▶ 「テストは通った」は、何で試した結果か：本番か、試験環境か。差出人・作成者・送り先は本番と同じか
• ▶ 失敗の側を試したか：空欄や不正な値で送ったとき、何が止まり、何が通るか
• ▶ フォームが失敗したら、誰が気づくか：誰も気づかないものがあるなら、届いた件数を定期的に見る人を決めたか
• ▶ 案内メールが迷惑メールに入っていないか：公開したら自分で1件請求して、受信箱に届くか、差出人のアドレスが会社のものかを見る
• ▶ 前任者の名前が残っていないか：通知の差出人や、フォームから入る記録の作成者が、辞めた人や前の担当者のままになっていないか

▼担当者向け：設定と手順の詳細

ここからは、Salesforce の Web-to-Lead を設定する担当者向けに、正式な名前と設定値を書く。組織 ID・項目 ID・実際のアドレスは伏せている。

前半の言い方と、実際の名前

前半の言い方	実際の名前
フォームから自動でリードを作る仕組み	Web-to-Lead（送信先は servlet.WebToLead）
試験環境	Developer Sandbox（今回のために新しく作成）
本当にその会社から来たかの確認（3種類）	SPF・DKIM・DMARC
Salesforce が代わりに使う仮のアドレス	代替アドレス email@<組織 ID>.sfcustomeremail.com（送信 → 到達性の「未確認のドメインには代替メールアドレスを使用」）
ドメインの確認と、メールに付ける署名の鍵	メール送信ドメインの検証（DKIM 鍵、または承認済みメールドメイン）
ロボット確認	reCAPTCHA v2（チェックボックス）。Web-to-リードの設定の「reCAPTCHA 検証が必要」
メールを送る範囲	送信 → 到達性 → 送信のアクセス権（アクセスなし／システムメールのみ／すべてのメール）
リードの作成者	Web-to-リードの設定の「デフォルトのリード作成者」
資料の案内メール	リードの自動レスポンスルール（資料ごとのエントリ）＋メールテンプレート（Classic のテキスト）
営業への通知	リードの割り当てルール → キュー（キューのメールアドレスに通知テンプレートで送る）
どの会社の Salesforce かの番号	組織 ID（フォームの oid）

pass の見方：pass の横のドメインを見る

受信したメールのヘッダー（Gmail なら「メッセージのソースを表示」）の Authentication-Results で、pass の横に書かれたドメインを見る。SPF は smtp.mailfrom（エンベロープの送信元）、DKIM は header.d（署名したドメイン）、DMARC は header.from（From のドメイン）だ。DMARC が pass するには、SPF か DKIM のどちらかが、From のドメインと一致した形で pass している必要がある（RFC 7489）。今回の Sandbox のメールは From が代替アドレスで、3つの pass は、会社のドメインではなく代替アドレスの側についての結果だった。

本番の状態（2026年11月5日に設定画面と公開 DNS を読み取りで確認）：会社のドメインは Salesforce でメール送信ドメインとして確認済み。DKIM の鍵は有効で、公開 DNS にセレクタの CNAME がある。SPF のレコードに Salesforce は入っていない。このため、本番で DMARC が pass するとすれば、会社のドメインでの DKIM 署名の一致による見込みだ。実際の結果は、本番から送ったメールのヘッダーで確かめる（未実施）。

新しい Developer Sandbox で本番と違っていた4つ

• ▶ 差出人が代替アドレスになる：Sandbox には会社のドメインの DKIM 鍵がなく、ドメインが確認済みになっていなかった。「未確認のドメインには代替メールアドレスを使用」は既定でオンで、組織のメールアドレスを選んでいなければ email@<組織 ID>.sfcustomeremail.com から送られる。表示名と返信先は変わらない（Salesforce ヘルプ：Send Email for Users with Unverified Domains）
• ▶ 「reCAPTCHA 検証が必要」がオン：Salesforce の説明でも、Web-to-Lead の reCAPTCHA は既定でオン（Salesforce ヘルプ：Generate Leads from Your Website with Web-to-Lead）。本番はオフだった。鍵の設定なしで送ると、リードは作られず、応答は 200 だった。テストのため Sandbox だけオフにした
• ▶ 送信のアクセス権が「システムメールのみ」：新規・更新した Sandbox の既定（Salesforce ヘルプ：Email Deliverability）。自動レスポンスが届いたのは「すべてのメール」に変えてから。テストが終わったら戻す（開けたままだと、Sandbox に写ったほかの業務の自動メールも外に出る）
• ▶ ユーザーのメールに .invalid が付く：Sandbox の作成・更新時に、本番のユーザーへメールが飛ばないよう付けられる（Salesforce ヘルプ：User Email Addresses Appended With ‘.invalid’）。デフォルトのリード作成者のアドレスも .invalid 付きになり、割り当てルールからキューへの通知が最初の4件とも届かなかった。作成者を自分に変えると届き、通知の差出人名は作成者の名前になった

失敗の側の試験（Sandbox の servlet.WebToLead に直接 POST）

送ったもの	結果
company・last_name なし	「[未指定]」でリードが作られる
email の形式が不正	リードは作られる（Lead の入力規則は0件で、形式は確かめていなかった）。キューへの通知も届く。自動レスポンスは届け先がない
oid が違う	何も作られない
氏名 120 文字	80 文字に切り詰めて作られる
debug=1 付き	リードは作られる
資料名（隠し項目）を書き換え	リードは作られる。自動レスポンスは出ない（エントリの条件に合わず、デフォルトの応答テンプレートを空にしているため）

フォームの側は、Salesforce の応答を読めない（別ドメインへの送信を見えない iframe に向けている）。そのため、iframe の読み込みが終わるか、5秒たった時点で完了の表示を出す。ブラウザ側の入力チェック（必須・メールと電話の形式・同意）と、人には見えない隠し欄（ボットが埋めたら送らずに完了の表示だけ出す）は、フォームの HTML に入れてある。

上限と、失敗の知らせ

• ▶ 1日の上限：Enterprise Edition などで24時間に500件。超えた分は Web-to-Case と共通の保留キュー（合わせて5万件まで）に入り、上限が戻ったときに処理される。上限を超えたことは、デフォルトのリード作成者にメールで知らされる。キューが満杯で拒否された分は、最初の5件だけ管理者に知らされる（Salesforce ヘルプ：How many leads can we capture from our website?）
• ▶ リードの作成に失敗したときの知らせ：デフォルトのリード作成者に届くという解説はあるが、Salesforce の公式の説明では確かめられていない。今回の試験でも確かめていない。上の「誰も気づかない」の①（oid 違い）では、作成者の側に何かが届く前提は置かない。知らせが届くとしても、宛先は作成者だ。作成者が前任者のままなら、今フォームを見ている人には届かない
• ▶ デフォルトのリード作成者の条件：Modify All Data・Send Email・Access Activities の権限が要る（上の Web-to-Lead のヘルプ）。前任者を外すなら、代わりの人にこの権限があるかを先に見る

本番に入れる前に直すもの

• ▶ キューのメールアドレス（Sandbox は自分のアドレス）→ 営業のメーリングリスト。Google グループなら、Salesforce からの投稿が弾かれないかも見る
• ▶ メールテンプレートの資料のリンク（今は仮）→ 資料ごとの URL
• ▶ デフォルトのリード作成者（前任者のまま）→ 会社が決めた人
• ▶ reCAPTCHA v2 の鍵を会社のアカウントで作り、Web-to-リードの設定に登録して「reCAPTCHA 検証が必要」をオン。埋め込みの枠のドメインも鍵に登録する（実際のドメインはテストで調べる）
• ▶ デフォルトの応答テンプレートは空のまま（資料名を書き換えた送信にメールを返さないため）
• ▶ フォームの送信先 URL と oid を本番の値に。Web-to-リードの生成画面で一度フォームを作り、項目 ID と reCAPTCHA の部分を照合する（生成するだけなら設定は変わらない）
• ▶ Sandbox の送信のアクセス権を「システムメールのみ」に戻す

セキュリティで聞かれたことへの答え

会議では「フォームのダウンロードは穴になりやすいと聞く」という指摘もあった。答えたのは次の4つだ。

• ▶ 入力内容の通り道：ブラウザから Salesforce へ HTTPS で直接送る。Wix に置くのはフォームの HTML だけ。Wix の実物の上で送信先が Salesforce だけかは、制作会社のテストで確かめる（未確認）
• ▶ 不正なリンクを送らせない：ダウンロードの URL は隠し項目で受け取らず、メールテンプレート側に固定した。フォームから受けるのは資料名だけで、自動レスポンスルールの条件と一字一句一致したときだけ送る。書き換えられると、会社のアドレスから任意のリンクを送れてしまうため
• ▶ HTML に入る値：組織 ID と項目 ID だけ。どちらも公開される前提の値で、ログイン情報や API キーは入らない。メールはテキスト形式で、入力に仕込まれたスクリプトが HTML として表示されることはない
• ▶ 受け取った後：リードを見られる人の範囲と、古いリードを含めた保存期間は、会社に決めてもらう項目に入れた。穴が残りやすいのは、フォームの作りより、受け取った後の置き場所のほうだ

公開後の見張り

リードソース（このフォームでは固定値）と作成日で絞ったレポートを作り、週に1回件数を見る。割り当てルールの条件に当たらないリードは、リードのデフォルト所有者に行く。キューの通知が来ないのに件数だけ増えている、または件数が止まった、というずれが、上の「誰も気づかない」の③と①②の合図になる。