建築向けのAIレンダリングツール「Visualizee」は、UIを使い慣れたチャット形式に変えたことで成長が加速し、Stripe連携で検証された月間継続収益（MRR＝毎月くり返し発生する売上）が8,184ドルに到達しました。開発したのは本業のかたわら個人で手を動かすエンジニアです。この記事では、コードを書く力ではなく「2つの意思決定」がどう収益を動かしたのかを整理し、個人開発で収益化を目指す人が自分の事例に置きかえられる形でお伝えします。
建築AIツール「Visualizee」が到達した数字
まず結論から整理します。個人開発のツールが「検証済みの売上」を公開している点が、この事例の信頼性を支えています。
MRR 8,184ドル・サブスク288件という実数
公開されている数字は次のとおりです。いずれも2026年10月8日時点のもので、Stripe（決済サービス）との連携により外部サービスで検証された値とされています。
- MRR 8,184ドル（毎月くり返し発生する売上）
- アクティブなサブスクリプション契約 288件
個人開発で発信される収益には、本人の自己申告だけで裏づけのないものも少なくありません。この事例は決済データと連携した検証済みの数字である点で、数ある「稼げました報告」とは性質が異なります。
開発者はポーランド在住の兼業エンジニア
Visualizeeを開発したのは、ポーランド在住で20年以上の経験を持つエンジニア、Piotr Obidowski氏です。本業を持ちながら兼業で開発を続けてきました。
最初のバージョンを2023年にリリースしてから、現在の形にたどり着くまでには段階がありました。短期間で一気に当てたわけではないという点は、兼業で開発を続ける人にとって現実的な参考になります。
伸びを決めた1つ目の意思決定：UIをチャット形式に変えた
このツールの転換点は、技術的な高度化ではなくUI（操作画面）の設計変更でした。ここが最大の学びどころです。
ノードエディタからチャット形式へ
初期のVisualizeeは「ノードエディタ」と呼ばれる形式でした。これは機能のまとまりを箱（ノード）としてつなぎ合わせて操作する画面で、慣れた人には柔軟ですが、初めて触れる人にはハードルが高い形式です。
これを、AIアシスタント「Vizzy」と対話しながら操作するチャット形式に変更しました。非技術者でも使えるようになったことで、成長が加速したと説明されています。チャット型への転換にはおよそ6か月を要しました。
「使える人の数」を増やす発想
ここで押さえておきたいのは、機能そのものは大きく変わっていないという点です。変わったのは「どんな人が迷わず使えるか」という間口です。
建築の現場では、レンダリング（設計データを写実的な画像に変換する処理）を必要とする人すべてが、ツールの操作に明るいわけではありません。操作の学習コストを下げることは、そのまま顧客候補を広げることにつながります。
- 高機能だが一部の人しか使えないツール
- 機能は同じでも誰でも迷わず使えるツール
同じ中身でも、後者のほうが契約につながりやすい。この視点は、建築に限らずBtoB（企業向け）ツールを作る個人開発者に共通して効く考え方です。
伸びを決めた2つ目の意思決定：都度課金からサブスクへ
もう1つの転換は、お金の受け取り方の設計、つまり課金モデルの変更でした。
月額15〜80ドルの3段階＋Agencyプラン
当初は使うたびに支払う「都度課金」でした。これを、毎月定額で使えるサブスクリプションに切りかえています。価格は月額15〜80ドルの3段階に、法人・代理店向けのAgencyプランを加えた構成です。
都度課金は「使った分だけ」の分かりやすさがある一方、売上が毎月ゼロから積み上がり、読みにくいという弱点があります。サブスクに変えると、継続契約が積み上がり、MRRとして可視化できるようになります。先ほどの288件という契約数は、この積み上げの結果です。
課金モデルは「売上の安定性」を左右する
個人開発では、開発そのものに集中したいあまり、課金設計を後回しにしがちです。しかしこの事例が示すのは、課金モデルの選択が売上の規模と安定性に直結するという事実です。
日本の個人開発者が応用できる3つの視点
この事例を「海外のすごい話」で終わらせないために、自分の開発に引き寄せられる形で整理します。
手を動かす前に検証したい3点
着手前や見直しの段階で、次の3点を自分のツールに当てはめて考えてみてください。
- 間口：いまのツールは、技術に明るくない人でも迷わず使えるか
- 課金：売上が毎月ゼロから積み上がる構造になっていないか
- 検証：収益や利用状況を、あとで数字で示せる形で記録しているか
「作る力」より「届ける設計」
Visualizeeの事例で動いたのは、新しい技術ではなく「誰に、どう使ってもらい、どう課金するか」という設計でした。これはコードを書く力とは別の、届ける力の領域です。
リスキリング（学び直し）で開発スキルを身につけた人ほど、機能の作り込みに目が向きがちです。しかし収益化の段階では、作る力と届ける設計は別のスキルだと切り分けて考えると、次の一手が見えやすくなります。
まとめ：収益を動かしたのは技術ではなく2つの設計判断
建築向けAIツール「Visualizee」が検証済みMRR8,184ドルに至った背景を整理しました。伸びを決めたのは、技術の高度化ではなく次の2つの意思決定でした。
- ノードエディタからチャット形式へ変え、非技術者でも使えるようにしたこと
- 都度課金からサブスクに変え、売上を積み上がる構造にしたこと
個人開発でツールの収益化を考えているなら、新しい機能を足す前に、「いまのツールは誰が使えるのか」「課金は積み上がる形か」を一度見直してみてください。手元のツールに当てはめて考えるところから、次の改善の糸口が見つかるはずです。
よくある質問
MRRとは何ですか？
MRRはMonthly Recurring Revenueの略で、毎月くり返し発生する売上を指します。サブスクリプション型のサービスで、継続契約がどれだけ積み上がっているかを示す指標として使われます。都度課金と違い、翌月以降も見込める売上として可視化できる点が特徴です。
この収益の数字は信頼できますか？
Visualizeeの数字は、決済サービスStripeと連携した外部サービスを通じて検証された値とされており、本人の自己申告のみの事例よりは裏づけがあります。ただし特定時点のスナップショットであり、今後も同じ水準が続くとは限りません。参考にする際は時点と前提を確認することをおすすめします。
プログラミング初心者でも同じように収益化できますか？
この事例の開発者は20年以上の経験を持つエンジニアであり、同じ成果を初心者がすぐ再現できるとは限りません。一方で、記事で取り上げた「間口を広げる」「課金を積み上がる形にする」という考え方自体は、技術レベルを問わず検討できる視点です。まずは小さく試し、数字で検証しながら進めるのが現実的です。
都度課金とサブスクはどちらが良いですか？
一概にどちらが良いとは言えません。都度課金は使った分だけ支払う分かりやすさがあり、サブスクは売上が積み上がり安定しやすい反面、継続して使う理由がなければ解約されます。この事例ではサブスクへの切りかえが成長要因の一つとされていますが、提供するツールの使われ方に合わせて選ぶことが大切です。
参考文献
関連記事
コメント