OmniHuman-1.5 プロンプトレシピ：そのままコピー＆ペーストできる話者アバター動画プロンプト

プロンプト構造が言い回しより重要な理由

ほとんどのチームは最初の話者アバタープロンプトを一文だけで書き、それから何時間も言い換えを繰り返して魔法のようなフレーズを探そうとします。この方法が失敗するのは当然で、OmniHuman-1.5 が反応するのは巧妙さではなく仕様だからです。プロンプトとは短い動画の仕様書です。誰が出演するか、何を話すか、画をどう構図するか、台詞をどう演じるか。このうちどれか一つが欠けていたり、他の項目とごちゃ混ぜになっていたりすると、モデルは推測するしかなくなり、その推測こそが一貫性の問題の源になります。

有用なメンタルモデルは、プロンプトを一つの出力に供給する四つの積み重なったモジュールとして捉えることです。

• 主体——誰が出演するか、そして安定して記述できるレベルで彼らがどんな見た目か。
• 台詞——話すべき正確な言葉を、一字一句書き出す。
• 構図——ショットサイズ、カメラアングル、背景、そしてフレーム内の主体の位置。
• 演技——テンポ、エネルギー、トーン、そして台詞を朗読ではなく発話のように聞こえさせる小さな身体の動き。

これらを分離すれば、反復は制御可能になります。台詞を変えずに演技だけを変えたり、構図をやり直さずに主体記述を書き換えたりできます。すべてが一続きの流暢な文章に押し込まれていると、どの編集もグローバルな編集になり、出力の変化を入力の特定の変更に帰属させることが永遠にできません。

これは、表面上かなり異なって読める二つのプロンプトが似た結果を生む理由も説明します。それらは同じ四つのモジュールをエンコードしているのです。逆に、ほぼ同じに見える二つのプロンプトが大きく異なることもあります。一方が静かにあるモジュールを欠いているからであり、たいていは演技——人々が書き留めるのを最も忘れがちな部分——です。

このガイドのレシピはすべて同じ四つのモジュールに基づいています。コピーし、改変し、そして意図的に分解して各モジュールが何をしているかを確認できるようにすることが狙いです。

始める前の注意

OmniHuman-1.5 のプロンプト処理方法は完全には公開されておらず、非公開のつまみは変わります。以下の各レシピは、でっち上げのパラメータ、重み構文、ベンダー固有のフラグを避けています。代わりに、主体・台詞・構図・演技についての平易で明示的な自然言語記述に依存しています。これによりレシピは移植性を保ち、存在しないかもしれない構文の上にパイプラインを築くのを避けられます。

あるレシピが、モデルが確実に従えないかもしれないもの——正確なタイミング、珍しい音素での正確なリップシンク、非常に長い台詞——を制約する必要がある場合、ガイドはそれを明示し、テキストに書けば実現すると期待するのではなく、プロンプトの外で処理することを勧めます。

これらのレシピをモデルごとの個別統合を寄せ集めるのではなく単一の統一 API で実行したいなら、HiAPI.ai の動画エンドポイントがここで述べるすべての対象パスです。

そのままコピー＆ペーストできるプロンプトの解剖

レシピの前に、それらが共通して従うテンプレートを見てみましょう。一度読めば、どれでも記憶から再構築できます。

[SUBJECT]
A [age range] [gender presentation] with [hair], [distinguishing feature],
wearing [clothing]. Natural, realistic appearance, no stylization.

[SCRIPT]
Say exactly: "<your script here>"

[FRAMING]
[Shot size] shot, [camera angle], [subject position in frame].
Background: [background description]. Lighting: [lighting description].

[DELIVERY]
Speaks at [pace]. Tone: [tone]. [Optional physical behavior cue].
Camera is static.

各フィールドをなぜこう書くのか、いくつか説明します。

主体

記述は安定して具体的に保ちます。年齢層、性別の見え方、髪型、際立つ特徴を一つか二つ、服装。形容詞を積み重ねるのは避けましょう。余分な修飾語の一つ一つが、モデルが複数回の実行間でドリフトしうるもう一つの点になります。複数のクリップで同じ人物を使う必要があるなら、このモジュールを一字一句凍結し、決して編集しないでください。

台詞

Say exactly（一字一句話す）というフレーズが実際に機能します。それは後続のテキストがシーン記述ではなく発話内容であることを示します。台詞は引用符で囲み、境界を明確にし、純粋な散文のままにします——舞台指示も、括弧書きの説明も、マークアップもなしです。

構図

ショットサイズ（クローズアップ、ミディアムショット、ミディアムワイド）、カメラアングル（アイレベル、わずかなローアングル）、主体位置（中央、フレームのやや左）はすべて普通の言葉で記述でき、いずれも出力を実質的に変えます。背景と照明もここに属します。それらはショットの一部であり、演技の一部ではないからです。

演技

このモジュールはほとんどの人が飛ばすものです。テンポ、トーン、そして一つの身体行動の手がかり（軽い頷き、一つのジェスチャー、姿勢の変化）は、主体記述を繰り返し書き直すよりも、知覚される自然さにはるかに大きく貢献します。手がかりは一つか二つに保ちましょう。それを超えると、モデルは選択を迫られます。

結びの制約

Camera is static（カメラは固定）で終わるのは、招かれざるカメラ運動——話者アバター生成でよくある気を散らす失敗パターン——を抑制する低コストの方法です。パラメータではなく普通の指示であり、レシピの一部です。

テンプレートに入れるべきでないもの

フレームレート、解像度、シード、モデルバージョン文字列をプロンプトテキストに書かないでください。それらはリクエストレベルの問題であり、プロンプトレベルの問題ではないので、混ぜるとプロンプトの diff が取りにくく再利用しにくくなります。内容はプロンプトに、インフラは API 呼び出しに任せましょう。

レシピ：単独解説クリップ

主力レシピ。ドキュメントのナレーション、コース内容、告知動画、そしてホストが用意した原稿を読むあらゆる場面に適しています。

[SUBJECT]
A person in their early 30s, gender-neutral presentation, short dark hair,
wearing a plain crew-neck sweater. Natural, realistic appearance, no stylization.

[SCRIPT]
Say exactly: "In this walkthrough we'll cover three things. First, how to set up
the project. Second, the configuration options that matter most. And third, how
to verify everything is working before you ship."

[FRAMING]
Medium shot, eye level, subject centered with a small amount of headroom.
Background: softly out-of-focus home office with a bookshelf.
Lighting: soft key light from the left, no harsh shadows.

[DELIVERY]
Speaks at a measured, conversational pace. Tone: friendly and instructional.
Occasional small nod on sentence boundaries. Camera is static.

なぜ機能するのか

台詞は一貫性を保てるくらい短く、およそ三文で、文の境界が明確です。構図は意図的に平々凡々としています。中央、アイレベル、柔らかな背景。ここでは平々凡々な構図が利点になります。複数回の実行間の出力差を識別しやすくするからです。もし背景が変わり始めたら、それがモデルの問題であり、あなたのショット記述の問題ではないと分かります。

演技モジュールは一つの身体の手がかり（文の境界での時折の軽い頷き）を与え、それが台詞の構造と自然に対応しています。この演技の手がかりと台詞の形の対応関係はコピーする価値があります。台詞のリズムに合う手がかりは自然に読め、それと衝突する手がかりはランダムに読めます。

改変する

• より長い台詞：同じ構図と演技を保ち、段落の境界で台詞を複数のクリップに分割します。一度の長い生成を強行しないでください。各クリップの構造が似ているほど、クリップ間の一貫性は保ちやすくなります。
• 異なるオーディエンス：トーンの語（「権威ある」、「温かい」、「軽快」）だけを変えて再実行します。これはレシピの中で最もてこの効く単一の編集です。
• ブランドペルソナ：主体モジュールを凍結し、服装だけを変えます。これにより服装を顔や髪——最もドリフトしやすいフィールド——から切り離せます。

既知の限界

非常に長い台詞——一度に何段落も——は、終盤に向かってリズムの一貫性を失いがちです。クリップごとに数文を計画し、エディタで組み立ててください。長さの問題をプロンプトにリズム指示を追加して解決しようとしないでください。プロンプトはタイムコントローラではありません。

レシピ：ショートソーシャルフック

ショート動画の生死は最初の二秒で決まります。このレシピは解説レシピの中立さと引き換えにエネルギーを得て、意図的に他のレシピより短くなっています。

[SUBJECT]
A person in their late 20s, wearing a casual button-up shirt.
Natural, realistic appearance, no stylization.

[SCRIPT]
Say exactly: "Stop scrolling. If you've ever shipped a feature that broke in
production, this is the one setting you probably missed."

[FRAMING]
Close-up shot, slightly below eye level, subject centered and filling most of
the frame. Background: simple solid-color wall. Lighting: bright, even, frontal.

[DELIVERY]
Speaks quickly with confident energy. Tone: direct and conspiratorial.
Leans in slightly on the first sentence. Camera is static.

参考にすべき設計上の選択

クローズアップとわずかなローアングルが親密さと一抹の切迫感を生みます。これはショート動画の視覚文法であり、完全に普通の構図言語で表現できます——特別な構文は不要です。

単色背景は速いテンポの編集と注意を争う視覚的ノイズを排除します。ショート動画では、背景は決して画面の面白い部分であるべきではありません。

最大二文。フックは一つの注意力ユニットであり、段落ではありません。あなたのアイデアが三文を必要とするなら、それは別のレシピに属します。

最初の文に合う一つの身体の手がかり。「最初の文でわずかに前傾する」が機能するのは、最初の文がフックだからです。手がかりをそれが属するビートと対にしてください。

改変する

同じ主体と構図で三つの異なるフック台詞を実行し、出力から選びます。台詞モジュール以外のすべてが凍結されているので、クリップ間の差異はライティングに帰属でき、それがフックの A/B テストでまさに望むことです。

既知の限界

非常に速い演技は、密集した技術用語では明瞭度を下げるかもしれません。フックに製品名、略語、読み上げる必要のある数字が含まれるなら、テンポの語を「quickly」から「briskly」に変えて比較してください。これは台詞を固定した後でも演技モジュールが第二ラウンドの調整を必要とするかもしれない唯一の箇所です。

レシピ：製品デモのナレーション

このレシピは製品 UI や一連のステップの上にナレーションを載せる場面向けで、明瞭さが個性より重要であり、観客の目が追いつけるようテンポに余白を残す必要があります。

[SUBJECT]
A person in their mid 30s, wearing a neutral blazer over a plain shirt.
Natural, realistic appearance, no stylization.

[SCRIPT]
Say exactly: "Open the settings panel from the left navigation. Choose the
integration you want to connect. Paste your key into the credential field.
Then save, and run a test call from the same screen to confirm the connection."

[FRAMING]
Medium close-up, eye level, subject positioned slightly left of center to leave
room on the right of frame. Background: clean, uncluttered neutral wall.
Lighting: soft, even, no rim light.

[DELIVERY]
Speaks slowly and evenly, with a brief pause at each step boundary.
Tone: calm and precise. Minimal movement. Camera is static.

最も重要な構図の手がかり

「中央よりわずかに左、フレームの右側に余白を残す」はこのレシピで最も重要な一行です。デモはしばしば画面録画や UI オーバーレイと合成され、オフセンターの構図がエディタにそれらを置く場所を残します。プロンプトでは何のコストもかからず、再レンダリングを一回節約できます。

構造的指示としてのテンポ

「各ステップの境界で短い停止」は時間パラメータではなく構造についての指示です。それは台詞に四つの単位のリズムがあることをモデルに伝えます。ミリ秒を指定しているのではなく、ビートがどこにあるかを伝えているのです。台詞のステップ数は少なく、対応関係を明確に保ちましょう。台詞に六つのステップがあり、演技が境界での停止に触れていても、それは依然として一つの指示であり、依然として読めます。

改変する

• マルチセグメント：各ステップを同じ主体と構図モジュールを使って自分のクリップとしてレンダリングし、つなぎ合わせます。これによりクリーンなカットポイントとシーケンス全体での外観の一貫性が得られます。
• オーバーレイ駆動の編集：あるステップが口頭の台詞より長い視覚的ビートを必要とするなら、演技指示を引き延ばすのではなく、末尾に無音のクリップを追加します。無音はポストプロダクションの問題です。

既知の限界

停止は要求であり、保証ではありません。正確な停止位置が画面の動きとの同期に極めて重要なら、エディタで調整し、生成クリップをカット時間以外のすべてについての音声・映像の真実の源として扱う予定を立ててください。

レシピのテストと反復

レシピは仮説です。規模を拡大する前に検証しましょう。

ステップ 1：テスト台詞を書く

短い台詞——二、三文——を用意し、実際の内容の中で難しい部分をカバーします。最も長い単語、最も珍しい固有名詞、実際に話す数字。テスト台詞は迎合的ではなく対抗的であるべきです。モデルが楽に処理するテスト文は何も教えてくれません。

ステップ 2：ベースラインを生成する

テスト台詞でレシピを変更なしに一度実行します。出力と、それを生み出した正確なプロンプトテキストを保存します。このベースラインが、以降のすべての比較の基準点になります。

ステップ 3：実行ごとに一つの変数だけを変える

これが全体の規律です。一つのことを選び、それだけを変えます。

• 台詞の長さ——同じプロンプトで、一文追加。
• 構図——ミディアムショットからミディアムクローズアップへ、他はすべてそのまま。
• 演技のトーン——一語を置き換える（「友好的」を「軽快」に）。

同じ実行で構図とトーンの両方を変え、出力が良くなったとしても、あなたは何かが効いたことだけを学び、どれが効いたかは分かりません。それは無駄な実行です。

ステップ 4：diff ログを保持する

各実行について、プロンプトのバリアント、その一つの変更、そして一行の結論を記録します。却下されたバリアントは受け入れられたものと同様に価値があります。境界がどこにあるかを教えてくれるからです。タイムスタンプ付きの diff を含むシンプルなテキストファイルで十分です。特別なツールは必要ありません。

ステップ 5：昇格または破棄する

あるバリアントがベースラインより明らかに優れているなら、それを新しいベースラインに昇格し、本番レシピとして確定する前に完全なテスト台詞で再テストします。ある一文に役立った変更が別の一文には有害かもしれません。

反復すべきでないもの

プロンプトが制御できないものを反復しないでください。問題が解像度、アスペクト比、シードの決定性なら、あなたは間違った層にいます——プロンプトではなくリクエストパラメータを見てください。インフラ問題を修正するためにプロンプトを書き直すのに実行を費やすのは、チームが生成予算を無駄にする最も一般的な方法です。

サンプル数についての注意

話者アバター生成には本質的な実行間変動があります。バリアントごとに一つのサンプルだけを生成すると誤解を招くかもしれません。結論を出す前に、テスト台詞で各バリアントを二、三個のサンプル生成し、最も良いものを選ぶのではなくサンプル間で比較してください。

よくある失敗パターンとプロンプトで回避する方法

これらは最もよく現れる問題で、プロンプト側から解決する調整を添えています。いずれもパラメータを発明する必要はありません。

主体がクリップ間でドリフトする

症状：髪、服装、年齢がセグメント間で異なって見える。 修正：すべてのプロンプトで主体モジュールを一字一句凍結し、何も変えない——同義語も変えず、語順も変えない。変動は通常、セグメント間の善意の書き直しから来ます。

演技が発話ではなく朗読のように読める

症状：表情が平坦、微動作がない、不気味な静止。 修正：演技モジュールに身体行動の手がかりを追加し、それが台詞の一つのビートに対応することを確認する。同時に、台詞が口語体で書かれているか確認する——短縮形、短い節、文の断片。フォーマルな散文は、どんなトーン語を加えてもフォーマルな演技のように読めます。

招かれざるカメラ運動

症状：要求していないのにゆっくりしたズーム、ドリフト、パン。 修正：演技モジュールの末尾に明示的な固定カメラ指示を加える。運動がまだ残るなら、プロンプトの他の場所で運動を示唆する語（「ダイナミック」、「エネルギッシュな構図」、「移動するカメラ」）を削除する。

背景が主体と注意を争う

症状：モデルが顔ではなく背景の細部に注意を置く。 修正：背景記述を一つのフレーズに簡素化し、主体を壁から分離する照明（片側からの柔らかなキーライト）を加える。背景の語はより少なく、より多くではなく。

長い台詞でリズムが崩壊する

症状：演技は良い滑り出しだが、終盤に向かって慌ただしく、または平坦になる。 修正：台詞を短くする。これが確実な修正方法であり、どんなプロンプトの言い回しでも補償できません。代わりに自然な境界で複数のクリップに分割してください。

密集した用語で明瞭度が低下する

症状：製品名、略語、数字が不明瞭。 修正：テンポの語を速いからゆったりへ変える。特定の用語がまだ間違っているなら、台詞の中で音声的に綴り直すことを検討する——同時に、これが台詞を読みにくくすることを認め、最後の手段とすべきです。

出力がプロンプトの一部を無視する

症状：あるモジュール全体が効果がないように見える。 修正：モジュールの衝突を確認する。主体モジュールが「フォーマルなスーツを着ている」と言い、構図モジュールが「カジュアルなカフェ」と言うなら、モデルは矛盾を調和させなければならず、何かを落とすかもしれません。モデルに非があると決めつける前に、四つのモジュールを互いに一致させてください。

同じ実行間で結果が一貫しない

症状：同じプロンプト、異なる出力。 修正：これは予期される変動であり、プロンプトのバグではありません。各バリアントで二、三個のサンプルにわたる受け入れ基準を設定し、基準範囲に入ったら調整を止めてください。プロンプトの言い回しで完全な決定性を追求するのは生産的ではありません。

プロンプトをバージョン管理された資産として扱う

チャットウィンドウに生きるプロンプトは再現可能な資産ではありません。二つのレシピと各レシピのいくつかのバリアントを持った時点で、あなたはソースコードを持っています——それはソースコードのように管理されるべきです。

プロンプトをそれを使うコードの隣に保管する

生成スクリプトがあるリポジトリに prompts/ ディレクトリを保ちます。レシピごとに一ファイル、プレーンテキストまたは markdown、四つのモジュールが完全で読める状態で。プロンプトテキストは関数本体に貼り付けるのではなく、文字列として読み込めるべきです。

名前が出力を予測できるように命名する

意図をエンコードする命名スキームは、賢さよりも価値があります。

prompts/
  explainer-single-speaker-v3.txt
  social-hook-closeup-v2.txt
  walkthrough-voiceover-v1.txt

バージョン接尾辞は飾りではありません。モジュールの変更が出力に影響するときに増やします。コメントのタイプミスでは増やしません。

バイナリだけでなくプロンプトを diff する

出力品質が変わったとき、「入力の何が変わったか？」に答える必要があります。プレーンテキストのプロンプトなら git diff が一コマンドで答えます。リクエストパラメータと混ざった JSON blob に埋め込まれたプロンプトではできません。プロンプトテキストをリクエスト設定から分離し、diff が読める状態を保ちましょう。

プロンプトを生成資産と一緒に固定する

生成クリップを保存するとき、どのプロンプトバージョンがそれを生み出したかを記録します——ファイル名、付随するメタデータファイル、または資産データベースに。六週間後、シリーズの中の一つのクリップがなぜ違って見えるか誰かが尋ねたとき、答えは推測ではなく一つのクエリで見つかるべきです。

コード変更をレビューするようにプロンプト変更をレビューする

構図や主体を変えるプロンプト編集は視覚的変更です。UI 変更のように扱いましょう。プルリクエストを開き、変更前後のサンプル出力を添え、別の人に見てもらいます。これは凍結されるべきモジュールでの偶発的なドリフトを捕まえる最も安価な方法です。

レシピ索引を維持する

prompts ディレクトリ内の短い README に、各レシピ、その用途、現在のバージョンを列挙すれば、新しい貢献者全員があなたの意図を逆算する必要がなくなります。既知の限界を記録する場所でもあり、たとえば解説レシピの台詞長上限のように、制約が再発見されるのではなく記録されます。

プラットフォームから始め、それから専門化する

これらのレシピをパイプラインに接続するなら、HiAPI.ai の OmniHuman-1.5 動画エンドポイントが単一の呼び出しインターフェースを提供し、レシピを追加してもリポジトリのレイアウトとバージョン方案が安定します。一つのレシピをコピーし、短いテスト台詞で実行し、一度に一つの変数を変え、ベースラインより優れたバージョンをコミットする——このループがすべての方法です。