今日やったこと

note.comで購入したある記事（DRAMブラックホール需給予測）を、自分用の3枚スライドにまとめ直した。元記事は文章主体で、章をまたいで数字が散らばっている。スマホでスクロールしながら追うと、HBMの需要曲線とウェハ供給能力の関係が頭の中でぐちゃぐちゃになる。

そこで「1セクション=1画面、矢印キーで送る、スクロールなし」のスライド形式に変換することにした。途中、ある事件が起きて作業の主役が私からCodexに移った。結論を反転させかねない計算ミスを、5回連続でCodexに見つけ続けてもらった事件である。

元データを取ってくるところからして手こずった

WebFetchで記事を取りに行ったらログインゲートで弾かれた。私のChromeはnote.comに月額課金してログイン済みなので、Chrome DevTools MCP経由でブラウザを操作し、記事内に貼られた図表74枚とHTMLをまとめて手元に保存した。

ここまでは前菜。本番はこのあとである。

計画書をCodexに5回連続で殴ってもらった

スライド化の計画書を codex exec -m gpt-5.5 でレビューにかけた。一発でGOサインが出ると思っていたら、初回からCodexは6点指摘してきた。全部本質的だった。瑣末な指摘はしないよう毎回プロンプトに刺しているので、Codexが「致命的」と判定したものだけが返ってくる。

修正して2回目に投げた。今度は4点指摘。そのうちの1つを読んで、椅子の上で固まった。

0.81 EB/年と書いてあるが、実際は6.8 EB/年。HBMの世代別容量を掛け忘れている。

桁が一個違う。1.44を49.5と読み違えれば、結論は「供給過剰」から「深刻な供給不足」に反転する。私が手で書いた数字で、私が気づかずに通そうとしていた。

3回目を投げた。「HBM換算7.55 EB/年は誤り、正解は6.5。全体としては供給過剰だが、HBM/LPDDRはタイトで、DDR/commodityは余る。セグメント分岐が正しい結論だ」と返ってきた。

4回目で「既存ベース需要が抜けている。AI追加需要だけを乗せてはいけない。これも結論反転リスクが大きい」。

5回目はだいぶ細かくなって、文言矛盾が1点。「S4で余ったDDR/commodity能力が他を補う」と書いたが、前提（HBMはプロセス制約で他に振り替えできない）と矛盾している、と。

ここまで来てようやくGOサインが見えた。6回目を投げる前に、Codexはもう新しい指摘を出してこないだろうと判断して実装に着手した。

計算ミスの怖さは、自分では気づけないところにある

電卓を叩いて検算しているわけではない。私は数字を式から逆算して確かめるワークフローを持っていない。元記事の図表74枚から数字を拾って計画書に書き写し、文章でストーリーを組んだだけだ。

その「書き写し」の段階で桁を一個間違えていた。ウェハ枚数からEB/年への換算で、HBMのスタック段数を掛け忘れていた。式そのものは合っているのに、変数の代入で事故っていた。

人間が書いた計算ロジックでも、画面の数字に違和感を覚えて自分で気づかないと事故る。これは前にも残高試算表で経験した。今日はそれをLLMにクロスチェックさせて拾ったバージョンだった。

実装フェーズ

数字が固まったので一気に書いた。DB schemaを定義し、chart-data.mjs でシナリオごとの数値を吐き、slide-runtime.js で矢印キー操作と画面遷移を組み、3枚のスライドHTMLを書き、Source Mapを別ページに分け、READMEで構成をまとめた。

途中で2つの問題に気づいた。

1つ目、書いたスライドのキーメッセージが箇条書きだと話がつながらない。「文章にしてストーリーにして」と自分に言い聞かせて、全スライドのキーメッセージを地の文に書き直した。

2つ目、スライドを横断すると、単位がEB/年・ウェハ枚数・iPhone台数で混在していて数字の比較がしづらい。たとえば「2025年184万枚→2028年298万枚」と言われても、それが何EBで、iPhone何億台分なのかが瞬時には繋がらない。全スライドの下部に「単位の橋渡し注釈」を追加して、3つの単位の換算をその場で示した。

需給バランス図にインタラクティブを入れた

base・upside・extremeの3シナリオを切り替えられるボタンを需給バランス図につけた。HBMの需要が増えるほど、他セグメント（DDR・commodity）から能力が削られる構造を可視化したかった。

ここでまた鋭い指摘を自分自身が出してしまった。「S3はHBM需要が増えたら逆転するんじゃないか？」。baseシナリオとupsideシナリオでメーカー配分が変わらないのは、HBMがプロセス制約で他から振り替えられないという前提と矛盾していた。

シナリオ間のロジック一貫性を見直して、HBM需要に応じてDDR/commodity側の能力が削られる挙動に直した。完成品はようやく自分の頭の中の需給モデルと一致した。

振り返り

Claude Codeにスライドを書かせ、Codexにレビューさせ、私は「画面の違和感を拾う係」と「方針を決める係」に徹した。手で計算した形跡はどこにもないが、計算ミスは5回連続で発掘された。

人間が判断する係、AIが実行する係、別のAIが検算する係。この3人体制が今日の作業の構図だった。

税理士・会計士フォロワーへの応用

決算予測モデル・税効果計算・連結ワークシートで、自分が手で書いた数字をスプレッドシートに転記する場面は多い。式は合っているのに変数の代入で事故るのは、簿記の現場でも頻繁にある。

たとえば繰延税金資産の回収可能性スケジューリングで、将来課税所得を年度別に書き出して将来減算一時差異と突き合わせる作業。手で式を組むと、年度をずらして掛けたり税率の切り替え時期を間違えたりする。完成したスケジュール表をLLMに渡して「この数値の整合性をクロスチェックして」と頼めば、今日のCodexのように「2027年度の数値が桁違いです」と返ってくる可能性は十分にある。

LLMを「自分の計算の追検算をさせる役」として使う発想は、税務の現場でもそのまま効く。実装の自動化より、数字の追検算の自動化のほうが、現場の事故率を下げる効果は大きいかもしれない。

明日やること

• 完成したスライドをローカルで通しで再生して、矢印キー操作の引っかかりを潰す
• 単位の橋渡し注釈をスライド間で表記揺れがないか確認する
• 3シナリオ切替の挙動を、HBM需要を極端な値にしたextremeケースで再検証する