AIコンパニオンを開発して分かった、チャット・画像・動画生成をつなぐプロダクト設計

生成AIを使ったプロダクトを作る場合、単純にLLMのAPIを接続するだけであれば、それほど難しくありません。

一方で、実際にユーザーが継続的に使うサービスを作ろうとすると、

• キャラクター設定
• 会話の一貫性
• 画像生成
• 動画生成
• コンテンツの保存
• コスト管理
• UX
• モデレーション

など、モデル以外の設計が非常に重要になります。

現在、私は Veline AI というAIコンパニオンサービスを開発しています。

この記事ではサービスそのものを紹介するというより、AIキャラクター、チャット、画像生成、動画生成を1つのプロダクトとして組み合わせる中で感じた設計上のポイントをまとめます。

1. AIコンパニオンは「チャットボット」だけでは成立しにくい

最初に考えたのは、LLMを利用してキャラクターと会話できる機能でした。

構成としては非常にシンプルです。

User
  ↓
Character Profile
  ↓
Conversation Context
  ↓
LLM
  ↓
Response

ただ、実際に作ってみると、LLMの回答品質だけを上げてもユーザー体験には限界があります。

ユーザーにとって重要なのは「AIの回答」そのものよりも、

同じキャラクターと継続してコミュニケーションしている感覚

だからです。

そこでVeline AI では、キャラクターにいくつかの属性を持たせています。

例えば、

{
  "personality": "romantic",
  "occupation": "doctor",
  "relationship": "neighbor",
  "conversation_style": "gentle"
}

のような情報です。

これらを会話生成時のコンテキストとして利用します。

重要なのは、毎回大量の設定をLLMへ渡すことではなく、「現在の会話で何が必要か」を判断して適切な情報だけを渡すことです。

コンテキストが長くなりすぎると、

• Tokenコストが増える
• レスポンスが遅くなる
• キャラクターの重要な設定が埋もれる

という問題が発生します。

2. Characterを中心にデータを設計する

チャット、画像、動画を別々の機能として作ると、ユーザーから見ると単なる「AIツール集」になってしまいます。

そこで、サービス内部ではCharacterを中心にデータを持たせる設計にしています。

イメージとしては以下です。

                ┌─ Chat
                │
Character ──────┼─ Image
                │
                ├─ Voice
                │
                └─ Video

つまり、

Chat → Image → Video

という機能中心ではなく、

Character → 各種Generation

という設計です。

これによって、ユーザーが作成した1人のキャラクターを複数の生成機能から利用できます。

個人的には、AIコンパニオン系サービスではこの考え方がかなり重要だと感じています。

3. 画像生成ではPromptを直接入力させすぎない

画像生成機能を実装する場合、最も簡単なのはユーザーにPrompt入力欄を提供することです。

例えば、

A woman wearing a black dress,
standing in a cafe,
cinematic lighting...

という形式です。

しかし一般ユーザーにとってPromptを書くこと自体が負担になります。

そのため、UIではできるだけ構造化した情報を選択してもらうようにしています。

例えば、

Scene
- Cafe
- Beach
- Bedroom
- Restaurant

Outfit
- Casual
- Dress
- Business
- Sportswear

Pose
- Standing
- Sitting
- Looking back
- Selfie

といった選択肢です。

内部ではこれらを組み合わせ、最終的なPromptを生成します。

Character
+ Scene
+ Outfit
+ Pose
+ Style
→ Final Prompt

ユーザーはPrompt Engineeringを意識する必要がありません。

これは生成AIプロダクトを作るときに個人的にかなり重要だと思っているポイントです。

モデルの能力をユーザーに直接操作させるのではなく、UI側で抽象化する。

モデルが高度になるほど、この設計は重要になってくると思います。

4. Image-to-VideoはUXが難しい

最近はImage-to-Videoモデルもかなり進化しています。

基本的なフローは、

Character
   ↓
Image Generation
   ↓
Generated Image
   ↓
Image-to-Video
   ↓
Video

です。

技術的にはAPIを呼び出すだけですが、実際のプロダクトでは生成時間が問題になります。

画像なら数秒〜数十秒でも許容されやすいですが、動画の場合はさらに時間がかかります。

そこで、

POST /video/generate

→ task_id

GET /video/status/{task_id}

→ processing

→ success

のような非同期Taskとして扱う必要があります。

ユーザーがページを閉じても生成処理は続き、完成後に「My Creations」のような一覧から確認できる設計にしておく方が自然です。

生成AIサービスでは、

GenerationとUI Sessionを分離する

ことが重要だと感じています。

5. モデルは固定しない方がいい

もう1つ感じているのが、生成モデルを1つに固定しない方が良いということです。

例えば画像生成でも、

Model A
- 高品質
- 高コスト
- 遅い

Model B
- 標準品質
- 低コスト
- 速い

という違いがあります。

すべてのリクエストで最高品質モデルを使うと、サービスとしてコストが成立しにくくなります。

そのため将来的には、

User Request
      ↓
Model Router
      ↓
 ┌────┴────┐
Fast Model Premium Model

のようなModel Routingも重要になると思っています。

ユーザーが求めている品質と、生成コスト・速度のバランスを取る必要があります。

特にVideo GenerationはImage Generationよりコスト差が大きいため、この問題が顕著です。

6. 無料体験をどこまで提供するか

生成AIサービスでは、無料ユーザーにもAPIコストが発生します。

例えば、

100 users
× 10 generations
× $0.02
= $20

程度なら問題ありません。

しかしユーザー数が増えると、

100,000 users
× 10 generations
× $0.02
= $20,000

になります。

そのため、

• 初回のみ無料
• Credits方式
• Daily Limit
• Modelごとに消費Creditsを変える

などの設計が必要になります。

特に画像や動画生成サービスの場合、

Conversion Rateだけでなく、無料ユーザー1人あたりのInference Cost

を見る必要があります。

これはSaaSとは少し違う生成AIサービス特有の指標だと思います。

7. AIコンパニオンではSafety設計も必要

AIキャラクターを扱う場合、生成機能だけでなくコンテンツモデレーションも重要です。

例えば、

Input
  ↓
Safety Check
  ↓
Prompt Generation
  ↓
Model
  ↓
Output Check
  ↓
User

という複数段階のチェックが必要になります。

特に外部の画像・動画生成APIを利用している場合、

「API側でフィルタリングされるから大丈夫」

と考えない方が安全です。

モデルごとにポリシーやフィルタリングの挙動が違うため、自分のサービス側でも一定の制御を入れる必要があります。

まとめ

AIコンパニオンを作っていて感じるのは、LLMやImage Generation Modelそのものよりも、

複数のAIモデルをどう1つのユーザー体験としてまとめるか

の方が難しいということです。

現在の構成をシンプルに表すと、

              ┌─ LLM
              │
Character ────┼─ Image Model
              │
              ├─ Voice Model
              │
              └─ Video Model

のようになっています。

今後はさらにModel RoutingやMemoryなども重要になると思っています。

生成AIプロダクトはモデルの進化が非常に速いため、特定のモデルに強く依存するよりも、

Product Layer
     ↓
AI Abstraction Layer
     ↓
Multiple Models

という構造にしておいた方が、新しいモデルへ移行しやすくなります。

Veline AIを開発しながら、このあたりは引き続き試行錯誤していく予定です。

参考までに、実際に開発しているサービスはこちらです。