OpusへのアップグレードでLLMコストを削減したMendralの方法：トリアージャーパターン、SQLアクセス、サブエージェントアーキテクチャ

Mendralは最近、CI障害分析のためにOpus 4.6にアップグレードしつつ、以前のSonnet 4.0のセットアップと比較してLLM全体のコストを削減した方法を公開しました。鍵となるのは、トリアージと調査を分離し、負荷の高い作業に安価なサブエージェントを使用するアーキテクチャです。

アーキテクチャ：安価なトリアージャー、高価なプランナー

分析された約4,000件のCI障害のうち、3,187件は重複でした（既知の不安定なテスト、インフラの不具合、ネットワークの一時的な問題）。そのようなものに高価なモデルを起動するのは無駄です。しかし、重複排除は決定的ではありません。同じジョブでも異なる理由で失敗することがあります。彼らの解決策はトリアージャーパターンです：

• Haikuエージェントが狭いタスクを処理：障害がすでに追跡されているかどうかを判断します。既知のエラーメッセージに対して完全一致とセマンティック検索（pgvector）を使用します。operator does not exist bigint character varyingとmigration type mismatch on installation_idのような異なる文字列でも同じ根本原因である場合があり、セマンティック検索がそれをキャッチします。
• 疑わしい場合、HaikuはOpus 4.6にエスカレーションします。誤検知はコストが少なく、見逃しは実際のバグを見逃すことになります。
• 5件中4件の障害はOpusに到達しません。トリアージャーの一致は完全な調査よりも約25倍低コストです。

コンテキストをプッシュするのではなく、エージェントに引っ張らせる

20万行以上のログをプロンプトに詰め込む代わりに、エージェントはClickHouseへのSQLインターフェースを取得します。生テーブル（github_logs、ログ行ごとに1行）と、事前集計データを持つマテリアライズドビュー（ワークフロー別の障害率、ジョブのタイミング、結果数）があります。ほとんどの調査はビューから始めて絞り込み、その後生ログにドリルダウンします。クエリが返す行が多すぎる場合、システムは切り詰めてより具体的なビューを提案します。ログがまだ取り込まれていない場合、エージェントはGitHub CLIにフォールバックします。

高価なモデルが計画し、安価なモデルが実行する

Opusは仮説を立て、Haikuサブエージェントを起動します（深さは1レベルまでに制限され、無制限のファンアウトはありません）。各サブエージェントはOpusからのプロンプトを受け取ります：何をどのように検索するか正確に。実際の例：

3つのStorybook CIジョブが同じコミットで失敗し、pnpm installでクラッシュしました。Opusはサブエージェントを派遣してそのステップのエラーメッセージを取得させました。ClickHouseにはまだログがなかったため、サブエージェントはGitHub CLIを使用し、gyp ERR! not found: make — [email protected]がコンパイルできなかった理由はmakeがランナーになかったため、と返しました。Opusはその後、ClickHouseで14日間の障害傾向をクエリし、変曲点を見つけてエスカレーションしました。サブエージェントのプロンプトは明示的です："この実行のCIログを取得してください。pnpm installステップの正確なエラーメッセージ、完全なエラー出力、特に最後の50〜100行を返してください。"

この記事の対象読者

CIデバッグや、コンテキストサイズとコストが問題となるタスクのためにLLM駆動エージェントを構築しているチーム。