はじめに
飲食店ビジネスでは顧客対応が負担です。
一件ずつの返信は時間を取ります。
「営業時間は何時ですか」などの質問が毎日来ます。
スタッフ一人で対応すると作業時間が増えます。
このプロジェクトはFoodie Japan向けにAIカスタマーサービスを設計しました。
さらに Claude AIを活用し、LINEとFacebook Messengerで動作します。
コーディング経験が少ない担当者でも構築できます。
コピー＆ペースト形式のガイドに従うだけです。
解決したい課題(ビジネス上の問題)
レストランに寄せられる顧客メッセージを分類すると。
さらに、AI の活用観点では大きく3つのパターンに分かれます。
- 注文状況の確認 — 「注文はどうなっていますか」「いつ届きますか」
- 一般的な質問 — メニュー、営業時間、配達エリア、支払い方法
- クレーム — 料理の質が悪い、配達が遅い、返金の要求
これらをスタッフ一人で対応すると、AI運用にも影響し、応答時間が長くなります。さらに、ピーク時にはメッセージが溜まりやすく、対応の一貫性も保ちにくくなります。担当者が変わるたびに回答スタイルが変わってしまいます。
本プロジェクトの目的は、顧客メッセージの大半をAIで自動で対応することです。
さらに複雑な案件だけをスタッフにエスカレーションします。
アーキテクチャ概要 — システム全体の接続方法
- チャネル層(LINE + Facebook)
顧客は使い慣れたアプリ(LINE、Messenger)からそのままメッセージを送信できます——新しいアプリ
をダウンロードしてもらう必要はありません。 - Webhookサーバー(Renderでホスト)
すべてのメッセージを受け取り、「どのエージェントに送るべきか」を判断する中央ハブです。
Node.js + Expressで書かれ、Render(無料枠のクラウドホスティング)上で稼働しています。 - マルチエージェント・ルーターシステム
これがこのプロジェクトの中核となる設計パターンです。メッセージが届くたびにルーターエージェン
トがまず内容を読み取り、「注文/FAQ/クレーム」の3種類のうちどれに該当するかを分類します。そ
の後、該当する専門エージェントに引き渡します——各エージェントには独自の「性格」と指示が設
定されています(例:クレーム対応エージェントには「まず謝罪すること」と特別に指示している)。 - Google Sheets — データベースとしての活用
初期段階(POC)のビジネスとして、SQLデータベースを新たに構築する代わりに、Google Sheetsを注
文データベースとして直接使用しています。サーバーコードはGoogle Cloudサービスアカウントを
使ってシートの読み書きを行います。ビジネスオーナー側もシートを開くだけで、すべての注文状況を
視覚的に把握できます——技術的なダッシュボードを別途構築する必要はありません。
ビジネスフロー — 顧客ジャーニーの実例
ジャーニー1:注文状況の確認
ビジネス価値 : 顧客はスタッフを待たせることなく、リアルタイムのステータスを取得できます。
ジャーニー2:メニューに関する一般的な質問
ビジネス価値 : AIが価格を推測して計算するのではなく、システムプロンプト内にあらかじめ設定され
た価格だけを常に回答します——何度質問しても価格は常に一貫しています。これはAIシステムを設
計する上で最も重要な原則の一つです——ハルシネーション(AIの憶測)を防ぐことです。
ジャーニー3: AIで新規注文の作成(ショッピングカートフロー)
ビジネス価値 : 顧客は複数のアイテムを段階的に追加でき、一つの注文番号のもとに自動的にまとめら
れます——スタッフによる手動の注文入力作業を完全に排除します。
ジャーニー4:クレーム対応
ビジネス価値 : クレーム対応のトーンを専用に設計しているため——FAQエージェントのシンプルなス
タイルではなく、共感を込めた返答が即座に得られます。
主要な技術的判断 — なぜこのように構築したのか
一つのサーバーで複数チャネルに対応
LINEとFacebook用に2つのサーバーを構築する代わりに——2つのWebhookルート(/webhook、/fb
webhook)を一つのサーバー上に置いています。今後WhatsAppやTelegramなど新しいチャネルを追加
したい場合も、ルートを一つ追加するだけで済みます——エージェントのロジックを書き直す必要は
ありません。
なぜマルチエージェントに分けたのか
一つのエージェントですべてのタスクを処理しようとすると——システムプロンプトが肥大化し、エー
ジェントの「焦点」がぼやけやすくなります。タスクごとにエージェントを分けることで、各エージェ
ントは専用のタスクだけに集中でき——トーン、正確性、振る舞いがより精密になります。
メニュー価格をAIに計算させず固定する
AIモデルは価格や数値を計算する際、一貫性を保つのが難しい傾向があります(メッセージごとに答え
が変わることがある)。そのため価格表をシステムプロンプトに直接固定し、「この価格だけを使い、
推測で答えないこと」という指示を特別に加えています。ビジネスにとって、これは信頼を築くための
最も重要な決定の一つです。
AIを活用する Google Sheets — 本格的なデータベースではないが効果的
POC(概念実証)段階では、データベースサーバーを構築するよりもGoogle Sheetsを使うことで:
- セットアップが速い(サーバー管理の専門知識が不要)
- ビジネスオーナー自身がデータを閲覧・編集できる
- コストがかからない(Google Sheetsは無料)
ビジネスが成長すれば、本格的なデータベース(MySQL、Firebaseなど)への移行も容易です——イン
ターフェースを変えずに、バックエンドだけを差し替えれば済みます。
制約事項(正直な限界)
このプロジェクトを誠実にお伝えするなら——POC段階ゆえの制約もまだ残っています:
セッションメモリ : メッセージごとに新しいAIセッションを作成しているため、会話履歴をAI自身が
「記憶」することはありません——カートやコンテキストはコード側で手動管理しています
サーバーを再起動すると、カートデータが失われる恐れがあります。
本番運用には永続化ストレージが必要です。
AI の活用は信頼性向上にも寄与します。
アイテム検出 : 正規表現ベースのキーワードマッチングを使用しているため、あらゆる言い回しを100%捕捉できるわけではありません
これらの制約はすべて、本番規模へ拡張する際に対応すべき次のステップであり——POCとしてコンセプトを実証するという目的においては十分な水準です。
まとめ
コーディング経験がそれほど多くない担当者でも——コピー&ペースト形式のガイドに従うだけで、これだけのシステムを実際に構築することができました:
- LINE + Facebookのマルチチャネル統合
- AIマルチエージェント・ルーターシステム(Claude Managed Agents)
- Google Sheetsをライブデータベースとして活用
- リアルタイム注文追跡 + ショッピングカートフロー
- メニュー価格の一貫性(ハルシネーション防止)
これは中小企業にとって、AI導入がもはや高コストで複雑なものではないことを示しています——適切なツール(Claude)、適切なプラットフォーム(LINE/Facebook)、適切なアプローチ(マルチエージェント設計)があれば、ビジネスのカスタマーサービスを数週間のうちに変革することができます。是非ともご相談
