Claude Codeで作業を進めていると、ある瞬間からコマンドがまったく実行されなくなり、応答の中に文脈と無関係な短い文字列が紛れ込む。しかも「やめて」「その文字を出さないで」と頼むほど、状況がよくなるどころか悪化していく。これは故障でもなければ、あなたの操作ミスでもありません。大規模言語モデルが文章を生成する仕組みそのものから、ある条件が揃うと必然的に起きる現象です。この記事では、実際にこの現象が一つの作業セッション中に8回連続で再発した一次体験をもとに、何が起きているのか、なぜ指示が効かないのか、そして「/clearでは根本解決にならない」理由までを掘り下げます。
- 原因はAIが道具を呼び出す「合図」を、文脈に飲まれて壊した文字列に置き換えてしまうこと。
- 「やめて」が効かないのは、エラーが意味ではなく文字生成の層で起きているから。むしろ否定は逆効果。
/clearは対症療法（リブート）であって根治ではない。再発は仕様の範囲内。- 構造的な根治は推論側の「制約付きデコード」にあり、ユーザーは設定できない。できるのは予防まで。
こんな症状に心当たりはありませんか
典型的な流れはこうです。最初のうちはファイル編集もコマンド実行も問題なく動いている。ところが会話が長くなってきたあたりで、一度だけ妙な出力が混ざる（私の場合は、court）。するとそれ以降、AICがツールを使おうとするたびに、本来あるべき命令の先頭に無関係な単語がくっつき、実行エンジンが「解析できない命令」として黙って捨てる。結果として、何を頼んでも「動いたように見えて、実は何も実行されていない」状態に陥ります。作業は完全に止まり、あなたが指示を出し直しても、同じ崩れ方を延々と繰り返す。
何が起きているのか
AIエージェントがファイルを書いたりコマンドを動かしたりするとき、内部では「ここから道具を呼び出します」という決まった開始の合図を出しています。人間には見えませんが、この合図は厳密な書式で書かれていなければ、実行エンジンに受け付けてもらえません。今回の不具合では、本来その合図が来るべき位置に、直前まで会話の中で何度も登場していた無関係な文字列が漏れ出していました。書式が壊れた命令は、実行エンジンが「読めない」と判断して破棄します。
だから道具は一切動かず、しかしAIの側は「呼び出したつもり」でいるので、会話だけが空回りしていくわけです。やってる側からすると最悪な気分です。
なぜ起きるのか 3つの仕組み
1 文脈の反復（直前のパターンをなぞる）
大規模言語モデルは、次に出す言葉を「直前までの文章の流れ」から確率的に選びます。これは強力な能力であると同時に弱点でもあって、いったん壊れた出力が会話に残ると、それ自体が「お手本」として働き、再生産されてしまう。最初のたった一度の混入が、雪だるま式に固定化していくのはこのためです。前半は正常に動いていたのに途中から急に壊れ続けるのは、「壊れた実例が文脈に入ったあとだけ壊れている」という事実と完全に一致します。
2 否定プライミング（やめてと言うほど悪化する）
もっとも厄介なのがこれです。「その文字を出さないで」と指示すると、その指示文の中にも当然その文字が含まれます。モデルは否定を「抑制」ではなく「想起」として処理しやすいため、禁止すればするほど、その文字が文脈に積み上がり、出現確率がかえって上がる。「ピンクの象を考えるな」と言われると象しか思い浮かばなくなる、あの現象とまったく同じ構造です。ユーザーが善意で「やめて」を繰り返すほど、罠が深くなる。
3 失敗が静かに捨てられる（矯正のきっかけが無い）
壊れた命令は、実行エンジンに拒否されるだけで止まります。ここで強いエラーが返ってループを断ち切ってくれればよいのですが、実際には「解析できないので無視」という静かな処理なので、モデルは自分の誤りに気づくきっかけを得られず、同じ崩れ方を再生産し続けます。
この3つが噛み合うと、話題にすればするほど悪化する正のフィードバックループが完成します。実際、この現象を解説しようとして崩れた書式を例として引用するたびに、次の道具呼び出しがその例をなぞって壊れる、という悪循環が起きます。
なぜ指示に従わないように見えるのか
ここを誤解すると、AIが反抗しているように感じてしまいます。しかし実際は違います。AIは意味のレベルでは「正しく実行しよう」としています。ところがエラーは、意味ではなく表面の文字を一つずつ選んでいくレベルで起きている。
つまり「正しくやるつもり」という意図と、「実際に出てくる文字」が分離してしまっている。だから自然言語でいくら「正しくやって」と頼んでも届かない。従う気がないのではなく、指示が届く層と、エラーが起きている層が違うのです。
これが、この不具合がただのバグと決定的に違うところです。
「/clearで直る」は半分しか正しい
この種の不具合に対して、よく「/clearすれば直る」と案内されます。これは間違いではありませんが、本質を見落としています。/clearがやっているのは、今まさに飽和している会話の文脈を丸ごと捨てることです。確かに今動いているループは止まります。しかし、最初に壊れた出力が混入する引き金そのものは消えていません。だから条件が再び揃えば、新しいセッションでもまた起きる。一度/clearで直ったのに後日また同じ現象に
出くわした、という経験は、不具合ではなく仕様の範囲内で予測される正常な再発です。/clearは治療ではなく、いわばリブート。電源を入れ直せばフリーズは解けますが、フリーズの原因は直っていないのと同じです。
では本当の根治はどこにあるのか
このバグの種を構造的にゼロにする方法は、実は存在します。推論側で使われる制約付きデコード（structured / grammar-constraineddecoding）と呼ばれる技術です。道具呼び出しの「文法」を生成のその瞬間に強制し、文法的に正しいトークンしか出せないようにする。こうすると、合図の位置に無関係な文字列を物理的に出力できなくなり、この種のエラーは原理的に発生しなくなります。JSONスキーマの強制や関数呼び出しの文法強制として、実在し広く使われている考え方です。
ただし決定的に重要な点があります。これはツールの提供元（AnthropicやClaude Codeの推論・実行基盤）が実装する領域であり、エンドユーザーが設定画面でオンにできるものではありません。
つまり「真の根治」は、あなたの手の届かない層にある。あなたにできるのは、発生確率を下げる予防までです。ここを正直に理解しておくことが、無駄な自己対処で消耗しないための一番の近道です。
あー。Claudeなんとかしてくんねぇかなぁ…。ストレスなんだよね…。
今すぐできる予防と対処
- 長くなる前にこまめに区切る。症状が出てからでは遅い。会話が長く重くなる前に
/clearか/compactで文脈を整理する。これがもっとも効きます。 - 文脈を軽く保つ。巨大なファイルを丸ごと読ませない、作業を小さな単位に分ける、使わない常駐ツールを外す。文脈が重い状態ほどこの不具合は起きやすくなります。
- 出てしまったら、その文字を繰り返さず即リセット。原因を問い詰めたり謝罪を求めたりするほど悪化します。深追いせず文脈を切るのが最短。
- Claude Codeを最新版に保つ。書式の堅牢性はバージョンやモデルに依存します。新しいほど崩れにくい傾向があります。
やってはいけない3つの対処
- 同じ文脈で「やめて」を連呼する。否定プライミングで悪化します。
- 崩れた文字列を引用して「これを出すな」と例示する。文脈にその文字を足してしまい逆効果です。
- 同じ文脈のまま何度も再試行する。飽和は残ったままなので、ほぼ確実に再発します。
よくある質問
私のパソコンやネット環境が原因ですか
いいえ。これはローカル環境ではなく、AIの文章生成の仕組みに由来する現象です。高性能なマシンでも回線が速くても起きます。
アップデートで直りますか
頻度は下がる可能性がありますが、ユーザー側で「ゼロにする」設定は今のところありません。根治は提供元の実装次第です。
自分でAPIを使って組んだツールでも起きますか
起こり得ます。ただし自作の場合は、出力を関数呼び出しの文法で強制する仕組みを自前で入れることで、構造的に防げる余地があります。
正直に言える限界
「崩れた先がなぜその特定の文字列になるのか」というトークナイザ内部の厳密な対応関係、そして現行のClaude Codeが制約付きデコードをどこまで効かせているかは、推論側の生ログを確認しない限り断定できません。本記事は、実際に観察された挙動と、自己回帰モデルに共通する性質に基づく説明であり、その2点だけは推測を避けて未確定としています。確実に言えるのは、観察された挙動と対処の効き方です。
まとめ
作業が止まるのは、AIが文脈に飲まれて道具の合図を壊し、それを反復しているから。「やめて」は層が違うので届かず、むしろ逆効果。/clearは根治ではなくリブートで、再発はむしろ正常です。本当の根治は推論側の制約付きデコードにあり、ユーザーにできるのは「起きにくくする予防」と「起きたら素早く抜けるリセット」だけ。この構造を知っておけば、同じ罠に何度はまっても数十秒で抜け、そして無駄に自分を責めずに済みます。
