Gemini Omni 1.2 Flash 選定チェックリスト：入力モード、仕様、予算

このチェックリストで確認する内容

gemini-omni-1.2-flash は HiAPI 経由で公開されています。選定時にはまず次の4点を確認します。入力モードが自社の素材パイプラインをカバーしているか、仕様パラメータが製品の制約を満たしているか、予算を解像度と長さに基づいて明確に算出できるか、そしてどのような効果が保証範囲外か、です。以下のチェックリストは現在公開されている能力のみを記載しており、競合製品の実測やランキングは含みません。

入力モード：4つの利用可能な経路と排他ルール

現在公開されている入力モードは次のとおりです：

• テキストから動画：prompt のみで動画を生成します。
• 先頭フレーム画像から動画：first_frame_url で開始画面を指定し、その画面を動かします。
• 先頭・末尾フレーム間の遷移：first_frame_url と last_frame_url を同時に指定し、先頭と末尾の画面の間の遷移を生成します。このモードは最長10秒で、negative_prompt や system_prompt を併用できません。
• 参照画像から動画：image_urls で 1〜10 枚の公開 HTTP(S) 参照画像を渡し、スタイルや主体を制約します。1枚だけ渡した場合でも参照画像であり、先頭フレームではありません。

排他の境界には特に注意が必要です。image_urls は first_frame_url/last_frame_url と排他です。last_frame_url は first_frame_url に依存し、単独では使用できません。first_frame_url は開始画面を単独で指定できます。すべての画像パラメータは公開 HTTP(S) URL のみを受け付け、Base64 には対応しません。

提供されていない機能には、動画編集、動画の続き生成、動画または音声の入力、seed があります。これらが必要な場合は、本モデルを候補に含めるべきではありません。

仕様パラメータ：必須項目、デフォルト値、ハード制約

prompt は唯一の必須項目で、空でなく、最大 20000 文字である必要があります。その他のパラメータは必要に応じて設定します：

• duration：整数、3〜15 秒、デフォルト 10 秒。
• resolution：360p、720p、1080p、4k、デフォルト 720p。1080p と 4k はアップスケール出力です。4k には音声トラックが含まれない場合があります。
• aspect_ratio：16:9 または 9:16、デフォルト 16:9。

先頭・末尾フレームモードでは、最長10秒という制限に加え、negative_prompt や system_prompt を同時に使用できません。参照画像モードは 1〜10 枚という枚数と URL 形式の制約を受けます。これらの制約を製品のパラメータ検証に組み込むほうが、呼び出し失敗後に補修するより手間がかかりません。

予算：解像度別単価 × リクエスト時間 × 本数

現在のデフォルト倍率の料金は解像度別に設定されています：

• 360p：$0.0229/秒
• 720p：$0.0343/秒
• 1080p：$0.0343/秒
• 4k：$0.0800/秒

予算 = 選択した解像度の単価 × リクエスト時間 × 本数。実際の請求額と適用倍率が優先されます。ファイルコンテナ内の秒数（例えば小数秒）から課金を逆算しないでください。リクエスト時間は動画ファイルのメタデータではなく、duration パラメータに基づいて計算してください。

2種類のコストイベントを区別する必要があります。成功したが不満足な場合はタスクを再作成する必要があり、予算が増えます。実際の失敗はプラットフォームの返金規則に従って処理されます。すべての失敗が返金される、あるいはされないと決めつけず、実際の請求額を基準にしてください。ネットワークタイムアウト時は直接タスクを重複作成せず、まず既存タスクを照会し、同じリクエストが二重に課金されるのを避けてください。

保証されない項目：これらの効果は自社で検収が必要

公開されている能力は効果の約束ではありません。現在、各モードに音声が付くこと、リップシンク、文字の正確性、主体やブランドの完全一致は保証されていません。1080p と 4k はアップスケール出力で、4k には音声トラックが含まれない場合があります。選定時にパラメータページから品質、所要時間、コスト優位性を推測しないでください。実測データがない場合、競合製品の横断比較やランキングを捏造してはいけません。

自社サンプルで検収：品質、ターンアラウンドタイム、適用コスト

同一の prompt、同一の参照画像または先頭フレーム画像を用いて、テキストから動画、先頭フレーム画像から動画、先頭・末尾フレーム間の遷移、参照画像から動画を（該当する場合）それぞれ実行し、次の3グループの結果を記録することをお勧めします：

• 品質：典型的なシナリオで、生成何回に1回がそのまま使用できるか。最良の1本だけを見ないこと。
• ターンアラウンドタイム：タスク投入から使用可能な結果を得るまでの所要時間。必要なリトライと照会を含む。
• 適用コスト：解像度、長さ、本数に基づいて予算を計算し、成功したが不満足だったやり直し分も含める。単価だけを見ないこと。

検収時は入力とパラメータを固定し、項目ごとに記録し、異なる解像度、異なる長さ、異なる入力モードの結果を混ぜて比較しないでください。自社のサンプルのみが、このモデルが自社製品に適しているかを示すことができます。

導入前のチェック項目

• 製品が動画編集、続き生成、動画または音声入力、seed を必要としていないか？必要なら本モデルは不適切です。
• 素材パイプラインが公開 HTTP(S) 画像 URL を提供できるか？Base64 しかない場合は、アップロードとホスティングの改修が必要です。
• image_urls と先頭/末尾フレームパラメータを同時に使用していないか？両者は排他であり、パラメータ検証層でブロックする必要があります。
• 先頭・末尾フレームモードの長さが10秒を超えていないか、negative_prompt や system_prompt を誤って併用していないか？
• 予算を解像度単価 × リクエスト時間 × 本数で計算し、成功したが不満足によるやり直し分の枠を確保しているか？
• ネットワークタイムアウト時に、直接重複作成するのではなく、まず既存タスクを照会しているか？

HiAPI の統一インターフェースを通じて、上記のチェックリストに沿って小規模サンプルで検収してから、本番導入を決定できます。選定の根拠は、実測していない比較結論ではなく、自社で測定した品質、ターンアラウンドタイム、適用コストであるべきです。