D4 プロンプトエンジニアリングと構造化出力

Task Statement 4.1明示的基準の設計（曖昧な指示は精度を上げない）

「慎重に」「高信頼のものだけ報告して」は精度を改善しない。効くのは「コメントの主張がコードの実挙動と矛盾する場合のみフラグ」のようなカテゴリー別の具体的基準。誤検知（false positive）が多いと、正しい指摘まで信用されなくなる。

試験が問うこと

曖昧指示（"be conservative", "check that comments are accurate"）vs 明示基準（"claimed behavior contradicts actual code behavior の場合のみ"）の対比
誤検知率が開発者の信頼を壊す構造：誤検知の多いカテゴリが、正確なカテゴリの信用まで巻き添えにする
対処：報告する問題（バグ・セキュリティ）とスキップする問題（軽微なスタイル・ローカル慣習）をカテゴリで定義する。「確信度でフィルタ」に頼らない
誤検知の多いカテゴリは一時的に無効化して信頼を回復し、その間にプロンプトを改善する
重大度（severity）の判定基準は、各レベルに具体的なコード例を付けて定義→分類が安定する

うちの組織の実物

rules/output-quality.md の抽象表現禁止テーブル（「適切に処理する」→「Try/exceptでログ出力し再raise」）と、feedback-quality-bar「抽象語は具体化しろ」が完全に同じ思想。「AIへの指示も、AIからの出力も、曖昧語を潰す」——組織の品質バーがそのまま答案になる。

ひっかけ

「プロンプトに『高信頼のもののみ報告』と足す」→ 一般的注意は具体的カテゴリ基準に勝てない
「確信度スコアでフィルタする」→ LLMの自己申告確信度は較正されていない（D5でも同じ論点が出る）

Task Statement 4.2few-shot プロンプティング（例で教える）

詳細な指示文でも出力がブレるとき、最も効くのは狙いを定めた実例2〜4個。特に「曖昧なケースでどう判断すべきか」を、なぜその選択をしたかの理由付きで見せると、モデルは新規パターンにも判断を汎化できる。

試験が問うこと

few-shot＝一貫したフォーマット・実行可能な出力を得る最有効テクニック（指示文だけで不安定なとき）
曖昧ケースの扱いを例で示す：あいまいな依頼でのツール選択、ブランチレベルのテストカバレッジの穴、など
「許容されるコードパターン」と「本物の問題」を区別する例→誤検知を減らしつつ汎化を保つ
抽出タスクのハルシネーション対策：形式が多様な文書（インライン引用vs巻末文献、本文埋め込みvs構造化表）の正しい抽出例を見せる→空欄・null処理が安定
例には「出力フォーマットの実物」（場所・問題・重大度・修正案）を含める→形式が揃う

うちの組織の実物

skills/agents のプロンプトに Good/Bad 例を書き込む流儀（editorial系スキルの文例、copywriting系のNG/OK対比）がこれ。empirical-prompt-tuning スキルは「few-shotを足した後に効果を実測する」工程で、試験の一歩先を行く運用。

ひっかけ

「指示文をさらに詳しく書き足す」→ ブレの根治は例示の方が効く（4.1と同じ対比構造）
「例は多いほどよい（5〜8個以上）」→ 2〜4個の狙いを定めた例が推奨。数はトークンコストとのトレード

Task Statement 4.3tool_use と JSONスキーマによる構造化出力の強制

「JSONで返して」とお願いするより、ツール定義のJSONスキーマを入力パラメータとして使い、tool_use で呼ばせるのが最も確実。構文エラー（壊れたJSON）は消える。ただし意味エラー（合計が合わない・値が違う欄に入る）は消えない——この区別が頻出。

試験が問うこと

tool_use＋JSONスキーマ＝スキーマ準拠を保証する最も信頼できる構造化出力の方法
tool_choice の復習（D2と共通）："auto"はテキストで返す可能性が残る／"any"でツール呼び出しを保証／文書タイプ不明で複数の抽出スキーマがあるなら"any"、特定の抽出を先に走らせたいなら強制指定
構文エラーは消えるが意味エラーは残る：明細の合計が総額と合わない、値が誤った欄に入る——スキーマでは防げない
スキーマ設計の考えどころ：required vs optional／enumに "other"＋詳細文字列のペアで拡張性を持たせる／元文書に無い情報の欄は nullable にする（必須にするとモデルが値を捏造して埋める）
曖昧ケース用に "unclear" のようなenum値を用意する／フォーマット正規化ルールはプロンプト側に書く

うちの組織の実物

Workflow ツールの schema オプション（サブエージェントにStructuredOutputを強制）が日常の実物。「必須欄が捏造を誘発する→nullable設計」は rules/data-accuracy.md の捏造防止と同じ問題意識をスキーマ設計で解いたもの。「東京院に実在しないドメインを書いた事故」は、まさに required 欄を埋めたがる性質の現れ。

ひっかけ

「strictスキーマにすれば抽出の正確性が保証される」→ 構文の保証であって意味の保証ではない
「欠けているかもしれない情報も required にして完全なデータを強制」→ 捏造の温床。nullable が正解
「プロンプトで『必ずJSONで』と念押し」→ tool_use による強制の方が確実

Task Statement 4.4検証・リトライ・フィードバックループ

検証に落ちたら、元文書＋失敗した抽出結果＋具体的な検証エラーを付けて再依頼する（retry-with-error-feedback）。ただし「情報がそもそも文書に無い」失敗はリトライしても直らない——リトライが効く失敗と効かない失敗を見分けるのが本題。

試験が問うこと

リトライが効く：フォーマット不一致・構造的な出力エラー／効かない：必要な情報が元文書に存在しない（外部文書にしかない等）
意味エラー（値が合計と合わない・欄違い）と構文エラー（tool_useで既に消えている）の区別——4.3の続き
自己修正フローの設計：「stated_total（記載の総額）」と別に「calculated_total（明細から計算した総額）」を抽出させ、不一致なら conflict_detected フラグを立てる
フィードバックループ：どのコード構造が指摘を発生させたかを detected_pattern 欄で記録→開発者が却下した指摘のパターン分析→プロンプト改善につなげる

うちの組織の実物

rules/data-accuracy.md の「合計突合＋書き込み後の計算列検証」は calculated vs stated の照合そのもの。memory/pii-mask-false-positives.md（誤検知を記録して後でルール調整）は detected_pattern によるフィードバックループの運用版。

ひっかけ

「検証失敗は常にリトライで解決」→ 情報が無いものは何度やっても出ない。失敗の種類を見てから
「エラー内容を伝えず『やり直して』とだけ再依頼」→ 具体的な検証エラーを渡さないと同じ失敗を繰り返す

Task Statement 4.5バッチ処理の設計（Message Batches API）

Message Batches API は50%引き・最大24時間・遅延保証なし。人が待つ処理（マージ前チェック）には使えず、夜間レポートや週次監査のような待てる仕事に使う。「どちらのAPIをどの業務に当てるか」のマッチング問題として出る。

試験が問うこと

3つの特性の暗記必須：コスト50%減／処理窓最大24時間／レイテンシSLAなし
適する：夜間レポート・週次監査・夜間テスト生成（ブロックしない・遅延許容）／適さない：マージ前チェック（人が待つ）——サンプル問題Q11そのもの
制約：バッチ内では複数ターンのツール呼び出しができない（実行途中でツールを走らせて結果を返せない）
custom_id でリクエストとレスポンスを対応付ける→失敗した文書だけを特定して修正（例：コンテキスト超過はチャンク分割）して再投入
SLA逆算：24時間処理＋30時間SLAなら4時間おきに投入、のような算数
大量投入の前にサンプルでプロンプトを磨いて一発成功率を上げ、再投入コストを減らす

うちの組織の実物

「同期かバッチか」の判断軸は、BQの「5MB超はload job必須」（feedback-bq-batch-vs-loadjob）と同じ「処理特性でAPIを選ぶ」型。週次レポート自動配信（セミナー・rehab）は、まさにバッチ向きワークロードの実例。

ひっかけ

「両方バッチにしてポーリングで待つ」→ 『だいたい速く終わる』は人が待つ処理の設計根拠にならない（Q11誤答B）
「バッチは結果の順序が壊れるから使わない」→ custom_id で対応付けられる。誤解として出題される（Q11誤答C）
「タイムアウトしたらリアルタイムにフォールバック」→ 不要な複雑化。適材適所が正解（Q11誤答D）

Task Statement 4.6多重インスタンス・多段パスのレビュー設計

自分で生成したコードを同じセッションでレビューさせると、生成時の思考の文脈を引きずって自分の判断を疑えない。独立した第2インスタンスに見せる。大きなレビューは「ファイル別の局所パス＋横断の統合パス」に分割して注意力の希釈を防ぐ。

試験が問うこと

自己レビューの限界：生成時の推論コンテキストが残るため、同一セッションでは自分の決定を疑いにくい。self-review指示や思考時間の延長より、文脈を持たない独立インスタンスが効く
多段パスレビュー：14ファイルのPRを1回で見せると、詳細な指摘と浅い指摘が混在し、同じパターンに矛盾した判定が出る（注意力の希釈）→ ファイル別パス＋クロスファイル統合パスに分割（サンプル問題Q12）
確信度の自己申告を検証パスに添えさせ、レビューのルーティング（人が見るべきもの）の材料にする——ただし較正が前提（D5.5と接続）

うちの組織の実物

組織の十八番。rules/audit-independence.md（盲検・独立コンテキスト・Generator-Evaluator分離）と lead-worker の Two-Reviewer Pattern（仕様準拠と品質を別々に独立起動）が、このタスクステートメントの完全な実装。「editorial-checker と geo-auditor を統合しない」円卓会議の結論は、試験の言う self-review threat の回避そのもの。

ひっかけ

「コンテキストウィンドウの大きい上位モデルに替えて1回で見る」→ 窓の大きさは注意力の質を解決しない（Q12誤答C）
「3回独立レビューして2回以上出た指摘だけ採用」→ 間欠的にしか検出されない本物のバグを合議が握りつぶす（Q12誤答D）
「開発者にPRを小さく割らせる」→ システム改善ではなく負担転嫁（Q12誤答B）

用語ミニ辞書（Domain 4）

明示的基準 / explicit criteria

「慎重に」ではなく「XがYと矛盾する場合のみ報告」のような、該当/非該当を機械的に判定できる基準。誤検知削減の第一手。

few-shot プロンプティング

入出力の実例を2〜4個見せて出力の形式と判断基準を教える技法。曖昧ケースの判断理由まで例に含めると新規パターンへ汎化する。

tool_use による構造化出力

出力スキーマをツールの入力パラメータとして定義し、そのツールを呼ばせることでJSON構文の正しさを保証する方式。「JSONで返して」より確実。

構文エラー vs 意味エラー

構文=JSONとして壊れている（tool_useで解消）。意味=形式は正しいが中身が間違い（合計不一致・欄違い。スキーマでは防げず、検証ロジックで捕まえる）。

nullable設計（捏造防止）

元文書に存在しない可能性がある欄を必須にすると、モデルが値をでっち上げて埋める。省略可能（null許容）にして「無いものは無い」と言える設計にする。

retry-with-error-feedback

検証に落ちたら「元文書＋失敗した出力＋具体的なエラー内容」を付けて再依頼する型。情報がそもそも無い失敗には効かない。

Message Batches API

非同期の一括処理API。50%引き・最大24時間・SLAなし・バッチ内での多ターンツール呼び出し不可・custom_idで結果を対応付け。待てる仕事専用。

注意力の希釈 / attention dilution

一度に多くの対象を見せると1つあたりの分析が浅く・不安定になる現象。ファイル別パス＋統合パスへの分割で対処。「大きい窓のモデルに替える」では直らない。

独立レビューインスタンス

生成時の推論文脈を持たない別セッション/別エージェントにレビューさせる設計。自己レビュー指示・拡張思考より効く。

仕上げチェックリスト（30秒で説明できたらチェック）

「be conservative」が効かない理由と、代わりに書くべき基準の形を説明できる
誤検知がなぜ「正しい指摘の信用」まで壊すのか、その対処（カテゴリ一時無効化）を言える
few-shot が「指示の追記」より効く場面と、例に含めるべき要素を言える
tool_use による構造化出力が「プロンプトでお願い」より確実な理由と、それでも残るエラーの種類を説明できる
nullable 設計がハルシネーションを防ぐ仕組みを説明できる
リトライが効く失敗と効かない失敗の見分け方を言える
Batches API の3特性（50%/24h/SLAなし）と適不適の業務例を即答できる
自己レビューの限界と独立インスタンスの優位を、audit-independence の実装と対応付けて説明できる