0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Figma Make で作ったデザインを引き継いで Claude Code で開発するには

0
Last updated at Posted at 2026-09-07

Figma Make で作ったデザインを引き継いで Claude Code で開発するには

上原正吉(EarthLink Network Co., Ltd.)。Claude Codeを開発の主体に据え、20を超えるプロダクトを1人で同時に開発・運用しています。これは、その現場の実測記です。

Figma Make で作ったデザインを引き継いで Claude Code で開発するには

2026 年の 2 月から 4 月にかけて、私は Figma Make が吐き出したコードバンドルを起点にした Web アプリを 4 つ立ち上げました。ある美容キュレーションサイト、贈り物記録アプリ、ぬいぐるみアルバム、そして AI 開発ツールの UI モック。どれも「見た目は完成している」状態でリポジトリが始まります。この記事では、その生成物を Claude Code で開発を引き継いで手を入れられる状態にするまでに何をしたのか、4 リポジトリがそれぞれどこまで進んで/止まったのかを、実際の設定ファイルとコミット履歴から振り返ります。

出発点: Figma Make の生成物はどんな形か

Figma Make の書き出しは、そのまま npm run dev で動きます。README がそれを物語っています。

# Beauty Information Curation Site

This is a code bundle for Beauty Information Curation Site.
The original project is available at https://www.figma.com/design/<id>/...

## Running the code
Run `npm i` to install the dependencies.
Run `npm run dev` to start the development server.

「原本は Figma にある」という README。これが生成物の性格を象徴しています。つまりコードは Figma デザインの投影であって、コードが正(source of truth)ではない。加えて package.json を見ると、依存が全部 exact pin されています。

{
  "dependencies": {
    "next": "15.3.4",
    "react": "19.1.0",
    "react-dom": "19.1.0",
    "lucide-react": "0.487.0",
    "motion": "12.23.24",
    "tailwind-merge": "3.2.0"
  }
}

^ の付かない固定バージョン。生成された瞬間のスナップショットとしては再現性が高いのですが、このまま放置すると誰もアップデートしないまま古びます。データ層もありません。画面はきれいでも、裏は全部モックデータで、永続化も認証も存在しない。「動くけれど、育てる土台がない」——これが 4 リポジトリ共通の出発点でした。

Figma Make の生成物の README と package.json(画面は再構成・匿名、内容は実測)。README は「原本は Figma にある / これは code bundle」と明記し、依存は next 15.3.4 のように exact pin。コードは Figma デザインの投影で、そのままでは正がコード側にありません

4 リポジトリはそれぞれどこまで進んだか

同じ Figma Make 起点でも、製品化をどこまで進めるかは中身次第でばらけました。

AI 開発ツールの UI モックは、名前のとおりモックで止めました。README も生成時のボイラープレートのまま。これは「UI 検討のための見た目」が目的で、プロダクトにする意思が最初から無かったので、無理に育てませんでした。捨てる判断も判断です。

美容キュレーションサイトが一番遠くまで行きました。ここは静的サイトとして成立するので、Next.js を静的書き出しにして Amplify へ載せました。

// next.config.ts — 静的サイトとして書き出す
const nextConfig: NextConfig = {
  output: "export",
  images: { unoptimized: true },
  trailingSlash: true,
};
# amplify.yml — out/ を成果物として配信(SSR を持たない)
frontend:
  phases:
    preBuild: { commands: [ "npm ci" ] }
    build:    { commands: [ "npm run build" ] }
  artifacts:
    baseDirectory: out
    files: [ "**/*" ]

output: "export" で SSR を持たない純静的サイトにし、images.unoptimized で Next.js の画像最適化 Lambda も外す。こうすると Amplify 側は out/ を配るだけになり、運用がとても軽くなります。3 月にはリポジトリの deploy 方式を「GitHub 連携の自動デプロイ」に切り替え、生成物から「配信されるサイト」まで到達させました。

贈り物記録アプリとぬいぐるみアルバムは、製品仕様は濃いのにデータ層で止まりました。前者の README には MVP スコープが具体的に書いてあります——ダッシュボード、人物管理、贈り物記録、カレンダー、記念日管理、法人向け 5 画面を Atomic Design で実装済み。しかし「後回し・未確定」の筆頭に、こう書かれています。

  • 実際のデータ永続化(現在はモックデータ)
  • 認証・ユーザー管理
  • 通知機能

見た目と画面遷移は完成しているのに、モックデータと本物のバックエンドの間に一番大きな隔たりがある。ぬいぐるみアルバムのほうも Vite + React 18 + Atomic Design 5 階層まで組み上がり、デザイン哲学(やさしいアースカラーの配色を具体値で規定)まで固まっていましたが、やはり永続化前で足踏みしました。

Figma Make 起点の4リポジトリが、それぞれどこまで進んだか(画面は再構成・匿名、状態は実測)。UIモックはモックのまま、美容キュレーションサイトは静的配信まで到達、贈り物記録とぬいぐるみアルバムはデータ層の手前で停止しました

生成物を「1 か所」で governance に載せる

4 リポジトリを別々に育てていくと、CI もセキュリティも品質も各リポでバラバラになります。そこで 6 月末、これらを含む一群のリポジトリをまとめて同じセルフホスト・セキュリティ CI に載せました。コミットログにその痕跡が全リポジトリに同じ形で残っています。

chore: onboard ELN self-hosted security CI (#1)          (2026-06-27)
chore(dependabot): group+monthly to cut hosted CI cost   (2026-06-27)
fix(security-pr): rename sticky comment script to .cjs
    for ESM repo compat                                  (2026-06-29)

最後の .cjs へのリネームは、セキュリティ PR に貼るコメント用スクリプトが、ESM 設定のリポジトリ("type": "module")で読み込めない問題への対処です。Figma Make の生成物は ESM 前提なので、CommonJS のスクリプトをそのまま .js で置くと require is not defined 系で落ちる。これを一群のリポジトリで一斉に踏んだので、横断で .cjs にリネームして直しました。「生成物を製品にする」とは、機能を足すことだけでなく、こうした governance の土台に載せて足並みを揃えることでもあります。

4リポジトリに同じ形で残った共通コミット(画面は再構成・匿名、コミットは実測)。同じセルフホスト・セキュリティ CI に一斉に onboard し、ESM リポジトリで CommonJS スクリプトが読めない問題を .cjs リネームで横断修正しました

なぜ生成物はそのままだと育てられないのか

理由は 3 つに整理できます。1 つ目は正の所在。README が「原本は Figma にある」と言うとおり、コードは投影物です。ここでコードに手を入れ始めた瞬間、Figma とコードは二重管理になり、どちらが正か決めないと再生成で上書き事故が起きます。だから製品化の最初の一歩は「もうコードを正とする」と腹を決めることでした。2 つ目は依存の凍結。exact pin は生成時点では正義ですが、更新の主体が居ないと腐ります。lockfile と CI を入れて初めて「更新できる」状態になります。3 つ目はデータ層の欠落。生成物は見た目とモックで閉じているので、永続化・認証・通知という「プロダクトの背骨」がまるごと未着手のまま。見た目が 9 割できていても、残り 1 割に見えるこの背骨が、実は工数の大半を占めます。

現在地と残課題

到達点はきれいに分かれました。捨てると決めたモックはモックのまま、静的で成立するサイトは配信まで到達、データ層が要るプロダクトはモックデータの手前で足踏み。そして全リポジトリが共通の CI とセキュリティゲートには載りました。「Figma Make で 1 日で見た目が立ち上がる」のは本当ですが、そこから先——正の移譲・依存の解凍・データ層——を見誤ると、「ほぼ完成」に見えて何ヶ月も進まなくなります。

転用できる教訓

  • デザイン生成物を製品にする最初の一歩は「コードを正とする」と決めること。原本が別にあるうちは、手を入れるほど二重管理の事故が増える。
  • 静的で成立するものは静的書き出し(output: "export")で配信を軽くする。SSR も画像最適化 Lambda も要らないなら持たない。
  • exact pin の生成物は lockfile と CI を入れて初めて「更新できる」状態になる。放置すると少しずつ古びる。
  • 見た目の完成度に騙されない。永続化・認証・通知という土台は、残り 1 割に見えて工数の大半。ここに大きな隔たりがあると認識してスコープを切る。

筆者について

上原正吉。EarthLink Network Co., Ltd. でAI開発をしています。2025年からClaude Codeを開発の主体に据え、今は20を超えるプロダクトを1人で同時に開発・運用しています。この連載では、その現場で実際に起きたこと(うまくいったことも、失敗も)を、数字と一緒に書いていきます。

また、AIで業務や開発を組み替えたい会社・チーム向けに、AI活用のコンサルティングも受け付けています。ご相談は www.eln.ne.jp からどうぞ。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?