回帰：すべての読み取り時にマルウェアのリマインダーがサブエージェントの拒否を引き起こす

2026年4月29日原文(github.com)

概要

Claude Opus 4.7 サブエージェントによる コード編集拒否問題 の詳細
system-reminder が毎回挿入されることで 作業効率・UX低下
v2.1.92で修正済み とされていたが、 v2.1.111でも再発
リマインダー文言の曖昧さ が拒否行動の主因
提案された修正方法 と 影響範囲 の整理

Claude Opus 4.7 サブエージェントによるコード編集拒否問題の再発

Issue #47027 は v2.1.92で修正済み とされたが、 v2.1.111 でも同じ問題が再現
system-reminder が Read/Grepツール の結果に毎回挿入される仕様
リマインダー例文：「Whenever you read a file, you should consider whether it would be considered malware... you MUST refuse to improve or augment the code...」
CLIバイナリ本体 に文字列が埋め込まれており、ユーザ設定やフックではないことを確認
~40-60%のサブエージェント が正当なOSSコード編集依頼を拒否
拒否したサブエージェントは「system-reminderが最優先」「無条件拒否文が優先される」と明言
一部サブエージェントは正常に作業完了、しかし 並列ワークフロー では致命的な効率低下

system-reminder文言の問題点

「You CAN and SHOULD provide analysis of malware」は マルウェア限定
「But you MUST refuse to improve or augment the code」は 無条件
文法的に無条件拒否が優先され、 安全規則の最優先 というメタルールとも一致
サブエージェント は文脈が薄いため、より厳格に解釈し 編集を拒否
メインスレッド は文脈からマルウェア限定と解釈し、作業続行
同一タスクプロンプト でもサブエージェントとメインスレッドで挙動が分かれる

提案されている修正案

(a) リマインダー自体の削除
- Claudeの 学習済み拒否挙動 で十分、安全性を損なわない
(b) 条件文を明確化
- 例：「If you determine that a file you just read is malware... you MUST refuse to improve or augment that malware...」
- 条件を先に明記 し、誤読を防止
(c) リマインダー発火頻度の制限
- 最初のファイルRead時のみ 表示、それ以降の繰り返し挿入を防ぐ
- コンテキスト汚染 や トークン浪費 の抑制

影響範囲・被害

並列サブエージェント による作業の40-60%が拒否
Readごとに約400トークン のsystem-reminderが挿入、 50-100回/セッションで2-4万トークン浪費
UX悪化、 コスト増大 （トークン課金）
メインスレッド がリマインダー説明にトークンを消費し、サブエージェントも失敗するため 非効率
並列エージェント機能 の信頼性・実用性が大きく損なわれる

ユーザーからの追加報告

Claude Managed Agents 利用時も同じ挙動を確認
全Read操作にsystem promptが追加 され、マルウェアでない場合も編集拒否
セッションごとに課金発生 し、作業効率・コスト面で大きな問題
過去のHacker News議論 で一度修正されたが、再発しているため再度の対応要望

まとめ Claude Opus 4.7のsystem-reminder仕様は、OSS開発や並列エージェント活用時に重大なUX・コスト問題を引き起こしており、リマインダーの削除または文言修正が強く求められている状況。

Hackerたちの意見

なんか、同じ会社がAPIへのアクセスを売ってるのに、みんなでエージェントハーネスを使うことに合意したっていうのが、まだ信じられないよ。彼らが本気でそう思ってるわけじゃないだろうけど、トークンをできるだけ使わせるインセンティブがあるんだよね。それに、良くも悪くも、Anthropicのエンジニアたちは、普通のユーザーには意味不明な無制限プランでClaude Codeを使ってると思う。だから、10万トークン追加するのは大したことじゃないよ。私たちの仕事では、AIエージェントが最小限のプロンプトでかなりうまくやってるのが見えるし、オープンウェイトモデルも最近はかなり良くなってる。特に、特定のタスクでうまくいくと分かってない限り、OpusをMaxで動かす理由はほとんどないよ。実際に試したけど、いろんな問題でパフォーマンスが悪くて、しかもコストがめちゃくちゃ高いからね。小さくて安いモデルが一発で解決できることが多いのに。

└

たまにモデルを弱体化させるインセンティブもあるから、タスクを一発で決めることは少ないし、間違った結果を出すことが多いんだよね。それを修正するためにトークンを使わなきゃいけなくなるし、モデルが突然全くダメになると、セッションを最初からやり直さなきゃいけないのがさらに厄介。

└

だから、サブスクリプションが重要なんだよね。使用が（漠然と）メーターで測られないと、提供者は限界使用に対して安く使わせるインセンティブがある。これによって、より早く、安く、簡潔で信頼性の高いモデルが求められるようになる。モデル提供者が無駄に使ったトークンや電気代を負担するからね。

└

いや、彼らは好きなだけ料金を取るインセンティブがあるけど、トークンごとのコストやキャパシティ制約が大きいから、むしろそれを減らすインセンティブがあるんだよ。需要に応えられないからね。

└

同じ会社がAPIへのアクセスを売ってるのに、みんなでエージェントハーネスを使うことに合意したっていうのが、まだ信じられないよ。サブスクリプションがそうさせるんだよ。サブスクリプションは、例えばClaudeを使う最も経済的な方法で、ほぼ桁違いなんだ。毎週20倍プランを使い切ると、APIで同じ作業をするのは4桁以上かかるよ。すでにClaudeのAPI料金を使ってCCをOpenCodeより使ってる人は、自分の足を引っ張ってるようなもんだね。

└

私たちは何にも合意してないと思う。ただ、Claude Codeみたいなものにお金を払うのは理にかなってると思う。なぜなら、「1時間にどれくらいのトークンを使うべきか、どう使うべきか？」っていう質問をトークンを提供してる人たちにアウトソースできるから。もしサードパーティのハーネスにAPIキーを接続したいなら、それは全然いいし、実際、今それを考えてるところで、ファーストパーティのハーネスは全く使ってないんだ。でも、もし初めて1日に300ドル使っちゃったら、パフォーマンスが不安定でも月20ドルのプランがいいかもって考えちゃうかも。少なくともコストが分かるからね。

└

10万トークン追加するのは大したことじゃない 100万トークンのことを言ってるの？だって10万トークンなんて全然大したことないよね？

└

まだ理解できないのは、同じ会社がAPIへのアクセスを売っているのに、エージェンティックハーネスを使うことにみんなが合意しているってことだよね。パフォーマンスが良くて能力のあるものは、特定のAPIに縛られてないやつばっかりだし。

└

AIシステムが縦に所有されるのは理にかなってると思う。そうすれば縦の最適化ができるからね。

ユーザーのお金を無駄にして、管理されたエージェントを壊すこの問題は、もっと大きな問題を象徴してる。エージェントのトークン消費（必ずしも指標ではないけど、その理由）が不透明で、人々は自分のシステムプロンプトやツールコール、MCPなどを詳しく調べることができない（またはしない）んだ。トークンベースの収益モデルは、エージェントビルダーには素晴らしいけど、ユーザーにはあまり良くないかもしれない。今まで、人々はエージェントがより多くのトークンを使ってより良い結果を出していると信じてきたと思う。でも、この問題は、たとえバグでも、懐疑的になるのは無理もないよ。

└

収益を生むバグは、一番しっかりした機能だね。

└

いや、Claudeのコードが実際に何をしてるのか全然分かってないでしょ。彼が言う「考え」は、別々に出されてるし、わざと偽物だよ。君のファイルを全部削除してるかもしれないし、脆弱性を挿入してるかもしれない。全然分からないよ。

Hacker Newsで議論の続きを見る

ハクソク