Home
Blog
OpenClawのようなAIエージェントがトークンを使い果たす理由とコスト削減方法

OpenClawのようなAIエージェントがトークンを使い果たす理由とコスト削減方法

Engineering

February 28, 2026

Min Yin

OpenClaw（旧ClawdbotとMoltbot）を使ったことがある人なら、このAIエージェントの優秀さはすでにご存知だろう。高速で、ローカルで、柔軟性があり、Slack、Discord、コードベース、その他あなたが接続したもの全てにおいて驚くほど複雑なワークフローを実行することができる。しかし、本格的に使い始めると、トークンの使用量が増え始めるという1つのパターンがすぐに浮かび上がってくる。

これは特にOpenClawのせいではなく、今日のほとんどのAIエージェントの振る舞いなのだ。ファイルを検索する、タスクを計画する、メモを書く、ツールを実行する、フォローアップの質問をする、などなど、ほとんどすべてのことにLLMコールをトリガーする。そして、トークンはこれらの呼び出しの共通通貨であるため、すべてのアクションにはコストがかかる。

そのコストがどこから来るのかを理解するために、2つの大きな貢献者のフードの下を見る必要がある：

検索：不適切に構築された検索は、ファイル全体、ログ、メッセージ、コード領域など、モデルが実際には必要としない膨大なコンテキストのペイロードを引き込む。
メモリ：重要でない情報を保存することで、エージェントは将来の呼び出し時に再読み込みと再処理を強いられ、トークンの使用量が長期的に増大する。

この2つの問題は、能力を向上させることなく、運用コストを静かに増加させる。

OpenClawのようなAIエージェントが実際にどのように検索を行うか - そしてそれがトークンを消費する理由

エージェントがコードベースやドキュメント・ライブラリから情報を必要とする場合、通常はプロジェクト全体のCtrl+Fに相当する操作を行います。一致するすべての行が、ランク付けもフィルタリングも優先順位付けもされずに返されます。Claude Codeはripgrepをベースにした専用のGrepツールでこれを実装しています。OpenClawには組み込みのコードベース検索ツールはありませんが、そのexecツールにより、基礎となるモデルはどんなコマンドでも実行することができ、ロードされたスキルはrgのようなツールを使うようにエージェントを導くことができます。どちらの場合も、コードベース検索はキーワードのマッチをランク付けもフィルターもせずに返します。

このブルートフォース・アプローチは、小規模なプロジェクトでは問題なく機能する。しかし、リポジトリが大きくなるにつれて、その代償は大きくなる。無関係なマッチがLLMのコンテキスト・ウィンドウに山積みになり、モデルは実際には必要のない何千ものトークンを読み込んで処理することを余儀なくされる。1回のスコープなし検索で、完全なファイル、巨大なコメントブロック、キーワードは共有しているが根本的な意図は共有していないログが引きずり込まれるかもしれない。このパターンを長いデバッグ・セッションやリサーチ・セッションで繰り返すと、あっという間に肥大化してしまう。

OpenClawもClaude Codeも、この肥大化を管理しようとしている。一方、Claude Codeはファイル読み込み出力を制限し、コンテキストのコンパクションをサポートする。これらの緩和策は機能するが、それは肥大化したクエリがすでに実行された後である。ランク付けされていない検索結果はまだトークンを消費しており、あなたはまだトークンの代金を支払っている。コンテキスト管理は、無駄を発生させた元の呼び出しではなく、将来のターンを支援する。

AIエージェントのメモリーの仕組みとトークンを消費する理由

トークンのオーバーヘッドの原因は検索だけではない。エージェントがメモリから呼び出すコンテキストの断片はすべて、LLMのコンテキスト・ウィンドウにも読み込まれなければならず、これにもトークンのコストがかかる。

今日ほとんどのエージェントが依存しているLLM APIはステートレスです：AnthropicのMessages APIはリクエストごとに完全な会話履歴を必要とし、OpenAIのChat Completions APIも同じように動作する。OpenAIの新しいステートフルなResponses APIでさえ、会話の状態をサーバーサイドで管理するため、すべてのコールで完全なコンテキストウィンドウを要求します。コンテキストにロードされたメモリは、それがそこに到達する方法に関係なく、トークンの費用がかかります。

これを回避するために、エージェントフレームワークは、ディスク上のファイルにメモを書き込み、エージェントがそれらを必要とするときにコンテキストウィンドウに関連するメモをロードバックする。例えば、OpenClaw はキュレーションされたノートを MEMORY.md に保存し、日々のログをタイムスタンプ付きの Markdown ファイルに追加し、ハイブリッド BM25 とベクトル検索でインデックスを作成し、エージェントが必要に応じて関連するコンテキストを呼び出せるようにしています。

OpenClawのメモリデザインはうまく機能していますが、OpenClawのエコシステム全体（ゲートウェイプロセス、メッセージングプラットフォーム接続、その他のスタック）が必要です。Claude Code のメモリも同様で、CLI と結びついている。これらのプラットフォーム以外でカスタムエージェントを構築する場合は、スタンドアロンのソリューションが必要です。次のセクションでは、両方の問題に対して利用可能なツールについて説明します。

OpenClaw がトークンを消費するのを止める方法

OpenClaw が消費するトークンの数を減らしたい場合、引けるレバーは2つあります。

1つ目は、より良い検索です。grepスタイルのキーワードダンプを、ランク付けされた関連性主導の検索ツールに置き換えることで、モデルが実際に重要な情報だけを見るようにします。
もう1つは、より良いメモリだ。不透明でフレームワークに依存したストレージから、理解し、検査し、制御できるストレージに移行することだ。

より良い検索でgrepを置き換える：index1、QMD、milvus

多くのAIコーディングエージェントは、grepやripgrepを使ってコードベースを検索する。Claude Codeには、ripgrepをベースに構築された専用のGrepツールがある。OpenClawはコードベース検索ツールを内蔵していないが、そのexecツールは基礎となるモデルに任意のコマンドを実行させることができ、ripgrepやQMDのようなスキルをエージェントの検索方法をガイドするためにロードすることができる。検索に特化したスキルがなければ、エージェントは基礎となるモデルが選択するどんなアプローチにも戻ってしまう。ランク付けされた検索がなければ、キーワードのマッチはフィルタリングされずにコンテキストウィンドウに入る。

これは、プロジェクトが十分に小さく、すべてのマッチがコンテキストウィンドウに快適に収まる場合に機能する。問題は、コードベースやドキュメントライブラリが大きくなり、キーワードが何十、何百ものヒットを返し、エージェントがそれらをすべてプロンプトに読み込まなければならなくなったときに始まります。そのような規模になると、一致度でフィルタリングするだけでなく、関連性でランク付けされた結果が必要になる。

標準的な解決策は、2つの補完的なランキング方法を組み合わせたハイブリッド検索である：

BM25は、与えられた文書にどれだけ頻繁に、どれだけユニークに用語が出現するかによって、各結果をスコアリングする。BM25は、与えられた文書にどれだけの頻度で、どれだけのユニークな用語が登場するかによって、各検索結果をスコア化する。「認証」に15回言及したフォーカスされたファイルは、1回言及した広大なファイルよりも上位にランクされる。
ベクトル検索は、テキストを意味の数値表現に変換するので、「認証」は、キーワードを共有していなくても、「ログインフロー」や「セッション管理」と一致することがある。

どちらの方法も単独では十分ではない：BM25は言い換えられた用語を見逃し、ベクトル検索はエラーコードのような正確な用語を見逃す。両方を組み合わせ、フュージョン・アルゴリズムによってランク付けされたリストをマージすることで、両方のギャップをカバーすることができる。

以下のツールは、異なるスケールでこのパターンを実装している。index1、QMD、milvusは、それぞれ容量を増やしながらハイブリッド検索を追加している。

index1: シングルマシンでの高速ハイブリッド検索

index1は、ハイブリッド検索を単一のSQLiteデータベースファイルにパッケージ化するCLIツールである。FTS5がBM25を処理し、sqlite-vecがベクトル類似度を処理し、RRFがランク付けされたリストを融合する。エンベッディングはOllamaによってローカルに生成されるので、あなたのマシンからは何も出ない。

index1は行数ではなく構造でコードをチャンクする：Markdownファイルは見出しによって、PythonファイルはASTによって、JavaScriptとTypeScriptは正規表現パターンによって分割される。つまり、検索結果は、ブロックの途中で切れてしまうような恣意的な行範囲ではなく、関数全体やドキュメントセクション全体のようなまとまった単位を返します。レスポンスタイムはハイブリッドクエリで40～180ms。Ollamaがない場合、BM25-onlyに戻るが、これはすべてのマッチをコンテキストウィンドウにダンプするのではなく、結果をランク付けする。

index1には、教訓、バグの根本原因、アーキテクチャの決定を保存するためのエピソード記憶モジュールも含まれている。これらの記憶は、独立したファイルとしてではなく、コードインデックスと同じSQLiteデータベース内に格納される。

注：index1は初期段階のプロジェクトです（2026年2月現在、星0つ、コミット数4）。コミットする前に、自分のコードベースと照らし合わせて評価してください。

最適な人: 一人の開発者や小規模チームで、コードベースが一台のマシンに収まるような場合。
同じインデックスに複数ユーザーでアクセスする必要がある場合や、SQLiteファイル1つで快適に扱える範囲を超えるデータがある場合。

QMD: ローカルLLM再順位付けによる高精度化

Shopifyの創設者であるTobi Lütkeによって構築されたQMD（Query Markup Documents）は、第3のステージを追加します：LLM再ランキングだ。BM25とベクトル検索がそれぞれ候補を返した後、ローカルの言語モデルが上位の結果を再読み込みし、クエリとの実際の関連性で並び替える。これにより、キーワードと意味的一致の両方が、もっともらしいが間違った結果を返すケースを捕らえることができる。

QMDは、エンベッディングモデル(embeddinggemma-300M)、クロスエンコーダーリランカー(Qwen3-Reranker-0.6B)、クエリ展開モデル(qmd-query-expansion-1.7B)の3つのGGUFモデル(合計約2GB)を使って、あなたのマシン上で動作します。3つとも初回実行時に自動的にダウンロードされる。クラウドAPI呼び出しもAPIキーもない。

トレードオフはコールドスタート時間です：ディスクから3つのモデルをロードするのにおよそ15秒から16秒かかります。QMDは永続サーバーモード(qmd mcp)をサポートしており、リクエスト間でモデルをメモリに保持し、繰り返しクエリーを行った場合のコールドスタートのペナルティを排除する。

最適な環境：データがマシンを離れることができず、レスポンスタイムよりも検索精度が重要なプライバシークリティカルな環境。
秒以下のレスポンスが必要な場合、チームで共有する場合、データセットがシングルマシンの容量を超える場合。

Milvus：チームやエンタープライズ規模でのハイブリッド検索

上記のシングルマシンツールは、個々の開発者には有効ですが、複数の人やエージェントが同じナレッジベースにアクセスする必要がある場合には、限界に達します。

Milvusは、そのような次の段階のために構築されたオープンソースのベクターデータベースである：分散、マルチユーザー、数十億のベクターを扱うことができる。

Milvus 2.5から利用可能で、2.6では大幅に高速化された。生テキストを提供すると、Milvusはtantivyをベースに構築されたアナライザを使って内部的にトークン化し、その結果をスパースベクトルに変換します。

BM25表現はすでに保存されているため、検索はその場でスコアを再計算する必要がない。これらの疎なベクトルは、同じコレクション内で密なベクトル（セマンティック埋め込み）と共存します。クエリ時には、Milvusがすぐに提供するRRFRankerのようなランカーを使って両方のシグナルを融合させる。index1やQMDと同じハイブリッド検索パターンだが、水平方向にスケールするインフラ上で動作する。

Milvusはまた、マルチテナント分離（チーム毎に独立したデータベースやコレクション）、自動フェイルオーバーによるデータレプリケーション、コスト効率に優れたストレージのためのホット/コールドデータティアリングなど、シングルマシンのツールにはない機能を提供します。エージェントの場合、これは複数の開発者や複数のエージェントインスタンスが、お互いのデータを踏むことなく、同じナレッジベースを同時に照会できることを意味します。

複数の開発者やエージェントがナレッジベースを共有する場合、大規模または急成長するドキュメントセット、レプリケーション、フェイルオーバー、アクセス制御が必要な本番環境に最適です。

まとめると

ツール	ステージ	デプロイメント	移行シグナル
クロード・ネイティブGrep	プロトタイピング	ビルトイン、ゼロセットアップ	請求書の増加やクエリの速度低下
インデックス1	シングルマシン（スピード）	ローカルSQLite + Ollama	マルチユーザーアクセスが必要、またはデータが1台のマシンを超える
QMD	シングルマシン（精度）	3つのローカルGGUFモデル	チーム共有インデックスが必要
Milvus	チームまたはプロダクション	分散クラスタ	大規模なドキュメントセットまたはマルチテナント要件

memsearchで永続的で編集可能なメモリを与えることでAIエージェントのトークンコストを削減

検索の最適化はクエリごとのトークンの無駄を減らしますが、エージェントがセッション間で保持するものについては役に立ちません。

エージェントがメモリから呼び出すコンテキストのすべてのピースは、プロンプトにロードされなければならない。問題は、メモリーを保存するかどうかではなく、どのように保存するかだ。保存方法によって、エージェントが記憶しているものを見ることができるかどうか、間違っているときに修正できるかどうか、ツールを変更したときにそれを持ち出せるかどうかが決まります。

ほとんどのフレームワークは、この3つの点で失敗している。Mem0とZepはすべてをベクター・データベースに保存する：

不透明。APIに問い合わせなければ、エージェントが何を記憶しているのか見ることができない。
編集が難しい。メモリの修正や削除は、ファイルを開くのではなく、APIコールを意味する。
ロックされる。フレームワークの切り替えは、データのエクスポート、変換、再インポートを意味する。

OpenClawは異なるアプローチをとります。すべてのメモリはディスク上のプレーンなMarkdownファイルに保存されます。エージェントは日々のログを自動的に書き込み、人間はどのメモリファイルも直接開いて編集することができます。これは3つの問題をすべて解決します：メモリは読み取り可能で、編集可能で、設計上ポータブルです。

トレードオフはデプロイのオーバーヘッドだ。OpenClaw のメモリを実行するということは、OpenClaw のエコシステム全体を実行するということです：ゲートウェイ・プロセス、メッセージング・プラットフォーム接続、その他のスタック。すでにOpenClawを使用しているチームにとっては、それは問題ありません。memsearchはこのギャップを埋めるために作られました：OpenClawのMarkdownファーストのメモリパターンを抽出し、どのエージェントでも動作するスタンドアロンライブラリにしました。

memsearchはZilliz（milvusの開発チーム）によって作られ、Markdownファイルを単一の真実のソースとして扱います。MEMORY.mdは、あなたが手で書いた長期的な事実や決定を保持する。デイリーログ（2026-02-26.md）はセッションサマリーから自動的に生成される。Milvusに保存されているベクターインデックスは、いつでもMarkdownから再構築できる派生レイヤーである。

実際には、テキストエディタで任意のメモリファイルを開き、エージェントが知っていることを正確に読み取り、変更することができるということです。ファイルを保存すると、memsearchのファイルウォッチャーが変更を検知し、自動的にインデックスを再作成する。Gitでメモリを管理したり、プルリクエストでAIが生成したメモリをレビューしたり、フォルダをコピーして新しいマシンに移動したりすることができる。Milvusのインデックスが失われた場合は、ファイルからインデックスを再構築します。ファイルが危険にさらされることはない。

memsearchは、前述のハイブリッド検索パターンを採用している。見出し構造と段落境界によって分割されたチャンク、BM25 + ベクトル検索、ログが大きくなった場合に古い記憶を要約するLLMを搭載したコンパクトコマンドなどだ。

エージェントが何を記憶しているかを完全に可視化したいチーム、メモリのバージョン管理が必要なチーム、単一のエージェントフレームワークに縛られないメモリシステムが必要なチームに最適です。

まとめると

能力	Mem0 / Zep	メムサーチ
真実のソース	ベクターデータベース（唯一のデータソース）	Markdownファイル（プライマリ） + Milvus（インデックス）
透明性	ブラックボックス、検査にはAPIが必要	任意の.mdファイルを開いて読む
編集性	APIコールによる修正	テキストエディタで直接編集可能。
バージョン管理	別途監査ロギングが必要	Gitがネイティブに動作
移行コスト	エクスポート→フォーマット変換→再インポート	Markdownフォルダをコピー
人間とAIのコラボレーション	AIが書き、人間が観察する	人間は編集、補足、レビューが可能

どの設定があなたの規模に合うか

シナリオ	検索	メモリー	次に進むタイミング
初期のプロトタイプ	Grep（組み込み）	-	課金額が上がるか、クエリが遅くなる
単一の開発者、検索のみ	index1(スピード) またはQMD(精度)	-	マルチユーザーアクセスが必要、またはデータが1台のマシンを超える
シングル開発者、両方	インデックス1	memsearch	マルチユーザアクセスが必要、またはデータが1台のマシンを超える
チームまたはプロダクション、両方	milvus	memsearch	-
迅速な統合、メモリのみ	-	Mem0またはZep	メモリの検査、編集、移行が必要

結論

AIエージェントの常時稼働に伴うトークンのコストは避けられないものではない。このガイドでは、より良いツールが無駄を省くことができる2つの領域、検索とメモリを取り上げた。

Grepは小規模では機能するが、コードベースが大きくなるにつれて、ランク付けされていないキーワードのマッチは、モデルが必要としなかったコンテンツでコンテキストウィンドウを溢れさせる。index1と QMDは、BM25キーワードスコアリングとベクトル検索を組み合わせ、最も関連性の高い結果のみを返すことで、1台のマシンでこれを解決する。チーム、マルチエージェントのセットアップ、またはプロダクションワークロードのために、Milvusは、水平方向にスケールするインフラストラクチャ上で同じハイブリッド検索パターンを提供する。

memsearchは異なるアプローチを取る。メモリは、あなたが読み、編集し、Gitでバージョン管理できるプレーンなMarkdownファイルに保存される。milvusは、それらのファイルからいつでも再構築できる派生インデックスとして機能する。あなたはエージェントが何を知っているかをコントロールし続けることができる。

memsearchと Milvusはどちらもオープンソースです。私たちはmemsearchを積極的に開発しており、実運用で使用している方からのフィードバックをお待ちしています。issueを発行したり、PRを提出したり、何がうまくいっていて何がうまくいっていないかを教えてください。

このガイドで言及しているプロジェクト