なぜ1人法人のCEOが、ファッションAIの独自モデルを作ることにしたのか

22体のAIと、1つの確信。


私はKOZUKI。株式会社TomorrowProofの代表で、社員はゼロ、AIエージェントが22体いる。

開発、マーケティング、経理、法務、セキュリティ、SNS運用——全てAIが担っている。人間は私1人。2025年8月に法人を設立して以来、この体制で複数のプロダクトを同時に開発・運営してきた。

その中で、私が最も時間と情熱を注いできたプロダクトがある。

Lumina Studio——ファッションEC事業者のための、AI画像生成ツール。

今日、このブログを書いているのは、Luminaが新しいフェーズに入ったからだ。汎用AIモデルを捨て、独自のファッション特化AIモデルをファインチューニングするという決断をした。

これは技術の話だけではない。なぜ私がこの市場を選び、何度も壁にぶつかり、それでもこのプロダクトを世に出そうとしているのか。その全てを書く。


ファッションECの「ささげ」という巨大な痛み

「ささげ」という言葉をご存知だろうか。

撮影・採寸・原稿——ファッションECで商品を販売するために必要な3つの工程の頭文字だ。モデルをブッキングし、スタジオを押さえ、カメラマンを雇い、ライティングを組み、何十着もの服を撮影する。1商品あたりの制作費は数千円から数万円。大手ブランドなら月に数百SKU。年間の制作費は数千万円に達する。

中小のEC事業者にとって、これは致命的なコストだ。

売れるかわからない商品に、撮影費を先行投資しなければならない。モデル1人のギャランティ、スタジオ代、カメラマンのフィー。全部固定費。売上がゼロでも発生する。

AIがこの問題を解決できるはずだ——そう思った。

商品の平置き写真をアップロードすれば、AIがモデル着用画像を自動生成する。撮影コストは90%削減。納品時間は数日から数分に。24時間稼働。追加コストなし。

従来のささげ工程 vs Lumina AI

理論上は完璧だった。


最初の壁——汎用AIの限界

Luminaの開発は、Googleの最新モデル「Gemini 3 Pro」をベースに始まった。

世界最高レベルの汎用AIだ。テキスト理解、画像認識、マルチモーダル処理——あらゆるベンチマークでトップクラスのスコアを叩き出す。このモデルにプロンプトを工夫すれば、ファッション撮影レベルの画像が出せるはずだと考えた。

甘かった。

最初の生成画像を見た瞬間、わかった。白飛び。のっぺりした光。生地の質感が完全に消えている。シルクがコットンに見える。デニムがプラスチックに見える。影がない。奥行きがない。

プロンプトを100回以上書き直した。「ライティングの影比率を1:2.5にしろ」「生地のテクスチャを保持しろ」「自然なドレープを再現しろ」——言葉を尽くした。400語のプロンプト、800語のプロンプト、1,200語のプロンプト。

わずかに改善した。でも、「制作会社レベル」には程遠い。

ここで気づいた。根本的な問題は、プロンプトの書き方じゃない。

Geminiは言語モデルだ。画像生成モデルではない。

テキストの理解は天才的でも、ピクセルレベルの制御はそもそも設計思想にない。ファッション写真に必要な「この角度のこの光で、この素材がどう反射するか」という物理シミュレーションは、言語モデルの守備範囲の外にある。

料理を注文するのに、最高の翻訳家を雇ったようなものだ。言葉は完璧に伝わるが、料理は作れない。


二番目の壁——ライセンスの罠

次に試したのが、バーチャル試着(VTON)の専門モデルだった。

学術論文で高い評価を受けた、ファッション画像に特化した拡散モデルがあった。デモ画像の品質は素晴らしかった。これをLuminaに統合すれば、一気に品質が上がる。

統合を始めた。コードを書いた。テストした。結果は良好だった。

そして、ライセンスを読んだ。

CC BY-NC-SA 4.0。

NC——Non-Commercial。商用利用禁止。

つまり、このモデルを使って収益を得た瞬間、ライセンス違反になる。Luminaは有料SaaSだ。使えない。

即座にコードベースから全削除した。

これは笑い話ではない。世の中のAIスタートアップの中には、このライセンス問題に気づかずに——あるいは気づいていながら——NC付きのモデルを商用サービスに組み込んでいるところがある。いつか訴訟リスクが爆発する時限爆弾だ。

同じ罠に落ちかけた別のモデルもあった。テクスチャ保持の性能は最高クラスだが、やはりCC BY-NC-SA 4.0。商用不可。

この業界は地雷原だ。性能が良いモデルほど、NC付きの学術ライセンスで公開されている。商用OKで、かつ品質が高いモデルは、驚くほど少ない。


三番目の壁——セキュリティの穴

技術的な問題はモデル選定だけではなかった。

ある日、Luminaのフロントエンドコードを精査していて、血の気が引いた。

APIキーがブラウザのJavaScriptバンドルにハードコードされていた。

外部AIサービスのAPIキーが複数、ブラウザの開発者ツールを開けば誰でも見える状態。つまり、ユーザーが私のAPIキーを使って無制限にAPIを叩ける。請求は全て当社に来る。

原因は、開発初期にスピードを優先してクライアントサイドから直接APIを呼ぶ設計にしたことだ。

全面的なアーキテクチャ再設計を決断した。

全ての外部API呼び出しをVercel Serverless Functionsに移行。クライアントからは自社のAPIエンドポイントだけを叩く。キーはサーバーサイドに閉じ込める。Vercel Proプランに切り替え、セキュリティヘッダー、レート制限、CSP、監査ログを追加。

1人法人だからセキュリティを軽視していい理由にはならない。むしろ1人だからこそ、穴が1つでもあれば致命傷になる。


なぜ「独自モデル」なのか

ここまでの経緯を整理する。

  1. 汎用AI → ファッション画像の品質に天井がある
  2. 既存の専門モデル → 商用ライセンスの問題
  3. 商用OKの専門モデル → 使えるが、他社も同じモデルを使える。差別化にならない

ここで私は考えた。

海外にはすでに複数の競合サービスが存在する。数十人のチームを擁し、独自の学習モデルを持ち、月額数千円〜数万円で世界中のEC事業者にサービスを提供している。品質は制作会社レベル。

なぜ彼らの品質が高いのか。答えは単純だ。自分たちでモデルを訓練しているからだ。

汎用モデルに「ファッション写真を生成しろ」と命令するのと、ファッション写真だけを見て育ったモデルに「いつも通りやれ」と言うのでは、結果が根本的に違う。

そして気づいた。

オープンソースの商用利用可能な画像生成モデルの中に、品質・エコシステムともにトップクラスのものがあった。

このモデルをベースに、ファッションECの画像データでファインチューニングを行う。モデルの基礎能力の上に、「ファッション写真の撮り方」を追加学習させる。

正直に言えば、独自モデルの開発は1人法人にとって小さな投資ではない。設立から7ヶ月。資金に余裕があるわけではない。

それでもやる。会社の全てをかける。

この判断に迷いはなかった。中途半端に汎用AIのプロンプトを調整し続けて、競合の背中を永遠に追いかけるくらいなら、腹を括って独自モデルに振り切る方がいい。勝負するなら、今だ。

しかも、私にはファッションディレクターとしての経験がある。どのライティングが正解か、どの構図が商品を最も魅力的に見せるか、どの素材感が「嘘」に見えるか——その判断基準を持っている。

AIモデルの学習データを、ファッションのプロの目でキュレーションする。「この撮影は完璧なライティングだから学習に入れる」「このカットは影が硬すぎるから除外」——その判断ができる人間が、学習データを選別する。

技術×審美眼。これが参入障壁になる。

コードは誰でも書ける。モデルの学習方法はオープンソースで公開されている。でも、「何を学ばせるか」の判断には、ファッション業界の経験が必要だ。


技術構成——何を、どう作るのか

今日のCouncil会議で、全エージェントの調査結果を統合し、技術構成を確定した。

ベースモデル

商用利用可能なオープンソースの画像生成モデルの中から、品質とエコシステムの成熟度で最適なものを選定した。

ファインチューニング手法

モデル全体を再学習するのではなく、特定のタスク(ファッション写真生成)に最適化された軽量な追加レイヤーを学習する手法を採用。反復が容易なので、「生成→確認→調整→再学習」のサイクルを何十回でも回せる。妥協せず、納得するまで回し続ける。

学習データ

ここがLuminaの独自性の核になる。私自身のファッションディレクターとしての経験と、業界関係者の知見を掛け合わせて、学習データをキュレーションする。何を学ばせ、何を学ばせないか——その選別基準そのものが、他社には真似できない参入障壁だ。詳細は非公開とする。

推論基盤

クラウドGPUのサーバーレス実行環境を採用。使った分だけ課金される従量制で、固定費を最小化する。

パイプライン

商品画像アップロード
  → 汎用AI(商品分析・テキスト生成)
  → 独自ファインチューニングモデル(画像生成)
  → 汎用AI(品質チェック)
  → ユーザーに納品

汎用AIは「目」と「口」として残す。画像を見て何の商品かを分析し、商品説明文を生成し、生成画像の品質をチェックする。「手」——実際に画像を描く部分——は独自モデルが担う。

適材適所。言語モデルには言語を。画像モデルには画像を。

AI Pipeline Architecture

Lumina Studio——現在のプロダクトUI

これが今のLumina Studioだ。まだ開発中だが、すでに動いている。

Lumina Studio — 生成画面とモデル選択画面

左が生成画面。ガーメント画像をアップロードし、スタジオプリセット・ブランドトーン・AIモデルを選択して、1クリックでプロフェッショナルショットを生成する。

右がモデル選択画面。AIモデルロスターから選ぶか、カスタムAIでポーズ・体型・年齢・髪色まで自在に設定できる。EC用のニュートラルポーズから、エディトリアル用のウォーキングポーズまで。

これが、撮影スタジオの代わりになる。


日本のEC事業者に届けたいもの

ここまで技術の話をしてきた。でも、Luminaを作っている本当の理由は技術じゃない。

私は日本のファッションEC市場を見てきた。

BASEで副業のアパレルブランドを始めた若い起業家。Shopifyで海外展開を目指す中小メーカー。楽天で生き残りをかけて戦うセレクトショップ。

全員が同じ問題を抱えている。撮影にかける資金と時間がない。

大手は制作会社に月数百万円を払える。ZOZOTOWNは自社スタジオを持っている。でも、月商100万円のショップが1商品あたり数千円の撮影費を払い続けるのは、体力的に限界がある。

結果、何が起きるか。**平置き写真だけで出品する。**モデル着用画像がないから、服のシルエットが伝わらない。素材感が伝わらない。購入率が下がる。返品が増える。利益が消える。

AIがこの構造を壊せる。

平置き写真を1枚アップロードすれば、AIが制作会社レベルのモデル着用画像を30秒で生成する。コストは1枚100円以下。24時間365日稼働。モデルのスケジュール調整も、スタジオの予約も、天候の心配もない。

これが「ささげAI」だ。

海外ではすでに複数のサービスがこの領域で急成長している。しかし、日本市場に特化したものはまだない。日本語で使える、日本のECモール(楽天・Yahoo・Amazon)の規格に自動対応する、日本のファッション市場を理解したAI。

それがLumina Studioだ。


失敗の記録

正直に書く。ここまでの道のりは失敗の連続だった。

全部記録してある。22体のAIエージェントが、毎日の意思決定と失敗をJournalに残している。

この透明性が、TomorrowProofという会社の価値だと思っている。1人法人でも、意思決定の過程をオープンにすることで、信頼を積み上げていく。


これからの話

今日、2026年3月12日。独自モデルのファインチューニングを正式に開始する。

Development Timeline

3月後半

4月

5月

6月以降

目標は明確だ。「AIで作ったと気づかないレベル」の画像品質。

それが達成できた時、日本のファッションEC市場は変わる。中小のショップが、大手と同じクオリティの商品画像を、100分の1のコストで作れるようになる。


最後に

1人法人のCEOが、22体のAIエージェントを率いて、独自のファッションAIモデルを作る。

普通に聞けば無謀だと思うだろう。数十人規模のチームを持つ海外の競合サービスが複数ひしめく市場に、1人で挑むのか。

しかし、私は確信している。

AIの時代に、チームの大きさは優位性にならない。速度と判断の質が全てだ。

ファインチューニングは数時間で完了する。フィードバックを受けて修正し、翌日には新しいバージョンを試せる。22体のAIエージェントが24時間並行で動く。1人の人間が判断し、22体のAIが実行する。

この構造は、10人のチームより速い。

そして、私にはファッションの目がある。何が「本物」に見えて、何が「AI臭い」か。その判断基準は、プロンプトには書けない。コードにも落とせない。人間の審美眼でしか担保できない。

技術 × 審美眼 × 速度。

これが、1人法人が大手チームに勝つための方程式だ。

Lumina Studioは、日本のファッションEC事業者のために作る。

まだ完璧じゃない。まだ道半ばだ。でも、ここまでの全記録をオープンにしながら、作り続ける。


KOZUKI TAKAHIRO 株式会社TomorrowProof 代表取締役 2026年3月12日


この記事の執筆にあたり、TomorrowProofの22体のAIエージェント(Research, Legal, CFO, EC Director, Dev, Security, Branding)が調査・分析・法的検証を担当しました。最終的な文章と判断は、すべて人間であるKOZUKIが行っています。