【waka-gen-model】
「和歌」の小さな生成AIを作った
（小規模言語モデル）

by

関連記事

1. シンプルな「生成AI」を作った

シンプルな和歌生成AIを作りました。

その動作を見ると、「和歌を理解して詠んでいる人工知能」ではないことがわかります。
やっていることは、「これまでの文字列を見て、次に来る文字の確率を計算する小さな言語モデル」です。

1. シンプルな「生成AI」を作った

とはいえ、乱数を並べているわけではありません。
179,019首のひらがな和歌から、文字の並び方・句切れの位置・よく現れる音の流れを数値パラメータとして学習した、本物の小型Transformerです1。
語彙90、最大系列長128、総パラメータ数95,040のdecoder-only Transformerとして実装されています2。

1. シンプルな「生成AI」を作った

1.1. 文字を番号に変換する

1.1. 文字を番号に変換する

モデルはそのまま「文字」を処理しているわけではありません。
「あ」「き」「の」「た」のような文字を、内部では番号として扱います。
この番号化を「トークン化（tokenization）」といい、モデルが扱う最小単位を「トークン（token）」と呼びます。
この実装では1文字が1トークンに対応しています3。

和歌の開始を表す<bos>、終了を表す<eos>、句切れを表す<sep>も特別なトークンとして使われています。
モデルにとって和歌は、文字と記号からなる番号列です。

1.2. 次の一文字を予測する

言語モデルの核心は「これまでの文字列が与えられたとき、次の1文字は何か」という問いに答えることです。

1.2. 次の一文字を予測する

「はるすぎて」まで与えられたとき、次に「あ」が来やすいのか、「な」が来やすいのか、<sep>で句切れるのかを確率として出します。
返すのは「正解の一文字」ではなく、候補全体に「どれくらいありそうか」を割り振った確率分布です。

学習はこの「次文字当て」の繰り返しで成り立ちます。
和歌のトークン列を少しずつ切り出し、入力を「ここまでの文字」、正解を「その次の文字」として学びます。
入力が「はる」なら正解は「す」、入力が「はるす」なら正解は「ぎ」という1文字ずらしの関係を、大量に処理します。

損失関数には「スパース・カテゴリカル交差エントロピー（sparse categorical cross entropy）」が使われています。
交差エントロピーとは、正解文字にどれだけ高い確率を置けたかを測る誤差です。
正解文字の確率が低ければ損失（loss）は大きくなり、確率が高ければ小さくなります4。

2. 学習で変わるのは重み

学習によって変わるのは「規則」ではなく「重み」、つまりモデル内部の数値パラメータです。
この実装では約9.5万個の数値があります。

2. 学習で変わるのは重み

学習前の損失は4.5707で、語彙90個をほぼ一様に予測している状態に近い値です5。
学習後には2.7517まで下がり、次文字分布の規則性をある程度つかんだことを示します。
ただし、損失が下がることと文学的に優れた和歌が生成できることは別の話で、この点は実装でも明確に制限として述べられています。

2.1. モデルサイズとデータサイズ

2.1. モデルサイズとデータサイズ

モデルのファイルサイズは約380KBです。
95,040個のパラメータをfloat32（1値あたり4バイト）で保持すると約370KBになります。
学習に使った和歌データは約39.4MBなので、比率は100対1です。

2.1. モデルサイズとデータサイズ
2.1. モデルサイズとデータサイズ

この差は、モデルが個々の和歌を保存していないことを意味します。
学習中にモデルがやっていることは、「この文字の次にこの文字が来やすい」という傾向を、179,019首を通じて平均化することです。
1首しか現れない珍しい表現は薄まり、繰り返し現れるパターンだけが重みとして残ります。

waka-search.jsonl と weights.binのテキスト表現
2.1. モデルサイズとデータサイズ
waka-search.jsonl と weights.binのテキスト表現

性質としては非可逆圧縮に近いです。
JPEGが人間の目が気づきにくい細部を捨てて画像を圧縮するように、このモデルは繰り返されない情報を捨て、統計的な傾向だけを保持します。
元の和歌データは復元できません。

95,040個のパラメータには、39.4MB分の情報を丸ごと入れる容量がありません。
この容量の制約が、結果的にモデルへ「丸暗記ではなく一般化」を強制しています。

逆に、数千億パラメータ規模のモデルでは、学習データを部分的に記憶してしまうことが知られています。
パラメータ数が増えるほど、個別の事例をそのまま保持できるようになるためです。
この和歌モデルの小ささは、純粋な統計学習の動作を観察しやすい規模でもあります。

3. モデルの内部構造

3. モデルの内部構造

3.1. パラメータ数の内訳

95,040という数は、「モデルの中で学習によって変わる数値」をすべて足した数です。
語彙90、埋め込み次元64、最大系列長128、Transformerブロック2層という構成から、次のように積み上がります。

3.1. パラメータ数の内訳

まず、文字を64次元ベクトルに変換する表です。

token embedding = 90 × 64 = 5,760

次に、位置情報の表です。

position embedding = 128 × 64 = 8,192

Transformerブロックは2個あります。
1ブロックあたり37,600なので、

Transformer blocks = 37,600 × 2 = 75,200

ここに最後の正規化層と出力層を足します。
「LayerNorm（Layer Normalization：層の値を整える処理）」は各次元に倍率とずれの2つの値を持つため、64次元×2=128です。

final LayerNorm = 64 × 2 = 128
output projection = 64 × 90 = 5,760
Code language: PHP (php)

output projection は64次元の内部表現を、90個の文字候補の点数に変換する表です。合計はこうなります。

5,760 + 8,192 + 75,200 + 128 + 5,760 = 95,040

1ブロックの37,600をさらに分解すると次のようになります。
「QKV（Query・Key・Value）」とはAttentionが「どこを見るか」を計算するための3種類の変換で、64次元からQ・K・V合わせて192次元へ変換します。

LayerNorm 2個         = 256
QKV projection        = 64 × 192 + 192 = 12,480
Attention output proj = 64 × 64 + 64   =  4,160
MLP up                = 64 × 160 + 160 = 10,400
MLP down              = 160 × 64 + 64  = 10,304

256 + 12,480 + 4,160 + 10,400 + 10,304 = 37,600

つまり95,040という数字は、学習で調整される重みの表のマス目数と「bias（バイアス：補正値）」をすべて数え上げたものです。

3.2. 埋め込みと位置情報

最初にあるのが「埋め込み（embedding）」です。
文字IDを64次元の数値ベクトルに変換する表で、「あ」と「き」にはそれぞれ異なる64個の数値が割り当てられます。
文字を計算しやすい形に置き換えるための仕組みです。

これに「位置埋め込み（position embedding）」が足されます。
同じ「あ」でも1文字目と10文字目では役割が異なるため、その位置情報を数値として与えます6。

3.3. 自己注意機構

Transformerブロックの中心にあるのが「自己注意機構（self-attention）」です7。
ある位置のトークンが、過去の各トークンにどれくらい重みを置くかを計算します。

3.3. 自己注意機構

和歌の後半で次の文字を決めるとき、直前の文字だけでなく前の句切れや冒頭の音が参照されることがあります。
self-attentionはそうした「どの過去位置をどの程度参照するか」を「head」と呼ばれる単位ごとに計算します。
headとは同じ入力を別の観点から見る小さな注意機構のことで、この実装では各ブロックに2つあり、ブロックは2層あります8。

注意が必要なのは、attentionの重みが高いからといって「その文字が理由で次の文字が選ばれた」とは言い切れない点です。
attentionは参照の重みを表しますが、その後にはvalue projection、output projection、残差接続、MLP、最終出力層が続きます。
実装でもattentionを「理由そのもの」とは呼ばず、「参照分布」として扱うべきだとしています。

3.4. MLPと出力

Transformerブロックのもう一つの要素が「MLP（multi-layer perceptron：多層全結合ネットワーク）」です。
attentionが「どこを見るか」を扱うなら、MLPは「見た情報をどう変換するか」を担います。
64次元の情報をいったん160次元に広げ、「GELU（Gaussian Error Linear Unit）」という活性化関数を通して、また64次元に戻します。
GELUは入力をなめらかに通したり弱めたりする関数です9。

最後にモデルは語彙90個それぞれに点数を出します。
この点数を「ロジット（logits）」と呼び、まだ確率ではありません。
「ソフトマックス（softmax）」という変換を通すと、90個の候補に合計1になる確率が割り振られます。
最も高い確率の文字を常に選ぶこともできますが、この実装では確率に従ってくじ引きをする「カテゴリカルサンプリング（categorical sampling）」を使います。

3.5. 自己回帰生成

推論時には、次の手順を一文字ずつ繰り返します。

3.5. 自己回帰生成

ユーザーが入力した冒頭をトークンに変換し、モデルが次の1文字の確率分布を出します。
その確率に従って1文字を選び、入力の末尾に追加する。
追加後の文字列をまたモデルに入れ、次の1文字を予測します。
これを<eos>が出るか、表示上限64文字などに達するまで続けます。

この方式を「自己回帰生成（autoregressive generation）」といいます10。
自分が直前に生成したものを次の入力としてまた使う、という意味です。

生成時には「温度（temperature）」という設定も使えます11。
温度が低いと高確率の文字が選ばれやすく、出力は安定します。
温度が高いと低確率の候補も選ばれやすくなり、出力は多様になりますが崩れやすくもなります。
「創造性のつまみ」と説明されることもありますが、正確には確率分布をどれくらい平たくするかの調整です。

4. 可視化の仕組みについて

Web APIは各生成ステップごとに、生成済み文字列・上位候補の確率・各ブロックのRMS集約値・attentionヘッドごとの参照確率を「NDJSON（newline-delimited JSON）」で逐次配信します12。
NDJSONとは1行ごとにJSONを流す形式で、生成中の内部状態を一文字ごとにブラウザへ送るために使われています。

4. 可視化の仕組みについて

「RMS（root mean square：二乗平均平方根）」はここでは層全体の反応の大きさを要約する値です。
ただしRMSは「このニューロンが発火した」という個別の説明にはなりません。
実装では実際のattention値を持つトークンとheadの間のエッジと、RMSのような集約値しかない層レベルの表示を区別しています。

生成結果だけでなく、学習run・checkpoint・loss・attention・候補確率・RMSを観察可能にしているのが、この実装の特徴です

4.1. モデル規模と生成品質

95,040パラメータで和歌らしい文字列を生成できるのは、対象領域が非常に狭く絞られているからです。

語彙は90、出力はひらがな中心、長さは短く、和歌という形式自体が強い制約として機能します。
英語の自由作文や対話と比べると、学ぶべき空間がはるかに小さい。

Shannonはすでに「言語を次の文字の予測として扱い、文字の出現頻度と前後関係だけでも、ランダムよりずっと言語らしい列が出る」ことを示していました13。
和歌という対象への限定は、その考え方の現代的な縮小版です。

学習環境もひとつの制約でした。
このモデルはIntel Pentium P6200（2コア、メモリ3.6GiB）という古いパソコン上で動くために規模を絞っています。
生成品質の最大化ではなく、生成AIの動作原理を小さなハードウェアで観察することが目的です。

現在のモデルが出せるのは、和歌らしい音の連なり、句切れの位置、頻出語句の再構成です。歌意の一貫性や深い比喩、主題の展開は期待しにくい。「TinyStories」の研究では、語彙や内容を強く制限したデータなら、1,000万パラメータ未満のモデルでも一貫した短文生成が可能だと示されています14。今回の和歌モデルも近い状況にありますが、TinyStoriesでも中心的なモデルは95kより大きな規模です。

「スケーリング則（Scaling Laws）」の研究では、損失はモデルサイズとデータ量を増やすほど予測可能に下がるとされています15。Chinchillaの研究でも、モデルサイズと学習トークン数はバランスよく増やす必要があると示されました16。現在のモデルは学習データ量に対してパラメータが少なく、過学習しにくいかわりに表現力が足りない状態にあります。

目的別の参考規模を示します。

目的目安のパラメータ数
教育用・内部可視化・動作原理の実演10万〜30万
和歌らしいリズムや句切れを安定させる50万〜100万
生成文の破綻を減らす100万〜300万
歌意・情景・語彙のまとまりも少し狙う300万〜1,000万

生成品質を上げるなら、次の実験候補は50万〜100万パラメータが妥当です。float32でのファイルサイズが約2〜4MBに収まり、ブラウザや軽量環境でも扱えます。句切れ・語感・局所的な文脈保持は、現在の5〜10倍のパラメータでかなり改善する可能性があります。いきなり数千万パラメータへ飛ばすより、段階的に検証するほうが原因の切り分けがしやすくなります。

品質の判断には、学習lossではなくvalidation lossを見ます。validation lossとは、学習に使っていない検証データでの誤差です。これが下がるなら、モデルを大きくする意味があります。学習lossだけ下がってvalidation lossが悪化するなら、個別の和歌を丸暗記する方向に進んでいます。

現在の95,040パラメータは「小さすぎて無意味」ではありません。狭い対象に対して「次の文字の確率予測」という動作原理を観察するには、むしろ適切な規模です。loss・attention・候補確率をすべて追えるのも、小さいからこそ可能なことです。

4.2. スケールの現実

学習データ667万トークンに対してChinchillaの最適比を当てると、約1Mパラメータが適切な規模になります。ただしこのパソコンで1Mパラメータを動かすと、1ステップあたり約53秒かかります。プラトーまでの推定8,000〜15,000ステップを乗じると、実時間で5〜9日の連続稼働です。

計算量はパラメータ数とデータ量の掛け算で増えます。パラメータを10倍にすれば1ステップの時間も約10倍になり、Chinchillaの最適比に従ってデータも増やすなら総学習時間は二乗で膨らみます。データ量が固定された今回の設定でも、1Mパラメータへの拡張は現行の約10倍の時間を要します。

一方で、2026年時点のChatGPTやClaudeのパラメータ数は非公開ですが、推定値ベースで数百億から数兆規模とされています。この和歌モデルの95,040パラメータと比べると、100万倍から1,000万倍の差があります。1Mパラメータに拡張しても、その差は縮まりません。

ただし、その差はそのまま「劣っている」を意味しません。ChatGPTやClaudeは英語・日本語・コード・対話・推論など膨大な用途を1つのモデルで扱うために、その規模が必要です。
和歌のひらがな列を次の一文字ずつ予測するという課題は、それよりはるかに狭い。狭い問題に対して、パラメータ数95,040という制約は「動作原理を観察しながら学習を完走できる」という点でむしろ合理的な選択です。

  1. Transformerは2017年にVaswani et al.が発表した論文「Attention Is All You Need」で提案されたアーキテクチャで、RNNや畳み込み層を使わずattention機構のみで系列変換を実現した。発表時の衝撃は大きく、現代の大規模言語モデルの多くがこの構造を基盤としている。 – Attention Is All You Need
  2. decoder-only Transformerはエンコーダなしでデコーダだけを積み重ねた構造で、OpenAIのGPT-1（2018年）が代表的な実装例。次トークンを予測する自己回帰学習に適した設計となっている。BERTなどエンコーダ型、T5などエンコーダ・デコーダ型と並ぶTransformerの主要な変種のひとつ。 – Meet GPT, The Decoder-Only Transformer
  3. 文字レベルのトークン化は語彙サイズを小さく抑えられる一方、系列長が長くなりやすい。現代の大規模言語モデルは多くがBPE（Byte Pair Encoding）などのサブワードトークン化を採用しており、語彙の柔軟性と系列長のバランスを取っている。ひらがなのみで構成される和歌コーパスでは、文字レベルでも語彙サイズが極めて小さく収まる。 – BPE vs WordPiece vs SentencePiece: A Beginner-Friendly Guide to Subword Tokenization
  4. 交差エントロピー損失は情報理論に由来する指標で、言語モデルの学習目標として広く使われている。正解トークンのマイナス対数尤度の平均として計算され、モデルが正解に高い確率を割り当てるほど損失が下がる。 – Cross Entropy Loss in Language Model Evaluation
  5. 一様分布を仮定したときの理論的な初期損失はln(V)となる（Vは語彙サイズ）。語彙90個の場合はln(90)≈4.4998 natsで、この実装の初期損失4.5707はこの値に近い。初期損失がln(V)から大きく外れている場合は、初期化・データ前処理・モデル構造のいずれかに問題がある可能性を示すサニティチェックとして機能する。 – Cross-Entropy Loss: Information Theory for Language Model Training
  6. 元のTransformer論文では正弦波関数（sinusoidal）を使った位置エンコーディングが提案されたが、学習可能な位置埋め込みとの比較実験でほぼ同等の結果が得られることも示されている。GPTなど多くのdecoder-only モデルは学習可能な位置埋め込みを採用している。 – Attention Is All You Need
  7. self-attentionは「Attention Is All You Need」（Vaswani et al. 2017）で中核として提案された機構。系列の各位置が他のすべての位置との関連を並列に計算するため、RNNのような逐次処理と異なり、長距離依存関係を直接参照できる。 – Attention Is All You Need
  8. 元のTransformer論文ではh=8のattention headを使用した。複数のheadを持つことで同じ入力を異なる部分空間で参照でき、多様な関係を並列にキャプチャできる。この実装の2 headは、総パラメータ数95,040という小規模なモデルサイズに合わせた設定。 – Attention Is All You Need – A Deep Dive
  9. GELUはDan HendrycksとKevin Gimpelが2016年に提案した活性化関数（arXiv:1606.08415）。ReLUが入力の符号で出力を制御するのに対し、GELUは入力の値をガウス分布の累積分布関数で重み付けし、なめらかな非線形変換を実現する。BERT、GPT-2など多くのTransformerモデルで採用されている。 – Gaussian Error Linear Units (GELUs)
  10. 自己回帰生成は言語モデルの標準的な推論方式。プロンプトから開始し、生成したトークンを順次入力に追加しながら<eos>または最大長まで繰り返す。GPTなどのdecoder-only Transformerはこの方式で動作し、<eos>または最大長に達した時点で生成を終了する。 – The Illustrated GPT-2
  11. temperatureはsoftmax計算前にlogitsをTで割ることで実装される（softmax(z/T)）。T→0では最大確率のトークンのみが選ばれる「貪欲デコード（greedy decoding）」に近づき、T→∞では一様分布に近づく。「創造性のつまみ」と説明されることもあるが、正確には確率分布の平坦さを調整するパラメータ。 – LLM Temperature
  12. NDJSONは各行が独立した有効なJSONオブジェクトで構成されるテキスト形式で、JSONLやJSON Linesとも呼ばれる。ファイル全体をパースせず1レコードずつストリーム処理できるため、ログ記録やリアルタイム配信に適している。標準のJSONと異なりファイルを丸ごとロードする必要がないため、長い生成過程をブラウザへ逐次送信する用途にも向いている。 – NDJSON Definition & Specification
  13. Claude E. Shannon, “Prediction and Entropy of Printed English,” Bell System Technical Journal, 30(1), 1951. 次の文字をどれだけ予測できるかで言語の冗長性を測る手法を提案した。 – Bell System Technical Journal
  14. Ronen Eldan and Yuanzhi Li, “TinyStories: How Small Can Language Models Be and Still Speak Coherent English?” 2023. 子ども向けの語彙に限定した合成データで小型モデルを学習し、一貫した短文生成を実証した。 – arXiv:2305.07759
  15. Jared Kaplan et al., “Scaling Laws for Neural Language Models,” 2020. モデルパラメータ数・データ量・計算量と損失の関係を実験的に示し、べき乗則で近似できることを報告した。 – arXiv:2001.08361
  16. Jordan Hoffmann et al., “Training Compute-Optimal Large Language Models,” 2022. 同じ計算予算であれば、大きなモデルを少ないデータで学習するより、小さめのモデルを多くのデータで学習するほうが損失が下がることを示した（Chinchillaモデル）。 – arXiv:2203.15556