LLMを活用したコーディング（2025年夏）
(antirez.com)- Redis開発者 antirez による LLM 活用記のアップデート
- Gemini 2.5 PRO や Claude Opus 4 のような最先端 LLM は、開発者の能力を 強化 する
- LLM を活用すると、バグ除去、アイデア検証、知識拡張 などさまざまな形で業務効率を高められる
- 専門外の分野や新しい技術でも、LLM の助けで容易に扱える体験 が可能になる
- ただし、コード全体の品質と保守性 のためには「人間 + LLM」の協業が鍵となる
- LLM を最適に活用するには、十分なコンテキスト提供と明確なコミュニケーション能力 が重要である
LLM を活用した開発の変化と重要ポイント
最先端の LLM（Gemini 2.5 PRO、Claude Opus 4 など）は、膨大な 理解力 と大規模コード処理能力を土台として、プログラマの能力を 拡張 する役割を果たす。
- 問題を明確に記述し、反復的なやり取りに慣れていれば
- リリース前にバグを事前に取り除く体験ができる（例: Redis の Vector Sets 実装事例では、Gemini/Claude のコードレビューで即座にバグを除去）
- アイデアが機能するかを素早く試しながら、実験的なコード作成や性能評価が可能になる
- 経験と直感に基づく ペアデザイン（pair-design） が可能で、LLM の豊富な専門知識と人間の直感を融合できる
- 明確な指示を LLM に与えれば、一部のコード実装を迅速に完了できる
- 不慣れな分野（例: Amiga 向け 68000 アセンブリコード）でも素早い技術適応が可能になる
以前の「LLMsと2024年初頭のプログラミング」という記事では LLM の有用性に触れていたが、ここ 1.5 年で LLM は飛躍的に進化 した。
LLM を最大限に活用するには、人間にも LLM にも特定の能力や習慣が必要であり、それに関する原則が重要になる。
Vibe Coding を控えることと、人間+LLM 協業の原則
現在の LLM は 開発者能力の増幅器 として非常に優れているが、自律的に単独ですべての作業を処理できる段階にはまだ達していない。
- テストや小規模ユーティリティなど、単発の小規模プロジェクトでは LLM 単独設計も可能である
- しかし大規模で非定型なプロジェクトで LLM を単独使用すると、複雑化、不要なコード、構造的な脆弱性 などの問題が生じる可能性が高い
- LLM+人間の協業が最も大きな生産性向上を示すが、その前提は 効果的なコミュニケーションと LLM 管理経験 を持っていることである
- 複雑な作業を LLM だけに任せず、常に人間が工程に積極的に介入する戦略 が必要である
LLM に十分なコンテキストを与える重要性
LLM に開発や問題修正の方向性を正しく理解させるには、広範なコンテキスト情報の提供 が不可欠である。
- 論文、対象コードベース（できるだけ全体）、作業意図などを提供するのが望ましい
- 実装目的、不要または脆弱な手法、実現可能な中核アイデア、目標、不変条件、コードスタイルなどの重要情報を含める
- たとえば、LLM が知らない新技術（例: Redis vector sets）を扱う際に README 文書をコンテキストに含める と、すぐに専門家レベルの回答が可能になる
LLM の選び方と使い方
最もよく知られた LLM が、実際に最良の結果を出すとは限らない。
- コーディングでは Gemini 2.5 PRO と Claude Opus 4 が特に有効である
- Gemini 2.5 PRO は 複雑なバグ検出と問題解決力 に優れる
- Claude Opus 4 は 新しいコードの作成 に強く、ユーザー体験も優れている
- 2 つのモデルを交互に使うと、複雑な設計時の理解が深まる
- 1 つだけ選ぶなら Gemini 2.5 PRO を勧める
- LLM 利用時に守るべき条件
- コードエージェントや IDE 統合エージェントの使用は避ける
- LLM がコードや文書などの全体コンテキストを直接見られるようにして、最良の回答を引き出す
- RAG（知識検索ベース） など、一部のコンテキストしか見せない機能を使うと性能低下が起きる
- 各工程で人間が手作業でコードをコピー＆ペーストしながら、直接フローを追跡する必要がある
結論 – 制御を維持することが鍵
コードを単独で書くエージェントの登場は遠くないが、現時点では人間が主導して LLM と協業 する方式が最も鋭いコードを生み出す。
- 人間が「何を、どう」行うかを決める役割は依然として核心である
- LLM を活用すれば、既存の知識の境界を越えて新しい技術や概念を学びながら成長できる
- コードを直接制御すれば、設計・実装の一貫性を保てるうえ、LLM の誤りがもたらす不確実性 も最小化できる
- エージェントの性能進化を定期的に点検するのも賢明な戦略である
- この段階で LLM 活用を避ければ変化に乗り遅れる可能性があるため、バランスの取れた活用法 が重要な時期である
1件のコメント
Hacker Newsの意見
Gemini 2.5 PROやClaude Opus 4のようなクローズドLLMモデルが標準になりつつある現実を残念に感じている。LLMの進歩やツールとしての強力さ自体は非常に前向きに見ているが、なぜ開発者たちが（有名人であれ無名であれ）プログラミングを続けるためにサードパーティーの有料サービスへ依存してもよいと考え続けているのか理解しがたい。以前はオープンソースと無料ツールだけでもコーディングできた。数年後には、有料LLMへの依存が今のIDEやvimなしでコーディングするのと同じくらい不便になるのではないかと心配している。月額$200など大したことではない、という類いの話は根本的な問題を解決しない
今ローカルで動かせるオープンモデルは質的に不足しており、何より運用コストがはるかに高い。Claude 4級のモデルを個人のコンピュータで経済的に動かせるようになれば、その時に多くの人が試すだろう。現時点ではKimi K2のようなモデルが512GB Mac Studio 2台で動くが、機材費だけで約$20,000だ
サブスクリプションモデルの価値は、初期には非常に優れたコストパフォーマンスを提供しているように感じさせる。しかし次第に価格が上がり品質が下がって、結局はサービスに縛られる状況になる。まるでブラック・ミラーの「Common People」エピソードのようだ
個人的には、すべての開発者が有料LLMに無条件で従属する未来は起こりにくいと思う。長期的には、コードを大量生産すること自体が問題だという現実に人々が気づくだろうと見ている。コードは負債であり、不安定または遅いコードが積み上がればその負債も大きくなる。AIが消えることはないだろうが、熱狂が少し落ち着けば、どこにどう使うべきかについての理解は深まるはずだ。また投資資金が尽きたらどうなるのかも疑問だ。OpenAIやAnthropicは収益性がなく、現在の状態を維持するには資本が継続的に流入し続ける必要がある。もしLLMの進化が今くらいで頭打ちで、これが限界なら、投資資金も引き上げられるだろうし、そうなれば利用コストが上がるか、完全にサービスから消えることもあり得ると思う
現実的には大きな問題ではないと思う。生産性向上に実質的な理由がないなら、高価で不親切なサービスに依存し続ける理由はない。オープンモデルも着実に進歩しているので、オープンモデルとの差が大きくなければ使い続ける必要はない。もしLLMの進歩が止まらず急速に進むなら、私たちも従来のやり方では競争力がないので別の領域へ移るべきだ。結論として、それほど大きく心配する必要はないと思う。また大規模モデル企業の価値は実態以上にかなり過大評価されていると感じている
オープンソースと無料ツールでコーディングできるという話に付け加えたい。JetBrainsは同僚たちより古い企業だし、MSのVisual Basic/C++/StudioがWindows開発を容易にしてくれたが、どれも有料だ
「PhD-level knowledge」という表現には同意しない。PhD課程は既存知識の習得が目的ではなく、研究を遂行する方法を学ぶことが核心だ。AIの議論でよく誤解されるポイントだが、博士号レベルの知識という言い方は意味が曖昧になってしまう
PhDとは研究を身につける過程だということに加えて、問いを立てられるかどうかが核心だ。LLMは「豊富な知識を持つ怠け者の労働者」に近く、自分で問いを立てながら仮説を探索しない。実体験を例にすると、Claude Code（Max Pro）にテストアサーションの数をコメントアウトさせたところ、元の計画での誤った仮定に基づくバグが生じた。私が直接、計画を書き直せと指示して初めて理由を見つけて修正できた。たとえばORMオブジェクトがnull値を持っていた理由は、コミット後にrefreshがなく、別のDBセッションから読み込んだものがセッション終了後もそのまま残っていたことに起因していた
同意する。専門家レベルの知識はあるが、人間が得意なことをLLMはそこまでできない。たとえばLLMは一発で並外れたプログラムを最初から最後まで書けることがある一方、反復的に改善するのは苦手だ
PhDが知識以上のものだと理解したとしても、その知識へ簡単にアクセスできる手段ができたこと自体は非常に大きな価値だ。以前の会社ではPhDでなければ答えられないような難解な質問（大ざっぱに言えば「2つの素材の境界に一定方向の電圧をかけると何が起きますか？」のような質問）に対して、LLMがかなり実用的な答えを出したこともある
PhDを取ったからといって科目自体をより気にするわけではない。結局重要なのは研究のやり方を学んだということだ
LLMベースのコーディングに関する議論では、扱うドメインと使うプログラミング言語に必ず言及すべきだと思う。この2つの変数は、LLMの活用方法よりもはるかに大きな影響力を持つ。誰かがLLMコーディングを好きだとか嫌いだとか言うなら、まずどの領域の問題を解いたのかを尋ね、実際に自分でもAIでその問題を解いてみるべきだ。そうしないと、いつも「使い方が間違っている」「自分は試したけど微妙だった」といった不毛な話にしかならないと思う
最近agentic codingに数か月集中して取り組んだ経験からすると、投稿の内容すべてに共感する。最先端のLLMが一番使いやすいのは確かだが、オープンモデルもすぐ追いつくことを期待している。LLMに新しい方法を提案させたり、すでに知っているアプローチを提示させたりもできる。ときどきLLMは内容を複雑にしがちなので、事前に検知するかリファクタリングを依頼すればよい。さまざまなモデルが出るたびに状況はまた変わるだろう。すべての作業に最先端モデルが必須というわけではない。単純な機能追加やバグ修正ならCopilotでもかなり良い出発点になる。みんなが新しい変化の中でいろいろ試し、学ぶ過程を楽しめたらと思う
ClaudeのGitHub actionを10～20件ほど、Issue実装とPRレビューに使ってみたが、文字どおり当たり外れが大きく、無差別な自動化より拡張ツールとして使うのが正しいという意見に同意する。変更が小さく、テストがよく整っている小規模な機能追加やリファクタリングは、ほぼ自動で成功する。actionとして回せば自分は他の作業ができるので利点がある（IssueもClaudeが書いてくれればさらに楽だ）。しかし中規模以上では、しばしばコードがもっともらしく見えても実際には動かない結果が出る。これはテストカバレッジ不足という自分の責任かもしれないが、確かによく起こる。Issueをより詳細に書いたりpromptを変えてみたりしても、結果は期待外れだ。大規模な作業が難しいのは言うまでもない。PRレビュー機能は小～中規模の仕事ではそこそこ使えるが、役に立たない確認も多い。結論として、LLMが自力でコーディングするにはまだ遠いと思う。小規模な作業だけIssueを書かせて、PRが上がるまで待つ形がいちばん効率的だ。大半の作業（中規模）では、私は主にClaudeに方向づけだけすればコーディングをほとんどしなくて済むので、生産性は確実に上がる。Geminiも使ってみたが、放っておくと予測不能なレベルでコードが暴れる。社内ではCopilotでPRレビューもしているが、あまり効果はない。大規模コードベースならGeminiの活用余地はより大きいかもしれない
OPとは違って、この分野を1か月集中的に掘ってみたところ、Gemini 2.5 PROとOpus 4はアーキテクチャのような抽象的な議論ではより良い結果を見せた。そして個々のコード実装はSonnetに任せるやり方が効率的だった。2.5 PROとOpusは正解の周辺を回りながら自分で修正を繰り返すパターンが多く、Sonnetは答えまで一直線に進むが、その代わり十分に細かい指示が必要だった
十分あり得る話だ。実際、Sonnet/Opus 4は最高の結果という点ではより強力だが、一部ではSonnet 3.5v2（3.6とも呼ばれる）や、場合によっては3.7よりも一貫性やアラインメントで劣る面もある。またモデルは複雑な対象なので、ドメインによっては「弱く見える」モデルの方がうまく機能することもある。さらに対話型（Interactive）環境とエージェント志向環境では強化学習の手法自体が異なるため、どのように使うかによってモデルのパフォーマンスが変わる
実際の内部統計データでも、OpusとGemini 2.5 proが現実的な環境ではSonnet 4より性能が低いという結果が確認されている 関連統計リンク
私も同じような経験をしている。Gemini 2.5 ProはAI Studioで大きな設計アイデアの検証や洗練に使い、要件をClaude Codeへ持っていくと、だいたいきれいにコーディングしてくれる。最近Gemini CLIも試したが、Claude Codeに比べてコーディング能力はかなり劣る。構文エラーも多く、ループから抜け出せず、出力は冗長で速すぎて追うのも大変だ。一方でClaude Codeはデバッグ能力も卓越している。「大きな絵」の問題解決にはDeepSeek R1も試す価値があり、非常に遅いが正答率は高い
AI/LLMがときには非常に非効率なコードを書いてしまう現実的な事例を共有する 関連ブログリンク
LLMにまず、やってほしい作業を直接コードにするのではなく説明だけしてくれと頼み、自分が途中でフィードバックを与えながら何度か反復した後だと、その次に出てくるコードの品質がずっと良くなる経験をした。詳細な計画を先に確認させてから進めると効果的だ
私の経験では、フロントエンドで検証しやすい反復的で単純な作業はvibe codingに任せてもよいが、普段は自分のコードをレビューし、さまざまな代替案を評価するスパーリングパートナーとしてLLMを使っている。提案が的外れだったり論理的欠陥があったりしても、自分があまりに当然のことを見落とさないよう助けてくれるので満足している。複雑にもつれた問題に対して、かえってやりすぎな試みをしてしまう自分の癖も直してくれる
OPが言っているやり方が何を正確に指すのか分からない。もしかしてredisのCファイルを手作業でGemini ProのWebチャット欄に貼り付けろということなのか？