Claude APIの「Prompt is Too Long」エラーを解決する方法

intermediate🧠 AI Tools2026-05-17| Anthropic SDK (v0.18.0+) を使用する Python または Node.js 環境、あるいは Claude 3/3.5 モデルへの直接的な REST API コール。

Error Message

prompt is too long: X tokens > 200000 maximum
#claude#anthropic#コンテキスト長#トークン

コンテキスト制限について理解するコンテキスト制限に達することは、まるで厚い壁にぶつかるようなものです。アプリがコードベースを要約していたかと思えば、次の瞬間にはAnthropicが400エラーを返してきます。Claude 3.5 SonnetおよびOpusは、20万トークンという膨大なコンテキストウィンドウをサポートしていますが、予想以上に早く使い果たしてしまうことがあります。参考までに、1MBのテキストファイルや500ページのPDFを処理すると、簡単に20万から25万トークンを消費してしまいます。

ログに表示される具体的なエラーメッセージは以下のようになります。

prompt is too long: 215432 tokens > 200000 maximum

これは「400 Bad Request」エラーです。システムプロンプト、メッセージ履歴、および新しいユーザー入力を含むペイロードが、モデルのアーキテクチャ上の容量を超えているため、APIがリクエストを拒否しています。レート制限とは異なり、再試行しても解決しません。リクエストを成功させるには、入力サイズを削減する必要があります。

デバッグプロセス修正の第一歩は、何がリクエストを肥大化させているかを特定することです。開発者はしばしば文字数とトークン数を混同しますが、これらは同じではありません。Anthropicのエコシステムでは、通常1,000トークンは約750語に相当します。しかし、コードスニペットや英語以外のテキストは密度がはるかに高く、トークンをより早く消費します。

1. メッセージオブジェクトの確認まずは、messages配列の長さをログに出力することから始めましょう。チャットボットを構築している場合、クリーンアップ戦略なしにすべてのやり取りを配列に追加し続けている可能性があります。数十回のやり取りを重ねると履歴が肥大化し、最終的に連携がクラッシュします。

2. 送信前にトークン数をカウントするAnthropicはトークンを計算するためのクライアント側メソッドを提供しています。これを使用してローカルでエラーをキャッチし、失敗する有料のAPIコールを回避しましょう。Pythonでの実装方法は以下の通りです。

import anthropic

client = anthropic.Anthropic(api_key="your_api_key")

# メッセージのペイロード
messages = [
    {"role": "user", "content": "Here is a very long document..."}
]

# APIを呼び出す前にカウントを確認
response = client.messages.count_tokens(
    model="claude-3-5-sonnet-20240620",
    messages=messages
)

print(f"トークン数: {response.input_tokens}")

if response.input_tokens > 200000:
    print("警告: このプロンプトは失敗します!")

エラーを修正するための実証済みの解決策### 解決策1:スライディングウィンドウ(FIFO)の使用対話型アプリで最も効果的な修正方法は「スライディングウィンドウ」です。履歴全体を送信する代わりに、直近の10個または15個のメッセージのみを含めます。これにより、プロンプトのサイズを予測可能に保ち、徐々に肥大化するのを防ぎます。

def get_limited_history(full_history, max_messages=10):
    # 直近のN個のメッセージのみを保持
    if len(full_history) > max_messages:
        return full_history[-max_messages:]
    return full_history

解決策2:巨大なドキュメントの切り詰め巨大なドキュメントを処理する場合は、切り詰め(トランケーション)戦略が必要です。ログファイルが30万トークンある場合、直近の10万トークンのみを送信するようにします。あるいは、ドキュメントを小さなチャンクに分割します。Claudeに各パーツを個別に要約させ、それらの要約を組み合わせて最終的な分析を行います。

解決策3:RAG(検索拡張生成)の実装データセットが常に20万トークンを超える場合は、プロンプトで生データを送信するのをやめましょう。代わりに、PineconeやChromaのようなベクトルデータベースを使用します。このアプローチは以下の3つのステップで機能します。

  • ドキュメントを数学的な埋め込み(エンベディング)に変換する。- ユーザーの特定の質問に基づいて、最も関連性の高いスニペットをデータベースから検索する。- それらのスニペット(通常2,000〜5,000トークン)のみをClaudeに渡す。### 解決策4:再帰的要約古いメッセージをただ削除するのではなく、要約しましょう。会話が15万トークンに達したら、バックグラウンドタスクを実行します。Claudeに「この会話の主要な決定事項と事実を要約してください」と依頼します。その後、肥大化した履歴をその単一の要約に置き換えることで、将来のやり取りのために大幅なスペースを確保できます。

検証とモニタリング修正が機能することを確認するために、APIコールを堅牢なエラーハンドラーでラップします。制限をわずかに超えていることがわかっているペイロードでテストを実行してください。これにより、切り詰めやRAGのロジックが、アプリをクラッシュさせることなくオーバーフローを適切に処理できるかを検証できます。

try:
    response = client.messages.create(
        model="claude-3-5-sonnet-20240620",
        max_tokens=1024,
        messages=my_processed_messages
    )
    print("成功!")
except anthropic.BadRequestError as e:
    if "prompt is too long" in str(e):
        print(f"ロジック失敗: {e}")
        # 緊急の切り詰め、またはユーザーへの通知を実行

まとめ- トークンは文字数ではない: 1,000トークンのプロンプトは約750語ですが、コードは多くの場合それよりもはるかに密度が高くなります。- 状態を管理する: 本番環境では、メッセージを無盲目に配列に追加し続けないでください。常にクリーンアップまたは切り詰め戦略を使用しましょう。- コストの削減: プロンプトのサイズを削減することは、エラーを修正するだけでなく、APIコストの大幅な削減にもつながります。特にClaude 3 Opusのようなハイエンドモデルを使用する場合に効果的です。- モデルの仕様を確認する: Claude 3.5 Sonnetは20万トークンをサポートしていますが、将来のモデルや異なるバージョンでは制限が異なる場合があります。

Related Error Notes