CASE STUDY 01

デザイナーのための、
AIインターフェース。

Claude Code は強力だ。
でも、それを使えるのはエンジニアだけだった。
Lumos は、その壁をなくすために作った。

ROLE — Product Designer / Developer YEAR — 2026 TYPE — Personal Project

01 — 課題の発見

AIは民主化された。
でもUIは
まだエンジニアのものだった。

2025年末、Claude Code という強力なAIツールが登場した。私はUI/UXデザイナーとして「これを使えば、デザイナーでも実装できるかもしれない」と感じた。

しかし現実は違った。ターミナル、コマンド、エラーログ——すべてがデザイナーの言語ではなかった。

Terminal vs Lumos

Claude Code の素の画面 vs Lumos

02 — ユーザー定義

私自身が、ターゲットユーザーだった。

プログラミング経験のないUI/UXデザイナー。アイデアはあるが、コードにできない。エンジニアへの依頼は時間がかかる。AIツールは存在するが、使うためにまたAIの知識が必要になる——この矛盾に気づいたとき、自分が解決すべき相手だとわかった。

PAIN POINT 01

アイデアがあっても、コードにできない

PAIN POINT 02

エンジニアへの依頼は時間と調整コストがかかる

PAIN POINT 03

AIツールを使うために、またAIの知識が必要になる

03 — 設計の意思決定

なぜそう作ったか。

DECISION 01 — キャンバス設計

タブではなく、無限キャンバス。

複数の画面を管理する方法として、タブ切り替えは一般的だ。しかしデザイナーは「空間的に考える」習慣がある。Figmaがそうであるように、画面を並べて俯瞰できる環境が、デザイン判断の質を上げる。

→ タブは文脈を殺す。キャンバスは文脈を生かす。

Canvas with multiple frames

DECISION 02 — エラー処理

エラーログを見せない。

AIの生成が失敗したとき、エラーメッセージをそのまま表示する選択肢があった。しかしターゲットユーザーはエラーログを読めない。読めないものを見せることはUXの失敗だ。

→ 見せるべきは「次にできること」だけ。

DECISION 03 — Skill システム

指示を分離する。

プロンプトが長すぎるとAIの品質が下がることがわかった。Figmaのスタイルガイドと同じ発想で、デザインルールを「Skill」として本体から分離し、必要に応じて有効化できる設計にした。

→ シンプルな指示が、良いアウトプットを生む。

04 — 成果

プロンプトを入力する。
待つ。
デザインが生まれる。

それだけでいい。

05 — 振り返りと限界

まだ解決できていないこと。

01

生成時間は2〜3分かかる。待機中のユーザー体験は改善の余地がある。

02

Figmaへのエクスポートは完全ではない。グラデーションと固定要素に課題が残る。

03

私自身がターゲットユーザーであることは強みでもあり、バイアスでもある。複数のデザイナーによる検証が次のステップだ。

06 — プロジェクト詳細

FEATURES

∙ 無限キャンバス + マルチフレーム

∙ リアルタイムプレビュー

∙ マインドマップ / アウトライン / チャート

∙ モデル自由切替(DeepSeek / Claude / Qwen)

∙ Skill システム(デザインルール分離)

∙ インタラクティブモード

∙ PNG / PDF / コードエクスポート

∙ Figma エクスポート

∙ トークン消費トラッキング

∙ 5言語対応(i18n)

BUILT WITH

∙ Electron

∙ React + TypeScript

∙ Tailwind CSS v3

∙ Vite

∙ Claude Code

∙ Claude API / DeepSeek API

∙ ECharts

∙ Mind Elixir

∙ Figma(UI設計)

TIMELINE

WEEK 01

基盤構築。Canvas、フレーム管理、Claude Code 接続。

WEEK 02

モデルルーティング、エクスポート、右側パネル。

WEEK 03

生成品質改善、Skill システム、i18n 対応。

NEXT STEP

デザインとAIの
交差点に興味があれば、
話しましょう。

CONTACT