Claude Code や Cursor、Devin といった AI コーディングエージェントの導入が進むなか、「品質をどう担保するか」が最大の課題になっている。栗田氏（@hikarine3）が公開した実践ガイドから、要点を紹介する。

Sonar の調査によれば、開発者の 96% が AI 生成コードを完全には信頼していないにもかかわらず、実際に検証しているのは 48% に過ぎない。この「検証ギャップ」が AI 開発における最大のリスクだ。

1. 設定ファイルにルールを書く

CLAUDE.md や .cursorrules 等の設定ファイルに、最低限 3 つのルールを書くだけで事故を大幅に減らせる。

ルール防げる事故
テスト結果を「○件中○件が正常」形式で報告0 件検出の見落とし
影響範囲を確認1 ファイル修正で他が壊れる
ファイル削除・本番デプロイ・DB 操作は承認必須取り返しのつかないミス

設定ファイルは 50 行以内 を推奨。IFScale の研究では、指示が長すぎると AI が先頭と末尾だけに従う傾向がある。詳細は別ファイルへの参照（ポインタ設計）で対応する。

2. リスクレベルで使い分ける

すべてのプロジェクトに同じ品質基準を適用する必要はない。

レベル対象テスト深度
ラフ静的サイト、ブログ目視確認
標準Web アプリ（ユーザーデータあり）回帰テスト
厳密金融・決済・認証・個人情報境界値・異常系テスト

3. AI にテスト設計もさせる

従来のように 12 項目のチェックリストを人間が作るのではなく、「この変更の回帰テストをして。検出件数も報告して」と指示するだけで、AI がテストケースの設計・実行・報告まで行える。

4. AI のテストが「嘘」になる 10 パターン

AI エージェントが出す「全件正常です」を鵜呑みにしてはいけない。代表的な落とし穴:

  • 0 件チェック: grep パターンの誤字で 0 件ヒット → 「問題なし」と報告
  • HTTP 200 = 正常ではない: ステータス 200 でもコンテンツが空、CSS が効いていない場合がある（本番 265KB のページがテスト環境で 19KB）
  • 見た目の問題の放置: 「AI に見た目がわからない」のではなく「判定ルールがない」。WCAG コントラスト比 4.5:1 以上など数値基準を与える
  • 1 ファイル直して終わり: 依存先の JS ファイルを無視してボタンが動作停止
  • 幻覚のスパイラル: 同じエラーを 3 回修正できなければ作業停止させる

対策の原則は「数値で検証可能なものは AI に判定させ、根拠なき『正常です』を禁止する」こと。

5. 一度起きたバグを二度と起こさない

地雷記録ファイル

過去のバグを設定ファイルに記録し、同じ過ちを繰り返さない:

## 地雷記録
- 【2026-03-05】0件検出をPASSにした → 検出件数が0件の場合はFAILにすること
- 【2026-03-06】テスト未実施でデプロイ → テスト→報告→承認→デプロイの順序厳守

3 ストライクルール

回数対策
1 回目設定ファイルにルール追記
2 回目ルール強化・具体化
3 回目仕組みで防ぐ（Hooks やバリデーションスクリプト）

Hooks による自動ブロック

Claude Code の Hooks 機能で、破壊的コマンドの実行や秘密情報の漏洩を自動的にブロックできる:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "command": "npx eslint $FILEPATH 2>&1 || true"
      }
    ]
  }
}

6. 専門エージェントの分業

Google DORA Report 2025 によると、AI 導入が 90% 増加した一方でバグ率が 9% 増加、コードレビュー時間が 91% 増加した。1 体の AI にすべてを任せるのではなく、役割を分業させることで品質が劇的に向上する。

OpenObserve の「専門エージェント評議会」

8 体のエージェントが 6 フェーズのパイプラインで分業する実践例:

フェーズエージェント役割
分析Analystソースコード解析 → 機能設計書
計画Architectテスト戦略策定
生成Engineerテストコード生成
監査Sentinelコード品質監査
修復Healerテスト実行 → 修正
文書化Scribeテスト結果記録

導入 6 ヶ月で、機能分析時間が 6〜10 倍高速化、Flaky テストが 85% 削減された。

個人・スモールチーム向け

8 体も用意できなくても、最低限「開発セッション」と「レビューセッション」を分けるだけで効果がある:

  1. Phase 0: 別セッションでプロジェクトを分析し設計書を作成
  2. Phase 1: 設計書を踏まえて開発
  3. Phase 2: 別セッションで diff を設計書と照合してレビュー
  4. Phase 3: Puppeteer 等で本番と数値比較

7. セキュリティ

Veracode 2025 の調査では AI 生成コードの 45% にセキュリティ欠陥があり、Aikido Security 2026 では AI 生成コードが 5 件に 1 件の侵害原因になっている。

主なリスクと対策:

リスク対策
SQL インジェクションパラメータバインディングのルール化
秘密情報のハードコードHooks で検知・ブロック
不適切な権限設定最小権限の原則をルール化
非推奨 API の使用依存ライブラリの自動チェック

まとめ

記事が提示する 10 の原則のうち、最も重要なのは以下の 3 つだ:

  1. 設定ファイルに 3 つのルールを書く — 件数報告、影響範囲調査、破壊的操作の承認
  2. 根拠なき「正常です」を禁止する — 数値で検証可能なものは AI に判定させる
  3. 3 回同じバグが出たら仕組みで防ぐ — Hooks やバリデーションスクリプトで自動化

「モデルより『ハーネス』が重要」という Harness Engineering の知見がここでも活きている。同じモデルでも環境設計を変えるだけで 22 ポイントのスコア差が生まれるが、モデル交換では 1 ポイント程度に過ぎない。

参考