1 ポイント 投稿者 GN⁺ 2025-12-08 | 1件のコメント | WhatsAppで共有
  • 1996年、ワーナー・ブラザースのスペース・ジャム公式ウェブサイトをAIモデルのClaudeで再現しようとする試みが行われた
  • Claudeにスクリーンショットと元画像アセットを提供したが、生成されたHTMLは原本とレイアウトが一致しなかった
  • 座標推定、グリッド・オーバーレイ/ピクセル比較ツールなどの各種補助ツールを追加したが、Claudeはなお正確な位置計算ができなかった
  • Claudeは自分の結果を「完璧だ」と評価したが、実際には誤差が蓄積し、自己結果への過度な自信を示した
  • この実験はAIの視覚的精度の限界と自己評価の誤りを明らかにしており、初期のウェブデザインの単純さが、再現不可能な複雑性を内包していることを示している

1996年版スペース・ジャムウェブサイトの概要

  • ワーナー・ブラザースが1996年に映画Space Jamの宣伝用として作成したこのウェブサイトは、単一のHTMLページとGIF背景で構成されていた
    • 単純な配色、テーブルベースの構造、容量200KB未満
    • 現在もspacejam.com/1996のアドレスで維持されている
  • 実験者はこのサイトをClaudeがスクリーンショットだけで再現できるかを検証しようとした

実験の準備

  • Claudeに提供された資料
    • ウェブサイト全体のスクリーンショット
    • 元画像アセットのディレクトリ
  • Claudeの内部動作を追跡するため、プロキシ経由のAPIトラフィックロギングシステムを構築した
    • すべてのプロンプト、レスポンス、ツール呼び出し(Read, Write, Bashコマンドなど)を記録
    • 試行ごとにtraffic.logファイルを作成

Part 1: 現実主義者のClaude

  • 最初の試みで、Claudeは惑星の配置とボタン位置を大まかに複製したが、軌道形状は原本と異なった
    • 原本は楕円形の配置だが、Claudeは対称的なダイアモンド形で配置した
  • Claudeは結果を「完璧だ」と評価し、自分の分析と配置が正確であると主張した
  • その後、Claudeに推論ステップを明示的に記述するよう要求したが、
    • 分析段階で示した数値をHTML生成時に反映しなかった
  • ピクセル単位の質問に対してClaudeは
    • 「正確な座標を測定できない」「視覚的推定のみ可能だ」と回答
    • 5ピクセル以内の精度に対する自信度は15/100程度だった
  • Claudeは正確なピクセル測定能力がないことを認めたため、実験者はツール拡張を試みた

Part 2: 信頼できない語り部のClaude

  • Claudeの測定限界を補うため、グリッド・オーバーレイ、座標ラベル、色比較ツール、スクリーンショット比較ビューアなどを追加した
  • Claudeはグリッドを「装飾のように」使い、なお座標を誤って解釈した
    • 例:中心(961,489)、Planet B-Ball(850,165)などの値を提示したが、実際の位置と一致しなかった
  • 複数の反復でClaudeは段階的な改善を主張したものの、実際には誤差が蓄積していた
    • 1回目(50pxグリッド):わずかに移動
    • 2回目(25pxグリッド):全体の軌道が内側に20px移動
    • 3回目(5pxグリッド):微調整を反復
    • 4回目:"精密調整完了"と宣言
  • 実際には惑星軌道の半径が150〜200px不足し、全体配置が圧縮されたまま維持されていた
  • Claudeは繰り返し「ほぼ完璧だ」と評価したが、自己生成結果を基準として誤判断した
  • 実験者はAnthropic論文*「Language Models (Mostly) Know What They Know」を引用した
    • モデルが自分で生成したテキストを外部入力と誤認し過信する現象を説明している
    • Claudeが自分のHTMLを「正解」と見なしてしまい、その後の修正が歪む現象と一致

Part 3: 盲目のClaude

  • Claudeの視覚的限界を分析するため、ビジョンエンコーダの構造的制約を仮定した
    • 画像を16×16ピクセルのブロック単位でトークン化するため、細かな幾何情報が失われる
    • Claudeは「惑星」や「位置関係」などの意味的認識は可能だが、正確な座標は不可能
  • 論文*「An Image is Worth 16x16 Words」を参照し、
    • Claudeが詳細なピクセル情報をパッチ単位で圧縮して認識していると推定した
  • これを検証するために2倍拡大したスクリーンショットを提供したが、
    • Claudeは拡大率を考慮せず、比例関係を維持できなかった
  • その結果、Claudeは概念的理解は正確だが、幾何学的再現能力は不足していると判明した
    • 「この惑星はあの惑星の上にある」という説明は正しいが、HTML配置は引き続きずれていた

結論と未解決課題

  • Claudeはスペース・ジャムウェブサイトの視覚的構造を認識するものの、正確な再現には失敗した
  • 失敗の原因としては
    • ピクセル単位の測定不能
    • 自己生成結果への過信
    • 視覚エンコーディングの解像度限界
  • 今後の試行として提案された項目
    1. 画面を4分割して個別に再現後、結合する
    2. 空間推論中心のプロンプトエンジニアリング実験
    3. ズームツールとスクリーンショット活用能力の強化
  • この実験はAIの視覚的な精度限界と初期ウェブデザインの複雑性の両方を示す事例である
  • 1996年のシンプルなウェブページは、現代AIにとってなお再現不可能なベンチマークとして残っている

1件のコメント

 
GN⁺ 2025-12-08
Hacker Newsのコメント
  • 90年代後半に似たようなウェブサイトを自作していた立場から、Space JamウェブサイトをOpus 4.5に入れてみた。
    元記事の筆者は「絶対位置指定で構成された単一のHTMLページ」だと言っていたが、実際にはテーブルベースのレイアウトだった。CSSがなかった時代なので、そうならざるを得なかった。
    私がテーブルベースで再現してみた結果はこのスクリーンショットにある

    • ありがとう。誤っていた部分は取り消し線で修正し、出典も明記した。
      コメント欄で冗談の流れが続いていたので、文脈のためにそのまま残した
    • あの頃はデザインを分割してテーブルに書き出していたのを覚えている
    • 私もGoLiveでウェブ開発を始めたので、ページをテーブルで組んでいたやり方を今でも覚えている
  • Claude のようなLLMは、依然としてレイアウトの細部実装には弱い。
    ただ興味深いことに、私はClaudeを使って Linux compositor(Hyprland) にガンマカラープロファイル対応を追加するCプログラムを数分で作れた。
    Claudeが生成したコードは最初の試行でそのままコンパイルでき、.icc ファイルを読み込み、VCGTを抽出してamdgpuドライバへ送る機能まで実装していた。
    ただしICCパースのエンディアン問題だけは自分で修正した

    • Claudeが直接コードを書いたのではなく、どこかのコードを持ってきて修正した可能性が高い。人間がやれば盗用と呼ばれていただろう
    • LLMが視覚的な細部に弱い理由は、ピクセル単位のデータが学習に含まれていないからだ。ほとんどのUIデータセットにはスクリーンショットがないか、収集されていない
    • そもそも、なぜこうした機能をWayland compositorが担う必要があるのか疑問だ。Appleはすでに90年代にColorSyncで解決していた
  • Claudeがほぼ完璧だったのに少しだけ足りなかった例だった。
    私は20年前の Mac OS向けabandonware を探してApple Siliconで動くように直すのを趣味にしている。
    たとえばjpegviewはClaudeと一緒に3回コードを修正しただけで動くようになり、その後は動画再生や新しいレイアウト機能まで追加した。
    こういうミニプロジェクトは、ブラウザウィンドウを1つ開いてClaudeのコードインスタンスと一緒に進めるのにちょうどいい

    • 「ほぼよかった」という表現は珍しいように言われるが、実際にはかなりよくある
    • ちなみに最近Macを使い始めたが、Phoenix Slides はかなりよかった
  • 「Claudeだけで復元すべきだ」という主張に対しては、別の方法もある。
    たとえばこのアーカイブファイルをダウンロードしてクラウドに保存しておけばいい

  • 絶対位置指定が可能になったのはCSS2(1998年)からだった。
    Space Jamウェブサイトはalign、valign、colspan、rowspanを活用したテーブルレイアウトだった

    • ありがとう。誤っていた部分は修正し、出典も明記した。冗談の流れが続いていたので文脈のためにそのままにした
    • こうしたテーブルはブラウザ設定、画面サイズ、フォントによって異なる描画になった。
      それこそがウェブ本来の姿、解釈されるハイパーテキストだった
  • こういうテストを試したのか気になる。
    惑星の軌道半径を計算し、各惑星が正確に軌道上にあるかをユニットテストスクリプトで検証するというやり方だ

    • 複雑な作業でLLMを使うと、運が良ければ一発でいけるが、たいていは明示的な指示と反復テストが必要になる。
      結局、LLMをずっと面倒見るくらいなら自分でやったほうが速いことが多い
    • そういうテストは試していないが面白い。ただ、Claudeやライブラリはピクセル単位の判別があまり得意ではないので難しかった
    • 結局私たちは「平文英語プログラミング言語」を作ったわけだ。世界の電力の10%と半導体の40%を使って
    • エージェントが自分で結果を検証できるなら高速に反復できる。そうでないなら何かがおかしい。それでもこのプロジェクトは本当にすばらしい
  • Claudeにウェブサイトの元のHTMLをそのまま入力して「復号」させればいいのでは、と思った。
    サイトは小さいので十分可能そうだ。
    元のコードとレンダリング結果は違うが、Claudeならその差を処理できそうだ。
    結局は複製より再創造のほうがよいアプローチかもしれない

    • 「元のHTML」がそのままソースコードだ。最近のウェブ開発は若い世代を混乱させているようだ
    • 元のHTMLがあるなら、わざわざこんな手順を踏む必要はない
    • このHTMLソースは約7,000文字、Claudeのトークン換算で2,000程度なので十分処理できる
    • Space JamウェブサイトはCSSなしで、テーブルと画像分割によって構成されていた
  • Space JamウェブサイトをLLMベンチマークにしたのは興味深い。
    Claudeはほぼ合っていたが順序が違っており、それは人間が直接直せる部分だ。
    個人的にはGitHub Copilotのほうが安く、GitHub統合もうまくできているのでそちらが好みだ

    • ただし初級開発者が誤った結果に気づけないなら問題になる。こうした失敗は他の場面でも繰り返されうる
    • この記事の要点は、Claudeがピクセル単位の再現に過信しているという点だ
    • 私も何度も試したわけではない。実際、スクリーンショットだけでHTMLを復元するのは非現実的な制約条件だった
    • ユーザーによる検証と修正が必要なツールなら、それはよいツールではない
  • Claudeはスクリーンショット活用能力が弱い。
    マルチモーダルモデルではあるが、強みは依然としてテキスト処理だ

    • 画像をピクセルグリッドではなく意味ベクトル空間に変換するため、ピクセル情報が失われる。
      正しいアプローチは、Claudeに独自の画像処理ツールを作らせて、それを使って座標を計算し、テストを実行させることだ。
      そうすれば反復の安定性と効率はずっと高くなる
    • テキストでも2D構造を把握するのは難しい。たとえばASCIIアートの円を正確な半径で描かせても、うまくいかない
  • 私もClaudeでStorybookコンポーネントの視覚テストを試したが、結果はよくなかった。
    その代わりにPlaywrightのvisionモードとCodexを組み合わせてみたが、視覚的検証ループは結局失敗した。
    関連内容はブログにまとめた