資産台帳は状態の所在であり、ダッシュボードではない

IT資産管理システムは一つの設計決定で生きるか死ぬかが決まる：「現在の真実」はどこにあるのか。NocoBaseが2026年8月に公開したITAMシステム設計ガイド——データモデル、ライフサイクル、ワークフロー——は、資産台帳を中心に据え、すべての業務アクションにその台帳を履歴レコードと並行して原子的に更新することを求めている。ダッシュボードはその機構の下流にあり、代替品ではない。

このガイドの枠組みは真剣に受け取る価値がある。なぜなら、ITAMの最も一般的な失敗モード——誰も信頼しない散在したスプレッドシート——に抗うからだ。機器データがExcelファイル、共有シート、チャットメッセージに散らばる約300人のテクノロジー企業は典型例であり、修正はより洗練されたレポートではない。それは、規則に縛られた遷移と、現在を過去と不整合にできない原子書き込みを伴う、単一の状態の所在である。

資産台帳は状態の所在である

資産台帳はシステム全体の中核である。各レコードは独立して管理できる具体的な資産を表し、資産IDとシリアル番号には一意性規則があり、同じデバイスが二重登録されるのを防ぐ。参照データ——カテゴリ、デバイスモデル、従業員、部門、オフィス所在地——は台帳にリンクされた別コレクションに格納され、一度保守してどこでも再利用される。

これが状態の所在の原則である：「現在のステータス、現在のユーザー、現在の所在地」に権威を持つ場所が一つある。それ以外すべて——割当、返却、修理の各レコード——は履歴であり、状態ではない。台帳は現在、業務レコードは過去である。チームが履歴ログを状態として扱うとき、あるいは台帳と履歴が乖離し誰もどちらを信じるべきか分からなくなるとき、混乱が始まる。

[UNIQUE INSIGHT] ITAMの失敗の多くは機能不足ではなく、状態の所在の不足である。「現在のユーザー」フィールドが3つのスプレッドシートと2つのチャットスレッドに存在するとき、ワークフローで修正できるものは何もない——ワークフローが更新すべき権威ある単一レコードを必要とするか、それは管理ではなく照合している。機能の穴は症状であり、状態の所在の穴が病気である。

Everythink自身のアーキテクチャも同じ原則に立つ。「The space is the router」とは、network→community→roomトポロジーが何かが応答する前にリクエストをルーティングすることを意味する——重なり合う空間へのファンアウトではなく、あるインタラクションに対して一つの解決済みの場所がある。資産台帳はデバイスに対して同じ役割を果たす：「これはどこにあるか、誰が持っているか、どんな状態か」を曖昧さなく答える唯一のレコードである。クエリをまず台帳にルーティングすれば答えは首尾一貫する。3つの場所にルーティングすれば、スプレッドシートに戻る。参照データ——カテゴリ、モデル、従業員、部門、所在地——は独自のコレクションにあり、コピーではなくリンクされるため、部門名の変更は1行の編集であり、500行ではない。

状態遷移は運用化の機構であり、ラベルではない

4状態モデル——Available、In use、Under repair、Retired——は単純に見える。機構はラベルではなく、それらを縛る遷移規則にある。ガイドは、返却されたデバイスが自動的にAvailableになるとは規定しない：システムは点検結果で分岐し、稼働機器をAvailableへ、故障機器をUnder repairへ、使用不能機器をRetiredへ送らなければならない。

業務アクションと状態変更には固定の1対1関係はない。「返却」は点検に応じてAvailable、Under repair、Retiredのいずれで終わることもある。「修理送り」は結果に応じてAvailableかRetiredで終わる。遷移規則が機構であり、ラベルは表示にすぎない。オプションの中間状態——Reserved、Pending inspection、Pending transfer、Pending disposal——は、資産がその段階に実際にしばらく留まる必要があるときだけ追加される。綿密に見せるためだけに存在する状態はノイズである。

これはTheorem 3の縮図である：ある性質（デバイスが状態間で黙って失われることはない）は、その機構（点検分岐の遷移規則）が実装され測定されているときにのみ保証される。「資産ステータスを追跡している」と分岐なしに主張するのは、保証ではなく主張である。保証は、返却されたデバイスを未定義の状態に留めることを拒む規則の中にある。

[PERSONAL EXPERIENCE] 私は遷移規則のない「ステータスフィールド」を納品したチームが、四半期を費やしてフィールドはAvailableと言うのに机は某人の鞄の中だと言うデバイスを照合するのを見てきた。フィールドはラベルであり、機構は欠けていた。修正はより良いフィールドではなく、点検結果なしにステータスを進めることを拒む規則だった。

原子ワークフローが一貫性の機構である

ガイドで最も荷重を担う一文は見落としやすい：「If any step fails, the system should roll back the change to avoid inconsistent data」。完全な業務アクション——割当、返却、修理——は独立した更新の連続ではない。それはトランザクションである：権限を検証し、資産台帳を更新し、業務レコードを作成し、通知を送る。すべてがコミットされるか、何もコミットされないかである。

これが一貫性の機構である。原子性がなければ、台帳を更新したが履歴レコード作成前に失敗したワークフローは、過去のない現在を残す——デバイスは「In use」と表示するが、理由を説明する割当レコードがない。ロールバックがなければ、部分失敗はシステムが排除しようとしたまさにその不整合を生む。ガイドのワークフローパターンは境界を明示する：

Validate current data and permissions → Update the asset register → Create the corresponding business record → Send notifications or trigger follow-up actions

矢印は提案ではなく、トランザクション境界である。台帳更新と業務レコード作成は同じ操作内で完了しなければならない。これはワークフロー層でのTheorem 3である：現在の状態と履歴の間の一貫性は、原子トランザクション機構が実装され測定されているときにのみ保証される。レコードなしで台帳を更新するノーコードページや、ロールバックなしでフォームを起草するAIエージェントは、システムではなくデモである。

転送は頻度の決定であり、教義ではない

転送に専用ワークフローが必要かは頻度による。企業が資産がどの従業員、部門、所在地からどこへ移動したかの明確な記録を必要とするなら、別個の転送レコードが推奨される。所在地が滅多に変わらなければ、別の操作の一部として所在地を更新し履歴を保存できる。機構は履歴レコードであり、ワークフロー数はチューニングパラメータである。決して使わない転送ワークフローを追加するのは、決して入らない状態と同じノイズである。

Everythinkの永続化層は同じ規律に従う。SistersはPostgresに直接書き込まない——SisterOutputを返しLoomが永続化するため、シミュレーション行とそのシナリオは一緒にコミットされるか、まったくコミットされない。資産台帳の原子ワークフローは、この規則のITAMインスタンスである：一人の書き手、一つのトランザクション、一つの一貫した状態。その境界を越えれば、自分のデータベース内で、置き去りにしたスプレッドシートの不整合を再現することになる。

ダッシュボードは台帳を読む；台帳を生産しない

管理ダッシュボードはITAMシステムで最も目立つ部分であり、最も過大評価されている部分である。ガイドはここで慎重である：ダッシュボードのデータは資産台帳と業務レコードから集計される。合計件数とステータス分布は台帳から、修理の傾向は修理レコードから、保証期限のフィルタは保証日付から来る。ダッシュボードは読み手であり、書き手ではない。不整合なデータを一貫させることはできない；すでにどれだけ一貫しているかを晒すことしかできない。

[UNIQUE INSIGHT] 古い、あるいは断片化された台帳の上に構築されたダッシュボードは信頼の罠である——不整合な基盤の上に精密な数値を提示する。修正は決してより良いグラフではなく、よりきれいな台帳とそこへの原子書き込みである。ダッシュボードから始めるチームは、一貫性機構が存在する前に運用可能に見えるシステムを構築し、1ヶ月以内に数値が現実から乖離する理由を不思議がる。

だからガイドは構築の順序を定める：データモデルを確認し、次にページ、次に業務アクション、次に権限、最後にダッシュボード。ダッシュボードは最後であり、下流にある。例えば保証期限のビューは、保証日付を確認し期限が迫る資産を表示するスケジュールタスクを必要とする——だがそのタスクは台帳の保証フィールドを読む。フィールドが欠落または不整合なら、タスクは空か誤解を招くメトリックを生み、ガイドはそう言う：「If a metric does not have the required fields, first explain which fields need to be added. Do not generate an empty metric directly.」

正直な成熟度の対応付けがここでは重要である。よく保守された台帳を読むダッシュボードはProduction ✅である——一貫したストアに対する読み取りである。「AI抽出された資産情報」を、管理者が一意性規則に対して資産IDとシリアル番号を確認せずに約束するダッシュボードは、せいぜいPartial ⚠️である——抽出は草案であり、確認が機構である。ガイドは明示する：重要フィールドは管理者が確認し、重複や認識エラーをチェックすべきである。抽出は入力を加速する；ゲートを置き換えない。

権限スコープがデータをルーティングする；ページではない

ガイドの権限設計は可視性のトグルではなく、ルーティング機構である。一般従業員は自分に割り当てられた資産のみを見る；部門管理者は自部門の資産のみを見る；IT管理者は割当、返却、修理、廃棄を扱う；システム管理者は構造を管理する。フィールドレベルの権限は、誰が資産ステータスや現在のユーザーを閲覧・変更できるかを制限できる。

これはデータスコープのルーティングである：誰が尋ねるかによって同じページが異なるデータを描画する。なぜなら権限スコープがページ描画前にクエリをルーティングするからだ。これは「the space is the router」のアクセス制御インスタンスである——役割がデータをルーティングし、ページは単なるレンダラである。すべてをすべての人に見せ、ユーザーの規律に頼って無視させるシステムには機構がない；希望があるだけである。

EverythinkのRBACは同じ形に従う：一つの関数can(role, action)、役割継承なし、3層で強制——アプリごとのallowedRolesホワイトリスト、ミドルウェア、サイトでのcan()。ITAMの権限スコープは資産データに適用された同じアイデアである：役割が台帳のどのスライスを読めるかを決め、そのスライスはページが構築される前に決まる。資産ステータスや現在のユーザーのような重要フィールドは、指定された役割だけが変更できるよう制限でき、それが同じルーティング規則のフィールドレベル・インスタンスである。

AIは構造を起草する；機構がシステムを届ける

ガイドで最も正直な節は、AIの役割に関する部分である。AIエージェントはコレクション、関連、ページ、ワークフロー、権限を起草できる。だがガイドは段階的実行を主張する：まず設計、確認、次に段階的に構築、小さなデータセットでテストし、それから生産データをインポートする。「For any rules that are still unclear, ask questions first and do not fill in the gaps yourself.」

これが正しい役割分担である。AIは速い構造の起草者であり、一貫性機構ではない。機構は原子ワークフロー、遷移規則、権限スコープ、一意性制約——実装され測定されるときに性質を保証するもの——である。AIは履歴レコードを作成せずに台帳を更新するフォームを生成できる。そのフォームはシステムではなくバグであり、段階的規律が本番前にそれを捕らえる。

ガイドのプロンプトテンプレートはこれを強制する：第一段階は設計のみを出力する——コレクション、フィールド、関連、ステータス、遷移規則、ページ構造、ワークフロー、役割、未解決の質問。設計が確認されるまで構成は作成されない。確認後、構築は順序通りに進む：コレクションとフィールド、次に基本ページ、次に業務アクションとワークフロー、次に役割と権限、次にダッシュボードと保証リマインダー。各段階の後、エージェントは何が完了したか、何が変更されたか、何を確認すべきか、どの業務規則が未決定かを説明する。続行前に確認を待つ。これはspec-before-codeであり、AI生成システムが実運用との接触で生き残る唯一の理由である。

Honest Architectのこれに対するタグ：安定したプラットフォーム上でのAI支援による業務システムの起草はPartial ⚠️である——実装を加速するが、保証はプラットフォームのデータモデル、権限、ワークフロー実行にあり、生成出力にはない。それらの機構を提供するプラットフォーム（NocoBaseは自身の記述通りそうする）がProduction ✅の層であり、AIの草案はその上の加速である。両者を混同することが、チームがシステムを運用する代わりにプロトタイプを保守することになる道である。ローンチ後も線は保たれる：AI従業員は認可されたスコープ内でデータ入力、照会、レポートを扱うが、公式記録を変更する操作——割当、ステータス変更、廃棄——は依然として権限とワークフローを通じて実行される。草案はAI；コミットはワークフローである。

Everythinkがここから借りるもの

このガイドの3点が、私たちの構築方法に直接対応する。

第一に、状態の所在の原則。Everythinkのnetwork→community→roomトポロジーは資産台帳の類似である：いかなる応答者が発言する前にも、あるインタラクションに対して解決済みの場所。The space is the router。roomにルーティングできないリクエストは首尾一貫して答えられない。それは「現在のユーザー」が3つの場所にあるデバイスが首尾一貫して管理できないのと同じである。HAI Engine ✅、2016年から本番稼働中、は何かが応答する前にその場所を解決する安定した基盤である——ガイドが長期稼働システムが提供すべきと言うデータモデル、権限、ワークフロー実行に相当する。

第二に、原子トランザクションの規律。Loomはシミュレーションとそのシナリオを一つのトランザクションで永続化するか、まったくしないかである。資産台帳のワークフローは台帳更新と履歴レコードを一緒にコミットするか、ロールバックする。The Oracle ✅は正確に一つの場所で確率を正規化する——和が1、降順ソート、エントロピーはナット——そしてすべての消費者がその保証に依存する。これらは異なるスケールの同じ規則である：性質は機構が実装され測定されている場所で保証される（Theorem 3）。The 21 papersはプラットフォーム全体でこれを体系化し、ITAMガイドは資産データのためにそれを再発見する。

第三に、権限スコープをルーティングとするパターン。Everythinkのcan(role, action)はいかなるUIが描画される前にもユーザーが何できるかをルーティングする；ITAMの権限スコープはページが構築される前にもユーザーがどの資産を見られるかをルーティングする。役割はルータであり、ページはレンダラである。World Monitor ✅は地理シグナルに同じ規律を適用する：クライアントは上流ではなくキャッシュを読み、ユーザーごとの接続上限が誰がどのタイルを見るかをルーティングする。

まだそこにないものについては率直である。Wallet & Token 🔵、Super App 🔵、Community Credit 🔵はRoadmapである——収益前、Howey審査対象、結果として約束されていない。ITAMガイドの、何が安定し何が草案かを言う規律は同じである：Roadmap項目は決して暗黙に能力へ昇格されず、Partial機構は決してProductionに偽装されない。

主要な要点

• 資産台帳は状態の所在である——唯一の権威ある「現在の真実」。それ以外はすべて履歴である。単一の状態の所在のないシステムは管理ではなく照合している。
• 状態遷移は運用化の機構であり、ラベルではない。保証は分岐規則（点検 → Available / Under repair / Retired）の中にあり、ステータスフィールドの中にはない。
• 原子ワークフローが一貫性の機構である。台帳更新と履歴レコードは一緒にコミットされるか、ロールバックされる。それがなければ、システムは排除すべく構築されたスプレッドシートの不整合を再現する。
• ダッシュボードは台帳を読む；台帳を生産しない。まず台帳とワークフローを構築せよ；ダッシュボードは最後であり、下流にある。
• 権限スコープはページ描画前にデータをルーティングする。役割はルータであり、ページはレンダラである。
• AIは構造を起草する；機構がシステムを届ける。段階的に実行せよ——設計、確認、次に構成——して、原子ワークフローが草案の誤りを捕らえるようにする。

よくある質問

なぜAIエージェントにITAMシステム全体を一括で生成させないのか？ 一貫性機構——台帳を更新し履歴レコードを一つのトランザクションで作成する原子ワークフロー——が、黙って壊れる部分だからである。レコードなしで台帳を更新する生成フォームは、機能に見えるバグである。段階的実行（まず設計、確認、次に構築）が、生産データがシステムに入る前にそれを捕らえる。

何が資産台帳を単なるテーブルではなく「状態の所在」にするのか？ テーブルはデータを格納する；状態の所在は「このデバイスの現在のステータス、ユーザー、所在地は何か」に対する唯一の権威ある回答である。台帳がその質問に答える唯一の場所であるとき、すべてのワークフロー、ダッシュボード、権限スコープがそれを通じてルーティングできる。3つの場所が答えるとき、いかなるワークフローも確実に照合できない。

別個の転送ワークフローは必要か？ ガイドの答えは頻度に基づく：転送が頻繁なら、別個の転送レコードが明確な移動元-先の痕跡を保存する；所在地がめったに変わらなければ、変更を別の操作に折り込み履歴を保存する。機構は履歴レコードであり、ワークフロー数ではない。

これはEverythinkのアーキテクチャとどう結びつくのか？ 同じ3つの原則が再現する：「the space is the router」（いかなる応答の前の解決済みの場所）、原子永続化（Loomはシミュレーションとそのシナリオを一緒にコミットするかしないか）、権限スコープのルーティング（can(role, action)がUI描画前にユーザーが何できるかを決める）。資産台帳は状態の所在の原則のITAMインスタンスである。

ダッシュボードは台帳を代替できるか？ できない。ダッシュボードは台帳と業務レコードを集計する；不整合なデータを一貫させることはできない。断片化した基盤の上の精密なグラフは、管理システムではなく信頼の罠である。

ルーティング・トポロジーが——照合されたスプレッドシートの山ではなく——何が応答するかを決めるネットワークを求めるなら、Everythinkであなたのネットワークを作成してください。

Sources

• NocoBase, « How to Design an IT Asset Management System: Data Model, Lifecycle, and Workflows », 2026年8月 — https://www.nocobase.com/en/blog/enterprise-it-asset-management-system-guide