Figma MCP × Claude Code で座標変換職人のサブエージェントを育てた話

はじめに

🐺です！ネオス株式会社でエンジニアをしています。

開発の現場では「デザインからコードへの実装」はよくある工程の一つですよね。デザインツール上の座標やサイズを確認し、コードに書き起こす
── 地味だけれど避けて通れない作業です。

今回は 🐺 が参画しているプロジェクトにてこの作業を「Figma MCP × Claude Code サブエージェント」を構築して効率化した体験記を紹介します。この記事は以下のような方におすすめです。

• Claude Code サブエージェントの実装・活用事例を知りたい方

• Figma MCP を使った自動化に興味がある方

• Phaser を使った開発で、Figma データの実装に苦労している方

ぜひ最後までご覧ください。

🥚 困っていたこと

このプロジェクトは React ベースの UI と Phaser ゲームエンジンの統合を組み合わせた構成になっています。

問題は、そのデザインからコードへの橋渡しでした。

例えば、次のような Figma 上のキャラクター（狼男 🐺）を実装する場合、
コードではこんな変換処理を行っていました。

addWolf({
  rect: {
    x: pt(translateToGrid(this, 64.23)), // 中心X座標
    y: pt(312.71), // 中心Y座標
    width: pt(85),
    height: pt(91),
  },
  angle: -10, // FigmaとPhaserで正方向が逆🥲
  texture: "wolfman",
});

このようにデザインを、Phaser 側で再現するためには、Figma の情報を読み取り、コードに座標・角度・サイズを指定して配置していく必要があります。しかも Figma と Phaser では座標の基準が異なるのでその補正も必要となります。

そんな細かな作業を各アセットで行っているので、もし

なんて言われた日には涙を禁じえません。

そんな折、弊社で AI コーディングツールであるClaude Codeが導入されました。

という発想から、この挑戦がスタートしたのです。

🐣 とりあえず動かしてみる

まず、Claude Code の導入と Figma MCP サーバーへの接続から始めました。IDE は VS Code を使用しているので拡張機能経由で Claude Code を起動させます。
セットアップの詳細については公式ドキュメントを参照しました。

続いて Figma MCP サーバーの追加です。
MCP については以前にも記事に取り上げているのでぜひご覧ください。こちらも導入は公式ドキュメント通りです。

Figma MCP サーバーを簡単に説明すると、実装したいデザインの情報（node ID）を AI に渡すと、MCP サーバーを経由してプログラミングに適した形式（例：Tailwind CSS）で取得できる仕組みです。

環境構築ができたのでさっそく先ほどのデザインで動かしてみることに

addWolf({
  rect: {
    x: pt(translateToGrid(this, 57.5)), // 中心座標に変換しようとしたが計算ミス🥲
    y: pt(260), // そもそも補正できず🥲
    width: pt(85), // OK
    height: pt(91), // OK
  },
  angle: 350, // 符号は補正してくれていい感じ！
  texture: "wolfman",
});

おしい、、、、
MCP から取得した CSS データをもとに入力しているので回転角度の補正はできていますが、座標は中途半端な補正になってしまっています。

何度か試してみたところ

• 複数のアセットを依頼すると回転角度を入れ忘れる。

• Figma 座標(左上基準)と Phaser 座標(中心基準)の変換が抜ける。

のように動作が安定しません。

一番の問題は、毎回「それっぽい」数字を出して、こちらの期待を巧みに煽ってきます。
デバッグ中は「逆に回ってる！」「お、今度こそ来たか!?」と勝手に感情を揺らされ、心のスタミナが削られます。これはいけません。

Claude Code:

どうやら確信して翻弄させていたようです。

🐤 プロンプトを調整してみる

このままでは心も、トークンもいくらあっても足りません。そこで再現性のある動作をさせるためプロンプトエンジニアリングを試みました。

実装に必要な情報を列挙して Claude Code に認識させます。MCP サーバーから受け取るのは Tailwind CSS 形式なので、今まで手動で行っていた計算方法に加え CSS から読み取る方法も伝えます。

• Phaser は中心基準なので中心座標を求めてから入力すること

• 回転している場合、left 値や top 値はバウンディングボックスの数値であること

• `translate-x-[-50%]`がある場合 left 値を中心座標として使えること

• etc

もっとも頭を悩ませたのは手順を事細かに指定することと、Claude Code 自身に柔軟に対応してもらう余白を残すことのバランスです。

たとえば、left 値 + サイズ* 0.5 =中心 X 座標と指示してしまうと`translate-x-[-50%]`が適用されていた場合に中心座標がずれてしまいます。Claude Code 自身が`translate-x-[-50%]`に気づいてサイズ* 0.5 を適用するか判断していたこともあったので、いかにこういった分岐点に気づかせて判断させるかがポイントだったと思います。

こうして出来上がったプロンプト🐤を活用することで、比較的、安定した実装が可能になりました！
計算が漏れていても指摘すれば修正してくれます。

もう🐺のやることは Figma アプリ上で実装したい画面を選択しプロンプトを渡すだけです。ちょっとエンジニアの存在意義を考え直したくなるくらいには便利です。

🐥 座標変換職人みならい？

やっと安定した動きをするようになりましたが、毎回プロンプトを与えるのは面倒です。また、このプロジェクトはチーム開発なので、プロンプトがブラックボックス化してはいけません。

そこで、最小の実装でチームがこのプロンプトを使える方法を模索しました。

まず、思い浮かぶはCLAUDE.mdにプロンプトをまるごと記載することです。しかし違うタスクのセッションにて、このプロンプトを読み込んで、意図しない動作（プロンプトインジェクション）をしてしまう懸念がありました。

そこで目を付けたのが サブエージェント です。

簡単にサブエージェントとは、特定のタスク処理に特化した AI アシスタントを指すようです。

さらにセットアップも複雑な実装を必要としません。コマンド１つでマークダウン定義による独立したエージェントを作れるとのこと。

導入は Anthropic の公式サイトを参考にしました。

/agents コマンドで作られるマークダウンに先ほどのプロンプトを記述し、いざ実行

よみがえる、翻弄されるあの感じ、、、、、
どうやら、情報をただ列挙するだけでは動作が安定しないようです。

「えっ、こんなに丁寧に書いたのに!?」と軽いショックを受けました。

どうやらサブエージェントさん🐥は指示を全部読んでいるようで、処理途中で忘れてしまうことがあるようです。

実際、完成したプロンプトでも一部の処理をすっと抜け落とすことがありました。

さらに困ったことに、サブエージェントの場合は細かなログがほとんど表示されません。出力されるのは結果のコードだけ。

結局その裏側を確かめるために、確認の手間がじわじわと増えてしまいました。

🐔そして座標変換職人へ

忘れん坊サブエージェントさんのために🐥ネット記事や公式ドキュメントを参考にマークダウンの作りこみをしました。

特に有用だったのは公式の以下の記述です。

要約しますと
1つのサブエージェントにすべてを実行させるのではなく、明確な役割を持たせることによりパフォーマンスと再現性が高まりますよ。プロンプトには、具体的な指示、例、制約、手順を含めるほど、サブエージェントのパフォーマンスは向上しますよ。
という内容です。

それらをもとに重視したのは以下のポイントです。

• 責務（何を目的とするサブエージェントなのか）を明記する

• 具体的な手順（例：Step １～ Step 〇）を書く

• チェックリストを設けて、自己検証を促す

以下がそのマークダウンです。長いので各項目の冒頭のみ記載しています。

完全に本プロジェクトに特化した「座標変換職人🐔」が完成しました。CSS の数値もコメント追記させるようにしたので人間による計算のチェックもやりやすいです。

そんな折に、デザインチームから連絡が

そう、いまの🐺には座標変換職人🐔がついています。
デザイン変更のたび狼狽えていた🐺はもういません。

実装よし！動作もよし！こんなすがすがしい PR を出したのは初めてでした。

🦅 職人、いい仕事してます

今回構築した「座標変換職人🐔」による効果を試算してみましょう。

これまで１枚のアセットに対して 3 分ほどかけて座標計算していたのが、いまは１画面まとめて３分ほどになりました。

このプロジェクトでは 32 枚のアセットに座標計算が必要なので 1.6 時間かかる計算だったところが、今はチェックと確認で 10 分程度に短縮できました。

その間に他のタスクを進められるので、実質 1.5 時間分の自分の時間が浮いた体感です。

Claude Code の API コストはサブエージェント 1 回あたり 0.3 ドルくらいでした。

育成に 3 人日（24 時間）かかりましたが、同じ規模の仕事を 16 回くらいこなせば元が取れる計算になります。

サブエージェントを動かすようになって気づいたのは、「AI が作業してる間に自分は別のことができる」という恩恵の大きさです。

🐺 は Backlog で他のメンバーの PR を確認したり、次に手を付けたい箇所の勉強に充てたりしています。これがあるだけで次のタスクの快適度が体感でかなり違うので、数値化できない利便性があるなと感じました。

 🐓 まとめ

ここまで読んでいただき、ありがとうございました。

Figma MCP やサブエージェント活用のヒントになっていれば幸いです。

今後もこの仕組みの活用範囲をさらに広げていきたいと考えています。
たとえば「カスタムコマンド化したらどうなるだろう？」など、まだまだ試してみたいアイデアが尽きません。

今回はサブエージェントを「座標変換職人 🐔」と比喩しましたが、
本当に自然言語で指示（プロンプト）を与えて動きを見守る過程は、まるで教育をしているような体験でした。

こうした感覚こそ、AI 時代のエンジニアリングに必要なのかもしれませんね。

弊社では、このような技術を活用した開発を積極的に進めています。
もしご興味をお持ちいただけましたら、ぜひ採用ページをご覧ください。

次の「🐣」が生まれる瞬間を、🐺は楽しみにしています。