「いい感じにして」で終わらせない ― UI/UX改善をAIエージェントに依頼するときのコツ

Posted at 2026-07-22

株式会社Good Labでエンジニアをしているコータローです。
日々、Java・SQL・Gitなどの技術情報や、新人エンジニア向けの学習ノウハウ、
AI活用についての情報を発信しています。

Good Labについて気になった方は、コーポレートサイトもぜひご覧ください。
▶コーポレートサイト

「AIエージェントにUIを直してもらったけど、なんか微妙」

AIコーディングが当たり前になって、UI/UXの実装や改善もエージェントに任せる人が増えました。でも、任せてみると多くの人が同じ壁にぶつかります。「いい感じにして」と頼むと、たしかに動くものは返ってくるけれど、"いい感じ"にはならない。色がちぐはぐだったり、ボタンが押しづらかったり、そもそも情報設計が整理されていなかったり。

私は本業がSES（受託・客先常駐）のエンジニアで、複業として個人・共同でiOSアプリを開発しています。SwiftUIのUI設計・改善は、専用のAIサブエージェント（デザイン方向性決め・画面実装・UI改善を担当）に任せる運用にしています。ただし丸投げはしません。工程を分けて、渡す制約を設計して、出てきたものを別の視点でチェックする。この「頼み方」の部分に何度も失敗して、ようやく安定してきました。

本記事は、その失敗と実践から得た「UI/UX改善をAIエージェントに依頼するときのコツ」を6つに整理したものです。実例はiOS（SwiftUI）ですが、内容はWeb/モバイル問わず、AIエージェントにUIを任せる開発者全般に応用できるように一般化して書きました。具体的な依頼プロンプトのBefore/Afterも載せています。

なぜ「いい感じにして」はうまくいかないのか

先に結論だけ言うと、UIにおける「いい感じ」は、依頼者の頭の中にしか存在しないからです。

あなたの中には「こういうトーンで、この有名アプリみたいに、ここは押しやすく」という像があります。でもそれを言語化して渡さない限り、エージェントは世間一般の平均的なUIを出してきます。平均的なUIは「動くけど刺さらない」。そして厄介なことに、平均的だからこそ、パッと見では何がダメか指摘しづらい。

だから、やることは1つです。あなたの頭の中の「いい感じ」を、具体的な制約に翻訳して渡す。制約というと窮屈に聞こえますが、UIにおいては制約こそが品質の源です。ここから、その翻訳のコツを具体化していきます。

コツ1: 参考にするアプリの「デザイン言語」を指定する

一番効果が大きく、一番簡単なのがこれです。「参考にする有名アプリを名指しする」。

「モダンでおしゃれな感じ」という形容詞は、人によって指す像がバラバラです。一方で「〇〇（有名アプリ）のような余白の取り方・タイポグラフィで」と言えば、エージェントはそのアプリが持つデザイン言語（余白・階層・配色・角丸・モーションの一貫した文法）を参照点にできます。形容詞より固有名詞の方が、はるかに情報量が多い。

【Before】
このプロフィール画面をおしゃれにして。

【After】
このプロフィール画面を改善して。
デザイン言語は「余白を広くとり、カードの角丸は控えめ、
アクセントカラーは1色に絞る」方針で。
情報の主従がはっきりする階層設計にしてほしい。
（※参考にしたい既存アプリがあれば、その名前や
　スクリーンショットを添えるとさらに精度が上がる）

ポイントは、名指ししたうえで「そのアプリのどの要素を参照したいのか」まで踏み込むこと。「あのアプリっぽく」だけだと、エージェントは色だけ真似して余白は無視、といったズレを起こします。「余白の取り方」「タイポグラフィの階層」「アクセントカラーの絞り方」など、真似してほしい軸を指定すると精度が上がります。

コツ2: 「カラートークン」を渡して、毎回説明しなくて済むようにする

コツ1を続けていると、次の悩みが出ます。依頼のたびに、同じデザイン方針を一から説明するのが面倒。「アクセントカラーはこれ、背景はこれ、角丸はこれ……」を毎回書くのは、時間の無駄だし、説明がブレると成果物もブレます。

そこで私は、複数アプリで使い回せるブラウザ製のUIカタログツールを自作しました。色・角丸・ライト/ダークの配色をブラウザ上でライブに調整できて、確定した値を「トークンセット」として持っておけるものです。エージェントには「このトークンセットに従って実装して」と渡すだけ。デザイン言語を毎回言葉で説明する必要がなくなりました。

専用ツールを作らなくても、この考え方は誰でも使えます。要はデザインの決定事項を、再利用できる形で1か所にまとめておくということです。

【デザイントークンの例（そのまま渡せる形にしておく）】
- Primary(アクセント): #2E7D6B
- Background(Light): #FFFFFF / (Dark): #121212
- Text(Primary): #1A1A1A / (Dark): #ECECEC
- 角丸: 12px（カード） / 8px（ボタン）
- 余白の基準単位: 8px（4の倍数で刻む）
- フォント階層: Title 22 / Body 16 / Caption 13

こうしておくと、依頼が「このトークンに従って」の一言で済みます。人間のデザインシステムと同じで、決定を再利用可能にすると、指示コストも品質のブレも両方下がる。CSS変数、Tailwindの設定、SwiftUIのColor拡張など、手段は何でもかまいません。

コツ3: アクセシビリティは「明示的に監査を依頼」しないと出てこない

これは声を大にして言いたい点です。アクセシビリティ観点は、自分から明示的に頼まないと、まず出てきません。

「UIを改善して」と頼んで返ってくるのは、たいてい"見た目"の改善です。コントラスト比、タップ領域のサイズ、スクリーンリーダー対応といった観点は、明示しない限りスルーされがちです。動いて見た目が整っていると、できた気になってしまう。でも実機で使う人の中には、文字が読みづらい人も、細かいタップが難しい人もいます。

なので私は、UI改善とは別のオーダーとしてアクセシビリティ監査を依頼します。

【Before】
このボタン、押しやすくして。

【After】
この画面をアクセシビリティ監査して。特に以下をチェック:
1. テキストと背景のコントラスト比が WCAG AA を満たすか
   （本文4.5:1以上、大きい文字・UI部品3:1以上）
2. タップ領域が最小44×44pt（Apple HIG）を満たすか
3. スクリーンリーダー（VoiceOver等）で各要素が
   意味の通るラベルで読み上げられるか
問題があれば箇所と修正案を挙げて。

数字の基準（4.5:1、44pt）まで書くのがコツです。基準を渡すと、エージェントは「なんとなく良くする」ではなく「基準を満たすか判定する」モードになり、指摘が具体的になります。

実際、私はこの監査依頼で 「アプリのテーマ設定と実際の画面の見た目が一致していない」不整合（設定上はあるテーマなのに、一部画面に反映されていない）を発見・修正できたことがあります。人間が目視で見落としがちな一貫性のズレを、基準を持った第三者の目で拾えるのは大きい。

補足: WCAG AAでは本文（おおむね18pt未満）が4.5:1、大きい文字やUI部品が3:1という基準です。Appleのヒューマンインターフェイスガイドラインは最小タップ領域を44×44ptとしています。プラットフォームが違っても「基準値を明示して監査させる」考え方は共通です。

コツ4: 見た目だけでなく「情報設計」まで踏み込んで相談する

ここまでは主に見た目の話でした。でも、AIエージェントとの相談が一番効くのは、実は情報設計のレイヤーです。画面遷移、CTA（行動喚起ボタン）の数、オンボーディングの長さ。この辺りは「色を変える」より効果が大きいのに、依頼から抜け落ちやすい。

私が実感したのはオンボーディング画面の改善でした。最初は説明したいことを詰め込んで画面数も多く、ボタンもあちこちにあって煩雑でした。それをエージェントとの壁打ちで、**「4画面に圧縮」「各画面のCTAを1つに一本化」**という情報設計レベルの整理に落とし込めました。見た目を磨く前に、そもそも「何を見せて、何を押させるか」を削る作業です。

【Before】
オンボーディングのデザインをきれいにして。

【After】
このオンボーディング（現状6画面）を情報設計から見直したい。
- 初回ユーザーが「使い始める」までに本当に必要な情報は何か
- 各画面のCTAは1つに絞れないか（選択肢が多いと離脱する）
- 画面数を減らせないか。減らすなら何を統合/削除すべきか
まず構成案（各画面の役割とCTA）を提案して。実装はその後で。

コツは、いきなり実装させず「構成案から」出させることです。UIは、実装してから「やっぱり画面構成が違う」となると手戻りが大きい。情報設計の段階でテキストベースの壁打ちを挟むと、安く早く方向性を固められます。「1画面1メッセージ」「CTAは原則1つ」といった原則を渡すと、議論が具体化します。

コツ5: 実装とレビューを「別の担当」に分ける

これは個人開発でも効く、地味だけど強力なコツです。UIを実装したエージェントに、そのUIの自己レビューをさせない。

作った本人（人間でもAIでも）は、自分の成果物に甘くなります。「さっき自分でこう書いたんだから、これでいい」というバイアスが働く。私は、UI実装を担当するエージェントと、コードレビューを担当するエージェントを別に立てています。実装が終わったら、必ず別のレビュー担当に「粗探し」の視点でチェックさせる。

工程を分けると、こんな流れになります。

[方向性決め] デザイン方針・トークンを固める
      ↓
[実装] UIを実装する（担当A）
      ↓
[レビュー] 別の視点でチェックする（担当B）
      ← コントラスト/タップ領域/命名/一貫性/未対応の状態
      ↓
[反映] 指摘を実装に戻す

※ 上図は私の運用イメージです。エージェントの分け方は各自のツール・スタイルに合わせて設計してください。

役割を分ける本質は、「作る視点」と「疑う視点」を混ぜないことです。同じセッションで「実装して、ついでにレビューして」と頼むと、直前に自分が出した実装を肯定する方向に引っ張られます。担当を分け、レビュー担当には「粗を探すのが仕事」と明示的に役割を与えると、指摘の質が上がります。これはClaude Codeのサブエージェントに限らず、チャットのセッションを分ける、レビュー用のプロンプトを別に用意する、といった形でも再現できます。

コツ6: 「実機でしか気づけない項目」はチェックリスト化しておく

最後は、依頼の"抜け"を仕組みで防ぐ話です。UIには、コードを読むだけ・1つの状態を見るだけでは気づけない項目があります。代表格が次の2つです。

ライト/ダーク両対応: ライトモードでは綺麗でも、ダークモードで文字が背景に沈む、といったことが起きる
Dynamic Type（文字サイズ変更）対応: ユーザーが文字を大きくすると、レイアウトが崩れる・見切れる

これらは「実機で、その状態にして、初めて分かる」タイプの問題です。毎回思い出しながら依頼するとほぼ確実に抜けるので、私は依頼テンプレにチェックリストとして固定しています。

【UI変更後に必ず依頼するチェックリスト】
□ ライトモード / ダークモード 両方で破綻がないか
□ 文字サイズを最大にしても崩れ・見切れがないか（Dynamic Type）
□ 縦横の画面回転・小さい端末で崩れないか
□ 空状態 / ローディング / エラー状態のデザインがあるか
□ 長いテキスト・0件・大量件数など極端なデータで崩れないか

コツ3のアクセシビリティ基準と同じで、「毎回思い出す」を「毎回貼る」に変えるのが肝です。人間の記憶に頼ると抜ける。テンプレ化してしまえば、依頼のたびに同じ品質のチェックが自動で乗ります。特に「空状態・エラー状態」は正常系だけ実装して忘れられがちなので、リストに入れておく価値が大きい。

まとめ: UI依頼の質は「渡す制約の質」で決まる

AIエージェントにUI/UXを任せるとき、成果物の質を決めるのは、エージェントの賢さよりあなたが渡す制約の質です。私が実践している6つを、もう一度並べます。

参考アプリのデザイン言語を指定する ― 形容詞より固有名詞。真似したい軸まで踏み込む
カラートークンを渡す ― 決定を再利用可能にして、毎回の説明コストとブレを減らす
アクセシビリティは明示的に監査依頼する ― 基準値（4.5:1、44pt）を書いて判定させる
情報設計まで踏み込む ― 画面数・CTA数・遷移。実装前に構成案から議論する
実装とレビューを別担当に分ける ― 作る視点と疑う視点を混ぜない
実機でしか気づけない項目をチェックリスト化する ― ライト/ダーク、Dynamic Type、空状態

共通しているのは、頭の中の「いい感じ」を、具体的な制約・基準・チェックリストに翻訳して渡すという一点です。「いい感じにして」で終わらせないこと。制約を渡すのは手を抜くのと逆で、むしろ一番丁寧なコミュニケーションだと私は思っています。

次にUIをAIに頼むとき、まず1つだけ試すなら コツ3のアクセシビリティ監査 をおすすめします。基準値を書いて「監査して」と頼むだけで、今まで見えていなかった問題がいくつも出てくるはずです。

参考

@kotaro_ai_lab
AI活用や開発効率化について発信しています。フォローお気軽にどうぞ！

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up