こんにちは。グッドパッチのUI/UXデザイナーのナスカです。
最近、仕事で「Claude Code」の話を聞かない日がありません。エンジニアはもちろん、デザイナーやPdMも使い始めていて、「AIが実装してくれる」「コードを書かなくても動くものが作れる」という話があちこちから聞こえてきます。
そんな波の中で、私もプロジェクトでClaude Codeを使い始めました。最初は「デザイナーが使うものなのか？」と半信半疑でしたが、気付いたらワークフローがまるごと変わっていました。
この記事は、Claude Codeがどう仕事を変えたのか、やってみたこと、変わったこと、変わらなかったことを正直に書きます。以下のようなことに興味がある方は、ぜひ読んでみてください！
- AI時代にデザイナーのキャリアをどう築いていけばいいか、考えている方
- 現場でAIがどう使われているか、具体的なイメージが欲しい方
- デザイナーの役割がこれからどう変わっていくか、気になっている方
目次
「デザインは固まっているのに、手が足りない」をきっかけに開発にチャレンジ
私は今、APO・デザイナー・フロントエンドエンジニア・バックエンドエンジニア・QAが並走する大規模なスクラムが進む、とあるプロダクトの開発プロジェクトに参画しています。
開発にあたって直面している問題が、「デザインの方向性は固まっているのに、エンジニアの工数が足りない」というものです。VOC（ユーザーの声）を基にしたプロダクトの改善も、優先度の関係でなかなか手が回らない。
この状況を乗り越えるため、私はデザイナーでありながら、初めてフロントエンドの開発に挑戦してみました。その裏には、正直、このままデザイナーとして手を動かすだけでいいのか、キャリアを考えたときに「できることを増やさないと」という焦りもあったように思います。
開発にチャレンジするにあたって、まずは使うツールから見直しました。Web会議もZoomからGoogle Meetに切り替え、Google Geminiでリファインメント（次のスプリントで着手する内容を確認・整理するミーティング）の場で話された内容を文字起こしします。
その文字起こしや過去のリファレンスを基に、Claude Codeが要件定義書の叩きを自動生成します。あとはClaude CodeとUIやUXの要件を対話しながら詰めていくという形です。
Claude Code活用の全体像
開発でもデザインでも、何をするにもWhyが大切です。「なぜ、この機能が必要なのか」「なぜ、このUIなのか」──。その問いを深掘りして問い直し、より良い提案へとつなげていく。その過程をClaude Codeが時間ごと圧縮してくれるようになりました。
Claude Codeを取り入れてワークフローを見直した
その後、私はフロントエンジニアとモブプログラミングをしながらGitHubの「お作法」を学び、UIコンポーネントからスタイル定義、テストデータまで自分で作れるようになっていきました（tsx・Stories・Mockなど）。
似たようなデザインパターンがすでに実装されているもの、コンポーネントの改善、軽微な微調整はClaude Code起点で動かせるようになりました。
一方で新規画面についてはFigmaで作成し、MCP経由でリンクを共有。Claude Codeが同じコンポーネントを探し、見た目の再現度が高い状態で実装してくれます。この流れが自分の中で定着してきました。Figmaの役割もマスター管理の場というよりも、新しい画面を検討するための場になってきているように思います。
最初は、VS CodeやCursorといったコードエディタやコマンドにアレルギーがあったものの、ターミナルだけでなくGUIで操作できるツールも充実しているので、一連の操作を繰り返すうちに自然と慣れていきました。
AIはGitHubの操作も自動でやってくれますが、コマンドの意味やコードエディタがどういうものかは、最低限理解しておく必要があると思っています。
今どんな操作が行われているのか、ローカルとリモートにどんな影響があるのかを把握していないと、AIが何をしているのかが分からないまま進んでしまいます。道具に使われないために、仕組みの輪郭だけは自分で把握しておく。それがAIとパートナーを組む上での必須のスタンスだと感じています。
ちなみに、AIが作業を回してくれている間に、Slackの返信やプロジェクト外のタスクなど、小さいサブタスクが並行して回せるようになり、動ける範囲が広がりました。実はこの記事自体も、Claude CodeとグッドパッチのPR観点レビューのSkillsを活用し、AIと行き来しながら書いています。
デザイナーに求められる「評価」の役割 チームのデザイン品質も仕組み化
私自身は、デザイナーからエンジニアの領域に踏み出したわけですが、こうした「越境」はデザイナー以外でも起こっています。
バイブコーディングで誰もがアウトプットを出しやすくなった今、逆に言えば、それを評価できる目の価値が上がっています。
非デザイナーがUIを作る機会が増えているのに、自分でデザインを評価できる仕組みがない。プロジェクトチームが抱えていたこの課題に気付き、品質チェックのGemを作りました。JIS、デザイン原則、プロダクト固有のガイドライン、アンチパターンといったチェック要素を組み込み、非デザイナーでも使いやすい形にしています。
さらに、実装の場でも活用できるようにスキル化して、Claude Codeとの開発フローにも組み込みました。コードを書きながらデザイン品質を確認できるようになったことで、後工程のレビューの手戻りが減っています。
ディレクトリ構成の例
ここで一つ、前提として伝えておきたいことがあります。今回のClaude Codeを使った実装がスムーズに回っているのは、デザインシステムが整っている状態があってこそです。
コンポーネントの命名規則、スタイルの定義、アクセシビリティの基準──こうした土台がなければ、AIは”それっぽいもの”を作ることはできても、人によってアウトプットがバラバラになり、属人化してしまうという課題が生まれます。品質を担保するのは難しい。その環境を整えるには、本来かなりの時間と専門知識が必要です。
グッドパッチのデザインシステム「Sparkle Design」は、この土台作りの工程を大きく省力化してくれます。品質の高い「いいデフォルト」が用意されているので、ゼロから設計しなくてもすぐ使える状態からスタートできます。
さらに、バイブコーディングで出力したコンポーネントが、ガイドラインやアクセシビリティ基準、アンチパターンに沿っているかを自動でチェックしてくれる仕組みが備わっています。デザインシステムを意識しなくても、アウトプットの品質が担保される。この安心感があるからこそ、実装のスピードを上げることができています。詳しくはこちらのブログもぜひ読んでみてください。
仕組み化という観点でもう一つ紹介したいのが、グッドパッチ社内で使われているスキルの共有サービスです。
デザインレビュー、コードレビュー、議事録作成、PRの文章生成……チームや個人の「やり方」を言語化して、再利用可能な形にまとめたスキルをインストールできます。「誰かのノウハウ」を「チームの資産」に変える仕組みとして、必要な場面でスキルを探して使う形が社内で定着しつつあります。
境界が融けるほど、デザイナーの「核」が鮮明になる
デザイナー、フロントエンジニア、PdMといった職種の境界が融けていく。これはグッドパッチのデザイン組織の方針でもありますが、スクラムの現場を経験して、自分ごととして捉えられるようになりました。
でも、越境する中で気付いたこともあります。実装ができるようになっても、自分の中でずっと変わらない問いがあるのです。
例えばAIのアウトプットを見たとき、「このグレーの色、もう少し調整できないか」「この角丸と余白のバランスが気になる」と思ってしまう。これはスキルではなく「自分が納得できるか」という基準、いわば「審美眼」のようなものです。こうしたレビューは、引き続きデザイナーがやる必要があるのでしょう。
プロダクト開発でも、Why（なぜやるのか）、What（どんな価値を提供したいのか）、How（それをどう提供するのか）の要件整理は、誰かがやらなければ本質的な課題を解決できなくなります。
そして、AIにはできないことがもう一つあります。現場に行き、実際にユーザーになって使うなど、一次情報を取りにいくこと。ユーザーが置かれている状況や、その場の感情の機微は、データや文字起こしだけでは見えてこない部分がほとんど。ユーザーの気持ちと課題を圧倒的に理解できる人間であること。それもデザイナーが守るべき核だと考えています。
非デザイナーのアウトプットに対しても、その観点でフィードバックしながら一緒に学んでいける環境を作りたくて、ガイドラインを整備し、Skillsを共有し、ナレッジを共有するSlackチャンネルも作りました。グッドパッチ社内でもクライアントワークでも、やり方を模索中です。
「デザイナーが手掛ける領域は『デザイン』だけではない」ということと「ユーザー体験の責任を持つのはデザイナーだ」というのは、一見矛盾しているように見えるかもしれませんが、自分の中では整合しています。越境するほど、核として守るべき領域が逆に鮮明になっていく感覚です。
生成AIが普及しても、ユーザー体験の責任を持つのは「人間」に変わりはない
AIが普及しても、サービスやプロダクトに込められた想いを届けるのは人間に変わりはありません。たくさんのリファレンス、AIのデータ、ユーザーの声──いろんな文脈を理解した上で、最後に決めるのは人間です。デザインのアウトプットも、コードも、生成AIのアウトプットを鵜呑みにすることはこれからもないと思います。最後は人が評価して、意思決定します。
役割や職種の境界が融けたとしても、最後に体験の責任を取るのは誰か。自分はデザイナーだと答えます。ユーザーとのコミュニケーションも人間が担うべきポイントですし、チームが回る仕組みを作るきっかけも、組織が抱える課題に気付き、解決しようと思えるのも、現場にいる人間に他なりません。
もう一つ、AIが普及したからこそ感じているポジティブな変化があります。かつては「やってみたい」という想いがあっても、技術的なハードルがそれを阻むことがありました。でも今は、AIがその壁を大きく下げてくれています。
ものづくりが好きで、誰かの心を動かしたいという想いがある人にとって、これはすごくうれしい変化です。この観点については、グッドパッチのクリエイティブディレクター・栃尾さんのブログに詳しく書いてあるので、ぜひ読んでみてください。
AI時代、積極的に自分の領域を広げていこうと考えている方。そしてAI時代のデザイナーの価値を考えていきたい方。私はそんな人たちと一緒に働きたいです。少しでも興味を持ってくれた方、お気軽にカジュアル面談からどうでしょう。お待ちしております。
