Hy4 Preview：2つのゲーム、185ステップ、そして自ら作成した51のテスト

Hy4 Previewが本日リリースされました。 そこで私は2つの開発タスクを与え、その後は一切手を加えずに任せてみました。結果、どちらも最初のバージョンから問題なく動作しました。

この最初の一文こそ、この記事を書こうと思った理由です。最初の試行で実行可能な成果物を完成させられるコーディングエージェントがあれば、1日の仕事の進め方そのものが変わります。

今回、あえて難易度の高いタスクを選びました。与えたのは、1段落のプロンプトと空のディレクトリだけ。プロジェクト全体をゼロから構築し、すべてのアセットもコードで生成するという条件です。

Hy4 Previewとは

• 総パラメータ数7700億、トークンあたり490億パラメータをアクティブ化。 スパースMixture-of-Experts（MoE）アーキテクチャを採用しており、モデル全体は巨大でありながら、各トークンの処理で実際に動作する部分は限定されています。この差が高速性につながっています。

• 2つの思考モード。 reasoning_effort: "high" では、回答前にモデルが推論を行い、その思考内容を独立した reasoning_content フィールドとして返します。 reasoning_effort: "no_think" では、推論プロセスを挟まず直接回答します。

• デフォルトで665,536出力トークン、コンテキストは最大1,000,000トークン。 100万トークンのコンテキストがあれば、単に長い回答を扱うだけでなく、プロジェクト全体をコンテキストに収めることができます。

• OpenAI互換のAPI。 標準的なChat CompletionsとFunction Callingに対応しており、OpenAI APIに対応したハーネスであればHy4も利用できます。

• テキスト入力、テキスト出力。 Hy4はテキストで動作するため、検証ループもテキストベースにしておくことが重要です。

モデルのディスカバリーはAPI外で行われるため、設定ではモデルIDを直接指定します。

TencentはHy4を、マルチステップのエージェントワークフロー、ソフトウェア開発、生産性向上タスクにおいてHy3を進化させたモデルと位置づけています。特に、タスク分解、コンテキスト保持、指示追従、長時間にわたるタスク実行能力が強化されています。コーディング能力では ゲーム開発とWeb開発 が明示的に挙げられており、まさに今回検証したかった領域です。

Hy4 Previewを支える5つの主要能力

Tencentは、Hy4の特徴を5つのコア能力に整理しています。

公式のコーディングエージェント評価ガイドラインでは、Web、モバイル、デスクトップにまたがるクロスプラットフォームのフルスタック開発、複雑なバックエンドロジック、3Dレンダリングなどが評価対象として挙げられています。生産性向上タスクでは、ディープリサーチ、プレゼンテーションデザイン、スプレッドシートの正確性などが対象です。

この説明の中で、特に重要だった一文があります。「長期タスク実行」の評価項目には、 成果物を提出する前の自己検証 が含まれています。この点は最後のセクションで重要になります。実際に、その動作を目の当たりにしたからです。

Crashゲーム

Hy4
116 steps
In 193,793 · Out 53,328 · Reason 73,349
Cache R 10,664,768 · W 0 · Hit rate 98.2%

与えた指示は、32ビット時代のマスコットゲームを思わせる横スクロール型プラットフォーマーの制作です。ネイティブHTML5 Canvasを使用し、ゲームエンジンは使わない。さらに、衝突判定、重力、走行時の加速、壊せる木箱、スピン攻撃、チェックポイント、死亡・リスポーン機能を実装するという内容でした。

Hy4 Previewが生成したのは3つのファイルです。 index.html、 style.css、そして1,634行の game.js。

この1つのスクリプトには、以下の機能が詰め込まれています。オプションパネルと仮のパスワード画面を備えたメニューシステム、タイルベースのレベルビルダー、固定タイムステップのゲームループ、接地判定、軸ごとの衝突処理、ジャンプ時のコヨーテタイム（足場から離れた直後でも短時間だけジャンプを受け付ける仕組み）、TNTを含む複数種類の木箱の物理演算、Aku Aku風のマスク型アイテム、フルーツ収集、ジェム管理、巡回するカニ型の敵、トゲや水などのハザード、チェックポイントとリスポーン、パーティクルシステム、パララックス表示された海を背景にプロシージャル生成されるヤシの木、リアルタイムFPS表示、モバイル向けオンスクリーンタッチ操作、そしてポーズ・クリア・ゲームオーバーの各オーバーレイです。

オーディオは AudioContextを使用して実行時に生成されます。すべてのスプライトもCanvasプリミティブで描画されています。関数は約40個。すべてのアセットがコードによって生成されています。

正確性のために1点明記しておくと、このゲームは2D Canvas Contextを使ってレンダリングされています。奥行き感はWebGLではなく、レイヤー化されたパララックスとシェーディングによって表現されています。ある意味では、こちらの方が難易度の高い手法とも言えます。

Spider-Manキャラクター

Hy4
69 steps · $0.00
In 167,511 · Out 36,531 · Reason 60,246
Cache R 5,678,848 · W 0 · Hit rate 97.1%

今回の指示は、Three.jsを使用して、モデリング、テクスチャリング、リギング、アニメーションまで施した3Dキャラクターを1体作成するというものです。歩く、走る、ジャンプするSpider-Man風のキャラクターを、メッシュを含めてすべてコードで構築します。

Hy4 Previewは、依存関係のない静的サーバー、README、テストスイートを含む、実際に動作するプロトタイプを完成させました。

• メッシュ： 1つの SkinnedMesh、9,739頂点、 1ドローコール。 頭、首、胴体、骨盤、腕、脚、ブーツ、グローブ、マスクのレンズ、胸のエンブレムまで、カプセル、楕円体、ボックスを組み合わせてコード上で構築されています。身長は約1.9mです。

• テクスチャ： 256×256ピクセルのクモの巣状パターンを実行時にCanvasへ描画し、3×3でタイル表示。スーツの配色には頂点カラーを使用しています。最終的な色は MeshStandardMaterial 上で vertexColor × webTextureとして生成されます。

• リグ： 22本のボーンからなるスケルトンを採用。 Hips → Spine → Spine1 → Chest → Neck → Headの階層に加え、左右対称の腕と脚のチェーンを構成しています。Pose Bindを設定し、スケルトン構築前にWorld Matrixを解決、Bind MatrixにはIdentity Matrixを使用しています。

• スキニング： 各ボディパーツについて、滑らかな (1 - (d/r)²)² のフォールオフでウェイトを算出。影響度の高い4つを保持し、合計が1になるよう正規化しています。

• 移動： 歩行速度1.53m/s、走行速度5.2m/s、重力22m/s²。ジャンプは crouch → air → land のステートマシンで管理し、最高到達点は1.25m。キー入力はエッジトリガー方式のため、ボタンを押し続けてもジャンプは1回だけ発生します。

• アニメーション： Idle、Walk、Run、Air、Crouch、Land間を滑らかにつなぐプロシージャルFKポージングを採用。歩行時1.45m、走行時2.9mのストライドを基準に、移動距離から歩行フェーズを算出しています。そのため、足の動きと地面上の移動速度が一致し、足滑りを抑えています。さらにContact Passによって、接地している足を床面に固定します。

画面上では、赤いマスク、青い胴体、赤いグローブとブーツ、各パネルに描かれたクモの巣状パターンなどによって、一目でキャラクターの特徴が伝わります。地面には実際に影も落ちます。一方で、カプセルや楕円体をベースとした形状や暗めのデフォルトライティングなど、あくまでプロトタイプらしさも残っています。

テレメトリから見えてくること

これらのテレメトリには、ステップ数以上に多くを物語る2つの数値があります。

Hy4は、出力以上に「考える」

Hy4が生成したトークンのうち、約6割はユーザーから見えない推論に使われていました。スキニングのフォールオフ、ボーン階層、歩行フェーズなどを計算する必要があった、より数学的なキャラクター制作タスクでは、出力トークン1に対して推論トークンは1.65に達しています。

この推論への「投資」こそが、品質を支える仕組みです。キャラクターのリグが正しく動作し、ウェイトが正規化され、Transformが有限値に保たれ、足が床面に接地していたのは、モデルがファイルを書き始める前に約60,000トークンを使ってMatrixの順序を検討したからです。

推論に必要なコストをあらかじめ見込んでおく必要があります。それはコストの大部分を占めると同時に、出力品質を支える大きな理由でもあります。

処理の大部分をキャッシュが支える

2つの開発タスクを合わせると、Hy4は約 1,670万トークン分のコンテキスト を処理しました。一方、新規入力は合計361,304トークンです。185ステップを通じて、キャッシュヒット率は97〜98%を維持しました。

これが長時間にわたって動作するAIエージェントの内部で起きていることです。各ステップでは会話全体を再び読み込みます。Crashでは1ステップあたり平均91,938のキャッシュ済みトークンを読み込んでいます。そのため、実行全体のコストは、この繰り返し読み込みをどれだけ低コストに抑えられるかに大きく左右されます。ヒット率98.2%であれば、その条件を満たしています。

なお、両方の実行でCache Writeは0と報告されているため、Cacheの数値は完全なキャッシュ利用状況ではなく、読み込み側の指標として捉えるべきです。

幅広いタスクはステップを、深いタスクは推論を必要とする

Crashゲームは 116ステップ。 Spider-Manキャラクターは 69ステップでした。

スキンメッシュのリギングや正確なウェイト正規化の方が難易度が高そうに見えるため、私は逆の結果を予想していました。しかし、Crashゲームの方が単純にタスクの幅が広かったのです。約40の関数、十数種類のエンティティ、メニュー、オーディオ、モバイル操作、レベルデザインなど、多数の要素を実装する必要がありました。

1ステップあたりの数値を見ると違いが明確になります。キャラクター制作では1ステップあたり873 Reasoning Tokens。一方、プラットフォーマーでは632でした。つまり、キャラクター制作はステップ数こそ少ないものの、各ステップの内部ではより高度な推論が行われていたことになります。

最も印象に残ったポイント

先ほど紹介した公式の説明にあった「成果物を提出する前の自己検証」を覚えているでしょうか。実際の動作では、こうなりました。

Hy4はテキストで動作します。そのため、視覚的な成果物を求められたとき、自分が利用できる形式で検証可能な証拠を作ろうとします。つまり、自らテストを書くのです。

キャラクターのプロトタイプには、リグ、スキニング、ポーズ、移動を検証する51項目のヘッドレス・スモークテストが含まれていました。実際にそのまま実行してみました。

$ npm test
...
51/51 checks passed

意見ではなく、Assertionによる検証です。すべての頂点に4つの正規化されたウェイトが設定され、その合計は1。頭部の頂点はHeadおよびNeckボーンへ正しく割り当てられています。 Thigh.L を回転させると足は動きますが、頭は動きません。Idle、Walk、Runの各状態で、接地している足裏は床面に維持され、足首は約0.03mの高さにあります。ジャンプの最高到達点は、設定値1.25mに対して実測1.250m。ジャンプキーを空中で押し続けても、ジャンプ回数は正確に1回。長時間のセッションでもBone Transformは有限値を維持します。

さらにテストスイートとは別に、READMEには人間が確認すべき10項目のチェックリストが用意されていました。テストだけでは判断できない部分を補うためです。「キャラクターとして認識できるか？」「走行から歩行への遷移は自然か？」「キーを離したとき、自然な呼吸を伴うIdleポーズに戻るか？」

この役割分担が非常に興味深い点です。Hy4は指示された内容を、自ら証明できるものと人間が判断する必要があるものに分類しました。そして前者には検証結果を添え、後者については人間が確認すべき項目として明確に提示しました。意見よりもテストスイートの方が強力です。そしてHy4は、そのテストスイートまで自ら構築しました。

特に優れていた点

• 最初のバージョンから高い完成度。 どちらの成果物も、そのまま実行できました。このファーストパスの安定性が、今回最も印象に残ったポイントです。

• スピード。 7700億パラメータという規模を考えると、体感速度は数字から想像するよりはるかに高速です。490億のアクティブパラメータという設計が効いています。

• 最後までやり切る。 116ステップ、69ステップという長い処理の中でも、最初の指示を維持し、一貫性を失うことなく完成まで進めました。

• 適切なツール選択。 今回実施したすべてのテストで、最初の試行から適切なツールと引数を選択しました。

• 実際に自己検証する。 Hy4はリグが正しく動作する証拠としてテストを作成し、そのテストも実際にパスしました。

利用時に考慮すべきポイント

• 検証ループはテキストで完結させる。 Assertionやログを使って検証できるようにします。

• モデルIDを直接指定する。 モデルディスカバリーはAPIの外部で行われます。

• Reasoningを前提に予算を組む。 出力トークン量に対して、およそ1.4〜1.7倍の不可視の推論トークンが発生すると考えておくべきです。

• Cache列は読み込み側の指標として捉える。 Cache Writeは0と報告されています。

• プロトタイプはあくまでプロトタイプ。 キャラクターは幾何学的には正しくても、ビジュアル面では粗さがあります。「正しいこと」と「洗練されていること」は別の目標であり、後者については人間側で仕上げる必要があります。

• ハーネスは慎重に選ぶ。 特定ベンダーのPatch形式に強く最適化されたAgent Frameworkでは、そのベンダーのモデルが有利に見える可能性があります。Adapterではなく、モデルそのものを評価することが重要です。

総評

2つのゲーム。185ステップ。処理したコンテキストは1,670万トークン。新たに生成されたトークンは584,758。そして、実際に動く2つの成果物。

Hy4には驚かされました。その理由は、派手なデモではなく信頼性です。どちらの成果物も最初のバージョンから動作し、エフェクトもスムーズに実装され、自ら作成したテストもすべてパスしました。そして、そのすべてが高速に進みました。

Hy4はテキストで動作します。それでもSpider-Manを作り上げ、51通りの方法で自ら成果物を検証し、最後には人間が確認すべき10項目まで明確に提示しました。