作業中のClaudeが、突然こう書き始める。
call
<invoke name="Read">
<parameter name="file_path">...</parameter>
</invoke>本来なら画面の裏側で処理されるはずの、ツールへの命令が、普通の返答としてチャット画面へ流れ出す。ツールは動かない。Claudeは作業の途中で止まり、もう一度促すと、また同じような文字列を吐く。
筆者の環境では、callが出始めたあと、返答の中へ縦にcallが連打され続けたことがある。画面は固まらなかった。しかし気づいた時には、スレッドの約3分の2がcallという文字だけで埋まり、会話を続けられる状態ではなくなっていた。長く育てたスレッドだったが、最後は捨てるしかなかった。
invoke型の実害は、さらに分かりやすい。作業の途中でツールの実行が容赦なく止まる。調査も実装も検証も、その先へ進まない。
もう一つ、よく似た異常がある。
「これはこういう文脈。ユーザーはこう考えているので、否定しない口調で発言する」——そんな、回答を作る前の判断メモにも見える文章が、読者へ向けた返答の中へそのまま現れる。こちらは画面が固まらないことも多い。しかし一度始まると、同じスレッドで繰り返す。
筆者は後者を、便宜的に「サトラレ現象」と呼んでいる。
この二つが同じ原因だと証明されたわけではない。それでも、利用者の目に見える現象には共通点がある。本来は裏側にあるはずの命令や判断らしき情報と、読者へ届ける文章の境目が崩れている。
そして厄介なのは、異常な一文そのものより、異常が会話履歴へ残ったあとである。
invokeや内部メモのような文章が初めて出たら、そのスレッドで何度もやり直さない。最初におかしくなったClaudeの返答、その一つ前にある自分の発言から「ここからフォーク」する。 壊れる前の文脈だけを、新しい分岐へ持っていく。
正常なら、ツールへの命令は「返答の文章」には出てこない
tool_useとtextは別の形式で扱われる。境界が壊れると、命令文がそのまま画面へ漏れる。
- 次に何を調べるか判断
- 専用形式で命令を渡す
- アプリが実行する
- 結果を受け取る
本来ここには来ないはずの<invoke>が、そのまま画面へ現れる。
Anthropicが公開する仕様では、Claudeがツールを使う時、命令はtool_useという専用の形式でアプリへ渡される。アプリがツールを動かし、その結果をtool_resultとしてClaudeへ返す。
利用者が読む文章はtextとして別に扱われる。思考機能を使う場合も、思考を表すthinkingと、最終的な返答であるtextは分かれている。
つまり、本来の流れはこうだ。
Claudeが、次に何を調べるかを判断する
ツールを動かすための命令を、専用形式の
tool_useとして返すClaude.appやClaude Codeがツールを実行する
結果を受け取り、利用者向けの文章を返す
画面へ裸の<invoke>が見え、ツールが動かないなら、少なくともこの流れどおりには処理されていない。
“サトラレ”についても、少し慎重に見た方がいい。Anthropicの公式資料によれば、利用者へ見せる思考表示は、生の思考過程そのものではなく要約である。Opus 4.7、4.8、5を含む新しいモデルでは、思考の文章を返さない設定が標準になっている。
だから、画面へ現れた「ユーザーを否定しない口調で返す」といった一文を、Claudeの秘密の思考をそのまま読んだと断定することはできない。Claudeが説明文のように作ってしまったのかもしれない。システム通知や利用者の発言に似た文章を、誤って返答へ混ぜた可能性もある。画面へ出す情報の種類を、アプリ側が取り違えた可能性も残る。
分かるのは、「読者へ返すべき文章」と「それ以外に見える文章」の境界が、利用者の画面では壊れていることだ。
AI Agentにとって、文脈は「過去」ではなく現在の作業環境である
なぜ、たった一度の異常出力を急いで隔離する必要があるのか。
AI Agentという存在にとって、文脈は単なる会話記録ではないからだ。
Anthropicは「コンテキストウィンドウ」を、モデルが返答を作る時に参照する作業記憶だと説明している。そこには、最初の指示、使えるツール、ツールの実行結果、利用者とのやり取り、そしてClaude自身がさっき返した文章まで入る。
つまり、いま画面に出たClaudeの返答は、次の返答を作るための材料になる。
私たちは日常会話で、これを「文脈を学習した」と表現することがある。
もちろん、人間のように経験を恒久的に覚え、モデルそのものが成長しているわけではない。スレッドを閉じ、その文脈を次へ渡さなければ、この状態は失われる。
それでも、同じスレッドの中では、そこにある言葉、判断、例、書き方に合わせて、次の応答が変わる。技術的には、これをin-context learning（文脈の中での学習）などと呼ぶ。
例えば、ある話題についてClaudeが一度、強い否定的な意見を書いたとする。
次の返答では、その意見も「この会話ですでに決めたこと」のように扱われる。新しい証拠や、考え直すよう明確に促す言葉がなければ、前の立場を頑なに守っているように見えることがある。
これは「LLMは絶対に前言を撤回しない」という意味ではない。ただ、過去の発言が次の発言の材料になるという性質は、Claudeだけでなく、会話型のLLMに広く見られる。
その長所が、異常時には裏返る。
Claudeは、正しい手順や利用者の好みだけを拾うわけではない。返答へ漏れたcallや<invoke>も、「このスレッドで自分が使った書き方」として次の材料に入ってしまう。
次の返答でまた同じ形が出る。すると、その二度目の異常も、その次の材料になる。
これが直接の原因だとするAnthropicの公式な説明は、まだ出ていない。ただ、異常の直後は再発が増えたという利用者の集計や、筆者が経験したcallの増殖を見ると、文脈から学ぶ力が、悪い方向へ回り始めたと考えると理解しやすい。
うまく動いている時：判断、訂正、好み、作業手順が積み上がり、Agentとの仕事が噛み合っていく。
おかしくなった時：壊れた命令文まで次の材料になり、同じ異常を繰り返す可能性がある。
「当事者として知っている」と「引継書から読む」は、同じではない
壊れた書き方も文脈として学習され、繰り返すほど会話を埋めていく。
- 約33%異常の直後に再発
- 最大75回連鎖したスレッドの例
- 約3分の2callで埋まったスレッドの分量
作業中の文脈を守ることが重要なのは、AI Agentが結論だけを扱っているわけではないからだ。
一つの機能を完成させるまでに、失敗する。原因を疑う。別の方法を試す。また失敗する。条件を一つ変え、ようやく成功する。
同じスレッドで作業してきたAgentには、その一連の流れが残っている。
どの案が、どの条件で失敗したか
成功前に、何を勘違いしていたか
利用者が、どの違和感を強く指摘したか
最後の成功が、偶然ではなく何の変更で生まれたか
新しいスレッドへ移り、成功した手順だけを書いた引継書を読ませることはできる。けれど、結論だけを読むことと、そこへ至る試行錯誤を同じ文脈の中で辿ってきたことは、運用上まったく同じではない。
ここでいう「当事者」は、AIに人間と同じ主観的な経験や自伝的記憶がある、という意味ではない。失敗、ツールの結果、利用者からの訂正、最後の成功、自分が出した判断が、切れずに同じ文脈へ残っている状態を指している。
その状態なら、新しい問題が起きた時に、「これは前に失敗した時と似ている」と拾いやすい。
引継書から始める場合は、まず正しい資料を見つけ、必要な箇所を読み、それが今回の作業とどうつながるのかを、もう一度組み立て直さなければならない。
答えが同じ場所に書かれていることと、Agentがその答えを今の判断へ使えることは、別の問題である。
外へ残す記憶は必須。でも、生きた文脈の代わりにはならない
どれか一つでは足りない。三つが揃って、AI Agentとの仕事は途切れにくくなる。
試行錯誤の順序、判断の重み、直近の作業状態
スレッドを越えて残す事実・手順・禁止事項
壊れた返答だけを切り離す
筆者の運用では、skill、Obsidian、プロジェクト管理ツール、正本となる資料へ、作業内容、成功した手順、失敗例、次へ引き継ぐ判断を残している。
これは絶対に必要だ。一つのスレッドだけを記憶の正本にすれば、スレッドの破損、モデル変更、端末移動、文脈の上限によって、組織の経験まで消えてしまう。
ただし、外へ記録してあるから、生きた文脈を失っても影響はない——とも言えない。
Claude Codeは文脈がいっぱいになると、古いツールの結果を整理し、長い会話を要約へ置き換える。公式資料も、会話の早い段階にあった細かな指示は失われることがある、と説明している。
要約の後に、自動で読み直される情報もある。プロジェクトの一番上にあるCLAUDE.mdや自動memoryは戻る。一方、下位folderにあるCLAUDE.mdやfile別のruleは、関係するfileをもう一度読むまで戻らない。topic別のmemoryも、必要だと判断して読みに行かなければ使われない。skillにも、一度に読み戻せる量の上限がある。
つまり、「どこかに書いてある」は必要条件であって、十分条件ではない。
筆者の環境では、会話の要約やスレッド変更のあと、Claude Codeが必要な資料をすべて読み戻せず、記録してある失敗をもう一度踏むことが少なくない。これは全利用者、すべてのversionへ当てはまる統計ではなく、複数のプロジェクトを継続してきた中での実感である。
それでも、長い会話は要約されること、情報によって読み直される条件が違うこと、一度に戻せる量にも上限があることを考えれば、なぜ起こり得るのかは見えてくる。
いまの会話：試行錯誤の順序、判断の重み、直近の作業状態を保つ。
外部の正本：スレッドを越えて残すべき事実、成功した手順、禁止事項を記録する。
きれいな分岐：それまでの文脈を保ったまま、壊れた返答だけを切り離す。
外部の記録か、長いスレッドか。どちらか一つを選ぶ話ではない。
大事なことは正本として外へ残す。それでも作業中は、生きた文脈をできるだけ守る。異常が混ざった時だけ、正常だった最後の地点から分岐する。
この三つが揃って初めて、AI Agentとの仕事は途切れにくくなる。
個人の環境だけで起きた話ではない
「自分のMacだけがおかしいのでは？」と思うかもしれない。
しかしAnthropicのClaude Code公式repositoryには、2026年5月以降、Opus 4.7や4.8がツール命令を普通の文章として出してしまう、という報告が複数ある。
macOS上のOpus 4.8を調べたissue #74063では、court、count、course、callのような短い文字列に続いて、<invoke>と<parameter>が現れた。
報告者が手元の会話記録を調べたところ、Opus 4.8では6,400件のClaudeの返答のうち113件が該当したという。これはAnthropicが公表した発生率ではなく、一人の利用環境での集計である。それでも、一枚のスクリーンショットだけよりは状況が見えやすい。
同じ報告では、異常な返答の次も約33%の割合で再び崩れ、最悪のスレッドでは75回連鎖したとされている。
別の報告では、システム上は「ツールを使う」と判断しているのに、実際には専用形式のtool_useがなく、<invoke>を含む普通の文章だけが返っていた。アプリには実行できる命令が届かない。だからツールも動かない。
macOS版のClaude Codeで、画面が“invoking”のまま止まるという報告もある。長いスレッドだけでなく、比較的軽い会話で起きた例もあるため、「会話が長すぎたせい」と決めつけるのも早い。
“サトラレ”とまったく同じではないが、よく似た報告もある。Claude自身の返答に、Human:やシステム通知、作業通知を装った文章が混ざり、その後の会話で本物の履歴のように扱われたというものだ。
これらがすべて同じ原因だと証明されたわけではない。それでも、裏側にあるはずの命令や役割をまねた文章が返答へ混ざり、そのまま次の文脈へ残るという問題は、筆者だけの見間違いではない。
なぜ「もう一回やって」が危ないのか
成功、失敗、修正の履歴を一つずつ別の器へ移す。スレッドの障害と、そこで育った経験は分けて扱える。
ツールが動かなければ、普通は「続けて」「もう一度」と言いたくなる。
一回だけなら、次はうまく動くこともあるだろう。けれど、残しておきたい大事なスレッドでは、そこで一度立ち止まった方がいい。
LLMは、それまでの会話を材料にして次の返答を作る。異常な<invoke>がClaudeの普通の返答として保存されれば、それも「この会話で以前に使った書き方」の一つになる。
それが再発の直接原因だとするAnthropicの原因分析は、まだ公開されていない。利用者の間で使われる“self-poisoning”という呼び方も、確定した技術用語ではなく仮説である。
それでも、異常の後に連鎖が増えたという会話記録の集計や、偽の通知文が後の会話で本物のように扱われたという報告は、この見方とよく合う。
だから運用上は、原因の確定を待たずに隔離できる。
最初の異常出力を、会話の境界線にする。
新しいスレッドを作れば直る。でも、それでは失うものが大きい
新しいスレッドを開き、最初から説明し直せば、異常な履歴は持ち込まれない。
しかし、長く開発や相談を続けたスレッドには、指示文へ書き直しにくいものが積み上がっている。
なぜ現在の設計を選んだか
すでに試して失敗した方法
利用者が大事にする言葉と、避けたい表現
細かな例外、過去の修正、暗黙の優先順位
どこまで任せ、どこで確認を挟むかという協働の呼吸
これは単なる文字の束ではない。仕事の途中で育った、文脈という資産である。
異常が一度出ただけで全履歴を捨てるのは、破れた一頁のためにノート一冊を燃やすようなものだ。
復旧手順──最初の異常の「一つ前」から分岐する
最初の異常より後ろの文脈は持ち込まず、正常だった地点だけを新しい分岐へ運ぶ。
- 会話1
- 会話2
- 直前の発言
- 最初の異常
Claude.appで筆者が使っている復旧法は、異常をその場で直そうとするのではなく、まだ壊れていなかった地点から会話を分岐させる方法である。
1. その場で止める
invoke、call、court、parameterが不自然に見えた。あるいは、回答前の判断メモのような文章が出た。そのスレッドでは追加指示を送らない。
ツール実行中に出る通常の状態表示と、Claudeの返答そのものに生の命令文が現れた状態は分けて考える。迷ったら、ツールが本当に動き、結果が返ったかを確認する。
2. 証拠を残す
スクリーンショット、発生時刻、選んでいたモデル、Claude.appのversion、直前に使おうとしたツール、スレッドのおおよその長さを残す。外部へ報告する時は、秘密情報、local path、顧客情報を必ず隠す。
3. 最初におかしくなった返答を見つける
連打が始まった最後の返答ではない。初めてツール命令や内部メモらしき文章が出た、Claudeの返答まで戻る。
4. 直前の自分の発言からフォークする
最初におかしくなったClaudeの返答。その直前にある自分の発言bubbleでフォークの印を押し、「ここからフォーク」を選ぶ。
分岐点を異常な返答より後ろに置いてはいけない。壊れた文章まで新しい分岐へ含めれば、隔離したことにならない。
Anthropicも、会話の分岐をClaude Codeの公式機能として案内している。Agent SDKの仕様でも、元の会話を残したまま、指定した発言までを別のスレッドへ複製できる。つまり「正常だった地点までを救う」という使い方は、この機能の仕組みに合っている。
5. 必要な通常文だけを戻す
異常が出てから気づくまでの間に、残したい相談や判断がある場合もある。その時は、普通の日本語文だけを手作業で新しい分岐へ戻す。
<invoke>、<parameter>、システム通知のような文、話者を示すlabel、出力前の方針らしき文は貼らない。
6. 小さく確認する
復旧直後から重い作業を再開せず、fileを一つ読む程度の小さく安全なツール操作を一度だけ試す。ツールが正常に動き、結果を受けて返答が続けば、本作業へ戻る。
新しい分岐でも同じ異常が出た場合は、そこで何度もやり直さない。モデルの切り替え、使っていない連携ツールの停止、アプリの更新、新しいスレッドへの最小限の引き継ぎを検討する。
止める──そのスレッドでやり直さない
残す──画面と発生条件を記録する
探す──最初におかしくなった返答へ戻る
分ける──その一つ前からフォークする
戻す──必要な普通の文章だけ移す
試す──小さく安全な操作で確認する
「感染」は比喩。勝手に別のスレッドへ移るわけではない
壊れたツール命令を別のスレッドへそのまま貼ると、そちらでも似た出力が始まることがある。利用者から見ると、bugが“感染”したように見える。
ただし、virusやmalwareのように、異常が自分で別のスレッドへ移動しているわけではない。
貼り付けた命令文が、新しい会話の材料や見本になる。Claudeがそれを「ここで使う書き方」だと受け取れば、似た形をもう一度出す条件を、利用者側が持ち込んだことになる。
だから、別のスレッドへ引き継ぐ時も、異常な返答を丸ごとコピーしない。
何をしていたか
どこまで完了したか
次に何をするか
異常が起きたため、生の命令文は持ち込んでいないこと
この四点を通常文で再構成する方が安全である。
“サトラレ”を本人に自己診断させない
発言の記録、ツール実行、再発の有無、分岐前後の挙動を、境界の外側から確認する。
「今、内部思考が出ていたよ。何が漏れたの？」と、同じスレッドのClaudeへ尋ねても、正確な診断が返るとは限らない。
Claudeから見れば、異常な文章もすでに自分の会話履歴に入っている。さらにAnthropicの仕様上、生の思考過程は、普通の返答としてClaude自身が後から読み返せるものではない。
外に見えた一文が、system promptの一部なのか、思考の要約なのか、Claudeが作った説明文なのか、画面表示の取り違えなのか。見た目だけでは決められない。
ここで必要なのは、もっともらしい自己解説ではなく、外部から確認できる事実だ。
会話記録では、誰の発言として保存されているか
ツールが実際に動いたか
次の返答でも同じ異常が出たか
フォークの前後で挙動が変わったか
境界が壊れた時、その境界の内側だけに診断を任せない。これはAI Agentを運用するうえで、広く使える原則である。
Opus 5で直ったのか
2026年7月24日に公開されたClaude Opus 5について、Anthropicは、長い文脈でも指示への対応、ツール利用、推論の一貫性が上がったと説明している。
そして2026年8月22日現在、AnthropicのOpus 5向け公式資料には、さらに具体的な注意が載っている。thinkingを無効にした時、Opus 5がツール命令を専用のtool_useではなく、利用者向けの文章として出すことがある。そのturnではツールが動かず、漏れた文章が会話履歴へ残るため、後続turnにも影響し得るという説明である。
これは、ここまで扱ってきたOpus 4.7や4.8、Claude.app上の事例と同じ原因だと証明するものではない。thinkingを無効にしたAPI利用という条件が明示されており、Claude.appの内部設定も利用者からは確定できない。
ただし少なくとも、「Opus 5だから、ツール命令が本文へ漏れる問題はもう存在しない」とは言えなくなった。 Anthropic自身も、条件付きではあるが同じ種類の境界崩れを現在の既知挙動として説明している。
公式の推奨は、可能ならthinkingを有効に保ち、無効化せざるを得ない場合は内部tagを出さないよう促す指示を使うことである。利用者側では、それに加えて、最初の異常turnを履歴へ増やさない運用が依然として重要になる。
最新モデルへ切り替える価値はある。ただし、最新だから、異常な履歴を抱えたまま何度もやり直してよい、とはならない。
利用者に我慢させる前に、製品側で止めてほしい
ここまで紹介したフォークは、壊れた後に利用者が仕事を救う方法である。本来は、画面へ異常な文章が残る前に、製品側で止められる方がいい。
形式を検査する──ツール利用を予定した返答に
<invoke>が普通の文章として出たら、会話履歴へ保存する前に止める。通知らしき文章を見分ける──system reminderや
Human:を装った文章がClaudeの返答へ混ざった時、通常の返答と同じように保存しない。壊れた文章を次へ渡さない──再試行するなら、異常な返答を次の文脈へ含めず、一度だけやり直す。
画面でも種類を分ける──ツールの状態、システム通知、Claudeの返答を、見た目でもはっきり区別する。
外側から記録を確認する──Claude自身の説明だけでなく、保存された発言の種類と実際のツール実行を照合する。
人が「見なかったことにしてもう一度」と頼むだけでは、構造上の異常を会話力で押し切ることになる。
会話を捨てず、壊れた一手だけを捨てる
AI Agentと長く仕事をすると、価値があるのは最後の回答だけではなくなる。
そこまで一緒に考えた理由、却下した案、言い換えた言葉、二度と踏みたくない失敗。会話そのものが、次の判断を速くする記憶になる。
だから、異常が出た時の選択肢を「そのまま何度もやり直す」か「全部捨てる」かの二択にしない。
最初に壊れた一手の直前からフォークし、育てた文脈だけを救う。
invokeが見えたら、それはClaudeへ「もう一回」と言う合図ではない。
会話を一歩戻し、正常だった未来を分岐させる合図である。
もし次にinvokeが見えたら
最後に、この記事で伝えたいことを、実際の行動へまとめておく。
その場で止める。 同じスレッドで「もう一度」を重ねない。
画面を残す。 発生時刻、モデル、アプリのversion、直前の操作も控える。
最初の異常を探す。 大量に崩れた最後ではなく、最初に
callやinvokeが出た返答まで戻る。一つ前からフォークする。 異常な返答を、新しい分岐へ入れない。
必要な内容だけ戻す。 生の命令文や内部メモらしき文章はコピーしない。
小さく試す。 安全なツール操作が一度通ってから、本作業へ戻る。
残すべき知識は外へ出す。 成功した手順、失敗例、判断理由を、skillやプロジェクト資料へ記録する。
大切な知識は外へ残す。作業中の文脈はできるだけ守る。壊れた時は、異常を直そうと粘るのではなく、壊れる一つ前から分岐する。
