IT資産台帳の実務ガイド｜社内ルールと責任分界を設計する

業者向け2025/4/5監修：恩拓亮

IT資産台帳の社内ルール設計｜購入から廃棄まで責任と状態遷移を固定する

IT資産台帳を作ったものの、実物と数字が合わない。退職者へ貸与した端末が回収済みか分からない。倉庫には端末があるのに、誰も再利用してよいか判断できない。こうした問題は、台帳の「入力が足りない」ことだけが原因ではありません。多くの場合、資産の状態を誰が、どの証拠に基づいて、いつ変更するかという社内ルールが決まっていないことが根本原因です。

本記事は、総務・情報システム・経理・購買・人事・内部監査の担当者を対象に、IT資産台帳を購入から廃棄まで一貫して運用する方法を解説します。Excel、SaaS、IT資産管理ツールのどれを使う場合でも、先に決めるべきなのは画面や製品ではなく、管理対象、識別子、状態遷移、責任分界、証跡、例外処理です。端末1,000台を管理する具体例も使い、月次照合や棚卸しまで実務に落とし込みます。

IT資産台帳は「一覧表」ではなく業務の現在地である

台帳の役割は、機器名やシリアル番号を並べることではありません。「会社が責任を負うIT資産が、今どの状態にあり、次に誰が何をすべきか」を示すことです。現物、会計記録、利用者、セキュリティ設定、契約、処分証跡を結び付ける基準点と考えると、必要な設計が見えやすくなります。

例えば同じノートPCでも、発注済み、入荷検品待ち、倉庫保管、従業員へ貸与中、修理中、回収済み、データ消去済み、売却済みでは、管理上の意味が違います。「在庫」という一語でまとめると、利用可能な端末と処分待ちの端末が混ざり、調達数や回収率を誤ります。

優れた台帳は、次の質問へ短時間で答えられます。

会社が現在責任を負う端末は何台か
そのうち利用者と保管場所を説明できる端末は何台か
退職・異動・故障に伴い回収すべき端末はどれか
OS更新や暗号化などの管理基準を満たさない端末はどれか
再配布できる端末と、売却・返却・廃棄すべき端末はどれか
データ消去が完了し、証明書まで受領した端末はどれか
会計上の固定資産、リース契約、保守契約と何件一致しているか
一つの変更を、申請者・承認者・実行者・日時まで遡れるか

これらに答えられない場合、入力欄を増やす前に業務ルールを見直す必要があります。

最初に管理対象の境界を文章で決める

台帳の不一致は、「何を載せるか」の認識差から始まります。購入金額や固定資産基準だけで対象を決めると、安価でも情報漏えいにつながるスマートフォン、USBメモリー、モバイルルーターなどが漏れます。反対に、消耗品を一台ずつ管理し過ぎると入力負荷が高まり、重要な端末の更新まで遅れます。

管理対象は、金額だけでなく、データ保持、認証、ネットワーク接続、契約責任、業務停止影響の観点で決めます。少なくとも次を検討します。

PC、スマートフォン、タブレット、サーバー、ネットワーク機器
外付けストレージ、USBメモリー、バックアップ媒体
SIM、eSIM、モバイルルーター、通信回線
ディスプレイ、ドック、充電器など、紛失や再調達を管理したい付属品
仮想マシン、クラウド資源、SaaS契約、管理者アカウント
リース、レンタル、デモ機、取引先からの借用品
BYODなど会社所有ではないが、業務データへ接続する機器
倉庫、店舗、委託先、海外拠点にある機器

すべてを同じ細かさで管理する必要はありません。例えばUSBメモリーは個体管理、一般的なケーブルは数量管理、SaaSは契約単位、クラウド資源は自動収集というように、対象ごとの管理粒度を定めます。「台帳対象外」にする場合も、対象外の理由と代替統制をルールへ明記します。

一つの資産IDを軸に複数の識別情報を持つ

シリアル番号だけを主キーにすると、読取ミス、同梱品との混同、メーカー表記の揺れ、基板交換などで追跡が崩れます。IMEIだけではPCを扱えず、電話番号はSIM交換や解約で変わります。そこで、社内で変わらない資産IDを一つ発行し、外部の識別情報を紐付けます。

推奨する識別情報

社内資産ID：原則として発番後に変更しない
メーカー、製品名、型番、構成
シリアル番号、IMEI、MACアドレスなど該当する個体識別子
購買番号、発注番号、請求書番号、会計資産番号
リース・レンタル・通信・保守の契約番号
MDM、EDR、IdPなど各管理システム上のID
資産ラベルのバーコードまたはQRコード

重複を防ぐため、社内資産IDは必須かつ一意にします。シリアル番号も原則一意ですが、空欄やメーカー側の重複があり得るため、例外登録には理由と承認を求めます。識別情報を修正した履歴は上書きだけで消さず、修正前の値、修正者、日時、理由を残します。

ライフサイクルを状態機械として定義する

台帳精度を上げる最も重要な設計は、状態名と遷移条件の固定です。自由入力の「利用中」「使用中」「貸与」「配布済み」が混在すると集計できません。状態は選択式にし、どの状態からどの状態へ移れるかを決めます。

基本状態の例

申請中：購入やレンタルの申請が提出された
発注済み：承認済みの注文が確定した
受入待ち：納品されたが数量・外観・識別番号の確認前
保管中：受入検品が完了し、配布可能な場所にある
設定中：初期化、更新、暗号化、MDM登録などを実施中
貸与中：利用者または部門へ引き渡し済み
共有利用中：会議室、店舗、検証室などで共同利用中
一時貸出中：期限を定めた短期貸与中
修理中：社内または外部事業者で修理中
紛失・盗難：所在不明で、事故対応を進行中
回収待ち：退職、異動、更新などで返却義務が発生した
回収済み：現物を受け取ったが、検品・消去前
消去中：データ消去または物理破壊を実施中
処分判定待ち：再利用、返却、売却、廃棄の判断待ち
売却・返却・廃棄済み：社外移転または処分が完了した
終了：必要な証跡、会計処理、契約処理まで閉じた

状態を増やし過ぎると運用が難しくなるため、自社の業務で「次の担当者や必要な証拠が変わる地点」に絞ります。色分けよりも、状態の定義、開始条件、終了条件、期限、責任者が重要です。

遷移条件を曖昧にしない

「貸与中」へ変えるには、利用者ID、部門、引渡日、返却予定日、同意記録、資産ラベル確認を必須にします。「消去済み」へ変えるには、消去方式、実施者、日時、結果、証跡番号が必要です。「廃棄済み」へ進めるには、消去済みであること、処分承認、引渡先、引渡日、受領証またはマニフェストを確認します。

正常な遷移だけでなく、禁止する遷移も決めます。例えば、受入検品前の端末を貸与中にしない、紛失中の端末を理由なく保管中に戻さない、消去確認前に売却済みにしない、終了した資産を直接貸与中へ戻さない、といった制約です。誤登録の訂正は、通常遷移と分けて承認付きの訂正処理にします。

所有者・管理者・利用者を分けて記録する

「担当者」一列では責任が曖昧です。少なくとも、資産の業務責任を持つ部門、台帳を更新する管理者、現物を保管する人、実際の利用者を分けます。

役割ごとの責任分界

購買：承認済み発注情報、仕入先、数量、納期、契約条件を登録する
受入担当：現物、納品書、発注内容を照合し、識別番号と外観を確定する
情報システム：初期設定、セキュリティ基準、貸与、回収、消去を管理する
利用部門責任者：業務上の必要性、利用者、異動時の引継ぎを確認する
利用者：適切に使用し、紛失・故障・不要化を報告し、期限までに返却する
人事：入社、異動、休職、退職の確定情報を連携する
経理：固定資産、費用、減価償却、除却、売却代金を会計記録と照合する
セキュリティ担当：例外承認、事故対応、消去基準、監査要件を定める
処分担当：査定、売却、返却、廃棄と証跡回収を行う
内部監査：ルール、記録、権限分離、サンプル現物を独立して検証する

小規模組織では一人が複数役を兼ねる場合があります。それでも、申請・承認・実行の記録上の役割は分け、重要な処分や例外は別の人が承認します。担当者が休職や退職をしても止まらないよう、個人名だけでなく担当グループと代替承認者も設定します。

状態ごとに必須項目を変える

全項目を最初から必須にすると、未確定情報へ仮の値を入れる習慣が生まれます。反対に任意項目ばかりでは、処理完了の判断ができません。状態遷移の際に、その時点で確定できる項目だけを必須にします。

発注・受入時

購入・契約区分、仕入先、発注番号、数量、取得価額
申請部門、費用負担部門、承認者
納品日、受入担当、社内資産ID
メーカー、製品名、型番、個体識別番号
所有権、リース満了日、返却条件、保証期限

貸与・利用時

利用者ID、所属部門、管理責任者
引渡日、返却予定日、利用場所
MDM・EDR登録状態、暗号化、OS基準適合
付属品、端末状態、利用者の受領確認
例外設定、例外期限、承認者

回収・処分時

回収理由、回収依頼日、期限、督促履歴
回収日、回収者、現物状態、付属品
データ消去方式、実施者、日時、結果、証跡番号
再利用・返却・売却・廃棄の判定と承認
引渡先、引渡日、価格または費用、受領証
会計上の除却・売却処理、契約解約、回線停止

自由記述は補足に使い、検索・集計・制御に必要な値は選択肢、日付、数値、参照IDとして持ちます。「不明」を許す場合も、不明理由、調査担当、解消期限をセットにします。

更新元を一本化し、システム間の優先順位を決める

購買システム、人事システム、MDM、会計、ヘルプデスク、倉庫表計算に同じ情報が存在すると、どれが正しいか分からなくなります。項目ごとに正本を定め、他システムは連携値として扱います。

例えば、従業員の在籍・所属は人事システム、発注と仕入先は購買、会計資産番号は会計、端末のセキュリティ状態はMDM、物理的な所在とライフサイクル状態はIT資産台帳を正本にします。連携が失敗した場合、古い値を無言で残さず、最終同期日時、失敗理由、再処理状態を表示します。

自動検出された端末をそのまま正式資産へ昇格させるのも危険です。MDMで見つかった未登録端末は「照合待ち」とし、所有関係や利用者を確認してから正規登録します。反対に台帳にはあるがMDMから一定期間見えない端末は、故障、保管、未接続、登録解除、紛失のどれかを調査します。

変更履歴は上書きではなく追記で残す

監査で必要なのは現在値だけではありません。いつ、誰が、どの申請や証拠に基づいて、何を変更したかです。最低限、変更前後の値、実行者、日時、理由、関連チケット・申請番号を残します。

特に次の操作は、承認と改ざんしにくい履歴を求めます。

資産IDや個体識別番号の訂正
利用者、部門、保管場所の変更
紛失・盗難状態の解除
セキュリティ例外の付与と延長
データ消去結果の確定
売却、返却、廃棄、会計除却
終了済み資産の再開
履歴や添付証跡の削除

通常の担当者が履歴を消せない権限設計にし、管理者による修正も記録します。証明書や受領書はファイル名だけでなく、資産ID、発行元、発行日、対象台数、ハッシュ値などで台帳と結び付けると、取り違えを発見しやすくなります。

例外資産こそルールを先に作る

台帳が崩れるのは、標準端末より例外処理です。例外を自由記述で逃がさず、専用の区分と期限を設けます。

リース・レンタル

会社所有ではなくても、返却義務とデータ消去責任があります。契約番号、所有者、満了日、返却期限、残価・違約条件、返却先を登録し、満了日の90日・60日・30日前に判断できるようにします。買取へ切り替えた場合は所有区分と会計処理を更新します。

BYOD

個人所有端末を会社資産として扱わず、業務接続端末として別区分にします。端末全体ではなく業務データや管理プロファイルの削除確認、利用同意、アクセス終了を記録します。退職時には会社所有端末の回収とは異なる完了条件が必要です。

修理交換・代替機

修理中の元端末と貸出した代替機を別資産として追跡し、関連IDで結びます。メーカー交換で個体識別番号が変わる場合、元の履歴を消さず、交換前後の関係、交換日、保証記録を残します。

共有端末・無人端末

個人利用者がいない端末には、設置場所、業務オーナー、日常点検者、緊急連絡先を設定します。「共有」という利用者名だけでは、所在不明時に誰も対応できません。

紛失・盗難

通常の棚卸し調査とセキュリティ事故対応を分けません。発覚日時、最終確認、遠隔ロック・消去、アカウント停止、通信回線停止、関係部門への報告、警察・保険対応を一つの案件番号で追跡します。発見された場合も、端末の完全性を確認してから再利用します。

データ消去と処分は二つの完了条件を持つ

端末が物理的に社外へ出たことと、データ保護上の処理が完了したことは別です。「業者へ渡した」だけで台帳を終了すると、消去失敗や証明書未回収を見逃します。

個人情報保護委員会の個人情報の保護に関する法律についてのガイドライン（通則編）は、機器や電子媒体を廃棄する際に、復元できない手段による削除や、委託先での実施確認を安全管理措置の例として示しています。自社のデータ分類と記録媒体に応じ、論理消去、暗号鍵破棄、物理破壊などの基準を定めます。

処分完了は、少なくとも次の二段階で管理します。

情報面の完了：データ消去・破壊の結果を確認し、証跡を台帳へ紐付けた
資産面の完了：売却・返却・廃棄の引渡し、会計・契約・回線処理まで終えた

消去失敗端末は売却可能在庫へ混ぜず、再処理または物理破壊へ回します。複数台をまとめた証明書では、証明書上の台数・個体識別番号と引渡し台帳を機械的または二者で照合します。

1,000台の月次照合を数式で管理する

台帳の総数だけが合っていても、状態内訳が誤っていれば意味がありません。前月末残高から当月末残高への増減を、状態遷移の件数で説明します。

例として、前月末に管理中の端末が1,000台あり、当月に購入40台、リース受入10台、売却25台、返却15台、廃棄10台だったとします。会社が責任を負う期末台数は次の通りです。

1,000 + 40 + 10 - 25 - 15 - 10 = 1,000台

一方、台帳の期末有効資産が1,006台なら6台の差異があります。差異を「棚卸差異6台」とだけ記録せず、未登録受入、処分済み未終了、二重登録、契約区分違いなどへ分解します。

さらに、利用中700台、保管中120台、設定・修理中40台、回収待ち35台、回収済み・消去中55台、処分判定待ち50台なら合計は1,000台です。ここで回収待ち35台のうち期限超過が12台、消去中55台のうち基準日超過が8台なら、合計一致だけでは見えない運用リスクがあります。

月次で次の指標を確認します。

総数差異：理論残高と台帳有効件数の差
識別不備率：資産IDや個体識別番号が欠ける割合
利用者不明率：貸与中なのに有効な利用者がいない割合
MDM不一致率：台帳と管理システムで対応しない割合
回収期限超過率：回収待ちのうち期限を過ぎた割合
消去証跡未回収率：消去完了扱いなのに証跡がない割合
長期滞留率：保管、修理、回収、処分待ちが基準日数を超えた割合

差異ゼロだけを目標にすると、担当者が不明項目を仮入力する恐れがあります。差異の原因、解消期限、再発防止まで記録して初めて改善になります。

棚卸しは全件確認とリスク確認を組み合わせる

年1回だけ全件棚卸しを行うと、紛失から発見まで最長一年かかります。重要資産、持出し端末、退職者、長期未接続、処分待ちなどは短い周期で確認し、全件棚卸しと組み合わせます。

実効性のある棚卸し手順

棚卸し基準日時点の対象一覧を凍結する
台帳担当者と現物確認者を可能な範囲で分ける
資産ラベルだけでなく、シリアル番号や端末画面も照合する
利用者回答だけに頼らず、MDMや入退室、修理記録なども突合する
発見できない資産を即座に「確認済み」にしない
差異を所在不明、登録漏れ、二重登録、状態誤り、識別誤りへ分類する
セキュリティ事故の可能性があれば事故対応へ連携する
是正後に再確認し、承認者が棚卸しを閉じる

IPAの中小企業の情報セキュリティ対策ガイドラインは、組織的な情報セキュリティ対策を進める実務資料とともに、資産管理台帳のサンプルを公開しています。また、IPAの組織における内部不正防止ガイドラインは、基本方針、資産管理、技術的管理、事後対策などを体系化しています。自社台帳は、これらを写すだけでなく、自社の業務状態と責任者へ対応付けて使うことが重要です。

導入は「全項目を埋める」より差異を閉じる順で進める

既存台帳が不完全でも、最初から作り直す必要はありません。まず、漏えい・費用・業務停止への影響が大きい資産から、現在地と責任者を確定します。

30日で行うこと

管理対象と対象外、管理粒度を決める
状態一覧と主要な遷移条件を決める
社内資産IDと重複ルールを定める
利用者、保管場所、所有区分、個体識別番号を重点照合する
退職者、所在不明、長期未接続、返却期限超過を抽出する
処分済み候補の消去証跡と会計処理を確認する

60日で行うこと

購買、人事、MDM、会計との正本ルールを定める
状態遷移ごとの必須項目と承認者を設定する
リース、BYOD、修理交換、共有端末の例外フローを作る
月次照合と差異是正の会議体を始める
権限、変更履歴、証跡保存期間を整える

90日で行うこと

バーコードや自動連携で入力負荷を下げる
回収期限、契約満了、長期滞留の通知を自動化する
棚卸しのサンプル確認と全件確認を計画する
KPIを部門別に可視化し、原因と改善策を追跡する
ルールの例外件数と期限超過を経営層へ報告する

ツール選定は、必要な状態遷移、履歴、権限、連携、証跡を定義した後に行います。ツールの標準項目へ業務を無理に合わせるのではなく、重要な統制が実装できるかを確認します。

社内ルールの最終チェックリスト

運用開始前と規程改定時には、次を確認します。

管理対象と対象外が、金額以外のリスクも含めて定義されている
社内資産IDが一意で、変更・再利用のルールがある
状態名、意味、遷移元、遷移先、期限が決まっている
各遷移の必須項目と証拠が決まっている
申請者、承認者、実行者、確認者の責任が分かれている
購買、人事、MDM、会計、台帳の正本項目が決まっている
退職・異動情報が回収業務へ期限付きで連携される
リース、BYOD、共有端末、修理交換の例外処理がある
紛失・盗難がセキュリティ事故対応へ接続される
消去完了と売却・返却・廃棄完了を分けている
処分証跡と会計・契約処理を資産IDで追跡できる
履歴を一般担当者が削除できず、管理者修正も記録される
月次の理論残高と状態別件数を照合している
差異に担当者、原因、期限、是正確認を付けている
長期滞留、回収期限超過、証跡不足を指標化している
規程、手順書、台帳設定、実際の運用が一致している

まとめ：台帳の精度は責任と完了条件で決まる

IT資産台帳を正確に保つ鍵は、入力項目の多さではありません。管理対象を定め、変わらない資産IDを発行し、ライフサイクルを状態として表し、状態が変わる条件・責任者・証拠を固定することです。現在値だけでなく変更履歴を残し、購買・人事・MDM・会計との不一致を月次で閉じれば、台帳は監査のための表から、調達・セキュリティ・再利用・処分を動かす業務基盤へ変わります。

回収後の端末を再利用するか売却するか判断する際は、状態や数量だけでなく市場価値も確認します。中古端末の買取相場を確認することで、保管コスト、データ消去費、売却見込み額を比較し、処分の優先順位を説明しやすくなります。まずは全台帳を完璧にするのではなく、所在不明、退職者貸与、期限超過、証跡不足という高リスク差異から、責任者と期限を付けて一件ずつ閉じてください。