Ace Sidecar：ローカルAIコーディングの効率最適化

AI コーディングエージェントは、多くのエンジニアリング組織にとって、最も観測が難しく、かつ高額な運用コストとなっています。毎月の API 請求額は分かっても、どのセッションがその費用を生んだのか、どれだけが20回目のコンテキスト再読込みだったのか、承認待ちでエージェントがどれだけ停止していたのか、ロードマップ上の最適化が本当に効果があるのかは分かりません。Ace Fleet チームは5週間かけて、1人の開発者の Claude Code セッションをリクエスト単位で測定し、42億のプロンプトトークン、定価で3,035ドル、その90.5%が既に送信済みの入力だったことを公表しました。さらに、理論上は大きな効果が見込めたいくつかのレバーが、測定によって崩壊することも示しました。

こうした測定のために構築したツールが、現在公開されています。ACE sidecar は、コーディングエージェントとモデルプロバイダーの間に位置するローカルリバースプロキシです。トラフィックをそのまま中継し、各リクエストに価格を付け、ディスク上の既存トランスクリプトを読み取り、127.0.0.1 のダッシュボードに全体像を表示します。アカウント不要、アップロードなし、作業方法の変更も環境変数1つだけです。

ダッシュボードには、入出力トークン、リクエスト数、ユーザーへのハンドバック数、ターンあたりのコスト、セッションあたりのコスト、セッションあたりのコミット数、コミットあたりのトークン数など、フリート全体を表す11の数値が表示されます。下の分布表は特に注目されます。25パーセンタイルのリクエストは、すでに10万トークン以上のコンテキストを持っています。安価な四分位は存在せず、そのためリクエストごとのペイロード調整は、コンテキストサイズの削減に常に劣ります。コミットの帰属は時間ウィンドウベースであり、セッションのウィンドウ内に落ちたコミットが、必ずしもそのセッションで生成されたとは限らないと明記されています。

作業量の形状セクションでは、日次トークン、日次コミット、アイドル日数を表示します。このコーパスでは、前日比の中央値が −12.2%、四分位範囲が −48% から +76% で、連続する日の間でボリュームが半分になったり倍になったりします。このグラフは、変化率に基づくアラートや予算が常に発火して無意味になることを示しており、期間予算に対する累積上限だけがこの形状に耐えられます。

コストセクションには、コスト、キャッシュ削減額、キャッシュヒット率、ピークコンテキスト、さらにレートカードと実際の計算式が含まれます。各レートはバージョン管理されたカタログから読み取られ、ベンダーの価格ページと確認日へのリンクが付いています。人々が通常気づくのは、キャッシュ削減額が請求額よりも大きい（このコーパスでは6.1倍）こと、そしてその削減はプロバイダーがすでに実現したものであり、ダッシュボードはそれを自社の功績とせずに表示していることです。また、キャッシュ読み取りがプロンプト量の約98%を占めており、これがページの残りの議論の中心となっています。

最適化評価セクションは2つのスコアカードに分かれています。企業はドル支出の最小化を目指し、会計上のレバーが有効です。ユーザーはトークン上限の下で余裕を最大化することを目指し、会計上のレバーはトークンを減らさず価格を変換するだけなので除外されます。各レバーのテーブルにはリスク列があり、その順序は心地よいものではありません。このコーパスで最大のレバー（ttl_keepalive、コストの6.4%）はトークンを1つも削減せず、実際にトークンを削減するレバーは小さいものです。シミュレーションされたすべての項目には SIMULATED のバッジが付けられています。

時間の側面も重要です。ウォールクロック時間の87.7%はアイドル状態で、そのうち233.8時間（204回、各約69分）は、エージェントが保留中のツール呼び出しを保持していました。ダッシュボードはこれをライブアラートとして提示しますが、分類器を必要としないため、誤ってコストがかかることはありません。これは「節約」ではなく「上限」とラベル付けされており、トランスクリプトは、より早く戻ってきた人間と、そもそも離れていた人間を区別できないため、上限を報告しています。

ACE sidecar は、プロンプト、パス、コード、セッション識別子、テレメトリなど、一切アップロードしません。~/.claude/projects を読み取り、ローカルの SQLite ファイルに書き込みます。アカウントも、独自の API キーも、既存のモデルプロバイダー以外のネットワーク宛先もありません。トラフィックを変更しないため、このリリースは測定のみで、リクエストをそのまま中継し、ヘルスエンドポイントで "levers": [] を報告します。すべての最適化レバーは後のフェーズで提供され、実行前にシャドウモードを経ます。また、認証情報を保持せず、ace up --no-key は何も保存せず、呼び出し元が送信したものを中継するだけで、ループバックにバインドし、プロキシヘッダーを拒否します。プロバイダーの削減効果を自社のものと主張せず、プロンプトキャッシュによる6.1倍の削減は表示・ラベル付けされますが、スコアカードには含まれません。

ツール呼び出しの自動承認も行いません。構造的にサイドカーがそれを実行できないとチームは結論付けました。権限決定は API を通過せず、モデルが tool_use ブロックを生成し、クライアントがローカルでプロンプトを表示するかどうかを決定するからです。/v1/messages 上のプロキシはそのループの中にありません。Claude Code の自動モードには自動承認機能がすでにありますが、何を承認し、何をブロックし、何を節約したかを報告しないため、測定が欠けています。時間セクションはそのギャップを埋めます。

実行方法は、uv pip install -e . と ace up --no-key の2つのコマンドと、1つの環境変数です。バナーには、ACE sidecar → https://api.anthropic.com、auth: loopback-trust、credential: caller-supplied、levers: none (Phase 0) と表示されます。ANTHROPIC_BASE_URL=http://127.0.0.1:8787 を設定し、eval "$(ace env)" を実行してから claude を起動します。ダッシュボードは即座に履歴データで埋まり、既存のトランスクリプトを読み取るため、サイドカーが最初のリクエストを中継する前に、フリートメトリクス、支出、時間予算が表示されます。GET /api/report は、スクラブされた共有可能な JSON サマリーを返します。これは集計のみで、セッション詳細、プロンプト、パス、識別子を含みません。エージェントのコストを尋ねられたときに、プラットフォームリーダーに送るものです。

ロードマップは順序付けられており、最後の項目まですべて読み取り専用です。1. セッション時間分解（出荷済み）、2. 承認待ち検出とアラーム（出荷済み、233.8時間、分類器不要）、3. シャドウモードでのターンごとのリスク着色、4. 現在分類器が読めない呼び出しの44.5%を対象とするシェルセグメントパーサー、5. 決定論的な許可リストルールジェネレーター、6. コンテキスト枯渇予測とローカルチェックポイント、7. Bash 出力の先頭と末尾を保持するトランケーション（コストの約1.7%、低リスク）。アイテム6は、コーパスによって考えが変わった点です。162のセッションでレート制限エラーは3回だけであり、実際のイベントはコンテキスト枯渇でした。自動圧縮はインラインで処理しますが、圧縮による有損失のサマリーはセッションとともに消えます。ディスク上の再開ブリーフは生き残ります。アイテム7は、診断を除外し、先頭と末尾を保持することで、Bash 出力の価値の90%が sed/cat ダンプ、grep ロールアップ、git 差分に由来することを分析で示し、ほぼゼロリスクで価値を得られます。

一方、最初に実装する予定だった「重複ファイル読み取りの排除」は、36日間で0.33ドル分の価値しかなく、97.6%の「再読み取り」が異なる行範囲を要求しており、実際には重複ではなかったため、破棄されました。この事例は、オプティマイザーの前に測定器が存在すべき理由を示しています。サイドカーは現在 Claude Code で動作し、完全にローカルで動作し、アップロードはゼロです。ベータ版はバッチで開放されており、チームが最も望むのは2つ目のコーパスです。現在のすべての発見は、1人の開発者が36日間にわたって使用したものに基づいています。コスト構造は一般化できるはずですが、数値は単一フリートのものであり、実際にどこで破綻するかを知りたいと考えています。興味のあるユーザーはメールアドレスを残してベータ版を入手するか、[email protected] までご連絡ください。