株式会社Cloverse様｜アパレル向けAIクリエイティブ基盤「Clovia Enterprise」を4名体制で開発支援

項目	内容
クライアント	株式会社Cloverse様
業界	アパレル / 生成AI SaaS
支援対象	アパレル企業向けAIクリエイティブ基盤「Clovia Enterprise」
支援期間	2026年2月〜現在（継続中）
体制	エンジニア4名
支援範囲	業務ヒアリング、生成モデルのR&D・比較検証、プロトタイプ作成、機能提案、設計・実装・テスト・運用
開発形態	プロダクトの実装を全面的に担当

株式会社Cloverse様は、アパレル企業のクリエイティブ制作を生成AIで変革するプラットフォーム「Clovia Enterprise」を2026年7月29日に発表しました。当社はこのプロダクトの実装を担当しています。

このプロダクトの難しさは、生成AIの精度そのものではありませんでした。

• 「きれいな画像が1枚生成できる」ことと、EC制作の業務が回ることは別問題である。 商品・モデル・背景のマスター管理、制作進行、レビューと差し戻し、大量生成の運用まで含めて初めて業務に乗る
• アパレルのEC制作という業務が、開発側にとって未知の領域だった。 何を「良い画像」とするか、どの工程が実際にボトルネックなのかは、業務を理解しないと仕様に落とせない
• 生成モデルは日進月歩で、どのモデルをどう組み合わせるかに正解が無い。 検証しながら決めるしかなく、その検証結果をプロダクト設計に反映し続ける必要がある
• 商用SaaSとして、組織・権限管理、利用量に応じた課金、非同期での大量ジョブ処理といったエンタープライズ要件を同時に満たす必要があった

FDE的な進め方 ─ 要件を受け取るのではなく、業務を理解して要件を作る

この案件で当社が担ったのは、仕様書を受け取って実装する役割ではありません。業務ヒアリング → 生成モデルのR&D・比較検証 → プロトタイプ作成 → 機能提案 → 実装という流れを、開発チーム自身が回しています。いわゆる FDE（Forward Deployed Engineer）的な関わり方です。

具体的には次のように進めました。

1. アパレルEC制作の業務理解から入る。 撮影・レタッチ・カラーバリエーション展開・レビューという工程のどこに時間がかかっているかを聞き取り、AIで置き換える対象を絞り込む
2. 生成モデルを実際に動かして検証する。 どのモデルがどの用途で使えるかを検証し、結果をそのままプロダクトの機能設計に反映する
3. プロトタイプで判断材料を作る。 議論ではなく動くものを出して、業務に乗るかどうかをクライアントと一緒に確認する
4. 仕様を提案として起こす。 実装前に1機能ごとの設計方針をドキュメント化し、合意してから着手する（後述の実装計画ドキュメント162本）

業務を理解した側が設計まで担うこの進め方については、FDE（Forward Deployed Engineer）が示す、上流から伴走できるエンジニアの価値でも考え方を整理しています。

実装した主な機能領域

出典: 株式会社Cloverse プレスリリース (2026-07-29)

プレスリリースで公開されている3つの機能群に対応する形で、以下を実装しています。

EC Production（EC制作業務）

• 商品・モデル・背景のマスター管理と、スタイリング／構図の組み合わせ管理
• 制作進行とレビュー管理（生成画像へのコメント、ステータス管理、差し戻し）
• カラーバリエーションの一括生成
• AI物撮り画像処理（背景生成・レタッチ）

Creative Studio（ブランドクリエイティブ）

• 案件（プロジェクト）単位での要件定義と、出力サイズ・解像度・向きといった納品要件の管理
• 生成セッションとレビューのワークフロー
• プロジェクトメンバー管理

Enterprise Foundation（商用SaaSの土台）

• 企業アカウント・組織・権限管理、管理者向けの二要素認証
• 利用アクションごとの単価設定と利用量ログ（従量課金の土台）
• A/Bテスト基盤

大量生成を支える非同期ジョブ基盤

画像生成は1件あたりの処理時間が長く、同期リクエストでは業務に耐えません。生成・カラーバリエーション・レタッチをそれぞれ独立した非同期ジョブとして設計し、AWS SQS でキューイングする構成にしました。ジョブごとに状態を持たせることで、失敗した生成だけを再実行でき、UI 側では進行状況を確認しながら次の作業に進めます。

データモデルは83テーブルに及びます。「画像を生成する機能」ではなく「制作業務そのものを扱うシステム」として設計した結果です。

開発の進め方

• 実装前に計画ドキュメントを書く。 1機能ごとに設計方針・影響範囲・テスト方針をまとめた実装計画を作成してから着手する運用にしており、これまでに162本の計画ドキュメントが蓄積されています
• レビュー前提の開発。 373本のプルリクエストを通して実装しており、判断の経緯がリポジトリに残る状態を維持しています
• 型安全とテストの担保。 TypeScript strict モード、Zod による入出力バリデーション、Jest・Playwright による自動テストを整備

2026年2月の開発着手から約5.5ヶ月で、アパレル企業向けAIクリエイティブ基盤としてプレスリリース公開まで到達しました（2026年7月29日発表）。

Cloverse様の発表によれば、Clovia Enterprise は PUMA社・ルック社をはじめとする30社以上のアパレルブランドとの検証を経ており、現在は先行導入企業（Founding Partner）を限定募集する段階に入っています。

開発規模は次のとおりです（2026年7月29日時点、リポジトリ実測値）。

指標	実績
開発体制	エンジニア4名
開発期間	2026年2月13日〜（継続中）
コミット数	約1,480
プルリクエスト	373本
対応イシュー	428件
実装計画ドキュメント	162本
データモデル	83テーブル

この事例からの示唆

生成AIプロダクトの難所は、モデルではなく業務側にある。 画像を1枚生成すること自体は、いまや誰でもできます。事業として成立させるために必要だったのは、マスター管理・制作進行・レビュー・権限・課金・非同期処理といった、業務を回すための地味な設計でした。83テーブルという規模は、その事実を素直に表しています。

未知の業界のプロダクトは、業務を理解した側が設計しないと形にならない。 アパレルEC制作の工程を知らないまま「AIで画像生成する機能」を作っても、現場では使われません。ヒアリング・R&D・プロトタイプ・提案までを開発チームが担ったのは、そうしないと仕様が決まらない領域だったからです。この構造は「使われないシステム」が生まれる要件定義の失敗とちょうど裏返しの関係にあります。

モデル選定に正解が無い領域では、検証を設計プロセスに組み込む。 どの生成モデルを使うかは半年で変わります。だからこそ、モデルを差し替えられる構造と、検証結果を機能設計に反映し続ける進め方の両方が必要でした。

よくある質問

Q. 生成AIを使ったプロダクトの開発は、通常のシステム開発と何が違いますか。 A. 最も違うのは、着手時点で仕様が確定できない点です。どのモデルがどの品質を出せるかは検証しないと分からないため、R&Dとプロトタイプを設計工程に組み込む必要があります。一方で、組織・権限・課金・非同期処理といった土台は通常のSaaS開発と同じ設計が求められます。

Q. 業界知識がない領域でも開発支援を依頼できますか。 A. できます。この事例ではアパレルEC制作の業務理解から入り、ヒアリングとプロトタイプを通じて要件そのものを一緒に作りました。仕様が固まっていない段階からのご相談のほうが、むしろ手戻りが少なくなります。

Q. どのくらいの体制・期間の支援ですか。 A. エンジニア4名、2026年2月から継続中です。プレスリリース公開までは約5.5ヶ月でした。規模や費用感の考え方はシステム開発とはで解説しています。

関連する支援領域

• AIシステム開発とは？開発の流れ・費用相場・失敗しない進め方 — 生成AIプロダクト開発の全体像
• AI PoCの進め方5ステップ｜「PoC止まり」を防ぎ本番導入につなげる実践手順 — 検証を本番に接続する設計
• FDE（Forward Deployed Engineer）が示す、上流から伴走できるエンジニアの価値 — 本事例の進め方の背景

生成AIを使った新規プロダクトの立ち上げや、仕様が固まりきっていない段階からの開発支援については、開発のご相談からお問い合わせください。

出典: アパレル企業向けAIクリエイティブ基盤「Clovia Enterprise」提供開始（株式会社Cloverse / PR TIMES, 2026-07-29）