AIはソフトウェア開発のあり方を変えましたが、マシンに関する基本的な真実は変わっていません。人間と同じように、マシンもノイズに溺れてしまうのです。エンジニアがAIを活用したデバッグを初めて試すとき、その本能的な行動は単純です。モデルにすべてを投入することです。生のログ、トレース、メトリクスがすべてコンテキストウィンドウに放り込まれます。その結果、得られるのは洞察ではなく、失敗です。ボリュームが大きすぎます。シグナルが失われてしまうのです。メトリクスはあるツールに、トレースは別のツールにあり、モデルはそれらを一貫したストーリーとして繋ぎ合わせることができません。AIがシステムの観測を支援できるようになる前に、まず自分自身でシステムを観測しなければなりません。まずデータを形作る必要があるのです。

なぜ生のログがAIパイプラインを壊すのか

現代のシステムは、人間が読むことのできない速度でテレメトリを生成します。それこそが人工知能にとって完璧な素材であるはずです。しかし、実際はそうではありません。大規模言語モデル（LLM）のコンテキストウィンドウは、拡大傾向にあるとはいえ、依然として有限なパイプです。フィルタリングされていない本番環境のログを詰め込むと、実際の障害を埋もれさせたまま、cronジョブのハートビートやヘルスチェックのノイズにトークンを浪費することになります。さらに悪いことに、生のログには関係性が欠けています。午後2時のレイテンシのスパイクと、同じタイムスタンプのログにあるデータベース接続エラーは明らかに相関していますが、事前にその関係性が構造化されていない限り、AIは推測するしかありません。推測はコストがかかり、時間がかかり、そしてしばしば間違っています。

解決策はアルゴリズムではなく、アーキテクチャにあります。モデルにプロンプトを送る前に、何を収集し、どのように形作り、どのバックエンドがどの問いに答えるのかを決定する必要があります。

モニタリングの4つの軸

airClosetでは、エンジニアリングチームはオブザーバビリティを単一の「放水ホース」として扱うのをやめました。彼らはモニタリングを4つの異なる軸に分割しました。それぞれが特定の形状を持ち、特定の問いに答えます。

  • Application: ログとトレースが「今、何が起きているか？」に答えます。
  • Infrastructure: メトリクスが「リソースは十分か？」に答えます。
  • CI: ログとアラートが「何が、いつ壊れたか？」に答えます。
  • LLM: メトリクスと構造化されたレコードが「いくら費やしているか？」に答えます。

この分離が重要なのは、リアルタイムのレイテンシグラフに適した形状が、事後のコスト分析には役に立たないからです。4つのドメインすべてに単一のスキーマを強制すると、AIによる支援を無用にするノイズがまさに発生してしまいます。

CIオブザーバビリティ：プッシュではなくプル

継続的インテグレーション（CI）は、コードが現実と出会う場所です。ビルドが失敗したとき、開発者は迅速にその経緯を知る必要があります。素朴なアプローチは、CIランナーが実行中にログをオブザーバビリティ・バックエンドに直接プッシュすることです。一見効率的に思えますが、実際には危険です。

airClosetでは、このモデルを逆転させました。CIランナーはオブザーバビリティ・スタックには一切触れません。GitHub Actionsのワークフローが終了した後、GitHub APIからログをプルし、Lokiにインジェストします。

このプル型アーキテクチャは、3つの具体的なメリットをもたらします。

Decoupling. インジェスト・パイプラインに一時的な問題が発生したり、Grafanaにアクセスできなかったりしても、テスト実行自体には影響しません。ビルドはそれ自体の妥当性に基づいて成功または失敗します。オブザーバビリティの失敗によってデプロイが停止することがあってはなりません。

Security. CIワークフローにGrafanaのAPIキーを持たせる必要がありません。テストコードは、本来触れるべきでないシークレットに触れてしまうことで悪名高く、その露出を排除することで、依存関係が侵害された際の被害範囲を縮小できます。

Cross-querying. CIが