デザインとAIの今とこれから 前編 デザイン実務におけるAI活用の現在地
AIの台頭によってデザインの仕事はどう変わるのか。エンジニア・テクニカルディレクター・UIデザイナーの3名が、AIをデザインプロセスに取り入れている現状や、DESIGN.mdのようなコンセプトワークの重要性について語り合います。
はじめに
Web制作の現場では、ワイヤーフレームを元に画面デザインが作られ、それをエンジニアが実装するという工程が何年も続いてきました。デザイナーが使うアプリケーションの変遷はあっても、職能ごとの役割と制作フローに大きな変化はありませんでした。
AIの台頭によって、ひと足先にコーディングの工程でのエンジニアの働き方は大きく変化し、今も適応しながら新しい開発現場の在り方を模索している状況といえるでしょう。そのうえで、サイト制作に欠かせないデザインの領域はどのように変わっていくのかを、長年Web制作にたずさわってきたメンバーで話します。
参加者は次のとおりです。
なお、この座談会は2026年3月下旬に行われました。発言の内容には、2026年3月時点の状況を反映したものが含まれています。
UIデザインの動きを確認するためにAIを活用
――AIの技術が発展して、「デザインの仕事はなくなるんじゃないか」というような漠然とした発言を見かけることもあります。実際にはどういった変化が起こってるのか、これからどうなっていきそうかについて、この座談会では話していきたいと思います。
中村：ピクセルグリッドのUIデザイナーである小原さんは、現時点でいいのですが、AIをどういうふうに使ってて、どの辺りに効果を感じていますか？
小原：デザインそのものを作っていく作業は、現時点ではAIは使ってません。デザインファイルを作る工程は、今でも自分で考えて手を動かしたほうが早い。社内のコードを書く人たちは今ではものすごくAIを活用しているなという印象を持ってるのですが、デザインの仕事でも同じくらい活用できているとは言えません。
でも、すでにAIはデザインの品質向上に貢献してくれていますよ。
Figmaで作ったデザインって、所詮パラパラ漫画というか、まだ動いていないので、実際にそれを動かしたときの感触はわからないんです。経験からある程度の想像はつくけれど、実際に動かして設計の良し悪しを判断したいケースがあります。
僕の場合は、実際に動かして判断したいのは、UIデザイン。UIデザインって、個々の画面で完結することって少なくて、ユーザーが操作する複数の画面の遷移や操作したときのインタラクションなど一連の流れ、全体を体験として考えたいんですよね。デザインツール上でモックアップを作っても、細かいインタラクションは実装したものとは差があります。自分の頭の中では、「これをポチっと押したら、これが横から開いて、何かやって、閉じて、戻って……」みたいに組み立ててみるんだけれども、実際に動かしてると「意外と微妙だった……」みたいなのって、いっぱいあるんですよね。
そういうのは、やっぱりデザインの段階で動かして確かめたいんです。体験を確認したい部分だけ見た目を作り込む前に簡単な画を作って、AIにコードを書いてもらえば、すぐに画面を触ってみることができるようになる。
中村：なるほど。動きを確かめたりとか、そういうプロトタイプ的なものは、自分だけが確かめる用途ですか？ それともクライアント確認などでも使いますか？
小原：小さい部品レベルのものは、自分の確認用です。「こういう動きをするコードを書いて」と指示して、それをJSFiddleとかにコピペして実行して確認します。これまでは自分でコードを書いてたんですけど、それを書く手間が減った。
中村：そのときのAIは、何を使っていますか？
小原：最初はChatGPTでしたけど、今はCodexのアプリを使ってます。
共有するような大きめの単位の場合は、Figma Makeを使います。Figma Makeのメリットは、チーム内に共有すれば、リアルタイムで同じものを見ながら触りながら、コミュニケーションがとれて、変更は即時ビルドされるところですね。あと、デザインツールとしてFigmaは扱い慣れているし。
高津戸：Figma Makeでは、デザインのバリエーションを出してみたりとかはしないんですか？ 自分だったら、余白を変えたパターンも見てみたいとか考えるんだけど。
小原：その辺は、自分は訓練されちゃってるから予測が利くので必要ないって感じですね。
AIにバリエーションを作らせて選ぶというやり方
高津戸：僕は個人事業の方のサイトでFigma Makeを使えないかなって試してみたけど、イマイチだったんで解約しちゃったんですよね。
――どんなことをやりたかったんですか？
高津戸：既存ページに何かを追加したいときに、最初からソースコード触って追加するのは面倒くさい。そもそもイメージが湧かないので、今までは、ページのスクリーンショットの上に線を引いたり、テキストを置いてみたり、画像を並べてみたりして考えていたんです。
なので、Figma MakeはMCPとかいろいろできるから、自分のサイトを読み込ませて、やりたいことをプロンプトで指示したらできそうだなって期待したんですよね。でも、試してみたら、読み込んでも微妙に崩れてるし、僕の求めてる精度で「こんな、余白がいい感じになってくれた！」みたいにはならなかったんですよね。
今はClaude Codeに任せるやり方を考えたので、僕にはデザインツールは要らないかな。
中村：ずどさんは個人事業の方でもAIを使った開発をいろいろやっていて、デザインもお願いしていると聞いているんですが、具体的にどんな風に使ってます？
高津戸：初めてAIにデザインも作らせたのが、妹がやっている教室のWebサイトです。僕はサイトのデザインを一からやりたくなかったんですよね。でも、AIに任せるとCSSを自分が納得の品質で書いてくれないという経験がありました。たとえば、僕が「余白をいい感じにして」っていう指示をしたとしても、「いい感じ」っていうのは抽象的な表現だから、AIには伝わらない。なので、ルールを書いたドキュメントをまとめました。
いわゆるCSS設計なんですけど、これを（Claude Codeの）スキルにして、ルールに基づいたこのサイト用のデザイントークンを作らせて、それを元にデザインのバリエーションを作らせました。「申し込みの流れのページを30パターン作ってください」って指示すると、こんな感じで出てくる。全部そのデザイントークンにしたがっているものが30パターン作られる。たとえばこんなかんじでバリエーションを作ってくれます。
実際には、最初はアイディア出しとしてルールは渡さずに作らせてみる。ある程度方向が出たところで、ルールを渡して、これを読んでそのとおりにやってくださいって言うと、きちんと揃う。CSSをうまく書いてくれないっていう問題は、これでほぼ解消されました。
AIと一緒にCSSを書くためのツール（高津戸談）
座談会中で少し話が出ましたが、AIに伝える開発の基盤というようなものが、Claude Codeのスキルとして汎用的なものとして固まってきて、さらに目的によって複数まとまってきました。
CSSを書かせる方法としては、私は次の流れを試みています。
- 反映させたいCSS設計をドキュメントにまとめ、実装時にそれを読ませる（zudo-css-wisdom）
- デザイントークンに外れたCSSを見つけたらlintでエラーにする（zudo-design-token-lint）
- 作ったページ内でデザイントークンの値を直接変更できるパネルのUIを用意し、自分でも直接トークンの編集をしやすくする（zudo-design-token-panel）
いずれも作りかけという状態ですが、各々以下で参照していただけます。
（高津戸）
高津戸：こうやってAIに要件を伝えれば、1時間くらいで制作はできるんです。でも、出てきたものを選ぶのは人だし、どうしたいっていうのは伝えないと形にならないので、デザインはしないといけないと考えてます。
今、僕のサイトのトップページを変えようと思ってるんですけど、何をどんなふうに配置したらいいのかみたいなことを決めるまでに時間がかかる。AIに相談しながら、20パターン作ってもらって、「これがいいかも」とか、「じゃあここに商品情報を並べたいんだけど、どういうバリエーションがあるか」って、また作らせてっていうのを繰り返して作っていってるんですよね。
中村：あれですね、デザイナーが作ったオススメ案と別案をいくつかクライアントに見せて、方向性を決めていたなという昔のWeb制作のワンシーンを思い出しました。
小原：今、ずどさんがやってるのは、ザッピングに近いんじゃないかな。指針を作ることができないので、とりあえずたくさん作ってみて、その中から雰囲気の合うものを選ぼうかなっていうやり方。それを精度を高くして、効率よく作っていくなら、「ワシのサイトはこういうルールでやっていくんで、こういう色をどういう時に使うんだ」みたいなものをAIに渡して、その上で30個作るように指示を出す。そうすれば、トンマナを外さない上でのバリエーションから選ぶだけになるので、かかる時間は短縮されると思いますね。
高津戸：そうですね。
デザインの言語化がデザイナーの中核に
中村：でも、トークンだとかきちんと定義してAIに渡せば、デザインツールを介さなくても、十分なクオリティのものが作れるようになってきてるってことですね。僕は、AIが読みやすいデザインシステムが結構大事なんじゃないかって、思ってるんです。
小原：めっちゃそう思いますね。現状では、私は自分の作業をアシストしてもらう役割としてAIを使ってますけど、今後、自分の役割をデザインを作るというよりはコンセプトワークをして、AIを上手に使って物を作るっていう在り方に変えていきたいと考えています。デザインシステムだったり、コンセプトだったりって、結果として作るもののトーンアンドマナーを定義してることなので、それを設計する役割。
中村：この間社内でシェアしてたGoogleのStitchを僕は触ってみたんですけど、小原さんはもう触りましたか？
小原：まだ触ってないですね。でも、まさにコンセプトを決めてAIに指示してデザインを生み出すツールですよね。（2026年）3月の大規模なアップデートで目玉となった機能が、DESIGN.mdというものを書き出せるようになったことです。
GoogleのStitch
StitchはGoogle LabsのAI支援UIデザインツールです。テキストや画像をもとに画面案やプロトタイプを作成でき、DESIGN.mdの入出力やMCP連携にも対応しています。2026年3月のアップデートでは、AIネイティブなキャンバスと複数案の管理機能が追加されました。
DESIGN.mdは、Claude CodeでいうCLAUDE.mdみたいなもので、画面をデザインするためのコンテキストやルールをまとめたドキュメントです。要するにデザインを言語化することで、AIとデザインに関する対話が可能になるという。AIに作業を任せるには、コンセプトワークが大事なんですよね。
高津戸：これは良さそうだな。
――小原さんは、この先、AIがデザインを作っていくっていう予感はありますか？ 今は自分がやったほうが早いって感じでやられてると思うんですけど。
小原：これからデザイナーは、コンセプトワークで食っていかないといけないなとは思いますね。”デザイン”って言葉が広すぎてて話しにくいんですが、具体的なデザインを作る領域はAIに任せることになると思います。一方、指針を決めるところはデザイナーが担う範疇で、それが”デザイン”を作る上流工程。その指針に沿った画面を組み立てていくのはAI。
Webサイトやアプリ制作ではいろんな画面が必要じゃないですか、それらを量産するためのルール、方針を決めることはすごく大事だから、そこは誰でもいいわけではないものとして残るというか、個性が残る部分なんじゃないかなと思うんですよね。
――そこが残れば、実際に作るのは誰でも構わないようになっていくのではということ？
小原：AIが作っていくのではないでしょうか。だから私がやるのはDESIGN.mdを作ることに変わっていくんじゃないかと。AIに指示を与えておいて、たとえば寝る前にポチっとやっとけば、朝にはサイト分のページがすべてでき上がってるみたいな。
――小原さんの中で、DESIGN.mdはこういう風に作ったらよいんじゃないかとかってありますか？ デザイントークンとかはすでにあるものを使えるとは思いますけど。
小原：情報伝達の領域は、体系立ったルールで対応できるんですけど、そういったものは世の中に無限にあるわけです。それは、AIも知識として持っているけれど、どのルールを適用するかっていうのは決まってないですよね。プロダクトやサービスに合わせて、どのルールを使うかは、デザイナーの知識に基づく判断が必要で、それをDESIGN.mdでAIに伝える。
たとえば、「このサイトは事務的なサイトなので、一覧性を維持して、情報ストックを多くさせたいから全体的に狭めのジャンプ率で設計する」みたいな指針を伝えるとか、あとは個々の要素を揃える必要があるというのがあるのであれば、それらもちゃんと書いておく。
色もそうですよね。どういうときにどんな色を使うかだけじゃなくて、サイトのベース色とアクセント色の割合は6対4なのか、それとも1対9なのか。アクセントカラーは1色しか使ってはいけない、2色まではOKとか。5色アクセントカラー使ったら、カラフルなサイトになりますよね。デザイナーは、そういうデザインを設計する側に回る。
高津戸：でも、聞いてて、一般的なデザイナーがそういう発想を持っているのかを少し疑問に感じましたね。
小原：でもデザインってそうなんですよ。コンセプトを維持してサイトを作るときに、デザイナーはコンセプトを表現するために、色の面積の割合とかいろいろな視覚効果を組み合わせて構築していくので。
――デザイナーには、そこで何を記述しなきゃいけないかっていう軸も見えてるし、ある程度こういうものを作りたいっていう言語化も、やれって言われればできるぐらいのレベルってことですか？
小原：一定の品質が維持されたものを作ろうとしてやってるデザイナーならば、できると思いますよ。毎回、なんとなく手癖で作っているタイプのデザイナーだと大変かもしれない。
高津戸：AIを使っていけるようになる人は多分そこが不可欠ですよね。「AIに頼むんだったら、今俺がやってることってどういうことなのかな？」って、一度咀嚼して言語化できないと。
小原：AIの活用が当たり前のデザインの世界では、デザインの言語化をできる人じゃないと残れない気がしますね。
中村：最終的な画面の見た目は、全部AIが出すようになるというか、中間生成物だったデザインファイル自体は不要になりますよね。必要になるのは、AIがちゃんとしたアウトプットをするためのDESIGN.mdみたいなもののほう。
一方、それを作るためのツールみたいなのが、さっきのStitchもそうだけど、出てくるんじゃないですかね。デザイナーがコンセプトとなる見た目を作って、AIがそれを元にHTMLとかCSSのルールを書き出すみたいな。
――確かに、見た目を作ったらそれを何らかの形でDESIGN.mdとして言語化してくれるツールのニーズはデザイナー側から生まれそうですね。
高津戸：Figmaもうまい塩梅を探りながら開発機能アップデートしてる感じはするので。それはなってく気はしますね。
中村：FigmaがDESIGN.mdみたいなのを吐けるようになっていくと、使い慣れたツールがAI用のデザインシステムになっていくとかね。そうなると、Figma上で過去に作ったルールを次に渡すみたいなことができるようになったりするのかもしれません。
――なるほど。では、次は、AIを開発リソースとして迎えた時、私たちはどういった役割分担をしていくようになるのか、また、AIをうまく使っていくために人間が身につけるべきことはどういったことかについてお話いただければと思います。（後編に続く）