# LLMに「もっと良いコードを書いて」と頼むと、ある程度までは効果がある――ブログ実験で判明
出来事の日付：2025年1月3日
ある新たなブログ実験が、意図的にばかばかしく見えるものの重要な意味を持つ問いを投げかけている。LLMに「もっと良いコードを書いて」と繰り返し伝え続けたら、コードは実際に改善するのか。記事による答えは、少なくともしばらくの間は「イエス」だ。筆者は、各桁の合計が30になる数字を抽出するPython関数を使ってテストを構築し、Claudeが生成した複数のバージョンがM3 Pro搭載MacBook Pro上でどれほど速く動作するかを測定した。
最初の結果は、飾り気のないベースラインだ。初期実装は正しいが華やかさには欠け、筆者によると平均実行時間は約657ミリ秒だった。この出発点が重要なのは、記事の残りの部分が、LLMにそもそもコードを書けるかどうかを扱っているわけではないからだ。焦点は、プロンプトを繰り返すことで、表面的な変更ではなく、実際に測定可能な改善が生じるかどうかにある。
最初の書き直しで、Claudeは複数の改善を施した「最適化版」と筆者が表現するコードを返した。新バージョンではロジックが再構成され、ベースラインのおよそ2.7倍の速度に達した。筆者が指摘しているのは、出力が単に速くなったことだけではない。モデルは、見栄えを整えるだけでなく、アルゴリズムの構造に影響を与える形でプロンプトに応答しているように見えるということだ。
次の段階では、さらに踏み込んだ。筆者は前回の解法をClaudeに入力し、もう一度、より良いコードを求めた。今回はモデルが、並列化手法を含む、より積極的な最適化を追加した。このバージョンには、サブプロセスやピクル化に関する問題など独自の問題が生じ、正常に実行できるようにするには修正が必要だった。修正を適用すると、コードは最初の実装より約5.1倍速くなった。
3回目の反復では、このプロンプトに潜む落とし穴が明らかになった。Claudeはより精巧なものを返したが、筆者によると性能は実際にはわずかに低下し、ベースラインの約4.1倍の速度に落ちた。つまり、「改善」を繰り返しても、性能が単調に向上する保証はない。ある時点から、システムは複雑さを増す一方で、それに見合う改善が得られなくなる可能性がある。
記事の最終段階では、numbaやJITコンパイルを含む、より高度なツールが導入される。ここで実験は、単なる目新しい試みというより、何を最適化とみなすかについての教訓的な事例に近づく。モデルはなおも高速なコードを生成できるが、新たな段階に進むたびに、追加された複雑さが速度向上に見合うか、そして速度向上そのものがモデルによるものなのか、モデルに使用を許したツール群の拡大によるものなのかを、人間が判断しなければならない。
より広い意味での教訓は、神秘的なものではなく実務的なものだ。プロンプトを反復することで、より良いコードを引き出せる可能性はあるが、改善は均一ではなく、プロセスは収穫逓減に陥り得る。筆者はまた、LLMを方向づけるための精神的負担もコストの一部だと明確にしている。すべての改善について、検証、ベンチマーク、デバッグが必要になる。つまり、「もっと良いコードを書いて」は、コストなしに生産性を高める魔法の呪文ではない。それはトレードオフを伴うワークフローであり、最速の答えが必ずしも最も簡潔で明快な答えとは限らない。
