Claude Opus 5が2時間で5500行のコードを書いた話——LLMの「テスト」が変わりつつある

AIの「テスト」が変わりつつある

AIの実力を試すとき、これまでよく使われてきたのは「自転車に乗るペリカンのSVGを作って」といった、答えの良し悪しをひと目で判断できる課題でした。ところが最近、その種の「お試し問題」ではLLMの実力を測りきれなくなってきています。AIの研究者であるAndrej Karpathy（元OpenAIの研究責任者、元Teslaの自動運転AIディレクター）が先日、その変化を象徴する実験を公開して話題になりました。

Karpathyは、Claude Opus 5に対して「指輪物語の冒頭段落を渡す」「トークン上限を100万トークン（費用にして約10ドル、日本円で約1,500円）に設定する」「そのシーンをThree.jsで3Dレンダリングするコードを書いてもらう」という課題を与えました。この記事では、その結果から読み取れることと、30〜40代の会社員にとって何を意味するのかを整理します。

2時間・5500行——何が起きたのか

Opus 5は約2時間かけて、5500行のコードを書き上げました。出力されたのは、指輪物語の冒頭シーンをプロシージャル（手続き的）に描画するThree.jsのプログラムです。プロシージャルというのは、あらかじめ用意した画像や3Dモデルを貼り付けるのではなく、コードの計算によって木の生え方や光の当たり方を自動生成する手法のことです。

Karpathy自身は「ちょっとガタガタしているけど面白い」と評しつつ、「LLMが木を一本一本配置し、光源を調整し、カメラアングルを決め、それらを全部オーケストレーションしなければいけないというのは、少し頭がくらくらする体験だ」とコメントしています。完成物のクオリティより、LLMがそれだけ複雑な判断を自律的に積み上げたという事実の方が、彼には驚きだったようです。

「簡単な課題で測る時代」の終わり

この実験が示しているのは、LLMの評価軸そのものが変わりつつあるという点です。「ペリカンのSVG」のような課題は、モデルが基本的な指示に従えるかを確認するには有効でした。しかし現在のモデルは、そのレベルをとっくに超えています。

評価の難しさは、課題が複雑になるほど「正解」が一つではなくなることにあります。5500行のコードが「良い出力か」を判断するには、Three.jsの知識が必要で、さらに「指輪物語の雰囲気を再現できているか」という文学的な判断も絡んできます。人間でさえ評価が割れる課題を、AIが自律的に取り組んで一定の形にまとめてしまった——これが今回の実験の核心です。

AIのChatGPTの使い方ガイドでも触れているように、現在のLLMはシンプルな質問応答を超えた使い方が主流になりつつあります。今回のケースはその延長線上にありますが、スケール感がまったく違います。

100万トークン・10ドルという数字の意味

ここで注目したいのが、コストの話です。今回の実験では1Mトークンを使い、費用は約10ドルでした。5500行のコードを2時間で生成するのに、1,500円程度しかかかっていない計算になります。

比較のために整理すると、フリーランスのエンジニアに5000行規模のコードを依頼した場合、相場は数十万円から、プロジェクトの複雑さによっては100万円を超えることもあります。もちろん、今回の出力は「ガタガタしている」とKarpathy本人が認めるレベルであり、実務で即使えるものではありません。ただし、「たたき台を作る」「アイデアを形にして確認する」という用途であれば、コストパフォーマンスの差は無視できないものになっています。

この表を見て「じゃあエンジニアはいらなくなる」という結論には飛びつかない方がいいです。5500行の出力を「使えるコード」に仕上げるには、レビューや修正の判断ができる人間が必要です。ただ、「プロトタイプを作るフェーズ」でのAI活用は、もはや選択肢ではなく標準になりつつあります。

会社員の仕事にどう関係するか

「Three.jsとか指輪物語とか、自分の仕事には関係ない」と思うかもしれませんが、この実験が示す変化は、コード以外の仕事にも同じように当てはまります。

たとえば、マーケティング部門で新商品のキャンペーン企画を担当している人が、競合他社の事例・自社の過去データ・ターゲット顧客のペルソナをまとめた長文ドキュメントをAIに渡して「3ヶ月分のコンテンツカレンダーを作って」と依頼したとします。これは構造的に今回の実験と同じです。大量の情報を与え、複数の判断を組み合わせた長期的なアウトプットを求める——その種の課題をAIが扱えるようになってきています。

あるいは、総務部門で社内規程の改定作業を抱えている人が、現行規程・改定案・関連法令・他社事例を全部渡して「矛盾点を洗い出し、改定案を作って」と依頼する使い方も同様です。以前なら「AIにそんな複雑なことは無理」と思われていた仕事が、少しずつAIの射程に入ってきています。

プロンプトの書き方ガイドでも解説しているように、こうした複雑な依頼をうまく扱うには、指示の構造化が重要になります。今回のKarpathyの実験でも、「指輪物語の冒頭」という明確なインプットと「Three.jsでレンダリング」という明確なアウトプット形式を指定していました。あいまいな依頼では、トークン上限をいくら増やしても出力の質は上がりません。

まとめ

「ペリカンのSVG」で測れた時代は終わりに近づいています。LLMの実力を試すには、より複雑で、正解が一つではない課題が必要になってきました。今回のKarpathyの実験は、その変化を端的に示す事例です。

重要なのは、このスケールアップが「エンジニアや専門家だけの話」ではなくなってきているという点です。複雑な情報を整理してアウトプットを作る仕事——企画書、規程文書、分析レポート——は、どの職種にも存在します。あなたの仕事の中で、「情報を渡せば形にしてもらえると助かる」という場面はどこにあるか、一度考えてみる価値はあります。