開発ツールの現状
こんにちは、AI駆動開発部の日常へようこそ。このポッドキャストは、日々AI駆動開発を行う企業課の山本とエンジニアの阿部が、AI駆動開発のリアルを緩く語り合う番組です。
はい、ということで、今回もよろしくお願いします。
はい、お願いします。
はい、ではですね、今回話したい内容が2つ、前半後半でありまして、前半が先週ね、ちょうどWindsurfとかCodexとか、
アンチグラビティ、クロードコード、カーサー、いろんなツールがある中で、2人とも何使ってんの?みたいな話したと思うんですけど、
そこからアップデートがあればその話ができたらなというふうに思っています。
その後また1週間経って、この辺がいいんじゃないか、心地いいな、みたいなところが出てきたかなと思うので、その話できたらと思っています。
後半は、最近ね、ドキュメントを更新し続けるの大変だねっていう話になって、
そこのドキュメントを更新し続けれる仕組みみたいなのを作ったので、その辺りの話をできればと思っていますので、よろしくお願いします。
はい、じゃあまずは、あれからまた1週間経って、今どういうふうに開発進めてるかみたいなところの話からできればと思いますが、僕から話しましょうかね。
はい、前回、CursorでCodecs、Gemini、Cloud Opus 4.5の3モデルに並列で要件定義投げて、その後Cloud Codeのサブエージェントで実装を進めるっていうふうに話したかなというふうに思ってるんですけれども、
そこからちょっと移り変わりというか、そんなに変わってないんですけど、ちょっと変わりがあったので、その話できればと思います。
で、話した後、速攻あれ?HunchGravityの方がいいんじゃね?ってなるときがあって、速攻ね。
で、それは、要件定義したやつを実装Cloudにしてもらって、全然ダメだったよね。
なんやけど、いやもうダメじゃんって思って、1回も全部フルリフレッシュして、もう1回HunchGravityにお願いしてみようってなったら、HunchGravity一発でかなりいいアウトプット出してきた。
それはUI的にもとか、ちゃんと感動してくれるとかそういう意味でも、完全に動作させれるとかそういう意味でもね、っていうのがあったんですよね。
かつCodexに最終レビューをお願いしても、特にプロジェクトのルールとかからの逸脱がないっていうところで、
まあなんかかなりいい動きするなと思って、あれやっぱHunchGravityいいんじゃないかなみたいな風に一瞬思ったんですけど、結局今の状況で言うと、逆になんか最近Cursor使ってなくて、
Codexで要件定義させて、その出来上がった要件を元にクロードコードで、サブエージェントで開発させますと。
で、そっからなんかUI的なとか、結構こみ入ったUIとか作る時に、かなりなんか複雑で全然できない。Codexでもクロードコードでもできないってなったら、HunchGravityでGemini 3.0 Proにお願いするっていう。
そうするとね、Codexとかクロードじゃできないかったやつが一発でGeminiだとできるよね。
へー、それはなんだろう。UI周りの実装が強いのかな。
UI周りの実装が多分強いんやと思う。
あ、そうなんだ。
相当強いと思う、これ。マジで。
で、ただ、なんか普段のロジック周りとか、なんか実装漏れとかはやっぱあって、あと嘘つくとか。
やっぱそこ気になるよね。俺もすごい気になる。
なんでCodexで要件定義。Codexが一番コードベースの理解度が高いと思うから、Codexで要件定義して、で、なんでクロード使ってるかというと、並列開発がやっぱできる。サブエージェント使って。
たとえばなんか調査も、たとえばなんか20件ぐらい改善タスクがあったとして、その20件を全部プロンプトに与えて、これ全部それぞれサブエージェントに並列でお願いして調査お願いしますみたいな。
あなたはあくまでも指示を出すだけと、最終的に集まった情報の整理だけお願いしますって言って、そのバンって出すと。
14とか、今俺が観測している限りで言うと、14並列で調査してくれたりとかする。
クロードで14並列でサブエージェントが動くの?
そうそうそうそう。
すごいね。
そういうのもできるから、早いよね。
なので、たとえばタスクを澄み分けるみたいな時とかは、20個あってそのうち優先度高いとか、簡単に回収できそうなやつとかを洗い出す時とかは、
一回クロードコードでサブエージェントでバンって十何並列とかで調査してもらって、それを最終的にまとめてもらったやつをコーデックスに一回レビューしてもらうと。
やっぱりコーデックスからレビュー返ってくるんだよね。これ破綻してるよとか、こういう回収方針破綻してるよみたいなの返ってくるから、
それを元にまたクロードコードに返して、コーデックスの方で情報を整えたやつを最終的にプロンプトで渡して並列で回収してもらうみたいな。
8個の回収物、簡単なやつだったら8個の回収物を全部並列で回収してくれるみたいなことが起きると。
タスク同士の衝突みたいなのがあると思うよね、複数で並列するとき。
だからGitワークツリー使ったりとかみたいなのがあると思うけど、それはどっちかというと、
俺の場合はもうクロードコードのスラッシュコマンドにタスクの依存関係とかそういうのを整理した上で、
直列でやっていかないといけないタスクは並列しないし、並列で実行できるものは並列でサブエージェントに依頼するしみたいな、
そういうプロンプトを与えてやってるって感じ。
そうなんだってことは、クロードでまず10個とか20個ぐらいのタスクをガーッと整理してもらって、
Codexがレビューされた結果っていうのが1個のタスク、大きな1個のタスクになってて、
その中に何個も回収があるんだけど、そこの回収の進め方っていうのは、
スラッシュコマンドで依存関係を確認しながら進めてもらうみたいな使い方をしてるんだね。
そうそう、クロードコードにね。で、1個の大きい回収をやってもらうみたいな感じだと、
初手からCodexに要件まとめてもらってっていうのをやる、方向性と要件まとめてもらってってやって、
で、Codex1体だけだとちょっと心もとないんで、2、3回ぐらいレビュー通してやるみたいな感じでやってる。
で、最終的なUIの調整部分で、どうしてもどんだけ指示飛ばしてもできないってなったら、
アンチグラビティにお願いするみたいな。
どうしても指示通らないっていうのはさっき言ってたUI周りのことがメイン?
開発プロセスの効率化
UI周りのことがメインかな。どっちかというと。
ロジック周りでどうしてもっていうのは、俺の中ではあんまり特にそういう現象が起きたことないかな。
まあそうだよね。俺もあんまりそういうのにはぶち当たったことないかな。
うん。なんかコミュニタUI作るときとかかな。
はいはいはいはい。
で、アンチグラビティにお願いするときのコツとしては、なんかその画像をちゃんと渡してあげる。今こうなんだよっていう。
はいはいはいはい。
うん。で、するとなんか精度上がる感じがする。
え、なんかさ、アンチグラビティってさ、右上にChromeのアイコンがあるの分かる?
あーはいはいはいはいはい。
あれでさ、ブラウザ起動したら、プレイライトなのかな?みたいな感じで操作してスクショ撮ったりしたりして、自律的にやってくれたりするけど、そういうのは使わない?
いや俺それさ、それはちょっと逆にアベちゃんに使い方を教えてもらいたいなって思ってる。立ち上がったことない。
立ち上がったことないけど、そこに対して魅力に感じてるというよりは、圧倒的UI生成能力に対して魅力を感じてるかなって感じ。探索してくれたらよりいいんだろうなと思うけど。
けどアンチグラビティ、そんなにタスクとかそういう意味では抜け漏れがあったりとか、リファクタリングとかそういうので言うと、タスク生成のおそらく内部的に入っているプロンプトが優秀なんで、かなり漏れなくやってくれるんやけど、
実装でみたいなところで言うと多分、実装でとかもそうだし、ちゃんとエージェントMD的なやつを見るかとか、プロジェクトルールを見てるかみたいなとか、そういうところにちょっと危うさがあるから、基本的にメインでは使ってないっていう前提があるんだけど。
なるほどね。まあなんやかんやアンチグラビティってなった瞬間はあれど、結局はクロードコード、コーディックスの、しかもCLIにほとんど戻っていってる状態なのかな?カーサーすらもあんまり使う頻度が減ってきてるのかな?
いやーそうやね、なんか、いやけどカーサー、説、なんかちょっとそこは揺らいでるというか、その4件定義は正直コーディックスのモデルが優秀って話やと思うから、カーサーから呼び出してもいいと思っていて、マストナンはクロードコードとアンチグラビティなのね。
ツールとしてというかサブエージェントの機能とかそういう意味で、マストナンはクロードコードと、あとアンチグラビティ。
UIをどうしても詰まったときのアンチグラビティってことやね。
そうそう、経由で使うGemini 3.0 Proっていうのが多分UIの、だからそっちがマストナンで、逆に言うとだからコーディックスモデルが呼べれば何でもいいって感じかもしれない。
なるほどね。
でもなんかCLIの方が立ち上げやすいとかで使っちゃいがちなんかな。
そうだね、結局そうなっちゃうね。以前のエピソードでも話した通り、やっぱTMAXで平行が簡単にできるというか並列で動かすとか、割と取り回しがいいし、やっぱり結局ターミナルで自分でタイプチェックとかリントとか回したりとかするから、その画面の中でやっちゃってるみたいなのがあるかなって感じ。
はいはいはい。
最近の実装がクロードになるっていう前提を考えると、まあそうですね。Cursorでもいいし、本当にどっちでもいいなって感じ。
けど観点としてはおそらくコーデックスをやめて、ChatGPTの課金をやめてCursorに寄せた方が、結局スラッシュコマンドはクロードと共存というか共通化できるっていうことがわかったので、
そういう意味では、そっちの方がスラッシュコマンドをちゃんと統一的にとかそういうのができるから、結局いいのかな。だからCursor、クロードコードっていうのは変わらずって感じかな。
あれだよね。Cursorが上手いことクロードコードのグローバルのスラッシュコマンドを読み込んでくれるから、再利用できるよねっていう話だったよね。
そうそうそうそう。
コーデックスがね、クセがね、スラッシュコマンドのクセが強くてね、なんか引数をプログラミングみたいに引数渡すような感じだから、なんかあいつだけちょっと書き方違うみたいな感じになって、ちょっと統一できないから。
そうそう、管理がちょっと。
大変だよね今。
うん、っていうのがまああるねーって感じ。
今はね、コーデックス、クロードコード、そしてCursor、なんならアンチグラビティ、それぞれ課金してるから、どれか一個でも削りたいなって思ったら今、コーデックスを削っていくのが、Cursorに寄せるっていう意味ではいいのかもしれないなっていう話はしてたよね。
そうなんよね。
って感じかな。今のところはっていうところで、感じです。
阿部ちゃんは?なんか変化あった?
まあ大きくは変わらないんだよね。でもまあ前回僕が話してたのは多分Windsurfがメインで、なんかそのGemini3 Proが出てきたから、アンチグラビティも使ってみたよっていうので、
アンチグラビティなんか使ってるときに結構いいなっていうのは、まあこの間も話したけど、阿部ちゃんも話したと思うけど、タスクの生成の精度というか、詳細に書いてくれるので、大きい開発をするときとかはアンチグラビティ使うといいよねみたいな話を先週もしてたと思うんだけど、
まあ同じくですね、やっぱなんか漏れが、結構致命的なところで漏れたりしたりしてて。
なんかプロンプトじゃないところやね、たぶん。嘘つきやすいところ。そういう性格によってっていう感じやな。
ちょっと信頼が難しいかなっていう風になってきちゃってるので、結局のところWindsurfがメインになりつつ、ちょっと細かく計画を立てたりとか調査をザッとするのには、
コーデックスとタスク管理
コーデックスを使って、CLIのコーデックスを使って、まず大枠の仕様とか何をしなきゃいけないっていうのをざっくり書いてもらって、それをアンチグラビティに渡してタスクを詳細に作ってやってくださいみたいな使い方を試しにやったりはしてたね。
はいはいはいはい。
それだったら抜け漏れとかない?
あ、そうそうそうそう。
結局要件定義はコーデックスにさせるのがいいっていう結論かな。
そうだね、僕の中では今のところそれで。Windsurf上の使ってるモデルに関しても、ほぼコーデックス5.1リーソニングモデルしか使ってないぐらいになってきてますね。
あ、急グロックファーストとかは使ってないんだ。
グロックファーストに関しては、なんか動かなくなっちゃって。
あ、Windsurfね。
そうそうそう、Windsurfで、そもそもレスポンスが返ってこないみたいな事象に陥ってまして、それが今3日間ぐらい続いてるんだけど。
はいはいはいはい。
ちょっとサクッとしたタスクが、サクサク進められないのは若干ネックでありつつも、言うてもコーデックスそんなベラボーに遅いってわけでもないから、一旦それでやってるっていうような感じかな。
うんうんうん。クロードコードは使ってない?それで言うと。
使わないね。
いやなんか、いいよクロードコード。実装力というかその、まあやっぱ並列で開発できるっていうのと、何がいいかっていうとあの、前回も話してたコンテキストエンジニアリング的な意味でも、そのタスクに必要な情報だけを渡してサブエージェントを動かすじゃん。
うんうんうん。
だから多分その、まあAIにこうまるっと大きいタスクを渡すより精度が高いよね、サブエージェントに渡していく方が。
うんうんうん。
だからしっかり一個一個やってくれるっていうのと、やっぱ並列でやってくれるから早い。そのなんか単純なモデルの速さじゃなくて、並列でやってくれるから早いっていう。
あ、そこは結構魅力的だよね。
そう、って感じかな。まあだからある意味バランスはいいよね。なんかやっぱ劇的に頭がいいかって言われるとあれだけど。
まあやっぱツールとしてのなんか成熟という、成熟っていうのかな。なんかかゆいところにしっかり届いていろいろこう、やれる幅が広いから。
まあなんか並列でもできるしとか、スキルとか。
阿部ちゃんが言ってた、あのプランモードみたいな。
あ、はいはいはい。
3つぐらい質問くれてみたいな。質問くれて精度上げるみたいな。それがさ、なんか実装の途中でも発動することがあって。
あ、そう、それ僕要件定義とかプランモードだけで出てくるものだと思ったら、そうじゃないんだね、あれ。
そう、それが発動してくれたことによって、そもそもクロードコード側の認識している問題と、こっちが認識している問題の層があることが発掘できて。
へー。
そう、そこ、そういう意味でも結構、なんか有用かなって感じ。
はいはいはい。
うん、なんかCodexとか、まあGeminiもそうかもしれないけど、結構頑固じゃん。
そうなんだよね。
うん、けどクロードコードは、なんかそこで言うと、あれ、今その観点で質問してるってことはちょっと認識層があるかもしれませんみたいな書いて、
で、これこれこうでこういう問題です、なのでここは関係ないですみたいなんて書いてあげると、あ、なんかなるほどみたいな認識の層があることが分かりましたって言って、結構一気に方向転換してくれて、最終着地してくれたから。
だからなんか考えるっていう一番、頭使うとか、コードのコードベースの理解が必要な部分だけCodexに渡してあげたら、
あと実装してる中での矛盾とかがあったら、ちゃんと方向転換もしてくれるし。
うんうんうんうん。
まあ実装者としてはすごい良いなって。実装者としてっていうか、まあクロードコードと抱き合わせでね、すごい良いなって。
まあ確かに、なんか最近僕はもうWindsurf一択になりつつある。
まあこの間とかはCodex CLIも併用してて、でWindsurfのCodexも使ってるっていう話をしていたと思うんだけど、
なんかWindsurfよりもCLIの方が精度高いんじゃないのかなとか、なんかより良いアウトプット出してくれるなっていう感覚があったんだけど、
なんかそこに関しては、やっぱMCPの充実度が、CLIの方が昔から使ってる、前から使ってるから充実してて、
結局コンテキストエンジニアリング的に優位だったっていう感覚になりつつあるので、今Windsurfにどんどん加わせてってるんですよ。
で、そこでやっちゃうと、なんかもうターミナルに行かなくなっちゃったんですよ、今週とかほとんど。
逆にね。
あ、そうそうそう。で、ってなってくると、クロードコードは、特にクロードのモデルはWindsurfではフリーのクレジット消費のないモデルがないので、
そっち側でも触らなくなったし、で、CLI側にも行かなくなりつつあるので、なかなかこう起動するタイミングが減ってきちゃったなっていうのが僕の使い方なんだよね。
クロードコードの有用性
クロードを使う、多分アベちゃんとかだとクロードを使う理由は、まあクロードコードを使わなければね。
他のツールからクロードのモデルを呼び出す理由っていうのはほぼない気がしてて。
なんでアベちゃんだったらなのかっていうと、多分俺とかコードの理解とかがそんなに薄い場合は、
分かりやすく説明してもらうことが結構重要じゃん。で、やっぱクロードのモデルって丁寧やから、結構しっかり図解してくれたりとか、
表にしてくれたりとか、分かりやすくしてくれるのよね。その要件とか質問してくれるときとかも。
で、そうしたときにWindsurfとかCursorとかだと、まあ普通にマークダウンで表示されるじゃん。会話の中でも。
だからすごく見やすいので、Cursorで使っててもクロードオーパス4.5が出すアウトプットというか、
こっちに教えてくれることっていうのはかなり有益、俺にとってはすごい分かりやすくて判断しやすい情報をくれてるっていうのがあって。
けど別にアベちゃんそこまで必要ないと思うよね。そもそもコードベースの知識あるしみたいなところがあるとか。
その間怒ってたからね。細かく言い過ぎだよって怒るぐらいじゃん、アベちゃんとか。
そうなってくると多分、本当に出してくれてる情報が正しいかどうかっていう信頼性においてはコーデックスの方が上だから、
そうするとクロードをアベちゃんが他のツールから呼び出す理由っていうのはほぼないと思ってて。
クロードコードで並列開発するっていう強みを生かすためだけにクロードを使うっていうのはあり得ると思ってて。
なので、アベちゃんの今の状況は割と必然だなって。逆にクロードコードを使うんだったらアリだと思うって感じかな。
なるほどね。確かに、それで言うと、今って、Windsurfにひたすらコーデックスを元々CLIで使ってました。
コーデックスのスラッシュコマンドとかカスタムコマンドがかなり独特すぎて、できるだけそこは排除していって、
引数とかじゃなくて柔軟にカスタムコマンドを作れるWindsurfに寄せていってるんですよ。
どんどんそっちに作っていって、そこでコーデックスを使ってるんだけど、その後、次の話としてはやまちゃんが言うように、
例えばクロードコードをCLIで使っていくって言うんだったら、いつのこと俺もWindsurfは捨てちゃって、
カーサーとクロードコードの2つを使って、カーサーのコーデックスをひたすら検討するときは利用して、
クロードコードには実装してもらうってやれば、完全にクロードコードのスラッシュコマンドでカスタムプロンプトン部分は統一できるようになるから、
今の話をしてて使い方を考えたら、僕はWindsurfじゃなくてカーサーに移行してもいいかなって思った。
なんか俺はカーサーに移行してもらいたいと思ってるけどね。
てか、移行してもらいたいと思ってるのもそうだけど、アメちゃん結構既存のお客さんがいるプロジェクトも多いじゃん。
なんかより確実なものを進めるとか、あとバグ調査とかあると思うけど、それも結局カーサーでやったほうが、カーサーだと最大8つまでの調査並列ができるわけじゃん。
並列調査できるね。
そうそうそうそう。やっぱそこが調査においては8個ぐらい並列すると、確からしさがつかみやすいじゃん。
その調査の。っていう意味では、8個もやらなくてもいいかもしれないけど、4つとかさ、そういうのでやれたほうが、アメちゃんのタスク的にはいいんじゃないかなって気はしてる。
まあ確かに。まあでもその話で言うと、先週、今週ぐらいから調査に関しては、もう4並列か5並列で一気に同じ調査依頼して、それをまとめて総括するみたいなのを基本に動いてるから、そういう意味でもカーサーがいいのかなみたいな若干ありそう。
カーサーの方がむしろいい気がする。であれ、カーサーはGitWorks3で分離するけど、前も言ったけど、分離するけど、マージできるから簡単に。
だからその、例えばなんか、なんちゃら調査フォルダみたいなのを作るとして、そのなんちゃら調査フォルダの中のファイルにIDを付与して、それぞれファイルを作成してもらったら、全部マージできるんよね。そのフォルダの中にだから8人分の調査ファイルみたいなのを、ボンって一気に作れると思う。
それを別になんか、例えばそのブランチ名にするっていうだけで全部ユニークになるから。
まあ確かになー。
そう、GitWorks3のブランチ名にして、ファイル名を付けてあげたら、そのフォルダの中に一気に8個の調査ファイルができて、それを統合するみたいなのをメインのエージェントにやらすみたいな。
そういうやり方もできてくるから、結構なんか有用ではある。
あとまあバックグラウンドエージェントとかね、その辺がやっぱり出てくるから、あとでね、話すことになると思うけど。
あとね、Windsurfはアプリがない、モバイルアプリがないけど、Cursorにはモバイルアプリがあるから。
そこもちょっと、もしかしたら魅力かもねって思ってるけどね。
確かに。外出時でもね、できるって書いてある。
結構最近…
それデカいなー。
やっぱなんかWindsurf使ってて、Windsurfのチャット内で複数、何個も何個も依頼は投げたりできるんだけど、席離れたらもう一切触れないから。
まあコーデックスCLIもクロードコードもそうなんだけど。
そうね、それでCursorにするのもありかなとは思うけど、ちょっとだけ後ろ髪引かれるのはCodemapsとかDeepWikiが結構なんでしょう。
既存のお客さんがいて、僕が説明責任を持っていて、ちゃんと状況を理解して何でこうなってたかっていうのを説明するときのキャッチアップでは、やっぱこれすごく効いてたので。
まあそれが欲しいな、Cursorにあったらいいなみたいなのは若干ありつつ。
なるほどね。
まあ試しに。
スラッシュコマンドでいけそうやけどね。
まあね、まとめてくださいって言えばいいような気もするけどね。
そうそうそう、関数名渡してスラッシュコマンドで引き継いで関数名渡したらいけそうやね。
まあまあそんな感じで、ちょっとCursorいいんじゃないかな、僕はCursor推しにどんどんなっていってますっていう話ですね。
では僕は来週、というか今日からCursorを導入します。
ドキュメント更新の仕組み
はい、ちょっと使ってみてください。
あとクロードコードの並列開発も正直結構いいなっていう風に。
中央並列とかCursorにはできないよね、サブエージェントじゃないからCursorの並列っていうのがあるんで、結構いいなって思ってますね。
まあそんな感じで、じゃあちょっとドキュメント更新の仕組みを整えたみたいな話。
僕からざっくりと課題感がこんな感じで、こういう風になってるみたいなところで、
阿部さんに整備してもらったから中身は全然知らないんで、ざっくり概要だけ僕の方から言ってって感じにしましょうかね。
今回Devinを使ってやってもらったんですけど、課題としては結局ガンガンAIで開発していくんですけど、
そのドキュメント管理、常に最新の情報にする管理するの面倒くさいというか遅いし結局。
毎回Cloudとかにお願いしても毎回遅いから、できるだけ非同期にしたい。
だからこっちで何も考えずに勝手にドキュメント更新されてるみたいな状態を作りたいと思ってました。
で、だからそれで言うとどのタイミングでドキュメント更新してもらった方がいいかみたいなところで言うと、
プルリクエスト投げた時にGitHub Actionsとかで動くとかがいいのかなっていう話はしていて、
なんでそこの整備をしてもらいましたっていう感じなんですけど、
プルリク投げたらそこから発火して、Devinが実際のこのコード差分を見て、
その結果、コード差分の結果、見た結果ドキュメント更新が必要であると判断したら、
勝手にドキュメントを更新してくれて、それをマージしてくれるみたいな感じの仕組みになってるという感じで。
ちょっとこの辺の細かいところを阿部ちゃんに…
なんか俺知らんから。
ほぼ言ったみたいなもんだけどね。
まあまあまあ。
教えてほしいなっていうところと、
あと正直本当はDevinじゃなくて、違うやつにしたいねっていう。
そうなんだよね。
やったこととりあえずで言うと、山ちゃんが今言ったように、
まずドキュメントをね、とにかく更新してほしいので、
とりあえず試しにDevin動かしてみようかっていう。
しかもクレジット今余ってるからっていうところを起点で、
とりあえずDevinにドキュメント生成をお願いしようかなっていうところからスタートしたんだけど、
お願いするにあたってもスラックとかで依頼するとか、
いろいろやり方があると思うんですけど、
プルリクエストをGitHubにプッシュして、プルリクエストが作成されたタイミングにトリガーして、
GitHub Actionsを回せるようにしているので、
そこの中でDevinのAPIがあるので、
新しくDevin向けにセッションを作成して、
ドキュメントを作成するためのプロンプトを一緒に与えてあげて、
このプルリクエストの変更差分を確認して、
詳細にドキュメントの更新をお願いしますと。
ドキュメント更新をする際は、ディアタクシスというドキュメントを作成するためのフレームワーク、
思考のフレームワーク的なものにのっとって、
ドキュメントを書き込んでくださいね、みたいな依頼を投げていて、
もし変更が必要だったら、そのプルリクエストに対してそのままコミットしてプッシュして変更を与えてくれるし、
なければいらない、今回の回収ではドキュメント更新不要ですよ、みたいな感じで動かしてるっていうのが、
ディアタクシスの導入
大枠かな。
やったこととしてはこれぐらいなんだよね。
簡単にできるもんなの?
あれか、簡単か、API呼び出したらいいってだけなのか。
一瞬一瞬、だからAPI叩いてプロンプトを渡せばいいだけなんで。
あとはデビンが自律的にやってくれるから、
プロジェクトを起動して実際に中身見てもらったりとか、そういうのもデビンは自律的にできるから、
あとはプルリクエストの中身をより詳細に確認してくれたりとかってくれるから、
全部デビンにお任せしようっていうのでやっていった感じかな。
本当はそれこそオープンAIのAPI、コーデックスのモデル使うだったり、
クロードのモデルを使うとか、他のLLMに任せる手もあると思うんだけど、
そっちはそっちでAPIの課金がかかってしまうかなっていうので、
今いったんデビンのクレジットあるし、やるって感じなんだけどね。
デビン自体もクレジットは消費するから、
じゃあ1回のPRのドキュメント更新のためにいからかかってんだいっていうような話は本当はあるんだよね。
そうやねんな。
300円ぐらいとかって言ってたよね。
だからそこはやめたいよね。プルリク投げる数分300円かかるのはちょっと嫌だなっていう気はしてて。
けど会社によっては全然いいじゃんみたいな話だと思うけどね。
人が管理しなくて良くなる。
結局見ないといけないから管理する必要あるけど、
仕組み化するという意味で、もう出来上がっちゃうからそれを見ざるを得ない状態に持っていけるっていうのは結構でかいから、
ドキュメンテーションをしっかりしないとみたいな、そこに課題感がある企業さんは結構いいよね。
いや本当にいいと思う。
安いもんっていう感じのね。
あとディアタクシスのフレームワークっていうのを使うのが、
安定したドキュメントを作成してもらう。
LLMにそれなりに網羅性のあったりとか、あとは整理されたドキュメントを作る上では、
これを使うのがやっぱり今のところはいいアプローチになってくるのかなっていうイメージでいるかな。
これが一体何なのかみたいな話も軽くしといた方がいいのかな。
そうやね。ディアタクシスはちなみに古代ギリシャ語に由来し、秩序や配置といった意味を持つらしいよ。
そうなんだ。
確かにそれを意識してそうな感じだよね。
4つのタイプにまず分類してドキュメントを作るっていうのが方向性としてありますよね。
1つ目がチュートリアル、2つ目がハウトゥー、3つ目がリファレンス、最後にエクスプレネーション。
この4つがあって、それぞれチュートリアルとかだと、まずそもそもこのプロジェクトを始めるにあたってどうすればいいのかみたいな概要を教えてくれて、
ハウトゥーとかについては個々の問題についてこういうケースでは解消するとか、こういうケースではこう使うみたいな部分書いてて、
リファレンスっていうのは一時情報的なAPIの仕様だったり、データベースのスキーマの仕様だったりを、
事実情報みたいなね。
事実情報を教えてくれるっていうところ。
あと最後に関しては背景とか、なんでこういうことをしているのかっていうところの詳細な説明っていうところの4分割に分けてるみたいですね。
ざっくり見たいみたいな、オンボーディングの時はチュートリアルを見て、ざっくり見たいんだよねみたいな時はハウトゥーガイドとかリファレンスを見て、
で、より詳細な経緯を知りたかったらエクスプレネーションを見るみたいな感じでね。
って感じかな。しかも僕らの使い方は、これどっちかっていうとAIが自分たちは開発しているプロジェクトについて、
ちゃんと毎回毎回セッションのたびに理解してもらえるようにっていうので、
AIDOCSっていうフォルダを作って、AI向けに書いてるっていうような、なんかそっちの方が強いよね。
DeepWikiの機能と活用
まあね、そうやね。
まあけど、だからこそ最新情報じゃないと困るんですよね。
あとなんか最近はけど、AIDOCSに、俺が要件定義したREQUIREMENTSっていうフォルダを作っちゃってるけど。
そこね、要件定義するとAIDOCSの配下に作っちゃうのは、ちょっと回避したほうがいいのかなとは若干思ってて。
例えばGitignoreでなんか。
エクスプレネーションに入るべきなのかな。もしかしたら。
エクスプレネーションに入れるべきなのかな。
なんかエクスプレネーションは一応議論の場として機能するっていうのが前提としてあるみたいなんで。
過去の経緯含めてみたいなんで言うと。
まあそこに入るべきなのかもしんないね。もしかしたら。
一時期その対応してきた履歴的な部分。
こういう機能が欲しくてこういうのを作りましたっていう計画とかも、
ドキュメントに残しておくべきかなとは思いつつ。
それは大事だけど、例えばバグの調査とかもあるわけで。
バグの時ってこういうエラーがあったからこういう回収しますみたいな計画になってるので、
あんまり残す価値ってそれほどにないのかなみたいな。
どっちかというとそこを抽象化して、
バグはないけどね。
俺のケースにおいてはバグの話は要件定義には入れてないかな。
リクワイアメントは基本的にもう要件定義書しか入ってないかな。
僕、リクワイアメントの中にそういうバグが起きました。
そのバグの回収のためにこういう修正するみたいなのも先生されてたりするから。
頼み方の問題かな。
そもそも要件定義書作らないっていう感じかもしれない。
バグの時は。大きすぎたらちょっとあれだけど。
使用変更みたいな意味合いでの要件定義書を作るから。
バグっていうよりは使用が良くないよねっていうのが起点なのかな、俺の場合は。
だからそういう意味ではリクワイアメントですよね。
純然たるリクワイアメントっていう感じ。
だからバグみたいなのはあんまないかもしれない。
確かに。規模が大きくなって全体的な仕様が変わるってなったら、それは普通に仕様に関するリクワイアメントになるので。
そうそうそうそう。
なのでそれは残すべきかなっていう。
いいや、ここの場とはちょっと違うところで話しましょうか。
というような感じでディアタクシスに乗ってて。
やっぱディアタクシスとかもう既に確立されてる考えに乗っとってAIにお願いするって結構重要よね。
だからまさにティーワダさんとかにテスト駆動開発をしてくださいみたいに言うと、より精度高くテスト開発をしてくれるとか。
みたいにグローバルには既に学習されている知識をちゃんと使うっていうのが大事だから。
今のところのたどり着いた結果としてはこのフレームワークを使うことなのかなっていう感じだよね。
だからAPI呼び出せたら別にいくらでもできるって感じか。
だったらディープシークとかでもできるかもしれないね。
そうそう。ディープシークとか他のモデル使ってもいいし。
ちょっとまあ少し検証してみたい、試してみたいなっていうのはデビンの内蔵のウィッキがあるじゃないですか。
あれをもう単一のリソースとしてしまう手もあるのかなと。
MCPでそのウィッキに対してアクセスできるようになるので。
そういうのあるんだ。
そうそうそう、そういうのもある。
何でしょう。仕様だったり、どういう機能があるかとか。
コーディングルールもある程度デビンの内部ウィッキに詳細に書いてくれるので。
そっちをメインに使いつつ、例えばコーディングする上で絶対守ってほしいルールとか。
要はagents.mdとかに書くにはあまりにも多すぎるけど、でも結構大事なのだけはプロジェクト内のドキュメントとして配置しておいて、詳細な仕様は。
それはできないんじゃないって思ったけど。
ディープウィッキをさ、そもそもカスタマイズできるようになってるじゃん。
だからむしろそっちに組み込むようにした方がいいのかなって思ったけど。
中途半端にこういう時はこうみたいな墨分けはなかなか難しいイメージはあるけどね。
こういう時はこうもそうだけど、
たぶん僕がエアクド開発してモデル観察してて思うのは、
似たようなトピックがあったらプロジェクト内を検索しているうちにヒットして、
あ、そういえばこういうのもあるんだみたいなのをチェックしたりしてる時もあるから、
コードを書く時に必要なパターンとかはプロジェクト内に配置しててもいいのかなみたいなイメージだったかな。
そうするとディープウィキも全部中に配置されてる方がいいっていう感じになりそうだよな。
まあ本来は全部書いてたらいいとは思うんだけど。
そう、だからディープウィキでmcpで読めるんだったらさ、
むしろ定期的にディープウィキからmcp呼び出しして、
サブディープウィキからいわゆるコピーしてくるとか持ってくるみたいな、
そういう仕組みを整える方がむしろセンス良さそうって思ったけど。
ディープウィキをそのままそっくり持ってくるっていうのをギッターバークションズで定期的に回しまくって。
そう、やったら別にそんなに頭が良くないモデルでもできそうだし。
それ一番いいかもしれない。
そしたらギッターバークションズ回して、デビンにクレジット消費しながらやってもらうとかじゃなくて、
DevinとDeepWikiの活用
もう出来上がった内部のウィキを取り出すっていう形になるからコスト的にも全然お安く済むし、
精度も非常に高くなるし、そっちがいいんじゃない?
デビンチームがカスタマイズしてくれてる前提やからね。
昨日僕たちが今作ってるプロジェクトをデビンウィキ作らせたんですけど、
かなり膨大な量の使用書、かつ中身もかなり整理されていて、
僕の知らなかった機能とかもちゃんと整理されて出てたから、
これやった方がいいんじゃないかって思って今日こういう話をしてたので。
なるほどね。
基本俺が今言ってるプロジェクトに関しては、
基本僕が開発してるやつなんて、阿部ちゃんが今、
使用を理解できてないところもあるっていう前提でもね。
そうなの。もう分かんない中でたまにバグ調査とかしてるから。
今すぐにそれやりたいな。試しに。
確かに今デビンのディープウィキ見てるけど、かなりいいですね。
ビジネス要件も全部まとめてくれてるんだ。
結構いいねこれ。
コーディングに関するルールとか、僕らが口酸っぱくAIに言ってた話。
今もドキュメントに書いてる。
コード規約とインスガイドね。
そこも結構しっかり書いてくれてるから、いいんじゃねっていう。
めっちゃいいじゃんこれ。
これをコピーできる仕組みに作るのが最高だな。
若干範囲にラグがあるけど、その辺のラグは許容かな。
1日ぐらいラグはあるはずだから。1日2日ぐらい。
まあまあまあまあまあ許容範囲じゃない。
ありだな。これできたら大発見ですよ。ちゃんとできたら。
いいね。
しかもこのディープウィーキ生成にはデビンの課金が走らないっていう謎なあれだからね。
なんかハックしてるような気分になるよね。
月額20ドル払えば、そのチーム内には何人でも参加できて。
しかもアスクもできてね。
仕様について質問して、しかもちゃんと詳細にリポジトリの中を探索してフィードバックくれるじゃん。
それが20ドルポッキリっていう。
どんだけメンバー入れてもね。
マジでデビン入れてないそこそこの規模の会社はマジで損してると思うね。
思っちゃうよね。
即入れた方がいいと思うぐらい。
もし聴いてる人が経営者とかAI開発やりたいと思ってる人だったら声かけてほしいですね。
僕らそういうのもやってるから。
自宅開発とかもそうですけど、AIのワークフルを整えたりとか、デビンの導入支援とかもできるから。
ぜひ。
SaaS開発の自宅とかもやってるんでね。
そういう意味ではもしリスナーさんで聞いてくれてる方いたらお声掛けください。
どこに行くの?どこにやったらいいのかわからないけど。
用意しておきます。
コメント欄に書いて。
ポッドキャストの概要欄に問い合わせできるようにしておきます。
いいなこれ。
これにしましょう。
こうやって来週その成果のご報告としましょうか。
あれけどさ、これあれじゃん。
スタートリフレッシュってボタンが配置されてるからさ。
手動でポチもできはする。
変更量がめっちゃ多いみたいになったらスタートリフレッシュして、今見たら30分くらいあったから。
だから全然いい。
さっき1日くらい差分あるみたいなの言ってたけど。
普通に結構コード変更したなって時はリフレッシュしたらOKみたいな。
それもそうだね。
素晴らしいね。
じゃあ決まりました。
これがちゃんと整ったらまたこのポッドキャストで報告しましょうかね。
そうですね。
じゃあこんなもんすかね。
もともとドキュメントの整備みたいなところがちょっと課題にあって。
結構他の会社さんの中でもやっぱ課題っていうのを感じてる企業多いなっていうのを聞いてたんで。
なんかいいソリューションみたいなのが作れたらいいなって思ってたんで。
ちょっと実験的に自分たちでやってみたみたいなのが経緯としてはあったんですけど。
結構AI駆動開発してたらGitHub Actionsでレビューを結構返してくれたりとかもするんで。
そのレビューの妥当性のチェックとかその辺りのワークフロー作りみたいなのにも今後ちょっと役立ってくるかなみたいなところはちょっと僕たちの中で話してたんですけど。
なんかそういうの興味ある方いたら本当にぜひお声掛けいただければと思います。
今日こんな感じですかね。またじゃあちょっと阿部ちゃんにカーサー使ってもらってまた来週教えてください。どんな感じか。
そうですね。
じゃあそんなもんすかね今日は。
はい。ありがとうございました。
AI駆動開発の新たな進展
じゃあありがとうございました。
本日もAI駆動開発部の日常をお聞きいただきありがとうございました。いかがでしたでしょうか。
今回の話題は前編後編で分かれて、ツールどんなの改めて使ってるのみたいなところの続編っていうところと、
あとはDevinを使った継続的なドキュメント更新、ドキュメント管理の仕組み作りみたいなところの話をしました。いかがでしたでしょうか。
もしこんなトピック話してほしいとか、これってどうなのみたいな話とかもそうですけれども、
僕ら普段からAIエージェントで開発とかも進めているので、知見共有とかもできるかなと思いますので、
ぜひコメント欄に質問とかお便りとかいただけると大変嬉しいです。
このポッドキャスト気に入ってくれた方は、いいねやフォロー、高評価ぜひお願いいたします。
それではまた次回もお楽しみください。バイバイ。
