生成AIと音楽制作の体験
おはようございます、inadyです。この番組では、プログリッドでエンジニアをしているinadyが、AI活用術や最新ツール、開発生産性向上のノウハウをシェアします。
感想はハッシュタグでデブログfmまで。この番組はアップルポッドキャスト、スポティファイ、youtubeで配信しております。
ぜひ、お好きなプラットフォームからサブスクライブをお願いします。
最近ですね、SNOWというAIの音楽サービスで音楽を作ってみました。
初めて使ってみたんですけれども、音楽制作もAIでここまでできるんだってすごい感動しましたし、それほどお金はかからないんですね。
一番安いプランでサブスクライブしても、もう何百曲と音楽を作ることができるので、それも驚きポイントでした。
私は音楽のプロフェッショナルではない、全く素人なので、そもそも音楽を作るためにプロンプトを渡さないといけないんですけれども、
もう何もわからないので、ジェミニーと対話しながら、ああいう風にしたい、こういう風にしたいって話したものを、
じゃあそれをSNOWのプロンプトに変換してっていう風にプロンプトに変換してもらったものをそのまま渡していたんですけれども、
その出来上がった音楽に対してちょっと曲調を変えたいとか、メロディーライン、この辺、このベースラインのところをなんかちょっと変えたいなって思った時に、
それをプロンプトに落とし込むことができなくて、使うのを結局やめてしまいました。
気づきとしては音楽の理論を知らないので、具体的なAIに支持ができないっていうことが、自分の中ではすごく面白かった経験でした。
自分は普段からコードを書いていて、コードってある意味答えが1位に定まる、こういう答えが欲しいっていう結果は明らかなので、それに対してコードを書くっていうものだと思うんですけれども、
音楽とか絵っていうのは答えが1位に定まるものではなくて、結構幅が広いというか、ある意味無限に答えがあるものに対して、
こういう風にしたいっていうことをプロンプトにする、つまり言語化するっていうことをするためには、まずたくさんの経験がないといけない。
たくさん音楽を聴いているとか、たくさん絵を見てきた、それから音楽理論を知らないといけない。
そして、昔からどういう音楽が歴史的になって今に至るのかみたいなことを理解していないと、すごいプロンプト書くの難しいんだなっていう気づきがあって、最近楽しい経験をしたところです。
結局、私の中では音楽はプロに任せようという結果に至ったところです。
エンジニアリングの生産性の問題
では、今回のDevlog FMで話したいことなんですけれども、生成AIがすごく進化してもアウトプットのスピードが上がらないのはなぜかということについて話したいと思います。
私個人ですね、生成AIによってコードを書くスピードが少なくとも3倍、4倍ぐらいには上がっている体感があるんですけれども、
最終的な成果、つまりリリースの回数とか新しい試作の実行数は、その3倍、4倍コードを書くスピードに比べたらすごく少ない、あんまり増えていないというふうに感じています。
これはエンジニア業界に起きている話ではあるんですけれども、周りの職種の方と話してもそれが起きていると、エンジニアでなくてそれ以外の職種でもこの問題が起きているということに気づきがありました。
エンジニア界隈では生成AIを活用するというのが昨年からすごく盛り上がっていて、他の職種よりも一歩進んでいる部分ではあると思うんですけれども、
エンジニア界隈で起きていることを理解して、今どういうことがディスカッションされていて、私個人としてもどう考えているかということをアウトプットした上で、
それ以外の職種の方にも応用ができるんじゃないかなというふうに思って、今日はその話をしたいというふうに思っております。
まず事実の確認からしていきたいんですけれども、スタックオーバーフローというサイトがあって、そこの調査によるとエンジニアの84%がAIエージェントを使ってコードを書いていると昨年回答しています。
なのでほとんどの全ての人がコードをAIで書いているという前提の世界になっていますという前提でこれから話していきます。
その上でGitHubのレポートによると、コードの変更量は2024年と2025年に比べてなんと25%も増えていたという結果が出ています。
これはGitHubに上がっている量なので、それが25%増えているということは、ローカルで開発しているコードの生産量ってもっともっとその倍ぐらい増えているというふうに私は捉えています。
一方で別のレポートで言われているのは、AI生産性のパラドックスというものがあるという話です。
生産性向上の要因分析
つまり私がさっき一番最初に話したように、コードを書く量が増えてにも関わらず会社全体の指標、つまり売上とかそういったものに何も変化が起きていないということが起きていますというレポートが出ていて、
私が感じていることと実際に調査会社が調べて出てきた結果というのが一緒でしたというところの事実の確認をまずしたいというふうに思います。
その上で生産性が向上しない要因というのをまずドリルダウンして考えていきたいと思います。
その後に具体的にどうしたらいいかという話をちょっと持っていきたいというふうに思っています。
まずドリルダウンの一つ目なんですけれども、人間が今まで以上にボトルネックになっているからというのが生産性が上がっていかない要因ではないかというふうに考えています。
これもGitHubのレポートなんですけれども、そのレポートによるとコードレビューのする時間が2024年から2025年、一昨年から去年にかけて91%も増えたという調査報告があります。
ほぼ倍に増えているということですね。
非エンジニアの方のために説明するとコードレビューというのは、自分が書いたコードを他の人に見てもらってから最終的に反映してお客様にそのサービスを提供するというプロセスです。
これは他の職種に例えると、それでもよくやっていると思うんですけれども、冗長に対してメールとか資料を一回確認してもらっていいですかというのをやると思うんですが、エンジニアはそれを昔から日常的にやっています。
基本的にはレビュープロセスというのは必須になっていて、レビューが通って誰かの承認がつかないと、それがコードとして本番環境に反映されていかないというワークフローを脈々とやっているわけです。
これを何でやっているかというと、生成AIが出る時代の前からずっとやっているんですけれども、これは品質を担保するためにやっています。
自分が書いたコードというのは自分の中では完璧だと思って出しているかもしれないんですけれども、他の観点、それからもっと知識の多いシニアのエンジニアが見ると、こういう部分まだ考慮が足りていないよとか、
この辺ちょっと間違いがあるよとか、バグがありそうだとか、セキュリティに問題がありそうだみたいなことをお互いに確認しながらお互い足りない知識を補って品質を担保するという仕組みになっています。
このコードの品質を保つための素晴らしい仕組み、このコードレビューなんですけれども、このコードレビューによってある意味コードを書くスピードが上がっているに対して生産性が増えていないという要因があるんじゃないかというふうに捉えています。
これはいくらコードを早く書けても、要は3倍、4倍とコードを書く量が増えても、コードをレビューするというプロセスは必ず人間がやらないといけないので、誰かにお願いをして、お願いされた方もすぐに作業することはできなくて、自分もコードを書いていたりとか、他の人とミーティング中だとか、いろんな要因があると思うんですけれども、すぐにはレビューできません。
ようやくレビューの番が回ってきて、確認をして、問題があるからコメントをしてそれを返して、返された方もまた作業をしている途中だったりするとすぐには見れないので、また時間が来るまで待って、それを確認してまた返して、コードを修正してというプロセスをやっているんですね。
ここはAIで最適化あまりされていなくて、人間同士の時間の奪い合いみたいなことが起きています。
これは他の職種でも応用できるかなと考えていて、例えばメールを書いて、そのメールを冗長に1回確認すると確認待ちですと、それから取引先さまにその実際のメールを送りました。
送ったメールが先方が確認するまで待っていますとか、それが返ってきてある程度道筋が決まった上で倫理を書きますとか契約書を書きますというときにその倫理のワークフローとか契約書のワークフローが終わるまで待つみたいなことが起きるんですね。
結局他の職種においてもチャットGBTとかジミニとかを使ってアウトプットのスピード自体は上がっているんだけれども、そこの間最後のプロセスに行くまでに人間というものが返すことによって最終的なスピードが結局上がっていかないということになっているというふうに捉えています。
次に最終的なアウトプットのスピードが上がっていかない理由というのが理解の不採というものです。
これはコンプリヘンションでと言うんですけれども英語ではエンジニアで言うとコードを理解していないままチャットGBTとかジミニとかカーサーとかクロードとかで出てきたコードをそのまま使ってそのまま反映してしまうことによってつまり中身を理解していないわけですよね。
それで一旦反映しちゃうんだけれどもいつかその中身を理解しないとコードの変更とかができないのでそれを返さないといけないとつまり不採になっているという例えなんですね。
これはエンジニアで例えると理解していないコードをリリースするとそれが例えば後々障害が起きたとしますと。
AIによる生産性の限界
障害が起きたときにそのコードを読まないといけないんですけれども自分が書いているコードではないのでチャットGBTとか書いているコードなので何でこの障害が起きたのかどういうコードによってそれがもたわされたのかどうやって解決したらいいのか。
ましてやその自分が書いたコードで障害が起きたなんて思ってもいないみたいなことが起きていますというのが理解の不採ですね。
結局その障害が起きたときにAIが書いたコードを結局01で見ないといけないと。
生産性がせっかく上がったのに対してまた手戻りをしてチェックしないといけないということで不採になっているから結局プラスマイナスで生産性が上がってないですよねという話です。
これも私他の部署の方とか他の業種の方といろいろ話してエンジニアでは今こういうことが起きてるんですよねみたいな雑談をするともちろん他の部署でも同じようなことが起きているということをよく聞きます。
あるあるの話が部下自分が上長だとして部下がメールを書いてそれのチェックをしてほしいと依頼が来ましたと。
その内容はチャットGPTでほぼ全部書いていてこれなんでこういうふうに書いたのって聞いたらチャットGPTがこうやってこれがいいって言ったんでみたいなところでそこの書いた文章に対してなんでこれがいいのかっていうのを持っていないということが起きています。
なので結局何かを修正しないといけないときに最初からまた理解しないといけないわけですよねチャットGPTが書いたメールがどういう意図で書いたのかということを振り返っていかないと結局いいメールっていうのは書くことができないんですけれどもそれができていないというところです。
ここでちょっと一個だけ言及しておきたいのはチャットGPTを使って生産性が上がっているので短期的には決して悪いことではないかなというふうに考えています。
つまりはチャットGPTを使うなと言っているわけではなくてチャットGPTを使って中身を理解しないままずっとずっと進んでしまうとその理解していない不細がいっぱい溜まっているんですよねってことをまず理解しておきましょうっていうことが大事だというふうに考えています。
ボトルネックの解消
ではですねこれらの課題に対してどうやって解決したらいいかという話を最後にしていきたいんですけれどもこれは私の中ではまだ答えが見つかっていないこれがベストですということは出ていないんですので仮説の話になるんですけれども次のようなことが考えられるかなというふうに思っています。
まず1個目がさっきレビュープロセスの人間のボトルネックの話をしましたけれどもやはりこの人間のボトルネックをいかに減らすかというところが大事なポイントだなというふうに思っています。
今までAI時代の前までの業務プロセスがありますよね。今やっていることって何かというと昔からやっている業務プロセスに対してここの部分AIにできるコード書くところがAIにできますねとかコードレビューの一部もAIにできますねとかそういうふうに昔からあるワークプロセスをAIで置き換えるみたいなことをやっているんですけれどもそうしているとどうしても人間のボトルネックはなくならないわけですよね。
ここはちょっとAIにできないからちょっと自分でやろうみたいなふうになって結局そこでスタックしてしまうという話です。
例えばですけどコードレビューは絶対必要だと昔からずっとやっているからこれは絶対意味があるんだというふうに捉えてやり続けるっていうところではなく一旦アンラーニングする必要があるかなというふうに思っています。
昔からやってるからコードレビューをしなきゃいけない。コードレビューがなくなってしまったら品質が下がるから怖いからやりたくないとか自分の仕事がなくなってしまうからこのプロセスは絶対自分がやるみたいなことがあると思うんですけれどもそれを一旦ある意味忘れてもう一回ゼロベースでこのAI時代本当にこれは自分がやらないといけないのかと。
AIでやらせることができないのかと本当が人間として本当に価値が提供できる部分にフォーカスすることができないのかということを改めてゼロベースで考えていく必要があるというふうに考えています。
このゼロベースで考えることができた企業、つまり今コードの書く量が3倍4倍に増えているわけですよね。
これが今は例えばコードレビューによってギュッと立足されて結局今昔通り1倍のスピードしか出ていないというのをどこかボトルネックが解消できた企業はこの3倍4倍のコードがもしそのままスルーして繁栄まで持っていくことができれば他社より3倍4倍生産性が上がるし
下手したら3倍4倍とまではいかないかもしれませんけれども2倍とかそれぐらいもしかしたら売上が増えていくかもしれない利益が増えていくかもしれないということは明らかですよね。
なので今このボトルネックがありますということをただただ受け入れるのではなく他社はそれをもしかしたら解消して自分たちよりもめちゃめちゃスピードがあって今は自分の会社よりも売上が下で2番手とか3番手とか見ているかもしれないけれども半年もしないうちにガンと抜かされるかもしれないということを真面目に考える必要があります。
具体的な進め方なんですけれども例えばコードレビューを例えるとコードレビューがスタックしているからもっとエンジニアを増やそうと今3人なのを5人にしましょう10人にしましょうっていうと解決しそうな気がしますよね。
でも解決しないんですね。なぜかというとまず一つ目はエンジニアの数が増えるのでその分コードの書く量もまた2倍3倍に増えるので結局レビュープロセスがスタックするという問題とそれからこのボトルネックを解消するために人を雇うということを常にやっていては結局人件費というものが常に常に増えていってしまうので費用対効果という面の生産性が上がっていかないというところがあるので
昔からやっている人間のプロセスをもう1回ゼロベースで考えてみてこれって今の時代AI時代において本当に全部人間がやる必要があるんだっけってところを全部棚卸しをして1個1個検証して場合によっては試しに1回やめてみるある程度ルールを決める必要はあると思うんですけども簡単にルールを決めた上で試しにやめてみるスキップしてみる順番を入れ替えてみるってことをいろいろ試してみることが大事だというふうに捉えています。
もう一つは自動化するって話なんですけれどもNATNとかDeFiみたいなワークフローのオートメーションツールを使ってそもそも人間が関与しない人間関与ゼロで物事が進んでいくプロセスをできるだけたくさん作るってことをやると人間のボトルネックを省いて生産性が急激に上がっていく世界が来るんじゃないかなというふうに思っています。
なので最近NATNとかDeFiみたいなワークフローのオートメーションツールが盛り上がっているかというところはここに一端があるのではないかというふうに私は捉えています。
理解の不採用
2番目の問題理解の不採用をどう解決するかというところなんですがこれの解決策をウェブとかで調べるとAIを使わない週間ウィークリーを定期的に作ると月に一回第一週はAIを使わずにやりましょうっていう案みたいなのは結構出てくるんですけれども個人的な考え方としてはこれ全くワークしないというふうに思っています。
これはAIとコーディングに例えるとちょっとわかりにくいんですけれども経理処理においてエクセルとか電卓みたいなすごい便利なものがあるにもかかわらず毎月第一週はエクセル電卓は使わず全部手計算しなさいって言ってるようなもんじゃないかなというふうに私は思っているんです。
この使うなって言いたくなるマネージャーの気持ちはすごくわかります。使わなければ元々計算の例で言うと手計算のやり方っていう基本がわかっていないとできないのでそれを強制的にやらせるって意味で言いたくなる気持ちはわかるんですけれどもそれを言われたメンバーの気持ちってことを考える必要があるというふうに思っています。
要は毎月第一週目はエクセルも電卓も使えないとつまり手計算で全部やらないといけないそうすると仕事の進むスピードがものすごく遅くなって残業が増えるだとか他の方はもしかしたらエクセル電卓使ってるかもしれません。
そういう人たちに比べてパフォーマンスがある意味下がってるように見えるので評価の時とかに結局低い評価になってしまうんじゃないかと恐れが出てくるとそういった問題がある。
なのでこのAIを使わない習慣を定期的に作るっていうのはマネージャーとして上長の立場としてメンバーに言いたくなる気持ちはすごくわかるんですけれどもそれをもし自分が言われたらどう思うかということを振り返って考える必要があります。
じゃあこのAI使わないウィークを作らずにどうやって理解の塞いを解消するかというとエクセル電卓の例で言うと3桁と3桁の足し算をしただけれども結果が100桁になったという時に極端な例で言うと計算をしたことがない人が突然エクセルでやって足し算ってことをやったことがないけれども
これをエンジニアに置き換えて言うと極端な例ですけれども何も知りもしない開発言語プログラミング言語を生成AIで書いてそれをそのまま本番環境で作るというのが大事だというふうに思っています。
それをエンジニアに置き換えて言うと極端な例ですけれども何も知りもしない開発言語プログラミング言語を生成AIで書いてそれをそのまま本番環境で使っているというそういう人がいたとしてその人に対してどういうアプローチをするかというとAI使わないウィークを作るのではなくその言語についての基本的な理論を書いている本を何冊か読んでもらって理解をしてもらうとか
その言語に対する資格があるものはあるのでそういったものを取ってもらってある程度中級とか上級とかまで取ってもらうというところがまず一つですね。
気づきのフックを作る重要性
もう一つは開発言語にとらわれない例えばアーキテクチャーの話とかデータ構造の話とか場合によってはコミュニケーションの話みたいなのがあると思うんですけどそういう個別具体の開発言語の話だけではなくてその周りにある様々な基礎知識応用知識を本とかそれこそポッドキャストとかで仕入れと理解するということをメンバーに対して提案してみるというところは一つアプローチかなというふうに私は思っています。
もう一つアプローチがあるのは気づきのフックをたくさん作るということです。
メールの例えで言うと自分の会社の名乗り方っていうのは会社名を書く弊社とか当社とか自社とかいろんなパターンがありますけれどもそもそもそういうパターンがいっぱいある。
使い分けをする必要があるってことをそもそも気づいていないとそれを調べようと思ったりとかチャットLGBT調べようと思ったりジェミニで調べようと思ったりすることもない。
調べようという好奇心も沸かないってことが起きますよね。
なのでメールであればそのメールの書き方みたいな基本的な本を読むであるとかそれからプロフェッショナルな営業パーソンが書いている実践的な応用の本を読むみたいなことによって自分の中で気づきのフックをたくさん作るというのがまず一つです。
それからメンバーを育てる上長の立場から言うとこのメールに対してこうはこうだあーだって指摘をする直してあげるっていう風なやり方があると思うんですけれども
今は調べるってことについてはチャットGPTの方が正直上長が言うよりもチャットGPTの方がより詳しく知っているのでここはあーだこうだっていうことよりもメンバーにそのたくさんの気づきを持たせてあげるフックをたくさん持たせてあげるっていう壁打ちをするのが大事になってきてるんじゃないかなという風に思っています。
次に弊社当社の例で言うとここって弊社って書いてるけどどうして弊社って書いたのみたいな疑問で返すみたいなところですね。
その疑問に対してチャットGPTがこうやって書いてるからそのまま使いましたって言われたら当社とか弊社とか自社とかそれこそ自分の会社の名前を書くとかいろんなオプションがあるからどれがいいかちょっと考えてみたらどうとかあとその文のフォーマットですねあとは体裁とか話の等みたいなところに対してもここってなんでこういう風にしたのみたいなことをたくさん話しかけるとそうすると言われた本人はそういうパターンがあるのとかそういうオプションがあるのねって
だんだん好奇心が湧いてくるわけですよね。この好奇心さえ分けさえすれば今はいろんなツールで調べることができるのでそれで徐々に理解の不細を解消していくというアプローチです。
理解の深化とボトルネック
メンバーにおいてもその言われた本に対してもこの気づきのフックを作るための方法があってそれはいろんなフィードバックがありますよねとか本を読みますよねとか応用的な本を読みます。
情緒から言われましたってことに対して好奇心を持たないといけないってことです。
結局あーだこうだ言われたとしてもそれをその後なんでだろうとか調べないと結局チャットGPTに言われっぱなしのものをずっと使い続けることになるので
チャットGPTが書いた文章に対してなんでこうしたんだろうとか情緒もなんかここどうしてこういう風にしたのって言ってたなとか
本でもここをこういう風に書いた方がいいって書いてたのみたいなことを好奇心を持って調べてみようという好奇心を持たないと結局不細を解消することができないので
そういうマインドセットを持つことが非常に大事だなというふうに考えています。
ここまで人間のボトルネックの話と理解の不細の解消の話したんですけれども他にもいろんな解決方法があると思いますけれども
今時点での私の考え方をちょっと話してみました。
またちょっと新しいアプローチとか実際にやってみてどうだったかみたいなことはまたいつかのポッドキャストで話せればなというふうに思っております。
ということで今回は生成AIが進化してもアウトプットのスピードが上がらないのは何でかという話をしてみました。
それでは次回の配信でお会いしましょう。ご視聴ありがとうございました。
