備品貸出台帳の作り方
｜個体IDと
返却記録から
貸出可否を照合する

同じ名前の備品をまとめて貸し出すときは、貸出1件に「返却済み」と書くだけでは、どの個体が戻ったか分かりません。個体IDごとの貸出明細に、受取記録と状態確認を対応させ、基準時点の扱いを読み直します。 受け取った台数と、次の貸出候補にできる台数は分けて数えます。

総務で備品の貸出・返却を記録する担当者向けに、同名のプロジェクター3台を一度に貸した架空例を示します。会社・部署・担当・備品・日時・確認結果は全て説明用です。実際の貸出や点検、AIや業務システムの実行結果ではありません。

この記事で分かること

• 同名の備品を個体IDで分け、貸出明細から受取・状態確認の原記録をたどれます
• 受け取った台数と次の貸出候補にできる台数を、基準時点をそろえて数えます
• 空欄CSVと架空の記入例を使い、一部返却と確認待ちを分けて記録します

貸出1件と、そこに
含まれる個体を分ける

貸出IDは、誰にどのまとまりで貸したかを指す番号です。個体IDは、同じ名前の備品のうち、どの一台かを指します。その間に明細IDを置くと、一つの貸出に含まれる個体を一台ずつ追えます。

今回の個体台帳にはEQ01・EQ02・EQ03が登録され、備品名は全て「プロジェクター」です。本体のラベルもそれぞれのIDに合わせた設定です。貸出LN01は営業チームへの一件で、明細は次の3行です。

3台とも、架空の2026年11月12日9時に貸し出し、返却予定を同日17時としています。本文の時刻は全て日本時間です。CSVには+09:00を含む日時を保存しています。

EQ01が戻ったときに更新する対象はLI01です。備品名が同じという理由でLI02やLI03まで受取済みにしません。反対に、同じ個体が次の貸出に出る場合は、新しい貸出明細へ対応させ、前の受取記録をそのまま流用しない扱いにします。今回は次の貸出は設定していません。

Microsoft公式のAsset managerテンプレートの説明にも、資産の識別番号、状態、利用者、返却予定日、状態メモなどの管理項目があります。以下の4つの原記録と照合方法は、編集部の手作業提案です。Microsoftの必須形式や、一部返却を自動処理した製品の結果ではありません。

原記録4種と、基準時点の
一覧を使い分ける

個体台帳は管理する一台を定義し、貸出明細はその個体をどの貸出に含めたかを記録します。受取と状態確認は、後から起きたこととして別に残します。最後に作る「15時の一覧」は、この4種から照合した結果です。

記入例と空欄CSVは、原記録ごとに同じ列です。

• 個体台帳：空欄／架空3台の記入例
• 貸出明細：空欄／LN01の3明細
• 受取記録：空欄／受取2件
• 状態確認：空欄／時刻の異なる確認2件
• 照合結果：15時の一覧見本／手で読む確認メモ

CSVはUTF-8、カンマ区切り、全列を文字列として読み込み、列が分かれたかを確認してください。数式や通知は入れていません。OfficeやGoogleスプレッドシートで実際に読み込んだ表示は未確認です。

照合結果の一覧を作り直す際は、原記録へ戻ります。前回の一覧に今回の一覧を継ぎ足すと、同じEQ01が二台あるように数えられます。貸出の状況と受取の経過も、原記録のIDから確認できる形にします。

受け取った2台を、どの
明細へ戻すか確認する

今回の受取記録は2件です。時刻だけでなく、明細IDと個体IDを一緒に見ます。

RR01からLI01をたどると、貸出LN01のEQ01と分かります。RR02もLI02・EQ02に対応します。LI03・EQ03に対応する受取記録はありません。この原記録の範囲では、受取2台、未受取1台です。

「LN01の備品が返ってきた」という連絡だけでは、3明細のどれを更新するか決まりません。個体ラベルを確認し、該当する明細に受取を記録します。ラベルと明細の個体IDが合わない場合は、名前が同じだからと別の一台へ付け替えず、対象を確認します。

ここで分かるのは、どの個体の受取を記録したかです。次の貸出候補にできるかは、状態確認を合わせて読みます。受取時に故障等の問題があった場合の対応や、責任者が保留を解除する手順は、会社の既存ルールへ従ってください。

15時の一覧には、
16時の確認結果を入れない

この教材の原記録には、同日16時10分までの架空の出来事を収録しています。そのうち、11月12日15時時点の状況を再現する例です。後から得た確認結果を、前の時点で分かっていたようには扱いません。

状態確認は、次の2行です。「例の条件に適合」は架空の通常確認結果であり、実物の安全性や、あらゆる用途で使用できるという判定ではありません。

EQ02も原記録の最後まで読めば確認結果があります。しかし、15時の一覧を作るときはCK02を除きます。受取のRR02は15時以前、対応する確認は15時より後なので、15時のEQ02は点検待ちです。

この例では、出来事の日時と、台帳へ記録した日時の両方が基準以前の行だけを使います。受取が終わっていても、記録がまだ届いていない場合を、当時分かっていた記録から勝手に埋めないためです。実際の貸出管理でも、どの時点で分かっていた状況を見たいかを先に決めます。

日時の表示を省くと、同じ「確認済み」の文字だけで前後を取り違えます。CSVの確認日時と記録日時は別列のまま保持し、コピーや並べ替えで片方を落とさないようにします。

個体ごとの現在の扱いから、
貸出全体の残件を読む

今回の会社には、次の架空の決めごとがある設定です。管理対象の個体について、対応する受取が未記録なら貸出中、受取はあるが基準までの状態確認がなければ点検待ち、受取と「例の条件に適合」という状態確認がそろえば貸出可候補へ分けます。

この区分で、原記録から15時の一覧を作ると次のようになります。

貸出可候補1台、点検待ち1台、貸出中1台で、個体台帳の3台へ対応します。受け取った2台を、そのまま貸出可候補2台へ足さないことがポイントです。

この一覧は、対象となる貸出と確認記録をそろえた架空例の、記録上の扱いです。実運用で受取記録が見つからない場合は、入力漏れや別明細への登録がないかも確認します。記録がないだけで実物の場所が確定したとはせず、未確認を貸出可へ置き換えないでください。

LN01は、3明細のうちどこが
残っているかを見る

LN01の受取は2／3明細、状態確認は1／3明細です。この例では、全明細の受取と状態確認がそろってから貸出全体の返却処理を終了するルールなので、LN01は未完了です。

残る対象は「プロジェクター」一式ではなく、受取状況を追うLI03・EQ03と、状態確認を追うLI02・EQ02です。受取担当と確認担当が違う場合も、個体IDと明細IDがあれば、どの一台について何を確かめるかを渡せます。

15時の時点では返却予定17時がまだ来ていないため、EQ03を返却遅れとはしていません。予定を過ぎた場合の連絡や、問題のある個体を再貸出へ戻す判断は会社の手順で決めます。この一覧から期限や権限を新しく作ることはしません。

「貸出可候補」も、次の予約を確定したという意味ではありません。この例には次回予約、修理、廃棄を含めていません。実際の用途、状態確認の項目、責任者、保留解除、貸出の許可は、自社で定めた条件を確認します。

まず一件の貸出を、
原記録まで手でたどる

新しいシステムへ移す前に、一件の貸出について次の順で読み比べます。Pythonを実行する必要はありません。

1. 個体台帳のEQ01〜EQ03と、LN01のLI01〜LI03が一対一で対応するかを見る。
2. RR01とRR02が、正しい明細と個体に付いているかを見る。LN01だけをキーにして全明細を更新しない。
3. 受取ごとの状態確認をたどり、確認日時と記録日時を基準15時と比較する。CK02は対象外にする。
4. 15時の一覧が3個体を一回ずつ示し、根拠のない受取や確認を補っていないかを見る。
5. LN01の受取2／3、状態確認1／3、返却処理未完了が、個体別の一覧と矛盾しないかを見る。

行の重複やIDの取り違え、同じ個体の重複した未返却貸出、受取に対応しない確認があれば、そのまま件数へ足さず元記録を調べます。貸出可否を会社名や備品名の文字列一致だけで決める処理にはしません。

貸出の手順そのものを整えたい場合は、AIでマニュアルを作る方法へ進めます。発注する消耗品の在庫や補充は、在庫管理のAI活用で扱う別の仕事です。

台帳をつないで確認する負担が繰り返し生じる場合は、まず社内の項目、更新担当、閲覧範囲を決めます。AIを使う場合も利用者情報をそのまま外部へ渡さず、会社で認めた扱いを確認してください。本稿ではLLMへの送信、AI製品の操作、効果測定を行っていません。

まるっとAIへ相談する際も、実際の利用者一覧は不要です。機密を含まない架空の記録と、基準時点に出したい一覧、どのIDの照合に手間があるかを用意すれば、既存の表で続ける範囲と、記録の連携を整える範囲を相談できます。

備品貸出台帳のよくある質問