データが多いシステムほど、テーブルや一覧画面の設計に苦労する。
社内の業務管理ツールをリニューアルするプロジェクトで、Google Stitch を使って大量の列を持つデータテーブルを設計した。最初に試したプロンプトは「ユーザー管理画面のテーブル」だった。生成された画面を見て、「全然足りない」と気づいた。
列が多すぎて横にはみ出す。行の高さが狭くて文字が読みにくい。ソート列のインジケーターがわからない。固定列の設計をどう示せばいいかわからない——そういう「データテーブル固有の問題」が次々と出てきた。
この記事では、Stitch でデータテーブル・一覧画面を設計した経験から、「情報の密度と読みやすさを両立させる」ための考え方と、Stitch でのプロンプトの書き方を整理して紹介する。
結論から言うと
データテーブル設計の核心は、「すべての情報を一度に見せようとしないこと」だ。列の優先度を決め、重要な列を目立つ位置に固定し、詳細は行のクリックで展開する——この「情報の優先度設計」を最初に整理してからプロンプトを書くと、Stitch の生成精度と設計の完成度が大幅に上がった。
データテーブル・一覧UIの基本要素
データテーブルとは何か
データテーブルとは、複数のレコード（行）を複数の属性（列）とともに表形式で表示するUIコンポーネントのことです。ユーザー管理画面、注文一覧、ログ表示、CRM の顧客リスト、在庫管理画面——データを一覧で管理・操作するあらゆる業務システムで使われる。
データテーブルの主な構成要素は以下の通りだ。
- ヘッダー行：各列の名前を表示。クリックでソートできる列にはソートアイコン付き
- データ行：実際のレコードを1行1件で表示
- チェックボックス列：複数行を選択して一括操作するための列
- アクション列：各行に対する操作ボタン（編集・削除・詳細など）を配置する列
- ページネーション：データが多い場合にページ分割または無限スクロールで表示する
- 固定列：横スクロール時に常に表示し続ける列（ID・名前などの識別列）
Google Stitch でテーブルを生成するときの基本
Stitch のデフォルト設定ではテーブル（table タグ）の生成は制限されており、Markdown のテーブル記法がそのまま HTML テーブルにならない。Stitch はテーブル形式のデータを箇条書きや div レイアウトで代替することがある。
ただしビジュアルデザインとして「テーブルに見える画面」は生成できる。「ユーザー管理画面。5列（ID・名前・メールアドレス・権限・登録日）×10行のテーブル。ヘッダー行に薄いグレー背景。偶数行に交互の背景色（ゼブラストライプ）」と指定することで、テーブルらしい見た目のデザインが生成できた。
詰まった点1：列が多すぎて横にはみ出す問題
「全部の列を一画面に収めなくていい」という判断
業務システムのテーブルは列が多くなりがちだ。ユーザー管理画面の場合、ID・氏名・メールアドレス・電話番号・住所・権限・最終ログイン日時・登録日・ステータス・備考——こんな列数になることも珍しくない。
これを全部一画面に収めようとすると、各列が極端に狭くなって文字が読みにくくなる。画面が「文字の壁」になる。
この問題への対処法として使ったのが「列の優先度付け」だ。
- 必須表示列（常に見える）：ID・氏名・ステータス・アクション
- 重要列（横スクロールで見える）：メールアドレス・権限・最終ログイン日時
- 詳細列（行クリックで展開して見る）：住所・電話番号・備考
この優先度を決めてから Stitch にプロンプトを書いた。「ユーザー管理テーブル。必須表示の4列（ID・氏名・ステータス・アクションボタン）を左側に固定。右側は横スクロールで追加列を見られる構造。行クリックで詳細ドロワーが開く」
このプロンプトで生成した画面は、「情報の優先度が反映されたテーブル」に近い見た目になった。固定列の視覚的な区切り（縦の影・ボーダー）も含めてプロンプトに指定することで、意図がより正確に伝わった。
「コンパクト」「通常」「ゆったり」の3密度バリエーションを生成した
テーブルの行の高さ（情報密度）は、ユーザーと用途によって最適値が変わる。
- コンパクト（密度高）：1画面に多くのレコードを表示したい大量データの管理作業向け
- 通常：汎用的。多くの業務システムで採用される標準的な行高
- ゆったり（密度低）：各行にアバター・サムネイルを含む場合や、タッチ操作が想定される場合
Stitch で「コンパクト・通常・ゆったりの3バリエーションを横並びで生成」と指定した。3パターンを並べてレビューすることで、「このシステムには通常密度が合う」という合意をチームで素早くとれた。
詰まった点2：ソート・フィルターとテーブルの統合
ソート列の「現在どの列でソートしているか」の可視化
テーブルのヘッダー列をクリックでソートできる設計の場合、「今どの列で・どの向きにソートしているか」をユーザーに常に示す必要がある。
一般的な表現方法は、アクティブなソート列のヘッダーを強調表示（太字・色付き）し、ソートアイコン（▲昇順・▼降順）を表示することだ。
Stitch でプロンプトを書くとき、「登録日列でソートされている状態。登録日のヘッダーが青色・太字で、右側に▼アイコンが表示されている（降順）。他の列のヘッダーは通常スタイル」と具体的に指定した。「ソートされている状態」を特定の列・特定の方向で明示すると、意図した状態の画面が生成できた。
テーブル上部の「検索 + フィルター + エクスポート」バー
業務システムのテーブルには、テーブル本体の上部に操作バー（ツールバー）を設けることが多い。左側にインライン検索欄、真ん中にフィルターボタン、右側にエクスポート（CSV出力）ボタンやカラム表示切り替えボタンを配置する構造だ。
Stitch でプロンプトを書くとき、「テーブル上部のツールバー。左に検索入力欄（プレースホルダー：名前・メールで検索）、中央にフィルターボタン（アイコン + フィルター）、右にCSVエクスポートボタン・列表示設定ボタン」と詳細に指定した。この指定でほぼ意図通りのツールバーが生成できた。
詰まった点3：モバイル対応とレスポンシブテーブル
スマートフォンでテーブルは見せるべきか
多列テーブルをスマートフォンでそのまま表示すると、非常に小さな文字が横に並んで実質的に読めない状態になる。業務システムの場合、スマートフォンアクセスを想定しているかどうかを設計段階で明確にする必要がある。
モバイルでの主な対応パターンは3つある。横スクロール型（テーブルを水平スクロールで見せる）、カード型変換（各行をカード形式に変換してリスト表示する）、重要列のみ表示型（スマートフォンでは必須列のみ表示し、詳細は行タップで展開する）だ。
Stitch でモバイル版の対応を設計するとき、「スマートフォン版ユーザー一覧。テーブルではなくカード型リストに変換。各カードに氏名・ステータス・最終ログイン日時を表示。カードをタップすると詳細画面に遷移」というプロンプトを書いた。モバイルで別のUIパターン（カード型）に切り替える設計を Stitch で生成し、PC版テーブルと並べてレビューすることで、レスポンシブ方針の合意が取りやすくなった。
「行展開」によるインライン詳細表示
テーブルの行をクリックすると、別画面に遷移するのではなくその行の下にアコーディオン形式で詳細情報が展開するパターンがある。詳細情報を見るための画面遷移コストを下げつつ、テーブルの一覧性を保てる設計だ。
Stitch で「3行目の行が展開した状態。行の下に詳細パネルがアコーディオン展開されており、住所・電話番号・備考・操作ボタンが表示されている」と指定した。このプロンプトで「通常行」と「展開行」が混在した状態のデザインが生成でき、行展開の設計を視覚的に確認できた。
Stitch でデータテーブルを設計するときの実践ポイント
「データが少ない状態」「データが多い状態」「ゼロ件状態」の3パターンを作る
テーブルUIは、表示するデータ量によって見え方が大きく変わる。3〜5件のデータが入った状態だけ確認して「完成」にすると、実際に100件以上のデータが入ったときに行が詰まりすぎる問題や、ページネーションのデザインが考慮されていないことに後から気づく。
必ず「3件の少ないデータ状態」「20件の標準状態」「空の状態（0件）」の3パターンを生成して確認する習慣をつけた。Stitch の無限キャンバスに3パターンを横並びで生成することで、設計の完全性をチームで確認しやすくなった。
チェックボックスで複数行選択した状態も設計する
「チェックボックスで5行選択した状態。テーブル上部のツールバーが変化して『5件選択中』の表示と『一括削除』『一括エクスポート』ボタンが現れる」というプロンプトで、一括操作のUIも生成できた。この「選択状態のUI」は忘れがちだが、業務システムでは頻繁に使われる重要な状態だ。
FAQ
Q1. Google Stitch でデータテーブルの「固定列」は表現できますか？
静的なデザインとして表現できます。「左から2列（チェックボックス列・氏名列）が固定されており、縦の影でその右側から横スクロール可能なことを示している」と指定すると、固定列の視覚的な区切りを含むデザインが生成されます。実際の固定スクロール動作はCSSのposition:stickyで実装します。
Q2. テーブルの行数は何行程度を表示するのが標準的ですか？
1ページあたり10・25・50・100件から選択できるページネーションが一般的です。デフォルトは25件が多く使われています。「表示件数を選べるセレクトボックス」をページネーション近くに配置する設計も広く使われています。ユーザーが1回のスキャンで把握できる行数は認知心理学的に7±2と言われることがありますが、業務システムでは一覧性を重視して25件以上表示することが多いです。
Q3. Google Stitch で生成したテーブルデザインを実装するためのライブラリはありますか？
はい、代表的なものとしてTanStack Table（React/Vue/Svelte対応の高機能テーブルライブラリ）、AG Grid（エンタープライズ向けの高機能グリッドコンポーネント）、Material-UI や Ant Design のデータテーブルコンポーネントなどがあります。Stitch のデザインをこれらのカスタマイズ参照として使い、スタイルをCSSで当てる方法が効率的です。
Q4. 数千行のデータがあるテーブルに特有の設計上の注意点はありますか？
大量データのテーブルには「仮想スクロール（Virtual Scrolling）」の実装を検討することをお勧めします。全行を一度にDOMに描画するとパフォーマンスが低下するため、表示領域に入っている行だけを描画する技術です。Stitch のデザインでは「5,000件のデータを表示中。仮想スクロール実装前提」とコメントを書き添えておき、開発チームに仕様を伝えることをお勧めします。
Q5. テーブルの列の表示・非表示をユーザーがカスタマイズできる機能は設計段階で考えますか？
業務システムで特に有効な機能です。「列表示設定」ボタンをツールバーに置き、ドロップダウンで各列の表示・非表示をチェックボックスで選べる設計が一般的です。Stitch で「列表示設定パネルが開いた状態。各列名にチェックボックスが並んでおり、住所と備考列が非表示（チェックなし）の状態」として生成すると、この機能の設計を視覚的に確認できます。
Q6. テーブルのインライン編集（セルを直接クリックして編集できる）はどう設計しますか？
インライン編集が必要なセルは「クリックすると入力フィールドに変わる」ことをデザインで示す必要があります。Stitch で「氏名セルが編集モードになった状態（テキスト入力フィールドに変わっており、保存・キャンセルボタンがセルに表示されている）」として生成すると、インライン編集の見た目を確認できます。インライン編集を多用する設計では、「どのセルが編集可能か」を視覚的に示すカーソルスタイル（クリック可能なセルにはペンカーソル）も合わせて設計することをお勧めします。
注意点・失敗しやすいポイント
1. テーブルは「ハッピーパスだけ作って終わり」にしやすい
通常のデータが入った状態だけ作って設計が完成したと思いがちだ。空の状態、データが少ない状態、特定のセルに長文が入った状態、数値が桁あふれた状態——実際の使用シーンで起きるエッジケースを Stitch で生成して確認する工程を入れること。特に「長い氏名や会社名が入ったとき、列幅はどう振る舞うか」は設計段階で決めておかないと実装で混乱する。
2. アクション列は「右固定」が基本だが例外もある
「編集・削除」のアクションボタンを配置するアクション列は、横スクロールがある場合に右側に固定することが多い。ただし「最も重要なアクションが1つだけ（例：『詳細を見る』）」の場合は氏名列の直後に置く方が使いやすいケースもある。アクション列の位置は使用頻度と重要度から判断すること。
3. ページネーションと「全件表示」の設計を忘れない
ページ切り替えのページネーションと「〇件中〇〜〇件を表示中」の件数表示は、テーブル下部に必ず含める設計をすること。「ページネーションがないテーブル」は、データが増えたときに画面が無限に伸び続けるか、データが途中で切れて「全部表示されているのか」がわからなくなるリスクがある。
まとめ
データテーブルを Google Stitch で設計してわかったのは、「情報の密度と読みやすさの両立」は、設計者が「何を見せて、何を隠すか」を先に決めることでしか達成できないということだ。
全情報を一度に見せようとすると、何も見えなくなる。重要な情報を優先し、詳細は必要なときに展開する——その判断が、テーブルUIの使いやすさを決める。
Stitch で「必須列 + 重要列 + 詳細の3層」という列の優先度設計をプロンプトに落とし込んでから、テーブルの設計プロセスが格段にスムーズになった。データが多い画面を設計するときは、まず「何を常に見せ、何を折り畳むか」を決めることから始めてほしい。
