大量の継続的インテグレーションログをテラバイト単位で大規模言語モデルに供給しました。

Japanese Translation:

（欠落している要素を含めて）**

システムは、巨大で高圧縮されたCIログデータベースに対しオンデマンドSQLクエリを実行することで、数秒以内にフラッキーなテストの原因を特定できます。

• 毎週約15億行のログと70万件のジョブがClickHouseに取り込まれます（35:1圧縮率、行あたり約21バイト、ディスク上で154 GiB）。

• エージェントのSQLインタフェースは調査対象組織に限定されており、動的にクエリを構築できるため、予期しない質問にも対応可能です。

• 2つのデータターゲットがクエリ対象になります：ジョブメタデータのマテリアライズドビュー（使用率63％）と生ログ行（37％）。メタデータは中央値20 ms、全文検索は110 msです。

• 8,534件の調査で52,312回のクエリが実行されました。典型的なスキャンでは約3問合せに対して33.5万行を読み取り、P95のスキャンでは9億4千万行、極端なケースでは43億行まで処理し、すべて数秒で完了します。

• ClickHouse のカラム指向フォーマット、非正規化メタデータ（1行あたり48列）、org/timestamp/repo/run_id による主キーソート、ブルームフィルター、および ngram インデックスにより、スキャン行数と線形的に遅延が伸びます。

• GitHub API の制限（1時間あたり15,000リクエスト）はインジェストをサロートする必要があります（約3リクエスト/秒）。耐久性のあるエンジンはレートリミットに達した際に一時停止し、重複なしで再開します。95パーセンタイルのインジェスト遅延は5分以内に抑えられ、3,000件までのキュー増加も吸収できます。

• Docker と Dagger の経験を持つ Mendral（YC W26）チームが構築したこのアーキテクチャは、失敗検出と根本原因調査を自動化し、開発者がデバッグ時間を短縮しパイプラインの信頼性を向上させることを可能にします。

先週、私たちのエージェントはフレッキーなテストを３週間前に発生した依存関係のバンプに結びつけることができました。
それは自らSQLクエリを書き、数十個のクエリにわたる何億ものログ行をスキャンし、ジョブメタデータから生ログ出力へと追跡することで実現しました。調査全体は数秒で完了します。

エージェントが必要とするもの

単一のログファイルではなく、月単位で全ビルド・すべてのテスト・すべてのログ行を網羅。
毎週約15億件のCIログ行と70万件のジョブがシステムに流れます。
それらはClickHouseに35:1の圧縮率で保存され、ミリ秒単位でクエリ可能です。

エージェント用SQLインターフェース

調査対象組織に限定したSQLインターフェースを公開します。
エージェントは質問に応じて自らクエリを構築し、事前定義されたクエリライブラリや厳格なツールAPIはありません。
LLMがSQLを書くのに長けているため、未知の障害をデバッグする際に予想外の質問も可能です。

主な対象

ターゲット	説明	利用時間割合
ジョブメタデータ	CIジョブ実行ごとに1行ずつのマテリアライズドビュー。	63 %
生ログ行	ログ行ごとに1行ずつ。	37 %

典型的な質問例：

ジョブメタデータ – 「この失敗はどれくらい頻繁か？」「成功率はいくらか？」「最も遅いジョブはどれか？」「いつから失敗が始まったのか？」
生ログ – 「このジョブのエラー出力を表示して。」「このログパターンはいつ初めて現れたか？」「このエラーメッセージは実行ごとにどれくらい頻度で発生するか？」

クエリの規模

指標	値
8.5 k調査で52 kクエリ	—
セッションあたり平均スキャン行数	4.4クエリ、335 k行（中央値）
P75 行数	5.2 M
P95 行数	940 M
最も重い生ログセッション	4.3 B行

典型的な調査では約３つのクエリで335 k行をスキャンします。最も重いケースは数十億行に達します。

データ構造と圧縮

各ログ行には48列のメタデータ（コミットSHA、著者、ブランチ、PRタイトル、ワークフローネーム、ジョブ名、ステップ名、ランナー情報、タイムスタンプ等）が付随します。
行ストアでは膨大になりますが、ClickHouseの列指向フォーマットは同一値を連続して保存し、大幅な圧縮を実現します。
圧縮率例
- ```
commit_message
```
  301:1
- ```
display_title
```
  160:1
- ```
workflow_path
```
  79:1
  …（詳細は元資料の表参照）

ストレージ概要

レイヤ	サイズ
生ログテキスト（未圧縮）	664 GiB
48列すべて未圧縮	5.31 TiB
ディスク上（圧縮済み）	154 GiB

つまりディスク上は1行あたり約21バイトで、メタデータを含めた全情報が保存されます。

クエリ性能

ClickHouseの設計により高速化：

主キー設計 –
```
(org, ts, repository, run_id, …)
```
でソートし、組織/時間帯限定クエリは不要データをスキップ。
スキップインデックス – 14列のブルームフィルタと
```
line_content
```
のngramブルームフィルタで全文検索を高速化。
マテリアライズドビュー – 挿入時に集計済み。
非同期挿入 – カスタムバッチなしでも高書き込みスループット。

レイテンシ（全クエリ）：

ターゲット	中央値	P75	P95
ジョブメタデータ	20 ms	30 ms	80 ms
生ログ行	110 ms	780 ms	18.1 s

レイテンシはスキャン行数にほぼ比例（10倍増＝10倍の遅延）。
60 % のクエリが <100 k 行をスキャンし、<50 msで応答します。

GitHub レートリミット経由の取り込み

GitHubはアプリインストールごとに1時間あたり15,000リクエスト（非Enterpriseプランでは5,000）を許容。
ワークフロー実行、ジョブ、ステップ、ログ出力を多数リポジトリから継続的に取得すると、この枠がすぐに逼迫します。

問題点

取り込みがレートリミットに突入し、残り時間はブロックされ、30分以上遅延。
エージェントが新鮮なデータを必要とする場合には全く機能しません。

解決策

1秒あたり約3リクエストでスロットリングし、残り4,000リクエストをエージェント用に確保。
バーストではなく時間窓内で均等にリクエストを分散。
スロットリングが安定した後は取り込み速度を約20 %増加。レート枠を完全に使い切らないようにする。

目標: P95で5 分以内（GitHubイベントからシステム内でクエリ可能になるまで）。ほとんどの場合数秒です。

Inngestによる耐久実行

取り込みパイプラインとエージェントはInngestという耐久実行エンジン上で動作します：

レートリミットに達したらクラッシュせずサスペンド。
GitHubの「retry‑after」ヘッダーを読み、10 %のジャイターを付与して正確に再開。
再初期化や重複処理なし。レート制限は単なる一時停止ボタンです。

トラフィックスパイクへの対応

CI活動は突発的（マージ、リリース、同時に複数チームがプッシュ）で、取り込みスループットは800–1,000実行/秒と安定。
キュー内の作業量が3,000件以上になるバーストでもシステムは迅速に回復し、5分P95の目標を維持します。

私たちは Mendral（YC W26）を構築しています。DockerとDaggerでCIシステムを10年以上スケールさせてきた経験から、常に直面する課題は「ログを見る」「失敗を相関させる」「何が変わったかを突き止める」ことです。今こそ、そのプロセスを自動化します。