Vibe Coding
コーディングエージェントを用いて、高速なアプリ開発を実施する。
プロダクトレベルを開発する場合、
- linter
- fomatter
- LSP
- コンパイラ
などの力を使って品質向上などを目指すが、こちらが考えている要件とAIが認知している要件にコードの肥大化に伴ってズレが生じることが有る。
ズレの是正として、AGENTS.mdのような入口を見出し化し、必要なドキュメントへのアクセスを可能とする。また同時にコンテキストを圧迫しすぎずハルシネーションを起こさないなどのテクニックが有る。
他にもコンテキストがクリーンな状態のエージェントにコードレビューを都度行わせるなど、品質向上のテクニックは色々存在するが、だいたい自分がやっているのはこの辺りになっている。
要件の合致はAI任せにするとどうしてもどこかで崩れやすい。これはコードが肥大化するに伴って破壊的要件変更や横展開の要件追加が発生したときに、もとからあった要件に引きづられてズレが発生したり、横展開した要件が基本要件と追従しない（別実装として切り分けられ、ロジックの定義がばらつく）などの問題が原因と考えている。
システマティックな方針としてはテストコードの充実によるロジックの担保で、UT,IT,E2Eなどを通じて定義した要件通りにコードが動いているかを確認する。
そのためテストコードのレビューのみを人間が十全に行うことで、コードの追加変更が発生したとしても、それぞれの要件の正しさをテストコードで担保することができるため、クリーンな開発を行いやすいというのが理屈の上では存在する。
ただしそれだけでもレビュー量が非常に多かったり、単純に可読性が低く理解が難しいなどの問題も発生する。
問題解決の他のアプローチとしてはPRを作成させ、それらのドメイン依存度や難易度と言ったものをタグ付けさせ、それの度合いが高いものだけ人間が目を通すなどが有る。
少なくとも現時点ですべての生成コードを目視で確認するというのは難しく、抽象的なレイヤでズレを拾ったり、目を通すコードを少なくする仕組みづくりが必要になっていると感じている。
生成AIによるリサーチ
これは多くの人にとって今後も大きく必要になってくると思う。自分の中ではフォーマットがある程度標準化された形であるので共有する
1.テーマの決定
これは自分がやりたいもので決める。具体性が高いほどリサーチの工程を減らすことができるため時短になるが、空振りになったときにそもそもテーマから変更することになる可能性が有る。
土台となるテーマを決定するというテーマでも良いが、抽象度が高くなるためリサーチの工程が増える。
2.事例の列挙
今回のケースでは仮に稼げそうなiOSアプリの企画の列挙とする。
このとき企画はできるだけスモールで具体性は低くて良い。とにかく多く出させると良い。
感覚的には9割はどうでもいいネタがでてくるが、1割ぐらいは「おっ」となるネタがでてくることが有るため、多ければ多いほどよい。AIをパワハラしていく
3.,事例の深堀
列挙させたものが100あったとして、粒度がAIを用いた植物識別アプリ。みたいなものの場合、そこから更に深掘りしてアイデアを出させる。
これは全く別の、例えば面白い企画みたいなアイデアで出させた場合で、深掘りさせる内容が変わってくる。
こういった何を深掘りさせるかはAIと相談しても良いと思うが、クリエイティビティを出せる要素なため自分で出したほうが良いし、優勢につながると思っている。
今回は結局稼げるかどうかは市場の状態によるため、競合アプリを50個を最大として列挙させる。
4.深掘り結果の確認、分析
100*50のデータをすべてチェックし、情報の正しさを検証したり、良さそうなものがあれば拾う
裏取りや面白いかどうかはAIにやらせるより、自分で確認したほうが良い。面白さやどういったものを調査させるかと言った部分は人間のほうが優位性が有ると思っていて、ここはAI頼りにしないほうが良いと思っているため。
ただ分析については定量的な評価指標を用意できるのであれば、システマティックにやることができるためAIにやらせて良い。
問えば挙げられた競合アプリすべてのレビューに書かれている内容をまとめてようやく。良い点悪い点を挙げさせる。その後、共通する良い点悪い点をまとめ、アイデアを考える。など
まとめ
AIリサーチのメインは2,3の部分のループに有ると思っていて、ここの処理は結構繰り返せる。例えば100件のアプリアイデアから50件の競合アプリの検索をさせ、さらにそこからそれぞれのレビュー記事や動画を50個とらせてレビューの確度を上げる。SNSでどれぐらい扱われているかどの用に扱われているかを調査する。なんて言うこともできる。
iOSアプリ企画>競合アプリ>レビューみたいな感じでもいいし、iOSアプリ企画にさらにそれぞれの企画の切り口を同階層で切ったりしても良い。
要するにAIリサーチの肝は超大量のデータを集めてきてくれる、柔軟なスクレイピング機能だと思っており、それを活用できればできるほど強力だと考えている。
deep researchなどを利用するのも良いが、結局あれは分析や確認の部分もAIになってしまっているため、調査結果をもとにアイデアを作り出すをAIにやらせてしまっている。
このアイデア捻出については明確に人間に優位性が有ると思っているため、できるだけデータを集めさせるという部分をAIにやらせるのが良いと考えている。
そういう意味では分析も人間が確認を通じてやっていると言えるけど、定量的な分析についてはAIにやらせる形でも十分だと思う。統計知識が十分に有るとかでなければ、定量的な分析はAIのほうが知識を持つため。
---
自分はこの２つしかやってない、とにかく柔軟なスクレイピングを以下に行わせるか？が重要だと思っているので、そこばかり深掘りしている。
また人間にやらせたら間違いなく過労死するレベルのデータ量を作成させるのも生成AIに優位性が有るため、量を担保させている。そこから質を作り出すのは人間の仕事というイメージ
できる限り確認コストを下げたいため、調査フォーマットを用意し、s3にアップロード。それをもとにスマホアプリから確認済み、favをできるようなアプリを作って、開発者モードでぶち込んでいる。
確認結果はdynamoDBに記録されるので、PC上であとはfavしたデータを確認したりしながらアイデアを考えたり、またスマホから眺めたりする。
大量のデータをばこばこ見るのはPCでは腰が重いと考えており、寝ながら適当に見れるような自分用データSNSみたいなのを作っていけたらなと思っている。
---
データ収集については（規約的には怪しい気がするが）claude codeをひたすらループで動かしている。やらせたい作業リストみたいなのから.shファイルを作成し、ひたすらclaudeコマンドが実行されていき、すべて完了した時点でdiscordへ通知が来る形とした。
何を調査させるのかのアイデア出しもやらせたいと考えているが、これは単純にAIにやらせると筋が悪い気がしている。
SNSやニュース系サイトを定期的にスクレイピングさせ、アイデアのストックを作成する方針で考えているが、先人の知恵を見る限りストックされたアイデアに引っ張られる問題があったりする様子。
調査結果をもとにどのデータが重要であるか判断するエージェントを切り分ければコンテキストがクリーンな状態で考えることが出来てよいのかなと思ってはいる。
個人的に生成AI時代はとにかくたくさん推論させたやつが強いよねというスタンスは変わらないのだけど、何を推論させるのかで結構悩んでいたが、柔軟なスクレイピングこそが優位性なのではと思ってきた。
スクレイピング自体はべつに今までも出来たが、非常に低コストで実施でき、さらに調査の深さもかなり深い。例えば特定のSNSのコメントを拾ったとして、そこに紐づくデータを調査し、アイデアを深めていく。なんていうのはコードで表現するのはかなり難しい
claudeがベクトル検索ではなくエージェント検索を土台にしたという記事を見たことが有るが、実際この調査力は生成AIはハチャメチャに強力で、調査力とスクレイピング能力が組み合わせがめちゃくちゃ強力な優位性を生んだのではないかと感じている。
そのため生成AIに何を推論させるかは一つが単一テーマに対するリサーチで、もう一つがリサーチするテーマの調査になるのかなと思った。
テーマの捻出についてはAIだよりにしてキューをつまらせてもつまらないなとは思うので、リサーチまでにとどめているが、これを読んで判断するのも結構大変な状態になっているため、どうしたら良いのか悩み中。
結局全てにおいて自分がボトルネックになっている。感覚的にはめちゃくちゃ仕事が早いやつに四六時中付きまとわれている管理職で、仕事を降ってさて溜まった仕事やるかーと思ったら10分で「終わりました！」と報告してくるやつが、ずっとついてくる。
みたいな状態で頭がおかしくなりそうではある。
---
生成AIとの関係性で今まで悩んでいたのは何を推論させるのか？だったのだけど、自分の中ではリサーチをさせることと、分析をさせること、コードを書かせること（プロダクトを作ること）の3つでFAという感じが有る。
そこで次の問題となってきたのが、大量に生成されたオブジェクトとの付き合い方で、コードにせよ、分析結果にせよ、リサーチ結果にせよ、しぬほど多い情報をぶつけられ続ける日々なため具合が悪くなる。
大量の情報を読むことは出来ない。っていう前提に立つと、どれだけ情報としての価値を失わない程度にAIに要約させるか？が課題だと思っているんだけど、暫定的に400文字ぐらいにしている。
たた要約としてみたいデータがテーマに紐づいてるなという気付きが最近あり、そうなると標準化されたリードアプリが向いてないという事実を突きつけられて困っている。
例えば今回例に出したiOSアプリのリサーチについては、競合のレビュー件数や評価なんかも合わせてみたかったりするけど、よく食べられている魚をリサーチさせたりしたら、どこでよく食べられているかとかどれぐらい食べられているか、漁獲量は、季節による違いは、月・週・曜日で違いは有るのか？
などちょっと異なるんだよなーとなっている。
optionalなオブジェクトを用意して、key:valueで作成した値を単に表示するとかでも良いのかもしれないけど、そういうことさせるとここの情報量がめっちゃ多くなっていたりして死んだりする。定量的な分析はまだいいんだけど、どういった部分に注目するかみたいなのが難しかったり、プロンプト一個投げてひたすら回すのはなんかいまいちだったりして難しい。
書いていて思ったけど自律性との向き合い方でも困っているのかもしれない。推論結果のリーディングと、どう自律させるかが今後の課題になりそう。もっと詳細に言うなら自律性って何を重要化判断させるっていう、判断の移譲なんだよな。自分はリサーチする対象までを移譲していて、リーディングが厳しいならデータの分析やアイデア出し。要するにリーディングとそれに連なる部分も移譲したほうが良いみたいな話になる。むずかしい
おわり
