本記事では、エンジニアがそれぞれに見つけてきた"AIとの付き合い方"をご紹介します。仕事に取り入れたツールやワークフローから、チームでの使いどころ、あえて自分の手でやると決めた場面まで。うまくいった工夫だけでなく、試して戻したことや思いがけない発見を通して、AIとの距離の取り方をのぞいていきます。AIをどう使うかだけでなく、どんな距離感で付き合っているのか。誰かのAIとの向き合い方が、あなたとAIのちょうどいい"さじ加減"の手がかりに。
こんにちは！スナガクです。普段はフロントエンドエンジニアとして、SaaSの開発に取り組んでいます。
AIエージェントを使うようになってから、実装の速度は上がりました。その一方で、細かな修正や目視でのデザイン確認、AIの出力チェックなどに苦戦している人も多いのではないでしょうか。
僕たちのチームでは、デザイナーがFigmaで画面をつくり、開発者が実装を担当しています。その実装をAIに任せてみたところ、文言やスタイルのミスが残り、結局、人が実装全体を確認し直す状態になっていました。
本記事では、この失敗の原因をどう切り分け、Figmaからの情報の取得方法や実装後の評価方法をどう見直したかを紹介します。あわせて、何を人が判断し、どこからAIに任せるのか、そこで得た知見をチームにどう広げたのかもお伝えします。
AIが思ったように動かず、手作業に戻した方や、任せる範囲の決め方に迷っている方の参考になれば嬉しいです。
FigmaのURLを渡せば、デザインどおりに実装してくれるはずだった
FigmaのURLを渡して「この画面を実装して」と伝えれば、AIがデザインを読み取り、細かな修正だけで使える状態になるだろうと思っていました。
ところが、実際には差分が残りました。原因を調べると、Figmaから情報を取得する段階と、実装後の結果を確認する段階の両方に問題がありました。
失敗その1：デザイン情報ではなく、スクリーンショットで実装していた
AIに実装してもらうと、ぱっと見ではそれらしい画面ができていました。ただ、細かく確認すると、文言や色、余白などにズレが残っています。
Figma MCPには、画面をスクリーンショットとして取得するTool（get_screenshot）と、レイアウトやスタイル、コンポーネントなどの詳細なデザイン情報を取得するTool（get_design_context）があります。僕は「Figmaを読んでUIを実装して」と伝えれば、get_design_contextで詳細なデザイン情報を取得したうえで実装するものだと思っていました。
ところが、実際にはスクリーンショットを取得する呼び出し方が使われていました。画像だけでは、文言や色、余白などのデータを十分に取得できず、一部をAIが推測しながら実装することになります。そのため、細かい部分で差分が発生し、人がそれを見つけて修正する必要がありました。
ここから学んだのは、「Figmaを読ませた」だけでは不十分で、どの方法で情報を取得しているのかまで確認する必要があったということです。
そこでFigma MCPの呼び出し方を見直しました。get_design_contextでレイアウトやスタイル、コンポーネントなどの情報を取得することをSkillに明記し、その内容をもとにUIの実装計画を作るようにしました。実装前には、その計画を人が確認し、AIがFigmaの構成や意図を正しく読み取れているかを確かめてから実装に進むようにしました。
これによって実装の精度は上がりましたが、実際の画面にはまだ細かな差分が残りました。コンポーネント単位では正しくスタイルが当たっているように見えても、実際に表示したときのスクリーン幅や要素の固定幅、CSSの継承などの影響で、ブラウザで描画して初めて分かるズレがあったためです。
失敗その2：実装後の差分をうまく検出できなかった
こうした差分を毎回人が目視で確認するのは大変です。そこで、「実装後の確認もAIに任せられないか」と考えました。実装担当とは別にチェック役のSubagentを起動し、Playwrightでブラウザに表示されている画面のキャプチャを取得して、Figmaのスクリーンショットと比較し、差分がありそうな箇所を洗い出す手順をSkillとして用意しました。
個人開発ではうまく機能していた方法だったため、今回も差分を拾ってくれると考えていました。ところが、人が見れば明らかにずれている部分を、何度試しても検出できませんでした。そこで、AIにどのようにデザインを確認していたのかを聞いてみると、実装全体ではなく、特定の観点を中心にチェックしていたことがわかりました。
実装を進めていたメインのAIは、チェック役のSubagentを起動するときに、確認してほしい観点を指定していました。ただ、僕が欲しかったのは、その観点だけを確認することではなく、実装担当のAIが見落とした箇所を広く検出してもらうことです。というのも、AI自身が「実装できている」と認識している部分よりも、そもそも意識できていない箇所や見落としている箇所に、不具合が残っていることが多かったからです。結果として、Subagentは指定された観点を中心に確認し、それ以外の実装漏れを見落としていました。
そこで、特定の観点だけではなく、実装全体をチェックさせるように指示を修正しました。すると、それまで見落としていた実装漏れを検出できるようになりました。
ここから学んだのは、単に「チェックして」と伝えるだけでは足りないということです。何を確認したいのか、どの範囲までを対象にするのかまで伝える必要がありました。
うまくいかなかった原因を、AIと一緒に切り分ける
この2つの失敗以降、AIがうまく動かないときは、プロンプトだけでなく、どの情報を取得し、どのように解釈して動いたのかまで確認するようになりました。
今回は、Figma MCPの呼び出し方と、チェック役のAIへの指示方法に原因がありました。単純に「AIの性能が悪い」と片づけていたら、見つけられなかったと思います。
原因を調べるとき、僕はまずAIに「なぜこの方法で進めたのか」「どの情報をもとに判断したのか」と聞きます。ただし、回答をそのまま原因とは考えません。原因を探すための仮説として、実際に呼び出したツールや取得した情報、受け取っていた指示と照らし合わせます。実際に調べてみると、モデルの性能だと思っていたものが、実は情報の渡し方の問題だったとわかることがあります。その一方で、仕組みを整えても今のモデルでは難しい場合もあります。失敗した原因がどちらなのかを言葉にできれば、次に見直すところもわかります。
原因がわかったら、指示やSkill、ドキュメントへ反映します。そうすることで、同じ失敗を繰り返しにくくなり、次に似たタスクへ取り組むときの判断材料として活かせます。
失敗しながら、AIに任せられる範囲を広げる
少なくとも僕の場合、最初からすべてが想定どおりに進むことは多くありませんでした。ただ、実際に任せてみなければ、今のAIに何ができて、どこからうまくいかなくなるのかは見えてきません。また、最初から広い範囲をAIに任せる必要はありません。まずは人が確認できる小さな範囲から試しつつ、うまくいかなければ原因を調べながら任せ方を調整していきます。
こうした経験から、失敗を避けるよりも、少しずつ新しいことを試す方が大切だと感じるようになりました。僕自身の経験を振り返ると、失敗せずにうまくいっていた時期ほど、新しいことを試さず、以前と同じ使い方を続けていました。その状態では、任せられる範囲も広がりません。
ただ、新しいことを試すからといって、何でもそのままAIに任せればよいわけではありません。今回のFigma実装でも、情報の渡し方や確認の仕組みが整っていなければ、細かな差分や見落としが残りました。
失敗したときは、AIそのものの限界なのか、今の任せ方に改善できる余地があるのかを切り分けることが大切です。「あとここまでできれば任せられる」という点がわかっていれば、モデルやツールが進化したときに、以前できなかったことをもう一度試すきっかけにもなります。
人が判断することと、AIに任せることを分ける
AIに実装を任せても、その結果を人が最初から最後まですべて確認するのであれば、「これなら自分で実装した方が早い」と感じてしまいます。実際、Figma実装でもその状態になりかけていました。
AIにできることが増えると、つい任せる範囲を広げたくなりますが、その分、失敗したときの手戻りも大きくなります。
そのため、僕はまず、人が「どの状態になれば完了なのか」「何をもって正しいと判断するのか」「どんな失敗を防ぐべきか」を決める必要があると考えています。
AIには、そのゴールへ向かう実装や修正を任せます。ただし、ゴールだけを伝えて終わりにするのではなく、途中の誤りを見つけるチェック手段や、失敗したときに修正できる仕組みも用意します。
人は作業の進め方をすべて握るのではなく、ゴールと評価基準を握り続ける。今回のFigma実装でも、「何をどうチェックするか」を明確にしたことで、実装だけでなく、その確認にもAIを使えるようになりました。
チームの向き先が変わった
こうした改善を続ける中で、チームのAIへの向き合い方にも変化が出てきました。Figma実装の失敗が続いたあと、チームは「うまくいかないなら、手動に戻した方が早い」という方向に傾いていました。AIに任せても人が広い範囲を確認し直し、細かなミスも残るのであれば、そう考えるのも仕方がないと思います。
ただ、僕自身はここで諦めたくなかったので、業務の合間に検証を続けました。Figma MCPの呼び出し方と実装後のチェック方法を見直したことで、実装漏れを検出できるようになりました。
改善した手順を共有すると、他のメンバーも同じ流れで使えるようになり、人が確認する回数や手間も減りました。実際の開発でも使われるようになったのです。
「ここはAIで解決できないか？」が最初に出るようになった
これまでは、必要でも手間がかかるため後回しになっていた作業も、AIを使えば取り組めないかと考えるようになりました。誰かが困りごとを話したときに、AIを使った解決方法をみんなで考える場面も増えました。
もちろん、AIを使えば何でも取り組むわけではありません。導入後のメンテナンスまで考え、今は対応しないと判断する場合もあります。その一方で、CIの整備など、重要でも優先度を上げにくかった改善にも取り組みやすくなりました。
AI活用をチームに広げるために、意識していた3つのこと
こうした変化が広がる中で、AI活用をチームに広げるために意識していたことがありました。ここでは、その中でも特に大切にしていた3つを紹介します。
1. 自分が先に試し、失敗も含めて共有する
全員が普段の業務と並行してAIの検証を繰り返すのは現実的ではありません。そこで僕が先に試し、「どこまで任せられそうか」「どこでうまくいかなかったか」をミーティングで共有しました。
うまくいった部分だけでなく、難しかったところや、そこから何を変えて改善したのかまで含めて共有しました。できることと難しいことの両方を伝えることで期待値を上げすぎず、「この範囲なら試せそう」と前向きに捉えてもらいやすくなったと思います。また、言葉だけで説明するのではなく、実際に触ってもらい、自分で確かめてもらうことも意識していました。
2. 挑戦したメンバーを1人にしない
僕ひとりが「これは使える」と伝えるよりも、実際に試したメンバー自身が手応えを感じ、その経験を共有する方がチームには広がりやすいと思っています。
そのため、途中でつまずいたときは、できるだけ一緒に原因を考えるようにしています。「なぜできないのか」と突き放してしまうと、次から相談しづらくなり、失敗から得た知見も個人の中に閉じてしまうためです。
質問しやすい状態をつくり、そこで得た知見をチームに共有することで、次に挑戦するメンバーにも活かせるようになります。
3. いきなり導入せず、小さく試す
新しい方法を見つけても、すぐにチームへ導入するのではなく、普段から活用事例を共有し、興味を持ったメンバーと小さく試します。
実際に使うと、外から見ているだけではわからない課題が出てきます。任せられる範囲や運用上の問題を確認し、チームでも使えそうだと判断できたものを導入しています。
こうした形でAI活用を共有しながら試していく中で、その動きは少しずつ開発チームの外にも広がっていきました。別件にはなりますが、開発チームがAIでFigmaを作成・メンテナンスする取り組みをきっかけに、デザイナーチームでもAIを使った試みが始まっています。開発メンバー以外の挑戦にもつながっているのを見ると、続けてきてよかったと感じています。
今、人がやっている作業の中からAIに任せられる部分を探す
AIにFigmaのURLを渡しただけでは、期待どおりにタスクをこなしてくれませんでした。ただ、原因を調べると、AIの性能だけでなく、Figma MCPの呼び出し方や実装後の評価方法にも改善できる部分がありました。
スクリーンショットではなく詳細なデザイン情報を取得し、特定の観点だけではなく実装全体を確認する。さらに、人がゴールや評価基準を決め、その基準に沿って確認できる仕組みを用意する。そうやってひとつずつ任せ方を見直すことで、実装だけでなく、これまで人が担っていた確認にもAIを使えるようになりました。
こうした経験を踏まえて、僕自身が今意識していることがあります。それは、目の前の作業に対して「ここもAIに任せられないか」と考えることです。今回も、人が行っていた確認作業をAIに任せられないかと考えたことが、チェック役のSubagentを使うきっかけになりました。
こうして作業を分けて見ていくと、今は人が担っている部分の中にも、次にAIへ任せられそうな作業が見えてきます。そのため、普段の作業でも「ここは人がやり続ける必要があるのか」「AIに任せられる部分はないか」を意識するようにしています。また、実際にAIへタスクを任せるときも、いきなりすべてを任せるのではなく、ゴールや評価基準を明確にした上で、小さな範囲から試すようにしています。
さらに、モデルやツールの進化によって、以前は難しかった作業を任せられるようになることもあります。今うまくいっている方法を完成形だとは考えず、過去にできなかったことも、ときどき試し直すようにしています。そうすることで、より良いやり方を学びながら、今のAIにどこまで任せられるのかも改めて確認できます。
普段の業務を進めながら検証するのは簡単ではありませんし、日々登場する新しいモデルやツールをすべて追いかけるのも大変です。
だからこそ、まずは目の前の作業で、「ここはもう少し負担を減らせないか」と感じるところから試すことが大切だと思っています。うまくいかなかった原因を調べた経験は、次にどこまでAIへ任せるかを判断する材料になり、その積み重ねが、AIに任せられる範囲を少しずつ広げることにつながると考えています。
あなたも、まずは目の前の「あの作業」をAIに任せてみませんか？
