スクリーンショット

運用コンソールの実際の画面です。このページの画像はすべてデモスタック (cargo make demo) で撮影しています。モックバックエンドが 248 台の架空フリートを返すだけで、NATS もエージェントも実機もありません。氏名・ホスト名・サインインアカウントはすべて作り物で、実際の導入環境から取ったものは一枚もありません。

デスクトップは 1440×900、モバイルは 390×901 で撮影しています。

ここでは日本語表示のコンソールを載せています。英語版のページには同じ画面を英語表示で載せています。データはどちらも日本語のままです。フィクスチャが日本企業という設定で、ウィジェット名・グループ名・チェックの説明は運用者が書いたものだからです — 画面の翻訳対象ではありません。

フリートの全体像

ダッシュボードは、運用者が最初に見る数字から始まります。何台が報告しているか、何台が沈黙しているか、ブローカーのストリームが上限内か、直近24時間で何件のジョブが失敗したか。どの数字からも、その内訳のページへ辿れます。

下のピン留めウィジェットは運用者が定義したものです。分析ページで自分で作ったビューを、そのままダッシュボードに固定できます。

エージェント

死活だけを見るページです。どの端末がオンラインか、エージェントのバージョンはいくつか、最後に応答したのはいつか。詳細はインベントリの担当で、ここが答えるのは「居るかどうか」です。

列は選べます。上の画面ではこのフリートに不要な列を隠しています。表示列の選択はそのためのものです。

1台を見る

行を開くと、その端末自身の数字が出ます。エージェントが採取した CPU・メモリ・ディスク・ネットワークを、選んだ期間で表示します。エージェントは自分自身も計測しているので、「端末のせいか、こちらのせいか」にもグラフが答えられます。

端末が知り得ないことを持たせる

端末は自分について見えることしか報告できません。誰の机の上にあるのか、どの部門が費用を持っているのかは、端末には分からないままです。そこで各ホストは、運用者が編集できる自由な key/value のカードを持ちます — 利用者、メール、部署、拠点、資産管理番号、この端末が特別な理由を書いたメモ。

これらは決まったスキーマではなくただのフィールドで、API から書き込めます。ディレクトリ同期のジョブが display_name や department を最新に保てるのはそのためで、誰も手で入力しません。一度入れてしまえば、フリート全体に対して表示・検索できる列になります。

The writes go through the backend API (kanade meta set / rm / clear, or the per-key endpoint behind them), so they are authenticated, role-checked (operator or above) and audited. A directory-sync job that calls kanade meta set therefore needs a KANADE_AUTH_TOKEN even when it runs on the backend host; it touches only its own keys, so hand-entered ones survive.

画面を見る

報告を読むだけでは分からず、実際に見るしかないことがあります。その端末のページから画面を開いて、そのまま見られます。

このために端末側で何かを待ち受けたりはしません。エージェントはすでに外向きの接続を1本持っていて、セッションはその上を通ります。NAT の内側にいる PC も、拠点の回線にいる PC も、自宅の Wi-Fi にいる PC も、隣の席の1台とまったく同じ条件で見られます。端末へ内向きの経路を開くことはありません。ヘッダーには画面サイズと受信タイル数が出ます。更新が止まったセッションと、変化していない画面を映しているだけのセッションは、区別できるべきだからです。

上のデスクトップは合成画像です。デモスタックが描いたもので、実在の端末から取得したものではありません。

インベントリ

マニフェストが集めたものが、そのまま並びます。プローブは YAML ジョブに inventory: を付けた運用者製の PowerShell なので、列は「あなたが集めると決めたもの」です。固定スキーマではありません。行をクリックすると、その端末の全ファクトが開きます。

さらに開くと、その PC が報告したファクトが、プローブごとに1枚のカードで並びます。

何がいつ変わったか

各ファクトカードには履歴タブがあります。インベントリはスナップショットだけではありません。実行のたびに前回と差分を取るので、インストール済みアプリはそれ自身の時系列を持ちます — いつ現れ、どのバージョンを辿り、いつ消えたか。

ここでは何ひとつ「追跡する」と設定していません。プローブはインストール済みアプリの一覧を報告するだけで、追加・削除・変更の行は連続する実行を突き合わせた結果として出てきます。

コンプライアンス

ヘルスチェックのフリート横断ステータスを、チェックごとに件数付きでまとめます。チェックとは check: ヒントを持つジョブにすぎないので、追加するとはマニフェストを書くことです。kanade が検証できる項目のハードコード一覧、というものは存在しません。

肝は詳細列です。その端末がなぜ問題なのかを、その端末自身の言葉で書きます。

サポート期限

同じ仕組みを、設定ではなく日付に向けたものです。このチェックは各ホストの OS ビルドを読み、そのサポート終了日を引き当て、期限までの距離に応じて異常・警告・OK として報告します。今日は問題ないビルドが、誰かが気づこうと思うより何ヶ月も前に、自分から警告し始めます。

稼働状況

電源・セッション・スリープ・アクティブの区間を、Windows イベントログから再構成し、種別ごとのレーンで並べます。レーンの空白は、その種別のイベントが無い区間 — 電源オフ、またはアイドルです。

分析

ジョブが吐いたものを集計します。ここではアプリ利用時間・閲覧履歴・インベントリを出しています。ウィジェットは YAML で定義し、ダッシュボードに固定できます。

タブは決まったレポートの一覧ではありません。ひとつひとつがどれかのマニフェストが宣言した dashboard: の名前なので、その名前を名乗るウィジェットを書けば新しいタブが現れます。次の2つはフィクスチャに入っているものです。

グループ

宣言的なフリートグループです。動的グループはクエリを持ち、バックエンドが一定間隔で再評価するので、メタデータが変われば所属も追随します — エージェントに site と department を一度付ければ、異動した端末は自分で正しいグループに入ります。静的グループはメンバーを直接列挙するもので、クエリでは表せない所属のためにあります。

通知

クライアントアプリに通知を送り、誰が確認したかを追跡します。本文は Markdown（見出し・箇条書き・表・リンク）なので、全社通知を段落ではなく文書として書けます。

誰が確認し、誰が取り消したか

通知を開くと、宛先ごとに、その端末にサインインしていた本人と紐づけて追跡されます。状態は2つではなく3つです — 確認済み、まだ未確認、そして取消済（一度確認したあとに取り消した人）。取消済の行は両方の時刻を保持するので、「全員が読んだ」があとから静かに真に戻ることはありません。

ジョブ

マニフェストそのものを、タグ別にまとめた一覧です。kanade が端末で実行するものは、すべてこのどれかです。

マニフェストそのもの

開くと、運用者が書いた YAML がそのまま出ます。そこから生成したフォームではありません。コメントもブロックスカラーのインデントも往復して残ります。ソースを解析したオブジェクトから再直列化するのではなく、そのまま保存しているからです — 保存したファイルが、そのまま返ってきます。エディタはスキーマを理解しているので、フィールド名にカーソルを合わせると説明が出ます。

Git で管理されているマニフェストは、代わりに読み取り専用で開き、リポジトリ内のパスを示します。SPA 側の編集が正本から乖離することを許さない、ということです。

1回の実行

配信のたびに、その実行自身の結果が残ります。終了コード、ジョブとリクエストへ辿るための各種 ID、そしてホストが出力したそのままの内容です。失敗は赤いバッジ以上の価値があります — この例では、原因になった PowerShell のエラーがそのまま入っています。

監査ログ

すべての配信と、すべての運用者操作を、その裏にあるペイロードごと記録します。実行主体・アクション・対象で絞り込め、ペイロード本文の全文検索もできます。

アカウント

運用者アカウントと、そのページアクセスです。混同しやすい3状態を同時に出しています — 無制限、アカウント個別の許可リスト、そして共有の権限グループ。グループが設定されている場合はグループが優先し、アカウント個別のリストは（あっても）効きません。

自分のアカウント

二要素認証とパスワードは、ひとつのセルフサービスページにまとまっています。管理者を介さずに運用者自身が設定できます。登録はごく普通の TOTP で、任意の認証アプリで QR を読むか、セットアップキーを手入力します。候補の秘密鍵は実際のコードで確認できて初めて保存されるので、途中でやめた登録はアカウントを元のまま残します。

JetStream

ブローカー自身の健康状態です。バックエンドがブートストラップするストリーム・KVバケット・オブジェクトストアを、上限に対する使用量とともに一覧します。

ダークテーマ

既定では OS の設定に追随し、ブラウザごとにライト／ダークへ固定もできます。

スマートフォンでは

1024px を下回ると、データテーブルは表であることをやめます。各行がカードになり、値には列名が付きます。横スクロールも、セルを読むためのピンチズームもありません。

クライアントアプリ

利用者の手元に届く側です。端末に常駐する小さなトレイアプリで、本人が見るヘルスタブ、問い合わせずに自分で実行できるジョブ、確認を求められる通知が入っています。同じ端末のエージェントと名前付きパイプで話し、バックエンドへは直接つながりません。

アプリ自身のウィンドウサイズである 880×560 で、日本語のみ掲載しています。クライアントアプリには i18n の層が無く、文字列がソースに直接書かれているため、英語版の画面というものが存在しません。

利用者に見てほしい2つを、開いた直後に出します。

端末ヘルス

運用者がコンプライアンスページで見ているのと同じチェックを、反対側から見たものです。警告には運用者自身が書いた説明と対処が付くので、最初の一手が「問い合わせる」にはなりません。

通知

通知ページから送られ、誰が確認したかまで追跡されます。開くと、運用者が書いた Markdown がそのまま描画されます — 見出し、番号付きの手順、表、引用、リンク。

セルフサービス

運用者が利用者に公開したジョブを、カテゴリ別に並べます。中身はどれも普通のマニフェストで、ここに出るかどうかは運用者が決めるだけです。

ジョブは実行前に確認を挟めます（マニフェストの confirm: に、運用者自身の文面で）。実行中は出力が流れていくので、沈黙のあと完了だけが現れる、ということになりません。

カタログは同じ仕組みを、インストールに向けたものです。

自分で動かす

cargo make demo         # 運用コンソール
cargo make demo-client  # クライアントアプリ

あとは http://localhost:5173 を開き、任意のユーザー名とパスワードでサインインするだけです。他に何も起動しておく必要はありません。モックが何をカバーしているか、どう足すかは crates/kanade-backend/web/demo/README.md にあります。