00:01
こんにちは、シニアソフトウェアエンジニアのriddleです。 こんにちは、ミドルソフトウェアエンジニアのひびのです。
このポッドキャストでは、僕たち2人でいろいろなことを話して、IT業界に関するリアルを届けていこうという趣旨の番組です。
今日のテーマが、開発現場でのAIのユースケース、2026年1月編。
ユースケースというか、使い方ですね。どう使っているんだろう、この人たちは、というのを聞きたいということですね。
どう使ってますか。僕、ちょっと気になってて。というのも、いざ考えてみると、ここ半年くらいはそんなに変わってないなっていう印象なんですよ。
いや、そもそもですね、私はAIとかほぼ使えない環境にいるので。
なんだと?
AIは壁打ち相談相手と、ちょっとしたコードの生成に使っていて、別にそれを商用のプロダクトコードに組み込んだりをしているわけではないので、
昔の古き良きコーディングの、自分で書くっていうのをやってますよ。
大変そうだ。
いや、もちろん、全然大変じゃなくて、こういうことをやりたいけどっていう相談相手としては使うんで、いろいろ意見をもらいながら、
なるほど、みたいな感じで、いまだにコードをちゃんと手で書いてます。
なんで、だいぶ多分世間の先頭を走っているコーディングエージェント側みたいな世界観とは離れてるんで、
ちょっとね、そこにくっついていってる人はどんな感じなのかなっていうのを聞きたいという感じですね。
おお、なるほど。
それで言うとさっき言ったように個人的には半年くらいはそんなに動きがないなっていう印象なんですよね、本当に。
もちろん半年の中であれですかね、Googleのアンチグラビティとか、なんか新しいAIを使う製品はいろいろ出てきたはずなんですが、
基本的にはコード書くときはクロードコードかDebianを使い、何か相談したいときとか、いろいろなテキストとテキストの相談ごとがChatGPTかGeminiを使い、みたいなところですかね。
ちなみに、
ちょっと一回まず整理したいんですけど、
はい。
何か機能を作る。
今、ひめのさんは商用というか普通にサービスをリリースしててアプリをリリースしてると思うんですけど、
そこの機能改善とかをしてますよね。
はい。
で、そこの機能追加とか改善をする際に、
例えばですけど、10仕事があったとして、その10の内訳をちょっと聞きたいんですけど、
最初にだからいわゆる仕様とかが検討とか決まるフェーズがありましたよね。
03:01
で、そこから設計して実装してQAしてリリースみたいな一般的な流れが。
なるほど。
それで言うと、ちょっと違っていて、僕の今働いてるチームだと大体なんだろう、それだけでは実装できないようなふわっとした仕様がまず降りてきます。
で、僕はそれを見て、細かいところ、ここをこうやって実装しますけどいいですかをまとめて投げて、それでOKを得たら、実際にシステムを作るための設計に取り掛かる。
なので、まず仕様が降りてくるっていうよりは、仕様と自分が戦うところがあるっていう感じですね。
はいはい。そこはもう多少ちょっとAIのヘルプがあるけど、基本的には人間が頑張るところですよね。
そうですね。AIが入り込む余地があるとしたら、例えばまだ使ったことがないAPIとか、まだ使ったことがない、例えばiOSのこういうところの仕様みたいなのが含まれてそうだったら、
チャットGPTに聞くとか、そういうところでは活躍してもらってますね。
で、そこである程度仕様が確定し、実際にプログラムの設計みたいなところに入ると思うんですけど、
そこは今って、さっきデビンとかクロードコードってありましたけど、いきなり動かす感じなんですか?
まず仕様を何かスペックドリブンだったらテキストにまとめるとか起こすとか、イシューにするとか。
そしてそれは誰がやるのかみたいな。
はいはいはい。まあ誰がやるのかに関して言えば、僕のところに降りてきた開発の依頼は基本的にはもうリリースまで僕が面倒見ます。
その上でタスクの流度による気がするな、なんか例えば、中規模大規模って言うとあれだけど、
本当に全く何もないところから新しい機能を作りますとかだったら、まずGitHubのイシューを作り、
で、そこから少し自分の頭を動かして、こういう小タスクに分解できそうだなみたいなのを画像書きしていき、
そうだな。で、まあそこで何だろう、いわゆる大まかな設計は終わったっていう理解でまずいいですよね。
で、何だろう、僕はあんまりこの辺りの用語詳しくないんですけど、SIRでいうところの詳細設計みたいなところは僕はなんか書きながらやることが多くて。
そこはもう人力でやるんですか?AIじゃなくて。
僕が詳細決まってないなと思っているものは、手元のVSコードでAIと壁打ちしながら詳細を詰めていって、
06:08
じゃあそれで書いていきましょうっていうことを指示して、AIにまず最初書かせます。
で、何かいわゆる何だろう、開発の中で発生するルーティンワークだったりとか、明らかにもうこれは誰に指示してもできるみたいな、
例えばまずこのライブラリインストールしておいてとか、そういうのはもう全部Devinに投げてますね。
えっと、じゃあまずイシュー作ります。で、そのコタスクみたいなのをサブイシューにする。
で、その中に設計をそれぞれのタスクごとに書いていくってところはAIと協力しながらやる。
で、そのイシューができたら、そのイシュー1個1個を自分がやるのか、DevinとかCloud Coreとかに投げるみたいなイメージですかね。
そうですね。はい。
これって今、Devinの、今の自分が知ってるDevinと今も同じかわかんないんですけど、なんかDevinって昔はイシューの番号とか渡したら、
あとは勝手にプルリク作って直したりとかしてくれるやつ。
そうですね。
かつそれがクラウドで動いてるみたいな感じだと思うんですけど。
はい。
ちなみに、最近って単一のことをやるエージェントだけじゃなくて、エージェントを複数操るエージェントみたいなのもいるし、作ろうと思えば作れるじゃないですか。
そうですね。特にクラウドだったりとか、オープンAIのコーデックスとかはそういう設定ができるらしいですね。
じゃあ、例えばさっきの話で言うと、大きなタスクを分解して、今タスクが定義できたと思うんですけど、
その大きなタスクを管理するオーケストレーター的なエージェントを用意して、それ以降はサブイシューはそのオーケストレーターが適当にエージェントを起動して、
サブイシュー単位にエージェントを割り当てて動かすみたいな、そういうところまではまだ言ってない。
僕の手元では言ってないですね。ただ確かに言われてみると、いわゆるサブエージェントみたいなものをたくさん動かすものをメインのエージェントにやらせる、
自分は基本的にメインのエージェントにしか指示しない、みたいな開発スタイルをやってる人はいそうというか、なんか見たことある気がしますね。
ちなみに、じゃあやってなくて個別にやってる端子だと思うんですけど、個別のサブイシューを取り組む場合はほとんどがAIですか?
そうですね。ほとんどAIですね。CっていうならAIに書かせて、なんならテストも書かせて、
09:01
テストで無駄なところをガッツリ削ったりするとか、僕手動でやるとか、そういう意味ではAIが生成したコードを読んでる時間のほうが圧倒的に長いですね。
Devinを使うか、ロードコードを使うかっていうのはどういう区分けで分けてるんですか?
それでいうと、僕今作ってるサービスがモバイルアプリとサーバーがあって、モバイルアプリフラッターなんですけど、自分の手で動作確認してからプルリク出したやつはまず自分の手でやりますね。
手でやるっていうのはローカルのクロードコードを使ってシミュレーターで動作確認してから出せるようにっていう感じですね。
本当に、例えばサーバーの中でもここのテスト通ればOKみたいなタスクはもうDevinに投げるだけ投げて、ちょっと放棄しておくみたいな感じですね。
なるほど。だからどこまで確認しないといけないのかによって使い分けているっていうだけで、本質的に性能差があるというよりかは、手元であるほうがより確認しやすいからそっち使ってるというか。
そうですね。僕は現時点においては完全にそうかなと思ってます。というのも何というか、最近のDevin賢いんですよ。
確か今のDevinってクロードソネット、クロード4.5ソネットとか載ってるんじゃなかったっけ。
手元でクロードコードを動かすときと同じモデルが載ってるはずだから、僕は性能差はないと思ってます。インターフェースの違いだけ。
例えばですけど、Devinが動かしてフラッターコードを直します。そのフラッターの実行環境も含めて提供してくれていて、
例えばウェブブラウザ経由でそこの実行環境にアクセスできて、そのDevinが作業したプリクラ内容がフラッターのランタイム、
ダートのランタイム経由で普通に動いてることが見えますみたいなところまで行ってれば別にローカルでやる必要もなくなるってことですよね。
そうですね。例えばいわゆるフラッターオンザウェブとかでウェブにビルドしてデプロイまでしてくれるまでをDevinがやってくれるとしたらっていう話ですよね。
そうですね。フラッターオンザウェブじゃなかったとしても何かしら仮想マシンみたいなの用意されてて、そこに繋ぐだけでフラッターの実行環境を用意されてて、普通に見えるみたいな。
そうだな、例えばウェブで動いてプラットフォーム特有の機能を使うとか、そういうものはもちろん手元で見たい気持ちはあるし、
12:11
とかはあるが、本当に依頼するタスクによるかなとは思いますね、現状は。
結局モバイルの制約に引きずられてますねってことは。これが例えばウェブアプリ開発だったら、ウェブアプリなんて別にポート番号変えればいくらでも平行に起動できるじゃないですか。
そうですね。あと何ならタスクごとにサブドメインキルとかやればできそうですもんね。
そうだ。そうなるとすごい確認も簡単だけど、モバイルアプリになるとほとんどIDで起動したら1IDで1個しか起動できないだろうし、エミュレーターって基本的には。
特に現にそれはありそうですね。僕はそれこそ最近はウェブフロントエンドを扱うことそんなにないですけど、なんだろう、AIが書いたコードのリフト、あとそれから実際にブラウザで動作確認できれば、それで自信を持って出せそうな気がしますね。
モバイルアプリだけちょっと今はなんだろう、制約が厳しくてそうなってるけど、もし日比野さんがウェブフロントエンドおよびバックエンドの開発に閉じるのであれば、もしかしたらほぼDevynに寄せたって問題ないかもしれないですね。
確かにね。
同格祭なんかこういい感じにできるんだな。
そうだよね。おっしゃる通りだ。
ちなみにDevynで作りましたっていうプルリクはもうGitHubにプルリクが作られるじゃないですか。その時点で初めてレビューって感じなんですか。
そうですね。DevynについてはDevynのダッシュボード、ウェブのインターフェースもあるわけなんですけど、基本的にDevynが開発した成果物を見られるのはプルリクの方が見やすいっていうところはありますね。
そこで大きく修正してほしいみたいなのはGitHubのコメントベースで依頼するって感じですか。
自分でも直したりするんですか、ID開いて。
自分でも直したりは、Devynにやらせるときは基本的にはないですね。
というのも僕の今いるチームではDevynに作らせたプルリクは基本的にはその人がレビューすればもうマジでOKっていうルールにしていて、
なので何というかな、自分で手を加えたらもともともない感じがあるというか。
だから本当に簡単なタスクというか、そんなに人によって触れないし、ええやったところでみたいな。
15:01
あと、ディフェンダーボットでバージョンハンプするぐらいの。
そうですね。僕のAIを使うときの方針として、もちろん最初の設計の壁打ちとしてAIを使うもあるはあるんですけど、
じゃあいざ手を動かさせるときはAIを超マイクロマネジメントしたいと思ってます。
だから本当に細かい単位でタスクリストを切り出すんですよ。
なんで、そのスキル度まで分割したらDevynが間違ったことをすることほとんどないんですよね。
なるほど。そういうもんだ。確かにめっちゃ細かくできるならまあそうだろう。
そうですね。本当にざっくりとした要望というかプロンプトを支持すれば、
なんというか、AIがよしなに解釈して自分が想像したものとはちょっと違う成果物ができるとかはまだまだ多いにあると思うんですけど、
それをなるべく避けたいから僕は損してるって感じです。
基本的にDevynに簡単なタスク依頼してる裏で、手元ではクローズコードを動かしてちょっと複雑なことを作らせながら修正して同格して、
まあまあブリック作ってるみたいな感じですかね。
そうですね。おっしゃる通り。
このタスクはこっちにやらせよう、あっちにやらせようみたいなのはどこで判断してるんですか?
タスクの難易度、都度自分で見て判断って感じですかね。
難易度とか、まあもちろん難易度が高ければタスクを分割するっていうのは最初に試みますし、
ただまあタスクの分解がある程度できてきたらもはや感覚でこっちは手元でやったほうがいい、こっちはDevynに任せて大丈夫みたいな感じですね。
あと大まかにはやっぱり手元で動作確認したいかどうか。
手元で動作確認したいかどうかと、あとコミットする前に念のためディフを確認しておきたいような変更かどうかですかね。
それって、例えばコミットって別にローカルのやつって、まあ別にどうでもいいっていうか。
まあそうですね。
本番に出るものじゃないじゃないですか。メインに入るものでもないしまだ。
ってなるとまあ、そんなに重要は高くないのかなと思っていて。
なんだろう、クロードコードとかローカルでやりたいものだよね、これはって。
どっかで判断してると思うんですけど、今なんかそれをどういう尺度で判断してるんだろうなっていう。
どういう尺度、例えばなんですけど。
18:02
前はだってなかったじゃないですか。前はだって全部自分でやってたのに、途中からレビューが入ってきて、クロードコードができて。
いつの間にかひめのさんの中ではグラデーションができてて。
そうですね。
このタスクはこいつで、このタスクはこっちだって。
なんかそれは言語化しがたいですね。
この1年、2年AIを使ってきて自ずとなんとなくこっちの方が向いてそう、なんとなくこっちの方が向いてそう、
という判別ができる、自分の中でできてきたが、せいではあるんですが。
なんかデビューに頼めるのは、ジュニアエンジニアにもお願いできるよねぐらいのレベル感の決まりきったタスクで、
そんなに驚いたことにはならないだろうなだけど、ちょっと複雑なやつは他のエンジニアと一緒にペアプロしたいなぐらいの感覚でクロードコードを使ってるというか。
確かにそれはあるかもしれないですね。
あともう1つ動作確認の観点で言うと、例えばデビューがモバイルアプリのプルリクを出しました。
その時に動作確認しておかないと不安だなっていうコードを動作確認するときは、
何だろう、手元に落としてきてビルドを始めるのもめんどくさいしなという気持ちはありますね。
なるほど。だからモバイルに関わるところは基本的にデビューに使うのはまずと避けたいなぐらいですね。
もちろん例えばフラッターにまだ使わないけど今後使いそうなライブラリー入れておくとか、
なんか明らかに今の挙動に影響を与えなそうなやつはガンガンデビューに慣れてますけどね。
なるほど。そうなってくるとひめのさんの仕事としてはタスクを分解した後に関しては大きなタスクをクロードコードと並走しながらやりつつ、
デビューに依頼出してプルリク作られたらそれを見てマージするみたいなところですかね。
そうですね。あとは何だろうな。グーグルクラウドとかそういうもののダッシュボードを開かないとサービスアカウント発行するとか。
ちなみに今なんかエージェントを使ったりとかで仕事の中で大変なことって何ですか。
エージェントを使って仕事の中で大変なこと。
大変なこと。
ここに負荷かかってるなみたいな。
いや、なんて言うかな。言語化が難しいけどというか、昔からあったことではあるけど、何というかAIはもう指示したら即座にやってくれるじゃないですか。
人がボトルネックになることがのじつに増えますよね。
21:05
例えば何だろう。僕がミーティング始まる前にDevinにタスク5個依頼しておきました。
ミーティング終わって全部一応プルリクはできてるけど、それを処理するのにも時間がかかるじゃないですか。レビューするとか。
ちなみに昔だったら例えば5個のプルリクを自分で作ってマージするのに1日くらいかかっていたのが、今だとレビューをしたとしても1,2時間で終わるじゃないですか。
そうですね。
そうなると5時間くらい空いているんですけど、その1,2時間で終わったとしてもちょっとボトルネックになっているのがつらいって感じなんですか。
ボトルネックになっているのがつらい。つらいというか、強いて問題をあげるとすれば。
強いて言えばってことですね。別にあれはないんですか。昔ってこれあれですよ。昭和とかに比べると仕事の時間あたりの密度がめちゃくちゃ高くなっているみたいな話があって。
要するに昔って例えばですけど、メールもなかった時代って手紙を送らない限り先方に連絡できないみたいな、例えば。電話ありますけど。
そうですね。
その手紙を届くのも別に明日に届くわけじゃなくて、もうちょっと時間かかるとか。そういうことがあったんで、昔同じ1時間働いても今ほど情報密度が高くなかったからそんなに負荷が高くないみたいな、そういう話もあると思うんですけど。
それが今エアエージェントいっぱい動かすともっと高いじゃないですか。
そうですね。
そういう観点で1時間あたりの仕事量というか考えないといけないこととかこなさないといけない細切れなタスク量とか増えてると思うんですけど、そういうとこは別にあまり気にならないですか。
あと、単位時間あたりの仕事の密度が増えました。それをこなさなきゃいけないから自ずと僕がボトルネックになりがちっていうのはありますよね。
別にそれ自体は大変じゃないですか。
大変ですよ。大変だから困ってる。
密度上がっては大変なんだ。困ってる。
そうだな。あともう一つあげるとしたら、何だろうな。
今まで自分たちが作ったものを運用するっていうのは全然わかるんですけど、AIによってめちゃくちゃ加速度的に作れるものが増えている現状において、
24:01
ほとんどAIを作ってて運用が人がやるみたいな感じだと、知らんコードというかあんまり筋肉になってないコードが大量にある中で運用するのだんだんきつくなりそうだなっていう、なんとなく外から見てる。
僕はそうなると思ってるから、僕自身がなるべくAIの書いたコードを把握できるようなワークフローを取っているっていうことですね。
なんかコード読むのとコード書くのって明らかにコード書く方が理解できるじゃないですか。
そうですね。
そうすると少なくとも今までと比べると書いてない分理解度落ちません。
いやそれはおっしゃる通り、そうですよね。
確かに自分の手を動かして試行錯誤して書くが一番現実的にコードの理解度を高める最大の方法ではありそうだが、
とはいえ今の時代AI使って開発しないとどんどん開発スピードが他社に比べて遅くなるみたいな現状もあるわけじゃないですか。
そこのトレードオフじゃないですか。
それほんとそんな大事なのかな。
いやなんか結局機能ってたくさんあったところで別に全部使われるわけじゃないから機能数は削ってった方がいいみたいな話あるじゃないですか。
そうですね。おっしゃる通り。
何というか。
本当にスピードを見せかけたら大事なのかな。
うーん。
いや大事じゃないことはないんだろうけど。
例えば一つのプロダクトの中でも開発のスピードが増えるそれは例えば開発チームがこういう機能を入れるといいんじゃないかみたいな言ってみたら
仮説を検証するための検証できる仮説が単位時間あたり増えてますよね。開発のスピードが上がるってことは。
ユーザー観点で見るといろんなよくわからん機能が次々出てきてよくわからんみたいにならんのかな。
なんかむしろそれはあれなんじゃないですか。人が手で書いてサービスを作ってデプロイしてた時代って何というか。
人のサービスを使う側としてもまだまだ全然これより早くなっても許容できるレベルだったんじゃないですか。
どうなんだろう。わからないですよね。
何だろう。例えば今いるチームだと2週間スプリントを組んで基本的には2週間ごとに定常リリースをしてるんですけど
言ってみたら新規の機能が追加されるのが2週間周期ってわけじゃないですか。
27:02
ちなみにIDとかって今1週1とか2週2回ぐらいアップデートしてますけどいろんな新機能毎回追加されるじゃないですか。
カーサーとかVSコールとか追ってます?
追ってないですね。
なんかむしろ便利なんだろうけど全然知らんみたいな感じになりがちで。
なんかユーザー的にはそんな頻度とか出てもわからんしついていけないしむしろあんまり買えんでほしいとか思っちゃいそうな気もするんだけどなと思って。
それこそC向けの機能は言ってみたらどれが大ヒットするかわからない世界じゃないですか。
プロダクトっていう単位ではそうですね。プロダクトの中の機能って意味だと頻繁に変わりすぎると使いづらくなっちゃう。
頻繁に変わる細かい変更がたくさんある中でどれか刺さったものだけを残す、それ以外はリタイアさせるみたいなことをどんどんやっているのがプロダクトのライフサイクルというかプロダクト開発の流れなんじゃないですかね。
機能の大きさによるけどそこまでやってるサービスあんまり見たことないか。
たとえばYouTubeとかで考えたときに今まで横の大きさの動画がメインだったけどショートってやつが出てきて。
で、そのショートってやつはとりあえず試しで作ってみました。皆さん投稿してくださいねみたいな感じで作ったけど、その後人気なかったらクローズするよ。人気出たら伸ばすよみたいな感じのとこですよね。
そういう単位のものが体上に出てきても使えないというか。それがすぐ無くなっちゃうと、どうせまたすぐ消えるのかな、触るのやめとこうみたいな。
どんどんなっていかないのかなっていう。
それはそんなにみんなどんなところにつくかというと。
わからんっていうところですね。
エンジニア採用の観点。
どっかで限界来ません?それは少なくとも。
今よりも許容度が高いかもしれないか。
開発の速度が上がったみたいな文脈で言うと、もう現にエンジニア採用、失業的には各社採用数を絞り始めてるとかはありそうですよね。
それは何だろう。エンジニアの数を減らしてその分、エンジニア一人当たりの開発速度が上がった分で元の開発体制を維持できるんじゃないかみたいな意思決定が取られてるんじゃないですか。
30:02
確かにそれはそうですね。だから開発量は増やさなくても、生産性は上がったから人を減らそうは分かりますというか。
そうですね。それで言うと、AIがなかった時代をもし考えたら、僕のいるチーム、今の3人の速度は3人では出せてなかっただろうと思うので、今限にそうなってるとも言えますね。
というところですかね。
はい。一旦ここまでにしようか。今回はですね、ひびのさんがAIをゴリゴリ使って仕事をしているというところで、
2026年1月現在のAIを使った仕事の進め方と困りごとみたいなところをちょっといろいろ聞いていきました。
このpodcastはハッシュタグライティで皆様からの感想やコメント募集しております。
またチャンネルの概要欄にありますGoogleフォームのリンクからもご投稿可能です。ありがとうございました。
ありがとうございました。
