03. Geminiの仕組み

Geminiを使っていると、不思議に思う場面がいくつも出てきます。同じ質問なのに毎回答えが違う。もっともらしい嘘の出典を出す。文字数の数え上げを間違える。どれもバグではなく、内部の仕組みから素直に説明できる性質です。

4つの鍵を順に見ていきます。難しい数式は使いません。

シリーズ目次 ／ 前章: 02. Geminiモデルファミリーの読み方 ／ 次章: 04. Geminiが「考える」仕組みと長いコンテキスト

Table of contents

この章のねらい

• 文章が生成される流れを、トークンと次トークン予測という言葉で説明できるようになる
• Mixture of Experts（専門家の混合）という設計が、なぜ大きなモデルを速く動かせるのかを理解する
• 最初からマルチモーダルであることの意味と利点を説明できるようになる
• 出力のばらつきや誤りが、仕組みから生じる必然だと分かる

鍵1　トークン：言葉を扱う最小単位

モデルは文字や単語をそのまま扱っていません。文章をトークン（token） という小さな断片に割ってから処理します。トークンは単語より細かいこともあれば、複数文字をまとめたものになることもあります。

たとえば「今日の天気は」という文は、内部でこういう断片の並びになります（割り方はモデルによって違います）。

["今日", "の", "天気", "は"]

英語ではおおむね「1トークン ≒ 4文字程度」、日本語では1文字が1トークン以上になることが多く、同じ内容でも日本語のほうがトークン数が多くなりがちです。

このトークンという単位が、後に出てくる料金計算や、一度に扱える情報量の上限（コンテキストウィンドウ）の基準になります。

同じ文を人間とモデルがどう数えるか、並べて比べてみます。

鍵2: 次のトークンを予測し続ける

大規模言語モデルの中核の動作は単純です。これまでの文章を受け取り、次に来るトークンの確率を計算し、その中から1つ選ぶ。これを終了条件に達するまで繰り返します。

「今日はいい」まで与えられたとき、モデルは次のような確率を出します。

常にいちばん確率の高い候補を選ぶと、毎回まったく同じ答えになり、文章も単調になります。そこで実際には、確率に従ってある程度ランダムに選びます。同じ質問でも毎回少しずつ答えが違うのは、このランダム性のせいです。

このばらつき具合を調整する値を温度（temperature）と呼びます。Geminiアプリの画面では普通いじりませんが、開発者向けAPIでは指定できます（第12章）。

モデルがやっているのは、正しい答えを検索することではなく、もっともらしい続きを作ることです。この性質が、後で出てくるハルシネーション（もっともらしい誤り）の根にあります。

鍵3　Mixture of Experts

Gemini 1.5以降のモデルは、Mixture of Experts（MoE、専門家の混合） という設計を採用しています。Gemini 3系では「スパースMoE」と説明されています。スパース（sparse）とは「まばら」という意味です。

考え方はこうです。モデルの内部を、多数の小さな専門家ブロックに分けておく。そして入力トークンごとに、振り分け役（ルーター）が担当する専門家を数個だけ選び、残りは動かしません。

大きな病院にたとえると分かりやすい。内科も外科も眼科も、専門医はたくさんいますが、患者ひとりに全員が対応するわけではありません。受付が症状を見て、必要な科へ回す。全体としては大規模でも、1人あたりの処理は軽く済みます。

この設計の利点は次のとおりです。

大きいのに速い。一見矛盾したこの特性は、この仕組みから来ています。

鍵4: 最初からマルチモーダル

多くのAIサービスは、もともと文章専用に作られたモデルへ、後から画像認識などを継ぎ足して機能を広げてきました。Geminiは設計の当初から、文章と画像と音声と動画を同じ入力として扱う方針です。これをネイティブマルチモーダルと呼びます。

画像も音声も動画も、いったんトークンの並びに変換されてしまえば、モデルにとっては文章と同じただの並びです。だから、こういう芸当ができます。

• 動画を見せて「3分22秒のあたりで何が起きているか」を説明させる
• 手書きのメモを撮影して、内容を表に整理させる
• 図表を含むPDFを読ませて、図の意味を踏まえた要約を作らせる

後付けで機能を足した構成だと、画像を説明文へ変換してから本体へ渡す二段構えになりがちで、その過程で細かい情報が落ちます。最初から同じ土俵に載せておくほうが、取りこぼしが少ない。

実際の使い方は第7章で扱います。

なお、入力を理解できることと、その形式を生成できることは別です。画像・動画・音声の生成は、対応する専用のモデル系統や機能が担当します。

知識はどこにあるのか

事前学習で得られる知識は、辞書のように整理して格納されているわけではありません。パラメータ（モデル内部の膨大な数値の集まり。重みとも呼ばれます）に、統計的な傾向として溶け込んでいます。だから、うろ覚えのところが滑らかに埋まってしまう。

学習に使われたデータには時期の区切りもあります。これを知識カットオフと呼び、それ以降の出来事は原則として知りません。最新情報が要るなら、Web検索機能と組み合わせてください。Geminiアプリは多くの場面で自動的に検索しますが、検索したかどうかは出典表示の有無で確認するのが確実です。

知識のありかと、知識が届く範囲を1枚にまとめます。

仕組みから説明できるよくある現象

4つの仕組みと現象の対応を、線で結んで整理します。

これは設計上の性質です。直るのを待つのではなく、使う側が前提として織り込んでください。詳しい対処法は第13章で扱います。

要点

• モデルは文章をトークンに分割し、次のトークンの確率を計算して1つずつ生成している
• 確率的に選ぶので出力は毎回ゆらぐ。常にもっともらしい続きが作られている
• Mixture of Expertsにより、多数の専門家ブロックのうち一部だけを動かすので、大規模でも速い
• 文章・画像・音声・動画を最初から同じトークン列として扱う設計になっている
• 知識はパラメータに統計的に溶けており、知識カットオフ以降の出来事は検索で補う必要がある

参考資料

• Gemini API ドキュメント「Models」 https://ai.google.dev/gemini-api/docs/models — モデル構成と対応モダリティ（基準日: 2026-08-04）
• Gemini API ドキュメント「Long context」 https://ai.google.dev/gemini-api/docs/long-context — トークンと入力量の関係
• Wikipedia（英語版）「Gemini (language model)」 https://en.wikipedia.org/wiki/Gemini_(language_model) — Mixture of Expertsの採用時期と世代ごとの構成

シリーズ目次 ／ 前章: 02. Geminiモデルファミリーの読み方 ／ 次章: 04. Geminiが「考える」仕組みと長いコンテキスト