1
メールだけに依存しない
問い合わせ内容をCloudflare D1へ保存。メールを見失っても、管理画面から受付日時や会社名で確認できます。
Cloudflare D1 / Workers / Pages
問い合わせフォームDB化
メールで届いて終わりだった問い合わせを、検索できるデータとして保存。通知、対応状況、担当者メモ、CSV出力まで、既存ホームページを活かしながら管理できる形へ整えます。
既存フォームを活かしながら、問い合わせ管理を一段進める構成
問い合わせ一覧
Cloudflare D1保存
メール通知
Access OTP保護
CSV出力
返信下書き
Before / After
問い合わせを「探せないメール」から「管理できる資産」へ
メール通知は便利ですが、過去の問い合わせ確認、担当者の引き継ぎ、対応漏れの把握には限界があります。DB化すると、問い合わせを業務データとして扱えるようになります。
2
対応状況が残る
未対応、対応中、対応済み、優先度、担当者、内部メモを管理し、あとから経緯を追える状態にします。
3
将来の営業支援へつながる
AI要約、返信文案、顧客管理、分析などへ拡張しやすいDB設計にしておくことで、次の改善がしやすくなります。
How It Works
既存フォームからCloudflareのDBへ保存
ホームページの見た目を大きく変えず、送信先をCloudflare側へ切り替える構成です。保存後は社内通知も行います。
フォーム送信
既存の問い合わせフォームから、Cloudflare PagesのAPIへPOSTします。
入力チェック
必須項目、メール一致、文字数、honeypot、レート制限などをWorker側で確認します。
D1へ保存
問い合わせID、会社名、氏名、本文、受付元、通知状態などをD1に保存します。
通知と管理
社内へメール通知し、管理画面から検索、対応管理、CSV出力を行えます。
Admin Features
問い合わせ管理に必要な機能をまとめて用意
単なる保存ではなく、日々の確認、返信準備、削除管理、運用点検まで見据えた管理画面を構築します。
管理画面でできること
- 問い合わせ一覧、詳細表示、最近の問い合わせ確認
- 会社名、氏名、メール、本文、内部メモの検索
- 状態、優先度、受付元、通知状態、担当者で絞り込み
- 対応状況、担当者、内部メモの更新
- 条件を反映したCSV出力
- 返信メール下書きの表示
運用面の備え
- 通知エラーの確認と再送導線
- 削除済み管理、復元、一定期間後の完全削除
- 対応履歴の記録
- 拒否メールドメインの管理
- バックアップ、復元、旧PHPへの戻し手順の整備
- Turnstileを有効化できるbot対策の余地
Screen Examples
問い合わせ管理画面の例
受付状況、未対応件数、通知状態、対応メモを確認し、日々の問い合わせ対応を止めないための管理画面イメージです。
管理トップ
未対応、3日超過、通知エラー、種別ごとの件数を一覧し、朝の確認で見るべき項目をまとめます。
3日以上未対応の問い合わせが 2 件あります。
通常一覧18
未対応6
3日超未対応2
通知エラー0
PC相談5
HP9
ソフトウェア4
削除済み3
定期運用
- 毎営業日
- 未対応、通知エラー、削除予定を確認
- 週1回
- CSV出力とバックアップ結果を点検
- 月1回
- 拒否ドメインと保存期間を見直し
- 変更前
- バックアップ後に変更し、作業記録を残す
障害時
- 通知失敗
- Webhook設定と送信ログを確認
- フォーム停止
- 旧フォーム送信先へ一時戻し
- アクセス不可
- Cloudflare Access / PIN設定を確認
- 記録禁止
- Secret、PIN、本文全文は共有資料に残さない
スパム対策
- 現状
- Turnstile有効、拒否ドメイン管理
- 判断
- 短時間の連続送信やURL過多を確認
- 拒否リスト
- /admin/blocked-domains
- 有効化
- site key と secret key を環境変数へ設定
問い合わせ一覧
受付日時、種別、状態、会社名、通知結果を横断して確認し、未対応やPC相談などで絞り込めます。
未対応 6件
通知エラー 0件
CSV出力可
| 受付日時 | 種別 | 状態 | 会社名 | 担当部門 | 通知 | 操作 |
|---|---|---|---|---|---|---|
| 2026/06/29 10:42 | HP / 設備見える化 | 未対応 / 高 | 株式会社東西製作所 | 生産技術部 | 送信済 | 詳細 |
| 2026/06/28 16:15 | PC相談 | 対応中 / 通常 | 大阪設計サービス株式会社 | 情報システム | 送信済 | 詳細 |
| 2026/06/27 09:30 | ソフトウェア | 未対応 / 通常 | 阪神部品工業株式会社 | 設計課 | 送信済 | 詳細 |
| 2026/06/26 14:05 | HP / 問い合わせフォーム | 対応済み / 通常 | 北摂メンテナンス株式会社 | 総務部 | 送信済 | 詳細 |
詳細・対応管理
問い合わせ内容を確認しながら、状態、優先度、担当者、内部メモを更新できます。
未対応
高
営業技術
受付内容
- 種別
- HP / 設備見える化
- 会社名
- 株式会社東西製作所
- 担当部門
- 生産技術部
- メール
- contact@example.co.jp
- 要件
- 稼働状況の見える化と、問い合わせ履歴を社内で共有できる管理画面を検討したい。
対応メモ
既存フォームの項目は維持希望。管理画面はAccess OTP + PINで運用。CSV出力は月次レポート用に必要。初回打ち合わせで保存期間と通知先を確認する。
保存
返信下書きを確認
Security
問い合わせ内容を扱うための保護を前提に
問い合わせには個人情報や取引先情報が含まれます。公開フォーム、管理画面、DB、CSVのそれぞれで必要な保護を入れます。
公開フォーム側
- 入力値の正規化と長さ制限
- HTML出力時のエスケープ
- honeypot、短時間送信拒否、IPハッシュ単位のレート制限
- 外部URLへ戻さないreturn_url制御
- Turnstile有効化に備えた構成
管理画面側
- Cloudflare AccessのメールOTP
- 管理PINによる追加確認
- CSRFトークンとOrigin確認
- 管理画面レスポンスのno-store指定
- CSVセルの数式注入対策
System Structure
小さく始めて、あとから育てられる構成
既存Webサーバーを残し、フォーム送信だけCloudflareへ接続するため、段階的に導入できます。
既存サイト
example.co.jp の問い合わせフォームをそのまま活用
API
Cloudflare Pages / WorkersでフォームPOSTを受付
DB
問い合わせ専用Cloudflare D1へ保存
通知
Google Apps Script等のWebhook経由で社内へメール通知
管理
Access OTP + PIN保護の管理画面で確認
導入時に重視すること
| 既存互換 | 今のフォーム項目や完了画面の流れをできるだけ維持します。 |
|---|---|
| 分離設計 | 問い合わせ専用D1を用意し、他サービスのデータと混在させません。 |
| 秘密情報 | Webhook Secret、PIN、認証情報はコードに直書きしません。 |
| 戻せる運用 | 切替前のHTMLとPHPを残し、必要時に旧構成へ戻せる手順を用意します。 |
Future
ミニCRMやAI活用の土台にも
最初から大きなCRMにする必要はありません。まず問い合わせをDBに残し、必要に応じて次の機能へ広げられる状態を作ります。
A
AI要約
問い合わせ内容を短く要約し、対応すべきポイントを把握しやすくできます。
B
返信文案
問い合わせ詳細から返信メールの下書きを作り、担当者の返信準備を軽くします。
C
顧客管理
会社名やメールアドレスを軸に、過去問い合わせや対応履歴を確認できる形へ発展できます。
FAQ
よくある質問
既存のホームページを作り替える必要がありますか？
必ずしも必要ありません。既存フォームの送信先をCloudflare側APIへ切り替え、見た目は大きく変えずにDB保存へ移行できます。
メール通知は残せますか？
残せます。問い合わせ内容をD1へ保存したうえで、社内へメール通知します。通知に失敗した場合も、管理画面上でエラーを確認できます。
管理画面はどのように保護しますか？
Cloudflare AccessのメールOTPと管理PINを組み合わせ、許可された担当者だけが閲覧できる構成にします。管理画面のレスポンスはキャッシュさせません。
CSV出力できますか？
できます。検索・絞り込み条件を反映したCSV出力に対応し、Excelで開く場合の数式注入対策も行います。
スパム対策はできますか？
honeypot、短時間送信拒否、レート制限、英文のみ本文の拒否などを組み合わせます。必要に応じてCloudflare Turnstileも有効化できます。
将来AIやCRMに拡張できますか？
拡張できます。問い合わせID、状態、優先度、担当者、内部メモ、AI要約用カラムなどを見越した設計にしておくことで、段階的な改善がしやすくなります。
本ページは問い合わせ管理基盤の紹介です。個人情報や業務情報を扱うため、導入時はフォーム項目、保存期間、管理者権限、バックアップ、通知先、既存サーバーとの切替方法を確認したうえで構成します。