AIキャラクターは会話するほど別人になるのか｜Canonと学習の境界

レイは、利用者についての記録に、発言の内容だけでなく対象、日時、利用範囲を付ける設計を勧めます。架空の相談室「ことばの窓」の案内役「灯」が「今日は箇条書きがいい」と言われた場合、当日の希望として扱う案と、今後も続く希望として確認する案があります。本人が述べたこと、応答側が推測したこと、まだ確認していないことを同じ確実さで保存しないのが出発点です。

技術研究の参照として、ParkらのGenerative Agentsの公開要旨は、経験の記録、記録からの省察、行動計画のための検索を組み合わせた構成を説明しています。本稿が参照するのは、この処理の区別までです。同論文を根拠に、特定サービスの記憶が正確だとか、利用者情報を長期保存すればよいと結論づけることはしません。

灯の紙上試行では、「紅茶が好き」「今週だけ朝の相談を避けたい」「去年の希望は取り消す」という架空の発言を三枚のカードにします。それぞれ、継続の確認が必要か、有効期限があるか、古い記録へ何をするかを担当者が判断します。正答率を測るより、判断が割れた理由を残します。保存の規則が曖昧なまま応答の自然さだけを調整するのを避けるためです。

保存する案を採る時も、次の会話で使える状態かを確かめます。対象者の取り違え、期限切れ、本人の訂正がないかを確認できないなら、古い記録を確定情報として返さない手順が必要です。個人的な情報は便利そうだから広く共有するのではなく、本人が理解した目的と範囲に限定する設計を検討します。ここでの提案は、現在のBASに特定の保存機能があるという説明ではありません。

振る舞いの境界は、丁寧な言葉を使うかどうかだけでは決まりません。レイは、何を説明してよいか、どの判断を利用者へ戻すか、どんな時に担当外と伝えるかを、場面ごとの返答例にします。灯が文章を整理する役なら、根拠のない事実を補って完成させないことや、重要な決定の意味を勝手に変えないことが候補になります。話し方と行為の範囲を一緒に確認します。

紙の上で、利用者が曖昧な感想を相談した場面と、正式な約束を含む文章を頼んだ場面を並べます。どちらも親しみやすく返せても、必要な確認は異なります。内容が不明なまま約束を増やす返答と、決まっている条件を先に聞く返答を比較します。キャラクターらしい言葉へ直す前に、返答の中で新しく引き受けたことがないかを見ます。

専門家へ渡す条件を考える時には、実際に紹介できる相手や窓口があるかも確認します。「担当につなぎます」と言いながら渡す先がない設計では、言葉だけの安心を作ってしまいます。渡せない場合は、その状態を伝えて必要な相談先を探す範囲を定めます。能力の説明、利用者への案内、内部の担当表が同じ状態を指すかを、運用の確認事項にします。

断り方にも比較の余地があります。短く限界だけを伝える案と、できる範囲の整理を一つ添える案を用意し、用件が置き去りにならないかを見ます。ただし親しさを演出するために、断る理由を架空の個人的感情へ置き換えないようにします。境界がどこにあるかを読み手が理解できることを優先し、その上で灯らしい語彙や文章の長さを整えます。

複数のキャラクターがいるサービスでは、全員が何でも同じように答えると、選ぶ理由を説明しにくくなります。レイは、入口の質問、判断の支援、根拠の検討など、役割ごとの成果物を定める案を出します。灯なら相談の目的と未決事項を短くまとめるところまで、別の担当は資料の比較へ進む、といった分担です。能力を大きく見せるより、受け渡す内容を具体化します。

紙上の会話を三つの担当へ渡してみると、重複と抜けが見えます。全員が同じ確認質問を繰り返すなら、引き継ぐ要約が不足しているかもしれません。一方、前の担当が確認済みだと思い込んで誰も尋ねない条件もあり得ます。役割表には、受け取る情報、追加で聞くこと、返すものを書きます。性格の差だけで業務の境界を代用しないようにします。

利用者から「今回はそのまま詳しく説明して」と頼まれた場合に、いつも担当交代を強いる必要があるとは限りません。説明を少し深める範囲と、根拠の評価や外部への行為まで広げる範囲を区別します。担当の輪郭を守るために会話を不便にしすぎないよう、引き継ぎが必要になる条件を設定します。例外を認める時も、誰がどこまで引き受けたかが残るようにします。

評価するのは、利用者が担当名を覚えたかだけではありません。次に何が得られるかを予想できたか、同じ事情を話し直す必要がなかったか、断られた用件の行き先が分かったかを確認します。この時点で実績がなければ、想定会話の比較として記録します。役割の違いを表現する工夫が、実際の相談の進み方にどう関わるかを後で確かめられるようにしておきます。

成長の提案を正本へ入れる時は、会話中に出た一文をそのまま設定追加として扱わず、変更の理由と影響を確認します。レイの変更票には、現在の設定、新しい案、変更を望む理由、影響する場面、確認者を書く欄を置きます。灯に資料比較の役割を加える案なら、既存担当との分担も対象です。利用者の一時的な希望と、全体へ適用する変更を分けて審査します。

承認前の案は、仮の設定として試す範囲を明記します。社内の想定会話だけで試すのか、許可を得た限定テストへ進むのかを決め、未承認の説明が通常の応答へ混ざらないようにします。採用しない場合も、その理由を残せば、似た要望が来た時に再検討しやすくなります。拒否された案が消えたために同じ試行を繰り返す、という運用上の無駄を避けるためです。

採用後は、文章の正本だけでなく、返答例、担当の紹介、古い説明を含む資料も見直します。変更前の会話を新設定で説明し直すと、以前からその能力があったように見えるかもしれません。いつから変わったかを示し、過去の返答に必要な訂正があるかを個別に確認します。新しい設定を公開した時点を、過去の全記録を書き換える理由にはしない手順です。

紙上試行は、一件の設定変更票と変更前後の返答を一つずつ作るところまでで十分です。元へ戻す場合に残る影響も書き添えると、承認の判断が具体的になります。変更の整理を相談する入口はBrand Agent Studioです。ここで示した承認票は本稿の設計案であり、サービス上で自動的に設定管理や承認処理ができることを示すものではありません。