世界を動かす技術を、日本語で。

2025年夏のLLMを用いたコーディング - アップデート

概要

  • Frontier LLMs (例:Gemini 2.5 PRO)はプログラマーの能力を大幅に拡張可能
  • LLMと人間が連携することで バグの削減開発速度の向上 が実現
  • LLM活用には 明確なコミュニケーション適切な情報提供 が必須
  • LLM単独では 複雑なタスクに脆弱性 が残るため、人間の介在が重要
  • 最適なLLMの選択人間主導のコントロール が高品質な成果の鍵

LLMとプログラミングの新時代

  • Gemini 2.5 PRO のようなFrontier LLMは、膨大な知識とコード理解力を持つ
  • 問題を 明確に記述 し、LLMとのやり取りを受け入れる姿勢が重要
  • LLMを活用することで、以下のような成果を得られる
    • コードリリース前に バグを自動的に除去
    • アイデアの検証用コードを 高速生成 し、パフォーマンス比較が容易
    • 人間の経験とLLMの知識を ペア設計 で融合し、最適解を発見
    • 明確な指示のもとで 一部コードの自動生成 による作業効率化
    • 専門外の技術(例:68000アセンブリ)も LLMの知識拡張 で対応可能

LLM活用のための心構え

  • Vibe coding(雰囲気コーディング) の多用は避けるべき
    • 小規模なテストやユーティリティならLLM任せも可
    • 複雑なプロジェクトでは 人間+LLMの連携 が最良
    • LLM単独では 冗長・複雑・脆弱なコード になる傾向
  • 高いコミュニケーション能力LLM活用経験 が不可欠
    • 効率的なやり取りがLLM活用の成否を分ける

LLMへの情報提供のコツ

  • 実装や修正を相談する際は 十分なコンテキスト を提供
    • 論文・対象コードベース全体(可能な限り)・自分の考えを共有
    • 特に以下を含める
      • 誤った解決策 とその問題点
      • 有望な解決策 のヒント
      • 明確なゴール・要件・コードスタイル
    • LLMは 依存関係が多いPythonコード を生成しがちだが、プロンプトで改善可能
    • 新しい技術や情報は ドキュメントも一緒に投入 (例:READMEを文脈に追加)

最適なLLMの選択と運用

  • コーディングには Gemini 2.5 PROClaude Opus 4 が推奨
    • Gemini 2.5 PRO: 複雑なバグ発見力・高い推論力
    • Claude Opus 4: 新規コード生成やUIの使いやすさ
    • 複雑な課題には 複数LLMの使い分け が有効
  • エージェントや統合エディタ は非推奨
    • フロンティアLLM本体に直接入力 し、全体像を把握させる
    • RAG(部分的コンテキスト提示) は性能低下の原因
    • 人間が手動でコードを移動 し、ループの中に居続けることが重要

結論と今後の展望

  • 現時点では 人間が主導権を持ちつつLLMを活用 するのが最適解
    • 将来的にはAIが単独で多くのコーディングを担う可能性
    • 今は人間の設計思想・品質管理が不可欠
  • LLMを使うことで、 知識の拡張・学習機会 も得られる
    • 生成物の品質・設計理解も維持可能
  • AIエージェントの進化を定期的に評価 しつつ、現状では コントロールの維持 がベスト
  • LLM活用を拒否することによるスキル格差 にも注意
    • In medio stat virtus (中庸こそ美徳)」の精神でバランスを取ることが重要

Hackerたちの意見

ちょっと話が逸れちゃうけど、OPの「PhDレベルの知識」って表現には賛成できないな。antirezにはすごくリスペクトしてるけど(同じ島出身だしね)。この言い回しは誤解を招くし、博士課程の本質についての広い誤解を指摘してると思う。AIラボに関するマーケティングやハイプの影響を受けてるからね。「PhDレベルの知識」が明確に定義されてるって主張は、あんまり意味がないよ。PhDの主な目的は、既存の知識をたくさん得ることじゃなくて、研究をどうやって行うかを学ぶことなんだ。

それに同意するわ。LLMが人間ほど上手くできない他のことを抜きにして、専門家レベルの知識として読んでね。LLMの知識の表現方法はちょっと異質で、確かにそれらは単純化しすぎてる。例えば、LLMはトップクラスのコーダーほど上手にコードを書けないけど、最初から最後まで繰り返しなしで非自明なプログラムを書くことはできるんだよね。

博士号の主な目的は、単に膨大な既存の知識を得ることではなく、研究を行う方法を学ぶことだ。博士号を取得したからといって、誰もそのテーマに興味を持つわけじゃないよね?重要なのは、研究を行う方法を学んだことだけだ。

でも、研究をどう進めるかを学ぶことが大事なんだよね。それに、PhDレベルの知識って、正しい質問を考えることだと思ってた。せいぜい「怠けた知識豊富な労働者」って感じで、自分から聞かない限り仮説を探求しない。PhDならその質問を自分に投げかけるはず。例えば、最近Claude Code(Max Proサブスクリプション)が、別のテストスイートの一部としていくつかのテストアサーションをコメントアウトしてたんだ。それは、元の計画に誤った仮定があったせいで、深刻なバグを探求しようとしなかった。だから、超思考して、なぜ失敗してるのかを探るように計画を変えるように頼まなきゃいけなかった。バグは、ORMオブジェクトがコミット後にリフレッシュされてなくて、閉じられた別のDBセッションによって取得されたためにnull値になってたんだ。

PhDって知識だけじゃないって理解してるなら、やっぱりその知識に簡単にアクセスできるのは超価値があるよね。前の仕事では、伝統的にはPhDレベルの人にしか答えられないような質問がよくあった。たとえば「一方向に電圧をかけたら、二つの材料のインターフェースはどうなるのか」みたいなやつ。これが意外と答えるのが難しいんだけど、LLMは結構いい仕事してるよ。

OPとは違って、まだ限られた経験だけど、このテーマに1ヶ月くらい没頭してきた中で、Gemini 2.5 PROとOpus 4の方が抽象的なレベル、例えばアーキテクチャとかではうまくいったよ。それからSonnetに入力してコーディングする感じ。2.5 PROは、少し劣るけどOpusも、当たり外れがあった。特にGeminiは、コーディング中に問題を回り道して自分で修正することが多かったけど、Sonnetは要点を突いてくれるけど、効率的に使うには明確な指示が必要だった。

これも私の経験だよ。大きなデザインアイデアを検証して洗練させるために、普段はAI Studio経由でGemini 2.5 Proを使ってる。洗練された要件をClaude Codeに持っていくと、大体ちゃんとコーディングしてくれる。最近Gemini CLIも試してみたけど、Claude Codeの鋭いコーディングスキルには全然及ばない。文法ミスをよくするし、行き詰まって抜け出せなくなることも多い。出力が冗長すぎて(しかも速いから)、何をしようとしてるのか追うのが難しい。Claude Codeはデバッグ能力がずっと優れてるよ。「大きなアイデア」の推論キャンプの別の候補はDeepSeek R1。こっちは遅いけど、大体の場合、問題を分析して一発で正しい解決策にたどり着ける。

全然可能だと思う。一般的に、Sonnet/Opus 4は最高の出力ではより強力だけど、他の面(整合性や一貫性)ではSonnet 3.5v2(よくSonnet 3.6と呼ばれる)よりも後退してると思う。Sonnet 3.7もそうだったしね。それに、モデルは複雑なオブジェクトで、時には、紙の上では弱いモデルが特定のドメインでうまく機能することもある。さらに、インタラクティブな使用とエージェントでは、異なる強化学習のトレーニングが必要で、時には整合したターゲットに向かないこともあるから、モデルの使い方によってその性能が変わることもあるよ。

翻訳:彼の会社は資金を得たりValkeyと競争するために「AI」製品を発表する予定だよ。実際に「AI」なしで生産的だった人たちが、今は「AI」のための小さな逸話的証拠を探し回ってるのを見るのはとても悲しい。

さらに悲しいのは、LLMに関する投稿のたびに現れて、私たちのポジティブな体験は妄想で、実際にはどれだけ悪いか気づいていないと言う人たちだよね。

私の投稿読んだ?読んでないといいな。この投稿はRedisとは関係ないし、会社に再入社する前に書いた投稿のフォローアップなんだ。

Gemini 2.5 PRO | Claude Opus 4 どんなに気分でコーディングしたり、エージェント的なコーディングをしたり、ウェブインターフェースからエディタにコピー&ペーストしたりしても、プライベート(つまり、有料)のLLMモデルの普及を見るのは悲しいよ。LLMがもたらす進歩は好きだし、強力なツールだと思ってるけど、プログラマーたち(無名の人も人気のある人も)が、プログラミングを続けるためにサードパーティに強く依存することを気にしないのが理解できない。プログラミングは、オープンで無料のツールでできる活動だったし、今でも大部分そうだよね。数年後にはそれができなくなるんじゃないかと心配してる(ほとんどのプログラマーが有料のLLMに依存するようになって、使わないのは今のIDEやvimを使わないのと同じになると思う)。みんながプライベートLLMを使ってるからね。「でも君は6桁稼いでるんだから、月200ドルくらい何だって?」って言う言い訳は、ここでの問題を本当に捉えてないよ。

プログラミングは、オープンで無料のツールでできる活動だったし、今でも大部分そうだ。だけど、JetBrainsは私の同僚が生まれる前からビジネスをしていて、MicrosoftのVisual Basic/C++/StudioはWindows用のソフトウェアを書くのをずっと簡単にしてくれたし、安くはなかったよ。

そうだね、さらに悪いことに、2025年まで公平性を推進しているように見えていた同じメガコーポレーションが、今は一部の国では月々の家賃と同じか、それ以上のコストがかかるゲート付きの開発環境を推進してるんだ。この問題には、ロックインや監視、IP盗難、SaaSに伴うその他の問題も含まれてないし。

そんなに悪くないよ:K2とDeepSeek R1は、1年前の最前線モデルと同じレベル(K2はもっと良いかもしれないけど、V3/R1の経験しかないからね)。LLMのトレーニングは非常にコストがかかるけど、本質的にはとてもシンプルだから、今後もっと出てくると思う。基本的なメカニズムが計算自体の物理的な性質に組み込まれているかのようだから、参入障壁は大きいけど、乗り越えられないわけじゃない。

モデルが安くなり、良くなり、無料になっていくなら、今が小さくてローカルで、驚くほど強力なモデルの未来の世界のインスピレーションや基盤となる技術、ユーザーインターフェース、ワークフローを開発する時だと思う。オンライン学習ができて、推論を形式化できて、自分の重みやコードに推論を組み込むことができるモデルがね。

「でも、あなたは6桁の収入があるんだから、月200ドルなんて大したことないでしょ?」って言い訳は、ここでの問題を全然捉えてないよね。ブラックミラーのエピソード「Common People」に出てくる他のサブスクリプションモデルと同じ。最初の価格に対して価値が良すぎるんだ。でも、長期的には価格が上がって品質が落ちて、あなたは彼らの囚人になっちゃう。

個人的にはプログラミングが「死ぬ」のを待ちきれないよ。最低でも10年は奪われた感じ。獣医がペットを助けるために訓練されて、結局はその仕事の大部分がペットを殺すことだとわかるみたいなもんだ。言語を議論したり、意見が分かれる何千人もの開発者とやり取りしたり、レガシーコードやメンテナンスが不十分なライブラリ、ツール、フレームワークに関わるとは思ってなかった。ゲームに10年以上いるなら、わざわざ@しないでね。プログラミングにはさよなら(新しい違った現実を歓迎するよ、何であれ)。ノスタルジーは人生のためにあるんであって、1日8時間画面を見つめるためじゃない。

ローカルで動かせるモデルはまだそれほど良くないし、運用コストもかなり高い。Claude 4クラスのモデルをローカルで動かすのが経済的になると、もっと多くの人がそれをやるようになると思う。今のところ、512GBのMac Studioを2台使ったKimi K2が最も近いかもしれないけど、コストは約2万ドルだね。

プログラマーがプログラミングを続けるために、サードパーティに強い依存関係を持つことを気にしないのが理解できない。そして、大手テック企業に自分のコードベースを自由に開放することを気にしないのも。

数年後には、それが不可能になるんじゃないかと心配してる。ほとんどのプログラマーが有料のLLMに縛られるようになると思う。今のところ、どのLLMにもロックインは見当たらないよ。AiderやCursorみたいなツールがあれば、気軽に使えるし、実際にAiderを使ってる。だから、今のところ投資に関しては理解できない部分がある。企業(多くの場合はVC)が何十億ドルも使ってるのに、明日には他の誰かにその利益を奪われるかもしれない。どこかでロックインの方法を見つけなきゃいけないけど、今の使い方ではそれが起こるとは思えない。

問題ないよ、その理由を教えるね。もし利益が頭打ちになったら、社会のために生産性を犠牲にする必要はないと思う。競争が激しいし、遅れを取っていないオープンモデルもたくさんあるから、競争が激しい高額なサービスにこだわる理由はないよ。もし利益が頭打ちにならなかったら、結局私たちは時代遅れになるし、何かにシフトしなきゃいけなくなる。だから同情はするけど、実際的にはあまりストレスを感じる意味がないと思う。頭打ちが来ると思うし、大手の株はかなり過大評価されてるんじゃないかな。

LLMを使ったコーディングやバイブコーディングについての会話は、ドメインやプログラミング言語の選択を考慮する必要があると思う。個人的には、その2つの変数が、どんなバイブコーディングのセッティングよりも10倍(場合によっては100倍)説明力があると思う。LLMを使ってコーディングすることに戸惑っている人は、相手がどんな問題に取り組んでいるのかを尋ねて、同じ問題をAIで解決してみると、相手の視点がわかると思う。それまでの間、こういうスレッドには「ただ使い方が悪いだけ」とか「試してみたけどダメだった」みたいなメッセージがたくさん並ぶだけで、今のところはノイズでしかないね。

彼らは自分たちのプロンプトを共有して、出力をチェックするのにどれだけの労力がかかったか、望む結果を得るために再プロンプトするのにどれだけの努力が必要だったかを話し合うべきだと思う。この投稿は、人間がどれだけの作業をしなければならないかを示唆している。「問題を明確に説明できて、LLMと協力するために必要なやり取りを受け入れられるなら…LLMに提供する情報は膨大で、論文やターゲットコードベースの大部分…そして、何をすべきかの理解をすべて吐き出す必要がある。こうしたブレインダンプには特に以下のことが含まれるべきだ」とかね。生成されたコードが受け入れられるレベルに達するまでの努力を考えると、なぜ自分で書かないのか疑問に思うよ。タイピングにかける時間は、問題を説明するための認知的努力に比べればほんのわずかだし、問題を厳密に説明することがプログラミングの本質だから。

ClaudeのGitHubアクションは結構使ってるよ(10〜20件のイシュー実装、ちょっとPRレビューも)。成功することもあれば失敗することもあって、放置するよりは強化されたコーディングの方がいいと思う。変更がすごく小さい自己完結型の機能やリファクタリングなら、ほとんど一人で動くけど、テストがその機能をカバーしてれば比較的安全だし(アクションで動いてるから他のこともできるのが大きなプラス…イシューを書けば終わりだし、時々Claudeにイシューを書かせることもある)。中くらいのサイズになると、動いてるように見えるけど実際には動いてないものを作ることが多い。テストカバレッジが足りないのは自分のせいかもしれないけど、そういうことがほとんどの時間で起こる。自分でイシューを書いたり、claude.mdに情報を追加したり、Claudeにイシューを書かせたりしても、うまくいかないことが多くて、レビューに時間をかけた後に何か間違いを見つけるのはかなりイライラする。もっと大きなものになると、当然だけどうまくいかない。PRレビューは小さいタスクや中くらいのタスクにはいいけど、ここはハードルが低いから、無駄なことも多いけど、見逃してたことをキャッチしてくれることもある。だから、個人的にはまだ独立して物事をこなすには遠いと思う。小さいタスクならClaudeにイシューを書かせて、PRを待つだけでいいから、それは素晴らしい。中くらいのタスク(ほとんどのタスク)は、実際にコーディングする必要があまりなくて、ただClaudeを指示するだけ…でもそれでも生産性はかなり上がってる。Geminiも試してみたけど、放置して全ての編集を受け入れると、めちゃくちゃになることがわかった。職場ではCopilotがPRをレビューしてるけど、あんまり良くない。Geminiは大きなコードベースではいいかもしれないけど、たぶんClaudeは苦戦するだろうね。

LLMに最初にコードを書かずにやりたいことを説明させると、その後に生成されるコードの質がかなり高くなることがわかった。やりたいことの詳細な説明を求めて、フィードバックを与え、数回の反復の後に実装を進めるように指示するんだ。

AI/LLMが非常に非効率なコードを書くことがある良い例があるよ。https://nullonerror.org/2025/07/12/ai-will-replace-programme...

同様に、AIはコードゴルフが本当に苦手だね。すごく得意だと思うかもしれないけど、実際は違う。冗長なコードが必要なんだ。

AntirezがLLMベースのコーディングに興味を持ってるのは偶然だと思う。Redisの細部へのこだわりのおかげで、すべてのLLMがRedisのコードベースでしっかりと訓練されてるからね。人間のために作られたものが、今やAIに消費されていて、彼はそのオープンさに対して何らかの形で報われている。全てが循環してるね。一貫性、明確さ、オープンさが再び勝つ。

コメント欄にChatGPTの名前が一つも出てこないね。Gemini ProとClaude Opusは、普通のChatGPT(無料版)よりそんなに優れてるのかな?