AIツールの進化が加速するなか、エンジニアの仕事はどう変わっているのか。日々の開発でAIを使い続けるエンジニア3名に、活用の実態から失敗談、半年後の開発スタイルの展望まで、本音で語ってもらいました。 登場人物 名前 役割 あさしん( @asashin227 ) （写真右下） 名古屋プロダクト部のエンジニアリングマネージャー。仕事でもプライベートでもAIをうまく使う方法を常に模索中。エンジニア以外でもAIを使えるようにスタメン内でのハンズオンやAIもくもく会を運営しています おしん( @38Punkd ) （写真左下） iOS開発を得意とするエンジニア。AIを使って積極的にAndroidやWeb技術にチャレンジ中。プライベートではAIでインフラ中心のエンジニアをしている いが( @cochumo ) （写真真ん中） フロントエンドを専門領域としているエンジニア。AIを使ってバックエンド開発にも軸足を伸ばしています。今回のインタビュアーも兼任。 1日の業務の50〜80%がAIと対話。コードの外にも使い道は広がる ── 1日の業務のうち、何%くらいAIと対話したり、作業を任せたりしていますか？ あさしん： ミーティングが結構多いので、思ったよりは使えていないんですよね。それでも50〜60%くらいにはなっていると思います。ミーティングの前に依頼しておいて、ミーティング後に確認みたいな使い方をしています。 おしん： 自分はあまりミーティングが多くないので、70〜80%は使っていますね。 いが： 60%ぐらいでしょうか。作るものの方向性についてメンバーとディスカッションする部分は人間がやらないといけないので、100%にはならないですね。 ── どんな場面でAIを活用していますか？ おしん： 仕様の方向性をまずAIと話して、提案の形に整えてから人間とのディスカッションに持ち込む流れが増えてきました。ステークホルダーへの合意形成の前段階だったり、CS（Customer Success）へのお知らせ文や顧客との調整の頭出しにも使っています。まるっと投げるというよりは、自分なりの仮説がある状態でブラッシュアップしていく、という使い方が多いですね。 あさしん： 最近はClaude Cowork（以下Coworkと表記）をコーディング以外の場面でも使えるようにしていきたいなと思っていて、少しずつ試しています。割合はこれからも増えていきそうだという感覚はありますね。 いが： Coworkいいですよね。社内のチャットのステータス変更の処理を自動化してスケジューリングさせるような使い方は、本当に助かっています。 スピードは上がった。でも、楽しさの「質」が変わった ── AI導入から、開発のスピード感や楽しさはどう変わりましたか？ あさしん： スピード感は確実に上がりましたね。やりたいことを自然言語で書けばとりあえず動く状態になるので、試行錯誤の回数が格段に増えています。ただ、仕事においては「プログラミングは自分がやらなくていい」という目標をもともと持っていたので、AIがコードを書くことへの心理的な変化はそれほどないというか。メンバーが書いてくれるのとAIが書いてくれるのとで、感覚的にはさほど変わらないんです。変わったと思うのは、人との解釈合わせにかかるコミュニケーションコストが減ったことです。AIへの指示は自分の責任で完結するから、より言語化の精度を上げないといけないという意識が強まりましたね。 おしん： 楽しさという意味では、むしろ大きくなりました。これまでネット上の記事を探し回ることに費やしていた時間をAIが肩代わりしてくれるので、「プロダクトの仕様をどう改善すれば売上に貢献できるか」という、本来考えるべきことに頭を使える時間が増えています。 いが： AIの進化にはワクワクするんですけど、AIに実装をやらせているとき自体はそんなにワクワクしなくなってきました。自分が書いていないからのめり込めなくて、複数のことを並行して浅く広く動かす形になってしまっている。コードを書いているときの楽しさは、正直なくなってきましたね。 おしん： ただ、その代わりに。職人的な充実感よりも、事業を前に進めている手応えに重きが移ってきた感覚がありますね。 ── 具体的に「これはAIにやらせて正解だった」という事例はありますか？ あさしん： テストケースを大量に作らせるのはAIが得意な領域で、活用しています。あとは先ほど触れたCoworkですね。カンファレンスのグッズを企画するときに、会話の中で出てきたアイデアをそのままデータ化したり、作ったデータをNano Bnanaで画像に合成して、それっぽいイメージを可視化できるのが便利でした。コーディング以外のプロトタイプも、以前より格段に作りやすくなっています。 いが： Coworkは自然言語で指示してワークフローを組むと、ブラウザ操作まで実行してくれます。そこが本当に大きい。こういった活用はこれからさらに広がっていくんだろうなと感じています。 ガードレールを引かないと、リポジトリもドキュメントも静かに汚れていく ── 逆に、失敗したことや、気をつけていることはありますか？ あさしん： 個々のミスというより、チーム全体として気になっているのはリポジトリに入っているドキュメントが少しずつ汚れていくことです。うちもそこまでドキュメントの文化が強いわけじゃないので、誰も深く見ていない箇所でAIが誤った内容を書き込んでいても気づけない。ガードレールをきちんと設計しておかないと、気づかないうちに的外れな方向へ進んでしまう。意識して向き合わなければならない課題だと思っています。 おしん： 嘘とまでは言えないけれど、根拠があいまいなままでも断言してしまうのがAIの特性だと思っていて。わずかでも事実と違う内容が混ざると、ドキュメント全体の信頼性が揺らいでしまいますよね。 いが： 仕様書をAIに書かせた場合でもユーザーインタビューに基づいた内容なのか、推測で書いたものなのか、根拠がまったくない記述なのか、読んだだけでは区別がつかない。その3パターンをちゃんと分類する仕組みを作って曖昧なところを明示的に固めていく、そういう工夫をこれからも続けていきたいですね。 ── プロンプトや指示の出し方で、自分なりにこだわっていることはありますか？ あさしん： まず一度考えさせる、というのは意識しています。「プランニングしてください」と明示的に書いてから進めるようにしていて。あとは、プロンプトで都度指示することより、ドキュメントを整えて自動的によい動きをしてくれる環境をつくることを優先していますね。スキルの整備やエージェントの動きを定期的に見直すのも続けています。週に一度くらいは、同じ作業を繰り返していたらスキルとして切り出す習慣もつけています。 セッションの履歴を見て、繰り返しやっていることをスキル化するのは効果的です。全セッションを遡る必要はなく、そのセッション内のやり取りから切り出すだけで十分なことが多い。CLI（Command Line Interface）やLSP（Language Server Protocol）をちゃんと使い込むと、その辺りがうまく機能すると思いますね。 これからのエンジニアに求められるのは、ドメイン分解力・抽象力・言語化力だ ── 半年後、自分たちの開発スタイルはどうなっていると思いますか？ あさしん： コーディング作業そのものは今より少なくなると思っています。その代わり、課題を持っているステークホルダーとのコミュニケーションがより重要になってくる。FDE（Forward Deployed Engineer）と呼ばれる役割、つまりお客さんの現場に立ってエンジニアとして提案していくような動き方も、これから注目されていくはずです。 いが： すでに別の会社では、CxO（Chief x Officer）にAI活用が得意な人を一人つけて、その人がやりたいことをPoC（Proof of Concept: 概念実証）化していくという動き方をしているところも出てきていますよね。 おしん： Figmaじゃなくてプロダクトレベルでのモックを素早く作る、という段階は確実に進んでいくと思います。エンジニアの強みは、やりたいことに対してどのアプローチが現実的かを具体的に示せる点にあります。自分のタスクや技術領域だけを見ていればいいという姿勢は通用しなくなって、事業全体を見渡して課題を見つけ動かしていけるエンジニアが、これからの開発を牽引していくと思っています。 ── AIが進化し続ける中で、エンジニアが磨くべき「コアスキル」とは何でしょうか？ あさしん： ITバブルの頃、エンジニアの工数が一番レバレッジが効くと言われていたのは、一人分の工数をかけることで、かけた工数をソフトウェアとして何万人というユーザーに展開できる、かけ算的な成長ができるからでした。今後はAIによってプログラミングが民主化されて誰もが主体的に開発できるようになってくる。そういった中で自分たちが発揮できる価値を捉えていく必要があります。アウトプットがソフトウェアである以上、ソフトウェアがわかる人向けの言語化の仕方はエンジニアならではの強みになると思う。 あとはロジックの破綻を整理してあげるとか、ドメイン駆動開発をエンジニアが担ってAIにドメインごとの指示を出していくとか、そういうやり方が主流になっていくでしょう。ドメイン分解能力、抽象能力、言語化能力、そして事業全体を俯瞰できる広い視野。自分のタスクだけ見ていればいいというエンジニアはどんどん淘汰されていって、事業全体から課題を見つけて推進できるエンジニアが成長して牽引できると思っています。 おしん： エンジニアの専門性はPMやデザイナーとも融合してきているし、モバイル・バックエンド・フロントエンドといった境界もなくなりつつある。そこをコアスキルにするのはもったいない。エンジニアが磨くべきは事業理解であり、事業ドメインをソフトウェア設計に落とし込んで、リリース後も安定的に運用できる力こそが本質なんじゃないかと思っています。 おわりに 今回はテックブログとしては新しい取り組みである「エンジニア3人でAI活用の座談会をする」という記事を作成しました。 AIを使える人と使えない人で、仕事の速さも質も変わってきており、何に注力して、何をAIに任せていくか、そして自身の思考をどこに使っていけばいいのかヒントが掴めたように思えます。 AIの使い方に正解はないからこそ、同じように模索しているエンジニアの方とお話してみたいと思っています。この記事が、そのきっかけになれば嬉しいです。 herp.careers 本記事はインタビュー音声をもとに編集・再構成しています。

はじめに こんにちは、ZOZOTOWN企画開発部 企画フロントエンド1ブロックの片岡優斗です。ZOZOTOWNでは、セール訴求や新作アイテム訴求、未出店ブランドの期間限定ポップアップ、著名人とのコラボなどの企画イベントが日々展開されています。その集客や回遊の起点となるランディングページを「企画LP」と呼んでおり、私はこの企画LPを主に実装するチームに在籍しています。 本記事では、LP制作における属人的なデザイン管理の課題解決に向けて「LP向けデザインガイドライン」を構築した取り組みをご紹介します。 目次 はじめに 目次 背景と課題 プロジェクトの進め方 プロジェクトの始動と進行の中で見えてきた課題 進め方の改善 ガイドラインの設計 ファイル構成 ガイドライン構成 変更可能な要素 コンポーネント まとめ さいごに 背景と課題 企画LP制作では速く作ることだけではなく、「案件ごとの表現を最大化すること」が求められています。 一方で制作を支えるデザインに関する仕様や参照基準は十分に体系化されていませんでした。施策の種別ごとに担当者をある程度固定する体制を取っていたこともあり、それぞれの経験やナレッジをもとに制作を進める状態が続いていました。 これは月10〜20本という高頻度のリリースを支えるためにスピードを優先してきた結果でもあります。しかし約30名（2026年3月時点）のデザイナーが関わる体制へと成長する中で、この暗黙知に依存した運用では徐々に限界が見え始めていました。 施策数の増加や案件内容の多様化に伴い、従来担当していなかった種類の施策を担当するケースが増え、参照すべき基準や過去事例が見えづらくなってきました。その結果、同じ役割を持つUI要素であっても担当や案件ごとに微細な差分が生じるようになり、それらが積み重なることで開発側の調整コストが増大していきました。 組織規模と施策量の拡大によって従来の運用モデルでは対応しきれなくなったことで、本来注力すべき施策の世界観設計や企画ごとの表現づくりに十分な時間を割くことが難しくなっていました。 プロジェクトの進め方 この課題を解決するために立ち上げたのがデザインガイドラインプロジェクトです。当初はデザインルールを整備することをゴールとしていました。リモート勤務が中心になって以降、職種間のコミュニケーション量も減っていました。そこで各デザイナーチームから担当者を1人選出して定例MTGや専用Slackで連携を取りながら継続的に議論できる体制を整えました。 プロジェクトの始動と進行の中で見えてきた課題 当初はエンジニア側がLPでよく使うコンポーネントをリストアップしてデザイナー側に共有し、デザイナー側がその内容をもとにガイドラインを作成する方針で進めていました。しかし実際に進めてみるとガイドライン作成は想像以上に停滞しました。 進行が停滞した背景には、ガイドライン整備という作業の性質と企画デザイナーの業務特性との間に構造的な問題があったと考えています。 ガイドライン整備は要素の網羅的な洗い出し、揺れの排除、再利用可能な形への収束が必要な作業です。さらに内容の正確さだけではなく公開可能なドキュメントとしての見た目の整合性や網羅性も求められるため、1つのコンポーネントを整えるだけでも想定以上の時間がかかります。 一方で企画デザイナーの日常業務は、案件ごとの世界観や表現を設計する発散型の思考が中心です。この性質の違いから、通常業務と並行してガイドラインをゼロから整備することは構造的にも負荷の高い進め方でした。デザイナーの業務は案件の波に影響されやすく、繁忙期には計画通りに工数を確保することが難しいという企画LP組織の特性もありました。 進め方の改善 こうした構造的な課題を踏まえ、ガイドライン整備という作業の性質に着目して進め方を改善しました。要素の網羅的な洗い出しや仕様の収束といった作業は、実装構造やコンポーネント設計を把握しているエンジニアの視点と相性が良いと判断しました。 そこでエンジニアがコードベースから過去の仕様やユースケースを確認して叩き台を作成し、デザイナーがその内容を精査・調整してガイドラインを発展させていく作業を担う体制へと切り替えました。この体制によりデザイナーは「ゼロから整える作業」ではなく「品質を高める判断」に集中でき、収束型の意思決定が加速しました。結果として進行は大きく改善し役割分担も明確になりました。 またこの進め方に切り替えたことで、エンジニアが普段の開発業務で扱っているコンポーネントや変数に近い概念をFigma上でも扱いやすくなり、コンポーネントやバリアブルなどの機能活用も進みました。その結果ガイドラインは単なるデザインルール集にとどまらず、デザインシステムに近い形へと発展していきました。 ガイドラインの設計 ここからは、実際のガイドライン構成をご紹介します。 ファイル構成 本デザインガイドラインでは、デザイナーが管理しやすいように、ガイドラインとコンポーネントセットを同じFigmaファイル内で管理しています。そのためFigma内の情報量が多く、今後もコンポーネントが継続的に増えていく可能性も高いことから、拡張性を考慮してコンポーネント単位でページを分けて作成しています。またファイル名は「デザイン名 / 実装名」で統一し、デザイナー・エンジニアどちらの視点からも目的の項目にたどり着きやすくしています。 また運用マニュアルとして「デザインガイドライン運用マニュアル」と「LP運用マニュアル」を用意し、ガイドラインの利用ルールやLP制作時のFigma活用方法を明文化しました。 ガイドライン構成 ガイドラインは「コンポーネントの利用方法を伝える」ことを意識した構成になっています。コンポーネント名・構造・変更可能な要素・スタイル・デザインパターンをひとまとまりで参照できるようにしています。 コンポーネント名 基本構造 構造詳細（デザイン変更可能な要素） スタイル デザインパターン 変更可能な要素 企画LPは施策ごとにトーンや世界観が大きく変わるため、表現の自由度を残す必要がありました。一方で1つのコンポーネントの中でも自由に変更可能な箇所やデザインパターンが多数存在するため、FigmaのComponent propertiesだけでは十分に制御しきれませんでした。そのためパターンとして定義できるものはComponent propertiesで管理し、それ以外の自由に変更できる部分についてはガイドライン上で変更可能な要素を明示する形にしました。 コンポーネント利用箇所から変更可能な要素を確認できるプラグインを作成 ガイドライン上で明示するだけではコンポーネントを使うたびにガイドラインを都度見に行く手間がありました。そこでコンポーネントの利用箇所からでも変更可能な要素を確認できるように専用のプラグインも作成しました。 変更可能な要素は画面上で点線のレイヤーを付けて視覚的に示し、右側のアノテーションでも項目を明示してどこが調整可能かひと目で把握できるようにしています。 コンポーネント 各コンポーネントのページには、デザインガイドラインとFigmaコンポーネントを1つのファイル内にまとめています。左側にはコンポーネントの基本構造やSP（スマートフォン）/PCごとのスタイル、基本的な種類といったガイドラインを記載し、右側にはFigmaコンポーネントを配置しています。これにより、デザイナーはガイドラインを確認しながらそのままコンポーネントを利用でき、仕様の確認と実作業を同じファイル内で完結できる構成としました。 ガイドライン整備の結果、利用を開始した2025年7月下旬以降のコンポーネント利用数は継続的に増加していきました。制作現場でもコンポーネント利用が徐々に定着してきており、ガイドラインを整備するだけでなく実際に使いやすい構成や運用にまで落とし込めたことがこの定着につながったと捉えています。 まとめ 本記事では、ZOZOTOWNのLP制作における属人的なデザイン管理の課題に対し「LP向けデザインガイドライン」を構築した取り組みをご紹介しました。 デザインガイドラインを作成することで開発側のコンポーネントとデザインの差分が抑えられ、企画LP開発時の出戻り削減につながりました。 またエンジニアが叩き台を作りデザイナーが精査・発展させるという進め方は、業務特性に合わせた協業モデルの再設計でもあり、暗黙知を言語化しチームで活用できる知識に変えるための知見も得られました。 企画LPのように表現の多様性が求められる領域でも「固定する要素」と「自由に変更できる要素」を明確に区分することで、効率化と表現の最大化を両立しやすい形にできました。この結果、制作の起点が「それぞれの経験やナレッジで作る」から「既存のコンポーネントを活用して表現を作り込む」へと移行できました。デザインガイドライン作成を通して個人最適ではなく組織全体として効率的に制作を進められる土台ができたと考えています。 さいごに 今回の取り組みを通して、企画LP向けのデザインガイドラインを整備できました。一方でガイドラインは作成して終わりではなく、実際の制作現場で継続的に活用され改善されていく状態を作ることが重要だと思います。今後は継続的に改善できる仕組みづくり、さらなるガイドラインの浸透、Figma Makeなどを活用した拡張を進め、制作現場の運用基盤としてさらに発展させていくことが目標です。 ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com

はじめに FigmaのデザインデータをもとにUIを実装する際、「デザインの読み取り」と「コードへの落とし込み」に時間がかかることはありませんか？ 本記事では、Figma MCP（Model Context Protocol）とGitHub Copilotを組み合わせてReactでUI実装を行った際の工夫点や注意点をまとめます。 Figma MCPとは Figma MCP（Model Context Protocol）は、Figmaのデザイン情報を構造化データとしてLLMに渡すための仕組みです。 Figma MCPサーバーのガイド – Figma Learn - ヘルプセンター