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

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

日本語の文書は、同じ内容を伝えるのに英語より多くのトークンを使います。理由と実測方法はClaudeの日本語トークン消費が英語より多い理由にまとめたとおりで、倍率は文書とモデルによって変わり、Anthropicのドキュメントは言語別の倍率を数値では示していません。

長文要約ではこのずれが二重に効きます。入力の文書量が同じでも消費トークンが増えるうえに、要約の出力自体も、日本語で書く限り同じ倍率で膨らみます。要約の長さはcount_tokensで実測して見積もります。

ウィンドウの大きさは言語に関わらず一定です。日本語の要約タスクは、英語のタスクより早く上限に近づきます。

分割が要るかは「引き算」で決める

分割するかどうかを勘で決めると、途中で失敗するか、不要な分割で処理回数が増えます。判断は次の4手順で足ります。

3手順目の計測は、次のように書けます。モデルを変えて2回数えれば、後述するトークナイザーの差も見えます。

for m in claude-sonnet-4-6 claude-opus-5; do
  jq -n --arg m "$m" --rawfile t report.txt \
    '{model:$m, messages:[{role:"user", content:$t}]}' |
  curl -s 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 @- | jq -r --arg m "$m" '"\($m): \(.input_tokens)"'
done

report.txtに要約したい日本語の文書を置いて実行します。

モデルを替えると同じ文書でも枠が変わる

Claude Opus 4.7以降のモデルは新しいトークナイザーを使い、同じ文章でも従来のモデルより約30%多くトークンを消費します。増え方は内容によって変わります。Claude Opus 4.6以前で測った値は、移行先のモデルでは当てになりません。

公式のモデル比較表は、現行のトークナイザーで1Mトークンを約250万Unicode文字としています。日本語の文書でどこまで入るかはこの換算では決まらず、手順3の実測が唯一の答えです。

200Kウィンドウのモデルへ下げると、入力の枠と出力の枠の両方が小さくなります。多言語の公式評価は英語の試験問題を翻訳したMMLUで測られ、日本語は英語を100%として、Claude Sonnet 4.5が96.8%、Claude Haiku 4.5が93.5%です。要約の品質そのものを測った値ではないので、モデルを下げる前に自分の文書で試す材料として読みます。

思考トークンとPDFは固定費に入る

思考(thinking)で使うトークンもウィンドウに数えられ、max_tokensの内数として出力料金で課金されます。Claude Opus 4.5以降のOpus、Claude Sonnet 4.6以降のSonnetなどは、過去のターンの思考ブロックも既定でウィンドウに残します。要約を会話の形で何往復も続ける構成では、この積み上がりも見込みます。

PDFや画像を渡す場合は、トークンより先にリクエストサイズの上限に当たることがあります。1リクエストに含められる画像またはPDFのページは最大600枚で、200Kウィンドウのモデルでは100枚です。

ウィンドウに収まるなら分割しなくてよいか

収まることと、よく要約できることは別です。トークン数が増えるほど精度と再現性が落ちる現象(context rot)があり、必要な情報だけを文脈に置くことが空き容量と同じくらい重要だと公式は説明しています。1Mトークンに入る文書でも、章ごとに区切ったほうが要約の抜けが減る場合があります。

予算を超えたとき、APIは何を返すか

分割せずに送った結果が失敗か途中停止かは、どこで超えたかで決まります。

要約が途中で終わったときはstop_reasonを見ます。max_tokensなら出力枠の不足、model_context_window_exceededならウィンドウ側の不足です。対処が違うので、切り分けてから設定を直します。

長文を分割するときの切り方

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

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

分割設計は入力側に意識が向きがちですが、max_tokensが小さすぎると、要約が途中で切れます。

Map-Reduceでは、Reduceリクエストの入力にMapの出力(日本語の要約)がそのまま積み上がります。Reduceのmax_tokensは、Mapの出力より余裕を持たせて設定します。

出力言語は、システムプロンプトで明示すると会話全体で安定します。要約の言語が揺れると出力トークン数も揺れるので、予算の見積もりを崩さないためにも指定しておきます。

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

Compactionは、会話の古い部分をClaudeがサーバー側で要約し、その要約から会話を続ける仕組みです。ベータ提供で、Claude Opus 4.6・Claude Sonnet 4.6以降のモデルが対象です。呼び出し方は2種類あります。

どちらもマルチターンの会話やエージェント処理が長引いたとき、会話を延命する機能で、1本の長文文書を1回で要約するタスクには直接使いません。1文書1回きりなら、前節の分割パターンで足ります。効くのは、同じセッションで複数の長文書を順に読ませて質問を続けるような、要約が主目的でない長時間タスクです。

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

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

Claude Sonnet 5・Claude Sonnet 4.6・Claude Sonnet 4.5・Claude Haiku 4.5は「コンテキスト認識」を備えています。コンテキストの残量を追跡する機能です。システムプロンプトには総予算が<budget:token_budget>200000</budget:token_budget>のような形で渡され、ツール呼び出しのたびに<system_warning>Token usage: 35000/200000; 165000 remaining</system_warning>のような更新が入ります。注入はAPI側が行うので、設定も自分でタグを送ることも要りません。

予算の値はリクエストに使えるウィンドウと一致します。1Mトークンのモデルでは100万、20万トークンのモデルでは20万です。

1チャンクの処理でツールを何度も呼びながら要約を組み立てる構成では、残量を把握しているモデルが、残りの空間をふまえて作業の配分を調整できます。分割設計を代替する機能ではありません。

Claude Opus 4.7以降のOpus、Claude Sonnet 5.5、Claude Fable・Claude Mythos系にはこのタグが注入されません。これらのモデルで予算を渡したいときは、ベータ提供のtask budgetsで明示します。同じSonnet 5でも5.5ではこの差が出るので、モデルを替えるときは構成の見直しも要ります。

独立したチャンクが多いならBatch API

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

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時間以内に終わりますが、24時間以内に処理が終わらなければバッチは期限切れになります。結果の取得は、全件完了後か24時間後の早いほうです。即時の応答が要る用途には向きません。

結果の順序は保証されないため、custom_idでチャンクと結果を必ず突き合わせます。

バッチ内の出力上限は同期APIと別枠です。Claude Opus 5.5・Claude Opus 5・Claude Sonnet 5.5・Claude Sonnet 5などは、output-300k-2026-03-24ベータヘッダーで最大30万出力トークンまで受けられます。1チャンクの要約が長くなる設計では、この枠が使える場面があります。

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

• 英語基準の閾値を日本語にそのまま流用する。英語で収まっていたチャンクサイズを日本語に当てると、同じトークン数でも文書量は少なくなり、分割回数が想定より増える
• モデル移行で古い計測値を使い回す。Claude Opus 4.6以前で数えた入力トークンを、4.7以降の見積もりに使うと約30%ずれる。移行先のモデルIDで数え直す
• チャンクごとのシステムプロンプトやツール定義を見積もりに入れない。チャンク数が多いと、その消費も積み上がる。プロンプトキャッシュで固定部分を使い回せるが、Batch APIでは非同期の並行処理のためキャッシュヒットはベストエフォートになる
• max_tokensを大きく取りすぎて入力の枠を食う。入力とmax_tokensの合計が大きいと、生成がウィンドウの上限に達した時点でClaude 4.5以降でも止まる

どの方式を選ぶか

まず上の表のどの行に文書が当たるかを決めると、そのあとの分割幅とmax_tokensの見積もりが定まります。日本語の要約では出力側の膨張が見積もりを崩しやすいので、出力枠は先に確保します。

文字数の扱いはClaudeの文字数制限と長文の扱い方、PDFなど資料形式ごとの手順はClaudeのPDF要約のコツも参考になります。