「すべてのAPIコールの73%が固定オーバーヘッドだった」— Xユーザー @Bichev が2026年4月22日に公開した、Hermes Agent でトークン消費をプロファイリングした検証結果は、AIエージェント運用のコスト最適化に取り組むエンジニア・経営者にとって衝撃的な数字でした。本記事では、株式会社Fyveの法人視点で、この事例の意味・固定オーバーヘッドが生まれる仕組み・そして実務でどう減らすかまで分解して解説します。

事例の概要 — 「73%は固定オーバーヘッド」が突きつけた現実

本記事で扱う事例は、Hermes Agent のオープンソース・コミュニティで広く共有された一次情報です。@Bichev は Hermes Agent のトークン消費を1コールごとにプロファイリングするツールを構築し、その分解結果を公開しました。

発信原文は次の通りです。

"73% of every API call is fixed overhead"

— @Bichev, 2026-04-22

この一文の意味するところは深刻です。エンジニアが書いたプロンプトの内容・指示・コンテキストといった「本当に必要な情報」は、実は1回のAPIコールの中で 27%程度しか占めていない ということです。残りの73%は、システムプロンプト・スキル定義・メモリ参照・ツール定義のスキーマなど、毎回ほぼ同じ内容が繰り返し送信されている「固定費」だったのです。

仮に月100万トークン使う運用であれば、そのうち約73万トークン分が「実質、毎回同じものに払い続けている料金」だった、ということになります。これは Claude API・OpenAI API の高単価モデルを使う場合、無視できない金額差につながります。

なぜ73%もの固定オーバーヘッドが発生するのか

「無駄が多いだけでは？」と捉えるのは早計です。固定オーバーヘッドが大きくなるのには、AIエージェントの設計上の必然的な理由があります。私たちが実務でAIエージェントを設計するうえで、まずこの構造を理解しておく必要があります。

固定オーバーヘッドの中身

1回のAPIコールで「固定費」として送られている内容は、おおむね次のカテゴリに分かれます。

• システムプロンプト: エージェントの性格・行動指針・出力フォーマット指示。長いと1万トークンを超えることもある
• ツール定義のスキーマ: 70以上のビルトインツール＋MCPツールの引数定義。Hermes Agent ではこれが膨大
• スキル定義の参照: 自動生成された再利用スキルのメタデータ
• メモリの抜粋: 3層メモリのうち、現在のタスクに関連しそうな永続記憶のスニペット
• 会話履歴のサマリ: 直近のターンに加えて、過去の意思決定の要約

これらは「毎ターン同じものを送る」性質のため、プロンプト内容が変わってもほぼ同量送信されます。@Bichev のプロファイリング結果は、これら固定費の累積が全体の73%を占めていることを実測で示しました。

プロファイリング手法 — 1コール単位での分解

@Bichev のアプローチは比較的シンプルです。Hermes Agent の API リクエスト送信時のペイロードをフックし、メッセージごとに「役割(role)」と「トークン数」を分解集計するロガーを組み込みました。具体的には次のステップで分解しています。

• ステップ1: APIコールのペイロードを丸ごと保存(system / tools / messages の3区分)
• ステップ2: 各区分のトークン数を tiktoken 相当のトークナイザで計測
• ステップ3: 「直前のコールと内容が同一の部分」を固定オーバーヘッドとしてラベル付け
• ステップ4: タスクごとに集計し、平均値・中央値・分布を可視化

この方法のポイントは 「差分検出」 です。毎回ほぼ同じ内容で送られているテキストブロックを抽出することで、「これは固定費だ」とラベル付けできます。AIエージェントを本格運用するチームであれば、自社のエージェントにも同じプロファイラを組み込めば、ほぼ同じ構造の数字が出てくるはずです。

私たちの解釈 — 「73%」は無駄ではなく、最適化の主戦場

株式会社Fyveとしてこの数字を見ると、まず最初に伝えたいのは 「73%は単なる無駄ではない」 ということです。固定オーバーヘッドの大半は、エージェントが「賢く動くために必要な土台」だからです。システムプロンプトもツール定義もメモリも、削れば動作品質が落ちます。

ただし、「73%という塊が存在する」という事実は、コスト最適化の主戦場がどこかを明確にします。プロンプトを5%短くする努力よりも、固定オーバーヘッドの73%にメスを入れる方が、桁違いに大きいリターンが得られるからです。

Claude Code との比較 — プロンプトキャッシングが効く理由

同じAIエージェント領域で日本国内でも普及している Claude Code は、Anthropic純正のサービスとして プロンプトキャッシング を標準で活用しています。これは固定オーバーヘッドの大部分を「キャッシュヒット」として安価に再利用する仕組みです。Anthropic 公式のドキュメントによれば、キャッシュヒット時のトークン単価は通常の 10% 程度まで下がります。

つまり、固定オーバーヘッドが73%あったとしても、その大半がキャッシュヒットになれば、実質コストは大幅に圧縮されます。@Bichev の数字は「キャッシュが効いていない場合」のフルコストを可視化したと捉えるのが正しい読み方です。

Hermes Agent のように複数の LLM プロバイダを切り替えて使うエージェントでは、プロバイダによってキャッシング対応の有無が異なります。Anthropic 直接 API・OpenAI などはキャッシュ対応していますが、ローカルLLM経由ではキャッシュの恩恵を受けにくい構造です。コスト試算ではこの点を見落とさないことが重要です。

中小企業のAI活用への影響

私たちが中小企業のAI活用顧問として現場に入ると、「ChatGPT は月20ドルだから安い」「Claude も似たような額だろう」という感覚で導入されるケースをよく見ます。しかしAIエージェントを本格的に業務に組み込み始めると、固定オーバーヘッドの累積で月のAPI料金が10倍・20倍に膨らむことは珍しくありません。

逆に言えば、固定オーバーヘッドの構造を理解して設計すれば、同じ業務をはるかに低コストで回せます。@Bichev の73%という数字は、私たちにとって「最適化前の出発点」を示すベンチマークになります。

実務落とし込み — APIコール最適化の4つの具体策

では実際に、固定オーバーヘッドを抑えるために何をすればよいのか。私たちが顧問先で導入を勧めている、効果の大きい順に4つの施策を紹介します。

1. プロンプトキャッシングを最優先で有効化する

最も投資対効果が高いのは、プロンプトキャッシングの活用です。Anthropic Claude API では cache_control ブロックを使って、システムプロンプトとツール定義をキャッシュ対象に指定できます。OpenAI も2024年以降、自動プロンプトキャッシングを段階的に導入しています。

• 対象: システムプロンプト・ツール定義・スキル定義など、コール間で変化しない部分
• 効果: 該当部分のトークン単価が約10%に圧縮される(Anthropic)
• 注意点: キャッシュには5分のTTLがある。短時間で連続呼び出しする場合に効く

固定オーバーヘッドが73%あるエージェントでも、その大半がキャッシュヒットになれば、実コストは元の30〜40%にまで下がる試算になります。

2. バッチング — 1タスク1コールではなく、複数タスクを1コールで処理

固定オーバーヘッドは「コールの回数」に比例します。同じ73%でも、コール数が半分になれば固定コストも半分です。実務では次のような工夫が有効です。

• 類似タスクをまとめて1プロンプトで指示する(例: 10件のメール要約を1回のコールで処理)
• サブタスクへの分割を最小限にする(細かく分けるほど固定費が増える)
• 「1コール完結型」のスキルを優先設計する

これは Hermes Agent のサブエージェント並列実行とトレードオフです。並列化は速度には効きますが、コスト面では固定費を増やします。「速度優先か、コスト優先か」をタスクごとに判断する設計が必要です。

3. ツール定義のスリム化

Hermes Agent は70以上のビルトインツールと、MCP経由で追加される無数のツールを抱えます。これら全てのスキーマが毎コール送信されるため、ツール定義は固定オーバーヘッドの大きな割合を占めます。

• 現在のタスクに不要なツールをスコープから外す(タスク種別ごとにツールセットを切り替える)
• 引数の説明文を簡潔に書く(冗長な説明は固定費に直結)
• 使用頻度の低いMCPサーバーは常時接続せず、必要時のみ起動する

私たちが顧問先で見るケースでは、「全部入り」のツール構成のままで運用されていることが多く、ここを見直すだけでコールあたり数千トークン削れることもあります。

4. メモリ参照の精度を上げる

Hermes Agent の3層メモリは、永続記憶層から「現在のタスクに関連しそうなスニペット」をプロンプトに注入します。この検索精度が低いと、無関係なメモリが大量に流し込まれて固定オーバーヘッドが膨らみます。

• 永続記憶のメタデータ(タグ・カテゴリ)を整備し、検索ノイズを減らす
• Hermes Curator による剪定を月1回は実行する
• 長期運用で陳腐化した記憶は明示的にアーカイブする

関連事例 — コスト視点の他の発見

@Bichev の73%プロファイリングと併せて参照すべき、コスト視点での代表的な事例を3つ紹介します。

$130→$10 の劇的コスト削減(Greg Isenberg × Imran)

海外のスタートアップコミュニティで広く共有された事例として、5日間で130ドル消費していた Claude Max ユーザーが Hermes Agent + VPS構成に移行することで 10ドル / 5日 まで圧縮した報告があります。10倍以上のコスト差が出る背景には、本記事で扱った固定オーバーヘッドの最適化余地が直接効いています。

家族3人共有のWhatsAppエージェント(@EXM7777)

2026年4月30日、@EXM7777 は ChatGPT $200プラン1本で家族3人分のWhatsApp秘書を Hermes Agent 経由で運用している事例を公開しました。1アカウントを複数人で共有することで固定費を分散させる、コストシェア型の運用例です。

"Much less token hungry" — r/LocalLLaMA コミュニティ評

Reddit の r/LocalLLaMA では、Claude Code から Hermes Agent に乗り換えたユーザーから「much less token hungry(はるかにトークン消費が少ない)」という体感報告が複数寄せられています。@Bichev のプロファイリングが示した最適化余地が、実運用ベースでも体感されている裏付けです。

これら3つの事例に共通するのは「料金プランの選択」ではなく「アーキテクチャ理解による削減」がコスト最適化の本丸だ、という構造です。@Bichev の73%はその出発点を数字で示した一次情報です。

関連記事

Hermes AgentMac miniでHermes Agentを常駐｜実測コストと構成

Hermes AgentHermes Agentの3層メモリと永続記憶｜育つAIの仕組み

Hermes AgentHermes Agent 297日連続運用で$100K自動化

まとめ

• @Bichev のプロファイリング結果「73% of every API call is fixed overhead」は、AIエージェント運用のコスト最適化における出発点となる一次情報
• 固定オーバーヘッドの中身はシステムプロンプト・ツール定義・スキル定義・メモリ抜粋・会話履歴サマリ。いずれも「賢く動くために必要な土台」
• 削除ではなく キャッシング・バッチング・ツール定義スリム化・メモリ精度向上 の4施策が最適化の主戦場
• プロンプトキャッシングを有効化すれば、固定オーバーヘッド部分の単価は約10%に圧縮できる(Anthropic公式仕様)
• $130→$10 の劇的削減事例(Greg Isenberg × Imran)も、本質的には固定オーバーヘッド最適化の効果
• 中小企業がAIエージェントを本格運用する場合、料金プラン選択より「アーキテクチャ理解」がコストに効く

出典:

• @Bichev X post (2026-04-22)
• Hermes Agent — User Stories & Use Cases(Nous Research 公式)
• Anthropic — Prompt Caching(公式ドキュメント)
• awesome-hermes-usecases(一次ソース付き事例集)