計画書を書かせ、別モデルでレビューし、3択フォームで決裁するまで

Xを眺めていたら、UIデザイナーの人が自作スキルを紹介する投稿が流れてきた。オブジェクトがどう紐づいているのかを見たくて、デザインデータと概念図とER図を同じキャンバスに乗せ、メニューひとつで行き来できるようにしたという。スクリーンショットが4枚ついていた。

見た瞬間、自分のChrome拡張でも同じことをやりたくなった。会計ソフトAの画面に機能を足している拡張だ。画像4枚をそのままClaude Codeに貼りつけた。

貼ったあと、すぐ実装へ走らせてもよかった。そうはせず、計画から入らせた。まずリポジトリの中身を把握させ、そのうえで計画書を書かせた。

足した機能そのものの話は別記事に書いた。

heredocがクォートで崩れた

計画書の本文をheredocでファイルへ流し込もうとしたら、クォートの扱いで途中から崩れた。バッククォートも引用符も混ざるマークダウンを、シェル越しに長文で渡したのがまずかった。

書き方を変えて、Writeツールで直接ファイルを作らせたら、そのまま通った。

計画書の初稿ができたところで、Codexへレビューを投げた。返事が来るまで、こちらの手は空く。

そのまま待つ理由はない。決裁フォームに載せる選択肢を先に用意させた。続けてsvg-diagramを読ませ、計画書に入れる図を描かせた。レビューが返るころには、図も選択肢も揃っている。

返ってきたのは、文章の良し悪しではなく、実データの誤りを1件突く指摘だった。計画書に書いた保存キーの前提が違う、という。

鵜呑みにはしない。 Codexの判定をそのまま受け取らないのは普段からの方針だし、今回はコードを見れば済む話だった。拡張のコードをもう一度grepし直して、自分で確かめた。

指摘どおりだった。

mfc:year:...   帳簿チェックが使う保存キー
mfv:year:...   明細一覧ビューが使う保存キー

接頭辞が2種類あって、別物を保存している。最初に計画書を書かせたとき、mfc: だけを検索していた。片方しか見ていない状態でキーの一覧を作り、その一覧を前提に設計を組み立てていたことになる。

このまま実装へ入っていたら、キーの一覧を前提に組んだ部分を書き直すことになっていたはずだ。すぐ作らせずに計画書を挟んだのは、これのためだった。

計画書を直して、もう一度Codexに投げた。今度は「承認」が返ってきた。

計画書が固まっても、こちらが決めないと先へ進めない項目が3件残った。

ターミナルの選択肢で聞かれるのは、この手の判断と相性が悪い。何を天秤にかけているのかは計画書の本文に書いてあるのに、選ぶ画面には選択肢の文字列しか出ない。前提を読み返そうとすると、選択の画面をいったん抜けることになる。

そこで計画書をHTML化して、判断が必要な箇所に3択ボタンを埋め込んだフォームを立てた。計画書を上から読んでいき、読み終わった流れのままボタンを押せばいい。

フォームを立てたら、描画を自分の目で確認する。

ところが、いつも使っているChromeのデバッグポートが開いていなかった。ここで復旧に時間を使う理由もないので、ヘッドレスで立ち上げてスクリーンショットを撮らせた。

1枚目で、UIが生成されていることは分かった。ただし全体を1枚に収めた画像では、ボタンの見た目までは分からない。判断事項の部分だけを切り出してもう1枚撮らせ、3択が崩れずに並んでいることを見た。最後に、待ち時間のあいだに描かせた図の描画も確かめた。

ここまで済ませてから、判断事項3件をブラウザで選べる状態にしたと報告し、http://127.0.0.1:8899/ を添えた。

#計画書#Codexレビュー#決裁フォーム#Claude Code#開発プロセス#開発日記