マルチモーダル検品の実装例｜動画コンテンツに対する多段品質ゲートと評価軸の組み方

AI×自動化
2026.05.08

動画コンテンツに対する多段品質ゲートを実装層で整理する。フレーム抽出から Vision LLM のプロンプト設計、メタデータ自動生成、偽陽性 / 偽陰性のバランス、フォールバック機構までを順に見ていく。終盤では、ここで扱う動画検品の手法を物理カメラ入力 (= リアルタイム物品検品) に応用する方向性にも触れる。マルチモーダル検品の組み方そのものは マルチモーダル検品の構造 で扱っている。動画の生成・アップスケール・投稿 API などは本記事では深く立ち入らないが、必要があれば記事末尾の関連記事から参照できる。

章別サマリー

各章の要点を先に整理する。気になる章だけ読む形でも全体を順に追う形でも進められる。

章 要点
1. 検品工程の位置付け パイプライン全体での検品の役割、検品で扱う 4 モダリティ
2. 検品の 4 段階設計 多グリッド一括判定 (1 段目) → 詳細スコア (2 段目) → borderline 救済 (3 段目) → 投稿前最終ゲート (2 次検品)
3. フレーム抽出とグリッド構成 抽出本数 / タイミング / 解像度 / パイプ受け渡しの判断軸
4. Vision LLM へのプロンプト設計 JSON 強制・温度設定・評価軸の問い方・応答パース
5. メタデータ生成と配布先仕様適合 タイトル / タグ / 説明文の自動生成、禁止語フィルタ、配布先別変換層
6. 偽陽性 / 偽陰性のバランス設計 スコア閾値の決め方、検品ログのヒストグラム分析、見落としと過排除のトレードオフ
7. フォールバック・リトライ機構 LLM 応答失敗 / メタデータ生成失敗 / フレーム読込失敗の救済
8. 検品 = 自分の成果物へのリバースエンジニアリング 生成と検品を分離する設計の意義
9. 物理カメラ入力への応用 動画検品の手法をリアルタイム物品検品に応用する場合の方向性

1. 検品工程の位置付け

動画コンテンツの自動投稿は、動画を生成し、品質を確認し、解像度を引き上げ、メタデータを付けて配布先に投稿する、という流れで進む。この記事で深く扱うのは中央の「品質を確認する」 段階、つまり検品工程だ。動画生成や 4K アップスケールなど前後の工程に踏み込む必要があれば、記事末尾に並べた関連記事に分かれている。

検品工程の役割は「生成された動画のうち、配布先要件を満たさないものを排除し、満たすものを通過させる」 ことである。生成側でどれだけ精度を上げても、配布先固有の禁止条件や品質基準にすべて適合する動画ばかりが出力される保証はない。検品はこの最終フィルタとして機能する。

本記事で示す数値や時間感は、RTX 5080 (16GB) と RTX 5060 Ti (16GB) を組み合わせ、Ollama を複数 port で並列稼働させる環境を前提にした目安である。Vision LLM は qwen3-vl 8B クラス、embedding が必要な場面は nomic-embed-text の併用を想定している。GPU 構成や VRAM 容量で目安は変動するため、自環境に合わせて調整すれば本記事の流れはそのまま使える。

1 つ留意点として、Oculink 経由でサブ GPU を外付けする構成では、Ollama のバージョンによってはサブ GPU が CUDA backend で検出されない場合がある。その際は Vulkan backend (`OLLAMA_VULKAN=1` 系の環境変数経由) で接続することで利用可能になる。dual GPU 構成を組む際にはまりやすい部分なので、 動作しない時の切り分けポイントとして記しておく。

検品で扱うモダリティ

動画コンテンツの検品で評価される情報は単一モダリティで完結しない。少なくとも 4 つの軸でモダリティが交差する。

モダリティ 評価対象 使用ツール
視覚 (静止) 各フレームの構図 / 解像感 / 色再現 Vision LLM (= qwen3-vl 系等)
動き (時系列) フレーム間の連続性 / フリッカー / ループ継ぎ目 Vision LLM (= グリッド配置から推定) + フレーム差分
テキスト (内省) 動画内容を Vision LLM が言語化した応答の妥当性 応答パース + 評価軸別スコア集約
仕様適合 配布先の禁止語 / 必須タグ / フォーマット 禁止リスト照合 + 構造検証

動画 1 本に対して、フレーム抽出 (= 視覚) → グリッド画像化 (= 視覚集約) → Vision LLM の応答 (= テキスト変換) → スコア集約 (= 数値) → 配布先仕様検証 (= 構造) という流れで複数のモダリティ変換を経る。マルチモーダル検品の本質は、この変換の各段階で別軸の評価を加える点にある。

次章では、検品工程の 4 段階構造を見る。

2. 検品の 4 段階設計

動画ストックの検品は、コストと精度のバランスを取るため多段で組まれる。1 段で全動画を厳格に評価するとコストが膨らみ、1 段で粗く判定すると合格率が下がる。4 段階に分けることで、明らかに不合格な動画を高速排除し、明らかに合格な動画を高速通過させ、判定が割れる borderline だけ厚く評価し、投稿前に最終調整する設計が成立する。

2-1. 1 段目: 多グリッド一括判定

1 段目はコスト最優先で「明らかに NG」 を高速排除する。動画から代表フレームを 12 枚抽出 (= 等間隔タイムスタンプ) し、3 グリッドに集約して Vision LLM に一括投入する。LLM への呼び出し回数は動画 1 本あたり 1 回。

判定軸はこの段階では粗い。

  • 明らかな破綻 (= 全フレームがノイズ / 黒画 / 静止)
  • 禁止表現の混入 (= 顔の歪み / 文字化け / 著作権リスクのある記号)
  • 主題の不在 (= 全フレームが同じ抽象パターンのみで動きが無い)

応答は JSON 形式で受け取り、reject_reason フィールドが空なら次段へ進める。複数グリッドを 1 回で送るため、LLM の文脈長は長くなるが呼び出し回数は最小化される。動画 1 本あたりの 1 段目処理時間は数秒〜十数秒に収まる。

1 段目で重要なのは「false negative (見落とし) を許容しない」 という設計判断である。明らかな NG を見落として 2 段目に流すと、2 段目で詳細評価のコストを払った後で結局排除する形になり、1 段目の存在意義が薄れる。閾値は厳しめに振り、安全側で排除する。

2-2. 2 段目: 詳細品質スコア

1 段目を通過した動画に対し、0-100 のスコアリングを行う。同じグリッドを使い、評価軸を細分化して LLM に問う。

  • 視覚品質 (= ノイズ / 解像感 / 色再現)
  • 構図 (= 主題の配置 / 余白 / 視線誘導)
  • 動きの自然さ (= フレーム間の連続性 / フリッカー)
  • 商用利用適合性 (= 配布先の禁止カテゴリへの該当)
  • 差別化要素 (= ありふれた構図でないか)

各軸に重み付けして合算スコアを出す。スコア 70 以上なら通過、50 未満なら NG、50-69 は borderline として 3 段目へ。

軸の重み付けは配布先の傾向で調整する。視覚品質を重視する配布先と、差別化を重視する配布先では、同じスコア軸でも採用率の差が出る。配布先別に重みを変えるか、共通重みで運用するかは、運用初期の採用率データを見て決める。

2-3. 3 段目: borderline 救済層

50-69 のスコア帯は人間が見ても判定が割れる領域である。1 段目 / 2 段目では粗いグリッドで評価したが、3 段目は高解像度フレーム (= 512px などより大きい) で 2 グリッド送信し、より詳細な判定を取る。

この段階では「救済の方向で再評価」 が原則となる。1 段目 / 2 段目は安全側に振っているため、見落としで不合格にされた素材を救う層と位置付ける。判定基準は 1B と同等だが、グリッド解像度が上がる分、細部の品質や動きの自然さが正確に評価できる。

3 段目を通過すれば最終スコアを 70 以上に補正して PASS、通過しなければ NG として排除する。

2-4. 2 次検品 (投稿前最終ゲート)

3 段階の品質スコア検品を通過した動画でも、投稿前にもう一段の選別を入れる構成がある。これを 2 次検品と呼ぶ。1 次検品が「個別動画の品質」 を評価するのに対し、2 次検品は「投稿全体の最適化」 を評価する。

2 次検品で見る軸は以下の系統である。

  • 類似投稿との重複: 自分が過去に投稿した動画と構図 / 色 / 動きが酷似していないか。配布先の検索結果でカニバリ化するリスクを減らす
  • メタデータの最終整合: タイトル / タグ / 説明文の組み合わせで矛盾が無いか (= 例: タイトルに「夜」 があるのに動画が昼間)
  • カテゴリ分布の調整: 直近の投稿カテゴリが偏りすぎていないか。1 ジャンルに集中すると配布先評価で「特化型」 と判定されて他ジャンルの露出が減る場合がある
  • 投稿頻度の制御: 配布先によっては 1 日の投稿上限や、短時間連続投稿の制限がある。これに合わせて投稿スケジュールを組む

2 次検品で不合格になった動画は、再投稿待機 (= 別日に回す) または完全排除に振り分ける。1 次検品とは判断軸が異なるため、別の評価器 / 別の LLM プロンプトで動かすのが望ましい。

運用初期は 1 次検品だけで投稿しても回るが、投稿数が累積して数百-数千本になると重複チェックや偏り是正の意味が大きくなる。2 次検品の導入タイミングは、過去投稿の蓄積が一定量を超えてから検討する形になる。

段階設計の効果

段階設計の本質は、コスト集中の最適化にある。動画 100 本中、明らかな NG が 30 本、明らかな PASS が 50 本、borderline が 20 本だとすると、1 段目で 30 本を高速排除、2 段目で 50 本を高速通過、3 段目で 20 本だけ詳細評価する形になる。1 段で全 100 本を 3 段目相当の精度で評価するのと比べ、計算コストは大幅に下がる。

次章では、検品で最初に行うフレーム抽出とグリッド構成を見る。

3. フレーム抽出とグリッド構成

動画は時間軸方向に展開された視覚情報の集合である。検品で必要なのは、動画全体を要約する代表フレームを少数枚選び、Vision LLM が一目で把握できる形 (= グリッド画像) に集約することだ。フレーム抽出とグリッド構成のパラメータ選定は、検品精度とコストの両方に直結する。

3-1. 抽出本数の選定

多すぎると LLM の文脈長を食う、少なすぎると動きを捉えられない。運用例として目安を挙げると以下になる。

  • 5 秒尺の動画: 8-12 枚程度。1 秒あたり 2 枚弱
  • 10 秒尺の動画: 12-16 枚程度。1 秒あたり 1.5 枚弱
  • 長尺 (30 秒+): シーン変化検出と組み合わせ、抽出本数は 15-20 枚で頭打ちにする

これは絶対値ではなく、Vision LLM の文脈長 / モデル性能 / 動画の動きの密度で調整する範囲である。動きが少ない動画なら本数を減らし、動きが多い動画なら増やす形になる。RTX 5060 Ti (16GB) で Vision LLM (qwen3-vl 8B クラス) を動かす運用では、5 秒尺・12 枚・3 グリッドの構成で 1 段目判定が動画 1 本あたり数秒〜十数秒に収まる目安がある。

本数を増やすと文脈長が線形に伸びるため、Vision LLM の応答精度が一定の点で頭打ちになる。文脈圧迫を避けつつ動きを捉えるには、本数を増やすよりグリッド解像度を上げる方が効果的な場合がある。

3-2. 抽出タイミングの設計

抽出ポイントの選び方には 3 系統ある。

方式 長所 短所
等間隔タイムスタンプ 実装が単純、再現性が高い シーン変化を取り逃す可能性
シーン変化検出 意味のあるフレームを抽出 ヒストグラム差分の閾値調整が必要、ノイズで誤検出
固定 3 点 (冒頭 / 中央 / 末尾) サムネイル相当、軽量 動きの中間が見えない

動画ストックの検品では等間隔タイムスタンプが最も実用的である。シーン変化検出は映画 / 物語動画で効果的だが、ストック動画 (= 短尺で連続性のある映像) では過剰検出になりやすい。

3-3. 解像度の段階別変化

段階別検品では、各段階のグリッド解像度を変える。実例として、運用上は以下のような配分になる。

  • 1 段目 (一括判定): 1024-1536px のグリッド (= 768px フレーム × 2-3 グリッド)
  • 2 段目 (詳細スコア): 同じグリッドを使い、評価軸を細分化
  • 3 段目 (救済層): 1024px のグリッド (= 512px フレーム × 2 グリッド) で細部を確認

入力動画の解像度や Vision LLM のモデル性能で適正値は変わるため、これは絶対値ではなく自環境で調整する範囲の数字である。解像度を上げると Vision LLM の処理時間が増え、文脈長も増える。1 段目で粗解像度、3 段目で精細解像度という配分は、コストと精度のバランス調整である。

3-4. ファイル受け渡し方式

ffmpeg からフレームを取り出して Vision LLM に渡す経路は 2 系統ある。

  • パイプ受け渡し: ffmpeg の出力を直接受け取り、メモリ上でグリッド合成。ディスク I/O ゼロ、高速
  • 一時ファイル経由: ffmpeg で JPEG を一時ディレクトリに書き出し、別プロセスで読込。デバッグ容易、互換性高

パイプ受け渡しは秒単位で処理時間を短縮できる場合があるが、バイト不整合時のエラー処理が必要になる。実装ではパイプ失敗時に OpenCV 経由のフォールバックを用意するのが堅実である。

動画 1 本の処理時間が秒単位で効くのは、検品スループットを生成スループットに合わせる場合に重要になる。生成側が 1 本 / 分で動くなら、検品も 1 本 / 分以上でこなせないと検品キューが膨らむ。

次章では、抽出されたグリッドを Vision LLM にどう問うかを見る。

4. Vision LLM へのプロンプト設計

検品で Vision LLM を使う場合、プロンプトの設計が応答品質を大きく左右する。自由応答だと応答が長文化してパースが難しくなるため、構造化された応答を強制する設計が必要になる。

4-1. JSON 強制とパース

応答形式は JSON 強制が望ましい。プロンプト内に「以下の JSON 形式で応答せよ」 と明示し、フィールド名 / 型 / 値域を厳密に指定する。

  • quality_score: 0-100 の整数
  • reject_reason: 排除理由 (= 該当なしなら空文字)
  • visual_quality / composition / motion_smoothness: 各軸 0-100 の整数
  • main_subject: 動画の主題を 30 文字以内で記述
  • tags: タグ候補の文字列配列 (= 後段のメタデータ生成で使用)

応答パースでは JSON が壊れている可能性に備え、try-except で再試行ループを組む。連続失敗時は MANUAL カテゴリに退避する設計にする。

4-2. 温度設定の判断

検品では再現性が重要になる。同じ動画に対して毎回違うスコアが出ると、運用判断 (= 閾値調整) が成立しない。温度設定 (temperature) は 0 か 0.1 程度の低値に固定し、サンプリングのランダム性を抑える。

qwen3-vl のようなローカル Vision LLM でも、temperature を 0 にしても出力にわずかな揺れが残る場合がある。判定スコアを完全に固定したいときは、seed や num_ctx の設定を併用してサンプリングを抑え込む。

逆にメタデータ生成 (= タイトル / タグ / 説明文) では多様性が必要なため、温度を 0.5-0.7 程度に上げる。検品とメタデータ生成は同じ Vision LLM でも、別プロンプト + 別温度で運用する形になる。

4-3. 評価軸の問い方

「全体的な品質を評価せよ」 のような曖昧な指示は応答がブレる。評価軸を分解して、それぞれを独立に問う設計が安定する。

  • 悪い問い: 「この動画の品質を 0-100 で評価せよ」
  • 良い問い: 「視覚品質 (ノイズ / 解像感 / 色再現)、構図、動きの自然さ、商用利用適合性、差別化要素の 5 軸を独立に 0-100 で評価し、各軸のスコアと総合スコアを JSON で返せ」

独立評価することで、ある軸で低スコアでも他軸が高ければ救済できるようになる。総合スコアを LLM に直接出させると、内部で軸を勝手に重み付けしてしまい、運用側の重み調整が効かなくなる。

4-4. プロンプトキャッシュの活用

同じプロンプトを多数の動画に対して繰り返し送る場合、プロンプトキャッシュを使うと推論コストが下がる。長い評価軸定義をキャッシュ対象にし、動画ごとに変わる部分 (= グリッド画像) だけを差分送信する形にする。

ただし、キャッシュの境界管理に注意が必要である。配布先別の禁止リストや評価軸が変わる場合、キャッシュをまたいでルールが混入しないよう、バージョンキー / 配布先キーで分離する。

次章では、検品結果からメタデータをどう生成するかを見る。

5. メタデータ生成と配布先仕様適合

検品を通過した動画には、配布先で検索される際のメタデータを付与する必要がある。手動入力では量産に追いつかないため、検品工程と連動して自動生成する形になる。

5-1. 検品結果の再利用

2 段目スコアリングで Vision LLM が main_subject や tags を返している場合、これをメタデータ生成の入力として再利用できる。検品とメタデータ生成で別々に Vision LLM を呼ぶより、検品時に必要情報を一括取得する方がコスト効率が良い。

5-2. タイトル生成のフォーマット制御

タイトル生成では、フォーマットパターンの統一が重要になる。例えば「[Specific Color] [Subject] [Motion] Background」 のような骨格を定めておけば、LLM が単語を埋めるだけで一貫性のあるタイトルが量産できる。

逆にフォーマットを定めずに自由生成させると、配布先の検索アルゴリズムで不利な命名 (= 主題が後ろにある / 過度に修飾的 / 一般語が多い) になりやすい。フォーマットパターンは 5-10 種類用意し、検品結果の主題から最適なパターンを LLM が選択する形にする。

5-3. タグ生成と禁止語フィルタ

タグ生成では、配布先の禁止タグリストを毎回参照する必要がある。汎用的すぎる語 (= visual / effect / pattern などの抽象語) や、誤誘導リスクのある語 (= 既存ブランド名 / 特定ソフトウェア名) は禁止される傾向がある。

生成手順は以下になる。

  1. 検品時の tags 候補を初期セットとして取得
  2. 禁止リストでフィルタ
  3. 必須タグ (= 主題系の固定タグ) を強制保証
  4. 不足分を語彙辞書から補充して目標数 (= 25-50 個) に到達
  5. 順序を配布先の SEO 重要度順に並べ替え

禁止リストは配布先側で随時更新される。生成時の禁止リスト参照を設定ファイル化し、リスト更新で全動画のメタデータが自動的に追従する設計が運用上は楽である。

5-4. 配布先別仕様適合

動画ストックの配布先は複数あり、それぞれ仕様が異なる。同じ動画を複数配布先に投稿する場合、メタデータの再フォーマットが必要になる。実例として、運用している Adobe Stock と Pond5 の 2 系統の差異を整理すると以下のような形になる。

差異領域 Adobe Stock Pond5
キーワード形式 カンマ区切り、25-40 個推奨 カンマ区切り (旧仕様はスペース区切り)、40-50 個推奨
必須タグ カテゴリ名のみ 主題系の固定タグ (= 例: abstract / background / motion) を必須
禁止語 ブランド名 / 競合サービス名 / 過度な修飾語 ファイル名拡張子 (= fhd / 1080p) / 一般語 (= stuff / various) も禁止
タイトル制約 200 文字以内、特殊記号制限あり 同様、加えて主題が冒頭 (= [Specific Color] 始まりなど) にあることが推奨

仕様は配布先側で随時更新されるため、実際に投稿する配布先の最新規約を都度確認した上で運用する形になる。表の数値や禁止語リストも目安として捉え、最新の公式ガイドラインを優先する。

1 つ前提として注記しておく。Pond5 は AI 生成コンテンツの投稿が原則認められていない (= 公式ガイドラインで AI / 機械学習由来の素材は受け付けない方針)。 AI 生成素材を扱う場合は Adobe Stock など別の配布先が対象になる。本記事は検品手法を扱う記事なので投稿可否そのものには深入りしないが、配布先選定の段階で各サービスの AI コンテンツポリシーを事前に確認する必要がある点だけは押さえておきたい。検品工程の手法自体は AI 生成 / 実写を問わず転用できるため、Pond5 を選ぶ場合は実写素材を対象にした検品ラインとして組む形になる。

複数配布先に同じ動画を投稿する場合、共通の中間表現 (= 主題 / 動き / 色 / 雰囲気 などの構造化データ) を生成し、そこから各配布先の仕様に変換する形にすれば、新しい配布先が増えた際の追加コストが下がる。3 配布先以上に投稿するなら共通中間表現方式が、1-2 配布先なら配布先別個別生成が現実的である。

次章では、検品閾値の調整方法と検品ログの分析を見る。

6. 偽陽性 / 偽陰性のバランス設計

検品システムには 2 種類の誤判定がある。両者のバランスをどう取るかが、運用全体の質を決める。

誤判定 意味 運用上の影響
偽陽性 (= 過剰排除) 本来通過すべき動画を NG にしてしまう 採用候補が減る、生成コストが無駄になる
偽陰性 (= 見落とし) 本来 NG にすべき動画を通過させてしまう 配布先に不適切な動画が投稿され、アカウント評価が下がる

6-1. 閾値の決め方

検品スコアの閾値 (= NG 50 / PASS 70) は、初期設定では一般値で良いが、運用後に採用率データから調整する必要がある。判断軸は以下である。

  • 採用率が低すぎる場合: 検品が緩すぎて配布先評価で不採用が増えている可能性 → 閾値を上げる (偽陰性を減らす)
  • 採用率が安定している場合: 閾値はそのまま、投稿本数を増やす方向に動かす
  • 投稿本数が稼げない場合: 検品が厳しすぎる可能性 → 閾値を下げて borderline を救済する方向 (偽陽性を減らす)

採用率の評価には少なくとも 1 ヶ月の運用データが必要である。短期の変動で閾値を頻繁に動かすと、評価軸自体がブレて改善か悪化か判別できなくなる。

6-2. 検品ログの構造化

運用データを後で分析するには、検品結果を構造化ログとして残す必要がある。最低限以下のフィールドを動画ごとに記録する。

  • 動画 ID / 生成日時 / 生成プロンプト
  • 各段階のスコア (= 1 段目 / 1B / 2 の判定結果)
  • 各評価軸のスコア (= 視覚 / 構図 / 動き / 商用適合 / 差別化)
  • 最終判定 (= PASS / NG / MANUAL)
  • 配布先別の投稿状態 (= 投稿成功 / 失敗 / 採用 / 不採用)

これを CSV または構造化ログ DB に蓄積すると、スコアと採用率の相関が取れる。「スコア 70-80 帯の採用率は何%か」 「動画 / 軸別スコアと採用率の相関係数」 「不採用動画に共通する軸の傾向」 などが見える。

6-3. ヒストグラムによる検品健全性確認

検品の健全性は、スコア分布のヒストグラムを定期的に確認することで見える。

  • スコアが正規分布に近い: 検品が機能している
  • スコアが両端に偏る (= 30-40 と 80-90 の二峰): 1 段目の一括判定で多くが排除され、通過後は均質になっている可能性
  • borderline (50-69) が 30% 以上: 2 段目の評価軸が粗いか、閾値設定が適切でない
  • スコアが特定値に集中: LLM の応答が単調化している、プロンプトの軸が機能していない

運用上の目安として borderline が全体の 5-10% に収まっていれば 4 段階設計は機能していると判断できる。30% を超えるなら、2 段目のスコアリングが粗いか、閾値設定が適切でないかのいずれかを疑う対象になる。これは厳密な業界標準値ではなく、運用での感覚値として参考にする目安である。

6-4. 偽陰性のリスク管理

偽陰性 (= 不適切な動画を通過させる) は配布先のアカウント評価に直結するため、偽陽性より重く扱うのが一般的である。具体的な対策として以下が考えられる。

  • 1 段目の閾値を厳しめに (= false negative を減らす方向に振る)
  • 禁止表現の検出を独立軸で評価 (= 総合スコアでなく禁止語フラグ単独で NG 判定)
  • 不採用動画を後で分析し、検品時の見落としパターンを抽出
  • 抽出されたパターンを次世代のプロンプトに組み込む

偽陽性は採用候補数の減少として現れるが、即座のアカウント影響はない。偽陰性は数件でもアカウント評価に響く可能性があるため、設計の初期段階では偽陰性を優先して抑える。

7. フォールバック・リトライ機構

検品パイプラインは長いため、どこか 1 つの工程で失敗するとパイプライン全体が止まりかねない。各層に失敗時の救済を設計しておく。

7-1. Vision LLM 応答失敗時

Vision LLM が応答せず / タイムアウト / 不正な JSON を返した場合の対応:

  • 同じプロンプトで再試行 (= 1-2 回)
  • 再試行も失敗なら、その動画を MANUAL カテゴリに退避 (= 後で人手レビュー)
  • 運用初期は MANUAL カテゴリを用意するが、安定後は MANUAL 廃止 → NG 扱いに切り替えると人手負荷が下がる

MANUAL を廃止する判断は、安定運用に入った時点 (= 90% 以上が自動で振り分けられる) で行う。MANUAL を残し続けると、人手レビューの待ち行列が膨らみ自動化の意義が薄れる。

7-2. メタデータ生成失敗時

タイトル / タグ / 説明文の生成で LLM が空応答や不正フォーマットを返した場合、固定値のフォールバックを用意する。

  • タイトル: 「Abstract Motion Background」 のような汎用フォーマット (= 配布先の禁止語に該当しない安全な命名)
  • タグ: 主題系の必須タグ + 「flowing / luminous / iridescent」 など具体性のある汎用語
  • 説明文: タイトルから機械的に生成した最小文

固定値は配布先の禁止リストに該当しないものを選ぶ必要がある。禁止リストが更新されると固定値も陳腐化するため、定期的に見直す対象になる。

7-3. フレーム読込失敗時

ffmpeg のパイプ受け渡しが失敗した場合、OpenCV 経由のフォールバックに切り替える。OpenCV はパイプより遅いが、ファイル形式の互換性が高く、エラー復旧の確率が上がる。

OpenCV も失敗するケース (= 動画ファイルそのものが壊れている) では、その動画を NG 扱いで排除する。生成側の不具合で壊れたファイルが出てきた可能性があるため、生成ログを見直す対象になる。

8. 検品 = 自分の成果物へのリバースエンジニアリング

検品で行っていることを工学的に再定義すると、自分が生成した成果物に対するリバースエンジニアリングである。「この動画はどう作られているか」 を出力側から推定し、想定品質との差分をスコア化している。

生成エージェントと検品エージェントを別プロセス / 別モデルで分けると、この自己リバースエンジニアリングが構造的に強制される。同じプロンプト / 同じモデルで生成と検品を行うと、生成側のバイアスが検品側にも引き継がれ、見落としが発生しやすい。検品側を別軸 (= 別プロンプト / 別 Vision LLM / 別評価軸) で組むことで、生成プロセスの盲点を構造的に検出できる。

マルチモーダル検品の鍵は、この自己リバースエンジニアリングを複数モダリティで多層化することにある。視覚 / 動き / テキスト / 仕様適合の各軸で別々に評価することで、単一モダリティでは見落とされる欠陥が、別モダリティとの重ね合わせで顕在化する。

リバースエンジニアリング自体の中身や応用範囲は リバースエンジニアリングの解説記事 で別途扱っている。検品設計の理論的根拠を整理する際に併読を推奨する。

9. 物理カメラ入力への応用

ここまで扱ってきたのは、生成された動画ファイルに対する事後検品である。一方で、物理カメラから入力されるリアルタイム映像に対しても、本記事の手法は応用できる。動画検品から物理カメラ検品への移行は、フレームをファイル経由で読み込むかストリーム経由で読み込むかという入力層の違いだけで、評価軸の組み立てやスコア集約の構造は共通する。

物理カメラ検品をマルチモーダルで組みたい場合の方向性を、動画検品との対比で整理する。

9-1. 動画ファイルとカメラストリームの違い

軸 動画ファイル検品 カメラストリーム検品
入力形式 完成した動画ファイル (= 数秒〜数十秒) 連続フレーム流入 (= 終端なし)
判定タイミング 動画 1 本ごとにバッチ処理 フレーム単位 / 数秒の窓単位
遅延制約 緩い (= 数秒〜数分) 厳しい (= サブ秒〜数秒)
偽陰性コスト 不採用 / アカウント評価低下 不良品流出 / 安全性影響
救済層の余裕 borderline で 3 段目に回せる 遅延制約で救済層を圧縮する必要

共通する部分も大きい。フレームを抽出してグリッドに集約、Vision LLM に評価軸を JSON 形式で問い、応答スコアで PASS / NG を振り分けるという中核ロジックは、入力がファイルでもストリームでもそのまま使える。

9-2. リアルタイム物品検品の典型ユースケース

物理カメラと Vision LLM のリアルタイム検品が応用される領域には、以下のような系統がある。

  • 製造ライン上の不良品検出: ベルトコンベア上を流れる物品をカメラが連続撮影、不良品を即時排除する。フレームレートと判定遅延の制約が最も厳しい
  • 物流の梱包品質チェック: 出荷前の梱包状態をカメラで確認、破損 / 表記漏れ / ラベル誤りを検出する
  • セキュリティ / 異常検知: 監視映像で異物侵入や行動異常を検出する。連続監視 + 異常時のみアラート発報の構成
  • 農業 / 食品の選別: 大きさ / 色 / 形状で等級判定を行う。検品精度が直接単価に影響する領域

いずれの領域も「物品 1 つに対して数秒以内に PASS / NG を出す」 という制約が共通する。動画ストック検品で許容される数秒〜数十秒の処理時間は、物理ライン検品では成立しない場合が多い。

9-3. 段階設計の調整

動画検品の 4 段階設計をリアルタイム物品検品に持ち込む場合、以下の調整が必要になる。

  • 1 段目 の高速化が必須: 動画では数秒許容だが、物理ラインではサブ秒判定が要求される。Vision LLM のモデルサイズを下げる、グリッド枚数を減らす、ローカル GPU で動かして API 経由のレイテンシを排除する、などの対策
  • 救済層の圧縮: borderline を 3 段目に回す余裕がない場合、1 段目で粗判定 → 即時排除 + ログ記録、後で蓄積バッチで詳細解析する非同期構成にする
  • エッジ判定と中央判定の分離: 撮影現場の小型 GPU / NPU で即時判定し、判断が割れる場合のみ中央サーバーに転送して精密判定する 2 層構成。エッジ側は軽量モデル (= RTX 5060 Ti クラスの 16GB GPU + qwen3-vl 8B など)、中央側は重量モデル (= RTX 5080 や上位機 + より大規模な LLM) というすみ分けが取れる
  • 偽陰性のリスク管理を強化: 不良品流出のコストが大きいため、閾値は厳しめに振り、誤って排除した分は後でバッチ確認するフローにする

9-4. 動画検品からの主な技術転用ポイント

動画検品でここまで扱ってきた以下の要素は、物理カメラ検品でも基本構造を変えずに転用できる。

  • フレーム抽出 → グリッド集約 → Vision LLM 評価 → スコア集約のパイプライン (= 入力層をストリームに差し替えるだけ)
  • JSON 強制プロンプトと評価軸の独立評価 (= 軸を物品検品向け = キズ / 汚れ / 形状 / ラベルなど に置換)
  • 偽陽性 / 偽陰性のバランス設計とログ構造化 (= 製造ラインでは特に重要、不良率の時系列分析が品質改善に直結)
  • フォールバック機構 (= LLM 応答遅延時はルールベース判定に切り替え、通信障害時はエッジ単独判断に縮退)

逆に物理カメラ特有で追加検討が必要な要素は、フレームレート設計、撮影環境の照明制御、カメラキャリブレーション、エッジと中央の通信プロトコル、判定結果の物理装置 (= ベルトコンベアのアクチュエータ等) への即時反映である。これらは動画検品の対象外で、産業用途のシステム設計に固有の知識領域となる。

本記事の手法を物理カメラ検品にそのまま適用するのではなく、共通する部分 (= マルチモーダル評価の構造) と置き換えが必要な部分 (= 入力層 / 遅延制約 / アクチュエータ連携) を分けて考えると、応用設計の見通しが立ちやすい。

関連記事

まとめ

マルチモーダル検品の実装層を、動画コンテンツに対する多段品質ゲートとして整理した。4 段階の検品 (= 多グリッド一括判定 / 詳細スコア / borderline 救済 / 投稿前最終ゲート) でコストと精度のバランスを取り、視覚 / 動き / テキスト / 仕様適合の 4 モダリティで評価を組み立てる。フレーム抽出とグリッド構成、Vision LLM へのプロンプト設計、メタデータ自動生成、偽陽性 / 偽陰性のバランス設計、各層のフォールバックを組み合わせることで、長いパイプラインでも止まりにくく、運用後の調整が効く検品システムが構築できる。

本記事で扱った要素は、動画ストックという特定ジャンルを越えて、画像 / コード / テキスト / 物理カメラ入力など他の領域でも応用可能である。モダリティの組み合わせや遅延制約は変わるが、4 段階設計と多軸評価という骨格は共通の枠組みとして使える。物理カメラを使ったリアルタイム物品検品に応用する場合は、入力層の差し替えと遅延制約への調整が中心となり、評価軸の組み立て自体は本記事の枠組みがそのまま使える。

検品は単なる品質ゲートではなく、自分が生成した成果物に対するリバースエンジニアリング工程である。生成と検品を別エージェントで分離する設計を取れば、生成プロセスの盲点を構造的に検出できる。マルチモーダル検品の効きどころは、この自己リバースエンジニアリングを複数モダリティで多層化することにある。

コメント

タイトルとURLをコピーしました