【ITニュース解説】Building Wan 3.0: The Hard Parts of an AI Video Workspace

AIを活用したサービス、特に動画生成のような複雑な処理を行う製品は、一見すると非常にシンプルに見える。ユーザーはテキストを入力し、「生成」ボタンをクリックするだけで、AIが自動的に動画を作り出してくれる。しかし、このようなシンプルなインターフェースの裏側では、目に見えない多くの複雑なシステムが動いている。今回解説する「Wan 3.0」というAI動画ワークスペースも、まさにその典型だ。システムエンジニアを目指す皆さんにとって、この裏側の工夫を知ることは、将来のシステム設計に役立つはずだ。

Wan 3.0のようなサービスでは、ユーザーからの「動画を作ってほしい」というリクエストが、ブラウザのタブを閉じた後も生き続ける必要がある。また、外部のAI提供サービス（プロバイダー）が途中で失敗したり、リトライによって意図せず二重に料金が発生したりする可能性もある。さらに、テキスト、画像、フレームなど、様々な形式の入力に対応し、複数のAIモデルを使い分け、使用量に応じた料金体系を管理する必要がある。これらの課題を解決するために、どのようなエンジニアリングの工夫がされているのかを見ていこう。

まず、ユーザーが動画を生成する際、入力形式は一つではない。例えば、テキストから動画を作る場合と、手持ちの画像から動画を作る場合では、必要な情報が大きく異なる。テキストからの動画生成では「プロンプト（指示文）」「アスペクト比」「解像度」「動画の長さ」が必要だが、画像からの動画生成ではこれに加えて「元となる画像ファイル」が必要になる。さらに、二つの画像を滑らかにつなぐ「フレーム遷移」や、既存の動画クリップや画像群を参考に新しい動画を作る「参照ベースの生成」など、様々な生成方法がある。それぞれ対応しているAIモデルも異なる。

Wan 3.0では、これらの異なる生成方法を「シーン」として明確に区別している。例えば、「テキストから動画」「画像から動画」「フレームから動画」といった具合だ。それぞれのシーンと、そのシーンで必要となる入力項目をAIモデル側が宣言する仕組みになっている。これにより、ユーザーインターフェースは選択されたワークフローに合わせて必要な入力欄だけを表示し、サーバー側も、AIプロバイダーにリクエストを送る前に、入力内容が正しいか、サポートされていない組み合わせではないかをチェックできる。この早期の入力チェックは非常に重要で、もしAIプロバイダーに送った後にエラーになった場合、処理に時間がかかり、エラーの原因も分かりにくく、場合によっては余計なコストが発生してしまうからだ。

次に、AIプロバイダーとの連携の課題がある。Wan 3.0は、動画生成を外部の様々なAIプロバイダーに依頼するが、これらのプロバイダーのAPI（システムとやり取りするための窓口）は、驚くほどバラバラだ。例えば、リクエストを送る際のパラメーターの名前、処理が終わったことを知らせる方法（すぐに結果を返す、定期的に問い合わせるポーリング、結果が出たら通知するウェブフックなど）、エラーや成功のステータス表示、結果のデータ形式など、全てがプロバイダーごとに異なる。

もしこれらの違いをそのままWan 3.0のシステム全体に反映させてしまうと、新しいプロバイダーを追加するたびに多くの部分を修正する必要が出てきてしまう。そこでWan 3.0では、各プロバイダーのAPIの周りに「アダプター」と呼ばれる小さな仲介役を置いている。このアダプターが、それぞれのプロバイダーの異なる仕様をWan 3.0の内部で統一された形式に変換してくれる。これにより、Wan 3.0のコアとなるアプリケーション部分は、プロバイダーごとの違いを意識することなく、一貫した方法でタスクを管理し、結果を受け取ることができる。AIモデル自体が持つ機能の違いは残るが、システムの複雑さを大幅に減らすことができるのだ。

動画生成のような処理は、完了までに時間がかかることがほとんどだ。ユーザーがブラウザを開いたまま、何分も、場合によっては何時間も待たせるのは現実的ではないし、途中でネットワークが切れたりブラウザを閉じたりすれば、せっかくのリクエストが無駄になってしまう。Wan 3.0では、このような動画生成のリクエストを「耐久性のあるタスク」として扱っている。

具体的には、ユーザーが生成ボタンを押すと、そのリクエストはすぐに「タスク」としてシステムに記録される。このタスクには、「ペンディング（待機中）」「プロセシング（処理中）」「サクシード（成功）」「フェイルド（失敗）」「キャンセル（中止）」といった状態が設定されている。AIプロバイダーが処理を完了すると、その結果がタスクの状態に反映される。ユーザーは一度ブラウザを閉じても、後で再びアクセスすれば、自分の生成した動画タスクが今どの状態にあるかを確認できる。この仕組みによって、システム側もユーザー側も安心して非同期な処理を進めることができる。また、タスクを永続的に記録しておくことで、どのモデルが使われ、どのプロバイダーが処理し、いくら費用がかかったか、いつ開始し終了したかといった、後で振り返るための貴重な情報も残る。

有料のAIサービスにおいて、最も重要な課題の一つが、ユーザーが意図せず二重に請求されてしまうことを防ぐことだ。ユーザーが生成ボタンを誤って二度クリックしたり、ネットワークの瞬断によって同じリクエストがサーバーに複数回届いたりすることはよくある。このような場合でも、「おそらく一回だけ」という曖昧な保証では不十分だ。

Wan 3.0では、「べき等性」という考え方を用いてこの問題を解決している。これは、同じ操作を複数回実行しても、一度だけ実行したのと同じ結果になることを保証する性質だ。具体的には、すべての生成リクエストに「べき等性キー」という一意の識別子を付与する。さらに、リクエストに含まれるモデル、シーン、検証済みのパラメーター情報から「フィンガープリント」という一意の値を計算する。もし、同じべき等性キーを持つリクエストが再び送られてきた場合、システムはまずそのフィンガープリントをチェックする。もしキーとフィンガープリントの両方が前回と同じであれば、それは同じ操作の重複とみなし、既存のタスクを再利用する。もしキーは同じでもフィンガープリントが異なる場合は、それは別の操作を誤って同じキーで送ってしまったと判断し、リクエストを拒否する。この二重のチェックによって、ユーザーは安心してリトライできるし、意図しない二重生成や二重請求を防ぐことができる。

料金体系についても重要な設計がある。従量課金制のサービスでは、ユーザーに高価な操作を開始する前にコストを明確に示す必要がある。そして、そこで表示された見積もりと、実際に課金される金額が正確に一致しなければならない。Wan 3.0では、ユーザーが選択したモデルや設定（動画の長さ、解像度など）に基づいて、生成開始前に正確なクレジット（料金）を計算し表示する。

この計算されたコストと、その時点での料金設定のスナップショットは、生成タスクと一緒に保存される。これにより、もし後で料金設定が変更されたとしても、過去のタスクにかかった費用が不正確になることはない。さらに重要なのは、タスクの作成とクレジットの予約（ユーザーの残高から料金を引くこと）を、データベースの「トランザクション」という仕組みを使って一度に行うことだ。トランザクションとは、一連の操作がすべて成功するか、一つでも失敗したらすべて元に戻すという「アトミック性」を保証する仕組みだ。これにより、「クレジットは引かれたのにタスクが作成されなかった」とか、「タスクはできたのにクレジットが引かれていない」といった、ユーザーにとってもシステム管理者にとっても困る状況を完全に防ぐことができる。

最後に、外部サービスでの生成が失敗した場合の返金処理についても、きめ細やかな設計がされている。AIプロバイダーでの処理は、途中でタイムアウトしたり、何らかの理由で失敗したりする可能性がある。また、失敗したことを通知するウェブフックが複数回送られてくる可能性もある。このような場合でも、返金処理が確実に行われ、かつ重複して実行されても問題ないように設計する必要がある。

Wan 3.0の返金処理は、まず該当するタスクのレコードをロックし、そのタスクがすでに処理済みか、あるいは返金済みではないかを確認する。その上で、返金を示すトランザクションを記録し、ユーザーのクレジット残高を元に戻し、タスクを返金済みとしてマークする。これら一連の処理も、全てデータベースのトランザクション内で行われる。目標は「とりあえず返金してみる」ではなく、「クレジットを予約した失敗した生成は、失敗の通知が複数回届いたとしても、一度だけ正確にクレジットを復元する」という厳密な保証だ。このような裏側の複雑な仕組みがあるからこそ、ユーザーは「失敗した生成で勝手にお金が引かれることはない」という安心感を得られるのだ。

このように、AI動画ワークスペースを構築する作業は、予測不可能な要素（処理の遅延、プロバイダーの変更、変動するコスト、重複リクエスト、部分的な失敗など）をいかに管理するかに尽きる。ユーザーが見るシンプルなプロンプト入力画面は、その背後にあるタスク管理、プロバイダー連携、そして料金管理のシステムが、それぞれ明確なルール（契約）に基づいて設計されているからこそ、シンプルで信頼できるものとして機能するのだ。システムエンジニアを目指す皆さんにとって、このような「裏側の仕組み」を理解し、設計できる能力は非常に重要となるだろう。