「差し戻しループ」を人間から外す

AIに資料やコードを作らせるとき、多くの人が同じことをしています。出てきたものを見て、足りない点を指摘して、直させる。また見て、また指摘する。この往復が3回も続くと、自分でやったほうが早かったのではないかという気分になります。

この往復が発生する根本原因は、「完成の定義」がAIに渡っていないことです。人間の頭の中にはチェックリストがあるのに、それを言語化せずに「いい感じにやって」と投げているから、何度も戻ってくる。

Outcomesは、そのチェックリストを最初に渡してしまう仕組みです。Anthropicの Managed Agents に用意された機能で、次のように動きます。

1. あなたが「達成したいこと」と「採点基準（ルーブリック）」を渡す
2. エージェントが作業して成果物を作る
3. 採点役のAI（グレーダー）が、ルーブリックの各項目を独立に採点する
4. 不合格なら、どの項目が足りないかがエージェントに戻され、作り直す
5. 合格するか、回数上限に達するまで2〜4を繰り返す

成否の9割はルーブリックの書き方で決まる

実装は数十行で終わります。難しいのはルーブリックです。ここが曖昧だと、採点が毎回ブレて、ループが無駄に回るだけになります。

原則はひとつ、「各項目を独立に、機械的に判定できるか」です。グレーダーは項目ごとに個別採点するため、判断が主観に依存する書き方をすると評価が安定しません。

ルーブリックの実例

Markdownで書きます。見出しでカテゴリを分け、箇条書きで判定項目を並べる形式が扱いやすいです。

# 月次売上レポート ルーブリック

## データの正確性
- 集計期間が明記されており、指定された月と一致している
- 各数値に集計元のテーブル名またはファイル名が併記されている
- 合計値が個別項目の合算と一致している

## 構成
- 冒頭に3行以内の結論セクションがある
- 前月比・前年同月比の両方が記載されている
- 数値が悪化している項目には、推定原因が1つ以上添えられている

## 出力形式
- 単一の .xlsx ファイルとして出力されている
- 「サマリ」「明細」「前提条件」の3シートに分かれている
- 前提条件シートに、使用した為替レートと集計ルールが記載されている

ルーブリックは必須です。省略はできません。インラインのテキストとして渡すか、Files APIでアップロードして複数セッションで使い回すこともできます。

実装：セッションを作って完成条件を送る

エージェントと環境はあらかじめ作成済みとします（作り方は定期実行の記事のステップ1が同じ内容です）。

from anthropic import Anthropic

client = Anthropic()

RUBRIC = """# 月次売上レポート ルーブリック

## データの正確性
- 集計期間が明記されており、指定された月と一致している
- 各数値に集計元のテーブル名またはファイル名が併記されている

## 出力形式
- 単一の .xlsx ファイルとして出力されている
- 「サマリ」「明細」「前提条件」の3シートに分かれている
"""

# 1. セッションを作る
session = client.beta.sessions.create(
    agent=agent.id,
    environment_id=environment.id,
    title="2026年6月の売上レポート",
)

# 2. 完成条件を送る（これだけでエージェントは作業を開始する）
client.beta.sessions.events.send(
    session_id=session.id,
    events=[
        {
            "type": "user.define_outcome",
            "description": "2026年6月の月次売上レポートを .xlsx で作成する",
            "rubric": {"type": "text", "content": RUBRIC},
            "max_iterations": 5,       # 省略可。デフォルト3、最大20
        }
    ],
)

セッション作成と完成条件の送信は、1回のAPIコールにまとめることもできます。sessions.create の initial_events に user.define_outcome を1つ渡すだけです。定期実行のデプロイメントと組み合わせれば、「毎月1日に、ルーブリックを満たすレポートが自動生成されるまで作り直す」という構成が作れます。

max_iterations の決め方

デフォルトは3回、最大20回です。1回のイテレーションは「作業＋採点」なので、上限を上げるほどトークン消費が増えます。

実務上は、まず3回で回してみて、毎回上限に達するならルーブリックが厳しすぎるか曖昧すぎるかを疑うのが健全な使い方です。回数を上げる前に基準を見直してください。

進捗の読み方：3つのイベントと5つの結果

採点の進行はイベントストリームに流れます。通常の agent.* イベント（作業内容）に加えて、Outcomes専用のイベントが3種類あります。

肝心なのは span.outcome_evaluation_end の result です。ここで次に何が起きるかが決まります。

explanation には「12項目すべて合格。売上予測は5年分の実績を使用し…」のように、どの項目がなぜ合否だったかの要約が入ります。これがそのままエージェントへのフィードバックになり、次の周回の改善指示として使われます。

ポーリングで状態を見る

ストリームを常時つないでおけない場合は、セッションを取得して確認できます。

session = client.beta.sessions.retrieve(session.id)

for outcome in session.outcome_evaluations:
    print(f"{outcome.outcome_id}: {outcome.result}")
    # outc_01a...: satisfied

採点が完了するまでの間、result は pending / running / evaluating のいずれかを返します。これらは「まだ途中」を意味するので、終了判定に使う値（前掲の5つ）と混同しないよう注意してください。

成果物を受け取る

エージェントはサンドボックス内の /mnt/session/outputs/ に出力ファイルを書きます。セッションがidleになったら、Files APIをセッションIDでスコープして取得します。

# scope_id での絞り込みには managed-agents ベータの明示指定が必要
files = client.beta.files.list(
    scope_id=session.id,
    betas=["managed-agents-2026-04-01"],
)
for file in files:
    print(file.id, file.filename)

if files.data:
    content = client.beta.files.download(files.data[0].id)
    content.write_to_file("/tmp/report.xlsx")

また、idleになった直後はファイルのインデックスに1〜3秒の遅延があります。一覧が空だった場合は少し待ってから再試行してください。

運用ルール：知らないと詰まる4点

1. 同時に扱えるOutcomeは1つだけ

複数の完成条件を並行して走らせることはできません。順番につなぐ（チェーンする）ことは可能で、その場合は前のOutcomeの終端イベント（satisfied / max_iterations_reached / failed / interrupted のいずれか）を待ってから次の user.define_outcome を送ります。セッションの履歴は引き継がれます。

2. 途中で口を出すことはできるが、必要ない

作業中に user.message で方向修正を送ることは可能です。ただし「そのまま続けて」といった催促は不要です。エージェントは終端に達するまで自律的に回り続ける設計なので、催促のメッセージはトークンを消費するだけになります。

3. 中断は「一時停止」ではなく「そのOutcomeの終了」

user.interrupt を送ると、進行中のOutcomeは result: "interrupted" として終了し、セッションはidleになります。再開ではなく、新しいOutcomeを定義し直すか、通常の会話として続けることになります。

なお、採点が始まる前に中断した場合、outcome_evaluation_start_id が空文字列になります。この値をキーにして何かを引くコードを書いていると落ちるので、空チェックを入れてください。

4. failed が出たら回数ではなく設計を疑う

failed は「頑張ったけど届かなかった」ではありません。ルーブリックが成果物に対して適用不能という判定です。典型的には、description で頼んだものとルーブリックの採点対象が食い違っているケースです。

たとえば「CSVを作って」と依頼しているのに、ルーブリックが「.xlsxの3シート構成であること」を求めている、といった矛盾です。max_iterations を増やしても解決しません。

Outcomesが向く仕事・向かない仕事

判断基準はシンプルで、「合格・不合格を、人が見なくても判定できる条件に書き下せるか」です。書き下せないタスクにOutcomesを使うと、採点がブレて回数を消費するだけになります。

Vertex AI・Bedrock経由のClaudeでは使えない

「うちはGoogle CloudのVertex AI（Agent Platform）でClaudeを使っている」「AWSのBedrock経由で契約している」というケースは多いはずです。結論から書くと、Managed Agentsはこれらのプラットフォームでは利用できません。Anthropicの公式ドキュメントに、サポート対象外として明記されています。

なぜ使えないのか

Managed Agentsが「モデルを呼び出すAPI」ではなく、エージェントの実行ループとサンドボックス環境そのものをAnthropicがホストするサービスだからです。Vertex AIやBedrockが提供しているのは推論（Messages API）であって、Anthropic側のコンテナやスケジューラではありません。

同じ理由で、これらのプラットフォームではFiles API・コード実行・Agent Skills・MCPコネクタ・Message Batchesなども対象外です。Vertex AI・Amazon Bedrock・Microsoft Foundryそれぞれの公式ドキュメントに、いずれも「サポートされない機能」の一覧としてClaude Managed Agentsが挙げられています。

Vertex AI・Bedrockのままで近いことを実現するには

「基準を渡して自己採点させる」という考え方自体は、Messages APIだけで再現できます。構造化出力（structured outputs）はVertex AI・Amazon Bedrockでも利用できるため、次の3段構えを自分で組む形になります。

1. 作業用の呼び出しで成果物を作らせる
2. 別の呼び出しで、ルーブリックと成果物を渡して採点させる。構造化出力で合否と理由をJSONで返させる
3. 不合格なら理由を添えて1に戻る。合格または上限回数で終了

GRADER_SCHEMA = {
    "type": "object",
    "properties": {
        "passed": {"type": "boolean"},
        "failed_criteria": {"type": "array", "items": {"type": "string"}},
        "explanation": {"type": "string"},
    },
    "required": ["passed", "failed_criteria", "explanation"],
    "additionalProperties": False,
}

# 採点は「作業とは別の呼び出し」にするのが肝心。
# 同じ会話の続きで採点させると、自分の実装意図に引きずられて甘くなる。
verdict = client.messages.create(
    model="claude-opus-5",
    max_tokens=4096,
    system="あなたは採点者です。提示されたルーブリックの各項目を独立に判定してください。",
    messages=[{
        "role": "user",
        "content": f"# ルーブリック\n{RUBRIC}\n\n# 成果物\n{artifact}",
    }],
    output_config={"format": {"type": "json_schema", "schema": GRADER_SCHEMA}},
)

失われるのは「採点役が自動で用意される」「別コンテキストであることが保証される」「イテレーション管理が自動」の3点です。特に2つ目は自分で気をつける必要があります。作業した会話の続きで採点させると、実装の経緯が文脈に残っているぶん判定が甘くなるため、採点は必ず新しい呼び出しとして分離してください。

一方で利点もあります。採点ロジックを自分で握れるため、AIによる判定だけでなく、機械的な検証を採点に組み込めます。テストの実行結果、リンターの出力、JSONスキーマ検証などを先に走らせ、それらを通ったものだけAIに渡す構成にすれば、採点の安定性はManaged Agentsより高くなることさえあります。

よくある質問

まとめ

今日やれる最初の一歩は、「直近で3回以上差し戻したAIの成果物を1つ思い出し、その3回で自分が指摘した内容を箇条書きにする」ことです。それがそのままルーブリックの原型になります。指摘が「なんとなく違う」だったなら、まだ言語化が足りないというサインです。