前回のハブ記事で「量産型は4層構造で組む」と書いたが、層の中身までは踏み込まなかった。今回は筆者が実際に運用しているストックフォト動画自動化を例に、4層がそれぞれ何をしているのかを思想レベルで開示する。コード・プロンプト・データソースは伏せるが、各層で何を判断しているかは追えるようにした。
本記事は、ハブ記事 2026年版｜AI自動化は本当に稼げるのか？ で挙げた量産型自動化の「内部構造」を、実例ベースで深掘りした内容だ。
例題：ストックフォト動画系の自動化
具体例として、特定のプラットフォームに動画をアップロードする自動化を前提に話を進める。ストックフォト動画はジャンルとしては量産が刺さりやすく、品質基準が比較的明確で、リジェクト/承認のフィードバックが取りやすい。4層構造を組んだときに、各層の効きが見えやすいテーマだ。
逆に言うと、ここで作った4層をそのまま画像生成・記事生成・音声生成へ転用しても、構造は崩れない。各層の中身（モデル・プロンプト・判定ロジック）を入れ替えるだけで動く。
第1層：リサーチ層
何が売れていて、何が売れていないのかを把握する層。実際に作る動画の「題材」をここで決める。
使用するモデルは、精度の高いものを選ぶ。ここをケチると、後ろの3層をどれだけ磨いても稼げない出力を量産することになる。トレンドの読み違い・市場のサチュレーション見逃し・季節性のミスは、すべてここの層の責任になる。
具体的なデータソース・選定ルール・スコアリング閾値は伏せる。これを公開するとリサーチがそのまま真似されて市場が飽和するからだ。詳細は派生記事 → AI自動化のリサーチ層 ─ 量産型で勝ち筋を作る最初の関門 でリサーチ層単独の設計方針を書いている。
第2層：生成層
リサーチ層から渡された題材を元に、動画を作るためのプロンプトを生成し、そのプロンプトで動画を出力する層。本記事で一番チューニング工数がかかった層でもある。
プロンプト作成用のモデルと、動画生成用のモデル（あるいは動画生成モデルを内蔵したAIツール）は分ける。混ぜると最適化軸が崩れる。プロンプトは言語モデルの仕事、動画は別系統だ。差別化はモデルではなくプロンプト側の仕込みで作る方が現実的で、同じモデルを使っていても出力分布は変えられる。バリエーションを派生させる仕組みも、ここで設計しておくと量産効率が変わってくる。
そして一番の鬼門は、出力をどこまでコントロールして、ハルシネーションや余計な文章を削げるかだ。プロンプトの出来 ＝ 動画の出来、と言っていい。出来上がった動画と入力プロンプトを並べて、何度も最適値を探すことになる。1回で終わる作業ではないので、最初から「永続的に磨く層」と思っておくと精神的に楽だ。
生成側のローカル実装に踏み込みたい人は、ComfyUI 入門か LTX 1 のノード構成あたりから入るのが早い。
第3層：品質層
生成層から出てきた動画を検品する層。線引きをここで決める。アップロードできるか・できないかの判定ロジックがここに入る。
主に使うのは VL モデル（Vision-Language）か、マルチモーダル対応モデル。動画の中身を見て、設定したルブリックでスコアを返してくれるモデルなら何でもいい。筆者はこの層を「マルチモーダル検品」と呼んでいる──視覚モデル・言語モデル・数値照合など、複数のモダリティで同じ生成物を多角的に検査する手法だ。動画に限らず画像・記事・音声などあらゆる AI 生成物に適用できる。
たとえば「スコア80%以上は合格→配信層へ、70%未満は廃棄かプロンプトに戻して再生成、70〜79%は保留にして後で人間が見る」みたいな線引きを設定する。閾値を上げればリジェクトが増えてゴミが減る、下げれば通過率は上がるがゴミが混ざる。出口（プラットフォーム審査）の厳しさに合わせて動かす変数だ。
もうひとつの判断材料は、配信プラットフォーム側のリジェクト率だ。アップロード後に審査落ちが続くようなら、品質層の閾値が低すぎる。逆に通過率が極端に高いのに売れていないなら、品質ではなく題材（リサーチ層）に問題がある。品質層は単独で評価せず、配信層からのフィードバックとセットで動かすのが基本だ。
第4層：配信層
合格した動画をアップロードする層。ここは正直そこまで難しくない。既存のAIエージェントで足りるタスクだ。動画とメタ情報（タイトル・タグ・カテゴリ）をAPIに投げて、結果（成功/失敗/審査中）をログに残し、売れた・売れなかった・審査落ちたをリサーチ層へ返す。それだけ。
気をつけるとしたらレート制限とアカウント評価くらい。プラットフォーム側は急にアップロード本数が跳ね上がったアカウントを警戒する。投げ放題にせずペース管理を仕込んでおく。技術的に難しい話ではないけれど、見落とすとアカウントが BAN されて4層全部が止まる。
各層のモデル選定マップ
4 層それぞれが要求する特性は異なるため、 全層を最高精度モデルで揃える選び方は API 課金の観点で破綻しやすい。 求められる性質ごとに分けてマッピングすると次のような構成になる。
| 層 | 主要モデルの種別 | 求められる特性 | 典型的な選択肢 |
|---|---|---|---|
| リサーチ層 | 言語モデル + 検索連携 | 事実精度・新鮮性 | Claude / GPT 系の上位モデル |
| 生成層 (プロンプト) | 言語モデル | 指示忠実性・ハルシ耐性 | ローカル LLM (Qwen / Llama 系) で十分 |
| 生成層 (動画) | 動画生成モデル | 映像品質・条件追従 | ComfyUI 上のローカルモデル / Runway / Pika / Luma |
| 品質層 | VL / マルチモーダル | 視覚理解 + 安定したスコアリング | Qwen2.5-VL / LLaVA / Gemini Vision 系 |
| 配信層 | API クライアント | レート制御・リトライ・ロギング | 素の Python + 既存エージェント |
視覚言語モデルの選定は、 配信先プラットフォームのリジェクト基準に対する判定の一致率で詰める。 Qwen2.5-VL のアーキテクチャと評価指標は Qwen Team 公式リリースノート に、 LLaVA 系の Visual Instruction Tuning の原理は LLaVA: Visual Instruction Tuning (arXiv:2304.08485) に整理されている。 Gemini の視覚入力 API 仕様は Google Gemini API Vision ガイド で確認できる。
生成層をローカルとクラウドのどちらで動かすか
生成層は 4 層のなかでも最もコストに影響する層なので、 月産本数を試算してからローカル/クラウドを決める。 月数千本以上を見込むなら、 一定の GPU 投資があってもローカル運用のほうが単価で勝つ場合が多く、 1 本あたりの従量課金が利益を圧迫する状況を避けやすい。
| 観点 | ComfyUI (ローカル) | SaaS API (Runway / Pika / Luma) |
|---|---|---|
| 初期コスト | GPU + 電源 + 冷却の投資 | 0 円から開始可能 |
| 1 本あたりの追加コスト | 電気代のみ | 従量課金 (秒数 / 解像度) |
| カスタマイズ自由度 | ノード単位で完全自由 | API の出力形式に制約 |
| 生成速度 | GPU 性能に直結 | クラウド側キューに依存 |
| 適合する量産規模 | 月数千本以上で割安に転びやすい | 少量・短納期に向く |
| モデル切替の柔軟性 | 新モデル公開後すぐに差し替え | SaaS 側の対応待ち |
ComfyUI のノードベース構成と最新リリースは ComfyUI 公式 GitHub リポジトリ に集約されている。 SaaS 側の仕様は、 それぞれ Runway 公式ドキュメント ・ Pika 公式サイト ・ Luma Dream Machine で随時更新される。 VRAM の見積もりは ComfyUI 推奨スペックの解説 も参考になる。
4層を1つの自動化として束ねる
筆者はこの4層をまとめて1つの「自動化」と呼んでいる。中では複数のモデルが層ごとに動いているが、入口にデータを入れて出口でアップロードされる、1本の自動化として外からは見える。
アップスケール・CSV連携・データ可視化のような付加機能を足すとさらに複雑化するが、骨格はこの4層で十分。アップスケールなら生成層と品質層の間に挟む、CSVなら配信層の入口、可視化はリサーチ層と配信層のフィードバックループ ─ という具合に、層に応じて足していけばいい。
関連 → AI自動化のコスト構造 ─ 単月黒字になっているかを見る / AIアプリは出した瞬間に再現される ─ 真似されても勝てる構造の作り方
4 層をつなぐ実装方式の選択肢
層ごとに切れた箱として動かす場合、 つなぎ方は次の表のように分けられる。 量産規模が小さいうちにフレームワークを入れると、 層ごとの個別チューニングがフレームワーク側の都合に縛られる結果になりやすい。
| 方式 | 導入コスト | 柔軟性 | 適合規模 | 導入の目安 |
|---|---|---|---|---|
| Python 関数 + SQLite | ほぼ 0 | 高 (層単位で書き換え自由) | 個人〜中規模 | 最初から |
| Apache Airflow / Prefect | 中 (DAG 設計が必要) | 中 | 複数自動化の並行運用 | 2-3 本目の自動化を並走させる段階 |
| n8n / Make / Zapier 系 | 低 | 低 (ノード制約あり) | シンプルな通知・統合 | 非エンジニア運用のみ |
SQLite で十分という判断の根拠は、 ファイルベースで運用できる組み込み RDBMS という性質にある (SQLite 公式 About ページ)。 ワークフローエンジンを後から導入する場合は Apache Airflow 公式ドキュメント や n8n 公式ドキュメント を参照しつつ、 既存の 4 層インターフェースを壊さない統合方法から検討する。 4 層側を Python の関数呼び出しで素直に書いてあれば、 後付けのオーケストレーション層は単純に外側を包む形に収まる。
4層を組む必要があるかは「量産するか」で決まる
ここまで読んで「面倒くさそう」と思った人は、たぶん組まなくていい。4層構造が必要になるのは、量産する場合だけだ。動画を数本だけ作りたい、月に数本のテンプレ運用で済む、というレベルなら、システムを構築する必要はない。
その場合は、すべてをチャット系AIで代替できる。実際、筆者も最初は Gemini 1本でやっていた時期があった。リサーチも生成のプロンプト出しも品質チェックも、Gemini に都度聞きながら手動で回していた。本数が増えてきて Gemini の回答待ちと手動コピペが追いつかなくなった時点で、初めて「自動化を組む価値が出る」。
逆に言うと、本数が少ないうちに4層を組み始めるのはオーバーエンジニアリングだ。「手作業の限界」を一度経験してから組むと、各層に何が必要かが体感として分かる。
動画を実際に作ってみたい人向け
4層の話よりまず動画を1本作ってみたい、という人は、生成層単体から触るのが早い。ComfyUIや動画生成モデルを使った具体的なワークフローはこちらにまとめた。
- ComfyUI 入門 → ComfyUIとは？必要スペックからAI画像生成の始め方まで初心者向けに解説
- LTX 1 でのノード構成 → LTX 1をComfyUIで動かすノード構成の全体像
- VRAMで何ができるか → ComfyUI推奨スペック｜VRAM 8GB・12GB・16GBで何ができるか実測解説
1本作って「これを毎日10本にしたい」と思ったら、その時点で4層構造の設計に戻ってきていい。
プラットフォーム審査と規約という変数
4 層のうち品質層と配信層は、 配信先プラットフォームの審査基準と直結する。 ストックフォト動画系の場合、 配信先ごとに次のような規約が公開されている。
Adobe Stock では、 投稿された素材が技術的品質 (露出・ホワイトバランス・ノイズ・ピント) と知的財産権 (商標・ロゴ・人物のリリース) の両面で審査される。 AI 生成コンテンツの取り扱いについても専用のガイドラインが用意されており、 投稿時にメタデータの付与が要求される。
出典: Adobe Stock Contributor 一般ガイドライン
このような審査ルブリックをそのまま品質層のスコアリング基準に落とし込むと、 配信層でのリジェクト率が安定する。 Shutterstock も同様に Shutterstock コンテンツガイドライン を公開しており、 配信先を複数持つ場合は、 もっとも厳しい基準を品質層の閾値に合わせるのが定石になる。
AI 生成コンテンツの取り扱いは各プラットフォームで方針が分かれている (Adobe Stock Generative AI 投稿基準)。 リサーチ層に「禁止カテゴリ」 と「需要のあるカテゴリ」 を並行で読み込ませる設計にしておくと、 規約の変更があっても 4 層全体の挙動を維持しやすい。 配信層側でも、 アップロード時に AI 生成フラグや使用モデル名を付与する処理を入れておくと、 規約変更でメタデータ要件が増えても改修が局所で済む。
よくある質問（FAQ）
Q. 4層全部に高精度モデルを入れる必要はある？
A. ない。各層で求められる性質が違う（リサーチは精度、生成はハルシネーション耐性、品質は判定の安定性、配信は API が叩ければ何でも）ので、全層を最高精度モデルで揃えるとAPI課金で単月黒字がだいたい崩れる。コスト側の検証は コスト構造の記事にある。
Q. 各層を別々のサーバー/インスタンスに分ける？
A. 思想は分離、実装は一体でいい。ローカルで動かすなら1台のPCで4層回せる。クラウドAPIを叩くなら、層ごとにAPIプロバイダを変えれば自然に「論理的な分離」ができる。物理的に分ける必要はほぼない。
Q. 4層をつなぐのに何かフレームワークを使ってる？
A. 使ってない。素朴な Python の関数呼び出しと、層ごとの出力をローカルファイルか軽量な DB（SQLite で十分）に貯めて次の層が拾うだけで足りる。Airflow や Prefect のようなワークフローエンジンを最初から導入する必要はないし、n8n / Make 系の SaaS も要らない。複雑化してきたら都度足せばいい話で、最初から重い基盤を入れると、たいてい層ごとのチューニングがそこに引きずられて回せなくなる。
Q. ComfyUI なしで動画生成は組めますか？
A. 組める。動画生成は ComfyUI 以外にも、APIで叩ける動画生成サービス（Runway / Pika / LumaなどのSaaS）が複数ある。ローカルで動かす理由がコスト削減なら ComfyUI、量とスピード重視ならSaaS APIを生成層に入れる、という選び方になる。4層構造は変わらない。
Q. 量産型は結局「数で勝負」ですか？
A. 違う。量産型でも単価は重要。リサーチ層が機能していれば、低単価市場ではなく中〜高単価市場に量を投下することになる。「数を出せば誰でも稼げる」のは集客フックに使われている話で、運用者の実感とはズレる。詳細はハブ記事 → 2026年版｜AI自動化は本当に稼げるのか？
Q. ローカル LLM を生成層のプロンプト側で使うなら、 どの系列が現実的？
A. 指示追従性と日本語の品質を見るなら Qwen2.5 系 / Llama 3.x 系 / Gemma 2 系のいずれかが当面の候補になる。 ComfyUI と組み合わせて使うなら、 量子化版を含むモデル配布が整っている系列を選ぶと運用が楽だ。 各モデルの一次情報は配布元の公式ページ (Qwen 公式ブログ ・ Meta Llama 公式) で確認できる。
Q. 品質層のスコアと実際のリジェクトが乖離する場合、 どこを疑う？
A. 乖離が出る原因は、 (1) VL モデルが画面内のテキストや小さなオブジェクトを取り逃している、 (2) ルブリックの言語化が曖昧でモデルがブレている、 (3) プラットフォーム側の審査基準が変わった、 のいずれかにほぼ収束する。 直近 30 件のリジェクト理由を集めてルブリックに反映する手当てを月次で組むと、 乖離は徐々に収束していく。 ルブリックは最初から完成させようとせず、 リジェクト履歴で育てる位置づけで運用する。
Q. 4 層ごとに残すべきログの最低限は？
A. 入力 / 出力 / モデル名 / モデルバージョン / 推論時間の 5 点を最低限残す。 これだけ残しておくと、 後から「あのときの出力なぜ悪かったか」 をモデル単位で再現できる。 ログを軽量 DB (SQLite) に貯めるだけで、 リサーチ層と配信層のフィードバックループも自動で組める。
まとめ
- 量産型AI自動化はリサーチ・生成・品質・配信の4層。プロンプトと動画のモデルは分ける、品質層は閾値を配信層のリジェクト率と一緒に動かす ─ ここまでが筆者の組み方
- 4層を組むのは「量産する場合だけ」。本数が少ないならチャット系AI 1本で十分回る
- 1本作って「これを毎日10本にしたい」と思ったタイミングが、4層に投資する適切なタイミング
- ちなみに筆者はリサーチ層以外（生成・品質・配信）をすべてローカルLLMで動かしている。クラウドAPIに頼るのは精度が必要なリサーチ層だけで、コスト構造はこれで成立している
合わせて読みたい：
- ハブ記事 → 2026年版｜AI自動化は本当に稼げるのか？
- リサーチ層を単独で深掘り → AI自動化のリサーチ層 ─ 量産型で勝ち筋を作る最初の関門
- コスト構造 → AI自動化のコスト構造 ─ 単月黒字になっているかを見る
- 後発対策 → AIアプリは出した瞬間に再現される ─ 真似されても勝てる構造の作り方
- 投資型と比較する → 2026年版｜AI自動化レバレッジ型（投資型）は稼げるのか？
あわせて読みたい：マルチモーダル検品とは何か ─ 視覚・言語・数値で重ね合わせる検品設計 ─ 4 層構造のうち品質ゲート層を独立ハブとして整理した記事。AI 生成物の検品は単一モデルでは取りこぼしが出るという前提から、視覚・言語・数値の三層で重ね合わせる設計を概念レベルで解説している。
あわせて読みたい：AI 自動化、 どのジャンルから始めるか ─ 完成形 × 非属人性で選ぶ入口設計 ─ AI 自動化を始める時の領域 (ジャンル) 選びを、 参入障壁・完成形・属人性の 3 軸で整理した入口判断ハブ。 ストックフォト動画系・非属人性 YouTube・業務 SaaS から、 同じカテゴリ内の難易度差まで踏み込んでいる。
本記事は AIツール図鑑編集部 が記載時点の情報をもとに執筆。製品アップデートや第三者ベンチマーク・価格・対応ランタイム等の変動で評価が変わる可能性がある。一定期間経過した内容は再検証を推奨する。
