Webアプリを公開して継続運用するなら、利用者向け画面だけでは足りません。
登録できる。
ログインできる。
データを入力できる。
そこまで作っても、運営側から次のことが分からなければ、サービスとして管理できません。
- 誰が利用しているのか
- どの契約が有効なのか
- どのプランを利用しているのか
- どのユーザーが利用可能なのか
- 現在有効なセッションはあるのか
- 問題が起きたとき、何が起きたのか追えるのか
- 必要な場合に利用を停止できるのか
今回、自分で開発しているWebアプリを本番運用できる状態まで整える中で、利用者向け機能とは別に、こうした運営管理機能も構築しました。
この記事では、管理画面のUIそのものではなく、
サービスを運営するために、何を管理対象として設計したか
を整理します。
この記事で公開しないもの
この記事は、実際に本番運用しているシステムを題材にしています。
そのため、
- 管理者権限の具体的な範囲
- 停止・失効・削除に関する内部条件
- 管理画面への具体的なアクセス制御
- 内部URL
- DBの実テーブル構造
- 本番環境固有の設定値
など、内部構成や防御条件の推測につながる情報は公開しません。
この記事で扱うのは、管理機能をどのような単位で考え、どのような責務に分けたかです。
1. 管理画面を「強い権限を持つ画面」と考えない
管理画面というと、
一般利用者にはできない操作
↓
管理者ならできる
という構造を思い浮かべがちです。
しかし、今回の設計では少し違う考え方をしています。
管理画面の役割は、
サービス全体の状態を把握する
↓
必要な判断をする
↓
必要な場合だけ操作する
ことです。
つまり、
操作するための画面である前に、状態を確認するための画面
です。
この考え方にすると、
「管理者だから何でも変更できるようにする」
という設計にはなりません。
2. ユーザーと契約を分けて考える
利用者管理だけを見ると、ユーザーのテーブルが一つあれば十分に見えます。
しかし実際には、
ユーザー
↓
契約
↓
プラン
↓
利用可能なサービス
という関係があります。
重要なのは、
ユーザーが存在することと、そのユーザーが現在サービスを利用できることは別
という点です。
例えば、
ユーザー：存在
契約：無効
なら利用させない。
逆に、
契約：有効
ユーザー：利用停止
でも利用させない。
そのため、管理側でもユーザーだけを見るのではなく、
User
Contract
Plan
Service
Status
を関係として確認できるようにします。
3. 「存在」と「状態」を分ける
DBにレコードがあるかどうかだけでは、本番システムの状態は判断できません。
例えば、
存在する
だけではなく、
利用可能
利用不可
処理途中
停止
失効
といった状態があります。
今回の公開登録でも、
登録要求
↓
本人確認
↓
アカウント成立
↓
利用可能
という途中状態が存在します。
そのため管理側では、
データがあるか
より、
現在どの状態なのか
を確認できることを重視しています。
4. 状態変更とデータ変更を同じにしない
管理画面では、DBの値を直接変更できるようにしたくなります。
例えば、
ユーザー情報を変更
契約情報を変更
プランを変更
状態を変更
です。
しかし、すべてを同じ「編集」として扱うと危険です。
例えば、
表示名を変更する
のと、
利用可能 → 停止
では意味が全く違います。
そこで考え方として、
属性変更
状態変更
運用制御
を分けます。
特に状態変更は、その後のログインやサービス利用に直接影響します。
編集画面で値を書き換えることと、サービス状態を変更することは別の操作
として扱った方が安全です。
5. 「使わせる」と「止める」はセット
公開サービスでは、利用開始の仕組みだけでは足りません。
登録
↓
認証
↓
利用開始
があるなら、逆方向も必要です。
利用停止
セッション失効
契約状態変更
ユーザー無効化
などです。
問題が起きたときに、
止められない
状態では運用できません。
そのため、
利用可能にする処理と、利用不能にする処理を両方設計する
必要があります。
6. セッションも管理対象にする
ログイン中の状態をブラウザ側だけで持つと、運営側から制御できません。
そこでセッションも管理対象として扱います。
概念的には、
User
│
├─ Session A
├─ Session B
└─ Session C
のように、ユーザーと現在のセッションを関連付けます。
管理側で確認したいのは、
いつ開始されたか
現在有効か
すでに失効しているか
などです。
これにより、
ログアウト
強制失効
期限切れ
複数端末制御
問題調査
にも対応しやすくなります。
7. 履歴は「あとから調べるため」に残す
本番運用では、
今どうなっているか
だけでなく、
どうして今の状態になったのか
を確認する必要があります。
そのため、
- ログイン履歴
- セッション状態
- 状態変更
- 操作履歴
などを、必要な範囲で確認できるようにします。
例えば問い合わせで、
昨日まではログインできた
と言われた場合、
現在のユーザー状態だけを見ても原因は分かりません。
認証履歴
↓
セッション
↓
契約状態
↓
状態変更
と追えることで、原因を絞れます。
8. 利用者へ見せる情報と管理側の情報は分ける
認証失敗を例にすると、利用者へ詳細な内部理由を表示することが適切とは限りません。
利用者側では、
ログインできませんでした
程度に抑えながら、内部では、
資格情報不一致
ユーザー状態
契約状態
セッション状態
などを区別して扱うことがあります。
つまり、
利用者に必要な情報
≠
運営側の調査に必要な情報
です。
管理機能は、この差を埋める役割も持ちます。
9. 削除は最後の手段として考える
管理画面を作ると、
登録
編集
削除
を一式そろえたくなります。
しかし、本番システムでは削除が最も慎重になります。
例えばユーザーを削除した場合、
契約
履歴
セッション
業務データ
などとの関係があります。
さらに、
後から調査する必要はないか
過去履歴として残すべきではないか
利用不可にするだけでは駄目なのか
も考える必要があります。
そのため、
削除できることより、削除しなくても運用できる状態設計
の方が重要になる場合があります。
以前noteでも、テストデータの後始末を題材に、関連データを単純には削除できない話を書きました。
本番ではさらに、「消せるか」ではなく「消してよいか」という判断が加わります。
10. 管理者だから何でもできる設計にはしない
管理画面は高い権限を持ちます。
そのため、
管理者
=
何でも操作可能
にはしません。
例えば管理機能でも、
閲覧のみ
変更可能
状態変更可能
停止可能
削除不可
のように操作の性質を分けて考えます。
理由は単純で、
操作できる範囲が広いほど、誤操作したときの影響も大きい
からです。
管理機能は便利なツールであると同時に、守るべき対象でもあります。
11. 管理系の入口を一般利用者と同じにしない
一般利用者とシステム管理者では、扱える情報も影響範囲も異なります。
そのため、管理系については一般利用者側と同じ入口・同じ考え方にはしていません。
概念的には、
一般利用者
↓
一般認証
↓
利用者向け機能
と、
管理者
↓
管理用認証
↓
追加のアクセス制御
↓
管理機能
を分けます。
具体的な制御方式は公開しませんが、
管理機能そのものを別の保護対象として扱う
という考え方です。
12. 管理画面もテストする
利用者側機能と同様に、管理機能にもテストが必要です。
特に確認したいのは正常操作だけではありません。
例えば、
一般利用者から管理機能へアクセスできない
無効状態のデータを誤って有効扱いしない
停止した利用者が利用できない
失効したセッションを再利用できない
関連データがある状態で不適切に削除できない
権限外の操作ができない
などです。
管理機能では、
できることのテストより、できてはいけないことのテスト
が重要になるケースがあります。
13. AIに管理画面を作らせるときに必要だったこと
今回も、管理機能の実装にはAIを使っています。
AIは、
- 一覧
- 検索
- 編集画面
- 状態表示
- 履歴表示
- DB処理
までかなり作れます。
しかし、
管理画面を作って
という指示だけでは足りません。
必要なのは、
何を表示するか
何を変更できるか
何を変更できないか
どの状態遷移を許可するか
何を履歴として残すか
どの操作を管理者に許可するか
という仕様です。
つまり、
画面を作る作業はAIへ渡せても、管理範囲を決める責任は残る
ということです。
まとめ
管理画面というと、
利用者には見えない
+
強い権限を持つ
=
管理画面
のように見えます。
しかし実際には、
ユーザー
↓
契約
↓
プラン
↓
利用状態
↓
認証
↓
セッション
↓
履歴
↓
停止・失効
↓
調査
を確認し、必要な判断をするための仕組みです。
今回の管理機能も、
「何でも操作できる画面」ではなく、「サービスの状態を把握し、安全に運用するためのシステム」
として設計しています。
利用者向けのWebアプリが表側なら、管理機能は運営側です。
どちらか一方だけでは、継続して運用できるサービスにはなりません。
関連記事
noteでは、技術構成よりも、
なぜ利用者から見えない管理機能が必要なのか
という運用側の視点で整理しています。
利用者には見えない。でも、これがないとサービスは運用できない。
また、削除と関連データについては、こちらの記事でも扱っています。