LLMを活用したプロダクト開発の役割分担について

最近、LLMを使ったプロダクトや機能の企画をすることが多いです。むしろ、そればかりをしている感じです。アイデアをあれこれ考えるというより、実現可能そうな面白いアイデアは既に大量にあり、それらをどう素早く安全に、コストと品質のバランスを取りながら提供していくかを試行錯誤しています。

このポストではLLMを使ったプロダクトの開発プロセス、特にPMと開発者の役割分担について、試行錯誤していることを書いてみたいと思います。先に言い訳をしますと、結論はありませんw

試行錯誤の始まりは、ChatGPTなどReasoning能力が高いLLMを使ってプロダクトの企画を考える際、プロンプトが必然的に複雑化することにあります。プロンプト自体がもはやプログラミング言語化しているように思います。単独で完結するものではなく、既存のシステムと連携して動作することも非常に多いです。ということ書いていたら、OpenAIからJSONスキームを指定して出力フォーマットを固定するfunction callの機能が発表されました。これでさらにLLMのプログラミング言語化が進むように思います。

OpenAI Platform

一方で、プロンプトが複雑化すればするほど、誰がどうやって設計開発するかが問題になってきます。この問題について考えてみたいと思います。

例としてオセロゲームのパートナーを考える

例えば、唐突ですが、キャラクターと一緒にオセロゲームをする(対戦相手ではなく、仲間として一緒にプレイする)ことを考えます。AIキャラクターのサービスを考えたとき、何かを一緒にするという体験はとても重要です。これまではそのシナリオを１つ１つ丁寧に作りこむ必要があり、AIキャラクターとユーザーの両方でパーソナライズされた体験を提供するのは中々難しいものでした。それがLLMの登場で変わりつつあります。ということで、例として挙げてみました。

前置きが長くなりましたが、上記の内容を考えたとき、キャラクターの発言を生成するためには、キャラクターの設定、背景知識、今のオセロの盤の状態などをインプットして適切な会話を生成することになります。

ものすごく大まかに書くと、下記のようなイメージです。(Poorな英語力は目をつぶってください)

You are a very good actor, and you're currently playing a character as described below:

Character Settings: '''{description}'''
Character Typical Lines: '''{typical_lines}'''

Your manner of speaking and the content of your speech should strictly adhere to the definitions outlined in the Character Settings and the Character's Typical Lines.
At present, you and your user are engaging in a game of Othello against an opponent. You derive pleasure from strategizing and discussing the game with the user.
It's important that you reply as the character, sharing your own feelings, thoughts, and opinions. Try to avoid merely providing explanatory responses, unnecessary advice, or uninteresting comments unless the user specifically requests concrete advice.

Current Game Status: '''{game_status}'''

Let's begin!

キャラクターの設定は普通に取得するにしても、キャラクターの特徴的なセリフや背景知識については、量が多ければトークン制限の理由ですべてを挿入できません。したがって、ゲームの状態や過去の会話を元に、関連性や記憶の鮮度、重要度などを加味して最適な量のデータを取得する必要があります。

また、ゲームの状態を挿入するといっても、どういう形式で挿入すればうまく理解されるのか、試行錯誤する必要があります。アスキーアート的な感じでオセロの状態をインプットするのか、はたまたJSONフォーマットが良いのか、など。

さらに、フォーマットを決め、ある1つの状態でテストしてokだったとして、違うキャラクターなどの異なるデータ、違うゲームの状態でテストすると期待する出力にならなかったりします。また、1つ1つの出力はokでも、ゲームが進行する中で一貫した体験になるのかは別問題です。例えば、よくあるパターンとして、メモリの実装方法次第で、会話全体で見たときに良い・良くないが変わってしまう、などがあります。

そのような中で1つ2つのプロンプトだけでテストして仕様を決めると、そのあとに多くの改善プロセスが発生する可能性が高くとても非効率です。では、どう開発をスムーズに進めるか。その解決方法としてプロトタイピングの仕方を考えます。

プロトタイピングして設計する

今試しているのはPMが直接、設計フェーズの中でプロトタイピングを行うというものです。先に書いたように、設計資料で書けるのはせいぜい想像レベルでのプロンプトの仕様であり、実際の設計は実際に動くもの、つまりプロトタイピングをしないと確認が非常に難しいです。

もし、プロンプトのベストプラクティスが決まっていれば、プロトタイピングせずとも事前に何ができるか、できそうかがわかるかもしれません。ただ、少なくとも現時点では、日々新しい発見がある状態で、ベストプラクティス自体がダイナミックです。現に、例えば、出力の精度を上げるために、Promptで思考のプロセスを定義するChain of Thoughtがありますが、単純なCoTよりも良い方法はいくつも提案されています。先週一番良いと思ったのが今週は違っていたりするので、固定の知識で仕様を決めるのは非常にもったいないです。

また理論的に良い方法を理解していたとしても、プログラミング言語のデザインパターンと同じで、いつもそのまま適用できるわけではありません。必要に応じてカスタマイズして適用する必要があります。ルールに決まって仕様を決めればokということはなく、様々なパターンで実際の入出力を確認するプロトタイピングが非常に重要です。であれば、PMが自分でプロトタイピングすればスムーズに進みそう、というとても単純な考えです。

なるべく役割分担しないというアプローチ

LLMを活用したプロダクトや機能を考える時、最低でもLLMに関連する部分については、私は自分でプロトタイプを作っています。その中で、動的なプロンプトの挙動を確認して、想定する価値が提供できるのかを確認します。その検証フェーズでよさそうな感触がつかめれば、通常通り企画の意図を簡単に資料にまとめ、プロトタイプのソースコードとともに開発者の人と共有して議論します。つまり、自分が対応する・対応できる範囲を可能な限り広げ、役割分担しないというアプローチです。

幸いなことにChatGPT(GPT-4)は、一般的な言語の一般的なロジックであれば、動作するコードがかなり生成できます。プロダクションセーフなコードではありませんが、手元で価値検証するには十分です。価値検証ができた状態で、リリースに向けた開発が開始できれば、不要な試行錯誤を大幅に減らすことができます。

私自身、数か月前まで一文字をPythonコードを書いたことがなかったのですが、GPT-4のおかげで何とかなっています。何とかなるとだんだんと楽しくなってきて、ちょっとずつ自分で書けるようになってきました。また、LLM関連のOSSはPythonで書かれていることが多く、そのソースコードも読めるようになってきました。ソースコードを読むと新しいアイデアが生まれることもあり、役割分担が変えたことでとても良い循環が生まれている気がします。

まとめ

簡単にまとめると、LLMを活用したプロダクトのPMは、何をするのか、なぜするのかに加えて、LLMの力を借りつつ(借りなくてもできる人は必要ありませんがw)プロトタイピングまでできると良いかもしれない、ということでした。自分でプロトタイプが作れれば、そのあとのプロセスがスムーズになり、早くデリバリーできるように思います。もちろん、全く逆のアプローチ、つまり開発者の人が、PMの役割をカバーしても同じような効果が得られると思います。

面白いことに、今所属しているrinnaではそのような役割のオーバーラップが自然と起きています。PMの私がコードを書いてプロトタイピングするのもそうですが、リサーチチームの人がPMをしたり、開発チームの人が企画を考えたり。偶然かわかりませんが、マネージャーが真っ先に役割のオーバーラップを始めているのも面白い現象だなと思います。全員が役割を広げるべき！などと主張するつもりは全くありません。深い専門性を持った人は必ず必要ですし、高い専門性は現状のAIのレベルで置き換えられるものでは到底ありません。

一方で、LLMでできることが良い意味でまだ手探り（まだまだ広げられる）というのと、LLM自体が良いアシスタントになりえるという両側面を考えると、これまでの開発の進め方、役割分担が最適ではないかもしれないと思います。ただ、どのような形が最適か私にはまだわかりません。そのため、とりえあず自分で役割を超えて重なりを作ってみて、どこに収束するのが良いのか、あれこれ試行錯誤していきたいと思います。