Define outcomes は「終わったはず」を rubric と grader で検査可能にする
このノートは原文の代替ではありません。読むべきポイントと実装上の意味を整理し、原典への入口を示します。
要点まとめ
- このページで重要なのは、AI に『終わった』と言わせるだけでは仕事完了の証明にならないと明示している点だ。
- 問題は二つある。AI は足りないまま完成と思いがちで、人間側も担当者ごとに採点基準がぶれやすい。
- 公式はそのズレを減らすために、何を満たせば合格かを書いた rubric と、別の判定役である grader による見直しループを用意している。
- つまり本体は新しい機能名ではなく、完成条件を会話の外に出し、未達なら機械的に差し戻せるようにする設計だ。
何が変わったのか
原典は `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 の粒度が悪い可能性を疑うべきだ。