wan2.7-image-standard 導入ガイド：能力の境界、API パラメータと価格実践

このモデルが解決する課題と、担わない領域

wan2.7-image-standard は Alibaba が提供する画像生成モデルで、出力タイプは画像です。能力範囲は明確に 2 種類のタスクに限定されます：テキストから画像（text-to-image） と 画像から画像（image-to-image） です。言い換えれば、テキスト記述を 1 枚の画像に変換すること、あるいは既存の画像をベースに制御された再生成を行うことが得意で、この 2 つの経路がコンテンツ制作、素材補完、スタイル調整のほとんどのシーンをカバーします。

事前に明確にしておくべきは、何をカバーしないかです。画像編集における局所再描画（inpainting）、マスク外拡張（outpainting）、超解像拡大、背景切り抜きなどのタスクは、この 2 つの能力には含まれません。ビジネスフローでこれらの工程の比率が高い場合は、それらに個別にモデルを選定すべきで、1 つのモデルで全部をまかなおうとすべきではありません。動画生成や 3D アセット生成もその範疇ではありません。

したがって、導入判断は次の 3 つの問いに簡略化できます：

• 中核となるニーズは「テキストや参照画像から 1 枚の新しい画像を得る」ことか？そうであれば候補になります。
• ピクセル単位の局所編集能力が必要か？必要であれば、別のモデルを用意する必要があります。
• 下流が生成結果のサイズや内容に厳しい制約を課しているか？これが画像から画像の経路でどれだけ前処理が必要かを決めます。

境界を明確にしてからパラメータとコストを論じれば、「まず導入してから使えないと気づく」という手戻りを避けられます。

枚数課金が意味するもの

wan2.7-image-standard は枚数課金の方式を採用しています：1 枚の画像を正常に生成するごとに 1 回分の費用が発生します。この方式自体は直感的ですが、予算への実際の影響は単価そのものではなく、呼び出し戦略によって決まります。

重要な変数は 3 つあります：

• 複数候補画像：同じ prompt に対して複数の候補をリクエストしてから選ぶ場合、それぞれがコストに計上されます。候補数が倍になれば、1 回のリクエストのコストも倍になります。
• 失敗リトライ：タイムアウト、パラメータエラー、コンテンツが不適切と判定された後のリトライは、有効な出力が発生した時点でコストとして累積します。エンジニアリング上のリトライ戦略が積極的であるほど、予算の見積もりは難しくなります。
• 段階リリースと負荷テスト：リリース前の比較テストや A/B 実験は実際に画像を生成します。この部分は予算から漏れやすいです。

簡単なコストモデルを構築します：月間推定コスト ≈ 1 日あたりの有効リクエスト数 × 1 リクエストあたりの平均生成画像数 × 30。ここでの「1 リクエストあたりの平均生成画像数」には、候補画像とリトライの成功率を折算して含める必要があり、理想的な 1 ではありません。

高頻度呼び出しのシーンでは、ビジネス側で 1 日の生成上限を設定し、同じ prompt の結果をキャッシュすることを推奨します。同じ入力の短時間での重複リクエストはデモ、リプレイ、テスト環境で非常によくあることで、キャッシュによってこの部分のコストを直接消し去れます。具体的な単価と最新の課金方式はサイトの価格パネルを基準とし、本文や過去のメールに記載された数字を長期的な予算の根拠にしないでください。

導入前のパラメータと呼び出しチェックリスト

HiAPI.ai の統一インターフェースで wan2.7-image-standard を呼び出すには、結合テスト前にインプットとアウトプットの方式を確定しておく必要があります。そうでなければ細部で度々手戻りが発生しやすくなります。

入力側で確認すべき要素

• prompt 表現の規範：まず目標言語の記述でベースラインテストを行い、長い記述、否定文、スタイル語に対するモデルの実際の反応を確認してから、prompt のテンプレート化を行うかを決めます。チーム内部で prompt の約束事（主体、シーン、スタイル、ネガティブ制約の順序）を維持し、個人の書き方の違いによる効果のばらつきを減らすのが望ましいです。
• タスクタイプ：テキストから画像と画像から画像の呼び出しを明示的に区別し、画像から画像では入力画像を必ず提供します。参照画像を prompt に混ぜてテキスト記述で代替しないでください。
• サイズと比率：モデルがサポートするサイズ範囲を確認し、ビジネス側でよく使う比率（縦版、方版、横版など）を数段階に固定します。毎回のリクエストで任意のサイズを使うと、その後のレイアウトやストレージのロジックが複雑になります。
• 入力画像の形式と容量：画像から画像の経路では、受け入れ可能な形式、解像度の上限、ファイルサイズを明確にし、必要に応じて呼び出し前にローカルで圧縮や形式変換を行います。

出力側で確認すべき要素

• 返却結果の形態：アクセス可能な画像リソースを直接返すのか、追加でダウンロードして保存する必要があるのか。これにより、呼び出し層に「画像取得＋保存」の関数をカプセル化する必要があるかが決まります。
• 結果の有効期限：一時リンクが返される場合、有効期限内に転送保存を完了しなければデータが失効します。この点はリリース前に必ず実測してください。
• エラーとレート制限の返却構造：エラーコードのフィールドを事前に確認し、クライアント側で分類処理できるようにします。すべての失敗を同じ種類の例外としてリトライしないようにしてください。

上記の要素を導入チェックリストとしてまとめ、結合テスト時に項目ごとにチェックすることを推奨します。事後の調査よりもはるかに時間を節約できます。

画像から画像のフローにおけるエンジニアリングの注意点

画像から画像はテキストから画像よりも入力処理のチェーンが 1 段階多く、エンジニアリングの複雑さも主にここに集中します。

入力の前処理

参照画像がモデルにそのまま渡せる理想的な素材であることはまれです。一般的な処理には、モデルがサポートする形式への統一、解像度を適切な範囲に調整、必要に応じて目標比率へのクロップなどがあります。前処理はサーバー側で完了させ、冪等性を確保して、同じ原画像が繰り返し処理されないようにします。同時に、原画像と処理後の画像の対応関係を保持し、効果の追溯を容易にすることを推奨します。

一貫性の検証

画像から画像の核心的な期待は「参照画像の一部の特徴を保持しつつ、prompt に従って変化させる」ことです。リリース前に何をもって合格とするかを定義する必要があります：主体が保持されているか、構図が近いか、スタイルの偏移が許容できるか。一般的な方法は、サンプリングによる人手評価に軽量な自動指標（元画像との類似度の閾値など）を加えて一次スクリーニングを行い、明らかに逸脱した結果を堰き止めて、人手で確認する量を減らすことです。

入力コンテンツのコンプライアンス前置

参照画像がユーザーアップロードによる場合、モデルを呼び出す前に一度コンテンツ検証を行う必要があり、明らかに不適切な入力を生成工程に送り込まないようにします。この層は生成後ではなくサーバー側に置く方がコストを抑えられ、業務フローにも適合します。

メタデータの保存

各生成結果には、元の入力画像の識別子、prompt、サイズ、モデル名、呼び出し時刻を記録することを推奨します。画像から画像の結果は入力と強く結びついており、このメタデータがなければ、後の問題の再現も効果の帰属分析も難しくなります。

比較負荷テストでどのタスクを担うかを決める

導入するかどうかの判断は、「既存案を全面的に置き換える」という考え方ではなく、候補モデルプールに入れてタスクタイプ別にグループ化して負荷テストを行い、どのタスクでコストパフォーマンスが最も高いかを見ることを推奨します。

グループ化の方法

入念に選んだ美しい prompt ではなく、業務の実際の分布に従ってテストセットを分割します：

• テキストから画像：商品画像、イラスト風素材、シーンコンセプト画像など、実際のカテゴリ別にグループ化。
• 画像から画像：参照画像の比率、スタイル転移の幅度、主体の複雑さをそれぞれ数段階に分ける。
• 難易度の層別：簡単な記述、長い記述、具体的な文字要求を含む記述、複雑な空間関係を含む記述を分けて集計。

評価軸

• 可用率：初回の結果が修正なしで使用できる割合。これが実際のコストを最も反映する項目です。
• 一貫性：同じ prompt を複数回呼び出した結果の安定度。ユーザー体験に影響します。
• 画像から画像の忠実度：参照画像の特徴保持と prompt への追従のバランス。
• エンドツーエンドの遅延と失敗率：非同期キューが必要かどうかを決めます。

組み合わせの結論

モデルの結果と既存案を同じテストセットで揃えて採点すると、通常は「ある種のタスクでは明らかに良い、ある種では同等、少数のシーンでは既存案に劣る」という分布が現れます。結論はタスクの割り当てルールとして書くべきです：どのタスクを wan2.7-image-standard にルーティングするか、どのタスクは元の案を維持するか、あるいは別のモデルを選ぶか。これによりリリースリスクが最小になり、その後の個別調整も容易になります。

画像呼び出しをエンジニアリングチェーンに組み込む

モデルの効果はリリースの一部にすぎず、長期的な体験を実際に左右するのは呼び出し層のエンジニアリング化の度合いです。

リトライとタイムアウト

画像呼び出しには明確なタイムアウト上限を設定し、エラータイプ別に処理を分けます：ネットワーク系のエラーは指数バックオフでリトライ可能、パラメータ系のエラーは直接失敗としてアラートを出し、リトライしないようにします。リトライ回数には上限を設け、コスト監視と連動させます。リトライ率の異常な上昇は通常、チェーンの問題の早期シグナルです。

非同期とキュー

画像生成の所要時間は通常、一般的なテキストインターフェースより長くなります。ユーザー向けのシーンでは非同期を推奨します：タスクを投入し、タスク識別子を返し、ポーリングまたはコールバックで結果を取得することで、長い接続が引きずられるのを避けます。バッチ処理のシーンではキューでピークを削り、並列度を制限して、瞬間的なトラフィックによるレート制限がリトライを増幅させるのを防ぎます。

結果の保存

生成結果は有効期限内に自社のオブジェクトストレージへ転送保存し、メタデータ（prompt、タスクタイプ、サイズ、モデルバージョン、タイムスタンプ）を記録する必要があります。ストレージ層ではコンテンツの重複排除を行い、同じ入力の結果を再利用できるようにすると、ストレージと呼び出しの両方を節約できます。

コストと品質の監視

リリース後は 3 組の指標を継続的に追跡します：1 日の生成画像数、失敗とリトライの比率、人手による手戻りの比率。最初の 2 つはコストに対応し、3 つ目は品質に対応します。手戻り比率が上昇しているのに生成が安定している場合、業務の入力分布が変わったことを意味することが多く、prompt の規範やタスク割り当てルールを再評価する必要があります。

モデルの能力、枚数課金のコスト方式、エンジニアリングチェーンをまとめて見ることで、導入判断は一度きりの効果比較ではなく、持続的に運用できる方案になります。モデルのパラメータ詳細と最新の課金方式を確認する際は、HiAPI.ai のモデルページと価格パネルを基準にしてください。