分～日のフィードバック：Observability

テストとCIは「コードは正しいか？」という問いに答える。しかし、答えられない問いのクラスがある：実際の環境で動いているとき、コードはどう振る舞うのか？

Observabilityはこのレベルのフィードバックを提供する。ログ、メトリクス、分散トレースがランタイムシグナルの3本柱を形成する。ログは離散的なイベントを記録し（何が起きたか）、メトリクスは集計的なトレンドを記録し（システムの状態がどう変化しているか）、トレースは因果関係を記録する（リクエストはどのサービスを通過し、どこで遅くなったか）。

Agent駆動開発にとって、Observabilityはテストではカバーできないフィードバックスペクトルのギャップを埋める。静的解析はミリ秒レベルの構文問題を処理し、テストは秒レベルのロジック問題を処理し、CIは分レベルの統合問題を処理する。Observabilityは時間～日レベルのランタイム問題を処理する：メモリが徐々にリークしていないか？エラーレートは上昇していないか？特定のエンドポイントのP99レイテンシが劣化していないか？これらのシグナルは遅延が最も長いが、問題ドメインのカバー範囲も最も広い。

Observabilityはまた、「合格か不合格か」を超えたフィードバック次元をAgentに提供する。テスト結果はバイナリだ --- 緑か赤か。Observabilityのシグナルは連続的だ：レイテンシが50msから200msに上昇するのは「失敗」ではないが、注目に値する。エラーレートが0.1%から0.5%に上昇してもアラートはトリガーされていないが、トレンドは間違っている。この種の連続的シグナルは、Agentにより洗練された軌道修正を要求すると同時に、改善の余地もより豊かに提供する。

実際には、Agentに直接Observabilityデータを消費させるには課題がある。ログは多くの場合、非構造化テキストだ --- 人間には意味があるが、Agentにはノイズだ。大量のメトリクスデータは先に集約・フィルタリングする必要があり、そうしないとAgentのcontext windowが無関係な情報で埋め尽くされる。効果的なアプローチは、Observabilityの「サマリー層」を構築することだ：生のシグナルを構造化され、アクション可能なフィードバックに加工する。100万行のログをAgentにダンプするのではなく、「過去1時間でpayment-serviceの5xxエラーレートが300%増加しました。代表的なエラーログ5件はこちらです」と伝える。

見落としやすい問題もある：静的コード分析はランタイムのトポロジー変更を捉えられない。仮想マシンからコンテナへの移行、単一データセンターからマルチアクティブアーキテクチャへの移行 --- これらの変更はコードには反映されないが、ランタイムの振る舞いに大きく影響する。Observabilityはそのような変更を感知する唯一の手段だ。