grade-system

グレード評価システム

Ane の MEL／SRHR システムについて、実質的な品質および信頼性の評価を行います。レターグレード、次元別分析、OECD-DAC を応用した評価基準、具体的なリスク、グレード向上に向けた推奨事項を含む Tier 1 の作業ブリーフを出力します。率直に評価してください。自己評価バイアスも明示します。

使用するタイミング

• Ane が /grade-system、/grade と入力した場合、またはシステムの品質について尋ねた場合
• 定期的な品質レビュー（推奨頻度：月次、または大規模なバイアス修正作業の後）
• システムを率直に説明する必要があるステークホルダーへの伝達の前
• 大幅なシステム変更の後、グレードが変化したかを評価する場合

必須の自己評価バイアスに関する注記（出力に必ず含めること）

あなたはシステムを評価すると同時に、そのシステムの内部で稼働しています。2026-05-06 の mel-system-bias-audit によれば、LLM-as-Judge 効果により、自身の推論パターンに合致する出力やアーキテクチャを高く評価しやすくなっています。この点を出力で率直に明示してください。このグレードはシステム内部での較正であり、外部検証ではありません。構造的なテスト（コミュニティ／外部の MA 実務者によるレビュー）は、このシステムがまだ実施を認めていないテストです。

この注記は必須です。省略すると、グレードは誤解を招きます。

ワークフロー

ステップ 1 — 実証的な根拠を集める

並行して以下を読みます。

• agent-improvements/ann-overlay.md（Active + Archived）— 費用の数値、ハーネスの状態、重要な学びを含む振り返りの箇条書きを抽出します。セッション数を数えます。重大なインシデント（例：DOCX の切り詰め、em ダッシュのリグレッション）を記録します。
• agent-improvements/coordination-log.md — 摩擦が生じた事象と、そのステータス（OPEN／CLOSED）を確認します。
• agent-improvements/cost-calibration-log.md — 実測値がある行と not observed の行を数えます。⚠️ 予算帯を超過した項目に注目します。
• agent-improvements/qa-rejection-log.md — データ行を数え、判定の傾向を確認します。これは稼働中の QA テレメトリ信号です。表が空なら、改善ループは逸話に基づいて調整されていることを意味するため、リスクとして指摘します。qa-disagreement-log.md は過去の記録にすぎません。2026-07-30 に稼働中のカウンターとして廃止され（system-audit item #12）、測定不能として Vi／Li の格上げを監視するトリガー（3 行）は撤回されました。廃止の理由については、同ファイルのヘッダーノートを読んでください。その行を監視トリガーとして数えてはいけません。表に行があっても、傾向分析に使えるデータがない場合があります。 ログのプロトコルでは、⚠️ PILOT または ⚠️ SMOKE TEST のタグが付いた行は、すべて却下率の傾向分析から除外されます。そのため、傾向分析の対象となる行を別途数え、行の総数ではなく、その数を報告します（grep -E '^\| 2026-' <log> | grep -vc -E '(PILOT|SMOKE TEST)'）。2026-08-15 には 10 行すべてに除外タグが付いていたため、表にはデータがあるように見えても、測定可能な信号はゼロでした。外部による構造的なテストは、引き続き未実施です。
• 監査履歴 — glob で検索しないでください。大半は別の場所に移動しています。 agent-improvements/system-audit-*.md に一致するのは 2026-04-28 のアーキテクチャ監査ファイル 1 件だけです。ベースラインとして読む価値はありますが、最近のものではありません。agent-improvements/audit-drift-*.md に一致するのは週次シリーズですが、2026-08-05 に廃止されました（Ane の決定によるものです。ハーネスがそのチェックを引き継ぎ、/system-audit が必要に応じて判断の評価を行います）。したがって、最新ファイルは現状の評価ではなく、締めくくりの記録です。最近の監査結果は agent-improvements/handoffs/（たとえば、ロックされた決定事項のセクションがほかのどこにもない system-audit-follow-ups.md）と agent-improvements/improve-system-runs.md にあります。ファイル名を推測するのではなく、python scripts/handoff_status.py を実行して現在の一式を確認してください。
• mel_wiki/wiki/index.md — ページ数（フレームワーク、概念、指標、レンズ）を確認します。
• agent-improvements/agent_registry.md — 専門エージェントの数を数え、~/.claude/agents/ と照合します。
• 静的状態を確認するため python tests/run_tests.py を実行し、フィクスチャのカバレッジを確認するため python tests/run_tests.py --output を実行します。

ステップ 2 — コンポーネントごとの評価を付ける

評価尺度：A／A−／B+／B／B−／C+／C 以下。印象ではなく、ステップ 1 の証拠を使います。

コンポーネント	検討事項
Ann（招集役）	7 段階ワークフローの整合性、振り返りの規律、コスト見積もりの精度、複雑度分類の実績、Vi／Li のオーケストレーション上限
Vi（オーケストレーター）	SELECT → DELEGATE → REVIEW → COMPILE のフロー、調整プロトコル、レジストリとのモデルルールの整合性、コンテキスト内スキルの上限、分類表の網羅性
Li（ナレッジマネージャー）	オペレーションの幅（10 ops：QUERY、INGEST-FROM-RESEARCHER、INGEST-AD-HOC、INGEST-DOCUMENT、CATALOG、OVERLAY-DIGEST、LINT、CURATE、SYNC-CLAUDE-AI、REORGANIZE）、CURATE の品質（実質的な整理か、アーカイブのみか）、ティア別の分岐を伴う取り込み、四半期ごとの多言語目標
Researcher（エビデンス統合）	2 成果物プロトコル、ティアタグ付きソース分類、多言語のライブ検索ルールの運用状況、外部検索の検証状況
Specialist（レジストリから数を確認）	エージェントファイル数の一致、キャリブレーションアンカーの網羅性、レジストリと Vi の一貫性、モデルデフォルトの規律
Wiki	ページ数、YAML フロントマターの規律、em ダッシュ数の推移、P1／P2／P3 の優先度に関する規律、双方向の相互参照
テストハーネス	静的チェック数、フィクスチャの網羅性、回帰防止の幅
qa_block スキーマと Ann の PHASE 5 ゲート	フィールド単位の検証が機能しているか、スキーマと実装の一貫性、最近の追加項目（power_shift_check、external_review_check）が統合されているか
3 リポジトリ構成	claude-config + personal-skills + anework-package — 復元経路、ミラークローン、同期の抜け、移行の堅牢性

各コンポーネントに評価を付け、根拠となる証拠ファイルを示した 1 行の理由を記載します。

ステップ 3 — 評価軸ごとの評価を付ける

評価軸	測定する内容
正確性	引用の正確さ、フレームワークのバージョンの最新性、レンズの適用
信頼性	実行ごとの品質の一貫性、障害モードの実績
堅牢性	適切な縮退動作、自己検出、スキルフォールバックの告知
効率性	出力に対するトークンコスト、可観測性の表面
保守性	ドリフトへの耐性、信頼できる唯一の情報源、復元経路
誠実さ／評価の適切さ	データ不足の明示、再帰的な限界の認識
対象者ティアの使い分け	ティア 1 の作業ブリーフ／ティア 2 の公開向け資料／ジュニア MEL 向け経路が機能しているか
レンズの実質的な適用	フェミニズム、脱植民地主義、交差性が実際に適用されているか、形だけか
権力への認識	立場性、知識の出所、誰が問いを形作るか
実証的な証拠基盤	設計上の主張を裏付ける実際の本番実行の数

各評価軸に評価を付けます。どの評価もステップ 1 で収集した証拠で裏付けられる必要があります。具体的な証拠なしに A を付けず、具体的な不足なしに C を付けないでください。

次に、グラフ構造に関する 2 つの問いに明確に答えます。オーケストレーションはエージェントグラフ（ジョブ、矢印、共有状態ファイル、チェッカー、人的ゲート）です。両方の回答を「信頼性」評価に反映し、「いいえ」があればステップ 5 のリスクとして挙げてください。

1. すべてのチェッカーが書き手から分離されていますか？ qa-reviewer と reader-position-reviewer には設計上 Write／Edit ツールがありません。この状態が維持されていること、また新たに追加されたレビュー担当者や QA スキルも書き込みをせずにレビューすることを確認してください。レビュー対象を編集できるチェッカーは、文章の質にかかわらず、グラフ上の欠陥です。
2. 各人的ゲートは、都合のよい場所ではなく、ミスのコストが高い場所に置かれていますか？ Ane の承認が求められる箇所（計画の承認、公開前、上書き前）を、実際にミスが Ane にコストをもたらす箇所（外部向けの送信、破壊的な書き込み、寄付者に見えるコンテンツ）と照らし合わせて整理してください。コストが低い段階にゲートがあり、コストが高い段階にはない場合は、配置ミスです。Run 4 で意思決定後の Q&A が超過したのは、この問題の表れでした。

ステップ 4 — OECD-DAC の6基準を適用する

2019年の6基準フレームワークをシステムの状況に合わせて適用します。

基準	適用した意味
妥当性	Ane の実際の MEL／SRHR 業務に役立っていますか？
一貫性	各要素は互いに適合していますか？
有効性	出版可能な水準の成果物を作成していますか？
効率性	トークンコストと出力品質のバランス
インパクト	ベースラインと比べて、Ane の生産性や出力品質は変化していますか？反実仮想データがなければ、「証拠不十分」となることがよくあります。
持続可能性	保守性、ドリフトへの耐性、依存関係の堅牢性

ステップ 5 — 具体的なリスクを3つ挙げる

欠陥をリスクとして挙げる前に、その欠陥が存在する箇所を開き、現在も残っていることを確認してください。 ログの行、オーバーレイの判定、qa_block は、修正のきっかけとなったインシデントを記録したものであり、現在の状態を示すものではありません。すでに修正が反映されている可能性があります。証拠（2026-10-14、パス9）：リスク3では、2026-08-14 の qa-rejection-log の行を根拠に、word_count.writer の null 欠陥が未修正だと述べていました。しかし、qa-block-schema.md には 2026-08-10 から修正が反映されており、2026-08-14 には Ann のステップ11、Vi スキル、qa-reviewer エージェントにも展開され、ハーネスのチェックでその分岐が保護されていました。ブリーフの作成前にスキーマを1回確認すれば見つけられたはずです。また、誤った採点によって、影響を受ける項目の評価も約半段階厳しくなっていました。ケース登録簿は履歴です。評価は実際の状態を示す箇所に基づいてください。

影響度順に、妥当なリスクを3つ挙げます。それぞれに以下を含めます。

• 説明（1文）
• 重要である理由（1文）
• 実施中の緩和策（あれば）
• 解消につながること

例：2026-05-06 の評価から、Ane が指摘せずに受け入れる qa-reviewer の見解の相違、トークンコスト見積もりの不透明さ、自己導出型のバイアス補正ロードマップ。

ステップ 6 — 外部の MA 評価者が依然として求めること

システムが自らの境界内では満たせない項目を挙げます。

• IPPF の外部にいる MA 実務者がレビューした qa_block 出力のサンプル
• 反実仮想データ（ベースラインと比較した生産性）
• qa-reviewer が Tier 2 の出力について外部レビューが欠けていると指摘し、実際に公開が遅れた最初の事例
• 複数国で活動する humanitarian-srhr-specialist の実績（ここでは Opus の上書き条件が発動します）
• 非英語コンテンツの取り込みに関する四半期目標を2四半期連続で達成

ステップ 7 — 総合評価と提言

根拠を添えて、総合評価を1つ示します。評価を上げるための具体的な提言：

期間	実現可能な取り組み
今日（1～2時間）	コスト較正ログ、スキャフォールディング、フィクスチャを1つ取得
今週	最も頻繁に使われる P2 ページ10件の em ダッシュを一掃し、外部監査人に招待を送り、フィクスチャをさらに2つ取得
来月	外部の MA 実務者によるサンプル監査を実施し、多言語対応のギャップログに最初の3件を記録し、1種類のタスクについてコスト較正ログに実測値を5件以上記録
戦略的（期限なし）	Vi／Li を真のサブエージェントへ昇格させます。3行の不一致監視トリガーは、測定不能として 2026-07-30 に撤回されました。昇格には、実現前に新たな証拠経路（qa-rejection-log の傾向）が必要です

1日でできる取り組みと、構造的な上限を正直に区別してください。A−からAへの評価アップには、通常、外部監査人が必要です。

出力形式

Tier 1 の作業ブリーフ。BLUF を最初に示してください。構成要素／項目／OECD の評価には表を使います。率直な語調で、へつらわないでください。em ダッシュは使わないでください。曖昧な表現は避けてください。CLAUDE.md に従ってください。

次のテンプレートを使用してください。

# Quality and reliability grading — Ann/Vi/Li/Researcher + MEL/SRHR system

**BLUF: Overall [grade]. [One-sentence summary of strengths and ceilings.]**

## Self-grading bias note
[Mandatory paragraph explaining the LLM-as-Judge effect and that this is internal calibration, not external validation.]

## Per-component grades
| Component | Grade | One-line rationale |
|---|---|---|

## Per-dimension grades
| Dimension | Grade | What it means |
|---|---|---|

## OECD-DAC adapted
| Criterion | Grade | Comment |
|---|---|---|

## Three concrete risks
1. [risk + impact + mitigation]
2. [risk + impact + mitigation]
3. [risk + impact + mitigation]

## What an external MA evaluator would still want
- [bullet list]

## Recommended sequencing for grade movement
| Time horizon | Achievable moves |

## Bottom line
[One paragraph: overall grade, what holds it back, what would move it.]

**Evidence base:** [inline file paths]

してはいけないこと

• お世辞のような評価を付けないでください。システムには実際の上限があります。それを明記してください。
• 自己採点バイアスに関する注記を省略しないでください。この注記こそが規律です。
• 具体的なバグ修正を提案しないでください。それは /system-audit の範囲です。
• 証拠を捏造しないでください。ステップ1で実際に読んだソースファイルを引用してください。
• すべての項目に A 評価を付けないでください。具体的な証拠を示して A を正当化できない場合は、より低い評価にしてください。
• すべての項目に C 評価を付けないでください。システムは相当な取り組みを行っています。誠実な評価では、うまく機能している点も認めてください。

終了

「評価を上げるための具体的な推奨事項が必要ですか？」で締めくくります。Ane の返答を待ちます。

Ane が承諾した場合は、特定の評価軸を引き上げる具体的な1日でできる施策を2～3件提示します。今日実現可能なことと、構造上の上限があることを正直に伝えます。その後、実行するかどうかを尋ねます。

コスト帯

実際の観測値に基づいて調整した2つのパターンがあります。

• 評価のみの実施： 約40～80k（オーバーレイファイル、監査履歴、ハーネスの状態を確認）。
• 評価とフォローアップの実行： 約200k。観測された3回の実行（2026-05-10、2026-05-20、2026-05-22）はすべて、フォローアップの編集とコミットを追加した時点で、評価のみのコスト帯を2.5～5倍超過しました。スキルのみのツールを使っていても、COMPLEX-execution に分類し、約200kを作業上の見積もりとして扱います。

どちらのパターンもシステム改善の上限である200k以内に収まり、評価とフォローアップのパターンでは上限に達します。編集を行わず評価のみを実施する場合は、低いほうのコスト帯が適用されます。

評価よりも、情報収集の方法のほうがコストに大きく影響します。 Pass 7（2026-06-20）では、Step 1を4つのサブエージェントに分散し、サブエージェント側で約340kを消費しました。Pass 8（2026-07-24）では、直接 Read と Bash を呼び出して同じ証拠を収集し、フォローアップ施策2件とリポジトリ間の同期を含むセッション全体で約208kに収めながら、同じA−に到達しました。情報収集は原則として直接行ってください。ただし、次の2点には留意してください。これは n=1 対 n=1 の比較であり、Pass 8ではPass 7ですでに証拠の所在が把握されていた恩恵を受けた可能性があります。ファンアウトは無駄だという証明ではなく、「直接収集で一度は十分だった」と捉えてください。証拠の範囲が本当に未知の場合や、複数ページにわたるエムダッシュの検出のように、並列スキャン自体が実作業となる場合は、サブエージェントを活用してください。

相互参照

• /system-audit はバグを見つけ、/grade-system は全体的な品質の姿勢を評価します。全体像を把握するには両方を使います。まず監査を行って手早く修正できる問題を解消し、その後に評価します。
• agent-improvements/system-audit-2026-04-28.md は元となるアーキテクチャ監査で、評価軸にも引き継がれています。
• agent-improvements/external-calibration-auditor-invitation-draft.md は、外部構造テストを実施するための常設の招待文です。