self-eval

self-eval skill の概要

self-eval の用途

self-eval skill は、作業後に率直な自己評価を行うための、プロンプトのみで動作する Claude Code skill です。タスク、コードレビュー、実装セッション、デバッグ、計画立案のあとに、AI エージェントが自分のアウトプットを評価する際、曖昧な称賛や根拠の薄い「4/5」評価に流れないようにします。

「これはどれくらい良かったか？」を主観的な単一尺度で尋ねるのではなく、self-eval は評価を「タスクの野心度」と「実行品質」という 2 つの軸に分けます。そのため、「これは本当に強い成果だったのか、それとも簡単なタスクを無難にこなしただけなのか？」を見極めたい場面で役立ちます。

向いているユーザーとタスク

完成した作業を受け入れる前、マージする前、またはその上にさらに実装を重ねる前に、エージェント自身にレビューさせたい場合は self-eval skill が適しています。特に、コード生成、リファクタリング、Issue のトリアージ、テスト作成、アーキテクチャ分析で AI を使うエンジニアリングチームに向いています。

ただし、テストスイート、人間によるレビュー、セキュリティレビュー、本番環境での検証の代替にはなりません。価値があるのは、構造化された自己批評です。過信を抑え、弱点を表面化し、作業セッションごとのスコア履歴を残せます。

通常のプロンプトとの違い

一般的な「自分の作業を評価して」というプロンプトでは、汎用的な長所、控えめな注意点、楽観的なスコアが返ってきがちです。self-eval は、評価の水増しをしにくくする制約を加えます。必須の devil’s advocate reasoning、固定されたスコアリングマトリクス、そして .self-eval-scores.jsonl へのスコア保存です。

この保存が重要です。直近の評価が不自然に狭い範囲へ集中している場合、各レビューを単発のものとして扱うのではなく、スコアインフレの傾向として検出できます。

self-eval skill の使い方

self-eval のインストールとリポジトリ確認

GitHub の skill ソースから、利用している skill manager でインストールします。例:

npx skills add alirezarezvani/claude-skills --skill self-eval

関連するリポジトリ内のパスは次のとおりです。

engineering/skills/self-eval/SKILL.md

現在の構成では、外部依存、補助スクリプト、同梱ルール、参照ファイルはありません。インストール前に素早く確認するなら、まず SKILL.md を読んでください。そこにスコアリングモデル、ワークフロー、出力への期待値がまとまっています。プロンプトのみの skill なので導入リスクは低い一方、出力品質はタスク文脈をどれだけ十分に渡せるかに大きく左右されます。

skill に渡すべき入力

self-eval を有効に使うには、単に「これを評価して」と言うだけでは不十分です。完了した作業と、それをどの基準で判断すべきかをエージェントに渡してください。

有効な入力には、たとえば次のようなものがあります。

• 元のユーザー依頼または Issue の説明
• エージェントが作成した最終回答、パッチ、計画、レビュー
• 時間制限、スタイルルール、テスト要件、禁止されたアプローチなどの制約
• 実行したテスト、変更したファイル、実行したコマンド、既知の不足点などの検証証拠
• 想定読者: maintainer、reviewer、product owner、beginner user、production team など

弱いプロンプトはスコアだけを求めます。強いプロンプトは、「野心度は低いがきれいに完了している作業」と「野心度は高いが未完了の作業」を区別できるだけの証拠を skill に渡します。

よい結果を得るためのプロンプト例

self-eval は作業前ではなく、作業が終わったあとに使います。実用的なプロンプトは次のような形です。

Use the self-eval skill to evaluate the work below. Original task: [goal]. Output produced: [answer or diff summary]. Constraints: [tests, style, repo rules]. Validation performed: [commands or none]. Known concerns: [risks]. Give the two-axis evaluation, devil's advocate reasoning, final matrix score, and concrete follow-up actions.

この構造にすると、モデルが文体や努力だけを評価するのを防げます。評価時に、野心度、実行内容、証拠、未解決リスクを必ず考慮させられるからです。

おすすめのワークフロー

誤って楽観的な評価を受け取るとコストが高くなる節目で、self-eval を実行します。

1. タスクを完了する、または解決案のドラフトを作る。
2. 元の目標と作業証拠を添えて self-eval を依頼する。
3. 最終スコアの前に devil’s advocate セクションを読む。
4. 弱点を短い修正リストに変換する。
5. 見た目だけの修正ではなく、意味のある変更を加えたあとにだけ再実行する。

作業ディレクトリに .self-eval-scores.jsonl が作成された場合は、ローカルの評価履歴として扱ってください。そのファイルをコミットするのか、ignore するのか、定期的にレビューするのかをチームで決めておくとよいでしょう。

self-eval skill FAQ

self-eval は Model Evaluation 用ですか、それともコード品質用ですか？

どちらにも役立ちますが、意味は限定的です。self-eval for Model Evaluation は、ベンチマーク級のモデル測定ではなく、AI エージェント自身の作業に対するタスク単位の評価と捉えるのが適切です。セッション間の比較、自己評価のインフレ検出、レビュー規律の改善には役立ちますが、正式な eval harness、golden dataset、人間がラベル付けしたスコアリングの代わりにはなりません。

self-eval を使うべきでない場面

高リスクな作業の唯一のゲートとして使わないでください。たとえば、セキュリティ上重要な変更、法務・医療に関するコンテンツ、本番移行、検証済みの正しさが必要なものです。また、評価対象となる具体的な成果物がない場合も避けるべきです。この skill には、タスク、アウトプット、評価基準が必要です。それらがない場合でも構造化された出力は返りますが、根拠の弱い評価になります。

初心者にも使いやすいですか？

はい。プロンプトのみで動作し、ツール依存がないため使いやすいです。ただし初心者でも、使用前に SKILL.md、特にスコアリングロジックを読むことをおすすめします。学習コストの中心はインストールではありません。評価が雰囲気ベースにならないよう、十分な文脈を渡すことです。

批評を依頼するのと何が違いますか？

批評は、較正されたスコアなしに問題点を列挙できます。self-eval は 2 軸モデルとマトリクスに固定された最終スコアを使うため、エージェントが「なんとなく妥当に感じる」評価を後づけで正当化しにくくなります。さらに devil’s advocate のステップにより、最終判断を出す前に、より高いスコアとより低いスコアの両方を主張する必要があります。

self-eval skill を改善する方法

self-eval により強い証拠を渡す

self-eval の結果を改善する最善の方法は、証拠を具体的にすることです。変更したファイル、失敗または成功したテスト、重要な未対応事項、受け入れ基準を含めてください。テストを実行していないなら、そのことを明記します。意図的に要件を省いた場合も、それを含めてください。

よい入力とは、長い入力ではなく、評価可能な入力です。「認証コードをリファクタリングした」は弱い入力です。一方で、「auth/session.ts をリファクタリングして重複した token parsing を削除した。npm test -- auth を実行した。OAuth callback は手動テストしていない」と書けば、skill は実際に採点できる材料を得られます。

よくある失敗パターンに注意する

最も多い失敗は、モデルが成果ではなく努力を評価してしまうことです。もう 1 つは、難しいタスクで部分的に実行できただけなのに、自動的に高評価として扱ってしまうことです。self-eval はこれに抗うよう設計されていますが、ユーザーが元の野心度と実際の成果物を含めた場合に限って有効に働きます。

スコア履歴のノイズにも注意してください。.self-eval-scores.jsonl に無関係な種類のタスクが混在していると、クラスタリングのシグナルは意味を持ちにくくなります。ドキュメントの軽微な polish pass と複雑な migration は、同じ数値スコアを共有しているだけで同等だと解釈すべきではありません。

スコアから次のアクションへつなげる

最終スコアで止まらないでください。役に立つのは、野心度と実行品質のギャップです。そのギャップを修正プロンプトに変換します。

Based on the self-eval weaknesses, revise the work to address the top three execution gaps. Do not expand scope. Preserve the original constraints and report what changed.

これにより、次の反復作業の焦点を保てます。また、エージェントが高いスコアを狙って無関係な機能を追加し、「改善」したつもりになるのを防げます。

カスタマイズは慎重に行う

self-eval skill を調整する場合でも、較正を生み出す部分は残してください。分離された評価軸、devil’s advocate reasoning、固定されたスコア対応、スコア履歴への意識です。ラベル、出力形式、チーム固有の受け入れ基準をカスタマイズするのは通常問題ありません。一方で、モデルに自分自身へ反論させる制約を外すと、この skill は普通のレビュープロンプトに近い挙動になってしまいます。