最近は 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 みたいに書いてみるのが丸いやり方かしらね。