後回しにした理由を探したら、そんな記録はどこにもなかった

4月下旬から、決定の記録なく止まっていた

止まっていた教材づくりを再開しようと思った。ただ、その前に確かめたいことがあった。自分は何か理由があってこれを後回しにしたはずで、その理由を忘れている。

再開したい理由のほうははっきりしている。教材を作る速度を、AI を使って一桁上げる。AI に手伝わせた過程は成果物の側には出さず、出来上がったものだけを届ける。喋りの音声も自分の声で用意できるなら、読み上げを聞きながら構成を決めていける。これはこれで、いまの道具立てに合った作り方だと思っている。

後回しにする理由を書いた文書がどこかに残っていないか、Claude Code に探させた。対象は関係する2つのリポジトリと、ドキュメント一式。

無い、という答えが返ってきた。そういう文書はどちらのリポジトリにもなく、この教材の作業は4月下旬を最後に、決定の記録なく止まっていた。止めた覚えがないのも当然で、止めるという決定自体をしていない。

まったくの空白でもなかった。順番と優先度を決めた記録が3本残っていて、そのうちの1本が、今回やろうとしている方向と食い違っていた。

食い違いの正体

食い違った1本は、8月中旬に書いた計画だった。冒頭の原則が、今回の方針を否定しているように読める。関係する4本をまとめて Chrome に開かせ、前面にその1本を出させて読み直した。

読んでいるうちに思い出した。あれは、ある直販の考え方に沿って外部プラットフォームを主戦場から外す、という話だった。動画そのものは作る。だから外部プラットフォームへの公開がバッティングするのは、確かにそのとおりだ。

ただ、自分のところで売るか外部で売るかはチャネルの違いであって、何を作るかとは関係がない。この教材をやるかどうかには、まったく効いてこない。読み直した原則は、最初から最後までチャネルの話しかしていなかった。

食い違って見えたのは、別々の軸の判断を1本の線に並べていたからだった。チャネルの選択と制作物の選択は、別の判断である。

整理し直したうえで決めた。教材は作る。公開は自社側のチャネルでやる。外部プラットフォームには出さない。

決めたことと、その根拠と、今回参照した計画書5本を、表にして再開用ビューの冒頭にまとめさせた。次に開いたとき、どの記録を踏まえた判断なのかが冒頭で分かる。

なお、この分野を選んだのは、需要があると自分で観測しているからだ。別の第1弾候補も残っているが、そちらはゼロから作る量が重い。こちらは手元でほぼできあがっていて、教材として出すだけで済む。手離れが違う。

併走させるものと、止めるもの

再開を決めると、いま回っている別の流れをどうするかが次の問題になる。動いているのは2本で、図をどこまで忠実に作り直せるか試している実験と、エージェントに書かせている記事のほうだ。

どちらも止めなくてよいと判断した。前者は、元の図を再現しつつより良いものを作れるかを見ているだけで、教材の進行を食わない。後者はエージェントが書いているので、こちらの手は空いている。併走でいい。

教材の方向も、2案のうち実務寄りのほうを選んだ。想定している論点を一通り押さえて、手元の計算書と表計算のファイルを見れば意味が分かる状態まで持っていく。会計ソフトAのAPIを使う説明に要る検証用の事業者は、既に作ってあるものを充てる。

この4件を判断として計画書に反映させ、HTML を作り直させて前面のタブに出させた。チェックボックスの状態と事業者の番号まで、描画を確認させている。

音声の手段を、書かせた後で訂正した

再開用ビューには、喋りの音声を汎用の音声合成エンジンで作ると書かせていた。書き上がったものを読んで、そこは違うと気づいた。

自分の声のクローンは、別の音声合成ツールで既に作ってある。実用に耐えることも確かめてある。前者の記述を消して、そちらでやると書き換えさせた。

書き換えさせてから、もう一つ思い出した。そのツールを入れてあるのは母艦の Mac だけで、この Windows 機には入れていない。入れれば済む話ではある。ただ、制作の手を動かす場所が片方の機体に寄っているという事実は、頭に置いておくことにした。

tmux は入っていなかったが、要らなかった

会計ソフトAのAPI検証を別の流れで進めている最中に、教材の消費税対応の計画書も要ると分かった。同時に2本は回せない。

Windows 機で tmux を使ったことがあったか聞いた。答えは、入っていない。実体がどこにも無く、設定ファイル群の中で tmux に触れているのは macOS 向けの記述だけだった。

ただ、tmux は要らなかった。この機で idle のまま生きている Claude Code のセッションが4本あり、そのうち同じリポジトリを見ている1本は、3時間前から手が空いていた。そこへ計画書づくりを投げさせた。実装はせず計画だけ、という条件を付けて。

止まって見えたのは、自分が見た時刻のせいだった

投げた先が手を離した、という通知が13時54分に来た。成果を見に行かせると、計画書はできているが完成ではない、という報告が返ってきた。Codex レビューの2巡目が「要修正」で終わっていて、その指摘が未反映のまま turn が終わっている。

向こうが idle になったという通知が入った。レビュー2巡目の指摘が未反映のまま turn が終わったように見えたので、差し戻しが飛んだ。3点を反映して、もう1巡させてから完了にしてほしい、と。

向こうからすぐ返事が来た。3点は13時56分の時点で計画書と判断項目の両方に反映済みで、いま3巡目を実行中だという。

「止まっている」と読んだ材料は、13時54分のタイムスタンプだけだった。手を離した時刻を見て、そこで作業が終わったと解釈していた。実際には、その2分後に反映が済んでいた。見ていたのは止まった証拠ではなく、反映前の断面でしかなかった。

idle の通知は「手を離した」を伝えるだけで、「そこで終わった」とは言っていない。差し戻す前に、ディスク上の実物と更新時刻を突き合わせればよかった。

Codex を4巡させて、実装着手可になるまで

消費税対応の計画書は、Codex レビューを4巡した。

1巡目で、致命的な指摘が5点出た。

• 統合の際に、精算仕訳が二重に計上される
• 帳簿上の税額と申告上の税額を3層に分けたうえで、精算差額を損益へどう落とすかが決まっていない
• 分類が漏れている取引の型がある
• 税抜への正規化を踏んでいない
• 還付が出る場合の扱いと、表示方法の切り分けができていない

この5点を反映させたあと、説明用の図2枚については、文字が枠からはみ出していないかを機械で測らせ、Chrome での描画も確認させた。図の崩れは、目で見て気づける保証がない。

2巡目で残ったのは3点だった。

• 中間納付を帳簿税額の集計から外し、精算差額は控除前、期末残高は控除後で判定する
• 納付の計算と控除不足の還付の計算とで、端数処理の分岐を分ける
• 表示方法を「発生」と「支払および還付」の2列に分ける方式へ変更する

3巡目の判定は、推奨案で進めるなら実装着手可、ただし別案を中間納付と併用する設計には1点修正が要る、というものだった。その1点は、未払から未収へ変わる期に3つの科目のあいだで振り替える配分の話だ。これも反映させた。あわせて、会計ソフトA側に実在する科目名や、中間納付を置く補助科目の位置など、もう一方のセッションで検証して分かっていた事実も取り込ませた。

4巡目で、最終判定が「実装着手可」になった。

残った判断は4件ある。ターミナルの選択肢で答えると前提を読みながら選べないので、3択の決裁フォームを立てて Chrome に表示させた。推奨がどれかのバッジと、自由記述の欄まで描画されていることを確認させている。

投げてから最終判定が出るまでのあいだ、向こうが手を離すたびに通知が届いた。その都度どこまで片付いたかを読む。相手が shell を走らせている最中は、手を出さずに待った。同じリポジトリを2本のセッションで触っている以上、両方が同時に書きにいくのがいちばん危ない。

今日の学び

• 止めた理由の記録が無いときは、「理由があって止めた」という前提のほうを疑う。今回は決定そのものが存在せず、ただ止まっていた
• 古い計画と食い違って見えたら、まず判断の軸が同じかを確かめる。チャネルの軸と制作物の軸を1本に潰していたせいで、無関係な原則に足を止められていた
• idle の通知は「手を離した」であって「終わった」ではない。差し戻す前に、ディスクの実物と更新時刻を見る
• 別セッションにレビューの巡回を任せても、判定の中身と反映の内容は自分で読む。今回の差し戻しは結果として空振りだった