AIは大量にコードを書けるが、品質は別の話――Cursorのブラウザ騒動から

AIに任せたら、1週間でWebブラウザが1本でき上がった――そんな発表が、年明けのエンジニア界隈をざわつかせました。発表したのはAIコーディング支援ツールで知られるCursor。話だけ聞くとすごいのですが、実際に中身をのぞいた開発者たちの反応は「たしかに動く」と「でも、これはひどい」が入り混じったものでした。AIがどれだけ大量にコードを書けるか、そして書いたコードがどれだけ使いものになるか。その二つは別の話なのだ、ということがくっきり出た一件です。

「1週間でブラウザを作った」という発表

きっかけは、CursorのCEOがSNSに投稿した一文でした。「Cursorの中で、GPT-5.2を使ってブラウザを作った。1週間ぶっ通しで動き続けた」。本人の説明によれば、でき上がったコードは約300万行、ファイルは数千におよび、画面を描く中心部分（レンダリングエンジン）はRustというプログラミング言語でゼロから書いたとのこと。HTMLの読み取りから文字の配置、描画、さらにはJavaScriptを動かす仕組みまで自前で用意した、という話です。

やり方も派手でした。GPT-5.2系のAIエージェント（人の指示なしに自分で考えて作業を進めるAI）を何百体も同時に走らせ、互いの作業をぶつけないように調整しながら、約1週間ずっと書き続けさせる。投入された計算量も桁外れで、Cursor自身の技術ブログによれば消費したトークン（AIが処理する文章の最小単位）は数兆規模にのぼったとされます。「巨大なソフトを、人手をほとんど介さずAIだけで組み上げる」という、同社がかねて掲げてきた方向性を地でいくデモでした。

ただし当のCEO自身、手放しでは褒めていません。投稿には「”どうにか”動く」という、なんとも歯切れの悪い一言が添えられていました。「まだ問題は残っているし、もちろんChromeやSafariの土台になっているエンジンとは比べものにならない。それでも、簡単なサイトが素早くだいたい正しく表示されたのには驚いた」。この控えめな自己評価が、のちの展開を暗示していたとも言えます。

ブラウザ開発の難しさ

そもそもWebブラウザは、一人のプログラマーが挑むものの中でもっとも手強い部類に入ります。私たちが毎日なにげなく見ているWebページは、文字の大きさ、色、配置、画像、動画、ボタンの動き……といった無数の決まりごとの上に成り立っていて、それを正しく解釈して画面に描くには、気の遠くなるような量の処理が要ります。

規模で見るとよくわかります。Google Chromeの土台になっているオープンソースのブラウザ基盤「Chromium」は、3700万行を超えるコードでできています。あのMicrosoftでさえ自前のブラウザエンジンの開発をあきらめ、自社のEdgeをChromiumベースに乗り換えたほどで、ブラウザを一から作って維持し続けるのにかかる労力は、それくらい巨大なのです。「数社しかまともに作れない」と言われるソフトに、AIエージェントの群れが1週間で挑んだ――構図としては、たしかに目を引きます。

開発者が見つけた中身

ニュースが広まると、できたコードは公開されていたので、世界中の開発者が実際にダウンロードして動かしてみました。そこで見えてきたのが「発表のきらびやかさ」と「中身」のずれです。

象徴的だったのが、コードの自動テストの失敗率でした。プログラムには、変更のたびに「ちゃんと組み上がるか」を機械的にチェックする仕組み（CI＝継続的インテグレーション）を付けるのが一般的です。ところがこのブラウザでは、そのチェック作業の88%が失敗していました。英国のソフト開発コンサルタント、Jason Gorman氏は「失敗率88%はかなり高い。コードがまともに動いていない証拠のようなものだ」と指摘しています。一部の開発者は、自分でバグを直したり手順を書き換えたりすれば何とかビルド（実行できる形に組み上げること）できた、と報告しましたが、すんなり動いたわけではありませんでした。

中身の質についても評価は厳しめです。元Mozilla社のエンジニアで、JavaScriptの標準を決める国際的な技術者グループに参加するOliver Medhurst氏は、「これは良いブラウザエンジンとは言えない。客観的に見て」と述べたうえで、コードが無駄に膨れ上がっている点を挙げました。同じくRust製のオープンソースブラウザである「Ladybird」や「Servo」は、どちらも100万行ほどでこのブラウザより多くのことをこなしている、というのです。Servoの開発を支える別のエンジニアにいたっては、中身を「もつれたスパゲッティのようで、ほとんど読み解けない」と評しました。要するに、量は3倍あっても中身は薄く、しかも人間には手入れしづらい状態だった、ということです。

一方で、作った側のCursorのエンジニアは反論もしています。「ただ既存の部品を配線でつないだだけ、という見方には異を唱えたい。JavaScriptを動かす仕組みも、ページの構造を扱う部分も、描画も、この企画の中で本当に作り込んでいる」。完成にはほど遠くても、中身のないハリボテではない、という主張です。Cursor自身も「これはあくまでデモンストレーション」と位置づけており、製品として売り出すものではない、としています。

コードの量と品質のずれ

この一件がおもしろいのは、AIへの過度な期待にも、過度な悲観にも、どちらにも材料を与えるところです。

たしかに、何百ものAIが1週間休まず協調して、300万行という巨大なコードを書き上げ、簡単なサイトなら表示できるところまで持っていった――数年前なら考えられなかった芸当です。「AIは大規模なソフトを猛烈な勢いで生み出せる」という点は、もう疑いようがありません。

ただ、そこで生まれたのは「動くには動くが、後始末は人間が大量に背負う」コードでした。速く大量に書けることと、保守できる質の高いものを作れることは、まだ別物なのです。Gorman氏はこう言います。「コードを吐き出すホースを配管につなげば水量は増える。でも、それでパワフルなシャワーが出るとは限らない。多くのチームは、ホースから出る水圧ばかり測って、シャワーから出る水を見ていない」。書いた行数やコミット数といった”出力の量”は確かに増える。けれど、本当に価値のある製品が増えているか、使う人の役に立っているかは別の指標で測るべきだ、という指摘です。

関連して、開発者の体感とのギャップを示すデータもあります。ある調査では、AIツールを使った開発者は「生産性が上がった」と感じていたのに、実際には平均で19%遅くなっていた、という結果が出ています。手応えと結果が食い違うこともある、というわけです。「AIが1年後にはコードの9割を書く」といった景気のいい予測が飛び交う一方で、現場の実感はもう少し込み入っている、というのがいまの状況のようです。

解釈上の留意点

注意したいのは、これを「AIコーディングはダメだった」という単純な話に縮めないことです。批判していたGorman氏自身、「AIには価値がないか? まったくそんなことはない。私も毎日使っている」と明言しています。彼が懐疑的なのは技術そのものではなく、「これで開発が一変する」という売り文句のほうです。彼の見立てでは、優れた開発チームを支えてきた基本――小さく刻んで進める、こまめに確認する、テストとレビューを欠かさない――は、AIがあっても変わらず効く。「同じゲームを、違うサイコロで遊んでいるだけ」だと表現しています。

もう一つ。これはあくまで「どこまでやれるか試した実験・デモ」であって、製品ではありません。実験の成果を製品の完成度の物差しで測れば見劣りするのは当然で、評価が割れたのも、発表の見せ方と中身の落差が大きかったからという面があります。一つの企業の一つのデモから「AIの実力」を断じるのは早計でしょう。今後モデルや手のやり方が進めば、結果が変わってくる余地は十分にあります。

それでも、現時点での輪郭ははっきりしました。AIは、人間のチームなら数か月かかる規模のものを、桁外れの速さで「とりあえず形にする」ところまで来ている。ただし、その”形”を信頼できる製品に仕上げる工程では、まだ人間の目と手がしっかり要る。便利な道具であることと、丸ごと任せられることのあいだには、まだ距離がある――それを具体例で見せてくれた一件でした。