再編集できるVRChat向けプロフィールカードメーカーを作るときに考えたこと

---

この記事は仕様書をもとに、Chat GPT-5.5 Thinkingに生成してもらってます。
でも、アプリ自体はVibe Codingではないので、そこはご安心を...

---

VRChat向けのプロフィールカードメーカーを作りました。

ただ、今回やりたかったのは単に「画像を作れるツール」ではなく、あとから再編集できることを前提にした設計です。

既存のツールでもプロフィール画像を作れるものはありますが、

• 再編集できない
• 再編集対応と書いてあっても復元が不安定
• 同一端末でも編集元に戻れないことがある

といった体験がありました。

そのため今回は、出力用画像ではなく、再編集可能なデータを中心に設計することを意識しました。

この記事で書くこと

この記事では、VRChat向けプロフィールカードメーカーを題材にしつつ、主に次の観点をまとめます。

• なぜ「画像生成ツール」ではなく「再編集可能なエディタ」として考えたのか
• ローカル保存に IndexedDB を選んだ理由
• PNG出力と編集データをどう分けて考えたか
• 将来的なクラウド保存を見据えて、どこまでをローカル責務にしたか

やりたかったこと

要件としてはシンプルで、最初はこうでした。

• ブラウザだけで使える
• VRChat向けのプロフィールカードを作れる
• あとから同じカードを編集し直せる
• 完成形は PNG で出力できる

ここで重要だったのは、PNG はあくまで成果物であって、編集元ではないということです。

画像を書き出せるだけだと、その瞬間に「編集の文脈」が失われます。
だから設計の中心は画像ではなく、カードの編集状態そのものに置く必要がありました。

再編集できることを最優先にした

プロフィールカードは、一度作って終わりではありません。

• 活動時間が変わる
• SNSリンクが増える
• 見た目を少し調整したくなる
• 季節やイベントに合わせて更新したくなる

つまり、必要なのは「画像生成」よりも、継続的に更新できることです。

この前提に立つと、保存対象は PNG ではなく、

• 入力されたプロフィール情報
• 使用している画像データ
• テーマやレイアウト情報
• どのカードをどう表示するかという状態

になります。

なぜ IndexedDB を使ったのか

初期段階では、ログインなしですぐ触れることを優先しました。

そのため、保存先としてはブラウザ内で完結できる IndexedDB を採用しています。

IndexedDB を選んだ理由

• ログイン不要で始められる
• ブラウザ内である程度まとまったデータを扱える
• 画像を含む編集データの保存先として localStorage より向いている
• 「まず作る、あとで再編集する」という基本体験を成立させやすい

とくに今回のように、カード情報だけでなく画像も扱う場合、localStorage はかなり窮屈です。
文字列中心で容量面も弱いため、Blob を扱いやすい IndexedDB のほうが現実的でした。

保存設計で分けたかったもの

今回の設計で重要だったのは、編集用データ と 出力用データ を混同しないことです。

考え方としては、次のように分けています。

1. カードのメタデータ

• 名前
• 活動スタイル
• 各種リンク
• テーマ
• レイアウトに必要な情報

これは「カードを再現するための情報」です。

2. 画像アセット

• アバター画像
• ギャラリー画像
• 背景など

これはカード本体に直接埋め込むのではなく、別のアセットとして管理したほうが扱いやすいです。

3. PNG出力

• 完成した見た目を画像として書き出したもの

これは配布や投稿には便利ですが、再編集の元データにしてはいけません。

この分離をしておかないと、「画像はあるけど編集状態に戻れない」という、まさに避けたかった状態になりやすいです。

ローカル保存だけでは足りない理由

IndexedDB は初期体験を作るには向いていますが、ずっとそれだけでいくのは厳しいとも感じています。

理由は単純で、

• 端末をまたげない
• ブラウザ環境に依存する
• 消えるリスクを完全には避けられない
• 公開や共有につなげにくい

からです。

なので、ローカル保存はあくまで 最初の体験を成立させるための手段 と割り切っています。

今後のクラウド保存をどう考えているか

次にやりたいのはクラウド保存です。

ただし、ここで重要なのは「ログイン機能を付けること」自体ではありません。
価値になるのは、

• 別端末でも同じカードを開ける
• 継続的に管理できる
• バックアップ性が上がる
• 将来的に公開プロフィールへつなげられる

ことです。

つまり、クラウド化は新機能というより、再編集体験をローカル環境の外まで拡張するためのものだと考えています。

作ってみて感じたこと

実際に作ってみると、プロフィールカードメーカーは「画像を出力できるか」より、「編集状態をどれだけ信用して預けられるか」のほうが大事だと感じました。

出力だけなら比較的早く実装できます。
でも、保存して、開き直して、また触れて、破綻せず更新できるようにするには、設計をかなり丁寧に考える必要があります。

このあたりは、プロフィールカードに限らず、何かしらのビジュアルエディタや作成ツール全般にも通じる話だと思います。

まとめ

VRChat向けプロフィールカードメーカーを作る中で、いちばん大事だったのは 「あとで戻ってこれること」 でした。

そのために、

• PNG は成果物として扱う
• 編集データは別に持つ
• 画像アセットとメタデータを分ける
• IndexedDB でまずローカル保存を成立させる
• 将来的にクラウド保存へ拡張できる形にしておく

という考え方で進めています。

もし、画像生成系のツールやエディタを作っていて、
「出力はできるけど、再編集や保存の設計が難しい」
と感じているなら、まずは 出力物ではなく編集状態を主役にする ところから考えると整理しやすいかもしれません。

補足

実際に作ったアプリはこちらです。
VRCardMaker