HubSpotフォームの電話番号は国番号なしで入力させられるか｜国コードドロップダウンを外せない理由と、ワークフローで+81を補う実装

フォームに電話番号の項目を置いたら、入力欄の左に「US ▼ +1」というドロップダウンが出てきた。日本向けのサイトなのに国旗と+1が並んでいて、これを毎回選ばせるのは無理があるのではないか。

新しいフォームエディターで「電話番号」フィールドタイプを使っている限り、このドロップダウンを非表示にすることはできません。設定項目そのものが用意されていません。ただし、ユーザーに国番号なしで入力させること自体は実現できます。フォームで受けるプロパティーを単一行テキストのカスタムプロパティーに差し替え、送信後にワークフローでE.164形式へ整形して、正式な電話番号プロパティーに書き戻す。この形にすれば入力欄はただのテキストボックスになり、「09012345678」とだけ打てば済みます。

なぜ設定では外せないのか、そして実際に何をどう組んだのかを順に書きます。

なぜドロップダウンを消せないのか

新エディターで既定の電話番号フィールドを配置し、フィールドを選択して左サイドバーを開いても、ドロップダウンの表示を切り替える項目は出てきません。設定で対応できる話ではない、というのが結論です。

理由はフィールドタイプの設計にあります。「電話番号」というフィールドタイプは単なるテキスト入力ではなく、国コードを起点に検証と書式設定がかかる作りになっています。既定の「電話番号」「携帯電話番号」「FAX」がこれにあたり、カスタムプロパティーでも選べます。

プロパティー設定の［ルール］タブで「このプロパティーの電話番号を検証する」をオンにすると、値はE.164形式を満たす必要が出てきます。プラス記号で始まる有効な国コードを含み、その国コードの数値形式に一致し、有効な市外局番を含み、全体で4桁から15桁。使えるのは数字と先頭のプラス記号だけです。保存される値には書式が入らず、+18884827768 として格納され、画面上は +1 (888) 482-7768 と地域形式で表示されます。

最初から国コードありきで設計されているので、フォーム上のドロップダウンは、その国コードをどう取得するかというUIでしかありません。だから消す設定が存在しない。

旧フォームエディターであれば外せます。ただし、旧エディターがいつ提供終了になるか公表されていませんし、旧エディターで作ったフォームを新エディターへ引き継ぐ手段もありません。あとから移行できない前提で旧エディターに作り込むのは、これから始めるものとしてはお勧めしません。

既定の国コードを+81にすれば済むのでは

電話番号プロパティーのルールでは、既定の国コードを設定できます。値に国コードがなくても他の条件を満たしていれば、保存前に指定した国コードが自動で付与される。日本のアカウントなら+81を入れておけば済みそうに見えますが、この既定の国コードが適用されるのはインポート経由での更新だけです。フォーム送信では働きません。

これを見落とすと、「+81を既定にしたのだからフォーム側は素の番号でいい」という前提のまま設計が進み、テスト段階で崩れます。実装の順番としては、ここの確認を最初に済ませておいたほうがいいです。

入力欄をただのテキストボックスにする

ここから実装です。前提はMarketing / Sales / Service / Data Hub のいずれかでProfessional以上とします（理由は後ろで書きます）。

まずコンタクトプロパティーで、フィールドタイプを「単一行テキスト」にした新しいプロパティーを作ります。「電話番号（入力用）」のように、正式な電話番号プロパティーと取り違えない名前にしておくと後の運用が楽です。ここで電話番号フィールドタイプを選ばないことが肝で、選んだ瞬間に国番号のドロップダウンが復活します。

次にフォームエディターで既存の電話番号フィールドを削除し、作ったカスタムプロパティーを配置します。プレースホルダーに「例：09012345678」と入れておくと、ハイフンの有無で迷われる率が下がります。

この時点で、ユーザーから見た入力欄はただのテキストボックスになります。国旗も+1も出ません。目に見える部分の対応はここで終わりです。

入った番号をどうやって+81付きに直すか

カスタムプロパティーに入った素の番号は、そのままでは架電にもSMSにも外部連携にも使えません。それらが参照しているのは正式な電話番号プロパティーのほうです。ここを繋ぎます。

コンタクトベースのワークフローを作り、登録トリガーを対象フォームの送信、またはカスタムプロパティーが空でないことに設定します。

※画像のトリガー条件は、電話番号（入力用）プロパティが更新された場合も含めています。

アクションは［CRM］カテゴリの「電話番号を検証してフォーマット」です。設定するのは、フォーマットして検証するプロパティー（作ったカスタムプロパティーを指定）と、既定の国コードモードの2つ。国コードモードは静的と動的があり、日本の番号しか来ない前提なら静的を選んでJapanを指定します。海外からの送信も想定するなら動的にすると、レコードの「国／地域コード」プロパティーを参照して判定します。ただし動的を使うなら、その「国／地域コード」がフォーム送信の時点で埋まっている必要があります。フォームに国の選択肢を置いていないなら静的のほうが破綻しません。

間違えやすいのはこの次です。「電話番号を検証してフォーマット」アクションは、プロパティーを自動では更新しません。整形した値を出力として返すだけです。

続けて［CRM］の「レコードを編集」アクションを追加します。編集するプロパティーに「電話番号」または「携帯電話番号」を選び、値を選択する画面で「プロパティーまたはアクション出力の表示元」を［アクションデータ］に切り替え、「電話番号を検証してフォーマット」の中から「解析済み電話番号出力(Parsed phone number output)」を選びます。

これで「09012345678」という入力が +819012345678 として正式なプロパティーに入ります。

変換に失敗した番号はどうなるか

整形が通らないケースは必ず出ます。桁が足りない、番号ではない文字列が入っている、そういうものです。

分岐アクションで「1つのプロパティーまたはアクション出力」を選び、分岐対象に「電話番号を検証してフォーマット」の「このアクションの最終的な成功率または失敗率」を指定します。条件を「次と等しい」「失敗、オブジェクトは次のアクションに進みました」にすると、失敗したレコードだけを別の枝に流せます。

その枝でやることとしては、担当者へのタスク作成が現実的です。「レコードを編集」で値をクリアする手もありますが、フォームから来た生の入力を消してしまうと、あとから何が入っていたのか追えなくなります。カスタムプロパティー側の値は残したまま、正式な電話番号プロパティーには書かない。この形にしておくほうが後で困りません。

テストは実装より時間がかかります。ハイフンなし、ハイフンあり、固定電話、頭の0を落とした入力、全角数字、そして+81を自分で付けてくる入力。このうちどれを通してどれを弾くかを先に決めておかないと、ワークフローの分岐を何度も作り直すことになります。

入力ルールはどこまで縛るべきか

実際に組んでいて一番時間を取られたのは、ワークフローよりも入力ルールの検証のほうでした。

単一行テキストのルールには「スペースを許可しない」「最小文字数」「最大文字数」「記号や特殊文字を許可しない」「数値のみを許可」といった項目が並んでいます。項目数はあるのですが、日本の電話番号表記との相性が良くありません。

たとえば「数値のみを許可」をオンにすると、ハイフン入りの「090-1234-5678」が弾かれます。ではハイフンを許可しようと「記号や特殊文字を許可しない」をオフにすると、今度は括弧やスラッシュ、ピリオドまで通ってしまう。桁数で縛ろうとしても、ハイフンありとなしで文字数が変わるので、最小・最大の幅を広く取らざるを得ず、結果としてほとんど何も弾けなくなります。

固定電話も厄介です。市外局番は2桁から5桁まであり、東京の「03-1234-5678」と、市外局番が4桁の地域では、ハイフンの位置がまるで違います。既存のルールの組み合わせでこれを表現する方法は見つかりませんでした。

結論としては、正規表現によるカスタムルールに寄せたほうが早いです。実際に使っているのがこちらです。

^(?:0[36][0-9]{8}|0[1-9][1-9][0-9]{7}|0[789]0[0-9]{8}|050[0-9]{8}|0800[0-9]{7}|0[36]-[0-9]{4}-[0-9]{4}|0[789]0-[0-9]{4}-[0-9]{4}|050-[0-9]{4}-[0-9]{4}|0800-[0-9]{3}-[0-9]{4}|0120-[0-9]{3}-[0-9]{3}|0570-[0-9]{3}-[0-9]{3}|0[1-9][1-9]-[0-9]{3}-[0-9]{4}|0[1-9][0-9]{2}-[0-9]{2}-[0-9]{4}|0[1-9][0-9]{3}-[0-9]-[0-9]{4}|\+81-?[36][0-9]{8}|\+81-?[1-9][1-9][0-9]{7}|\+81-?[789]0[0-9]{8}|\+81-?50[0-9]{8}|\+81-?800[0-9]{7}|\+81-?[36]-[0-9]{4}-[0-9]{4}|\+81-?[789]0-[0-9]{4}-[0-9]{4}|\+81-?50-[0-9]{4}-[0-9]{4}|\+81-?800-[0-9]{3}-[0-9]{4}|\+81-?120-[0-9]{3}-[0-9]{3}|\+81-?570-[0-9]{3}-[0-9]{3}|\+81-?[1-9][1-9]-[0-9]{3}-[0-9]{4}|\+81-?[1-9][0-9]{2}-[0-9]{2}-[0-9]{4}|\+81-?[1-9][0-9]{3}-[0-9]-[0-9]{4})$

長く見えますが、やっていることは単純です。前半が国内表記、後半が+81始まりの表記で、それぞれについてハイフンなしとハイフンありのパターンを列挙しています。

カバーしているのは次のとおりです。

逆に通らないものもはっきりさせておきます。

• 全角数字（「０９０－１２３４－５６７８」は弾かれます）
• 括弧表記（「03(1234)5678」）
• スペース区切り（「090 1234 5678」）
• 内線付き（「03-1234-5678 内線123」）

全角数字は日本語フォームだと一定の割合で入ってきます。弾いてエラーを出すか、通しておいて後段で半角に変換するかは判断が分かれるところです。エラーを出す場合は、無効な値のメッセージを「半角でご入力ください」のように具体的に書かないと、何が悪いのか伝わりません。

なお、このカスタムルールを使うにはProfessionalまたはEnterpriseが必要です（執筆時点）。

それと、検証ルールが効く場所も把握しておいたほうがいいです。新しいフォームエディター経由の送信には適用されますが、ワークフロー、チャットフロー、ミーティングスケジュール設定ページ、旧エディターのフォームからの送信には適用されません。フォームだけ固めても、チャットから入ってくる値は素通りします。

厳しくすればデータはきれいになりますが、そもそも国コードのドロップダウンを外したのはコンバージョンを取りに行くためでした。入力ルールで別の脱落を作っては本末転倒です。

Starter・Freeでもできるのか

標準機能の範囲では、途中までしか進めません。

カスタムプロパティーを作ってフォームに置き替えるところまでは同じようにできます。国コードのドロップダウンを消すという目的だけなら、それで達成されます。止まるのはその先で、入ってきた素の番号を誰がE.164に直すのか、というところです。

「電話番号を検証してフォーマット」ワークフローアクションは各HubのProfessionalまたはEnterpriseで使える機能で、正規表現によるカスタム検証ルールも同様です（執筆時点）。Starterではどちらも選べません。

ここから先はAPIの領域になります。フォーム送信をサーバー側で受けてCRM APIで書き込む、あるいは外部から定期的にプロパティーを更新する。そういう作り方をすれば実現はできます。標準機能でできることではありませんが、できないわけでもない。Data Hub Professionalがあれば、ワークフロー内のカスタムコードアクションでも書けます。

プランを上げるのと外部に処理を持つのと、どちらが妥当かはフォームの本数と月間の送信件数次第です。フォームが1本で月に数十件なら、正直どちらでも回ると思います。

こういう相談を受けています

「国番号を選ばせる形式は日本のフォームでは見慣れないので、入力の途中でやめている人がいるのではないか」

以前いただいた相談です。問い合わせ、資料請求、見積依頼等、サイト上のフォームをHubSpotで構築している企業からの話でした。代替案の設計から実装、テストまで対応しています。

手を動かすまで気づかなかったのは、旧エディターなら簡単に外せるのに、新エディターへ移行する手段がないせいで旧エディターという選択肢自体が取りづらい、という点でした。標準機能のどこまでが本当に限界で、どこからが組み方の問題なのか。その切り分けから相談を受けることが多いです。フォームの項目を変えたいがCRM側のデータ形式との整合が取れるか分からない、といった段階でも構いません。月10時間からの保守プランもあるので、スポットや小規模なところから始められます。