はじめに
現在、AWSのリソース設定やCloudFormationテンプレート生成を支援するWebアプリを個人で開発しています。
開発を進める中で、機能面だけでなく、次のようなUI上の課題を感じるようになりました。
- 業務ツール感が強く、画面が少し固い印象になっている
- 操作ボタンや設定項目が多く、情報の優先順位が分かりにくい
- AWSサービスごとに画面構成が少しずつ異なり、統一感が弱い
- 初めて使う人が、次に何を操作すればよいか迷う可能性がある
これまでもChatGPTやCodexを使い、HTML・CSSのデザイン案を作成しながら改善していました。
以前は主にGPT-5.5を使用していましたが、GPT-5.6で同じようにWebアプリのUI改善を依頼したところ、以前よりもデザインの完成度が上がったように感じました。
そこで今回は、実際のWebアプリのUI改善を通して、GPT-5.5とGPT-5.6でどのような違いを感じたのかをまとめます。
なお、この記事はモデル性能を厳密に測定したベンチマークではありません。
あくまで、個人開発中のWebアプリで実際に使用した際の体験をもとにした内容です。
改善対象のWebアプリ
今回改善したのは、AWSリソースをGUI上で設定し、CloudFormationテンプレートを生成するWebアプリです。
現在は、次のようなAWSサービスの設定画面を実装しています。
- Amazon S3
- AWS Lambda
- Amazon API Gateway
- Amazon CloudFront
- Amazon DynamoDB
各サービスの画面では、リソースの追加、設定変更、料金試算、テンプレート生成などを行えるようにしています。
機能が増えるにつれて、単に設定項目を並べるだけでは、画面が見づらくなってきました。
特に、S3のリソース管理画面と編集画面には、次のような課題がありました。
- 画面上部に情報やボタンが集中している
- 主な操作と補助的な操作の区別が弱い
- 設定項目が縦に長く並び、現在地を把握しにくい
- 情報量に対して、セクションの区切りが弱い
- 画面全体が管理画面らしい固い印象になっている
そこで、まずはS3画面を対象としてデザインを見直しました。
以前のデザイン
以前の画面は、機能を実装することを優先していたため、必要な操作は一通り行える状態でした。
一方で、設定項目、説明文、操作ボタンが同程度の強さで表示されており、画面を開いたときに最初にどこを見るべきか分かりにくい状態でした。
変更前の画面
画像：AWSサービス選択管理画面
画像：変更前のS3リソース管理画面
機能面では問題ありませんでしたが、次の点を改善したいと考えました。
- ページタイトルとリソース情報を分かりやすくする
- 主操作と副操作のボタンを分ける
- 設定内容をカードやセクション単位で整理する
- 画面全体の余白と文字サイズを調整する
- 他のAWSサービス画面にも展開できる構成にする
GPT-5.5で作成していたデザイン案
以前から、画面のスクリーンショットを見せながら、ChatGPTに改善案を依頼していました。
GPT-5.5でも、カードUI、角丸、シャドウ、余白の調整など、一般的なWeb UIの改善案は十分に作成できました。
ただし、生成された案には次のような傾向を感じることがありました。
- すべての要素をカードで囲む
- 余白が均一で、情報の重要度による差が小さい
- ボタンやラベルの種類が増えすぎる
- 見栄えは良いが、実際の業務画面としては少し装飾が多い
- 画面単体では良いが、アプリ全体への展開を考えると調整が必要
もちろん、プロンプトや入力する情報によって結果は変わります。
また、当時は自分自身も、改善したい点を十分に言語化できていなかったと思います。
GPT-5.6でデザインを作り直した
GPT-5.6では、現在の画面と以前の改善案を提示し、比較しながら再設計を依頼しました。
依頼時には、単に「おしゃれにしてください」とは伝えず、次のような観点を指定しました。
- 情報の優先順位
- 視線誘導
- 主操作と副操作の区別
- AWSサービス間で共通化できる構成
- 業務ツール感を残しつつ、固すぎないデザイン
- 実際にReactへ組み込みやすいHTML・CSS
- 既存機能を削除しないこと
実際のプロンプトは、次のような内容です。
現在のWebアプリ画面と改善案を比較し、
情報の優先順位、余白、視線誘導、操作性の観点から
デザインをレビューしてください。
業務ツールとしての分かりやすさは残しつつ、
固すぎない現代的なUIにしてください。
また、S3だけの専用デザインではなく、
CloudFront、API Gateway、Lambda、DynamoDBなどにも
同じ構成を展開できるようにしてください。
既存機能は削除せず、Reactに組み込みやすい
HTML・CSSの静的デザイン案を作成してください。
プロンプトには、現在の画面と以前のデザイン案のスクリーンショットも添付しました。
GPT-5.6で作成した改善案
GPT-5.6で作成した案では、以前よりも画面全体の情報整理が自然になったように感じました。
改善案の画面
ここにGPT-5.6で作成したHTML・CSSの画面を掲載します。
画像：GPT-5.6で作成したAWSサービス選択管理画面
画像：GPT-5.6で作成したS3リソース管理画面
特に変化を感じたのは、単にカードや色を追加するのではなく、画面内の役割ごとに情報が整理されていた点です。
例えば、次のような改善が含まれていました。
- リソース名や状態をページ上部にまとめる
- 頻繁に使う操作を目立たせる
- 削除などの危険な操作を通常操作から離す
- 設定内容を意味のある単位でグループ化する
- 補足説明を主情報より弱く表示する
- 余白を使ってセクションの境界を表現する
- 他のAWSサービス画面にも流用しやすい構造にする
見た目を変更するだけでなく、操作の流れまで考えた構成になっているように感じました。
GPT-5.5とGPT-5.6で感じた違い
今回の利用経験をもとに、違いを整理すると次のようになります。
| 観点 | GPT-5.5で感じた傾向 | GPT-5.6で感じた変化 |
|---|---|---|
| 全体レイアウト | 要素を整列させる改善が中心 | 画面全体の役割を整理する提案が増えた |
| カードの使い方 | 多くの要素をカードで囲む傾向 | 必要な部分だけをまとまりとして表現 |
| 余白 | 全体的に均一 | 情報の重要度に応じた差がある |
| ボタン配置 | 機能ごとに並べる | 主操作、副操作、危険操作を分離 |
| 視線誘導 | 見た目を整えることが中心 | タイトルから操作までの流れが自然 |
| 説明文 | 説明をそのまま表示 | 主情報を邪魔しないように弱く表示 |
| 共通化 | 画面単位の改善 | 他画面への展開を考慮した構成 |
| 実装イメージ | 静的なサンプルとして完成 | 実際のアプリへ組み込みやすい構造 |
特に大きな違いとして感じたのは、GPT-5.6では「見た目を良くする」だけでなく、「利用者がどの順番で情報を見るか」を考えた提案が増えた点です。
実際にReactへ反映した
生成されたHTML・CSSを参考にしながら、実際のReactアプリへデザインを反映しました。
ただし、生成されたコードをそのままコピーしたわけではありません。
既存コンポーネントや状態管理に合わせて、次のような調整を行いました。
- HTML構造をReactコンポーネントへ置き換える
- 既存のイベント処理を接続する
- CSSを既存のデザインシステムへ合わせる
- ボタンやラベルの文言を調整する
- モバイル表示を確認する
- 他サービスでも使えるように共通コンポーネント化する
- ローディング、エラー、空状態の表示を追加する
Reactへ反映した画面
画像：Reactへ反映したS3リソース管理画面
画像：Reactへ反映したS3編集画面
静的なHTML・CSSでは良く見えても、実際のアプリへ反映すると、調整が必要な部分が出てきます。
例えば、実際のデータが長い場合、ボタンが増えた場合、エラーメッセージが表示された場合などは、サンプル画面だけでは確認できません。
そのため、AIが作成したデザインを完成形として扱うのではなく、実装の土台として利用する形が良いと感じました。
人間側で調整が必要だった部分
GPT-5.6でデザインの完成度が上がったと感じた一方で、すべてをそのまま採用できるわけではありませんでした。
1. 実際の利用頻度までは分からない
AIは画面の見た目や説明から操作の重要度を推測できますが、実際に利用者がどの機能を頻繁に使うかまでは分かりません。
そのため、ボタンの優先順位は、自分で見直す必要がありました。
2. 既存機能との整合性が必要
静的なデザイン案では、ローディング中、エラー発生時、権限不足時などの状態が含まれていない場合があります。
実際のアプリでは、正常時以外の表示も考える必要があります。
3. 文言は別途調整が必要
デザイン上は分かりやすくても、AWSの設定内容として正確ではない文言が使われることがあります。
特に、AWSサービスの設定項目やCloudFormationのプロパティについては、別途確認が必要です。
4. デザインの一貫性は人間側で管理する
一つの画面として完成度が高くても、別の画面で毎回異なるデザインを生成すると、アプリ全体では統一感がなくなる可能性があります。
そのため、次のような要素は共通ルールとして定義しました。
- ページタイトルの表示方法
- メインボタンとサブボタンの色
- カードの余白
- 見出しの文字サイズ
- 状態ラベルの表示
- 削除ボタンの配置
- 空状態のデザイン
- 設定セクションの構成
GPT-5.6だけが理由ではない
今回、以前よりも良いデザインになった理由は、GPT-5.6の性能向上だけではないと考えています。
自分自身が開発を続ける中で、以前よりもUIの課題を具体的に伝えられるようになったことも影響しています。
以前は、次のような依頼をすることが多くありました。
この画面を見やすくしてください。
現在は、次のように具体的な条件を伝えるようになりました。
ページ上部に主操作が集中しているため、
情報表示と操作領域を分けてください。
削除は頻繁に使用しないため、
通常の編集操作から離してください。
この構成はS3専用ではなく、
LambdaやAPI Gatewayにも展開できるようにしてください。
AIに依頼する際は、完成形を細かく指定するよりも、現在の問題点、利用者、操作の優先順位を伝える方が、良い提案につながると感じました。
そのため、今回の改善は次の組み合わせによるものだと考えています。
- GPT-5.6のデザイン生成能力
- スクリーンショットを使った比較
- 既存画面の問題点の言語化
- 複数回のレビューと修正
- 実際のReact画面での確認
- 過去のUI改善経験
AIを使ったUI改善で有効だった進め方
今回の経験から、AIを使って既存WebアプリのUIを改善する場合、次の流れが進めやすいと感じました。
1. 現在の画面を見せる
文章だけで説明するよりも、スクリーンショットを提示した方が、余白、配置、情報量などを理解してもらいやすくなります。
2. 問題点を自分でも書き出す
AIにすべて判断させるのではなく、現在感じている問題を伝えます。
例えば、次のような内容です。
- 操作ボタンが多い
- 情報の優先順位が弱い
- 初心者が迷いやすい
- 縦に長すぎる
- 他の画面と統一されていない
3. いきなり実装させず、先にレビューを依頼する
最初からコードを作成させるのではなく、まずは現在の画面をレビューしてもらいます。
レビュー内容を確認してから、採用する方針を決めます。
4. HTML・CSSで静的な案を作成する
Reactへ直接組み込む前に、静的なHTML・CSSでデザインを確認します。
この段階では、レイアウトや見た目の確認に集中できます。
5. 実際のアプリへ反映する
静的案をもとに、既存のReactコンポーネントへ反映します。
6. 実データで確認する
短いサンプル文字列だけでなく、長いリソース名、複数リソース、エラー表示なども確認します。
7. 共通コンポーネント化する
一つの画面で問題がなければ、他のAWSサービス画面にも適用します。
今後の予定
今回のS3画面の変更をもとに、次のサービスにも同様のデザインを展開する予定です。
- CloudFront
- API Gateway
- Lambda
- DynamoDB
- VPC
- EC2
- RDS
ただし、すべての画面を同じ形にするのではなく、共通部分とサービス固有部分を分けて設計していきます。
例えば、ページタイトル、操作ボタン、状態表示、設定セクションなどは共通化し、各AWSサービス固有の設定内容は個別コンポーネントとして管理する予定です。
まとめ
GPT-5.6を使って既存Webアプリのデザイン改善を行ったところ、GPT-5.5を使用していた頃よりも、UI全体の完成度が上がったように感じました。
特に、次の点で変化を感じました。
- 情報の優先順位が分かりやすくなった
- 主操作と副操作の区別が自然になった
- 余白や文字サイズのバランスが良くなった
- 単なる装飾ではなく、操作の流れを考えた提案が増えた
- 他画面への展開を考えやすい構成になった
一方で、AIが生成したデザインをそのまま採用できるわけではありません。
実際の業務要件、利用頻度、エラー状態、既存コンポーネントとの整合性などは、人間側で確認する必要があります。
今回の経験では、AIに完成品を作ってもらうというより、デザイナー兼レビュアーとして参加してもらう使い方が有効でした。
また、GPT-5.6の性能だけでなく、自分自身がUIの問題点を具体的に伝えられるようになったことも、完成度の向上に影響していると思います。
今後も、AIが作成した案をそのまま採用するのではなく、実際の操作性を確認しながら、Webアプリ全体のUIを改善していく予定です。