論文解説: Gemini 1.5 — Sparse MoEで100万トークンコンテキストのマルチモーダル理解を実現

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

論文概要（Abstract）

Google DeepMindが2024年3月に発表したGemini 1.5 Proは、Sparse Mixture-of-Experts（MoE）アーキテクチャを採用した計算効率の高いマルチモーダルモデルである。著者らによると、最大100万トークンのコンテキストウィンドウにより、複数の長文ドキュメント、1時間の動画、11時間の音声を単一プロンプトで処理できる。Needle-in-a-Haystack タスクでは100万トークンのコンテキストにおいて99%超の精度を達成したと報告されている。

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

情報源

arXiv ID: 2403.05530
URL: https://arxiv.org/abs/2403.05530
著者: Machel Reid, Nikolay Savinov, Denis Teplyashin et al. (Google DeepMind)
発表年: 2024
分野: cs.CL, cs.AI, cs.CV

背景と動機（Background & Motivation）

Gemini 1.0（arXiv:2312.11805）はマルチモーダル処理において高い性能を示したが、コンテキスト長が32Kトークンに制限されていた。これは長時間の動画や大量のドキュメントを一括処理する用途では不十分である。著者らは、この制約を解消するため、以下の2つの技術的課題に取り組んだと述べている。

第1に、コンテキスト長のスケーリング。100万トークンのコンテキストを実用的なレイテンシで処理するためには、注意機構の計算量を制御する必要がある。標準的なSelf-Attentionの計算量は $O(n^2 \cdot d)$ であり、$n$ が100万に達すると現実的でない。

第2に、計算効率。モデルパラメータ数が増大しても、推論時の計算コストを抑制する必要がある。Gemini 1.0 Ultraを上回る性能を、より少ない学習コンピュートで達成することが目標とされた。

主要な貢献（Key Contributions）

貢献1: Sparse MoEアーキテクチャにより、大規模パラメータモデルでありながら推論時の活性化パラメータ数を制限し、計算効率を実現
貢献2: 100万トークンのコンテキストウィンドウを実用化。論文のNeedle-in-a-Haystack実験では99%超の情報検索精度を達成
貢献3: Gemini 1.0 Ultraを上回る性能を、より少ない学習コンピュートで達成。効率/性能のパレートフロンティアを更新

技術的詳細（Technical Details）

Sparse Mixture-of-Experts（MoE）アーキテクチャ

Gemini 1.5 Proの核心はSparse MoEアーキテクチャである。標準的なTransformerでは各層のFFN（Feed-Forward Network）が全パラメータを使用するが、MoEでは複数の「エキスパート」FFNを用意し、入力トークンごとに一部のエキスパートのみを活性化する。

MoEレイヤの計算は以下のように定式化できる：

\[\text{MoE}(\mathbf{x}) = \sum_{i=1}^{N} g_i(\mathbf{x}) \cdot E_i(\mathbf{x})\]

ここで、

$\mathbf{x}$: 入力トークンの隠れ表現
$N$: エキスパートの総数
$E_i$: $i$番目のエキスパートネットワーク（FFN）
$g_i(\mathbf{x})$: ゲーティング関数の出力（エキスパート$i$の選択重み）

Sparseゲーティングでは、Top-$k$のエキスパートのみが活性化される：

\[g_i(\mathbf{x}) = \begin{cases} \text{softmax}(\mathbf{W}_g \mathbf{x})_i & \text{if } i \in \text{Top-}k(\mathbf{W}_g \mathbf{x}) \\ 0 & \text{otherwise} \end{cases}\]

ここで $\mathbf{W}_g$ はゲーティングネットワークの重み行列、$k$ は活性化するエキスパート数（典型的には $k=2$）である。

この設計により、モデルの総パラメータ数は大きいが、推論時に活性化されるパラメータは $k/N$ の比率に抑制される。例えば $N=16, k=2$ の場合、各トークンの処理に使用されるパラメータは全体の12.5%である。

ロングコンテキスト処理

100万トークンのコンテキストを処理するための技術的詳細について、論文では明示的なアーキテクチャ変更（Ring Attention等の分散アテンション手法）の記述は限定的だが、以下の特徴が報告されている：

効率的なアテンション機構: Gemini 1.0から引き継いだ効率的なアテンション（具体的な手法名は非公開）により、100万トークン長のシーケンスを処理可能
コンテキスト長の段階的拡張: 学習中にコンテキスト長を段階的に増加させるカリキュラム学習が使用されている
位置埋め込みの拡張: RoPE（Rotary Position Embedding）の拡張により、学習時より長いコンテキストへの汎化が可能

マルチモーダルトークンの容量

100万トークンのコンテキストウィンドウは、各モダリティで以下の容量に相当する（論文Section 1より）：

モダリティ	容量	トークン換算
テキスト	~700,000語	1,000,000トークン
動画	~1時間	~1,080,000トークン（300トークン/秒）
音声	~11時間	~1,267,200トークン（32トークン/秒）
コード	~30,000行	~1,000,000トークン
画像	~3,800枚	~996,000トークン（258トークン/枚）

アルゴリズム：ロングコンテキスト推論

  
import torch
import torch.nn as nn
from typing import Optional

class SparseMoELayer(nn.Module):
    """Gemini 1.5のSparse MoEレイヤの簡易実装

    Args:
        d_model: モデルの隠れ次元数
        n_experts: エキスパートの総数
        top_k: 活性化するエキスパート数
        d_ff: FFNの中間次元数
    """
    def __init__(
        self,
        d_model: int,
        n_experts: int = 16,
        top_k: int = 2,
        d_ff: int = 4096,
    ):
        super().__init__()
        self.n_experts = n_experts
        self.top_k = top_k

        # ゲーティングネットワーク
        self.gate = nn.Linear(d_model, n_experts, bias=False)

        # エキスパートFFN
        self.experts = nn.ModuleList([
            nn.Sequential(
                nn.Linear(d_model, d_ff),
                nn.GELU(),
                nn.Linear(d_ff, d_model),
            )
            for _ in range(n_experts)
        ])

    def forward(self, x: torch.Tensor) -> torch.Tensor:
        """Sparse MoE順伝播

        Args:
            x: 入力テンソル (batch_size, seq_len, d_model)

        Returns:
            出力テンソル (batch_size, seq_len, d_model)
        """
        batch_size, seq_len, d_model = x.shape

        # ゲーティングスコア計算
        gate_logits = self.gate(x)  # (B, S, N)

        # Top-kエキスパート選択
        top_k_logits, top_k_indices = torch.topk(
            gate_logits, self.top_k, dim=-1
        )  # (B, S, k)
        top_k_weights = torch.softmax(top_k_logits, dim=-1)

        # 選択されたエキスパートの出力を加重和
        output = torch.zeros_like(x)
        for i in range(self.top_k):
            expert_idx = top_k_indices[:, :, i]  # (B, S)
            weight = top_k_weights[:, :, i].unsqueeze(-1)  # (B, S, 1)

            for j in range(self.n_experts):
                mask = (expert_idx == j)
                if mask.any():
                    expert_input = x[mask]
                    expert_output = self.experts[j](expert_input)
                    output[mask] += weight[mask] * expert_output

        return output

実装のポイント（Implementation）

MoEアーキテクチャの実装では、以下の点が重要である：

負荷分散: エキスパートへの入力が偏ると、一部のエキスパートに計算が集中する。論文ではauxiliary loss（補助損失）を使用して負荷分散を促進していると推測される
ロングコンテキストのメモリ管理: 100万トークンのKVキャッシュはGBオーダーのメモリを消費する。実用上はKVキャッシュの圧縮やページング手法が必要
バッチ処理の効率化: MoEでは各トークンが異なるエキスパートに送られるため、バッチ処理の効率が低下する。TPU/GPU上ではAll-to-All通信パターンが使用される

Gemini API利用時の実装パターン:

  
from google import genai
from google.genai import types

def analyze_long_video(
    video_path: str,
    questions: list[str],
) -> list[str]:
    """長時間動画を1回のAPI呼び出しで分析する

    Gemini 1.5の100万トークンコンテキストにより、
    1時間の動画を単一プロンプトで処理可能。

    Args:
        video_path: 動画ファイルパス
        questions: 動画に関する質問リスト

    Returns:
        各質問への回答リスト
    """
    client = genai.Client()

    # Files APIで動画をアップロード
    video_file = client.files.upload(file=video_path)

    # 複数の質問を1回のリクエストで処理
    prompt = "以下の質問それぞれに回答してください:\n"
    for i, q in enumerate(questions, 1):
        prompt += f"{i}. {q}\n"

    response = client.models.generate_content(
        model="gemini-2.5-flash",
        contents=[video_file, prompt],
    )
    return response.text

実験結果（Results）

著者らは以下のベンチマーク結果を報告している（論文Table 1, 2, 3より）。

一般的なベンチマーク

ベンチマーク	Gemini 1.0 Ultra	Gemini 1.5 Pro	比較
MMLU (5-shot)	90.04%	81.9%	Ultra優位
MMMU (val)	59.4%	58.5%	ほぼ同等
EgoSchema (video QA)	53.0%	75.0%	+22%

ロングコンテキスト性能

タスク	コンテキスト長	精度
Needle-in-a-Haystack	100Kトークン	99.7%
Needle-in-a-Haystack	500Kトークン	99.3%
Needle-in-a-Haystack	1Mトークン	99.2%

音声・動画理解

タスク	説明	性能
CoVoST 2	音声翻訳	67.5%
Long-context ASR	長時間音声認識	4/5タスクで最高精度
Audio understanding	音声理解	10/11タスクで最高精度
Video understanding	動画理解	10/11タスクで最高精度

著者らは、Gemini 1.5 ProがGemini 1.0 Ultraをロングコンテキストタスクで大幅に上回りながら、より少ない学習コンピュートで実現されたことを強調している。ただし、短いコンテキストでのMMLU等では1.0 Ultraに劣る結果も報告されている。

実運用への応用（Practical Applications）

Zenn記事で解説されているGemini APIの動画処理・音声処理パターンは、Gemini 1.5で導入されたロングコンテキスト能力に基づいている。

実運用での活用パターン:

長時間動画の一括分析: 会議の録画（1時間）を単一リクエストで要約・議事録生成
音声+動画の同時処理: 動画中の音声情報とビジュアル情報を統合的に理解
大規模ドキュメント+画像の横断検索: 数百ページのPDF群とその中の図表を同時に分析

コスト・レイテンシの考慮:

100万トークンの入力処理には数十秒〜数分のレイテンシが発生する
Gemini 2.0 Flash（後継モデル）では入力$0.10/Mトークンだが、100万トークン入力で$0.10のAPI費用が発生
長時間動画処理では、必要な区間のみをクリッピングすることでコストとレイテンシを削減可能

Production Deployment Guide

AWS実装パターン（コスト最適化重視）

ロングコンテキストの動画・音声分析をAWSバックエンドで運用するパターンを以下に示す。

トラフィック量別の推奨構成:

規模	月間リクエスト	推奨構成	月額コスト	主要サービス
Small	~3,000	Serverless	$100-250	Lambda + Gemini API + S3
Medium	~30,000	Hybrid	$500-1,500	ECS Fargate + S3 + SQS
Large	300,000+	Container	$3,000-8,000	EKS + S3 + SQS + ElastiCache

ロングコンテキスト処理特有の考慮事項:

Lambda実行時間上限（15分）に注意。1時間動画の処理はGemini API側で数分かかるため、Step Functionsとの組み合わせを推奨
動画ファイルはS3に保存し、署名付きURLまたはFiles API経由でGeminiに送信
非同期処理パターン（SQS + Lambda/ECS）でレイテンシを吸収

コスト試算の注意事項:

上記は2026年2月時点のGemini API料金とAWS ap-northeast-1リージョン料金に基づく概算値です
ロングコンテキスト処理ではトークン消費量が通常の10-100倍になるため、Gemini API費用が支配的になる
最新料金は AWS料金計算ツールで確認してください

Terraformインフラコード

非同期動画処理構成: SQS + Lambda + S3

  
# --- S3バケット（動画・結果保存） ---
resource "aws_s3_bucket" "video_store" {
  bucket = "gemini-video-analysis-store"
}

resource "aws_s3_bucket_lifecycle_configuration" "video_lifecycle" {
  bucket = aws_s3_bucket.video_store.id

  rule {
    id     = "expire-processed-videos"
    status = "Enabled"
    expiration { days = 30 }
    filter { prefix = "processed/" }
  }
}

# --- SQSキュー（非同期処理） ---
resource "aws_sqs_queue" "video_analysis" {
  name                       = "gemini-video-analysis"
  visibility_timeout_seconds = 900  # 15分（Lambda最大実行時間）
  message_retention_seconds  = 86400
}

# --- Lambda関数（Gemini API呼び出し） ---
resource "aws_lambda_function" "video_analyzer" {
  filename      = "lambda.zip"
  function_name = "gemini-video-analyzer"
  role          = aws_iam_role.lambda_role.arn
  handler       = "index.handler"
  runtime       = "python3.12"
  timeout       = 900  # 15分
  memory_size   = 2048

  environment {
    variables = {
      GEMINI_MODEL_ID = "gemini-2.5-flash"
      S3_BUCKET       = aws_s3_bucket.video_store.id
      RESULT_PREFIX   = "results/"
    }
  }
}

# --- SQSトリガー ---
resource "aws_lambda_event_source_mapping" "sqs_trigger" {
  event_source_arn = aws_sqs_queue.video_analysis.arn
  function_name    = aws_lambda_function.video_analyzer.arn
  batch_size       = 1  # 動画処理は1件ずつ
}

運用・監視設定

  
import boto3

cloudwatch = boto3.client('cloudwatch')

# 動画処理レイテンシ監視
cloudwatch.put_metric_alarm(
    AlarmName='gemini-video-processing-timeout',
    ComparisonOperator='GreaterThanThreshold',
    EvaluationPeriods=1,
    MetricName='Duration',
    Namespace='AWS/Lambda',
    Period=300,
    Statistic='Maximum',
    Threshold=840000,  # 14分（15分タイムアウトの93%）
    AlarmDescription='動画処理がタイムアウトに近い'
)

コスト最適化チェックリスト

動画入力: media_resolution=LOW でトークン消費を1/3に削減
動画クリッピング: start_offset/end_offset で必要区間のみ処理
結果キャッシュ: 同一動画への重複リクエストを排除（S3 + DynamoDB）
非同期処理: SQSキューで負荷分散、ピーク時のAPI制限を回避
モデル選択: 簡易タスクはFlash、高精度タスクのみPro
AWS Budgets: 月額予算設定（80%で警告）

まとめと今後の展望

Gemini 1.5 Proは、Sparse MoEアーキテクチャと100万トークンコンテキストウィンドウの組み合わせにより、マルチモーダルAIにおける「長文脈理解」の実用性を実証した。

Zenn記事で解説されているGemini API利用パターン（動画1時間の一括処理、音声文字起こし等）は、この論文で確立された技術基盤に基づいている。後継のGemini 2.0/2.5ではコンテキストウィンドウが200万トークンに拡張され、動画処理性能もVideoMMEで85.2%に向上している。

参考文献

arXiv: https://arxiv.org/abs/2403.05530
Related Zenn article: https://zenn.dev/0h_n0/articles/3d32da8cfe0ac1
Gemini 1.0 paper: https://arxiv.org/abs/2312.11805

📄 論文解説: Gemini 1.5 — Sparse MoEで100万トークンコンテキストのマルチモーダル理解を実現

論文概要（Abstract）

情報源

背景と動機（Background & Motivation）

主要な貢献（Key Contributions）

技術的詳細（Technical Details）

Sparse Mixture-of-Experts（MoE）アーキテクチャ

ロングコンテキスト処理

マルチモーダルトークンの容量

アルゴリズム：ロングコンテキスト推論

実装のポイント（Implementation）

実験結果（Results）

一般的なベンチマーク

ロングコンテキスト性能

音声・動画理解

実運用への応用（Practical Applications）

Production Deployment Guide

AWS実装パターン（コスト最適化重視）

Terraformインフラコード

運用・監視設定

コスト最適化チェックリスト

関連研究（Related Work）

まとめと今後の展望

参考文献

📄 論文解説: Gemini 1.5 — Sparse MoEで100万トークンコンテキストのマルチモーダル理解を実現

論文概要（Abstract）

情報源

背景と動機（Background & Motivation）

主要な貢献（Key Contributions）

技術的詳細（Technical Details）

Sparse Mixture-of-Experts（MoE）アーキテクチャ

ロングコンテキスト処理

マルチモーダルトークンの容量

アルゴリズム：ロングコンテキスト推論

実装のポイント（Implementation）

実験結果（Results）

一般的なベンチマーク

ロングコンテキスト性能

音声・動画理解

実運用への応用（Practical Applications）

Production Deployment Guide

AWS実装パターン（コスト最適化重視）

Terraformインフラコード

運用・監視設定

コスト最適化チェックリスト

関連研究（Related Work）

まとめと今後の展望

参考文献

関連記事

📄 論文解説: Gemini — ネイティブマルチモーダルモデルの設計と画像・音声・動画統合処理

📄 論文解説: Qwen2-VL — 任意解像度の画像・動画を動的トークン化するVision-Language Model

📄 論文解説: MIO — 音声・テキスト・画像・動画を統一トークンで理解・生成する基盤モデル