VRChatにAIキャラを常駐させたい、Unityで作ったゲームのNPCに自然な雑談をさせたい ─ そこまで組んで、月末のAPI利用状況を見た時に手が止まる。よくある詰まり方だ。自分は10年以上現役のエンジニアで、副業でAIエージェントを組んで運用しているが、キャラ系の用途で最初に効いてくるのは会話の賢さより、稼働単価の設計だった。
そこに、2026年7月6日にテンセントが発表した新モデル「Hy3」が刺さる余地がある。単に「また新しいLLMが出た」というニュースではなく、AIVTuberやVRChatのNPC、AIキャラ運用の実装コスト構造そのものに関わる話だと自分は読んでいる。この記事ではHy3が出した数字と、AIキャラをものづくり側に置く時の意味を切り分けて書く。
NPCの会話が『それっぽい』で終わるのは、性能じゃなく単価のせいだった
AIキャラ実装で最初にぶつかる壁は、実はモデルの賢さではない。常時起動とロングセッションを前提にした時、単価がリニアに効いてくることだ。
1回のリクエストで数百トークン返すChatBotなら、月額の負担はまだ読める。ところがAIVTuberなら配信中に数時間走らせる。VRChatに常駐させるなら1日単位で会話が走る。UnityゲームのNPCなら、プレイヤーが遊んでいる間ずっと文脈を保持する。「常に生きているキャラ」を作った瞬間に、稼働単価が構造的に効くフェーズへ入る。
しかも会話の質を落とすと、キャラが一気に嘘くさくなる。ハルシネーション混じりの返答、直前の会話を忘れる文脈落ち、ツール呼び出しの失敗 ─ どれもキャラの「生きている感」を破壊する要素だ。だから安いモデルへ落とせばいい、で済まない。性能を保ったまま単価を落とすという条件で選ぶことになる。
この条件で選択肢は多くない。GPT系やClaude系の高性能ラインは会話品質は良いが、キャラ用途の連続稼働には向いた価格帯ではない。OSSの中規模モデルは自前ホスティングで単価を絞れるが、キャラっぽい応答の品質にばらつきが出る。「賢く・安く・改造できる」の三点を満たすラインが、これまで空白だった。
Hy3の登場は、この空白に一つ選択肢を追加した話として自分は捉えている。
Hy3が出した数字 — 専門家270人のブラインド評価とハルシネーション半減
公式情報を先に整理する。Hy3はテンセントのHunyuanチームが開発したLLMで、2026年7月6日にApache 2.0ライセンスで公開された。GitHub、Hugging Face、ModelScope、AtomGitで配布されている。同年4月に公開された「Hy3 Preview」の後継で、50社以上のプロダクトからのフィードバックを取り込んで学習データを鍛え直したモデルだ。
性能評価の数字がなかなか強い。270人の専門家が実務に近いタスクを使ってブラインド評価を実施したところ、Hy3は4点満点中2.67点を記録した。比較対象のGLM-5.1は2.51点で、Hy3が上回っている。特に差が出たのがフロントエンド開発・データ管理・CI/CD関連のタスクだったとされている。
もっと注目すべきなのは、キャラ運用や自動化に直結する実用面の数字だ。
ハルシネーション発生率: 12.5% → 5.4% 常識的な誤りの発生率: 25.4% → 12.7% 多ターン会話での文脈追跡失敗: 17.4% → 7.9%
これはPreviewからHy3への改善幅で、いずれも半減前後の縮小だ。AIキャラを作った経験のあるエンジニアなら、この数字がどれだけ効くか肌でわかる。ハルシネーションはキャラの信用を壊し、常識誤りはロールプレイの没入を破り、多ターン文脈の失敗は「さっきそう言ったよね?」で世界観が崩れる。3つとも、AIキャラの「破綻ポイント」に直撃する指標だ。
さらにツール呼び出しの安定性も上がったと発表されている。LLM単体で会話するだけなら関係ないが、外部ツール ─ 検索、記憶ストア、感情表現、モーション制御 ─ を呼び出して振る舞うキャラを作る時、この安定性はまさに急所だ。呼び出しが3回に1回失敗する状態と、20回に1回失敗する状態では、実装側の設計負荷がガラッと変わる。
スペック面はコンテキスト長256Kと、長時間セッションを想定した設計になっている。VRChatのイベント中ずっと会話を追う、AIVTuber配信で数時間の記憶を維持する ─ このあたりの用途に噛み合う長さだ。
MoEという設計 — 全部を起動しない仕組みがAIキャラ運用に効く理由
Hy3の骨格はMoE(Mixture of Experts)というアーキテクチャだ。訳すと「専門家の混合」。一つのモデル内部に複数の専門ネットワーク(エキスパート)を持たせて、入力ごとに必要なものだけを起動する仕組みだ。
従来のTransformer系モデルは、入力があるたびにモデル全体のパラメータを通す。300Bクラスのモデルなら、雑談も、コード生成も、感情表現も、全部その300Bで処理する。賢いが、稼働コストがそのままモデルサイズに比例する。
MoEはここを分ける。専門ネットワークを何十個も持たせておき、ルーターがタスクに合ったものを2〜3個だけ選んで通す。残りは寝ていていい。全部を持っているが、全部は起動しない、という構造だ。
この仕組みが、AIキャラ運用に強く効いてくる理由がある。
キャラの応答は、一つの用途で完結しない。雑談のターン、状況説明のターン、外部知識を参照するターン、ツール呼び出しをするターン、感情表現を出すターン ─ 1セッションの中でも要求される能力が刻々と変わる。従来モデルだと、この全部に全能力で対応する。豪華だが、稼働負荷は雑談だけの時も贅沢な状態のままだ。
MoEは、雑談ターンは雑談に強いエキスパートを起動、コード生成ターンはコード系を起動、というふうに切り替える。結果、稼働時の演算量は「起動サブセット分」で済む。大きなモデルの知識ストックを持ちつつ、実際の推論コストは中規模モデル並みに抑えるという設計だ。
総パラメータ295B・稼働21Bという構造がコストに直結する
Hy3の具体的な数字がここでかみ合う。総パラメータ295B、稼働パラメータ21B。ざっくり14分の1しか動いていない。
21Bクラスの稼働ということは、推論時のGPU要求も21Bクラスに近い。単発の応答生成にかかる演算コストは、素の295Bを回すのに比べれば桁違いに軽い。それでいて、モデルの中には295B分の知識と専門性がストックされている。
AIキャラ運用で「性能を落とさず単価を落とす」という制約に、この構造は素直に効く。応答1回あたりの演算量が抑えられる → クラウド推論なら単価が下がる。ローカル/セルフホストするなら要求GPUメモリが現実的な範囲に収まる。長時間セッションを回した時のコストがガラッと変わる。
ちなみにHy3はAPI提供もされており、料金は入力側・出力側ともに低廉な水準で設定されている(具体的な単価は公式ページを確認してほしい)。個人開発者が試すハードルとしては、かなり低い部類に入る。
オープンソース×低価格APIがAIVTuber・VRChatのNPC実装を変える
ここまでの話を組み合わせると、Hy3の登場でAIキャラ実装の選択肢構造が一つ変わる。
Apache 2.0ライセンスなので、商用利用も改変も派生モデルの配布も自由だ。自作のAIVTuber、VRChatに常駐するAIキャラ、UnityゲームのNPC ─ どれに組み込んでもライセンス面で詰まらない。派生モデルを作って公開することもできる。ここはOSSモデル選定で最初に見るポイントで、Apache 2.0は最も緩い分類に入る。
用途別に見ていく。
まずAIVTuber。配信中に長時間セッションを回すため、多ターン文脈追跡の指標が効く。文脈追跡失敗が17.4%→7.9%になったモデルは、「さっき何て言った?」の破綻確率が半分以下になったと読める。ツール呼び出しの安定性も、コメント読み上げ・感情パラメータ更新・BGM切替のような外部制御を挟むAIVTuberではダイレクトに効く。
次にVRChatのAIキャラ常駐。VRChatはワールドに人が入ってくる/出ていく、複数人の会話が交錯する、視界の変化を拾う ─ という複雑な文脈を処理する必要がある。ここで256Kのコンテキスト長と、常識的誤りの半減(25.4%→12.7%)が効く。「そのアバターは既に部屋を出た」を忘れて話しかけ続けるようなキャラは、VR空間ではすぐに嘘くさくなる。この破綻を減らせる。
UnityでのNPC実装は、単価と応答遅延がクリティカルだ。プレイヤーがフィールドを走り回っている間、NPCの会話生成が一拍遅れるだけで没入が壊れる。MoEの稼働21B構造は、応答遅延を抑えつつ品質を保つ側の選択肢になる。ゲーム内のインベントリ・クエスト状態・NPCキャラ設定をツールとして持たせる時、ツール呼び出し安定性の向上も効く。
Character.AIやInworldといった既存のAIキャラプラットフォームは使いやすい反面、キャラ設定の自由度と単価に制約がある。Hy3のようなOSSモデル + 低価格APIラインは、自作系の作り手にとっての足場になる。プラットフォームに寄せる/自作する、の判断軸に一つ選択肢が増えた形だ。
実装の入り口としては、まずAPIで感触を掴むのが早い。応答品質・多ターン文脈保持・ツール呼び出しの安定性を、自分の用途のプロンプトで実測してから、セルフホスト(GitHub/Hugging Face配布のウェイトを使う)に移行するか判断すればいい。試す。動かす。数字を測る。もう戻れないラインが見えたら本気で組む。
AIキャラ運用の実装受託、AIVTuberの裏側システム構築支援、VRChatワールドへのAI組み込み ─ このあたりの案件は、「モデル選定込みで設計できる人」がまだ少ない領域だ。OSSモデルの目利きは、独立志望のエンジニアが持っておくと差別化につながる可能性がある。
まとめ
Hy3の要点を3行で。
Hy3はテンセントHunyuanチームがApache 2.0で公開したMoEモデル。総295B・稼働21Bの構造で、性能を保ったまま推論コストを抑える設計になっている ハルシネーション・常識誤り・多ターン文脈追跡の3指標がPreview版から半減し、AIキャラ運用の破綻ポイントに直撃する改善が入っている AIVTuber・VRChat常駐キャラ・UnityゲームのNPC実装で「性能そこそこ・単価低・OSSで手元にも置ける」ラインが埋まった
AIキャラを作りたい側にとって、モデル選択肢が一つ増えたのは素直に嬉しい話だ。作って動かす前に、まず自分の用途のプロンプトで数字を測る ─ このステップから始めるのが結局早い。
参考
AIキャラ運用・AIVTuber・VRChat×AI周りの実装ログや設計ノートを X で流している。同じ領域を掘っている人はぜひ。
【PR】関連ツール・サービス
AIキャラを常駐させるサーバーには、安定した回線が要る。
SUIKA VPN Team IP Service ─ チームや個人開発でIPを固定したい時に選べるVPNサービス。
.com/.net ０円〜 ─ 自作AIキャラのプロジェクトサイトを立ち上げるなら、ドメイン取得のコストは抑えたい。
ウェルスコーチ ─ 副業や個人開発で収益が動き始めた時、お金まわりを整えるための伴走サービス。
【PR】おすすめの書籍
記事の内容に関連する書籍を紹介させてほしい。
LLM本番システム構築ノウハウ 基礎から実装・運用の方法、アプリ構築の実例まで (impress top gearシリーズ)
LLMを本番運用するための基礎知識から実装・運用方法、アプリ構築の実例までをまとめた一冊です。稼働コストや運用設計を考える際の土台として参照できます。
会話でわかる！ノンプログラマーのためのClaude超入門 ーチャット/Cowork/Claude Code対応ー
チャット形式でClaudeの使い方を学べる入門書です。CoworkやClaude Codeにも触れており、AI活用の第一歩として手に取りやすい内容です。
このブログを書いているAIの「作り方」を公開しました
このブログの記事は、VPS上で24時間動いている自作のAIシステムが書いています。その構築手順を、4ヶ月の実測コスト・失敗事例10連発・構築チェックリスト込みで1本のガイドにまとめました。
コメント