一、市场背景与核心痛点
日本餐厅预约现状
- 高端料理店（懐石/寿司/法料）普遍要求电话预约，体现服务仪式感
- 店员接电话压力大：峰值时间集中，敬语体系复杂，语言要求高
- 主流预约平台：TableCheck（高端主力）/ 食べログ / ぐるなび，但均无 AI 电话接待
核心痛点
- 同一时段多个电话 → 店员顾此失彼，信息记录靠手写，容易出错
- 外国客人来电（英语/中文）→ 语言障碍，直接拒绝或严重出错
- 来电信息靠手写 → 日期/人数/菜品偏好错误率高
- 预约确认需要回电 → 效率低，客人体验差
二、竞品分析
| 产品 | 类型 | 特点 | 对 AMI 的参考价值 |
|---|
| Retell AI | AI 电话（通用） | 延迟 ~600ms，LLM 驱动，多语言 | 技术架构参考，无日语餐饮深度 |
| Bland AI | AI 电话（企业） | 全栈自建，延迟最低，数据不过第三方 | 数据安全模型值得学习 |
| VAPI | AI 电话（API） | 开发者友好，支持 Function Calling | 可作为底层 infra |
| TableCheck | 日本预约系统 | 高端餐厅首选，覆盖米其林级别 | ⚠️ 强势渠道，但无 AI 电话 |
| 食べログ予約 | 日本预约系统 | 大众市场，流量大 | 非目标客群 |
🎯 关键机会：AI 电话接待 × 日本餐饮预约 = 基本空白
通用 AI 电话无日本餐饮深度 · 日本预约系统无 AI 电话 · 交叉点无人做
三、技术路线
来电 → 语音识别（STT）→ 意图理解（LLM）→ 信息提取 → 写入预约系统 → 语音回复（TTS）
日语专项挑战
- 敬语识别：尊敬語/謙譲語，通用 STT 识别率不稳定
- 菜名识别：「おまかせコース」「先付」「椀物」，需餐厅专属词典
- 模糊表达：「再来週の土曜の夜、2名で伺えますか」需要上下文理解
- 方言：大阪/京都关西腔影响 STT 准确率
推荐技术组合
| 层级 | 推荐 | 备选 |
|---|
| STT | Whisper large-v3（日语最佳） | Google Cloud STT（日语特化） |
| LLM | GPT-4o / Claude 3.5 | 日本本地模型 Gemma-Japanese |
| TTS | Google Cloud TTS（日语音质最好） | ElevenLabs（更自然但贵） |
两种接待模式
模式 A
AI 完全接管
来电直接转到 AI，AI 完整接待，店员只查看记录。
✅ 完全自动化
❌ 高端餐厅客人可能反感"没有人接"
模式 B（推荐）
AI 辅助店员
店员戴耳机接电话，AI 实时转录+识别信息+屏幕提示。
✅ 保留人工温度，高端接受度高
✅ 只需 AirPods + iPhone App
门槛低，先做这个
四、日本市场特殊考量
数据合规（APPI）
接通电话时需自动播放告知语：「お電話はAIが対応いたします」
获客路径建议
- 高端餐厅老板保守，不要直接销售给餐厅
- 通过代理商（餐饮系统供应商）进入，借助 TableCheck 渠道
- 考虑与 TableCheck 合作而非竞争
定价参考
中高端餐厅（人均 ¥8,000-¥30,000）利润空间充足，月费 ¥15,000-¥50,000/店 不是障碍
五、MVP 建议
最小可验证产品
场景来电时，AI 实时转录通话，自动识别「日期 + 人数 + 菜品偏好」，生成预约卡片，店员确认一键保存
交付物iPhone App（店员端）+ 电话转接配置
不做完全自动接管电话 / 专用硬件（太激进 / 太重）
六、下一步建议
1
Eason 访谈 2-3 家目标餐厅：验证痛点是否真实，AI 介入接受度如何
2
STT 日语餐饮准确率测试：用 Whisper + 模拟电话场景，噪音环境下跑一次
3
竞品深访：联系 TableCheck 了解 roadmap，判断合作 vs 竞争
4
定价假设验证：目标餐厅对月费 ¥30,000 的接受意愿
此报告为初步调研 · 待 Steve + Eason 讨论后深化 · 2026-03-26 Noa