掲題の通り、アプリを作ろうとおもって断念した話、イェイ
はじめに
最近社内でLLMを使った評価を作っていることもあり、それ関連のアプリを練習がてらなにかしら作りたいなぁと思っていました。
まぁコーディングはほぼバイブスと仕様駆動開発によるもので、ほぼAIくんが書いたものを採用するだけなんですけど。
けっこうYouTubeで漫才とかコントとかお笑いを見ることがあって。
ぜんぜん偏見なんですけど、自分から「お笑い好きなんですよね」って言うの、めっちゃ恥ずかしいというか、
べつにそんなんちゃうわ！っていう、ちょっと童貞みたいな感じの振る舞いをしてしまうんですよね。
あれ、なんなんでしょうね。
そんな感じのノリで、LLM as a Judge という考え方を使って、漫才を評価するアプリを作ってみようと思いました。（もう終わりましたが）M-1も近いしちょうどいいだろうとか思って始めました。 最近はClaudeCodeとか使って脳死でリリースはしない個人開発することが多いですね、Youtube見てるみたいな感じの趣味と言っていいのだろうかわからない時間の浪費をしています。
なぜ漫才だったか
これChatGPTに書けって言われて書かされてるんですが、題材として漫才を選んだのも、深い理由があったわけではなく、単によく見ているし、評価しづらそうでちょうど良さそうだった、くらいの感じでした。
特別に詳しいわけでもないし、語れるほど好きという感じでもない。
ただ、「評価する」となると、漫才はかなり難しそうだなと思いました。何が正解か分からないし、点数を付ける理由も曖昧だし、人に聞いても全然違うことを言いそうです。
だからこそ、LLMに投げるとそれっぽい結果が返ってきそうだな、という雑な期待がありました。当たるかどうかは正直どうでもよくて、「評価っぽいもの」が出てくるかどうかを見てみたかった、というのが本音です。
いわゆるお笑い論みたいな違和感が最初からあったわけでもなく、面白さを言語化したかった、みたいな高尚な動機でもありません。その時点では、そこまで真面目に考えていなかったと思います。
どう評価させるつもりだったか
これもあんまり考えてなかったですが、とりあえずAIに聞いたらなんかそれっぽい指標出るやろ、っていうノリで始めてます。
- とりあえず100点満点みたいな、分かりやすい点数は出したい
- 全体をまとめた総合スコア。いわゆる100点満点の点数。
- 1つの点数だけだとつまらないので、内訳も欲しい
- 各項目には0〜10点くらいの点数が付いていて、その内訳として、台本寄りの観点と、現場寄りの観点に分かれた項目がいくつか。
- 理由もそれっぽく書いてくれれば十分
- それぞれに「なぜその点数になったのか」を説明する短いコメントが付いてくる。
- 全体をまとめた総評っぽい文章が返ってくる。
- 正解かどうかはそこまで重要じゃない
- 毎回同じ基準で見てくれるなら、それでいい
- 人がやるとブレるので、AIの方がむしろ向いてそう
このくらいの期待値で、「AIに聞いたらなんかそれっぽい指標出るやろ」というノリで始めています。ただやっぱり「面白い」っていう感覚をAIに任せるのは難しいよね、みたいなことは思ってはいました。
というわけで出てきたルーブリック（評価項目・観点・基準）は下記。返ってきた項目をざっくり見ると、だいたい「台本寄り」と「現場寄り」に分けて作るようにしました。
台本寄りの観点
- ネタの設定やコンセプト
- 構成の分かりやすさ
- アイデアの新しさ
- ボケや展開の作り方
- 言葉選びやフレーズのキレ
現場寄りの観点
- テンポや間の取り方
- 声の強さや抑揚
- ボケとツッコミの掛け合い
- その場のノリやアドリブっぽさ
- 観客の反応や盛り上がり
ここに出しているのは最終的な形ですが、もちろん最初から一発でこの構成が出てきたわけではありません。
実際には何度かやり取りを重ねていますし、使える素材が音声のみという制約もあったので、評価項目としてはこのあたりが妥当かな、という落としどころになっています。
正直なところ、この先にやろうと思えば、まだいくらでもやれることはありました。ルーブリック（評価基準・項目）をもっと細かく分けたり、プロンプトを工夫したり、精度改善のためのテクニックを入れたり。それでなんかいろいろ試行錯誤できたら良かったんですが、後述する制約の問題を考えると、公開できる形にはならないため、ここで作業を止める判断をしました。
後述する制約の話をする前に、まずはこのアプリがどんな技術構成だったのかだけ整理しておきます。
技術構成（制約の前提）
技術的な構成としては、だいたい以下のような感じです。
- フロントエンド：Next.js + TypeScript
- バックエンド：API（Firestoreを永続化に使用）
- LLM：Gemini（マルチモーダル入力）
- 入力：音声（必要に応じて字幕）
全体としては、音声（必要であれば字幕も）を入力として受け取り、それをLLMに投げて評価結果を返す、というかなり単純な構成です。本来であれば、動画を丸ごと入力として評価する方が筋はいいと思っています。表情や動き、間の取り方など、音声だけでは拾えない要素も多いので。ただ、MVPとしては難しくなるしそこまでやらなくてもいいかな、という判断で、最初は音声のみを入力にする構成にしました。
評価自体はLLMに任せていて、いわゆる LLM as a Judge という形です。点数と簡単な理由を、ある程度固定したフォーマットで返させています。評価に使っていたモデルは、Gemini 2.5 Flash です。特に理由があったというよりは、無料枠で気軽に試せて、音声を含むマルチモーダル入力が扱えた、というのが大きいです。
公開できないと判断した理由
結論から書くと、この構成のままでは一般向けのサービスとして公開するのは難しいと判断しました。
理由はいくつかありますが、いずれも技術的・運用的な問題というより、入力として扱っているデータの性質に起因するものです。
想定していた体験としては、かなりシンプルなものです。
- 「この動画って何点なんだろう？」と思ったときに、YouTubeのURLを入力すると、AIが評価して点数を返す
- 評価結果は単発で終わらせず、他の動画と一緒にランキング形式で並び、気になったものから元の動画に辿れる
- いわゆるレビューサイトというより、「点数をフックにして動画を見に行くための導線」のような体験
ただ、この体験を成立させるためには、いくつか避けられない前提があります。
- 評価の入力として、音声データを扱う必要があること
- その音声が、YouTubeなどの外部動画コンテンツ由来になること
- 音声をそのままLLMに送って評価させる構成になっていること
- これを不特定多数のユーザーが使える形で提供することになる点
問題は、これら体験を成立させるために必要な前提が、一般向けサービスとしてはかなり危ういところにある、という点でした。これを不特定多数のユーザーが使える形で提供するとなると、入力の権利関係、データの取り扱い、第三者サービスへの送信など、サービス提供者側で責任を持たなければならない前提が一気に増えます。。
これらを踏まえると、たとえ評価結果の閲覧のみであっても少なくとも個人開発の延長線上で、「ちょっと公開してみる」ような形で扱えるものではない、という判断になりました。
悔しいです！
作ってみてどうだったか
「正直なところ、個人開発としてはちょうどいい体験だったな、と思っています。」ってChatGPTに提案されましたが、そんなことはぜんぜん思っていません。途中で止まってしまった感じの方が強いです。残念です。
もうちょっとLLM as a Judgeはもうちょっと勉強したり詰めれたと思いますし、LLMによる評価を実際に使って解像度高めたり、あわよくば人に使ってもらえたらなぁ〜とか思いました。
ちなみに開発自体はClaude Codeによるコーディングでほぼ全てやっていて、仕様駆動開発のツールとしてはcc-sddを使っています。ここまであるスクショも全てAIが作ってくれたものです。
一方、今回別のアプリも並行して作ってて思ったのは、デザインが弱いですね。Figma MakeでとりあえずそれっぽいプロトタイプみたいなのはReactベースで作れるんですが、技術的問題だったりデザイン的問題だったりをうまく解決できなかったり、洗練できなかったりしますね。やはりそこはFigmaを使って細かくやったり引き出しを増やさないと胃いけないんだろうなぁ。デザイナーは偉大。。。
まとめ
とりあえず作るのは簡単、プロダクトレベルは難しい、といった当たり前のことを学びました。
ChatGPTによると「AI時代に、何が自分のボトルネックとして残るかが見えた記録」と評されました。どこがだ？って思ったので聞くと
あなたの場合、AI時代に残ったボトルネックは、
- 「公開できる体験」に落とす最終判断と責任、「公開する／しないを決める最後の一線」
- 「雑に作れる」ことと「洗練させる」ことの断絶、「洗練させる感覚」
- 違和感の最後の1mm を潰すのは、人間側の審美眼と引き出しです
- もう一段やり切るかどうかを決める意志と執着
です。これはどれも、AIが肩代わりできない・コード量やスピードでは解決しない・経験と選択の問題
とのことです。
AIによるコーディングができるようになったことで、脳死でプロダクト？というかちょっとしたアプリをつくれるようになったのは暇つぶしっぽくて良いです。なんかちゃんとコーディングとか設計とか学ばないと・実践しないとなぁと思いますが、自分はどっちかというとできるものベースの方が好きなのかもしれません。
AIによるコーディングが台頭する前までは、わりといろんなことに気を配りながら少しずつ着実にやっていったものが、なんかいい感じにできてしまう体験は自分のコーディングとかそういうエンジニアリング力にとっては悪影響かもしれません・・・。まぁもはや僕よりはAIの方がコードを書けますしね。
ああ、健康になりたい。
コメント