ゴールデンセットとは、20〜50件程度の実際の業務タスクを固定して集めたもので、それぞれの出力は既に人間が確認し、そのまま提出できる品質だと承認済みである。重要なのは「固定」という点だ。プロンプトを修正したとき、Claude のモデルを切り替えたとき、Claude Projects のナレッジベースに資料を追加したときに、同じタスク群を再実行し、新しい出力を承認済みの出力と並べて比較する。抜き取り検査と混同されやすいが、問う内容が違う。抜き取り検査は「今日の出力は使えるか」を問い、ゴールデンセットは「今日のシステムは先週より良いか悪いか」を問う。正解が文字列一致ではなく判断である以上、エンジニアリング的なテストスイートとも異なる。
プロンプトを修正するとき、人は直したい問題だけを見ており、これまで正常に動いていた10件のうち2件が静かに壊れたことには気づかない。モデルのバージョン更新、担当モデルの切り替え、ナレッジベースへの資料追加、スケジュールタスクのトリガー条件の微調整——いずれも出力の挙動を変えるが、「前のバージョンがどうだったか」を記録している職場はほとんど存在しない。その結果、品質の議論は印象のぶつけ合いに崩れていく。良くなったと言う人と、最近どうもおかしいと言う人がいて、どちらも比較材料を出せないまま平行線になる。ゴールデンセットの存在理由はただ一つ、「前のバージョン」を記憶からいつでも開けるファイルに変え、変更の効果を目に見える差分にすることである。
まず選定から始める。中心になるのは毎週回している平凡な業務タスク、つまり誰も議論したがらない退屈な仕事であり、そこに既に問題が起きると分かっているエッジケースを数件加える。スキャンされた添付ファイル、二言語が混在したメール、数字が互いに矛盾している元データなどである。各項目は入力と承認済み出力をペアで保存し、スプレッドシートでも Claude Projects のナレッジベースでもよいが、誰でも取り出せることが条件だ。検証時はバッチ処理でセット全体を一度に流し、事実に誤りがないか、必要な項目が揃っているか、対外基準に合った語調かという三点で一件ずつ照合する。合格ラインは満点ではなく「前のバージョンより悪くないこと」である。実務上の形式は二つある。項目・数値・日付など出力形式が固定のタスクには厳密比較が向き、自由記述には評価表による採点が向いていて、各件を人が1〜5点で採点し合計点の推移を見る。運用面では、常に合格するようになった項目を四半期ごとに数件入れ替え、新たに踏んだ失敗事例を追加していく。
ゴールデンセットの構築にかかるのは概ね半日である。20〜30件の入力を揃え、承認済み出力を貼り付け、比較基準を書き出す。以降の再実行は一回あたり15分程度だ。割に合うかどうかは二つの条件で決まる。同種のタスクを週に数回以上回していること、そして出力が顧客のメール、経営層向け資料、社外文書に直接入ることである。両方に当てはまるなら、半日の投資で「壊れたその場で気づける」状態が手に入る。三週間後に顧客から指摘される代わりに、である。一度きりのタスクには不要だ。比較する次回が存在しない。注意すべき本当のリスクはセットの老朽化である。使い続けるうちに、既に直した問題ばかりが残り、毎回100%合格し、安心感だけがあって何も測れなくなる。判定方法は単純で、二回続けて失敗がゼロなら、それは安定ではなく入れ替えの合図だ。
Anthropic は新モデルを公開するたび、model card で同一の公開ベンチマーク（MMLU、GPQA、SWE-bench など）のスコアを示す。問題が固定されているからこそ、外部の読み手は新旧のスコアを並べて比較できる。毎回問題を入れ替えていたら、スコアが上がっても改善の証明にはならない。企業内のゴールデンセットも規模が違うだけで、やっていることは同じである。
メリット：品質を印象から比較可能な差分に変えられるため、壊れた変更をその場で検知でき、モデルの切り替えやプロンプト修正が賭けではなくなる。デメリット：初期構築に半日、四半期ごとに項目を入れ替える保守が必要で、放置すればセット自体が老朽化して機能しなくなる。さらに創作コピーや戦略立案のように出力が開放的なタスクでは比較基準の定義が難しく、主観採点を言い換えただけのものに陥りやすい。