こんにちは。新卒UIデザイナーの河野です。今回は、私がFigmaプラグインの開発に挑戦した体験談をお話しします。結論から言うと、完全な成功とは言えませんが、たくさんの学びがありました。プラグイン開発の経験がないデザイナーが、どのような壁にぶつかり、それをどう乗り越えようとしたのか。技術的な課題から、AIとの対話の仕方、チーム内での相談のタイミングまで、実体験を通じて得られた気づきを詳しく紹介します。完璧にできなくても、挑戦してみることに大きな意味があることを実感できた貴重な経験でした。同じようにデザイナーでありながら技術的な挑戦をしてみたい方の参考になれば嬉しいです。業務効率化への想いがプラグイン開発の出発点UIワークフローの長期化という課題デザインチームでは、UIスケッチからワイヤー作成、実装連携までのループが長期化していました。もっと効率化できないかと常々思っていました。特に気になっていたのは、Rera, Inc.によって開発された「Layermate」というプラグインでした。テキストプロンプトからUIを自動生成してくれる便利なツールなのですが、生成したデータがモデル学習に使われてしまう可能性があり、社内の機密情報を扱うには不安がありました。（参照元：https://www.layermate.ai/privacy）そこで、「それなら、学習に使われない安全なプラグインを自分で作ってみよう」そんな軽い気持ちで、このプロジェクトは始まりました。甘い見通しと現実のギャッププラグイン開発の経験がなかったため、「AIの力を使えばプラグインは作れるんじゃないか」という甘い考えでスタートしました。まず、Figmaのプラグイン開発について調べてみると、JavaScriptやTypeScriptが必要だということが分かりました。幸い、Web制作で少しJavaScriptに触れた経験があったので、「これならなんとかなるかも」と思いました。しかし現実は厳しく、最初の数日間はプラグインを起動させることすらできませんでした。manifest.jsonの書き方が分からない、TypeScriptのコンパイルでエラーが出る、Figma上でプラグインを読み込んでも真っ白な画面しか表示されない。「一体何から手をつければいいんだろう...」と途方に暮れる時間を過ごしました。公式テンプレートという救世主との出会いドキュメントの再読で発見した転機行き詰まって数日後、Figma公式のプラグインドキュメントをもう一度じっくり読み直してみました。すると、「Plugin Quickstart Guide」（https://www.figma.com/plugin-docs/plugin-quickstart-guide/）というページで、公式のテンプレートから始める方法が紹介されていたのです。「New plugin created!」ダイアログから基本的なプラグイン構造を作成し、それをベースにカスタマイズする方法を知りました。この発見が大きな転機でした。ゼロから作ろうとするのではなく、既存のリソースを活用することの大切さを痛感しました。公式テンプレートのおかげで、ようやくプラグインが起動するようになったのです。学び１：既存のライブラリやリソースを最低限活用するべきこれが最初の重要な学びでした。技術的な挑戦において、車輪の再発明をする必要はありません。特に初心者であればなおさら、確実に動作する土台から始めることが成功への近道です。公式が提供するテンプレートやライブラリは、多くの開発者によってテストされた信頼性の高いものです。本格的な技術的課題との格闘CORS（クロスオリジンリクエスト）という難敵プラグインが起動するようになったものの、次は本格的な技術的課題が待っていました。AIとの連携にはClaude APIを使いたかったのですが、Figmaプラグインから直接APIを呼び出すとCORSエラーが発生してしまいます。これは、セキュリティ上の理由でブラウザが異なるドメイン間の通信を制限する仕組みです。デザイナーの私には「CORS」という概念すら初耳で、なぜエラーが出るのか理解するのに時間がかかりました。調べてみると、プロキシサーバーを作る必要があることが分かりました。つまり、FigmaとClaude APIの間に仲介役となるサーバーを置く必要があったのです。AWS Lambdaとの出会いと苦戦プロキシサーバーをどこで動かすか悩んでいたところ、AWS Lambdaという選択肢を知りました。サーバーを常時稼働させる必要がなく、リクエストがあった時だけ動くサーバーレス環境です。コスト効率が良く、今回のような用途には最適でした。ただ、AWSの設定も初心者には難しく、IAM権限の設定、Secret ManagerでのAPI Key管理、Lambda Function URLの設定など、これらの概念を理解するのに苦労しました。それぞれが独立した技術要素でありながら、相互に関連し合っているため、一つでも設定を間違えると全体が動作しないという複雑さがありました。タイムアウト問題との戦いなんとかプロキシサーバーが動くようになったものの、今度はタイムアウトの問題が発生しました。Lambdaには実行時間の制限があり、Claude APIからの応答が遅い場合にタイムアウトしてしまうのです。特に詳細なUIを生成しようとすると、応答に時間がかかってしまいます。// 2.5分でタイムアウト設定const timeoutId = setTimeout(() => controller.abort(), 150000);if (fetchError.name === 'AbortError') { console.error('Request timeout after 2.5 minutes'); return createErrorResponse(408, 'Claude API request took too long');}この問題に対して、フォールバック機能を実装しました。API呼び出しに失敗した場合は、事前に用意したモックデータを表示する仕組みです。try { // Claude API呼び出し const response = await callClaudeAPI(prompt); return response;} catch (error) { console.warn('API failed, using mock data:', error); // モックデータで代替 return getPromptBasedMockData(prompt);}完璧な解決策ではありませんが、ユーザー体験を維持するための現実的なアプローチでした。学び２：完璧を目指さず、エラー時の代替案を用意しておくこの経験から、プロダクト開発においてエラーハンドリングがいかに重要かを理解しました。理想的な動作を目指すのは当然ですが、現実には様々な問題が発生します。そのときに「何も表示されない」「完全に止まってしまう」という状況を避けるための代替案を用意しておくことが、実用的なプロダクトを作る上で欠かせません。現在の成果と今後への展望不完全でも価値のある現状数日の試行錯誤の結果、現在のプラグインは以下のような状態になっています。プラグインの起動・UI表示は正常に動作し、プロンプト入力からAPI呼び出しまでの処理は実装済みです。ただし、ReadableStream not supportedエラーが発生するため、エラー時はモックデータを表示しています。完全に期待通りの動作ではありませんが、フォールバック機能により「何も表示されない」という最悪の状況は避けられています。開発過程で得られた予想外の学びAIとの対話の仕方という新たなスキル開発中は、ChatGPTやClaudeに多くの質問をしました。最初は一つのチャットで延々と会話を続けていましたが、これがあまり効果的ではないことに気づきました。むしろ、問題を整理して新しいチャットで質問したり、前回の回答を引用して根拠を明確にしたりする方が、適切な回答を得られることが多かったです。AIツールは確かに便利ですが、その能力を最大限引き出すためには、人間側にも相応のスキルが必要です。曖昧な質問では曖昧な回答しか得られず、具体的で構造化された質問をすることで、より実用的な回答を得ることができます。学び３：AIとの対話も技術。質問の仕方次第で回答の質が変わるこれは現代のデザイナーにとって重要なスキルだと感じます。AIツールがますます普及する中で、それらを効果的に活用できるかどうかは、業務効率や成果物の質に大きく影響します。単にツールを使うだけでなく、どう使うかが重要なのです。相談することの心理的障壁技術的に詰まった時、社内のエンジニアに相談することが最も効率的だと分かっていました。しかし、「忙しい中で時間を取ってもらうのは申し訳ない」という心理的な障壁がありました。結果的に、一人で悩む時間が長くなってしまったことは反省点です。もっと早めに相談していれば、効率的に問題解決できたかもしれません。チームワークとは技術的なスキルだけでなく、適切なタイミングで適切な人に声をかけるコミュニケーション能力も含まれるのだと実感しました。学び４：相談のタイミングと方法も重要なスキルこの学びは、技術的な分野に限らず、デザイン業務全般にも応用できます。一人で抱え込まずに、チーム全体の知識と経験を活用することで、より良い結果を効率的に達成できるのです。デザイナーとしての成長と新たな視点エンジニアとの協業における変化技術的な実装は完璧ではありませんでしたが、この経験を通じてエンジニアとの協業がスムーズになりました。技術的な制約を理解した上でのデザイン提案ができるようになり、APIやサーバーの概念を踏まえた要件定義も可能になりました。エラーハンドリングの重要性への理解も深まり、より現実的なデザイン判断ができるようになりました。デザイン業務への波及効果これらの知識は、日々のデザイン業務でも活かされています。ユーザビリティだけでなく、実装コストや保守性も考慮したデザイン判断ができるようになりました。また、プロトタイプ作成時にも、より技術的に実現可能な範囲での検証ができるようになり、開発段階での仕様変更が減りました。プロダクト全体を俯瞰する視点最も大きな変化は、デザインと技術の境界を意識することなく、プロダクト全体を俯瞰した提案ができるようになったことです。「ユーザーにとって良いもの」を作るという目標は変わりませんが、そこに至るまでのプロセスや制約をより深く理解できるようになりました。挑戦することの意味と価値完璧でなくても価値のある体験「完璧にできなくても、挑戦してみることに意味がある」これが、今回の開発体験で得た最も大切な気づきです。結果として動作するプラグインを完成させることはできませんでしたが、その過程で得られた学びと経験は、今後のキャリアにとって非常に価値のあるものでした。デザイナーとしてのスキルセットが広がっただけでなく、技術的な課題に対する取り組み方や、問題解決のアプローチも身につけることができました。また、自分の限界を知ると同時に、適切なサポートを得れば思っている以上のことができる可能性も感じました。そして何よりも、このような挑戦ができる環境が新卒にも用意されているというオープンなゆめみの姿勢に改めて感謝を感じました。同じ挑戦を考える方へのエールもし同じようにデザイナーでありながら技術的な挑戦を考えている方がいれば、ぜひ一歩踏み出してみてください。最初は困難に感じるかもしれませんが、現在は学習リソースも豊富で、AIツールのサポートも受けられます。失敗も含めて、きっと貴重な経験になるはずです。完璧を目指す必要はありません。むしろ、「できる範囲でやってみる」「わからないことは素直に質問する」「小さな成功を積み重ねる」という姿勢が重要です。技術的なスキルだけでなく、学習の仕方や問題解決のアプローチも同時に身につけることができます。おわりにデザイナーがプラグイン開発に挑戦することは、決して簡単ではありませんでした。しかし、この経験を通じて得られた学びは、デザイン業務だけでなく、チームでの協業においても大きな価値があったと感じています。技術的な知識だけでなく、学習方法や問題解決のアプローチ、チーム内でのコミュニケーション方法など、多面的な成長を実感できました。現在のプラグインはまだ改善の余地がありますが、それもまた今後の楽しみの一つです。技術は日々進歩しており、今回解決できなかった問題も、いずれは解決できるようになると考えています。この記事が、デザインと技術の境界を越えた挑戦をする方の背中を少しでも押せたら嬉しいです。最後まで読んでいただき、ありがとうございました。