FormBridgeとkintoneの設計方法｜フォーム入力を業務データに変える構成

FormBridgeは、kintoneに直接データを登録できるWebフォームを作るためのサービスです。

問い合わせフォーム、資料請求、イベント申込、アンケート、社内外の申請、取引先からの報告。

kintoneのユーザーではない人から入力を受け付けられるため、Excelやメールで集めていた情報をkintoneに入れる入口として使えます。

FormBridge公式の機能ページでも、フォーム作成、デザイン変更、確認画面、条件分岐、自動返信メール、iframe埋め込みなど、Webフォームとして必要な機能が紹介されています。

リコーの紹介ページでも、フォームへの回答をkintoneに自動登録できるサービスとして説明されています。

リコー：フォームブリッジ

ただし、実務で失敗しやすいのは、フォームを作れないことではありません。

問題になりやすいのは、フォームから入ったデータを、そのままkintoneの本データとして扱ってしまうことです。

• 同じ人が複数回送信して、問い合わせや申請が重複する
• 入力内容が不完全なのに、案件や顧客として登録される
• スパムや営業メールが対応対象に混ざる
• 問い合わせ、申請、アンケート、資料請求が同じアプリに入る
• フォーム項目の変更でkintone側の集計や通知が壊れる
• 誰が確認し、誰が返信するのか決まっていない
• 自動返信は送られているが、社内の対応期限が追えない
• 公開ページ、帳票、メール送信との責任範囲が曖昧になる

FormBridgeは、外部入力をkintoneに入れる入口です。

入口を作るだけでは、業務は完了しません。

外部から入ったデータを、受付、確認、振り分け、対応、返信、公開、帳票へつなぐ設計が必要です。

FormBridgeとkintoneの設計で最初に決めるべきなのは、フォーム項目ではなく、「外部入力をどこで確認し、いつ本データに昇格させるか」です。

この記事では、FormBridgeの操作手順ではなく、kintoneの業務アプリとして崩れにくいフォーム連携の設計方法を整理します。

kintone問い合わせ管理の設計方法はこちら
kintone顧客管理の設計方法はこちら

先に結論：フォーム入力は受付アプリでいったん受ける

FormBridgeからkintoneにデータを登録するとき、いきなり顧客マスタや案件アプリに入れたくなります。

問い合わせフォームなら問い合わせアプリへ。

資料請求なら顧客マスタへ。

申請フォームなら申請アプリへ。

構成としては分かりやすいですが、社外から入る情報をそのまま本データにすると、後から修正しにくくなります。

基本は、FormBridgeの登録先に「受付アプリ」を置きます。

分けるもの	1レコードの意味	役割
公開フォーム	1つの入力画面	外部ユーザーに見せる項目、説明、同意、完了画面を持つ
受付アプリ	1回の送信	入力原文、受付経路、確認状態、重複候補を残す
確認キュー	1件の確認作業	本データ化するか、差し戻すか、破棄するかを判断する
顧客・担当者マスタ	1社、1人	既存顧客との照合、表記揺れの統一に使う
問い合わせ	1件の対応対象	担当、期限、返信、対応履歴を管理する
案件・申請	1商談、1申請	受付後に業務プロセスへ渡す
対応履歴	1回の対応	返信、確認、社内判断、差し戻し理由を残す
連携ログ	1回の連携結果	フォーム版、登録結果、通知結果、エラーを追う

受付アプリは、外部入力の原本を残す場所です。

問い合わせアプリや案件アプリは、社内が対応する業務単位です。

顧客マスタは、表記揺れを統一する辞書です。

この3つを混ぜると、入力された内容を直すべきなのか、顧客情報を直すべきなのか、対応状態を進めるべきなのかが曖昧になります。

FormBridgeの入門ガイドでも、フォーム作成からkintone連携までの初期設定が説明されています。

FormBridge入門ガイド

その次に必要なのが、受付後の業務設計です。

フォームを作った後、誰が確認し、どのアプリへ渡し、どの通知を出し、どの情報を残すのかを決めます。

FormBridgeが向くフォームと向かないフォーム

FormBridgeは、kintoneとつながる入力フォームを早く作りたい場面に向いています。

特に、kintoneのユーザーではない人から情報を受け付ける業務と相性がよいです。

向いている用途	理由
問い合わせフォーム	外部からの相談をkintoneの問い合わせ管理へつなげやすい
資料請求・見積依頼	顧客候補、案件、営業担当への振り分けに使える
イベント申込	参加者、同意、支払確認、案内メールの起点にできる
アンケート	回答をkintoneで集計し、顧客や案件に紐づけられる
取引先からの報告	kintoneアカウントを配らず、必要情報だけ受け取れる
社外向け申請	添付、同意、確認ステータスを持たせやすい
社内申請の簡易受付	kintoneにログインしない人からの依頼を受けられる

一方で、FormBridgeだけで完結させない方がよいフォームもあります。

注意が必要な用途	理由
厳密な本人確認が必要な申請	認証、権限、本人性の設計が重くなる
決済や契約を伴う手続き	決済サービス、電子契約、会計との責任範囲を分ける必要がある
大量アクセスが集中する公開申込	待合室、重複送信、締切後処理まで考える必要がある
個人情報や機微情報を扱う受付	保持期間、閲覧権限、削除ルール、同意文言が重要になる
顧客ごとのマイページ更新	kViewerなど公開・認証系サービスとの組み合わせが必要になる

FormBridgeで作れるかどうかだけで判断しない方がよいです。

判断すべきなのは、外部入力を受けた後の責任をkintoneで持てるかです。

フォームは「入力画面」ではなく、社外から社内業務へデータを渡す境界です。境界に確認、権限、ログを置かないと、kintone側のデータ品質が崩れます。

最初に決めるアプリ構成

FormBridge連携で最初に決めるのは、フォームの見た目ではありません。

kintone側でどのアプリに何を置くかです。

アプリ	1レコードの意味	主なフィールド
フォーム受付	1回の送信	受付番号、フォーム種別、送信日時、入力原文、確認状態、重複候補
顧客マスタ	1社、1顧客	顧客コード、正式名称、表示名、顧客区分、担当部署
担当者マスタ	1人	氏名、メール、電話、所属顧客、役割、利用状態
問い合わせ	1件の対応対象	件名、種別、優先度、担当、初回返信期限、状態
案件	1商談、1相談	顧客、流入元、見込み金額、フェーズ、次回アクション
申請	1申請	申請者、申請種別、承認者、差し戻し理由、承認状態
対応履歴	1回の対応	対応日時、対応者、内容、送信先、添付、原本URL
通知ログ	1回の通知	通知種別、送信先、送信結果、エラー、再送状態

小さく始める場合でも、受付アプリと業務アプリは分けます。

受付アプリには、入力されたままの情報を置きます。

業務アプリには、確認済みの情報を置きます。

例えば、問い合わせフォームであれば、次のように分けます。

流れ	置く場所	内容
フォーム送信	受付アプリ	氏名、会社名、メール、本文、添付、同意、受付経路
確認	受付アプリ	スパム判定、重複候補、既存顧客候補、確認者
問い合わせ化	問い合わせアプリ	件名、問い合わせ種別、優先度、担当、返信期限
顧客照合	顧客・担当者マスタ	既存顧客への紐づけ、新規登録、表記揺れ修正
返信	対応履歴、通知ログ	自動返信、個別返信、社内通知、送信結果

受付アプリを挟むと、誤入力や重複を確認してから本データへ渡せます。

逆に、受付アプリを挟まない構成では、フォームの自由入力がそのまま顧客マスタや案件アプリに入ります。

顧客名の表記揺れ、メールアドレスの typo、スパム、同じ問い合わせの再送信が混ざりやすくなります。

フォーム項目とkintoneフィールドを同じにしない

FormBridgeでは、kintoneのフィールドに対応したフォーム項目を作れます。

だからといって、フォーム項目とkintoneフィールドを完全に同じにする必要はありません。

フォームは、入力者に分かる言葉で作ります。

kintoneは、社内が管理しやすいデータ構造で作ります。

フォーム側の考え方	kintone側の考え方
入力者が迷わない項目名にする	集計、検索、通知に使えるフィールド名にする
必要最低限の入力にする	社内確認用の管理項目を持つ
長い説明文で補足する	選択肢やコードで分類する
入力者が選びやすい選択肢にする	業務上の分類に変換する
同意や注意事項を画面に出す	同意日時、同意文言版、取得経路を残す

例えば、フォームでは「お問い合わせ内容」と見せても、kintone側では次のように分けます。

kintoneフィールド	役割
受付本文	入力された原文をそのまま残す
問い合わせ種別	見積、契約、使い方、不具合、その他に分類する
優先度	緊急、重要、通常、保留を社内で決める
確認状態	未確認、確認中、本データ化、破棄を持つ
重複候補	既存問い合わせや顧客の候補を残す
担当部署	営業、サポート、管理、開発などへ振り分ける
返信期限	初回返信の期限を持つ
同意文言版	どの文言に同意したかを残す

フォームで入力させる項目と、社内で管理する項目は別です。

フォーム上では見せない管理項目も必要です。

• 受付番号
• フォーム種別
• 流入元
• 広告キャンペーン
• 同意文言版
• 確認担当
• 重複候補
• 連携ステータス
• エラー内容
• 本データ化した先のレコード番号

これらを受付アプリに持たせると、後から「どのフォームから入り、どう処理されたか」を追えます。

問い合わせ・申請・アンケートでフォームを分ける

FormBridgeでフォームを増やすとき、1つの万能フォームにしない方がよいです。

問い合わせ、申請、アンケート、資料請求では、入力後の業務が違うからです。

フォーム種別	受付後の処理	つなぐアプリ
問い合わせ	種別判定、担当割当、初回返信、対応履歴	問い合わせ、顧客、対応履歴
資料請求	顧客候補登録、営業担当割当、資料送付	顧客、案件、活動履歴
見積依頼	要件確認、案件化、見積作成	案件、見積確認、顧客
申請	申請内容確認、承認、差し戻し	申請、承認履歴、通知ログ
アンケート	回答集計、顧客属性との照合、改善テーマ化	アンケート回答、顧客、改善タスク
イベント申込	参加者管理、案内メール、出欠確認	参加者、イベント、通知ログ

フォームを分けると、入力者に見せる項目を減らせます。

受付後の担当部署や通知も分けられます。

ただし、フォームを分けすぎると、管理できなくなります。

次の管理項目を共通化しておくと、フォームが増えても整理しやすくなります。

共通項目	使い道
フォームID	どのフォームから入ったかを特定する
フォーム版	項目変更前後の回答を区別する
受付番号	社内外の問い合わせ番号として使う
受付日時	期限、集計、通知に使う
入力者メール	重複判定、自動返信、顧客照合に使う
受付経路	Web、QR、メールリンク、広告などを分ける
同意文言版	個人情報や利用規約の同意を追う
処理状態	未確認、確認済み、本データ化、破棄を分ける

フォームごとに自由に項目を作るだけでは、あとから全体の受付状況を見られません。

共通項目を揃えたうえで、用途ごとの項目を追加します。

下書き扱いにする確認フロー

FormBridgeから登録されたレコードは、最初は「下書き」扱いにします。

下書きとは、フォーム入力者が送信したが、社内の業務データとしてはまだ確定していない状態です。

受付アプリには、次のようなステータスを持たせます。

ステータス	意味	次に動く人
未確認	フォームから登録された直後	受付確認担当
確認中	内容、重複、顧客候補を確認中	受付確認担当
差し戻し	入力不足や確認待ち	受付確認担当、入力者
本データ化待ち	問い合わせ、案件、申請へ渡す前	業務担当
本データ化済み	対応対象として登録済み	担当者
破棄	スパム、営業メール、重複など	管理者

この状態管理を入れないと、フォームから入った瞬間に「対応すべき問い合わせ」や「新規案件」として扱われてしまいます。

特に外部フォームでは、次の確認が必要です。

• メールアドレスが正しいか
• 同じ人からの重複送信ではないか
• 既存顧客か新規顧客か
• 営業対象なのか、サポート対象なのか
• 添付ファイルを開いてよいか
• 個人情報の同意を取得できているか
• 返信が必要か
• 期限を持つ対応なのか

確認済みになったら、問い合わせアプリ、案件アプリ、申請アプリへ渡します。

渡し方は、手作業のアクションでも、自動処理でもかまいません。

重要なのは、受付レコードに「どの本データへ渡したか」を残すことです。

受付アプリに残す項目	理由
本データ化先アプリ	問い合わせ、案件、申請のどれに渡したか分かる
本データ化先レコード番号	受付原本と業務レコードを追跡できる
本データ化日時	どれくらい確認に時間がかかったか見える
本データ化担当	誰が判断したか残る
破棄理由	スパムや重複の傾向を確認できる

受付レコードと本データの対応関係を残しておくと、フォーム送信から対応完了までの流れを後から説明できます。

重複防止はフォーム側だけに任せない

FormBridgeの機能ページでは、JavaScriptカスタマイズ例として重複排除にも触れられています。

ただし、重複防止をフォーム側だけに任せるのは危険です。

重複には、いくつか種類があります。

重複の種類	例	対応
送信操作の重複	同じフォームを連続送信	受付番号、送信時刻、メールで判定する
問い合わせの重複	同じ内容を別フォームから送信	本文、メール、会社名、件名で候補を出す
顧客の重複	同じ会社が表記違いで登録	顧客コード、法人番号、ドメインで照合する
担当者の重複	同じ人が部署名違いで登録	メールアドレス、氏名、所属で照合する
案件の重複	同じ見積依頼が複数案件化	顧客、件名、受付日、担当で確認する

フォーム側で完璧に止めるより、kintone側で重複候補を表示し、人が確認できるようにします。

受付アプリには、次のフィールドを用意します。

フィールド	役割
入力者メール	同一人物の候補検索に使う
会社名入力値	表記揺れ確認に使う
会社ドメイン	顧客候補の照合に使う
件名・本文要約	似た問い合わせの確認に使う
既存顧客候補	顧客マスタとの照合結果を残す
既存問い合わせ候補	過去問い合わせとの照合結果を残す
重複判定	新規、重複候補、既存追記、破棄を選ぶ

重複が疑われる場合は、新しい問い合わせを作らず、既存問い合わせの対応履歴に追記します。

顧客情報の場合は、顧客マスタを新規作成する前に既存顧客へ紐づけます。

kintone顧客管理の設計方法でも触れたように、顧客マスタは表記揺れを防ぐための辞書です。

FormBridgeから入った会社名を、そのまま顧客名の正本にしない方がよいです。

担当割当と通知を設計する

フォーム連携でよくある失敗は、自動返信だけを設定して安心することです。

自動返信は、入力者に「受け付けた」と伝えるためのものです。

社内の対応を進めるには、担当割当と通知が必要です。

通知	送る相手	目的
受付通知	受付確認担当	新しいフォーム送信に気づく
不備通知	受付確認担当、必要に応じて入力者	入力不足や確認事項を処理する
担当割当通知	一次担当	対応すべきレコードを知らせる
期限前通知	担当者、上長	初回返信や承認期限の遅れを防ぐ
完了通知	関係者	対応完了や承認完了を共有する
エラー通知	管理者	登録失敗、送信失敗、連携失敗に気づく

担当割当は、フォーム種別、問い合わせ種別、顧客区分、地域、製品、優先度で決めます。

例えば、次のようなルールです。

条件	担当
資料請求	営業担当、またはインサイドセールス
既存顧客からの問い合わせ	顧客担当、またはサポート
請求・契約に関する問い合わせ	管理部門
技術的な不具合	一次サポート、必要に応じて開発
採用応募	採用担当
個人情報削除依頼	管理責任者

このルールを決めずに通知だけ出すと、誰かが見るだろうという運用になります。

FormBridgeの自動返信メールや、kMailerとの連携を使う場合でも、社内の担当割当とは別に考えます。

自動返信は入力者向け。

担当通知は社内向け。

対応履歴はkintone側の正本。

この3つを分けます。

kViewer・PrintCreator・kMailerとのつなぎ方

FormBridgeを使う業務では、トヨクモ系サービスを組み合わせることがあります。

代表的には、kViewer、PrintCreator、kMailerです。

サービス	役割	設計上の注意
FormBridge	外部入力を受け付ける	入力原本、同意、受付番号を残す
kViewer	kintoneデータを外部へ公開する	公開範囲、認証、見せる項目を絞る
PrintCreator	kintoneデータから帳票を出す	帳票に使う確定データと下書きを分ける
kMailer	メール送信、自動返信の拡張	送信内容、送信結果、再送ルールを残す

ここで重要なのは、どのサービスを使うかではありません。

外部から入る、社内で確認する、外部へ返す、帳票として出す、という流れを分けることです。

流れ	使うもの	正本
入力を受ける	FormBridge	受付アプリ
顧客に見せる	kViewer	公開用ビュー、公開対象レコード
書類にする	PrintCreator	確認済みの業務レコード
メールを送る	FormBridge自動返信、kMailer	対応履歴、通知ログ
社内で処理する	kintoneプロセス管理、通知	問い合わせ、案件、申請

例えば、イベント申込であれば、FormBridgeで申込を受け、kintoneの受付アプリで確認し、kViewerで参加者向けの案内ページを出し、kMailerで参加案内を送る構成が考えられます。

申請業務であれば、FormBridgeで申請を受け、kintoneで承認し、PrintCreatorで控えや証明書を出す構成があります。

このとき、FormBridgeで受けた直後のデータから帳票を出すと、未確認の誤入力がそのまま書類になります。

帳票や公開に使うのは、確認済みの業務レコードに限定します。

権限と個人情報の扱い

外部フォームでは、kintone内部だけのアプリよりも権限と個人情報に注意が必要です。

入力者はkintoneユーザーではありません。

そのため、フォーム上でどの情報を集めるか、kintone側で誰が見られるか、いつ削除するかを決めます。

論点	設計すること
入力項目	目的に必要な情報だけを集める
同意文言	個人情報の利用目的、問い合わせ対応、第三者提供の有無を明記する
同意の記録	同意日時、同意文言版、受付番号を残す
添付ファイル	受け付ける形式、容量、確認担当、保管期間を決める
閲覧権限	受付担当、業務担当、管理者で見える範囲を分ける
削除・保管	不採用応募、キャンセル、期限切れデータの扱いを決める
エラー時	登録失敗、通知失敗、再送、手動対応の手順を残す

フォームに入力された情報は、入力者にとっては送信した瞬間に会社へ渡した情報です。

社内では、未確認データとして慎重に扱う必要があります。

特に添付ファイルを受け付ける場合、確認担当、保存先、開封ルール、削除ルールを決めます。

問い合わせフォームなら比較的軽くても、採用応募、本人確認書類、契約関連資料を受ける場合は設計を重くします。

フォーム変更に強い運用にする

FormBridgeのフォームは、業務に合わせて変更しやすいのが利点です。

ただし、フォーム項目を気軽に変えすぎると、kintone側の集計や通知が壊れます。

フォーム変更では、次の情報を残します。

管理項目	目的
フォーム版	どの項目構成で送信されたか分かるようにする
変更日	変更前後の回答を区別する
変更理由	何のために項目を追加・削除したか残す
影響範囲	通知、帳票、集計、公開ページへの影響を見る
テスト結果	送信、登録、通知、返信、帳票の動作を確認する
戻し方	失敗時にどの設定へ戻すか決める

フォーム項目を追加したら、kintoneの受付アプリだけでなく、次の場所も確認します。

• 一覧や絞り込み
• プロセス管理
• 通知条件
• 自動返信メール
• 対応履歴のテンプレート
• 帳票テンプレート
• kViewerの公開項目
• 集計グラフ
• CSV出力

フォームは入口なので、変更の影響が広がりやすいです。

小さな文言修正なら軽く済みますが、選択肢や必須項目、同意文言、添付項目の変更は業務フロー全体で確認します。

よくある失敗パターン

FormBridgeとkintoneの連携でよくある失敗を整理します。

失敗	起きること	対策
フォームから本アプリへ直接登録する	誤入力や重複が顧客、案件、問い合わせに混ざる	受付アプリで確認してから本データ化する
フォーム項目を増やしすぎる	入力率が下がり、途中離脱が増える	入力者向け項目と社内管理項目を分ける
同意文言を残さない	いつ何に同意したか説明できない	同意日時、文言版、受付番号を残す
自動返信だけで運用する	社内の担当者が動かない	担当割当、期限、社内通知を別に設計する
重複を止めない	同じ顧客、同じ問い合わせが増える	顧客候補、問い合わせ候補を受付時に確認する
添付ファイルの扱いを決めない	保存先、閲覧範囲、削除ルールが曖昧になる	添付の種類、確認担当、保管期間を決める
フォーム変更の履歴がない	どの回答がどの項目構成か分からない	フォーム版と変更履歴を残す
帳票や公開に未確認データを使う	誤情報が顧客に見える	確認済みレコードだけを出力対象にする

特に多いのは、「フォームを増やしたら業務が整う」と考えることです。

フォームが増えるほど、受付、確認、振り分け、通知、返信、公開の設計が重要になります。

最小構成で始めるなら

最初から大きく作る必要はありません。

問い合わせフォームを例にすると、最小構成は次の程度です。

構成	内容
FormBridge	氏名、会社、メール、問い合わせ内容、同意、添付を受け付ける
受付アプリ	入力原文、確認状態、重複候補、確認者を管理する
問い合わせアプリ	件名、種別、担当、期限、状態を管理する
顧客マスタ	既存顧客や新規顧客を整理する
対応履歴	返信、電話、社内確認、差し戻しを残す
通知	受付通知、担当割当通知、期限前通知を出す

この構成なら、フォームから入った内容をすぐに対応対象へできます。

同時に、誤入力や重複を確認する余地も残せます。

次に、必要に応じて追加します。

追加するもの	追加するタイミング
kViewer	顧客向けに状況や結果を見せたいとき
PrintCreator	受付票、申請書、証明書、控えを出したいとき
kMailer	自社ドメインでの返信や一括案内を整えたいとき
案件アプリ	資料請求や見積依頼を営業管理へつなげたいとき
申請アプリ	承認、差し戻し、証跡を持たせたいとき
連携ログ	通知、登録、帳票、公開の失敗を追いたいとき

kintone案件管理の設計方法でも整理したように、案件化するデータは顧客、活動履歴、見積とつながる必要があります。

FormBridgeからの入力は、その起点として扱います。

Bitlightに相談できること

Bitlightでは、FormBridgeのフォーム作成だけではなく、kintone側の業務設計まで含めて整理できます。

例えば、次のような相談に対応できます。

• 問い合わせフォームをkintoneの対応管理へつなげたい
• 資料請求や見積依頼を顧客管理、案件管理へつなげたい
• 既存のFormBridgeフォームが増えすぎて整理できない
• フォームから登録された顧客や問い合わせの重複を減らしたい
• 自動返信、担当通知、期限通知を整理したい
• kViewer、PrintCreator、kMailerとの役割分担を決めたい
• 外部フォームの個人情報、添付、同意文言の扱いを見直したい
• 受付アプリ、本データ、対応履歴の分け方を設計したい

FormBridgeは、kintoneに外部入力を入れる強い入口になります。

ただし、入口だけを作っても、業務データは整いません。

受付アプリで外部入力を受け、確認してから問い合わせ、顧客、案件、申請へ渡す。

担当割当、通知、返信、公開、帳票までつなげる。

この設計にしておくと、フォームが増えてもkintone側のデータ品質を保ちやすくなります。

FormBridgeはフォーム作成ツールとして見るより、社外入力をkintone業務へ接続する入口として設計する方が、長く使える構成になります。