概要とデモ
TableCastは、卓上のiPadに話しかけて料理を相談し、そのまま注文できるAI接客・注文システムです。チームKOSENで制作し、私は全体の設計・実装を主導しました。2026年9月15日の「OpenAI 大学生向け 夏の Codex 開発祭 2026」で発表しました。
メニューを見ても、どの料理が自分の好みに合うのか分からない。店員に聞きたくても、忙しそうで声をかけづらい。言葉が通じるか不安で、相談をためらうこともあります。TableCastは、そんな場面で気軽に話しかけられる、卓上の相談相手を目指して作りました。
来店客は日本語や英語で好みを伝え、提案を聞きながら料理を選べます。量や温度などを指定し、内容と金額を確認したら注文します。話しかけるだけでなく、途中で画面をタッチして選び直すこともできます。店舗向けには、メニューの編集、注文の確認、売上などの分析機能を用意しました。
技術構成は、発表時点の実装（e9af366）をもとに紹介します。操作画面は2026年9月18日にstaging環境で撮影しました。画面内の店舗・商品・注文は検証用のデータです。
音声で相談し、タッチでも注文する
好みに合う料理を相談する
料理が決まっていなくても、好みや気になることを伝えるところから始められます。AIがメニューを参照して提案し、会話の内容は画面にも表示されます。
音声対話にはGPT-Live 1を使い、ブラウザーからWebRTCで接続します。商品を調べたり注文を操作したりするときは、Responses delegationでgpt-5.6-lunaに処理を引き継ぎます。必要なAPI呼び出しはブラウザーを経由して行います。AIの発言だけで注文が成立することはなく、APIの処理結果を会話と画面に反映します。
音声の送受信と注文操作では、接続先が異なります。下図の上段はモデルとの対話、下段は商品の取得や注文を処理するAPIへの接続です。
音声とタッチ操作は、同じAPIと注文かごを使います。会話を止めても選んだ商品は残るので、そのままタッチ操作に切り替えられます。音声を再開する際は、来店客がボタンを押します。
日英の切り替えでは、商品IDや価格を共通にしたまま、名前と説明を切り替えます。表示名とは別に読み上げ用の名前も設定でき、声では伝わりにくい商品名の読み方を調整できます。
カスタマイズから注文確認まで
料理や飲み物を選ぶときには、数量だけでなく、サイズや温度などの指定が必要です。TableCastでは、必須の選択肢、選べる数、追加料金、売切れ、ほかの選択肢との組み合わせを設定できます。指定が足りなければ、選びかけの商品を注文かごに残して追加で尋ねます。
音声で追加した商品も、画面から変更できます。価格や注文できる組み合わせは、AIではなくAPIが商品設定に基づいて判定します。選び直したときは注文かごの該当項目を更新し、同じ商品を重複して追加しないようにしました。
注文の確定時には、来店客が確認した内容と保存する内容を照合します。シーケンス図では、確認内容の作成から承認、保存までを時系列で示しています。
注文前に、商品・選択肢・数量・価格をまとめたスナップショットを保存します。画面と読み上げにはその内容を使い、来店客の承認後に確定します。途中で注文かごが変わったら、確認からやり直します。また、同じリクエストが再送されても注文を二重登録しない仕組み（冪等性）を設けています。
店舗スタッフは、届いた注文を確認して提供状況を更新できます。
デモでは注文から提供・会計までを試せます。ただし、会計は模擬処理で、決済サービスやPOSとは連携していません。
店舗管理とMCP
メニューと接客情報を設定する
管理画面では、商品名・価格・画像に加え、説明文、日英の翻訳、サイズなどの選択肢を編集できます。ここで設定した情報を、画面表示とAIの接客、注文時の検証で共通に使います。
画面の実装にはTanStack StartとReactを使いました。ページ遷移はRouter、データ取得はQuery、入力はFormに任せ、APIと型を共有しています。入力内容はブラウザーだけでなく、Honoで実装したAPIでもZodを使って検証します。
AIから下書きを作り、人が公開する
店舗の設定は、ChatGPTやCodexからも変更できます。店舗向けプラグインを接続すれば、お品書きの画像や資料をもとにメニューの下書きを作れます。店舗の利用者がコードをダウンロードしたり、開発環境を用意したりする必要はありません。
プラグインは、AIが外部の機能を呼び出すためのMCPを通じてAPIに接続します。通信方式はStreamable HTTPで、認証にはOAuth 2.1・PKCEを使い、動的クライアント登録にも対応しています。APIでは、読み取り・書き込みの権限に加えて、操作対象の店舗へのアクセス権を確認します。
プラグインが作成した設定は、担当者が承認するまで下書きとして扱います。次の状態遷移図は、下書きの作成から公開までと、修正が必要になった場合の戻り先を示しています。
MCPのget_configurationで現在の設定を取得し、create_draft・update_draftで下書きを作成・編集します。画像はupload_imageで出典とともに登録します。価格や説明をAIが書き換えても、担当者が承認するまでは公開されません。
注文や商品ごとの集計も、管理画面とMCPの両方から取得できます。集計をもとに改善案を考え、メニューや接客設定の下書きに反映するところまでを、検証用データで試しました。
アーキテクチャと技術選定
WebとAPIを分け、業務の判定を一か所に集める
システムは、画面を返すWeb Workerと、認証・メニュー・注文を処理するAPI Workerに分けました。どちらもCloudflare Workers上で動かし、Service Bindingで接続しています。音声、タッチ操作、MCPのどこから操作しても、価格や権限の判定は同じAPIが担います。
下図では、Cloudflare上で動くサービスを枠内にまとめました。左側のブラウザーやMCPクライアントから受けたリクエストを、Web WorkerがAPI Workerへ転送します。API Workerからは、処理の目的に応じてD1、R2、Durable Objectsを呼び出します。
ブラウザーからのアクセス先を一つにまとめ、/api/*や/mcp、OAuthのメタデータ、/media/*をWeb WorkerからAPIへ転送します。転送時にはCookieに加え、ストリーム、リクエストの中断、WebSocketも引き継ぎます。
SSRで使うTanStack Queryのクライアントはリクエストごとに作成し、ログイン後のHTMLは共有キャッシュに保存しません。利用者間でデータが混ざらないようにするためです。モデルへの接続に使うAPIキーもサーバー側で管理します。
データの性質に合わせて保存先を分ける
| 構成要素 | 役割と選定の狙い |
|---|---|
| D1 / SQLite・Drizzle | 商品、権限、公開設定、注文履歴の正本を保存します。関係を持つデータをSQLで扱い、join・バッチ処理・条件付き更新で整合性を守ります。 |
| R2・Images | 商品画像やテーマ、ゲームなどのアセットを扱います。注文などの構造化データとは保存先を分けます。 |
| Durable Objects | StoreEventsを通じて店舗・卓の更新を通知します。注文や提供状況の変化を画面へ伝える役割です。 |
| GPT-Live 1・gpt-5.6-luna | 音声での対話と委譲先での処理を担います。注文の価格計算や権限判定はAPIに残します。 |
Durable Objectsは変更を素早く知らせるために使い、注文やイベント履歴はD1に保存します。接続が切れて通知を受け取れなくても、再接続後に保存済みの情報を取得できます。
注文の確定には、D1の条件付き更新とバッチ処理を使います。画面のボタンを無効にするだけでなく、保存する直前にも確認済みの版と現在の状態を照合します。別端末での変更や通信の再送があっても、古い内容で確定しないための対策です。
開発・検証・改善
並行開発と環境の分離
Web・API・共有コードは、Bun workspacesとTurborepoで管理しています。並行開発にはGit worktreeを使い、作業ディレクトリだけでなく、ポートやCookie、ローカルの保存データも分離しました。別の作業のログイン状態やテストデータに影響を与えずに検証できます。
ローカルではworkerdを使い、Cloudflareの実行環境で動作を確認します。その後はPRごとのpreview、統合検証用のstagingを経て、本番へ反映します。
環境ごとの違いは、実行場所とデータの保持期間です。比較表では用途と保存先を並べ、下段のタイムラインでは本番配備までの順序を示しています。図中のDOはDurable Objectsを指します。
previewのデータはPRごとに独立させ、PRを閉じたら一時的な資源を削除します。一方、stagingは継続して使う環境なので、通常の配備ではデータを保持します。
GitHub Actionsでは、フォーマット・リント・型チェックに加え、Vitest、D1を使うテスト、Storybook、PlaywrightのE2Eを実行します。関数単位のテストだけでなく、画面で商品を選んで注文する流れや、権限のない店舗へアクセスできないことも確認します。
Grafanaで注文処理を追う
注文の送信に時間がかかったとき、画面だけでは原因が分かりません。そこで、認証、商品取得、注文の保存、通知までを一つのトレースで追い、Grafanaで処理時間の内訳を調べられるようにしました。
PR #63では、2026年9月10日のPR preview（4a3ed88）で、検証用店舗の通常注文を追跡しました。この1回のトレースでは全体が約1.85秒で、商品取得は約555ミリ秒、通知は約200ミリ秒でした。各spanには包含関係があり、単純に足し合わせるものではありません。また、本番環境の平均や上位パーセンタイルを示す計測でもありません。
調査では、SQLの実行時間だけでなく、APIとD1の間で何回やり取りしているかにも注目しました。ログのrequest IDからトレースをたどると、待ち時間が長い処理を絞り込めます。後続のIssue #101では、認証やSSRでのD1への問い合わせ回数を減らすことと、API Workerの配置を最適化することを検討しました。
Codexを実装から検証まで使う
Codexにはコードの実装だけでなく、Issueの作業分割、テスト、PRレビュー、配備設定の確認も任せました。AGENTS.mdやskillsに仕様と手順をまとめ、各worktreeで同じ前提を参照できるようにしています。
不具合の調査では、読み取り専用MCPを通じてGrafanaのログとトレースを参照させました。画面はStorybookやブラウザー操作で確認し、コード上の推測だけで修正を終えないようにしました。
架空の店舗・商品・利用者のデータを生成し、デモとE2Eで共用しました。音声テストでは、来店客の発話に相当する音声をInworld TTSで用意しています。来店客へ応答するGPT-Live 1とは別の用途です。デモ動画も、OpenScreenでの録画、Computer useでの操作、Hyperframesでの音声・字幕編集にCodexを使って制作しました。
制作・発表の背景
2026年9月15日、横浜で開催された「OpenAI 大学生向け 夏の Codex 開発祭 2026」に、書類選考を経て現地参加しました。チームKOSENとしてTableCastを制作・発表し、音声で料理を相談する体験から、店舗の設定や検証環境までを紹介しました。
会場はTHE BEACH YOKOHAMA（〒231-0801 神奈川県 横浜市 中区新山下3-2-5）です。