8月6日、MkAnime の MRR は 1,446.30ドルになった。ざっくり言えば、月1,500ドルだ。
もちろん、人生が変わるような金額ではないし、「週末に作ったサービスが大成功した」という話でもない。それでも、自分にとっては大きな節目だった。7か月前には空だった Astro のリポジトリを、今では誰かが継続して使い、そのためにお金を払ってくれている。
この記事では売上を伸ばす方法ではなく、なぜこのプロダクトを作ったのか、そして AI アニメ制作の裏側でどんな実装に時間を使ったのかを書いてみたい。
作りたかったのは「もう一つの生成画面」ではなかった
MkAnime を始めた理由は、AI 画像生成サービスが足りないと思ったからではない。すでに一枚の画像を作るツールはたくさんあったし、短い動画も少しずつ作りやすくなっていた。
困っていたのは、その前後だ。
同じキャラクターなのにカットごとに顔が変わる。脚本、プロンプト、参考画像、生成結果が別々の場所に散らばる。一つのシーンを直しただけなのに、後ろの工程をほとんど作り直すことになる。数日たつと、どの画像をどの設定で生成したのか自分でも分からなくなる。
そこで考えたのが、「生成モデルを増やす」のではなく、「物語が途中で壊れないための作業環境を作る」という方向だった。それが MkAnime の始まりだ。
最初のコミットは、本当に空に近かった
最初のコミットは2026年1月18日。メッセージは "Initial commit from Astro" だった。
大きな設計図があったわけではない。まず作ったのは Dashboard、Project、Character、Episode、Asset、Script Editor、それから多言語ルートだった。
今振り返ると、この順番はかなり正直だ。モデルの API を呼ぶ前に、「一つの作品をどんな単位で保存するべきか」を考えていた。
-
作品には複数の Episode がある
-
Episode は順序を持つ Scene に分かれる
-
Character と Scene は何度も参照される
-
生成した画像や動画は、必ず元の Project と Shot に戻れる必要がある
派手な機能ではない。でも、この土台がなければ、生成結果はまたダウンロードフォルダに積み上がるだけだった。
AI をつなぐ前に、データの流れを作った
1月22日の時点では、まだ API ドキュメントとデータ構造を作っていた。翌日には pnpm monorepo に移行し、Fastify API、PostgreSQL、Drizzle、認証、非同期 AI タスクが入った。
技術スタックだけを並べると、きれいに計画して実装したように見える。でも実際は逆だった。
画面を作る。データ構造が足りないことに気づく。Schema を直す。API を直す。もう一度画面に戻る。この繰り返しだった。
たとえば Character 画面を作ると、メイン画像だけでなく、下書き、承認済み素材、参照画像、Character Sheet が必要になる。Storyboard を作ると、Shot の並び順、Keyframe の履歴、Dialogue、生成タスクの状態まで必要になる。
アーキテクチャは最初から完成していたのではなく、UI とデータモデルの矛盾を直すうちに形になっていった。
最初の10日で、デモからプロダクトに変わった
1月27日までに、Character Generation、Script、Scene、Storyboard、Keyframe、Video Model、Task Polling、Soft Delete が入っていた。
コミット履歴だけを見ると速い。でも、実装している本人の感覚は「一つ終わるたびに、次の前提が壊れる」だった。
キャラクターを一枚生成できても、それだけでは足りない。設定を変えて再生成したとき、今のメイン画像を上書きしてはいけない。Shot も画像一枚ではなく、移動、複製、編集ができ、Scene、Character、Keyframe、Video Task とつながっている必要がある。
ここで初めて、MkAnime は AI のデモではなく、制作途中の状態を持つソフトウェアになった。
モデルの API 呼び出しより、状態管理のほうが難しい
AI API を呼ぶコード自体は、それほど長くない。難しいのは正常系の外側だった。
外部プロバイダーはタイムアウトする。Callback は遅れて届く。ユーザーがブラウザを閉じたあとにタスクが完了することもある。一時 URL は期限切れになる。モデルによって参照画像の枚数や Aspect Ratio、エラー形式も違う。
そのため、実際に時間を使ったのは次のような部分だった。
-
内部 Task ID と Provider Task ID の対応
-
Callback と Polling が重なっても壊れない更新
-
生成物の所有関係と永続化
-
Retry と途中状態からの復元
-
Provider Error と User Credit Error の分離
-
課金処理とタスク結果の整合性
画面にはほとんど映らない。でも、一度だけ動くデモと、翌日も続きから使えるツールの差はここにある。
生成結果を「URL」ではなく、編集できるデータとして扱う
作り直しを重ねても変えなかった方針がある。生成結果を最終回答にしないことだ。
Script は編集できる。Shot は並べ替えられる。Prompt は書き直せる。Keyframe には履歴がある。Character と Scene は毎回 Prompt にコピーする文字列ではなく、再利用できるレコードとして保存する。
また、表示用に変換した画像や動画と、元の素材も分けている。軽いプレビューを表示するための URL を、モデル入力やダウンロード用の原本 URL と混ぜないためだ。
単純な画像生成ツールなら、生成した URL を返して終了できる。MkAnime では、その画像がなぜ存在するのか、どの Shot に属するのか、採用済みなのか、差し替えたとき何を残すのかまで管理しなければならない。
実装量は増える。でも、生成が「一つの答え」を返すものなら、編集は人間がその答えに反対できる仕組みだと思っている。
個人開発では、フロントエンドとバックエンドの境界も曖昧になる
一人で作っているので、Product、Design、Frontend、Backend、Infrastructure、Support を別のチームに渡すことはできない。
同じ日に DB Migration を直し、Video Callback を調べ、エラーメッセージを書き換え、日本語ルートを確認し、公開ページを調整することもある。
これは便利でもある。Storyboard の使いにくさを見つけたら、その場で Schema まで変えられる。一方で、どこまで作っても別の未完成部分が見える。
「一人で全部作った」という話を格好よく見せるつもりはない。実際には、今日いちばん壊れているものを直しながら、他の不完全さをしばらく受け入れるということだ。
失敗したことと、今も続けている理由
一番大きな見積もり違いは、AI プロダクト開発の多くが状態管理になることだった。
「モデルを一つ追加する」コストも甘く見ていた。入力形式、参照画像、料金、エラー、タスクの完了方法、UI が約束できる範囲まで変わる。Dropdown に項目を一つ足せば終わり、ではない。
機能を増やす速度が、体験を整える速度を上回った時期もあった。公開ページが実際のプロダクトより自信満々に見えたこともある。
MkAnime は動いているが、完成した答えではない。Character Consistency には限界があり、Video Provider ごとの差も大きい。長い制作フローにはまだ摩擦があるし、今の設計の一部はきっと作り直すことになる。
それでも続けているのは、最初の問いがまだ面白いからだ。
確率的で、安定せず、毎月のように変わるモデルを使いながら、一人または小さなチームが物語を保ち続けられるのか。AI の混乱をソフトウェア側で吸収しつつ、作者の判断は残せるのか。
MRR 1,500ドルは、その答えではない。ただ、少なくとも自分以外にも、この問題を解くための道具を必要としている人がいると分かった数字だった。