Claude Media
Cresta Conductorの評価設計 — Agent SDK製のエージェント構築エージェントをどう測るか

Cresta Conductorの評価設計 — Agent SDK製のエージェント構築エージェントをどう測るか

Cresta Conductorは、Claude Agent SDKを土台にエージェントを作るエージェントです。成果物・実行経路・品質・資源消費の4観点評価と、新モデル出荷時の回帰確認までたどります。

カスタマーエクスペリエンス(CX)向けAIのCrestaは、2026年10月5日、自社の「Conductor」をClaude Agent SDKの上に作った経緯を公開しました。Conductorは、自然言語の指示から別のエージェントを設計・実装・評価・改善するエージェント(メタエージェント)です。

読みどころは、Conductor自身をどう測っているかです。Crestaは「タスクを完了したか」だけで採点せず、成果物・実行経路・品質・資源消費の4つの問いで見ています。この4観点は、自分のエージェントを評価する側にもそのまま持ち込めます。

Conductorとは何か — CX特化の制御層とSDKの実行基盤

Conductorは、Crestaが「自然言語のエージェントビルダー」と呼ぶ製品です。利用者が作りたいものを説明すると、根拠のある設計案(ブループリント)から実装、評価、最適化までを案内します。

Crestaは当初、Claude SonnetとClaude Opusを使った初期版を、社内チームが顧客導入を支援するために使っていました。それを顧客が直接使える製品にできるか、というのが出発点の問いです。

役割分担は次のとおりです。

くらべる

Conductorの二層構造

CX固有の層

Cresta側

会話データ、CXの専門知識、評価、ランタイム。ポリシー・可観測性・検証・フィードバックで各エージェントの実行を統制します。

汎用の実行基盤

Claude Agent SDK側

コンテキストの収集、ツール呼び出し、コードの記述と実行。CrestaのCXワークフローやツールは、この上に載せます。

SDKの位置づけは、公式ドキュメントの説明と合っています。Agent SDKは、Claude Codeと同じツール・エージェントループ・コンテキスト管理をPythonとTypeScriptから使えるライブラリです。

Crestaのエンジニアリングリードは、社内ではClaude Codeを開発ツールとして使っており、それと同じ開発ハーネスをプログラムから呼べるのがSDKだった、と述べています。SDKの採用前には、複数ステップ・大量のコンテキスト・繰り返しのツール使用というConductorの作業内容に照らして評価し、データプライバシー、テナント構成、組織単位のキー配布、統制、可観測性も確認したとのことです。

Crestaは、導入初期のユースケースでConductorにより初期デプロイ時間が約半分になったと報告しています。これは同社の自己申告の数値です。

4観点評価 — 完了だけを合格にしない

Conductorの評価は、まず「何をやらせるか」の固定から始まります。Crestaが回す構築タスクは4種類です。

  • 新しいエージェントを作る
  • 既存エージェントのテストケースを書く
  • 既存のエージェントを変更する
  • 根本原因を分析する

この各タスクを、次の4つの問いで採点します。

観点答える問い
成果物(Outcome)答える問い依頼どおりの、使える成果物ができたか
実行経路(Execution path)答える問い適切なツールと必要なコンテキストを使ったか
品質(Quality)答える問い人が整えた参照解と比べてどうか
資源消費(Resource use)答える問い時間とモデル使用量はどれだけかかったか

ポイントは、成果物が合っていても実行経路が悪ければ評価に出る点です。必要なコンテキストを読まずに、たまたま当たった出力は、次の入力で外れます。資源消費を軸に入れておけば、同じ品質でもコストが倍になる変化を見逃しません。

新モデルが出たら同じ問題で回し直す

Crestaは、この4観点のタスク群を安全網としても使っています。新しいClaudeモデルが出たときや、Conductorのフレームワークを更新したときに、同じタスク・同じ採点で評価をやり直します。何が良くなり、何がまだ足りないかを、変更を採用する前に確かめる運用です。

評価の対象を「モデル」ではなく「エージェント全体」に置くのも特徴です。成果物だけを採点すると、経路とコストの変化は拾えません。

評価をプロダクトの機能として載せる

Crestaは、評価をCresta社内の検証にとどめず、Conductorの機能にも入れています。構築の途中で出てきた要件やエッジケースを、評価モジュールのテストに変換する作りです。

利用者は、動き続けるべきワークフローを、ポリシー・接続先システム・会話パターンが変わる中でも監視できます。こうして、業務の変化に合わせてエージェントを更新しつつ、すでに固めたワークフローの信頼性を保ちます。

この考え方は、決定的に動くべき部分の切り分けともつながっています。Crestaの説明では、会話のすべてを分岐図で縛ると巨大な決定木になる一方、規制の強い業界では毎回確実に動かすべき業務フローがあります。Conductorは過去の会話から、人を介在させる箇所と、モデルに任せる箇所の境界を見つける手助けをします。境界が決まったら、固定したい部分を、強制したい要件に対してテストし、業務ルールの変更に合わせてテストも直すことになります。

さらに、構築で得た知見を再利用できる記憶の成果物にまとめ、スキルとしてチームに共有できます。パターン、業務ルール、評価の進め方がそこに入るため、次の構築が速く、揃ったものになります。

自分のエージェントに写す — 4観点を計測する最小の形

ここからは、Crestaの実装ではなく、同じ4観点を自作のエージェントで計測する場合の一例です。Agent SDKの公開機能でどこまで取れるかを確認すると、観点ごとに取得元が分かれます。

計測

4観点の計測元

  • 成果物と品質

    生成物を検査するコードか、参照解との比較で採点します。SDKの外側で書く採点器の領域です。

  • 実行経路

    フックで取ります。PostToolUseはツール実行の結果で発火し、PreToolUseとの対応付けにツール使用IDが使えます。

  • 資源消費

    resultメッセージのtotal_cost_usdやmodelUsageを読みます。

実行経路は、PostToolUseフックでツール名と入力を記録していけば、あとから「必要なファイルを読んだか」「禁止のコマンドを使わなかったか」を判定できます。フック全般の仕組みはAgent SDKのHooksの解説にまとめています。

次のTypeScriptは、1回の実行について、使ったツールの並びと費用を記録する骨組みです。

import { query, HookCallback } from "@anthropic-ai/claude-agent-sdk";
 
const toolTrace: string[] = [];
 
// ツール名を実行順に残すだけのフック
const traceTools: HookCallback = async (input) => {
  toolTrace.push((input as { tool_name: string }).tool_name);
  return {};
};
 
let costUsd = 0;
for await (const message of query({
  prompt: "対象ディレクトリのテストを追加して",
  options: {
    hooks: { PostToolUse: [{ hooks: [traceTools] }] },
  },
})) {
  if (message.type === "result") {
    costUsd = message.total_cost_usd;
  }
}
 
console.log({ toolTrace, costUsd });

資源消費を読むときの注意が3点あります。

  • total_cost_usdは、SDKが内蔵の価格表から手元で計算する推定値です。請求額とずれることがあり、課金の根拠にはなりません。
  • サブエージェントを使うと、usageにはその分が含まれません。ツリー全体のトークンはmodelUsage(Pythonではmodel_usage)で集計します。
  • 複数回のquery()を呼ぶときは、各結果が個別の呼び出し分です。セッションを再開した呼び出しは、それ以前の費用も加算されます。

モデルを入れ替えるときは、同じタスク集合を新旧のモデルで回し、4観点の差分を並べます。経路とコストの変化まで見える点が、成果物だけを採点するよりも判断材料になります。採点の設計そのものは、AIエージェントのEval設計が採点者の類型と非決定性への対処を詳しく扱っています。

構築より後が重い — Crestaの4つの教訓

Crestaは、自社のやり方から4つの教訓を挙げています。

Crestaが挙げた4つの指針

  • 自社製品を先に自分で使う。Conductorは社内ツールとして動かし、出力が深いAI知見を持つエンジニアの成果物に並んでから製品にした
  • 独自の強みに集中する。会話データとCXの理解は自社の領分とし、SDKで調達できるものは作らない線を引いた
  • 決定的にする部分を決める。止まってはいけない業務フローは固め、残りは柔軟にする
  • 本番到達は簡単な部分。初期構築は労力の2割ほどで、残り8割はその後のテスト・最適化・継続的な改善に当たる

最後の指針は、評価設計と直結します。評価の仕組みを後付けにすると、その8割の側で手探りになります。ツールの定義を評価で磨く考え方はエージェント向けツール設計の原則と、生成と評価を分ける構成はAnthropicのハーネス設計と通じる部分があります。

Conductorの記事に書かれていないこと

評価の仕組みを自作に写す前に、元記事の範囲を押さえておきます。

  • 4観点それぞれの採点方法、閾値、参照解の作り方は載っていません。数値の結果も公開されていません。
  • 新しいモデルを評価した結果の具体例や、モデルごとの比較は載っていません。
  • 導入が約半分になったという数値は、Crestaと提携先の初期ユースケースでの同社報告です。条件の内訳は記載がありません。
  • 使うモデルは、初期版でSonnetとOpusという記述にとどまり、現行のConductorの構成は示されていません。

Claude Agent SDKを自社プロダクトに組み込む際の制約として、公式の概要ページには注意書きがあります。承認がない限り、第三者の開発者は、Claude Agent SDK上のエージェントを含め、自社製品でclaude.aiのログインやレート制限を提供できません。代わりにAPIキー認証を使います。Conductorのような製品型の組み込みを考えるときは、この条件も前提になります。

まとめ

Conductorの評価で参考になるのは、タスクを固定して4つの問いで測り、モデルやフレームワークの変更のたびに同じ採点で回し直す、という運用の骨格です。完了だけを合格にしないことで、経路とコストの劣化が早く見えます。

自作のエージェントに写すなら、最初は実際に任せたい依頼を少数だけ選んで固定し、そのうち「必ず読むべきファイルがある」タスクから経路の記録を試すと、合否の線を引きやすくなります。評価を機能の一部として最初から設計に入れるかどうかが、公開後の80%の作業の重さを決めます。

この記事を共有:XはてブLinkedIn