--- title: "Web-to-リードとは？Salesforceの設定手順・1日500件の上限とretURLの注意点" url: "https://www.issoh.co.jp/column/details/7227/" published: 2025-06-13 updated: 2026-09-11 categories: ["マーケティング"] publisher: "株式会社一創" --- # Web-to-リードとは？Salesforceの設定手順・1日500件の上限とretURLの注意点 Web-to-リードは、自社サイトのフォームに入力された内容をSalesforceのリードとして自動登録する標準機能です。設定は管理画面でHTMLを生成して貼るだけで済みますが、そこに落とし穴があります。生成されたフォームの送信先である webto.salesforce.com を実際にたたいて応答を調べたところ、リードの作成に失敗して内部例外が発生した送信でもHTTPステータスは200が返り、retURLを指定していればユーザーはサンクスページへ遷移しました。つまり画面上は成功と区別がつきません。この記事では、Web-to-リードの仕組みと設定手順を整理したうえで、24時間500件という上限の実際の挙動、reCAPTCHAの対応バージョン、そして取りこぼしを検知するための運用設計までをまとめます。 ## まとめ - Web-to-リードは、フォームの内容を webto.salesforce.com へPOSTしてリードを作るSalesforce標準機能です。追加のAPI連携もApexの実装も要りません。 - リードの標準項目として姓（LastName）と会社名（Company）は必須です。ただしWeb-to-リードには空欄時の補完処理があり、個人取引先の設定によっても扱いが変わります。 - 取り込み上限は24時間あたり500件（Professional／Enterprise／Unlimited／Performance／Developer Edition）。超過分はWeb-to-ケースと共通の保留キューに入り、キュー自体にも50,000件という上限があります。 - スパム対策として組み込めるreCAPTCHAはv2だけです。スコア方式のv3には対応していません。 - 2026年9月11日の実測では、不正な組織IDまたは組織ID欠落を含む5条件のすべてでHTTP 200が返りました（正常登録時やすべての失敗条件を検証したものではありません）。エラーを示すステータスが返らない以上、監視は登録件数の突き合わせで組む必要があります。 ## Web-to-リードの仕組みとSalesforce側で起きること Web-to-リードは、Salesforceの設定画面で項目を選んでHTMLを生成し、それを自社サイトに設置して使います。訪問者がフォームを送信すると、内容はSalesforceのリードオブジェクトのレコードとして作成されます。CRMやSFAの外部連携でよく使うREST APIやSOAP APIとは別系統の、フォーム送信専用の受け口だと考えると位置づけがつかみやすくなります。Salesforce全体の機能構成は[Salesforceとは？CRMの機能・料金・認定資格から導入判断まで解説](/column/details/15087/)で整理しています。 この機能が組織で使える状態かどうかは、API上も参照できます。Object Reference for the Salesforce Platform（Version 68.0, Winter ’27）はOrganizationオブジェクトのUsesWebToLead項目を「Indicates whether this organization can use Web-to-Lead (true) or not (false).」と定義しており、boolean型の1項目で有効・無効が表現されています。 ### 送信先エンドポイントと隠し項目oid・retURL Salesforceが生成するフォームは、本番組織の場合 webto.salesforce.com/servlet/servlet.WebToLead?encoding=UTF-8 をactionに指定します。ここに加えて、hidden項目が2つ入ります。oidは送信先の組織IDで、どのSalesforce組織にリードを作るかを決めます。retURLは送信後に利用者を遷移させるURLで、いわゆるサンクスページの指定です。 ```
``` 上のコードは送信する項目を示す簡略例です。oidとretURLは自社の値に置き換えます。reCAPTCHA検証を有効にしている組織ではこの例だけでは足りないため、Salesforceが生成するreCAPTCHA関連のコードを含めて設置し、有効な検証用組織で登録を確認してから公開してください。 注意したいのはretURLです。後述する不正な組織IDを使った実測では、retURLを省いたPOSTに対して中身が空のレスポンスが返りました。この場合ブラウザは白い画面のまま止まり、利用者には送信できたかどうかが分かりません。retURLは任意項目のように見えて、実質的には必ず指定するものと考えてください。 ### リード作成に必須の標準項目と、空欄のときに入る値 リードの作成には姓と会社名が要ります。Object Reference v68.0は、Lead.LastNameを「Required. Last name of the lead up to 80 characters.」、Lead.Companyを「Required. The lead’s company. If person account record types have been enabled, and if the value of Company is null, the lead converts to a person account.」と記述しています。ただしフォーム側で空欄を防がないと、後述する補完処理によって実名の入っていないレコードが作られます。実名を取得したいのであれば、フォーム側で氏名欄を必須にしてください。また日本語のフォームでよくある氏名を1つの入力欄にまとめる設計にすると、その値をlast\_nameへ丸ごと送ることになり、姓と名を分けた集計ができなくなります。入力欄を分けるかどうかは、フォームの離脱率だけでなく後工程の分析要件から決めてください。 では空欄で送るとエラーになるかというと、そうではありません。Salesforceのナレッジ記事000385721は、Company項目がリードで普遍的に必須であるため「The Web-to-Lead system automatically inserts "\[not provided\]" as a placeholder」と説明しています。姓や会社名が空でも送信自体は通り、代わりに\[not provided\]という文字列が入ったレコードが作られます。ただしこれは個人取引先を使っていない組織での話です。Object Reference v68.0のLead.Companyは、個人取引先のレコードタイプが有効で会社名がnullの場合にリードが個人取引先へ変換されると定義しており、会社名を空のまま扱う前提が置かれています。BtoCのキャンペーンフォームなど会社名を聞かない設計を採るなら、自組織で個人取引先が有効かどうかによって保存される値と取引開始時の変換先が変わるため、後続のリスト作成やスコアリングを設計する前に確認しておいてください。なお、空欄が補完されることは登録の成功を意味しません。入力規則に違反すればレコードは作られません。 各項目の文字数もフォーム側で合わせておきます。Salesforce Field Reference Guide（Winter '27、2026年8月28日更新）がリード標準項目に定義している長さは、姓が80、名が40、会社名が255、メールが80です。名が40文字までである点は見落としやすく、氏名の分割設計を決めるときに確認してください。 もう一つの制約が項目型です。Salesforce Helpのリード生成に関する考慮事項（sales.leads\_gen\_considerations.htm）は「Salesforce doesn’t support Rich Text Area (RTA) fields on Web-to-Lead forms.」と明記しています。問い合わせ内容を書式付きで受け取ろうとしてRTA項目を作っても、Web-to-リードのフォームからは狙いどおりに扱えません。長文の入力欄はロングテキストエリアで設計します。 ## Salesforceでの設定手順と必要な権限 設定は、Salesforceの設定画面からWeb-to-リードを開き、取得したい項目を選んでHTMLを生成し、自社サイトに設置するという流れです。手順そのものは短く、詰まるとすればその前後にあります。 ### 必要な権限と対応エディション 設定にはアプリケーションのカスタマイズ権限（Customize Application）が必要です。Salesforce Helpの設定ページは必要権限を「To set up Web-to-Lead: | Customize Application」と示し、対応エディションを「Available in: Essentials, Group, Professional, Enterprise, Performance, Unlimited, and Developer Editions」と列挙しています。営業部門の担当者が自力で設定を進めようとして権限で止まるのはこの箇所です。着手前に権限セットを確認しておくと、手戻りが減ります。 ### debug・debugEmailによる公開前の動作確認 Salesforceは、公開前の確認手段としてフォームにデバッグ用のhidden項目を追加する方法を案内しています。debugに1を、debugEmailに自分のメールアドレスを設定して送信すると、「When you submit the form, Salesforce sends an email with debugging information to your email address.」とあるとおり、送信内容の詳細がメールで届きます。公開前にこのデバッグ情報を確認し、あわせて有効な検証用組織で作成されたリードの各項目が送信値と一致しているかまで照合してください。 画面側の挙動も変わります。debugに1を付けた送信を実際に行ったところ（2026年9月11日）、retURLを指定していてもサンクスページへは遷移せず、代わりに Salesforce.com Lead Capture Interface と題したデバッグページが返りました。そこには処理結果の理由に続けて、送信した company、last\_name、oid、retURL の値がそのまま列挙されます。 したがって確認が終わったら、この2項目は必ず削除します。残したままだと、送信者は毎回サンクスページの代わりにこのデバッグページを見ることになり、組織IDを含むhidden項目の中身まで画面に出ます。 ## リード未作成でもHTTP 200を返すエンドポイントの実測結果 ここからは実測です。Web-to-リードのエンドポイントに対して、条件を変えながらPOSTし応答を記録しました。使用した組織IDは実在しない00D000000000000で、実在の組織にリードは作成されません。 ### 送信条件別の実測レスポンス | 送信内容 | ステータス | レスポンスヘッダー | 本文 | | -------------------------------- | ----- | ----------------- | ----------------- | | oid + 姓 + 会社名（retURLなし） | 200 | defer: true | 0バイト | | oid + 姓 + 会社名 + retURL | 200 | defer: true | 559バイト（retURLへ遷移） | | oidなし + 姓 + 会社名 + retURL | 200 | is-processed に例外名 | 539バイト（retURLへ遷移） | | GETでフルパラメータ | 200 | defer: true | 0バイト | | oid + 姓 + 会社名 + retURL + debug=1 | 200 | defer: true | 421バイト（デバッグページ） | 計測は2026年9月11日、curlで実施しました。読み取れることは3つあります。 第一に、5条件すべてでHTTPステータスは200でした。組織IDが欠けて内部例外が発生したケースも例外ではありません。フォームの送信結果をステータスコードで判定する監視は、この設計では機能しません。 第二に、失敗した送信でもretURLへのリダイレクトは実行されました。oidなしのケースで返ってきた539バイトの本文は、meta refreshとwindow.location.replaceの両方でretURLへ遷移させるHTMLです。利用者はサンクスページを見て、送信できたと理解します。運営側も、フォームは動いているのにリードだけが増えないという状態を、何日も気づかないまま続けることになります。 第三に、レスポンスヘッダーも成否の判定には使えませんでした。oidを欠いた送信にはis-processed: true Exception:common.exception.SalesforceGenericExceptionが付きますが、存在しない組織IDを指定した送信にはdefer: trueが付き、内部例外を示すヘッダーは付きません。ところがまったく同じ内容にdebug=1だけを足して送ると、返ってきたデバッグページには「Reason: Your Lead could not be processed.」と書かれていました。defer: trueはリードが作られたことを意味しません。そもそもブラウザがフォームを直接POSTする通常の構成では、レスポンスヘッダーを読む手段がありません。 ### 取りこぼしを検知する運用の組み方 以上から、監視はエンドポイントの応答ではなく、送信数と作成数の突き合わせで組むのが現実的です。ただしサンクスページの表示回数は再読み込みや直接アクセスでも増えるため、差分監視の参考値にとどめます。正確に照合するなら、フォーム側で送信IDと送信日時を記録してSalesforce側にも保存し、保留キューによる作成の遅れを織り込んで突き合わせてください。差が開いたら、まずoidが正しいか、リード項目の必須設定や入力規則が送信内容とかみ合っているかを疑います。 その突き合わせを成立させるには、Web-to-リード経由で作られたレコードを識別できる必要があります。ところがSalesforceのナレッジ記事000387484は「Currently, there is no automated feature to identify how a lead is created.」と述べています。作成経路を自動で記録する仕組みは用意されていません。したがって、フォーム側でリードソース（Lead Source）の項目に固定値を渡し、自分で経路を刻む設計が要ります。Object Reference v68.0のLead.LeadSourceは選択リスト型で「The origin or source of the lead.」と定義された標準項目なので、フォームに含めるだけで済みます。複数のフォームを運用しているなら、フォームごとに値を分けておくと後の分析が楽になります。 ## 自動返信メールと担当者通知の役割分担 ここでは、リードが作られた後に動く割り当てルールと自動返信ルールを扱います。 割り当てルールは、作られたリードを誰が持つかを決めます。Salesforce Helpのリード準備に関するページは「If the rule is inactive, all web-generated leads get assigned to the default owner you specify in Lead Settings.」と記述しており、ルールが無効な状態では、Web経由のリードはすべてリード設定のデフォルト所有者に集まります。ルールを作ったつもりで有効化を忘れると、特定の1人の下にリードが積み上がり、誰も気づかないまま滞留します。 自動返信ルールは、送信者への確認メールを送ります。ここで押さえるべきは評価の順序です。Salesforce Helpの自動返信ルール作成ページは「The rule stops processing at the first matching entry, and then Salesforce sends the email using the specified email template.」と説明しています。ルールエントリは上から順に評価され、最初に一致した1件で処理が止まります。資料請求と問い合わせで文面を分けたい場合、条件の広いエントリを上に置くと下のエントリは永久に発火しません。並び順は設計対象です。 なお、送信者への自動返信と営業担当者への通知は別物です。前者は自動返信ルール、後者は割り当て時のメール通知や、リード作成をトリガーにしたフローで組みます。両方を必要とするなら、それぞれを別に設定してください。この先の育成の流れ、つまりスコアリングやシナリオ配信までを自動化したい場合は、Web-to-リードの守備範囲を超えます。[MAツールとは？主要6製品の公式料金比較と選び方・失敗しない判断基準](/column/details/13409/)で製品ごとの機能範囲を確認したうえで判断してください。 ## 24時間500件の上限と、超えたときに起きること Web-to-リードには取り込み件数の上限があります。Salesforce Helpは「In Professional, Enterprise, Unlimited, Performance, and Developer Edition organizations, you can capture up to 500 leads in a 24-hour period.」と記載しており、24時間あたり500件が基準です。 上限を超えた分がその場で失われるわけではありません。Salesforceのナレッジ記事000382807は「When an organization reaches the 24-hour limit, Salesforce stores additional requests in a pending request queue that contains both Web-to-Case and Web-to-Lead requests.」と説明しています。超過分は保留要求キューに入り、上限がリセットされてから処理されます。ここで重要なのは、このキューがWeb-to-ケースの要求と共用である点です。同じ組織でWeb-to-ケースも動かしているなら、両者の合算で枠を消費します。 そのキューにも上限があります。Web-to-ケースの注意事項ページは「The pending request queue has a limit of 50,000 combined requests. If your organization reaches the pending request limit, additional requests are rejected and not queued.」と記述しています。50,000件を超えた要求は拒否され、キューにも入りません。ただし未登録が起きるのはこの上限に達したときだけではなく、入力規則違反などでもリードは作られません。 500件という数字が足りるかどうかは、自社のフォーム送信数の日次実績とピーク日の値で判断します。上限が問題になるのは、キャンペーンやセミナー申し込みで短時間に集中するケース、そして次章で扱うスパム送信で枠を食い潰されるケースです。日次で500件に迫る見込みがあるなら、上限緩和をSalesforceのサポートへ相談するか、フォーム側で受け付けてから流量を制御して送る構成に切り替えます。 ## スパム対策のreCAPTCHAはv2のみ 公開フォームには自動送信が届きます。前章の500件の枠は、スパムでも同じように消費されます。 Salesforceは対策としてreCAPTCHAの組み込みを用意しており、設定ページは「To add a reCAPTCHA widget to the lead submission form, select Include reCAPTCHA in HTML and specify the reCAPTCHA API Key Pair」と案内しています。Google側でサイトキーとシークレットキーの組を発行し、それをSalesforceに登録したうえで、フォーム生成時にreCAPTCHAを含める指定をします。 ここに制約があります。Salesforceのナレッジ記事000394922は「The Web-to-X framework (used by Web-to-Lead and Web-to-Case) supports only Google reCAPTCHA version 2 (reCAPTCHA v2).」と述べており、対応するのはv2だけです。Google側のv2にはチェックボックス方式とInvisible方式の2種類があり、前者は「The "I'm not a robot" Checkbox requires the user to click a checkbox indicating the user is not a robot.」と説明されるとおり利用者の操作を求めます。一方v3は「reCAPTCHA v3 allows you to verify if an interaction is legitimate without any user interaction. It is a pure JavaScript API returning a score」とあるとおり、操作なしでスコアを返す別方式です。Salesforce側が対応を明示しているのはv2という版までなので、v2のどの方式まで想定するかは自組織の設定画面で確認してください。 サイト全体をv3で統一している場合、Web-to-リードのフォームだけはv2のキーを別に発行して併存させることになります。reCAPTCHA検証そのものはSalesforceの設定で無効にもできますが、v3のスコア判定を必須にしたいのであれば、標準のWeb-to-リードから離れ、自社サーバーでいったん受けてからSalesforceへ渡す構成を選ぶことになります。 ## Web-to-ケース・MAツールのフォームとの使い分け Salesforceには、リードを作るWeb-to-リードのほかに、ケース（問い合わせ）を作るWeb-to-ケースがあります。作られるオブジェクトが違うので、用途で選びます。新規の見込み客を営業が追いかけるならリード、既存顧客からのサポート依頼を対応履歴として管理するならケースです。 上限値も同じではありません。ナレッジ記事000382807は「Salesforce enforces a maximum number of new Cases (5000) and Leads (500) generated in a 24 hours period」と記述しており、ケースが5,000件に対してリードは500件と10倍の開きがあります。問い合わせフォームの設計時に、この差を知らずにリード側で受けると先に枠を使い切ります。サポート窓口としての運用設計は[問い合わせ管理システムとは？機能・種類とExcel管理の限界、自社開発の判断基準](/column/details/15376/)もあわせて検討してください。 ### Web-to-リードを選ぶべきでない場面 標準機能で足りるかどうかは、次の条件で判断がつきます。 まず、送信結果をその場で利用者に返したい場合は不向きです。実測したとおりエンドポイントは失敗しても200を返し、retURLへ遷移させます。入力内容の検証結果や重複チェックの結果を画面に出したいなら、自社サーバーで受けてApexやREST APIでSalesforceに渡す構成にします。Salesforce側の実装言語については[Apexとは？Salesforce専用のオブジェクト指向言語をガバナ制限と実装目線で解説](/tech/details/15399/)で扱っています。 次に、日次の受信が500件を超える規模では、超過分が保留キューに入り、リードの作成が遅れます。インサイドセールスが当日中の架電を運用ルールにしている組織では、この遅延が成果に直結します。 さらに、reCAPTCHA v3を前提にしたフォーム設計や、リッチテキスト項目での受け取りを必要とする要件も、標準では満たせません。逆に言えば、これらに該当しないのであれば、Web-to-リードはAPI連携の独自実装を省ける合理的な選択肢です。ただしフォームの設置、項目設定、動作確認、監視の作業までが不要になるわけではありません。SFA全体の中でどこまでを標準機能に任せるかという整理は[SFAとは？営業支援システムの機能・CRM/MAとの違いと選び方を解説](/column/details/12807/)が参考になります。 ## よくある質問 ### Web-to-リードとは何ですか？ 自社サイトのフォームに入力された内容を、Salesforceのリードとして自動登録する標準機能です。Salesforceの設定画面で取得したい項目を選ぶとHTMLが生成され、それを自社サイトに設置すると、送信内容が webto.salesforce.com へPOSTされてリードが作られます。REST APIやSOAP APIを使った連携実装は不要で、対応エディションはEssentials、Group、Professional、Enterprise、Performance、Unlimited、Developerです。 ### Web-to-リードで1日に登録できる件数に上限はありますか？ Professional、Enterprise、Unlimited、Performance、Developer Editionでは24時間あたり500件です。超過分はWeb-to-ケースと共通の保留要求キューに入り、上限がリセットされた後に処理されます。ただしそのキュー自体にも50,000件の上限があり、超えた要求は拒否されてキューにも入りません。同じ組織でWeb-to-ケースを併用している場合、キューの枠は合算で消費される点にも注意が必要です。 ### フォームは動いているのにリードが登録されません。どこを見ればよいですか？ まずoidに設定した組織IDを確認してください。2026年9月11日の実測では、oidが欠けて内部例外が発生した送信でもHTTPステータスは200が返り、retURLを指定していればサンクスページへ遷移しました。画面上は成功と区別がつかないため、送信自体が通っているように見えても登録されていない状態が起こり得ます。次に、リード項目の必須設定や入力規則がフォームの送信内容と矛盾していないかを確認します。切り分けにはdebugとdebugEmailのhidden項目を一時的に追加してください。debugに1を付けた送信ではサンクスページへの遷移が止まり、代わりに処理結果の理由と送信値を列挙したデバッグページが返るため、失敗しているかどうかをその場で確認できます。確認が終わったら2項目とも必ず削除します。 ### Web-to-リードで自動返信メールを送れますか？ リードの自動返信ルールで送れます。ルールエントリは上から順に評価され、最初に一致した1件で処理が止まり、そのエントリに指定されたメールテンプレートが送信されます。資料請求と問い合わせで文面を分けたい場合は、条件の広いエントリを上に置かないよう並び順を設計してください。営業担当者への通知は自動返信ルールとは別の仕組みなので、割り当て時のメール通知やフローで個別に設定します。 ### Web-to-リードでreCAPTCHA v3は使えますか？ 使えません。Web-to-リードとWeb-to-ケースが属するWeb-to-Xのフレームワークが対応しているのはGoogle reCAPTCHA v2のみです。v2はチェックボックスの操作を利用者に求める方式で、操作なしでスコアを返すv3とは別系統になります。サイト全体をv3で統一している場合は、Web-to-リードのフォーム用にv2のキーを別途発行するか、自社サーバーで受けてからSalesforceへ渡す構成に切り替えます。 ### Web-to-リードとWeb-to-ケースはどちらを使うべきですか？ 作りたいレコードで選びます。新規の見込み客を営業が追いかけるならリード、既存顧客からのサポート依頼を対応履歴として残すならケースです。24時間あたりの上限はケースが5,000件、リードが500件と差があるため、問い合わせ量が多い窓口をリード側で受けると先に枠を使い切ります。 ## 関連記事 - [Salesforceとは？CRMの機能・料金・認定資格から導入判断まで解説](/column/details/15087/) - [SFAとは？営業支援システムの機能・CRM/MAとの違いと選び方を解説](/column/details/12807/) - [MAツールとは？主要6製品の公式料金比較と選び方・失敗しない判断基準](/column/details/13409/) - [問い合わせ管理システムとは？機能・種類とExcel管理の限界、自社開発の判断基準](/column/details/15376/) - [Apexとは？Salesforce専用のオブジェクト指向言語をガバナ制限と実装目線で解説](/tech/details/15399/) --- 出典: [Web-to-リードとは？Salesforceの設定手順・1日500件の上限とretURLの注意点]()（株式会社一創）