VisionHubAI DAILY BRIEF
2026.09.15 TUE / No.411 / 音声AI・業務実行
GEMINI 3.8 LIVE — BEYOND CONVERSATION

AIは、話しながら
仕事を進める。

Gemini 3.8 Liveが変えるのは、声の自然さだけではありません。
会話・推論・外部ツールを並行して動かす音声AIを、能力、費用、実行権限の3つに分けて読み解きます。[1][4]

9月15日の発表を中心に編集調査・仕様確認:2026年9月17日 JST本文の「ET」は Extended Thinking の略

最初に1枚で全体像を見る

2026年9月15日のAIニュース・ダッシュボード。中心テーマは話しながら仕事を進める音声AI。標準Liveは会話と費用、Extended Thinkingは複雑な処理を重視。ET HighのSpeech-to-Speech Indexは82.6。標準Liveの0.84ドル毎時はAAベンチマーク換算でAPIの音声入力単価ではない。発話終了と仕事完了は別であり、重要操作には承認が必要。周辺ニュースはClaudeの業務接続、Jevの型付き判断、NVIDIAの固定電力枠内での処理量24%向上という検証結果。
本ページ用に生成した要約画像。カバーは images/0915/cover.jpg を相対参照。画像の数値・表現は本文で補足します。AA指標は9月17日の取得値で、API単価・実際の通話料金とは区別します。[7][8]
01 / 体験の変化

待たせずに話し、
裏で処理を進める。

特にETは、声を返しながら背景推論を継続する設計です。[4]

02 / 選び方

対話なら標準、
複雑な処理ならET。

総合順位・会話の好み・業務完遂率は同じ軸ではありません。[7]

03 / 守るべき境界

できることと、
実行してよいことは別。

予約変更や外部送信の承認は、モデル任せにしない設計が必要です。〈編集部提案〉

先に直しておきたい点
Gemini APIは「公開プレビュー」ではなく、9月15日からGA。また、$0.84/時は入力単価ではありません。企業向けのprivate preview、AAの比較用費用、APIの実請求を混ぜずに読みます。[2][1][7]
01
WHAT CHANGED

新しくなったのは、声よりも「仕事の進め方」。

会話のテンポを保ちながら、検索や計算に必要な処理を進める。
そのために、低遅延の標準版と、背景推論を強めたET版を使い分けます。[1][2]

会話・規模・費用を重視

Gemini 3.8 Live

gemini-3.8-live
1.18
AAの初音までの時間
タスク完了時間ではない

会話への割り込み、視覚入力、非同期ツールを扱う標準モデル。推論そのものがないのではなく、thinking_levelを利用者が指定できないモデルです。[3][7]

選ぶ場面の例:問い合わせの一次受付、音声検索、短い案内。用途例は本稿の整理であり、品質は業務別に検証します。
複雑な処理・多段推論を重視

Live Extended Thinking

gemini-3.8-live-extended-thinking
82.6
AA Speech-to-Speech Index
ET Highの総合スコア

発話しながら背景で考え、ツール結果を待ち、追加の処理へ進むモデル。推論量をlow / medium / highから選びます。MINIMALは使えません。[4][7]

選ぶ場面の例:複数条件をまたぐ手続き、技術支援、学習支援。Highが常に最適とは限らず、費用と最終回答時間で比較します。
ネイティブ音声Gemini 3 Proベース。ASR→LLM→TTSの3段構成とは異なる。[6]
97言語会話途中の言語切替に対応。生成音声にはSynthID。[1]
128K / 64K入力131,072、出力65,536トークン。対応上限であり推奨使用量ではない。[3][4]
もう少し詳しく:ネイティブ音声だと何が違う?

従来型の一例は「音声を文字にする→文章として考える→音声に戻す」という分業です。今回のモデルは音声そのものを入出力として扱います。[6] ただし、ネイティブ音声であることと、外部システムの処理が並行して走ることは別の設計要素です。

たとえば音声モデルが即座に「確認します」と言っても、予約システムが遅ければ確定結果は遅れます。モデル内部の改善だけで、ネットワーク遅延、DBのロック、ツールの権限不足まで解消するわけではありません。ここはシステム全体で測定する必要があります。〈技術的な読み解き〉

「公開された」と「自分の画面で使える」は分ける。

API / AI Studio

両モデルを提供。Gemini APIのリリースノートは9月15日からGA(一般提供)と明記しています。[2]

Googleの製品

標準版はSearch Live。ETはGemini Liveに加え、DocsはPro / Ultra、Gmail・KeepはGoogle AIプラン向けに展開と発表。地域・プラン・展開時期の条件は、各製品側で別途確認が必要です。[1]

企業向け

Enterpriseはprivate preview。企業向けWorkspaceなどの予定を、個人向けサービスへの展開と同一視しません。[1]

SO WHAT

同じ「3.8」でもFlashとは別の軸。Liveの主題は、音声対話と業務処理をどうつなぐかです。[2]

02
THE IMPORTANT API CHANGE

「話し終わった」からといって、仕事は終わっていない。

ETで最も重要なのは、turnComplete: trueを受け取っても、後から音声やツール呼び出しが届き得ることです。受信を止めると、肝心の後続処理を取りこぼします。[4][5]

A / 発話の状態

今のひと言が終わった

turnCompleteは発話の区切り。ETでは、これだけで待機中とは判断できません。[4]

B / AI側の状態

推論やツール待ちが続く

IN_PROGRESSなら処理継続。IDLEでモデル側の一連の処理が終わります。[4]

C / 業務の状態

予約の確定は別管理

承認待ち、更新中、確定、失敗は業務システム側で持つ状態です。IDLEだけで「予約完了」と表示しません。〈設計提案〉

INTERACTIVE EXPLANATION / 通信しない模式デモ

予約変更を、7つの段階で見る

STEP 1 / 7 — 利用者の依頼
「明日の予約を、午後に変更できる?」

これは変更できるかの相談です。この時点では予約を書き換えません。

発話の区切り
AI側の処理IN_PROGRESS
業務側の状態NOT_CHANGED
変更前 → 変更案9/16 10:00 → 15:00
変更対象を特定 → 変更案を提示 → 明確な承認 → 確定応答を確認。曖昧な相談から書き込み処理へ飛ばしません。
架空の予約です。API接続・録音・実際の予約操作は行いません。
開発者向け:receiveループで間違えやすいところ

SDKごとのイベント構造は異なるため、次は実装方針を示す擬似コードです。モデルのメッセージ内に複数の要素が含まれる前提で処理します。

while session_is_open:
    event = await receive_next_event()

    process_audio_frames(event)
    process_transcripts(event)
    dispatch_tool_calls_without_blocking_receiver(event)
    handle_interruption_and_tool_cancellation(event)

    if event.turnComplete:
        mark_current_utterance_finished()
        # ETではここで break / close しない

    if event.interaction_status == "IN_PROGRESS":
        show_model_processing()
    elif event.interaction_status == "IDLE":
        show_model_idle()
        # 外部システムの COMMITTED とは別

    update_business_ui_from_server_owned_transaction_state()

JSONとSDKではcamelCase / snake_caseの表記が異なることがあります。受信側のturnCompleteと、送信側のturn_complete=trueも区別します。後者はETの進行中の生成を中断し得る設定です。[4][5]

ツール呼び出しを受けた処理が、同じ受信ループを長時間ふさぐのも避けます。外部処理は別タスクへ渡し、結果を呼び出しIDに対応づけて戻す、という責務分離が必要です。〈設計提案〉

SO WHAT

音声の状態・AIの処理状態・業務の確定状態。この3つを分けるのが、ET移行の出発点です。

03
READ THE LEADERBOARD, NOT ONLY THE HEADLINE

総合1位でも、「あらゆる面で一番」ではない。

首位はET Highの82.6。標準Liveは76.0で5位です。
一方、会話の好み・速度・特定の成功率を見ると、別のモデルが上に来ます。[7]

主要モデル比較 / AAの2026-09-17取得値。名称・推論設定をそろえて読む。
モデル / 設定総合Index
高いほど良い
τ-Voice
業務シナリオ
Arena
好み Elo
タスク
成功率
初音
AA換算費用
$/入力音声時*
Gemini 3.8 Live ETHigh / 総合1位82.668.6%99089.1%1.35$3.50
GPT-Live-1 Astramedium81.567.9%104887.4%1.34$5.83
Grok Voice Think Fast 2.0High81.356.5%101194.6%0.70$4.80
GPT-Live-1 Sollow80.159.3%105390.9%1.24$4.47
Gemini 3.8 Live標準 / 総合5位76.030.1%108393.2%1.18$0.84
GPT-Realtime-2.1High73.945.7%92891.5%1.21$10.75
Gemini 3.1 Flash LiveHigh / 旧世代71.537.7%106371.8%2.99$1.75
Gemini 3.1 Flash LiveMinimal / 旧世代63.926.2%109674.6%0.96$1.50

出典:[7]。*AA換算費用は固定問題セットの総コストを入力音声時間で割った比較指標であり、音声入力だけの単価や実通話1時間の料金ではありません。横スクロール対応。順位・Eloは将来変動します。

業務の完遂

標準30.1% → ET68.6%

τ-Voiceでは明確に役割が分かれます。ただし、Astraの67.9%との差は0.7ポイント。これだけで統計的な優位とは断定できません。[7]

人間の好み

旧Minimalが1096

Arenaは声質だけでなく、対話全体への好みです。旧3.1のHighとは別設定。標準Liveの1083は高い一方、ETは990です。[7]

応答の速さ

最初の声と、完了は別

Grokの0.70秒は表内で最速。全掲載モデルの最速ではなく、Deepslate Opalには0.44秒の結果もあります。[7]

深掘り①:30.1%と93.2%は、なぜ両立するのか?

試験が違うからです。τ-Voiceは航空・小売・通信の模擬カスタマーサポートで、処理後のデータベース状態が正解と一致したかを見ます。Arenaのタスク成功率は、対象会話で正しい最終ツール呼び出しが行われたかを見る指標です。[7]

例えるなら「複数の規則を守って予約を変更し切れたか」と「対象の会話で最後に正しい操作を選べたか」は、似ていても同じ試験ではありません。どちらも本番の問い合わせ全体にそのまま掛けられる成功率ではない、という点が実務では重要です。〈解釈〉

深掘り②:Indexの作り方と、比較の限界

Indexは①Big Bench Audio、②τ-Voice、③変換後のArena評価、④タスク成功率の等重み平均です。会話の割り込みなどを測るFull Duplex Benchの指標は、別軸で掲載されています。[7]

Arena Score = 100 / (1 + 10^((800 − frozen Elo) / 400))

Index用のEloは公開対象となった時点で固定されるため、表に見える現在のEloを式に入れても、公表Indexを厳密には再現できません。またτ-Voiceは通常3試行の平均ですが、Astra / Solは1試行、Realtime-2.1 Highは2試行という注記があります。[7]

したがって「同じ評価機関が測った」ことと「試験条件・誤差まで完全に同じ」ことは別です。GoogleがAAの数値を紹介していることも、GoogleとAAが独立に同じ実験を2回再現した証拠ではありません。〈解釈〉

深掘り③:音声推論の97.7%は何を測る?

GoogleはETのBig Bench Audioを97.7%、Sierraのτ-Voice-bankingを35.1%と紹介しています。[1] Big Bench Audioは、音声で与えた論理・数え上げなどの問題への回答を評価する試験です。[7]

これは「日本語が97.7%正しく聞き取れる」「銀行業務全般の成功率が35.1%」という意味ではありません。ベンチマークのタスク定義、入力、正解基準を外して数字だけを転用しないことが大切です。〈解釈〉

深掘り④:Arenaの1位と2位は、どこまで違うと言える?

9月17日のArenaでは、旧3.1 Flash Live Minimalが1096 ±27(841サンプル)、標準3.8 Liveが1083 ±30(482サンプル)です。±の範囲は掲載された95%信頼区間で、順位範囲も前者は1〜2位、後者は1〜4位と示されています。[25]

点推定の差は13 Eloですが、掲載区間は重なっています。したがって本稿では「旧モデルの点推定が上」と読み、旧モデルの声が明確に優れている、あるいは新モデルが劣化したとは断定しません。区間の重なりだけで同等性を証明できるわけでもありません。会話全体の好みを測る評価であり、声質だけの試験でもない点に注意します。〈統計的な読み解き〉

実務では、同じ日本語シナリオで声を伏せて比較し、好みと業務完遂率を別々に記録します。最初の声が好まれても、実行結果まで正しいとは限りません。〈評価提案〉

SO WHAT

総合順位で候補を絞り、最後は自社の日本語・業務フロー・待ち時間で選ぶ。1つのスコアに全部を代表させない。

04
COST ≠ TOKEN PRICE ≠ COST PER CALL

「$0.84で1時間しゃべれる」と読むと、見積もりを誤る。

APIの単価と、AAが試験に払った費用の換算値は別です。
標準LiveとETは公式のトークン単価が同じでも、使う量が違えば実費は変わります。[7][8]

Google公式 / 有料ティア

音声の単価

$0.005 / 入力1分
$0.018 / 出力1分

音声入力 $3 / 100万トークン、音声出力 $12 / 100万トークンの分換算。両モデル共通の掲載単価です。[8]

Artificial Analysis / 比較用指標

固定問題セットの換算費用

$0.84 / 入力音声時:標準Live
$3.50 / 入力音声時:ET High

音声・テキストの入出力、分離して計上される推論トークンを含む試験の総コストを、入力音声の長さで割った値。外部ツール費などは含みません。[7]

両モデル共通の公式掲載単価 / USD・有料ティア・100万トークンあたり [8]
入力・出力料金実務での注意
音声入力$3.00 / 約$0.005/分会話の長さと、課金対象の音声量を同一視しない。
音声出力$12.00 / 約$0.018/分途中経過の発話が増えれば、出力費も増える。
テキスト入力$0.75指示・文脈・ツール結果も見積もり対象。
テキスト出力・推論$4.50声に出ない処理を含め、実際の利用量で検算する。
画像・動画入力$1.00 / 約$0.002/分不要なカメラ入力を送り続けない。

検索の別課金、ネットワーク、電話回線、周辺サーバー、業務API、税などは別です。無料ティアの利用条件を、本番運用の契約条件と同一視しません。[8]

音声部分だけ、条件を変えて概算する

これは下限保証ではなく、入力した課金対象の音声分数に基づく部分見積もりです。ETの推論費などは含みません。初期値は仮定です。

音声入出力のみ / 1件
$0.102
音声入出力のみ / 月間
$1,020.00

6分 × $0.005 + 4分 × $0.018 = $0.102 / 件

実通話10分だから入力6分・出力4分になる、という意味ではありません。連続送信や会話の重なりも考慮し、実際の利用量で置き換えてください。為替換算は行っていません。

深掘り:AAの価格差はどこまで使えるか?

AAは同じ40問のBig Bench Audio部分集合で費用を比較しています。これは「同じ課題を解く効率」の参考になりますが、受付業務の発話量やツール呼び出し回数を代表するものではありません。[7]

標準 Live
$0.84
ET High
$3.50
Grok Voice High
$4.80
GPT-Live-1 Astra
$5.83
GPT-Realtime-2.1 High
$10.75

同じ掲載単価のETが、この試験では標準の約4.17倍の費用です。違いは単価だけでなく、処理の長さや出力・推論の使用量にも表れます。逆に、旧モデルの$1.75と比べて安いからといって、公式の音声トークン単価そのものが半減したとは言えません。[7][8]

本番の選定指標は「1分あたり」だけでなく、「正しく1件を終えるまでの総費用」にします。安いモデルでも、失敗後の再試行や人への転送が増えれば全体費用は上がります。〈実務への提案〉

SO WHAT

比較にはAA、見積もりには公式単価、本番予算には実測の利用量。この3段階で考えると、価格の誤読を防げます。

05
PERMISSION IS A SYSTEM RESPONSIBILITY

速く動くAIほど、「実行してよいか」を外側で決める。

予約の検索は進めても、予約の確定は勝手に進めない。
会話を止めないことと、承認を省くことは違います。ここからはAPI仕様に基づく実装提案です。

01 / READ

調べる

許可されたデータだけを参照。まだ変更しない。

02 / PREPARE

変更案を作る

対象・変更前後・費用・期限を特定する。

03 / APPROVE

明確に承認する

利用者が何に同意したかを記録する。

04 / COMMIT

確定結果を確認

サーバーが権限と状態を再検証して実行する。

実行の境界

ツールを「読む」と「書く」に分ける。

検索・空き枠照会はread-only。外部送信、予約確定、取消、削除は副作用のあるwriteです。writeを行うバックエンドが、本人・権限・承認対象・有効期限を検査します。

モデルが高い確率で「承認された」と推測しても、それだけを実行許可にしません。承認対象の操作内容が変わった場合は、前の承認を流用しない設計にします。

失敗の境界

中断・再接続でも、二重に実行しない。

利用者の割り込みで音声を止めても、外部APIへの送信済み処理が取り消されたとは限りません。処理IDで照会し、「成功したが返事だけ失われた」状態を識別します。

再試行には冪等キーを用意し、同じ要求が二度届いても同じ予約を二重に作らない設計にします。接続の再開と、業務処理の再実行は別の問題です。[10]

ETへ移行するときのAPIチェック表
確認点ETの仕様実装の対応
発話終了turnCompleteの後も処理継続し得る受信ループを終了しない。[4]
AIの待機状態interaction_statusで通知IN_PROGRESS / IDLEをUIに反映。[4]
関数呼び出しNON_BLOCKINGのみ。同期はエラー非同期で実行し、結果を対応する呼び出しへ返す。[4]
Function schedulingETでは非対応旧例のscheduling設定をそのまま移植しない。[4]
推論設定low / medium / high。MINIMAL不可標準Liveに推論レベル設定を送らない。[3][4]
送信のturn_completetrueが進行中の生成を中断し得る受信側の完了通知と混同しない。[4]
付加機能コード実行、構造化出力、キャッシュ、URL contextなどは非対応別モデルのサンプルコードを無条件に流用しない。[4]
Proactive audio両モデルで常時有効。proactive_audio: falseはエラー旧モデルの無効化設定を削除。アプリ側の録音停止・ツール実行権限とは別に扱う。[3][4]

標準版との違い:標準LiveはNON_BLOCKINGが既定ですが、互換性のためBLOCKINGも利用できます。Function schedulingも対応します。ETの「非同期のみ・scheduling不可」を標準版へ広げて解釈しないでください。[3][4]

共通ガイドとモデル別ページの記述に差がある場合、この版では9月15日更新の個別モデル仕様を優先しました。会話中に関数へ引数を渡せることと、通常のStructured outputs機能が使えることも別です。

実運用で追加すること:認証、データ、ログ、切断への備え

ブラウザに長期のAPIキーを置かない

Live APIにはクライアント接続用の短命トークンがあります。[11] 自社の認証済みバックエンドで発行し、モデル接続の認証と、予約を変更する業務権限の認証は分離します。トークンを持っていることだけで、他人の予約へアクセスできない構成にします。〈設計提案〉

ログは「声」だけでは足りない

発話開始・終了、処理状態、ツール呼び出しID、承認された変更案、実行結果、再試行、利用量を関連づけます。全文の音声・文字起こしを無条件に保存せず、必要性と保管範囲を先に決めます。〈設計提案〉

接続が落ちた後も、業務は続いているかもしれない

Live APIのセッション再開機構だけで、外部DBの重複処理や確定済み予約の整合性まで守れるわけではありません。[10] 復帰時は処理IDで結果を照会し、不明な状態を成功と表示しないようにします。〈設計提案〉

音声入力の内容を、権限に昇格させない

利用者の発話、画面に映った文章、検索結果、ツールの返答は、操作権限の根拠ではありません。指示らしい文字列が紛れ込んでも、許可されたツール・対象・操作だけが通るよう、サーバー側で検査します。〈設計提案〉

SO WHAT

AIは提案と対話、システムは権限と確定。重要な操作ほど、この分担を崩さない。

06
JAPANESE UX & THE REPORTING TIMELINE

日本語対応と、日本語で安心して任せられることは別。

97言語への対応には日本語も含まれます。[1][9]
しかし、今回の総合スコアだけで「日本語の声が大幅に自然になった」とは結論できません。

承認設計で試すべき発話
「そのファイル、消そうか」

独り言なのか、相談なのか、実行依頼なのか。言葉だけでは一意に決まらない場面があります。「今から、どのファイルを削除するか」を示して確認する設計が必要です。

「うん」「そうだね」も、変更の承認とは限りません。高リスクの操作では、対象と操作が明確な確認に限定します。これは日本語の優劣を示す実測ではなく、評価に入れるべきシナリオ例です。

実機試験で分ける観点

自然さ・理解・実行を別々に採点する。

自然さ:読み方、間、声の好み、長く聞いたときの疲れやすさ。

理解:人名・数字・日時、言い直し、否定、雑音、日英の切替。

実行:正しい対象への操作、不要な変更をしないこと、途中で取り消せること、確定結果の説明。

発表日と、日本語の記事が出た日も分ける。

09/02 — 別の発表

Gemini 3.8 Flash

同じ3.8という名前でも、Liveと同日のニュースではありません。Gemini APIのリリースノートで日付を区別できます。[2]

09/15 — 本稿の主題

Live / Extended Thinking

Googleの公式発表日。音声対話と背景推論のモデルを同時に公開しました。[1]

09/16 — 国内の続報

日本語の記事を確認

Impress Watchは12:16 JST掲載。GIGAZINEにも同日記事があります。「国内に報道がない」とは扱いません。[19][20]

9月15日版は公式発表の日付を中心に編集し、9月16日以降の確認事項は続報・検証として区別しています。今回は国内媒体全体の網羅調査をしていないため、「大手はどこも説明していない」「日本語圏は皆この反応」といった一般化はしません。

Xでの拡散と、実証された性能をどう分けたか

表示数、いいね数、声への個人の感想は、時刻や観測範囲で変わります。本稿では再現できない投稿カウントを主要指標に採用せず、公式資料・評価機関の定義・モデル別仕様へ戻って確認しました。

「英語圏は単価、日本語圏は声や承認に注目」という見立ては、仮説にはなっても、比較調査なしに地域差の結論にはできません。自然な声を好むこと、仕事を正しく終えてほしいこと、勝手に実行してほしくないことは、併存する評価軸です。〈編集上の判断〉

SO WHAT

日本語の評価セットに「曖昧な承認」「言い直し」「否定」を入れる。流暢に返せることだけで合格にしない。

07
THREE RELATED MOVES

同じ週の動きを、「AIを仕事にする部品」として読む。

話せるモデルだけでは業務は完成しません。
既存の業務への接続、速い判断、計算資源の効率にも動きがありました。3件の共通点は本稿の分析です。

公式発表 / 既存業務への接続

Claude for Financial Advisors

2026.09.14

新モデルではなく、金融アドバイザーが使うシステムへつなぐコネクタと業務Skillsの組み合わせです。[12]

16,000+Schwabが支援する独立系RIA
導入済み企業数ではない。[13]
接続Schwab、BlackRock、Addepar、
Orion、Wealthboxなど。[12]
人が承認面談準備・資料整理・草案を支援。
重要業務の判断は人に残す。[12]

価値は「文章が上手」から「散らばった口座・顧客・面談情報を、必要な仕事の形にまとめる」ことへ移っています。面談準備やポートフォリオの確認、フォローアップ草案を支援し、重要なアクションはレビュー・承認を前提にしています。[12]

深掘り:なぜ16,000社を「即日フル接続」と書けないのか

16,000超はSchwabの顧客基盤であり、当日のアクティブ利用社数ではありません。[13] 実際の導入では、利用する接続先を選び、認証・権限・既存の契約条件を満たす必要があります。[12]

コネクタが発表されたこと、各社が接続を有効にしたこと、全機能が稼働していることは別々です。個々の接続先の「coming soon」との食い違いについては今回すべてを独立確認できていないため、断定しません。

読み解き:モデル能力が同じでも、正しい業務データへ、正しい権限で接続できるかが実用性を大きく左右します。

同社発表 / Early access

TypeSafe Jev — 文章ではなく、判断を返す。

2026.09.15

説明文を長く書く代わりに、あらかじめ決めた選択肢や尺度の上で、型付きの判断と確率を返すモデルです。入力された状態を使い、ソフトウェアの分岐へ直接つなぐ発想です。[14][15]

$0.042100万入力トークンあたり。
出力は無料という掲載価格。[14]
70–500ms同社の応答時間の説明。
日本からの保証値ではない。[14]
型は保証「型を壊さない」と
「判断が正しい」は別。[14]

何を返す?

Choice:選択肢から選ぶ。
Score:尺度上で評価する。
Noul:真偽に関する0〜1の値。
各型の確率・信頼度の扱いはAPI仕様で確認します。[15]

何に使う?〈例〉

問い合わせを既知の窓口に分類する。要確認フラグを立てる。簡単なケースと難しいケースを振り分ける。
ただし、最終的な実行権限は周囲のコードが制限します。

深掘り:「幻覚0%」と速さの主張をどう評価する?

同社自身が、0%は実証された正答率ではなくスキーマ一致の保証だと説明しています。訓練手法をRLCDと呼び、速度測定は主にサービスと同じ米国西海岸から行ったと注記。Doomデモも映像のピクセルではなく、構造化したゲーム状態を入力しています。[14]

たとえば選択肢が「承認」「保留」「拒否」なら、存在しない4つ目の文字列を返さないことと、選ぶべき項目を間違えないことは別です。高い信頼度を実行許可へ直結させず、自社データで誤判定率と、低信頼度を人に回したときの処理量を測ります。〈評価提案〉

同社の速度倍率・費用倍率は条件付きの測定です。別の公開モデルとの「同等の知能」という一般的結論や、X上の個人検証を大規模な独立評価としては採用していません。

読み解き:全部を大きなモデルの長い文章生成で解かず、「小さな判断」と「複雑な推論」を分ける余地があります。LiveやETを置き換える音声モデルではありません。

顧客PoC / 実測と投影を区別

NVIDIA DSX MaxLPS — 同じ電力枠で、処理量を増やす。

2026.09.15 / 検証結果の紹介

新チップの発表ではありません。Lambdaが、固定の電力予算内で稼働ノード数と処理量を増やした検証結果です。MaxLPSの仕組み自体は8月24日の資料でも公開済みです。[16][18]

16 → 19同じ電力予算内で稼働させた
HGX B200ノード数。[17]
+24%クラスタの推論スループット。
約4.04M → 5.00M tokens/s。[17]
+23%電力あたり性能の報告値。
全環境への保証ではない。[17]

静的な割り当てで余っていた電力枠を、負荷に合わせて使い直す仕組みです。Lambdaの例は5ラック、129kWの予算、85%の電力ポリシー。掲載図はGPT-OSS-120B、ノードあたり40 QPSという条件を示しています。[17]

深掘り:+24%と「GPU最大+40%」を混ぜない

+24%はLambdaの条件付き検証における処理量の改善です。一方、Vera Rubin NVL72で同じMWあたりGPUを最大40%多く置けるという説明はNVIDIAの投影です。対象ハードウェアも、測っている量も、証拠の段階も異なります。[16][17]

電力ポリシーの85%を掛け算するだけで、どんな設備でも同じ効果が出るわけではありません。実際の負荷、GPU以外の消費、冷却、ピーク制御、待ち時間の制約を合わせて見る必要があります。〈読み解き〉

この発表が示すのは、個々のGPUをいつも最大出力で回すことと、設備全体の処理量を最大化することは一致しない場合がある、という点です。顧客PoCの結果を全フリートで実現済みとは扱いません。[17]

読み解き:AIの費用はモデル選びだけでなく、設備の使い方でも変わります。ただし、この改善がAPI料金へ直ちに還元されるとまでは言えません。

08
FROM MODEL NEWS TO AN ADOPTION PLAN

試すなら、最初から「全部任せる」にしない。

まずは調べるだけ、次に変更案を作る、最後に承認付きで実行する
ここからはニュースを踏まえた、開発・運用チーム向けの提案です。

段階1 / Read-only

安全に比較する

合成データで問い合わせと検索を試し、標準LiveとETの日本語・正答率・最終回答時間・利用量を同じ条件で記録します。

段階2 / Draft

処理は提案で止める

予約変更などの案を作らせ、正しい対象・日時・理由になっているかを人が確認。曖昧な依頼で勝手に進まないかを試します。

段階3 / Approved write

限定した操作を任せる

承認記録、冪等キー、監査ログ、タイムアウト後の照会、人への切替がそろった範囲から実行を許可します。

管理したい指標は、少なくともこの4つ。

正しく終えたか

自社の業務上の完遂率。言い換えの上手さではなく、正しい状態になったかを確認する。

最後まで何秒か

初音までと、確定回答までの時間を分離。平均だけでなく、遅いケースのP95も見る。

1件いくらか

音声・推論・ツール・再試行・人への転送を含む、完遂1件あたりの総費用を比べる。

勝手に変えないか

未承認の変更、別人への操作、二重実行を失敗として独立集計。許容件数の目標は0に置く。

医療・金融などの業務に持ち込む前の確認

モデルがGAであることと、自社の業務に適合することは別です。まずは実データを含まない試験から始め、利用契約、入力データの扱い、保持、リージョン、アクセス権、既存の社内基準に照らして適用範囲を決めます。

たとえば診療・投資などの判断と、予約照会・面談資料の下書きではリスクが異なります。この資料はモデルとシステム設計の解説であり、特定サービスの法令適合や医療・投資判断を保証するものではありません。

補足ニュース:Siri AIとGlass Imagingは、本編から切り分ける

Siri AI:英語ベータと、言語・地域別の展開

Appleは9月14日のソフトウェア更新とともに英語ベータを案内し、日本語などは10月予定としています。[21] EUの遅れはiOS / iPadOSなどの対象を特定して読む必要があり、「EUではすべて使えない」と一括りにはしません。[22]

Glass Imaging:報道と公式確認を分ける

WSJは9月14日18:31 UTC(日本時間9月15日03:31)、OpenAIによるGlass Imagingの買収を3億ドル超の評価額で報じました。[23] 今回の調査ではOpenAI公式発表を確認できていません。買収の報道を、特定の新端末や搭載時期が確定した話へ広げません。

THE BIG PICTURE / 本稿の結論

9月15日の変化は、AIが「答える道具」から「対話しながら処理する仕組み」へ進んだこと。採用の決め手は、賢さだけでなく、正しく・安く・勝手に動かずに終えられるかです。

09
SOURCES & VERIFICATION

出典と、今回の確認範囲。

編集上の区別:「公式発表」は提供元の説明、「第三者測定」はAAの評価、「同社・顧客PoC」は条件付きの測定・投影、「読み解き/提案」は本稿の分析です。新しい情報を含めた確認日は2026年9月17日 JST。AAの動的ランキングを9月15日時点の保存表と偽って扱っていません。

意図的に断定しなかったこと:Xの表示数や反応の国別傾向、日本語音声の改善幅、未確認の個人ベンチマーク、16,000社の実利用、API料金への将来の値下げ効果、未公式の買収に基づく製品計画。数値の小差には誤差と測定条件の注意を付けました。

このHTMLについて:冒頭のダッシュボード画像は images/0915/cover.jpg を相対参照し、本文・スタイル・説明用JavaScriptはファイル内に含まれます。閲覧時の外部フォント・解析タグ・API呼び出しはありません。出典リンクを開く場合だけ外部サイトへ移動します。参照した9月13日版と同様、1枚の画像から入り、本文の疑問へ進む構成です。[24]
[9]
Live API:Capabilities ↗

2026-09-17確認

言語、音声と映像、モデル比較。個別モデルの仕様を優先して読む。

ONE SENTENCE TO TAKE AWAY

声を返す速さではなく、
安心して仕事を終えられるか。

会話、推論、実行。つなぐところと、切り分けて守るところを決める。

1枚ダッシュボード