AI にコードを書かせる日々を送っているが、あんまりいっぱいごりごり書かせても実はあんまりうまくいかないよねという所感。
AIコード生成への3つのスタンス
AI 開発によりコード生成速度が上がったが、それに人間の心やレビューが追いついていない状況があるように感じる。
生成されたコードにどれくらい責任を持つべきか？という観点でもいくらかのポリシーがあるように思う。
- 生成されたコードは、テストが通っていれば内容はどうでもいいんだよ派
- おかしくなったら全部書き直せばいいんだから中身にこだわらなくていいんだよ派
- 中身も一行一行全部理解しないとダメだよ派
自分は3つ目の派閥であるが、しかし今後もっとモデルの性能が上がったりガワアプリのプロンプトが改善されたり、生成速度が何倍にもなったりした先には違う意見になるかもしれない。
バイブコーディングって言うけれども
コード生成の戦略も、バイブコーディングと呼ばれるような、テストや lint で一定のガードレールを引いた上であとは AI に生成を任せて大量にコードを作り出すやり方もあるし、Claude Code Action のようなものを引き合いに出せば、ややバイブコーディングよりは生成圧はマイルドなやり方もある。
バイブコーディングのようなやり方は、新規に何かを PoC 的に作り出すときにはとてもフィットする。数千行のコードがサクッと生成され、とりあえず動く。ちょっと気に食わないところがあればそれをまた AI に指示すれば直してもらえる。AI でのコーディング技術が登場する以前ではこういう体験は得られなかった。実際やってみるとおおーって感じになる。すごい。
なんだけど、これを継続してメンテナンスしていこうと思うと、すぐに AI だけの力では立ち行かなくなる。バイブコーディングしたときのコンテキストは失われ、なんとなく取り残されたドキュメントとコードをもとにして AI は続きを書こうと試みてくれる。しかし実際にやってみると既存の機能はぶっ壊れるし、ぶっ壊さないにしてもまあまあうまいコードが出てくるまでに大変な時間がかかったりする。ひどいときには既存のコードを消して「テスト通った！」みたいに言ってくることすらある。お前は俺か。インチキするな。
AI によるコード大量生産系のやり方は、既存の大きなコードベースがあるようなプロダクトには現状は適用が難しい。AI にコードを書かせるアプローチがまったく駄目かというとそうではなく、こういう土台の上ではプロンプトが重要になる。プロンプトを凝って、小さくコードを書かせる分には十分ワークする。しかしこれをやろうと思ったら、プロンプトを書く人間自身がしっかりとコードベースを理解している必要がある。設計原則や、アルゴリズムに詳しい必要がある。何を DRY にして何を DRY にしないかを選定できる必要がある。何が AI にフレンドリーで、何が AI にフレンドリーでないかを知っている必要がある。
バイブコーディングで大量にコードを生成した場合、コードを書かせた人間はどれくらいコードを理解しているだろうか。デッドコードがなくて、全部の行が必要であると言い切れるだけの理解をしているだろうか。書き捨てるコードならそんな理解をする必要もないのかもしれないが、しかし業務で「これはプロトタイプだから！真面目にやるときには書き直そうね！」って言って、それがしっかり書き直せたことがある人がどれだけいるというのか。意に反して、捨てたいコードが捨てられないなんてことはよくある話である。バイブコーディングして中身がてんでわからない状態のものを、このままメンテするしかない！みたいになったときに俺達は立ち向かうことができるだろうか。もっかい AI に書き直させればいい？そんなわけなくて、結局どこかで中身を理解した人間になる必要がある。
ゆっくりするしかない
個人プロジェクトでとりあえずちょっと作ってみよう、くらいのものであればバイブコーディングはとても良いと思う。しかしちょっとでも長くメンテする可能性があるものについては、そういう作り方をしないのが賢明だろうと思う。作り出したものを読んで理解すればいいじゃん？っていう論説もあるが、動く確信を持ちながら書き進めたコードと、ただ読んで理解したコードとでは、その理解には大きな差がある。ちょっとの量なら読んで完全理解できるかもしれないが、たとえば数千行のコードをほいっと渡されて、読んで理解するのにどんだけ掛かるだろうか。まあまあ時間をかけて読んだとして、そのコードへの理解が正しいという自信を持てるだろうか。責任持てる状態になるのかっていう話。
これは近道をする力を得ているように見せかけて、実は泥沼であるようにすら思える。AI に大きな裁量を任せて作業を任せたとして、任せた部分は自分の理解がすっぽ抜けるのである。理解をしなくてよいか、あるいはすでに完全に分かっている領域以外は AI に任せるべきでない。仮に任せたとして、うまく動いたとして、それはたまたまであるし、さらに機能を追加しようと思ったときにぐだった土台 (コードというか自分の理解がぐだっている) の上で戦わないといけないから早晩うまくいかなくなる。
最近、Claude Code が output-style として Learning モードというのを出してきた。これは Claude Code にコードを書かせているときに、Claude Code が「(TODO:Human)」みたいなコメントと共に、人間が書くための穴埋めクイズみたいのを残してくれる機能である。
この機能は、バイブコーディングのような AI にまかせてもりもりコードを量産するような機能とは明らかに趣が異なる。ちょっと立ち止まって、人間に学びの時間を与えてくれようという AI の粋なはからいである。知らんけど。でもまあ自分も言いたいのはこういうことである。もりもりコードを書かせることにだけ熱を上げるんではなくて、人間の理解も両輪で進めないと駄目だよ、と。
人間に大量のインプットをしたところで、即座に理解することはできない。マトリックスの世界のようにはいかない。つまりちゃんとみんなで遠くへ行くためには、ゆっくり理解しながら進むしかない。
最近は Claude Code (CLI のやつ) をだいぶ使っている。
Vim のターミナルで Claude Code を動かすとして、いくらか便利に使うための TIPS 載せておく。
前提として、不便を感じていたところ
Claude Code に「ファイルの何行目を見てくれ」みたいに指示したいとき、便利なやり方が分からなくて困っていた。
いつも別のターミナルを開いて find だの grep だの cat だのして、そんでだいたい場所を特定したら Claude Code に戻って「@hogehoge.go の Ln-Lm を見てくれ」と打ち込む感じ。おお、なんとみっともない非効率なやり方かパン粉よ
別のターミナルがスッと開ける環境ならまだ良くて、ssh しているときなんかは他のターミナルをスッと起動することもできないときがあり、いったん Claude Code を落としてから find だの grep だの… とやって、あたりをつけたらもう一回 Claude Code を起動してさっきあたりをつけた場所を打ち込む、という手順を踏むこともあった。おお、なんとみっともない非効率なやり方かパン粉よ
tmux を使えばだいぶマシになるという話もあるが、自分はいままで tmux を使ってこなかったこともあり、つい tmux の起動を忘れがちだったりするのもある。
Vim のターミナルから Claude Code を使う
で、自分は普段は Vim を使っている。プロジェクトのルートディレクトリで Vim を開き、あとは NerdTree を使ったり silversearcher-ag と fzf の連携でファイルを探したりしている。ファイルを探すのも grep するのも Vim なのである。
ということで、Vim と Claude Code をうまく連携できると良いのだけど、いくらかやり方を模索してみたところ割と自分に合いそうなやり方を見つけたので TIPS として記録しておく。やりたいことは以下であった。
- yank した内容を Claude Code に貼り付けたい
- ビジュアルブロックで指定した行の場所 (内容ではない) を、ファイル名を添えて Claude Code に貼り付けたい
- @{ファイル名}:Ln-Lm みたいなフォーマットで Claude Code に貼り付けたい
Claude Code は Vim のターミナルで動かす想定。
まず先に困りごと: Vim のターミナルで Claude Code を起動したらなんか見た目が変だったし動きも変だった
自分のところの Vim のターミナルで Claude Code を動かすと、こんなふうになっていた。動きもなんか変
これは ambiwidth=double という設定が悪さをしていたことが分かった。ambiwidth=single にしてあげるとキレイな見た目になるしちゃんと動く。しかし ambiwidth=double を捨てて俺達日本人が生きていけるのかは分からない。
yank したものを Claude Code に貼り付ける
これは Claude Code に貼り付けるというよりは「yank したものをターミナルに貼り付けるにはどうすれば」という話である。
これは yank したあと、ターミナル側のペインで入力モードに入ったのち、「Ctrl-w “"」と入力すれば yank したものが貼り付けされることが分かった。なんか Vim の基本中の基本の操作っぽい雰囲気がするのだが自分は知らなかった……。10年以上 Vim 触っているのに……。
ターミナル上で Claude Code を起動した状態で同様の操作をすれば、Claude Code の入力欄に yank したものがペーストされていくという寸法。具体的なコード片を Claude Code に貼り付けたいときに便利。
ビジュアルブロックで指定した場所 (ファイル名と行数) を Claude Code に貼り付ける
具体的なコードを貼り付けるんじゃなくて、ファイルパスとその中のどのへんっていうのを指示したいときの話。
これは少しだけ工夫が必要だったが、しかしワンライナーで済ますことができた。
ビジュアルブロックで行を選択した状態で、以下のコマンドを入力する。
:let @" = '@' . expand('%') . ':L' . line("'<") . '-L' . line("'>")<CR>
" に突っ込んでいるあたりはもっと便利にできるかもしれない。しかしこれをやると「@{ファイル名}:Ln-Lm」というフォーマットの文字列が yank された状態になる。ちなみにファイル名は相対パスで取得される。
そのまま Claude Code 側にいって「Ctrl-w “"」とすれば、件の文字列が Claude Code に貼り付けられるという寸法である。
自分は vimrc に以下のように書いておいた。leader を , に設定しているので、,y とやると先述のコマンドが動いてビジュアルブロックで指定した部分のファイル情報が yank された状態になる。
vnoremap <leader>y :<C-u>let @" = '@' . expand('%') . ':L' . line("'<") . '-L' . line("'>")<CR>
シンプルだが便利だぞ
これで vim で高速にファイルを探索しながら、所望の場所を特定したら Claude Code にペッと貼り付けるというのを快適に行うことができそうである。
世の中の Claude Code を便利に使うための Vim Plugin (概ねは nvim 用のもののようだが……) はもっともっと便利機能がありそうだが、自分の需要という点ではいったんここまで。もっと便利にしたくなったら Vim Plugin を書く (Claude Code に書いてもらう) のもいいかもしれないな！
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 みたいに書いてみるのが丸いやり方かしらね。