AIで作る業務UI/UX 01：受注一覧を作らせたら、やっぱりしっくりこなかった

業務でLunaに指示して、WebシステムのUIを作っています。でも、出てきた画面を見ると、なんかしっくりこない。

余白が想定より大きい。タブの幅や高さも大きい。色による区別が少なく、見分けにくいと感じる画面もあります。いまだに「これだ」と思える画面になっていません。

Normal表示の受注一覧。検索欄、ステータスの絞り込み、色付きのステータスラベルを備えた表

「そう、こんな画面ができるんよ。仕事でも」。架空の受注一覧を見ても、仕事で感じていた違和感が出ました。英語、余白、押せる場所。画面を見て8つの疑問を出し、Codexにコードと採用理由を確かめてもらいました。

実務とは無関係の検証用プロジェクトです。

Codexで約35分、最初の受注一覧を作った

CodexでGPT6.1Solを使い、約35分で最初の画面を作りました。検索とステータスの絞り込み、受注ID・顧客・金額・ステータス・納期・担当者の表。右上にはNormal／Compactの密度切替があります。

受注IDを押すと、右側に詳細が出ます。一覧と選んだ受注を同じ画面で見られる形です。

Normal表示の受注一覧を残したまま、右側に選択した受注の詳細を表示した画面

この2枚はどちらもNormal表示です。比較の入口になる画面はできました。ただ、自分でも「使いやすいUI」を判断する軸が決まっていません。

A画面はドロワー、B画面はポップアップ

AIに作らせると、画面ごとに違う方法が出てきます。どの条件ならドロワーで、どの条件ならポップアップなのか。全部そろえるのか、作業に合わせて変えるのか。そのルールが欲しい。

作っているWebシステムではReactと、C#やGoのWebAPIを使っています。React自体より、その上にどんな画面と操作を作るかで悩んでいます。文字を小さくするか、余白を詰めるか。リスト・表・カードのどれにするか。表をキーで移動し、詳細や編集をどこへ出すか。

社内システムの分かりにくさとOOUiについて書いた時から、一括処理やExcelライクな操作は考えています。それでも画面を作る段階では迷う。そこで、比較・試作のためのenterprise-ui-labを立ち上げました。

判断の手がかりにした資料と、最初に比べたかったこと

SalesforceやSnowflakeなどの情報の並べ方、密度、操作を手がかりにしたいと考えました。ChatGPTとの相談では、画面を一覧・検索、1件の詳細、大量入力、登録・編集に分け、一覧との見比べや入力の複雑さで表示方法を選ぶ案が出ています。製品全体の比較はこれからです。

Salesforceの公式ヘルプには、ラベルの位置と要素間の余白が異なるComfy／Compactがあります。Cloudscapeの設計指針でも、表・カード・Split viewを用途で選びます。Split viewは監視など一覧に追加の詳細が要る作業向けで、別の詳細ページで足りるなら使わない、という条件があります。

同じ16件で「青葉商事の未処理を探す」「金額上位3件を比べる」「未処理6件を選んでレビュー指定とUndo」「異なる2件の詳細を順に開く」を試す計画です。密度の順序も入れ替え、1440×900・ズーム100%を最初の候補に、ブラウザー・入力機器などをそろえます。この利用者比較は未実施。カード、別ページや行展開の詳細、大量入力、複雑なフォームも今後比べたいです。

ぱっと見で、8つの疑問が出た

見た目を眺めるだけでも引っかかるところがあります。コードへ戻ると、理由がある選択、理由が残っていない見た目、これから作る操作が混ざっていました。

1. 何で所々に英語があるのか

左には「PATTERNS」「Collection」「Record」「Workspace」「Task」。上には「EXPERIMENT 01 / COLLECTION」。項目や検索は日本語なのに、その周囲は英語です。

左メニューと受注一覧の見出し。英語の検証テーマ名と日本語の説明が混在している

コードに直接書いた検証パターンの名前でした。英語で画面に出す理由は記録されていません。「Collection」が受注を探す人に何を伝えるのか。コードや資料での名前を、そのまま見せてよいのかが気になります。

2. 説明文は、なぜその位置・色・サイズなのか

「探す、比較する、まとめて操作する。」を、なぜタイトルの直下に置くのか。文字は13px、共通の補助色#637087でした。実装値は分かっても、その場所とサイズを選んだ理由や、別案との比較は残っていません。

受注を探す時に要るのか、初めて見る時だけ役立つのか。説明があることより、置く理由を考えたいです。

3. Compactでも、画面全体の余白は縮まらない

表本文14pxを保ち、行高52px／36px、セルの縦余白10px／3pxを切り替える。文字を小さくする前に密度を比べる初期案です。

でも、変わるのは表だけ。メイン領域の左右は通常36px、広い幅では48pxのまま。ヘッダー、見出し、説明、検索、選択案内も一覧の前の領域を使います。表を詰めることと、作業領域を広げることは両方見たいです。

4. 行を押しても詳細が出ず、小さなIDを押す必要がある

顧客名や行の余白を押しても反応しません。IDはリンクのように見えますが実装はボタンで、押すと詳細へ進み、閉じると元のIDへフォーカスが戻ります。

設計上は、詳細を開くIDと、一括対象を選ぶチェックボックスを分けていました。その理由は分かる。でも、行クリックで詳細を開き、チェックボックスだけ分ける案はどうだろう。

W3CのTable Patternも、表の中のボタンなどを個別のTab移動の対象として扱います。行クリックを足す時にもキーで開けるボタンは残し、文字選択との衝突を考えたい。今はその使い比べの前です。

5. 左メニューを最小化・閉じる機能がない

通常208px、1150px以下では170pxのメニューが、常に幅を使います。700px以下では上へ移り、一部の説明や計画中の項目を隠しますが、閉じる操作はありません。

しかも、まだ計画中の画面や検証の問いも並んでいます。受注を探す間、この幅をずっと取るのか。ノートPCではもっと表に使いたいです。

6. ステータスの前の「・」は何なのか

丸はCSSの::beforeで描く5pxの円で、文字と同じ色でした。形や有無に別の業務上の意味はなく、文字と色付き背景に加えた装飾です。

付けた理由や見分けやすくなった結果は残っていません。よく見る形だから、で必要だと決めず、外した場合も比べたいです。

7. ノートPCの表示領域は妥当か。項目が増えたら？

Compactでも、上と左の領域は残ります。

Compact表示の受注一覧。ヘッダー、左メニュー、見出し、検索欄、選択案内があり、その下に受注の表が表示されている

今の6項目から増えたら、全部を一覧へ出すのか、詳細へ回すのか、列を選ぶのか。表は最小幅750pxで、足りなければ表内を横スクロールします。詳細は広い幅では右290px、1150px以下では一覧の下です。

列の切替・固定、メニュー開閉はまだなく、詳細も同じ6項目だけ。ノートPCの有効表示幅、ブラウザーのズーム、OSの拡大率、項目を増やした操作をそろえて試す必要があります。まずは画像を見て生じた疑問です。

8. なぜ最上部中央の検索バーにしなかったのか

検索はID・顧客・担当者で受注を絞るものとして、ステータスと一緒に表の直前に置いていました。最上部には名前と検証環境だけです。

Cloudscapeにも、上部ナビゲーションの任意の全体検索と、Table viewのText filterがあります。画面全体の検索と一覧の絞り込みを分ける例です。

受注だけを探す時も、ヘッダーへ置く案を試したい。対象、画面をまたぐ使い方、一覧を絞ると伝わるかまで見て、置き場所を決めたいです。全体検索と最上部中央への配置は、この時点では未実装でした。

16件の初期試作で決めた操作と、26件のテストで確かめた範囲

React・TypeScript・Viteで作り、架空の16件をMSWのHTTP APIモックから取得します。取得と表示を分け、一覧はHTMLのtable、検索・絞り込み・並べ替え・選択はTanStack Tableです。金額は右揃え、状態は文字と色で示します。バックエンド・DB・認証は未実装です。

  • 全選択は検索・状態の条件に合う受注だけ。条件変更で選択と詳細を解除し、並べ替えと密度変更ではIDに結び付いた選択を維持します。
  • レビュー指定とUndoは画面内の操作で、対象件数も通知します。再読込で消え、受注確定やサーバー保存は未実装です。
  • 詳細へフォーカスを移し、Escapeで閉じてIDへ戻ります。Tabで移動し、Spaceで選択、Enterで詳細や並べ替えを操作します。セル間の矢印移動や大量入力・貼り付けは今後の対象です。
  • 検証設定は通常、8秒遅延のLoading、0件のEmpty、HTTP 503のError。Errorの再試行は同じ設定なら失敗し、通常へ切り替えて戻します。未登録0件と検索一致0件を分け、後者には「条件をクリア」を出しました。

Codexのnpm run checkでlint・26件の自動テスト・型検査・ビルドが通りました。ORD-1048を選んで「北辰」と検索すると一括操作と全選択が解除され、金額順への変更では選択が残ります。検索と絞り込みの併用、レビュー指定とUndo、閉じた後のフォーカス、不正応答・通信障害、古いリクエストの完了による上書き防止、応答を正常に戻した再試行も対象です。

初期のChromium記録には、開発画面とビルド後プレビューで一覧、検索・選択・Undo・詳細、各シナリオを確認した結果があります。52px／36pxの切替、320px幅で表内の横スクロールと詳細の下配置も記録しました。探す時間・誤選択・見落とし・疲労感、読み上げ、タッチ、複数ブラウザー、実際の200%ズームは次に確かめる項目です。

密度・表・詳細・一括選択の採用理由と、文字を小さくする案、カード、別ページ詳細、非表示の選択を残す案もメモにしました。詳細の編集や関連情報が増えたら別ページ、多件数ならページ分割や検索を見直す、という再検討の条件も付けています。

「そういう設計です」の先を考えたい

8つをコードまで戻って見ると、全部を同じ理由では説明できませんでした。採用理由があるものもあれば、見た目だけで付いたものや、まだ作っていない操作もあります。

欲しいのは、説明や装飾がそろった画面だけではない。何をどこへ置き、どこを押せば何が起きて、限られた幅で何を比べられるのか。そこを自分で判断できるようになりたいです。

次は日本語、余白、行クリック、メニュー、列と検索を実際に変えて比べます。今の時点で疑問が出たことと、直した後の結果は分けて残します。

確認した情報

2026年10月3日、Windows上のWSL2のLinux側プロジェクトで、画面を見て疑問を出し、実装・検査はCodexへ任せました。本文の公式リンクは10月17日に再確認。初期16件のコード・設計理由・ブラウザー記録・検査ログを照合しています。

シリーズの記事

次の記事：AIで作る業務UI/UX 02：受注一覧の余白・検索・詳細を直し、15,000件で試した

「AIで作る業務UI/UX」の記事一覧（読む順）

コメント

タイトルとURLをコピーしました