1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Claude Codeの3月騒動で見えたこと。最強モデルより、まず“通ること”が大事だった話

1
Posted at

thumbnail-note.png

正直、このポストはかなり本質を突いていると思う。 Codeを触っている人ほど、「モデルが賢いか」より先に「今日はちゃんと通るのか」に振り回された3月だったんじゃないかな、という感覚がある。今回の話は、単なる愚痴ではなくて、AI駆動開発のボトルネックがモデル性能だけではないことを、かなり生々しく見せている。 ## このポスト、何を言っているのか

投稿の主張はシンプルで、でも重い。

3月18日のある時間帯に、 Code利用中に17分で53回もHTTP 529が出た。しかもそれは、ちょっと遅いとか、一時的に返答が鈍いとか、そういうレベルではない。サーバー側が処理しきれず、リクエストを受け切れていない状態だった、という話だ。 > つまり、「自分の使い方が悪かったのかも」ではなく、
そもそも向こう側が詰まっていた可能性が高い、ということ。

しかもこの人は、上位モデルのOpus 4.6を使い続けた結果、Max枠がどんどん削られて、最後はSonnetへ移るしかなかったと言っている。ここで大事なのは、本人がそれを“最適化”ではなく“強制”と表現している点だと思う。自分で賢くチューニングしたというより、使いたい構成を維持できなくなったわけだ。 ---

529って、実はかなり嫌なエラー

HTTP 529は、ざっくり言うと過負荷による拒否だ。429みたいな「契約上・設定上のレート制限です」という話に近いようで、実務上のニュアンスはかなり違う。Anthropicのドキュメントでも、529はoverloaded_error、つまりAPI全体の高トラフィック時に起きる一時的な過負荷として説明されている。 API Docs

ここが厄介で、エンジニア側から見ると「プロンプトを削る」「会話を短くする」「モデルを落とす」みたいな自衛はできても、サーバー混雑そのものはユーザー側でどうにもならない。だから、体感としては“自分の工夫が効きにくい不調”に見える。これが、ただの使いすぎ問題よりストレスが強い理由だと思う。 さらにややこしいのは、 の利用上限がClaude Codeだけで閉じていないこと。ヘルプには、 、 Desktop、 Codeの利用が同じ使用量の枠を共有すると明記されている。しかも有料プランでは、5時間セッションと週次上限の両方をUsage画面で見る設計になっている。つまり、「今日はCLIしか触ってないのに、なぜか重い」ではなく、面で消費している可能性もある。 ---

3月のClaude界隈、実際に不安定だった

このポストが刺さるのは、3月に似たような“詰まり方”が本当に続いていたからだ。ステータスページを見ると、3月18日にOpus 4.6のエラー増加、 .aiの障害、 Codeのログイン影響が記録されている。その後も3月21日にはOpusとSonnet 4.6の両方でエラー率上昇、さらに3月25日〜27日にもOpus 4.6やSonnet 4.6でのエラー増加が複数回出ている。一度だけの偶発事故ではなく、月内に断続的な不安定さがあったと見たほうが自然だと思う。 ステータス

同じ月には、Sonnet 4.6の投入や、 Code/Coworkでのcomputer use機能の拡張も進んでいた。Sonnet 4.6は2月17日に、コーディングやcomputer use、長文推論、エージェント計画を強化したモデルとして公開され、3月23日にはPro/Max向けにcomputer useの研究プレビューも広がっている。機能拡張が前に進む一方で、可用性との綱引きが露わになった月だった、という見方はかなりしっくりくる。 > AIツールって、性能が上がるほど幸せになる、とは限らない。
性能が上がるほど、需要も集中しやすい。


ここが本当に重要だと思う

この件を「Anthropic大丈夫か」で終わらせるのは、ちょっともったいない。個人的には、もっと重要なのは、AI駆動開発の評価軸が変わってきたことだと思う。以前は「一番賢いモデルを選ぶ」が正解っぽかった。でも今は、それだけでは足りない。通るか、止まらないか、予算内で回り続けるかまで含めて、モデルを選ぶ必要がある。 CursorでもClaude CodeでもGitHub Copilotでも同じだけど、現場で効くのは“理論上の最高性能”より、“今日ちゃんと仕事を前に進める構成”なんだよね。Opusを主役にしたい日があってもいい。ただ、常用系はSonnet、詰めや難所だけOpusみたいな運用のほうが、結局は安定する場面が増えている気がする。これは妥協というより、実務の設計だと思う。


僕ならどう組むか

僕なら、もう単一モデル前提では組まない。

普段の実装、調査、リファクタ、雑多な修正はSonnet系。重い設計レビュー、難所のバグ、長い思考が欲しいところだけOpus系。さらに、止まったときの逃がし先として別ベンダーや別ワークフローも持っておく。“モデル選定”ではなく“可用性設計”として考える感じだ。 個人開発者やスタートアップほど、ここは大事だと思う。大企業みたいに止まっても他の人が吸収してくれるわけじゃない。ひとり開発、少人数開発では、AIの数時間停止がそのままスケジュール遅延になる。だから、最強モデルを愛することと、事業を止めないことは分けて考えたほうがいい。3月のClaude Code騒動は、その現実をかなりはっきり見せた出来事だった。 ザ・レジスター+2

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?