第2回個人開発でできるリアルタイム翻訳 - 500msを実現するLLMストリーミング

4言語の双方向翻訳に対応: 英語・日本語・スペイン語・中国語の任意の組み合わせでリアルタイム双方向翻訳が可能です。ソースコードはGitHubで公開しています。

第1回では、Intent-First Translationという音声翻訳のアプローチをご紹介しました。話し始めてから約500ミリ秒で意図を表示し、会話のテンポを維持するという考え方と、Deepgram・FastAPI・WebSocketによる基盤構成について述べました。

今回は、核心となるLLMストリーミング実装について詳しく解説します。デュアルプロンプト戦略、ストリーミングJSON抽出、デバウンス・フィルタリング処理、そしてこれらを結合するフロントエンドの段階的表示まで、実際のコードを交えて説明します。

3つのレイヤーで「段階的に」情報を届ける

Intent-First Translationは、単一の翻訳処理ではありません。速度の異なる3つのレイヤーを重ねて、段階的に情報を提供する構造になっています。

Layer 1: キーワード予測     → 約0ms   （LLM不要）
Layer 2: 意図ラベル（Intent）→ 約500ms （LLMストリーミング）
Layer 3: 完全翻訳            → 約500-800ms（LLMストリーミング続き）

Layer 1：キーワード予測（遅延ほぼゼロ）

音声認識から届く断片的なテキストに対して、LLMを使わず辞書ベースで即座にトピックを予測します。

“meeting” → 「会議」、“budget” → 「予算」、“Tuesday” → 「火曜日」

これだけでも、聞き手は「会議と予算と火曜日の話だな」と瞬時に把握できます。LLMの応答を待つ必要がないため、ほぼゼロ遅延で表示されます。

Layer 2 & 3：LLMによる意図推定と翻訳

音声認識（Deepgram）のPartial結果——話している途中のまだ確定していないテキスト——が更新されるたびに、LLMへJSON形式で意図推定と翻訳を依頼します。

ポイントはストリーミング出力です。LLMがJSONを上から1文字ずつ生成するのを、リアルタイムでパースして、生成され次第フロントエンドへ送信しています。

JSONのフィールド順序が速度を決めていた

ここが今回最もお伝えしたい点です。

LLMのストリーミング出力は、JSONを上から順番に生成します。つまり、最初に定義されたフィールドが最初に生成され、最後のフィールドは最後に生成されます。

これは、フィールドの配置順序によって、各情報がユーザーに届くタイミングが変わることを意味します。

意図と翻訳を先に配置した場合

{
  "dialogue_act": "PROPOSAL",
  "intent_label": "日程調整の提案",     ← すぐ表示される
  "slots": {"when": "Tuesday"},
  "full_translation": "火曜に...",       ← 翻訳も早めに届く
  "confidence": 0.85,
  "is_meaning_stable": true
}

翻訳を最後に配置した場合

{
  "dialogue_act": "PROPOSAL",
  "slots": {"when": "Tuesday"},
  "key_terms": ["meeting", "reschedule"],
  "confidence": 0.85,
  "is_meaning_stable": true,
  "intent_label": "日程調整の提案",
  "full_translation": "火曜に..."        ← すべての生成を待つ必要がある
}

後者の場合、翻訳が表示されるまでに全フィールドの生成を待つことになり、体感で約2倍の遅延が発生しました。

JSONのフィールド順序を入れ替える——たったこれだけの変更で、翻訳の表示速度がほぼ2倍に向上しました。LLMの「上から順に生成する」という性質を理解したことで見つかった最適化です。

デュアルプロンプト戦略

音声認識の結果には2種類あります。

Partial（進行中）: 話している最中の不完全なテキスト（例: “I think we should…”）
Final（確定）: 発話が完了した確定テキスト（例: “I think we should reschedule the meeting to Tuesday.”）

この2つに対して、同じプロンプトを使うのは非効率だと気づきました。

状態	目的	プロンプトの方針
Partial（進行中）	速く意図を表示する	速度重視：意図 → 翻訳を先に生成
Final（確定）	正確な翻訳を提供する	品質重視：文脈分析を先に行い、翻訳の精度を上げる

話している最中はスピード優先で大まかな意図と翻訳を先行表示し、話し終わった時点で品質優先の正確な翻訳に差し替えます。

これは、人間の同時通訳者が行っていることと同じ構造です。まず大意を伝え、確定したら正確に訂正する。

以下が実際のプロンプトです。

SPEEDプロンプト（Partial / 進行中の発話用）

INTENT_SYSTEM_PROMPT_SPEED = """あなたはリアルタイム同時通訳AIです。
英語の発話をリアルタイムで日本語に翻訳します。

処理順序（重要）:
1. まず対話行為(dialogue_act)を判断
2. 意図(intent_label)を抽出
3. 重要情報(slots)を特定
4. 上記を考慮して翻訳(full_translation)を生成

翻訳ルール:
- 自然で流暢な日本語に翻訳してください
- 文が途中でも、現時点で言いたいことを推測して完結した日本語にしてください

その他のルール:
- intent_labelは日本語で10文字以内
- 出力は必ず指定されたJSON形式で行ってください

出力JSON形式（この順序で出力すること）:
{
  "dialogue_act": "QUESTION | PROPOSAL | AGREEMENT | ...",
  "intent_label": "短い日本語ラベル",
  "slots": {"when": "", "who": "", "where": "", "what": ""},
  "full_translation": "文脈を考慮した自然な日本語訳",
  "key_terms": ["重要な単語"],
  "confidence": 0.0〜1.0,
  "is_meaning_stable": true/false
}

注意: JSON以外の文字は出力しないでください。"""

SPEEDプロンプトでは、intent_labelとfull_translationがJSONスキーマの前半に配置されています。LLMはトークンを上から順に生成するため、これらのフィールドが先に生成され、話者がまだ話している最中でも意図と概略的な翻訳をユーザーにすぐ届けることができます。

QUALITYプロンプト（Final / 確定した発話用）

INTENT_SYSTEM_PROMPT_QUALITY = """あなたはリアルタイム対話支援AIです。
入力される英語から、話者の「意図」と「重要な単語」を抽出し、正確な翻訳を行ってください。

ルール:
- まず対話行為(dialogue_act)と重要情報(slots)を分析してください
- その分析結果を踏まえて、文脈に即した正確な翻訳を行ってください
- 出力は必ず指定されたJSON形式で行ってください
- intent_labelは日本語で10文字以内

出力JSON形式（この順序で出力すること）:
{
  "dialogue_act": "QUESTION | PROPOSAL | AGREEMENT | ...",
  "slots": {"when": "", "who": "", "where": "", "what": ""},
  "key_terms": ["重要な単語"],
  "confidence": 0.0〜1.0,
  "is_meaning_stable": true/false,
  "intent_label": "短い日本語ラベル",
  "full_translation": "文脈を考慮した正確な日本語訳"
}

注意: JSON以外の文字は出力しないでください。"""

QUALITYプロンプトでは、slots、key_terms、confidenceが先に配置されており、LLMは翻訳を生成する前に文脈を分析します。intent_labelとfull_translationは最後に配置されているため、先行する分析結果の恩恵を受けることができます。これは、人間の通訳者が丁寧な翻訳を行う前にまず文脈を理解する時間を取るのと同じ構造です。

全プロバイダーのLLM呼び出しコード

本システムでは、3つのプロバイダーに対応しています。フロントエンドのトグルでワンクリック切り替えが可能です。

プロバイダー	種別	モデル
OpenAI	自社開発モデル	GPT-4o-mini
Google Gemini	自社開発モデル	Gemini 2.5 Flash Lite
Groq	オープンソースモデルの推論プラットフォーム	Llama 4 Maverick, Llama 3.3 70B 等

クライアント初期化

from openai import AsyncOpenAI
import google.generativeai as genai

# OpenAI — 標準クライアント
openai_client = AsyncOpenAI(api_key=os.getenv("OPENAI_API_KEY"))

# Google Gemini — 独自SDK
genai.configure(api_key=os.getenv("GOOGLE_API_KEY"))
gemini_model = genai.GenerativeModel("gemini-2.5-flash-lite")

# Groq — OpenAI互換APIを提供しているため、AsyncOpenAIクライアントをそのまま使える
GROQ_BASE_URL = "https://api.groq.com/openai/v1"
groq_client = AsyncOpenAI(base_url=GROQ_BASE_URL, api_key=os.getenv("GROQ_API_KEY"))

# Groqでは複数のオープンソースモデルから選択可能
GroqModel = Literal[
    "llama-3.1-8b-instant",
    "llama-3.3-70b-versatile",
    "meta-llama/llama-4-maverick-17b-128e-instruct",
    "openai/gpt-oss-120b",
]
groq_model_name: GroqModel = "llama-3.3-70b-versatile"  # デフォルト

GroqがOpenAI互換APIを提供しているのは実装上の大きな利点です。base_urlを変えるだけで、OpenAIとまったく同じコードで呼び出せます。

OpenAI（GPT-4o-mini）

async def _call_gpt4(self, text: str, is_final: bool):
    start_time = time.time()
    system_prompt = INTENT_SYSTEM_PROMPT_QUALITY if is_final else INTENT_SYSTEM_PROMPT_SPEED

    context = ""
    if self.context_history:
        context = "過去の発話:\n" + "\n".join(self.context_history[-3:]) + "\n\n"
    user_prompt = f"{context}現在の発話（{'確定' if is_final else '進行中'}）:\n{text}"

    stream = await openai_client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[
            {"role": "system", "content": system_prompt},
            {"role": "user", "content": user_prompt},
        ],
        temperature=0.3, max_tokens=500, stream=True,
    )

    full_response = ""
    async for chunk in stream:
        if chunk.choices[0].delta.content:
            full_response += chunk.choices[0].delta.content
            await self._process_streaming_chunk(full_response, text, ...)

    await self._finalize_response(full_response, text, is_final, start_time, "GPT-4")

Google Gemini（2.5 Flash Lite）

Gemini は独自SDKを使用し、非ストリーミングで呼び出しています。asyncio.to_threadでブロッキングを回避します。

async def _call_gemini(self, text: str, is_final: bool):
    start_time = time.time()
    system_prompt = INTENT_SYSTEM_PROMPT_QUALITY if is_final else INTENT_SYSTEM_PROMPT_SPEED

    context = ""
    if self.context_history:
        context = "過去の発話:\n" + "\n".join(self.context_history[-3:]) + "\n\n"
    user_prompt = f"{context}現在の発話（{'確定' if is_final else '進行中'}）:\n{text}"
    full_prompt = f"{system_prompt}\n\n{user_prompt}"

    # Gemini APIは同期呼び出し → asyncio.to_threadでラップ
    response = await asyncio.to_thread(
        lambda: gemini_model.generate_content(
            full_prompt,
            generation_config=genai.types.GenerationConfig(
                temperature=0.3, max_output_tokens=1000,
            ),
        )
    )

    full_response = response.text if response.text else ""
    await self._finalize_response(full_response, text, is_final, start_time, "Gemini")

Groq（Llama等オープンソースモデル）

GroqはOpenAI互換APIなので、_call_gpt4とほぼ同じコード構造です。違いはクライアントとモデル名だけです。

async def _call_groq(self, text: str, is_final: bool):
    start_time = time.time()
    system_prompt = INTENT_SYSTEM_PROMPT_QUALITY if is_final else INTENT_SYSTEM_PROMPT_SPEED

    context = ""
    if self.context_history:
        context = "過去の発話:\n" + "\n".join(self.context_history[-3:]) + "\n\n"
    user_prompt = f"{context}現在の発話（{'確定' if is_final else '進行中'}）:\n{text}"

    # groq_client は AsyncOpenAI(base_url=GROQ_BASE_URL) で初期化済み
    stream = await groq_client.chat.completions.create(
        model=groq_model_name,  # フロントエンドから動的に切り替え可能
        messages=[
            {"role": "system", "content": system_prompt},
            {"role": "user", "content": user_prompt},
        ],
        temperature=0.3, max_tokens=500, stream=True,
    )

    full_response = ""
    async for chunk in stream:
        if chunk.choices[0].delta.content:
            full_response += chunk.choices[0].delta.content
            await self._process_streaming_chunk(full_response, text, ...)

    await self._finalize_response(full_response, text, is_final, start_time, f"Groq/{groq_model_name}")

モデル切り替え（WebSocket経由）

フロントエンドからのメッセージでプロバイダーとモデルを動的に切り替えます。

# プロバイダー切り替え
elif msg_type == "set_model":
    model = message.get("model", "gpt4")  # "gpt4" | "gemini" | "groq"
    manager.set_model(model)

# Groq内のモデル切り替え
elif msg_type == "set_groq_model":
    groq_model_name = message.get("groq_model", "llama-3.3-70b-versatile")

共通する設計ポイント

全プロバイダーに共通する設計は以下の通りです。

プロンプト切り替え: is_finalフラグにより、SPEEDプロンプトとQUALITYプロンプトを使い分けます。
コンテキスト履歴: 直近3件の発話をユーザープロンプトに含めることで、LLMに会話の文脈を与え、より一貫した翻訳を実現します。
ストリーミングチャンク処理: LLMからの各チャンクはfull_responseに追加され、_process_streaming_chunkが即座に呼ばれて部分的な結果を抽出・送信します。
計測ログ: 各プロバイダーの_call_*メソッドはstart_timeから経過時間を計測し、First Chunk到着時間・翻訳検出時間・完了時間をログに記録します。後述のベンチマーク表はこのログから算出しています。

ストリーミングJSON抽出

_process_streaming_chunkメソッドは、生成途中のJSONをパースし、利用可能になった部分結果をWebSocket経由でフロントエンドに送信します。

async def _process_streaming_chunk(self, full_response: str, text: str,
                                    sent_intent: bool, sent_translation: bool):
    """Parse in-progress JSON and send partial results via WebSocket"""
    if not sent_intent and '"intent_label"' in full_response:
        match = re.search(r'"intent_label"\s*:\s*"([^"]+)"', full_response)
        if match:
            await self.websocket.send_json({
                "type": "intent_partial",
                "intent_label": match.group(1),
                "source_text": text,
            })

    if not sent_translation and '"full_translation"' in full_response:
        match = re.search(r'"full_translation"\s*:\s*"([^"]+)"', full_response)
        if match:
            await self.websocket.send_json({
                "type": "translation_partial",
                "translation": match.group(1),
                "source_text": text,
            })

正規表現を使い、不完全なJSONからフィールドの値を抽出しています。あるフィールドの値が完成した時点（閉じ引用符が検出された時点）で、即座にフロントエンドへ送信します。JSON全体が妥当になるのを待つ必要はなく、個々のフィールドがパース可能であれば十分です。

これが段階的表示を実現している仕組みです。intent_labelが最初に届き、full_translationがそれに続きます。それぞれ生成された瞬間に送信されます。

デバウンス・短文スキップ・重複チェック

Deepgramは非常に高速にPartial結果を返します。対策なしでは毎秒数十回のLLM呼び出しが発生しかねません。estimate()メソッドに3つのフィルタリング機構を実装し、これを制御しています。

async def estimate(self, text: str, is_final: bool):
    """Estimate intent from text (with rate limiting)"""
    if not text.strip():
        return
    if text == self.last_text:    # Duplicate check
        return

    self.last_text = text
    current_time = time.time() * 1000
    word_count = len(text.split())

    if is_final:
        # Final results always get processed immediately
        self.context_history.append(text)
        if len(self.context_history) > 5:
            self.context_history.pop(0)
        await self._call_llm_streaming(text, is_final)
        return

    # Skip short partials (e.g., "I" or "I think")
    if word_count < self.min_words:
        return

    time_since_last = current_time - self.last_call_time

    # Cancel any pending debounced call
    if self.pending_task and not self.pending_task.done():
        self.pending_task.cancel()

    # Debounce: wait 300ms before calling LLM
    if time_since_last < self.debounce_ms:
        wait_time = (self.debounce_ms - time_since_last) / 1000
        self.pending_task = asyncio.create_task(
            self._delayed_call(text, is_final, wait_time)
        )
    else:
        await self._call_llm_streaming(text, is_final)

3つのフィルタリング機構は以下の通りです。

重複チェック: 前回と同一のテキストが来た場合はスキップします。DeepgramがPartial結果を複数回送信することがあるため、冗長な処理を防ぎます。
短文スキップ: 5単語未満のPartial（例: “I” や “I think”）は翻訳に十分な情報を含まないためスキップします。有意な情報を損なうことなく、不要なLLM呼び出しを削減できます。
デバウンス（300ms）: 前回の呼び出しから300ms以内に新しいテキストが届いた場合、保留中のLLMリクエストをキャンセルしてタイマーをリセットします。中間状態を逐一送るのではなく、最新版のテキストのみをLLMに送ります。

重要な点として、is_finalの結果は3つのフィルタをすべてバイパスします。話者が発話を終えた場合は品質重視の翻訳をすぐに取得する必要があるため、遅延やスキップの理由がありません。

フロントエンド：WebSocketメッセージハンドラ

フロントエンド（React）側では、handleMessageコールバックが3種類のWebSocketメッセージを処理し、UI状態を段階的に更新します。

const handleMessage = useCallback((message: WebSocketMessage) => {
  switch (message.type) {
    case 'intent_partial': {
      // Display intent label immediately
      setPartialIntentLabel(message.intent_label);
      // Update timeline: add or replace the latest partial entry
      setTimeline((prev) => {
        const lastPartialIndex = prev.findLastIndex((e) => !e.isFinal);
        if (lastPartialIndex !== -1) {
          const newList = [...prev];
          newList[lastPartialIndex] = {
            ...newList[lastPartialIndex],
            intentLabel: message.intent_label,
          };
          return newList;
        }
        return [...prev, {
          id: Date.now(),
          intentLabel: message.intent_label,
          dialogueAct: 'OTHER',
          translation: null,
          isFinal: false,
          timestamp: new Date(),
        }];
      });
      break;
    }
    case 'translation_partial': {
      // Update the latest partial translation
      setRealtimeTranslations((prev) => {
        const lastPartialIndex = prev.findLastIndex((entry) => !entry.isFinal);
        if (lastPartialIndex !== -1) {
          const newList = [...prev];
          newList[lastPartialIndex] = {
            sourceText: message.source_text,
            translation: message.translation,
            isFinal: false,
          };
          return newList;
        }
        return [...prev, {
          sourceText: message.source_text,
          translation: message.translation,
          isFinal: false,
        }];
      });
      break;
    }
    case 'intent': {
      // Complete result: replace partial with final
      setCurrentIntent(message.data);
      setPartialIntentLabel('');
      // Update timeline with confirmed entry
      setTimeline((prev) => {
        const lastPartialIndex = prev.findLastIndex((e) => !e.isFinal);
        const newEntry = {
          id: Date.now(),
          intentLabel: message.data.intent_label || '',
          dialogueAct: message.data.dialogue_act || 'OTHER',
          translation: message.data.full_translation || null,
          isFinal: message.is_final,
          timestamp: new Date(),
        };
        if (lastPartialIndex !== -1) {
          const newList = [...prev];
          newList[lastPartialIndex] = newEntry;
          return newList;
        }
        return [...prev, newEntry];
      });
      break;
    }
  }
}, []);

表示フローは3段階で構成されています。

intent_partialが最初に到着（約500ms）: 意図ラベルが即座に表示されます。翻訳エリアにはプレースホルダーとして「翻訳中…」が表示されます。
translation_partialが次に到着（約500-800ms）: 翻訳テキストが入り、プレースホルダーを置き換えます。
intent（完全結果）が最後に到着: 部分的なエントリが確定結果で置き換えられます。視覚的なスタイルが変化し、翻訳が確定したことを示します。

各段階は同じタイムラインエントリを更新します（findLastIndexでisFinalがfalseのエントリを探索）。これにより重複が生じず、部分結果が滑らかに最終結果へ遷移します。

フロントエンド：タイムラインUI

タイムラインコンポーネントは、データフローを反映した視覚的な状態で各エントリを描画します。

{/* Real-time translation timeline */}
<div className="bg-white rounded-xl shadow-lg p-6 mb-6">
  <h2 className="text-lg font-semibold text-gray-700">Real-time Translation</h2>
  <div className="max-h-[400px] overflow-y-auto space-y-3">
    {timeline.map((entry, i) => {
      const isLatest = i === timeline.length - 1;
      return (
        <div
          key={entry.id}
          className={`p-3 rounded-lg ${
            isLatest
              ? entry.isFinal
                ? 'bg-green-50 border-l-4 border-green-500'    // Confirmed
                : 'bg-blue-50 border-l-4 border-blue-400'      // In-progress
              : 'bg-gray-50'                                     // Historical
          }`}
        >
          {/* Intent label row */}
          <div className="flex items-center gap-2 mb-1">
            <span className="px-2 py-0.5 rounded text-white text-xs bg-blue-500">
              {entry.dialogueAct}
            </span>
            <span className="text-gray-700 font-medium">{entry.intentLabel}</span>
            {!entry.isFinal && (
              <span className="text-xs text-blue-500 animate-pulse">processing...</span>
            )}
          </div>
          {/* Translation row */}
          {entry.translation ? (
            <p className="text-gray-800 text-lg pl-1">→ {entry.translation}</p>
          ) : (
            <p className="text-gray-400 text-sm pl-1 animate-pulse">→ Translating...</p>
          )}
        </div>
      );
    })}
  </div>
</div>

タイムラインUIは3つの視覚的状態を持ちます。

青い左ボーダー + パルスアニメーション: 処理中（部分結果）。意図ラベルは表示されていますが、翻訳はまだ到着中の場合があります。
緑の左ボーダー: 確定翻訳（最終結果）。エントリは完成し、検証済みです。
グレーの背景: 履歴としてスクロールアップした過去のエントリ。

この段階的表示はデータフローを反映しています。意図が最初に表示され（青いボーダー）、翻訳が埋まり、確定すると緑に変わります。ユーザーは空白の画面が突然すべて埋まるのを待つのではなく、情報がリアルタイムで積み上がっていくのを目にします。

6つのLLMモデルを実際に比較

このシステムでは、フロントエンドのトグルで任意のプロバイダー・モデルに切り替えられます。同じ入力に対して全モデルをテストした結果が以下です。

自社モデル（プロプライエタリ）

プロバイダー	モデル	翻訳表示速度	品質	5時間コスト
Google	Gemini 2.5 Flash Lite	954ms	◎	$1.17（約175円）
OpenAI	GPT-4o-mini	1,976ms	◎	$1.74（約261円）

オープンソースモデル（Groq LPU推論）

Groqは自社でモデルを開発しているわけではなく、Llamaなどのオープンソースモデルを独自開発のLPU（Language Processing Unit）チップで高速に推論するクラウドサービスです。

モデル	翻訳表示速度	品質	5時間コスト
Llama 4 Maverick	413ms	◎	$3.43（約515円）
Llama 3.3 70B	480ms	◎	—
Llama 3.1 8B	377ms	○	—
GPT-OSS 120B	662ms	◎	—

比較から見えること

速度重視: Groq経由のオープンソースモデルが圧倒的に速い（400ms前後）。LPUチップによるハードウェア最適化の効果です。
コスト重視: Gemini 2.5 Flash Liteが5時間で約175円と最も経済的。無料枠もあります。
品質と安定性: OpenAI GPT-4o-miniは速度では劣るものの、翻訳品質が安定しており、APIドキュメントも充実しています。
注意点: Groqは最速ですが、継続利用のコストは最も高い（5時間で約515円）。速度とコストはトレードオフの関係にあります。

システム全体のデータフロー

技術的な全体像を示します。

[ブラウザ]               [バックエンド(FastAPI)]          [外部API]
   |                          |                           |
   |-- 音声バイナリ --------->|                           |
   |                          |-- 音声データ ------------>| Deepgram
   |                          |<-- Partial/Final text ----|
   |                          |                           |
   |                          |-- テキスト -------------->| LLM (Gemini/Groq)
   |                          |<-- ストリーミングJSON ----|
   |                          |                           |
   |<-- intent_partial -------|  （意図ラベルを即送信）     |
   |<-- translation_partial --|  （翻訳を即送信）          |
   |<-- intent (complete) ----|  （完全な結果）            |

重要なのは、LLMの出力を最後まで待ってからまとめて送るのではなく、JSONの各フィールドが生成されるたびに個別のWebSocketメッセージとして即座にフロントエンドへ送信している点です。

この開発で得られた知見

このシステムの開発を通じて最も実感したのは、LLMの出力を「結果」としてではなく「ストリーム」として扱うことの重要性です。

JSONのフィールド順序を最適化し、重要な情報を先に生成させる
生成途中のJSONを部分的にパースして即座に送信する
Partial/Finalの状態に応じてプロンプトを動的に切り替える
入力側で積極的にフィルタリングする — デバウンス、重複排除、短文スキップ
フロントエンドを「一括表示」ではなく「段階的表示」で構築する

いずれも、LLMの「上から順に生成する」という基本的な性質を理解し、それを活かした設計です。これらはリアルタイム翻訳の根本的な課題を解決するものではありません。それにはモデルやハードウェアレベルの進歩が必要です。しかし、現在利用可能なツールの範囲で何ができるかを示す実践的な知見だと考えています。

次回は、ローカルLLMでの推論検証、このシステムを他の言語ペアに適用するためのガイド、そしてこのアプローチの可能性と限界について考察します。