キーワードから完成広告まで：運用できる5段階パイプラインと6つのステータス

「キーワードを入力すれば、広告動画が完成する」。いまのAIクリエイティブツールは、たいていそう見せている。ただし、ここがいちばん自分をだましやすいポイントでもある。

実際に動かしてみると、「自動」の一言では片付かない判断が次々に出てくる。ニッチなキーワードで、オーガニック検索には何も出ず、商用ライブラリにも該当データがない。このときパイプラインは「根拠なし」として止まるべきか。それとも、検証されていない空のブリーフのまま動画を生成すべきか。途中でアカウントの対象範囲外となるチャネルがあり、データを取得できないこともある。これは「結果なし」なのか、それとも「問い合わせ自体をしていない」のか。対応は正反対になるのに、多くのワンクリック型ツールは、どちらにも同じローディング表示を出すだけだ。

デモではなく運用に耐えるクリエイティブパイプラインの価値は、最後の「生成」ボタンにはない。各段階で今どんな状態にあるのかを、正直に示せることだ。それが本番で回るかどうかを決め、何も出力されなかったときにどこで止まったかを見つけられるようにする。

最初に前提を置いておく。このパイプラインのリサーチ段階では、自分のアカウントでログインし、各プラットフォームの公開広告ライブラリやクリエイティブセンターを参照する。対象は、そのプラットフォームがすべての広告主に公開しているデータだけだ。署名の偽装も、制限の迂回も行わない。ここで扱うのは公開データの取得方法ではなく、そのデータを出荷可能な意思決定とアセットへ整理する方法である。

自動化の前に、5段階の流れを固める

キーワードから広告動画へ至る流れは、順番のある5段階で構成される。単なる「手順」ではない。各段階は前段の出力を受け取り、次段へ渡す。

1. 需要の発見。 市場に関する検索語を起点にオーガニックコンテンツを探し、実際のユーザーの間でそのテーマに熱量があるかを確認する。ここで得られるのはオーガニックコンテンツのシグナルだ。

2. 商用性の検証。 2種類の商用シグナルを見る。ひとつはキーワード機会、つまり検索ボリューム、競合度、出稿側のデータだ。もうひとつはクリエイティブセンターで成果を出しているTop Ads。どちらも実際に費用が投じられ、市場で検証されている。オーガニックコンテンツとは別物として扱うべきだ。

3. クリエイターのマッチング。 このテーマと市場に合うクリエイターを、インフルエンサーライブラリから見つける。

4. クリエイティブブリーフ。 上の3段階で適格と判断した根拠を統合し、生成モデルへそのまま渡せる構造化仕様にする。物語の組み立て、フックの型、対象市場はここで確定する。

5. 生成。 ブリーフを動画生成モデルへ渡し、9:16の縦型ネイティブ広告を作る。

重心があるのは4段階目だ。最初の3段階は根拠を集め、5段階目は費用を使う。その間にあるブリーフだけが、根拠を判断へ変換する。前半3段階の収集が雑なら、ブリーフはノイズをもとに判断し、ノイズでできた動画を生成する。ローディング表示を見ていても、それには気付けない。各段階のステータスを明示して初めて見える。

最初の3段階は、それぞれ単独で掘り下げる価値がある。秒単位のリテンションカーブの読み方、キーワード機会をひとつの予算額に落とし込む方法、フォロワー数だけで選ばず、インフルエンサーライブラリとアセットライブラリを突き合わせる方法は、それぞれ別の記事で扱っている。この記事で扱うのは、それらを一本の流れにつないだときに初めて現れる問題だ。

「失敗」を4つに分けるべき理由：6つのステータス

この記事で最も重要なのが、この部分である。

多くのパイプラインは、各段階の結果を成功か失敗かの2つで表す。1、2段階ならそれでも回る。しかし5段階になると破綻する。「失敗」というひとつの箱に、まったく異なる対応が必要な4つの状況を押し込んでしまうからだ。

このパイプラインでは、各段階の結果を次の6つで表す。

• completed：実行され、適格な結果を取得できた。次へ進める。

• empty：実行可能なチャネルで実行したが、適格な結果がゼロだった。検索はしたが、見つからなかった状態。

• skipped：クオータを0に設定して、この段階を自分で無効にした。実行されていない。

• unavailable：実行しようとしたが実行できなかった。たとえばキーワード機会が対応する市場言語が限られており、アカウントの対象範囲外だった場合や、依存先が一時的に停止していた場合だ。

• blocked：上流から得られた根拠が不足し、ゲートによって意図的に止められた。この段階そのものが失敗したのではなく、上流から必要な入力が来ていない。

• ready：生成専用の中間状態。事前チェックは通過したが、まだ送信指示は出していない。動画を生成できる状態で、実行を待っている。

重要なのは6つの名前を増やすことではない。empty、skipped、unavailable、blockedをひとつの「失敗」にまとめた瞬間、運用できなくなることだ。いずれも「今回は動画が出ない」という結果にはなるが、次に取るべき行動はまったく違う。

• emptyはデータの問題だ。市場にボリュームがないか、キーワードが狭すぎる。コードには触れず、検索語を変えるか閾値を緩めればよい。

• skippedは自分の判断である。対応不要だが、emptyと区別しておかないと、そもそも有効化していなかった段階を半日かけてデバッグすることになる。

• unavailableはチャネルまたは設定の問題だ。キーワードをいじるのではなく、アカウントのカバレッジを確認するか、再試行する。

• blockedは上流の問題だ。この層は正常で、前段のどこかが空だった。止められた層と格闘するのではなく、emptyになった上流段階を探す。

不透明な「失敗」ひとつでは、この4つの経路がすべて閉ざされ、原因を推測するしかなくなる。結果だけを返し、ステータスを返さないパイプラインが長く運用できない理由はここにある。何かが壊れるたび、何が起きたのかを知るために全体を再現しなければならない。

エビデンスは合算しない：オーガニックと商用シグナルを分ける

需要の発見は、「いくつか見つけた」で終わりではない。生の結果はファネルを通し、各層で件数を数える。何件返ったか、期間外だったものは何件か、言語が違ったものは何件か、テーマ外は何件か、サンプルと呼ぶには視聴数が少なすぎたものは何件か、そして実際に適格だったものは何件か。ここがemptyで返った場合、ファネルを見ればどの層で根拠が尽きたのか分かる。そもそも見つからなかったのか、多数あったがすべて期限切れだったのか、コンテンツはあったがサンプル基準を満たさなかったのか。いずれも空ではあるが、次の手は異なる。ファネルがなければ、emptyはただの空配列で、なぜそうなったのかすら分からない。

件数を数える以上に重要なルールがある。オーガニックコンテンツのシグナルと商用シグナルは別々に数え、ひとつの「エビデンススコア」に合算しない。Top Adは、誰かが実際に広告費をかけ、プラットフォームも成果を認めたアセットだ。一方、どれほど勢いがあってもオーガニック動画が10本あることは、「人が無料で視聴したいと思っている」ことを示すにすぎない。重み付き合計にすると、量の多いオーガニック動画が1本のTop Adを上回ってしまう。しかし商用的な価値は、そのTop Adのほうがはるかに高い。先に分類し、その後で順位付けするべきだ。まず商用シグナルを見て、なければ適格なオーガニックコンテンツへ、さらに何もなければクリエイターへ進む。件数ではなく、信頼性で層の順番を決める。

この考え方は1本の動画の評価にも及ぶ。オーガニックコンテンツを見るとき、いいねとコメントはひとつのシグナルであり、シェアと保存は別のシグナルだ。シェアと保存は、残したい、誰かに渡したいという行動で、より商用寄りの意味を持つ。順位付けでは、単純なエンゲージメントより重く扱う。エンゲージメント量は視聴に値することを示す。シェアと保存は、実際に商品を動かせる可能性を示す。同じ動画でも、読むべきものは別だ。

（余談だが、アトリビューションの段階でモデルが最も犯しやすいのは、「相関を因果として扱い、頻度を有効性として扱う」ことだ。そのため、プロンプトには反例を出させる制約が必要になる。これは、フィンガープリンティングの記事で、モデルに見つけたパターンをさらに疑わせるために使うプロンプトの規律と同じだ。あちらはリバースエンジニアリングにおける反証のセクションを扱う。こちらは広告アトリビューションにおける反例を扱う。仕組みは同じである。）

「生成できる」と「生成すべき」を分ける2つの準備判定

生成直前には、混同しやすいが絶対に統合してはいけない判断がある。「プラットフォームが動画を生成できるか」と、「この動画を生成すべきか」は別のゲートだ。

ひとつ目はプラットフォームの事前チェックだ。生成サービスは稼働中か、クオータは足りているか、プロンプトは許可されているか。これはインフラレベルの確認である。ふたつ目はリサーチ根拠の準備判定だ。集めた情報の中に、適格な一次根拠が少なくとも1件あるか。こちらはコンテンツレベルの確認になる。送信前には両方のゲートを通る必要があり、どちらか一方でも満たさなければステータスはblockedだ。

どちらも「生成できるか」に関する話なので、統合したくなる。しかし統合すると、最も高くつく失敗が起きる。プラットフォームは正常、クオータも十分、プロンプトも適法で、事前チェックは通る。それでも根拠ゼロの動画を生成してしまう。この失敗は、きれいに止まる失敗より高くつく。成功に見えるうえ、実際にその動画へ広告費を投じるかもしれないからだ。2つに分けておけば、このケースは安全にblockedとなり、不足しているのがクオータではなく根拠だと分かる。「作れる」と「作るべき」は同義ではない。この2つをひとつの条件式に書いてしまうのが、この種のパイプラインで最も多い設計ミスだ。

ブリーフが参照するのは適格な根拠だけ：競合コピーは調査に残し、プロンプトには入れない

クリエイティブブリーフは、この一連の流れでテキストモデルに最も多くを求める場所であり、同時に情報の無害化に関する規律が最も崩れやすい場所でもある。

役割は、適格な根拠から検証済みの構造を取り出すことだ。Top Adsに繰り返し現れるフックは何か。リテンションカーブがピークになるのは何秒目か。成果を出したオーガニックコンテンツは、「問題を示す、結果を見せる、行動を促す」のうち、どの骨格を使っていたか。そうした構造を統合し、生成仕様へ落とし込む。

ただし、厳格な制約がひとつある。競合アセットの生テキストは構造の選定にだけ使い、最終的な生成プロンプトには決して入れない。競合のフックに含まれるブランド名、ベンダー数、クオータ、価格、成果主張は、その競合固有の主張であって構造ではない。それらはリサーチ結果にはそのまま残す。どのアセットがアイデアの起点だったかを確認・追跡できるようにするためだ。しかし生成プロンプトを組み立てるときには、明示的に除外する。生成モデルに渡すのは「この物語の骨格とフックの型を使い、自社製品の動画を作る」であって、「この一文をコピーする」ではない。

この制約に手間をかける価値は明確だ。競合のコピーをそのまま生成プロンプトへ流し込めば、出力動画には他社のブランド名や価格訴求が混ざる。よくても法的リスクを持つアセットであり、悪ければ明白な盗用になる。主張を取り除いた構造だけを渡せば、検証済みの構造を再利用しつつ、自社のストーリーを語る動画ができる。リサーチでは原資料の忠実さを保ち、生成入力はクリーンに保つ。同じ根拠群でも、用途に応じて読み方は異なる。

「根拠の山から本当に検証された構造を取り出し、競合の主張を能動的に除外し、『有効な構造』ごとに反例をひとつ示す」という指示は、強い推論力と、自分の結論に反論する姿勢を同時に試す。これは、リバースエンジニアリングでモデルに任せること、任せないことと同じ役割分担だ。モデルは仮説を生み出すのは得意だが、事実の検証は弱い。検証は自分の根拠とテストに戻さなければならない。

工程ごとにモデルを使い分ける

この流れでテキストモデルが担う仕事はひとつではない。要件の異なる4つの仕事があり、最後に画像・動画生成が加わる。全工程をひとつのモデルで回すと、バッチ処理に余計なコストを使うか、ブリーフの精度を落とすかのどちらかになる。

単独でテストする価値があるのはブリーフ層だ。モデルの切り替えが結果に明確に出る唯一の工程である。テストは具体的で、この記事の中で実際に自分で試すべき箇所でもある。

1. 実際にcompletedしたパイプライン実行から、適格な根拠バンドルをひとつ取り出す。Top Adsのフック、リテンションカーブの要点、クリエイタープロフィール、キーワード機会、成果を出したオーガニックコンテンツ数件を含める。

2. 同じブリーフプロンプトを使う。ルールは、アセットの構造だけを使うこと、ブランド名・価格・クオータ・成果主張を明示的に除外すること、「有効な構造」ごとに反例仮説をひとつ示すこと。このプロンプトをclaude-opus-5とgpt-5.6-solへ別々に渡す。

3. 見るのは2点だけだ。競合固有の主張が生成プロンプトへ漏れていないか。漏れていれば失格である。そして「この構造は機能する」と述べたとき、反例を出しているか、それとも頻度を有効性と取り違えているか。

4. この2点での出来が選定基準になる。生成された動画が「競合の台本をコピーしたもの」になるか、「検証済みの構造を再利用したもの」になるかを直接左右するからだ。

1回試せば、どんなベンチマークより直接的に差が分かる。バッチのフィールド抽出層であるSonnetは、あまり厳密な選定を要しない。動けばよい。長文コンテキスト層のKimiは、自前でチャンク分割リトリーバルを書く手間を省くために選ぶ。

生成工程は非同期で扱う：送信、終端状態の待機、タイムアウト時のtask_id保持

生成は「呼び出せば動画が返る」処理ではない。動画生成は時間のかかるジョブだ。送信するとキューに入り、結果を知るには終端状態までポーリングしなければならない。この工程には3つの終了パターンがあり、混同してはいけない。

• 送信直後に返す。 ジョブはキューに入り、task_idとprocessingステータスが返る。待ち続けず、別の作業へ移れる。

• 終端状態まで待つ。 completedまたはfailedになるまでポーリングする。これが求めていた結果だ。

• 境界でタイムアウトする。 ポーリングに時間予算を設定し、結果が出る前に時間切れとなる場合がある。このとき、ジョブを失敗として捨ててはいけない。正しい対応はtask_idを保持し、「タイムアウト、未完了」と記録することだ。再送信ではなく、あとでそのIDから待機を再開できるようにする。再送信は同じ費用を二度払うことになる。

3つ目は特に間違えやすい。ポーリングのタイムアウトをタスクの失敗と同一視する実装は多い。その結果、実際にはまだレンダリング中で、想定より遅いだけのジョブを捨ててしまう。「タスクが失敗した」と「今回は待機をやめた」を区別することが、この工程の核心だ。前者は終端状態だが、後者は今回の待機をやめただけである。タスクもIDも残っている。再開すればよい。

根拠が全滅なら送信しない：最も価値があるのは、実行しない判断

ここまでの制約を一文にまとめると、このパイプラインで最も直感に反し、同時に最も価値のあるルールになる。根拠がすべて空なら、生成を送信しない。

需要の発見がempty、商用性の検証もempty、クリエイターマッチングもempty。3経路すべてに、適格な一次根拠がひとつもない。ブリーフはblockedとなり、生成事前チェックのリサーチ準備ゲートも失敗する。全体はblockedで停止し、1フレームも生成されない。

これは「何もしなかった」ように聞こえるかもしれない。しかし、最も難しく、最も費用を節約する工程でもある。前進することしか知らないパイプラインは、根拠が全滅した状況で一般論のブリーフに逃げる。誰にも刺さらない動画を生成し、「成功」と報告する。動いたように見えて、実際には情報ゼロのまま生成1回分の費用を使い、偽の成功シグナルを渡している。

パイプラインの価値の半分は生成できることにある。もう半分は、生成すべきでないときを判断できることだ。前者は能力、後者は規律である。そして、その規律の前提となるのが先ほどの6つのステータスだ。emptyとblockedを分けなければ、「根拠が全滅した」という明確なシグナルは得られず、「送信しない」という判断の土台も作れない。

分析から生成まで、ひとつのキーでつなぐ

パイプラインの設計はこれで終わりだ。残るのは純粋なエンジニアリング上の摩擦であり、実際には多くの人がここで詰まる。

この流れに必要なモデルは、2種類のベンダーにまたがる。テキスト層は、根拠の読解、フィールド抽出、ブリーフ作成、アトリビューションという複数ベンダー由来の機能で構成される。生成層は別の画像・動画サービスだ。各層ごとにSDK、認証方式、エラー形式を接続するか、あるいは多くの人のように、すべてをひとつのモデルで済ませることになる。後者ではバッチ処理に余計な費用を使い、ブリーフの精度を落とし、そのうえで別の動画プラットフォームまで接続しなければならない。統合の手間を減らすために、パイプライン全体の品質を一段下げてしまう。

AIReiterは、その統合層を取り除く。キーはひとつ、インターフェースはOpenAI互換で、4つのテキスト層を背後にまとめている。リクエストボディのmodelフィールドを変えるだけで切り替えられる。画像・動画生成も同じキーで同じサイト内にあり、ブリーフができたら/chatでそのまま生成を試せる。

# Write the brief: the reasoning tier
curl https://aireiter.com/api/v1/chat/completions \
  -H "Authorization: Bearer $AIREITER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-opus-5",
    "messages": [{"role": "user", "content": "<brief prompt + qualified evidence bundle>"}]
  }'

# Extract fields in bulk: change the model field, leave the rest
#   "model": "claude-sonnet-5"
# Stage attribution:      "model": "gpt-5.6-sol"
# Read long evidence at once: "model": "kimi-k3"

すでにOpenAI SDKを使っているなら、base_urlをhttps://aireiter.com/api/v1へ向けるだけでよい。ほかは変更不要だ。Anthropic SDKでは、同じキーでPOST /api/v1/messagesを呼び出す。

価格体系も、このパイプラインのコスト構造に合っている。最も呼び出し密度が高いのは一括フィールド抽出で、数十から数百のアセットに対して1件ずつ呼び出すため、テキスト側コストの大半を占める。Claudeは30%オフで、この用途にちょうど当てはまる。Sonnetがバッチを担当し、Opusがブリーフを反復する、どちらもClaude層だ。アトリビューションはGPT-5.6を半額で利用できる。長い根拠の読解には、同じキーでKimi K3を使う。生成は実行ごとに課金される別のコスト行だが、エビデンスゲートを通り、実際に動画を作るべきときだけ実行される。「根拠が全滅なら送信しない」というルールそのものが、生成費用を抑える。

• APIキーを取得する

• 登録なしで試す：適格な根拠バンドルをひとつ、手作業でブリーフプロンプトに渡してみよう。競合のブランド名や価格が生成入力に漏れないかを確認し、安定してからスクリプト化すればよい。

まとめ

「キーワードから完成広告まで」で本当に難しいエンジニアリングは、「完成広告」の部分ではない。公開データを適格な根拠へ変え、さらにクリーンなブリーフへ変える、その中間工程にある。

この工程を運用可能にする鍵は3つだ。各段階の結果を成功か失敗かではなく6つのステータスで表し、empty、skipped、unavailable、blockedそれぞれに明確な次の行動を持たせること。根拠を合算せず、分類して層別に扱うことで、弱いシグナルの量に強いシグナルを埋もれさせないこと。そして「生成できる」と「生成すべき」を2つのゲートに分け、根拠が全滅したときに生成前で安全に止めることだ。

モデルは、この流れの仕事を担う道具であって主役ではない。根拠を読み、フィールドを抽出し、ブリーフを書き、アトリビューションを説明し、最後に生成モデルが動画を作る。「先へ進むべきか」を決めるのは常にステータスとゲートであり、モデルの自信ではない。この設計を組み立て、4つのテキスト層とサイト内生成をひとつのキーで接続すれば、キーワードから完成広告までを本当に運用できるパイプラインになる。