AI自律駆動の課題
こんにちは、AI駆動開発部の日常へようこそ。このポッドキャストは、日々AI駆動開発を行う企業家の山本と、エンジニアの阿部が、AI駆動開発のリアルを緩く語り合う番組です。
はい、じゃあ本日もよろしくお願いします。よろしくお願いします。じゃあ今日はなんか、阿部さんのほっぺ、悩みがあるんですか?
悩み、まあ悩みと言えば悩みだね。お悩み相談ということで。
壮大な悩みがあるということで。はい。
いきなりハードルを上げていきますけど。
まああの、ちょっと僕最近、まあ開発している中で、その、何でしょう。結構気になっていることがある。まあ一つのテーマみたいな形になっているのがあって。
はい。
なんかその、AIにロングランさせる。作業を長時間自律的に動いてもらうにはどうすればいいのかなっていうのをすごい悩んでいます。
うんうんうん。
で、なんかね、僕がやってて普段思うのは、やっぱりなんかコーデックスもクロードコードも、まあ10分とか長くても20分ぐらいの作業で、まあ一旦停止するんですよ。
なるほど。
で、まあ長いっちゃ長いんだけど、なんかまあ僕の場合は基本的に調査のタスクだったり、まあ細かい回収とかをするので、まあそんなに長くなりにくいのかなとは思いつつ、なんかもっと自律的にこう自分で問題を特定して、その解決策に対してこうフィードバック回したり、
あとはそれに合わせて実装とか、まあデリレーションといって直したことによってバグがさらに起きないかっていうチェックとかを自律的にやってくれるようになれば、まあその10分とか20分の壁ってもっと越えて、長く動いてくれるようになるんじゃないかなっていうふうに思ってます。
はいはいはいはい。
まあなんか長くなることが全てってわけでもないような気がするんだけど。
はいはい。まあもうちょっとやってくれ、欲しいことがあるってことだよね。
そうそうそうそう。
まあ時間で話しちゃったけど、まあどっちかというと、もうちょっとやってくれるはずというか、まあ欲しいんだけど早く終わっちゃうみたいな感覚があると。
あ、そうなの?
まあ10分20分って言ってるけど、まあそれが10分20分でもその阿部ちゃんがやって欲しいところまで、まあやってくれてるんだったら満足してるはずで、まあ何かしら満足できてない原因があるみたいな感じなのかな。
CodexとClaudeCodeの活用法
確かにそうだね。あのー、それで言うと確かに時間というよりかは、なんかここで止まらなくてもよかったんじゃないっていうタイミングでやっぱり止まっちゃったりする。
ちなみに俺は全くなくて。
なんかね、見ててそんな印象を勝手に受けてる。
うん、まあ3時間とか。
そんなに動く?
動く。
マジで?
まあ俺寝る前に回したりすると、あのーそうだね、たまにまあ見ながら、様子見ながらみたいな感じで、2,3時間とか普通に動くよ。
そうなんだ。いやなんか、でなんかその長く動かせるようになるっていうことはいろいろメリットあるなって思ってるんですよ。
なんか、クロードとかは30時間でコーデックスは7時間自立駆動しますみたいな。
コンテキストウィンドウ食いつぶさないの?みたいな。
そうそう、だから結局俺の場合は時間でというよりはコンテキストウィンドウの問題で、コンテキストウィンドウが圧迫し始めたら、俺の方でキリの良いところで止めるみたいな感じだから。
止めるんだ。
だからどっちかというと、なんだろう、これクロードコード使ってるかコーデックス使ってるかにもよって、
クロードコード使ってる場合はできるだけサブエージェントに渡すっていう、あくまでも親エージェントはオーケストラでいうところの指揮者をになってもらうっていうのをちゃんと指示出しする
みたいなことを絶対するようにしてて、それでコンテキストウィンドウの問題はできるだけ排除していきたいなっていうのが俺にはあって、
コーデックスはあるけど一方で、その辺がサブエージェントの機能とかないからさ。
そうだよね。
だから結局俺の場合は時間の問題というよりはコンテキストウィンドウの問題なのかなーみたいな感じかもしれない。
確かに。
うん。
だから長時間動かせるようになるっていうことはそのコンテキストをうまく使いこなせるっていうことにも直結するから、
なんかもうちょっとこの辺、どういう工夫してるのか、まあ今もちょっと軽く教えてもらったけど、聞けたら嬉しいなーっていうふうに思ってました。
だからか、なんかアベちゃん、コーディングしてる、俺よりコーディングしてるじゃん。
たぶんね、そうだね。
その割に、なんかこのLLMにコーディングさせるっていうことに対しての努力が足りないなって思ってた。
努力が足りない。
努力っていうか試行錯誤が足りないなって思ってたけど、
俺はね、基本的にコンテキストウィンドウとかが圧迫されるから、なんか明確に弊害があるけど、
アベちゃんの今のその10分、20分で終わっちゃうんだよねとか、
途中でまあ、いやここで聞くなよみたいなところで聞いて1回ストップされるとかみたいなのがあると、
コンテキストウィンドウの問題とかってあんま起きないのかもね、そのワンショットでっていう意味で。
あの、クロードは結構その調査のフェーズが、まあコーディックスもそうなんだけど、調査のフェーズが長かったりすると、
コンテキストウィンドウの問題が出るんだけど、じゃあ問題解決して新しいセッションで、なんか実装し直してもらえますとか、
タスク管理の工夫
いうタイミングにおいては、基本的にクロードコードとかだと、まあ60%残ってる。
コンテ、コーディックスとかも80%とか残ってる。
そんな感じなんだ。
結構残るんよ。
なんか俺あれを、1個の計画、まあ俺の場合は今01の開発してるからっていうのはあるけど、
基本的に1個のタスクをすべて完遂することは、タスクっていうのはすごい大きい開発のタスクを完遂することはコンテキストウィンドウの問題でできないんよ。
だからワンステップやってもらったらほぼ20%ぐらいになってて、
だからそれを1回エスケープ2回押してさ、過去のヒストリーに戻って、でステップ1をやった手で、
他の作業者にステップ1をやってもらいました。だからステップ2から始めてくださいみたいな感じで、
事前のインプットはワンショットでまず計画書の一番初めで操作させて、ある程度コンテキストを与えてるって状態まで持っていって、そこでレディーの状態にしとく。
でステップをこう踏んで進めていって、ステップがある程度完了、例えば3ステップまでコンテキストウィンドウの問題とかにぶち当たらず終わりました。
でここで次やったらリセット入るなって思ったらそこで止めるんよ。でエスケープ2回押してステップ3まで他の作業者にやってもらってるから、
それをまずチェックしてもらって問題ないかどうかチェックしてもらいます。問題ないことを確認できたらもう1回エスケープ2回押して戻る。
そのレディーの状態に戻る。でレディーの状態から3のところまでは完全に実装済みなので4から進めてくださいみたいな感じでお願いすると、
基本的にはその一番初めの計画を認知するっていうところはレディーの前に。
スタンバイのフェーズを1個設けてて。 一番最初にだから今回のその計画とかどういうことやるのかってもうもちろん最初にやるんだけど
緻密に結構インプットしておいて、でステップが1から5とかあるときに1ステップ終わったらあれかセッションを履歴で戻って
また何でしょう何でしょう開始のところからやり直す。で他の人がやったてにして混乱させないようにして
でそうする。でちなみに設計フェーズは完全に切り分かれてて、設計書を作るっていうのは全く別のセッションでやってて
でそれで1回フルフラットな状態で。 設計をするために無駄にコンテキストがいっぱい溜まるはずなんで
設計書が完全に出来上がったら2、3回ぐらい他のモデルたちにレビューしてもらうじゃん。 である程度これだよねっていう風になったタイミングで
全く新しいセッションを立ち上げて、まず理解してくれとっていうフェーズを挟んでそこでオンレディの状態で今のステップ
さっき言ったステップが始まるみたいな。 なるほど理解してねっていうところも含めてのオンレディにその最初の認識するっていうステップ挟んでるんだ。
そうそうそうそう。 確かになそれはね僕もなんか似たようなことはやってるけどそこまで明示にできてなかった気がする。
でちなみにクロードコードを使う場合はあのタスクの依存関係とか結構大事なんで なぜならサブエージェントで4並列とか8並列
8並列くらいまで確かサブエージェントで動くから だからタスクの依存関係の整理までまずやっといて
で指示の中にあの適宜サブエージェントに依頼するかつ タスクの依存関係的に並行で実行していいものは並行で
並列で処理するようにしてもらうみたいな感じにしてするとすごい効率が上がる なるほどね
ちょっとこれ聞いてる方向けの話にはなるんですけど クロードコードもコーデックスもあれだよねセッションの履歴を戻ることで
もともとコンテキストウィンドウが例えば60%まで減ってたやつが 会話を2ステップ3ステップ履歴戻ることで80%まで回復したりとか
そういう機能が エスケープ2回押したらその会話履歴の中のどこに戻るみたいなことができる
別セッションのヒストリーみたいなんじゃなくて その1パイントセッションの中のヒストリーみたいなのを見てる
だからAIは履歴全体を見てるから元に戻れば戻った分圧縮できるというか 普通に過去の時点に戻っただけだから
ただ過去に戻ったタイミングにおいての未来のセッションは全部切れるので 戻るときはちょっと注意しないといけない
ちゃんとここまでやったんですよっていうのもだからセットで教えて それをステップ1はもうやったから確認して
ステップ2に進んでくださいって言ったらコンテキストウィンドウはほとんど消去しないまま
例えば実装の中でさこの実装をやってもらいました でその後に
この実装に対して聞きたいみたいなのあるじゃん
その時はほら俺はアスクコマンド作ってるからアスクコマンドして アスクコマンドして自分の得たい情報を知ったらまたエスケープに変えてその聞く前に戻る
あー確かにそれもいいね そうすると無駄にコンテキストを加わなくていいから
だから俺めっちゃ多分コンテキスト気にしながらあのLLMと 会話してるからなんかその感覚が阿部ちゃんからはなんか見ないなって思ってた
あんまり気にしないだから多分ね困ってなかったんだよね 困ってないんやと思うけどそれはタスクの性質上かもしれないし
もしかしたら阿部ちゃんのもともとの課題である 自分の使い方的に大きくある意味だから
AIの恩恵を享受しきれてない状態なのかもしれないしそれはどっちかわからんけど
タスクの性質は要因としてあるかなと思ってて 調査も結局調査してもらったやつを僕は確認したいっていうので
1回止めてもらわないと逆に困るみたいなタイミングもあったり あとは開発規模が回収とか調整とかそんなに大きくならないから
気にならないっていうのはあるんだけどやっぱりでも何でしょう 複数のタスクとかを例えば同時並行である程度やってもらえるようになったりとか
タスクとプロンプトの関係
あとは大きなタスクを何でしょう 小さな複数のタスクをまとめて1個の大きなタスクにしてドカッとやるとか
なんかもうちょっと使い方あるんじゃないかなっていうのが悩みだったから
なるほどな けどなんかその阿部ちゃんの多分やって欲しいこと
おそらくやけどちっちゃいタスクであってももうちょっとやってほしいみたいなのがあるんだろうなと思ってて
それテストを書くとかテストを実際にしてもらうとか そこはなんか
プロンプトというか設計者なのかなって思った プロンプトでそれをやりきるのは正直あんまりなんか微妙かなって思ってて
なぜならプロンプトを与えすぎてもそれはそれで あんまりオーバーすぎてなんか回らないじゃん
だしそれをスラッシュコマンドにしても汎用化しきれることはないと思うから なんか俺のイメージで言うと
プロンプトと設計書を使い分けて設計書の中に まあ設計書と別に計画書を作ってもいいけど
なんか計画書テンプレートみたいなのをなんか阿部ちゃんの普段 あのやってほしいってか基本的に多分既存のプロジェクト開発回収って
開発する前に要件定義して 要件定義したものをもとに計画書を立てて計画を立ててで開発
でその後にテストを行ってで実際にドキュメント化するみたいなとか なんかそういう多分順序が基本的に決まってて
この順序っていうのを阿部ちゃんにとってフィットする計画書の なんかテンプレートみたいなのをまず作ってこのテンプレートに沿ってあの
設計書を作ります この設計書をもとにこの計画書テンプレートをもとに計画書を立ててくれって言って
でプロンプトにはこの計画書を見て こういう振る舞いをしなさいみたいなのをすると
最後までいきそうだなって思った まあ確かにまああれだよねまあ要件定義書みたいなものも作ってなんか1個の
大きな仕様みたいに固めたらそれをブレイクダウンというか あのどういう順序でやっていくかっていう
あのタスクの実行計画書みたいなのを作ってそれをやってもらう そうそう俺いつもそうしてディレクトリーもう
ドックス配下にディレクトリーそのプロジェクト そのタスクのプロジェクトのディレクトリー切ってで設計書要件定義書と計画書は分離している
で各ステップなんか大きすぎる場合はさらにその要件定義書の各ステップにブレイクダウン したすべての詳細な設計書をまず作ってもらって
その上で始めるみたいな結構資料数が多くなる そうなんかサマリー的なものと計画と実行計画とそのそれぞれの実行計画の
クロードコードの利点
ステップの詳細なステップみたいなのを そうなんだ確かにステップが2段階にこう分かれて書かれてたらさすがに
実行するなんでしょうより細かく設定されているからそれ順序 辿ってやってくれてみたいなそうでそうすると何がいいかというと
まあLLMからするとLLMを精度一番高くやっぱ出すっていうのはフォーカスさせることだと思ってて
そこでクロードコードのサブエージェントはすごくいい 1ステップごとにフォーカスさせれるから
1ステップのここの部分に注力してやってもらうっていうので相当精度が上がる けどモデルのやっぱ頭の良さ的にCodexかなみたいな感じでCodex
買っちゃうけどまあけど 基本的には
そうだね各ステップを詳細化していく だからもうこの詳細化する時に仕様が全部細かい仕様まで決まるから
あとは実装例みたいなところまで決まるから そこで頭を使わせるみたいな残りはもうなんか作業をさせるみたいな感じで
なるほどタスクの中にもはや実装があるぐらいまで持っていってるんだ 持っていく時もある
ややこしそうな時は
ちなみにその中にサブエージェントとかをこのタイミングで使ってねみたいなことはやったり
それは計画書の中にクロードコードでやる場合はタスクの依存関係があって 並列できるところは並列できるとかっていうのをマッピングしておいて
でそれをもとに基本的にはあの 親エージェントにはあなたはこのプロジェクトのいわば指揮者のようなものでした
なのであなた自身が作業するのではなくて基本的にサブエージェントに実行させてください で計画書の中には並列可能なタスクとかもあるんで
並列させられるとこはサブエージェントに並列実行させて効率的に進めてくださいみたいな でその時にあの必ずサブエージェントには詳細な指示と
あとその関連ドキュメントは必ず閲覧するように あの指示を投げてくださいみたいな
指示の方もできるだけ細かく定義してあげる
これステップ1やっといてっていう指示をやられるかステップ1をやっといてください このドキュメントとこのドキュメントとこのドキュメントは必ず確認してからやってくださいって
どういうふうに親エージェントがサブエージェントに指示出すかによって精度が変わるはず なんで
そう考えるとやっぱりクロードコードのサブエージェントってめちゃめちゃありがたい機能かな そうそうめっちゃありがたい機能
コーデックスだとできないもんね できない
なんか確かになと思いつつ あとちょっと気になったのが 確かにちょっと僕も実行計画書っぽいものを作るときはあるんですよ
フェーズ1からフェーズ4までみたいなのでその中にタスクが分解されてて こういう順序でやってくださいみたいな話を書いた時に
コーデックスの特性
それ読み込んでやってもらってもたまにフェーズ2とかで ここの今これは詰め切れてないだけなのかな
複雑なので停止しますとか なんかなったことない
そうなんだ それは2段階にタスク分解することで
多分そのフェーズが1,2,3,4ってある中のちょっと龍田が荒い部分も細かくされるから AIは迷うことなくただただひたすら突き進むことができたりするのかな
なのかなぁ あんまないかもしれない
なるほどね 僕はねたまに止まっちゃうんだよ なんかそこがあるかもしれないあの僕が最初言ってたロングランクしてくれないっていうところ
複雑すぎて止まるみたいな なのかななんか
ちょうど昨日とかは変更量が多いので なんかその残タスクとしてドキュメントにまとめるっていう対応をしますって切り替えたんですよ
ちょっと待ってよみたいな
それ最近のそのコーデックスナーフ問題とかそっちの方なんだよもしかしたら
あーまぁそっちもあるかも なんかねコーデックスが最近ナーフされたんじゃないかって
Xでもねちらほら言われててね まぁこの間2ヶ月前ぐらいかなクロードでもあったような話で
結構バリバリやってたのに急にスペック落ちたなみたいな
けどオープンAIのシステムプロンプとおそらく内部の作り的にはオープンAIの方が無駄なことをさせないような
あの 指示を多分細かく書いているはずなんで
指示なのか何なのかわかんないけどモデルの作り上の問題なのか何なのかわかんないけど
そういう性質あるじゃん結局
オープンAIのチャットGPTの方がやっぱ端的に出す
で多くのことをやらないだからまあ傾向としてはもともとあったよねその大きすぎるから一旦やりませんみたいなとか
逆にクロードはその辺オーバーブルマリーじゃないけどしっかり全部出し切るというか
なんだったら余分なことまでやっちゃうみたいななんかそういうなんだろう性質の違い みたいなもともとあったから
まあけどとはいえなんか指示されたことはやるイメージだけどね
計画の中身もざっくりしてたりするとやっぱり迷って止まるとか
まあタスクの性質によるよね俺もだからそこまでやる時もあるしそこまでやらなくていいなぁみたいな時もあるし
それはなんかその感覚は俺より絶対阿部ちゃんの方が高いはずで
イメージはなんで俺がその大きいか小さいかなんでイメージできてるのかよくわかんないぐらいの感じじゃん正直
まあそうだねこれは重そうだなこの開発は重そうだなって普通感じない
やってないとわかんないはず
多分阿部ちゃんの方が絶対精度高いはずだから
逆に僕が過度にAIに期待しすぎてるのかもしれないね
こんぐらいだったらまあできるでしょうみたいな
こんぐらいのタスクだったらまあそんな苦ないかな
まあ自分があんまり苦に感じないタスクとなんでしょう
AIが本当に苦に感じるタスクっていうのをあんままだ切り分けできてないのかもしれない
なんかそれで言うともしかしたら俺がその途中で終わっちゃうとか
阿部ちゃんのその意図しない動き振る舞いをLLMがした時に
どっちかというとあれかも俺が気にしてないだけで俺止めてるかもしれない今思ったけど
一回なんか予期しない予期しないというかなんか初手ぐらいなんか初めの動きぐらい初動の動作ぐらいで
なんかこいつ俺の思ってるなんかベストな動きしてないなみたいな時がたまにあって
その時は俺もう全部リセットするまあそれが中盤ぐらいであってもリセットするよね
全部消すコードの編集も全部消すでもう一回何もやってない状態からで
で俺がモヤっとしたポイントを指示書にもう一度書いて
なるほど指示書の精度がだから何でしょう
まあそれも時と場合によると思うけど止めてやり直す時っていうのはどんどん指示書の精度が上がっていく
そう上がっているだから俺がなんかモヤっとしたいやこんな振る舞いやめろよっていう時は
あのもう一回指示書に重要な事項として書く書いて上でやるから
だからなんか俺はそれを気にせずにやってただけで
実は同じことがあるのかもしれない
いやでもそれすごいわかる気がするけどそんなにちゃんと意識的にやってなかったかも
あの特にまあこれどうかなコーデックスで結構強い傾向かなと思ってるのが
一回コーデックスが判断したことってあんまり曲げれないっていう感覚があるんですよ
それ言うよね俺全くその感覚がないのはセッションを全部切ってるから
そうそう多分切ってるから僕の場合はなんかそのアジャストしようとするんだよね
多分ちょっと違う方向行ってるな
あーなるほどね
これって今作業ここまでやってもらってるけど
でもこれはこういう風にやるべきなんじゃないか
なんかすっごいザラザラこういやそれはみたいな
わかったわかったそれなんでかというと多分あれだね
俺はさこのエピソードの一番初めの方に話した
コンテキストめっちゃ気にするから
その一個方向転換を嫌なんよね
そのセッション内で方向転換が一個でもしてると
なんか無駄な知識というか無駄なコンテキストが圧迫されてるとかすごい気持ち悪いから
ゼロベースでそれを至上に盛り込んでやるっていう
あーなるほどね
そうするとめちゃめちゃ精度上がるから
だからか阿部ちゃんが言ってるのずっと理解してなかったけど
阿部ちゃんはそのセッションの中でやりくりしようとしてるんだ
最近やっぱなんかあんまり軌道修正って難しいんだろうなっていうのを理解してきたから
止めることもあるしやり直すこともあるんだけど
その時にもちろん改めて指示書に盛り込むっていうのは
自然とやってたけどなんかすごい意識的に何でしょう
自律駆動開発の効率化
こういう時はこうしようみたいなパターン化が自分の中にもなかったから
言われてちょっとハッと気づいたかもしれない
確かになんか俺絶対に途中での方向転換
チャットアプリ使ってる時もね
何の時でもそうやけど途中で方向転換する
初手のアウトプットが一番最大化されてるっていう認知があるから
絶対に自分の思わないアウトプットが出たら
そのチャットのセッション内でやりくりしようとするんじゃなくて
全く新しいチャットに対して
もともと与えたプロンプトをコピペした上でその下に
注意事項としてみたいな補足としてみたいなとかって書いて
そっちの方向に寄らないような
全く新しいやつみたいなのを召喚させるようにして
それは確かになんか結構面白い気づきかもしれないです
なんか問答だからAIと
問答しない
AIとは問答しない
常に自分が期待するっていうのが
自分の期待がそもそも間違ってるかもしれないけど
こうだよねとか間違ってないよねっていう
最大パフォーマンスのアウトプットを
常に吐き出させ続けて
そうそうそうそう
阿部ちゃん以外の人にもそうやけど
LLM AIに求めてるものが
根本的に違うと
こういう使い方の違いって生まれるなって
最近気づいて
例えばやけどちょっと相談したいんだよねとか
ちょっと参考にしたいんだよねぐらいで使ってる人は
おそらくプロジェクトとか作って
クロードで言うプロジェクト
ChatGPTsを自分で作って
システムプロンプトを高精度化していこう
みたいな発想にはならない
例えばそれはなぜなら別に参考程度に使ってるから
それをそのままアウトプットに使うみたいなことは
別にしようとしてないから
期待値が低いよね例えばやけど
けど俺は作業をゼロにしたいんで
システムプロンプト磨きまくって
最終的にこの作業自体ゼロに
ここに投げるだけでゼロにしたいって思ってる
からプロジェクトとかGPTsとか作って
ほぼ自動化というか
システムプロンプトを厚くする方に
結構注力したくなるタイプだよね
みたいななんかこういう
それに対して何を求めてるかによって
結構人間人の振る舞いって変わるなって思ってて
それで阿部ちゃんは問答しながら
やっていくっていうスタイルというか
問答する前提
何やろうね期待値が
だからこうちょっとずつ自分に寄せていくというか
みたいなやり方を
俺はそこに対して期待してなかったから
なんでだろう
あとコンテキストウィンドウ問題も
俺は結構センシティブに考えてたから
初手でやっぱり大きいアウトプットを
出してほしいっていう
それはあれかな
俺が自分でコーディングできないからとかもあるかもしれない
多分俺はもしかしたらできるからこそ
詳細をちゃんと把握した上で
あんまり間違った方向の実装とか
動いてればある程度正しいっていうのはありつつも
中身の詳細なコードまで
正しからを状態に持っていきたいとか
内部の状態をしっかり把握したいっていうのが
まだ戦前的にあるから
けどそれはね俺もあるよ
だから阿部ちゃんにこのコーディング規約とか
めっちゃ厚くしてもらったりとかさ
これってどうなんかなみたいなとかっていうのがあるから
だから俺はシステムプロンプトでどうにかしようとしてるんだよと思う
ドキュメントとか
でも俺ね今の話はコード一行一行追ってみたりするときも
全然あるから
本当にここにあるべきものがあるかとか
もちろんその中で細かい書き方の癖みたいなもの
人間同士でコードレビューとか
いろんなところでやったりするけど
そういう細かい癖みたいなのは指摘しないけど
プロジェクトとして品質を担保するために
あるべきところにしっかりあるかっていうところを
細かくチェックすることがあるから
全体として規約ベースだったり
間違った実装をしないようにというのは
サブエージェントとか作書コマンドで充実していくっていうのがあるんだけど
俺はもっともっと角に
ここにちゃんとあるかなみたいな
そういうのがあるのであれば
俺はドキュメントに書けよって思っちゃうけど
正直
そういうのがあるってことは
阿部ちゃんの理想のコードをみんなが書けるようにするっていうのが
ここでいうみんなっていうのは人間じゃなくてAIなんやけど
っていうのがやっぱり最大の目標で
入れれるコンテキスト量は日々増えていくと
みたいな感じの世の中の中で
限って書きすぎることはない
ただ書くときに抽象化されたルールとして
糸をちゃんと書いてもらわないといけないけど
正直その文句が出てるんだったら
いやいやそれ書けよって感じかもしれない俺の中では
明確に書けるときと
なかなかどうなんだろう
感覚の部分は指摘しないって言ってたじゃん
それがもしかしたら感覚の部分を指摘しちゃってたときに
ルール化できないみたいなのがあるかもしれないけど
感覚じゃないところは基本的には言語化されるはずなんで
そこはちょっと頑張ってほしいなって感じがするけど
もうちょっとそこの言語化頑張ったほうがいいのかな
あと切り分けもちょっと甘いかもしれないね
感覚で物を言ってるのか
ちゃんとルールベースで明確な理由を持って
こうしてほしいって思ってるのか
確かに
AIモデルの進化
ニオコードだなみたいな感覚だけなのか
これって規約的にこうじゃないみたいな
確かに規約的にこうじゃないって思ったものに関しては
こうだよねみたいな
ここにはこうあるべきだよねとか
ここではこう書くべきだよねみたいなのは
プロンプトにはagent.mdとかに組み込んだりとか
そういうのがトロトロやってるんだけど
新しい実装とかでファイルがそもそも増えるとか
ディレクトリが増えるっていうタイミングでは
まだこうちゃんとこうあるべき論が
どっちかというと試行錯誤してたりもするから
なかなかできてなかったりするかなっていうのはあるかもしれない
なんかそれでさ
俺ちょっと別のエピソード話したいと思ってたんやけど
そうなんなんだ
ことがあって
最近WindsurfがさSWE1.5っていう
agentモデルを出したんですよね
デビンのチームがね出した
そうそうそうそう
結構さうちとかでリアクトルーターV7を使って
プロジェクト開発していくみたいな
リアクトのフレームワークのやつだよね
最新すぎて知識がないからわかんないみたいな
その一個前のバージョン
リミックスを統合される前のバージョンの書き方をしちゃったりとか
なぜかNext.jsの書き方をしちゃったりとかみたいな感じで
結構困ってたよね
コンテキスト7でどうにかやるみたいな前提としてあったけれども
その知識的な最新知識どこまで持ってるか問題っていうのは
払拭もしかしたらできないかもしれないけど
ある程度コーディングエージェントとして
コーデックスの方がおそらくコードに特化してエージェントが作られてて
クローゾの方がおそらく汎用化エージェントとして作られてるエージェントを
だから資料作りとか上手いのかなみたいな気がしてて
むしろアンソロピックは明言してるじゃん
汎用化エージェントですと
コード以外でも使えるよっていうのを明言してるから
おそらくそういう違いが
コーデックスに関してはコーデックスっていう
コードっていう名を冠してるから
まさにコーディングエージェントとしてやりたいんだろうなみたいなとか
みたいなのを感じるんですけど
それをよりSWE1.5ってやつは
Devinのチームがベストプラクティスとか
しっかりとチューニングして教育した
っていう前提のモデルらしくて
じゃああれか
コーデックスのモデルと似てるというか
思想としては似てるんじゃないかな
オープンAIの会社員の方が
どれくらいそこに対してチューニングをかけてるかっていうのは
正直僕たちは知るよしもないっていう感じではあるんですけれども
とはいえ
そういうのを実際に公式で言ってるんよね
これ結構期待大なんじゃないかなって思って
だから阿部ちゃん的に言う
ちょっとしたエンジニア的諸差
それは言語化に至らないまでも
みたいなところも感覚的に
いやこれダメだよねみたいな
エンジニア的にみたいな
そういうのがちゃんと詰め込まれてる
それはありがたいね
事前にエンジニアとしての諸差とか感覚っていうのを
理解してくれていると
やっぱりここに書くべきじゃないじゃんとか
その実は絶対違うでしょみたいなのが起きにくいから
いいかなって思って
それはありそうだね
コーデックスがクロードと明確に個性が違う理由の一つは
やっぱりコード特化してるからっていうのはあるかなと思ってて
書き味も全然違うんですよ
安心感あるよね
余計なこともあまりしない
余計っていうのは
例えば例外って言って
プログラムがうまく動かなかった時に
エラーをちゃんと補足して
プログラムが停止しないようにキャッチしたりするんですけど
クロードコードはめちゃくちゃその例外処理を書こうとするんですよ
それちょうどね SW1.5の説明にもあって
ちょうど書いてた
無駄にトライキャッチが多くなったりすることを防ぎますみたいな
防いでるって感じ
一応クロードに和訳してもらったあれで言うと
SWE1.5はWindsurfで実際に行う作業を反映した
多様で実世界のコーディングシナリオで学習されていると
私たちは単にテストに合格するコードではなくて
クリーンで保守性の高いコードを書くことを
モデルに教えることを注力しました
これにより冗長な出力が減り
不必要なトライキャッチブロックが少なくなり
ベストプラクティスに従ったソリューションが得られます
シニアエンジニアやオープンソースのメンテナーと協力し
多くの言語やフレームワークに渡る高品質な例から
モデルが学習できるようになりました
コード品質の向上
その結果何をコーディングすべきかだけでなく
どのようにうまくコーディングするかを理解するAIが誕生しました
っていうのが一応SWE1.5の説明
さらにセレブラスっていう
高速に推論できるみたいな
提供している会社さんがあるらしくて
そこと協力して
馬鹿みたいな速さで高精度が
だいたいクロードソネット4.5よりが
43.60%SWEベンチプロっていうやつで
SWE1.5っていう新しいモデルは40.08%
3%ぐらい低いぐらいのレベルで
これはChatGPT5が36.3%らしくて
これ本当なのかなって感じだけど
それよりもいいと
その上で
例えばソネットって結構速いじゃん
ソネット4.5結構速いと思ってて
これは69トークンパーセカンド
69?
それが950トークンパーセカンド
10倍以上じゃん
この60トークンって
この図の読み方がわからんから
少なくても10倍ぐらいの差がある
でもなおSWEベンチの
問題解決力を測るベンチマークにおいて
ほとんど3ポイント差しかないよね
っていうところがすごいんだよね
かつGPT5よりも高い
なんだったらみたいな
すごいね
一応731エージェンティックコーディングタスクアクロス
みたいな書いてるから
コーディングタスクを実際にやらせた
達成率みたいなのかな
これはコンテキストウィンドウとかもどんな感じなんでしょうね
どうなのかな
10倍以上出るけどコンテキストウィンドウは狭いですってやったら
一瞬でF1レーサーみたいな
一瞬で食い潰すみたいなことは起きそうだけど
一方で10倍も速く出してくれるんだったら
俺のやり方にマッチしてるかもね
リセットOKみたいな
アピレーション回しやすいよね
だから根本的な使い方が変わる気がするよね
確かにこれはかなり変わりそうだね
普通の人っていうかサンクコスト的な感じで言うと
たぶん1時間回したやつをコードの編集すべて
抹消するってあんましない
そうなんだよやっぱ心理的にちょっと
抹消しにくいってなるよね
それをたぶん抹消するかしないかでも変わるけど
抹消しやすくなる環境が用意される
1時間かかったやつが6分で割るんだったら
全然消すわね
そうそうそうそう
でそれを6回くらい回してさ
30分くらいそれでも30分くらいで
一番いい品質のものをチョイスすればいいみたいな
確かにな
これは使ってみたいな
ね、いいでしょこれ
めちゃめちゃいい
これはなんだろウィンドサーフを
インストールしないと使えないのかな
ウィンドサーフないらしい
そうなんだ
結構しっかりこのデビン
あとそのね僕がこれ単なる
情報としてもいいなって思ったけど
やっぱデビンチームがすごい人たちの集まりじゃん
そうだよねデビンはやっぱり
当時僕らもすごく助かったし
品質もねすごい良かったから
チームもあれでしょ
卓球プロの上位ランカーたちが集まってる
小数生の人たちがやってるから
しかもその人たちがさ
みんなで同じ家で寝泊まりしながら
24時間ずっと頑張ってるみたいな
そんな環境で作られた
優秀な人たちがさらに血へど吐きながら作ってるみたいな
そういう前提が
確かにすごいベストプラクティスの質が
本当に高いんだろうなっていう
そういう人たちがこういう風に
ベストプラクティスをちゃんと叩き込んでるよって
言ってるっていうこの
なんだろう
信頼というか安心感というか
二段活用的な
これを単純に読むだけでもすごいなって思うけど
その人たちが言ってるっていうので
さらに信頼感高いなみたいな
性能ベンチマークの比較
そうだね
しかもトライキャッチを防ぎますとかって言われたら
そうなんだよみたいな
思ってたんやろね
多分思ってたんだろうし
結構期待大な気がしますね
ちゃんとインフラ作業とかも
フィールド名を暗記するとかじゃなくて
ちゃんとKubernetesのマニフェストを読むとか
テラフォームのコンフィグ読むとか
ちゃんとこっちを読むみたいな
コンフィグファイルを読むとかみたいな
そういう風な
ちゃんとエンジニアらしい振る舞いを
エンジニアっぽいね
コンフィグから見に行くのはエンジニア仕草だね
そもそも問題解決するにあたって
見始める場所からによっても精度変わるわけじゃん
そうだね
コンテキストウィンドウ
全然違うところ見てるじゃんみたいになると
そこがコーデックスだったらまだマシだけど
こいつだともっといいみたいな
あるかもね
そうだね
高いのかな
なんかね
なんか
1タスク
1
1クレジット
謎の覚悟体系
1タスク1クレジット
なんか
ちょっと僕は
ウィンドサーフまだ使ったことないから
ウィンドサーフいいよ
俺みたいな人にはおすすめなのかな
そうだよね
推しだったよね
中でやっぱウィンドウが立ち上がって
クロームとか立ち上がって
ブラウザで
ちゃんと見て
明示的にそこを指定して指示できるとか
っていうのが
結構
コンテキストだからAIに渡しやすいんだよね
渡しやすいそうそう
エンジニアからしたら別にこうしたらいいじゃんみたいな
あるかもしれないけど
俺みたいな人にとっては
すごいコンテキストを渡しやすいから
いいなって
そうなんですよ
自信を持ちをしたいなって思ってたんですよ
そうだったんだ
うん
このモデルの作りがどう
なのかなみたいなのは
V0のさ
V0 1.5とか
のモデルっていうのはさ
今はどうなのかわからんけど
もともとその
ベースモデルみたいなのがあって
ベースモデルっていうのは
普通に
チャットGPTとかみたいな
なんかそういう
普通のまあ普通のって言ったら変ですけど
なんか他の企業が出している
ベースモデル
の
にラグで強化する
事前学習で強化する
フロントエンド開発においてみたいな
なんかそういう
モデルの作りをコンポジットモデルっていうらしいんやけど
V0ってあれか
あの
フロントエンドの開発してくれる
そうそうそうそう
そのモデルがそういう作りになった
独自モデル出したんだけどそのモデルっていうのは実は
モデルから
自分で0から
自炊したんではなくて
あの
もともとある既存モデルみたいなのを
まあうまくチューニング
するというか
でよりこう高い精度で
あの
コーディングフロントエンド開発を
してくれるような
ものを作ったみたいな感じだから
だからLLMプロバイダー
に感じに見えるけど
ちょっと違うよね
なるほどね
要はだからクロードコードを
なんかまあファインチューニングなのか
心理的影響とコミュニケーション
何かして
強化してるっていう
みたいなクロードコードではないけど
まあそんな感じのような
まあ今どうなのか分かんないけど
あの少なくても出た時は
そうだった
そう
この
SWE
1.5がどうか
どういう作り方なのかなっていうのは
ちょっと興味深いなって思ってる
うん
ベースモデルがみんな頭良くなってくると
まあ確かになんかそっちの
方針
でも
まあなんか
いけそうだなみたいな気はするけどね
まあけど外部の
オープンソース基盤モデルを活用し
その上に独自の強化学習チューニングを
施した大規模モデルです
うーん
なんかあれなんかね
ディープシークとかのモデル使って
特化型にしたとか
そういう感じなのかな
うーんけどディープシークとかリャマとかって
多分なんか名前を入れないといけないとか
そういう制限があった気がする
ああライセンスのあれがあるんだ
そうそうリャマは確かね
なんちゃらリャマみたいなのあるじゃん
あれは全部リャマを使うと
モデル名に
リャマを入れないといけないみたいな
そういうのが確か
ディープシークはちょっとわからないけど
そういうパターンもあるらしくて
だからそういうのに定食しないやつなんでしょうね
モデル的には
うーん
逆に
これの精度によっては
このオープンLLM
チャットGPも最近
オープンソースのやつ出したけど
パソコン上でも動くよみたいな
あれをチューニングする可能性が
すごい感じられるよね
これがもし
うまく動く
本当にコーデックスとか
クロードコードと遜色ないじゃんみたいなぐらいの
精度出すんだったら
オープンソース
だからもっとそういう企業が増えそうやね
なんかにめっちゃ特化した
LLMみたいな
特化型
いわゆる汎用的な
ベースモデルみたいなのは
すごく高度になってきてるから
要は
人間世界でいう専門職みたいなのを
どんどん作っていくっていう
そっちに
行くでしょうね
こういうのを考えるときさ
俺いつも思うんやけど
人と一緒で考えたほうがいいなって思ってて
例えば人ってさ
めっちゃ優秀な人がいてもやっぱ専門職っていうのが
いくらでも
LLMは今人にも追いついてない状態なんで
LLMが
めっちゃ頭いいじゃんって言われるようになった世界って
どういうことかというと
人みたいにすごいみたいなところが
まず
第一到達してやと思うよね
手足を持ったとか目を持ったとかもそういう意味でもね
フィジカル的な意味でも
そうしたときに
人ってちゃんと専門職あるよな
みたいな
評価されるときに
っていう今の世界を考えると
やっぱ専門職
とか
そういうのがどんどん出てくるみたいな
世界はLLMでも全然
ありそうだなみたいな
たしかに
専門職持っても結局
コミュニケーションうまくいかないとか
AI技術の進展と課題
推論力が足りないから
めちゃくちゃ頭はいいのに
問題の本質を突き止められないみたいなのが
これまでの課題とかで
多分大きい部分が
例えばあったとして
その部分がある程度解決されて
いわゆるベースの
めちゃくちゃ改善されたから
ようやく専門職に
かじ切りできるような
時代になったのかなって
気がするね
そこで問題となるのが
今までだと
LLMプロバイダー的な
オープンAIとか
アンソロピックとかみたいな
企業が
専門職っぽいことを
しなかった
Googleはあくまでもプラットフォームを
作ってただけ
っていうところから
専門職とかも
バンバン作り始めてるみたいな
スタートアップ入る
余地どうなんだみたいな
スタートアップがいても一瞬で食い潰されるみたいな
そこがちょっと
怖いところだね
僕らは怖いところだね
結構最近ね
Googleの発表とかで
スタートアップが何個か死んだなみたいな
感じることが
正直このLLMとか
AIとかの進化で
ニュースとか見ると
あのプロダクト死んだみたいな
もちろんそこで
もっと
針の穴の
糸を通すじゃないけど
すごい局所的な課題を解決して
生き残るとか
AIを使うっていうのも
抵抗がまだある人も多いし
実際俺も
別の作業においては
抵抗があったりするときもあるから
そういう意味でいうと
デビンの影響
AIを使っていることが完全な優位性には
ならないかもしれないけど
今のところね
ただ結構そういうのが
オープンAIとかがやっちゃうっていうのが
一個あるよね
そうだね
今後だからサービス作るときとか
単にこうAIにお願いして
作業ショートカットできるぐらいの
サービスはもう
一瞬で淘汰されるから
どういうふうに
差別化というかね
測っていくか
改めて考え方を
考えていかなきゃいけないのかな
っていうのはあった感じ
そうやね
今回のこのWindows SurfのSWE1.5は
そのチューニングによる音形
オープンソースの
LLMモデルでも
やってけるよねみたいなところを
ある意味証明してくれる
一つの
一個の旗
旗印じゃないけど
みたいになるような可能性を
僕は感じてます
なるほど
デビン出たときも
そうやったけど
そういう意味ではすごいよね
このデビンの開発チームって
デビン出たときもインターフェースが
チャットから呼び出せるようになるだけで
こんなに体験感あるんだみたいな
なんか一個の違い
ブレイクスルーみたいなのを起こしてくれてるよね
自分が普段使ってるところから
指示出しできるとか
そうすることによって
より非動機な感じで
今までだったら画面上で
AIがどう動いてるかなって見てたのが
あんまり気にしなくなったとか
自分
イコール人間
人間自体の振る舞いを変えられる
その体験によって
確かにデビンの登場って相当
インパクトあったよね
いろんな軸であって
それは例えばスラックから
接続できるから
エンジニアじゃない人も
AIにコーディングを
頼みやすくなったっていうのもそうだし
かつデビン自体が
GitHubとかいろんなものに接続できるから
ある程度自立して
PRまでプロリクエストまで投げてくれる
そうそうそうそう
やっときましたみたいなね
分かりましたみたいなね
あとは質問の信用レベルによって
ここ不安だから聞いてきます
聞いてくるとか
あとはもう
サンドボックスの環境を作って
提供してくれたっていうのが
すごいでかいかなと思って
今までやっぱセキュリティとか
破壊的変更
例えばパソコンの
あれもあれも
そういうのされると怖いとか
いろいろそういうリスクっていうのを
みんな感じてるからこそ
全権委任できていなかったのを
デビンは
デビンは
しかも簡単に
作れるバーチャルマシンを
提供したことによって
一気に人類が
AIに頼もう
っていうタイミングを
作ったきっかけだよね
たぶんデビンは
今はそういう意味では
完全に任せることは結局できないよね
っていう感じになっちゃってるじゃん
そうなっちゃった以上
CSとか
非エンジニアの人が
スラックからお願いする簡単にはできないよね
っていうところになったから
今結局
エンジニアが使うためのツールとして
CLIツール
クロードコードであったりとか
コーデックスCLIがすごい注目されてる
し俺らも使ってるけど
あれはけど本来はたぶん
AIの恩恵を
完全に享受できるサービスではなくて
あくまでもエンジニアの
俺ずっと言ってたじゃん
1.5倍2倍になるツールじゃなくて
エンジニアもそうだし
CS非エンジニアの人も
100倍になるツールの可能性が
AIにあるから
Windsurfの統合
そういう使い方をアベちゃんに工夫して
やっていってほしいって
ずっと言ってるんですけれども
その可能性がある方は
やっぱりいまだにデビンっていうところあるよね
ただコストパフォーマンス的な問題で
やっぱコーデックスの方が
コストパフォーマンス高いから
結局絶対量上がるから
みたいな話があったりとか
みたいなのはやっぱLLMを
作ってる原理のところが
サービス提供してる強さが
やっぱずっと
残っちゃうみたいなところはあるけど
まあとはいえ
デビンはいまだに
その意味では
もう1回復活しそうな気がする
もっとLLMとしての
性能が上がった時に
より
強くなるというか
そうだね
ちょっとねデビン
最近ね話を聞かないことの方が
クロードコードとか
コーデックスの鍵に掛けられてる
イメージがあったんですけども
今回この登場によって
また
もしかしたら
昨日なんか
Windsurfも統合されて
Cursorと一緒な感じになったじゃん
要するに
で
ツールも出すんじゃないかなって気はするけどね
ここまで来たら出してほしいなって
思ってますね
その上でインテグレーションめちゃくちゃ
豊富でいろんなものに接続できるから
元々あったデビンの良さを
活かせるみたいな
そうするとデビンの元々の資産を
流用するという意味でも
すごいことになるよね
また1個ね
ブレイクスロー来てくれるんじゃないかな
あと1個気になってるのが
なんか
使えば使うほど
デビンって元々
使えば使うほど知識貯めていくみたいな
そうだね
それをこのSWE1.5の
説明にも書いてて
そうなんだ
これだ
SWE1.5はWindsurfのエージェント体験に特化して
最適化されていますと
実際のコーディングタスクで
エンドツーエンドの学習を行い
社内で継続的に自社利用することで
日々遭遇する複雑な
煩雑なシナリオに対応できるようにしました
この緊密な統合により
モデルはWindsurfのツールを
効果的に使用する方法を理解し
ワークフローに自然に馴染む形で応答します
みたいな書いてて
だから多分デビンのその
知識を貯めていくみたいな
元々の資産
とうまく統合されてるのか
これからするみたいな
未来があるのか
どうやって
基本的にMCP化したら
いけるじゃん
でもMCPって
限界あると思ってて
内部統合することのメリット
みたいなのを
その可能性を見せてくれるんじゃないかなって
俺は思ってる
今まではMCPでそういうナレッジ
蓄積されたのは取りにいくよねって
いう話だったと思うけど
それをもう内部で持っちゃうみたいな
内部統合することで
MCPって無駄にコンテキスト食っちゃうと思うよね
正直
そうじゃない知識連携方法
みたいなのを
もしかしたらやるのかもしんないし
内部的にMCP作ってるだけとかもあるかもしんないけど
デビンってもともと
そういうのが
ナレッジっていうのに
貯めていけて
チーム利用にすごくいいよねみたいなのが
もともとのあれで
今コーデックスとかはそういうのが一切ない
ないよね だからセレナとかで
メモリをやってもらうとか
ちょびちょび作るとか
ドキュメント充実させるとかそういうのでやっぱ
収支するけど
あれって別に
ラグじゃないからさ
だから
Cypherとかだとラグ化できるから
Cypherとか使うと
近しいことはできるかもしんないけど
多分セレナとか
ドキュメント充実だけでやってる
人たち
と
大きく
ブレイクスループが起きる
マスモス買ってみたい
どうやって
知識を貯めていくの
デビンの
デビンのやつを
使うんじゃない
デビン上に保存するのか
デビンのシステムを模して
ウィンドサーフ上に蓄えるのか
みたいなのもあるかもしんないけど
チームでも生きるって話だから
多分
今はできないのか
今はそういうことは書いてない
そういう説明
一文があっただけで
この一文ちょっと気になるなって
俺は思ってるだけ
将来の不責になってそうだね
そんな気するよね
って感じでした
結構しゃべりましたね
結構しゃべったね
阿部さんの
阿部さんの課題解決にできたのか
一応ちょっとできたか
AIへの向き合い方
結構気づくことは多かったかな
僕がAIに向き合うときに
要件定義書と
自己計画書を書くと思うんだけど
そこの流動の差とか
あとはセッションを戻ったときに
履歴を戻るってことも
そうだし
そこの戻る意識的に
戻ったときに
プロンプトをより改善していくっていうのを
もっとやれればいいんだろうなとか
結構気づくことは多かった
思い切ってセッションを切る
コード編集も全部切る
やり直すっていうね
難しいですよっていうのを
改めて認識できたのは
よかったかな
10分ぐらいで終わる話かなって思ったんだけど
人に
人と一緒だと思ってて
こうって思ってるエンジニアの人にさ
いやこれはこうだからこっちでお願いします
って言ってもさ
あんまコミュニケーション上手くいかんくない?
いかないね
それと一緒だと思ってて
まっさらの全く新しい人に
事前情報として使えて
人と一緒だと思ってる
基本的には
人と一緒だよね
上手く動いてくれないときも
自分が悪いっていう
そうそうそうそう
上手く動いてくれないときは
絶対に自分が悪いと思って
それで過去に戻れるっていうのが
AI駆動開発の良さだよね
そうだね
過去に戻った上で
前ちょっとエンジニアと
上手くいかなかった部分を
補足情報として加えて
再度指示をやり直せるみたいな
時をかける少女みたいな
そんな感じじゃん正直
確かに
なんだったら
性格すら指示で何とかできるみたいな
チートだよねそういう意味では
ある意味チートなんで
そういう意味では
過去に戻れるっていうのを
大きく使って
思い込みっていうのは
できるだけ排除して
コンテキストはできるだけ
クリーンな状態を保つっていう
雑面を消してあげるっていう
だいぶなんか
AIへの向き合い方が
ちょっと今日変わった気がしますね
最近の話題
ありがとうございます
頑張ってよろしくお願いします
ありがとうございます
ありがとうございました
本日もAI駆動開発部の
日常をお聞きいただき
ありがとうございました
いかがでしたでしょうか
今回の話題は
安倍さんがね
AIにもっと長期的に
タスクをこなしてほしい
みたいなところから派生して
Windsurfの最近出した
WE1.5のモデルの話であったりとか
デビンがもたらしてくれた
ブレイクスルーについての
雑談みたいなのをお話ししました
もしこのPodcast
気に入ってくれた方は
いいねやフォロー
高評価お願いいたします
それではまた
次回もお楽しみください
バイバイ
