CASE STUDY ・ 介護業界 ・ CareSupply|福祉用具EC・事業所管理の開発事例(仮称)
- Next.js
- React
- Laravel
- PHP
- MySQL
- AWS S3
- Firebase
- 福祉用具EC
- 注文管理
- 権限管理
※ 機密保持のため、企業名・プロジェクト名・システム画面は仮名およびモックに置き換えています。
この事例の根拠と読み方
根拠:移行時に保管されたケース資料、実装範囲を確認できる操作デモ、本ページで使用する匿名化済みの画面素材です。これらから、AMELAがストアフロント、注文管理、商品マスタ、法人・事業所管理を実装したことを確認できます。
対象期間:公開資料には実運用の測定期間や比較期間が含まれていません。そのため、導入前後の業務成果は扱いません。
確認できること:カテゴリ検索、購入・レンタル区分、カート注文、事業所別の注文確認、注文状態の更新、商品マスタ、法人・事業所の階層と権限の画面構成です。
確認できないこと:取扱品目数、注文件数、作業時間、転記ミス、在庫精度、利用率、売上などの実績値、および法令・監査要件への適合です。
公開上の扱い:機密保持のため、企業名、サービス名、商品名、商品画像、価格、在庫、注文内容、画面内の数値は仮名またはモックに置き換えられています。
発注画面だけでは、B2Bの注文業務はつながらない
福祉用具を法人・介護事業所向けに扱う企業様では、紙カタログ、FAX、電話を使う発注からオンライン注文へ移す構想がありました。利用者が商品を探して注文できても、運営側の注文確認や商品更新、法人配下の事業所管理が別のままでは、一連の業務になりません。
AMELAの担当範囲は、Next.js/Reactのストアフロント、LaravelのAPI、注文管理、商品マスタ、法人・事業所管理、役割に応じた画面と操作権限の実装です。
導入前に決めるべき四つの境界
- 購入品とレンタル品で、価格表示、注文単位、期間、変更・取消の扱いをどこまで分けるか。
- 法人、事業所、発注担当者の関係をどう持ち、誰がどの注文を閲覧・作成・更新できるか。
- 受付、出荷準備、出荷済などの注文状態を誰が変更し、例外時にどの状態へ戻すか。
- 商品名、価格、在庫、購入・レンタル区分の基準データを誰が更新し、公開画面へ反映するか。
カタログ・注文・商品・権限を一つの運用単位へ
AMELAは、ケース資料で確認できる要件を、利用者側の注文導線と運営側の管理業務へ分けて実装しました。
- カタログとカート:カテゴリから商品を探し、購入・レンタル区分を確認してカートへ追加する画面を設けました。
- 事業所別の注文管理:注文一覧、条件による絞り込み、状態更新を管理画面で扱う構成にしました。
- 商品マスタ:商品名、価格、在庫、購入・レンタル区分を登録・編集する管理機能を実装しました。
- 法人・事業所管理:法人配下に事業所を置き、役割に応じて閲覧・発注・管理の操作を分けるための画面を実装しました。

ケース資料とデモで確認できる実装結果
- 注文導線:カテゴリ検索から商品選択、カート、注文へ進む画面遷移を一つのストアフロントへまとめました。
- 注文状態の共有:事業所ごとの注文と状態を、運営側が一覧で確認する構成にしました。
- 商品情報の管理:価格、在庫、購入・レンタル区分を商品マスタで扱えるようにしました。
- 組織と権限の分離:法人、事業所、利用者の関係を管理し、役割に応じて操作を分ける構成にしました。
上記は実装された機能を示すもので、発注時間の短縮、ミスの削減、在庫精度、情報の即時反映、権限制御の完全性、売上への効果を証明するものではありません。発注チャネルを移行する判断では、機能の有無に加え、例外注文と責任分界を受け入れ条件へ落とし込む必要があります。
読者が使える実践ツール
- 発注経路を「通常注文、緊急注文、変更、取消、返品」に分け、オンライン化する範囲と残す経路を決める。
- 法人、事業所、発注担当、承認者、運営担当について、閲覧・作成・承認・状態更新の権限表を作る。
- 注文状態ごとに、変更できる担当者、次の状態、差し戻し先、通知先を定義する。
- 商品名、価格、在庫、区分の基準データについて、更新責任者と反映タイミングを決める。
- 購入とレンタルで異なる契約条件、請求、期間、返却の扱いを、画面と運用手順の両方で確認する。
- 本番公開後に測る指標と期間を決め、デモの商品数・価格・注文数を本番実績として扱わない。
記入例:通常注文は事業所の発注担当が作成し、法人の承認者が承認する。受付後の数量変更は運営担当へ連絡し、管理画面では「差し戻し」へ戻す。価格は商品管理担当が更新し、公開前に別の担当者が確認する。




