# Weights & Biases Weave：AIアプリケーションのトレーシング・評価・運用観測 CURRENT_STATUS: CURRENT OBSERVATION: SPEC_ONLY FRESHNESS: CURRENT PAGE_TYPE: reference CANONICAL_URL: /tools/ea-173-weights-biases-weave-ai CLAIM_IDS: none EVIDENCE_IDS: EVD-EA-173-URL-3C94D1F5D485, EVD-EA-173-URL-89A1C3EDCDD1, EVD-EA-173-URL-6F44C68791F2, EA-173-CURRENT-APPROVAL, EA-173-CURRENT-BODY-READBACK UNKNOWN_IDS: EA-173-UNKNOWN-01 OPS_IDS: none ## Summary 「Weights & Biases Weaveは、AIエージェントやLLMアプリケーションの実行をトレースし、評価・フィードバック・性能／費用観測へ接続するための基盤として利用できる。ただし、記録されたtraceはinstrumentationと送信条件の範囲での観測であり、実行の完全性を自動的に保証しない。評価結果もdataset、scorer、model、prompt等のversionと適用範囲に依存する。Enterprise利用では、機密情報の収集制御、権限・retention、self-hostedのpatch管理、trace欠測、scorer calibrationを別途監査する。」 ## Current judgment 「Weights & Biases Weaveは、AIエージェントやLLMアプリケーションの実行をトレースし、評価・フィードバック・性能／費用観測へ接続するための基盤として利用できる。ただし、記録されたtraceはinstrumentationと送信条件の範囲での観測であり、実行の完全性を自動的に保証しない。評価結果もdataset、scorer、model、prompt等のversionと適用範囲に依存する。Enterprise利用では、機密情報の収集制御、権限・retention、self-hostedのpatch管理、trace欠測、scorer calibrationを別途監査する。」 ## Scope Weights & Biases Weave：AIアプリケーションのトレーシング・評価・運用観測 ## Confirmed ## UNKNOWN - EA-173-UNKNOWN-01: - 現在利用中tenant／deploymentのWeave SDK、W&B Server、ClickHouse等のexact versionとpatch state。 - managed環境とself-hosted環境におけるregion、retention、deletion、backup、SLA、契約上の差異。 - 実際のproduction trace coverage、送信loss、sampling、instrumentation overhead。 - 各scorer／LLM judgeのdomain・language別calibrationと再現性。 - OpenTelemetry経路とnative Weave instrumentationの完全なfield parity／ordering／retry semantics。 - incident時に外部tool side effectとtraceをどこまで一意にcorrelateできるか。 ## Evidence - EVD-EA-173-URL-3C94D1F5D485 (RESEARCH): W&B Weave official repository: — https://github.com/wandb/weave - EVD-EA-173-URL-89A1C3EDCDD1 (RESEARCH): W&B Docs, “W&B Weave”: — https://docs.wandb.ai/weave/ - EVD-EA-173-URL-6F44C68791F2 (RESEARCH): W&B Server releases: — https://github.com/wandb/server/releases - EA-173-CURRENT-APPROVAL (RESEARCH): 現行本文の監査・revision対応 - EA-173-CURRENT-BODY-READBACK (IMPL): 現行本文の収録照合 ## Failure / limits SDKを初期化しただけで、必要なagent/tool/function経路がすべてinstrumentationされていると誤認する。 ## Failure / limits trace送信失敗やsamplingを考慮せず、観測された件数を実処理件数と同一視する。 ## Failure / limits prompt/model/tool/dataset/scorerのversionを固定せず、異なる条件のevaluation scoreを比較する。 ## Failure / limits LLM judgeのscoreを未校正のままrelease gateに使用し、judge driftやdomain biasを見逃す。 ## Failure / limits prompt、response、retrieved context、tool argumentへ含まれる秘密情報をredactionなしで保存する。 ## Failure / limits managed serviceとself-hosted Serverのsecurity、retention、upgrade条件を混同する。 ## Failure / limits dashboard上のlatency/cost集計だけで、外部tool、queue、network、provider billingを含むend-to-end SLO／costを証明したとみなす。 ## Failure / limits tracing/evaluation製品の存在自体を、AIアプリケーションの正確性、安全性、法令適合性の保証として扱う。 ## Failure / limits Weaveの公式資料は、trace・evaluation・agent integrationの機能存在を確認する一次資料として強いが、特定組織のtrace completeness、scorer validity、実運用overhead、障害時loss rate、tenant設定、実際のretention/deletion結果を証明しない。公式Server release notesにsecurity issueやupgrade prerequisiteが現れること自体、運用時にはversion固定とsecurity currentness確認が必要であることを示す。 本candidateでは、Weaveが他のobservability/evaluation製品より優れている、あるいは導入だけで品質・安全性が改善するという比較優位claimは置かない。独立した大規模比較benchmarkも確認済み根拠として扱わない。 ## 要点と前提 CANDIDATE_ID: ORPHAN-RESCUE-EA173-20261019-C1 EVIDENCE_AS_OF: 2026-10-19 ## 概要 Weights & Biases Weaveは、LLMアプリケーションやAIエージェントの実行をトレースし、評価・フィードバック・運用観測へ接続するためのプラットフォーム／OSSツールキットである。現在の公式リポジトリはWeaveを「AI agentsのtracing and evaluating」のためのtoolkitとして説明し、agent SDKとの統合、会話・turn・LLM call・tool callの追跡、任意関数の`@weave.op`によるトレース、evaluation/scorerを主要用途としている。したがってEnterprise AI運用では、Weaveを単なるログ画面ではなく、実行証跡と評価結果を結び付ける観測・検証レイヤとして扱うのが適切である。 ## 何を記録し、何に使うか Weaveの中心はtraceである。agent向け経路ではconversation、turn、LLM call、tool callを記録でき、一般の関数や評価処理は`@weave.op`でCallとして追跡できる。公式ドキュメントはOpenTelemetry互換SDKによるagent trace収集、任意関数・LLM callの手動instrumentation、versioning、feedback収集、LLM judgeやcustom scorerによるevaluationを主要機能としている。 運用上の価値は、最終回答だけを採点するのではなく、「どの入力・モデル・ツール・処理経路からその結果が生じたか」を追える点にある。失敗調査ではtrace treeからtool callやLLM callまで降り、評価では同じアプリケーション／agentに対してscorerを適用し、変更前後の結果を比較する。2026年3月のW&B Server 0.78系ではWeave Trace Analyticsがrequest count、P50/P95/P99 latency、model別token usage、cost breakdownを表示する機能を持つことも公式release notesで確認できる。これはobservabilityを品質だけでなく性能・費用の調査にも利用できることを示す。 ## Enterprise AIでの実装原則 ### 1. traceを「完全な真実」とみなさない instrumentationされていない処理、送信失敗、sampling、SDK／serverのversion差、非同期処理、外部system側の副作用はtraceだけでは完全に復元できない場合がある。したがってtrace IDをアプリケーションlog、job ID、tool request ID、外部transaction ID等と相関できるようにし、「traceがない＝処理されていない」と短絡しない。 ### 2. 評価対象をversionと結び付ける 評価値だけを保存しても、prompt、model、tool schema、dataset、scorerが変われば比較の意味が変わる。Weaveはtrace/evaluationとversioned objectを扱うため、少なくともapplication/prompt/model identifier、dataset revision、scorer definition、実行時設定、評価日時を同じ評価証跡に残す。production monitorとoffline evaluationを同じ名称のscoreで混同せず、母集団とsampling条件を明示する。 ### 3. 自動評価を人間判断の代替にしない LLM judgeやcustom scorerは大量評価に有用だが、scorer自体にも誤判定、model drift、prompt依存、language/domain biasがある。重要なquality gateでは、人手gold setまたは独立した基準とのcalibrationを行い、false positive/false negativeを確認する。score改善だけをproduction品質改善と同義にしない。 ### 4. traceへ機密情報を無制限に送らない LLM observabilityではprompt、response、tool argument、retrieved contextがそのまま機密情報になり得る。API key、認証token、個人情報、契約情報、秘密文書を「デバッグに便利」という理由だけでtraceへ保存しない。収集前redaction、field-level allowlist、environment別project分離、RBAC、retention/deletion、export権限を設計する。connected providerのdata policyとWeave側の保存境界も別々に確認する。 ### 5. managedとself-hostedを同一条件とみなさない W&Bはmanaged serviceとself-managed Serverを持ち、Server releaseにはWeave固有のupgrade prerequisiteやsecurity fixが含まれる。たとえばW&B Server 0.78.0/0.78.1にはartifactへのunauthorized accessを許すcritical security issueがあり、公式release notesは0.78.2への更新を指示している。またWeave利用deploymentでは0.78 upgrade前にClickHouse 0.25.8+が必要と記載されている。したがって「self-hostedだから安全」「cloudと同じ機能・patch level」とは扱わず、server version、依存DB、security advisory、backup/restore、upgrade pathを運用台帳で固定する。 ## Failure envelope - SDKを初期化しただけで、必要なagent/tool/function経路がすべてinstrumentationされていると誤認する。 - trace送信失敗やsamplingを考慮せず、観測された件数を実処理件数と同一視する。 - prompt/model/tool/dataset/scorerのversionを固定せず、異なる条件のevaluation scoreを比較する。 - LLM judgeのscoreを未校正のままrelease gateに使用し、judge driftやdomain biasを見逃す。 - prompt、response、retrieved context、tool argumentへ含まれる秘密情報をredactionなしで保存する。 - managed serviceとself-hosted Serverのsecurity、retention、upgrade条件を混同する。 - dashboard上のlatency/cost集計だけで、外部tool、queue、network、provider billingを含むend-to-end SLO／costを証明したとみなす。 - tracing/evaluation製品の存在自体を、AIアプリケーションの正確性、安全性、法令適合性の保証として扱う。 ## 具体的control 1. production trace coverageを経路別に定義し、agent turn、LLM call、tool call、重要なapplication operationの欠落率を定期確認する。 2. trace correlation IDをapplication log、queue/job、外部effectのidempotency key／transaction IDへ接続する。 3. prompt/model/tool schema/dataset/scorerにimmutable revisionまたはcontent hashを付け、evaluation resultから再現可能にする。 4. release gate用scorerはgold setでcalibrationし、閾値変更を監査対象にする。 5. sensitive fieldを収集前にredactし、raw prompt/response保存をdefaultにしない。project/team権限とretentionを環境別に確認する。 6. self-hostedではW&B Server、Weave関連dependency、ClickHouse等のversionとsecurity advisoryを追跡し、unsupported/EOL versionを残さない。 7. cost/latency dashboardはprovider invoice、application metrics、queue/tool latency等と突合し、observability自身の欠測を監視する。 ## 適用境界 Weaveは観測・評価の基盤であり、外部toolのauthorization、agent sandbox、transaction consistency、秘密管理、provider側retentionを代替しない。traceは観測された実行の証跡であって、未観測経路の不存在証明ではない。evaluationは設定したdataset/scorerに対する測定であって、未知のproduction分布や全ユーザーへの一般化を自動的には保証しない。 また、OSS repository上の機能とW&B managed／Serverの提供機能・release cadenceは分離して確認する必要がある。公式repositoryは2026年時点でTracingとEvaluationsへ重点を置いており、過去のWeave engine/boardsの一部はpauseと明記されている。古い記事やサンプルの画面・APIを現行契約として固定しない。 ## Counterevidence / limitations Weaveの公式資料は、trace・evaluation・agent integrationの機能存在を確認する一次資料として強いが、特定組織のtrace completeness、scorer validity、実運用overhead、障害時loss rate、tenant設定、実際のretention/deletion結果を証明しない。公式Server release notesにsecurity issueやupgrade prerequisiteが現れること自体、運用時にはversion固定とsecurity currentness確認が必要であることを示す。 本candidateでは、Weaveが他のobservability/evaluation製品より優れている、あるいは導入だけで品質・安全性が改善するという比較優位claimは置かない。独立した大規模比較benchmarkも確認済み根拠として扱わない。 ## OPEN_UNKNOWN - 現在利用中tenant／deploymentのWeave SDK、W&B Server、ClickHouse等のexact versionとpatch state。 - managed環境とself-hosted環境におけるregion、retention、deletion、backup、SLA、契約上の差異。 - 実際のproduction trace coverage、送信loss、sampling、instrumentation overhead。 - 各scorer／LLM judgeのdomain・language別calibrationと再現性。 - OpenTelemetry経路とnative Weave instrumentationの完全なfield parity／ordering／retry semantics。 - incident時に外部tool side effectとtraceをどこまで一意にcorrelateできるか。 ## SAFE_WORDING 「Weights & Biases Weaveは、AIエージェントやLLMアプリケーションの実行をトレースし、評価・フィードバック・性能／費用観測へ接続するための基盤として利用できる。ただし、記録されたtraceはinstrumentationと送信条件の範囲での観測であり、実行の完全性を自動的に保証しない。評価結果もdataset、scorer、model、prompt等のversionと適用範囲に依存する。Enterprise利用では、機密情報の収集制御、権限・retention、self-hostedのpatch管理、trace欠測、scorer calibrationを別途監査する。」 ## Source / provenance locator - Canonical research provenance: COMM-049-EA0173, legacy research communication; Drive immutable source/provenance recovered in integrated ledger. Canonical topic: Weights & Biases Weave. - W&B Weave official repository: https://github.com/wandb/weave — current README accessed 2026-10-19. Current description: agent tracing/evaluation; conversation/turn/LLM/tool tracing; `@weave.op`; prerequisites and supported integration guidance. - W&B Docs, “W&B Weave”: https://docs.wandb.ai/weave/ — current documentation surface accessed 2026-10-19. Observability/evaluation, OTel-compatible agent tracing, manual instrumentation, versioning/feedback, LLM judges/custom scorers. - W&B Server releases: https://github.com/wandb/server/releases — current release notes accessed 2026-10-19. Relevant currentness/security locator: 0.78.0/0.78.1 critical artifact authorization issue and 0.78.2 remediation; Weave upgrade prerequisite for ClickHouse; Trace Analytics latency/token/cost features. - Integrated management ledger: EA_MASTER row EA-173; EA_REVISION_LEDGER revision EA-173-V21-LEGACY-MIGRATION-20261003-R1. Historical evidence and UNKNOWN are retained; this candidate does not reuse legacy AUDIT_PASS/READY as current approval. NEXT: /agent/start.json STOP: This is a knowledge projection, not an execution order.