多品種少量・受注生産の中小製造業に「全工程スケジューリング」は要らない

生産スケジューラーを入れると最初の壁にぶつかる

受注生産・多品種少量の工場に生産スケジューラーを導入しようとしたとき、たいてい最初の壁はマスタ整備になる。

スケジューラーを動かすには、品目ごとの工順と標準時間が必要になる。どの工程をどの順番で通るか。各工程に何分かかるか。この情報を品目ごとに登録しなければ、計画が計算できない。

多品種少量の工場は品目数が多い。受注するたびに仕様が変わる製品もある。数百・数千の品目に工順と標準時間を設定し、仕様変更のたびに更新し続けることは、数十人規模の工場には現実的ではないことが多い。

整備が追いつかないまま月日が経つ。あるいは無理やり整備しても、現場の実態と乖離した計画が出力される。「スケジューラーの計画より、自分たちで判断した方が正確だ」という声が現場から出始め、やがて使われなくなる。

全工程スケジューリングが定着しないのは、現場が怠慢なのではなく、マスタデータの整備コストがその規模の工場には見合わないからになる。スケジューラーが要求するインプットを用意できない構造的な問題で、これは見積データの再利用で一部カバーできるが、根本的な解決にはならない。

中小製造業の生産計画は、見積もりデータの再利用から始められる

管理するポイントを絞る

全工程をスケジューリングしなくても、生産は回る。

重要なのは結果として「いつ出荷できるか」と「今どこが詰まっているか」が把握できていること。そのために必要なのは全工程の管理ではなく、重要なポイントだけを管理することになる。

出荷日と、いくつかの管理ポイントだけを押さえる。それ以外の工程は現場に任せる。

「管理を諦める」のではなく、「管理すべきポイントを絞る」という発想の転換になる。全部を管理しようとするからマスタが整備できずに破綻する。管理するポイントを絞れば、マスタは最低限で済む。

バッファで前後工程を分断する

効果的な管理ポイントは、仕掛品としてバッファを置けるところの前後に設定する。

たとえば機械加工と受注組立が順番に並ぶ工程を考える。

素材 → 機械加工 → [仕掛品バッファ] → 受注組立 → 出荷

この中間バッファで前後工程を分断すると、機械加工と組立がそれぞれ独立して動けるようになる。機械加工側は「バッファにいつまでに届ける」という目標だけ持てばいい。組立側は「バッファから取り出して組み立て、出荷日に間に合わせる」だけを考えればいい。どちらも、相手の工程の細かい状況を把握する必要がなくなる。

管理するポイントは「出荷日」「バッファ到着期限」「投入日」の3点に絞られる。この3点が機能していれば、中間工程の細かいスケジュールはなくても生産は回る。

なおこの仕掛品バッファは、受注に紐づいたフロー在庫として意図的に設けているもので、行き先のないストック在庫とは性質が違う。受注生産での在庫の分け方については別の記事で書いた。

受注生産の在庫管理は「数える」より「分ける」が先 ── フロー在庫とストック在庫

現場に任せる、ただし条件付き

ポイント間の作業を現場に任せると聞いて、「それは属人化ではないか」という反応が返ることがある。

ただ、手作業中心の現場には、スケジューラーには持てない情報がある。今この機械の調子はどうか。段取り替えにどのくらい時間がかかるか。隣の担当者が手が空いているかどうか。これらはリアルタイムの現場情報で、システムには載せようがない。この判断を生かすために、現場に裁量を渡す。ただし放任ではなく、3つの条件が必要になる。

バッファの状況が見えること。 どの仕事がバッファに届いていて、どれが届いていないか。これが見えないと、現場は優先順位をつけられない。ホワイトボードでも、シンプルなExcelでも、「今バッファがどういう状態か」が共有されている必要がある。

優先順位が現場に伝わっていること。 出荷が近い順、顧客の重要度順——何を優先するかのルールが決まっていて、現場が自律的に判断できる状態を作る。ルールがなければ、経験の長い人の判断が暗黙の基準になり、その人がいなくなると誰も判断できなくなる。

投入量がコントロールされていること。 前工程へ投入する仕事量を絞らないと、工程内で仕掛品が積み上がり、どれを優先すべきかわからなくなる。「詰め込みすぎない」こと自体が管理の一部になる。

属人化として問題になるのは、判断の根拠が1人の頭の中にあって、その人がいなくなると誰も判断できなくなる状態のこと。ここで言う現場への委任は、優先順位のルールを決めた上で裁量を渡すことで、属人化とは性格が違う。

中小製造業は「脱属人化」ではなく「属人化のトリアージ」

受注が積み上がったとき:負荷の見える化

ポイントを絞った管理の弱点は、受注が急増したときにボトルネックが見えにくいことになる。ポイント間は現場に任せているから、特定の工程に仕事が積み上がっていても、管理側からは気づきにくい。

ここで必要なのはスケジューリングではなく、 負荷の見える化 になる。受注ごとに「どの工程グループを通るか」「概算でどのくらいの工数か」を把握し、週単位で工程別に積み上げる。精密な工数見積もりは要らない。「重い・普通・軽い」程度のランク付けで十分機能する。

この負荷の山積みは、納期回答の判断にも直接使える。「来月第2週の加工工程はすでに埋まっている」という情報があれば、引合いに対して根拠を持って答えられる。以前の記事でも書いたが、追加入力は受注時の1項目だけで、負荷の溢れと空きは把握できる。

中小製造業の納期回答は、受注データと1項目で仕組み化できる

時間軸によって粒度を変える

生産計画の粒度は、時間軸によって変える必要がある。

数ヶ月先は月単位で見れば十分で、受注の傾向や繁忙期の予測が目的になる。経営判断の材料として使う。数週間先は週単位で、負荷の溢れと空きの検知が目的になる。外注・残業の判断に使う。1〜2週間以内は日単位で、具体的な優先順位の指示が目的になる。

遠い先はぼんやり、近づくにつれて解像度を上げる。この粒度の使い分けが、限られた管理コストで機能する仕組みを作る。全工程を毎日日単位で管理しようとするから、コストが見合わなくなる。

骨格として機能すれば十分

この考え方で完全に解決しない課題もある。リードタイムの長い材料の手配タイミング、突発的な仕様変更への対応、バッファ量の設定——これらは個別に対処が必要になる。

ただ、これらの多くはExcelやホワイトボードで対応できる。大掛かりなシステムは要らない。

この記事で書いてきた考え方——管理ポイントを絞る、バッファで工程を分断する、投入量を制御する——は、それぞれ新しいものではない。TOC(制約理論)のドラム・バッファ・ロープやデカップリングポイントなど、生産管理で確立された複数の考え方がベースにある。ここではそれらを、中小製造業の現場で回せる形に組み合わせている。

骨格となるポイント管理と負荷把握が機能していれば、肉付けは必要に応じて後から追加できる。受注生産・多品種少量の工場に必要なのは、完璧な計画より、崩れても立て直せる骨格になる。全工程スケジューラーがなければ計画が立てられない、という状態こそが本当のリスクで、人と仕組みの組み合わせで動く体制の方が、現場の変化に追従しやすい。


このシリーズの他の記事:

シリーズ記事一覧・著者への相談はこちら →

中小製造業の生産計画は、見積もりデータの再利用から始められる

生産計画の前に立ちはだかる壁

生産計画をロジックで組むには、BOM(部品表)・工順・標準時間・設備能力といった製品マスタが必要になる。しかし、受注生産・多品種少量の中小製造業では、これらがきちんと整備されているケースは少ない。

BOMはベテランの頭の中にあり、標準時間は勘と経験で回している。この状態では、どんなツールを入れても、システムとして動かすための入力データがそもそも足りない。

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

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

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

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

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

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

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

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

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

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

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

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

まず回すべきは見積→計画→実績のサイクル

中小製造業にとって現実的なのは、完璧なマスタを整備することではなく、見積もりデータを計画に流用し、実績を返すサイクルを回し始めること。

この仕組みは大がかりなシステムでなくても実現できる。見積管理と実績入力をつなぐ小さなツールから始めれば、データは自然に溜まっていく。溜まったデータは、類似案件の検索や見積精度の改善に使える。

自分が内製で取り組んできた経験からすると、最初の一歩は「見積もりデータを捨てずに残す仕組み」を作ること。それだけで、生産計画の見通しは一段変わる。


このシリーズの他の記事:

シリーズ記事一覧・著者への相談はこちら →

中小製造業の多品種少量生産における原価計算の「落とし所」

収益が見えにくいという課題

受注生産・多品種少量のビジネスモデルは、案件ごとに内容が異なるため「結局いくら儲かっているのか」が見えにくい。厳密な原価計算を目指すと、工数の記録精度、間接費の配賦ロジック、材料の按分など、事務負荷が急激に上がる。自分が見てきた範囲では、多くの現場が材料費に経験則の倍率を掛ける程度の管理で回しているのが実態だった。

怠慢ではなく、合理的な判断の結果であることが多い。「決算のための会計で手一杯」という声は珍しくなく、原価管理にまで手が回らないのが正直なところだろう。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Excelのテンプレートが多品種少量に合わない理由

「Excel 原価計算」で検索するとテンプレートがたくさん出てくる。ただ多品種少量の受注生産に当てはめようとすると、合わないことが多い。テンプレートは品目マスタ・標準原価が整った量産品向けに作られており、案件ごとに材料も工数も変わる受注生産では枠に収まらない。加えて帳票が先に固定されるため、「全案件の一覧」「特定案件の内訳」「月次集計」といった切り口の違いにも対応できない。

アワーレートで計算した原価を1案件1行のテーブルで積み上げていけば、欲しい切り口はフィルターやSUMIF、VBAで後から作れる。テンプレートを探す前に、まず自分の計算方法とデータの持ち方を決めておく方が、結果的に早く使えるものができる。

まとめ:管理の落とし所

中小製造業における管理の落とし所は、次の3つのセット運用になる。

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

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

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


このシリーズの他の記事:

シリーズ記事一覧・著者への相談はこちら →

中小製造業は「脱属人化」ではなく「属人化のトリアージ」

標準化が現場に合わないとき

外部の業者は、判で押したように標準化や脱属人化を勧めてくる。その目的は、業務を特定の人に依存させず、誰がやっても同じように回る体制を整えること。管理する側にとっては正しいが、それをそのまま中小企業に持ち込むと、入力コストだけが膨れ上がって現場が疲弊する。

数千人規模の会社と数十人の会社では、標準化にかけられる体力がまるで違う。にもかかわらず、同じフレームワークを当てはめようとするから無理が生じる。

属人化は本当に悪か

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

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

中小製造業では、 「属人化」と呼ばれているものの中に、その会社の強みそのものが埋まっている ことが多い。音で機械の異常がわかる、この客はこういう仕上げを好むと知っている、材料を見れば加工の段取りが頭に浮かぶ。こうした力は、同じ業務を何年もやり続けた結果として身についたもの。属人化とは、裏を返せば特定の人が時間をかけて専門性を積み上げてきた状態でもある。

そもそも中小製造業には、属人化が進みやすい構造的な理由がある。大企業のように人材が豊富ではないから、1つの業務を複数人で回す余裕がない。結果として、特定の人が特定の業務を長く担い続け、自然とベテラン化していく。これは怠慢ではなく、限られた人数で回す中小企業の必然に近い。

「誰がやっても同じように回る」ことを目指す標準化は、70点で回せる体制をつくることはできても、ベテランと同じ95点には届かない。その差の部分こそが会社の競争力になっている。そのうえ中小の人員規模では、脱属人化そのものが構造的に難しい。職人的な強みを失わせ、しかも実現もできない。

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

対策の基本は「人で回す」設計

ただ、仕分けの前に一つ大事な前提がある。

属人化への最も基本的な対策は、同じ業務をできる人を複数つくること。重要な業務を定年まで1人にやらせ続ける状態は、そもそも設計ミスと言っていい。

中小企業に専任のバックアップを置く余裕はない。だから同じ部署の人が、自分の業務をこなしながら隣の業務も最低限カバーできる状態をつくる。ベテランと同じ水準にはなれなくても、いざというとき業務が止まらない体制にはできる。定年が近いベテランなら、かなり前から後任を横に付けて一緒に仕事をさせる。こうしたソフトランディングの設計が、属人化対策の基本になる。

中小製造業の現場では、文字にしづらい判断のタイミングや勘所が業務の質を左右する。マニュアルを読むより、隣で見て一緒にやった方が伝わることの方が多い。だから「人で引き継ぐ」設計がまずあって、文書化はそのうえでのプラスアルファになる。

ただし、人の配置にも限界はある。後任が辞めることもあれば、異動や体調不良もある。だからこそ、どの領域に追加の備えが必要かを仕分けるトリアージが要る。

属人化のトリアージ

致命的リスク:絶対に属人化してはいけない領域

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

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

深刻なリスク:段階的に共有すべき領域

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

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

軽微なリスク:属人化を許容してよい領域

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

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

線引きの基準

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

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

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

文書化で「もしも」に備える

人の配置で引き継ぎの設計ができたら、次はそれを補う「記録」に手をつける。「致命的リスク」に該当する領域は、引き継ぎ体制が整っていても、情報そのものを残しておく価値がある。

ここで陥りがちなのが、仕組み化=大きなシステム導入と考えてしまうこと。実際には、もっと手前にやるべきことがある。まず残すだけでいい。

パスワードが1人の頭にしかないなら、台帳を作る。サーバーの構成を誰も把握していないなら、構成図を1枚書く。見積もりのロジックがベテランの勘に頼っているなら、「なぜこの金額にしたか」のメモを1件分だけ残す。

形式はどうでもいい。Excelでも紙でも、共有フォルダに置いたテキストファイルでもいい。大事なのは、今この瞬間に1人の頭の中にしかない情報を、もう1箇所に写すこと。それだけで致命的リスクは致命的でなくなる。

完璧なマニュアルを作ろうとすると手が止まる。まずは雑でいいから残す。それが、属人化と向き合う最も確実な一歩になる。


このシリーズの他の記事:

シリーズ記事一覧・著者への相談はこちら →

中小製造業がAI・RAGと付き合うための現実的な整理

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が効く領域に絞って小さく使い始める。中小製造業にとっては、それが最も確実な一歩になる。


このシリーズの他の記事:

シリーズ記事一覧・著者への相談はこちら →

ベクトルDBとRDB ── 「意味の検索」と「値の検索」は土俵が違う

RAGの中で何が起きているのか

このシリーズでは、中小製造業がAIと付き合う際にRAG(社内データを検索してAIに回答させる仕組み)が選択肢の一つになるという話を書いた。

中小製造業がAI・RAGと付き合うための現実的な整理

RAGを導入するにせよ見送るにせよ、その中で使われているベクトルDBという技術の特性を知っておくと、業者の提案を聞くときや自分で検討するときに判断しやすくなる。少し技術的な話になるが、中身を理解しておいて損はない。

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

RDBは「文字の並び」で検索する。「ステンレス」で検索すれば「ステンレス」を含むレコードだけが返る。完全一致や前方一致といった、確実な検索が得意な道具になる。

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

「意味で検索できる」の落とし穴

ベクトルDBで知っておくべきは、データの入れ方で検索精度が変わること。たとえば「材質:SS、Φ400」のような簡潔な記述よりも、「材質はSSです。直径は400です」のように文章として入れた方が精度が上がる。AIが単語間の関係性を文脈から読み取るため、文としての構造があった方が意味の抽出がうまくいく。

つまり、ベクトルDBは「入れたデータがそのまま返る」道具ではなく、「入れ方次第で結果が変わる」道具になる。この性質を知っておくと、業者から「ベクトルDBで検索精度が上がります」と言われたときに、何がどう上がるのかを具体的に聞ける。

製造業のデータで考える使い分け

ここが一番大事なところ。中小製造業のデータには、数値や型番のように確定的なものと、備考や過去の経緯のように文章でしか残っていないものが混在している。

RDBが適するデータ:

  • 材質コード、型番、単価など「1文字の違いも許されない」検索
  • 径や重量の範囲検索(100mm〜200mmの間、など)
  • 受注件数の集計、納期順のソート

ベクトルDBが適するデータ:

  • 見積の備考欄、過去のトラブル対応メモなど自由記述の検索
  • 表記ゆれを超えたマッチング(「アルミ」と「軽合金」、「ポンプ用の軸」と「回転軸(ポンプ向け)」)
  • 「前に似たような案件なかったか」という曖昧な問いに対する検索

数値や確定コードをベクトルDBで検索するのはリスクが高い。「近い」結果が返ってくるだけなので、正確性が求められる場面には向かない。逆に、RDBでは備考欄の中身を意味で引っ張ることはできない。

どちらか一方ではなく組み合わせる

実務では、RDBとベクトルDBを組み合わせて使うのが現実的な構成になる。

たとえば、材質と径の絞り込みはRDBで確実に行い、過去の類似案件や加工時の注意点といった「文章の中にしかない情報」をベクトル検索で引き出す。構造化されたデータと自由記述を、それぞれ得意な道具で扱う考え方になる。

自分がシステムを組むときも、最初からこの組み合わせを前提にすることが多い。RDBだけでは備考欄や過去の知見が拾えず、ベクトルDBだけでは正確な値の検索ができない。両方の特性を知った上で使い分けることが、RAGを含めたAI活用の判断にもつながってくる。


このシリーズの他の記事:

シリーズ記事一覧・著者への相談はこちら →

Mattermost サーバー移行

Mattermostは最低限のスペックで試験運用中だったため、前回Jitsiを入れた高スペックサーバーに引っ越し。

直インストールから、Caddy + Docker運用へ変更。
バージョンは現行の10.12.4のまま移行。

旧サーバー

・Mattermost停止
systemctl stop mattermost
(起動する場合は、systemctl start mattermost)

・MySQLダンプ
mysqldump –no-tablespaces –default-character-set=utf8mb4 -u mattermost_user -p●●● mattermost_db > backup.sql

・データベース名を調べる
mysql -u mattermost_user -p●●●
show databases;

・データディレクトリ圧縮
cd /opt/mattermost
tar czvf mattermost_data.tar.gz data/
(/opt/mattermost/data/をカレントディレクトリにmattermost_data.tar.gzという圧縮ファイルにして保存)

・設定ファイルコピー(復旧に使うわけではない予備)
cp /opt/mattermost/config/config.json ./
(Mattermostの設定ファイルを今いるディレクトリにコピー)

・移行先サーバーにアップロード

新サーバー

・Caddy(既に運用状態で設定ファイルだけ変更)

cd /home/caddy
vim Caddyfile
docker compose down
docker compose up -d

・Mattermost

cd /home
mkdir mattermost
cd mattermost
vim docker-compose.yml

docker compose up -d

・データインポートのためDocker停止
docker stop mattermost-app

・SQLリストア
docker exec -i mattermost-db mysql –default-character-set=utf8mb4 -u mmuser -p●●● mattermost < backup.sql

・別ターミナルでプロセス確認する場合
docker exec -it mattermost-db mysql -u mmuser -p●●● -e “SHOW PROCESSLIST;”

・dataディレクトリ展開
※tarをdocker-compose.ymlと同じ階層に保存。
cd /home/mattermost
tar xzvf mattermost_data.tar.gz -C ./volumes/mattermost/
(tarを./volumes/mattermost/に解凍。tarにdataディレクトリを含んでいる)

・パーミッション
chown -R 2000:2000 /home/mattermost/volumes/mattermost/

・Docker開始
docker start mattermost-app

・エラーになる場合、AIプラグイン削除
rm -rf /home/mattermost/volumes/mattermost/plugins/mattermost-ai
docker restart mattermost-app

・DNSレコードのIPアドレス変更

FAX受信

GCP Javascript 複合機で受信したFAXをMattermostに投稿(PNGを投稿+PDFへのリンク)

アクセストークンが無効化されてしまうのでこちらは再設定。

・アクセストークン有効化
ステムコンソール>統合機能>統合機能管理>パーソナルアクセストークンを有効にする

・トークン生成
プロフィール>セキュリティー>パーソナルアクセストークン>編集する>トークンを生成する

・チャンネルID確認
チャンネルの上のチャンネル名をクリック>情報を表示

 

VPS Caddy Jitsi Meet 設定メモ

社内コミュニケーションにMattermostを利用しているが、会話なら一瞬で済む内容でも、テキストベースだと時間がかかってしまう。

かといってZoomやMeetを立ち上げるほどではないという場面のために手軽に呼び出せるJitsiプラグインを導入することにした。

Caddy

・共通ネットワーク作成
docker network create localproxy

・フォルダ準備
cd /home
mkdir caddy
cd caddy

・Caddyfile

vim Caddyfile

・docker-compose.yml

vim docker-compose.yml

・コンテナ起動
docker compose up -d

Jitsi Meet

・フォルダ準備
cd /home
mkdir jitsi
cd jitsi

・docker-compose.yml

vim docker-compose.yml

・コンテナ起動
docker compose up -d

・ufw
ufw allow 10000/udp

DNS

jitsi.●●●.comのAレコードをサーバーIPアドレスに向ける。

Mattermost

https://github.com/mattermost-community/mattermost-plugin-jitsi

Releasesからtar.gzをダウンロード。
システムコンソール>プラグイン管理>プラグインをアップロードする

プラグインを有効にする>設定

Jitsi Server URL:https://jitsi.●●●.com
Embed Jitsi video inside Mattermost:無効
Show pre-join page:有効
Jitsi Meeting Names:Random
Use JWT Authentication for Jitsi:有効
App ID for JWT Authentication:mattermost
App Secret for JWT Authentication:Jitsiと同じ秘密鍵

 

VBA vbac.wsf インストール

https://github.com/vbaidiot/ariawase
からzipをダウンロード、vbac.wsfを取り出す。

という構成にして、
cscript vbac.wsf decombine
を実行する。

インポートは
cscript vbac.wsf combine
を実行する。

AI/LLM Claude Code インストール

インストール

powershell
>npm install -g @anthropic-ai/claude-code
>claude

・テキストスタイル選択

Choose the text style that looks best with your terminal
To change this later, run /theme

❯ 1. Dark mode
2. Light mode
3. Dark mode (colorblind-friendly)
4. Light mode (colorblind-friendly)
5. Dark mode (ANSI colors only)
6. Light mode (ANSI colors only)

・ログイン方法

Claude Code can be used with your Claude subscription or billed based on API usage through your Console account.
Select login method:

❯ 1. Claude account with subscription · Pro, Max, Team, or Enterprise
2. Anthropic Console account · API usage billing
3. 3rd-party platform · Amazon Bedrock, Microsoft Foundry, or Vertex AI

ブラウザが開くので、承認する。

・Claude Codeのターミナル設定

Use Claude Code’s terminal setup?
For the optimal coding experience, enable the recommended settings
for your terminal: Shift+Enter for newlines

❯ 1. Yes, use recommended settings
2. No, maybe later with /terminal-setup

・セキュリティ(信頼できるプロジェクトかどうか)

Quick safety check: Is this a project you created or one you trust? (Like your own code, a well-known open source project, or work
from your team). If not, take a moment to review what’s in this folder first.
Claude Code’ll be able to read, edit, and execute files here.
Security guide

❯ 1. Yes, I trust this folder
2. No, exit

GitHub CLI

powershell
>winget install GitHub.cli
>gh auth login

Claude by Anthropic for Excel

・インストール

Microsoft 365管理センター > 設定 > 統合アプリ > Add-ins > アドインの展開 > Microsoft Store から展開する
Claude by Anthropic for Excel
を選択する。

・確認

Microsoft 365管理センター > 設定 > 統合アプリ > Claude by Anthropic for Excel > 概要 > アプリを開く > Excelで開く

・その他、確認ポイント

Microsoft 365管理センター > 設定 > 組織設定 > ユーザーが所有するアプリとサービス
ユーザーがOfficeストアにアクセスすることを許可する。
がONかどうか。

ローカルExcel > ファイル > オプション > トラストセンター > トラストセンターの設定 > 信頼できるアドインカタログ

・ローカルExcelのライセンスがおかしくなった場合

cmd > cscript “C:\Program Files\Microsoft Office\Office16\ospp.vbs” /dstatus
Last 5 characters of … の英数字をコピー

cmd > cscript “C:\Program Files\Microsoft Office\Office16\ospp.vbs” /unpkey:3RQ6B

Excel サインアウト > サインイン