マルチモーダルAIとは、文章だけでなく画像や音声など複数種類の情報を入力・出力として扱うAIの総称です。ただし、使える形式はサービス全体ではなくモデルやAPIごとに異なります。
画像の内容を尋ねる、録音を文字にする、テキストを音声にするなどが例です。何ができるかは、入力と出力の両方を利用する製品の仕様で確認します。
比較で見るのは対応数だけではありません。必要な入力を理解できるか、必要な出力を生成できるか、ファイルや時間の制約が合うかを分けて確認します。
目次
情報形式をmodalityと呼ぶ
text
image
audio
video
のような情報形式をmodalityと呼びます。複数modalitiesを同じsystemで扱えるものがmultimodal AIです。
画像とテキストを組み合わせる
現在のOpenAI flagship model群はtextとimage inputを扱えるものがあり、画像内のobject、chart、UIなどを見ながらtextで回答できます。
音声は目的に応じて処理経路を選ぶ
音声入力・speech-to-text・speech generation・realtime conversationは専用modelやAPIへ分かれることがあります。multimodalという言葉だけで全機能が一modelに入っているとは限りません。
モデル名ではなく現在の対応表を確認する
製品発表時のモデル紹介は、その後のモデル・APIの現行条件を保証しません。動画を直接受け付けるか、画像フレームや音声を別に渡す必要があるかなど、利用時点のModels・Images・Audioの公式ガイドで確認します。
入力形式から出力形式へ変換する
audio→text、image→text、text→speechのように、異なるmodality間を変換できます。transcriptionやvoice agentはその代表例です。
目的に合う情報形式を選ぶ
UI bugを文章だけで説明するよりscreenshotを渡す、meeting noteだけでなくaudioを使うなど、taskに合ったmodalityを選ぶとcontextを伝えやすくなります。
送信する情報と制約を確認する
画像や音声には背景の個人情報、顔、位置情報、会話などが含まれる場合があります。upload前に不要部分を削除し、file limitやdata policyも確認します。
モデルと接続先の対応表を確認する
service名だけで「画像も音声も全部できる」と判断せず、利用するmodelのinput / output modalitiesとendpointを確認します。
「入力できる」と「出力できる」を分ける
マルチモーダル対応という表示だけでは、利用者が必要な操作をできるか分かりません。モデルが画像を受け取って文章で答えられても、画像を生成できるとは限りません。音声を文字にする機能と、文章から音声を作る機能も別です。さらに、チャット画面、API、Realtime接続など利用する入口によって、選べるモデルや送れる形式が異なる場合があります。
表は横にスクロールできます
| 入力 | 出力 | 仕事の例 | 事前に確かめること |
|---|---|---|---|
| テキスト | テキスト | 質問、要約、分類 | 長さ、書式、根拠の扱い |
| 画像+テキスト | テキスト | 写真や画面の説明、図表の質問 | 解像度、細かい文字、複数画像の扱い |
| 音声 | テキスト | 録音の文字起こし | 対応形式、長さ、話者、雑音 |
| テキスト | 音声 | 読み上げ、音声案内 | 音声の種類、長さ、利用条件 |
| 音声 | 音声 | 音声での対話 | リアルタイム性、割り込み、接続方式 |
| 動画または連続した画像 | テキスト等 | 動きの説明、場面の確認 | 直接対応か、フレーム・音声への変換が必要か |
この表は一般的な仕事の整理です。全てのモデルが全ての組み合わせを受け付けるわけではありません。動画ファイルを送れること、動画内の音声を理解できること、連続する動きを評価できることも別の能力です。利用する入口の現行ドキュメントで、モデル名、入力形式、出力形式、制限を一つずつ確認してください。
タスクから必要な情報形式を決める
情報を増やすほど回答が良くなるわけではありません。文章で伝えにくい状態を画像で示す、会話の間や発話を確認するために録音を使うなど、回答に必要な証拠を選びます。逆に、テキストで十分な質問へ無関係な写真や長時間の録音を添えると、処理時間・費用・個人情報の扱いが増えます。
画面の不具合を報告する場合、文章だけでは見えない配置や表示状態を画像で示すと、状況を伝えやすくなります。ただし、画像を読めるモデルでも小さな文字、色の差、画面外の状態を見落とすことがあります。画像から原因を断定させるのではなく、再現手順、期待した結果、実際の結果を文章で添え、回答に含まれる推測と観察を分けます。
会議録音なら、目的が「議事録の下書き」か「話者ごとの発言確認」か「リアルタイム字幕」かを決めます。必要なものが文字起こしなら、会話生成まで行う音声モデルは不要かもしれません。ライブ対話なら、録音ファイルの文字起こしAPIではなく、音声セッションを管理する方式が必要になる場合があります。音声とテキストを扱うという共通点だけで、同じ手順を流用しないでください。
画像・音声で起きやすい失敗
画像では、文字の小ささ、傾き、低解像度、反射、圧縮、画面の一部欠けが読み取りに影響します。グラフでは、軸の単位や凡例が読めないと数値の説明を誤ります。重要な数値や固有名詞は、原画像と回答を照合してください。画像の一部を切り出す場合は、周辺の見出しや単位も含め、意味が変わらない範囲を残します。
音声では、背景雑音、複数人の同時発話、固有名詞、数字、日付、専門語が誤認識されることがあります。出力が自然な文章でも、聞き取った語が正確とは限りません。重要な数字や担当者名は元音声へ戻って確認し、必要なら単語の候補や時刻を記録します。文字起こしの流暢さを正確さの証明とみなさないことが大切です。
動画を扱うケースでは、利用サービスが直接動画を理解するのか、画像フレームや音声へ分解して処理するのか確認します。フレームだけなら、短い動きや場面の順序が失われる可能性があります。音声だけを抜き出せば、画面上の操作やジェスチャーは分かりません。「動画対応」というラベルだけで、動作の細部まで理解すると判断しないでください。必要な場面の時刻を指定し、別の記録や原動画で確認します。
一つの仕事を処理する具体例
製品の操作動画からFAQ案を作る場合、最初に完成物を「質問、回答案、根拠となる時刻、要確認点」と決めます。録音だけでは画面上のボタン名が分からないことがあり、画像だけではナレーションの説明が失われます。動画機能が必要な情報を扱えるかを確認し、足りない場合は音声の文字起こしと必要場面の画像を別々に用意する方法も検討します。
作業は、素材の確認、不要情報のマスキング、対応形式の確認、短い代表区間での試行、出力の照合、最終判断の順に進めます。まず一つの短い場面でボタン名と説明を正しく拾えるかを確認し、うまくいった場合に対象を広げます。いきなり全動画を処理すると、入力形式の不一致や読み取り誤りを大量に見つけることになります。
受け入れ条件は、質問と回答の組み合わせが動画の説明に沿うこと、根拠時刻が存在すること、動画にない仕様を補わないこと、曖昧な操作は要確認へ回すことです。出力後に担当者が原動画で該当箇所を確認します。AIが自然なFAQを書いたことと、製品仕様として正しいことは別々に判定します。
選定前に確認する手順
-
Reader Jobを一文で書く。 例「画像内の表から合計値を確認する」。
-
必要な証拠を決める。 表画像が必要か、元データをテキストやCSVで渡せるかを比べます。
-
必要な方向を決める。 入力を理解するのか、音声や画像を出力するのか、両方かを分けます。
-
利用する製品・model・endpointを特定する。 サービス名だけで決めません。
-
制約を確認する。 ファイル形式、サイズ、時間、解像度、対応言語、リアルタイム条件を公式仕様で調べます。
-
代表例で確認する。 読み取り精度だけでなく、処理時間、費用、失敗した場合の手戻りも記録します。
-
人が確認する箇所を決める。 金額、契約、個人情報、公開物など、誤りの影響が大きい箇所は原資料へ戻します。
形式の対応有無だけで選ぶと、入力できても必要な情報を取り出せないことがあります。手元の資料から小さな評価セットを作り、正しい回答の条件を先に決めてください。モデルを複数比べる場合は、同じ入力、同じ指示、同じ評価条件を使います。
プライバシーと送信前の確認
写真や音声には、顔、名札、住所、位置、周囲の会話、画面に映った顧客データが含まれることがあります。アップロード前に、タスクに不要な部分を切る、伏せる、無音化するなど、素材を最小化します。ただし加工で必要な文脈や証拠を消さないようにします。会社の資料を外部サービスへ送る場合は、社内ルール、契約、データ利用条件を確認します。
削除後の保持期間、学習利用、管理者アクセス、外部連携は別の論点です。利用者向けの設定やプランだけを見て「安全」と断定せず、対象サービスの現行プライバシー文書と組織の契約条件を確認してください。生データを評価用ログへ残さず、必要な場合でもアクセス権と保存期限を定めます。;
AIものさしの判断
マルチモーダルAIは、複数種類の情報を理解・生成できるAIの総称です。
ただしservice全体がmultimodalでも、個別modelではtext + imageのみ、audioは別modelという構成があります。
用途ごとに必要なinput / output modalityを先に決めてmodelを選びます。
引用・データ出典
公式情報を編集部が見た内容です。Hands-on未実施の記述は本文かここに分けています。
確認日:2026-10-08
