産業機械メーカーの設計部に1日張り付くと、設計者が机に座っている時間の半分以上が、実は「過去の図面を探している時間」であることに気づきます。3D CADを開く前に、似た案件のアセンブリ図、客先別の特殊仕様、ECN（設計変更通知）の履歴、見積根拠になった部品リストを順番に呼び出す。共有サーバ、PDM、メールの添付、退職者のローカルフォルダ。検索の結果は「たぶんこれ」が3〜4件出てきて、開いて中身を見るまで正解は分かりません。本記事では、年商120億円・設計者18名の産業機械メーカーが、図面バンクという業務エージェント基盤を導入し、12ヶ月で「設計者の半日」を取り戻した実装記録をお伝えします。PoCのつまずきと、本導入で効いた論点を、時系列で残します。

※本記事の主要数値は実際の導入支援案件をベースに、企業特定を避けて再構成しています。

図面検索ではなく「業務文脈の再構築」に時間がかかっている

導入前の同社では、設計1案件あたり平均14時間の「過去案件参照」が発生していました。検索そのものは1分で済みます。問題はその後で、開いた図面の改訂履歴、適用された顧客要求、構成部品の現行性、見積時のVE提案——これらの業務文脈を再構築するのに時間が溶けていました。

業務フローで分解すると、痛点は4層に分かれます。情報層では、図面ファイルが共有サーバ・PDM・個人PC・メールの4箇所に分散し、命名規則が10年で3回変わっていました。人層では、設計歴25年のベテラン2名が「どこに何があるか」の暗黙知を握り、退職リスクが顕在化していました。プロセス層では、新規案件の8割が過去案件の派生にもかかわらず、「過去図面の流用判断」が個人の記憶に依存していました。ツール層では、PDMは導入済みでしたが、検索インデックスが部品番号と表題欄しか拾わず、本文中の特殊仕様・客先要求・設計者コメントは検索対象外でした。

既存の解決策には限界がありました。検索ツールの全文検索はPDFを文字列としてしか読まず、業務的な意味——「これは食品機械の客先要求」「これは耐圧仕様の派生」——を理解しません。汎用の生成AIチャットは、社内図面DBに繋がっていないため、外の知識で答えるか「分かりません」と返すかのどちらかです。設計部長は「結局、ベテランに聞きに行くのが一番早い」という現実に戻り、暗黙知の集中はむしろ進んでいました。

数字に直すと、年間の影響は以下の通りでした。

• 設計者18名 × 年間案件平均22件 × 1案件14時間 = 年間5,544時間
• 設計者単価4,500円換算で 年間2,494万円相当
• 加えて、見積精度のばらつき（過去類似案件の見落としによる単価過小評価）が年商の約0.6%

設計部長の言葉は単刀直入でした。

3D CADの操作は速くなった。でも『設計に取りかかれる状態』になるまでが遅い。半日が消えている感覚は、現場全員が持っています。

設計部長（年商120億円・産業機械メーカー）

12ヶ月の実装プロセスと、業務エージェント基盤としての図面バンク

Phase 0：着手前の認識合わせ（着手月）

最初の議論は「ツール選定」ではなく「業務分解」でした。同社が当社の業務OS提供チームに最初に問い合わせた時、要望は「PDMの検索を強化したい」でした。しかし業務診断（無料・30分）で論点を整理した結果、本質的な課題は「設計者が業務に取りかかるまでの文脈再構築」にあると合意しました。ここで対象範囲を、検索精度の改善ではなく設計業務の起点を整える基盤づくりに再定義しました。

Phase 1：PoC（1〜3ヶ月目）——最初の壁は「データではなく分類」

PoCでは、過去5年分の図面データ約7,200件を対象に、図面バンクの試験環境を構築しました。ここで最初のつまずきが発生します。ファイル名と表題欄だけでは、業務的な分類が立ち上がらなかったのです。

具体的には、同じ「○○機-1500」というモデル名が、客先A向け（食品仕様）と客先B向け（医薬仕様）で全く別物にもかかわらず、ファイル名だけでは区別できませんでした。AIに分類させると、表面的な型番でグルーピングしてしまい、現場の感覚と合わない。

解決策は2段構えにしました。第1に、ベテラン設計者2名に1日ずつ「分類観点」を言語化してもらうワークショップを実施。「客先別」「仕様階層（食品／医薬／一般）」「派生世代」「VE適用有無」の4軸を抽出しました。第2に、その4軸をRAG（社内データを参照して答える仕組み）のメタデータとして埋め込み、検索結果がこの4軸でフィルタできるようにしました。

PoC終了時点で、過去案件参照に要する時間は1案件14時間→6時間まで短縮。ただし設計部長からは「これだけでは現場が定着しない」というフィードバックが入りました。

Phase 2：本導入（4〜8ヶ月目）——「検索」から「業務エージェント」へ

本導入で踏み込んだのは、検索ツールの提供ではなく設計業務のスタート地点を変えることでした。具体的には、新規案件の引き合いがCRMに登録された瞬間に、図面バンクが自動で以下を準備します。

1. 客先別・仕様別の類似案件を上位5件提示（4軸メタデータでスコアリング）
2. 各案件の「設計時に注意した点」をベテランの過去コメントから抽出
3. 構成部品の現行性チェック（廃番・代替品・単価変動の自動フラグ）
4. 過去のVE提案・客先からの設変要請の履歴をタイムライン化

設計者は朝、案件IDを開くだけで、これらが既に整理された状態で見えます。「探す」「組み立てる」が「読んで判断する」に変わりました。

ここで効いたのが、業務OSという考え方です。図面バンクは単独のツールではなく、調達・品質・営業のデータと繋がる業務基盤として設計しました。設計者が見る画面の裏側で、見積根拠の更新、ECNの自動配信、品質トラブル履歴の照合が走っています。「図面検索ツール」ではなく「設計業務の起点を統合した業務エージェント」と位置づけたことが、現場の使われ方を変えました。

Phase 3：定着（9〜12ヶ月目）——数字とベテランの納得

12ヶ月後の数値はこうなりました。

• 1案件あたり過去案件参照時間：14時間 → 3.5時間（▲75%）
• 年間換算：5,544時間 → 1,386時間（年間4,158時間の回復、設計者2名分相当）
• 見積精度ばらつき：年商の0.6% → 0.18%（精度向上による粗利改善）
• 暗黙知の集中度：ベテラン2名依存 → 図面バンク経由で全員が参照可能

半日取り戻したというより、設計者が本当にやるべき思考に集中できる時間が増えた。新人が3ヶ月でベテランの『判断の引き出し』に触れられるのも大きい。

設計課長（同社）

ROI試算の考え方

金額の議論は、節約時間×単価では本質を捉えません。同社では3つの観点で評価しました。第1に、設計者2名分の余力創出を新規受注の引き合い対応に振り向けたことで、12ヶ月で受注機会が約1.4倍に。第2に、見積精度の改善が粗利を直接押し上げ、投資回収は実装から8ヶ月で完了。第3に、ベテラン退職リスクへの保険として、暗黙知が社外流出する前に基盤化できた点を、金額に換算しない「経営判断としての価値」と位置づけました。

自己診断ミニチェックリスト：あなたの設計部に当てはまりますか

• 設計者が新規案件に取りかかる前に、過去案件参照に半日以上かかっている
• 「あれはたぶん〇〇さんが知っている」という会話が週に複数回発生している
• 共有サーバ・PDM・個人PCの3箇所以上に図面が分散している
• PDMは入れたが、表題欄しか検索対象になっていない
• 見積精度のばらつきが、過去案件の見落としに起因しているという感覚がある

3つ以上当てはまる場合、年間1,000時間以上が「業務文脈の再構築」に消えている可能性があります。

反論への先回り：「PDMで十分なのでは」「内製で作れるのでは」

「PDMで十分なのでは」——PDMは図面の版管理と部品構成の正本性を担保する基盤として優れています。ただし、PDMの検索インデックスは構造化データ（部品番号・表題欄・属性）を主対象としており、本文中の客先要求や設計者の判断コメント、VE適用履歴のような非構造データの業務文脈は対象外です。同社でも、PDMはそのまま継続使用し、図面バンクはPDMの上位レイヤとして「業務文脈を統合する層」として位置づけました。PDMを置き換えるのではなく、PDMが拾えない領域を補完する設計です。

「内製で作れるのでは」——可能なケースもあります。社内に生成AIエンジニアと業務分解ができる設計者の両方がいる場合、6〜9ヶ月で類似のものは構築できます。一方、PoC段階で詰まりやすいのは技術ではなく「業務分類の言語化」です。同社でも最初の壁はここでした。内製を選ぶ場合、設計部とエンジニア部が並走する体制と、ベテラン設計者の知見を引き出すワークショップ設計が成功条件になります。「ChatGPTを社内に置けば終わり」という想定で始めると、定着前に頓挫する確率が高いというのが実装現場の感触です。合わないケースは、設計案件の8割以上が一品一様で過去流用が成り立たない受託特化型の設計組織です。

教訓：他社にも当てはまる3点

1. 検索精度の改善ではなく、業務の起点を変える設計にする——「速く探せる」ではなく「探さなくて良い状態」を作る方向に倒すと定着する
2. 分類観点はAIではなく、ベテランの言語化から始める——AIに任せると現場感覚と合わない分類になる。1日のワークショップが12ヶ月の運用を決める
3. PDM・CRM・調達データと繋がる業務基盤として設計する——単体ツールでは半年で使われなくなる。業務OSとして他データと繋がることが定着の条件

次のアクション：30分の業務診断で「貴社の半日」を可視化する

同社の事例の主要数値は、業務診断（無料・30分）で「貴社の場合は何時間に相当するか」を可視化できます。設計者数・年間案件数・過去案件参照の実態をヒアリングし、年間の「設計者の半日」相当量と、図面バンクが効く業務／効かない業務を切り分けてお伝えします。診断後の押し売りは行いません。

CTA文言A/Bテスト用 別案：「設計OSが効く業務／効かない業務を診断する（無料・30分）」「自社の設計部に当てはめた『半日の行方』を可視化する」

関連記事

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

業務OSパッケージ・関連ページ

• 設計OSパッケージ概要
• 業務診断（無料・30分）申込