管理アプリ設計案 ― アカウント管理とデータパック適用を画面で完結させる

令和8年度 千葉県地域医療提供体制データ分析チーム構築支援事業　／　関連：システム構成案・データパック仕様書・技術選定書
県職員が使う閲覧側アプリ（ダッシュボード）とは別に、県担当者だけが開く「管理アプリ」の設計です。 必須機能はアカウント管理、主機能はデータパックの適用で、年1回必ず発生する更新作業をブラウザの画面だけで完結させます。 確定構成では認証を自前のNode.js＋Expressで実装するため、この管理アプリは同じサーバ上の一機能として当初から組み込まれます（後付けのオプションではありません）。 閲覧側アプリは静的ビルドのSPAのままで、同じサーバから配信されます。

1　位置づけ ― なぜ管理アプリを用意するのか判断の背景

① 年1回のパック適用が、県担当者にとって最もハードルが高い 県担当者の作業は年1回・3手順だけですが、その中身は「サーバの data/ にフォルダを置いて向き先を切り替える」というサーバ操作です。 権限・手順書・情報システム課への依頼が絡み、しかも年1回しか行わないため手順が身につかない。ここが運用上いちばん詰まりやすい箇所です。
② スクリプト実行（Python／exe）は採らない 適用作業を自動化する手段として「コマンド1つで済むスクリプト」や「実行ファイル」を県に配る案もありますが、 庁内での実行許可（実行ファイルの持ち込み審査・AV検知・アプリ制限）を得る難度が高い。 ブラウザで開く画面で完結する管理アプリのほうが、既存の庁内業務システムと同じ形であり承認を得やすいという判断です。
③ アカウント発行は県庁マター。ただし機構は用意する 誰にIDを出すか、部署共用IDにするか個人別にするかは県庁の判断事項です。 開発側はその判断を先取りせず、どちらを選んでも同じ画面・同じ運用で回せる仕組みを用意します。
この資料の範囲：本書は管理アプリの機能・画面・アクセス制御・構成への影響・新たに負う責任を整理した設計案です。 データパックの中身（列定義・検証ルール）はデータパック仕様書（分析班向け）、 全体の構成・確認事項はシステム構成案に規定します。

2　機能一覧 ― 2系統必須＝アカウント管理／主機能＝パック適用

2-1　アカウント管理（必須機能）― この5機能だけ

機能画面での動作設計上の要点
① 一覧登録されているIDを一覧表示。ID・区分（管理者／一般）・作成日・最終ログイン日時を列に持つ。並べ替え・絞り込み可共用IDなら数件、個人別なら数十件。どちらも同じ一覧で扱えるだけの違い。最終ログインは棚卸しの材料になる（§6）
② 新規登録IDを指定して発行し、区分を選ぶ。初期パスワードはシステムが自動生成し、作成直後に1回だけ画面に表示する（以降どこにも表示されない）管理者が初期パスワードを考える必要がなく、弱いパスワードが発生しない。保管された値は復元できない（§6）
③ パスワード再発行対象IDを選んで実行。新しいパスワードを自動生成して1回だけ表示。「忘れた」場合も「共有先が変わった」場合も、この1機能で対応するパスワードに関する操作を再発行だけに絞る。本人による変更・初回変更強制は設けない（§2-3）
④ ID削除不要になったIDを削除する。以後そのIDではログインできない無効化／再有効化は設けず削除に一本化する（§2-3）
⑤ 区分管理者＝アカウント管理＋パック適用の全操作／一般＝閲覧側アプリのログインのみ（管理画面に入れない）区分はこの2つだけ。細かい権限設計は行わない（運用が複雑になる割に利点が小さい）
アカウントの単位は県庁の判断事項です。 「健康福祉政策課で1つの共用ID」でも「職員ごとに個人別ID」でも、上の5機能はそのまま使えます（扱う件数が数件か数十件かの違いだけ）。開発側からどちらかを前提とすることはしません。 共用IDでも成立するように、本人によるパスワード変更と初回ログイン時の変更強制は設けていません（一人が変更すると他の利用者がログインできなくなるため）。パスワードの更新は管理者による再発行に一本化しています（§2-3）。

2-2　データパック適用（主機能）

手順画面での動作この手順を置く理由
① アップロード分析班から受け取った datapack_v2027.04.zip を画面にドラッグ＆ドロップ（またはファイル選択）。サーバ側の一時領域に受け取る。この時点では公開データに一切触れない県担当者の作業を「受け取ったzipを画面に落とすだけ」にする
② 適用前の再検証アップロードされたzipに対し、分析班の検証ツールと同じチェック（規約照合・コード整合・地図結合・一意性・秘匿・数値規約・manifest・版間差分照合の8分類）を管理アプリ側でもう一度実行。エラーがあれば適用ボタンを出さない分析班の検証との二重チェック。古いzip・別事業のzip・破損したzipがそのまま反映される事故を構造的に防ぐ
③ プレビュー適用前に 版数（pack_version）・発行日・発行者・変更点（manifest の notes）・収載ファイル数・現在の版との差分を表示。「本当にこれを適用してよいか」を画面上で確認できる年1回しか行わない作業で「どのzipだったか」を確信を持って判断できるようにする
④ 適用確認のうえ「適用」を押すと、版数フォルダを配置し current の向き先を切り替える（原子的差し替え）。職員はブラウザ再読み込みで新版に切り替わる従来の手作業（フォルダ配置＋向き先変更）を1操作に置き換える
⑤ 版数履歴・ロールバック適用済みの版を新しい順に一覧表示（版数・適用日時・実行者・notes）。任意の旧版を選んで1クリックで切り戻しできる。保持する世代数は設定で決める「いつ誰がこの版に切り替えたか」はこの履歴だけで追えます（§2-3）。「戻せる」ことが分かっていれば、担当者は適用を怖がらずに実行できる
現在の状態表示管理画面の先頭に現在の版数・発行日・収載ファイル数・最終適用日時／実行者を常時表示「今どの版が公開されているか」を毎回サーバを見に行かずに確認できる
適用前の再検証を置く意味：分析班側の検証は「正しく作れたか」を発行前に確かめるもので、 管理アプリ側の再検証は「いま適用しようとしているこのファイルが、本当にその正しいパックか」を確かめるものです。 役割が違うため、二重に見えても両方必要です（分析班側の検証を省略する意図はありません）。

2-3　版数履歴への統合と、あえて設けない機能

「いつ誰がこの版に切り替えたか」は、版数履歴に集約します。 §2-2⑤の版数履歴に「適用日時」「実行者」を持たせることで、切替の経緯は版数履歴だけで追えます。 1年後に実際に起きる問い合わせは「この数字、去年と違うが何が変わったのか」であり、これは版数履歴とmanifest の notes（変更点）で答えられます。 独立した操作ログ画面を持たなくてもこの用途は満たせる、というのが本設計の整理です。
設けない機能設けない理由（判断の記録）
操作ログ（監査ログ）の画面扱うのは機密性1（公表相当）の秘匿処理済み集計値のみで、県から監査要件の指定がありません（Q4-3「事業者から当班に提出頂くものとしては無い」）。加えて部署共用IDの場合は「誰が」を個人まで特定できず、追跡の用を成しません。適用の経緯は版数履歴が担うため、独立機能としては廃止します
無効化／再有効化ID削除に一本化します。状態が「有効・無効・削除済み」と増えるほど一覧が読みにくくなり、年に数回しか触らない画面では取り違えのもとになるためです
初回ログイン時のパスワード変更強制部署共用IDでは運用を壊します。一人が変更した時点で他の利用者がログインできなくなるためです。パスワードの更新は管理者による再発行（§2-1③）に一本化します
本人によるパスワード変更同じ理由で設けません。再発行で対応します（管理者が新しいパスワードを1回だけ表示し、共有先に配る）
サーバ側に記録自体は残します。ログインやアカウント操作の記録はサーバ側に残しますが、画面には出しません（将来必要になれば取り出せる状態にしておく、という位置づけです）。

3　画面遷移3画面だけ

ログイン ID／パスワード 管理者区分のみ ダッシュボード 現在の版数・発行日 ファイル数・最終適用 アカウント管理 必須機能（5機能） （§2-1） データパック適用 主機能 （§2-2） 一覧（ID・区分・作成日・最終ログイン）／新規登録（初期 PWを自動生成し1回だけ表示）／パスワード再発行／ID削除 ※共用IDでも個人別IDでも同じ画面で扱える zipアップロード → 適用前の再検証 → 版数・変更点のプレビュー → 適用（current の切替）→ 版数履歴（適用日時・実行者） ※履歴から1クリックで旧版へ切り戻し
管理画面は3画面のみ。県担当者が年1回使う導線は「ログイン → ダッシュボード → データパック適用」の一直線です。
画面使う人使う頻度備考
ログイン管理者その都度閲覧側アプリとはURLを分ける（§4）。初回ログイン時のパスワード変更強制は設けない（§2-3）
ダッシュボード管理者その都度現在の版数・発行日・ファイル数・最終適用日時／実行者を表示し、2画面への入口を置く
アカウント管理管理者随時（異動時等）§2-1の5機能（一覧・新規登録・パスワード再発行・ID削除・区分）。一般区分のIDからはこの画面に入れない
データパック適用管理者年1回＋臨時§2-2。①〜⑤を1画面のウィザードとして構成し、途中で中断しても公開データに影響しない。版数履歴（適用日時・実行者）とロールバックもこの画面

4　管理画面のアクセス制御 ― 3案の比較運用上の選択（推奨は③の併用）

ここは構成の分岐ではなく、県庁の手続き事情に合わせて選ぶ運用上の設定です。②の管理者ログインは確定構成に常時含まれるため、実際の選択は「①のIP制限を掛けるかどうか」に帰着します。推奨は③（併用）です。
案仕組み長所短所成立条件
① 庁内ネットワーク／特定IPからのみサーバ側で接続元を制限し、管理画面URLへの到達自体を庁内（または特定端末）に限る認証情報が漏れても外部から到達できない。設定が単純で、アプリ側に持ち込む仕組みが少ない庁内からは誰でも到達できる（操作者を区別できない）。庁外・別拠点から作業できない統合サーバまたは前段機器でのIP制限設定が可能なこと
② 管理者ID・パスワードによる認証管理アプリ自身のログイン。区分＝管理者のIDだけが入れる版数履歴に「実行者」を残せる（どのIDで適用したかが記録される）。場所を選ばず作業できるパスワードが単独の防御線になる。総当たり対策・パスワード保管の責任が発生（§6）確定構成に含まれるため常に成立（§5）
③ ①と②の併用到達をIPで絞ったうえで、さらに管理者ログインを課す防御が二重になり、かつ誰が操作したかも残る。どちらか片方が破られても即座に影響しない設定項目が増え、IP制限の申請手続きが必要①と②の両方
推奨は③（併用）です。管理画面はデータパックを差し替えられる＝全職員が見る数字を変えられる画面であり、閲覧側より一段高い保護が妥当です。 同時に、②を入れないと版数履歴に「実行者」を書けず、履歴が説明資料として使えません。 ②だけでも運用は成立しますので、IP制限の申請手続きの重さを見て県庁側でご選択ください（本設計はどの案でも同じ画面のまま動きます）。
URLの分離：いずれの案でも管理画面のURLは閲覧側と分けます（例：閲覧側 / に対し管理側 /admin/、または別ホスト名）。 分けることで、①のIP制限を管理画面だけに掛けられ、職員の閲覧アクセスを妨げません。 また閲覧側のURLは固定運用が前提（個人設定は端末のオリジン単位で保存されるため。システム構成案 §5）であり、管理画面の追加でこのURLを変えないことが条件です。
採らない案：閲覧側と同じ画面に「管理者だけ見えるボタン」を置く方式は採用しません。 画面が同一だと①のIP制限を管理機能だけに掛けられず、誤操作の余地も残るためです。

5　確定構成における位置づけ同一サーバの一機能

確定構成：認証は統合サーバの機能に頼らず自前のNode.js＋Expressで実装することが確定しています（システム構成案 §6）。 管理アプリはその同じサーバ上の一機能であり、閲覧側SPAの配信・ログイン・管理画面をすべて1つのサーバプロセスが担います。
項目確定構成での姿
サーバNode.js 24 LTS ＋ Express 5（技術選定書 §3）。1プロセスで①閲覧側SPAの静的配信 ②ログイン・セッション ③管理画面（アカウント管理・パック適用）を担う
閲覧側アプリ（職員が使うダッシュボード）静的ビルドのSPAのまま。同じサーバから配信され、データパックは従来どおり data/ をHTTPS GETで読むだけ（閲覧側からサーバAPIは呼ばない）
認証閲覧側・管理画面とも同じExpressのログインで保護。区分＝管理者のIDだけが管理画面に入れる（§2-1）。URLは分ける（§4）
データパックの更新管理画面からアップロード・再検証・適用・ロールバック。サーバ上のフォルダ差し替えは非常時の予備手順として残す（§7）
通信HTTPS の GET＋POST（POSTはログインとzipアップロード）。WebSocket・SSEは使わない（SSLインスペクション対応）
サーバ上の保存物静的ファイル＋データパック（版数フォルダ・旧版）＋アカウント情報・版数履歴（小規模DB。SQLite等の単一ファイルで足りる）＋アップロードの一時領域
設置先庁内の統合サーバが第一候補。Node.jsを実行できない場合のみ国内リージョンのクラウド（ISMAP登録事業者を優先）に設置する（§8）。どちらでも管理アプリの機能・画面・手順は同一
閲覧側と管理側の分離は維持します：閲覧側SPAは管理画面のAPIに依存せず、管理画面が停止しても閲覧は動き続けます。 この分離により、サーバサイドの攻撃面を管理画面だけに閉じ込められます（§6）。

6　自前実装に伴って負う責任トレードオフの明示

先に結論：認証とアカウント管理を自前で持つ確定構成では、サーバ製品の標準機能に委ねる場合に不要だった事項を開発側と県側が守るべき事項として引き受けます。 設計に織り込む対策とあわせて、正直に列挙します。
負う責任具体的な対策（設計に織り込む）担い方
パスワードの安全な保管ソルト付きハッシュ（bcrypt／Argon2id等の実績ある方式）で保存し、平文・可逆な暗号では持たない。管理者を含め誰も既存パスワードを閲覧できない（＝忘れた場合は再発行のみ）。パスワードは自動生成して1回だけ表示する（§2-1②③）開発側（実装）
アップロード受付の安全性zip展開時のパストラバーサル対策（../ や絶対パスを含むエントリを拒否）、シンボリックリンクの拒否、ファイルサイズ・展開後の総容量・ファイル数の上限、圧縮率の異常検知（zip爆弾）、拡張子とファイル種別の検証。一時領域に展開して再検証に合格したものだけを公開領域へ移す開発側（実装）
セッション管理Cookieに HttpOnly／Secure／SameSite を設定、一定時間の無操作で失効、ログアウトで破棄。ログイン試行回数の制限（連続失敗で一時ロック）開発側（実装）
版数履歴の保全版数履歴（版数・適用日時・実行者・notes）は追記のみとし、管理画面からの削除・改変機能を設けない。「いつ誰がこの版に切り替えたか」を後から説明できる唯一の記録であるため（§2-3）。保持世代数は県の方針に合わせる（§8）開発側（実装）＋県（保持世代数の方針）
バックアップと復旧アカウント情報・版数履歴（DBファイル）とデータパック旧版をバックアップ対象に含める。サーバ故障時の復旧手順を運用手順書に明記サーバ管理者（対象への追加が必要）
実行環境の維持（脆弱性対応）実行環境（Node.js）と依存ライブラリに更新義務が発生する。LTS系列に固定し、更新は年度改修でまとめて実施。担当と手続きを事前に決める（§8）情報システム課＋開発側
アカウントの棚卸し異動・退職時のID削除を運用に組み込む。管理画面の一覧に作成日・最終ログイン日時を表示し、使われていないIDを見つけられるようにする健康福祉政策課（運用）
この責任を軽くするための設計方針：①管理アプリの機能を3画面・アカウント管理は5機能という必要最小限に留める（作らない機能には脆弱性が生まれない。設けない機能とその理由は§2-3）。 ②閲覧側SPAは静的のままとし、サーバサイドの攻撃面を管理画面だけに閉じる。③§4③（IP制限＋認証）を推奨し、そもそも管理画面に到達できる範囲を絞る。

7　運用フロー（改訂版）年度更新・臨時更新

データ分析班（千葉大）集計→秘匿処理→検証ツールでチェック→版数付きzip発行
→
搬入ファイル転送サービス（第一）／物理メディア（予備）
→
県担当者管理画面にログイン → zipをアップロード → 再検証と版数を確認 → 適用
→
県職員ブラウザ再読み込みで新版に切り替わる
  1. 分析班：集計・秘匿処理 → データパック作成 → 検証ツールで機械チェック → 版数付きzip発行（例 datapack_v2027.04.zip）
  2. 搬入：ファイル転送サービスでダウンロード提供（予備：物理メディア郵送）。版数と変更点（notes）を県担当者へ連絡
  3. 県担当者：管理画面にログイン → zipをドラッグ＆ドロップ → 再検証の結果（エラー0件）と版数・発行日・変更点を画面で確認 → 「適用」を押す。所要は数分、サーバ操作は不要
  4. 反映：職員はブラウザ再読み込みのみ。アプリはmanifestの版数で更新を検知し「データが v2027.04 に更新されました」と表示
  5. 問題があれば：版数履歴から旧版を1クリックで復帰。復帰も版数履歴に「適用日時・実行者」つきで記録される

予備手順（サーバ上のフォルダ差し替え）との対比

作業サーバ上のフォルダ差し替え（予備手順）管理画面から（標準手順）
サーバへの接続ファイル共有やリモート接続などサーバへの到達手段と権限が必要ブラウザで管理画面URLを開くだけ
zipの展開・配置手元で展開し、版数フォルダごとサーバへコピー画面に落とすだけ（サーバ側で展開）
正しいzipかの確認フォルダ名などを目視で確認するのみ適用前に再検証を自動実行し、エラーがあれば適用させない
切替current の向き先を手作業で変更「適用」ボタン1つ
元に戻す手作業で向き先を戻す（手順を覚えている必要がある）履歴から1クリック
記録残らない（誰がいつ実施したか後から分からない）版数履歴に自動記録（適用日時・実行者・notes）
県担当者が直接できない場合情報システム課へ依頼（書式・リードタイムが発生）依頼不要。管理者IDの権限だけで完結
フォルダ差し替えは予備として残します。管理アプリが停止した場合や、サーバ移設などの非常時に、 サーバ上のフォルダ差し替えだけでも復旧できる状態（data/ の版数フォルダ＋current 構成）を維持します。 管理アプリはこの構造を画面から操作するものであって、独自の保存形式を持ち込むものではありません。

8　確認事項 ― 最重要は「Node.jsを動かす場所」の1点設置先の確認

確認いただきたい最重要事項は1つだけです。統合サーバで Node.js を実行できるか――可能なら庁内の統合サーバに設置し、不可なら国内リージョンのクラウド（ISMAP登録事業者を優先）に設置します。 いずれでも管理アプリの機能・画面・県担当者の操作手順は同一で、設計は分岐しません。以下の他項目は運用条件を詰めるための確認です。
確認事項確認先（想定）設計への影響
統合サーバで Node.js を実行できるか（常駐プロセスの許可、リバースプロキシ／ポートの設定可否、実行環境の導入手続き）情報システム課 設備管理班最重要（唯一の設置先判断）。可＝庁内の統合サーバに設置／不可＝国内リージョンのクラウド（ISMAP登録事業者を優先）に設置。県回答上443直接アクセス可・ホワイトリスト不要のため到達性の障壁は低い
管理画面のURL・ポートを閲覧側と分けられるか同上§4（URLの分離）。閲覧側URLは固定のまま変えないことが条件
接続元IP制限の可否と申請手続き同上§4①・③の成立性。不可なら②（認証のみ）を採る
サーバ上の書き込み権限（data/ 配下・一時領域）と容量上限同上アップロード受付・版数履歴の保持世代数（§2-2⑤）
アカウントの単位（部署共用ID／個人別ID）と、発行・削除の責任者健康福祉政策課§2-1。画面はどちらでも同じのため設計は分岐しない。共用IDでも成立するよう本人によるパスワード変更は設けていない（§2-3）
パスワードポリシー（文字数・更新周期の要否）情報システム課／健康福祉政策課§2-1②③の自動生成パスワードの強度設定
版数履歴の保持世代数・保存期間同上§2-2⑤・§6（版数履歴の保全とバックアップ対象）。監査ログの提出要件は県から指定なし（Q4-3）のため、独立した操作ログ画面は設けない（§2-3）
実行環境の更新（脆弱性対応）の担当・手続き・費用情報システム課＋開発側§6（自前実装に伴う継続的な保守義務）
集計結果データの機密性区分の正式確認デジタル推進課クラウドに設置する場合の制約有無
まとめ：管理アプリにより、県担当者の年1回の作業は「受け取ったzipを画面に落として、確認して、適用を押す」だけになり、 サーバ操作・情報システム課への依頼・手順の記憶がいずれも不要になります。アカウント管理は一覧・新規登録・パスワード再発行・ID削除・区分の5機能に絞り、同じ画面で完結します。 誤ったzipは適用前の再検証で止まり、万一のときは1クリックで元に戻せます。「いつ誰がこの版に切り替えたか」は版数履歴で追えるため、独立した操作ログ画面は設けません（§2-3）。 その代わり、パスワード保管・アップロード受付・セッション・版数履歴・バックアップ・実行環境の維持という責任（§6）を引き受けます。 残る確認はNode.jsを動かす場所（§8）の1点です。