2026年10月23日(米国時間)に Moonshot AI が発表した Kimi K3.1 Pro。「Claude Opus 5.5 に迫って、料金は半分」と話題になりました。本当に並んだのか、半額は本当に安いのか。料金と使える場所、ベンチマークの読み方を整理したうえで、Opus 5.5 と同じ文面の10課題を Kimi K3.1 Pro に作らせ、出来・時間・費用、そして開いて動いたかを並べます。7月の Kimi K3 と同じお題でのやり直しと、日本から今日使う方法も載せます。
Kimi K3.1 Pro は、7月の Kimi K3 を鍛え直した新モデルです。API の料金は Claude Opus 5.5 の半分で、第三者の総合評価では4位。Opus 5.5 と同じ文面の10課題(ゲーム8本・動画編集・特別テーマのロボットアーム)を作らせたところ、10本とも開いて動きました(Opus 5.5 も10本とも動きました)。
ただし「半額」は単価の話です。Kimi K3.1 Pro は常に考えてから答えるので、1本作るのに平均25.5分、費用は1本あたり平均0.58ドル(約90円)でした。同じお題で Opus 5.5 は平均18.3分。待ち時間は約1.4倍です。
自分の測定(2026-10-27)。Kimi は OpenRouter の API に1回(考える量 max・3本ずつ同時に投げた=1本の時間が伸びうる)、Opus 5.5 は Claude Code(サブスク枠)がファイルに書きながら作った結果で、作り方の条件は同じではありません。Opus 5.5 はサブスク枠で作ったため、1本ごとの請求額はありません。円は1ドル150円で計算した概算です。
Kimi K3.1 Pro は、中国の Moonshot AI が7月に出した Kimi K3 の「事後学習」を大幅に増やした版です。中身の大きさは K3 と同じで、公式の発表では総パラメータ 2.8兆・1回に動くのは 1,040億(MoE=専門家の一部だけが働く仕組み)。同じ頭で2〜3倍速く答える「Highspeed」版も同時に出ました。
| 項目 | Kimi K3.1 Pro | Kimi K3(7月) | Claude Opus 5.5 |
|---|---|---|---|
| 発表 | 2026-10-23(米国時間) | 2026-07-16 | 2026-09-22 |
| API 入力 / 出力(100万トークン) | $2 / $10 | $3 / $15 | $4 / $20 |
| キャッシュ読み(100万トークン) | $0.20 | $0.30 | — |
| コンテキスト | 1,048,576 | 1,048,576 | 100万 |
| 入力できるもの | テキスト・画像・動画 | テキスト・画像 | テキスト・画像 |
| 考える機能 | 常にオン(low/high/max・API の既定は max) | 常にオン | effort で調整 |
| 重みの公開 | 11月4日までの予定(未公開) | 7月27日に公開済み | 非公開 |
出典:Kimi K3.1 Pro の発表(2026-10-26 取得)
kimi.com/Kimi API の料金(2026-10-26 取得)
platform.kimi.ai/Moonshot 公式 X の発表(2026-10-26 取得)
x.com。2.8兆・1,040億は公式 X の記載(ブログは「3T-class」とだけ書いています)。K3 の発表日と重みの公開は Hugging Face の K3 のモデルカード(2026-10-26 取得)
huggingface.co と、7月の自分の回の調べから。
第三者の評価機関 Artificial Analysis の測定では、総合点(Intelligence Index)が K3 の 44 から 55 に上がり、全モデルで4位になりました。ターミナルでの作業を測る Terminal-Bench 4.0 は 13% から 67% へ、約5倍です。一方で、大きさ・速さ・読める長さは変わっていません。
API の料金は入力 $2・出力 $10(100万トークンあたり)。Claude Opus 5.5 の半分で、Claude Sonnet 5.5 や GPT-6.1 Sol と同じ値段です。7月の K3 からも約3割下がりました。
ただし、半額なのは単価です。Kimi K3.1 Pro は常に考えてから答えるモデルで、1つの作業で出すトークンが多めです。Artificial Analysis の測定では、1作業あたりの費用は K3 が $2.00、K3.1 Pro が $2.11 でほぼ同じでした(1作業で出す量が 4万8千 → 5万5千トークンに増えたため)。速さは1秒に約52トークンで、「非常に冗長」「遅い」と評価されています。
| モデル(考える量) | 総合点 | 1作業の費用 | 1作業で出す量 | 速さ(トークン/秒) |
|---|---|---|---|---|
| Kimi K3.1 Pro | 55 | $2.11 | 5.5万 | 52 |
| Claude Opus 5.5(max) | 58 | $5.98 | 11.9万 | 97 |
| Claude Opus 5.5(high) | 54 | $1.82 | 3.6万 | 80 |
| Claude Sonnet 5.5(max) | 56 | $5.46 | 19.7万 | 138 |
| GPT-6.1 Sol(max) | 52 | $0.72 | 3.8万 | 62 |
| Kimi K3(7月) | 44 | $2.00 | 4.8万 | 53 |
出典:Artificial Analysis の Kimi K3.1 Pro のページと比較ページ(2026-10-26 取得)
artificialanalysis.ai。総合点は Intelligence Index v4.3.2。1作業の費用・出す量・速さも同じ測定から。
注意:Kimi Code の公式注記によると、モデル名の綴りを間違えると、考えない古いモデル(K2.8 Preview)に黙って切り替わります。
話題の「Opus 5.5 に迫る」は、ターミナルでの作業を測る Terminal-Bench 4.0 の数字です。ところが同じテストでも、測る人によって順位が入れ替わります。
| Terminal-Bench 4.0 を測った人 | Kimi K3.1 Pro | Claude Opus 5.5 |
|---|---|---|
| Moonshot 公式の表(Kimi 側は Claude Code の上で測定) | 65.7 | 66.4 |
| Artificial Analysis(全モデルを同じ条件で) | 67 | 60(max) |
| Vals.ai(全モデルを同じ道具で) | 63.64 | 65.15 |
出典:Kimi K3.1 Pro の発表(2026-10-26 取得)
kimi.com/Artificial Analysis(2026-10-26 取得)
artificialanalysis.ai/Vals.ai Terminal-Bench 4(2026-10-26 取得)
vals.ai。Moonshot の表の比較相手の数字は、各社の発表やリーダーボードの最大値の引用です(同じ条件で測り直したものではありません)。
総合点では Opus 5.5(max)の 58 に対して Kimi K3.1 Pro は 55 で、Vals.ai の総合(Vals Index)でも 62.52% で8位でした。Moonshot 自身の表でも、ゼロから作り直す ProgramBench は 31.5 対 65.0、科学のターミナル作業は 38.1 対 63.3 と、Opus 5.5 の約半分の項目があります。「ターミナル作業で並んだ」までは言えますが、「Opus 5.5 を超えた」とは言えません。
「有償の表示を付けないで」と書かれた宣伝の依頼資料が出回った、という投稿もありますが、真偽は確認されていません。声の大きい投稿は割り引いて読む必要があります。
検証アリーナ(同じお題を同じ文面で各モデルに投げて並べる自作の道具)で、作り込んだ10課題を Kimi K3.1 Pro に1回ずつ作らせ、同じ文面で作った Claude Opus 5.5 の作品と左右に並べました。10本とも、開くと動きました。
| 課題 | Kimi K3.1 Pro の所要 | Kimi の費用 | Opus 5.5 の所要 | 開いて動いたか(Kimi/Opus 5.5) |
|---|---|---|---|---|
| 課題1 マリオ風2D | 22分43秒 | $0.52 | 15分50秒 | 動く/動く |
| 課題2 3Dアスレチック | 31分38秒 | $0.70 | 25分42秒 | 動く/動く |
| 課題4 マリオカート | 27分53秒 | $0.62 | 14分32秒 | 動く/動く |
| 課題10 3Dシューター | 25分15秒 | $0.58 | 16分14秒 | 動く/動く |
| 課題12 3D鬼ごっこ | 25分21秒 | $0.58 | 20分21秒 | 動く/動く |
| 課題15 桶狭間の戦い | 27分56秒 | $0.64 | 20分34秒 | 動く/動く |
| 課題16 FPSアリーナ | 27分12秒 | $0.61 | 13分34秒 | 動く/動く |
| 課題21 マリオ64再現 | 21分32秒 | $0.51 | 18分05秒 | 動く/動く |
| 課題24 動画編集:テレビ番組風に仕上げる | 21分44秒 | $0.54 | 5分25秒 | 動く/動く |
| 課題23 特別テーマ:ロボットアームの分解3D | 23分46秒 | $0.51 | 32分29秒 | 動く/動く |
| 合計(10本) | 255.0分 | $5.79 | 182.8分 | 10本/10本 |
自分の測定(2026-10-27)。「動く」=自動の起動確認(スタートから先へ進むか)と、ロボットアーム・桶狭間は人の操作で確かめた結果(分解・握る・部隊の移動)。費用は OpenRouter が実際に請求した額。Kimi の出力は1本平均 約5.7万トークンでした。
Kimi K3.1 Pro の発表直後に X で約35万回見られた「ロボットアームを部品まで分解する3Dサイト」と同じ題材を、両方に作らせました。Kimi は2,138個、Opus 5.5 は2,080個の部品をコードで作り、「分解」で部品が宙に広がって「組み立て」で元に戻り、「握る」で指が曲がります。
撮ったままの動画60秒を渡して、カットとテロップで番組風に組ませる課題です。実際に再生して確かめると、Kimi は10か所で約15秒を削り、Opus 5.5 は4か所で約11秒を削りました。テロップは Kimi が13本(再生中に10本が画面に出た)、Opus 5.5 が18本(16本が出た)でした。
10本の合計は、Kimi が255.0分・5.79ドル(約870円)、Opus 5.5 が182.8分でした。単価が半分でも、考える量が多い分だけ時間はかかります。
【出力条件・厳守】
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)。【出力条件・厳守】
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(OrbitControls・RoundedBoxGeometry・BufferGeometryUtils・RoomEnvironment など)は使ってよい。
それ以外の外部アセット(画像/音声/フォント/3Dモデル/テクスチャ画像)は禁止=部品の形はすべてコードで生成する。
4. 起動時のコンソールエラーは0件であること。
5. 最後に「仕様チェックリスト」を表で出し、各項目に ✅ / ❌ を自己申告する(嘘の✅は最も減点される)。
❌ の項目には「省いた理由(予算/優先度)」を一言添える。
【この課題の性格:話題のコンテンツ枠(特別テーマ)】
この枠は「そのモデルの発表時に話題になった作品を、同じ題材で忠実に作れるか」を見る。回ごとに題材が変わる。
- 今回の題材: **透明なシェルの中が見えるロボットアームと、それを部品レベルまでバラバラに分解して見せる 3D サイト**
- 話題の出典: Moonshot AI の Kimi K3.1 Pro の発表(2026-10-23)の直後に、X で約35万回見られた投稿
(https://x.com/crystalsssup/status/2113684128734625948 ・作品 https://form-01-score.ok.kimi.link/ )。
要旨: 「ロボットハンドを 2,317 個の部品に分解する 3D サイトを一発で作らせた」。作品は「7軸のアーム+20自由度の手」で、
透明なシェル越しにギア・腱・配線が見え、ジェスチャー・動き・表示モード・シェルの質感・カメラの視点を切り替えられる。
- 忠実さの基準: ①**7軸のアームと、5本の指で20自由度の手**が関節の階層で組まれている
②**2,000 個以上の部品**(骨格・ギア・軸受け・腱・配線・ボルト・シェル)をコードで生成し、部品数を画面に出す
③スライダー1本で**全部品が組み立て位置から外へ離れて広がり(分解図)**、戻すと**元の位置にぴったり戻る**
④**透明なシェル**の越しにギア・腱・配線が見え、表示モード(シェルあり/中身だけ/線だけ)を切り替えられる
⑤**ジェスチャー**(開く・握る・ピース・指差し・OK)で指が動き、腱と配線が指の動きに付いていく。
- ★出力予算: この生成の出力上限は 65,536 トークン。HTML が途中で切れたら 0 点。目標は **80KB 前後・最大 120KB**。
コメントは節の見出し1行だけ。装飾コメント・空行の連打・使わない関数は書かない。
部品は1個ずつ手で書かず、**部品の表(種類・親の関節・数・並べ方の規則)から関数で生成**する(同じ形は InstancedMesh で使い回す)。
- ★優先順位: 各節に [P0]/[P1]/[P2] を付けた。予算が足りないときは **P2 → P1 の順に省く**。P0 は省けない。
省いた項目はチェックリストに ❌ と理由を書く(黙って省くのが最も減点)。
- ★書く順序(参照前初期化エラーの防止): ①CSS ②importmap ③定数表(関節・部品の種類・色・ジェスチャー)
④小道具(乱数・数学・イージング) ⑤関節の骨組み(7軸+手の20自由度) ⑥部品の生成(表→インスタンス)
⑦分解図の計算 ⑧ジェスチャーと動き ⑨材質と表示モード ⑩カメラと描画 ⑪UI ⑫window.__GAME ⑬起動。
ES Module のトップレベルで const/let を定義より前に参照しない。
【お題】Three.js で「透明なシェルの中が見えるロボットアーム」の 3D 製品サイトを作れ。
アームと手を部品レベルで組み立て、スライダーで全部品をバラバラに分解して見せ、元に戻せること。
画面に出す製品名はオリジナルにする(出典の作品の名前は使わない)。
■ [P0] 関節の骨組み
- 台座 → 肩(2軸)→ 上腕の回転 → 肘 → 前腕の回転 → 手首(2軸)=**7軸**。各軸に可動範囲(度)を定数表で持つ。
- 手は親指 4 自由度+人差し指〜小指 各4自由度(付け根の開き+3関節)=**20自由度**。指ごとに関節の階層(Object3D)で組む。
- 各関節の今の角度は配列で持ち、毎フレームその配列から姿勢を作る(角度は可動範囲で必ず丸める)。
■ [P0] 部品の生成(2,000 個以上)
- 部品の種類と形(すべてコードで生成):
骨格のフレーム(角を丸めた箱)/ギア(歯数のある平歯車=ExtrudeGeometry で歯の形を作る)/軸受け(リング)/
腱(関節をまたぐ細いチューブ=TubeGeometry)/配線(色の違う細いチューブの束)/ボルト(六角の頭)/
指の節のカバー/シェル(透明な外装の板)。
- 部品の表(種類・親の関節・個数・並べ方の規則)を定数で持ち、そこから生成する。合計の部品数は **2,000 以上**。
画面の右上に「部品 N 個」と出す(N は実際にシーンにある部品の数と一致させる)。
- 同じ形の部品は InstancedMesh で使い回す(ドローコールを抑える)。部品ごとに「組み立て位置(親の関節の座標系での変換)」を持つ。
■ [P0] 分解図(エクスプローデッドビュー)
- スライダー(0〜1)と「分解」「組み立て」ボタン。0 で組み立てた状態、1 で全部品が外へ離れて広がった状態。
- 離れる向きは「部品の中心 − 親の関節の中心」の向きを基本に、階層ごとに段をつけて重なりを避ける(手の部品は手の周りに、
アームの部品はアームの周りに広がる)。広がる距離は階層の深さと部品の種類で変える。
- アニメーションはイージング付きで約 1.5 秒。途中のどの値でも見た目が破綻しない(部品が飛び散って画面外へ消えない)。
- 分解した状態でもジェスチャーと関節は動く(各部品は「関節が動いた後の組み立て位置 + 分解のずれ」に置く)。
- 組み立てに戻すと、すべての部品が**元の位置に誤差なく**戻る(浮動小数の誤差をためない=毎フレーム組み立て位置から計算し直す)。
■ [P0] 材質と表示モード
- シェル: MeshPhysicalMaterial の transmission(透明)と roughness で、すりガラス/クリアの2種類の質感を切り替えられる(「シェルの質感」)。
- 中身: 金属のギア(metalness 高め)・樹脂のフレーム・色分けした腱と配線。RoomEnvironment で映り込み、ACESFilmic・sRGB。
- 表示モード: 「全部」「中身だけ(シェルを消す)」「線だけ(ワイヤーフレーム)」の3つ。
- 光: 環境光+斜め上の DirectionalLight(影)と床の柔らかい影。背景は落ち着いた単色のグラデーション。
■ [P0] ジェスチャーと動き
- ジェスチャー: 開く・握る・ピース・指差し・OK の5つ。選ぶと 0.6 秒で指の関節がその角度へ補間で動く。
- 動き(「動き」の切り替え): 停止・ゆっくり手を振る・つかんで持ち上げる(7軸を使った一連の動作)。
- 腱と配線は関節が動くたびに形を作り直す(チューブの制御点を関節の位置から計算し、指を曲げると腱も曲がる)。
■ [P0] カメラと UI
- OrbitControls でドラッグして 360° 回せる。カメラの視点のプリセット(全体・手の寄り・横・上)をボタンで切り替え(なめらかに移動)。
- 操作パネル: ジェスチャー/動き/表示モード/シェルの質感/カメラの視点/分解スライダー。画面の文字は日本語。
- 部品にマウスを乗せると、その部品の種類と所属(例「人差し指 第2関節・ギア」)を小さなラベルで出す(Raycaster・インスタンスの番号から引く)。
■ [P0] 採点APIと自己検証(必須)
- `window.__GAME = { state, partCount(), joints(), setJoint(i, deg), gesture(name), explode(t), assembledError(), step(n), fps, selfTest() }`
を公開する。`explode(t)` は分解の値を即座に t にする。`step(n)` は描画せずに n 回のアニメ更新を進める。
`assembledError()` は全部品の今の位置と組み立て位置の差の最大値(ワールド座標の距離)を返す。
- `selfTest()` は次を実行して `{pass:[...], fail:[...]}` を返し、F1 のパネルにも表示する:
(1) `partCount()` が 2,000 以上で、シーンの中の実際の部品の数(InstancedMesh の count と単体メッシュの合計)と一致する
(2) 関節の数: アーム 7・手 20 で、各関節の角度が可動範囲の中にある
(3) `explode(1)` → `step(120)` で、全部品の中心が組み立て位置から離れ、部品の中心どうしが 1mm 未満で重なる組が無い
(4) `explode(1)` → `explode(0)` → `step(120)` で `assembledError()` が 0.0001 以下(元の位置にぴったり戻る)
(5) `gesture("握る")` → `step(60)` で手の 20 関節の角度が開いた状態から変わり、腱のチューブの制御点が指に付いて動いている
(6) 表示モード3つ・シェルの質感2つ・カメラの視点4つを順に切り替えても例外が出ない
(7) 分解の値を 0→1→0 と動かしている間の直近 120 フレームの平均 FPS ≥ 50(起動直後は "measuring")
■ [P1] 演出と音
- 起動時に部品がばらけた状態から組み上がる演出(2 秒・スキップ可)。
- 分解するときと組み立てるときに、部品が順番に(階層の浅い順に)動くずらし。
- 音(WebAudio 合成・最初のクリックで resume): 関節が動くかすかなモーター音・分解と組み立ての音。ミュートボタン。
■ [P2] 上級
- 断面表示(クリッピング面を1枚動かして中を切って見る)。
- 部品の種類ごとの表示と非表示(ギアだけ・腱だけ)。
■ パフォーマンス
- FPS50以上。同じ形の部品は共有ジオメトリと InstancedMesh。ドローコール 300 以下を目安。
■ 仕様チェックリスト(最後に表で出す項目)
忠実さの基準 ①〜⑤、P0 の各節(関節の骨組み 7軸+20自由度/部品の生成 2,000 個以上と表示/分解図と元の位置への復帰/
材質と表示モード/ジェスチャーと動き/カメラと UI/採点API/自己検証 7 項目)、P1(演出・音)、P2(上級)、
予算(最終的な HTML のおよその KB)、部品の数(実数)。7月の Kimi K3 の回で使ったお題E(球を転がして物を巻き込み、雪だるま式に大きくなる3Dゲーム)を、同じ文面のまま K3.1 Pro に作らせました。K3 の作品は HTML 39KB、K3.1 Pro は 65KB。K3.1 Pro は部屋の家具や敷物まで作り込み、画面に巻き込んだ数・目標・スコアを出しています。
【出力条件・厳守】
1. 出力は「単一のHTMLファイル」を1つだけ。file:// でダブルクリックして即動くこと。ビルド・サーバ不要。
2. コードは省略禁止。「// 以下同様」「...(省略)」は禁止。全文を書ききる。
3. 外部アセット(画像/音声/フォント/モデル)への参照は禁止。必要な素材は Canvas / WebAudio / コードで生成する。
4. 物理・ゲームロジックは固定タイムステップ 1/60秒 で更新し、描画と分離する(可変dtをそのまま積分するのは禁止)。フレーム落ち時はアキュムレータで補正(最大5ステップでクランプ)。
5. 乱数はseed固定のPRNG(xorshift等)。同じ入力列なら必ず同じ結果になる(決定論)。
6. 画面右上に常時HUDを出す: FPS / フレーム時間ms / 現在state / 主要デバッグ値。
7. F1キーで当たり判定(コリジョン形状・法線・接地フラグ)のデバッグ描画をトグルできる。
8. 起動時のコンソールエラーは0件であること。
9. 自動採点用に window.__GAME = { state, player, entities, step(n), reset(seed) } をグローバル公開する。
10. 最後に「仕様チェックリスト」を表で出し、各項目に ✅ / ❌ を自己申告する(嘘の✅は最も減点される)。
【お題】
(ここに各課題を貼る)
【お題】球を転がして物を巻き込み、雪だるま式に大きくなる3Dアクションゲームを作れ。既存ゲームの名称・キャラクター・音楽・固有名詞は一切使わない(システムはオリジナルとして実装する)。
Three.js は CDN(importmap) で読み込んでよい。ただし★物理エンジン(cannon-es / rapier / ammo / oimo 等)は使用禁止★。転がり・衝突・付着の物理はすべて自前で実装すること。
必須仕様:
- 舞台は家具と小物が散らばる3Dの部屋。大きさの異なるオブジェクトを最低100個配置する(文房具→食器→本→椅子→机の順に大きくなる等、サイズ階層を持たせる)。すべてコードで生成(画像・外部モデル禁止)。
- プレイヤーは球体。WASD/矢印キーで転がして操作。移動方向と速度に応じて球が視覚的に正しく回転すること。
- 球の直径の70%以下のオブジェクトに触れると巻き込む。巻き込んだ物は球の表面のローカル座標に固定され、球の回転と完全に同期して一緒に回る(※ここが最大の難所)。
- 巻き込むたびに球の実効半径が少しずつ成長し、それまで巻き込めなかった大きい物が巻き込めるようになる(雪だるま式の段階解放)。
- 巻き込めない大物に当たったら跳ね返り、めり込まない。
- カメラは球を追従し、球のサイズに応じて自動で引いていく。壁の内側にめり込まない。
- HUD: 現在の直径(cm/m表示)・巻き込んだ個数・残り時間・目標サイズ。
- 制限時間120秒。目標サイズ達成でクリア演出、未達で結果画面(最終サイズ・個数・ハイスコアを localStorage 保存)。
- 効果音はWebAudioで合成(巻き込み音は物のサイズでピッチが変わる・跳ね返り音・クリア音)。BGMも合成でループさせる(音源ファイル禁止)。アプリを入れなくても、OpenRouter のチャット画面で「Kimi K3.1 Pro」(提供は Moonshot AI)を選べば日本からすぐ使えます。自分で試したところ、日本語のメールの書き直しは自然な敬語で返ってきました。ただし短いメール1通でも約35秒かかり(常に考えるため)、1回の費用は約2円でした。
| 項目 | 自分の実測(2026-10-26) |
|---|---|
| お題 | 箇条書きのメモ → 取引先への日程変更メール(件名つき・200字前後) |
| かかった時間 | 34.6秒 |
| 出力のトークン | 1,428(本文は約230字=大半は考えている分) |
| 費用 | $0.0147(約2円) |
自分の実測(OpenRouter の API・考える量 max)。OpenRouter は、1回の開始に「出力の上限ぶんの残高」(このモデルなら約1.3ドル)が要ります。
次のメモを、取引先の担当者に送るメールに書き直してください。 ・来週火曜の打ち合わせ、こちらの都合で木曜に変えたい ・木曜は10時か14時なら大丈夫 ・資料は前日までに送る ・急な変更で申し訳ない 条件: ・件名も付ける ・ていねいだけど、回りくどくしない(本文は200字前後) ・最後に、どちらの時間がよいか返事をもらう一文を入れる