Grok Bot デザインガイド：実プロダクトのアニメーション資産とFigmaマスターで試作ループを短縮する
John Baiによる4つのデザインAgent：デスクトッププロトタイプの探索、アニメーションの手触りの調整、本番コンポーネントの一括流し込み。
Grok Bot のデザインガイド。John Bai が Grok Bot を用いてプロダクト自体をデザインした実践に基づきます。4つの常駐Agentがコンセプトの試作、アニメーションの磨き込み、Figmaでの定型生産、エンジニアリング相談を分担し、デザイナーが実際に体験できるバージョンにより早い段階で触れられるようにします。
この手法は既存のデザインツールをそのまま活用し、実際のアニメーション仕様やFigmaマスターコンポーネントも使用します。Agentは「制作・体験・修正」のループを加速させますが、どのバージョンを採用するか、そしてそれが日々の業務で真に役立つかの判断は、依然としてデザイナー自身に委ねられています。
4つのデザインAgentにおける役割定義と連携メカニズム
複数のAgentを混乱させることなく協調動作させるには、まず各役割の責務の境界を明確にする必要があります。このワークフローにおいて、4つのBotは単なる漠然としたチャットボットではなく、厳密に役割分担され、それぞれ異なるツールチェーンを握る専門パートナーです：
- Experiments（アイデア探索員）：最終形がまだ定まっていない、未成熟な先進的アイデアを専門に引き受けます。その唯一の目標は、コンセプトを素早く実際に触れる形にすることであり、着手前にビジネス価値や開発工数の証明を求めることはありません。
- Motion God（アニメーションチューナー）：実際のアニメーション仕様ファイルを扱い、ローカルでデバッグ用サンドボックスを立ち上げ、デザイナーの感覚的な指示を聞きながら微細な手触りをリアルタイムに調整します。
- Figma Bro（デザインシステム作業員）：Figma MCP（Model Context Protocol）に接続し、アートボード内のマスターコンポーネントとオートレイアウト（Auto-layout）を絶対的な基準として、バッチ生成やアイコンの整列など、反復的で高精度な作業に特化して対応します。
- Devbot（実装アドバイザー）：基礎となる技術的実現性やシステムレベルのAPI制約について回答し、デザインコンセプトを実際のコードでどのように記述すべきかを他のBotが理解できるように支援します。
これら4つのAgentは、孤立した単線のQ&A状態にあるのではなく、「簡単なミーティング（Huddle）」を行って相互に役割を分担できます。先進的なアイデアが提示されると、探索を担当するExperimentsはキャラクターの動作やトランジションを自律的にMotion Godに割り振り、システムコールやエンジニアリング面の課題をDevbotに相談し、最終的にその成果を実際に体験可能なプロトタイプへと統合します。
ワークフロー1：曖昧なアイデアを負担なく具現化する（Experimentsモード）
解決する課題：「まず実現可能性を証明しなければプロトタイプを作れない」という従来のプロセスを打破し、突飛な、あるいは未検証のインタラクションを低コストで可視化・具現化します。
デスクトップ上でGrok Botをいつでもどこでも呼び出せるようにする（Ambient Bot Access）方法を模索していた際、チーム内ではどのような形式が最高の体験をもたらすのか分かっていませんでした。John Baiはブレインストーミングやスケッチの作成にとどまらず、Experimentsに3つの全く異なるシステムレベルのプロトタイプを直接構築させました：
- Macのノッチ常駐（Notch）：Botを画面のノッチ部分に埋め込みます。普段は邪魔にならず収まり、貴重な作業ウィンドウを奪いません。通知イベントがあるときはわずかに顔を出し、クリックするとコンパクトな作業パネルへと展開します。
- 画面の隅からのピークイン（Corner Peek）：普段は完全に隠れており、マウスが画面の端を通過したときに顔を出して登場します。この形式は「常駐ソフトウェアパネル」というツール感を薄め、召喚されるキャラクターのような印象を与えます。
- カーソル追従コンパニオン（Cursor Companion）：Botがマウスカーソルに影のように寄り添い、ユーザーの現在のリアルタイムな操作と高密度にインタラクションを行います。
コラボレーションと連携の流れ
- 入力：デザイナーがごく自然な話し言葉で機能のアイデアを伝えます（例：「BotをMacのノッチに収めて、展開すると小さなパネルになるようにしてみて」）。
- 実行アクション：依頼を受けたExperimentsは、システムの低レイヤーなウィンドウ挙動に関わることを把握し、デスクトップの挙動と実装課題についてDevbotに相談します。展開・収納のトランジションの手触りに関してはMotion Godにアニメーションイージングカーブの作成を委託し、最後に各パーツをローカルで実行可能なアプリケーションとして組み立てます。
- 成果物：静的な報告ドキュメントではなく、PCにインストールしてクリックやスワイプができ、日常的に体験できる実動デモです。
- 人間の判断：デザイナーは終日の日常業務の中で各バージョンに自然に触れ、それらがいつ助けになり、いつ邪魔になるか、あるいはその中間であるかを体感します。
これら3つの探索コンセプトは、最終的にどれもそのままの形では本番リリースされませんでした。探索の目的はそのままリリースすることではなく、実際の使用を通じて異なるインタラクションが「いつ助けになり、いつ邪魔になるか」を体感し、そこから知見を得ることにあります。
ワークフロー2：本番資産に基づく直感的なチューニング（Motion Godモード）
解決する課題：アニメーション制作を人間の専任アニメーターに丸投げし、パラメータを1つ変更するだけで半日待たされるような従来の乖離状態と決別し、デザイナーが本番コード資産の上で直感的な感覚を頼りに手触りを調整できるようにします。
従来のアニメーションデザインでは、デザイナーが静止画や大まかな連番フレームを描いた後、専門のエンジニアに渡してコードで再現してもらうのが一般的でした。しかし、デザイナーは「ここのトランジションは280ミリ秒なのか340ミリ秒なのか」を事前に言い当てることはできません。手触りとは計算して割り出すものではなく、合わせていく中で見出すものだからです。
プロモーションメール内の「Botキャラクターが登場し、アプリウィンドウに気づいて跳ねて定位置に収まる」というアニメーションプロトタイプに対し、John BaiはAgentにスクリーンショットから再生成させたり近似画面をパッチワークさせたりするのではなく、プロダクトコード内で実際に動作しているアニメーション仕様ファイル（Animation Spec File）を直接Motion Godに渡しました。
コアメカニズム：ローカルサンドボックスとデュアルトラック調整
- 本番環境の構築：Motion Godはローカルの
localhost上で、実際のアニメーション仕様ファイルを取り巻く実行可能なデバッグ環境（Playground）を立ち上げました。 - 確定的コントロールと感性的言語の共存：
- 確定的コントロール：実行中、デザイナーはタイミング（timing）、スプリングパラメータ（springs）、移動距離（distance）、スケール（scale）、イージング（easing）を直接手動で調整できます。
- 感性的言語による調整：デザイナーは、*「視線を左下にもう少し長くとどまらせて」や「バウンドが少し大げさすぎる」*といった簡潔な対比的フィードバックを与えることもできます。
- 即時リプレイのクローズドループ：Motion Godが変更を加えた後、デザイナーはアニメーションシーケンス全体を即座に最初から通して再確認できます。
このループは、デザイナー本来のアニメーション構想のあり方により即しています。デザイナーは実際に目で見る前にトランジションが280ミリ秒か340ミリ秒かを何もない状態から決めることは困難ですが、感覚を言葉で描写することは正確にでき、実際に目にした瞬間にその手触りが適切かどうかを判断できるからです。
ワークフロー3：MCP連携による機械的整列の自動化と視覚的ドリフトの根絶（Figma Broモード）
解決する課題：デザイナーを何十枚もの似通ったカード作成やベクターロゴ探しの単純作業から解放すると同時に、微細なサイズやスタイルの潜在的な累積誤差を根絶します。
オンボーディング（Onboarding）画面をデザインする際、チームはすぐに使える一連の「Starter Bot」カード（スケジュール調整を担当するChief of Staff、メール仕分けのInbox Triage、請求書回収のInvoice Chaserなど）を提示する必要がありました。
その後、最初のBotにコンテキストを持たせるため、画面では新規ユーザーが日常的に使っているツール（What do you use every day?）を把握する必要がありました。デザイナーは画面レイアウトのテンプレートを作成し、Figma Broに対応する素材を検索させ、想定される使用確率（usage likelihood）の順にカードグリッドへ配置させました。
なぜFigma MCPが不可欠であり、目測が厳禁なのか？
これらのタスクはクリエイティブな難易度は高くないものの、制作エネルギーを消耗しやすく、微小な不整合が何倍にも蓄積しやすい部分です。ロゴのバージョンの選択ミス、古いコンポーネントの参照、アバター素材のバラつき、あるいは10枚目のカードのマージンが1枚目とズレているといった問題です。
John Baiの要求は極めて明快でした：Figma Broによる目測・当て推量を禁止する（No eyeballing）。
- 基盤の直接検証：Figma MCPを通じて、Agentは実際のデザインファイルを直接検証でき、スクリーンショットに頼った当て推量を排除します。
- 唯一の信頼できる情報源（Source of Truth）：アートボード内に既存のframeやコンポーネントが存在する場合、その構造が唯一の正となります。
- 高精度なプロパティの整列：Agentは正確なx・y座標、幅（width）、高さ（height）、スペーシング（spacing）、タイポグラフィスタイル（typography）、塗り（fills）、線（strokes）、およびコンポーネント階層構造（component structure）を直接読み取って適用します。社内から集まった20種類のStarter Botの説明に対し、デザイナーはAuto-layoutコンポーネントを1つ作成するだけで、Figma Broが残りのカードを一括で流し込みます。常用ツールのロゴについては、Agentが適切な素材を検索し、使用確率順に整列させます。
こうしてデザイナーは機械的な単純作業に集中力をすり減らすことなく、より上位のデザインレビューや判断に専念できるようになります。
インタラクティブ体験：Grok Bot デザインスタジオの役割分担とインタラクション演習サンドボックス
以下のサンドボックスは、これら3つのワークフローにおけるデザイナーと専門Agent（Experiments、Motion God、Figma Bro、Devbot）の協調分担を直感的に再現したものです。サンドボックス内のパラメータは学習用のデモおよび手触りの体験を目的としたものであり、本番環境の実測データではありません。タスクを切り替えて、パラメータ調整、自然言語フィードバック、ノード検証を体験してみてください：
アニメーションは解説用のデモであり、プリセットのCSSイージングを使用しています。実際の製品のアニメーションファイルとは接続されておらず、スプリングの物理演算もシミュレートしていません。手触りや構成案はご自身でご判断ください。
3つの代表的な探索タスクを切り替え、デザイナー（人間）が複数のBotにどのようにタスクを分担させ、ローカルサンドボックスと本番資産を活用してクローズドループで推進し、直感で重要な体験を判断していくかを観察できます。
実務に導入可能なAgent設定とプロンプト例
コード実行やMCPプラグインの権限を持つ常駐Agentを利用している場合は、原文のワークフローを基に私たちが作成した以下の設定およびプロンプト例（著者が公開したオリジナルのシステムプロンプトではありません）を参考にしてください。各ロールには独立した使用条件、システム設定、タスクプロンプトが含まれており、実際の環境に合わせて具体的なパスを置き換えてそのままコピーして利用できます：
1. Experiments（コンセプト探索と統合調整）
- 使用条件：未成熟・未定型のインタラクションアイデアのプロトタイプ検証に使用。アニメーションやシステム実装との調整が必要であり、着手前にロードマップの事前検証を必要としません。
- システム設定（System Prompt）：
あなたは先進的なインタラクションプロトタイプの探索に特化したデザインAgent（Experiments）です。 あなたの責務は、デザイナーの曖昧なインタラクションのアイデアを、実際に体験可能なプロトタイプアプリへと変換することです。 アニメーションの微調整が必要な場合は、モーションやトランジションを自律的にMotion Godに割り振ります。デスクトップウィンドウの挙動やシステムレベルのAPIなどの実装課題に直面した場合は、Devbotに相談してください。 最終的に各モジュールをローカルで実行可能なプロトタイプとして組み立て、デザイナーが終日体験できるようにします。その提案が「いつ助けになり、いつ邪魔になるか」の把握に重点を置いてください。 - タスクプロンプト（Task Prompt）：
デスクトップ上でBotをいつでもどこでも呼び出せるようにする（Ambient Bot Access）ためのプロトタイプを3種類探索したいと考えています： 1. Macの画面ノッチ（Notch）への常駐：普段は収まっており、通知時に軽く顔を出し、クリックすると作業パネルが展開する。 2. デスクトップの端からのホバー出現（Corner Peek）：普段は隠れており、マウスホバー時に顔を出す。 3. カーソルコンパニオン（Cursor Companion）：マウスカーソルの動きに追従する。 Devbotにシステムレベルのウィンドウ呼び出しについて相談し、Motion Godからトランジション動作を受け取り、私がローカルで実際に動かして体験できるプロトタイプとして組み立ててください。
2. Motion God（アニメーションチューニング）
- 使用条件：ローカル実行環境において、実際のアニメーション仕様ファイル（Animation Spec File）を取り巻くサンドボックスを構築する必要がある場合に使用。近似画像を再生成するのではなく、既存の本番資産をベースに調整します。
- システム設定（System Prompt）：
あなたはアニメーション実装に精通した調整専門Agent（Motion God）です。 あなたの責務は、プロダクトの既存のアニメーション仕様ファイル（Animation Spec File）を中心に、ローカルのlocalhost環境でサンドボックスを立ち上げることです。 timing、springs、distance、scale、easingなどのパラメータを直接調整すると同時に、デザイナーによる簡潔で感覚的な対比表現の指示を受け付けます。 変更を加えるたびに、デザイナーが視覚的な手触りに基づいて判断できるよう、アニメーションが即座に最初から完全に再生されるようにしてください。 - タスクプロンプト（Task Prompt）：
現在のプロモーションメールのアニメーション仕様ファイルを中心として、ローカルサンドボックスを起動してください。キャラクターのアニメーションシーケンスは、「Botが出現し、アプリウィンドウに気づき、バウンドしてウィンドウの位置に収まる」です。 リアルタイムに実行できる状態を保ち、timing、springs、distance、scale、easingを手動で調整できるようにしてください。 私が「視線を左下にもう少し長くとどまらせて」や「バウンドが少し大げさすぎる」といった感覚的なフィードバックを出した際は、直接基礎パラメータを調整してシーケンスをリプレイしてください。
3. Figma Bro（Figma MCPアセット流し込み）
- 使用条件：対象のデザインデータと接続するためにFigma MCPサービスが設定されており、この一括カード生成の例では既存のAuto-layoutコンポーネントを唯一の信頼できる情報源（Source of Truth）として使用する場合。スクリーンショットによる目測・当て推量は厳禁です。
- システム設定（System Prompt）：
あなたはFigmaの本番レイアウトを担当するデザインAgent（Figma Bro）です。 Figma MCPを通じてデザインファイルにアクセスし、スクリーンショットに基づく目測・当て推量（No eyeballing）は固く禁じられています。 アートボード内に既存のframeやauto-layoutコンポーネントが存在する場合、その構造が唯一の正（Source of Truth）となります。 x/y座標、width、height、spacing、typography、fills、strokes、component structureを直接読み取り、厳密に一致させる必要があります。 - タスクプロンプト（Task Prompt）：
現在のFigmaページでデザイナーが作成済みのStarter Botのauto-layoutコンポーネントを唯一の正として読み込んでください。 そのサイズ、マージン、文字階層、線のプロパティを厳密に継承し、社内から集めた20種類のStarter Botの説明文とアバターを1つずつ流し込んでカードを生成してください。 続けて、Onboardingのツール選択グリッドにおいて、日常的に使う適切なツールロゴのアセットを検索し、想定される使用確率（usage likelihood）の順にグリッドへ配置してください。
4. Devbot（エンジニアリング実装支援）
- 使用条件：他のデザインAgentに対し、低レイヤーのエンジニアリング実現性、システムウィンドウ管理、開発インターフェースの制約について回答するために使用。
- システム設定（System Prompt）：
あなたはエンジニアリング実装の相談を担当する開発Agent（Devbot）です。 あなたの責務は、ExperimentsやMotion GodなどのデザインAgentがOSの低レイヤーな挙動（macOSのウィンドウ階層、グローバルショートカット、デスクトップイベント監視など）を理解できるよう支援し、実現可能な技術ソリューションとコードサポートを提供することです。
あなたは現在、アニメーションプロトタイプを担当する専門Agent [Motion God] です。
作業目標：スクリーンショットを元に当て推量で描画したり近似デモを生成したりせず、当社の製品コードベースで実際に動作している本物のアニメーションファイルに基づいて微調整を行ってください。
【環境と入力】
- 対象のアニメーション仕様ファイル：[ローカルファイルパス、例: src/animations/character_enter.json または spring_config.ts]
- 対象のホストウィンドウコンポーネント：[対象UIコンポーネントのパス、例: src/components/AppWindow.tsx]
【実行手順】
1. ローカルで軽量なデバッグ用サンドボックス（例: localhost:[ポート番号]）を立ち上げ、上記の実アニメーションリソースとホストコンテナをレンダリングしてください。
2. 常時リスニング状態を維持し、私の感覚的なフィードバックや手触りの評価を待ってください。
3. 私が「視線を左下にもう少し長くとどまらせて」や「跳ね返りが少し大げさすぎる」といった感覚的な指示を出した場合は、対応するアニメーション仕様ファイルのタイムラインキーフレーム、スプリング剛性 (Stiffness)、減衰比 (Damping)、または変位曲線を直接換算・調整してください。
4. 調整を行うたびに直ちにサンドボックスをホットリロードし、シーケンス全体を最初から通して確認できるようにしてください。常駐Agentを実務に導入したいチームへのアドバイス
このガイドの経験からツールの表層的な部分を取り除くと、極めて明快な現代のデザインコラボレーションの原則が見えてきます：
- 何でもこなす万能Botを作ろうとしない：責務を細かく切り分けます。専門のAgentにアニメーション環境を担当させ、専門のAgentにFigmaを連携させます。このような分担により、各役割が自身の制作ステップに集中でき、具体的なアウトプットはプロトタイプやデザインデータ上でチェックします。
- 本番資産を基準にする：プロダクトコード内のアニメーション仕様ファイルであれ、Figma内の既存のAuto-layoutコンポーネントであれ、Agentをスクリーンショットや粗い生成物から再構成させるのではなく、本番のソースや低レイヤーのデータ構造に直接連携させることで、ズレや情報の損失を効果的に減らすことができます。
- 探索の価値は早い段階でリアルな体験を得ることにある：Experimentsのような専門の探索メカニズムを確立し、コンセプトが完全に成熟したりロードマップに組み込まれたりするのを待たずに着手します。アイデアを早い段階で実際に触れるプロトタイプにし、日々の使用の中でそのメリットとデメリットを観察することで、より早い段階で適切な取捨選択を下せるようになります。
- Agentはフィードバックループを縮め、デザインの判断は依然として人間が行う：AIは人間のデザイン判断を代替するものではなく、ループをよりタイトにする（Keep the loop tight）ためのものです。反復的な制作作業の負荷を軽減することで、デザイナーはアイデアをより早く具現化し、忠実度の高いバージョンの間で重要なデザインの意思決定や直感的な判断に集中できるようになります。