CF教材の消費税対応をP0からP4-2まで進めた日。仕訳の削除と投入は内部APIが速い
同じ指摘を、1日のうちに2回言うことになった
前日に書いたCF教材の消費税対応の計画書を握って、朝7時にP0から始めた。フェーズはP0からP5まで刻んである。区切りごとにCodexのレビューを受け、次のセッションへの引き継ぎプロンプトをダウンロードフォルダにテキストで置き、コンテキストを捨てて次を開く。この形で5回セッションをまたいだ。
夕方にはP4-2まで来ていた。ただ、途中で同じことを2回言うはめになっている。それが今日いちばん残った出来事だった。
なお5セッションとも、動いていたのは計画書が想定していたOpus 5ではなくFable 5.1だった。冒頭で毎回そう報告させたうえで続行している。
P0とP1で、税区分を測って1論点の型を作る
P0では会計ソフトAの税区分をそのまま実測させた。P1は304の運転資本を税込に直して、他の論点へ横展開できる型を作るところまで。計画書§6の検証1から5は、すべてcheck=0で通った。
途中で気になって、Dropboxのどのファイルが書き換わったのかを聞いた。返ってきたのは「運転資本のフォルダだけ、Excelが3本」。301から306に手が付いていないのは計画書どおりの段取りで、つまりフェーズ1が終わった状態だった。そこで計画書を更新させ、P2の引き継ぎプロンプトをダウンロードフォルダに保存させた。
レビューの上限4000行と、走っているゲートを書き換えた事故
P2（301から306の税込化と300への統合）は、各モジュールと300でcheck=0をExcelの実評価まで確認して終わった。Codexにも読ませて、指摘3件に対応させた。売却対価の課税売上、前払家賃の控除時期、支払利息の非課税仕入という会計処理そのものには誤りなし、という評価だった。
引っかかったのはコミットのほうだ。差分6,156行が上限の4,000行を超えたという理由で、コミットゲートのCodexレビューが自動スキップされた。上限は誰が決めているのかと聞くと、Codexではなく自分のフックスクリプトの既定値だという。今日そのゲートを入れたときに、「時間と費用」を理由に置いた数字だった。スキップされるなら意味がないので、7,000行に上げさせた。
ここで事故った。前のコミットをgit reset --softで解いて再コミットしている最中に、走っているゲートスクリプト本体を書き換えさせてしまった。待っているあいだレビューログは58万バイトまで伸びていて、Codex自身は8分かけてレビューを終え、JSONも正常に書けていた。落ちたのはその外側で、shが再開時に別の行の途中から読み、構文エラーになってコミットが失敗した。「実行中のゲートを編集しない」をリファレンスに残させた。
このときのゲートの判定はblock（high 1件）だった。指摘を直して再コミットさせ、今度はcriticalもhighもなしで通過した。差分6,221行のコミットが1本残った。
未収消費税の科目は、ブラウザを操作させて作った
P3を終えたあと、未収消費税の勘定科目を作らせた。管理画面を自分で開くかわりに、Chrome DevTools経由で検証用の法人に科目を追加させ、画面で出来上がりを見た。分類の根拠と、どの事業者にログイン中かを先に確認させてから触らせている。
407件の削除が、待っても終わらない
P4で詰まったのはここだった。投入前に仕訳を消す必要があり、削除ジョブ407件を走らせたら、250件まで進んだところでまだ待っている。
会計ソフトAの公開APIは、削除を1件ずつ投げてレスポンスを待つ作りになっている。だから件数ぶんだけ時間が積み上がる。一方でWeb UIの内部APIには一括削除があって、そちらなら一発で終わる。この話は別リポジトリの実装ドキュメント（会計ソフトA向けのChrome拡張側）に書いてあった。
そこを教えて、削除は今後すべて内部APIに切り替えさせ、計画書にはそのドキュメントへの参照を足させた。知見が外部リポジトリ側にしか無いと、次のセッションでまた同じ遠回りをする。
投入側にも、同じ話があった
削除で内部APIを使ったなら、投入側も同じはずだと思って続けて聞いた。内部APIにはCSVインポートがあり、公開APIで1本ずつ登録するより速い。
実際、300総合演習の5年度623仕訳は、全部CSVインポートで入った。公開APIのほうはこのとき1リクエスト20秒前後と遅く、突合の再実行だけで数分かかっている。差がそのまま出た。
この日の投入と突合は3論点（304、300、202）まで進み、5項目すべて不一致0件で揃った。202の47件は検証用の法人に残してある。
criticalかどうかを、誰が決めているのか
コミットゲートを3回回した時点で、Codexの指摘は11件になっていた。仕訳の再送で決算整理仕訳が二重登録される、CSVを配る一時サーバーが任意のWebページから読める、一括削除が対象事業者を確認しない。並べられるとどれもcriticalに見える。
ここで手を止めさせた。Codexが付けた重要度をそのまま飲み込んで直しては回し直しているように見えたからだ。中身を見て自分で判定してほしい、と伝えた。
判定し直させると、本当にcriticalと言えるのは事業者の照合1件だけだった。残りは「直すのが安いから直した」もので、放置しても教材データが壊れる類ではない。そう分かれば4回目のゲートは要らない。省略の理由をREVIEW_SKIP_REASONに書かせて、そのままコミットさせた。
この運用はフック側にも残させた。書き足したのは3点。重要度はCodexの判定を鵜呑みにせず中身を見て判定し直すこと。報告には両方の判定と理由を並べること。自分の判定がmedium以下なら、理由を書いて通してよいこと。グローバルのCLAUDE.mdにあるコミットゲートの節など、4か所に入れてある。
P4-2の段取りを決める
P4が出口条件まで終わったので、残りを次のセッションにどう渡すかを決めた。やることは3つある。201、205、301、303、305の投入。300と200番台で必要な補助科目の登録。次年度繰越で会計ソフトA上の期末残高を繋ぐこと。
繰越も内部APIでやればいい、と伝えた。仕訳をCSVインポートで入れるのだから、その完了を確認してから繰り越せば同じ流れに乗る。年度ごとに繰り越しても最後にまとめても結果は変わらないので、やりやすいほうでいい。
ただし最終確認は自分でやる。まず一通り全部入れて、仕訳が合う状態まで持っていってもらう。そのうえで後日、画面を見ながら一緒に確認していく。ここは任せきりにしない部分なので、引き継ぎプロンプトにもその前提を書かせた。
5回目で、同じ指摘をもう一度することになった
P4-2のセッションのログを見ると、コミットゲートが5回目を回していた。突合CLIを直した版で300を再実行して不一致0件、繰り越し直しの完了判定も「処理中」を待ってから完了になることを実測で確認しているところまでは良い。問題はそこに至るまでにゲートを5周していることだった。
本当に5回も必要なのか、と聞いた。数時間前に同じことを言ったばかりだった。
返ってきた答えは「5回は不要でした」。1回目で自分がhighと判定した1件だけ直し、残りは自分の判定を書いて通すべきだった、Codexの判定に引きずられて直しては回し直し、約20分を無駄にした、というものだった。5回目はそこで止めさせてコミットさせた。
ルールに書いただけでは、次のセッションで元に戻る。フックに入れた文面が実際に効くかどうかは、明日以降のコミットで見ることになる。
売却前減価償却3件の月額按分をどう入れるか
最後に残っていたのが、売却前減価償却3件の月額按分だった。報告を読みながら、これは決算整理仕訳として入れなければいいだけではないか、と思った。303と202と300のやつはできなかったのか、と聞いてみる。
できた。生成器の側で、売却前減価償却に決算整理仕訳の印を付けなければ済む話だった。着手前に「生成器は自分が直すと決めたときだけ触る」と指示してあったので、そこには手を付けずにいたという。決裁して、生成器の3箇所だけ直させてコミットさせた。
再生成と会計ソフトAへの入れ直しは明日に回した。明日の開始用プロンプトは、いつもどおりダウンロードフォルダにテキストで置かせてある。
学びメモ
- 会計ソフトAの公開APIは削除も登録も1件ずつレスポンスを待つ。件数が多いときはWeb UIの内部API（一括削除とCSVインポート）のほうが速い。知見が別リポジトリのドキュメントにあるなら、計画書から参照を張っておく
- レビューの重要度は、レビュアー側の申告ではなく自分で判定し直す。「この経路で実際に何が壊れるか」を見れば、criticalは11件のうち1件まで減った
- フックやスクリプトは、走っている最中に書き換えない。
shは実行中のファイルを読み進めるので、途中の行から再開して構文エラーになる - フェーズの区切りで引き継ぎプロンプトをテキストに落としておくと、コンテキストを捨てて次のセッションを開ける。5回またいでも計画書と突き合わせて進捗を確認できた