JustHTMLをPythonからJavaScriptへ移植、Codex CLIとGPT-5.2で4.5時間で完成

 (simonwillison.net)
7 ポイント 投稿者 GN⁺ 2025-12-19 | 1件のコメント | WhatsAppで共有
  • HTML5パーサー JustHTML をPythonから JavaScriptへ完全移植 した事例で、Codex CLIとGPT-5.2を使って約4.5時間で実装
  • 新ライブラリ JustJSHTML は 依存関係のないHTML5パーサー で、html5lib-testsの 9,200件のテストを通過 し、元のAPI設計をそのまま再現
  • 全工程は 8つのプロンプト と数回の追加コマンドで進み、GPT-5.2が 9,000行のコードと43件のコミット を自動生成
  • プロジェクトは 自動コミット・テスト・ドキュメント化・プレイグラウンドページ生成 まで含め、完全なオープンソースとして完成
  • 今回の実験は LLMベースのコーディングエージェントの実質的な生産性 を示す一方で、著作権・倫理・信頼性の問題 も新たに提起

プロジェクト概要

  • JustHTML はEmil Stenströmが開発した 標準準拠のHTML5パーサー で、Pythonで書かれ、html5lib-tests全体を通過する実装
    • html5lib-testsはHTML5パーサー間の 相互運用性テストの標準 で、Servoのhtml5everなどさまざまなプロジェクトで利用されている
  • Simon Willisonはこのプロジェクトを JavaScriptへ直接移植 することを決め、Codex CLIとGPT-5.2を活用して最小限の手作業で進めた
  • 成果物の JustJSHTML は ブラウザとNode.js環境の両方で動作 し、外部依存なしの純粋なJavaScript で書かれている

開発プロセス

  • ローカル環境でjusthtml、html5lib-testsのリポジトリをクローンし、新しいディレクトリjustjshtmlを作成
  • Codex CLIを --yolo オプション（承認およびサンドボックス回避）で実行し、GPT-5.2モデルを起動
  • 最初のプロンプトでは既存のPythonコードを分析し、新しいJavaScript API仕様書（spec.md） を作成するよう指示
    • 初期段階（Milestone 0.5）として、簡単なHTML文書の解析テスト を通過するバージョンを実装
  • その後は段階ごとに「Implement Milestone 0.5」「commit and push often」などの命令によって自動開発を進行
    • GitHub Actionsを設定し、すべてのコミットごとにテストを実行
    • 合計 43件のコミット、9,000行のコード、9,200件のテスト通過 という結果を生成

結果と成果物

  • Codex CLIは合計 2,089,858トークン を使用し、ChatGPT Plusの月額サブスクリプション内で追加費用なしに実行
  • 完成したライブラリには次の機能が含まれる
    • stream()、query()/matches()、toMarkdown() などのAPI拡張
    • 依存関係なしの単体テストスクリプト とCI統合
    • <br> タグ処理の不具合修正など、細かなバグ対応
  • playground.html を自動生成し、ブラウザから直接テスト可能
  • README.md には使い方、ビルドプロセス、Node.jsおよびHTML環境の例が含まれる

LLM活用の示唆

  • GPT-5.2 は数百回のツール呼び出しと数時間にわたる連続作業を 最小限の監督で完遂
  • テスト駆動で問題定義 できる場合、コーディングエージェントは 高い完成度のコードを自律的に生成 できる
  • 言語間移植 のような構造的作業は、LLMが非常に効率よく実行できる
  • コード生成コストは事実上 「ほぼ無料」レベル まで低下した一方、検証済みコードの維持コスト は依然として残る

提起された倫理的・法的な問い

  • RustおよびPythonの元コードに対する 著作権侵害の有無
  • LLMが生成したコードの 著作権帰属の問題
  • このような開発手法が オープンソース生態系に与える影響
  • 自動生成コードの信頼性 と 本番利用における責任
  • 人間の専門家が数か月かけて開発したコードとの 品質比較の可能性

結論

  • 今回の事例は プログラミング自動化の新たな段階 を示し、AIコーディングエージェントの実用的な可能性 を証明した
  • 同時に、法的・倫理的基準整備の必要性 と オープンソース協業のあり方の再定義 という課題も残した

関連記事

1件のコメント

 
GN⁺ 2025-12-19
Hacker News のコメント

  • 今回の事例で最も興味深いのは、言語非依存のテストに基づくライブラリ移植プロジェクトが、はるかに現実的に可能になった点だ
    核心は、html5lib-tests という 9,000 件以上の HTML5 パーサーテスト集にある
    Servo の html5ever(Rust)、Emil の JustHTML(Python)、そして私の JavaScript 版はいずれもこのテストを利用している
    コーディングエージェントを使って Python コードを JavaScript に移植し、すべてのテストに通るまで自動で反復実行させることができた
    このような標準化されたテストスイートは珍しいが、存在する場所では大きな可能性を示している

    • WHATWG 仕様と html5lib テストを組み合わせると、さらに強力になる
      私は昨日、数時間で型注釈付きの OCaml 版を作り、純粋な OCaml の HTML5 validator を自動ビルドするようエージェントを走らせている
      html5lib テストと validator テスト を組み合わせて、依存関係の少ない OCaml HTML5 validator を作っている
      これはまるで逆向きの形式検証のように感じる — 散在する事実(テスト)から構造化された仕様へと収束していく過程だ
    • 昨日は Python から Rust に移植していたが、LLM は問題をまったく見つけられなかった。結局、Python の原本を Rust プロジェクトにコピーして比較したら、すぐに解決した
      言語間のパターンマッチングにはかなり強いようだ。潜在空間(latent space)の観点から見ると納得できる
    • 次の段階は、プロジェクト依存のテストを独立フォーマットに変換して、原本と照合したうえで移植するプロセスになりそうだ
    • LLM は言語間の移植に非常に強い。MLE-Bench のようなベンチマークでは、エージェントが 24 時間以内に Kaggle コンペでメダル圏の成果を出す水準にある
      AI4AI 論文 のように、AI が AI を作る時代がすでに始まっている感じがする
    • こうした理由から、現在のプロジェクトのテストは公開しないことにした。普段はオープンソースで配布するが、今回は再考している

  • 実際、Firefox の HTML5 パーサーはもともと Java で書かれ、その後半自動的に Gecko 向けの C++ に変換された
    JustHTML の移植自体は良い実験だが、個人的には Java コードを TypeScript に移したほうが生産的だった気がする

    • 驚いたことに、Firefox の Java パーサーは今もまだ保守されている
      関連フォルダ と 最近のコミット を見ると、11 月にも更新があった
    • もっと良い方法はいろいろあったが、Emil の API デザインが気に入ったので JustHTML をベースにした
      彼が 1,000 件以上のコミットで作り上げたライブラリを、一晩で Python に移植してみるのは面白かった
    • 法的観点から見ると、言語を変えて移植したコードも依然として派生著作物だ
      MIT ライセンスなら、元の著作権表示とライセンス文言をそのまま含める必要がある
      つまり、元の著作権行の下に自分の著作権情報を追加するのが正しい
    • デバッグと監査の観点では、JavaScript で書くほうが良いと思う
      TypeScript の利点は開発者体験の改善だが、機械生成コードではその必要性が薄れる

  • 「コードはほぼ無料だ」という言葉については、実際のコストは人間がそのコードを理解し修正できるかにかかっている
    LLM が作ったコードでも、結局は複雑なバグや文脈の問題では人間の介入が必要だ

    • とはいえ、いつかは保守するより作り直すほうが安くて速い世界が来るかもしれない

  • 元のリポジトリのテスト結果を見ると、html5lib-tests の 9,000 件のテストをすべて通過している
    ただしブラウザごとに処理方法は異なる。たとえば selectolax は html5lib 基準では 68% だが、Chrome と比較すると 90% 以上一致する

    • これは名前空間処理の問題だ。<svg title> は SVG 専用タグなので、パーサーがそれを認識しなければならない
      Chrome でもテストを回してみると面白そうだ

  • 最近 HN に上がった "ソフトウェアのコストは 90% 下がった" という記事とも文脈がつながっている

    • ただし、その記事は単純化された主張だ。Simon の実験が可能だったのは、言語非依存の 9,000 件のテストと既存の API 設計があったからだ
      ほとんどのプロジェクトにはこうした条件がないため、一般化は難しい

  • 著作権と倫理の問題について、私は MIT ライセンスのプロジェクトを Claude Code で Rust/Python 版へ移植している
    オープンソースの精神とは、既存コードを改善しながらエコシステムを発展させることだと思う
    ただし、GPL プロジェクトは絶対に移植しない

    • どんなライセンスであっても著作権は尊重すべきであり、LLM が作った移植も派生著作物と見なされる
    • GPL を選んだ開発者には明確な意図があるので、LLM を使ってライセンス回避を試みるのはその精神を損なう行為だ

  • 「このやり方で作ってから法的・倫理的問題を問うのは無責任だ」という批判もあった

    • しかし私は、この議論を引き起こすためにあえてリスクを取った
      今は、こういうことが「可能なだけでなく、驚くほど簡単だ」と示すことが重要だと思う

  • オラクルアプローチを使えば、標準テストがなくても実用的だ
    元のプログラムの入力/出力をキャプチャしてテストにし、Hypothesis のようなツールで何千件ものケースを自動生成できる
    いまやコードベースではなく、テストスイートそのものが中核資産になる時代だ

    • 実際、テストだけでアプリ全体を作れるのではないかという気もしてくる

  • GPT-5.2 が 9,000 行の完全な JavaScript コードを生成するのに $28.31 かかった
    この効率なら、5〜10 年以内にジュニア〜ミドル級の開発者の役割は大きく縮小しそうだ
    コスト計算リンク 参照

    • ただし、これは既存プロジェクトを移植する理想的な事例だ。新しいライブラリをゼロから作るのは依然として別の話だ
      それでも、小さなエコシステムしかない言語には大きな経済的変化が起きるだろう
    • 「ソフトウェアエンジニア」という概念は消えず、役割と期待値が変わるだけだ
    • 「私たちが一日中やっていることは言語移植だけなのか」という反論もあった。現実はもっと複雑だ

  • すべての AI 移植が成功するわけではない。失敗例もある → The port I couldn’t ship

    • 成功するかどうかは、ソースコードに対するテスト比率に大きく左右される
      どのプロジェクトが簡単で、どのアプローチが速いのかというデータが蓄積されれば、興味深い分析になりそうだ
      Simon がこうした比較実験をしてくれたら、本当に面白いと思う