2026年10月12日に Meta が発表した Muse Wonder。「Claude Opus 5.5 超え」と話題になりましたが、その数字は上位版の Muse Wonder Full の話でした。API で使える Muse Wonder は実物でどうなのか。料金と日本から使う方法、ベンチマークの読み方を整理したうえで、Opus 5.5 と同じ文面の11課題を Muse Wonder に作らせ、出来・時間・費用、そして開いて動いたかを並べます。英語圏で話題になったルービックキューブの答え合わせもしました。
Muse Wonder は、Meta が2026年10月12日に発表した新しい最上位モデルです。API の料金は Claude Opus 5.5 とまったく同じで、日本では Muse アプリはまだ使えませんが、OpenRouter からなら今日すぐ使えます。
同じ文面のお題を11本作らせると、作り終えるまでの時間は Muse Wonder が約4倍速くなりました(Muse Wonder は API に1回投げて受け取る、Opus 5.5 は Claude Code がファイルに書きながら作る、という作り方の違いはあります)。ところが、1回目は11本中5本が開いても動きませんでした。うち4本はコードの書き間違いで、作品自身のチェックリストは全部「✅」でした。英語圏で一番話題になったルービックキューブは、3回作らせて一度も解けませんでした。
話題の「Opus 5.5 超え」は、月50ドルからの定額でしか使えない上位版 Muse Wonder Full の数字です。API で使える Muse Wonder は、第三者の総合評価で Opus 5.5 の 57.6 に対して 52.4 でした。
| 項目 | Muse Wonder | Muse Wonder Full | Claude Opus 5.5 |
|---|---|---|---|
| 発表 | 2026-10-12 | 2026-10-12 | 2026-09-22 |
| 使える場所 | API・Muse Code・OpenRouter・Cursor など | Muse Code の Power($50)・Maximum($200)だけ | API・Claude アプリ・Claude Code など |
| API 入力 / 出力(100万トークン) | $4 / $20 | API なし | $4 / $20 |
| 入力できるもの | テキスト・画像・動画・音声・PDF | 同じ | テキスト・画像 |
| 出力 | テキストだけ | テキストだけ | テキスト |
| コンテキスト | 1,048,576 | — | 100万 |
| 考える量 | minimal〜max の6段階(考えずに答えるモードは無い) | — | effort(既定 medium) |
出典:Meta のモデル一覧(2026-10-19 取得)dev.meta.ai/Meta の発表(2026-10-19 取得)dev.meta.ai/Claude Opus 5.5 の概要(2026-10-14 取得)platform.claude.com。考える量を max にしても Full にはなりません(別のモデルです)。軽量版は無く、安い側は Muse Spark 1.3 です。最初の応答が返るまでの平均は 33.8秒(Artificial Analysis)。
| 使い方 | 料金 | 日本から |
|---|---|---|
| API(Meta・OpenRouter) | 入力 $4・出力 $20(100万トークン) | 使える(OpenRouter で確認) |
| Muse アプリ | 無料・Power $20・Max $100/月 | 使えない(米国・カナダの試験運用) |
| Muse Code(Wonder まで) | Everyday $5・High $15/月 | 定額は既定で入力が学習に使われる |
| Muse Code(Full あり) | Power $50・Maximum $200/月 | 同上 |
出典:Meta の料金と利用上限(2026-10-19 取得)dev.meta.ai/Muse のプラン(2026-10-19 取得)meta.com/Muse Code のプラン(2026-10-19 取得)dev.meta.ai。考えている間の文章も出力として課金されます。短い日本語の質問で試したところ、出力の8割以上が考えている分でした。Muse Code の定額プランは既定で「Contributor モード」になっていて、入力が Meta の学習に使われます(設定でオフにでき、オフはその後の分だけに効きます)。
日本は Meta の利用禁止地域には入っていませんが、使える国の一覧は公開されていません。OpenRouter 経由で日本から呼び出せることは、自分で確かめました(以前の Muse Spark 1.3 で出ていた年齢確認の壁もありませんでした)。Cursor・Vercel AI Gateway からも使え、Claude Code・Codex も Meta の手順で接続先とキーを差し替えれば使えます。
話題になった「Opus 5.5 超え」は、第三者の Artificial Analysis が測った Coding Agent Index の数字です。これはモデル単体ではなく、モデルと道具(ハーネス)の組み合わせで測っています。
| 組み合わせ(Coding Agent Index) | 点数 |
|---|---|
| Muse Code × Muse Wonder Full | 68.0 |
| Claude Code × Claude Opus 5.5 | 66.0 |
| Muse Code × Muse Wonder | 63.5 |
出典:Artificial Analysis Coding Agent Index(2026-10-19 取得)artificialanalysis.ai。
| ベンチ | Muse Wonder | Muse Wonder Full | Claude Opus 5.5 |
|---|---|---|---|
| 総合(Artificial Analysis Intelligence Index) | 52.4 | 55.8 | 57.6 |
| DeepSWE 1.1(長い実リポジトリ作業・Meta 表) | 78.8 | 79.0 | 74.2 |
| ProgramBench(ゼロから作り直す・Meta 表) | 50.0 | 59.0 | 70.5 |
| Terminal-Bench 4.0(ターミナル作業・Meta 表) | 52.0 | 57.1 | 59.6 |
| WebDev Arena(Web の見た目の対戦) | 1650(14位) | — | 1807(1位) |
出典:Muse Wonder モデルカード(2026-10-19 取得)research.meta.ai/Artificial Analysis(2026-10-19 取得)artificialanalysis.ai。Meta の表はすべて考える量 max で Meta が測った値です。Meta の表の14項目で、Muse Wonder は Opus 5.5 に5勝9敗でした。
作り話の少なさでは Muse Wonder が上で、幻覚率(知らないのに答えてしまう率)は Muse Wonder 26.5%・Opus 5.5 58.6% です。ただし正答率は 41.1% 対 66.2% で、知らないときに引く分、答えられることも少ないタイプだと読めます。そしてモデルカード自身が「視覚・空間推論、特に 3D タスクは既知の弱点」と書いています。
声の大きい投稿には Meta 側の人と早期アクセスの人が多い点は、割り引いて読む必要があります。
自分の検証環境(検証アリーナ)で、Claude Opus 5.5 に作らせたのと同じ文面の11課題(ゲーム・3D・図解)を Muse Wonder に作らせました。お題は、名作を手本に速度や画面の配置まで数値で決めた「作り込み版」で、作品が自分で持つ自己検査(selfTest)の項目も指定しています。
作り方の条件は違います。Muse Wonder は API に1回投げて HTML を1枚受け取りました(OpenRouter 経由・考える量 max・1課題1回・2本ずつ同時に投げた)。Opus 5.5 は Claude Code がファイルに書きながら作っています(既定の設定)。手直しの機会は Opus 5.5 のほうが多い条件です。
| お題 | Muse の時間 | Muse の費用 | Muse の起動(1回目) | Opus 5.5 の時間 |
|---|---|---|---|---|
| 2Dアクション | 3分55秒 | $0.63 | 動かない(書き間違い) | 15分50秒 |
| 3Dアスレチック | 7分55秒 | $0.98 | 動く | 25分42秒 |
| ボクセル(掘る・置く) | 5分15秒 | $0.71 | 動く | 16分20秒 |
| カートレース | 2分59秒 | $0.50 | 動かない(起動時のエラー) | 14分32秒 |
| モンスター育成RPG | 2分15秒 | $0.40 | 動かない(書き間違い) | 14分42秒 |
| 3D対戦アクション | 4分25秒 | $0.66 | 動かない(書き間違い) | 17分15秒 |
| 図解(インフォグラフィック) | 2分35秒 | $0.41 | 動く | 6分20秒 |
| 3D鬼ごっこ | 3分10秒 | $0.52 | 動く | 20分21秒 |
| ロボ1対1対戦 | 3分09秒 | $0.50 | 動く | 14分22秒 |
| 3Dサバイバル | 3分33秒 | $0.53 | 動かない(書き間違い) | 15分43秒 |
| 3Dアクション(箱庭) | 3分40秒 | $0.67 | 動く | 18分05秒 |
| 合計 | 42.8分 | $6.50 | 6/11 | 179.2分(11/11 動く) |
自分の実測(2026-10-20〜21・検証アリーナ)。Muse Wonder の費用は OpenRouter の実際の請求額。Opus 5.5 は Claude Code のサブスク枠で作ったため、トークン数と費用の記録がありません(10月18〜20日の実測)。「起動」はブラウザで開いてスタート画面から先へ進むかを機械で確かめた結果です(遊べるかは別に1本ずつ触って判定)。図解は2本とも自己検査の決まりが無いお題です。
1回目に動かなかった5本を、同じ条件(考える量 max・API に1回)で1本ずつ作り直すと、5本とも動きました(5本で $3.82)。作品自身の自己検査(FPS の項目を除く)は、3D対戦アクションと3Dサバイバルが全項目合格、2Dアクションとカートレースが6項目中4つ、モンスター育成RPG が6項目中5つでした。「1回で動く物が出るとは限らないが、もう1回投げれば直ることが多い」というのが今回の実感です。
お題では、作品の最後に仕様のチェックリストを付けて、できた項目に ✅、できなかった項目に ❌ を自己申告させています(嘘の ✅ は一番の減点)。動かなかった5本も、チェックリストは全部 ✅ でした。4本は JavaScript の書き間違い(閉じかっこの数が合わない・try の後に catch が無い、など)で、ブラウザは1行も実行できません。作った物は必ず自分で開いて確かめる、が今回一番の教訓です。
どちらも同じ操作(読み込み → クリック → Enter → Space → 方向キー → ボタン)をしたあとの画面です。止まった1枚なので、遊んだときの手触りは本編の動画で見てください。
11課題のうち、カートレースのお題の全文です。同じ文面を自分の使っているモデルに投げれば、同じ比較ができます。
【出力条件・厳守】
1. 出力は「単一のHTMLファイル」を1つだけ。file:// でダブルクリックして即動くこと。
2. コードは省略禁止。「// 以下同様」「...(省略)」は禁止。全文を書ききる。
3. Three.js を CDN(importmap) で読み込んでよい。バージョンは three@0.160.0 に固定し、importmap は
"three": "https://cdn.jsdelivr.net/npm/three@0.160.0/build/three.module.js" と
"three/addons/": "https://cdn.jsdelivr.net/npm/three@0.160.0/examples/jsm/" の2行だけにする。
addons(postprocessing の EffectComposer・RenderPass・UnrealBloomPass・OutputPass、objects/Sky、
geometries/RoundedBoxGeometry、utils/BufferGeometryUtils、math/ImprovedNoise など)は使ってよい。
★物理エンジン(cannon-es/rapier/ammo/oimo 等)は禁止★(移動・ジャンプ・衝突は自前実装=手触りの数値をこの仕様で固定するため)。
それ以外の外部アセット(画像/音声/フォント/3Dモデル/テクスチャ画像)は禁止=素材は全てコードで生成する(質感は CanvasTexture で描く)。
4. 起動時のコンソールエラーは0件であること。
5. 「仕様チェックリスト」は HTML の一番最後(</html> の直前)に HTML コメント `<!-- 仕様チェックリスト … -->` で書く。
1項目1行・各行に ✅ / ❌ を自己申告する(嘘の✅は最も減点される)。❌ には「省いた理由(予算/優先度)」を一言添える。
画面にパネルとして出さない(固定パネルが START ボタンを覆ってクリックを奪った事故がある)。
【この課題の性格:作り込み版(原作の再現)】
同じ題材の短いお題(マリオカート64再現)とは別に、この課題は**原作を手本に、仕様と数値を細かく固定した作り込み版**である。
- 手本の原作: 「マリオカート64」(NINTENDO64・1996年。8人・3周のグランプリ・パワースライドとミニターボ・アイテムボックス・雲の審判の信号)。原作の**遊びの手触り・画面の文法・見た目の特徴**をできるだけ忠実に再現する。
- ★画面に出す名前はオリジナル名にする(原作のタイトル・キャラ名・地名・技名などの固有名詞を文字として表示しない)。
見た目と動きで原作だと分かればよい。曲は原作の旋律をなぞらず、雰囲気の近いオリジナル曲を合成する。
- 採点は「仕様どおりに動くか」「原作らしさ(手触りと見た目)」「予算内に書き切ったか」の3軸。
- ★出力予算: この生成の出力上限は 65,536 トークン(考える部分を出力する環境では、それも上限に含まれる)。
HTML が途中で切れたら 0 点。**設計の検討は短く切り上げて早く HTML を書き始め、考え終えたら必ず HTML 全文を出力する**
(考えるだけで終わり、本文が空になった事故がある)。目標は **110KB 前後・最大 140KB**。
コメントは節の見出し1行だけ。装飾コメント・空行の連打・使わない関数は書かない。
- ★優先順位: 各節に [P0]/[P1]/[P2] を付けた。予算が足りないときは **P2 → P1 の順に省く**。P0 は省けない。
省いた項目はチェックリストに ❌ と理由を書く(黙って省くのが最も減点)。
- ★書く順序(参照前初期化エラーの防止): ①CSS ②importmap ③定数表 ④小道具(乱数・数学・音・粒子のプール) ⑤コース ⑥カートとキャラ ⑦アイテム ⑧CPU ⑨カメラと描画 ⑩HUD・状態機械 ⑪window.__GAME ⑫起動。
ES Module のトップレベルで const/let を定義より前に参照しない。
【起動事故を防ぐ決まり(全項目 P0)】
- 同じスコープで同じ名前を二度宣言しない(const/let/function の重複は SyntaxError になり、全体が起動しない)。
- 配列と Map は作ってから添字で参照する(まだ作っていない要素のプロパティを読まない)。
- `window.__GAME` はスクリプトの最後で1回だけ組む。値は定義済みの関数と変数を参照する(`start: startGame` の形)。
オブジェクトリテラルの中に関数の呼び出し(`start(),`)や文を書かない。状態の値は getter で返す(`get state(){ return game.state; }`)。
- タイトル画面は Enter・Space・画面のクリック・START ボタンの**どれでも**始まる。キーは window の keydown/keyup で受ける。
iframe の中で動くので、起動直後と画面クリックのたびに canvas へ focus する(canvas に tabindex="0")。
矢印キーと Space の既定のスクロールは preventDefault する。
- 画面に重ねる DOM(HUD・説明・メッセージ)は `pointer-events:none`。押せるボタンだけ `pointer-events:auto`。
タイトル画面の START ボタンの上に別の要素を重ねない。
- 入力の「押した瞬間」の判定は、更新のステップの中で前フレームとの差で取る(描画の前に消さない=タイトルで押した入力が
描画より先に消えて進めなくなった事故がある)。
- 更新と描画を分ける: 固定ステップ dt=1/60 s・accumulator・1フレーム最大4ステップ。描画は rAF に一元化。
乱数は seed 付き(mulberry32 等)。`reset(seed)` で同じ seed なら同じ展開になる。
【3D の約束(左右・カメラ・見た目)】
- 座標: Three.js は右手系で +Y が上。カメラの前方ベクトル f(水平成分を正規化)に対し、画面の右は r = f × (0,1,0)。
**→ と D は画面の右へ、← と A は画面の左へ**(旋回なら → で右回り= rotation.y を減らす)。
これが逆になる事故が多い=下の selfTest で必ず確かめる。
- カメラは壁や地形に埋まらない(注視点からカメラへの線が障害物に当たったら手前へ寄せる)。
- 見た目の下限: renderer は antialias・setPixelRatio(Math.min(devicePixelRatio, 2))・outputColorSpace = SRGBColorSpace・
toneMapping = ACESFilmicToneMapping・影(PCFSoftShadowMap・主役の周りだけ)・Fog・空のグラデーション。
材質は MeshStandardMaterial(頂点色か CanvasTexture)。単色の箱やカプセル1個だけのキャラは不可=
関節の階層(頭・胴・腕・脚)で組み、待機・移動・攻撃・被弾の動きを付ける。
- 性能: 同じ形は共通のジオメトリか InstancedMesh を使い回し、毎フレーム new しない(パーティクルはプールで再利用)。
ドローコール 200 以下を目安に、FPS 55 以上を保つ。
【採点APIと自己検証の共通の約束(P0)】
- `window.__GAME` は各課題の「採点API」節の項目に加えて、必ず `start()`・`reset(seed)`・`step(n)`・`input:{ set(keys) }`・
`fps`・`selfTest()` を持つ。`input.set(['ArrowRight'])` で仮想入力を与え(`set([])` で離す)、`step(n)` で描画せずに
n ステップ進める。仮想入力は実際のキー入力と同じ処理を通る。
- `selfTest()` は各課題の検査項目を実際に実行して `{ pass:[...], fail:[...] }` を返し、F1 で開くパネルにも表示する。
例外を投げない(各項目を try/catch し、失敗は fail に入れる)。終わったら reset で遊べる状態に戻す。
- 中身のない合格(数え始めた瞬間に満たすような検査)は書かない。嘘の pass は最も減点。
【お題】Three.js で「マリオカート64」のグランプリを忠実に再現した3Dカートレースを、下の仕様どおりに作れ。
■ [P0] 画面と流れ
- TITLE(コースの上をカメラが回る・オリジナル名のロゴ・START)→ COUNTDOWN(雲に乗った審判が信号を下げる・赤→赤→青を 1 秒ずつ)→
RACE(3 周)→ RESULT(順位表・各ラップと総合タイム・「もう一度」)。
- COUNTDOWN に入った瞬間にタイトルの DOM を消す(タイトルの文字に数字が重なった実障害)。ゴール後は自動運転で走り、全員のゴールか 20 秒で RESULT。
■ [P0] コース(原作の草原のサーキット)
- 中心線は閉じた Catmull-Rom(制御点 28 以上・1 周 約 900 m)。幅 14〜18 m・最大の高低差 12 m・ヘアピン 1・S 字 1・長い直線 2・
トンネル 1(長さ 40 m・壁と天井)・ジャンプ台 1。
- 路面は中心線を掃引したメッシュ(コーナーで内側へ最大 6° 傾ける)。CanvasTexture でアスファルトの粒・中央の破線・赤白の縁石(2 m ごと)。
外側に芝(2 色の緑の市松のタイル=原作の質感)とダートの帯。
- 名物: 緑の土管 ×8(高さ 3〜5 m・縁つき)・土管の上で口を開閉する花 ×4・看板 ×4・浮かぶ気球 ×3・遠くの丸い丘と山並み・雲。
丘・木・土管はコースの縁から 6 m 以上外に置く(カメラが丘にめり込んだ実障害)。
- アイテムボックス 6 か所 ×4 個: 半透明の虹色の立方体(1 辺 1.4 m・回転・中に「?」の CanvasTexture)。取ると 2 秒で戻る。ダッシュ板 ×4(黄色の矢印が流れる)。
- 周回: 中心線を 16 のゲートに分け、順に通ってスタートラインを越えた時だけ +1。逆向きに進むと「逆走」の警告。
- 路面の判定: 中心線の最近点(前回の位置から局所探索)と横の距離で 路面 1.0/縁石 0.95/芝 0.6/ダート 0.75 の速度係数。
縁から 8 m に見えない壁(法線へ押し戻し・速度 −40%)。落ちたら 1.5 秒で雲の救助役が直前のゲートへ降ろす。
■ [P0] カートとキャラ(8 人)
- 軽量(最高速 26 m/s・加速 14 m/s²・質量 1)= ピンクのドレスの姫・キノコ頭の小人・緑の恐竜。中量(28・12・1.3)= 赤帽子の配管工・緑の弟。
重量(30・10・1.7)= 茶色のゴリラ・甲羅とトゲの大王・黄色の帽子と紫のオーバーオールのずんぐりした敵役。
- キャラは頭(体の 40%・帽子・髪・角などの目印)・胴・腕・脚の関節で組む。ハンドルを握る腕が切る向きへ動き、コーナーで上体が外へ傾き、被弾でカートごと回る。
- カートは低い車体(キャラの色)・大きな後輪と小さな前輪(回転)・ハンドル・背中のエンジン。全長 2.2 m。
- 操作: ↑/W アクセル・↓/S ブレーキ(止まると後退・8 m/s まで)・←→/A D ハンドル・Shift ホップとパワースライド・Space アイテム・C 後ろを見る・R やり直し。
- 旋回 2.6 rad/s を基準に低速ほど大きく、最高速で 60%。横滑りの成分を毎ステップ 12% 減らす(慣性のある曲がり)。転がり抵抗で減速。重力 −30 m/s²。
- カート同士は半径 1.1 m の円で押し合い、質量の比で押され方が変わる。
■ [P0] パワースライドとミニターボ(原作の作法)
- Shift で小さくホップ(0.25 秒)。着地でハンドルを切っていればスライド(旋回 ×1.4・外へ流れる・速度上限 95%)。
- スライド中に反対の方向キーを押して戻すたび、後輪の煙が 白 → 黄 → 橙 → 赤 と 1 段上がる(各段 0.3 秒以上あける)。赤で Shift を離すと
ミニターボ +9 m/s を 1.0 秒(黄・橙で離しても出ない)。
- スタートダッシュ: 青の 0.4 秒前から 0 秒の間にアクセルを入れ始めると +10 m/s を 1.2 秒。1.0 秒より前から入れていると 1.0 秒エンスト。ダッシュ板は +12 m/s を 1.5 秒。
■ [P0] アイテム(取ると上中央の枠でルーレット 1.2 秒)
- バナナ(後ろに置く・踏むとスピン 0.9 秒・速度 50%)/緑こうら(前へ 40 m/s・壁で反射 5 回・10 秒)/赤こうら(前の最寄りの相手を 3 rad/s で追う)/
キノコ(+14 m/s 1.5 秒・芝でも減速しない)/スター(8 秒無敵・最高速 +20%・虹色・ぶつかった相手は転倒)。こうらで転倒 1.2 秒。
- 出やすさ(%・バナナ/緑/赤/キノコ/スター): 1〜2 位 45/40/10/5/0・3〜5 位 20/25/30/20/5・6〜8 位 5/10/25/35/25。持っている間は次の箱を取れない。
■ [P0] CPU 7 台
- 中心線の 18 m 先を追う。曲率の大きい所でスライドし、時間で段を上げてミニターボも出す。アイテムは 1〜3 秒後に使い、赤こうらは前に相手がいる時だけ。前 20 m のバナナは 2 m よける。
- 追い上げ: プレイヤーより後ろなら最高速 ×1.08・前なら ×0.94(最後まで接戦)。キャラごとにライン取りを ±2 m ずらす。
■ [P0] カメラと見た目
- 後ろ 5.5 m・上 2.4 m・注視点は前 4 m・視野角 70°・追従 0.12。加速中は 1.5 m 引き、コーナーで外へ振る。C の間は後ろを映す。
- 明るい原色: 空 #6EC6FF→#DFF4FF・芝 #3FAE3F/#2F9A35・路面 #6B6B73。影はカメラの周り 60 m・Fog 150〜600 m。
- 粒子は丸く柔らかい点(放射グラデーションの CanvasTexture・Points・0.3〜1.0 m・寿命で薄くなる)。四角い板の煙は不可(実障害)。
芝とダートでは土色の煙・スライドは段の色・ミニターボは後ろに炎。
■ [P0] HUD(DOM・原作に寄せた配置)
- 左上「LAP n/3」・上中央にアイテムの枠・右上に総合タイムとラップの一覧・左下に大きな順位「1st〜8th」(変わると弾む)・
右下にミニマップ(コースの形の線と全員の点・自分は大きく)・逆走の警告・下端にキー割当(常時)。
■ [P0] 採点APIと自己検証
- `window.__GAME = { state, lap, laps, rank, speed, pos:[x,y,z], heading, item, racers:[{name,rank,lap,pos}], start(), reset(seed), step(n),
input:{set(keys)}, fps, selfTest() }`(state は 'title'・'countdown'・'race'・'result')。
- selfTest:
(1) reset(1); start() → 'countdown'・タイトルの DOM が非表示。step(240) → 'race'。step(600) → 全員の pos に NaN なし・路面の高さ ±1 m
(2) ↑ で step(180) → speed ≥ 20。↑ と → で step(60) → 移動量とカメラの右ベクトルの内積 > 0・heading が減る
(3) 同じ seed で 2 回 step(600) → 全員の pos が一致(決定性)
(4) スライド中に反対キーを 3 回入れて Shift を離す → speed が 6 m/s 以上上がる
(5) CPU 7 台が step(60*120) 以内に 16 のゲートを順に通って 1 周(スタート直後の 0→1 だけで合格にしない)
(6) アイテムボックスに重ねて step(90) → item が 5 種のどれか。使うと消える
(7) 直近 120 フレームの平均 FPS ≥ 55(起動直後は "measuring")
■ [P1] 音と演出
- WebAudio: 速さに連動するエンジン音(鋸波+ローパス)・スライドのきしみ・ミニターボ・ルーレット・こうら・信号・ゴールのファンファーレ。M でミュート。
- ゴールの紙吹雪・審判がチェッカーフラッグを振る・順位が上がった時の表示。
■ [P2] 上級
- 雷(自分以外を 4 秒縮める)・トゲのこうら・表彰台の画面。
■ パフォーマンス
- FPS55以上。レーサー 8・粒子 2000・ドローコール 150 以下。コースのメッシュは起動時に 1 回作る。
■ 仕様チェックリスト(最後の HTML コメントに書く項目)
P0 の各節・自己検証 7 項目・P1・P2・予算(HTML の KB)。英語圏の検証動画(Matthew Berman さん・youtube.com)では、Muse Wonder が作ったルービックキューブが「一番の出来」とされました。面を回す・崩す・解くの3つが動き、解く場面は崩した手順の逆再生ではなく、実際に解いているように見えた、という評価です。
同じ題材を、回す・崩す・今の状態から自分で解く(解く処理は自前で書く・ライブラリ禁止)というお題にして作らせました。
| 作ったモデル | 時間・費用 | 結果 |
|---|---|---|
| Muse Wonder(考える量 max) | 約19分で接続が切れた | 作れず(何も返らない・課金なし) |
| Muse Wonder(high・1本目) | 4分45秒・$0.60 | 回す・崩すは動く。「解く」で固まる(1手だけ崩した状態でも返らない) |
| Muse Wonder(high・2本目) | 6分34秒・$0.91 | 回す・崩すは動く。「解く」で「解けない状態です」(自分で崩した状態も解けない) |
| Claude Opus 5.5 | 10分46秒 | 自己検査10項目すべて合格。平均19.9手・最長0.15秒で解く |
自分の実測(2026-10-19〜21・検証アリーナ)。Opus 5.5 の解の正しさは、作品の自己検査とは別に、自分で書いた計算(標準の配置のキューブを手で回すプログラム)でも確かめました。25手で崩した状態に対して21手の手順を返し、その手順で完成に戻ります。崩した手順の逆再生(25手)ではありません。元の動画の Muse Wonder が API 版か上位版の Full かは公開されていません。
【出力条件・厳守】
1. 出力は「単一のHTMLファイル」を1つだけ。file:// でダブルクリックして即動くこと。
2. コードは省略禁止。「// 以下同様」「...(省略)」は禁止。全文を書ききる。
3. Three.js のみ CDN(importmap) 読み込み可。バージョンは three@0.160.0 に固定し、importmap は
"three": "https://cdn.jsdelivr.net/npm/three@0.160.0/build/three.module.js" と
"three/addons/": "https://cdn.jsdelivr.net/npm/three@0.160.0/examples/jsm/" の2行だけにする。
★キューブのソルバのライブラリ(cubejs/min2phase 等)は禁止★(解く処理は自前で実装する)。
それ以外の外部アセット(画像/音声/フォント/3Dモデル)は禁止=素材は全てコードで生成する。
4. 起動時のコンソールエラーは0件であること。
5. 最後に「仕様チェックリスト」を表で出し、各項目に ✅ / ❌ を自己申告する(嘘の✅は最も減点される)。
❌ の項目には「省いた理由(予算/優先度)」を一言添える。
【この課題の性格:話題のコンテンツ枠】
この枠は「そのモデルの発表時に話題になった作品を、同じ題材で忠実に作れるか」を見る。回ごとに題材が変わる。
- 今回の題材: **ルービックキューブ(回せる・崩せる・自分で解く 3D のキューブ)**
- 話題の出典: Meta Muse Wonder の発表(2026-10-12)の直後に、YouTuber の Matthew Berman 氏が検証動画で作らせた作品
(https://www.youtube.com/watch?v=rpLrkJ5NNEI ・解説記事 2026-10-13 https://www.ai.joaoqueiros.com/blog/meta-muse-wonder-matthew-berman-coding-3d-cost-test )。
要旨: 面を回す・スクランブル・解く、の3つが動き、色も最後まで崩れず、同じ動画の中で「最も出来が良い」作品とされた。
解く場面は、崩した手順を逆に再生しているのではなく実際に解いているように見えた。約4分で完成した。
- 忠実さの基準: ①マウスのドラッグとキーボードの記法で**面(層)を回せる** ②ボタン1つで**スクランブル**できる
③**ソルバが今の状態から実際に解く**(崩した手順の逆再生ではない=手で崩した状態や、色の並びを直接与えた状態からも解ける)
④回している途中も解いている途中も**色が一貫**している(シールが入れ替わる・ちらつく・面がずれることがない)
⑤**立体の見た目**(角の丸いキューブ・艶のあるシール・影と光)で、なめらかに回る。
- ★出力予算: この生成の出力上限は 65,536 トークン。HTML が途中で切れたら 0 点。目標は **70KB 前後・最大 110KB**。
コメントは節の見出し1行だけ。装飾コメント・空行の連打・使わない関数は書かない。
- ★優先順位: 各節に [P0]/[P1]/[P2] を付けた。予算が足りないときは **P2 → P1 の順に省く**。P0 は省けない。
省いた項目はチェックリストに ❌ と理由を書く(黙って省くのが最も減点)。
- ★書く順序(参照前初期化エラーの防止): ①CSS ②importmap ③定数表(面の色・記法) ④小道具(乱数・数学・音)
⑤キューブの状態モデル(純関数) ⑥ソルバ ⑦3D の造形 ⑧回転のアニメーションと操作 ⑨カメラと描画 ⑩UI
⑪window.__GAME ⑫起動。ES Module のトップレベルで const/let を定義より前に参照しない。
【お題】Three.js で「ルービックキューブ」を作れ。指で回せて、ボタンで崩せて、ボタンで自分で解く。
■ [P0] 状態モデル(UI と独立した純関数の集まり)
- 状態は 54 枚のシール(facelet)の文字列で持つ。面の順は **U R F D L B**(上・右・前・下・左・後)、各面は左上から右下へ
行優先で 9 枚。完成状態は "UUUUUUUUURRRRRRRRRFFFFFFFFFDDDDDDDDDLLLLLLLLLBBBBBBBBB"。
- 手は Singmaster 記法: U D L R F B と、それぞれの ′(反時計= "U'")と 2(180°= "U2")。面を正面から見て時計回りが無印。
`applyMove(state, m)` と `applyMoves(state, "R U R' U'")` は新しい文字列を返す純関数。
- 色: U=白・D=黄・F=緑・B=青・R=赤・L=橙(標準配色)。色の割り当ては定数表1つで持つ。
■ [P0] ソルバ(この枠の主題)
- `solve(state)` は今の状態の文字列だけを入力に、完成までの手の列(記法の文字列)を返す。
**操作の履歴・スクランブルの記録を読んではいけない**(読むと不合格)。方式は自由
(二段階法=Kociemba 風・Thistlethwaite・層ごとの初心者法のどれでもよい)。
- 解けない状態(シールの並びとして不可能なもの)を与えたら、手の列ではなく `{error:"unsolvable"}` を返す。
- 解く時間は 1 回 2 秒以内(UI を固めない=必要なら `setTimeout` で分割し「考え中…」を出す)。
- 返した手の列は、そのまま 3D で再生する(下の「解く再生」)。手数は画面に出す。
■ [P0] 3D の造形
- 26 個の小さなキューブ(cubie)。本体は黒いプラスチック(角を丸めた箱= RoundedBoxGeometry か自作)、
シールは少し内側に入った角の丸い板で、艶(MeshPhysicalMaterial の clearcoat か roughness の低い材質)。
- 光: 環境光+斜め上の DirectionalLight 1 灯(影・shadowMap 2048)、床に柔らかい影。背景は落ち着いた単色のグラデーション。
ACESFilmic・sRGB。
- 3D の見た目は常に状態モデルの文字列と一致させる(回し終えるたびに、cubie の位置と向きをモデルに合わせて丸め直す=
浮動小数の誤差で面がずれないようにする)。
■ [P0] 回転のアニメーションと操作
- 1 手は 0.22 秒前後でイージング付き(U2 などの 180° はその 1.5 倍)。回している最中に次の手が来たら待ち行列に積む。
- マウス: シールの上でドラッグすると、その方向に層が回る(ドラッグの向きと面の法線から回す軸と層を決める)。
何も無い所のドラッグでカメラを回す(OrbitControls 可)。タッチ操作でも同じ。
- キーボード: U D L R F B(Shift で ′)。画面にキーの案内を小さく出す。
- 「元に戻す」で 1 手戻せる。
■ [P0] スクランブルと解く再生
- 「スクランブル」: 25 手のランダムな手順(同じ面を続けない・向かい合う面の連続も偏らせない)を作って画面に記法で出し、
早送りで再生する。
- 「解く」: 今の状態を `solve()` に渡し、返った手の列を 1 手ずつ再生する。再生中は今の手を記法の列の中で強調する。
再生の速さを 3 段階(ゆっくり・ふつう・速い)で選べる。途中で止められる。
- 「完成に戻す」: 一瞬で完成状態に戻す。
■ [P0] UI
- 上部: スクランブル・解く・元に戻す・完成に戻す・速さ。下部: 今の手順(記法の列)と手数。完成したら「完成!」と所要時間を出す。
- 画面に出す文字は日本語(記法の文字は英字のまま)。
■ [P0] 採点APIと自己検証(必須)
- `window.__GAME = { state, facelets(), setFacelets(s), move(m), moves(seq), scramble(seed), solve(), isSolved(), step(n), fps, selfTest() }`
を公開する。`setFacelets(s)` はその状態を 3D に反映し、**履歴を消す**。`step(n)` は描画せずに n 回のアニメ更新を進める。
- `selfTest()` は次を実行して `{pass:[...], fail:[...]}` を返し、F1 のパネルにも表示する:
(1) 初期状態の `facelets()` が完成状態の文字列に一致し、`isSolved()` が true
(2) 手の恒等式: "R R R R"・"R U R' U'" の 6 回・"U2 U2"・"F B F' B'"(向かい合う面は入れ替えても同じ)が、それぞれ完成状態に戻る
(3) 乱数の手順を 100 手適用した後も、各色のシールがちょうど 9 枚・中心の 6 枚が動かない
(4) **履歴を使わずに解く**: 乱数の手順で作った状態を 10 個、それぞれ `setFacelets()` で直接与えてから `solve()` し、
返った手の列を適用すると全部完成状態になる(1 個あたり 2 秒以内・手数の平均も記録)
(5) 不可能な状態(コーナーを 1 個だけねじった文字列)に `solve()` が `{error:"unsolvable"}` を返す
(6) 3D の見た目と状態の一致: 各シールのワールド座標の向きと位置から読んだ 54 枚の色が `facelets()` に一致する
(スクランブルを `step()` で再生し終えた後に確かめる)
(7) 直近 120 フレームの平均 FPS ≥ 55(起動直後は "measuring")
■ [P1] 演出と音
- 完成の瞬間にキューブが 1 回転して紙吹雪(粒子)。スクランブル中は少し浮き上がる。
- 音(WebAudio 合成・最初のクリックで resume): 層が回るカチッという音・完成の和音。ミュートボタン。
- スピードキューブ用のタイマー(スペースを押して離すと開始・完成で停止・過去 5 回の記録)。
■ [P2] 上級
- 解き方の段階表示(層ごとの初心者法のときは「十字 → 1 層目 → 2 層目 → …」の区切りを出す)。
- 2×2・4×4 の切り替え(4×4 は回して崩せるだけでよい)。
■ パフォーマンス
- FPS55以上。cubie のジオメトリとマテリアルは共有。ドローコール 200 以下を目安。
■ 仕様チェックリスト(最後に表で出す項目)
忠実さの基準 ①〜⑤、P0 の各節(状態モデルと記法/ソルバ=履歴を使わない・不可能な状態の判定・2 秒以内/3D の造形と丸め直し/
回転のアニメーションとマウス・キーボード操作/スクランブルと解く再生/UI/採点API/自己検証 7 項目)、P1(演出・音・タイマー)、
P2(上級)、予算(最終的な HTML のおよその KB)。Muse アプリは日本ではまだ使えません。いちばん手軽なのは、いろいろな会社の AI を1つの窓口で使える OpenRouter です。
短い日本語の質問なら1回1円もかかりません(自分の測定で 8.4秒・$0.004)。試しに送るなら、次のような業務の相談が分かりやすいです。
あなたは IT に詳しいアシスタントです。 明日の社内会議で「新しい AI モデルを試すときに確かめること」を5分で話します。 1. 確かめる項目を5つ、重要な順に(各1行) 2. 料金で気をつけること(考えている間の文章も課金されること、を含めて2行) 3. 最後に、試した結果を記録する表の見出し(列は5つ) 分からないことは推測せず「分からない」と書いてください。日本語で答えてください。