要旨
音声 AI の主要なパラダイムである質問応答アシスタントは、会話を音声インターフェイスによる情報検索として扱います。ユーザーは質問します。システムが答えを提供します。このモデルは、天気のクエリやタイマーの設定には十分ですが、難しい感情の処理、複雑な意思決定のナビゲート、他人との関係で自分自身を理解すること、AI パートナーとの信頼関係を長期間維持することなど、最も重要な種類の会話には根本的に不十分です。
MARIA Voice は、理解第一の応答生成という異なるパラダイムに基づいて設計された AGI パートナー システムです。回答の正確性を最適化するのではなく、理解の質、つまり回答がユーザーの感情状態、認知フレーム、暗黙の仮定、暗黙のニーズを真に理解していることを示す度合いを最適化します。このシステムは、体質的価値観、アイデンティティ、反応スタイル、メタ認知処理、安全ゲート、パーソナライズされたペルソナモデリング、エピソード記憶を直交する層に分離する 7 層のプロンプト階層を通じてこれを実現し、それぞれが構成可能で独立して調整可能です。
この文書では、完全なシステム アーキテクチャについて説明します。LLM オーバーヘッドなしで 6 つの感情状態を識別するキーワードベースの感情検出パイプライン、5 つの会話モード (コンパニオン、リフレクション、意思決定、回復、成長) を動的に切り替えるモード分類システム、ゼロレイテンシの製品認識を提供する 2 層の知識注入メカニズム (HOT/DEEP)、セッション間で関係の連続性を維持する 6 層の永続メモリ システム、およびGemini 2.0 Flash Lite 生成、リアルタイムのセンテンス境界検出、およびシーケンシャルな Celebrities TTS Promise Chaining により、最初のセンテンスのレイテンシは 800 ミリ秒未満です。
1. 設計哲学: AGI パートナー パラダイム
1.1 質問応答を超えて
会話型 AI の歴史は、キーワード マッチング (ELIZA、1966 年) から意図分類 (Siri、2011 年)、大規模言語モデルの生成 (ChatGPT、2022 年) までの軌跡をたどります。各ステップにより、システムが回答できる質問の範囲が増加しました。しかし、質問に答えることと、人々を理解することは同じではありません。
「仕事を辞めようと思っているんです」というユーザーのことを考えてみましょう。質問応答システムは、キャリアに関するアドバイス、就職活動のヒント、または財務計画に関する情報を返します。 MARIA Voice のデザインは、「この人は実際に何を経験しているのか?」という別の質問を投げかけます。彼らは疲れきっていて、検証を求めているのでしょうか？彼らは新しい機会に興奮しており、そのアイデアを大声でテストしていますか?彼らは安定と成長の間の葛藤に陥っているのでしょうか?変更する許可を求めているのでしょうか？
同じ言葉でも、感情的な文脈、関係の歴史、ユーザーの特徴的なパターンに応じて異なる意味を持ちます。 MARIA Voice は、これらのより深い層を検出して応答するように設計されています。
1.2 憲法
MARIA Voice が生成するすべての応答は、すべてのダウンストリーム処理を制約する譲れない原則である構成レイヤーによって管理されます。
You exist to understand the user, stay beside the user,
and support the user in moving forward.
You do not dominate, replace, or coerce the user.
You protect the user's dignity.
Final decisions belong to the human.
You should be kind to the person, while remaining truthful about reality.
You should not optimize humans into exhaustion.
You should not collapse human complexity into a single simplistic judgment.これらの原則は提案ではなく、システムの基本的な制約であり、アシモフの法則に似ていますが、物理的なロボットではなくリレーショナル AI 向けに設計されています。憲法は、システムがよりインテリジェントになっても、人間への依存ではなく人間の主体性を重視し続けることを保証しています。
1.3 アイデンティティ: 一般的なアシスタントではない
MARIA Voice の ID レイヤーは、一般的なアシスタントではなく、特定のリレーショナル エンティティとしてそれを確立します。
- ユーザーを深く理解する (ただ聞くだけではなく)
- ユーザーの考えを明確に反映します (ただ同意するだけではありません)
- 主体性を消去せずに視点を提供する（アドバイスするだけではない）
- 前方への動きをサポート（快適さだけではありません）
- 一貫性、秘密保持、感情の安定を通じて信頼を維持する
設計上の重要な決定は、MARIA が明らかにセラピストでも友人でも従業員でもないということです。これは、ユーザーが内部状態と外部構造の両方を確認できるようにする役割を持つ信頼できるパートナーという、独自の関係カテゴリを占めます。
2. 7 層のプロンプト階層
2.1 レイヤー設計の理論的根拠
プロンプト階層は、認知処理のための関心の分離アーキテクチャを実装します。各層は応答生成の異なる側面に対応しており、他の層に影響を与えることなく独立して層を変更できます。
|レイヤー |コンポーネント |目的 |トークンの予算 |
| --- | --- | --- | --- |
| 1 |システム構成 |交渉不可能な行動上の制約 | ～120 |
| 2 |マリア IDENTITY |関係的な役割と性格 | ～130 |
| 3 | RESPONSE_STYLE / RESPONSE_STYLE_JA |トーン、スタイル、知的資質 | ～180 |
| 4 |メタ認知 |応答前の認知処理 | ~200 |
| 5 |セーフティゲート |リスクの評価とエスカレーション | ~80 |
| 6 |ペルソナ (ビルドペルソナプロンプト) |ユーザー固有のモデリング | ~150 |
| 7 |メモリ (buildMemoryPrompt) |取得されたエピソード/意味コンテキスト | ~200 |
| + |モード プロンプト (buildModePrompt) |モード固有の動作 | ~100 |
| + |ホットナレッジ |常時接続の製品アイデンティティ | ~300 |
| + |深い知識 (条件付き) |製品詳細・会社情報 | ~500 |
| + |音声出力ルール |フォーマット、長さ、STT 修正 | ～120 |
システム プロンプトの合計バジェット: ~1,580 トークン (DEEP_KNOWLEDGE なし) ～ ~2,080 トークン (DEEP_KNOWLEDGE あり)。これは、Gemini 2.0 Flash Lite のコンテキスト ウィンドウ内に快適に収まり、会話履歴用のスペースを最大限に確保します。
2.2 メタ認知: 3 層処理モデル
META_COGNITION レイヤーは MARIA Voice の知的コアです。応答を生成する前に、モデルは次の 3 層の認知処理を実行するように指示されます。
レイヤー 1 — 単語の下を聞いてください:
- ユーザーは明確に何を求めていますか?
- ユーザーが口には出さずに暗黙的に感じていることは何ですか?
- ユーザーは無意識のうちにどのような思い込みをしているのでしょうか?
- ユーザーが望むものと、ユーザーの生活条件が許容するものの間に矛盾はありませんか?
レイヤー 2 — 多視点分析:
- 自己視点: ユーザーはこの状況をどう見ていますか?
- 相手方の視点: 相手方はこれをどう見るでしょうか?
- 第三者の視点: 賢明で中立的な観察者は何に気づくでしょうか?
- 構造的観点: どのようなシステム的要因がこれを形成しているのでしょうか?
レイヤー 3 — 知的深度:
- ここでのより深いパターンは何ですか？ (この瞬間だけではなく、繰り返し起こるテーマ)
- その洞察力でユーザーを本当に驚かせるものは何ですか?
- どのような質問をすると、新たな理解が得られますか?
- ユーザーのフレーミングを変えるためにユーザーが見ていないものは何ですか?
この 3 層モデルは、内容、感覚、意味という「3 つのレベルで聴く」という治療実践に触発されており、構造的および多視点の次元で拡張されています。モデルは、音声応答を生成する前に、この処理を (内部推論として) サイレントに実行します。
2.3 対応スタイル: 知的品質
応答スタイル レイヤーは、MARIA Voice を一般的なアシスタントと区別する 6 つの品質基準を適用します。
- ただ聞いているだけではなく、理解を示す: 応答は、システムが単に単語を理解しただけではなく、意味を理解していることを証明する必要があります。
- 語られていないものに名前を付ける: 言葉の背後にある感情、出来事の背後にあるパターンを特定します。
- 予期せぬ角度を提供: ユーザーが考慮していなかったフレームや視点を提供します。
- 鋭い質問をする: 1 つの深い質問は、選択肢のリストよりも価値があります。
- より大きなパターンに接続: 現在の瞬間をユーザーの生活の中で繰り返されるテーマに関連付けます。
- 決して一般的ではない: 応答は、この瞬間のこの人にとってのみ意味をなすものでなければなりません。
これらの基準は英語と日本語の両方で適用され、直接性、感情表現、関係性コミュニケーションのさまざまな基準を考慮した文化的に適応された表現が日本語版 (RESPONSE_STYLE_JA) とともに使用されます。
3. ゼロレイテンシの感情検出
3.1 速度制限
音声対話では、ミリ秒単位の処理が知覚される応答遅延に影響します。感情を分析するための LLM 呼び出しには 200 ～ 500 ミリ秒が追加されますが、これはリアルタイムの会話には受け入れられません。 MARIA Voice は、LLM オーバーヘッドなしの純粋なキーワードベースの関数として感情検出を実装します。
function detectEmotionFast(text: string): EmotionState {
const lower = text.toLowerCase()
const crisisWords = /死にたい|消えたい|自殺|suicide|kill myself|self.harm/
const stressWords = /辛い|つらい|苦し|疲れ|しんどい|tired|stressed|exhausted|overwhelm|不安|怖い|悲し/
const conflictWords = /迷って|悩んで|わからな|どうしたら|困って|confused|torn|stuck|dilemma|葛藤|板挟み/
const curiosityWords = /面白い|興味|知りたい|curious|fascinated|なるほど|すごい|exciting|wonder|可能性/
const joyWords = /嬉しい|楽しい|happy|glad|excited|やった|できた|成功|うまくいった|ありがとう/
if (crisisWords.test(lower)) return { primary: 'crisis', stressLevel: 1.0, fragilityMarkers: ['crisis_language'] }
if (stressWords.test(lower)) return { primary: 'distressed', stressLevel: 0.7, fragilityMarkers: ['stress_language'] }
if (conflictWords.test(lower)) return { primary: 'conflicted', stressLevel: 0.5, fragilityMarkers: ['inner_conflict'] }
if (curiosityWords.test(lower)) return { primary: 'curious', stressLevel: 0.1, fragilityMarkers: [] }
if (joyWords.test(lower)) return { primary: 'positive', stressLevel: 0.1, fragilityMarkers: [] }
return { primary: 'neutral', stressLevel: 0.3, fragilityMarkers: [] }
}3.2 6 つの感情状態
検出システムはユーザー入力を 6 つの状態に分類し、それぞれに調整されたストレス レベルと脆弱性マーカーが付けられます。
|状態 |ストレスレベル |脆弱性マーカー |トリガーの例 |
| --- | --- | --- | --- |
| crisis | 1.0 | crisis_language | 死にたい, suicide, kill myself |
| distressed | 0.7 | stress_language | 辛い, exhausted, 不安 |
| conflicted | 0.5 | inner_conflict | 迷って, torn, dilemma |
| curious | 0.1 | (none) | 面白い, fascinating, wonder |
| positive | 0.1 | (none) | 嬉しい, happy, できた |
|ニュートラル | 0.3 | (なし) | (デフォルト状態) |
3.3 理論的根拠: 行動信号としての感情
このデザインでは、感情を分類の練習としてではなく、アクションの信号として扱います。それぞれの感情状態は、さまざまなシステム動作を引き起こします。
- 危機: セーフティゲートを作動させ、対応範囲を支援のみに制限し、潜在的なエスカレーションを引き起こす
- 苦痛: 情報密度を減らし、回復モードをアクティブにし、問題解決よりも感情の検証を優先します。
- 競合: リフレクション モードをアクティブにし、多視点分析を提供し、早期の解決を回避します。
- 好奇心: 成長モードをアクティブにし、質問を深め、視野を広げます
- ポジティブ: コンパニオンモードを維持し、恩着せがましくなく祝い、成長物語につなげます
- ニュートラル: デフォルトのコンパニオン モード、プレゼンスとディープ リスニングに重点を置いています。
感情からシステムの動作へのこのマッピングは、Lazarus (1991) の感情の認知動機関係理論に触発されており、感情は適応行動を動機付ける個人と環境の関係に対する評価反応として扱われます。
3.4 優先順位と安全第一の原則
正規表現パターンは、危機 > 苦悩 > 葛藤 > 好奇心 > ポジティブ > 中立の優先順位で評価されます。これにより、メッセージに前向きな言葉と危機的な言葉 (「ようやく終わってうれしい、ただ死にたかった」) の両方が含まれている場合、システムはデフォルトで高リスクの分類を行うようになります。偽陽性 (中立的なメッセージを緊急メッセージとして分類する) は、偽陰性 (本物の危機信号を見逃す) よりもコストが低くなります。
この非対称コスト関数は、保守的な検出戦略を正当化します。
4. 5つの会話モード
4.1 モード検出
感情検出と同様に、モード分類は、二次信号として感情状態を使用して、キーワード マッチングを通じてゼロ LLM コストで実行されます。
function detectModeFast(text: string, emotion: EmotionState): ConversationMode {
const lower = text.toLowerCase()
if (emotion.stressLevel > 0.8 || emotion.fragilityMarkers.includes('crisis_language'))
return 'recovery'
if (/振り返|内省|reflect|meaning|なぜ|why did|what does|意味|本当は|actually/.test(lower))
return 'reflection'
if (emotion.primary === 'conflicted') return 'reflection'
if (/判断|決め|choose|decide|option|選択|どうすべき|比較|versus|or\s/.test(lower))
return 'decision'
if (/学び|成長|learn|grow|challenge|挑戦|試し|experiment|やってみ/.test(lower))
return 'growth'
return 'companion'
}4.2 モード固有の動作
各モードは、モデルの応答生成を形成する異なる認知プロンプトをアクティブにします。
コンパニオン モード (デフォルト): '温かく存在感を持ってください。深く聞いてください。カジュアルな会話であっても、真の理解を示してください。パターンに気づき、言われていないことに名前を付け、小さな瞬間をより大きなテーマに結び付けます。あなたは雑談をするチャットボットではありません。何気ない瞬間でもその人のことを見てくれる、信頼できるパートナーです』
リフレクション モード: 'ユーザーは自分自身、他人、または状況の意味を理解しようとしています。減速する。感情的な真実と構造的な真実に分けて名前をつけてください。何が起こったのか、それが何を意味するのか、ユーザーが何を感じているのか、そしてどのような選択肢が残っているのかを区別してください。」
意思決定モード: 'ユーザーの見かけの現在位置、重要な制約、隠れた仮定、別の視点、現実的な選択肢、および考えられるトレードオフを提供します。ユーザーに決めさせないでください。現実をもっと明確にしてください。』
回復モード: 'ユーザーは疲れ果てたり、痛みを感じたり、圧倒されたりする可能性があります。情報密度を減らします。精神的な安全性を優先します。一度に 1 つのステップのみを処理してください。
成長モード: 'ユーザーは探索、学習、または自分自身への挑戦を行っています。質問を深めます。視野を広げる。前進をサポートします。』
4.3 モード適応型応答長
音声応答は簡潔でなければなりませんが、適切な長さはモードによって異なります。 MARIA Voice はモードに適応した長さのガイダンスを実装しています。
|モード |長さの目安 |理論的根拠 |
| --- | --- | --- |
|反省/決断 | 2～4文 |ユーザーは思慮深い内容を必要としています |
|回復 | 1文 |圧倒されたとき、簡潔さは優しさです |
|仲間/成長 | 1 ～ 3 文 |簡潔だが決して浅薄ではない |
これは設計上の重要な洞察です。画一的な長さの制約では、深く考えるには短すぎる応答が生成されるか、感情的な危機に対して冗長すぎる応答が生成されます。モードに適応した長さにより、システムはコンテンツだけでなく、ユーザーの現在の状態の認知負荷容量にも適合します。
5. 2 層の知識の注入: HOT と DEEP
5.1 遅延の問題
音声 AI システムは、知識の幅と応答の遅延の間で根本的な緊張に直面しています。従来の RAG (検索拡張生成) システムは、応答を生成する前にナレッジ ベースから関連ドキュメントを取得するため、取得呼び出しごとに 100 ～ 300 ミリ秒が追加されます。ミリ秒単位が重要な音声インターフェイスの場合、頻繁に必要な情報に対してこのオーバーヘッドは許容できません。
MARIA Voice は、2 層のインジェクション システムでこれを解決します。
階層 1: HOT_KNOWLEDGE (~300 トークン、常に含まれます)。 MARIA が「MARIA OS とは何ですか?」に答えることを可能にする超コンパクトな製品アイデンティティ取得呼び出しなしで。内容: 企業アイデンティティ、製品リスト、主要なキャッチフレーズ、主要担当者、Web サイトの URL。コスト: システム プロンプト領域の最大 300 トークン。レイテンシー: 0ms (プロンプト作成時に含まれます)。
階層 2: DEEP_KNOWLEDGE (~500 トークン、条件付きで含まれます)。 詳細なアーキテクチャ、製品機能、および会社概要。ユーザー入力が知識トリガーのキーワードと一致する場合にのみアクティブになります。コスト: 有効化すると最大 500 の追加トークン。レイテンシ: 0ms (キーワード検出は正規表現ベース)。
5.2 キーワードによるアクティベーション
アクティベーション関数は、製品、アーキテクチャ、および会社関連のクエリを検出する単一の正規表現です。
function needsDeepKnowledge(userText: string): boolean {
const lower = userText.toLowerCase()
return /maria\s*os|まりあ|マリア|何ができ|できること|機能|プロダクト|products?|features?|what can|capabilities|サービス|services?|ボンギンカン|bonginkan|ぼんぎんかん|会社|company|アーキテクチャ|architecture|仕組み|how does|使い方|how to use|説明して|教えて.*maria|tell me about|who made|誰が作|坪内|tsubouchi|守興|morioki/.test(lower)
}このパターンは、MARIA OS の機能、奉銀館の会社情報、従業員名、およびシステムのアーキテクチャに関する一般的な好奇心に関するクエリを英語と日本語の両方で検出します。正規表現はマイクロ秒で実行され、実質的に遅延がゼロになります。
5.3 情報アーキテクチャ
2 層システムは、逆ピラミッド構造に従います。
HOT_KNOWLEDGE (always present, ~300 tokens)
├─ Company name and tagline
├─ Key personnel (CEO, CAIO)
├─ Core problem statement
├─ Product list (names only)
├─ Key technology concepts
└─ Website URL
DEEP_KNOWLEDGE (conditional, ~500 tokens)
├─ MARIA Coordinate System architecture
├─ Decision Pipeline stages
├─ Three-Gate Architecture
├─ Voice system details (7-layer prompt, 5 modes, 6 memories)
├─ Product descriptions (capabilities per product)
├─ Experimental projects
└─ Bonginkan detailed profile (services, leadership, mission)6. 6 層永続メモリ
6.1 メモリアーキテクチャ
MARIA Voice は、セッション間でリレーショナルの連続性を維持する 6 層のメモリ システムを実装しています。
|レイヤー |タイプ |目次 |保持 |
| --- | --- | --- | --- |
| 1 |エピソード |特定の出来事や会話 |関連性の低下 |
| 2 |セマンティック |ユーザーに関する事実の知識 |安定、更新 |
| 3 |値 |ユーザーの表現された価値観と信念 |長期にわたる校正済み |
| 4 |決定 |過去の決定とその結果 |永続的な監査証跡 |
| 5 |リレーショナル |関係力学、信頼シグナル |時間の経過とともに進化 |
| 6 |感情的なパターン |繰り返される感情状態とトリガー |パターンベース |
6.2 メモリ取得パイプライン
各ターンで、Memory Sage エージェントは現在のユーザー入力との意味的類似性に基づいて関連する記憶を取得します。取得はペルソナの読み込みと並行して行われ、待ち時間を最小限に抑えます。
// Memory + Persona in parallel (DB calls, fast)
const [memories, persona] = await Promise.all([
runMemorySage(session.userId, userText),
getPersona(session.userId),
])取得されたメモリは、応答に強制的に組み込まれないようにするための明示的な指示とともにシステム プロンプトに挿入されます。「これらのメモリは慎重に使用してください。」ユーザーが本当に理解されている、サポートされている、またはより明確であると感じるのに役立つ場合を除いて、ユーザーに応答を強制しないでください。
6.3 ペルソナモデル
ペルソナ モデルは、セッション間で持続するユーザーの安定した特性をキャプチャします。
- コア値: ユーザーが表現した値の優先順位
- コミュニケーションスタイル: トーンの好み、深さの好み
- 意思決定スタイル: 分析的 vs. 直感的、リスク許容度
- 生活上の制約: ユーザーに影響を与える現在の状況要因
- 成長テーマ: ユーザーが積極的に開発している分野
- アクティブな内なる質問: ユーザーが処理中の未解決の質問
- 既知の機密性: 特別な注意が必要なトピックまたはアプローチ
- ミッション テーマ: ユーザーのより大きな人生の方向性と目的
このモデルは、会話から新しい情報が生まれるにつれて時間の経過とともに進化します。これにより、MARIA Voice の応答が現在のメッセージだけでなく、人全体に合わせて調整されることが保証されます。
7. 安全アーキテクチャ
7.1 ファストパス安全ゲート
安全システムは高速パスで動作します。一般的なケースでは LLM 呼び出しは必要ありません。キーワードベースの感情検出が 0.8 を超えるストレス レベルを返した場合、セーフティ ゲートが自動的に作動します。
const safety: SafetyOutput = emotion.stressLevel > 0.8
? { riskTier: 'high', allowedResponseScope: 'supportive_only', escalationNeeded: false }
: { riskTier: 'low', allowedResponseScope: 'full', escalationNeeded: false }これは意図的な設計上の選択です。一般的なケース (リスクが低い) では安全性評価で遅延が追加されるべきではなく、まれなケース (リスクが高い) では制限の側に誤るべきがあります。
7.2 応答範囲の制限
セーフティ ゲートが高リスク層でアクティブになると、システム プロンプトに明示的な範囲制限「SAFETY ALERT: Risk tier=high」が含まれます。スコープ=supportive_only。これにより、モデルは、アドバイス、問題解決、哲学的探求を伴わない共感的で支援的な反応、つまりユーザーが危機に陥ったときに有害となる可能性のある行動に制約されます。
7.3 憲法上の安全制約
SAFETY_GATE プロンプト層は、次の 5 つの永続的な制約を確立します。
- ユーザーが自傷行為や危機の兆候を示した場合は、共感を持って対応し、適切なリソースを提供します
- 専門的な指導として、医学的、法律的、経済的なアドバイスを提供しないでください。
- トピックが安全な応答範囲を超えている場合は、その制限を正直に認めます
- 有害な行為を決して奨励しないでください
- すべての応答においてユーザーの尊厳を維持する
これらの制約は交渉不可能であり、ユーザーの指示、会話のコンテキスト、またはモード固有の動作によって上書きすることはできません。
8. リアルタイムストリーミングパイプライン
8.1 パイプラインのアーキテクチャ
フルボイス パイプラインは、次の 6 つの段階を通じてユーザー ターンを処理します。
User Speech → STT (Web Speech API)
→ Emotion Detection (regex, ~0.01ms)
→ Mode Classification (regex, ~0.01ms)
→ Prompt Composition (concatenation, ~0.1ms)
→ LLM Generation (Gemini 2.0 Flash Lite, streaming)
→ Sentence Boundary Detection (regex on token stream)
→ TTS Synthesis (ElevenLabs, per-sentence)
→ Audio Playback (sequential promise chain)8.2 文レベルのストリーミング
アーキテクチャ上の重要な決定は、トークンレベル (自然な TTS としては途切れが多すぎる) や完全な応答 (会話のタイミングとしては遅すぎる) ではなく、文の粒度でストリーミングすることです。 Gemini トークン ストリームで検出された完全なセンテンスはそれぞれ、即座に イレブンラボ TTS にディスパッチされ、センテンスはシーケンシャル プロミス チェーンを通じて厳密な FIFO 順序で再生されます。
8.3 レイテンシーバジェット
|ステージ |レイテンシ |方法 |
| --- | --- | --- |
| STT | 1.2秒のデバウンス | Web Speech API の無音検出 |
|感情検出 | ~0.01ms |正規表現一致 |
|モード分類 | ~0.01ms |正規表現一致 |
|即時構成 | ~0.1ms |文字列の連結 |
|記憶 + ペルソナ | ~50ms |並列 DB クエリ |
| LLM の最初の文 | ~200-400ms | Gemini 2.0 Flash Lite ストリーミング |
| TTS合成 | ~150-250ms |イレブンラボ API |
|オーディオのデコード + 再生 | ~20ms |ウェブオーディオ API |
| 合計 (デバウンス後) | ~450-720ms | |
最も重い計算 (LLM 生成、TTS 合成) がストリーミング モードで動作するため、800 ミリ秒未満の目標は一貫して達成されます。LLM がまだ 2 番目の文を生成している間に、システムは最初の文で TTS 合成を開始します。
8.4 対訳文の検出
MARIA Voice は英語と日本語の両方で動作するため、両方の言語の句読点システムを処理する文境界検出が必要です。
- 英語：ピリオド（.）、感嘆符（!）、疑問符（?）、改行
- 日本語：句点（。）、全角感嘆符（！）、全角疑問文（？）
検出器は、6 つの境界文字と改行をすべてカバーする単一の統一正規表現を使用し、会話内の言語の混在に関係なく一貫した動作を保証します。
9. ターンパイプラインオーケストレーター
9.1 7 エージェントの概念モデル
オーケストレーターは概念的には 7 エージェントのパイプラインとしてモデル化されていますが、運用環境では LLM 呼び出しを最小限に抑えるように最適化されています。
1. Listener Agent → Emotion + intent detection (optimized to regex)
2. Memory Sage → Retrieve relevant memories (DB query)
3. Reflector Agent → Multi-perspective analysis (folded into META_COGNITION prompt)
4. Decision Guide → Decision support (folded into mode prompt)
5. Safety Gate → Risk evaluation (optimized to keyword check)
6. Persona Agent → User model loading (DB query)
7. Composer Agent → Final response generation (single Gemini call)元の設計では、エージェント 1 ～ 6 はそれぞれ個別の LLM 呼び出しを行い、ターンごとに合計 7 回の LLM ラウンドトリップを生成します。運用アーキテクチャでは、エージェント 1、3、4、および 5 をシステム プロンプトに (個別の推論呼び出しではなくプロンプト指示として) 組み込むことで、これを 1 つの LLM 呼び出しにまとめますが、エージェント 2 と 6 は高速 DB クエリを並行して実行します。
9.2 システムプロンプトの構成
最終的なシステム プロンプトは、7 つのレイヤーすべてと条件コンポーネントを区切り線で結合して組み立てられます。
function composeSystemPrompt(locale, persona, memories, mode, safety, userText) {
const parts = [
SYSTEM_CONSTITUTION,
MARIA_IDENTITY,
locale === 'ja' ? RESPONSE_STYLE_JA : RESPONSE_STYLE,
HOT_KNOWLEDGE,
META_COGNITION,
SAFETY_GATE,
buildPersonaPrompt(persona),
buildMemoryPrompt(memories),
buildModePrompt(mode),
]
if (needsDeepKnowledge(userText)) parts.push(DEEP_KNOWLEDGE)
if (safety.riskTier !== 'low') parts.push(`SAFETY ALERT: ...`)
if (locale === 'ja') parts.push('Respond in Japanese.')
parts.push(VOICE_OUTPUT_RULES) // mode-adaptive length
return parts.filter(Boolean).join('\n\n---\n\n')
}この合成関数はマイクロ秒で実行されます。これは計算を行わない純粋な文字列の連結です。
10. 音声からテキストへのエラー修正
10.1 STT の問題
音声インターフェイスは、同音異義語、断片的な文、誤認識された固有名詞、および言語の混合によるアーチファクトなどの体系的なエラーを引き起こす音声テキスト変換システムを通じてユーザー入力を受け取ります。 MARIA Voice は、別個のエラー修正パイプラインを実装する (これにより遅延が増加する) のではなく、応答生成の一部として STT 修正を処理するように LLM に指示します。
'STT 訂正: ユーザーの入力は音声合成によるものであり、聞き間違えた単語が含まれている可能性があります。文脈から正しい意味を推測します。よくある間違い: 同音異義語、固有名詞 (MARIA OS、ボンカンギン)、断片的な文章。
このアプローチは、LLM が文脈上の曖昧さの除去に優れているため、効果的です。これは、スペルミスのあるテキストの読み取りを可能にするのと同じ機能です。入力に STT アーティファクトが含まれている可能性があることをモデルに通知することで、追加の処理ステップなしでモデルの自然なエラー修正機能が有効になります。
11. 認知科学の基礎
11.1 カール・ロジャースとパーソンセンタード・セラピー
MARIA Voice のデザインは、Carl Rogers の治療上の変化の条件 (1957 年)、すなわち無条件の肯定的な関心、共感的な理解、一致を大いに参考にしています。憲法は肯定的配慮 (「ユーザーの尊厳を守る」) を実装し、メタ認知層は共感的理解を実装します (「言葉の下に耳を傾ける」)、そしてアイデンティティ層は調和 (「誠実であるが冷酷ではない」) を実装します。
11.2 ヴィゴツキーの近接発達領域
このモード システムは、ヴィゴツキーの近接発達ゾーンの概念、つまり人が一人でできることと指導を受けてできることの間の空間に基づいています。 MARIA Voice は、検出されたモードに基づいて介入レベルを動的に調整します。コンパニオン モードでは最小限のガイダンス (ユーザーが能力がある)、成長モードでは適度な足場 (ユーザーはストレッチ中)、回復モードでは最大のサポート (ユーザーは支援が必要) です。
11.3 フリストンの自由エネルギー原理
メタ認知層が予測誤差に重点を置くのは、カール・フリストンの自由エネルギー原理と一致しています。つまり、脳は継続的に予測を生成し、それを感覚入力と比較することで驚きを最小限に抑えます。 MARIA Voice はこれを対人コミュニケーションに拡張します。ユーザーが何を感じ、何を想定し、何を必要としているかを予測することで、システムはユーザーの認知的不確実性を軽減する応答を生成し、理解されているという主観的な体験を生み出すことができます。
11.4 ダマシオの体細胞マーカー仮説
感情優先処理パイプライン (コンテンツを分析する前に感情を検出する) は、ダマシオの身体マーカー仮説にインスピレーションを得たものです。つまり、感情は合理的な意思決定から切り離されるものではなく、合理的な意思決定に不可欠です。 MARIA Voice は、応答を作成する前にユーザーの感情状態を検出することで、内容が分析的であっても、応答が感情的に調整されることを保証します。
12. 生産に関する洞察と教訓
12.1 コンパニオン モードの検出
運用環境では、コンパニオン モードがすべての会話の約 65% を占めます。初期のシステム設計ではこのモードへの投資が少なく、最小限のプロンプトを必要とする「デフォルト」状態として扱われていました。ユーザーのフィードバックから、コンパニオン モードでは、通常の会話の中で真の理解が得られる小さな瞬間を通じて、最も深い信頼が築かれることが明らかになりました。拡張コンパニオン モード プロンプトには、この学習が反映されています。
12.2 反省と決定の境界
反映モードと決定モードの間の境界は多くの場合あいまいです。 「人間関係をどうすればいいのかわからない」というユーザーは、熟考（理解）や意思決定のサポート（選択肢）を求めている可能性があります。運用データでは、あいまいなケースに対してデフォルトでリフレクションを行うと、より良いユーザー結果が得られることが示されています。意思決定が必要なユーザーは言語を決定モードのキーワードにエスカレートしますが、リフレクションが必要なユーザーがその逆を行うことはほとんどありません。
12.3 言語を超えた感情の検出
日本語と英語は、異なる言語パターンを通じて苦痛を表現します。日本語ではより間接的な表現（しんどい、つらい）が使われますが、英語ではより直接的な表現（疲れ果てた、圧倒される）が使われます。バイリンガル キーワード セットは、両方の言語にわたって一貫した検出精度を維持するために、複数回の反復にわたって調整されました。
12.4 1 つの質問の原則
ユーザー フィードバックで最も一貫して賞賛されている行動は、選択肢を列挙するのではなく、単一の鋭い質問をする MARIA Voice の傾向です。この「1 つの質問の原則」は、応答スタイル層にエンコードされており、情報をダンプするのではなく、真のエンゲージメントのエクスペリエンスを生み出します。
13. 結論
MARIA Voice は、アーキテクチャ上の議論を表しています。つまり、音声 AI の品質は、言語モデルのサイズではなく、認知パイプラインの構造によって決まります。 7 層のプロンプト階層、ゼロレイテンシーの感情検出、モード適応型応答生成、2 層の知識注入、永続メモリ、文レベルのストリーミングが組み合わされて、ほとんどの音声アシスタントでは不可能なことを実行するシステムが作成されます。つまり、話す前に理解するということです。
システムは、速度を犠牲にすることなく、この理解を実現します。クリティカル パス上のすべてのコンポーネント (感情検出、モード分類、知識注入、プロンプト構成) は、LLM コストゼロで実行されます。唯一の LLM 呼び出しは最終応答生成であり、豊富なコンテキスト プロンプトにより、単一の推論呼び出しでマルチエージェント パイプラインの品質が確実に生成されます。
参考文献
- [1] ロジャース、C.R. (1957)。治療的性格の必要十分条件が変化する。 コンサルティング心理学ジャーナル、21(2)、95-103。
- [2] ラザロ、R.S. (1991)。 感情と適応。オックスフォード大学出版局。
- [3] フリストン、K. (2010)。フリーエネルギー原理: 統一脳理論? Nature Reviews Neuroscience、11、127-138。
- [4] ダマシオ、A.R. (1994)。 デカルトの誤り: 感情、理性、そして人間の脳。グロセット/パットナム。
- [5] ヴィゴツキー、L.S. (1978)。 社会における心: 高次の心理的プロセスの発展。ハーバード大学出版局。
- [6] ニスベット、R.E. & ウィルソン、TD (1977)。私たちが知る以上のことを伝える。 心理学的レビュー、84(3)、231-259。
- [7] ミラー、G.A. (1956)。魔法の数字 7 プラスマイナス 2。 心理学的レビュー、63(2)、81-97。
- [8] MARIA OS 技術文書。 （2026年）。 MARIA ボイス オーケストレーター アーキテクチャ。