こんにちは、株式会社K.Platinum代表の沼田です。
3ヶ月前、このブログで「GraphRAGで"図面と仕様書"がやっと検索できる」という記事を書いた（COMPANYBLOG-56）。中小製造業に「ナレッジ検索」を入れる話で、おかげさまでいくつかの製造業の経営者・情シスの方から「うちでもやれますか？」という相談をもらった。
そのうちの1社で、本当にGraphRAGを本番運用に乗せてもらった。3ヶ月、現場と並走した。
そして3ヶ月後、お客さんから返ってきた声がこれだった。
「テキストは引けるようになりました。けど、結局、現場が見たいのは"図そのもの"なんですよね」
正直、この一言を聞いた時、僕は天井を見上げた。「あ、まだ壁あるじゃん」と思った。
今日はその"次の壁"——マルチモーダルRAGを、中小製造業の現場でどこまでやれて、どこから「やってはいけない」のかを書いてみたい。やってみて分かった現実的な落とし所と、「マルチモーダルRAGをやる前に絶対やっておくべき5つの整備」までセットで残しておく。
僕は今年で起業して3期目、社員17人のITコンサル会社をやっている。製造業のAI/RAG実装を主戦場のひとつにしている立場から、生っぽく書く。
「GraphRAGで検索できる」の次に来た声
GraphRAGを入れた中小製造業のお客さんは、長年「過去案件の仕様書がどこにあるか分からない」「ベテラン社員の頭の中にしかない知識がある」という状態だった。
3ヶ月運用してもらって、テキスト系のナレッジ検索はちゃんと回るようになった。
- 「あの製品の耐圧試験、仕様書のどこに書いてあった？」 → ヒット
- 「過去に同じ顧客で似た案件あったよね？」 → 関連案件をリストアップ
- 「この部品、社内で誰が一番詳しい？」 → ノウハウ持ちの社員名がGraphから返る
ここまでは想定通り。ベテランの「頭の中ナレッジ」をテキスト形式でグラフに乗せる、というのがGraphRAGの本来の得意領域だ。
問題は、ここから先に出てきた要望だった。
「先月の◯◯案件、左上のフランジ形状がうちの△△の図面とそっくりなんですよ。それ、検索で出せないですかね？」
これだ。
現場が探しているのは"言葉"じゃなくて"絵"だった。
設計図面の左上にあるフランジ部の形状、配管レイアウト、組立図の見た目。テキストで「フランジ径100mmで肉厚厚めの」と書いても、その表現は人によってブレる。図面そのものを引きにいきたい——これが、GraphRAGの次の壁だった。
JAPAN AIの『マルチモーダルRAG』が示した到達点
タイミング的にちょうど、2025年9月にJAPAN AIがプレスリリースを出していた。
「マルチモーダルRAGを実装。全長50m級の船舶設計図面から、寸法・出力データを自動抽出可能に」
雑にまとめると、「テキストだけじゃなくて、図そのものをRAGに乗せる」を実装した、というやつ。日本の製造業向けRAGの文脈で、業界の到達点を一段引き上げた重要なプレスだったと思う。
業界として、RAGは確実にフェーズが進んでいる。流れはこうだ。
- テキストRAG：仕様書PDF・社内Wikiを引く
- GraphRAG：エンティティ間の関係を引く（人・案件・部品・ノウハウ）
- マルチモーダルRAG：図面・画像・CAD・写真を引く
3年前は1すらまともに動かなかった。1年前は2が話題になった。今、業界の最前線は3だ。
ただし、ここで僕が止めたい点がある。
「業界の最前線」と「中小製造業で実装できるか」は、別の問題だ。
JAPAN AIの実装は素晴らしいけど、お客さんの会社のサーバールームを見て「いきなりこれは無理」と思った。理由は3つある。
中小製造業がフルマルチモーダルRAGを採れない3つの理由
理由1：GPUの固定費
マルチモーダルRAGの中核は、画像を埋め込みベクトルに変換するVLM（Vision Language Model）推論だ。これはテキスト用のEmbeddingモデルと比べて、GPU消費がケタ違いに重い。
クラウドGPUで回すと、過去図面10万枚を初回インデックス化するだけで、ざっくり数十万〜数百万円のコンピュートが飛ぶ。月次の差分インデックスでも、固定費として数万円/月は普通に乗る。
中堅製造業ならまだ呑める数字。けど従業員数十人〜100人前後の中小だと、この固定費の説明だけで稟議が止まる。
理由2：自社図面はラベル付けされていない
商用VLMはネット上の汎用画像で学習されている。だから「猫が写ってる」「グラフがある」みたいな一般的な認識は強い。
でも、お客さんの会社の図面には、その会社特有の部品名・略号・組立ルールが書いてある。「Fig-A の SUS304-φ32-L120 のあのフランジ」みたいなのを精度よく引くには、自社図面で追加学習（fine-tuning）か、少なくとも自社特化のメタデータが要る。
このメタデータが、中小製造業ではまず整っていない。
理由3：そもそもCAD/図面が整理されていない
これが一番大きい。
社員10人〜30人の製造業に入って図面サーバーを見せてもらうと、フォルダ構成からして混沌としている。
- 案件番号で切ってる人、年月で切ってる人、客先名で切ってる人が混在
- 同じ部品の図面が「ver1」「FINAL」「FINAL2」「印刷用」で4つある
- Rev管理が紙にハンコ押す運用のままで、デジタル上はどれが最新か分からない
この状態でマルチモーダルRAGを入れても、AIが返してくる結果が「最新版か分からない図面」「廃番部品の図面」だったりして、現場の信頼を一発で失う。
マルチモーダルRAGは"検索の話"じゃなくて"整地の話"だった。
これが3ヶ月並走して、僕が腹落ちした結論だ。
K.Platinumが取った折衷案：『二段構えRAG』
じゃあ、お客さんに「申し訳ない、できません」と言ったかというと、もちろん言わない。中小ITコンサルの仕事は、最先端を諦めることじゃない。最先端を、その会社の体力で実装する設計図に書き換えることだ。
僕らが取った折衷案はこうだ。
第1段：図面の"テキスト化できる部分"をGraphRAGに乗せる
CAD図面には、実はテキスト情報がたくさん埋め込まれている。
- レイヤー名（「外形線」「補助線」「文字」など）
- 部品名・部品番号
- 寸法線に紐づく数値
- ノートに書かれた指示文・コメント
- タイトルブロック（案件名・日付・図面番号・担当者名）
これらをCAD APIまたはOCRでテキスト抽出して、まずGraphRAGの拡張ノードとして既存ナレッジグラフに繋ぐ。
これだけで、「フランジ径100mm以上の図面を出して」「鈴木さんが担当した昨年度の組立図」みたいなクエリは引けるようになる。画像認識を使わず、メタデータ検索の延長で勝負するやり方だ。
第2段：画像クエリはCLIPで類似画像引き
「左上のフランジ形状」みたいな図そのものの類似性は、フルマルチモーダルRAGの代わりに、CLIPベースの類似画像検索でカバーした。
CLIPは「画像→ベクトル」「テキスト→ベクトル」をどちらも同じ空間に埋め込むモデルで、商用利用可のオープンソース実装が複数ある。GPUコストもVLMより圧倒的に軽い。
「この図面と似てるやつを過去から探して」というクエリは、CLIPの埋め込みベクトルでcosine類似度を計算するだけで、それなりに精度が出る。100%ではないけど、ベテランが頭の中で「似てる気がする」と言うレベルには近づく。
二段構えのいいところ
この設計は、いきなりフルマルチモーダルRAGを採るのと比べて、3つメリットがあった。
- 既存のGraphRAGが活きる：捨てて作り直しじゃなく、増築で進められる
- GPUコストが3〜5倍違う：CLIPはVLMより圧倒的に軽い
- 段階的にお客さんが理解できる：何ができて何ができないかが、運用しながら見える
中小製造業に最先端を入れる時、僕がいつも気にしているのは「お客さんが運用フェーズで自走できるか」だ。社員数十人の会社にいきなり最先端を渡すと、ベンダーロックインの不安だけが残る。増築可能な設計は、それ自体が中小ITコンサルの提供価値だと思っている。
導入後3ヶ月で見えた『マルチモーダルRAGをやる前にやっておくべき5つの整備』
ここからが、たぶんこの記事で一番役に立つパート。
3ヶ月運用して、僕らが「マルチモーダルRAGどころか、その手前の二段構えRAGすらまともに走らない」というケースを何度も見た。理由はぜんぶ、技術じゃない。現場のデータ整地が遅れているだけだった。
逆に言えば、ここを先にやっておけば、後でフルマルチモーダルRAGに移行するのが圧倒的に楽になる。
整備1：命名規則の統一
部品名・図面番号・案件番号の付け方を、社内ルールで統一する。
ありがちな悪い例：「ボルト」「BOLT」「螺子」「ねじ」が同じ部品を指している。「2024-001」「24-01」「001/24」が同じ案件を指している。
整備の最低ライン：辞書を1枚作って、社内Wikiに固定する。「これからは"ボルト"に統一」と決めるだけでも、半年後のRAG精度が変わる。
整備2：Rev管理（版管理）の徹底
「FINAL.dwg」「FINAL2.dwg」「ほんとうにFINAL.dwg」をやめる。
整備の最低ライン：ファイル名末尾に _Rev01 _Rev02 を必ず付ける運用に切り替える。GitHubほど厳密じゃなくていい、けど「最新がどれか」が機械的に判定できる状態は最低限要る。
整備3：部品台帳の再構築
「部品マスタExcelが10年前から更新されていない」会社、本当に多い。
整備の最低ライン：現役部品だけでいいから、Excelで「部品コード／部品名／代替品／廃番フラグ」の4列を整理する。これがあるだけで、AIが「廃番部品の図面を最新と勘違いして返す」事故を防げる。
整備4：タグ辞書の整備
「ボルト＝BOLT＝螺子＝ねじ」「フランジ＝Flange＝つば」「組立図＝アセンブリ図＝ASSY」みたいな同義語辞書を作る。
整備の最低ライン：Excel 2列（標準語／同義語リスト）でいい。後でRAGのクエリ拡張に使える。
整備5：OCR耐性のチェック
手書きの寸法書き込み、紙にハンコの承認欄、スキャンが斜めになっている過去図面。これらはOCR精度がガクッと落ちる。
整備の最低ライン：過去5年分くらいの図面をサンプリングでOCRにかけて精度を測る。精度が低すぎる年代の図面は「AIから除外」と最初から決める。全部を相手にしようとすると死ぬ。
僕らがやっているのは、ぶっちゃけ整理整頓のITコンサルだ。AI/RAGのプロというより、AIを入れる前にお客さんの会社のデータを整地するプロ、と言ったほうが近い。
最先端のマルチモーダルRAGを導入したいという経営者は多い。けど、そのほぼ全員が、自社のデータがマルチモーダルRAGに耐える状態かを見ていない。
こういう"整地から最先端まで"を一気通貫で設計する仕事は、正直かなり面白い。製造業の現場にAIを根付かせる泥臭さを、技術で楽しめるエンジニアを、K.Platinumでは募集している。少しでも引っかかった人は、エンジニア募集の詳細をのぞいてみてほしい。
結論：マルチモーダルRAGは"いきなりやる"ものではない
3ヶ月、現場と並走して見えたことは、シンプルに3つだった。
- テキストRAG → GraphRAG → マルチモーダルRAGは"段階導入"でいい。いきなり3段目から始めない
- CLIPベースの類似画像検索でも、現場の8割の要望はカバーできる。フルVLMは2割の精度要件のために残しておく
- どの段階でも、データ整地が前提。整地されていないと、AIが「信頼を失う最速の道」になる
中小製造業の現場で、AIを"信頼される道具"として残すために、僕らITコンサル17人がやっているのは、結局のところ「お客さんと一緒に図面に名前を付ける作業」だ。地味だけど、ここを飛ばしてはいけない。
マルチモーダルRAGをやる前に、図面に名前が付いているか確認しよう。設計図面を引ける状態にする前に、設計図面に名前を付ける作業がある。
K.Platinumでは、製造業のRAG/AI導入を、こうやって"その会社の体力に合わせて"設計しています。「うちもいきなり最先端は無理だけど、何かしら始めたい」という会社の経営者・情シス担当の方、よかったらカジュアルに話しましょう。整地の話から付き合います。
沼田海斗（ぬまた・かいと）
株式会社K.Platinum代表。製造業のAI/RAG実装を主戦場に、最先端技術を「その会社の体力で実装できる設計」に落とし込むことにこだわっている。
K.Platinumでは一緒に働くエンジニアを募集しています。「実力で正当に評価される環境」で製造業×AIの最前線に挑みたい方は、ぜひエンジニア募集の詳細をご覧ください。
関連記事
- [COMPANYBLOG-26] 製造業×AI。AWSで作ったAI一元管理プラットフォームの話
- [COMPANYBLOG-56] GraphRAGで"図面と仕様書"がやっと検索できる — 中小製造業のRAG導入を3ヶ月でやってみた話