はい、こんにちはー！クロス イノベーション 本部 サイバーセキュリティテクノロ ジー センターの福山です。 2025年もReact2Shellなどを筆頭に多くの 脆弱性 情報が公表されました。 公開された 脆弱性 情報の傾向を1年単位で振り返ってみたいと思い、各種サイトの API を用いて収集し、分析してみました。 収集対象のデータ 2025年 分析結果 深刻度レベル別（2024／2025年） 深刻度レベル別（2025年月別） NVDステータス別 攻撃コード公開済み脆弱性の割合（PoC／MSF） 悪用確認済み脆弱性の割合（CISA KEV）／製品内訳（上位5製品） RCE可能な脆弱性の割合／悪用確認済みネットワーク機器内訳 CWE別件数（上位10位） CWE別リスク分布 CVE別／2025年最も危険な脆弱性4選 CVE別／今後悪用が広まる可能性が高い脆弱性4選 まとめ 収集対象のデータ 2025年に公表された約5万件のCVEを含む各種データを、 スクリプト で収集しました。 取得した情報の内容や抽出条件については以下を参照してください。 取得情報の一覧を表示 取得情報 概要 取得方法 参照元 CVE-ID 脆弱性 の一意の識別子。NIST（米国国立標準技術研究所）が運営するNVDに登録されたCVE番号を使用 2025年に公表されたCVE-IDを全件取得 NVD（ https://nvd.nist.gov/vuln ） CVSS Base Score 基本評価基準に基づいて、 脆弱性 そのものの深刻度を数値（0.0〜10.0）で評価したスコア 対象CVE-IDにおける、CVSS v3.1（※1）のスコアを取得。取得優先度はNIST評価（Primary）＞CNA（※2）評価（Secondary）で、両方未評価の場合は「N/A」とする。 NVD（ https://nvd.nist.gov/vuln ） CVSS 深刻度レベル CVSS Base Scoreを基に分類した深刻度レベル（Low / Medium / High / Critical） 対象CVE-IDにおける、CVSS Base Scoreに基づく深刻度レベルを取得。取得優先度はNIST評価（Primary）＞CNA評価（Secondary）とする。 NVD（ https://nvd.nist.gov/vuln ） NVDステータス NVDにおける当該 脆弱性 の分析状況（例：Undergoing Analysis、Analyzed など） 対象CVE-IDにおける、NVDステータスを取得 NVD（ https://nvd.nist.gov/vuln ） CWE-ID 共通 脆弱性 タイプ（Common Weakness Enumeration）の識別子 対象CVE-IDにおける、CWE-IDを取得。取得優先度はNIST評価（Primary）＞CNA評価（Secondary）とする。 NVD（ https://nvd.nist.gov/vuln ） RCE リモートから任意のコード実行が可能かどうか 筆者独自のフィルター。対象CVE-IDにおいて、Descriptionに大文字・小文字に関わらず「remote code execution」「execute arbitrary code」「arbitrary code execution」のいずれかのキーワードが含まれ、かつAttack Vector が「NETWORK」であるか判定 NVD（ https://nvd.nist.gov/vuln ） CISA KEV 実際に悪用されているかどうか CISA のKEV（Known Exploited Vulnerabilities Catalog）への登録有無、ベンダー名、製品名を収集 CISA KEV（ https://www.cisa.gov/known-exploited-vulnerabilities-catalog ） PoC PoC（概念実証コード）が公開されているかどうか 筆者独自のフィルター。PoC-in- GitHub のデータを基に判定（※ GitHub に存在するPoCのみ参照）。具体的にはZIPファイルを取得したうえで、全ファイルパスを走査し、CVE-IDが含まれる場合は抽出。 PoC-in- GitHub （ https://github.com/nomi-sec/PoC-in-GitHub ） MSF Metasploit Frameworkに当該 脆弱性 のモジュールが組み込まれているかどうか 筆者独自のフィルター。Metasploit Frameworkに対象CVE-IDを示すファイルが存在するかチェック。具体的にはZIPファイルを取得したうえでmodules/配下のファイルパスを走査し、CVE-ID形式の文字列があれば抽出。 Metasploit Framework（ https://github.com/rapid7/metasploit-framework ） EPSS Score FIRSTが提供するEPSS（Exploit Prediction Scoring System）。今後30日以内に悪用される確率の予測値（0〜1） 対象CVE-IDにおける、EPSS Scoreを取得 FIRST EPSS（ https://www.first.org/epss/ ） （※1）CVSS v3.1の上位バージョンであるCVSS v4.0が2023年11月に公開されたが、2025年に公表されたCVE全体の約25%しか評価されておらずNVDによる評価が進まないため、広く普及していない状況である。本記事ではCVSS v3.1をベースに解説を進める。 （※2）CNA＝CVE Numbering Authorityの略称で、MITRE社から認定を受けて採番を行う組織のこと。 2025年 分析結果 ⚠️本集計は2026年1月中旬時点のデータに基づきます。 2025年に公表されたCVEの総数は 49,972 件でした。 2024年は40,704件であったため、 前年比で約23%増 、 9,000件近くの増加 となっています。 以降、分析結果の詳細です。 深刻度レベル別（2024／2025年） 2025年に公表された全CVEにおける、深刻度レベル別の件数です。 2024年と比較して 全体的に増加傾向 となっています。 2025年分は直近での集計ということもあり2024年分と比較すると差が出ていますが、それでも 未評価のCVEが前年比約4倍 と目立ちます。 NVDとしては、CNAによる評価の迅速化であったり、CWEの紐づけをLLMで自動化するなどの効率化（※）を図っているようですが、それでも対応が追いついていないことがわかります。 （※）参考： Vulnerability Root Cause Mapping with CWE 深刻度レベル別（2025年月別） 2025年に公表された全CVEにおける、月別／深刻度レベル別の件数です。 直近で公表されたCVEに未評価が多いのは当然ですが、12月は 未評価が1,500件 を超えています。 NVDではKEVに登録があるものを優先して評価（※）しているようですが、直近の 脆弱性 には対応が追いついていない状況が見て取れます。 今は未評価でも、分析が進むにつれてCriticalレベルと判明する 脆弱性 が出てくる可能性はありそうです。 （※）参考： The National Vulnerability Database (NVD) – Where It Is and Where It’s Going NVDステータス別 左が2024年、右が2025年に公表された全CVEにおける、NVD分析状況の割合を100%積み上げ棒グラフで示したものです。 （各ステータスの意味は下表を参照してください） 2024年分はAnalyzed（分析完了）と Modified（更新）を合わせて約80%の分析が完了しています。 一方、2025年分は分析完了の割合は前年並みを維持しているものの、 Awaiting Analysis（分析待ち）が約40% と大きく目立ちます。 ここについては今後分析が進んでいくと思われますが、現状では情報の確定に時間を要していることが伺えます。 また、 Rejected（却下）されたCVEが前年比で2倍以上 に増加している点も注目すべき変化です。 背景には、特定のライブラリに起因する 脆弱性 が製品ごとに乱立した際のCVEの統合や、昨今話題となっているAIツールを用いた大量かつ低品質な 脆弱性 報告の増加（※）といった、NVDを取り巻く環境の変化が影響していると考えられます。 （※）参考： NVD's HUGE Backlog: Vulnerability Crisis Explained ステータス名 意味 解説 Received 受理 NVD登録初期状態 Awaiting Analysis 分析待ち CVEの情報は公開されているが、NVDによるCVSSスコアやCWEの紐付けなどの詳細分析を待っている状態 Undergoing Analysis 分析進行中 CPE （情報システムを構成する、ハードウェア・ソフトウェアなどの識別子）やCWEの付与を行っている最中の状態 Analyzed 分析完了 NVDによる詳細分析がすべて完了した状態 Modified 修正 分析完了後に、新しい情報が追加・更新された状態 Deferred 延期 分析の優先順位が下げられた状態 Rejected 却下 脆弱性 ではないと判明した、あるいは既存のCVEと重複していた等の理由で、CVE-ID自体が取り消された状態 攻撃コード公開済み 脆弱性 の割合（PoC／MSF） 2025年に公表された全CVEにおける、PoCが公開されているCVEの割合は 2.47% で、 1,234件 ありました。 GitHub 以外やプライベー トリポジ トリのPoCも含めると、実際にはこの数値より膨らむものと推測されます。 また、上記のうちMetasploit Frameworkでモジュール化されているCVEの割合は 4.04% で、 50件 でした。 攻撃コードがモジュール化されている 脆弱性 は、高度な技術を持たない攻撃者でも簡単に悪用できる可能性があるため、特に注意が必要です。 悪用確認済み 脆弱性 の割合（ CISA KEV）／製品内訳（上位5製品） 左の円グラフは2025年に公表された全CVEのうち、 CISA KEVに登録された割合を示しており、全体の 0.33% でした。 件数にするとわずか167件ですが、これらは理論上のリスクではなく、実際に悪用されていることが確認されているため、優先的に対応すべき重大な 脆弱性 として取り扱う必要があります。 右の円グラフは、その中でも悪用報告が多かった製品の内訳です。 Windows が17.37% と最多なのは、多くの企業で共通基盤として使われており、攻撃者にとって最も効率よく広範囲に影響を及ぼせるためと考えられます。 また、上位にはFortinetやIvantiといったネットワーク機器も並んでいます。 VPN などの境界を守る機器は、一度突破されると組織内への侵入や権限奪取に直結するため、OSと同等に執拗な標的となっていると考えられます。 RCE可能な 脆弱性 の割合／悪用確認済みネットワーク機器内訳 2025年に公表された全CVEにおいて、リモートコード実行（RCE）可能と判断されるものは、全体の 3.25% でした。 リモートから悪意のあるコードを実行された場合、情報窃取や攻撃の起点となるリスクが高く、特に注意が必要です。 さらにその中でも悪用確認済みの 脆弱性 に絞ると、 ネットワーク機器の 脆弱性 が3割 を超えています。 なお、これらの 脆弱性 のうち CWE-787（境界外書き込み） に分類される 脆弱性 は約4割と最も多く占めていることもわかりました。 これらの境界機器のRCEは、認証を介さず外部から直接システム権限を奪取できるものが多いため、昨今の ランサムウェア 攻撃において最も警戒すべき侵入経路とされています。 CWE別件数（上位10位） 2025年のCWE別件数の上位10タイプを、2025年（オレンジ）と2024年（グレー）で比較しました。 CWE-79（ クロスサイトスクリプティング ）が不動の1位となっています。 また、最も件数が増加したのは CWE-74(インジェクション)で1,169件増加 、一方で最も件数が減少したのは CWE-787(境界外書き込み)で843件減少 となりました。 CWE-74については、2025年に暫定策として取り入れられたGap Filling（CNAから提出されたCVSSおよびCWEデータを再検証せずに、一時的に受け入れるもの）による登録促進（※）の影響で、CNA側で付与したCWE-74が精査を待たずに大量に登録されたことが、増加の主な要因ではないかと推測しています。 （※）参考： The National Vulnerability Database (NVD) – Where It Is and Where It’s Going CWE別リスク分布 前項では件数に着目しましたが、ここでは筆者独自の観点で、リスクベースで分析してみます。 下図のバブルチャートでは、バブルの大きさが2025年に公表されたCVE総数を表し、X軸にRCE可能なCVE件数、Y軸に CISA KEVに登録されたCVE件数でプロットしたものです。 その中でもRCE可能な件数が50件以上、KEV登録数が10件以上のCWEに注目し、右上の領域にプロットされたCWEを下表にリストアップしました。 これらの 脆弱性 タイプは、 段階を踏まずインターネット越しから任意のコマンドを実行できる割合が高く、悪用実績も多数報告されている ため、特に注意が必要なカテゴリと言えるでしょう。 一方で最もサイズが大きいバブルはCWE-79ですが、単体でのRCEやKEV登録数は相対的に低めです。 CWE-ID 名称 解説 CWE-787 境界外書き込み メモリ操作時の不備により、本来の範囲を超えてデータを書き込んでしまう 脆弱性 のタイプ CWE-502 信頼できないデータのデシ リアラ イゼーション 外部から受け取ったデータをオブジェクトに復元する際、悪意あるコードを実行可能にする 脆弱性 のタイプ CWE-78 OSコマンドインジェクション OSコマンドの生成時に外部入力のバリデーションを不適切に行うことで、任意のコマンドを実行可能にする 脆弱性 のタイプ CVE別／2025年最も危険な 脆弱性 4選 2025年を通して最も危険な 脆弱性 について、個人の見解に基づいて選抜しました。 選抜の観点としては以下です。 CVSSスコア10（最大値）かつRCE、PoC、MSF、KEVをすべて網羅している 脆弱性 もし自社の環境や稼働しているシステムに下記に該当する 脆弱性 が存在する場合は、一刻も早く対処することをおすすめします。 CVE Published Vendor Product CVSS CWE RCE PoC MSF KEV EPSS CVE-2025-32433 2025-04-16 Erlang Erlang /OTP 10 CWE-306 TRUE TRUE TRUE TRUE 0.43921 CVE-2025-47812 2025-07-10 Wing FTP Server Wing FTP Server 10 CWE-158 TRUE TRUE TRUE TRUE 0.924 CVE-2025-55182 2025-12-03 Meta React Server Components 10 CWE-502 TRUE TRUE TRUE TRUE 0.5512 CVE-2025-37164 2025-12-16 Hewlett Packard Enterprise (HPE) OneView 10 CWE-94 TRUE TRUE TRUE TRUE 0.8131 CVE別／今後悪用が広まる可能性が高い 脆弱性 4選 最後に、2025年に公表されたCVEの中で、今後悪用が広まる可能性が高い 脆弱性 について、個人の見解に基づいて選抜しました。 選抜の観点としては以下です。 CWE別リスク分布で特定したCWEのうち、EPSSスコア0.9以上（直近30日間で悪用される可能性が非常に高い）かつPoC、MSFが公開されている 脆弱性 これらの 脆弱性 も早期に特定し、優先的に対処することをおすすめします。 CVE Published Vendor Product CVSS CWE RCE PoC MSF KEV EPSS CVE-2025-0282 2025-01 Ivanti Connect Secure, Policy Secure, and ZTA Gateways 9 CWE-787 TRUE TRUE TRUE TRUE 0.94105 CVE-2025-24016 2025-02 Wazuh Wazuh Server 9.9 CWE-502 TRUE TRUE TRUE TRUE 0.93801 CVE-2025-24813 2025-03 Apache Tomcat 9.8 CWE-502 TRUE TRUE TRUE TRUE 0.94183 CVE-2025-53770 2025-07 Microsoft SharePoint 9.8 CWE-502 FALSE TRUE TRUE TRUE 0.91188 まとめ 2025年はこれまで以上に 脆弱性 情報の量が増えたと感じていましたが、実際に分析することで日々のニュースを追うだけでは見えてこないその年の傾向や、NVDを取り巻く環境の変化や運用方針の転換が、データに影響を及ぼしていることが見えてきました。 CWEの総数で上位10位に入っていないものの、ひとたび悪用されればRCEに直結しやすく、かつ実際にKEVとして登録されるケースも目立ちました。 特に、ネットワーク機器の深刻な 脆弱性 として分類される傾向が見えたCWE-787と、冒頭でも触れたReact2Shellを含む CWE-502の動向には引き続き注視する必要がありそうです。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @fukuyama.kenta レビュー： @miyazawa.hibiki （ Shodo で執筆されました ）

はじめに こんにちは、AI チームの長澤 ( @sp_1999N ) です。 弊社では AI Worker という LLM エージェント構築プラットフォームを提供しています。 LLM エージェントを運用していると重要な要素になるのが「可観測性 = Observability」になります。 複雑な推論や複数のアクションを前提とした LLM エージェントでは、その挙動をいかに監視するかが運用上重要なトピックになります。 LLM エージェントの Observability 基盤としては、Datadog など様々な企業からサービスとして展開されており、また OSS として使えるものも多数出現しています。このことからも、LLM エージェントを自社サービスとして提供する場合は、可観測性が重要であることが伺えます。 一方で増えつつある選択肢の中から、どれを選べば良いかというのもよくある悩みです。 そこで今回は、多く存在する LLM エージェント Observability 基盤を網羅的に紹介してみようと思います。 注意: この記事の内容は 2025/7 時点の情報をベースにしておりますのでご注意ください。また基本的にドキュメントベースの情報になります。 早見表 サクッと比較したい方向けに、早見表を記載しております。一言はあくまで自分の所感になります。 OSS プロンプト管理 評価基盤 SDK 一言 Braintrust × ⚪︎ ⚪︎ Python, TS, Ruby, Java, Go, Kotlin エージェントやツール管理までできるend-to-end なプラットフォーム Dash0 × × ⚪︎ Python, JS/TS, Go, Erlang, Java, .NET言語, Ruby ランチャーやマルチテナント対応など本番想定での使い勝手の良さが特徴 LangSmith × ⚪︎ ⚪︎ Python, JS/TS LangChain エコシステムとのシームレスな統合 New Relic × × △ Python, JS/TS, .NET言語, Java, Go, Ruby 汎用 APM という立ち位置。MCP の呼び出しもトレースしてくれる LangWatch × △ ◎ Python, TS Scenario を使ったエージェントのシミュレーション評価が可能 Datadog × × ⚪︎ Python, Java, JS/TS Ragas など off-the-shelf な llm-as-a-judge の評価が可能 Traceloop × ⚪︎ ⚪︎ Python, TS, Go, Ruby OTel を LLM 向けに拡張した標準規格である OpenLLMetry 提供 Phoenix ⚪︎ ⚪︎ ◎ Python, TS 検索やエージェント評価まで対応した充実した評価基盤を持つ Langfuse ⚪︎ ⚪︎ ⚪︎ Python, JS/TS カスタムダッシュボードなど UI/UX 面で優れる Laminar ⚪︎ △ ⚪︎ Python, JS/TS キューを使ったデータのラベル付けが可能 SigNoz ⚪︎ × × Python, JS/TS, Java, Go, PHP, .NET言語, Ruby, Elixir, Rust, C++, Swift 汎用 APM という立ち位置で他フレームワークとの統合で利用 Langtrace ⚪︎ ⚪︎ ⚪︎ Python, TS 2行の実装でトレースが可能な手軽さが魅力 紹介する Observability 基盤の選定 弊社で開発している AI Worker では、開発言語として TypeScript、エージェントフレームワークとして Mastra を採用しています。(AI Shift における開発体制については こちらのブログ で述べていますので、興味のある方はぜひどうぞ！) そこで今回はこのような背景を踏まえ、以下を選定の条件とします。 SDK として TypeScript がサポートされていること データ収集基盤だけでなく、評価・分析基盤まで提供されていること 今回は TS を対象言語としていますが、多くのプロバイダーは Python も同時にサポートしているため、Python で開発されている方にとっても参考になる内容になっていると考えられます。また Go や Ruby などをサポートしているフレームワークも存在するので、言語軸で調べられている方の足掛かりにもなれば幸いです。 比較対象とする Observability Providers 条件を踏まえ、まずは Mastra 側の情報をチェックしてみます。 Mastra の公式ドキュメントには Observability Providers のリストが公開されています。 https://mastra.ai/en/reference/observability/providers これだけでも多くのプロバイダーが存在することが分かります。数は多いですが、せっかくなのでそれぞれ特徴を紹介してみようと思います。また Datadog, Arize AI の Phoenix, Langtrace も LLM Observability プラットフォームとしてツール提供しているため、これら3つも紹介の対象に加えたいと思います。 1つ紹介の軸として、OSS としてセルフホストが可能かどうかを設けて整理したいと思います。 Non-OSS プロバイダー このセクションで紹介するプロバイダーは全て non-OSS なサービスとして開発されているものになります。 商用レベルの利用では基本的に有料ですが、趣味としての個人開発やトライアルとして無料で使えるプランも用意されているものがほとんどです。 それぞれの特徴を簡単に見てみます。 Braintrust Braintrust は2023年に設立されたスタートアップで、 a16z などの著名なベンチャーキャピタルからの出資を受けています。利用企業には instacart, stripe, Notion など有名な企業が並びます。 OSS としては開発されていませんが、Python や TypeScript 以外にも Go や Ruby など 様々な言語 で SDK を提供してくれています。監視や評価基盤だけでなく、LLM エージェントそれ自体やエージェントに提供するツールなども構築できる、end-to-end なプラットフォームとして展開されているのが特徴と言えそうです。( Agent の作成機能 は執筆時点では beta 版としての提供のようです) https://www.braintrust.dev/docs/start Free plan も用意されており、個人プロジェクトなどの小規模な利用の場合はこのプランで試してみるのも良いかもしれません。 Dash0 Dash0 も2023年に設立され、ニューヨークに拠点を置く企業になります。OpenTelemetry ネイティブな監視基盤を提供しています。SDK としてこちらも JS/TS, Python, Go, Ruby, Java など 複数の言語 をサポートしています。こちらも OSS ではなく、セルフホストなどはできません。 こちらも、監視から評価までを一貫して提供してくれています。その上で、プラットフォーム内に ランチャー が用意されているなど使い勝手の良い印象です。また マルチクライアント・マルチテナント対応 や アクセスコントロール 、 アラート通知 の設定が可能になっていたりと、本番利用に向けた充実した機能が揃っています。 LangSmith LangSmith は、お馴染み LangChain 社が展開するプラットフォームの1つです。趣味の範囲での個人開発であれば無料で利用できますが、商用の場合は有料となります。また LangChain がそうであるように、LangSmith においてもサポートされる言語は Python と JS/TS のみになります。 Observability, Evals, Prompt Engineering の3要素を柱として構成されています。 https://docs.smith.langchain.com/ 最大の特徴は LangChain エコシステムとのシームレスな統合であると考えられます。LLM アプリケーションのフレームワークとして LangChain や LangGraph を使用している場合、環境変数の設定のみを行えば、 基本的には追加コードなし でトレースができるようになります。 その一方でフレームワーク非依存な提供であるため、LangChain エコシステム以外にも組み込むことが可能で、実際に各種商用 LLM プロバイダーや Vercel AI SDK とのインテグレーションなどが提供されていたりします。 New Relic New Relic は 2008 年にサンフランシスコで設立された、APM (Application performance monitoring) ツールを提供する企業です。他のプロバイダーと比較するとその立ち位置としては Datadog に近いと言えます。 AI Monitoring として、AI アプリ向けの APM ソリューションを提供しています。 対応言語 には Go, Ruby, JS/TS, Python などがあります。 MCP の呼び出しに関してもトレースを行い、そのパフォーマンスの監視も行ってくれます。ただし、他プロバイダーが押し出しているような「評価」に関する機能については、現時点ではユーザーフィードバックの収集程度にとどまっているようです。 LangWatch LangWatch は 2023 年にオランダで設立された LangWatch 社によって提供される LLMOps プラットフォームです。ライセンス自体は Business Source License 1.1 になるので、OSS には分類されません。セルフホストでの運用も可能ですが、商用利用の場合は 有料プラン での契約が必要になる点にご注意ください。対応言語は Python および TypeScript のようです。 エージェントの評価に力を入れたプラットフォームになっており、 Scenario と呼ばれるエージェントテストフレームワークが独自に導入されています。これはマルチターンの行動を前提とした LLM エージェントを、シナリオベースでマルチターンに評価するためのものになります。多くのプロバイダーを紹介していますが、このようなユーザーシミュレーター機能を備えたものは他ではあまり見当たらなかったため、大きな特徴と言えます。 また有料機能として Guardrails があり、ハルシネーションやセンシティブデータの漏洩などをリアルタイムで検知してくれます。 Datadog 馴染みのある方も多いと思われる Datadog も LLM Observability 基盤の提供 を行っております。 対応言語 として Python, Java, JS/TS で SDK が提供されています。LangChain や VertexAI などのフレームワークに対するインテグレーションも提供されているため、対象のものであれば少ないコードの変更量でトレースを計装できるようになります。しかし言語によって サポートフレームワーク が異なっています。 モニタリング、評価、実験の3つを柱として構成しており、それらをリッチなダッシュボードで管理することが可能です。 https://docs.datadoghq.com/llm_observability/ 評価においては Ragas や NeMo などが組み込まれているため、off-the-shelf な LLM-as-a-judge の実施が可能です。これ以外にもカスタムメトリクスを実装することも可能です。 エージェントに特有のマルチターンやツール呼び出しの評価など、LangWatch や Phoenix が提供してくれている部分についての拡張も期待したいところです。 Traceloop Traceloop は Y Combinator などから出資を受けている企業で、2023 年に設立されています。Traceloop 自体は OSS ではない、商用プラットフォームなのですが、同社によって OpenLLMetry という OSS の標準規格が提唱されています。Traceloop 自体はその上に立つ分析/評価プラットフォームという位置付けになります。 対応言語 は Python, TS/JS, Go, Ruby になります。トレース、評価、データセットの3つを軸としてサービスが構成されています。他プロバイダーで見たようなプロンプトのバージョニングなどは、記事執筆時点ではなさそうでした。 デモページ から簡単に使用感を確かめることができます。 OpenLLMetry Op enLLMetry は OpenTelemetry を「LLM 特有のデータ」に拡張する形で機能します。例えばプロンプトの内容、生成結果、消費トークン量など LLM 特有のデータについて、OTel では標準的な仕様がありませんでした。そこで、OpenLLMetry はその不足分を補う形の標準規格として提唱されている、という位置付けになります。 また OpenLLMetry は Traceloop 以外にも Datadog や Braintrust などの他社ツールへの統合も提供しています。したがって、データ収集基盤として OpenLLMetry を使うことにより、可視化や評価基盤のツールは Traceloop 以外にも様々選べるようになります。(= ベンダーロックインの回避) OpenLLMetry の 対応言語 は Python, TS/JS, Go のようです。 OSS プロバイダー Phoenix Phoenix は Arize AI によって開発されている OSS ( ELv2 ) の LLM Observability 基盤になります。 セルフホストであっても、料金の発生なしに機能制限なく利用することが可能です。ただし、同社により Arize AX というエンタープライズ向けの有料プラットフォームが用意されていることから、ある種のオープンコアモデルとしても見ることができます。アーキテクチャも比較的シンプルであるため、セルフホスト時の保守・運用コストはそこまで高くなく利用できると考えられます。 https://arize.com/docs/phoenix/self-hosting 対応言語は Python と TS の2種類のようです。 こちらもトレース、評価、実験およびプロンプト管理を主機能として備えています。クラウド、コンテナ、jupyter notebook、ターミナルなど様々な 環境 で利用することができます。その意味では研究などの実験管理基盤としても利用できるかと思います。 また エージェント周りの評価 や RAG などで必要な 検索に関する評価 なども用意されているため、やれることが細やかに整備されている印象を受けます。 デモ も用意されているので、その使用感を簡単に確認することができます。 Phoenix については弊社の 別記事 でもその使用感を簡単に紹介しているので、興味のある方はぜひご覧ください。 Langfuse Langfuse はドイツに拠点を構え、 Y Combinator からも出資を受ける 2022 年設立の企業になります。 Phoenix と同様、有料プランの加入なしでも、セルフホストで ほとんどの機能を利用できる オープンコアの形式をとっています。(基本的には MIT ライセンス ですが、一部機能は商用ライセンスが適用されます。) 対 応言語 は Python, JS/TS になります。 トレース、評価、実験、プロンプト管理などほとんどの主要な機能が提供されています。 LLM-as-a-judge の評価においては、Datadog 同様、Ragas などのメトリクスをそのまま利用できます。 ダッシュボードのカスタマイズ も可能で、OSS のプロバイダーとしては総合的に完成度が高いように感じられます。デモ画面も用意されているので、気になる方はぜひ覗いてみて下さい。 https://langfuse.com/docs/demo その反面、アーキテクチャ構成が若干複雑で、セルフホストする場合の保守・運用コストは若干高めかもしれません。ただし、 Helm チャート も提供されているので、チャレンジはしやすいように整えられています。 Google Cloud での例: https://langfuse.com/self-hosting/gcp Laminar Laminar も Y Combinator に出資を受ける、2024 年設立のサンフランシスコの企業になります。 Apache-2.0 ライセンス で開発されており、セルフホストでの運用が可能です。 対応言語 は JS/TS, Python になります。Laminar 自体のバックエンドは Rust で実装されているため、高速な挙動が期待できます。アーキテクチャは少し複雑ですが、メッセージキューとして RabbitMQ, データは Clickhouse と Postgres を組み合わせたモダンな構成のようです。 こちらもトレース、評価、実験、プレイグラウンドなどの主要な機能がサポートされています。またメッセージキューを使ったデータセットのラベル付けが可能です。 SQL エディタ の機能があり、Laminar に格納されているデータに対する読み書きがしやすいインターフェースが提供されています。SQL でトレース情報などを管理・集約されたい方にとっては魅力的な機能かもしれません。 SigNoz SigNoz は汎用的な APM (Application performance monitoring) ツールという感じで、ポジションとしては Datadog や New Relic と近いですが、OSS ( Apache-2.0 ) として使用できる点に違いがあります。 ドキュメント を見る限り、SigNoz 自体は LLM Observability に特化した機能を提供しているわけではなさそうです。その代わりそれに準ずる OSS との統合を押し出している印象を受けます。 本記事でも紹介している Langtrace や Traceloop などがその統合例として紹介されています。したがって、LLM に対する監視基盤を整えつつ、アプリケーション全体の監視基盤と統合したい場合は SigNoz を使うと良さそう、と言えそうです。 Langtrace Langtrace は 2024 年 2 月に一般提供が開始された比較的若いツールとなります。 Scale3 Labs という企業によって開発されました。同社はもともと Web3 インフラの Observability ツールを開発する企業として 2022 年に設立されたようです。対応言語は Python および TS のみのようです。OSS ( AGPL-3.0 ) として利用でき、セルフホストも可能です。セルフホストの場合、Langtrace の client サーバーに加え、Postgres DB, Clickhouse DB が必要になります。 https://github.com/Scale3-Labs/langtrace?tab=readme-ov-file#-langtrace-system-architecture トークン利用量などを含めたログ・トレースの取得、評価、プロンプトのバージョン管理など LLM Observability で主要な機能は全て揃っているようです。 また、Langtrace は2行の実装のみでトレースが可能になり、その手頃さは魅力的なポイントになります。 まとめ 今回は LLM エージェントの Observability 基盤として使えるプロバイダーをまるっと紹介してみました。単なる監視基盤というより、評価・実験基盤としての意味合いで機能が提供されている点が、LLM Observability ならではな印象を受けました。 基本的な提供機能は概ね共通していましたが、LangWatch や Phoenix はエージェントに特化した評価の整備が進んでいるなど、主に評価基盤における機能の差が見られました。そのほかはダッシュボードや導入のしやすさなどがそれぞれ特色が出るポイントとなりました。導入のしやすさにおいては、インテグレーションの提供有無を見ることも重要です。今回紹介した多くのプロバイダーは Mastra インテグレーションを提供しているため、簡単に組み込むことができます。 個人的にまとめるのであれば、次のようになると思います。 Non-OSS からは、Datadog を APM としてすでに導入している場合は Datadog を、LangChain, LangGraph をエージェントフレームワークとして使用しているのであれば LangSmith を、LLM エージェントの評価にこだわりたいなら LangWatch をおすすめするかなと思います。 OSS の場合は、ダッシュボードなどの UI/UX の良さにこだわるなら Langfuse、手軽さや全体的な網羅性を取るなら Phoenix という感じでしょうか。 これから LLM エージェントの Observability 基盤を導入する方にとって、参考になれば幸いです。 投稿 LLMエージェントオブサーバビリティ基盤についてまとめてみた は 株式会社AI Shift に最初に表示されました。

みなさんこんにちは、 電通国際情報サービス （ISID）X イノベーション 本部ソフトウェアデザインセンターの佐藤太一です。 皆さんは最近発売された 『実践プロパティベーステスト ― PropErとErlang/Elixirではじめよう』 はもう読みましたか？ この本は Erlang やElixirを使ってプロパティベーステストというテスト手法について具体的なコードを使って実践的に学習できる本です。非常に素晴らしい本ですが、難しい部分も多いため私は少しずつ読んでいる所です。 この記事では、この本を読むにあたってサンプルコードを動かすための環境を使っているOSに依存せずに作成する方法を説明します。 事前の準備 最小限のDev Container devcontainer.jsonを編集する環境の構築 Erlang用VS Code拡張 テスト用プロファイルで使うライブラリをエディタに認識させる まとめ この記事で紹介している開発環境の構成ファイル .devcontainer/devcontainer.json 事前の準備 この記事が前提とする環境について軽く説明します。 まず、  VS Code  を事前にインストールしておいてください。 次に、 Docker Desktop をインストールして動作する状態にしてください。基本的には単に インストーラ を実行すれば動作する状態になります。 そして、 VS Code に  Dev Containers 拡張をインストールしておいてください。 最後に、作業用のプロジェクト ディレクト リを作成してください。ここでは、pbt という ディレクト リを作成してプロジェクトのルート ディレクト リとしています。 最小限のDev Container まずは、Dev Containerを使って Erlang が提供する公式のDockerイメージを使った開発環境を作成してみましょう。 プロジェクトのルート ディレクト リに、  .devcontainer  という ディレクト リを作って、その中に  devcontainer.json  というファイル名で以下の内容を保存します。 { " name ": " devcontainer-erlang ", " image ": " erlang:slim ", " containerEnv ": { " TZ ": " Asia/Tokyo " } , " runArgs ": [ " --init " ] } name の値は、分かりやすい名前なら何でもいいです。ここでは、devcontainer- erlang としています。 image の値は、 erlang :slim としています。これは公式のイメージ名です。 ベースイメージや Erlang ランタイムのバージョンを別なものにしたい場合には、 https://hub.docker.com/_/erlang から探してください。 containerEnv の値は、コンテナ内で参照される 環境変数 です。ここでは タイムゾーン が  Asia/Tokyo になるよう設定しています。時刻に起因する問題の調査は難しいので、ここで明示的に設定しています。 runArgs の値は、  --init  を渡すことでDockerが  /dev/init  というシグナルハンドリング用のプロセスを起動してくれます。これによってコンテナを安定的にシャットダウンできます。 devcontainer. json を編集する環境の構築 ここから、devcontainer. json を編集しながら開発環境を構築していくので、まずは快適に json ファイルを編集できるようにしましょう。 devcontainer. json には、Dev Containerとして起動した VS Code を構成するための設定項目がありますので、それらを編集します。 { " name ": " devcontainer-erlang ", " image ": " erlang:slim ", " customizations ": { " vscode ": { " settings ": { " editor.renderWhitespace ": " all ", " [json][jsonc] ": { " editor.defaultFormatter ": " esbenp.prettier-vscode ", " editor.formatOnSave ": true , " editor.codeActionsOnSave ": { " source.fixAll ": true } } } , " extensions ": [ " esbenp.prettier-vscode " ] } } } customizations  というキーがDev Containerの構成を行うための設定項目です。この中に vscode  という項目がありますね。 settings の中では、 VS Code の設定項目を管理します。 editor.renderWhitespace  の値として、  all  を設定しているのは、ファイルの中に紛れ込んだ全角スペースを見つけやすくするためです。私たちが IME を使っている以上、意図しない場所に全角スペースが入り込んでしまい、それによって理解が困難なエラーメッセージを読むことになるのは避けられません。全角スペースが見えていれば、そういったドハマりから抜け出しやすくなります。 [json][jsonc]  の値として、いくつか設定しています。ちなみに、jsoncは、 JSON  with commentsの略称です。 editor.defaultFormatter  の値として、esbenp.prettier- vscode  を設定しています。これによってprettierを使ったフォーマットが行われます。 editor.formatOnSave  の値として、trueを設定することでファイル保存時にフォーマットが行われるようにしています。 editor.codeActionsOnSave  の値として、source.fixAll を有効化することで自動的に補正できるフォーマットエラーをprettierが積極的に補正してくれます。 extensions の中では、Dev Containerとして起動された VS Code にインストールされる VS Code 拡張を列挙します。ここでは、 JSON を自動フォーマットするための  esbenp.prettier-vscode  を設定しています。 Erlang 用 VS Code 拡張 次は、 Erlang 用の VS Code 拡張を追加します。 マーケットプレイス を確認するといくつかの拡張がありますが、一番利用者の多いものを今回は使います。 erlang devcontainer. json のextensionsに拡張を追加すると、以下のようになります。 { " name ": " devcontainer-erlang ", " image ": " erlang:slim ", " customizations ": { " vscode ": { " settings ": { " editor.renderWhitespace ": " all ", " erlang.formattingLineLength ": 200 , " [erlang] ": { " editor.defaultFormatter ": " pgourlain.erlang ", " editor.formatOnSave ": true , " editor.codeActionsOnSave ": { " source.fixAll ": true } } , " [json][jsonc] ": { " editor.defaultFormatter ": " esbenp.prettier-vscode ", " editor.formatOnSave ": true , " editor.codeActionsOnSave ": { " source.fixAll ": true } } } , " extensions ": [ " pgourlain.erlang ", " esbenp.prettier-vscode " ] } } } erlang.formattingLineLength の値として、200を設定しています。この設定項目はドキュメントには記載がないので、私の設定値をここに書いています。 [erlang] の値として、いくつか設定しています。何をしているかは [json][jsonc]  の時と同じです。 これで Erlang のアプリケーション開発環境は完成です。しかし、本を読み進めていくと早々に問題にぶつかります。 テスト用プロファイルで使うライブラリをエディタに認識させる 書籍では、PropErというライブラリをrebarというビルドツールに構成するように指示されます。 その結果、rebar.configを以下のように構成します。 { project_plugins , [ rebar3_proper ]} . { profiles , [ { test , [ { erl_opts , [ nowarn_export_all ]} , { deps , [ proper ]} ]} ]} . { erl_opts , [ debug_info ]} . { deps , []} . rebar3では、依存ライブラリをプロファイル毎に管理できるようになっています。 そして、 proper は test プロファイルでのみ参照されます。 ダウンロードされた依存ライブラリは、プロジェクトのルート ディレクト リにある _build ディレクト リ以下に格納されています。 この状態だと、rebarによるビルドは成功するのですが、エディタ上で can't find include lib "proper/include/proper.hrl” といったエラーが出力されます。 このエラーを解決するため VS Code のエディタ上でも、testプロファイル以下にダウンロードされたライブラリを参照するように設定を追加します。 変更した後のdevcontainer. json は以下のようになります。 { " name ": " devcontainer-erlang ", " image ": " erlang:slim ", " customizations ": { " vscode ": { " settings ": { " editor.renderWhitespace ": " all ", " erlang.formattingLineLength ": 200 , " erlang.includePaths ": [ " _build/test/lib " ] , " [erlang] ": { " editor.defaultFormatter ": " pgourlain.erlang ", " editor.formatOnSave ": true , " editor.codeActionsOnSave ": { " source.fixAll ": true } } , " [json][jsonc] ": { " editor.defaultFormatter ": " esbenp.prettier-vscode ", " editor.formatOnSave ": true , " editor.codeActionsOnSave ": { " source.fixAll ": true } } } , " extensions ": [ " pgourlain.erlang ", " esbenp.prettier-vscode " ] } } } erlang.includePaths の値として、ライブラリを格納している ディレクト リの 相対パス を記述しています。 まとめ ここまで、Dev Containerで Erlang アプリケーションの開発環境を構築する方法について説明してきました。 普段あまり使っていない プログラミング言語 でも、Dockerベースのコンテナ技術を使えば簡単に開発環境を構築できることがお分かりいただけたんじゃないでしょうか。 特に私が普段使っている Windows では インストーラ を使ったバイナリのインストールは後腐れが残り易いので、本を読み終わったら全てを片付けられて副作用のないDev Containerは非常に便利です。 この記事を読んでいただいたあなたも是非、クリーンな開発環境を構築してプロパティベーステストという応用可能性の高いテスト手法に習熟できることを願っています。 この記事で紹介している開発環境の構成ファイル 最後に作った構成ファイルを紹介します。 .devcontainer/devcontainer. json { " name ": " devcontainer-erlang ", " image ": " erlang:slim ", " customizations ": { " vscode ": { " settings ": { " editor.renderWhitespace ": " all ", " erlang.formattingLineLength ": 200 , " erlang.includePaths ": [ " _build/test/lib " ] , " [erlang] ": { " editor.defaultFormatter ": " pgourlain.erlang ", " editor.formatOnSave ": true , " editor.codeActionsOnSave ": { " source.fixAll ": true } } , " [json][jsonc] ": { " editor.defaultFormatter ": " esbenp.prettier-vscode ", " editor.formatOnSave ": true , " editor.codeActionsOnSave ": { " source.fixAll ": true } } } , " extensions ": [ " pgourlain.erlang ", " esbenp.prettier-vscode " ] } } } 執筆： @sato.taichi （ Shodo で執筆されました ）