テックメモ

ロジックで解ける問題と、AIが必要な問題を分けて考える

生産スケジューリングは本来、確定的な計算で成立する領域が大きい。リードタイム、工程順序、設備能力、在庫量といった入力データが揃えば、ロジックで対応できる部分が多い。

一方、AIが力を発揮するのは、認識や需要予測、文脈判断など、ルール化が難しい領域になる。ロジックで対応できる領域にAIを持ち込むと、結果が確率的になって検証しにくくなる上、コスト負担も増える。

自分の考えとしては、AIはロジックの上位互換ではなく、ロジックの限界を補完する道具。この使い分けを意識しておくと、どこにAIを使うべきかの判断がしやすくなる。

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

生産計画をロジックで組むには、BOM（部品表）・工順・標準時間・設備能力といった製品マスタが必要になる。しかし、自分が見てきた中小の現場では、これらがきちんと整備されているケースはほとんどない。

BOMはベテランの頭の中にあり、標準時間は勘と経験で回している。この状態では、AIであろうとロジックであろうと、システムとして動かすための入力データがそもそも足りない。

そして、これが悪循環になる。マスタが未整備だからシステム化が進まず、人に依存する。繁忙期にはマスタ整備に手を割く余裕がなく、いつまでも着手できない。

受注生産・多品種少量ではマスタ整備が報われにくい

受注生産で多品種少量の場合、製品単位でマスタを整備しても、その製品をもう作らないかもしれない。整備コストに対して活用機会が少なく、完璧なBOMを構築するか、あきらめるかの二択に見えてしまう。

自分もこの壁には何度もぶつかった。製品マスタを真面目に作ろうとすると工数が膨れ上がり、かといって何もしなければ計画はベテラン頼みのまま。この二択から抜け出す方法はないかと考えた結果、たどり着いたのが次のアプローチだった。

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

発想の転換は「粒度を変える」こと。製品単位の完璧なBOMではなく、工程・作業レベルのマスタを構築する。

ここで着目したのは、受注生産なら必ず見積もりをしているという事実。見積もり時には、工程・時間・材料の概算を既に出している。このデータを計画にそのまま流用すれば、追加作業をほとんどかけずに簡易マスタとして使える。

現状では、見積もりデータは見積もりのためだけに使われ、その後は死蔵されていることが多い。これを計画側に流す仕組みを内製で作れば、「マスタ整備」という重い作業をせずに、大まかな負荷計画や納期回答の精度向上、ボトルネック工程の把握に使える状態が作れる。

完璧なMRP展開には届かないが、中小の現場が本当に必要としているのは、完璧な計画よりも「大きく外さない見通し」であることが多い。

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

見積もりに対して実績を返す仕組みを組み込むと、精度が自然に向上していく。「溶接3時間の見積に対して実績は4.5時間だった」という差分が蓄積され、次の類似品の見積もりに反映される。

この見積→計画→実績のサイクルを回すことで、ベテランの頭の中にあった暗黙知が、少しずつデータとして形になっていく。標準時間を一から測定するのではなく、日々の業務の中で自然にデータが溜まる構造を作るという考え方になる。

そして、このサイクルが回り始めたとき、初めてAIが本当に効く場面が出てくる。過去の見積もり・実績データから類似パターンを検索し、曖昧な条件でも近い事例を見つけ出す。これはルールベースの検索では難しく、AIならではの仕事になる。

まとめ：データの流れを先に作り、AIは後から効かせる

中小製造業にとって現実的なのは、いきなりAIを導入することではなく、まず見積もりデータを再利用できる流れを作ること。見積→計画→実績のサイクルが回り始めれば、データが自然に蓄積され、その先にAIを活かせる土壌ができる。

自分が内製で取り組んできた経験からすると、この仕組みは大がかりなシステムでなくても実現できる。見積管理と実績入力をつなぐ小さなツールから始めて、データが溜まった段階で類似検索にAIを組み込む。この順番が、中小の体力に合ったやり方だと考えている。

収益が見えにくいという構造的な課題

受注生産・多品種少量・手作業中心のビジネスモデルは、顧客の個別ニーズに応えられる強みがある。一方で、案件ごとに内容が異なるため「結局いくら儲かっているのか」が見えにくいという課題を抱えやすい。

自分がこれまで関わってきた中小製造業の現場でも、この問題は共通して存在していた。そしてこの「見えにくさ」に対してどこまで管理の手間をかけるかの落とし所を見つけることが、現実的な経営判断の一つになっている。

原価が見えにくい背景

厳密な原価計算を目指すと、工数の記録精度、間接費の配賦ロジック、材料の按分など、事務負荷が急激に上がる。自分が見てきた範囲では、多くの現場が材料費に経験則の倍率を掛ける程度の管理で回しているのが実態だった。

これは怠慢ではなく、合理的な判断の結果であることが多い。日報の精度が十分でなく工数データが揃わない中で、間接費を製品ごとに分ける作業は膨大な事務手間を要する。「決算のための会計で手一杯」という声は珍しくなく、原価管理にまで手が回らないのが正直なところだろう。

70点の精度を目指すアワーレート方式

自分が現実的だと考えるのは、100点の精密さを捨てて70点の実用的な精度を取るアプローチ。その具体的な方法がアワーレートの活用になる。

やり方はシンプルで、前年度の総費用を総労働時間で割り、「1時間あたりの単価」を固定する。現場が15分単位で記録した作業時間にこのレートを掛け合わせれば、個別案件の採算性が見えてくる。

式にすると 「材料費 ＋（作業時間 × アワーレート）」 だけ。1分単位の精密な計測よりも、全案件を15分単位で揃えて比較できることの方が、経営判断には役立つ。

この計算は、Excelでも内製の簡単なツールでも仕組み化できる。大事なのは計算方法そのものよりも、全案件に同じ物差しを当てて「勝ち案件」と「負け案件」の傾向を把握すること。

機械レートを分けるべき場面

手作業が中心の工場でも、特定の工程で高価な設備を使っている場合がある。このとき、設備を使う工程と手作業工程を同じアワーレートで計算すると、設備工程の原価が過小評価されてしまう。

高価設備を使う工程については、設備の償却費や維持費を加味した機械レートを別に設定する方が実態に近い。

もう一つ意識しておきたいのが機会損失の視点。稼働率を上げようとして低レートの案件を受注すると、その設備が埋まっている間に高利益の案件を断ることになり得る。フルコストを把握した上で、戦略的に受ける・断るを判断するという考え方が重要になる。

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

材料原価の計算で悩ましいのが、定尺材を切り出して使う場合の端材の扱い。自分は再利用の可能性で割り切るのが現実的だと考えている。

特殊材で他の案件に流用しにくい場合は、半分余っても全額をその案件にチャージする。汎用材で再利用が見込める場合は、歩留まり係数（1.3倍程度）を掛けて計算する。厳密な端材管理は手間に見合わないことが多く、このくらいのルールで十分に回る。

なお、定尺材の運搬にかかる時間コストも原価に含めておくと、見積もりの精度が上がる。現場では「材料を取りに行く時間」が意外と馬鹿にならない。

在庫が利益を膨らませる仕組みを理解しておく

これは原価管理とは少し角度が異なるが、中小製造業の経営者に知っておいてほしい話として書いておく。

在庫が増加すると、会計上の売上原価が圧縮され、利益が大きく見えることがある。しかし現金は材料購入時に出ていっており、手元に残っているわけではない。利益が出ているのに資金が回らないという状況は、この構造から生まれることが多い。

受注生産であっても、先行手配や予備としての在庫は発生する。在庫を持つこと自体が悪いわけではないが、「確実に現金化できる見込みがある」在庫と「念のため持っている」在庫を区別しておくことは、資金繰りの見通しを立てる上で重要になる。

簡易PLで会社全体の生存を確認する

個別原価計算は「案件ごとの勝ち負け」を見るための道具だが、それだけでは会社全体のキャッシュフローは追い切れない。

自分が勧めているのは、当月の売上から変動費（材料費・外注費）と固定費の支払い分を引いて、手元現金の見通しを出す簡易PL。これにより、個別原価で「案件の勝敗」を、簡易PLで「会社全体の生存」を確認するという二階建ての管理ができる。

この簡易PLは、仕組みとしてはシンプルなので内製で十分に対応できる。売上データと仕入データが整理されていれば、集計の自動化もそれほど手間ではない。

まとめ：管理の落とし所

自分がたどり着いた中小製造業における管理の落とし所は、次の3つのセット運用になる。

1. アワーレートによる個別原価 ── 案件ごとの採算を70点の精度で把握する
2. 簡易PL ── 会社全体の資金繰りの見通しを月次で確認する
3. 在庫の限定的な評価 ── フロー在庫に限定し、会計上の利益と実態のズレを防ぐ

これ以上細かい管理に踏み込むと、事務コストが経営判断の改善に見合わなくなるケースが多い。逆に、この3つが回っていれば、会社の状態を大きく見誤ることはないと思っている。

会社の心拍数と血圧を把握できる仕組みを持つこと。変化の激しい環境で生き残るには、精密な計器よりも、すぐに読めて継続的に使える計器の方が役に立つ。

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

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

ERPの本質は、部門ごとにバラバラだったデータと業務プロセスを一つのシステムに統合すること。営業・製造・経理が同じデータを見て動ける状態を作るのが本来の目的であり、それ自体は正しい思想と言える。ただし、その統合を実現するために、現場には標準化されたフォーマットでのデータ入力が求められる。この入力負荷が、特に人手の少ない中小企業にとっては重くのしかかる。

ERP自体が悪いわけではない。拠点が複数あり、管理層がリアルタイムで数字を見なければ回らない規模の会社にとっては、標準化のコストを払うだけの見返りがある。

問題は、この構造をそのまま中小企業に持ち込むことにある。中小企業に数千人規模の会社と同じ管理体制を敷いても、入力コストだけが膨れ上がり、現場が疲弊する。コンサルが言う標準化は、管理する側にとっては正義だが、現場の規模や体力を無視すれば、手足を縛る鎖になり得る。

属人化は本当に悪か

「属人化は危険」という指摘は正しい。特定の誰かがいなくなったときに業務が止まるなら、それは経営上のリスクに他ならない。

しかし、すべての属人化を同列に扱うのは間違っている。

中小製造業において、ベテランの勘や柔軟な対応力こそが競争力の源泉であることは多い。音で機械の異常がわかる、この客はこういう仕上げを好むと知っている、材料を見れば加工の段取りが頭に浮かぶ。こうした暗黙知を標準プロセスに押し込めようとすれば、膨大なコストがかかる上に、結局マニュアル通りにはいかない現実にぶつかる。

目指すべきは「脱属人化」でも「属人化の肯定」でもなく、属人化のトリアージ。つまり、どの知識が消えたら致命傷になるかでランク分けをして、対処の優先度を決めることにある。

属人化のトリアージ

即死リスク：絶対に属人化してはいけない領域

システムの管理者パスワード、サーバーの構成情報、基幹業務が止まるプロセスの手順。これらが特定の1人の頭の中にしかない状態は、戦略ではなくただの怠慢。

ここは最優先で文書化・共有する。コストがかかるとかの問題ではなく、この人が明日いなくなったら会社が止まるかどうかで判断する。

重傷リスク：段階的に共有すべき領域

見積もりのロジック、主要取引先との暗黙の取り決め、特殊工程の段取りノウハウなど。完全なマニュアル化は現実的ではないが、判断の根拠だけでも記録しておけば、引き継ぎ時のダメージは大幅に軽減される。

ここは「完璧な手順書」ではなく「なぜその判断をしたか」のメモで十分。

打撲リスク：属人化を許容してよい領域

現場のベテランの微調整、経験に基づく加工順序の組み立て、長年の付き合いで成立している取引関係。これらを標準化するコストは、中小企業の体力では回収できないことが多い。

ここに無理やり標準化を持ち込むくらいなら、その時間とコストを即死リスクの解消に使った方がいい。

線引きの基準

属人化を残すか潰すかの線引きは、その作業に判断が伴うかどうかだけでは足りない。もう一つ、その人がいなくなったとき何が起きるかという視点が必要になる。

判断が不要で、かつ誰がやっても同じであるべき作業は標準化する。判断が必要で、かつ代わりがすぐ見つかる領域は属人化を許容する。判断が必要で、かつ代わりがいない領域は、判断そのものではなく判断の根拠を共有する。

この仕分けを現場のベテランと一緒にやることが、トリアージの第一歩になる。

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

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

外部ベンダーに頼むと、管理しやすい標準を前提としたパッケージを提案されがちになる。それが自社に合えば問題はないが、合わない場合は現場が運用で帳尻を合わせることになる。

社内の業務を知る人間、内製エンジニアにAIツールを持たせ、現場の痒いところをかく小さなツールを作らせるというアプローチは、中小にとって現実的な選択肢の一つになる。

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

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

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

ERPでそれを実現できるなら、ERPを使えばいい。ただ、中小の現実としては、既存のExcelや小さな内製ツールの組み合わせで同じことを安く実現できるケースも多い。大事なのはツールの選択ではなく、データが1回の入力で流れる構造を作ること。

キラキラしたツールやAIの話に踊らされず、自分たちの現場を起点に、まずは即死リスクの洗い出しから小さく始めること。それが、属人化と向き合う最も確実な一歩になる。

AIで成果が出やすい領域、出にくい領域

RAG（Retrieval-Augmented Generation）への注目が高まっている。社内データをベクトルDBに入れてチャットボットを作れば業務が変わる、という話を耳にする機会も増えた。

一方で、自分が見聞きする範囲では、社内RAGチャットボットで明確な成果を上げている中小企業はまだ少ない。「探している情報が出てこない」「回答が的外れ」「結局自分で検索したほうが早い」という声は珍しくなく、期待と実態のギャップに戸惑っている現場は多いように感じる。

では、現時点でAIが実際に成果を出している領域はどこか。自分の経験では、大きく3つに絞られる。

1. コード生成・開発支援 ── GitHub Copilot、Cursor、Claude Codeなど。生成物の誤りはコンパイルやテストで即座に判明するため、人間のチェックコストが低い。自分自身、内製開発でこの恩恵を日常的に受けている。

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

3. 画像認識・分類 ── 製造業の外観検査や帳票のOCR。タスクが明確で、出力の検証が容易な領域。

これらに共通するのは、AIの出力をそのまま使うのではなく、人間が最終判断する前提で設計されていること。逆に言えば、AIに判断そのものを委ねる方向では、どの領域でもまだ安定した成果が出ていないのが実情だと思う。

社内チャットボット導入で見落とされがちなポイント

ChatGPTやClaudeは個人ユースで広く使われている。ユーザー自身が「間違っているかもしれない」という前提で使うため、多少の誤りは問題にならない。

しかし企業が社内RAGチャットボットとして導入すると、ユーザーの期待値が変わる。「会社が用意したシステムだから正確に答えてくれるはず」という前提で使い始める。ここにギャップが生まれやすい。

見落とされがちなのは、次のような問いへの回答を事前に用意しておく必要があること。

• 回答の正確性を誰がどう担保するのか
• 間違った回答に基づいて業務判断した場合の責任の所在

これらを曖昧にしたまま導入すると、現場は不安を感じて使わなくなる。社内の秘匿情報を扱う必要がない範囲であれば、既存のAIチャット（ChatGPTやClaudeのエンタープライズプラン）をそのまま使う方が、コストも運用負荷も軽いケースは多い。

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

ここは技術的な話になるが、RAGの導入判断に直結するので整理しておきたい。

見積管理を例に考える。見積データには、数値フィールド（材質・径・長さ）と自由記述テキスト（用途・備考）が混在している。

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

一方、材質の完全一致や径の範囲検索はRDB（リレーショナルデータベース）の領域。価格のように「1円の狂いも許されない」データを、確率的な類似度で扱うのはリスクが高い。

つまり、構造化データはRDBで正確に検索し、RAGは文章にしか残っていない知見の検索に使う。この使い分けが共有されないまま「とりあえず全部RAGで」と進めてしまうと、期待と実態のギャップが生まれやすい。逆に、適材適所で組み合わせれば、RAGは確かに価値のある技術になる。

中小製造業にとってAIが最も効くポイント

AI活用というと「全社員にAIツールを配る」というアプローチが思い浮かびやすい。それ自体が間違いとは言わないが、中小製造業の現場では、PCスキルのばらつきや「何を聞けばいいかわからない」という壁があり、投資に見合った効果を引き出すには工夫が要る。

自分が実感として最も効果が大きいと考えるのは、別のアプローチ。業務を理解している内製エンジニアが、AIを活用して社内システムを高速開発することにある。

見積管理、在庫・発注管理、作業日報の入力・集計。こうした「外注なら数百万かかるシステム」を、業務を知る人間がAIの力を借りて自分で作る。要件定義のズレが起きにくく、現場に合ったものが出来上がる。

中小製造業の本当のボトルネックは「やりたいことはあるけど作る人がいない」という点であることが多い。ここにAIが効く。コードを書く能力のハードルをAIが大幅に下げてくれるため、業務に精通した人間が開発者を兼ねるという選択肢が、以前よりずっと現実的になっている。

バズワードに振り回されないために

「全部AIで」という期待が膨らむのは、かつてのクラウドやDXブームと同じ構造に見える。過剰な期待のあと幻滅期が来て、最終的に「使う場所を選べば確実に価値がある」という地味な結論に落ち着く。

クラウドが「オンプレとのハイブリッド」に着地したように、AIも「人間とのハイブリッド」に着地するだろう。数年後には「コード生成と下書き支援が当たり前になった」という控えめな結論になっているのではないかと思う。

大事なのは、流行りの技術から逆算するのではなく、自社の現場の課題から出発すること。その上で、AIが効く領域に絞って小さく使い始める。中小製造業にとっては、それが最も確実な一歩になる。

そもそも解いている問題が違う

ベクトルデータベースとRDB（リレーショナルデータベース）は、同じ「検索」でも解いている問題が根本的に異なる。

RDBのLIKE演算子は「文字の並び」をパターン照合する。「ステンレス」で検索すれば「ステンレス」を含むレコードが返る。完全一致や前方一致といった、決定的な検索が得意な道具になる。

一方、ベクトルDBは「言葉の意味」で検索する。文章を多次元空間の座標（ベクトル）に変換し、座標同士の近さで「意味が似ている」かどうかを判定する。「ステンレス」で検索したときに「SUS304」や「耐食鋼」が近い結果として返ってくるのは、この仕組みによるもの。

この違いを理解しておくと、どちらをどこで使うべきかの判断がしやすくなる。

テキストを座標に変換する仕組み

ベクトルDBを使うには、まずテキストを「埋め込み（embedding）」と呼ばれる数値ベクトルに変換する必要がある。この変換を担うのが埋め込みモデル。

自分が実装する中で気づいたポイントをいくつか挙げておく。

• チャンク分割が必要 ── 長い文章をそのまま1つのベクトルにすると、意味がぼやけて検索精度が落ちる。適切な長さに分割（チャンキング）してから変換する
• 日本語では200〜500文字程度が目安 ── ただし最適な分量は、使うモデルや検索対象の性質によって変わる。実際に試して調整する部分になる
• モデルを変えたら全データ再計算 ── 埋め込みモデルが変わるとベクトルの空間自体が変わるため、過去データとの互換性がなくなる。モデル選定は最初に慎重にやっておいた方がいい

自然文の方が精度が出る

これは自分が試してみて面白いと思った点。データを埋め込む際、ラベル的な書き方よりも自然文の方が良いベクトルが生成される。

たとえば「材質：SS、Φ400」のような簡潔な記述よりも、「材質はSSです。直径は400です」のような自然言語で書いた方が、検索時の精度が高くなる。

これはAIが単語間の関係性を文脈から読み取るためで、文としての構造があった方が意味の抽出がうまくいく。データの入れ方一つで検索精度が変わるという点は、実装時に意識しておく価値がある。

類似度の測り方にも種類がある

ベクトル同士の「近さ」を測る方法は一つではない。代表的なものを整理しておく。

• コサイン類似度 ── ベクトルの向き（角度）で比較する。長さの違いに影響されないため、テキスト検索では最もよく使われる
• ユークリッド距離 ── ベクトル間の直線距離で比較する。座標空間上の「物理的な近さ」を測りたい場合に向く
• ドット積（内積） ── ベクトルの向きと大きさの両方を考慮する。スコアリングの用途で使われることがある

自分がテキスト検索で使う場合は、ほぼコサイン類似度を選んでいる。迷ったらコサイン類似度から始めて、精度に不満が出たら他を試すくらいの感覚で問題ないと思う。

実務での使い分け

ここが一番大事なところ。両者は得意な場面が明確に違う。

RDBが適する場面：

• 単価や型番など「1円の狂いも、1文字の違いも許されない」厳密な検索
• 数値の範囲検索（径が100mm〜200mmの間、など）
• 集計・ソート・結合といったデータ操作

ベクトルDBが適する場面：

• 「軽い素材」のような曖昧な自然言語からの検索
• 表記ゆれを超えた意味的なマッチング（「アルミ」と「軽合金」を近いと判断できる）
• 文章として記録されたノウハウや備考欄の中身の検索

逆に言えば、数値データや確定的なコードをベクトルDBで検索するのはリスクが高い。確率的な「近さ」で返ってくるため、正確性が求められる場面には向かない。

ハイブリッドで組み合わせる

実務では、RDBとベクトルDBのどちらか一方ではなく、組み合わせて使うのが現実的な構成になる。

たとえば、スペックの絞り込みはRDBのWHERE句で確実に行い、自由記述の備考や過去の知見といった「文章の中にしかない情報」をベクトル検索で引き出す。構造化されたデータと非構造化されたデータを、それぞれ得意な道具で扱うという考え方になる。

自分がシステムを組むときも、最初からハイブリッドを前提にすることが多い。RDBだけでは拾えない情報があり、ベクトルDBだけでは正確性が足りない。両方の特性を理解した上で適材適所に配置すると、検索の質が一段上がる実感がある。