一括表示を「私しか作れない」から「誰でも作れる」へ――食品表示DBの再設計

現在の一括表示ラベルは、商品情報をデータベースへ登録し、テンプレートへ出力できるところまで進んでいます。

しかし、商品情報の入力欄があることと、担当者が安全に一括表示を作れることは同じではありません。

関連情報：商品マスタ・一括表示・製品規格書を一つのデータへ――取引先別書式との向き合い方

「誰でも作れる」は、自由に文章を書けることではない

私が目指しているのは、知識がなくても自動的に正しい表示が完成する魔法のシステムではありません。

原料規格書、配合、製造条件、検査結果、最新の食品表示基準を確認しながら、必要な情報を漏れなく組み立て、確認者が承認できる仕組みです。

関連情報：食品表示と規格書をExcel・Accessで管理する限界――転記が増え続ける理由

担当者が入力できることと、最終表示の法令適合をシステムが保証することは別です。

私しか分からない状態の問題

• 原材料名をどの順序で入れるかが暗黙知になっている
• 複合原材料をどこまで展開するかの判断が残る
• 添加物とアレルゲンの根拠が画面から分からない
• 過去の表示をコピーしたまま使う危険がある
• 規格書とラベルで別々に修正される
• 私が不在だと変更理由を説明できない

再設計で分けたいデータ

• 原材料マスタ：正式名称、仕入先、規格書、改訂日
• 配合・構成：商品に使用する原料、配合順、使用量
• 複合原材料：構成原料と添加物、表示上の扱い
• アレルゲン情報：根拠資料と確認日
• 栄養成分：分析値・計算値の区分と根拠
• 包装資材：材質、容量、ラベルサイズ、テンプレート
• 出力版：一括表示、規格書、ラベルの承認済み版

作成・確認・承認を分ける

担当者が原料と包装を選び、システムが表示案を生成します。その後、品質管理または責任者が原料規格書、配合、表示面積、最新制度と照合して承認します。

担当者が商品構成を入力
        ↓
システムが一括表示案を生成
        ↓
警告・未確認項目を表示
        ↓
責任者が根拠資料と照合
        ↓
承認済み版として固定
        ↓
ラベル・規格書へ出力

一度承認した後に原料や配合が変わった場合は、承認済み表示を自動で上書きせず、再確認が必要な新しい版を作る設計が必要です。

システムに持たせたい警告

• 原料規格書の確認日が古い
• アレルゲン情報が未確認
• 表示案と配合の版が一致しない
• 必須項目が空欄
• 承認後に商品構成が変更された
• ラベルテンプレートの表示可能範囲を超える可能性

最終判断を人が行うとしても、確認すべき箇所をシステムが示せれば、見落としと属人化を減らせます。

食品表示は必ず最新の公式資料で確認する

制度やQ&Aは更新されます。システム内へルールを固定しきるのではなく、ルールの版、確認日、根拠資料を記録し、更新できる設計が必要です。

• 消費者庁：食品表示
• 消費者庁：食品表示パンフレット

この連載の記事

1. 第1回：ツールから選ぶと沼にはまる――小規模食品メーカーがAccessからブラウザDBへ進んだ理由
2. 第2回：食品表示と規格書をExcel・Accessで管理する限界――転記が増え続ける理由
3. 第3回：kintone・FileMaker・Exment・規格書サービスを検討して分かった――構想から逆算するツール選び
4. 第4回：なぜブラウザベースにこだわるのか――工場のPC・タブレット・OS依存を減らす設計
5. 第5回：Accessの商品マスタをPHP・MySQLへ移した――まだ「引っ越し段階」の食品表示DB
6. 第6回：在庫管理で検証したBrotherブラウザ印刷を、一括表示ラベルへ転用できるか
7. 第7回：何枚印刷したかを残す――ラベル履歴・ロット・商品情報を結ぶ設計
8. 第8回：一括表示を「私しか作れない」から「誰でも作れる」へ――食品表示DBの再設計
9. 第9回：商品マスタ・一括表示・製品規格書を一つのデータへ――取引先別書式との向き合い方
10. 第10回：AIで長年の構想が動き出した――食品現場と技術を横断して組み立てる小規模DX