こんにちは！逆瀬川 (@gyakuse) ちゃんです
今日はコーディング時に気をつけてることなどをQA形式でまとめてみました！
参考になればと思います！
また、こういう使い方があるよ！とかこうしたほうがいいよ！があればぜひおしえてください！
どのLLMを使えばいいの？
この節のサマリ
- 基本は Claude 3.7 Sonnet or Claude 3.5 Sonnet
- 大量のコードを渡したい等の場合は Gemini 2.5 Pro
- 上記で達成できない複雑な問題は o1 or o1-Pro
そもそもどう評価するか
LLMを使うときに困ることといえばどういうものがあるでしょうか？
「うまく思った通りに書いてくれない」「複雑なことができない」「古い/存在しないライブラリのAPIを使おうとする」「多くの参照コードや既に書いたコードを与えると推論能力が見るからに落ちる」「推論に非常に時間がかかる」このあたりでしょうか。
これらを評価するためには、コーディング性能、ライブラリ指示追従性能、ロングコンテキスト性能、推論速度を見る必要がありそうです。とはいえ、コーディング性能はシチュエーション依存が多く、ライブラリ指示追従性能は適切なベンチマークがなく、ロングコンテキスト性能も一般的に出ているベンチマークと体感では少し異なります。そのため、多くを主観で今回は評価しました。なお、コーディング評価にあたって SWE bench, AIDER, Chatbot Arena を, 推論速度評価にあたって Artificaial Analysis を一部参照しています。
性能表
この性能について主観的にまとめたのが以下の表です
| コーディング | ライブラリ指示追従 | ロングコンテキスト(70k token~) | 推論速度 | |
|---|---|---|---|---|
| Gemini 2.5 Pro | ◎ | ◯ | ◎ | ◯ |
| Gemini 2.0 Flash | ◯ | △ | △ | ◎ |
| Claude 3.7 Sonnet | ◯ | ◎ | △ | ◯ |
| Claude 3.5 Sonnet | ◯ | ◎ | △ | ◯ |
| o1-Pro | ◎ | △ | ◯ | △ |
| 4o | ◯ | △ | △ | ◯ |
総評としては、Claudeがライブラリ指示追従性能が高く便利で、ロングコンテキストを加味するとGemini 2.5 Proをサブとして用いると良さそうです。
備考
実際のコーディングにおいては画像対応やモデルごとの最大コンテキスト長も加味する場合もあります。上記ではo1以外は画像対応しており、かつコンテキスト長を最大付近まで使うと現状では性能劣化が激しいためロングコンテキスト性能だけを見るに留めました。
どの言語を使えばいいの？
この節のサマリ
- とりあえず日本語でOK
LLMにおける言語間の差異について
プロンプトにおける言語選択は重要な問題です。言語によって、これらの能力が変わります。
- 推論能力
- トークン効率
ChatGPT が登場した当時は明確に英語での推論が優れていましたが、現在はトークン効率が改善され、以下のベンチマークで見るとおり、推論能力も他とあまり変わりません。
ゆえに現状では、ユーザーがコンテキストを深く記述できる言語を選択するのが良いと思われます。
備考
最近登場したChatGPTの新しい自己回帰的な画像生成の仕組みでは日本語の指示追従能力は英語よりも少し劣るように感じます (ここでの指示追従能力は画像にテキストを描画させる性能における言語差のことではない)。これからわかるように、不変ではなくケースに依存することは留意するべきでしょう。
LLMコーディングで気をつけるべきことは何？
この節のサマリ
- LLMは Python, JavaScript がやっぱ得意
- ライブラリは枯れたものか、更新指示に忠実なモデル (Claude系) を使うといい
- 実装は小さくするか、1つにでかく書こう
LLMの得意 / 不得意なプログラミング言語を知っておく
最近の研究でも示されているとおり [Twist et al.]、LLMはPythonが大好きです。
これは、学習元である Stack Overflow や GitHub の言語比率に依存しています (さらに言えば、個人ブログ等の記事もおおむね Stack Overflow の比率に近いものであると予想されます)
そのため、Python, JavaScript はLLMが得意な言語となります。
プログラミング言語選定は本来はもっと自由であるべきですが、LLMの恩恵を受けるためにはLLMがよく知っている言語を選択することは利にかなっていると言えるでしょう。
ライブラリ選定に注意する
先に触れたように、LLMのモデルによってはライブラリについての指示を与えても忠実に利用できない場合があります。LLMは、かえって知らないライブラリのほうが忠実に利用できる、という性質があります。一方、知っているライブラリの場合、APIの更新情報を与えても古いAPIを利用するケースが多くあります (OpenAIのライブラリが特にそうです。古いバージョンで学習しすぎてしまい、最新の使い方を与えても古い使い方をする場合が多いです)。そのため、以下のようなテクニックが必要になります
- 枯れたライブラリを使う
- 別のライブラリとして定義して情報を与え実装させ、後で自動（もしくは手動）でリプレイスする
設計に気をつける
LLMコーディングは本質的に長いコンテキストを嫌います。ゆえに以下のような方針を立てておくと便利です。人間の実装と似ていますが、異なる部分としては、1ファイルでやれるなら一定以上でかく複雑になっても問題ない、ということです。
- 最大2000行程度の1ファイルで達成できるような実装は1ファイルでやりきる
- 大きいアプリケーションを作る場合は、マイクロサービス化させる
- 大きいモジュールは適切な責務に則り小さくする
コーディングツールの候補
このあたりは私がちゃんと触れていないので候補群だけ挙げます。Cline はシンプルで良いです。
- GitHub Copilot
- Cline
- Cursor
- Devin
これらのツールについては以下のブログが詳しいです。
誤りの伝播
LLMは自己回帰的なモデルゆえに、一度間違えると、そのコンテキストを引きずる性質があります。Cline, Cursor等を私があまり使わないのはこの誤り伝播が体験的にあまり良くないためでもあります。誤った場合、プロンプトを修正して推論し直す等が対応としてありますが、時間がかかります。何度もミスる場合もあります。個人的な対応策としては、各APIとの対話UIを作り、asssistant側のミスがあった場合、assistant側のメッセージを手動で修正して、「なかったこと」にすることをしています。これについてはもっと楽な誘導および修正をできるツールを待つしかなさそうです。
おすすめの実装フロー
PoC大量実装
最近個人的にオススメしているのがこの実装方針です。
プログラミングでは設計のミスは命取りです。これは伝播し、負債となります。ある程度作ってからでは、泣きながら負債を返済するのが世の常です。一方で、LLMコーディング時代はこれをある程度緩和させる仕組みを作れます。それがPoC大量実装です。
素早くアプリケーションを作り、それを繰り返すことで、設計の課題が見えてきます。
これを8回程度繰り返すと、適切な体験、適切なUI、適切な型/テーブル設計等がわかり、良い設計が生まれます。PoC大量実装では、「質の高い設計」およびLLMに与える最初のコンテキストを洗練させていくことが目的となります。