全て説明用の架空記録です。社名・部署・担当・備品・日時・確認結果は実在の貸出、点検、承認、安全確認ではありません。AI製品やMicrosoft Listsの出力でもありません。
例の基準日時は2026-11-12T15:00:00+09:00（日本時間）。原記録の収録範囲は同日16:10までとし、15時の表を後から再現するための教材です。基準より後の記録を混ぜないでください。
4つの原記録CSV：asset-master（個体3台）、loan-items（貸出LN01の明細3件）、return-receipts（受取2件）、condition-checks（状態確認2件）。それぞれ同じ列の空欄CSVが付いています。availability-asof-example.csvは原記録ではなく、15時の照合結果の見本です。古い照合結果を原記録へ足さず、原記録から作り直します。
例の決めごと：管理対象の個体について、基準までの貸出を明細で特定し、同じ明細・個体の受取と、同じ受取・個体の状態確認を照合します。受取未記録は貸出中、受取あり・状態確認なしは点検待ち、受取あり・状態確認の結果が『例の条件に適合』なら貸出可候補とします。いずれも発生日時と記録日時が基準以前であることが必要です。このセットの範囲だけの手作業提案で、一般システムの自動判定仕様ではありません。
状態確認の具体的な項目・責任者・保留解除・再貸出のルールは会社で定める必要があります。『貸出可候補』はこの例の通常確認を満たすという区分で、安全、予約枠、将来の利用、実貸出の許可を保証しません。この例に次の予約や修理・廃棄は登場しません。
貸出全体LN01の返却処理終了は、全3明細の受取と状態確認がそろったとき、という例のルールです。15時では受取2/3、状態確認1/3なので終了しません。
Pythonなしの確認手順：
1. masterでEQ01/EQ02/EQ03が同名でも別の個体であることを読む。
2. LN01にLI01/LI02/LI03があり、それぞれ一つの個体へ対応することを読む。LN01一行だけで3台を返却済みにしない。
3. 受取表のRR01→LI01/EQ01、RR02→LI02/EQ02を指でたどる。LI03/EQ03の受取はない。
4. CK01→RR01/EQ01は13:20に確認、13:25に記録。両方15時以前なので使う。CK02→RR02/EQ02は16:00に確認、16:05に記録で、15時の判断から外す。
5. 15時の見本がEQ01=貸出可候補、EQ02=点検待ち、EQ03=貸出中の各1台、合計3台かを照合する。受取2台を貸出可2台にしない。
6. 借りる部署のLN01について、未受取がLI03、状態確認待ちがLI02と分かるか見る。貸出全体は返却処理未完了。
7. 各CSVのID重複・参照先違い・同じ個体の重複した未返却貸出・受取に対応しない状態確認があれば、勝手に件数へ足さず確認する。この例にはそうした不整合は入れていません。一般的な検出ツールの成功を示す資料ではありません。
CSVはUTF-8、カンマ区切り、全列文字列で読み込んで、列が分かれることを確かめます。BOM付き・数式なしです。Office/Sheetsの実際の読込・表示、QR/バーコード読取、通知や予約画面は未検証です。
実データへ使う際は保管先と閲覧範囲を会社で決め、利用者一覧や備考をそのまま外部AIへ送らないでください。今回は実人名・顧客資料・外部送信を使っていません。