爆速開発を支えるAIワークフローの現在地 〜 AIが読めるデザインをどうつくるか 〜 松橋 洋平 末良 崇将 本田 凌一 エンジニアリングマネージャー フロントエンドエンジニア UIデザイナー DADAN株式会社 / 株式会社グリー 株式会社グリー 株式会社グリー 

はじめに 登壇者 松橋 洋平 Engineering Manager 末良 崇将 Frontend Engineer 本田 凌一 UI Designer DADAN株式会社 / 株式会社グリー 株式会社グリー 株式会社グリー 2011年グリー入社後、インフラ開発・ 新規事業に従事。2022年にDADANサー ビスを立ち上げ、現在に至る 株式会社DADANのサービス「DEDEN」 のフロントエンド開発に従事 複数社でサービス立ち上げを経験。株式 会社DADANのサービス「DEDEN」のデ ザインリード 2 

はじめに お話しすること 01 チーム・サービス紹介 SDD部・DADANと、サービス「DEDEN」 松橋 02 爆速開発の現在地 AIエージェントで変えた開発ワークフロー 松橋 今日のメイン｜AIが読めるデザインをどうつくるか 03 UI開発の壁 Figmaを読めるだけでは足りない理由 末良 04 AIが読めるDesign System デザインの判断基準を、AIが読める形にする 本田 05 AIワークフローと実サービスでの検証 DEDENの開発で、実際に試していること 06 まとめ 開発フロー全体を、1本のAIワークフローに 本田 → 末良 松橋 3 

01 チーム・サービス紹介 私たちのチーム：グリー SDD部 × DADAN株式会社 株式会社グリー SDD部 DADAN株式会社 Service Design & Development グリーグループ内外を問わず、 技術支援でお客様の課題を解決 マンガアプリと、電子書籍業務のクラウドツールを運営 × DEDEN DADAN 電子書籍業務のクラウドツール マンガアプリ 課題解決を通じて、電子書籍業界へ貢献する 4 

01 チーム・サービス紹介 DEDEN：電子書籍の業務を支えるサービス EPUB制作 話ファイル制作 マンガ翻訳 メディア構築 特殊ファイル制作 最安・最速で EPUBファイルを制作 話分割の指示書から 分割作業まで AI＋プロ翻訳家で スピードと品質を両立 配信システムを基盤に メディアを構築 合本版・Webtoonなど 様々な形式に対応 ファイル管理 ファイル自動納品 監修ツール 配信カレンダー 売上管理 クラウドで検索・編集・ 閲覧を一元管理 指定日に書誌と本編を 書店へ自動納品 分割指示書や翻訳の 監修をシステムで完結 納品予定日と配信日を カレンダーで確認 配信先ごとの売上報告を データベース化 出版社・書店へのヒアリングを通じて、必要な機能を次々に実装 → 日々、多様なニーズが生まれ、開発に追われている 5 

02 爆速開発の現在地 DEDENの開発サイクル：各チームが連携してタスクを動かす AI 企画 要望を整理し、仕様を決める AI デザイン 顧客 出版社・取次店・書店 課題発生 AI UI/UXを設計し、 デザインを作成 リリース フロントエンド 画面を開発 AI バックエンド ビジネスロジックを 開発 AI QA 顧客の要求を叶えられるか／既存機能に不具合が出ていないか いまは、企画から QA まで、すべての工程でAIが開発を手伝っている 要件定義・詳細設計｜生成AI Figma → コード｜Figma MCP コーディング｜Claude Code・Copilot 6 

02 爆速開発の現在地 人と AI エージェント協働する「爆速ワークフロー」へ 以前 開発要望・ 不具合報告 チケット起票 開発 QA 開発課題が発生 作業単位でチケット化 チケットに沿って改修 課題解決・退行テスト リリース いま｜爆速ワークフロー Slack AI Agent 開発 開発要望・ 不具合報告 調査（GCP・コード） 成果物もAIが 自動レビュー チケット起票 QA リリース AIエージェントが自力解決可能であれば自動修正 7 

02 爆速開発の現在地 爆速ワークフローの土台：AI に DEDEN を理解させる サービス全体を読めるようにする 01 AI の認知負荷を下げる 02 03 モノレポに集約 コンテキストを Markdownで整理 定型作業を skill として保持 DEDEN を構成する サービスを、1つの モノレポに集約 AI に必要な コンテキストを、 Markdown で整理して渡す 定型作業は スクリプト化し、 skill として AI に持たせる 専門エージェントチーム 分野ごとに専門エージェントを育て エージェントが連携して成果物を仕上げる 8 

02 爆速開発の現在地 開発加速計画：AI が理解できる範囲を、段階的に広げる STEP 1 STEP 2 STEP 3 STEP 4 AIにDEDENを 理解させる AI にデザイン を 理解させる AI に 確かめさせる 開発フローを AI でつなぐ サービス全体を AI が読める状態に 判断基準を、 AIが読める形にする 確認と修正を、 AI自身が繰り返す 要件定義〜QA を 1本の AI フローに 実践中 今日のメイン 検証中 これから ▲ ここからが今日のメイン 9 

02 爆速開発の現在地 AIにDEDENを理解させて、開発は速くなった。 でも、UIを「決める」ところは まだ人の判断に頼っている 今日の結論 AIにUIを任せるなら、デザインの判断基準を「AIが読める形」にして渡す 10 

03 UI開発の壁 UI実装には「Figmaあり」「Figmaなし」の2つのルート Pattern A Figmaあり 画面仕様 Figma AI Frontend Figma MCPでAIが デザイン情報を直接参照 Figmaを読んで実装 Pattern B Figmaなし 画面仕様 Figmaなし AI Frontend 小さな変更・既存UIの延長 スピード優先のとき UIも決めて実装 11 

03 UI開発の壁 Figma MCPで、AIがFigmaのデータを直接読める Figma Figma MCP AI Agent 実装コード デザインデータ MCPサーバー Claude Code / Copilot Frontend AIが直接取得できるもの 数値（サイズ・余白） 色 変わったこと スクリーンショットから推測するのでは なく、Figmaの値をそのまま使える レイヤー構造 Variable・Component名 ※ → Figmaとのズレが少ない 実装コードをつくれる ※ Figma側で定義されている場合 12 

03 UI開発の壁 Figmaを読めることと、デザインを理解していることは違う 読める 読めない Figmaに描かれていること Figmaに描かれていないこと 値・色・レイアウト なぜ、このデザインなのか レイヤー構造 いつ、どのComponentを使うべきか 使われているVariable・Component 例外のとき、どう判断するか Figmaがない画面では、どうするか Figmaにあるのは「答え」。AIに必要なのは「解き方」。 13 

03 UI開発の壁 Figmaがなければ、AIはUIのあらゆる判断を推測する 「この仕様で画面をつくって」 → AIは、これを全部自分で決めることになる どのButtonを使う？ Primary Colorは？ Spacingはいくつ？ Radiusはいくつ？ どのIconを使う？ 既存か、新規か？ Pattern Bでは、AIの仕事が「コードを書く」から「デザインを判断する」に変わる 14 

03 UI開発の壁 推測でつくられたUIは、少しずつサービスからズレていく 画面 A 画面 B ≠ 登録する padding 16px 登録する radius 6px padding 18px radius 10px 一画面ずつはきれい。でも同じ役割のUIが少しずつズレていき、 AIが速いほどズレも速く増える 15 

03 UI開発の壁 Figmaを読めるようにするだけで、十分なのか？ 必要なのは、AIが 「デザインの判断基準」を読める状態 では、その判断基準を、どこに、どんな形で持たせるのか 16 

04 AIが読めるDesign System Design Systemを、Designer・Engineer・AIの共通言語に Design System ＝ UIを一貫して設計・実装するための、共通のルールと仕組み 今まで これから AI Designer Design System Engineer Design System Designer Engineer 17 

04 AIが読めるDesign System shadcn/ui + Tailwindを土台に、固有の部分だけを足す shadcn/uiをベースにした理由 Design / Frontend / AI 1 Tailwindベースの論理的な構造 同じルールを参照して、設計・実装する 色・余白・角丸などがスケールとトークンで定 義されている 2 3 Figmaとコードで構造を揃えやすい Service Design System Figma Kitで同じ構造をつくりやすい コードと1対1で対応させられる Brand Color · 独自Variant · Custom Token · Layout Rule AIが読める・使える ルールと命名が一貫しているので、AIが解釈し やすい shadcn/ui + Tailwind CSS Component · Tailwind Scale · Semantic Theme · Icon 目的はshadcn/uiを使うことではなく、AIにも解釈しやすいルールと構造をつくること 18 

04 AIが読めるDesign System 見た目ではなく、名前と構造をFigmaとコードで揃える 概念 Figma Frontend Component Button Variant Variant = Secondary variant="secondary" State State = Disabled disabled Color Primary bg-primary（--primary） Spacing spacing / 4 p-4（16px） Icon Search 揃える：UIの「名前と構造」 Component・Props・Token・Scale・Icon 19 

04 AIが読めるDesign System Tokenは「値」ではなく「役割」でAIに伝える Button Primary Yellow / 500 #FFD12E Component Semantic Token｜役割 Primitive Token｜値の種類 値 ブランド変更 Primaryの参照先を 変えるだけ。 Componentは触らない Light / Dark 同じTokenの参照先を、 Modeで切り替える AIへの伝わり方 「#FFD12E」ではなく 「サービスのPrimary」 として伝わる 20 

04 AIが読めるDesign System DESIGN.mdだけでは、AIに判断の余地が残る Q. デザインのルールも、DESIGN.mdに全部書けばいいのでは？ DESIGN.md ＝ デザインのルールや判断基準を、AI向けに文章でまとめたMarkdownファイル 01 説明であって、制約ではない 「余白は原則16px」と書いても、 コードで自由な値を使えるなら、判断の余地が残る 02 長くなるほど、読み違える ルールや例外が増えるほど、文章が膨らみ、解釈がブレる 03 実装と同期しない コードが変わっても、文章は自動では変わらない Design Systemなら、 使える部品と値そのものが選択肢を絞る → 型エラー 21 

04 AIが読めるDesign System 何が使えるかはDesign System、どう使うかはDESIGN.md What How Design System DESIGN.md 何が存在していて、何を選べるのか（構造） それを、いつ、どう使うのか（文章） Component Variant State - 既存のComponentを優先する Token Scale Theme Icon - 色はHEXではなくSemantic Tokenを使う - SpacingはTailwind Scaleを使う - 表現できなければ、DSへの追加を検討する 22 

04 AIが読めるDesign System 人がDesign Systemを育て、AIはそのルールでつくり続ける 人がルールを決め、育てる Figma 同じルールでつくる Frontend 同じルールでつくる AI 同じルールでつくる Design System （Single Source of Truth） 例外にせず、 Design Systemを拡張 既存で表現できないUI 目指すのは「速くつくれる」ではなく、 「同じルールで、速くつくり続けられる」開発環境 23 

05 AIワークフローと実サービスでの検証 Figmaがあれば「変換」、なければ「設計」からAIが担う AIに渡す情報 画面仕様 Pattern A｜Figmaあり 何をつくるか コードに「変換」する Figma（あれば） 何をどう配置するか Design System 何が使えるか 完成したデザインを、正しいルールで AI DESIGN.md Pattern B｜Figmaなし どう使うか UIを「設計」してから実装 Codebase 実際の実装 ルールをもとに、AIがUIを決める 完成図ではなく「デザインするためのルール」を渡すことで、 AIは開発の一部を自走するエージェントに近づく 24 

05 AIワークフローと実サービスでの検証 実サービス「DEDEN」の開発で、ワークフローを検証中 1 仕様をAIに渡す 2 必要に応じてFigmaを参照 3 Design System / DESIGN.mdを参照 Before After ルールなしでAIが生成 画面仕様 Figma Design System + DESIGN.mdあり 画面仕様 Design System 4 既存コードを確認 AI 5 実装する 実際のDesign System・仕様・コードを使って検証 AI Figma DESIGN.md Codebase Codebase ＋手修正 (＋手修正) 25 

05 AIワークフローと実サービスでの検証 AIの実装が速くなると、次はReviewがボトルネックになる ボトルネック 人が毎回、手で確認 AIが実装 画面を開く 動かす 問題を探す 修正を指示する とても速い AIの自走に必要なのは 「つくる力」＋「自分でつくったものを確かめる力」 26 

05 AIワークフローと実サービスでの検証 確認と修正のループを、AI自身に回させる AIが自分で回すループ 実装する テストで確かめる 問題を直す 人が最終確認 最後の判断に集中する 問題がなくなるまで繰り返す AIに求めること 導入するテスト 仕様とDesign Systemに沿って実装し、 テストで確かめ、自分で直す ①ビジュアルリグレッション ②統合テスト ③E2Eテスト 27 

05 AIワークフローと実サービスでの検証 できていること、まだできていないこと DONE WIP できていること まだできていないこと ・Design Systemに基づく開発 ・自動テストをループに組み込む ・Figmaの変更点をコードに自動反映 実サービスで確かめていること どこまでAIに任せられるか どこに人の判断が必要か 何を構造化すれば精度が上がるか 28 

06 これから ワークフロー全体をAIエージェントでつなげる 開発加速計画 Step 4｜1本のAIワークフロー 要件定義 仕様策定 ワイヤー デザイン 開発 QA お客様の 課題解決 速く・正確に ▲ 今日の話 これまで 工程ごとに、AIで速くする これから ワークフロー全体を、AIで速くする 29 

06 まとめ まとめ 01 コンテキスト整理 02 デザイン理解 03 Design System 整備 AIにサービスを理解させると、開発は爆速になる UIを任せるなら、判断基準をAIが読める形に構造化する Designer・Engineer・AI をつなぐ共通言語になる 30 

AI は、コードを読み書きできるようになった。 AIが読めるデザインで、 開発フロー全体をつなぐ ご清聴ありがとうございました Ask the Speaker / SDD部の他事例紹介など、ブースでお待ちしております。 31 

No content