【実測】Kimi K2.6のAPI費用を1日$28から$8に圧縮した7つのコンテキスト節約術

2026年1月9日、Anthropicがサブスクリプション認証経由でのサードパーティツール利用を技術的にブロックしました。4月4日にはその方針をさらに厳格化し、Claude Pro/Max契約者が OpenClaw、OpenCode、Hermes Agentなどの外部ハーネスでClaudeを使う経路を完全に塞ぎました。月$200のMaxサブスクで実質無制限に使えていたトークンが、API従量課金では同等ワークロードで月$1,000〜$5,000になるという試算も各所で報告されています。

筆者もまさにこの流れで Hermes Agent + Kimi K2.6 構成に切り替え、1日で$28のAPI請求という結果を見て青ざめた一人です。本記事では、その状態から1週間かけて1日$8台まで圧縮した実測ベースの節約術を、7つの打ち手にまとめてお届けします。

対象読者は、フロンティアLLMのAPIを本気で業務利用している開発者・AI実装コンサル・個人事業主です。ByteRoverなどのメモリ層を既に導入済みでもまだコストが下がらない方に、特に刺さる内容だと思います。

なぜ今コンテキスト節約が必要なのか — Anthropic締め出しの衝撃

2026年のLLM API料金は「定額の時代」の終わり

Anthropicが締め出しを実施した背景を整理すると、サブスクプランは人間のチャット利用を前提とした価格設計だったのに対し、サードパーティのエージェント系ツールは24時間自動ループでAPI換算数千ドル相当のトークンを消費していた、という構造的な問題がありました。

Anthropicエンジニアの公式コメントでも「サブスクリプションはこれらサードパーティツールの利用パターンを想定していない」と明言されており、月額200ドルで数千ドル分使える"裁定取引"は終わりを告げました。

この動きはAnthropicだけではありません。各社のフロンティアLLMは軒並み、エージェント用途の実価格を正直に反映する方向にシフトしています。

従量課金で浮き彫りになる「コンテキストの浪費」

サブスク時代には見えていなかったコストが、従量課金では一気に顕在化します。

注目すべきはKimi K2.6のキャッシュ時価格 $0.16/1Mです。これはClaude Sonnet 4.6のキャッシュミス価格の約1/20。つまりキャッシュが効けば、エージェント用途でも実用的なコストに収まります。逆に言えば、キャッシュが効かない構造でK2.6を使うのは最大級の浪費ということです。

コンテキスト設計が「プロダクトの原価」を決める時代

LLM APIが従量課金に一本化された結果、プロンプトの構造がそのまま事業原価になる時代が来ました。

これは、クラウドコンピューティング初期に「EC2インスタンスを立てっぱなし」で請求書に驚いた頃と同じ構造です。設計の巧拙が直接お金に跳ね返る。だからこそ、コンテキスト設計は単なる「最適化」ではなく、事業判断の最重要トピックになりました。

以下、実測ベースの7つの打ち手を紹介します。

打ち手1: プロンプトキャッシュを確実に効かせる構造にする

なぜキャッシュが効かないのか

Kimi K2.6、Claude、Geminiの主要モデルは自動プロンプトキャッシュに対応しています。ただし、これには明確な前提条件があります。

よくある破壊パターンはこちらです。

• 動的要素をプロンプト先頭に入れている: 現在時刻、ユーザー名、セッションID、リクエストIDなど
• ByteRoverなどメモリ層の出力を先頭に置いている: これらは毎回変わるのでキャッシュキーを破壊する
• ツール定義と会話履歴の順序が固定されていない: フレームワーク任せだと順序が揺れる

正しいプロンプト順序

キャッシュを最大限効かせるには、「不変の巨大ブロック」を先頭に、「毎回変わる小さなブロック」を末尾にというルールが鉄則です。

[固定部 = キャッシュ対象]
1. システムプロンプト（Hermesの定型文など）
2. AGENTS.md 全文
3. スキル定義・ツール定義
4. プロジェクト固有の永続コンテキスト
---ここまで毎回同一にする---

[動的部 = キャッシュ外]
5. ByteRover等から取得した動的メモリ
6. 現在日時・ユーザー情報
7. 会話履歴（古い順）
8. 今回のユーザー入力

この順序に変えるだけで、AGENTS.mdが巨大なほどキャッシュ効果が大きくなります。20Kトークンのシステムプロンプト+AGENTS.mdなら、キャッシュヒットで入力料金が83%削減されます。

キャッシュヒット率の確認方法

Moonshot、Anthropic、OpenAI、いずれもAPIレスポンスの usage オブジェクトに cached_tokens が含まれます。これをダッシュボードで可視化し、キャッシュヒット率70%以上を維持するのが目標です。

30%未満なら、ほぼ確実にプロンプト順序に問題があります。

打ち手2: 司令塔と実行層を分離する「階層化アーキテクチャ」

すべてをフロンティアLLMに投げる愚を避ける

Hermes Agent、OpenClaw代替、Codex CLIなどを使っていると、あらゆるタスクが司令塔LLMを経由する構造になりがちです。その結果、「メールを1通分類するだけ」のタスクでも、AGENTS.mdを含む巨大プロンプトを読み込ませてしまう。

これはCPUに例えると、メモ帳を開くのに毎回OSを再起動しているようなものです。

3層に分離する

┌─────────────────────────────────────────┐
│ レイヤー1: 軽量判定層                     │
│ モデル: ローカルgemma4:e4b / DeepSeek V3.2 │
│ 役割: 分類、ルーティング、単純判定        │
│ コスト: ~$0                              │
└─────────────────────────────────────────┘
         ↓「複雑な判断が必要」と判定時のみ
┌─────────────────────────────────────────┐
│ レイヤー2: 司令塔層                      │
│ モデル: Kimi K2.6 / Claude Sonnet 4.6   │
│ 役割: タスク計画、進行管理、委譲判断      │
│ コスト: キャッシュ活用で$5〜10/日         │
└─────────────────────────────────────────┘
         ↓ 重い実装タスクは委譲
┌─────────────────────────────────────────┐
│ レイヤー3: 実行層                        │
│ モデル: Claude Code / Codex              │
│ 役割: 実際のコーディング、レビュー、設計  │
│ コスト: サブスク                         │
└─────────────────────────────────────────┘

レイヤー1の存在が最重要です。ここがフィルタとして機能することで、上位層への呼び出しが激減します。

ローカルLLMを遠慮なく使う

ローカル推論は「なんとなく精度が不安」という心理的ハードルがありますが、分類タスクや単純判定にgemma4:e4bを使う程度なら、十分実用的な精度です。Ollamaで ollama run gemma4:e4b 一発で動きます。

レイテンシも、ネットワーク往復がない分、むしろクラウドAPIより高速なケースが多いです。

打ち手3: cronジョブはフロンティアLLMに投げない

cronジョブがコストブラックホールになる構造

筆者の1日$28の内訳を分析すると、最大の食いしん坊はcronジョブでした。具体的には以下です。

• 10分毎のメール新着チェック
• 1時間毎の過去ジョブ失敗ログの確認
• 夜間バッチの実行結果サマリ生成

これらを全部Hermes経由でKimi K2.6に投げていたのですが、1回あたり以下のトークンを消費していました。

• システムプロンプト+AGENTS.md: 約20Kトークン（キャッシュヒット率次第で$0.003〜$0.019）
• ツール結果: 5〜15Kトークン
• 出力: Thinkingモード込みで3〜8Kトークン

1日に50回のcronが走ると、それだけで$10〜15になる計算です。

cronは「頭を使わない判定」に徹する

メールチェックの中身を冷静に見ると、やっていることは以下くらいです。

• 差出人は既存クライアントか？
• 件名に緊急性ワードがあるか？
• 24時間以内の対応が必要そうか？

これはgemma4:e4bやDeepSeek V3.2で十分な精度が出る判定です。フロンティアLLMの洗練された推論は、ここでは不要。

具体実装例

Hermes経由ではなく、独立したPythonスクリプトをcronから直接叩きます。

# cron_monitor.py
import ollama
import json

SYSTEM_PROMPT = """あなたはメール分類エージェント。
以下のメールを JSON で以下のフィールドに分類せよ:
- priority: urgent / important / normal / ignore
- needs_human: true / false
- category: client / internal / notification / spam

出力はJSONのみ。前置き・後置き禁止。"""

def classify_email(email):
    response = ollama.chat(
        model='gemma4:e4b',
        messages=[
            {'role': 'system', 'content': SYSTEM_PROMPT},
            {'role': 'user', 'content': f'From: {email.sender}\nSubject: {email.subject}\nBody: {email.body[:500]}'}
        ],
        format='json'
    )
    return json.loads(response['message']['content'])

# urgent または needs_human=true のときだけ司令塔に通知
for email in fetch_new_emails():
    result = classify_email(email)
    if result['priority'] == 'urgent' or result['needs_human']:
        notify_hermes_commander(email, result)

効果: 筆者の環境では、cronジョブ関連コストが1日$12 → $0になりました。10回中9回はローカル判定で終わり、本当に司令塔の判断が必要な1回だけK2.6が起動する構造です。

打ち手4: Thinkingモードは司令塔用途ではオフにする

Thinkingモードのコスト構造

Kimi K2.6、Claude Opus、DeepSeek R1などの「Thinking」「Extended Thinking」「Reasoning」モードは、出力トークンに推論トークンが加算されます。Artificial Analysisの検証では、K2.6はThinkingモード有効時に平均の4倍のトークン量を生成することが確認されています。

出力$4.00/1Mのモデルでトークン数が4倍になるということは、実効コストは$16/1M相当になる計算です。

司令塔用途にThinkingは不要

司令塔が下す判断の大部分は、以下のような単純なルーティングです。

• このタスクはClaude Codeに委譲すべきか、自分で処理すべきか
• このエラーは自動リトライ可能か、人間に通知すべきか
• このファイル操作は安全か、確認が必要か

これらに深い推論は要りません。Thinkingは設計判断、複雑なデバッグ、アーキテクチャ選定など、本当に必要な場面だけオンにすればいいのです。

実装

Moonshot API の場合、リクエストパラメータで制御します。

response = client.chat.completions.create(
    model='kimi-k2.6',
    messages=[...],
    extra_body={'thinking': {'type': 'disabled'}}  # Thinking無効化
)

Hermesの場合は、subagent単位で thinking: disabled を設定できます。タスク種別に応じて切り替えるのがベストプラクティスです。

効果: 出力トークンが30〜60%減少。1日$3〜5の削減。

打ち手5: AGENTS.mdに「効率ルール」を刻む

完遂力の高いLLMほど往復が増える

皮肉なことに、指示を忠実に守るモデル（Kimi K2.6、Claude Sonnet 4.6など）ほど、「念のため確認します」「もう一度ファイルを見てみます」という往復を多用します。これは信頼性の副作用ですが、往復1回ごとにAGENTS.md全体を読み直すので、コストが膨らみます。

AGENTS.mdに刻むべき節約ルール

AGENTS.mdに以下のセクションを追加すると、モデルが自発的に節約行動を取るようになります。

## 効率ルール（厳守）

1. **ファイル再読み込み禁止**: 一度読んだファイルの内容は会話内で記憶せよ。
   同じファイルを2度以上 view することは禁止。

2. **まとめ読みの原則**: タスク着手前に、必要になりそうなファイルを
   すべて列挙し、1回のターンで並列に読み込め。1ファイルずつ順次読むな。

3. **確認往復の上限**: 確認目的のツール呼び出しは最大2回まで。
   それ以上の確認が必要な場合は、人間に質問せよ。

4. **Thinkingの使い所**: 単純判定・ルーティングではThinkingを使うな。
   設計判断・複雑なデバッグの時のみ使え。

5. **出力の簡潔性**: 応答は結論ファースト。前置きと後置きを最小化せよ。
   箇条書きで済むものは箇条書きにせよ。

6. **不確実性の扱い**: 確信度が低い判断を強行するな。
   追加情報が必要なら、まず人間に確認を求めよ。

効果測定

この効率ルールを導入すると、同じタスクでの往復回数が平均30〜40%減少します。キャッシュも効いているので、実コストは体感でそれ以上削減される印象です。

打ち手6: リポジトリ検索はRAGで前処理

巨大リポジトリ問題

筆者が管理するリポジトリの1つは約19GBあります。当然、これを丸ごとLLMのコンテキストに入れることは不可能です（K2.6の256Kコンテキストでも1MB程度）。

にも関わらず、司令塔がコードベースを「探索」するプロセスで大量のトークンを消費していました。具体的には以下です。

• ファイルをlistして候補を絞る
• 各候補をview して中身確認
• 関係なかったら次をview
• 見つかったら関連ファイルも連鎖的にview

1つの質問に答えるために、20〜50ファイルをviewすることもザラです。

解決策: 事前ベクトル化

RAG実装経験のある方なら、これは見慣れた問題設計のはずです。

1. リポジトリを定期的にベクトル化
   - OpenAI text-embedding-3-small: $0.02/1M tokens
   - ファイル単位 or 関数単位でチャンク分割
   - pgvectorやChromaDBに格納

2. 司令塔が必要な時は、まずベクトル検索
   - 上位5〜10ファイルだけを司令塔のコンテキストに渡す
   - 「どのファイルを見るべきか」の探索コストがゼロに

3. さらに必要なら、具体ファイルをview

コスト比較: 19GBリポジトリの定期再インデックス費用は月$1〜3程度。対して、探索コストの削減は1日$5〜8。圧倒的に元が取れます。

ripgrepラッパーという軽量解

全面RAG化が重い場合、暫定策としてripgrepラッパーを1つ作る方法もあります。司令塔は「xxxに関連するコード箇所を探せ」と指示するだけで、ラッパーが rg コマンドを実行し、マッチした行のみを司令塔に返します。

これだけで、探索フェーズのトークン消費が1/10〜1/20になります。

打ち手7: 会話履歴の早期圧縮戦略

デフォルトの圧縮は遅すぎる

Hermes Agent、OpenCode、Kimi Code CLIなど多くのフレームワークには、コンテキスト制限に近づいたら自動圧縮する仕組みが入っています。しかし、デフォルトでは上限95%くらいまで溜めてから発火します。

これは「限界まで使うのが最効率」という前提ですが、従量課金では溜まった履歴全体にトークン課金が発生し続けるので、実は逆効果です。

DeepSeekの3戦略から学ぶ

DeepSeek V3.2が採用している3つの戦略が参考になります。

1. Summary: コンテキストを要約し、新コンテキストで再スタート
2. Discard-75%: ツール呼び出し履歴の先頭75%を破棄
3. Discard-all: ツール呼び出し履歴をすべて破棄（Anthropicの "new context" 相当）

司令塔用途では、50%を超えたらDiscard-75%を発動するくらいが節約効果とバランスが取れます。

実装パターン

def manage_context(messages, threshold=0.5, max_tokens=256_000):
    current_tokens = count_tokens(messages)
    
    if current_tokens / max_tokens > threshold:
        # tool_call / tool_result ペアの先頭75%を破棄
        tool_interactions = [m for m in messages if m['role'] in ['tool', 'assistant']]
        keep_count = len(tool_interactions) // 4
        
        preserved = messages[:1] + tool_interactions[-keep_count:]
        return preserved
    
    return messages

効果: 長時間セッションでの入力トークンが平均40%削減。

実測: 1日$28 → $8の内訳

筆者が1週間かけて上記7つの打ち手を順次導入した結果の実測値です。

月額換算: $840 → $240、年間で$7,200の削減です。しかも司令塔の完遂率は変わらず、むしろ効率ルールの副作用で体感的には改善しました。

打ち手6（RAG前処理）は、リポジトリによっては月$3〜5程度の構築コストがかかるため、上記表には含めていませんが、同等の削減効果が期待できます。

まとめ: これからのLLMコスト設計

3つの原則

2026年以降のLLM API設計で押さえるべき原則は、突き詰めれば以下の3つです。

1. 適材適所: フロンティアLLMを全タスクに使うのは、ランボルギーニで通勤するようなもの。軽量モデル・ローカルモデルを遠慮なく混ぜる。
2. キャッシュファースト: プロンプト構造を「キャッシュが効く前提」で設計する。固定部分を先、動的部分を後。
3. トークン会計: APIコストは事業原価。毎日の請求額を把握し、異常値には即座に介入する。

Anthropic締め出しは悪い話ばかりではない

OpenClaw系ツールによるサブスク経由の裁定取引が終わったことは、短期的にはユーザー負担増です。しかし、これはLLM API市場の健全化でもあります。

各社が実コストを正直に価格反映した結果、DeepSeek V3.2のような安価モデルや、Kimi K2.6のようなキャッシュ重視モデルが競争優位を持つようになりました。ユーザー側のコスト設計力が、そのままサービスの競争力に直結する時代です。

次のステップ

本記事で紹介した7つの打ち手のうち、最も即効性が高いのは打ち手3（cron分離）です。もし今すぐ1つだけ試すなら、これをお勧めします。次に打ち手1（キャッシュ最適化）、打ち手4（Thinking制御）の順で効果が出やすいです。

全部をいきなり導入する必要はありません。1週間かけて1つずつ試し、毎日の請求額の変化を観察してください。トークン会計の感覚が身についてくると、コンテキスト設計そのものが楽しくなります。

この記事が役に立ったら、同じように従量課金の請求書に悩む開発者にシェアしていただけると嬉しいです。実測データを元にした具体策が、誰かの1ヶ月の請求書を$600救うかもしれません。