家事代行・電気工事・清掃などの訪問サービスを予約できるプラットフォームを、個人開発や小規模チームでAIコーディングツールを使って作ろうとしている方に向けた内容です。顧客アプリ・管理ダッシュボード・技術者向け画面という3者が1つのバックエンドを共有する構成は、単純なCRUD（データの作成・読み取り・更新・削除だけを行うシンプルな処理）アプリとは設計の難しさの質が違います。
海外の開発者コミュニティdev.toで公開された事例では、HomeFixという訪問サービス予約プラットフォームが紹介されています。顧客用モバイルアプリ、React・TypeScript製のWebサイト、管理者用ダッシュボードという3つのフロントエンドを、Node.js・Express・Socket.IOのバックエンドが束ねる構成です。この手の「複数ロールが1つの状態を共有するシステム」は、ChatGPTやClaude CodeのようなAIコーディングツールに丸投げすると、ロール間の整合性が崩れやすい典型パターンでもあります。
なぜマルチロール予約システムの設計は難しいのか
予約フローを順番に見ると、顧客が予約を作成し、バックエンドに保存され、管理者が受け取り、技術者を割り当て、顧客に更新が通知されます。
この5ステップのうち、どこか1つでも非同期処理の扱いを誤ると、顧客画面には「予約済み」なのに管理画面には反映されていない、といった不整合が起きます。
単一ロールのTodoアプリなら、画面をリロードすれば最新状態が見えます。しかしこの予約システムでは、顧客・管理者・技術者がそれぞれ別の端末からリアルタイムに同じ予約レコードを見ている状態を維持する必要があります。
ここで使われているのがSocket.IOです。これはWebSocket（サーバーとクライアントが双方向に常時接続する通信方式）を扱いやすくラップしたJavaScriptライブラリで、ポーリング（一定間隔でサーバーに問い合わせる方式）に頼らず、サーバー側の変化をクライアントへ即座にプッシュできます。技術者の位置情報や予約ステータスの変更を、画面の手動更新なしに反映する用途に向いています。
AIコーディングツールに設計を任せる時の落とし穴
Claude CodeやCursorのようなAIコーディングツールに「予約システムを作って」と指示すると、多くの場合REST API（HTTPでリソースを操作する標準的な設計様式）のCRUDエンドポイントは綺麗に生成されます。
問題はロール間の状態同期です。AIは「顧客が予約を作る」機能と「管理者が技術者を割り当てる」機能を、別々のプロンプトで依頼すると、別々の実装方針で作ってしまうことがあります。
たとえば、ある機能ではSocket.IOのイベント名をbooking:createdにし、別の機能ではnewBookingにしてしまうようなケースです。片方のクライアントだけイベントを受信できず、サイレントに同期が壊れます。
これを防ぐには、最初のプロンプトでイベント名・ペイロード構造を明示的に固定し、以降のプロンプトでは「既存のbooking:createdイベント仕様に従って実装して」と毎回参照させる運用が有効です。AIに新規実装を都度任せるのではなく、一度決めた契約（イベント名・データ構造）をドキュメント化し、プロンプトに含め続ける方が崩れにくくなります。
MCPで予約データベースとAIツールをつなぐ発想
こうしたマルチロールシステムの開発では、AIコーディングツールにデータベースの実スキーマを直接確認させる仕組みが役立ちます。
MCP（Model Context Protocol、AIモデルが外部ツールやデータソースに安全にアクセスするための標準プロトコル）対応のデータベースサーバーをClaude CodeやCursorに接続すると、AIが実際のテーブル定義を見ながらコードを生成できます。
具体的には、PostgreSQL用のMCPサーバーを設定ファイルに登録すれば、AIが「bookingsテーブルのstatusカラムが本当にenum型かどうか」を推測ではなく実物を見て判断できるようになります。予約ステータスの不整合は、AIが古い想定のままコードを書くことで起きやすいため、この確認ステップは地味ですが効果があります。
従来のモノリシック構成との比較で見る設計判断
| 観点 | 単一フロントエンド構成 | マルチロール構成(今回の例) |
|---|---|---|
| 状態管理 | クライアント内で完結しやすい | 複数クライアント間での同期が必須 |
| リアルタイム通信 | 任意(なくても成立) | Socket.IO等がほぼ必須 |
| AIへの指示粒度 | 機能単位で依頼しやすい | 契約(イベント仕様)を先に固定する必要 |
| テストの焦点 | 単体テスト中心 | ロール間の結合シナリオテストが重要 |
この比較から分かるのは、ロールが増えるほど「個々の機能が動くか」より「ロール間の受け渡しが崩れていないか」の確認比重が上がるという点です。
今日確認できること
すでに訪問サービス予約やマッチング系のアプリをAI駆動で作っている、あるいはこれから作る場合、次の点を確認してみてください。
- Socket.IOを使っているなら、イベント名とペイロード構造を1枚のドキュメント(README等)にまとめ、AIへのプロンプトに常に添付しているか
- 顧客・管理者・技術者それぞれのクライアントで、同じイベントを受信するコードが別々に実装されていないか(重複実装はズレの温床)
- 使っているAIコーディングツールがMCP対応なら、データベース用MCPサーバーを設定し、スキーマを都度確認させているか(Claude Codeなら
.mcp.json、Cursorなら設定画面のMCPタブで登録状況を確認できます) - 予約作成から技術者割り当てまでの一連の流れを、E2Eテスト(ユーザー操作全体を通して検証するテスト)で1本は用意しているか
特に最後の項目は見落とされがちです。各ロールの機能が個別に動いていても、一連の流れとして通しで確認していないと、本番で初めて不整合が発覚します。
まとめ
複数ロールが1つのバックエンドを共有する予約プラットフォームは、個々の画面よりも「ロール間のデータ受け渡し」が設計の核心になります。
Socket.IOのようなリアルタイム通信の仕組みを使う場合、イベント名とデータ構造を先に固定し、AIコーディングツールへのプロンプトに継続して含めることが、実装のブレを防ぐ具体的な手立てです。
MCP対応のデータベース接続を使えるツールなら、AIにスキーマの実物を見せることで、推測によるコード生成を減らせます。
まずは手元のプロジェクトで、Socket.IOのイベント一覧とE2Eテストの有無を棚卸しするところから始めてみてください。