はじめに

Claude Code や ChatGPT などのAIを活用することで、開発の進め方は大きく変わってきました。

これまで時間のかかっていた実装や修正、調査、設計補助などが、AIの支援によってかなり速く進められるようになっています。

私自身もAIを活用しながらプロダクト開発を進めていますが、実装速度や生産性は明らかに向上しました。

一人でもかなりのスピードで機能追加や改善を進められる感覚があります。

ただ、その一方で強く感じるのが、開発速度が上がるほど、品質の担保が難しくなるということです。

AIは速くコードを書いてくれますが、そのコードを本当に理解できているか、影響範囲を把握できているか、安心してリリースできる状態かというと、必ずしもそうではありません。

気づかないうちに理解が浅いまま実装が積み上がり、あとから不具合や想定外の影響として表に出てくることがあります。

AI駆動開発では、単にコードを書く速度が上がるだけでは不十分です。
理解できる状態を保ちながら、品質を落とさずに開発を続けられることが重要だと感じています。

特にその中でも大きなテーマになるのが、理解負債と品質です。

この記事では、AI駆動開発において起きやすい理解負債の問題を整理しながら、品質を守るためにどのようにテストを設計すべきか、実務目線でまとめます。

AI駆動開発で起きやすい問題は「実装不足」ではなく「理解負債」

AI駆動開発では、「実装が遅い」という問題はかなり解消されます。
仕様を伝えれば、AIがコードを書き、修正案も出し、リファクタリングも支援してくれます。

ただ、ここで別の問題が生まれます。
それは、実装したものを自分が十分に理解しきれないまま先に進めてしまうことです。

一つひとつは動いて見えても、全体として見ると、「どの条件で壊れるか」「何がどこに依存しているか」が見えづらくなっていきます。

これが積み重なると、コードは動いていても、プロダクト全体への理解は薄くなっていきます。

つまり、AI駆動開発では、技術的負債だけでなく、理解負債が非常にたまりやすいです。

そして理解負債がたまると、次のようなことが起きやすくなります。

• リリース前に毎回不安になる
• 人手で全部確認したくなる
• 変更時の影響範囲が読めない
• 同じ箇所を何度も壊す
• バグ修正が場当たり的になる
• 品質の再現性がなくなる

AI駆動開発におけるテストの目的は、単にバグを見つけることだけではありません。

理解負債を抑え、品質を維持できる開発構造を作ることが本質だと思っています。

品質を守るには、E2Eを増やすより「構造」を変える

品質の課題が出ると、まず「E2Eテストを増やそう」と考えがちです（私はそうでした）。

もちろんE2Eテストは重要です。実際の操作に近い形で確認できるため、安心感があります。

ただし、E2Eだけで品質を守ろうとすると、別の問題が出ます。

• 実行に時間がかかる
• テストが壊れやすい
• メンテナンスコストが高い
• 原因の切り分けが難しい
• 結果として運用されなくなる

AI駆動開発では、コード変更の量と頻度が増えます。

そのため、品質を守るには、E2Eをひたすら増やすのではなく、どの層で何を担保するかを分けることが重要です。

おすすめは、以下の3層で考えることです。

① ロジックの自動テスト
② 画面や機能単位の統合テスト
③ 主要導線だけのE2Eテスト

この構造にしておくと、理解負債を減らしやすくなります。
なぜなら、「どの品質をどのテストで守っているか」が明確になるからです。

① ロジックを分離してテストすることで理解負債を減らす

理解負債が大きくなる原因の一つは、重要な判断ロジックが画面の中に埋もれてしまうことです。

たとえば、予約可否の判定や売上計算、権限制御などがコンポーネントの中に散らばっていると、挙動を理解するのもテストするのも難しくなります。

そこで重要になるのが、業務ロジックを分離することです。

たとえば、以下のようなロジックです。

• 予約可能時間の算出
• 営業時間外判定
• 休業日判定
• 重複予約判定
• 法人枠と個人枠の分離
• 売上計算
• 必須項目チェック
• 権限による操作制御

これらを純粋関数やサービス層として切り出しておけば、ロジックそのものを理解しやすくなります。

そして、そのままユニットテストを書けます。

このようなテストは単にバグを防ぐだけではありません。

「この機能はどういう条件で成立するのか」をコードとして明文化する役割があります。

つまり、自動テストは品質担保のためだけでなく、理解負債を減らすためのドキュメントとしても機能します。

② 統合テストは「機能の品質」を守る

ロジックのテストだけでは、実際の画面操作や保存処理の流れまでは見えません。
そこで有効なのが統合テストです。

統合テストでは、以下のような一連の流れを確認できます。

• 入力
• バリデーション
• API呼び出し
• 保存成功時の表示
• 保存失敗時のエラー表示

たとえば、施術録の保存画面なら、

• 必須項目が空なら保存できない
• 正しい入力なら保存APIが呼ばれる
• 保存成功後にメッセージが出る
• 保存失敗時にエラー表示される

といった観点をまとめて確認できます。

この層は、ユニットテストより実際の動作に近く、E2Eより軽いです。
そのため、AI駆動開発において非常にバランスが良いです。

品質を守るうえでも有効ですし、「この画面は何を保証すべきか」が整理されるので、理解負債の抑制にもつながります。

③ E2Eは「品質の最後の砦」として最小限に絞る

E2Eテストは、最も安心感がある反面、最も重いです。

そのため、AI駆動開発では、E2Eに過剰な期待をかけない方がよいです。

E2Eは、売上や信用に直結する主要導線だけに絞るべきです。

ここで重要なのは、E2Eを「すべてを網羅するもの」として使わないことです。

役割は、クリティカルパスの品質確認です。

E2Eまで含めて全部を人がメンテナンスしようとすると、それ自体が新しい負債になります。

したがって、E2Eは少数精鋭でよいと思います。

AIには「実装」ではなく「品質を守る作業」まで依頼する

AI駆動開発では、AIへの依頼内容そのものが品質に大きく影響します。

「この機能を実装して」とだけ依頼すると、AIはコードを書いてくれます。

ただ、それだけだと理解負債も品質リスクも残りやすいです。

そこで、AIには次の作業まで含めて依頼するのが有効です。

• 変更影響範囲の整理
• 想定される不具合パターンの列挙
• 必要なユニットテストの追加
• 必要な統合テストの追加
• E2Eが必要かどうかの判断
• 例外処理の確認
• 権限漏れの確認
• レビュー観点の整理

たとえば、次のように依頼します。

この機能を実装してください。あわせて以下も対応してください。

1. 変更影響範囲を整理する
2. 想定される不具合パターンを列挙する
3. 必要な unit test / integration test を追加する
4. E2Eが必要なら最小ケースを提案する
5. 型安全性、例外処理、権限漏れを確認する
6. レビュー観点をMarkdownで出力する

AIに対してここまで要求すると、実装だけでなく品質を守る観点まで出やすくなります。

結果として、人間側の理解もしやすくなり、理解負債の蓄積を抑えやすくなります。

テストは「品質確認」だけでなく「仕様確認」

ここは個人的にかなり重要だと感じています。

AI駆動開発において、自動テストは単なる確認手段ではありません。

自分たちの理解を再現可能な形で残すものだと思っています。

たとえば、

• この条件なら予約可能
• このケースでは保存失敗にする
• このユーザー権限では表示しない
• この法人枠では個人予約を入れない

といった判断は、頭の中だけに置いておくと、時間が経つほど忘れます。
AIが実装したコードであればなおさらです。

だからこそ、テストとして明文化しておくことが重要です。
テストがあることで、「この機能の品質は何によって守られているのか」が見えるようになります。

これはそのまま、理解負債の削減につながります。

リリース前チェックリストを固定化する

AI駆動開発では、変更量が増えるため、手動確認の観点が毎回ぶれやすいです。

ここでも品質を安定させるには、チェック項目の固定化が有効です。

たとえば、リリース前に毎回確認する項目をテンプレート化します。

• 新規登録ができるか
• 編集内容が保存できるか
• 保存後に一覧へ反映されるか
• スマホ表示が崩れていないか
• 権限違いで見えてはいけない情報が見えないか
• エラー時に画面が固まらないか
• 主要ページで console error が出ていないか

こうしたチェックリストがあると、品質確認の再現性が上がります。

同時に、「毎回どこを見るべきか」が明確になるので、理解負債による見落としも減ります。

CIは品質ゲートであり、理解負債の暴走を防ぐ仕組み

AI駆動開発では、コード生成量が増えるため、人間のレビュー前に落とせるものは機械で落とすべきです。

最低限、以下はCIで自動化したいところです。

• lint
• typecheck
• build
• unit test
• integration test
• 主要E2E
• プレビュー環境デプロイ

ここが整っていると、品質を一定ラインで維持しやすくなります。
また、「どこまでが機械で保証され、どこからが人の確認か」という境界も明確になります。

これは品質を守るだけでなく、開発者の認知負荷を減らす意味でも重要です。

理解負債が大きい状態では、「何を信用してよいか」が分からなくなります。

CIは、その不安を減らすための基盤になります。

本番監視まで含めて品質と考える

品質というと、開発中のテストだけに意識が向きがちです。
しかし、実際の運用では、本番で異常が起きたときにすぐ気づけることも品質の一部です。

たとえば、以下のような監視です。

• フロントエンド例外監視
• APIエラー監視
• 保存失敗の通知
• 予約作成失敗の通知
• 重要操作の監査ログ
• DB更新失敗の収集

テストを整えても、不具合はゼロにはなりません。

だからこそ、「起きないようにする」だけでなく、「起きたらすぐ気づける」状態を作ることが重要です。

品質とは、単にバグが少ないことではなく、運営としてコントロール可能な状態であることだと思います。

まとめ

AI駆動開発では、実装速度が大きく上がります。
その反面、人間の理解が追いつかないままコードベースが膨らみ、理解負債がたまりやすくなります。

そして、理解負債が積み上がると、手動テストが増え、影響範囲が読めなくなり、品質が不安定になります。

この問題に対して重要なのは、単にテストを増やすことではありません。
理解負債を抑えながら品質を守れる構造を作ることです。

そのためには、次のような考え方が有効です。

• ロジックを分離してテストしやすくする
• 統合テストで機能単位の品質を守る
• E2Eは主要導線に絞る
• AIに品質観点まで含めて依頼する
• チェックリストで人の確認を再現可能にする
• CIで品質ゲートを作る
• 本番監視まで含めて品質と考える

AI駆動開発では、速く作ること自体はそれほど難しくありません。
難しいのは、理解できる状態を保ちながら、品質を落とさずに開発を続けることです。

今後AI活用がさらに進むほど、この「理解負債」と「品質」の設計はますます重要になるはずです。