シーバさんの自己紹介
はい、なんか最近は暑いですね。暑くないですか?
暑いですね。
なんかどちらに住まいなんでしたっけ?
僕は大阪です。
そうですよね。なんか割と関西のアジャイル方面の人たちとかとも仲良くやっているイメージがありますね。
あーそうですね。仲良くさせてもらってます。
タグちゃんとかが一応ヘンリーにいるので、
なんかそのアジャイルラジオとかでシーバさんと話してるのを聞いて、
あーなんかそこも繋がりがあるんだなっていうのを聞いていました。
タグちゃんもヘンリーにいるんですね。
そうなんですよ。なのでだいぶそういうアジャイルスクラムのご意見版的な感じでいろいろ頼られてますし、
あと結構社内の文書とかにアジャイルとかスクラムについて書かれてたりするので、だいぶなんていうか、そうですね、活躍してるっていう感じですね。
すごい、さすがタグちゃん。
まあそういう感じなんですけど、この番組は趣味でOSSをやっているものだという番組でOSS作家のソムがゲストを交えながら趣味や仕事について話すポッドキャストです。
ということで今日のゲストはシーバさんです。よろしくお願いします。
よろしくお願いします。
じゃあシーバさん軽く自己紹介をお願いしていいでしょうか。
はい、シーバと言います。ツイッターXはBufferingsというのでやってます。
今は駆け橋という医療系のスタートアップでVPオブテクノロジーという形で仕事をさせてもらってます。
あとさっきお話しあったみたいにアジャイルとか結構興味持っていろいろ勉強したりしてるんで、その辺でコミュニティにお世話になったりしてます。
今日はよろしくお願いします。
よろしくお願いします。
OSSフレームワーク「氷」について
そうですよね、Bufferingsでやられてますよね。なんか僕はあんまり基本的にシーバさんってお呼びすることが多いんで。
はい、全然大丈夫です。
このIDの由来ってどういうものなんですか。
いやいや、ID由来なんだっけな。なんか特にあんまり深く考えずに作っちゃいましたね。
もう2010年より前ぐらいなんですけど、シーサーとかのコミュニティが活発だった頃かなに日賀さんがツイッターいいよみたいな言ってたんで、
じゃあ作ろうって言って作ったのが始まりだったかなと思います。
なるほど、ツイッター作った時に何となく作ったものをそれこそAthenaブログでもGitHubでも使ってるみたいな感じなんですね。
そうですね、もうちょっとちゃんと考えてつければよかったなっていう気持ちは少しあります。
そうなんですか。
でも仕事とかだとシーバさんとかコミュニティでもシーバさんって呼ばれることが多いですか。
そうですね、Bufferさんって言われる時もありますけど、仕事はシーバさんが多いかも。
確かにシーバって珍しい名字でかつ呼びやすい感じがありますよね。
そうですね、真ん中は横棒みたいに呼べますからね。
確かにそうかそうか、そういう伸ばし棒みたいな感じもあって、あだな感もちょっとある感じはありますね、確かに。
そうですね、それ自体がちょっとあだなっぽいですよね。
そうか、今VPOTを務められてるんですね。
はい、そうです。
それって何かいつからですか。
いつだったかな、3月ぐらいだったかなと思います。だから今まだ4、5ヶ月ぐらいですね。
なんかVPOTってそれこそ最近そこにちゃんと役割をつけようっていう風になってきてると思うんですけど、
掛橋さんの場合ってどういったところがVPOTの役割になるんですか。
そうですね、自分の場合はインデビジュアルコントリビューターの延長線上でもうちょっと広く全体を見たらどうかって話を、
CTOの井上と話して、じゃあそれでやってみますっていうことでVP of Technologyになりましたね。
だから組織を見たりとか評価に入ったりとかはしてなくって、あくまでもエンジニアの延長線上にある役割として動いてます。
そうなんですね。動き方として変わったことってありますか。
そうですね、変わったのは前者的な技術に関していろいろいろな人と議論しながら決めていくことが増えたなとは思ってます。
それ以外でもなる前、VPOTという役割をもらう前も結構前者的には動いていて、
どっかのチームに入っていって開発のサポートをしたりアーキテクチャーの相談を受けたりとかはしていたって感じです。
それのもうちょっとオフィシャルにこの人VPOTだから依頼していいんだよっていうのが役割として与えられた形にはなってますね。
なるほどなるほど。今ってじゃあ具体的にどっかのチームに入ってSHMの開発チームみたいなのもある感じなんですか。
今はないですね。今は一つサポートしているチームがあって、あと他にもいくつかその前者的な部分で任されているものがあって、そのプロジェクトとかをちょっとやったりはしてます。
だからSHMで見ているプロジェクトは今のところないですね。
なるほどなるほど。そうなんですね。VPOT、若干気になるトピックだったから、いろいろ聞いてしまった。ありがとうございます。
僕とシーバさんでいうと、僕は結構シンパシーっていうか、なんとなくその縁を感じている部分があって、
多分年齢も結構近いのと、結構同時期に外資系にいて、しかもなんかそういうチャレンジをしてたんだけど、結構同じような時期にちょっとやめざるを得なくなって、
職探しをすることになったみたいなのがあって、なんかその時になんか一回お互いその仕事がない時にお話をさせてもらったみたいなのがありましたよね。
そうですね、あれはびっくりしましたね。僕は一方的にSOMさん知ってて、そのハテナの頃からいろいろやられてたり、OSSの開発されてたりとか、
あとは発表されてたりとかするのを知ってたので、一方的に自分は知ってるなと思ってたんですけど、それがちょっとお話ししようよみたいに声かけてもらえたのがびっくりしました。
そうですね、しかもその後じゃあお互いちょっと仕事探し頑張りましょうねみたいな話をして、その後入った会社がヘンリーと架橋さんっていう、
両方ともその医療系の結構勢いのあるスタートアップに2人とも入ったみたいなのがあるから、そういった部分もちょっと縁を感じてる部分があったりします。
そうですよね、あの聞いたときにあほーって思いました。
そう、なんか、はい、まあという感じなんですけど、今回結構お呼びしたのはちょっと違う文脈で、そのシーバさんがその氷、氷?これなんていう、氷でいいんですかね。
はい、氷って呼んでます。
アクセントが、まあじゃあ普通に日本語っぽく氷でいいんですね、氷。
はい。
はい、氷ってOSSを作られていたので、ちょっとこれについて聞いてみようということで、はい、お呼び立てをしてますっていう感じです。
ありがとうございます。
はい、なのでちょっとこの氷について紹介してもらっていいですか。
はい、そうですね、氷はまだ作ってる途中なんですけど、タイプスクリプトのサーバーサイドのタイプスクリプトのウェブアプリケーションフレームワークですね。
結構タイプスクリプトなので、型安全に作れるところを最大限生かしたいなと思って作ってます。
だからそのバリデーションのスキーマとかを定義したら、それがそのままバリデーションされたものが型安全に取り出せて、
それを使えるとか、そのスキーマがそのままオープンAPIのスキーマになるとか、そういうふうなのができたら便利かなと思って作り始めてます。
その特徴としては、コアのルーターの部分は炎なんですよね。
だから炎をラッピングした氷みたいなんで、ちょっとすぐ溶けてなくなっちゃいそうな感じしますけど、そういうフレームワークになってます。
ただ炎のルーターがコアにあるので、安心して使えるかなとは自分で思ってます。
確かに炎をラップすると確かにすぐ溶けちゃいそうな感じはしますね。
「氷」の開発動機
でも、きっと炎と氷結構対比で面白いですよね、名前としても。
しかも結構しっかりとしたそういう型定義っていうかリクエストパラメーターみたいなところを含めて静的なリクエスト処理をしようっていうところで、
氷っていう名前になってるのはなかなか面白いなっていうのは思いました。
ありがとうございます。ちょっとその固い感じが出せたらいいかなって思ったのと、
まん直に炎だから氷かなみたいなんでつけちゃいました。
そうですね、これは日本人的にはすごい対比がわかりやすいっていう感じですね。
はい。
まあでも、そうですね、これってなんか作りたくなるだろうなっていう動機はなんとなくわかるんですけど、
なんかその作った動機みたいなのをもう少しお話いただいていいですか。
そうですね、一番最初はその炎のオープンAPIのところをZotとかで簡単に作れたらいいなと思ってプラグインとかを触ってみてたんですけど、
もうちょっと自分好みにやっても面白いかなって思い始めたのがきっかけなんですよね。
だから最初は炎のプラグインを作ってみようと思って、ミドルウェアか作ってみようと思ってやってたんですけど、
そのうちその炎の作りの中の方に入っていくと、この作りだと自分がやりたいところまで実現するのは結構深くまで手を入れないといけないなと思って、
一旦ちょっと諦めたんですよね。
で、その後しばらくして今年の3月とかぐらいかな、カーソルとかクロードコード、その頃はクラインだったかな、とかが流行り始めてて、
自分も触ってみてたんですけど、これ使ったらちょっとなんとか頑張れるかもなと思って、そこからちょこちょこ触っていってたっていう感じになってます。
なるほど。じゃあ炎には依存してるけど結構別のフレームワークとして作ってるっていう感じなんですね。なんですか?
そうですね。炎を参考にしながら作っていってて、一回その炎に完全に依存せずに作ってみるのもいいかなと思って途中まで作ってたんですけど、
やっぱりその炎のルーターはめっちゃよくできているなと思って、でもこれ炎を参考にして作ってるから結構炎のルーターも組み込みやすい形だし、
ウェブアプリケーションフレームワークのコアの部分は安心して使える方がいいかと思って、その炎のルーターを組み込むことにしましたね、途中で。
なるほど。炎のルーター部分だけ組み込んでるっていう感じなんですね。
はい、そうですね。その炎のルーターが結構インターフェースもしっかり作ってあって、組み込みやすい形なんですよね。だからそのままラッピングして氷の中に入れたって感じになってます。
炎の設計と機能
そういうことなのか。いや、それってすごく炎の設計が優れてるっていうか、そういうふうに単体で切り出して利用できるようにしてあるのってなかなかフレームワークとしては珍しいのかなっていう感じがするんですけど、
そこがちゃんと独立して、なんていうか素結合な形で切り出せるようになってるのって、かなり炎のイケてる部分なのかなっていうのは今聞いていて思いました。
本当にそうですね。炎のルーターは何種類かあって入れ替えられるようになってるんですよね、その用途によって。だからそれのうちの代表的なルーターを今組み込んでる形になってますね。
なるほど。そっかそっか。いろいろルーターありますもんね。レジェックスのやつとかトライトリーのやつとか、そういう。なるほどなるほど。
はい。だからインターフェースがしっかりしてあって、それで使いやすい形になってますね。
なるほど。これってやっぱりそういうオープンAPIみたいなものをお仕事なり趣味でも使うことが多いから、そういったものを作りたいみたいな、そういうのがあったんですか。
そうですね。オープンAPIみたいなものでインターフェース定義したいな、インターフェースっていうかAPIの仕様の定義をしたいなっていうのがやっぱり気持ちとしてはありますね。
なるほどなるほど。結構こういうニーズあるんじゃないかなっていうふうに思ってるんですけど、既存の類似のアプローチだったりとか、
そういうのってあるかどうかって調べたりとかってされました?
結構趣味で作り始めたので、そこまで深くは調べてなくて、そもそも炎にオープンAPIのプラグイン、ミドルウェアありますし、Zotのバリデーションの仕組みもあるんですよね。
最近また別のバリデーションの仕組みも入ってますけど、何日か前に発表されてました。
だけど、趣味でやる時に考えているのは、あんまりあるかどうか、既存のものがあるかどうかっていうよりは、自分にとって面白いかどうかかなと思っているので、全然気にせずにどんどんコーディングしてました。
なるほど、そっかそっか。もう炎にもやっぱりそういう機能はあるんだね。
そうですそうです。で、それのちょっと書き方が一部自分好みに変えたいなって思ったのがきっかけだけなんですよね。
具体的にはどういったところが自分好みみたいなところなんですか?
簡単に組み込めるっていうところですかね。炎のミドルウェアは結構柔軟な仕組みになっているので、型推論のところも効く部分と効かない部分があった気がするんですよね。
で、自分はそれをちょっと無理やり組み込みたいなって思って、バリデーションとオープンAPIが両方うまく動く形にしてみたいなと思ったっていうところですかね。
なるほどなるほど。やっぱそこは逆に結合度を上げて、パフォーマンス的にも使いやすさ的にも良くしたいみたいな、そういうモチベーションがあったっていう感じなんですかね。
そうですね。パフォーマンス的には炎をラッピングしているので、炎より良くなることはないんですけど、型安全性のところでいくと炎では柔軟フレキシブルな作りになっている分、ちょっと対応しきれない部分があって、
炎の場合はそこに無理やり制約を入れているので、制約のせいで割とシームレスにつながるような作りになっています。
なるほどなるほど。紹介している氷のウェブサイトだとランタイムキャストゼロみたいなことを書いてますけど、なので炎にオープンAIのミドルウェアを組み込むよりかはパフォーマンス出るのかなみたいなのを思ったんですけど、そこはあんまり気にしてないって感じですか。
オープンAPIの方ですよね。オープンAIじゃない。
そうですね。オープンAPI。はいはい。
そうですね。いや、炎はかなりパフォーマンスがチューニングされている感じがあるんですよね。だから、オープンAPIのミドルウェアを入れたらどれくらいパフォーマンスに影響があるかまでは見てないんですけど、
タイプスクリプトと開発体験
炎自体の作りが結構スピードが出るようになっている。シンプルな作りになっているって感じですね。で、自分の作った氷の方はもうちょっと型を持ち運ぶために冗長な作りになっている部分があって、それがパフォーマンスには良くない影響を与えるなとは思っています。
なるほど、なるほど。そうなんですね。
はい。
なんか、このZODとかでちゃんと型をつきま定義して、それをもうそのまままるっと食わせられるみたいな感じなのかなって思うんですけど、結構こういうZOD使ったりみたいなのは、結構趣味とかお仕事とかでも、そういうオープンAPIで何というか作るみたいなのは多いんですか?
そうですね。タイプスクリプトでサーバーサイドのアプリケーションをCacacheでは採用しているので、そういうところで結構オープンAPIとかZODで型安全に作ったりとかはやってますね。
なるほど。じゃあ新しいものは結構タイプスクリプトでサーバーサイドを作ってるっていう感じなんですね。
そうですね。自分が過去にやったことあるのは、FastifyっていうJavaScriptのフレームワークがあるんですけど、その頃まだ炎がそんなにメジャーになってなくて、自分は一旦Fastifyを採用したって形ですかね。それにタイプスクリプトのタイプを当てて使ってる形でやってます。
なるほど。
やったことがあるって感じ。
お仕事ではFastifyを結構使ってるっていう感じなんですね。
そうですね。FastifyとZOD組み合わせて使ってます。結構そのFastifyの思想も自分は好きなんですよね。そのコアをできるだけ小さくして、ミドルウェアとかプラグインで拡張するっていう形の思想で、それにも結構強く影響を受けてますね、氷は。
なるほど。じゃあ結構、例えば新しいものをお仕事で作るってなった時に、氷を使うかFastifyをまた使うかみたいなところも結構悩みポイントになりそうなんですかね。
いや、炎を使うかなと思います。
素直に炎を使う。
はいはい、氷使うとしてもちょっと一旦端っこの方で使うかなと思います。結構エンジニアがフレームワーク作って導入したはいいけど、その後メンテナンスしないみたいなのとかはちょこちょこ見かけるので、自分がそうなると申し訳ないなという気持ちもあって、まずは使うとしても小さい影響の少ないところでやろうかなとは思ってます。
まあそうですよね、こういうの。やっぱりいくらオープンソースにしてるからとはいえ事例が少ないとメンテナンスも止まっちゃうし、こともあるだろうし、やっぱその辺、すでにいいものがある場合はそっちを使うっていうのがいいですよね。
し、まあちゃんとそうですよね、最後までやっぱ責任、責任というか責任を取るみたいなのがやっぱ必要ですからね、ちゃんと自分が作ったものを突っ込むんだったら。
そうですね。
なるほどなるほど、まあ確かにそういう技術選定みたいなものも逆に立場が高い、相対的に高いとなんか自分のわがままを通しづらくなるというか、なんか通していいかどうか困る、迷うみたいなのが逆に増えてくるみたいなのありませんか。
まあ確かにそれはちょっと考えますね、もっとこう入ったばかりのエンジニアだったら、あのこれ作ったから使おうよみたいな言いやすい、今よりは言いやすいかもしれないですね。
そうですよね、しなんかまあむしろそういうのをちょっとやってみて、まあいい、なんかうまくいけばいいし、ちょっとした痛い目を見るみたいなのもやってもらえればなっていうのはこう思いますよね。
はい、30代前半だったらやってたかもしれないなっていう気持ちは少しあります。
まあそうですね、まあでもそう、まあ結構やっぱなんか自分が作ったOSS的なものをやっぱ仕事で使うっていうのはいい体験だと思うので、その若い人とかにはやってもらいたいですよね。
そうですね、いいと思います。ちょっとまあ自分もそのちょっとしたライブラリーぐらいだったらいいかなと思うんですけど、ウェブアプリケーションフレームワークは結構土台なので、まあちょっと手を出すのはなかなか勇気がいるなっていうところです。
氷の開発始動
そうですね、やっぱそういうなんかそうですね、フレームワークとかやっぱORマッパーとかそういうデータバインディング部分とか、あとフロントのなんかこうなんかテンプレートエンジンみたいなところはやっぱ自分で作るべきではないよなっていうのは思いますよね。
はい、そうですね。
まあ作ってもいいんだけど、なんかやっぱり既存のものよりよくできる可能性は低いよなっていう感じはしますよね。
そうですね。
そういう感じなのかなるほど。で、まあなんかこの氷っていうやつを、なんかこれってそのいつ頃から、だからその今年の3月4月ぐらいからまた作り始めて、8月の頭ぐらいにいったなんかアナウンスみたいな感じですよね。
はい、そうですね。3月、4月ぐらいからカーソルとかクロードコードとかでちょこちょこ遊び始めて。で、そうだな、そのカーソルとかクロードコードとか使いながら、それを会社でも生成AIの導入を推進する立場になってたんですよね。
で、でもまあ会社では結構サポートが多いので、メインでこう生成AIを使ってコードを書くっていう機会はあんまりなくって、だけどまあ推進する立場だからちゃんとエンジニアたちが言ってることを理解できないといけないなという気持ちがあって、まあちょっと家でも触るかって思ってたところに、
そうしばらく使ってたら、その生成AI使ってたら、なんかこれあのこうホビーコーディングぐらいだと全然あの深く理解できないなと思って、もうちょっと難しいものを触った方がいいなと思ったんですよね。
で、よく考えてみたら、なんかそういうのでいい題材ないかなと思ったら、そういえば炎の拡張してみたいんだったなと思い出して、それで触り始めたのが始まりですかね。
なんか結構ちょこちょこじゃあやられて、細かく少しずつ進めて、なんか8月ぐらいにその今月一段落したみたいな感じなんですか。それとも結構バリバリやってたみたいな感じなんですか。
そうですね。最初はまあ週に1回とか2週間に1回触ってちょっとコードを書くぐらいで、これできたら面白いなできるかなっていうのを生成AIに相談しながら書いてたんですよね。
で、そのうちだんだんこれもできるかこれもやってみたら面白そうかみたいなのを試行錯誤しながらやってて、だんだん書く頻度が上がっていった感じはありますね。面白くなってきて。
生成AIツールの進化
なるほど、そうですよね。たぶんそれこそ3月4月から8月ぐらいでもだいぶいろんな、ツールの変化とかトレンドの変化みたいなのがあったと思うんですけど、その中でどういうツールを使ったりとか、何が良かったかとかってどういうのがありますか。
そうですね。最初はChatGPTから始めて、ChatGPTにウェブで相談しながらこういうフレームワーク作ってみたいんだよねって話をしながら、じゃあこうやってたら作れるっていうのをウェブで出てきたやつをコピーして作ってたんですよね。
その後、クロードのウェブ版を触り始めて、こっちの方が書くコードがいいなと思って、そっちでやってたんですけど、そしたらしばらくしたらカーソル出てきて、これちょっとVSコード的なエディターの中で使えて便利だなっていうのを使い始めたのが、それからは結構進みが早くなったかなと思いました。
なるほど。相談とかはもう去年ぐらいからしてたって感じなんですか?カーソル自体は結構、去年と今年の頭とか、それぐらいにだいぶ流行って、なんか今は若干、使われる頻度みたいなのはシェアとしては減ったなっていう感じがしてるんですけど、
去年とかはすごいめちゃくちゃカーソルみんな使ってるみたいな感じだったなって思ってるんですけど、今でも結構しばさんカーソルがメインなんですか?
そうですね。多分僕はカーソルを使い始めたのは今年に入ってからだと思ってるんですけど、だからChatGPとかに相談してたのは去年かもしれないですね。
今年に入ってカーソルを使って、なんとなくクラインには手を出してなかったんですけど、その後クロードコードを使って、ソネットとかめっちゃ頭いいなと思いながらコーディングしてましたね。
あと途中でDeviumを使ったりして、でまた今はカーソルに戻ってきてますね。で、今のところの感覚としてはクロードコードとカーソルは、一旦クロードコードが先月とか先々月とかぐらいまでめっちゃ盛り上がってましたけど、今はまたカーソルとクロードコード同じぐらいなのかなとは思ってます。
そうですね。最近なんかカーソルもまた元気になってきてる感じもあるんで、同じぐらいってのはどういったところが同じぐらいっていうイメージなんですか。
そうですね。クロードコードはCLIで使えて便利だなっていうのとか、あとはオーパスが結構手放しで、ちょっと中規模のタスクをお願いできるっていうところとかが魅力的だなと思いながら使ってたんですよね。
ただ僕が使う使い方としては、もうちょっと相談をしながら使いたいので、やっぱりカーソルに戻ってきたところがありますね。
ちょっとクロードコードだと距離が遠いというか。で、自分の好みでカーソルに戻ってきたんですけど、カーソルの良さとしてはそういう近くで喋れる感じなのと、あとはモデルがいろいろ使い分けられるので、その辺も面白いかなと思って使ってますね。
そうなんですね。会社としてはその辺のツールってどういうふうにしていこうとか、そういう方針みたいなのって決まってるんですか。むしろシーバさんがある程度決めたり相談したり提案したりする側なのかもしれないなと思ってるんですけど。
会社は自分もみんなと話したりはしてるんですけど、みんなで手探りで進めてる状態ではありますね。結構医療系っていうドメインのこともあって、結構慎重にデータは使わないといけないから、丁寧にリスクマネジメントとかをしてるんですよね。
だからちょっとゆっくりめではあるんですけど、検証を進めていて、今はCursorとChatGPTとGitHub Copilotは普通に使える状態にはなっています。ただ今はそうだな、ChatGPTよりはGeminiの方がメインになってきてるかなと思いますが。
クロードコードはエンジニアたちが使いたいっていう話が出てるので、今パイロットでチェックしてるところですね。
なるほど。そうなりますよね。確かにデータアクセスとかその辺はかなりちゃんと制限して、そっちにアクセスがいかないような形でうまく使うみたいにしないと怖い部分はありますよね。
そうですね。特にMCPとかはリスクもかなり高いかなと思っているので、結構慎重にやってますね。
リスクマネジメントの重要性
そうですよね。ただなんか結構医療系、僕も関わってますけど、文書とかドキュメントみたいなものがやっぱり膨大にあるから、そういったものを食わせて、学習させて、ドメインにうまく落とすとか、そういったのができるだけでもだいぶ効率は上がるよなっていうのは思うところではありますよね。
そうですね。難しい文書とかもいっぱいあるんで、その辺を一緒に触れたりするのはいいですよね。
あとは、その氷の話には戻っちゃうんですけど、結構生成AIでいいなと思うのは、コードを書いてて自分が知らない情報をいっぱいくれるのがありがたいなと思いますね。
っていうのも結構その自分で一人で開発してると、知らないことにあふれるのが難しい、出会うことが。だから、自分はこういうことをやりたいんだけどなーみたいなのをカーソルに言うと、カーソルがこういう方法ありますよみたいなのを言ってくれた中に、あ、これ知らないっていうのがあったりして、そういうので結構勉強になってるなと思います。
それはありますよね。結構新しい書き方だったりとか、ライブやツールとか、そういうのを提案してくれたりしますよね。
はい、そうですね。あとは僕自身はその型から型を取り出したりするところとかは、そこまでちゃんとやったことがなかったので、今回氷のコアは結構そういう部分なので、その辺をカーソルとかクロードコードに聞きながらコーディングしてましたね。
なるほど、なるほど。そういうのできるの本当いいですよね。
一人だったら全然作れなかったなーと思ってます。
なるほど、いいですね。結構この氷の紹介エントリーみたいなのを見ると、そういう意味では結構アグレッシブにもう、なんていうか、AIとかそういう生成AIツールみたいなのを使ってみるみたいな、そういう振り切った使い方を、なんかそういうのされてるなっていうふうに思ったんですけど、
なので、もうかなりほとんどカーソルとかに書かせて、かつコードレビューとかも別のAIにさせるみたいなことをされてますよね。
そうですね。基本的にはコードは書いてもらえる分は生成AIに書いてもらって、コミットのメッセージもカーソルに生成してもらっていて、プルリクエストの作成とかディスクリプションとかもカーソルにお願いしてます。
で、OSSなんで英語でやるほうがいいかと思って、基本全部英語なんですけど、それ自分じゃ書けないなと思いながらプルリクエストを眺めたりしてます。
そうそうそう、英語ね、英語それなりに、それなりにっていうかちゃんと書いてくれるからありがたいですよね。
本当にそうなんですよね。自分だったらこんなに書けないな、書こうと思ったら1時間かかっちゃうなみたいなのが10秒ぐらいでできたりするのが便利だなと思います。
どれくらい自然なのかみたいなところはちょっとわからない部分はあるけど、でも普通に英語の勉強になりますよね。
そうですね、こういう書き方いいなと思ったりしながら眺めてます。
で、プルリクエストを作った後は、もうそれもSAIがいいかと思って、カーソルのバグボットってやつがあるんですけど、それにレビューしてもらったり、後はGitHub Copilotにレビューしてもらったりしてましたね。
で、バグボットがお試し期間が終わって有料化したんですけど、それはさすがに払えないなと思って、コパイロットだけにしようと思ってたら、TwitterXでコードラビットってやつありますよって教えてもらったんで、コードラビットを入れて使ってみてるとこですね。
コードラビットはOSSの場合は無料で使わせてもらえるんで、ありがたく使わせてもらってます。
そうですよね。この氷のコントリビューターを見ると、AIツールがたくさん並んでて面白いなっていう感じになりました。
そうですね。コミットしてくれてるのが並んでるんで、4,5人AIがいるかなと思います。
結構レビューも生成AIによって違うので、それも面白いなと思いながら眺めてましたね。
確かに。コードラビットどうですか?
そうですね。結構いいなと思ってますね。もともとバグボットは結構好きだなって思う感じだったんですよね。
コンテキストを広く見てくれて、指摘をしてくれるので結構当たってることが多くて、確かにそうだなと思いながら修正。
修正自体もカーソルにやってもらってたんですけど、修正を依頼してたんですけど、
コパイロットはまだちょっとめちゃくちゃレビューが早いんですよね。
だけどその変更した範囲ぐらいしか見てないっぽくて、ちょっと他を見たらわかるような間違えた指摘をしてくることも多いので、
パイロットは3,4個指摘してきたら1個いい指摘があるかどうかみたいな感覚があるんですけど、
バグボットは結構指摘してきたらそれは直さないといけないなと思って見てました。
コードラビットもバグボットと近いぐらい、もっといいかもしれないなと思いながら見てます。
ちょっとレビューに時間はかかるんですけど、指摘されたことは確かにって思うことばかりですね。
そうなんだ、なるほどな。それはちょっと興味が出てきたな。
コパイロットは結構すぐ使えるじゃないですか。使いませんか?みたいなのが結構GitHubでコード書いてるとサジェストしてくるので、結構使ってみたことがあるんですけど、
なんかちょっと正直がっかりなレビューしか出てこないなっていう感じがしてて、あんまりそういったものを使う気が起きてなかったんですよね。
すごい些細なニットピックだったりとか、細かいコーディング規約的なそういうところの指摘に終始することが多い印象だったので、
あんまり役に立たんなって思ってたんですけど、でもそういうちゃんとコードラビットとかはちゃんと役に立つんだなっていうのは、いいなって思いました。
でも僕はデフォルトのまま使ってるので、特にチューニングとかせずにやってるんで、ちゃんとコンテキストとか指示を設定ファイルとかに書けばまた違うかもしれないなとは思ってるんですけど、デフォルトで使ってるときにはそんな印象でしたね。
なるほど。AIツールのチューニングみたいなのって結構みんな頑張ってる印象ですけど、あんまりそういう小手先のことで消耗したくないなっていう感じが僕はちょっとあって、僕もやってないんですよね。
カーソルとプロジェクト管理
一応カーソルにルールは与えてるんですよね。プルリクエストのレビューではそんなに何も設定してないんですけど、普段のコーディングの中では結構指示をちゃんと出しとかないと、ルール決めとかないといろんな書き方があるんで、そこはある程度指示出してますね。
タイプを使うのかインターフェースを使うのかとか、関数を使うのかクラスを使うのかみたいな、そういう大きい方針は書いてはありますね。
そこは必要ですし、だんだん使ってれば使ってるほど成熟してくる部分ではありますよね。
そうですね。カーソルであるのはそういうルールを明示的にmdcっていうファイルに書いたりするのもあるんですけど、それとは別に指示出したときにシーバさんはこういうものを好んでいるみたいなのを覚えていくんですよね、ちょこちょこ。
それがその多分プロジェクトのコンテキストで覚えられるっぽくて、そこもちょこちょこ使ったりしてますね。ただそこに乗っちゃうと僕のローカル環境ですか、覚えられない、メモリされないので、その中でも重要かなと思ったやつはルールに書き出してほしいっていうのをお願いしてます。
基本そういうルールも全部カーソルに書いてもらってるって感じです。
そうですよね。そうだよね。それってクロードコードでも普通にそういうのできるので、最近はそういう方向性かなっていう感じがしますね。
なんか最近だとそのエージェンツMDみたいなものが出てきてっていうか、ある程度そういうどこに書くかみたいなのが定まりつつあると思うし、あれってカーソルもなんか参加してましたよね。
参加してるんじゃないですかね。あんまり自分は家でコーディングするときはもうカーソル以外あまり使う機嫌ないので、カーソルとかでいいかと思って作ってますけどね。
確かに確かに。あれなんかクロードコードが入ってないじゃんみたいな、なんかそのワーキンググループ的なやつにっていうのが結構取り沙汰、話題になってましたけど。
でもなんかそういったところに共通のルール書いておいて、エンジニアは好きなAIツールを使うみたいなのになると、確かにいいよなっていうのは思ったりはしたりしています。
そうですね。はい、なるほど。あとあれですよ、ディープウィキを設定するといいんじゃないかなっていうのを思いました。
デビンのやつですか? あ、そうですそうです。ディープウィキ、なんか最近OSS調べるときにディープウィキ見るっていう人がすごくたくさんいるんですよね。
っていうのがあるので、ディープウィキって誰でも普通に見に行ったらオープンソースのリポジトリのディープウィキ作ってくれるんですけど、リポジトリのReadMeにディープウィキのバッジつけとくと自動的にリフレッシュしてくれるみたいなのがあるんですよ。
へー、そんなのあるんですね。 なので、リポジトリのReadMeにそれを入れておくと、結構目につく人とか、理解を使ってみようとする人が増えたりするかもしれないなっていうのを思いました。
ありがとうございます。そうですね。言ってドキュメントも今書いてもらってるんですよね。GitHub Pagesで。カーソルとかに生成してもらって、できるだけ読んでる、使おうと思って読んでくれた人がわかりやすいように書いてほしいみたいな指示を出して、ドキュメントを生成してもらっている感じですね。
それももう少ししたらちゃんとブラッシュアップできるかなとは思ってます。
そうです。GitHub Pagesでなんかやられてるなーっていうのを見ました。そう、やっぱドキュメントを書いてくれるのがね、でかいですよね、本当に。
そうですね。しかも英語で書いてくれるので楽ですね。まず英語版を作って、これで大体見ても流れは悪くないなと思った後に、じゃあこれを日本語に起こしてほしいっていうのを依頼して、日本語版作った感じになってます。
なるほど、なるほど。じゃあだいぶ小売の話をして理解が深まった感じなので、ちょっと前半はこれぐらいにしようかなと思います。ということで、じゃあ一旦この辺で切ります。ありがとうございます。
ディープウィキの活用
ありがとうございます。
