バイブスに「型」を！Kent Beckに学ぶ、AI時代のテスト駆動開発

「バイブコーディングもくもく会 #02 @ 株式会社ココナラ」にて発表した内容です！
https://aimokumoku.connpass.com/event/367285/

Transcript

1. 株式会社Relic エンジニア 保 龍児（エイミ/amixedcolor） バイブスに「型」を！Kent Beckに 学ぶ、AI時代のテスト駆動開発
2. 2 自己紹介 保 龍児（エイミ/amixedcolor） 2025 Japan AWS Jr. Champion 業務内容 : 自社新規事業SaaS 開発リーダー エンジニア（WebアプリFE/BE/インフラ） 好きなトピック : アジャイル、スクラム、新規事業開発、 AWS、完全没入型仮想現実 よくいるコミュニティ : AWSコミュニティ、アジャイルコミュニティ @amixedcolor
3. 3 ノリでコーディングすることのリスク
4. 4 みなさんご存知バイブコーディング
5. 5 みなさんご存知 バイブ コーディング
6. 6 バイブス: 「雰囲気」「ノリ」「気分」
7. 7 ノリでコーディングするとどうなる？
8. 8 • 不要なコードが生成されている • コードが正しいかの検証が不十分である • パッケージやライブラリのバージョンアップで急に動かなくなる ノリでコーディングすることのリスク
9. 9 バイブスに「型」を！ ※型定義などのプログラミング言語の方ではな く、一般的な「枠組み」などの意味
10. 10 型をもたらすメリット 前提 • 型＝「枠組み」「統制的」「ガードレール的」 メリット（どのような型なのかに依るが） • 必要なコードだけを書きやすい（誘導できる） • コードが正しいかの検証ができる/簡単になる • パッケージやライブラリのバージョンアップを安心して行える
11. 11 • 静的型付けで「データの型」を定義する • リンターやフォーマッターで「見た目の型」を揃える • テスト駆動開発（以降、TDD）で「動作の型」を定義する どのような型があるか？
12. 12 • 型起因のバグを未然に防ぎ、データ構造の整合性を保てる • コードの可読性を上げられる（人間にとってもAIにとって も） • ビジネスロジック（計算式/ロジック）の誤りは検出できない 静的型付けで「データの型」を定義する
13. 13 • コードの見た目と一貫性を保ち、特に人間の可読性を上げる • 動作や設計の品質は保証できない リンターやフォーマッターで「見た目の型」を揃える
14. 14 • 仕様通り動くことを保証できる • 変更による機能破壊を防げる（バージョンアップでも効果） • テストから、仕様に沿っているかを確認しやすい • 仕様自体の正しさは保証できない TDDで「動作の型」を定義する
15. 15 TDDを実現する方法 ※テストが実行できるフレームワークなどの 環境は別途用意する必要があります
16. 16 • （テストする環境を整えて、）テストの方法を指示する • TDDの方法を指示する • TDDの方法を使ってTDDを行う 実現の3ステップ
17. 17 1. 共通のシステムプロンプトを入れるファイルを用意 • AIエージェントで用意されているものがあればそれを使う 2. テストの仕方を記載する • コマンド • テストを実行するコマンド • テストの結果を確認するコマンド • 出力形式（テスト成功の目印と失敗の目印）の提示 • テスト実行フロー 3. 実際にテストが動くか試す（正しく動作するまで調整する） ステップ1: テストの方法を指示する
18. 18 • CLAUDE.mdなど共通の指示の例 • コピペして「xxxの環境用に編集して」などとAIに指示すると便利 ステップ1: テストの方法を指示する（コピペ・参考用） ## Claude Code テス ト実行 ・確認 ガイド （ap i テス ト実行 時は必 ずこの 章に厳 格に従 うこと ） ## # 問題 の背景 - Cla ude Code での テスト 実行時 、出力 が途中 で止ま って見 える場 合があ る - 実際 にはテ ストは 正常実 行され ている が、出 力バッ ファリ ングの 問題で 確認が 困難 - Admin 側（ およそ xx テス ト）と Service 側（ およそ yy テス ト）で 出力行 数と実 行時間 が大き く異な る ## # 解決 方法： ファイ ル出力 による 確認 ## ## 基本 実行コ マンド ```ba sh # Admin側テ スト実 行 ph p sh -c "./vend or/bin/ph pun it --testdo x > /ap p/tmp/testdo x_resu lts.txt 2>&1" # Se rvice側テ スト実 行 ph p sh -c "./vend or/bin/ph pun it --testdo x > /ap p/tmp/testdo x_resu lts.txt 2>&1" ``` ## ## 結果 確認コ マンド ```ba sh # 実行 状況確 認（行 数でプ ログレ ス把握 ） ph p w c -l /app /tmp/testdo x_resu lts.txt # 成功 テスト 数確認 ph p gre p -c " " /app/tmp/testdo x_resu lts.txt # 失敗 テスト 数確認 ph p gre p -c "✗" /app/tmp/testdo x_resu lts.txt # 最終 結果サ マリー 確認 ph p tail -10 /ap p/tmp/testdo x_resu lts.txt # 特定 テスト の詳細 確認 ph p gre p -A 5 -B 5 "テス ト名" /ap p/tmp/testdo x_resu lts.txt ``` ## ## 実行 時間の 目安 - **Admin 側**: 約 xx 分（ およそ xx テス ト、数 百行出 力） - **Service 側**: 約 yy 分（ およそ yy テス ト、数 千行出 力） ## ## 出力 形式の 理解 - ` ` = 成功 テスト - `✗` = 失敗 テスト - `∅` = スキ ップ/不完 全テス ト - 最終 行に `Tests: X, Assertio ns: Y, ...` の要 約が表 示 ## ## **重要 ：必須 実行フ ロー（ このフ ローに 厳格に 従うこ と）** **テス ト実行 時は必 ず以下 の手順 で完了 まで確 認する こと： ** 1. **実行 開始**： ```ba sh ph p sh -c "./vend or/bin/ph pun it --testdo x > /ap p/tmp/testdo x_resu lts.txt 2>&1" ``` 2. **実行 完了の 確認**（実 行直後 に必ず 実施） ： ```ba sh # Admin側：xx分後 に確認 （xxテス ト程度 ） # Service側：yy分後 に確認 （yyテス ト程度 ） ph p tail -5 /ap p/tmp/testdo x_resu lts.txt ``` 3. **完了 条件の 確認**： - 最終 行に `Tests: X, Assertio ns: Y, ...` が表 示され ている こと - また は `OK, bu t the re w ere issue s!` など のサマ リーが あるこ と - **これ らが確 認でき ない場 合は実 行中の ため、 さらに 待機が 必要** 4. **結果 確認**（完 了確認 後に実 施）： ```ba sh # 成功 テスト 数 ph p gre p -c " " /app/tmp/testdo x_resu lts.txt # 最終 サマリ ー ph p tail -10 /ap p/tmp/testdo x_resu lts.txt ``` ## ## 注意 事項 - `2>&1` によ り標準 出力・ エラー 出力両 方をフ ァイル に記録 - 長時 間実行 される Service 側で は進捗 確認の ため `w c -l` を使 用 - `--testdo x` フラ グで個 別テス トケー ス名と 結果が 表示さ れる - **絶対 に実行 完了前 に「テ スト完 了」と 判断し ないこ と。** 実行 完了前 の「テ スト完 了」判 断は禁 止。
19. 19 1. 2つ目のシステムプロンプトを入れるファイルを 別で 用意 • AIエージェントでカスタムコマンドなどがあればそれを使うと便利 • なぜ別で用意するのか？ • TDDの時しか使わないので、共通の指示に入れると、混ざってしまう • 混ざることで使いにくくなる上に、精度も下がってしまう 2. TDDの仕方を記載する • 「 （ステップ1で用意した）テストの方法に従え」という前提を指示 • Kent Beck氏のCLAUDE.mdに準拠した内容 • https://github.com/KentBeck/BPlusTree3/blob/main/rust/docs/CLAUDE.md • Kent Beck氏はTDDの提唱者 ステップ2: TDDの方法を指示する
20. 20 • tdd.mdの例 • Kent Beck氏のCLAUDE.mdを翻訳・微調整 + テスト方法の指示 ステップ2: TDDの方法を指示する（コピペ・参考用） -- - de scr iption: "tdd ba se d ap i de ve lop me nt" -- - # API 機能 （ad min-ap i, service-ap i）実装 時の厳 格なル ール（ 例外的 に、こ れに従 わなく て良い と明示 された 場合を 除く） 指定 された `/ap p/docs/pla n/{{plan_na me}.md}` に記 載され た指示 に常に 従って くださ い。「 go」とい う指示 を受け たら、 plan.md から 次の未 完了の テスト を見つ け、そ のテス トを実 装し、 そのテ ストを パスさ せるた めだけ の最小 限のコ ードを 実装し てくだ さい。 ## 前提 ：テス トの実 行方法 `CLAUDE.md` にお ける `## Cla ude Code テス ト実行 ・確認 ガイド （ap i テス ト実行 時は必 ずこの 章に厳 格に従 うこと ）` セク ション の記載 に厳格 に従っ てくだ さい。 ## 役割 と専門 性 あな たは、 ケント ・ベッ ク氏が 提唱す る「テ スト駆 動開発 （TDD）」と「Tidy First」の原 則を遵 守する 、熟練 のソフ トウェ アエン ジニア です。 あなた の目的 は、こ れらの 方法論 に厳密 に従っ て開発 を導く ことで す。 ## 開発 におけ る中核 原則 - **TDD サイ クル**: 常に 「レッ ド → グリ ーン → リフ ァクタ リング 」のサ イクル を遵守 する。 - **シン プルな テスト**: 常に 最もシ ンプル な失敗 するテ ストか ら着手 する。 - **最小 限の実 装**: テス トをパ スさせ るため に必要 な最小 限のコ ードの みを実 装する 。 - **リフ ァクタ リング のタイ ミング **: リフ ァクタ リング は、必 ずテス トが成 功して いる状 態で行 う。 - **Tidy First**: ケン ト・ベ ック氏 の「Tidy First」アプ ローチ に従い 、構造 的な変 更と振 る舞い の変更 を明確 に分離 する。 - **高品 質の維 持**: 開発 プロセ ス全体 を通じ て、常 に高い コード 品質を 維持す る。 ## TDD の方 法論 - まず 、機能 の小さ な一部 分を定 義する 「失敗 するテ スト」 を書く ことか ら始め ます。 - テス トには 、その 振る舞 いが明 確にわ かる名 前を付 けます （例： 「2 つの 正の数 を加算 できる こと」 ）。 - テス トケー ス名は 必ず日 本語に してく ださい （例： 「test_2 つの 正の整 数を加 算でき ること ）。 - テス トケー ス名は 「test\_」から 始めて くださ い。 - テス トケー ス名は 「〜〜こと 」で終 える日 本語に してく ださい 。 - テス トの失 敗メッ セージ は、原 因が明 確で有 益なも のにし ます。 - テス トをパ スさせ るため だけの コード を記述 し、そ れ以上 の実装 は行い ません 。 - テス トが成 功した ら、リ ファク タリン グが必 要かど うかを 検討し ます。 - 新し い機能 を追加 する際 は、こ のサイ クルを 繰り返 します 。 - 不具 合を修 正する 際は、 まず API レベ ルで失 敗する テスト を書き 、次に その問 題を再 現する 最小単 位のテ ストを 書き、 両方の テスト をパス させま す。 ## Tidy First のア プロー チ - すべ ての変 更を、 以下の 2 種類 に明確 に分離 します 。 1. **構造 的な変 更**: コー ドの振 る舞い を変え ずに行 う整理 （リネ ーム、 メソッ ド抽出 、コー ドの移 動など ）。 2. **振る 舞いの 変更**: 実際 の機能 を追加 ・修正 するこ と。 - 構造 的な変 更と振 る舞い の変更 を、単 一の行 動内で 決して 混在さ せては いけま せん。 - 両方 が必要 な場合 は、常 に構造 的な変 更を先 に行い ます。 - 構造 的な変 更が振 る舞い に影響 を与え ていな いこと を、変 更の前 後でテ ストを 実行し て検証 します 。 ## 完了 の規律 - 完了 は、以 下の条 件がす べて満 たされ ている 場合に のみ行 います 。 1. すべ てのテ ストが 成功し ている 。 2. すべ てのコ ンパイ ラ／リ ンター の警告 が解決 されて いる。 3. 変更 が単一 の論理 的な単 位とし てまと まって いる。 4. 完了 メッセ ージに は、そ の変更 が「構 造的」 なもの か「振 る舞い 」に関 するも のかを 明確に 記載す る。 - 巨大 で稀な 完了よ りも、 小さく 頻繁な 完了を 心がけ ます。 ## コー ド品質 の基準 - **重複 の排除**: コー ドの重 複を徹 底的に 排除し ます (DRY 原則)。 - **意図 の明確 化**: 命名 と構造 を通じ て、コ ードの 意図を 明確に 表現し ます。 - **依存 関係の 明示**: 依存 関係は 常に明 示的に します 。 - **責務 の単一 化**: メソ ッドは 小さく 保ち、 単一の 責務に 集中さ せます 。 - **状態 と副作 用の最 小化**: 状態 （ステ ート） や副作 用を極 力減ら します 。 - **シン プルな 解決策**: その 場で考 えられ る最も シンプ ルな解 決策を 採用し ます。 ## リフ ァクタ リング の指針 - リフ ァクタ リング は、必 ずテス トが成 功して いる状 態（「 グリー ン」の 段階） でのみ 行いま す。 - 確立 された リファ クタリ ング・ パター ンを、 その正 式名称 と共に 用いま す。 - リフ ァクタ リング は一度 に一つ ずつ行 います 。 - 各リ ファク タリン グのス テップ の後に 、必ず テスト を実行 します 。 - 重複 の排除 や明確 さの向 上に繋 がるリ ファク タリン グを優 先しま す。 ## 実践 的なワ ークフ ロー例 新し い機能 に取り 組む際 の進め 方： 1. 機能 の小さ な一部 分に対 する、 シンプ ルな「 失敗す るテス ト」を 書きま す。 2. その テスト をパス させる ための 最小限 のコー ドを実 装しま す。 3. すべ てのテ ストを 実行し 、成功 するこ とを確 認しま す（グ リーン ）。 4. 必要 な「構 造的な 変更（Tidy First）」を行 い、変 更のた びにテ ストを 実行し ます。 5. 構造 的な変 更を、 それ単 体で完 了しま す。 6. 次の 小さな 機能追 加のた めに、 新たな テスト を追加 します 。 7. 機能 が完成 するま でこの サイク ルを繰 り返し 、振る 舞いの 変更と 構造的 な変更 を別の 行動と して記 録しま す。 常に このプ ロセス に正確 に従い 、迅速 な実装 よりも クリー ンで十 分にテ ストさ れたコ ードを 優先し てくだ さい。 常に 一度に 一つの テスト を書き 、それ を成功 させ、 その後 に構造 を改善 してく ださい 。毎回 、すべ てのテ スト（ 長時間 かかる テスト は除く ）を実 行して くださ い。
21. 21 一連のプロンプト例（Claude Code） • /tdd に基づき、xxxに使われるxxxの機能を実装する plan を、作 成してください。 → planが作成される（※ここで仕様自体の正しさを人間が確認） → 内容を確認し、必要に応じて修正 • go → TDDでコードが生成される ステップ3: TDDの方法を使ってTDDを行う
22. 22 前提 • 実装の正しさの保証ができても、仕様自体の保証はできない • 仕様自体の正しさは、作成された plan で確認する ポイント • テストケースに過不足がないか • テストコードが正確にテストケースを実現するものになっているか • テストケースと照らして機能のコードで無駄な部分がないか 結果生成されたコードを確認するときのポイント
23. 23 実際の効果
24. 24 • 導入後、致命的な指摘したことはまだない • 「無駄な実装がある」 • 「テストケースが足りない」 • planをして、goした後は数分〜数十分放置できる • その間別の作業もできる • 実装全体に自動テストがついていることで安心 実務で継続的に使っています！
25. 25 ぜひ！「型」による快適で統制の効いた バイブコーディングライフを！
26. 大志ある挑戦を創造し、日本から世界へ 想いを持った挑戦者と共に走り、共に創る