コードにはぜいたくがあります。動くか、動かないかのどちらかです。あなたがアサーションを書き、それを実行すると、緑のチェックか赤のチェックが返ってきます。ほとんどのLLM評価フレームワークはまさにこれに寄りかかっています――assert output contains X、assert valid JSON、assert no error。
しかし、編集（エディトリアル）出力にはそんなぜいたくはありません。ピッチ用のトリートメント、ショーノートの下書き、リード文――「有能なプロデューサーならこのように送るはずだ」と真になるテストは存在しません。では、毎回あらゆる出力を人間が読まずにどう評価するのでしょうか？
私はこれを具体的に答える必要がありました。メディア業務向けに、約400のClaudeスキルのライブラリを維持しているからです。「信じて、良いから」は品質基準になりません。ここでのアプローチです。
2段階：まず二値、次に判断
第1段階は安価なフィルター――二値のアサーションです。 文章であっても、多くの失敗は機械的でテスト可能です。必要なセクションは生成されたか？ リードは1文か？ ソースが与えられないのに引用を捏造しないか？ こうしたものは、明らかな破綻を素早く見つけ、複数の入力に対してブラインドに実行でき、コストはゼロです。ライブラリはこれらを何千回も実行します。興味深い結果として、「失敗」とされるものの大半は、薄い入力に対して意図的にコンテンツを捏造しないスキルでした――望ましい挙動であり、バグではありません。
第2段階が、文章にとって重要な部分――段階評価の判断です。 モデルは、各出力を7つの次元（coherence、relevance、accuracy、completeness、usefulness、format-fit、そしてもう1つ）で1〜5のスコアを付けます。このうち「もう1つ」が実際に効いてくる部分です。
実際に効く次元：Editorial Naturalness（編集上の自然さ）
7つのうち6つは一般的なものです。7つ目はハードな下限値です――「その媒体を理解している人が書いたように読めるか」、それとも「モデルが書いたように読めるか？」
これは直感（vibes）ではなく、観測可能な手がかりに基づいてスコア付けします：
- 語彙（Lexical） ―― AIの語彙（delve、leverage、robust、seamless、tapestryなど）。
- 構造（Structural） ―― 誤った転換（「XだけでなくYも」）、口を切るような前置き、毎行のルール・オブ・スリー。
- トーン（Tonal） ―― 作られた熱意、ヘッジの連なり、謝罪のスパイラル。
- ジャンル（Genre） ―― 自分が提供すると主張するフォーマットの慣習をちゃんと尊重しているか？
あるスキルが他の6つの次元で5/5を取っても、失敗しうることがあります。Editorial Naturalnessが下限値を下回っていれば、そのスキルは出荷されません。この1つの制約が、ライブラリが「それっぽいが中身がない」ものへ漂流するのを止めています。
なぜ平均ではなくハードな下限値なのか
平均は、あなたが本当に気にしているものを隠します。正確で、網羅的で、よく構造化されていて――しかも明らかに機械で書かれているドラフトでも、平均スコアなら十分に通ってしまうでしょう。メディア業務では、そんなドラフトは役に立ちません。視聴者（聴衆）は1文でそれと気づきます。下限値を設けることで、「失敗」が平均に埋もれて消えてしまうのを防げます。
正直な制約
モデルが文章を採点するのは寛大です――流暢な文章、とりわけ流暢なAIの文章が好きになりがちです。なので、スコアは判決ではなくフィルターとして扱います。明確な失敗を拾い、候補を順位付けするのはできますが、「安定している」ことの基準は意図的に高く設定しています（自然さの下限値込みで≥4.0）。また、ルーブリックは好みではなく観測可能な手がかりに根差しているため、2回実行してもだいたい一致します。完璧ではありません。でも、「雰囲気で出荷する」よりずっと良いです。
このフレームワーク全体――次元、閾値、禁止フレーズのリスト――はオープンソースです。コード以外のLLM出力を評価しているなら、分解して「どこが柔らかすぎるのか」を教えてください。
