kViewerやFormBridgeを使ってログインが必要なサイトを構築している中で、kintoneのWebhook上限問題に引っかかっていませんか？
最初は問題なく動いていたはずなのに、ページや機能が増えてくると、Webhookの数が足りなくなってくる——
このあたりで一度は悩んだことがある方も多いと思います。
この記事では、この制約を回避する現実的な設計パターンとして、
Makeを使ったWebhook集約の方法を紹介します。
kintoneユーザの皆様のご参考になれば幸いです。
ログインが必要なサイトをkViewerとFormBridgeで作成する際に発生する問題点
kViewerとFormBridgeで作成したページにログイン制限を設ける場合、
必然的にkintone側のユーザ情報と同期する設定を行うことになります。
この設定は、
kViewer・FormBridgeそれぞれのページ単位で行う必要があります。
このとき、ユーザ同期の手段は以下の2つです。
- 1日1回、指定時間にユーザ同期する方法
- Webhookをトリガーとして、ユーザ同期を行う方法
kintoneに新規でログインユーザを追加した際、
ユーザ同期が行われる前にアクセスすると、そのユーザはページを閲覧できません。
そのため、基本的な実装としては、
ユーザ追加のタイミングでWebhookを使って即時同期する
という形になります。
kintoneのWebhookは10個まで
kViewerとFormBridgeで構成したサイトは、一般的に以下のような構造になります。
- kViewer：A機能の一覧ページ
- FormBridge：A機能の登録画面
- FormBridge：A機能の編集画面
- kViewer：A機能で使用するAPI
- kViewer：B機能の一覧ページ
- FormBridge：B機能の登録画面
- FormBridge：B機能の編集画面
サイトが小規模であれば問題ありませんが、
ページ数が増えてくるとすぐに限界が見えてきます。
kintoneでは、Webhookは1アプリにつき10個までしか設定できません。
そのため、
ユーザ追加のたびに、すべてのページをリアルタイム同期することができない
という状態になります。
結果としてどうなるかというと、
- 一部のページはすぐ使える
- 一部のページは次のバッチ同期まで使えない
という状態になります。
これは利用ユーザからすると、
「ログインできたのにページが見れない」
「権限はあるはずなのに表示されない」
といった、かなり分かりづらい挙動になります。
設定の問題ではなく、構造的に発生する問題です。
Makeを使った解決方法について
そこでおすすめしたいのが、iPaaSのMakeを使った方法です。
Makeは、ノーコードでクラウド上にワークフローを構築し、自動実行できるサービスです。
MakeにはWebhookを受信する機能があり、
kintoneから送られてきたデータをトリガーに処理を開始できます。
さらに、受け取ったデータを元に、複数のAPIやWebhookへ再送することが可能です。
この構成により、サーバーやコードを書かずにWebhookの中継・分岐を実現できます。
Makeについて詳しく知りたい方は、以下の記事で紹介していますのでご参照ください。
Make(旧:integromat)の紹介とアカウント登録の手順について
構成イメージ
この構成にすると、
同期先が増えても、kintoneのWebhook設定は増えません。
Webhook上限の影響を受けずに、すべてのページをリアルタイム同期できるようになります。
構築手順について
実際の設定手順は、こちらの記事で解説しています。
➡️ kintone×MakeでWebhookを中継する手順【ノーコードで構築】
MakeはFreeプランがあり、ここで紹介している仕組みは無料で運用をスタートできます。
興味のあるかたは是非ご覧下さい。
Makeを使うメリット
- Webhook数を節約できる：kintone側では1本だけ使えばよくなります。
- ノーコードで分岐・連携ができる：GASやNode.jsを書かなくても、GUIで構築できます。
- 後から拡張しやすい：新しい連携を追加しても、kintone側は変更不要です。
- 構造が整理される：「どこで何をしているか」がMake上で可視化されます。
まとめ
kViewerやFormBridgeでログインサイトを構築する場合、
ユーザ同期の仕組みは避けて通れません。
そしてその中で、Webhook上限によってリアルタイム同期が制限されるという問題が発生します。
このとき重要なのは、
「Webhookを増やす」のではなく
「Webhookの入口を1本にする」
という考え方です。
Makeを使えば、この構成をノーコードで実現できます。
ログイン直後に「見れない」状態をなくすためにも、最初からこの形で設計しておくと、後々の運用がかなり楽になります。
kintoneのWebhook上限でお困りの方は、是非Makeの活用を検討してみてください。
