1
ゲスト4ステップのアンケートカードとボタンで回答
(事例) ケータリング・Polish AI / Polish 3D
四ステップの質問でグレード別メニューを受け取り、確定後は3Dシーンでテーブル全体をセッティング
婚礼向けケータリングの顧客は、料理の確認と同時に、テーブルの様子も見たいと考えます。顧客は四つのステップで要望を伝えてグレード別メニューを受け取り、確定後はそのまま3Dシーンに入って、テーブル全体をセッティングできます。
同じ手法は、ケータリング、宴会場、ウェディングコンサルタント、食器やフラワー装飾のレンタル、そして組み合わせてはじめて全体像が分かるあらゆるサービスに適用できます。
7種類のケータリングサービス
6組のプリセットプラン
4ステップの質問
(課題)
ケータリングの顧客は、料理とテーブルの様子を同時に確認したい
ケータリングの顧客が購入するのは、宴席の情景そのものです：料理と、当日のテーブルの佇まい。サービスは七種類あり、洋風ウェディング、円卓の中華コース、一歳の誕生日パーティーから個人向け弁当まで、仕様はそれぞれ異なります。日程、人数、会場、食材の制限によっても、料理と価格は変わります。
見積依頼を人手で一問ずつ聞き取り、一件ずつ料理を組み合わせる場合、提案のスピードは受注できる件数と、顧客が他社と比較する時間に影響します。
(アプローチ)
AIがメニューを書き、価格は常に仕様どおり
AIを顧客に直接対応させる際の最大のリスクは、AIが勝手に価格を提示することです。そこで作業を二つに分けました。料金体系、一人あたりの価格、追加サービスは管理画面の仕様に従い、品数も仕様の上限で切り詰めます。AIが担うのは、プラン名、メニュー、説明文だけです。価格に食い違いがあれば、バックエンドが仕様の値で上書きします。
AIが参照する料理も、先に絞り込みます。日付から季節を割り出し、会場から屋内外を判断し、記述からベジタリアン対応を見分けたうえで、料理ライブラリから候補の料理群を選んでAIに渡します。
提案は仕様に沿って、クラシックからアップグレード、シェフ特選へと段階的に上がっていきます。さらにシステムは、サービス種別、価格帯、人数が近い過去の事例をAIに参考として渡します。
ゲスト
- 4ステップのアンケート
- 一文での説明例：年配の方が多い、菜食の方がいる
要件等級別プラン
開発チームのサービス
- 候補料理の事前選別季節、屋内外、菜食の要望に応じて
- 仕様で上書き料金体系、1人あたりの価格、追加サービス、品数の上限
候補料理命名と説明文
モデル提供元
- 言語モデルプランの命名、メニュー、説明文
モデルに任せない価格、料金体系、品数の上限。
範囲：提案の生成。
メニューはAIが書き、価格は管理画面の仕様で決まります。
全文を読む RAG企業ナレッジQ&Aにおける逐語検証フロー(設計の要点)
三つの設計ポイント
四ステップのアンケート
アンケートはカードとボタンで回答し、予約可能な日はシステムがリアルタイムに提示します。入力の途中でページを再読み込みしても、内容は失われません。会員登録は不要で、送信後にメール認証を行えば提案を保存できます。最後のステップで、たとえば高齢者が多い、ベジタリアンがいる、といった状況を一言書くだけで、AIが料理を調整し、ベジタリアン向けの料理を確保し、食べられない食材を避けます。
3Dテーブルセッティング
洋風ウェディング、円卓の中華コース、ビュッフェを選んだ顧客は、プランの確定後、注文を持ったまま3Dテーブルに入ります。どのテーブル形状にも着席位置のアンカーがあらかじめ設定されており、椅子、皿、グラス、ナプキン、メニューカードまでがその位置に配置されます。角テーブルを円卓に替えると、卓上全体が自動で並べ直されます。
プリセットプラン
六つのプリセットプランをワンクリックで適用でき、テーブル、椅子、食器、フラワー装飾まで卓上全体を一度に切り替えられます。自分で組み合わせたい場合は、十のカテゴリーから項目ごとに入れ替えられます。セッティングの完了後、選択内容は同じ注文に保存され、チームは管理画面で、顧客がどのプランと品目を選んだかを確認できます。
デスクトップ
6つのプリセットで、テーブル全体を一度に入れ替え
3Dテーブルの下には6つのプリセットが並び、角テーブルと丸テーブルが各3つです。選ぶとテーブルの形、テーブルと椅子、食器、テーブルランナーまで全体が並べ直されます。カスタマイズに切り替えると、各カテゴリーで項目ごとに入れ替えられます。
スマートフォン
スマートフォンでもワンタップでテーブル全体を入れ替え
スマートフォンの3Dテーブルにも、同じプリセットとカスタマイズのタブが用意されています。1本指で視点を回転し、プランを選ぶとテーブル全体が並べ直されます。
組み合わせて初めて内容が分かるサービスは、初回ミーティングでアンケートとルールに分けて整理できます。
(成果)
連携する二つのサイトと、調整できるAIを納品
現在は、連携する二つのサイトと、運営側で調整できるAIが稼働しています。シェフの口調や命名ルールといったプロンプトは管理画面でセクションごとに管理し、変更のたびに版を残すため、元に戻せます。品目やプランも管理画面で追加・削除でき、新しい皿を加えるためにプログラムを修正する必要はありません。
3Dモデルは圧縮済みで、スマートフォンでは自動的に軽量版へ切り替わるため、顧客はスマートフォンだけでセッティングできます。紹介文とQ&Aはページのソースコードに記述してあり、検索エンジンもAIエンジンも読み取れます。
アンケート
提案
配置
確認
ゲスト
システム
チーム
2
システム等級別プランを生成クラシック、シェフ版へアップグレード
3
ゲスト3Dテーブルへ進む既定プランを適用、または項目ごとに差し替え
4
システムオプションを注文に保存
5
チーム管理画面でプランと品目を閲覧
3Dテーブルは洋式の結婚披露宴、円卓での合菜、ビュッフェに対応します。
サービスとよくある質問は管理画面のデータベースから提供し、テキストは引き続きページのソースに含まれています。
- コンテンツソース静的ファイル、または管理画面のデータベース
- 更新頻度固定、または頻繁に更新
- 3D読み込み失敗時ユーザーにテキストが見えているか
- コンテンツは固定で、パス数は限られています。ビルド時のプリレンダリング磨人の公式サイト：フレームワークは変更せず、ビルドにステップを一つ加えて、ルートごとに静的HTMLを出力します。
- コンテンツはデータベースから取得し、頻繁に更新されます。サーバーサイドレンダリングとインクリメンタル静的再生成サービスカードとFAQは管理画面のデータベースから配信されます。
- 3Dがインタラクションの中心で、読み込みに失敗することがあります。サーバー側のテキスト層（3Dが引き継いだ後に除去）ある公共機関のサイト：3Dが読み込めないかタイムアウトした場合にのみテキストを表示
- テキストはクローラーのためだけに置かれ、ユーザーには見えません。採用せずコンテンツは、ユーザーが見るものと同一でなければなりません。
(工程記録)
手法と実測、カードごとに展開
ケータリングのオンライン提案システムの作り方：4 ステップのフォーム、仕様に基づく料金計算、3D テーブル
価格、品数、追加サービスは管理画面の仕様で決まり、モデルが返すのは名称、メニュー、説明文だけであるモデルの応答後に項目ごとに仕様と照合し、金額と品数は管理画面の値を正とする3Dサイトの検索・AIクローラーへの可読性：プリレンダリング、クローラーの振り分け、構造化データ
プリレンダリングにより、磨人の公式サイトのトップページの生のHTMLは730バイトから39,516バイトに増えましたが、画面に変化はありません。 関連する手法・数字は他プロジェクトの実績
トップページの生のHTMLサイズ（バイト）生のHTML内のh1の数
- 730バイトプリレンダリング前（シングルページアプリ、空のコンテナ）前0
- 39,516バイトプリレンダリング後（ビルド時にルートごとに静的HTMLを出力）確定1
磨人の従来版公式サイトのトップページです。h1の数はプリレンダリングの方式に従って説明しています。
三種類のクローラーは同じHTMLを読みますが、用途が異なり、robots.txtで管理できる範囲も異なります。 関連する手法
クローラー
- 検索インデックス用クローラーOAI-SearchBot、Claude-SearchBot、PerplexityBot：テキストを取得し、検索とアシスタントの結果に利用
- 学習用クローラーGPTBot、ClaudeBot。Google-Extendedはトークンで、独自のuser agentを持ちません。
- ユーザーがトリガーするクローラーChatGPT-User、Claude-User、Perplexity-User：ユーザーが質問したときのみ、一ページを取得します。
リクエストとuser agentHTMLテキスト
Webサイト（開発チーム設定）
- プリレンダリング済みHTMLh1、直接回答の段落、本文は、すべてソースコードに含まれます。
- robots.txt のグループ分け検索とアシスタントは許可、学習は事業判断で決定
- サーバー層でのuser agent判定robots.txtに従わないリクエストを拒否
robots.txtはアクセス制御ではありませんRFC 9309は、これらのルールはアクセス許可ではないと説明しています。ユーザーがトリガーするクロールについて、公式ドキュメントでは、ルールが必ずしも適用されないと説明されています。
OpenAI、Anthropic、Perplexity、Googleの公式ドキュメントをもとに整理。確認日 2026-11-05
AIプロジェクトの費用の見積り方：見積りが数倍ずれる理由
発見ごとに検証エージェントを一つずつ割り当てると、エージェント数は発見数に応じて136個まで増え、バッチ検証後は約7個に減ります。 関連する手法・数字は他プロジェクトの実績
- 発見ごとに検証エージェントを一つずつ割り当て136個のエージェントエージェント数は発見数に応じて増大
- 統合後に減るエージェントコストは元の約5%一エージェントが15〜20件を検証
- バッチ検証約7個のエージェント割り当て前に、発見数×検証者数の上限を算出
監査フロー。コストは定価による換算値で、請求額ではありません。
思考をオフにすると執筆時間を6〜17秒に短縮できますが、タイトルの成功率は11/11から2/13に下がります。 関連する手法・数字は他プロジェクトの実績
執筆時間タイトル成功率
- 15〜75秒思考オン、一括執筆保留11/11
- 6〜17秒思考オフ、一括執筆採用せず2/13
テスト環境、実モデル、13問。検証プログラムに削除された文は、思考オフ時がオン時の3倍でした。
最も高価なモデルは、抜き取り確認の後に標示された難しい事例だけを処理し、コーパス全体を記事ごとに読んではいません。 関連する手法・数字は他プロジェクトの実績
- コーパス全体のアノテーション約1,500記事一記事一サブタスク、Haikuがアノテーション
- 抜き取り確認なしの記事数プログラムの検証器のみ通過終了コード0のみ採用
- リスクに応じた抜き取り確認約160記事約一割、Sonnetが審査
- Opusに引き上げ9個のサブタスク標示された難しい事例と、検証器を通過しないものだけを処理
サブタスク数：Haiku約1,600個、Sonnet約50個、Opus 9個。記事数とサブタスク数はいずれも概算値です。
初回ミーティング（15〜30分）で、手法の方向性、予算帯、スケジュール案を確認できます。
Polish AIPolish 3D次のプロジェクト：省庁横断の年次屋外教育プログラム、ダウンロード不要のウェブゲームで全国の施設をつなぐ
(お問い合わせ)
Start a project.
三つのステップで、判断に足る進め方と予算帯が得られます。
- 01最初の打ち合わせを予約：時間を選びます。完全な仕様は不要です。
- 02オンライン相談（15〜30分）：進め方の方向性、予算帯、スケジュール案を提示。
- 03素材を確認したうえで、約3〜5営業日で見積書兼納品仕様明細書を提出します。
- メール
- hello@polish-design.com.tw
- 郵送先住所
- (104) 台湾 台北市 中山区 植福路191-1号 3F
