Claude Designで業務システムのUIをリニューアルした記録｜design 1時間・実装2時間・修正に2日【2026年6月】

先日、Claude Designの大型アップデートを「使ってみた」として紹介しました。あれから、今度は実際に運用している“ちゃんとした業務用Webシステム”のUIを、本気でリニューアルしてみています。

結論を先に言うと——デザイン案づくりは約1時間、実装は約2時間。そして“そこから”が長い。修正に2日（まだ進行中）。 「AIに任せたら一瞬で終わる」という話ではなく、実用品質に持っていく工程こそが本番でした。

この記事は、きれいにまとまった成功談ではなく、いま現在進行形でやっている作業の、正直な記録です。これから同じことをやる人が「どこに時間がかかるのか」を先に知れるように、内訳ベースで書きます。

結論：時間の内訳は「design 1h ／実装 2h ／修正 2日（進行中）」
デザイン案づくり（約1時間）：モックを見比べて選ぶ
実装（約2時間）：5フェーズに分けて進む。ただし途中の正誤が見えない
本当に長いのは「修正」だった（約2日・進行中）
1. 2日やるうちに「修正サイクル」が固まってきた
つまずき集（これからやる人へ）
2日やってみた所感：向き・不向き
1. いまの状況（進行中）
まとめ

結論：時間の内訳は「design 1h ／実装 2h ／修正 2日（進行中）」

ざっくりの内訳はこうです。

工程	かかった時間	ひとことで言うと
① デザイン案づくり	約1時間	Claudeに3案出してもらい、選ぶだけ。速い。
② 実装（コードへの反映）	約2時間	選んだ案を実装。ここも思ったより速い。
③ 修正・調整	約2日（まだ続行中）	実用品質に詰める工程。ここが本番。

つまり、「作る」より「直す・整える」の方が圧倒的に長い。これは手作業のUI改修でも同じですが、AIに任せてもこの比率は変わらなかった、というのが今回いちばんの発見です。以下、工程ごとに詳しく書きます。

デザイン案づくり（約1時間）：モックを見比べて選ぶ

最初の工程は速かったです。

まず「こういうテイストにしたい」という初期の要望を伝える。
その要望に沿った3パターンのモックを作ってもらう。いきなり本実装ではなく、まず“たたき台”を見せてくれる流れです。
モックはHTMLで出力されるので、静止画ではなくブラウザで実際の表示を確認しながら選べるのが良い点。「言葉のイメージ」と「実物の見え方」のズレが、選ぶ前に潰せます。
要望に合った3バリエーションから、見比べて選ぶだけ。

専門知識がなくても「これがいい」と選べるのは、前回の記事18でも感じた通り。入口のハードルは本当に低いです。

実装（約2時間）：5フェーズに分けて進む。ただし途中の正誤が見えない

選んだデザインを、実際のコードに反映する工程。ここで作業は5つのフェーズに分割されて進みました。大きな改修を一気にやらず、段階に区切ってくれるのは安心感があります。

ただ、ここで最初の落とし穴がありました。

各フェーズは、あくまで「最終案の完成形」をゴールに置いた部分作業です。そのため、途中段階の見た目を見ても、それが“正しい途中経過”なのか“間違い”なのか判断しづらい。最終形を頭に入れていないと、中間状態の正誤が分かりません。
特にスタイルシート（CSS）。新しいスタイルを書いて上書きしても、既存のスタイルのほうが優先されて適用されないことがあります（CSSの詳細度・読み込み順の問題）。結果、コードは追加されているのに、見た目は一向に変わらない——という状態が起きました。

ここまで（design＋実装）で約3時間。この時点では「思ったより早く終わりそう」と感じていました。問題はこのあとで表面化します。

本当に長いのは「修正」だった（約2日・進行中）

ここが本題です。5フェーズの実装がすべて終わって、全体を通して確認した段階で、ようやく気づきました——「あれ、思ったほどデザインが変わっていない」。

前述のCSSの上書きが反映されていない問題が、最後まで進めて初めて表面化したわけです。各フェーズの途中では「正しく進んでいるのか」が判断しづらく、全部終わって全体を見て初めて「反映されていない」と分かる。ここから、“ダメ出し作業”が始まりました。

「ここが変わっていない」「この部分は古いスタイルのまま」と、反映されていない箇所を一つずつ指摘して直してもらう往復。
既存スタイルとの優先順位の衝突なので、一発では直らず、往復が増える。直してもらう→確認→まだ残ってる→また指摘、の繰り返し。
この「指摘と確認の往復」こそが、2日かかっている工程の正体です。実装そのものより、“ちゃんと反映させる・整える”ほうが圧倒的に長い。

2日やるうちに「修正サイクル」が固まってきた

ただ、ずっと混乱していたわけではありません。往復を繰り返すうちに、お互い（自分とAI）が慣れてきて、修正の回し方が定着しました。いまは次の流れで回っています。

人間がダメ出し：「ここが反映されていない」「この挙動を直して」と具体的に指摘。
AIが修正：指摘を受けてコードを直す。
AIがPlaywrightで確認：直したあと、AI自身が実際の画面をPlaywrightで開いて、反映されたかをセルフチェック。
人間が最終確認：その上で、人が目で見て確認。問題があれば 1 に戻る。

ポイントは、③のAIによる自己確認が挟まること。直しっぱなしで人に渡すのではなく、AIが一度「本当に変わったか」を見てから人の確認に回るので、「直したはずなのに変わってない」という空振りの往復が減りました。最初の混乱期を越えてこの型ができてからは、修正がかなり流れ作業に近づいたのが実感です。

つまずき集（これからやる人へ）

同じことをやる人が先回りできるよう、引っかかったポイントを整理します。

CSSの上書きが効かないことがある：新しいスタイルを足しても、既存スタイルの優先度が勝って反映されない。コード上は変わっているのに見た目が変わらず、原因に気づきにくい。既存CSSが厚いシステムほど起きやすい。
途中段階では正誤が判断しづらい：実装が複数フェーズに分かれ、各段階は最終形ありきの部分作業。最終イメージを自分が持っていないと、中間の良し悪しが見えない。
問題が最後にまとめて出る：フェーズを全部終えて全体確認して、初めて「反映されていない」と分かる。こまめに表示確認しないと、手戻りが大きくなる。
動きのあるページは、モックだけでは足りない：モックは基本“静止状態”なので、ホバー時の色・操作中の状態変化・足りないボタンなどは出てきません。動的なページほどその都度モックを直して対応する必要がありました。見た目の一枚絵だけでなく、触ったときの挙動まで含めて詰めるのがポイント。
だから“ダメ出し”の往復が要る：AIに任せても、反映漏れを人が見つけて指摘する工程は省けない。

2日やってみた所感：向き・不向き

現時点（まだ修正中）での率直な評価です。

向いている：たたき台づくりと“見た目の底上げ”。要望から3案のモックをHTMLで出してくれて、選んで実装に入るまでが速い。デザイン資産のない既存システムに、トーンの整った新デザインを当てる入口としては優秀。
過信は禁物：既存スタイルが厚いシステムの“確実な反映”。CSSの優先度衝突で「入れたのに変わらない」が起きやすく、反映漏れを人が見つけて指摘する往復は省けない。ゼロからの新規より、成熟した既存改修のほうが手こずる印象。
コツ：フェーズごとに、こまめに実際の表示を確認する。全部終えてからまとめて確認すると、反映漏れが積み上がって手戻りが大きくなる。途中で「反映されている/されていない」を潰すほど、最後のダメ出しが短くなる。

一言でいうと——Claude Designは“最初の数時間”でデザインと実装のたたき台を一気に作ってくれる。一方、既存システムに確実に反映させて整える工程は、これまで通り人の根気と確認が要る。その前提で使えば、既存システム刷新の心強い相棒になります。

いまの状況（進行中）

正直に現状も書いておきます。

範囲は割り切った：全ページを一度に作り替えるのではなく、マスタ系（設定・台帳系）のページは今回いったん断念。主要な画面から優先して手をつけ、欲張らず範囲を絞りました。一気に全部やろうとしないのが、現実的な進め方だと感じています。
ログイン画面が完成：ログイン画面もモック作成からやり直していましたが、無事に仕上がりました。「ふぅ、一区切り」と気を抜いた、まさにその瞬間——。

そして、ここで小さな“事件”がありました。ログイン画面ができてホッとしていたら、Claude Codeのほうから「まだ手をつけていない画面がありますね」と、未着手ページのリストを出して次の作業を提案してきたのです。こちらが見ないふりをしていた残タスクを、的確に突いてくる。休ませてくれない…と思いつつ、言っていることは正論。「人間が止まっても、AIは次の一手を促してくる」のだと実感した瞬間でした。断念したはずのマスタ系も、こうして少しずつ片付いていくのかもしれません。

この作業はまだ進行中です。完成したら、最終的な完成度と所感をこの記事に追記します。