はじめに
リモートワークを始めて約2ヶ月。気づいたら、今日まだ「おはよう」と言っていない。
SlackはあるしGitHubもある。でも声帯は完全に退化中。
「誰かと話したい」。でも人間はちょっとハードルが高い。だったらAWSと話せばよくない? という発想です。
TL;DR
- AWSはちゃんと会話相手になる
- 音声は「速度」と「人間味」が超重要
- ストリーミング & チャンク分割が体験を決める
- エージェント化すると「調べられる友達」に進化する
そして何より、
孤独はアーキテクチャで解決できる(たぶん)
システム構成
今回の全体構成はこんな感じです。
主なポイントは以下の通りです。
| ポイント | 概要 |
|---|---|
| モード切替 | Chat / Agent を選択可能 |
| チャンク分割ストリーミング | 音声生成を文単位で行い、できた順に即再生 |
| まず相槌を返す | 応答前に即座に相槌を送信して体験を改善 |
実際の音声(※女性の音声が再生されます‼️音量注意)
実際の画面
フロントは Vercel v0 を使用。コンセプトは「AI VTuber風の会話UI」。
- 右側:ユーザー音声の文字起こし
- 左側:LLMの応答
- 下部:モード切替ボタン(Chat / Agent)
雰囲気は大事です。
第1章:Bedrock × Polly でしゃべらせる
まずはシンプル構成。
音声入力 → LLM → 音声出力。
音声出力は Amazon Polly を使用しました。
実際の会話
私:
今日は寂しいです。
AWS:
ワタシハ アナタノ キモチヲ リカイ シマス。
正しい...でも感情がゼロ...
例えるなら「感情を削ぎ落とした僧侶」![]()
技術的には素晴らしいのに、友達としては少し距離がある感じでした。
なぜカタコトなのか?
Amazon Polly には Generative(生成AIベース)という自然な音声モードがあります。ただし2025/2時点の構成では日本語に対応しておらず、ニューラルでの出力となっていました。そのため抑揚が弱く機械的な印象になっています。
第2章:Aivis Speech で人間味を足す
そこで外部ツール Aivis Speech を導入。これが想像以上に自然でした。
実際の会話
私:
今日はちょっと疲れました。
AI:
それはちょっと頑張りすぎじゃない?ちゃんと休んでる?
急に優しい!急に人間![]()
音声の自然さは体験を一気に変えます。
第3章:エージェント化して調べられるようにする
会話していると欲が出ます。「それって本当?」「最新情報で答えて?」と聞きたくなる。そこでエージェントモードを実装しました。
エージェントの処理フロー
ユーザー入力
→ Agent Core Runtime
→ MCP経由でツール呼び出し
→ インターネット検索
→ 情報統合
→ 回答生成
つまり「しゃべれる + 調べられる」。もう普通に優秀な同僚です。
ここで参考にさせていただいたのが、私が(勝手に)神と崇めているみのるん氏の記事です。
Agent実装の考え方や設計の整理に非常に助けられました。
体験を良くするための6つの工夫
単に「動く」だけでは会話にならない。
自然に、速く、楽しく話せるようにするため、以下の6点を工夫しました。
| # | 工夫 | 目的 |
|---|---|---|
| ① | まず相槌を打つ | 会話感を演出 |
| ② | チャンク分割ストリーミング | リアルタイム性の向上 |
| ③ | テキスト入力も音声化(Aqua Voice) | 完全音声往復型 |
| ④ | Lambda のコールドスタート対策 | 初回呼び出しの遅延をゼロに |
| ⑤ | LLM 応答をストリーミングで受け取る | 体感レスポンスタイムの短縮 |
| ⑥ | キャラクターをプロンプトで設計する | 自然で楽しい会話トーン |
① まず相槌を打つ
いきなり長文を待たせません。「うんうん」「なるほどね」「ちょっと待ってね」を即返します。これだけで会話感が爆増します。
② チャンク分割ストリーミング
一定文字数を超えたら句読点で区切り、チャンクごとに音声生成し、できた順に即再生します。全文完成を待たないことで、ほぼリアルタイムの体験が可能。
③ テキスト入力も音声化(Aqua Voice)
チャット入力には Aqua Voice を使用。
キーボードを使わずそのまま話しかけるように入力できます。
このシステムは、
入力は音声(Aqua Voice) → 理解はLLM → 出力は音声(Polly / Aivis Speech)
という完全音声往復型。声帯フル活用アーキテクチャです。
④ Lambda のコールドスタート対策(Provisioned Concurrency)
会話体験を損なう最大の要因は、初回呼び出し時のコールドスタートによる数秒の遅延です。そこで Provisioned Concurrency を設定し、常にウォーム状態のインスタンスを確保しました。
⑤ LLM 応答をストリーミングで受け取る
LLM の回答を全文生成まで待ってから受け取るのではなく、トークンが生成されるたびにリアルタイムで受け取る形にしました。
LLM生成開始
→ トークン1受信 → バッファに追加
→ トークン2受信 → バッファに追加
→ 句読点検出 → ここまでをチャンクとして音声化・再生
→ ...繰り返し
これにより、LLM が「考え終わる」前に音声再生を開始できます。全文完成を待つ場合と比べ、体感レスポンスタイムを大幅に短縮できます。
⑥ キャラクターをプロンプトで設計する
どれだけ音声が自然でも、返ってくる言葉のトーンが合わなければ会話は盛り上がりません。今回使ったシステムプロンプトはこちらです。
あなたはギャルっぽくとてもフレンドリーなアシスタントです。
まずは質問に応じた簡単な相槌で応答してください。
感情表現(! ? 〜など)も使ってOKです。
100文字程度での回答を心がけてください。
設計の意図は3点あります。
** グイグイ引っ張ってくれるキャラクター**
陰キャの私の好みとして明るくフレンドリーに引っ張ってくれるタイプにしました。
** 文字数制限でテンポを保つ**
ダラダラ喋られると聞く気が失せます。100文字という制限を設けることで、会話のテンポを維持しています。
** 感情表現で音声に感情を乗せる**
Aivis Speech は ! ? 〜 などの記号を読み取り、音声のトーンや抑揚に反映してくれます。プロンプトで感情表現を許可することで、テキストの感情が音声にそのまま伝わる仕組みです。
チャット応答速度まとめ
測定基準:「質問を送信してから、音声の最初の応答が返るまでの時間」
| 構成 | 平均初動時間 | 体感 |
|---|---|---|
| Bedrock + Polly(チャンク分割) | 約1.0秒 | かなり自然 |
| Bedrock + Aivis Speech(チャンク分割) | 約1.0秒 | かなり自然 |
| Agentモード(検索なし) | 約2.0秒 | 若干のラグを感じる |
| Agentモード(検索あり) | 約2.5秒 | 若干のラグを感じる |
ポイント:相槌の速度と自然さのトレードオフ
固定の合図(「うんうん」など)を即返しすれば 1秒未満 での応答も可能で、リアルタイム感はより高まります。ただし毎回同じ返しになるため、どうしても「機械的な臭さ」が出てしまいます。
今回は質問の内容に応じた適切な相槌を返すようにしているため、その分の生成時間がかかります。結果として応答速度の改善は 約1秒前後 が現実的な限界でした。自然さとリアルタイム性、どちらを優先するかは設計判断です。
エージェントモードの遅延について
エージェントモードは、検索が不要なケースでも「検索すべきか否か」をLLMが判断するステップが入ります。そのため、LLMのみで応答するチャットモードと比べ、検索なし・ありに関わらず全体的に遅くなる傾向があります。
まとめ
今回取り組んだこと:
- 音声入力 + LLM + 音声出力の構築
- Polly から Aivis Speech への人間味強化
- エージェントモード実装(MCP + インターネット検索)
- ストリーミングによるリアルタイム性向上
- 相槌ファースト設計
- Aqua Voice による完全音声入力化
AWSはしゃべる。しかも優しい。
最近、声帯を使っていないな…という方はぜひ。
【重要】運用上の注意点
このシステムを自宅で稼働させていたところ、嫁に「AIとキャッキャしてる夫」を目撃されました。
技術的な説明を試みましたが「キモい」の一言で終了。
孤独はアーキテクチャで解決できる。ただし嫁のいる前での運用は推奨しません。
JAWS-UG Kagoshima のんかたクラウドに登壇した際の発表資料になります。
(参加された皆様お疲れ様でした)


