認証、役割、設定、請求、監査/ヘルプ、エラーを含む実践的な12画面の設計図で、ビジネスアプリの再利用可能な画面を解説します。

多くのビジネスアプリは一見シンプルに聞こえます:「ユーザーがログインして、レコードを追加し、レポートを出力する」。時間のかかる部分はそのコアの周りにあるすべてです。チームは同じ基本的な画面を何度も作り直し、毎回少しずつ違う選択を積み重ねます。
遅延の原因は大抵、繰り返しです。ある人がログイン画面を設計し、別の人が管理領域向けにもう一つ作り、さらに別の人が「パスワードを忘れた」フローを追加して挙動が異なる――設定、役割、請求、ヘルプ、エラー状態でも同じことが起きます。繰り返すたびにQAが増え、エッジケースが増え、小さなUI差異がユーザーを混乱させます。
繰り返される画面はまた、早期に見つけにくいバグも生みます。権限画面では役割を割り当てられるのに、招待画面では同じルールを強制していないことがあります。請求画面は上限を示しているのに、アップロードフォームがなぜ上限に達したのか説明していないこともあります。アプリは動きますが、雑然とした印象を与えます。
再利用可能な画面の設計図(blueprint)は、多くのビジネスアプリが必要とするデフォルト画面の共有セットで、明確な挙動とコンテンツルールを持ちます。白紙から始める代わりに、実績のあるビルディングブロックからスタートし、本当に固有な部分だけを調整します。
これは創業者、小さなチーム、プロダクトオーナー向けです。早く出荷したいが手を抜きたくない人に。Koder.aiのようなチャット優先のツールで構築する場合、このような設計図は明確なプロンプト作成とプロダクト全体での一貫性に役立ちます。
再利用可能な画面は再利用可能なコンポーネントより大きな概念です。コンポーネントは部品(ボタン、テーブル、モーダル)です。再利用可能な画面は「Manage users」や「Billing」のように多くのアプリで同じ仕事をこなす1ページ分です。明確な目的、馴染みあるレイアウト、予測可能な状態を持ちます。
画面を再利用可能にするために、ユーザーが再学習する必要のない部分を標準化します:
一方で、変わる部分は柔軟にしておきます。設定画面は構造を共有しつつフィールドを製品ごとに変えられます。役割画面は同じパターン(役割リストと権限マトリクス)を保ちつつ実際の権限はドメインによって異なります。請求は異なるプラン、使用量上限、税金、通貨に対応できる余地が必要です。ブランディングは画面を書き直さずに入れ替え可能であるべきです。
これが12画面の設計図が有効な理由です:各画面を一度だけ記述し、小さなCRMのような実際のアプリにはフィールド、役割、プランルールを少し変えるだけで適用できます。
一連の画面をコピーできるように用意しておくと、新製品が毎回ゼロから始まるようには感じません。コツはこれらを個別作業としてではなく、1つのつながった道筋として扱うことです。
シンプルな流れはこうです:新しいユーザーがサインアップしてログインし、短いオンボーディングを済ませ、プロフィールを更新し、チームを招待して役割を設定し、設定を調整し、(有料なら)プランを選んで使用状況を監視する。何かがおかしければ監査ログを確認するかヘルプを開きます。
| 画面 | MVPか? | 機能するための最小データ |
|---|---|---|
| 1) ログイン | 必須 | メール/ユーザー名、パスワード、セッション/トークン |
| 2) サインアップ | 必須 | メール、パスワード、利用規約同意フラグ |
| 3) パスワードリセット | 必須 | メール、リセットトークン、新パスワード |
| 4) オンボーディング(初回) | 必須 | 組織/ワークスペース名、デフォルト設定 |
| 5) プロフィール | 必須 | 表示名、メール、任意のアバター |
| 6) チームメンバー | 任意 | ユーザー一覧、招待メール、ステータス(保留/有効) |
| 7) 役割と権限 | 任意 | 役割名、権限セット、ユーザーと役割の紐付け |
| 8) 設定(アプリ/組織) | 必須 | 現在の設定値、保存/更新エンドポイント |
| 9) 請求とプラン | 任意(有料なら必須) | 現在のプラン、価格、支払い方法の状態 |
| 10) 使用状況と上限 | 任意(制限があるなら必須) | 使用カウンター、上限閾値、リセット日 |
| 11) 監査ログ | 任意 | イベント一覧(誰/何/いつ)、基本フィルタ |
| 12) ヘルプとサポート | 任意 | FAQ項目、連絡手段、チケット/メッセージ欄 |
小さなMVPでも、どれを先に出すかは早めに決めてください。マルチユーザーなら通常はTeamとRolesが必要です。料金を徴収するならBillingが必要です。上限を課すならUsageが必要です。その他はシンプルに始めて後で拡張できます。
認証は最初の信頼の瞬間です。混乱したり安全でないと感じると、ユーザーは製品を見る前に離れてしまいます。
ページをシンプルに保つ:メール(またはユーザー名)、パスワード、明確なボタン一つ。サポート対応を減らしつつ煩雑にならない小さな改善を加えます。
追加するなら次を優先してください:パスワード表示の切替、認証失敗時の明確なエラーテキスト、「メールでパスワードを尋ねることはありません」のような短いセキュリティ注意書き。アプリが主に個人端末で使われるなら「ログイン情報を記憶する」は有効です。SSOはしっかりサポートできるなら導入します。
サインアップは販売方法に合わせます。公開製品はメール認証付きのオープンな登録が向きます。チーム向けツールは招待制が合うことが多く、「管理者に招待を依頼してください」のようなメッセージで行き止まりを避けます。
パスワードリセットは安全で予測可能にします。メールの存在を確認する表現は避け、例えば「該当するアカウントがあればリセットリンクを送信しました」のようにします。手順を短く:リクエスト、メール、新パスワード、成功。
ロックアウトや疑わしいアクティビティには、助けになる落ち着いた対応を。試行回数超過後は「15分後に再試行するかパスワードをリセットしてください」で十分な場合が多いです。リスクのあるサインインを検出したら簡単な検証ステップを促し、一言で何が起きたかを説明します。
オンボーディングはアプリが「簡単に感じるか」「面倒に感じるか」を決める場所です。初回は短く:歓迎を示し、スタートに必要なことだけ尋ね、任意のステップは「今はスキップ」を分かりやすくします。必須項目は(利用規約承認やワークスペース選択など)平易に伝えます。
有効なルール:"使い始めること" と "完璧にすること" は分ける。ユーザーがすぐに作業を始められるようにし、後で補完を促します。
一画面に収まる小さなステップを目指します。多くのアプリでは次が適切です:
プロフィール画面は名前、メール、アバター、タイムゾーン、言語をカバーします。パスワード変更やセッション/デバイスの管理はセキュリティ項目の近くに置き、見つけやすくします。
マルチワークスペースをサポートする場合、トップバーとプロフィール/設定内の両方に明確なチーム切り替えを入れます。ユーザーは自分がどこにいるか、どう切り替えるか常に分かるべきです。
ログアウトとセッションタイムアウトの位置も意図的に。ログアウトはプロフィールメニューが一般的です。セッションが切れたときは「操作によるサインアウトでした。再度ログインしてください。」のように理由を説明する方が無言のリダイレクトより親切です。
多くの「セキュリティ」問題は実はUIの問題です。誰が何をできるか見えなければ人は推測します。再利用可能な役割とユーザー領域はその推測を排し、ほとんどのチームアプリに適合します。
まずは役割画面を用意し、シンプルな役割リスト(Owner、Admin、Member、Viewer)と短い説明を平易な言葉で示します。これに権限マトリクスを組み合わせ、行をアクション(例:「レコードを見る」「エクスポート」「請求管理」「ワークスペース削除」)にし、列を役割にします。チェックマークを使い、アクションをいくつかのカテゴリにまとめ、必要な箇所にだけ小さなツールチップを付けて読みやすくします。
ユーザー管理はデータベースのようであってはいけません。受信トレイの感覚で、各ユーザーに明確なステータスバッジ(Active、Invited、Pending approval、Suspended)を付け、招待(役割付き)・再送・役割変更(確認付き)・削除(「データはどうなる?」の文言あり)・最終アクティブ日といった高速アクションを用意します。
アクセス要求が必要なら軽量に:"Request access" ボタン、短い理由欄、承認キューだけで十分です。
ガードレールも重要です。請求関連権限、ワークスペース削除、所有権移譲はOwnerのみが行えるようにします。誰かがそれを試みたら理由とそれを実行できる正確な役割(または人物)を示します。
設定画面はしばしば「雑多な引き出し」になります。解決策は設定ハブで、安定したレイアウト:左にナビゲーション、右に選択に応じて変わる詳細パネルです。
簡単なルール:繰り返し変更されるものはSettingsに。初回設定の一部ならオンボーディングに入れます。
メニューは短く、人が認識しやすい文言にします。多くのビジネスアプリでは次のカテゴリでほとんどをカバーできます:ProfileとPreferences、Notifications、Security、Organization(またはWorkspace)、Integrations(実際にある場合のみ)。
コア項目をしゃれた名前で隠さないでください。"Organization"は"Workspace DNA"より分かりやすいです。
通知はチャネル別(メール vs アプリ内)と重要度別に分けると有効です。重要でない更新は頻度を選べるようにし、重要アラートは見落とせないようにラベルを付けます。
セキュリティは信頼獲得の場です。2段階認証(2FA)、アクティブセッション一覧、共有コンピュータで使う場合は最終アクティブやデバイス情報を含めます。
組織設定は管理者がまず触る項目をカバー:組織名、ブランディング基本(ロゴ/カラー)、新規招待のデフォルト役割。
小さなCRMでは、営業担当は通知頻度やタイムゾーンを変え、管理者は会社名やデフォルト役割を更新します。これらが予測できる場所にあるとサポートが減ります。
請求は信頼を勝ち取るか失うかの場です。人は支払うこと自体を嫌いませんが、驚きは嫌います。請求はいつも同じ質問に答える小さな画面群として扱います。
まずは請求の概要を地味に正確に:現在のプラン名、更新日、支払い方法、請求書履歴、領収書の送付先メール。支払い方法の編集を分かりやすくします。
次にプラン比較画面。上限は平易な言葉で(席数、プロジェクト、ストレージ、APIコールなど)示し、上限に達したときに何が起きるかを明確にします。「フェアユース」のような曖昧なラベルは避けます。
別に使用状況と上限の画面を用意するとサポートが減ります。いくつかのメーターと、ブロックされる前の明確なメッセージがあれば十分です。アクションはシンプルに:アップグレードボタン一つ、管理者のみがプラン変更できる旨を注記。
キャンセルやダウングレードはボタン一つではなくフローとして扱ってください。何が変わるかを説明し、確認ステップを入れ、最後に「請求が変更されました」の通知を送ります。
例:3人チーム用CRMならFreeはパイプライン1つ、Proは5つ許可するとします。チームが2つ目のパイプラインを追加しようとしたら、上限と代替案、アップグレードの道筋を示して行き止まりにしないでください。
監査、ヘルプ、サポートは付け足しではなく、準備された主要画面として扱ってください。これらは信頼を高め、サポートスレッドを短くし、管理者の作業を穏やかにします。
監査ログは「誰が何をしたか」「いつ」「(追跡していれば)どこから」を素早く答えます。データやアクセスを変えるイベントに注力します。出発点としてはサインイン活動、パスワード変更、役割/権限変更、主要レコードの作成/更新/削除、請求イベント(プラン変更、支払失敗)、上限到達、エクスポートが含まれます。
読みやすさを重視:明確なイベント名、実行者、対象、タイムスタンプ、短い詳細パネル。基本フィルタ(日付範囲、ユーザー、イベントタイプ)を付け、現在のフィルタでのCSVエクスポートを用意すれば多くのチームには十分です。
困っている人のためにヘルプ画面は機能するようにします。小さなFAQ、連絡手段、短い状態表示(既知の問題や予定されたメンテナンス)を含め、言葉は平易で行動指向にします。
「問題を報告する」ではサポートが常に必要とする情報を求めます:期待していたことと実際に起きたこと、再現手順、スクリーンショットや録画、端末/ブラウザとアプリバージョン、発生時刻、エラーメッセージ。送信後には何がキャプチャされたかと追跡方法をまとめた確認を表示します。
多くのチームはエラーや空状態を最後に考え、穴を埋めるのに数日を費やします。これらを共有パターンとして扱えば、より早く、サポートの少ない出荷が可能です。
グローバルエラーページは丁寧で有用に:何が起きたか平易に伝え、次の明確な一手(再試行)を提示し、サポートにつながる手段を示します。リクエストIDなどの技術的詳細は「詳細」領域の裏側に置きます。
インラインエラーはさらに重要です。修正が必要なフィールドの横にメッセージを置き、口調は中立にします。「Emailの形式が正しくありません」は「無効な入力」より受け入れられます。フォーム送信後に失敗したらユーザー入力を保持し、最初の問題箇所をハイライトします。
空状態は空白ページではありません。ページの目的と今できることを答えるべきです。例:「まだ請求書がありません。最初の請求書を作成して支払いを追跡しましょう。」明確な行動呼びかけを一つ入れます。
読み込み状態は待ち時間に合わせます。短い操作にはスピナー、長いページ読み込みにはスケルトンを使い、レイアウトが来ていることを示します。
オフライン時は明確に表示し、何がまだ機能するか(キャッシュされたデータの閲覧など)を示し、ネットワーク復帰時に確認します。
速度は、ドメインの詳細に引きずられる前に共通画面を決めることから生まれます。チームが早期にこれらの基本で合意すれば、最初の使えるバージョンは数週間早く出ます。
例:小さなCRMを作るなら、「Sales Rep」デモユーザーを作り、連絡先は追加できるがエクスポートはできないようにして、UIがなぜエクスポートできないかと次にどこに行けばよいかを説明する。
多くの遅延は難しい実装からではなく、UI構築後に曖昧な決定を残していたことから生じます。この設計図が時間を節約するなら、いくつかの合意を早めに得る必要があります。
チームがよく踏む同じ落とし穴:
簡単なルール:ユーザーにデータがない、アクセスがない、ネットがない、クレジットがない場合に何が起きるかを、ハッピーパスを磨く前に決めておきます。
例:CRMなら最初にSalesは自分の担当案件のみ編集でき、Managersはチームレポートを見られ、Ownersが請求を統制する、と合意してから「My profile」と「Workspace admin」に設定を分ければ、請求画面は曖昧なエラーメッセージの代わりに明確な上限表示になります。
Koder.ai(koder.ai)で構築する場合、Planning Modeでこれらのルールを書いておくと画面生成時の手戻りが減ります。
出荷前に初めての顧客のように画面を一通り操作してみてください。UI上の操作だけで進めるか。隠しURLやDB調整、管理者への依頼が必要ならMVPはまだです。
このチェックリストで設計図が防ぐ共通の穴を見つけてください:
簡単なテスト:新しいアカウントを作り、2人目のユーザーを追加し、役割を変え、データをエクスポートしてみてください。UI上で迷わずできればナビゲーションと権限はおおむね堅いです。
地域サービス向けの小さなCRMを想像してください。リード、連絡先、案件を追い、役割はOwner、Sales、Supportの3つ。データモデルがシンプルでも、1日目に必要な共通画面はほぼ同じです:
現実的なプランルールの例:Proプランは5席と2,000件の連絡先を許可。Ownerが6人目を招待しようとすると、あいまいなエラーではなく明確な上限状態を表示します:
"席数上限に達しました(5/5)。プランをアップグレードするかメンバーを削除してAlexを招待してください。"
よくあるエラー例:Salesが連絡先を削除しようとしたら、その連絡先にSupportの未解決チケットが2件紐づいている。操作をブロックして次に何をすべきかを示します:
"削除できません。この連絡先には未解決のサポートチケットが2件紐づいています。チケットを閉じるか担当を変更してから再試行してください。"
チャットベースのビルダーでこの設計図を実装する場合、一貫性は速度と同じくらい重要です。Koder.ai(koder.ai)はチャットからWeb・バックエンド・モバイルアプリを生成する設計で、Planning Modeとソースコードエクスポートをサポートしており、画面パターンを定義してからページを生成するワークフローと相性が良いです。
多くの遅延は、同じ「退屈な」ページ(認証、設定、請求、役割)を毎回少しずつ変えて再構築することに起因します。共有のデフォルト画面を持つことで動作が一貫し、QA工数・エッジケース・ユーザーの混乱を減らせます。
コンポーネントはボタンやテーブルのような小さなUI部品です。再利用可能な画面は「1ページ分」で、明確な役割、予測できるレイアウト、読み込み・空状態・エラーなどの標準化された状態を備えており、ユーザーが何度も学び直す必要をなくします。
実用的なMVPセットは、ログイン、サインアップ、パスワードリセット、オンボーディング、プロフィール、設定です。マルチユーザーならチームメンバーと役割、課金するなら請求、制限があるなら利用状況画面を追加します。
シンプルに:メール/ユーザー名、パスワード、明確なボタン。パスワード表示切替とわかりやすいエラーメッセージを追加し、余計なオプションは本当にサポートできる場合のみ入れます。
存在確認をしない中立的な文言にします。例:「該当するアカウントがあれば、リセットリンクを送信しました。」フローは短く:要求、メール、パスワード設定、成功の確認。
開始に必要なものだけを尋ね、任意のステップは簡単にスキップできるようにします。「作業を始める」と「完璧にする」を分け、先に作業できる状態にしてから後で補完を促します。
最初は小さく、馴染みのある役割セット(Owner、Admin、Member、Viewer)から始め、各役割を平易な言葉で説明します。権限マトリクスを見やすくし、課金関連や所有権移譲はOwnerのみに限定します。
受信トレイのような感覚で:状態バッジ(Invited、Active、Suspended)、招待の再送、役割変更、削除などの高速アクション、最後のアクティブ日時の表示。操作をブロックする場合は理由と誰ができるかを明示します。
左側メニューと右側詳細パネルの安定した配置にして、カテゴリは明快に(Profile、Notifications、Security、Organization)。重要な項目をバラバラにしないことが肝心です。
現在のプラン名、更新日、支払い方法、請求書履歴、領収書用の請求先メールを分かりやすく表示します。上限は明確に示し、上限到達時の挙動を具体的に書きます。利用状況画面で事前に警告を出すとサポートが減ります。