「設計者が一日のうち4割を、図面を探したり、部品表をメンテしたり、設計変更を関係部署に伝えたりすることに使っている」——製造業の設計部門で繰り返し聞く話です。CADもPLMも入っているのに、業務時間そのものは10年前と変わっていない。ツールは揃っているのに、設計者が本来やるべき構想設計や検図に集中できない構造的な理由は何か。本稿で取り上げる「設計OS」は、CADやPLMの代替ではなく、その上で図面・部品表・設計変更を業務として一気通貫で動かす業務エージェント基盤です。設計部門のDXが「ツールを入れただけ」で終わる構造を、業務分解の観点から崩しにいきます。

設計部門で繰り返される「ツールはあるのに業務が回らない」という構造

多くの設計部門は、過去20年でCAD（2D/3D）、PDM/PLM、ERP、構成管理ツール、DRレビューシステムと、複数のITツールを順次導入してきました。一方で、現場の設計者の業務日誌を細かく見ると、次のような時間の使い方が露わになります。

• 図面検索：類似品設計の参考図面が見つからず、ベテランに聞いて回る。1件30分。1日2-3件発生
• 部品表メンテ：設計変更のたびに、設計BOM・製造BOM・購買BOMの整合を手作業で確認
• 設計変更通知：ECN（Engineering Change Notice）を関係部署に通すが、誰がいつ受領したか追跡できない
• 過去の検討経緯の探索：「なぜこの形状にしたのか」が議事録・メール・Excel・口頭で散在
• 新人教育：暗黙知の継承が属人化。先輩の隣に座って覚える以外の方法がない

これらは個別の「ITツール導入で解決すべき課題」のように見えますが、実は同じ根を持っています。設計業務はもともと「情報を探す・組み合わせる・伝える・記録する」の連鎖であり、CADやPLMはその連鎖の各点（モデル管理、版管理）を扱っているにすぎません。連鎖そのもの——業務フローを動かす仕組み——は、人間の頭の中と暗黙のルールに残されたままです。だから、ツールを増やしても業務は速くならず、むしろツール間の整合作業が増えていく。これが「PLMを入れたのに業務が変わらない」の正体です。

10名の設計課で月10件の流用判断が走るとして、平均1.5日／件の意思決定遅延を仮置きすると、年間1,200時間（150人日）が失われている計算になる。

設計部長が知らないと損する、図面検索の本当のコスト——年間1,200時間が消える理由

設計OSとは——CADでもPLMでもない「第3の業務基盤」

設計OSは、設計部門の業務フローそのものを動かすために設計された業務エージェント基盤です。ハードウェア（CAD・PLM・ERP・社内Wiki・図面サーバー）の上に乗り、それらを横串で繋ぎながら、設計者の代わりに「探す・整える・伝える・記録する」を実行します。

設計OSの3つの役割

役割1：情報の即時取り出し（業務エージェント＝図面バンク／設計知識検索）
類似図面・過去の設計議事録・部品表・FMEA記録などを、自然言語で問いかければ取り出せる状態に統合します。「型番Xの後継機で、外形は近いがモーター容量が大きい設計実績はあるか」のような複合条件で、CAD・PDM・ファイルサーバー・メールアーカイブを横断検索する。設計者の「ベテランに聞きに行く」が「設計OSに聞く」に置き換わる構造です。

※「図面バンク」は株式会社New Innovationsが提供するAI図面管理クラウドです。湖国精工・三重精機・昭和精工など複数社の導入実績が公開されています（出典：PR TIMES、公式YouTube）。設計OSはこうした業務エージェントを横串で組み合わせる基盤層として位置づけます。

役割2：業務フローの整合（業務エージェント＝BOM整合／設計変更通知）
設計変更が発生したとき、設計BOM・製造BOM・購買BOMの整合確認、ECNの起票、関係部署への通知、受領確認までを、設計者が手作業で追わなくていい状態にします。Excel仕様書・FMEA・是正処置・見積書・各種ログなど、製造業のExcel帳票を構造化して扱える基盤（SPESILL等）と組み合わせることで、帳票単位の業務が情報の流れに変わります。

役割3：暗黙知の言語化と継承（業務エージェント＝設計レビュー支援／教育）
設計DRやVE/VA活動で生まれた判断（なぜこの板厚にしたか、なぜこの材料を選んだか）を、議事録から自動抽出し、構造化された形で蓄積します。新人が「先輩の頭の中」にしかなかった判断軸を、業務フロー上で参照できるようになる。設計部門の暗黙知が、属人ではなく組織の資産として残る状態を作ります。

設計OSとCAD・PLMの位置関係

層	役割	例	設計OSとの関係
表現層	形状・寸法を作る	2D/3D CAD	設計OSは入力源として参照する
管理層	図面・BOMの版管理	PDM/PLM	設計OSは横断アクセス層として活用する
計画層	製造計画・原価計算	ERP	設計OSは設計変更を計画層に伝える
業務層	業務フローを動かす	設計OS	本稿で扱う第3の業務基盤

つまり、設計OSはCADやPLMを置き換えるものではなく、それらを使いこなしながら設計者の「業務時間」を取り戻す層です。既存の投資を活かしたまま、業務フローの主導権をツール側に渡します。

理由は単純で、ERPは「お金とモノの記録台帳」、PLMは「図面とBOMの保管庫」であり、いずれも「業務そのもの」を実行する仕組みではないからです。

業務OSとは何か——製造業ERPでもPLMでもない、第3の業務基盤の正体

自己診断ミニチェックリスト：あなたの設計部門に設計OSは効くか

• 設計者が「過去の類似図面を探す時間」を1日30分以上使っていると感じる
• 設計変更の通知が、口頭・メール・Excel・チャットに分散している
• BOM整合が手作業で、設計変更のたびに人海戦術になっている
• 新人設計者の独り立ちに2-3年かかっており、その間ベテランが教育コストを負担している
• PLMを導入しているが、設計者の業務時間そのものは導入前と変わっていない

3つ以上当てはまる場合、設計OSの導入で改善余地が大きい状態です。後述の業務診断で、自社の現状を業務分解して可視化できます。

導入の全体像——どこから着手し、何で測るか

設計OSの導入は「全部いっぺんに」ではなく、3ヶ月単位で業務領域を絞って始めるのが現実的です。中堅製造業の設計部門で実際に進む手順を整理します。

STEP1：図面・知識の検索系から（1-3ヶ月目）

最初に効くのは、設計知識検索です。CAD・図面サーバー・メール・社内Wikiを横断検索できる環境を作り、設計者が「ベテランに聞きに行く」を「設計OSに聞く」に置き換えます。測定指標は「図面検索1件あたりの所要時間」「ベテランへの問い合わせ件数」。3ヶ月で30%以上の短縮が見えれば、次のステップに進みます。

STEP2：BOM整合・設計変更通知（4-6ヶ月目）

次に、設計変更時のBOM整合確認・ECN起票・受領追跡を業務エージェントに任せます。測定指標は「ECN起票から受領完了までのリードタイム」「設計変更起因の品質トラブル件数」。設計から品質・調達への横串が通るので、部署横断の効果が見えます。

STEP3：暗黙知の構造化・教育（7-12ヶ月目）

設計DR・VE/VAの議事録を自動構造化し、新人教育や検図支援に活用します。測定指標は「新人独り立ちまでの期間」「設計DR時間あたりの指摘件数」。暗黙知が組織の資産として残り始めると、設計部門全体の生産性が一段上がります。

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

反論1：「自社のエンジニアが内製すれば良いのでは？」

内製は選択肢として正しい場面があります。ただし設計OSの内製で躓くポイントは、AI技術ではなく業務分解です。設計者が日々何に時間を使っているかを業務単位で分解し、どこを業務エージェントに置き換えると最も効くかを見極める作業は、設計現場と実装の両方を理解している人材が必要になります。中堅製造業で「設計部にAIエンジニアがいる」ケースは稀で、社内のDX推進担当が独学で設計OSを組むのは現実的に厳しい。だからこそ「業務分解は外部と一緒にやり、構築の一部は内製化する」という分担が、最も再現性のある進め方です。

反論2：「ChatGPTやMicrosoft Copilotで十分では？」

汎用LLMは設計者個人の検索・要約には役立ちますが、業務フローを動かすことはできません。設計OSが扱うのは、CAD・PLMの社内データ、過去の図面・BOM・議事録、ECNの状態管理など、社外には出せない情報の連鎖です。ここを動かすには、社内データへの安全な接続、業務状態の永続化、設計部門の業務ルールに沿ったエージェント設計が必要で、これは汎用LLMの「対話インターフェース」とは設計思想が異なります。汎用LLMは設計OSの中の構成要素として活用しますが、それ単体で設計部門の業務フローを動かすことはできません。

反論3：「PLMをまだ使い切れていないのに、また新しい仕組みを入れるのか」

設計OSはPLMを置き換えるのではなく、PLMの上に乗ります。PLMはモデル・図面・BOMの版管理という「管理層」を担い続け、設計OSは「業務層」として、PLMの中身を業務フローに沿って引き出します。むしろ、PLMを使い切れていない理由の多くは「業務フローと結びついていない」ことであり、設計OSはPLMの活用度合いを上げる方向に働きます。

多くの設計部で、デザインレビュー（DR）は本来の「設計品質を上流で確定させる場」から、「形式上やっておく会議」に変質しています。

設計DRが形骸化する5つの理由と、AIエージェントで補える部分・補えない部分

次のアクション：30分の業務診断（無料）から始める

設計OSが自社に効くかどうかは、業務分解をしてみないと分かりません。一般論で「効くはず」と言うつもりはなく、設計部門の業務フローを30分で聞き取り、どの業務領域に最も効くかをその場で構造化してお返しする業務診断（無料）を提供しています。診断後に必ず受託や導入をご提案するわけではなく、内製で十分と判断できればその旨をお伝えします。

関連記事：次に読むべき3本

• 設計部長が知らないと損する、図面検索の本当のコスト——年間1,200時間が消える理由（業務別課題編・本記事の前提となる課題定量化）
• 業務OSとは何か——製造業ERPでもPLMでもない、第3の業務基盤の正体（5/2公開予定・業務OSの概念訴求）
• 設計OSパッケージの構成要素と導入ステップ（製品ページ）

設計部門の業務時間は、ツールの数を増やすだけでは戻ってきません。図面・部品表・設計変更という設計者の業務の連鎖を、業務エージェント基盤として一気通貫で動かす設計OSは、すでにあるCAD・PLM投資を活かしながら、設計者の業務時間そのものを取り戻す現実的なアプローチです。まずは30分の業務診断で、自社の業務フローを構造化することから始めてみてください。