Open Design解説：Claude CodeとCodexをAIデザインツールに変える

Mon, 18 May 2026 18:57:16 +0800

Open Designは、nexu-ioが公開しているオープンソースのAIデザインプロジェクトだ。local-firstで、Claude DesignやFigmaの代替方向を目指している。

解決しようとしている問題は明確だ。Claude Designは、大規模モデルがデザイン成果物を直接生成できることを示した。しかしその能力が、クローズドで、クラウド限定で、単一モデルに縛られた製品の中だけにあるなら、ユーザーは自己ホスト、自分のAgent接続、モデル差し替え、私有デザインシステムの蓄積、ローカルワークフローへの組み込みが難しくなる。

Open Designは新しい基盤モデルを作るのではない。あなたのPCにすでにあるcoding-agent CLIを、デザインワークスペースへ接続する。Claude Code、Codex、Cursor Agent、Gemini CLI、OpenCode、Qwen、Copilot CLI、Kimi、DeepSeek TUIなどが、デザインエンジンとして使える。

Open Designとは何か

Open Designは3つの要素の組み合わせとして理解できる。

会話、プレビュー、プロジェクト管理、エクスポートを行うWeb UI。
Agentのスケジューリング、ファイル管理、プロジェクト保存、API提供を行うローカルdaemon。
Agentの出力を、単なるAIページではなくデザイン成果物へ近づけるためのSkills、Design Systems、テンプレート。

ユーザーが要望を入力すると、Open Designは一文をそのままモデルへ投げるだけではない。まずデザインbriefを補足させ、用途と方向性を選ばせる。そのうえで、プロジェクトメタデータ、現在のデザインシステム、Skillファイル、テンプレート、チェックリストをAgentへ注入する。Agentは実際のプロジェクトフォルダでファイルを読み書きし、最後にサンドボックスiframeでプレビューできるartifactを生成する。

そのため、単発のWebページ生成器ではなく、AIデザインワークフローに近い。

普通のAI Web生成と何が違うのか

多くのAIツールはHTMLページを生成できる。しかしOpen Designの焦点は「モデルにページを書かせる」ことではない。「デザインプロセスに沿って、プレビューでき、エクスポートでき、反復できる成果物を届ける」ことだ。

いくつかの設計方針がある。

生成前に質問する。新しいdesign briefでは、まず対話式のquestion formが出て、対象者、トーン、ブランド文脈、制約、視覚方向を固める。
Skillsはファイルであり、ブラックボックスプラグインではない。各Skillは SKILL.md、assets/、references/ で構成され、読めるし、差し替えられるし、拡張できる。
Design SystemsはMarkdownであり、固定テーマJSONではない。色、タイポグラフィ、余白、コンポーネント、モーション、ブランドボイス、避けるべきパターンを DESIGN.md に書ける。
Agentは実際のプロジェクトディレクトリで作業する。テンプレートを読み、ファイルを書き、画像を生成し、.pptx、.pdf、.zip などを出力できる。
成果物はサンドボックスiframeでプレビューされ、制御されていないコードを直接実行するリスクを減らす。

この構造の狙いは、AIを、ルール、素材、チェックリストを持つデザイン協力者に近づけることだ。

対応するAgent

Open Designの特徴の一つは、Agentをランタイムとして扱い、特定のモデル企業へ固定しない点だ。

READMEには、Claude Code、Codex CLI、Devin for Terminal、Cursor Agent、Gemini CLI、OpenCode、Qwen Code、Qoder CLI、GitHub Copilot CLI、Hermes、Kimi、Pi、Kiro、Kilo、Mistral Vibe、DeepSeek TUIなどが挙げられている。これらのCLIを PATH から自動検出し、ユーザーが切り替えられる。

適切なローカルCLIがない場合は、OpenAI-compatibleなBYOK proxyも使える。baseUrl、apiKey、モデル名を入力すると、daemonがストリーミング出力を同じチャットストリームへ正規化する。

この設計には利点がある。

単一モデルにロックされない。
ユーザーがすでにインストール・設定したAgentを再利用できる。
ローカルファイルの読み書きをdaemonが管理し、権限境界がわかりやすい。
企業や上級ユーザーは、自社モデルやAPIプロバイダーを接続しやすい。

SkillsとDesign Systemsが中心資産

Open Designには多くのSkillsとDesign Systemsが同梱されている。READMEによれば、組み込みSkillsはWebプロトタイプ、SaaS landing page、dashboard、mobile app、gamified app、SNS carousel、雑誌ポスター、PPT、週報、財務レポート、HR onboarding、invoice、kanban、OKRなどをカバーする。

Design Systemsは、Agentにブランドレベルの視覚制約を与える。リポジトリ紹介では、Linear、Stripe、Vercel、Airbnb、Tesla、Notion、Apple、Anthropic、Cursor、Supabase、Figma、小紅書などのデザインシステムが挙げられている。

関係はこう考えるとよい。

Skillは「今回どんな種類の成果物を作るか」を決める。
Design Systemは「その成果物がどんなブランドスタイルになるべきか」を決める。

この2層がないと、AIは見慣れているが判断のない汎用ページを生成しやすい。SkillsとDesign Systemsがあれば、モデルは少なくとも明確なタスク境界、視覚参照、チェックルールを持つ。

何を生成できるのか

Open DesignはWebプロトタイプだけのツールではない。

READMEによると、web、desktop、mobile prototypes、slides、images、videos、HyperFramesなどを扱い、HTML、PDF、PPTX、ZIP、Markdownへのエクスポートにも対応する。メディア生成では、ポスター、アバター、インフォグラフィック、地図イラスト、短い動画、HTMLからMP4へのモーショングラフィックなども同じデザインループに含まれる。

利用場面は広い。

スタートアップチームがpitch deckを素早く作る。
プロダクトチームがlanding pageや機能プロトタイプを生成する。
運用チームがキャンペーンページ、SNS画像、週報を作る。
デザイナーがmoodboard、視覚方向、初期layoutを作る。
開発者が要求を動くフロントエンドartifactへ変える。

価値は「1ページを生成する」だけではない。複数のコンテンツ形態を同じAgentワークフローへ入れることにある。

local-firstとは何か

Open Designはlocal-firstを強調する。すべてを遠隔SaaSバックエンドへ渡すのではなく、ローカルでdaemonとプロジェクトワークスペースを動かす。

READMEで説明されているアーキテクチャはおおむね次の通り。

フロントエンドはNext.js / React / TypeScript。
ローカルdaemonはNode、Express、SQLite、SSEを使う。
プロジェクト、セッション、メッセージ、tab、テンプレートなどはローカルSQLiteと .od/projects/<id>/ に保存される。
Agentは child_process.spawn で起動し、プロジェクトartifactフォルダで読み書きする。
プレビューはサンドボックスiframeでレンダリングされる。
エクスポートはHTML、PDF、PPTX、ZIP、Markdownを含む。

この構造は、設計成果物を自分のマシンに残し、ローカルAgentを接続し、API keyを管理し、私有ワークスペースを維持したいユーザーに向いている。

ただしlocal-firstは完全オフラインを意味しない。実際の生成は利用するAgentとモデルに依存する。クラウドモデルAPIを使えば、内容はそのプロバイダーへ送られる。より正確には、Open Designはワークスペース、スケジューリング、ファイル、プレビューをローカル制御へ戻し、モデル層はユーザーに選ばせる。

Claude Design / Figmaとの関係

Open DesignはREADMEで、Claude Design / Figmaのオープンソース代替方向と説明している。ただし、伝統的なFigmaクローンではない。

Figmaは、デザイナーが手動編集、協業、デザイン稿の納品を行うプロ向けツールだ。Open Designはよりagent-nativeで、ユーザーが自然言語、フォーム、Skills、デザインシステムを通じてAgentを動かし、実行可能なartifactを出力する。

組み合わせている要素は次のようなものだ。

Claude Designのartifact-first体験。
Figma的なデザインシステム意識。
Claude Code / CodexのようなAgentのファイル読み書きと実行能力。
ローカルdaemonによるプロジェクト管理とサンドボックスプレビュー。

そのため、プロデザイナーの全工程を置き換えるとは限らないが、「アイデアからプレビュー可能なプロトタイプ」への高速ルートとしては向いている。

向いているユーザー

Open Designが向いているのは次のような人だ。

Claude Code、Codex、Cursor、Gemini CLIなどのAgentをすでに使っている開発者。
AIデザイン成果物をローカルプロジェクトディレクトリで管理したい人。
Webプロトタイプ、PPT、ポスター、運用素材を素早く作りたいスタートアップチーム。
Skills、Design Systems、プロンプトスタックをカスタマイズしたい上級ユーザー。
単一モデルや単一クラウド製品に縛られたくないチーム。

あまり向いていないのは次のような人だ。

Webページを開き、一文を入力し、すぐ画像をダウンロードしたい軽量ユーザー。
Node、pnpm、daemon、CLI、ローカル設定に触りたくない人。
成熟した共同編集、デザインレビュー、ベクター編集を必要とする本格的なFigmaワークフロー。

言い換えると、Open Designは万人向けの軽量デザインSaaSというより、Agentユーザーと技術寄りのデザインチーム向けのツールだ。

注意点

Open DesignのREADMEには 0.8.0-preview とあり、プロジェクトがまだ高速に進化していることが示されている。活発さは魅力だが、API、データディレクトリ、デスクトップ版移行、Skills構造、エクスポートフローは変わる可能性がある。

使う前に注意したい点は次の通り。

安定した企業向けデザインプラットフォームとして扱わない。
重要な資料を入れる前に、テストプロジェクトでワークフローを試す。
.od/ データを移行する場合は先にバックアップし、daemonとデスクトップアプリを停止する。
BYOK利用時はAPI key、プロキシURL、ローカル私有ネットワークアクセスのリスクに注意する。
生成されたデザインは、人間がレビューする。特にブランド、著作権、コピー、視覚一貫性は確認が必要だ。

オープンソースの利点は、検査でき、変更でき、貢献できることだ。その代わり、ある程度のエンジニアリング摩擦を受け入れる必要がある。

まとめ

Open Designの見どころは、単に「オープンソース版Claude Design」であることではない。本当に面白いのは、Agent CLI、Skills、Design Systems、ローカルdaemon、サンドボックスプレビューを一つのデザインワークフローにまとめている点だ。

設計生成を単発promptから、より構造化された流れへ押し上げている。質問し、方向を選び、デザインシステムを読み込み、Skillを読み、実ファイルへ書き、artifactをプレビューし、結果をエクスポートする。

すでにClaude Code、Codex、Cursorでコード作業をしているなら、Open Designは注目に値する。AIが一枚の画像を描くだけでなく、ローカルプロジェクト空間で、デザインシステムとタスクスキルに沿って、継続的に反復できるデザイン成果物を生成するという新しい製品形態を示している。

参考資料

nexu-io/open-design GitHubリポジトリ

Open Design on KnightLiブログ