2024年冬、僕が試した最も生産性を高めるIDE/AIの組み合わせと設定を公開します
どんな人向けの記事?
- AI系開発ツールが多すぎてついていくのがしんどい方
- AIツール導入を検討しているが、コストパフォーマンスや実践的な使い方に悩んでいる方
- 最新のAIツールの動向をキャッチアップしつつ、実務での具体的な活用方法を知りたい方
GitHub Copilotの初回リリースから、約2年半。AIによるコーディングツールは数えきれないほど出現した
GitHub Copilot が初回リリースされたのは2021年6月。初期はVSCodeのExtensionとして公開されていました。公開時点では、セキュリティリスクや他人が書いたコードを読むのが嫌だという反応も多かった印象です。
しかし、ZOZO TECH BLOGにて全社導入され、その効果が一定程度実証されたくらいから、日本でも一気に導入が加速していきました。
最近はCursorなどは人気もあります。いたるところで使われており、Zennでも記事を見る機会が増えました。非エンジニアの方でも使う人がいるくらいメジャーなツールになりました。
LLMによる業務改善効果が出しやすい領域だったことも相まって、いまではAIとコーディングに関するツールは数えきれないほど存在し、新しいツールの名前を聞かない日の方が少ないくらい。今後もツールは増えていくことでしょう。
他方、これだけ増えているツールをいちいちチェックするのは面倒です。
したがって2024年冬時点におけるベストツールの組み合わせをまとめておくことは、変化が激しくキャッチアップが面倒なAIツールをベターに使いこなす上で便利かと考え、ここでまとめておきます。
個人的な結論は、VSCode + GitHub Copilot + ClineとPerplexity
結論をグダグダと長引かせることは、せっかちなエンジニアの方には無意味です。
結論をタイトルに書きました。新ツールの名前をいれて興味を惹こうという意図もありません。
極めてベーシックな構成です。
これらのツールの組み合わせをすでに利用している人はもうこの記事を読む必要もありませんが、「どのようなユースケースでどのツールを使う」か、「実質無料で使えるツール」などの情報もあるため示しておきます。
Cursorを使わない理由
高いです。
Github Copilotは individual plan で $10 から利用できるものの、Cursorは pro plan だと $20 からです。では CursorはCopilotの2倍賢いのかというとそういうことはありません。
また、Xなどでは Cursor を使うとアプリケーションがばっちりできちゃうような触れ込みのポストがいくつも見当たりますが、エンジニアが求められるような品質のアプリケーションをCursorだけで作るのは現段階ではほぼ不可能です。
CursorはVSCodeのフォークなのですが、UIが不安定になったりすることもあります。Extensionとの統合も完璧になることはないと考えられるため、原因追及するのも面倒です。
さらに、ファイル保存時にフォーマットするよう設定している場合、私のケースではプチフリーズが多発しました。一行修正してさっさとテスト通したいのに10秒程度待たされたりすることは、せっかちな私にとっては我慢できません。致命的なデメリットでした。(課金してないからかも...?)
逆に、AIに任せたいような単純なコーディングは Cursorでもできますが、GitHub Copilotでもできます。
さらに、GitHub Copilotには GitHub Copilot for Business として組織単位で契約・有効化できる形態も提供しており、ポリシー設定して特定のファイルへの適用を避けるなど細かい設定も有効にできる安心感もあります。
Cursorならではのデメリットが存在し、後述するClineと組み合わせるとCopilotでは解決できなかったことも精度よくできるようになったので、私の場合、Cursorを使うモチベーションはなくなりました。
通常のコーディングは VSCode + Copilotを使うと退屈なコーディングは楽になる
Copilotをいつ使うか?
それは、JsonレスポンスをDTOに詰め替えるときや、型を書くとき、単体テストを書くときなど、「書き方は当然わかるが、冗長だったり、書くのが面倒だったりするとき」です。
たとえば、Goの Struct Tagです。
type Pharmacy struct {
ID int `json:"id"`
MedicalID int `json:"medicalID"`
Name string `json:"name"`
PostalCode string `json:"postalCode"`
Address string `json:"address"`
Phone string `json:"phone"`
Fax *string `json:"fax,omitempty"`
}
Goでは json:"id"
のように書くことでJSONのキー名と構造体のフィールド名を変換することができますが、このようなコードはわかっちゃいるが手を動かすのがめんどくさい部類のコードです。
Copilotはこの手のコードを書くのは得意で、構造体全体を一気に補完してくれたりもするのでコードを書くスピードや、本来集中すべき、価値を生み出すロジックの部分に脳のリソースを集中させたままコードを書くことができます。
Copilotはファイル内の文脈を理解してうまい補完を出してくれるようなツールです。ただしレベルは優秀なジュニアくらいのレベル感でもあるので、間違ったコードを書いたときも、やさしく手ほどきしてあげるようにしましょう。彼も修正されたコードを見て自分のコードを修正してくれます。
GitHub Copilotを使用することでフロー状態(作業に没頭し集中できる状態)に入りやすい。
上記は、ZOZOの調査で示された内容です。たしかに、Copilotを使うと脳の無駄なリソースを使わずに済む感覚が生まれてくるのがわかるはずです。これがCopilotを使う大きなメリットの一つです。
また、単体テストを書くようなタイミングでも便利に使うことができます。
client := enttest.Open(t, "sqlite3", "file:ent?mode=memory&cache=shared&_fk=1")
defer client.Close()
ctx := context.Background()
たとえば、Goの場合、テストのボイラープレートを生成してくれるようなツールも充実していますが、entを使っているプロジェクトの場合、entをin-memoryなsqlite3につなぎこむようなコードをCopilotが自動生成してくれるなど、ちょっと手のかかる部分の面倒をCopilotが見てくれるのも良いポイントの一つです。
単体テストでは、様々なmockツールが使われますが、テストの例を1つだけ書いておくと、ファイル内を走査し、自分が使っているmockに合わせたコードを生成するなど気を利かせてくれたりもします。
前述したentのテストの自動生成を自分のCopilotがうまくやってくれないときは、例を1個提示すればそのまま書いてくれるはず。ぜひお試しください。
このように、Copilotはちょっとしたコーディングの手間を秒単位で減らすように使うと良いのではないでしょうか。
ちょっとした機能を追加したりするときは VSCode + Clineでやると精度高く解決できる
Clineは今回紹介するツールの中では最も新しいもので、問題解決をAIエージェント的に行うコーディングサポートツールです。
AIエージェント的とはなにかというと、タスクを入力すると、そのタスクを適切な粒度に分割し、それらを段階的に解決するように働くということです。
VSCodeのExtensionとして提供され、インストールするとサイドバーに統合されるため非常にスムーズに使い始めることができます。画像の読み込みにも対応しており、なんとスクリーンショットから問題解決を行うこともできます。
Clineは、OpenRouter、Anthropic、OpenAI、Google Gemini、AWS Bedrock、Azure、GCP Vertexなど非常に多くのAPIプロバイダーに対応しています。今どきの開発者なら、何か一つは契約していたりするのではないでしょうか?
OpenRouterを利用すれば、freeなモデルを利用することもできますし、Ollamaにも対応しているためローカルLLMを利用したいケースでも使えるのが特徴です。
実際に、DartのStringを特定のフォーマットに変換するようなコードを書いてもらったところ、以下のような手順で解決してくれました。
私: Text(
textMemo.updatedAt.toString(),
style: kBody2.copyWith(color: kTextGrey),
),
これをYYYY-MM-DD hh:mm形式のテキストにして
Cline: textMemo.updatedAt.toString()をYYYY-MM-DD hh:mm形式に変換するためには、DateTimeオブジェクトをフォーマットする必要があります。textMemo.updatedAtがDateTime型であると仮定し、intlパッケージを使用してフォーマットを行います。まず、text_memo_card.dartファイルを読み込んで、該当箇所を特定し、変更を加えます。
Cline: intlパッケージをpubspec.yamlに追加します。
text_memo_card.dartでintlパッケージをインポートし、DateFormatを使用して日付をフォーマットします。
まず、pubspec.yamlを更新します。
Cline: intlパッケージをインポートします。
Cline: (ここでファイルを修正してくれた)
状況 : 実はnullableであることに気付く
Cline: (修正して正解コードを書いてくれた)
DartでDateTimeをフォーマットするために intl
が必要であるという前提から初めて、VSCode上に表示される lint error も検知して正確なコードを書いてくれました。
このように、使用したトークン数とコストも計算してくれるため、精神的にも非常に優しいです。
Clineは関連ファイル全体を舐める傾向があるため、1つのファイルに関係ないものは書かない工夫が必要(トークン数の無駄遣いを避けるため)ですが、これはむしろ設計をよくする役に立つと考えています。
まとめると、Clineは問題を分解するのが得意で精度は現存ツールの中ではかなり高いと言えるでしょう。モデルやコストの制御も容易です。VSCodeのExtensionとして提供されていることで、Cursorよりも安定性に優れていると思います。
Clineを使うと「数分程度の作業」を委任できると考えています。
エラーが出たときは、Perplexity を一次検索ツールとして使う
エラーが出たら、まずググるのが数年前までの常識だったように思いますが、それももう古くなってきています。
近年は質の低い記事がGoogle検索の上位に上がってくる傾向もあり、検索がノイジーであるため、適切な情報を集める難易度は増しています。
検索に特化したAIツールとしては、Perplexityのほか、GenSpark 、Feloが3強として存在しています。これらのツールで検索すると、よく出るようなエラーについてはかなりまとまった内容を提供してくれます。
マイナーツールやマイナーエラーについてはGitHubのIssueを詳しく読むことも必要ですが、一次検索としてはこれらのツールを使って良いと思います。
それぞれのツールの特徴として筆者は、
- GenSparkは遅いが詳細
- Feloは早くて精度も高く、プレゼン作成機能なども充実している後発
-
Perplexity はそこそこ早い、精度もそこそこ
といった印象を持っています。
ただし、Perplexity はソフトバンクと提携しており、ソフトバンク、ワイモバイル、LINEMOのユーザーはProプランを1年間無料で使えます。
いつ終わるかわからないサービスなのですが、本来月額3000円程度かかる費用をゼロに抑えられるので、Perplexity が一番お得と考えています。
さらに、これらの専用エージェントに対する期待は高く、新しいサービスが出てくるスピードも速いように思えるため、いったんコストが低いサービスで様子見をするのが良いのではないでしょうか?
Reviewは相変わらず CodeRabbit を使っているが、好みがある
この記事でも紹介した通り、弊社では CodeRabbit を利用しています。現在はレポジトリがDeprecatedとなり、基本的には有料のサービスとなっています。
一方でPR-AgentなどLLMを利用したレビューサービスは非常に多く出てきています。
CodeRabbitの特徴は、LGTMも含めて非常に細かいコメントを大量に出してくるところです。これにより見逃しやすそうなコードの問題点を指摘してくれる一方、うるさいと思う方も多いようです。
PR-agentは非常に細かい設定ができるので、こちらが好みの方もいるようです。
私個人としては、時短のためにやっていることに時間をかけたくないので、CodeRabbitの膨大な指摘をサラッと眺めて、マズそうな指摘を直すのが好きです。かなり好みが分かれるので、ここはチーム内での議論が必要なのではと考えています。
数時間かかるような、スケールの大きなことはプロのエンジニアが考えよう
残念ながら、AIツールは現状でエンジニアの完全代替となりません。
もちろん1年後は?3年後は?10年後は?というとわからないのですが、今のところは無理です。
先述した通り、Copilotは数秒程度の時間 ( x数千回 ), Clineは数分程度の時間でできることを代替してくれるツールです。
これらの話は的を得ています。
現状のLLM・ツールのクオリティだと、自分が作業した換算で数分程度の作業を短縮・省力化するためにツールを使うのには良いと思います。
ただし、数時間かかるようなことをAIにやらせると、アウトプットを理解する時間も長くなり、逆に修正や保守に無駄な時間がかかるようになってしまうこともあるでしょう。そもそも保守できない可能性すらあります。
アウトプットは理解しなくていいって?それは許されないでしょう。
それに、LLMでプロジェクトを作ろうとした方なら、キャッチボールを繰り返すたびにLLMのレスポンスが悪くなっていくことを経験したことがあるはずです。そのような状態で保守なんてさせられますか?僕は任せられません。
設計やアーキテクチャを考えるようなことも、チームやビジネス、自分の実力、出せるお金など多様なContextのもと決定されるべきことなので、AIの Context windowには入りきらないと思った方が良いでしょう。
そもそも、それらを理解可能な形で言語化できる人の方が少ないはず。言語化できる人がいるならその人が設計すべきです。
このようなAIツール使い分けの肌感のようなものは、普段からツールを利用しないと理解できないため、日ごろのアップデートが重要です。
もちろん、破壊的な技術革新が近い将来出てくる可能性も高いのでその前提すら覆る可能性もあります。引き続きアンラーニングを続けていきましょう!
まとめ
最近はAI関連の情報が本当にあふれかえっていますね。
どうしてもインプレッションが高くなる最新ツールやすごいデモばかりが注目されがちですが、 いま、エンジニアが使うツールとしてベターなものはなにか? という点に注目して情報をまとめてみました。
夢のようなうたい文句に惑わされず、現状最適を選び続けるエンジニアになりたいですね。
弊社マインディアでは、AI朝会という名目で、Biz / Dev ともにLTが毎朝開かれています。
BizがAIアプリを作ってデモすることもあり、Bizの着想の鋭さに驚く一方、エンジニアの仕事ってなんだっけ?と考えることもありました。
でも逆に、良いツールを本気で作るなら既存のプログラムや技術との掛け合わせをどうやるかを考えるのは必須です。チーム一丸となって考える必要性をあらためて感じています。
今後どうなるかはわかりません。
いまできることは、現在地を把握すること。
さぁ、AIというビッグウェーブを乗りこなしていきましょう!
友達になってくれる方はぜひ、フォローしてください!
Discussion