Engineering · アーキテクチャ
ルーブリック駆動の自己検証ループ — Outcomes パターン
エージェントの出力を、別の独立したコンテキストウィンドウで動くグレーダーが採点する——これが Outcomes パターンの核心です。推論の過程を知っている評価者は出力品質を正しく測れないという根本問題に対し、コンテキスト分離で答えを出します。
要点
- ✓Outcomes は「何をすべきか」ではなく「どうなれば成功か」を先に宣言するパラダイム
- ✓グレーダーを独立した CTX で動かすと、タスクエージェントの推論過程に汚染されない評価になる
- ✓Anthropic 内部ベンチマーク：Word 文書品質 +8.4%・PowerPoint 品質 +10.1%（Managed Agents 公開ベータ、2026年5月）
- ✓ループは「合格」「予算超過」「明示的不合格」の 3 状態で終了し、無限ループを防ぐ
- ✓コード・文書・スライドなど任意のアーティファクトに適用できる汎用パターン
「エージェントは自分の出力を正確に評価できているか。」これは多くの本番運用で顕在化している問題です。エージェントが生成過程で積み上げた推論の文脈は、同じコンテキストウィンドウ内で評価をさせると「汚染源」になります。「なぜそう書いたか」を知っている評価者は、実際には書かれていない内容を補って読んでしまい、見落としを見落としたまま合格と判定してしまうことがあります。
同じ現象は人間の知的作業でも知られています。自分の論文を自分で読み返すと、執筆時の意図が投影されて実際には存在しない論理が「あるように見える」——これはレビュー行為の本質的な限界です。AIエージェントも同じ構造を持ちます。推論の流れを引きずった自己評価は、盲点を生みやすい。
Outcomes パターンの全体構造
タスクエージェントとグレーダーの分離
Outcomes パターンの核心は、評価（グレーダー）をタスクエージェントとは完全に独立したコンテキストウィンドウで実行することです。グレーダーが受け取るのは最終アーティファクト（文書・コード・スライドなど）だけで、タスクエージェントの中間思考・ツール呼び出し履歴・部分出力はいっさい渡りません。
（B）この分離が有効な理由は、グレーダーが「白紙の状態」でアーティファクトを見るからです。ルーブリックの各基準と出力を突き合わせる際、タスクエージェントの意図を知らずに判定できます。「書き手の言いたいことはわかる」という補完が起きず、書かれていないものは評価されません。人間のピアレビューが自己レビューより信頼できる理由と同じ構造です。
ルーブリックの書き方
ルーブリックは「どうなれば合格か」を自然言語で記述した成功の定義です。重要なのは、各基準が判定可能（verifiable）であることです。「質の高い文章」「わかりやすい説明」といった抽象的な言い回しでは、グレーダーが一貫した判定を下せず、ループが意味のない形で収束するか、まったく収束しなくなります。
判定可能な基準は「出力を見れば確認できる」性質を持ちます。例：「各セクションの冒頭に主題文がある」「引用がすべてインライン脚注で示されている」「結論が 200 字以内に収まっている」「コードに型アノテーションがすべて付いている」。スコープを明確にすること（「全体として」より「第3段落では」のように範囲を限定する）と、優先順位をつけること（必須 MUST / 品質向上 SHOULD）が、グレーダーの判定を安定させます。
判定可能な基準の3要素
①「観察可能」——出力を見るだけで判定できる。×「良い文章」○「段落の先頭に主題文がある」。②「スコープが明確」——「全体として」より「第3段落では」のように範囲を限定する。③「優先順位付き」——MUST（必須）と SHOULD（品質向上）に分け、グレーダーが重み付け判定できるようにする。
イテレーション予算と終了条件
Outcomes パターンはループですが、終了条件を明示しなければ意図せず無限反復に陥ります。実用実装では「イテレーション予算」（最大繰り返し回数 N）を設定し、ループを3つの状態のいずれかで確定させます。①合格——グレーダーがルーブリックの全基準をクリアと判定。②予算超過——N 回の反復後も合格に達しなかった（N を超えた時点で強制終了）。③明示的不合格——グレーダーが「このアーティファクトは基準を満たせない」と判断したとき。
フィードバックの粒度もループ収束の速度を左右します。「改善してください」という曖昧な指示より、「第3段落の主語が不明確です。主題文を 30 字以内で先頭に追加してください」のような具体的な差分指摘のほうが、次のイテレーションで確実に収束します。ルーブリックの記述粒度がフィードバックの粒度を決めるため、ルーブリックを細かく書くほどフィードバックも具体的になります。
実測値と適用範囲
Anthropic が Code with Claude 2026（2026年5月6日）の基調講演で示した内部ベンチマークでは、Outcomes を用いた場合に Word 文書品質で +8.4%、PowerPoint 品質で +10.1% の改善が確認されています（通常プロンプティングとの比較）。改善は複数ステップを要する長い文書・スライド作成タスクに集中し、単純な要約や短い生成タスクでは効果が小さい傾向がありました。
一方、コストのトレードオフも存在します。グレーダーが独立したコンテキストウィンドウで動くため、1 タスクあたりのトークン消費はタスクエージェント単体より多くなります。短い単発生成では検証ループのオーバーヘッドが品質向上を上回ることがあります。Outcomes パターンの効果対コスト比が最も高いのは、複雑なアーティファクト（長文ドキュメント・スライドデッキ・コードファイル群）の生成です。
🛡 ルーブリックの質が品質の上限を決める
ルーブリックが曖昧・抽象的だとグレーダーも一貫した判定を下せず、ループが収束しないか、誤った合格を返します。Outcomes を本番に投入する前にルーブリック自体をレビューする工程を設けること、そして初回は小さなスコープで試すことが推奨されます。
agens での位置づけ
（B）一般的なパターンとして、Outcomes は「生成役と評価役の分業」を体現する generator-evaluator パターン（→ 生成役と評価役の分業）の具体実装のひとつです。generator-evaluator パターンが「生成役と評価役を別のエージェントに割り当てる」構造を定義するのに対し、Outcomes は評価役を「独立した CTX で動く専用グレーダー」として実装し、評価基準をルーブリックとして形式化するという 2 点を設計決定として明示します。
（B）Outcomes パターンの考え方——「手順ではなく成果基準を宣言する」「評価者の文脈を独立させる」——をワークフロー設計に組み込むと、長文ドキュメント生成・スライド作成・レポート分析などのタスクで反復的な品質向上が実現しやすくなります。エージェント評価（→ エージェント評価の設計）と組み合わせることで、オフラインの品質測定とオンラインの自己検証ループの両輪が揃います。
よくある質問
generator-evaluator パターンと何が違うのですか？
ルーブリックは何文字くらいで書けばよいですか？
イテレーション回数の目安はどのくらいですか？
最終更新: 2026-06-15