Define outcomes は「終わったはず」を rubric と grader で検査可能にする

要点

要点まとめ

このページで重要なのは、AI に『終わった』と言わせるだけでは仕事完了の証明にならないと明示している点だ。
問題は二つある。AI は足りないまま完成と思いがちで、人間側も担当者ごとに採点基準がぶれやすい。
公式はそのズレを減らすために、何を満たせば合格かを書いた rubric と、別の判定役である grader による見直しループを用意している。
つまり本体は新しい機能名ではなく、完成条件を会話の外に出し、未達なら機械的に差し戻せるようにする設計だ。

続けて読む

読み終えたら次へ

この1本で終わらせず、同じ目的・同じテーマ・近い原典へ進めます。

同じ目的で読む 品質を見たい

AI の良し悪し、劣化、評価方法を見たい人向け。

同じテーマで読む AIエージェント

ツール利用、MCP、Agent SDK、長時間タスク、実行責任の設計。

次の記事 LangSmith の evaluation concepts は「評価を本番前だけで終わらせるな」と教える

AI の評価は公開前のテストだけでは足りず、本番で起きた失敗を拾って次の事前テストへ戻す循環まで作って初めて役に立つ。

読解

何が変わったのか

原典は `outcome` を、会話を仕事へ引き上げる定義として扱っています。単なる目標文ではなく、何を done とするかまで含めた仕事の枠です。そして rubric はその判定に使う採点表で、optional ではなく required です。さらに grader は main agent と別の context window で成果物を見て、`needs_revision`、`satisfied`、`max_iterations_reached` などの形で結果を返します。完成判定を AI の自己申告や人の気分から切り離す点が本質です。

日本の文脈

なぜ重要か

日本語圏では『agent に依頼すれば勝手に完成する』という期待が残りやすいですが、実務で危ないのは done 条件が曖昧なまま成果物を流すことです。成果物の質は model の賢さより、何を満たせば合格かを外に書けているかでかなり決まります。PM や創業者にとっても、人間レビューをゼロにする話ではなく、毎回ゼロから採点する負荷を下げる構造として読む価値があります。

技術ポイント

技術的ポイント

`user.define_outcome` は outcome 開始イベントであり、description に加えて rubric を渡し、必要なら `max_iterations` を設定する。
rubric は per-criterion scoring を書いた採点表で、inline text でも Files API でも渡せる。required なので『ざっくりやって』運用とは相性が悪い。
grader は main agent とは separate context window を使い、作業中の流れに引きずられず成果物自体を rubric に照らして評価する。
`span.outcome_evaluation_*` events で iteration loop を観測でき、`satisfied`、`needs_revision`、`max_iterations_reached`、`failed`、`interrupted` が次の流れを決める。
session 完了後の deliverables は `/mnt/session/outputs/` に書かれ、Files API で取得する。結果回収と outcome 判定も分離されている。

用語

英日キーワード

英語	日本語	補足
outcome	完成条件付きの目標	何を done とするかまで含めた仕事の定義。依頼文だけでは曖昧になりがちな完了条件を外出しする。
rubric	採点表	成果物を何で評価するか書いた基準文書。managed agents では required として扱われる。
grader	採点役	rubric に照らして成果物を評価する別系統の判定役。agent 本体の自己申告をそのまま信じないために置く。
iteration loop	反復修正ループ	評価して直し、再評価する周回。完成条件未達を機械的に差し戻す。
needs_revision	要再修正	rubric 未達のためもう一周修正が必要な状態。
satisfied	条件充足	rubric を満たし、完了として受け取れる状態。

試す

試すなら

1 つの agent 作業を選び、『できたら嬉しいこと』ではなく『満たしていなければ差し戻す条件』を rubric に書き出す。
rubric は 3 から 5 個の判定基準に絞り、各基準が観察可能か確認する。曖昧な美辞麗句では grader が機能しない。
`needs_revision` が返った時に何を直すかを explanation から追えるか確認し、人間レビューの怒号ではなく iteration loop へ戻す。

注意

注意点

rubric が悪いと grader も悪くなる。観察不可能な基準や矛盾した条件を書くと `failed` に落ちうる。
iteration があるから放置してよいわけではない。`max_iterations_reached` まで行くなら、task 定義か rubric の粒度が悪い可能性を疑うべきだ。

この記事は役に立ちましたか

公益的に続けるため、役に立った点や読みづらかった点だけを短く送れます。メールアドレスは不要です。