AI駆動開発の原則：「生成+検証」がセットでなければスケールしない

はじめに

AIによるコード生成は開発プロセスの中で当たり前になりつつあります。しかし、「検証」を伴わないままでは開発が高速化しません。本記事では、「生成」と「検証」のセット設計を基本とし、ローカルとCIの棲み分けによるプロセス構築の考え方を提示します。

なぜ「検証なし」のAI生成は破綻するのか

AIによるコード生成の普及とともに、「生成量を増やせば開発速度が上がる」という期待が広がっています。しかし、検証プロセスを伴わない生成のみの投資は中長期で投資対効果を損ないます。

検証を省略した場合、誤りが発見されないまま開発フローに混入します。リリース直前に欠陥が発見されるほど、修正コストは跳ね上がります。これは、従来の開発プロセスでも同じです。

検証なき生成は、技術的負債の高速生産でしかありません。

ここで立ち戻るべき原則は2つです。

• 原則1：欠陥は確率的に必ず混入する： 人間であれAIであれ、コード生成には必ず誤りが混じります。これは確率論の問題です。「AIによる生成精度を上げる」は当然のベースラインとして行いますが、それをもって欠陥がゼロになることは期待できません。
• 原則2：修正コストは発見の遅延と共に増加する： これは工学の基本原則です。早期に発見するほど修正コストが低くなり、後方に流れるほど指数的に拡大します。

この2つの原則から、投資すべき領域は明確になります。

(1) 「生成」と「検証」をセットとしてプロセスを設計する
(2) 「生成」と「検証」の時間的な距離を最小化する

なぜ「時間的な距離」がAIにとっても重要なのか

「時間的な距離の最小化」は人間のエンジニアにとっても重要ですが、AIにとっても同様のメリットがあります。

コンテキストやセッションを隔てた状態でAIがバグを解析し修正しようとすると、再現のためにトークンを大量に消費します。本質的には、人間のコンテキストスイッチと同じ現象です。つまり、時間的な距離は「AIにとっても、人間にとっても、プロジェクトにとっても」非効率です。

AIエージェント・プレコミット・CIの三層検証設計

「生成と検証をセットにする」と言葉では簡単に聞こえますが、実装には「何を開発者ローカルで検証し、何をCIで検証するか」の判断基準が必要です。

①AIエージェント内検証

責務の定義

AIエージェント内検証は「この生成物は要求に沿っているか」を確かめます。品質保証の最終責任ではなく、生成品質を底上げする内蔵制御として位置づけます。

検証スコープ

• ハッピーパス（最短の正常ルート）の通過確認
• 通常想定されるエラーケース（null、空配列など）
• 基本的なアサーション（期待値との一致）

停止条件

エッジケースの網羅や完璧なカバレッジは追求しません。動作する状態での人間への引き渡しを優先します。AIエージェントの処理時間を考慮し、目安10分以内で完了する検証に留めます。

原則：動作検証未済のAIエージェントのアウトプットをそのまま使わないこと。人間の認知負荷を減らせていないため、AIエージェント導入の本来の目的を果たしていません。

②プレコミット検証

プレコミットとは

責務の定義

プレコミット検証は「開発者ローカルで通らないと提出できない最低限の静的品質を保証する」役割を持ちます。目的は実施率の担保であり、人間の推奨事項への依存を排除します。

配置すべき検証

短時間・安定・差分対象の3条件を満たすもののみ配置します。

配置してはいけない検証

時間がかかるもの、環境依存で揺れるものはプレコミットに含めません。コミットが詰まりスキップが常態化して強制力が消えるためです。

• 統合テスト（DBアクセス、外部API呼び出し）
• E2Eテスト（Playwrightなど）
• 全体カバレッジ計算（差分のみならOK）
• 重いSAST/DASTスキャン

原則：30秒を超える検証をプレコミットに入れないこと。開発者がスキップする未来が見えます。

CI検証：チーム安全基準の定義と固定

責務の定義

CI検証は「チーム／システム全体として統合された状態で安全を保証する」役割を持ちます。CIは漏れを拾うだけでなく、チームの安全基準を定義して固定する役割が大きいです。失敗は個人環境ではなくプロジェクトとして直すべき信号になります。

配置すべき検証

システム全体のコンテキストが必要、ポリシー統制や監査が必要のいずれかに当てはまるものを配置します。

リグレッションテストとしての価値

CIの本質的価値は「既存機能の保護」です。新規生成コードが既存システムを破壊していないかを、全テストスイート実行で確認します。

原則：CIの失敗を減らすための投資はローカル層に対し行います。CIで発見することを前提にしてはいけません。

プロセスの全体像

 

AIエージェント実装

「AIエージェント内検証」を実装する際の具体的例を示します。重要なのは、AIエージェントが生成と同時にテストも生成し、ハッピーパスの通過確認してから人間に引き渡すまでを自動化することです。

フロントエンド（Vitest + Storybook）の例

このAIエージェントは、設計書の解析からテストコードの生成、さらには自動修正までを全6段階のフェーズで完結させる仕組みを備えています。

 

実現はAgent Skillの仕組みによって行います。成果物は人間向けのテスト計画書から、機械処理用のJSONデータ、視覚的なStorybook、そしてVitestによる検証コードを生成、テストの実施とテスト結果からのセルフヒールまでを連続的に実行します。

特筆すべきは、手順を共通化するSkillとプロジェクト固有のドキュメントを分離することで、高い汎用性と保守性を実現している点です。

まとめ

AI生成における検証プロセスの指針を、３つにわけて説明しました。

• ① エージェント内検証の構築：生成と検証を同一セッション内で閉じることが、コストを根本的に減らします。ハッピーパスをAIエージェントが通してからエンジニアに提出するまでを自動化します。
• ② プレコミットによる実施率担保：人間の推奨事項に依存せず、Gitのコミット操作という避けられないタイミングで強制実行します。30秒以内で完了する検証のみを配置し、スキップされない設計を維持します。
• ③ CI失敗時のフィードバック構造化：閉ループでも漏れた場合に、最小コストで修正に戻れるようにします。エラー情報＋関連ファイル＋推定材料をパッケージとして渡します。

AIによるコード生成のポテンシャルを現実にするためには、生成量の拡張と同等以上に検証プロセスに投資することが不可欠です。