はい、こんにちはー！クロス イノベーション 本部 サイバーセキュリティテクノロ ジー センターの福山です。 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 で執筆されました ）

これは 豆蔵デベロッパーサイトアドベントカレンダー2025 第17日目の記事です。 1. はじめに：なぜ今、PBTを試すのか # プロパティベーステスト（以下 PBT）は、 仕様から抽出された「満たすべき性質（property）」を任意の入力・状態・操作系列に対して検証する テスト手法です。PBT は、従来の事例ベーステストと 相互補完的な関係にある ことが知られています [1] 。 正直、この説明だけでピンと来る人は多くないのではないでしょうか。私自身も、以前から興味はあったものの、満たすべき挙動の形式化が難しい、実装コストが高そうと感じて手を出せずにいました。 しかし、2025年11月17日に GA となった Kiro では、IDE 機能として 「プロパティベーステストによる仕様の正確性検証」 が導入されました [2] 。この新機能により、PBT 導入のハードルが下がったように見えたため、 実際に手を動かして体験してみることにしました。 Kiro の PBT 機能については、公式ドキュメント「 Correctness with Property-based tests 」を参照してください。 2. なぜ PBT なのか：EBT との決定的な違い # 書籍『実践プロパティベーステスト』 [3] では、PBT の特徴を次のように説明しています。 テストのための例をたくさん書いたり、コードに投げるためのランダムなデータを生成したりするのではなく、コードに潜む思いもよらなかった新しいバグを見つけるための手法である 具体例で考えてみましょう。従来の事例ベーステスト（EBT）では「1 と 3 を足したら 4 になる」のような特定の例を確認します。一方 PBT では「どんな数字を 2 つ足しても、順番を変えて足した結果と同一になる」という普遍的な性質を定義します。 左図は EBT、右図は PBT のイメージです。EBT はテストケースを手動で作成し検証する一方、PBT はプロパティを定義してランダムな入力で検証します。 つまり、EBT は 予測可能なバグ に強く、PBT は 予測できなかったバグ を発見できる可能性があります。この違いは、後半の UI 表示テストで実感することになります。 3. 題材に「チケット管理」を選んだ理由 # Kiro + PBT の解説記事として、「部屋移動ゲーム」を題材にした Medium 記事 [4] があります。 このゲームは、以下の構造により PBT に非常に向いています。 状態 × 操作 × 不変条件（Property） 同じ構造は、 業務アプリケーション にも頻出すると考え、 今回はその一例である、「チケット管理」を題材とすることにしました。 チケット管理には以下の特徴があります。 状態遷移の制約 終端状態の不変条件 再実行・順序依存性 異常系の保証 これらは 事例ベーステストでは拾いにくいが、PBT と相性が良い性質 です。 そのため、実務への応用を意識してチケット管理を題材に選びました。 4. 仕様：極めてシンプルなチケット管理 # 今回は、あえて仕様を極限まで単純にしました。 チケットの状態 # Status = { Open, InProgress, Done } 上記の３つのみ 許可される状態遷移 # Open → InProgress InProgress → Done 上記以外の遷移はすべて無効 Done は終端状態であり、どの操作も受け付けない この最小仕様を、Kiro に入力していきます。 5. Kiro による Property-Based Testing の実行 # 5-1. 要件文書（requirements.md）の生成 # まず、Kiro IDE に以下の要件を入力します。 - GUI ベースの簡易チケット管理アプリを作成する - 永続化は不要、検証用の最小アプリとする - チケットは必ず3状態のいずれかを持つ - 状態は「未対応→対応中→完了」の一方向のみ遷移可能 - 完了状態から他状態へは遷移できない - 状態更新はボタン押下で切り替える - 機能は作成・一覧・状態更新に限定 - 状態遷移ルールを不変条件として PBT で検証したい 以下のような要件文書が出力されました。 受入基準が EARS 記法 [5] (「Easy Approach to Requirements Syntax: 要件定義の構文ルール)で明確に言語化 されています。 要件文書の抜粋 ### 要件3 **ユーザーストーリー:** ユーザーとして、チケットの状態を更新したい。作業の進捗を正確に反映するため。 #### 受入基準 1. WHEN ユーザーが未対応チケットの状態更新ボタンを押した時 THEN Ticket_System SHALL そのチケットを対応中状態に変更する 2. WHEN ユーザーが対応中チケットの状態更新ボタンを押した時 THEN Ticket_System SHALL そのチケットを完了状態に変更する 3. WHEN チケットが完了状態の時 THEN Ticket_System SHALL 状態更新ボタンを無効化する 4. WHEN 状態遷移が実行される時 THEN Ticket_System SHALL 未対応から対応中、対応中から完了の順序のみを許可する 5. WHEN 完了状態のチケットに対して状態変更が試行された時 THEN Ticket_System SHALL その操作を拒否し現在の状態を維持する 特に注目したのは、無効な遷移は拒否される、完了状態では操作できない、状態遷移の順序制約といった 後続の Property 定義につながる記述 が明確になっていた点です。 5-2. 設計文書（design.md）と Property 定義 # 設計書生成時、Kiro は次のことを宣言しました。 設計文書の前半部分を作成しました。次に、受入基準の分析を行ってから正確性プロパティを定義します。 出力結果の抜粋は以下でした。 Property が設計成果物として明示的に出力 されています。 設計文書の抜粋 ### プロパティ1: チケット作成時の初期状態 *任意の*有効なタイトルに対して、新しいチケットを作成すると、そのチケットは常に未対応状態で作成される ### プロパティ2: チケット作成時のリスト追加 *任意の*チケットリストと有効なタイトルに対して、新しいチケットを作成すると、リストのサイズが1増加し、新しいチケットがリストに含まれる ### プロパティ3: チケット表示内容の完全性 *任意の*チケットに対して、そのチケットをレンダリングした結果には、タイトルと現在の状態情報が含まれる ### プロパティ4: 有効な状態遷移の実行 *任意の*チケットと有効な遷移（未対応→対応中、対応中→完了）に対して、状態更新操作を実行すると、チケットの状態が期待される次の状態に変更される ### プロパティ5: 無効な状態遷移の拒否 *任意の*チケットと無効な遷移に対して、状態更新操作を実行しても、チケットの状態は変更されない ### プロパティ6: 完了状態での操作無効化 *任意の*完了状態のチケットに対して、状態更新ボタンは無効化され、操作が実行できない ### プロパティ7: システム不変条件の維持 *任意の*操作（作成、状態更新）の実行後、システム内の全てのチケットは有効な状態（未対応、対応中、完了のいずれか）を持つ 結果として、状態遷移だけでなく、初期状態の不変性、表示内容の完全性、システム全体の不変条件など、 人が明示的に頼んでいない Property まで含めて 7 件 が定義されました。 5-3. 実装計画（tasks.md）と Property のトレーサビリティ # 以下のような実装計画が出力されました。 実装計画の抜粋 - [ ] 2. ビジネスロジック層 - [ ] 2.1 状態遷移ロジックのテスト作成 - **プロパティ4: 有効な状態遷移の実行** (要件 3.1, 3.2, 3.4) - **プロパティ5: 無効な状態遷移の拒否** (要件 3.5, 4.2) - _要件: 3.1, 3.2, 3.4, 3.5, 4.2_ - [ ] 2.2 状態遷移関数の実装 - 有効な遷移の判定ロジック - 状態更新処理の実装 - テスト実行と通過確認 - _要件: 3.1, 3.2, 3.4, 3.5_ tasks.md では、Property、要件、テスト、実装タスクが対応付けられており、 「なぜこのテストが存在するのか」 が追跡可能になっていました。 また、TDD によるテストファーストの原則を採用したため、以下の流れが自然に形成されています。 テスト作成 → 実装 TDDを用いたAI駆動開発については、以下の記事も参照してください。 https://developer.mamezou-tech.com/blogs/2025/11/28/qdev-aidd-spec-kit/ 5-4. 実装と PBT の具体例 # 状態遷移の Property は、fast-check [6] を用いた PBT として実装しました。 記述されたテストコードサンプルを提示します。任意のタイトル、任意の有効状態に対して、 遷移の性質が必ず成立すること を検証しています。 TypeScript と fast-check によるテストコード例 test('未対応から対応中への遷移が正しく実行される', () => { fc.assert( fc.property(validTitleArb, (title) => { const ticket: Ticket = { title, status: TicketStatus.PENDING }; // 未対応から対応中への遷移は有効 const isValid = isValidTransition(ticket.status, TicketStatus.IN_PROGRESS); const nextStatus = getNextStatus(ticket.status); expect(isValid).toBe(true); expect(nextStatus).toBe(TicketStatus.IN_PROGRESS); }), { numRuns: 100 } ); }); 5-5. 動作確認 # 完成した画面にいくつかチケットを登録したり、エラーを発生させてみて、動作確認を行いました。 6. まとめ：Kiro で PBT を実装して分かったこと # 正直に言うと、 状態遷移だけでは PBT の凄さは分かりにくい と感じました。 今回の状態遷移のルールは単純なため、事例ベーステストでも十分に確認できてしまうからです。 しかし、UI 表示に関する Property で状況が一変します。 想定外だった発見 # チケットタイトル表示の Property テストでは、 連続する空白が HTML によって正規化されることや、 前後の空白・空白のみのタイトルの扱いが曖昧であることなど、 仕様として意識していなかった問題 が検出されました。 これらは、手動テストや事例ベーステストでは、まずテスト観点として挙がらなかったと思います。 この経験から、 PBT の価値は「網羅的に試すこと」ではなく、 「人が想定していなかった入力や前提を炙り出すこと」 にあると実感しました。 7. おわりに # Kiro を使うことで、以下のことを実感しました。 PBT 導入の心理的・実装的ハードルは確実に下がった。 Property を中心に仕様・設計・テストをつなげられる。 今回は単体レベルでしたが、 結合テストやシステムテストでの活用 も価値がありそうです。 今回使用したリポジトリは以下で公開しています。 （予告なく公開停止する可能性があります） https://github.com/hironori-maruoka/kiro-pbt-sample Takuto Wada. Property-based Testing の位置付け / Intro to Property-based Testing . Speaker Deck. ↩︎ Amazon Web Services. Kiro：生成 AI で IDE とコマンドライン機能を強化する新ツールが一般提供開始 . AWS ブログ, 2025. ↩︎ Fred Hebert, Leonid Rozenberg. 実践プロパティベーステスト ― PropErとErlang/Elixirではじめよう . ラムダノート, 2023. ↩︎ Matheus Evangelista. Building Smarter with Kiro: A Hands-On Look at Property-Based Testing . Medium, 2025. ↩︎ Alistair Mavin. EARS: The Easy Approach to Requirements Syntax . ↩︎ fast-check. fast-check . ↩︎

はじめに こんにちは、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 に最初に表示されました。