マルチモーダルとは？複数データを扱うAIの仕組み・業務応用と実装判断を解説

マルチモーダルとは、テキスト・画像・音声・動画といった複数の種類のデータ（モダリティ）を横断して扱うAIのことです。文章だけを読む、画像だけを見るといった単一データのAIと違い、画像を見ながら質問に文章で答えるような、人間に近い情報処理ができます。この記事では、そもそも「モーダル」という語が何を指すのかの整理から始め、シングルモーダルとの違いと扱えるデータ形式、異なるモダリティをベクトルの埋め込み空間で結びつける統合の仕組み、対照学習（CLIP）が画像と言葉を対応づける原理、手元でCLIPを動かして類似度を計算する具体的な手順、帳票処理や外観検査での業務応用、そして自社の課題に汎用マルチモーダルLLMのAPIを使うか専用モデルを構築するかの実装判断までを、つくる側の目線で通しで整理する構成です。大規模言語モデルがどう成り立つかの一般解説は別記事に譲り、ここでは「なぜ複数のデータ形式を1つのモデルで扱えるのか」と「どう動かすのか」に踏み込みます。

まとめ：マルチモーダルAIの要点と実装判断の結論

マルチモーダルAIは、異なる形式のデータをそれぞれ専用のエンコーダで数値ベクトルに変換し、意味が近いもの同士が近くに集まる共有の埋め込み空間で結びつけることで成り立ちます。画像と「猫」という単語を同じ空間の近い位置に配置できれば、モデルは画像と言葉を横断して扱えるわけです。この対応づけを大量のペアデータで学習させる代表手法が対照学習（CLIP）で、2021年に公開された原論文では4億組の画像とテキストのペアで事前学習したと報告されています。現在のマルチモーダルLLMは、この考え方を大規模言語モデルに取り込み、1つのモデルで文章生成と画像理解を両立させたものです。

実装判断の結論を先に述べます。問い合わせ対応や社内文書検索のように、既存の汎用マルチモーダルLLMのAPIで解ける課題なら、専用モデルを構築せずAPI利用から始めるほうが費用対効果で有利になります。一方、製造ラインの外観検査や医療画像のように、自社固有のデータでの精度と処理速度、機密データの外部送信可否が問われる領域では、学習済みモデルを転移学習で自社データに適合させた専用モデルの構築が現実的な選択です。「マルチモーダル＝とりあえず新しいLLM」と短絡せず、扱うデータの機密性と求める精度から入口を選ぶ。それが投資を無駄にしない分岐点になります。

もう1点、検討の初期に効くのがコストの当たりを付けておくことです。画像や音声の入力は文字数ではなくトークンに換算されて課金されるため、1件あたりの単価は事前に計算できます。Gemini APIの画像理解ドキュメント（2026年9月2日時点）は、両辺が384ピクセル以下の画像を258トークン、それより大きい画像を768×768ピクセルのタイルごとに258トークンとして数えると明示しています。1日何件処理するかを掛ければ、PoCに進む前に月額の桁は見えるはずです。

マルチモーダルの定義とシングルモーダル・扱うデータ形式の違い

マルチモーダルという言葉は「マルチ（複数の）」と「モダリティ（データの様式・種類）」を組み合わせたものです。まず語そのものの意味をほどき、単一データしか扱えない従来のAIとの違いと、実際に組み合わせられるデータ形式を押さえます。

マルチモーダルの定義と単一データしか扱えないシングルモーダルとの違い

シングルモーダルAIは、1種類のデータだけを入力として処理します。文章の要約モデルはテキストのみ、従来の画像分類モデルは画像のみを扱う、といった具合です。これに対しマルチモーダルAIは、複数の形式を同時に、あるいは相互に関連づけて処理します。たとえば商品写真とレビュー文を合わせて評価を判定する、レントゲン画像と問診テキストを突き合わせて所見の候補を出す、といった処理が典型です。人間は目・耳・言葉を無意識に統合して状況を理解しますが、シングルモーダルAIはそのうち一感覚だけを切り出したモデルにあたります。マルチモーダルの狙いは、複数の情報源を突き合わせることで、単一データでは判断しきれない曖昧さを減らす点にあります。

モーダルという語の意味とUIのモーダルウィンドウとの取り違えを解く

「モーダル」だけで検索すると、AIの話とはまったく別の解説が並びます。これは同じ英単語 modal が、分野ごとに違うものを指しているからです。Web開発やアプリ開発の文脈での「モーダル」は、画面に覆いかぶさって表示され、閉じるまで背後の操作を受け付けないダイアログ、いわゆるモーダルウィンドウを指します。HTMLではdialog要素のMDNリファレンスが、showModal() で開いた場合にダイアログ以外の操作が遮断されると説明しています。こちらの「モーダル」は「モード（状態）を持つ」という意味合いです。

一方、本記事が扱う「モーダル」はモダリティ（modality＝情報の様式）の略で、テキストや画像といったデータの種類そのものを指します。両者に技術的なつながりはなく、たまたま語幹が同じなだけです。社内でAIの要件を議論するときは、この取り違えが議事録レベルで混乱を生みます。「マルチモーダル対応」と書かれた要望が、実は画面のダイアログ改修だった、という食い違いは実際に起こります。AIの文脈で使うときは「マルチモーダル」または「モダリティ」まで含めて書き、UIの文脈では「モーダルウィンドウ」と省略せずに書く。この使い分けだけで、要件定義の初期の齟齬はかなり減らせます。

テキスト・画像・音声・動画という主要モダリティと組み合わせの例

実務で組み合わされる主なモダリティは、テキスト、画像、音声、動画の4つです。動画は画像の時系列と音声の複合と捉えられ、この4つに加えてセンサー値や3Dデータを扱う例もあります。組み合わせ方は課題によって変わります。

入力側が複数モダリティのものと、入力は1つで出力が別モダリティのもの（テキストから画像を生成する画像生成など）があり、どちらもマルチモーダルの範疇に入ります。自社の課題がどの組み合わせに当たるかを最初に言語化しておくと、後の技術選定はぐっと絞り込めるはずです。なお主要APIの対応状況は組み合わせごとに差があり、たとえば動画についてはGemini APIの動画理解ドキュメントのように専用の入力手順が用意されている一方、扱える尺やフレームレートには制限が設けられています。要件を固める前に、使う予定のAPIの制限値を必ず読み合わせてください。

マルチモーダルLLMと従来のマルチモーダルAIの関係を版で押さえる

マルチモーダルAIという概念自体は、大規模言語モデル以前から画像認識や音声処理の分野で研究されてきました。言葉が広く知られるようになった背景には、大規模言語モデルが画像入力に対応したマルチモーダルLLMの登場があります。ただし「どのモデルが画像を読めるか」は版によって入れ替わるため、記事や資料の記述をそのまま信じるのは危険です。2026年9月時点でOpenAIの画像入力ガイドが画像入力対応として列挙しているのは gpt-6-astra、gpt-5.5系、gpt-5.4系、gpt-5.2、gpt-4.1-mini、gpt-4o系などで、GPT-4oはすでに最新版ではなく互換のために残る位置づけです。Google側も同時点の公式サンプルは gemini-3.8-flash を用いています。

実装時に確認すべきなのはモデル名そのものではなく、公式ドキュメントが「いま」何を推奨しているかです。これらはいずれも「LLMがマルチモーダルに拡張されたもの」であり、マルチモーダルAIの一形態にすぎません。大規模言語モデルそのものの仕組みと企業導入の判断基準は、LLMの仕組みと企業導入の判断基準を解説した記事で扱っています。本記事はその拡張として、複数モダリティをどう1つのモデルで統合するかに焦点を当てます。

マルチモーダルAIが異なるモダリティを埋め込み空間で統合する仕組み

異なる形式のデータを1つのモデルで扱う鍵は、すべてを共通のものさし、すなわち数値ベクトルに変換し、意味の近さで結びつけることにあります。テキストと画像という見た目の違うデータを、どうやって同じ土俵に乗せるのかを分解します。

各モダリティをベクトルに変換するエンコーダと共有埋め込み空間の役割

マルチモーダルモデルは、モダリティごとに専用のエンコーダを持ちます。テキストはテキストエンコーダで、画像は画像エンコーダで、それぞれ意味を凝縮した数値の並び（埋め込みベクトル）へ変換する役割を担う点は共通です。これらのエンコーダはニューラルネットワークの仕組みと種類を解説した記事で扱うTransformerや畳み込みネットワークで構成されます。要は、生のピクセルや文字列を、意味を表す座標へと写す変換器です。学習の目標は、意味が近いデータ同士のベクトルが、モダリティが違っても近い位置に来る共有の埋め込み空間をつくることにあります。猫の画像のベクトルと「猫」という単語のベクトルが空間内で近ければ、モデルは画像と言葉を橋渡しできます。この共有空間が、マルチモーダルの土台です。

対照学習（CLIP）で画像とテキストを同じ意味空間に対応づける仕組み

共有埋め込み空間をつくる代表的な手法が、OpenAIが公開したCLIPに代表される対照学習です。Web上の大量の「画像とその説明文」のペアを教材に、正しいペアのベクトルは近づけ、無関係な組み合わせのベクトルは遠ざける、という引き寄せと押し離しを繰り返します。実装の実体はGitHubのopenai/CLIPリポジトリで公開されており、画像エンコーダとテキストエンコーダの出力を同じ次元の潜在空間へ射影し、その内積を類似度スコアとして扱う構造だと確認できます。明示的なラベル付けをせずとも、画像と言葉の意味的な対応が空間内に立ち上がる点が、この手法の面白いところです。

学習済みの対応関係を使えば、あらかじめ用意していないカテゴリでも、テキストで指定して画像を分類・検索できます。こうした画像とテキストをまたぐ検索や分類を担う画像も処理できるマルチモーダル埋め込みモデルCohere Embed 4を解説した記事のように、埋め込みを直接扱えるモデルも実務で選択肢になります。RAGの検索対象に画像やPDFを含めたい場合、この種のマルチモーダル埋め込みが要です。具体的な構成と方式選定の判断はマルチモーダルRAGの仕組みと実装方式の選び方で詳しく解説しています。

入力段階で結合するearly fusionと出力側で統合するlate fusionの違い

複数モダリティをモデルのどの段階で統合するかで、大きく3つの方式に分かれます。統合位置は精度と柔軟性のトレードオフを決めるため、設計の分岐点になります。

• early fusion（早期統合）：入力に近い段階で各モダリティの特徴を結合し、以降を一体で処理する。モダリティ間の細かな相互作用を捉えやすい一方、片方のデータ欠損に弱い。
• late fusion（後期統合）：各モダリティを独立に処理し、最後の判断だけを統合する。構造が単純で欠損に強いが、モダリティをまたぐ微妙な関係は捉えにくい。
• intermediate fusion（中間統合）：処理の途中でクロスアテンションなどにより情報を交差させる。両者の中間で、マルチモーダルLLMはこの方式に近い。

どの方式が向くかは、モダリティ同士の関係の深さと、入力欠損の起きやすさで決めます。画像と文章が密に絡む視覚的質問応答なら早期から中間の統合、独立性の高い複数センサーの異常検知なら後期統合が扱いやすい、といった見極めになります。

CLIPを手元で動かして画像とテキストの類似度を計算する手順

ここまでの仕組みは、実際に動かすと一気に腹落ちします。CLIPは公開の学習済みチェックポイントがあり、GPUがなくても数行で試せます。以下はHugging Faceのtransformers（2026年9月時点のドキュメントは5.15系）の公式リファレンスに沿った手順です。

transformersのpipelineでゼロショット画像分類を試す手順

いちばん短い経路は pipeline です。transformersのCLIPモデルドキュメントが掲載しているゼロショット画像分類の例をそのまま動かすと、画像1枚に対して候補ラベルごとの確率が返ります。学習時に「猫クラス」を定義していなくても、テキストで指定するだけで分類できる点が、共有埋め込み空間の恩恵そのものです。

pip install transformers torch pillow

# zero-shot 画像分類（候補ラベルはテキストで自由に指定できる）
from transformers import pipeline

clip = pipeline(
    task="zero-shot-image-classification",
    model="openai/clip-vit-base-patch32",
)
labels = ["a photo of a cat", "a photo of a dog", "a photo of a car"]
image_url = "http://images.cocodataset.org/val2017/000000039769.jpg"
print(clip(image_url, candidate_labels=labels))

ラベルを自社の検査項目や商品カテゴリに置き換えれば、そのまま実務のあたりを付けられます。ここで期待どおりの順位が出ないなら、対照学習の事前学習データに自社ドメインの語彙が乏しいということで、後述する専用モデル構築の検討材料になります。

AutoModelで埋め込みを取り出し類似度スコアを自分で確かめる

pipeline は結果だけを返すので、埋め込みの中身を見たい場合は AutoModel を直接使います。画像とテキストがそれぞれベクトルになり、その内積から類似度が出るという流れが、コードの上で追えます。

import requests
from PIL import Image
from transformers import AutoModel, AutoProcessor

model = AutoModel.from_pretrained("openai/clip-vit-base-patch32", device_map="auto")
processor = AutoProcessor.from_pretrained("openai/clip-vit-base-patch32")

url = "http://images.cocodataset.org/val2017/000000039769.jpg"
image = Image.open(requests.get(url, stream=True).raw)
labels = ["a photo of a cat", "a photo of a dog", "a photo of a car"]

inputs = processor(text=labels, images=image, return_tensors="pt", padding=True).to(model.device)
outputs = model(**inputs)
probs = outputs.logits_per_image.softmax(dim=1)
idx = probs.argmax(dim=1).item()
print(labels[idx], round(probs[0][idx].item(), 3))

logits_per_image が画像ベクトルと各テキストベクトルの類似度で、softmax を通して確率に直しているだけです。検索用途なら softmax を取らず、類似度をそのまま並べ替えのスコアに使います。画像側の埋め込みだけを事前に計算してベクトルDBへ入れておけば、テキストクエリで画像を引く検索が組めるわけです。マルチモーダル検索の実装は、この一手間の置き場所を設計するだけとも言えます。

マルチモーダルLLMのAPIへ画像と音声を渡す実装とトークン計算

自前でモデルを持たない場合は、マルチモーダルLLMのAPIへ画像や音声をそのまま渡します。テキストのみのAPIとの違いは、入力の組み立て方と、課金対象のトークンの数え方の2点に集約されます。

Responses APIのinput_imageで画像を渡しdetailで粒度を選ぶ

OpenAIのAPIでは、input_text と input_image を並べて1つのメッセージに入れます。画像はURL指定でも、data URLとしてbase64で埋め込む形でも渡せる仕様です。公式ガイドによれば、1リクエストあたりのサイズ上限は512MB、画像枚数は最大1,500枚までとされています。

from openai import OpenAI

client = OpenAI()
response = client.responses.create(
    model="gpt-5.4-mini",
    input=[
        {
            "role": "user",
            "content": [
                {"type": "input_text", "text": "この請求書の合計金額と発行日を JSON で返してください"},
                {
                    "type": "input_image",
                    "image_url": "https://example.com/invoice.png",
                    "detail": "high",
                },
            ],
        }
    ],
)
print(response.output_text)

ここで効くのが detail の指定です。low は粗い理解向けで固定コスト、high は高忠実度で1枚あたり最大2,500パッチ、original は座標の精密さやOCR用途向けで最大30,000パッチと段階が分かれています。帳票から小さな数字を読む用途で low を選ぶと精度が落ち、逆にサムネイルの内容判定に original を選べば無駄に払うことになります。用途ごとに検証して固定するのが定石です。

Gemini APIへ画像と音声を渡すときの上限とトークン換算

Gemini APIも構造は似ていますが、制限値の設計は別物です。インライン画像データを使う場合、テキストプロンプトやシステム指示を含むリクエスト全体で20MBが上限で、これを超えるならFiles API経由でアップロードしたファイルのURIを渡す形に切り替えます。設計段階でこの分岐を決めておかないと、本番でファイルサイズの大きいスキャン画像に当たって落ちます。

from google import genai

client = genai.Client()
interaction = client.interactions.create(
    model="gemini-3.8-flash",
    input=[
        {"type": "text", "text": "この作業動画で手順書と違う操作を指摘してください"},
        {"type": "image", "uri": "YOUR_FILE_URI", "mime_type": "image/jpeg"},
    ],
)
print(interaction.output_text)

音声も同じ枠組みで扱えます。Gemini APIの音声理解ドキュメント（2026年9月2日時点）は、音声を1秒あたり32トークン、つまり1分あたり1,920トークンに換算し、1リクエストで最大9.5時間の音声を扱えると記載しています。WAVやMP3のほかFLAC、Opus、WebMなど13のMIMEタイプが対象です。1時間の会議音声なら入力だけで約11万5千トークンという計算になり、議事録用途の単価はここから逆算できます。

マルチモーダルAIの業務での使いどころと文書処理・検査への応用

ここからは、技術の話から実務へ移ります。マルチモーダルが単一データのAIより効くのは、複数の情報源を突き合わせて初めて判断できる業務です。代表的な使いどころを、応用度の高い順に挙げます。

帳票・契約書の文書理解とOCR単体では届かない項目の読み取り精度

請求書や契約書の処理は、マルチモーダルが実務で成果を出しやすい領域です。従来のOCRは文字を読み取るところまでは担いますが、「どの数字が合計金額で、どれが明細か」という文書の構造理解は苦手でした。マルチモーダルモデルは、文字情報とレイアウト（表の位置や罫線といった見た目）を同時に扱うため、非定型の帳票でも項目の意味を推定できます。結果として、様式がばらばらな取引先の請求書からでも、金額・日付・取引先名を構造化して抽出しやすくなります。文字を読むOCRから、文書の意味を読む処理への発展が、この応用の核です。前節のコードで detail を high 側に寄せる判断が効くのも、まさにこの用途になります。

視覚的質問応答・画像キャプション生成による検索と問い合わせ対応

画像について文章で問答する視覚的質問応答（VQA）は、問い合わせ対応や検索の実務に直結します。製品の写真を送ると型番や対処法を答える一次サポート、社内の図面やスクリーンショットを自然文で検索する仕組みなどが典型例です。画像の内容を説明文にする画像キャプション生成は、大量の画像資産にテキストの索引を付け、検索可能にする用途で使われます。写真1枚に手作業で説明を付ける工数を、モデルで下書きし人が確認する運用に置き換えられる点が実務的な利点になります。

製造業の外観検査・医療画像診断・動画解析における実務的な応用例

画像認識が主役の領域に、テキストや数値の文脈を足すことで判断の質が上がる応用もあります。製造ラインの外観検査では、傷や欠けの画像判定に、その製品の仕様や過去の不良履歴といったテキスト情報を組み合わせ、良否の境界を状況に応じて調整できる点が利点です。医療では画像所見と問診・検査値を突き合わせ、動画解析では作業映像と手順書を照らして逸脱を検知します。いずれも、画像単独では「見えているが意味づけできない」情報に、言語や数値の文脈を与えて判断につなげる構図です。こうした画像を軸にした業務適用は、専用の画像認識AIモデル構築と組み合わせる場面が多くあります。

企業がマルチモーダルAIを実装する際の採用判断と費用対効果の見極め

ここからは、自社の課題にマルチモーダルAIを持ち込むべきかの判断軸を示します。結論から言えば、マルチモーダルは万能の切り札ではなく、単一データで足りる課題にまで持ち出すと過剰投資になります。

マルチモーダルを採用すべき条件とシングルモーダルで足りる見送り場面

マルチモーダルが有利なのは、複数の情報源を突き合わせないと判断できない課題です。画像とテキスト、音声と文脈のように、片方だけでは曖昧さが残る場面でこそ、統合の効果が出ます。逆に、見送ってよい場面もはっきりしています。テキストの分類や要約だけで完結する業務に、画像処理まで載せたマルチモーダルLLMを持ち込むのは、コストと運用の重さに見合いません。扱うデータが実質1種類なら、その形式に特化したシングルモーダルのモデルのほうが、精度も速度も運用のしやすさも上回ります。「複数のデータがあるから」ではなく「複数を突き合わせないと解けないか」で採否を決めるのが妥当な判断です。単一モダリティで目的の精度に届くなら、そこにマルチモーダルは要りません。

トークン換算から画像1枚あたりの推論コストを事前に見積もる手順

採用を決める前に、1件あたりの推論コストを概算しておくと議論が具体的になります。手順は3つです。まず対象画像の解像度を決め、公式の換算式でトークン数を出します。前述のとおり両辺384ピクセル以下なら258トークン、大きい画像は768×768のタイル単位で258トークンずつ積み上がるので、A4のスキャン画像を長辺1,536ピクセルで扱うなら概ね数タイル分の換算です。次に、そこへプロンプトと出力のトークンを足します。最後に、使うモデルの単価と月間処理件数を掛けます。

この3ステップを踏むと、「1日1,000件の帳票を読む」といった要件が、月いくらの話なのかが数字で見えます。逆に、単価が想定を超えるなら、解像度を落とす、detail を low に下げる、前段で軽量モデルの振り分けを挟む、といった打ち手を先に検討できるはずです。PoCの企画書に概算のトークン計算を1枚付けるだけで、稟議の通りやすさが変わります。

汎用マルチモーダルLLMのAPI利用か専用モデル構築かの選択基準

マルチモーダルを使うと決めたら、次は汎用モデルのAPIを呼ぶか、専用モデルを構築するかの選択です。まずは汎用マルチモーダルLLMのAPI利用から試すのが定石で、初期投資を抑えて短期間で効果を検証できます。ただしAPI利用が向かない条件も明確です。医療画像や設計図のように機密データを外部へ送れない、ミリ秒単位の応答が要る、自社固有の不良パターンで高い精度が要る、という条件のいずれかに当たるなら、専用モデルの構築が現実的な選択になります。その場合もゼロから設計する必要はなく、公開された学習済みモデルを自社データで適合させる転移学習とファインチューニング・特徴抽出の違いを解説した記事の手法で、少ないデータでも実用精度に近づけられます。

自社のデータを軸にマルチモーダルなAIを実装したいが、汎用APIと専用構築のどちらが適切か判断に迷う段階では、要件定義から実装まで対応する一創の生成AI開発・AI受託開発にご相談ください。データの機密性・求める精度・応答速度の条件と、前節のトークン換算による費用の見積もりを突き合わせ、API利用と専用モデルのどちらで組むべきかの見極めまで含めて設計します。

マルチモーダルAIの仕組み・業務応用・実装に関するよくある質問

マルチモーダルAIの検討でよく検索される疑問に、実装目線で簡潔に答えます。

モーダルとマルチモーダルは何が違うのですか？

AIの文脈での「モーダル」はモダリティ、つまりテキストや画像といったデータの種類そのものを指し、「マルチモーダル」はそれを複数扱う性質を指します。ただしWeb開発の文脈で「モーダル」と言えば、閉じるまで背後の操作を受け付けないモーダルウィンドウのことです。同じ語で分野がまるごと違うため、AIの話では「モダリティ」「マルチモーダル」まで略さずに書くのが安全です。

マルチモーダルとマルチモーダルLLMの違いは何ですか？

マルチモーダルは、複数のデータ形式を扱うAI全般を指す広い概念です。マルチモーダルLLMは、そのうち大規模言語モデルを土台に画像などを扱えるよう拡張したものを指します。つまりマルチモーダルLLMはマルチモーダルAIの一形態で、両者は上位概念と下位概念の関係です。画像認識や音声処理の分野には、LLMを使わないマルチモーダルAIも従来から存在します。

マルチモーダルAIはどんなデータを組み合わせられますか？

テキスト・画像・音声・動画が主な対象で、動画は画像の時系列と音声の複合として扱われます。これに加え、センサーの数値や3Dデータを組み合わせる例もあります。組み合わせは課題次第で、画像とテキストの2つだけでも十分にマルチモーダルです。すべての形式を載せる必要はなく、判断に必要な情報源だけを選ぶのが実務的でしょう。

マルチモーダル埋め込みとは何ですか？

画像とテキストなど異なる形式のデータを、意味の近さが位置の近さに対応する同じベクトル空間へ変換したものです。これにより、テキストで画像を検索する、画像で似た文書を探すといった、モダリティをまたぐ検索や分類ができます。RAGの検索対象に画像やPDFを含めたい場合の基盤技術で、対照学習（CLIP）などで学習されます。本記事のコード例で取り出している logits_per_image は、まさにこの埋め込み同士の類似度です。

マルチモーダルAIを自社で使うには専用モデルの開発が必要ですか？

必ずしも必要ありません。問い合わせ対応や文書検索など汎用的な課題は、既存のマルチモーダルLLMのAPI利用で始められます。専用モデルの構築が要るのは、機密データを外部へ出せない、自社固有のデータで高精度が要る、高速応答が要る、といった条件に当たる場合です。まずAPIで検証し、条件に合わなければ専用構築へ進む順序が費用対効果に見合います。

マルチモーダルAIと生成AIはどう違いますか？

生成AIは、文章・画像・音声などの新しいコンテンツを生み出すAIの総称です。マルチモーダルは、複数のデータ形式を扱う性質を指します。両者は切り口が異なる概念で、重なり合う部分もある関係です。テキストから画像を生成するモデルは、生成AIであり同時にマルチモーダルでもあります。一方、画像を分類するだけのマルチモーダルAIは、生成を伴わない例です。

関連記事

• LLMとは？大規模言語モデルの仕組みと企業導入の判断基準：マルチモーダルLLMの土台となる大規模言語モデルの導入判断を知りたい方はこちら。
• マルチモーダルRAGとは？仕組みと実装方式の選び方：画像やPDFを検索対象に含めるRAGの構成を具体的に組みたい方へ。
• Cohere Embed 4とは？画像も処理できるマルチモーダル埋め込みモデル：画像とテキストをまたぐ検索・分類を担う埋め込みモデルの実例を深掘りしたい方へ。
• ニューラルネットワークとは？仕組み・種類・学習方法を実装目線で解説：各モダリティのエンコーダを支えるネットワーク構造の基礎を押さえたい方へ。
• 転移学習とは？ファインチューニング・特徴抽出との違い：学習済みモデルを自社データで適合させ専用モデルを近道で作りたい方へ。