Datawhale 干物
作者：筱可、Datawhaleメンバー
一、Kimi K3とGPT-5.6 Solの徹底比較
先週、AI業界にKimi K3という新しいハードコアなオープンソースプレイヤーが登場し、発表されるやいなやFrontend Code Arenaランキングの1位に輝きました。私たちDatawhaleは、いち早くこのモデルともう一つのトップモデルとの横断的比較テストを行いました。私たちがずっと考えていたのは、「どうすれば全ての読者にもモデル間の違いを直感的に感じてもらえるか？」ということでした。最後に思い付いた方法は、彼らに私たちが子供の頃に遊んだゲームを再現させることでした。
Kimi K3はMoonshot最新のオープンソース大規模パラメータモデルで、規模は2.8兆級に達しています。公式の原文では、全体的なパフォーマンスは依然としてClaude Fable 5やGPT-5.6 Solといった最強のクローズドソースモデルに及ばないと述べられています。今回はGPT-5.6 Solのみを横断的比較の対象とし、Claude Fable 5はテストしていません。理由は一つにコストが高すぎること、二つに我々のアカウントが凍結され、安定した再テストができなかったためです。今回は主に3Dゲーム開発におけるレベルを検証します。多くのモデルは一般的なフロントエンドのコードを書くことならもう decent な域に達していますが、3Dゲームはレンダリング、衝突判定、状態管理、リアルタイムインタラクションを伴う、より難易度の高いシナリオであり、モデルの能力の限界をより見えやすくしてくれます。
そこで、私たちはKimi K3に5つの子供の頃のクラシックゲームを作らせ、GPT-5.6 Solにも同一のプロンプトで対照実験を行いました。動画を撮影し、コードを精査し、完成品の見栄えを比較した結果、あるゲームは直接遊べるレベル、あるものは完成品に近いレベル、そしてあるゲームはまだ一歩及ばないことが分かりました。
二、モデルの評価：「動く」から「遊べる」へ
モデルのコーディング能力を評価する際によく行われるのは、単一ファイルのフロントエンドページを生成させることです。この手法は低コストですが、複雑なエンジニアリングにおける真の実力を見出すことは難しいです。
3Dゲーム開発はより優れた試金石となります。レンダリング、衝突判定、状態管理、リアルタイムインタラクションを伴うため、モデルはただコードを書くだけでなく、ページ上の視覚的なフィードバックに基づいてデバッグを繰り返す必要があります。そこで、2つのモデルに完全に同一のプロンプトと視覚的制約を与え、それぞれに5種類の子供の頃からのクラシックゲームを復刻させ、どちらがよりプレイ可能な完成品を出力できるか競わせることにしました。
しかし、ゲームでは「どちらが強いか」を比べることはできても、「K3自身が単独でリアルなエンジニアリングを納品できるか」という問いには答えられません。そのため、ゲーム以外のフルスタックバックエンドプロジェクトをK3に追加で課しました。ゼロからデータベースを構築し、REST APIを書き、フロントエンドのレンダリングまで完遂させるというもので、全プロセスにおいて人手の介入は一切ありませんでした。
Kimi K3はKimi Code + WebBridgeを介し、GPT-5.6 SolはCodexを介して実行しています。唯一の変数はモデル自体と、それぞれに対応するエージェントツールチェーンのみです。
三、Kimi K3とGPT-5.6 Sol：5つの童年クラシックを一つずつ比較
1. プラント vs ゾンビ（植物大戦僵尸）
Kimi K3のバージョンを開くと、緑の芝生、ゾンビの進軍、ポテト地雷の爆発が見られます。実際にプレイしてみると、終わりのないウェーブのみで、ステージ選択、一時停止、星評価、勝利統計がありません。GPT-5.6 Solのバージョンは、コアなバトルに加えて、ステージ選択画面、星評価、勝敗統計も実装しています。
コード構造を見ると、Kimi K3は単一ファイル内で全システムをインライン化し、セーブデータを直接読み書きしています。GPT-5.6 Solは複数モジュールに分割し、さらにデフォルトのセーブロジックとデータ検証を追加しています。
Kimi K3は開いてすぐに遊べますが、数回プレイすると目標感や進捗フィードバックに欠けることが分かります。GPT-5.6 Solのフローはより長く、明確なステージと評価体系が存在します。
Kimi K3-プラント vs ゾンビ
GPT-5.6 Sol-プラント vs ゾンビ
2. メタルスラッグ（合金弹头）
Kimi K3のバージョンではカスタムキャラクターのレンダリングが見られますが、敵の種類がGPT-5.6 Solより2種類少ないです。プレイ中に最も顕著な違いは、死亡後に直接ゲームオーバーとなり、コンティニューができない点です。GPT-5.6 Solはチェックポイントを実装し、死亡後もそこから再開できます。
コード構造では、Kimi K3は円形の衝突判定を使用し、ファイル構成はコンパクトです。GPT-5.6 Solは矩形のヒットボックスを使用し、構造は標準的なゲームアーキテクチャに近いです。
Kimi K3の画面は独自のスタイルがありますが、許容範囲が狭く、死亡ペナルティが重いです。GPT-5.6 Solは敵が豊富で許容範囲も広く、アーケード版の体験に近いです。
Kimi K3-メタルスラッグ
GPT-5.6 Sol-メタルスラッグ
3. ザ・キング・オブ・ファイターズ'97（拳皇 97）
K3版はキャラクター選択と難易度選択があり、必殺技のフィードバックが密です。キャラクターのレンダリングはGPT-5.6 Solの四角いキャラクターより詳細です。しかし、ステージ選択、体力/時間/ダメージ倍率の調整がなく、設定項目も永続化されません。
GPT-5.6 Solはこれらのオプションを全て網羅し、ルールが保存でき、繰り返し調整して遊べる格闘ゲームに近いです。
Kimi K3-ザ・キング・オブ・ファイターズ'97
GPT-5.6 Sol-ザ・キング・オブ・ファイターズ'97
4. 魂斗羅
K3版は開いてすぐに遊べ、射撃と移動は正常です。しかし、タイトル画面、ステージ選択、ポーズ、コンティニューがありません。浮遊する地形は視覚的な効果だけで、キャラクターが乗ることができません。
GPT-5.6 Solは完全なアーケードフローを作り上げ、プラットフォームの衝突判定も機能しており、完全なアーケード体験に近いです。
Kimi K3-魂斗羅
GPT-5.6 Sol-魂斗羅
5. バトルシティー（坦克大战）
K3版は基地防衛、アップグレード、地雷など核心となるメカニズムが揃っていますが、メニュー、ポーズ、ステージ戻り、ステージ管理がありません。
GPT-5.6 Solは完全なメニューシステム、ポーズメニュー、決算画面、ステージ検証機能を備え、長期にわたり開いて遊べるゲームに近いです。
Kimi K3-バトルシティー
GPT-5.6 Sol-バトルシティー
四、5つのゲームから見るKimi K3
評価基準は5つ：直接遊べるか、画面の完成度、操作感、ルールの完全性、賢さです。
K3の利点は、5つのゲームが全て直接開いて遊べ、核心的なシステムが成立していること。「プラント vs ゾンビ」と「KOF'97」では視覚的雰囲気が強く、ハイライトのフィードバックが密です。プロンプト外にもかかわらず、自発的にスターのアップグレードや武器の切り替えなどのコンテンツを追加してくれました。一部のポイント（キャラクターのレンダリングなど）ではGPT-5.6 Solより優れてさえいます。
K3の課題はルールの完全性が全体的に不足していることです。大半のゲームにメニュー、ポーズ、ステージ選択、セーブデータ検証などの付随プロセスが欠けており、一部のゲームは死亡ペナルティが重すぎるか、許容範囲が狭いです。また、単一ゲーム内のUIの質にばらつきがあります。
GPT-5.6 Solの完成度はより高いと言えます。プレイヤーが褒めることはないが、欠ければ没入感を削ぐような部分（メニュー階層、ルールの永続化、境界値の検証、画面エフェクトなど）に、予算を割いているからです。
効率面でも差があります。GPT-5.6 SolはCodex上でサブエージェントを合理的に並行処理させ、完了時間はK3の約25%で、トークン消費も少ないです。しかし、GPT-5.6 SolのAPI利用料金はより高く、越境アクセスや決済のハードルを加味すると、国内の個人開発者にとって実際の使用コストは逆に高くなります。K3は一つのタスクでより多くのトークンを消費するものの、国内から直接アクセス可能で、導入のハードルが低いという利点があります。
五、横断比較以外：純粋なK3でデータベース付きのフルスタックプロジェクトを実践
ゲーム比較は2つのモデルの差違を直感的に示せますが、限界もあります。シナリオが比較的単一で、主にフロントエンド表現力を見ることになるからです。さらに、前出の5種のゲームではバックエンドがあるかに関わらず、データベース部分を提示の重点としていませんでした。そこで、タスクが「プレイ可能なページを書く」ことから「非ゲーム類の実在するフルスタックエンジニアリング」に切り替わり、データベース設計、REST API、フロントエンドの調整を一気に完遂させる必要がある場合、Kimi K3が独立して任務を遂行できるかどうかを知りたくなりました。
そこで私たちは、K3に単独でフルスタックプロジェクトを割り当てました。オープンソースプロジェクトhttps://github.com/li-xiu-qi/paper-graph-manager（論文引用関係グラフ管理システム）をベースに、K3自身にゼロからバックエンドを立ち上げ、インターフェースを補完し、フロントエンドのレンダリングを検証させました。全過程で手動操作によるデバッグ介入は一切なく、すべてK3自身が完了させました。
1. 環境起動と依存関係の修復
K3の最初のステップは、依存関係のインストールとサービスの起動です。FastAPIバックエンドに必要な全依存関係を正しく認識してインストールし、その後uvicorn main:app --host 0.0.0.0 --port 8001を実行してサービスを起動しました。
起動過程で、dotenv、pyvis、kimi_agent_sdkの3つのModuleNotFoundErrorに連続して遭遇しました。K3はこれらをコードのバグではなく、環境依存の問題と正しく判断し、順次インストールした後、 http://localhost:8001 でサービスを正常に稼働させ、ヘルスチェックが ok を返しました。
2. バックエンド機能の実装とAPI検証
コアとなる要件は、論文の引用関係に完全なバックエンド能力を追加することでした。K3は以下の3つのファイルを変更しました。
• database.py：複合主キー、外部キー、インデックスを持つpaper_referencesテーブルを新規追加。
• graph.py：build_reference_graph() とexport_reference_html() を新規追加。
• main.py：4つの引用エンドポイント + 2つのグラフエンドポイントを新規追加。
納品物の品質を検証するため、K3は新しいポート8002で8ステップのエンドツーエンドテストを実行し、すべてパスしました。論文の登録、引用の追加、outgoing/incomingのクエリ、graphの取得、HTMLエクスポート、引用の削除、削除後の空確認です。新規テスト36個はすべてパス、全量134個がpassed、2個がfailedでした。K3は git stash で自身の変更を取り消しましたが、この2つの失敗は依然として存在しており、これらがプロジェクトに元から存在したレガシーの問題であり、今回の機能追加とは無関係であることを証明しました。
3. フロントエンド連携とリアルなページレンダリング
バックエンドが立ち上がった後、K3はフロントエンドの処理を継続しました。Viteの起動時にパスエイリアスのエラーが発生しました：Failed to resolve import "@/lib/utils" from "src/components/ui/dialog.tsx"。これは典型的なエンジニアリングの問題であり、フロントエンドは起動できるものの、コード内に正しく設定されていないエイリアス参照が残っている状態です。
K3はここで止まることなく、Kimi CodeのWebBridgeを通じて直接ブラウザを操作し、ページの状態を検証しました。rootLen をJSで注入して計測し、ページが0から30081へ増加したことを確認し、フロントエンドが確かにレンダリングされたことを立証しました。
最終的にページは正常にレンダリングされました。Paper Graph Managerのダッシュボードトップページには、総論文数、注釈済み数、ノートカバレッジ、最近追加された論文リスト（Mistral 7B、Verifiable Fully Homomorphic Encryptionなど）、そして論文管理、ナレッジグラフ、スマートチャット、ノート管理などのモジュールエントリが表示されました。
六、最後に
Kimi K3は提示効果、ゲームロジック、操作の滑らかさにおいて素晴らしいパフォーマンスを見せました。オープンソースモデルとして、この完成度に達しているのは戦える数少ない存在であり、中国オープンソースモデルのパラメータにおけるマイルストーンと言えます。
しかし昨日、K3は算力不足のため全体的に購入ルートを閉鎖しましたが、これも Kimi が旧ユーザーの体験を比較的重視していることを示しています。興味のある方は、彼らの算力が十分に回復した後に購入して体験してみてはいかがでしょうか。
しかし、評価の基準を「プレイヤーに直接渡して何度も開いて遊べる」水準まで引き上げると、K3にはシステムの完全度、ルールの厳密さ、パッケージ層においてまだ明らかな差があります。完全な製品を一足飛びで作り上げるというよりは、遊べるプロトタイプを素早く作る用途により適しています。
横断比較とは別に、フルスタックプロジェクトはもう一つの判断基準を提供してくれました。K3は既存のプロジェクト構造を読み解き、環境問題とコード問題を区別し、独立してデータベース設計、REST API、フロントエンド連携を完了し、ブラウザの自動化を通じて実際のレンダリングを検証できます。これは、その能力の限界がフロントエンドページにとどまらず、実際のバックエンドエンジニアリングもエンドツーエンドで完遂できることを示しています。
K3の採用を検討している方へ：コアとなるゲームプレイの実装においてはすでに遊べるレベルにあり、リアルなバックエンドエンジニアリングにおいても単独で完遂可能であり、キャラクターレンダリングや視覚表現といった単一点でさえ優位性を持っています。しかし、箱から出してすぐに遊べる完全な製品体験を求めるなら、システムの完全度やエンジニアリング規範においてまだ追従の余地があります。ゲームケースの完成度を見ると、K3はすでにトップクラスのクローズドソースモデルの90%以上の水準に迫っています。みなさんはKimiのメンバー会員をゲットできましたか～