AI時代の可観測性設計 – アプリ、インフラ、CI、LLM（パート1）
AI時代に対応した可観測性スタックの再設計について。監視を4つの軸（アプリケーション、インフラストラクチャ、CI、LLM）に分割。アプリは標準OTelスタック、インフラはGCPメトリクスをMimirに統合、CIはGitHub APIから事後的にログをLokiにプル、LLMはGeminiはPrometheusでリアルタイムコスト推定、Claude CodeはBigQueryでSQL集計。データはAIが消費する前に整形される必要があると強調。
本記事はシリーズ第1回。airCloset CTOのRyan氏が、AI時代に向けた可観測性スタックの再設計について解説。データはAIが消費する前に整形される必要があり、生ログをそのままAIに投入するとコンテキストウィンドウを圧迫し、エラーとノイズの区別もつかない。そこで監視面を4つの軸に分割した。
アプリケーション：標準OTelスタック。全cortexアプリにOpenTelemetryを導入し、トレースはTempo、ログはLoki、メトリクスはMimirへ。全サービスで一貫した形状が後々のAIによる横断検索を可能にする。
インフラストラクチャ：GCPメトリクスをMimirに統合。Cloud Run、BigQuery、Pub/SubなどのメトリクスをCloud Monitoring経由でMimirに集約。単一ストアによりAIは「先週最もCPUを使ったサービスは？」といった質問に自然に答えられる。
CI：ログを事後プルでLokiに送信。GitHub ActionsでCIを実行し、完了後にGitHub APIからログをプル。プッシュ方式を取らない理由は、CI実行と可観測性の分離、APIキーのセキュリティ、独立したリトライとアラートが可能な点。LogQLでメインブランチの失敗をフィルタリングし、アラートから自動修復へつなげる。
LLM：GeminiとClaude Codeで異なる形状。Geminiは呼び出しコードを制御できるため、Prometheusメトリクスでリアルタイムコスト推定。クライアントサイドでトークン数×料金表からコストを計算し（クラウド課金APIは遅延と粒度不足のため）、呼び出しサイトごとのコスト可視化を実現。Claude Codeは外部CLIのため、使用記録を構造化データとしてBigQueryに送信。SQL集計により、ユーザー別やリポジトリ別の利用状況、キャッシュヒット率などを分析する。
次回（パート2）ではPII処理、統合面、自己修復について取り上げる予定。