AIにコードを書いてもらう時代らしいので試した
AIエージェントにコードを書いてもらう！というのが、2024年の暮れくらいからツイッターのタイムライン上で賑わっていたように感じる。cursor composer、GitHub Copilot Edits、あと cline あたりがよく見る名前だっただろうか。
Roo Cline というのがなんとなく評判がいい？ような気がしたので、ちょいとお試しで触ってみた。
なぜ Roo Cline か？ → 無料で試せそうだったから
Cline にはいくらか亜種が存在する。元祖を Cline として、Roo Cline とか Recline とかっていう似たような名前のツールがいくらかある。Cline をカスタマイズするにはフォークするしかなかった、というのが背景にあるらしい。
で、この Cline はなんらかの言語モデルの API を叩いて動作する。OpenAI や Gemini みたいなものの API を叩いてもらう構図なのだが、なので基本的には従量課金という話になる。なんだけども、GitHub Copilot の機能を使って動かすこともできるらしく、つまり GitHub Copilot の契約があれば定額で動かすことができるっていう話らしい。定額？ならば試してみよう！ということで手を出してみたのであった。
ちなみに、2025年1月前半の時点では Roo Cline っていうのと Recline っていうのが GitHub Copilot の機能で動かすことができる Cline であるらしい (たぶん。pankona 調査)。
ファーストインプレッション：大変おもしろい
Roo Cline の導入は VSCode のプラグインを入れるだけなので一瞬で済む。簡単。GitHub Copilot の機能で Roo Cline を動かそうという場合には、おそらく GitHub Copilot のプラグインあたりも必要なんだと思われる。
モデルとしては gpt-4o であるとか claude sonnet 3.5 であるとかいくらか選択が可能。sonnet 3.5 を選び、さっそくメンテが滞っていた hashira を持ち出して「このリポジトリでは Go のバージョンが古いみたいなのでできるだけ最新にしてくれたまえ。さて君にできるかな？AI の力を見せてごらんよ」みたいなことをお願いしてみた。
すると go.mod の中身を確認し始めた。go1.20 ですねーみたいなことを認識してくれて、その後は go.1.21 に書き換えてくれた。Task Complete! じゃないんだよ。さっきは煽ってごめんね、真面目にやってください。最新は go1.23.5 です。頼みます。
せっかくなので「最新は go1.23.5 です。更新したらテストが通るかどうかも確認してください。大丈夫そうだったらブランチを切ってコミットしてプッシュまでしてください。gh コマンドを使ってプルリクも作ってください」と一息にお願いしてみた。
すると
- 先ほど同様にファイルの中身を確認し、
- go.mod を go1.23.5 に書き換えて (ここは
go mod tidyコマンドとかを使わずにいきなり書き換えていた。まあいいんだけど)、 - sdk をダウンロードして然るべき場所に展開し、
- go version で現在の Go コンパイラの版を確認し、
- go test を実行し、
- テストがパスすることを確認し、
- ブランチを切り、コミットを適当に積み、ブランチにプッシュし、プルリクを作る
- プルリクの URL はこれです、というところで Task Complete
こんなふうに作業をしてくれた。なんかすげえじゃん。差分はたった一行のプルリクだけども、結構いろいろやってもらえた感じがした。ありがとう、Roo Cline (その後 CI が通らないことが分かったので追加で色々直してもらえた。ちゃんとすごかった)。
自分は Roo Cline が作業をしている様をずっと眺めているだけだった。洗濯機が回っているのを延々と眺めていた小学校の頃の自分をちょっと思い出した。
他のモデルはなんかいまいち
で、遊び続けていると次第にレートリミットだってことで動かなくなってしまった。おもちゃを取り上げられたような気分だ。ということで sonnet 3.5 以外のモデルに切り替えて引き続き遊んでみたのだが、これがなかなか微妙である。同じファイルの中身の確認をし続けたり、まるであさっての方向の作業をして Task Complete! になってしまったり、まともに動かないという印象をもった。定額使いたい放題ではこのへんが限界か。
ってことで OpenAI に課金して OpenAI の API も試してみた。しかしこれもまあまあ微妙で、先述の sonnet 3.5 のほうがまともに動いてるのではないかっていう気がした。gpt-4o は1時間くらい作業して1,000円以上のコストになってしまったし、gpt-4o-mini あたりは安いんだけど何も進捗を出せずに一処をうろうろしているだけみたいなこともあった。わざと遠回りするタクシー運転手みたいなやつだなと思った。
gemini もちょっと試したんだけど、OpenAI の gpt-4o あたりとあんまり差がないようにも感じた。ある筋の話によると、gemini は食わせられるコンテキストが大きくて「鍛える」ことができるらしい。もしかしたら使いようによってはもっと強いやつなのかもしれないが、ちろっと触った範囲ではよくわからなかった。
sonnet 3.5 しか勝たんのか → そう
やっぱり sonnet 3.5 なのか、ということで Anthropic にも課金して sonnet 3.5 を引き続き試してみた。今度は従量課金だ。レートリミットになることもあるまい。ということでしばらく遊んでみたところ、やっぱりこれがもっともまともに動くという気がした。ちゃんと「わかってる」コードを書いてくる。多少複雑でも延々と動かしていると次第にゴールに辿り着く。しかも gpt-4o よりちょっと安いか？
定額使いたい放題とはなんだったのか
ということで定額使いたい放題を試すために Roo Cline をいじってみたのだが、気づいたらクレカ片手にあっちこっち課金して回っていた。いいんだ、楽しかったからいいんだ。そんでコードを書くならば claude sonnet 3.5 を使うのがいったん強そうだよ、っていうのが定性的ではあるが今回の知見。
いやしかし今後の俺達はどうなるのか
この手の AI エージェントと呼ばれるツールはこの度始めて触ったのであるが、今後のコーディングのありようを考えさせられるツールであるな。ソフトウェアエンジニアがまったく要らなくなるとまではまだ思わないが、仕事のあり方は GitHub Copilot 登場のときのそれよりもだいぶ変わるんじゃないかという気がした。「人が書いて人がレビューして」みたいな感じではなく、「AIに書かせて人がレビューして」っていうのがもしかしたら主流になるのかもしれんなーと。SIer じみた感じになっていくのかもしれない。
突然の料理ログ
完成したところ
材料
- キャベツ：約200g（ざく切り）
- にんじん：1本（細切り）
- たまねぎ：1/2個（スライス）
- 豚肉（または鶏肉）：200g（一口大に切る）
- コンソメ：1個（固形の場合）または大さじ1（顆粒の場合）
- 水：200mlサラダ油：大さじ1
- 醤油（お好みで）：少々
- 塩・胡椒：適宜
作り方
- フライパンにサラダ油を熱し、お肉を炒める。お肉に焼き色がついたら一旦取り出しておく。
- 同じフライパンに、キャベツ、にんじん、たまねぎを加え、しんなりとするまで炒める。野菜がしんなりしたら、お肉を戻し入れる。
- 水とコンソメを加え、軽く煮込む。この時、お好みで醤油を少々加えてもいいよ。
- 塩・胡椒で味を調える。
- すべてがよく混ざり合い、味がなじんだら完成！
作った/食べた感想
- レシピは ChatGPT に聞いた。だいたい「キャベツとコンソメがあるぞ！」とだけ伝えたら上のようなレシピが提示された。
- キャベツと人参を切ったところで MP を使い切ったのでタマネギの参入は見送った。
- 味噌汁も作っておよそ一時間かかった。タイパは微妙か
- 味見した感じでは味が薄かった。醤油を2さじくらい足したらまあまあの味になったけどコンソメというよりは醤油味になった。コンソメスープで煮る？という部分のやり方が “なってない” のかもしれない。
- そもそも「煮る」という行為は栄養を摂取するという観点では好まれないらしい (Refs: 勝間式 超ロジカル家事)
- ので、煮るのをやめろって話しもワンチャンある
- コンソメ味で蒸す、ってできるものか？
- あと「炒める」という工程は、完全に人間をブロックする (人間がフライパンに張り付いてないといけない) ので、その間に何かをやるってのが難しい。非同期で行える何かをスタートしてから (味噌汁の湯を沸かすとか) 炒めものに入るほうがリソース効率が良さそう。
- とはいえ家族からの評判はまあまあだった。熟練して半分の時間で作れるならまたやっても良いかも。
- 素材をカットするだけで 30 分近くかかっているので、なんかこう、トントントントンーン！って出来るようになればもっと早く済みそうではある
https://coderabbit.ai という、AI のちからでコードレビューを勝手にやってくれるというサービスが登場していたので試してみる。このブログでだ。
自分が書いているこのブログサイトは以下の流れで記事が作られている。
- issue を立てて article ラベルを貼り付ける
- 自動的に issue の内容をちょいといい感じに整形した pull request が作成される
- マージすればブログ記事が公開される
スマホでも記事が書きたいし PC でも記事が書きたいし、せっかく GitHub pages でブログやってるんだからそれになんかいい感じ乗っかって楽ができないかなーと思って構築したのがこの仕組みである。スマホだけでも GitHub で issue を書きさえすればブログ記事が書けるってのはなかなか便利である (便利ではあるが別に記事が量産されるかというとそれは別の話ではある)。
で、つまり記事が出ていく過程で pull request が一度生成されるようになっているわけで、先述の CodeRabbit さんに「ブログ記事を公開する前にいっちょレビューしてもらえる」って話ならば、なかなかもしかして便利で面白いのではないかと思ったわけである。
CodeRabbit の導入はとても簡単で、5分もあれば所望のリポジトリに CodeRabbit を導入することができた。お値段は、Open Source (Public Repository) ならば無料で使いたい放題らしい。ほんまか？大丈夫か？
公式ドキュメントはこちら https://coderabbit.ai/docs/introduction/
導入方法なども紹介されていてたいへん親切であった。これでとても便利だったらとても嬉しい。
さて、本記事に対応する pull request は https://github.com/pankona/pankona.github.io/pull/205 である。
ここを見ると CodeRabbit がどんなようなことを言ってくれるものであるかなんとなく察することができるかと思う。
変更の概要をコメントしてくれたり、あと謎のポエム？もつけてくれるようだ。文章のどこがおかしいとかもっとこうしたほうが読みやすいとか言ってくれたら嬉しかったが、そこまではしてくれない？ようだ (日本語だしソースコードじゃないってこともあろうか)。あんまり便利でもないがひとまず邪魔ではないので、いったん入れたままで様子を見てみようと思う。
ちなみに設定項目は Web の UI からぽちぽちいじってもいいし、リポジトリのてっぺんに .coderabbit.yaml を置いといても見てくれるようだ。たくさんのリポジトリに導入しようと思ったら設定ファイルを使うほうが便利そうね。
記事を何度か書き直している途中で Rate Limit に達してしまって CodeRabbit さんが動かなくなってしまった。一時間単位で Rate Limit が設定されているようなのでほっとけばまた動いてくれるのだと思う。とはいえそんなにヘビーにレビューをお願いしているわけでもないのにあっさり Rate Limit に達してしまうところを見るにつけては、一通り書き終わったところで一発レビューをお願いする (自動でレビューさせない) という使い方のほうがいいのかもしれない。
スラッシュコマンド (dependabot を操作するのと同じようなやり口) でレビューの依頼ができるみたいなので、WIP が外れるところで一発 @coderabbit review みたいに書いてみるのが丸いやり方かしらね。