何を試したか
コーポレートサイトを、単に読む場所ではなく、掲載内容を会話で案内する場所にできるかを試した。
実装したのは、kidsplates.jp の右下に表示される AI アバター受付である。来訪者が質問すると、アバターはサイトに掲載されている製品・研究・実績の範囲から関連情報を探し、回答と関連ページへのリンクを返す。テキスト会話に加えて、音声入力・読み上げ・表情やポーズの変化も組み合わせている。
この実験で重視したのは、AI 機能を入れてもサイト本体を壊さないことだった。アバター層は追加レイヤーとして設計し、無効化しても通常の静的サイトとして成立するようにした。
構成
大きく 4 つの層に分けている。
| 層 | 役割 |
|---|---|
| 静的サイト | Astro で生成した通常のコーポレートサイト。製品・研究・会社情報を Markdown で管理する |
| アバター UI | 右下に表示される VRM アバター、会話パネル、音声入力、関連リンク表示 |
| サイト内 content-map | 公開済みページから生成した、アバターが参照するためのサイト内知識マップ |
| VPS API proxy | API キーをブラウザに出さず、AI 応答・音声・設定保存を中継するサーバー |
サイト本体は静的に配信し、AI との通信だけを VPS 上の小さな API server に逃がしている。これにより、検索エンジンや通常の訪問者に対しては従来の静的サイトとして振る舞い、会話したい人だけがアバター層を使える。
なぜ静的サイトに重ねたか
企業サイトの多くは、問い合わせ前の来訪者に「何を見ればよいか」を案内できていない。ページは存在していても、来訪者は製品名や専門用語を知らないため、目的の情報にたどり着く前に離脱する。
一方で、すべてをチャットボット化すると、サイトの構造・検索性・運用性が失われやすい。そこで今回は、静的サイトを情報の本体として保ち、その上に会話できる案内役を重ねる形にした。
この構成では、AI はサイトの代替ではなく、サイトを読むためのインターフェースになる。
管理画面
アバターの表示や会話の調整は、専用の管理画面から行えるようにした。
管理できる項目は、カメラ位置、初期表情、使えるジェスチャ、挨拶文、回答できないときの文言、人格プロンプト、音声設定、会話状態ごとの表情・ポーズなどである。
重要なのは、開発者が毎回コードを書き換えなくても、受付としての振る舞いを調整できる点である。Web サイトの文章と同じように、アバターの人格や接客トーンも運用対象として扱う。
何が分かったか
最も大きな知見は、AI アバターサイトは「アバターを表示する技術」だけでは成立しないということだった。
必要だったのは、少なくとも次の設計である。
- サイトに掲載された内容だけを根拠にする回答方針
- API キーをブラウザに出さない proxy 境界
- アバター UI を無効化しても壊れない静的サイト構成
- 管理者だけが触れる設定画面
- staging と production の分離
- 本番反映とロールバックの手順
- 音声が使えない場合の fallback
特に、会話できるアバターは来訪者に「人がいる」ような印象を与えるため、回答範囲の制御が重要になる。サイトに書いていない価格・契約条件・将来予定を断定しないこと、分からないことは問い合わせへ誘導することを、人格設計の一部として扱う必要があった。
製品化に向けた切り分け
この実験で得た構成は、今後「AI アバター受付付きサイト構築」としてパッケージ化できる可能性がある。
ただし、Lab で公開するのは研究発表としての構造と知見に留める。実際の製品仕様、導入手順、運用テンプレート、セキュリティ境界、顧客向け設計項目は内部仕様として分けて管理する。
理由は単純で、AI アバター受付はサイト制作、キャラクターデザイン、LLM 運用、VPS 運用、セキュリティ設計が重なる領域だからである。見た目は右下の小さなアバターでも、製品として提供するには、裏側の運用設計まで含めて 1 つのパッケージにする必要がある。
制限・今後
現時点では、掲載内容をもとにした案内と、基本的な音声応答・表情制御までを確認している。今後の課題は、利用量の可視化、レート制限、顧客ごとのナレッジ設計、管理画面の権限管理、音声会話の安定性向上である。
また、サイトごとに「回答してよいこと」と「問い合わせへ誘導すべきこと」は異なる。今後は技術実装だけでなく、アバターの接客ポリシーを設計する工程そのものを、導入パッケージの中核として整備していく。