出来事の日付：2026年10月7日。

SREGymが公表した結果によると、意思決定モデルJevを中心に構築した実験的な信頼性エンジニアリング用パイプラインが、Kubernetesの障害シナリオ群における105回の診断のうち80回で合格した。合格率76.2％は、過去の9月4日版SREGym-Lite評価セットに含まれる21種類の障害を、それぞれ5回ずつ実行して得られた。診断時間の中央値は14.6秒だった。

このシステムは、一般的な言語モデルエージェントとは異なる。まずプログラム化された収集機構が、Kubernetesのオブジェクト、イベント、直近のPodログ、リソース使用状況を読み取る。観測内容をコンポーネント別にまとめ、疑われる障害の概要を整理する。その後Jevが、どのコンポーネントが最も関係していそうか、それが原因なのか下流で影響を受けている側なのか、どの証拠が診断を最もよく裏付けるかについて、パイプラインが提示した選択肢から選ぶ。最終報告書を組み立てるのはJevではなく、パイプラインだ。

この制約を設けた設計は、収集機構が明確な不一致を見つけた場合に、特にうまく機能した。あるソーシャルネットワークのシナリオでは、デプロイメントのテンプレートで256Miが指定されていたにもかかわらず、新たに作成されたnginx-thriftのPodのメモリー上限が16Miになっていた。収集した証拠からは、これに対応するAdmission Webhookも特定された。Jevは影響を受けたコンポーネントと、それを裏付ける観測結果を選択し、5回の試行すべてが評価基準を満たした。

失敗例は、証拠を過度に絞り込むことの代償を示している。Astronomy Shopのテストでは、Jevは処理能力が飽和したフロントエンドのプロキシーに正しく着目したものの、負荷を引き起こした処理コストの高いリクエストフィルタールールではなく、低いCPU上限を原因とした。各試行の得点は0.67で、この研究の合格基準である0.70を下回った。ホテル予約のシナリオでは、診断は料金サービスの過負荷を認識したが、キュー、タイムアウト、再試行が互いに増幅し合う相互作用を見落とした。パイプラインがそのループに関する十分な測定値を提供していなかったためだ。

SREGymによると、Jevパイプラインは比較対象の言語モデルエージェントより約7倍高速で、診断1回当たりの費用は約200分の1だった。また、76.2％という結果は、比較対象システムの77.8％に近かった。これらの数字は同プロジェクト自身が条件を管理した評価から得たもので、本番環境全般に通用するベンチマークと受け取るべきではない。

この実験の主な教訓は、システムの設計にある。高速な選択モデルが役立つのは、周囲の収集機構が適切な事実と回答の選択肢を提供する場合に限られる。著者らは、これを診断の第一段階に使い、より広範な調査や複数のサービスにまたがる推論が必要な障害は、より柔軟な言語モデルエージェントに任せる方法を提案している。

結果の一貫性も注目された。それぞれの障害は、5回すべてで合格するか、5回すべてで不合格になるかのいずれかで、18種類の障害では毎回同じ得点になった。この傾向は、クラスターの状態をどのように表現して与えたかが、結果を強く左右したことを示唆している。大まかな要約は決定的な細部を隠してしまう一方、設定を漏れなく出力すると、その細部が大量の情報に埋もれるおそれがある。