Claudeを解約した理由: トークン問題、品質低下、貧弱なサポート
(nickyreinert.de)- 最初の数週間は、速さと公平に感じられるトークン許容量、良好な結果品質で満足度が高かったが、約3週間前から体感が大きく変わった
- 10時間休んで戻ったあと、Claude Haikuに短い質問を2つ送っただけで使用量が100%まで急上昇し、サポートチャネルは問い合わせの核心を扱えない自動化された回答のあと、事実上閉じられてしまった
- 最近は複数プロジェクトを同時に回していた状態から、単一プロジェクトでも2時間でトークン上限が尽きるほど作業可能時間が短くなり、リファクタリングの過程では安易な回避策を正すだけで5時間ウィンドウの約半分を使ってしまった
- 一定時間が過ぎると会話キャッシュが消え、コードベースを再度読み込むコストが繰り返し発生し、週次基準時点の変更や説明のない月間上限警告まで重なって、上限体系に一貫性があるように見えなかった
- 生産性向上と製品の潜在力は高く評価していたが、サポートの不備と品質低下、利用制限の混乱が積み重なり、最終的にAnthropicアカウントを解約することになった
初期の満足感とその後の変化
- Claude Codeの購読開始から最初の数週間は、速度が速く、トークン許容量も公平に感じられ、結果の品質も良かった
- 混雑していない時間帯のトークン許容量を増やしたという案内も確認できた
- 一部の政府規則に反対する姿勢も相まって、製品を支持したい気持ちも生まれた
- 約3週間前からは、当初の満足感が急速に薄れ始めた
- 以降のセクション全体で、サポート対応、品質、利用制限の問題が続く
サポート品質の問題
- 10時間ほど休んでトークンが再び補充されたと考え、朝に作業を始めたが、Claude Haikuにリポジトリとも無関係な短い質問を2つ送った直後、トークン使用量が100%まで急上昇した
- 質問は単純で、規模も小さかった
- 期待していたトークンのリフレッシュと実際の使用量の増加は一致していなかった
- AIサポートボットに問い合わせたが、基本的な案内しか返されず、実際の問題も正しく把握できていなかった
- その後、人間のサポートを依頼した
- 数日後に届いた返答も、実際の問題とはずれた定型的な内容に見えた
- 届いた返答は「システムがProまたはMax料金プランの使用上限に関する問い合わせとして検知した」という文言で始まっていたが、実際にはすでにPro plan利用中であり、問い合わせの核心もまったく捉えていなかった
- 続く本文も、日次・週次上限を説明するドキュメント的な内容が長く続いていた
- 問い合わせた問題を解決したり、直接扱ったりする流れも見られなかった
- メールの最後には、追加の返信は監視されない可能性があるのでヘルプページを訪れるようにという文言が添えられており、問い合わせチャネルは事実上閉じられていた
- 実際の問題を反映しない自動返信のあとで、サポート経路まで塞がれてしまった形だった
- サポート品質への失望が本格的に大きくなった
品質低下
- その後の数日から数週間にかけては、結果品質が初期の体験に比べて満足できず、作業可能時間も大きく短くなった
- 以前は最大3つのプロジェクトを同時に進められたが、今では単一プロジェクトでも2時間でトークン上限が尽きてしまう
- 利用可能量と体感的な生産性がともに悪化した
- 品質評価は主観的になり得ること、またエージェント性能がユーザーの使い方に大きく左右される点にも触れている
- 同時にGitHub Copilot、OpenAI Codex、OMLX、Continue、Qwen3.5-9Bも併用していると明かしており、比較利用の経験がうかがえる
- 絶対的な専門性を主張しているわけではないが、複数のツールを使ったうえで感じた低下として読める
- Claude Opusにプロジェクトのリファクタリングを任せた事例では、モデルの思考ログに、すべてのスライダーをJSXで直接修正する代わりに
ui-events.jsへ汎用イニシャライザを追加し、値表示を自動注入する方針が現れた- そのアプローチは、各range inputに値表示がなければ自動挿入する回避的な方式になっていた
- こうしたログは、ときどきではなく頻繁に確認する必要があると感じられた
- この方法は良い実践ではなく安易な回避策だと評価され、直接指摘するとOpus自身も怠惰なアプローチだったと認め、JSXにラベルを直接追加して明示的に結びつける方向へ切り替えた
- 最初の誤った方向を修正するだけで、5時間のトークン許容量の約50%を使った
- 結果品質の低下が、単なる印象を超えて実際のコスト浪費につながった
キャッシュと上限表示の混乱
- 会話キャッシュの問題も新たに表面化し、関連してAnthropicのpostmortemとHacker Newsの議論があわせてリンクされている
- この問題を公に扱っている点自体は前向きに受け止められている
- ただし、ユーザー体験の面での負担はそのまま残る
- 一定時間が過ぎて作業に戻ると、会話キャッシュが消えており、モデルがコードベースを最初から読み直し始める
- コスト面では合理的かもしれないが、ユーザーにとっては初回ロードにすでにトークンを一度使ったあと、強制休憩後に再び同じロードコストを払う構造になる
- 特に5時間のトークンウィンドウ上限のために休んで戻った場合、同じコストを繰り返し支払うことになる
- 週次ウィンドウが突然「今日基準」から「月曜基準」に変わったこともあり、その変更とともに使用量が0にリセットされた
- リセット自体は歓迎だったが、なぜこの変更が起きたのかはわからなかった
- 上限体系が一貫していないという印象を与えた
- プロジェクト作業中にトークン使用量を追っていたところ、組織ユーザーでもないのに、突然月間使用上限を心配すべきだという警告が表示された
- その時点では、時間単位・週単位の上限もまだ超えていなかった
- 警告の根拠も画面上では説明されていなかった
- その警告は約2時間後に消え、再び作業を続けられるようになった
- ドキュメントにも月間使用上限は出てこない
- 設定ページにも現在のセッションと週次上限しか表示されると書かれており、月間上限の正体は最後まで不明のままだった
生産性の効果と最終的な解約
- 製品自体への好感は依然として大きく、理論上はあらゆることが非常によく機能し、機会も多いと評価している
- Claudeベースの独自harnessを作っており、バックグラウンドでGitHub Issueを扱うClaude Caudeも高く評価している
- Claude CoworkでNerd Enzyklopädieの執筆を続けている
- 生産性は一桁倍ではなく一段階規模で伸び、頭の中のアイデアを数年前よりはるかに速く簡単に実装できるようになった
- 製品の潜在力と実際の有用性そのものは明確に示されている
- 機能構成が細やかだという評価も添えられている
- 同時に、このような製品を運営する際の技術的・組織的な難しさも理解しており、推論の販売は増分コスト構造であるため、追加時間や新規顧客ごとに同程度の計算資源が必要になる
- 規模の経済を得にくい構造も見えている
- サービス運営の難しさ自体を否定しているわけではない
- 最終的には、Anthropicは新規顧客を一度に多く抱えすぎているようだと見て、その負担を少し減らすという表現とともにアカウントを解約した
- 製品への愛着と、実際の利用中に感じた運用上の問題とのギャップが、解約の決断につながった
- サポートの不備、品質低下、上限の混乱が積み重なった結果として整理されている
10件のコメント
「最初の数週間は高速で、公平だと感じられるトークン許容量」??
公平さって誰が決めるんでしょうか？
月額220ドルのサービスが99.5%の可用性すら達成できないのを見ると、ユーザーがいいカモなのかと思ってしまいます。Claude.ai は99%すら達成できていません。
代わりにどのサービスを利用していますか？ Codexですか？ 代替が見当たらないので、使い続けているところですが…
代替手段がないのも事実ですが、稼働率99%すら維持できないサービスは、生まれて初めて使いました……
GitHubは99どころか95と戦わなきゃならなさそう
Claude AIはプロジェクトデータの同期の問題のため移行しにくく、当面はClaude Code、Codex、Gemini CLIを併用するつもりです
代替案があれば、私も知りたいです
月間使用限度
年間使用限度
（笑）...
クロードとChatGPTが競争してくれれば消費者としてはありがたいですね（笑）。Geminiも早く本格参戦してほしいですし、中国系モデルの進歩もすさまじいので、みんな激しく競い合ってくれたらと思います。
Hacker Newsの意見
詳細な仕様書をMarkdownとサンプルコード付きで複数ファイルにして Claude Sonnet に渡しても、要件を落としたり、重複コードを作ったり、不要なデータ加工まで入れたりすることがあった。
テストも通すことだけを目的に無理やり取り繕っているように見えて、結局コードを書く代わりに大量のコードを読む羽目になった。
もともと実際にやってみると、コーディングより コードを読むこととメンタルモデルの形成 のほうがはるかに難しいのに、Gen AIを使うとその負担がさらに大きくなる。
だから今のAnthropicの価格帯では純損だと思う。
vibe coding ではなく実際のユーザーが依存するソフトウェアを作っているので、サブスクはもうすぐ解約するつもりだ。
ふだんのテスト・lintサイクルに組み込んでレビューさせたり、サードパーティ製ライブラリの評価を素早く行ったり、新しいトピックを調べたり、RFCや設計文書のたたき台を作ったり、難しい問題に取り組む際の対話相手として使うほうが合っている。
AI企業全般は好きではないし、著作権侵害の上に成り立っているという不快感も依然としてあるが、最新モデルはある面では信じがたいほど賢い。
誇張された vibecoding hype を受け入れる必要はなく、単なる生産性ツールとして使うだけでも十分に価値がある。
まったく使わなくてもよいし、特定の企業に金を払う義務もないが、vibecodingだけを見てこの技術全体を切り捨てる必要はないと思う。
システム仕様全体を任せず、設計は自分で行い、必要なら設計補助だけ受けつつ、実装は一度に一つずつやらせるほうが精度が高い。
各段階でレビューして修正させ、次に進めば、依然として全部を自分で書くより速く、しかもはるかに制御しやすい。
文書化という工程が一つ増えた vibecoding に近く、整理作業を減らしたいならSonnetよりその時点の最高モデルを使うほうがよい。
それでもどのモデルも全部を完璧に処理してくれるわけではないので、全部かゼロかの使い方はせず、
判断は引き続き自分で行いながら、役立つ局面にだけAIを当てて速度を上げるやり方が現実的だ。
非ジュニアのエンジニアはだいたいそういう使い方に落ち着いており、LinkedInやSNSのアプリ自動生成の誇張は無視したほうがよい。
似たやり方で使っていても、より速く、しかも品質の高いコードを作れており、手首への負担もかなり減った。
違いは、AIにできるところまでだけ任せ、範囲を狭く段階的に管理している点にある気がする。
小さな単位の明確な変更はレビューしやすいが、毎日 1万行のコードダンプ を渡されると評価が難しい。
あまりに多くを、あまりに速く、あまりに早い段階で押し進めすぎているのかもしれない。
バランスさえ取れれば価値は見えてくるだろうし、期待するほど爆発的に速くはなくても、一人でやるよりは依然として速い可能性が高い。
検証と確認が頻繁に必要で、計画も何度も直す必要はあるが、実装も引き続きOpusを使っている。
現在はモデルがキャッシュを保持しているためSonnetで実装するなという警告が出ることもある。
読んで理解するのに時間はかかるし、手動修正も多いが、おおむねProサブスクの範囲内で収まっている。
Claude Opus をかなり効果的に使えていて、中間グレードのサブスクでも上限に頻繁に当たることはない。
作業スタイルはautopilotではなく copilot に近く、範囲が限られたタスクだけをプロンプトで投げ、ほぼすべてをレビューしている。
こうした用途なら、先頭集団のモデルはほぼ 十分に良い水準 まで来ていると感じる。
きちんとライセンスされたコードを基盤にしたオープンソースモデルが登場して、LLM補助コーディングが commoditized されるとよいと思う。
トークンをもっと使わせてより多く請求したい一方で、予想以上に使われて現行の価格体系が持ちこたえにくくなっているようにも見える。
結局の解決策が上位プランへの移行だというなら、その二つは完全に矛盾しているわけでもない。
月100ドルで済むし、先進国で電気代より安い家も珍しくない。
自分の考えるLLM補助コーディングは、あらゆる変更とあらゆる行を完全に理解している場合のことで、それでなければvibe codingだ。
その原則を本気で守るなら、$100 tier のクォータを使い切るのは難しいと思う。
複数のモデルの中ではこれが一番よいと感じており、実作業をさせるというより、ときどき 検索エンジン代わり に主に使っている。
LLMが実際に仕事を代行するのに効率的だと感じたことはなく、昔のように技術文書がまともに使えた時代が懐かしい。
結局Claudeは、開発者体験の隙間を埋める松葉杖 に近いように見える。
使用量を使い切るのはものすごく難しく、実際の業務をかなり任せていても週平均30%程度で終わる。
ただ、Proのときは笑ってしまうほど頻繁に上限に当たり、1回のリクエストでセッション100%を超えて追加課金まで行くこともよくあった。
Max 5xは体感では5倍よりずっと大きく感じるが、Anthropicがsurge rateのようなものをあまりにも曖昧に扱っているので確信は持てない。
最近HNにあふれている Opusは終わった、Codexへ行こう 類の投稿はかなり懐疑的に見ている。
単なる腹いせもあるだろうが、一部は astroturfing の匂いもする。
実務でかなり使っているのに、上限に達したことは一度もない。
何時間もLLMを回しっぱなしにするようなやり方は、結局何をしたのか、なぜそうしたのかを追跡するのに自分の時間を浪費するレシピに見える。
心配なのは、人々が 独占的で不透明なサブスク型GenAI に依存するようになることだ。
それを堅牢な土台であるかのように見なして何かを積み上げているが、ある日その所有者がその土台を突然引き抜くかもしれない。
最近はrate limitがやや煩わしくてCCよりCodexを好んでいたが、作業のやり方自体はほとんど変える必要がなかった。
競合を圧倒できるほど金を使って参入不能な差を作り、その後で価格を好きに決めたいのだろう。
それでも今のところ競争は激しく、コーディングツールとしてはAnthropicが最良だが、その優位は以前より小さくなった。
正直、Opus 4.5 の時点ですでに十分実用的な水準に達しており、今はそのクラスのモデルがいくつもある。
Gemini Pro 3.1も似たようなものだし、現在のCodexはOpus 4.5より良く、4.7に近いと思う。
自分も同じプロジェクトでモデルやエージェントを頻繁に切り替えるが、移行コストは事実上ない。
claudeの代わりにgemini、copilot、hermesを実行すれば済むので、特定モデルへの依存は深くない。ベンダーは囲い込みを生む機能を付けようとするだろうが、上位モデルはあまりにも賢いので、必要なことをそのまま指示すれば済む場合が多い。
今のところ 唯一一貫した moat は最高クラスのモデルを作る能力くらいで、それすら浅いので、Claude Codeが明日消えても致命的ではない。
自前ホスティング可能なオープンモデルもすでにかなり近づいている。
OpenAIとAnthropicの競争も面白いし、オープンソースの流れまで加われば、近いうちにその地点に達しそうだ。
Claudeが Sonnet medium effort で1セッション上限100%と追加課金まで使い切ったうえ、53分考えたあとに、
API Error: Claude's response exceeded the 32000 output token maximum...だけを返してきた。API Error: Claude's response exceeded the 32000 output token maximumだったというジョークがぴったり当てはまる。ここ数か月で何度も見たし、最初はAWS Bedrockの問題かと思ったが、それだけではなさそうだ。
自分と同僚数人は、ここ2か月でClaudeの 認知能力の低下 を大きく感じている。
4.5は使い物になったし、4.6は本当に良かったが、個人的なベンチマークでは4.5は2-wayポインタのmerge loopをかろうじて追える程度で、4.6は3-way、1M contextでは k-way まで扱えた。
こうした追跡能力のおかげで、実際のプロダクションコードを理解して修正するのに役立っていた。
ところが2か月前から4.6が頻繁に忘れたり、愚かな判断をしたりし始め、比較してみると自分だけではなかった。
4.7も大して良くなく、ここ数週間は auto level of effort downgrade とずっと戦っている感じだ。
何か馬鹿っぽいと思って設定を見ると、こっそりダウングレードされていて摩擦が大きい。
4.6初期のように良いモデルが可能だということはすでに確認できていて、問題はAnthropicが大衆市場向けに出す過程でthrottleやdowngradeを行い、実用性を落としている点だ。
自分の考えでは、DeepSeekが近いうちに4.6+級の more-than-good-enough な水準に達すれば、みんなClaudeの「より多く払い、より少なく受け取る」流れから離れていくはずだ。
もっとすごいものが必要なのではなく、すでに可能なものを、自分たちが制御でき、meter方式ではなくprovisioned方式で安定して使いたいだけだ。
会社がこういうミスをすると腹が立つのは当然だが、しばらく制限を緩めて事実上の補償を行ったし、何より対応はかなり透明だった。
他の大手AI企業がここまで透明かはわからないので、Claudeには腹が立っても、その対処の仕方には敬意を持てる。
自分の max20サブスク は4月以降ほとんど遊んでいて、Codex 5.4と今の5.5はfast modeでも体感がまるで違う。
Opusはもっともらしく失敗し、重要な詳細の半分を忘れるか、こっそり pragmatic の名の下に技術的負債の絆創膏を貼っておきながら成功したと言い張る。
実際には変更後にシステムが壊れているのにそうだし、エラーを指摘するとさらに大きな混乱を作ることすらある。
Opusはgreenfieldの範囲をワンショットで作るには良いが、その後の反復修正や複雑な統合作業では 害になるほど悪い。
一方GPT 5.4+は時間をかけてエッジケースまで先に考え、その判断が実際に当たっていて、その後のデバッグターンを減らしたうえでちゃんと結果を出す。
1行のスクリプト修正にすら何分も「マルウェアっぽくない」「ちょっと待って」といった思考ループに陥ることもない。
コード整理は新機能実装とは別の作業であり、GLM系は見かけ上はより賢く振る舞うように見えても、実際のコードをレビューすると結局 build/prune cycle が必要だった。
「これ、race conditionだらけじゃないか？」とレビューさせる形だった。
今はCodexだけを使っていて、Claudeは信頼しづらく、データレースや否定条件の抜けを残しすぎる。
最近は Aider を使っていて、新しい学習ポリシーのせいでGithub multi AI bundleのサブスクもたぶん解約する。
新しいオープンモデルと一緒にAiderを使い、渡す前に Open Spec で要件をすり合わせる流れがかなり役立った。
AIサービスには トークン使用量を減らすインセンティブ が弱い。
トークンを多く使わせればそのぶん儲かるので、ユーザーが怒り出す直前までどこまで押せるかを試し続けるだろう。
すべてのAI企業はコスト上昇に応じて、トークン使用量と価格の間で立ち位置を入れ替えながら動いていくはずで、
私たちは沸騰寸前なのにまだ風呂だと言い張る ぬるま湯の中のカエル のように見える。
AI企業にも同じインセンティブがある。
安くなればもっと使われ、価格が原価を上回っている限り、結局利益は増えうる。
当然、自分たちのコストを下げる理由も十分にある。
だから トークン効率 だけを目標に、オープンソースの（clineフォーク） https://github.com/dirac-run/dirac を作った。
クローズドな囲い込みベンダーは時間が経つほど十分にユーザーを苛立たせるだろうと見ていて、貢献者も探している。
陰謀論めいて聞こえるが、Anthropicのような会社は、モデルが仕事を終えられないときにも利益を得る。
最近 over editing phenomenon の話も読んだが、機械は決して終わらせたがらないように見える。
まるでデーティングアプリが良いマッチングを望まないのと同じだ。
成功すればユーザーがサブスクを解約してしまうからだ。
昨日が気づきの瞬間だった。
ローカルLLMをつないだ Claude Code に簡単な抽出作業を任せたところ、10分間うなっているだけだった。
同じデータとプロンプトを
llama_cppのチャットUIからモデルに直接入れたら、1分もかからず single-shot で終わった。となると、コーディングエージェントそのものか、LLMとの対話の仕方のどこかがおかしいと考えるしかない。
今はとても単純なオープンソースのコーディングエージェントを探しているが、NanocoderはMacでインストールもうまくいかず、node-modulesが重すぎて嫌だし、Opencodeは完全なオープンソースには見えない。
当面は自分がコーディングエージェント役をしながら
llama_cppのWeb UIを使っていて、それなりにうまく回っている。リポジトリには MIT License が付いている。
「極度に単純な」コーディングエージェントが欲しいなら、むしろぴったり合うものを作れる。
自分も今週Anthropicの妙な挙動にうんざりして、実際にそうしてみたが、数日で使えるものを立ち上げられた。
自分の場合はBeOSや古いMacではClaude Codeがないので、なおさら自分でブートストラップしてつなぎ合わせるほうが簡単だった。
この過程を踏むと、モデルが実際にどう動くのか、Claude Codeの中でどれだけ ばかげた絆創膏パッチ が動いているのかもかなり学べる。
もちろん、エージェントやハーネスが解決しなければならない難しさもある程度わかるようになる。
そして
llama_cppに比べてClaude Codeが遅い問題は自分も経験したが、推測では APIトラフィックがサブスクトラフィックより優先 されているように思う。APIのほうがずっと速く感じるが、そのぶん費用もはるかに高い。
構造は思っているよりかなり単純だ。
vLLMにエンドポイント文法だけ変える薄いshimを挟んで、実際にやってみた。
ときどき同じClaudeモデルでも、あるときは論理エラーを出し、あるときは出さない。
Claudeの性能は時間依存的 な面が強いように見え、それを示すグラフもある。
https://marginlab.ai/trackers/claude-code/
また、公にはあまり語られないが、同じモデルでも quantization によって結果がかなり違うと感じる。
4-bitと8-bitでは計算要件も異なり、出力品質も違う。
https://newsletter.maartengrootendorst.com/p/a-visual-guide-to-quantization
フロンティアモデルがまったく同じように動くわけではないのはわかるが、ピーク時間帯にはメモリやリソース使用量を減らすため、どこかに fidelity dial があって性能を調整しているのではないかと思ってしまう。
60%の線が95%信頼区間内に収まっているなら、単なる測定ノイズかもしれないと思う。