AI が書いたコードを「動いた」で終わらせる時代は終わった。2026 年以降で価値がつくエンジニアは、AI 出力を「評価・批評・破壊・修復」できる判断力を持っています。本記事では現役 PM の「やむぅ。」が、自社プロダクトの本番運用で実際に使っている 5 つの実務手法を、具体的なパターン付きで公開します。
なぜ AI が書いたコードを「評価・破壊・修復」できる必要があるのですか？
AI 出力は「動く」と「正しい」が同義ではないからです。本番障害・セキュリティ事故・パフォーマンス劣化の多くは、AI が出したコードをレビューせずそのまま採用したことに起因します。
「動いた」と「正しい」の差
| 観点 | 動くだけのコード | 評価された正しいコード |
|---|---|---|
| エッジケース | テスト通らない | エッジケースもテスト済み |
| セキュリティ | 平文で保存・XSS の可能性 | OWASP 対応済み |
| パフォーマンス | N+1 や無限ループの可能性 | バグ考慮済み |
| 保守性 | 命名が一貫しない | プロジェクト規約に従う |
| ドキュメント | なし | 設計判断を残す |
「作れた」なレベルだと、3ヶ月後にはシステム全体が本人ですら読めなくなる。「正しい」と評価できる人が、AI のスピードに乗れる時代の主役に立てる。
AI 出力レビューの市場価値
AI 出力を評価できるシニアエンジニアの単価は、評価できないジュニアエンジニアの 1.3〜2 倍に達することが珍しくありません。これは「AI が書ける範囲が拡大した結果、評価する側の希少性が逆説的に上がっている」という構造変化です。
手法 1: 5 段階評価フレームワークを使う
AI 出力を「動く / 安全 / 効率的 / 保守可能 / 拡張可能」の 5 段階で評価する。1 つでも欠ければ採用しない、というルールを設けてやっていくと良いです。
5 段階評価フレームワーク
| 段階 | チェック内容 | NG なら |
|---|---|---|
| 1. 動く（Works） | ハッピーパスでエラーなく動作 | 即修正 |
| 2. 安全（Secure） | OWASP Top 10 / 認証認可 / 入力検証 | セキュリティリファクタ |
| 3. 効率的（Efficient） | N+1 なし / 計算量妥当 / メモリ妥当 | プロファイル後修正 |
| 4. 保守可能（Maintainable） | 命名規則 / 関数分割 / コメント適切 | リファクタ |
| 5. 拡張可能（Extensible） | 将来の変更に耐えるか | 設計再検討 |
フレームワークの使い方
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 種と検出方法
| 種類 | 症状の例 | 検出ツール |
|---|---|---|
| 1. 存在しない API | そんなものないやつ→array.popFirst() | エディタ型補完 + tsc --noEmit |
| 2. Deprecated | React componentWillMount 等 | ESLint + 公式 changelog |
| 3. セキュリティ脆弱性 | 平文保存 / XSS / SQL injection | OWASP ZAP / Snyk / SonarQube |
| 4. N+1 クエリ | ループ内クエリ | DB ログ + EXPLAIN プラン |
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 倍になります。
頻出する悪コードと修復パターン
| 悪コードのパターン | 修復パターン |
|---|---|
try/catch で握りつぶし | エラー型を明示、ログ出力、上位に再 throw |
async/await の暴走 | Promise.all で並列化、Result 型でエラー伝播 |
| 巨大な関数（100 行超） | 単一責任原則で分割 |
| マジックナンバー散在 | 定数化 + 型化 |
| ループ内 DB クエリ | バルク取得 / JOIN / IN 句 |
| インライン SQL | プリペアドステートメント / ORM |
修復パターン辞書の運用
- プロジェクトの
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 実務模擬での反復が最短経路
関連記事:
本記事の手法・パターンは 2026 年 5 月時点の現役 PM 観測値および公開情報に基づきます。実プロジェクトでの適用は、各プロジェクトの規模・規約に応じて調整してください。
Related Articles
関連記事
YouTubeでも発信中
Xでも発信中
@yamuu_desu_yo を見るFree Counseling
学習やキャリアの悩みを無料で相談できます
何を学ぶべきか、AIをどう実務に活かすか、エンジニアへの転職や個人開発の進め方まで、現役エンジニアにご相談ください。
無料相談を申し込む