Claude Opus 5のnarrationでツール間の文章が見えない — 確認と対処

Claude Opus 5(claude-opus-5)とOpus 5.5で、ツール呼び出しの合間にモデルが書く経過説明(narration)がtextブロックではなく、サーバーが要約したthinkingブロックとして返る報告があります。要約は言い回しを変え、コードブロックを落とします。Desktopアプリはこのブロックを描画しません。ユーザーの画面に何も出ないのに、モデルは「上のコマンドを実行してください」と書いて、ターンを終えます。

GitHubのissue #95764(2026年9月21日起票・open)と#97504に、この現象の報告と集計があります。公式ドキュメントの記述と並べて見ていきます。

何が起きているのか — textのはずの文章がthinkingで返る

#95764の報告者は、2026年9月11日の02:00 UTC頃を境に、Opus 5(effort xhigh)の挙動が変わったと書いています。ツール結果のあと、次のツール呼び出しの前に書く文章が、textブロックではなく要約入りのthinkingブロックになるという内容です。

報告者は60日分・約5.7万件のアシスタントメッセージを自分のJSONLから集計しました。ツール呼び出しを含む「続きの応答」のうち、要約ブロックになった割合は日によって大きく動きます。

切り替わりの基準は日付で、クライアントのバージョンではありません。9月9日の2.1.267は0%で、9月11日の2.1.266は79%でした。ターンの最初の応答は影響を受けません。

要約は、元の文章の言い換えです。報告者の例では、一人称で「〜を案内しました」と過去形に書き換えられ、モデルが書いていない案内を済ませたかのように読めます。

公式ドキュメントが説明している仕組み

プラットフォームドキュメントの「Progress updates between tool calls」節は、この仕組みを仕様として書いています。対象はFable 5.1・Mythos 5.1・Opus 5.5・Sonnet 5.5・Fable 5の5モデルで、ツール呼び出しの間に書く「いま見つけたことと次にすること」の一言が、独立したsignatureを持つthinkingブロックで返ります。

読めるかどうかはthinking.displayの値しだいです。

"updates"にはベータヘッダーthinking-display-updates-2026-08-18が要ります。#95764によると、Claude Code 2.1.278は既定でこのdisplay: "updates"をリクエストしています。同じ節には、受け取るテキストは「通常1〜2文の要約」で、長さに頼らないよう書かれています。出力トークンは要約の長さではなく、元の長さで数えられます。

Opus 5.5のプロンプトガイドも同じ点を指摘しています。Opus 5.5の進捗メモはtextではなくthinkingブロックで返るため、textだけを描画するクライアントは長いエージェント処理の間、無言に見えます。

Opus 5は公式の対象一覧に入っていない

ここに食い違いがあります。報告のきっかけはOpus 5でしたが、公式のprogress update節が名指しするのはOpus 5.5で、Opus 5は載っていません。#95764の後続コメントは、Opus 5.5でも同じ症状を報告しています。ある報告者の集計では、9月23日以降に4回以上ツールを呼んだOpus 5.5のターン318件のうち、307件で後続バッチの4割以上が要約ブロックでした。同じ集計でOpus 5は5ターンで0件でしたが、標本が小さく、影響がないとは言えません。

画面で何が起きるか — 「言ったはず」が通らなくなる

起票者がDesktopアプリで経験した事例が2つあります。

• 事例A(9月16日):自動モードの分類器にコマンドを拒否されたあと、モデルは「提示したコマンドを実行してください」とだけ告げました。コマンド本体はどのtextブロックにもなく、ユーザーは「また命令を教えてくれなかった」と返しています
• 事例B(9月21日):「2通りの方法を案内しました」という要約だけが返り、ユーザーは「いつ案内した?」と聞き返しました。コマンドが届いたのは3回目で、ユーザーが出力を求めたあとです

起票者によると、CLIは要約ブロックを通常のテキストとして描画しますが、Desktopアプリは描画しません。モデルの手元には元の全文が残ります。そのためモデルは「見せた」と信じたまま、ターンを終えます。

別の報告者は、Desktopアプリのコードタブでターンの最後にwrap_upを呼ぶ構成だと、本来の回答がその直前の「ツール間の文章」に当たり、要約ブロックにされると書いています。2026年10月18日のセッションで11件がこうなり、4件がユーザー向けで、そのうち2件には実行すべきシェルコマンドが含まれていました。症状は毎回ではなく、断続的です。

#97504は同じ現象をVS Code拡張の側から報告しています。Opus 5.5・Claude Code 2.1.283・Windows 11で、AskUserQuestionの直前の文脈説明が非空のthinkingブロックに入り、textブロックがない形です。1日分12件の記録のうち、ツール呼び出しを含む1,371件の応答の8.5%(117件)がこの形でした。通常の推論ブロックも数に入るため、8.5%は上限の値です。手で確認した1セッションでは非空のthinking12件がすべてユーザー向けのメッセージでした。

起きているか確かめる方法

画面の見た目では判定できません。要約が元の語を引き継いでいると、逐語に見えることがあるためです。コメントの報告者は、JSONLのsignatureをデコードして見分ける方法を共有しています。thinkingブロックのsignatureをbase64で読み、narrationの文字列が入っているかを見ます。署名つきで中身を読めないthinkingブロックの扱いは、redacted_thinkingブロックの記事が扱っています。

import base64
 
def is_narration(block):
    if block.get("type") != "thinking":
        return False
    sig = block.get("signature") or ""
    try:
        raw = base64.b64decode(sig + "=" * (-len(sig) % 4))
    except Exception:
        return False
    return b"narration" in raw

この関数をセッションのJSONL(~/.claude/projects/配下)の各メッセージのcontentブロックに当てます。同じmessage.idの応答にtextブロックがなく、narrationのブロックだけがある応答が、ユーザーに届かなかった可能性のある応答です。これはissue上の判定法で、公式が保証する識別方法ではありません。

claude -pの--output-format stream-json --verboseで見るなら、起票者はstream-jsonのスキーマにあるnarration_block_indexesを手がかりにしています。このフィールドは、サーバーがnarrationと印を付けたthinkingブロックの位置を指します。

いま取れる対処

どれも根本対策ではなく、ユーザーへの伝達漏れを減らす手段です。

環境変数のオプトアウトは当てにならない

起票者は、CLAUDE_CODE_THINKING_DISPLAY_UPDATESをfalseにするとdisplay: "updates"のリクエストが止まる、とクライアントの実装から読んでいます。コマンドラインの再現ではfalseの1回だけtextで届きました。ただし1回の試行で、証明にはなりません。

別の報告者がClaude Code 2.1.286でsettings.jsonのenvに同じ値を入れましたが、要約ブロックは出続けました。

{
  "env": {
    "CLAUDE_CODE_THINKING_DISPLAY_UPDATES": "false"
  }
}

同じコメントは、単純な「軽いツール呼び出しだけを頼む」テストでは要約が出にくく、オプトアウトが効いたように見えると警告しています。効果の判定は、実際の作業ターンで集計して行います。この環境変数は、Claude Codeの公式の環境変数ページに載っていません。

結果を最終メッセージに寄せる

2つの報告者がたどり着いた原則は同じで、ユーザーに届けたい内容を、ターンを終えるテキストに入れることです。ある報告者は、グローバル指示に「テキストでターンを終える。テキストを書いたあとにツールを呼ばない。作業が残っている間はテキストを書かない」という規則を入れています。「最終メッセージに全部書く」という言い方は、書く時点でどれが最後になるか分からず、失敗したそうです。進捗の報告をツール結果と照合させる指示文の書き方は、Fable 5の進捗報告の記事にあります。

Opus 5.5のプロンプトガイドは、API利用者向けに別の手を書いています。部分的に逐語で渡したい内容(コードなど)があるなら、ユーザーへメッセージを送るだけのツールを用意し、その内容にだけ使うよう伝えます。ツールはセッションの最初のリクエストから宣言しておきます。後から足すと、会話の先頭が変わり、過去のthinkingブロックが無効になるからです。

フックで取りこぼしを検知する

起票者と別のコメント投稿者は、フックの自作を共有しています。

• PreToolUseのAskUserQuestionフック:質問の本文に「上のコマンド」としか書かれておらず、コードブロックを含まなければ拒否する
• Stopフック:ターンの最後の本文が短い(150字未満)のに、その応答にnarrationブロックがあるなら、一度だけ停止を止め、要約を引用して言い直しを促す

起票者が30日分の記録に当てたところ、前者は924件中27件、後者は913件中1件に反応し、どちらも実際の事故でした。後者の投稿者は、長い最終メッセージが失われた答えを繰り返さないケースは拾えない、と限界も書いています。

Opus 5.5のnarration問題は修正されたか

修正済みとは言えません。#95764はopenのままで、報告はDesktopアプリ・VS Code拡張・CLIにまたがっています。Fable系で同じ構造が指摘された経緯とdisplay設定の詳しい仕組みは、Claude Codeの応答が消える理由にあります。

まとめ

ツール呼び出しの間に書かれた文章は、Opus 5.5(報告ではOpus 5も)でtextではなく、要約されたthinkingブロックになることがあります。Desktopアプリはこれを描画せず、モデルは元の全文を持ち続けます。コマンドや一覧など、ユーザーが実行する内容を頼むときは、ターンを終えるメッセージに入っているかを、画面ではなくJSONLのsignatureで確かめるほうが確実です。