DX担当者の次に来る問い
以前の記事で、中小製造業のAI活用で最も効果が大きいのは「業務を理解した内製エンジニアがAIで開発速度を上げること」だと書いた。
この考え方は変わっていない。ただ、DX担当者がAIで成果を出し始めると、次の問いが自然に出てくる。
「他の社員にもAIを使わせたいけど、どうすればいいか」。
見積担当者が過去の類似案件を探すとき。購買担当者が仕入先の条件を確認するとき。品質管理の担当者が検査基準を参照するとき。こうした日常の業務でAIが使えたら——という話が出てくるのは自然な流れだと思う。
「社内チャットボット」が提案されるが
この段階で業者に相談すると、高い確率でRAG（Retrieval-Augmented Generation）を使った社内チャットボットの構築を提案される。社内文書をベクトルDBに入れて、チャットで質問すれば回答が返ってくる仕組み。
以前の記事でも触れたが、社内RAGチャットボットで明確な成果を上げている中小企業はまだ少ない。「探している情報が出てこない」「回答が的外れ」「結局自分で調べたほうが早い」という声は珍しくない。
RAGの仕組みは、文書をベクトル（数値の配列）に変換して、質問と意味が近い文書を探して引っ張ってくるもの。ベクトルDB、embedding、チャンク分割——技術スタックが多く、構築にも運用にもそれなりのコストがかかる。
ここで立ち止まって考えたい。中小製造業で「AIに教えたい知識」とは何か。そして、それは本当にRAGで扱うべきものなのか。
業務知識は「検索する」ものではなく「参照する」もの
中小製造業の業務知識を挙げてみる。
- 見積のルール（材質ごとの単価、加工費の計算方法、特殊条件の扱い）
- 受注処理のフロー（受注登録→手配→出荷の手順と条件分岐）
- 品質基準（検査項目、合否の判定基準、不良時の対応手順）
- 仕入先のルール（発注ロット、リードタイム、支払条件）
これらには共通点がある。 「検索して見つけるもの」ではなく、「分類して参照するもの」 だということ。
過去の議事録が1万件あって、そこから関連する議論を探すならRAGの出番がある。しかし業務ルールは構造化できる。構造化できるなら、もっとシンプルな方法で済む。
AIに「目次と参照ファイル」を渡すだけでいい
今のAI（大規模言語モデル）には、指示文と参照ファイルを事前に設定する機能がある。月額数千円のプランでも使える標準的な機能で、特別な構築は要らない。
やることは2つだけ。
- 目次を書く：どんなルールがどのファイルにあるかの一覧
- ルールファイルを用意する：カテゴリごとに業務ルールを書いたテキストファイル
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
業務ルール/ ├── 目次.md（全体の見出しと、どのファイルに何が書いてあるかの一覧） ├── 見積/ │ ├── 材料費.md │ ├── 加工費_旋盤.md │ ├── 加工費_溶接.md │ └── 特殊条件.md ├── 受注処理/ │ ├── 受注登録フロー.md │ └── 手配ルール.md └── 品質/ ├── 検査基準.md └── 不良対応.md |
AIに目次を渡しておけば、見積の質問が来たときに自分で判断して見積ルールのファイルを読みに行く。品質の質問なら品質基準のファイルを読む。全部のファイルを一度に読み込む必要はない。必要なときに必要な部分だけ参照する。
これは実質的にRAGと同じことをしている。違いは、ベクトルの類似度で探すのではなく、AIが目次を見て「このファイルだ」と判断する点。構造化されたルールなら、この方がベクトル検索よりも正確に必要な情報にたどり着く。
ルールだけでは足りない——「前提知識」と「聞き返す設計」
ルールファイルを整備しても、それだけでは実用にならないことがある。
見積の質問を例にすると、ベテランなら「SUS304の3mm、500×300で10枚、溶接あり」と具体的に聞いてくれる。しかし現場から上がってくる質問は「これいくら？」だけかもしれない。材質も板厚もサイズも抜けている状態でルールを参照しても、AIは答えようがない。
ここで必要になるのが2つある。
前提知識を渡しておく。 自社が何を作っているか、扱う材質の種類、主な加工工程、取引先の傾向——こうした会社の基本情報をAIに持たせておく。「うちは製缶板金がメインで、SUS304とSS400が大半」と書いてあれば、AIは材質を聞くときにも「SUS304ですか、SS400ですか」と具体的に聞ける。「何の材質ですか」と漠然と聞くのとでは、現場の使いやすさがまるで違う。
足りない情報を聞き返す設計にする。 目次に「見積の質問には材質・板厚・サイズ・数量が必要。不足していたら確認すること」と書いておけば、AIは情報が揃わないまま答えようとせず、先に聞き返してくれる。人間の先輩が「で、材質は？板厚は？」と確認するのと同じ流れを、AIにも持たせる。
つまりAIに渡す情報は3層になる。
- 前提知識（会社の概要、製品、工程など。常に参照する土台）
- 業務ルール（見積・受注・品質などのカテゴリ別ルール。必要に応じて参照）
- 質問ごとの必要情報（何が揃えば回答できるか。不足なら聞き返す）
この3層を意識して整備すれば、「ルールは入れたのに使えない」という失敗を防げる。
なぜこのシンプルな方法が語られないのか
理由は2つあると思う。
歴史的な経緯。 RAGが注目された2023年頃、AIが一度に読めるテキストの量は数千文字程度しかなかった。業務ルールすらまともに入りきらないから、外部に検索の仕組みが必要だった。今は20万文字近く読める。中小製造業の業務ルール全部を合わせても、この範囲に収まることがほとんどだと思う。状況が変わったのに、語られ方だけが残っている。
知識のギャップ。 AI技術者は業務ルールの構造化ができない。現場の人間はAIの仕組みを理解していない。両方わかっている人間が少ないから、シンプルな方法に気づきにくい。
以前の記事で、内製と外注の線引きについて「自社固有の領域を理解していないと、外注先を値段でしか選べなくなる」と書いた。AI活用でも同じ構造がある。自社の業務ルールをどう構造化すればAIに伝わるかを理解していないと、業者の提案を評価する基準が持てない。
本当に大変なのは「ルールを書き出すこと」
技術はシンプルだとわかった。では何が大変なのか。
業務ルールを日本語で書き出す作業そのもの が一番の壁になる。
見積を例にとる。材質ごとの単価テーブルや加工費の計算式——こうした明文化されたルールは書き出しやすい。難しいのは、ベテランの頭の中にある暗黙知のほう。
- この形状だと溶接がやりにくいから工数を1.5倍にする
- この客は初回だから少し余裕を持たせておく
- この材質とこの板厚の組み合わせは曲げで割れるから別の方法にする
こうした判断は「なんとなく」で処理されていることが多い。しかし、ベテランに「なぜ1.5倍にしたんですか」と聞けば、理由を説明できることがほとんど。説明できるなら、ルールとして書き出せる。
以前の記事でナレッジ管理について「問題はツールではなく、現場の人が自分の仕事を言語化できないこと」と書いた。AI活用の文脈でも、まったく同じ壁にぶつかる。
ただし、ここでの言語化は完璧なマニュアルを作ることではない。AIは多少あいまいな記述からでもかなり的確に判断できる。30点のルールでも、ゼロよりはるかにまし。まず書き始めて、AIに使わせてみて、「ここが違う」とベテランが指摘した部分を追記していけばいい。
計算はAIではなくスクリプトに任せる
一つ注意点がある。AIは計算が苦手だということ。
パンチングメタルの開口率から重量を出す数式、ロックウールの充填量の計算——こうした数値計算はAIに考えさせるより、計算スクリプト（ExcelやPython）にやらせたほうが正確になる。
AIが得意なのは 「この条件ならどの計算式を使うべきか」という判断 のほう。計算式はスクリプトとして用意しておいて、どの計算式をどの順番で使うかの判断をAIに任せる。この役割分担が精度を上げる。
今Excelでやっている計算がそのまま動いているなら、その計算ロジックには手を付けず、AIにはルールの判断と条件分岐だけを任せる設計が自然だろう。
ルールとデータを分けて考える
業務ルールの棚卸しだけでは対応できないケースもある。ルールとデータの違いを整理しておきたい。
- ルール（こうすべき）→ テキストファイルに書いて、AIに読ませる
- データ（過去の実績）→ データベースに入れて、SQLなどで取りに行く
- 大量データの分析（傾向を出す）→ 集計してからAIに結果を読ませる
RAGが本当に必要になるのは、非構造化データ（議事録、メール、チャット履歴）が大量にあって、そこから関連する情報を探したい場合に限られる。中小製造業でそこまでのデータ量を持っている会社は多くないだろう。
以前の記事で「ベクトルDBとRDBは別の問題を解く道具」と書いたが、同じ考え方がここにも当てはまる。構造化できる知識にベクトル検索を使うのはオーバースペックで、構造化できないデータにだけベクトル検索を使えばいい。
「AIに何を教えるか」を設計する仕事
ここまでの話を整理すると、「みんなでAI」に必要なのは3つになる。
- 業務ルールを構造化して日本語で書き出す（暗黙知の言語化）
- 目次とファイルの構造を設計する（AIが必要な情報にたどり着ける導線）
- 計算はスクリプト、判断はAIという役割分担を決める
どれもコーディングの話ではない。業務を理解している人間が、業務を整理して、日本語で書く作業になる。
問題は、この作業ができる人間が少ないこと。業務を深く理解していて、かつAIの仕組み（何ができて何ができないか、どう情報を渡せば正確に動くか）も理解している人が必要になる。
以前の記事で「AIに代替されない能力は、身体性×膨大なコンテキスト×構造化能力の3つのかけ算」と書いた。業務ルールの棚卸しは、まさにこの構造化能力の出番だと思う。そしてこれは、DX担当者がAIで開発速度を上げた次の段階として、自然な仕事の広がり方でもある。