Skip to Content
Docs12. モダリティ応用リアルタイムマルチモーダル Agent
上級realtimemultimodalstreaming更新: 2026-09-10この記事の誤りを報告

この記事の音声は準備中です。

音声の一覧・再生リストへ

リアルタイムマルチモーダル Agent

この記事の目的

カメラ・画面共有・音声を継続的に観測しながら支援するエージェント(ライブ型)の設計判断ができるようになります。ターン型との違い(いつ応答するか)・入力設計(フレームレートとコスト)・プロアクティブ利用者が頼む前にエージェント側から動く性質(通知・提案・先回り)。便利さとうるささが紙一重で、外し続けると正しい通知まで無視され信頼を損なう。確信度 × 重要度 × 頻度の掛け算で介入を絞り、ユーザー制御(頻度設定・ミュート・「なぜ出たか」の説明)を用意する。介入・長時間ストリームの管理・常時観測のプライバシーを、実務判断として持ち帰れる状態を目指します。音声のみのリアルタイム対話は 音声エージェント(voice agents)、画面の「操作」は コンピュータ操作エージェントの実装 が正本で、本記事は視覚を含む継続観測・支援側に絞ります。

対象読者

  • カメラ・画面共有を継続入力する支援エージェント(ライブアシスタント)を設計する実装担当
  • 常時観測型の体験を検討していて、コスト・応答タイミング・プライバシーの設計判断が要るプロダクト設計者

前提知識

本文

概要: 「常に見て・聞いて、必要なときだけ話す」

リアルタイムマルチモーダルテキスト以外の入力(画像・音声など)を理解できるモデルの能力。コンピュータ操作型 Agent の前提となる。 Agent は、カメラ・画面・音声を継続的に観測し、必要なタイミングで支援するエージェントです。1 往復ずつのターン型と違い、「常に入力が流れ、いつ応答するかを自分で判断する」のが本質です。音声リアルタイムの基礎(音声エージェント)を前提に、本記事は視覚(映像)を足すことで生じる設計判断を扱います。画面の操作は コンピュータ操作エージェントの実装 が正本で、本記事は観測・支援側です。

最終確認日: 2026-09-10。 リアルタイム API の映像入力の仕様(フレームレート上限・セッション上限)は変化が速く、2026-08 時点の値です。代表例と数値は一般類型・スナップショットとして読み、採用時は各社公式で再確認してください(後述の「変わりやすい項目」)。

「映像入力」の実態: 連続動画ではなくフレーム列

まず、設計の土台になる重要な実態です。**「リアルタイム映像入力」は、多くの場合”連続動画”ではなく”低頻度の静止画フレーム列”**です(2026-08 時点)。

  • 連続動画をそのまま流す汎用 API は限られる: リアルタイム API に映像を入れるとき、実際にはフレームを静止画に落として送る方式が一般的です。あるライブ API では最大 1 fps 程度のフレーム列、別の API では「必要な画像を会話に差し込む」離散方式、というように、「なめらかな動画」ではありません
  • カメラも画面共有も「画像フレーム」: API から見ると、カメラ入力も画面共有も「画像フレームを送る」点で同じ扱いです。画面共有専用の入力があるわけではありません
  • 設計への含意: 「毎秒何十フレームの動画を解析する」前提で設計しないことです。実態は「間欠的な静止画スナップショット」であり、後述のフレームレート・コスト設計がそのまま効きます

ターン型との違い: いつ応答するか

継続観測型の最大の設計課題は、応答のタイミングです。ターン型は「ユーザーが送ったら返す」で自明ですが、常時入力では「いつ話すか」を決めねばなりません。

  • 常時入力・随時応答: 入力は途切れなく流れ続けます。その中で「今、発話すべきか」をエージェントが判断します。音声のターン検出(音声エージェントの VAD・ターン検出)に加え、視覚の変化に応じた応答判断が加わります
  • 黙っていることも正解: 常時観測型では、「何もしない(黙って観測を続ける)」が正しいことが多いです。見聞きするたびに話すエージェントは、うるさく使えません
  • 確信度で発話を絞る: 「介入する価値がある・確信がある」ときだけ発話する設計にします(信頼度と較正(calibration)の考え方を発話判断に応用)

入力設計: フレームレート・解像度とコスト

視覚を足すと、コストとセッション上限が跳ねます。ここの設計が実務の要です。

  • フレーム = 画像トークン: 映像フレームは 1 枚ずつ画像トークンとして課金・コンテキスト計上されます(マルチモーダルモデルの仕組みのトークン経済)。フレームレートを上げるほど線形にコストが増え、コンテキストも埋まります
  • セッション上限が縮む: 視覚を足すと、音声のみよりセッションの上限時間が短くなることがあります(映像がトークンを食うため)。長時間の常時観測には、後述のセッション管理が要ります
  • 「必要な瞬間だけ送る」が定石: 常時フル fps で流すのではなく、必要なとき・変化があったときだけフレームを送る / fps を落とす設計が、コストと上限の両面で効きます。「何を・いつ送るか」をエージェント側で制御します
  • 解像度も絞る: 全画面を高解像度で送る前に、関心領域の切り出し・縮小を検討します(画像理解の実務パターンの解像度とコスト)

プロアクティブ介入の設計

継続観測型は、エージェントから話しかける(プロアクティブ)ことができます。これは価値の源であり、同時に事故の源です。

  • 割り込みの節度: 観測して気づいたことを逐一話すと、うるさく邪魔になります。「本当に伝える価値があるか」で介入を絞ります。頻度の設計が体験を左右します
  • 確信度による発話判断: 誤った指摘を割り込みで言うと、信頼を大きく損ないます。確信が低い指摘は、控える・確認の形にします(信頼度と較正(calibration))
  • 割り込みのタイミング: ユーザーが集中している最中の割り込みは迷惑です。音声の割り込み制御(音声エージェント)と同じく、割り込みの是非とタイミングを設計します

セッションとコンテキストの管理

長時間の常時観測は、コンテキストが際限なく積み上がります。管理しないと、上限・コスト・品質が破綻します。

  • 長時間ストリームの圧縮: 古い観測を要約・破棄し、コンテキストを一定に保ちます(メモリと状態管理・コンパクションとコンテキスト分離の考え方をライブストリームに適用)
  • セッションの継続・再接続: セッション上限に達したら、要約を引き継いで継続する設計が要ります。長時間の常駐は 常駐エージェントのライフサイクル管理の劣化・メンテナンスの観点も関わります
  • 何を覚えておくか: 全フレームを保持するのは不可能です。「後で要るのは何か」を決めて保持し、それ以外は流します

プライバシー: 常時観測の同意と録画

常時観測は、プライバシーの重大な論点を伴います。カメラ・画面を継続的に見るのは、テキスト対話とは次元が違います。

  • 常時観測の同意: 「いつ・何を・観測しているか」を明示し、同意を得ます。カメラ・画面共有が有効な間、それが明確に分かる状態にします。黙って観測を続けるのは、信頼を破壊します
  • 録画・保存の扱い: 観測した映像・音声を保存するか、するならどれだけ・誰がアクセスできるかを設計します(会話データの管理基盤の映像版 — 収集・マスキング・保持・削除・アクセス統制)。映像は個人情報を大量に含み、テキストログより機微です
  • 最小限の観測: 支援に不要な映像は送らない・保存しないのが原則です。プライバシーとコストの両面で、「必要な瞬間だけ」が効きます

提供状況の読み方(2026-08 時点)

リアルタイムマルチモーダルの提供状況は、変化が速く・実態が広告と異なることがあります。冷静に読みます。

  • 「映像対応」の中身を確認する: 「リアルタイム映像」を掲げる API でも、実態はフレーム列・低 fps・離散画像差し込みなど様々です。デモの印象でなく、入力方式・フレームレート・セッション上限・コストを仕様で確認します
  • プレビュー段階が多い: リアルタイムマルチモーダルは、プレビュー・制約付きの提供が多い領域です。本番採用は、上限・安定性・コストを実測してから判断します
  • 具体は変わる前提で: 個別 API の対応・数値は変化が速いため、本文は設計原則に徹し、具体は公式と調査メモ research/multimodal/realtime-tts.md で確認します(下記 TODO)

変わりやすい項目(定点観測)

本記事のうち、次は変化が速く、四半期ごと(および改訂時)の再確認が必要です。

  • リアルタイム API の映像入力仕様(フレームレート上限・入力方式・native 連続映像対応の有無)
  • セッション上限(音声のみ / 音声+映像の上限時間)
  • 映像フレーム・音声の課金単位
  • 各社のリアルタイムマルチモーダル提供ステータス(プレビュー / GA)

調査メモ research/multimodal/realtime-tts.md(2026-08-18 時点)に、この定点観測の詳細と出典を記録しています。

保存済み動画の能動的な読解と区別する

動画から必要な時刻の情報を取りに行く能動的な動画読解(agentic video understanding)もあります。Google は 2026-09-01 に、モデルがタイムラインを移動して transcript・frame・audio を必要に応じて要求する方式を案内しました。固定 FPS で全体を読む方式と比較し、追加取得の待ち時間と合計トークンを計測します。公表された最大削減率を自分たちの入力への保証にはしません。

これは保存済み動画の探索であり、常時接続の Live API が同じ方式・モデルに対応することを意味しません。また 2026-08-27 GA の Gemini Omni 1.1 Flash は動画生成・編集の系統です。入力の観測、保存動画の検索、生成の各 API を分けて選定します。

実務での注意点

アンチパターン

  • 「なめらかな連続動画を解析する」前提で設計する → 実態は低 fps のフレーム列でコストも上限も想定と違う → 入力方式・フレームレートを仕様で確認し、フレーム列前提で設計する
  • 常時フル fps で映像を流す → 画像トークンでコストが爆発し、セッション上限も縮む → 必要な瞬間だけ・fps を落として送る
  • 観測するたびに話す → うるさく邪魔で使えない → 黙る選択を許し、確信のある介入に絞る
  • 確信の低い指摘を割り込みで言う → 誤指摘で信頼を損なう → 確信度で発話を絞り、低確信は確認の形にする
  • 常時観測の同意・録画設計を欠く → プライバシーの重大事故になる → 観測を明示して同意を取り、映像の保持・削除・アクセスを設計する
  • 長時間ストリームを圧縮せず流す → コンテキストが破綻し上限・コストが暴走する → 古い観測を要約・破棄し、セッション継続を設計する

チェックリスト

  • 映像入力の実態(連続動画かフレーム列か・fps・セッション上限)を仕様で確認した
  • 「必要な瞬間だけ・fps を落として」フレームを送る入力設計にした
  • 応答タイミングを設計し、「黙って観測を続ける」選択を許している
  • 確信度でプロアクティブ介入を絞り、割り込みのタイミングを設計した
  • 長時間ストリームの圧縮・セッション継続を設計した
  • 常時観測の同意を明示し、映像の保持・削除・アクセス統制を設計した
  • 支援に不要な映像は送らない・保存しない最小限の観測にした

関連トピック

参考資料

TODO・未確認事項

音声合成(TTS)と声の設計セクション概要