産業機械メーカーの設計部に通うと、ほぼ例外なく聞こえてくる声がある。「過去案件の図面を探しに行くだけで午前中が消える」「結局ベテランしか答えられないから、新人は手が止まる」「PLMは入れたが、検索しても出てこないので結局共有サーバを漁っている」。図面バンクという業務エージェント基盤を導入した産業機械メーカー（売上150億円規模／設計者60名）の現場で、この詰まりがどう解けたか。実装の手順、つまずき、3ヶ月後の数字を本記事に記録する。製品の機能列挙ではなく、業務の動き方そのものがどう変わったかに焦点を当てる。

導入前の現場——「探す」が業務の主成分になっていた

導入前のヒアリングで明らかになったのは、設計者60名×1日2.5時間（自己申告）が「過去図面・過去案件・部品仕様を探す」時間に消えている事実だった。年間換算で約1.4万時間。これを「業務時間がもったいない」と片付けるのは早い。本当の問題は3つの構造に分けられる。

第一に、探す対象の正体が曖昧。設計者は「3年前の食品機械A型の搬送ユニット図面」を探したいのに、共有サーバ上のフォルダ名は「20XX_案件名_最終版_v3_修正後_山田」のような表記揺れだらけ。検索キーワードを思いついても、そのキーワードがファイル名やメタ情報に入っている保証がない。第二に、暗黙知が個人に張り付いている。「あれを聞くなら山田さん」「Bラインの過去トラブルは佐藤さんが知ってる」という属人化が常態化し、聞きに行く時間と中断コストがダブルで発生する。第三に、PLMが「保管」に閉じている。導入済みのPLMはBOM管理・改訂管理には強いが、「曖昧な意図から該当図面に辿り着く」検索体験はSharePointの全文検索とほぼ同じ品質だった。

図面バンクで何を構築したか——3層の設計

導入したのは、図面バンクと呼ぶ業務エージェント基盤である。単なる検索ツールではなく、設計部の業務フローに寄り添った3層構造で組んだ。

層1: 取り込み層（既存資産の構造化）

共有サーバ・PLM・メールサーバ・拠点ファイルサーバに散らばった図面（PDF・DXF・各種CAD中間ファイル）と、関連する仕様書・FMEA・是正処置記録・見積書をエージェントが自動で取り込み、文書ごとに「機種・搬送方式・想定ライン速度・主要部品・関連案件・改訂履歴・関係者」をメタ情報として抽出する。SPESILLは仕様書・FMEA・是正処置・見積書・各種ログを構造化＋AI活用可能にする基盤として、この層の中核に据えた。表記揺れ（搬送ユニット／搬送モジュール／搬送機構）は同義語辞書で吸収する。

層2: 検索・対話層（曖昧な意図を絞り込む）

設計者は「3年前の食品機械A型で、搬送速度を上げたら振動が出た案件」と自然文で投げる。エージェントは候補を3〜5件提示し、不足情報があれば「具体的な振動の出方は？立ち上げ時／量産後のどちら？」と逆質問で意図を絞る。検索結果は単なるファイル一覧ではなく、「該当案件の概要・どの図面・誰が関わったか・関連トラブル記録」までを1画面で見せる。

層3: 業務接続層（次の行動に直結する）

過去図面が見つかった瞬間に、その案件の見積・FMEA・是正処置・後続改訂までを横断表示。新規案件のひな形として「この案件をベースに新規BOMを起こす」を1クリックで起動できる。属人化していた山田さん・佐藤さんへの問い合わせは、エージェントが過去議事録・社内チャットから自動的に該当箇所を引っ張り、「山田さんが過去にこう判断した記録」として提示する。

3ヶ月後の数字——半日が戻ってきた

導入後3ヶ月で、設計者1人あたりの「探す・聞く」時間が1日2.5時間→1.1時間に短縮。設計部全体で月間1,680時間（およそ設計者10名分の工数）を捻出した計算になる。捻出された時間は「新規案件の構想設計」「過去トラブルの体系化」「新人OJTの個別フィードバック」に振り直された。属人化の指標として「特定の人にしか答えられない問い合わせ件数」も52%減少。新人設計者の独り立ちまでの期間は、従来12ヶ月→7ヶ月に短縮した（同期間に入社した新人2名×3社の比較）。

つまずいた3点と、それぞれの解き方

つまずき1: 「過去図面のメタ情報が貧弱で、AIに食わせても精度が出ない」。最初の1ヶ月はメタ情報抽出の精度が60%程度で、検索結果のノイズが多かった。解は「過去全件をいきなり構造化しない」こと。直近3年分・主力機種A型／B型の図面に対象を絞り、メタ情報抽出のレビューを設計リーダー2名で1日2時間×4週間集中投入した。結果、対象範囲のメタ精度は92%に到達。残りの旧案件は「使われたら学習する」運用で段階的に品質を上げる方針に切り替えた。

つまずき2: 「ベテランが図面バンクを使わない」。導入後2週間時点での利用率は若手中心で偏っていた。原因は「自分の頭の中の方が速い」という体感。解は「ベテランの暗黙知をエージェントに教える役割」として再定義したこと。新人からの問い合わせをエージェント経由にし、ベテランが回答した内容を構造化記録として残す運用に切り替えると、ベテラン自身がエージェントの育成主体として参加するようになった。

つまずき3: 「PLMとの役割分担が不明瞭」。社内から「PLMがあるのに二重投資では」という反論が出た。解は明確な役割分担の言語化。PLMは「正本管理・改訂管理・出図フロー」を担当、図面バンクは「曖昧な意図から該当資産に辿り着く検索体験・暗黙知の構造化」を担当。両者は対立せず補完関係にあり、PLMの正本データを図面バンクが参照する構造で運用した。

自己診断ミニチェックリスト（設計部長向け）

• 設計者が「過去図面を探す・聞く」に1日2時間以上を費やしている自覚があるか
• 共有サーバ・PLM・メール・拠点ファイルサーバの4ヶ所以上に図面が散在しているか
• 「あれはあの人に聞かないと分からない」案件が部内に5件以上あるか
• 新人設計者の独り立ちまでに12ヶ月以上かかっているか
• 過去トラブルの再発防止策が「個人の記憶」に依存しているか

3つ以上当てはまるなら、図面バンク／設計OSの検証価値はある。

反論への先回り——「内製で十分」「ChatGPTで足りる」への答え

「社内エンジニアでRAGを組めば十分では」という反論。実際に試した企業の話を聞くと、初期PoCは2ヶ月で動くが、本格運用に必要な「メタ情報抽出の精度向上ループ」「業務フローへの組み込み」「権限管理・拠点別分離」「現場の運用学習」は片手間では回らない。図面バンクのような業務エージェント基盤は「ツール」ではなく「業務OS」であり、業務フローと一緒に育てる対象である。内製と外注の境界は、技術層は内製可能だが、業務分解と運用設計は外部の知見を入れた方が早い。

「ChatGPTやCopilotで設計者一人ひとりが工夫すれば」という反論。汎用AIは個人の生産性は上げるが、組織の暗黙知を構造化する仕組みは持たない。図面・案件・人の関係性をデータとして持ち、検索体験として組織全体に提供するには、業務に紐付いた専用基盤が必要になる。汎用AIと業務OSは対立せず、設計者の手元には汎用AI、組織の資産検索には業務OSという棲み分けが現実的である。

次のアクション——自社の設計業務フローを30分で診断する

自社で同じ詰まりが起きているかを判断する最短経路は、設計部の代表的な3業務（図面検索・BOM整合・設計変更通知）について、現場担当者に「最も時間が読めなくなっている瞬間」を1つずつ言語化してもらうことだ。30分の業務診断（無料）では、自社の設計業務フローを3層モデルに当てはめ、図面バンク／設計OSが効く領域と、そうでない領域を切り分ける。実装ロードマップは診断結果に応じて個社別に組む。

次に読むべき記事

• 設計部長が知らないと損する、図面検索の本当のコスト——年間1,200時間が消える理由
• 設計OSとは——図面・部品表・設計変更を一気通貫させる業務エージェント基盤
• 業務OSとは何か——製造業ERPでもPLMでもない、第3の業務基盤の正体

30分の業務診断（無料）を申し込む