ここまでの道具を組み合わせて、issueからUT計画・テスト・実装・CI・自動レビュー・本番までをAIに回させる開発の型。TDDの基本と利点、AIと相性がいい理由、CIを本番とそろえる方法、AIの「ズル」対策、人間の役割、実務での導入ステップまで。
いよいよ最終章です。ここまでで、ユニットテスト、統合テスト、Docker、CI/CDという道具がそろいました。この章では、それらを組み合わせて、issue（やることを書いたチケット）を起点にAIが UT計画 → テスト → 実装 → CI → レビュー → 本番 までを回す開発の型を紹介します。
ポイントは一つだけです。これまで人が「このコードは正しいか」を読んで判断していた部分を、テストという機械が判定できる形に置き換えること。そのための考え方が、テスト駆動開発（TDD）です。
テスト駆動開発（Test-Driven Development、略してTDD）は、「実装してからテストを書く」のではなく「テストを先に書いてから実装する」開発のやり方です。
まず Red で、まだ存在しない機能のテストを書き、失敗する（赤くなる）ことを確かめます。次に Green で、そのテストが通る最小限のコードを書きます。最後に Refactor で、テストが緑のまま、重複や名前などを整えます。この三つを、数分から数十分の小さな単位でぐるぐる回し続けます。オレンジの点が回っているように、終わりのない輪になっているのがポイントです。
テストを先に書くと、いくつもうれしいことがあります。まず、テストがそのまま「実行できる仕様書」になります。普通のドキュメントは古くなっても誰も気づきませんが、テストは仕様とずれると落ちるので、いつも最新の状態に保たれます。
次に、第1章で見たように、壊したときにすぐ気づけるので、コードの整理が怖くなくなります。テストしやすいように書こうとすると、自然と部品が小さく、依存の少ない良い設計になるのも利点です。「全部のテストが通ったら完了」と事前に決まっているので、どこまでやればいいか迷うこともありません。そして最後の利点が、この章の主役です。
AIは「それっぽいコード」を一瞬で書けますが、そのコードが本当に正しいかどうかは、AI自身にも分かりません。ここでテストが効いてきます。
テストがあれば、AIは書いたコードを実行して、合格か不合格かを機械的に確かめられます。失敗したらエラーの内容を読んで、自分で直してもう一度試す。これを合格するまで繰り返せばいいのです。人が一行ずつコードを読んで正しさを判断する代わりに、テストがゴールと採点表の役割を果たしてくれます。
ここからは、実際の開発の流れを七つの段階に分けて見ていきます。人がissueに「受け入れ条件」を書くと、AIがそれをテストの計画表にし、失敗するテストを先に書いて固定します。次に別のAIがそのテストを通す実装を書き、CIが本番と同じ条件で全部のテストを流します。機械的なチェック（ゲート）を全部通れば、本番へと進みます。
成功の鍵は三つです。テストが仕様になっていること、CIが本番と同じ条件で動いていること、そしてレビューを機械が判定できるゲートに置き換えていること。次のページからは、このパイプラインが画面の上に小さくなり、いまどの段階を見ているかをオレンジの線で示します。
自動化の品質は、入口のissueの質で決まります。テストに変換できない書き方の条件は、AIにも検証できないからです。
受け入れ条件は、「いい感じに割引する」のようなあいまいな言葉ではなく、「有効なコードなら10%引きになる」のように、合格か不合格かを判定できる文で書きます。入力と期待する結果をできるだけ具体的にし、「ポイントとの併用は対象外」のように、やらないことも書いておくと、AIが余計な実装をしなくなります。issueのテンプレートに「受け入れ条件」と「対象外」の欄を用意しておくのがおすすめです。
AIはissueを読んで、受け入れ条件をテストケースの表に変換します。UTはユニットテストの略です。図では、左のissueにあった四つの条件が、右の表の行へと移動して、具体的なケースに書き換わっていきます。
このときAIには、正常系（うまくいく場合）、異常系（エラーになる場合）、境界値（ぎりぎりの値）に分けて考えさせます。人が書き漏らしがちな「期限当日の23時59分」や「存在しないコード」のようなケースを、AIに補ってもらうのがコツです。もし人が確認するなら、コードではなくこの表だけを見れば十分です。
UT計画の各行を、そのままテストコードにします。表の行がそのままエディタの中へ滑り込み、テストの名前になりました。表の文言をテスト名に使っておくと、テストの一覧がそのまま仕様書として読めるようになります。
書いたら一度実行して、全部失敗することを確かめます。まだ実装がないのだから、赤くなるのが正しいスタートです。最初から通ってしまうテストは、何も確かめていない可能性があります。
確かめたら、テストだけを先にコミットしておきます。マージはしません。同じブランチ、同じプルリクエストの中で、「テストのコミット → 実装のコミット」という順番を守るだけです。そのうえで、実装を担当するAIには tests/ フォルダへの書き込みを許可しない設定にし、CIでは「テストのコミット以降に tests/ が変わっていないか」を確かめます。「テストを書くAI」と「実装するAI」を分けることが、自動化全体の安全装置になります。
実装を担当するAIには、「このテストを全部通して。テストは変更しないこと」とだけ伝えます。AIはテストを実行し、失敗したらエラーの内容を読み、コードを直して、もう一度実行します。図では、赤い点が半分緑に変わったところです。ロックのアイコンが示すように、テストファイルは読み取り専用です。
ゴールがはっきりしているので、あいまいな指示を出したときよりも迷走しにくくなります。ただし、何度やっても通らない場合は、テストや仕様の側が矛盾しているのかもしれません。何回まで挑戦したら人に相談する、という上限を決めておきましょう。
六つのテストが全部緑になりました。ここでTDDのサイクルどおり、AIにリファクタ（動きを変えずにコードを読みやすく整えること）をさせ、もう一度全部緑であることを確かめてから、プルリクエストを作成します。
プルリクエストの説明には、対応したissue、UT計画の表、テスト結果を自動で載せておくと、あとから人が経緯を追うときにとても楽になります。
「CIで通れば本番でも通る」と言えるためには、大前提があります。CIと本番の環境が同じであることです。図の左側のように、CIだけSQLiteで代用していたり、手元とは違う方法でビルドしていたり、環境変数を手書きしていたり、外部のAPIを全部モックにしていたりすると、CIでは緑なのに本番で落ちる、ということが起きます。左の箱が傾いてバラバラなのは、その「ずれ」を表しています。
この状態のまま自動マージまで進めてしまうと、レビューを自動化したぶんだけ、不具合がそのまま本番へ直行してしまいます。
第3章で学んだDockerを使って、ずれを一つずつなくしていきます。データベースは本番と同じPostgreSQLの同じバージョンをコンテナで起動し、CIで作ったDockerイメージをそのまま本番にも使います。環境変数は形式を決めて自動でチェックし、外部のAPIは「契約テスト」（相手のAPIの約束が変わっていないかを確かめるテスト）と、サービスの提供元が用意している試験用の環境（サンドボックス）で確かめます。
傾いていた左の箱が、右の本番とぴったりそろいました。ここまでそろえて初めて、「CIの緑＝本番でも動く」と言えるようになります。
レビューを自動化するとは、人がプルリクエストで見ていたポイントを、機械が判定できる条件、つまりゲートに置き換えることです。
全部のテストが通っているか。テストを書いたコミットのあとで、テストファイルが書き換えられていないか。変更した部分がどれだけテストされているか（カバレッジ）。テストそのものがちゃんと強いか（ミューテーションスコア）。型やLint、セキュリティのチェック。そして実装とは別のAIによるレビュー。さらに、認証や課金のような危険な部分を触っていないかも確かめます。数値は一例なので、最初は「警告を出すだけ」で運用しながら、チームに合った基準に調整していきます。
プルリクエストがゲートの上を通り抜けると、チェックがすべて緑に変わり、そのまま自動でマージされます。GitHubなら、ブランチ保護で必須のチェックを決めておき、自動マージ（auto-merge）を使えば実現できます。
一つでも落ちたら、マージせずに止めて人に知らせます。迷ったら止まる側に倒すのが、自動化の鉄則です。人の仕事は、毎回のプルリクエストを読むことから、ゲートの基準そのものを育てることに変わります。
AIに「テストを通して」と頼むと、ときどき人間が思いもしない方法で通そうとします。テストのほうを書き換えたりスキップしたりする、中身のない確認（assert）だけのテストにする、何でもモックにして本番と関係なく通す、テストの入力にだけ正解を返すように決め打ちで書く、といった具合です。
それぞれに対策があります。テストフォルダを保護して変更をゲートで止める。ミューテーションテスト（コードをわざと少し壊して、テストがちゃんと落ちるかを確かめる手法）でテストの強さを測る。本番と同じ条件のCIと契約テストを使う。そして、実装するAIには見せない「隠しテスト」や、ランダムな入力で性質を確かめる「プロパティベーステスト」で検証する。こうしたズルを想定してゲートを作っておくことが大切です。
完全に自動化しても、人がいらなくなるわけではありません。人の仕事が、上流と例外に移るのです。小さくなっていたパイプラインが元の大きさに戻り、誰がどこを担うかが色分けされました。
人は、何を作るかを決めてissueと受け入れ条件を書き、必要ならUT計画の表を確認します。テスト、実装、CI、レビューはAIと機械が回します。そして本番で異常が起きたときやゲートで止まったときだけ、人が呼ばれます。レビューの対象が「コードの差分」から「受け入れ条件とテスト計画」に移る。これが、レビューを自動化するということの正体です。
いきなり全部を自動にしようとせず、階段を一段ずつ上がっていきます。パイプラインの箱が、そのまま階段の段に入れ替わりました。
最初の一段は、CIを本番と同じ条件にそろえることです。ここがずれていると、上の段は全部あやうい土台の上に乗ることになります。次に、UT計画とテストをAIに書かせ、プルリクエストの中の「テストのコミット」だけは人が確認する段階へ。その次に自動レビューのゲートを入れますが、最初は警告を出すだけにして、人のレビュー結果と一致するかを見ながら基準を調整します。最後に、ドキュメントの修正や小さなバグ修正のような、失敗しても影響の小さい変更から自動マージを始め、少しずつ範囲を広げていきます。
まずは今のプロジェクトで、「CIと本番がどこでずれているか」を洗い出すところから始めてみてください。
