Dance with Agents

LLMが表を作れるのは、表も文章で書けるからだった——組み直して表示しているのは、受け取る側のアプリ

LLMに「この2つを比べて」と頼むと、きれいな表が返ってきます。箇条書き、見出し、コードの枠も同じです。次に来る言葉を当てているだけの装置が、なぜ表やレイアウトまで作れるのか。

先に結論を書きます。LLMは表を作っていません。 表に見える文字列を書いているだけで、それを表の形に組み直しているのは、受け取る側のアプリです。


チャットに表示される表は、届いた時点では1本の文字列

たとえば、こういう表が返ってきたとします。

道具 用途
ハサミ 切る
のり 貼る

LLMが実際に出力したのは、次の文字の並びです。

| 道具 | 用途 |
|---|---|
| ハサミ | 切る |
| のり | 貼る |

縦棒(|)とハイフンと文字だけでできています。これはMarkdownという書式での表の書き方です(Markdown自体については『Markdownってなんだろう』にまとめました)。

LLMの側では、最初から最後まで文字を1つずつ選んでいるだけです。|を選び、道を選び、具を選び……と続いていく。罫線を引く工程は、どこにもありません。

表に見えるのは、ChatGPTやClaudeの画面のほうが、この文字列を受け取ってから表の形に組み直して描いているからです。同じ文字列をメモ帳に貼れば、縦棒だらけの行がそのまま並びます。

表を文字だけで書く方法は、Markdownより前からいくつもあった

表を文字列で表す取り決めは、Markdownが最初ではありません。

書き方 見た目 主な出どころ
HTML <table><tr><td>ハサミ</td> Webページ
CSV 道具,用途 のようにカンマ区切り 表計算ソフトの書き出し
LaTeX \begin{tabular} で始まる記法 論文や数式の多い文書
文字の罫線 +------+------+ を並べる 仕様書、昔のメール

共通しているのは、どれも「文字だけで表を表す」ための取り決めだという点です。 表は紙に描く絵である前に、ずっと以前から文字で書き表せるものでした。だからそれは、文章として読めるし、文章として書けます。

LLaMAの学習データは8割以上がWebページ由来。ただし記法が残っているのは別の出どころ

では、その書き方をどこで覚えたのか。学習データの中身が公開されている例を見てみます。

Metaが2023年に発表したLLaMAの論文(arXiv:2302.13971)には、事前学習——最初に行う大量の読み込み——に使ったデータの内訳が載っています。

出どころ 割合
CommonCrawl(Webページを大規模に収集したもの) 67.0%
C4(同じくWebページを整えたもの) 15.0%
GitHub(ソースコード) 4.5%
Wikipedia 4.5%
書籍 4.5%
arXiv(論文) 2.5%
StackExchange(技術系のQ&A) 2.0%

割合は、学習のときにその出どころをどれだけの比重で使ったかを示す数字です。全体で1.4兆トークン(トークンは言葉を切り分けた単位)が読み込まれています。

ただし、出どころによって記法の扱いが違います。 同じ論文には、それぞれをどう下ごしらえしたかも書かれています。

出どころ 記法の扱い
CommonCrawl・C4(82%) テキストだけを抜き出した形式を使っており、HTMLのタグは残っていない
GitHub(4.5%) ソースコードなので、.htmlも.cssも.mdもそのまま読まれる
Wikipedia(4.5%) リンクや書式の指定を取り除いたと書かれている
arXiv(2.5%) LaTeXの本文を残している(コメントの削除とマクロの展開だけ)
StackExchange(2%) HTMLタグを除去したと明記されている

つまり「Webページを大量に読んだから記法を覚えた」とは言えません。記法がそのまま残っているのは、GitHubとarXivという、割合の小さいほうです。 この点は『LLMが読んだWebページから、HTMLのタグは剥がされている』に詳しく書きました。

それでも、「文章を大量に学習した」という言い方が中身はベタ書きの散文だけだったことを意味しないのは変わりません。割合が小さくても、表・見出し・リンクの指定を含んだ文字列は確かに読み込まれています。表の作り方は、そこに書かれていた見本です。

画面のレイアウトも、HTMLとCSSという文章で指定されている

同じことが、ボタンや余白のような見た目にも当てはまります。

Webページの見た目はCSSという書式で指定します。たとえば padding: 16px; は「内側に16ピクセルの余白を取る」という意味で、color: red; は「文字を赤に」です。どれも絵ではなく、文です。

だからLLMは、レイアウトを描いているのではなく、レイアウトを指定する文の続きを書いています。表と同じ構図で、それを実際の見た目に変えるのはブラウザの仕事です。

LLMは、出力の時点では画面でどう見えるかを確かめていない

ここが限界にもなります。文字列としては正しいCSSを書けても、表示したときに文字がはみ出す・背景と同系色で読めない、といったことは起こります。 見え方を確かめる工程は、文字を予測するという処理の中に含まれていないからです。

画像を読めるモデルにスクリーンショットを渡せば、見え方そのものを判断させることはできます。ただしそれは、文字を出力したあとに別で足している工程です。

表もレイアウトも、文章の範囲を超えていなかった

不思議に見えていたのは、受け取る側のアプリが組み直したあとの姿を見ていたからでした。LLMの側は、最後まで文字を1つずつ選んでいます。

では、本当に文章の外にあるもの——画像や動画は、どうやって作られているのか。そちらは同じ理屈では説明できず、まったく別の訓練が使われています(『画像生成AIは、絵の描き方を習っていない』)。

LLMの仕組みの記事

LLMの仕組みのページへ →