はじめに：なぜ、素人が「メーカー製」を超えられたのか
わずか数ヶ月前、私のPCの中には空っぽのフォルダしかありませんでした。
それが今、ここにはファイル総数9万、プロジェクト容量約10GB（ビルド生成物含む）にまで膨れ上がった、巨大な生産管理システム「Forge」が存在しています。
完成度は95%。
製番とMRPを融合した複雑な計算エンジン、AIによる図面解析、需要予測、そしてGoogle基準のセキュリティ。これらはかつて、数千万円の予算を持つ大企業だけが許された特権でした。
しかし、その特権は今、崩れ去りました。
プログラミングスキルが一切ない私でも、これを作ることができたのです。
本記事は、中小製造業の現場で戦う私が、Google Gemini（AI）を「CTO」として雇い入れ、業界の長年の課題を技術でねじ伏せた開発の全記録です。
これは単なる技術解説ではありません。「システムを『買う』時代から『創る』時代へ」という、製造業DXのパラダイムシフトの物語です。
1. 核心機能：プロも唸る「製番管理×MRP」ハイブリッドロジック
生産管理システムの世界には、長年解決されない「水と油」の問題があります。
それが、「製番管理（受注生産）」と「MRP（見込生産）」の共存です。
「うちは特注品が多いから製番管理が必須だけど、ネジやボルトみたいな共通部品までいちいち紐付け管理するのは面倒くさい…」
「かといってMRPだけで回すと、どのお客さんの注文に必要な部品なのか分からなくなって、欠品の奪い合いになる…」
多くの中小製造業がこのジレンマに頭を抱え、結果として「高額なERPを入れてカスタマイズ地獄に陥る」か「Excelバケツリレーで凌ぐ」かの二択を迫られてきました。
私が「Forge」で最初に挑み、そして最も苦労して実装したのが、この二つを完全に融合させる「f-MRP (Flexible MRP)」ロジックです
なぜ「混ぜる」のが難しいのか？（ハンバーグとポテトの話）
まずは、なぜこれがプロのエンジニアでも嫌がる難題なのか、料理に例えてみましょう。
- 製番管理（Seiban）：
「Aさん専用の特注ハンバーグ」です。材料のひき肉にも「Aさん用」という名札（製番）を貼り、他の人が勝手に使うことを禁じます。管理は確実ですが、手間がかかります。 - MRP（Material Requirements Planning）：
「ランチタイム用の作り置きポテト」です。必要な総量を予測してまとめて材料を買い、在庫の山から順次使っていきます。効率的ですが、「誰の分か」という紐付きが消えます。
通常のシステムは、どちらか片方の思想で作られています。しかし、実際の現場では「ハンバーグは特注だけど、付け合わせのポテトは作り置き」のように、一つの製品の中で両方が混在します。
これをシステム上で再現しようとすると、「計算ロジックが衝突して破綻する」のがオチでした。
AIと構築した「f-MRP」の正体
Forgeでは、この難題を以下のシンプルなルールを徹底させることで解決しました。
1. 品目ごとの「手配区分」フラグ
全ての部品・製品マスタに、allocationType（手配区分）というフラグを持たせました。
- SEIBAN：親の製番をそのまま引き継ぐ（紐付き）。
- MRP：ここで製番をリセットし、在庫としてまとめる。
2. 再帰的BOM展開と「製番リセット」
ここが実装のキモです。AIに書かせたMRPエンジンは、受注情報を受け取ると、製品の構成部品（BOM）を親から子へと順番に展開していきます。
その際、Forgeのエンジンは毎回「お前は製番品か？それともMRP品か？」と問いかけ、以下のようにIDを書き換えます。
この条件分岐を何階層もの部品構成の中で正確に回すことで、「重要部品はガチガチに管理し、汎用ネジはざっくり管理する」という、現場が本当にやりたかった運用を実現しました。
【失敗談】AIは「空気」を読まない 〜在庫引当の悲劇〜
と、偉そうに書いていますが、最初からうまくいったわけではありません。
開発初期、私はAIに「在庫があったら古い順に引き当てて（FIFO）」とだけ指示しました。すると何が起きたか。
テスト稼働中、「A社用の特注モーター」が、後から来た「B社の定期案件」に勝手に引き当てられてしまうという致命的なバグが発生したのです。
AIは忠実に「古い在庫（A社用）」を「B社の注文」に渡してしまったわけです。AIに「これはA社用だから取っておいて」という人間の常識（空気）は通じません。
そこで私は、プロンプト（AIへの指示）を修正し、以下のようにロジックを変更させました。
- 製番優先（Seiban First）：
まず、その品番の在庫の中に「指定された製番（A社用）」を持つものがあるか検索する。あれば、それを最優先で確保する。 - MRP引当（FIFO）：
製番指定がない、または製番在庫がない場合のみ、製番なし（NULL）の在庫から古い順に引き当てる。
この「優先順位」をコードに落とし込むことで、ようやく現場の感覚と一致する挙動になりました。
納期から逆算する「バックワードスケジューリング」の深淵
もう一つ、AIに実装させて感動したのがスケジュールの自動計算です。
「納期が来月15日なら、いつ作り始めればいい？」という問いに対し、基本式はシンプルです。
着手日 = 納期 - (製造リードタイム + 部材調達リードタイム)これをバックワードスケジューリングと呼びますが、実務で使うには「カレンダー」という魔物を倒さねばなりません。
- 「納期から3日戻ると日曜日だから、金曜日まで戻らないといけない」
- 「工程Aと工程Bは同時進行できるから、長い方に合わせる」
私はAIに「再帰的に日付を遡る際、holidays テーブルを参照して土日祝日ならさらに前倒ししてください」と指示しました。AIは文句も言わず、再帰関数の中にループ処理を組み込み、「土日を華麗にスキップして着手日を決定するロジック」を一瞬で生成しました。
2. 現場の執念：「鋼材・端材管理」と「もったいないロジック」
f-MRPというシステムの「脳みそ」の話の次は、もっと泥臭い、しかし経営者にとってはf-MRP以上に切実な「お金（原価）」の話をしましょう。
鉄工所や板金工場における最大の敵。それは、「半端に残った材料（端材）」です。
「この前の仕事で余った14mmの鉄板、どこに置いたっけ？」
「探すのが面倒だから、新しい定尺（新品）を切っちゃいました」
「えっ、あの端材使えばタダ同然だったのに！」
この会話、日本の製造現場で1日1万回は繰り返されているはずです。
汎用的な生産管理システムやERPは、この「端材（Scrap）」の管理が致命的に苦手です。「不定形な物体」を管理する機能がないからです。
私がForgeで実現したかったのは、この「見えないお金」を拾い上げる仕組みでした。
汎用ERPが逃げ出す「切り板」の重量計算
まず、鋼材には大きく分けて2つの買い方があります。
- 定尺 (Standard)：「3尺x6尺（サブロク）」のように決まったサイズで買うもの。
- 切り板 (Cut Plate)：必要な寸法だけを指定して切ってもらうもの。
システム的に厄介なのは後者です。サイズが無数にあるため、マスタ登録なんてやってられません。現場では「SS400 t14x150x210」のように、呪文のような文字列で注文します。
私はAIにこう指示しました。
「サイズ欄に入力された文字列（例: t14x150x210）を解析して、自動で重量と原価を計算してくれ」
AIが実装したTypeScriptのロジックは、正規表現を使って数値を取り出し、鉄の比重（7.85）を掛けて答えを出します。
// AIが生成したロジックのイメージ
const calculateWeight = (sizeString) => {
// "t14x150x210" から [14, 150, 210] を抽出
const [thickness, width, length] = parseSize(sizeString);
// 体積法で重量算出: 厚み x 幅 x 長さ x 密度
return (thickness * width * length * 7.85) / 1000000;
};これだけで、今まで現場の職人が電卓を叩いていた時間がゼロになり、原価計算のミスも消滅しました。
「シマ板」も「アングル」も自由自在
さらに厄介なのが、「シマ板（滑り止め加工された鉄板）」や「アングル（L字鋼）」です。これらは形状が特殊なため、単純な体積計算では重量がズレます。
既存ソフトだと「対応不可」になる部分ですが、私はAIに「品目マスタに『計算式タイプ』のカラムを追加して」と伝えました。
- 通常鋼材 → 体積 × 7.85
- シマ板 → 体積 × 8.15（滑り止め分重い）
- アングル → 長さ × 単位重量（カタログ値）
この分岐処理を実装したことで、あらゆる鋼材のコストが1円単位で正確になりました。
昭和の美徳をコードにする「もったいないロジック」
そして、Forgeの鋼材管理における真骨頂が、仕様書で「Scrap Logic（もったいないロジック）」と定義した機能です。
これは、新しい製造指示が出たときに、以下のような優先順位で材料を探しに行くアルゴリズムです。
- 端材（Scrap）置き場を検索：「今回の必要サイズ（100×100）を切り出せる、余り物はないか？」を全力で探します。
- 定尺（Standard）在庫を検索：端材がなければ、新品の定尺在庫を引き当てます。
- 発注アラート：定尺もなければ、購買担当に「買ってください」と通知します。
AIとの「板挟み」バトル
この実装時、AIとのやり取りで印象的なエピソードがあります。
最初はAIが「幅と高さが一致する端材」を探すコードを書いてきました。しかし、現実の鉄板は回転させれば使えることもあります。
「幅100が必要なら、在庫が『幅100』じゃなくても『長さ100』あれば回して使えるだろう！」
そう指摘すると、AIはハッとしたように（？）条件式を修正しました。
-- AIが修正した「回転考慮」の検索クエリ
WHERE
(width >= required_W AND length >= required_L) OR
(width >= required_L AND length >= required_W) -- 90度回転！このたった1行の「OR条件」が追加されたことで、ゴミ箱行き寸前だった端材が、次々と有効活用されるようになりました。
3. AIの真骨頂：図面解析（Vision）と需要予測（Prophet）
生産管理システムと聞くと、「人間がキーボードを叩いてデータを入力する箱」を想像します。
しかし、私が目指したのは、その「人間による入力」そのものを消し去ることでした。
なぜなら、製造現場におけるミスの9割は「見間違い」と「打ち間違い」だからです。
そこで私は、最新のAI技術である「Vision（視覚）」と「Prophet（予言）」をシステムに組み込みました。
「定規と電卓」を捨てる日：AI図面解析 (Vision)
製造業の事務員さんの机には、必ず定規が置いてあります。図面の寸法を読み解き、システムに手打ちする「BOM起こし」は重労働です。
Forgeでは、この作業を「ドラッグ＆ドロップ」だけにしました。
Gemini Visionが「図面を読む」
GoogleのGeminiなどのマルチモーダルAIは、画像を「見る」ことができます。
しかし、ただ「読んで」と言うだけでは使い物になりません。私は何度も試行錯誤し、以下のような「AIへの指示（プロンプト）」を完成させました。
/** 実際のプロンプト（要約） */
あなたは熟練の製造エンジニアです。この図面画像から以下の情報を抽出し、JSON形式のみを出力してください。
1. 材質: 'SUS304', 'SS400' などのJIS記号を探せ。見つからない場合は null を返せ。推測するな。
2. 寸法: 外形の最大寸法（W x H）を探せ。
3. 注意点: 手書き文字が乱雑で読めない場合は、無理に解釈せず uncertain: true フラグを立てよ。この「推測するな」「nullを返せ」という指示が重要です。AIに知ったかぶりをさせないことで、実務で使える精度になりました。
AIの「誤読」をどう防ぐか？
とはいえ、AIも完璧ではありません。特に「l (小文字エル)」と「1 (イチ)」の見間違いは起こります。
そこでForgeでは、AIの回答をそのまま信じるのではなく、「正規表現（Regex）」による防波堤を設けました。
- 材質欄に
SUS-304（ハイフン入り）と返ってきたらSUS304に自動修正する。 - 寸法に異常な値が入っていたらアラートを出す。
それでも、「ゼロから手入力」するのに比べれば、作業時間は10分の1以下。これが実装された瞬間、私は本気で「事務仕事の終焉」を感じました。
「勘と経験」をデータに変える：AI需要予測 (Prophet)
もう一つの未来機能が、「需要予測」です。
発注業務は、常に「在庫切れ（機会損失）」と「過剰在庫（キャッシュフロー悪化）」の恐怖との戦いです。
そこで導入したのが、Meta社が開発した時系列予測ライブラリ「Prophet」です。
「環境構築」という最大の壁
正直に言うと、ここが開発の最難関でした。Forgeの本体はNext.js（JavaScript）ですが、ProphetはPythonで動きます。
私はここでもAIに助けを求めました。
「Pythonで簡単なAPIサーバーを立てて、Dockerコンテナで同居させましょう」
AIが書いたDockerfileをコピペして実行すると、黒い画面に文字が流れ、魔法のように予測エンジンが動き出しました。
「信頼区間」という名の優しさ
Forgeは毎日深夜、過去3年間のデータを学習し、来月の発注数を予測します。
Prophetは「季節性（Seasonality）」を考慮するため、「毎年8月はお盆で減る」といったパターンも検知します。そして、結果は以下のように表示されます。
- 予測需要：150個
- 信頼区間 (80%)：130個 〜 170個
- 判定：「少なくとも 130個 は確保してください。攻めるなら170個です」
AIは「絶対に150個だ！」とは言わず、「だいたいこの範囲（信頼区間）に収まるよ」と幅を持たせてくれます。この設計が、発注担当者のプレッシャーを劇的に下げてくれるのです。
4. 現場DX：タブレットとQRコードで回す「紙のいらない工場」
高機能なf-MRPやAI予測機能ができても、それを現場で使ってもらえなければ意味がありません。
油汚れと騒音にまみれた現場で、「PCで入力してください」というのは暴論です。
だからこそ、Forgeは徹底して「PCレス」と「現場ファースト」にこだわりました。
「紙」は捨てない、役割を変える
Forgeでは、紙をなくすのではなく、紙を「デジタルの入り口」に変えました。
システムから印刷される作業指示書には、大きなQRコードが印字されています。
現場の作業員が行うのは、これだけです。
- 指示書のQRコードを、手持ちのデバイスで「ピッ」とスキャンする。
- その作業の「専用画面」がブラウザで一発起動する。
- 画面には、最新の図面と「開始」「完了」の超巨大なボタンだけが表示される。
「軍手」でも押せるUI
私がAIにモバイル画面のコードを書かせた時の指示はこうです。
「機能はいらない。ボタンは画面の半分くらいの大きさにしてくれ。軍手をしたままでも、絶対に押し間違えないサイズだ」
このデザインにより、ITアレルギーのある職人でも使えるツールになりました。デバイスも高価な専用機は不要。AmazonのFireタブレットや中古のiPadで十分です。アプリのインストールすら不要なWebアプリ（Next.js）だからです。
ワンタップで終わる「バックフラッシュ」の魔法
作業員が「完了」ボタンをタップした瞬間、裏側では「バックフラッシュ (Backflush)」という処理が走ります。
これは、「完成品ができたなら、材料も使ったはずだ」という理屈で、在庫を自動的に引き落とす機能です。
マイナス在庫も「許容」する優しさ
もし実在庫が足りなかったら？
Forgeはエラーを出して作業を止めることはしません。「マイナス在庫」として一旦処理を通し、アラートだけを管理者に飛ばします。
「データが合わないから仕事ができない」という本末転倒を防ぐため、「現場の動きを止めない」ことを最優先に設計しました。
5. 信頼性の壁：自動バックアップとセキュリティは「素人仕事」ではない
「個人が作ったシステムなんて、怖くて会社の命運を預けられない」
そう感じる経営者も多いでしょう。しかし、Forgeは一昔前の「自作ソフト」とは違います。AIは最初から「エンタープライズ（大企業）基準」の構成を提案してきました。
サーバーレスDB「Neon」と「パラレルワールド」
Forgeのデータは、Neonという最新のクラウドデータベース上にあります。AmazonやGoogleのインフラ上で動く要塞です。
Neonを採用した最大の理由は、「ブランチ（Branching）」機能です。
これは、ボタン一つで「本番データの完全なコピー」を一瞬で作成できる機能です。
私はAIに指示してブランチを作成させます。そこはいわば「パラレルワールド」。どれだけデータを壊しても本番には影響しません。この安全な実験場があるからこそ、素人でも恐れずに開発を続けられるのです。
午前2時の「完全自動バックアップ」と「復旧訓練」
Forgeは毎日、工場が眠っている深夜02:00に密かに目を覚まします。
自動スクリプトが走り、データベースのスナップショットを作成し、それをGoogle Driveの指定フォルダに転送します。
【バックアップの鉄壁ルール】
- オフサイト保存：工場が火事になっても、データはGoogleのサーバーに残る。
- 7世代管理：過去一週間分のデータを保持。
「戻せないバックアップ」はゴミである
しかし、重要なのは「戻せること」です。
私は開発中、わざと本番データを全消去し、Google Driveのバックアップから復旧させる「避難訓練」を行いました。
AIにコマンドを聞きながら実行し、わずか10分でシステムが元通りになった瞬間、本当の意味での「安心」を手に入れました。
「パスワードを作らない」という最強のセキュリティ
情報漏洩の原因は「安易なパスワード」です。だからForgeにはパスワードがありません。
代わりに採用したのが、Google OAuth（Googleでログイン）です。
社員はGoogleアカウントでログインするだけ。退職者が出たら、Google Workspace側でアカウントを停止すれば、即座にシステムに入れなくなります。
6. 開発の裏側：AIを「CTO」に据えたアジャイル開発の極意
「非エンジニアがAIで作ったコードなんて、中身はぐちゃぐちゃなんじゃないか？」
そう疑うエンジニアもいるでしょう。しかし、Forgeのコードは驚くほどモダンで、堅牢で、美しいのです。
なぜなら、私は開発初期にAI（Gemini）にこう宣言したからです。
「私は素人だ。だから技術的な意思決定権はすべて君に譲る。君がCTO（最高技術責任者）として、世界で最もイケてる技術選定をしてくれ」
AIが選んだ「最強の武器」たち
AI CTOが選定したアーキテクチャは以下の通りです。
- フレームワーク：Next.js 14+ (App Router)
- 言語：TypeScript
- バックエンド：Server Actions
「Server Actions」という発明
以前のWeb開発では、APIサーバーを立てるのに数日かかっていました。
しかし、AIが選んだServer Actionsは革命でした。「注文ボタンを押した時の処理」を関数として書くだけで、サーバー側で実行してくれます。
| Before | After |
|---|---|
| API設計に3日かかる | 関数一つ書くだけで3分で終わる |
この圧倒的な工数短縮が、個人開発者が「週末だけで新機能」をリリースできる秘密です。
鬼軍曹「TypeScript」の指導
AI CTOが導入した最も厳しいツールがTypeScriptです。これはコードに「型（Type）」というルールを設けるものです。
例えば、「受注データには納期が必要」と定義すれば、納期を入れ忘れたコードは「エラー！」と赤くなり、実行すらさせてくれません。
「書いている時点でバグを防ぐ」。このプロの常識を、AIは私に強制したのです。
「仕様書」こそがプログラミング言語
この開発を通じて、私の役割は完全に変わりました。
私は今、コードではなく「日本語の仕様書」を書くことに全精力を注いでいます。
### 3.4 鋼材管理
- **切り板**: "t14x150x210" のような文字列を入力。
- **計算式**: 厚み × 幅 × 長さ × 密度(7.85) / 1,000,000これをAIに読み込ませて「実装して」と頼むだけ。AIは完璧な計算ロジックを生成します。
私が書くのは自然言語（日本語）ですが、それはAIにとって、どんなプログラミング言語よりも正確なコードなのです。
結論：生産管理システムは「買う」から「創る」時代へ
こうして私のPCの中には、ファイル総数9万、プロジェクト容量約10GB（ビルド生成物含む）にまで膨れ上がった、巨大な生産管理システム「Forge」が誕生しました。
プログラミングスキルが一切ない私でも、これを作ることができたのです。
この連載の最後に、私がこの「冒険」を通じて得た、たった一つの確信をお伝えします。
「合わせる」苦しみから、「合わせさせる」自由へ
これまで、中小製造業は「パッケージソフトに業務を合わせる」しかありませんでした。
「ウチのやり方は特殊だから…」と言っても、「仕様です」とあしらわれる。仕方なく現場が汗をかく。
しかし、AIを手にした私たちは、逆のアプローチが可能になりました。
「システムを、私たちの業務に合わせさせる」のです。
- 「端材をもったいない精神で使いたい」なら、そう動くロジックを作ればいい。
- 「軍手でボタンを押したい」なら、巨大なボタンを作ればいい。
これらを実現するのに、追加費用は1円もかかりません。
最強の武器は「コード」ではなく「ドメイン知識」
これからの時代、システム開発において最も価値があるのは、プログラミング能力ではありません。
「現場の何が問題で、どうなれば幸せになれるか」を知っていること。
つまり、あなたが長年培ってきたドメイン知識（業務知識）こそが、最強の武器になります。
AIは「How（どう作るか）」においては天才ですが、「What（何を作るか）」を決めることはできません。それを決められるのは、毎日現場で戦っているあなただけなのです。
次なるステップ：泥臭い「並行稼働」の覚悟
今後の計画として、いよいよ実データを用いた並行稼働テストへ移行します。
ただし、いきなり切り替えるような無茶はしません。最初の1ヶ月は、これまでの「紙の伝票」も捨てずに両方回します。
もしシステムと紙で計算がズレたら？ 迷わず紙を信じます。
それくらいの慎重さで、職人さんの信頼を一つずつ勝ち取っていく。
バグが出たら、「3分で直します」と言ってその場でAIと修正する。この泥臭い高速改善サイクルこそが、内製化の醍醐味であり、成功への唯一の道です。
さあ、あなたの番です
もしあなたが、「ウチの会社を変えたい」と思っているなら。
今すぐ、GeminiやChatGPTを開いて、こう打ち込んでみてください。
「私はこういう業務をしていて、こんなことで困っている。これを解決するWebアプリを作りたい。設計図を書いて」
そこから、あなたの「Forge」作りが始まります。
生産管理システムは、もう「買う」ものではありません。
あなたの手で、AIと共に「創る」ものです。
- 【完全無料】Google Antigravityl Cursorの代わりになる? 非エンジニアがGemini 3 Proで開発してみた本音
- 【脱・挫折】知識ゼロの私がAIとペアプログラミング! 自作Webツールを 「Windowsアプリ」にするまでの全記録
- 知識ゼロの私が、Al (Cursor)と会話しただけで 「LINEスタンプ全自動生成アプリ」を爆誕させた話
この記事へのコメントはありません。