Claude Sonnet 5.5でtool間の表示が消える原因と直し方

結論：表示欠落はstream parserとthinking設定を先に切り分ける

一次情報はClaude Sonnet 5.5公式What's newとPreserved thinking公式ドキュメントです。モデルの基本上限・料金は公式モデルページで確認します。既存のClaude Codeの出力上限ガイドがCLIの保存上限を扱うのに対し、この記事はAPI streamingのblock処理に限定します。

何が変わったかを3層で比較する

層	確認すること	典型的な症状
API契約	thinking、effort、block type、account	400、block drop、会話継続失敗
stream parser	thinkingとtext、tool use/resultの分岐	tool間だけ画面が無言
UI表示	display値、進捗表示、最終text	処理中か判断できない
監査保存	request ID、model、block種別、権限	再現できず原因不明

「thinkingは内部情報だから表示しない」という設計と、「tool間の利用者向け進捗まで捨てる」ことは同じではありません。UIへそのまま思考内容を表示する必要はありませんが、公式仕様に沿って安全な進捗要約をdisplayへ出すか、処理中表示を別に作るかを決めます。監査ログには生の秘密や不要な内容を保存せず、block種別とrequest IDを中心にします。

表示が消える時の8手順

1. 処理が止まったかを分ける。requestの完了、tool実行、usage、stop reasonをログで確認し、画面だけの欠落か判定します。
2. 生streamを一件保存する。個人情報を除いたfixtureで、content blockのtypeと順序を記録します。
3. textだけの分岐を検索する。parserがthinking、tool_use、tool_resultを無視していないか確認します。
4. Sonnet 5.5を固定する。model ID、provider、SDK version、effortをログへ残します。
5. thinking設定を試す。disabledを送っていないか調べ、前倒し思考を止める場合はbetween_toolsを公式条件の範囲で試します。
6. displayを分けて実装する。利用者へ見せる短い進捗と、監査に残すblockメタデータを別のフィールドにします。
7. 会話を新規で再試験する。別modelや別accountが生成したthinking blocksを混ぜず、同じaccountで一往復ずつ確認します。
8. fallbackを決める。未対応blockは安全に処理中表示へ切り替え、無言のまま長時間待たせないタイムアウトを置きます。

手順1で最も重要なのは、画面の沈黙をAPI障害と決めつけないことです。toolが実行され、最終回答が返っているなら、まずUIのblock分岐を直します。逆に400ならthinking設定、tool_choice、effortの組合せを公式のエラー条件で見直します。異なる原因を同じretryに入れると、コストと処理時間だけが増えます。

between_tools・adaptive・表示の選び方

選択	向く場面	注意点
adaptive	高いeffortや思考深度を使う通常運用	thinking blocksをparserが扱う
between_tools	前倒し思考を止め、tool間で進める運用	高い条件や他の設定との組合せを確認
処理中UIを別表示	thinking本文を利用者へ直接出さない設計	block typeを捨てず状態だけ表示

between_toolsを万能な互換設定として使わないでください。公式文書ではeffortの範囲、会話途中の変更、display以外のフィールド、manual budgetの扱いに制限があります。目的が「表示を戻す」ならparserとUIを直し、目的が「前倒し思考を止める」なら設定変更を別の変更票にします。2つを同時に変更すると、改善の原因を説明できません。

企業運用チェックリスト

• 生streamのfixtureから個人情報と秘密を除いた。
• block typeごとの受信・保存・表示ルールがある。
• thinking本文を利用者へ無加工で表示しない。
• 処理中、tool承認、完了、失敗の状態をUIで区別した。
• model、provider、account、conversation、request IDを追跡できる。
• between_toolsとadaptiveの採用理由を記録した。
• 別accountのthinking blocksをそのまま再利用しない。
• timeout、fallback、再試行で課金と安全性を確認した。

よくある質問

tool間の表示が消えるのはAPI障害ですか？

処理と最終回答が成功しているなら、stream parserがthinking blocksをUIへ渡していない可能性があります。まず生streamとtool実行ログを比較します。

displayを入れればthinking本文を表示できますか？

利用者向け表示は、公式のdisplay仕様と自社の安全基準を確認して設計します。生のthinkingをそのまま公開するのではなく、短い状態表示と監査メタデータを分けます。

別アカウントの会話を引き継げますか？

Sonnet 5.5のthinking blocksは生成元またはリンクされたアカウントに結び付きます。別アカウントではblockがdropされ得るため、新規会話や公式の再構成手順を確認します。

障害対応の記録には「表示が消えた」という利用者の言葉だけを残さず、発生時刻、model ID、provider、SDK、request ID、最後に表示されたblock、toolの完了状況を記載します。これらがそろえば、APIの400、streamの解析漏れ、UIの状態管理、account条件のどこで再現するかを切り分けられます。再試行前に一件の生streamを保全すると、原因を上書きしません。

安全運用では、thinking blocksの本文を長期保存することが目的にならないようにします。利用者が必要とするのは処理が続いているか、承認が必要か、いつ終わるかであり、内部データをすべて画面へ出すことではありません。表示用の短い状態、監査用のblock種別、サポート用のrequest IDを分け、保持期間と閲覧権限をそれぞれ決めます。

公式情報と次の一歩

blockの挙動はSonnet 5.5公式What's new、会話継続の条件はPreserved thinkingを公開直前にreadbackします。移行全体はSonnet 5.5移行ガイド、tool設計はinline toolsとMCPガイドも参照できます。表示・監査・権限の境界が曖昧なら、Miraigentの無料診断で再現fixtureから整理します。