レンタル EC の在庫は「ある・ない」では足りない：貸出中・検品中・予約済みの状態設計

レンタルの EC を作るとき、最初に「在庫数」の列を 1 本用意して、貸すと減り、返ってくると増える作りにしてしまうことがあります。販売型の EC なら、それで足ります。ところがレンタルでは、同じ 1 台が「今日は貸出中、明日は検品中、来週は予約済み」と、時間とともに別の状態になります。数を 1 本持つだけの設計では、二重予約も、返却された商品がいつまでも貸せない問題も、仕組みの上で防げません。

この記事では、レンタル EC の在庫を状態と遷移条件で設計するときに、発注前に決めておきたい論点を整理します。

在庫は数ではなく、状態と時間で持つ

レンタル管理システムを解説する一創のコラム（2026 年 7 月 23 日）は、在庫の状態管理を次のような数字で説明しています。

同じ10台の機材でも、3台は貸出中、2台は返却後の整備中、1台は来週から予約済、となれば、いま新規に貸せるのは4台だけ。

出典：レンタル管理システムの記事（株式会社一創）

この例が示すとおり、貸せる数は「全体の数」から「貸出中」「整備中」「予約済み」を引いて初めて決まります。さらに「予約済み」は、いつからいつまでかという時間の情報を持ちます。つまり、レンタルの在庫は「何台あるか」ではなく「いつ、どの 1 台が、どの状態か」を持つ必要があります。

同じコラムは、予約と貸出で在庫の扱いを分けることも挙げています。

予約段階で在庫を仮押さえし、貸出で本引き当てに変える二段階の在庫管理が要ります。

出典：レンタル管理システムの記事（株式会社一創）

ここまでは、今回参照した解説でも触れられている部分です。以下では、解説では「何を決めるか」までで終わりがちな、状態ごとの遷移条件と、例外の扱いを具体的にします。ここから先は、私たちの設計の考え方です（一般論であり、出典のある事実ではありません）。

状態は「商品」ではなく「個体」に持たせる

まず、状態を持たせる単位を決めます。同じ型番の商品が 10 個あるとき、その 10 個を「型番の在庫数 10」としてまとめて持つと、どの個体が検品中なのかを追えません。傷の履歴や点検の期限は個体ごとに違うからです。

物流の面でも、同じ考え方が取られています。LOGISTICS TODAY が報じた富士ロジテックホールディングスのレンタル品向け物流サービスの記事（2025 年 6 月 17 日）は、個体管理について次のように書いています。

全商品にシリアルナンバーを付けることで、貸出から返却までのプロセスを可視化する（…）

出典：富士ロジテックHDがレンタル品総合物流サービス（LOGISTICS TODAY）

システム側も同様に、型番（商品マスタ）と個体（1 台ごとの記録）を分けて持つのが基本になります。予約は「型番と期間」で受け、貸出の確定時にどの個体を割り当てるか決める形にすると、検品中の個体を避けて割り当てやすくなります。

状態ごとの遷移条件を決める

次に、状態を「誰が、何を契機に」変えるかを表にします。例として、貸出中・検品中・貸出可・予約確保済みの 4 つで考えてみます。

• 貸出可から予約確保済みへ：顧客が予約を確定したとき（システムが自動で変える）。
• 予約確保済みから貸出中へ：出荷または店頭での引き渡しを倉庫・店舗のスタッフが記録したとき。
• 貸出中から検品中へ：返却された荷物を受け取り、スタッフが受領を記録したとき。返却予定日が来ただけでは変えない。
• 検品中から貸出可へ：検品の結果が合格で、清掃や整備が終わったとき。ここだけは人の確認を必須にする。

ここで大事なのは、システムが勝手に変えてよい遷移と、人が確認してはじめて変わる遷移を分けることです。とくに「検品中から貸出可」を自動にすると、未点検の個体が次の予約に回ります。Aurant Technologies の解説は、点検が済んでいない機材について「点検未済機材の予約ブロック（誤貸出防止）」を必須機能の例として挙げています（出典、2026 年 9 月 20 日更新）。

同じ解説は、返却後の流れを「返却受付、検品、清掃・整備、再貸出可能化。」とまとめ、整備にかかる時間も予約枠として登録する考え方を示しています。検品や整備の所要時間を、貸出可になるまでの空白として予約の計算に入れておくと、返却が遅れても次の予約を守りやすくなります。

期間が重なる予約と、仮押さえの期限切れ

状態の表ができたら、例外を決めます。論点は 3 つです。

1. 期間が重なる予約の優先順位：同じ型番の最後の 1 台に、期間が一部重なる予約が 2 件入ったときにどうするか。先着順にするのか、期間の長い予約を優先するのか。決め方によって、空き期間が細切れになる度合いが変わります。
2. 仮押さえの期限：カートに入れた段階や見積もり段階で在庫を取り置くなら、何分、または何日で解放するのか。決済が終わらないまま取り置きが残ると、貸せるはずの個体が他の顧客に見えなくなります。期限切れで解放するときに、顧客へ通知するかも決めます。
3. 返却遅れの扱い：貸出中の個体が予定日に戻らないとき、次の予約をどうするか。代替の個体を割り当てるのか、顧客に連絡して日程を調整するのか。遅れが出た時点で「次の予約が危ない」と気づける表示も必要です。

いずれも正解は事業ごとに違いますが、決めないまま作ると、運用の現場で個別判断が積み重なり、後から仕様に戻すのが難しくなります。

延長・延滞・破損を精算にどうつなぐか

貸出後に状態が変わる場面は、料金にも影響します。一創のコラムは、延長や途中解約で請求金額が変わることや、延滞時の督促、返却時の検品記録、破損・紛失時の弁済請求まで扱えるかを確認するよう述べています（出典）。状態設計の立場から言えば、これらは「状態の記録」と「料金の計算」を結ぶ設計の問題です。

• 延長は、貸出中の個体の予約期間を伸ばす操作です。伸ばした先に別の予約が入っていないかを、確定前に確認する必要があります。
• 延滞は、返却予定日を過ぎても貸出中のままの状態です。延滞日数を料金に反映する規則（日割りか、定額か、上限はあるか）を、契約と合わせて決めます。
• 破損は、検品の記録から請求につながります。検品時の写真やチェック項目を記録しておくと、顧客への説明と請求の根拠になります（これは設計上の提案です）。

料金の規則は契約条件に依存するため、ここでは中身に踏み込みません。ただ、「検品の記録が、請求の入力になる」という流れを最初に決めておくと、後から精算を手作業で補う運用を避けやすくなります。

発注前のチェックリスト

レンタル EC の開発を外部に頼む前に、次を書き出してみてください。

1. 在庫を持つ単位は個体か、型番か。個体ごとに持つ情報（点検期限、傷の履歴）は何か。
2. 状態の一覧と、各状態へ遷移する契機（誰が何をしたとき）。人の確認が必須の遷移はどれか。
3. 予約はいつ仮押さえし、いつ個体を確定するか。仮押さえの期限は。
4. 期間が重なる予約の優先順位。
5. 返却が遅れたとき、次の予約をどうするか。
6. 延長・延滞・破損の記録は、どの料金計算につながるか。

すべてに答えが出ていなくても構いません。答えが出ていない項目が見えることが、要件定義の出発点になります。

まとめ

レンタルの在庫は、数ではなく「どの個体が、いつ、どの状態か」を持つものです。状態の種類、遷移の契機、仮押さえの期限、重なる予約の優先順位、延長・延滞・破損の扱いを先に決めておくと、二重予約と返却後の滞留を、運用の頑張りではなく仕組みで減らせます。

私たちは、レンタル・サブスク、基幹システム連携、予約・受注生産など、既存の EC サービスでは実現しにくい仕組みを持つ EC を、要件定義から設計・開発する「ECサイト構築」を提供しています。レンタル EC の在庫設計でお悩みの場合は、お気軽にご相談ください。