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

全工程スケジューリングが合わない現場

手作業が多い中小製造業では、全工程の詳細スケジューリングはうまく機能しないことが多い。作業時間は人や製品ごとにばらつきがあり、段取りの入れ替えは日常的に発生する。正確な標準時間マスタの整備が難しいケースも少なくない。計画を立ててもすぐに崩れてしまい、管理コストだけが増えることになる。

管理するポイントを絞る

すべての工程を管理する代わりに、重要なポイントだけをスケジューリングする「ポイントスケジューリング」が有効になる。例えば出荷と組立だけを管理するアプローチで、多くの中小製造業では実際に出荷日のみ管理し、社内工程は現場リーダーの経験で対応している。

管理ポイントの置き場所は在庫バッファの手前

効果的な管理ポイントは、在庫としてバッファを持てる場所の前に置く。例えば機械加工と受注組立がある場合:

素材 → 機械加工 → [中間在庫] → 受注組立 → 出荷

在庫で前後を分断することで、それぞれを独立して管理できる。結果として、出荷日、バッファ到着期限、投入日の3つの管理ポイントに絞られる。

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

手作業中心の現場には、スケジューラーが持たない判断情報がある。ただし放任ではなく、最低限3つの条件が必要になる:

  • どの仕事がバッファに届いていないかが見えること
  • 優先順位が現場に伝わっていること
  • 投入量がコントロールできていること

特に投入量の管理が重要で、過剰投入は仕掛品の混乱につながる。

溢れる工程が見えない問題

ポイントスケジューリングの弱点は、受注が積み上がったときのボトルネック特定にある。解決策は「スケジューリングではなく負荷の見える化」になる。受注ごとに工程グループの通過と概算工数を把握し、週単位で工程別に山積みするだけで十分機能する。

時間軸で見方を変える

時間軸により見方を変えるのも有効だろう:

  • 数年〜半年先: 月単位で経営判断の材料に
  • 半年〜1ヶ月先: 週単位で戦術的判断に
  • 1ヶ月以内: 日単位で優先度指示に

遠い先はぼんやり、近づくにつれて解像度を上げる。この使い分けが重要になる。

それでも残る課題

完全には解決されない課題として以下がある:

  • 材料手配タイミング(リードタイムの長い部品など)
  • 現場の優先順位判断支援
  • 管理ポイント通過の実績把握
  • 負荷溢れ時の対応ルール

これらは大掛かりなシステムではなく、Excelやホワイトボードで対応可能なものが多い。骨格となるポイント管理と負荷把握が最優先で、肉付けはその後の段階になる。


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

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

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

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

生産計画をロジックで組むには、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 サインアウト > サインイン