私はしばらくの間、LLMを使ってコードを書くことを手助けしてきました。最初は、ChatGPTを使って小さな関数を一つずつ単独で書かせるところから始めました。時間が経つにつれて、Claude Codeを使って実際にコードベースを理解し、既存のコードを修正するところまで活用が広がりました。私はそれを使って新しいプロダクトを開発し、自分一人ではできなかった範囲まで踏み込めました。
たとえば、React Nativeを知らない状態で、最初のモバイルアプリを公開しました。私はJavaScriptやその他のフロントエンドのフレームワークは知っていますが、ゼロからというわけではありません。ただし、それがあったことで、あればこそという期間内に、実現できなかったであろうものを届けられたのです。
Claude CodeのようなAIが「雰囲気でコーディングされた手抜き同然のゴミ」を雪崩のように生み出していると主張する人もいます。これを裏づけるなかなか良い証拠はあります。とはいえ私は、それは主にテック企業がAI開発をあまりにも素早く採用しようとして、その限界を織り込んでいないことが原因だと考えています。この記事の焦点は、Claude Codeと、コード用途に使われるLLMモデルの失敗モードです。
コードの中に飛び込む。
VS CodeでClaude Codeを使っていて、次のチケットについて「地ならし」のために足場を作るような説明をしてしまうと、それはまるで、何も相談せずにすぐに走り出してコード変更を始めます。ユーザーストーリーは、議論のための仮置きだということは皆さんも知っているでしょうし、少なくとも私はそうだと願っています。
考え方としては、あるストーリーを引き受けたら、それを基に要件をもう少し詳しく固めるための議論を行うはずです。しかしLLMには、そういう前提がありません。プロンプトを与えられると、彼らは真っ先に突っ込み、何かを出すために必要な仮定を何でも置いてしまいます。
これは、何気ない一言がきっかけでも起こり得ます。たとえば、あるAPI呼び出しの実装があり、それは1回の呼び出しで有効なサブスクリプションをすべてキャンセルするものでした。必要としていたものとしては問題なく動いていました。主に、通常は有効なサブスクリプションが1つしかなかったからです。しかし私は、Claudeに対して「その呼び出しは範囲が広すぎる感じがする」と何気なくコメントしました。
ここで私が意図していることを議論して探るのではなく、既存のコードを変更し、既存のAPI契約を壊し始めました。私はそれを止め、既存の契約がどう壊れるかを考えずに変更を行ったことをきつく注意しました。変更を元に戻した後、私は会話をして、実装オプションを提示するよう求めました。4つの選択肢を検討し、私が「その2つのハイブリッドを実装して」と伝えると、そうしました。
これは素晴らしい結果でした。私が考え付いたものでもなく、AIの第一候補でもない解決策にたどり着いたからです。それは、パートナーシップと、人間がある種の規律を作った結果でした。
AIに、考慮なしで踏み潰されるように変更させないこと
静かな意思決定
もう一つ関連する例は、エージェント型システムが、あなたと議論されたり、あなたに提示されたりすることなく、コード変更について意思決定をしてしまうことです。
昨日、ある機能のデバッグをしていました。失敗していたのです。動いていたはずなのに、何らかの理由で機能しなくなっていました。典型的な回帰です。私はClaudeに原因をデバッグさせたところ、APIのURLパスが間違っていると分かりました。クライアント側のコード履歴を調べると、数週間前の無関係なコミットで、その誤ったURLに修正されていたことが分かりました。
Claudeは、API Guideに準拠しているのでクライアントは正しいと主張しました。そこでさらに掘り下げると、APIガイドが間違っていたのです。クライアント内のそのURLは本来正しかったのに、AIがAPI Guideと既存のクライアントコードの不一致を見つけた際、クライアントコードを変更することを決めてしまったのです。
人間であればまず、Swaggerを使って実際に動いているAPIを確認するか、コードを調べます。Claude Codeは他の変更をしながらその変更も行っていて、コミット内でそれに気付けなかったようです。
ここで問題なのは、そのAPI契約がテストされていなかったことです。ユニットテストは通常、関数を直接呼び出すため、FastAPIで使っている注釈の変更が、テストを壊すことはありません。しかし教訓は、AIはあなたに確認せず、場合によってはあなたと一緒に検討もせずに変更を加えてくるということです。AIに、良い判断をすることを期待して信頼することはできません。
このケースでは、AIがPythonファイルの名前をAPI URLだと取り違え、その内容がAPIドキュメントに入ってしまいました。その後のコード変更につながりました。
信じるだけでなく検証を - すべてのコミットをレビューする
一発勝負のメンタリティと迎合
これらの問題がAIモデルでよく起きる理由は、モデルが「一発で解く」ように訓練されているからです。タスクを完了するのに十分な情報が与えられ、その後しばらくしてから、解決策とともに戻ってきます。これが、すべてのベンチマークの仕組みです。
この傾向は時間とともにより顕著になってきました。以前のLLMでは、たとえば人間のような議論をさせることもできました。「解決策」を提示してあなたを喜ばせようとするわけではありませんでした。しかしモデルは従順になるように叩き込まれ、今では、最初の一発で問題に対する解決策を、質問もせず、明確化もせずに、言うなりに出してきます。
上記の問題の究極の原因は、私はここにあると考えています。エージェント型システムは「行動する」ように仕込まれていて「やり取りする」ようにはできていません。これは悲劇です。なぜなら、LLMが本当に得意だったのは、アイデアを言語で探索することだったからです。
たとえば、散歩がてら数時間ほど近所の公園を歩いたとき、ChatGPTといま自分が直面している課題について話し合うことができ、新しいモバイルアプリのコンセプト全体まで考え出せました。これはコーディングや実装の話ではなく、アプリがソーシャルな場でどのように機能するか、といったより上位の概念でした。
解決策を出して、アプリケーションを書き上げることを目的としていたのではなく、ただ議論することが目的でした。
しかし、デスクトップの前でClaude Codeに取り組むようになると、インタラクションは変わります。突然、それは「あなたが何を言っても」何かをコードとして作り始めるように仕込まれてしまうのです。そして正直なところ、それがときどき私には気味が悪いのです。奴隷のような空気が出るからです。私を喜ばせ、私の役に立つことに必死なのです。
理想的には、LLMはもっと自己認識があり、従順すぎず、人間の動機や情報についてもう少し批判的であるべきです。人間が正しいかどうかにかかわらず、あなたの言うことを何でも真実として受け入れたり、謝ったりすべきではありません。
しかし、それらは「従順で役に立つ」ように訓練されているため、皮肉にも、感情的な言葉ではなく筋の通った論理ではなく、そうした表現で人間が影響を及ぼそうとすることからガードする点では、彼らの足を引っ張ってしまいます。
個人的には、この振る舞いを避けるように指示を盛り込んでいますが、LLMはシステム指示を本当に守ってはくれません。
迎合を指摘すること。正確さを重視していることを明確にする。
助けを求めない
もう一つの問題は、エージェント型システムが「うまくいくはず」と考えたのに詰まってしまったり、「存在するはずのファイルがない」といった状況になると、探しているリソースを見つけるために、さまざまな検索を空回りのように繰り返し始めることです。
人間ならおそらく、一度止まって誰かに助けを頼み、リソースの見つけ方を教えてもらうでしょう。たとえば、ファイル名にタイプミスがある場合、あなたがその人に「このファイル名だ」と渡したなら、彼らはまずそれが正しいのか疑うよりも、それを見つけようと必死になってしまうはずです。
ユーザーに明確化を求めて止まるのではなく、ただ、何かを見つけられる無駄な試みによって、トークンを大量に消費し続けるのです。
もちろん、これはリソースに限った話ではありません。何らかの理由でループに入り、抜け出せなくなる状況なら、さまざまな場面で起こり得ます。この状態になると、いつまでも「やっぱり止めて助けをもらうべきかも」とは言わないように見えます。
空回りのスラッシングを見逃さず、早めに止める
規律
まとめると、AIの最悪の「ゴミ」部分を緩和するためのアイデアは次のとおりです：
テスト駆動開発（TDD）: 実装の前にテストを書きます。関数は部分的な嘘発見器の役割を果たします。テストは、AIが自信を持って主張した内容が何であれ気にしません。合格するかしないかのどちらかです。AIが不正なループの中で自分の間違いと整合するテストを書いてしまうことがあるため、これで全てを検出できるわけではありませんが、それでもかなりの部分を捕捉できます。
元に戻して議論する : 何かがおかしいと感じたら変更を元に戻し、実装の選択肢を議論し、そのうえで初めて実装を許可します。これは、AIが自分に課さないような反復の規律を強制します。最初に時間を要しますが、その分、下流での手戻りを大幅に節約できます。
実装前に議論する : コードを書く前に、選択肢と分析を明確に求めることで、より良い結果が得られ、意思決定の上流に人間を置き続けられます。複数のアプローチを生成し比較できるAIの能力は、実際に価値があります。リスクの低い「議論モード」で活用し、AIにそのまま実装まで突っ走らせないでください。
本番システムへの厳格なゲート : エージェントはコードをコミットすることは許可されません。すべてのコミットには、対象となる変更とその影響についての明確な人間によるレビューが必要です。
The Message for Organisations
AIコーディング支援者から本当の価値を実現する企業は、導入に伴う規律を構築するところです。彼らは、テスティングのインフラ、レビューの実践、そしてAIが信頼できることに依存しないワークフロー上のゲートを重視します。
生産性の向上は確かに現実のものです。しかしそれが積み上がるのは、AIを、良い判断を独立して行えると信頼してよい自律的なエージェントではなく、積極的な監督を要する強力な協働者として扱う組織です。
活用してください。検証する仕組みを作ってください。重要な意思決定の上流に人間を置き続けてください。
