Claudeで日本語要約のコンテキスト予算を分割設計する

日本語の長文要約でコンテキスト予算が先に尽きる理由

日本語の文書は、同じ内容を伝えるのに英語より多くのトークンを使います。理由と実測方法はClaudeの日本語トークン消費が英語より多い理由にまとめたとおりで、Anthropicは言語別の正確な倍率を公表していませんが、第三者検証では2〜3倍という数字が繰り返し報告されています。

長文要約タスクではこのずれが二重に効きます。入力の文書量が同じでも消費トークンが増えるだけでなく、要約の出力自体も日本語で書く限り同じ倍率で膨らみます。英語で1,000トークンに収まる要約が、日本語では2,000〜3,000トークンに達することも珍しくありません。コンテキストウィンドウのサイズは言語に関わらず一定なので、日本語の要約タスクは英語のタスクより早く上限に近づきます。この記事では、その前提でコンテキスト予算をどう設計し、いつ分割するかを扱います。

分割が必要になる境目をどう見積もるか

分割するかどうかを勘で決めると、途中で失敗するか、逆に不要な分割で処理回数が増えます。見積もりの起点は3つです。

1. モデルのコンテキストウィンドウサイズ。Claude Sonnet 5・Claude Opus 5をはじめとする1Mトークン対応モデルは既定で100万トークンを使えます(ベータヘッダー不要)。一方、Claude Sonnet 4.5やClaude Haiku 4.5は20万トークンが上限です。同じ文書でも、載せるモデルによって分割が要るかどうかが変わります。

2. 出力の上限。どのモデルでも1リクエストの出力上限は最大128,000トークンです。入力に余裕があっても、日本語の要約が長くなりやすい以上、出力側の上限も無視できません。

3. 実測。見積もりの精度を上げる一番確実な方法は、実際の文書でトークン数を数えることです。count_tokensエンドポイントを使えば、送信前に入力トークン数を無料で確認できます。

curl https://api.anthropic.com/v1/messages/count_tokens \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "content-type: application/json" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "claude-opus-5",
    "messages": [{"role": "user", "content": "(ここに要約対象の日本語文書を貼り付け)"}]
  }'

入力トークン数がコンテキストウィンドウの6〜7割を超えたら分割を検討する、という目安を持っておくと判断が速くなります。システムプロンプトやツール定義も同じ予算を消費するため、実際に使える余地は数値上の上限より狭くなります。

概算の当たりを付ける例: 日本語の文字数から大まかなトークン数を見積もるときは、Claudeの日本語トークン消費が英語より多い理由にある英語基準(1トークン≈3.5文字)と、日本語での第三者検証値(2〜3倍のトークン消費)を組み合わせます。たとえば20万字の日本語レポートなら、英語換算で1トークン3.5文字とすると約57,000トークン相当ですが、日本語では2〜3倍の消費として約114,000〜171,000トークンになる計算です。20万トークンモデルなら6〜7割の目安(12〜14万トークン)にすでに近く、要約の出力分も足すと単一リクエストでは厳しくなります。1Mトークン対応モデルであれば同じ文書量でも余裕があり、分割せずに済む可能性が高くなります。この概算はあくまで当たりをつけるためのもので、実際の分割判断は前述のcount_tokensでの実測に置き換えます。

長文を分割するときの設計パターン

分割そのものは単純ですが、切り方を間違えると要約の質が落ちます。用途に応じて次の3パターンを使い分けます。

文字数だけで機械的に区切ると、文の途中や箇条書きの途中で切れてしまい、その回のチャンクだけ意味が通らない要約が返ってきます。見出し・段落・箇条書きの境界を優先し、やむを得ず途中で切る場合は前後のチャンクに数文分の重複を持たせるのが安全です。

Compactionは会話の長期化向け、単発の長文要約には別の道具

Compactionは、入力トークンが指定した閾値(既定15万トークン、最小5万トークン)に達すると、Claudeが会話の古い部分を自動で要約し、その要約から会話を継続する仕組みです。Claude 4.6以降のモデルでベータ提供されています。

これはマルチターンの会話やエージェント処理が長引いたときにコンテキストを延命する機能であって、1本の長文文書を1回で要約するタスクには直接使いません。1文書1回きりの要約なら、前節の分割パターンで十分です。Compactionが効くのは、同じセッション内で複数の長文書を順番に読ませて質問し続けるような、要約が主目的ではない長時間タスクの副産物としてコンテキストが膨らむ場面です。

要約の中身をどう残すかを制御したい場合は、instructions パラメータでデフォルトの要約プロンプトを丸ごと差し替えられます。日本語文書の固有名詞や数値を優先的に残したいときの書き方はCompactionのカスタム要約プロンプトを書く実装ガイドで扱っています。

Claudeが自分の残り予算を把握する仕組み

Claude Sonnet 5・Claude Sonnet 4.6・Claude Haiku 4.5は、会話の中で自分がどれだけコンテキストを使い、あとどれだけ残っているかを追跡する「コンテキスト認識」を備えています。システムプロンプトには総予算(<budget:token_budget>200000</budget:token_budget> のようなタグ)が渡され、ツール呼び出しのたびに残量が更新されます。特別な設定は不要で、API側が自動的に注入します。

これは、1回の分割チャンクの中でClaudeがツールを何度も呼び出しながら要約を組み立てるような処理で効いてきます。残り予算をClaude自身が把握しているぶん、予算切れ直前で作業を強引に打ち切るのではなく、途中経過をまとめて終わらせるような挙動を取りやすくなります。ただしClaude Opus 4.7以降のOpusモデルやClaude Fable・Mythos系は、この自動タグ注入の対象外です。これらのモデルで同等の制御をしたい場合は、ベータ提供のtask budgetsで明示的に予算を渡す必要があります。分割設計そのものを代替する機能ではありませんが、1チャンクの処理が複数ステップにまたがる構成では、モデルによってこの違いがあることを踏まえてモデルを選びます。

複数文書をまとめて要約するならBatch API

分割した結果、独立したチャンクの要約リクエストが何十件・何百件にもなる場合や、社内文書を一括で要約する定期処理を組む場合は、Message Batches APIが向いています。標準料金の50%で処理でき、1バッチは最大10万件・256MBまで、多くは1時間以内に完了します。

curl https://api.anthropic.com/v1/messages/batches \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "requests": [
      {
        "custom_id": "doc-chunk-001",
        "params": {
          "model": "claude-opus-5",
          "max_tokens": 2048,
          "messages": [{"role": "user", "content": "(チャンク1の日本語文書を要約)"}]
        }
      },
      {
        "custom_id": "doc-chunk-002",
        "params": {
          "model": "claude-opus-5",
          "max_tokens": 2048,
          "messages": [{"role": "user", "content": "(チャンク2の日本語文書を要約)"}]
        }
      }
    ]
  }'

同期処理でチャンクを1件ずつ待つより、独立したチャンク要約はBatch APIにまとめて投げたほうが速く、コストも半分で済みます。ただし結果の順序は保証されないため、custom_id でどのチャンクの結果かを必ず突き合わせる必要があります。

出力トークンの予算も見落とさない

分割設計は入力側に意識が向きがちですが、日本語の出力も同じ倍率で膨らむことを忘れると、max_tokens の設定が小さすぎて要約が途中で切れる事故が起きます。特にMap-Reduce方式では、Reduceステップで複数チャンクの一次要約をまとめて読み込むため、Reduceリクエストの入力トークンにはMapステップの出力(=日本語要約)がそのまま積み上がります。Reduceステップの max_tokens は、Mapステップの出力より余裕を持たせて設定します。

実装時によくあるつまずき

• 固定文字数で機械的に分割し、文や箇条書きの途中で切ってしまう。境界チャンクの要約だけ意味が通らなくなる。見出しや段落の切れ目を優先する
• 英語基準の閾値をそのまま流用する。英語の文書で問題なく収まっていたチャンクサイズを日本語文書にそのまま適用すると、同じトークン数でも実際の文書量は少なくなり、分割回数が想定より増える
• チャンクごとのシステムプロンプトやツール定義のトークンを見積もりに入れない。チャンク数が多いと、その分だけシステムプロンプトの消費も積み上がる。プロンプトキャッシュで固定部分を使い回すと無駄が減る
• Reduceステップの max_tokens をMapステップと同じ値のまま使う。入力側の日本語要約が積み上がる分、出力の余地も別途確保する必要がある
• Batch APIの結果を custom_id で突き合わせず、返ってきた順に処理する。結果の順序は入力順と一致しない

どの分割方式を選ぶか

日本語の長文要約でコンテキスト予算に余裕を持たせたいなら、入力だけでなく出力側の膨張も含めて見積もり、意味単位での分割を基本にしたうえで、独立したチャンクが多い場合はBatch APIでコストと処理時間を圧縮するのが実務的な落としどころです。長さそのものへの対処はClaudeの文字数制限と長文の扱い方、PDFなど資料形式ごとの要約手順はClaudeのPDF要約のコツも参考になります。