話している途中から、数秒遅れで、話者の声の調子を残したまま別の言語の音声が流れてくる。Googleが2026年6月に公開した Gemini 3.5 Live Translate を初めて試したとき、多くの人が「これは今までの翻訳機とは別物だ」と感じるはずです。この記事では、Googleの「Speech-to-Speech（音声から音声へ）」系モデルがどういう仕組みなのか、社内のプログラムからどう呼び出して検証するのか（最初の一歩と最小コード）、APIの利用料金はいくらか、そして精度をどう見ればよいかを、実務で検証を任されたエンジニアと、その報告を受ける経営層の両方に向けて整理します。

※本記事の情報は2026年9月時点の公式ドキュメント・料金表・モデルカードに基づきます。対象モデルは「プレビュー（公開前評価）」段階で、仕様・料金・モデル名は変わる可能性があります。

1. 何が「凄い」のか：文の終わりを待たずに、声ごと翻訳する

従来の音声翻訳は、①音声を文字にする（音声認識） → ②文字を翻訳する → ③翻訳文を読み上げる（音声合成）という3段階を直列につないだ「カスケード型」でした。この方式には構造的な弱点があります。文が終わるまで待つので必ず「間」が生まれ、②の段階で声の高さ・速さ・感情といった情報は捨てられ、③では別人の合成音声で読み上げられる。

Gemini 3.5 Live Translateは、この3段を1つのモデルで音声から音声へ直接行います。Googleの説明によれば、話者が話し終えるのを待たず、文脈を待って品質を上げるか即座に訳して同期を保つかのバランスを取りながら連続的に音声を生成し、セッション全体を通じて話者の数秒後ろを走り続ける。しかも話者の抑揚・間・声の高さを保つので、翻訳音声が「その人が別の言語で話しているように」聞こえます。対応は70以上の言語で、話者の言語は自動検出、途中で言語が切り替わる会話にも対応します。

文末を待たず、声の情報を捨てずに翻訳する。1つのモデルで音声→音声

2. どういうモデルなのか：Gemini 3 Proを土台にした「音声ネイティブ」モデル群

公式のモデルカード（2026年8月26日公開）によると、Gemini 3.5 Live TranslateはGemini 3 Proを基盤とし、音声とテキストを入力（コンテキスト最大128Kトークン）、音声とテキストを出力（最大64Kトークン）します。生成された音声にはすべてSynthIDという不可視の電子透かしが入り、AI生成音声であることを後から検出できます。

ここで大事なのは、Googleが「Speech-to-Speech」と呼べるモデルを用途別に複数用意している点です。一般に「GoogleのSpeech to Speech」と言われるとき、指しているのは主に次の2つのどちらかです。

  • Gemini 3.5 Live Translate（モデルID：gemini-3.5-live-translate-preview）
    音声を別言語の音声に翻訳する専用モデル。推論やツール呼び出しはしない。
    向いている用途：会議・通話・接客の同時通訳、配信の吹き替え

  • Gemini 3.1 Flash Live（モデルID：gemini-3.1-flash-live-preview）
    音声で対話する汎用モデル。声のニュアンスを読み、関数呼び出し（社内システム連携）もできる。
    向いている用途：音声エージェント、電話応対、音声アシスタント

  • Gemini 3.5 Transcribe / Transcribe Live（モデルID：gemini-3.5-transcribe / -live）
    音声を文字にする（話者分離、タイムスタンプ、言語自動検出）。
    向いている用途：議事録、文字起こし、字幕

  • Gemini 3.1 Flash TTS（モデルID：gemini-3.1-flash-tts-preview）
    文字を音声にする（タグで抑揚・速度を指示）。
    向いている用途：ナレーション、音声コンテンツ生成

「翻訳したい」ならLive Translate、「AIと話して仕事をさせたい」ならFlash Live、と覚えておけば迷いません。どちらも、開発者向けにはWebSocketで音声を双方向に流し続ける Gemini Live API 経由で使います。

翻訳したいなら Live Translate、AIと対話させたいなら Flash Live。1時間の会議で約330円

3. 最初の始め方：30分で「動く」ところまで

ステップ0：コードを書かずに体験する（5分・無料）

Google AI Studio（aistudio.google.com）の「Live」画面でモデルに gemini-3.5-live-translate-preview を選び、マイクの使用を許可して話すだけです。まずここで、自社の業務で使う言い回しや固有名詞を実際に喋ってみてください。API検証に進む価値があるかどうかは、この5分でかなり見えます。

ステップ1：APIキーとSDK（5分）

AI Studioで APIキーを取得し、PythonのSDKを入れます。

pip install google-genai
export GEMINI_API_KEY="取得したキー"

ステップ2：最小コード（15分）

Live APIは、通常のリクエスト／レスポンスではなく、WebSocketで接続を張り続け、音声チャンクを送りながら翻訳音声チャンクを受け取るという作りです。公式ドキュメントの例を、検証で最低限必要な形に整理すると、骨格は次のようになります。

import asyncio
from google import genai
from google.genai import types

client = genai.Client()  # 環境変数 GEMINI_API_KEY を読む
MODEL = "gemini-3.5-live-translate-preview"

config = types.LiveConnectConfig(
    response_modalities=["AUDIO"],
    input_audio_transcription=types.AudioTranscriptionConfig(),   # 入力の文字起こしも受け取る
    output_audio_transcription=types.AudioTranscriptionConfig(),  # 出力の文字起こしも受け取る
    translation_config=types.TranslationConfig(
        target_language_code="en",   # 翻訳先（例：英語）。入力言語は自動検出
        echo_target_language=False,  # 入力が既に英語だったとき、そのまま流すか
    ),
)

async def run(pcm_chunks):
    async with client.aio.live.connect(model=MODEL, config=config) as session:

        async def sender():
            for chunk in pcm_chunks:  # 16kHz / 16bit / モノラル PCM を100msずつ
                await session.send_realtime_input(
                    audio=types.Blob(data=chunk, mime_type="audio/pcm;rate=16000")
                )
                await asyncio.sleep(0.1)  # 実時間に合わせて流す

        async def receiver():
            async for msg in session.receive():
                sc = msg.server_content
                if not sc:
                    continue
                if sc.input_transcription:
                    print("[入力]", sc.input_transcription.text)
                if sc.output_transcription:
                    print("[出力]", sc.output_transcription.text)
                if sc.model_turn:
                    for part in sc.model_turn.parts:
                        if part.inline_data:
                            save_or_play(part.inline_data.data)  # 24kHz PCM の翻訳音声

        await asyncio.gather(sender(), receiver())

押さえるべき仕様は3つだけです。入力は16kHz・16bit・モノラルのPCM、出力は24kHzのPCM、チャンクは100ms単位が推奨。 マイクからのリアルタイム入力や、ブラウザ・スマホからの接続は、この上にメディア配信の実装が必要になります。ここは自作せず、Googleが公式に連携を案内している LiveKit、Pipecat、Agora などのフレームワークを使うのが近道です（LiveKitを使った同時通訳のデモコードがGeminiのCookbookに公開されています）。

なお、ブラウザやアプリから直接つなぐ場合、永続的なAPIキーをクライアント側に置いてはいけません。サーバー側で短寿命の「エフェメラルトークン」を発行してクライアントに渡す方式が公式に案内されています。前回のセキュリティ記事でお伝えした「APIキーを直書きしない」原則が、ここでもそのまま当てはまります。

4. 社内で「本当に使えるか」を検証する手順

ここが本記事の中心です。デモが凄いのは分かった。問題は、自社の会議・自社の接客・自社の専門用語で、どこまで使えるかです。Googleは評価の「方法」（後述）は公開していますが、翻訳品質の数値は公開していません。独立したベンチマークもまだありません。つまり自社で測るしかない、というのが2026年9月時点の現実です。

4-1. テスト音声を用意する（最重要）

評価の質はテストセットで決まります。次の観点を意図的に混ぜた、合計30〜60分程度の録音を用意します。

  • 自社の固有名詞・専門用語：製品名、部署名、業界用語。ここが一番落ちやすい。
  • 数字・日付・金額：「15日」と「50日」、「1,500万」など。契約や発注に直結する。
  • 話者の混在：2〜3人が短く言葉を交わす会話。モデルカードが「複数話者の速い会話で声が固定される場合がある」と明記している弱点。
  • 言語の切替：日本語の中に英語の用語が混ざる、途中で英語話者が割り込む。「言語検出は非ネイティブの訛り・似た言語・速い切替で苦戦する」と明記されている。
  • 雑音：店頭、工場、オンライン会議のエコー。「背景音を完全には無視できない」と明記されている。
  • 長い沈黙：数十秒の沈黙のあとに再開する。「長い間のあとで声が変わる場合がある」と明記されている。

弱点をGoogle自身が書いてくれているので、そこを狙って録るのが効率的です。

4-2. 何を測るか：Googleの評価軸をそのまま借りる

Googleの評価方法書（Evals & Methodology）は、3つの軸で評価すると書いています。社内検証もこの3軸に揃えると、後で公式情報と比較しやすくなります。

  1. 翻訳品質：Googleは AutoMQM（翻訳の誤りを種類別に検出して点数化する自動指標）を使っています。社内では、出力側の文字起こし（output_transcription）を保存し、①バイリンガルの担当者が「意味の誤り／用語の誤り／欠落」を数えるMQM方式の人手評価、②参照訳を用意してCOMETなどの自動指標、のどちらか（できれば両方）で採点します。
  2. 遅延：①話し始めから翻訳音声が出始めるまでの「初期遅延」、②入力の単語と対応する出力の単語の時間差「単語レベル遅延」。入力・出力の文字起こしにタイムスタンプを付けて記録すれば、単語レベルの近似値は自動で出せます。
  3. 音声の自然さ：途切れ、声のドリフト（セッション中に声質が変わる）、ノイズ的なアーティファクト。ここは人手評価（5段階のMOS方式）が現実的です。

4-3. 判定基準を先に決める

「凄い」で終わらせないために、検証前に合否ラインを決めます。たとえば「固有名詞の正答率90%以上」「初期遅延の中央値3秒以内」「30分セッションで声のドリフトなし」など。ラインは用途で変わります。社内会議の補助なら緩く、顧客との契約確認なら厳しく。

Googleは評価方法を公開、数値は非公開。自社の音声で3軸（品質・遅延・自然さ）を測る

4-4. 比較対象を1つ置く

同じテスト音声を、既存のカスケード型（例：音声認識＋翻訳API＋音声合成）や、汎用モデル（Gemini 3.5 Flashに文字起こしを翻訳させる非リアルタイム処理）にも通しておくと、「Live Translateが本当に必要か」が判断できます。リアルタイム性が要らない用途（録画の翻訳など）なら、汎用モデルのほうが安く、文脈も長く扱えます。

5. API利用料金：1分あたり約5.5円、1時間の会議で約330円

Gemini Developer API（AI Studio経由）の公式料金表（2026年9月時点）は次の通りです。音声は1秒＝25トークンで課金されます。

  • Gemini 3.5 Live Translate
    入力（音声）：$3.50 / 100万トークン（≒$0.0053/分）／出力（音声）：$21.00 / 100万トークン（≒$0.0315/分）
    → 1分あたり約$0.0368（Google試算）

  • Gemini 3.1 Flash Live
    入力（音声）：$3.00 / 100万トークン（≒$0.005/分）／出力（音声）：$12.00 / 100万トークン（≒$0.018/分）
    → 会話の半分ずつ話すなら約$0.012（約1.8円）

  • Gemini 3.5 Transcribe Live（文字起こし）
    入力（音声）：$3.50 / 100万トークン／出力（テキスト）：$21.00 / 100万トークン
    → 約$0.009

1ドル150円で換算すると、Live Translateは1分あたり約5.5円、1時間あたり約330円。月に100時間の海外拠点会議で使っても約3万3千円です。人間の同時通訳者の相場と比べれば桁が2つ違います。

料金で見落としがちな点を3つ補足します。

  • 無料枠がある：Live Translateには無料枠があり、検証段階はまず無料で始められます。ただし無料枠の利用内容は「Googleの製品改善に使われる」と料金表に明記されています。社内の会議音声や顧客との会話を無料枠で流してはいけません。 検証でも、機密を含む音声は有料枠に切り替えてから流す運用にしてください。
  • Vertex AI（Gemini Enterprise Agent Platform）は別料金表：企業がデータ所在地やセキュリティ要件で Google Cloud 側を使う場合、料金は Cloud の料金ページに従います。金額は近いことが多いですが、稟議には Cloud 側の表を添えてください。
  • 双方向会話は2倍近くなる：上の1分あたり試算は「1本の音声ストリーム」の入出力合計です。日英の話者が交互に話す2方向の同時通訳では、2セッション分に近いコストになります。

6. 精度をどう見るか：公式が言っていること、言っていないこと

公式が公開していること

  • 評価は「翻訳品質（AutoMQM）」「遅延（初期遅延・単語レベル遅延）」「音声の自然さ」の3軸で行ったこと。
  • 既知の限界として、声の不安定さ（長い沈黙後の変化、複数話者での固定）、言語検出の弱点（訛り・類似言語・速い切替）、背景音の残留、目標言語をエコーする設定時の雑音アーティファクト。
  • 姉妹モデルの Gemini 3.5 Transcribe については具体的な数値があり、Googleは実環境の雑音入り音声での平均単語誤り率をストリーミングで4.0%、非ストリーミングで2.6%、多言語ベンチマークFLEURSの主要言語で5.50%／5.04%と公表しています（翻訳の前段である「聞き取り」の実力の目安になります）。

公式が公開していないこと

  • Live Translateの翻訳品質の数値。言語ペア別の精度も非公開。
  • 日本語を含む特定言語ペアでの性能。

第三者の声

  • 開発プラットフォームのAgoraは、社内テストで「低遅延と高精度でリアルタイム翻訳の新たな水準」と評価。CJ ENM、LiveKitなども肯定的なフィードバックを寄せた、とGoogleは紹介しています。
  • ただし、いずれも導入パートナーの声であり、独立した第三者ベンチマークは2026年9月時点で見当たりません。

結論として、**「精度は高いらしいが、自社の用途で数字を持っているのは自社だけ」**という状態です。だからこそ第4章の検証手順が必要になります。

7. 企業でどう活用できるか：用途を「翻訳」と「対話」に分けて考える

Speech-to-Speechの活用先を考えるときは、第2章の区分をそのまま使います。言葉の壁を越えたいなら Live Translate、AIに話しかけて仕事をさせたいなら Flash Live。この2つを混ぜて考えると、要件も検証もぼやけます。

翻訳か対話か × 誤りのコスト。左上（会議・接客）から始めて右下（顧客対応エージェント）へ

  • 海外拠点・取引先との会議（Live Translate／難易度：低）
    英語が苦手な参加者も議論に入れる。Google Meetの翻訳も同モデルへ移行予定。
    先に潰すべきリスク：専門用語・数字の誤訳。会議録音の保存先とデータ管理。

  • インバウンド接客（店頭・宿泊・観光）（Live Translate／難易度：低〜中）
    スタッフのスマホ1台で70+言語に対応。Google翻訳アプリでも同モデル。
    先に潰すべきリスク：店頭の雑音、複数話者。金額・日時の確認は画面表示と併用。

  • 外国人従業員への現場指示・安全教育（Live Translate／難易度：中）
    現場の口頭指示を母語で伝えられる。事故防止に直結。
    先に潰すべきリスク：安全に関わる指示は誤訳が許されない。文字表示・確認応答を必須に。

  • 多言語コールセンター（Live Translate＝人が応対／Flash Live＝AIが応対、難易度：中〜高）
    言語別の人員配置が不要になる。AI一次応対で待ち時間を削減。
    先に潰すべきリスク：顧客対応は誤りのコストが高い。人へのエスカレーション設計が前提。

  • 社内ヘルプデスク・予約受付の音声エージェント（Flash Live／難易度：中〜高）
    電話やアプリからの問い合わせをAIが受け、社内システムを関数呼び出しで操作。
    先に潰すべきリスク：権限管理（AIに何を操作させるか）。本人確認。

  • セミナー・配信・eラーニングの多言語化（Live Translate／難易度：中）
    1つの登壇音声を同時に複数言語で配信（吹き替え）。
    先に潰すべきリスク：配信遅延との同期。録画物なら非リアルタイムの汎用モデルのほうが安い。

  • 音声でのデータ入力・報告（点検・営業日報）（Flash Live + Transcribe／難易度：中）
    手が離せない現場で、話すだけで報告が構造化データになる。
    先に潰すべきリスク：数字・固有名詞の精度。入力後の確認画面。

Googleが公開している事例も、この2軸にきれいに分かれます。翻訳側では、東南アジアの配車サービスGrabが、ドライバーと旅行者の待ち合わせ時の多言語会話（月1,000万件超の通話）で検証中。対話側では、米国の住宅ローン会社UWMが Flash 系の音声モデルを組み込んだ音声システムで1万4,000件以上のローン処理を行い、受付AIを提供するNewo.aiは雑音下でも主話者を識別し、通話中に言語を切り替えられると報告しています。

日本の企業にとって現実的な入り口は、上の2〜3項目です。会議と接客は「失敗しても取り返せる」うえに効果がすぐ見え、しかも Google Meet と Google翻訳アプリという既製品で先に体験できる。ここで自社の音声での合格ラインを確認してから、コールセンターや音声エージェントのような「誤りのコストが高い」領域に進む順番をお勧めします。

8. 企業が開発するときの注意点：6つの観点

デモは1日で動きます。本番で使えるものにするには、次の6観点を最初から設計に入れておく必要があります。

デモは1日で動く。本番はこの6観点を最初から設計に入れる

① データの扱い（最優先）

  • 無料枠に流した音声は「Googleの製品改善に利用される」と料金表に明記されています。社内音声・顧客音声は有料枠かVertex AI（Gemini Enterprise Agent Platform）で。
  • 音声は個人情報の塊です。録音の保存要否、保存期間、保存先リージョン、誰がアクセスできるかを先に決める。「翻訳だけしてログは残さない」のか「品質改善のために文字起こしを残す」のかで設計が変わります。
  • 会話相手（顧客・取引先）への告知。AIが通訳・応対していること、録音の有無を伝える文言と同意の取り方を法務と決めておく。

② 認証・鍵の管理

  • ブラウザ・スマホから直接 Live API につなぐ構成では、永続APIキーをクライアントに置かない。自社サーバーで短寿命のエフェメラルトークンを発行し、翻訳設定を固定して渡す方式が公式に案内されています。
  • サーバー側では鍵をSecret Managerなどで管理し、コードに直書きしない（本連載のセキュリティ記事で繰り返している原則です）。

③ 信頼性とフォールバック

  • 対象はプレビュー段階のモデルで、仕様変更・提供終了・レート制限の変更が起こり得ます。本番の中核に置くなら、モデルIDを設定値にして差し替え可能にしておく。
  • WebSocket接続は切れます。切断時の自動再接続と、再接続までの間の字幕（文字）へのフォールバックを用意する。
  • 「聞き取れなかった」「翻訳に自信がない」ときの振る舞いを決める。黙るのか、聞き返すのか、人に回すのか。

④ 誤訳・誤動作のコストに応じた人の介在

  • 金額・日時・数量・安全指示のような「間違えると損害が出る」情報は、音声だけで完結させず、画面に文字で出して確認する二重化を入れる。
  • 音声エージェントが社内システムを操作する（関数呼び出し）場合は、Mollick氏のガイドで紹介した原則と同じで、「送る・買う・消す」系の操作は人の承認を挟む。
  • エスカレーション（人へ引き継ぐ）導線は、後付けではなく最初の画面設計に含める。

⑤ コスト管理

  • 1分約5.5円は安いが、双方向通訳は約2倍、同時接続数が増えれば線形に増える。セッションごとの利用時間・トークン数をログに残し、部署別に集計できるようにしておく。
  • 無音時間も入力トークンとして課金されます。無音検出（VAD）で送信を止める、一定時間無音ならセッションを閉じる、といった制御で無駄を減らせます。
  • 大量・安定利用が見えてきたら、Vertex AI側の Provisioned Throughput（予約制の処理能力）の検討対象になります。

⑥ 評価と継続改善の仕組み

  • 第4章の3軸（翻訳品質・遅延・自然さ）を、PoCで一度測って終わりにせず、本番でもサンプリングして定期的に測る。モデルが更新されると挙動が変わるため、回帰テスト用の音声セットを社内資産として持っておく。
  • 現場からの「ここが変だった」を集める窓口（ボタン1つで該当区間を報告できる等）を用意する。

9. インフラ構成：2つの基本パターン

Live APIは「音声を流し続ける」性質上、通常のREST APIを呼ぶシステムとは構成が変わります。企業で組む場合の基本形は2つです。

PoCはA、機密・顧客対応はB。共通の5要素（トークン発行・ゲートウェイ・ログ・フォールバック・同意UI）

パターンA：Gemini Developer API 直結（PoC〜小規模）

  • クライアント（ブラウザ／スマホ／会議室端末）→ 自社の軽量サーバー（トークン発行・設定固定・利用ログ）→ Gemini Live API（WebSocket）。
  • 音声のキャプチャ、チャンク化、再生、エコーキャンセルはクライアント側の実装負荷が大きい。LiveKit、Pipecat、Agora などのリアルタイム音声フレームワークを使うと、WebRTCでの音声配信とLive APIの橋渡しを任せられます（GoogleがLiveKitを使った同時通訳デモを公開しています）。
  • 適用：社内会議の補助、店頭のスマホ運用、PoC。数十同時接続まで。

パターンB：Vertex AI（Gemini Enterprise Agent Platform）経由（本番・機密あり）

  • クライアント → 自社のメディアゲートウェイ（Cloud Run／GKE 上のLiveKit等）→ Vertex AI の Live API。認証はIAM・サービスアカウントで行い、APIキーを使わない。
  • VPC Service Controls で通信境界を作り、データ所在地（リージョン）を指定できる。監査ログ、リクエスト／レスポンスのログ記録もCloud側の仕組みに乗せられる。
  • 録音・文字起こしを残す場合は Cloud Storage／BigQuery に保存し、保持期間と暗号鍵（CMEK）をポリシーで管理する。
  • 適用：コールセンター、顧客対応、社内機密を含む会議。数百同時接続以上や安定稼働が必要な場合は Provisioned Throughput を検討。

両パターン共通の設計要素

  1. トークン発行サーバー：クライアントに永続鍵を渡さない。翻訳先言語・モデルIDなどの設定をサーバー側で固定する。
  2. メディアゲートウェイ：WebRTC（クライアント）と WebSocket（Live API）の変換、16kHz/24kHz のサンプリング変換、無音検出、再接続。
  3. ログ・計測：セッションID単位で、利用時間、トークン数、遅延、切断回数、言語ペアを記録。コスト集計と品質監視の両方に使う。
  4. フォールバック経路：Live APIが不調のとき、字幕表示（Transcribe Live）や人へのエスカレーションに切り替える。
  5. 同意と告知のUI：AI通訳・録音の有無を表示し、必要なら同意を記録する。

どこまで作るかは用途の重さで決めます。会議補助ならパターンAを1〜2週間で組んで検証し、顧客対応に広げる段階でパターンBへ移す、というのが投資対効果の良い順序です。

10. Four Youの見解：始める順番と、外してはいけない3つのルール

技術的に「凄い」ことと、業務で「効く」ことは別です。私たちは日本の中堅・中小企業に対して、第7章の並びの上から順に、次のように進めることを勧めています。

1. 海外拠点・海外取引先とのオンライン会議の補助。 参加者全員が英語を話せる会社は少数です。Live Translateを「聞き取りの補助」として片方向で流すだけでも、会議の質が変わります。Google Meetの翻訳機能も同じモデルに置き換わっていくので、まずAPIで自社の会議音声を検証し、良ければ Workspace の機能を待つ、という2段構えが現実的です。

2. インバウンド接客・外国人従業員への現場指示。 店頭や現場は雑音が多く、モデルカードの弱点がそのまま出る環境です。逆に言えば、ここで合格ラインを超えるなら本番投入の根拠になります。スマホの Google翻訳アプリでも同じモデルが使えるので、現場担当者に1週間使ってもらう「体験検証」から始められます。

3. コールセンター・電話応対の多言語化。 ここは翻訳専用の Live Translate ではなく、関数呼び出しで社内システムと連携できる Gemini 3.1 Flash Live の領域です。誤りのコストが高いため、第8章の6観点をすべて満たし、第9章のパターンBで組むことが前提になります。

いずれの場面でも、プレビュー段階のモデルを差し替え不能な形で本番の中核に置かない、無料枠に機密音声を流さない、クライアントにAPIキーを置かないの3点は、検証開始前に社内ルールにしておいてください。

Four Youでは、Live APIを使った音声翻訳・音声エージェントのPoC（テストセット設計、評価スクリプト、料金試算）から、Vertex AIを使った本番インフラの設計・構築（認証、ネットワーク境界、ログ、フォールバック）までをご支援しています。「うちの会議・うちの現場で試したい」「PoCは終わったが本番の組み方が分からない」という企業様は、お気軽にご相談ください。

出典

#SpeechToSpeech #音声翻訳 #Gemini #GeminiLiveTranslate #GeminiLiveAPI #GoogleAI #同時通訳AI #音声AI #生成AI #API料金 #PoC #AI導入 #FourYou