結論
Opus 4.8（claude-opus-4-8）固有のバグ。ツール呼び出しの内部マークアップから名前空間プレフィックスが欠落し、パーサが弾いて会話が止まる。GitHub に複数の issue が上がっており、モデルを Sonnet 4.6 に切り替えると即座に解消する。
| 状態 | 対処 |
|---|---|
| Claude Code が「malformed」エラーで止まる |
/model で Sonnet 4.6 に切り替え |
| 4.8 のままで減らしたい | ツール呼び出し前の前置き文を書かない |
| 環境・設定の問題かどうか疑っている | そうではない。モデルレベルのバグ |
前提：どんな状況で起きたか
私の環境：
- Claude Code（CLI）、macOS
-
/compactで圧縮した長いセッション - 複雑な Bash コマンド（パイプ・正規表現・日本語混在）を多用
症状は「ツール呼び出しを実行しようとした瞬間に会話が固まり、エラーメッセージが出る」というもの。1セッションで何度も繰り返し発生した。
最初に疑ったこと（全部ハズレだった）
① HTML ペイロードが大きすぎる説
前の作業で大きな HTML ファイルを生成していたので、「コンテキストが重くなりすぎた」と疑った。→ ハズレ。小さなコマンドでも同じエラーが出た。
② RTK フック説
グローバル設定でコマンドラッパーを使っており、「フックが干渉している」と疑った。→ ハズレ。フックはコマンド出力の後に動くため、ツール呼び出し前の崩れとは無関係。
③ foreground sleep でブロックされている説
別の問題（sleep コマンドを前景実行するとハーネスが固まる）と混同していた。→ ハズレ。別の現象。sleep なしでも起きていた。
④ コンテキスト長が限界説
/compact 直後でも起きたため否定。
真因：Opus 4.8 のシリアライズバグ
小さな echo コマンドだけ実行しようとしたときも同じエラーが出た。これで「環境側」の説明がすべて崩れた。
エラーの形式：
Your tool call was malformed and could not be parsed.
内部的に何が起きているか：Opus 4.8 が stop_reason=tool_use を返すにもかかわらず、レスポンスの content 配列にツール呼び出しブロックが入っていないことがある。パーサが弾いてテキスト出力になり、会話が止まる。
正常なら内部マークアップに存在すべき名前空間プレフィックスが、間欠的に欠落する。
GitHub で確認した issue
海外フォーラムも含めて調べたところ、複数の独立した報告が見つかった。
Issue #67295（私の状況と完全一致）：「/compact 済みの長いセッションで malformed stall が多発する、claude-opus-4-8、macOS」
Issue #68510：「Opus 4.8 で頻繁に malformed エラー。回避策：4.7 に切り替え」
Issue #63604：「Opus 4.8 は malformed tool_use を繰り返す。4.7 では再現しない」
Issue #66400：「ツール呼び出しが失敗し、マークアップがチャット文字として描画される」
複数のユーザーが「4.7 または Sonnet に切り替えたら止まった」と確認している。
上記の GitHub issue は私が実際に検索して確認した一次情報です。Anthropic の公式アナウンスではなく、ユーザー報告として受け取ってください。
悪化する条件
報告を読み合わせると、次の条件が重なると頻発しやすい：
-
/compact後の長いセッション（圧縮でコンテキスト構造が変わる） - ツール呼び出しの前に前置き文を書く（「では実行します」などの説明をしてからツールを呼ぶパターン）
- 複雑な Bash（パイプ・エスケープ・日本語混在）
逆に言えば、単純なセッションや新しいセッション開始直後は出にくい。
回避策
根本解決：モデルを切り替える
Claude Code の入力欄で /model を入力し、Sonnet 4.6（または Opus 4.7）を選択する。これで問題は発生しなくなる。
Sonnet 4.6 はファイル編集・コード生成・Bash 実行といった日常的なコーディング作業なら十分な品質がある。Opus 4.8 の停止問題のほうがコストが高い。
部分緩和：前置き文を書かない
4.8 のまま使い続ける場合、「ツール呼び出しの前に説明文を書く」パターンを避けると頻度が減る。ただし根絶はしない。
補助：新しいセッションで再開
長い /compact 後ほど出やすいため、重い作業の前に新しいセッションを開く。
この経験で気づいたこと
バグの調査中、私は最初「自分の環境のせい」と思い込んでいた。設定を疑い、フックを疑い、コンテキストサイズを疑った。
でも実際はモデルレベルの既知バグだった。GitHub を調べてみれば5分でわかった。
AI ツールをビジネス・業務に組み込んでいると、トラブルが「自分の設定ミス」なのか「ツール側のバグ」なのかを切り分けることが重要になる。最も速い切り分け方：
-
最小の操作で再現するか試す（今回は
echoだけで確認できた） - 他の環境・設定で試す（モデル切り替えで消えた）
- 公開 issue を検索する（ほぼ確実に先人がいる）
この順番で動けば、1時間以内に真因にたどり着ける。
まとめ：今日やること
- Claude Code で止まる現象が出ていたら
/modelで Sonnet 4.6 に切り替える - 長いセッションを始める前に
/compact→ 新セッション開始を習慣にする - トラブルが起きたら「自分の設定」より先に「ツールの既知バグ」を疑う
AI ツールを業務に組み込む設計について実験ログを書いています。