LLMを活用してルームカスタマイズを自動化? ambrのフィジビリティスタディ
はじめに
最近ではGrokのAniがLLMを活用したサービスとして注目を集めていましたが、近年さまざまな分野でLLMを活用したサービスの開発が活発になっています。LLMがこれほど期待される理由の一つとして、チャット機能だけでなく構造化されたデータを取り扱える点があります。ambrでもLLMを活用したR&Dに取り組んでおり、本記事ではその一例を紹介します。
goghアプリの紹介
私たちは gogh というアプリを開発しています。
このアプリでは、アバターを作成し、部屋をカスタマイズすることで、アバターと一緒に楽しく勉強やデスクワークを行うタイマーアプリです。実はこの記事も、アプリ内のポモドーロタイマーを使用しながら執筆しています。
スマホアプリ版とSteam版がありますので、興味のある方はぜひお試しください → 公式サイト
今回のLLM活用の狙い
goghでは豊富なアイテムを使って自由度の高いルームカスタマイズを行うことができます。これはgoghの楽しさである一方で、「もっと手軽に部屋を衣替えしてみたい」や「デザインに自信はないけどおしゃれな部屋を作ってみたい」と考える方もいらっしゃると思います。そこで、今回LLMを活用したルームカスタマイズ機能のR&Dに取り組んでみました。
ユーザーが「モダンなカフェ風の部屋を作りたい!」や「机周りをすっきりさせたい!」といったリクエストを入力すると、LLMがそれを解釈し、レイアウトやアイテム配置を自動でカスタマイズする仕組みを目指します。
今回の試みはあくまでフィジビリティスタディなので、厳密なアーキテクチャやセキュリティは深掘りしていません。あくまで調査段階である点をご了承ください。
システム構成と流れ
今回はフットワークよく検討するため、Claude Desktopを活用し、MCPサーバー(LLMから外部情報にアクセスするための仕様)を介して部屋の編集機能を実現しています。
システム構成概要
- Claude Desktop: MCPサーバーと連携し、ユーザー入力を受け取る役割。
- 部屋表示アプリ: ルームJSONを読み込んで部屋を3D表示する簡易アプリ。
- MCPサーバー: ルームJSONやアイテムリストの取得、部屋表示アプリとやり取りする。
- ルームJSON: goghの部屋情報(アイテムの位置、親子関係、色など)を記述したデータ。
- アイテムリスト: 利用可能なアイテムの一覧。各アイテムの説明文(サムネイル画像からLLMで作成)やサイズ情報が記載。
図では簡易的に記述しましたが、実際にはMCPサーバーと部屋表示アプリの間にAPIサーバーが存在します。
処理の流れ
- Claude Desktopに部屋編集手順のプロンプトと部屋の要望(例: 「モダンなカフェ風の部屋」)を入力。
- MCPサーバー経由でルームJSONと部屋のスクリーンショットを取得。
- LLMが部屋のコンセプトを考え、アイテムリストを取得しJSONを編集。
現構成に至るまでに発生した問題とその解決策
LLMを用いて部屋内にアイテムを配置する際、幾つかの方法を試しました。初めはルームJSONを直接出力させる方法を採用しましたが、出力に時間がかかることや、誤ったJSONが生成される問題が発生しました。次に、JSONの代わりに独自定義のコマンドを列挙する方式を試みましたが、コマンドが正しく生成されないことが多く、期待通りの動作を得られず断念しました。
その後、情報のやり取りを柔軟に行えるようにすれば精度が向上するのではないかと考え、Unityを直接操作するMCPサーバーを用いたアイテム配置を試みました。しかし、未実装の正規表現を用いたり、アイテムリスト対象カテゴリのアイテム毎にMCPツールを余計に繰り返し呼び出すなどの問題が生じ、こちらも実現に至りませんでした。
これらの課題を踏まえ、LLMに不要な情報を渡さない専用のMCPツールを作成し、アイテム配置には独自仕様ではなくJQコマンドを介してJSONを操作する方法を採用したのが現在の構成となります。独自定義コマンドではなくLLMが既に学習済みであるJQを利用することで余分な説明を省略でき、MCPツールの操作精度も向上しました。また、与える情報を減らしたことでリクエストの理解と思考の精度の向上にも努めています。
細かなTipsと課題
- Claude Opus 4のThinkingモードで実行しました。実現可能性をまず確認したかったため最上位モデルを使っています。Thinkingモード不使用時はリクエストの理解とルーム編集の精度が低く、Thinkingモードを使用することで時間はかかるようになりましたが大幅に改善いたしました。
- Claude Opus 4の画像認識はそこまで精度が高くないため、スクリーンショットはあくまで参考としJSONベースでの思考を指示しています。
- 不要な情報、過度な情報をLLMに与えると精度が低くなる傾向があるため、JSONのインデントや不要なスペースを消し、アイテムリストは全て渡すのではなくカテゴリに分けて取得できるようにしています。
- ルームJSON取得時に含まれているアイテムの説明文章も付与し、LLMの余計なMCPツール呼び出しステップを削減しています。
- LLMは小数を正確に取り扱えないため、色や座標の値を整数に変換して扱いやすくしました。ただし、LLM上で算術を行う場合は精度に不安が残るため、専用のMCPで計算を分離させた方が良いかもしれません。
- JSONのデータ構造そのものがLLM側にとって直感的でなさそうな部分が多くあるようで、同じような過ちを繰り返し、かつ指示を付け加えても同様のミスが多く発生していました。
- 部屋をまっさらな状態から作り直したり、それを控えるように指示すると控えすぎてしまうなど扱いがピーキーでプロンプトの調整が難しそうでした。
- JQを使うことでデータの取り扱い精度が上がりましたが、関係ない部分を編集していまう可能性があるためプロダクトとして組み込む場合にはセキュリティ面なども含め要検討した方がいいです。
「カフェ風の部屋」で作成された例
リクエストに応じて部屋がアレンジされる例
試みを通して
- MCPツールを用意するだけでLLMがそれを使いこなせるというわけではなく、どういった順番でMCPツールを呼び出せばよいかの指示することも必要でした。また、今回JQコマンドを介したことで精度が上がったように、独自の仕様を使うよりもLLMが学習済みの一般的な仕様を使う方が適切にMCPツールを利用でき、質が向上するのかもしれません。
- LLMでの機能改善はモデルごとの出力傾向も異なることからも、欲しい結果を得るための開発手法の体系化が難しいと感じました。例えば、今回うまく行っても新しいモデルでは本当にうまく動くのか正直なところ分かりませんし、個々の改善の効果測定も判別が難しかったです。一方で情報をスリム化したりシンプルにすることはモデルに依らず効果が認められたので、こういった知見を集約して行きたいです。
- LLMを利用した開発に限らないですが、どの程度のクオリティ、どの程度の早さで動作ができたらゴールとして良いのかが判断が難しく、どこからどのように着手すべきか悩むことがよくありました。そのうちプロンプトエンジニアリングを含めたプロダクトの開発管理フレームワークも出てくるのかもしれません。
最後に
以上、ambrでのLLMを使った取り組みの一つを紹介しました。
ambrに限らず今後もLLMを活用したサービスやアプリが増えていくことかと思います。LLMを使った開発は多くの課題がありますが、人類の進歩と調和を大切に、積極的に慎重に取り組んでいきたいものです。
※今回のLLMによるルームカスタマイズ機能は現時点で公開中のgoghには実装されておらず、また具体的な実装予定もありません。社内R&Dの範囲で取り組んだプロジェクトになります。
※goghにおけるキャラクター、アイテム、楽曲等はすべて社内外のクリエイターやアーティストが制作したものになります。
Discussion