VtigerCRM OSSの導入・運用｜フォーム連携

WordPressの問い合わせをVtigerCRMに自動登録する方法｜フォーム連携の設定とテスト

WordPressにVtigerCRM OSSの標準Webフォームを設置すると、問い合わせを見込み客（リード）として登録できます。CRM側で担当者を割り当て、ワークフローで受付を知らせれば、営業やサポートがCRMから対応を始められます。

このガイドでは、氏名・会社名・メールアドレス・問い合わせ内容の項目対応から、二重登録対策と送信失敗時の切り分けまで、公開前に確認する順に解説します。

対象環境｜ VtigerCRM OSS 8.4.0の標準WebフォームとWordPressのブロックエディター

01 ／連携方式を選ぶ

新しい問い合わせフォームは標準Webフォームから始める

新しくフォームを設置する場合は、VtigerCRMで生成したHTMLをWordPressに貼り付けます。ブラウザーからVtigerCRMに送信され、設定したモジュールにレコードが登録されます。この方式では、WordPress側で問い合わせを保存する処理は別途設ける必要があります。

現在のフォームを使い続ける場合は、フォームプラグインの送信後処理やコネクターを使い、WordPress側のサーバーからVtigerCRMのWebサービスAPIへ連携する方式を検討します。現在の自動返信や入力チェックを維持しやすく、CRM障害時の受付履歴や再送処理も設計できます。API認証情報はサーバー側で管理します。

VtigerCRMのAPI連携の全体像と実装方式 →

02 ／ CRM側の受け皿を作る

VtigerCRMのWebフォームを作成し、項目を対応させる

登録先を決める。管理者で「CRM設定 → オートメーション → Webフォーム」を開き、新規フォームを作成します。ここでは「見込み客（Leads）」を選びます。
受付担当と戻り先を設定する。受付を受け持つ担当者を選び、戻りURLにWordPress側の結果案内ページのHTTPS URLを指定します。OSS 8.4.0標準は戻りURLに結果のクエリを付加するため、既存のクエリがないURLを使います。最初は固定担当者でテストすると割り当てを確認しやすくなります。
入力項目と受付経路を設定する。下表を参考に項目を選びます。フォーム専用の通知に絞る場合は、カスタム項目「受付経路」を用意し、Webフォーム側で固定値「WordPress問い合わせ」と非表示を設定します。
有効化してHTMLを取得する。保存後に「フォームを表示する」を開き、生成されたコードをコピーします。CRM側の必須項目が入力または適切な固定値で満たされるか確認します。

見込み客に登録する場合の項目対応例。実際の入力欄名は生成したHTMLで照合します。
フォームに表示する項目	VtigerCRMの項目	設定時の確認
姓・名	姓 `lastname`、名 `firstname`	姓は必須。名も必要な場合は別欄にします。
会社名	会社名 `company`	B2Bの受付では入力欄を用意し、CRM側の必須設定と合わせます。
メールアドレス	メール `email`	返信に使う場合は必須にし、テストで保存された値を照合します。
お問い合わせ内容	説明 `description`	複数行の入力欄にし、日本語と改行が保存されるか確認します。
受付経路（非表示）	受付経路（カスタム項目の例）	CRMのWebフォーム設定に固定値を持たせます。項目の内部名は環境ごとに確認します。

画面付きの基本手順を読む｜ VtigerCRMの標準Webフォーム設定 →

03 ／ WordPressに設置する

カスタムHTMLブロックに生成コードを貼り付ける

WordPressの固定ページを開き、「カスタムHTML」ブロックを追加します。既存フォームの内側に新しいフォームを入れず、独立したブロックに配置します。
生成HTMLの <form> から </form> までを貼り付けます。method="post"、action、publicid や urlencodeenable などの隠し項目、各入力欄の name を保ちます。8.4.0標準の送信先はCRM配下の modules/Webforms/capture.php です。
保存後、ログアウトした状態で公開前のテストページを開きます。ブラウザーの開発者ツールで実際に出力されたフォームと送信先を確認します。保存後にタグや属性が消える場合は、編集権限とWordPressのHTMLフィルターを確認します。

結果ページの表示は、登録結果に合わせます。

OSS 8.4.0標準は、戻りURLを設定すると成功時は ?success=ok、戻り先を確定した後のエラーでは ?error=... を付けて移動します。戻りURLが空の場合はJSONで結果を返します。固定ページに到着しただけで「受付完了」と表示せず、結果に応じて文言を出し分けるか、案内だけのページにします。エラーの詳細は公開画面にそのまま表示せず、管理者が確認できるようにします。

04 ／担当者が対応を始められるようにする

担当者通知を設定し、二重登録の原因を分けて対策する

登録時だけ、受付担当へ通知する

見込み客のワークフローを「新規作成時」で設定し、条件を「受付経路がWordPress問い合わせ」に絞ります。メールアクションの宛先は、初期運用では受付担当や受付用共有メールアドレスを指定すると検証しやすくなります。メール本文には確認に必要な最小限の情報を載せ、詳しい内容は権限を持つ担当者がCRMで確認します。

レコードの担当者と、通知メールの宛先は個別に設定・確認します。担当者を交代で割り当てる場合は、担当者ごとに期待した宛先に届くか、複数回テストします。8.4.0標準のワークフローメールはキューで処理されるため、送信メールサーバーとワークフローのスケジューラー・サーバー側のcronも確認します。

連打・同じ人からの別件・通信障害後の再送を区別する

連打対策。入力検証を通って送信を開始した時点でボタンを無効化し、送信中と表示します。処理の失敗が確認できた場合や、入力画面に戻った場合に再操作できるかもテストします。
CRMの重複チェック。標準フォームは新規作成を試み、CRMの重複防止設定に該当すれば登録が拒否される場合があります。同じメールアドレスから別件が届く運用では、メール一致だけで受付を拒否すると取りこぼしが生じます。新規問い合わせと既存顧客の名寄せは別のルールにします。
再送時の二重登録防止。再送や障害復旧が必要な場合は、サーバー連携で送信ごとに受付IDを発行し、同じ送信の再試行ではそのIDを使い回します。受付側でIDを一意に確保し、CRM側にも保存して登録状況を照合できるようにします。タイムアウトで結果が不明なら、CRMの受付IDを確認してから再送します。

05 ／公開前に送信テストする

画面・CRM登録・担当者通知をそれぞれ確認する

検証用のフォームと宛先を使い、問い合わせ本文に「フォーム試験 A01」などの識別用の文字列を入れます。テスト後はCRMに残った検証用レコードを確認し、運用ルールに沿って整理します。

WordPressのフォームを公開する前の確認表
試すこと	確認する結果
正常送信	結果画面を確認し、見込み客が1件登録されること、日本語・改行・担当者が正しいこと、予定の宛先に通知が1通届くことを確認。
必須項目を空欄にする	入力エラーが出て、見込み客も通知も増えないことを確認。
送信ボタンを連打する	連打対策を入れた場合は、同じ操作でPOSTと登録が重複しないことを確認。
同じアドレスで別件を送る	異なる問い合わせが、事前に決めた方針どおりに記録されることを確認。
CRMの受付失敗	検証用フォームを無効にして送信し、登録されず、成功表示や担当者通知が出ないことを確認。検証後は設定を戻す。
同じ受付IDで再送する	再送対応を実装した場合は、通信途絶後も同じ受付IDで照合でき、登録が増えないことを確認。

06 ／症状から原因を絞る

送信できないときは、POST・登録結果・通知を順に確認する

ログには受付ID、時刻、処理結果などを残し、入力内容の全文や認証情報の記録は避けます。
症状	最初に確認する場所
押してもPOSTが出ない	開発者ツールのNetworkとConsoleを開き、必須入力のエラー、公開後のHTML、フォームの入れ子、サイトのCSP（`form-action`）を確認します。
HTTP 403・404	HTTPSの送信先URL、CRMの設置ディレクトリ、`capture.php` の大文字・小文字、アクセス制御やWAFのログを確認します。CRMが社内ネットワークからのみ利用できる場合は、外部ブラウザーからの直接送信に代わるサーバー連携を検討します。
フォームが見つからない・項目が保存されない	フォームの有効状態、生成し直した `publicid`、項目の `name`、固定値、CRMの必須項目と重複条件を確認します。
HTTP 200・戻り先に到着したが見込み客が見つからない	送信リクエストの応答本文またはリダイレクト先の結果を確認し、CRMで試験用の文字列と担当者を検索します。タイムアウト時も登録済みか先に確認します。
登録されたが通知が来ない	受付経路とワークフローの実行条件、キューとスケジューラー、宛先、SMTP、受信側の隔離・迷惑メールを順に確認します。