Readdyで顧客サイトのデータを扱う｜保存先・アクセス権限・外部連携(2026)

要点

顧客サイトにデータの保存とサーバー処理を組み込む場合、Readdyでは内蔵のバックエンド機能を使う方法と、Supabaseと連携する方法を選べます。2026年11月時点では内蔵のバックエンドはスタータープラン以上、顧客向け環境を自社ブランドにするホワイトラベルは代理店プロプラン以上が対象です。

業務で使うデータ連携は、接続ができることに加え、保存した情報を誰が扱い、失敗した処理をどう再開するかまで決めると構成が明確になります。ここでは、問い合わせや会員向けの情報を扱うサイトを想定し、Readdyで用意できる機能と設計する項目を紹介します。

新しい保存先を用意するか、Supabaseを使うかを選ぶ

Readdyのバックエンド機能には、データベース、サーバー関数、APIキーなどの機密情報を管理する仕組みがあります。別のバックエンドサービスを先に契約せず、サイトのデータと処理をReaddy内で組み立てたい場合に使えます。

Supabaseを使う場合は、Readdyと連携することで、対象プロジェクトのデータベースや認証などを利用できます。一つのReaddyプロジェクトでは、内蔵のバックエンドかSupabaseのどちらかを使う構成になるため、保存先を決めてから実装を進めましょう。

構成	始めるときに用意するもの	採用前に見ておく点
Readdyのバックエンド機能	対象プランと、保存する項目・処理の設計	内蔵機能で必要な仕事を実装できるか
Supabaseとの連携	Supabaseのアカウントと対象プロジェクト	既存のデータ構造、認証、権限との適合
外部の業務システムへの送信	接続先のAPI仕様と認証情報	送信条件、制限、失敗時の扱い

既存の保存先がある案件では、残すデータ、移すデータ、接続先で行っている処理を先に洗い出します。接続機能があることと、現在の業務をそのまま引き継げることは別なので、必要な画面とデータの読み書きを実際に確かめます。

入力から業務完了まで、記録する情報を決める

保存項目は、入力された値と、その後の対応に必要な情報を合わせて決めます。資料請求なら、氏名や連絡先に加え、どの請求を処理しているかを識別する番号や、対応状況を持たせる設計が考えられます。

たとえば外部の顧客管理システムへ送る場合は、「受付済み」「外部への登録待ち」「登録完了」などの状態を設計できます。これは案件ごとに実装する処理の例です。Readdyに業務用の再送管理が自動で用意されると考えず、状態を更新する条件と、担当者が確認する方法を決めてください。

同じ入力が届いたときの扱いも決めておくと、送信結果が分からない場面に対応できます。通信が切れた後は、受付番号や接続先の記録を照合してから再処理する形にすれば、何が完了しているかを調べられます。

ログインと、見られる記録の範囲を分けて設計する

利用者ごとのデータ制限には、認証とアクセス権限の両方が必要です。Readdyのバックエンドでは、ログイン済みの利用者に権限を与えるだけでは、その人自身の記録だけに読み書きを限定できません。

データへのアクセス制御では、行単位でアクセスを制限する仕組みを使い、必要な利用者が必要な記録を扱えるようにします。たとえば会員向けの申込履歴なら、別の会員でログインしても他人の履歴が表示されないことを試しましょう。

制作環境の閲覧者・編集者と、公開サイトにログインする会員は、異なる対象です。顧客企業の担当者が制作に参加する権限と、サイト利用者がデータを扱う権限を分けて一覧にすると、設定する場所と確認する操作が明確になります。

外部連携は、接続先の結果まで確かめる

Readdyのサーバー関数では、サイトの裏側で動く処理を組み立て、機密情報を管理する仕組みと組み合わせられます。外部APIを使う案件では、接続先で必要な認証や送信形式を調べ、秘密の値が公開ページのコードに出ない構成にします。

検証では、正常な送信だけでなく、必須項目が足りない場合や、接続先が応答しない場合も扱います。画面に受付完了が出た後も、保存先の値と外部システムの結果を照合し、どこまで終わったかを判断します。

試す場面	見る結果	決めておく対応
正常な入力	保存値と外部の登録結果	完了を示す条件
同じ依頼の再送	記録や外部処理の重複	既存結果の照合方法
別の利用者での操作	閲覧・更新できる記録	拒否すべき操作
通信の中断	保存と外部登録の状態	再処理の判断と担当

公開後の保守には、エラーを受け取る窓口、状況を調べる担当、接続先への問い合わせ先を含めます。データベースを選ぶときは、実装だけでなく、この対応を続けられる構成かも採用条件にしてください。

よくある質問

問い合わせ内容を保存するために、別のデータベースサービスが必要ですか？

Readdyの内蔵バックエンドを使えば、別のサービスを契約せずにデータベースとサーバー処理を用意できます。スタータープラン以上が対象です。フォームの項目と保存処理を設定し、入力内容が記録されるところまで試してから公開します。

すでにSupabaseにあるデータを利用できますか？

Readdyでは、Supabaseのアカウントを認証し、対象のプロジェクトを選んで連携できます。必要なデータを読み書きできるか、既存の権限や認証と合うかを確認します。内蔵バックエンドとの同時利用はできないため、案件で使う保存先を決めましょう。

会員登録を付ければ、他人のデータは見えなくなりますか？

会員登録に加えて、記録へのアクセスを制限する設定が必要です。ログイン済みという条件だけで、自分の記録だけに限定されるわけではありません。行単位のアクセス制御を設計し、異なる会員からの閲覧と更新を検証します。

顧客が使う業務システムへ、自動で情報を送れますか？

接続先のAPIと認証が利用できる場合に、サーバー関数などで送信処理を組み立てられます。利用制限、送信する項目、応答がない場合の扱いを先に決めてください。すべての業務システム向けに標準の接続機能があるとは限りません。

データ連携と顧客向け画面のブランド化は、同じ設定ですか？

データを扱う構成と、画面のブランド設定は別々に準備します。内蔵バックエンドはスタータープラン以上、ホワイトラベルは代理店プロプラン以上が対象です。両方を提供する案件では、必要な機能と外部サービスの費用を合わせて見積もります。

まとめ

Readdyでは、内蔵バックエンドやSupabaseとの連携を使い、顧客サイトのデータ保存と処理を組み立てられます。採用時は、保存先、利用者ごとの権限、外部処理の完了条件を具体化しましょう。失敗後に何を調べ、誰が再対応するかまで決めると、自社ブランドで提供する業務機能の範囲を説明できます。