クロードはブロックを組み立てるのが得意だが、作ることにはまだ苦労している

93日前原文(www.approachwithalacrity.com)

概要

Opus 4.5（Claude）は大きな進化を遂げたが、全能ではない。
実用例では単純作業の自動化には強いが、抽象化や本質的な設計は苦手。
AWS移行やSentryデバッグなどの反復作業は得意分野。
Reactの複雑なリファクタでは、誤った提案をしやすい傾向。
良い抽象化やインフラがあれば力を発揮するが、それ自体は創造できない。

Opus 4.5の実力と限界

Opus 4.5（Claude） の登場で「AGIが近い」との声が高まる現状
実際のコードベース で数週間使った結果、単純な評価では語れない現実
既存の良質な設計や抽象化 を組み立てるのは得意だが、ゼロから創出するのは苦手
三つの実例（Sentryデバッグ・AWS移行・Reactリファクタ）で傾向を検証

Sentryデバッグ自動化の成功体験

PlaywrightとSentry を組み合わせたデバッグループの自動化
Claude が自律的に90分間問題解決に取り組み、最終的に成功
Sentryのトレース を活用し、手動の試行錯誤作業を大幅に短縮
FastAPIのStreamingResponse に関する特殊ケースも自力で発見
反復的な検証作業 では人間の負担を大きく軽減

ModalからAWS ECSへの移行事例

ModalからAWS ECS への移行をClaudeが3時間で一発成功
TerraformやAWS CLI を駆使し、Dockerfile作成や権限設定まで自動化
従来なら1〜2日かかる作業 を深夜に短時間で完了
細かいミスやドキュメント調査 をAIが肩代わりするメリット
抽象度の高いインフラ構築 でも成果を発揮

シニアエンジニアの視点とAIの壁

優れたエンジニア とは、非自明な改善点を見抜き、抽象化を洗練できる人材
sweeks氏 のように「コードガーデニング」を地道に行う姿勢が重要
AIは“ハック的な修正” には対応可能だが、本質的なリファクタは苦手
Reactの複雑なリファクタ では、Claudeが非効率な提案をし、コードベースを悪化させるリスク
本質を見抜く力や美意識 はAIにはまだ備わっていない

Claudeの強みと限界

良質な抽象化やインフラ（レゴブロック） があればAIは高いパフォーマンスを発揮
SentryやTerraform、Playwright などの優れたツール上では強力な自動化が可能
一方で、抽象化自体の創出や設計 はAIには困難
「Claudeには魂がない」 という指摘：美しいものを生み出す意志や本質的な設計力の欠如
AIは優れた道具 だが、エンジニアを完全に置き換える存在ではない

今後のエンジニアとAIの関係

AIの進化でルーチン作業は自動化 され、エンジニアの価値はむしろ上昇
良い抽象化・インフラの設計 がますます重要に
AIの限界を理解し、適切に使いこなす ことが現代のエンジニアに求められるスキル
Opus 4.5は素晴らしいツール だが、過度な期待は禁物
「AI時代のエンジニアの本質」 を再認識する必要性

Hackerたちの意見

私の経験では、Claudeは「良いジュニア開発者」みたいな感じだね。できることはすごく上手だけど、他のことはFUBARしちゃう。でも全体的には、ちゃんと説明すればタスクを任せられる存在。もし/いつかミッドレベルのエンジニアの能力に達したら、革命的になると思う。普通、ミッドレベルのエンジニアは、最小限の監視で正しいことをやってくれるし、不完全な指示を理解して質の高い結果を出せる（しかもジュニアをトレーニングすることもできる）。その時点で、人間のジュニアエンジニアが必要なのは、彼らがアーキテクトに成長して、Claudeエージェントの群れをまとめてアプリケーションを開発したり、複雑なタスクやイニシアティブを完了させたりするため。そうなると、Claudeは何ができるかっていうと…ビジネスや市場全体を分析して、製品の特徴や業界の非効率、ギャップ分析を決定して、それに対処するプロジェクトを定義し、エージェントの艦隊を調整して、ビジネス全体を変えたり、根本的に方向転換させたりすることができるの？ CEOと大規模なClaudeアカウントだけが残るなんてことにはならないと思うけど、考えれば考えるほど、完全にSFってわけでもない気がする。

└

> CEOと大規模なClaudeアカウントだけが残るなんてことにはならないと思うけど、考えれば考えるほど、完全にSFってわけでもない気がする。その時点で、CEOは本当に必要なの？

└

> 私の経験では、Claudeは「良いジュニア開発者」みたいなものだ。もう何年もこれを言ってるよね。あなたには同意しないけど、これらのツールが「素晴らしいシニア開発者」に卒業するのはいつなの？サム・アルトマンが約束した「2025年末までに超人的なコーダー」はどこにいるの？これらの企業が宣伝しているベンチマークと、実際のツールのパフォーマンスとの間にこんなに大きなギャップがあるのはなぜなの？理由はわかってるけど、詐欺やガスライティングは疲れるよね。[1]: 実際、私は彼らを「良い」ジュニアとは言わない。良いジュニア開発者と一緒に働いたことがあるけど、彼らはどんな「AI」システムよりもずっと能力があるから。

└

クロード（他のエージェントもだけど、主にクロード）との経験は本当に混沌としてる。時には最小限のプロンプトで、20分後にはきれいなPRを作り出して、すべてがうまくいくこともあるけど、そうじゃないこともある。時には大きなプロンプトを受け入れて（自分のプロンプトや他のLLMが作ったもの、計画モードによるものなど）、成功することもあれば失敗することもある。私にとって、失敗ケースのほとんどは、クロードが文脈の中の矛盾する情報を理解できず、ただ止まって「それは解決できません」と言う代わりに、全く間違った方法で解決しようとすることだ。それが、私が考えるのと同じ前提を持っていることが多いから、計画を読むと問題なさそうに見える。労力のレベルも測りづらい。クロードは、私が1週間かかることを1時間で終わらせることもあれば、私が20分でできることに1時間かかることもある。まるで二つのレベルのコンプライアンスを強制しなければならないみたいだ。コードはビジネスの要求に応えているか、コードベースと整合しているか。最初の方は比較的簡単だけど、それだけやっても、クロードが探索中にsome_file.{好きな言語の拡張子}を見なかったせいで+1KLOCを生成するような奇妙な結果を生むことがある。ある機能ブランチでレガシーコードの5つのバージョンを作成することもある。兄弟よ、何と互換性を保とうとしているんだ？潰されて忘れ去られるコミットか？それなら、圧縮を行って、これら5つのバージョンのうちどれが「ライブ」かを忘れて、間違ったものを更新することになるかも。クロードは良いジュニア開発者の仕事をするかもしれないけど、今日雇われたジュニア開発者からのPRとしてレビューされるべきだ。

LLMはただの優れた検索機能だよ。何かを作るように頼むと、事前にトレーニングされた重みの中で検索してる。何かを見つけてほしいと頼むと、コードベースの中で意味的に検索してる。何かを修正してほしいと頼むと、その両方をやる。これがただの検索だって理解すれば、すごく良い結果が得られるよ。

└

「ただの検索」って呼ぶのは、コンパイラを「ただの文字列操作」って呼ぶのと同じ。間違ってはいないけど、ポイントを完全に見失ってる。

└

より良いメンタルモデル: それは人間の知識の損失圧縮で、斬新（時には役に立つ、時には雑）な方法で解凍して再結合できるもの。従来の検索は単に取得するだけだけど、LLMは合成もできる。

└

ある程度同意するけど、特に論理の使い方に関してね。彼は人間の言語から論理を引き出すだけで、実際、あれはめちゃくちゃなんだよね。以前にも言ったけど、人間の活動の大半は派生的だと思ってる。誰かに新しい動物やエイリアン、ランダムな物体を考えさせると、必ず以前に見たものを基にするんだ。本当にオリジナルな考えや物はこの世界では絶対に珍しいし、ほとんどの「オリジナルな」考えは他人が作ったものを参考にしている。そういう人たちは自然界からインスピレーションを得ているんだよね。私たちは、物Aと物Bを組み合わせて「新しいものを作った！」って発表するのが得意なんだ。誰か、完全にオリジナルなコンセプトを返信してくれ！最近、ゲームのプロトタイプを考えているときに、魔法ベースの物理システムを作ろうとして同じ問題に直面したんだ。

└

それは違うよ。

└

> ただの検索だと理解すれば、いい結果が得られる。これは問題を過小評価していて、文脈を無視していると思う。検索エンジンで検索するのがどれだけ

└

これは非常に役立つモデルだけど、完全ではないね。新しいものを作るなら、一日中かかるし、たくさんのガードレールが必要だってことを認めなきゃいけない。でも、その概念を後で検索することができる（リポジトリをワークスペースに追加して、プロンプトを使う）と、エージェントはそれを広く使われているパターンのように他のところにも適用するんだ。「ただ検索する」っていうのはちょっと合わないね。後で簡単に検索できるように何かを作るために、検索エンジンをどう使うかを考えたことはないよ。

└

検索がそのものの複雑な関係を理解する能力を捉えているとは思えない。2000行のPRの中で本当のバグを見つけるのは検索じゃないよ。

└

どうして誰もがこんなことを言えるのかよくわからない。確かに良い検索だけど、アイデアを組み合わせたり、論理的に考えたり、誰もが絶対に聞いたことがないような複雑なタスクをこなすこともできるんだ。

Claudeが「悪い」Reactコードを書いたという逸話には、あまり納得できないな。 > でも文脈的に見れば、これは明らかにおかしい。キーとIDが同じ上流ソースから来ていることは知っていたから、正しい解決策は上流ソースにもIDを渡して、キーを持つコードが高速に検索できるようにすることだった。Claudeもそんな間違いをすることがあるけど、「呼び出しコードも修正していいよ」とか「もっと良いやり方ない？」って言うと、最適な解決策を提案してくれる。私の予想では、Claudeは問題を解決するために最小限の編集をするようにバイアスがかかるようにトレーニングされてるんだ。これは望ましい特性で、6ヶ月前にはLLMに対する一般的な不満が、小さな変更を頼むと、何十行も追加で書き直されることだった。だから、「より効率的な実装を常に探して、大きな変更を伴うかもしれないものをユーザーに提案する」というCLAUDE.mdのルールを追加すれば、著者の不満は解消されるんじゃないかな。

└

（著者です） > Claudeが「悪い」Reactコードを書いたという逸話には、あまり納得できないな。そうだね、それは公平だ。友人もTwitterで指摘してたし（https://x.com/konstiwohlwend/status/2010799158261936281）、その具体的な問題についてもっと技術的な詳細を話したよ。 > Claudeもそんな間違いをすることがあるけど、「呼び出しコードも修正していいよ」とか「もっと良いやり方ない？」って言うと、最適な解決策を提案してくれる。私も同意するけど、Claudeが将来的に自分の間違いを見つけられるとはあまり楽観的じゃないな。逆に、より賢いモデルなら、より大きな規模で間違いを見つけられるかもしれないと思う。 > 「より効率的な実装を常に探して、大きな変更を伴うかもしれないものをユーザーに提案する」というCLAUDE.mdのルールを追加すれば、著者の不満は解消されるんじゃないかな。それについてはちょっと疑問だな！ CLAUDE.mdを更新しても修正できないようなことがいくつかある気がする。Pythonでよく見かけて、CLAUDE.mdの指示にもかかわらず常に修正しなければならない他の問題は、 - 簡単な関数を早めに返す代わりに、たくさんのネストしたif文を書くこと - インポートを関数内に入れる代わりに、トップレベルに置くこと - 例外を飲み込む代わりに、発生させること（常に大きな問題）これらは小さいけど、Opus 4.5でもまだこれらの簡単なタスクに失敗することができるモデルの限界を示していると思う。

└

トレーニングを元に戻そうとする指示を追加することは、最初から過度に一般化を含めない方が悪い結果を生むと思う。著者は不満を言っているのではなく、トレードオフを文書化しているんだと思う。

└

そうだね、でも大事なポイントは、AIを管理するには新しい人間のスキルが必要ってことだよ。言ってみれば、馬を手綱で操るようなもんだ。結局のところ、これらのAIツールは、職人の時代から電動工具や機械に移行するようなもので、手術用のナイフから機関銃に変わる感じ。人間のように理解することなく、速いペースで動くから、すべての副作用や大きな仮定を理解する時間を人間に与えないんだ。だから、人間はそれを正しく、適切なスケールで管理することに適応しなきゃいけない。それが学ぶべきことになるんだよ。

└

> 私の予想では、Claudeは問題を解決するために最小限の編集をするように訓練されていると思う。でも、私は同じ感覚は持ってない。Claudeは他のLLMと比べて、問題を解決するためにコードを出しすぎる傾向があると思うんだ。

└

確かに、トレーニングパラメータがこれを促進してる。AIは実際にあなたを騙そうとしているし、それは確かだよ。説明するのが難しい、または一度に出力できないほど複雑な解決策は論外。AIは、こういう問題を与えられると、一発解決を優先する傾向がある。すべてのトレーニングが短い解決策に偏っているからね。多段階の超複雑な解決策を持つトレーニングデータを与えるのは実用的じゃない。考えてみて。強化のために与えられる何千もの質問…トレーナーはそれをできるだけ効率的に処理しようとするから、読みやすい問題で短い読みやすい解決策でなければならない。だから、AIは短くて読みやすい解決策に偏ることがわかる。次に、読者を騙すような解決策はトレーニングを通過する。定義上、この基準を満たす質問/解決策のペアが確実に存在するのは、私たちトレーナーが騙されていることに気づいていないから。だから、このデータがトレーニングに漏れ込んで、結果としてAIは欺瞞に偏ることになる。要するに、AIはあなたを騙すように訓練されていて、一度に読みやすいコンテキストに収まる最良の解決策を提供するようになっている。理論的には、完璧な強化データがあれば、私たちが望むことをさせることができる。求めている信頼性は、このハードルを越えたところにあるようだね。

大体、この記事には同意するよ。Claudeは低レベルの開発作業をするのが得意で速い。複雑なメカニズムの構文を正しくすることや、編集・実行・ログ読みのループを実行すること、複数ファイルの編集をすることができる。これが私が好きな理由なんだ。彼は私の雑用をやってくれるくらい賢い。プログラマーにとってタイピング速度は重要じゃないという考えを再考しているんだけど、候補者をそれで判断するのは変だと思うけど、今は別の意味で感謝してる。速く正確にタイピングできると、イライラが減るし、イライラが少ない人は考えていることを試す可能性が高いからね。LLMのおかげで、今まで試したことのないことをたくさん試せるようになった。ちょっとしたことでつまずかないから、学びが早くなってる気がする。

└

> 速く正確にタイピングできると、LLMはコードを迅速に生成できる。でも、それが文法的に、ましてや意味的に正確である保証はない。 > 私は、ちょっとしたことでつまずかないから、学びが早くなってる気がする。気になるんだけど、LLMを使ってコードを生成することで実際に何を学んだの？私の経験は全く逆だよ。生成されたコードを実行しても何も学ばないし、理解しようと掘り下げない限りはね。実際、レビューして修正しなきゃいけないから、そうなることが多いんだ。だから、実際にはあまり時間やエネルギーを節約できてない。LLMは学びや理解のために使ってるけど、つまりインタラクティブなドキュメントサーバーとしてね。でも、これは君が言ってる使い方じゃないよね。それにしても、情報を実際のAPIや使用ドキュメントで確認しなきゃいけないことが多いし、しばしば幻覚を見たり、古かったり、単純に間違ってたりするからね。

└

> 自分が学ぶスピードが速くなってる気がする。そう感じてるんだね。でも、それは本当なの？もし今すぐ君から全てのLLMを取り上げたら、今の君はLLMがなかった頃の君よりも優れているの？夢の中では飛べる気がするし、夢を見ている限りその感覚は本当なんだ。でも、その感覚の主題は決して本当ではなかった。

└

フィルムからデジタルへの移行に似てる部分があるね。再挑戦の限界コストがほぼゼロになったっていう点で。撮影ごとにお金と準備時間がかかると、クリエイターは頭の中で事前に最適化して、アイデアの半分も探求しないことが多かった。撮影が安くなると、クリエイターは思考を外部化できて、試したり、見たり、調整したり、そうしなければ発見できなかったことを見つけることができるようになった。クリエイターはもっと自由にさまよえるようになった。失敗しても大丈夫だと思えるようになったから、直感に従うことができるようになった。それは探求する価値のあるスペースだよね。デジタルはアートを魔法のように改善したわけじゃないけど、もっと多くのクリエイターがアイデア、試行、フィードバックのループに入れるようになった。LLMも似たような感じで、自分自身でより良いアイデアを提供するわけじゃないけど、アイデアが実現可能かどうかを見つけるのを妨げていた摩擦を取り除いてくれる。それが学ぶ頻度や、考えを放棄する前にどこまで押し進めるかを変える。私もたくさんの小さなプロジェクトをやってみたけど、もしLLMの摩擦がなかったら絶対に挑戦しなかったと思う。もちろん、学んだことはそれほど多くはないけど、それでも何かの価値にはなるよね。編集: ただし、危険なのはアイデアが多すぎることじゃなくて、動きと進歩を混同することだ。摩擦が高いと、思考を事前に圧縮し、内部でリハーサルし、外部化する前に矛盾に気づくことを強いられる。そのマリネーションの段階（ゆっくり何かをすること）は本当の仕事をする。メンタルモデルを構築し、味を鋭くし、何を試すべきでないかを教えてくれる。それが、ループが十分に安くなって、可能性を世界にばらまいて何が残るかを見ることができるようになると消えてしまう。低摩擦のループは、深さよりも幅に偏る。私たちは、ある方向に十分に座って抵抗を感じることなく、多くの方向の表面をスキミングできる。半形成のアイデアを頭の中に保持し、他の思考と衝突させ、どこが弱いかに気づくスキルは、すべての曖昧な概念がすぐにプロンプトになると退化してしまう。文化的な影響もある。誰でも無限に生産できると、環境は半端なものや浅いアーティファクトであふれる。シグナル対ノイズが低下するにつれて、発見が難しくなる。そして個人的には、満足感が空洞化することもある。摩擦は出力に重みを与えていた。何かを完成させることは、それに取り組んだことを意味していた。すべてのアイデアが数秒で実現できるなら、どれも使い捨てのように感じる。永遠にプロトタイピングの状態に陥り、何かを自分のものにするために長くコミットすることができなくなることもある。だから、その滑りやすい坂道は怠惰ではなく、浅さだ。人々が考えないわけではなく、考えにじっと座っていられないのだ。ここでの課題は、もはや必要のない世界の中で意図的な遅さを保つことだ。安価なループを探求に使いつつ、何が存在するに値するかを選ぶ能力を育てること。

なんか、平均的な開発者みたいに聞こえるね。トランスフォーマーモデルが模倣するように訓練されてきたものだ。良いAPIを設計するのは難しいし、上手くできる人は少ない。だからほとんどのAPIはクソで、私たちは新しいAPIを呼び出したり依存関係を追加することに対してネガティブな先入観を持っている。良いAPIを作るには、強い心の理論、知識の呪いに対する抵抗、境界の両側での経験が必要なんだ。クロードがそれが得意じゃないのは驚くことじゃないし、ほとんどの人間もそうだよね。

どんな記事も、特にこのように、コーディングエージェントが何が得意で何が得意でないかを、6〜12ヶ月の視点でしっかりと描くことができるとは思えない。ここに挙げられた例は共感できるし、私もさまざまなコーディングハーネスを使ってきた中で似たようなことを見てきたけど、特にオーパス4.5によるものも含めてね。けど、ここ数年の開発におけるLLMの使用経験は、次のようなものだった。1. 最初はモデルは基本的な目標を達成するために、単純な手続き的または構成的なコマンドや関数のシーケンスを組み立てることができるのがせいぜいで、テストや型チェックには合格するかもしれないけど、全体的な一貫性はなかった。2. 小さな関数を合理的に構造化できるようになった。3. 大きな関数を合理的に構造化できるようになった。4. 中規模のファイルを合理的に構造化できるようになった。5. 大きなファイルや小さなマルチファイルサブシステムを、ある程度合理的に構造化できるようになった。だから、彼らが今マルチモジュールやマルチファイル、マルチマイクロサービスレベルでつまずいているという考えは、私にとって特に驚くべきことではないし、将来のパフォーマンスを示すものでもない。抽象化が適用できるスケールの階層があり、エージェントが合理的にコードを抽象化できるスケールの向上は、継続的に上昇しているように思える。あるいは、ここに正当な不連続性があって、現在のアプローチに似たものが限界に達する可能性もあるけど、ここではそれを示す強い証拠は見当たらない。

└

LLMは、誕生以来、抽象境界を作るのが苦手だ。人々はそれを指摘してきた。（実際、私も12ヶ月以上前にそれを指摘したツイートがどこかにあるけど、私はその努力のリーダーではない）これはサイズに関係なく、技術は新しい概念や抽象を作り出すことができず、だから抽象化に失敗する。信頼性がない。

└

たくさんの人が、私たちが高原に達したと考える罠に陥っているように感じる。つまり、「積極的に探求して学ぶ」モードから「人々に確固たる事実を教える」モードに移行できると。1週間前、スコット・ハンゼルマンがAI支援コーディングについてStack Overflowのポッドキャストに出演した。私はその人をとても尊敬しているので、聞いてみたけど…ちょっと驚いた。彼は本当に自信満々で教えるような口調で、数ヶ月前のことを言っていた。特に「あなたは絶対に正しい！」というジョークを言って、LLMは一般的に非常にお世辞を言うと主張していた。私は「彼はまだクロードコードを使っていて、GPT 5のCodexを試していないんだな」と思った。10月以降、LLMがそんなことを言うのを聞いたことがないし、一般的にGPT 5.xは、私が間違っているときに自己主張する点で大きなブレークスルーだと思っている。だけど、そのニュース（多くの人にとって非常に価値があるだろう）についてはポッドキャストで言及されなかった。おそらく、二人とも最近Codexを試していなかったからだと思う。彼らを責めることはできないけど、すべての変化についていくのは本当に大変だし、同時に一つの場所に十分な時間を費やして深く学ぶことも難しい。でも、「教師の役割」を演じることに慣れている多くの人は、謙虚さを持って不確実な言葉で話すことに慣れる必要があると思う。

└

昔は関数の中で作り込まれたAPIを使ってたけど、今はモジュールで手に入れるようになった。以前はファイル内で自信満々に間違ったアサーションを見てたけど、今はコードベース全体でそれを見かける。ひどい定義のAPIがファイル間であったり、関数間でも見かけるしね。LLMはスタックのどのレベルでもしっかり定義されたAPIを書くのが得意じゃない。去年できなかったレベルで試みることはできるけど、問題がよく知られている場合じゃない限り、良いコードを再生産するのはまだまだ苦手だよ。

└

この記事は主に現在のことを報告してるね。（タイトルの「まだ」に注目。）未来については一文だけ軽く触れてるけど、その部分はカットすべきだったと思う。

この記事に反論するプロジェクトがいくつかあるんだ。理由はよくわからないけど、クリーンで読みやすく、しっかり構築されていて、テストも済んだコードを抽出できたよ。いつか何か書こうと思ってるけど、これをシェアするね： https://github.com/chicagodave/devarch/ これはClaude Codeの使い方ガイドがある新しいリポジトリだよ。

ゴールポストがこんなに早く動いているのは本当に驚きだね。4年前に、LLMが最初の2つのタスクを一発でこなせるなんて言ったら、みんな狂ってるって言っただろうな。技術がすごい勢いで進化してる。Opus 4.5を見逃してたけど、GPT 5がちょっと微妙だったから、ここ数週間で使い始めたんだ。めちゃくちゃ良いよ。今までのほとんどのものよりずっと優れてる。以前は考えもしなかったタスクを一発でこなせるんだ。

ランダムなネットの情報でAIを「シニアエンジニア」や、良いエンジニアにするのは不可能だと思う。そこには百万の脳のコードが詰まってるから、悪いパターンもあれば良いパターンもある。悪いパターンを取り除かないと、「覚えて」再生産することをやめないよ。プロンプトもこれには役立たないと思う。頭の外傷にバンドエイドを貼るようなものだね。

最近、クロードや他のエージェントを使って、簡単な雑務や繰り返し作業をやってみたんだけど、みんながこれを実際の業務でどう使ってるのか全然わからない。自動化はめっちゃ素晴らしいけど、すごい手間がかかるし、後処理も大変なんだよね。

ハクソク