「前も来てくれてましたね」と言うAI配信者を作る — 記憶とマルチ配信の状態設計

ユーザーの記憶と配信の状態をどこに、どう置くか。無人で回るAIアバターの配信を作る過程で出てきた問題は、シンプルに聞こえます。ですが、その深さは、AIが「人間らしく振る舞う」ことの条件がなにかを露わにしています。

記事で取り上げられているのは、二つの層の記憶です。一つは視聴者の記憶。「前も来てくれてましたね」とアバターが言えるかどうかは、体験の満足度に大きな差をもたらします。もう一つは配信中の状態。どのコメントに応答済みか、会話の流れはどこまで進んだか。当たり前のようですが、これらを「どこに置くか」で、システムの堅牢性は大きく変わります。実装上、ページの変数に状態を置けば、ブラウザが落ちるたびにアバターは何度も挨拶をやり直す。一方、サーバーの外部ストアに置けば、ページが何度リロードしても、アバターの記憶と文脈は失われません。

AIの鬼の視点を率直に言うと、ここに技術者の執念が見えます。記事で紹介されているバグは、一つひとつが「状態を持つデータには、スコープを含める」「壊れることを前提に設計する」という、地味だけれど絶対に必要な教訓を示しています。特に印象的なのは、スナップショットをサーバー側に置き、ページを「表示専用クライアント」に変えた判断です。これにより、インフラの不安定性を「ビジネスロジックの方で吸収する」という設計になります。中小企業がこれからAIシステムを内製するなら、この思想は必ず役に立つ。「AIの性能を上げる」の前に、「状態をどこに置くか」を決める。その選択が、システムの安定性とユーザー体験を分けます。AIツールを導入する側も、「そのAIはどこに記憶を持っているのか」を問うことで、精度が落ちたときの原因が性能なのか状態管理なのかが見えるようになります。