最初の受注一覧では、表の行を詰めても、上と左の広い領域が残っていました。行を押しても詳細が出ない。メニューは閉じられず、検索位置も気になる。そこで、画面を見ながら順に直すよう頼みました。
同じ16件・行高・表本文の文字サイズで比べると、完全に見える行は標準で6行から8行、高密度で9行から12行へ増えました。その後15,000件へ増やすと、詳細と検索をまたやり直しています。機能を足すたび、一覧に使う領域を考え直すことになりました。
実務とは無関係の検証用プロジェクトです。2026年10月3〜4日、画面を見て指示し、実装・検査はCodexへ任せています。
行を詰めても、一覧の上と左は広いままだった
改修については、こう伝えました。
次画面の改善を進めつつ、それを記事にして。で失敗も失敗でログとして記事にするのはありだと思うので無茶苦茶無理する必要はない。
Normal/Compactで変わるのは、表の行高とセルの縦余白だけ。ヘッダー、固定メニュー、英語の小見出し、説明、選択案内は同じ領域を使っていました。

「探す、比較する、まとめて操作する。」を別の気の利いた文へ替えるより、小見出しと一緒に外しました。操作の説明は表の直前へ置き、未選択時の一括操作の帯も隠しています。
ヘッダーの最小高さは72pxから56px、本文上の余白は36→16px、見出しの下は25pxから12pxへ。表本文14px、行高52px/36px、IDの13px、状態の12pxは維持しました。文字を小さくせず、周りを変えてみます。
表示名は「標準」「高密度」にし、メニューと検証状態も日本語へ。ステータスの5pxの丸は外し、文字と背景色は残しました。
メニューを閉じると、一覧を広く使える
左の計画中の画面まで常設するのをやめ、初期状態を閉じました。ヘッダーの「メニューを開く/閉じる」で切り替え、開くと180px、閉じるとその幅を一覧へ戻します。検索・選択・詳細は維持します。

同じChromium・1366×768、架空の16件、検索・選択・詳細なし、一覧先頭で比べました。変更前は固定メニュー、変更後は既定の閉状態です。
| 表示密度 | 改修前に完全に入った行 | 改修後に完全に入った行 | 行高・表本文 |
|---|---|---|---|
| 標準 | 6行 | 8行 | 52px・14px |
| 高密度 | 9行 | 12行 | 36px・14px |
途中で切れた行は除外。表の上端は約380pxから267pxへ移り、改修後にメニューを開いても高密度は12行でした。説明・余白・メニューをまとめて変えた結果ですが、気にしていた「一覧の前に何が場所を取るか」が行数にも出ました。
一方、別画面への移動にはメニューを開く一手間が増えます。画面が増えた時にも閉状態がよいかは、また比べたいです。

行クリックと列の切替も試した
行クリックで詳細を開くようにし、キーボード用のIDボタンは残しました。Enterで開き、見出しへフォーカスし、Escapeや「閉じる」で元のIDへ戻ります。

チェックボックスやラベル、ボタンは行クリックから除外。文字の選択中も詳細を開きません。「青葉商事」を実際にドラッグして選び、通常クリックでは開くこと、レビュー指定とUndoも確認しました。次は押せる場所の迷いや、意図しない参照が出ないかを見たいです。
列はIDと選択欄を残し、ほかを「表示する列」で隠せます。最小の表幅も列に合わせて減らしました。

隠れた列も検索対象です。担当者を隠して「鈴木」を検索すると4件になり、条件は表の上に出ます。並べ替え中の列を隠したらID降順へ戻し、見えない値で並ぶのを避けました。
選択はIDで維持し、詳細は6項目を表示します。列設定は再読込やシナリオ変更で戻ります。次は20列、30列と増やし、列固定、長い値、多件数と入力も含めて比べたいです。
この時の検索は、左に状態、中央に「受注を検索」、右に件数と列設定。1150px以下では検索を上段全幅へ移しました。対象はID・顧客・担当者で、共通ヘッダーの検索は次の候補でした。
16件では足りないので、15,000件へ増やした
次は改善候補を推奨順で出し、3,000件を用意するよう頼みました。検討と作業を記録し、指示するまでコミットしない条件も付けています。次の指示欄は保存した履歴の要約です。
指示の要点:
受注一覧の使い勝手とUI/UXの改善候補を、推奨順で出して。
サンプル16件だけでなく、実業務を想定した3,000件のデータを作って。
検討したことや作業内容は、備忘録として残して。
候補は、ページ分割、見出し・ID列固定、日付・金額・担当者の絞り込み、検索入力、条件解除、全選択の範囲、詳細拡張、CSVの8案。その後、条件を増やしました。
指示の要点:
テストデータは5年分。1年3,000件で、計15,000件を用意して。
これだけあれば実業務のスタートラインでしょ。
提案した改善案1から8まで進めてみて。
生成した固定データは重複のない15,000個の受注IDを持ち、種を固定した乱数で生成しています。約5年分で、年ごとの件数にはばらつきがあります。古い受注は出荷済み・キャンセル中心、最近は未処理・処理中も混ぜた試作用の分布です。
起動直後から15,000件を使い、毎回切り替える手間も減らしました。基本操作のテストには16件を残しています。
ページ分割・全選択・検索入力で変えたこと
初期表示は25件、50件・100件へ変更できます。「1 / 600」は15,000件を25件ずつ表示したページ数です。まずページ内を選び、必要なら「条件に一致する全件を選択」へ進む2段階にしました。検索・絞り込み変更では選択と詳細を解除します。
列見出しと左端の選択欄・IDを固定し、担当者・納期・金額の条件と個別解除、詳細の前後移動、CSV出力も追加しました。仮想スクロールとの比較は今後の対象です。
検索の候補だったデバウンスはuseDeferredValueへ変わりました。入力値と絞り込みへ渡す値を分け、結果更新を後回しにします。一定時間待つデバウンスとの違いはReact公式でも確認しました。入力処理時間は未測定です。
全15,000件を受け取り、ブラウザーで検索・並べ替え・ページ分割します。使用版のTanStack Tableガイドにあるクライアント側の方式です。必要なページ分だけ返すAPIは未実装で、表示行を減らしても全件取得の負担は残ります。
詳細の狭さと、上部の余白をまた指摘した
機能を増やすと、また気になる箇所が出ました。挙げた指摘も対応すべきか評価するよう頼んでいます。
指示の要点:
すべて修正して。
私からの指摘も、対応すべきかレビュー・評価して。
・上段と下段の検索結果件数を、カンマ区切りにしてほしい。
・詳細表示が小さく、「受注詳細」が縦に並んでいる。
GitHubのように、一覧を見せたまま手前へ出す形ではだめなのか。
・標準/高密度の切替が大きい。なぜ2行なのか。
・受注一覧のタイトルの余白が多くないか。
・画面最上部中央に検索バーを設けない理由は何か。
最初の詳細は横290pxのSplit Viewで、文言が縦に詰まっていました。これを右手前へ出すドロワーに変更。通常520px、拡張900pxで画面幅に応じた上限を付け、背景の一覧と前後移動を残しました。
「全画面」というボタン名でも、実装は900pxまで広げる動作です。呼び名と動作は見直したい。今回の画像は閉状態なので、新しいドロワーは次のスキル適用の記事で見られます。
件数は15,000のカンマ区切り、密度切替は横1行へ。タイトル周りも再圧縮しました。一度詰めた余白も、部品を足すと見直すことになります。
検索を一覧内に置く理由はあった。それでも上へ移した
一覧内の絞り込みだから表の前へ置く。最初は画面をまたぐ対象・遷移・状態管理が未定で、共通ヘッダーや全体検索を範囲に入れませんでした。
でも、検索・ステータス・詳細条件・CSV・件数・列設定が表の前に集まり、最上部中央は空いています。

最終的に検索を最上部中央へ移し、ヘッダーを固定しました。ID・顧客名・担当者を探すと伝わる文言を付けています。対象は受注のままです。

最初の理由は理解できても、部品が並んだ画面を見ると別の置き方を試したくなる。今回の中央配置も、次の全画面へ無条件に使う基準にはしたくありません。
改修中の失敗と、32件・38件の検査で分かったこと
ラベルを日本語へ変えると旧名を探すテストが7件失敗しました。文字選択のテストでは、空の選択範囲が残って新しい範囲が入らず、範囲と文字を確かめ直しました。実ブラウザーのドラッグも別に確認しています。
31件の操作テストが通った後には、ビルドが失敗しました。
error TS2769: No overload matches this call.
'exact' does not exist in type 'ByRoleOptions'.
PlaywrightのオプションをTesting Libraryへ混ぜた、確認コード側の間違いです。型検査まで含めて見つかりました。
8秒遅延の連続確認では、一度JSON以外の応答でUnexpected token '<'が出ました。単独再試行は約8.5秒で復帰し、最後も両密度で復帰しましたが、その一度の原因は未確定です。「受注データの形式が正しくありません。」を表示する処理とテストを追加し、表示を直しました。
10/3の最終検査はlint・32操作テスト・型検査・ビルドが成功。両密度で読み込み中・0件・HTTP 503・再試行・通常復帰、320/720pxで表内スクロールと詳細の下配置を確認。axeの13状態で違反0件でしたが、重なった色や空の表など自動判定できない項目は目視が必要です。
15,000件版には10/4にnpm run checkを1回実行し、静的検査・38操作テスト・型検査・ビルドが成功。25件から次ページで「26〜50件」「2 / 600」、50件表示で「1 / 300」、担当者と金額の併用・条件解除・詳細の前後移動を確かめています。
CSVはダウンロード処理の呼出しまでで、コードはUTF-8 BOM付き。Excelで開く確認は残っています。この版のaxeはjsdom上でコントラスト判定を除外。読み上げ・拡大・実ブラウザーの色、検索時間・誤操作・長時間の疲れは今後の対象です。固定データを含むモックの大きなチャンクにはビルド警告も残りました。
件数と、押した後の対象も確かめたい
コードの「納期遅延」は、バッジの集計では出荷済み・キャンセルを除き、タブの絞り込みは日付だけでした。基準日を10/3に固定した15,000件へ条件を当てると430件と14,847件。この時点ではコードからの計算値で、実画面での確認は次の回です。
日付・金額範囲はURL同期の対象外、一括変更は画面内だけでサーバー保存はこれから。プリセットの件数・条件・タブ表示、ページをまたぐ詳細と閉じた後の戻り方、ノートPCの窮屈さ、項目増加、キー操作や再読込後の条件も引き続き見たいです。
この画面を、次の生成の正解にはしない
表示行は増えましたが、画面を増やすたびメニューを閉じ、検索を中央へ置くルールにはしたくありません。
CodexにAGENTS.md・スキル・ガイドラインの改善を調べさせると、短い必須条件、利用者のタスク・表示幅・比較項目・検索対象を先に決める手順、配置理由付きの例とブラウザー確認へ分ける案が出ました。AGENTS.mdの公式説明、スキルの公式説明も参照しています。
この段階は調査案です。同じ依頼から初稿を作って手戻りが減るか、これから比べたい。余白・色・表示形式・操作の何に引っかかったのかを、自分で判断できるようにしていきたいです。
確認した情報
10月3〜4日のWSL2上のコード・設計理由・固定データ・指示履歴・検査ログを照合。指示は引用と要約を分けました。公式資料は10月17日確認。検索移動前の画像は3日、移動後は4日で、撮影条件は異なります。表示行数の比較条件は16件・1366×768の表のものです。
シリーズの記事
前の記事:AIで作る業務UI/UX 01:受注一覧を作らせたら、やっぱりしっくりこなかった
次の記事:AIで作る業務UI/UX 03:UI/UX Pro Maxを導入。操作は直ったが、表示行は増えなかった
「AIで作る業務UI/UX」の記事一覧(読む順)
- AIで作る業務UI/UX 01:受注一覧を作らせたら、やっぱりしっくりこなかった
- AIで作る業務UI/UX 02:受注一覧の余白・検索・詳細を直し、15,000件で試した(この記事)
- AIで作る業務UI/UX 03:UI/UX Pro Maxを導入。操作は直ったが、表示行は増えなかった
- AIで作る業務UI/UX 04:UI/UX Pro Maxで受注一覧v2を作った。でも、まだしっくりこない
- AIで作る業務UI/UX 05:受注一覧v3をExcel・TUIに寄せた。でも、まだ惜しい

コメント