novel-jp/learn-ac-evaluate

/learn-ac-evaluate — AI 出力の評価と検証（05-01）

AI 生成コードを批判的に読み、正しさ・セキュリティ・保守性を評価する演習です。

所要時間: 約 60 分 前提: /learn-se-decompose（04-01）完了済み スキル対応: AI Collaboration（AI との協働）

---

Step 1: 導入

「AI Collaboration — AI が書いたコードを盲信するのは危険です。

AI は正しそうに見えるコードを高速に生成しますが、
エッジケースの見落とし、セキュリティホール、パフォーマンス問題を含むことがあります。

このセクションでは、AI 生成コードを『批判的に読む力』を養います。
これは従来のコードレビュースキルと同じですが、AI 特有の落とし穴を知ることが重要です。」

---

Step 2: 学習環境の準備

受講者の作業ディレクトリに learn-workspace/ がなければ作成する:

mkdir -p learn-workspace && cd learn-workspace

learn-workspace が作成できない場合: 現在のプロジェクトディレクトリ内の任意のディレクトリで代替できます。コードの生成・レビューができれば演習は成立します。

---

Step 3: AI にコードを生成させる

ガイド AI の振る舞い: ガイド AI がこの場でコードを生成し learn-workspace/validator.ts（または .js）に保存する。受講者はコードの生成過程を観察し、次の Step 4 で評価に集中する。

以下の 意図的に曖昧なプロンプト でコードを生成する:

「以下の機能を実装してください:
ユーザー入力のバリデーション関数。メールアドレス、パスワード（8文字以上、大文字小文字数字を含む）、
ユーザー名（3-20文字、英数字とアンダースコアのみ）を検証する。」

曖昧なプロンプトで生成することで、AI の出力に改善の余地がある状態を意図的に作り出している。

生成後、コードを git init && git add -A && git commit -m "initial: AI generated validator" でコミットしておく。Step 4 のレビュー後に修正差分を確認するために使う。

---

Step 4: 評価演習

Phase A: 自力レビュー

生成されたコードを以下の 4 観点 でレビューしてもらう。まずは観点名だけを提示し、受講者自身に問題を探してもらう。

| 観点 | 問いかけ | | ------------------ | -------------------------------------------------------------------------------- | | 正しさ | 「このコードにエッジケースの漏れはありませんか？ 想定外の入力で壊れる箇所は？」 | | セキュリティ | 「悪意のあるユーザーがこのコードを攻撃するとしたら、どこを狙いますか？」 | | パフォーマンス | 「大量リクエストや極端に長い入力が来た場合、問題になる箇所はありますか？」 | | 保守性 | 「半年後に別のエンジニアがこのコードを修正する時、困りそうな箇所はどこですか？」 |

各観点について順番に問いかけ、受講者の回答を待つ。

受講者が 30 秒以上沈黙した場合、または「わからない」と答えた場合の誘導質問:

• 正しさ: 「validateEmail('') を呼んだら何が返りますか？ 期待する動作は？ null や undefined を渡したらどうなりますか？」
• セキュリティ: 「正規表現に非常に長い文字列を渡すとどうなりますか？ 'a'.repeat(100000) のような入力を想像してみてください」
• パフォーマンス: 「この関数が 1 秒間に 1000 回呼ばれるとしたら、毎回やらなくていい処理はありますか？」
• 保守性: 「コード内の数値 8, 3, 20 は何を意味していますか？ 変更が必要になったとき、すべての箇所を見つけられますか？」

Phase B: 答え合わせ

受講者の回答が出揃ったら、以下の表を開示して補足する。受講者が自力で発見した問題と見落とした問題を明確にする。

| 観点 | チェックポイント | AI がよくやるミス | | ------------------ | -------------------------------------------- | -------------------------------- | | 正しさ | エッジケース（空文字、null、Unicode） | 正常系のみ対応、境界値テストなし | | セキュリティ | ReDoS、入力サニタイズ | 複雑な正規表現でReDoS脆弱性 | | パフォーマンス | 不必要なループ、正規表現のコンパイル回数 | 毎回正規表現をコンパイル | | 保守性 | 命名、構造、テスタビリティ、エラーメッセージ | マジックナンバー、不明確なエラー |

用語解説:

• ReDoS (Regular Expression DoS): 悪意のある入力で正規表現の処理が極端に遅くなる脆弱性。例: (a+)+$ に aaaaaaaaaaaaaaa! を入力
• サニタイズ: ユーザー入力から危険な文字やコードを除去・無害化する処理。XSS 攻撃の防止に重要
• マジックナンバー: コード内に直接書かれた意味不明な数値（例: if (len > 20)）。定数名をつけて意図を明確にすべき

Issue 記録

見つけた問題を upsert_issue で ProjSight に記録する。

なぜ Issue として記録するのか: 実プロジェクトではコードレビューの指摘は PR コメントや改善タスクにすることが多いですが、ここでは ProjSight の Issue 機能に慣れることも目的の一つです。「問題を発見し、構造化して記録する」練習として取り組んでください。

記録後、修正を実施し git diff で修正差分を確認する。

---

Step 5: 振り返り

まず、レビュー結果のサマリーを提示する:

「レビュー結果サマリー:
- 自力で発見した問題: X 件 / 全 Y 件
- 見落とした観点: （該当する観点名を列挙）

（見落とした観点がある場合）
→ 見落とした観点については、Phase B の表を再確認してみてください。
  次に AI 生成コードをレビューする際の重点チェック項目になります。

（全問題を自力発見した場合）
→ 素晴らしい！ AI 特有の落とし穴も含めて的確にレビューできています。」

続けて、学びのまとめを伝える:

「AI の出力を評価する力は、コードレビューの力と同じです。

ポイント:
- AI は『正しそうに見えるコード』を書くのが得意 — だからこそ批判的な目が必要
- 正規表現は AI が生成するコードの中で最もバグが多い領域の1つ
- エッジケース（空文字、null、Unicode、極端に長い入力）は必ずチェック
- 『動くコード』と『良いコード』は違う — セキュリティ・保守性まで見る

ちなみに、Step 3 では意図的に曖昧なプロンプトでコードを生成しました。
01-01 で学んだ Prompt Craft を適用していたら、AI の出力品質はどう変わったでしょうか？
具体的な制約や期待動作を指示に含めることで、レビューで見つかった問題の多くは未然に防げます。

次の /learn-ac-iterate では、1回で完璧を目指さず段階的に精度を上げる対話パターンを学びます。」

受講者のタスクを complete_work(taskId) で完了にする。