00:02
こんにちは、AI駆動開発部の日常へようこそ。このポッドキャストは、日々AI駆動開発を行う桐岡の山本とエンジニアの阿部が、AI駆動開発のリアルを揺るぐ語り合う番組です。
はい。 じゃあ、よろしくお願いします。
よろしくお願いします。
はい、ちょっと1週間空いちゃったんですけれども、その1週間空いちゃった理由が、話したのに撮れてなかったっていう。
はい。
大きい声が出ましたよ、僕は。
というハプニングがあってですね。
まあまあまあ、仕方ないということで。
新たに撮る時間はないなーっていうことで、すいません、1週間空いてしまいましたっていう感じですね。
ちょっとあれかな、先週話してそれのアップグレードバージョンみたいな感じになると思うんですけれども、撮れてないんで誰も聞いてないっていう幻の回みたいな感じですけれども。
並列実装の概要
今日は、AI駆動開発とは切っても切り離せない並列実装ですね。
AI駆動開発の並列実行っていうところにちょっと焦点を当てて話ができたらなというふうに思っております。
最近だとオープンコードがちょっと話題になってたりとかもしたりするし、
クロードコードが結構みんなに重宝されている理由の一つはおそらく並列のサブエージェントで並列開発ができるっていう機能にもあるのかなというふうに思っていて、
そのあたりの並列開発って言ってもとはいえいくつもあるかなって思ってるので、
その辺の整理をして、その上で今後こういうのが開発的にボトルネックになるような話とか、
どういうふうに使ってるのかみたいな話ができたらいいのかなっていうふうに思っています。
よろしくお願いします。
じゃあちょっと簡単におさらいというか、全体感の把握みたいな意味で、
今なんか世の中的にある並列実装っていうところで言うと、どういうものがあるのかっていうところを整理からできればと思っています。
大きくは2パターンかなと思っていて、
カーサーとかがやっているベストオブエヌ。
だから1個の指示を複数のモデルにお願いするっていうものですね。
っていうのが1個あると思っていて、詳細は後で話してあると思うんですけども。
もう1つがクロードコードとかオープンコードがやってるやつですね。
サブエージェント型の並列実装っていうのがあるのかなって思っています。
それはどちらかというと1つのタスクを親エージェント、オーケストレートするエージェントに渡して、
そのエージェントがサブエージェントに指示を与えながらオーケストレーションをしてくれるっていうようなパターンですね。
この2つのパターンがあるかなっていうふうに思っております。
オープンコードとクロードコードの比較
結構大きな違いなのは、カーサーのほうは、ベストオブエヌのほうは、
Gitワークツリーの機能を使って完全にパラレルワールドみたいなのを作って並列実行するので、
お互い本当に全くパラレルな世界で、けどやってることは同じみたいな。
その中で1個チョイスするからベストオブエヌみたいな感じになっていると思うんですけども。
もう1つはクロードコードの場合は、あくまでも1個のブランチの中でサブエージェントを呼び出して、
なので1つのタスクを複数のエージェントで並列的に開発するみたいなのがある。
だからサブエージェントに作業自体を預けれるんで、コンテキスト効率っていう観点でも結構いいよねっていうところがあるのかなと思います。
一方でクロードコードの方は、もし仮にGitワークツリーを使えば並列でできるのかなっていうふうには思うんですけれども、
そういう機能が標準では搭載されていないっていう。
オープンコードもほぼほぼ一緒でサブエージェントみたいなのを呼び出してあると。
結構使ってみたんですけど、初め結構いいじゃんって思ったんですけど、
クロードコードとオープンコードを比較すると、
クロードコードって明確に親子関係がはっきりしてるんですけど、
オープンコードだと親子関係がちょっと曖昧で、
実はオープンコードサブエージェントを起動したら別セッションで立ち上がって、
そっちにも指示を追加で出したりとかできるんですよね。
だからその辺が結構いいなって思いつつも、
最終的にずっと作業自体は終わってるのに、
親に帰ってこないみたいな問題が起きたりとかしてるっていうのが、
今オープンコード使ってみての課題みたいなところあるのかなっていうふうに思ってますっていう感じですね。
オープンコードを実際使って、
クロードのサブスクリプションプランとかコーデックスのチャットGPTのサブスクリプションプランとかでログインするみたいな機能も一応あって、
クロードに関しては純正としてあって、
コーデックスはプラグインを入れるとサブスクの利用料課金みたいなので、
オープンコードを使えるよみたいな感じになってたんですけど、
コーデックスの方は非公式なので、まずどうなのかなっていうところはあるっていうのと、
あとクロードもそれで使った後にニュースで流れてて、
クロードのオープンコード経由でやってたらアカウントがバンされるっていう問題があったりするっていう。
一応そんな感じでオープンコードはいろいろ全部のサブスクで使えたらめちゃめちゃいいんやけど、
何よりコーデックスで並列開発、サブエージェント的な使い方振る舞いができるっていうのは結構でかいんだけどっていう。
あと最近GitHub Copilotのサブスクでオープンコード使えるようになったっていう。
これは公式でちゃんと提供してやったみたいなので、
今後GPTとかクロードもそれに追随するような形でオープンコードの提携してくれたらよりいいなっていう感じがするんですけど、
一応それが今のちょっと並列開発の今みたいなところかなというふうに思ってます。
Windsurfも実は1個1個ベストオブエヌ的なやつじゃないんだけど、GitWorks 3で使えるようになったので、
自分で何個も指示を与えれば並列開発的なのができるっていうような状況にはなっているので、
今後AIやっていくってなったら絶対に必要というか、並列で開発させた方が効率いいよねっていうのはそりゃそうなんで。
そこを実際に僕たちもどういうふうに使っているのかみたいなところを話しできたらなっていうふうに思ってるっていう感じです。
阿部ちゃんはどんな感じでやってるみたいなのがあったりするのかな。
僕もつい最近ようやくGitWorks 3っていうものを使い始めて、
GitWorks 3の導入と課題
これまで僕は複数のプロジェクトとかを並列で開発することが多くて、
そもそも環境を分離しようとか、Best of Nをやろうとかっていうところの動機があんまりなかったんですけど、
意図せず並列だったってことね。
そうそう、意図せず。プロジェクトがそもそも分離しているから並列化できていたっていう状態だったんだけど、
最近結構一つの大きなプロジェクトをメインで動かすことが多くなった時に、
やっぱりどうしても並列で開発することの難しさっていうところにぶち当たったっていうような状況があるんですよね。
例えばクロードコードをメインで使っていたら、さっき山ちゃんが言ってたように、
サブエージェントとかによしなにこを実装させれば、
ある程度1個の大きな開発タスクを複数のファイル編集するときに、
それをサブエージェントにそれぞれ開発させる。
なので開発のスピードが上がるみたいな使い方ができたんだけど、
僕の場合は全然違う機能を複数同時に開発進めたいなってなった時に、
結構ファイルが衝突するとか動作検証するときに、
この開発とこの開発の影響が出てるんじゃないかみたいなので、
結構検証自体に困ることが多くあったんですよ。
なので僕がやってたのはGitWorks 3をそのままシンプルに使って、
環境をまるまる分離する。
カーサーがやっているようなBest of Nの1個版みたいな感じにはなるんだけど、
開発タスクごとに完全にフォルダを環境を分離して作るっていうものを、
まずそういう仕組み作りっていうところを始めて、
あまり意識せずとも使えるようにしたっていうのが大きな取り組みになってますね。
あるいは前提としてコーデックスとかクロードコードで
そういうふうな振る舞いができるようにしたっていうこと?
そうそうそう。
コーデックスとかは特に並列開発みたいなものはできないので、
コーデックスで特に使えるようにっていうのも意識して、
そういうCLIのエージェントができるような環境を作ってあげたような感じかな。
個人的には理想論で言うと、
クロードコードのサブエージェント的な機能と、
あとカーサーの1個の指示で、
カーサーはどっちかというと1個の指示で、
複数の同じタスクだけど複数の回を出していくみたいなと思うんだけど、
結構最近、例えばバーって課題がいくつもあって、
それを一発ドンってAIに投げると、
結局複数の課題、でかすぎる課題になるんで、
一気にバコッて渡したいなとかって思っちゃうよね。
クロードとかだと、ちっちゃいタスクの集合体だと、
クロードとかだとサブエージェントでバーってやってくれるんだけど、
それにもちょっと限界があるというか、
クロードはコンテキストウィンドウが狭いとかもあって、
全部やってたらそれを全部指示出して、
回答が返ってきた時点でコンパクト走るみたいな感じになっちゃうから、
ちょっと使えないなみたいな感じはあるんだけど、
それをコーデックスで、かつ一個の指示ができたら、
それぞれのセッションが立ち上がって、
パラレルで、カーサー的な動きなんだけど、
それぞれのエージェントが違う振る舞いをやってるみたいな、
ギットワークついてみたいなとかっていうのができると、
魔法みたいな話やけど、結構便利だなとは思うけどね。
魔法で言ったら、
若干親子孫みたいな感じかもしれないけど、
いろんな開発タスクがドカンとあって、
それをまず分類して、
サブエージェントか何かに渡して、
それらは全部パラレルな環境で、
例えばコーデックスがそれぞれで独自で実装してくれて、
それぞれでプロリクエストも全部分離してできるみたいなイメージかな。
どっちかというと、指揮者がいて、
親エージェントにパラレルで、ギットワークツリーでパスして、
パラレルな環境で、
サブエージェントの呼び出し
そこからは親エージェントがサブエージェントを呼び出してゴラゴラするんだけど、
指揮者には帰ってこなくていいみたいなぐらいかな。
だからタスクをわっと全部あげたら、
それを分解して、
グルーピングして渡してほしいっていう。
そこだけでもいいかもしれない。まずはっていうところで。
最終的に帰ってこなくてもいいかなっていう気はしてるんだけど。
そうだよね。
あとCursorとかWindsurfも最近、
ベストオブエヌではないけど、
ギットワークツリーの機能が入って、
パラレルなものは作れるようになったけど、
どっちかというとオーケストレートをする側っていうのが今のところないから、
そういうのもあって、
僕自身は自分でギットワークツリーを簡単に操作できるルールっていうのを作って、
それを運用できるようにしたので、
それをもとにちょっとクロードコードとかが、
それこそオーケストレートしてコーデックスをギットワークツリー上で動かすみたいなことができたら、
一番最高になれるんじゃないかなって今のところは思ってるんだよね。
開発環境の分離
結構難しいのが、
これってギットワークツリーとか作るときに、
そんなにいろんなプロジェクトで全部使い回せるような仕組みを作るのは結構今のところ難しくて、
そうだね。
なんとなく僕はそう感じてるんだよね。
ギットワークツリー自体の仕組みっていうのは至って簡単で、
コマンドでブランチを、今まではブランチで開発ブランチを切って、
そこで開発してみたいな操作をしてたと思うんだけど、
それをワークツリーっていうのでやると、
フォルダごともブランチみたいに分離して作られるから、
そこで作業すれば完全に隔離された環境が用意されるよねっていうところは、
もちろん今までのツールで使えることだったんだけど、
分離された環境が作られたときに、
データベースをコピーして、
パラレルな環境でそれぞれ独立して動かそうとか、
あとはローカルホストっていって開発サーバーを立てようとしたときに、
そのままの設定だと、
大体ローカルホストって8000番のポートあったり3000番だったり、
みんな開発のときに決まったポートでアクセスするみたいな、
決まったURLでアクセスするみたいなのが一般的だったから、
そうなってくるとパラレルで開発サーバーを起動して、
それぞれの環境を動作検証するようすると、
URLがそもそも被っててアクセスできないみたいな、
そういう問題にぶち当たりがちだったんで、
そういうのも吉谷にワークツリーを作るとき、
環境を分離するときにポートの割り当てとか、
そういうのを全部データベースのコピーとかっていうのを、
吉谷に行ってもらう必要があって、
でもそれって結構プロジェクトごとに、
使ってるデータベースがそもそも違うとか、
ポートの割り当てもそもそもやり方が違うとかっていうのがあって、
そうなってくると、結構プロジェクトごとに独自にチューニングしたスクリプトを用意して、
Gitワークツリーの仕組みを構築するみたいな感じに今はなってるんだよね。
だから今僕らがやってるL-Shiftっていう大きめなプロジェクトも、
今回Gitワークツリーの機能と仕組みを僕の中で作ってみたけど、
やっぱりスクリプト結構書いて、
AIが一応ワークツリーを使いはするんだけど、
そのときに特に細かいことは意識せずにできるっていうところまでやったんだけど、
これをいろんな開発プロジェクトに適応しようとすると今のところはちょっと難しいし、
もちろんCursorとかWindows Arcでもやろうとすると結構手間がかかることになってるような状況なんだよね。
AI駆動開発の未来
なるほどなるほど。
一応Cursorもセッティングはできるようになってるけど、
そこまでの細かいところがどこまでできるのかっていう感じなんだよね。
確かGitワークツリーで分岐したタイミングで走らせるコマンドは確か指定できるから、
そのコマンドだけでやりきれるかどうかみたいな話なのかな、どっちかというと。
そうそうそう。大体できるはずなんだけど、
じゃあ次環境を消すときにクリーンアップする処理がちゃんと走るのかなとか、
その辺も全体としての管理をしっかりやっていくってなると、
まだ一歩及ばないのかなっていうところがあって。
ちなみに今発見したんだけどさ、
なんとCursorのドキュメントを今見ててさ、
サブエージェント機能が。
え?
話が変わった。
サブエージェント機能が来た。来てるっていうのを。
あー。
ナイトリリリースか、あれか。
アルファ版というか先行リリースで使えるようになってるのかな。
そうそうそうそう。
だから、来る気配が来てるね。
まあけど、俺が言ってる多分どっちかというとベストオブエヌの、
ベストオブエヌをセッティングできるようにしてくれたら嬉しいんやけどな。
もう完全に分離したタスクをとしてやってくれたりとかすると。
来たね。ナイトリリリースチャンネルでのみリアルできますとのことですね。
けどこれ機能安定するまでちょっと時間かかるやろうな。
なんかサブエージェントの機能が結構難しい。
オープンコードもさっき話してたようにあるけど、
全然安定しないし、コーデックスも結局その機能が。
いやいや、コーデックスも昔、初期からずっとあるツールなのにサブエージェントはずっとサポートして。
そういう意味ね。
クロードコードも初期はオープンコードみたいに戻ってこれないとか、
サブエージェントがまださらにサブエージェントを呼んでしまって、
無限ルーフみたいなのがあったから、
そういう意味ではクロードコード並みの制度でっていうのが結構難しいなって感じやね。
まあ、けどカーサーはツール作りはすごいなって思うから期待ではある。
けどカーサーってLMを呼び出すコストが良くないからさ。
16倍くらいコストかかるっていうもんね。
API経由で呼べるから、
API経由で呼ぶような形である程度精度を担保できる安いモデルを使わないと結構きついよね。
最近だとオープンコードで、GLM4.7ってやつが結構安いんよね。
中華系のモデルでかなり安くて。
それだとかなり精度も良くて、オープンコードで使いまくれるみたいな感じで、
ちょっと話題になったりとかしてきてるけど。
中華系モデル、ディープシークとか中華系モデル系でやれないと一瞬で100万とか吹き飛ぶみたいな世界観になってくるよね。
そうだね、オーケストレートしてサブエージェント使ってってなったら何並列走らせるんですかみたいな感じになるけどね。
結局俺らもさ、コーデックス使ってるだけでも毎週毎週リミットきちゃうみたいな。
けどコーデックスって正直一番サブスクの中ではコスパ良いじゃん。
ほぼ来ないって言われてたと思ってて。
ナーフされてたのか、俺らが使う量が増えたのかどっちかちょっとわかんないけど。
クロードコードなんてもう一瞬よね。正直1日とかで来るじゃん。
ちょっと大きい仕事させてたりとかすると。
だから今後このAI駆動開発で無人像に開発し続けるという意味では、
やっぱり良いモデルを見つけないといけないっていう。
モデルを見つけるのか、例えば要件定義だけはコーデックスに任せるんだけど、
作業だけはGLM4.7に任すみたいな。
阿部ちゃんはオープンコードでとか。
そういうのをするとなるとやっぱりエンジニアしかちょっときついなって感じにもなるよね、結局。
俺はやっぱりトライはしてるの。正直コーデックスのミディアムですら、5.2のミディアムですら心持たないときがあって。
だからやっぱりエクストラハイを使っちゃうんよね、基本的には。
やっぱり考えないな、こいつって思っちゃうよね。
それを一応俺は認知できてるけど、認知できるし、
細かい制御という意味では、概念的にこいつはおかしい方向に走ってるなっていう理解はできるのよ、俺は。
けど細かく指示出しをして制御するほどの具体は知らないみたいな感じの人にとっては、
ちょっとでもそれられると、いや違うんだけどなって思いながら、
けどどう具体的に指示を出せばいいのかわかんないみたいな。
違うのはわかってるみたいな状態になるから、そうするとコーデックスのエクストラハイ使うしかなくなるみたいな。
結局クロード構造も微妙じゃん。
あんまりって感じ。だから簡単そうなやつをお願いしたりするけど、正直あんまり頭は良くない気がするんで。
結局コーデックスのエクストラハイに頼りがちみたいな。
まあそうね、調査とか検討するのはもうコーデックス、僕はミディアム結構今使ってて、
たまにミスってるけど、僕は気づけるからあれってなるけど、
全くこう完全にAIに任せるとかっていうところを前提とすると、
バイブコーディング的なやつをね。
ちょっとまだそれは今どのモデルでもっても、まあエクストラハイだったら大丈夫だけど、それ以外は結構難しいみたいなのがある。
俺もあれとはなるけどさ、やっぱそこから是正するのは結構厳しくて、
そうするとあれってなるってことはさ、怖いよね個人的には。僕がわかってる範囲であれってなる。
だから僕がわかってない範囲であれってなってんじゃないかなって思っちゃって。
たぶんね、気づいてないけどね、たぶんあると思う。
まあでも今AIがね、その細かい部分をわからないけどとりあえず動くところまではやってくれるっていうのができてるけど、
たぶん知らないうちにそういうあれっていうポイントはたぶんちょっとちょっと入ってってんだろうなっていう。
例えば、今後そのサブエージェントとかいろんなモデルをこう状況に応じて使い分けてっていうようなことをするってなった時に、
僕とかだと結構最近はコーデックスとクロードコードをなんかどっちもよく使うようになったんですよ。
それはやっぱりリミットがすぐ来るから、やっぱり分散しなきゃっていう意識がより強くなって、
オーパス4.5とCodexの評価
クロードコードもちゃんと活用しようみたいな。
コーデックスにプランを立てさせて、クロードコードのオーパス4.5で並列開発をさせるじゃないですか、
結構規模が大きいと、なんかオーパス4.5でさえ相当漏れが多くて。
オーパス4.5は漏れるよね。だからコーデックスにレビューさせるとマジで穴だらけ。
そう、穴だらけで。そうなってくると、今Xとか全体を見ての評価ってオーパス4.5の評価非常に高いじゃないですか。
それでいてもなお、こんだけ漏れるって言うんだったら、もう他のモデルに任せるっていうのは本当にできるんだろうかみたいな。
けどクロードコードのオーパス4.5が俺的にイヤで評価されてる理由って、なんかあれやと思うよね。聞いてくれるとかやと思うよね。
ツールとしての成熟度。さっき言ったサブエージェントとか聞いてくれるとか、
あとバックグラウンドでスクリプトを走らせておけるとか、サブエージェントもバックグラウンドで稼働させておけるとか。
だからなんか、純粋な頭の良さで評価されてないよね、多分。
そうだよね。聞いてくれるから人間がそこで指示を与えて、精度が上がってるっていう。
精度が上がってるっていう。そうそうそうそう。だから、何だろう。指示さえ与えてたら精度は変わらんから、真の頭の良さは結局Codexみたいな。
そうなんだよね。
ちょっとレベルが違うもんね、多分。CodexとかChatGPT系のモデルと、最近ChatGPTの5.2プロ使って、
ちょっとコミュニティの話を検討してもらってて、コミュニティの話を検討した上で伝えないといけないみたいな感じだったけど、
頭が良すぎて直したもんね、逆に。
レベルくん、合わない。言ってる話がわからない。
そう、言ってる。頭が良すぎて、これ普段の俺じゃねえって思って直したもんね。
めちゃめちゃすごい、めちゃめちゃすごい、本当に。だから、Cloudに直したら、やっぱアホなんだな、こいつって思って。
ちゃんとAIなんだなって思って。
話を聞くのは上手いけど、みたいな。
推論してるだけだなって思ったよね。洞察されたなって感じ。ChatGPT 5.2プロは洞察してくれたなって感じで。
ちょっとね、頭の良さのレベルが一段違うなってことを感じて。
コーデックスよりいつも、コーデックスかクラウドコードでやっぱり全然振る舞いというか違うから、コーデックスの方が信用できるなっていうのを。
カーサーのベストオブ-Nの課題
5.2プロはね、チャットアプリから使えるやつ。あれは、ただでさえ頭の良いモデルを聴講型で、ディープリサーチぐらい聴講させて、より精度の高いものにしようっていう動きをするから。
ちょっと文脈がずれるんだけど、とはいえ、やっぱChatGPTのモデルの方が頭良いんだなっていう。
日本語上手いのはクラウドだよね。
もう間違いない。ドキュメント書かせたりとか、対人と会話するためのテキストを生成するだったら、圧倒的にクラウドなんだよね。
そんな感じで、ちょっと話はずれましたが、モデル差は結構あると。
すいません、カーサーでサブエージェントが出てるっていうビックニュースすぎて、そこから話がずれにずれ持ってたんですけど。
そうですね。並列開発いろいろできるようになってきてるけど、本当はもうちょっとね、カーサーのベストオブNはもうちょっとタスク分離して渡せるようにできるとよりいいなっていう。
もうタスクの栽培さを預けたいなっていう感覚がちょっと最近あるっていう。
あとあれだよね、なんかその、そうなった時に個人的に欲しいなって思ってるのは、その分離されたタスクの状況とかを確認できるように、
なんかどういう方針でそれぞれ進めてるんだっけっていうのが、たぶん今クラウドコードとかのサブエージェントとかも正直中身は見れないじゃないですか。
オープンコードで初めてちょうど見れるようになって、どういう動きをしてるのかなっていうのは。
なんかそれさ、思ったんやけどさ、ドットコーデックスの中にさ、あれが出てくるじゃん。リストとかログみたいなのが出てくるじゃん。
出る出る出る。
そこをさ、コーデックス立ち上げでさ、まあスラッシュコマンドなんかスキルなんかわからんけど、なんか監視させるっていうのが結構ありそうやな。
なんか今こういうタスクが動いてるみたいな、なんかID指定するのかちょっとわかんないけど。
確かに。
オブザーバーエージェントみたいなの立てるみたいなイメージで。
そうそう。ただね、俺それも最初似たようなことを考えてたんだけど、それやろうとすると、なんかモデルに割と何でしょう、固有されちゃうというか、制限されちゃう。
要はコーデックスが作業してる内容しか監視できないみたいな形になってしまうから。
けどドットクロードにもあるでしょ、ログみたいなの。カーサーにもあるよね、確か。
モデルごとに対応していかなきゃいけない。
あ、いやけどそれぞれのさ、それぞれのディレクトリを参照してもらえばいけるんじゃないかなって思ったり。
例えばコーデックスにオブザーバーエージェントの役目を与えました。で、そこの指示の中にはドットカーサー、ドットクロード、ドットコーデックス全部のログを監視するみたいな感じにするとか。
常時監視ではないけどね。
あともう一つ俺やり方あるかなと思ってたのが、ワークツリーになるっていう前提に立ったときに、
基本的にディレクトリとかファイルっていうのはどの作業中でも重複しないので、
例えばGit ignoreされたドキュメント用のフォルダとかを作っておいて、
必ずこういうルールにのっとって記載しなさいみたいな指示を与えておくことで、
今の作業っていうのがどのワークツリーでも見れるようになるっていうのは作れるかなと思ってるから、
そっちでもいいのかなと思ってた。
けどそれ、作業者にそのコンテキストを消費させるのちょっと嫌やな。
そう言うかなとはちょっと思ったけど。
コンテキスト貧乏なんで、コンテキスト貧乏なんで。
まあまあまあまあまあ、けどそっちの方向もあるよね。
けどなんかそれこそ、そのワークツリー、ログが勝手に測れるみたいな仕組みがあるところを参照する方がいいと思うな。
そいつにやらせると指示が濁るから。指示が濁るっていうのがあるから。
なんか、そうやな。ハルシネーションのリスクも上がるわけじゃん。やること多くなるから。
ただでさえぬけもりがあるっていう前提だよね。
ただでさえぬけもりもあるわ、ハルシネーションもあるわっていうリスクをちょっとでも上げるのは避けたいなっていう感覚があるかもしれない。
コミット頻度と開発効率
まあけどGitワークツリーの機能をうまく使うとありそうやんな。
そのリフを見るとかコミットログを見るとかでね、なんかうまく。
あとコミットを細かくさせてログとするとかね。
やってる人はいるよね。
あれがいいのかどうかっていうのは、コミットを細かくさせてログとするってあれやってる人っていうのはどうなんだろうね。
俺はさ、リフを見たくてさ、コミット勝手にされるの嫌だなって思っちゃう。
まあそこはまあテストなりをしっかりしてAIをそもそも実装レベルでは信頼を置くっていう前提の運用だと思うから。
例えばそれをログを積んでったときに結局どういう作業をしてたかっていうのは、
Gitログを参照して、Gitログのリスト取ってきて、さらにその詳細を見に行ってっていう操作が必要になるから。
だったら一つのファイルに出してた方がはるかに効率がいいんじゃないかなって僕は感じてるから、
あんまりコミット積み上げるのはどうなんだろうって思ってたけどね。
うんうんうんうん。
まあそう、そういうあれもあるから、なんか違うよなって感じだよな。
まあでもね、あのカーサーとか、この間実験してたAIを数百体、それこそオーケストレーションさせて。
あーカーサーのCEOのね。
そう、1週間でブラウザ作りましたって、あれ1日に最大6000コミットぐらいやってたんだっけな。
だからまさにその作業は全部コミットさせてログで積んでいくっていうような運用をきっと取っているだろうなと思って。
まあそれであそこまでオーケストレーションできてるっていうのは、一定その実用たるっていう証拠でもあるのかなと思う。
若干は思うけど。
前提あの数百体のオーケストレーションをやってるので、まあそうなるようにっていうのはちょっとありつつも。
まあそうやな。うちで何コミットとかやったっけ。
うちで。
1日100とかが、100とか200じゃないかな。
うちで100コミット。
まあプロジェクト単位で見てみるか、今。1日でどんぐらいコミットしてるか。
けど結構俺コミット頻度低いよ。正直。結構でっかい開発してても、リフで見たいような。
多分僕がコミット多め、てかまあ細かいタスクが細かかったり修正のタスクが多かったりするから。
僕がこのプロジェクトに結構ガッツリ入ってからやっぱコミット数ガッと増えてるんだよね。
12月の後半からほぼ50コミットは1日行くようになってて。
なるほどね。
それはもうデカプルリクエストをどんばんどんっていうやり方になってるからね。
1回で数万行変更しましたみたいな。
最近思ったけど、あれだなって思って。
やっぱオース周りとかコミットところは阿部ちゃんにやってもらわないといけないなって思ったから。
バイブコーディングだけでいけるっていう未来はちょっとまだ先なのかなっていう感覚ではあるよね。
それを吸収してくれるサービスがあればあれかもしれないけど。
そんなサービスあるのかな。
バーセルとかも一応そういうのをしてるじゃん。バーセルがいいのかっていうのがあるけど。
そんなサービスある?どんなの。
あれバーセルってだって認証も全部バーセル側で持ってるでしょ。
あーそういうことね。
バーセルじゃないスパベースだ。
スパベースだ。ごめんごめん。
スパベースとかみたいに認証まで丸っと引き受けてくれるから安全だよねとか考えること少なくていいよねみたいな。
一番コアな場所だけはスパベース側でやってくれてるっていう点で。
結局スパベースしか使えないみたいな話になっちゃうから選択肢が低くなるけど。
オープンコードとセキュリティの考察
一方で認証預けちゃっているがゆえにもあるかもしれないけどスパベースとかはデータベースの漏洩がバイブコーディングでめっちゃ急上昇してるみたいな話もあるからね。
そこをもうちょっとセキュアにやってくれるサービスが出てきたらさ。
てかスパベースも多分そうしようとしてるけど漏洩しちゃったっていうだけだと思う。
だけではないという話だと思うから。
まあけど素人がバイブコーディングしてゼロからオース周りをやるよりはまだ安全だったけど漏洩しちゃったっていう結論だと思う。
多分環境変数とか細かい扱いっていうところがスパベースのおよび知らぬところで起きてる問題ではあるから。
そこをVゼロとかは環境変数とかをVゼロのサービス内で今ここに入れてくれとかって言ってくるじゃん。
だからレプリットとかVゼロとかより多分より全部包括的にあったレプリットとかになるけど、
そういうサービスとか使ってる方が本当の素人みたいな人は安全なんだろうなって思うよね。
確かに。セキュアな部分はオンボーディングしてくれるっていうようなね。
そうそうレプリットだとDBから全部用意してくれてるっていう前提でしょ確か。
だからそっちの方が安全にできるっていう。
っていうのはなんか最近感じたことだなっていうのを言おうとしたけど並列開発からだいぶ外れるなって思ったんですけど言っちゃいましたって感じですね。
まぁまぁそんな感じで並列開発ちょっと引き続きね。
まぁちょっと阿部ちゃんが一旦Gitワークツリーをうまく、それこそDBのコピーからローカルホストのポート番号の勝手に変わるみたいなとかその辺整備していってくれてるから、
ちょっともうちょっとその先の部分まで行けたらまたちょっとここで報告しましょうって感じですかね。
だからオープンコードがやっぱりちゃんと動くようになったしなと思ってるけどね。
オープンコードのサブエージェントはモデルを指定できるはずだから、
カーサーもサブエージェント出てきて今ドキュメント読んでたらサブエージェントごとにモデルを指定できるとかっていうのがあるんだけど、
そこが動くと一歩先進めれるかなっていう。
まぁオープンコードも今多分2日に1回、1日に1回ペースでリリースされてるから、
だから多分ガンガン開始はされていくと思うんよね。
だからそこを広報期待って感じかな。
並列開発の進展
オープンコードをたまに使って使えるぜってなったらここで報告するようにしましょうかね。
ちなみにオープンコード使ってみようかなって思った人いると思うんですけど、
オープンコードって2つあって、
オープンコードのOとCが大文字のやつと全部小文字のやつみたいなのがあるんですけど、
全部小文字のやつが正式なオープンコードらしいんで、
お気を付けくださいっていう感じです。
オープンコード.aiっていうサービスサイトからGitHubに行けますね。
これも引っ掛け問題よね。
なんでこんなことになったんだって思うよね。
ほんとに。なんでこんなことになったんだろうって感じだね。
そんな感じで引き続き、開発に関しては、
今ほんとに少人数で開発やってるからこそやらないといけないからね。
やったほうがいいじゃなくてやらないといけないっていう僕たちの立場的には。
追いつかないからね、完全に。
っていうのがあるんで、ぜひ引き続き聞いていただけたら嬉しいなと思います。
こんな感じで普段もAI駆動開発のよもやも話をしてるんで、
ぜひ今回初めて聞いた人がいたら聞き続けてくれたら嬉しいなって思います。
じゃあ今日はこんな感じですかね。
はい。
ちゃんと撮れてます。レコーディングできてます。
ここで確認入るんだ。
じゃあ以上ですかね。
じゃあ本日もありがとうございました。
ありがとうございました。
本日もAI駆動開発部の日常をお聞きいただきありがとうございました。
いかがでしたでしょうか。
今回はAI駆動開発に切っても切り離せない並行開発についてお話しさせていただきました。
いかがでしたでしょうか。
こんな感じで基本的には撮って翌日とかその次の日とかぐらいに出してるので、
リアルな声をお届けできたらと思っております。
ぜひまた引き続き聞いていただけると嬉しいです。
もしこのポッドキャスト気に入ってくれた方は、いいねやフォロー、高評価お願いいたします。
それではまた次回もお楽しみください。
バイバイ。
