テックメモ

AIで本当に成果が出ている領域は限られている

最近はなんでもRAG（Retrieval-Augmented Generation）という風潮がある。社内データをベクトルDBに入れてチャットボットを作れば業務が変わる、という話をよく聞く。しかし実際にそういったシステムを導入した企業の声を拾ってみると、「探している情報が出てこない」「回答が的外れ」「結局自分で検索したほうが早い」という感想が大半だ。

では、エンタープライズ領域でAIが実際に成果を出しているのはどこなのか。整理してみると、大きく3つに絞られる。

1つ目はコード生成・開発支援。GitHub Copilot、Cursor、Claude Codeのような開発ツールは確実に生産性を上げている。生成物が間違っていてもコンパイルエラーやテストで即座にわかるため、人間のチェックコストが低い。

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

3つ目は画像認識・分類。製造業の外観検査や帳票のOCRなど。「正常/異常」の2値判定のように、タスクが明確でAIの出力を目視で検証しやすい領域だ。

この3つに共通しているのは、AIの出力をそのまま使わず、人間が最終判断する前提で設計されているということ。逆に「AIに判断を任せる」方向は、どの領域でもまだ成果が出ていない。

チャットボットが期待外れに終わる構造的な理由

ChatGPTやClaudeのチャットは爆発的に普及し、検索の代替や壁打ちに日常的に使う人は増えた。これが成功しているのは、ユーザー自身が「間違っているかもしれない」という前提で使っているからだ。間違っていても調べ直せばいいだけで致命的ではない。

ところが企業が「社内RAGチャットボット」を作ると、途端に期待値が変わる。ユーザーは「正確に答えてくれるはず」と思って使う。同じチャット形式なのに、求められるものがまったく違う。回答の正確性を誰が保証するのか、間違った回答で業務判断した場合の責任は誰が取るのか。そういった問いに答えられないまま導入すると、結局使われなくなる。

皮肉なことに、ChatGPTやClaudeのエンタープライズプランをそのまま社員に使わせたほうがよかった、というケースは少なくないはずだ。RAGで社内チャットボットを自作する理由が「社内データの秘匿性」なら理解できるが、それ以外の動機なら既存のAIチャットで十分なことが多い。

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

見積RAGシステムを題材に具体的に考えてみる。見積データには材質・径・長さといった数値フィールドと、用途・備考といった自由記述テキストがある。

ベクトル検索が本当に力を発揮するのは、「ポンプ用の軸」と「回転軸（ポンプ向け）」を意味的に近いと判断できるような自由記述テキストの検索だけだ。材質の完全一致や径の範囲検索はRDBのほうが正確だし、価格のように「1円の狂いも許されない」データを確率的な近さで扱うのはリスクが高い。

結局、ベクトルDBとRDBは優劣ではなく適用領域が異なる。構造化データはRDBで正確に引き、RAGは文章にしか残っていない知見の検索に使う。この使い分けを無視して「全部RAGで」と言うから期待外れになる。

OCRと方眼紙Excelの話

帳票のデータ化にAIを使うアプローチは、実はかなり現実的だ。特に中小製造業にありがちな方眼紙Excelは、プログラムで.xlsxをパースしようとするとセル結合や罫線で地獄を見る。しかし画像に変換してマルチモーダルLLMに投げれば、人間と同じように「見て読む」ことができる。

ただし、100%の精度は出ない。だから元データは絶対に捨てられない。LLMの抽出結果はあくまで「下書き」であり、最終的な正しさの担保は人間のチェックに依存する。やっていることは手入力の代替でしかなく、構造は変わっていない。作業時間が短くなるだけだ。

中小製造業にとっての最適解

ここまでの議論を踏まえると、中小製造業がAIにお金を使うなら、優先順位は明確になる。

まず、事務員全員にAIのライセンスを配るのは費用対効果が悪い。PCスキルにばらつきがあり、「何を聞けばいいかわからない」という壁がある。日常業務が定型作業の繰り返しなら、AIに聞く場面がそもそも少ない。

一方で、内製のエンジニアにAIをがっつり使わせて、社内システムを高速で作るというアプローチは噛み合っている。見積管理、在庫・発注管理、作業日報の入力・集計。こういった「あれば便利だけど外注すると数百万」だったシステムが、エンジニア＋AIで現実的な工数で作れる。業務を理解している人間が作るので要件のズレも少ない。

中小製造業の本当のボトルネックは「やりたいことはあるけど作る人がいない」という部分であり、AIでコーディングが加速するなら、そこが一番効く。

バズワードとの付き合い方

AIは完全にバズワードだ。少し前のクラウドやDXと同じパターンで、「全部AIで」という過剰な期待がいずれ幻滅に変わり、最終的に「使う場所を選べば確実に価値がある」という地味な結論に落ち着く。

クラウドが「オンプレとのハイブリッド」に着地したように、AIも「人間とのハイブリッド」に着地するのだろう。数年後に振り返れば、「コード生成と下書き支援が当たり前になった」というだけの話になっている気がする。それはそれで十分に価値があることだ。

RAGで使われるベクトルデータベースは、従来のSQLとはそもそも解決する問題の種類が違う検索エンジンである。SQLのLIKE演算子が「文字の並び」をパターンで照合するのに対し、ベクトルDBは「言葉の意味」を多次元空間の座標に変換し、座標同士の近さで検索する。一文字も合っていなくても、「犬」と「ドッグ」を同じ近所に配置できるのは、AIが単語の背後にある概念を捉えているからだ。

この「文章を座標（点）にする」仕組みには、特有のルールがある。長い文章をそのまま1つの点にすると意味が薄まってボヤけてしまうため、適度な長さの「チャンク」に細かく刻んで保存するのが定石だ。日本語であれば200〜500文字程度が一つの目安だが、最適な分量は言語・モデル・用途によって変わる。いずれにせよ、数百次元から数千次元に及ぶ計算空間の中で、その情報の個性を鮮明に描き出せるサイズ感を探ることが肝要となる。ただし、この座標は使用する「埋め込みモデル」固有の地図。モデルを変えれば地図の縮尺も方角も変わるため、データは全て計算し直しになる。

文章を点にする際、AIは単語をバラバラにするだけでなく、文脈の「味わい」を数値に凝縮している。例えば「材質：SS、Φ400」という簡素なラベル形式よりも、「材質はSSです。直径は400です」という自然な文章形式の方が、AIにとっては「何が何であるか」の関係性が読み取りやすく、精度の高い座標が打てる。検索時の短い問いかけも同じ空間の点となり、意味の近いチャンクを高速で探し出していく。この「近さ」の測り方にも複数の流儀があり、ベクトルの向きで比較するコサイン類似度、距離で比較するユークリッド距離、内積で比較するドット積など、用途に応じて使い分けられている。

しかし、ここで一つの疑問に突き当たる。データが完璧にクレンジングされ、「材質」や「寸法」が整理されているなら、そもそもベクトルDBを使わずとも、これまでのRDB（関係データベース）の検索で事足りるのではないか。事実、数値の厳密な比較や特定の型番検索において、RDBの正確性とコストパフォーマンスにベクトル検索は勝てない。ただし逆に、構造化されたデータであっても、ユーザーの問いかけが自然言語である限り、「軽い素材」という曖昧な検索語からアルミやチタンを引き当てるような意味の橋渡しは、SQLの得意分野ではない。両者は優劣ではなく、得意な問題の領域が異なるのだ。

この議論を「積算業務へのAI活用」に当てはめると、より現実的な使い分けが見えてくる。1円の狂いも許されない単価の特定や計算に、確率的な「近さ」で答えを出すRAGをそのまま使うのはリスクが高い。積算における理想の形は、正確なスペック検索はRDBに任せ、過去の特記事項や現場の勘所といった「文章の中にしかない知見」をRAGで呼び出すハイブリッドな構成だ。

結局のところ、ベクトルDBは「整理しきれない人間のニュアンス」を扱うための道具であり、議事録や現場報告のような非構造データに対しては、負債の先送りどころか正当な解法となる。一方、美しくクレンジングされたデータセットがあるのなら、無理にベクトル化するのではなく、SQLでスマートに引くのがエンジニアリングとしての正攻法。大切なのは、どちらかを選ぶことではなく、それぞれの土俵を見極めて適材適所で組み合わせることだ。