AI導入から半年、開発スタイルの変化
ugo Robotics Radioです。 本日は、ugoのロボティクスエンジニアとプラットフォームエンジニアによる雑談会第2弾です。
前回は、2025年12月末にワイブコーディングについて話をしました。 あれから半年で開発環境も大きく変わったので、その変化について雑談していきたいと思います。
司会は、Ugo株式会社ソフトウェア開発部の横沢です。 そして、雑談会参加メンバーは、前回と同じくプラットフォーム開発部の石川さんとソフトウェア開発部の佐々木さんです。
では、本日もよろしくお願いします。
よろしくお願いします。
前回はですね、ワイブコーディングというところで、これまでGitHubコパイロットとか使ってきていたところがクロードコードに置き換わっていって、かなり任せる量も変わってきたなというふうな実感だったり、
一方で全部任せるのではなくて、あくまで壁打ちというところで、自分の考えの整理にAIを使うというふうな形で、結構その各々の考え方があったかなと思いますが、
あれから半年でかなりAIの精度も上がったりとか便利なツールが出てきて、皆さんの開発スタイルも変わったかと思いますので、その辺をお話しできればと思います。
というところで、まず率直に最近AIをどのようにお二人は活用されていますか?
めちゃくちゃ変わりましたよね、この半年間で。
いやー、コーデックスも5.5が出てきて、前回まだあれですよね、ごっけいが出始めて…
ないかもしれない。
まだないかもしれない。
まだないですね。
そんな。
使い方でいうと、前回の時点で9割くらいはもうAIに欠かしていると言っていました。
でも本当に100パーAIみたいな感じにプラットフォーム側はなってきましたね。
書くのはもうほぼ1行も書いていなくて、読むのはあらかじめ決めたルールでここは読もうみたいなことをやっていますが、コーディングはほぼAIにお任せみたいな感じになっています。
加えてその設計に関してもかなり壁打ちして、一発である程度納得のいく設計が返ってくる割合が増えてきているので、設計でも大いに役立てております。
佐々木さんどうですか?
まず前回からの個人的な差分として、あまりコードをがっつり書くよりもチームメンバーのレビューとかそういった機会が増えました。
その中で前回はどちらかというと開発にAIを使うのを新調派みたいな立場だったと思うんですけど、さすがにもう自分でゼロからコードを書くっていう機会はほぼ0%になったと言えますね。
もうほとんどエディターを開いてコードを書くみたいなことはしてないです。
ただその中でまだコードを読む機会は個人的にはまだ結構残っています。
チームメンバーが出してくれたプルリクエストをレビューするだったり、あと不具合調査のために、まず不具合調査もAIに任せるんですけど、その中で指摘のあった箇所が不具合の基準について、
実際にそれが妥当かどうかっていうのを評価するために自分で読むっていう機会はまだ残っていて、
なので書くことはなくなったけど、読むことはまだ残ってるっていうのが個人的なAIの使い方、現時点でのAIの使い方ですね。
本当に2人とも書かなくなったというか、かなり劇的でしたね、この半年間は。
AIによるレビュー効率化とコード理解の向上
そうですね。もう2月、3月ぐらいの時点でほぼほぼ書かなくなって、その時点で前回の雑談会を自分で聞き返した時にちょっと恥ずかしかったですもんね。
俺結構慎重派だなみたいな。
コードを書くだけじゃなくて、レビューする時のしやすさっていうのも結構変わってきているのかなというふうに個人的には感じています。
もちろんコードも書かせるんですけれども、その結果をサマライズさせる時に、前はテキストベースでサマライズさせていたところが、
だんだんもうマークダウンだけじゃなくて、例えばちょっと移動中でマークダウンも見づらいなというときはPDFにもしといてってやってあげると、
いい感じにマーベードを使って見やすい図にしてくれて、本当簡単な書籍読んでるような気持ちで移動しながらもレビューできるようになったりとか、
そういうふうな扱いやすさも出てきているのかなというふうに個人的には思います。
コード理解のしやすさはだいぶ変わりましたね。
もうまず自分で最初に何かエディター開いてコードを読んでみたいなことはしてなくて、
もう最初にサマライズしてもらって、その内容から特にフォーカスしたい部分だけ読むみたいなスタイルに変わってきましたね。
VS Codeを1日の終わりに、今日VS Code立ち上げてないみたいなのがめちゃくちゃ気が付きます。
そこまでいってます。
基本的にターミナルとマークダウンも最近ビューアーを入れたので、端末で全部完結するようになってきちゃって。
その分、読む量は増えましたよね。
レビューのプルリクの本数とか、単純に1回のコードの量みたいなのが密度と量が増してきたので、
そこをどうやって乗り切るかみたいなのがみんな課題になってるのかなと思いますね。
まさにですね。
私、今プラットフォームの方でやっているのは、さっきも言いましたけど、
読むコードの場所、ちゃんと読むべき場所と、ここはもうある程度お任せしていいよねみたいなのを分けています。
具体的にはADRっていう設計に関する意思決定のドキュメントっていうのを最初に方針を立てるんですけど、
そこはしっかり人間がレビューをして、これで行こうっていうのを任せる。
プラス、今のドメイン駆動設計をやっていて、
ドメインモデルとか重要な設計のパートは見るんですけど、
プレゼンテーションとかインフラストラクチャーとか、個別の実装に寄ってきているところは、
もうテストが通っていれば大丈夫でしょっていう感じで任しちゃってる感じですね。
テストコードとかはどういう観点でテスト書いてくれてるかなとかは読むんですけど、
そんな感じで絞ってますね、見る場所。
設計的にそうやってレビューを重点的にした方がいい部分としなくても良さそうな部分を分けるっていうのはすごい良いアプローチな感じがしますね。
ロボット開発におけるAI活用の課題と展望
だんだんその、でもロボットがやっぱ実機が絡んでくると大変ですよね。
機場レビューで完結しない部分っていうのが人間のどんどん負担になってくるじゃないですか。
そうなんですよね。今私ナビゲーションチームで動いてるんですけど、そこがやっぱり一番のネックで、
コードを読んだだけではレビューしきれない部分、ロボットの実際の振る舞いの部分っていうのがどうしても残ってきて、
そこは一手で確認する必要がまだあって、どんどんシミュレーションに寄せていきたいなと思っているんですけど、
やっぱり最後は実機で確認しなきゃいけない部分が残るので、そこをどれだけ効率化できるかっていうのがちょっとこれからの勝負になってくるかなと思っています。
それこそさっき佐々木さんのおっしゃったように言ったシミュレーションの割合をどれぐらい増やせるかっていうところですよね。
特に自立走行のあたりだと、最終的には確かに実機で動かさなきゃいけないとか障害物があった時の避け方っていうところは、
実機のセンサーのデータを使ったりとか、あとは事故位置ついてがちゃんとできているかっていうところは、
本当にセンサーデータとか周囲の環境に依存するところなので、最終確認はしなきゃいけないんですけれども。
ただ、結構ハードウェアとも離れている領域も多いと思うので、そこら辺をいかにシミュレーションで回していけるかっていうところを考えていきたいですよね。
そうなんですよね。やっぱりさっきおっしゃっていた設計的に重点的にレビューする部分、そうじゃない部分を分けるっていうのは、
すごい私たちのチームでも取り入れたいなと思ったアプローチで、今は1個のプルリクエストの中にプルマイが変わりそうなものとそうじゃないものが
根前一体として来るので、やっぱりどうしてもそれぞれちゃんとチェックしていかなきゃいけないっていうところがあるので、
この変更だったらシミュレーションで十分だな、ここはちゃんと実験を課して評価した方がいいなっていうところを
ちゃんと設計的に分けられれば、かなり効率化できそうだなと今話してて思いました。
AIによる設計議論の活性化と学習曲線
さっきADRの話があったかと思うんですけれども、そういった設計観点っていうのは皆さんチームの中でこういう設計がいいよねとかっていう議論する機会が増えましたか?
そうですね、個別の実装をある程度お任せできているので、より工事の設計どうするかっていうのを議論する機会増えましたね、チーム内で。
チームメンバーが増えてきたっていうのもあるんですけど、そこはいい流れだなと思いますね。
これで面白いのが、こういった中で、それこそさっきのドミンド駆動開発、駆動設計ですかね、であったりとかテスト駆動開発とか、
昔からあるけれども実際にこれできるのかよっていうようなところが、もうそういったコーディングにかける時間的な制約が取っ払われて、
一気にそこが改めて見直されて、そこに対して改めてちゃんとできるようになったっていうところがすごく面白いなって最近思って。
確かにドメイン駆動設計と、あとラストとか、最初の学習曲線が課題になっていたところっていうのが、
AIでポーンと、自分で勉強するでも完全お任せでも乗り越えられるようになったので、
すごい良いですよね、その観点だと楽しい、やっと設計の議論ができるようになってきたなって、実装だけでアップアップしていたのが、
そういう良い中でですよね、すごく。
今まで以上にどういったプロセスで良いものを作っていくかみたいなところにフォーカスできるようになってきた気がしますね。
それこそさっきのラストの学習曲線の話もあったかと思うんですけれども、
その細かい文法のとかっていうところよりも、どちらかというと言語としての設計思想だったりとか、
そこに触れて、じゃあその設計思想に対して適する箇所はどこかとか考えながら作れるようになった気がして、
逆に言うとそこを意識しないで適当にAIに任せたりすると、あまり良い結果を生まないというところもあるので、
我々エンジニアとしてのどこを勉強するかというところも変わってきている印象ですね。
AIレビューの現状と人間による判断の必要性
そうですよね。
ちなみにAIが作ったプルリクをAIにレビューさせてますよね、皆さん。
はい。
そのAIのレビューが通ったプルリクを見る。
その上で弾く割合っていうとどんなもんですかね。
結構もう大体、一発で大丈夫だなってコードが出てくるようになっちゃっていて、
だんだんレビューのザルカーみたいなのを少し気持ちしています。
それで動くコードができているのは良いんですけど、
レビューを通じて我々自身の設計とか実装への理解が深まるみたいな側面が、
ちょっと別のサポートをしないとな、みたいなのは最近感じてますね。
大丈夫なつもりだったんだけど、
意外と仕様ですっぽり抜けている部分があって後で慌てて直すみたいなのも、
例えば社内のプロットとか開発であったりしたので、
そこの抜けを防ぐ上手いやり方がないかなって最近考えています。
そうですよね。
Appleリクエストをレビューしていて、
個々のロジックはもうほとんどというか、
破綻なくAIが作ってくれていて、
なのでそのプルリクエストとしては完結したものが出てくるんですけど、
そもそもそれが我々のビジネスにとって良い方向性なのかどうかっていうところは、
また別な議論としてあると思っていて、
プルリクエストとしてはバグがないけど、
そもそもこのアプローチじゃない方が良さそうみたいなところは、
まだ人間が判断してあげる必要がありそうだなというところで、
そういった観点で弾いているものはいくつかありますね。
これもっとこういう実装の方がいいんじゃないみたいな、
会話はちょこちょこありますね。
それで言うと、その会話をプルリクエスト前にやっちゃうっていうのが結構多いのかなっていう印象が個人的にはあって、
それこそやっぱりちょっと前のAIとかだと作りすぎちゃうというか、
余計なところまですごく高度として書かれていて、
そこの量が多いからその中で本当はいらないっていう部分とかが埋もれてしまったりとかするので、
そこは結局タイミングとしてはどちらでもいいような気はするんですけれども、
自分の体感としてはプルリクが出る前に書かれてきたコードで、
それの時点でもうここはいらないとか、
その時点で設計方針を見直すとかっていうところをやっちゃっていて、
これがベストかというところはさておきなんですけれども。
AI疲れとデジタルデトックスの必要性
確かにそうですよね。
私たちのチームでは解決したい課題とか、
新しく入れたい機能の大きな方向性みたいなのはメンバーと共有していて、
ただそれを解決するため、達成するための具体的な実装みたいなのは今のところメンバーにお任せして、
出てきたものをレビューするっていう流れになっているので、
その実装に取り掛かる前にもう少し会話できると良さそうだなって思いましたね。
ちなみになんですけれども、今AIを使ってバリバリ書いて、
それをめちゃくちゃレビューしていてっていうふうな形になってるかと思うんですけど、
お二人は俗に言うAI疲れとかはしてないですか?
ちょっと同じこと話題に出そうとしてました。
疲れますよね。
疲れますよね。
また個人開発でもコーデックスプログラム契約してやっているので、
常にAIとの会話を考えながら生活をしていて、お風呂入っているときとか。
本当にそうなんですよね。
なかなか頭から離れない。
そうなんですよね。
こっちでレビューを回しつつ、こっちで実装をして、
あと他のチームとの会話みたいなのもこっちでやりつつで、
コンテキストスイッチの頻度が格段に増えたなっていう。
実感がありますね。
並列で回してないともったいないみたいな。
時間使いたいみたいな。
お二人はちなみに今ターミナルでいうとどれぐらい今開きっぱなしにしてますか?
AI活用による趣味開発の充実と学習方法の変化
僕CMAXっていうターミナル使ってるんですけど、
今は8枚あるのかな。
8個のトピックがあって、
それぞれでAIを開いていて会話してるような感じですね。
手元で見たら5並列でしたね。
確かに他の子とMAX8くらいはやってるかもしれない。
ただこの8も今見るとだいぶ会話が止まってるものがあるので、
アンキティブなのはもう少し低くなそう。
ありえないですね、マジで。
8人から詰め寄られてるわけですよね。
ここどうしますか?
この問題にぶち当たりました。
まさにですね。
さっきの要求の擦り合わせみたいなところの話はすごく重要で、
8並列で忙しく見えてもやる必要がない無駄なことを一生懸命やっていたら意味ないわけですよね。
なのでその観点でAIにある程度お任せできてきたので、
要求とかビジネスにちゃんと寄与するかどうかの観点で議論する時間が人同士は増えたっていうのは望ましい流れかなと思います。
そうですね。やっぱりチームである程度方向性、ベクトル合わせられるかっていうところとか、
あとちゃんとビジネスのところまで見据えて何か機能について考えるみたいな、
そういったより上流の部分へのアプローチが必要になってきてますよね。
実装自体はもうほとんどお任せできちゃうので。
疲れるっていうあれに関しては、まじで自分でも信じないですけど、デジタルデトックスをした。
最近?
最近っていうか昨日だわ。
息子と一緒に猪頭公園に昨日、レーザー乗りたいって言ったので、
猪頭線に乗って行って、一日自然に囲まれて。
素晴らしいですね。
スラックは開かずに過ごして、ゆっくりしましたけど。
割と強制的に自分をターミナルから引き離す時間みたいなのは今後ちょっと必要になってくるかもしれないなと。
良かったですよ、デジタルデトックス。
僕ももうあれですよ、ここを週末だいたい1時間ぐらい近所の公園散歩するとかをルーティンに入れだして、
無理にでも自然を感じないといけないとか。
AIの登場によって人間が自然に回帰していく。
それこそ人間ぽいことを週末だけでもしようみたいな。
自分で料理を作ったりとか、パソコンを使わない趣味をするとか。
そうしないと多分、考えがどこかで詰まってしまうのかなという風な。
そうなんですよね。
一応出かける前にコーデックスに最近追加されたゴール機能ですね。
スラッシュゴール。
10時間とか20時間とかかかりそうなタスクをペッて投げておいて、
チャートよろしく、私は出かけてきますって感じで。
良いですね。
任せるで言うと、僕は趣味の開発の方はクロードコードを使っていて、
最近ちょっと前にクロードのアプリでもリモートコントロール機能が付いたので、
自宅に置いているデスクトップPCで作業しているターミナルの状況を
スマートフォンのアプリでウォッチできるし、追加で指示出せるっていうところがあって、
それでやってたんですけれども、やっぱり承認を求められるところとか、
それがあるので定期的にモニタリングをしているとやっぱりお風呂に入っちゃうみたいな。
ちょっとね、生活を伸縮していくみたいな。
コントロールしないとAIに伸縮されてしまうっていうのがありますね。
プライベートの開発で言うと、今までどうしても腰が重くてできてなかったことを
AIによってどんどんできるようになっているっていうところで、
開発の趣味が充実し始めたっていうところが最近の変化として結構ある気がしますね。
どういうものを作ってますか?
ちょっとあまりラジオ向きの話題じゃないかもしれないんですけど、
個人的に競馬予想AIっていう。
当たるもんですか?
当たらないですね。
今までずっと作ってみたいなと思いつつ、
ゼロから勉強してデータも集めてっていうところで、
ちょっとまとまった時間できたらやろうかなって思っていたタスクではあったんですけど、
もう最近AIに任せると最初の初動の部分は一気にやってくれちゃったので、
あとはその細かいチューニングのところを会話しつつ、
あと一回実装してもらって、
後から自分で勉強しながら改良していくっていうプロセスを取り組むことができるようになって、
今までやりたかったこと一つAIのおかげでできたなっていうところで、
最近そこに嬉しさを感じてますね。
確かにそういったところでどうしても足が重いというか腰が重くて動けなかったというところも勝手にやってくれるっていうのはすごい。
そうなんですよね。
勉強の仕方変わりましたよね。
AIにとりあえず調査させて、先にコードを書かせちゃう。
で、書いたものの説明も出力させて、それを読んで、
あ、ふむふむ、こう書けばいいのかみたいな。
そうですそうです、まさに。
今までだと社協で書籍のサンプルコードとか手打ちで打ちながらだんだん覚えていったものが、
そこが大きくスキップされますよね。
思い出したのが、AIはそういった学習スタイルで、
AIによるトラブルシューティング能力の低下懸念
その欠落してしまいそうな情報というか、
多少何かトラブルがあったとしても、
もう自走して全部解決先にしてくれちゃうじゃないですか。
なのでトラブルシューティングするときの何か、
勘というか、この辺が怪しいみたいなセンスを育てる機会ってあんまりないのかなというのがちょっとあるんですよね。
確かに。
その辺ももう全部AIにお任せでいいのかな。
何かトラブルがあったときに、
この辺が多分怪しいから調べておいてみたいなのを、
私はフレームワークとかベースの作りをある程度知っているので指示が出せるんですけど、
それをやらずに今ゼロから始めさせようとすると、
全然でったらめな方向の調査を始めていつまでも終わらないみたいなのはたまにあったりしますね。
一回お願いするとその方向性でどんどん掘り進んでくれちゃうので、
そこの最初のお願いの精度っていうのが大事になってきますよね。
別な個人的なプロジェクトとして、
ちっちゃいロボットを作ってるんですけど、
その中でどうしてもエンコーダーの値が正しく取れないみたいな問題があって、
これってどういうことなのってずっと会話して、
この数値がどうのこうのみたいなずっと会話した挙句、
最終的には回転部に物がぶつかっていてうまく回ってませんでしたみたいなところがあって、
そこってAIに任せてなくても時間はかかる問題だったと思うんですけど、
完全にAI任せだと出てこないところに階があると、
そこにたどり着くまでに結構時間かかるみたいなのがあって、
そういった勘どころは確かにどんどん養うの難しくなっていくなっていう感覚はありますね。
特にそういう個人開発とか、
あと自分の詳しくない領域を勉強しようっていう過程で、
詳しくないところでトラブルがあるととりあえずAIに任せるっていう動きをしてしまって、
結局そういった新しい領域に対して、
勘どころがなかなかつつかめないまま時間だけ過ぎていくっていうのはありますよね。
ありますよね。
AIとの共存とエンジニアとしての成長
一方で、最近自分が今まであまり勉強してなかった数学の分野の書籍を買って、
数式を一つずつAIに読んでもらって説明をしてもらうっていうことをしてるんですけど、
これがめちゃくちゃわかりやすくてですね、
学生時代にこれがあったら勉強めちゃくちゃ効率的に、
俺がもうちょっと頭良くなってたかなみたいないうぐらい役に立っているので、
そういった勘どころっていう部分では難しいけど、
基礎となる学習の部分の役には立つみたいなところで、
使い分け、AIの使い分けみたいなのが大事になってきそうだなっていう気がします。
そうですね。今までの話で、
AIにも完全にお任せでショートカットするべきところと、
自分の知識として蓄えておくべきところって、
見極めをしっかりしてから取り組まないと、
完全にAI依存になっちゃって、
AIがないと何もできない人みたいになっちゃうかもしれないですね。
それがあまり人の働き方とか見ててもわからないから、
チームメンバー的にもちゃんとAI正しく使えてるかっていうか、
難しいですけど、
両方両領を守ってうまくやりましょうみたいなのが大事なんですかね。
本当にそうですね。
我々の組織は中途で入られた方がいて、
別にAIがなかった時でも行動がかけた人の方が割合が多いから、
まだそんなに感じてはいないですけど、
これからジュニアのエンジニアが増えていった時に、
この壁にぶち当たりそうな予感がしててですね。
そうですよね。
例えば何か不具合が起きた時に、
AIにログ渡して状況を説明するけど、
そこからじゃわからない原因だった時に、
ずっとハマり続けるというか、
そこの勘どころはずっと養えないままになっちゃうっていう恐怖がありますよね。
かといって、じゃあAIを使わなきゃいいかというと、
そういう問題でもないような気はしてて、
結局世の中的にはAIで開発するっていうのが大前提になっているので、
だから使いつつうまく勘どころを養える、
そんな良い方法があるといいなとは思うんですけどね。
というわけで本日は、
UGOのエンジニアによる雑談会第2弾を受けしました。
ということで、実は石川さん佐々木さんありがとうございました。
ありがとうございました。
