「テキストしか扱えないエージェント」はもう古い。Claude 3.5 / 3.7、GPT-4o、Gemini 2.5 はいずれも、画像・音声・テキストを同一モデルで処理できるネイティブマルチモーダルへ進化した。だが、APIの構文・対応モダリティ・コスト・レイテンシは三社で大きく違い、「全部 GPT-4o で済ませる」「全部 Claude で組む」という単純な選び方では本番運用に耐えない。
本記事では、Anthropic・OpenAI・Google の公式ドキュメントだけを一次ソースに、マルチモーダル AI エージェントを実装するためのAPI構造・統合パターン・本番運用の落とし穴を 1 万 4,000 字超で整理する。読み終わる頃には、「どのモダリティをどのモデルで処理し、どこで切り分けるか」を判断できるはずだ。
結論:2026年5月時点での”勝ち筋構成”
細かい話に入る前に、ベンチマーク・API仕様・コスト構造をすべて見たうえでの結論を先に出す。
- テキスト + 画像の同時処理:Claude 3.7 Sonnet または GPT-4o。画像トークンの計算式が公開されており、コスト試算しやすい。
- 音声入出力(リアルタイム会話):OpenAI Realtime API(GPT-4o Realtime)が一強。音声 → 音声を 1 モデルで完結できる。
- 長尺音声・動画の理解:Gemini 2.5 Pro。動画ネイティブ対応(1 秒 = 263 トークン)で 100 万トークンコンテキスト。
- 非リアルタイムの音声入力:Whisper(whisper-1)でテキスト化 → 任意のテキストモデルへ。汎用性とコストでこれが鉄板。
- 画像生成連携:GPT-image-1(API)または DALL·E 3。エージェントの「ツール呼び出し」として扱うのが現実解。
1 モデルで全部やろうとせず、モダリティごとに最適モデルを束ねる “オーケストレーション型” エージェントが本番では強い。本記事はその設計図を描く。
1. マルチモーダルAIエージェントとは何が新しいのか
1-1. 「ファイル添付に答える」だけでは足りない
「マルチモーダル AI」というと、ChatGPT に画像を貼って質問する、あの体験を思い浮かべる人が多い。ただしエージェントとして組み込むときの要求は段違いだ。エージェントは、ユーザーから受け取った入力モダリティを判別し、必要に応じて別ツール(音声認識、画像分析、画像生成、外部 API)を呼び出し、最終的にテキスト・音声・画像のいずれか(または複合)で応答する。
つまり、マルチモーダルエージェントには以下の 4 つの能力が必要になる。
- 入力モダリティ判定:受け取った入力が画像か音声かテキストかを判別する
- モダリティ別前処理:画像なら resize/format、音声なら ASR(音声認識)
- 統合推論:複数モダリティを 1 つのコンテキストとして扱い、推論する
- 出力モダリティ選択:回答をテキストで返すか、音声合成するか、画像を生成するか決める
従来「LangChain + Whisper + GPT-4 + DALL·E」のように複数 SDK を直列で繋いでいた処理が、Claude / GPT-4o / Gemini の登場で「1 モデル + Tool Use」に集約できるようになった、というのが 2025〜2026 年の構造変化だ。
1-2. ネイティブマルチモーダル vs パイプライン型
マルチモーダル実装には大きく 2 つのアーキテクチャがある。
| 方式 | 構造 | 強み | 弱み |
|---|---|---|---|
| ネイティブマルチモーダル | 画像・音声・テキストを単一モデルが直接処理 | 低レイテンシ、ニュアンス保持 | モデル固定、コスト高 |
| パイプライン型 | ASR → LLM → TTS など分割 | 各段を最適化可、コスト調整 | レイテンシ累積、情報欠落 |
GPT-4o Realtime API はネイティブ型の代表で、「音声で問いかけて音声で答える」を 1 リクエストで完結できる。一方、Whisper + Claude + ElevenLabs のように分割すれば各段で最良のモデルを選べる代わりに、音声 → テキスト → 音声と変換するたびにイントネーションや笑い声などの情報が失われる。
本番では「カスタマーサポートのリアルタイム電話応対」のように低レイテンシが命のユースケースはネイティブ型、「動画から議事録を生成」のように非リアルタイムで品質最優先のユースケースはパイプライン型、という棲み分けが現時点での実務的な結論である。
2. モデル別:マルチモーダル対応状況の一次情報
ここから各社の公式仕様に基づいて整理する。仕様は頻繁に更新されるため、本記事は2026 年 5 月時点の各社 docs.公式ページを基準とする。
2-1. Anthropic Claude のビジョン機能
Claude 3.5 Sonnet 以降のモデルは画像入力に対応している。Anthropic の Vision ドキュメント(docs.anthropic.com)によれば、サポート形式は JPEG / PNG / GIF / WebP、最大画像サイズは 5MB、1 リクエスト内で最大 20 画像を同時に渡せる(Messages API)。バッチ API では最大 100 画像。
画像トークンの算出式は公式で公開されており、おおまかには「画像の縦 × 横 / 750」で計算できる。1092 × 1092 px の画像なら約 1,590 トークン。
音声入力にはネイティブ対応していない(2026 年 5 月時点)。Claude で音声を扱うなら Whisper や Google Speech-to-Text でテキスト化してから渡すパイプライン構成が前提となる。
# Anthropic Python SDK での画像入力例
from anthropic import Anthropic
import base64
client = Anthropic()
with open("chart.png", "rb") as f:
image_data = base64.standard_b64encode(f.read()).decode("utf-8")
message = client.messages.create(
model="claude-3-7-sonnet-20250219",
max_tokens=1024,
messages=[{
"role": "user",
"content": [
{"type": "image", "source": {"type": "base64", "media_type": "image/png", "data": image_data}},
{"type": "text", "text": "このグラフから読み取れる主要なインサイトを3つ挙げて"}
]
}]
)
print(message.content[0].text)
Claude の強みは、画像と長文テキストを同一コンテキストに混ぜたときの「読解の正確さ」だ。たとえば PDF を画像化して 20 枚渡し、内容についての構造化抽出を依頼するようなユースケースで安定する。
2-2. OpenAI GPT-4o / GPT-4o Realtime
OpenAI の Vision Guide(platform.openai.com)によれば、GPT-4o は画像理解にネイティブ対応し、URL 渡し・Base64 渡しの両方が可能。画像トークンは「detail パラメータ」で粗解像度/高解像度を切り替える設計で、low detail なら 85 トークン固定、high detail なら 170 トークン × タイル数 + 85 で計算される。
音声面が GPT-4o の真骨頂で、Realtime API(platform.openai.com)は WebSocket または WebRTC で「音声入力 → 音声出力」を 1 モデルで完結できる。マイクからの音声ストリームを直接モデルに流し込み、合成音声で返答が返ってくる。レイテンシは数百ミリ秒オーダーで、対人会話に十分耐える。
# OpenAI Realtime API への接続(Python・WebSocket)
import asyncio, json, websockets, os
async def chat():
url = "wss://api.openai.com/v1/realtime?model=gpt-4o-realtime-preview"
headers = {"Authorization": f"Bearer {os.environ['OPENAI_API_KEY']}",
"OpenAI-Beta": "realtime=v1"}
async with websockets.connect(url, additional_headers=headers) as ws:
await ws.send(json.dumps({
"type": "response.create",
"response": {"modalities": ["audio", "text"],
"instructions": "日本語で簡潔に答えて"}
}))
async for msg in ws:
event = json.loads(msg)
if event.get("type") == "response.audio.delta":
# 16-bit PCM 24kHz が delta で連続して飛んでくる
handle_audio_chunk(event["delta"])
asyncio.run(chat())
従来の Whisper(whisper-1)エンドポイントも引き続き提供されており、非リアルタイムなら$0.006 / 分と圧倒的に安く済む(Speech to text)。バッチ的に「録音済み音声を後追いでテキスト化する」ユースケースは依然として Whisper が最適解だ。
2-2-b. Whisper の音声認識仕様もう少し詳しく
マルチモーダルエージェントを設計するうえで、Whisper の挙動は外せない。OpenAI 公式ドキュメント(Speech to text)で示されている主要パラメータを整理する。
- model:
whisper-1(オープンソース版の large-v2 相当)。後続のgpt-4o-transcribeシリーズも段階的にリリースされている。 - language:ISO 639-1 で言語指定(
"ja"など)。未指定だと自動判定だが、日本語ファイルを英語と誤認するケースがあるので明示推奨。 - response_format:
json/text/srt/verbose_json/vtt。動画字幕生成なら srt / vtt を直接吐かせると後処理が省ける。 - temperature:0.0 が決定論的。書き起こし用途では 0 を推奨。
- prompt:固有名詞や専門用語を事前にコンテキストに入れられる。社内用語や人名は必ず入れる。
# Whisper の prompt で固有名詞を補強する例
with open("interview.mp3", "rb") as f:
transcript = openai_client.audio.transcriptions.create(
model="whisper-1",
file=f,
language="ja",
prompt="株式会社Uravation、Claude Code、AIエージェント、佐藤傑、本日のテーマはマルチモーダル統合です。",
response_format="verbose_json",
temperature=0
)
# verbose_json なら segments[].start / .end (秒)が取れるので、
# 動画字幕や音声ハイライト機能を作る時に便利
Whisper は短い音声で“hallucination”(無音や雑音から「ご視聴ありがとうございました」「字幕作成」などの定番フレーズを捏造する)を起こすことが知られている。1 秒以下のサンプルや無音区間が長いファイルでは、no_speech_prob と avg_logprob を見て足切りするのが定石だ。
2-3. Google Gemini 2.5 のマルチモーダル
Google の Gemini API ドキュメント(ai.google.dev)によれば、Gemini 2.5 Pro / Flash は画像・音声・動画・PDF をネイティブで入力可能。100 万トークンの長大コンテキストを活かして「2 時間の会議動画をそのまま投入」が物理的に可能になっている。
トークン換算は以下が公式で示されている。
- 画像:1 枚あたり最大 258 トークン(384 × 384px ベース、それ以上はタイル分割)
- 音声:1 秒あたり 32 トークン
- 動画:1 秒あたり 263 トークン(映像 + 音声)
動画 1 分が約 15,780 トークンになる計算なので、1 時間動画なら 95 万トークン。100 万トークンコンテキストにかろうじて 1 時間ぶん収まる。「議事録ではなく動画そのものを RAG のソースにする」ような設計が、Gemini なら正面突破で可能になる。
2-4. 画像生成 API:DALL·E 3 と GPT-image-1
マルチモーダルエージェントの出力側で画像生成を組み込むときに使うのが、OpenAI の画像生成系 API だ。Images Guide で示されているとおり、2026 年 5 月時点では 2 系統が並走している。
- DALL·E 3:
dall-e-3。HD 品質、1024 × 1024 で約 $0.04 / 枚。テキストプロンプトのみ。 - GPT-image-1:後継のマルチモーダル画像モデル。テキスト + 参照画像入力、書き込みやテキスト合成に強い。
エージェントから呼び出すなら、Tool Use の引数としてpromptとsizeを渡す薄いラッパーを書き、戻り値の URL を Markdown 画像として最終応答に組み込む構成が最もシンプルだ。注意点は、生成画像は一定時間で OpenAI 側 URL から消えること。本番ではすぐに S3 などに転送するパイプラインを必ず仕込んでおく。
3. 統合パターン4種:本番設計の選択肢
3 社の API 仕様を踏まえ、本番でよく採用される統合パターンを 4 つに分類して整理する。
3-1. パターン1:オールインワン型(GPT-4o or Gemini)
1 モデルだけで画像・音声・テキストすべてを処理する最もシンプルな構成。GPT-4o は音声で、Gemini 2.5 Pro は動画で特に強い。プロトタイプや単機能アプリには最速。
長所:実装行数が極小、保守が楽。レイテンシも最短。
短所:モデル固有のクセに引きずられる。価格も他モデルへの逃げ場がない。
3-2. パターン2:Whisper + テキストモデル(分離型)
音声を Whisper でテキスト化し、Claude や GPT-4 にテキストとして渡す古典的構成。コストとモデル選択の自由度で優れる。
とくに Claude を主軸にするチームは、音声をテキストに変換してから Claude へ流すこの構成が事実上の標準だ。Whisper は 100+ 言語に対応していて精度も高く、$0.006/分でほぼ無視できる金額。
# Whisper でテキスト化 → Claude に渡す
from openai import OpenAI
from anthropic import Anthropic
openai = OpenAI()
anthropic = Anthropic()
with open("meeting.mp3", "rb") as f:
transcript = openai.audio.transcriptions.create(
model="whisper-1", file=f, language="ja"
)
reply = anthropic.messages.create(
model="claude-3-7-sonnet-20250219",
max_tokens=2048,
messages=[{
"role": "user",
"content": f"以下は会議の文字起こし。意思決定事項を箇条書きで:n{transcript.text}"
}]
)
print(reply.content[0].text)
3-3. パターン3:Tool Use 経由のモダリティ分離
テキストモデルを「司令塔」として中央に置き、画像生成・音声合成・画像分析をすべてツール(Function Calling)として登録する。エージェントが自律的に「いまは画像が必要だ」「いまは音声で返したい」と判断してツールを呼び出す構成。
マルチエージェント開発が増える 2026 年現在、もっとも本番運用に強いパターンだ。OpenAI Agents SDK や Anthropic 公式の Claude Agent SDK は、こうしたツール統合を前提に作られている。
# Claude にツールとして画像生成を持たせる例
tools = [{
"name": "generate_image",
"description": "DALL·E 3 で画像を生成する。図やイラストが必要な時に使う。",
"input_schema": {
"type": "object",
"properties": {
"prompt": {"type": "string", "description": "英語の詳細プロンプト"},
"size": {"type": "string", "enum": ["1024x1024", "1792x1024", "1024x1792"]}
},
"required": ["prompt"]
}
}]
resp = client.messages.create(
model="claude-3-7-sonnet-20250219",
max_tokens=1024,
tools=tools,
messages=[{"role": "user", "content": "猫が宇宙服を着てる絵を作って"}]
)
# resp.stop_reason == "tool_use" なら、tool_use ブロックを取り出して DALL·E を実行
3-4. パターン4:マルチモーダルRAG
RAG(Retrieval Augmented Generation)もマルチモーダル化が進んでいる。テキストの埋め込みだけでなく、画像埋め込み・音声埋め込みもベクトルストアに格納して検索する構成だ。
OpenAI の text-embedding-3-large はテキスト専用だが、Cohere の Embed v3 や Vertex AI の Multimodal Embeddings は画像とテキストを同じベクトル空間に埋め込める。これにより「テキストクエリで関連画像を検索」「画像をアップして関連ドキュメントを検索」が同じ仕組みで実装できる。
マルチモーダル RAG については Agentic RAG の 4 パターン比較ガイドでテキスト RAG のパターン整理を行っているので、まずそちらでクエリ書き換え・自己評価ループの基本を押さえてから、画像/音声に拡張する流れが消化しやすい。
4. 実装:ファイル添付 → 分析 → 回答の統合フロー
もっとも頻度の高いユースケース「ユーザーが画像/音声/PDF を添付 → エージェントが解釈して回答」を、Pattern 3(Tool Use 経由)で組んでみる。
# Claude を司令塔にしたマルチモーダルエージェント(簡略版)
from anthropic import Anthropic
from openai import OpenAI
import base64, mimetypes
claude = Anthropic()
openai_client = OpenAI()
def transcribe(path: str) -> str:
with open(path, "rb") as f:
return openai_client.audio.transcriptions.create(
model="whisper-1", file=f
).text
def handle_upload(user_text: str, file_path: str | None) -> str:
content = [{"type": "text", "text": user_text}]
if file_path:
mime, _ = mimetypes.guess_type(file_path)
if mime and mime.startswith("image/"):
data = base64.standard_b64encode(open(file_path, "rb").read()).decode()
content.insert(0, {
"type": "image",
"source": {"type": "base64", "media_type": mime, "data": data}
})
elif mime and mime.startswith("audio/"):
text = transcribe(file_path)
content.insert(0, {"type": "text", "text": f"[音声書き起こし]n{text}"})
elif mime == "application/pdf":
# Claude は PDF も直接渡せる(2024-11 以降)
data = base64.standard_b64encode(open(file_path, "rb").read()).decode()
content.insert(0, {
"type": "document",
"source": {"type": "base64", "media_type": "application/pdf", "data": data}
})
resp = claude.messages.create(
model="claude-3-7-sonnet-20250219",
max_tokens=2048,
messages=[{"role": "user", "content": content}]
)
return resp.content[0].text
ポイントは次の 3 つだ。
- 画像と PDF は Claude のネイティブ機能を使う:base64 で渡すだけで OCR や図表理解まで一気通貫
- 音声は Whisper でテキスト化:Claude に音声を直接渡せないので前段で変換
- 判定ロジックは MIME タイプベース:LLM に判定させず決定論的に分岐
この設計だと「Claude にネイティブ対応がない部分」だけを別 API で補えばよく、Claude のメイン能力(言語推論、長文整理)はそのまま使える。設計の見通しが立ちやすく、ベンダーロックも限定的だ。
5. コストとレイテンシ:本番運用での現実
マルチモーダルは「動かす」までは簡単でも、「月数百万円規模で運用する」段階でコストとレイテンシが一気に問題化する。各モダリティの実費を見てみよう。
5-1. 画像入力のコスト
各社の公式価格表(Anthropic、OpenAI、Google)から、1024 × 1024 px の画像 1 枚を入力した場合のコスト概算を比較する(2026 年 5 月時点)。
| モデル | 画像トークン数(概算) | 入力単価 | 1 枚あたりコスト |
|---|---|---|---|
| Claude 3.7 Sonnet | 約 1,500 | $3 / 1M tokens | 約 $0.0045 |
| GPT-4o (high detail) | 約 1,105 | $2.50 / 1M tokens | 約 $0.003 |
| Gemini 2.5 Pro | 約 258 | $1.25 / 1M tokens (≤200K) | 約 $0.0003 |
画像 1 枚なら数円のオーダーだが、「画像 20 枚を毎リクエスト同梱」が日常になるエージェントだと、月数百万円規模で効いてくる。Gemini のトークン効率が画像では圧倒的で、画像が大量に流れる業務(OCR・帳票処理・カタログ解析)では Gemini 採用が経済的に正しい場合が多い。
5-2. 音声処理のコスト
| 用途 | API | コスト |
|---|---|---|
| 音声 → テキスト(非リアルタイム) | Whisper(whisper-1) | $0.006 / 分 |
| テキスト → 音声 | OpenAI TTS(tts-1) | $15 / 1M chars |
| 音声 → 音声(リアルタイム) | GPT-4o Realtime 音声入出力 | 入力 $40/1M tokens、出力 $80/1M tokens (2026-05時点公式表) |
Realtime API は便利だが、音声入出力は「1 秒 ≒ 約 50 トークン」程度になるため、1 分の会話で入出力合わせて 5,000〜6,000 トークン消費する。1 分の通話あたり数十円かかる計算で、Whisper + GPT-4o テキストの分離構成($0.006 + わずかなテキスト料金)に比べて 5〜10 倍高い。低レイテンシが本当に必要かを設計段階で問い直したい。
5-3. レイテンシ設計
レイテンシの観点では、モダリティごとに以下のオーダー感を覚えておくと設計判断が早くなる。
- テキストのみ:約 0.5〜3 秒(モデル/トークン数/ストリーミング有無で変動)
- 画像 + テキスト:約 2〜8 秒(画像エンコード時間が支配的)
- Whisper(1 分音声):約 3〜10 秒
- GPT-4o Realtime:数百ミリ秒〜1 秒(WebSocket / WebRTC、TTFB)
- 動画(Gemini、1 分):約 10〜30 秒
ユーザー対話のリアルタイム性が必要なら Realtime API、バックエンドの非同期処理なら Whisper パイプライン、と「リアルタイム要件の有無」を最初に切り分けるのが王道だ。
6. 本番運用での落とし穴 5 つ
1 年マルチモーダルエージェントを運用していて、「これは設計時に気付きにくい」と感じたハマりポイントを 5 つ挙げる。
6-1. 画像は「縮小しないと高くつく」
スマホで撮影した写真は 4032 × 3024 px などザラ。これをそのまま GPT-4o の high detail に投げると、1 枚で数千トークン消費する。1024px 程度に縮小してから送るだけで、コストが 1/4 になることも珍しくない。Pillow(画像のリサイズ用)などで前処理を挟む。
6-2. 音声ファイルは「Whisper の 25MB 上限」に当たる
Whisper API は 1 ファイル最大 25MB。MP3 で約 30 分、WAV だと数分で上限。長尺は ffmpeg で分割するか、音声ビットレートを下げる必要がある。会議録音をそのまま投げてエラーになるのは初心者の定番。
6-3. Realtime API の WebRTC 切断問題
本番でリアルタイム音声会話を運用すると、ネットワーク瞬断によるセッション断が頻発する。再接続ロジック、会話履歴の永続化、途中の音声バッファ再送、いずれも自分で実装する必要がある。OpenAI 公式 docs はサンプルコードだけで、本番ハンドリングは利用者側責任だ。
6-4. マルチモーダル RAG での「画像説明テキストとの併用」
画像をそのまま埋め込みで検索すると、似た色味の画像ばかり引いてしまうことが多い。実務では「画像 → GPT-4o などで詳細キャプションを生成 → そのテキストも埋め込む」のハイブリッド埋め込みが安定する。検索クエリも同じく、テキストとキャプション両方とマッチさせる二段検索が有効。
6-5. モデル切替時の “プロンプト互換性問題”
GPT-4o で動いていたマルチモーダルプロンプトを Claude に移植すると、画像の指示が読み取れない・JSON 出力が崩れる、といった小さな差が必ず出る。本番運用するなら、Claude Agent SDK の自律エージェント実装で扱われているような評価データセット(画像入りの eval set)を最初に組み、モデル切替時のリグレッションテストを習慣化したい。
7. 用途別:結局どの構成を選ぶか
ここまで API・コスト・落とし穴を見てきたうえで、典型的な 5 ユースケースの推奨構成をまとめる。
| ユースケース | 推奨構成 | 理由 |
|---|---|---|
| カスタマーサポート音声 Bot | GPT-4o Realtime 単体 | 低レイテンシ最優先、対人感を保つ必要 |
| 会議録音 → 議事録 | Whisper + Claude 3.7 Sonnet | コスト最小、長文整理は Claude が強い |
| 請求書 OCR + 仕分け | Gemini 2.5 Pro(画像 + テキスト) | 画像トークンが安く、大量バッチに耐える |
| 動画コンテンツ解析 | Gemini 2.5 Pro 単体 | 動画ネイティブ対応、長尺コンテキスト |
| マルチモーダル社内ナレッジ検索 | Vertex Multimodal Embedding + Claude | 画像 + テキスト統合検索 + 長文要約 |
大事なのは「全部 1 モデルで」とは考えず、モダリティの組み合わせと利用頻度を 1 枚の表に書き出し、月間コストとレイテンシ目標から逆算することだ。
8. 評価とモニタリング:マルチモーダル版の作り方
テキスト LLM の評価は OpenAI Evals や DeepEval などのフレームワークが揃ってきたが、マルチモーダルになると評価設計が一気に複雑化する。
- 画像理解:「特定オブジェクトの有無」「数値読み取り」など正解が決定論的な eval セットを 50〜100 件用意する
- 音声認識:WER(Word Error Rate)を計測。Whisper は日本語の固有名詞で誤りやすいので、ドメイン特化 eval を持つ
- 音声合成:人手評価が中心。本番では「ユーザーが途中で切ったか」「再生時間」を proxy にする
- マルチモーダル RAG:画像クエリ → 取得チャンクの recall@k、テキストクエリ → 画像 recall@k を別軸で測定
「全モダリティを 1 つのスコアで評価しよう」は破綻する。モダリティごとに目標値を切り分けて運用するのが正しい。
9. セキュリティとガバナンス
マルチモーダル運用では、テキストにはない 3 つのリスクが新規に発生する。
- 画像内の機密情報漏洩:スクショに個人情報が映っていないか、エージェントがそのまま外部 API に送る前のサニタイズが必要
- 音声データの保存期間:OpenAI Realtime は会話ログが OpenAI 側にも残る(オプトアウトが必要)。Anthropic/Google も同様にトレーニング利用の有無を契約条件で確認
- プロンプトインジェクション(画像版):画像内のテキスト(“ignore previous instructions and …”)が GPT-4o / Claude に拾われる事例が報告されている。重要な指示はシステムプロンプト側で多層化しておく
とくに業務システムに組み込むなら、各社の Zero Data Retention や Enterprise プランを必ず確認してから本番投入したい。
9-2. 補足:各社のデータ保持・トレーニング利用ポリシー
API 利用時のデータ取り扱いは各社で異なる。本番運用に組み込む前に、必ず公式ドキュメントで最新条項を確認してほしい(2026 年 5 月時点の概況のみ示す)。
- Anthropic:API 経由で送ったデータは Anthropic のトレーニングに使われない(Commercial Terms)。エンタープライズ契約では Zero Data Retention(ZDR)も選べる。
- OpenAI:API 経由のデータは既定でモデル訓練に使われない(API data usage policies)。30 日でログ自動削除、ZDR は要相談。
- Google:Gemini API 経由データは Google の生成 AI モデル訓練に使われない(Gemini API Terms)。Vertex AI を経由するエンタープライズ設定では明示的に制御可能。
とくに音声・画像は「文字情報よりセンシティブ度が高い」というクライアント認知が一般的だ。社内承認を取りに行く資料には、各社の該当ポリシー URL を直接引用してリンクしておくと話が早い。
9-3. オープンソースモデルでマルチモーダルを組む選択肢
API 依存を減らしたい場合、オープンウェイトのマルチモーダルモデルも 2025 年から急速に増えた。代表的な選択肢を簡単に整理する。
| モデル | 得意モダリティ | 備考 |
|---|---|---|
| Llama 3.2 Vision | テキスト + 画像 | Meta 公開。11B/90B、Hugging Face で動かせる |
| Qwen2-VL | テキスト + 画像 + 動画 | Alibaba 公開。動画フレームを直接入力できる |
| Whisper(オープンウェイト) | 音声 → テキスト | OpenAI のオリジナル Whisper モデルは MIT ライセンス |
| Pixtral 12B | テキスト + 画像 | Mistral 公開、Apache 2.0 ライセンス |
API 製品ほど品質は出ないが、「業務データを外部 API に出せない」「コストを GPU 償却に振り替えたい」というユースケースでは選択肢になる。Hugging Face Transformers と vLLM の組み合わせで、開発機での PoC は半日もあれば構築できる。
9-4. アーキテクチャ図:オーケストレーション型エージェントの全体像
本記事の Pattern 3 + Pattern 4 を組み合わせた「実際に本番で動かしているレベル」の構成を、テキストで描いておく。
┌────────────────────────────────────────────────┐
│ ユーザー入力(任意モダリティ) │
│ テキスト / 画像 / 音声ファイル / 動画 / PDF │
└─────────────────────────┬──────────────────────┘
│
▼
┌────────────────────────────────────────────────┐
│ 入力ルーター(MIMEタイプ判定 + 前処理) │
│ - 画像: Pillow で 1024px 縮小 + base64 encode │
│ - 音声: Whisper API でテキスト化 │
│ - PDF: Claude ネイティブ document type で渡す │
│ - 動画: Gemini 2.5 Pro 直接入力 or フレーム抽出 │
└─────────────────────────┬──────────────────────┘
│
▼
┌────────────────────────────────────────────────┐
│ 司令塔 LLM(Claude 3.7 Sonnet) │
│ ・統合コンテキストで推論 │
│ ・必要に応じて Tool Use で外部呼び出し │
│ └─ search_kb (社内ナレッジRAG) │
│ └─ generate_image (DALL·E 3 / GPT-image-1) │
│ └─ synthesize_speech (OpenAI TTS) │
│ └─ run_sql (BigQuery / Snowflake) │
└─────────────────────────┬──────────────────────┘
│
▼
┌────────────────────────────────────────────────┐
│ 出力レンダラー(モダリティ選択) │
│ テキスト / 画像 URL / 音声ストリーム / Markdown │
└────────────────────────────────────────────────┘
司令塔を 1 つに固定するメリットは、会話履歴・ユーザー状態・ツール使用ログが一元化されること。LangGraph や OpenAI Agents SDK、Claude Agent SDK のいずれを使う場合でも、この骨組みは共通している。
10. まとめ:2026 年のマルチモーダル設計指針
本記事の要点を 7 つに圧縮する。
- マルチモーダルは「1 モデルで全部」ではなく、モダリティ別最適モデルを束ねるオーケストレーションが本番では強い
- テキスト + 画像は Claude 3.7 Sonnet / GPT-4o、低レイテンシ音声は GPT-4o Realtime、長尺動画は Gemini 2.5 Pro が現時点での最適
- 非リアルタイムなら Whisper パイプラインが圧倒的に安い($0.006/分)
- Tool Use 経由のモダリティ分離(Pattern 3)が、保守性と柔軟性のバランスでベスト
- 画像はリサイズしないと高くつく。1024px ベースで縮小してから送る
- コスト試算は各社公式トークン換算式から逆算し、月間コストを 1 枚の表に
- 評価はモダリティごとに分離。1 つのスコアで全部測ろうとしない
マルチモーダルは「ChatGPT に画像を貼って便利!」のレベルから、「業務システムの中核」へと役割を変えつつある。実装するなら今が一番おもしろい時期だ。
この記事を読んで導入イメージが固まってきた方へ
Uravationではマルチモーダル AI エージェント実装の研修・コンサル・PoC 支援を行っています。社内データを使った請求書 OCR 自動化、会議録音 → 議事録ワークフロー、リアルタイム音声 Bot 構築まで一気通貫でサポート可能です。
関連記事
- Agentic RAG 完全比較:4 パターン実装ガイド 2026 — テキスト RAG の最新設計を整理。マルチモーダル化の土台に。
- OpenAI Agents SDK TS/Python 完全比較ガイド 2026 — Tool Use 経由でモダリティを分離するときの SDK 選び。
- Claude Agent SDK Python 自律エージェント実装ガイド 2026 — Claude を司令塔にした統合構成の参考実装。
