Frame0、HTML、ASCII —— ワイヤフレームの三つの描き方

2026-05-23 · 7 min read

ここ数日、Claude と GPS アプリの設計の話をしていて、「受け入れ半径」をどのくらいに設定すべきかという話になった。20m? 50m? 100m? 数字だけだと感覚がつかめない。図にして比べたい。

先日 Frame0 と ASCII のコストを実測したばかりだが、あれは 93 個の図形を使った複雑な UI ワイヤフレームだった。今回はもっとシンプルで——交差点ひとつと同心円三つ——だが、もう一つ選択肢を比べたい。HTML+SVG だ。

問題はこうだ。AI との会話の中で、この図をどう描くのが良いのか?

                       100 m
                  .------+------.
              .---'             '---.
            .'        50 m           '.
          .'      .----+----.          '.
         /      .'   20 m    '.          \
        /      /   .---+---.   \          \
       |      |   |        |    |          |
  -----+------+---+--------+----+----------+-----
       |      |   |        |    |          |
        \      \   '---+---'   /          /
         \      '.            .'         /
          '.      '----+----'          .'
            '.                       .'
              '---.             .---'
                  '------+------'

三つの選択肢

1. Frame0 —— MCP 経由で AI に作図能力を渡す。図形ライブラリつき、PNG にエクスポートでき、利用者は Frame0 アプリ内で引き続きドラッグ編集できる。
2. HTML + SVG —— ウェブのソースコードを書く。ブラウザで開けば見える。
3. ASCII —— プレーンテキスト。メッセージにそのまま書く。

三つとも「交差点ひとつと同心円三つ」のシーンを描ける。問題は——コストの差はどれくらいか?

実測してみる

同じ画面を AI に描かせた。交差する二本の道、三つの同心円(20m、50m、100m)、ラベルつき。

HTML+SVG 版(ブラウザで開く):

Frame0 版(PNG エクスポート):

ASCII 版は冒頭で見たとおり。三つの版が出揃ったところで文字数を数えた。重要なのは、送信するぶんと返ってくるぶんを両方カウントすること——Frame0 の create_* 呼び出しは、毎回完全な shape descriptor をコンテキストに返してくる。これは見落とせない。

ASCII が最安なのは予想通り。意外だったのは Frame0 と HTML の差が見た目以上に大きいこと——Frame0 は送信側だけでも重いうえに、create_* の返却がもう一度フルデータを返してくるから、往復で送信側のほぼ二倍になる。HTML は書き込みのあと「ファイル書き込み完了」の確認が返るだけで、受信側のコストはほぼゼロ。

表に出していない隠れ支出もある。Frame0 の export_page_as_image は PNG を直接 AI のコンテキストに送り込む。これがだいたい 600–1,500 image token ぶん。HTML にはこの問題はない——ユーザーが自分でブラウザで開くので、画像が AI のコンテキストに入ることはない。

読み返しのコストも

書き出すだけが話の半分。あとで AI がもう一度この画面を読む必要が出たら、それも別途かかる。get_page の返却を実測した:

これは予想より良かった——Frame0 の read-back は入力よりほんの少し大きい程度(id、parent ref、計算済みのジオメトリが追加されている)。倍に膨れ上がるという心配は外れた。

ただ忘れてはいけない。read-back 自体の文字数は怖くないが、read-back できるようにするために、前段の 4,756 字ぶんの round-trip はすでに払い終えている。Frame0 のコストは作成時に一括で払う形で、読み出し時に後払いするわけではない。

コストだけでは判断できない

安いから最良、とは限らない。三つそれぞれに強みがある:

ASCII はメッセージ上で一番ストレート。HTML の強みは diff が取れて、ブラウザで即見え、静的サイトにそのまま埋め込めること。SVG の座標系は Frame0 と同じなので、相互変換も痛くない。Frame0 が本当に元を取れる場面は図形数が多いとき——スマホ枠、ナビゲーションバー、十数個のボタンとリストアイテムからなる本格的な UI モックを描くと、内蔵コンポーネントライブラリが要素ごとの boilerplate を平準化して「全体としてはむしろ安い」になる。この閾値はだいたい 15 個以上の図形あたり、と見ている。

三軸でまとめる

コスト、速度、産出を並べて見る:

読み方:バーが多いほどその軸の度合いが強い——コストが高い、速度が速い、産出が精緻。全体の規律として、安くて速くしたければ産出は軽くなり、産出を精緻にしたければトークンと時間を払うことになる。