先月、私が構築しているコーディングエージェントは、入力と出力の合計で 130 億トークンを処理し、キャッシュヒット率は 97.24%、実効コストは約 100 万トークンあたり 0.04 ブラジルレアルでした。
この数字を話すと、最初の反応はたいてい疑念です。それは健全な反応です。コストは、企業が自律エージェントを断念する最大の理由です。パイロットは機能するが、請求書が届き、プロジェクトは頓挫する。そこで、この記事では、これらの数字がどのように実現しているかについて説明します。単一の秘策があるわけではなく、すべての出入りするトークンが圧縮され、ルーティングされ、測定されるアーキテクチャがあります。
これが Velua Code です。私が立ち上げることにした新しいスタートアップ Velua AI (https://velua.aihttps://velua.ai/)) で構築しているエージェントです。アーキテクチャの前に、そのテーゼを述べます。
テーゼ：3 つの問題を同時に解決する
コーディングエージェントは 3 つの箇所で機能不全に陥り、そのうちの 1 つだけを解決しても不十分です。
コスト。 自律エージェントは、どの CFO も恐れる規模でトークンを消費します。各イテレーションが高価であれば、誰もエージェントにイテレーションをさせません。そして、イテレーションしないエージェントは、実際には何も解決しません。
コンテキスト。 コンテキストウィンドウは有限で高価です。典型的な実装では、ファイル全体と grep 結果でプロンプトを埋め尽くし、毎回の呼び出しで何千もの無関係なトークンに対して支払いを行います。
メモリ。 すべてのセッションはゼロから始まります。エージェントは火曜日に、月曜日にすでに学習したことを再発見し、その再発見に対して（トークンとエラーで）代償を払います。
これら 3 つは相互に影響を与え合います。コンテキストの肥大化はコストを増大させ、メモリの欠如はコンテキストを肥大化させます。だからこそ、Velua Code はこれら 3 つすべてに同時に取り組みます。
コスト：ソース圧縮 + アクティブルーティング
最初のアーキテクチャ上の決定：コンテキストを最終段階ではなく、ソースで圧縮する。すべてのツール出力（ファイル読み取り、検索結果、ビルドログ）は、セッション履歴に入る前に圧縮パイプラインを通過します。中核は、開発者のマシンまたはエージェントのコンテナ内で、ローカルで ONNX 上で動作する独自の圧縮モデルです。圧縮のためにネットワーク呼び出しは発生しません。節約はトークンを消費しません。
その周辺では、より単純なレイヤーが主要な処理を行います。読み取りの重複排除（エージェントが同じファイルを再読み取りしたか？古いバージョンはコンテキストから削除）、構造化 JSON 圧縮、コード本体のシグネチャ維持部分の省略、そしてコンテキストが大きくなるにつれて圧縮を強化する適応型しきい値です。すべてはターゲットモデルの実際のトークナイザーで測定されます。節約は推定値ではなく、実際のトークンでカウントされます。
そして、やらないことについての決定もあります。実行時にシステムプロンプトに触れることは決してありません。安定したプロンプトこそが 97.24% のキャッシュヒット率を支えており、キャッシュヒットは存在する中で最も安価なコストレバレッジです。なぜなら、キャッシュされたトークンのコストはフルトークンのごく一部だからです。
2 番目の決定：エージェントはモデルを選択しない。ローカル分類器が各タスクをカテゴリと複雑度で事前分類し、Velua Gateway（50 以上のモデルをリアルタイムの価格とパフォーマンスで監視）が、ガードレールの適用と RAG による拡張に加えて、必要な範囲内で最も能力の高いモデルにルーティングします。変数の名前変更にフロンティアモデルは必要ありません。スキーママイグレーションの設計には必要です。アクティブルーティングにより、ほとんどの呼び出しはより小さなモデルに送られ、複雑さが要求する場合にのみ高価なモデルが使用されます。
また、ゲートウェイは各リクエストの実際のコストを測定します。これにより、プロダクションのエージェントにとって譲れないと考えていること、つまり停止条件としての予算が可能になります。自律ループは、期待ではなく、通貨単位のコスト上限を持って実行されます。
ソース圧縮、高いキャッシュヒット率、小規模モデル間のルーティングという組み合わせが、100 万トークンあたり 0.04 ブラジルレアルという数字を生み出しています。これらの 3 つの要素のうち、どれか 1 つだけでは、到底この数字に近づくことはできません。
コンテキスト：grep の代わりにグラフ
エージェントがコードベースを「理解する」標準的な方法は grep とファイル読み取りですが、これは高価で目が見えません。Velua Code はコード知識グラフを維持します。関数、クラス、ルート、およびそれらの間の関係（誰が誰を呼び出すか、誰が何を実装するか）を含みます。
これにより、ループの両端が変わります。入力側では、エージェントはファイルをプロンプトにダンプする代わりに、グラフを参照して（プロジェクトのアーキテクチャビューとタスクに関連するノード）コンパクトなコンテキストパッケージを組み立てます。出力側では、検証が変わります。エージェントが関数を変更すると、グラフは影響を受ける呼び出し箇所を正確にリストアップし、レビューアエージェント（クリーンなコンテキストを持ち、コードを書いた人のバイアスがない）が、テスト、lint、ビルドの実行に加えて、それらの各箇所をチェックします。「processOrder のシグネチャを変更しました。7 箇所がそれを呼び出しています」という種類の検証は、grep では提供できません。
メモリ：学習するループ
システムを完成させるピースです。検証された各イテレーションの終わりに、エージェントはエンジニアリング上の決定事項を記録します。何が決定されたか、なぜか、どのような代替案が検討されたか、何が失敗したかです。そして、各決定事項は、それが説明するコードノードに、グラフ自体の中でリンクされます。
次のイテレーションでは、コンテキスト収集フェーズがこれらの決定事項を取得します。すでに失敗したアプローチも含まれ、それらを繰り返さないようにします。ループはタスクを繰り返す実行器ではなくなり、コードベースに関する知識を蓄積するシステムになります。これはまた、存在する中で最良のコスト償却手段でもあります。安価なメモリが高価な再発見を置き換えます。
したがって、完全なループは次のようになります。コンテキストの収集（グラフ + メモリ + RAG）、問題のサイズに適したモデルでの計画、サブエージェントでの実行、クリーンなコンテキストのレビューアとグラフ認識による検証、決定事項の記録による学習、そしてコスト上限の下での繰り返し。これは標準的なエージェントループであり、各汎用フェーズを独自の能力に置き換えたものです。
なぜ最初のクライアントは私たち自身なのか
プロダクト戦略は意図的に直感に反しています。いかなるクライアントにも販売する前に、Velua Code はSIGE Cloud 社内で実行されます。真のドッグフーディングです。本番稼働中の ERP で、実際のチームが実際のコード上でエージェントを日々運用しています。
この社内利用こそが 130 億トークンを生み出し、プロダクトを形成しているものです。本番環境の自律エージェントは、どのベンチマークも明らかにしない問題を露呈します。権限、累積コスト、停止するタスク、腐敗するコンテキストなどです。私は、その痛みが私たち自身のものになる場所で成熟させることを好みます。
今後の展開：企業向け統合メモリ
現在、決定メモリはプロジェクトごとに存在します。次のステップは、私が最も興奮していることです。それを企業向けの統合エンジニアリングメモリレイヤーに引き上げることです。
チーム A のエージェントによって記録された決定事項「Y のために X に移行した。W が壊れたため Z は回避した」を、チーム B のエージェントや、これらのエージェントを操作する人間の開発者が、アクセス制御、来歴、監査機能付きで取得可能にすることを想像してみてください。「なぜこのコードはこのようになっているのか？」という質問に、コードにリンクされた元の決定事項で、組織内の誰でも、あるいは任意のエージェントでも答えられるようになります。オンボーディングの迅速化、チーム間の一貫性、そして企業のエンジニアリング知識がもはや人々の頭の中だけに存在しなくなります。
ゲートウェイによって提供されるこのメモリは、インフラストラクチャとなります。企業内の任意のエージェント、任意のツールが、蓄積された学習を継承します。
自律エージェントはコモディティ化されるでしょう。しかし、彼らがあなたのシステムについて蓄積する知識は、コモディティ化されません。
それが私たちの賭けです。
もしあなたが本番環境でエージェントを構築している、あるいはコンテキストコストに頭を悩ませているなら、私の DM は開いています。
