🎨

VibeCodingで複雑なオブジェクトを扱うようなFigmaプラグインを作成したときの学び

に公開

どんな物を製作したか

もともとはMCPサーバを使ってFigmaの情報を参照したり、Variablesの情報を実際のコードと同期したいという欲望を抱いて制作しました。
FigmaのREST APIはVaribalesの操作がEnterpriseプラン以上じゃないと使用できず、さすがにちょっと手が出る金額ではなかったので別のアプローチを検討。Plugin APIのVariablesでは、変数の削除やモードの作成などが無いという状況 ではあるのですが、 Plugin APIを使用することで、まずは変数を管理できる機能を用意してそこから発展させる計画を考えました。

追記:申し訳ありません、変数の削除やモードの作成がないというのは誤りでした。hiroki TaniさんがXでご連絡くださった内容を掲載させていただきます。
https://x.com/hiloki/status/1926543849935056969

あと、Figmaのプラグイン管理ではダブルクリックしないと変数の名前を変えられないとか、手動では並び替えられるが自動ソートがないなどのちょっとした不便を感じるところもあり、ついでにそれらもなんとかできるような管理ツールを作りました。
https://x.com/ampersand_xyz/status/1926475387678187961

VibeCordingでの開発

今回制作した成果物はほぼほぼcursorによるVibeCodingで作成しました。
関数などをAIに作成させることはよくありますが、AIによるCodingでほぼ全てを対応したことはなかったのでそこから得られた自分なりの発見を書いておこうと思います。すでに似たような記事はたくさんあり目新しい発見はないかもしれませんが、誰かの学びの一助になれば幸いです。

AIは環境構築があんまり得意ではない

環境構築は正直かなりAIでの作業に躓いた、というか私自身も環境構築は苦手な部分だったので苦戦しました。
今回はFigmaのプラグインをVue.js+tailwindで開発しました。Figmaのプラグインを開発するためのテンプレートは公式から公開されているものがあるのですが、情報が少し古くなっているのと、Vueのテンプレートは今のところ存在していません。
https://github.com/figma/plugin-samples

WebpackでReactを使って開発するためのテンプレートがあるので、それに倣った形でVueの環境を構築できないかということでClaude3.7に情報元として渡して作業を指示してみたものの、Figmaプラグイン特有の制限(プラグインのファイルは分割せずすべてpageとなるhtmlに1ファイルとして出力するようにしないといけないなど)の制限情報の前提がうまく認識できず、普遍的な形の環境構築をしようとしてずっと失敗し続けたり破壊的な変更をトライアンドエラーするようになるなど散々でした。

環境構築のタスクは結局人間がすべて手作業で解決をするほうが早く確実でした
https://github.com/maiko-ando/figma-vue-plugin-boilerplate

指示は細かく・コミットはマメに行う

VibeCordingで複雑なオブジェクト操作を行う場合、当然指示1発でうまくいかないことが多いです。
タスクAがあるとしてサブタスクB、Cに分解できる場合について、タスクAの指示を行うとサブタスクBは成功するがCは不具合が起こってバグDも発生する、みたいなことが頻発します。

まず、タスクを分解し、プロンプトにサブタスクB,サブタスクCについて明示的に記載するか、サブタスク単位で対応させてうまく行ったらコミットする、という形で漸進をする進め方が良いなと思いました。
また、このタスク分解をうまく行えるかどうかはそれこそ業務としてエンジニアをやってきたことがあるかという経験もある程度は物を言うのかもしれません。

VibeCordingだからこそリファクタリングを常に行う

1ファイルにバリバリと追記していくAIのパワーに任せてバリバリと進んでしまうことはできますが、おそらく後々取り返しがつかなくなると感じました。これは早めというかまず最初に土台を設計し、そこからは常に行うのが良いというか、基本的にはReactやVueを使ってお作法にちゃんと準拠していれば問題はないかと思います。

これは明確にリファクタリング方針を指示する必要があり、どのようにリファクタリングされるべきかを人間も目標地点を定めてハンドルを握って行う必要があると思いました。

また、AIは型定義などをコンポーネント内とかその場で定義しがちな動きが見られたので、ある程度の作業を行った段階で型について整頓させるのが良かったです。

”課題の解決方法”はAIもかなり頑張ってくれるが、人間が主体になり考える方が良い

ある部分のパフォーマンスが良くないという問題があったとして、パフォーマンスを改善するためにロジックを見直すのか、それとも仕様自体を見直すのかという話があったとします。

こういった課題ケースについて、AIは仕様自体を見直すような提案は行ってくれませんでした。
ロジックの見直しに固執したり、的はずれな改善(のようなもの)を繰り返すケースも見られたので、人間が問題を分析し、どう解決されるべきであるのかを認識して検討する必要があると思います。

まとめ

AIへのダメ出しみたいな内容が多くなってしまいましたが、CorsorとClaude3.7(現在は4.0)がなければ、Figmaの複雑なVariablesの取り扱いが嫌になって作業を投げてしまっていたと思います。
AIによって圧倒的に人類の作業効率は進歩しました、私も失職カウントダウンなのかもしれません。

今回なぜある程度ちゃんとできたのか

前段の話を覆し気味になりますが、今回の作業が自分としてはある程度うまく行ったのは Figmaプラグイン という枠組みがある環境での作業だったことや tailwindcssを採用するという、0から完全フルスクラッチというよりは 0.3ぐらい色々決まってるラインからスタートし、見た目にもあまりこだわらなかった、というところが大きそうです。

独自のUIやデザインシステムを使いたいようなケースでも以前VibeCodingを試したことがありましたが、そのさいは全然いい進捗を生むことができませんでした。
しかし、自分のAICoding経験値の低さもあったかなともおもうので、今度は別の土壌で試してみようと思います。

Discussion