散布図の指標解説を書く — 2回落ちて「小さく単純に」で復帰した
/beat-monitoring/scatter には、横軸に NTM EPS 成長率、縦軸にフォワード PER を取った散布図が置いてある。9銘柄が右下・右上・左のゾーンに散らばるのを眺めていて、自分でも「この2軸が結局何を言っているのか」を一度言葉にしておきたくなった。図だけ見て結論を出すと足をすくわれる。そこで、軸の指標が何を表し、何を表さないのかをまとめた解説ドキュメントを1本書き、散布図ページからリンクでたどれるようにする、という作業に入った。
指標解説そのものはこの記事には書かない。読み方と限界を並べた本体は 成長率 × フォワード PER 散布図の読み方 に置いた。この記事は、その1本を仕上げるまでに2回セッションが落ち、codex のレビューを通したあとで自分でデータを見直して食い違いを2つ見つけた、その過程の記録だ。
1回目: ファイルを探している途中で、2回続けて落ちた
最初のセッションは、ドキュメントを書く前の下調べで止まった。散布図ページの実体とデータの定義を確認しようと、関連ファイルを並列で探しに行った。その「散布図ページの実体を読みます」と言った直後に、ツール呼び出しが壊れて返ってきた。
Your tool call was malformed and could not be parsed. Please retry.
The model's tool call could not be parsed (retry also failed).
リトライも失敗した。続けて codex のレビューも頼んだら、そこでもう一度同じ壊れ方をして、retry も通らず、セッションがそのまま立ち上がらなくなった。ファイルの中身をまだ1行も読んでいない、探索の段階での全滅だった。原因の深掘りは別に切り分けるとして、ここで分かったのは「ファイル確認のために一度に複雑なツール呼び出しを投げると、その引数が壊れて落ちることがある」という具体的な事実だった。
2回目: ツール呼び出しを小さく単純に保つ方針に切り替える
セッションを立て直したとき、まず方針を変えた。前回はファイル確認中に落ちたのだから、今回はツール呼び出しを小さく単純に保って進める。一度に全部を読みに行かず、まず関連ファイルを特定する、次に散布図ページの実装だけを読む、と段階を分けた。
特に意識したのは、データファイルを全部開かないことだった。指標の定義を確認したいだけなのに、生成済みの大きなデータを丸ごと読み込みに行くと、それがそのまま重い引数になって次の呼び出しを不安定にする。だから「まず構造だけを見る」を徹底した。index.ts、valuation.ts、types.ts の定義を順に確認し、計算ロジックの裏取りは生成スクリプトと銘柄メタを必要な分だけ開いた。
この進め方で、軸の指標がどう作られているかを正確に拾えた。
- NTM EPS は次の4四半期の予想を合計したもの
- LTM EPS は直近4四半期の実績を合計したもの
- 成長率は NTM ÷ LTM − 1
- フォワード PER は株価 ÷ NTM EPS
縦軸の PER を横軸の成長期待で正規化して読む、つまり PEG 的に「この成長を織り込んでこの倍率は高いのか安いのか」を見るための図だ、という骨格がここで固まった。ロジックが固まれば、図がカバーできない限界も書ける。会計年度の期末がバラバラなこと、コンセンサスの偏りや改定のタイミング、構造転換の途中で過去実績が比較対象にならないことなど、構造上どうしても拾えない点を9つ正直に並べた。
ルーティングの罠: ticker と誤認される
置き場所で1つ引っかかった。/beat-monitoring/[ticker] という動的ルートが既にあるので、解説ドキュメントのパスを /beat-monitoring/... の配下に切ると、その文字列を銘柄ティッカーだと誤認してしまう。/beat-monitoring/scatter-guide のようにすると、scatter-guide という名前の銘柄ページを探しに行く挙動になりかねない。そこで既存記事と同じく、配下に潜らせず、フラットに /beat-monitoring-scatter-guide を採った。後で dev で叩いたら、動的ルートに吸い込まれず 200 で素直に返ってきた。
codex は「問題なし」、でも自分でデータと照合したら2つ食い違っていた
ドキュメントを書き、散布図ページに誘導リンクを足したあと、内容を codex にレビューさせた。財務指標の定義・ロジック・限界の記述に致命的な誤りがないかを見てもらう狙いだった。返ってきた評価は「致命的な問題なし」だった。
ここで終わらせなかった。書いた内容を自分でも実データと突き合わせて読み直した。すると2つ、事実とずれている箇所が出てきた。
1つ目は、限界として挙げた「会計年度の期末がバラバラ」の具体例。記事の中で期末月を例示していたが、実データを見ると STX・WDC・SNDK は6〜7月期末で、書いた具体例とは違う月になっていた。期末がずれているという主張そのものを補強するための例なのに、その例が間違っていたら主張ごと信用を落とす。
2つ目は、成長率の表示値の丸め。本文に書いた成長率の数字が、散布図ページ側の丸め(整数%)と一致していなかった。同じ図を説明する文章なのに、図と本文で数字がずれていたら読者は迷う。
どちらも codex の指摘リストには載っていない。レビューが「致命的問題なし」と言ったあとに、自分で数字を1つずつ実データに当てて初めて見つかったずれだった。表示値はページの丸めに合わせ、期末月の具体例は実データどおりに書き直した。最後に dev で両ページを開き、散布図ページに解説リンクが入っていること、解説ページがフラットパスで正しく描画されることを目で確認して終わりにした。
残しておきたいこと
軸はフォワード PER だ。途中で「フォワード PBR」と口走りかけたが、ページもデータもコミットもすべて PER 軸で揃っている。指標名の取り違えは、解説記事そのものの信頼を一発で崩すので、ここは何度でも確認するに値する。
作業を通して残ったのは2つ。1つは、ファイル探索のような単純な下調べでもツール呼び出しが壊れて落ちることがあり、そのときは引数を小さく単純に保って段階を刻むと抜けられる、という体の感覚。もう1つは、レビューが合格を出したあとでも、数字を実データに当て直す係は最後まで自分の手元に残る、ということ。codex が「問題なし」と言った2つの数字は、どちらも実データと違っていた。