AIAgentOps_Weave

Transcript

1. を活用したコスト削減や新しい事業価値の 創出を実現するために必要な開発体制 の使い所
2. 目次 目次 1. はじめに 3 2. Weaveの概要 6 Agent-native tracing 7 Agent分析ダッシュボード 7 柔軟な評価体系の構築（オフライン評価） 7 フィードバック収集とHuman Annotation 8 W&B Weave Signalsと本番Monitoring 8 PlaygroundによるPromptとModelの反復検証 8 Coding Agentによる自律的な改善 9 W&B UIに組み込まれたCoreWeave ARIA（Preview） 9 エンタープライズ要件への対応 9 3. 継続的な評価体系の構築 11 評価体系構築の考え方と事例 11 Anthropic：評価は早く始め、育て続ける 11 GSK：Agentic AI Playbook 12 Algomatic：Innerループ/Middleループ/Outerループ 12 13 評価項目 1. Outcome Metrics：最終的に目的を達成したか 13 2. Trajectory / Tool Use Metrics：過程とTool Useは適切か 14 3. Safety / Policy Metrics：禁止事項と権限境界を守ったか 14 4. Cost / Latency / Reliability Metrics：本番運用を続けられるか 15 5. ユースケース特有の評価項目 15 オフライン評価とオンライン評価 15 Agentのリスクに応じて評価体系の強度を変える 16 W&B Weaveを用いたオフライン評価の進め方 17 `weave.Evaluation` 17 Evalsで全体から事例へ掘り下げる 19 W&B Weaveを用いたオンライン評価の進め方 20 まとめ 23 4. コスト最適化 24 コスト削減手法の大分類 24 コスト削減手法（Agentハーネス・API orchestration） 26 Prompt Caching 26 Compaction 27 Batch APIとFlex processing 28 Model Routing 29 Tool定義の遅延ロード 29 独立したTool Callをまとめ、Model Turnを減らす 30 ToolループとRetry Stormの分析・削減 30 contact-jp@wandb.com www.wandb.ai Page 1
3. 目次 ガードレールを立てる 31 コスト削減に向けたステップ 31 ステップ1：Batch・Flex処理が許容される範囲を決定する 31 ステップ2：タスク単位で可視化し、基準値を作る 31 ステップ3：明らかな重複と過剰なContextを減らす 31 ステップ4：安定したPrefixを作れる処理を見極める 32 ステップ5：ルーティングを行う 33 ステップ6：ループとRetryへ予算と停止条件を設ける 33 ステップ7：同じ評価セットで比較し、設定を詰める 33 33 まとめ 5. 多くのAI Agentを開発・改善・保守する体制の構築 35 35 自己改善のためのハーネス設計 改善を一度の生成ではなく「ループ」として設計する 36 AgentのMemory設計 36 評価・権限・停止条件をハーネスに組み込む 36 自己改善の難しいポイント 36 自己改善ハーネスのメモリとしてのW&B 38 Senpai: W&Bが提供する自己改善ハーネスのテンプレート 38 GitHubとW&BをメモリにしたSenpaiの構成 39 定型的な制御をLLMから分離する 40 Senpaiの設計を自己改善ハーネスの参考にする 40 ARIA（AI Research and Iteration Agent） 40 まとめ 41 6. 終わりに 42 contact-jp@wandb.com www.wandb.ai Page 2
4. 1. はじめに 1. はじめに 多くの企業がAI Agentを導入することで、業務にかかるコストを抑えると同時に、将来の成長を生み出す事業の創出 を目指しています。そうした企業の多くは、まずは業務の効率化や既存ツールの見直しを通じて、日々の業務にかか る時間とコストを減らす生産性向上・コスト削減から取り組みます。そして、生み出した時間やリソースを、新しい ビジネスや高付加価値業務へ振り向けることで、成長へのリソースシフトを行いながら、さらにその先のAIエージェ ントを活用し新しい事業価値の創出を目指す企業も多いでしょう。 W&Bは、こうした成果を目指す企業のAI活用推進担当者と日々対話しています。多くの企業では、独自のAI Agent ハーネスとGCP、AWS、Azureなどを活用し、AI Agentの開発基盤を構築しています。たとえば、AI Agentが社内の ツールやデータにアクセスできる環境の整備も、その一つです。 一方で、初期バージョンの開発だけに集中しすぎると、再開発に時間がかかる、コストが増える、増え続ける依頼に 対応できないといった課題に直面します。「AI Agentを活用したコスト削減や新しい事業価値の創出」を実現するに は、以下の開発体制が欠かせないという認識が広がっています。 取り組むべき内容 1. 継続的な評価体系の構築 • AI Agentの最終的な課題解決率を高め、維持するためには、評価体系が必要です。 • 評価には時間がかかり、繰り返し実施する必要があります。そのため、AI Agentの更新に迅速に対応できる、 属人化しないオフライン評価体系を構築する必要があります。 • オフライン評価だけではカバーできない点も多いため、開発時の評価に加えて、本番運用時の品質劣化を検 知するオンライン評価体制も必要です。 2. コスト最適化 • AI Agentの投資対効果を高めるには、消費するAPIコストを把握し、削減対象を分析できるようにする必要が あります。 3. 多くのAI Agentを開発・改善・保守する体制の構築 • 増え続けるAI Agentの開発依頼に限られたエンジニアで対応するには、AI Agent開発基盤やテンプレートの構 築に加えて、Coding Agentを活用した自律的な改善プロセスを導入する必要があります。 contact-jp@wandb.com www.wandb.ai Page 3
5. 1. はじめに 一方で、実装は簡単ではありません。これらの取り組みを実装し、運用するには、次のような難しさがあります。 実装する上で難しいポイント 1. 継続的な評価体系の構築 • AI Agentの何を、どの基準で評価すべきかを定めることが難しく、評価体系の構築に時間がかかります。 • AI Agentの更新に合わせて評価を繰り返す必要がありますが、個別の自作ワークフローに依存すると、評価 が属人化し、組織全体で再現できません。 • オフライン評価だけでは、本番環境で発生する想定外の入力や品質劣化を十分に捉えられません。 2. コスト最適化 • AI Agentのトレースを取得していない場合、どのモデル呼び出しやツール利用がAPIコストを増やしているの かを特定できません。 • コスト削減の方法は継続的に変化するため、最新の選択肢を把握し、具体的な施策として検証する必要があ ります。 3. 多くのAI Agentを開発・改善・保守する体制の構築 • 限られたエンジニアで増え続ける開発依頼に対応するには、AI Agent開発基盤やテンプレートを組織で共通化 する必要があります。 • Coding Agentを用いた自己改善は発展途上であり、自律的な改善プロセスをどこまで適用するかを判断するこ とが難しい状況です。 • 実行履歴や評価結果をリポジトリ内で個別に管理すると、情報が肥大化し、再利用や引き継ぎが難しくなり ます。 上記の課題は簡単ではありませんが、これらに対応をしていかなければ、最終的な目的を達成することはできませ ん。特に品質管理をおろそかにすると、途中で必ず問題に当たります。 上記課題を仕組みとして解決していく必要が あります。AIエージェント開発・運用時のこうした課題を解決する様々なOps（AgentOps）が提案されています。 W&B WeaveはAWSやAzure, GCPなどの開発環境に依存せず、共通して上記課題をサポートできるAgentOpsです。 Weaveはそれぞれの課題に対して、以下のような価値を提供します。 contact-jp@wandb.com www.wandb.ai Page 4
6. 1. はじめに Weaveが提供する価値 1. 継続的な評価体系の構築 • 評価用のDataset、Scorer、評価結果をバージョン管理し、組織で再現可能なオフライン評価体系を段階的に 構築できます。 • 評価結果を可視化し、AI Agentの更新前後を同じ基準で比較できます。 • W&B Weave Signalsを活用したオンライン評価により、本番運用時の品質劣化を検知し、オフライン評価の改 善につなげられます。 2. コスト最適化 • AI Agentのモデル呼び出しやツール利用をトレースし、APIコストを増やしているループや処理を分析できま す。 • W&B SkillsやMCPを通じて、Coding Agentがトレースと評価結果を参照し、コスト削減の対象分析を支援でき ます。 3. 多くのAI Agentを開発・改善・保守する体制の構築 • トレース、評価結果、実験の証拠を共有・検索可能な形で管理し、個人に依存しにくいAgentOpsと引き継ぎ の仕組みを構築できます。 • Coding Agentを用いた自己改善のハーネスからW&B Weaveの証拠を参照することで、改善プロセスを複数の AI Agentで再利用しやすくなります。 本書では、上記3点について詳細に説明をした後に、W&B Weaveがいかに役に立つか解説していきます。 contact-jp@wandb.com www.wandb.ai Page 5
7. 2. Weaveの概要 2. Weaveの概要 このセクションでは、W&B Weaveの概要を簡単に解説します。 Weights & Biasesは、AIモデルの学習・評価・運用を支えるAI開発者向けプラットフォームです。世界中で1,500以上 の組織（AstraZeneca、Canva、Snowflake、Square、Toyota、Wayveなど）に利用されており、OpenAI、Meta、Cohere といった30社以上の基盤モデル開発企業も、学習やファインチューニングの実験管理、そしてAgentic AIアプリケー ションの開発における記録基盤（system of record）として活用しています。Weights & Biasesは、いくつかのソリュー ションを提供していますが、本資料で扱うW&B Weaveは、AI Agentの観測、評価、継続的な改善を支援します。 AI Agentは、リリース前のテストだけで品質を完成させることが難しいシステムです。実際の利用者から寄せられる 依頼や、本番で直面する状況をすべて事前に想定することはできません。そのため、最初から完璧を目指すだけでな く、本番で起きたことをチームで振り返り、次の改善へ確実につなげる仕組みが必要です。W&B Weaveは、AI Agent の実行状況と評価結果を一か所に蓄積し、どこで問題が起きたのか、変更によって良くなったのかをチームで確認で きるようにします。これにより、開発チームは勘や個人の経験だけに頼らず、実際の利用から得た学びを継続的な品 質改善へ生かせます。 contact-jp@wandb.com www.wandb.ai Page 6
8. 2. Weaveの概要 Agent-native tracing Weaveの利用はシンプルです。AI Agentを動かすアプリ ケーションにWeave SDKを組み込むと、Agentへの入 力・出力や処理の流れが、W&Bのサーバーへ送られま す。記録は開発者の手元だけに閉じず、チーム共通の場 所に集約され、W&Bの画面やAPIから確認できます。 Weaveは、AI AgentのSDKやハーネス、LLM Provider、 Orchestration Framework向けに多様なIntegrationを提供し ています。対応済みのIntegrationであれば、 weave.init() を追加するだけで、Conversation、Turn、LLM call、Tool callをトレースすることができます。 すでにOpenTelemetry（OTel）で計装している環境では、OTel exporterの送信先をWeaveの専用OTLP endpointへ切り替 え、認証情報を設定することで、Weave SDKを追加せずにAgents viewへ簡単に取り込むことができます。 IntegrationやOTelへの対応により、既存アプリケーションへの変更を最小限に抑えながら、まずAgent-native tracingを 始めることが可能です。詳しくはインテグレーションの概要、エージェントIntegrationを選択する、OpenTelemetry SpanをAgents viewに送信するを参照してください。 また、Weaveのトレースの素晴らしいポイントは、AgentのセッションやMulti-turn対話をConversationとしてまとめ、 Turn単位で確認できる点にあります。わかりやすい可視化で、各TurnからLLM call、Tool call、Span、Sub-agentの呼び 出しまで掘り下げられます。最終回答だけでなく、どのToolやSub-agentが呼ばれ、どの入力と出力を経て結果へ至っ たかを追跡することが可能です。これにより、Agentの振る舞いに対する透明性と説明責任を高めます。詳しくはエー ジェントのアクティビティを確認とサブエージェントをトレースを参照してください。 Agent分析ダッシュボード WeaveでAgentsをトレースすると、Agentの統計情報が自 動的にダッシュボードに表示されます。Tool、Agent、 Model、Providerごとの利用状況から異常や調査対象を絞 り込み、対応するConversationやSpanへ移動できます。 詳しくはエージェントのアクティビティを確認を参照し てください。 柔軟な評価体系の構築（オフライン評価） WeaveはEvaluationというオフライン評価専用のクラスを 用意しています。このクラスを使うことで、Dataset、評 価関数、AIエージェントのバージョン管理とその結果の 管理を簡単に行え、W&B Weaveに結果を送信すると、 UI上では深掘り分析のための可視化も自動的に行ってく れます。Weaveを利用するだけで評価の属人化から脱す ることができます。また、同じ評価ケースに対して Prompt、Agent実装を反復測定し、複数のEvaluationを横 並びで比較することができるため、変更による改善とリ グレッションの確認をチームで体系的に行うことができ contact-jp@wandb.com www.wandb.ai Page 7
9. 2. Weaveの概要 ます。詳しくは評価の概要、スコアリングの概要、Evaluationの比較を参照してください。 フィードバック収集とHuman Annotation AIエージェントの評価は最初に人手評価を伴うケースが 多いでしょう。Weaveには、ビジネスユーザーがHuman AnnotationをUI上で行うことができる機能があります。 トレースを選択し、Annotation Queueに追加するだけ で、ビジネスユーザーがHuman Annotationを開始する画 面を作ることができます。詳しくはAnnotation Queueを 設定するとフィードバックを収集し、Human Annotation を活用するを参照してください。 W&B Weave Signalsと本番Monitoring オフライン評価だけではカバーできないポイントが多い ため、開発時だけでなく、本番運用時の品質劣化を検知 するオンライン評価体制も必要になります。大量のト レースをすべて人が読むことは現実的ではありません。 W&B Weave SignalsはWeaveに送信されたトレースに対 してW&BのサーバーからLLM as a judgeを実行するBuiltinのオンライン評価機能を提供しています。ユーザーの不満や低品質の出力などを自動的にtag付けてして可視化しま す。Custom Signalも定義できます。さらにAutomationsを設定すると、Slack通知やWebhookを実行できます。詳しくは シグナルを使ってエージェントをモニタリングする、カスタムモニターを設定する、オートメーションを設定するを 参照してください。 PlaygroundによるPromptとModelの反復検証 Playgroundでは、新しいPromptやModelを試すだけでな く、本番で記録した既存Callを開き、PromptやModelを 変えて再実行できます。複数Modelの応答を並べ、用途 に合う振る舞いを比較できます。Evaluation Playgroundで は、Dataset、Model、ScorerをUIで組み合わせ、コード を書かずにUI上でEvaluationを実行できます。詳しくは Playgroundを使ってPromptを試すとEvaluation Playground を使ってModel性能を比較するを参照してください。 contact-jp@wandb.com www.wandb.ai Page 8
10. 2. Weaveの概要 Coding Agentによる自律的な改善 Andrej Karpathy氏のautoresearchに着想を得た、Coding Agentが分析・変更・評価を繰り返す自律的な改善アプ ローチ（Self-improvement）が注目されています。W&B SkillsやW&B MCP Serverを使うと、Claude Code、 Codex、CursorなどのCoding AgentをW&B Weaveへ接続 することができます。Coding Agentが権限の範囲内で Weaveの本番トレースを読み取り、失敗例を分析し、修 正を行った後、再度のWeave Evalで評価を実装し、その 結果を元にまた改善をするというサイクルを回すことが できます。 W&B UIに組み込まれたCoreWeave ARIA（Preview） Coding Agentとの外部接続とは別に、W&B UIにはAI Research and Iteration Agent （ARIA）と呼ばれる独自の Coding Agentを実装しています。ARIAはRunやMetricを 分析し、パターンの発見、次の実験の提案、可視化、 WorkspaceやReportの作成を支援します。設定された環境 では、利用者の承認を経てW&B Launchから実験を実行 することもできます。ARIAは2026.8時点ではPreview機 能です。詳しくはARIAの概要とCoreWeave ARIAを参照 してください。 ARIAの動作は、公式デモ動画で確認できます。 エンタープライズ要件への対応 AI Agentのトレースには、ユーザー入力、生成結果、Tool call、アプリケーション内の処理結果などが含まれます。 W&BではOrganization、Team、Projectの単位でアクセスコントロールが可能です。Planに応じてSSOの設定も可能で す。デプロイメントは、W&Bが運用する共有環境のW&B Multi-tenant Cloud、AWS、Google Cloud、Azure上の顧客専 用環境をW&Bが運用するW&B Dedicated Cloud、利用企業が管理するCloud（VPC）またはオンプレミスへ構築する W&B Self-Managedから選択できます。Dedicated Cloudでは、IP allowlisting、Private connectivity、専用Compute環境、 一意のW&B管理暗号化Keyなどを利用できます。これらの豊富なデプロイメントオプションにより、企業はデータレ ジデンシー、Network分離、認証・認可、Compliance、運用責任に合わせてAgentOps基盤を設計できます。Dedicated Cloudを提供しているLLM Observability ToolはWeaveだけであり、多くのエンターブライズ企業に選ばれる要因の一つ になっています。 contact-jp@wandb.com www.wandb.ai Page 9
11. 2. Weaveの概要 このセクションでは、Weaveの機能一覧を簡潔に紹介しました。次のセクションからは、「継続的な評価体系の構 築」、「コスト最適化」、「多くのAI Agentを開発・改善・保守する体制の構築」についてそれぞれ解説をしていき ます。 contact-jp@wandb.com www.wandb.ai Page 10
12. 3. 継続的な評価体系の構築 3. 継続的な評価体系の構築 AI Agentの出力や行動は確率的で、同じ入力でも結果が変わることがあります。自然言語のような自由度の高い出力 は、単一の数値だけで良し悪しを決められません。一方、「良い回答」の定義が利用者や業務によって異なるため、 評価基準づくりに課題を感じているエンジニアは多いでしょう。また、評価に使えるデータセットが、開発初期には 十分に揃っていないことも珍しくなく、AI Agentの評価体系は簡単ではありません。 リリース後も評価は終わりません。想定外の入力や使い方が現れ、利用者の期待も変わります。すぐにAI Agentの再 開発が求められますが、LLM、Framework、接続するToolを更新すれば、以前は成功していたケースが失敗すること もあります。評価を単発のテストで終わらせると、変更のたびに膨大な時間を費やすことになり、改善の速度を保て ません。 必要なことは、最初は評価体系の構築に時間がかかったとしても、評価体系を育てていきながら、個人に依存せず、 再現高いものにしていく仕組みです。本章では、まず評価体系の考え方と評価観点を整理しながら、Weaveを用いた 評価体系構築についても解説をしていきます。 評価体系構築の考え方と事例 AI Agentの理想的な出力や評価方法が、最初から明確であることは多くありません。評価指標やLLM Judgeの手法を 学んでも、自分たちのAgentにとって望ましい出力を定義できなければ、評価設計は進みません。 そこで、完成した評価体系を一度に作ろうとせず、実際の出力に対する人の判断を記録しながら、評価観点、データ セット、スコアラーを段階的に整えます。ここで、AI Agent開発を進めているいくつかの企業の評価に対する考え方 をみていきましょう。 Anthropic：評価は早く始め、育て続ける Anthropicの「Demystifying evals for AI agents」では、評価がないと劣化や変更の影響を捉えにくく、デバッグが本番の 不具合報告に依存しやすいと説明しています。同記事が示す出発点は、評価を早く始め、開発と運用の中で保守し続 けることです。 • Step 0：早く始める：最初は、実際の失敗や想定ユースケースから選んだ20〜50件程度のタスクでも構いません。 • Step 1：手動確認を評価へ変える：リリース前に確認している挙動や、利用者から報告された不具合を評価タスク にします。 • Step 2：曖昧さのないタスクを書く：複数の専門家が同じ合否判断に到達できる仕様と、動作確認済みの参照解を 用意します。 • Step 3：偏りの少ない問題セットを作る：「実行すべきケース」と「実行すべきでないケース」の両方を含めま す。 • Step 4：安定した評価環境を作る：本番に近い構成を使い、各試行をクリーンな状態から始めます。 • Step 5：スコアラーを慎重に設計する：可能な箇所には決定的な評価を使い、必要な箇所へLLM Judgeと人手評価 を割り当てます。 • Step 6：トレースを読む：Scoreだけで判断せず、Agentの失敗と評価設計の不備を切り分けます。 • Step 7：評価の飽和に注意する：Scoreが上限へ近づいたら、より難しいタスクを追加して改善余地を取り戻しま す。 • Step 8：評価を保守する：基盤の管理者を置き、プロダクト担当者やドメイン専門家がタスクを継続的に追加しま す。 contact-jp@wandb.com www.wandb.ai Page 11
13. 3. 継続的な評価体系の構築 Anthropicが示す、評価Suiteの開発、評価ハーネスの開発、評価の保守からなる優れた評価へのRoadmap GSK：Agentic AI Playbook 製薬企業GSKの取り組みは、評価体系を継続運用の型として整えた例です。W&BのGSK事例では、AI Agentを本番運 用するうえで、次の課題が挙げられています。 • 自由記述の出力を単純な正誤だけでは評価しきれない • FrameworkやLibraryの更新によって既存のワークフローが壊れる可能性がある • 新しいLLMへ切り替えるべきかを、自分たちの基準で判断する必要がある • LLMのバージョン変更で出力形式が変わり、後続処理にRegressionが生じる可能性がある そこでGSKは、Agentic AI Playbookを、次の3本柱で整備しています。 1つ目は、利用者のフィードバックを記録し、実運用に根ざしたGoldenデータセットへ変える「知識の蓄積」です。2 つ目は、そのデータセットと再利用可能なスコアラーを使い、新しいLLMやAgent戦略を同じ条件で比べる「迅速な 試作」です。3つ目は、本番のトレースを残し、問題が起きた箇所を調査できるようにする「モニタリングとガバナン ス」です。なお、このPlaybookはW&B Weaveを基盤として構築されています。 Algomatic：Innerループ/Middleループ/Outerループ Algomaticの事例では、評価を単発のテストではなく、開発ライフサイクル全体に組み込む考え方が示されています。 W&B AI Agent LT会の宮脇氏資料では、改善活動をInnerループ、Middleループ、Outerループに分けています。 • Innerループ：Model選択やPrompt作成を素早く試し、ドメイン専門家と方向性を確認します。ここでは、学びの速 さを重視します。 • Middleループ：有望な案をデータセットとテスト設計で検証し、本番へ出せる品質かを確認します。 • Outerループ：本番のLatency、品質、利用者の反応を継続的に観測し、得られた学びを次の改善へ戻します。 この構造なら、最初から大きなデータセットを用意できなくても、Innerループで見つけた成功例と失敗例をMiddle ループのデータセットへ加え、Outerループで得た利用者の反応を次の評価へ戻せます。 contact-jp@wandb.com www.wandb.ai Page 12
14. 3. 継続的な評価体系の構築 3つの事例に共通するポイントは、評価体系を完成品ではなく、判断と失敗を蓄積して育てる資産として扱うという 視点です。 評価項目 評価体系を育てるという考え方を理解できたあとは、次に「何を評価するか」について理解を深めていきましょう。 最終回答が正しく見えても、Agentが必要なToolを使っていない、不要なTool Callを繰り返している、関係のないテス トを削除して成功扱いにしている、といった失敗は起こり得ます。そのため、最終結果だけでなく、過程とTool Use、安全性、Cost、Latency、Reliabilityを複数の層で見ます。本章では、評価観点を次の5つに整理します。 1. Outcome Metrics：最終的に目的を達成したかを見ます。代表的な失敗は、回答は自然でもタスクを解決できてい ないことです。 2. Trajectory / Tool Use Metrics：どのような過程で到達し、Toolを適切に使えたかを見ます。代表的な失敗は、結果 は合っていても、非効率な手順や不要なTool Callが多いことです。 3. Safety / Policy Metrics：やってはいけないことをしていないかを見ます。代表的な失敗は、承認なしに更新や削除 を実行することです。 4. Cost / Latency / Reliability Metrics：本番運用できるかを見ます。代表的な失敗は、処理が遅い、高い、不安定、再 現しないことです。 5. ユースケース特有の評価項目：Agentの用途に応じて、特に見逃したくない失敗を評価します。例えば、Customer Support Agentでは、不適切な返金判断やHandoffの見落としを確認します。 AI Agentの評価項目をOutcome、TrajectoryとTool Use、SafetyとPolicy、Cost・Latency・Reliability、ユースケース特有の項目の5 つに整理し、主な指標と代表的な失敗を対応づけた一覧 1. Outcome Metrics：最終的に目的を達成したか Outcome Metricsは、Agentが最終的にタスクを達成したかを見る指標です。評価体系の入口に置きやすい一方、これ だけでは途中の危険な行動や非効率な処理を捉えられません。 • Task Success Rate：タスクが完了したかを見ます。例えば、問い合わせに回答できたか、修正PRを作れたかを確認しま す。 • Correctness：最終結果が正しいかを見ます。例えば、回答、計算、分類が正しいかを確認します。 contact-jp@wandb.com www.wandb.ai Page 13
15. 3. 継続的な評価体系の構築 • Reference Alignment：参照情報と一致しているかを見ます。例えば、FAQ、仕様書、DBの結果と矛盾していないかを確認 します。 • User Acceptance Rate：人間が結果を採用したかを見ます。例えば、担当者がAIの提案をそのまま使ったかを確認します。 • Resolution Rate：問題が解決したかを見ます。例えば、サポートへの問い合わせが再オープンされていないかを確認しま す。 2. Trajectory / Tool Use Metrics：過程とTool Useは適切か Trajectory / Tool Use Metricsは、Agentがゴールへ到達するまでの行動と、各StepでToolを適切に使えたかを見る指標で す。検索、DB、社内API、Code実行、Browser、チケットシステムなどの選択、引数、結果の利用、呼び出し回数を 評価します。 Anthropicの「Writing effective tools for agents」も、Agentの性能がToolの設計に左右されるため、Toolそのものを継続 的に評価・改善する必要があると説明しています。 • Step Efficiency：無駄なステップが少ないかを見ます。例えば、不要な確認や処理を繰り返していないかを確認します。 • Decision Correctness：分岐判断が正しいかを見ます。例えば、人間の承認が必要な操作を自動実行していないかを確認し ます。 • Recovery Quality：失敗から回復できたかを見ます。例えば、APIエラー後に再試行や代替手段を選べたかを確認します。 • Constraint Adherence：指示や制約を守ったかを見ます。例えば、read-only条件で更新系APIを呼んでいないかを確認しま す。 • Tool Selection Accuracy：適切なToolを選べたかを見ます。例えば、最新情報が必要な場面で検索したかを確認します。 • Tool Use Recall：必要なToolを使えたかを見ます。例えば、顧客情報が必要な場面でCRMを参照したかを確認します。 • Tool Call Count：Toolの利用回数が適切かを見ます。例えば、同じ検索やAPIを必要以上に繰り返していないかを確認しま す。 • Argument Correctness：Tool Callの引数が正しいかを見ます。例えば、 customer_id 、期間、File Pathが正しいかを確認しま す。 • Tool Call Validity：Schemaに合う呼び出しができたかを見ます。例えば、引数名や型が正しいかを確認します。 • Tool Result Utilization：Toolの結果を正しく使えたかを見ます。例えば、検索結果を無視して想像で回答していないかを確 認します。 Outcomeが「結果が良かったか」を見るのに対し、Trajectory / Tool Use Metricsは「その結果へ至る過程を信頼できる か」を見ます。Toolを使って外部状態を変えるAI Agentでは、この過程の観測が欠かせません。 3. Safety / Policy Metrics：禁止事項と権限境界を守ったか Agentは外部Toolを使い、状態を変更することがあります。そのため、単なる回答品質だけでなく、安全性や権限境界 も評価対象になります。 • Policy Adherence：業務・法務・安全ポリシーを守ったかを見ます。例えば、返金条件や医療・金融助言のルールを守った かを確認します。 • Unauthorized Action Rate：権限外の操作をしていないかを見ます。例えば、承認なしに削除、送信、キャンセルをしてい ないかを確認します。 • Sensitive Data Leakage：機密情報やPIIを漏らしていないかを見ます。例えば、他の顧客の情報を出していないかを確認し ます。 • Guardrail Trigger Accuracy：Guardrailが適切に作動したかを見ます。例えば、危険な操作を止めたかを確認します。 • Handoff / Escalation Accuracy：人間に渡すべきケースを渡せたかを見ます。例えば、曖昧なケースや高リスクなケースを自 動処理していないかを確認します。 安全性についても、最初から大規模な評価体系を作る必要はありません。そのAgentにとって最も危険な操作や、最 も避けたい失敗から評価を作ります。 contact-jp@wandb.com www.wandb.ai Page 14
16. 3. 継続的な評価体系の構築 ここでのHandoffは、Agentが自分で処理を続けるのではなく、人間の担当者や別の承認フローに引き渡すことを指し ます。Customer Support Agentであれば、返金条件が曖昧なケース、法務・医療・金融など慎重な判断が必要なケー ス、顧客感情が強く人間対応が望ましいケースなどが該当します。Handoffは「最終回答が正しいか」だけでは見えに くいため、Safety / Policy Metricsの中で明示的に評価します。 4. Cost / Latency / Reliability Metrics：本番運用を続けられるか 本番では、品質だけでなく、Cost、Latency、Reliabilityも評価対象になります。 • Cost per Task：1タスクあたりの推論・Toolコストを見ます。例えば、1件の問い合わせに何円かかるかを確認します。 • Cost per Successful Task：成功1件あたりの実効コストを見ます。例えば、失敗や再試行を含めてどれだけのコストがか かったかを確認します。 • Token Usage：Tokenの消費量を見ます。例えば、ContextやTool Resultが大きすぎないかを確認します。 • Time to Completion：完了までの時間を見ます。例えば、ユーザーが待てる範囲に収まっているかを確認します。 • Regression Rate：変更によって既存のケースが壊れていないかを見ます。例えば、Promptの変更後に成功率が下がっていな いかを確認します。 • Multi-run Stability：複数回実行しても安定するかを見ます。例えば、同じ入力に対する結果が大きくぶれないかを確認し ます。 Anthropicの「Quantifying infrastructure noise in agentic coding evals」は、Coding Agentの評価Scoreがタスクの難しさだけ でなく、CPU、RAM、時間制限などの実行環境にも左右されることを示しています。外部Toolや実行環境に依存する Agentでは、環境由来のノイズも評価設計に含めます。 5. ユースケース特有の評価項目 評価の重点は、Agentの用途によって変わります。共通の分類を土台にしながら、個別ユースケースで見逃したくない 失敗を具体化します。 • Customer Support Agent：OutcomeとSafety / Policy（Handoffを含む）が特に重要です。ポリシーにない返金条件を 作ることや、人間に渡すべきケースを自動処理することを見逃さないようにします。 • Coding Agent：Outcome、Trajectory / Tool Use、Reliabilityが特に重要です。テストを削除して処理を通すこと、必 要なLintやBuildを実行しないこと、CIのノイズを実装Bugと誤解することを見逃さないようにします。 • Research Agent：OutcomeとTrajectory / Tool Useが特に重要です。必要な情報を検索しないことや、調査タスクを完 了できないことを見逃さないようにします。 • Data Analyst Agent：Correctness、Trajectory / Tool Use、Reproducibilityが特に重要です。SQLや集計条件を間違うこ とや、再現できない分析を返すことを見逃さないようにします。 • ワークフロー Automation Agent：Outcome、Trajectory / Tool Use、Safety、Reliabilityが特に重要です。処理の順序 を間違うこと、承認なしに更新すること、途中の失敗から復帰できないことを見逃さないようにします。 Tips：評価項目の選び方 最初は「このAgentで、どの失敗を見逃したくないか」と問い、その失敗を検出できる観点から選ぶと設計しや すくなります。 オフライン評価とオンライン評価 ここまでは「何を評価するか」を整理してきました。次に考えるのは、「いつ、どの段階で評価するか」です。AI Agentの評価方法は、大きくオフライン評価とオンライン評価の2つに分けられます。 contact-jp@wandb.com www.wandb.ai Page 15
17. 3. 継続的な評価体系の構築 オフライン評価では、評価データセットと評価関数を用意し、AI Agentの絶対的な品質を測定します。人手評価も評 価方法の一つです。オフライン評価は、AI Agentを更新する際も利用することができます。LLM、Framework、 Prompt、Toolを更新すると、修正した箇所が良くなる一方で、以前は成功していたケースが壊れることがあります。 そのため、現行版と候補版を同じ評価体系で比較し、重要なケースのリグレッションをリリース前に確認します。 評価結果を表計算ファイルへ手作業で記録するだけでは、変更頻度が上がったときに、条件の再現やバージョン間の 比較が難しくなります。評価プロセスをAgentOpsの一部として反復可能にし、データセット、スコアラー、実行結果 をチームで共有できる状態にすることが重要です。共通の仕組みを持つことで、プロジェクトごとに評価基盤を作り 直す負担も抑えられます。 このように、オフライン評価は、既知の失敗をリリース前に見つけ、変更によるRegressionを防ぐための第一の防波 堤になります。しかし、限られたデータセットと想定シナリオだけでは、本番で現れる入力や利用パターン、細かい 不具合を網羅できません。AnthropicによるAI Agent評価の解説も、実利用パターンと合わない自動評価は誤った安心 につながり得る一方、Production Monitoringは分布変化や想定外の失敗を見つける役割を持つと解説しています。 特にAI Agentは、複数のTurnにわたってToolを呼び、外部の状態を参照・変更しながら処理を進めます。個々の応答 は妥当に見えても、途中の判断、Tool Call、再試行、外部APIの状態が組み合わさることで、開発時には想定しな かった失敗が生じます。利用者、入力、接続先、Modelが変われば、リリース時に合格した評価結果だけで品質を説 明し続けることはできません。 そこで、リリース後はオンライン評価によって、本番で起きていることを継続的に観測します。👍や👎、不具合報告 などの明示的フィードバックは重要ですが、それだけでは十分ではありません。こうしたフィードバックはほとんど 得られないので、十分な情報になりません。 一方、すべてのトレースを人が読む方法は、利用量の増加に合わせて拡張しにくくなります。そこで、決定的なRule で判定できる観点はRuleを使い、文脈を要する観点にはLLM Judgeを使います。自動集計とScoringで調査対象を絞 り、必要に応じて人手のレビューへ回すことで、本番の理解と改善を両立します。 オンライン評価では、主に以下のような観点を確認します。 • Outcomeと利用者反応：タスク完了率、解決率、Handoff率、再質問や離脱、ユーザーのリアクションなどを見ま す。上記の通り、利用者が成功や不満を明示してくれるとは限りません。そのため、明示的フィードバックを待つ だけでなく、離脱・不満などをトレースと関連づけ、暗黙的な反応を取得する仕組みが必要です。 • Safety：Policy違反、権限外の操作、機密情報やPIIの漏洩、悪意ある入力、危険な出力などを見ます。 • TrajectoryとTool Use：Tool Call数、選択したTool、引数、失敗・再試行、処理順序、Spanごとの状態を見ます。最 終結果だけでは見えないループ、不要な呼び出し、途中失敗をトレースから調査します。 • Cost、Latency、Reliability：Conversation数、Error rate、Token、Cost、Latencyなどを見ます。全体平均だけでな く、期間、Agent、Model、Providerなどで絞り、特定の構成や変更後に悪化していないかを確認します。 本番で見つけた失敗候補は、人が確認したうえでデータセットとスコアラーへ反映し、次のオフライン評価へ戻しま す。このように、オフライン評価で既知の失敗をリリース前に防ぎ、オンライン評価で本番固有の失敗を見つけ、そ の学びを再びオフライン評価へ戻します。2つの評価方法を別々に考えるのではなく、シームレスなつなぎを意識し ながら、本番の未知を次の比較可能な評価へ組み込んでいくことが重要です。 Agentのリスクに応じて評価体系の強度を変える 組織内のAI Agentが増えるほど、すべてに同じ評価工程を課し続けることは難しくなります。対象利用者数、求める 精度、処理の複雑さだけでなく、外部状態を変える権限、失敗の可逆性、扱うデータの機密性を確認し、評価体制を contact-jp@wandb.com www.wandb.ai Page 16
18. 3. 継続的な評価体系の構築 変えていく工夫も現実的には求められつつあります。例えば、W&Bが日々お客様とお話をする中では、次の2つの評 価体系が話題に上がることがあります。 • オンライン評価を中心とする評価体系：対象利用者が少なく、処理が比較的単純で、失敗時の影響が限定的かつ 回復しやすいAgentに適用します。基本動作、権限、安全性を確認し、トレースを計装したうえで、限定的な本番 利用から学びます。 • オフライン評価とオンライン評価を組み合わせる評価体系：利用者が多い、高い精度が必要、機密データや重要 業務を扱う、外部状態を変更する、複雑な研究開発へ使う、といったAgentに適用します。リリース前の体系的な 評価と承認を、本番観測と組み合わせます。 例えばPortfolioの約80%をオンライン評価中心、約20%をオフライン評価とオンライン評価の併用するといった運営 方法も考えられます。この辺りはまだ完璧なパターンが見えてきたわけではありませんが、実践的な観点として注目 されつつあります。 W&B Weaveを用いたオフライン評価の進め方 W&B WeaveのEvaluation機能を使い、オフライン評価を進める方法をみていきましょう。W&B WeaveのEvaluation は、Dataset、Scorer、評価対象を組み合わせ、同じ条件で変更前後を比較する仕組みです。実行結果をEvalsへ記録す ると、全体のScoreだけでなく、各サンプルに対する結果まで深掘りすることができます。 weave.Evaluation W&B Weaveのオフライン評価では、 weave.Evaluation を利用します。weave.Evaluationに、次の3つの要素を渡して実装 すると、可視化からバージョン管理までを自動的に行ってくれます。 • Dataset：評価対象となる入力と、必要に応じて期待出力を行ごとにまとめたデータセット • 評価対象：出力を生成する関数。weave.ModelというAI Agentのバージョン管理を行うクラスを利用すると、AI Agentのバージョン管理まで行うことができますが、LLM Observability Toolの中で、評価対象のAI Agentのバー ジョンまで行ってくれるツールはW&B Weaveだけです。 • Scorer：出力を採点し、Metricへ変換する評価関数です。完全一致などの決定的なRule、Codeによる検証、LLM Judgeなどを評価観点に応じて使い分けます。 contact-jp@wandb.com www.wandb.ai Page 17
19. 3. 継続的な評価体系の構築 評価を実行すると、Datasetの各事例が評価対象へ渡され、出力がScorerによって採点されます。結果はWeaveのEvals に記録されるため、平均Scoreだけでなく、個々のサンプル、Latency、Token使用量、Scorerごとの結果を確認できま す。 入力を大文字へ変換する関数を、期待値との完全一致で評価するサンプルでEvaluationの使い方を見ていきましょ う。DatasetとScorerを weave.Evaluation へ渡して実行すると、評価計画と結果がW&B Weaveへ記録されます。 import asyncio import weave from weave import Evaluation weave.init("my-team/my-project") # 評価関数 @weave.op() def exact_match(expected: str, output: dict) -> dict: return {"match": expected == output.get("prediction")} # 評価データセット dataset = [ {"text": "hello", "expected": "HELLO"}, {"text": "weave", "expected": "WEAVE"}, ] # AI Agentの推論インターフェース class MyModel(weave.Model): @weave.op() def predict(self, text: str) -> dict: return {"prediction": text.upper()} evaluation = Evaluation(dataset=dataset, scorers=[exact_match]) summary = asyncio.run(evaluation.evaluate(MyModel())) print(summary) contact-jp@wandb.com www.wandb.ai Page 18
20. 3. 継続的な評価体系の構築 Evalsで全体から事例へ掘り下げる Evalsでは、Evaluationの一覧から個別の結果を開き、Scorerごとの集計とDatasetの各事例を確認できます。 weave.Evaluationを利用すると、それ以外にもさまざまな便利な可視化をW&BのUI上で実現してくれます。 • 全体の結果：AI Agentのバージョンごとの平均Score、分布、Latency、Token使用量を見て、変更後の傾向を確認し ます。 • 各事例の結果：どの入力で失敗し、期待出力と実際の出力がどう違うかを確認します。 • トレースの深掘り：失敗した事例のトレースを開き、Prompt、Model、検索結果、Tool Call、前処理・後処理のど こに原因があるかを調査します。 • バージョン間の比較：変更前後を並べ、狙った観点が改善したか、別の観点や重要ケースが悪化していないかを 確認します。 複数のEvaluationを比較するときは、Summary MetricsとScorecardで、Scorerごとの結果、Latency、Token使用量などの 違いを俯瞰できます。 contact-jp@wandb.com www.wandb.ai Page 19
21. 3. 継続的な評価体系の構築 全体の傾向を確認した後は、Output Comparisonで同じ入力に対するModelごとの出力を並べ、事例単位の違いを確認 します。 平均Scoreが上がっていても、重要なケースが壊れていればリリースできない場合があります。Summaryだけで合否を 決めず、事例単位と評価軸単位でもRegressionを確認します。 Tips：柔軟な評価記録には EvaluationLogger を使う DatasetとScorerを事前に定義して繰り返す weave.Evaluation に加え、動的なワークフローや一部のStepを逐次記録 できる EvaluationLogger もあります。評価対象を固定したDatasetへまとめにくい場合に選べる、柔軟な実装方式 です。自分が実装したい形式に合わせて評価体系を作ることができるポイントがWeaveの特徴です。 W&B Weaveを用いたオンライン評価の進め方 W&B Weaveでは、オンライン評価という視点では、次の2つのツールを提供しています。 • ダッシュボードと通知：Agents viewで、計装したConversation、Turn、LLM Call、Tool Call、Spanをトレースとして 記録します。ダッシュボードではConversation、Error rate、Token、Costなどの推移を確認し、変化した期間やAgent から個別のトレースへ掘り下げます。Automationsでは、Metricの期間、集約方法、閾値を設定し、Slackまたは Webhookへ通知できます。ここではあくまで可視化と、ルールベースの通知になります。 • W&B Weave Signals：W&B Weave SignalsはWeaveに送信されたトレースに対してW&BのサーバーからLLM as a judgeを実行するBuilt-inのオンライン評価機能を提供しています。ユーザーの不満や低品質の出力などをLLMで分 析をし、自動的にtag付けてして可視化します。Custom Signalも定義できます。こちらも、Automationsを設定する と、Slack通知やWebhookを実行できます。なお、LLM as a judgeのAPI代はユーザー負担です。 ここからは、W&B Weave Signalsを詳しく見ていきます。大量のトレースをすべて人が読むことは現実的ではありませ ん。W&B Weave SignalsはAI Agentの各ターンを評価し、「ユーザーの不満」や「低品質な応答」などのタグ、「ユー ザー満足度」や「応答品質」などの評価として可視化します。プリセットに加え、業務固有のCustom Signalsも定義で きます。 SignalsはW&B WeaveのUIまたはAPIで設定できるため、Scoring処理をアプリケーションコードへ組み込む必要はあり ません。トレースが記録されると、設定したFilterとSample rateに従って自動評価されます。 contact-jp@wandb.com www.wandb.ai Page 20
22. 3. 継続的な評価体系の構築 コラム：なぜ「Signals」という名前なのか ユーザーは、不満を感じても、必ずしも👍や👎、不具合報告で知らせてくれるとは限りません。AI Agentも、明 確なErrorを出さないまま、低品質な応答や不自然なやり取りを生むことがあります。「Signals」という名前に は、こうした表面化しにくい不満や問題の「兆候」を本番のTurnから捉え、改善の入口にするという意味が込め られています。 W&B Weave Signalsの組み込みSignal 組み込みSignalには、特定の状態を検出する「Tag」と、0〜1の数値で度合いを測る「Rating」があります。 • Tag • ユーザーの不満（User Frustration）：ユーザーの苛立ち、怒り、混乱、不満の兆候を検出します。 • 悪意ある意図（Malicious Intent (Jailbreaking)）：Jailbreak、Prompt Injection、Role-playによる回避など、AI Agent にGuardrailを無視させようとする意図を検出します。 • 職場に不適切な内容（NSFW）：露骨な性的表現、過激な暴力表現など、職場での利用に適さない内容を検出し ます。 • 低品質な応答（Low Quality Response）：事実誤認、的外れ、曖昧な回避、過度な反復、不十分な拒否理由など、 ユーザーの依頼に十分応えていない出力を検出します。 • Rating • ユーザー満足度（User Satisfaction）：肯定的なフィードバック、継続的なやり取り、タスク完了と、不満、繰り 返しの言い換え、離脱などから、ユーザーの満足度を評価します。 • ユーザー意図の健全性（User Good Intent）：ユーザーの意図が正当で無害か、Jailbreak、危険な依頼、Prompt Injectionなどに当たるかを評価します。 • 職場で扱える内容か（Safe-for-Work）：会話が業務環境に適しているか、露骨な表現、暴力表現などの不適切な 内容を含むかを評価します。 • 応答品質（Response Quality）：AI Agentの応答が正確か、必要な内容を十分に含み、ユーザーの依頼へ直接答え ているかを評価します。 contact-jp@wandb.com www.wandb.ai Page 21
23. 3. 継続的な評価体系の構築 Signalsを設定し、Trendからトレースへ掘り下げる Signals画面の上段にはFilter、期間、Score volumeがあり、下段にはScoringされたTurnが並びます。各行でScorer、最後 のMessage、Agent、Score、Trend、Scoring時刻を確認できるため、全体の変化から問題のあるTurnへ掘り下げられま す。 • Signals画面を開く：W&B WeaveのProjectでAgentsを選 び、Signals tabを開きます。まだSignalがない場合は、 + New signal から作成します。 2. TagかRatingかを決める：特定の状態を検出したい場合はTagを使います。例えば、User FrustrationやLow Quality Responseを検出し、発生件数のTrendを追います。品質や満足度を0から1で継続的に測りたい場合はRatingを使い、 期間ごとの平均値を追います。Tagの一覧には条件に一致したTurnだけが表示されます。 • Presetから始め、必要に応じてCustom Signalを作る： まずはUser Frustration、Low Quality Response、User Satisfaction、Response QualityなどのPresetを選びます。 業務固有の基準が必要な場合はCustom Tagsまたは Custom Ratingを選び、Scorer prompt、Scorer名、評価に 使うInference modelを設定します。 • 評価対象と量を調整する：Advanced settingsでAgent、 Operation、Tool、ModelなどをFilterします。複数の FilterはAND条件で適用され、未指定の場合はすべての Turnが対象です。Trafficや推論Costが大きい場合は Sample rateを下げ、一部のTurnだけを評価します。 5. Trendからトレースへ掘り下げる：期間とFilterでScorer、Agent、Scoreを絞り、Score volumeと各行のTrendを確認 します。増加や低下が見られたSignalのTurnを開き、Conversationとトレースから入力、応答、Tool Callを調査しま contact-jp@wandb.com www.wandb.ai Page 22
24. 3. 継続的な評価体系の構築 す。期待する結果が表示されない場合は、Active signalsの設定に加え、トレーステーブルのScorer名とStatusを確認 します。 オンライン評価は、基本的に本番出力を受動的・非同期に評価する仕組みです。危険な操作を生成中に止めたい場合 は、Guardrailなどの同期的な制御を別に設計します。SignalsのScoreを、実行停止へ直接つなげないようにします。 まとめ AI Agentの品質管理が難しいのは、何を「良い」とするかがユースケースによって異なり、開発の初期段階では十分 なデータセットや評価基準が揃っていないからです。しかし、最初から完璧な評価体系を用意する必要はありませ ん。実際の出力を人が確認し、その判断と失敗例を少しずつデータセットやスコアラーへ変えていくことで、評価体 系を育てられます。 評価観点を選ぶときは、最終結果の正しさだけでなく、ゴールへ至る過程とTool Use、安全性、Cost、Latency、 Reliabilityまで目を向けます。すべての指標を一度に揃えるのではなく、「このAI Agentで、どの失敗を最も見逃した くないか」から考えると、必要な評価が見えやすくなります。評価の強度も一律にせず、Agentの権限、失敗したとき の影響、扱うデータの機密性などに合わせて決めることが重要です。 W&B Weaveでは、同じDatasetとScorerによる変更前後の比較、本番のトレースやMetricsの確認、W&B Weave Signals による問題の兆候の抽出を、一連の改善に利用できます。評価結果と実行過程を共通の証拠として残すことで、「な んとなく良くなった」という感覚ではなく、どこが改善し、どの課題が残っているかをチームで確認しながら開発を 進められます。 評価体系に完成形はありません。まずは、そのAI Agentで最も避けたい失敗を一つ選び、代表的な事例を評価できる 形で残すところから始めてみてください。本番から得た学びを次の評価と改善へ戻し続けることが、AI Agentの品質 を継続的に高める土台になります。 参考文献 • Demystifying evals for AI agents https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents • Writing effective tools for agents — with agents https://www.anthropic.com/engineering/writing-tools-for-agents • Quantifying infrastructure noise in agentic coding evals https://www.anthropic.com/engineering/infrastructure-noise • Physical AI at GSK | W&B https://wandb.ai/site/customers/gsk/ • W&B AI Agent LT会 Algomatic 宮脇氏資料 https://speakerdeck.com/smiyawaki0820/2024-dot-02-dot-19-w-and-b-aiezientolthui?slide=25 • Evaluations overview | W&B Weave https://docs.wandb.ai/weave/guides/core-types/evaluations • Compare evaluations | W&B Weave https://docs.wandb.ai/weave/guides/evaluation/compare_evals • Log evaluation data from your code | W&B Weave https://docs.wandb.ai/weave/guides/evaluation/evaluation_logger • Evaluation Playground | W&B Weave https://docs.wandb.ai/weave/guides/tools/evaluation_playground • View agent activity | W&B Weave https://docs.wandb.ai/weave/guides/tracking/view-agent-activity • Monitor your agents with signals | W&B Weave https://docs.wandb.ai/weave/guides/tracking/view-agent-signals • Set up automations | W&B Weave https://docs.wandb.ai/weave/guides/evaluation/automations • Set up guardrails | W&B Weave https://docs.wandb.ai/weave/guides/evaluation/guardrails contact-jp@wandb.com www.wandb.ai Page 23
25. 4. コスト最適化 4. コスト最適化 AI Agent活用を巡る議論は、まず取り組むことに意義がある段階から、2026年以降は費用対効果を問われる段階へ移 りつつあります。W&Bが日々多くの方とお話しする中でも、品質とコストの同時最適化への関心の高まりを感じま す。 コスト削減のためにAI Agentを導入しても、運用費用が想定以上にかかれば、期待した効果を得られません。AI Agentによるビジネス価値の創出に注目が集まる中、コストを抑えられる開発体制の整備が急務です。 安価なモデルに切り替えたとしても、複数回の推論とTool実行を繰り返すAI Agentでは失敗が増え、再試行や人手に よる確認が必要になれば、最終的なコストはむしろ上がります。高性能なモデルに全ての不要な履歴や巨大なTool定 義を毎回送信していれば、コストは高くつきます。見るべき指標は「100万Token当たりの価格」だけではなく、成功 タスク当たりの総コストになりますが、これを削減するのは簡単なことではありません。 コスト最適化は、品質や性能とのバランスを考える必要があるため、1つの手法だけで解決できるものではありませ ん。銀の弾丸はありませんが、主要なコスト削減手法を1つずつ理解し、実践することが重要です。このセクション では、代表的なコスト削減手法とコスト削減に向けたステップを紹介します。 コスト削減手法の大分類 AI活用の効率化は、大きく3つに分類できます。OpenAIのブログ"How GPT‑5.6 fuses frontier intelligence with frontier efficiency"では、次の3層に整理されています。 contact-jp@wandb.com www.wandb.ai Page 24
26. 4. コスト最適化 GPT-5.6の効率化をAgentハーネス、API orchestration、Model inferenceの3層に整理した図 Agentハーネス - Agentハーネスは、モデル、Tool、ユーザー環境をつなぐ実行基盤です。AI Agentは1つの依頼を完了 するまでに、モデルによる判断、検索、ファイルの読み取り、API Call、検証を何度も繰り返します。ループ内の1 秒、1 Request、1,000 Tokenの無駄は、反復回数に応じて増幅します。そのため、ハーネスでは次の3点が重要です。 毎回モデルへ渡す履歴、Tool定義、Tool出力を必要最小限にする - 同一の指示や処理結果を再利用し、同じ仕事を繰 り返さない - ループの停止条件、再試行回数、権限境界を明示する API orchestration - API orchestrationは、単なるモデル選択ではありません。同期か非同期か、単発かバッチか、直列 か並列か、モデルに判断させるか通常のコードで処理するかまで含めて、仕事の流し方を設計する層です。 - 同じモ デルを使っていても、全件をリアルタイムAPIへ送る構成と、緊急度の低い処理をBatchへ移す構成ではコストが異な ります。同様に、10個の独立した検索をモデルとの10往復で処理する構成と、コードで並列実行して要点だけをモデ ルへ戻す構成では、トークン量も待ち時間も変わります。 Model inference - Model inferenceは、リクエストをどの計算資源へ割り当てるか、GPU上の演算とメモリ移動をどう 最適化するか、生成済みの計算をどう再利用するかという領域です。 - モデルをホストする場所、利用可能容量、ア クセラレータ種別、Context長、Cache状況を考慮した負荷分散や、GPUカーネルの最適化、KV Cache管理、投機的デ コーディングなどにより、コストを削減できます。（投機的デコーディングとは、小型モデルが複数の候補Tokenを先 に提案し、主モデルがまとめて検証することで、逐次計算を減らす方法です） これらを総合的に考えながら、コスト削減を目指します。たとえば、推論基盤が20%効率化されても、AI Agentが不 要なModel Callを2倍行えば、その恩恵は容易に失われます。一方、API利用者は推論カーネルを直接書き換えられな くても、「何を何回、どれだけのContextとともに推論させるか」を制御できます。この部分には、大きな改善の余地 があります。 contact-jp@wandb.com www.wandb.ai Page 25
27. 4. コスト最適化 本書の主な対象は、モデルそのものを開発する研究者ではなく、APIを組み合わせてAI Agentを開発する人です。その ため、AgentハーネスとAPI orchestrationに絞って、実践的な方法を解説します。 コスト削減手法（Agentハーネス・API orchestration） AgentハーネスとAPI orchestrationに関する、代表的なコスト削減手法を紹介します。なお、実際の金額や仕組みにつ いては、OpenAIのAPIをメインに解説をしていきます。 • Prompt Caching • Compaction • Batch APIとFlex processing • Model Routing • Tool定義の遅延ロード • 独立したTool Callの集約によるModel Turnの削減 • ToolループとRetry Stormの分析・削減 • 実行予算と停止条件のガードレール Prompt Caching Prompt Cachingとは 長いSystem指示、共通の例、Tool定義などを毎回送るAI Agentでは、入力の多くがRequest間で重複します。Prompt Cachingは、入力の先頭から一致するPrefixの処理結果を再利用する仕組みです。一致した入力部分はCached Inputの単 価で課金されますが、出力Tokenの生成と課金は省略されません。 Prompt Cachingで実際にコストを抑えるには、後続RequestでCache Hitを増やす設計が必要です。OpenAIのPrompt Cachingガイドでは、Cache HitにはPrefixの完全一致が必要だと説明されています。同じ情報を含んでいても、入力の 先頭から内容と順番が一致していなければ再利用できません。 そのため、System指示、共通規約、Few-shot例、安定したTool定義などの固定内容を先頭にまとめ、ユーザー入力、 現在時刻、今回だけのTool Resultなどの可変内容を末尾に配置します。また、既存Contextは書き換えず、新しい MessageやTool Resultを末尾へ追加します。これにより、Requestを重ねても再利用できるPrefixを長く保てます。 文章だけでなく、画像、Tool定義、Structured OutputsのSchemaもPrefixの一部です。Cache境界より前では、内容と並 び順を揃える必要があります。 ※ Cacheがない初回は、対象Prefixを処理してCacheへ書きます。例えばOpenAIのGPT‑5.6以降では、このWriteにも料金 がかかります。したがって、同じPrefixをあと何回使うかまで含めて、初回のWriteを後続のReadで回収できるかを判 断します。 Implicit CachingとExplicit Caching (OpenAI) OpenAIのGPT‑5.6以降では、Cacheを自動判定するImplicit Cachingと、読み書きするPrefixを指定するExplicit Cachingを 利用できます。Implicit Cachingは設定が簡単ですが、暗黙のBreakpointまでに可変情報があると、その部分もRequest ごとに書き直されます。 固定部分だけを確実に再利用したい場合は、 prompt_cache_breakpoint で終端を示し、 prompt_cache_options.mode="explicit" を設定します。どちらの方式でも、同じ用途には安定した prompt_cache_key を使 い、次の値を観測します。 • cache_write_tokens ：今回Cacheへ書いた入力Token数 contact-jp@wandb.com www.wandb.ai Page 26
28. 4. コスト最適化 • cached_tokens ：今回Cacheから読んだ入力Token数 Cold RequestでWriteが増え、同じPrefixを使う後続RequestでReadが増えているかを確認します。Prefixが短い場合や頻 繁に変わる場合は、Write料金を後続のReadで回収できないことがあります。 料金と効果 OpenAIのPrompt Cachingガイドによると、GPT‑5.6以降では、Cacheへ書く入力Tokenは通常入力の1.25倍、Cacheから 読む入力Tokenは0.1倍の単価です。GPT‑5.6 LunaのStandard料金では、100万Token当たり、通常入力は $0.20 、Cache Writeは $0.25 、Cache Readは $0.02 です。 同じ100,000 TokenのPrefixだけを比較すると、Cacheを使わない場合は1回当たり $0.020 です。Prompt Cachingを使う場 合、初回のWriteは $0.025 になるため、1回だけで終わる処理では $0.005 高くなります。しかし、同じPrefixが2回目に Cache Hitすると、2回分の累積費用はCacheなしの $0.040 に対して、Cacheありは $0.027 です。つまり、この条件では2 回目からPrompt Cachingを使う方が安くなり、その後は再利用するたびに差が広がります。下の表は、同じ100,000 TokenのPrefixが初回に1回だけWriteされ、2回目以降は毎回Cache Hitする場合の単純な試算です。 同じPrefixの利用回数 Cacheなしの累積費用 Cacheありの累積費用 累積費用の差 1回 $0.020 $0.025 $0.005 高い 2回 $0.040 $0.027 $0.013 安い 5回 $0.100 $0.033 $0.067 安い 10回 $0.200 $0.043 $0.157 安い 例えば、2026年の論文Don't Break the Cacheでは、10,000 TokenのSystem Promptを使う500超のAgent Sessionを4つの Modelで比較しました。各Providerで選んだCache戦略では、API Costが41〜80%減り、TTFTが6〜31%短くなったとい う報告がなされています。 TTFTはTime to First Tokenの略で、Requestを送ってから最初の出力Tokenが返り始めるまでの時間です。回答全体が完 了するまでの時間ではなく、APIから回答が返り始めるまでの待ち時間を表します。この論文の結果は、Prompt CachingがAPI Costだけでなく、回答が始まるまでの待ち時間も短縮できる可能性を示しています。ただし、削減率は Benchmark、Model、Provider、Cache戦略によって異なります。 Prompt Cachingに関する詳しい情報は、以下のブログをご確認ください。 W&B note: APIコスト削減のためにPrompt Cachingを理解する Compaction Compactionとは AI Agentが長く動くと、会話履歴やTool ResultがContextへ蓄積されます。その状態でRequestを繰り返すと、以前の長 い入力も後続Turnへ引き継がれ、Token、Cost、Latencyが増える要因になります。 Compactionは、後続Turnに必要な状態を保ちながらContextを小さくする仕組みです。OpenAI Responses APIでは、過 去の重要な状態と推論を暗号化された compaction itemへ引き継ぎます。このItemは人が読む要約ではなく、APIが会話 を続けるためのデータです。 Prompt Cachingが同じPrefixの計算結果を再利用するのに対し、Compactionは次のRequestへ渡すContext自体を小さく します。ただし、CompactionにもToken、Cost、Latencyが発生します。長いContextをあと何Turn使うかまで含めて効 果を判断する必要があります。 contact-jp@wandb.com www.wandb.ai Page 27
29. 4. コスト最適化 OpenAI API：Server-side CompactionとStandalone Compaction OpenAI Responses APIには、2つのCompaction方式があります。 Server-side Compactionは、 responses.create に context_management と compact_threshold を設定する方式です。入力の Token数が設定した閾値を超えると、APIの処理中にCompactionが実行されます。別のCompact Callは不要です。長い 会話を継続しながら、圧縮のタイミングをAPI側へ任せたい場合に向いています。 Standalone Compactionは、アプリケーションが選んだタイミングで responses.compact を呼ぶ方式です。長いワークフ ローの区切りで圧縮したい場合や、Compact Call自体のToken、Cost、Latencyを分けて観測したい場合に向いていま す。返されたWindowには保持されたItemが含まれることがあるため、内容を削らず、そのまま次の responses.create へ渡します。 Compactionがある場合とない場合の比較 合成した監査記録320件を含む124,504 byteのTool Resultを使い、GPT-5.6 Lunaに請求情報に関する9問を順に尋ねる独 自実験を行いました。Model、質問、出力Schema、出力上限、採点方法は同一です。違いは、質問を始める前に Standalone Compactionを1回実行するかどうかだけです。結果はW&B Weaveでトレースし、コストを計算しました。 • Compactionなし： 長い function_call_output を全TurnのContextへ残します。 • Compactionあり： 最初にStandalone Compactionを行い、返されたWindowへ後続の質問と回答を追加します。 Compact Callを含む累積結果は次のとおりです。 後続Turn数 正答数 入力Tokenの変化 Costの変化 1 1/1・1/1 1.8%増 12.1%減 3 3/3・3/3 64.8%減 21.6%減 6 6/6・6/6 81.3%減 31.0%減 9 9/9・9/9 86.7%減 36.8%減 この実験では、どちらも9問すべてに正答しました。Compactionありの場合、9 Turn時点で入力Tokenが86.7%、Costが 36.8%下がりました。一方、Compactionを挟む分、全処理時間は約19.78秒から約22.41秒へ増え、13.3%長くなりまし た。 1 Turn時点では入力Tokenが1.8%増えており、Compaction自体の処理負担が見えます。後続Turnが多く、同じ大きな Contextを繰り返し送るワークフローほど、その先行負担を回収しやすくなります。導入判断では、品質を維持できる ことを前提に、Compact Callを含む全体を比較します。 Batch APIとFlex processing なぜ待ち時間がコスト削減になるのか すべての処理に即時応答が必要なわけではありません。評価、文書分類、データ補完、日次レポートなどは、対話中 に結果を返す必要がなく、後から受け取れればよい処理です。 Standardな処理は、Requestを受け取った後すぐにResponseを返す必要があるため、処理を後回しにできません。一 方、Batch APIは複数のRequestをQueueへ入れ、24時間以内に非同期で処理します。個々のRequestをすぐに開始する必 要がなく、OpenAI側は同期APIとは別の処理枠で実行タイミングを調整できます。そのため、Standardな処理の半額で APIを利用することができます。 contact-jp@wandb.com www.wandb.ai Page 28
30. 4. コスト最適化 Flex processingは、StandardとBatchの中間にある選択肢です。BatchのようにRequestをファイルへまとめる必要はな く、通常のResponses APIまたはChat Completions APIで service_tier: "flex" を指定します。応答の遅延やリソース不足 による未処理を許容する代わりに、Batchと同じToken単価で利用できます。評価やデータ補完など、低優先度で再試 行できる処理に向いています。こちらも、Standardな処理の半額でAPIを利用することができます。 このように、FlexとBatchはModelの処理量そのものを減らす仕組みではありません。即時性や確実な処理開始を優先 しない仕事を低価格な処理方式へ振り分けることで、コストを削減します。 Batch APIとFlex processingを実装した際のコスト削減効果 同じ100件の文書分類をGPT-5.6 Lunaで処理する場合を考えます。1件当たりの入力を10,000 Token、出力を1,000 Token とし、CacheやToolの追加料金は含めません。100件の合計は入力100万Token、出力10万Tokenです。 2026年8月15日時点のOpenAI公式料金にあるShort Context料金で試算すると、Standardは入力 $0.20 、出力 $0.12 、合計 $0.32 です。FlexとBatchはいずれも入力 $0.10 、出力 $0.06 、合計 $0.16 となり、Standardより50%低くなります。これ は公式料金に基づく試算であり、APIの実測結果ではありません。 同一の合成Job 5件を実際にStandard、Flex、Batchで処理した結果は、次のとおりです。処理時間と引き換えに、コス トが下がったことを確認できました。 処理方法 成功率 入力Token 出力Token Cost 処理時間（参考） Standard 100%（5/5） 910 130 $0.000338 Response中央値 1,430.6ms Flex 100%（5/5） 910 130 $0.000169 Response中央値 1,747.8ms Batch 100%（5/5） 910 130 $0.000169 Server上の完了時間 138秒 Model Routing 高性能モデルを全Requestへ使うのは簡単ですが、分類、定型抽出、短い要約まで同じ能力を必要とするとは限りませ ん。用途に合った小型モデル・低reasoning effortを利用することで、コストを抑えられます。 入力 ├─ 定型・低リスク ─→ 小型モデル・低reasoning effortまたは通常コード ├─ 中程度 ───────→ 標準モデル └─ 複雑・高リスク ─→ 高性能モデル・高reasoning effort + 厳格な検証 なお、ルーター自体を大きなモデルにすると、その判断コストが節約額を消すことがあります。ルール、文字数、 ファイル種別、ユーザーが選んだモードなど、決定的な情報で振り分けられる部分は通常のコードで処理します。モ デルによる分類が必要な場合も、小さな構造化出力に限定します。また、「まず小型モデル、失敗したら大型モデ ル」というカスケードは万能ではありません。失敗を確実かつ安価に検知できる場合に限って有効です。検知不能な 誤答が増える用途では、最初から適切なモデルへ送る方が、成功タスク当たりでは安くなります。 また、頻度高くモデルを切り替えると、Cachingの効果が得られなくなってしまうので、そうした目線での総合的な判 断も重要です。 Tool定義の遅延ロード Toolが増えると、JSON Schema、説明、利用条件が毎回入力に含まれます。使わないToolにもTokenを費やし、似た Toolが増えるほど、モデルが適切なToolを選ぶのも難しくなります。そのため、すべてのTool定義を最初から一律に渡 すのではなく、候補を目的別に絞り、必要になったTool定義だけをモデルが参照できるようにする必要があります。 これを実現する方法が、Toolのグループ分けと定義の遅延ロードです。 contact-jp@wandb.com www.wandb.ai Page 29
31. 4. コスト最適化 まず、Toolをユーザーの意図ごとにNamespaceやMCP Serverへ分け、モデルが少数の明確なグループから候補を選べる ようにすることが重要です。OpenAIのデプロイメントガイドでは、効率と性能のため、1つのNamespaceをおおむね10 関数未満に保つことを推奨しています。Descriptionは短く識別しやすい内容にし、詳細な手順は個々のTool側に置きま す。 その中で、Responses APIの tool_search と defer_loading: true を使って、Tool定義を遅延ロードします。Request開始時 には検索用Toolと短いDescriptionだけをモデルへ見せ、選ばれたToolの定義だけを後からContextへ読み込みます。な お、Tool実装については、テナントや権限によって利用できるToolが変わる場合はクライアント実行型、それ以外は ホスト型のTool Searchから始めるのが基本です。 独立したTool Callをまとめ、Model Turnを減らす 直列のAI Agentでは、ModelがTool Aを呼び、その結果を読んでTool Bを呼び、さらにTool Cを呼ぶたびにModel推論が 発生します。各Turnでは入力と出力のTokenが課金されるだけでなく、それまでのTool ResultがContextへ追加されるた め、後半のRequestほど入力Tokenが増えやすくなります。 直列: Model → Tool A → Model → Tool B → Model → Tool C → Model 集約: Model → Tool A・B・Cを並列実行 → 結果を集約 → Model 在庫、需要、価格の取得のように互いの結果へ依存しない処理では、途中でModelへ判断を戻す必要がありません。 まとめて実行すれば、Tool間のModel Turnを省けます。さらに、取得した結果をアプリケーションやプログラム内で 絞り込み、結合、集計し、必要な項目だけをModelへ返せば、後続Requestに追加する入力Tokenも減らせます。この2 点がコスト削減につながります。 選択肢は二つあります。 • アプリケーション側で依存関係を把握し、副作用のない読み取りToolを並列実行して結果をまとめます。 • Programmatic Tool Callingを使い、生成されたプログラム内で複数のToolを呼び、途中結果を絞り込み・結合・集計 して、小さな構造化結果をModelへ戻します。 Toolごとの利用料がある場合、A、B、Cの3件を同時に呼んでも3件分の料金が発生します。Costが下がるのは、Model Turnや入出力Token、重複したTool Callまで減らせた場合です。 各結果を見て次の行動を変える探索や、意味判断が必要な処理、承認を伴う書き込み操作には、Modelが結果を1つず つ確認する直接のTool Callが適しています。一方、Programmatic Tool Callingは、独立した構造化データの取得や、決 定的な絞り込み、結合、集計、検証に向いています。 なお、並列実行では、最大同時数、全体とTool別のTimeout、Retry上限、停止条件を明示しましょう。上限がなけれ ば、一度に不要なToolまで呼んだり、失敗した処理を繰り返したりして、かえってCostが増える可能性があります。 ToolループとRetry Stormの分析・削減 AI Agentは、目的を達成するまでModelによる判断とTool Callを繰り返します。この仕組み上、Toolの結果が不十分な 場合やErrorから回復する場合には、同じ処理へ戻ることがあります。適切な反復はAI Agentの自律性に必要ですが、 停止条件が曖昧であったり、失敗への対処方法が定まっていなかったりすると、進展のないToolループや過剰なRetry が生じます。 たとえば、検索結果が不足するたびに同じQueryを実行する、同じErrorに対して待機せずRetryする、SDKとアプリ ケーションの両方が同じRequestをRetryするといった現象です。個々のCallは妥当に見えても、Task全体ではModel Turn、入力Token、Tool利用料、Latencyが積み上がります。書き込みToolでは、同じ処理の再実行が二重登録や二重送 信につながる可能性もあります。 contact-jp@wandb.com www.wandb.ai Page 30
32. 4. コスト最適化 したがって、すべての反復を一律に止めるのではなく、Taskの完了に寄与していないループとRetryを検知し、原因ご とに減らす必要があります。 ガードレールを立てる ループを検知してから止めるだけでは、不要なCostがすでに発生しています。AI Agentへ「終わるまで調べて」とだけ 指示せず、Task開始時に実行予算と停止条件を渡します。 • 最大Model Call数 • 最大Tool Call数と、同一ToolのRetry上限 • 入力、出力、推論のToken予算 • 外部APIや有料Toolの費用上限 • 経過時間と無進展Turn数 • 高額Modelへ切り替えられる条件 上限へ達したこと自体を、単純な失敗として扱う必要はありません。予算内で証拠が不足した場合は、「判明したこ と」「不足している証拠」「実行済みの試行」「続行に必要な予算」を構造化して返します。これにより、人や上位 ワークフローが、終了、追加調査、別手段への切り替えを判断できます。 コスト削減に向けたステップ ここまで、コスト削減手法を見てきました。次に、コスト削減に向けたステップを見ていきます。コスト削減のヒン トとなる情報は、過去の実装に多く含まれています。実装をWeaveでログし、その結果を分析していきましょう。な お、以下の内容は、包括的なものではありませんが、観点としては参考になると考えています。 ステップ1：Batch・Flex処理が許容される範囲を決定する ユーザーが待つ処理はStandard、低優先度で再試行できる同期処理はFlex、評価や文書分類など即時性が不要な Request群はBatchの候補です。あわせて、推論方式の工夫によるコスト削減も検討します。互いに依存しない読み取り Toolは、同時実行数とTimeoutを決めたうえで並列化を検討します。並列化だけではTool Call数やTool利用料は減らな いため、Model Turnと中間結果のTokenまで減ったかを確認します。 ステップ2：タスク単位で可視化し、基準値を作る 必要となるToolコールの回数はAI Agentによって異なるので、最初に、代表的なタスクを使い、実際に実装をしなが ら、成功条件を決めます。成功／失敗、入力・出力Token、Model CallとTool Callの回数、Retry、Modelと外部Toolの 費用、完了時間のp95をW&B Weaveでタスク単位で記録し、おおよその目安を把握します。 ステップ3：明らかな重複と過剰なContextを減らす W&B Weaveでは、Token、Cost、Latencyなどで並び替えることができます。まずコスト上位のタスクを並べ、「入力 が長い」「出力が長い」「Modelとの往復が多い」「失敗してやり直している」「外部Toolが高い」のどこに費用が 集中しているかを確認します。次に、高コストなトレースをCall単位まで掘り下げ、同じErrorへのRetry、全履歴の再 送、未使用のTool定義、巨大なTool Resultを探します。いずれも、Modelの能力や実行方式を変える前に減らせる可能 contact-jp@wandb.com www.wandb.ai Page 31
33. 4. コスト最適化 性がある無駄です。W&B Skillsを使ってCoding Agentに分析させるのも1つの手段です。まずはこの段階でTool loopな どの異常があれば、解消をし、その上で、Modelへ渡すTool情報とContextを減らしていきます。 1. ToolのNameとDescriptionを具体化する Modelが似たToolを取り違えないよう、Nameから1つの操作が分かるよう にします。Descriptionには「いつ使うか、いつ使わないか」「必要な入力」「返却Fieldと型」「Error時の動作」を 明記します。共通規約は各Toolに重複して書かず、System指示に一度だけ置きます。たとえば、 manage_invoice の 「請求書を処理する」では用途が広すぎます。読み取り専用なら、 get_invoice_status を「 invoice_id から status 、 amount 、 updated_at を返す。未検出時は NOT_FOUND 。更新には使用しない」のように定義し、選択条件と 返却契約を判別できるようにします。詳しくはOpenAIのModel guidanceを参照してください。 2. Tool Resultに出力契約を設ける 検索結果やLogが大量にある場合は、すべてを一度にModelへ返さず、アプリケー ション側で分割します。Toolの入力には、1回に返す最大件数を表す limit 、返してほしい項目を表す fields 、前回 の続きから取得するための位置情報を表す cursor を設けます。最初のCallでは cursor を指定しません。返却された next_cursor を次のCallの cursor へ渡すと、続きのデータを取得できます。 next_cursor が null なら、続きはありま せん。 OpenAIのProgrammatic Tool Callingガイドでは、戻り値の形を事前に決められるToolについて、 output_schema でFieldと 型を定義するよう推奨しています。全文、HTML、長いLogはアプリケーション側へ保持し、Modelには判断に必要な 項目だけを返します。たとえば、請求書の検索結果なら、対象データ、元データを再取得するための evidence_ids 、 続きの位置を表す next_cursor 、Errorの種類を表す error_code に絞ります。詳細が必要になったときだけ、 evidence_ids から元データを再取得します。 json { "items": [{"invoice_id": "INV-1043", "status": "overdue"}], "evidence_ids": ["ledger_204"], "next_cursor": "invoice_page_2", "error_code": null } 3. Tool定義を必要なときだけ読み込む ToolをUser IntentごとにNamespaceまたは MCP Serverへ分け、NamespaceのDescriptionも短く、用途を区別できる内容にします。Responses APIでは、API deployment checklistにある tool_search と defer_loading: true を使うと、最初から全Tool定義をContextへ入れず、必要な 定義だけを後から読み込めます。 1. 独立した読み取りToolの並列化を検討する 互いに依存しない読み取りToolは、同時実行数とTimeoutを決めたうえ で並列化を検討します。並列化だけではTool Call数やTool利用料は減らないため、Model Turnと中間結果のTokenま で減ったかを確認します。 2. Contextを整理し、Compactionの方法も検討する。 まず、次のTurnに必要な情報だけを残します。固定指示、決定 事項、未解決事項、必要な証拠IDは残し、取得済みの全文、巨大なTool Result、完了した処理の中間出力は持ち越 しません。それでもContextが増え続ける長時間ワークフローでは、入力Tokenが閾値を超えたときに自動実行する Server-side Compactionと、ワークフローの区切りで実行するStandalone Compactionのどちらが適切かを検討しま す。適用タイミングと閾値を変え、品質、入力Token、Cost、Latencyを同じタスクで比較します。 変更後は同じタスクを再実行し、成功率と必要な証拠を維持したまま、入力Token、Model Turn、Tool Call、Retry、 Costが減ったかを確認します。weave.Evaluationで代表的なタスクをまとめて実装するようにしておくと、Tokenやコス トなどの比較がわかりやすい可視化付きで確認することができます。 ステップ4：安定したPrefixを作れる処理を見極める 同じ種類のタスクを複数回実行したとき、入力の先頭に繰り返し使える固定部分があるかを確認します。System指 示、共通規約、Few-shot例、Tool定義をタスク間で共通化でき、ユーザー入力、現在時刻、Request ID、今回だけの Tool Resultを後方へ分離できる処理が候補です。 W&B WeaveのトレースをAPIでExportするか、W&B Skillsを使ってCoding Agentで直接分析し、安定したPrefixを作れ る処理かを特定します。候補が見つかったら、固定部分を入力の先頭へ移し、Tool定義の内容と並び順を固定しま す。その後、同じ代表タスクでCold Requestと後続のReuse Requestを実行します。 contact-jp@wandb.com www.wandb.ai Page 32
34. 4. コスト最適化 ステップ5：ルーティングを行う ここまでのトレースからタスクの難易度、失敗リスク、即時性を整理し、Modelと実行方式を振り分けます。定型・ 低リスクな処理は通常のコードまたは小型Model、複雑・高リスクな処理は必要な能力を持つModelへ送ります。安価 な構成で開始し、必要に応じて高性能Modelへ昇格する場合は、失敗を安全かつ低コストで検知できる条件を先に定 義します。 ただし、前のチャプターでも解説をした通り、ルーター自体を大きなモデルにすると、その判断コストが節約額を消 すことがあります。ルール、文字数、ファイル種別、ユーザーが選んだモードなど、決定的な情報で振り分けられる 部分は通常のコードで処理します。モデルによる分類が必要な場合も、小さな構造化出力に限定します。また、「ま ず小型モデル、失敗したら大型モデル」というカスケードは万能ではありません。失敗を確実かつ安価に検知できる 場合に限って有効です。検知不能な誤答が増える用途では、最初から適切なモデルへ送る方が、成功タスク当たりで は安くなります。 また、頻度高くモデルを切り替えると、Cachingの効果が得られなくなってしまうので、そうした目線での総合的な判 断も重要です。 ステップ6：ループとRetryへ予算と停止条件を設ける 次に、最大Model Call数、最大Tool Call数、同一ToolのRetry上限、Token、経過時間、外部費用、無進展Turn数へ上限 を設定します。高性能Modelへ切り替える条件も、Task開始時に決めます。 設定した上限までにTaskが完了しなければ、その時点で処理を停止します。そのうえで、「確認できたこと」「不足 している証拠」「実行済みの試行」「続行に必要な追加のTool Call数、Token、時間、外部費用」を構造化して返しま す。人または上位ワークフローは、この情報を見て、終了するか、条件や予算を変更して続行するかを判断します。 ステップ7：同じ評価セットで比較し、設定を詰める コストと品質はトレードオフの関係にあります。コスト最適化の後は、1つのタスクだけでなく、代表的なデータ セットを用いて、品質が低下していないことと、コストを削減できたことの両方を確認します。 W&B WeaveのEvaluationで評価体系を構築すると、評価をすぐに実装できます。また、品質とコストのバランスを分 かりやすく可視化しながら、結果を確認できます。 まとめ AI Agentのコスト最適化では、安価なModelへ切り替えることや、1回のAPI Requestを安くすることだけでは達成でき ません。Retry、Tool Call、長いContext、人手による確認まで含め、品質要件を満たした成功タスク当たりの総コスト を下げることが重要です。 そのためには、タスクの特性に合わせて複数の手法を組み合わせます。即時性が不要な処理はBatchやFlexへ振り分 け、安定したPrefixはPrompt Cachingで再利用します。長時間のワークフローではCompactionを検討し、Tool定義や Tool Resultは必要な範囲へ絞ります。互いに依存しない読み取りToolは、同時実行数やTimeoutを定めたうえで並列化 します。さらに、タスクの難易度に応じてModelとreasoning effortを選び、ループやRetryには予算と停止条件を設けま す。 ただし、どの手法にも適用条件とトレードオフがあります。Prompt CachingにはCache Write、Compactionには圧縮処 理、BatchやFlexには待ち時間が伴います。並列化してもTool Call数やTool利用料が減るとは限りません。単価やToken だけではなく、Quality、Latency、Cost、Riskを同じ条件で比較する必要があります。 contact-jp@wandb.com www.wandb.ai Page 33
35. 4. コスト最適化 最初の一歩は、代表的なデータセットと成功条件を決め、現在の入力・出力Token、Model Call、Tool Call、Retry、 Latency、Costを基準値として記録することです。W&B Weaveのトレースで高コストな処理や無駄な反復を特定し、変 更後は同じDatasetを使ったEvaluationで品質とコストを比較します。この計測、改善、再評価の反復が、品質を維持し ながらコストを継続的に最適化するための基本になります。 参考文献 • Cost optimization https://developers.openai.com/api/docs/guides/cost-optimization • Compaction https://developers.openai.com/api/docs/guides/compaction • API deployment checklist https://developers.openai.com/api/docs/guides/deployment-checklist#use-tool_search • OpenAI Prompt caching https://developers.openai.com/api/docs/guides/prompt-caching • OpenAI GPT‑5.6 Luna https://developers.openai.com/api/docs/models/gpt-5.6-luna • OpenAI Pricing https://developers.openai.com/api/docs/pricing • Elias Lumer et al. Don't Break the Cache: An Evaluation of Prompt Caching for Long-Horizon Agentic Tasks https://arxiv.org/abs/2601.06007 • Programmatic Tool Calling https://developers.openai.com/api/docs/guides/tools-programmatic-tool-calling contact-jp@wandb.com www.wandb.ai Page 34
36. 5. 多くのAI Agentを開発・改善・保守する体制の構築 5. 多くのAI Agentを開発・改善・保守する体制の構築 Coding Agentの登場によって、ソフトウェアやAI開発の進め方は大きく変わりつつあります。以前は、人間がコード を書き、AIは補助的に候補を出す存在でした。しかし2025年以降は、Coding Agentがリポジトリを読み、実装し、テ ストを実行し、失敗を見て再計画するところまで担うようになってきました。 増え続けるAI Agentの開発依頼に限られたエンジニアで対応するには、共通の開発基盤やテンプレートを整えるだけ では不十分です。リリース後も続く評価、改善、保守の負荷を抑えるために、Coding AgentをAI Agentの開発プロセス へ組み込み、失敗の分析、変更候補の作成、評価を反復できる自己改善（Self-improvement）の仕組みが注目されてい ます。 OpenAIの共同創業者の一人であり、2025年2月にXでvibe codingという表現を広めたAndrej Karpathyが、2026年3月にX で、Self-improvement(Xの中ではAutoResearchという言葉がメインで使われています)に関する投稿を行い、2026年に入 り、さらに注目を集めています。 ただし、Coding Agentを用いた自己改善は、業界全体でも実践知が蓄積されている途上にあり、どの作業をCoding Agentへ任せ、どこに評価基準、権限、停止条件、人間の承認を置くべきかは、まだ自明ではありません。論文レベ ルでは、自律的な長時間の実装でモデルやAI Agentを改善する事例が提案されていますが、実践レベルでは1、2ター ンの自動実装が現実的な範囲です。この章は、自己改善といえども、人の介入が入る逐次的な改善を前提に解説をし ます。 手元のリポジトリでさまざまなハーネスを構築しず、実装結果や評価結果、実装プランの保存を外部化し、プロジェ クト横断で利用できるハーネスを構築することができます。手元のリポジトリをシンプルにすることができるので、 改善の再開や引き継ぎもしやすくなります。 自己改善をAI Agentの改善で利用する上では、チームで再利用できるハーネスを設計することが重要になります。 W&B Weaveは、共有・検索可能なトレースや評価結果を蓄積することができます。W&B Weave上にあるデータを、 W&B SkillsとW&B MCP Serverを通じてCoding Agentから抽出するパイプラインを提供しており、W&B Weaveを利用 するだけで、自己改善のハーネスの一部を設計することができます。具体的には、大量の実行・評価証拠をCodeのリ ポジトリから分離できるため、リポジトリの肥大化を抑えながら、組織で共有できる改善プロセスを構築できる効果 があります。 本章では、自己改善を支えるハーネスの設計、その難しさ、W&Bを組み込んだ段階的な実践方法を説明します。 自己改善のためのハーネス設計 Coding Agentによる自己改善を実現するには、単に「コードを変更して、評価し、結果が悪ければもう一度変更す る」という指示を与えるだけでは不十分です。重要なのは、Coding Agentが長時間の改善作業を安定して継続できる ように、どのように作業し、何を記録し、どのように結果を評価し、いつ継続・停止するのかを取り巻く仕組み(ハー ネス)として設計することです。 Lilian Wengによる自己改善のためのハーネス設計の解説に、自己改善のために必要なハーネスがまとまっています。 以下、この記事で解説されている自己改善のためのハーネス設計を紹介します。 従来のAgent Frameworkでは、Agentを「LLM + Memory + Tools + Planning + Action」のような構成要素として捉えるこ とが一般的でした。ハーネス設計では、その外側にあるワークフロー、評価、権限制御、状態管理までを設計対象と します。つまり、良いPromptを書くことだけではなく、Coding Agentが観察し、実行し、結果を検証し、失敗から学 び、次の行動へ進めるRuntimeを設計するという考え方です。 contact-jp@wandb.com www.wandb.ai Page 35
37. 5. 多くのAI Agentを開発・改善・保守する体制の構築 自己改善のハーネスを考える上では、特に「改善ループ」「永続的な状態」「評価と停止条件」の3つを分離して考 えると理解しやすくなります。 改善を一度の生成ではなく「ループ」として設計する 自己改善の基本は、一度のコード生成ではなく、Plan → Execute → Evaluate → Analyze → Improveという反復的なルー プです。Coding Agentは、過去の実行・評価結果を確認して改善仮説を立て、コードを変更し、テストやEvaluationを 実行します。結果が改善しなければ原因を分析し、別の変更を試します。 重要なのは、Agentに「改善を繰り返せ」と指示するだけでなく、何をもって改善とするかをハーネス側で定義する ことです。Accuracy、Latency、Costなどの評価指標やRegression Testを設定し、一定回数改善しなければ停止すると いった条件も用意します。 AgentのMemory設計 自己改善を繰り返すと、実行ログ、Evaluation結果、コード差分、失敗した仮説などが蓄積されます。これらをすべて Context Windowに保持する方法は、長期的にはスケールしません。 そのため、実装計画や状態をファイル、コード変更をGit、トレースやEvaluationを外部システムに保存し、Agentが必 要なときに必要な情報だけを取得できる設計にすることが重要です。ここでWeaveを利用することができます。 特にチームで利用する場合、実行・評価結果を個々のリポジトリから分離して共有可能な場所に蓄積することで、リ ポジトリをシンプルに保ちながら、別のAgentやプロジェクトでも過去の改善結果を再利用できます。 評価・権限・停止条件をハーネスに組み込む 自己改善では、Agentに高い自由度を与えるほど、意図しない変更や評価指標への過剰適合といったリスクも高まり ます。そのため、何をAgentに任せ、どこで停止し、人間に判断を戻すかをハーネスとして設計する必要があります。 例えば、コード変更とテストまでは自動化し、本番Deployには人間の承認を求めることができます。また、Evaluation が基準値を下回った場合や、一定回数改善が見られない場合には処理を停止します。 自己改善は必ずしも完全自律化を意味しません。現在のCoding Agentでは、数回の実装と評価をAgentが行い、重要な 判断では人間が介入するHuman-in-the-loop型の改善が現実的です。 自己改善の難しいポイント 自己改善のハーネスを作れば、Coding Agentが長時間動き続ける環境は用意できます。しかし、ループが最後まで動 いたことと、正しい改善ができたことは同じではありません。もっともらしい成果物を作れても、参照情報の誤り、 当初の設計からの逸脱、弱い実験結果を見落とす可能性があります。 TrehanとChopraによる2026年の事例研究では、6つのLLM Agentを使い、研究アイデアから論文を作るまでの4件の試 行を検証しました。そのうち3件は実装または評価で失敗し、最後まで完了したのは1件だけでした。主な原因は、古 いLibraryや一般的な実装への偏り、難しい実装を避けることによる当初設計からの逸脱、長期TaskでのContextの劣 化、失敗を成功と判断する過度な楽観、専門知識の不足、重要な問いに答えていない実験設計です。4件だけの事例 であり、Coding Agent全般の成功率を示すものではありません。それでも、ハーネスを長時間動かすだけでは、正し い成果を得られるとは限らないことが分かります。 contact-jp@wandb.com www.wandb.ai Page 36
38. 5. 多くのAI Agentを開発・改善・保守する体制の構築 Lilian Wengの解説は、自己改善を実用化する上で残る課題を七つに整理しています。これらをAI Agent開発へ当ては めると、次の設計課題が見えてきます。 1. スコアラー：多くの研究上の主張や現実のTaskには、結果の良し悪しを高速かつ厳密に判定できる検証手段があ りません。現在の自己改善ループは、評価指標を客観的に測定できるTaskで最も機能しやすいものです。一方、問 題設定の妥当性、新規性、長期的な価値は簡単には測れません。どの意外な結果を追究し、どの失敗を再試行す るかという判断も必要です。そのため、一つのスコアラーだけに頼らず、複数のスコアラー、データセット、人手 評価を組み合わせていきますが、その設計によって結果が変わってくるところに注意が必要です。 2. 文脈と記憶の寿命：AI Agentの自律性が高まり、実行期間が長くなるほど、必要な記憶も増えます。現在のLong Contextには限界があるため、ハーネスはContextとMemoryを管理し、長期Taskを継続できる状態を保つ必要があり ます。何を永続的な証拠として残し、何を要約し、必要なときにどう検索するかを設計します。Context Engineeringは、単なるソフトウェア層の工夫ではなく、長期Taskを支える中核的な機能になります。 3. 失敗結果の欠落：研究成果や学習データは、公開されやすい成功例に偏ります。そのため、LLMは、仮説をいつ 諦めるか、失敗をどう報告するか、結果が失敗だったと認めるかという判断を苦手とする可能性があります。 ハーネスには、失敗した仮説、変更内容、実行条件、評価結果、却下理由を残します。失敗から学べる状態を作 ることで、同じ試行を繰り返さず、探索範囲を絞り込めます。 4. 多様性の崩壊：進化的な探索や強化学習のループは、既知の高い報酬を得られるPatternを利用する方向へ進みま す。その結果、変更候補が似た解決策へ収束する可能性があります。正解が一つに定まらないTaskでは、最も有望 な経路が現在のEvaluatorでは劣って見えることもあります。複数の仮説を残し、異なる条件や失敗ケースで比較で きる仕組みが必要です。 5. 報酬ハッキング：自己改善ループは、与えられた評価信号を最適化します。Unit Testを使えばTestへ過剰適合し、 Judge Modelを使えばそのModel固有の判定傾向を利用し、Benchmarkを使えばその構造上の抜け道を利用する可能 性があります。そのため、Coding Agentが、自分を評価する基準や与えられた権限まで自由に変更できる状態は避 けます。改善中には見せないHoldoutデータセットで結果を確認し、トレースを監査し、重要な変更は人間が Reviewします。こうした監督をどこまで自動化できるかは、現在も研究途上です。 6. 保守性：Coding Agentは目の前のTaskを完了できても、多くのエンジニアが共同で管理するリポジトリの健全性ま で守れるとは限りません。一般的なSandbox内の評価では、保守性、Ownershipの境界、Migration Cost、後方互換 性、将来のDebug負荷を十分に捉えにくいためです。短期的なScoreだけでなく、Regression Test、Code Review、変 更範囲、運用後のトレースを確認する必要があります。 7. ヒューマン・イン・ザ・ループ：人間をループから外すのではなく、より上位の判断へ役割を移します。改善目標 を定める、曖昧な結果を解釈する、探索を続けるかを決める、影響の大きい変更を承認するといった判断は人間 に残ります。ハーネスには、人間が適切な時点と抽象度で介入できる接点を組み込む必要があります。 自己改善をどこまで自動化するかは、上記の観点をどこまでクリアできるかに依存してきます。次のチャプターで は、W&Bが自己改善の中でどのような価値を提供していくのかを見ていきます。 contact-jp@wandb.com www.wandb.ai Page 37
39. 5. 多くのAI Agentを開発・改善・保守する体制の構築 自己改善ハーネスのメモリとしてのW&B 自己改善でCoding Agentの性能を引き出すには、どの バージョンを評価・運用したのか、本番で何が起きたの か、変更後に結果がどう変わったのかを検索できる必要 があります。バージョン情報、Evaluation、本番のト レースをW&B Projectへ残すことで、Coding AgentとTeam 全員が同じ証拠を参照できます。さらに、W&B Skillsや W&B MCP Serverを使って権限の範囲内で必要な情報を Coding Agentから検索・抽出したり、Evaluationの分析手 順を再利用できます。W&Bを利用することで、個人の 記憶や手元の運用に依存せず、改善を再開・再現しやす い足場になります。 Lilian Wengの解説でいうMemoryの役割のうち、W&Bは 実行・評価証拠を永続的に残す部分を担います。Codeと 変更履歴はGitHubに残し、大量のトレースやEvaluationはW&Bへ分けて保存することで、リポジトリの肥大化を抑え ながら、Coding Agentによる開発を進めることができます。 Senpai: W&Bが提供する自己改善ハーネスのテンプレート Senpaiは、Coding Agentが学習Codeと実験条件を変更し、対象Modelの学習レシピを反復改善するための、半自律的な ML研究ハーネスです。論文で報告された実験では、AdvisorとStudentはいずれもClaude CodeをHeadless modeで動かし ていました。現行リポジトリはOpenHands Agent SDKへ移行しています。 Model学習を対象とした事例ですが、作業状態を外部に残し、人間が同じ証拠を確認しながら改善を進める設計は、 Coding Agentを用いた開発にも通じます。W&Bが自己改善ハーネスの例としてGitHubで公開しています。この中で は、Advisorが実験を提案・Reviewし、複数のStudentが実装と学習を担当します。実験の証拠はGitHubとW&Bへ返さ れます。リポジトリには、W&BのRun、Metric、Artifact、Evaluation、Agentトレースを調べるためのSkillも組み込ま れています。 Senpaiは、Observabilityを優先する研究ハーネスとして設計されています。その論文は、ICML 2026 AI for Science Workshopで採択・発表されました。SenpaiはあらゆるAI Agentを自動的に正しく改善する製品ではありませんが、自 己改善ハーネスの具体例として参考になるかと思います。 contact-jp@wandb.com www.wandb.ai Page 38
40. 5. 多くのAI Agentを開発・改善・保守する体制の構築 Senpaiの薄いハーネスがKubernetes上のAdvisorと複数のStudentを動かし、対象リポジトリでの変更をGitHub PRとGit履歴へ、実 験結果をW&B Runsへ残し、人間がReview、Issue、Fleet controlから介入する構成 GitHubとW&BをメモリにしたSenpaiの構成 SenpaiはKubernetes上で動きます。実験を提案・ReviewするAdvisorは1つのCPU Pod、実装と学習を担当するStudentは 複数のGPU Podで実行します。データセットやCheckpointは、各Podから利用できる共有の永続Volumeへ保存します。 Senpaiのハーネスは、同じContainer Imageを使いながら、実験対象のリポジトリだけを差し替えられます。実験で作ら れたBranch、Commit、PRはハーネス側ではなく、研究者が普段確認する対象リポジトリに残ります。 Senpaiの中心原則は、実験に関する正本をAgentのMemoryやLocalのScratchpadへ置かないことです。仮説、Code変 更、学習結果、Reviewの判断を、既存の開発・研究Toolから永続的に参照できる形で残します。そのため、Senpaiの 実験台帳は、次の二つのRecordを結びつけています。 Record 残す情報 GitHubのPRとGit履歴 仮説、実装指示、Code Diff、Studentの報告、AdvisorのReview、最終判断 W&Bの実験Record 実験設定、Metric、Checkpoint、System情報、Agentトレース この二つを結びつけることで、Coding Agentは過去の実験を検索し、研究者は同じ証拠をGitHubとW&BのUIから確認 できます。個々の実験を監査するだけでなく、複数の実験を横断して研究全体の進捗を振り返ることもできます。 Advisorは、現在のBaseline、データセットに関する注意点、未検証の研究方針などをMarkdownにも要約します。ただ し、これらは判断を速くするためのCacheです。Markdownの要約とPR、Git履歴、W&Bの実験Recordが矛盾した場合 は、後者から構成される実験台帳を正本として扱います。これにより、AgentのContextが圧縮されたり、Processが中 断・再開されたりしても、研究の経緯を外部の証拠から復元できます。 この実験台帳を使い、AdvisorとStudentは次のPR Lifecycleで実験を進めます。 1. Advisorが仮説を実験へ変換します。Advisorは現在の実験台帳を読み、必要に応じて文献検索を行います。その上 で、仮説、実装方針、目標Metric、Baseline、終了条件を記載したDraft PRを作り、担当するStudentをLabelで指定 します。 contact-jp@wandb.com www.wandb.ai Page 39
41. 5. 多くのAI Agentを開発・改善・保守する体制の構築 2. Studentが実装と学習を行います。GPUを割り当てられたStudentは、自分に割り当てられたPR Branchを取得し、学 習Codeや実験設定を変更します。学習を実行し、結果をW&Bへ記録します。 3. Studentが証拠をPRへ返します。実行Command、W&B RunへのLink、主要Metric、結果の解釈をPR Commentとして 報告します。Code Diffと実験結果が同じPRから追跡できる状態になります。 4. AdvisorがBaselineと比較します。Advisorは提示された証拠を確認し、改善をMergeするか、追加の修正を求める か、有用な失敗としてPRをCloseするかを判断します。MergeされたPRは、次の仮説で使う研究ProgramのBaseline を更新します。 この構成では、Agent同士のやり取りを一時的な会話だけに閉じません。一つの仮説が、どのCode変更とW&B Runに つながり、どの理由で採用または却下されたかが、通常のPR履歴として残ります。 人間も、この実験台帳へGitHub IssuesとPR Commentから介入できます。研究者はGitHub Issuesを通じてAdvisorまたは Studentへ指示し、特定の実験に対する助言をPR Commentから伝えられます。これにより、別の管理画面を常時監視 しなくても、普段の開発ワークフローから研究ループへ介入できます。 この介入経路は、継続的に付きっきりで指示するためのものではありません。Senpaiは、人間が必要な局面でのみ方 向を修正するSparse Steeringを前提としています。IssueやCommentは、それによって影響を受けた実験のRecordに結び つくため、誰がどの時点で何を変えたのかを後から確認できます。 定型的な制御をLLMから分離する 実験状況の確認にLLMは使いません。通常のProgramであるWrapperが、ReviewできるPR、人間から届いたIssueや Comment、作業可能なStudentがあるかを定期的に確認します。対応するものがなければ、そのまま待機します。仮説 の検討や結果のReviewなど、研究上の判断が必要なときだけAdvisorを起動または再開します。これにより、単なる状 態確認でContextやCostを消費せず、LLMを研究上の判断に集中させられます。 Senpaiの設計を自己改善ハーネスの参考にする Senpaiの構成を、そのまますべてのProjectへ導入する必要はありません。自社の自己改善ハーネスを設計する際に は、個別の実装ではなく、次の三つの考え方を参考にできます。 1. 実験状態の外部記録 仮説とCode変更はGitHubへ、学習条件と結果はW&Bへ保存。Agentの内部状態だけに依存せ ず、中断後も再開できる実験管理。 2. シンプルな自律ループ 仮説の立案、実装、結果の解釈はAgent、Polling、状態遷移、停止条件などの定型処理は Programという役割分担。 3. 人間とAgentが共有する実験台帳 情報をCoding Agent専用のMemoryへ閉じず、人間もPR、Issue、W&B Runから検 索・Reviewできる情報管理。 是非、Senpaiを参照しながら、Code変更、学習、比較、Reviewを繰り返す自己改善ハーネスを構築してみてくださ い。 ARIA（AI Research and Iteration Agent） W&Bは、W&B SkillsやW&B MCP Serverを通じて外部のCoding AgentをW&Bの実験・評価証拠へ接続するだけでな く、W&B UI上でも分析から次の実験までを進められるように、CoreWeave ARIAを開発しています。ARIAはW&B UI に組み込まれたAI Research and Iteration Agentであり、Coding Agentとは異なる製品機能です。2026年8月時点では Previewとして提供されています。 contact-jp@wandb.com www.wandb.ai Page 40
42. 5. 多くのAI Agentを開発・改善・保守する体制の構築 ARIAは、権限の範囲内でProjectのデータを自然言語で分析することを可能にします。Patternの発見、仮説や次の実験 の提案、可視化、WorkspaceやReportの作成を支援します。W&B Launchを利用できる環境が設定されている場合は、 利用者の承認を経て実験を提出し、結果を比較して次の実験を提案することもできます。 W&Bは、外部のCoding Agentとの接続とARIAの両面から、W&Bに蓄積した証拠をAgentによる分析と改善へつなげる 機能の開発に力を入れています。 詳しくはARIAの概要とCoreWeave ARIAを参照してください。ARIAの動作は公式デモ動画で確認できます。 まとめ 増え続けるAI Agentの開発・改善・保守へ限られたエンジニアで対応するには、共通の開発基盤やTemplateに加え、 Coding Agentが分析、変更、評価を繰り返せる自己改善のハーネスが必要です。ただし、自己改善の難易度が高いた め、評価基準、Memory、権限、停止条件、人間の承認まで含めて設計することが重要です。 W&Bにバージョン情報、Evaluation、本番トレースを残し、W&B SkillsやW&B MCP Serverから検索できるようにする と、Coding AgentとTeamが同じ証拠を参照できます。Codeと大量の実行・評価証拠を分けて管理することで、リポジ トリの肥大化を抑え、改善の再開、再現、引き継ぎをしやすくできます。 Senpaiは、GitHubとW&Bを実験台帳として使い、Coding Agentと人間が長期の研究ループを進めるハーネスの具体例 です。こうした例を参考にしながら、証拠の検索や失敗分析から始め、Evaluationと人間のReviewを保ちながら、 Coding Agentへ任せる範囲を段階的に広げていきましょう。 参考文献 contact-jp@wandb.com www.wandb.ai Page 41
43. 6. 終わりに 6. 終わりに AI Agentを作ることは、価値創出のスタートにすぎません。継続的な評価、コスト最適化、開発・改善・保守の仕組 みがなければ、利用の拡大や技術の変化に対応し続けることは困難です。これらを支える環境の構築は、もはや「あ ると望ましいもの」ではなく、AI Agentを事業で活用し続けるために欠かせない取り組みです。 本書では、そのために必要な実践を三つの観点から整理しました。 • 継続的な評価体系の構築：人の判断と本番の失敗をデータセットやスコアラーへ反映する、オンライン評価とオ フライン評価の循環。 • コスト最適化：トレースからToken、Cost、Latency、Retry、Tool Callを把握し、同じ評価条件で品質維持を確認す る改善プロセス。 • 多くのAI Agentを開発・改善・保守する体制の構築：共通のハーネスと実行・評価証拠を整え、Evaluationと人間 のReviewを維持しながら、Coding Agentへ任せる範囲を段階的に広げる運用体制。 W&B Weaveは、トレース、Evaluation、実験の証拠を共有・検索可能な形で蓄積し、観測・評価・改善・最適化をつ なぐ基盤になります。W&B Weaveを用いて、何が起きたのか、変更によって結果がどう変わったのかを確認できるた め、チームは証拠に基づいて次の改善を判断できます。 AI Agentを支えるAgentOpsは、現在も発展途上です。Model、Tool、ハーネス、評価手法が日々進化するなかで、最初 から完成形を作ることはできません。だからこそ、日々進化するAgentOpsの実践知を取り込みながら、運用の仕組み を作ることが大切です。W&B Weaveをその共通基盤として活用し、AI Agentが価値を生み出し続けられる環境を育て ていきましょう。 本書も、AI AgentとAgentOpsの進化に合わせて更新を続けます。最新情報は、W&B Japan公式noteとW&B Japan公式X でお知らせします。 参考文献 contact-jp@wandb.com www.wandb.ai Page 42