技術記事

「元気なときの声や話し方を、家族に残せないだろうか。」

写真や動画を保存しておくだけでは、家族が質問したときに本人の声が返ってくるわけではありません。本人に似た声と顔で思い出を話す仕組みを作るには、どのような技術が必要になるのでしょうか。

micomiaでは以前、仕事の進め方や判断基準を反映した「畑井駿佑AI」を紹介しました。自分の知識を参照しながら、システム開発の相談に対応するAIです。今回考えるのは、そこから対象を広げて、本人の声・顔・話し方・思い出を組み合わせるシステムになります。

「故人AI」や「デジタルヒューマン」といった言葉で紹介されることもありますが、実際には複数の技術を組み合わせて構築します。動画をアップロードするだけで、本人の人格や記憶がすべて再現されるわけではありません。生前の動画やインタビューを材料に、動画メッセージや対話型AIを組み立てるまでの構成と手順を順に紹介します。

1.本人を模したAIを4つの要素で考える

本人らしさを再現するには、まず対象を分けて考える必要があります。声・話し方・顔・記憶は、それぞれ使う技術も、用意すべきデータも異なります。

たとえば、本人に似た声が出せても、話している内容が一般的な回答であれば、本人らしい会話にはなりません。反対に、思い出について正確に答えられても、言葉遣いや声が大きく違えば、受け取る印象は変わります。そのため「似ているか」という一つの評価で済ませず、何を再現できていて、どこに違和感があるのかを分けて確認します。

ここで扱うAIは、残された記録をもとに応答を生成するシステムです。本人の意識や人格そのものを保存するものではありません。

2.最初に「何を残すか」を決める

開発に入る前に、どのような体験を作るのかを決めます。同じ声や顔の素材を使う場合でも、目指す体験によって必要なシステムは変わります。

最初の試作では、動画メッセージ型が取り組みやすい構成です。本人が確認した短い文章を使えば、声と顔の再現度だけに絞って評価できます。

一方、「本人が実際に話した言葉を聞きたい」という目的であれば、記録検索型が合う場合もあります。質問への返答を新しく作らず、該当する映像をそのまま再生する方法です。

自由に質問できる対話生成型は、その後の段階として考えます。記録にない質問にも答えられるようにすると、本人が話していない内容まで生成する可能性があるため、回答範囲の設計が欠かせません。

3.動画から、声・顔・記憶のデータを整理する

3-1.元の動画は残し、用途ごとに素材を分ける

家族旅行の動画や本人へのインタビューには、声・顔・思い出が一緒に含まれています。ただし、すべての場面がそれぞれの機能に適しているとは限りません。

元の動画を保管したうえで、音声用の区間、アバター用の映像、文字起こしを別々に管理します。新しく撮影できる場合は、静かな場所で、無理のない長さに区切って話してもらいます。「子どもの頃は何をして遊んでいたか」「仕事で覚えている出来事は何か」など、一つずつ聞いていくと、後から整理しやすくなります。

3-2.文字起こしは、話し方用と検索用に分ける

文字起こしには二つの役割があります。一つは、本人がどのような言葉を使っていたかを確認することで、こちらは語尾や言い回しをできるだけ残します。もう一つは、思い出を検索しやすくすることで、こちらは人名の誤変換を修正し、長い話を一つの出来事ごとに整理します。

検索しやすくするためにすべてを整文してしまうと、本人特有の話し方が消えてしまいます。元の文字起こしと、検索用に整理した文章の両方を保持する構成が扱いやすいでしょう。

3-3.思い出には出典を付ける

検索用データには、文章だけでなく、元の動画と再生位置も持たせます。
以下は、データ構造を説明するための例です。

{
  "memory_id": "memory_001",
  "person_id": "person_001",
  "topic": "家族旅行",
  "text": "家族旅行では長野によく行っていた。朝にみんなで散歩する時間が好きだった。",
  "source_type": "本人のインタビュー",
  "source_file_id": "interview_001",
  "start_seconds": 125,
  "end_seconds": 167,
  "review_status": "本人確認済み",
  "access_group": "family_001"
}

本人が話した記録、家族から聞いた話、後から推測した内容は、同じ情報として混ぜないようにします。また「昔はそう考えていたが、後に考えが変わった」ということもあります。収録日や発言した時期を残しておくと、異なる時期の記録を一つの考え方としてまとめてしまうことを防ぎやすくなります。

4.本人に似た声を作る

声の再現には、本人の録音から特徴を取り出し、新しい文章を似た声で読み上げる音声クローンを使います。音声クローンにも、音声サンプルを生成時の手がかりとして使う方式と、追加学習を行う方式があります。

たとえばElevenLabsでは、Instant Voice CloningとProfessional Voice Cloningで仕組みが異なります。前者は既存の学習内容をもとに近い声を推測する方式で、後者は30分から180分程度の音声で専用のモデルを学習させる方式です。「音声ファイルを登録した」という操作が、常にモデルの追加学習を意味するわけではありません（ElevenLabsの音声クローン解説）。

実装では、利用するサービスで作成・利用が認められた音声のIDを管理し、読み上げたい文章と組み合わせて音声合成を呼び出します。ただし、声質が似ていても、本人らしい話し方になるとは限りません。丁寧な文章ばかり生成すれば、普段くだけた話し方をする人でも改まった印象になるため、文章を作る部分と、声にする部分の両方を調整します。

4-1.日本語で確認したいこと

家族向けの利用では、人名や呼び名の読み間違いが特に目立ちます。

• 家族の名前や、普段使っていた呼び名を正しく読めるか

• 地名や方言のアクセントに違和感がないか

• 語尾が伸びすぎたり、不自然な場所で区切れたりしないか

• 短い返答と長い説明の両方で、声の印象が保たれるか

読み方の調整が必要な場合は、画面に表示する文章と音声合成に渡す文章を分け、対応するサービスでは発音辞書も使います。必要な録音量や再現できる抑揚は方式によって異なるため、最初から「動画が何分あれば十分」と決めず、使う機能の要件を確認したうえで、手元の素材で短い文章を試作します。

なお、本人の録音をそのまま再生できる場面では、音声クローンを使わずに原音を使う構成も選べます。

5.顔を動かし、動画メッセージにする

AIアバターは、写真や動画をもとに、顔や口の動きを生成する部分です。音声に合わせて口を動かす処理は、リップシンクと呼ばれます。

たとえばHeyGenのAudio to Videoでは、利用可能なアバターや画像に音声ファイルを渡して、話している動画を生成できます。処理は非同期で実行され、動画IDを受け取ったあとに状態を確認し、完了してから動画を取得する仕組みとなっています（HeyGen Audio to Video）。

動画メッセージ型は、次の順序で作れます。

1. 本人が話す文章を作り、内容を確認する

2. 本人の録音、または利用可能なクローン音声で音声を用意する

3. 音声とアバターを動画生成サービスに渡す

4. 完成した動画の発音・口の動き・表情を確認する

5. 確認済みの動画を、家族向けの画面などから再生できるようにする

システム側では、動画生成のジョブIDと「生成待ち・生成中・完了・失敗」の状態を保存します。画面を閉じても処理を追跡できるようにし、失敗した場合だけ再実行できる構成にします。同じ操作の二重送信で動画が重複生成されないよう、アプリ側の依頼IDも管理しておくと運用しやすくなります。

アバターの評価では、顔の似具合に加えて、視線、まばたき、口の開き方、手や体の動きも確認します。顔が似ているほど、小さな動きの違いが気になる場合もあるためです。

6.本人の記憶と話し方を回答に反映する

6-1.思い出はRAGで参照する

「昔、家族でどこへ旅行した？」という質問に答えるには、本人の記録を参照する仕組みが必要です。ここで使えるのがRAGで、質問に関係する資料を検索し、その内容を生成AIに渡して回答を作ります。記録の検索と回答生成を組み合わせる方式であり、資料を登録するたびにモデルそのものを追加学習する仕組みではありません（Google CloudのRAG解説）。

本人AIでは、次のように処理します。

1. 利用者が、その人物のどの記録を閲覧できるかを確認する

2. 閲覧可能な記録の中から、質問に関連する思い出を検索する

3. 該当する文章と出典を生成AIに渡す

4. 記録に基づく回答文を作る

5. 回答と一緒に、参照した動画や文章を表示する

検索対象の制限は、生成AIに「他の家族の情報を出さないでください」と指示するだけでは不十分です。サーバー側で利用者と人物・家族の対応を確認し、検索する前に対象を絞ります。

micomiaで紹介した園芸の知識を学習したAI社長でも、動画を知識として活用する際のデータ整備や、RAGとファインチューニングの違いを扱っています。本人の思い出を扱う場合も、資料をどのように整理するかが回答の質に直結します。

6-2.話し方は、具体例から整理する

話し方の指定は、「優しい性格」「明るい人」といった抽象的な説明だけでは調整しにくくなります。実際の会話から、文章の長さ、よく使う語尾、家族の呼び方、説明の順序を整理し、短い会話例として渡します。たとえば、次のようなプロンプトを出発点にできます。

役割:
本人が残した記録をもとに、家族の質問に答えるAIです。

回答内容:
- 本人の経験に関する回答は、渡された記録を根拠にしてください。
- 記録にない出来事、感情、約束を作らないでください。
- 根拠が見つからない場合は、その旨を短く伝えてください。
- 記録に食い違いがある場合は、一つに決めつけないでください。

話し方:
- 本人の会話例にある語尾と、説明の長さを参考にしてください。
- 口癖を毎回繰り返すなど、特徴を強調しすぎないでください。
- 家族の呼び方は、確認済みの設定を使ってください。

出力:
- answer_text: 読み上げる文章
- source_ids: 回答の根拠にした記録のID
- answer_status: grounded / insufficient / conflicting

これは設計例であり、プロンプトだけで誤った生成を完全に防ぐことはできません。サーバー側では、返された出典IDが実際に渡した記録に含まれるか、必要な項目が揃っているかを確認します。記録が取得できない場合や処理に失敗した場合は、決めておいた案内文に切り替えます。出典が付いていても、その出典が回答を裏付けているかは別途検証が必要です。

6-3.「知らない」と答える範囲を作る

先ほどのサンプルの記録には、長野へ旅行したことと、朝の散歩が好きだったことが書かれています。「旅行では何が好きだった？」には答えられますが、「泊まった旅館の名前は？」の答えはありません。

後者に対して、ありそうな旅館名を生成してしまうと、事実と違う思い出が生まれてしまいます。この場合は、「残っている記録では、旅館の名前までは確認できません」と伝える設計にします。

また、新しく生成した会話を、そのまま「本人の記憶」として再登録しないようにします。元の記録とAIの会話履歴を分けておくことで、生成した内容が次の回答の根拠になる循環を避けられます。

7.リアルタイムで会話できる構成にする

動画メッセージの次の段階として、利用者の声を受け取り、その場で返答する構成を考えます。会話中は、次の順序で処理が流れます。

1. 利用者が画面のマイクから質問を話す

2. 音声認識が質問を文字に変換する

3. 会話サーバーが利用者の権限を確認し、閲覧できる記録の中から関連する思い出を検索する

4. 話し方の設定と検索結果を合わせて、回答生成のLLMへ渡す

5. 返ってきた回答の出典と出力形式をサーバー側で確認する

6. 確認を通った回答文を音声合成へ渡す

7. リアルタイムアバターが音声に合わせた映像を生成し、利用者の画面へ音声と映像を返す

8. 同時に、回答文と参照した記録を画面に表示する

会話サーバーは、ログインの確認、記録の検索、各AIへの依頼、失敗時の処理をまとめる部分です。外部サービスのAPIキーはサーバー側で管理し、利用者の画面には配布しません。

7-1.技術を役割ごとに選ぶ

これは役割ごとの候補であり、この組み合わせの動作検証結果ではありません。採用前に、必要な機能の提供範囲と、音声形式・接続方式の対応を確認します。音声認識は人が話した音声を文字に変換する処理で、Google Cloud Speech-to-Textなどを使い、その文字列を検索や回答生成へ渡します。

リアルタイム映像については、LiveAvatarのAvatar Only（LITEモード）のように、音声認識・LLM・音声合成を自分たちで用意し、映像の生成をサービス側に任せる構成があります（LiveAvatar LITEモードの説明）。

完成した動画ファイルを生成するAPIと、会話中に映像を配信するAPIでは役割が違います。動画生成用に用意したアバターが、そのままリアルタイム用途でも使えるかは、採用するサービスで確認が必要です。

7-2.会話では、待ち時間と中断処理が重要になる

自然に会話できるかどうかは、回答の内容だけでは決まりません。利用者が話し終わってから、音声認識、検索、文章生成、音声合成、映像生成を順に待つと、返答までの時間が長くなります。

そのため、対応するサービスでは、回答を短い文のまとまりで音声合成へ渡すなど、処理を少しずつ進めます。ただし、根拠の確認前に読み上げてしまうと、誤った文章を途中から訂正できません。何を確認してから音声にするのかを、あらかじめ決めておきます。

また、利用者が「もう一度」「ちょっと待って」と話した場合は、再生中の音声と映像、待機中の音声データを止め、新しい質問に切り替える必要があります。音声と映像を別々に再生するとずれやすいため、対応するリアルタイム配信の仕組みで同期させます。これらは、動画を一度生成するだけの構成にはない開発項目です。

8.生前に作る場合と、故人の資料から作る場合

技術を選ぶうえで大きな違いになるのが、本人が素材の準備や確認に参加できるかどうかです。

たとえば、ElevenLabsのProfessional Voice Cloningは自分自身の声を対象としており、声の確認手続きを求めています。本人の許可があっても他人の声では作成できないと明記されているため、開発者が手元の音声だけで誰の声でも作れる機能としては扱えません（ElevenLabs Professional Voice Cloning）。

HeyGenでも、動画から本人のアバターを作る際には、本人による同意動画の提出を求める手順があります（HeyGenの同意動画の案内）。家族が了承していることと、利用サービスの手続きを満たせることは別に確認します。故人の素材から作れるかどうかは、対象の機能と条件を確認してから判断する必要があります。

本人が参加できる段階では、声や顔を作ることに加えて、次の内容も記録しておきます。

• 誰が利用できるか、一般公開してよいか

• 確認済みのメッセージだけを再生するか、新しい回答も生成するか

• 話してよい内容と、家族だけに残す内容

• 利用を止める場合や、本人が亡くなった後の管理担当者

長く残す目的であれば、元の動画、文字起こし、確認済みのメッセージを取り出せる構成にしておくことも大切です。特定のサービス上にあるクローン音声やアバターを、別のサービスへ移せるとは限りません。

削除機能を作る場合は、画面上の人物データだけでなく、保存した素材、検索用データ、生成済み動画、外部サービス上のデータまで対象を整理します。

9.小さく作り、本人らしさを検証する

9-1.まず一つのメッセージと、一つの話題で試す

最初から人生全体の記録とリアルタイム映像を組み合わせると、問題が起きた場所を見分けにくくなります。次の順番で、確認する対象を増やしていく構成が考えられます。

用途が動画メッセージで満たせる場合は、段階3までで成立します。

9-2.評価する質問を先に用意する

記録を登録してから何となく会話するだけでは、回答品質を比較しにくくなります。検証用の質問と、参照すべき記録を先に用意しておきます。

回答内容の評価と、声・顔の印象の評価は分けて記録します。「声がよく似ているので内容も正しい気がする」という判断を避けるためです。

待ち時間は、「利用者が話し終わってから最初の返答音声が聞こえるまで」など、測る区間を揃えます。平均値だけでなく、待ち時間が長くなるケースや通信が不安定な場合も確認します。

9-3.高齢の方が使う画面は、操作を絞る

本人が高齢の場合も、利用する家族が高齢の場合も、画面の操作が負担になると使い続けにくくなります。最初の画面には、大きな「話す」「止める」「もう一度聞く」のボタンを用意し、必要に応じて文字でも質問できるようにします。返答は字幕を表示し、音量や文字サイズを変更できる構成にします。

話す途中の間を質問の終わりと判定してしまう場合は、話し終わりをボタンで知らせる方式も候補になります。自動判定にするか、ボタン式にするかは、実際に使う方に試してもらって決めます。

画面では、本人の元の映像と、AIが生成した応答を区別できるようにします。回答の根拠になった動画も開けるようにすると、思い出を確認する体験につながります。

9-4.費用は、制作費と継続利用費に分ける

動画を数本作って納品する場合と、毎日会話できるシステムでは、費用の発生の仕方が異なります。

概算では、月に何人が、何回、何分使うかを置き、各サービスの課金単位に換算します。LLMは入出力のトークン数、音声は文字数や時間、映像は生成時間や接続時間など、課金単位が揃っているとは限りません。無料枠や最低プランだけで見積もらず、試作で実際の使用量を記録してから、継続利用時の費用を算出します。

10.本人の記録を残すために、どこまでAIを使うか

本人の声・顔・話し方を模したAIは、音声クローン、AIアバター、記録の検索、回答生成を組み合わせることで構成できます。ただし、どの機能も最初から必要とは限りません。

家族に残すメッセージであれば、本人が確認した動画が適しているかもしれません。本人の言葉をそのまま聞きたい場合は、記録検索型が役立ちます。質問に応じて思い出をたどりたい場合は、出典を確認できる対話型の構成が考えられます。

先に決めたいのは、「誰が、どんな場面で、何を受け取れるようにしたいか」です。その目的に合わせて、記録の保存とAIによる生成の範囲を設計します。こうした構成は、家族の思い出を残す用途だけでなく、専門家の経験や経営者の判断基準を伝えるAIにも応用できます。

micomiaでは、資料や専門知識を活用したAI、RAG、ローカルLLMを使ったシステムについて、要件整理から設計・開発まで対応しています。声やアバターを含む構成についても、利用目的と素材の条件を整理するところからご相談いただけます。

関連記事：自分をコピーしたAIを作ってみた｜ローカルLLMで自分の業務をそのまま代行する

関連記事：【社長の知識をAIに】園芸の知識を学習したAI社長を開発しました。

※紹介した外部サービスの仕様・利用条件は、2026年9月16日時点の公式情報をもとにしています。