マルチモーダル検品とは何か ─ 単一視点では見抜けない欠陥を、複数モダリティで重ね合わせる

なぜ単一視点では足りないのか

AI 生成物を本番に乗せようとすると、ある時期から急に「単一モデル検品」の限界がはっきり見える。原因は単純で、欠陥はモダリティをまたいで出るのに、検品側が一つのモダリティしか見ていないからだ。

視覚モデルにフレームを送ると、構図やコントラスト、モーフィングのような物理的な破綻はそれなりに拾える。ところが「絵としては成立しているのに、テーマの一貫性が崩れている」「色彩は綺麗だが季節感や時間帯が混在している」といった意味レベルの違和感は、視覚側だけでは判定が安定しない。

逆に、生成された説明文だけを言語モデルに読ませても、画像と照らさない限り「絵にないものを語ってしまった」を捕まえられない。AI が書いた文章は文法的に自然に見えることが多く、文法だけ見ているうちは、画像との不一致や事実誤認が素通りする。

数値スコアも同じ盲点を持つ。マルチモーダル LLM や独自の品質スコアモデルが「品質 8.5」と返してきても、人間が見ると 1 秒で「これは違う」と分かる映像が混ざる。スコア値は集計には強いが、外れ値の救済には向かない。

つまり、AI 生成物の品質を一つのモダリティで保証しようとすること自体に無理がある。「複数の視点で重ねて、はじめて欠陥が浮き上がる」というのが、運用してみての実感に近い。

三つのモダリティと、その分担

マルチモーダル検品は、ざっくり三層に分けて考えると整理しやすい。視覚層・言語層・数値層の三層で、得意分野と苦手分野がきれいにずれているからだ。

分担の発想は、人間の検品チームと変わらない。最終チェックを一人にやらせず、デザイナーが見て、ライターが見て、品質担当が数字で締める、という体制を機械に置き換えただけと言える。

ここで重要なのは、各モダリティが 同じ対象に対して別の問いを投げる ことだ。視覚層が「絵として破綻していないか」を見て、言語層が「説明と絵が一致しているか」を見て、数値層が「過去の合格ロットと比べて偏差が大きすぎないか」を見る。質問が違うから、見落としの傾向もずれる。

デュアル GPU 並列で「生成と検品を同時に回す」

マルチモーダル検品を本番運用しようとすると、すぐに当たるのが 計算リソースの取り合い だ。生成と検品を同じ GPU で順番に回すと、ロット全体のスループットが大きく落ちる（低下幅は生成モデル・検品モデル・解像度・並列度に依存する筆者環境での体感）。

筆者の環境では、メイン生成を RTX 5080 (16GB)、並列生成と検品ワークロードを RTX 5060 Ti (16GB) に振り分けるデュアル GPU 構成で動かしている。RTX 5060 Ti は Oculink eGPU ドック (MINISFORUM DEG1、Oculink 4i = PCIe 4.0 x4) でつないでいて、このバンド幅でも筆者環境の検品系推論は実用範囲で動く（速度はモデル・入力サイズ・GPU 間転送量・CPU/メモリ構成に依存する）。

※ Ollama の既定ポートは 11434、ComfyUI は利用形態により 8000 または 8188。上表は筆者環境でのカスタム割当なので、そのままコピーせず自分の環境に合わせてほしい。

生成側の GPU が次のロットを動かしているあいだに、検品側の GPU が前のロットを評価する。筆者環境では、生成側と検品側を別 GPU に分けることで、少なくとも通常ロットでは生成待ちと検品待ちが大きく重なりにくくなった（処理時間はモデル・解像度・同時実行数に依存）。これが検品の段数を増やせる前提になっている。検品の精度を上げる前に、まず検品が「邪魔にならない」状態を作るのが運用設計の最初のハードルになる。

具体的なベンチマークや、Oculink eGPU を半年使った感触は別記事にまとめてあるので、リソース設計の側から興味があればそちらも参照してほしい。

段階設計：粗くから細かくへ

三層に分けたうえで、もう一つの設計上のポイントが「粗い順に通す」段階性だ。最初から重い検品を全数に走らせると、生成バッチが詰まる。実運用では、段階を切って「明らかな失敗を早く落とし、グレーだけを深く見る」という流れを組む。

段階設計のポイントは、「同じ生成物に対する精査を、進むほど深くする」 ことだ。仮に第 1 段階で 6 割を弾ければ、第 3 段階へ送る件数はその分減り、後段コストを抑えられる。粗い検品が手抜きなのではなく、後段リソースの保護として機能している。

もう一点、地味だが効くのが コンテキスト注入 だ。第 2 段階のスコアリング時に「この生成物は上位品質帯（高品質ライン）として扱う」「この生成物は量産帯（数量ライン）として扱う」という前提を入れる。同じ画像でも、上位帯と量産帯では合格基準が違う。品質帯ごとの採用ラインを LLM のプロンプトに混ぜることで、人間の「これは上位帯の中ではちょっと弱い」という相対判断に近い動きを出せる。

失敗時の救済層

マルチモーダル検品の運用で、本番品質を決めるのは検品の精度ではなく 失敗時の救済層 の方だ、というのが正直な実感に近い。検品自体はどこかで必ず失敗する。問題は「失敗したあと、どう拾い直すか」をシステムに組み込めるかどうかになる。

救済層には、大きく二つの役割がある。一つは 視覚フォールバック。言語層がメタデータ生成に失敗したとき、もう一度視覚層に戻って「画像から拾えるラベルだけで最低限を埋める」という代替経路だ。タイトル・タグの精度は落ちるが、ロット全体が止まらない。

もう一つは リトライ層。検品で NG になった生成物を即廃棄せず、生成パラメータを変えて n 回までやり直す。1 回目で破綻した seed が再生成で通ることも一定数ある（筆者環境のログでの傾向で、件数・再生成条件・上限回数に依存）。リトライの上限を決めておかないと無限ループに入るので、ここはハードリミットを必ず置く。

救済層は地味で、検品本体ほど見栄えがしない設計だが、運用安定の本体はここにある。検品が完璧に動く前提のシステムは、検品が落ちた瞬間に止まる。

モダリティ間の整合性チェック

三層をそれぞれ動かすだけでも検品としては機能するが、もう一段踏み込むと モダリティ間の整合性 を別の角度で見るパスを足せる。視覚層が「画像に X はない」と言い、言語層が「説明文に X が出てきた」と言う場合、その差分をハルシネーション検知の信号として取れる。

整合性チェックの実装は重くない。視覚層の所見と言語層の出力を、もう一度 LLM に並べて「両者は同じ対象を語っているか」を yes/no で照合させると、不整合候補を抽出できる。ただし yes/no 判定自体も誤るため、重要ロットではしきい値・再評価・サンプル目視を併用する。視覚側にしか出てこないオブジェクトを言語側が語っていれば、説明文の方を直す。逆に、言語側にしか出てこない概念を視覚側が確認できなければ、捏造の疑いが立つ。

このチェックは AI 生成物のハルシネーション検出と本質的に同じ問題で、画像側で確認できない要素を言語側が断定していれば捏造候補、というのは音声・テキスト・コードのいずれでも同じロジックで成り立つ。マルチモーダル検品の汎用性は、この整合性レイヤーの薄さに支えられている。

他の領域へどう応用するか

マルチモーダル検品はストックフォト動画系の運用から組み上げた手法だが、設計の骨格は AI 生成物がある他領域にも応用しやすい。「視覚・言語・数値の三層 + 救済層 + 整合性チェック」という構造の中で、何を「視覚」「言語」「数値」に置くかを差し替えるだけで成立する。

表の中で「視覚層」というのは比喩的に使っている。コードに視覚があるかと言われると物理的にはないが、「構造そのものを直接見るレイヤー」という意味では役割は変わらない。重要なのは、同じ生成物を異なる角度から複数回見る という設計方針であって、モダリティの呼び名ではない。

多くの領域で、単一モダリティ検品はいずれ限界に当たりやすい。マルチモーダル検品はそこを抜けるための共通フレームとして使える。ただし各領域で評価指標・失敗モード・品質や法令の要件は異なるため、そのまま転用できるとは限らない。

最後の人手チェック ─ 結果に直結する場所にだけ人間のリソースを使う

三層の検品と救済層と整合性チェックを通したあとでも、筆者は最後にロットのすべてを 自分の目で 1 度だけ 通すようにしている。ここまで重ねた自動検品をすり抜けたものでも、人間が見て初めて気づく違和感は確実に残るからだ。

もっとも、ここで残る違和感の多くは、自分側の検品システムの不良というよりは、投稿先プラットフォーム側のレビュー基準の揺らぎ に起因するものになる。具体的には、動画自体に技術的な問題はないのに、投稿先プラットフォームに似たテーマや構図の素材が既に大量に登録されていて、新規投稿が「重複に近い」として弾かれる というケースが一番多い。同じ品質帯の素材でも、投稿先のコレクション内に類似素材が多いと通らないことがある。個別の審査理由はプラットフォームから通知される範囲に限られる。これはこちら側で詰めきれる問題ではなく、人間の目で「今のプラットフォームのライブラリ状況に対して、新しい角度を出せているか」を最後に当てるしかない領域だ。最後の人手チェックは、自分のシステムの穴埋めというより、プラットフォーム側の不確実性 を吸収するゲートとして機能している。

ここでもう一つ押さえておきたいのは、このプラットフォーム類似度の問題は、マルチモーダル検品の精度をいくら上げても解決しない ということだ。検品レイヤーで解ける問題ではなく、「そもそも何を作るか／どこに新しい角度を見出すか」という 上流の設計レイヤー で対応する話になる。プラットフォーム側の在庫構成を読み解いて、まだ薄い領域に素材を作りに行く動きは リサーチ層 の役割だし、競合がどう棲み分けて、どこなら自分が勝てるかを設計するのは 逆解析 の領域に属する。ここでは検品レイヤーの話で完結させるが、検品の精度だけでは届かない問題があることは、最初から区別して認識しておくほうが運用設計を間違えない。

理由は単純で、AI を 100% は信じていないからだ、と言うのが一番素直な表現になる。ここでいう「信じない」は、不信感や懐疑というより、判断の最終責任を AI に委ねない という運用上の線引きに近い。マルチモーダルで重ね合わせた検品でも、最後の合否判定だけは人間に残しておく。

もう一つの理由は、リソース配分の話になる。自動化できる工程は徹底的に自動化してタイパを取り、人間のリソースは 結果に直結する判断 にだけ集中させる、という配分だ。検品の各段階は機械が大量にこなしてくれるので、人間が関わる必然性は低い。一方で、ストックに採用されるかどうかを最終的に決める「これを世に出すか」という判断は、自動化精度がいくら上がっても結果への寄与度が高いままになる。だったら、ここに集中投下したほうが良い。

具体的には、第 3 段階のメタデータ生成まで通って「採用候補」になったロットを、ストック投稿の直前に一覧で並べ、サムネイルとタイトル・タグの組を一通り目視する。違和感のあるものはここで外す。所要時間は 1 ロットあたり数分で、自動化の段数からすると軽いコストだ。それでも、ここを省いたバージョンと省かないバージョンでは、最終的な採用率の質感が違う。

大事なのは、人手チェックを 自動化のメインライン に置かないことだ。流れの中に組み込むと、人間がボトルネックになって自動化の意味が薄れる。自動化の最後にだけ置く「上限を引くゲート」 として配置しておく。検品が機械的に動く範囲はどこまでで、どこから先が人間の判断領域か、その線をはっきり引いておくと、運用が楽になる。

マルチモーダル検品は、人間の判断を置き換えるための仕組みではなく、人間の最終判断の前に、明らかな失敗を機械が大量に落としてくれるための仕組みとして捉えると、設計の落としどころが見えやすい。タイパ最優先で自動化する範囲と、結果に直結するから人間が見る範囲を、最初に分けておくのが運用設計の本体になる。

ここで述べた段階設計を実際のパイプラインに落とし込む手順（フレーム抽出、Vision LLM へのプロンプト設計、偽陽性・偽陰性のバランス、フォールバック機構）は、マルチモーダル検品の実装例で具体的に解説している。

よくある質問

Q. 単一モダリティの精度を上げるのと、マルチモーダル化するのは、どちらを先にやるべきか

筆者のストックフォト動画運用では、単一モダリティを詰めるより先に視覚層と言語層を分けたほうが、効果を確認しやすかった。単一モダリティの精度は上限に近づくほどコストがかさみやすく、二層目を足したときの効果は早い段階で出やすい。ただし最適な順序は、タスク・既存精度・検品コスト・失敗時の損失によって変わる。

Q. すべての生成物にマルチモーダル検品をかける必要があるか

いらない。第 1 段階の欠陥検出は全数にかけるが、第 2 段階以降は「採用候補」だけに絞ってよい。筆者環境では、フレーム枚数・再試行回数・利用モデルによって検品側の処理時間や API コストが生成側を上回ることがあった。明らかな NG を早く落として後段に送る件数を絞る設計が効く。

Q. デュアル GPU は必須か。単一 GPU でも組めるか

必須ではない。単一 GPU でも、生成と検品を時間軸で分けてバッチで回せば動く。ただし生成スループットが検品の重さに引きずられる。月産ロットが小さいうちは単一 GPU で問題ないが、ロットが増えると検品の方が処理時間を支配する側に回ってくるので、その段階でデュアル化を検討すればいい。

Q. ローカル GPU を持っていない場合、クラウド API だけで組めるか

組める。実際、最初から大規模な GPU 投資をせずに、クラウド API だけで三層を組むのは現実的な選択肢になる。視覚層は Claude (Vision) や GPT のマルチモーダル機能、Gemini などに画像・動画フレームを投げると、自由記述の欠陥所見や意味的な評価が返ってくる（Google Cloud Vision API はラベル検出や OCR など専用機能が中心で、自由記述の品質所見にはマルチモーダル LLM と役割を分けて使う）。言語層は同じプロバイダーのテキストモデルで成立するので、視覚層と言語層を一つの API ベンダーで揃えると、整合性チェックの実装も楽になる。数値層は、API が標準で返す使用量・レイテンシ・エラー率などに加え、必要なら自前のルーブリックで LLM に評価点を出させて集計する（Google Cloud Vision の label score のような専用 API のスコアは、品質スコアとは分けて扱う）。ただしクラウド構成では画像・動画フレームを外部サービスへ送信するため、機密素材・個人情報・契約上の制限がある場合は、各 API のデータ利用・保持・学習利用・人間レビュー・リージョンを必ず確認したい。

クラウド構成の利点は、GPU 購入の初期投資なしで始められて、ロット規模に応じて課金が増減する点だ。一方で API は従量課金で、無料枠・有料枠・データ利用条件・レート制限がサービスごとに異なる。導入前に月間ロット数・画像枚数・再試行回数から費用上限を試算し、課金アラートと API キー管理（露出防止）を設定しておきたい。ロットが大きくなると 1 件あたりの API 呼び出しコストが運用コストの主役 になり、ローカル GPU を持つケースより損益分岐点が早く立ち上がる。筆者環境では、月産規模が大きくなるほど API 呼び出しコストが支配的になった。分岐点は 1 ロットあたりのフレーム数・利用モデル単価・再試行回数・GPU 償却期間・電気代で大きく変わるため、導入前に自分の条件で月額を試算してほしい。検品の 設計の骨格（三層 + 救済層 + 整合性チェック + 人手最終ゲート）は、ローカルでもクラウドでも変わらない。

Q. どのモダリティから組み合わせるのが現実的か

視覚層と言語層を最初に組むのが汎用性が高い。数値層は、視覚と言語が動き始めてから「このスコア帯はだいたい合格率が n%」という統計を取って後付けするほうが、しきい値が現実に合う。

Q. 救済層は具体的に何を実装すればよいか

最低限はフォールバック分岐 1 本でよい。「言語層が JSON を返せなかった場合、画像から最低限のラベルだけ拾うパス」を 1 つ用意しておくだけで、ロット停止の発生頻度が大きく落ちる。リトライ層はその後で足せばいい。

Q. ハルシネーション検知の整合性チェックは、どのくらいの頻度で立つか

筆者環境では、一定期間のサンプルで不整合候補が一定割合（おおむね 1 割前後まで）出た。母数・しきい値・偽陽性率で変わる値なので目安として扱ってほしい。完全な一致を要求しすぎると判定が辛くなるので、しきい値はゆるめに置き、不整合があったら言語層側を再生成する、くらいの運用が落ち着く。

まとめ

この記事は AI 自動化のなかで検品レイヤーをどう組み立てているかを整理した内容で、各層の具体的な実装は別記事で展開している。先に読むなら、量産型 AI 自動化の 4 層構造 の記事から「マルチモーダル検品が 4 層のどこに位置するか」を押さえておくと、ここでの三層モデルが運用全体のなかでどこに位置するかが見える。GPU リソース設計から入るなら、デュアル GPU 運用ガイド と Oculink eGPU ドックのレビュー を先に読むと、検品レイヤーが「なぜこの構成で組んだか」が立体的に見える。

あわせて読みたい：AI 自動化、 どのジャンルから始めるか ─ 完成形 × 非属人性で選ぶ入口設計 ─ AI 自動化を始める時の領域 (ジャンル) 選びを、 参入障壁・完成形・属人性で整理した入口判断ハブ。 ストックフォト動画系・非属人性 YouTube・業務 SaaS から、 同じカテゴリ内の難易度差まで踏み込んでいる。

本記事は AIツール図鑑編集部 が記載時点の情報をもとに執筆。製品アップデートや第三者ベンチマーク・価格・対応ランタイム等の変動で評価が変わる可能性がある。一定期間経過した内容は再検証を推奨する。