FormBridgeとkintoneを連携して事務処理を自動化。フォーム入力の先をn8nでつなぐ方法を紹介！

FormBridgeを入れれば社外入力はkintoneで完結する、と思っていないか

協力会社や現場から届く報告を、FormBridgeで受けてkintoneにまとめたい。

外注先からの進度の報告、検収の可否、現場で起きたクレームの一次受け。こうした社外からの情報こそ、手元のkintoneにそのまま入ってきてほしい。そう考えるDX推進の担当者は、私たちが話を聞くなかでも珍しくありません。

ところが、協力会社や現場の担当者全員に、kintoneのアカウントをわたすことはできません。ライセンスの費用も、社外の人にアカウントを配る運用上のハードルもあるからです。

結局、報告はメールや電話で受けて、こちらが手でkintoneに打ち直す。そんな運用が、いまも職場に残っているケースがあります。

この課題の受け皿として名前が挙がるのが、FormBridge（フォームブリッジ）です。トヨクモが提供するkintone連携サービスで、kintoneのアカウントを持たない社外の人でも、公開フォームから入力するだけでkintoneにデータを登録できます。

ひとつ、確かめておきたいことがあります。

「FormBridgeを入れれば、社外からの入力はkintoneに取り込めて、それで完結する」と思っていないでしょうか。

そう考えていた場合、導入後に「思っていたのと違う」と気づくことになります。「FormBridgeとkintoneは何が違うのか」と改めて調べ直す人がいるのも、この境界が分かりにくいからです。

FormBridgeが引き受けてくれるのは、あくまで「フォームから受けて、kintoneに保存する」ところまで。その先の処理は、フォームだけでは動きません。

FormBridgeは保存まで。保存の先はn8nを挟めば担当アサイン・通知まで自動で流せる

先にお伝えする結論はこうです。

FormBridgeが担うのは「フォーム入力をkintoneに保存する」ところまでです。保存されたあとの担当者の割り当て、担当者への通知、他システムへの連携といった「受付後の処理」は、n8nというワークフロー自動化ツールを間に挟むことで自動で流せます。

社外の人がフォームに入力する。kintoneにレコードが保存される。そこからn8nが受け取り、内容に応じた担当者へ割り当て、名指しで通知し、必要な二次処理まで走らせます。この一連の流れを、人の手を介さずにつなげられるのです。

FormBridgeとkintone連携の役割分担図。FormBridgeは保存まで、n8nが保存後の担当割り当て・通知・二次処理を担う流れ

大がかりな開発をSIerに発注する話ではありません。「保存されたあとに何をするか」をワークフローとして組む、という発想の転換です。なぜこの構成に価値があるのか、そして実際にどこが手作業として残るのかを、順を追って見ていきます。

全員にkintoneライセンスは配れない。FormBridgeは保存まで、その先は残る

kintoneはユーザー単位のライセンスで使う仕組みです。社内のメンバーには配れても、外注先や現場の協力会社まで含めた全員にアカウントを用意するのは、費用の面でも運用の面でも現実的ではありません。

だからこそ、kintoneのアカウントを持たない人に入力してもらう窓口として、公開フォームが要ります。FormBridgeは、この窓口の役割を確かに果たします。

情シスやDX推進の担当者は、社外から届く報告を、社内の複数部門へ振り分ける立場にあります。受けた報告を、承認フローに乗せたり、担当部署へ転送したり。その入り口を整えるのが、フォームという受け皿です。

ただし、FormBridgeが引き受けるのは「フォーム入力を受けて、kintoneのレコードとして保存する」ところまでです。保存されたレコードを見て、誰が対応するかを決め、担当者に知らせ、別のシステムに転記する。こうした保存後のロジックは、フォーム単体では持っていません。

「入れれば完結する」と見えていたのは、保存までの部分しか見えていなかったからです。ここから先、受付後の処理が手作業のまま残ると、社外入力は「受けて終わり」の状態から抜け出せません。

なお、n8nがそもそもどんなツールなのかは、別記事の【超入門】n8nとは？kintoneと生成AI連携のはじめかたで解説しています。この記事では基礎には立ち入らず、「FormBridgeで受けた後をどう流すか」に絞って進めます。

FormBridge単体で受けており、kintoneに保存した「その先」は全部手作業だった

自社のホームページの問い合わせフォームとして、FormBridgeを単体で使っている会社は多いでしょう。Formbridge単体ではフォームからの「登録」までは自動化できていました。しかし、そこから先の業務フローが、まるごと手作業に依存しやすくなります。

これは自社の問い合わせフォームでの話です。ですが、社外の非ライセンス者がFormBridgeで入力し、kintoneに保存されるという構造そのものは、協力会社からの進度の報告でも、検収やクレームの一次受けでも変わりません。どんな内容を受けるにせよ、「保存の先が手作業で残る」という同じ壁に突き当たります。

実際にどこで手を動かし続けていたのか、受付の流れに沿って開示します。

FormBridgeで保存した後に残る4つの手作業。目視の仕分け、画一的な通知、優先度づけの欠落、転記や一次返信の手作業

受けた内容を人が目で見て仕分けし、担当者フィールドを手で更新していた

まず、届いた内容を人が1件ずつ目で見て、種類を判別していました。

問い合わせフォームであれば「料金について」「サービス導入」「協業・採用」といった種類を、届くたびに読んで振り分けます。これが外注先からの報告であれば「進度」「検収」「クレーム」といった種類に相当します。

判別したうえで、kintoneの担当者フィールドを手で更新し、営業・カスタマーサポート・管理部門といった担当先へ、個別に引き渡していました。内容を読み、送り先を決め、フィールドを直す。この一次仕分けが、届くたびに発生していたのです。

「新規登録がありました」だけの通知では、誰宛ての案件か分からず初動が遅れた

通知にも課題がありました。kintoneの通知やチーム全体宛てのチャット通知は、私たちの運用では「新規登録がありました」という画一的な知らせにとどまりがちでした。誰に向けた案件なのかが、ひと目では分かりません。

結果として、各メンバーの確認は後回しになり、未読のまま埋もれてしまうこともありました。通知は届いているのに、初動が遅れる。これが、受付を「流れ」にできていないことの分かりやすい症状でした。

至急案件も大口クライアントも、一般の連絡と同じ列にフラットに並んでいた

緊急度や重要度に応じた扱い分けも、できていませんでした。「至急で見積もりが欲しい」という連絡も、既存の大口クライアントからの相談も、一般的な連絡とまったく同じ列にフラットに並びます。優先度をつけた即時のメンションや、上長へのエスカレーションといった動きが取れません。

本来なら真っ先に動くべき案件が、ほかの連絡に埋もれてしまう。そのリスクを、運用でカバーし続けていました。

別システムへの転記や集計、種別ごとの一次返信まで、都度コピペで回していた

受付にともなう付帯作業も、手で回していました。kintoneにレコードが作られたあと、商談管理用の別システムへ転記したり、リード情報を更新したり、集計用のスプレッドシートに書き写したり。こうした作業を、そのつどコピー&ペーストでこなしていました。

一次返信にも、私たちの運用では手作業が残っていました。問い合わせの種類ごとに案内する資料のURLを変える。営業時間外だけ夜間用のメッセージを差し込む。こうした条件による出し分けを、標準の自動返信の設定だけでまかなおうとすると難しく、結局は個別に返信していたのです。

この「登録までは自動、その先は全部手作業」という状態が、n8nを組み合わせる前に私たちが向き合っていた現実でした。

保存後の振り分け・通知・二次処理を、n8nのワークフローに任せる

保存されたあとの手作業は、n8nに引き受けさせます。kintoneに保存されたレコードをn8nが受け取り、内容に応じた処理を順番に走らせます。前の章で挙げた4つの手作業に、それぞれ対応する形で設計していきます。

受信内容から担当を自動で振り分け、kintoneの担当者フィールドを自動更新する

一次仕分けは、n8nに任せます。フォームの回答に含まれる種類や本文のキーワードをもとに、どの担当が対応すべきかをn8nが判定。判定した担当者を、kintoneのレコードの担当者フィールドへ自動で書き込みます。人が1件ずつ読んで振り分けていた作業が、レコードが保存された時点で片づく形になります。

宛先と要点を含む通知を、担当者へ名指しで自動配信する

通知は、宛先と要点をのせた形に変えます。「新規登録がありました」という画一的な知らせではなく、「誰に向けた・どんな内容の案件か」を含んだ通知を、担当者へ名指しで自動配信します。

配信先は、SlackやTeams、メールなど、ふだん確認している場所にあわせられます。通知を見た瞬間に「自分の案件だ」と分かるので、初動の遅れを抑えられるのです。

緊急度・重要度で経路を分け、至急案件は即時エスカレーションする

優先度のつけ方も、ワークフローに組み込みます。内容に「至急」の要素があるか、相手が大口の取引先かといった条件で、n8nが経路を分けます。急ぎの案件は通常の列に並べず、担当者や上長へ即時にエスカレーションする経路へ流す設計です。真っ先に動くべき案件が、ほかの連絡に埋もれない仕組みです。

転記・集計・条件分岐した一次返信を、ワークフローにまとめて自動化する

付帯作業と一次返信も、まとめて引き受けさせます。外部システムへの転記や集計表への書き込みといった二次処理を、n8nのワークフローに集約します。

一次返信についても、問い合わせの種類ごとに案内する資料を変えたり、時間帯に応じてメッセージを差し込んだりと、条件によって中身を出し分けられます。手作業のコピー&ペーストや個別返信に費やしていた時間を、丸ごと自動化に置き換えられるのです。

なお、n8nでkintoneや外部システムをつなぐときは、認証情報の扱いなどセキュリティの設計も欠かせません。この点はn8nとkintoneを安全に連携！n8nの強力なセキュリティの仕組みを解説で詳しく触れています。

組むのは「保存の先」だけ｜n8nワークフローの全体像と、要点になる4つの設定

ここまでは「保存の先に何を組むか」という設計の考え方をお伝えしてきました。ここからは、私たちが実際にn8nで組んだワークフローを見ながら、全体像と、要点になる設定を4つに絞ってお見せします。

設定を一つずつ細かく追う必要はありません。**「どのノードが、前の章のどの手作業を引き受けているのか」**という対応さえつかめれば、自社で組むときの見取り図になります。

bm131-ss-01-overview

全体は、kintoneにレコードが保存されたことを受け取る入り口から始まり、そこから担当の振り分け・通知・経路の分岐・一次返信へと、一本の流れでつながっています。前の章で挙げた4つの手作業が、そのままノードに置き換わっている、と見てもらうと把握しやすいはずです。

要点1：kintoneへの保存をきっかけに動かす「入り口」の設定

bm131-ss-02-trigger

ワークフローの起点は、「kintoneにレコードが保存された」という出来事を受け取る設定です。FormBridgeから保存が走った瞬間に、この入り口が反応して、後続の処理が動き出します。ここが、社外の入力とn8nの処理をつなぐ結び目になります。

要点2：受信内容から担当を判定する「振り分け」の設定

bm131-ss-03-switch

受け取ったレコードの内容を見て、どの担当が対応すべきかを判定する部分です。フォームの回答に含まれる種類や本文のキーワードを条件にして経路を分け、判定した担当者をkintoneの担当者フィールドへ書き戻します。人が1件ずつ読んで振り分けていた作業に対応する設定です。

要点3：宛先と要点をのせて名指しで届ける「通知」の設定

bm131-ss-04-notify

通知は、「新規登録がありました」だけの画一的な知らせから、「誰に向けた・どんな内容の案件か」を含んだ形に変えます。差し込む宛先や要点は、前の振り分けで判定した結果を受け取って組み立てます。配信先は、SlackやTeams、メールなど、ふだん確認している場所に合わせられます。

要点4：緊急度で経路を分け、条件で一次返信を出し分ける設定

bm131-ss-05-branch

最後は、優先度づけと一次返信をまとめて引き受ける部分です。「内容に『至急』の要素があるか」「相手が大口の取引先か」などといった条件で経路を分け、急ぎの案件は即時のエスカレーションへ流します。あわせて、問い合わせの種類ごとに案内する資料を変えたり、時間帯に応じてメッセージを差し込んだりと、一次返信の中身も条件で出し分けます。

社外入力を「受けて終わり」から「流れる業務」に変える

実際に使ってみて分かったのは、FormBridgeは単体で使うよりも、n8nでkintoneと組み合わせたほうが使い勝手が良い、という手応えでした。

FormBridgeが担うのは、社外・非ライセンス者の入力をkintoneに保存するところまで。その保存の先、つまり担当の割り当て・通知・二次処理をn8nが受け持つ。この役割分担で、社外からの入力は「受けて終わり」の状態から、「受付後が自動で流れる業務」へと変わります。

社外入力の運用のビフォーアフター図。受けて終わりの手作業状態から、n8nで受付後が自動で流れる業務へ変わる対比

大切なのは、手作業として残る場所が、はっきりと数えられるという点です。私たちの場合は、仕分け・通知・優先度づけ・付帯処理という4か所でした。詰まる場所がどこか分かっていれば、そこにワークフローをあてていくだけです。

これはSIerに大がかりな開発を発注する案件ではなく、保存の先をどう組むかという設計の話です。発想を切り替えれば、自社の手でも十分に実現できます。

最後に

ライブAI開発の案内

株式会社アディエムでは、kintone × 生成AIで日々の業務改善に取り組んでいます。
今回ご紹介したような例の他にも、お客様の業務に合った改善をご提案させて頂きます。
無料相談も実施しておりますので、お気軽にお問い合わせ頂ければ幸いです。

お問い合わせはこちら

関連記事