2014年の概念モデルから、26ユースケース・36エンティティへ。
出発点は、テクノロジックアートの「UMLによる分析設計手順書」（2014年）に収められた在庫管理の例題です。手順書の概念モデル・ユースケース図・論理アーキテクチャを業務要件に展開し、手順書に記載のない事項は物流実務の一般的な要件で補いました。そこから単一の真実源（SSoT）を作り、アクティビティ図18・ユースケース26・クラス図（7パッケージ）・状態遷移図7・シーケンス図26を生成しています。モデル検証は エラー0・警告0（品質スコア98.4）です。
各パッケージの詳細なクラス図です。クリックすると原寸で開きます（数字はエンティティ数）。
本ページは、手順書からのモデル駆動開発の概要と、生成したアプリケーションの操作マニュアルをまとめたものです。画面・ボタンの名前は実装のとおりで、画面の例はデモデータ（約60日分）を使って操作したときのものです。
- 対象システム: 在庫管理システム（B2Bサイト向け WMS）
- 構成: フロントエンド（React + TypeScript）＋ バックエンド（Express REST API）
- 設計トレース: 業務要件 → 業務シナリオ → アクティビティ図 / ユースケース図 / クラス図 / 状態遷移図 → 実装（UC-001〜UC-026、BR-001〜BR-018 は設計書と共通）
01手順書からの生成
入力は「UMLによる分析設計手順書」（2014年4月18日、テクノロジックアート）の本文と図です。登場人物・ロール図、業務パッケージ図、発注処理のアクティビティ図、ユースケース図とユースケース記述例、在庫管理概念モデル、勘定パターン、論理アーキテクチャ図、論理WMSコンポーネント図を読み取り、実務レベルの業務要件に整理しました。
システム化の対象は、論理WMSコンポーネント図の在庫業務コンポーネント（ロケーション管理・在庫管理・荷受管理・引当）と、論理アーキテクチャ図の中心にある予実績管理です。受注・出荷・発注は隣接コンポーネントとして扱い、API（サービスアカウント）でつなぎます。
| 成果物 | 数量 |
|---|---|
| ユースケース（API と業務画面を実装） | 26 |
| エンティティ（汎用の一覧・詳細画面と CRUD API） | 36 |
| 状態遷移図 | 7 |
| ビジネスルール | 18 |
| アクティビティ図 / シーケンス図 | 18 / 26 |
| テスト（単体42・API 51・E2E 2） | 95（全件合格） |
1.1 設計の中心：勘定パターン
手順書の概念モデルのとおり、Fowler の勘定パターンで在庫を記録します。
| 勘定パターン | 本システム | 役割 |
|---|---|---|
| Account | 保有 | 品目×保有者×ロケーション（×ロット）の口座。期首在庫・安全在庫量を持つ |
| Entry | 移動 | 予定／実績 × 受入／払出。数量は正、符号は受払区分 |
| Transaction | 物流取引 | 2件以上の移動を束ね、予実区分×品目ごとに数量合計ゼロを保証 |
時点 t の在庫量 = 期首在庫 + 受入実績 − 払出実績 + 受入予定の残数 − 払出予定の残数- 在庫量は保存しません。在庫量を書き換える API はなく、数量はすべて物流取引で変わります（BR-001・BR-002）。
- 予定は実績で上書きせず、予実の対応付けで残数を求めます（BR-003）。訂正は逆仕訳です（BR-011）。
- 棚入れ・商品移動・一括移動・関連付け・CSV取込は、すべて同じ格納チェックを通ります（BR-004）。
1.2 設計からの読み替え（実装上の判断）
| 箇所 | 実装 | 理由 |
|---|---|---|
| 受入実績の記録 | 入荷検品で入荷検品場へ受入実績、棚入れは格納先へのロケーション移動 | 検品済の商品だけが在庫になり（BR-006）、流通加工とクロスドックも在庫勘定の上で表せる |
| 期首在庫 | 期首日付の在庫調整取引（相手方：調整勘定）として記録 | 在庫量を書き換えない（BR-001）。訂正は逆仕訳 |
| 商品状態 | 品目（SKU）には持たず、シリアル管理品は個体、それ以外は保有の在庫状態区分で持つ。状態の変化は区分間の移動 | 品目単位では SKU 全体が一斉に状態を変えてしまうため |
| 引当の実行主体（手順書で未決） | 本システムに引当 API を置き、受注・出荷管理から呼ぶ | 在庫の数量を変えられるのを在庫管理に限るため |
02はじめに
| 区分 | 機能 |
|---|---|
| 入荷 | 発注先による入荷予定の登録・分納、入荷連絡の記録、荷受け（パレット・ボックス・ラベル印刷）、入荷検品、流通加工、棚入れ、クロスドック、入荷進捗 |
| 保管 | ロケーションと商品の関連付け（最大格納数）、商品移動、ロケーション一括移動、CSV 取込、ロット・消費期限の管理と警告リスト |
| 棚卸 | 棚卸指示、実数の登録、差分リスト・再カウント、確定（差異を在庫調整として記録） |
| 在庫 | 在庫照会（見込在庫・過去時点の在庫）、要約在庫、CSV 出力、期首在庫・安全在庫の登録、CSV 一括取込、販売可能数の配分、引当ルール |
| 管理 | 予実（受注・出荷・発注・荷受・ロケーション移動・在庫の予定と実績、在庫推移）、発注依頼、マスタ管理、監査ログ（改ざん検知） |
| ロール（利用権限区分） | 主な仕事 |
|---|---|
| 倉庫担当者（WMS） | 入荷連絡の記録、荷受け・検品・流通加工・棚入れ、ロケーション管理、ロット・消費期限、棚卸の実数登録。担当倉庫の分だけを扱う |
| OMS利用者（OMS） | 期首在庫・安全在庫の登録、在庫 CSV 取込、販売可能数の配分、引当ルール |
| 発注先（発注先） | 自社の注文書（PO）に対する入荷予定の登録・分納。自社分だけを参照 |
| マネージャ・棚卸責任者（WMS） | 予実の確認、棚卸指示と確定、発注依頼、全倉庫の照会 |
| クライアント（OMS） | 在庫の確認と発注依頼 |
| システム管理者（WMS） | マスタ・利用者の管理、監査ログ |
03起動とログイン
# ① バックエンド（REST API / ポート 4000）
cd app/backend
npm install # 初回のみ
cp .env.example .env # 初回のみ（そのままでも動きます）
npm run dev # 起動時に約60日分のデモデータを作成
# ② フロントエンド（画面 / ポート 5173）
cd app/frontend
npm install && npm run devブラウザで http://localhost:5173/ を開きます。Docker の場合は docker compose up --build で http://localhost:8089/ に起動します。デモ用アカウントのパスワードはすべて Wms-Demo-2026! です。
- パスワードを5回続けて間違えると、30分間ロックされます。多要素認証を有効にした環境では、認証アプリの確認コード（TOTP）も求められます。
- 左のサイドバーはロールに応じて表示されるメニューが変わります（使えない機能は出ません）。画面タイトルの下にはその画面で守られている業務ルール、枠の見出しには設計書のユースケース番号が表示されます。
04業務の流れ
| 順 | 担当 | 操作 |
|---|---|---|
| 1 | クライアント・マネージャ | 在庫を確認し、必要なら発注を依頼する（発注管理が注文書を発行） |
| 2 | 発注先 | 注文書（PO）に対して入荷予定を登録する。分けて納める場合は分納する |
| 3 | 倉庫担当者 | 発注先からの入荷連絡（EDI・メール・電話）を記録する |
| 4 | 倉庫担当者 | 荷受けを登録し、荷受票・検品ラベルを印刷する |
| 5 | 倉庫担当者 | ボックスごとに検品する（数量・ロット・期限、シリアル管理品はシリアル番号） |
| 6 | 倉庫担当者 | 必要なら流通加工（タグ付け・セット組みなど）を記録する |
| 7 | 倉庫担当者 | 格納先を読み取り、格納チェックを通して棚入れする。入荷待ちの注文があればクロスドックする |
| 8 | 倉庫担当者 | 補充・再配置のため商品を移動する。ロットの期限を管理する |
| 9 | マネージャ → 倉庫担当者 → マネージャ | 棚卸を指示・開始し、実数を登録して、差異を確定する |
| 10 | マネージャ | 予実と在庫推移を確認し、安全在庫を割る見込みがあれば発注などを検討する |
引当と出荷確定は、受注・出荷管理システムから API で行います（本システムの画面にはありません）。
05ダッシュボード
ロールに応じて、見える範囲の情報だけを表示します。安全在庫割れの品目、30日以内に安全在庫を割る見込の品目、未完了・遅延の入荷予定、期限切れ・期限間近のロット、棚卸の開始や入荷差異などの通知が並びます。
06在庫照会（UC-001〜003）
在庫量は保存している値ではなく、期首在庫と移動（受入・払出）から計算した値です（BR-001）。保有（品目×ロケーション×ロット×在庫状態）ごとに、在庫量・引当済・引当可能数・安全在庫量・最終移動を表示します。倉庫担当者には担当倉庫の在庫だけが表示されます。
「見込在庫の時点」に日付を入れると、その時点の在庫量の列が加わります。未来の日付では受入予定・払出予定を加えた見込み、過去の日付では移動の記録から再現した在庫です（UC-002）。
07入荷予定（UC-008〜010, 015）
入荷予定・荷受け・検品・棚入れは、すべて注文書（PO）をキーにつながっています（BR-007）。
- 入荷予定の登録（発注先） — 自社宛ての注文書を選び、入荷予定日・予定数量・ロット番号・期限を入力します。同じ注文書の予定の合計が発注数を超える場合は登録できません。発注先には自社の注文書・入荷予定だけが表示されます（BR-010）。
- 入荷進捗 — 予定数・検品数・棚入れ数・状態と、遅延・差異・予定外の印を表示します。
- 入荷連絡の記録（倉庫担当者） — EDI連絡・電子メール連絡・電話連絡を記録し、状態が「連絡受領」になります。
- 分納・予定外入荷・取消 — 分割後の数量の合計は予定数と一致させます（BR-003）。取消は削除せず「取消」として残ります（BR-011）。
08荷受け・検品・流通加工・棚入れ（UC-011〜014）
ハンディターミナルでの利用を想定した画面で、読取 → 確認 → 確定の順に進めます。ボックスの状態は「入荷済 → チェック済 → 入庫済」と進みます。
8.1 荷受け
注文書のバーコードを読み取り、パレットID・箱ごとの入数・ロット番号・外観ダメージを入力して「荷受け登録」を押すと、荷受票とボックスごとの検品ラベルが表示され、印刷できます。
8.2 入荷検品
ボックスIDを読み取り、検品数量・ロット・期限・破損の有無、シリアル管理品はシリアル番号（検品数量と同じ数）を入力して「検品確定」を押します。
- 検品数量が入荷検品場の在庫に「検品済」として入ります。検品前の商品は在庫に入らず、引当もされません（BR-006）。
- ロットが未登録なら登録され、ラベルの期限がロットの消費期限の初期値になります（BR-018）。シリアル管理品は個体として登録されます（BR-017）。
- 数量不足・過剰などの差異はボックスと入荷予定に印がつき、通知されます。
8.3 流通加工と棚入れ
棚入れの前に、チラシ挿入・包装・タグ付け・セット組み・セット解体などの流通加工を記録できます。完了すると在庫状態区分が「検品済」から「流通加工処理済」へ移ります。棚入れでは格納先を選んだ時点で格納チェックが行われ（BR-004）、最大格納数の超過・混載不可・保管方法の不一致などがあれば理由が表示されます。
09ロケーション（UC-016〜019）
棚・パレット・ピッキングカートにアドレスを振り、どの商品がどこにあるかを管理します。関連付け・商品移動・一括移動・CSV取込は、すべて同じ格納チェックを通ります（BR-004）。
| タブ | 内容 |
|---|---|
| 関連付け（UC-016） | 商品とロケーション、最大格納数を関連付ける。在庫量が最大格納数を超える場合や混載できない場合はエラー（BR-005） |
| 商品移動（UC-017） | 移動元と移動先を選び、数量と理由で移動。払出と受入が1つの物流取引として記録される。引当可能数を超える数量は移動できない（BR-012） |
| 一括移動（UC-018） | 棚単位・パレット単位で全品目をまとめて移動。1品目でも格納できなければ全体を中止 |
| CSV取込（UC-019） | 行ごとに格納チェックを通して関連付け。エラーの行は行番号と理由を表示し、同じファイルを取り込み直しても結果は変わらない |
10ロット・消費期限（UC-020）
ロットは品目×ロット番号で1つだけあり、消費期限の正しい値をロットが持ちます（BR-018）。在庫のあるロットを期限の近い順に表示し、在庫状態区分ごとの数量と、期限切れ（赤）・期限間近（黄）を示します。期限切れのロットは引当の対象になりません。
11棚卸（UC-021〜023）
棚卸差異は、棚卸責任者（マネージャ）の承認を経て在庫調整の取引として記録します。在庫量を直接書き換えることはありません（BR-009）。棚卸指示の状態は「登録 → 開始 → 結果登録中 → 確定」と進みます。
- 棚卸指示（マネージャ）: 倉庫・対象ゾーン・基準時点・実施期間を登録し、開始すると倉庫担当者に通知されます。
- 実数の登録（倉庫担当者）: ロケーション・品目を読み取り、実数を入力します。差異（実数 − システム在庫量）が表示されます。
- 確定（マネージャ）: 差分リストで差異を確認し、必要なら再カウントを指示してから確定します。
12予実（UC-024）
受注・出荷・発注・荷受・ロケーション移動・在庫の予定と実績を、品目ごとに「実績 / 予定」で並べて表示します（BR-014）。行を押すと、その品目の在庫推移（過去30日の実績と30日先までの見込）がグラフで表示され、安全在庫を割る見込みがあれば、その日付と対応を促すメッセージが出ます。
13在庫計画（UC-004〜007）
| タブ | 内容 |
|---|---|
| 期首在庫・安全在庫（UC-004） | 期首在庫は保有の値を直接書かず、期首日付の在庫調整取引として記録。すでにある場合は逆仕訳してから記録し直す |
| 在庫CSV一括取込（UC-005） | 行ごとに検証し、エラーの行は行番号と理由を表示。同じ行は二重に取り込まない（BR-015） |
| 販売可能数の配分（UC-006） | 販売先ごとの配分比率（合計100%）で引当可能数を配分し、受注管理へ提供。配分比率は権限外には「***」で表示 |
| 引当ルール（UC-007） | 先入先出・先期限先出・ロット指定・ピッキング棚優先・同一ゾーン優先。対象が具体的なルールほど優先 |
14在庫確認・発注依頼（UC-026）
品目を選ぶと引当可能数の合計と安全在庫量、発注が必要かどうかの目安が表示されます。数量・入荷倉庫などを入れて「発注を依頼する」を押すと、発注管理が注文書を発行し、その番号が表示されます。発行された注文書は、発注先が入荷予定を登録するときに選べるようになります。
15データ（全エンティティ）と監査ログ
設計モデルのすべてのエンティティを分類ごとに一覧できます。詳細画面では参照先へのリンクと、このデータを参照している関連データ（ドリルダウン）の件数を表示します。マスタ・利用者の登録・編集はシステム管理者だけが行い、マスタは削除せず無効化します（BR-011）。
物流取引・在庫調整・棚卸確定・引当と配分の変更・マスタ変更・権限変更・CSV取込・ログインなどを、誰が・いつ・何を・なぜ行ったかとともに追記専用で記録します（BR-016）。「改ざん検知」でハッシュの連鎖を最初から検証できます。
16業務ルールと状態遷移
16.1 業務ルール
| 番号 | ルール | 画面での現れ方 |
|---|---|---|
| BR-001 | 在庫量は期首在庫と移動から計算する値で、直接書き換えない | 在庫量を入力する画面はない。期首在庫も取引として記録 |
| BR-002 | 物流取引の移動の数量の合計はゼロ | 移動・棚入れ・加工は、必ず払出と受入の組で記録 |
| BR-003 | 予定を実績で上書きせず、対応付けて残す | 予実・入荷進捗で予定と実績・予定残を並べて見られる |
| BR-004 / 005 | 格納はすべて同じ格納チェックを通り、最大格納数を超えない | 棚入れ・移動・一括移動・関連付け・CSV取込で同じ理由のエラー |
| BR-006 | 検品前の商品は棚入れ・引当しない | 検品前のボックスは棚入れ・クロスドック・加工完了ができない |
| BR-007 | 入荷は注文書（PO）をキーにトラッキング | 入荷予定・荷受け・検品・棚入れがすべて PO でつながる |
| BR-008 | 入荷待ちの注文はクロスドック | 棚入れ画面の「入荷待ちの注文があります」 |
| BR-009 | 棚卸差異は棚卸責任者が確定し、在庫調整として記録 | 確定はマネージャのみ。自分で数えた結果の確定には理由が必要 |
| BR-010 | 利用権限区分ごとに使える機能と見える範囲を制御 | メニュー・データの出し分け。発注先は自社分のみ |
| BR-011 | 記録は削除・上書きせず、訂正は逆の移動、取消は取消状態 | 取消・無効化はできても削除はできない |
| BR-012 | 同時操作でも引当可能数・格納上限を超えない | 移動数量が引当可能数を超えるとエラー |
| BR-013 | 引当は払出予定、出荷確定で払出実績 | 在庫一覧の「引当済」「引当可能数」 |
| BR-014 / 015 | 予定と実績を予実算 I/F で通知、CSV 取込は冪等 | 予実画面、取込結果の行番号と理由 |
| BR-016 | 重要な操作を追記専用で記録 | 監査ログと改ざん検知 |
| BR-017 / 018 | 商品の状態は個体・在庫状態区分で持ち、ロットは品目×ロット番号で一意 | 在庫照会の「在庫状態」、ロットでの期限更新 |
16.2 主な状態遷移
| 対象 | 状態の流れ |
|---|---|
| 入荷予定 | 予定 → 連絡受領 → 荷受中 → 検品済 → 一部完了／完了（予定・連絡受領から取消） |
| 入荷ボックス | 入荷済（荷受け）→ チェック済（検品）→ 入庫済（棚入れ・クロスドック） |
| 個体（シリアル管理品） | 検品済 → 流通加工処理済 → 加工処理済 → 出荷済 → 返品済 →（再検品で）検品済 |
| 棚卸指示 | 登録 → 開始 → 結果登録中 → 確定（登録・開始の間はキャンセル可） |
| 引当 | 引当済（払出予定）→ 出荷済（払出実績）。出荷前なら解除 |
17品質とトレーサビリティ
17.1 テスト
| 種別 | 対象 | 件数 |
|---|---|---|
| 単体 | 在庫勘定・格納チェック・状態遷移・認証 | 42 |
| API | ユースケース API（UC-001〜026）・権限と参照範囲・汎用 CRUD・共通 | 51 |
| E2E（API レベル） | 発注依頼 → 入荷 → 出荷 → 棚卸 → 予実の通し業務、デモデータの健全性（全取引が保存則を満たすこと） | 2 |
95件すべて合格しています。
17.2 トレーサビリティ行列
| 追跡レベル | カバレッジ |
|---|---|
| 業務シナリオ（役割の振る舞い）→ アクティビティ | 100%（25/25） |
| アクティビティのアクション → ユースケース | 100%（85/85） |
| ユースケース → エンティティ / シーケンス図 / セキュリティ | 各 100%（26/26） |
| ユースケース → API / バックエンドコード / テスト | 各 100%（26/26） |
| ユースケース → 画面 | 96.2%（25/26。UC-025 は隣接システム向けの API 専用） |
| ビジネスルール → テスト | 100%（18/18） |
| End-to-End 完全追跡 | 100%（26/26） |
18制約事項
- データはメモリ上に保持します。バックエンドを再起動すると、デモデータ（約60日分）を作り直します。
- 引当・出荷確定・予実の通知は、受注・出荷管理システムから API（サービスアカウント）で行います。発注の登録・実施は発注管理システムが行い、デモではスタブで代用しています。
- ハンディターミナル・インテリジェントカート・ラベルプリンタとの機器連携は、画面の読取欄と印刷までです。
- 棚卸でシリアル管理品が多かった場合は、個体を特定できないため数量だけを調整します（シリアル番号の照合は未実装）。
- ブラウザでの E2E テストは未実施です（E2E は API レベル）。多要素認証の登録画面はなく、API で登録します。
- 性能・可用性の目標値は、元の手順書で未整理のため設定していません。