エラー画面のスクリーンショットを貼って原因を尋ねると、AI が画面の文字を読み取って答えを返してくれます。
このように、文字だけでなく画像や音声、動画まで入力として扱える性質が、マルチモーダル（multimodal）と呼ばれるものです。
便利な反面、画像を渡したときに AI の中で何が起きているのか、気になったことはありませんか？
仕組みが分かると、画像がなぜトークンを消費するのか、なぜ細かい数字を読み違えるのかが見えてきます。
マルチモーダルは「情報の種類」を複数まとめて扱うこと
モダリティ（modality）とは、テキスト・画像・音声・動画といった情報の種類を指す言葉です。
その種類を複数（multi）扱えるから、マルチモーダルというわけです。
ただし、入力のマルチモーダルと出力のマルチモーダルは別の話です。
たとえば Anthropic のVision ドキュメントには、Claude は画像を理解するモデルであり、画像の生成や編集はできないと書かれています。
つまり、入力では画像を受け付けても、出力は文字だけです。
一方、2023年に公開されたGemini の技術報告は、テキスト・画像・音声・動画が混ざった入力を受け取り、文字と画像を織り交ぜて出力できるモデルとして Gemini を紹介していました。
「マルチモーダル対応」と書かれていたら、どの種類を入力でき、どの種類を出力できるのかを分けて確かめておくと安心です。
画像を「言葉と同じ並び」に変えて読ませる仕組み
では、文章を読むために作られた言語モデルが、どうやって画像を読むのでしょうか。
言語モデルが扱うのは、文章を細かく刻んだトークンの並びです。
基本の考え方は、画像も小さな単位の並びに変えて、文章と同じ列に並べることです。
流れを 3 つの段階に分けると、次のようになります。
画像を小さな正方形に切り分ける
最初の段階は、画像をパッチと呼ばれる小さな正方形に切り分けることです。
2020年に発表された Vision Transformer（ViT）の論文は、大量のデータで事前学習すれば、画像をパッチの並びとして、いまの言語モデルの土台になっている Transformer に読ませる方式でも、画像分類で高い性能が出ることを示しました。
言葉と同じ「数値の空間」にそろえる
切り分けたパッチは、そのままでは言語モデルが読める形になっていません。
よく使われるのは、画像を数値に変換する画像用のエンコーダーで各パッチをベクトルに変え、言葉を表す数値ベクトルである埋め込みと同じ次元にそろえるやり方です。
公開研究の LLaVA では、CLIP という画像エンコーダーの出力をシンプルな線形層 1 つで言語モデルの単語埋め込みの空間へ写し、「視覚トークン」の並びとして扱っていました。
埋め込みの考え方そのものは、こちらで詳しく扱っています。
文章と同じ列に並べて読む
3 つ目は、ベクトルにした画像を文章のトークンと同じ列に並べ、まとめて読ませる段階です。
先ほどの Gemini の技術報告にも、テキスト・画像・音声・動画を交互に混ぜた並びをそのまま入力にできると書かれています。
動画は、フレームの連続として並べて読む仕組みです。
音声は文字に書き起こさず、専用のモデルが作った特徴量のまま取り込むことで、書き起こしで失われがちなニュアンスも捉えられるとされています。
商用モデルの内部の作りは、細部まで公開されているわけではありません。
それでも各社の公式ドキュメントを読むと、画像の数え方にはこの「切って並べる」発想がはっきり残っています。
使いどころは「言葉にしにくい情報」を渡す場面
マルチモーダルが効くのは、言葉で説明し直すと手間がかかる情報をそのまま渡せる場面です。
エラーが出た画面のキャプチャ、設計図やグラフ、請求書や申込書のような帳票の読み取りが代表例です。
音声も同じで、Gemini API の音声理解のドキュメントには、書き起こしや翻訳に加えて、話者の聞き分けやサイレンのような言葉以外の音の理解まで挙げられていました。
渡し方にも、覚えておくと得をするコツがひとつあります。
Anthropic のドキュメントは、画像を先に置き、質問の文章を後に置く構成のほうが Claude はうまく働くと説明しています。
複数の画像を送るときは「Image 1:」「Image 2:」のような短い見出しを付けておくと、後の質問で画像を名前で指せるとも書かれていました。
例えば、以下のようなイメージで画像と文字を 1 つの配列に並べて送ります。
# Anthropic Messages API の content の例（画像を先、質問を後に並べる）
content = [
{"type": "text", "text": "Image 1:"},
{"type": "image",
"source": {"type": "base64", "media_type": "image/png", "data": before_b64}},
{"type": "text", "text": "Image 2:"},
{"type": "image",
"source": {"type": "base64", "media_type": "image/png", "data": after_b64}},
{"type": "text", "text": "2 枚の画面の違いと、エラーの原因として考えられるものを挙げてください。"},
]
# messages=[{"role": "user", "content": content}] として送る（略）画像と文章が同じ「列」に入っていることが、コードの形からも読み取れます。
落とし穴は「トークンの消費」と「細部の読み違い」
便利さの裏で、押さえておきたい落とし穴が 2 つあります。
画像もトークンを消費する
1 つ目は、画像も文章と同じくトークンとして数えられ、料金と上限に効いてくることです。
2026年9月時点の Anthropic のドキュメントでは、28×28 ピクセルの区画 1 つを視覚トークン 1 つと数え、幅と高さをそれぞれ 28 で割って切り上げた値を掛ける式が示されています。
式に当てはめると、1000×1000 ピクセルの画像は 1,296 トークンになる計算です。
import math
def visual_tokens(width, height, patch=28):
# ceil(幅/28) × ceil(高さ/28)
# 上限を超える画像は先に縮小されるので、その場合は縮小後の寸法で数える
return math.ceil(width / patch) * math.ceil(height / patch)
print(visual_tokens(1000, 1000)) # 1296
print(visual_tokens(200, 200)) # 64上限を超える画像は先に縮小されるため、実際の値はこれより小さくなることもあります。
特に高解像度に対応したモデルでは、標準の解像度のモデルと比べて、同じ画像でも最大でおよそ 3 倍の視覚トークンを使うことがあると注意書きがありました。
細部の読み取りが要らない用途なら、送る前に縮小しておくとよいでしょう。
OpenAI の Images and vision ガイドでも、一部のモデルは画像を 32×32 ピクセルの区画で覆って数えると説明されており、画像のトークンは 1 分あたりのトークン数の制限（TPM）にも含まれると書かれています。
トークンが料金と上限の単位になる仕組みそのものは、こちらの記事で整理しています。
音声も例外ではなく、同じく2026年9月時点の Gemini API のドキュメントでは 1 秒あたり 32 トークン（1 分で 1,920 トークン）と数えられています。
細かい文字や数値を読み違える
2 つ目は、小さな文字や数値、回転した画像の読み違いです。
Anthropic のドキュメントは、画質の低い画像や回転した画像、200 ピクセル未満のとても小さな画像では誤った解釈をすることがあると明記しています。
物の数え上げはおおよその数にとどまり、位置の指定も近似にすぎないそうです。
OpenAI のガイドには、日本語や韓国語のようなラテン文字以外の文字を含む画像では、性能が最適にならない場合があるとも書かれていました。
動画についても、Gemini API の動画理解のドキュメントは、既定の「1 秒に 1 フレーム」の読み取りでは動きの速い場面や素早い切り替えを見落とすことがあると注意しています。
帳票の金額や型番のように、1 文字の読み違いが結果を変える用途では、人が確かめる前提で組み込むべきでしょう。
最後に
マルチモーダルは、画像や音声を小さな単位の並びに変え、文章と同じ列に並べて読ませる仕組みでした。
だからこそ、言葉にしにくい画面や図表をそのまま渡せるという強みが生まれます。
一方で、画像もトークンを消費し、細かい文字や数値の読み違いも起こり得ます。
入力と出力でどの種類を扱えるのかを確かめ、読み取りの確認まで含めて使い方を組み立てるのがよいと考えています。
以上です。
コメントを残す