開発AIエージェント(Cline等)の爆速開発を妨げる、人間の激遅な調査・意思決定・要件定義・案出しをNotebookLMで爆速化したいぞ・・・・！

## はじめに

ClaudeやClineなどのLLMを利用して開発を行うと、爆速で開発ができることは間違いありません。

私も使って自分の好みのアプリを作ってみましたが、土曜日１日で、ひと月の休みの半分使ったくらいの成果が出ました。

コードがほぼほぼ迷うことなく組まれ、高速でタイピングされていくんですからびっくりですね

しかし、コードの改善案を探したり、これからどうするかという方針を相談するには、自問自答したり、誰かと一緒に考える必要があります。

多くの開発者は、こんな感じでLLMにラブコールを送ってしまうことがあるでしょう。

![LLMへの質問例](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/96675/a40773c4-1988-4f88-b0ba-60b85057cda0.png)

正直Clineちゃんにソースコード全部読ませて、Claudeちゃんに解釈してもらいながら、私がどうでもいいことでも毎回相談していると、お金がいくらあっても足りません。少なくとも個人開発では厳しそうです。相談や、指示を厳選する必要があります。

そのため、Clineなどにはあらかじめやることを、できるだけ正確に伝えられるよう、準備する必要があります。

でも、ほんとの事言うと、コードを一緒に見ながら、「これどう思う？」「こうしたい」「それだめじゃね？」「それいいかも！」みたいな対話形式でのやり取りをもっと気軽にしたいです。

## NotebookLMでの実験

そういえば、最近、似たようなことをしてました。

![NotebookLMの使用例](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/96675/799b6f4f-842b-423f-a0a7-9e46149a0439.png)

NotebookLMは、テキストやPDFを読み込ませると、それを元に質問に答えたり出典を示してくれる機能を持っています。

長文もかなり正確に理解して、覚えていてくれます。

GoogleのNotebookLMに、競馬AIの論文を読み込ませて議論したことがありました。

研究内容の説明を受けながら

「それってこういうことじゃない？」

「それなんでなんだろ」

「精度出過ぎじゃない？大金持ちじゃん。」

といった対話形式の議論をしてました。

競馬AIの英語論文を読ませてみると、ある論文ではレースの対象が非常に絞られていたり、目的変数が明記されていないといった問題点も見つかりました。

NotebookLMは確か無料で使えますが、Gemini Advanceのサブスクに入っていると、いっぱいノートを作れたりしたはずです。確認してみてください

https://notebooklm.google/

## ソースコードでの活用

この体験から、「ソースコードを全部NotebookLMに読み込ませて議論すればいいのでは？」という発想に至りました。

そんなことを考えていた日、ちょうど、TwitterでソースコードをLLMが読みやすいようにまとめてくれるツールの話が流れてきたのを思い出しました。渡りに船ですね。

https://x.com/kakakakakku/status/1894594405753131240

一旦、読まれても問題ないような自分のリポジトリを元に読ませてみました。

具体的にはPythonで動画編集を行う、Moviepyを用いたプロジェクトです。

※この記事はGitingestの安全性を保証するものではありません

実際にこのフローを本格活用するとなると、自前でNotebookLMに読ませるファイルを作るスクリプトを書きたいですね。

## NotebookLMと会話しながらソースコードを相談する。

とりあえず、Gitingestでソースを１つにまとめて、NotebookLMに読ませて相談してみました

実際にNotebookLMとソースコードの相談を、実際にやってみた様子はこちらです：

https://x.com/masachaco/status/1895889059329032250

## もっと踏み込んだ内容を相談してみる。

NotebookLM自体は長めのテキストでも正確に記憶してくれる特性があるため、うまくいくだろうと予想していましたが、実際の結果は予想以上に良好でした。

読ませた動画生成プログラムは、複雑さが増すと動画の出力処理がどんどん重くなることが既知の問題でした。そこで、改善方法についてNotebookLMに相談してみました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/96675/138e927a-b4af-4dd5-974e-aac89afb6a0f.png)

ここらへんの話はすでに、考えてやってみたりしています。

上から目線で反論してみましょう。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/96675/73e1b333-1040-4118-9edb-1e530bfc7df7.png)

ちょっと、クリティカルな解決方法に繋がらなさそうです。


現状の問題点を更に上から目線で赤裸々に話してみます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/96675/11f39dcb-7e1e-4271-80a8-56124a43c546.png)

たしかにね！あらかじめまとめてリサイズしておけば、高速にできるかも。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/96675/19fc57d6-ea13-4845-9f04-94714779891e.png)


最初の質問をした後、私の考えを伝えつつ議論を進めたところ、「動画のリサイズに時間がかかっているため、それを最初からバッチでまとめて処理すればよい」という提案を得ることができました。

Moviepyがフレーム単位エフェクトを書けてで処理して時間がかかっていたものを、それらのエフェクトが得意なプログラムであらかじめまとめて処理して準備しておくことで、効率化できるかもですね。

まぁ、リサイズをあらかじめやっておくとすると、Moviepyの便利さが半減してしまいそう、、、というのもありますが、めちゃくちゃ遅くて困ってる現状なら処理フローを改善してみるのはアリそうですね。

仕事でこんな聞き方・そしたりしたら、険悪待ったなしですが、自問自答して、正直ベースで、案出し、ツッコミするならこれくらいの気持ち感でやれると、書いてる方は楽です。

癖になってリアルではやらないようにだけは、気をつけましょう。

## まとめ

NotebookLMを使ったコードレビューや改善提案の体験は非常に有意義でした。LLMとの対話形式でコードについて議論することで、新たな視点や改善案を得ることができます。特に、長いテキストや複数ファイルからなるコードベースに対しても効果的に機能することが分かりました。

今後もこのようなツールを活用して、より効率的な開発プロセスを構築していきたいと思います。