Karpathy氏の200行GPT「microGPT」の解説記事を読んだら、局所勾配・バックプロパゲーション・ソフトマックスといった用語の前で完全に手が止まった。数学とMLの言葉がわからないと一行も進めない。それなら、自分の土俵である会計・簿記の言葉に翻訳すれば読めるはずだ、と考えた。今日はその教材を一日かけて設計した。ただし実装は1行も書いていない。計画だけで終わった。
なぜ「会計の言葉」に翻訳したいのか
microGPTは外部ライブラリなし・200行でGPTの仕組みを見せてくれる教材だ。一行ずつ追えば学習ループの全体像がつかめる、はずだった。
実際には、勾配が (1,1) になるとか (b,a) になるとか、活性化関数とか、トポロジカルソートとか、ガウス分布とか、ソフトマックスとか、知らない言葉で埋まっていて読み進められなかった。
そこで、税理士・会計士が毎月やっている予実管理の感覚に翻訳すれば直感だけは持てるんじゃないか、と思いついた。数式そのものを厳密に理解するのが目的ではない。「自分の言葉に置き換われば腹落ちする」を狙う。
設計の背骨はこう決めた。
GPTの学習ループ ≒ 予算実績管理（予実）のループ
過去データからパターンを学ぶ → 予測する → 予測と正解のズレ（差異）を測る → ズレの原因を遡る → 前提を修正する → 精度が上がる。
これは会計人が毎月やっている予実差異分析と来期予算へのローリング修正そのものだ。この太い軸に全用語をぶら下げることにした。
既存ページの作りを先に調べさせた
いきなり書き始める前に、このサイトに既にあるインタラクティブ教育ページの作りをClaude Codeに調べさせた。science、financial-quiz、cashflow-worksheet あたりが該当する。
特に「連結会計仕訳シミュレーター」が好例だった。純粋関数を utils/ に切り出し、computed で副作用なしに描画し、見た目はネオブルータリズム調で統一されている。この設計をそのまま今回の教材にも取り込むことにした。デモが使う計算（relu / softmax / 勾配など）は app/utils/microgpt-math.ts に純粋関数として置き、Vitestでテストする方針にした。
ルーティングも science/ のハブ＆分岐構造を踏襲する。親の index.vue が全体像のハブ、子の [concept].vue が用語ごとの「そもそも〇〇とは？」解説になる。
ML用語 → 会計アナロジーの対応づけ
この教材の核心は用語の翻訳表だ。今日決めた主な対応はこうなった。
- 勾配・局所勾配 = 感応度分析。「売上を1円増やすと営業利益はいくら増えるか」。変動費率30%なら +0.70円、これが勾配0.70。固定費は動かないので勾配0。
- ReLU（活性化関数） = 赤字なら税額0。マイナスはゼロで止める。
- ソフトマックス = 構成比100%。複数の値を合計1の割合に正規化する。
- バックプロパゲーション = 差異のドリルダウン。最終差異がどの科目から来たかを上流へ遡る。
- トークナイザ = 取引事象を勘定科目という記号に変換する、仕訳の入口。
- 再帰／依存順（トポロジカルソート） = 仕訳→元帳→試算表→F/Sの集計の順序。
最初はタイトルを「複式簿記で理解する」にしていた。でも学習ループの本質は管理会計・予実・原価計算・配賦に近くて、借方貸方の二面性に厳密対応する箇所はトークナイズや依存順くらいしかない。だから主軸は「会計人の実務感覚」にして、複式簿記の語は対応が成立する箇所だけで使う、とタイトルごと寄せ直した。
codexに2ラウンド再帰レビューさせた
計画書を memo/2026-05-30/ に書いたあと、プロジェクトルール（plan-codex-review）に従って codex に計画をレビューさせた。瑣末なクソリプは捨てて致命的な点だけ出させる、いつものやり方だ。
返ってきた指摘は5点。どれも妥当だった。中でも引っかかったのが「includeInList の自動検出が実際に効くのか」という指摘。記事一覧にこの教材を載せる前提を置いていたが、その仕組みが本当に動くか確証がなかった。
そこで useBlogArticles.ts の実装を確認させたら、予想が外れた。一覧は vuePageArticles 配列でハードコード管理されていて、includeInList の自動検出は現行実装では効かない。確認しなければそのまま壊れる計画を書くところだった。ハブページ1件を vuePageArticles に手で追加する、と計画を直した。
5点すべてを反映してから、resume --last で文脈を保ったまま codex に再レビューさせた。2ラウンド目で「致命的な問題なし」まで仕上がった。最終的な方針はこう確定した。
- ハブ＋用語別ページの構成
- コア9語＋全体像ハブ
- 会計アナロジー中心・数式は最小限
「計画は厚いが完成物は薄い」と気づいた
ここで一度立ち止まって、自分のプランを読み返した。
計画書としては厚い。でも完成物、つまり各用語ページの中身は薄くなりそうだ、と気づいた。原因ははっきりしていて、各用語ページが実質「アナロジー1行＋デモ1個」しかない。読者を最後まで連れていく物語が足りない。スコープ（コア9語）はむしろ十分で、足りないのは1ページあたりの深さのほうだった。
スコープを広げるのではなく、1ページの掘り下げを増やす方向で考え直す必要がある。これは明日以降に持ち越す宿題にした。
実装はゼロ。翌日の積み残しにした
そして肝心なことに、この日は計画だけで実装は1つも書いていない。念のためディスク上を確認させたら、計画書に並べた成果物のファイルは1つも存在しなかった。記憶で「だいたいできた気がする」で済ませず、実体を見て未実装と確定させた。
翌日（5/31）に「積み残しある?」と聞いたときに確実に拾えるよう、計画書の冒頭に積み残しバナーを追記した。
ついでに Google タスクにも登録しようとしたが、gws の呼び出しで引用符のエスケープが壊れてエラーになった。issue を切ってから Python スクリプト経由で引用符ネストを避ける別アプローチも試したが、これも素直に通らず、深追いをやめた。タスク登録は諦めて、作りかけの一時スクリプトを消した。結局この日やったのは計画書の冒頭バナー追記だけだ。
振り返り
設計の背骨（予実ループ＝学習ループ）が一本通ったこと、codexの指摘を鵜呑みにせず useBlogArticles.ts を実際に開いて事実で裏を取れたことは収穫だった。一方で「計画の厚さ」と「完成物の薄さ」は別物だと改めて思い知らされた。明日は各ページの深さをどう作るかから考え直す。