Home 論文解説: Gemini 1.5 — 1000万トークンコンテキストで実現するマルチモーダル長文脈理解
投稿
キャンセル

📄 論文解説: Gemini 1.5 — 1000万トークンコンテキストで実現するマルチモーダル長文脈理解

投稿日 23/02/2026
投稿者 0h-n0
21 分読了時間

本記事は Gemini 1.5: Unlocking multimodal understanding across millions of tokens of context (arXiv:2403.05530) の解説記事です。

論文概要（Abstract）

Gemini 1.5 は Google DeepMind が2024年3月に発表したマルチモーダルモデルファミリーで、最大1000万トークンのコンテキストウィンドウを持つ。MoE（Mixture-of-Experts）アーキテクチャを採用し、Gemini 1.0 Ultra と同等以上の性能を、より少ない計算コストで達成したと著者らは報告している。1時間の動画、11時間の音声、100万行のコードを単一のコンテキストに収めて処理できる点が最大の技術的特徴である。

この記事は Zenn記事: Gemini 3.1 Pro マルチモーダルAPI実践ガイド：画像・音声・動画をPythonで統合処理する の深掘りです。

情報源

  • arXiv ID: 2403.05530
  • URL: https://arxiv.org/abs/2403.05530
  • 著者: Gemini Team, Google DeepMind（Machel Reid, Nikolay Savinov, Denis Teplyashin et al.）
  • 発表年: 2024
  • 分野: cs.CL, cs.AI, cs.LG

背景と動機（Background & Motivation）

Gemini 1.0（arXiv:2312.11805）はネイティブマルチモーダル設計で広範なベンチマーク性能を示したが、コンテキスト長は32Kトークンに制限されていた。この制約は以下の実用上の問題を引き起こす。

  • 長尺動画の分割処理: 30分以上の動画を処理する場合、複数回のAPI呼び出しに分割する必要があり、動画全体の文脈を一貫して理解できない
  • 大規模コードベースの解析: リポジトリ全体を1コンテキストに収められないため、ファイル間の依存関係を完全に把握できない
  • 長時間音声の文字起こし: 会議録音など数時間の音声をチャンク単位で処理すると、文脈の断絶が生じる

これらの課題に対し、著者らはコンテキスト長を32Kから1000万トークンに拡張するアーキテクチャを開発した。単純にコンテキストを伸ばすだけでなく、長文脈での性能劣化を防ぐための複数の技術的工夫が導入されている。

主要な貢献（Key Contributions）

  • 10Mトークンコンテキスト: 既存モデルの約300倍のコンテキスト長を実現。1時間の動画、11時間の音声、70万語のテキスト、100万行のコードを1パスで処理可能
  • MoE による効率化: Gemini 1.0 Ultra 相当の性能を、学習・推論ともに低いコストで達成
  • Needle-in-a-Haystack での高精度: 10Mトークン中から埋め込まれた情報を99%以上の精度で検索可能（論文 Figure 3 より）
  • In-context learning の飛躍: 1-shot で未知の言語（カラムネート語）を学習し翻訳するデモを実施

技術的詳細（Technical Details）

コンテキスト長拡張のアーキテクチャ

長文脈 Transformer の最大の課題は、Self-Attention の計算量がシーケンス長の2乗に比例する点である。

\[\text{Attention}(Q, K, V) = \text{softmax}\left(\frac{QK^T}{\sqrt{d_k}}\right)V\]

シーケンス長 $n$ に対し、$QK^T$ の計算量は $O(n^2 \cdot d_k)$ である。$n = 10^7$（10Mトークン）の場合、naive な実装では $10^{14}$ 回の演算が必要になり、現実的でない。

著者らは具体的な長文脈の実現手法について詳細を公開していないが、論文からは以下の要素が読み取れる。

1. MoE による計算効率化

MoE は Attention 層ではなく FFN 層に適用される。エキスパート総数 $E$ のうち、各トークンについて上位 $k$ 個のみを活性化する。

\[\text{FLOPs}_{\text{MoE}} \approx \frac{k}{E} \times \text{FLOPs}_{\text{Dense}}\]

例えば $E = 64$, $k = 2$ の場合、FFN の計算量は Dense モデルの約3%で済む。この削減が長文脈処理を実用的にしている。

2. 段階的コンテキスト長拡張

著者らは、事前学習時のコンテキスト長を段階的に拡張する手法を採用したと報告している。

\[L_{\text{context}} \in \{32K, 128K, 512K, 1M, 10M\}\]

各段階で位置エンコーディングの補間（Position Interpolation）またはNTK-aware スケーリングを行い、既存の学習済みパラメータを活用しつつ、より長いコンテキストに適応させる。

3. 位置エンコーディングの拡張

RoPE（Rotary Position Embedding）ベースの位置エンコーディングを使用していると推測される。RoPE のスケーリングは以下の式で表される。

\[\text{RoPE}(x, m) = x \cdot e^{im\theta / s}\]

ここで、

  • $x$: 入力トークンの隠れ表現
  • $m$: トークンの位置インデックス
  • $\theta$: 基底周波数
  • $s$: スケーリングファクター（コンテキスト長に応じて調整）

スケーリングファクター $s$ を増加させることで、事前学習時のコンテキスト長を超える位置にも対応できる。

マルチモーダルトークナイゼーション

10Mトークンのコンテキストにおける各モダリティのトークン消費量は以下の通りである（論文の記述に基づく推定値）。

モダリティトークン化レート1Mトークンで処理可能な量
テキスト約1トークン/語約70万語（1,000ページ）
画像約560トークン/枚（MEDIUM解像度）約1,786枚
動画約300トークン/秒（1fps）約55分
音声約32トークン/秒約8.7時間

Needle-in-a-Haystack テスト

著者らは、長文脈での情報検索能力を Needle-in-a-Haystack テストで評価している。テスト手順は以下の通り。

  1. 長いテキスト（haystack）の中のランダムな位置に、特定の事実（needle）を埋め込む
  2. モデルにその事実について質問する
  3. 正しく回答できるかを評価する
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

def needle_in_haystack_test(
    model_name: str,
    context_length: int,
    needle: str,
    haystack: str,
    needle_position: float,  # 0.0 (先頭) 〜 1.0 (末尾)
) -> bool:
    """Needle-in-a-Haystackテストの概念的実装

    Args:
        model_name: 使用するモデルID
        context_length: コンテキスト長（トークン数）
        needle: 埋め込む事実（例: "The special number is 42."）
        haystack: 背景テキスト（長文ドキュメント）
        needle_position: needleを埋め込む相対位置

    Returns:
        正しく検索できたかどうか
    """
    # needleをhaystackの指定位置に挿入
    insert_pos = int(len(haystack) * needle_position)
    test_input = haystack[:insert_pos] + needle + haystack[insert_pos:]

    # トークン数がcontext_lengthに収まるようにトランケート
    test_input = truncate_to_tokens(test_input, context_length)

    # モデルに質問
    question = "What is the special number mentioned in the text?"
    response = generate(model_name, test_input + "\n\n" + question)

    return "42" in response

著者らの報告によれば、Gemini 1.5 Pro は1Mトークンの Needle-in-a-Haystack テストで99%以上のリコールを達成した（論文 Figure 3 より）。また、テキストだけでなく、動画フレームや音声セグメントに埋め込まれた情報の検索でも同様の高精度を示したとされている。

In-Context Learning の実証

論文で著者らが示した印象的なデモとして、カラムネート語（Kalamang）の翻訳がある。カラムネート語はパプアニューギニアの少数言語で、話者数が約200人、学習データにはほぼ含まれていない。

著者らは、カラムネート語の文法書（500ページ）をコンテキストに入力し、1-shot（1つの翻訳例のみ）で英語→カラムネート語の翻訳タスクを実行した。結果として、BLEU スコアは人間の翻訳者と同程度の品質を達成したと報告されている。

\[\text{BLEU}_{\text{Gemini 1.5 Pro}} = 18.2 \quad (\text{論文 Table 5 より})\]

これは、10Mトークンのコンテキストに文法書全体を収容し、文法規則・語彙・用例を1パスで「学習」できたことを意味する。

実装のポイント（Implementation）

1. コンテキスト長とコストのトレードオフ: 10Mトークンのコンテキストは技術的に可能だが、APIコストは入力トークン数に比例する。Zenn記事で紹介されている media_resolution パラメータによる解像度調整は、このコスト制御に直結する。

2. 動画のフレームサンプリング: 論文ではデフォルト1fpsのサンプリングが使用されている。Zenn記事の VideoMetadata による区間指定は、不要なフレームのトークン消費を削減する効果的な手法である。

3. ファイルの再利用: Files API でアップロードしたファイルは48時間保持される。同一ファイルへの複数質問では再アップロード不要であり、レイテンシとコストの両面で有利。

4. Long context での “Lost in the middle” 問題: 先行研究（Liu et al., 2024）で報告されている「コンテキスト中間部の情報が見落とされやすい」問題に対し、Gemini 1.5 は Needle-in-a-Haystack テストで位置に依存しない高い検索精度を示している。ただし、実用タスクでの検証は限定的である。

実験結果（Results）

コア性能比較

ベンチマークGemini 1.5 ProGemini 1.0 UltraGPT-4 Turbo
MMLU81.9%83.7%86.5%
HumanEval71.9%74.4%86.6%
MATH58.5%53.2%52.2%
Natural2Code77.7%74.9%73.4%

論文 Table 1 より。Gemini 1.5 Pro は短文脈ベンチマークでは Gemini 1.0 Ultra とほぼ同等の性能を維持しつつ、MoE による計算効率化を達成している。

長文脈評価

テストコンテキスト長Gemini 1.5 Pro他モデル（最良）
Needle-in-a-Haystack (テキスト)1M tokens>99% recallClaude 2.1: ~95% (200K)
Needle-in-a-Haystack (動画)10.5h video>99% recallN/A
1-shot 翻訳（カラムネート語）~500K tokensBLEU 18.2N/A

論文 Figure 3, Table 5 より。長文脈タスクでは比較対象のモデルが存在しないため、絶対性能での評価となる。

マルチモーダル評価

ベンチマークGemini 1.5 ProGemini 1.0 Pro
MMMU58.5%47.9%
EgoSchema (動画QA)72.2%55.7%

論文 Table 3 より。マルチモーダルタスクでは Gemini 1.0 Pro から大幅に改善されている。

注意点: 10Mトークンのコンテキスト長は研究用途での評価であり、公開 API（Gemini 1.5 Pro）のコンテキスト上限は128Kトークン（後に拡張）である。

実運用への応用（Practical Applications）

Zenn記事の Gemini 3.1 Pro API は、この Gemini 1.5 の長文脈技術を継承・発展させたものである。

1. 動画要約パイプライン: Zenn記事の summarize_video 関数は、Files API 経由で動画をアップロードし Gemini に処理させる。Gemini 1.5 の長文脈能力により、分割せずに動画全体を一括処理できる。

2. コードリポジトリ分析: 100万行のコードを1コンテキストに収められるため、リポジトリ全体のアーキテクチャ分析やセキュリティ監査が1パスで実行可能になった。

3. 長時間会議の分析: 11時間分の音声を32トークン/秒で処理すると約127万トークンとなり、1Mトークンのコンテキストに収まる。話者識別・議事録生成・アクションアイテム抽出を統合的に実行できる。

4. コスト最適化: Zenn記事で紹介されている4段階のコスト削減戦略（モデル使い分け、media_resolution 調整、動画クリッピング、ファイル再利用）は、長文脈処理のコスト増大に対する実践的な対策である。

関連研究（Related Work）

  • Gemini 1.0 (Google DeepMind, 2023, arXiv:2312.11805): Gemini 1.5 の前身。ネイティブマルチモーダル設計を確立したが、コンテキスト長は32Kに制限されていた。
  • Claude 2.1 (Anthropic, 2023): 200Kトークンのコンテキスト長を持つテキストモデル。マルチモーダルではないが、長文脈処理の先駆的な事例。
  • LongRoPE (Ding et al., 2024, arXiv:2402.13753): RoPE の拡張により2Mトークンまでのコンテキスト長を実現する手法。Gemini 1.5 の位置エンコーディング拡張に関連する技術。
  • Ring Attention (Liu et al., 2023, arXiv:2310.01889): Attention 計算をデバイス間で分散させることで、メモリ制約を超える長文脈処理を実現する手法。

まとめと今後の展望

Gemini 1.5 は、マルチモーダル AI における長文脈処理の実用性を示した論文である。10Mトークンのコンテキストウィンドウは、動画・音声・テキスト・コードの大規模データを分割せずに一括処理することを可能にした。

Zenn記事で解説されている Gemini 3.1 Pro の API 体系（Files API、media_resolution、thinking_level）は、この長文脈技術の上に構築されたものであり、コスト効率と性能のバランスを取るための制御パラメータと位置づけられる。

今後の課題としては、10Mトークンを実用的に使用する際のコスト低減（現状では入力トークン数に比例）、”Lost in the middle” 問題のさらなる改善、および長文脈での推論精度の安定化が挙げられる。

参考文献

blog paper arxiv
gemini multimodal long-context moe transformer google
この投稿は CC BY 4.0 でライセンスされています。
最近の更新
目次