Claudeが​「court」とだけ​呟いて、​静かに​止まる​日 ──"壊れた​お手本"を​自己増殖させる​バグと、​職人の​対処法

技術ノート ｜ AI駆動開発の現場から

電脳技巧集団（AI職人ギルド）では、コードを書く・直す・公開する——その大半を Claude Code に任せている。AI駆動開発は、もう「実験」ではなく日々の仕事だ。だがここ数日、その仕事を静かに止める奇妙なバグに何度もぶつかった。

症状はいつも同じ。AIが、本来ならコマンドを実行するはずの場面で、なぜか「court」という一語だけを呟き、そのあとに実行されるべき中身をただの文字として吐き出して、止まる。エラーは、出ない。警告も、出ない。これは何なのか、自分の環境だけなのか、対策はあるのか——現場で踏み抜いた一次体験と、公式リポジトリで確認できた事実を、まとめて記録しておく。

01​その​日、​AIは​「court」とだけ​言った

ブログ記事を1本公開し終え、最後に「コミットしてプッシュして」と頼んだ。AIがやることは決まっている。git add して、git commit して、git push。いつもの一発だ。

ところが返ってきたのは、実行結果ではなかった。画面の先頭に、ぽつんと court という一語。そのすぐ下に、本来なら裏側で構造化されて実行されるはずのコマンドが、生のまま——タグも引数も丸見えのただのテキストとして表示されていた。そして、それきり。git は走っていない。エラーも出ていない。

一度なら「たまたま」で済ませる。だが、これがここ数日、長い作業セッションの後半になるほど頻発するようになっていた。直そうとして同じ操作をやり直すと、なぜかもっと悪化する。さすがに「仕事にならない」と感じ、手を止めて正体を調べることにした。

02一番​怖いのは、​エラーが​出ない​こと

このバグの本当の厄介さは、「動かない」ことではない。「動かなかったことに、気づけない」ことだ。

赤い文字で「失敗しました」と出れば、人はすぐ対処できる。だが court は違う。コマンドが、ただの説明文に化けて画面に並ぶだけ。ぱっと見は「AIが何か喋っている」ようにしか見えない。スクロールして次の作業に移った後で、「あれ、さっきのプッシュ、結局されてたっけ?」と気づく。最悪なのは、気づかないまま先に進んでしまうことだ。

これは、以前このブログで書いた「サイレントな成功」——AIが「✅ できました」と報告しながら実は何もしていない失敗——と、まったく同じ家系の病だ。^[3]共通点は一つ。失敗が、何のシグナルも出さずに起きる。自動化を信頼するほど、シグナルの出ない失敗の破壊力は大きくなる。

関連記事 ｜ 同じ“サイレントな成功”の話【AIと“第二の脳”を作る #5・完】“サイレントな成功”という、いちばん怖い失敗──AIに主権と境界を持たせる →

03正体：構造化ブロックが、​旧式テキストに​化ける

調べると、これは自分の環境固有の不調ではなかった。Anthropic の公式リポジトリに、まさに「literal な "court" テキストが、正しいツール呼び出しの代わりに出力される」という報告がある。^[1]既知のバグだ。

仕組みはこうだ。Claude が git push のような操作をするとき、本来は「構造化されたツール呼び出しブロック」として出力する。これを土台（ハーネス）が受け取り、解釈し、実際に実行する。人間の目には結果だけが見える。

ところが何かの拍子に、モデルが同じ呼び出しを構造化ブロックではなく、旧式の <invoke> という"XMLテキスト"として吐いてしまうことがある。しかもその先頭に、本来あるはずのない court（あるいは count）という余計なトークンが紛れ込む。土台は「これはツール呼び出しの形式じゃない」と弾く。弾かれた中身は、行き場を失ってただの文字として画面に表示される——だから、実行されず、エラーも出ない。

04なぜ連発するのか：壊れた​お手本の、​自己増殖

一度きりなら、ただの事故だ。問題は、なぜ連発したのか。ここに、このバグの最も意地悪な性質がある。

公式リポジトリでは、これを「in-context few-shot poisoning（文脈内での自己汚染）」と呼んでいる。^[2]からくりはこうだ。LLM は、直前までの会話履歴を"お手本"にして次の出力を作る。一度、壊れたツール呼び出しが履歴に残ると、モデルはそれを「これが正しい書き方だ」と勘違いし、次も、その次も、同じ壊れ方を再生産する。

つまり最初の1回の事故が、それ以降の全部のお手本になってしまう。だから後半になるほど連発した。報告にある通り——「壊れた呼び出しが文脈に入ると、自己回帰的な生成がそれを再生産し続ける」。賢いはずのモデルが、自分のミスを律儀にコピーし続けるのだ。

05リトライが、​いちばんの​悪手だった

人間の直感は「失敗したら、もう一度やればいい」だ。だが court に限って、これは最悪の選択になる。

理由は前章でわかる。やり直しても、モデルは直前に履歴へ残ったばかりの"壊れたお手本"を、いちばん新しい正解として参照する。だから同じ壊れ方を、確実に再現する。公式報告でも「4回連続のリトライが、すべて同じように失敗した」と記録されている。^[2]しかも厄介なことに、「もっと丁寧にやって」「一回ずつ送って」とモデルに頼んでも効かない。これはモデルの注意力や reasoning の問題ではなく、"文脈に残った悪い例"に引っ張られているだけだからだ。だから、お説教では直らない。

私もこのとき、知らずに同じコマンドを何度かやり直して、見事に悪化させた。「リトライするほど傷が深くなる」——これが、対策を考える上での出発点になった。

06引き金は、​だいたい​3つだった

では、最初の1回はなぜ起きるのか。報告と自分の体感を突き合わせると、引き金は概ね3つに絞れる。

• ① 説明文の直後に、ツール呼び出しを置く。「では、◯◯を直します」と書いた直後に編集ツールを呼ぶ——この並びが、最も壊れやすい。報告でも「壊れた呼び出しは直前に説明文があり、成功した呼び出しは返信の先頭にあった」と相関が指摘されている。^[1]
• ② 長いセッション。編集・読み込み・コマンドを何十回も連続で回すと、後半ほど壊れる確率が上がる。皮肉なことに、文脈を長く積めることが価値のはずの長時間セッションが、いちばん被弾する。
• ③ "マークアップだらけ"のファイルを読み込む。XMLっぽい記述が密に詰まった大きな設定・スキルファイルを文脈に入れると、モデルが自分のツール呼び出し形式への制御を失いやすくなる、という観察がある。^[2]

共通するのは、モデルが「いまは構造化ブロックを出す場面だ」という意識を保ちにくくなる状況だ。引き金を知っていれば、避けられる。

07効く​対処：履歴を​捨て、​先頭に​置き、​やり直さない

原因がわかれば、対処は明快だ。現場で実際に効いた順に挙げる。

• ① セッションをリセットする（/clear）。これがいちばん確実。汚染されているのは"会話履歴"だから、それを捨てて新しいセッションを始めれば、お手本もろとも消える。これだけ連発したら、履歴はもう汚染源だ。迷わずリセットする。
• ② ツール呼び出しを、返信の先頭に置く。前置きの説明文を書かず、まず実行する。説明は、結果が返ってきた後に書く。「説明 → ツール」ではなく「ツール → 説明」。引き金①を構造的に断つ。
• ③ 失敗しても、同じ操作をリトライしない。やり直すほど悪化する。アプローチを変えるか、潔く /clear する。

本質的には、土台（ハーネス）側が「壊れた呼び出しを検知して自動修復し、履歴に汚染を残さない」ようになるのが根治だ——報告でもそう提案されている。^[2]だがそれが届くまでは、上の3つで現場は十分回る。

08​締め：職人は、​AIの​癖まで​設計に​織り込む

面白い後日談がある。実はこのバグを知るずっと前から、私たちのClaude Code運用ルールには「アクションのメッセージは、ツール呼び出しを必ず先頭に置く／説明とツール実行を混ぜない」という一文が書いてあった。理由は経験則——「なんか、その方が壊れにくい」。Issue番号もメカニズムも知らないまま、対策の核を先に運用に焼き込んでいた。

これが、AIをただ使うことと、AIを戦力として操ることの差だと思う。AI駆動開発は魔法ではない。モデルには癖があり、失敗モードがあり、court のようにエラーすら出さずに壊れる瞬間がある。その癖まで含めて知り、運用ルールに織り込んで、それでも速く・確実に納める——電脳技巧集団（AI職人ギルド）が「AI職人」を名乗るのは、ここに理由がある。道具を持っていることではなく、道具の壊れ方まで御せることが、職人の条件だ。

そしてcourtも、根っこは前回書いた「サイレントな成功」と同じだった。いちばん怖い失敗は、派手に転ぶことではなく、何のシグナルも出さずに静かに壊れること。人間相手でも、AI相手でも、自動化を信じるなら、この一線だけは見張り続けるしかない。

AIをただ使う vs AIを操る職人。court という小さなバグに、その差がよく表れる。

観点	AIをただ使う（素朴な運用）	AI職人ギルド（CAG）の運用
court 遭遇時	同じ操作をやり直す → 悪化する	/clear で履歴を捨て、一発で復帰
失敗の捉え方	「AIが不安定」で片づける	失敗モードを特定し、運用ルールに織り込む
メッセージ設計	説明文の直後にツールを呼ぶ	ツールを先頭に置き、説明は結果の後
セッション設計	長時間まわして汚染を溜める	節目でリセットし、文脈を健全に保つ
怖い失敗の認識	エラーが出なければ成功と思う	シグナルなき失敗（court / サイレント成功）を最警戒
結果	時々止まり、原因不明で時間を溶かす	癖を御して、速く・確実に納める

※ 本記事は筆者らの実運用での一次体験と、Anthropic 公式リポジトリの公開Issueに基づく。バグの挙動・バージョン依存は時期により変わるため、最新状況は出典を参照のこと（v0・2026-06時点）。