開発方針を相談する

AI でコード生成するなら、先にテストとレビューを整備すべき理由

生成速度が上がるほど、品質ゲートがない開発は危険になる。

この記事の結論

「AI に書かせたら、なぜか動かない」「動くけど、レビューでバグだらけ」

AI コーディングを始めたチームから、よく聞く声です。多くの場合、原因は AI ではなく、そのコードベースに品質ゲートが整っていない ことにあります。テスト・lint・型チェックがないリポジトリでは、AI が書いたコードが「動いているように見えるが、壊れている」状態のまま CI を通ってマージされます。

この記事では、AI でコード生成を本格化する前に整えるべき品質ゲートを、最低限のセットと、具体的な CI 設定、AI への指示例まで含めて整理します。

AI は実装速度を上げるが、品質保証は別問題

OpenAI のドキュメントによれば、Codex はテスト出力やターミナルログを通じて作業の検証可能性を提供する設計とされています (Introducing Codex / OpenAI)。これは 「AI が書いたコードを、テストで検証する」前提 が組み込まれているということです。

逆に言えば、テストがないコードベースでは、AI の生産性は活かしきれません。「動いていそうに見える」ところまでは速く到達できますが、本当に動いているかは確認できない。速く間違える だけになります。

テストがないコードベースで起きること

実際にテスト不在のコードベースで AI 開発を進めると、以下のような状況が発生します。

事業上の被害: 改修のたびに別のバグが出るので、改善速度が落ちます。開発者の信頼も落ち、「AI を使うとむしろ遅い」という結論になります。

実際、min's に持ち込まれる立て直し案件の多くは、「テストがゼロまたはほぼゼロ」 のコードベースです。最初の 1〜2 週間は、テストを書く作業から始まることが大半です。

最低限整える 6 つの品質ゲート

新規プロジェクトで AI 開発を本格化するなら、以下の 6 つを最初に整えます。既存プロジェクトでも、これらが揃っていない場合は補強を優先します。

1. 型チェック

CI で必ず通る状態にします。型エラーがあれば PR がマージできない設定。

# 例: GitHub Actions
- name: Type check
  run: pnpm typecheck   # TypeScript の場合は tsc --noEmit

TypeScript なら strict: true、Python なら mypy --strict を目指します。一気に上げると既存コードでエラーが噴出するので、ディレクトリ単位や段階的に厳しくしていくのが現実的です。

2. 単体テスト

主要なドメインロジック (集計、状態遷移、認証判定) を、関数単位でテスト。AI に書かせる対象としても最適です。

Vitest や Jest なら、ファイル横並びにテストを置く構成が AI と相性が良いです。

lib/domain/
  booking.ts
  booking.test.ts     ← 同じ場所にテストを置く
  pricing.ts
  pricing.test.ts

カバレッジは最初から 100% を目指す必要はありません。主要ドメインの 70% を最低ライン に置くのが現実的です。

3. 重要フロー E2E

ログイン、決済、予約、申込のような事業上重要なフローは、Playwright や Cypress で E2E テストを書きます。リリース判断の根拠になります。

// 例: Playwright での E2E
test('予約フロー全体', async ({ page }) => {
  await page.goto('/booking')
  await page.fill('[name=date]', '2026-12-25')
  await page.click('text=予約する')
  await expect(page).toHaveURL(/\/confirmation/)
})

E2E は遅いので、全機能ではなく重要フローだけ に絞ります。「これが壊れたら売上が止まる」ものを 5〜10 本書く感覚です。

4. lint と formatter

ESLint / Biome / Prettier / Black などで、スタイルの揺れを自動で潰します。これも CI で必須化。

- name: Lint
  run: pnpm lint
- name: Format check
  run: pnpm format:check

formatter は 「議論しない」 のがコツです。Prettier や Biome のデフォルトに従って、PR で「ここのスペースが…」のような議論を発生させない。AI が書いたコードも自動でフォーマットされるので、レビューがコード本質に集中できます。

5. PR レビュー

最低 1 人、認証・課金・データモデルの変更は 2 人レビュー。AI が書いたかどうかに関わらず、人間が判断する工程を残します。

PR テンプレートに以下のチェックボックスを入れると、レビューが効率化します。

## レビュー観点
- [ ] 要件と一致している
- [ ] 影響範囲が想定通り
- [ ] テストが追加されている
- [ ] セキュリティ観点が考慮されている
- [ ] エラーハンドリングが妥当
- [ ] ログ・通知が適切

6. 手動検証観点

リリース前に確認する「動作確認チェックリスト」を、Notion などに残します。E2E でカバーできない UX 部分の最終確認用。

例:

これは「AI には判断できない」最後の関門になります。

AI にテストを書かせる方法

AI に「実装と一緒にテストを書かせる」ことで、品質ゲートを通る形で開発を進められます。

具体的な指示パターン

AI が書いたテストの落とし穴

AI が書いたテストは、「動くことだけ確認している」 ケースが多くあります。たとえば、

// AI が最初に書きがちなテスト (薄い)
test('add は数値を返す', () => {
  expect(typeof add(1, 2)).toBe('number')  // 動くことしか確認していない
})

// 望ましいテスト (具体)
test('add は引数の和を返す', () => {
  expect(add(1, 2)).toBe(3)
  expect(add(-1, 1)).toBe(0)
  expect(add(0, 0)).toBe(0)
})

テストケースが「振る舞いを保護しているか」「異常系を網羅しているか」は、人間がレビュー します。AI が書いたテストをそのまま信頼しない、というのが基本姿勢です。

レビューで見るべき観点

AI が書いた PR をレビューするときに、確認するポイントを整理します。

観点確認内容見落としたときに起きること
要件適合実装が要件と一致しているか別物がマージされる
影響範囲既存機能への影響が想定通りか回帰バグ
保守性命名、責務分割、コメントが妥当か半年後に読めない
セキュリティ認証・権限・入力検証が抜けていないか脆弱性
テスト異常系を含めたテストが追加されているかエッジケースで壊れる
運用エラーハンドリング、ログ出力が適切か障害時に追えない

OpenAI の Codex ベストプラクティスでも、失敗が起きたら振り返って AGENTS.md に反映する 運用が推奨されています (Codex Best Practices / OpenAI Developers)。レビューで指摘した内容を、その場で AI のドキュメントに追記しておくと、次から同じ指摘が減っていきます。

AI にレビュー補助をさせる

レビューする側も AI を活用できます。

これらを AI に依頼すると、人間は 「事業判断」「例外許容」「リスク受容」「UX 判断」 という、AI では決めきれない部分に時間を集中できます。

Anthropic のセキュリティ解説でも、AI を使った脆弱性管理のボトルネックは「発見」ではなく「検証・トリアージ・修正」に移っていると整理されています (Using LLMs to Secure Source Code / Anthropic)。コードレビューでも同じ構造で、AI が候補を出し、人間が判断する 分担が現実的です。

ここまでで「自社のコードベースに品質ゲートを整えたい」と感じたら、現状診断から始めるのが現実的です。

品質ゲートの整備を相談する →

既存プロジェクトに後から入れる順序

既存プロジェクトで品質ゲートがほぼゼロの場合、いきなり全部入れようとすると挫折します。以下の順で 1〜2 ヶ月かけて入れていきます。

Week 1〜2: 型チェック

Week 2〜3: lint + formatter

Week 3〜5: 単体テスト

Week 5〜6: CI で必須化

Week 6〜8: E2E

この順序だと、いきなり全部を強制せず、段階的にチームが慣れていく ことができます。

min's での実際の運用

min's では、AI を本格活用する案件で、以下を最初に整えます。

これを最初の 1〜2 週間で揃えてから、AI による実装フェーズに入ります。一見遠回りに見えますが、結果的に総工数は減ります。

既存プロジェクトの場合は、上記の段階的導入を 1〜2 ヶ月かけて並走支援することが多くあります。

品質ゲートを入れない場合のコスト

「テストを書く時間がないから、後でやる」と判断したプロジェクトは、ほぼ確実に 後で書けない 状態になります。理由は以下です。

最終的には、改修コスト × 不具合対応コストの合計が、初期のテスト整備コストの 3〜5 倍 に膨らみがちです。これは現場での体感値ですが、数字を出さなくても「後で書こうと思ってたが、書けないまま運用 1 年経った」という案件は多くあります。

AI コードレビュー・品質ゲート整備を依頼したい方へ

min's では、AI 生成コードのレビュー、品質ゲートの整備、CI / テスト戦略の設計を支援しています。

以下のような状態であれば、ご相談ください。

次に読む記事

参考

動くデモで終わらせず
本番まで持っていく開発を

AI で作りかけたもの、止まりかけている開発、新しいプロダクトの構想。 まずは現状を整理するところから、ご相談ください。

開発方針を相談する概算見積もりを依頼する