第34回：【テストコードのガイドライン その9】【AI連携】AIにテストを書かせる極意 ── 規律なきAIは「負債」を量産する。

♨️ AIという名の「暴走特急」

東根温泉支部の朝。開発室の窓からは、温泉街を包む朝霧が朝日を浴びて、琥珀色に輝きながら消えゆくのが見える。その静謐な空気とは裏腹に、ヒマリのデスク周辺だけは、まるで未来都市のように活気づいていた。

ヒマリは今、生成AIをフル活用した開発フローの構築に夢中だった。エディタ上でAIに指示を飛ばすと、ものの数秒で複雑なテストコードが画面を埋め尽くしていく。

ヒマリ： 「……よし！ また10ケース完成。……。サキ先輩、見てください！ AIを導入したら、テストコードの作成時間がこれまでの10分の1になりました。もはやタイピングの速度すら必要ありません。これで爆速開発間違いなしですよ！」

ヒマリは、かつてない高揚感に包まれていた。「書く苦しみ」から解放され、膨大なテストコードが「自動的」に積み上がっていく光景は、エンジニアにとっての理想郷（ユートピア）に見えた。

サキ： 「おー、文明の利器じゃん。✨ 本当、魔法みたいにコードが増えてくね。……。」

サキは、次々と生成されるコードの奔流を眺めながら、不敵な笑みを浮かべた。

サキ： 「……でもさ、ひま。その山のようなコード、誰がレビューするの？✨」

♨️ レビュー地獄と「負債」の山

サキのその一言は、予言のように的中した。 午後、ヒマリが自信満々に提出したプルリクエストをレビューし始めたサキの顔が、見る見るうちに険しくなっていく。

サキ： 「……ひま、ちょっとこっち来て。✨」

ヒマリ： 「はい！ どうですか？ 網羅率もバッチリですし、バグも見当たらないはずです！」

サキ： 「うーん、バグがあるかどうかの前にさ……『読みたくない』んだよね、このコード。✨」

サキが指差したAI生成コード。そこには、規律を失った「野良のAI」が吐き出した醜悪な構造が広がっていた。

1. 構造の不在: AAAの原則などどこへやら。準備（Arrange）の途中でいきなり実行（Act）が走り、また準備に戻る。迷路のような構成。

2. 実況中継の連発: 「変数が空でないこと」「型が正しいこと」など、本質に関係のない箇所でアサーションが10個も20個も散らばっている。

3. 保守不能なロジック: テストコードの中に if 文や複雑な for ループが平然と混じり、まるでパズルを解くように読み解かなければ、何を確認しているのか判別不能。

サキ： 「ひま、これじゃ逆にレビューに時間がかかるよ！✨ 書くのは一瞬でも、メンテナンスするのは一生なんだ。規律のないAIに書かせたコードは、ただの『負債量産機』だよ。これなら、最初から人間が丁寧に書いたほうが100倍マシだよ。✨」

ヒマリは絶句した。爆速だと思っていた開発効率が、実は「将来の自分たちへのツケ」を積み上げていただけだったことに気づいたのだ。

♨️ AIを「躾ける」プロンプトの規律 ── 鎖で縛る職人の魂

ルル： 「（指でビシッと眼鏡のブリッジを直し、冷徹な響きで断言する）……当然の結果です。ヒマリさん、AIに『自由』など与えてはいけませんッ！😤」

突然のルルの言葉に、ヒマリは背筋を正す。

ヒマリ： 「自由を……与えない？」

ルル： 「そうです。AIを『万能の天才』として扱うから裏切られるのです。AIは、こちらが厳格に管理すべき『規律を知らない職人』に過ぎません。私たちがこれまで血肉にしてきた『テストの作法』を、プロンプトという名の鋼の鎖で、一字一句違わぬよう縛り付けるのですッ！！😤」

ルルはホワイトボードを叩き、AIを「躾ける」ための禁忌を書き殴った。

① AAAの物理的な強制

「テストコードは、必ず空行で区切られた Arrange / Act / Assert の三段構成にせよ。それ以外の構造は認めない」

② 単一責任の絶対化

「Act（実行）は必ず一行にせよ。アサーションは最後の一塊に集約せよ。中間に検証を挟むことは万死に値する」

③ ロジックの完全禁止

「テストコード内に if、for、while などの制御構文を書くことは死罪とする。常に一直線の実行ルートを保て」

ルル： 「これらの規律を、プロンプトの冒頭に叩き込むのです。AIが『賢く』振る舞おうとするのを禁じ、私たちの『型』に従うことだけを強いる。そうして初めて、AIは真の戦力となりますッ！！😤」

規律に従ったAIのコードは、人間がパッと見た瞬間に「何をテストしているか」が脳に直接流れ込んでくる。レビューコストは最小化され、AIのスピードがそのままチームの推進力へと変わる。

♨️ 人間は「何を保証するか」に集中する

ルルの「教育」を受け、ヒマリは自分専用の『テストコード生成プロンプト』を磨き上げた。

マリ： 「いいわね、ヒマリちゃん。コーディングという『作業』をAIに任せることで、私たち人間はもっと大事なことに集中できるようになったわ。☕」

ヒマリ： 「もっと大事なこと……？」

マリ： 「そう。『何が正しい結果（期待値）か』を定義する設計者の役割よ。コードを書く手はAIに貸して、私たちは『何を保証すべきか』という仕様の深淵に潜るの。☕」

たとえPythonのような自由度の高い言語であっても、プロンプトに「規律」という名の骨組みを通せば、出来上がるコードは鉄のように硬く、透明な盾となる。

ユイ： 「あぅ……っ。……私たちが『型』をちゃんと守ることで……初めて、AIが本当の相棒になってくれるんだねぇ……っ。……AIは、私たちの『規律』を鏡のように映し出す……魔法の鏡なんだねぇ……っ。」

ユイの詩的な気づきに、ヒマリは晴れやかな表情で頷いた。 かつての「暴走特急」は、今やヒマリの手綱さばきによって、正確無比な「品質の盾」を鍛え上げる最強の工房へと変わっていた。

ヒマリ： 「プロンプトはただの命令じゃなく、私たちの『エンジニアとしての誇り』の共有なんですね。……。AIと一緒に、世界で一番読みやすく、一番頼りになる盾を作ってみせます！」

琥珀色の湯気を上げる東根温泉。その湯船が、身体を支える適切な深さを持っているように。 規律という「型」があるからこそ、AIという広大な海の中で、エンジニアは溺れることなく泳ぎ続けることができるのだ。

ヒマリの打鍵音は、もはや迷いのない、AIとの美しい二重奏（デュエット）となって開発室に響き渡っていた。

📜 ボスの秘蔵：設計の美学と現場のリアル

ついに、AIの登場です。 これまでの「設計」の話も、「テストコード」の作法の話も、すべてはAIに最高のテストコードを書いてもらうための、長く、そして不可欠な「序章」であったと言っても過言ではありません。

AIによるテストコードの自動生成は、決して悪ではありません。むしろ、これからの開発における必須スキルです。しかし、何も考えずに「このメソッドのテストコードを書いて」とだけ指示を出せば、どうなるでしょうか。

AIは「とりあえず失敗しないコード」を量産し始めます。メソッドを叩き、エラーが出なければ合格とする……。そんな、アサーション（検証）の魂が抜けた「意味のないコード」が積み上がっていくのです。

それでは、プロダクトコードの品質を担保することはできません。内部のロジックをどれだけ修正しても、テストは沈黙したまま。バグは見逃され、「テストがあるから安心」という偽りの自信だけがチームを蝕んでいきます。

そこで必要になるのが、私たちが積み上げてきた**「規律」**です。

私が構築した「テストコード実装ルール」や、これまでお話ししてきた「設計のルール」を、あらかじめAIにプロンプトとして読み込ませる。

# テストコード実装ルール

本ドキュメントは、システムの品質を担保し、デグレードを未然に防ぐためのテスト実装基準である。
テストコードは単なる検証作業ではなく、ビジネスロジックの「振る舞い」を証明する実行可能な仕様書として記述すること。

## 1. テストの範囲と役割分担

効率的かつ意味のあるテストを実現するため、レイヤーごとにテストの重点を分ける。

* **Unitテスト（単体テスト）**:
* **主戦場：ビジネスロジック層（Service / Module / Util）**
* すべての条件分岐、例外系、境界値を網羅し、ビジネスルールの正しさを完全に証明する。
* 外部依存（DB、外部API等）はすべてモック化し、ロジックのみを純粋に検証する。

* **Integrationテスト（結合テスト）**:
* **主戦場：インターフェース層 / データ層**
* ビジネスロジックの正しさはUnitテストで保証されていることを前提とし、ここでは「各層が正しく接続されているか」および「フレームワーク（Routing, SQL, DI設定等）が正しく機能するか」を検証する。
* 正常系を中心に、エンドツーエンドでの疎通を確認する。

* **カバレッジ目標**:
* **目標値: 80%**。数値を追うために無意味なテスト（単純なゲッター・セッター等）を書くことは避け、重要なビジネスロジックの網羅に注力する。

## 2. テストコードの設計

### 2.1 配置と命名

* **配置**: テスト対象のファイルと同じディレクトリ（階層）に作成する。
* **ファイル名**: 元のファイル名に `_test` を付与する（例: `user_service_test.py`）。
* **関数名**: 「仕様書」として機能するよう、以下の形式で内容を明確にする。
* `test_正常系_【テストしたい振る舞いと期待する結果】()`
* `test_異常系_【発生すべき事象や例外】()`
* 例：`test_正常系_重複のないメールアドレスの場合はユーザー登録が成功し受理メールが送信されること()`

### 2.2 テストの構成（4フェーズ構成）

「どのような前提で、何をしたときに、どうなるか」を明確にするため、以下の構成を厳守する。

1. **前処理 (Setup / Arrange)**
* モックの用意、依存オブジェクトの注入、テストデータの作成。
* 他のテストに影響を与えないよう、副作用を遮断したクリーンな環境を用意する。

2. **実行 (Exercise / Act)**
* 対象のクラス・メソッドを実行する。

3. **アサーション (Verify / Assert)**
* **状態の検証**: 戻り値が正しいかを確認する。
* **振る舞いの検証**: 内部メソッド（メール送信、リポジトリ保存等）が、期待される引数で、期待される回数呼び出されたかを検証する。

4. **後処理 (Teardown)**
* 作成した一時データの削除など、環境を元の状態に戻す。

## 3. 「振る舞い」を証明するための指針

* **仕様書としての可読性**: テストコードを一読するだけで、そのビジネスロジックがどのような仕様（ルール）を持っているか理解できるように記述する。
* **モックを用いた依存関係の検証**: ビジネスロジックの実行手順が正しいことを証明するため、注入されたオブジェクトの呼び出し履歴をアサーション対象に含める。
* **異常系の「理由」を検証**: 単にエラーが出るだけでなく、正しい例外クラス、エラーメッセージ、エラーコードが返されているかを厳密に検証する。

## 4. 禁止事項

* **テストコード内のロジック**: テストコードの中に複雑な `if` 文や `for` 文を書かない。テストはシンプルで宣言的であるべき。
* **本番・外部環境への接続**: テスト実行時に、実際の外部APIやDB（本番相当）へ接続することを厳禁とする。
* **不確定要素の放置**: 現在時刻や乱数など、実行のたびに結果が変わる要素は必ず固定値（モック）に差し替える。

（これはアップデートするものですので、これで完璧ではないですｗ）

これらの「作法」をAIに強いることで、生成されるコードは劇的に変わります。AIが吐き出すコードは、人間にとって「レビューしやすく」、かつ「仕様を雄弁に語る」意味のあるテストへと進化するのです。

一般的に、テストコードを実装に含めると、工数はプロダクトコード単体の実装の「3倍」に跳ね上がると言われます。それほどまでにコストのかかる作業ですが、AIを「規律ある職人」として使いこなすことができれば、そのコストを劇的に抑えつつ、実装スピードを飛躍的に高めることができます。

AIに命を吹き込むのは、AI自身の知能ではなく、使い手である私たちが持つ「設計の美学」です。 最高のパートナーと共に、爆速で「品質の盾」を鍛え上げる。その準備は、もう整っています。

（つづく）

#エンジニア #プログラミング #テストコード #生成AI #ChatGPT #プロンプトエンジニアリング #設計 #AAA #ユニットテスト #ソフトウェア開発 #品質保証 #QA #リファクタリング #クリーンコード #DX #東根温泉秘密結社 #エンジニアの日常 #技術的負債