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の二層構造
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%の作業の重さを決めます。