AI が書いたコードを「評価・破壊・修復」する 5 つの実務手法 2026｜現役 PM が現場で使う検証ノウハウ

AI が書いたコードを「動いた」で終わらせる時代は終わった。2026 年以降で価値がつくエンジニアは、AI 出力を「評価・批評・破壊・修復」できる判断力を持っています。本記事では現役 PM の「やむぅ。」が、自社プロダクトの本番運用で実際に使っている 5 つの実務手法を、具体的なパターン付きで公開します。

なぜ AI が書いたコードを「評価・破壊・修復」できる必要があるのですか？

AI 出力は「動く」と「正しい」が同義ではないからです。本番障害・セキュリティ事故・パフォーマンス劣化の多くは、AI が出したコードをレビューせずそのまま採用したことに起因します。

「動いた」と「正しい」の差

「作れた」なレベルだと、3ヶ月後にはシステム全体が本人ですら読めなくなる。「正しい」と評価できる人が、AI のスピードに乗れる時代の主役に立てる。

AI 出力レビューの市場価値

AI 出力を評価できるシニアエンジニアの単価は、評価できないジュニアエンジニアの 1.3〜2 倍に達することが珍しくありません。これは「AI が書ける範囲が拡大した結果、評価する側の希少性が逆説的に上がっている」という構造変化です。

手法 1: 5 段階評価フレームワークを使う

AI 出力を「動く / 安全 / 効率的 / 保守可能 / 拡張可能」の 5 段階で評価する。1 つでも欠ければ採用しない、というルールを設けてやっていくと良いです。

5 段階評価フレームワーク

フレームワークの使い方

PR レビュー時に、各セクションでこの 5 段階を チェックリスト化 します。AI に書かせたコードがどの段階で止まっているかを言語化すれば、修復の方向性が明確になります。

5 段階のうち「1. 動く」だけ満たして残りが NG のコードを「動いたから OK」と承認しちゃうひとをSNSでよく見かけるがこれがAIの最大の罠っす。

手法 2: 「壊して直す」破壊的テスト演習をくりかえす

わざと AI 出力を(意図的に)壊してテストを通す訓練が、エラーメッセージの読解力と修復力を急成長させます。ProFact でもここを大事にしています。

破壊的テスト演習の手順は？

このフレームワークは「動くコード」と「壊れないコード」の差を体感するための演習です。

ステップ 1: 動く AI 出力を準備する

Cursor / Claude Code などで「ログイン機能」のような小さな機能を作らせる。テストが通る状態にしてからがスタート。

ステップ 2: わざと壊す（破壊フェーズ）

5 つの破壊パターンから 1 つ選ぶ:

• パスワードを平文で保存するように戻す（セキュリティ）
• 入力検証を外す（バリデーション）
• 古い バージョンのAPI を使うように書き換える（Deprecated）
• 認証チェックを削除する（認可）

ステップ 3: 壊れた状態でテストを書く

「漏れても平気か？」「N+1 が起きていないか？」を確かめるテストを AI に書かせる。テストが正しく **失敗** することを確認。

ステップ 4: 直す（修復フェーズ）

テストが PASS するように修正する。修正の意図をメモに残しておくとなおよし！

ステップ 5: なぜ動くかを言語化する

修復後、コードのどの行が何を担保しているかを 自分以外に説明できるレベルで言語化する。ここができれば「AI 共生型エンジニア」の核心スキルを身につけたと言えます。

「動かなくなった原因」を即座に切り分けて修復できる人が、実際の実務の障害発生時でも力を発揮できる。

手法 3: ハルシネーション検出パターン 4 種を機械化する

AI 出力に頻出する 4 種のハルシネーションを、エディタ・CI・SAST ツールで機械的に検出するパイプラインを自分なりに構築します。人間の集中力に頼らない仕組み化を作っちゃうのが鍵です。

ハルシネーション 4 種と検出方法

CI に組み込むベースライン

# .github/workflows/quality.yml（抜粋）
jobs:
  hallucination-check:
    runs-on: ubuntu-latest
    steps:
      - run: npm run typecheck     # 1. 存在しない API
      - run: npm run lint          # 2. Deprecated
      - run: npm run sast          # 3. セキュリティ
      - run: npm run test:db       # 4. N+1（クエリログ計測）

4 つすべてを CI で機械検出できる状態にしておけば、AI 出力の品質を人間の集中力に依存しなくて済む。

手法 4: 修復パターン辞書を持つ

AI が書きがちな悪コードに対する「修復パターン」を自分なりに辞書化しておくと、レビューと修復のスピードが 3〜5 倍になります。

頻出する悪コードと修復パターン

修復パターン辞書の運用

• プロジェクトの docs/refactoring-patterns.md を作って蓄積してみよう
• AI への指示プロンプトにも参照させる（「refactoring-patterns.md の指針に従って修正して」）

こういった辞書は後々役に立ちます。同じミスをさせない、同じようなことを繰り返さないなどが可能。

手法 5: ADR（Architecture Decision Record）で判断を残す

「なぜそのコードにしたか」を ADR(アーキテクチャ決定記録) として残すことが、AI 出力の品質を将来にわたって担保します。実際の開発は一人でやることはほぼないです。なので自分以外にもチーム全体で統一感を維持するために必要になります。AI が再生成しても、過去の判断履歴があれば一貫性が保てます。

ADR テンプレート（最低限）

# ADR-001: パスワードハッシュに bcrypt を採用する

## ステータス
Accepted（2026-05-22）

## コンテキスト
ユーザー登録機能のパスワード保存方式を決める必要があった。

## 決定
bcrypt（cost factor: 12）を採用する。

## 理由
- 業界標準で広くレビューされている
- レインボーテーブル攻撃に耐性がある
- Argon2 も候補だったが、対応ライブラリの安定性で bcrypt を採用

## 影響
- 認証速度が約 200ms 増加
- パスワードリセットフローに影響なし

ADR が AI 時代に効く理由

• 再現性: AI に再生成させても過去の判断と整合
• 教育: 新メンバーが過去の意思決定を学べる
• 監査: コンプライアンス・セキュリティ監査で説明可能

仕事としてタスクは再現性が大事です。ADR を残せるエンジニアは、AI が書いたコードに 「人間の判断」という付加価値を乗せられる。これが AI 時代の差別化要因になってくる。

よくある質問

Q1: AI 出力を全件レビューしていると、生産性が落ちませんか？

A1: そもそも実装スピードが桁違いなので生産性は落ちてません。ただしレビューに慣れていないと意味がないことも。最初は「明らかに OK な部分」と「要レビュー」で分けられるようなるのがいいかもです。長期的には 生産性 × 品質の両立で結果が出ます。

Q2: 5 段階評価フレームワークは大企業以外でも使えますか？

A2: 個人開発・スタートアップでも有効です。が、導入するにはその会社・チームでの承認が必要なのでこのフレームワークの必要性が承認されれば使えるはずです。

Q3: 破壊的テスト演習は実プロダクトでやって大丈夫ですか？

A3: ブランチを切ってローカルでやれば安全です。本番環境では絶対にやっちゃダメです。

Q4: ハルシネーション検出を CI で自動化するコストは？

A4: 既存の TypeScript / ESLint / SAST ツールを組み合わせれば、追加コストは月 $12〜 程度で導入できます。

Q5: 修復パターン辞書はどこから集めればよいですか？

A5: これは自分で積み上げるしかないです。自分の過去 PR コメントを 1 ヶ月分振り返るだけで 5〜10 個は集まります。AI 出力に対するコメントを「悪コードのパターン」と「修復パターン」に分類してドキュメント化してみるといいかもです。

Q6: ADR は何件くらい書けば十分ですか？

A6: 重要な技術選定（フレームワーク・DB・認証方式・キャッシュ戦略）+ 妥協した判断の理由が残っていれば 10〜30 件で十分。書かないより 5 件でも書く方が圧倒的に価値があります。

Q7: ProFact ではこの 5 手法をどう教えますか？

A7: 「AI 制御と品質監査」のカリキュラムで全 5 手法を実演します。また、用意したコードを「壊して直す」演習をしたり、現役 PM のやむぅが GitHub PR で実務同等のレビューを行います。詳細は AI 共生型エンジニア完全ロードマップ を参照。

まとめ

• AI 出力は「動く」と「正しい」が同義ではない
• 手法 1: 5 段階評価フレームワーク（動く / 安全 / 効率的 / 保守可能 / 拡張可能）
• 手法 2: 破壊的テスト演習（わざと壊して直す訓練）
• 手法 3: ハルシネーション 4 種を機械検出（型 / Lint / SAST / DB ログ）
• 手法 4: 修復パターン辞書（チームの財産として蓄積）
• 手法 5: ADR で判断を残す（AI 再生成にも耐える設計記録）
• 5 つすべてを回せるエンジニアの市場価値は急上昇中
• これらは独学では身につきにくく、1on1 実務模擬での反復が最短経路

関連記事:

• AI 共生型エンジニア完全ロードマップ 2026
• Cursor を実務で使いこなす完全ガイド 2026
• エンジニア不要論の正体
• プログラミングスクール選定完全ガイド 2026
• 無料カウンセリング予約

本記事の手法・パターンは 2026 年 5 月時点の現役 PM 観測値および公開情報に基づきます。実プロジェクトでの適用は、各プロジェクトの規模・規約に応じて調整してください。