Sunagaku
JA / EN
Blogsへ戻る

2026.05.01

【Qiita Bash】エンジニアリングとデザインをつなぐAI活用の学びシェア

個別ツールではなく自分の抽象に依存させる、という考え方が刺さりました。AI でデザインを進める時の 4 ステップ、定番プロンプト、実務で使えない要因まで、勉強会で学んだ内容を整理します。

はじめに

先日参加した勉強会 (#QiitaBash) で、AI を使ったデザインや資料作成の考え方について、非常に学びの多い話を聞くことができました。

その中で印象に残った内容を、自分の整理も兼ねてまとめてみます。これから AI を活用してデザインや資料作成を進めたい方の参考になれば嬉しいです。

依存をデザインする

Figma や Claude Code、Gemini など、個別ツールを追いかけ続けると、それだけで時間が溶けていきます。

重要なのは、個別ツールへの依存を「自分の抽象への依存」に置き換えることだと感じました。

自分のドメインや業務プロセスを言語化して AI に渡し、その抽象に従って AI のアウトプットを評価する。新しいツールが出てもこの土台は崩れないので、ツールの入れ替わりに振り回されなくなります。

「自分がドメインになって、周りに依存させる」というイメージです。AI に振り回されるか、AI を抽象の中で使い倒すかは、ここの設計次第になると思います。

AI でデザインを進める 4 ステップ

スライドや資料を AI で作る時は、次の順で進めると精度が上がるとのことでした。

  1. 要件定義（誰に・何を・どのくらいで）
  2. Markdown での原稿執筆
  3. テキスト版 PPTX
  4. 画像版 PPTX

要件 → 原稿 → 骨格 → ビジュアルの順で粒度を上げていきます。順番を逆にしたり、間を飛ばしたりすると、後工程で必ず手戻りが出ると感じています。

テキスト版 PPTX を必ず挟む

特に重要なのが「テキスト版 PPTX を必ず挟む」ことです。

いきなり画像にすると、見栄えに引っ張られて中身の弱さが見えなくなってしまいます。テキストだけで通る骨格があってはじめて、ビジュアルが意味を持つ、という話が腑に落ちました。

画像化は Gemini API に日本語のまま渡す

画像化は Gemini API などでインフォグラフィック化すると良いそうです。日本語をそのまま渡しても、テキストを正確に出してくれます。

モデル差は CLAUDE.md と Skills に貯める

画像系は使うモデルによってチューニングが必要になります。Gemini Nano Banana で動いていたプロンプトを、そのまま GPT-Image 2 に渡すと崩れることが多いそうです。

毎回試行錯誤するのは効率が悪いので、気づきや注意点を CLAUDE.md や Skills に随時反映させていきます。次に同じ場面が来た時、AI 側がその制約を踏まえて動いてくれるようになります。

AI に投げる定番プロンプト 3 つ

何度も使える依頼パターンとして、次の 3 つが効くとのことでした。

  1. 根本原因を特定して、再発防止してください
  2. 専門チームを設計して取り組んでください
  3. ルール・スキルに反映させてください

特に 3 つ目は、今回うまくいった工夫を再利用可能な資産として残してくれるので、より AI が思い通りに動いてくれるようになると感じました。

AI で作ったデザインが実務で使えない 3 要因

AI のポン出しが実務で使えない要因は、3 つに収束していくそうです。

  1. ユーザーの特性や利用シーンが反映されていない
  2. デザインシステムを無視した一貫性のない出力になる
  3. ブランドやビジネス目標から離れる

本当の問題は「インプットの難解さ」

上記の問題は「インプットの難解さ」という一つの問題に行き着きます。

ペルソナ・行動シナリオ・デザインシステム・ブランドガイドラインを渡せないと、AI は「ありそうな見た目」を作るしかありません。

バイブで作ると、立ち戻る場所がなく使われずに消える

とりあえず AI でポン出しすると、立ち戻る場所がなくなります。

本来何をすべきか、どこをユーザーにヒアリングすべきかの土台がないまま画面だけ増えていき、使われずに消えるアプリができあがってしまいます。

デザインの 3 フェーズを意識する

Figma の Config キーノートで打ち出された枠組みとして、デザインには次の 3 フェーズがあります。

  • Freeform Design
  • Structured Design
  • Engineering

自分の作業が今どのフェーズにいるのかを意識すると、AI に渡すべきインプットも、返ってくるべきアウトプットも明確になると感じました。

Structured Design に責任を持つ人を置く

Structured Design は「みんなが使えるようにする」「共通資産として持てるようにする」責任を持つフェーズです。

この領域に対して責任を持つことが、デザインシステムを継続してメンテナンスする上で重要になります。AI を入れる前提でも、ここを支える人がいないと結局運用できなくなってしまいます。

「育てるループ」を作る

色々作っても運用できなければ意味がありません。プロダクトは変化しますし、片手間では品質は保てません。使われなければ存在していないのと同じです。

ポイントは AI に渡す情報 = デザインの資産として、両方を一緒に育てることだと感じました。AI が出てくる前からあった課題なので、AI を理由に積み残すのではなく、人が継続的に育てる前提で土台を作るのが大切だと思います。

デザインシステムは自動メンテで回せる

差分は GitHub Actions で検出できます。PR レビュー待ちには Lost Pixel のような Visual Regression Test ツールで「間違い探し」を自動化できます。

先にプロトタイプを作ってから考える手段も有効

デザイナーが AI でサクッとプロトタイプを作って、その上で考慮漏れをチェックする、というワークフローも組みやすくなったと感じています。

おわりに

今回の勉強会では、「ツールではなく抽象に依存させる」「テキストの骨格を必ず挟む」「育てるループを作る」など、AI を実務で使い倒すための考え方を沢山学ばせていただきました。

主催いただいた Qiita さん、登壇者・参加者の皆さん、ありがとうございました！

Xフォローしてくれると嬉しいです

Xでも情報発信しているので、フォローしていただけると励みになります！

https://x.com/suna_gaku