AI駆動開発でコードを読まないのは危険？品質を担保する「仕組み」とハーネスの作り方
最近、Xなどの投稿を見ていると、「生成AIでバイブコーディングをしたり、AIエージェントで自分で開発したりすれば、コードを知らなくてもよい」というような風潮が増えているように見受けられます。
確かにAIを使うことで、かなり高品質なコードが生成されます。実際に動くものが短時間でできあがるため、それで完成だと思ってしまう気持ちもよく分かります。
しかし、本当にそのコードは安全なのでしょうか。サービスを継続して運用することは可能なのでしょうか。
とくに、顧客情報や社内データを扱う業務システムでは、認証・権限・データベース・外部連携の設計を誤ると、画面上は正常に見えても情報漏えいやデータ破損につながります。AIを使って開発する人が増える今こそ、「コードを読むか、読まないか」ではなく、どうすればコードを盲信せずに品質を確かめられるかを考える必要があります。
この記事では、AI駆動開発で品質を担保するための仕組み・・ここでは「ハーネス」と呼びます・・を整理します。
コードを読まないことが危険なのではありません
まず結論を言えば、すべてのコードを人間が一行ずつ読むことが、唯一の品質保証ではありません。機能数が増え、変更が頻繁に入るシステムでは、目視レビューだけに頼る方法はすぐに限界を迎えます。
危険なのは、AIが作ったコードを理解も検証もせず、そのまま本番環境へ入れることです。
安全なAI駆動開発では、人の役割をなくすのではなく変えます。人間が担うべきは、目的、扱うデータ、権限、業務ルール、完成条件、例外時の判断です。AIには、定められた範囲の実装、テスト作成、差分確認、調査を高速に担わせます。そして、機械的な検査と独立したレビューで、AI自身の誤りを見つけます。
つまり目指すのは「コードを読まなくてよい」状態ではありません。全部を信用しなくても、危険な変更が混ざりにくく、混ざっても検知・復旧できる状態です。
品質は、実装の後ではなく前から決まります
AIに実装を頼む前に、少なくとも次の四つを決めておく必要があります。
- 誰が何のデータを閲覧・更新・削除できるのか
- 正常時だけでなく、失敗時にどう振る舞うのか
- どの状態になれば「完成」と判定するのか
- どの変更は人間の承認なしに公開してはいけないのか
ここが曖昧なままでは、AIはもっともらしい画面や処理を作れても、正しい業務システムは作れません。例えば「顧客一覧を表示する」という指示だけでは、他社のデータが混ざらないこと、権限のない担当者は見られないこと、CSV出力に個人情報を含めてよいか、といった重要な条件が抜け落ちます。
そのため、受入条件を先に書くATDD（Acceptance Test Driven Development）の考え方が有効です。「誰が」「何をしたとき」「どうなるべきか」をテスト可能な言葉で定義し、実装より先に確認方法を用意します。AIに任せる範囲が広がるほど、曖昧な依頼ではなく、検証可能な条件が重要になります。
ハーネスを構成する8つの層
1. 役割を分けます
一つのAIに、要件解釈、実装、テスト、自己レビューまで任せると、自分で作った前提を自分で肯定しがちです。企画・設計、実装、テスト、レビューの役割を分け、少なくとも別の視点で確認します。
当社でも、Planner、Implementer、Tester、Reviewerを分ける形で進めています。実装前に受入条件を整理し、実装後は別の観点からテストとレビューを行うことで、「動くものを作った本人が、動くと言っているだけ」の状態を避けます。
2. アーキテクチャで変更範囲を狭めます
ヘキサゴナル・アーキテクチャやモジュラーモノリスは、流行の名称を採用することが目的ではありません。画面、業務ルール、データベース、外部APIの責務を分け、依存関係を一方向に保つための考え方です。
業務ルールが画面やデータベースの詳細に直接結びついていなければ、UIの変更が売上計算を壊す、といった事故を減らせます。外部サービスとの接続を決められた入口に集約すれば、AIが任意の場所からAPIを呼び出すことも防ぎやすくなります。AIに自由度を与えすぎないことは、能力を制限するためではなく、失敗の影響範囲を小さくするためです。
3. lint・型検査・ビルドを最初の関門にします
フォーマット、lint、型検査、ビルドは地味ですが重要です。未使用の値、危険な記述、型の食い違い、壊れたimportなどを、レビュー担当者が読む前に機械で落とせます。
これらは「品質を上げる魔法」ではありませんが、初歩的な不整合を自動で排除し、人間の注意力を本当に難しい判断へ回すための基礎になります。PRで必須化し、失敗したらマージできない状態にするところまでが重要です。
4. テストを一種類で済ませません
テストには役割があります。単体テストは計算や状態遷移などの業務ルールを守ります。結合テストは認証、DB、外部APIとの接続を確認します。E2Eテストは利用者の一連の操作を確認します。回帰テストは、過去に起きた不具合を二度起こさないための資産になります。
金額計算、日付処理、権限判定のように条件が多い処理には、入力パターンを広く試すプロパティテストも有効です。重要な業務ロジックでは、テストの一部を意図的に壊して、本当に失敗を検知できるかを見るミューテーションテストも検討できます。
ただし、すべてを最大限に行う必要はありません。変更内容とリスクに応じて、必須のテストセットを決めることが現実的です。
5. UIを見た目だけで終わらせません
画面移行では、見た目が似ていても、ボタンを押した後の遷移、入力エラー、権限による表示差、保存後の状態が異なることがあります。当社では、Playwrightを使い、画面ごとの操作・期待結果を台帳化したうえで、見た目と機能のParity（同等性）を確認しています。
これは「スクリーンショットが一致したからOK」とするためではありません。どの画面で、誰が、何を操作し、何が起きるべきかを再実行できるようにするための仕組みです。AIが実装した画面であっても、同じ受入条件に対して検証できます。
6. セキュリティをコードの外にも広げます
セキュリティは、SQLインジェクションやXSSだけではありません。認証、認可、セッション、入力値、ファイルアップロード、秘密情報、依存ライブラリ、クラウド設定、監査ログ、バックアップまで含めて考える必要があります。
最低限、次は自動検査または必須レビューの対象にします。
- APIキーやパスワードなどの秘密情報がリポジトリに入っていないか
- 利用ライブラリに既知の脆弱性がないか
- 権限のない利用者や別組織の利用者がデータへアクセスできないか
- 入力値をサーバー側で検証しているか
- 本番設定でデバッグ情報や過度な権限が有効になっていないか
- 重要な参照・更新・削除を追跡できるか
OWASP ASVSは、こうしたWebアプリケーションのセキュリティ要件を体系的に確認する基準になります。脆弱性スキャンだけで十分とは言えず、設計段階の脅威分析、静的解析、実行時テスト、人によるレビューを組み合わせることが重要です。
7. データベースを「裏側」として扱いません
業務システムの重大事故は、DB設計や運用から起きることが多くあります。アプリで入力チェックをしていても、DB側に制約がなければ不正な状態が残ることがあります。
主キー、外部キー、NOT NULL、UNIQUE、CHECK制約、適切なインデックスを設けます。組織ごとにデータを分ける仕組みでは、テナント境界を検索・更新・削除のすべてで強制します。削除方針、監査ログ、データ保持期間、バックアップ、復元手順も、実装と同じくらい設計すべき対象です。
また、本番DBの変更は慎重に扱います。列の追加、データ移行、アプリ切替、旧列の削除を段階的に行う「追加→移行→切替→削除」の手順を標準化すると、AIが生成したmigrationをそのまま本番へ流すリスクを下げられます。
8. CIと運用で「出した後」も守ります
品質ゲートは開発環境だけで完結しません。PRでlint、型検査、テスト、ビルド、秘密情報検査、依存関係確認を自動実行し、基準を満たさない変更をマージできないようにします。高リスクの変更では、人が設計と差分を承認します。
本番では、エラー監視、操作ログ、権限変更ログ、アラート、ロールバック手順、バックアップからの復元訓練が必要になります。万一の不具合を完全にゼロにできなくても、早く発見し、影響を限定し、復旧できれば事業へのダメージは大きく変わります。
人が必ず読むべき変更は残ります
自動化が進んでも、次の変更は「CIが通ったからOK」にしない方がよいでしょう。
- 認証・認可・組織間のデータ分離
- 個人情報、機微情報、金銭に関わる処理
- DBスキーマの破壊的変更とデータ移行
- 外部公開API、Webhook、ファイルアップロード
- クラウド権限、ネットワーク設定、秘密情報の扱い
- 利用規約、法令、業務ルールの解釈を伴う仕様変更
この領域では、コードだけでなく、設計意図、データの流れ、失敗時の振る舞いまで人が確認する必要があります。AIは優秀な実装者・調査者になれますが、最終的なリスク受容の責任まで引き受けてはくれません。
AI駆動開発の本当の価値
AI駆動開発は、速く作るためだけのものではありません。本来は、要件、テスト、レビュー、記録、再発防止をつなぎ、品質確認を繰り返せる形にするためのものです。
人が目的と基準を決めます。AIが高速に実装・検証します。機械的なガードレールが危険な変更を止めます。重要な判断だけは人が引き受けます。こうした役割分担ができて初めて、コードをすべて精読しなくても、品質を高めながら開発速度を上げられます。
「AIに任せるから品質が下がる」のではありません。任せ方と、任せた結果を確かめる仕組みがないときに品質は下がります。これからの開発力は、コードを書く速さだけでなく、AIが書いたコードを安全に届けるためのハーネスを設計できるかで決まっていきます。
