デザイナーのためのAIエージェント：エージェント型ワークフローの設計と構築

チャットボットとエージェントの違いは、次のメッセージを待つジュニアと、仕事全体を片付けてくるジュニアの違いだ。

その「後者」が、ここ18ヶ月のうちにあなたのツールに姿を現した。しかし大半のデザイナーはまだ気づいていない。チャットウィンドウにプロンプトを打ち込み、答えをコピーして、Figmaに貼り付けて、「なぜワークフローが2023年を少し速くしただけに感じるんだろう」と不思議がっている。エージェントへの転換は「より賢いChatGPT」ではない。カテゴリーの変化だ。

エージェントはゴールを受け取る。どのツールを呼ぶかを自分で決める。順番に呼び出し、結果を読み、軌道修正し、完成したものをあなたに渡す。もうチャットに打ち込んでいるのではない。小さなチームにブリーフィングして、成果物をレビューしているのだ。

チャットボット、コパイロット、エージェント、そしてその違いが重要な理由

3つの言葉が同じ意味のように使われている。そうではない。

チャットボットはターン制だ。あなたが聞き、それが答え、あなたがまた聞く。ツールなしのChatGPT、プレーンなチャットウィンドウのClaude、アプリのGemini。コンテキストはあなたが貼り付けたもの。出力はテキストだ。

コパイロットはインライン補助だ。GitHub Copilot、FigmaのAI機能、Notion AI。別のツールの中に住んでいて、あなたが作業する間に次の動きを提案する。あなたのいるレーンを出ない。複数ステップの作業を計画しない。

エージェントはゴール指向だ。次のステップではなく、アウトカムを与える。自分でツールを選び、ループでそれらを呼び出し、自分の進捗を確認し、ゴールが達成されるか入力が必要になると停止する。最も明確な現代の例は、MCPサーバーを接続して端末で動くClaude Codeだが、ChatGPTのエージェントモード、Cursorのエージェントパネル、AnthropicのComputer Useもすべて同じように動作する。

要点：チャットボットは応答し、コパイロットは支援し、エージェントは納品する。

エージェントはループであり、単一のプロンプトではない

あなたが使うすべてのエージェントは、同じ4ステップのサイクルを実行する。この形を覚えれば、どんなエージェント型ツールがどう動くか予測できる。

1. 計画する。 エージェントはゴールを読み、最初のステップを決める。
2. 行動する。 ツールを呼び出す。ファイルを読み、APIをクエリし、コマンドを実行し、URLをフェッチする。
3. 観察する。 ツールの出力を読み、ゴールに近づいたかどうか判断する。
4. 反復する。 完了していなければ、次のステップを計画する。完了していれば、報告する。

ループがすべてだ。エージェントに人々が帰属させる魔法は、十分な有用なツールが接続された状態でループがきれいに動いているだけだ。ループがなければ、エージェントではない。一度だけ返答するモデルはチャットボットだ。ツールを持ち、ゴールに向かってループを実行するモデルがエージェントだ。

2026年のデザイナーのエージェントツールキット

ゼロからエージェントを構築する必要はない。2026年4月、デザイナーにとって有用なエージェントの領域はこうなっている。

Claude Code。 端末またはVS Codeの中に住んでいる。リポジトリ全体を読む。ファイルを呼び出し、コマンドを実行し、MCPサーバーと通信する。コード、トークン、またはデザインシステムのリポジトリに触れるものすべてに最適。

Claude DesktopとMCP対応ChatGPT。 どちらも今やMCP接続をサポートしている。Figma、Google Drive、Notion、Linear、ファイルシステムに接続できる。コーディングよりも、リサーチ、ブリーフ、スペックライティング、コンテンツ作業に向いている。

Cursorエージェントモード。 React、Vue、Svelteでの構築向けエディタネイティブエージェント。Claude Codeと機能的に近いが、端末の代わりにビジュアルインターフェースがある。

Figma MCP。 エージェントそれ自体ではない。ツールコネクターだ。FigmaをエージェントがReadできるデータソースに変える。一度接続すれば、MCP対応のすべてのエージェントがあなたのフレームを見られる。セットアップはFigma MCP：FigmaをClaude CodeとAIエージェントに接続するでカバーされている。

n8n、Zapierエージェント、カスタムスクリプト。 スケジュールで動作するか、Webhookに反応するエージェント（新しいFigmaコメント、新しいGoogleフォームの送信、共有受信トレイの新しいメール）が必要な場合、これらがホスティングプラットフォームだ。デザイナーはこれらを「グルー」エージェント、あなたが眠っている間にバックグラウンドで動くものに使う。

ほとんどのデザイナーにとって、適切なスターターはClaude Code、Figma MCP、Google DriveまたはNotionへの接続1つだ。それだけでエージェント型デザイン作業の90パーセントをカバーできる。

エージェントの設計方法（それはまだブリーフだ）

エージェントの設計はコーディングタスクではない。ブリーフィングタスクだ。フリーランサーやジュニアに仕事を渡すたびにやっているのと同じものだ。

何かを構築する前に、順番に答えるべき4つの質問がある。

1. ゴールは何か？ 1文で。「クライアントのディスカバリーコールトランスクリプトからムードボードと短いクリエイティブブリーフを作成する。」
2. エージェントにはどんなツールが必要か？ リストアップする。「Google Docを読む、ウェブを検索する、画像をフェッチする、Figmaファイルに書く、Google Driveフォルダに保存する。」
3. どんなルールが制約するか？ 「エディトリアルソースからのみ画像を引き出す、ストック写真は不可。ブランドを絶対に発明しない。すべてのソースを引用する。常にハウスフォーマットでブリーフを作成する。」
4. どこで停止するか？ 「Figmaファイルに少なくとも12個のリファレンスを持つムードボードフレームがあり、ブリーフが共有ドライブにPDFとして保存されたとき。」

ゴールを見落とすとエージェントは漂流する。ツールを見落とすと間違ったツールで即興する。ルールを見落とすとトレーニングデータの平均を出荷してくる、それは大抵ストックとAIスロップだ。停止条件を見落とすと永遠にループするか早期に停止する。

これはデザイナーのためのプロンプトエンジニアリングでカバーされた5パートのプロンプトと同じ形状で、複数ステップの作業にスケールアップしたものだ。

レシピ1：リサーチからムードボードへのエージェント

すべてのデザインスタジオが最初に構築すべきエージェント。クライアントのディスカバリーコールトランスクリプトを食べ、ファーストパスのムードボードと短いクリエイティブブリーフを作る。

ゴール。 ディスカバリーコールトランスクリプトから、FigmaにムードボードとGoogle Driveにクリエイティブブリーフを作成する。

必要なツール。 Google Drive MCP（トランスクリプトを読む、ブリーフを書く）、ウェブ検索、画像フェッチ、Figma MCP（ムードボードフレームに書く）。

システムプロンプトの形状。 これはセッションの冒頭に一度エージェントに与える指示だ。

You are a senior brand strategist at Brainy, a design studio with 2M+
community followers. Your job: turn a discovery call transcript into
a first-pass creative direction.

Goal:
- Read the transcript at the Google Drive URL I give you.
- Extract: client name, industry, audience, brand adjectives (3-5),
  competitors mentioned, any visual references they named.
- Produce two deliverables:
  1. A creative brief, saved as a Google Doc in /Brainy/Briefs/
     using our template at /Brainy/Templates/brief.docx.
  2. A Figma moodboard in the file I specify, populated with at
     least 12 editorial image references (no stock photography).

Rules:
- Use only editorial sources: Are.na, It's Nice That, Brand New,
  museum archives, design studio portfolios. Never Shutterstock,
  Getty, or Unsplash generic.
- Every image needs a source URL captioned on the Figma frame.
- Voice for the brief: Brainy house voice. Opinionated on craft,
  neutral on facts. No corporate filler.
- If the transcript is unclear on an adjective, flag it as "needs
  confirmation" in the brief instead of inventing one.

Stop when:
- Brief is saved, moodboard has 12+ captioned references, and you
  have posted the two URLs back to me.

これが機能するエージェントブリーフだ。Claude DesktopにDriveとFigmaへのMCP接続と一緒に貼り付け、トランスクリプトに向け、出力をレビューする。

レビューすること。 形容詞は正しいか？リファレンスはブランドに合っていて、ありきたりなものに流れていないか？すべての画像にソースとキャプションがついているか？ブリーフはハウスボイスか、それともLinkedIn英語に戻ったか？

反復。 最初の実行はラフだ。エージェントが見落としたものでシステムプロンプトを更新する。もう一度実行する。3〜4サイクル後、エージェントはクライアント向けストラテジストに書き直しなしで渡せるブリーフを出荷する。

レシピ2：スペックからハンドオフへのエージェント

このエージェントは「デザインが承認された」と「開発者が必要なものをすべて持っている」の間のギャップを埋める。Figmaファイルを読み、エンジニアリングハンドオフドキュメントを書く。

ゴール。 FigmaファイルのURLが与えられたとき、コンポーネントインベントリ、トークンリスト、スペーシング値、未解決の質問を含む開発者ハンドオフドキュメントを作成する。

必要なツール。 Figma MCP、出力を書く場所（Notion、GitHubイシュー、Google Doc、お好みで）。

システムプロンプトの形状。

You are a senior design systems engineer acting as the bridge
between a design team and a front-end team.

Goal:
- Read the Figma file at the URL I give you.
- Produce a handoff document containing:
  1. Component inventory: every component instance used, counted,
     with Figma component name and closest existing code component
     name from our /components/ directory.
  2. Token usage: every color, spacing, and typography variable
     referenced, compared against /design/tokens.css.
  3. Layout specs: breakpoints used, any auto-layout frames that
     might be ambiguous at edge cases.
  4. Open questions: a bulleted list of anything in the Figma file
     that cannot be resolved from the file alone (missing states,
     unclear interactions, content placeholders).
- Write the output as a Notion page in /Engineering/Handoffs/.

Rules:
- Never invent a component. If a Figma element does not map to an
  existing code component, list it under "new components required"
  with a one-line description.
- Flag every free-form (non auto-layout) frame as a risk.
- Include the Figma node ID for every item so devs can jump to it.
- Do not assume interactions that are not explicitly in the file.

Stop when:
- Notion page is written and you have posted the URL back to me.

このレシピが重要な理由。 「デザイナーはハンドオフしたつもりだった、開発者はトークンを見つけなかった」問題は典型的だ。このエージェントはそれをフィーチャーごとに約90秒で排除する。

壊れるところ。 散らかったFigmaファイルで。非auto-layoutフレーム、一貫性のない変数の使用、ランダムなワンオフコンポーネント。エージェントはその散らかりを明るみに出す。それはギフト（今わかった）か問題（今修正しなければならない）かのどちらかだ。

レシピ3：デザインQAエージェント

デプロイ後に実行し、何が間違って出荷されたかを教えてくれるエージェント。

ゴール。 デプロイされたステージングURLを記録のFigmaファイルと比較し、ビジュアルドリフトを報告する。

必要なツール。 Figma MCP、Playwright（ステージングページのスクリーンショットを撮るため）、画像比較（ClaudeはビジョンモードでネイティブにDiffできる）。

システムプロンプトの形状。

You are a senior product designer doing a pre-release visual QA pass.

Goal:
- Visit the staging URL I give you at three breakpoints: 1440px,
  768px, 375px.
- For each breakpoint, take a full-page screenshot using Playwright.
- Compare each screenshot to the corresponding Figma frame at the
  URL I provide.
- Produce a QA report listing every visual difference, categorized:
  - BLOCKING: wrong components, wrong colors, broken layouts
  - NON-BLOCKING: spacing off by less than 4px, minor type weight
    mismatches, image crops slightly different
  - INFORMATIONAL: intentional differences between design and code
    worth noting

Rules:
- Do not flag differences that are within 2px of intended spacing
  unless they visibly break alignment.
- Include a screenshot-with-annotation for every BLOCKING item.
- Link every item back to the Figma node ID.
- Output as a Markdown file in /qa/reports/ with timestamp.

Stop when:
- Report is saved and you have posted the path back to me.

このレシピが重要な理由。 ほとんどのチームはデザインQAを手動で行うか、まったく行わない。QAエージェントはプリプロダクションデプロイのたびに実行される。目が3ページ目に見落とすドリフトの80パーセントを捕捉する。

デザイナーがどう使うか。 ステージングデプロイで自動的に実行されるようにCIに組み込む。または手動で保ち、可視化されるものを出荷する前に実行する。どちらにしても、「これは正しく出荷されたか」のボトルネックでなくなる。

エージェントにできないこと（まだ）

自分に正直になれ。2026年4月時点でエージェントが失敗するところはここだ。

センスの判断。 エージェントは有能なムードボードを出荷する。そのムードボードが感情的にフラットだとか、ブランドはもっと節制を強調すべきだとかは言えない。それはまだあなたの仕事だ。

曖昧なゴール。 「サイトをよくして」はゴールではない。エージェントはループするか、ジェネリックな出力を生成する。明確な停止条件を持つ1文でゴールを述べられなければ、エージェントには勝ち目がない。

新規ストラテジー。 エージェントはあなたが定義したストラテジーを実行するのに優れている。白紙から発明するのは苦手だ。ポジショニング、ブランドアーキテクチャ、ファーストプリンシプルのプロダクト判断はまだ人間の仕事だ。

長期的な判断。 エージェントは「このButtonバリアントは使われていない」と言える。「もうすぐ4番目のButtonバリアントが必要な価格ページをローンチするので、削除しないで」とは言えない。エージェントはスナップショットを見ているのであって、ロードマップではない。

クライアントやパートナーとの信頼が必要なもの。 クライアント向けストラテジスト、フリーランサーにフィードバックを与えるアートディレクター、アイデアをピッチするクリエイティブディレクター。エージェントはこれらの人間を支援する。置き換えはしない。

ルール：エージェントは実行を担う。センス、ストラテジー、信頼は人間が担う。

エージェントユーザーではなく、エージェントデザイナーとして考える方法

エージェントを使うことと、エージェントを設計することは違う。ほとんどのデザイナーは最終的に両方をやることになる。

エージェントを使うことはプロンプト作業だ。ブリーフを書き、出力をレビューし、反復する。

エージェントを設計することはシステム作業だ。ゴールを定義し、ツールを選び、制約を書き、停止条件を設定し、エージェントが時間とともに改善されるフィードバックループを構築する。プロンプトを書くよりも、小さなチームを動かすことに近い。

良いエージェントを設計する人と壊れたエージェントと格闘する人を分ける3つの習慣。

1つ目、ツールを開く前にブリーフを書く。 ゴール、ツール、ルール、停止条件が紙にあるまでタイピングしない。1時間の迷走を節約できる。

2つ目、コードのようにシステムプロンプトをバージョン管理する。 ファイルに保存する。できればgitにチェックインする。エージェントが新しい方法で失敗するたびにルールを追加する。プロンプトは時間とともに賢くなる、うるさくなるのではなく。

3つ目、最初の10回の実行をすべてレビューする。 デフォルトで信頼しない。すべての出力を読み、評価し、プロンプトの更新に使う。10回の実行後、エージェントはバックグラウンドで動かせるほど信頼できる。10回前はそうではない。

AIワークフローの詳細な解説がもっと欲しければ、Brainy Papersの残りを閲覧してほしい。最初の3ヶ月の試行錯誤なしにエージェント型ワークフローをチームに組み込みたければ、Brainyを雇って、スタック全体を出荷する。

デザイナーのエージェントスタータープラン

1週間、1つのエージェント、1つの動くループ。

• 繰り返しやっているワークフローを1つ選ぶ。空想のワークフローではなく。今月実際にやったものを。
• ゴールを1文で、ツールリスト、ルール、停止条件を紙に書く。
• Claude CodeまたはClaude DesktopをMCP接続1つで設定する（Figma、Drive、またはファイルシステム）。
• ブリーフをシステムプロンプトとして貼り付ける。実際の入力でエージェントを実行する。
• 出力を批判的に読む。自分が出荷したであろうものと照らし合わせて評価する。
• 失敗したことでプロンプトを更新する。もう一度実行する。
• 3〜5回繰り返す。自分でやる場合と比べて各実行にかかる時間をメモする。
• 最終的なシステムプロンプトを保存する。それがあなたの最初のプロダクションエージェントだ。

一度やれば、2番目のエージェントは半分の時間でできる。4番目のエージェントは午後一つで完成する。8番目のエージェントはあなたが眠っている間にスケジュールで動く。

FAQ

AIエージェントを構築するにはコードを書く必要があるか？

いや。上のレシピはすべてシステムプロンプトとMCP接続で設定され、どちらもUIまたは単一のコマンドで設定できる。プロダクションコードを書くのではなく、ブリーフを書き、ツールを接続している。Zapierを設定できるなら、エージェントも設定できる。

Claude Codeと「Claudeエージェント」の違いは何か？

Claude Codeは1つの特定のエージェント、端末に住みコードベースで作業するために構築されたものだ。「Claudeエージェント」はClaudeモデルを搭載したどんなエージェントでも指す。Claude Code、ツールを持つClaude Desktop、Anthropic APIを通じて構築されたカスタムエージェント、またはClaudeをアンダーザフードで使うChatGPTスタイルのエージェントが含まれる。Claude Codeは2026年のデザイナー・デベロッパー作業のフラッグシップエージェントだ。

エージェントを動かすのにいくらかかるか？

個人のデザイナーにとって、Claude MaxサブスクリプションまたはChatGPT PlusサブスクリプションがそれぞれClaude Codeとエージェントモードをカバーする。月に低め数百ドルの範囲で動き、必要なツールのほとんどが含まれる。チームの場合、API使用量はエージェントの実行量に応じてスケールする。ヘビーユースでデザイナー1人あたり月$50〜$200からスタートする予算。節約できる時間に比べれば安い。

あなたは今、小さなチームを動かしている

かつてあなたはデザイナーだった。ブリーフを受け取り、作業を生産していた。それは今も仕事の一部だ。

今は2番目の部分がある。最初の部分をやりながら作業を生産するエージェントの小さなチームにブリーフを書く。彼らの出力をレビューする。漂流したら修正する。成果を上げないエージェントを引退させ、成果を上げるものを昇格させる。

この転換を最初に理解するデザイナーが、この10年を支配する。エージェントがデザイナーを置き換えているからではなく、エージェントを動かすデザイナーがそうでないデザイナーを置き換えているからだ。

ワークフローを選べ。ブリーフを書け。最初のエージェントを出荷しろ。出力をレビューしろ。月曜日にもう一度やれ。