AI駆動開発のリアルとポッドキャスト編集自動化の成功体験
おだしょー こんにちは、AI駆動開発部の日常
へようこそ。このポッドキャスト は、日々AI駆動開発を行う企業課の
山本とエンジニアの阿部が、AI 駆動開発のリアルを緩く語り合う
番組です。本日もよろしくお願いします。
山本 よろしくお願いします。
おだしょー じゃあ、今日はAI駆動開発 から少しスコープを広げて、AI
って何でもある程度効率化できる ようになってきてる。今、どこから
効率化していくのが筋がいいんだろう みたいな話をしたいなって思って
ます。そこから、AI駆動開発をし始めて 生産性が多分20倍10倍とか100倍
とかになる人もいれば、1.5倍とか かな、みたいな人もいれば、逆に
0.7倍みたいな人もいたりとか、いろん な人がいるのかなと思っていて、
僕のケースからちょっとエンジニア の人からすると、いや、それ微妙
でしょ、阿部ちゃんとかからすると それ、どうなの、みたいなとかっていう
意見もコメントでいただけたらな と思いつつ、今現時点で単純にAI駆動
開発、AIのポテンシャルを最大化 するという観点に立ったら、こっち
のほうがこういう進め方いいん じゃね、みたいな話とかにつなげ
ていけたらなと思ってます。ちょっと その前段階として、最近僕が実際に
開発して実現できたことみたいな ところをシェアをして、そこで得た
絆みたいなところも話せたらと思 ってるんですけれども、まず今オープニング
から本編に入るにあたってBGMとか いい感じに流れてたと思うんですけ
れども、これ全部システムで自動で 吐き出されるようになりました
と。あとは本編の今BGM流れてるんですけど、 これをもともとは1分ぐらいのBGM
なんですけれども、それが40分とか ずっと流れてる。この音声のループ
間を自動で推論というか判定して そのループをいい感じに伸ばして
いって、最後エンディングとの切れ 目の部分でフェードアウトして
いって、次またエンディングが始まる みたいな。逆に短かったらループ
間を切って、いい感じにBGM当てはめる みたいな仕組みであったりとか、
あとは僕がこういうふうに喋ってる 間に、阿部ちゃんのほうが喋って
なかったらそこはカットされてる みたいなやったりとか、両方無音
だったらもちろんカットするし みたいな。あとは言い間違えて
この部分カットしといてっていう ふうにお願いしたら勝手にカット
してくれるみたいな。LLMが推論して みたいな。そういう仕組みが一連
の流れが一応完成して、実は今もう ビデオポッドキャストもほぼ実現
可能性があるところまでは開発 時代は進んでるんですけれども、
まず音声ポッドキャストの編集自動化 っていうところは完成しました
と。ここのこれやってること自体 がどうかというよりは、その中の
開発を行う中で僕が感じた、結構 やばいなみたいな思ったことが
いくつかあって、まず一つがエンジニア なし。阿部ちゃん一切今回開発
として噛んでない。だから正直俺が ここまでできたわとかって言ってる
ぐらい。
おだしょー そうだね。横で聞いて そんなことができるんだみたいな
BGMをいい感じに調整できるって あるんだみたいな。そんなことできる
んだみたいな。
三沢 そうそう。みたいな。そんな ぐらいなのかなみたいな感じだ
と思うんだけど、それがエンジニア なしで。僕はプログラミング多少
は知識あるんですけども、自分で コーディングとかしてなかった
人がここまでできるっていうこと が、まずここまでできるようになって
きてるっていうことがまず1個の 要因だなっていう。もう一つが、
さっきのループ区間を自動で判定 してうまくつないでいくとか。初め
僕が始めたときって、今Zencaster ってやつで収録して、2トラック
で音声ができるから、それを文字起こし して、それを元にLLMに推論させて
カットしたら、ある程度自動化できる じゃんみたいな思ってたよね。俺の
想像範囲内で言うと。けどBGMちょっと 難しそうだなみたいな。俺の想像
範囲内で言うと難しそうだなみたいな。 だからそこに関しては完全に想像
の範囲外だったところが、AIがいろいろ 調査してきて、こういう技術がある
ようだと、OSSで。だからこれをこういう ふうにやるといけるんだぜみたい
のを言われて、なるほどと。聞いて みて、違和感もない。こちらとして
も違和感はないし、できそうだな みたいな感じだから、じゃあやって
みてみたいな。もちろんその間には こういうふうにしたほうがいいん
じゃないみたいなとかって言われてる りはあるんだけど、少なくとも自分
自身が想像してる範囲外のことを AIが見つけてきてやってくれた
っていうこの事実。今まで僕の中で AIって部下みたいに扱うべき
かなって思ってたんだよね。だから 自分の想像の範囲内の指示を出して
いい感じにやってもらう。自分の 思う通りにいい感じにやってもらう
っていうところの範囲での役割を 果たしてもらってたのが、もう完全
に自分の想像の範囲外のことを 見つけてきてやってくれて、実際
に再現性ある形でできてるっていう これがAIとの対峙の仕方をまた
一段認知としてアップデートさせない といけないなっていうふうに思った
体験としてまず共有したかった なというふうに思った。
AIとの向き合い方の変化と「スーパー予測者」の研究
三沢 うん。けどこれってすごい認知コスト
が高いというか、自分の知らない ことの中でその方針が確からしい
かどうかっていうのをAIとの問答 によって判断して実際にやって
もらうみたいな。正直俺とかみたい にPMとかやってる人からすると
今までのエンジニアにお願いして 自分の分かんないことをエンジニア
に調査してもらって、その説明だったら 確からしそうだとかここちょっと
何か欠点ありそうだみたいなのを 判断しながらやってたから多少
やってることは一緒なんですけど とはいえ想像の範囲内である程度
進めてたみたいなところから完全に 自分の知識を逸脱した行為が行
われる状況っていうのにかなり ちょっと驚きを感じてましてそこ
もまず一個AI駆動開発する上で もちろんこれが一般ユーザー向け
にとかってなるとより慎重にならない といけないとかいろいろあると思うん
ですけどかなりやばいことが起き てるなっていうのを改めて実感しました
っていうような感じですね そこ 実際たぶん阿部ちゃんもやってる
中でそれを認知の中に閉じ込めよう としたときにすごい認知コスト
がかかってめちゃめちゃ大変みたいな 特にクライアントワーク
そうだね
あるよねなんか
でも確かに今まで自分ができてこ なかったこととか考えもしなかった
ことをいわゆる自分の想像の中で こうしてるっていう中でこうある
べきだみたいな想像の中で手足 として動いてもらうAIからこれ
までになかった発想とか調査した 結果こういう方針ができますよ
って提案してくれるある意味専門家 への害虫ができるみたいなそういう
感覚は最近強くあって自分の中で 新しいシステムを作っていくとき
に大体こういうふうに作ったら いいのかなっていうのは想像の中
で思うんですけどもっと実は拡張 性があるものを作れたりするん
じゃないかみたいなのを思って 聞いてみると結構いろいろ調べ
て前例としてこういうのあるから できるよみたいな教えてくれる
からなんかもう手足とは違う世界 に来てるなっていうのは体感して
ますよね
おだしょー 本当にいろいろ調べ てて一個そのなんかあって結構
AI駆動開発と関連しそうだみたいな のがあって脳臓的解放思考っていう
研究があるらしいんだけど自分の 考えに反する理由を脳臓的に探す
姿勢っていうものは脳臓的解放 思考と名付けた認知特性として
一応科学的には定義づけられて いてそれの研究の結果みたいな
のが結構面白くてその上でそれに ちょっと近しいものとしてまず
スーパー予測者これ多分日本語 訳されてるから多分違う言い方
なんか分かんないけどスーパー 予測者の研究っていうのがあって
これ結構面白くて簡単に言うと 専門家がいますとその専門家機密
情報にアクセスできる情報機関 の専門家っていう人たちがいて
それとは一方で上位のスーパー 予測者たちっていう人たちはIQ
とかそういうのに関わらず実際 にこの情報とかにアクセスできる
専門家よりも30パーセントその 予測っていうの精度が高いっていう
それはだから実際に情報を持ってる 専門家よりもそのスーパー予測者
的な人はより精度高く考えられる みたいなそういうイメージ
そうより精度高いでそれはいわゆる このAOTで言われる労働的解放思考
っていうのを持ってる人は簡単に 言うと自分が1回決めたものを
あくまでも仮説として信念をひたすら 更新し続けて自己改善し続ける
姿勢があったとその人たちでほとんど 労働的解放思考の一緒のような
人たちは実際にそのような30パーセント も専門家よりも精度が高い予測
をしたというような研究がある らしいのでしかもこれが面白い
のがIQとかも関係ないらしい
つもりん 要は知的な能力ではなくて マインドセット的なところで結構
変わるみたいなイメージの話なの かな
三沢 そう解放的な思考スタイル っていうのが最も近いライバル
知能であったり計算力よりその 的確な予測をする予測因子として
約3倍強力だったっていう影響度 として
つもりん そういうのがあるんだ
三沢 そうだから頭の良さよりも むしろ更新し続けるみたいな
三沢 だからあれなのかな超能力者 っぽく聞こえるんだけど僕には
スーパー予測者
つもりん めったい違う良い呼び名 があるんだけど
三沢 でもスーパー予測者はAIと だから問答するのが得意なのかな
どっちかっていうと
つもりん 多分スーパー予測
三沢 こういう考え方もあるのかな みたいな
つもりん 多分例えば専門家例えば エンジニアとかもそうだけど専門家
の人たちが自分の枠の範囲内で 考えるじゃんけど一番多分最強
なのは専門家が解放型思考脳動的 解放思考っていうのを持って挑む
っていうのが一番多分最強なん やと思うけど自分の固定観概念
みたいなところにとらわれずに 常に更新し続けるっていうその
思考スタイルそのものがそもそも 専門性よりもはるかに効果が高い
っていう
三沢 でも確かに何だろうな僕自身 はどっちかっていうと専門家情報
を持った専門家よりの
つもりん エンジニアとしてね
三沢 エンジニアとしての動きが多い
なっていう中で他のプロジェクター ってヤマちゃんと一緒に仕事
してる中で時々ハッとさせられる というか僕がよく言うのがショック
失いそうだなって感じる瞬間が 多いみたいな話をたまにヤマちゃん
に聞くんですけどそれについて 今まで自分が蓄積していた技術
的な開発っていうのはこうある べきとかステップとしてここ踏
まないとリスクがあるんじゃない かなみたいな体感みたいなのが
あるんだけど話してる中でとりあえず それAIにやらせてみればみたいな
そういうちょっと今までに発想 になかったことを言われて確か
になみたいなってやってみると 意外とサッと解けたりするそれは
自分の中ではAIには解けるのが 難しいって思っていたことが意外
とそれをフラットに考えてやら せてみたときに案外うまくいったり
するっていうことも時たまある わけもちろんうまくいかなくて
残念だったねっていうケースもあるん だけど別にそれってAIが失敗してる
だけだからそんな自分にすごい コストかかったわけじゃなくて
その辺のトライアンドエラーも 今しやすくなった状況において
はもう考えるより先にとりあえず やってもらうみたいなのはかなり
大きくあるんじゃないかなみたいな 意味は感じるよねそれが一つ予測者
としてのマインドの一つもある のかな自信過剰を警戒して自信
過剰というか自分の知識を無駄に 信用するんじゃなくて一旦フラット
に考えてやらせるみたいなそういう のもスーパー予測者として必要
になるマインドセットなのかな って感じで
おだしょー 多分これは今までAIが登場する
前にあった研究でだからこれAIっていう ツールと共にやったら30パーどころ
じゃないみたいな話になる可能性 はあるよね
山本 そうですね さっき山本ちゃん が言ってたBGMがデッキ難しそうだ
なって思ってたけどそもそもやら せてみたら意外といけたみたいな
おだしょー そう調査してもらう っていうだからしっかり調査して
もらってその中で確からしそうだ みたいなものを判断して選択する
みたいなときに専門性みたいな のとかを発揮できたら一番組み合わせ
としてはいいよねエンジニアの 人とかからすでに神秘感は身に
付けてる少なくても俺とかより は身に付けてる状態でけど広く
はAIに探索してもらってその中で 一番ベストだよねみたいなのを見て
もらうみたいなのは結構あるんだろう なと思ってそのときに結構自分の
自己認知として能動的解放思考 これはその後にしたいけどの嫌い
があるなっていうのは自分自身 自己認知としてあるんだけどそれ
でも自分は自分の思考の檻に閉じ 込められてたなっていうのをすごく
そのときに感じた
おだしょー そうだよねBGMできない なゼロだった成果が意外とやら
せたらできたでもう10倍とかそういう 次元じゃなくなってるもんね
AI開発における「問いの立て方」と「ボトルネック」の重要性
大平 そうっていう
おだしょー でも意外と僕これ難しい なって感じてるのが問いのとき
問いの立て方は結構大事なのかな みたいなやりたいこととかこういう
のできたらいいんだろうなって 思ってとりあえずAIにお願いして
もその問いの立て方次第では全然 漁ってんな方向にいったりそもそも
これやんないほうが良かったみたいな むしろ例えば自動化したいです
みたいな自動化したいですって 自動化確かにできたんだけどそこ
までのステップが逆に増えちゃ ったりあとは確認のフローが増え
ちゃったりしてむしろ効率化が 下がっちゃったみたいなときも
なくはないと思っててAIにそういう 新しい取り組みをお願いするとき
にその問いの立て方っていうのも 結構スーパー予測者これPM的な
感覚のマインドセットなような 気もするんだけどそこで気をつける
べきこととかってあったりするん じゃないかなって思うみたいな
三沢 それがまさに今日一番メインテーマ
で話したかったみたいなやつが それに近しいもの前提として自分
の思考の檻みたいなのを感じて ハッとさせられたっていうところ
の共有をしたかったなっていう のとあとその上で今阿部ちゃん
が言ったちょっとこれはAIでワーク フロー組むとか社内の業務を効率
化するみたいなとかひいてはサービス 開発で特定の事業者の課題を解決
するみたいなところに多分ひも づいてくると思うしそれが結果
的にAI駆動開発をする生産性を 上げる一つのあれになるのかな
と思ってるんだけど1個問いの立て方 とはちょっと角度が違うけどすごい
思うのは例えばこれ音声ポッドキャスト の編集自動ワークフローが完成
しましたってなったときにボトルネック になるのはこの俺と阿部ちゃん
がいかに毎日喋るかとかそんな話 じゃん
おだしょー そうだね喋れば喋る ほどもう生成されるっていう状態
になってるからね
三沢 そうそうそうっていう状態 じゃんそれがベストかどうかっていう
のをさておきボトルネックになる ことがあらかじめ特定できてる
とその1個のワークフローなんで 例えば技術生成ワークフローを
作りましたけど人がちゃんと確認 しないといけないっていうのと
人の確認っていうのがボトルネック になるわけじゃんこれが例えば
俺らの一番いい例でいうと開発 してプロリクの作文を見てドキュメント
を更新するっていうのはほぼ確認 のステップは踏まないわけじゃん
一応ちょっと見るけどどっちか というとレビューの中というか
自然と中に挟むから人がボトルネック になることってないじゃん
人がボトルネックになってない このユーザーマニュアルの更新
作業みたいなのはAIの能力をい かんなく発揮してるなというふう
に思っていて
しばやん そうだよねだって今 プロダクト
のドキュメントを誰も触らずに 更新できてる状態って結構ありえない
というか
しばやん そうだから人がボトルネック になり得るっていうのはまずある
じゃんそのボトルネックになった 時に例えばPodcastは毎日話すのは
きついよねみたいなとかっていう 方の話とあとこのまま例えばPodcast
ヘルスに数時間かけてるのが5分 になったら嬉しいよねみたいな
話とかいくつか観点を切り分けて これが先にまずやるべきなのか
どうかみたいなのはある程度予測 できそうだなって思うとまずAI
でワークフロー化された時にどこ にボトルネックが次現れそうか
みたいなのを予測しとくみたいな のは結構大事なのかなと思って
て
しばやん はいはいはい
しばやん そうブロッカーが結局 1日1回しか記事が確認できないって
なったらどんだけ記事の自動生成 ができたとしても1日1個の記事の
自動生成が効率化のアッパーになる
しばやん 確かにそれはあるかもね いくら生産性上がってもその先
でストッパーが解消されないんだ ったら一瞬の作業が早くなるだけ
で全体のフロー的なスループと 全体としてのスループとは変わ
らないみたいなことになる
しばやん そう例えば1日1記事っていう 前提があったとしてじゃあ1週間
であの記事しかできないぐらいの 生産性しか俺たちは獲得できなかった
っていう判断になるからそれって 自動化できてよかったのかどうか
みたいなもちろんよかったみたいな 話も
しばやん 編集する時間自体は下がる からね
しばやん そうそうっていうところ があるからだから真の意味でAIを
本当に最大限発揮するっていう のは完全に無限に何のストッパー
もなく生き切るみたいなところ かどうかみたいなのが結構重要
なのかなって思っててそこから ちょっとAI工房開発の話に入って
いくんやけどなんか初めに設計 を結構やるみたいなそれはなんか
阿部ちゃんが言ってたさあれも 結構近い話で何だったっけグリル
なんちゃらみたいなスキルなんか 3行4行ぐらい
しばやん グリルミーカーっていうやつ
だよね
しばやん グリル何だったっけ
しばやん グリルミー
しばやん グリルミー
しばやん グリルミーかグリルミー 俺見たとき微妙だなって思って
思っちゃった
おだしょー はいはいはいいや 僕も正直微妙
だなっててかなんかもう既に結構 誰でもやってそうなことだしな
みたいなところもあったし
しばやん それもそうなんだけど 何だろう
質問をしらみつぶしに全部一つ 一つ全てやるってその質問に回答
するボトルネックを人が担うわけ でだから質問は三つまででいい
設計とかの質問は俺は三つまで ぐらいで十分だと思ってて
ちょうだいになればもちろん5個 ぐらい欲しいなみたいなときは
あるけど全部やるっていうのは あんまり良くないんじゃないかな
っていうのがあってそれは一発で 一番精度が高いものを出そうと
したらもちろん必要な行為なんですけど 個人的に一晩寝てる間にいかに
開発させとけるかっていうのが 重要だと思って
しばやん そうだよね 寝る前に 頂戴なタスクを渡して起きたら
出来上がってるみたいな
ちょまど けど一週間に設計してたら 設計はネジライズにはしてくれない
わけですよね
しばやん そうだよね
ちょまど だから設計はもう何か 数時間とか寝る前までに終わらせて
まず実行しといてもらってアウトプット 見てフィードバックしながら改善
していくみたいなのを一週間あ ったら例えば護衛業務とかとして
5日間のフィードバックサイクル が回せるし実行する間寝てるんだ
から別に関係ないとこっちから するとって考えると一週間かけて
AIと問答しながら同期的に設計 を詰めるより5サイクル回した
ほうが効果高いんじゃねっていう それはAPIコストとかそういうのは
一回土返しにしてねこれがさっき 言ったAIがボトルネックじゃなくて
人がボトルネックになってる点 が多いほどAIの生産性の器用っていう
のがうまくいかないうまくいかない というか最大化できないみたいな
だとすると一週間AIと問答して 繰り返して同期的にやるよりは
よっぽどとりあえずエイヤーで やらせてそっからガンガンもう一回
それをもとに話を組みそれは前回 の記号設置問題とかの解消にも
なるし記号設置問題の解消プラス やっぱり一番時間がかかる実装作業
とかそういうのを人が関与しない 時間の間にやらしておくことで
イテレーションを回し続けるみたいな フローを作るのがかなり重要
なのかなっていうふうに
おだしょー いやそれすごく感じる ところもありつつ適応範囲がある
かなみたいな感覚もやってる中で 僕は感じていて確かに最初にど
かっととりあえず三つの質問とか まずどういうことをしたいのかを
伝えてほとんどAIに大きな計画 を立てさせてあとはその計画が
問題ないかをAIに言ってレビュー させた後に大きなタスクとして
移情してもう一晩でやってもらう とかっていうのは結構これはこれで
ワークする動かし方だなという ふうに感じていて僕がさっき言った
適応範囲があるっていうふうに 感じてるのはまず一番大きいの
がアプリケーション内に開発が 閉じてるかどうかでここがかなり
うまくワークするかが変わってる なっていうところを感じてるんですよ
ね
おだしょー わかる
三沢 例えば僕の場合だとアプリケーション 内っていう例えばWebのSaaSのシステム
を組んでいるとしてそれが本当に SaaS単体として動くものを作りたい
例えば新しい機能で画面を一個 作ってそこでユーザーが操作できる
ものをちょっとロジックは複雑 なんだけど作りきってほしい
こういうのは結構うまくいくし 途中で変な方向に走ったとしても
あとからここは違うからっていう テストの段階とかでAIに指示出せ
ば結構すんなり直してくれてなんか 塞いとかも残りにくいなって感じ
てるっていうのと あと閉じてる がゆえにAIが自立的に改善する
っていう取り組みも結構作りやすい 例えば今だとPlay Lite MCPとかブラウザ
ユーズとかいろいろあると思うん ですけどああいうのを使って自分
で見に行ってページがうまくレンダリング されてるかそのレンダリングの
見た目が正しいかどうかボタン を操作したら動くかってAIが自分
で操作しながら直したりすることも できるので結構この範囲において
はかなりワークするかなって感じ るんですけど一方で結構難しい
なって感じてるのが外部連携が 必要になるとかそもそもインフラ
が分離してしまうっていうときに かなりこれが難しくなるっていう
感じがします
おだしょー なんかそれで言うと AIで開発させるの難しいねみたいな
話でそのイテレーション回しま くったほうがAIの生産性に寄与
するんじゃないかみたいなのと 掛け算かなって気はしててだから
とりあえずやり切って人が確認 するみたいなところを一晩一晩
でサイクル回すみたいなのは早 そうだなみたいなところはあって
俺がアプリケーション内で分かる 分かるって言ったのはどっちか
例えばオープンコードとかOSS系 のやつってめちゃくちゃ爆速で
開発されてるじゃんあの辺が結構 強いのはデータベース持ってない
からみたいな感じとかあるんじゃない かなって思っててなんとなく
大きいと思うよ
だから破壊的変更とかがあんまり 置きづらいかどうかみたいなの
結構ありそうだなって思ってて 例えばPodcastの編集ワークフロー
ってもう一切UIすら作ってなくて 今だから破壊的変更も別にして
もいいしもちろん公開してない からしてもいいみたいなとかだから
破壊的変更を許容してどこまで 開発しきるかみたいなところを
決めてまずゴリゴリ開発させて ある程度形になるところまでは
OSSとかがうまくそっからサービス 化するみたいなとかもあると思
うけどそっちの進め方のほうが うまく回るんだろうなみたいな
一回公開しちゃうとなかなか難しい みたいなところがあって
責務境界の切り方とAI開発の適用範囲
おだしょー そうだね その話で 言うと多分CodeとかCodexとかこれ
らって基本的にみんなの手元ローカル で動くものだから実行環境として
はNイコール1みたいな状態なので 整合性をその中に閉じ込めること
っていうのは結構早すぎあるまま で作るのは大変だと思うけど比較
的容易なんだけど これがSaaSの システムとして組もうとかって
なるとNイコールXというか いくら でも増えるものだし 人がどういう
ふうなデータを持つかっていう のは状況によって変わるのでそういう
依存関係 それがさらにデータベース だったり あとはジョブ級として
依存関係を波及するとかそういうこと があるから結構難易度が上がる
そういう意味ではYamaちゃんの イメージはそうなのかなって思う
ね
Yama そう だから依存関係ができる だけ少ない状況で まずコアな機能
っていうのを決めて そこをゴリゴリ もう破壊的変更も関係なく 広報
互換も全く関係なく開発しきる これができるケースはできない
ケースはもちろんあると思うけど その上でN化していくという
はい でもなんかPodcastのときも そんな感じの進め方してたよね
自動化Podcast自動化のときも
そう もう固定化して変数っていう のを極力減らした上で 音声カット
の精度だけに注力してやり続けて そこからNトラック化していって
みたいな
最初はだから2人だけしかPodcast 作れなかったけど そこからNトラック
みたいな感じで何人入っても大丈夫 みたいな
1でも3でもこれ以上でもみたいな みたいな感じで だから それって
コアな機能がカットとか編集の 判断の部分であるっていうのを
決めきってやってるからなのかな と思ってて そこがプロダクト開発
のスピードにかなり結構
そうだね でも これが多分Nイコール 2から いくらでもいけるようになる
みたいな違いが生まれる中で そもそも設計がドラスティック
に変わるものなのか 多分 ちゃんと 設計をしとけば 別にあとはかける
Nに拡張するだけだよねみたいな ものになるのかいは 全然その開発
のスピードだったり 手戻り感 っていうのは変わってくるかな
みたいな
そういうふうに思って
そこで言うと だから Nトラック にするよっていうのは伝えずに
やってたよね 俺 最初はもう2トラック 固定でやってて Nトラックにする
ので やっぱ命名の変更とか全部 必要になるよねみたいな感じで
そこで一番効いたなっていうのは Nトラック前提で汎用性を持って
設計してもらうっていうこと よりも 積分協会をきっぱり分けて
Nトラック化したときに変わる のってここだけだよねみたいな
状態を 別にそれはNトラック化 したときにここだけだよねじゃなくて
積分協会をもう完全に切り分けてる からこそ 影響範囲が拡張化する
みたいな作り方のほうが効いた なって感じがするから 花から
Nトラック前提で命名とかを考える と記号設置問題にぶち当たる
気がしてて だからどっちかという と 積分協会を意識させるだけ
おだしょー 本当にプログラミング 的な思考かなっていうのは感じる
よね 積分協会っていうのは多分 依存関係をちゃんと紐解いてあげ
て 影響範囲を閉じるようにする みたいな考え方かなと それこそ
オブジェクト思考とかもDDDとか いろんな設計パターンって今まで
クリーンアーキテクチャーとかも ある あれって 究極 雑にまとめる
と 整理をちゃんとして 影響が起きる 範囲内を閉じ込めましょうみたいな
そういう文脈でしかなくて どれ だけの機能を将来実現したいの
かっていうよりかは どこに影響 範囲を閉じて
線引きするか
おだしょー 線引きするかっていう のが重要かなっていうのは確かに
そうだよね
せきむきょうがはっきりしたら NzRackにしたときの影響っていう
のは 初めの入り口の部分とかだけで あと 実行のワークフローになってる
部分だけで 他の処理系自体は全部 関数を呼び出して 一個一個の処理
を直にやるだけだから だから 命名とかどうでもいいなって
感覚になった そん時はね もちろん 逆に 命名なんてNzRack化するとき
に変えればいいっていう感じで 逆にせきむきょう会 完全に依存関係
めちゃくちゃで どこがどういう ふうに影響するかも分かんない
みたいな状況が生まれてるほう が よっぽどやばいなっていう
いや まさにね 僕はもうせきむきょう会が本当に重要かな
って感じてて さっき僕が話した 適用範囲 とりあえず作ってゴリゴリ
イトリエーション回して 一晩 ずつ改善していくっていうところ
の適用範囲があるんじゃないか っていうところは そのせきむきょう
会の切り方が AIにできない部分 がやっぱりまだあるんじゃない
かなって感じてるんですよ それ自体が 例えば 自分が今 AIエージェント
ハーネスとかを自作 自分で作って それを しかもクラウドに乗せて
いろんな状況においてもきっちり 動くよねっていうふうに考えた
ときに いろんなインフラに結合 させなければいけないっていう
ところが課題としてあるんですけど そこのどのインフラにどの機能
を帯びて せきむきょう会を分離 させるかっていうのを AIに考え
させると そこに置いたらだめだよ ねみたいな 結構大きくなって 特に
AIっていうのは今 例えばECみたいな ありふれた仕組みを作ること自体
は得意だけど 今までなかった 概念とか 今までなかったシステム
をゼロから考えるってなると そもそも 何か参考にするものがあまり
なくて 結局 せきむきょう会を どこに置けばいいのかみたいな
判断ができずに迷ってしまった りとか そこでとりあえず実装さ
せてしまうと その後の手盛り取り がかなりきつくなるなっていう
ところ ゼロ設計がまた必要になって しまうっていう感じ 実際になって
いたっていうところが 自分の中の すごい課題感であったところが
その適応範囲の差なのかなっていう ふうに感じてる
そう 俺はせきむきょう会 大事って言ったけど 初手の実行
のタイミングではせきむきょう会 もクソもなくて それは実行させます
実行させましたで E2Eレベルで自分で 見ます 動作レベルで保証されてる
ことを確認します ある程度の正常 経過ぐらいは その上でリファクタリング
させて せきむきょう会をきっちり 分け直してっていうのを
再構成してもらうみたいな
そう ワンツーパンチでひたすら ワンが実行 ツーがリファクタリング
ワンが実行 ツーがリファクタリング みたいな感じでやることで 一番
時間がかかる実行っていうのは 寝てる間に済ませれるから 朝
起きたらE2Eテストして オッケー だよねってなったら 次リファクタリング
日の間にもさせてみたいな感じ で そういう意味では せきむきょう会
さえあればNトラック化するとき にみたいな話をしたけど そもそも
実行のタイミング 初手の実行の タイミングでは せきむきょう会
もクソもないというか
なるほどね だから一日 取りあえずやりたいことを伝えて
作ってもらう 二日目
やって動作検証して
そうするとテストで固定化 できるから
できるのかな それは逆に 僕がいま まさにさっき話して
た スーパーウェスワーク社と情報 機関の専門家みたいな中でいう
ところの 僕は専門家っぽいマインド でいまいたから また試してみる
のは 試してみようかな
おだしょー 逆TBBみたいな
確かに
おだしょー 逆TBB
何をテストするかじゃなくて でき
たものに対してテスト作って そこを守らせるみたいな
おだしょー そこを守らせた上で 責務境界をきっちり切り分けて
リファクタリングさせていく
リファクタリングしていく みたいな
おだしょー そう それを設計とかに 時間かけちゃうと 初めの実装する
AI開発における「実行」と「リファクタリング」のサイクル
っていうところまで 実装するって なったときに AIとそもそも認識
の疎合とかがあったりするから 実装させたことで顕在化しやすい
みたいなのがあって
でもこの考え方って プログラマー の思考っていうのは どっちかっていう
と 一個一個レイヤーというか 土台を積み上げていくものじゃない
ですか 基本的に でも山ちゃんの イメージのやり方 どっちかっていう
と バンって絵があって
おだしょー ビルを立ててね
全部
おだしょー ビルを立てて
そう ビルを立ててとか すごい 滲んだ絵があって それが
ちょっとずつ形として形成されて いくみたいな こういうイメージ
があるから 逆転の発想というか 発想というか 逆転の思考なのかな
っていうのはあるよね
多分 それがおそらくエンジニアル 人たちの今までの考え方みたい
なのは やっぱり開発にコストが それなりにかかったし 人欠で高
数がお金もかかるとかっていう のがあって しかも一回やったやつ
をまた壊すんかいみたいな 人の メンタリティ的なところでの気遣い
みたいなのがあって 取れなかった そもそも思っても取れなかった
と思って それによって形成されている 考え方だから 実装コストがほぼ
ゼロに近づいてるけど 時間は発生 するから 時間コストはかかるって
考えたときに 自分が一番AIが開発 してる中で 時間コストが感じない
場所っていうのは寝てる間の時間 だから そのときに実装させれて
ないっていう そのものがもったいない っていうふうな観点に立ったとき
に こういう考え方ももしかしたら ありなのかもしれないけど 阿部ちゃん
では絶対否定されそうだなって 思ってるし おそらく本当にクライアント
ワークとかだと取れないなかなか
阿部 なかなか難しいよね 一応 僕がジレンマに感じてるのは この
設計に立った合理性みたいなのを ある程度 説明できる必要がある
とかはあって
大平 そう それが今回のPodcastの 編集ワークフローでいうと 俺 多分
説明できるのよね ここに至った
阿部 はい 確かにね やってる中で トライアンドエラーがあって こういう
方針になったみたいなのを なんとなく 理解してる
大平 そう むしろ解像度高く 想像 じゃなくて 全部試した上で言える
から 逆に角度の高い これ こういう 理由があって ここにこういう処理
があるみたいな 設計方式の判断 っていう意味だよね
阿部 例えば 100ある概念の集合 として 1画面として表示されてる
ときに じゃあ その1個1個について 何も知らないと さすがに心配
だなみたいな感じは
大平 それは分かんないと けど Podcastの編集ワークフローはできない
と思う 逆に やっぱ 途中で詰ま るんよね どうしても AIだと
大平 だから理解して
阿部 だから 理解して
大平 初めて理解するんだよね 多分
大平 詰まって 整理してあげる 必要があって 整理してあげるっていう
か こっちが理解できてる必要 があって だから いろんなパターン
を調査してもらって こういう 壁があるから こういうふうにする
べきなんじゃないみたいな そっち の方針 良くないんじゃないみたいな
やっぱ 問答は中であって
阿部 やっぱ そこはあるんだね
大平 そう けど それっていう のが 実装してからのほうが早いん
じゃないっていう話
おだしょー うん なるほどね
大平 そう だから 物がある状態 で話すほうが 話は進むじゃん 人
同士でも それを叩き台にできる から なんか それなのかなっていう
おだしょー 誰か知らないな そういう ことね 逆に言うと 僕の中では
大体 こういう要求が飛んできた 時に 頭の中でパッとこういう組み方
をするといいんだろうなみたいな のが もう大抵 ある程度されてる
から 逆にそこを投影しようとし ちゃうのかなと思う それをちゃん
とAIが理解してるのかなみたいな ところの起点に立って 逆にそこに
差分があると 違和感がすごすぎる し それでできた結果 全然違うもの
になったら いや 手戻りすげえな っていうふうなことを やっぱり
どうしても感じてしまう もちろん 問答の時間にコストがかかるぐらい
だったらやらせたほうがいいっていう のは もちろんそうなんだけど これ
を問答する以前に 自分で指摘すれば さっと実装 ある程度いける その
先のちょっとした調整は できた 後にやればいいかなみたいなのは
あるから そのぐらいの
おだしょー 夜に実際 時間かかってる のが事実かなって思う
AIの進化と人間ボトルネック問題、ツールの使い分け
平岡 ああ そうなんだ
おだしょー なんとなくね あと 固定化した 最適化されたものっていう
のが 本当に最適化なのかっていう のも一つあるよね 特に
平岡 そうだね そこは
おだしょー ウェブサイト制作みたいな とか そういう ある程度揉まれた
ものをやるんだったら 別にそんな ものはあんまり必要ないかもし
れないけど 未知のものをやる みたいになったときに より効いて
くる話なのかなっていう そんな 感じで 結構 だいぶ しかもこれ
ができてるのがDeepSeekっていう とこが驚きで
平岡 ないよね 本当に半年前ぐらい じゃ想像もつかんかった この中華
モデルがここまで 僕もほとんど DeepSeek Proをメインで使ってる状況
っていうのが想像つかなかったん で もちろん裏でサブエージェント
としてGPTモデルを使ったりは もちろんしてるけど かなり安定して
かつ 推論もそれなりにまともに オーケストレーションもやって
くれるみたいな すごいよね
平岡 ね 本当に そういう意味で 何だろう まだちょっとAIの力 開放
しきれてないなっていう感覚が 僕の中であって けど それの一つ
としては人間ボトルネック問題 をどう改善していくかみたいな
これはAIで業務を効率化するっていう 観点でも結構あるなと思って
平岡 そうだね ボトルネックの 先のボトルネックまでも考えた
ほうがいいよねっていうのは 確かに な
大平 そう そう そう っていう感じで どうぞ
平岡 ボトルネックが解消されて 次のボトルネックができたら また
そこをAIでゴリゴリ改善することも 最近はできるようになってるという
か やりやすくなってると思う から
大平 だから AIでボトルネックが 改善できる間はいいんやけど 人
がボトルネックになる だから 例えば Podcastの動画編集で言う
と 収録がボトルネックになる みたいなのは もうAI化はできない
わけじゃんみたいな そこの話かな そこを見せたときに ここで止まる
なっていうのを ある程度認知した 上で 取捨選択する
平岡 そう いくらでも楽にしたい 作業っていうのあるわけじゃん
だから できればAIで完結するもの を そもそもの考え方として 1分
でも作業が残るものは 真の効率 化ではないと思ってて 人間のストレス
が増えるだけ 効率化はされる けど やることは増えるみたいな
だから 1分 多分 行き切ったら 1分の作業が1000個ある1日でみたいな
めっちゃやってる量は多い こな せる量は多いんだけど 1分の違う
やつがっていうのがあるなと思 ってて その1分すらもなくなる
ことから効率化していったほう が効率的だなっていう
それが5分の効率であっても ゼロ になるのと 1分残るのは 結構
運勢の差がありそうだなっていう
平岡 確かに 結局 仕事を1日8時間 働いてる中で 効率化進んだら 単純
にその空いた分 別の仕事が増える からみたいなので 1分かける 今
までは1時間かける8個の仕事が 1分かける1000に増えて大変みたいな
そういうことになりかねないから むしろゼロにしていくっていう
確かにそうだね
おだしょー っていうのがあるなと思 って その視点に立ったときに やっぱ
人間って 人間がボトムネックになる ことのほうが圧倒的に多いから
難しいよね
おだしょー うん 最後 物を生産 するところのきっかけ自体は まだ
人間にあり続けるみたいなところ があるからね
おだしょー きっかけもだし 最初 アウトプットの確認とかも やっぱ
人間
おだしょー そうだね
おだしょー うん
おだしょー 極小化できるけどね だいぶ
おだしょー うん でも 本当にでも
おだしょー 反動作業
おだしょー うん
おだしょー うん
おだしょー そうだね 本当に でも 結局は やっぱり AIにどこまで
作業を移情できるか さっき言 ってた とりあえず作ってもらって
ゴリゴリイテレーション回して 改善するっていうのも どこまで
これをAIに移情できるか イテレーション 回すのも 全部自分がテストして
たりしたら かなり苦痛といえば 苦痛なのね
おだしょー うん
おだしょー うん うん
おだしょー うん うん うん
おだしょー 明後日の方向に行かない ような調整っていうのは必要かな
と思うんだけど 例えば クロード デザインとかで あらかじめデザイン
は固めておいて それを差分と ちゃんと正しく反映できるように
イテレーション回すような仕組み を作るとか
おだしょー うん
おだしょー うん うん うん
おだしょー うん なんか そっち側 の取り組みは 今まで以上に必要
になってくというか AI前提になる ときに 結構重要かなっていう
感じてますね
おだしょー 確かに ちなみに クロードデザインで はじめデザイン
を固めるほうが やりすぎ問題に ぶち当たるんで
おだしょー 確かに そうだね
おだしょー そう だから オープン コードでやったやつを クロード
デザインでやったほうが いいな っていう覚悟が
おだしょー 初手はね 今 例って 出したけど 本来は
おだしょー クロードをやりすぎる
おだしょー 記号設置的な話がある ので とりあえず 要件伝えて それ
に従った仕様を実装してもら ったのを クロードデザインに
取り除いてもらって 反映するって 本当のいいフローなんでしょ
けどね
おだしょー うん そんな感じかな 結構 長くなったね
おだしょー そうだね
おだしょー 思ったより激突は しなかったんで
はい
おだしょー 大丈夫か 聞いてる 人 何だこれ
おだしょー 全然 何だいったい 聞いてる
おだしょー まあ でも
おだしょー まあ それも含めて AI工房開発部の日常なんで
おだしょー そう いや 未だに葛藤 というか AIに結構 任せてると思う
し ただ 外せないって感じるところ が どうしてもポイントとしてある
ので そこをうまく言語化して伝え られたらいいんだろうなと思って
おだしょー うん
おだしょー どういうところに 課題があるの まだ 僕がちゃんと
言語化しきれてないと思っている ところがある
おだしょー まあ ちょっと あ そうだ Maxiね Maxi 僕は引き続き使って
いるんで もうCursorはアンインストール しようかなって思っています もう
Maxiだけでいいじゃんってなってます
おだしょー はい はい はい なるほど いや でも Maxi 本当にすごい
一番いい まあ CMaxがやっぱり今 一番話題というか Xとかでみんな
いいよって言ってるんですけど CMax 以上に機能は多いというか CMax
とかだと TypeScriptのファイル開こう とすると 別のファイル形式と誤認
されて オーディオが立ち上がる っていう TSファイルっていうのが
動画配信とかで使うファイルの 形式なんですけど TypeScriptも .ts
と同じ拡張機能の拡張子だから 違う って そういう細かいところでファイル
が開けないとか バグが多くて それに比べて Maxiが非常に ちゃん
とファイルも開けるし ディフも 見やすいし かなり
おだしょー 結構いいよね あとコミット メッセージ考えてくれる機能
とか どんどん追加されていってる し 機能拡張されていってる
大平 最近 プラグイン機能できた からね
おだしょー そうなん
大平 そうそう リリースはまだ できてないのかな プラグイン機能
作ってて 立ち上がるペンインの 見た目を変えたりとか まだ表示
する内容をカスタマイズできたり とか 作ってるみたいですよ
おだしょー そうなんや
大平 そう って言いつつ 僕は 毎日 Maxiを起動して とりあえず
使おうかなってするんですけど 最近はもう ターミナルに戻って
ます 結局 ターミナル T-Max NeoBeam が最強だなっていうところに落ち
ついてしまってるんで
おだしょー もう 俺はもう Maxi 一択ですね
大平 なるほどね 僕はもう これが LLMのありがたいことで やって
ほしいこと伝えたら 全部セット してくれるから Maxiに これ ちょっと
違和感あるな どうしようかなっていう のが 例えばあったとして それが
ターミナル上とかだったら AIに ここ ちょっと違和感あるんだけど
AI前提の開発と今後の展望
直してって言ったら さっと直って 使えるようになったりするから
T-MaxとNeoBeamでいいかもっていう 感覚に最近があった
おだしょー 俺 阿部ちゃんが整備 してくれないから 自分で整備し
きってたもんね
大平 いや 別に そうだね 勝手に 頑張ってって感じになるけど
おだしょー そんな感じで 今日は 以上となりました かなり白熱しました
ね
大平 そうですね
おだしょー じゃあ 本日もありがとうございました これで以上にできればと思います
おだしょー ありがとうございます
おだしょー 本日もAI駆動開発部 の日常をお聞きいただきありがとうございました
いかがでしたでしょうか 今回は ちょっとAI駆動開発の より生産性
を高く開発していくには みたいな ところで おそらく阿部ちゃんには
突っ込まれるだろうなと思いながら 聞いてるエンジニアの方もいたら
おそらく思うところあるだろう なというふうに思ったんですけ
れども ちょっと議論しがいがある 話題かなと思ったので この話を
してみました いかがでしたでしょうか こんな感じで 日々 AI駆動開発
しながら お互いに思ったことの 共有とかして 知見の共有とかも
していっているので ぜひ気に入って くれた方は いいねをフォロー
高評価お願いいたします それでは また次回もお楽しみください
バイバイ
はい
