> [!abstract] 概要 > 近年のコーディングエージェントの進歩により、ますます複雑なソフトウェアシステムの生成が可能になった。既存の評価は主に機能的正しさに焦点を当てているが、本番システムはオブザーバビリティを支えるために障害の証拠を露出しなければならない。本論文では、エージェント生成システムにおけるオブザーバビリティの体系的研究を提示する。我々は、10 件のオープンソースと 8 件の産業用リポジトリでオブザーバビリティアーティファクトを復元することにより、エージェントがソースレベルの診断意味論を再構築できるかを検証する。また、これらのアーティファクトが Kubernetes 上にデプロイされ 13 件の障害が注入された 200 個の生成マイクロサービスシステムを通じて、実行時に効果的な障害シグナルへと転化するかも評価する。我々の結果は、ソースレベルの診断意味論と実行時の障害シグナルの間に一貫したギャップがあることを明らかにした。ソースレベルでは、エージェントはオブザーバビリティアーティファクトを部分的に回復するが、主要な診断意味論を捉えることには苦戦する。実行時には、生成されたシステムはロギングが存在するにもかかわらず、失敗のごく一部(最大 13.99%)に対してしか障害シグナルを露出しない。これは、生成されたオブザーバビリティアーティファクトが障害を効果的に露出するために必要な失敗固有の意味論を欠いている可能性を示唆する。我々はさらに、診断意味論と障害シグナル露出の両方を改善する指針として機能できる observability-oriented skill を導入するが、その効果は限定的にとどまり、このギャップが容易には解消されないことを示す。より広く、我々の知見は、機能的正しさを主に対象とする現行の評価が、実用的なソフトウェア品質の重要な次元としてのオブザーバビリティを見落としている可能性があることを示唆する。 ## 論文情報 - **タイトル**: Can Large Language Models Generate Observability-Aware Code? - **著者**: Yongliang Tao¹, Hongyu Zhang¹, Pengfei Gao², Minghua Ma², Zhiyu Fan², Yu Kang², Jue Zhang², Si Qin², Liqun Li², Qingwei Lin², Saravan Rajmohan² - **所属**: ¹Chongqing University(重慶大学、中国)、²Microsoft - **媒体**: arXiv プレプリント - **発表年**: 2026(投稿日 2026-07-07 と推定。arXiv ID `2607.05785` から) - **arXiv ID**: 2607.05785v1 - **URL**: https://arxiv.org/abs/2607.05785v1 ## 概要 コーディングエージェントが生成するコードのオブザーバビリティ(可観測性)を、ソースレベルの診断意味論復元(RQ1)と実行時の障害シグナル露出(RQ2)の 2 軸で評価した実証研究。18 リポジトリ・1,223 インスタンスのソースレベル復元実験と、200 個の agent 生成マイクロサービス・1,615 件の注入障害インスタンスによる実行時実験を組み合わせ、両者に一貫したギャップがあることを示す。軽量な diagnosis-oriented skill による緩和策(RQ3)も検証するが、改善は小幅にとどまる。 ## 問題設定 - **入力**: (RQ1)オブザーバビリティ文(ログ・トレース・メトリクス呼び出し等)を削除したソースコード + リポジトリ全体のコンテキスト。(RQ2)高レベルのアーキテクチャ仕様。(RQ3)RQ1・RQ2 と同一タスクに observability skill を付加したプロンプト。 - **出力**: (RQ1)エージェントが再生成したオブザーバビリティ文を含むコード。(RQ2)Kubernetes にデプロイ可能な完全なマイクロサービス実装。 - **前提**: エージェントはリポジトリ全体のコンテキストにアクセスできる(単一関数の孤立コンテキストではない)、ツール実行の自動承認あり。 - **中心的な問い**: 「現行のコーディングエージェントは、実行可能(runnable)なだけでなく操作可能(operable)なコード ── 失敗時に診断可能なコード ── を生成するか」。論文は「診断意味論(diagnostic semantics、observability artifact が捉える失敗関連の文脈)」と「障害シグナル(fault signal、失敗時実行中に得られる明示的で障害固有の証拠)」を明確に区別し、前者が後者の**必要条件だが十分条件ではない**と位置づける(source-level 分析と runtime 分析は関連するが等価ではない)。 ## 提案手法 - **アーキテクチャ**: 3 段階の評価パイプライン(Figure 1)。RQ1(ソースレベル復元)→ RQ2(agent 生成マイクロサービスの実行時障害シグナル評価)→ RQ3(observability skill による誘導と再評価)の順に、孤立能力分析から現実的な運用挙動、誘導による改善へと段階的に検証範囲を広げる。 - **RQ1: 静的オブザーバビリティ復元(アルゴリズム/手法の詳細)**: - **データセット**: 10 GitHub リポジトリ(441 インスタンス、いずれも 1k star 超のマイクロサービスプロジェクト)+ 8 産業用データセット(782 インスタンス、1 年以上稼働・インシデント駆動で改善されてきた本番システム)= 計 1,223 インスタンス。 - **手続き**: 言語固有パーサでログ・トレース・メトリクス更新・span 属性・span イベントのいずれかを含む関数を抽出(自明な関数・テスト・生成コード・ビルド成果物は除外)。オブザーバビリティ文を全て削除してビジネスロジックと制御フローのみ保持したものをエージェントへの入力とし(Figure 3)、元の実装を ground truth とする。 - **3 種のプロンプト戦略**: (1) observability-blind(オブザーバビリティに関する明示指示なし。エージェントの内発的意識を測る)、(2) observability-hinted(オブザーバビリティ改善を明示指示)、(3) few-shot(同一ファイル内の実例を提示)。 - **評価指標**: - **Position F1(どこに計装するか)**: 生成コードと ground truth を非オブザーバビリティ文をアンカーに整列させ、関数を「バケット」(最初のマッチ前・マッチ間・最後のマッチ後)に分割。各バケットが観測可能性文を含むかの二値指標から Precision/Recall/F1 を計算(式は本文参照)。 - **KeyBag F1(何を捉えるか)**: 両方にオブザーバビリティが存在する整列済みバケットについて、文字列リテラル・識別子・属性名・キーワード引数名を正規化(小文字化・区切り文字分割・camelCase 分割・`logger`/`span`/`event` 等のストップワード除去)してトークン集合(KeyBag)を抽出し、集合の重なりから Precision/Recall/F1 を計算。 - **RQ2: agent 生成マイクロサービス系の実行時オブザーバビリティ**: - **データセット**: e-commerce・ソーシャルネットワーキング・IoT テレメトリ・金融・医療・コンテンツ管理・SaaS・旅行・物流・ゲーム・observability/DevOps を含む多様なドメインから抽出した 200 件のクラウドネイティブマイクロサービスアーキテクチャ仕様。各仕様をコーディングエージェントへの実装プロンプトとして与え、デプロイ可能な完全なマイクロサービス系を自動生成させる。 - **評価パイプライン(Figure 2)**: エージェントがサービスを生成 → 統一評価ハーネス(ランタイム環境・デプロイ設定・ワークロード生成・障害注入基盤)上で Kubernetes へビルド・デプロイ → 継続的リクエストでサービスを稼働状態に保ちながら Chaos Mesh で障害を注入 → 障害ウィンドウ中のランタイムログを収集・オフライン解析。 - **障害注入(13 種、Table I)**: サービス障害(pod-kill)・依存性障害(upstream-fail/slow, db-down/slow, cache-down/slow, queue-down/slow)・ネットワーク異常(network-delay, net-corrupt)・資源競合(cpu-stress)・時間関連障害(time-skew)。ChaosMesh の PodChaos/NetworkChaos/HTTPChaos/StressChaos/TimeChaos を使用。200 系×13 障害プリミティブから計 1,615 件の実行可能障害インスタンスを生成。 - **Fault Signals Rate(FSR)**: 障害ウィンドウ中に収集したログのうち、少なくとも 1 件のフォールト固有ログ証拠(Table I の障害別シグネチャ、例: タイムアウト/デッドライン語彙、`connection refused`、HTTP 503 等)が現れた障害インスタンスの割合。「ログの量」でなく「障害を明示的に露出できたか」を測る保守的(conservative)な定義であり、完全な根本原因分析(RCA)を要求しない代わりに、汎用的なリクエストログやステータスコードだけでは不十分とする。 - **RQ3: observability-oriented skill による誘導**: - 内部の失敗レポジトリから収集した約 200 件のオブザーバビリティ関連コミット(経験豊富なエンジニアが本番障害の診断・修復のために作成)を分析し、依存性障害・タイムアウト・リトライ・例外伝播などの再発パターンを軽量な診断指向の原則として抽象化。 - スキルは以下を指導する: サービス境界・責務・依存性・運用文脈の識別、依存呼び出しと制御フロー境界への計装、相関 ID・ステータスコード・レイテンシ・リトライ回数・タイムアウト値・例外原因などの主要診断シグナルの捕捉、サービス/操作/依存性/リクエスト文脈にわたる一貫したオブザーバビリティ規約の遵守、高基数/機微データを避けた軽量な計装。 - RQ1・RQ2 と同一のタスク・障害注入設定で skill-guided agent とベースラインを比較(モデル・プロンプト・環境は統制)。 - **実装**: GPT-5.5・Claude Opus 4.8・Gemini 3.5 Flash の 3 種のクローズドソースフロンティアモデルを、GitHub Copilot SDK ベースの統一エージェントインタフェース経由で評価。生成サービス実験では全モデルが同一のタスク記述・プロンプトテンプレート・リポジトリワークスペース・対話プロトコルを共有し、リポジトリアクセスとツール権限の自動承認を持つ。実行トレースは監査用に記録。 ![[_attachments/arxiv-2607.05785v1/fig01-study-overview.png]] (Figure 1. Overview of Study. RQ1〜RQ3 の 3 段階評価パイプライン。RQ1 はオープンソース/産業リポジトリからのオブザーバビリティ剥離→エージェント再生成→ground truth 比較で Position F1・KeyBag F1 を算出。RQ2 は vibe-coded マイクロサービスをデプロイし障害注入→ランタイムログ解析で Fault Signal Rate を算出。RQ3 は失敗プロファイル抽出から observability skill を作り強化エージェントを再テストする。Source: Fig. 1, p.2.) ![[_attachments/arxiv-2607.05785v1/fig03-restoration-example.png]] (Figure 3. Example of Static Observability Restoration. `checkout` 関数の例。左は元実装からオブザーバビリティ文(`span.set_attribute`・`span.add_event` 等、赤字)を削除する Observability Stripping の過程。右は剥離済みコードに 3 種のプロンプト(observability-blind/hinted/few-shot)を与えてエージェントが Agentic Regeneration した結果 ── `logger.info("start checkout")` と `span.set_attribute("user.id", ...)` を独自に挿入するが、元の `payment_charged` イベントのような意味論までは再現しない。Source: Fig. 3, p.4.) ## 新規性 既存のコーディングエージェントベンチマーク(HumanEval・TerminalBench 等の関数レベル正しさ評価、SWE-Bench 等のリポジトリレベルタスク完了評価)は、機能的正しさ(パッチが issue を解決するか)を中心に据えており、生成システムが本番で障害発生時にどれだけ診断可能かを問わない。ソフトウェアオブザーバビリティ研究(ログプラクティス調査等)は人間が書いたコードのロギング慣行を扱ってきたが、コーディングエージェントが自律的に生成するコードのオブザーバビリティは未開拓だった。ログ解析研究(Drain・LLM ベースのログ解析/異常検知/RCA)は既存ログを解析する側に注力しており、「そもそも生成されたログが診断に十分な意味論を含むか」という計装(instrumentation)側の問いには答えていない。 本論文の新規性は、(1) 診断意味論(source-level)と障害シグナル(runtime)を明確に区別した多レベル評価フレームワークの導入、(2) 18 リポジトリ 1,223 インスタンスの統制されたソースレベル復元研究と 200 系・1,615 件注入障害の大規模実行時評価を組み合わせた実証、(3) 現実世界の 200 件の失敗修復コミットから抽出した軽量スキルによる緩和策の検証、の 3 点にある。特に「ロギングの量」でなく「障害固有の意味論を明示的に含むか」を保守的に定義した FSR 指標により、"生成システムはログを大量に出すが実際には何も診断できていない" という定量的なギャップを初めて可視化した。 ## 実験設定 - **RQ1 データセット**: 10 GitHub リポジトリ(OpenTelemetry Demo・Google Cloud microservices-demo・DeathStarBench・eShop・nestjs・robusta・microservices-demo・Train-Ticket・Strapi・Vector)、441 インスタンス + 8 産業用データセット、782 インスタンス。計 1,223 インスタンス。 - **RQ2 データセット**: 200 件のクラウドネイティブマイクロサービスアーキテクチャ仕様(実世界のオープンソース・産業システムから抽象化)。 - **比較対象・評価モデル**: GPT-5.5・Claude Opus 4.8・Gemini 3.5 Flash の 3 モデル(GitHub Copilot SDK 経由)。 - **評価指標**: Position P/R/F1、KeyBag P/R/F1(RQ1)、Fault Signals Rate(FSR)・Subset FSR(RQ2)。 - **障害注入基盤**: Kubernetes クラスタ上の Chaos Mesh。13 種の障害プリミティブ(Table I)、Easy/Medium/Hard の難度分類(Table IV)。 - **再現性**: LLM 生成のランダム性を緩和するため各実験を 5 回繰り返し平均を報告。 ## 実験結果 ### RQ1: 静的オブザーバビリティ復元(Table II) | Prompt | Model | Pos. P | Pos. R | Pos. F1 | KeyBag P | KeyBag R | KeyBag F1 | |---|---|---|---|---|---|---|---| | observability-blind | GPT-5.5 | 0.544 | 0.606 | 0.551 | 0.331 | 0.458 | 0.357 | | observability-blind | Claude Opus 4.8 | 0.554 | 0.708 | 0.580 | 0.270 | 0.412 | 0.294 | | observability-blind | Gemini 3.5 Flash | 0.277 | 0.333 | 0.278 | 0.233 | 0.262 | 0.237 | | observability-hinted | GPT-5.5 | 0.442 | 0.695 | 0.505 | 0.204 | 0.488 | 0.260 | | observability-hinted | Claude Opus 4.8 | 0.426 | 0.842 | 0.528 | 0.243 | 0.476 | 0.291 | | observability-hinted | Gemini 3.5 Flash | 0.269 | 0.438 | 0.307 | 0.176 | 0.288 | 0.197 | | few-shot | GPT-5.5 | 0.530 | 0.774 | 0.594 | 0.334 | 0.571 | 0.383 | | few-shot | Claude Opus 4.8 | 0.568 | 0.816 | 0.633 | 0.371 | 0.518 | 0.398 | | few-shot | Gemini 3.5 Flash | 0.409 | 0.578 | 0.448 | 0.349 | 0.446 | 0.367 | - **Finding 1(暗黙的意識の限界)**: blind プロンプトでも GPT-5.5 の KeyBag Recall が 0.458、Claude Opus 4.8 の Position Recall が 0.708 に達し、エージェントは明示的指示なしにオブザーバビリティの必要性をある程度認識する。しかし KeyBag F1 は全モデルで低い(GPT-5.5: 0.357、Claude Opus 4.8: 0.294、Gemini 3.5 Flash: 0.237)。 - **Finding 2(explicit hint 下での Quantity over Quality)**: observability-hinted プロンプトは blind と比べ生成量を大幅に増やす(4.9 vs 2.1 文/インスタンス、22.9 vs 11.5 KeyBag トークン/インスタンス、Figure 4)が、KeyBag Recall はわずかに改善(0.488 vs 0.458、+0.030)する一方 Precision は大きく低下(0.20 vs 0.33、-0.13)し、KeyBag F1 は低下(0.26 vs 0.36、-0.10)。Position F1 も同様に低下(0.51 vs 0.55、-0.05)。 - **Finding 3(Few-shot の効果)**: few-shot プロンプトは blind と比べ KeyBag F1 を 0.357→0.383(+0.025)、Position F1 を 0.551→0.594(+0.043)改善。この改善は主に Recall の伸び(KeyBag +0.114、Position +0.168)によるもので、Precision はほぼ維持される。 - **Finding 4(配置 vs 内容)**: 全プロンプト戦略で Position F1 が KeyBag F1 を一貫して上回る(blind: 0.551 vs 0.357、hinted: 0.505 vs 0.260、few-shot: 0.594 vs 0.383)。エージェントは「どこに計装するか」より「何を記録するか」の再現が体系的に弱い。 ### RQ2: agent 生成マイクロサービス系の実行時オブザーバビリティ(Table III・Table IV) | Model | Runnable Services | FSR | Subset FSR | |---|---|---|---| | GPT-5.5 | 151/200 | 4.95% | 6.56% | | Claude Opus 4.8 | 154/200 | 6.32% | 8.28% | | Gemini 3.5 Flash | 136/200 | 13.99% | 20.62% | - **Finding 1(大半の障害は不可視のまま)**: 全モデルで FSR は 4.95〜13.99% と一貫して低く、正常稼働したサービスに限定した Subset FSR でも最良モデルで 20.62% にとどまる。この限界はログの不在によるものではなく、ログに障害固有の明示的意味論が欠けていることに起因する。 - **Finding 2(可観測な障害は明示的エラーを伴うものに限られる)**: Table IV(全障害の FSR、Caught/Total)によると、upstream-fail(F03)27.45%、pod-kill(F01)20.33%、cache-down(F07)17.13% は "Easy" に分類され、明示的なエラー応答・サービス利用不能として自然に現れる障害ほど高い FSR を示す。一方 time-skew(F13)1.26%、cpu-stress(F11)1.44%、net-corrupt(F12)1.80% は "Hard" に分類され、暗黙的な影響しか生じない障害はほぼ検出されない。 - **Finding 3(ログは多いが診断意味論を欠く)**: 生成システムは頻繁にランタイムログ(リクエストイベント・ステータスコード等)を出力するが、これらは異なる障害タイプを区別するための情報をほとんど含まない。Figure 5 の失敗事例は、多数のログ(`GET /events/resource`、`HTTP Status=201`)が出力されながらタイムスタンプ不一致や TTL 期限切れ、クロックスキューといった障害固有の意味論を一切含まず Fault Signal を得られない一方、成功事例では `error="timeout"`・`dependency=redis` のように具体的な依存性とエラーの種類を含むログが Fault Signal を生む対比を示す。 ![[_attachments/arxiv-2607.05785v1/fig05-success-failure-cases.png]] (Figure 5. Representative success and failure cases under the same evaluation. 左(Failure Case): `GET /events/resource` と `HTTP Status=201` のみのログは多いが、Timestamp Mismatch・TTL Expired Early/Late・Clock Skew といった障害固有の意味論を欠き Fault Signal を生まない。右(Success Case): `error="timeout"`・`dependency=redis` を含むログは Redis タイムアウトと具体的な依存性を示し Fault Signal として成立する。Source: Fig. 5, p.8.) ![[_attachments/arxiv-2607.05785v1/fig04-quantity-vs-quality.png]] (Figure 4. Quantity over Quality under observability-hinted prompt. (a) 生成文数は blind 2.1→hinted 4.9 文/インスタンスへ倍増、(c) KeyBag トークン数も 11.5→22.9 へ倍増。(b) Position F1 は 0.55(blind)→0.51(hinted)、(d) KeyBag F1 は 0.36(blind)→0.26(hinted)へいずれも低下し、量の増加が質の低下と表裏一体であることを示す。Source: Fig. 4, p.7.) ### RQ3: observability-oriented guidance の効果(Table V) | Model | Setting | Pos F1 | KeyBag F1 | FSR | |---|---|---|---|---| | GPT-5.5 | w/o skill | 0.594 | 0.383 | 4.95% | | GPT-5.5 | w/ skill | 0.597 | 0.395 | 13.62% | | GPT-5.5 | Gain | +0.003 | +0.012 | +8.67 pp | | Claude Opus 4.8 | w/o skill | 0.633 | 0.398 | 6.32% | | Claude Opus 4.8 | w/ skill | 0.649 | 0.407 | 7.31% | | Claude Opus 4.8 | Gain | +0.015 | +0.009 | +0.99 pp | | Gemini 3.5 Flash | w/o skill | 0.448 | 0.367 | 13.99% | | Gemini 3.5 Flash | w/ skill | 0.452 | 0.371 | 16.53% | | Gemini 3.5 Flash | Gain | +0.004 | +0.004 | +2.54 pp | - **Finding 1(FSR の改善)**: observability skill は全モデルで FSR を改善する。GPT-5.5 は 4.95%→13.62%(+8.67 pp)と最も大きく改善する一方、Claude Opus 4.8 は 6.32%→7.31%(+0.99 pp)、Gemini 3.5 Flash は 13.99%→16.53%(+2.54 pp)と改善幅は小さく、全体としては依然として低い水準にとどまる。 - **Finding 2(診断意味論の改善は限定的)**: Pos F1・KeyBag F1 も小幅ながら一貫して改善する(GPT-5.5: KeyBag F1 +0.012、Claude Opus 4.8: Pos F1 +0.015、Gemini 3.5 Flash: いずれも +0.004)が、いずれも 0.01〜0.02 程度の小さな伸びにとどまる。 ## 考察 - 論文は「観測性は指示に単純に従うだけの能力ではなく、文脈依存の生成問題である」と総括する(RQ1 サマリ)。RQ1 のソースレベル復元における限界(特に低い KeyBag F1)は、RQ2 の実行時評価における低い FSR と整合的であり、根底にある能力限界が両レベルで一貫して現れる。 - explicit instruction が量を増やしても質を伴わない(Finding 2、Quantity over Quality)ことは、単純なプロンプトエンジニアリングによる緩和には限界があることを示す。一方 few-shot による改善(Finding 3)は、リポジトリ固有の規約・命名パターンへの文脈的グラウンディングが有効であることを示唆する。 - observability skill(RQ3)は 200 件の実コミットから抽出した診断指向原則にもかかわらず、改善が小幅にとどまる(§V-A)。論文は 2 つの仮説を提示する: (1) 訓練データにおいてオブザーバビリティが独立した目的として表現されることが稀であり、コーディングエージェントは「どこに計装が通常挿入されるか」という表層パターンは学習できても、「特定の失敗に対して何を記録すべきか」という意味論を推論できない、(2) 現行のコーディングエージェントは主に静的ソースコードから学習しており、実行時のシステム挙動から学習していないため、障害伝播や実行可能な診断的証拠についての推論能力が不足している。 - 論文は、オブザーバビリティが「機能的コード生成の副産物」ではなく「コーディングエージェントの独立した能力」として扱われるべきであり、将来研究はプロンプトエンジニアリングに頼るのではなく、失敗を意識した推論やランタイムフィードバックを生成プロセスへ統合する必要があると結論づける。 ## 強み / 弱点・課題 **強み**: - ソースレベル(診断意味論)と実行時(障害シグナル)を明確に区別し、両者の関係を実証的に接続した点。1,223 インスタンスの統制された復元実験と 1,615 件の実障害インスタンスによる大規模実行時実験を組み合わせることで、単一レベルの評価では見えない一貫したギャップを可視化した。 - FSR という保守的な指標(ログの量でなく障害固有の明示的意味論の有無)により、「ログは大量にあるが実際には診断に使えない」という現象を定量化した。 - 現実の失敗修復コミットから抽出した skill による緩和策を検証し、プロンプトレベルの介入だけでは解決しない構造的なギャップであることを示した点。 **弱点・課題(著者の Threats to Validity に基づく)**: - **Oracle-based FSR の見落とし**: FSR は障害固有のオラクル(Table I のシグネチャ)に依拠しており、オラクル基準を満たさない部分的・間接的な有効シグナルを見落とす可能性がある。ただし同一オラクルを全設定に一貫適用しているため相対比較の傾向は安定するとされる。 - **人間記述オブザーバビリティの非最適性**: KeyBag の ground truth は人間が書いたコードに由来するが、これは事後的な障害対応で追加・改善されたものであり、完全または最適なオブザーバビリティを保証しない。ただし、エージェントは単純化された復元設定でもこの実践的パターンの再現に失敗しており、この限界は基準の選択に起因するものではないと考えられる。 - **LLM 生成のランダム性**: デコーディングの変動が生成ログの配置・内容、ひいては FSR に影響しうる。5 回の繰り返し平均で緩和しているが、LLM のハルシネーションによる追加的な変動も指摘されている。