Webシステムの運用では、デプロイの進行確認、サービスの起動停止、設定差分の確認といった作業が日常的に発生する。 これらを管理コンソールやCLIで都度実行していると、待機時間が読めず、複数サービスにまたがる状態を頭の中で突き合わせることになる。 そこで多くの現場が、CloudWatchダッシュボードのカスタムウィジェットにLambdaを組み合わせて、状態の集約と操作の実行を1画面にまとめようとする。
これは立ち上がりが速く、実際よく機能する。しかし運用担当者へ展開する段階で、設計上動かせない2つの境界に突き当たる。 本稿ではその境界を仕様レベルで確認し、管理画面を独立させる場合の設計判断を解説する。
1. 課題: 運用操作をどこに置くか
運用操作の置き場所には、おおむね次の選択肢がある。
中央の選択肢は、参照系のダッシュボードとしては十分に強い。 問題は、そこに実行系のボタンを置いた瞬間に現れる。
2. 境界1: 実行した個人を記録できない
カスタムウィジェットは、CloudWatchがLambdaを呼び出し、返却されたHTMLを表示する仕組みである。
このときLambdaへ渡される widgetContext の構造は公式ドキュメントで規定されており、次の要素を持つ。
dashboardName / widgetId / accountId / locale / timezone
|
period / timeRange / theme / linkCharts / title
|
forms / params / width / height |
利用者を識別する要素がない。 accountId はAWSアカウントIDであり、操作した個人ではない。
つまりLambda側は、受け取ったイベントだけでは「誰がボタンを押したか」を確定できない。
さらに影響が大きいのは、その先である。 LambdaからCodeBuild、ECS、SSM Automationなどを起動すると、対象サービスに記録されるAPI呼び出し元はLambda実行Roleになる。 操作対象、操作内容、実行時刻、結果は記録できても、それを個人へ結び付ける情報がどこにも残らない。
ウィジェット側にボタンの表示制御はあるが、これはUI制御であって認可境界ではない。 イベントのパラメータだけで操作を許可する設計にすると、画面を経由しない直接呼び出しを拒否できない。
商用サービスの運用でこの状態は許容しにくい。誤操作や事故が起きたとき、経緯を追跡できないためである。
3. 境界2: 更新の単位がダッシュボードに従属する
カスタムウィジェットの再実行契機は、ウィジェット作成時に選ぶ。公式ドキュメントが挙げるのは次の3つである。
自動更新は存在する。しかし更新の周期はダッシュボード全体で共通であり、ウィジェットが自分の都合で周期を決めることはできない。
これが運用画面で効いてくるのは、実行時間が長く、かつ段階が進む処理を扱うときである。 CodeBuildによるCD、ECSのデプロイ、ターゲットグループのヘルス遷移は、それぞれ進み方の速度が違う。
- 進行中の処理は数秒間隔で追いたい
- 落ち着いているサービスは数分に一度で足りる
- 処理が完了したら追跡をやめたい
ダッシュボード共通の周期では、この出し分けができない。 結果として、担当者は「今処理中なのか、止まっているのか、終わったのか」を判断できず、古い表示を現在の状態と誤認する。 これは操作ミスに直結する。実行系を載せた画面で、状態の誤認は最も避けたい失敗である。
4. 再構成: 実行者を認証に結び付ける
2つの境界は、いずれもウィジェットという実行経路そのものに由来する。 表示を工夫しても解けないため、経路を分けることになる。
要点は、認証で確定した利用者の識別子を、AWS API呼び出しまで運ぶことである。
STSの AssumeRole には SourceIdentity という引数がある。
ここへ認証済み利用者の識別子を設定すると、その一時セッションで行ったAPI呼び出しのCloudTrailレコードに識別子が残る。
共通のRoleを使いながら、操作を個人へ結び付けられる。
設計上、次を守る必要がある。
更新の問題も、経路を分けた時点で解ける。 画面が自分でデータ取得の周期を持てるため、進行中の対象だけ短い間隔で追い、完了したら止められる。 表示のたびに「いつ時点の情報か」「取得に失敗していないか」を出せるため、取得失敗を直前の成功状態で置き換えずに済む。
5. なぜAWS由来の設計システムを選ぶのか
経路を分けると、画面を自前で作ることになる。ここで何を使うかが次の判断になる。
Cloudscape Design System は、AWSが自社の管理コンソールのために2016年から開発し、 2022年にApache 2.0でオープンソース化した設計システムである。Reactコンポーネントとして提供される。 2026年9月時点で、94のコンポーネント、62のパターンガイドライン、33のデモページを公開している。
汎用UIライブラリとの違いは、想定用途が絞られていることにある。
自由度が高いことは、管理画面では必ずしも利点にならない。 運用画面に求められるのは独自性ではなく、状態が誤解なく読めることだからである。
加えて実務上大きいのは、運用担当者がすでにAWSコンソールに慣れていることである。 左のナビゲーション、上部のバナー、テーブルの絞り込み、状態表示の色と記号が管理コンソールと同じ語彙で並ぶため、 画面の読み方を新しく覚え直す必要がない。運用画面の導入コストは、機能ではなく習熟に出る。
6. 制約が設計判断を減らす
「制約が利点になる」という主張は抽象的になりやすいので、具体例で示す。
Cloudscapeの状態表示コンポーネントは、受け付ける状態の種類があらかじめ決まっている。
success、error、warning、info、pending、in-progress、loading、stopped といった固定の語彙であり、
それぞれに色と記号が割り当てられている。
一方、運用画面が扱いたい状態は業務側の語彙である。
未開始 / 実行中 / 成功 / 失敗 / 確認不能 / 要確認 / 対象外 / 不整合 |
自前でUIを組む場合、ここで「確認不能は何色か」「対象外はグレーか、それとも非表示か」を一つずつ決めることになる。 設計システムを使う場合、判断は次の形に変わる。
// 概念例: 業務の状態語彙を、設計システムが持つ固定の語彙へ対応させる
|
const STATUS_TYPE = {
|
未開始: "pending",
|
実行中: "in-progress",
|
成功: "success",
|
失敗: "error",
|
確認不能: "warning",
|
要確認: "warning",
|
対象外: "stopped",
|
不整合: "error",
|
}; |
「何色にするか」ではなく「この状態は8つのどれに当たるか」を決める問題になる。 色や記号の一貫性は設計システムが担保するため、議論の対象から外れる。
そして残った「この状態はどれに当たるか」は、UIの問題ではなく業務の問題である。
たとえば「確認不能」を error にするか warning にするかは、
取得に失敗しただけの状態をサービス障害として扱うかどうかという運用方針の判断であり、
デザインの判断ではない。
これは当社がインフラ側で採っている考え方と同じ構図である。 AWS SDKからTerraform、そして目的別に具体化したモジュール群へと段階を重ねるほど、 構築時に決められることは減る。減った分だけ、本来考えるべき業務要件に検討を集中できる。
フロントエンドでも同じことが起きる。汎用ライブラリからAWS由来の設計システムへ寄せると、 画面で決められることは減り、残るのは「どの状態を、どの粒度で、誰に見せるか」になる。
基盤側とUI側で同じ出自の制約を採ると、両者の語彙が最初から揃っているという副次的な効果もある。 リソースの状態名、監視の考え方、画面上の表現が、別々の翻訳を挟まずに接続する。
7. まとめ
運用管理画面は、機能を並べれば完成するものではない。 誰が実行したかを追跡でき、今の状態を誤解なく読めることが、展開できる画面の最低条件である。 この2点はいずれも、どの実行経路とどのUI語彙を選ぶかという、開発を始める前の判断で決まる。