Wrtn AI Case Studies
Wrtnでは、月間アクティブユーザー数が500万人を超えるAIプラットフォームと、AIキャラクターチャットサービスに携わっていました。以下の3つのケーススタディでは、これらの体験を設計し、公開する中で私が取り組んだ主要なプロダクト課題をご紹介します。
言語を選択してください：
Case Study 1
Visual Novel Redesign
Case Study 2
Input Field AB Testing
Case Study 3
Image Studio
Case Study #1
AI生成の限界を踏まえたビジュアルノベル体験の再設計
Team
1 PM, 1 Designer, 3 Engineers
Role
Sole Product Designer
Timeline
Nov-Dec 2025, Mar-Apr 2026
Platform
Web, iOS, Android
Overview
Kyarapuは、韓国でCrackが成功した後、Wrtnが日本で開始したAIキャラクターチャットサービスです。日本のユーザーがより没入感のあるAIコンテンツを楽しめる方法を模索する中で、画像と物語が一緒に進行する、恋愛シミュレーションゲームのようなビジュアルノベル体験を作れる可能性に気づきました。
このアイデアは、ユーザー行動データに裏打ちされていました。Kyarapuにはすでに、各チャットメッセージごとにシーン画像を生成する機能があり、日本のユーザーは韓国のユーザーよりもこの機能をはるかに頻繁に利用していました。私はこれを、日本のユーザーがテキストだけの会話よりも、ストーリーとビジュアルを組み合わせた体験により大きな価値を見いだしている強いシグナルだと解釈しました。
この洞察をもとに、画像生成を完全に統合されたコンテンツ体験へと拡張することを提案しました。Visual Novel機能の初版は2025年12月にローンチされました。会話のたびに新しい画像が生成され、ユーザーはチャットしながら展開していく物語を体験できました。
チームの期待は高かったものの、初期結果は期待に届きませんでした。そこで私たちは、何が没入感を妨げているのか、そして体験をどのように改善できるのかを理解するために、ユーザーデータと定性的なフィードバックに目を向けました。
問題
ローンチ後の分析により、この機能が期待に届かなかった理由が明確になりました。
Average scene generation time
10～15秒
Average conversation length
~20 turns per user
Drop-off rate
Significantly higher than in the standard chat experience
各画像の生成には10秒以上かかりました。ユーザーは通常、約20ターンの会話を行うため、待ち時間の合計は数分に及びました。こうした繰り返しの遅延はストーリーの流れを妨げ、没入感の大きな障壁となりました。
User Research
問題をよりよく理解するために、Visual Novel 機能を使用したことのある6人のクリエイターにインタビューしました。そのうち4人は、画像生成にかかる長い時間を最大の摩擦要因として挙げました。
「待ち時間が長すぎると感じるので、たいてい帰ってしまいます。」
「待っても、画像が思いどおりにならないと、さらにイライラします。」
インタビューと行動分析を通じて、クリエイターはAIに画像を自動生成させること自体よりも、自分が思い描く世界観やシーンに合った一貫した視覚的品質を維持することをより重視していることがわかった。この傾向は特に活動量の高いクリエイターで強く、毎回異なる画像を生成するよりも、より制御されたワークフローを好んでいた。
言い換えれば、中心的な課題は単なる生成速度ではなかった。長い待ち時間と不安定な画像品質の組み合わせは、クリエイターが伝えたい物語をコントロールし続けることを難しくしていた。
Insights
研究結果に基づいて、その問題を3つの重要な課題に整理しました。
速度最適化を超えて
生成時間の短縮はモデルとインフラの改善に依存していたため、デザイン上の課題は、技術的な最適化を超えたUXソリューションを見つけることでした。
クリエイターがアップロードしたアセット
クリエイターが独自のアセットをアップロードできるようにすることで、キャラクターと背景の品質を一貫して保ちながら、より高速な画像配信が可能になりました。
明確な使用ガイダンス
主な課題は、アップロードした素材を使うべきときと、AI生成に頼るべきときをユーザーに理解してもらうことでした。
The Solution
私は、AI生成に頼る前に、クリエイターがアップロードしたアセットを優先するようにシステムを設計しました。クリエイターがあらかじめ画像アセットをアップロードできるようにすることで、生成時間を短縮しながら、一貫したキャラクターや背景のビジュアルを維持できました。
ビジュアルノベルビルダーにおけるモード選択の設計
既存のビルダーにドロップダウンを追加し、作成者がニーズに応じてアセットモードとAI生成モードを選択できるようにしました。
アセットライブラリ体験の構成
私は、クリエイターがキャラクターの表情、ポーズ、背景、シーン画像をアップロードして管理でき、自分だけの世界を自由に構築できるようにするために、アセットライブラリを設計しました。
ドラッグ＆ドロップ編集体験の実装
クリエイターがアップロードしたアセットをカテゴリごとに簡単に配置・整理できるドラッグ＆ドロップのインターフェースを設計し、大規模な画像ライブラリも直感的に管理できるようにしました。
Impact
~5sec
読み込み時間
15+%
コスト削減
より高い
ユーザー満足度
Reflection
レイテンシは単なるインフラの問題ではありませんでした。
当初はバックエンドの問題に見えましたが、UXデザインでも解決できました。ユーザーフローを再設計することで、技術的な最適化だけに頼らずに体験を大幅に改善できました。
デフォルトの体験は、説明文よりも効果的でした。
2つのモードを説明するためにさまざまな指示文を試しましたが、適切なアセットをデフォルトで表示する方が、ユーザーを導く方法としてはるかに効果的であることが分かりました。短期的な解決策と長期的な解決策では、異なるアプローチが必要です。
短期的には、既存のビルダー内にモード切り替えを追加するのが最も実用的な解決策でした。長期的には、アセットベースの作成とAI生成は、より明確に分かれた体験へと進化すべきだと考えています。
Case Study #2
チャット入力欄をデータに基づいて再設計し、ARPUを向上
Team
PM 1人、デザイナー1人、エンジニア3人
Role
Sole Product Designer
Timeline
2026年2月（ABテスト2週間）
Platform
Web, iOS, Android
Overview
チャット入力は、Kyarapuで最も頻繁に使われるインターフェースです。ユーザーは1日に何十回もこの領域を通じてキャラクターとやり取りするため、入力部分への小さな変更でも、ユーザー体験と収益の両方に直接影響を与える可能性があります。
2025年2月、私はチャット入力の全面的な再設計を主導し、3つのインターフェース案（A、B、C）を作成しました。各アプローチを評価するため、2週間のA/B/Cテストを実施しました。ユーザー行動データに基づき、日本のユーザーの嗜好に合わせたパターンを提案し、ARPUの大幅な改善を実現した後、最終デザインであるVersion Cが採用されました。
The Problem
元のチャット入力は1つのテキストフィールドで構成されていました。ただし、キャラクターチャットでは、ユーザーのメッセージは通常、2つの異なるカテゴリに分かれていました。
対話
ユーザーがキャラクターに直接言う内容。
内面の思考、行動、ナレーション
ユーザーの考え、行動、または情景描写の説明
どちらの入力タイプも同じテキスト欄で処理されていました。既存ユーザーは、会話と内心の描写を毎回手動で整形するのが面倒だと感じており、新規ユーザーは、どのような入力が求められているのか、またどのように書けばよいのかが分からないことが多くありました。
User Research
プロダクトアナリストと協力してメッセージ入力のパターンを調査したところ、およそ60%の日本人ユーザーはすでに「」の引用符を使って対話を入力していることが分かりました。
日本の小説、漫画、ビジュアルノベルでは、「」が会話文の標準的な表記です。
これは、ユーザーが自然に親しみのある物語表現の慣例に頼っていることを示しており、UIで既存の振る舞いを形式化するほうが、まったく新しい操作パターンを導入するよりも効果的であることを示唆していました。
Insights
調査結果に基づき、この問題を3つの重要な課題に整理しました。
異なる入力タイプ
インターフェースでは、話し言葉の対話と内面の思考や行動を明確に区別する必要がありました。
自然なユーザー行動
「」を使うことは、すでにユーザーの間で定着した行動パターンでした。
データ駆動型の検証
チーム内で意見が分かれていたため、最適な方法を検証するには定量的なテストが必要でした。
The Solution
3つのUIコンセプトを並行してテストしました。
コントロール
既存のデザインと変わらない、単一のテキスト入力フィールド
バリアント A
ナレーション、内面の考え（
**）
提案された返信
バリアント B
ナレーション、内なる思考 (
**)
提案された返答
会話 (
「」)
Test Setup
期間: 2週間
参加者: 新規ユーザーと既存ユーザーの無作為に割り当てられた混在
主要指標: ARPU
副次指標: ボタン使用率とメッセージ入力パターン
What I did
日本人ユーザーの60%がすでに「」の引用符を使用していることを示すデータに基づき、提案版Cを作成しました。
コンセプトを客観的に検証し、チーム内の意見の相違に対応するために、A/B/Cテストのフレームワークを設計しました。
UI変更による直接的な収益への影響を測定するため、主要指標としてARPUを使用しました。
Impact
バージョンC は最も高いARPUを達成し、最終デザインとして選択されました。
「」ボタンの使用は、元データで観測された行動パターンと非常によく一致していました。
バージョンCはユーザーの100%に展開されました。
~24%
バリアントBのARPU
より高い
ユーザー満足度
Reflection
既存の行動を製品化することで学習コストを下げられる。
新しい操作パターンを教えるよりも、ユーザーがすでに自然に行っていた行動を支援する方が、はるかに効果的だった。
チームの認識をそろえるための最も強力な手段はデータである。
直感だけでは他者を説得できない場合でも、明確なデータとよく設計された実験がチーム全体の合意形成に役立った。市場理解が製品の優位性を生む。
日本の物語表現の慣習を深く理解していなければ、「」ボタンを導入するという発想はおそらく生まれなかっただろう。文化的文脈がUXソリューションの形成において重要な役割を果たした。
Case Study #3
断片化した画像生成ワークフローを一つの画像スタジオに統合
Team
PM 1人、デザイナー1人、エンジニア3人
Role
Sole Product Designer
Timeline
Apr-May 2026
Platform
Web, iOS, Android
Overview
当初、画像生成はビルダー内のモーダルとして利用でき、主にクリエイターがコンテンツ制作の過程で使用していました。特に日本のアニメ風アートワークの生成に強い PixAI API を統合したことで、クリエイターによる利用は一貫して高い水準を維持していました。
同時に、一般ユーザーはチャット中に同じ基盤技術を使ってシーン画像を生成しており、多くのクリエイターも外部ツールで作成した画像をアップロードしていました。つまり、画像生成とアセット管理への需要はすでに複数のユースケースで検証されていたものの、それらの体験をひとつにまとめる専用の場はありませんでした。
このギャップに対処するため、私は Image Studio を設計しました。これは、画像生成、画像変換、アセット保存をひとつのワークフローに統合した独立型の体験です。これにより、クリエイターは制作アセットをより体系的に整理できるようになり、一般ユーザーも生成した画像をより簡単に閲覧、管理、再利用できるようになりました。
The Problem
画像生成は複数のユーザーフローで広く使われていましたが、全体的な体験は断片化したままでした。
クリエイター向け画像生成
クリエイターはビルダーのモーダル内で直接アートワークを作成しました
チャット内シーン生成
一般ユーザーはキャラクターとチャットしながら、シーン画像を作成しました
外部画像のアップロード
クリエイターは外部ツールで作成した画像もアップロードしました
ユーザーはさまざまな目的で画像を生成・保存していましたが、それらを一か所で管理し、再利用するための統一された体験はありませんでした。
Personas
クリエイター
制作中、クリエイターはキャラクター、背景、シーンの画像を体系的に管理する必要があり、プロジェクトごとのフォルダ整理への強い要望がありました。
「プロジェクトごとに画像をフォルダに整理したいです。」
一般ユーザー
彼らの主な目標は、自分の好みに合う画像を生成して保存することであり、複雑な整理構造よりも、シンプルなライブラリ体験を好んでいました。
「Pinterestのように、たくさんの画像を保存して閲覧したい。」
中心的な課題は、2つのユーザーグループそれぞれの異なるニーズを自然に支えられる、ひとつの製品構造を設計することでした。
Information Architecture
The Solution
Image Studio を独立した製品画面として設計し、画像生成、変換、ライブラリ管理を 1 つのワークフローに統合しました。
画像生成
スタイルの選択、画像枚数、プロンプト入力
画像から画像へ
画像から画像への変換と背景の除去
ライブラリ
画像の整理、フォルダー管理、お気に入り
What I did
ユーザーの意図を明確にするために、GenerateとEditを分けました。
2つの機能は似て見えましたが、必要な入力は異なっていました。ユーザーが現在どの作業を行っているのかを明確に理解できるよう、別々のタブとして設計しました。
Libraryを独立したコンテキストとして分けました。
GenerateとEditは作業スペースとして扱い、Libraryは保存スペースとして位置づけました。この違いに基づき、Libraryを右上からアクセスできる独立した領域として設計しました。使い慣れたモバイルのパターンを活用しました。
フォルダ内で画像を追加・削除する操作には、学習コストを抑えるためにiOSの写真アプリの操作モデルを参考にしました。
Trade-offs
モバイルアプリでのフォルダナビゲーションを簡素化。
理想的には、フォルダを選択すると専用の詳細画面に移動するべきでした。しかし、アプリのパフォーマンス制約のため、選択時にフォルダの画像一覧をすぐ表示することにしました。
Web特有の生産性向上機能を後回しに。
デスクトップ向けに最適化されたより高度な編集ワークフローも検討しましたが、課金ユーザーの大半はモバイルアプリに集中していたため、まずモバイル体験を優先しました。
Impact
ローンチ後まだ初期段階ではありますが、すでにいくつかの前向きな兆候が見られています。
増加
画像生成
より高い
一般的なユーザーエンゲージメント
Reflection
ペルソナは情報アーキテクチャを形作ります。
異なる目的を持つユーザーを明確に区別することで、より直感的で自然な製品構造を設計できました。
優れたUXは現実の制約の中で作られます。
技術的な制約とビジネス上の優先事項の適切なバランスを見つけることは、設計プロセスの重要な部分でした。なじみのあるパターンは学習コストを下げます。
ユーザーがすでに理解しているインタラクションパターンを活用するほうが、まったく新しい振る舞いを導入するよりも効果的だと分かりました。
