プレイ可能な状態に見えたキューブ
著名なAIパフォーマンステスターであるMatthew Berman氏は最近、Mistral Mistral Large 4に対し、ブラウザベースのインタラクティブなルービックキューブシミュレーションを作成するよう挑戦した。このタスクは静的な画像生成の枠を超え、3Dオブジェクトをレンダリングし、ユーザーの入力に応答できる機能的なコードを生成することをモデルに要求する。
シミュレーションを成功させるには、単なる視覚的な忠実度以上のものが必要である。以下の要件を満たさなければならない：
- キューブを構成する27個の個別のキュービー（小立方体）をレンダリングすること
- 特定の面を選択・回転させるユーザー入力を受け付けること
- 複雑な変換を通じて、各面の配色と位置を正確に保持すること
当初、Mistral Large 4は視覚的に説得力のあるキューブを提供し、カメラの完全な回転を可能にした。この最初の反復は有望に見えたが、重大な欠陥が明らかになった。「スクランブル」ボタン（キューブの状態をランダム化するためのもの）が反応せず、キューブは永遠に揃ったままの状態だった。Berman氏はこれを自身のcube testにおける「失敗」と表現し、視覚的な出力と機能的なインタラクティブ性の間のギャップを浮き彫りにした。
修正によって、機能していた部分が壊れた
Berman氏がMistral Large 4から機能的なルービックキューブを引き出そうとした2回目の試みは、もどかしいパラドックスを生んだ。別の反復の後、生成されたコードはside rotations（面の回転）を正常に実装し、ユーザーが意図通りに面を回転させられるようになった。しかし、この修正によって新たなバグが発生した。回転のたびにキューブの表面からすべての色が消えてしまったのである。
この結果は、3Dシミュレーションにおける重要な違いを浮き彫りにしている。カメラがキューブの周りを旋回し、ダイナミックな視点を提供できたとしても、この視覚的な動きはパズルの内部メカニズムとは完全に切り離されている。面の回転と色の状態を正しく更新するには、レンダリングされたジオメトリと基礎となるデータモデルとの間で綿密な同期が必要である。
課題は、3D transforms（3D変換）、キュービーの識別情報、およびレンダリングされたマテリアルの管理にある。26個の可視な「キュービー」はそれぞれ、異なる面や向きに移動しても、独自の識別情報と色情報を保持しなければならない。Mistral Large 4のコードによって色が消えたことは、同期の不一致を示唆している。つまり、キュービーは物理的に回転しているものの、それに関連付けられたマテリアルプロパティやUVテクスチャマッピング（表面に色がどのように適用されるか）が正しく更新されていないか、上書きされていたのである。
これは単なるレンダリングの問題ではなく、永続的なstate management（状態管理）の問題である。シミュレーションは、キューブの中心に対する各キュービーの位置と向きを追跡し、スクランブルや回転のたびに色情報が正しい面に一貫して結びついていることを保証しなければならない。モデルは、反復的なコード変更を通じて、この複雑で絡み合った状態を維持するのに苦労した。
失敗したのはモデルか、それともハーネスか？
Berman氏の動画「Mistral Large 4 failed my Rubik's Cube Test」は、LLMの評価において見過ごされがちな重要なニュアンスを明らかにしている。彼は最終的な失敗の原因をMistral Large 4そのものではなく、モデルとそれを制御する「ハーネス（ツール群）」との相互作用に帰している。この区別は、複雑なAI主導の開発を理解する上で不可欠である。
Harnessとは、モデルにコンテキストを提供し、編集を適用し、生成されたコードを実行またはチェックする自動化システムといった、周囲のエージェントワークフローを指します。その挙動は、特に反復的なデバッグにおいて、モデルが何を修正できるかに大きな影響を与える可能性があります。例えば、Harnessがdiffを誤って適用したり、モデルの指示を誤解したり、包括的なテストフィードバックを提供できなかったりする場合があります。
このシナリオでは、Mistral Large 4がサイド回転を機能させるコードを生成した一方で、その後のHarnessの処理がキューブの視覚的状態を破損させ、色が消えてしまった可能性があります。動画はその結果を示していますが、根本的な原因を特定していないため、モデルの推論、生成されたコード、編集の適用、あるいはテストフレームワークのいずれに責任があるかを断定することは困難です。
これは、AI支援開発における増大する課題、つまりモデルの能力とそれらを調整するツールのパフォーマンスを切り分けることの難しさを浮き彫りにしています。モデルが高度化するにつれ、状態を維持し、複数ファイルの編集を管理し、正確なフィードバックを提供するHarnessの品質がボトルネックとなります。Mistralの継続的な進歩に関する詳細を知りたい開発者は、Mistral AI - Latest News and Model Announcementsを参照してください。この区別は、Rubik's cubeテストのような複雑なタスクが、強力なモデルであっても失敗する理由を理解するために不可欠です。
この記事が気に入ったら、毎朝同じようなものをメールで受け取れます。
1日1通 · 2クリックで解除 · サードパーティのトラッキングなし
なぜこの小さなテストが大きな意味を持つのか
Bermanのキューブテストは、重要な区別を浮き彫りにしています。静的なコーディングベンチマークや魅力的な最初のレンダリングだけでは、根本的な弱点を見落とすことが多いということです。ステートフルでインタラクティブなタスクは、AIが複数のターンにわたって永続的なデータ、イベントリスナー、リアルタイムのUI更新をどのように処理するかを明らかにします。モデルは美しい初期コードを生成できても、ユーザーが操作したり、システム自体がコードを反復したりする際に一貫性を維持できない場合があります。
開発者にとって、これは実践的な教訓となります。AIコーディングツールは、最初の出力のスクリーンショットだけでなく、エンドツーエンドの挙動で判断してください。繰り返されるインタラクションを通じてパフォーマンスを評価し、ワークフローに回帰チェックを統合しましょう。これらのステップにより、AIが堅牢で保守可能なシステムを構築できるのか、それとも印象的だが脆い出発点しか生成できないのかが明らかになります。
Rubik's cubeテストにおけるMistral Large 4のパフォーマンスは、試みられたワークフローの失敗を如実に物語っています。モデルは視覚的に魅力的でインタラクティブな3Dオブジェクトを生成し、その後、機能的な回転を実現することはできました。しかし、空間座標、状態同期、UIレンダリングの複雑な相互作用は、Bermanが採用した反復プロセスには荷が重すぎたようです。
この単一のデモだけでMistral Large 4にコーディング能力がないと証明することはできませんが、マルチターンでステートフルなコード生成における課題を強調しています。Bermanが示唆するように、問題はモデルの固有の能力だけでなく、モデルとHarnessの間の相互作用にある可能性が高いです。AIと運用環境の間のこの複雑なやり取りは、高度なAIコーディングエージェントにとって依然として大きなハードルとなっています。
よくある質問
Rubik's CubeテストでMistral Large 4は何を間違えたのですか？
最初のバージョンではキューブはレンダリングされましたが、スクランブルボタンには反応しませんでした。後の反復で面の回転は可能になりましたが、キューブの色が消えてしまいました。
Mistral Large 4はRubik's Cubeの仕組みを理解できなかったのでしょうか？
このテストではそれは断定できません。生成された実装が、インタラクションと視覚的状態を連携させて維持することに苦戦したことを示しています。
このテストにおける「Harness」とはどういう意味ですか？
Harnessとは、編集、コンテキスト、コード実行、反復を管理する、モデルを取り巻くツールとワークフローのことです。
なぜRubik’s CubeはAIコーディングの難関テストなのか？
動作するシミュレーションには、単に立方体を描画するだけでなく、3Dレンダリング、面の回転、コントロール、そして永続的な色の状態を統合する必要があります。