テスト連載2026 の4本目です。
AI戦略推進グループ(AIXG) の佐藤です。
最近は業務でも趣味でも Claude Code にコーディングさせることが増えてきました。趣味の方では、先日社内有志とともに参戦した AtCoder マスターズでも Claude Code 先生が大活躍でした。
さて昨今流行りの vibe coding、適当に回して放って置くと使い物にならないゴミを生じることが多々あります。
ゴミにならない事を祈りながら使うのは流石に宜しくありません。なんとか再現性を保ちつつ品質をコントロールしたいというところで、自分一人でちょっとしたツールを作りながら AI Slop を踏んでは潰してやっとまともに動くようになってきたためブログ記事にしようと思います。
本記事の試行錯誤の大半は3月頃の話です。
業務ユースも幾らか始まっている中で、お客様に提供するコードを生成するならもっと真面目にハーネスとテストケースを作ります。作っています。
今回の題材
社内制度を非常にぼかして説明すると、今年から”とある”管理が結構厳しくなりました。この管理用サイト上の任意の操作が異様に重い上に、左右にウィンドウ分割したりすると画面がはみ出し操作不能となり、ちょっとイレギュラーな入力をしたりすると融通が効かず、削除操作は都度都度ポップアップが出てきて、その癖 1 日分で 10–20 回くらいの繊細なマウス操作を要求されます。当然一回の操作ごとに数秒のウェイトが挟まります。
そこで代わりにターミナル上のキーボード入力だけで完結するツールを Claude Code をベースに作りました。
(vibe coding における) TDD
新し目のところでこの辺を読んでください。
“t-wada の TDD” と限定することでクオリティが上がる話は X 旧 twitter で流れていたのを目にしてやってみたところ、結構良くハマりました。
おそらく同じ方の note 解説記事 → 降霊術で t_wada を AI に降ろして PR レビューして貰うテクニックが伸びたのでその裏側記事を書きました！
じゃあ、「”t-wada の TDD” で作って」
ツールのリクエストとレスポンスを平文で置いて、作りたいものを説明して、呪文を唱えてもまず動きません。
TDD のサイクルで実現できるのは、いま動かないもの (red) が将来にわたって動くようになること (green) です。加えて、動かなくなったときすぐ直せるようにしておくこと (refactor) も。
どの順番で何をどのくらい動くようにするかという取捨選択がどうしても大切です。それが「テストリスト」と呼ばれる最初のステップで、AIへ任せ切るために人の手が必要なステップです。
多くの人が、書籍『テスト駆動開発』の中に出てくるこのステップ1を見逃しているようだ。「TDDはいきなりコードを書き始める。いつ終わるのかも全然見通せない」という意見は、全くの見当外れだ。
テストリストのコントロール
今回の記事がテスト連載であることを思い出しました。
まずは、毎回のセッションで作りたい機能を言語化します。裏返せばこういう機能が実現されていること、という大枠の外部結合テストケースになります。この大枠を個別具体の関数の挙動に置き換えた単体～内部結合くらいのテストケース、これがAIに作らせるテストリストです。
そういうわけで、初期情報取得、入力、送信など、システムとして切り分けるならここが単位かな、というところで切り分けて置くとスムーズです。もし慎重にいくのならば Plan mode でここでできたリストを確認すると良いでしょう。最近の私は Auto mode で突っ走らせつつ、何かまずそうなら Esc で止めて（場合によっては過去に遡って歴史改変しながら）修正案を投げています。
機能ごとに切り分けておくとよいのは新規機能に限った話ではありません。いまこの記事を書きながら「1日単位ではなく1週間単位でまとめて入力送信できるようにしたい」みたいな指示をしたら、入力画面自体1週間単位になりそうだったので慌てて Esc 押しました。「入力は1日ごと、送信をまとめて」。
また、特に改修を実施するときには、今回のテストの内容にとどまらず過去との整合性も必要です。いまある挙動を変えないことはいまあるテストが保証してくれていますが、過去の挙動に影響がありそうな修正に対してはどうあるべきかを一緒に与えないと結構壊れます。大体は今回の指示を優先してよい一方、変えて欲しくないところまでもまとめて壊そうとするのでテストリストを見てまずそうなら介入します。
そうして一瞥した、あるいは Auto Mode で高速に流れていくテストリストが大丈夫そうであれば、あとは目を離しても早々酷いことにはなりません。最後に動いてそうならば CLAUDE.md, もしくはそこからリンクされている仕様書を更新して終了です。
酷いことになるとしたら過去のテストを沢山巻き込むような大幅にデグレてしまったときで、こうなると面倒になるのか過去のテストを雑に green にするような hack をかましてくることがあります。予想以上に diff が膨らんだ際にはクリーンな別の session を立ち上げて監査を行うことで対応しています。
できたもの
を見せられれば良かったのですが、もれなく社外秘のため。
ただ、ある程度ツールが完成して以降というもの当該の管理サイトは週1で確認のために開くだけになりました。一式ぜんぶ手元で入力した後にまとめてリクエストだけ送信して事を済ませています。とても便利。
おわりに
頭はいいけどそこまで詳しくない生成 AI に説明できるように、作りたいものに対するドメイン知識が今後もっと大事になってくる……という話は一般によく聞きますが、ではどのように活かすのか？ というとなんともはぐらかされがちです。
本記事では簡単な一ツールを例にしたところですが、質の良いテストリストを初っ端から精度よく生成できるような指示を与えられるのであれば、動き出しのスピードが早くなるということなのでしょう。
特に今回みたいな terminal 上のツールでよいのであれば、E2E や画像読み書き、Officeファイル作成など、AI にやらせるとトークンを結構な勢いで消費する人間向けの儀式をショートカットして進めることができます。極論一周回って半世紀前みたいなUIのツールが流行ってもおかしくないかもしれません。本当に、これならすぐできるので。
ところで5月半ばくらいに /goal 機能ができたのでこの記事で気をつけるべきことの半分以上はもう不要なナレッジの可能性があります。キャッチアップはどこまでも。