AIで長年の構想が動き出した――食品現場と技術を横断して組み立てる小規模DX

商品マスタ、一括表示、規格書、ラベル印刷を一つにつなげたいという構想は、生成AIが普及する前からありました。

関連情報：ツールから選ぶと沼にはまる――小規模食品メーカーがAccessからブラウザDBへ進んだ理由

ただし、構想があっても実装する時間がありませんでした。

プレイングマネージャーには、まとまった開発時間がない

小規模食品メーカーの経営では、製造、営業、仕入れ、品質対応、経理、労務、設備修理などが同時に発生します。

システム開発だけに数週間集中することは難しく、Accessの商品マスタとラベル出力を作った後も、規格書統合の構想は長く残ったままでした。

ブラウザへ移行すると決めても、認証、データベース、画面、帳票、印刷、バックアップまで一人で作るには負担が大きく、まずAccessの機能を引っ越すところで止まっていました。

AIが変えたのは、構想ではなく実装速度

AIが商品情報の関係や現場運用を自動的に理解して、完成形を決めてくれたわけではありません。

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

どの情報を正本にするか、誰が入力し誰が承認するか、ラベル印刷をどこへつなぐか、現場でタブレットをどう使うかは、業務を知る側が決める必要があります。

AIによって大きく変わったのは、構想をコードへ落とす速度です。

• 既存コードを読み解き、移行案を比較する
• DB設計やAPIのたたき台を作る
• 画面、バリデーション、ログ処理を実装する
• エラー原因を整理し、修正候補を試す
• 仕様書やテスト項目を文章化する

これまで時間不足で止まっていた構想を、小さな単位へ分けて実装できるようになりました。

横断的に触ってきた経験が、構想をつなぐ

私は特定の技術分野を専門として深く掘り続けてきた専業エンジニアとは異なります。

一方で、食品製造の業務、ハードウェア、ラベルプリンター、ネットワーク、Linuxサーバー、Web、データベースを必要に応じて横断して触ってきました。

そのため、次のような境界を一つの運用として考えられます。

食品表示と規格書の要件
        ↓
商品・原材料データの構造
        ↓
ブラウザの操作画面
        ↓
サーバー・認証・バックアップ
        ↓
Windows印刷エージェント
        ↓
Brotherラベルプリンター
        ↓
製造ロットと履歴

一つひとつで最先端を目指すのではなく、現場で使えるところまでつなぐ。その役割を「現場実装型エンジニア」と表現しています。

AIを使えば誰でも完成するわけではない

AIが生成したコードは、誤り、安全上の問題、保守しにくい構造を含むことがあります。食品表示の内容についても、AIの回答をそのまま採用できません。

実装後には、コードレビュー、権限確認、バックアップ、テスト、実データとの照合が必要です。食品表示は原料規格書、配合、最新の公式資料に基づいて人が最終確認します。

AIは責任を引き受ける存在ではなく、設計者と現場担当者の作業速度を高める道具です。

まず公開し、事実に合わせて更新する

この連載で紹介しているシステムは現在も開発中です。画面や構成は今後変わります。

完成を待ってから書くと、なぜその設計になったのか、どこで詰まったのかという過程が失われます。そのため、現在地を明確にしたうえで一度公開し、実装が進んだら画面、図、結果を追記します。

更新時には、記事冒頭または末尾へ更新日と変更内容を残し、当時の判断と現在の構成を混同しないようにします。

この方法がすべての会社の正解ではない

既製サービスを使う方が安全で早い会社もあります。FileMakerやkintoneが運用に合う会社、Exmentで十分に構築できる会社、規格書サービスを中心に据える会社もあります。

当社は、少人数、多品種小ロット、自前サーバーを扱えること、独自の帳票と印刷連携が必要なことを踏まえ、現在の構成へ進んでいます。

同じように、現場業務をしながら「既存サービスだけではつながらない」「自作するには重い」と悩んでいる小規模事業者にとって、この試行錯誤が一つの判断材料になればと思います。

この連載の記事

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