◉CLAUDE LABEN
●2.1.301 — vim の % モーション、VS Code パネルでの LaTeX 数式表示、使用量上限待ちのリトライ監視の上限が入りました(10/15)●2.1.299 — 200K トークン超で約54分放置した会話はアイドル圧縮。MCP の許可ルールは名指ししたサーバーだけに一致します●SONNET 4.5 — Claude API での提供終了は 11/30、残り45日。移行先は Sonnet 5.5●WINDOWS — 日本語の環境でだけフックが黙って壊れる報告があり、文字コードの確認が呼びかけられています●FAST MODE — Opus 5.5 の Fast mode がリサーチプレビューを終え、ベータヘッダーが不要になりました(10/15)●NEW — Cowork に渡したフォルダの先頭に、十行の約束ファイルを置いてみました●2.1.301 — vim の % モーション、VS Code パネルでの LaTeX 数式表示、使用量上限待ちのリトライ監視の上限が入りました(10/15)●2.1.299 — 200K トークン超で約54分放置した会話はアイドル圧縮。MCP の許可ルールは名指ししたサーバーだけに一致します●SONNET 4.5 — Claude API での提供終了は 11/30、残り45日。移行先は Sonnet 5.5●WINDOWS — 日本語の環境でだけフックが黙って壊れる報告があり、文字コードの確認が呼びかけられています●FAST MODE — Opus 5.5 の Fast mode がリサーチプレビューを終え、ベータヘッダーが不要になりました(10/15)●NEW — Cowork に渡したフォルダの先頭に、十行の約束ファイルを置いてみました
記事一覧/API & SDK
⬡ API & SDK/2026-05-19上級

Claude API のチャット履歴を階層サマライズする:3 段階圧縮でトークンを 70 % 削減した設計

壁紙アプリのインアプリ AI チャットで増え続ける履歴トークンを抑えるため、直近ターン・中期エピソード・長期エンティティの 3 層に分けて圧縮する設計を、TypeScript の動くコードと 7 週間の運用データつきで記録しました。月額 API 費用を $480 から $145 まで下げています。

claude-api83chat-historysummarizationtoken-optimizationproduction87

✦ プレミアム記事

2026 年 4 月の中ごろ、運営している癒し系の壁紙アプリに組み込んだインアプリ AI チャットが、突然 1 セッションあたりの API コストを倍に押し上げ始めました。月のグラフで気付いたわけではありません。アプリ内のレスポンスがじわじわ重くなっていることをユーザーレビューで指摘されて、ようやくダッシュボードを開いたのです。原因は単純で、長く会話するユーザーほど履歴が膨らみ、毎回その全文を messages に詰めて送り続けていました。直近 40 ターンで input_tokens が 18,000 を超えるセッションも珍しくない状態です。

個人でアプリを運営していると、サーバー側の課金事故はひと通り味わうことになります。ただ Claude API の場合は、いつもの事故と手触りが違いました。壊れていないのです。会話は止まらず、ユーザー満足も悪くありません。それでも履歴が線形に伸びていく以上、input_tokens のグラフは静かに右肩上がりでした。私は数日かけて、履歴を捨てるのではなく階層的に圧縮する設計に切り替え、結果として入力トークンを 7 週間の平均で 70 % 削減できました。

この記事は、その階層サマライゼーションを 3 層構造で組み直した実装記録です。Tier 1(直近ターンの忠実保持)、Tier 2(中期記憶の Haiku 要約)、Tier 3(長期記憶の Sonnet 抽象化)を分業させ、トリミング 1 つでは到達できない圧縮率と意味保持の両立を狙います。コードは Cloudflare Workers + TypeScript で動かしている本番版から再構成しました。

個人開発のアプリで「履歴問題」が形を現すまで

履歴問題は、messages 配列に過去のターンを足し続けるだけのチャット設計につきまといます。短いセッションでは無視できる量ですが、ヘビーユーザーは平気で 80 ターン、100 ターンと続けます。私の壁紙アプリでも、長期利用者の上位 5 % が API コストの 38 % を消費していました。AdMob 経由の広告売上でこのコストを吸収する設計だったので、上位ユーザーが課金で報われない構造になり、放置できないと判断しました。

トリミング戦略の落とし穴

「履歴を 10 ターンで切る」という単純なトリミングを最初に検討しましたが、これは捨てたくない情報まで捨てる可能性があります。たとえば「あなたが先に教えてくれたカラーパレットの好み」「過去に却下したテーマ」のような、会話の文脈を作っている要素は、20 ターン前に出てきても次のリクエストで参照したいものです。トリミングは安いですが、ユーザーの「覚えていてくれない感」を生みます。実体験として、レビュー欄で「設定を毎回聞いてくる」「前に話したことを忘れる」と書かれることが何度かありました。

「忘却」ではなく「圧縮された記憶」

階層サマライゼーションは、この「直近の流れ」と「長期の文脈」を別々に扱う発想です。直近ターンは生のまま保ち、古いターンは要約に置き換え、さらに古いものは抽象化したエンティティ集合に落とします。トリミングが「忘却」だとすれば、階層サマライゼーションは「圧縮された記憶」だと考えています。輪郭だけを残して細部を手放す——昨日の打ち合わせを思い出すときに人がしていることと、案外近いのかもしれません。

3 層構造で履歴を圧縮する全体像

私の本番設計は、会話履歴を次の 3 つの Tier に分けています。

Tier内容圧縮方法想定トークン
Tier 1直近 6 ターン生のまま保持約 2,500
Tier 2中期エピソード(要約済み)Haiku 4.5 で 200 トークンに要約各 200、合計 800〜1,200
Tier 3長期エンティティ・意図Sonnet 4.6 で抽象化した JSON約 600

Tier 1 の役割

Tier 1 は会話の連続性を保つために生のまま送ります。直近 6 ターンを残しているのは、ユーザーが「さっきの返信を変えてほしい」「3 つ前の提案に戻して」と参照する範囲が、私のアプリでは 5〜7 ターンに収まることが多かったからです。これより短いと文脈飛びが起き、これより長いとトークン削減効果が頭打ちになります。

Tier 2 の役割

Tier 2 は中期記憶です。会話が伸びるにつれて「8 ターン前から 14 ターン前までの 1 セット」を 1 つのエピソードとして扱い、Haiku 4.5 で 200 トークン程度に要約します。Haiku を選んでいるのは、要約という比較的軽い推論タスクに対して費用対効果がはっきり見合うからです。後述するプローブで測ると、Haiku の要約は Sonnet の要約に対して再現率で 3 ポイントほど落ちる程度に収まり、要約 1 回あたりのコストは Sonnet の 約 1/6 で済みます。

Tier 3 の役割

Tier 3 は長期記憶です。エピソードが 3 つ以上溜まったら、それらを横断的に眺めて「ユーザーが繰り返し求めていること」「明示的に拒否したこと」「進行中の選好(カラー・モチーフ・気分)」を JSON 構造に抽象化します。ここだけは Sonnet 4.6 を使います。意図抽出は要約より難しく、Haiku に任せると重要なエンティティを取りこぼすことが運用で確認できたためです。浮世絵壁紙で古い紙の写真を仕分けるときの手つきに近いもので、Tier 2 は「一枚ずつ縮めて並べる」、Tier 3 は「並べた束から繰り返し立ち上がる主題を抜き出す」という比喩が、私の中では合っています。

✦

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること
✦Tier 1〜3 の階層サマライゼーションを TypeScript で組む完成コードと、しきい値の決め方が分かります
✦Haiku 4.5 で要約・Sonnet 4.6 で抽象化を分業させ、月額 API 費用を $480 → $145 に下げた配分が分かります
✦圧縮で落ちた文脈を位置別に測るプローブ実装と、エピソード境目の再現率を 63.5 % から 86.5 % へ戻した一行の修正が分かります
Stripe による安全な決済 · いつでもキャンセル可能
✦

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または
メンバーシップなら全記事が読み放題 →
シェア

お読みいただきありがとうございます

Claude Lab は広告なしで運営しており、サーバー費用などの運営コストはメンバーシップのご支援で賄っています。実装コード・ベンチマーク・本番設計パターンなど、実務でお役立ていただける記事を毎日更新しています。もし読んでよかったと感じていただけましたら、ぜひご覧ください。

  • ✦コピー&ペーストで使える実装コード付き
  • ✦毎日新しい上級ガイドを追加
  • ✦¥580/月 または ¥1,480 の永久アクセス
メンバーシップを見る →

関連記事

⬡ API & SDK2026-05-26
Claude API の構造化レスポンスを本番で安定させる — tool_use と JSON Schema、多層検証の実装メモ
Claude API の応答を JSON で受け取る実装は数行で書けますが、本番運用では「形は正しいが意味が壊れている」レスポンスにどう備えるかが分かれ目になります。tool_use・JSON Schema・ドメイン検証を組み合わせた多層パイプラインを、壁紙アプリの分類処理での実体験を交えて整理しました。
⬡ API & SDK2026-05-22
Claude API の tool_result could not be submitted が再発しないための回復ハンドラ設計
Claude API でエージェントを長時間動かしていると、ある日突然 'tool_result could not be submitted' が連発し始めることがあります。再試行しても直らない、ストリーミング途中で死ぬ、そして次のセッションでもまた出る — 常時稼働のエージェント基盤で実際に踏み抜いた4種類の原因と、TypeScript で書いた回復ハンドラの実装を整理しました。
⬡ API & SDK2026-05-10
Claude API のプレフィルで『JSON 出力が必ず通る』本番設計 — 個人 SaaS で辿り着いた4層防御
Claude API のプレフィルだけでは JSON パースが落ちる本番ケースを、4層防御パイプラインでパース成功率 99.98% まで持ち上げた実装記録です。切断応答 1,081 件で修復コードを実測し、当初掲載していた閉じ補完の誤りも訂正しています。