Spec.md

製造実績管理システム 仕様書（ASP.NET Core バックエンド + Blazor Webクライアント版）

プロダクト名：Parallel Factory MES

作成日: 2026-07-15（改訂4：MES機能をWebクライアントに一本化。デスクトップMESクライアントを廃止し、Windows Store配布アプリはWPF製のライセンス購入・登録専用アプリに変更。シートはPC（端末）単位の割当に変更） 改訂5: 2026-07-16（ロット・BOMをデータモデルに追加しトレーサビリティ／部材自動消費の根拠を定義。シート購入を複数SKU方式に変更。購入登録の一意キーをアプリ生成の購入トラッキングIDに変更し、購入リカバリ手順を拡充） 改訂6: 2026-07-16（シート調整（返金対応）エンティティ追加、アクティベーションコード失効時のシート解放を定義、「端末」＝ブラウザプロファイルの定義明確化、JWT保管・リフレッシュ・CSRF対策の規定、初期管理者セットアップの定義、Storeポリシー適合の事前確認をフェーズに追加） 改訂7: 2026-07-16（.NET 10（LTS）へ変更、製造日（業務日付）境界の定義、工順の方針（工程ごとに指示分割）、在庫更新の楽観的同時実行制御、アクティベーションコードの形式・レート制限、バックアップ・リストア方針（7.7節）を追加） 改訂8: 2026-07-16（課金モデルを消費型シートから恒久エディション（Durable）＋サブスクリプションの併売に変更。総シート数＝所有エンタイトルメントの合算とし、エンタイトルメント同期方式を定義。購入トラッキングID・消費完了報告・シート調整（SeatAdjustment）を廃止し、返金・解約はライセンス照会の再同期で自動反映） 改訂9: 2026-07-21（標準業務一覧（ENAA）のMES対象「〇」項目に基づき機能スコープを再定義。製造指図管理・差立・段取り・チェックリスト・検査指示/判定・不適合管理・出荷/棚卸・保全計画/治工具寿命管理・従業員スキル管理・出荷判定等を追加し、機能モジュール詳細（3章）・データモデル（5章）・画面一覧（6章）・開発フェーズ（10章）を拡充） 改訂10: 2026-08-16（商用化を当面予定しないため、1.4節「製品構成・課金モデル」（課金方式・エディション構成・購入フロー・返金方針）を削除。7.1節の具体的なエディション構成・シート数の記載も削除。シート・端末管理の技術仕様（2.2節・5.6節・Phase 8〜9）は将来の実装候補として残置） 改訂11: 2026-08-22（3.9節に「ロットの使用可否」を追加。部材投入・FEFO自動引当・出荷実行で在庫ステータスと有効期限を同一条件で判定することを定義し、判定をLotUsabilityPolicyへ集約。出荷判定の承認後に保留・不良となったロットの出荷、および有効期限切れロットの投入・引当・出荷を不可とした） 改訂12: 2026-08-22（5.3節にLotGenealogy（ロット系譜）とLotStatusHistory（ロット状態履歴）を追加。分割・統合・振替の系譜をLot.親ロットIDの単一親からLotGenealogyへ移し、統合されたロットも前方・後方追跡できるようにした。在庫ステータスの変更は契機を問わず遷移履歴を残すこととし、トレース画面の履歴タブに状態履歴を追加） 改訂13: 2026-08-22（5.4節にInspectionOrderItemを明記し、検査指示の発行時点の検査基準（規格値・項目名・版数・検査方法・サンプリング数）をスナップショットとして保持する方式へ変更。自動判定・詳細画面・検査成績書はスナップショットを参照し、基準改訂後も過去ロットの判定根拠と成績書を再現できるようにした。5.7節に「検査基準の版と過去実績」を追加） 改訂14: 2026-08-22（3.9節に「部材投入の照合」を追加。手動の部材投入で作業指示の品目のMBOMに定義されていない品目を投入不可とし、判定をMaterialIssuePolicyへ集約。代替材料はMBOMの代替部品グループで表現することとし、代替使用時の個別承認は将来拡張とした） 改訂15: 2026-08-22（7.6節に監査ログ詳細の記録方式を追加。IAuditLoggerの詳細をobject型に変更し、変更前後を追跡したい操作は{ before, after, reason }のJSONで記録するようにした。実績訂正・検査実績訂正・在庫の数量調整/ステータス変更/分割/統合/振替を移行） 改訂16: 2026-08-22（実績訂正を業務履歴として残す方式を追加。5.2節にProductionRecordCorrection、5.4節にInspectionResultCorrectionを追加し、5.7節に「実績訂正の扱い」を定義。訂正前の値をトレース画面の履歴・検査詳細画面・検査成績書から参照できるようにした） 改訂17: 2026-08-22（生産実績に不良数の内訳として廃棄数・再作業待ち数を追加。3.2節の製造実績報告、5.2節のProductionRecord／ProductionRecordCorrection、5.7節に「出来高の数量区分」を追加。品質分析サマリ（C-40-10-03）にも内訳を集計するようにした） 改訂18: 2026-08-22（不良理由マスタ（DefectReason）と不良明細（ProductionDefect）を追加。実績入力で不良数を不良理由別に分解して記録し、品質分析に不良理由別の不良数・構成比の集計（C-40-10-01）を追加。マスタ管理画面に不良理由タブとCSV一括入出力を追加） 改訂19: 2026-08-22（製造指図の工程展開時に工順とMBOMを実績側へ固定する方式を追加。作業指示に工順スナップショット（標準時間・必要スキル・工程管理項目・チェックリスト）、指図に予定材料（ManufacturingOrderMaterial）を持たせ、差立のスキル照合・部材投入の照合・バックフラッシュをスナップショット基準に変更。5.2節にエンティティ、5.7節に「指図展開時のマスタ固定」を追加） 改訂20: 2026-08-23（作業指示の状態履歴（WorkOrderStatusHistory）を追加し、配布・着手・完了・承認・取消の遷移を記録。MBOMに代替部品フラグを追加し、代替部品の投入時に代替理由の入力を必須として投入実績へ記録するようにした。出荷判定ゲートの条件をShipmentGatePolicyへ集約） 改訂21: 2026-08-23（単独PC完結のデスクトップ配布形態（MesApp.Desktop）を追加。プロセス内でKestrelをループバック起動しWebView2でBlazorクライアントを表示するMSIXアプリとしてMicrosoft Storeへ公開する。DBファイル・JWT署名鍵の既定の保存先を実行ファイルの隣から書き込み可能なユーザーデータディレクトリへ変更。7.2節に配布形態、7.8節にMSIX公開の要件を追加） 改訂22: 2026-09-02（書き込みの原子性と競合時の応答を3.9節に追加。複数回の保存に分かれる操作（受入・ロット分割・ロット振替・検査指示発行）を明示的なトランザクションでまとめ、在庫の楽観的同時実行制御と採番衝突をProblemDetailsの409へ変換することとした。7.4節に初回パスワード変更の強制をAPI側で行うことを追加し、搬送指示（B-50-10）の更新系を在庫操作と同じ在庫権限に揃えた） 改訂23: 2026-09-02（7.4節にリフレッシュトークンの再利用検知（失効済みトークンの再提示で当該ユーザーの全トークンを失効）と保持期間を追加。7.6節に監査ログの保存はキャンセルしないことを明記。JWT署名鍵の生成をプロセス内で1回に統一し、鍵ファイルの作成を原子的にした） 改訂24: 2026-09-02（7.5節に一覧APIのページングを追加。運用とともに増える一覧（在庫トランザクション・稼働ログ・治工具利用実績・製造指図・検査指示・不適合・出庫・棚卸・保全指示・出荷判定・トラブル報告・搬送指示）を {items, total, page, pageSize} の応答に変更し、画面に共通のページ送りを置いた。選択肢として全件が要る一覧と、SQLiteの制約で絞り込みをクライアント側で行っている一覧は対象外とした） 改訂25: 2026-09-02（3.6節に「システム管理者を失わない」制約を追加。有効なシステム管理者が0人になる無効化・降格を、ユーザー管理画面とマスタCSV取込の双方で拒否する。判定はLastAdminPolicyへ集約） 改訂26: 2026-09-02（7.5節に選択肢API（options）を追加。ドロップダウンの元になっていてページングできなかった在庫・作業指示・出荷指示について、検索で絞り込む選択肢APIを用意し、一覧側をページング対象に加えた。工程別進捗の集計もDB側へ移した） 改訂27: 2026-09-03（7.4節にHTTPSの扱いを明記。サーバー運用のHTTPSは配置側（Kestrelの設定・リバースプロキシ）で用意することとし、アプリ側では強制しない（HTTPSリダイレクト・HSTSを入れない）。単独PC配布がループバックHTTPで動作するため） 改訂28: 2026-09-03（2.2節Eに初期管理者パスワードの自動生成を追加。デスクトップ配布で全インストール共通の固定パスワードを同梱していたのをやめ、インストールごとに生成して画面に表示する。生成値は保存せず、変更が済むまでは起動のたびに作り直す。パスワードの指定も自動生成もない場合は初期管理者を作らない） 改訂29: 2026-09-03（3.9節に採番の方式を追加。既存番号の最大値+1をやめ、採番テーブル（NumberSequence）の1行を更新してから読む形にして、同時採番でも番号が重複しないようにした） 改訂30: 2026-09-03（7.4節に参照系と更新系の線引きを明記。コントローラのクラスにロール指定を付けないこと（認可属性が合成され参照系を開放できない）を規約化し、製造実行の記録を現場作業者・生産管理・システム管理者に限定した（RoleGroups.ShopFloorRecord）。設備稼働報告・治工具使用実績・保全依頼・不適合報告は意図的にロールで絞らないことを明記） 改訂31: 2026-09-03（7.5節の「マスタは件数が有界」の前提に目安（1マスタ1,000件）を入れ、品目マスタだけは前提が成立しないとして選択肢API（api/products/options）を追加した。品目を選ばせる画面は全件取得をやめ、検索付きの選択肢に統一する） 改訂32: 2026-09-03（6.1節に画面のロール制御の方針を明記。画面自体は全員が開け、書き込みの操作要素だけをAuthorizeViewで隠す形に統一した（在庫・受入・出庫・出荷・棚卸・差立・段取りの7画面に適用）。ナビゲーションは全ロールに全項目を出す） 改訂33: 2026-09-03（3.9節の製造日（業務日付）に基準タイムゾーンの設定（BusinessDay:TimeZone）を追加。未設定はサーバーのローカルタイムで従来どおり。範囲の算出をその日のUTCオフセットに直し、夏時間のある地域で1時間ずれるのを防ぐ） 改訂34: 2026-09-03（2.2節の冒頭に、A・B・Dと端末認証が未実装（Phase 8〜9・将来拡張）であることを明記。断定形の記述が実装済みと読めていたため。docs-dev/CodeMap.md の作業時間記録の「テストなし」を実態（ExecutionTests）に修正し、.gitignore を settings.local.json だけの除外に変えて .claude の launch.json・commands をリポジトリに含めた（CLAUDE.md がこれらを前提にしているため）） 改訂35: 2026-09-03（7.6節に監査ログの参照（GET api/audit-logs・監査ログ画面・参照専用）と保持期間（5年・自動削除しない）を追加。記録するだけで読み出せず「追跡可能にする」を満たしていなかった。6.1節の画面一覧に監査ログ画面を追加し、detailのenumを名前で保存することを明記） 改訂36: 2026-09-03（7.6節の［将来拡張］だった監査ログの一括削除を実装。システム管理者が監査ログ画面（または POST api/audit-logs/purge）から、保持期間を過ぎた分だけを削除できる。保持期間の内側は削除を拒否し、理由を必須とし、削除したこと自体を監査ログに残す。画面は件数の確認→実行の二段階とし、期間か理由を変えたら確認をやり直させる（?dryRun=true）。保持期間は Audit:RetentionYears で変更可能。6.1節の画面一覧にも反映） 改訂37: 2026-09-03（7.4節に「同じマスタは単票APIとCSV取込で同じ権限にする」を追加。スキル・資格マスタが単票APIはシステム管理者専用なのにCSV取込はマスタ更新権限で通り、フォームからは登録できないマスタがCSVからは書き換えられていた。あわせて6.1節に、権限不足で画面を開いたときはログイン画面へ戻さず理由を表示することを追加し、検査実績の訂正と着手・実績登録の操作要素をAPIと同じロールで隠すようにした） 改訂38: 2026-09-03（7.5節の選択肢APIに作業者（api/users/options）を追加。ユーザー管理APIがクラス単位でシステム管理者に絞られていたため、差立（B-10-20）で生産管理担当者が作業者を選べなかった。7.4節の規約どおりクラスは[Authorize]に戻し、管理系のアクションへ個別にロールを付けたうえで、選択肢は有効なユーザーの氏名だけを返す。受入コントローラのクラス指定も同じ形に直した） 改訂39: 2026-09-03（APIだけで画面から操作できなかった機能に画面を用意した。実績入力画面へ部材投入（B-30-20-01）・製造条件データ（B-30-30-04）・実績訂正（B-70-30-01）・状態履歴を追加し、製造指図詳細に変更（A-20-20-02）、検査詳細に検査指示の取消を追加。作業時間記録（B-30-30-02／F-30-20-02）と工程間搬送・移動指示（B-50-10）は独立画面として新設し、6.1節の画面一覧に加えた。docs/reference.md の「画面のないAPI」の節は役目を終えたため機能と画面の対応表に置き換えた） 改訂40: 2026-09-15（7.6節に「実績データの保持とアーカイブ」を追加。保持期間の定めが監査ログとリフレッシュトークンにしかなく、設備稼働履歴・製造条件データ・在庫トランザクション等が無制限に増えていた。実績データを「追跡の連鎖」「連鎖に付随する業務履歴」「運用ログ」の3層に分け、層ごとに削除可否と保持期間を定義。追跡の連鎖は削除せずアーカイブ対象とし、運用ログのみ監査ログと同じ二段階の手動削除とする。アーカイブ機構は将来拡張） 改訂41: 2026-09-15（3.9節に「製造品の識別方式」を追加。シリアル管理が将来拡張と書かれている一方でバッチ管理は言及がなく、対象かどうかが読めなかった。バッチ管理は対象外とし、ロットの統合では代替できない理由（統合は物理的に混ぜる操作、バッチは同一性を保ったままの同時処理）と、まとめ処理の事実を作業指示に紐づく設備稼働履歴で残す方針を明記） 改訂42: 2026-09-15（5.7節に、MBOMの部品切替を有効日／失効日で持つ方式を採らない理由を追記。実績側スナップショットの方針との関係を明示し、この方式では設計変更の予告運用（A-40-10-05）ができないこと、当面の運用と将来拡張時の形（マスタに有効期間を持たせず「切替予定」を別に持つ）を記録） 改訂43: 2026-09-15（作業区（WorkCenter）マスタを追加。設備の所在が Equipment.Site の自由記述、ロケーションがフラットで、差立と進捗集計の軸が設備しかなかった。工場・ライン・エリア・作業区を1つの自己参照ツリー（BOR）で持ち、段の飛び越し・上位のない下位段・循環を Api/Policies/WorkCenterHierarchyPolicy で拒否する。判定は単票APIとCSV取込の両方から呼ぶ。5.1節・6.1節の画面一覧・3.8節のCSV対象に反映。設備・ロケーション・工順からの参照は別途対応） 改訂44: 2026-09-15（設備・在庫ロケーションから作業区（改訂43）を参照できるようにした。設備は最下段の作業区のみ、ロケーションは段を問わず紐付ける。理由は5.7節「資源階層への紐付け」に記載。Equipment.Site は設置場所の正を作業区参照へ移し、自由記述は移行用の旧項目として残す。CSVは equipments・locations に WorkCenterCode 列を追加し、列を省けば現在の紐付けを保ち、列があって空欄なら紐付けを外す） 改訂45: 2026-09-15（工順（BOP）・作業指示・従業員に作業区を追加し、工程別進捗を作業区で絞り込めるようにした。工順の作業区は設備と同じく最下段のみとし、指図展開時に作業指示へスナップショットする（設備は差立で割り当てるため、作業区を設備から導くと差立前の指示が集計に乗らない）。従業員の作業場所は段を問わない。GET api/work-orders/process-summary?workCenterId= は指定した資源と配下すべての作業区へ展開して絞り込む。CSVは routing に WorkCenterCode、users に作業場所の WorkCenterCode を追加。5.1節・5.7節・6.1節に反映） 改訂46: 2026-09-15（設備稼働履歴に対象作業指示を追加し、稼働状態にアイドルを足した。設備実績が設備ID＋時刻しか持たず、「このロットを作ったときの設備状態」を時刻の重なりから推測するしかなかった。ロットの履歴（H-30-10-04）に設備稼働履歴を追加し、産出した作業指示に紐づく稼働区間を辿れるようにした。稼働サマリにアイドル時間を追加し、時間稼働率の分母にも含める。方針は5.7節「製造品軸と設備軸の紐付け（2軸データ）」に記載） 改訂47: 2026-09-15（工程管理項目マスタ（ControlItem）を追加。Routing.ControlItems が自由記述1本で、実績側にも指示値・許容範囲が無く、製造条件の逸脱を自動判定できなかった。検査項目と同じ形（対象品目/工程・指示値・許容上下限・版数）とし、指示値が許容範囲の外にある登録は拒否する。判定条件は単票APIとCSV取込で共通。5.1節・5.7節「製造条件の指示値と実績値」・6.1節・3.8節に反映。工順への紐付けと逸脱判定は続けて追加する） 改訂48: 2026-09-15（工程管理項目を指図展開時に作業指示へスナップショットする（WorkOrderControlItem）。検査基準と同じく、対象品目/工程に合致する有効な項目を自動選択し、工順には明示的な紐付けを持たせない。マスタを改訂しても展開済みの指示値・許容範囲・版数は変わらない。GET api/work-orders/{id}/control-items と実績入力画面に「製造条件の指示」を追加。5.2節・5.7節に反映） 改訂49: 2026-09-15（製造条件の実績を指示と照合して逸脱を判定するようにした。あわせて、サーバー側で時刻を文字列にする履歴表示を工場のタイムゾーンへ変換するようにした（IBusinessDateService.ToFactoryTime）。UTCのまま文字列にすると、画面がローカル時刻へ直して表示する箇所と食い違う。判定は Api/Policies/ControlItemDeviationPolicy に集約し、基準は作業指示のスナップショットを使う。数値でない記録と上下限を持たない項目は判定対象外とし、逸脱フラグはnullのままにする（falseにすると条件を決めていない項目まで合格扱いになる）。逸脱は監査ログの detail に内容を残し、ロットの履歴（H-30-10-04）では逸脱した記録だけを出す。実績入力画面に指示項目の選択と判定表示を追加。Routing.ControlItems の自由記述は当面残す） 改訂50: 2026-09-15（工順に候補設備（RoutingEquipment）を追加し、差立で候補内からしか設備を選べないようにした。工順が設備を1台に固定していたため代替設備を表せず、設備故障時に工順を書き換えるしかなかった。候補が未登録の工順は従来どおり限定しない。Routing.EquipmentId は候補の1つとして扱い、画面は候補リストに一本化する。GET api/work-orders/{id}/equipment-candidates を追加し、差立画面は候補があればその中だけを出す。CSVは routing に EquipmentAssetNos（セミコロン区切り）を追加。5.1節・5.7節に反映） 改訂51: 2026-09-15（設備の保全部品（EquipmentPart）を品目マスタ参照にした。Equipment.MaintenanceParts が自由記述1本で、3.5節に消耗材の使用状況モニタリング（E-20-10-04）があるのに受け皿が無かった。資産管理部品（金型）と消耗品（Oリング）を区分で分け、登録は設備ごとの一括置換とする。GET/PUT api/equipments/{id}/parts と設備タブの編集、CSV種別 equipment-parts を追加。自由記述は移行元として残し、保全実績からの在庫引落しは続けて追加する。5.1節・5.7節・6.1節・3.8節に反映） 改訂52: 2026-09-15（保全実績に消費部材（MaintenanceRecordPart）を追加し、在庫を引き落とすようにした。引落しは既存の InventoryService 経由で行い、在庫履歴に新しい区分 保全消費（InventoryTransactionType.MaintenanceIssue）として残る。使える現品かの判定は部材投入・出荷と同じ LotUsabilityPolicy を通す。資産管理部品として登録済みの品目は数量在庫の引落し対象外（個体・寿命で管理するため）。保全部品として未登録の品目は突発保全がありうるため通す。消耗材モニタリング GET api/maintenance-orders/parts-consumption（E-20-10-04）と保全画面のタブを追加。5.5節・5.7節・6.1節・3.5節に反映） 改訂53: 2026-09-15（作業手順書（SOP。WorkProcedure）を追加した。保全側にだけ手順書（MaintenanceProcedure）があり、製造の作業者が参照する手順の置き場が無い非対称を解消する。紐付けは工順（BOP）側から行い（Routing.WorkProcedureId。I-30-20-12）、手順書側に対象品目・対象工程は持たせない。手順書の作成自体はMESの対象外（I-30-30-01）なので、本文を置けない場合に備えて所在（文書番号・URL）だけの登録も許す。更新のたびに版数を上げる。工順から参照中の手順書は無効化できない。api/work-procedures、マスタ画面の作業手順書タブ、CSV種別 work-procedures と工順CSVの WorkProcedureNo 列を追加。5.1節・3.1節・3.8節・6.1節に反映） 改訂54: 2026-09-15（作業手順書（SOP）を指図展開時に作業指示へ紐付け、作業指示から手順を確認できるようにした（B-10-30-03）。手順の本文は固定せず版数だけを固定する：安全上の訂正のように改訂した手順は仕掛中の作業指示にも届くべきなので、表示はマスタの現在値を使い、展開時点の版数と食い違えば「改訂あり」を出す。製造条件（WorkOrderControlItem）が本文ごと固定するのは逸脱の判定基準が後から変わってはいけないためで、手順書とは前提が違う。GET api/work-orders/{id}/procedure と作業指示画面の手順表示を追加。5.2節・5.7節・3.1節に反映） 改訂55: 2026-09-15（勤務シフト（直。Shift）マスタと従業員の所属・所属する直を追加した。3.9節の製造日（業務日付）は夜勤の日跨ぎ実績を同じ製造日へ集めるための仕組みだが、「その実績がどの直か」を表す定義が無かった。夜勤は終了時刻が開始時刻以下という形で日跨ぎを表し、翌日フラグのような別項目は持たない。時間帯が重なる直は登録できない（重なると実績の直が一意に決まらない）。誰がいつどの直に入るかの勤務計画は持たない（勤怠管理 F-30-10 は対象外）。api/shifts、マスタ画面の勤務シフトタブ、CSV種別 shifts と users の Department・ShiftCode 列を追加。5.1節・3.6節・3.8節・5.7節・6.1節に反映） 改訂56: 2026-09-15（生産実績に直（ProductionRecord.ShiftId）を持たせ、品質分析に直別の不良集計を追加した（C-40-10-03）。直は実績の記録時に開始時刻から引いて固定する。集計のたびに時刻から引き直すと、直の時間帯定義を変えたときに過去の集計まで動くため（5.7節 指図展開時のマスタ固定と同じ考え方）。直を登録していない運用の実績は「（直なし）」にまとまる。5.2節・5.7節・3.3節に反映） 改訂57: 2026-09-15（ユーザー登録画面が所属（部署・課）・作業場所（作業区）・所属する直を入力させながら、登録APIがそれらを受け取っておらず黙って捨てていた不整合を直した。3.6節は登録時点で従業員情報を持つと書いているのに、実際には登録後にもう一度編集しないと反映されなかった。登録でも更新と同じ検証（存在しない作業区・無効な直は拒否）を通して保存する。検証はユーザーを作る前に行う（作成後に弾くと所属だけ欠けたユーザーが残る）） 改訂58: 2026-09-15（参照されているマスタの無効化が、単票APIでは拒否されるのにCSV取込からは素通りしていた不整合を直した。対象は工順から参照中の作業手順書と、在籍中の従業員が所属する直。判定を MasterDeactivationPolicy へ集約し、両経路で同じ条件・同じ文面で拒否する（改訂25の LastAdminPolicy と同じ扱い。片方にだけ置くと迂回経路になる）。3.8節に反映） 改訂59: 2026-09-15（記録済みの直（ProductionRecord.ShiftId）を実績照会でも辿れるようにした。改訂56で直を固定したが出口が品質分析の集計だけで、ある実績がどの直に入ったかを現場が確認できなかった（作業者・作業区は実績照会に出るので軸の扱いが揃っていなかった）。実績一覧の列とロット履歴（H-30-10-03）の製造行に直を出す。訂正しても直は動かない。5.7節に反映） 改訂60: 2026-09-16（直の時間帯と製造日の境界時刻（3.9節。既定6時）が互いを見ておらず、境界をまたぐ直（22:00〜翌07:00など）を無言で登録できた。その直の実績は2つの製造日へ分かれるため、日報と直別集計で母数が食い違う。拒否ではなく警告とする——交代時刻と日次締めの時刻が揃わない工場はあり、運用として成立しうるため。判定は ShiftSchedulePolicy.CheckBusinessDateBoundary、伝達は ShiftResponse.BoundaryWarning で、登録時だけでなく一覧にも出し続ける（境界時刻は設定値なので、設定変更で後からまたぐようになることもある）。5.7節に反映） 改訂61: 2026-09-16（直まわりで書かれていなかった振る舞いを明文化し、無言だった箇所に案内を足した。①全実績が「（直なし）」のとき、品質分析が直別の表を出すだけで理由を伝えていなかったため、直の定義を促す案内を出す（集計キーは ShiftLabels.NoShift としてAPIと画面で共有）。②直の名称の変更は過去の集計表示にも及ぶ（集計は固定した ShiftId で行い、表示名はマスタの現在値から作るため）。時間帯の変更が過去に及ばないのと非対称だが意図的。③マスタの無効化は画面から、再有効化はCSV取込の IsActive 列から行う（全マスタ共通。画面に再有効化の導線は持たせていない）。5.7節・3.8節に反映） 改訂62: 2026-09-16（設備稼働サマリ（api/equipment-logs/summary）に製造日の期間指定を追加した。従来は終了済みログを全期間集計しており、当日や先週の稼働率を出せないうえ、ログが増えるほど指標として意味を失う。期間は稼働の開始時刻が属する製造日で振り分ける（3.9節。夜勤の日跨ぎ稼働を1つの製造日に寄せるため、終了時刻では分けない）。引数は省略可能で、省略時は従来どおり全期間。3.5節に反映） 改訂63: 2026-09-16（3.8節のダッシュボードが定義（当日実績サマリ・稼働率・不良率・進捗のKPI表示）に対して進捗一覧しか出していなかったため、当日のKPIを実装した。「当日」は暦日ではなく製造日（3.9節。境界は既定6時で設定により変わる）であり、クライアントは境界を知らないため、現在の製造日は api/business-date がサーバー側で解決して返す（画面が DateTime.Today で代用すると、境界をまたぐ時間帯に夜勤の実績が前日・当日へずれる）。集計は既存API（api/quality/summary・api/equipment-logs/summary・api/manufacturing-orders/progress）を製造日で絞って呼ぶだけとし、画面では数えない（7.5節）。KPIの取得に失敗しても進捗一覧は表示する。3.8節・6.1節に反映） 改訂64: 2026-09-16（生産性モニタリング（B-60-10-05）を実装した。3.2節の工程進捗管理に「歩留まり・直行率・標準時間予実」と書かれていたが、対応する集計も画面も無かった。直行率は手直しを経ずに一度で良品になった割合、歩留まりはリワークでの救済を含めた最終的な良品の割合とし、リワーク指図（ManufacturingOrderType.Rework）の産出は分母に入れず歩留まりの分子にだけ足す（同じ材料を二度数えないため）。標準時間の予実は予定＝標準段取り時間＋標準作業時間×計画数量で、どちらも指図展開時に固定した工順の値を使う（5.7節。マスタの現在値で引き直さない）。これに伴い工順マスタの標準時間の意味を5.1節で明示した——標準作業時間は1個あたり、標準段取り時間は1回あたり。実績は直接作業時間（F-30-20-01）と段取り実績（B-20-50）の合計で、いずれも終了済みの記録のみを数える。api/productivity と /productivity 画面を追加。3.2節・5.1節・6.1節に反映） 改訂65: 2026-09-16（設備総合効率（OEE。E-20-30-03）を三要素で算出するようにした。従来は時間稼働率だけで、EquipmentLogStatus.Idle を停止と分けた理由（OEEの時間区分）に実装が追いついていなかった。負荷時間は記録済み総時間とする——計画休止を表す区分を持たないため除外できない。区分を増やすのは、計画休止を記録する運用が定着してから（EquipmentLogStatus への追加は末尾のみ：JSONが数値）。理論サイクルタイムは指図展開時に固定した標準作業時間（1個あたり。5.1節）を使い、工順マスタの現在値では引き直さない。性能稼働率と良品率は作業指示に紐づけて記録した稼働（EquipmentLog.WorkOrderId）からしか導けないため、紐付けのない稼働区間は対象外とし、カバー率（紐づいた稼働÷全稼働）を併記する。産出0として扱うと記録漏れが設備の悪い評価に化けるため、算出できない指標は0ではなくnullで返す（画面は「-」）。差立の割当設備では補完しない（割当と実際に動いた設備は一致するとは限らない）。同じ設備の同じ時間帯に複数の作業指示が紐づく場合（まとめ処理。3.9節）は重なりを按分して同じ時間を二重に数えない。1つの作業指示が複数設備で動いた場合は産出を稼働時間の比で配分する。api/oee を稼働サマリと別に置く（あちらは稼働監視の素の時間区分、こちらは製造実績と突き合わせた評価指標）。3.5節・6.1節に反映） 改訂66: 2026-09-16（検査機・測定器マスタと校正管理（C-20-50-03）を追加した。3.3節に「検査機の校正管理・有効期限確認」と書かれていたが実装が無く、校正期限を過ぎた機器で測った結果が合格として通る状態だった。マスタは現在の校正状態（最終校正日・次回校正期限・校正周期）を持ち、校正の実施は履歴（InspectionDeviceCalibration）に残す——現在値の上書きだけでは「いつ誰がどの結果で校正したか」が消えるため（保全実績と同じ考え方）。検査実績の登録時に期限を判定し、期限切れ・無効化された機器は使わせない（InspectionDeviceCalibrationPolicy。期限接近の一覧と同じ条件を使う）。期限を設定していない機器は判定しない（基準が無いため）。検査実績に使用した検査機を任意で記録し、検査成績書に出す。治工具（Tool）と別のマスタにしたのは、治工具が寿命（回数・時間）で管理されるのに対し検査機は日付で管理され、期限切れの影響が「使えない」ではなく「測定結果を信用できない」だからである。CSV種別 inspection-devices を追加。3.3節・5.1節・5.4節・3.8節・6.1節に反映） 改訂67: 2026-09-16（工程レベルの遅延検知（A-30-20-01）と不良理由のパレート表示（C-40-10-01）を追加した。遅れの検知は指図の納期超過しか無く、工程が遅れていても完了するまで気づけなかった。api/work-orders/delays が①指図の納期を過ぎて未完了の作業指示 ②着手済みで経過時間が予定時間（段取り＋作業×計画数量。展開時に固定した工順の値）をしきい値（既定20%）以上超えている作業指示 の2種類を返す。通知の仕組み（メール・プッシュ）は持たないため画面に出すところまでとし、工程進捗画面に一覧、ダッシュボードに件数を出す。標準時間が未設定の工程は超過を判定できないため対象にしない（0分に対する超過率は意味を持たない）。経過時間は着手（状態履歴。5.2節）からの実時間で、休憩や段取り待ちも含む。不良理由別の集計には累積構成比を足し、パレート図として読めるようにした（構成比を丸めてから積むと合計が100%からずれるため、数量の累計から毎回求め直す）。3.2節・3.3節・6.1節に反映） 改訂68: 2026-09-16（7.6節に「電子記録・電子署名規制（21 CFR Part 11 / EU Annex 11）は対象外」を明記した。本システムは加工・組立産業を前提としており（1.3節）、医薬・医療機器の規制には対応しない。監査ログがあることをもって規制対応済みと解釈されるのを防ぐための記述であり、機能の追加や変更は伴わない。規制が求める①電子署名の本人固有性・否認防止 ②監査証跡の改ざん検知 ③バリデーション文書 のそれぞれについて、本システムの実際（ロール操作＋監査ログによる単段階承認、保持期間を過ぎた監査ログの手動一括削除を許容、自動テストはあるが規制形式の検証文書は作らない）との食い違いを表にした。対応するなら承認フロー（3.9節）と監査ログの設計そのものの見直しになるため、［将来拡張］ではなく対象外とする） 改訂69: 2026-09-16（治工具の引当・払出・受領確認（B-20-30-01〜03）と寿命分析（E-60-20-03）を追加した。治工具マスタ・利用実績・寿命通知はあったのに、前段取りで治工具を確保する経路が無く、「いま誰がどの治工具を持っているか」を追えなかった。ToolIssue が引当→払出（受領確認）→返却を1レコードで表す。利用実績（ToolUsage）とは統合しない——こちらは現物の所在、あちらは寿命の累計で、片方だけを記録する運用もありうるため。引当可否は ToolIssuePolicy に集約し、引当時と払出時の両方で判定する（引当から払出までの間に寿命へ達したりメンテへ入ったりしうるため）。無効・廃棄・メンテ中・寿命到達・他の作業指示に引当中の治工具は引き当てられない。引当時に治工具を「使用中」にして二重引当を防ぎ、返却・取消で「使用可」へ戻す（ただしメンテ中・廃棄へ変わっていたらそのまま）。寿命分析は期間内の使用ペース（使用実績のあった日で割る）から寿命到達の見込み日を出す。閾値未設定・期間内に使用なし・すでに寿命到達のものは見込みを出さない（適当な日付を置くと交換計画が実態とずれる）。3.2節・3.5節・5.5節・6.1節に反映） 改訂70: 2026-09-16（設計変更反映時の在庫・生産状況確認（J-40-40-01/03）を追加した。1.3節が「設計〔J〕は各モジュールに包含する」と宣言していながら実体が無く、MBOM・工順を改訂する人が、その改訂がどの指図に届くのかを知る手段が無かった。GET api/products/{id}/change-impact が進行中（未完了・未取消）の指図と、部材の在庫・所要を返す。指図展開時のスナップショット方式（5.7節）のため展開済みの指図に改訂は届かない——この事実を改訂者に見せるのが目的で、IsSnapshotFixed で指図ごとに示す。部材は現行MBOMの部材と進行中指図がスナップショットで持つ部材の和集合とする。一致しない部材（改訂で外したのに指図がまだ必要としているもの）こそ在庫の行き先を判断する材料になるため。改訂そのものを止める判定は入れない（止めるべきかは業務側の判断で機械的には決まらない）。3.1節に反映） 改訂71: 2026-09-16（推奨ロケーション指示（D-10-30-03、D-40-40-03）を追加した。3.4節に機能として書きながら、受入・完成品入庫の入庫先は毎回ロケーション一覧から選ぶだけで、どこへ置くべきかの手がかりが無かった。GET api/locations/recommendations が候補を優先度順に返す。根拠は3段階で、①品目マスタの既定ロケーション（Product.DefaultLocationId。固定ロケーション運用のために新設）②同じ品目の在庫が既にあるロケーション（数量の多い順。散らばると探せなくなる）③品目区分に対応するエリア（製品→製品倉庫、それ以外→部材倉庫）。理由を画面に出す（根拠を伏せた推奨は従われない）。強制はしない——棚が埋まっていることは実地では普通に起こり、機械が決められるのは「どこが妥当か」まで。既定ロケーションは品目CSVの DefaultLocationCode でも設定でき、無効・未登録のロケーションは弾く。3.1節・3.4節・5.1節に反映） 改訂72: 2026-09-16（倉庫業務進捗管理（D-50-30-07）とサンプル品保管管理（D-40-50-01）を追加した。どちらも3.4節に書きながら実装が無かった。進捗は新しいエンティティを持たず、既存の指示（出庫ピッキング・出荷・在庫移動・棚卸）を製造日で数え直す。受入は対象にしない——受入には「指示」が無く実施の記録だけで、件数を並べても他の行と同じ意味で読めないため。取消は分母にも完了にも数えず、滞留を見るために未完了のうち最も古いものの経過日数を併記する。サンプル品は SampleStorage で保管期限まで追う。採取した分は在庫から抜く——保管棚へ移り出荷・投入には使えないので、在庫に残すと引当・先入れ先出しの対象になってしまう。抜く先は保管場所ではなく現物があったロケーション。保管の終了は払出（再試験等で使用）か廃棄かを明示させ、期限前の処分も禁止しない（再試験のための払出は期限前に起こるのが普通で、止めると運用が画面の外へ出る）。期限前だったかは監査ログに残す。3.4節・5.3節に反映） 改訂73: 2026-09-17（実績のCSV一括取込（api/actuals/csv）を追加し、最初の種別として受入を対応した。実績系APIは内部IDを受け取るため、試験・移行用の実績をCSVで用意できなかった。受入の業務処理を ReceivingController から ReceivingService へ移し、単票APIとCSV取込の両方から呼ぶ（トランザクションは呼び出し側が張る。CSVは全行を1つにまとめるため）。列・行数の事前検証と結果の組み立ては CsvImport としてマスタCSVと共有した。サンプルとして samples/actual-csv/ を追加。3.8節に反映。製造指図・製造実行・検査・工数・トラブルの種別は続けて追加する） 改訂74: 2026-09-17（実績CSV取込に製造指図（manufacturing-orders）を追加した。指図の登録・承認・工程展開を ManufacturingOrdersController から ManufacturingOrderService へ移し、単票APIとCSV取込の両方から呼ぶ。後続の実績CSVが作業指示を「指図番号＋工程順序」で指せるよう、CSV取込に限り指図番号の手入力を許した（MO で始まる番号は自動採番と衝突するため拒否）。3.8節に反映） 改訂75: 2026-09-17（実績CSV取込に作業指示の実行記録（段取り実績・チェックリスト実施・部材投入・生産実績・製造条件データ）を追加した。実行系の業務処理を WorkOrderExecutionController から WorkOrderExecutionService へ移し、単票APIとCSV取込の両方から呼ぶ。サービスが失敗を返した行では未保存の変更を捨てる——バックフラッシュの途中で在庫不足になった払出などが追跡中に残り、同じ取込の次の行の保存へ混ざるため。記録者は取込を実行したユーザーとし、作業者を指定する列は持たない。3.8節に反映） 改訂76: 2026-09-17（実績CSV取込に検査（指示・実績・判定）・作業時間・製造トラブル報告を追加した。検査の発行・実績登録・総合判定を InspectionOrdersController から InspectionService へ、作業時間とトラブル報告の登録を ShopFloorReportService へ移し、単票APIとCSV取込の両方から呼ぶ。検査CSVはファイル内のキー（InspectionKey）で行を1件の検査指示にまとめ、キーはDBに残さない。取込の権限は単票APIと同じで、トラブル報告は全ロールに開いている。3.8節に反映） 改訂77: 2026-09-17（実績CSV取込画面（/actual-csv。6.1節 22.1）を追加し、ナビゲーションの「管理」に導線を置いた。マスタ用のCSV入出力パネルを、APIの基点とエクスポートの有無を指定して実績でも使えるようにした。取込欄を出すロールは画面に直書きせず、api/actuals/csv/kinds の WriteRoles で受け取る（APIの権限と表示がずれないようにするため）。6.1節に反映） 改訂78: 2026-09-17（倉庫業務進捗の「未完了のうち最も古いものの経過日数」を、改訂72で定めたとおり製造日同士で数えるよう直した。今日は製造日なのに作成日時をUTCの暦日にしていたため、工場の時刻とUTCで日付がずれる時間帯（日本では0〜9時）の指示が1日古く数えられていた。3.4節の記述は変更なし） 改訂79: 2026-09-17（バックフラッシュが指図の予定材料の全行を消費しており、同じ代替部品グループの主材料と代替部品の両方を原単位ぶん払い出していたのを直した。代替部品の行（IsAlternative）は消費対象から外す。代替部品を使った場合は手動の部材投入で理由とともに記録する。3.9節「部材投入の照合」に反映） 改訂80: 2026-09-17（マスタCSV・実績CSVのZIP一括取込と、全マスタのZIP一括出力を追加した。サンプルだけでもマスタ19・実績12ファイルあり、1ファイルずつ選んで取り込む必要があった。全ファイルを1つのトランザクションで処理し、1ファイルでもエラーがあれば全ファイルを取り消す。マスタと実績の混在ZIPは受け付けない。取込の権限はZIP内の全種別に要る。1ファイルの取込も同じ仕組み（1ファイルのZIPと同じ扱い）に寄せ、MasterCsvService・ActualCsvService は外側のトランザクションに乗る形にした。3.8節に反映） 改訂81: 2026-09-17（ZIPの一括取込・一括出力（改訂80）を画面から使えるようにした。マスタ管理画面の上部に一括取込と全マスタの出力、実績CSV取込画面の上部に一括取込のパネルを置く。結果はファイルごとの成否とエラー、エラーで処理しなかったファイルを表で出す。取込後はマスタの開いているタブを読み直す。6.1節 22・22.1 に反映） 改訂82: 2026-09-17（保全指示を発行済みの保全計画の取消を拒否するようにした。これまでは完了・取消済み以外なら取り消せたため、発行済みの計画を取り消すと保全指示だけが「指示済み」のまま残り、計画と指示の状態がずれていた。取り消すときは先に保全指示を取り消す（指示の取消で計画は計画中へ戻る）。現場が着手しようとしている指示を計画側の操作で連動して消さないため、連動取消ではなく拒否とした。3.5節に反映） 改訂83: 2026-09-17（製造トラブル報告の状態変更を制限した。これまでは発生・対応中・完了のどの状態へも変更でき、完了から発生へ戻すこともできたうえ、監査ログには変更後の状態しか残らなかった。状態は発生→対応中→完了・発生→完了の前進のみとし、同じ状態のまま対応履歴を追記することはできる。完了したトラブルの再発に備え、完了→対応中の再オープンは理由を対応履歴に入力したときだけ認める。発生へ戻すと対応を始めた事実が消えるため認めない。監査ログには変更前後の状態と理由を残す。3.2節に反映） 改訂84: 2026-09-17（設備の状態を差立と保全実績に結び付けた。これまで設備の状態は設備台帳で手入力するだけで、差立は有効フラグと候補設備しか見ていなかったため、保全中・停止中・廃棄の設備にも作業指示を割り当てられた。差立で新しく割り当てる設備は稼働可能のものに限り、それ以外は409で拒否する（割当済みの設備のまま着手順だけを変える差立は通す）。保全指示は予定日を持って前もって発行し着手の状態を持たないため、発行時点では保全中にしない。保全中への切替は保全担当が設備台帳で行い、保全実績の登録で保全中の設備を稼働可能へ戻す（停止中・廃棄の判断は上書きしない）。戻したことは監査ログに変更前後と理由を残す。3.2節・3.5節・5.1節に反映） 改訂85: 2026-09-17（治工具の「使用中」をマスタ編集で付け外しできないようにした。引当で使用中になり返却・取消で使用可能へ戻る一方、治工具マスタの編集とCSV取込では状態を自由に変えられたため、引当中の治工具を使用可能に戻したり引当の無い治工具を使用中にしたりでき、表示上の状態と引当の実態がずれた。使用中は引当から決まる状態とし、手で使用中にする変更（新規登録を含む）と、引当中の治工具を使用可能にする変更を拒否する（APIは409、CSVは行エラー）。引当の無い治工具を使用中から戻す変更は、ずれた表示を直す操作として認める。メンテナンス中・廃棄への変更は引当中でも認める（払出時にもう一度判定するため現物は現場へ出ない）。判定は ToolIssuePolicy に置き、画面・CSVの両方から呼ぶ。5.1節に反映） 改訂86: 2026-09-21（消耗材モニタリング（api/maintenance-orders/parts-consumption）の期間を製造日（3.9節。既定6時境界・工場タイムゾーン）で切るよう直した。ここだけ暦日のUTC 0時を区切りにしていたため、工場の時刻とUTCがずれる時間帯（日本なら0〜9時）の保全実績が隣の日へ寄り、同じ画面に並ぶ他の期間集計（品質分析・稼働サマリ）と日付の意味が食い違っていた。改訂78（倉庫業務進捗の経過日数）と同じ取りこぼし。終端は翌製造日の開始時刻とし、他の期間APIと同じ半開区間に揃える。3.5節に反映） 改訂87: 2026-09-21（監査ログの記録日（AuditLog.RecordedOn）と保持期間の境界を、サーバーのローカル日付ではなく工場のタイムゾーン（BusinessDay:TimeZone）の暦日で求めるよう直した。UTCのコンテナに置いてタイムゾーンを設定しても、この2つだけが設定を見ずサーバー基準のままで、日本なら9時間ぶん現場とずれた。期間の絞り込みが画面の表示（ローカル時刻）と食い違い、一括削除で消せる日／消せない日も1日食い違う。製造日の6時境界は当てない——監査ログは業務の1日ではなく法定の保存年数で数えるため、夜勤を前日へ寄せる意味がない。列の追加前からある行の穴埋め（起動時のバックフィル）だけはSQLiteが任意のタイムゾーンへ変換できないためサーバーのローカルタイムのままとする（一度きりの近似）。7.6節に反映） 改訂88: 2026-09-21（製造日の境界時刻（BusinessDay:BoundaryHour）の不正な設定値に防御を入れた。タイムゾーンは解決できなければ警告してローカルタイムへ落とすのに、境界時刻は素通しで、24 や -1 を書くと TimeOnly・DateTime の生成が例外になった。しかもサービスの生成は遅延のため起動は成功して最初のリクエストで全画面500になり、原因が設定値の書き間違いだと分かりにくい。0〜23の整数以外は警告を出して既定の6時に落とす。あわせて、設定値はプロセス起動時に一度だけ読むこと（変更には再起動が要ること）と、境界を変えたときに過去の集計が遡って動く一方で記録時に固定した値は動かないことを3.9節に明記した） 改訂89: 2026-09-21（CSV取込の結果に警告（CsvImportResult.Warnings）を追加し、直の製造日境界またぎ（改訂60）をCSVからの登録でも伝えるようにした。重なりの拒否と無効化の拒否は「単票APIと同じ判定をCSVでも通す」形になっていたのに、警告だけ単票APIにしか無く、CSVで入れた直に限って登録時に気づけなかった。警告はエラーと違いロールバックしない（Succeeded に影響しない）。取込が失敗した場合の警告は捨てる（取り消された内容についての警告は読み手を混乱させる）。位置引数ではなく既定値を持つプロパティとして足し、ZIP一括取込を含む既存の応答の組み立てを壊さない。5.7節に反映） 改訂90: 2026-09-21（リバースプロキシでHTTPSを終端する配置に対応した。改訂27でHTTPSの終端を配置側の責務としながら、アプリが転送ヘッダを読んでいなかったため、プロキシの後ろではすべての接続がHTTPに見え、リフレッシュCookieに Secure が付かず（7.4節の要件を満たさない）、監査ログの接続元IPが全件プロキシのIPになっていた。信頼するプロキシを ReverseProxy:KnownProxies／KnownNetworks で明示したときだけ X-Forwarded-For・X-Forwarded-Proto を読む。未設定なら読まない（ヘッダ偽装による接続元・HTTPS扱いの詐称を防ぐ）。アプリ側でHTTPSを強制しない方針は変えない。7.4節に反映） 改訂90: 2026-09-21（シート・端末のライセンス管理を実装しないことに決定し、本システムのライセンスを AGPL-3.0 のみとした。改訂10で将来の実装候補として残置していた2.2節A・B・D（ライセンス購入・端末アクティベーション・割当解除）、Cの端末認証、3.8節のシート・端末管理、5.6節（LicenseEntitlement・Device・SeatAssignment・ActivationCode）と5.7節のシート計算、6.1節の端末アクティベーション画面・シート・端末管理画面、6.2節（WPFライセンスアプリ）、7.1節（Store公開・アドオン課金）、7.4節のデバイストークン・アクティベーションコード関連、8〜9章のライセンスアプリ・Store API、Phase 8〜9を削除した。節・画面・フェーズの番号は他所からの参照を壊さないよう欠番として残す。Microsoft Store 配布は単独PC向けの MesApp.Desktop（7.8節）のみ） 改訂91: 2026-09-21（DBプロバイダーをPostgreSQL・SQL Serverへ切り替えられるようにした（4章。Phase 10のうちDB切替）。Database:ProviderにPostgreSql/SqlServerを指定すると、それぞれ専用プロジェクトのマイグレーションを起動時に適用する。1つのモデルから3プロバイダーのスキーマを作るため、PostgreSQLではDateTimeOffsetをUTCで書き込み、SQL Serverでは多重連鎖を避けるためSET NULLをEF側の処理に移し、SQLite以外では精度未指定のdecimalを(18,6)にした。SQLiteのスキーマは変えていない。採番（NumberingService）の生SQLは表名・列名をプロバイダーの引用符で囲み、同時作成で一意制約違反になったときはセーブポイントまで戻してから再試行する（PostgreSQLは失敗した文のあとトランザクションを受け付けないため）。テストは環境変数（MESAPP_TEST_PROVIDER / MESAPP_TEST_CONNECTION）で実DBに向けられ、PostgreSQL 18・SQL Server（LocalDB）で全件通過を確認した。PostgreSQL・SQL Serverでは小数桁固定のdecimalが1.500000のように返るため、読み出し時に末尾ゼロを落としてSQLiteと同じ値の見え方にした。既存SQLiteデータの移行ツールと、実DBでの自動テストの常時実行は将来拡張とした） 改訂92: 2026-09-21（3プロバイダー分のマイグレーションをまとめて追加するスクリプト（scripts/Migrations.ps1）を用意し、4章の将来拡張から「3プロバイダー分を作る運用の省力化」を外した。1つのマイグレーションで3プロバイダーを兼ねる形は、列の型がプロバイダーごとに生成されるため手修正が毎回必要になり採らない。あわせて、マイグレーションに生SQLを書かない規約を4章に加えた） 改訂93: 2026-09-22（7.8節：ストア提出で「予約していない表示名」として弾かれたため、MSIXの表示名をマニフェストへの直書きからbuild/msix-identity.jsonのDisplayNameに移し、予約名と一致させる旨を明記） 改訂94: 2026-09-22（Zip配布とDocker配布を実装した（7.2節。Phase 10完了）。自己完結版zip（win-x64 / linux-x64）とコンテナイメージ（linux/amd64・arm64、GHCR）を、タグpushでGitHub Actionsから公開する。7.7節のDocker構成のバックアップをボリューム退避の手順に改め、9章の構成を実配置に合わせた。あわせて、Linuxで~/.local/shareが未作成のときデータ保存先がカレントディレクトリになる不具合を直した（4章MesAppDataDirectory）） 改訂95: 2026-09-22（7.2節：リリースにサンプルCSVのzipを添付することにした。紹介ページとユーザーガイドを3つの配布方法（Microsoft Store・zip・Docker）に合わせて更新） 改訂96: 2026-09-22（ダッシュボードを当日以外の期間で見られるよう、期間別・軸別の集計API（api/dashboard/trend・api/dashboard/breakdown）を追加した。推移は日・週（月曜始まり）・月で区切り、内訳は工程・品目・直・ライン・作業区・設備の軸で分ける。稼働ログは作業指示との紐付けが任意なので工程・品目では稼働を絞らない（紐付けた区間だけで数えると記録漏れが稼働率に化ける）。設備は作業指示に固定されないので設備軸では生産実績を出さない。求められない指標は0ではなくnullで返す。あわせて、品質分析・生産性・OEEの生産実績を登録時刻ではなく開始時刻の製造日で振り分けるよう改めた。登録時刻では、朝に登録した夜勤の実績が翌製造日へずれ（3.9節の趣旨に反する）、過去日の実績をCSVで入れると取込日に寄っていた。直の判定・稼働ログの振り分けと基準が揃う。3.8節に反映） 改訂97: 2026-09-22（ダッシュボード画面をサマリ・推移・内訳のタブに分けた。サマリは当日固定をやめ、日次・週次・月次の期間を選んで前後へ移動できる（既定は今日の製造日）。推移は日次14日・週次12週・月次12か月を棒（良品・不良）と点（不良率）と表で示し、工程・品目・作業区で絞り込める。内訳は軸を切り替えて表で示す。求められない指標（工程・品目軸の稼働率、設備軸の生産数）は列ごと出さず、理由を画面に書く。週の区切りはAPIと画面で DashboardPeriods を共有する（別々に書くと画面が選んだ週とAPIが数える週がずれる）。6.1節に反映） 改訂98: 2026-09-22（実績CSVに設備稼働記録 equipment-logs を追加した。稼働ログを入れる手段が単票APIしか無く、試験・移行や稼働率の推移を確かめるデータを用意できなかった。登録の判定（有効な設備・終了＞開始・停止と故障には停止原因・作業指示の存在）と監査ログを EquipmentLogsController から ShopFloorReportService へ移し、単票APIとCSV取込の両方から呼ぶ。設備は資産番号、作業指示は指図番号＋工程順序で指す。取込のロールは単票APIと同じく絞らない。あわせて、ダッシュボードの推移・内訳を確かめるための約3か月分（2026-06-29〜09-20の12週。昼勤・夜勤、お盆休み、工具摩耗による故障、不良率の改善を含む）のサンプル samples/actual-csv-bulk/ と生成スクリプト scripts/New-SampleBulkActuals.ps1 を追加し、リリースのzipに加えた。3.8節・7.2節に反映） 改訂99: 2026-09-22（ダッシュボードの数値をグラフで示すようにした。サマリはKPIタイル（前日・前週・前月との差を▲▼で示し、増えると悪い指標は赤）と、稼働率・検査合格率のドーナツ、製造指図の工程進捗のバー。前の期間は同じAPIを同じ条件で呼び直して求める。推移は生産数（良品・不良の積み上げ棒）と不良率（折れ線）、故障件数（棒）と設備稼働率（折れ線）の2つの複合グラフにし、目盛りと単位を付けた。内訳は軸ごとの横棒（生産数・設備稼働率。上位10件、全件は表）。グラフは自作のSVG部品（Shared/Charts）で描き、JSのグラフライブラリは使わない——Store・ZIP・Dockerのどの配布でもオフラインの工場LANで動く必要があり、CDNに頼れず、同梱すると相互運用とライセンスの管理が増えるため。割合の色のしきい値は割合バーと共通にした（同じ値が画面によって違う色にならないように）。集計はAPIのままで、画面では数えない（7.5節）。6.1節に反映） 改訂100: 2026-09-22（7.9節を追加した。画面とAPIのメッセージを日本語・英語で切り替えられるようにする基盤として、言語の保存（ブラウザごと）・切替部品・Accept-Language によるAPIの文言の翻訳を入れた。訳のキーは日本語の原文とし、英語の訳だけを *.en.resx に持つ。今回はレイアウト・ログイン画面・認証APIの文言だけを訳し、残りの画面とAPIは docs-dev/I18nPlan.md の I18N-02〜10 で順に訳す） 改訂101: 2026-09-22（7.9節：区分値（ステータス・区分）とロールの表示名を Core の EnumLabels に集め、英語の訳を付けた（I18N-02）。画面・APIに散らばっていた同じ変換（約40か所）を取り除き、表記の揺れ（半製品／半製品・中間品）を揃えた） 改訂102: 2026-09-22（7.9節：APIが返すエラー・説明文（約250種）を英語でも返すようにした（I18N-03）。状態を含むエラーは状態名の内部値ではなく表示名で示すように改めた。保存される文字列（在庫トランザクションの備考・状態履歴の理由・監査ログ等）は訳さないことを明記した） 改訂103: 2026-09-22（7.9節：メニューと共通部品（CSV入出力・ZIP一括取込・ページ送り・検索付き選択・スキャン入力・印刷ボタン・グラフ等）の文言を英語でも出すようにした（I18N-04）。共通部品の既定の文言は部品側で訳し、呼び出し側が渡す文言は呼び出し側で訳すと定めた） 改訂104: 2026-09-22（7.9節：マスタ管理の全タブ（品目・MBOM・工順・設計変更の影響を含む）の文言を英語でも出すようにした（I18N-05）。品目の単位の既定値「個」のように保存される値は訳さない） 改訂105: 2026-09-22（7.9節：製造・実行の画面（製造指図・差立・作業指示・段取り・実績入力・工程進捗・生産性・作業時間と、作業指示書・現品票の印刷）の文言を英語でも出すようにした（I18N-06）） 改訂106: 2026-09-22（7.9節：在庫・品質の画面（受入・在庫照会・出庫・出荷・搬送・棚卸・倉庫業務・検査・不適合・品質分析・出荷判定・トレーサビリティと、出荷伝票・棚卸表・検査成績書・出荷判定書の印刷）の文言を英語でも出すようにした（I18N-07）。数量調整の理由の既定値「実棚差異」は在庫トランザクションの備考として保存されるため訳さない） 改訂107: 2026-09-22（7.9節：保全（稼働監視・保全計画・保全指示と実績・保全手順書・消耗材）・ダッシュボード（サマリ・推移・内訳）・治工具管理の画面の文言を英語でも出すようにした（I18N-08）。ダッシュボードの日次の区切りの曜日と内訳の「（直なし）」は API が表示言語で返す（直なしのキーは並び順の判定に使うので訳さない）） 改訂108: 2026-09-23（7.9節：マスタCSV・実績CSVの種別・列の表示名と説明、取込エラー、CSV・ZIPの受付エラーを英語でも返すようにした（I18N-09）。列キー（ヘッダー行）は英語のまま変えず、取込で受け付ける日本語の区分値（「製品」「合格」など）も言語によらず受け付ける） 改訂109: 2026-09-23（7.9節：残っていた画面（このアプリについて・監査ログ・パスワード変更・初期セットアップ・実績CSV取込・権限なし・ページが見つからない）の文言を英語でも出し、すべての画面を訳し終えた（I18N-10）。取りこぼしを一覧にする scripts/I18nCheck.ps1 を追加した） 改訂110: 2026-09-23（3.1節・5.2節：生産進捗の予実管理（A-30-10-01）の「予」として、製造日×品目×工程（作業区は任意）の計画数量を持つ ProductionPlan と登録API（api/production-plans）を追加した（PLAN-01）。MESは計画を立てず外から受け取る位置づけで、製造指図に紐付けず、既存の指図・実績からは参照しない。作業区なしの計画もキーの1つの値として二重登録を止める） 改訂111: 2026-09-23（3.1節：生産計画と工程ごとの出来高を製造日×品目×工程で突き合わせる予実集計API（api/production-plans/plan-actual）を追加した（PLAN-02）。実績は開始時刻の製造日で振り分けリワーク指図の産出を除く。作業区で絞るときは計画・実績とも作業区が配下にあるものだけに揃える） 改訂112: 2026-09-23（6.1節：生産計画・予実画面（計画登録タブ・予実タブ）を追加した（PLAN-03）。予実のグラフは品目・工程をまたいで数量を足さないよう1品目・1工程に絞ったときだけ出し、計画と実績は同じ単位なので左右の軸の目盛りをそろえる） 改訂113: 2026-09-23（3.8節：生産計画をマスタCSVの種別 production-plans として出力・取込できるようにした（PLAN-04）。キーは製造日・品目コード・工程コード・作業区コード（空欄も1つのキー）で上書きし、ZIPの一括入出力にも含める。参照先・数量・キーの判定を ProductionPlanPolicy に移し、単票APIとCSV取込の両方から呼ぶ。取込の権限は単票と同じ ProductionManage） 改訂114: 2026-09-23（3.8節・5.2節：同じ製造日・品目・工程で、作業区の範囲が重なる生産計画（作業区なしと作業区あり、上位の段と配下の段）を併存させないようにした。予実は作業区違いの計画を合算するため、全体の計画と内訳の計画が並ぶと二重に数えていた。兄弟の作業区どうしは併存できる。判定は ProductionPlanPolicy に置き、単票API（409）とCSV取込（既存との間・ファイル内とも行エラー）の両方から呼ぶ。既に重なって登録されている計画はそのまま残る） 改訂115: 2026-09-23（3.8節・7.2節：生産計画をマスタの一括ZIPの取込・出力から外した（改訂113で含めていた）。生産計画はマスタではなく日々増える業務データで、全期間がZIPに入り、マスタを別環境へ移すと過去の計画まで付いていったため。取込の仕組み（キーで上書き）は引き続きマスタCSVのものを使う。計画のCSV出力は全件をやめ、一覧と同じ絞り込みの api/production-plans/csv を追加した。あわせて、3か月分の実績サンプルと同じ期間の生産計画のサンプル samples/production-plans/ を追加し（scripts/New-SampleBulkActuals.ps1 が乱数を使わず生成。実績の内容は変えない）、リリースに samples-production-plans.csv として添付する。利用者向けガイド（生産管理・ロールと権限など）に生産計画・予実の操作を追記） 改訂116: 2026-09-23（3.8節：実績CSVに出荷指示 shipping-orders・出荷判定 shipment-judgments・出荷実行 shipments を追加した。サンプルの実績で出荷だけが画面操作で、製造から出荷までをCSVだけではたどれなかった。判定と出荷で取込の権限が違うため3種別に分ける。出荷判定の登録・承認を ShipmentJudgmentsController から ShipmentJudgmentService へ移し、単票APIとCSV取込の両方から呼ぶ。出荷指示は後続のCSVから指すため出荷番号の手入力を許す（SH〜 は自動採番用として拒否）。サンプル samples/actual-csv/13〜15 を追加） 改訂117: 2026-09-23（3.9節・5.1節・5.2節：MBOMの行に消費工程（BomItem.RoutingSequence。親品目の工順の工程順序）を追加した。バックフラッシュが作業指示の工程にかかわらず指図の予定材料をすべて引いていたため、複数工程の品目で工程ごとにバックフラッシュすると部材が工程数ぶん減っていた。バックフラッシュはその作業指示の工程で消費する部材だけを引き、消費する部材の無い工程では拒否する。未指定の行は最終工程で消費し、展開時に予定材料へ最終工程の工程順序を入れて固定する。工順は一括置換で行が作り直されるためIDではなく工程順序で指し、工順に無い工程順序は展開時に拒否する。MBOMのCSVに RoutingSequence 列を追加し、サンプル samples/master-csv/15_bom.csv は実績サンプルの部材投入に合わせて工程10とした） 改訂118: 2026-09-23（5.1節・5.2節：品目の標準不良率を指図の予定材料に反映するようにした。A-40-10-04（不良率などのMBOM付加情報）として入力できたが、どこにも使われていなかった。予定数量を 原単位×指図数量÷(1－親品目の標準不良率) とする。不良品も部材を消費する（バックフラッシュは良品＋不良の数で引く）ため、良品を指図数量だけ得るのに要る部材を見込む。割り切れない値は列の精度（小数6桁）で切り上げる（切り捨てると欠品側にずれる）。÷(1－率) のため標準不良率は100%を受け付けず 0〜99.99 とした（単票API・CSV）。バックフラッシュの消費量は実績（良品＋不良）基準のままで変えない） 改訂119: 2026-09-23（5.1節：MBOMの循環（A→B→…→A）を登録時に拒否するようにした。これまでは品目自身を子品目にする行だけを拒否しており、2段以上で一周する構成は単票APIでもCSVでも登録できた。今の展開は1段だけなので処理は止まらないが、作れない品目の構成になり、多段の所要量展開や逆展開を足したときに無限ループになる。判定は ProductStructurePolicy.FindBomCycle に置き、単票APIとマスタCSV取込の両方から呼ぶ。置き換える親品目自身の既存明細は判定に入れない。CSVでは取り込んだ親品目の明細をその都度判定用に置き換え、同じファイルの後の行が前の行と循環するのも捕まえる。エラーには一周する経路を品目コードで示す） 改訂120: 2026-09-23（5.1節：MBOMの代替部品グループの整合を登録時に確かめるようにした。グループの無い代替部品の行、主材料の無いグループ、主材料が2つ以上あるグループを登録できた。主材料が無いとバックフラッシュ（代替部品の行を消費しない。3.9節）がそのグループの部材を何も引かず、主材料が2つ以上だと代わりになるはずの部材を両方とも原単位ぶん引く。グループの無い代替部品はどの主材料の代わりかが決まらない。判定は ProductStructurePolicy.CheckAlternativeGroups に置き、単票APIとマスタCSV取込の両方から呼ぶ。グループ名は前後の空白を除いて比べ、その形で保存する（空白違いで別グループになるのを防ぐ）。既存のデータは直さない（次にそのMBOMを保存するときに判定される）） 改訂121: 2026-09-23（3.1節：MBOMの改訂（A-40-10-05 設計変更）の監査ログに変更前後の明細を残すようにした。これまでは items=件数 だけで、一括置換のため何を変えたか追えなかった。明細は子品目をIDではなくコードで残す（品目を無効化・改名しても読めるように）。マスタCSV取込では種別ごとの取込ログに加えて親品目ごとに同じ形のログを書く（CSVが追跡の抜け道にならないように）。監査ログは書くたびに保存するため、取込の途中では書かず、全行の検証が通って保存した後にまとめて書く） 改訂122: 2026-09-23（5.7節「指図展開時のマスタ固定」に、予定材料の標準不良率による割り増しと消費工程の固定（改訂117・118）を追記した。あわせてマスタCSV・実績CSVの列の案内（AlternativeGroup・IsAlternative・Backflush）、サンプルの説明、利用者ガイド（帳票・用語・マスタのCSV・部材投入）を改訂117〜121に合わせた） 改訂123: 2026-09-23（工程管理項目の自由記述（Routing.ControlItems）の長さの上限を、工順・作業指示・API・マスタCSVで1000文字に揃えた。工順が1000文字、展開先の作業指示が500文字だったため、501文字以上を書いた工順は PostgreSQL / SQL Server で指図の展開に失敗していた（SQLiteは長さを守らせないため表に出なかった）。上限を超える記述は工順の登録で拒否する） 改訂124: 2026-09-23（工程管理項目を工順（BOP）の工程ごとに紐付けるようにした（RoutingControlItem。I-30-20-10）。これまでは項目側の対象品目/対象工程に「または」で合致する項目を展開時に自動選択していたため、品目を指定した項目がその品目の全工程の作業指示に載り、品目と工程の組合せや、同じ工程が2回ある工順の工程ごとの条件を表せなかった。改訂48の「工順に明示的な紐付けを持たせない」方針を改め、ControlItem から対象品目・対象工程を削除した（作業手順書と同じく紐付けは工順側だけに持つ）。紐付けられるのは有効な項目だけで、紐付け中の項目は単票APIでもCSV取込でも無効化できない（MasterDeactivationPolicy）。API は RoutingStepRequest.ControlItemIds、CSV は工程管理項目から TargetProductCode・TargetProcessCode を外し、工順に ControlItemCodes（セミコロン区切り）を追加。Routing.ControlItems の自由記述は補足として残す。5.1節・5.7節に反映） 改訂125: 2026-09-23（検査基準の自動選択を「対象品目 または 対象工程に合う」から「かつで合う（空の方は問わない）」に改めた。品目Yの加熱工程の基準が品目Xの加熱工程の検査に載り、品目Xの別工程の基準も載っていた。工順（BOP）には紐付けない（基準は品質管理が品目・工程単位で策定するもの（C-10-10-02）で、受入・完成品検査は工程を持たないため）。あわせて、対象工程は工程内検査の基準だけに許し、受入・完成品・サンプル検査の基準は対象品目を必須に、工程内検査の基準は対象を少なくとも一方必須に、基準値は規格値の範囲内にした。検査項目を指定して発行する場合（API・実績CSV）も同じ条件で確かめる。判定は InspectionItemPolicy に集約し、単票APIとマスタCSV・実績CSVで共通にする。サンプルCSVの完成品検査基準から工程を外した。5.1節・5.7節に反映） 改訂126: 2026-09-23（検査指示がロットの保留を外す抜け道を塞いだ。ロットを拘束する検査指示（サンプル検査以外）は、ロットが正常か検査待ちのときだけ発行でき、再検査に限り不良ロットにも発行できる。同じロットに判定前の検査指示を重ねて発行しない。取消はロットを一律に正常へ戻していたのを、その指示が拘束する前のステータス（状態履歴の最初の拘束）へ戻すようにした。これまでは保留・不良のロットに検査指示を出して取り消すだけで正常になり、判定前の指示が2件あると先に合格した方でロットが使えるようになっていた。判定は InspectionLotPolicy。5.7節に反映） 改訂127: 2026-09-23（検査の判定を厳格にした。測定値と規格値で合否が決まる項目で、手で指定した合否が自動判定と食い違えば拒否する（これまでは手の指定が優先され、規格外の測定値でも「合格」と指定すれば合格になった）。規格外の品を使うなら不適合の特採で処置する。実績の訂正も同じ条件で合否を決める（訂正は合否を直接書き換えていた）。サンプリング数を総合判定の下限とし、その数以上のサンプルの実績がそろうまで判定できない（これまでは参考値で、1件でも判定できた）。判定は InspectionJudgmentPolicy。サンプルCSVの検査基準のサンプリング数を実績サンプルに合わせた。5.7節に反映） 改訂128: 2026-09-23（再検査（C-20-50-01）を、そのロットの直近の判定済みの検査をやり直すものとし、検査項目を引き継ぐようにした（版はいまの基準）。種別で完成品の基準を選んでいたため、受入ロットの再検査は基準が見つからず発行できなかった。判定済みの検査が無いロットには発行しない。あわせて、取消済みの作業指示への工程内検査の発行、作業指示と別品目のロットの指定、取消済みの検査の実績の訂正を拒否する。5.7節に反映） 改訂129: 2026-09-23（着手時にもスキル・資格を照合するようにした（F-20-30-01）。照合は差立（作業員割当）にしか無く、着手は差立を省略できる（小規模運用）ため、差立を省いた運用・割当者と異なる者の着手・差立後の有効期限切れのいずれでも、必要スキルを持たない者が作業できていた。照合するのは割当者ではなく実際に着手する者。判定は Api/Policies/SkillQualificationPolicy に集約し、差立と着手で同じ条件を使う。3.2節・3.6節に反映） 改訂130: 2026-09-23（保全手順書に必要スキル・資格を持たせ、保全実績の登録時に実施者と照合するようにした（MaintenanceProcedure.RequiredSkillId。F-20-30-01）。3.6節は「差立・検査・保全の各業務で照合」と書いていたが、保全・検査には必要スキルの項目自体が無かった。保全指示は手順書を版数ごと固定しないため、照合は手順書の現在値を使う。判定は差立・着手と同じ SkillQualificationPolicy。検査側は未実装のまま3.6節にそう明記した（検査基準の見直しが別ブランチで進行中のため、合流後に扱う）。5.1節・3.6節に反映） 改訂131: 2026-09-23（管理図と工程能力指数を実装した（api/quality/control-chart。C-50-10-01〜02）。3.3節は「初期は基本的な管理図表示」を実装対象とし、6.1節の品質分析画面にも管理図があったが、実装は無かった。検査実績の測定値を検査指示ごとの群にまとめ、X̄-R（群の大きさ1なら X-Rs）管理図と Cp・Cpk を返す。新規エンティティは無い。計算は Api/Services/ControlChartCalculator（係数表は JIS Z 9020-2）。品質分析画面に検査項目を選ぶ管理図の欄を追加した。3.3節・6.1節に反映） 改訂132: 2026-09-23（製造リードタイムの分布を生産性モニタリングに追加した（api/productivity/lead-time。B-60-10-05）。納期の管理が指図の納期超過フラグだけで、実績リードタイムのばらつきと異常値が見えなかった（実践的MES導入ガイド 8.3.2 の納期実績の見える化）。着手・完了は状態履歴ではなく作業の記録の時刻で決め、製造日の差で数える。新規エンティティは無い。3.2節・6.1節に反映） 改訂133: 2026-09-23（標準時間の見直し候補を生産性モニタリングに追加した（api/productivity/standard-time-review。B-60-10-05）。標準時間の予実は作業指示ごとに並ぶだけで、工順マスタを見直すきっかけにつながっていなかった（実践的MES導入ガイド 8.3.2(4)：標準時間などの業務パラメータは定期的に再設計する）。工順の工程ごとに実績の中央値をマスタの現在値と比べ、件数としきい値で候補を挙げる。マスタは書き換えない。新規エンティティは無い。3.2節・6.1節に反映） 改訂134: 2026-09-23（1.3節にエネルギー管理を［将来拡張］とすることを明記した。仕様にエネルギーの記述が無く、対象かどうかが読めなかった（実践的MES導入ガイド 3.4.2・4.4.7・7.2.2 は、MES の役割を FEMS へ製造オーダ別の分母を渡すことと位置づける）。計測・総量監視・ユーティリティ制御は FEMS／FMCS の領域として持たず、実装する場合は設備×期間の使用量をCSVで受け取り稼働区間の時間比で作業指示へ按分する形とした。機能の追加・変更は無い） 改訂135: 2026-09-23（検査項目・基準に必要スキル・資格を持たせ、検査実績の登録時に検査員と照合するようにした（InspectionItem.RequiredSkillId。F-20-30-01）。改訂130で保全を実装した際、検査の見直し（改訂125〜128）と衝突するため後回しにしていたもの。必要スキルは発行時に InspectionOrderItem へ写し（作業指示の必要スキルと同じ）、発行後にマスタを変えても発行済みの検査の照合条件は変わらない。写す値なので、CSV取込で変えると版数が上がる。判定は差立・着手・保全と同じ SkillQualificationPolicy。実績の訂正では照合しない。マスタCSVの検査項目に RequiredSkillCode 列を追加（列が無ければ現在値のまま）。3.6節・5.1節・5.4節に反映） 改訂143: 2026-09-24（3.8節：実績CSVに保全計画 maintenance-plans を追加した（CSV対応バックログで保留にしていたもの）。計画の登録を MaintenancePlansController.Create から MaintenanceOrderService.CreatePlanAsync へ移し、単票APIとCSV取込の両方から呼ぶ（API契約は変えない）。計画には番号が無いため、保全指示CSVに FromPlan 列を足し、設備と予定日が一致する未指示の計画が1件だけのときにその計画から指示を作る。サンプル samples/actual-csv/18_maintenance-plans.csv を追加し、以降のサンプルの番号を1つずつ繰り下げた（19〜30）） 改訂142: 2026-09-24（3.8節：実績CSVに不適合 nonconformances・サンプル品保管 sample-storages を追加した（CSV-07）。不適合の対応と保管サンプルが画面からしか進められなかった。検査の不合格で自動起票された不適合は、ロット番号で指す（そのロットの未完了の不適合が1件だけのときに限る）。サンプルの採取・保管の終了を SampleStoragesController から新設の SampleStorageService へ移し、単票APIとCSV取込の両方から呼ぶ（API契約は変えない。サンプル番号の手入力はCSVのみ）。サンプル samples/actual-csv/28〜29 を追加） 改訂141: 2026-09-24（3.8節：実績CSVに搬送指示 transfer-orders・ピッキング指示 picking-orders・棚卸指示 stocktakes・実棚数 stocktake-counts を追加した（CSV-06）。物流の指示系と倉庫業務進捗がサンプルで空のままだった。搬送指示の作成・実行・取消を TransferOrdersController から新設の TransferOrderService へ移し、単票APIとCSV取込の両方から呼ぶ（API契約は変えない）。ピッキング・棚卸は後続の行・ファイルから指すため番号を手入力にする（CSV-01 の手入力番号）。サンプル samples/actual-csv/24〜27 を追加） 改訂140: 2026-09-24（3.8節：実績CSVに在庫オペレーション inventory-operations を追加した（CSV-05）。在庫の移動・調整・分割・統合などが画面からしか行えなかった。9つの操作を1種別にまとめ、Operation 列で選ぶ。分割・振替（LotOperationService の派生ロット作成）は保存が2回に分かれるため自前でトランザクションを張っていたが、CSV取込の外側のトランザクションがあるときはそれに乗るようにした（入れ子のトランザクションは張れない。単票からの呼び出しは従来どおり）。サンプル samples/actual-csv/23_inventory-operations.csv を追加） 改訂139: 2026-09-24（3.8節：実績CSVに治工具の利用実績 tool-usages・治工具の引当 tool-issues・検査機の校正 calibrations を追加した（CSV-04）。治工具の寿命・引当と校正がサンプルで試せなかった。利用実績の登録を ToolUsagesController から ShopFloorReportService.AddToolUsageAsync へ、校正の記録を InspectionDevicesController から新設の InspectionDeviceService へ移し、単票APIとCSV取込の両方から呼ぶ（API契約は変えない）。利用実績は記録日時をCSVでだけ指定できる。引当には番号が無いので、1行の Issue・Return 列で払出・返却まで進める。サンプル samples/actual-csv/20〜22 を追加し、19 の治工具メンテは寿命をリセットしないようにした（リセットすると 20 の過去日時の利用実績が累計に入らないため）） 改訂138: 2026-09-24（3.8節：実績CSVに保全指示 maintenance-orders・保全実績 maintenance-records を追加した（CSV-03）。保全指示・実績は画面からしか入らず、サンプルだけでは消耗材モニタリング・保全の履歴を試せなかった。保全指示は後続の実績CSVから指すため番号を必須の手入力にし、MaintenanceOrderService.CreateAsync の手入力番号（CSV-01）を使う。計画保全を作れるロールを MaintenanceOrderService.PlannedOrderRoles に置き、単票APIとCSV取込で共有する。実績は AddRecordAsync を通すので、在庫引落し・資産管理部品の拒否・必要スキルの照合・設備の復帰は単票と同じ。サンプル samples/actual-csv/18〜19 を追加し、保全部品の受入（ロット番号指定）を 01_receiving.csv に足した） 改訂137: 2026-09-24（3.8節：保全手順書をマスタCSVの種別 maintenance-procedures として出力・取込できるようにした（CSV-02）。マスタで唯一CSVに対応しておらず、サンプルだけでは保全手順書を用意できなかった。列は手順書番号（キー）・表題・対象設備の資産番号・対象治工具コード・必要スキル・資格コード・手順ステップ・有効。更新は単票APIと同じく版数を上げる。単票APIは参照中の手順書の無効化を制限していないため、CSVでも拒否しない（保全指示は手順書を版数ごと固定せず、無効な手順書は新しい指示で選べなくなるだけ）。取込の権限は単票と同じ MaintenanceManage。全マスタの一括ZIPの最後（20番）に入る。サンプル samples/master-csv/20_maintenance-procedures.csv を追加） 改訂136: 2026-09-23（画面の目視確認で見つかった2点を直した。①製造リードタイムの異常値判定で四分位範囲を1日を下限にした（多くの指図が同じ日数だと範囲が0になり、1日長いだけの指図まで異常値に出ていた。3.2節）。②スキル照合の文面を「作業者」から「担当者」に改めた（差立・着手に加え、保全の実施者・検査員にも同じ文面が出るため。利用者ガイドの例とトラブルシューティングも合わせた）） 参考: みんなのMES（min-MES） https://min-mes.com/ / OSS: https://github.com/mihatama/open-mes-project

---

1. プロジェクト概要

1.1 目的

製造現場における生産実績・在庫・品質・設備情報を一元管理するオールインワン型MES（製造実行システム）を開発する。機能要件は**『MES/MOM導入のための標準業務一覧』（一般財団法人エンジニアリング協会）のMES対象「〇」項目**を実装対象の基準とし、オープンソースの「みんなのMES」を機能面の参考とする。バックエンドはASP.NET Core APIに一本化し、データベースはバックエンドのみが保持する単一DBとする。

MES機能のクライアントはWebブラウザ（Blazorクライアント）のみとする。本システムは AGPL-3.0 のオープンソースソフトウェアとして提供し、シート・端末単位の利用ライセンス管理（ライセンス購入・端末アクティベーション）は持たない（改訂90）。サーバーにアクセスできる端末はすべて利用できる。

1.2 対象ユーザー

• 現場作業者（作業指示確認、段取り・実績・部材投入の記録）
• 生産管理担当者（製造指図発行・承認、進捗管理、MBOM/BOPマスタ管理）
• 物流・倉庫担当者（受入、出庫・払出、出荷、棚卸）
• 品質管理担当者（検査指示・実績・判定、不適合管理、不良分析）
• 品質保証担当者（出荷判定、トレーサビリティ）
• 設備保全担当者（設備台帳、保全計画・指示・実績、治工具管理）
• システム管理者（マスタ管理、ユーザー・スキル管理、監査ログ）

1.3 機能スコープ

機能スコープは**『MES/MOM導入のための標準業務一覧』**を正とする。MES対象「〇」の業務プロセスを実装対象、「△」を将来拡張（オプション）、「×」を対象外（ERP/PLM/購買/会計など外部システムの領域）とする。〔 〕内は同一覧のDivision記号。

1. 生産管理〔A〕：製造指図の発行・承認・変更、生産進捗モニタリング、MBOM／BOP・BOE・作業区マスタ管理
2. 製造実行〔B〕：指図の工程展開・作業指示、差立（ディスパッチング）、段取り、チェックリスト、部材投入、製造実績・設備稼働・品質実績の報告、工程間搬送、工程進捗管理、リワーク・リペア
3. 品質管理〔C〕：検査基準管理、受入／工程内／製品完成品／サンプル検査（指示・実績・判定・成績書・承認）、不適合／逸脱管理、品質分析
4. 物流/在庫管理〔D〕：受入、部材倉庫・工程内・製品倉庫の在庫オペレーション、出庫・工程払出、出荷、棚卸、ロケーション管理
5. 設備保全〔E〕：設備台帳・保全手順書、稼働監視、保全計画・指示・実績、治工具管理（寿命・メンテナンス）
6. 従業員管理〔F〕：工場従業員情報、スキル・資格管理（有効期限）、資格・スキル照合、間接時間管理
7. 品質保証〔H〕：出荷判定、ロットトレーサビリティ（トレースバック／フォワード、各種履歴閲覧）
8. 共通基盤：認証・ロール管理、監査ログ、帳票・ラベル/現品票発行、ダッシュボード、バーコード/QRスキャン

HSE〔G〕はチェックリスト項目への健康衛生・安全項目の組み込み（G-20-20-02、G-30-20-03）で対応する。生産技術〔I〕はBOP/BOE情報のMES登録（I-10-20-02、I-30-20-02/13）・保全台帳整備（I-10-20-05）・工程変更反映（I-50-30-01/03）、設計〔J〕は設計変更反映時の在庫・生産状況確認（J-40-40-01/03）として各モジュールに包含する。購買・資材〔K〕・工場経理〔L〕は対象外。

エネルギー管理（HSE〔G〕の環境）は［将来拡張］とする。 電力・ガス・圧縮空気などの計測と総量の監視、ユーティリティ設備の制御は FEMS／FMCS の領域であり、本システムは持たない。MES の役割は、FEMS が持たない**「どの製造指図・品目・工程で使ったか」の分母**（設備ごとの稼働区間と、そこに紐づく作業指示・産出数。EquipmentLog.WorkOrderId）を渡すことにある。実装する場合は、設備×期間の使用量を FEMS からCSVで受け取り、同じ設備の稼働区間の時間比で作業指示へ按分して、品目別・指図別の原単位（kWh/個など）を出す形とする（OEEの按分と同じ考え方。3.5節）。計測値を直接収集する経路（センサー・PLC）は作らない。

業界固有の規制対応も対象外とする。 とくに医薬・医療機器で求められる電子記録・電子署名規制（21 CFR Part 11 / EU Annex 11）には対応しない（7.6節）。監査ログを持つことと規制に適合することは別である。

---

2. システムアーキテクチャ

バックエンド（ASP.NET Core API + DB）を中心に、MES機能クライアントはBlazor Webクライアントのみ。データアクセスはすべてAPI経由のみで、DBには直接触れない。

               ┌──────────────────────────────┐
               │ MesApp.Client.Web              │
               │ (Blazor WebAssembly)           │
               │  MES機能の唯一のクライアント      │
               │  ブラウザからアクセス            │
               └──────────────┬─────────────────┘
                              │ HTTPS / REST API
                              ▼
                 ┌─────────────────────────┐
                 │  MesApp.Api               │
                 │ (ASP.NET Core Web API)    │
                 │ 認証(JWT等)・業務ロジック   │
                 │ Webクライアントの静的配信も担う│
                 └────────────┬─────────────┘
                              ▼
                 ┌─────────────────────────┐
                 │   単一DB（バックエンドのみ保持）│
                 │  既定: SQLite／設定で変更可     │
                 │  (PostgreSQL, SQL Server 等)  │
                 └─────────────────────────┘

2.1 各コンポーネントの役割

• MesApp.Api（バックエンド）: 唯一のデータアクセス主体。認証、業務ロジック（在庫整合性チェック、実績集計など）をすべて担う。MesApp.Client.Webの静的ファイル配信も行う。DBは1つのみ保持し、クライアントからの直接アクセスは行わせない。
• MesApp.Client.Web: Blazor WebAssemblyとして実装し、ブラウザからAPIを呼び出すMES機能の唯一のクライアント。
• MesApp.Desktop: 単独PCで完結させるためのデスクトップホスト（Windows専用・MSIX配布）。MES業務機能そのものは持たず、MesAppHostでMesApp.Apiをプロセス内に起動し（ループバックアドレス・OSが選ぶ空きポート）、その画面をWebView2で表示するだけの薄いシェル。サーバーを別途立てられない小規模利用者向けの配布形態で、業務ロジックはWeb版とまったく同じものを使う（7.8節）。
• MesApp.Core: ドメインモデル・DTO・APIコントラクト（リクエスト/レスポンス型）。API・Webクライアントで共有。

2.2 認証・初期セットアップの流れ

A（ライセンス購入とエンタイトルメント同期）・B（端末アクティベーション）・D（割当解除・端末入替・トークン再発行）は改訂90で削除した（シート・端末ライセンス管理を実装しない。欠番）。C・E の記号は実装側のコメントが参照しているため振り直さない。

C. ログインとアクセス判定

1. ブラウザからログイン画面へアクセスし、MESユーザーアカウントで認証してJWTを取得する。
2. 以降のAPI呼び出しはJWT（ユーザー認証）をAPI側で検証する。端末の認証は行わない（サーバーにアクセスできる端末はすべて利用できる）。
3. 同一端末で複数のMESユーザーが利用可能（交代勤務・共有端末を想定）。

E. 初期セットアップ（初期管理者アカウント）

• 初回起動時（Userテーブルが0件）のみ初期セットアップAPI・画面が有効になり、初期管理者アカウント（ユーザーID・パスワード）を作成できる。作成完了と同時に初期セットアップAPIは無効化される。
• 無人セットアップ（Docker／zip配布）向けに、環境変数または設定ファイルによる初期管理者の自動シードもサポートする（起動時にUserが0件の場合のみ適用し、シード用資格情報は初回ログイン時にパスワード変更を強制する）。
• 初期管理者のパスワードの決め方は次の2通りとし、どちらも指定がない場合は初期管理者を作らない（値を誰も知らないアカウントを残さないため）。
  • MesAdmin:Password を設定する：無人セットアップ向け。運用者が値を知っている前提。
  • MesAdmin:GeneratePassword=true にする：デスクトップ配布（7.8節）向け。インストールごとに生成し、画面に表示する。配布物に固定のパスワードを同梱しない（全インストールで同じ値になり、リポジトリにも残るため）。生成値は保存しないので、パスワード変更が済むまでは起動のたびに作り直して表示する（利用者が控える必要はなく、控えても次回は使えない）。
  • 生成パスワードは画面から書き写す前提のため、見間違えやすい文字（l I O 0 1）を除いた英小文字・数字から16文字とし、パスワードポリシー（英小文字・数字を含む）を必ず満たすよう構成する。

---

3. 機能モジュール詳細

各機能の（ ）内は『MES/MOM導入のための標準業務一覧』の業務プロセスNoで、要件のトレーサビリティを担保する。無印はMES対象「〇」、**［将来拡張］**はMES対象「△」または実装コスト上初期リリースから外す項目。

3.1 生産管理〔A〕

• 製造指図管理：製造指図の登録・発行（A-20-10-01。ERP等外部からのCSV/API取込、または手動登録）、承認（A-20-20-01）、変更・削除（A-20-20-02）、製造現場発の突発指図登録（B-10-10-04）
• 生産進捗モニタリング：工場・ライン横断での指図単位の進捗確認（A-30-10-01）、納期遅延・トラブル発生時の状況把握（A-30-20-01）
  • 遅延の検知は①指図の納期超過（納期を過ぎて未完了の作業指示）②標準時間超過（着手済みで経過時間が予定時間をしきい値以上超過。予定＝段取り＋作業×計画数量）の2種類。通知の仕組みは持たず画面表示まで（工程進捗画面の一覧とダッシュボードの件数）
  • 標準時間が未設定の工程は超過を判定できないため対象にしない。経過時間は着手（状態履歴）からの実時間で、休憩や段取り待ちも含む
  • 生産計画（予実の「予」）：製造日×品目×工程（作業区は任意）ごとの計画数量を受け取る（api/production-plans。A-30-10-01）。MESは計画を立てない（A-10 は対象外）ので、外から来た計画の入れ物とし、実績とは品目・工程・作業区・製造日で突き合わせる。計画は製造指図に紐付けず、指図・作業指示・実績の側からは参照しない（依存は計画 → 実績の一方向）
    • キー（製造日・品目・工程・作業区）が同じ計画は二重に登録できない。作業区なしも1つの値として扱う（DBの一意索引はNULLの行を止められないため、判定はAPIで行う）。作業区の段は問わない
    • 計画数量は0以上（0は計画上の休止）。計画は改訂されるので、更新でキーを付け替えられ、削除もできる（業務の記録ではなく受け取った予定のため、無効化ではなく削除）。登録・更新・削除は監査ログに残し、更新は変更前後を持つ
    • 一覧は製造日の期間（両端を含む）・品目・工程・作業区で絞り込める。作業区に上位の段を指定したら配下へ展開する。書き込みは製造指図と同じロール（ProductionManage）
    • 工程別の予実（api/production-plans/plan-actual）：製造日×品目×工程で1行。実績は工程ごとの出来高＝生産実績の良品数で、記録の開始時刻が属する製造日で振り分け（ダッシュボードと同じ）、リワーク指図の産出は数えない（生産性と同じ規則。B-60-10-05）。期間は製造日の from〜to（省略時は当日。実績は境界時刻の半開区間で絞る）。同じキーに作業区違いの計画があれば合算する。計画だけ・実績だけの日も行にし（無い側は0）、達成率（実績÷計画×100）は計画が0なら求めない（null）。集計はAPIで行う（7.5）
    • 予実を作業区で絞るときは、実績側は作業指示に展開時点で固定した作業区で判定し、上位の段は配下へ展開する。計画・実績とも作業区が配下にあるものだけに揃える（作業区なしの計画も作業区なしの作業指示の実績も外す。片側だけが減って達成率がずれないようにする）
• 生産計画変更［将来拡張］：スケジューラーを介さないMES上での計画変更（A-10-30-02）
• MBOM管理：MBOM登録（A-40-10-01）、中間品（追加品目）登録（A-40-10-02)、内外製区分登録（A-40-10-03）、不良率・代替部品等の付加情報（A-40-10-04）、設計変更対応（A-40-10-05）
• BOP/BOE管理：工順（BOP）・設備情報（BOE）の登録・付加情報管理（A-40-20-01〜02、I-10-20-02、I-30-20-02、I-30-20-13）、工程変更対応（A-40-20-03、I-50-30-01/03）、設計変更反映時の在庫・生産状況確認（J-40-40-01/03）
  • MBOMの改訂は監査ログに変更前後の明細（子品目コード・原単位・内外製・代替部品グループ・代替部品フラグ・消費工程）を残す。単票APIでもマスタCSV取込でも同じ形で、CSVでは親品目ごとに1件書く
  • 設計変更（MBOM・工順の改訂）の影響は品目マスタ画面で確認する。進行中の指図と、部材の在庫・進行中指図の予定数量を並べる
  • 展開済みの指図には改訂が届かない（5.7節のスナップショット）。改訂後の条件で作り直すなら指図の取消と再作成が要る。未展開（未承認・承認済）の指図は展開時に改訂後の値を使う
  • 部材は現行MBOMと進行中指図のスナップショットの和集合で並べる。改訂で外したのに進行中指図がまだ必要としている部材と、その在庫が見えるようにするため
• 作業手順書（SOP）管理：手順書の登録・改訂（I-30-40-01〜02。版数管理）と工順への紐付け（I-30-20-12）。作業者は作業指示から手順を確認する（B-10-30-03）。手順書の作成自体はMESの対象外（I-30-30-01。3Dデータ・図面など形式が多様）のため、本文を置けない手順書は所在（文書番号・URL）だけの登録を許す
  • 手順書は指図展開時に作業指示へ紐付き、作業指示画面で手順を確認できる。表示は常にマスタの現在値で、計画時から改訂されていれば「改訂あり」を示す（5.7節「指図展開時のマスタ固定」の例外）

3.2 製造実行〔B〕

• 製造指図の工程展開・作業指示化：製造指図を工順（BOP）に基づき工程単位の作業指示に展開（B-10-10-01）、受領・内容確認（B-10-10-02〜03）、産出ロットNo採番（B-10-10-05。自動採番：品目コード＋日付＋連番、または手入力。シリアルNo単位は将来拡張）
• 差立（ディスパッチング）：作業指示への作業員割当（B-10-20-01。スキル・資格照合 F-20-30-01 を伴う。照合は着手時にも着手する者に対して行う）、工程・設備割当（B-10-20-02。新しく割り当てられる設備は状態が稼働可能のものだけ。割当済みの設備のまま着手順だけを変える差立は通す）、着手順割当（B-10-20-03）
• 作業指示の配布・確認：作業指示の承認・配布（B-10-30-01〜02）、指示内容（構成部品・手順等）の閲覧（B-10-30-03）、作業指示書・現品票等の帳票出力（B-10-30-04）
• 前段取り・セッティング：始業前点検・自主保全記録（B-20-10-01〜02）、部材引当・受領・構成確認（B-20-20-01、B-20-20-03〜04）、治工具引当・払出指示・受領確認（B-20-30-01〜03。引当→払出（受領確認）→返却を ToolIssue で追う。無効・廃棄・メンテ中・寿命到達・他の作業指示に引当中の治工具は引き当てられず、判定は引当時と払出時の両方で行う）、製造条件/設備プログラム展開・設備作業前点検（B-20-40-01〜02）、段取り指示確認〜着手〜完了の記録（B-20-50-01〜05。開始/終了時刻・実施者・異常報告）
• チェックリスト：共通事項・工程/品目別制約・作業資格のチェック実施記録（B-30-10-01〜03）。チェックリストマスタにHSEの健康衛生・安全項目を組み込み可能（G-20-20-02、G-30-20-03）
• 部材投入：投入部材の数量・ロットNo・投入時刻の記録（B-30-20-01）。投入部材はMBOM照合を行い、作業指示の品目のMBOMに定義されていない品目は投入不可とする（誤投入防止。3.9節「部材投入の照合」）。秤量機等との自動連携（B-30-20-02）は［将来拡張］とし、初期はCSV取込で代替
• 製造実施：製造着手（B-30-30-01。差立を省略しても着手できるが、必要スキルのある作業指示は着手する者のスキル・資格を照合する）、作業時間記録（B-30-30-02、F-30-20-01）、製造条件データの記録（B-30-30-04。手入力/CSV取込。設備自動収集は［将来拡張］）、作業完了報告（B-30-30-06）
• 製造実績報告：出来高（良品数・不良数、および不良数の内訳としての廃棄数・再作業待ち数・不良理由別の内訳）報告（B-40-10-01）、半製品・製品の在庫計上（B-40-10-02）、進捗・時間報告（B-40-10-03〜04）、完了時の製造データ・トラブル履歴・部材欠品報告（B-40-10-05〜07）、部材投入実績の事後報告（B-40-10-08）、バックフラッシュ（MBOMと完了数量から部材消費を自動算出し在庫引落し。B-40-10-09）、製造完了承認（B-40-10-10）
• 設備稼働報告：稼働時間・停止時間・停止原因の記録（B-40-20-01〜02。手入力。自動収集は［将来拡張］）
• 品質実績報告：逸脱/品質不具合の記録（B-40-30-01）、不良原因の選択式記録＋詳細（文章・写真）（B-40-30-02）、不良部材報告（B-40-30-03）、不良品在庫の計上・引落し（B-40-30-04）
• 後段取り：指示確認〜着手〜実行〜完了の記録（B-40-40-01〜05）
• 工程間搬送：半製品の搬送・移動指示と移動実行（B-50-10-01〜02）、製品の梱包・包装（B-30-30-05、B-50-20-02）、完成品の倉庫・出荷場への入庫（B-50-20-03）
• 工程進捗管理：工程毎の完了状況把握（B-60-10-01）、製造トラブルの発生報告・対応履歴記録（B-60-10-02〜04。状態は発生→対応中→完了の前進のみとし、完了からは理由を対応履歴に残したときだけ対応中へ戻せる。発生へは戻さない）、生産性モニタリング（歩留まり・直行率・標準時間予実・製造リードタイム・標準時間の見直し候補。B-60-10-05）
  • 直行率＝良品数÷(良品数＋不良数)。歩留まり＝(良品数＋リワーク良品数)÷(良品数＋不良数)。リワーク指図の産出は分母に入れない（同じ材料を二度数えるため）、救済された良品として歩留まりの分子にだけ足す
  • 標準時間の予実：予定＝標準段取り時間＋標準作業時間×計画数量（指図展開時に固定した工順の値。5.7節）。実績＝直接作業時間＋段取り実績時間（いずれも終了済みの記録のみ）。作業時間を記録していない作業指示は実績0分として並ぶ
  • 製造リードタイム（api/productivity/lead-time）：取消以外の作業指示がすべて完了・承認済みの製造指図ごとに、最初の作業（段取り・生産実績の開始）から最後の生産実績の終了までを製造日の差で数える（同じ製造日なら0日）。状態履歴の時刻は使わない——実績CSVで後から取り込むと状態の変わった時刻が取込の時刻になり、実際の作業日から外れるため。期間は完了の製造日。リワーク指図は含めない（歩留まりと同じ扱い）。平均だけではばらつきと異常値が見えないため、日数ごとの度数分布（うち納期遅れの件数）・中央値・90%点と、第3四分位＋1.5×四分位範囲を超える異常値（4件以上のとき）を返す。四分位範囲は1日を下限にする（日数は整数なので、多くの指図が同じ日数だと範囲が0になり、1日長いだけの指図まで異常値になるため）。納期に対する遅れは完了の製造日−納期
  • 標準時間の見直し候補（api/productivity/standard-time-review）：工順の工程ごとに、期間内の作業指示の1個あたり実作業時間（直接作業時間÷(良品数＋不良数)）と1回あたり段取り時間の中央値を、工順マスタの現在値と比べる（作業指示のスナップショットではない。見直す対象そのものであり、改訂後もまだずれているかを見たいため）。作業時間を記録していない作業指示は0分として混ぜず件数から外す。件数が既定3件以上でずれが既定20%以上なら候補にする（標準0分で実績があるものも候補）。マスタは書き換えない——標準を実績に寄せるか、作業を改めるかは業務の判断。工順の工程順序と工程が作業指示と一致しないもの（工順改訂で並びが変わったもの）は数えない。リワーク指図は含めない
• リワーク・リペア：リワーク指図の作成・実施・実績記録（B-70-10-01〜03。製造指図の指図区分で表現）
• 外注管理［将来拡張］：工程外注・庫内外注の管理（B-70-20-01〜02。初期は工程マスタの内外製区分と実績記録まで）
• 製造履歴訂正：出来高・品質・稼働時間等の変更・削除（B-70-30-01。権限制御＋監査ログによる改ざん防止付き）。訂正前の値はProductionRecordCorrectionに業務履歴として残し、トレース画面の履歴から参照できるようにする（5.7節「実績訂正の扱い」）

3.3 品質管理〔C〕

• 検査基準管理：検査規格値・基準値・検査方法（サンプリング数含む）のマスタ管理（C-10-10-01）、工程・品目単位の検査項目・基準の策定・更新（C-10-10-02〜03）
• 検査（受入／工程内／製品完成品／サンプル共通）：検査進捗・ステータス一覧（C-20-10-01、C-20-20-01、C-20-30-01、C-20-40-01）、検査指示（依頼）発行（C-20-10-02 ほか）、検査実績登録（C-20-10-03 ほか。受入はサプライヤー検査データの取込も可）、規格値との照合による検査結果判定（C-20-10-04 ほか）、検査成績書の発行（C-20-10-05 ほか）、検査指示・実績の承認（C-20-10-06 ほか）、サンプル取得・識別ラベル貼付（C-20-40-03）
• その他検査：再検査（C-20-50-01）、検査機の校正管理・有効期限確認（C-20-50-03。検査機マスタで最終校正日・次回校正期限・校正周期を管理し、校正の実施を履歴に残す。検査実績の登録時に期限を判定し、期限切れ・無効化された機器は使えない。期限未設定の機器は判定しない）、滞留在庫の有効期限延長判定検査（C-20-50-04）、検査実績の訂正・削除（C-20-50-07。訂正前の記録をInspectionResultCorrectionへ残し、検査成績書にも訂正理由・訂正者を出力する。権限制御付き）、先行評価品検査・委託先検査データ取込（C-20-50-02、C-20-50-05）は［将来拡張］
• 不適合／不具合管理：逸脱・品質不具合の一覧・管理（C-30-10-01）、逸脱理由分析（C-30-10-02）、不適合対応指示（リワーク/保留/廃棄等。C-30-20-01）、対応実行記録（C-30-20-02）、逸脱承認／特別採用（C-30-20-03）
• 品質分析：品質異常検知（C-40-10-01）、品質記録参照（C-40-10-02）、不良項目別・工程別・直別・期間別の集計分析（C-40-10-03。直別は3.9節の製造日が夜勤を前提にしているため、昼勤と夜勤の不良率を比べられるようにする）、不適合・逸脱発生状況のモニタリング（C-40-10-05）
• 不良項目別分析：不良理由マスタ（C-10）に基づく不良理由別の不良数・構成比・累積構成比の集計（C-40-10-01）。数量の多い順に並べパレート図として読めるようにし、改善対象の選定に使う
• 品質傾向管理：管理図等による傾向分析に基づく検査判定（SPC。C-50-10-01〜02。初期は基本的な管理図表示、本格的SPC・予兆管理（C-50-10-03）は［将来拡張］）
  • 管理図（api/quality/control-chart）：検査項目ごとに、検査実績の測定値を検査指示ごとの群にまとめて X̄-R 管理図を描く。群の大きさが1なら個別値－移動範囲（X-Rs）管理図にする。群の大きさは最も多い大きさに揃え、違う大きさの群は除外して件数を示す（係数の違う群を混ぜると管理限界が意味を失うため）。大きさ11以上（X̄-s 管理図）は扱わず点だけを示す。取消した検査の測定値は使わない。期間は測定日時が属する製造日
  • 異常の判定は管理限界の外と、中心線の同じ側に9点以上続く並び（JIS Z 9020-2 のルール2）の2つだけ。群が2つ未満なら管理限界を出さない
  • 工程能力指数（Cp・Cpk）は**群内のばらつき（R̄/d2）**から推定する。全測定値の標準偏差を使うと群間の変動（工程の異常）までばらつきに入り、管理状態でない工程の Cpk が良く見えるため。規格値は検査指示が発行時に写した値（5.7節）で、期間内に改訂があれば最新の群の規格で求めてその旨を示す。規格が片側だけなら Cp は出さず Cpk を片側で求める
• グレード管理：検査結果により出荷先・品目が変わる製品の管理（C-60-10-01。ロットのグレード属性で表現）

3.4 物流/在庫管理〔D〕

• 受入：受入進捗確認（D-10-10-01）、注文情報を元にした受入登録・在庫計上（D-10-10-02。受入ロット採番含む）、ラベル/現品票印刷（D-10-10-03）、受入の変更・取消（D-10-10-04）、返品対応（D-10-10-05）
• 在庫オペレーション（部材倉庫／工程内／製品倉庫の共通機能）：在庫照会（品目別・ロケーション別・ロット別。D-10-30-01、D-30-10-01、D-40-40-01）、在庫移動（D-10-30-02、D-30-10-02、D-40-40-02）、推奨ロケーション指示（D-10-30-03、D-40-40-03。受入・完成品入庫の画面で候補と理由を出す。選ぶのは人で、強制しない）、数量調整（実在庫との差異訂正。D-10-30-04、D-30-10-05、D-40-40-04）、ロット分割・統合（D-10-30-05、D-30-10-06、D-40-40-05）、品目振替・ロット振替（D-10-30-06〜07、D-30-10-07〜08、D-40-40-06）、在庫ステータス変更（保留・廃棄・不良品・検査待ち等。D-10-30-08、D-30-10-09、D-40-40-07）、滞留在庫の期限管理・アラート（D-10-30-09、D-30-10-10、D-40-40-08）
  • 推奨の根拠は3段階で上から順に強い。①品目マスタの既定ロケーション ②同じ品目の在庫が既にあるロケーション（数量の多い順） ③品目区分に対応するエリア（製品→製品倉庫、それ以外→部材倉庫）
  • 同じロケーションが複数の理由に当たるときは最も強い理由だけを残す。理由は画面に出す（根拠を伏せた推奨は従われない）
• 出庫・工程払出：出庫指示/要求（D-20-10-01）、ピッキング指示（ロケーション・先入れ先出しロット指定。D-20-10-02）、ピッキング実行（バーコード照合。D-20-20-01）、配膳/出庫/払出（D-20-20-02）、払出戻し（D-20-20-03）、工程間在庫搬送（D-30-10-04）。カンバン方式（B-20-20-05、D-20-20-04）は［将来拡張］
• 製品入庫・出荷：完成品の入庫（D-40-10-01）、出荷指示確認（D-40-20-01）、出荷ピッキング・梱包/キッティング・積み込み指示（D-40-20-02〜04）、出荷実行（ピッキング・梱包・パレタイズ・積み込み。D-40-30-01〜04）、出荷完了報告（D-40-30-05）、出荷関連伝票発行（D-40-30-07）。EDI/ASN連携（D-40-20-07、D-40-30-06）は初期はCSV出力で代替し、本格連携は［将来拡張］
• 棚卸：棚卸指示作成（D-50-10-01）、実棚数登録（D-50-10-02）、差異一覧・分析（D-50-10-03）、差異調整（D-50-10-04）、棚卸確定（D-50-10-05）
• その他：棚番号・ロケーション管理（D-50-20-01）、在庫廃棄（D-50-30-01）、帳票・ラベル/現品票発行（D-50-30-05〜06）、倉庫業務進捗管理（D-50-30-07）、サンプル品保管管理（D-40-50-01）。
  • 倉庫業務進捗は指示（出庫ピッキング・出荷・在庫移動・棚卸）の指示件数・完了件数・未完了件数と、未完了のうち最も古いものの経過日数を製造日基準で返す。受入は指示を持たないため対象にしない。取消は分母にも完了にも数えない
  • サンプル品は採取時に在庫から抜く（保管棚へ移り出荷・投入には使えない。在庫に残すと引当・先入れ先出しの対象になる）。保管の終了は払出か廃棄かを明示させ、期限前の処分も禁止しない（期限前だったかは監査ログに残す） AGV/AMR連携（D-50-20-02）・リサイクル管理（D-50-30-02）・VMI/外部倉庫（D-50-30-03〜04）は［将来拡張］

3.5 設備保全〔E〕

• 設備台帳管理：設備台帳の作成・更新（E-10-10-01〜02。保全タイプ（カレンダ/時間/回数ベース等）・閾値・保全部品の設定を含む。I-10-20-05）、保全手順書の作成・管理（E-10-20-01〜02）
• 設備稼働監視：稼働情報の収集（E-20-10-01。初期は手入力/CSV、センサー自動収集は［将来拡張］）、設備/ライン毎の稼働・停止実績モニタリング（E-20-10-03）。稼働サマリは製造日で期間を絞れる（稼働の開始時刻が属する製造日で振り分ける。省略時は全期間）、消耗材の使用状況モニタリング（E-20-10-04。期間は製造日基準。保全実績の開始時刻が属する製造日で振り分ける）
• 保全履歴分析：保全履歴一覧・詳細（いつ・誰が・どう保全したか）の確認（E-20-30-01〜02）、設備パフォーマンス（OEE等）確認（E-20-30-03）、保全台帳・手順書の見直し（E-20-30-04〜06）
  • OEE＝時間稼働率×性能稼働率×良品率。時間稼働率＝稼働時間÷負荷時間（負荷時間＝記録済み総時間。計画休止の区分は持たないため除外しない）。性能稼働率＝(標準作業時間×産出数)÷紐づいた稼働時間。良品率＝良品数÷産出数
  • 性能稼働率・良品率は作業指示に紐づけて記録した稼働（EquipmentLog.WorkOrderId）からしか導けない。紐付けのない稼働は対象外とし、カバー率（紐づいた稼働÷全稼働）を併記して指標の信頼度を示す。差立の割当設備（WorkOrder.AssignedEquipmentId）では補完しない——割当と実際に動いた設備は一致するとは限らないため
  • 算出できない指標は0ではなくnull（画面は「-」）。産出0として扱うと記録漏れが設備の悪い評価に化ける
  • 同じ設備の同じ時間帯に複数の作業指示が紐づく場合（まとめ処理。3.9節）は重なりを按分する。1つの作業指示が複数設備で動いた場合は産出を稼働時間の比で配分する
  • 性能稼働率は100%を超えることがある（標準作業時間より速い）。上限で丸めない
• 保全計画・指示：中長期・年次保全計画の作成・変更（E-30-10-01〜03）、保全指示の作成・発行（E-30-20-01）、生産計画への影響連携（E-30-20-02）、計画外の保全依頼（E-30-30-01）。保全指示を発行済みの計画は取り消せない（先に保全指示を取り消す。指示の取消で計画は計画中へ戻る）
• 保全実施：保全手順確認（E-40-10-01）、作業準備・実施（E-40-20-01〜02）、保全実績登録（消費部材・交換部品・対応人員等。E-40-30-01。設備が保全中なら稼働可能へ戻す。保全中への切替は保全担当が設備台帳で行う）。消費部材はロットを指定して在庫から引き落とす（引落しは在庫サービス経由。5.7節）
• 消耗材モニタリング：期間内に保全で消費した部材を品目別に集計し、現在庫と並べて補充の要否を判断する（E-20-10-04）
• 治工具管理：治工具マスタと在庫管理（E-60-10-01/03/04。在庫オペレーションと共通）、寿命管理（作業指示との紐付けによる利用実績記録（E-60-20-01）、閾値到達前の交換・廃棄通知（E-60-20-02）、寿命分析（E-60-20-03。期間内の使用ペースから寿命到達の見込み日を出す。使用実績のあった日で割り、閾値未設定・使用なし・到達済みは見込みを出さない））、治工具メンテナンスの指示・実施・実績（E-60-30-01〜03）
• 予兆保全（E-20-20-01）は［将来拡張］

3.6 従業員管理〔F〕

• 工場従業員情報管理：従業員データの登録・変更・削除（F-10-10-01〜02。MESユーザーアカウントと統合管理）。所属（部署・課）・作業場所（作業区）・所属する直を持つ
• 勤務シフト（直）の定義：昼勤・夜勤などの時間帯を定義する（F-10-10-01）。3.9節の製造日（業務日付）が夜勤を前提にしているのに対し、「その実績がどの直か」を表す。誰がいつどの直に入るかの勤務計画は持たない（勤怠管理 F-30-10-01〜02 は本システムの対象外。ガイドでも△）
• スキル・資格管理：スキル・資格の定義（F-20-10-01）、従業員への資格・スキル登録（使用可能設備・製造可能品・有効期限等。F-20-10-02〜03）、有効期限接近の警告（F-20-10-04）、有効期間の管理（F-20-10-05）
• 資格・スキル照合：差立・検査・保全の各業務で担当者に必要スキル・資格があるかを照合（F-20-30-01、B-30-10-03）。製造では差立（割当者）と着手（着手する者）の両方で、保全では保全手順書の必要スキルを保全実績の登録者（実施者）に対して、検査では検査項目・基準の必要スキル（発行時点のスナップショット）を検査実績の登録者（検査員）に対して照合する（SkillQualificationPolicy）。検査員の割当は持たないため、検査の照合は実績の登録時だけ。実績の訂正（責任者の操作）では照合しない
• 間接時間管理：段取り・部材準備・設備メンテ等、製造に直接紐づかない作業時間の記録（F-30-20-02）
• システム管理者を失わない：有効なシステム管理者が0人になる変更は行えない（無効化・システム管理者ロールの剥奪のいずれも）。管理者がいなくなるとユーザー管理も権限付与もできず、初期セットアップAPIはUserが0件のときしか動かない（2.2節E）ため、DBを直接操作する以外に復旧手段がなくなる。単独PC配布（7.8節）では管理者が1人だけの運用が普通で、現実に起こりうる
  • 判定は1か所（Api/Policies/LastAdminPolicy）に置き、ユーザー管理画面（PUT api/users/{id}）とマスタCSV取込（users）の双方から呼ぶ
  • CSV取込は行ごとではなく全行を適用したあとに確認する。「Aを降格してからBを昇格する」という引き継ぎを、行の順序で誤って弾かないため。条件を満たさなければ取込全体をロールバックする
• 勤怠管理（F-30-10-01〜02）は対象外（人事系システムの領域）

3.7 品質保証〔H〕

• 出荷判定：出荷判定一覧・検査結果・工程記録の確認（H-10-10-01）、出荷判定（可・保留・特採。H-10-10-02）、判定承認（H-10-10-03）、出荷判定書・製造/検査履歴書類の発行（H-10-10-04）
• トレーサビリティ：ロット番号によるトレースバック（問題品目の製造元特定。H-30-10-01）・トレースフォワード（使用先特定。H-30-10-02）、製造履歴・設備稼働履歴・検査履歴の閲覧（H-30-10-03〜05）、不具合対象品への対応連携（保留（在庫ステータス変更）・再検査（検査指示）・リワーク（リワーク指図）。H-30-20-01〜03）
• 追跡の連鎖：部材ロット → 部材投入/連動出庫（作業指示に紐付く）→ 作業指示 → 生産実績 → 産出ロット。逆方向も同様。シリアル番号（個体）単位の追跡は［将来拡張］

3.8 共通基盤

• ユーザー管理・ロールベースアクセス制御（API側で一元管理。従業員管理（3.6）と統合）
• ログイン認証（ASP.NET Core Identity + JWT、API側に集約）
• ダッシュボード（当日実績サマリ、稼働率、不良率、進捗などのKPI表示。B-60-10-05、C-40-10-05、E-20-10-03の各モニタリングの基盤）
  • 「当日」は製造日（3.9節）。境界時刻は設定値でクライアントは知らないため、現在の製造日は api/business-date から受け取る。暦日で代用すると境界をまたぐ時間帯に夜勤の実績が前日・当日へずれる
  • 数値は既存の集計API（api/quality/summary・api/equipment-logs/summary・api/manufacturing-orders/progress）を製造日で絞って取得する。一覧を全件取って画面で数えない（7.5節）
  • KPIの取得に失敗しても進捗一覧は表示する（ダッシュボードが丸ごと開けなくならないようにする）
  • 期間別・軸別の集計は api/dashboard/trend（日・週・月の推移。週は月曜始まり、区切りは製造日。データの無い区切りも行として返す。上限400区切り）と api/dashboard/breakdown（工程・品目・直・ライン・作業区・設備の内訳）で行う。絞り込みは工程・品目・作業区（配下へ展開）
  • 生産実績も稼働ログも開始時刻が属する製造日で振り分ける（品質分析・生産性・OEEも同じ）。稼働は工程・品目では絞れない（作業指示との紐付けが任意のため）。生産実績は設備では分けられない（設備が作業指示に固定されないため）。求められない指標は0でなくnull（「実績なし」と区別する）。ライン軸は最下段の作業区を祖先のライン段へまとめる
• 帳票・ラベル発行基盤（作業指示書・現品票・検査成績書・出荷伝票・出荷判定書・棚卸表等の印刷/PDF出力。B-10-30-04、C-20-10-05、D-10-10-03、D-50-30-05〜06、H-10-10-04）
• 監査ログ（実績訂正・検査訂正・マスタ変更等の変更履歴。7.6節）
• マスタのCSV一括入出力：各マスタ（品目／MBOM／工順／工程／作業区／設備／設備の保全部品／治工具／ロケーション／検査項目・基準／検査機・測定器／工程管理項目／チェックリスト／作業手順書／勤務シフト／スキル・資格／ユーザー／ユーザーのスキル資格／保全手順書）のCSV出力・テンプレート出力・一括取込。保全手順書（maintenance-procedures）は単票APIと同じく保全の権限（MaintenanceManage）で取り込み、取込欄は保全管理画面の保全手順書タブに置く（一括ZIPでは最後の番号。対象設備・治工具・必要スキルをコードで参照するため）。取込はコード（自然キー）によるupsertで、他マスタはコードで参照する。文字コードはUTF-8/Shift_JISを自動判別し、出力はExcel互換（UTF-8 BOM＋CRLF）。行単位で検証し、1行でもエラーがあれば全件ロールバックして行番号付きのエラー一覧を返す。反映せず検証のみ実行するモードを持つ。参照されている状態のマスタを無効化できないという制約は、単票APIと同じ判定をCSV取込にも通す（工順から参照中の作業手順書、在籍中の従業員が所属する直など）。片方にしか書かないとCSVから迂回できてしまうため、判定はポリシーへ集約する。なおマスタの無効化は各マスタ画面から、再有効化はCSV取込の IsActive 列から行う（全マスタ共通。画面に再有効化の導線は持たせていない）
  • 生産計画（production-plans）は取込の仕組みだけをこれに乗せる。生産計画はマスタではなく日付を持つ業務データだが、改訂のたびに同じ計画を上書きしたいので、常に新規登録する実績CSVではなくキーで上書きするマスタCSVの取込を使う（A-30-10-01）。キーは BusinessDate, ProductCode, ProcessCode, WorkCenterCode(任意) で、同じキーなら計画数量（と Note 列があれば備考）を上書きし、無ければ追加する。WorkCenterCode が空の行も1つのキーとして扱い、同じ製造日・品目・工程の作業区なしの計画を上書きする（二重に追加しない）。計画数量は0以上。ファイル内で同じキーが複数行にあればエラー。取り込んだ後に同じ製造日・品目・工程で作業区の範囲が重なる行（既存の計画との間・ファイル内とも）もエラー。数量とキーの判定は単票API（api/production-plans）と共通の ProductionPlanPolicy に置く。取込の権限は単票の登録と同じ ProductionManage（種別の WriteRoles）。取り込み直しても変わらない行は更新日時を動かさない。マスタではないので一括ZIPの取込・出力には含めない（日々増えるデータを、マスタの移行や全件出力に巻き込まないため。ZIPに入っていれば取込を拒む）。取込は生産計画画面の計画登録タブから1ファイルずつ行い、出力は一覧と同じ絞り込み（製造日の期間・品目・工程・作業区）の api/production-plans/csv で行う
• 実績のCSV一括取込：試験・移行・教育用に、実績（取引データ）をCSVで一括登録する（api/actuals/csv/{kind}。テンプレート出力と取込。対応種別は受入 receiving・製造指図 manufacturing-orders・段取り実績 setup-records・チェックリスト実施 checklist-records・部材投入 consumptions・生産実績 production-records・製造条件データ data-records・検査 inspections・作業時間 work-time-records・製造トラブル報告 trouble-reports・設備稼働記録 equipment-logs・出荷指示 shipping-orders・出荷判定 shipment-judgments・出荷実行 shipments・保全計画 maintenance-plans・保全指示 maintenance-orders・保全実績 maintenance-records・治工具の利用実績 tool-usages・治工具の引当 tool-issues・検査機の校正 calibrations・在庫オペレーション inventory-operations・搬送指示 transfer-orders・ピッキング指示 picking-orders・棚卸指示 stocktakes・実棚数 stocktake-counts・不適合 nonconformances・サンプル品保管 sample-storages）。マスタCSVと同じく1行でもエラーがあれば全件ロールバックし、行番号付きのエラー一覧を返し、検証のみのモードを持つ。マスタCSVとの違いは次のとおり。①取込は常に新規登録で既存の実績を更新しない（実績の訂正は理由付きの訂正機能で行う）。②行ごとに単票APIと同じ業務サービスを通す（受入は ReceivingService、製造指図は ManufacturingOrderService、作業指示の実行記録は WorkOrderExecutionService、検査は InspectionService、作業時間・トラブル報告は ShopFloorReportService、出荷指示・出荷実行は ShippingService、出荷判定は ShipmentJudgmentService、保全指示・保全実績は MaintenanceOrderService、治工具の利用実績は ShopFloorReportService、治工具の引当は ToolIssueService、校正は InspectionDeviceService、在庫オペレーションは LotOperationService、搬送は TransferOrderService、ピッキングは PickingService、棚卸は StocktakeService、不適合は NonconformanceService、サンプル品保管は SampleStorageService）——実績は在庫・ロット・状態履歴を連鎖して動かすため、行をエンティティへ直接写すと判定や監査ログが迂回される。③取込の権限は種別ごとに単票APIと同じロールグループ（受入は在庫・物流オペレーション）。④行は保存しながら進めるので、後の行は前の行の結果（登録済みロット番号の重複判定など）を前提にでき、検証のみも実際に登録してからロールバックする。他のマスタ・実績はIDではなくコード・番号で参照する。⑤作業指示は「指図番号＋工程順序」で指す。自動採番の指図番号は取込前に分からないため、製造指図CSVに限り指図番号の手入力を許す（自動採番の形式 MO〜 と重なる番号は、採番テーブルの連番と後で衝突するため拒否）。製造指図CSVは1行で登録・承認・工程展開まで進められるが、承認は省略できない（展開は承認済みの指図だけ）。⑥実行記録の記録者は取込を実行したユーザーとし、作業者を指定する列は持たない（他人名義の実績を作れると、記録者に意味が無くなる）。投入ロットはロット番号で、日時はオフセットの無い値を工場の時刻として読む。生産実績の直は開始日時で決まる。⑦検査CSVは InspectionKey が同じ行を1件の検査指示にまとめる。キーはファイルの中だけの名前でDBに残さない（検査指示番号は自動採番のままにし、後続のCSVから検査指示を指す必要も無いため）。まとまりに含まれる検査項目がその指示の対象になり、Judge=true なら実績に続けて総合判定する（ロットの状態反映・不合格時の不適合起票も単票APIと同じ）。⑧出荷は指示・判定・実行の3種別に分ける（判定は品質保証、指示と実行は物流の権限で、1種別にまとめると③を満たせない）。出荷指示CSVは出荷番号が同じ行を1件の指示（1行＝1品目の明細。同じ品目を2行書けない）にまとめ、後続の判定・実行CSVから番号で指せるよう出荷番号を必須の手入力とする（⑤と同じ理由で自動採番の形式 SH〜 と重なる番号は拒否）。出荷判定CSVは1行＝1件の判定で、Approve=true なら続けて承認する。出荷実行CSVは出荷番号が同じ行を1回の出荷にまとめ、承認済みの判定（可・特採）とロットの使用可否は単票APIと同じく出荷実行の処理で判定する（判定の無い指示を含むファイルは全件取り消し）。⑨保全は指示と実績の2種別に分ける。保全指示CSVは1行＝1件の指示で、保全実績CSVから指せるよう保全指示番号を必須の手入力とする（⑤と同じ理由で MT〜 は拒否）。単票APIと同じく突発依頼は誰でも、計画保全の指示は保全担当者（MaintenanceOrderService.PlannedOrderRoles）だけが登録でき、CSVでは行ごとに取り込んだユーザーのロールで判定する。保全計画CSVは1行＝1件の計画で常に新規登録する（設備×年度×区分でも同じ区分の計画が複数ありうるため自然なキーが無く、マスタCSVのように上書きしない。権限は単票と同じ MaintenanceManage）。計画には番号が無いので、保全指示CSVの FromPlan=true の行は設備と予定日が一致する未指示の計画が1件だけのときにその計画から作り、計画を指示済みにする（0件・2件以上は行エラー。同じ設備の計画は予定日を分ける）。保全実績CSVは保全指示番号が同じ行を1件の実績にまとめ、1行に消費部材を1つ（ロット番号・払出元・数量）書ける。実施者は取り込んだユーザーで、手順書の必要スキルもこのユーザーと照合する。登録で指示は完了するので、1件の指示に実績は1件だけ。資産管理部品を書いた行・在庫不足は単票と同じく拒否する。⑩番号の無い記録は1行で完結させる。治工具の引当CSVは1行＝1件の引当で、Issue・Return の列で払出・返却まで進め、後のファイルからは指さない（引当・払出の両方で ToolIssuePolicy が使用中・メンテ中・寿命到達を拒否する）。治工具の利用実績CSVは記録日時（RecordedAt）を指定でき、空欄なら取り込んだ時刻とする（寿命の累計はメンテで寿命をリセットした時刻より後の記録だけを数えるので、リセットより前の日時の記録は累計に入らない）。検査機の校正CSVは1行＝1回の校正で、単票と同じく検査機の最終校正日・次回期限（省略時は校正周期から）を更新する。⑪在庫オペレーションは1種別にまとめ、Operation 列で操作を選ぶ（移動・数量調整・状態変更・分割・統合・振替・廃棄・返品・払出戻し。操作ごとに種別を分けると取込画面のパネルが9枚増えるため）。1行＝1操作で、単票と同じ LotOperationService の同名メソッドを呼ぶ。操作ごとの必須列はコードで検査する（数量調整の理由は単票でも必須）。分割・振替は新ロット番号（NewLotNumber）を指定できるので、同じファイルの後の行から新しいロットを指せる。ロット系譜・状態履歴・監査ログは単票と同じに残る。⑫物流の指示：搬送指示CSVは番号が無いので1行＝1件で、Execute の列で移動の実行まで進める。ピッキング指示CSVはピッキング番号（必須の手入力。PK〜 は拒否）が同じ行を1件の指示にまとめ、1行＝1明細（品目と数量）。ロット・ロケーションは単票と同じく先入れ先出し（有効期限優先。期限切れは引き当てない）で自動引当し、Execute で払出まで進める。棚卸指示CSVは棚卸番号（必須の手入力。ST〜 は拒否）と対象ロケーションで作り、作成時点の在庫が明細になる。実棚数CSVは棚卸番号と明細のロット番号＋ロケーションで指し、Finalize で確定（差異の棚卸調整）まで進める。⑬不適合CSVは1行＝1件の不適合で、不適合番号（未登録なら新規起票。NC〜 は拒否）か、番号を空欄にしてロット番号で指し、Action（対応指示）→ActionRecord（対応記録）→Approve（承認）の列があればその順に進める。検査の不合格で自動起票された不適合は番号が取り込むまで分からないため、ロット番号で指せるのはそのロットの未完了（クローズ前）の不適合が1件だけのときに限る（0件・2件以上は行エラー。どれを進めるかを推測で決めない）。起票と対応記録は誰でも、対応指示と承認は単票と同じく品質管理の担当者だけ（行ごとに取り込んだユーザーのロールで判定）。⑭サンプル品保管CSVは1行＝1件で、未登録のサンプル番号（SP〜 は拒否）なら採取（在庫から抜く）、Close（払出・廃棄）を書けば保管を終える。登録済みの番号の行は保管の終了だけを行う
• CSVのZIP一括取込・一括出力：複数のCSVをまとめたZIPを1回で取り込む（マスタは POST api/masters/csv/bundle、実績は POST api/actuals/csv/bundle）。ファイル名の昇順に取り込み、種別はファイル名の最初の「_」より後ろで決める（01_work-centers.csv → work-centers。同じ種別を番号違いで複数入れてよい）。CSV以外のファイル（README.md等）は無視する。全ファイルを1つのトランザクションで処理し、どれか1ファイルでもエラーがあれば全ファイルを取り消す（後のファイルが前のファイルの登録結果を参照するのでファイルごとに保存はするが、途中まで反映された状態が残るとどこから取り込み直せばよいか分からなくなるため）。エラーが出たファイルより後は処理せず、未処理として名前を返す。マスタと実績が混ざったZIPは受け付けない（取込の権限も対象画面も異なるため、別のZIPにする）。取込にはZIPに含まれる全種別の取込権限が要り、1種別でも権限が無ければ何も取り込まない。種別が分からないファイルは取り込む前に拒否する。ZIP爆弾対策として、CSVの数・1ファイルと合計の展開後サイズに上限を設け、読みながら数えて超えたら打ち切る。一括出力（GET api/masters/csv/bundle）は全マスタを取り込む順の番号付きファイル名でZIPにし、そのまま一括取込に使える（参照を絞っている種別は権限が無ければ含めない。ユーザーはパスワードを出力しないため、新しいDBへ移すときはユーザー系のファイルに初期パスワードを書き足す）。実績の一括出力は持たない
• バーコード/QRスキャン共通コンポーネント（ブラウザのカメラAPI or USB HIDリーダー入力）

3.9 横断的な業務ルール

• 製造日（業務日付）の定義：日次集計・日報・ダッシュボードの「当日」は暦日ではなく業務日付で扱う。日付境界は既定で午前6時とし、設定で変更可能とする（夜勤の日跨ぎ実績が同一製造日に集計されるようにするため。実績の集計はすべてこの境界を用いる）
  • 基準は工場のタイムゾーン（BusinessDay:TimeZone。IANA名 Asia/Tokyo でもWindows名 Tokyo Standard Time でも指定できる）。未設定ならサーバーのローカルタイムを使う。サーバー運用でタイムゾーンがUTCの環境（コンテナ等）に置く場合は必ず設定する。設定しないと境界時刻が現場とずれ（日本なら9時間）、日次集計・日報・ロット番号の日付がまとめてずれる。解決できないタイムゾーン名は起動を止めず、警告を出してローカルタイムに落とす（綴り違いだけでシステムが上がらなくなるのを避けるため）
  • 境界時刻（BusinessDay:BoundaryHour）は0〜23の整数。範囲外・数値でない値は起動を止めず、警告を出して既定の6時に落とす（タイムゾーンと同じ扱い。サービスの生成は遅延のため、例外にすると「起動は成功して最初のリクエストで全画面500」という形になり原因にたどり着けない）
  • 設定値はプロセス起動時に一度だけ読む。境界時刻・タイムゾーンを変えたらアプリを再起動する。なお変更後の見え方は一様ではない——集計（品質分析・稼働サマリ等）は記録時刻から都度計算するため過去分まで遡って動くが、記録時に固定した値（ロットの製造日・採番の日付・実績の直）は動かない。境界の変更は運用の区切りで行う
  • 製造日の範囲（開始・終了）はその日のUTCオフセットで求める。「現在の」オフセットを使い回すと、夏時間のある地域で日付をまたぐ集計が1時間ずれる
• 製造品の識別方式：識別方式にはシリアル管理（個体ごと）・ロット管理（まとめて1つ）・バッチ管理（炉・洗浄機などで同時に処理する単位）があるが、本システムはロット管理を唯一の識別単位とする
  • シリアル管理は［将来拡張］。トレーサビリティの連鎖（5.7節）をロットからシリアルへ置き換える必要があり、ロット単位の実績・在庫・検査のすべてに波及する
  • バッチ管理は対象外とする。ロットの統合（LotGenealogy）では代替できない：統合は複数ロットを物理的に混ぜて1つにする操作だが、バッチは各ロットの同一性を保ったまま同時に処理するもので、処理後もロットは分かれたままだからである
  • まとめ処理を行った事実は、作業指示に紐づく設備稼働履歴（EquipmentLog）で「同一設備の同一稼働区間に複数の作業指示が紐づく」形として残る。これで足りない業務（バッチNo.を一次識別子として採番し、バッチ単位で検査・判定する運用）が出てきた時点で改めて設計する
• 工順の方針：製造指図（ManufacturingOrder＝品目×数量）を工順（BOP）に基づき工程ごとの作業指示（WorkOrder＝品目×工程）に展開する。初期リリースでは工程間の順序強制（前工程完了チェック）は行わず、着手順は差立で管理する
• 承認の方針：製造指図承認・作業指示配布承認・製造完了承認・検査承認・出荷判定承認は、初期リリースでは単段階承認（承認権限ロールによる承認操作＋監査ログ）とし、多段階ワークフローは将来拡張とする
• ロットの使用可否：部材投入（B-30-20）・FEFO自動引当（D-20-10-02、バックフラッシュ B-40-10-09）・出荷実行（D-40-30）は、いずれも次の同一条件を満たすロットのみを対象とする。判定は1か所（Api/Policies/LotUsabilityPolicy）に集約し、経路ごとに条件を持たない
  • 在庫ステータスが正常であること（保留・検査待ち・不良・廃棄予定は不可）。特採は不適合の特採承認時にステータスを正常へ戻すことで表現するため、使用可否側に特採の例外分岐は設けない（5.7節）
  • 業務日付時点で有効期限内であること（期限なしのロットは対象に含む）。期限切れロットの使用は、期限延長判定検査（C-20-50-04。［将来拡張］）が実装されるまで一律不可とする
  • 出荷はこれに加えて、当該出荷指示を対象とする**承認済みの出荷判定（可／特採）**を必要とする（H-10-10）。判定の承認後にロットが保留・不良へ変わった場合は出荷できない
• 部材投入の照合：手動の部材投入（B-30-20-01）は、投入する品目が作業指示の品目のMBOM（BomItem）に定義されていることを照合し、定義外の品目は投入不可とする。判定はApi/Policies/MaterialIssuePolicyに置く
  • MBOMが未登録の品目には照合の基準がないため、部材を投入できない（MBOMの整備を促す。バックフラッシュも同じ理由で不可）
  • 代替材料はMBOMの代替部品グループへ登録することで表現する。同一グループ内で主材料でない行には代替部品フラグを立て、その行の部材を投入するときは代替理由の入力を必須とする（誰がどの理由で代替を認めたかを実績に残すため。A-40-10-04）。主材料の投入は理由不要
  • 代替理由は投入実績（MaterialConsumption）へ代替フラグとともに保存し、監査ログにも記録する。代替そのものへの承認フロー（別の承認者による事前承認）は初期リリースでは行わない［将来拡張］
  • バックフラッシュ（B-40-10-09）はMBOMから投入部材を導くため、この照合は元から満たしている。ただし代替部品の行はバックフラッシュで消費しない（主材料の代わりに使う部材なので、主材料と両方を原単位ぶん引くと二重に減る。また代替の投入には理由が要るが、バックフラッシュは理由を受け取らない）。代替部品を使った場合は手動の部材投入で理由とともに記録する
  • バックフラッシュは、その作業指示の工程で消費する部材だけを引く。MBOMの行に消費工程（親品目の工順の工程順序）を持たせ、未指定の行は最終工程で消費する。消費工程は展開時に予定材料へ固定し、未指定の行はその時点の最終工程に解決して入れる。工順に無い工程順序を指すMBOMの品目は指図を展開できない（MBOMと工順は別々に改訂でき、どちらを先に登録してもよいため、登録時ではなく展開時に照合する）。消費する部材の無い工程でバックフラッシュを指定したときは拒否する（黙って何も引かないと、引いたつもりの在庫がずれる）
• 採番：指図番号・ロット番号等（MOyyyyMMdd-0001、品目コード-yyyyMMdd-001）は、採番テーブル（NumberSequence）のプレフィックス1行を更新してから読むことで払い出す。既存番号の最大値+1では、同時に採番したリクエストが同じ番号を得て一意制約違反になるため
  • 採番列が無い場合（採番テーブル導入前のデータ）は、既存番号の最大値の次から始める
  • 採番列ができたあとに、同じ形式の番号を手入力で登録すると衝突しうる（採番側はその番号を知らない）。衝突は409で返るため、操作をやり直せば次の番号で成立する。供給者のロット番号など、自動採番と別形式の手入力は影響を受けない
• 書き込みの原子性：1つの業務操作で複数回の保存に分かれる処理（採番済みIDを確定してから関連レコードを作る受入・ロット分割・ロット振替・検査指示発行）は、明示的なトランザクションでまとめる。途中で失敗したときに「在庫のないロット」「検査待ちにならない対象ロット」のような中途半端な状態を残さないため。監査ログ（7.6節）も同じトランザクションに含める
• 競合時の応答：在庫の楽観的同時実行制御（5.3節）による更新競合と、採番（指図番号・ロット番号等）の同時発行による一意制約違反は、障害ではなく通常運用で起こりうる競合として扱い、409 Conflict＋日本語のProblemDetailsで返す。利用者には再読込のうえ再実行を促す。変換は1か所（Api/MesAppExceptionFilter）に集約し、コントローラごとに例外処理を持たない

---

4. DBプロバイダー切替の設計（バックエンドのみ）

DBはバックエンド（MesApp.Api）のみが保持し、既定はSQLiteとする。EF CoreのDbContextをプロバイダー非依存に設計し、appsettings.jsonでプロバイダーと接続文字列を切り替えられるようにする。クライアント側はDB設定を一切持たない。

{
  "Database": {
    "Provider": "Sqlite",   // "Sqlite" | "PostgreSql" | "SqlServer"
    "ConnectionString": "Data Source=mesapp.db"
  }
}

• 接続文字列のData Sourceが相対パスのときは、書き込み可能なユーザーデータディレクトリ（既定%LOCALAPPDATA%\ParallelFactoryMES、環境変数MESAPP_DATA_DIRで変更可）を基準に絶対パス化する（MesAppDataDirectory）。実行ファイルの隣に作るとMSIX配布時にインストール先が読み取り専用で書き込めないため。JWT署名鍵（Jwt:SigningKeyFile）も同じ規則で解決する。絶対パス指定はそのまま使う。
• MesApp.Infrastructure内でプロバイダーごとのUseSqlite / UseNpgsql / UseSqlServerを設定値に応じて切り替える（DependencyInjection.UseProvider。設定できる名前はDatabaseProviders）。
• マイグレーションはプロバイダーごとに作成が必要（EF Coreの制約）。SQLiteはMesApp.Infrastructure/Migrations、PostgreSQLはMesApp.Migrations.PostgreSql、SQL ServerはMesApp.Migrations.SqlServerに置き、起動時のMigrateAsync()は設定中のプロバイダーの分を適用する。スキーマを変えるときは3プロバイダーすべてで同じ名前で追加する。追加はscripts/Migrations.ps1 -Add <名前>で3つまとめて行い、最後にDatabaseProviderTestsで3つともモデルに追いついていることを確かめる（作り忘れもこのテストが落とす）。マイグレーションには生SQL（データの修正・移行）を書かない（3方言で書き分けることになるため。既存データの手当ては起動時の処理やサービス側にC#で書く）。
• プロバイダー間でスキーマを1つのモデルから作るための調整（SQLiteのスキーマは変えない）：
  • PostgreSQL：timestamptzはオフセット0の値しか書けないため、DateTimeOffsetは書き込み時にUTCへ直す。読み出した値はUTCになる（同じ時点を指すので比較・表示には影響しない）。
  • SQL Server：削除の連鎖が同じ表へ複数経路で届く形・循環を許さないため、SET NULLの外部キーはDB側では何もせず、読み込み済みの子だけEFがnullにする（ClientSetNull）。SET NULLの親（利用者・設備・作業指示・ロット等）はアプリから物理削除しないため実運用上の差はない。
  • SQLite以外：精度未指定のdecimalはdecimal(18,6)とする（SQL Serverの既定decimal(18,2)では測定値・数量の小数3桁目以降が切り捨てられるため）。読み出した値は末尾ゼロを落とす（1.500000→1.5。CSV・APIの出力をSQLiteとそろえる）。
  • 文字列比較：SQL Serverの既定照合順序は大文字・小文字を区別しない（コードABCとabcが重複扱いになる、検索も区別しない）。SQLite・PostgreSQLは区別する。照合順序は変えず、この差を仕様とする。
• ［将来拡張］ 既存のSQLiteデータをPostgreSQL/SQL Serverへ移すツール。実DB（PostgreSQL/SQL Server）に対する自動テストの常時実行。
• SQLite利用時の同時アクセス対策：ASP.NET Coreは並行リクエストを処理するため、SQLiteでも書き込み競合は発生し得る。WALモードを有効化し、busy timeoutを設定し、書き込み競合時（SQLITE_BUSY）のリトライを実装する。数十端末規模まではこの構成で運用可能とするが、高負荷が想定される場合はPostgreSQL等への切替を推奨する旨をドキュメントに明記する。
• 在庫数量等の同時更新対策（プロバイダー非依存・アプリレイヤ）：InventoryStockなど同時更新が起こり得るエンティティにはEF Coreの**楽観的同時実行制御（同時実行トークン／RowVersion）**を設定し、競合検出時は再読込・再計算のうえリトライする。マイナス在庫の防止判定は更新トランザクション内で行い、同時実績入力による在庫の二重引落し・引落し漏れを防ぐ。

---

5. データモデル（主要エンティティ）

5.1 マスタ系

エンティティ	主な項目
User（ユーザー/工場従業員）	ユーザーID、氏名、ロール、パスワードハッシュ、作業場所（作業区）、所属（部署・課）、所属する直、在籍状態（F-10-10）
Shift（勤務シフト/直）	シフトコード、名称、開始時刻、終了時刻（開始時刻以下なら翌日にまたぐ夜勤）、状態（F-10-10-01）。3.9節の製造日が夜勤を前提にしているのに対し「その実績がどの直か」を表す
SkillMaster（スキル・資格マスタ）	コード、名称、種別（スキル/資格）、有効期限管理要否（F-20-10-01）
UserSkill（従業員スキル・資格）	ユーザーID、スキル/資格ID、取得日、有効期限、状態（F-20-10-02〜05）
Product（品目マスタ）	品目コード、品目名、単位、規格、品目区分（製品/半製品・中間品/部材）、標準不良率（0〜99.99%。指図の予定材料を割り増す。A-40-10-04）、既定ロケーション（推奨ロケーション指示の第一候補。D-10-30-03）
BomItem（MBOM明細）	親品目ID、子品目ID（部材）、必要数量（親1単位あたり）、内外製区分、代替部品グループ、代替部品フラグ（同一グループ内の主材料でない行。A-40-10）、消費工程（工順の工程順序。未指定なら最終工程。B-40-10-09）。品目自身を子品目にする行と、明細をたどって親品目へ戻る循環は登録できない（単票API・CSVで同じ判定。ProductStructurePolicy.FindBomCycle）。代替部品グループは主材料（代替部品フラグの無い行）をちょうど1つ持ち、代替部品フラグの行はグループを必須とする（CheckAlternativeGroups。グループ名は前後の空白を除いて保存・比較）
Process（工程マスタ）	工程コード、工程名、工程区分（内製/外注）
Routing（工順/BOP）	品目ID、工程順序、工程ID、標準作業時間（1個あたり）、標準段取り時間（1回あたり）、必要スキルID、候補設備・治工具、作業区、**工程管理項目（紐付け）**と補足（自由記述）、チェックリストID、作業手順書ID（A-40-20、I-30-20） 標準時間の予実（3.2節 B-60-10-05）は 段取り時間＋作業時間×数量 で予定を出す
RoutingEquipment（工順の候補設備）	工順ID、設備ID（同一工順で一意）。同じ工程を複数の装置で実行できる場合に列挙し、差立ではこの中から1台を選ぶ（B-10-20-02）
RoutingControlItem（工順の工程管理項目）	工順ID、工程管理項目ID（同一工順で一意）。その工程で記録する製造条件を指す。指図展開時にこの紐付けどおり作業指示へ指示値を写す（I-30-20-10、B-30-30-04）
WorkCenter（作業区／資源階層）	作業区コード、名称、段（工場/ライン/エリア/作業区）、上位の資源、有効フラグ。工場・ライン・エリア・作業区を1つの自己参照ツリーで持ち、資源構成全体（BOR）を表す。最下段の作業区が作業の管理単位（I-10-20-02）
Equipment（設備台帳/BOE）	資産番号、設備名、設置場所（作業区）、状態（稼働可能/停止中/保全中/廃棄・除却。差立は稼働可能のみ）、保全タイプ（カレンダ/時間/回数ベース）、保全閾値、保全部品（EquipmentPart）（E-10-10、I-10-20）。MaintenanceParts（自由記述の保全部品）とSite（自由記述の設置場所）は作業区を整備するまでの旧項目として残すが、設置場所の正は作業区参照とする
EquipmentPart（設備の保全部品）	設備ID、部品の品目ID（同一設備で一意）、管理区分（資産管理部品/消耗品）、1回あたり数量、備考。自由記述では消耗材の使用状況（E-20-10-04）を集計できないため品目マスタを参照する（E-10-10-01）
Tool（治工具マスタ）	治工具コード、名称、種別（型/切削工具/検査工具等）、寿命閾値（使用回数/時間）、状態（使用可能/使用中/メンテナンス中/廃棄。使用中は引当（ToolIssue）から決まり、マスタ編集・CSV取込では付けも外しもできない。引当中の治工具は使用可能にできず、メンテナンス中・廃棄への変更はできる）（E-60）
Location（ロケーション）	ロケーションコード、倉庫/エリア区分（部材倉庫/工程内/製品倉庫/出荷場）、所属する作業区、棚番（D-50-20-01）
ControlItem（工程管理項目）	工程管理項目コード、名称、単位、指示値、許容下限/上限、版数、有効フラグ。対象品目・対象工程は持たず、工順（BOP）の工程から紐付ける（RoutingControlItem）。温度・回転数など製造時に記録すべき条件の定義（B-30-30-04）。検査項目と同じ形にしているのは、「指示値と実績値」の関係が「検査パラメータと検査結果」と同じ構造で、判定の考え方も揃うため
InspectionItem（検査項目・基準）	検査項目コード、対象品目/工程、検査種別（受入/工程内/完成品/サンプル）、規格値（上限/下限/基準値）、検査方法、サンプリング数、必要スキルID（任意。検査実績の登録者と照合。F-20-30-01）、版数（C-10-10）。対象品目/工程は両方を「かつ」で組み合わせ、空の方は問わない（5.7節「検査基準の対象」）
InspectionDevice（検査機・測定器）	検査機コード、名称、製造番号、設置場所、最終校正日、次回校正期限、校正周期（日）、備考、状態（C-20-50-03）。校正期限切れ・無効化された機器は検査実績に使えない
InspectionDeviceCalibration（校正実施記録）	検査機ID、校正日、次回期限、結果・所見、実施者（C-20-50-03）。現在値の上書きだけでは「いつ誰がどの結果で校正したか」が残らないため履歴に残す
Checklist（チェックリストマスタ）	チェックリストコード、名称、適用区分（共通/工程/品目/段取り/保全/HSE）、項目一覧（B-30-10、G-20/G-30）
WorkProcedure（作業手順書/SOP）	手順書番号、表題、手順ステップ、手順書の所在（文書番号・URL）、版数（I-30-40-01〜02、B-10-30-03）。対象品目・対象工程は持たず、工順（BOP）側から紐付ける（I-30-20-12）
DefectReason（不良理由マスタ）	不良理由コード、不良理由名、区分（材質・部材/加工・作業/設備/人的要因/その他）、有効フラグ。粒度は「現場が迷わず選べて、集計にも使える」範囲で定義する（C-40-10-01）
MaintenanceProcedure（保全手順書）	手順書番号、対象設備/治工具、手順ステップ、版数（E-10-20）、必要スキルID（任意。保全実績の登録時に実施者と照合する。F-20-30-01）

5.2 指図・実績系

エンティティ	主な項目
ProductionPlan（生産計画）	製造日、品目ID、工程ID、作業区ID（任意）、計画数量（0以上）、備考。一意キーは製造日・品目・工程・作業区（作業区なしの重複はAPIで止める）。同じ製造日・品目・工程で作業区の範囲が重なる計画（作業区なしと作業区あり、上位の段と配下の段）は併存させない（予実で二重に数えるため。兄弟の作業区は可）。既存の指図・実績からは参照しない（A-30-10-01）
ManufacturingOrder（製造指図）	指図番号、品目ID、数量、納期、指図区分（通常/リワーク/突発）、状態（未承認/承認済/展開済/完了/取消）、承認者、元指図ID（リワーク時）（A-20、B-70-10）
ManufacturingOrderMaterial（指図の予定材料）	指図ID、部材品目ID、原単位（親1単位あたり）、予定数量（＝原単位×指図数量÷(1－親品目の標準不良率)。小数6桁で切り上げ）、代替部品グループ、消費工程（未指定のMBOM行は展開時の最終工程に解決。本項目の追加前に展開した指図は空で、最終工程として扱う）。展開時にMBOMから固定し、部材投入の照合とバックフラッシュの基準にする（A-40-10、B-30-20）
WorkOrderControlItem（作業指示の工程管理項目）	作業指示ID、工程管理項目ID、展開時点のスナップショット（項目コード・名称・単位・版数・指示値・許容下限/上限）。実績の逸脱判定と画面表示はこれを使い、マスタの現在値を参照しない（B-30-30-04）
WorkOrderStatusHistory（作業指示の状態履歴）	作業指示ID、変更前状態、変更後状態、契機（差立/着手/実績入力/承認/指図取消）、備考、変更者、変更日時。配布・着手・完了・承認・取消の遷移を業務履歴として残す（B-10、B-30-30、B-40-10-10）
WorkOrder（作業指示）	指示番号、製造指図ID、品目ID、工程ID、計画数、着手順、割当作業者ID、割当設備ID、作業区（展開時の工順スナップショット）、作業手順書IDと展開時点の版数、状態（未配布/配布済/着手/完了/承認済）（B-10）
SetupRecord（段取り実績）	作業指示ID、区分（前段取り/後段取り）、開始/終了時刻、実施者、異常報告（B-20-50、B-40-40）
ChecklistRecord（チェックリスト実施記録）	チェックリストID、対象（作業指示/設備）、実施者、実施日時、項目別結果（B-30-10）
MaterialConsumption（部材投入実績）	作業指示ID、部材品目ID、投入ロットID、数量、投入日時、記録方式（手動/バックフラッシュ）、代替フラグ・代替理由（A-40-10-04）（B-30-20、B-40-10-08〜09）
ProductionRecord（生産実績）	作業指示ID、作業者、良品数、不良数、廃棄数・再作業待ち数（不良数の内訳）、開始/終了時刻、産出ロットID、承認状態（B-30-30、B-40-10）、直（記録時に開始時刻から引いて固定）
ProductionDefect（不良明細）	生産実績ID、不良理由ID、数量、備考。不良数を理由別に分解した内訳で、合計は不良数を超えられない（残りは理由未分類）（B-40-10-01、C-40-10-01）
ProductionRecordCorrection（生産実績の訂正履歴）	生産実績ID、作業指示ID、訂正前（良品数・不良数・廃棄数・再作業待ち数）、訂正後（同左）、訂正理由、訂正者、訂正日時。訂正のたびに1レコード追加（B-70-30-01）
ProductionDataRecord（製造条件データ）	作業指示ID、対応する指示（WorkOrderControlItemID）、項目（温度・回転数等）、表示用の値、判定に使う数値、逸脱フラグ（true=逸脱／false=範囲内／null=判定していない）、記録日時（B-30-30-04、B-40-10-05）
WorkTimeRecord（作業時間記録）	作業者ID、区分（直接/間接（段取り・部材準備・設備メンテ等））、関連作業指示ID、開始/終了時刻（B-30-30-02、F-30-20）
TroubleReport（製造トラブル報告）	発生日時、区分（QCDS）、対象（作業指示/設備）、内容、対応履歴、状態（B-40-10-06、B-60-10-02〜04）
TransferOrder（搬送・移動指示）	対象ロットID、数量、移動元/先ロケーション、状態（指示/完了）（B-50-10）

5.3 在庫・物流系

エンティティ	主な項目
Lot（ロット）	ロット番号（一意）、品目ID、初期数量、由来区分（生産/受入）、生成元作業指示ID（生産ロットのみ）、製造日/受入日、有効期限、在庫ステータス（正常/保留/検査待ち/不良/廃棄予定）、グレード、親ロットID（分割・振替の直接の由来。表示用の簡易参照であり、追跡の正はLotGenealogy）（D-10-30、C-60-10-01）
LotGenealogy（ロット系譜）	由来元ロットID、由来先ロットID、関係区分（分割/統合/振替）、数量、実施者、発生日時。統合のように親が複数になる関係も表現でき、トレーサビリティ（H-30-10）はこの関係を辿る（D-10-30-05〜07）
LotStatusHistory（ロット状態履歴）	ロットID、変更前ステータス、変更後ステータス、契機（在庫操作/検査/不適合/受入）、理由、関連検査指示ID、関連不適合ID、変更者、変更日時。保留・解除の判断を後から説明するために遷移を残す（H-30-10-04）
InventoryStock（在庫）	品目ID、ロケーションID、ロットID、現在数量、RowVersion（楽観的同時実行制御）
InventoryTransaction（在庫トランザクション）	品目ID、数量、区分（受入/入庫/出庫/払出/払出戻し/移動/調整/廃棄/返品/振替/分割/統合/棚卸調整）、日時、関連ロットID、関連作業指示ID（生産連動出庫時）、移動元/先ロケーション、実施者
PickingOrder（出庫・ピッキング指示）	指示番号、区分（工程払出/出荷）、品目・ロット・数量明細（ロケーション・先入れ先出しロット指定）、払出先（作業指示ID/出荷指示ID）、状態（D-20、D-40-20）
ShippingOrder（出荷指示）	出荷番号、出荷先、品目・数量明細、出荷予定日、状態（指示/ピッキング/梱包/積込/完了）、出荷判定参照（D-40-20〜30）
Stocktake（棚卸）	棚卸番号、対象ロケーション、実施日、状態（指示/実施中/確定）。明細：品目・ロット・理論数量・実棚数量・差異・調整済フラグ（D-50-10）
SampleStorage（サンプル品保管）	サンプル番号、品目、採取元ロット、検査指示（任意）、数量、保管場所、採取日（業務日付）、保管期限、状態（保管中/払出済/廃棄済）、保管終了日（D-40-50-01）。採取時に在庫から抜くため、在庫には載らない

5.4 品質系

エンティティ	主な項目
InspectionOrder（検査指示）	検査指示番号、検査種別（受入/工程内/完成品/サンプル/再検査）、対象（ロットID/作業指示ID）、検査項目セット、依頼者、状態（指示/実施中/判定済/承認済）（C-20）
InspectionOrderItem（検査指示の対象項目）	検査指示ID、検査項目ID（参照）、発行時点の基準のスナップショット（検査項目コード・名称・版数・規格値上限/下限・基準値・検査方法・サンプリング数・必要スキル）。自動判定・検査員のスキル照合・画面表示・検査成績書はこのスナップショットを使い、マスタは新規指示の作成時にのみ参照する（C-20、C-10-10-03）
InspectionResult（検査実績）	検査指示ID、検査項目ID、測定値、判定（合格/不合格）、検査者、検査日時、承認者、使用した検査機ID（任意。C-20-50-03。校正期限切れの機器は登録時に弾くため、残るのは当時有効だった機器に限られる）（C-20）
InspectionResultCorrection（検査実績の訂正履歴）	検査実績ID、検査指示ID、訂正前（測定値・記録・判定）、訂正後（測定値・記録・判定）、訂正理由、訂正者、訂正日時。訂正のたびに1レコード追加（C-20-50-07）
NonconformanceReport（不適合・逸脱）	発生元（生産実績/検査/受入）、対象ロットID、逸脱・不具合内容、原因区分＋詳細（文章・写真添付）、対応指示（リワーク/保留/廃棄/特採）、対応実績、承認者（特採時）、状態（B-40-30、C-30）
ShipmentJudgment（出荷判定）	対象（ロットID/出荷指示ID）、判定（可/保留/特採）、判定者、承認者、判定日、判定書番号（H-10-10）

5.5 設備保全系

エンティティ	主な項目
EquipmentLog（設備稼働履歴）	設備ID、対象作業指示ID（任意）、ステータス（稼働/停止/段取り/故障/アイドル）、開始/終了時刻、停止原因、備考（B-40-20、E-20-10）
MaintenancePlan（保全計画）	対象設備ID、保全種別（定期/計画外）、計画年度、予定日、周期、状態（E-30-10）
MaintenanceOrder（保全指示）	指示番号、対象（設備ID/治工具ID）、保全計画ID、手順書ID、予定日、依頼区分（計画/突発依頼）、状態（E-30-20〜30、E-60-30）
MaintenanceRecord（保全実績）	保全指示ID、実施者、開始/終了時刻、消費部材・交換部品（自由記述の補足）、結果、備考（E-40-30、E-60-30-03）
MaintenanceRecordPart（保全実績の消費部材）	保全実績ID、品目ID、ロットID、ロケーションID、数量、備考（E-40-30-01。在庫から引き落とした明細。消耗材モニタリング E-20-10-04 の集計元）
ToolIssue（治工具の引当・払出）	治工具ID、作業指示ID、状態（引当済/払出済/返却済/取消）、引当日時・引当者、払出日時・受領者、返却日時・返却者、備考（B-20-30）。現物の所在を追う。寿命の累計は ToolUsage 側
ToolUsage（治工具利用実績）	治工具ID、作業指示ID、使用回数/時間、記録日時（E-60-20。寿命検知の根拠データ）

5.6 （欠番）

改訂90で削除（LicenseEntitlement・Device・SeatAssignment・ActivationCode。シート・端末ライセンス管理を実装しない）。

5.7 モデル間の主要な関係

• 指図の階層：ManufacturingOrder（品目×数量）→ 工順（Routing）に基づく展開 → WorkOrder（品目×工程）。リワーク指図はManufacturingOrder.指図区分＋元指図IDで表現する。
• トレーサビリティの連鎖：産出ロット（ProductionRecord.産出ロットID）⇔ 作業指示 ⇔ 部材投入（MaterialConsumption.投入ロットID。バックフラッシュ・手動とも同一エンティティに記録）⇔ 部材ロット、のリレーションでロット単位の前方・後方追跡を実現する。ロットの分割・統合・振替はLotGenealogy（由来元⇔由来先の1関係＝1レコード）で系譜を保持し、統合のように由来元が複数ある場合も前方・後方の双方向で辿れるようにする。
• 検査の対象：InspectionOrderは受入検査ではロット、工程内検査では作業指示（＋ロット）、完成品検査では産出ロットを対象とする。判定結果はロットの在庫ステータス（検査待ち→正常/不良）へ反映する。
  • 検査とロットの在庫ステータス：ロットを拘束する検査指示（サンプル検査以外）は、ロットが正常か検査待ちのときだけ発行できる。再検査（C-20-50-01）に限り不良のロットにも発行できる。保留・廃棄予定のロットに発行できると、発行→取消や発行→合格で保留が外れてしまう（保留の解除は不適合の処置で行う）
  • 同じロットに判定前の検査指示を重ねて発行しない。先に合格した方でロットが正常になり、もう一方の判定を待たずに使えてしまうため
  • 再検査（C-20-50-01）は、そのロットの直近の判定済みの検査をやり直すものとし、検査項目をその検査から引き継ぐ（版はいまの基準）。種別で基準を選ぶと、受入ロットの再検査に完成品の基準を探して発行できなかった。判定済みの検査が無いロットには発行しない
  • 工程内検査は取消済みの作業指示には発行しない。対象ロットを指定するなら作業指示の品目のロットに限る。取消済みの検査の実績は訂正しない
  • 取消は、ロットをその指示が拘束する前のステータスへ戻す（状態履歴の最初の拘束から引く）。一律に正常へ戻すと、不良ロットの再検査を取り消しただけで不良が解除される。判定は Api/Policies/InspectionLotPolicy
• 出来高の数量区分：生産実績は 良品数・不良数 に加えて、不良数の内訳として廃棄数・再作業待ち数を持つ（廃棄数＋再作業待ち数 ≦ 不良数。残りは判定待ち・保留中の数量）。内訳としたのは、総生産数（＝良品数＋不良数）を基準にするバックフラッシュ（B-40-10-09）と不良率（C-40-10-03）の意味を変えないため
  • 在庫計上（B-40-10-02）の対象は従来どおり良品数のみで、内訳は在庫に影響しない
  • 再作業待ち数はリワーク指図（B-70-10）との数量突合に使う
  • 不良理由別の内訳はProductionDefect（生産実績×不良理由×数量）で持つ。合計は不良数を超えられず、残りは理由未分類として扱う（現場がその場で理由を決められない場合を無理に標準へ押し込まないため）
• 保全部品は品目マスタで持つ：交換部品を自由記述で持つと、消耗材の使用状況（E-20-10-04）を集計できず、保全実績から在庫を引き落とすこともできない。設備の保全部品は品目マスタを参照する（EquipmentPart）
  • 資産管理部品（金型など）と消耗品（Oリングなど）を区分で分ける。前者は個体・寿命を追い、後者は交換のたびに在庫から引き落とす、と管理形態が違うため
  • 登録は設備ごとの一括置換とする（工順・MBOMと同じ方式。行単位の追加だと、CSVから削除したつもりの部品が残る）
  • Equipment.MaintenanceParts（自由記述）は移行元として残す
• 保全で消費した部材は在庫から引き落とす：保全実績にロット単位の消費明細（MaintenanceRecordPart）を持ち、登録と同時に在庫を減らす。実物は減っているのに在庫が減らない状態を作らないため
  • 引落しは既存の InventoryService 経由で行い、在庫履歴（InventoryTransaction）に区分保全消費で残す。引落し経路を別に作ると、在庫と履歴の整合を守る場所が二重になる
  • 使える現品かの判定（在庫ステータス・有効期限）は部材投入・出荷と同じ LotUsabilityPolicy を通す。保全部材だけ期限切れロットを使えるようにする理由がない
  • 資産管理部品として登録済みの品目は引落しの対象外とする（400）。個体と寿命で管理する対象で、数量在庫を減らすと在庫と実物が合わなくなるため
  • 保全部品として未登録の品目は通す。突発保全で想定外の部材を使うことはあり、記録できない方が在庫がずれる（製造の部材投入が予定材料と照合して弾くのとは前提が違う）
  • 明細が1行でも失敗すれば実績ごと登録しない（1操作＝1トランザクション。在庫だけ減って実績が残らない状態を作らない）
• 工程で使える設備は工順の候補で絞る：同じ工程を複数の装置で実行できる工場があるため、工順は設備を1台に固定せず候補を列挙する（RoutingEquipment）。差立（B-10-20-02）ではその中から1台を選び、候補外の設備は割り当てられない
  • 候補が未登録の工順は設備を限定しない。候補を整備していない運用でも差立が止まらないようにするため
  • 候補は工順マスタの現在値を見る（設備は差立で決めるため展開時スナップショットに含めない：下記「指図展開時のマスタ固定」）。工順の候補を増やせば、仕掛中の作業指示でも新しい設備を選べる
  • Routing.EquipmentId（代表設備）は候補の1つとして扱う。候補を書かずに代表だけ指定した既存の工順が、差立で設備を選べなくならないようにするため。画面は候補リストに一本化し、代表設備はCSVと既存データの移行用に残す
• 製造条件の指示値と実績値：製造条件（温度・回転数など）は「こう作れ」という指示値と「実際はこうだった」という実績値の対になる。指示値と許容範囲を持たないと、実績を記録しても逸脱かどうかを判定できない
  • 条件の定義と指示値・許容範囲はControlItem（工程管理項目）に持つ。検査項目（InspectionItem）と同じ形にする：指示値と実績値の関係は検査パラメータと検査結果と同じ構造であり、判定・版管理・スナップショットの考え方をそのまま適用できるため
  • 指示値は許容範囲の内側であることを登録時に確認する。範囲外を許すと、指示どおりに作った実績が逸脱と判定されてしまう
  • どの工程で記録するかは工順（BOP）の工程ごとに紐付ける（RoutingControlItem。I-30-20-10「BOPに登録された作業に工程管理条件を定義する」）。指図展開時は紐付けどおりにWorkOrderControlItemへ写す
    • 項目側に対象品目・対象工程を持たせて自動で選ぶ方式（改訂48）はやめた。品目を指定した項目がその品目の全工程の作業指示に載り、「品目Xの加熱工程だけ」を表せず、同じ工程が2回ある工順では工程ごとに条件を変えられなかったため
    • 項目側には対象を持たせない（作業手順書と同じ。両側に持たせるとどちらで紐付けたかで運用が割れる）。品目ごとに指示値が違う条件は、品目ごとに別の項目として登録する
    • 紐付けられるのは有効な項目だけで、紐付け中の項目は無効化できない（MasterDeactivationPolicy。単票APIとCSV取込の両方で同じ条件）。無効化を許すと、使わせないはずの条件が以降の作業指示へ写り続ける
  • スナップショットを取る理由は検査基準（下記）と同じ。マスタを改訂しても展開済みの作業指示の指示値・許容範囲・版数は変わらない
  • 実績は指示と照合して逸脱を判定する。判定は1か所（Api/Policies/ControlItemDeviationPolicy）に集約し、基準はマスタの現在値ではなく作業指示のスナップショットを使う（現在値で判定すると同じ実績の合否が後から変わる）
    • 判定しない場合を「範囲内」と混同しない。数値でない記録（定性的な記録）と、上下限をどちらも持たない項目（記録だけが目的の条件）は判定対象外とし、逸脱フラグはnullのままにする。falseにすると、条件を決めていない項目まで合格扱いになる
    • 逸脱は監査ログのdetailにも内容を残し、ロットの履歴（H-30-10-04）では逸脱した記録だけを出す（範囲内まで並べると見るべきものが埋もれる）
  • Routing.ControlItems（自由記述）は工程管理項目の補足として残す。指示値を持たない確認事項や外注の内容など、工程管理項目にもチェックリストにも当てはまらない記述の置き場になる。作業指示へはそのまま写す（上限1000文字）
• 製造品軸と設備軸の紐付け（2軸データ）：製造の実績は「どのロットをどう作ったか」（製造品軸）と「そのとき設備はどうだったか」（設備軸）の2つの軸で残り、両者の交差点が品質不良の原因究明に効く。交差点を作るのはEquipmentLog.対象作業指示IDだけなので、これを欠かすと設備の状態を時刻の重なりから推測するしかなくなる
  • 稼働報告（B-40-20-01）では作業指示を任意で指定する。段取り・保全・アイドルのように作業指示に紐づかない稼働区間もあるため必須にはしない
  • ロットの履歴（H-30-10-04）は、そのロットを産出した作業指示に紐づく稼働区間を設備稼働履歴として返す。紐付けのない稼働は履歴に出ない（出すと別のロットの設備状態を混ぜて見せることになる）
  • 稼働状態にアイドル（設備は動かせるが加工していない待機）を持つ。停止と分けないとOEEの時間区分が取れないため。稼働サマリ（E-20-10-03）では時間区分として表示し、時間稼働率の分母にも含める
  • EquipmentLogStatusはDBへ文字列で保存するがJSONでは数値でやり取りするため、列挙子は末尾にだけ追加する（途中へ挿入すると既存のAPI利用者が送る数値の意味が変わる）
• 資源階層への紐付け：設備・在庫ロケーションは作業区（WorkCenter）を参照して所在を表す。判定は1か所（Api/Policies/WorkCenterHierarchyPolicy）に集約し、単票APIとCSV取込の双方から呼ぶ
  • 設備は最下段の作業区にだけ紐付ける。作業区は「作業の管理単位」であり、ここを一意に決めておかないと、同じ設備群がラインに付いたり作業区に付いたりして工程別・作業区別の集計軸が定まらなくなるため。上位（エリア・ライン・工場）は作業区から辿れば得られる
  • 在庫ロケーションは段を問わない。部材倉庫・製品倉庫は工場直下に置かれることが実際に多く、倉庫のためだけにダミーの作業区を作らせないため。有効な資源であることだけを求める
  • どちらも未設定を許す（作業区を整備する前でも設備台帳・ロケーションを登録できる）。無効化された作業区は新たに指定できない
  • 工順（BOP）にも作業区を持たせ、設備と同じく最下段のみとする。設備は差立（B-10-20）で割り当てるため、作業区を設備から導くと差立前の作業指示は所在が不明になり進捗を場所で見られない。計画段階で決まる工順側に持たせることで、展開直後から集計軸として使える
  • 工順の作業区は指図展開時に作業指示へスナップショットする（上記「指図展開時のマスタ固定」と同じ方針）。工順を改訂しても展開済みの指示の集計軸は変わらない
  • 従業員の作業場所も作業区で表す。段は問わない（工場単位・ライン単位で働く担当者を表せるようにするため）
• 直（シフト）の定義：夜勤は終了時刻が開始時刻以下という形で日跨ぎを表す（22:00〜06:00）。「翌日フラグ」のような別項目は持たない——持たせると 06:00〜06:00 のような同じ時刻の組み合わせで意味が二通りになる
  • 実績の直は記録時に固定する（ProductionRecord.ShiftId）。集計のたびに時刻から引き直すと、直の時間帯定義を変えたときに過去の集計まで動いてしまう（上記「指図展開時のマスタ固定」と同じ考え方）。直を登録していない運用では null のままで、集計では「（直なし）」にまとまる。この状態では品質分析で直の定義を促す案内を出す（表だけ出しても、なぜ1行なのかが伝わらないため）
    • 直の名称を変えると過去の集計表示にも及ぶ。集計は固定した ShiftId で行い、表示名はマスタの現在値から作るため。時間帯の変更が過去に及ばないのと非対称だが意図的で、時間帯は「どの実績がその直か」を決める判断基準（後から変わると集計が動く）なのに対し、名称は同じ直の呼び名でしかない
    • 製造日の境界時刻（3.9節）をまたぐ直は警告する（拒否しない）。またぐとその直の実績が2つの製造日へ分かれ、日報（製造日単位）と直別集計の母数が食い違う。交代時刻と日次締めの時刻が揃わない工場はあるため運用としては成立しうるので、登録は通して気づけるようにする。警告は保存時だけでなく一覧にも出し続ける（境界時刻は設定値で、設定変更で後からまたぐようになることもある）。CSV取込でも同じ条件で警告を返す（取込結果の Warnings。エラーと違いロールバックしない＝取込は成功する）
    • 固定した直は集計だけでなく実績照会にも出す（実績一覧の列とロット履歴の製造行）。集計にしか出さないと、ある実績がどの直に入ったかを現場が確認できず、直別の不良率を見て原因を追うときに個々の実績まで降りられない
  • 時間帯が重なる直は登録できない。重なると、ある時刻がどの直かを一意に決められず、実績の直が定まらない。判定は Api/Policies/ShiftSchedulePolicy（単票API・CSV取込の両方から通す）
  • 所属（部署・課）は自由記述とし、組織のマスタは別に持たない。権限は作業場所とロールで決まり、所属は表示と名簿の並べ替えにしか使わないため
  • 進捗を上位の段でまとめて見るときは配下へ展開する（WorkCenterHierarchyPolicy.SelfAndDescendantIds）。作業指示が持つ作業区は最下段なので、指定したIdと一致するかだけで絞ると、ラインや工場を選んだときに常に0件になる
• 指図展開時のマスタ固定：工順（BOP）とMBOMは改訂され上書きされるため、製造指図の工程展開時点の値を実績側へ固定する。以降にマスタが改訂されても、既に展開された指図の製造条件と照合条件は変わらない
  • 工順 → WorkOrder（標準作業時間・標準段取り時間・必要スキル・工程管理項目・チェックリスト）。差立のスキル照合（F-20-30-01）はこのスナップショットを使う
  • MBOM → ManufacturingOrderMaterial（予定材料）。部材投入の照合（B-30-20-01）とバックフラッシュ（B-40-10-09）はこの予定材料を基準にする
    • 予定数量は親品目の標準不良率で割り増し（原単位×指図数量÷(1－率)）、消費工程は未指定なら展開時の最終工程に解決して固定する。バックフラッシュはその作業指示の工程を消費工程とする行だけを引き、作業指示書にもその行だけを載せる
  • 改訂を仕掛中の指図へ反映したい場合は、指図を展開し直す（マスタ側に有効期間や版を持たせる方式は採らない。実績側スナップショットのほうが「当時どの条件で作れと指示されたか」を直接説明できるため）
  • MBOMの部品切替を有効日／失効日で持つ方式は採らない（切替前後の両方の行を保持し、失効日・有効日で切り替える一般的な方式）。理由は上と同じで、マスタ側に期間を持たせても「その指図が展開された時点でどちらの部品が有効だったか」は展開時刻と有効日の突き合わせを毎回やり直さないと分からないのに対し、予定材料（ManufacturingOrderMaterial）へ固定すれば当時の指示がそのまま残るため。部材投入の照合（3.9節）も日付の解釈を持たずに済む
  • ただしこの方式では、切替日を事前に登録しておく運用（設計変更の予告。A-40-10-05）ができない。当面は切替日にMBOMを差し替え、仕掛中の指図は必要に応じて展開し直す運用とする。予告運用が必要になった場合は、マスタに有効期間を持たせるのではなく**「切替予定」を別に持って切替日にMBOMへ適用する**形で［将来拡張］する（実績側スナップショットの方針を崩さないため）
  • 設備・治工具は差立（B-10-20）で作業指示へ割り当てるため、工順の既定値はスナップショットに含めない
  • 作業手順書（SOP）は本文を固定せず、参照と版数だけを固定する。上の方針の例外で、理由は手順書と製造条件で前提が違うため：
    • 製造条件（WorkOrderControlItem）は逸脱の判定基準なので、後から変わると同じ実績の合否が変わってしまう。だから本文ごと固定する
    • 手順書はこれから作業する人への指示であり、安全上の訂正のように改訂した手順は仕掛中の作業指示にも届くべき。だから表示はマスタの現在値を使う
    • 代わりに展開時点の版数（WorkOrder.WorkProcedureVersion）を残し、現在値と食い違えば作業者に「改訂あり」を示す。監査には「計画時はどの版だったか」が残る
    • 工順から手順書の紐付けを外しても、展開済みの作業指示の紐付けは変わらない（スナップショットなので）
• 作業指示の状態履歴：作業指示の状態も現在値しか持たないため、配布・着手・完了・承認・取消の遷移をWorkOrderStatusHistoryへ残す（ロット状態履歴と同じ方針）。状態変更はWorkOrderStatusService経由で行い、直接代入しない
• 実績訂正の扱い：生産実績・検査実績は現在値を上書きして訂正する（一覧・集計・在庫計上は常に最新値を見ればよい）。訂正前の値は訂正履歴（ProductionRecordCorrection / InspectionResultCorrection）へ1訂正＝1レコードで残す。「現在状態は業務を進めるため、履歴は後から説明するため」という分離をロット状態履歴（5.3節）と同じ方針で適用する
  • 訂正履歴は業務履歴であり、製造記録・トレース画面・検査成績書から参照する。監査ログ（AuditLog。7.6節）は操作の記録であり、用途が異なるため両方に残す
  • 訂正できる状態と権限は従来どおり（承認済みの検査は訂正不可。訂正は生産管理・品質管理ロールのみ）。訂正そのものへの承認フローは初期リリースでは行わない［将来拡張］
• 検査基準の対象：検査基準は品質管理が品目単位・工程単位で策定するもの（C-10-10-02）で、工程管理項目（5.7節「製造条件の指示値と実績値」）と違い工順（BOP）には紐付けない。受入・完成品・サンプル検査は工程を持たず、購入品には工順そのものが無いため。また検査指示は人が対象を選んで発行するもので、全作業指示へ自動で載るものではない
  • 対象品目・対象工程は、それぞれ空なら条件にしない・指定があれば一致を求めるとし、両方を**「かつ」**で組み合わせる（Api/Policies/InspectionItemPolicy）。「または」で選ぶと、品目Yの加熱工程の基準が品目Xの加熱工程の検査に載り、品目Xの別工程の基準も載る
  • 対象工程を持てるのは工程内検査の基準だけ。受入・完成品・サンプル検査の基準は対象品目を必須とする（工程を持たない検査に工程付きの基準を登録しても永久に選ばれない）。工程内検査の基準は対象品目か対象工程の少なくとも一方を持つ（全品目・全工程に載る基準は意図せず広がるため作らせない）。基準値は規格値の範囲の内側に置く
  • 検査項目を指定して発行する場合（API・実績CSV）も同じ条件で確かめ、合わない基準（無効・種別違い・対象違い）は拒否する
  • 同じ工程が工順に2回ある場合、工程ごとに別の基準を持たせることはできない。必要になれば基準に工程順序を持たせて拡張する［将来拡張］
• 検査の判定：合否は指示発行時点のスナップショットの規格値で決める（Api/Policies/InspectionJudgmentPolicy）
  • 測定値と規格値（下限・上限のどちらか）があれば自動判定し、手で指定した合否が自動判定と食い違えば拒否する。規格外の品を使うなら不適合の特採（C-30）で処置する。判定を手で上書きできると、規格外品が合格の記録で出ていく
  • 実績の訂正も同じ条件で合否を決める（訂正だけ別の条件にすると、訂正が規格外品を合格にする抜け道になる）
  • サンプリング数は総合判定の下限。サンプリング数を持つ項目は、その数以上のサンプル（サンプル番号の種類）の実績がそろうまで判定できない
• 検査基準の版と過去実績：検査項目マスタ（InspectionItem）は改訂され規格値が上書きされる（版数のみ加算）。最新マスタで過去ロットを判定・印字すると当時の判定根拠を再現できないため、検査指示の発行時点の基準をInspectionOrderItemへ写して保持する。合否の自動判定・詳細画面・検査成績書はこのスナップショットを使う（改訂後に成績書を再出力しても、当時の規格値と版数が印字される）。マスタを参照するのは新規指示の作成時だけとする。
• 不適合の連鎖：NonconformanceReportの対応指示から、リワークはManufacturingOrder（リワーク区分）、保留・廃棄はLot.在庫ステータス変更、特採は承認記録付きで次工程進行（在庫ステータスを正常へ戻す）、へそれぞれ接続する（C-30、H-30-20）。在庫ステータスの変更は契機（在庫操作/検査/不適合/受入）を問わずLotStatusHistoryへ遷移を残す（誰が・いつ・なぜ止め、どの判断で解除したかを後から説明できるようにするため）。
• 治工具寿命：ToolUsageの累計とTool.寿命閾値の比較で交換・廃棄通知を行う（E-60-20-02）。

---

6. 画面一覧

6.1 Webクライアント（MesApp.Client.Web）

画面のロール制御の方針：APIと同じ線引きにする。画面そのものは認証済みユーザー全員が開ける（参照系はAPIも全員に開放しているため）。書き込みの操作要素（登録・実行・取消のフォームとボタン）だけを AuthorizeView で隠す。ナビゲーションも全ロールに全項目を出す（開いて中身を見ることはできるため）。表示制御はUXのためであり、最終判定は常にAPI側（7.4節）。 ロールで絞らない記録（設備稼働報告・治工具使用実績・保全依頼・不適合報告・トラブル報告。7.4節）は、画面側でも隠さない。 APIにある機能は画面からも操作できるようにする。画面のないAPIは、代替手段を書いても運用では使われず、 実装だけが残って仕様と実態がずれる（部材投入・作業時間・搬送指示・製造条件データ・実績訂正・指図変更・検査取消で実際にそうなっていた）。 権限が足りずに画面を開けなかった場合は、ログイン画面へ戻さず「権限がありません」を表示する（ログイン済みの利用者がログイン画面に送られると、権限の問題だと分からないため）。

1. （欠番。改訂90で端末アクティベーション画面を削除）
2. ログイン画面
3. ダッシュボード（サマリ・推移・内訳のタブ。サマリは期間の実績・稼働率・不良率と進捗、推移は日次14日・週次12週・月次12か月、内訳は工程・品目・直・ライン・作業区・設備別。サマリはKPIタイル（前の期間との差）とドーナツ、推移は棒と折れ線の複合グラフ、内訳は横棒で示し、数値は表でも見られる。グラフは自作SVG（Shared/Charts）でJSライブラリを使わない。期間は日次・週次・月次で選び前後へ移動する。「今日」は製造日で、api/business-date から受け取る）
4. 製造指図管理画面（一覧・登録・承認・変更/削除・工程展開・リワーク指図作成）
5. 差立画面（作業指示への作業者・設備・着手順の割当。スキル/資格照合付き）
6. 作業指示一覧・詳細画面（配布・承認、指示書/現品票出力）
7. 段取り・チェックリスト画面（前/後段取りの着手〜完了記録、治工具の引当・払出・受領・返却、チェックリスト実施）
8. 実績入力画面（着手/完了、良品数・不良数、部材投入、製造条件データ、実績訂正、状態履歴。バーコード/QRスキャン対応）
9. 工程進捗管理画面（工程別進捗、遅れている作業指示、トラブル対応履歴） 9.1 作業時間画面（直接作業＝作業指示に紐づく時間、間接作業＝区分を指定する時間。一覧は本人分、管理系ロールは全員分） 9.1.1 生産計画・予実画面（計画登録タブ＝製造日×品目×工程（作業区は任意）の計画数量の登録・変更・削除、予実タブ＝製造日×品目×工程の計画と出来高・達成率の表と、1品目・1工程に絞ったときの日ごとのグラフ（計画は棒・実績は折れ線、左右の軸は同じ目盛り）。集計はAPIが行う。A-30-10-01） 9.2 生産性モニタリング画面（歩留まり・直行率の品目別/工程別集計、標準時間の予実と見直し候補、製造リードタイムの分布。期間は製造日基準）
10. 受入画面（受入登録・取消・返品、ラベル/現品票印刷）
11. 在庫照会・在庫オペレーション画面（在庫移動、数量調整、ロット分割/統合/振替、在庫ステータス変更、期限アラート）
12. 出庫・払出画面（出庫指示、ピッキング指示・実行、払出戻し） 12.1 搬送指示画面（工程間搬送・移動指示の作成・実行・取消。指示と実行を分け、運搬中の状態を残す）
13. 出荷管理画面（出荷指示、ピッキング/梱包/積込、出荷完了報告、伝票発行）
14. 棚卸画面（棚卸指示、実棚入力、差異一覧・調整・確定）
15. 検査管理画面（受入/工程内/完成品/サンプル検査の進捗一覧、検査指示発行、実績入力、判定、成績書発行、承認、取消）
16. 不適合管理画面（逸脱/不具合一覧、対応指示・実行記録、特別採用承認）
17. 品質分析画面（不良集計、品質モニタリング、管理図と工程能力指数）
18. 出荷判定画面（判定一覧、判定・承認、判定書発行）
19. トレーサビリティ画面（ロット番号によるトレースバック/フォワード、製造・設備・検査履歴閲覧）
20. 設備保全画面（設備台帳、稼働履歴、稼働サマリ・OEE、保全計画・指示・実績（消費部材の在庫引落しを含む）、保全手順書、消耗材モニタリング）
21. 治工具管理画面（治工具マスタ、利用実績・寿命通知、メンテナンス記録）
22. マスタ管理画面（品目／MBOM／工程／工順（BOP）／作業区／設備（BOE。保全部品の編集を含む）／治工具／ロケーション／検査項目・基準／検査機・測定器（校正管理）／工程管理項目／作業手順書／チェックリスト／不良理由／勤務シフト／ユーザー・スキル資格。各タブにCSV一括入出力パネルを持つ。画面上部にZIPの一括取込・全マスタの一括出力パネルを持つ） 22.1 実績CSV取込画面（実績の種別ごとに取込パネルを取り込む順に並べる。テンプレート出力・検証のみ・取込。エクスポートは持たない。画面上部にZIPの一括取込パネルを持つ。取込欄の表示は種別ごとのロールで制御し、そのロールは api/actuals/csv/kinds が単票APIと同じ定数を返す）
23. （欠番。改訂90でシート・端末管理画面を削除）
24. 初期セットアップ画面（Userが0件の初回起動時のみ有効：初期管理者アカウント作成）
25. 監査ログ画面（システム管理者専用：期間・分類/操作・対象での絞り込み、変更前後を含む詳細の表示。個々の記録は編集・削除不可。保持期間を過ぎた分の一括削除は件数確認→実行の二段階）

6.2 （欠番）

改訂90で削除（WPFライセンスアプリを作らない）。

---

7. 非機能要件

7.1 （欠番）

改訂90で削除（WPFライセンスアプリのStore公開・アドオン課金。Microsoft Store での配布は単独PC向けの MesApp.Desktop のみで、7.8節を参照）。

7.2 配布形態

• Windows Store（MSIX・単独PC向け）: MesApp.Desktop。API・DB・Webクライアントを1つのパッケージに同梱し、1台のPCで完結して動作させる（7.8節）
• Zip配布: MesApp.Api（Webクライアント静的ファイル同梱）を自己完結版（win-x64 / linux-x64。配布先に.NETランタイム不要）で発行してzip化し、社内サーバー等に手動配置できるようにする（build/Pack-Zip.ps1）。起動スクリプト（start.cmd / start.sh）・LICENSE・対応ソースの所在（コミット）を同梱する。zipはUnixの実行権限を保持しないため、start.shが起動前に実行権限を付ける。リリースにはサンプルCSVのzip（samples-master-csv.zip / samples-actual-csv.zip / ダッシュボード確認用に約3か月分の実績を入れた samples-actual-csv-bulk.zip。同じ期間の生産計画は計画登録タブが1ファイルずつ取り込むのでCSVのまま samples-production-plans.csv）も添付する（リポジトリを持たないzip・ストア版の利用者が取込画面にそのまま渡せるよう。名前に版数を入れずreleases/latest/download/の固定リンクで案内する）
• Docker配布: MesApp.Api（Webクライアント同梱）をコンテナイメージ化し（Dockerfile。linux/amd64・linux/arm64）、ghcr.io/msmsrep/parallelfactorymesで公開する。非rootで動かし、DB（SQLite）とJWT署名鍵は/dataボリューム（MESAPP_DATA_DIR=/data）に置く。TZの既定はAsia/Tokyo（業務日付の境界に効くため）。起動例としてcompose.yaml（SQLite）とcompose.postgres.yaml（PostgreSQL）を置く。HTTPSはコンテナでは扱わず前段のリバースプロキシで終端する
• リリースの自動化: タグvX.Y.ZのpushでGitHub Actions（.github/workflows/release.yml）がビルド・テストの後にzipをGitHub Releaseへ添付し、イメージをGHCRへ登録する。版数はタグから取り（-p:Version）、既定値はDirectory.Build.props。-を含むタグはプレリリース扱いにしてイメージにlatestを付けない。MSIXは署名とストア提出が手作業のため対象外。push・PRごとのビルドとテストは.github/workflows/ci.yml（Windows。MesApp.Desktopを含むため）
• MesApp.Client.Webは必ずMesApp.Apiが配信する（別配信は行わない。APIと同一オリジンに置き、CORSや配置の組み合わせを増やさないため）

7.3 オフライン動作について

• 本構成はクライアントがAPI経由でしかDBにアクセスしないため、API・DBがダウンしているとクライアントは操作不能になる。
• 完全オフライン対応が必要な場合は、WebクライアントのPWA化（Service Workerによるキャッシュと再送信キュー）を将来検討する（初期リリースではスコープ外とし、Phase以降で拡張）。

7.4 セキュリティ

• 認証はASP.NET Core Identity + JWT、API側に集約
• JWTの構成と保管：アクセストークン（短命、既定60分）＋リフレッシュトークン（既定12時間、交代勤務のシフト長を考慮）で構成する。アクセストークンはWebクライアントのメモリ上にのみ保持し、localStorage等の永続ストレージには保存しない（XSS時の窃取面を最小化）。リフレッシュトークンはHttpOnly Cookieで保持し、サイレント更新する
• リフレッシュトークンの再利用検知：リフレッシュはローテーション（旧トークンを即失効し新トークンを発行）する。失効済みトークンが再提示された場合は盗用の可能性があるものとして、そのユーザーの全リフレッシュトークンを失効させ、監査ログに記録して再ログインを求める。正規の利用者も巻き添えで再ログインになるが、盗んだ側にセッションを継続させないことを優先する
• リフレッシュトークンの保持期間：失効済み・期限切れのレコードは有効期間の2倍を過ぎた時点で削除する（発行のたびに当該ユーザー分を掃除する）。監査は監査ログ（7.6節）側で行うため、トークン行を残し続けない
• JWT署名鍵：発行側と検証側は同一のインスタンスから鍵を取る。鍵ファイルの自動生成は一時ファイルへ書いてから移動し、同時起動で別々の鍵を作らないようにする。UNIX系では鍵ファイルを所有者のみ読み書き可とする
• CSRF対策：状態変更APIはすべてAuthorizationヘッダのJWTを必須とし（Cookieのみでは実行不可）、Cookie（リフレッシュトークン）にはHttpOnly・Secure・SameSite=Strictを設定する。トークンリフレッシュ等Cookieのみで動作するエンドポイントへのクロスサイトからの発火はSameSite属性で遮断する
• 通信は全てHTTPS。バックエンドはローカル（社内）環境で稼働するため公的CA証明書は取得できない前提とし、プライベートCA（社内CA or mkcert等）で発行した証明書をサーバーに設定し、CA証明書をクライアント端末（ブラウザ利用端末）に配布・信頼させる運用手順をドキュメント化する
• HTTPSはアプリ側で強制しない（UseHttpsRedirection・HSTSは入れない）。HTTPSの終端は配置側の責務とし、Kestrelのエンドポイント設定またはリバースプロキシで用意する。アプリ側で一律に強制すると、単独PC配布（7.8節）がループバック（http://127.0.0.1）で動作できなくなるため。サーバー運用でHTTP接続を塞ぐ必要がある場合も、リダイレクトではなく配置側でHTTPのリッスンをやめる
• リバースプロキシの転送ヘッダは、信頼するプロキシを設定したときだけ読む（ReverseProxy:KnownProxies（IP）・ReverseProxy:KnownNetworks（CIDR））。読むのは X-Forwarded-For・X-Forwarded-Proto で、これによりプロキシの後ろでもリフレッシュCookieに Secure が付き（接続がHTTPSかどうかで付け外しするため）、監査ログ（7.6節）に端末の接続元IPが残る。未設定なら転送ヘッダを一切読まず、ASP.NET Core 既定のループバック信頼も外す。誰のヘッダでも信じると、HTTPで直接つないだ端末や同じPCの別プロセスがヘッダを偽装して接続元IPとHTTPS扱いを詐称できるため。設定値が解釈できないときは起動を止める（黙って無効になると、HTTPSで運用しているつもりで Secure の無いCookieを配り続ける）
• ロールベースアクセス制御はAPI側で一元的に判定（クライアント側の表示制御はUXのためのみで、最終判定は常にAPI側）
• 参照系と更新系の線引き：参照系は認証済みユーザー全員に開放し、更新系のみロールで絞る。ただしコントローラのクラスに [Authorize(Roles = ...)] を付けてはならない。認可属性はクラスとアクションで合成されるため、クラスで絞るとアクション側の [Authorize] では参照系を開放できない（出荷・出庫・棚卸で実際に、出荷判定を担う品質保証ロールが出荷指示を参照できなくなっていた）。クラスは [Authorize] とし、更新系のアクションへ個別にロールを付ける
• 製造実行の記録の権限：着手・段取り・チェックリスト・部材投入・実績報告・製造条件データ・作業時間の記録は、システム管理者・生産管理担当者・現場作業者に限る（RoleGroups.ShopFloorRecord）。現場作業者ロールの定義（1.2節）がまさにこの範囲であり、品質・保全・物流の担当者が製造実績を報告できる状態は監査上説明できないため
• CSV取込の権限は単票APIに揃える：マスタCSVの取込に必要なロールは、そのマスタの単票API（POST/PUT）と同じにする。CSVは同じマスタへの別の入口であり、片方だけ緩いと「画面のフォームからは登録できないマスタが、CSVからは書き換えられる」状態になる（スキル・資格で実際に起きていた）。種別ごとの必要権限はMasterCsvKindsが持ち、MasterCsvControllerはそれを見て判定する
• 異常・使用実績の記録は絞らない：設備稼働報告・治工具使用実績・保全依頼・不適合報告は、認証済みであればロールを問わず記録できる（上の「更新系はロールで絞る」の意図的な例外）。気づいた人がその場で上げられることを優先し、絞って報告が落ちるほうが害が大きいと判断する。これらに対する指示・承認・判定は従来どおりロールで絞る
• 初回パスワード変更の強制：初期管理者のシードおよび管理者によるユーザー作成・パスワードリセットで発行した資格情報は、パスワード変更が済むまでパスワード変更以外のAPIを使えない。アクセストークンに未変更を示すクレームを載せ、API側（Api/MustChangePasswordFilter）が参照系も含めて403で拒否する（クライアント側の画面誘導だけでは、デスクトップ配布で画面に表示する初期パスワード（7.8節）のまま全APIを操作できてしまうため）

7.5 性能・規模

• 想定同時接続端末数、日次実績データ件数などは導入規模に応じて別途設定（初期は数十端末規模を想定）
• 一覧APIのページング：運用とともに件数が増え続ける一覧は {items, total, page, pageSize} の形で返し、既定50件・上限200件とする（?page=2&pageSize=100）。画面は共通コンポーネント（Web/Shared/Pager.razor）でページ送りする。ページ間の重複・欠落を避けるため、並べ替えを確定させてからページを切ること
• 選択肢（ドロップダウン）は一覧とは別のAPIにする。一覧はページを送って全件を見せるもの、選択肢は「目的の1件を選ばせる」ものであり、件数が増えたときに要るのはページ送りではなく検索。GET .../options?q=&limit=（既定50件・上限200件）でコード・番号・名称の部分一致を返し、ロット番号や指図番号をスキャンした値をそのままqに渡せるようにする
  • 該当が上限を超えたら応答のtruncatedで知らせ、画面は「絞り込んでください」と表示する。黙って切り捨てない
  • 対象：在庫（api/inventory/stocks/options）・作業指示（api/work-orders/options）・出荷指示（api/shipping-orders/options）・品目（api/products/options）。これらは複数画面でドロップダウンの元になっているため、選択肢APIを用意したうえで一覧側をページング対象に含める
  • 作業者（api/users/options）：差立で作業者を選ばせるために、有効なユーザーの氏名だけを全ロールへ返す。ユーザー管理の一覧（ロール・有効フラグ・パスワード状態を含む）はシステム管理者専用のままとし、選択肢と管理の一覧を分けることで、参照系を開くために管理情報まで配ることを避ける
  • 「有界」と見なす目安は1マスタ1,000件とする。工程・ロケーション・設備・治工具・スキル・検査項目・チェックリスト・不良理由はこの範囲に収まる前提で、従来どおり一覧を全件返して選択肢に使う。品目マスタだけはこの前提が成立しない（実運用で数千〜数万件になる）ため選択肢APIを用意する。他のマスタも運用で目安を超えるなら同じ扱いにする
• 一覧を集計に使わない。工程別の進捗（B-60-10-01）のように件数を数える表示は、一覧を全件取得して画面で数えるのではなくDB側で集計する（api/work-orders/process-summary）
• ページングの対象外は、絞り込みをクライアント側で行っている一覧（作業時間記録の期間絞り込み。SQLiteがDateTimeOffsetの比較を翻訳できないため、先にページを切ると絞り込み結果が正しくならない）

7.6 ログ・監査

• 操作ログ（誰が・いつ・何を変更したか）をAPI側で記録し、追跡可能にする。
• 変更前後を追跡したい操作（実績訂正・検査実績訂正・在庫の数量調整/ステータス変更/分割/統合/振替）は、AuditLog.詳細へ{ before, after, reason }の形のJSONで記録する。後から「何がどう変わり、なぜ変えたか」を検索・抽出できるようにするため、文字列の連結ではなく構造化して残す。作成・削除など要約で足りる操作は要約文字列でよい
• 日本語はエスケープせずそのまま保存する（監査ログは人が読む前提のため）
• 監査ログの保存はキャンセルしない：記録は業務データの保存後に行うため、リクエストのキャンセル（利用者が画面を閉じた等）で中断すると「業務データは確定したのに記録がない」状態になる。保存にはキャンセルトークンを伝播させない
• 監査ログを参照できるようにする：記録するだけでは「追跡可能」にならない。GET api/audit-logs（期間・分類・操作・対象種別/ID・ユーザーで絞り込み、ページング）と監査ログ画面（システム管理者専用）を用意する。参照専用とし、監査ログを作成・更新・削除するAPIは設けない（記録を書き換えられると監査の意味がなくなる）
  • 期間の絞り込みは記録日（AuditLog.RecordedOn）で行う。記録日は工場のローカル暦日（BusinessDay:TimeZone。未設定ならサーバーのローカルタイム）とする（画面は記録時刻をローカル時刻で表示するため、UTCの日付で絞ると見え方と食い違う）。製造日（3.9節の6時境界）ではなく暦日とする——監査ログは業務の1日ではなく法定の保存年数で数えるため、夜勤を前日へ寄せる境界は当てない。保持期間の境界も同じ暦日で求める。SQLiteはDateTimeOffsetの比較・並べ替えをSQLへ変換できないため、Timestampだけでは全件読み出しになる。並べ替えも同じ理由で記録順（Idの降順）を用いる
  • detailのJSONではenumを名前で保存する（数値のままでは人が読めず、列挙子を並べ替えると過去のログの意味が変わる）
• 保持期間：監査ログは5年間保持する（Audit:RetentionYears で変更可。製造記録の追跡要求と、単独PC配布（7.8節）でDBが際限なく膨らまないことの兼ね合い）。自動削除は行わない：消してよいかは業務判断であり、システムが黙って消すと監査の根拠が失われる。容量が問題になる運用では、7.7節のバックアップを取得したうえで、システム管理者が監査ログ画面（または POST api/audit-logs/purge）で期間を指定して削除する
  • 保持期間の内側は削除できない（指定日が保持期間の境界より新しければ拒否する）。任意の期間を消せると、直前の操作の記録を消して隠せてしまい、監査ログが証跡として成り立たない
  • 理由の入力を必須とし、削除したこと自体（期間・件数・理由・実行者）を監査ログに残す（削除の記録は削除の後に書くため、同じ操作では消えない）
  • ?dryRun=true で削除件数だけを確認できる（DBには触らない）。CSV取込（3.1節）と同じ考え方で、消す前に対象を確かめられるようにする。画面では件数の確認を必須の一段目とし、期間か理由を変えたら確認をやり直させる（確認した内容と実際に消す内容がずれないようにするため）

実績データの保持とアーカイブ

監査ログ以外の実績データにも保持の方針が要る。製造を続ける限り増え続ける一方で、単独PC配布（7.8節）ではSQLiteのファイルが1つであり、容量が増えれば一覧・集計の応答が直接悪化するため。

実績データは、消してよいかの判断が同じものどうしで3層に分け、層ごとに削除可否と保持期間を決める（エンティティごとに個別の年数を持たせない。どれがどの理由で消せないのかが読めなくなるため）。

層	対象	削除	保持期間
A. 追跡の連鎖	ManufacturingOrder / WorkOrder / Lot / LotGenealogy / MaterialConsumption / ProductionRecord / InspectionOrder / InspectionOrderItem / InspectionResult / NonconformanceReport / ShipmentJudgment	削除しない	無期限（アーカイブ対象）
B. 連鎖に付随する業務履歴	WorkOrderStatusHistory / LotStatusHistory / ProductionRecordCorrection / InspectionResultCorrection / ProductionDefect / ProductionDataRecord / SetupRecord / ChecklistRecord / ChecklistResultItem	単独では削除しない	Aと同じ寿命（Aのアーカイブに同行する）
C. 運用ログ	EquipmentLog / WorkTimeRecord / ToolUsage / InventoryTransaction	保持期間を過ぎた分のみ手動削除	既定5年（Retention:OperationalLogYears）

• A は保持期間による削除の対象にしない。トレースバック／トレースフォワード（H-30-10）は部材ロット → 部材投入 → 作業指示 → 生産実績 → 産出ロットの連鎖を辿るため、途中の1種類でも欠けると追跡そのものが成立しない。「10年前のロットだけ消す」も成り立たない（そのロットを使った製品がまだ市場にある）。容量対策は削除ではなくアーカイブで行う
• B を A から切り離して消さない。親（作業指示・ロット・検査）が残っているのに履歴だけ消えると、「なぜ保留にし、どの判断で解除したか」「当時どの規格値で判定したか」を説明できなくなり、履歴を分離して持たせた意味（5.7節）が失われる
• C も自動削除は行わない（監査ログと同じ理由。消してよいかは業務判断）。削除は監査ログの一括削除（上記）と同じ形にする：保持期間の内側は拒否、理由を必須、?dryRun=true で件数だけ確認、画面は件数確認→実行の二段階、削除したこと自体を監査ログに残す
• C にも個別の削除禁止条件がある。次に該当する行は保持期間を過ぎていても残す
  • ToolUsage：治工具のLifeResetAt以降の行（寿命累計の根拠。消すと寿命判定がやり直しになる。E-60-20）
  • InventoryTransaction：在庫が残っているロットに紐づく行（現在庫がどこから来たかを説明できなくなる）
  • EquipmentLog：作業指示に紐づく行（PQC×EQCの対比に使う。設備軸の実績は作業指示に紐づいた時点でAの一部として扱う）
• アーカイブ（別DB・別ストレージへの移送）は［将来拡張］とする。当面は7.7節のバックアップを取得したうえで、容量が問題になる運用ではDBプロバイダーをSQLiteからPostgreSQL/SQL Serverへ切り替える（4章）ことで対応する。移送を実装する際も、Aは参照できる状態のまま移すこと（トレース画面が移送済みロットで空振りしない）を条件とする

電子記録・電子署名規制（21 CFR Part 11 / EU Annex 11）は対象外

本システムは加工・組立産業を前提としており（1.3節）、医薬・医療機器で求められる電子記録・電子署名規制には対応しない。 監査ログ（上記）があることをもって規制対応済みと解釈しないために、ここに明記する。

規制が求める主なものと、本システムの実際は次のとおり食い違う。

規制が求めるもの	本システムの実際
電子署名が本人に固有で否認できないこと（署名者・日時・意味を記録に結合する）	承認はロールによる操作＋監査ログで表す（3.9節の単段階承認）。署名の概念は無く、パスワード再入力も求めない
監査証跡の消去・改ざんができないこと	監査ログは追記のみだが、保持期間を過ぎた分の一括削除を管理者に許している（上記）。ハッシュ連鎖等の改ざん検知も持たない
システムのバリデーション（CSV/CSA、IQ/OQ/PQ）の文書化	自動テスト（ビルド時に全緑）はあるが、規制が要求する形式の検証文書は作らない
権限・アクセス管理の厳格な統制	ロールベースのアクセス制御（7.4節）までとし、操作単位の権限や職務分離の強制は行わない

規制対象の業務で使う場合は、電子署名（署名の意味と署名者の結合）・監査証跡の改ざん検知・バリデーション文書の3点を別途設計する必要がある。 いずれも後付けではなく、承認フロー（3.9節）と監査ログ（本節）の設計そのものを見直す規模になるため、［将来拡張］ではなく対象外として扱う。

7.7 バックアップ・リストア

• SQLite利用時：稼働中のオンラインバックアップ手段（VACUUM INTO またはSQLite Backup API）を用いた定期バックアップ手順を提供する。WALモードで稼働するため、稼働中のDBファイル単純コピーは行わないことを運用手順書に明記する。Docker構成ではコンテナを停止してから/dataボリュームを退避する手順を運用手順書に示す（バックアップ専用のコンテナやスクリプトは同梱しない。ボリュームの退避はDockerの標準手段で足りるため）
• PostgreSQL/SQL Server利用時：各DBの標準手段（pg_dump等）によるバックアップを前提とし、推奨手順をドキュメント化する
• リストア手順（バックアップファイルの差し替え→API再起動）と、リストアの影響範囲（実績データ・ユーザー・リフレッシュトークンがバックアップ時点へ巻き戻る。リストア後に再ログインが必要になり得る）を運用手順書に明記する
• MesApp.Desktop（7.8節）ではDBの実体は%LOCALAPPDATA%\Packages\<パッケージファミリー名>\LocalState\mesapp.db。アプリのアンインストールでこのフォルダーごと削除されるため、残したいデータは事前に退避する必要がある点を運用手順書に明記する。WALモードで稼働するため、バックアップは稼働中のファイルコピーではなくVACUUM INTOで取得する

7.8 単独PC向けMSIX配布（Microsoft Store）

サーバーを別途用意できない利用者向けに、MesApp.Desktopを1つのMSIXパッケージとしてMicrosoft Storeで配布する。

• 構成：MesApp.Desktop（WinForms + WebView2）がMesAppHost.BuildでMesApp.Apiをプロセス内に起動する。待受はhttp://127.0.0.1:0（OSが空きポートを選ぶ）で、外部からは接続できない。表示は同一プロセスのWebView2で、ユーザーから見えるのはひとつのデスクトップアプリのウィンドウのみ
• エントリポイントの共有：サーバー実行（MesApp.Api/Program.cs）とデスクトップ実行の双方がMesAppHostを使う。デスクトップ起動時はエントリアセンブリがAPIでなくなりコントローラの自動探索が働かないため、MesAppHostでAPIアセンブリをApplicationPartとして明示登録する
• 発行形態：自己完結（SelfContained）で発行し、配布先に.NETランタイムを要求しない。アーキテクチャごと（x64 / arm64）にパッケージを作る
• 書き込み先：インストール先（C:\Program Files\WindowsApps\...）は読み取り専用のため、DB・JWT署名鍵・WebView2ユーザーデータ・起動ログはすべてMesAppDataDirectory配下に置く（4章）
• データの置き場所はパッケージ専用領域：MSIXとして実行されている場合は%LOCALAPPDATA%\Packages\<パッケージファミリー名>\LocalStateを使う（GetCurrentPackageFamilyNameで判定し、MESAPP_DATA_DIRに設定してから他の初期化を行う）。ファイルシステムのリダイレクトは起きないため、既定の%LOCALAPPDATA%\ParallelFactoryMESのままだとアンインストール後もDBが残ってしまう。アプリを消したらデータも消えるという利用者の期待に合わせる
• 前提ランタイム：Microsoft Edge WebView2ランタイム。Windows 11には標準搭載。未導入時は起動時に検出し、日本語のメッセージで導入を案内する
• 初回起動：ユーザーが存在しないときのみMesAdmin設定の初期管理者を作成する。初期パスワードは初回ログイン時に変更を強制する（MustChangePassword）。ストア配布では利用者が手元に手順書を持たないため、初期管理者がまだパスワードを変更していない間はウィンドウ上端に資格情報を常時表示する（変更が済むと自動的に消える）。ストア審査でも審査員がログインできずに機能を確認できない事態を防ぐ
• 二重起動の抑止：同じSQLiteファイルを複数プロセスで奪い合わないよう、2つ目以降の起動は既存ウィンドウを前面に出して終了する（ログオンユーザー単位のミューテックス）
• 起動の記録と失敗時の扱い：WinExeはコンソール出力が誰にも見えず起動失敗が無言になるため、起動の各段階を%LOCALAPPDATA%\ParallelFactoryMES\startup.logに記録する。ホストの起動はUIスレッドではなくスレッドプールで実行し（UIスレッド上で待つとデッドロックし得るため）、2分を超えたら打ち切ってウィンドウにエラーを表示する。未処理例外はログに残したうえでメッセージボックスで通知する
• パッケージID：IdentityのName / Publisher / PublisherDisplayNameはPartner Centerが発行する値を使う。表示名（Properties/DisplayName・VisualElementsのDisplayName）はPartner Centerで予約したアプリ名と完全に一致させる（マニフェストに直書きせずbuild/msix-identity.jsonのDisplayNameで与える）。バージョンはx.y.z.0（第4桁は0）
• 署名：ストア配布ではMicrosoft Storeが署名するため、提出用パッケージは署名しない。手元での動作確認時のみ自己署名する
• 手順：build/Pack-Msix.ps1（発行→不要ファイル除去→マニフェスト生成→makeappx pack）。詳細はdocs-dev/MsixRelease.md

7.9 多言語対応（日本語・英語）

• 対象：画面の文言と、APIが返すエラーメッセージ（ProblemDetails の Title）。訳さないものは、マスタの値（品目名など）、監査ログの detail、利用者が入力した理由・備考、CSV の列キー（ProductCode などは元から英語）
• 言語の選び方：画面上部とログイン画面の切替で選ぶ。選んだ言語はブラウザごとに保存し（localStorage）、再読込して反映する。保存が無いとき、または対応していない言語が保存されているときは日本語にする。ユーザーごとには保存しない（別のPCでは既定の日本語に戻る）
• APIの文言：画面は選んだ言語を Accept-Language で送り、APIは対応している言語（MesCultures）で文言を返す。対応していない言語やヘッダが無いときは日本語で返す。en-US などの地域付きの指定は en として扱う。APIが利用者に返す文言（エラー・表示用の説明文）はすべて ApiText.T を通して訳す。状態を含むエラーは状態の表示名で示す（例：「状態 '着手' の作業指示は着手できません。」／ "A work order with status 'Started' cannot be started."）
• 保存される文字列は訳さない：在庫トランザクションの備考、ロット・作業指示の状態履歴の理由、監査ログの detail、自動で作る記録の本文（不適合報告・リワーク指図の備考など）は、表示言語に関係なく日本語の原文で保存する。操作した人の言語で記録の中身が変わると、後から検索・集計できなくなるため。サーバーのログも日本語のまま
• 書式は言語で変えない：切り替えるのは表示言語（UICulture）だけで、数値・日付の書式（Culture）は変えない。日付は yyyy-MM-dd のまま。言語によって CSV の出力やログの書式が変わらないようにするため
• 訳の持ち方：日本語の原文をそのままキーにし、英語の訳だけを *.en.resx（画面は Shared/UiText.en.resx、APIは Localization/ApiText.en.resx）に持つ。訳が無い文言は日本語のまま出るので、画面ごとに順に訳していける。値を埋め込むAPIの文言は {0} の書式で書き、値は引数で渡す（補間すると値ごとにキーが変わり訳に当たらない）
• 区分値とロールの表示名：ステータス・区分などの表示名は Core の EnumLabels に1か所で持ち、APIと画面の両方がそこから引く（訳は Localization/CoreText.en.resx）。同じ値が画面によって違う表記で出ていたのをこれで揃えた（例：品目区分の半製品は一覧・選択肢・APIのメッセージのすべてで「半製品・中間品」）。選択肢の補足（「受入検査」「HSE（健康衛生・安全）」など）は画面の文言として扱う
• 共通部品の文言：共通部品（CSV入出力・ページ送り・検索付き選択など）が自分で持つ既定の文言（「選択してください」「印刷 / PDF出力」等）は部品側で訳す。呼び出し側が引数で渡す文言（CSV の種別名・キー列名・ボタンの文言など）は、呼び出し側の画面で訳してから渡す（部品は受け取った文字列をそのまま出す）
• 取りこぼしの点検：訳のキーは原文そのものなので、文言を書き換えると英訳が当たらなくなり、L[...] を通し忘れた文言は英語でも日本語のまま残る。どちらもビルドでは分からないため scripts/I18nCheck.ps1 で一覧にする（en.resx に訳の無いキー、L[...] を通っていない画面の日本語。どちらかがあれば終了コード 1）。訳さない画面の日本語（言語名の「日本語」、保存される既定値など）はその行に「訳さない」と書いて対象から外す。APIの日本語リテラルは保存される文字列と見分けられないため対象にせず、レビューで確かめる

---

8. 技術スタック

分類	技術
Webクライアント	Blazor WebAssembly（.NET 10（LTS）、MES機能の唯一のクライアント）
バックエンドAPI	ASP.NET Core Web API（.NET 10（LTS）、Webクライアント静的配信を含む）
ORM	Entity Framework Core（プロバイダー切替対応、バックエンドのみ）
既定DB	SQLite
追加対応DB	PostgreSQL（Npgsql）、SQL Server
認証	ASP.NET Core Identity + JWT（APIに集約）
バーコード/QRスキャン	ブラウザカメラAPI or USB HIDリーダー入力
パッケージング	MSIX（Microsoft Store、単独PC向けMesApp.Desktop）、自己完結型Zip（API）、Dockerイメージ（API）

※ .NET 8はLTSサポートが2026年11月に終了するため採用せず、現行LTSの.NET 10で統一する。

---

9. ディレクトリ構成案

/ParallelFactoryMES
  /src
    /MesApp.Client.Web           … Blazor WebAssembly（MES機能クライアント）
      /Pages
      /Components
      /Services                  … APIクライアント、スキャン処理
    /MesApp.Api                  … ASP.NET Core Web API（バックエンド本体、Webクライアント配信）
      /Controllers
      /Services                  … 業務ロジック
    /MesApp.Desktop              … WinForms + WebView2（単独PC向けMSIX配布のホスト）
      /Assets                    … MSIXのタイル画像・アプリアイコン
      Package.appxmanifest
    /MesApp.Core                 … 共通ドメインモデル・DTO・APIコントラクト
    /MesApp.Infrastructure        … EF Core、DBプロバイダー切替、リポジトリ実装（API専用）
  /tests
    /MesApp.Api.Tests
  /.github/workflows
    ci.yml                        … push・PRごとのビルドとテスト
    release.yml                   … タグpushでzipとコンテナイメージを公開
  Dockerfile                      … MesApp.Api（Webクライアント同梱）のイメージ
  compose.yaml                    … SQLiteで起動する例（compose.postgres.yaml はPostgreSQL付き）
  /build
    Pack-Zip.ps1                  … 自己完結版zipの作成
    Pack-Msix.ps1                 … MSIXパッケージの作成
    New-MsixAssets.ps1            … タイル画像・アイコンの生成
    msix-identity.json            … Partner CenterのパッケージID
  /docs
    仕様書.md（本ドキュメント）

---

10. 開発フェーズ（マイルストーン）

フェーズ	内容
Phase 1	バックエンド基盤構築（MesApp.Api / Core / Infrastructure、EF Core+SQLiteでのDB設計・マイグレーション、JWT認証（アクセス＋リフレッシュトークン）、初期管理者セットアップ、監査ログ基盤）
Phase 2	マスタ管理API（品目・MBOM・工程・工順（BOP）・設備（BOE）・治工具・ロケーション・検査項目/基準・チェックリスト・ユーザー/スキル資格）＋生産管理API（製造指図の発行・承認・変更、工程展開、差立（スキル照合含む）、産出ロット採番、進捗モニタリング）
Phase 3	製造実行API（作業指示、段取り実績、チェックリスト実施、部材投入、実績入力・完了承認、製造条件データ、トラブル報告、リワーク指図、製造履歴訂正）＋物流/在庫管理API（受入、在庫オペレーション（移動・調整・分割/統合/振替・ステータス・期限）、出庫/払出（ピッキング）、バックフラッシュ、出荷、棚卸）
Phase 4	品質管理API（検査指示・実績・判定・成績書・承認、不適合/逸脱管理・特別採用、品質分析）＋品質保証API（出荷判定、ロットトレーサビリティ）
Phase 5	設備保全API（設備台帳・保全手順書、稼働履歴、保全計画・指示・実績、治工具寿命管理・メンテナンス）
Phase 6	MesApp.Client.Web（Blazor WebAssembly）のUI実装（製造指図・作業指示一覧・実績入力から着手）、MesApp.Apiからの静的配信
Phase 7	Webクライアント残画面の実装（差立・段取り/チェックリスト・在庫/物流・検査/不適合・出荷判定/トレーサビリティ・保全・マスタ管理）、帳票・ラベル出力、バーコード/QRスキャン統合（ブラウザカメラAPI / USB HIDリーダー）
Phase 8	（欠番。改訂90で削除：シート・端末管理）
Phase 9	（欠番。改訂90で削除：WPFライセンスアプリ）
Phase 10	DBプロバイダー切替対応（PostgreSQL/SQL Server）、Dockerイメージ化、Zip配布パッケージ作成、最終テスト

---

11. Claude Codeへの実装依頼時の進め方（推奨）

本仕様書をベースに、フェーズごとに区切って実装を依頼することを推奨する。

Phase 1の指示例:

この仕様書（Spec.md）を読み込んだ上で、Phase 1（バックエンド基盤構築）を実施してください。ソリューション構成（MesApp.Api / MesApp.Core / MesApp.Infrastructure）を作成し、EF Core + SQLiteでのDBモデル定義・マイグレーション、ASP.NET Core Identity + JWT（アクセス＋リフレッシュトークン、7.4節）による認証基盤、初期管理者セットアップ（2.2節E：Userが0件時のみ有効なセットアップAPI＋環境変数シード）を実装してください。DBプロバイダーは設定ファイルで切替可能な形で抽象化してください。

Phase 6の指示例（Webクライアント着手時）:

Phase 1〜5で実装済みのMesApp.Apiを呼び出す形で、MesApp.Client.Web（Blazor WebAssembly）に作業指示一覧・実績入力画面を実装し、MesApp.Apiから静的配信できるようにしてください。

各フェーズ完了後に動作確認を行い、次フェーズへ進む。

---

12. 参考

• 『MES/MOM導入のための標準業務一覧』（一般財団法人エンジニアリング協会。機能スコープの正とする要件定義） https://www.enaa.or.jp/research/smart/mes ※ 同一覧は著作権がENAAに帰属するため本リポジトリには含めない。上記より各自入手すること。
• みんなのMES（min-MES）: https://min-mes.com/
• OSSリポジトリ: https://github.com/mihatama/open-mes-project