thinkingのdisplay: summarizedとは — フィールドが空文字になる理由

レスポンスにthinkingブロックは入っているのに、その中のthinkingフィールドを見ると空文字で、signatureフィールドだけが埋まっている。この現象は不具合ではなく、新しいモデルのdisplay設定の既定値が変わったことによる仕様です。原因と、本文を受け取るための切り替え手順をまとめます。

何が起きているか

{
  "type": "thinking",
  "thinking": "",
  "signature": "EqQBCgIY..."
}

このようにthinkingフィールドが空文字列になり、signatureだけが値を持つレスポンスが返ります。エラーにはならず、リクエスト自体は正常に完了するため、ログを見て初めて気づくケースが多い現象です。

なぜ空文字になるのか

新しいモデルでは、思考の表示方法を決めるdisplayパラメーターの既定値が"omitted"になっています。display: "omitted"は、thinkingブロックの構造(typeやsignature)自体は返しつつ、本文にあたるthinkingテキストは返さない設定です。signatureは後続のターンでこのブロックを会話履歴として送り返すために必要な値で、displayの設定にかかわらず常に埋まります。空文字になるのはthinkingテキストの方だけです。

displayの既定値はモデルごとに次のように分かれます。

omittedが既定になっている一番の狙いはレイテンシです。サーバー側が思考トークンのストリーミング自体を省略し、シグネチャだけを返してテキスト応答をより早く開始できるようにするためで、コストを減らす設定ではありません。omittedでも思考トークンは全額課金されます。

本文を受け取るにはdisplay: "summarized"に切り替える

思考の要約テキストを受け取りたい場合は、リクエストのthinking設定にdisplay: "summarized"を明示します。

{
  "thinking": {
    "type": "adaptive",
    "display": "summarized"
  }
}

この設定にすると、thinkingフィールドにClaudeの思考内容を要約したテキストが入って返ります。生の思考過程をそのまま返す設定ではなく、あくまで要約である点は変わりません。

ツール呼び出しの合間の短い状況表示だけが欲しい場合

思考の要約ではなく、ツール呼び出しの合間に表示される短いステータス行(「〜を確認しています」のような一言)だけを受け取りたい場合は、display: "summarized"ではなくdisplay: "updates"(ベータ)を使います。用途が異なる設定なので、欲しい情報の種類で使い分けます。

display: "updates"はベータ機能で、リクエストにanthropic-beta: thinking-display-updates-2026-08-18ヘッダーを付けて指定します。このヘッダーを付けずにdisplay: "updates"を送ると、未知のdisplay値を指定したときと同じ400エラーになります。この設定では通常の推論を担うthinkingブロックのthinkingフィールドはomittedのときと同様に空のままで、ステータス行にあたる進捗更新のブロックだけがテキストを持ちます。エージェントの実行状況をユーザーに見せたいが、内部の推論内容そのものは隠したいUIに向いた設定です。

summarizedは要約であって生の思考ではない

display: "summarized"にしたときに返ってくるテキストは、Claudeの思考過程をそのまま出力したものではなく、要約用の別モデルが生成した要約です。思考を行ったモデル自身はこの要約テキストを見ません。課金対象になるのは要約のトークン数ではなく、元の思考で実際に生成されたトークン数です。表示されるテキスト量と請求されるthinkingトークン数が一致しない点は、コストを見積もるときに誤解しやすいポイントです。

summarizedにしても生の思考過程はそのままでは見えない

display: "summarized"で受け取れるのは要約であり、Claude Opus 4.6・Sonnet 4.6以前のモデルでは要約の冒頭部分だけがやや詳しめに書かれ、プロンプトエンジニアリングの参考にしやすくなっています。Claude Mythos Previewは最初のトークンから要約する仕様のため、この冒頭の詳しめの説明は付きません。生のチェーンオブソートそのものが必要な用途では、summarizedを含めどのdisplay設定でも到達できず、公式には個別に問い合わせる形になっています。「要約ではなく生の思考が必要」という要件は、通常の実装では想定されていない前提だと捉えておくと設計判断がぶれません。

thinkingを無効化する設定と混同しない

「本文が空なら思考自体がオフなのでは」と考えてthinking.typeを"disabled"に変更するのは別の対処です。多くの新しいモデルは思考が既定でオンかつ常時オンで、disabled自体を受け付けないモデルもあります。またdisplayはthinking.type: "disabled"と組み合わせられません(思考をしていないので表示するものがありません)。今回の現象は思考が行われていないのではなく、行われた思考の本文を返す設定になっていないだけです。思考の有無を切り替えたいのか、返ってくる思考本文の量を変えたいのかを区別してから設定を変えます。

実務でつまずきやすいのが、この非互換を知らずにthinkingオブジェクトへdisplayを残したままtypeだけ"disabled"に変えてしまうケースです。displayが指定された状態でthinking.type: "disabled"を送ると、未知のdisplay値を送ったときと同じ400のinvalid_request_errorになります。思考をオフにするときは、displayキー自体をthinkingオブジェクトから外す必要があります。もう一つ注意したいのが、マルチターンの会話で前のターンのthinkingブロックを履歴として送り返すときの扱いです。omittedのまま運用している場合、前のターンのthinkingフィールドは空文字ですが、このブロックを次のリクエストのmessagesにそのまま含めて送り返す必要があり、フィールドの値を書き換えてはいけません。空文字のthinking欄に独自のテキストを書き込んで送っても、その内容はサーバー側で無視され、後続ターンの検証に使われるのはsignatureだけです。

thinkingパラメーター自体を省略しても解決しない

「thinkingの設定をリクエストから丸ごと外せば、この空文字問題を避けられるのでは」と考えることがありますが、思考が既定でオン、特に常時オンのモデルではこの方法は効きません。thinking.typeを指定しなくても、モデル側は変わらず思考を行います。省略した場合のdisplayはそのモデルの既定値がそのまま適用されるため、omittedが既定のモデルでは、thinkingパラメーターごと省略してもthinkingフィールドは空文字のままです。空文字を避けたいなら、thinkingオブジェクトを省略するのではなく、displayを明示的にsummarizedにする必要があります。

display・effort・thinking.typeは別々の設定

thinkingまわりの設定は3つに分かれていて、混同しやすいところです。

effortを上げてもdisplayは変わりませんし、displayをsummarizedにしても思考の量自体が増えるわけではありません。3つは互いに独立したパラメーターとして扱われ、片方の値を変えても残り2つの既定値には影響しません。「本文を見たい」ならdisplay、「もっと考えてほしい/考えなくていい」ならeffort、「思考自体を止めたい」ならthinking.typeを触る、と目的で使い分けます。この3つはリクエストの中で独立して指定でき、どれか一つを変えたら他も連動して変わる、ということはありません。

ストリーミングでも同じ現象が起きる

ストリーミングでは、display: "omitted"のときthinking_deltaイベントがそもそも発行されません。thinkingブロックのcontent_block_startイベントは届きますが、その後に続くはずのテキスト断片が流れてこないため、フロントエンド側で「thinkingブロックが開いたのに中身が来ない」という形で気づくことがあります。ストリーミングで本文を受け取りたい場合も、対処は同じくdisplay: "summarized"です。

with client.messages.stream(
    model="claude-opus-4-8",
    max_tokens=16000,
    thinking={"type": "adaptive", "display": "summarized"},
    messages=[{"role": "user", "content": "..."}],
) as stream:
    for event in stream:
        if event.type == "content_block_delta":
            if event.delta.type == "thinking_delta":
                print(event.delta.thinking, end="", flush=True)

display: "updates"(ベータ)にした場合は、進捗更新に該当するブロックだけthinking_deltaが流れ、通常の推論ブロックはomittedのときと同じく空のままです。

displayを会話の途中で切り替えてもよいか

signatureの値はdisplayの設定に関わらず同じものが返るため、会話の途中でdisplayを切り替えても構いません。omittedで始めた会話を途中からsummarizedに変えても、それまでのやり取りが壊れることはありません。一方でadaptive thinkingがそのターンの思考自体をスキップした場合は、displayをどの値にしていてもthinkingブロックは生成されません。空文字はthinkingブロックが「ある」上での話で、ブロックの有無とは別の話です。この現象はadaptive thinking blockが出ない理由で扱います。

よくある質問

signatureフィールドの値は何に使うのか

後続のターンでこのthinkingブロックを会話履歴として送り返すときに使う値です。API側がこのsignatureを検証・復号して元の思考を会話に組み込むため、displayの設定に関わらず必ず埋まります。空文字になるのはthinkingテキストの方だけで、signatureを見て「ブロック自体は正常に生成されている」と判断できます。逆にsignatureまで空、あるいはブロック自体が存在しない場合は、この記事の現象とは別に、思考そのものがそのターンでスキップされたケースです。

既存のリクエストにdisplayを追加するだけで動くか

はい。thinkingオブジェクトの中にdisplay: "summarized"を1行追加するだけで動きます。モデルやthinking.typeの値を変える必要はなく、effortなど他の設定と組み合わせても独立して機能します。ツール定義やmessages配列の組み立て方も変える必要はなく、既存のコードに対する変更はthinkingオブジェクトの1フィールドだけで完結します。

omittedのまま運用してよいケースはあるか

あります。思考の内容をユーザーに見せる予定がなく、後続ターンへの引き継ぎ用にsignatureだけ保持できれば十分な実装では、omittedのままで問題ありません。むしろomittedはストリーミングの最初のテキストトークンが届くまでの時間を短縮する効果があるため、UIに思考内容を表示しない構成では既定のままにしておく方が有利です。逆に、デバッグ時だけsummarizedに切り替えて思考の流れを確認し、本番リクエストではomittedに戻す、という使い分けも成り立ちます。

まとめ

displayはリクエストのthinkingオブジェクトに1つ値を追加するだけの設定で、モデルやツール定義を変える必要はありません。空文字のthinkingフィールドを見て不具合を疑う前に、まず自分が使っているモデルのdisplay既定値を確認し、本文が必要ならsummarizedを、状況表示だけでよいならupdatesを選びます。thinkingフィールドが空文字になるのは、新しいモデルでdisplayの既定値が"omitted"になっているためで、signatureだけは常に返ります。思考の要約テキストが必要な場合はdisplay: "summarized"を明示し、短いステータス行だけでよい場合はdisplay: "updates"を使います。効果的なeffortの設定と合わせて使う場合の考え方はClaude effortとは — low〜maxの使い分け方にまとめています。adaptive thinkingが一部のターンでまったく実行されない現象についてはadaptive thinkingで一部ターンにthinkingブロックが出ない理由を参照してください。