00:02
こんにちは、AI駆動開発部の日常へようこそ。 このポッドキャストは、日々AI駆動開発を行う企業課の山本とエンジニアの阿部が AI駆動開発のリアルをゆるーく語り合う番組です。
はい、じゃあよろしくお願いします。
よろしくお願いします。
はい、お願いします。
じゃあちょっと今回はですね、AI駆動開発の考え方について、最近ちょっと気づきがあったんで、これちなみに阿部ちゃんにはまだ、阿部ちゃんにもまだしゃべってないという状況なんで、阿部ちゃんもどんな話しされるんだろう。
今日は何も言わずにしゃべるっていう。
ドキドキしてるっていう。
ドキドキしてる?そう。
っていう感じなんで、ちょっとなんかざっくりね、考え方って結構大事だなと思ってて、AI駆動開発をするにあたって。
するにあたって、だからプレイヤーとしての考え方みたいなイメージなんですね。
AI駆動開発というものを行うにあたっての考え方のアップデートみたいなのが結構大事だと思っていて、その上でしかも特に阿部ちゃんみたい、阿部ちゃんとか他のエンジニアの人たちもそうだと思うけど、
もともと開発をやってた人たちの方が、ここの飛行のスイッチみたいなのに苦労するだろうなっていう。
ちょっと一個事例合わせてね、最近気づきがあったんで、どう言い表せばいいのかっていうのが僕の中でちょっとなかったんですけど、ちょっと最近北海道の鶴井村っていうところに行ってきたんですよね。
ちょっと職関連の仕事でね。
そこで羊飼いの、羊牧舎というのか、羊の飼っているところ、羊飼いの方のところ、2軒にお邪魔して生産者訪問に行ったりとか、僕自身も実は昔は蜂蜜を作ったりイチゴを作ったりとかしていたりとかしてっていう感じなんですけど、
その中でAI駆動開発と、まずエンジニアっていうのは今まではどうで、AI駆動開発はどうなのかっていうところのお話ができたと思うんですけど、
エンジニアの今までの職業っていうのは料理人だったと思ってて、やることレベルで。
で、AI駆動開発っていうのは羊飼いとか、農家さんみたいなイメージだなって思っていて、
03:05
これは若干小流的な話じゃなくて、やってることそのものの話です、前提としてね。小流の話ではないですって感じなんですけど、
何が違うかというと、料理人っていうのは自分がやりたい、やらなければいけない具体の料理層があって、それに対して必要な調理器具であったりとか、
素材を集めてきて、自分の技術とかを使って組み上げていって、最終的なアウトプットに持っていくっていうものじゃないですか。
そうですよね。
で、一方で農家さんとか、あ、どうぞ。
多分両方聞いてからコメントもらった方がわかりやすいかもしれない。
一方で羊飼いとか農家、養蜂とかもイメージつきやすいかもしれないけど、
例えば養蜂が結構わかりやすいかな。蜜蜂が蜜を集めてくれるんですよね。
で、蜜蜂がどういうふうな蜜蜂たちにとっていい環境を提供してあげると、いい蜜が作れるのかっていうのを考えて、
その実際の品質は、農家側というか人間側は直接は触れられないんですよね。
羊飼いとかもそうで、この羊がいいお肉に育つためには、どういう牧草があって、どういう環境があって、
どういうふうな異色獣みたいなのを与えたらいいお肉とかになるのか、いい養乳ができるのかみたいなことは考えて、
飼い人はするんだけど、あくまでもそのものを作るのは羊さんであったりとか、蜜蜂さんであったりとかみたいな感じ。
なるほどね。
そう、直接手は加えられないっていう限定条件の下、品質をどう上げるかっていうのを考え続けるのが農家さんとか一時停止者の方みたいな。
うんうん。
で、料理人は自分の技術を使って、どう品質の高いものを作っていくかみたいなのを考える。
確かにそれは、なんかいい例というか、言い得てみような気がしますね。
僕もエンジニアとしてやってる場合は、クライアントからこういう要求とか、社内でこういうものを作りたいっていうのからスタートして、
そこに合うパーツ、要はフレームワークだったり、言語だったり、あとはそれを実際に作る上で必要なエディターが何がいいとか、
そういうのを考えたりとか、あとはそれに対してどういうふうに実装するかっていう設計レベルの話を細々考えて、
06:02
一個一個積み木を組み上げて、一つのお城を作るみたいな作業を多分すると思うんですよね。
多分料理人もそうで、こういう料理を作りたい。
自分の使うツールはどうかとかね、包丁はどうかとか。
包丁、鍋が、鍋が今回何人分作るから何リットル用の鍋とかっていうのも、自分で考えて作るわけですよね。
ところが羊飼いとかそういう例で考えると、正直もうコントロールができないと。
羊さんに5リットル今日作ってくださいみたいな。
しかもいい、こういう系のこういうおいしい料理を出してほしいみたいなとかって言えないわけですよね。
はいはいはい。
AIも確かに細かく、要は今僕たちがAI開発をするっていうのにも多分2つあって、
エンジニアの人たちが自分の手足となってもうコントロールできる範疇の中でパフォーマンスを最大化していく。
これも一つ開発のスピードを上げるっていう意味では非常にありはありなんですけど。
一方でもっとこう、AIって機械なんで人間みたいに休む必要もなくて、
20時間行動生成できるっていうような前提に立った時に、
まさにこれは自然と一緒で、自然発生的に物生産されていくっていう仕組みを作ることが重要なのかな。
だからAI自動開発みたいな文脈が生まれてきているんじゃないかな、確かにそう。
そうした時に、やっぱりこれが難しいのが、
AI駆動開発においては人間が蜂蜜を作る蜜鉢の役目も果たせるし、
蜜鉢の巣をね、巣っていうかな、板を挟んで板の環境を良くする方、
いわゆる用法でいうところの人側にも立てるしっていう2つが混在しているから、
頭の切り替えが結構難しいみたいなのがあるのかなっていう。
逆に言うと、一時生産者の方々はもう割り切れるじゃん、できないからある意味。
そうですね。
そうそうそうそう。だから割り切ってるっていうのが前提としてあるし、
多分科学的にというか、ある程度ハックされている部分が今までこれまでの研究の積み重ねで、
こういう風な型があるよねみたいな、PDCA回しづらい分余計で、
もう研究され尽くしているものをやるっていう前提があるから、
そこの勉強に時間を使ったりとかっていうのを多分していくみたいなのがあるんですけど、
09:00
AI駆動開発においては自分が介入できるし、たぶん農家さんとかも自分が介入できるようになればしたいよね。
まあそうだよね。
うんうん。
今この作業をちょっとやるだけで味が数段良くなるとか思ったら触っちゃうよね、たぶん。
そうそうそうそう。
だからそれができないがゆえに諦めて環境整備に逆に注力できてるみたいなのは、
まあその仕組み上そうなりやすいみたいなのはあるけど、
なんかAI駆動開発も結局人が手を入れるっていう判断をしたらそこがボトルネックになってくるから、
どんだけこう環境づくりをしっかりしてあげて、
常に品質の高い、自分たちでも説明責任を博多せるものの品質で、
そのAIの環境を構築しきるかみたいなのがたぶん今肝になってて。
確かに。
だからこそ僕らもだから、その、まあエージェントAMDとかまあ細かい話ではなってしまうんですけど、
AIが起動してから調査して何かこうタスクを完遂するまでの環境っていうのを整えてあげるっていうのは、
まさにやっているところ、工夫しているところはあったりすると思ってて、
例えばそれが今言ったエージェントAMDに細かくある程度ルールを書いておくとか、
スキルとかね。
そういう文脈として環境を作ってあげて、AIにどうやって知識を投入して、
だからAIがその自然な流れとして、なんか行き着く先が正しい実装にあるように、
まあいろいろ工夫とかしてるけど、まさにそれが用法で言うところの、なんだろう、箱の位置を変えてあげるとか、
なんかそういう話。
だからコンテキストエンジニアリングは、実はエンバイラメントエンジニアリングに内包されている、
位置機能の一つに過ぎないって思った方が、環境整備なわけじゃなくて、
イチゴがどう飛ばすかっていうののためにハウス栽培しようかみたいなとか、
けどイチゴの生育には直接的には手をかけれないから、みたいなことをするわけでハウス栽培しようとか、
じゃあ土に設置しすぎたら菌が来て病気になりやすいからあげとこうみたいなとか、
効率化も含めて全部考えてやると思うけど、だから基本的にはAIを取り囲う環境をエンジニアリングしていくみたいな、
エンバイラメントエンジニアリングみたいな一環の中に、その中でコンテキストエンジニアリング、
コンテキストがうまく渡らないよねっていうのが今AI開発上では課題として顕在化してるから、
みんなコンテキストエンジニアリングをしてるから、そこが完全になったら次のまた課題が出てきて、
12:05
それは勝手に環境の整備であるっていう。
その呼び方すごくいいな、コンテキストエンジニアリングってつまりはAIが動くための判断材料とか知識を与えるものだと思ってて、
エンバイラメントエンジニアリングにすると多分何か問題が起きたものをAIに知らせる、
今だとLinearとかが問題を見つけたらIssueを自動で発行してくれるとか、いろいろそういうのもできてきてるけど、
そことか、あとはレビューとかですね、GitHubとかにPR、プルリクエスト投げたらレビューが自動で回るサイクルを作るとか、
そこも包括してAIが自律的に改善を進められていく環境を整えるっていう意味では、
コンテキストエンジニアリングの枠を超えてエンバイラメントエンジニアリングみたいな概念っていうのが確かにすごくしっくりくる。
しっくりくるよね。
そうそう。っていうのをね、なんかちょっと羊深井のところに訪問したり。
北海道に行ってそんなこと考えてたんですか。
そっか。そうだなと思って。
だから、AI駆動開発でやった時に、AIに完全に任せるっていうのは若干違和感を感じてたんですね。
AIにもっと任せなよっていう一方で、完全に任せるのは違うなっていう頭が僕の中にもあって。
それは環境整備、生産物、最終的な生産物、羊飼いだったら養肉、養乳っていう生産物に対して、人は説明責任を取らないといけない。
AI駆動開発でいうと、そこに出来上がった行動をこれAIが勝手にやったからっつって、それで責任放棄にはならないわけで。
そうした時に、任せれる環境をどう整備していくかみたいなのを考えて、考えた結果任せれるようにならないといけないみたいなのが本質なのかな。
任せないといけないじゃなくて、任されるようにならないといけないみたいなのが本質なのかな。
環境をデザインした結果、なんでそういう成果物になるのかっていうのは、農家さんとかも、例えばこの羊のミルクがなんでこんなにまろやかなのかっていうのは結構説明できる。
土壌が違いますよとか、餌が違いますよとか、ストレスがいっぱいあって。
いい養乳を作るためにハーブセラピーとかやってたりするよね。
そうなんだ。ハーブセラピー。羊にハーブ食べさせるの?
15:00
食べさせるのも言ってたかな。食べさせるの。ちょっと混ぜ込んでみたいなとか。ちょっと調子悪そうなやつがいたら、そういうふうに食べさせてみたいとか。
なるほどね。でもあれですよね。今までAIとコーディングをやるって機械にさせてるのが、僕の1年ぐらい前の感覚だったんですけど、より最近体感を得てるのは生き物と対峙してる感じ?
そっちのほうが自然よね。生き物と対峙して、生き物の振る舞いってこういうふうに言ったらこうなるかもしれないとかを見ながらやる。
山ちゃんもよく人間の世界に当てはめて考えるとAIってこうだよねみたいな。よく言ってた話も多分それと近いというか、それのまさにベースになってるのかなと思って。
じゃあそのAIの振る舞いっていうのが人間の社会に落とし込んだ時に、まさに今言ってたようにこう言ったらこう振る舞うよねみたいなのをとにかく溜め込んだりして、じゃあそういうのに対してどうアジャストするかっていう話になってくる。
自分の思う通りにAIが自然といくように導く環境づくりを通していくかみたいな感じの。
まあ確かに。まあでもね、一方でこう今ね、主戦、実際にこう企業とかでエンジニアリングをしているITエンジニアの人たちっていうのは、やっぱその環境をデザインするのにある程度の制約を受けていたりするというのもまあ多分ギャップがあって。
アジレマってね。
そうそうそう。例えばそれこそクロードを使う、クロードコードを使う一つにとってもパーミッションをクロードに全渡しできないよねみたいな。結構ガチガチでやらなきゃいけないよねとか。
まあなんかそういうのもあって、なかなかそこにスイッチする。マインドとしてもそうだし。結局制約があるとAIってその認知できる幅、それはどっちかっていうとコンテキストエンジニアリングっぽい話なんだけど。
例えば本番のデータベースとかテスト環境のデータベースにAIがアクセスできないとなると、やっぱりこの判断の質っていうのは低下するし。だからそういうところでAIを使っていると、どうしてもAIってそんなに性能としては良くない感覚を得てしまうと思うんですよね。
だからやっぱなんかエンジニア一つとっても環境でどれだけ性能がAIが出せるかどうかも認知っていうのが結構ギャップありそうだなっていうのは。
それはそうだと思う。モデル一つとってもそうだし、情報にアクセスできるみたいなのもそうだし、なんか試しにやってみようみたいな質問がオープンクエスチョンだったら、多分正しい答えは返ってこないというか、みたいな感じになって微妙みたいな感じになるし。
18:13
だからその時に一番初めのファーストインプレッションで依頼した物事によっても、多分評価が揺らぐから結構難しいところはあるし。
やっぱり今まで自分たちで蜂蜜を生成できてたところからAIに完全に任せるみたいな感じの頭の切り替えみたいなところも結構難しいところもあるよね。
本当に難しい。見てしまうし止めてしまいますからね、僕も。
AIがちょっとでも違うなって動きをしてた時に、いやそれ違うんじゃないの?って言ってしまう。
最近はそれは違うんじゃないのもそうだけど、じゃあなんでそれが間違った判断したのかなっていうのに立ち返って、じゃあそれを先回りしてそういうミスをしないような策を講じていこうっていうのは、AIを使う上では重要であるんですけど。
そういうふうに振る舞うように僕自身も気をつけてはいるんですけど、やっぱりエンジニアとして一定の制約がある中でやってるとどうしても料理人の振る舞いというか。
確実に美味しい料理を作らないといけないっていう限定の上で。
だから社会の認識とそのものが変わらないといけないんだなっていうのも一個あるね。
自然現象なんだと捉えて、その環境には介入できない、むしろ変われないぐらいの方がそっちの方に寄せれるというか、自分の削く頭を。
確かにそうですね。あとはあれですよね、今話してた制約があるっていうのを多分セキュリティとか権限をどう渡すかって話だと思うんですけど、そこをAIが触ってもいい環境づくりっていうのをまた考えていく。
それはそれとして考えて、それをベースとしたエンバイラメントエンジニアリングをしていくっていうのを多分やっていくべきなんでしょうね、きっと。
それは環境変数を除いても全然問題なくするように、環境変数は例えば全く影響が出ないものを用意してあげるとか、ローテーションをするとかいろいろあると思う。
細かい話で言えばあると思うんですけど、そこからだったり、あとはそこに対して技術的な進歩が多分今後起こってきそうですよね。
21:03
どうやってサンドボックスの環境を作ってあげるか。
でもエンジニアの人たちは多分結構そのジレンマで戦っている気がしますね。
戦っているよね、絶対。
戦っているし、場合によってはもうやっぱ人間じゃないと無理なんじゃないかって思っている人もまだまだいるんだろうなって感じますね、実際に。
そんな気づきがあったんで話したらなと思って話しましたって感じですね。
最近だとUI UXのレビューをしてくれるみたいなスキルを裏でちょこちょこ作ってたりとかして。
そうなんですか。
そういう自分ではできないことをできるようになっていくと、もっと任せやすい。
だから自分よりも品質が低いと思っているよね、たぶん。
自分たちがやっぱ品質が高い状態まで持っていけるポテンシャルはAIにはもうすでにあると思うから、それを引き出してこれ自分じゃ作れねえわみたいなやつを常に出せるような環境作りみたいなのをしていけるとかなり強いんだろうなっていう。
効率化のアイテムとして考えない方がいいんだなっていうのが最近の学びかな。
キーワード選定とかもさ、うちの社内のメンバーで記事のキーワードをいろいろ頑張って考えてもらってみたいなのをしてもらってたんですけど、なんでAI使わないんですかみたいな話を僕がして。
これは効率化した方がいいからAIでうまくできるようにしてくださいってお願いして。
そのお願いしたタイミングでは効率化のためのお願いだったんですけど、最終的に出来上がったものっていうのはその非エンジニアのメンバーがやってなかったような手法をとって、さらに高精度なキーワードを選び抜くっていうようなものを作ってきたんですよね。
そうなんだ。
効率化じゃないよね。レベルを上げたみたいな感じになってて。
レベルを上げるアイテムとして使っていくっていうのが結構一つ。
確かにな。
AIを使うことによって、人間って結局認知の幅に限界があるし、あとは体力的な、考え抜く体力も限界があるし、あとは普通に判断ミスをするっていう前提があって。
24:03
そう考えると、じゃあどう考えると考え抜くといいのかみたいなのをAIに適切に渡しさえすれば、より人間よりも数段レベルの高い品質のものが、多分その道中ではもちろん人間よりも劣化した品質になることもあると思うけど、ちゃんとそこを磨けば出てくるみたいな。
そういう話なのかな。
まあ、そうな気がする。
そうっていうところが結構大事なところなのかなって。
考え方の違いとしてね、そもそも自分のやってることを自分と同じレベルで効率化しようと思わない方がいいという。
むしろ自分の知らない知識を調査したりとか、むしろAIがすでに学習していて持っていて、それを携えて自分の今のこのやりたいこと、目的を格上げしてくれる存在として、しかもさらに効率的になるみたいな。
存在として上手く使っていく方がAI活用って進みそうだなって。効率化だけだと面倒くさいじゃん。
はいはい、まあそうだね。
いやでもこれ結構難しいのが、多分聞いてる人も本当かなと思ってる気がするんですけど、やっぱなんかAIって本当にピンキリというか、そのAIを使ってめっちゃいいアウトプットが出るときと、
自分でじゃあ、例えばだけど、クロードのコワークとか使ってパワポを生成しましたって言ったときに、めちゃくちゃパワポの生成の精度が高いというか、いいパワポがアウトプットに出てくるじゃないですか。
あれっていうのはそんなに努力しなくても、ちょっとこうAIに効率化の一環でパワポイントを作らせてましょうという気持ちでやってみると、すごくいいものができました。
じゃあこの期待値で、じゃあ他の作業もAIに任せようと思ってやってみるじゃないですか。
それが例えば、それこそキーワードの記事選定とかもそうだと思うし、コードの生成とかもそうだと思うんですけど、自分でそうやってトリックモードすると、めっちゃしょぼいアウトプットが序盤出がちだと思うんですよね。
僕は結構そこで、ダメじゃんみたいな。他の事例とかでパッと夢は見たりするんですけど、実際自分の業務とかでやってみると、それは上手く使いこなせてないとか、それは使ってるモデルが無料でやってるからとかいろいろあると思うんですけど、
そんなに精度じゃなくて、そこに向き合って精度を上げていくっていう取り組みをインセンティブ的に得られないというか。
27:04
なるほどね。結構だるいし、大変だし。
そうそう。だからこそ、やってよし、自分にはできなかったパフォーマンスの高いAIの活用ができたまでたどり着くのに、結構遠かったりして挫折する人も多いんじゃないかなみたいな。
なるほど、確かに。マインドセットが問題なのかな。
なんか、僕はAIがちゃんと動かなかったら、もう僕のせいだと思ってるんですよね。
だからAIがちゃんと動くまではできるはずだっていう前提を持ってやってるっていう、そこがちょっとでも不信感があると、多分行き詰まるというか、やんなくなる。
だから、僕はもう圧倒的に自分よりもAIのほうが優秀だと思ってるんですよ。もう真相こそ思ってるんですけど。
最近、うちの社内のメンバーと喋ってて、実は最近まで僕がこんなにAIは僕よりも頭いいし、すごいみたいな言ってるけど、言っても人間より頭悪いっしょって思ってたって言ってて。
あー、そうなんだ。
そこの信じてるかどうかの差は結構ありそうだなっていう。
自分より頭いいやつができないってなったら、もう自分の伝え方が悪い以外の改善策は見当たらんわけでさ。
そうだね。
けどちょっとでも自分のほうが頭いいと思ってたら、やっぱ自分にしかできないものなのかって思って、いつも通り自分でやるみたいなことに戻っていくみたいな感じで。
そうなんですよ。だからそこの、まさにそうだね。マインド変えていかないと、結局自分でやっちゃうに戻るんですよね。
それで言うと多分、養乳を作るとかは羊にしかできないから、人間は割り切ってできるとかやっていくわけですよね。
確かにね。
だから非エンジニアだった人のほうが多分AI活用はやるんですけど、非エンジニアの人はそこの環境整備の仕方が、羊に例えると、養乳を作ったことないのに環境整備なんかどうしたらいいんだみたいな状態に陥ってるんだけど、
エンジニアの人は自分でも養乳を作ったことがあるから、そのHowみたいなところを知ってるから、より高度に環境整備ができるはずだという期待値を持って、
僕とか非エンジニアの人は多分エンジニアの人に環境整備を依頼するみたいなポーズが多分生まれると思うけど、
30:00
けど、エンジニアの人は自分でやったほうが早いし、自分でやったほうが高精度だから、なかなかそこまではいかないみたいな感じになって、ここでもちょっとジレンマが生まれるみたいな。
みたいなのはあるのかもしれないね。
多分エンジニアとして養乳の話をされたら、工場で自分が化学的に生成したほうが美味しくて高品質なものが作れるみたいな、例えば考えて、
でもそれって自分が手を動かして実験室で合成してないと美味しいのはできなくて、でもそれを一歩引いて動物にやらせるだけで24時間も生成されてるよねみたいなところまでやっぱ、
なかなか生きにくいっていうところがある。一方でやっぱそれをやらないとスループット、トータルではスループットは多分AIにやらせるのが圧倒的に高いという前提。
かつ、今のヤマチャンの話もそうだけど、AIのほうが人間よりも頭がいいベースに立ったときにスループットも24時間動かせて高い、
人間よりも頭がいいっていうのであれば、もうAIに全部やらせる前提でどう環境をやったらいいのか考えなきゃいけないっていうのは本当にそうで、
そこにどう自分がマインドとして追いついていくかだとかなーみたいな気持ちはありますね。
おだしょー まあそうやね。科学的に乳を作るみたいなんで言うと、おそらく人々が求める養乳の味とは違うから、そもそも違うから違うなーとか思いながらっていうのと、
ちょっと多分なんかそのちょっと俺がその農家さんとかそういう話を出したけど、環境というか自然物を取り扱うっていうイメージでAIと対峙したほうがむしろ自然なのかもしれないということを言いたい。
だから養乳を、羊に養乳を、まあそれは養乳って言うから羊から出てくるんだけど、超効率的かと言われると、効率じゃないよね多分。
羊飼いの人が羊に乳を出してもらうっていう行為は効率ではなくて、羊から出る乳が、例えば好きで、そこからしかもさらに出来上がるチーズっていうものが好きでやってるみたいな感じだから、だから効率とはちょっと似て非なるもの。
外部化して、工場とかみたいに生産を外部化してるって感覚じゃなくて、そこでしか出ない味を作ってるみたいな感覚があると思うけど、なんかそういう感覚までいかないといけないのかなみたいなちょっと思った。
33:03
今のアメちゃんの話を聞いて余計思ったかもしれない。単なる効率化じゃないなって思って。
だから外部化って捉えると、外部化、外注する先と捉えると、アメちゃんの言ってた合成して乳っぽいものを作るみたいなとかで、より効率的にみたいな話だけど、なんかそもそも効率じゃなくて、AIにこういう環境を用意したものでやってもらうと、より高品質で自分の求めるものが出てくるっていう状況をいかに作るかみたいな。
こっちの頭でやってる方が心理に近づきそうだなって。
効率化じゃないって感じかな。
なんかだから、自然の生性別であるからこそ、さっき言った羊の乳であるからこその良さみたいなのが、たぶんある種、ブランドにもなるというか。
って考えると、環境でもってそういう良さを引き出すっていうのが、要入をしている人たちのやってることで、AIとの向き合い方も、なんかAIにやらせるからの良さみたいなのをどう引き出すかっていうのを考えるべきなんじゃないかっていうようなイメージなのかな。
単なる効率化で、自分が今までやってきたことを効率化するっていう頭じゃちょっと足りないのかなって。
なんか若干自分の中でも一個ジレンマというか、確かにそれはそうなんだが、システム開発って割ともう既にあるようなパターンとかをたすらどう組み合わせるかとか、どう標準的な仕様に乗せるか。
それは例えばJOTトークンとかOOSみたいな業界標準とされた仕様にどう乗せるかみたいな話もあったりして、そうなるとどっちかっていうとパターン、効率化というか、そのパターンにどう当てはめるかみたいなことを細かく考えがちではあるかなって。
なんか味の、どうAIの良さを引き出すかみたいな。ちょっとレイヤーが、なんか僕は今まだごちゃごちゃしてるんだろうなっていうのを聞いてて感じなのかな逆に。
俺もまだちょっとごちゃごちゃしてるんだけど、たぶんこのAI活用っていうのは、AI駆動開発、システム開発という文脈においてもそうだし、仕様書作りっていうところに落ちるとまたちょっと違うかもしれないし、デザイン作りとか文章を作るとか、いろんな使う文脈によって全然違うから。
今ちょっと全部ひっくるめて話しちゃったから、ちょっとごちゃごちゃしちゃってるかもしれないけど。
まあけどとはいえ、自然物として取り扱うみたいな視点でやっていくのが、もちろん介入が可能なんで、システム開発はもともと人がやってきたものなんで、介入が可能なんで、そことのバランスをどう取っていくかみたいなのが結構重要な視点になってきそうだなって。
36:19
特にAIに預けられきれないみたいな思ってるエンジニアの人がいたら、そういう視点を持つと1個ブレイクするおきそうかなって思ったっていうので、ちょっと話してみたかったなって思ったって感じですね。
はい、いやでもすごく鍵となるようなマインドだと思いますよ、この環境エンジニアリングするっていうのは。もちろんシステム開発ってセンサー判別で、そういうAIのエラーを許容できるようなシステムもあれば、絶対にもう想定通りに動かなきゃもう大混乱のもとになるみたいなのもあるので、
すべてがすべて適用できるわけではないような気もするんですけど、けどAIを使ってどう今後開発を推し進めていくかって一つのマインドになりそうですよね。
そんな感じでした。羊農家さんのお話でした。
じゃあこんなもんすかね。
はい。
じゃあ本日もありがとうございました。
ありがとうございました。
本日もAI駆動開発部の日常をお聞きいただきありがとうございました。今回はですね、AI駆動開発をする上での考え方みたいなところにちょっと少し気づきがあったので、それのシェアとして取らせていただきました。いかがでしたでしょうか。
もしこのポッドキャスト気に入ってくれた方は、いいねやフォロー、高評価ぜひお願いいたします。それではまた次回もお楽しみください。バイバイ。
