Claude Codeの応答が消える理由 — thinkingに吸収される仕組み
Claude Codeでツール呼び出しの合間の短い説明が表示されず記録にも残らない現象の原因と回避策。Fable系モデル限定のprogress update仕様を公式ドキュメントとGitHub issueの実測から解説します。
Claude CodeでFable系のモデルを使っていると、ツール呼び出しの合間に書いたはずの短い説明が画面に出ず、セッションの記録(transcript)にも残らないことがあります。原因として有力なのは、Claudeがツール呼び出しの間に書く短い状況説明(progress update)を、APIがtextではなくthinking型のブロックとして返すという仕様です。既定の表示設定ではそのthinkingブロックの中身が空文字になるため、画面にもログにも何も残りません。
progress updateの仕様自体はAnthropicの公式ドキュメントに書かれており、対象はClaude Fable 5・Claude Fable 5.1・Claude Mythos 5.1に限られます。GitHub上では2026年7月にこの現象を実測付きで報告するissueが立ち、複数のユーザーが自分のセッションを解析して数値化しました。何が起きているのか、どの程度の量が消えているのか、Claude Code側でどう回避するのかをまとめます。
症状 — ツール呼び出しの間に書いた文章が画面にもログにも残らない
Claude Codeのセッション記録は、アシスタントの応答をAPIから届いたブロックの並びのままJSONL形式で1行ずつ保存します。この現象が起きたメッセージは、本来あるはずのtextブロックが欠けたまま[thinking, thinking, tool_use]という並びで記録されます。
GitHub issue #74260は2026年7月4日、Claude Code 2.1.201・claude-fable-5(adaptive/interleaved thinking)の環境で報告されました。ターン内でtextブロックのあとにもう1つのthinkingブロックやさらなるツール呼び出しが続くと、そのテキストが画面に表示されず、transcriptのJSONLにも記録されないという内容です。一方で、テキストがツール呼び出しの直前に置かれた[thinking, text, tool_use]という並びや、ターン最後のテキストは正常に表示・記録されます。
| モデルが書いた並び | JSONLに残る並び | 結果 |
|---|---|---|
thinking → text → tool_use(テキストが呼び出し直前) | JSONLに残る並びthinking → text → tool_use | 結果表示・記録される |
thinking → text → thinking → tool_use(テキストが2つのthinkingに挟まれる) | JSONLに残る並びthinking → thinking → tool_use(テキストが消える) | 結果表示も記録もされない |
| ターン最後のテキスト | JSONLに残る並びテキストのまま | 結果常に表示・記録される |
報告者はある作業セッションで、ツール呼び出しの合間に書かれた13個の状況説明のうち12個が画面からもJSONLからも消えていたと記録しています。モデル自身は「印刷したはずのリストを確認しましたか」といった確認を求めてきますが、ユーザー側には何も表示されていません。会話の記録がそのまま消えるため、--resumeでの再開やコンパクション(会話履歴の要約)を経ると、失われたテキストは復元不能になります。
Claude Codeは応答テキストをOpenTelemetryのログイベント(claude_code.assistant_response)に記録する仕組みも持っていますが、これはハーネスが受け取った応答本文を記録する機能です。Claude Code v2.1.193の変更点で追加されたこのログも、API側が最初からthinkingとして返してきた文章までは記録できないと考えられます。
原因として有力なのは「progress update」というAPIの仕様
Anthropicの公式ドキュメントには、モデルがツール呼び出しの間に「たった今何を確認し、次に何をするか」を伝える短い一文をthinkingブロックとして返す「progress update」という仕様が明記されています。プラットフォームドキュメントの「Progress updates between tool calls」は、この仕様の対象をClaude Fable 5.1・Claude Mythos 5.1・Claude Fable 5としており、この一文は独立したsignatureを持つthinkingブロックとして次のtool_useの直前に置かれると説明しています。issue #74260の症状は、このprogress update仕様とthinking.displayの既定値(後述)の組み合わせで説明できるというのが有力な見立てです。ただし報告者自身はこれとは異なる説も主張しています。モデルが消えたはずの文章をあとから逐語で再現できたことを根拠に、テキストはAPIから受け取ったあとハーネス側の描画・保存経路で失われているというものです。issueは未解決のまま開いています。
このthinkingブロックの中身が実際に読めるかどうかは、リクエストのthinking.displayフィールドで決まります。
display | 通常の推論ブロック | progress updateブロック |
|---|---|---|
omitted(これらのモデルの既定値) | 通常の推論ブロック空文字 | progress updateブロック空文字 |
updates(ベータ) | 通常の推論ブロック空文字 | progress updateブロック要約テキスト |
summarized | 通常の推論ブロック要約テキスト | progress updateブロック要約テキスト(推論ブロックと区別不可) |
Claude Fable 5.1・Claude Mythos 5.1・Claude Fable 5・Claude Opus 5・Claude Sonnet 5などではdisplayの既定値がomittedです。設定を変えない限り、progress updateのthinkingブロックはsignatureだけが入り、thinkingフィールドは空文字のまま届きます。Claude Codeがこの値を明示的に上書きしていなければ、モデルが生成した状況説明は空のブロックとして届き、画面には何も描画するものがありません。
{
"content": [
{ "type": "thinking", "thinking": "", "signature": "Eqx..." },
{ "type": "thinking", "thinking": "", "signature": "Es8..." },
{ "type": "tool_use", "id": "toolu_01...", "name": "edit_file", "input": { "...": "..." } }
]
}display: "updates"を指定すると、2つ目のthinkingブロックにだけ要約テキストが入るようになります。ただしこれはベータ機能で、thinking-display-updates-2026-08-18というベータヘッダーが必要です。指定しなければ、未知のdisplay値を渡したときと同じ400 invalid_request_errorになります。この機能はAWS Bedrock・Google Cloud・Microsoft Foundry経由でも同じベータ値で使えます。
同じ挙動は、AWS Bedrockのユーザーガイドでは「Connector text summarization(beta)」という別の名称でも説明されています。Bedrock側の文書はClaude Fable 5のみを対象に挙げ、「ツール呼び出しの間に書かれるテキストはサーバー側で要約され、thinkingブロックとして返される」「顧客側のオプトイン・オプトアウトは無い」と記載しています。Anthropicのプラットフォームドキュメントは対象モデルをFable 5.1・Mythos 5.1まで広げ、同じ仕組みを「progress update」という名称で説明しています。Fable 5の後継であるFable 5.1でも、progress updateの仕組みは仕様として続いています。
どのモデルで、どのタイミングで起きるか
progress updateが発生するのは、会話にtool_resultが1つ以上存在したあと、次のツール呼び出しの直前だけです。最初のツール呼び出しより前に書かれたテキストや、すべてのツール呼び出しが終わったあとの最終応答は対象外で、常に通常のtextブロックとして届きます。
| 状況 | 対象になるか |
|---|---|
| 会話の最初、まだツール呼び出しが1回もない時点のテキスト | 対象になるか対象外(通常のtextブロック) |
| ツール呼び出しのあと、次のツール呼び出し前の短い状況説明 | 対象になるか対象(display設定に従う) |
| すべてのツール呼び出しが終わったあとの最終応答 | 対象になるか対象外(常に通常のtextブロック) |
対象モデルはClaude Fable 5.1・Claude Mythos 5.1・Claude Fable 5の3つだけです。GitHub issueで実測を投稿したユーザーは全員この3モデルのうちFable系を使っており、Claude Opus 4.8・Opus 4.6〜4.7・Claude Sonnet 5・Sonnet 4.6・Haiku 4.5では同じ実測スクリプトでこの兆候がほぼゼロ件だったと報告しています。公式ドキュメントの対象モデル一覧とも一致する結果です。
progress updateが書かれる頻度自体も一定ではありません。公式ドキュメントは「これらのモデルはeffortを上げるほど、また長いツール呼び出しの連鎖ではprogress updateを書く頻度が下がる」と説明しています。effortを上げる調整は、この現象で消える文章の量を減らす方向にも働く可能性がありますが、progress update自体をゼロにする設定ではありません。
どのくらいの量が消えているか — コミュニティの実測
GitHub issue #74260には、複数のユーザーが自分の~/.claude/projects配下のセッションJSONLを走査したスクリプトと結果を投稿しています。いずれもAnthropicが公表した数値ではなく、ユーザー個人の環境を対象にした集計です。
| 報告者の環境 | 走査したFableメッセージ数 | 兆候(thinking, thinking隣接)の割合 |
|---|---|---|
| macOS + Linux VM(2台) | 走査したFableメッセージ数2,936 | 兆候(thinking, thinking隣接)の割合25.3%(744件) |
| Windows 11(2.1.214) | 走査したFableメッセージ数10,334 | 兆候(thinking, thinking隣接)の割合28.7%(2,964件) |
| CachyOS + Debian 13(2台) | 走査したFableメッセージ数25,762 | 兆候(thinking, thinking隣接)の割合27.3%(7,041件) |
| Fedora 44 | 走査したFableメッセージ数1,048ターン | 兆候(thinking, thinking隣接)の割合20.8%(218件) |
対照群として計測されたClaude Opus 4.8・Opus 4.6〜4.7・Sonnet 5・Haiku 4.5では、同じ走査で兆候がほぼゼロ件(数万件中1〜数件、いずれも別要因の誤検出)でした。メッセージ単位の割合はメッセージ全体を分母にするため過小評価になりやすく、ツール呼び出しの合間に何らかの短いテキストが書かれたケースだけに絞った「ブロック単位の損失率」では55〜60%前後という報告が複数の環境で一致しています。つまり、Fableがツール呼び出しの合間に書く短い文章のうち、半分以上がこの経路で消えている計算になります。
実害 — 「見えないだけ」で済まない理由
表示が欠けるだけではありません。記録そのものが欠けます。Claude Codeの--resumeやコンパクションはセッションのJSONLを唯一の正として動くため、画面に一瞬映らなかっただけでなく、あとから読み返しても存在しなかったことになります。
これはモデル自身の判断にも影響します。ある報告では、AskUserQuestionツールの直前にモデルが状況説明を書いたのに表示されず、ユーザーが文脈の分からないまま選択肢を選ぶことになったケースが複数件挙がっています。別の報告では、消えた発言をtranscript上で「一度も送られていない」と誤って確認した結果、実際には説明していたことについて「説明不足だった」という誤った記録がメモリーに書き込まれてしまった例もあります。あるユーザーは、ファイルの既定の削除的挙動について警告する発言が表示されなかったために、その警告に気づかないままツールを実行してしまい、バックアップからの復旧が必要になったと報告しています。
Claude Code側での回避策
Anthropicのプラットフォームドキュメントが示す本来の解決策は、リクエストのthinking.displayフィールドをupdatesにし、ベータヘッダーthinking-display-updates-2026-08-18を付けてprogress updateを要約テキストとして受け取ることです。ここで受け取れるのはあくまで要約テキストで、モデルが実際に書いた元の文章そのものではありません。ただしClaude Codeの変更履歴を確認した範囲では、このベータ機能を採用したという記載は見当たりません。ハーネス側の対応を待つ間、実務では3種類の対処を組み合わせます。
1つ目は、CLAUDE.mdでの誘導です。「ユーザーに見せる必要のある内容は、必ずターン最後の単独テキストメッセージに書く」「AskUserQuestionを呼ぶときは、同じメッセージ内にテキストを同居させない」という指示を加える方法です。ターン最後のテキストは常に生き残るため、実務上の被害の大きい部分を避けられます。ただしこれは誘導であって強制ではなく、モデルがルールに従わなかった場合の抜け道は残ります。
2つ目は、showThinkingSummaries設定です。Claude Codeの設定ドキュメントには、この値が既定で無効になっていること、有効にするとCtrl+Oで展開したときにthinkingの要約が表示されることが明記されています。progress updateもthinking型のブロックである以上、この設定を有効にしておけば、展開時に消えた内容の意訳が見える可能性があります。ただし公式の説明は「redactionは見え方だけを変え、モデルが生成する内容そのものは変えない」というものにとどまり、progress updateの表示切り替えを名指ししたものではないため、必ず復元できるという保証ではありません。
3つ目は、フックによる検知と復元指示です。PostToolUseやStopフックでセッションのJSONLを増分走査し、[thinking, thinking]という隣接パターン(このメッセージIDでテキストが失われた痕跡)を見つけたら、モデルがまだ会話状態として保持している内容をターン最後のメッセージで言い直すよう指示を挟む、というコミュニティ製の実装がGitHub issue上で複数共有されています。この方式には共通の弱点があり、2つのtool_useの間でテキストが消えるパターンには隣接thinkingの兆候が残らないため、検知できません。
MessageDisplayフックでは直せない理由
Claude Codeには応答の画面表示を書き換えるMessageDisplayフックがありますが、この現象の対処には使えません。MessageDisplayフックで応答表示を書き換えるで扱ったとおり、MessageDisplayはdeltaとして渡された文字列を加工するだけの仕組みで、transcriptの内容もClaude自身が参照するテキストも変更しません。今回の現象は、APIがtextブロックではなくthinkingブロックとして返してくる(と考えられる)ケースなので、MessageDisplayに渡すdelta自体が存在せず、書き換える対象がありません。
もう一つの近縁の話題として、adaptive thinkingでは一部のターンでthinkingブロックそのものが出ないことがあるという正常な挙動もあります。ただしそちらはモデルが簡単だと判断して思考自体をスキップする話で、今回のテーマとは別物です。今回は思考ではなく、ユーザー向けの短い発言がthinking型のブロックに変換されて中身が空になる現象を指します。
まとめ
Claude Codeで応答の一部が消えるように見える現象は、Fable系モデルがツール呼び出しの合間に書く短い状況説明(progress update)を、APIがthinking型のブロックとして返す仕様が原因として有力です(issueの報告者はハーネス側の描画・保存経路の問題という説も唱えており、issueは未解決のまま残っています)。既定の表示設定ではその中身が空文字になるため、画面にもセッション記録にも何も残りません。Anthropicはdisplay: "updates"というベータオプションを用意していますが、Claude Code自身がこれを使っているという記載は見当たらず、当面はCLAUDE.mdでの誘導とフックによる検知が現実的な回避策になります。ツール呼び出しを挟む長いターンで「説明したはずなのに伝わっていない」と感じたら、対象モデルと発生タイミングをこの記事の早見表で確認してみてください。起動やMCP接続など、Claude Codeでほかによく起きるエラーはClaude Codeでよくあるエラー10選にまとめています。