コンテンツにスキップ
画面の分け方と遷移の設計ガイド Webアプリの画面の分け方と遷移の設計ガイド

関連するガイド・文献

このガイドで紹介する文献は、次のような実務的な観点でこのガイドと近いものを選んでいます。

  • UI とデータ構造をどう一致させるか
  • 画面の切り口をどう評価するか

そのため、UI 設計ガイド（Apple HIG、Material Design、OOUI など）と、API 設計や画面とデータの整合性を扱うガイド（Google API Design、GitHub など）の両方を含みます。

紹介の観点

Section titled “紹介の観点”
観点参照しやすいガイド・文献
UI の構造・画面の生成原理Apple HIG、Material Design、Microsoft Fluent / UWP
画面分割の意味OOUI、UX 設計の古典（Don’t Make Me Think など）
API と UI の整合性Google / GitHub の API Design Guides
操作モデルの分離（属性／状態／業務）CQRS / Command-first API 系の解説
実務的な UI + API ガイド有志の「API を UI から設計する」系ガイド

以下、カテゴリごとに簡潔に紹介します。

1. Human Interface Guidelines / Design Systems（プラットフォーム）

Section titled “1. Human Interface Guidelines / Design Systems（プラットフォーム）”

Apple / iOS Human Interface Guidelines

Section titled “Apple / iOS Human Interface Guidelines”

画面構造の原則、モーダルの使いどころ、遷移の一貫性、検索・一覧・詳細・編集の統合をきちんと定義しています。REST とは無関係ですが、ユーザー認知を基準にした UI の構造化という点で、このガイドと方向性が近い指針の1つです。

Google Material Design Guidelines

Section titled “Google Material Design Guidelines”

切り口の視点、画面の役割、階層 vs モード vs フロー、UI の増殖を防ぐ原則といった観点で設計パターンを多く提供しています。UI が主体なので REST とは別ですが、画面分割の良い指針として参照しやすいです。

Microsoft Fluent Design / UWP UI Guidelines

Section titled “Microsoft Fluent Design / UWP UI Guidelines”

一覧ビュー、詳細ビュー、コンテンツの階層とモーダルの意味を、API ではなく画面設計の構造として定義しています。「分けるべきでない画面」「分けるべきとき」の指針を持っています。

2. OOUI（オブジェクト指向 UI）系

Section titled “2. OOUI（オブジェクト指向 UI）系”

オブジェクト指向UIデザイン（上野学・藤井幸多 著、技術評論社）や ソシオメディアのヒューマンインターフェース ガイドラインなど、OOUI を提唱する人たちは次のような設計観を持っています。

OOUI 自体は REST とは独立した UI 理論ですが、このガイドは OOUI を背景に持っているため、思想がよく重なります。

3. REST + UI の実務ガイド

Section titled “3. REST + UI の実務ガイド”

単純な REST API 設計ではなく、UI 側の切り口「どの画面で何を操作するか」「画面構造と API の一致」という観点でまとめられたガイドがあります。

  • API を UI からまず設計する
  • API を screen map と一致させる
  • Route ⇔ View の整合性

といった流れで書かれた、実装者向けの「REST API Design — UI Driven」系の資料を探すと、このガイドの考え方と近い内容が見つかります。（特定の公式 URL ではなく、有志のブログ・スライド等をキーワードで検索する形になります。）

4. Steve Krug / Don’t Make Me Think（UI 設計の古典）

Section titled “4. Steve Krug / Don’t Make Me Think（UI 設計の古典）”

REST とは別の書籍ですが、無駄な画面増殖を避けるという観点で影響が強い古典です。このガイドが述べていることは、本質的にはそのAPI・画面構成版に当たる部分があります。（書籍のため、公式の無料ガイド URL はありません。）

5. Google / GitHub の API Design Guides（実務 API ガイド）

Section titled “5. Google / GitHub の API Design Guides（実務 API ガイド）”

純粋な REST 原理（リソース中心、状態遷移はリンクで表す）だけでなく、UI との整合性を明示している記述があります。

といった整理は、このガイドの「内容更新／状態更新／業務操作の分離」と一致します。

6. CQRS + UI / Command-first 系

Section titled “6. CQRS + UI / Command-first 系”

操作モデル（Command）を先に書くという観点のガイドでは、次のような分類を前提に設計します。

  • 属性 update → content
  • 状態 update → state
  • 業務操作 → command

これはこのガイドの「状態と操作を分離する」で述べている**属性更新（内容）／状態変更（状態）／業務操作（approve / submit など）**の分離とほぼ同じです。（CQRS / Command-first の解説は各技術ブログ・書籍に分散しているため、ここでは特定の URL は挙げていません。）

なぜこれらが近いか（共通する思想）

Section titled “なぜこれらが近いか（共通する思想）”

このガイドの思想は、次の三点で一貫しています。

  • UI は切り口で考える → 都合による画面増を避ける
  • 操作は意味で分類する → 属性 update / 状態 update / 業務操作
  • API は意味を反映して名前にする → REST だけに縛らず、command-style も容認する

純粋な REST 教義（リソース至上・HATEOAS 黄金道）とは異なります。

UI の認知単位と API の意味単位を一致させる

という実務設計者寄りの主張です。つまり「REST は正しいが、画面設計とそのまま同期するものではない」という立場を取っており、上で挙げたガイド（UI 設計系 + 実務 API 設計系）はいずれもこの思想と相性が良いものです。

さらに形にしたい場合

Section titled “さらに形にしたい場合”

このガイドの考え方をチームで共有しやすくするには、次のような設計テンプレに落とし込むと伝わりやすくなります。

  • 画面分割の判断基準
  • 操作の 3 分類（属性／状態／業務）チェックリスト
  • REST / 非 REST API 分類表
  • RESTとルート設計の「ルートでUIの健全性を診断する」のチェックリスト

必要に応じて、チェックリスト・マトリクス・フロー図・具体例付きガイド（CRUD と非 CRUD の比較）など、チームに合う形で整えるとよいでしょう。