この参考モデルの位置づけ
kintone は中小企業の業務システム化の入り口として広く普及していますが、そのままでは「対外向けの体験」が限定的です。会員が自分でログインして予約する画面、注文履歴を確認する画面、といったカスタマー向け UX を kintone の標準機能だけで作るのは難しく、無理に JavaScript カスタマイズで実現しようとすると保守費が跳ねます。
一方で、kintone を全部やめて自社スクラッチに乗り換える判断は、社内業務が既に kintone に乗っている状況ではハードルが高すぎます。この中間解として現実的なのが、kintone を残して社内業務のデータ基盤として使い続けつつ、社外向けのフロントだけを Next.js で作るフロント補完型のアーキテクチャです。本記事はその参考実装モデルを、AI 駆動開発のクリエイティブスタジオが整理したものです。
kintone と自社スクラッチの分岐点や、組み合わせ 3 パターンの全体像は kintone 開発費用と自社開発の判断軸 にまとめています。本記事はその中の「フロント補完型」に絞って、具体的な構成に踏み込みます。
フロント補完型が向く 3 つの状況
このアーキテクチャが最適解になるのは、次の 3 つの状況が重なるときです。
- 社内業務が kintone で回っている。顧客管理、予約、在庫、案件進捗などが kintone アプリで管理されており、業務担当者は kintone の画面を日常的に使っている。
- 社外向けの UX が限定的または存在しない。会員が自分で予約する、注文履歴を確認する、といった対外画面が kintone のポータル機能では実現しづらいか、UX が業務用途に留まっている。
- kintone をやめる予算と期間が確保できない。全業務を自社スクラッチにするフル刷新は経営判断のハードルが高く、まずは対外体験の改善から効果を出したい。
この 3 つが揃うとき、kintone を残しつつ社外向けだけ切り出す構成が、費用対効果とリスクの両面で最適解になります。
参考アーキテクチャの全体像
構成は次の 4 層で組み立てます。
- kintone 層 (既存): 顧客・予約・注文などのデータ管理。業務担当者は kintone の画面で日常業務を継続。
- kintone REST API 層: kintone が公開する REST API で、外部システムからのデータ読み書きを提供。認証は API トークンまたは OAuth。
- エッジ / バックエンド層: Cloudflare Workers または Hono で、kintone REST API を叩く BFF (Backend For Frontend) を配置。会員認証、キャッシュ、レート制限をここで処理。
- フロント層: Next.js で会員ポータル・予約・小規模 EC の画面を構築。認証は Auth.js または Cloudflare Access で kintone とは独立した会員認証を組む。
認証は kintone のゲストスペースを使わない。kintone のゲスト機能を対外会員認証に流用すると、ライセンス費が跳ね、UX の自由度も限定されます。会員側の認証は Auth.js などで独立させ、認証成功後に kintone REST API を BFF 経由で叩く構成にします。
kintone REST API を叩くパターン 3 種
BFF から kintone REST API を叩くパターンは、業務の性質で使い分けます。
1. 参照専用 (会員照会・履歴表示)
会員が自分の情報や過去履歴を照会する画面は、kintone REST API の GET エンドポイントで十分です。Next.js の Server Component から BFF 経由でリクエストし、SSR で描画します。
- 頻度が高い場合は BFF に Cloudflare KV でキャッシュを持たせ、kintone 側のレート制限 (プランごとに 1 秒あたり 10 リクエスト前後) を回避
- 会員 ID をキーにキャッシュキーを構成し、更新時は BFF から明示的にキャッシュ削除
2. 書き込み (予約作成・注文投入)
会員が予約したり注文したりする画面は、kintone REST API の POST/PUT エンドポイントで kintone 側にレコードを作成します。
- 書き込み処理はサーバー側の Route Handler で実施し、フロント側から直接 kintone へアクセスさせない
- 成功後は kintone のレコード ID を BFF から取得し、フロント側で予約番号として表示
3. 非同期処理 (メール送信・在庫更新)
予約や注文の直後に、確認メール、在庫更新、CRM 通知、といった副次処理が発生します。これを同期的に処理するとフロントの応答が遅くなるため、kintone の Webhook を Cloudflare Workers で受けて非同期化します。
- kintone アプリで「レコード追加時」の Webhook を Cloudflare Workers のエンドポイントに向ける
- Workers 側でメール送信 (Resend、SendGrid)、在庫更新 (kintone REST API 別アプリ)、CRM 通知 (Salesforce、HubSpot) を並列実行
- リトライは Workers Queues で 3 回まで自動、失敗時は kintone の別アプリに「未処理キュー」として蓄積して業務担当が確認
Feature Flag と段階リリースの設計
kintone を残す前提でも、フロント側は段階的にリリースします。既存の kintone 画面での運用と、新しい Next.js 画面での運用を、会員セグメントごとに切り替える構成にします。
- 会員テーブルに
experimentalフラグを持たせ、対象会員は新画面を使う運用 - BFF 側で会員 ID を見て、experimental フラグが立っている会員には Next.js 画面、それ以外には kintone のポータル画面 (または新画面の read-only 版) を返す
- 段階的に experimental フラグの ON 対象を広げていく (10% → 25% → 50% → 100%)
参考期間と費用レンジ
kintone フロント補完型の参考レンジは次のとおりです。
- 期間 — 2〜4 ヶ月 (要件定義 2〜3 週間、実装 6〜10 週間、リリース準備 2〜3 週間)
- 費用 — 400 万〜1,200 万円 (税抜)
規模を左右する変動要因は次のとおりです。
- 対外画面の数 (会員ポータル 1 画面 vs 予約 + EC + 履歴 + マイページの 5 画面以上)
- kintone アプリの複雑さ (単一アプリを参照 vs 複数アプリを組み合わせて表示)
- 非同期処理の種類 (メールのみ vs メール + CRM + 在庫 + 会計)
- 認証要件 (メール認証だけ vs SSO 統合 vs 決済連携)
同じレンジで従来開発するより、AI 駆動開発で 1/2 〜 2/3 の期間に圧縮できるのがこの構成の利点です。
リリース後の運用と、中核系への発展余地
フロント補完型のリリース後、次に検討できる発展形が 3 つあります。
- バックエンド補完型への拡張 — 分析基盤や帳票出力を Next.js 側に持たせ、kintone の標準機能ではできない集計を実装
- 機能特化型への段階移行 — 業務の一部 (受注や請求) を Next.js 側に移し、kintone は残りの業務システムとして継続
- フル刷新の判断 — 3 年後、kintone の月額とカスタマイズ費が積み上がり、Next.js 側で全業務を扱えるようになった段階で、kintone を停止する判断
いずれの発展形も、フロント補完型で得た構成 (BFF、認証、CDC 相当のデータ同期) がそのまま使い回せます。
kintone 連携の開発ご相談
「kintone は残したいが、対外体験を改善したい」「会員ポータルや予約画面を Next.js で作りたいが、kintone との連携設計が分からない」といった状況こそ、AI 駆動開発で設計と実装を加速できる領域です。まずは AI 駆動開発のサービス内容 をご覧いただき、お問い合わせ からお気軽にご相談ください。