1システム概要
FM Compass は、複数棟のビル維持管理を一つの画面にまとめる IFM（Integrated Facility Management）クラウドです。建物ごとに分散しがちな「契約中のサービス」「法定点検の期限」「進行中の工事案件」「業者の連絡先」を同じ台帳の上に置き、案件を発生から支払・帰檔まで同じ流れで追跡します。本書は、導入をご検討中の企業の技術担当者や同業の技術者の方に向けて、システムの構成・設計上の判断・現時点での限界を、公開できる範囲で説明するものです。
| 項目 | 内容 |
|---|---|
| 名称 | FM Compass（複雑なビル管理を、ひとつの羅針盤で。） |
| 位置づけ | IFM 複数棟ビル管理クラウド。ブラウザで利用する業務台帳システム |
| 提供形態 | ウェブアプリケーション。アカウントは申請・承認制（インストール作業なし） |
| 現行版 | v0.2.1 稼働中 |
| 技術構成 | ブラウザ側＝素の JavaScript による単一ページアプリケーション／サーバー側＝PHP／保存＝JSON ファイル（データベース不使用） |
| 画面数 | 7 画面（管理者はユーザー管理を加えた 8 画面） |
| 案件管理 | 9 段階のライフサイクルで進捗を管理 |
| 運営 | PPAP株式会社（東京都中央区東日本橋2-6-5） |
画面構成
| # | 画面 | 役割 |
|---|---|---|
| 1 | ダッシュボード | 4 つの KPI タイル（P1 合規レッドライン／P2 期限接近／消防対応 F1-F8 の各未完了件数と、状態が「進行中」の案件数）、未完了 P1 の最優先アクション一覧、注意・危険ステータスのサービス一覧、進行中案件とその現在段階 |
| 2 | 建物 | 管理対象の建物ごとの基本情報カード。未完了 P1 件数・注意サービス件数・進行案件数を併記 |
| 3 | サービス台帳 | 契約中の保守・点検サービスの一覧。建物での絞り込みとキーワード検索 |
| 4 | 案件（全流程） | 9 段階を列に並べたボード。カードをクリックして編集と段階移動 |
| 5 | リスク・行動 | 優先度（P1／P2／P3／F消防）別の行動清単。未完了のみ表示の切替 |
| 6 | 年間カレンダー | 1 月〜12 月と「随時」に、法定・契約上の定期作業を配置 |
| 7 | 連絡先 | 業者・役所の連絡先。電話とメールはリンクから直接発信 |
| 8 | ユーザー管理 | 管理者のみ。登録申請の承認・却下、無効化、権限変更、削除 |
案件のライフサイクル
維持管理の案件は、必要性の確認から支払・帰檔まで 9 段階で管理します。段階を移動させると、その案件の履歴に日付付きの記録が自動で追記されます。
| 段階 | 名称 | その段階で確かめること |
|---|---|---|
| 1 | 必要性確認 | そもそもその工事・点検が必要か。法定義務か、任意の改善か |
| 2 | 合規・最適化研究 | 法令上の要求水準と、まとめ発注などの最適化余地 |
| 3 | 業者調査 | 依頼先の候補と実績 |
| 4 | 見積評価 | 金額・内訳・前提条件 |
| 5 | 代替案分析 | 他の工法・他社・見送りという選択肢との比較 |
| 6 | 交渉 | 金額と条件の詰め |
| 7 | 工期管理 | 着工から完了までの進捗 |
| 8 | 完工確認 | 現物と書類の確認 |
| 9 | 支払・帰檔 | 支払と、証憑の保管 |
この 9 段階は画面の見た目だけの区分ではなく、案件データが持つ段階番号そのものです。ダッシュボードの「進行中の案件」も、この段階番号を参照して現在地を表示しています。
2アーキテクチャ
構成は三層です。ブラウザ上の単一ページアプリケーションが画面を描き、PHP のエンドポイントが認証とデータの読み書きを担い、データはサーバー上の JSON ファイルとして保存されます。常時動き続ける部品を意図的に減らし、障害が起こり得る箇所を絞る方針をとっています。
| 層 | 役割 | 備考 |
|---|---|---|
| ブラウザ側 | 画面の描画、入力フォーム、絞り込みと検索 | フレームワークもビルド工程も使用しない。検索の絞り込みは読み込み済みデータに対して行うため、入力のたびに通信は発生しない |
| 認証エンドポイント | ログイン、登録申請の受付、セッションの発行 | セッションは Cookie ベース。ログイン成功時に識別子を再発行 |
| API エンドポイント | 台帳データの読み書き、ユーザー管理操作 | すべてのリクエストで利用者の権限と状態を再確認する |
| ストレージ | JSON ファイルとして保存 | データベースサーバーを使用しない。保存の直前に必ず世代バックアップを作成 |
| メール通知 | 登録申請の管理者通知、承認時の開通通知 | この 2 通のみ。期限のリマインドメールは送信しない |
| リクエスト | 動作 |
|---|---|
| 取得（GET） | 6 コレクションをまとめて返す。管理者の場合はユーザー一覧も含むが、パスワードのハッシュは取り除いたうえで返す |
| 保存（POST・データ） | 種別とデータを受け取り、そのコレクション 1 つを丸ごと置き換える |
| 操作（POST・ユーザー） | 承認・却下・無効化・有効化・権限変更・削除、および本人のパスワード変更 |
3技術選択とその理由
この規模の業務システムで最も高くつくのは、開発費そのものよりも「数年後に触れなくなること」だと考えています。そのため、部品点数を増やす方向の技術選択は意識的に避けています。以下に、その選択の理由と、引き換えに受け入れたトレードオフを併せて記します。
| 選択 | 理由 | 受け入れたトレードオフ |
|---|---|---|
| データベースを使わず JSON ファイル | 対象は複数棟のビル管理であり、扱うのは点検・契約・案件といった件数の限られた台帳。データベースを持つと、バックアップ・移行・障害対応の手間が扱うデータ量に見合わなくなる。ファイルなら中身をそのまま読めるため、障害時の確認も移行も単純になる | 大規模な同時編集には向かない。件数が桁違いに増えた場合や、多人数が同時に同じ台帳を書き換える運用になった場合は、データベースへの移行が必要になる |
| フレームワークを使わない素の JavaScript | この種の長期運用ツールが動かなくなる原因は、機能不足よりも周辺ツールの陳腐化であることが多い。ビルド工程を持たなければ、数年後もファイルを開いてそのまま直せる | 大人数での並行開発や、複雑な画面状態の管理には向かない。画面が増えるほど記述量は増える |
| サーバー側は PHP のみ | 一般的なレンタルサーバーでそのまま動き、常駐プロセスの監視が要らない。稼働に必要な前提が少ないほど止まりにくい | 常時接続を前提とした機能（他の利用者の編集内容をリアルタイムに反映するなど）は実現できない |
| 外部の CDN やライブラリを読み込まない | 外部サービスの障害や仕様変更で画面が壊れることを避けるため | 既製の UI 部品が使えないぶん、画面は素朴になる |
| 保存はコレクション単位の全置換 | 処理が単純で、保存の直前に必ず「元の状態」をバックアップできる。差分適用の失敗による中途半端な状態が発生しない | 同じコレクションを同時に編集した場合、後から保存した内容で上書きされる |
同時編集の扱いを、あらかじめ明記します。二人が同じ画面を開いたまま別々に編集し、続けて保存した場合、後に保存した側の内容で上書きされます（先に保存した変更は失われます）。保存の直前に世代バックアップを取っているため以前の状態に戻すことはできますが、その復旧は画面上の機能ではなく、管理者による手作業です。少人数での運用を前提とした割り切りであり、同時編集の制御そのものは現行版では行っていません。
| 使っていないもの | 理由 |
|---|---|
| データベースサーバー | 現在のデータ量では利点より運用負担が上回る |
| フロントエンドのフレームワーク | 長期の保守性を優先 |
| ビルドツール・パッケージ管理 | 工具の陳腐化がそのまま保守不能につながるため |
| 外部 CDN | 依存先の障害を持ち込まないため |
4データモデル
データは 6 つのコレクションと、それとは別に管理されるユーザー情報で構成されます。各コレクションは独立したファイルとして保存され、相互の関係は建物 ID による参照だけです。構造を単純に保つことで、内容を人が直接読んで確認できる状態を維持しています。
| コレクション | 主な項目 | 説明 |
|---|---|---|
| buildings 建物 | 名称／所在地／竣工／階数／面積／用途／管理体制／消防区分／昇降機／備考 | 他のすべてのコレクションが参照する基準。建物 ID で紐づく |
| services サービス台帳 | 建物／サービス名／業者／頻度／費用／状態／課題・備考／出典 | 状態は 稼働／注意／危険／要確認／完了。出典欄には、その費用の根拠となる書類を記録する |
| actions リスク・行動 | 優先度／番号／建物／事項／アクション／期限／状態／備考 | 優先度は P1（合規レッドライン）／P2（期限接近）／P3／F消防 の 4 区分 |
| cases 案件 | 建物／案件名／段階（1〜9）／業者／金額／期限／状態／メモ／履歴 | 履歴は日付付きで蓄積される。段階を移動させると自動で 1 行追記される |
| calendar 年間カレンダー | 月／建物／作業内容 | 月は 1月〜12月と「随時」。定期作業を年間で俯瞰する |
| contacts 連絡先 | 名称／役割／電話／メール／備考 | 業者・役所の窓口を建物横断で保持 |
| users ユーザー | 氏名／メール／所属／役割／状態／申請日／承認日 | 台帳とは別に管理。パスワードはハッシュ化して保持し、画面には一切返さない |
「出典」欄という設計判断
サービス台帳の費用欄には、金額だけでなく、その金額の根拠となった書類を必ず併記する運用にしています。口頭の記憶や過去の請求実績だけで金額を台帳に載せない、というのが設計上の前提です。
| 建物 | サービス | 業者 | 頻度 | 費用（出典付） | 状態 |
|---|---|---|---|---|---|
| 中央第2ビル | 消防用設備等点検 | 〇〇設備サービス | 年2回 | ¥120,000／回（2026-03 見積書） | 稼働 |
| 中央第2ビル | 昇降機保守（フルメンテ） | △△エレベータ工業 | 月次 | ¥45,000／月（2025-04 契約書） | 稼働 |
| A ビル | 貯水槽清掃 | □□環境管理 | 年1回 | 金額未確認（見積書待ち） | 要確認 |
この書き方であれば、「なぜこの金額なのか」を後から遡れます。裏付けの書類がまだ無いものは、金額を書かずに「要確認」として残します。
運用上の原則として、法定項目は「実施した」ではなく「報告書・受理印のある控えを保管した」時点で完了とみなしています。また、一定額を超えるサービスは自動更新せず、定期的に相見積もりを取り直す前提で台帳を組んでいます。これらはシステムが強制する仕組みではなく、台帳の項目設計がその運用を支える形になっています。
5認証とアクセス制御
アカウントは申請・承認制です。誰でも登録フォームから申請できますが、管理者が承認するまでログインはできません。承認・無効化などの状態変更は、次のリクエストからただちに反映されます。
| 項目 | 仕様 |
|---|---|
| 認証方式 | メールアドレスとパスワードによるログイン。認証状態はサーバー側のセッションで保持する |
| セッション Cookie | スクリプトから読めない設定（HttpOnly）、HTTPS 接続時のみ送信（Secure）、外部サイトからの遷移では送らない設定（SameSite=Lax） |
| パスワード | 登録時は 8 文字以上。ハッシュ化して保存し、平文では保持しない |
| パスワード変更 | 利用者が画面上の鍵ボタンから自分で変更する。現在のパスワードの入力が必要 |
| 権限 | 一般ユーザーと管理者の 2 種類。ユーザー管理画面と利用者一覧の取得は管理者のみ |
| 状態の即時反映 | リクエストのたびに利用者の状態を確認するため、無効化するとその時点から操作できなくなる（セッションの期限切れを待たない） |
| 自己ロック防止 | 管理者は自分自身を降格・無効化・削除できない。管理者が全員いなくなる事故を防ぐ |
| 状態 | ログイン | 管理者ができる操作 | 自動メール |
|---|---|---|---|
| 承認待ち | 不可 | 承認／却下 | 申請時に管理者へ通知が届く |
| 有効 | 可 | 無効化／権限変更 | 承認した時点で本人に開通メールを送信 |
| 無効 | 不可 | 有効化／削除 | 送信しない |
| 却下 | 不可 | 有効化／削除 | 送信しない |
6データ保護
台帳は日々書き換えられるものなので、「壊れないこと」よりも「壊れても戻せること」を優先しています。保存のたびに直前の状態を残す仕組みが、その中心です。
| 対策 | 内容 | ねらい |
|---|---|---|
| 保存前の自動バックアップ | 台帳を保存する直前に、変更前のファイルを日時付きでコピーする。コレクションごとに最新 20 世代を保持し、古いものから自動的に削除する | 誤操作・誤削除・上書きからの復旧。世代が残るため「いつの状態に戻すか」を選べる |
| 通信の暗号化 | HTTPS を必須とし、暗号化されていない接続は自動的に HTTPS へ転送する。ブラウザに対して以後も HTTPS を使うよう指示する（HSTS） | 通信経路上での盗聴・改ざんの防止 |
| パスワードのハッシュ化 | パスワードはハッシュ化して保存し、復元できる形では持たない。旧方式で保存されていたものは、本人のログイン成功時に現行方式へ自動的に置き換える | 保存データが読まれた場合でもパスワードそのものは復元されない |
| 書き込みの排他制御 | ファイルへの書き込み時にロックをかける | 書き込みの途中で内容が混ざることを防ぐ |
| 応答ヘッダの指定 | コンテンツ種別の推測禁止（nosniff）、他サイトへの枠内表示の制限（SAMEORIGIN）を指定 | ブラウザ側の解釈のぶれに起因する事故を減らす |
| 復元 | 画面上に復元ボタンは設けていない。バックアップからの復元は、管理者がサーバー上の世代ファイルを戻す手作業で行う | 誤操作による意図しない巻き戻しを防ぐため。復旧には管理者の対応時間が必要になる |
バックアップは同一サーバー上の世代コピーです。別のサーバーや別拠点への遠隔複製は行っていません。災害対策としての多拠点保管が要件になる場合は、別途の構成が必要になります。
7セキュリティ上の考え方
基本方針は 2 つです。ひとつは、権限の判定を必ずサーバー側で行うこと。画面にボタンを出さないことは補助にすぎず、それを防御とは考えていません。もうひとつは、利用者が入力した文字列を常に「データ」として扱い、決してそのまま画面の構造として解釈させないことです。v0.2.1 では、この方針に沿って以下を反映しました。
| 方針 | v0.2.1 での対応 |
|---|---|
| 入力値は常にデータとして扱う | 台帳のすべての項目について、画面に表示する際に文字列をエスケープする。入力された内容が画面の構造として解釈されることはない |
| 認証の境界で識別子を切り替える | ログインに成功した時点でセッション識別子を再発行し、ログイン前の識別子をそのまま引き継がない |
| 通信経路を固定する | HTTPS を必須とし、Cookie は HTTPS 接続時のみ送信する設定にした |
| 保存方式は新しい方へ寄せる | 旧方式のパスワードハッシュを、本人のログイン成功時に現行方式へ移行する |
| 権限はサーバー側で判定する | 管理者専用の操作は、リクエストのたびにサーバー側で役割と状態を確認する。利用者一覧を返す際は、パスワードのハッシュを取り除いてから返す |
| 管理者を締め出さない | 管理者が自分自身を降格・無効化・削除することを禁止し、誰も管理できない状態が生まれないようにした |
本書は方針と対応の範囲を示すもので、攻撃手法の詳細には触れていません。また、これらの対策をもって「絶対に安全」と主張するつもりはありません。安全性は一度きりの作業ではなく、継続的な見直しの対象と考えています。
8制約と今後
現行版でできないことを、そのまま列挙します。以下は「将来やらない」という意味ではなく、現時点では存在しない機能という意味です。
| 項目 | 状況 | 現在の扱い |
|---|---|---|
| 建物の追加・削除の画面 | 未実装 | 建物データの追加・削除は、管理者がデータファイルを直接編集して行う。画面からは閲覧のみ |
| 書類・領収書のファイル添付 | 未実装 | 「出典」欄に書類名を文字で記録する運用。ファイルそのものはシステム外で保管する |
| パスワードの自己リセット | 未実装 | パスワードを失念した場合は管理者へ連絡する。ログイン中の変更は可能 |
| 期限リマインドのメール送信 | 未実装 | 期限の把握はダッシュボードとカレンダー画面を開いて確認する。通知は届かない |
| 画面からのバックアップ復元 | 未実装 | 世代バックアップは自動で取得されるが、戻す操作は管理者の手作業。利用者が画面から復元することはできない |
| 操作履歴（監査ログ） | 未実装 | 誰がいつ変更したかの記録は残らない。案件の履歴欄は利用者が記入するもの |
| 多言語切替 | 未実装 | 画面は日本語のみ |
| モバイルアプリ | 未実装 | ブラウザから利用する |
| AI 機能 | 未実装 | 自動分類・自動要約・自動提案の類は一切持たない |
| 外部システム連携・自動取込 | 未実装 | 会計システムや他の管理システムとの連携、データの自動取込は行わない。入力はすべて手作業 |
| 同時編集の制御 | 未実装 | 同じコレクションを同時に編集した場合、後から保存した内容で上書きされる（第 3 章参照） |
上記は 2026-08-19 時点の事実であり、実装の時期を約束するものではありません。仕様・構成に関するお問い合わせは vip.contact@ppap.biz までご連絡ください。