投稿者: okamura

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 ── 「意味の検索」と「値の検索」は土俵が違う
• AIの具体的な未来予測はどうでもいい ── それでも中小製造業が今から触るべき理由

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

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活用の判断にもつながってくる。

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

• 中小製造業がAI・RAGと付き合うための現実的な整理
• Excelのデータは「いつでもDBに移せる形」で持つ ── データの文法という考え方

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