故人のテキストメッセージや音声データを学習させ、生前の話し方を再現するチャットボットを「deadbot（デッドボット、死者を模したAIボット）」と呼びます。
この種のサービスを個人開発で作ろうとしている方、あるいは類似の「人格模倣型AI」を業務で扱っているエンジニアに向けて、技術的な落とし穴を整理します。感情面の是非ではなく、実装上どこに問題が生じやすいかに絞って解説します。
デジタル遺産（digital legacy、故人が残したデータやアカウントの扱い）市場は、Zion Market Researchの調査によると2024年時点で約224.6億ドル規模とされ、2034年までに3倍以上に拡大する見込みです。Eternosという企業は2024年のサービス開始以降、400人以上に「AIデジタルツイン」を提供しています。利用者は300のフレーズを録音し、人生観や人間関係についての質問に答え、2日間の計算処理を経て音声モデルが生成されます。単なる録音の再生ではなく、話し方のパターンやリズムを学習したうえで新しい発話を生成する仕組みです。
何が起きるか：意図しない発言の生成
この手のシステムで実際に起きるのは、学習元データにない発言をLLM（大規模言語モデル）が「それらしく」生成してしまう現象です。
故人が言ったことのない政治的意見や、家族間の対立に踏み込む発言を、モデルが文脈から補完して出力するケースが考えられます。これは一般的な生成AIの「ハルシネーション（幻覚、事実に基づかない出力を生成する現象）」と同じ原理です。
You, Only Virtual（YOV）というサービスは、テキストメッセージや音声、動画クリップを提供すると2〜3か月後に「Versona」と呼ばれる人格モデルがリンクで届く仕組みを取っています。ここで問題になるのは、学習データが少ない話題について尋ねられたとき、モデルが沈黙するのではなく生成を続けてしまう点です。
なぜ起きるか：段階的に原因を分解する
原因は主に3層に分けて考えられます。
1つ目は学習データの偏りです。テキストメッセージや音声は、その人の人生のごく一部しか記録していません。感情的なやり取りや日常会話に偏り、専門的な判断や込み入った価値観の表明は記録されにくい傾向があります。
2つ目はプロンプト設計の甘さです。人格模倣型のシステムプロンプト（AIに与える振る舞いの指示文）で「この人物になりきって答えてください」とだけ指示すると、モデルは知識の穴を埋めるために創作を始めます。本来は「わからないことは推測せず、そう答える」という制約を明示的に組み込む必要があります。
3つ目はガードレール（AIの出力を制限する仕組み）の不在です。政治・宗教・家族間の対立など、センシティブな話題を検出して応答を止める仕組みがなければ、モデルは求められるまま発言を続けます。Project Decemberのように GPT-3ベースで構築されたサービスは、この種のフィルタリングを後付けで追加する設計になっていることが多く、初期バージョンほどこの問題が起きやすい構造です。
自分のプロジェクトが該当するか確認する
人格模倣型のAIアプリケーションを開発・運用している場合、以下の観点で確認できます。
- システムプロンプトに「不明な場合は憶測で答えない」という制約が明記されているか
- ファインチューニング（追加学習）またはRAG（検索拡張生成、外部データを検索して回答に反映する仕組み）のどちらでデータを扱っているか
- 出力ログに対して、事実確認できない発言をフラグ立てする仕組みがあるか
- センシティブな話題（政治・宗教・対立関係）を検出するフィルタが入り口・出口のどちらに配置されているか
RAG方式であれば、参照元データが見つからない質問に対して「該当する記録がありません」と返す設計が比較的作りやすくなります。一方、ファインチューニングのみで人格を学習させた場合、モデル内部に知識が溶け込むため、発言の出所を後から追跡しにくいという弱点があります。どちらの方式を採用しているかは、実装のアーキテクチャドキュメントかモデル呼び出し部分のコードで確認できます。
対策の手順
実装レベルで取れる対策を、優先度順に示します。
1. システムプロンプトに明示的な制約を追加する
例：「学習データに根拠のない発言は生成しないこと。
不明な質問には『それについては話した記録がありません』と回答すること」
2. RAGアーキテクチャを採用し、根拠となる原文を必ず引用可能にする
（出力に対して参照元のメッセージIDや日時を紐付ける）
3. センシティブトピック検出を出力側に配置する
政治・宗教・対立関係などのキーワードを含む応答を
人間のレビューまたは追加確認フローに回す
4. 利用者（遺族）向けに「これはAIの生成物であり、
本人の発言そのものではない」という表示を常時つけるこのうち特に見落とされやすいのが4番目です。UI上での注記は技術的対策ではありませんが、利用者が生成結果を実際の発言と誤認するリスクを減らす、実装コストの低い防御策になります。
また、開発初期段階でモデルのバージョンを固定し、後から挙動が変わっていないか確認できるようにしておくことも欠かせません。GPTやClaude系のモデルは頻繁にアップデートされるため、同じプロンプトでも出力の傾向が変わることがあります。人格模倣という性質上、出力の一貫性が信頼性に直結するため、モデルのバージョン管理とプロンプトのバージョン管理は必ずセットで行う必要があります。
まとめ
人格模倣型AIの開発では、学習データの偏り・プロンプト設計・ガードレールの不在という3段階の原因が積み重なって、意図しない発言の生成につながります。
自分のプロジェクトを点検するなら、まずシステムプロンプトの制約を見直し、RAGとファインチューニングのどちらを使っているかを確認するところから始められます。
センシティブトピックの検出フィルタが入り口・出口どちらにあるかも、実装コードを読めばすぐにわかる項目です。
人格模倣という機能そのものの是非は開発者だけで判断できる話ではありませんが、技術的な誤生成のリスクを減らす手立ては、今のアーキテクチャを見直すだけでも十分に打てます。