- HTMLとCSSをレンダリングできるブラウザを、わずか3日で1人の人間と1つのLLMエージェントがRustで直接実装
- プロジェクトは約20,150行のコードで完成し、スクロール・戻る・ヘッドレスモードなどの基本機能を含む
- 外部Rustライブラリなしで、Windows、macOS、Linuxで動作するよう設計
- 開発プロセスはCodexエージェントとの協業で進められ、人間は調整と検証を担当し、エージェントはコード作成を担当
- 結果として、**「1人の人間 + 1つのエージェント」**の組み合わせが、多数のエージェントより効率的であることを示す事例
プロジェクト概要
- 目標は、HTMLとCSSをレンダリングできる基本的なブラウザを完全にゼロから作ること
- JavaScriptはサポートしない
- 開発者は「楽しみ半分」で始め、LLMエージェント（Codex）と協業して進行
- 3日以内の完成、外部Rust依存の禁止、主要3 OS対応などの制約条件を設定
- ブラウザは独自のレンダリングエンジンを備え、スクリーンショット機能、リンククリック、回帰テスト機能を含む
Day 1 – 初期実装
- 「Hello World」のレンダリングから始めて、ネストしたタグの処理とスクリーンショット機能を追加
- HTML/CSS仕様を定義し、E2Eテストのために画像比較機能を導入
- 1日でX11とcURLを使ってWebサイトを取得してレンダリングする段階まで到達
- コードベースは約7,500行、すべてのファイルは1,000行以下に維持
Day 2 – 機能拡張
- テスト中にウィンドウが開く問題を解決するため、
--headlessモードを追加
- ウィンドウサイズ変更、互換性、性能、フォントレンダリングを改善
- ワークフローは、Webサイトのスクリーンショットを共有し、それをCodexが再現する方式
- コードの大半はエージェントが作成し、人間はレビューと承認を担当
Day 3～4 – 完成とクロスプラットフォーム対応
- スクロール、デバッグログ、戻るボタンなど、ブラウザに必須の機能を追加
- macOSとWindows対応を実装し、テストを通過
- CI統合とリリースビルドを完了し、総開発時間は約72時間
結果とコード統計
- 最終コードベースは約20,150行、72ファイルで構成
- 主要ファイルには
layout、style、platform、browserモジュールなどを含む
- Cargo.lockが空であり、つまり外部Rustパッケージなしで完全に独立実行可能
- GitHubでCIビルド済みバイナリとソースコードを直接ダウンロード可能
主な教訓
- 1人の人間 + 1つのエージェントの組み合わせは、数千のエージェントを使うより効率的
- 単一のエージェントが長時間1つのコードベースを扱いながら実質的な前進を達成できる
- 複数の人がそれぞれエージェントを持つ形へ拡張できる可能性がある
- 速度を落とすことが、むしろより速くより良い結果を生むことがある
- エージェントを操る人間の役割は、システム設計より重要かもしれない
- 結論として、「複数のエージェントを投入すれば開発は加速するのか？」という問いに対し、
単一の人間とエージェントの協業の方が、より現実的で効率的である可能性を示す事例である
4件のコメント
私がよく分かっていないのでお聞きしたいのですが、Hacker News の意見に出てくる
Simonのブログって、いったいどんなブログだからそんなにたびたび言及されるのでしょうか……？Simon Willison が投稿したブログ記事が Hacker News でよく話題になる理由は、おそらく、
Hacker Newsで2025年に最も人気だったブログ の中で1位だったブログですね。知名度も知名度ですし、掲載される記事数もかなり多いため、一般的なHacker Newsユーザーの立場では最も頻繁に訪れるブログであり、自然と指標のように見なされているのではないかと思います。
Hacker Newsのコメント
CursorのFastRenderよりはるかに優れたコード生成ブラウザのデモだと思う
Rust約2万行とかなり小さく、画像・テキスト描画にはシステムライブラリだけを使っていて、コードも読みやすい
たとえばflexbox実装コードを見ると明快
私のブログを描画したスクリーンショットも載せたが、CSSグラデーションとSVGアイコンはうまく処理する一方で、PNGは失敗する
HTML+CSSを描画するブラウザは並列エージェント実演に最適な課題だと思っていたが、1人のコーディングエージェントでも可能だったのは驚き
重要なのは単にトークンを多く使うことではなく、エージェントを効果的に活用する方法だ
私も複数のプロジェクトを生成したあと、数日して捨てたことが何度もある。エージェントはフィードバックなしでは言われた通りに動くだけなので、方向が間違っているとむしろさらに深い穴を掘ってしまう
Claudeがとんちんかんな方向に進んでも、正しいエージェント構造があれば立て直せる
私はいま評価者・研究者・実装者エージェントを分離した実験を進めている
スコアを基準にテストを拡張したり失敗原因を調査させたりし、改善がなければコミットを破棄する
こうした構造のほうがコード品質管理にはるかに有利だ
コードが安く、捨てられる時代には、ワークフローそのものが変わるべきだ
1人+1エージェントが500万ドル、160万LOCのブラウザに勝つ**『ダビデ対ゴリアテ』のような話に感じる
AIはいまなおブラックボックス**で、誰もが実験しながら方向を探っている
2026年はもう1か月経ったが、これからどんな実験が出てくるのか興味深い
SimonがHNの2026年予測スレッドを定期的にレビューしたら面白そうだ
3日という制限を設け、RustのサードパーティcrateなしでOS標準ライブラリだけを使ってX11/Windows/macOSをサポートするというルールを定めた
約2万LOCで完成し、そのうち1.4万行がエンジン、6000行がプラットフォーム対応コードだ
ソースコードとバイナリを公開した
今は機械可読なテストスイートのおかげでずっと効率的だ
昔はIEの挙動が事実上の標準だったが、いまはGoogleやAppleなどが標準化に貢献していて、はるかに良くなった
機能とは別に、こういうコードベースのセキュリティ監査が気になる
Rustは助けになるだろうが、言語保証だけで十分なのか疑問だ
Rustは基本的なメモリエラーを防ぐだけで、ローカルファイルアクセスのようなものは防げない
JSエンジンがないのでデータ流出は起こしにくいが、監査すれば深刻な脆弱性がいくつも見つかりそうだ
コミュニティがbrowserBenchを待ち望んでいたが、ついに始まってうれしい
ブラウザは最も複雑なソフトウェアのひとつなので、こうした試みは限界評価の基準点になるはずだ
2万行でブラウザを作るというのがあまり想像できない
zlibだけでも1.2万行なのに、何か抜けているのではと思ってしまう
OSの描画呼び出しだけをしているのか気になる
どのライブラリを使っているかはREADMEに明記されている
自分で動かしてみたところ、描画はかなり混乱している
リンクの色や下線に一貫性がなく、Windowsでは戻るボタンが動かない
それでもHNのホームページやSimonのブログはかなりうまく描画している
LOCを少なく保ちながら似た機能を実装するのが目標だった
デフォルトスタイルシートがないのでリンク色が一定ではない
Windows 11では戻るボタンは動作する。もしWindows 10なら、それが原因かもしれない
Simonのブログを描画することがAIブラウザの代表的な目標になりそうだ
ただ、まだ本物のブラウザというよりレンダラーの段階だ
Servoのようなプロジェクトで、AIがAPI実装を補完する方向のほうがより印象的だろう
それでもCursorの試みよりは良く、**「コンパイルできる」**という点は最低限の前進だ
1人でやっていたらどれくらいかかったのか気になる
エージェントの助けを理解するには、そのガイドに注ぎ込まれた専門性の深さを知りたい
Rustは分かるが、X11やmacOS、Windows APIは知らなかったので、そもそも始めるのも難しかったはずだ
ただ、テスト・インフラ・設計の経験が多かったので、エージェントと協業するうえで助けになった
このプロジェクトは2000年基準で4.58人年、61万ドル、
2025年基準では5.6年、138万ドル規模と推定される
この記事が興味深いのは、成果物ではなく作る過程と制約条件に焦点を当てているからだ
たいていの記事は成果物や作者に注目するが、これはプロセス中心の洞察を与えてくれる
だから、何が本当に難しい部分なのか、どの過程が誤っているのかを探るほうがより意味があると感じた
印象的な仕事だ
アクセシビリティ(Accessibility) をRust依存なしで実装するにはどうすればいいのか気になる
Windows/macOSではUI AutomationとNSAccessibilityで可能だが、X11では