W&B Weave は、Weights & Biases（以下 W&B）が LLM アプリケーションとエージェント向けに出したオブザーバビリティと評価のプラットフォームです。関数に @weave.op() を付けるだけでトレースが自動で取れ、weave.Evaluation でモデル・データセット・スコアラーをつなぐと、評価実行の結果がダッシュボードに実験として記録されます。
AI eval ツールの系譜で見ると、Weave は少し毛色が違います。多くの LLM オブザーバビリティ製品が「エージェント開発チーム向けの新興ツール」として立ち上がったのに対し、Weave は違います。ML 実験管理の老舗 W&B が、既存ユーザーの文脈を LLM 側に延長する形で出した製品です。この出自の差が、使い勝手と「どのチームに刺さるか」を決めています。
W&B との関係 — 実験管理の DNA
Weights & Biases はもともと、PyTorch / TensorFlow で深層学習モデルを学習しているチーム向けの実験管理 SaaS でした。損失曲線、ハイパーパラメータ、モデルの重み、評価メトリクスを wandb.log() で送れば、ダッシュボードに全部まとまる。学術研究から大規模 ML チームまで、2020 年代前半のデファクトです。
LLM 時代になり、評価の対象が「モデルの重みと学習ジョブ」から「プロンプト・ツール・エージェントのトレース」に広がりました。Weave はこの延長線上に設計されています。コアコンセプトは次の 3 つです。
- Traces — 関数呼び出しをツリー状に記録する。LLM 呼び出し・ツール使用・サブエージェントが入れ子で見える
- Evaluations — モデル × データセット × スコアラーの組み合わせで一括評価し、結果を実験として比較
- Objects — プロンプト、データセット、モデル定義を Weave の中にバージョン付きで保存
W&B 全体の思想と同じく、「ジョブを 1 回走らせたらそれが未来の自分と他人へのログになる」が通底しています。
なぜ ML 系チームに刺さるか
既に W&B を使って学習ジョブを管理しているチームにとって、Weave は追加の心理的コストがほぼありません。アカウントも UI も同じ画面の別タブで、組織の権限管理もそのまま。ファインチューニングと LLM アプリ評価を同じプラットフォームに置ける利点は、研究寄り・ML Ops が成熟しているチームほど大きく出ます。
逆に言うと、「アプリ側の開発チームが単独で LLM を使い始めた」ようなプロジェクトには少し重い印象もあります。これは後の節で LangSmith / Phoenix と比較します。
主な機能
Traces
@weave.op() デコレータを付けた関数は、呼び出しごとに入力・出力・時間・エラーが記録されます。LLM SDK（OpenAI, Anthropic, LiteLLM など）は自動計測されるため、素の openai.chat.completions.create もラップ不要で可視化されます。
ツリー構造が優秀で、エージェントの「ツール呼び出しの中からサブエージェントが呼ばれ、その中で LLM が 3 回叩かれた」というような深い入れ子でも、UI で折りたたんで追えます。OTel（OpenTelemetry）互換の取り込みもサポートされるようになっており、既存の分散トレーシング基盤から流し込む経路もあります。
Evaluations
評価は weave.Evaluation クラスを中心に組みます。モデル・データセット・スコアラーの 3 点セットで、evaluate() を呼ぶとデータセットの全行に対してモデルを走らせ、スコアラーを適用し、結果を 1 つの実験として保存します。
スコアラーは単純な関数、LLM-as-a-judge、組み込みの MultiTaskBinaryClassificationF1 のような汎用スコアラーを混ぜて使えます。実験は W&B のダッシュボード上で並べて比較でき、プロンプトを変えた、モデルを変えた、スコアラーを足した、といった差分を数値と行単位で追えます。
Datasets
評価用データセットは weave.Dataset としてバージョン付きで保存されます。CSV や JSONL から読み込み、プロジェクト配下に名前で公開しておけば、別の評価ジョブからも参照できます。本番トレースから「失敗した会話」を抽出してデータセットに追記するフローも、UI から直接できます。
Models
weave.Model は Pydantic 風のクラスで、プロンプトテンプレートやモデル名などのハイパーパラメータをフィールドとして持ちます。predict メソッドを @weave.op() で装飾しておけば、評価を走らせたときにどのバージョンのプロンプトでどんな入力に対してどんな出力が出たか、全部ひもづいた形で残ります。
Playground と Compare
Playground は UI 上で過去のトレース（または任意のメッセージ列）を取り出し、別モデルや別プロンプトで再実行できる場所です。LLM 呼び出しを 1 件だけ「このモデルに差し替えて再現したい」というケースに向いています。
Compare は評価実験同士を並べ、スコアの行列と、どの入力で結果が食い違ったかを見るためのビューです。回帰（regression）の切り分けはこの画面で行うことになります。
最小動作例
次のコードは、文章から果物の情報を抽出するタスクを Weave で評価する最小構成です。実際に動かすには pip install weave openai と OPENAI_API_KEY が必要です。
import asyncio
import json
import openai
import weave
weave.init("fruit-eval-demo")
class ExtractFruitsModel(weave.Model):
model_name: str
prompt_template: str
@weave.op()
async def predict(self, sentence: str) -> dict:
client = openai.AsyncClient()
response = await client.chat.completions.create(
model=self.model_name,
messages=[
{
"role": "user",
"content": self.prompt_template.format(sentence=sentence),
}
],
)
return json.loads(response.choices[0].message.content)
examples = [
{
"sentence": "Neoskizzles are purple and taste like candy.",
"target": {"fruit": "neoskizzles", "color": "purple", "flavor": "candy"},
},
{
"sentence": "Pounits are a bright green fruit.",
"target": {"fruit": "pounits", "color": "green", "flavor": "unknown"},
},
]
dataset = weave.Dataset(name="fruits", rows=examples)
weave.publish(dataset)
@weave.op()
def fruit_name_score(target: dict, output: dict) -> dict:
return {"correct": target["fruit"] == output.get("fruit")}
model = ExtractFruitsModel(
model_name="gpt-4o-mini",
prompt_template="Extract fruit, color, flavor as JSON from: {sentence}",
)
evaluation = weave.Evaluation(
name="fruit_eval_v1",
dataset=dataset,
scorers=[fruit_name_score],
)
asyncio.run(evaluation.evaluate(model))実行すると fruit_eval_v1 という実験が Weave のダッシュボードに現れ、2 行分の予測、正解、スコア、所要時間が並びます。プロンプトを書き換えて再実行すれば fruit_eval_v1 の 2 つめのバージョンが並び、Compare 画面で差分を見られます。
向くケース・向かないケース
向くケース
- 既に W&B を使って学習ジョブを管理している。アカウント・組織・権限を増やしたくない
- ファインチューニングと LLM アプリケーション評価を同じ場所でひもづけたい
- 研究寄りのチームで、評価実験そのものを論文の実験記録として残したい
- Python 中心、非同期・大量データで評価を回したい
向かないケース
- フロントエンド中心のアプリで、ネットワーク越しに素早くトレースを見たいだけ
- クラウド SaaS に送れないデータを扱っており、完全セルフホストが要件
- 評価より先にまずトレースだけ軽く始めたい（Phoenix のほうが初速が速い）
LangSmith / Phoenix との違い
同じ領域で比較されるのが LangChain の LangSmith と、Arize の OSS Phoenix です。ざっくり整理すると次のようになります。
- LangSmith は LangChain エコシステムとの統合が最も厚く、Chain / Agent の構造を前提にした UI が強み。SaaS 中心
- Phoenix は OSS でローカル起動が簡単、OpenTelemetry にフル準拠。実験管理より「開発中のデバッグビュー」寄り
- Weave は実験管理の DNA を引き継ぎ、評価を「W&B の実験」として保存することに重心が置かれている
Chain を書くなら LangSmith、まずローカルでトレースだけ見たいなら Phoenix、学習ジョブと評価を同じ場所に置きたいなら Weave、という住み分けが現状の実感です。
ハマりポイント
weave.init()を忘れると@weave.op()の装飾は無害ですが、トレースはどこにも送られません。CI でこっそりログだけ消えがちなので、エントリポイントでアサートしておくと安全です- 非同期関数と同期関数が混じる構成だと、
asyncio.run()の二重呼び出しでRuntimeError: This event loop is already runningを踏みがちです。評価はevaluation.evaluate(model)を awaitable として返すので、呼び出し側のイベントループに合わせます weave.Modelは Pydantic ベースなので、model_nameフィールドは Pydantic の protected namespace とぶつかります。警告が出たらmodel_config = {"protected_namespaces": ()}を足すか、フィールド名を変えます- データセットを
weave.publishせずにEvaluationに渡すと、評価は走りますが UI 側で「どのデータセット版か」が追えなくなります。回帰調査が面倒になるので、評価用データは必ず publish しておきます - トレースの PII マスキングは SDK の
postprocess_inputs/postprocess_outputフックで自前実装します。デフォルトはそのまま送るので、個人情報を扱うなら最初に設定します
価格・無料枠
W&B の料金体系に乗る形で、個人・学術向けには無料枠があります。チームプランから有料で、エンタープライズは専任サポート付き。Weave 単体の課金ではなく、W&B 全体の使用量（トレース数・ストレージ）で計算される建て付けのため、詳細は公式のプラン表を確認してください。セルフホスト（W&B Server）版は Weave の機能もサポートされていますが、エンタープライズ契約が前提です。
評価を回し始めるとトレース数が一気に増える点は注意が必要です。大規模データセット × 複数モデルの実験を日次で回すなら、月間のイベント数の見積もりを最初にやっておくと予算の事故が減ります。
まとめ
Weave は、評価を「W&B のもう 1 つの実験」として記録する発想のツールです。@weave.op() と weave.Evaluation の 2 つを押さえれば、トレースと評価が同じダッシュボードに乗る体験を素早く作れます。既に W&B の文化が根付いているチームにとっては、追加コストが小さく、学習ジョブと LLM アプリの往復がスムーズになる選択肢です。
逆に、LLM 用途から始まったチームが新たに Weave を入れる場合は、料金・SaaS 前提・W&B 全体の UI 複雑さを事前に見ておくと期待値が合います。LangSmith / Phoenix と並べて 1 日ずつ触り比べれば、どれが自分のプロジェクトの重心に合うかはすぐ分かるはずです。
関連記事
- AI エージェント評価サーベイ論文を読み解く
- AI の評価って何？なぜ難しい？
- AI エージェントの evaluation (evals) 入門
- AI eval ツール: Phoenix
- AI eval ツール: LangSmith
Singularity Society はテクノロジー集団として MulmoClaude / MulmoTerminal / MulmoCast を開発しています。エンジニア・起業家向けの実践プログラム BootCamp も運営しています。