ソースコードを覗いた訳ではないので
私も詳しい事は分からないのですが、
ずっと使っていることで分かった事があります。
MinimaxH3は
Subject(動画内の目的人物、モノ)として
入力画像と音声を明確に紐づけしても
AIはしっかりと記憶しておらず、
シーンが進むにつれて忘れ、キャラを見失う。
では検証実験をどうぞ。
＊
■ウマ娘小劇場第４話から
ニコニコ動画で公開し、Sunoの規約変更で削除した
ウマ娘小劇場第４話で検証しました。
観てくれた方(感謝
)は覚えているかも？
▽シーン１
MinimaxH3に
「各キャラの頭に名前を書け」
と指示しています。
Re：サトノレイナス
So：ソダシ
Ye：メイケイエール
Ub：ユーバーレーベン
完璧に紐づけが機能していますね。
このシーンではサトノレイナスの台詞がありますが、
ちゃんとサトノレイナスだけが喋ります。
何回やってもサトノレイナスの台詞をサトノレイナスが喋りますね。
▽シーン２
はい、ユーバーレーベンが行方不明になりました(苦笑)
Shot7の文字に名前が隠れた、という訳じゃありません。
認識しているときはShot7に重なって”Ub”と表示されます。
ここではソダシの台詞がありますが、
”So”とソダシを認識できているので
ソダシだけが喋り、紐づけはギリギリ機能しています。
ソダシが認識できてない場合、
サトノレイナスかメイケイエールが喋ります。
▽シーン３
はい、もーダメです(苦笑)
ユーバーレーベンを探そうとしたのか、
でも分からなくて、せっかく分別できていた
ソダシとメイケイエールの二人を”Ub”にしました(笑)
しかも本来のユーバーレーベン(左端青色髪)は
相変わらず認識すらされてない。
ここはメイケイエールの台詞があって、
たまたまメイケイエールだけが喋ったのですが、
既に見失っているので偶然に過ぎません。
むしろサトノレイナスがメイケイエールの声で喋ることが多いです。
▽シーン４
ここではソダシの台詞があるのですが、
既にソダシを見失っているので、
サトノレイナスにその役目が渡り、
ソダシの声で喋っています(苦笑)
ソダシを見失った以上、
AIが主体的と見ているサトノレイナスに
役割が回ったのです。
※サトノレイナスだけは最初から最期まで見失っていない。
このシーン４では、ほぼ100%の確率で
サトノレイナスがソダシの台詞を喋ります。
※追記：認識できていても？
▽シーン４B：上記シーン４と同じ
呪文でキャラ説明を更に詳細に追記すると、
画像レベルでは判別できたのです。
本来はソダシを認識したのでソダシの台詞をソダシが喋る筈ですが、
AIが判断する”主体(Subject)”が強すぎて、
サトノレイナスがソダシの声で喋ります…(汗)
※追記２：主体をソダシだと指定すると？
AIが主体をサトノレイナスとしているので
ソダシが台詞を喋れないのであれば、
「このシーンのメインはソダシである」
と明記すれば、ソダシが喋るはずです。
▽シーン６：上記シーン４，４Bと同じ
はい、やっとソダシが喋りました…はぁ(ため息)
なるほどね、喋らせたいキャラに「主体である」と
書いておくことで、AIの見ている主体を上書きできるんだね。
※MinimaxH3を使っている人向け：上記シーンサンプル呪文
実際は英語で、改行はなく、#で区切った説明もありません。
Shot 9 AT 00:09.000: Shot 8から続き。# 時間指定とShot間継続を指示。
画面左上部に"Shot9"の文字を書け。 # デバッグ用表示
# キャラクターの位置関係と簡単な説明
橙色髪の(Satono Reinas)は画面右端に立って
白髪の(Sodashi)の右隣に寄りかかっている。
白髪の(Sodashi)は茶髪の(Meikei Yell)の右隣に寄りかかっている。
茶髪の(Meikei Yell)は青髪の(Uberleben)の右隣に寄りかかっている。
青髪の(Uberleben)は左側の窓に寄りかかっている。
# デバッグ用表示
(Satono Reinas)の頭に"Re"の文字を書け。
(Sodashi)の頭に"So"の文字を書け。
(Meikei Yell)の頭に"Ye"の文字を書け。
(Uberleben)の頭に"Ub"の文字を書け。
(Uberleben)、(Meikei Yell)、(Sodashi)は皆困った表情をしている。
# MinimaxH3の主体(メイン)を上書きで指示する。
このシーンでのメインは白髪の(Sodashi)である。
# 以下の台詞を明確にソダシが喋る様になる。
白髪の(Sodashi)が<d>"狭い！狭いってば～"</d>と困った声色で話す。
▽蛇足～シーン７：上記シーン６、４，４Bと同じ
ユーバーレーベンを含めて全キャラが完璧に認識できてます。
ただ、この状態でも、サトノレイナスの主体度は強くて
ソダシが最後の台詞をきちんと喋るのは、
三十数回に１回あるか、ないかみたいです。
いずれにしても、キャラを混乱して他のキャラの台詞を喋る、
というよりは、この主体度によるものと考えた方が良さそう。
＊
■
第４話には完成動画がありますが、
動画生成で一度たりとも最期の台詞を
ソダシ自身が喋ってません(苦笑)
どうしたかって？
自分で描いて修正したんですよ！(笑)
サトノレイナスも口パクしてましたけど、
隣のソダシの口パクを描いたんです！
無理くりにソダシが喋っている様にしただけ。
余談なのですが、キャラの頭に名前を書かせると、
な・ぜ・か、キャラの紐付けの寿命が少しだけ伸びます。
そういうタスクを与える事でAIが再確認しているのかな？
とは言っても紐付けは定義から離れれば離れるほどに
(シーンが進むごとに)AIが忘れていくので…(苦笑)
●付録
ネットからMinimaxH3で悩んで辿り着いた人向けです。
まずはMinimaxH3のトークンについて。
※トークンとはAIに入力するプロンプトや画像などを処理する単位で
出力を生成する処理単位でもあります。(情報量)
📊 トークン数の目安
項目 トークン数 概要 推奨されるトークン数
（処理効率の最適目安）平均 約4,000 トークン 内部の最適化機構（H3-Context-IR）が、長大な入力情報を構造化・圧縮してベースモデルに引き渡す際の推奨かつ平均的な処理サイズです。 受け入れる最大トークン数
（コンテキスト窓）最大 約10万 トークン 複数の画像、動画、音声、および詳細なテキスト指示（カメラワークやセリフ、役割の指定など）をそのまま流し込める、実質的なコンテキストの上限となります。 💡 長文プロンプト利用時のポイント
MiniMax H3は、前段の解析機能である
H3-Context-IR（Context Information Retrieval）によって、ユーザーが入力した大量のテキストやマルチモーダル素材（場所、人物、動き、時間、音などの関係性）を一度解析し、ベースモデルが理解しやすい約4,000トークンの中間表現へと自動でスマートに圧縮します。 [1]そのため、10万トークン規模の非常に長い指示や、多くの参考素材を詰め込んでも破綻しにくい設計になっていますが、最も追従性が高くコストや処理速度のバランスが良いのは、圧縮後の基準となる「4,000トークン前後」に収まるような具体的な指示内容です。 [1]
もしAPIを介して利用する場合は、この
H3-Context-IRによるトークン処理に対して「入力100万トークンあたり $0.90 / 出力100万トークンあたり $3.60」の従量課金が発生するため、長すぎるプロンプトはコスト面にも影響する点だけ留意しておくと安心です。 [1]
要するに、
10万トークンが最大処理量
で、
AI内部で処理して4000トークンに収められる
と効率が良い、というわけ。
続いて、上記検証動画でのトークンの計算(AI説明)
📊 内部トークン消費の概算内訳
1. 生成する出力動画（11秒 / 960x544）
- 計算式:
(960 ÷ 32) × (544 ÷ 32) × 7フレーム × 11秒- 消費トークン数: 約 39,270 トークン
- 解説: MiniMax H3では、生成する動画そのものが最大のコンテキストを消費します。11秒という長さが、全体の約8〜9割のトークンを占めています。 [1, 2]
2. テキストプロンプト
- 消費トークン数: 約 1,000 トークン
- 解説: ユーザーご指定の文字通り、1,000トークンがそのまま加算されます。
3. 入力画像（計8枚）
- 640x896 (2枚) / 1280x1808 (2枚) / 608x352 (4枚)
- 消費トークン数: 約 2,000 〜 4,000 トークン
- 解説: 画像は解像度そのままではなく、内部のVision Encoderによって特定の中間サイズ（パッチ）にリサイズ・最適化されてからトークン化されます。そのため、1280x1808のような巨大な画像であっても破滅的なトークン数にはならず、1枚あたり数百トークン程度に圧縮されます。 [1, 2]
4. 音声ファイル（3ファイル：計16秒）
- 2秒 ＋ 6秒 ＋ 8秒 ＝ 16秒
- 消費トークン数: 約 500 〜 1,000 トークン
- 解説: 音声（AAC）は波形データとしてトークン化されますが、映像データに比べて情報密度が非常に低いため、トークン消費量はわずかです。 [1, 2]
📉 合計のコンテキスト消費量
すべてを合算すると、約 43,000 〜 45,000 トークン前後（誤差を含めても5万トークン以下）となります。
これはMiniMax H3の最大上限である「10万トークン」の半分以下であり、モデルが本来持っている推奨目安（圧縮後4,000トークンにするための、圧縮前の入力許容量） としても、非常に健全で破綻しにくい理想的なワークフローが組めている状態です。
要するに、制限があるトークンは
入力される動画があるときは入力でも膨れ上がりますが、
主に出力される動画の幅高さのサイズと長さで大量に消費されます。
なので、プロンプトで多少長い説明をタラタラ書こうが、
トークン消費量としては微々たるものなので、
どんどん書いても構わない、という事になります。
ただ…書けば書くほど、AIが混乱する危険もありますので…。
不必要な描写は、混乱の元なのですよ。
必要な描写は丁寧に、細かく。
不必要な描写は徹底的に省く。
こちらもどうぞ！
前記事
●おまけ
▽今回使用したワークフロー(手順書)の概要
参考になるかな…？
シーン説明１と２を日英翻訳
↓
人物設定を日英翻訳し、
シーン説明１か２を加える
(セレクタノードで選択)
↓
登場人物画像・音声読込、
場面設定用画像読込
↓
動画サイズ設定(960x544)
↓
高速化ノードを繋いだ
MinimaxH3本体で生成
↓
(総トークン計算)
(処理に影響しない)
↓
動画の画像を縮小(608x352)
↓
標準の動画生成(内部表現)
↓
動画の鮮鋭化とFPS倍化
↓
FFmpegによるFPS1/2化、
MP3等設定し動画生成、保存
-AR
