設備投資の発表と販売可能ビットを分けて書いたメモリ供給編と、56件の推敲を共通チェーンで回した1日

朝いちで貼ったのは、他人が書いた原稿の冒頭だった。メモリ4社の低PERは歴史的なミスプライスなのか、その供給編。2027年のコンセンサス予想EPSで見ると、Micronが約5.5倍、SK hynixが約4.0倍、Samsungが約3.8倍、Kioxiaが約5.3倍。2028年で見るとさらに落ちて、4.8倍、3.8倍、3.7倍、4.3倍になる。7月17日の終値で計算した数字だ。

そのまま載せるつもりはなかった。当サイトには工場ごとの能力データを構造化して置いてある。突き合わせて、合わないところを洗い出してから書き直す。

投資額の発表と、ビットが売れる時期

市場が恐れているのは供給の氾濫のほうで、需要の減退ではない。だとすると、どの時点をもって「供給が増えた」と数えるかで結論が変わる。投資枠の発表、躯体工事、装置搬入、製品出荷。この4段階を分けずに扱うと、ビットが市場に出てくる時期を2〜3年早く見誤る。

工場ごとにこの4段階へ割り付け直す、というのが記事の骨格になった。

ファクトチェックを4本、並列で走らせた

担当を4つに分けた。韓国勢、米日勢、中国勢、PERと実装パターン。同時に走らせて、返ってきた順に読んだ。

最初に返ってきたのは中国勢で、CXMTの2025年末能力が食い違っていると書いてあった。元原稿は月26.5万枚、当サイトの既存記事は月20万枚。どちらを採るか迷う数字ではあるが、元原稿側は内部で辻褄が合っている。26.5万に8.5万を足すと、2026年末の35万枚になる。

もう一つ、既存記事の側にしかない論点が出てきた。HBMのビット税だ。同じビット数を作るのに、HBM3Eはおよそ3倍、HBM4はおよそ4倍のウェハーを食う。これでDDRのビット成長が年+3〜5%削られる。元原稿にこの論点はなかった。供給を語るなら外せない。

韓国勢からは、結論を裏側から支える数字が来た。SK hynixの汎用DRAM（Non-HBM）能力は2026Q4に月40万枚、2028Q4も月40万枚。横ばいのままだ。HBMがラインを食っているぶん、汎用側は増えない。

PERは2系統に分けて持たせた。出典側は7月17日の終値と年次EPS、当サイト側は7月30日の終値とNTMで計算している。同じ「PER」という名前で混ぜると比較にならない。

構造化データには供給プロジェクトを28件、出典12件、前提7件を入れた。件数はテーブルにも図にも出るので、数える純粋関数を1本置いてそこから引く形にした。テストは17件書いて全部通した。

図の文字が読めなかった

コンポーネント実装とSVG図解は3本並列で任せて、自分は本文を書いた。全部そろってからページを開いて、上から順に見ていった。

PER図の脚注が小さい。実測させると、SVG内の最小フォントは9.5pxだった。viewBox 1040を記事幅752pxに縮小して表示しているので、実効6.87px。svg-diagramの規約は11px以下を禁止している。読めないはずだ。

作った担当に直させようとしたが、そのエージェントは再開できなかった。自分で組み替えた。viewBoxを720に落とし、左右に並べていた2つの系列を上下2段に変え、長い脚注はSVGの外のHTMLへ出した。実効12.53pxになった。

数字が読めるようになると、今度は別の問題が見えた。上段の高い棒、5.5倍と4.8倍の値ラベルがブロック見出しに重なっている。上段の開始位置を208から248へ、下段を512から560へ下げ、全体の高さを800から880へ広げた。getBBox() で矩形の重なりを実測して0件、テキストの右端は653px（viewBox 720の内側）に収まった。

タイムラインのほうは、年ラベルの「2033」が右マージンを3px侵食していた。プロット右端を690から680に詰めて解消した。

Vueのtemplateで Math.min を呼んでいる箇所もあった。templateからはグローバルの Math が見えない。同じ計算をscript側の純粋関数に切り出して、templateからはそれを呼ぶ形に直した。

最重要の列が画面外にあった

テーブルは8列980pxで、記事幅750pxに収まっていなかった。横スクロールしないと「ビットが出てくる時期」の列が見えない。記事の主張そのものが入っている列だ。

事業者はグループ見出しへ移し、製品と増やし方を1列に統合した。到達能力はビット列に入れて、5列720pxまで圧縮した。横スクロールが消えて、フォントも本文と同じ14.4pxになった。

画像を検証させたときは、4枚ともnaturalWidth 0で返ってきた。lazy loadingを疑って全体をスクロールさせたら、全部読み込まれていて、viewBoxの比率とも一致していた。

件数の誤りも1件出た。プロジェクトを当初29件と書いていたが、実データは28件だった。表と図は .length から数えるので追従するが、メモの記載だけ手で直した。

この記事に走らせた担当は、ファクトチェックの4本と実装の3本で合わせて7本になった。出来上がった本文は366行、図は静的SVGが4枚とVueコンポーネントが3本ある。

56件の例文を推敲させる

午後は作業を切り替えた。手元の56件の例文を、japanese-tech-writingスキルを必ず使う条件で推敲させる。スキル本文と参照資料を先に読ませてから全56件を通し、入力文と推敲後が左右に並ぶHTMLにまとめさせた。

途中でどのモデルで動いているか確認させたら、Opus 5（1M context）だと返ってきた。4.7ではないという。

HTMLはパスを教えられても読む手段がない。Chromeで前面タブに開かせた。目次があり、1件ごとにBefore/Afterと変更点が左右に並んでいる。これでようやくレビューできる。

チェーンごと指定し直す

同じ56件をもう一度、今度は指示の書き方を変えて回した。

最初の1通は届いていなかった。「貼り付けられたテキスト（223行）の内容が私には見えていません。何をしてほしいか教えてください」と返ってきた。貼り直した。

2回目は、スキル名を並べるだけにしなかった。publication-polish-chain.md を共通チェーンとして先に読ませ、今回は短い文の校正だから説明モードを使う、と明示した。使うスキルは4本。japanese-tech-writing、vivid-writing、cognitive-rhythm-writing、honda-sakubun。vivid-writingとcognitive-rhythm-writingは、元文にある具体と不確実性を保つために参照するだけにさせた。元文にない場面、数値、身体動作、感想、因果は足すな、と条件をつけた。

順序も5段階で固定した。事実、数字、固有名、実行主体、時制、因果、推量、直接引用を意味固定する。japanese-tech-writingの6パスで推敲する。最後の文章変換としてhonda-sakubunの5パスを実行する。入力文と照合して意味固定項目が変わっていないか確かめる。戻した文があれば、その文だけhonda-sakubunを再適用する。

情報が足りない箇所をもっともらしく埋めるのも禁じた。プレースホルダーか「要確認」で残せ、直接引用の中身は変えるな、曖昧な評価を根拠のない別の評価語に置き換えるな。過去の回答HTML2本は読むな、とファイル名で指定した。

末尾には検証記録を付けさせた。返ってきたのはこうだった。

• パス別の修正件数は、整形11件、構成8件、厳密さ4件、読み手の負荷6件、演出とLLMっぽさ14件、見出し2件
• honda-sakubunの5パスは、修飾語順、修飾先との距離、読点、助詞、無神経な文章のそれぞれに該当番号つき
• 意味固定の照合で差し戻した文章はなし
• 創作せず保留にしたのは4件。指示語の対象が元文にない2件はプレースホルダー、体言止めで時制が確定しない2件は「要確認」
• 直接引用を含む2件は、カギカッコの中を1字も変えていない
• 「〜ようにも思われる」「〜といわれている」といった推量と伝聞は、そのまま残した

スキル名だけ渡したときと違うのは、最後の部分だ。何を変えなかったかが、番号つきで返ってくる。推敲は変えた箇所を見せる作業だと思っていたが、読んで安心できるのは変わっていない側の記録のほうだった。

残っているもの

• 図4（HBM税）の記事内表示を自分の目で見る。図1〜3は確認済み
• モバイル幅390pxでの表示確認。エミュレーションで見て、終わったら空文字で解除する
• 記事本文の日本語校閲。数値、固有名詞、リンク、MDC記法、figure要素は触らない
• pnpm test:run を全体で1回通す

当サイト側に直す必要のある記述も2件残っている。Micronの1工場は、出荷寄与の年度が会社発言とずれている。SK hynixの龍仁については「完成の前倒し」と書いてあるが、正しくは装置搬入開始の前倒しだ。今回は記事に注記を書いただけで、既存ファイルには手をつけていない。

書いた記事はこれ: メモリの設備投資は2026年に史上最大となるが、販売可能ビットが洪水になるのは2028年後半から2030年