2026年5月30日の開発日記

朝からツール呼び出しが何度も壊れてセッションが落ちた。最初は「セッションに溜まった巨大ファイルが悪い」と決め込んでいたが、実際に件数を数えてみると思い込みが崩れた。落ちる原因を計測で突き止めながら、microGPTを会計の言葉に翻訳する教材を構想し、make-diaryの並列化に見切りをつけ、公開データに残っていた書籍の出典表記を消した。手を広げた一日だった。

今日のタイムライン

今日やったこと

1. tool-call-malformed の真因を計測で突き止めた

複数のセッションで「ツール呼び出しが壊れて parse できない」というエラーが頻発し、retry も失敗して落ちることがあった。犯人は数十MBに膨れたセッションだと思い込んでいたが、件数を数えたら逆だった。画像base64で48MBに膨れたセッションは parse失敗ゼロで完走していて、落ちたのは入力が0.1MBほどの小さいセッションの方だった。真因はファイルサイズではなく、モデルが吐くツール呼び出しの引数構造そのものの破綻だと分かった。

主な成果:

• 「巨大ファイル犯人説」を計測で否定し、真因をtool_use引数の破綻と特定
• 単純な grep -c "could not be parsed" は自分が議論で書いた文字列まで拾って過大カウントする（32ヒットでも本物は0）と判明 → isApiErrorMessage:true で絞る
• ツール引数を小さく単純に保つ予防ルールに切り替え、肥大セッションは session-backup で掃除

詳細: tool-call-malformedの真因は巨大ファイルではなかった—計測で思い込みを覆した日

2. microGPT を「会計の言葉」に翻訳する教材を構想した

200行のmicroGPTを1行ずつ読み解き、機械学習の用語を会計・簿記のアナロジーに置き換えるインタラクティブ教材を企画した。勾配＝感応度分析、ReLU＝赤字なら税額0、ソフトマックス＝構成比100%、バックプロパゲーション＝差異のドリルダウン、という具合に対応づける。codexで計画書を2ラウンド再帰レビューして「致命的な問題なし」まで仕上げた。

主な成果:

• ML用語→会計アナロジーのマッピングを設計、ハブ＋コア9語の用語ページ構成に確定
• codexの指摘を事実確認（includeInListの自動検出は効かず、配列でハードコード管理と判明）して計画を修正
• ただし計画は厚いのに完成物が薄くなりそうだと自分で気づき、実装は翌日の積み残しにした

詳細: 200行のmicroGPTを「会計の言葉」に翻訳する教材を設計した

3. make-diary の並列化を本番テストして棚上げした

毎朝の/make-diaryを並列ワークフロー化する試作を本番で1回フルランした。理論上は3割ほど速くなる見込みだったが、計測すると2大コスト（ログ同期に約16分、記事書きに約16分）は並列化では1秒も縮まないと分かった。3つのバグも出た。潔く棚上げし、/make-diary単体運用を続けることにした。

主な成果:

• 並列WFを本番フルランし、費用対効果が薄いと計測で判断 → アーカイブ（削除せず経緯コメントを残して温存）
• 本丸は並列化ではなく、ログ同期のフルスキャン約16分を増分化することだと整理
• テスト中に出た5件のエラーをissue化

詳細: /make-diary の並列化を本番テストして、潔く棚上げした判断

4. 散布図に指標解説を足し、2回落ちて復帰した

ビートモニタリングの散布図（横軸＝NTM EPS成長率、縦軸＝フォワードPER）に、指標の意味とロジック、そして限界を解説するドキュメントを足してページからリンクを張った。最初のセッションはファイル探索中にmalformedで2回落ちて死亡。次のセッションで「ツールを小さく単純に保つ」方針に切り替えて完遂した。codexは「問題なし」と言ったが、自分で実データと照合したら会計年度期末の具体例と成長率の丸めが食い違っていて、自分で直した。

主な成果:

• 散布図の指標解説ドキュメントを新規作成し、限界を9点正直に列挙
• malformedで落ちた後、構造だけ見る進め方に切り替えて完遂
• codex合格後に自己検証でデータ不整合を発見・修正

詳細: 散布図の指標解説を書く — 2回落ちて「小さく単純に」で復帰した話 ／ 解説そのものは成長率×フォワードPER散布図の読み方

5. 公開データに残った出典表記を消した（eurekapu）

別プロジェクトの積み残しを棚卸ししたら、公開スライドのデータにある投資家の名言と参考書の書名・出版社・ページ番号が丸ごと残っていた。しかもその読み上げ台本は本番ページに表示されていて、読者に見えている状態だった。これが一番リスクが高いと判断して最優先で潰し、ついでに統合機能の未作成分も実装した。

主な成果:

• 出典表記の明確な違反3箇所を特定して修正（読み上げ台本が本番表示されていた点に注意）
• 名言が画像に焼き込まれていないか（台本だけ消しても意味がない）を確認
• 積み残しの統合機能（コラム＋図＋章への適用＋クイズ）を実装

詳細: 公開データに残った出典表記を消し、積み残しの統合機能を実装した

今日の試行錯誤

今日の学び

• tool-call-malformed の真因はファイルサイズではなく、ツール呼び出しの引数構造の破綻。小さく単純に保つのが唯一効く予防だと腑に落ちた
• エラーの計測は単純grepだと自分の書いた文字列まで拾って過大カウントする。本物だけ数えるには isApiErrorMessage:true と組み合わせる
• 並列化は万能ではない。律速になっているコストが並列で縮まないなら効果は薄い。期待で作る前に計測して判断する
• codexが「問題なし」と言っても、財務数値は自分で実データと照合しないと食い違いを見逃す
• 計画の厚さと完成物の厚さは別物。1ページあたりの深さが足りないと、立派な計画でも薄い成果物になる
• 公開物に書籍の出典表記が残るのはコンプラ事故。読み上げ台本も本番に表示されることを忘れない

明日やること

• microGPT会計アナロジー教材の実装（計画書 microgpt-bookkeeping-plan.md の成果物。ハブ＋コア9語の用語ページ）

関連記事

• tool-call-malformedの真因は巨大ファイルではなかった—計測で思い込みを覆した日
• 200行のmicroGPTを「会計の言葉」に翻訳する教材を設計した
• /make-diary の並列化を本番テストして、潔く棚上げした判断
• 散布図の指標解説を書く — 2回落ちて「小さく単純に」で復帰した話
• 成長率×フォワードPER散布図の読み方
• 公開データに残った出典表記を消し、積み残しの統合機能を実装した