企業向け IT 資産管理システム構築ガイド：要件整理から導入まで

はじめに

最近、Sarvam AI のプロダクトマネージャーである Neha Kalani 氏が、妹の勤務するスタートアップでの事例を X に投稿しました。そのチームは 3 月に Vibe Coding を使い、Jira に似た社内向けプロジェクト管理システムを自作しました。開発を担当したのは QA リーダーでしたが、最初のバージョンは従来の SaaS ツールよりもチームの使い方に合っており、機能も充実しているように見えました。

ところが 7 月になると、チームは自作システムを手放し、再び Linear へ移行しました。社内システムを継続的に保守するために、あまりにも多くの時間と労力が必要になったためです。

Vibe Coding や AI Coding Agent の普及により、業務システムを構築すること自体はますます簡単になっています。一方で、システムが日常業務に深く入り込むほど、その後の変更や保守にかかるコストは高くなります。

Vibe Coding の柔軟性と、成熟した業務システムの安定性を両立する方法はあるのでしょうか。

💬 NocoBase ブログへようこそ。NocoBase は、あらゆる種類のシステム、業務アプリケーション、社内ツールを構築できる、拡張性に優れた AI 搭載のノーコード／ローコード開発プラットフォームです。完全なセルフホストに対応し、プラグインベースの設計で、開発者にもやさしい構成になっています。→ GitHub で NocoBase を見る

本記事では IT 資産管理システムを例に、実際の要件からデータモデル、資産ライフサイクル、主要ワークフローを整理し、AI を活用して、カスタマイズの柔軟性とシステムの安定性を両立しながら、実務に導入して継続的に改善できる業務システムを構築する方法を紹介します。

1. 実際の業務シーンから IT 資産管理システムの範囲を決める

以降のデータモデル、資産ライフサイクル、ワークフロー設計を具体的にするため、本記事では従業員約 300 名のテクノロジー企業を例にします。

この企業は複数のオフィスで事業を行い、一部の従業員はリモートで勤務しています。IT チームはパソコン、モニター、スマートフォン、周辺機器、ネットワーク機器を一元管理する必要がありますが、現在の情報は Excel、共有スプレッドシート、従業員同士のチャット履歴に分散しています。

日常の資産管理には、主に次のような業務があります。

新入社員の入社時に、利用可能な機器を探して割り当てる
退職時に、本人に割り当てられている資産を確認して回収する
従業員、部門、オフィス拠点の間で機器を移動する
機器に故障が発生した際、修理の経過と結果を記録する
機器の現在地、利用者、状態、保証期限を確認する
過去の貸与、返却、移動、修理履歴を追跡する

これらの業務シーンから、システムが備えるべき 3 つの主要機能を整理できます。

今後、調達やコスト管理まで対象を広げる場合は、仕入先、購入契約、修理費用、資産減価償却、予算などを追加できます。ソフトウェア資産も管理する場合は、ソフトウェアライセンス、アカウント割り当て、利用期限などを追加できます。

2. IT 資産管理システムの基本構造を設計する

業務範囲が明確になったら、次にシステムへ保存するデータ、データ同士の関連、資産ステータス、業務プロセスを整理します。この段階でも AI を利用できます。前述の業務シーンをもとに、AI に主要なデータオブジェクトを特定させ、関係を分解し、資産ステータスと業務プロセスの初期案を作成させたうえで、業務担当者が実際のルールに合わせて確認・調整します。

ここでは、従業員向け機器管理の例を使い、IT 資産管理システムの基本構造を具体的に見ていきます。

1. 資産台帳を中心としたデータ構造を作る

基本的な従業員向け機器管理システムには、主に 3 種類のデータがあります。

その中核となるのが資産台帳です。1 件のレコードが、個別に管理できる 1 つの具体的な資産を表します。資産番号とシリアル番号には一意性ルールを設定し、同じ機器が重複登録されないようにします。

資産カテゴリ、機器モデル、従業員、部門、オフィス拠点のように、複数の資産から繰り返し参照され、一元管理する必要がある情報は、独立したデータテーブルとして作成し、資産台帳と関連付けます。データ量が少なく、管理要件が単純な場合は、ブランド、モデル、仕入先などを資産のフィールドとして保存し、必要に応じて後からデータ構造を変更することもできます。

システムの主要なデータ関係は個別資産を中心に構成され、リレーショナルデータモデルで一般的な複数の一対多関係が含まれます。1 つの資産カテゴリや機器モデルには複数の資産が属し、1 人の従業員は複数の資産を保有できます。また、1 つの資産には、複数の貸与、返却、移動、修理記録を関連付けられます。従業員、部門、オフィス拠点などの基本情報は関連フィールドから繰り返し参照し、仕入先は必要に応じて修理記録と関連付けます。これにより、重複入力を減らし、後から検索や集計を行いやすくなります。

it en-mj1x7z.png

資産台帳には、機器の現在の利用者、部門、オフィス拠点、状態、購入情報、保証情報を保存します。業務記録には、過去の貸与、返却、移動、修理を保存します。各業務操作では、資産台帳を更新すると同時に対応する記録を追加し、現在の情報と過去の変更履歴を一致させる必要があります。

2. 資産ステータスと遷移ルールを定義する

資産台帳には「現在のステータス」フィールドを設定し、機器が現在利用可能か、どの管理段階にあるかを示します。登録、利用、最終的な廃棄までの流れは、現在のステータスと過去の業務記録を組み合わせて表現できます。

ステータスルールを整理する際は、登録、貸与、返却、修理、廃棄などのシーンを AI に渡し、想定されるステータス、遷移経路、同時に更新すべきデータの初期案を作成させることもできます。

基本システムでは、まず 4 種類の資産ステータスを設定できます。

ステータスの変化は、具体的な業務操作によって発生します。

資産登録完了 → 利用可能

利用可能
  └─ 貸与 → 利用中

利用中
  ├─ 返却後の点検に合格 → 利用可能
  ├─ 修理へ送る、または返却後に故障を確認 → 修理中
  └─ 今後利用しないことを確認 → 廃棄済み

修理中
  ├─ 修理完了 → 利用可能
  └─ 修理不能 → 廃棄済み

「利用可能」「利用中」「修理中」「廃棄済み」は資産ステータスです。一方、「貸与」「返却」「移動」「修理へ送る」「修理完了」は業務操作です。業務操作によって資産ステータスが変わる場合もあれば、利用者、部門、オフィス拠点だけが変わる場合もあります。

たとえば、機器の返却後は、点検結果に応じて次のステータスを決めます。正常であれば利用可能に戻し、故障が見つかれば修理中に移し、継続利用できない場合は廃棄済みにします。このように、業務操作とステータス変更は固定された一対一の関係ではありません。

点検、承認、処理待ちが必要な業務では、予約済み、点検待ち、移動待ち、廃棄待ちなどの中間ステータスを追加できます。ただし、その工程で資産が実際に一定期間とどまる場合にのみ、独立したステータスを追加する必要があります。

3. 頻繁に行う業務操作をワークフロー化する

ここまでで、資産台帳の現在情報、業務記録、ステータス遷移ルールを定義しました。ワークフローの役割は、これらのルールを 1 回の完全な操作にまとめ、管理者が資産ステータス、現在の利用者、オフィス拠点、履歴記録を個別に変更しなくてもよいようにすることです。

貸与、返却、修理のいずれであっても、完全な業務操作には通常、次の処理が含まれます。

現在のデータと操作権限を検証 → 資産台帳を更新 → 対応する業務記録を追加 → 通知を送信または後続処理を実行

一般的なワークフローは、次のように設計できます。

移動専用のワークフローを作成するかどうかは、実際の利用頻度に応じて判断します。資産がどの従業員、部門、拠点からどこへ移動したかを明確に記録する必要がある場合は、独立した移動記録を残すことを推奨します。オフィス拠点の変更がまれな場合は、他の操作の中で場所を更新し、変更履歴を保存する方法でも対応できます。

工作流1-ly6gyt.png

ワークフローでは、関連データが同期して更新されることを保証する必要があります。資産貸与を例にすると、現在の利用者、資産ステータス、貸与記録がすべて正常に更新されて初めて、操作が完了したとみなします。途中で問題が発生した場合は変更を取り消し、前後で矛盾したデータが残らないようにします。

機器修理の場合は、ワークフローの実行後に資産ステータスを「修理中」へ変更し、同時に修理記録を作成します。修理記録では、修理業者、修理種別、処理ステータス、費用、完了日時などを追跡します。修理完了後は、結果に応じて資産を「利用可能」に戻すか、「廃棄済み」へ変更します。

ワークフロー 2-ijpa3u.png

4. 管理ダッシュボードで資産状況を集約する

資産台帳と業務記録が蓄積されると、管理ダッシュボードから全体の資産状況を把握し、対応が必要な機器をすばやく見つけられるようになります。

ダッシュボードのデータは、資産台帳と各種業務記録から直接集計できます。たとえば、資産数とステータス分布は資産台帳から、修理傾向は修理記録から取得し、保証期限が近い機器は保証日で絞り込みます。

資産ステータス、カテゴリ分布、変化傾向はグラフ表示に適しています。対応が必要な項目は、保証期限が近い資産、修理中の資産、返却予定日を超過した資産、長期間未割り当ての資産、修理回数の多い機器など、明細リストで表示する方が適しています。

管理ダッシュボード-3cetbu.png

3. AI Agent と NocoBase でシステムを構築する

ここまでで、データモデル、資産ステータスと遷移ルール、業務ワークフロー、管理ダッシュボードの設計が完了しました。次は AI Agent を NocoBase に接続し、これらの設計をデータテーブル、関連関係、ページ、業務操作、ワークフローへ変換します。

1. AI Agent、NocoBase、業務担当者の役割を明確にする

システム構築では、それぞれが異なる役割を担います。

業務担当者は実際の要件を説明し、資産ステータス、操作条件、ロール権限、例外処理ルールを確認します。たとえば、返却後の点検が必要か、部門責任者が閲覧できる資産の範囲、修理中の機器を再割り当てできるかなどは、企業の運用ルールに基づいて決める必要があります。

AI Agent は、これらの業務ルールを実行可能なシステム設定に整理します。NocoBase に接続すると、データテーブルと関連関係の作成、一覧・フォーム・詳細ページの構築、ワークフローと権限の設定を行い、要件変更後も既存構造を調整できます。NocoBase は公式に CLI と Skills を提供しており、Claude Code、Codex、Cursor、OpenCode などの AI Agent がデータモデリング、ページ構築、ワークフロー設計、権限設定に参加できます。

💡 AI Agent を NocoBase に接続する方法は、公式ガイドをご覧ください：https://docs.nocobase.com/ja/ai-builder

NocoBase は、システムの長期運用を支える役割を担います。オープンソースの AI ノーコードプラットフォームとして、データモデル、ページ、ロールとデータ範囲の権限、ワークフロー、定期実行、操作監査などの基本機能を提供し、セルフホストとプラグイン拡張にも対応しています。AI Agent はこれらの既存機能を直接利用できるため、システムごとにアカウント、権限、ページフレームワーク、プロセス実行機構を作り直す必要がありません。

これにより構築速度を高めながら、後から保守・調整できる余地も残せます。システム公開後も、管理者はビジュアル画面からフィールド、ページ、権限、ワークフローを確認・変更できるため、生成コードや 1 回限りの AI 出力への依存を減らせます。

2. AI Agent に初期構築を段階的に進めてもらう

資産管理システムには複数のデータテーブルと業務プロセスが含まれます。すべてを一度に設定すると、細部を見落としやすくなります。まず AI Agent に設計案を出力させ、データ構造とステータスルールを確認したうえで、ページ、ワークフロー、権限、管理ダッシュボードを順番に作成する方法を推奨します。

次の順序で進め、データモデル、資産ステータス、遷移条件、ワークフローを明確にしてから、AI Agent に段階ごとに実行させます。

データモデルを確認
→ 基本ページを作成
→ 業務操作を設定
→ ロールと権限を追加
→ 管理ダッシュボードとリマインダーを構築
→ 業務フロー全体をテスト
→ 本番データをインポート

前述の内容では、管理対象データ、データ同士の関係、資産ステータス、頻繁に行う業務操作を整理しました。次に、以下の Prompt を企業の実情に合わせて調整し、確認済みのフィールド、ステータス、プロセスを書き込んだうえで、NocoBase に接続済みの AI Agent に実行させます。

NocoBase 上で IT 資産管理システムを設計・構築してください。
主にパソコン、モニター、スマートフォン、周辺機器、
ネットワーク機器を管理します。

まず、現在のアプリケーションにあるデータテーブル、ページ、
ワークフロー、権限設定を読み取ってください。
同一または類似する内容がすでに存在する場合は、
重複作成や既存設定の上書きを避けるため、再利用または調整を優先してください。

以下の確認済み業務設計に厳密に従って実行してください。
未確定のルールについては、勝手に補完せず、先に質問してください。

1. データ構造

システムには 3 種類のデータが必要です。

1. 基本情報

- 資産カテゴリ
- 機器モデル
- 従業員
- 部門
- オフィス拠点
- 仕入先（任意）

データを繰り返し参照し、一元管理する必要があるかどうかに基づき、
どの情報を独立したデータテーブルにするべきか、
どの情報を資産フィールドとして保存できるかを判断し、理由を説明してください。

2. 資産台帳

各資産には次の情報を保存してください。

- 資産名
- 資産番号
- シリアル番号
- 資産カテゴリ
- ブランドとモデル
- 現在のステータス
- 現在の利用者
- 現在の部門
- 現在のオフィス拠点
- 機器の状態
- 購入日
- 保証日

資産番号とシリアル番号には一意性ルールを設定してください。

3. 業務記録

システムには次の記録を保存してください。

- 資産貸与記録
- 資産返却記録
- 資産修理記録

資産移動の実際の頻度に基づき、
独立した移動記録が必要かどうかを判断してください。

移動が少ない場合は、利用者、部門、オフィス拠点の変更を
既存の業務記録へ含めることができます。具体的な処理方法を説明してください。

データ関係は次の条件を満たす必要があります。

- 1 つの資産カテゴリまたは機器モデルに複数の資産を関連付けられる
- 1 人の従業員が複数の資産を保有できる
- 1 つの資産に複数の業務記録を関連付けられる
- 必要に応じて、仕入先を資産の調達元または修理記録に関連付けられる

2. 資産ステータスと遷移ルール

基本ステータスは次のとおりです。

- 利用可能
- 利用中
- 修理中
- 廃棄済み

次のステータスは任意です。

- 予約済み
- 点検待ち
- 移動待ち
- 廃棄待ち

各ステータスの意味、移行条件、終了条件、
そのステータスで実行可能な業務操作を説明してください。

ステータス遷移は、次の基本ルールに従う必要があります。

- 資産登録完了後、利用可能になる
- 利用可能な資産は、貸与完了後に利用中になる
- 利用中の資産は、返却後の点検に合格すると利用可能に戻る
- 修理へ送る、または点検で故障が見つかった場合は修理中になる
- 修理完了後は利用可能に戻る
- 継続利用または修理ができない場合は廃棄済みになる

3. 業務操作

システムは次の操作に対応する必要があります。

- 機器の貸与
- 機器の返却
- 機器を修理へ送る
- 修理完了
- 機器の廃棄
- 任意の資産移動

各業務操作では、次の処理が必要です。

- 資産の現在のステータスと操作権限を検証する
- 資産台帳の現在情報を更新する
- 対応する業務記録を作成する
- 必要に応じて通知を送信または後続処理を実行する

資産台帳の更新と業務記録の作成が、
同じ操作内で完了するようにしてください。

実行中に例外が発生した場合は、
現在情報と履歴記録の不整合を防ぐため、変更を取り消してください。

4. ページと管理ダッシュボード

次のページを設計してください。

- 資産管理概要
- 資産一覧
- 資産詳細ページ
- 資産の新規作成・編集フォーム
- 従業員保有資産ページ
- 貸与記録ページ
- 返却記録ページ
- 修理記録ページ
- 任意の移動記録ページ

管理ダッシュボードには、次の内容を表示してください。

- 資産総数とステータス分布
- カテゴリとブランドの分布
- 修理中の資産
- 保証期限が近い資産
- 修理件数と費用
- 従業員または部門別の保有資産状況

関連指標に必要なフィールドがない場合は、
空の指標を直接作成せず、追加すべきフィールドを先に説明してください。

機器の保証期限を追跡する場合は、
保証日を確認する定期実行を設定し、
保証期限が近い資産を管理ダッシュボードに表示してください。

5. ロールと権限

次のロールに対する権限を設計してください。

- IT 管理者
- 一般従業員
- 部門責任者
- システム管理者

各ロールについて、次の内容を説明してください。

- アクセスできるページ
- 閲覧できるデータ
- 実行できる操作
- 変更できるフィールド

一般従業員は、自分が利用している資産のみ閲覧できます。
部門責任者は、自部門内のデータのみ閲覧できます。
IT 管理者は、資産の貸与、返却、修理、廃棄を担当します。
システム管理者は、データ構造、ページ、ワークフロー、権限設定を担当します。

6. 実行方法

段階的に実行してください。

第 1 段階では、次の設計のみを出力し、設定は作成しないでください。

- データテーブルとフィールド
- データテーブル間の関連関係
- 資産ステータスと遷移ルール
- ページ構造
- 業務ワークフロー
- ロールと権限
- 業務担当者による確認が必要な未確定事項

私が確認した後、次の順序で実行してください。

1. データテーブル、フィールド、関連関係を作成する
2. 基本ページを作成する
3. 業務操作とワークフローを設定する
4. ロールとデータ権限を設定する
5. 管理ダッシュボードと保証期限リマインダーを作成する

各段階の完了後に、次の内容を説明してください。

- 完了した内容
- 作成または変更した設定
- 確認が必要な項目
- 未確定の業務ルール

確認を待ってから、次の段階へ進んでください。

AI Agent が設定を完了したら、少量のテストデータを使って業務フロー全体を確認します。

たとえば、機器を貸与した後に、現在の利用者、部門、オフィス拠点、資産ステータス、貸与記録が同時に更新されているかを確認します。機器の返却や修理完了後には、前述の遷移ルールに従って正しいステータスになっているかを確認します。データ関係、ワークフロー、権限が実際の要件に合っていることを確認してから、本番データを取り込みます。

3. 既存データを接続し、公開前の確認を行う

正式なデータ接続前に、定義済みの基本情報、資産台帳、業務記録に合わせてフィールド名、関連関係、ステータス値を統一し、重複データや無効データを整理します。少量のデータで検証した後、資産データ全体をインポートまたは接続します。

既存の資産情報が Excel や共有スプレッドシートに保存されている場合は、フィールドとデータ形式を統一してから一括インポートできます。データがすでに企業データベースや他の業務システムに保存されている場合は、NocoBase のデータソースまたは API から接続し、重複入力を減らせます。

また、実際の職務に応じて権限を設定し、各ロールがアクセスできるページ、実行できる操作、閲覧・変更できるデータを明確にします。NocoBase では、フィールド単位の権限も設定できます。たとえば、一般従業員は自分が利用している資産のみ閲覧し、部門責任者は自部門の資産を閲覧し、IT 管理者は貸与、返却、修理、廃棄を担当します。資産ステータスや現在の利用者などの重要フィールドは、指定されたロールのみが閲覧・変更できるように制限できます。

権限-bmz28n.png

4. AI を日常の資産管理に組み込む

システム公開後も、AI は日常の資産管理に引き続き参加できます。

AI Agent は主にフィールド、ページ、ワークフローの調整に使用します。AI 従業員は NocoBase 内の構造化データをもとに、許可された範囲で情報入力、検索、集計、レポート作成を行います。資産貸与、ステータス変更、機器廃棄、責任確認など、正式なデータを変更する操作は、引き続きシステム権限とワークフローを通じて実行します。

資産情報を自動抽出する

IT 管理者が購入リスト、請求書、資産ラベルの写真、機器引き渡し資料を受け取った後、AI 従業員に機器種別、ブランド・モデル、資産番号、シリアル番号、購入日、保証期限を抽出させ、結果を資産フォームへ自動入力できます。

資産番号、シリアル番号、保証日などの重要フィールドは、引き続き管理者が確認し、一意性ルールと照合して重複や認識ミスがないか確認する必要があります。

自动提取资产信息-vc502w.png

資産を検索し、レポートを生成する

AI 従業員は許可されたデータ範囲内で資産台帳と業務記録を参照し、未使用機器、保証期限が近い資産、修理頻度、部門別の保有状況、修理費用を確認できます。また、一定期間の資産変化を集計し、月次の資産活動レポートを作成できます。

資産レポートの検索と生成-gn7yto.png

より早く始める

機器の種類が少なく、権限や承認フローも単純な場合は、すべての構造をゼロから設計する必要はありません。まず資産範囲、フィールド、ステータス、業務操作、ロール権限を整理し、NocoBase に接続済みの AI Agent に初期版を生成させることができます。また、**NocoBase の軽量 IT 資産管理ソリューション**をもとに、フィールド、ステータス、権限を調整する方法もあります。

資産数や管理要件が増えたら、複数拠点、複雑な権限、完全な履歴追跡、調達、コスト管理などの機能を段階的に追加します。

まとめ

ITAM、ITSM など、長期運用が必要な企業向け業務システムを構築する場合は、NocoBase のように安定した業務基盤と AI 機能を兼ね備えたプラットフォームを選ぶことを引き続き推奨します。安定したデータモデル、権限体系、ワークフローを提供しながら、AI Agent によって構築を効率化し、AI 従業員を運用にも活用できます。これにより、短期間のプロトタイプにとどまらず、実際の業務へ導入し、長期的に運用しながら、管理要件の変化に応じて拡張できるシステムを構築できます。

この記事が役に立った場合は、AI と企業向けシステム構築に関心のある方にもぜひ共有してください。

関連記事：