AIエージェントに「デザインもやっておいて」と頼める時代が、じわじわ近づいています。
MCP（Model Context Protocol）サーバーとして動く AIDesigner は、まさにそのコンセプトを実装したツールです。
「どんな仕組みで動くのか」「実際に使ってみてどうなのか」を、セットアップの手順も含めて具体的に書いていきます。
AIDesignerとは何か――コードベースを読んでデザインを生成するMCPサーバー
AIDesignerは、AIエージェントに「UIデザインを生成する能力」を後付けするMCPサーバーです。
公式サイト（aidesigner.ai）で提供されており、GitHubでは bacoco/AiDesigner として公開されています。
Product Huntでも「Give your agent tools to create beautiful, codebase-aware UI」というキャッチコピーで紹介されていて、エージェント拡張ツールとしての位置づけが明確です。
公式サイトでは「codebase-aware UI generation」という言葉が使われていて、これがこのツールの核心をよく表しています。
多くのAI画像生成ツールは、プロンプトを受け取って「それっぽいビジュアル」を返します。
AIDesignerはそこが少し違っていて、あなたのリポジトリを読んだうえでデザインを生成しようとします。
フレームワーク・CSSトークン・コンポーネントライブラリ・ルート構成といった情報を検出して、既存のスタックに合ったアウトプットを返す、という設計思想です。
アウトプットも画像だけではありません。
Tailwind CSSのクラス構成・CSSトークン・デザインシステムのドキュメントも出力します。
つまり「見た目の参考画像」ではなく「そのまま実装に使えるもの」を目指しているわけです。
MCPサーバーとしての位置づけはシンプルで、Claude CodeやCursorといったMCPクライアントからツール呼び出しを受け取り、デザイン生成の結果を返します。
エージェント側から見ると、コーディング能力に加えてデザイン生成の能力が増えた、という感覚に近いです。
「デザイナーがいないチームでも、エージェントにUIの初稿を任せられる」という文脈で注目されているのも、この構造があるからです。
提供されるツール群と、実際に何ができるか
AIDesignerが提供するツールは6つあります。
大きく「UIデザイン生成系」と「ブランド・メディア系」の2系統に分けると整理しやすいです。
まず、実務で使う頻度が高いのは UIデザイン生成系 の3つです。
generate_ui_design はテキストプロンプトからUIデザインを生成するツールで、デスクトップ・モバイル両方のビューポートに対応しています。
「料金プランページを作って」のような指示で、レイアウト・タイポグラフィ・カラーを含む画面が返ってきます。
ここで個人的に「これは使える」と感じたのが iterate_design です。
既存のデザインに対して自然言語でフィードバックを与えて反復改善できるツールで、「ヘッダーの余白を広げて」「エンタープライズプランをもっと目立たせて」といった指示でゼロから作り直さずに調整できます。
デザインツールを開かずに、チャットだけで初稿を固めるワークフローが現実的に見えてくるのは、このツールがあるからです。
generate_website_design_image はランディングページのスライスやWebサイトの参考画像を生成します。
ブランドキットを指定することも可能です。
ブランド・メディア系 の3つは、ビジュアルアセット全般を扱います。
- generate_image ― 単体の画像を生成・編集する。参考画像や保存済みブランドキットを使った生成にも対応。
- generate_branding_kit_variations ― ブランドブリーフから9種類のブランドアイデンティティ案を3×3のボードで生成する。方向性の検討フェーズで使う。
- generate_media_asset_kit ― SNS用バナーなどのメディアアセット一式を生成する。
ブランド・メディア系は「UIを作る」というより「素材を揃える」用途に近いです。
UIデザイン生成系と組み合わせて使うことで、画面設計からビジュアルアセットまでをエージェントに委譲できる、という構成になっています。
セットアップ：インストールから最初の動作確認まで
セットアップの起点はCLIの初期化コマンドです。
使いたいMCPクライアント名をホストとして渡します。
npx -y @aidesigner/agent-skills init <host>
ホストには claude-code / cursor / vscode / windsurf のいずれかを指定します。
このコマンドが、クライアントごとに異なる設定ファイルを適切な場所に書き出してくれます。
Claude Codeを使う場合、書き出されるファイルは以下の3つです。
~/.claude/agents/aidesigner-frontend.md
~/.claude/commands/aidesigner.md
~/.claude/skills/aidesigner-frontend/SKILL.md
これらはClaude Codeがエージェントとして動くときに参照するスキル定義とコマンド定義です。
initコマンドが自動で配置してくれるので、手動で書く必要はありません。
設定ファイルが書き出されたら、認証を通します。
Claude Codeの場合の手順はシンプルです。
1. 対象リポジトリでClaude Codeを開く
2. /mcp を実行する
3. 一覧から「aidesigner」を選択する
4. ブラウザが開くのでOAuth認証を完了させる
5. /aidesigner コマンドか、「Use AIDesigner to...」の形で指示する
CursorやVS Code・Windsurfの場合も、CLIが対応する設定ファイルを書き出した後、各クライアントのMCPパネルから認証を完了させる流れは同じです。
VS Codeの場合はGitHub CopilotのAgentモードで使います。
最初の動作確認として試しやすいプロンプトは、公式ドキュメントにも載っているこれです。
Use AIDesigner to generate a pricing page with a prominent enterprise plan.
これを投げると、エージェントがgenerate_ui_designを呼び出して、料金プランページのデザインを返してきます。
初回はここまで動けば、接続は正常です。
実際に動かしてみての感触――精度・速度・つまずきどころ
repo-aware contextの動作は、使ってみると「なるほど」と思う部分と「あ、そういうことか」と気づく部分が両方あります。
フレームワークやTailwindの設定を検出して、既存のデザイントークンに近い値でアウトプットしてくれるのは、確かに便利です。
ゼロから色やスペーシングを指定しなくても、リポジトリのスタックに合ったTailwind CSSのクラス構成が返ってくる感覚は、「コードを読んでいる」という実感があります。
ただ、ここで一つ逆説的な気づきがあります。
アウトプットの品質は、コードベース側の整備度に強く依存する ということです。
デザイントークンがちゃんと定義されていて、コンポーネントが整理されていて、命名規則が一貫しているリポジトリほど、AIDesignerの出力がそれに沿ったものになります。
逆に、CSSが散らかっていてトークンもバラバラなリポジトリだと、検出できる情報が少なくなり、汎用的なアウトプットに近づいていきます。
これはデザイン系MCPを使うときに共通して起きる構造的な問題で、AIDesigner固有の話ではありません。
ただ、AIDesignerを使い始めると「自分たちのコードベースはAIに読ませられる状態になっているか」という問いが自然と浮かんできます。
暗黙知が多いコードベースでは、AIが誤った判断をしやすい。
ドキュメントや明文化されたルールが精度を支える、という構造です。
AIDesignerを導入するプロセスが、コードベースの整理を促す副次効果を持つ、という見方もできます。
iterate_designを使った反復改善のサイクルは、体感としてかなり速いです。
「余白を広げて」「このセクションの背景色を変えて」といった指示を重ねていくと、ゼロから作り直すより明らかに早く調整が進みます。
# iterate_design を呼び出すプロンプト例
Use AIDesigner to iterate on the previous design.
Make the enterprise plan card more prominent with a highlighted border,
and increase the vertical spacing between pricing tiers.
こういった指示を重ねると、前回のデザインを起点に差分だけ調整した結果が返ってきます。
「全部作り直し」ではなく「ここだけ直して」が通るのは、実際の作業フローに合っています。
つまずきやすいポイントとして正直に書いておくと、コードベースの暗黙知が多い場合に意図しない結果になりやすいです。
「なぜかうちのデザインシステムを無視したコンポーネントが生成される」という現象は、AIDesignerに限らずデザイン系MCPでよく起きます。
その場合の対処は、暗黙知を明文化してコードベースに残すことです。
向いている使い所・向いていない使い所
AIDesignerが一番力を発揮するのは、「完成度よりもスピードが優先される初稿フェーズ」です。
プロトタイプや社内ツールのUI、LPの初稿生成といった場面では、デザイナーがいなくてもエージェントに任せて動けるものが出てきます。
「何もない状態から議論できるレベルのもの」を素早く作るのが得意で、そこから人間がレビューして方向を決める、というサイクルに組み込みやすいです。
一方で、ピクセルパーフェクトな最終仕上げには向きません。
マーケティング用の画像やブランドの公式ビジュアルを一発で完成させるような使い方も、現時点では期待値を下げておいた方がいいです。
AIDesignerは公式にも「UI-focused」と位置づけていて、テンプレートレンダリングや画像エクスポートは対象外です。
「デザイナーがいないチームでの底上げ」と「デザイナーとの協業補助」という2つの文脈で考えると、どちらにも使えますが性格が少し違います。
デザイナー不在のチームでは、エンジニアがAIDesignerを使って初稿を出し、そのまま実装に進む流れが現実的です。
デザイナーがいるチームでは、「叩き台を素早く出してデザイナーにレビューしてもらう」という補助役として使う方が、お互いの役割が明確になります。
導入を判断するうえで、個人的に重要だと思う軸はコードベースの整備度です。
デザイントークンやコンポーネントが整理されているほどアウトプットの品質が上がるので、「今のリポジトリの状態でAIに読ませて意味があるか」を先に確認しておくと、期待値のズレが少なくなります。
チームにデザインの評価眼がある人がいるかどうかも、品質管理の観点から見ておきたいところです。
生成されたものを「使える・使えない」と判断できる目がないと、そのまま実装に流れてしまうリスクがあります。
UIを頻繁に変更するプロダクトほどiterate_designの恩恵を受けやすく、逆に一度作ったら長期間変えないような画面には導入コストが見合わないかもしれません。
AIDesignerは「デザインを自動化するツール」というより、「デザインの初速を上げるツール」として捉えた方が、使い所の判断がしやすいと思います。
完成品を期待するのではなく、「議論の起点になるものを素早く出す」という役割を与えると、実務に組み込みやすくなります。
株式会社ホコサキは山口県宇部を拠点に、Web制作・業務システム開発・AI活用支援を手がけています。
AIDesignerのようなMCPツールの導入検討から、既存ワークフローへの組み込み支援まで、実務ベースでご相談に乗っています。
気になることがあれば、お気軽に お問い合わせ からどうぞ。