#410 仕様駆動開発の理想と現実、そして向き合い方

2025/11/23 ·

00:00
この番組はエンジニアの成長は楽しい学びからおもとに日々インプットした話題をワイワイお届けするラジオになっていますおーですはい、というので今日はですねはい使用駆動開発の理想と現実、そして向き合い方というはいすごく面白そうなはいはいはいセッションなのかなをCCSDD開発者のはいゴータさんなのかながうんうんやっている
00:27
資料があってそれがめっちゃ面白かったんですよ一番世界でやり込んでそうな人だねその肩書きまあそうですねただCCSDTというのは日本では結構使われてる気するんでなんすかそのCCSDTっていうのは使用駆動開発のライブラリの一つで代表的なので言うとキロとかGitHubのスペックキットとか有名なんですけどで
00:56
その中でキロと同じコマンドを使って使用駆動開発を進めるライブラリのOSSCCSDDっていうのがあって多分これが割と日本で人気なんじゃないかなと僕は勝手に思ってるんですけどちょっと待ってください使用駆動開発って最近できたやつですよねまあそうねAIでできてけどもうそんなことになっちゃってるんですね
01:22
世界は早いよちょっとエンジニア辞めてた間にそんなんだっちゃうやばいなんでCCSDDの作者の人がすごく中立的な立場で現状と今主力度開発の今と現実そして向き合い方っていう話をしてたんでめっちゃ面白かったですとなのでこの資料を読んだ私がこの資料の内容を薄めて
01:51
お届けするのが今回の回になってますありがとうございますお茶みたいだねお茶みたいな2番戦士ってこと?まあそうですねあとは我々の独自ノウハウでこれはこうだよねみたいな話をしながらやれると楽しいかなっていう感じですいいですねというので始めていくんですけどまず主翼導火閉じってそもそもなんじゃいというところを軽くおさらいから始めます
02:21
使用駆動開発っていうのはもともとバイブコーディングの課題を解決するために出てきたと言われてますまずバイブコーディングこれ何なのかというとこれ間違えてたら言ってって感じなんですけどAIにこれを作りたいっすって言ってそれでそのままコーディングをしていくようなものバイブスでコーディングするってことですよねバイブスっていうワードが市民権得てるのを僕びっくりしたんですけどそういうことですよねバイブスで
02:51
なんでしょうねそんな細かく見ていかないでとりあえず動くものをとりあえず一個作りたいこれってあれなんですかねバイブコーディングってそもそもプロトタイプ作るための手法だったりするんですかねいやーそんなイメージはないですねほんちゃんソフトウェアバイブコーディングで作っていこうぜってことなんか
03:12
なんとなく最初にこういうAIを主導して開発するっていうのに多分名前をつけようとした人たちがAI駆動開発っていうのをうっすら言い始めてた時に急にバイブコーディングっていうかっこいいワードが出てきてAIでやるコーディングはバイブコーディングだってやってたんだけどそれの幻滅期に入ってバイブコーディングってなんか
03:35
すげー早くできるけどあんま保守性とかそういうのとか無視されるんだよなっていう時にいや待てよこれドキュメントがあればいけるんじゃないかってなって使用駆動開発が出てきて使用駆動開発が出てきたことによって適当なコーディングイコールバイブコーディングみたいになったような印象がありますねそれはあるかもしれないですね結局バイブコーディングの課題っていうよく言われてるのが大規模コードベースになると
04:02
コンテキスト読み切れないとかナレッジ管理しきれないとかそういうのでちょっと技術的不細がめっちゃ出ちゃうよねみたいな課題感があってAWSのキロっていう主要駆動開発をするIDEなのかなが出てきたりとかして主要駆動開発がちょっと盛り上がりを見せていて
04:22
なのでその使用駆動開発っていうのはつまり何かというとAIが実行可能な明確なスペック使用を書くことで成果物を作っていくようなアプローチになってます伝わるかな今のでなんか結構ふわっとしたこと言っちゃってますけど
04:40
必要なことをちゃんと書いてそれを元にAIが開発してるってことですよねまあそうっすね広く言うとそうっすねそれをどういうやり方で文字に起こすかとかどういう流れで要件定義しよう作って開発に移っていくかそのタスク管理をしていくかみたいなのを決まった流れでやらせてくれるのがキロだったりスペックキットギターウォークスペックキットだったりCCSDDだったりっていう
05:10
ような立ち位置になってますそもそもさっきスペック使用みたいな話をしましたけどスペックとは確かにそこ曖昧かもこれもふわっとしてるんですけど結局AIがそのまま実行可能なレベルまで構造化されたドキュメント群
05:37
をスペックと指しますなんでAIが作りたいものを作るときに必要な情報これは一体何をやりたいことなのかそれはどういう風な方法で実現するのかそのどういう風な方法に関してはインフラレベルのアーキテクチャかもしれないしソフトウェアの構造レベルのアーキテクチャかもしれないし開発の流れTDDでやりますなのかBDDでやりますなのかえー
06:04
あとはなんだろうな指揮多数言語の定義とこれはこういう用語で表しますとかあとはどういう順番で仕事を進めていきますとか実装の順番タスクをこうするとかみたいなものをいろいろ含めてスペックと呼んでますこのセッションの中でこのゴータさんが理想的なスペックオレオレ6カ条って
06:36
ものを言っててこれは多分ゴータさんが思うスペックはこうあるべきだっていう話なんですけどどうやらスペックは自然言語で書かれている文書化されている構造化されている下流にわたって検証可能である下流に行くにつれてそれぞれが検証可能である正しいかを検証することができるようなものであるスペックは人とAI両方のSSOTであるこのSSOTっていうのはシングルソースオブトゥルース信頼できる唯一の情報源うん
07:07
勉強だったと思いましたである最後スペックは実装のフィードバックを通じてどんどん変化するドキュメントを陳腐化させないこれが理想的なスペックオレオレ六箇条まあわかるって感じですねただね僕これやってるんですけどこのオレオレ六箇条守るのもむずいこの辺の話も最後になんのかな後半の現実っていうところにもあるんですけどね一旦理想の話をしていきますさっき言ったようにその
07:37
スペックってAIがそのまま機能開発可能なレベルで自然言語で構造化されているっていうものになってくるのですっごくいろいろ書かなきゃいけないんですよさっき言った通りね具体例なんかちょっと適当なアプリで説明していきたいな料理レシピ記憶アプリ料理レシピ記憶アプリ記録でもなく記録
08:06
記憶アプリ記憶アプリフラッシュカードでメニュー出てきてそうね覚える裏に材料書いてるそうしますそうします英単語覚えるみたいなノリでねやっぱね現場ではいちいち開いてらんないですからそうだねやっぱ火加減変わっちゃうからね変わっちゃうからちょっと待ってるだけで余熱で火が入りすぎたりとかするからねやっぱ覚えるの大事なの大事だね料理レシピ記憶アプリだとしてはいじゃあその
08:35
フラッシュカードみたいに覚えるっていう機能を作ろうってなった時にまずホワイを整理しますなぜなんでそんなことが必要なんだとさっき言ったように料理は覚えないと火加減とか火入っちゃうとかリアルタイム性が非常に求められるだから覚える必要がある人間の記憶に定着するような機能だったり作りである必要があるとあとはスコープ
09:07
ここからここまでやるけどここからここまではやらないみたいな今回だったらどういうことだフラッシュのアニメーションは一旦いいですなのかもしれないし一旦20枚までにしましょうあーとかねなるほどあともうすでにレシピ自体は保存されてるからそこの処理はやらなくていいよとかもそうなのかあーそうですねみたいなそういうふわっとした要件みたいなところをまず定義しますでその後にじゃあ一体何を作るんでしょうフォアットの部分を整理します
09:39
例えば今の状態だとAIは覚えたいらしいなとこれはやらなくていいんだっていうことしか与えられてないんでそれをやるために何をするのかユースケースユーザーストーリーだったり画面遷移とかこういうエッジケースありますよねとか非機能要件とか結構漏れなく出す感じじゃないですか結構漏れなく出す感じですね書かないとやってくれないんで
10:09
意外とエラーハンドリングとかやってくれない?エラーハンドリング勝手にやってくれるのはあります勝手にやってくれたものを正直完全に漏れなく出すのは厳しいこともあるんでそれは後でフィードバックできるようになってるのが使用駆動開発のなるほどねそのドキュメントにあるからこうじゃんってことが言えるという状況にするって感じか一旦そうですねもし後から変えたかったらねコード変えて仕様変えてやっていく
10:38
ようなものになってます手元に減らすために出せるだけ出すのが一応理想ですねなんでさっきのフラッシュカードでいうとログインした後に学習みたいなページ行ったら始まりますとか
10:56
ここの料理のデータはどうしようかなダイナモかなんかに入ってますなのかでそのデータはAPIが裏側であって問題一気に取ってきますなのかもしれないしで性能としてはボタンを押してから何秒以内に問題が表示されて何秒以内に答えが出ることみたいなのが書かれるのがないで最後How to verifyっていうどうやったら
11:30
検証の条件って言うんですか何をしたら終わりと言っていいか完了の定義とかテスト観点とかそれぞれタスクごとにタスクを分けた後にそれぞれ何ができてるよいかみたいなところを作っていく大変だ別にAIとか関係なく普通に理想だよね普通に理想っすね
11:59
普通にリソーっていうのがさっきタスクまで行ったんですけどタスクまで行ったら次この番号のタスク実装してくださいって実装してHow to Verifyの条件にのっとった形でそれができるまで実装してくれて終わったらコードが出来上がってレビューとかいろいろやってフィードバックしてまた実装に戻るかもしれないし実装が終わったらまた次のスペック作りに移る
12:30
っていうのが使用駆動開発SDDの理想的な機能の追加フローになりますなのでなんて言うんでしょうねLLMっていろいろやり取りをするとなんかちょっとなんでしょうね忘れちゃったりとかちょっと違うことやっちゃったりとかしますけどそういう不確実性を下げるためにいろんなものをドキュメント化してそれをちゃんと読ませて言ったことをちゃんとやらせるっていうのが使用駆動開発のアプローチになってます
12:59
ですが現実そんなうまくいってないということをこの作者の方は言ってますわかるー
13:12
結構細かくトゥードゥとかまで作るんですけどトゥードゥ全部終わってチェック全部ついたねみたいな42トゥードゥみたいなやつチェックリストでできて全部チェックついてるよしって実際に動かしてテストしたら余裕でページないとかめっちゃあるマジっすかそうなんだ
13:32
あーそれもあんのかなんかページ内までは行かないけどなんだろうなぁこれ言ってなかったかこうなっちゃうのみたいななんかある意味マジ api はあるんだけどフロントできてねーじゃんみたいなええええええまあでもなんか一気に頼む強いこともあるかもしれないですね一気に頼みすぎてるのかなそれでもなんかアレですよ日曜使用駆動開発のなんかのツール使ってるわけではないないあの前
13:58
マイスペックドリブンってことですねそれだったらそういうことあるかもしれないですねなんか主に最近カーソルのプラン機能を使ってるな結構それとも全然違うんですよね僕カーソル使ったことなくてクラウドコードのプランとかギター部のプランモードを使うことが多いんですけどそれらとも全然違いますねへー
14:23
それらのプランとも全然違いますそうなんだどんな差分があるんですかさっき言ったようにめっちゃ色々定義してなおかつ忘れないようにマークダウンで管理されてタスクやる時って一個ずつちっちゃいタスクやるじゃないですかそのちっちゃいタスクやる時にちゃんと該当箇所を読んでからやってくれるんであんまり忘れないでやってくれるっていうんですかタスクをいっぱい積み上げた時に全体として最初にやりたかったこと全部やってるよねみたいなのをおさらいしながらやってくれるんであんまり
14:53
それはCCSDDの動きって最初にプランをガーンって作ってるイメージだったんだけどその後のエージェントの動きもコントロールしてるの?エージェントの動きはコントロールしてないんです知ってるのかな?知ってるんですけど仕様を作るのはチャットの上じゃなくてマークダウンでドキュメントが作られますと全てがタスクもだし要件もいろいろ全部他のやつって違うの?
15:23
他のやつプランモードプランモードクロードコードのプランモードはあんまりマークダウンに作ったりしないですねそうなんだギター部もやんないですねそうなんだカーソルは割とマークダウンにやってくれるんですねカーソルはねマークダウンで作ってるねそうなんだそこはじゃあ違いますね動きがはいで
15:41
多分キロのコマンドで多分ここ見に行ってが決まってると思うタスク実装する時とかそのキロのコマンドがなんかちょっとよしなにやってくれてるのかなとは思ったりしますけど正直同じことをやって比較したわけじゃないから同じことが起きるかもしれないですそののりさんが言ってるフロントエンドの話とかもねただあんまりまだ経験ないですねそんな複雑なことやってないですけどまあっていうので現実がいろいろありますとで
16:13
いろいろ仕様を作って実装していくじゃないですかリアルに想像してほしいんですけどガーってドキュメントができてよっしゃ作ったできたってなった時によっしゃちゃんとできてるねどうやって確認するんでしょうというのが非常に難しいそのToDoはできてるけどそのToDo通りに本当に実装されたのかっていうのをチェックが難しいってこと?
16:38
だしいざできたものが本当に頭に思い描いたものを確認するためには人力でドキュメントちゃんと読んで人力でコードちゃんと読んで人力で動作確認して人力で判断するしかないんですよそうだねそれってなんか職人技確かに検証可能性が高いとは言えないぶっちゃけ人間がやっても一緒なんですけどただ人間ができたっていうのが難しいうん
17:09
なので本当はAIが作るからコードレビューもそんなにやらなくていいよねとか省力化できるのが超理想なんですけどそうではないとコードもだし機能もどっちもそうだな実装も複雑だと実装漏れとかするし人間気づけないしテストコードも同じくさっき言ったように理想的なスペック俺より六箇所の中に
17:40
下流にわたって検証可能であるとかってあったんですけどなかなかそうはなってないというのが現状になってますとただなんかこれ思うのが僕は趣味でやってるんですけど視力高いです朝起きて子供が起きるまでの30分と昼休み飯食って昼休み終わるまでの20分くらいと夜子供が寝てからの1時間未満くらいすげえこれって
18:16
深く読めないんですよ何もまあ確かになんでレビューだいぶ諦めてますとだいぶ諦めてるんですけど実務でやるときってまあ時間取れると思うんでそこはなんかちょっとやってる感じひょっとしたら違うのかなどうなんだろうって思いながらやってますなるほどねどうなんでしょうねいやちょっと
18:35
多分そもそもスペックSSスペックドリブンSDDの方法でやってるかどうか微妙なんであれなんですけど僕その最初の仕様チャットGPTじゃないやつでやってるんですよつまりジェミニでやってるんですよその時に個人的にレビュー楽だなってめっちゃ感じててっていうのもスペック作る時に
19:03
最初から会話でずっとやってるというか次こういう機能を開発したいみたいなっていうので会話の中で作っていって最終的に決まったやつをカーソル用の指示書にしてくださいカーソル用の指示書にしてその後それをカーソルにマークダウンとして保存した後にそれを読み込ませて現在のコードと一致してるかどうかチェックさせて最終的にそのプランでトゥードゥ作るみたいなのをやってるんですよ
19:27
会話の中でやってるからめちゃめちゃレビューしやすいというかそういうのもあるんだよな僕も一回仕事で無理矢理使ったことがあってその時は仕様を結構気をつけて作ったんでそこはそんなに仕様のレビューはそんなにまだなかったなと思っててまだ開発は開発部分だけ他の人にやってもらってるんですけど今
20:01
やっぱり他の人に電波させるには他の人に無理矢理触ってもらうしかないと思って入り口だけちょっとやってツールの説明してこれ使ってみてくださいって軽いタスクでお願いしてるんですけど本当は最初から最後までやらせた方が良かったかもって思いながらなるほどね仕事でやってみたらさりごと違うのかもしれないなと思いながら早くやってみたいですけどコードレベルしんどいって言いますよね
20:31
ちなみに仕事で使えないのはルール的な制約があるんですかそれともプロジェクト的にデカすぎてできないみたいな感じなんですかまずそもそもこれがいいのかよく分かってないのと何だろうな何個かありますでも結局ドキュメントが今ジラコンフレンスにまとめるっていうルールでチームであるんでなおかつそこのチームに僕が今入りきれてないんで外から急に入ってきてルールを変えるのは数字が違うなと思ってやってないって感じですなるほどね
21:04
うんうんこんな感じかななるほど今一人プロジェクト中なんでほぼあそうなの?はい社外の会社の人と俺一人みたいなノリさん状態ですね俺は完全一人だからそうあんまりね社外の開発のやり方とか口出さないしね出さない方がいいしね難しいのがありながらただなんかその
21:32
ちょっと巻き込む機会があるときにスッて今差し込みましたCCSDD実験ですけどっていうのを置いといてあとはですねフィードバックループのところがちょっと難しいって話があってCCSDDってさっき言ったようにスペック作って実装してよしたらできたで次また別のスペック作ってでやっていくというのがあるんですけどはい
22:04
現状このスペックって割と独立してできるんですよ何て言うんでしょう1個スペック作りましたで別のスペック作ろうってなると別のファイルでできるんで全体を管理するドキュメントを作る仕組みがまだないんですよね自分で作る必要がありますだから自分でって言ってもAIにやってもらえばいいんですけど
22:27
全体むずいよね受け漏れ起きんだよねめっちゃそこの整理のやり方とかっていうのがまだちょっとうまいことできてないしでもそれはねキロなのかどっかが一個作れば進む話なのかもしれないですけど現状ない本当の理想はすっごい高速でこのサイクルをガーって回してなおかつ複雑性をある程度管理した状態でいいコードといいドキュメントができるみたいな理想なんですけどなかなか
22:58
いやいやムズーって感じですねというのでそんな現実がありつつそこに立ち向かう動きもややありますと戦士たち?戦士?戦士なのかなテストとかメトリクス検証でテストが合ってるかとかそのテストによって機能が合ってることをちゃんと証明できてるのかみたいな検証が難しいみたいな話があったんですけど
23:25
11月18日のアップデートで3日前?4日前キロがプロパティベーストテストプロパティベーストテスト聞いたことあるぞそれさすがだなもともとあるがいねえんじゃねえんそれっていうのをテストするように機能が入りました僕はあんまりやったことなかったんですけどプロパティベーストテストっていうのは従来のテストと違いますと
23:56
従来のテストって入力と出力をそれぞれ一つずつ定義してそれを合ってるかみたいなのを検証するのが卒業テストでしたとプロパティベースドテストって常に成り立つべき一般則を定義するらしいですとこれがねめっちゃ分かりづらいんですよね例えばですよADDっていう関数あるとするじゃないですか足し算するね引数が2個入るやつねADD関数って引数入れ替えても出力値一緒じゃないですかうんうん
24:26
じゃあアド関数2つ並べて引数2つ入れ替えて合ってればまず足し算として入れ替えても中は大丈夫な作りになってるねが検証できるわけじゃないですか掛け算してるかもしれないですよだからそれはまた別のシナリオでやる必要があるとかあとリバース関数だったらリバース関数って文字を入れ替えるストリングを入れ替える関数があったとしたらリバース2回やったら元に戻るよねとかそれもね最初から入れ替えてない可能性もあるんですけど
24:57
そういうずっと成り立つ一般則を頑張って思いついてそれで数百パターンを数行で数百パターンを数行のテストでやってもらうっていう考え方がプロパティベーステストらしいですテストしきれてるのかそれ本当にっていう不安がすごいなまあでもなんか何でしょうねいろんなパターンの入力値でバグを
25:23
見つけるって言うんですかっていうことは普通のテストよりはやれてるんじゃないかな境界値のテストの考え方ありますけどあれも人間が結局ここ境界値一緒ってやってるだけなのでっていうのがすごい非常にもともとスペックドリブンデベロップメントで要件作る時にイヤーズ記法っていうのが使われてこういう時にこういう振る舞いをしたらこうなるみたいな要件の記法があるんですけどそれと相性いいらしくてテストケースを作る時に
25:53
それでやるっていうのがあるみたいですちょっとよくわかんないんでこれは別のエピソードにしようと思いますそうしようっていうなんかその本当のスペックドリブンレベロップメントではなんか仕様をAIと一緒に考えて抜け物ない感じにして実装作ってやってでちゃんとその下流に当たって検証可能性があってでその機能開発が終わったら次の開発に移っていい感じのドキュメントでいい感じのことができるぜっていう理想がありつつ実際レビュー超大変だよねとかえー
26:22
下流からのフィードバックもちょっとコツいるよねとかフィードバックループ回していくとどんどんなんかスペックとかも複雑になっていくよねとかテストとかもレビューむずいよねみたいな色々なのがありますというところまでいきましたで向き合い方どうしようというところで一旦このセッションではこのゴータさん言ってるのが一つCICDを整えようというのと二つシステム全体を複雑性を抑えたモジュール性の高い設計にしようということを言ってますそりゃそうだ
26:56
本当にこれってAIじゃなくて人間の設計力にかかってるんで劇ムズなんですけどそうなのよCICDは割とサクってて本当にマジですごい楽確かに超楽もしこういうAIエージェントで開発するんだったらそういうのやっていこうっていうところとうん
27:20
現状のSDDツールで適しているユースケース適していないユースケース適しているものとしては明確な境界が引きやすい構造になっていたり仕様が変わりにくいようなところが割と良いとされていると一方で未知の未知本当に先端技術がどうのとかだったり小規模タスクは向いていないですと
27:52
オーバーエンジニアリング的な感じそうですねバイブコーディングでもできるみたいな話なのかもしれないですね余計時間かかっちゃうということかそうそうそうというような感じもっとねいろいろディープな話があったんですけどちょっと時間もあれなんでざっくりこんな感じの話をしてましたというところでなるほど僕この話を読んでて思ったのがなんでしょうね結局この
28:16
今後この現実に対して各社がどういう各ツールがどういうアプローチを取っていくかっていうところだったりあと人間が見るしかない設計とかテスト品質なのかなあと設計って言っても要件定義と仕様のところもだしソフトウェアの設計もそうだしテストのところとレビュー化のところをうまくやる必要はどうせどこまでいってもありそうな気がしていて
28:45
人間としてはそこを学んでこうだしチームとしても多分シニアエンジニアが一人いるようなチームに相性いいんだろうなとか思いますねシニア?テクリードみたいな感じだね導ける人がいないと逆にそうじゃないと割と地雷だと思います変な方に導いていっちゃうねっていう後から直せるっちゃ直せるのかもしれないですけどなんかどうなんだろう苦戦結構辛いと思うんで
29:14
自動テストがあったとしてもそのテストそもそもあってんのかわかんないからね確かにねというとこは非常に注意が必要だなということを思っておりますうんうんなんでやっぱり結構チームに入れるのね僕はハードルあるんですよねこれなんかレビュー負荷高い
29:34
のは本当にそうだなと思うし前の順平いなかったAIDLCの回でも言いましたけどペア作業でやっていくんだったらいいんじゃないとは思うあとはドキュメントの整理をどうするかぐらいですねドキュメントねGitHubにタスクとか残るんでタスクが残るのが果たして適切なのかもよく分からないし
29:58
残してもいいのか別にコードベースでかくなっても気にならないのかななんかイメージなんですけど従来の設計書って例えばコンフレンスとかGitHubのウィキとかそういうのにまとまるリュードってアプリケーションが一つドーンって親ページであってその下に大機能ごとにまとまるじゃないですか
30:22
ただこのスペック使用駆動開発でやると割とその大機能のさらに小さい機能ごとにドキュメントがポコポコできるんで複数ファイルになるんだなりますねなるというか一気に作ったら一個になるんですけど後から機能追加した時に既存ドキュメントに追記とかしないんで多分そういうことかなんで何も考えないでやると本当に流度の揃わないドキュメントのページがいっぱいある状態になると思うんですねはい
30:52
そこをどう整理しながらやっていくとかいっぱい複雑になった時にAIがちゃんと読めるようにどう整理していくかチームとして理解し続けられるようにどう整理していくかあとは知らないところで大量の情報が出てきた時にコードリーブもしない他の人のタスクっていうんですか時にそのドキュメントに対してどう立ち向かうかLLM使いながら読み取ればどうにかなるのかもしれないですけど
31:22
でもそもそも質問をするための事前知識もいりますからね確かにそこも結構難しいなとか思ってはいますがでもどうにかするやり方は出てくるんでしょうから自分がそれを見つけられるようになるといいなって感じですなるほどねちょっとアフタートークいいですかはい今更なんですけど
31:47
GitHubコパイロットを仕事で使っててGitHubコパイロットって他のAIエージェントのツールと違ってリクエスト数でキャップがあるんですよトークン数じゃなくてそうなんですよなので他にも何かあったなキロとかもそうなんですけどなので対話的に進めていくよりはガチガチに作ったやつ1個ボンって投げるっていうのが多分
32:16
節約術としては正しそうなんですよそうだねなので会社でジェミニを使えるんでジェミニを使いながらコパイロットに投げてとかっていうのをやってるわけなんですけどのりさんもそのスタイルじゃないですかそのスタイルで仕事をしてるのが一方あってもう一方はクロードコードを今使って趣味開発やってクロードコードの今勇気を出してMAXでやってるんですけど
32:44
マックスって100ドル?そう有給出してクロードコードだとJmini GitHubコパイロットと違って全部一緒にやって大丈夫なんですがやっぱり全部一緒にやった方が楽というか安心感があるなと思っててJminiもねリポジトリ読めれればいいんですけど会社で使ってるGitHubだと読み込ませれないとかあるんでクラウド版使ってないとかはいはい
33:13
っていうのでやや使いづらいなとかっていうのはあったりするんですけどコンテキスト渡すときののりさんの工夫とかってなんかあります?なんて言うんでしょうねジェミニと一緒に考えてプロンプト作ってもらうと思うんですけどジェミニと一緒に考えたことって全部渡してるわけじゃないじゃないですかある程度情報を落としてカーソルに渡してると思うんですけどその辺抜け落ちないようにするような工夫ってなんかやってます?とりあえず投げてから成果物をジェミニに渡してジェミニにチェックさせることでカバーしてるみたいなイメージですか?
33:43
えっとねジェミニーには逆にあの今ソースコード渡してないですパンクしますああコンテキストははいパンクするとすぐバグるそうなんだなんかねあの同じだろ3個前の質問の回答とか返してきたりするようになるんで言ってましたね前ももしかしたら今週ジェミニー3になって確かに治ってる可能性もあるんですけど
34:08
ソースコードを食わすと一撃でではないから2機能くらい作ったらもうそれになると思う基本的にはGoogleドキュメントに最新の全体像を書き連ねていってるずっとそれを最新にしていってるなるほどドキュメント読ませてるんですねジェムでそのドキュメントを
34:30
ラグ的な感じで使って出力形式とかも全部そのジェムの中で指定するようにしてそのジェムを使って開発し使用を作るとでも一方それでやると現状のコードとかに合わない場所出てくるんだよねモデル名違うとかテーブル名違うとかっていうのは
34:54
逆にカーソルのプランの時に現状の行動と違う箇所があったらそこは分かるようにしてプラン作っていってくださいみたいなそのプラン見ていけるって言ったらやるみたいななるほどファイラットそこまでやってくれるのかなあとデータベースの情報を読ませるならスキーマダンプがいいかもしれないダンプしてその文を出すってことですかスキーマだけダンプしてデータ入れずにクリエイトテーブルの文章だけバーって出てるから
35:29
それを読み込ませるとテーブルの情報をちゃんと理解してくれる可能性高いなと思ってるテキストでジェミニーに渡すってことですかそうそうカーソルからGoogleドキュメントの更新とかはやるんですかやんないですかやんないできんのかもわかんないですけどGoogleドキュメントは常にそのジェムで最後を
35:56
そろそろ更新時変わってきたらじゃあこれまで実装したやつをドキュメントに追記してくださいつって新しいドキュメントパーって出させてジムの裏側のあれ切り替えるっていうのをやってますねなるほどなんか結構その今の話僕が良かったなと思ったのがAIエージェントそのVSコードとかについてるコパイロットとかの良いことってコンテキストを引き継げるんですよファイルを通じてで
36:24
クロードとかチャットGPDとかのアプリとかはファイル割とローカルネス読んでくれたりしますけど地味にブラウザだから不便だなと思ってたんですけどGoogleドキュメントでやればいいですねGoogleドキュメントでやってるねそしたらそのドキュメントがドキュメントになるそうですよねなるほどいいこと聞いたそれはちょっとめんどいけどねあれでもバグるよりはいいかバグるよりはいいんじゃないですか本当ならそのドキュメントをリポジトリに上げた上で
36:55
リポジトリごと上げてしまいたいまあねでもGoogleドキュメントはそういかないですからねファイナリーデータですからねどうなんだろう全然マークダウン形式に変換してもらえばできるのか今はできるんだけどちなみにバグる問題があるからそうですねありがとうございます
37:18
ハッシュタグひまじんプログラマーでSNSネックスでフィードバック募集してますので本日のエピソードの感想とかありましたらぜひお願いします最近AIが早すぎてついていけないんですよね早いっていうのは処理がそれとも進化が進化がどんどんどんどんポコポコポコポコツールが出てきてなんか年末昇仙館ありますよね今あれって
37:39
半暴起なのか今じゃあそうなんじゃないだってねオープンAIが5.1出して10.3出して今多分クロードが腕ぶん回してるでしょうからあー確かにねドンキーコングだ多分ね溜めてる今なるほどねステージの端っこの方でそうそういうやついたら速攻ぶっ倒しに行くぶっ倒しに行くためのコーデックスマックスとかクロード3なんじゃないですかなるほどねクロードじゃないやジミニかフットブカはクロード次第
38:10
とりあえずそのスペックドリブン一回やってみたいなやったほうがいいです簡単簡単簡単広めたい広めたいんですよ僕はこれをそれをやるならキロが何がおすすめですかCCSDDですキロは無料でも使えるんですけど僕は触ったことないですっていう前提なんですけど
38:30
無料だとリクエスト数が限られてるんで月50回だったかな忘れちゃったんですけどどう考えても足りんやろって個人的には思うんでCCSD OSSであとキロって日本語対応してないんで日本人が作ってるんでCCSDはファインディーの方らしいんですけどファインディーの人なんだCCSD日本語対応してるしOSSだしお金かかんないんでAIエージェントにはかかりますけどCCSDTおすすめ個人的には今
39:04
会社でも入れやすいと思いますよそうなんだライブラリなんで承認とかいらないですサーズじゃないんでキロもいらないと思うんですけどキロはお金かかるんで決済とかキロの方が優秀かもしれないですけどね今言ったようなプルパティベーステスティングとかが去ったりするんでCCSEはこの後追従するって言ってました頑張れコータさん頑張ってって感じやってほしい超簡単にできる分かりましたやろう
39:42
何の話してましたっけXかあとはポッドキャストのエピソードの説明欄からGoogleフォームで番組への要望・感想・質問何でもお待ちしてますチャンネルの説明欄からスラックオンラインコミュニティひまプロ談話室の参加フォームもありますのでそちらもお願いいたしますアドベントカレンダーやるみたいなイベントもありますしね順平書かないの?順平書かないの?言っちゃいますか言っちゃおうぜ
40:11
すごくないですかアドベントカレンダーやろうっていう声が上がるのもすごいしやってくれるのもすごいしこんなに枠埋まってるのもすごい今最近の枠見てないわ今残り8とかじゃないですか意味わかんないすごすぎ8いくんすか会社のやつもあるんでマジか今から考えようそれだなこういうのもね
40:45
割と書くこと作ってからやるんじゃなくてやってから書くこと考えるんで9割5分そうだと思うアドベントカレンダー特に最初からタイトル決めて枠埋めてる人あんまり見たことない大体そうだよねなんか書くってみんな書いてるこれを聞いてるコミュニティの方もしくはコミュニティ入ってない方ぜひひまプロ談話室のアドベントカレンダー書くのもいいですし
41:15
書かなくても見てください12月1日から出るのかな枠埋まってればですけどねお楽しみにテーマはなんだっけあの頃の駆け出しだった丸々の駆け出しだったあの頃へのメッセージみたいな丸々の駆け出しだったあの頃のへのメッセージっていうあれですね過去の自分への手紙みたいな系の記事になる予定ですねいいテーマ設定だ本当に
41:50
最後に各種ポッドキャストプラットフォームのフォロー高評価お願いしますそれではまた次回バイバイ正直者のエンジニアは不可分散ができるようになりました
42:22
それを見ていた欲張りの男がサーバーを落としましたあなたが落としたのはこの金のサーバーですか?へい、その金のサーバーを落としましたどうやらあなたは嘘つきのようですそう言って女神は帰っていきました欲張りの男は復旧できないサーバーの前でわんわん泣いていました
42:53
サーバーを落としたくないあなたへひまじんプログラマーの週末エンジニアリングレッスン

0:00 43:02