テックメモ

ロジックでできることにAIを持ち込まない

生産スケジュールの話になると、AIで最適化という言葉が飛び交う。でも、生産スケジューリングの本質はあくまで確定的な計算で、リードタイム、工程順序、設備能力、在庫量といった入力が揃えばロジックで回せる。

AIが力を発揮するのは、認識、需要予測、文脈を踏まえた判断などルールを明文化しきれない領域。逆にロジックで十分なことをAIでやると、結果が確率的になってたまに間違えるし、ブラックボックス化して検証も難しくなる。コストも無駄に高くつく。

AIは万能の上位互換ではなく、ロジックでは届かない領域を補う道具として使ってはじめて価値が出る。

中小製造業の壁は製品マスタにある

ロジックで生産計画を回すにはBOM、工順、標準時間、設備能力といった製品マスタが不可欠で、これらがきちんと整備されていればシステムが計算してくれる。

ところが中小の現場ではこのマスタがほとんど揃っていない。BOMはベテランの頭の中にしかなく、標準時間は勘と経験で決まっている。設計変更があってもマスタは更新されないし、そもそもマスタを作って維持する人がいない。

結果としてロジックで回せるはずの生産計画が回らず、ベテランの属人的な判断に頼り続けることになる。

しかもこれが悪循環していて、マスタ未整備でシステム化できないから人に依存する、でも忙しくてマスタ整備の余裕がない、だからマスタは未整備のまま、という繰り返しになっている。

中小にもAIをという声はあるけれど、マスタが整備されていなければAIもロジックも動かない。AIは魔法ではなく、正しいデータがあってはじめて機能する。

毎月新規品ならマスタ整備は無駄になる

ここでひとつ矛盾にぶつかる。

受注生産で多品種少量、手作業も多い。毎月ほぼ新規品が流れるような世界では、製品単位のマスタを整備しても使い捨てになってしまう。整備のコストが活用効果を上回るので、やる意味がない。

マスタがなければロジックは回らない、でもマスタを作っても使い捨て。完璧に作るか何もしないか、二択に見えてくる。

見積もりデータをそのまま簡易マスタにする

落とし所はマスタの粒度を変えること。

製品単位の完璧なBOMではなく、工程や作業レベルのマスタを持つようにする。製品は毎回違っても通る工程の組み合わせはある程度パターン化できて、切断から曲げ、溶接、塗装、組立といったパターンが実は数十種類に収まることが多い。

そして重要なのが、受注生産なら必ず見積もりをしているという事実。見積もり時に工程と時間と材料をざっくり出しているはずで、新規品であっても簡易的な積算はしている。そのデータをそのまま計画に流せば、それが簡易マスタになる。

現状では見積もりを作って受注したら、あとは現場に図面だけ渡して見積もりデータは死蔵されている。これを計画側に流すだけでよく、追加の作業はほぼゼロで見積もり時の入力フォーマットを少し整えるだけで済む。

完璧なMRP展開こそできないものの、大まかな負荷計画や納期回答の精度向上、ボトルネック工程の把握あたりは十分に回せるようになる。

100点の計画を捨てて、70点の計画を低コストで毎回出せる仕組みにする。現場のベテランが頭の中でやっている、この製品ならだいたいこの工程でこのくらい、という感覚を工程テンプレートとして外出しするイメージ。

実績を返せば精度は勝手に上がっていく

さらに見積もりに対して実績を返してやると、精度が自然に向上していく。

見積もりで溶接3時間と出したけど実績は4.5時間だったとする。次の類似品ではその差分を反映できるので、見積もりの精度が上がれば計画の精度も連動して上がる。

ベテランの頭の中にしかなかった感覚が、見積もりから計画、計画から実績というサイクルを回すことでデータとして蓄積されていく。

ここまで来ると、過去の類似品の見積もりデータを探して参考にする場面でAIが活きてくる。曖昧な条件から似たパターンを引き当てる作業はまさにAIの得意領域で、最初に書いたロジックでできることにAIを持ち込まないという原則の裏返しとして、ここにAIでしかできないことがある。

中小製造業が抱える効率化のジレンマ

受注生産、少量多品種、手作業中心。 このビジネスモデルは顧客の細かなニーズに応えられる強みがある一方、現場の負荷は極めて高い。

こうした環境では、手間はかかるが「いくら儲かっているか見えない」という収益管理の課題が常につきまとう。

どんぶり勘定から抜け出せない理由

製造月の間接費を生産高に応じて正確に配布する原価計算は、多くの中小企業にとって理想論に過ぎない。 現実には、材料費に過去の経験則に基づいた「魔法の倍率」を掛けるだけのどんぶり勘定が横行している。

日報の精度が低く、誰がどの案件に何時間使ったかという工数データが圧倒的に不足している。 家賃や電気代、事務員の給与といった間接費を製品ごとに分ける作業は、膨大な事務手間を要する。

結果として、決算のための会計で手一杯になり、経営判断に使うための管理会計まで手が回っていない。 忙しいのに儲からない理由が不明なまま、言い値で受注を続けているのが実情である。

精度を70点まで引き上げる実戦的な原価計算

教科書通りの厳密な配賦を諦め、事務負担を最小限にして精度を出す方法がある。 それは、すべての経費を時間に集約する「アワーレート」の活用。

前年度の総費用を総労働時間で割り、自社の「1時間あたりの単価」を一度だけ固定して算出する。 これに、現場が15分単位で記録した作業時間を掛け合わせる。

「材料費 ＋（作業時間 × アワーレート）」というシンプルな式だけで、個別の案件が赤字か黒字かが見えてくる。 正確な1分を測るよりも、だいたいの15分を全案件で揃えることの方が、経営判断には価値がある。

機械レートの考え方と機会損失の罠

機械を動かせば動かすほど固定費を回収できるという考え方は、短期的には正しい。 しかし、安売りをしてでも稼働率を上げようとする行為には、大きな落とし穴が潜んでいる。

低いレートの仕事でスケジュールを埋めてしまうと、本来受けるべき高利益の仕事を断る「機会損失」が発生する。 手作業中心であっても、高価な設備を使う工程はレートを分けて考える必要がある。

「やらないよりマシ」な仕事が、実は会社の未来を食いつぶしている可能性がある。 フルコスト（間接費込み）のレートを把握した上で、戦略的に価格を判断する視点が欠かせない。

材料原価における定尺材と端材の扱い

受注生産で悩ましい定尺材や長尺材の扱いは、再利用の可能性でルールを決めるのが合理的。 めったに使わない特殊な材料であれば、たとえ半分余っても定尺1本分を全額チャージする。

汎用的な材料であれば、切り代や端材分を考慮して1.3倍程度の歩留まり係数を掛けて計算する。 この「少し多め」の計上が、端材の管理コストや切り捨てられる部分の補填になる。

材料費だけでなく、重い定尺材をクレーンで運んだり棚から引き出したりする「時間」も、本来は原価に含まれている。 目に見えない労務費が材料費の裏側に隠れている。

在庫が生み出す「幻の利益」の正体

在庫が増えると売上原価が圧縮され、PL上の利益は膨んで見えるマジックが起きる。 しかし、通帳の現金は材料費や給与として既に出ていっており、手元には残っていない。

受注生産であっても、フローの在庫（仕掛品）を利益と見なすのは、確実に現金化できる場合に限定すべき。 現場判断で作った予備や、手が空いたからという理由での前倒し分を利益と捉えるのは危険。

それは利益を稼いだのではなく、今月の経費をBS（資産）に押し込んで「後回し」にしただけ。 「利益はあるのに現金がない」という状態は、こうした在庫への甘い認識から生まれている。

生存を確認するための「資金繰り用簡易PL」

個別原価の計算だけでは、会社全体のキャッシュフローまでは追い切れない。 そこで、当月の売上、仕入れ、支払いを単純に比較する「資金繰り用簡易PL」を羅針盤として活用する。

これは税務署のための書類ではなく、経営者が「今月の稼ぎで飯が食えているか」を知るためのもの。 売上高から、材料・外注費（変動費）と、給与・家賃（固定費の支払い分）を差し引いて、手元に残る現金を算出する。

個別原価で「案件ごとの勝敗」を見極め、簡易PLで「会社全体の生存」を確認する。 このマクロとミクロの二階建て管理が、在庫の増減という会計マジックに惑わされない唯一の道である。

中小製造業における管理の「黄金の落とし所」

資金繰り用簡易PL、材料とアワーレートによる個別原価、そしてフロー在庫の限定的な利益評価。 この3点セットの運用は、中小製造業が到達できる実務上の最高到達点と言える。

これ以上に細かな管理を求めても、事務コストが増えるだけで利益には直結しない。 管理のための管理に陥らず、会社の心拍数と血圧を正しく把握できる仕組みを維持している。

この「中小の限界点」こそが、最も変化に強く、筋肉質な経営スタイルを支えている。

コンサルが売る標準化の正体

なぜ外部コンサルや大手ベンダーは、判で押したように標準化や脱属人化を勧めてくるのか。その正体は、経営層の生産性を上げるための管理ツールに他ならない。

ERPの本質は、グローバルで統一されたKPIをリアルタイムで監視するためのツール。 その透明性を確保するために、現場には大量のデータ入力という不便を強いる構造になっている。

だからこそ、導入には強烈なトップダウンが必要になる。

コンサルが言う標準化は、管理する側にとっては正義だが、現場にとっては手足を縛る鎖になり得る。 この構造を理解せずに導入すれば、現場が疲弊してしまう。

中小製造業の生存戦略は戦略的属人化

特に受注生産・多品種少量の中小製造業において、この標準化は毒になる可能性がある。

中小企業の競争力の源泉はベテランの勘や柔軟な対応力といった属人化された部分にある。 これを標準プロセスに押し込めば、単なる代替可能な工場に成り下がる。

目指すべきは脱属人化ではなく、あえて属人化を許容する戦略的属人化。判断や職人技はそのまま残し、その前後にある情報収集や転記といった雑用だけをAIにやらせる。

ただし、標準化＝悪、属人化＝善という単純な二項対立に陥ってはいけない。

誰がやっても同じであるべき作業は標準化した方が全員が楽になる。一方で、材料の選定判断や加工手順の組み立てのように、経験が品質に直結する領域は属人化を残すべき。

線引きの基準はシンプルで、その作業に判断が伴うかどうか。判断が不要な作業は標準化して手を抜き、判断が必要な領域には属人化を許容して力を集中させる。 この仕分けを現場のベテランと一緒にやることが、戦略的属人化の第一歩になる。

内製エンジニアと情報のワンストップ化

では、具体的にどうシステムを組むべきか。 答えは内製化と入力の一本化にある。

外部ベンダーに頼むと、どうしても管理しやすい標準を押し付けられる。 だからこそ、社内の業務を知る人間、内製エンジニアにAIツールを持たせ、現場の痒いところをかく小さなツールを爆速で作らせるのがいい。

狙うべきゴールは、入力が1回で済むデータの流れ。

現状、営業・技術・製造がそれぞれ別のExcelやシステムに同じデータを打ち込んでいる。 これがミスの温床であり、無駄の極み。

情報の最上流、つまり見積や受注の段階でAIを使ってデータを確定させ、あとはAIがそれを翻訳しながら下流へ流す。 人間は確認と修正だけを行う。

ERPの機能の9割は不要と割り切り、現場の強みを活かすための隙間を埋めるAIを自分たちで作る。 これが2026年現在、最もROIが高いIT投資の形と言える。

キラキラしたAIの話に踊らされず、自分たちの現場を起点に小さく、泥臭く始めること。 それが、2026年のAI活用における最も確実な一歩になる。

AIで本当に成果が出ている領域は限られている

最近はなんでもRAG（Retrieval-Augmented Generation）という風潮がある。社内データをベクトルDBに入れてチャットボットを作れば業務が変わる、という話をよく聞く。

しかし実際にそういったシステムを導入した企業の声を拾ってみると、「探している情報が出てこない」「回答が的外れ」「結局自分で検索したほうが早い」という感想が大半だ。

では、エンタープライズ領域でAIが実際に成果を出しているのはどこなのか。整理してみると、大きく3つに絞られる。

1つ目はコード生成・開発支援。GitHub Copilot、Cursor、Claude Codeのような開発ツールは確実に生産性を上げている。

生成物が間違っていてもコンパイルエラーやテストで即座にわかるため、人間のチェックコストが低い。

2つ目は定型文書の下書き・変換。契約書のドラフト、議事録の要約、翻訳など。80点の出力を人間が100点に直すワークフローが自然に成立する。

3つ目は画像認識・分類。製造業の外観検査や帳票のOCRなど。「正常/異常」の2値判定のように、タスクが明確でAIの出力を目視で検証しやすい領域だ。

この3つに共通しているのは、AIの出力をそのまま使わず、人間が最終判断する前提で設計されているということ。逆に「AIに判断を任せる」方向は、どの領域でもまだ成果が出ていない。

チャットボットが期待外れに終わる構造的な理由

ChatGPTやClaudeのチャットは爆発的に普及し、検索の代替や壁打ちに日常的に使う人は増えた。

これが成功しているのは、ユーザー自身が「間違っているかもしれない」という前提で使っているからだ。間違っていても調べ直せばいいだけで致命的ではない。

ところが企業が「社内RAGチャットボット」を作ると、途端に期待値が変わる。ユーザーは「正確に答えてくれるはず」と思って使う。同じチャット形式なのに、求められるものがまったく違う。

回答の正確性を誰が保証するのか、間違った回答で業務判断した場合の責任は誰が取るのか。そういった問いに答えられないまま導入すると、結局使われなくなる。

皮肉なことに、ChatGPTやClaudeのエンタープライズプランをそのまま社員に使わせたほうがよかった、というケースは少なくないはずだ。RAGで社内チャットボットを自作する理由が「社内データの秘匿性」なら理解できるが、それ以外の動機なら既存のAIチャットで十分なことが多い。

ベクトルDBとRDBは「別の問題を解く道具」

見積RAGシステムを題材に具体的に考えてみる。見積データには材質・径・長さといった数値フィールドと、用途・備考といった自由記述テキストがある。

ベクトル検索が本当に力を発揮するのは、「ポンプ用の軸」と「回転軸（ポンプ向け）」を意味的に近いと判断できるような自由記述テキストの検索だけだ。

材質の完全一致や径の範囲検索はRDBのほうが正確だし、価格のように「1円の狂いも許されない」データを確率的な近さで扱うのはリスクが高い。

結局、ベクトルDBとRDBは優劣ではなく適用領域が異なる。構造化データはRDBで正確に引き、RAGは文章にしか残っていない知見の検索に使う。この使い分けを無視して「全部RAGで」と言うから期待外れになる。

中小製造業にとっての最適解

まず、事務員全員にAIのライセンスを配るのは費用対効果が悪い。PCスキルにばらつきがあり、「何を聞けばいいかわからない」という壁がある。日常業務が定型作業の繰り返しなら、AIに聞く場面がそもそも少ない。

一方で、内製のエンジニアにAIをがっつり使わせて、社内システムを高速で作るというアプローチは噛み合っている。見積管理、在庫・発注管理、作業日報の入力・集計。

こういった「あれば便利だけど外注すると数百万」だったシステムが、エンジニア＋AIで現実的な工数で作れる。業務を理解している人間が作るので要件のズレも少ない。

中小製造業の本当のボトルネックは「やりたいことはあるけど作る人がいない」という部分であり、AIでコーディングが加速するなら、そこが一番効く。

バズワードとの付き合い方

少し前のクラウドやDXと同じパターンで、「全部AIで」という過剰な期待がいずれ幻滅に変わり、最終的に「使う場所を選べば確実に価値がある」という地味な結論に落ち着く。

クラウドが「オンプレとのハイブリッド」に着地したように、AIも「人間とのハイブリッド」に着地するのだろう。

数年後に振り返れば、「コード生成と下書き支援が当たり前になった」というだけの話になっている気がする。それはそれで十分に価値があることだ。

RAGで使われるベクトルデータベースは、従来のSQLとはそもそも解決する問題の種類が違う検索エンジンである。SQLのLIKE演算子が「文字の並び」をパターンで照合するのに対し、ベクトルDBは「言葉の意味」を多次元空間の座標に変換し、座標同士の近さで検索する。一文字も合っていなくても、「犬」と「ドッグ」を同じ近所に配置できるのは、AIが単語の背後にある概念を捉えているからだ。

この「文章を座標（点）にする」仕組みには、特有のルールがある。長い文章をそのまま1つの点にすると意味が薄まってボヤけてしまうため、適度な長さの「チャンク」に細かく刻んで保存するのが定石だ。日本語であれば200〜500文字程度が一つの目安だが、最適な分量は言語・モデル・用途によって変わる。いずれにせよ、数百次元から数千次元に及ぶ計算空間の中で、その情報の個性を鮮明に描き出せるサイズ感を探ることが肝要となる。ただし、この座標は使用する「埋め込みモデル」固有の地図。モデルを変えれば地図の縮尺も方角も変わるため、データは全て計算し直しになる。

文章を点にする際、AIは単語をバラバラにするだけでなく、文脈の「味わい」を数値に凝縮している。例えば「材質：SS、Φ400」という簡素なラベル形式よりも、「材質はSSです。直径は400です」という自然な文章形式の方が、AIにとっては「何が何であるか」の関係性が読み取りやすく、精度の高い座標が打てる。検索時の短い問いかけも同じ空間の点となり、意味の近いチャンクを高速で探し出していく。この「近さ」の測り方にも複数の流儀があり、ベクトルの向きで比較するコサイン類似度、距離で比較するユークリッド距離、内積で比較するドット積など、用途に応じて使い分けられている。

しかし、ここで一つの疑問に突き当たる。データが完璧にクレンジングされ、「材質」や「寸法」が整理されているなら、そもそもベクトルDBを使わずとも、これまでのRDB（関係データベース）の検索で事足りるのではないか。事実、数値の厳密な比較や特定の型番検索において、RDBの正確性とコストパフォーマンスにベクトル検索は勝てない。ただし逆に、構造化されたデータであっても、ユーザーの問いかけが自然言語である限り、「軽い素材」という曖昧な検索語からアルミやチタンを引き当てるような意味の橋渡しは、SQLの得意分野ではない。両者は優劣ではなく、得意な問題の領域が異なるのだ。

この議論を「積算業務へのAI活用」に当てはめると、より現実的な使い分けが見えてくる。1円の狂いも許されない単価の特定や計算に、確率的な「近さ」で答えを出すRAGをそのまま使うのはリスクが高い。積算における理想の形は、正確なスペック検索はRDBに任せ、過去の特記事項や現場の勘所といった「文章の中にしかない知見」をRAGで呼び出すハイブリッドな構成だ。

結局のところ、ベクトルDBは「整理しきれない人間のニュアンス」を扱うための道具であり、議事録や現場報告のような非構造データに対しては、負債の先送りどころか正当な解法となる。一方、美しくクレンジングされたデータセットがあるのなら、無理にベクトル化するのではなく、SQLでスマートに引くのがエンジニアリングとしての正攻法。大切なのは、どちらかを選ぶことではなく、それぞれの土俵を見極めて適材適所で組み合わせることだ。