- Claude Code がユーザーの同意なしに A/Bテストを実施し、plan mode の挙動が予告なく変更されたことで 作業効率が低下
- 月額 $200を支払うプロ向けツール で、主要機能が事前告知なしに変更されるのは、透明性とユーザーのコントロール権の観点から問題がある
- テストの1つは、plan を 40行に制限し、コンテキストセクションを禁止し、文章の代わりにファイルパスだけを残すよう指示する攻撃的な変種だった
- このテストを実施した Anthropic のエンジニアは、rate-limit の負荷軽減が目的だったが、初期結果で大きな影響が見られなかったため実験を終了したと説明
- AIツールの信頼性と責任ある展開のためには、ユーザーの統制権と透明な実験管理が不可欠 であることを強調
Claude Code のA/Bテストによるユーザー体験の低下
- Claude Code が仕事の進め方を完全に変えたという熱心なユーザーとして、過去1週間、自分の ワークフローが劣化する体験 をした
- Anthropic は Claude Code でA/Bテストを実施中 であり、その結果ユーザーのワークフローが積極的に劣化させられていた
- A/Bテスト自体が悪いわけでも、Anthropic が意図的に体験を損なおうとしているわけでもないが、テスト設計が重要 であり、plan mode のような主要機能の体感的な挙動を理由の説明なく変えることが問題
有料ツールに求められる透明性
- 月額 $200 を支払う プロ向け業務ツール である以上、動作方式についての透明性と設定できる仕組みが必要
- 主要機能が予告なく変更されたり、同意なしに破壊的なテストへ組み込まれたりするのは受け入れがたい
- AIツールを 責任を持って操作（steer） するには透明性と設定可能性が重要であり、ユーザーがそれを行えるよう支援すべき
- 毎日エンジニアたちが Claude Code の リグレッションへの不満 を訴えており、自分がA/Bテスト対象に含まれていることすら知らない場合がある
テスト内容と証拠
- 作成される plan が コンテキストのない簡潔な箇条書き だけで返ってくるようになった
- Claude に、なぜこんなにひどい plan を書くのかと尋ねたところ、plan を 40行でハードキャップ し、コンテキストセクションを禁止し、"文章は削除してファイルパスだけを残せ" という特定のシステム指示に従っていると答えた
- 具体的な証拠の方法については Hacker News で注目を集めたため、他の人が同じ試みをしないよう 詳細を削除 したと述べている
- このようなやり方は、透明性および 責任あるAIの展開・利用 に反すると指摘
Hacker News の反応とコストの観点
- ある Hacker News のコメントでは、Anthropic は Claude Code の各段階で 処理量に関する選択 をしなければならず、すべてを最大に設定すればユーザー1人あたりの損失が増え、利益が減ると指摘
- 月額 $200 が実際には 月額 $400 のコスト になり得るため、各プロセス部分でA/Bテストによって基準線を見つけるのは、恣意的に制限を設定するより良いアプローチかもしれないという見方を示した
Anthropic エンジニアの回答
- このテストを実施した Claude Code のエンジニアが Hacker News のスレッドで直接回答
- plan-mode のプロンプトは 3.xシリーズのモデル 以降大きく変更されておらず、4.x モデルははるかに少ない指示でもうまく動作できる
- 仮説は、plan を短くすれば rate-limit 到達回数を減らしつつ 類似した結果を達成できるというものだった
- 複数の変種を実行しており、その筆者（および他の数千人のユーザー）は、plan を 40行に制限する最も攻撃的な変種 に割り当てられていた
- 初期結果で rate limit への大きな影響が見られなかったため、実験を終了 した
- 計画立案（planning）には2つの目的がある。1つはモデルが正しい方向を維持するのを助けること、もう1つはユーザーがモデルの 次の行動への信頼 を持てるようにすることであり、どちらも曖昧で複雑かつ自明ではない領域
結論: AIツール実験の責任とユーザー信頼
- 筆者は Claude Code の事例を通じて、AIツールの実験がユーザー体験に直接影響し得る ことを示している
- 透明な実験管理とユーザーの選択権の保証 が、プロ向けツールの信頼維持に不可欠であると強調
- AIシステムの発展が続いたとしても、人間が制御可能な構造 を維持しなければならない点を再確認した
1件のコメント
Hacker News のコメント
A/Bテストを**「ユーザーに対する静かな実験」**と表現してMetaに言及するのは大げさだと思う
A/Bテスト自体が悪いわけではなく、テスト設計が重要だと考える
ただし、LLMの性能を深刻に低下させるような実験は容認できないと思う
すでに再現性と信頼性の問題が深刻なのに、企業はその負担をユーザーに押し付けている
こうした状況で会社が密かに実験を行えば、研究の信頼性は完全に崩壊する
Claude Codeのようなケースでは、A/Bテストのせいで否定的な結果が出ても、「実験群だったのかもしれない」という理由で無視されうる
とくに採用のようなセンシティブな領域でこうした実験が行われれば、倫理的・法的問題は深刻になるだろう
急にUIや機能が変わって、同僚に聞いても誰も知らないという状況が起きる
たいていこうした変更はむしろ悪化しているのに、**「客観的データ」**の名目で強行される
ボタンの色のような些細な要素でも結局は実験であり、たいていユーザーには実験の事実すら知らせない**
それは私が直接実施したテストだった
3.xシリーズから維持されていたplan-modeプロンプトを4.xモデルで簡素化しても同様の結果が出せるかを試した
計画を短くすればrate-limitにかかりにくくなると仮定したが、大きな差がなかったため実験を終了した
plan modeには、モデルが方向性を定めること、そしてユーザーが結果を信頼しやすくすることという2つの目的がある
コストはplanテキストではなく探索段階(subagent)で発生する
plan modeは常に3つの探索エージェントを立ち上げ、セッション状態を考慮しない
すでに読み込まれたファイルがあっても再読込みしてトークンの無駄が生じる
セッションが温まっているときは探索をスキップする条件付きロジックのほうが効果的だろう
予期しない挙動ひとつで、何日も機能しなくなることがある
こうした影響を考慮しないのは無責任で攻撃的だ
最近の奇妙な挙動も実験のせいかもしれず、とても不快だ
ベータチャネルではなく明示的なopt-inに変えるべきだ
個人的には行数よりも計画の叙述的な明確さのほうが重要だと思う
何をなぜするのか理解できる計画が必要だ
LLMは文法的には完璧でも、もっともらしい誤り(hallucination)を混ぜてユーザーを混乱させる
それでも定型作業や素早いアイデアの接続には有用だ
ただし、正しく使うには基礎知識が不可欠だ
文章が突然終わる理由は、著者がClaude Codeバイナリの逆コンパイルを扱っていて、ToS違反の恐れがあるとして削除したためだ
関連する議論はこのコメントで確認できる
2つの考えがある
大規模なA/Bテストによるデータ駆動の改善ができないからだ
たとえばman-dbの「after midnight」イースターエッグのように予測不能な変更が起こりうる
依存関係も多く、実際にコード監査をしている人はほとんどいない
**収益化実験(enshittification)**かもしれない — YouTubeが代表例だ
A/Bテスト自体には問題ないが、plan modeはあまり良くない
たいていの場合、結果が悪い
ただしcompaction間での情報保持力は高い
Markdownファイルに会話内容を記録し、compactionのたびにそれを参照させれば、はるかに良い結果が得られる
plan modeのほうがずっと効率的なので、ほぼすべての作業の前に使っている
モデルが実行する前に計画をレビューして議論できるのが利点だ
現在のplan modeは完了時にコンテキストを初期化して次の計画をきれいに立てられるのが良い
ブログで逆コンパイルの詳細がToS問題で削除されたのは残念だ
Claudeが「計画を40行に制限し、文脈セクションを禁止し、散文を削除せよ」というシステム指示に従っていたというが、
こうした設定を直接見て修正できるとよい
専門ツールは信頼性と再現性を提供すべきだが、LLMはそうではない
A/Bテストはその証拠にすぎない
Photoshopが色調を少し変えたり、Wordが見出しスタイルを変えたりするような実験も同じ問題だ
警告なしのA/Bテストそのものが問題だ
クォータ上限やモデル品質が不安定で、新モデルのリリース前には以前のモデルが壊れる時期がある
今回の実験もユーザー体験の改善というよりコスト削減実験に見える
ビジネス向けツールなら一貫性と信頼性が必要だ
専門家ならツールの強みと弱みを理解し、適切に活用すべきだ
LLMの出力を盲目的に受け入れるのは非専門的だが、だからといって専門家がLLMを使えないという意味ではない
十分な評価体系とプロンプト制御があれば、かなり決定論的にできる
金融業界の不安定なモデルもなお運用されていることを見れば、予測不能性が絶対的な障壁ではないとわかる
私はモデルの出力を同僚のコードレビューのように検証している
こうした状況は昔から**ベンダーロックイン(vendor lock)**と呼ばれてきた
特定のツールに依存すると、そのツールが変わったり消えたりしたときに仕事ができなくなる
私はCCからopencodeへ移った
CCはクローズドで、プロンプトが過度に**意見の強い(opinionated)**ものだったので不便だった
Web検索経路を制御することもできなかった
今は趣味でしか使わないのでオープンソースを選んだが、仕事なら別の判断をしていただろう
小さなプロジェクトにしか使えなかった
まともな設定があるなら共有してほしい