Jarred（Bunから）によると、最近のユーザー数の急増が原因で、いくつかのエラーが発生しているらしいよ（つまり、OpenAIから流れてきた人たちね）。

最初のスケーリングイベントは、彼らの大成功したスーパーボウルの広告の後で、2回目は週末に歴史の正しい側にいたときだった。

何か見落としたかな？なんでみんなOpenAIから移ってるの？gpt-5.3-codexが出てから使ってるけど、Opus-4.6と一緒に使ったClaudeの方が常に良くて、正確だし、幻覚も少ない。20ドルのOpenAIプランでできることの方が、Claude Max 100よりも多いよ。

claude.aiと長めのインコグニートチャットをしてたんだけど、急に応答が止まった。トランスクリプトをメモ帳に保存して、別のタブでダウンしてるか確認したんだ。インコグニートセッションは消えちゃったのかな？再投稿すれば復活できるかも。Geminiではそうしたことができたけど、そこには「Geminiが言った」みたいなコードがあったから、ここでは見当たらない。誰か知ってたら、解決策教えてほしいな。

週末にOpenAIのトラブルでAnthropicに切り替えたんだけど、サービスを使い始めてまだそんなに経ってないから、レスポンスやコード生成の質についてはコメントできない。ただ、ダウンが本当に影響大きい。Claudeを使おうとした半分以上がエラーかダウンに遭遇してる気がするし、Claude Codeの使用制限もかなり厳しい。Claudeにデータベースを検索するウェブサイトを作ってもらったけど、作成に約6分かかって、その間に4時間のクォータの60%を使っちゃった。基本的なフォント変更を頼んだ後は再度見つけられなかったし、制限がかかるまでそれ以上は無理だった。30分も経たずに4時間のウィンドウが使い切っちゃった。一方、ChatGPT Codexだと、数時間のコーディングセッションでも4/5時間のウィンドウの終わりには20%以上残ってるんだよね。

確かに、シンプルなケースでは不利かもしれないけど、複雑になると、唯一正常に動かせるものだから勝つんだよね。まぁ、真剣に使うならMaxサブは必須だね。

もう1年近くAnthropicをほぼ専用で使ってるけど、こんなことは一度もなかったよ。ダウンタイムなんて経験したことない。チャットでランダムなエラーが出ることはあるけど、それは次のリクエストで即解決。デスクトップアプリもモバイルアプリも、いくつかのアプリでAPIを使ってるけど、信頼性に問題はない。個人用のAPI利用で月に約1500ドル払ってるよ。

場所によるのかもね？今週Claudeをたくさん使ったけど、全然ダウンタイムなかったよ。

Codexの制限が変だな、基本のサブスクリプションの制限を使い切るのもやっとだよ。両方を組み合わせられるからClaude maxに切り替えたんだ。週末からずっと問題が続いてる。動いてる時は最高なんだけど、正直この実験をキャンセルしようか真剣に考えてる。

これが起こったのは、君と他の多くの人が今週末に切り替えたからだよ。

問題が増えてるのは、みんなが君と同じことをやってるからだと思う。使用量が急増してるんじゃないかな。

そうだね、これはAnthropicにとって大きな問題で、残念ながらまだChatGPTのサブスクリプションを解約できてない理由なんだ。

またダウンしてる。もう一回あったらCodexに移るわ。いや、実際に自分の脳を使ってコーディングする方がマシかも、神様、お願いだから。もうやってらんない。

また戻ってくるよ :)

もう一度頭を使うことを学んでほしいな。自分でうまく作業できないのに、LLMエージェントを適切に監督できるとは思えない。もしエージェントが自分よりかなり速く作業してるなら、実際には監督できてないってことだし、変なことが入り込む可能性があるよ。ボイラープレートを生成したり、手作業だと面倒なAPIの変な部分を処理するのが少し早くなるのはわかるけど、根本的にエージェントを使って手作業よりもずっと速くやってるなら、ちゃんと監督できてないってこと。だから、手作業に戻った方がいいよ。練習のためにも、たぶんそのくらいの時間は手でコーディングするべきだし。

そうだね、人が増えて仕事が乱れてるけど、OpenAIの消費者サポートの低下を目の当たりにするのは楽しいよ。あのJonny Iveの製品、何だったんだろうね。

Jony Iveのような地位の人が、詐欺的なAltmanの空虚な約束に引っかかるなんて、本当に驚きだよ。もっと期待してたのに。

今後、インシデント対応のコミュニケーションが改善されるといいな。2.5時間も「この問題を引き続き調査中です」だけって、ちょっとひどいよね。過去のインシデント処理の履歴も同じくらい悪いし。

彼らはClaudeが復旧するのを待ってるんだ。それを使ってClaudeがダウンしてる理由を調べようとしてる。

彼らのビジネス全体が「人間はもう何もできる必要がない」という前提で成り立ってるから、何を期待してたの？彼らの脳はダウンしてるよ。

Anthropicの社員がこの投稿をボットしてるの？このサイトで一番投票されるべき投稿なのに、最初の3ページには全然ないよ。あと、Claudeを使ってコーディングすると、働いてる会社が儲かるかもしれないけど、自分のスキルを忘れちゃってるよ（実際に見たことある）。新しいことも学べてないし、プロとしてはダウングレードしてる。次の面接ではAIスキルを試されることはないよ。

> 次の面接ではAIスキルを試されることはないよ その意見には賛成だけど、最近面接を受けたことある？俺が関わった90%の会社はAIスキルを求めてたし、どうやって生産性を上げるために「活用」してるかを説明しなきゃいけなかったよ。

> プロとしてはダウングレードしてるよ いや、逆だよ！すごくパワフルなツールを使って学んでるんだ。これは、テキストエディタやコンパイラみたいなツールだよ。でも、コンピュータ言語の文法の細かいところや気まぐれにこだわるんじゃなくて、論理や機能にもっと焦点を当ててる。建設の例えで言うと、レンガ職人からエンジニアに昇進するような感じ。様々な形のシャベルや手押し車を使うのと、掘削機やダンプカーみたいな機械化された道具を使うのとでは、土木工事のやり方が全然違うよね。もちろん、レンガ職人のマスターになることに焦点を当てるのは立派なことだし、冗談抜きで、レンガ積みはその分野で美しい成果を生む素晴らしいスキルだよ。そういう人たちにはAIは本当に不要だと思う。存在の脅威だけど、必要ないね。

> でも君は自分のスキルを忘れてるよ それは「スキル」を何と考えるかによるよね。文法はいつでも再学習できるけど、建築を構築した経験やメンテナブルなコードベースを開発した経験は絶対に忘れないよ。LLMは君のために「何を」するだけで、「なぜ」を理解するわけじゃない（もしくは使い方を間違えてる）。

> 君の次の面接ではAIスキルを試されることはないよ かなり大きな岩の下に住んでるね。

> 新しいことを学んでない それは全然違うと思う。むしろ「使い方次第」だよね。AIを使い始めてから、プロジェクトにすごく役立ってる。もし間違ったやり方をしてたら教えてくれるし、もっと良いアプローチを提案してくれるんだ。計画が曖昧な時には、知識を補ってくれるしね。

新しいことを学んでないなら、やり方が間違ってるよ。LLMをただ使うのと、最適に使うのでは大きな違いがある。ちゃんとしたハーネスを使って、自分のワークフローにカスタマイズしたり、サブエージェントを使ったりすることが大事だよ。これは別のスキルセットだから、AIツールなしで手動コーディングが必要な仕事に行くなら、そのスキルを磨くことに集中した方がいいよ。ちなみに、私の前回の面接ではAIスキルを試されたからね。

> でも君は自分のスキルを忘れてるし（実際に見たことある）、新しいことを学んでない。これは間違いだよ。手でコードを書くことを忘れるかもしれないけど、今までやる時間も能力もなかったことに挑戦してるし、15年のエンジニアリング経験では得られなかった経験を積んでる。 > 次の面接ではAIスキルを試されないだろうね。それが私にとって良いシグナルになる。もし次の面接がリートコードスタイルだったら、私は壊滅的に失敗するだろうけど、もうコードを書くことに興味はないんだ。AIの方が私より上手だから。私は問題解決者になりたいんだ。

AIは、Githubのような非AI企業でも、AIを活用したスケールアップの使用パターンに迅速に適応しなければならない状況を作り出した。GPUの容量は数ヶ月から数年先に事前に割り当てられていて、推論やトレーニングのための大きな塊で存在してるから、実験的な研究の仕事をスパイクの時に食い潰すための控えめなバッファがあるだけなんだ。リザーブ容量をたくさん持つのは経済的に成り立たないよ。特に今はサプライチェーンが大きな負担を抱えていて、チップ生産がボトルネックになり始めてるからね。もし量子化されたり、何らかの形で削減されたモデルを提供することで回避できたとしても（これは時々使われる一般的な戦略）、新しい人たちは失望するだろうし、それは信頼を損なうことになる。AIをみんなに提供するためには、少し9の数が減るのは合理的な妥協かもしれないね。技術が自律的なキルチェーンに搭載できるほど信頼性がないことを証明する一つの方法だね（笑）。

「大丈夫、みんなやってるから」

自律的なキルチェーンが1つの9以上を必要とするとは限らないよ。今も20%未満のターゲティング精度で戦争が起きてるんだから。

> AIは可用性の単一9を標準化している、... ちなみに、私は毎日AIを使ってコーディングを手伝ってもらってる。... そして、LLMの出力も単一9を標準化しているみたいだけど、それが十分かどうかはわからない。セキュリティの問題やパフォーマンスの問題、膨大な量のボイラープレートが生成されて、メンテナンスが必要になるのがいつも厄介だし、今は稼働時間の問題もあるから、これらのAIツールを使うには、もっと頭を使わないといけないって気づいたよ。生成されたコードが期待通りに動かないこともあるしね。まず、インフラについて全く知らないなら、すでに大変な目に遭うことになるよ。エージェントがあなたのGitリポジトリをrm -rfしてOSを壊すとき、どう compartmentalize するかもわからなかったら、後悔することになる。秘密が公開されることになったら、さらに最悪だね。今や、コーディングの基礎だけじゃなくて、スタック全体に慣れておく必要があるみたい。プロンプトエンジニアになるのは確かに簡単そうに聞こえるけど、実際はそうでもないよ。

検証コード付きのメールが届かない。 > 代わりに検証コードはある？ > 送信されたリンクから生成されたコードを入力してね。 > 一部のメールプロバイダーで配信の問題が発生していて、解決に向けて取り組んでいます。 > ジャンク/スパムフォルダーや隔離フォルダーを確認して、support@mail.anthropic.comが許可された送信者リストに入っているか確認してね。1時間前からコードを待ってるのに。ちなみに、12ヶ月前に自分でソースコードを直したことがあるよ。

> 12ヶ月前に自分でソースコードを直した。昨日友達に言ったんだけど、新しいことではもううまくできないよね。数年前のAndroidライブラリで新しいプロジェクトを始めたんだけど、問題にぶつかると、もう公共のインターネットには情報がない可能性が高い。昨日はこれで大変な目に遭ったよ。問題を解決しようとしたけど、自分の解決策は明らかに最適じゃなくて、数時間後に嫌になった。でも、良い情報が見つからなかった（インストゥルメンテッドテストの場合のマルチライブラリAndroidManifestのマージ）。それで、Claude Codeに失敗する明確な例を持って行ったら、完璧に解決してくれた。その後、別のセッションでこのマージの仕組みと、なぜその解決策が機能するのかを尋ねたら、良い答えが返ってきた。でも、出典を求めたら何も提供できなかった。GoogleやKagiで調べても、何も見つからなかった。解決策を知っていてもね。情報は公共の場から隠されているか、AGPのソースコードの奥深くにしか存在しなかった。これまでに同じ問題を抱えていた人は他にもいるはずなのに、インターネット上にはこの問題を解決するための適切な例が全くないし、マージの仕組みを示唆するものもない。既存の情報は、インストゥルメンテッドテストとは全く別の手順についてのものだし。だから、もう自分で解決できるかどうかわからない。人々はもうあまり情報を共有しなくなってるから。StackOverflowを見てみて。

Anthropicは2023年から私のOutlookのメールアドレスにメールを送れたことがないんだ。メールアドレスを変えると助かるかもね。

これは、クライアント向けの自動化システムをこれらのAPIの上に構築する際の実際の運用上の問題だよね。私はクライアントのためにチャットボットやワークフロー自動化、AIエージェントシステムを作ってるんだけど、一番難しいのは、自分のシステムの稼働時間が基本的にLLMプロバイダーの稼働時間に制約されていることを説明することなんだ。実際の運用で役立ったパターンは以下の通り。 1. 複数プロバイダーのフォールバック。会話システムの場合、デフォルトでClaudeにルーティングして、5xxエラーの時はGPT-4にフォールバックする。フォールバックに当たるリクエストは2-3%だけど、応答の質の違いは大体許容範囲だよ。これで、ハードな障害を少しの質の低下に変えられる。 2. 非リアルタイムワークフローのための非同期キューイング。ドキュメントを処理したり、レポートを生成したり、バッチ分析を行うときは、APIを同期的に呼び出さない方がいい。作業をキューに入れて、指数バックオフで再試行して、APIが回復したときにシステムが自己修復できるようにする。私たちの自動化パイプラインのほとんどは、500msではなく15分のSLAで動いてる。 3. リアルタイムシステムでの優雅な劣化。チャットボットや音声エージェントの場合、スクリプト化されたフォールバックパスを用意する。「今その処理がうまくいかないので、人間に転送しますね」は、接続がハングしたりエラーメッセージが出るよりずっといいよ。 もっと広い問題としては、私たち全員が「四つのナイン」がまだロードマップにすら載っていないインフラの上に構築しているってことだね。それを考慮して設計するなら問題ないけど、LLM APIは他の不安定な外部依存関係と同じように扱うべきで、データベースクエリのようには扱わない方がいいよ。