Lv2 プロンプト設計と評価

前提: L1（API基礎）修了。CCAドメイン①・②（Prompting and Task Execution／Output Evaluation and Validation） / 力量マップ D・E。 このレベルの核: 「プロンプトを書く技術」より先に「プロンプトを測る技術」。ここで作る eval の習慣は L6 まで全成果物に横断適用する。

学習目標

1. 本番投入前に自前の eval pipeline で客観スコアを得て反復できる
2. テストデータセットを用意し、code / model / human based grading を基準に応じて使い分けられる
3. 4技法（明確・具体・XMLタグ・例示）を効果を測定して採否判断できる
4. 要件分解 → 委譲 → 検証の中に prompt engineering と eval を位置づけて説明できる

モジュール 2.1 — evalファースト思考

学ぶこと

• プロンプトを書いた後の3つの道: ①1〜2回試して本番投入 ②手持ちの入力で数回試して手直し ③eval pipeline で客観スコアを得て反復改善。①②は「誰もが陥る罠」、常に③を選ぶ
• 典型的な eval の5ステップ: ドラフトプロンプト → データセット作成 → 各 test case をプロンプトにマージして送信 → grader で採点 → スコアを平均して反復
• 業界標準の唯一の手法はない。まず自前で小さく作って動きを理解する
• スコアの絶対値より「V1 と V2 の比較」に価値がある（単発スコアでは良し悪しを判断できない）

次の図で、eval ファーストが「体感でなく客観スコアの比較で採用/棄却を決める反復サイクル」であることを掴む。

✏️ 再現チェック: モジュールを読み終えたら、この図を見ずに白紙へ描き直す（矢印のラベルまで）。描けなかった部分が復習ポイント。

読む

• 全文ガイド の Prompt evaluation と A typical eval workflow の2レッスン

やる: 手動テストの限界を体感する（手順付き）

1. ベースライン: L1 の CLI のプロンプトに入力を3つ投げ、良し悪しを主観でメモ
2. 設計: 「データセットに入れる入力の種類」「採点基準」を紙に書き出す（実装しない）
3. 敵対テスト: 壊れそうな入力を5つ以上列挙（空・超長文・言語混在・矛盾指示・フォーマット崩し）
4. 測定: 手動テストの所要時間を記録し、入力10倍時を見積もる
5. 言語化: ①②がなぜ罠か、手順3・4を根拠に3行で書く

自己チェック

モジュール 2.2 — テストデータセット生成と実行

学ぶこと

• データセットの各レコード＝ test case。デモは3件だが実際は数十〜数千件になりうる
• 手動でも Claude 生成でも作れる（生成は Haiku など高速・低コストモデルが向く）。JSON 抽出は prefill（```json）＋ stop sequence（L1 の再利用）
  現行API

  ⚠️ 現行API注記（2026-07-11確認）: prefill が使えるのは旧世代モデル（Haiku 4.5 / Sonnet 4.5 等）のみで、現行モデル（Opus 4.6+ / Sonnet 4.6+）では 400 エラー。生成に Haiku 4.5 を使うなら教材どおりで動く。現行モデルで生成するなら structured outputs（output_config.format）で代替する（L1 1.5 の注記参照）。stop_sequences 自体は prefill と組み合わせなくても現行APIで引き続き利用できるパラメータ。

• test case には入力に加え採点に必要な期待値（format・solution_criteria 等）を含める。ファイルを手で直さず生成プロンプト側を更新する
• 実行部は3関数構成が定石: run_prompt（マージして呼ぶ）/ run_test_case（1件実行・採点）/ run_eval（全件ループ・集約）
• 実行時間は無視できない（Haiku でも3件で約31秒）。並行実行で速くなるがレート制限に注意（まず3並行、エラーなら 2→1）。実行のたびにレポート（output.html）で低スコアの reasoning を読んでから直す

読む

• 全文ガイド の Generating test datasets と Running the eval の2レッスン

やる: 自分のデータセットを生成する（要点のみ）

1. ベースライン: task を持つ JSON 配列を Claude（Haiku 推奨）に3件生成させ dataset.json に保存
2. 設計・実装: 自分のユースケース向けに生成プロンプトを書き換え 10件以上生成。3関数構成で実行部を書く（採点は仮スコアでよい）
3. 敵対テスト: 生成結果を目視監査（重複・非現実的・簡単すぎ）。2.1 の「壊れる入力」を2件以上手動追記
4. 測定: 実行時間とトークン使用量を記録。並行数を変えて時間差を測る
5. 言語化: 「Claude 生成の利点と目視監査を省けない理由」を3行で

低コスト版: Claude の出力を JSON に保存し、以降は記録済みレスポンスに採点だけ再実行（API を呼ぶのはプロンプトを変えたときだけ）。

自己チェック

モジュール 2.3 — 採点方式の使い分け（code / model / human）

学ぶこと

• grader は出力を受け取り客観的シグナル（慣行は1〜10、数値必須ではない）を返す。3種類:
  • Code based: プログラムで検証。長さ・特定語・構文検証（JSON パース / Python AST / 正規表現コンパイルを試み、成功10・失敗0）。決定的・高速・低コスト
  • Model based: 追加の API リクエストでモデルに採点させる。品質・忠実さ・完全性など柔軟な基準を評価できるが、コスト増で採点が揺らぐ
  • Human based: 最も柔軟だが遅く地道。全件には使えない（補足: 「スポットチェックの基準点として使う」のは教材外の実務補足）
• 「6点問題」: スコアだけ求めると無難な6点に偏る。strengths / weaknesses / reasoning を求めると具体的なスコアに絞り込まれる
• solution criteria の注入: 生成時に solution_criteria も作らせ、grading プロンプトに XML タグで挿入すると採点精度が上がる
• 複数 grader のスコアはマージできる（例: score = (model_score + syntax_score) / 2）
• 評価基準は採点実装の前に決め、基準ごとに方式を割り当てる（コース例: フォーマット・構文 → code、タスクへの的確な対応 → model）

次の図で、3つの採点方式を「何を測るのに向くか」の軸で対比し、基準ごとに方式を割り当てる使い分けを押さえる。

読む

• 全文ガイド の Model based grading / Code based grading / Exercise on prompt evals の3レッスン

やる: 自分の grader を実装する（要件のみ）

1. ベースライン: 仮スコアのまま1回実行し、平均スコアを記録
2. 設計・実装: 評価基準を3つ以上書き出し、code / model を割り当ててから両方を最低1つずつ実装しマージ。model grader には strengths / weaknesses / reasoning を要求
3. 敵対テスト: わざと壊れた出力（不正 JSON・途切れ・冗長な説明つき）を直接食わせ、低スコアになるか確認。grader 自体もテスト対象
4. 測定: model grader の時間・コスト増分を記録。同じ出力に3回採点させばらつきを観察
5. 言語化: 「この基準はなぜ code / model なのか」を基準ごとに1行で

自己チェック

モジュール 2.4 — プロンプトエンジニアリング4技法

学ぶこと

必ず eval とセットで、1技法適用するたびに再測定する（コースの食事プランデモで 2.32 → 7.96。講師は弱いモデルで伸びを誇張したと明言、絶対値の再現は不要）。

1. Being clear and direct: 最初の一行が最重要。action verb＋シンプルな言葉で何をすべきかを正確に伝える。デモで 2.32 → 3.92、演習（トピック抽出）ではこれだけで 2.8 → 9.5
2. Being specific: タイプA=出力に持たせたい属性のリスト（ほぼ常に推奨）と タイプB=従うべき手順のリスト（自然には考慮しない視点を検討させたいとき）。実務では併用が多い。デモではAで 7.86（Bは 7.3 で劣りAに戻した）
3. Structure with XML tags: 補間するコンテンツの塊をタグで囲み、何が何かを明確にする。大量・複数種のコンテンツで特に効く。タグ名は自由で内容を表す名前をつける（<my_code> <docs> 等）
4. Providing examples（one-shot / multi-shot）: サンプル入力と理想の出力のペアを XML タグで囲んで示す。コーナーケース（皮肉ツイート分類）と複雑な出力フォーマットに有効。eval レポートの高スコア実例を例に転用し、reasoning も添えるとさらに効く

読む

• 全文ガイド の Prompt engineering から Exercise on prompting までの6レッスン

やる: 測定つきプロンプト改善（要件のみ・本レベルの中心）

1. ベースライン: L1 の CLI のプロンプトを 2.2〜2.3 の eval に通し、スコアを記録
2. 設計・実装: 4技法を1つずつ適用し、適用のたびに再測定（一度に全部入れると効果を分離できない）。examples はレポートの高スコア事例から転用
3. 敵対テスト: 最高スコア版に 2.1 の敵対入力を追加しスコア低下を観察。カバーする guidelines か example を足して再測定
4. 測定: 各バージョンのスコア・時間・トークン数を表に（技法を足すほど高コスト、トレードオフを見る）
5. 言語化: 採用/棄却した技法と根拠を設計判断メモに残す

低コスト版: データセットを10件・モデルは Haiku に絞る。各バージョンの応答は保存し、grader の調整・再採点は記録済みレスポンスに対して行う（API を呼ぶのはプロンプトを変えた直後の再測定だけ）。

自己チェック

モジュール 2.5 — 要件分解と委譲（ai-fluency-for-builders 接続）

学ぶこと

• 4D Framework = Delegation（何を任せるか）/ Description（どう伝えるか）/ Discernment（出力をどう評価するか）/ Diligence（結果に責任を持つ）。Description＋Discernment が日々の inner loop、Delegation＋Diligence が outer loop
• Description Chain: user voice → requirement → technical spec → AI instruction → tests。prompt engineering はこの連鎖の1リンク。「コードは動くのにプロダクトがダメ」なら壊れたリンクを遡る
• テストは最も精密な description。コードの前に acceptance tests（done の定義）を書く
• 実装の委譲はおおむね安全、判断の委譲はおおむね危険。AI の失敗の多くは上流の description / discernment / diligence の失敗に遡れる
• L2 との接続: eval は Discernment の機械化。solution criteria は acceptance tests のプロンプト版で、「良い出力の基準を先に言語化してから作る」規律は共通

読む

やる: eval を Description Chain に位置づける

1. ベースライン: 2.4 のプロンプトが「誰の何の要求に応えるか」を1段落で書く
2. 設計: user voice → requirement → spec → AI instruction → tests（eval の criteria）の5リンクを自分のプロジェクトで埋める
3. 敵対テスト: 「スコアは高いのに想定ユーザーが不満」なシナリオを2つ考案し、どのリンクの記述漏れが原因か特定
4. 測定: 記述漏れを criteria に反映し、eval を再実行してスコア変化を記録
5. 言語化: 「AI に委譲した部分・自分に残した判断」を各3つ列挙

自己チェック

キャップストーン増分 — ドキュメント調査アシスタント【第2形態】

L1 の構造化出力つきチャット CLI に eval ハーネスを追加する。

• テストデータセット 10件以上（Claude 生成＋敵対ケース手動追記、solution_criteria 相当の期待値つき）
• code based と model based の併用（例: スキーマ検証＝code、的確さ＝model。マージ方法は自分で決めて根拠を書く）
• ベースラインスコアを記録し改善後と対で残す（以降のレベルで回帰チェックとして再利用）
• 記録済みレスポンスで grader だけ再実行できる低コストモード

提出物（4点）: ①実装 ②eval データ（dataset.json＋敵対ケース） ③実行結果（前後スコア・時間・トークン数） ④設計判断メモ（採用/棄却と grader 割り当ての根拠）

修了ゲート（L2）

共通ゲート運用（知識20% / 実技60% / 説明20%、総合80%以上、部分合格・遅延チェックあり）は README.md 参照。安全性の必須項目は配点と独立に全問正解（safety-security.md 参照）。

L2 固有の宣言: L3A 以降 L6 まで、全レベルの成果物（tool use・RAG・MCP 等）に eval による測定と回帰チェックを横断適用する。以降のゲートの「評価」観点はこのレベルの成果物が土台。

演習導線: この時点で safety-security.md の演習 S-2（eval ハーネスに敵対 eval ケース10件を追加。S.6）を実施する。追加した敵対ケースは L3A 以降のゲートの実技評価（「安全性」観点）で再利用する。

知識確認（4問・類題2〜3種から出題）

1. eval ワークフローの5ステップを成果物とともに順に述べよ
2. code / model / human based grading の使い分けを、コスト・決定性・柔軟性の3軸で説明せよ
3. model grader に strengths / weaknesses / reasoning を要求する理由を述べよ
4. being specific のタイプA（属性リスト）とタイプB（手順リスト）はそれぞれどんな場面に向くか

安全必須問題（全問正解が必要・配点と独立）

1. eval データや grader に入れる外部由来テキストを無条件に信頼してはいけない理由を述べよ（S.2）
2. 演習 S-2（敵対 eval ケース10件の追加。S.6）を実施し、「攻撃成功の定義」と誤検知の測定まで含めて説明できること

（詳細は safety-security.md の組込み表を参照）

実技（eval ハーネスのルーブリック: 5観点 × 0〜3点）

説明課題（20%）

いずれかを他者に見せられる文章（400〜800字目安）で:

• model based grading の弱点と対策（6点偏り／採点の揺らぎ／追加コストに対し、reasoning 要求・solution criteria 注入・code grader 併用・human スポットチェック（教材外の補足）の組み合わせ）
• 4技法のうちキャップストーンで最も効いた技法と効かなかった技法を、測定値を根拠に説明

レベル末尾情報

• 力量マップ対応: competency-map.md の D（プロンプト設計・構造化出力）と E の「評価・観測」。数値更新には提出物への証拠リンク必須
• CCA副線: ドメイン①・②（Prompting and Task Execution／Output Evaluation and Validation）。L2 修了後に cca-prep.md の「プロンプトエンジニアリング＆構造化出力」ドリルを解く（先に解答を読まない）
• 次のレベル: L3A／L3B は並行可。どちらにも eval ハーネスを回帰チェックとして持ち込む
• 最終確認日: 2026-07-11（教材出典は各モジュールの「読む」欄）