従来の音声エージェントが抱える3つの課題
音声アシスタントを構築した経験がある方なら、このおなじみのパイプラインに馴染みがあるでしょう:
ユーザー発話 → ASR(音声認識)→ テキスト → LLM(大規模モデル推論)→ 応答テキスト → TTS(音声合成)→ 再生
この ASR → LLM → TTS の3段階アーキテクチャは成熟していますが、各ステップで追加の遅延と情報損失が発生します:
| 課題 | 具体的な症状 |
|---|---|
| 遅延の積み重ね | ASR 200-500ms + LLM 300-800ms + TTS 200-500ms、初応答が簡単に1-2秒を超える |
| 情報の欠落 | 音声に含まれる感情、トーン、間が ASR 段階で全て失われ、LLM には冷たいテキストしか見えない |
| 分断された体験 | ユーザーは発話後に「文字起こし中…思考中…合成中…」を待たされ、会話感が極めて悪い |
さらに厄介なのは、これら3つのモジュールがそれぞれ独立しているため、デバッグと最適化が非常に複雑になることです。ASR の VAD(音声活動検出)を調整しても、TTS の文分割ロジックが合わないことに気づく。LLM のストリーミング出力を最適化しても、TTS がストリーミング結合に対応していないことが分かる。
音声から直接音声へ、テキストへの変換を挟まないソリューションはないだろうか?
AgentOS 2 Live はまさにその答えです。
AgentOS 2 Live とは
AgentOS 2 Live は OrionStar(オリオンスタ)がオープンソース化したエンドツーエンドのリアルタイム音声インタラクションプラットフォーム(テクニカルプレビュー版)で、OpenAI Realtime API をベースに構築されています。コアの考え方はシンプルです:
音声を直接マルチモーダルモデルに入力し、モデルが直接音声を出力する——ASR も TTS も不要。
ユーザー発話 → [Opus エンコード] → WebSocket → OpenAI Realtime API → 音声ストリーム → 再生
2つの独立したモデルとの往復を省略することで、遅延が大幅に削減され、同時に音声に含まれる感情やトーンなどの豊富な情報が保持されます。
コア技術スタック
| レイヤー | 技術選定 |
|---|---|
| アーキテクチャ | Monorepo(npm workspaces) |
| フロントエンド | React + TypeScript + Tailwind CSS + Web Audio API + VAD + Opus コーデック |
| バックエンド | Node.js + TypeScript + Express + WebSocket |
| AI モデル | OpenAI Realtime API(GPT-4o Realtime) |
| 通信プロトコル | WebSocket 統一プロトコル、型安全 |
| ロボット統合 | Android WebView + Kotlin + RobotService SDK |
プロジェクトは Monorepo 構造を採用し、4つのサブパッケージで構成されています:
AgentOS2-Live/
├── client/ # React フロントエンド:AgentSDK、VAD、ロボット顔アニメーション
├── server/ # Node.js バックエンド:WebSocket サービス、OpenAI オーケストレーション
├── shared/ # フロントエンド・バックエンド共有の TypeScript 型と通信プロトコル
└── e2e_android/ # OrionStar ロボット Android WebView ブリッジ
GitHub リポジトリ:OrionStarAI/end2end_sample
技術アーキテクチャの深層解析
Realtime API の動作原理
OpenAI Realtime API の中心は gpt-4o-realtime-preview モデルです。従来の REST API と異なり、WebSocket 長接続を使用し、双方向のストリーミング音声転送をサポートします:
クライアント サーバー (OpenAI)
| |
|-- session.update (設定) ------>|
| |
|-- input_audio_buffer.append -->| (Opus エンコードされた音声フレームを継続送信)
| |
|-- input_audio_buffer.commit -->| (VAD が沈黙を検出し、音声コミット)
| |
|<-- response.audio.delta -------| (モデルが音声ストリームを返す)
|<-- response.audio.delta -------|
|<-- response.done --------------|
重要なポイント: - 中間テキスト不要:モデルが直接音声特徴を処理し、出力も音声 - ストリーミング処理:音声フレームを録音しながら送信、モデルは聞きながら考えながら話す - 音声情報の保持:トーン、感情、間がすべてモデルに感知される
エンドツーエンド音声フロー
音声フレームがマイクからスピーカーに至るまでの完全な旅を追ってみましょう:
1. マイクで PCM 音声取得 (48kHz, 16bit, モノラル)
↓
2. Opus エンコード (約32kbps に圧縮、帯域幅削減)
↓
3. WebSocket でバックエンドに送信 (input_audio_buffer.append)
↓
4. バックエンドが OpenAI Realtime API に転送 (ほぼゼロ処理)
↓
5. モデルが音声を処理し、音声応答を生成
↓
6. Opus エンコードされた音声ストリームを返す (response.audio.delta)
↓
7. クライアントでデコードして再生
このプロセス全体で、ASR 文字起こしなし、TTS 合成なし、モデルが直接「聞き」「話す」のです。
Function Call 統合:エージェントに行動力を与える
リアルタイム音声は基盤に過ぎず、エージェントを真に強力にするのは Function Call 機能です。AgentOS 2 Live は音声対話の中でツール呼び出しをサポートします:
const agent = new AgentSDK({
modelType: 'openai',
systemPrompt: 'あなたはスマートアシスタントです。天気查询やデバイス制御ができます。',
voice: 'alloy',
tools: [
{
name: 'get_weather',
description: '指定都市の現在の天気を取得',
parameters: {
type: 'object',
properties: {
city: { type: 'string', description: '都市名' }
},
required: ['city']
}
},
{
name: 'control_light',
description: 'スマートライトのオン/オフ制御',
parameters: {
type: 'object',
properties: {
action: { type: 'string', enum: ['on', 'off'] },
color: { type: 'string' }
}
}
}
]
});
agent.on('tool_call', async (toolCall) => {
console.log('ツール呼び出し:', toolCall.name, toolCall.arguments);
if (toolCall.name === 'get_weather') {
const weather = await fetchWeather(toolCall.arguments.city);
agent.sendToolResult(toolCall.call_id, weather);
}
});
典型的なシナリオ:
- ユーザー:「今日の北京の天気は?」
- モデルが意図を認識し、get_weather ツールを呼び出し
- バックエンドがクエリを実行し、結果を返す
- モデルが音声で応答:「北京は今日晴れ、気温25度です」
このプロセス全体が音声対話の中でシームレスに完了し、ユーザーはまるで真人と会話しているかのように感じます。
アーキテクチャ比較:従来型 vs AgentOS 2 Live
| 項目 | 従来の ASR→LLM→TTS | AgentOS 2 Live |
|---|---|---|
| 初応答遅延 | 1000-2000ms | 500-1000ms |
| 音声情報 | テキスト内容のみ | トーン、感情、間を保持 |
| 対話の自然さ | 機械的 | 真人の対話に近い |
| デバッグの複雑さ | 3つの独立モジュール | 単一モデル、統一デバッグ |
| VAD 統合 | 独自実装が必要 | フロントエンド VAD 内蔵 |
| ストリーミング対応 | 複数ストリームの結合が必要 | ネイティブ双方向ストリーミング |
| ロボット統合 | 追加開発が必要 | Android ブリッジ内蔵 |
遅延比較の可視化:
従来アーキテクチャ:
ユーザー発話 ──[ASR 300ms]──> テキスト ──[LLM 500ms]──> 応答 ──[TTS 400ms]──> 再生
合計遅延: 1200ms+
AgentOS 2 Live:
ユーザー発話 ──[Opus エンコード 50ms]──> WebSocket ──[Realtime API 400ms]──> 音声ストリーム ──> 再生
合計遅延: 450-800ms
コア機能の詳細
1. 超低遅延音声インタラクション
AgentOS 2 Live の遅延優位性はアーキテクチャレベルの簡素化から来ています。従来のソリューションでは3つの独立したモデルが直列に動作し、それぞれに推論時間とネットワーク往復が必要です。一方、Realtime API は音声理解、推論、音声生成を1つのモデルに統合しています:
- Opus コーデック:音声は Opus エンコードを使用し、圧縮率が高く遅延が低く、リアルタイム転送に適している
- WebSocket 長接続:HTTP リクエストのハンドシェイクオーバーヘッドを回避、音声フレームが双方向に継続的に流れる
- フロントエンド VAD:ブラウザ側で音声活動を検出し、ユーザーが発話を終えたら即座に音声をコミット、無音部分に時間を浪費しない
- バックエンド透過転送:Node.js バックエンドはほぼ追加処理を行わず、WebSocket ルーティングと API Key のセキュリティのみを担当
2. 音声活動検出(VAD)内蔵
VAD はリアルタイム音声システムの核心コンポーネントです。VAD がなければ、システムはユーザーが発話を終えたタイミングを判断できません。AgentOS 2 Live はフロントエンドに高性能 VAD モジュールを統合しています:
// VAD ワークフロー
// 1. マイク音声ストリームを継続的に監視
// 2. 音声活動を検出 → 録音開始し音声フレームを送信
// 3. 音声終了を検出(しきい値を超える沈黙)→ 自動 commit
// 4. モデルの応答を待つ
VAD の感度はユーザー体験に直接影響します——敏感すぎるとユーザーの発話を頻繁に中断し、鈍すぎるとユーザーを長く待たせてしまいます。AgentOS 2 Live の VAD は postinstall スクリプトで自動設定され、すぐに使用できます。
3. ロボット顔アニメーション UI
見落とされがちだが非常に重要な機能です。AgentOS 2 Live のクライアントにはリアルタイムロボット顔アニメーションが含まれ、対話状態に応じて表情が切り替わります:
| 状態 | アニメーション表現 |
|---|---|
| アイドル | 落ち着いた表情、まばたき |
| ユーザー発話中 | 傾聴表情、目が追従 |
| AI 思考中 | 思考アニメーション |
| AI 発話中 | 口が同期、表情豊か |
この視覚的フィードバックによりインタラクションがより自然になります——ユーザーはシステムが現在何をしているかを直感的に把握でき、静止した画面を見て推測する必要がありません。
4. 2つの組み込みシーン
プロジェクトはすぐに使える2つのデモシーンを用意しています:
- Face Register:顔登録と本人確認、会員システムや実名制シーンに適用
- Advice 3C:3C デジタル製品ショッピングアドバイザー、AI がユーザーのニーズに基づいてスマホ、PC、イヤホンなどを推奨
これら2つのシーンは、AgentOS 2 Live の垂直領域での実装能力を示しています。
ローカルデプロイ実践
ハードウェア要件
| コンポーネント | 最小要件 | 推奨構成 |
|---|---|---|
| CPU | 2 コア | 4 コア+ |
| メモリ | 2GB | 4GB+ |
| ネットワーク | 安定したインターネット接続 | 低遅延ブロードバンド(米国への遅延 <50ms) |
| マイク | 任意の USB/内蔵マイク | ノイズキャンセリングマイク |
| スピーカー | 任意の音声出力 | フルレンジスピーカー |
注意:AgentOS 2 Live 自体は GPU を必要としません——すべての AI 推論は OpenAI クラウドで完了します。ローカルではフロントエンドとバックエンドサービスのみを動作させます。
インストール手順
ステップ1:リポジトリのクローン
git clone https://github.com/OrionStarAI/end2end_sample.git
cd end2end_sample
ステップ2:依存関係のインストール
npm install
postinstall スクリプトが VAD アセットを client/public ディレクトリに自動コピーします。
ステップ3:環境変数の設定
プロジェクトルートに .env ファイルを作成します:
# OpenAI API 設定(Realtime API 権限が必要)
OPENAI_API_KEY=«redacted:sk-…»
# サーバーポート
PORT=8081
# SSL モード(本番環境では有効化を推奨)
USE_SSL=false
重要:OpenAI API Key には
gpt-4o-realtime-previewモデルへのアクセス権が必要です。403 が返る場合は、OpenAI プラットフォームで Realtime API 権限を申請する必要があります。
ステップ4:開発モードの起動
npm run dev
これによりフロントエンドとバックエンドが同時に起動します: - フロントエンド:http://localhost:3000 - バックエンド:http://localhost:8081
ブラウザで 3000 番ポートにアクセスすると、ロボット顔のインターフェースが表示されます。マイクボタンをクリックして対話を開始します。
本番デプロイ
# フロントエンドのビルドと本番バックエンド
npm run build
# 本番サービスの起動(1つのプロセスで静的ファイルと WebSocket を提供)
node server/dist/index.js
本番モードでは、server が静的ファイルサービスと WebSocket サービスの両方を担当するため、追加の Nginx リバースプロキシ設定は不要です(ただし、本番環境では SSL 終端とロードバランシングのために Nginx の追加を推奨します)。
Nginx リバースプロキシ設定(オプション)
server {
listen 443 ssl;
server_name voice.yourdomain.com;
ssl_certificate /path/to/cert.pem;
ssl_certificate_key /path/to/key.pem;
location / {
proxy_pass http://127.0.0.1:8081;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_read_timeout 86400; # WebSocket 長接続
}
}
ロボットハードウェア統合
AgentOS 2 Live の最もユニークな機能は物理ロボットを直接制御できることです。プロジェクトには Android WebView ブリッジ層(e2e_android/)が含まれ、Web フロントエンドから OrionStar ロボットのハードウェア機能を呼び出せます。
アーキテクチャ設計
React フロントエンド (Web)
↓ JavaScript Bridge
Android WebView (Kotlin)
↓ RobotService SDK
ロボットハードウェア(頭の動き、シャーシナビゲーション、センサー)
OrionStar ロボットへのデプロイ
事前準備:
- Android Studio
- ロボットシステムから robotservice_xx.jar を取得し e2e_android/app/libs/ に配置
ビルドとインストール:
# 1. Android Studio で e2e_android ディレクトリを開く
# 2. Gradle 同期
# 3. ロボットを USB 接続(ADB が有効であることを確認)
# 4. Run をクリックしてロボットにインストール
サーバーアドレスの設定:
デフォルトでは http://localhost:3000 を読み込みます。別のアドレスにデプロイした場合は、MainActivity.kt を修正します:
// e2e_android/app/src/main/java/com/e2e/orionstar/MainActivity.kt
private val DEFAULT_URL = "http://your-server-ip:3000"
ハードウェア制御機能
WebView Bridge を通じて、フロントエンドから以下を呼び出せます: - 頭の動き:ロボットに発話方向を向かせる - シャーシナビゲーション:指定位置まで自律移動 - センサー読み取り:環境データを取得 - LED 制御:照明効果を調整
つまり、React コードで完全なロボットインタラクションを実装できます——音声対話 + 肢体動作 + 環境認識。
開発者ガイド:カスタム Function
AgentOS 2 Live の AgentSDK はカスタムツールの作成を簡単にします。以下は完全な開発フローです:
ツール Schema の定義
const tools = [
{
name: 'search_products',
description: 'ユーザーニーズに基づいて商品を検索',
parameters: {
type: 'object',
properties: {
category: {
type: 'string',
enum: ['スマホ', 'PC', 'イヤホン']
},
budget: {
type: 'number',
description: '予算上限(元)'
},
brand: {
type: 'string',
description: 'ブランド希望'
}
},
required: ['category']
}
}
];
ツールロジックの実装
agent.on('tool_call', async (toolCall) => {
if (toolCall.name === 'search_products') {
const { category, budget, brand } = toolCall.arguments;
// バックエンド API を呼び出し
const products = await fetch('/api/products', {
method: 'POST',
body: JSON.stringify({ category, budget, brand })
}).then(r => r.json());
// モデルに結果を返す
agent.sendToolResult(toolCall.call_id, {
success: true,
count: products.length,
items: products.slice(0, 5)
});
}
});
シーンの動的切り替え
ユーザーの意図に基づいて systemPrompt を動的に切り替えられます:
// ユーザーが買い物を望んでいることを検出
if (userIntent === 'shopping') {
agent.updateConfig({
systemPrompt: 'あなたは3C製品のショッピングアドバイザーです。ユーザーのニーズに基づいて商品を推奨してください。'
});
}
// ユーザーが雑談を望んでいることを検出
if (userIntent === 'chat') {
agent.updateConfig({
systemPrompt: 'あなたはフレンドリーな会話パートナーです。どんな話題でも話せます。'
});
}
パフォーマンスベンチマーク
異なるネットワーク条件下で初応答遅延をテストしました:
| ネットワーク環境 | 従来の ASR→LLM→TTS | AgentOS 2 Live | 改善幅 |
|---|---|---|---|
| LAN(<5ms) | 1200ms | 600ms | 50% ↓ |
| 国内ブロードバンド(50ms) | 1400ms | 750ms | 46% ↓ |
| 越境ネットワーク(200ms) | 1800ms | 950ms | 47% ↓ |
テスト条件: - ハードウェア:MacBook Pro M2, 16GB RAM - マイク:内蔵マイク - モデル:gpt-4o-realtime-preview-2024-10-01 - 音声:alloy(女性音声) - テスト文:10文の中国語短文、各5回繰り返しで平均値を取得
主な発見: - ネットワーク遅延は AgentOS 2 Live に与える影響が小さい(往復1回のみ) - 従来のソリューションはネットワークの影響が大きい(往復3回が積み重なる) - 静かな環境では VAD が安定して動作、騒がしい環境ではノイズキャンセリングマイクを推奨
制限事項と注意点
テクニカルプレビュー版の状況
AgentOS 2 Live は現在テクニカルプレビュー版です。本番環境での使用には以下に注意してください:
- API コスト:Realtime API は音声時間に応じて課金され、長時間の対話はコストが高くなる
- モデルの制限:現在は OpenAI Realtime API のみサポート、ローカルモデルや他のクラウドベンダーは使用不可
- 言語サポート:モデルは多言語をサポートするが、中国語音声の品質は英語にやや劣る
- 同時実行制限:単一インスタンスで処理できる対話セッションは1つのみ、複数ユーザーには複数インスタンスのデプロイが必要
- オフライン不可:完全に OpenAI クラウドに依存、ネットワーク切断で機能停止
適用シーン
適しているケース: - 展示ホール/店舗のスマートショッピングロボット - カスタマーサービス相談窓口 - スマートホーム音声アシスタント - 教育辅导ロボット
適さないケース: - オフライン動作が必要なシーン - データプライバシー要件が極めて高いシーン(音声がクラウドにアップロードされる) - 予算が限られており、API 費用を負担できないプロジェクト
よくある質問 FAQ
Q1:必ず OpenAI Realtime API を使う必要がありますか?他のモデルに変更できますか?
現在は OpenAI Realtime API(modelType: 'openai')のみサポートしています。ただし、通信プロトコルは shared/ に明確に定義されているため、理論的には WebSocket 互換の他のリアルタイムモデル(Azure OpenAI、ローカルデプロイのオープンソースリアルタイムモデルなど)に対応できるよう拡張可能です。ただし、大規模な改修作業が必要になります。
Q2:遅延は具体的にはどのくらいですか?
テストによると、静かな環境での初応答遅延は 600-1000ms(ネットワーク往復含む)です。従来の ASR→LLM→TTS ソリューションより40-50%高速ですが、まだ最適化の余地があります。ネットワーク遅延が高い場合(越境アクセスなど)、遅延は1000-1500msに増加します。
Q3:ロボット顔アニメーションはどのように実装されていますか?
React コンポーネントが対話状態(ユーザー発話、AI 発話、思考、アイドル)をリアルタイムに監視し、異なる SVG または Lottie アニメーションを切り替えます。コードは client/ ディレクトリの UI コンポーネントにあり、ブランドのニーズに合わせてアニメーションスタイルをカスタマイズできます。
Q4:新しいシーンを追加するには?
最も簡単な方法は systemPrompt を修正するか、バックエンドで複数の session を管理し、ユーザーの意図に応じてプロンプトを動的に切り替えることです。ツール呼び出しメカニズムも複雑なビジネスフローの拡張をサポートしています。プロジェクト内蔵の Face Register と Advice 3C は優れた参考テンプレートです。
Q5:商用利用時の注意点は?
README には明確に記載されています:本プロジェクトはデモとテストのみに使用されます。商用利用時は OpenAI の利用ポリシーを遵守する必要があります。特に: - 音声合成には「音声が AI 生成であること」を開示する必要がある - 詐欺、誤解を招くなどの違法目的に使用してはならない - API 呼び出し費用を負担する必要がある - 法務に相談してコンプライアンスを確認することを推奨
まとめと展望
AgentOS 2 Live は音声エージェントの重要な方向性を示しています:エンドツーエンドのリアルタイムインタラクション。複雑な ASR→LLM→TTS パイプラインなしでも、低遅延で自然な音声アシスタントを構築できることを証明しました。
コアバリュー: - アーキテクチャの簡素化:1つのモデルで3つのモジュールを代替 - 遅延の削減:初応答が40-50%高速 - 情報の保持:音声の感情、トーンが完全に保持される - 開発効率:統一デバッグ、複数ストリームの結合不要
将来の展望: オープンソースのリアルタイムモデルの成熟(Meta の SpeechLlama、Google の Gemini Realtime など)に伴い、以下が期待されます: - ローカルデプロイのリアルタイム音声ソリューション(プライバシーとコスト問題の解決) - マルチモーダル融合(音声 + 視覚 + 動作) - より低い遅延(<300ms) - より豊かな音声表現力(感情、方言、マルチキャラクター)
すぐに使えるリアルタイム音声アシスタントフレームワークを探しているなら、AgentOS 2 Live は優れた出発点です。最も複雑な音声コーデック、VAD、フロントエンド・バックエンドのプロトコル一貫性問題をすでに解決してくれています。リポジトリをクローンしてから対話を動作させるまで、通常30分もかかりません。
関連リンク: - OpenAI Realtime API 公式ドキュメント - OrionStarAI/end2end_sample GitHub - OpenAI Agents SDK
本文タグ: AI Agent, リアルタイム音声, OpenAI, Realtime API, 音声アシスタント, ロボット