本文へ移動
購読
GUIDE#biz更新 2026.09.24

IT資産管理の始め方:台帳の作り方とOSSツール(Snipe-IT)での運用手順

必須7項目に絞ったIT資産台帳のテンプレートと、OSSのSnipe-ITをDocker Composeで構築して貸出・返却・QRコード棚卸し・バックアップまで回す手順を、情シスの運用目線でまとめました。

level
初級
time
約25分
stack
Snipe-IT / Docker Compose
author
@ryoma_t
// 前提条件
Docker Composeの基本操作 / Linuxサーバーへのログインとファイル編集
Snipe-ITの資産一覧画面
画像:nagoya.dev(実際の画面・実行結果をもとに作成)

IT資産管理とは、会社が保有するPC・サーバー・ネットワーク機器・ソフトウェアライセンスを台帳に載せ、購入から廃棄までの所在と状態を追い続ける業務です。「ノートPCは全部で何台ありますか」に即答できない状態は、パッチ適用漏れ、退職者の端末未回収、ライセンスの二重購入のどれかがすでに起きている状態だと考えてください。

台帳はExcelでも始められますが、貸出・返却の履歴と棚卸しの記録まで残そうとすると担当者が2人になった時点で破綻します。必須7項目のテンプレートを決めてから、オープンソースのSnipe-ITをDocker Composeで立ち上げ、実際の導入と同じ順番で運用に乗せていきます。

この記事でわかること

  • 台帳が開かれる3つの場面から逆算して項目を絞る判断基準
  • 必須7項目の台帳テンプレートと、修理や再キッティングでも変わらない資産タグの採番ルール
  • Snipe-ITとMariaDBをDocker Composeで起動する設定ファイルと初期化コマンド
  • 会社→拠点→カテゴリ→モデルの順に登録する理由と、貸出・返却・ライセンスの記録方法
  • QRコードラベルで棚卸しを回す手順、バックアップと監査対応、導入初期のつまずきポイント

台帳が開かれる場面から項目を決める

項目を決める前に、台帳を「誰がどの場面で開くのか」を書き出します。使う場面のない項目は登録の負担にしかならず、半年後には空欄になるからです。実務で台帳を開く場面は次の3つにほぼ集約されます。

  • セキュリティ:EDRやMDMの導入率を出すときの分母は台帳の台数です。退職者が出たら退職日の前日に「貸出中の資産」を抽出して返却チェックリストを作り、紛失時はシリアル番号から暗号化の有無と保存データの範囲を判断します。
  • コスト:保証切れ端末の修理費が新品価格に近づいていないか、余っているライセンスシートがないか、別拠点に在庫があるのに新規購入していないかを、購入日・金額・ステータスの組み合わせで見つけます。
  • 監査:ISO/IEC 27001:2022の管理策5.9は情報資産の目録と管理責任者の明確化を求め、ソフトウェアベンダーのライセンス監査ではインストール台数と保有シート数の突合を求められます。どちらも「いつ誰が更新した記録か」が残っていなければ証拠になりません。

判断ルールは、この3場面のどれにも登場しない項目は台帳に入れない、です。ISMS取得を目指す場合、資産目録は最初に整備を求められる文書のひとつで、全体の流れはISMS認証取得の進め方にまとめています。

台帳の項目テンプレートと資産タグの採番ルール

項目は「受領時に必ず埋める必須」「棚卸しのついでに埋める推奨」「気づいたら書く任意」の3区分にします。必須を7つに絞るのは、全数登録を最初の2週間で終わらせるためです。列ごとに更新するタイミングと担当も決めておきます。

項目記入例区分更新するタイミング(担当)
資産タグ(管理番号)PC-0001必須受領時に採番、以後変更しない(情シス)
カテゴリノートPC / デスクトップ / サーバー / ネットワーク機器 / モニター必須受領時(情シス)
メーカー・モデルメーカー名+型番必須受領時(情シス)
シリアル番号本体ラベルまたはOSから取得必須受領時、修理でボード交換されたら再取得
ステータス在庫 / 修理中 / 所在不明 / 廃棄済み必須貸出・返却・修理・廃棄のたび(情シス)
利用者・部署人事マスタと同じ表記必須貸出・返却時(情シス)、異動時(人事連絡で)
拠点・設置場所本社3F / 名古屋支店 / 在宅必須貸出・返却・異動時(情シス)
購入日・購入先・金額発注番号と紐づける推奨受領時(購買)
保証期限・保守契約番号保証終了日、契約番号推奨受領時、契約更新時
OS・暗号化の有無Windows 11 Pro、BitLocker有効推奨キッティング時、OS更新時
備考・履歴修理歴、付属品、返却時の傷任意都度

キーにする列は資産タグです。シリアル番号は修理でマザーボードが交換されると変わることがあり、ホスト名は再キッティングで付け直されます。資産タグだけは、OSを入れ直しても利用者が変わっても同じ個体を指し続けるよう、物理ラベルとして本体に貼り、二度と変更しません。採番は「PC-」「SV-」「NW-」の種別プレフィックス+4桁連番で十分で、部署名や利用者名を含めると異動のたびに矛盾が生まれます。さらに、ホスト名を資産タグと同じ文字列にしておくと、MDMやEDRのコンソールと台帳の突合が目視で済みます。例外は、ホスト名に拠点コードを入れる規則が全社で決まっている場合で、そのときは資産タグをコンピューターの説明欄に書き込みます。シリアル番号はWindowsなら(Get-CimInstance Win32_BIOS).SerialNumber、Linuxならsudo dmidecode -s system-serial-numberで取得できます。

Excel管理をやめる判断基準

破綻の前兆は決まっています。共有フォルダに「台帳_v3_最終.xlsx」と「台帳_最新.xlsx」が並ぶ、監査で「この端末はいつ誰から誰に渡ったか」を聞かれてセルの上書きしか残っていない、保証切れを担当者の記憶で管理している、閲覧だけしてほしい部門長にも編集権限を渡している。このうち2つ当てはまれば移行時期で、数字で言えば端末100台前後・担当者2人以上・拠点2つ以上のどれかです。100台の根拠は入れ替えのペースにあります。4〜5年で更新するなら年に2割前後が入れ替わり、毎月2件前後の登録と廃棄に加えてそれより多い貸出・返却が発生するので、「ファイルを開いて保存する」運用では漏れが出ます。逆に30台以下で担当1人なら、Excelに「履歴」シートを足す方がツールの運用コストより安く済みます。

ツールに移行しても、運用ルールがなければExcelと同じ結果になります。移行前に「受領時」「貸出時」「返却時」「廃棄時」の4つのタイミングで、誰がどの項目を更新するかを1枚の表に決めてください。ツール選定より先にこの表を作った方が、移行後の定着率が明らかに違います。

Snipe-ITとは

Snipe-ITは、AGPLライセンスで公開されているWebベースのIT資産管理ツールです。PHP(Laravel)製で、自社サーバーやクラウドのVMにセルフホストすれば全機能を無償で使えます。開発元が運営する有償ホスティング版もあり、料金は公式サイトで確認できます。機能は、資産の登録とユーザー・拠点・別資産への貸出(Checkout)・返却(Checkin)、ライセンス・アクセサリ・消耗品・コンポーネントの管理、QRコード付きラベル印刷と監査(Audit)による棚卸し記録、保証・ライセンス期限のメール通知、CSVインポート、REST API、LDAP/SAML連携で、日本語UIもあります。

向いていないのはSaaSの契約管理です。ライセンスとして登録はできますが、契約更新日・利用者の棚卸し・SSO連携状況まで追うには項目が足りません。「モノとインストール型ライセンスはSnipe-IT、SaaS契約はSaaS台帳」と分けるのが現実的です。

Docker ComposeでSnipe-ITを構築する

前提はDocker EngineとDocker Compose v2が動くLinuxサーバーです。Dockerの導入から始める場合はDocker Compose入門を先に済ませてください。Snipe-IT本体とMariaDBの2コンテナ構成で、アップロードファイルとDBは名前付きボリュームに置きます。

compose.yaml
services:
  app:
    image: snipe/snipe-it:latest   # 本番ではバージョンタグに固定する
    restart: unless-stopped
    ports:
      - "127.0.0.1:8000:80"        # リバースプロキシ経由で公開する前提
    env_file: .env
    volumes:
      - app_data:/var/lib/snipeit
    depends_on:
      db:
        condition: service_healthy

  db:
    image: mariadb:11
    restart: unless-stopped
    environment:
      MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
      MYSQL_DATABASE: ${DB_DATABASE}
      MYSQL_USER: ${DB_USERNAME}
      MYSQL_PASSWORD: ${DB_PASSWORD}
    volumes:
      - db_data:/var/lib/mysql
    healthcheck:
      test: ["CMD", "healthcheck.sh", "--connect", "--innodb_initialized"]
      interval: 10s
      timeout: 5s
      retries: 10
      start_period: 30s

volumes:
  app_data:
  db_data:
.env
APP_ENV=production
APP_DEBUG=false
APP_KEY=                      # 次の手順で生成した値を貼る
APP_URL=https://assets.example.co.jp
APP_TIMEZONE=Asia/Tokyo
APP_LOCALE=ja-JP

DB_CONNECTION=mysql
DB_HOST=db
DB_PORT=3306
DB_DATABASE=snipeit
DB_USERNAME=snipeit
DB_PASSWORD=長いランダム文字列
MYSQL_ROOT_PASSWORD=別の長いランダム文字列

MAIL_MAILER=smtp
MAIL_HOST=smtp.example.co.jp
MAIL_PORT=587
MAIL_ENCRYPTION=tls
[email protected]
MAIL_FROM_NAME=Snipe-IT
terminal
mkdir -p ~/snipeit && cd ~/snipeit   # 上の2ファイルをここに置く

docker compose run --rm app php artisan key:generate --show
# 表示された base64:... を .env の APP_KEY に貼る

docker compose up -d
docker compose logs -f app   # マイグレーション完了まで待つ

APP_KEYは保存データの暗号化に使う鍵で、後から変えるとライセンスキーなど暗号化済みのフィールドが復号できなくなります。生成した値はバックアップと一緒に保管してください。ブラウザでAPP_URL(リバースプロキシ未設定ならhttp://サーバーのIP:8000)を開くと、前提条件チェック(Pre-Flight)から管理者アカウント作成に進みます。最初の管理者は個人名にせず「初期管理者」として作り、担当者ごとの個人アカウントは後から権限を分けて追加します。

APP_URLは実際にアクセスするURLと完全に一致させてください。Laravelはこの値から絶対URLを組み立てるため、食い違うとCSSが読み込まれない、ログイン後のリダイレクトが失敗するといった症状が出ます。また上のcompose.yamlではポートを127.0.0.1に限定しています。社内公開はnginxやCaddyでHTTPS化してから行い、攻撃者にとって価値のある情報である台帳をインターネットへ直接公開しないでください。

初期設定は会社→拠点→カテゴリ→モデルの順に登録する

Snipe-ITではモデルがカテゴリとメーカーを、資産がモデルとステータスラベルを前提にします。逆順で登録すると資産登録の途中でモデル作成に戻る手戻りが起きるため、親から先に作ります。

  1. 会社(Companies):単一法人なら1件。グループ会社で分けるなら、設定で複数会社サポートを有効にすると会社ごとに表示を分離できます。
  2. 拠点(Locations):本社、支店、倉庫、在宅の単位で登録します。「本社3F」のようなフロア単位は、棚卸しでフロアごとに担当を分ける規模になってから増やします。
  3. カテゴリ(Categories):資産ならノートPC、デスクトップ、モニター、スマートフォン、ネットワーク機器、サーバーの6つから始めます。
  4. メーカーとモデル(Models):同じ型番は必ず同じモデルに紐づけます。モデルにカスタムフィールドセット(OS、暗号化など)を割り当てると、資産登録画面にその項目が現れます。
  5. ステータスラベル:下表の4タイプを理解したうえで、自社の運用語で作ります。
  6. 資産タグの自動採番:設定でプレフィックスと桁数を指定すると、登録時に連番が自動で入ります。
  7. ユーザー:人事マスタからCSVで取り込むか、LDAP/SAMLで同期します。手入力すると氏名表記が揺れ、貸出先の検索で見つからなくなります。
ステータスタイプ意味自社ラベルの例
Deployable貸出できる状態在庫
Pending処理待ちで貸出できない受領検品中、修理中
Undeployable貸出できない故障、所在不明、廃棄待ち
Archived通常の一覧から除外廃棄済み、売却済み

「利用中」というラベルは作りません。利用中かどうかは貸出の有無でSnipe-ITが判断するためで、ステータスに「利用中」を作ると貸出記録と食い違う日が必ず来ます。

資産を登録して貸出・返却を記録する

初回の全数登録はCSVインポートで行い、列は「資産タグ、シリアル番号、モデル名、ステータス、拠点」の5列から始めます。列を増やすほど表記揺れによるインポートエラーが増えるからで、購入情報や保証期限は登録後に一括編集で足す方が早く終わります。貸出先は3種類あり、個人に渡すPCやスマートフォンはユーザーへ、会議室のモニターやネットワーク機器などの共用機は拠点へ、ドッキングステーションのようにPCに付随するものは資産(親のPC)へ貸し出します。貸出機や検証機には返却予定日を入れ、期限超過の一覧で追跡します。

ユーザーへの貸出でEULA(利用規約)の承諾を必須にすると、本人がメール上で受領を確認した記録が残り、「そんな端末は受け取っていない」という後日の食い違いを防げます。返却(Checkin)ではステータスを「在庫」か「修理中」に変え、拠点を倉庫に戻し、欠品や傷を備考に残します。利用者欄を編集画面で直接書き換える運用は禁止し、必ずCheckout/Checkinを通します。履歴タブの記録がそのまま監査証跡になるからです。新規購入から配布までは「受領→登録→キッティング→Checkout」の順で、キッティング側の手順はPCキッティングの効率化にまとめています。

ライセンス・アクセサリ・消耗品・コンポーネントの使い分け

資産以外の4種類は「個体を追跡するか数量だけ追うか」「貸したら返ってくるか」で区別します。ここを間違えると、マウスを1台ずつ資産登録して台帳が膨らむ、逆にサーバー用SSDを消耗品にして行き先がわからなくなる、といったことが起きます。

種別管理単位典型例貸出の扱い
資産(Assets)1台ごと(シリアル)PC、サーバー、スマートフォン、モニターユーザー・拠点・資産へ貸出し、返却で戻る
ライセンス(Licenses)シート数OS、オフィススイート、開発ツールシート単位でユーザーまたは資産へ割当
アクセサリ(Accessories)数量(個体管理なし)マウス、キーボード、ドッキングステーションユーザーへ貸出し、返却で数量が戻る
消耗品(Consumables)数量トナー、LANケーブル、SDカード返却なし。消費として記録
コンポーネント(Components)数量メモリ、SSD、電源ユニット資産に組み込み、取り外しで戻る

ライセンスにはシート数、期限、購入証憑のファイル、ライセンスキーを登録できます。キーは閲覧権限を持つロールにしか表示されないので、ヘルプデスク担当には「ライセンスキーの表示」権限を外したロールを渡します。期限アラートは設定で通知先メールと何日前かを決めます。目安は保証・ライセンスとも60日前で、更新稟議と発注のリードタイムから逆算した値です。年度末に一括更新する契約が多いなら90日前に伸ばします。

QRコードラベルで棚卸しを回す

棚卸しは台帳と現物の一致を確かめる作業で、Snipe-ITでは監査(Audit)機能がその記録先です。ラベルのQRコードには資産ページのURLが埋め込まれるため、スマートフォンのカメラで読むとその資産の画面が開き、そこから監査を記録できます。

  1. 設定のラベル項目で用紙サイズ、2Dバーコードの種類(QR)、印字項目(資産タグ、モデル、シリアル)を決めます。ラベルプリンターがなくてもA4シール用紙で印刷できます。
  2. 資産一覧で対象を選んでラベルを生成し、本体の同じ位置(ノートPCなら底面の手前左など)に貼ります。位置を統一するのは棚卸しで裏返す時間を減らすためです。
  3. 設定で監査間隔(例:12か月)と警告日数を入れておくと、「監査期限切れ」「期限が近い」の一覧が自動で出ます。
  4. 当日はQRを読み取って監査ボタンを押し、現在の拠点と備考を記録します。社内ネットワーク外からはVPN経由でアクセスします。
  5. 見つからなかった資産は「所在不明」に変えて調査を始め、30日以内に結論を出します。紛失と判断したら情報セキュリティインシデントとして記録します。

頻度は年1回の全数と、四半期ごとの抜き取りの組み合わせです。複数拠点なら全拠点を同じ週にやらず、月ごとに拠点を割り当てて1年で一巡させる方が、業務への影響も担当者の負荷も平準化できます。拠点が1つで50台以下なら、逆に半日で全数を終わらせる方が早く、分割する意味はありません。

バックアップと監査対応

Snipe-ITにはDBダンプとアップロードファイルをまとめてzip化する組み込みコマンドがあり、管理画面のバックアップ項目からもダウンロードできます。生成物はコンテナ内の/var/lib/snipeit配下、つまりapp_dataボリュームに置かれるので、必ず別ホストへコピーします。

terminal
# 組み込みバックアップ(DB + アップロードファイルを zip 化)
docker compose exec app php artisan snipeit:backup

# DB だけを個別にダンプする場合(コンテナ内の環境変数を使う)
docker compose exec db sh -c 'mariadb-dump -u root -p"$MYSQL_ROOT_PASSWORD" snipeit' \
  > snipeit-$(date +%F).sql

cronで毎晩実行し、zipと.env(APP_KEYを含む)をNASやオブジェクトストレージへ転送します。復元テストは年1回、棚卸しと同じ時期に別のVMでdocker compose upから復元まで通し、所要時間を記録します。監査対応で用意するものは4つで、監査人や部門長向けの閲覧専用ロール、レポートメニューのアクティビティレポートを期間指定でCSV出力できる状態、廃棄資産にデータ消去証明書のPDFを添付してArchivedにする運用、そして「誰が台帳の管理責任者か」を情報セキュリティ規程側に書いておくことです。この4つが揃っていれば、ISMS審査で資産目録の追加資料を求められることはほとんどありません。

つまずきポイント:導入初期によくある失敗

  • 全項目を埋めようとして登録が止まる:20列の台帳を設計し、1台の登録に10分かかって1か月で頓挫するパターンです。必須7項目で全数登録を先に終え、推奨項目は棚卸しのついでに埋める2段階にします。
  • シリアル番号をキーにして修理で追跡が切れる:マザーボード交換でシリアルが変わり、EDRのコンソールと台帳が突合できなくなります。キーは資産タグに固定し、修理返却の手順書に「シリアル再取得」のステップを入れます。
  • 利用者欄を直接上書きして前任者が消える:異動のたびに編集画面で利用者を書き換えると、未返却の端末を誰が持っているか辿れません。Checkout/Checkin以外の変更を禁止し、編集権限を情シスの担当者に限定します。
  • バックアップがサーバーの中にしかない:ホストのディスク障害で台帳が丸ごと消え、Excel時代の古いファイルから作り直す羽目になります。別ホストへの転送と年1回の復元テストを、棚卸しの年間予定に最初から組み込みます。

よくある質問

IT資産管理ツールは無料で使えますか?

Snipe-ITのようなオープンソースのツールは、自社でサーバーを用意してセルフホストすればライセンス費用はかかりません。その代わり、更新・バックアップ・障害対応の工数は自社で負担します。運用の手を確保できないなら、開発元の有償ホスティングや商用ツールを検討し、価格は各公式サイトで確認してください。

何から登録すべき?

紛失したときの影響が大きい順です。まず現在使われている業務用PCとスマートフォンを全数、次にサーバーとネットワーク機器、その後にライセンス、最後にモニターや周辺機器です。在庫や廃棄待ちの機器は、PCの全数登録が終わってから手を付けた方が途中で息切れしません。

SaaSのアカウントも資産管理に含めますか?

情報資産としては含めるべきですが、Snipe-ITで扱うのは無理があります。SaaSは契約更新日、利用者の棚卸し、SSO/SCIM連携の有無、退職時のアカウント停止まで管理する必要があり、専用のSaaS台帳を別に持つ方が現実的です。台帳の項目と棚卸しサイクルはSaaS管理の始め方で扱っています。

まとめ

使う場面から項目を絞り、資産タグをキーにして物理ラベルで固定する。この2点が守れていれば、ExcelでもSnipe-ITでも台帳は回ります。Snipe-ITに移す価値が出るのは、貸出・返却の履歴と棚卸しの記録を人手で追えなくなったときで、目安は100台・担当2人・拠点2つのいずれかです。構築は2コンテナで半日あれば終わるので、時間をかけるべきなのはその前の運用ルールの表と、その後の全数登録です。

次に読む

$ subscribe --weekly
毎週月曜、企業ITとホームラボの要点を5分で。