コーディングエージェントでAI動画アプリを構築する

先月、小さな動画生成機能をリリースした。インテグレーション層のほとんどはコーディングエージェントが書いた。推論は以前と変わらず別のモデルAPIで動いており、独自のレイテンシ、課金、キューの挙動がある。2日後、自分が誤った思考モデルを持っていることに気づいた——エージェントとモデルが同じ軸上に存在するという思い込みだ。そうではない。

2026年のAI動画アプリ開発は、奇妙な中間地点にある。スキャフォールディングは速くなった。ランタイム——キュー、リトライ、プロバイダが廃止したときのフォールバック——は難しくなった。これがコーディングエージェントの助けになる部分であり、止まる部分であり、スタックが実際に必要なものだ。

私はDoraだ。これはそのノートだ。

コーディングエージェントがAI動画アプリ開発を変えた理由

アプリスキャフォールディングにおいてCodexが自動化できること

Codexのようなコーディングエージェント——CLI、IDE、SDKからアクセス可能で、現在のスコープはOpenAIのCodexドキュメントにある——は、AI動画アプリ開発の退屈な半分を圧縮する。

得意なこと：動画生成APIをラップするバックエンドのスキャフォールディング、OpenAPI仕様から型付きクライアントの生成、キューワーカーロジックとWebhookハンドラの記述、ReactのアップロードプロンプトプレビューコンポーネントのビルD、モックレスポンスに対する統合テストの記述。これらのタスクはどれも難しくない。しかし、どれも面倒くさい。エージェントは1日かかる作業を1時間でこなす。

空のリポジトリから、リトライロジックと実際のフロントエンドを備えた動画生成エンドポイントまで、半日もかからずに到達した。最初は信用していなかった。3回目には、ゼロから書く代わりにエージェントが生成したコードをレビューする習慣が身についていた。

Codexがメディア推論で置き換えられないもの

エージェントは動画を生成しない。エージェントは、動画を生成するAPIを呼び出すコードを生成する。これが常にぼやけている境界線であり、ぼやけることでアーキテクチャの意思決定にコストがかかる。

Codexはどの動画モデルがユースケースに合うかを選ばない。秒単位の料金とクレジットベースのサブスクリプションのどちらにするかも決めない。2026年9月24日のSora 2サンセットを乗り越えるフォールバック戦略も書かない。画像から動画か、テキストから動画かが、ユーザーが実際に必要としているものと一致するかどうかも教えてくれない。これらはあなたが下す決断だ。エージェントはその決断を実装する。決断を下すのではない。

ビルダーが実際に必要なAI動画アプリスタック

フロントエンド、バックエンド、ジョブキュー、ストレージ、モデルAPI

本物のAI動画アプリは5つの層で構成され、モデルAPIはその1つに過ぎない。

フロントエンド：プロンプト入力、アセットアップローダー、生成プレビュー、ジョブが3分かかっているときに嘘をつかないステータスインジケーター。
バックエンド（AIアプリバックエンド、最も時間を費やす場所）：APIサーフェス、バリデーション、モデレーション、ジョブ送信、ステータスポーリングまたはWebhook処理、進行中のものを追跡するデータベース。
ジョブキュー：動画生成は数ミリ秒ではなく数分かかる。同期呼び出しは生き残れない。
ストレージ：生成されたMP4はどこかに保存される——S3、R2、自分のCDN——そしてアプリがそのURLを記録する。
モデルAPI：実際の動画生成エンドポイント。Sora 2、Veo 3.1、Kling 3.0、Runway、Seedance——1つ選ぶか、複数にルーティングするか。

Codexは1〜4層をスキャフォールドする。5番目が問題だ。

画像生成APIと動画生成APIの位置づけ

ほとんどの動画アプリには両方が必要だ。画像生成は、サムネイル、参照フレーム、画像から動画へのパイプラインでの最初フレームのコンディショニング、またはユーザーが提供した静止画に使われる。現在のOpenAIの選択肢はgpt-image-2であり、OpenAI画像APIドキュメントに記載されている。動画については、直接ベンダーAPI（OpenAI Videos、Google Veo、Kling、Runway）または複数のバックエンドにルーティングするアグリゲーションプラットフォームがある。

これが重要な理由：画像生成は秒単位で動作し、画像ごとに課金される。動画生成は分単位で動作し、出力の秒単位で課金される。レート制限が異なり、レイテンシプロファイルが異なり、コストモデルが異なる。バックエンドは両方を処理しなければならず、同じ種類の呼び出しとして扱うとキューロジックが間違ったものになる。

ワークフローの設計方法

プロンプト受付とアセットアップロード

ユーザーがプロンプトを送信する際、オプションで参照画像や開始フレームが含まれることがある。リクエストがバックエンドを離れる前に正しく処理すべき3つのこと：

入力を検証する。 解像度の制約、アスペクト比の制限、ファイルサイズ。モデルは必ずしも読みやすいエラーで不正な入力を拒否する。
最初にモデレーションを実行する。 OpenAIの無料omni-moderationエンドポイントを使用する——テキストと画像を受け付け、コストゼロで、動画APIの呼び出しにお金を使う前にほとんどのポリシー違反を止める。
元の入力を保存する。 生成が失敗した場合、ユーザーに再アップロードさせることなく別のモデルに対してリトライするために元のものが必要になる。

画像から動画またはテキストから動画へのモデルルーティング

ほとんどの動画モデルは両方のモードをサポートしているが、それらの間の品質差はプロバイダによって異なる。ルーティングロジックはこれをエンコードする場所だ。

シンプルな版：入力タイプでルーティングする。ユーザーが参照画像を添付した場合、画像から動画モデルに送る。純粋なテキストプロンプトの場合、テキストから動画モデルに送る。

より成熟した版：ユースケース（短いソーシャルクリップvsより長いナラティブショット）、コスト予算（ドラフト層vs最終レンダリング）、レイテンシ要件でルーティングする。これは経年劣化しにくい層だ——各ルートの裏にあるモデルは変わるが、ルーティングロジックはほとんど変わらない。

非同期生成、リトライ、ステータスコールバック

動画生成は本質的に非同期だ。ジョブを送信してIDを受け取り、ポーリングするかWebhookを待つ。両方に対応してビルドする——一部のプロバイダはどちらか一方しかサポートしていない。ワーカー層が必要なもの：

ジッターを伴う指数バックオフリトライ。フリートからの同期リトライは同時に同じレート上限に達し、障害を悪化させる。
pending、running、succeeded、failed-retryable、failed-permanentを区別するステータスステートマシン。すべての失敗を同じように扱うことで予算を燃やしてしまう。
ジョブごとのタイムアウト。上限がないと、プロバイダの問題後にジョブが永遠にスタックする。

計画すべき本番リスク

キューレイテンシ、生成失敗、フォールバックモデル

生成失敗率はゼロではなく、プロバイダ、負荷、プロンプトの内容によって異なる。ジョブの無視できない割合が失敗することを計画する。

必要になる前にフォールバックパスをビルドする。プライマリ動画生成APIがエラーを返した場合、ワーカーは最小限のコード変更で2番目のプロバイダに対してリトライすべきだ。

プロバイダごと、モデルごとのレイテンシを追跡する。その数字は時間とともに変化し、特にピーク時に変化する。p95レイテンシがタイムアウトを超え始めると、ダッシュボードよりも先にユーザーが失敗を見ることになる。

コスト管理とAPIキーセキュリティ

動画生成はあっという間に高額になる。10秒のクリップが$0.30/秒なら$3だ。1日1,000本生成すれば、ストレージを除いて月$90,000になる。デフォルトの失敗モードは無制限の支出だ。

早期にビルドする価値があるコントロール：

ユーザーごとの生成クォータ。 無料枠、有料枠、日次上限、月次上限。通知付きのソフトリミット、ブロック付きのハードリミット。
環境ごとのAPIキー分離。 開発、ステージング、本番。1つをローテーションしてもプロダクトを止めないように。
プロジェクトスコープのキーで、どの機能がどの予算を使っているかを確認できる。
Codexが生成したリポジトリにAPIキーを入れるときは、必ず.envテンプレートと.gitignoreエントリを付ける。 エージェントは求めればこれらをスキャフォールドするが、常に自発的にやってくれるわけではない。Codexの自律シェル環境内のキーは、あなたのアカウントができることを何でもできる。

メディア推論プラットフォームを使うべきタイミング

直接モデルAPIvsアグリゲーション層

モデル層には2つのアーキテクチャ選択がある。各ベンダーのAPIを直接呼び出す。または、1つのインターフェースを通じて複数のモデルAPIを公開するアグリゲーションプラットフォームを呼び出す。

直接接続は完全なコントロール、完全なベンダー関係、最新機能への早期アクセスを提供する。コストはインテグレーションのオーバーヘッドだ：各ベンダー（OpenAIの動画エンドポイント、GoogleのVeo APIドキュメント、Klingのもの、Runwayのもの）には独自の認証、リクエスト形状、エラーコード、Webhook形式がある。4つの直接インテグレーションを維持することは、おおよそ半人月の工数だ。

アグリゲーションはそのコントロールの一部をサーフェスエリアの削減と引き換えにする。1つのAPIキー、1つのリクエスト形状、プラットフォームがベンダーの違いを処理する。トレードオフ：機能が遅れる可能性があり、アグリゲーターの稼働時間に依存し、課金マークアップが適用される。

モデル切り替えに1つのAPIが重要な理由

動画スタックでの切り替えコストは人々が期待するよりも高い。異なる出力寸法、異なるパラメータロジック、異なる非同期パターン、異なる課金単位。維持している直接インテグレーションのすべては、モデルを交換するときに変更しなければならないコードベースの一部だ。

AI動画アプリ開発計画に「3ヶ月後に別のモデルを試すかもしれない」が含まれているなら、統一APIパスは再インテグレーションの作業を節約する。計画が「モデルを選んで変更しない」なら、直接インテグレーションの方がクリーンだ。変更頻度にアーキテクチャを合わせる。

FAQ

AI動画アプリとは何か？

ローカルで実行するのではなく、APIを通じてアクセスするAIモデルを使用して、ユーザー入力——テキストプロンプト、参照画像、またはその両方——から動画を生成するアプリケーション。フロントエンドがプロンプトを収集し、バックエンドが動画モデル（Sora 2、Veo、Kling、Runway、Seedance）に生成ジョブを送信し、非同期ワーカーが待機を処理し、生成されたMP4が保存されて配信される。2026年のほとんどのAI動画アプリは、モデルが合理的な速度でコンシューマーハードウェア上で実行するには大きすぎるため、ホストされたモデルAPIを使用している。

CodexはAI動画生成アプリを単独でビルドできるか？

アプリケーションコード——フロントエンド、バックエンド、キューロジック、動画APIとのインテグレーション——をビルドする。推論はビルドしない。動画生成自体は、別途呼び出して支払うホストされたモデルAPIで動く。Codexは退屈な半分を圧縮する。興味深い半分——モデル選択、コスト管理、本番の耐障害性——は人間の問題として残る。

本番でAI動画APIを使用する前に開発者が注意すべきことは？

3つある。プロバイダの廃止カレンダー（Sora 2 Videos APIは2026年9月24日にサンセット——それを基にビルドしているなら移行計画が必要だ）。モデルごとの失敗率とレイテンシ変動——ゼロではなく、変化する。生成秒ごとのコストに期待トラフィックを掛けたもの——デフォルトの失敗モードは無制限の支出だ。

ビルダーが直接モデルAPIの代わりに推論プラットフォームを使うべきタイミングは？

モデルを切り替えることを期待しているとき、または2つ以上のプロバイダを並行して実行するとき。複数の直接インテグレーションのメンテナンスコストは積み重なる。アグリゲーション層はいくらかのコントロールをインテグレーションオーバーヘードの削減とモデル交換の容易さと引き換えにする。1つのプロバイダにコミットしているなら、直接インテグレーションの方がクリーンだ。ロードマップにプロバイダ間の評価やフォールバックが含まれているなら、統一層はすぐに元が取れる。

まとめ

コーディングエージェントを使ったAI動画アプリ開発は、1年前より速くなり、人々が思うよりアーキテクチャが難しくなった。エージェントはかつて1週間のタイピングが必要だった部分を処理する。残るもの——モデル選択、非同期ワークフロー設計、フォールバック戦略、コスト管理、APIキーの衛生管理、廃止カレンダー——はそこに作業が存在する場所だ。

今日から始めるビルダーへ：Codexを使ってAIアプリバックエンド、フロントエンド、キュー、インテグレーション層をスキャフォールドする。先週リーダーボードのトップに立ったモデルではなく、ユースケースに基づいてプライマリ動画生成APIを選ぶ。初日からモデル交換を前提にアーキテクチャを設計する。トラフィックが想定を超える前にコストを上限設定する。

ここで私のデータは終わる。残りはドキュメントに照らして検証する必要がある。続きはまた。

前回の投稿：