Skip to main content
KISS TS版YAGNI TS版SoC TS版ADR TS版HC/LC TS版DRY TS版リファクタリング TS版テスタブル TS版TDD TS版エラーモデリング TS版レイヤー TS版MVC TS版依存関係ルール TS版DIP TS版DI TS版Is-a/Has-a TS版SOLID TS版GoFデザインパターン TS版Observer TS版CQS TS版状態機械 TS版不変条件 TS版Entity/VO TS版DDD TS版集約/境界 TS版ドメインイベント TS版モジュラーモノリス TS版ヘキサゴナル TS版クリーンアーキ TS版ACL TS版API Contract TS版SemVer TS版DbC TS版冪等性 TS版CAP定理 TS版Outbox TS版Saga TS版CQRS TS版イベントソーシング TS版BC TS版

第06章：AI時代のTDDルール（使い方固定）🤖✅

AIロボットの相棒

🎯目的​

AI（Copilot / Codex など）を使っても、TDDの品質（＝テストが仕様書）を絶対に崩さずに回せるようになること💪✨ 「AIが主役になって仕様がねじれる」を防いで、いつも同じ手順で安心して進めるための“固定ルール”を作ります🧷

📚学ぶこと（この章のコア）📌​

1) AIは“速いけど間違える”前提で扱う🧠​

GitHub公式も、Copilotの提案は**必ず検証（validate）**して、テストやツールでチェックするのを推奨しています✅ (GitHub Docs)

2) 依頼の粒度：AIには「小さい仕事」だけ渡す🔪​

Copilotも「複雑なタスクは分解して」「要件は具体的に」って方針です✍️ (GitHub Docs)

3) “テストが仕様”はAI時代ほど強い🧪📘​

AIがどれだけ賢くても、最終的に正しいかを決めるのはテスト。 だからこの章は、AIの使い方を「固定化」して、テストが常に上位になるようにします👑

4) AIツールの性格を知る（Chat / Inline / Agent）🧰​

  • Copilot：Inlineは“小さい補完”、Chatは“まとまった作業＋対話”に向くよ、という整理がされています🧩 (GitHub Docs)
  • Codex：IDE拡張で Chat / Agent / Agent(Full Access) みたいに“自動化の強さ”を選べる設計です（＝ルールが超重要）🎚️ (OpenAI開発者向け)
  • ちなみに Codex の VS Code 拡張は Windowsサポートが実験的という案内もあるので、使うなら注意点は押さえよ〜⚠️ (OpenAI開発者向け)

✅AI時代のTDD “固定ルール” 7つ（ここが本体）🧷🤖​

ルール1：仕様は「文章」じゃなく「テスト」に刻む🧪🪓​

  • AIに説明する前に、まず自分で Given/When/Then を1行で書く
  • それをテスト名（またはコメント）にする
  • AIにはその“仕様の骨”を渡す

仕様がフワッとしてると、AIが勝手に補完して別物になります🥲 だから「テストに刻む」✨

ルール2：AIへの依頼は「テスト」か「次の一手」だけ🪜​

画像を挿入予定

AIに丸投げしないで、依頼をこの3種類に限定します👇

  1. 次に足すべきテスト候補（境界値/異常系の洗い出し）
  2. テストの書き方の改善（命名、AAA整形、Assert強化）
  3. 失敗ログの読み解き（原因仮説→最小修正案）

GitHubのテストチュートリアルも「良いテストを作るには、より具体的なプロンプトや戦略が必要」って言ってます📌 (GitHub Docs)

ルール3：AIが出したテストは“穴がある前提”でレビュー👀​

Copilotには /tests みたいにテスト生成のショートカットもあるけど、カバーしきれない場合があるから必ず見直してねと明言されています🧯 (GitHub Docs)

チェック観点（この章で固定）👇

  • ✅ 境界値が入ってる？（0、1、最大、直前など）
  • ✅ 異常系が入ってる？（無効入力、例外、reject）
  • ✅ 仕様の言葉になってる？（実装の写しじゃない？）
  • ✅ 1テスト＝1約束になってる？

ルール4：AIの提案は「理解できた部分だけ」採用🧠✅​

GitHub公式のベストプラクティスでも「理解してから実装」「注意深くレビュー」って流れが書かれています🧾 (GitHub Docs)

採用ルール（固定）👇

  • ✅ 自分が説明できる
  • ✅ テストが落ちる→通るが確認できる
  • ✅ 将来読んでも意図が残る

ルール5：検証は“テスト＋型＋lint”で機械的にやる🧪🔍​

「AIが間違えたかも…」を心で判断しない！ 自動チェックに寄せるとブレません✨ GitHub公式でも「自動テストやツールでチェック」って推してます🧰 (GitHub Docs)

ルール6：AIに“仕様決定権”を渡さない👑🚫​

AIに任せちゃダメなもの👇

  • 仕様の決定（ビジネスルールの最終決定）
  • 例外メッセージの基準（ユーザー向け文言など）
  • 重要な境界（どこまでユニットで、どこから統合か）

AIは提案係！決めるのはあなた🫶

ルール7：採用/却下の理由を1行メモする📝✨​

これ、地味に最強です🔥 あとから迷子にならないし、AIの提案も上手くなる！

例👇

  • 採用：境界値が仕様に合ってる、テスト名も読みやすい
  • 却下：例外の種類が違う、仕様にない挙動を足してる

🧪手を動かす：AI案を「採用/却下」して理由を書く練習💪🧸​

お題：送料計算（ミニ仕様）📦​

  • 小計が 3000円以上なら送料 0
  • それ未満は送料 500
  • ただし地域が "Hokkaido" なら +500
  • 小計がマイナスはエラー

ステップ①：自分で“最小の仕様テスト案”を3本書く🧪​

（コードじゃなくてOK！テストの文章でOK！）

例：

  • 3000円以上なら送料0
  • 2999円なら送料500
  • 北海道なら+500される

ステップ②：AIに「追加すべきテスト候補だけ」聞く🤖​

プロンプト例（コピペOK）👇

  • 「上の仕様に対して、足りないテスト観点を境界値/異常系中心に箇条書きして。1項目に理由も添えて」

ステップ③：AI案を“採用/却下”して理由を1行で書く📝​

  • 採用したもの → 次のテストにする
  • 却下したもの → なぜ違うか明文化（仕様の守りが固くなる！）

🤖AI：毎章使える「質問テンプレ」セット（第6章の提出物）🎁✨​

テンプレA：次の一手（最小テスト）🪜​

  • 「この仕様で 次に足すべき最小テストを1本だけ提案して。テスト名案＋Given/When/Thenで」

テンプレB：観点の穴あけチェック（境界/異常系）🕳️🔍​

  • 「境界値と異常系の観点を 漏れなく出して。各項目に“なぜ必要か”も付けて」

テンプレC：失敗ログの診断（最小修正）🧯​

  • 「この失敗ログの原因仮説を 可能性が高い順に3つ。各仮説ごとに“最小修正案”も」

テンプレD：テストを仕様書にする命名📝​

  • 「このテスト名、仕様が読める形に直して。案を3つ。誤解しにくい理由も」

✅チェック（できたら合格）🎉​

  • ✅ AIに“実装まるごと”を渡してない
  • ✅ AIの提案を 採用/却下で仕分けできた
  • ✅ 却下の理由が「仕様に照らして」書けてる
  • ✅ “テストが仕様の上位”になってる
  • ✅ AIのコード/テストは 必ず検証する流れになってる (GitHub Docs)

🌸この章のミニ提出物（教材っぽく）📦​

  1. AI質問テンプレ.md（テンプレA〜Dを貼るだけでOK）
  2. 採用/却下ログ 10件（1行理由つき）

次の第7章からは、いよいよ「回せる土台（フォルダ構成）」を作って、ここで決めた固定ルールを“習慣化”していくよ〜🧪🔁💖