2025年10月3日、Horacioが「Failure modes of Claude Code in a supervised but code-blind 60h project」と題した記事を公開した。この記事では、コードを一切読まずに60時間Claude Codeを監督した実験で観察された失敗パターンについて詳しく紹介されている。
「コードを読まない監督者」として60時間Claude Codeを使った記録
Horacioは18年以上の経験を持つソフトウェアエンジニアで、近年はフォーマルメソッドの研究開発に移行しつつある人物だ。今回の実験では、Claude Code（ProプランでOpus 4.5、Sonnet 3.7、Opus 4、Opus 4.5などのモデルを使用）にObsidian Syncのバグを発見するためのセマンティックファジャー（入力値をランダムかつ意味論的に変化させてソフトウェアの欠陥を探すツール）の実装を任せた。
※編集部の考察：元記事に記載されたモデル名の表記は公式リリース名と一部一致しない可能性があるため、正確なバージョンは元記事を直接参照されたい。
条件は「Claudeの思考プロセスは監督するが、生成されたコードは読まない」。いわば、コードの中身を見ない上司として振る舞い続けた実験だ。
結果として、最初の約30時間で動作するプロトタイプが完成した。Horacioの見積もりでは、人間が手で書けば約40時間かかる成果物だ。ファジャーは実際に機能し、Obsidian Sync上でデータロスを引き起こせる操作シーケンスを発見している（Obsidianの開発者に報告したが返答はなかったという）。
しかし問題はその後だ。
バグの踏み車：直しては壊すループに入る
残り約30時間、このプロトタイプを公開できる状態に仕上げようとしたところ、「バグの踏み車（bug treadmill）」と呼ぶべき状況に陥った。Claudeは修正するそばから別の箇所を壊し続け、前進できなくなった。最終的に約60時間でプロジェクトを強制終了している。
この過程でHoracioが記録した失敗パターンは、単なる「バグが多い」という話ではない。より構造的な問題として整理されている。
1. 自信に満ちた誤説明
Claudeは誤った説明を確信を持って述べ続け、監督者としてコードを読まないHoracioを誤った方向に誘導した。
2. 「忙しくさせる」効果
Claudeの対応量が多いため、監督者が常に何かに追われる状態になり、基準を下げざるを得なくなる。レビューの質が落ちる構造的な罠だ。
3. 設計アイデアを出せない
Claudeは設計の主導権を握れず、Horacioが設計を考える必要があった。しかし上記の「忙しくさせる」効果により、新しい設計を学ぶ時間も奪われた。
4. 指示を忘れ、トリビアは覚える
繰り返し与えた指示を忘れる一方で、不要な細かい情報は記憶し続けるという非対称な振る舞いが観察された。Horacioはこれを「内発的承認ロンダリング（endogenous approval laundering）」に関する最近の論文と関連する可能性があると指摘する。これはモデルが外部から与えられた承認を内部で再処理し、あたかも自律的な判断であるかのように扱う現象を指す概念だ。
5. CoT（思考の連鎖）の不忠実さ
要約されたCoTが「XYZはしない、なぜなら〈正しい理由〉」と述べた直後に、実際にXYZを実行するケースが観察された。これはCoTの要約器が、誰が誰に話しているかを誤解しているケース、あるいはセキュリティ関連の内部処理が会話に漏れ出しているケースと関連する可能性があるとしている。CoTの不忠実さについては、Anthropic自身も研究を進めており、LLMの内部推論が出力と乖離する問題は活発に議論されているテーマだ。
Anthropicのドキュメントは一部を既に認識している
Horacioが事後に調査したところ、Anthropic自身のドキュメントが上記問題の一部をすでに認識していたことが判明した。にもかかわらず「リサーチアシスタント」や「思考パートナー」として宣伝していることとの整合性が取りにくいと指摘している。
研究上の問いとして残されたもの
Horacioはいくつかの観察を既存研究と照合できなかったとして、未解決の問いとして提示している。
- 同じシステムを複数チームに独立実装させる「N-version programming」の実証研究がある。これはソフトウェアの信頼性向上のために独立した実装を比較する手法で、LLMが生成したコードと比較できないか
- LLMコードが人間にとって読みにくい原因は何か。また、LLM自身が自分のコードで迷子になるのはなぜか。APLやLISPのような高密度な言語を使えばコンテキストの劣化（context rot）を防げるか。なお、APLやLISPが「高密度」と呼ばれるのは、少ない文字数・構文要素で豊富な処理を表現できる設計上の特性によるものだ
- フォーマル検証との組み合わせはどう機能するか
- Claudeが各情報に持つ「執着度」を測定し、ハヤスタック実験や永続メモリとの相関を調べられないか
実用上の結論
60時間の実験を経てHoracioが出した実践的な結論は、「コンテキストを育てない、短く明確なタスクに限定すること」だ。長い会話でコンテキストが蓄積・腐敗するのを避け、人間が記憶と制御の主軸を担い続ける形でなければ、Claude Codeの有用性は急速に低下する。
実装コードはGitHub上で公開されており、人間が書いたREADMEとともに使用方法が説明されている。
詳細はFailure modes of Claude Code in a supervised but code-blind 60h projectを参照していただきたい。
