Flaz：デザイン自動化アプリケーション

プロジェクト概要

Flazは、反復的なカタログ制作作業を排除するために開発されたデザイン自動化プロダクトです。デザイナーが画像スロットとテキストフィールドを含むレイアウトテンプレートを一度定義すれば、オペレーターはスクリーンショットや収集したソース素材をアップロードするだけで、OCRパイプラインが価格、ラベル、商品属性を抽出して構造化データに変換し、編集可能なキャンバスに配置します。ReactとKonvaによるブラウザベースのレイアウトエディタ、スキャンセッションとTesseractベースの抽出を行うFastAPIバックエンド、最終カタログ出力用のPlaywright PNGレンダリング、組織別ワークスペース、そして外部クライアントやAIエージェントがレイアウト作成・キャンバス入力・アセットアップロード・抽出データマッピングをプログラムで行えるAPIおよびMCPレイヤーで構成されています。

私はフルスタック開発者として、同じカタログレイアウトを何度も手作業で再作成していた社内デザインチーム向けに**4週間（2026年5月〜6月）**でこのプロダクトを構築しました。MVPのスコープは「スクリーンショットを投入し、抽出データを編集可能なキャンバスに出力する」という単一のワークフローに絞り、CMS連携やSNSカタログ配信はロードマップに残しました。

Flaz キャンバスエディタ

使用技術スタック

flowchart LR
    subgraph Clients ["クライアント & エージェント"]
        UI["ブラウザ UI (React / Konva)"]
        Agents["AI エージェント (Cursor / Claude)"]
        API_Clients["外部 API クライアント"]
    end

    subgraph Backend ["FastAPI バックエンド"]
        API["REST API"]
        MCP["FastMCP サーバー"]
        OCR["OCR パイプライン (Tesseract)"]
        Render["Playwright レンダラー"]
    end

    subgraph Storage ["データ & インフラ"]
        DB[("PostgreSQL")]
        S3[("S3 / オブジェクトストレージ")]
    end

    UI <-->|HTTP / JSON| API
    Agents <-->|Streamable HTTP| MCP
    API_Clients <-->|発行済み API キー| API
    
    API --- MCP
    
    API <--> DB
    API <--> S3
    
    API -->|抽出| OCR
    API -->|PNG 生成| Render

フロントエンド: React, TypeScript, Vite, react-konva, TanStack Query, Tailwind CSS
バックエンド: Python, FastAPI, SQLAlchemy, Alembic
データ抽出: OpenCV, Tesseract OCR, 参照データマッチング
レンダリング: Playwright ヘッドレス Chromium, Konva レンダリングバンドル
データ & インフラ: PostgreSQL, S3, Docker Compose
外部連携: FastMCP サーバー (19 ツール), 発行済み API キー, /mcp での Streamable HTTP

プロダクトの背景

元々の課題は、カタログデザインの繰り返される手作業でした。新商品のリリースごとに同じレイアウト構造をイチから作成し、スクリーンショットや商品ページから価格や画像を文字入力・再配置していました。Flazは抽出データと完成カタログ画像との間のギャップを埋めるために存在します。OCRがソース素材を読み取り、構造化フィールドがテンプレートのスロットにマッピングされ、オペレーターは白紙のアートボードから始める代わりにキャンバス上で仕上げ作業を行います。

リスクのあった仮説は「OCRがスクリーンショットを読めるか」ではなく、「デザイナーが従来のフローに戻らず、実際にこのツール内でカタログ制作を完結させるか」でした。

そのためMVPのスコープは狭く保ちました。認証、OCR抽出を含むスキャン・トゥ・デザインパイプライン、編集可能なキャンバスをスコープに含め、CMS機能、Instagram投稿機能、チームコラボレーション機能は含めませんでした。

実装内容

flowchart LR
    A["ソース素材をアップロード"] --> B["OCR パイプライン"]
    B --> C{"参照データマッチング"}
    C --> D["構造化 JSON"]
    D --> E["レイアウトスロットへマッピング"]
    E --> F["オペレーターによる確認"]
    F --> G["最終 PNG をレンダリング"]

レイアウトエディタ: デザイナーが繰り返し使うカタログページ用に画像スロット、テキスト領域、テンプレート構造を定義するKonvaベースのキャンバス
OCRスキャンパイプライン: スクリーンショットの一括アップロード、Tesseractによる抽出、参照データマッチング、キャンバススロットに割り当てる構造化JSON変換
オペレーターワークスペース: 抽出値の確認、キャンバス上での配置調整、バリエーションのプレビュー、完成カタログPNGのレンダリング
アセットライブラリ: カテゴリ分類や一括アップロード機能を備えた組織別画像ストレージ
マルチテナント認証: JWTセッション、組織メンバーシップ、失効可能なAPIキー管理
APIキー管理: 外部クライアント向けキーを発行する設定UI。作成時に完全なトークンを一度だけ表示
MCPサーバー: /mcp にマウントされたStreamable HTTP経由で、レイアウト、キャンバス、アセット、データマッピングをAIエージェントに露出する19種類のツール

APIとMCPの統合

Flazはブラウザアプリにとどまりません。REST APIと/mcp にマウントされた Model Context Protocol (MCP) サーバーを通じて、同じレイアウト、キャンバス、データ操作を提供します。

発行済みAPIキーは Settings > API で管理します。ユーザーは外部クライアント用に失効可能なキー（接頭辞 vxg_live_）を生成します。完全なトークンは作成時の1回のみ表示され、サーバー側ではハッシュ化して保存されます。

MCPは Cursor や Claude Desktop などのAIエージェントにFlazを開放します。Settings > MCP ページで19個すべてのツールを解説し、コピペで使える mcpServers 設定を提供しています。認証には、Streamable HTTP経由で X-API-Key ヘッダーに発行済みAPIキーを使用します。

MCPツールの表面は、カタログワークスペース全体をプログラムでカバーします。

レイアウト: スロットやテキスト領域の設定を含むテンプレート定義の一覧取得、取得、作成、更新、削除
キャンバス (プロジェクト): レイアウトに紐付けられたカタログインスタンスの一覧取得、取得、作成、更新、削除
アセット: 組織ライブラリへの画像アップロード、カテゴリ・名前・属性による検索
データマッピング: レイアウトスキーマの読み取り、抽出値のスロット/テキスト領域へのマッピング、入力データの管理（作成、更新、複製、削除）

これにより、AIエージェントは人間がUIをクリックすることなく、OCRや収集データを取得し、レイアウトスキーマにマッピングし、キャンバスに入力してレンダリングを実行できます。リポジトリ内のニュースカード自動化スキルでは、すでにこのAPIパスをエンドツーエンドで利用しています。

主な技術的決定

1. 入力フォーマットを限定する

入力ソースを適当な画像ではなく構造化素材（既存カタログのスクリーンショットや収集データ）に絞ることで、OCRパイプラインの抽出精度が高まり、4週間でのMVP出荷が可能になりました。

2. テンプレート設計とカタログ入力を分離する

デザイナーはレイアウトエディタで繰り返し使う構造を定義し、オペレーターはキャンバスワークスペースで抽出データを適用します。この役割分担が実際の作業現場に合致しており、全員に複雑なデザインツールのトレーニングを行わずに運用できます。

3. サーバーサイドレンダリングを信頼できる単一の情報源にする

クライアントサイドのKonvaプレビューは編集時に高速ですが、最終PNG出力はPlaywright経由で実行し、どのブラウザやデバイスでもテンプレート通りの正確なレンダリング結果を得られるようにしました。

4. 人間だけでなくエージェントにも製品を開放する

カタログ作業は反復性が高いため、自動化はOCRにとどまるべきではありません。発行済みAPIキーと19のツールを持つMCPサーバーにより、AIエージェントや外部スクリプトがUIと同様にレイアウト管理、キャンバス入力、データマッピングを行えます。人間は確認作業に専念し、大量処理はエージェントが担当します。

5. ロードマップの規律

機能候補リストは実際にリリースしたものの3倍以上ありました。CMS連携やSNS投稿を開発対象から外したことが、2,000ドル・4週間でのMVPを実現させた要因です。

成果

Flazは私のポートフォリオの中で最も明確な実用最小限プロダクト（MVP）の例です。OCR抽出から完成カタログ画像までの単一ワークフローを完結させ、本番のレイアウトで実際に稼働しており、ロードマップ項目は意図的に未着手のまま残されています。大規模システムと同じフルスタックパターン（UI, API, 抽出パイプライン, レンダリング, 認証）を個人開発者が1ヶ月で出荷できる規模に圧縮して証明しました。