「ChatGPTで社内データに繋ぐAIを作ってみよう」と検討を始めたものの、PoCの本体に入ると一気に話が止まる——情シスやDX推進の現場でよく聞く症状です。設計エージェントは、自然言語の問いを受け、図面・部品表・設計変更通知などの社内データから根拠を引き、設計者の判断を支える業務エージェントです。本記事では、その実装アーキテクチャをRAG（検索拡張生成）・MCP（既存システム接続規約）・社内データ連携の3要素に分解し、PoCで詰まるポイントと本番運用に乗せるための判断軸を、現場のDX推進担当者向けに整理します。

1. なぜ「設計エージェント」は社内データに繋いだ瞬間に精度が崩れるのか

汎用LLMに「弊社の似た図面を教えて」と聞いても、当然ですが社内図面の場所も命名規則も知らないため答えられません。そこで「RAG（Retrieval-Augmented Generation：関連データを検索してから生成する仕組み）で社内データに繋げばよい」と発想するわけですが、PoCを始めるとほぼ確実に4つの壁にぶつかります。設計部のDX推進担当者の方であれば、心当たりがある番号があるはずです。

• 壁① スキーマ不揃い：図面ファイルは共有フォルダ、部品表はExcel、設計変更通知はメール、品質不具合は紙のノート——という具合に「同じモノを指している記録」が散らばっており、エージェントが意味で繋げられない
• 壁② 検索精度の崩れ：単純な類似度検索だけでは「形が似ているがまったく違う用途の図面」を上位に出してしまい、設計者の信頼を最初の3問で失う
• 壁③ 判断基準のプロンプト化：設計者がベテランから引き継いだ「この材料は厚みが3mm未満ならNG」の判断は誰のドキュメントにも書かれておらず、エージェントに教える先が存在しない
• 壁④ フィードバックループの欠落：設計者が「この回答は使えない」と感じても、その評価が次回の検索に反映されない仕組みになっており、いつまでも精度が上がらない

この4つの壁は、いずれも「LLMの性能」ではなく「業務記録の構造化」と「業務イベントへの埋め込み」の問題です。GPT-4を最新のClaudeに差し替えても、根本解決には至りません。だからこそ、エージェントを成立させる実装アーキテクチャの設計図を最初に持っておく必要があります。

業務OSは、業務のイベント（受注／設計変更／不具合）が発生した瞬間に、関係する記録を意味で繋ぎ直して次の判断を準備する基盤です。ERPは記録の台帳、PLMは保管庫として完成していますが、業務の意思決定をAIエージェントとともに動かす階層が、これまで存在していませんでした。

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

2. 設計エージェントの実装5層アーキテクチャ

設計エージェントを「業務に乗せて回し続ける」状態にするには、最低でも次の5層を意識した実装が必要です。1〜2層しか整備していない状態でPoCを切ってしまうと、精度の伸び代が頭打ちになり、社内の評価が下がってから巻き返すのは難しくなります。

L1 業務UI層：設計者が「使うほど自然に呼ぶ」入口

独立したチャットアプリを立てるのは初期PoCには向いていますが、本番展開ではかえって使われなくなります。設計者の業務動線は3D CADとPLM画面に張り付いており、別アプリを開く一手間が「使わない理由」になります。3D CADのアドイン、PLMのカスタム画面、Teamsの応答Bot——のように普段使っている画面の中に埋め込むのが成功条件です。

L2 オーケストレーション層：問いを業務タスクに分解する司令塔

「似た図面を教えて」という一言の裏には、用途・寸法・材質・公差・量産数量・調達リードタイムなど、複数の検索軸が隠れています。オーケストレーション層は、設計者の問いを業務テンプレートに照らし、必要な検索手順を組み立てて検索層と統合層に投げる役割を持ちます。製造業の設計エージェント開発でPoC止まりになるプロジェクトの多くは、この層の業務テンプレート辞書（業務分解の知見）を持たないまま、汎用LLMにそのまま投げているために精度が伸びません。

L3 検索層（RAG）：意味で図面・仕様書・変更通知を引き当てる

RAGはベクトル埋め込み（テキストを意味のベクトルに変換する処理）と類似度検索を組み合わせ、関連する社内文書を引き当てる仕組みです。設計エージェントでは、図面の画像特徴量、仕様書のテキスト、部品表の構造、変更通知の差分などを別々のインデックスとして持ち、それらを横断的にランキングする再ランキング（Reranking）が必須になります。「単一の巨大ベクトルDBに全部入れる」設計は、検索の重みが付けにくく、PoC直後に精度劣化する典型パターンです。

L4 統合層（MCP）：既存システムを安全に呼び出す共通規約

MCP（Model Context Protocol）は、エージェントが既存システム（PLM・ERP・3D CAD・社内Wiki等）にアクセスするための共通の接続規約です。重要なのは、MCPは「便利な拡張」ではなく権限管理と監査ログを集中させる必須レイヤとして位置づけることです。設計エージェントが3D CADやPLMに書き込みできる状態を作ってしまうと、誤った書き込みが量産品質に直結します。読み専用・書き込み専用・承認付き書き込みの3段階に分離し、各操作を監査ログに残せる設計を最初から組み込みます。

L5 データ層：最大の作り込みポイント

5層の中で最も時間がかかり、最も差がつくのがこのデータ層の前処理です。社内記録は「同じ部品を別の名前で呼んでいる」「設計変更通知の差分がメール本文の自由記述に埋まっている」「品質不具合のノートが個人PCにある」など、業務上は通用するが機械可読ではない状態が混在しています。スキーマを統一し、属性タグを付け、変更履歴を構造化する作業は、AIエージェント本体の開発工数よりも大きくなることが普通です。「データ層に手をつけずに精度を上げる方法は存在しない」と最初に経営に伝えておくことが、PoCで詰まらないための前提条件になります。

設計OSは、図面・部品表・設計変更通知という3つの業務記録を一気通貫させ、設計者の判断イベントごとに最適化された情報を返す業務エージェント基盤です。既存PLMが記録の保管庫として完成していた構造の上に、業務の意思決定を支える層をAIエージェントで増築します。

設計OSとは——図面・部品表・設計変更を一気通貫させる業務エージェント基盤

3. 精度を決める3要素——どこに作り込みを投じるか

図2は、設計エージェントの回答精度を決める要素を「業務側フィードバックの組込度」と「回答精度の伸び」の2軸で整理したマトリクスです。横軸は使うほど学習が回るかの度合い、縦軸はその結果として現れる業務での体感精度です。象限I（右上）の「業務OS型設計エージェント」のみが、本導入後に精度が育つ構造を持っています。

3つの作り込みポイントは「データ前処理」「再ランキング」「フィードバック取込み」

精度が育つエージェントを作るために投じるべき作り込みは、技術スタックの選定ではなく次の3点です。LLM本体は3年で複数回入れ替わるため、選定の影響は実は限定的です。

1. データ前処理：図面の表題欄から発注図番／改訂番号／材質を抽出し、部品表・変更通知と紐づける作業。ここで6〜8割の工数を使う想定が現実的です
2. 再ランキング：類似度検索の結果に対し、業務文脈（量産品か試作品か、社内向けか客先向けか等）の重みづけで並び替える処理。設計者の業務評価で精度差が目に見えて変わる層です
3. フィードバック取込み：「この回答は使えない／使えた」を1クリックで残せるUIと、その評価を週次バッチで再ランキングに反映する仕組み。最も後回しにされやすく、最も精度差を生む層です

選択肢比較：汎用LLM／単発RAG／業務OS型エージェント

評価軸	A. 汎用LLM直接	B. 単発RAG	C. 業務OS型エージェント
社内データへの接続	なし（業務文書をその都度コピペ）	あり（限定範囲のベクトルDB）	あり（PLM／ERP／CAD／品質DBを横断）
業務イベント連動	なし	なし（独立アプリ）	あり（設計変更通知／DRに自動起動）
権限管理・監査	個人責任	システム側で部分対応	MCP層で集中管理＋監査ログ
業務側フィードバックの取込	仕組みなし	未実装が多い	業務UIから1クリックで評価→学習
精度の伸び方	3週間で頭打ち	3ヶ月で停滞	運用で半年〜1年かけて育つ
初期投資（目安）	0〜50万円	300〜800万円	1,000〜2,000万円超
本番投入の難易度	個人運用なら容易	部署内で止まりやすい	業務分解＋実装＋運用設計の総合力が必要

ROI試算の考え方——「節約工数」ではなく「判断到達時間」で測る

設計エージェントのROIを「図面検索の時短×単価」で試算すると、本導入の判断が下りないケースが多くあります。設計者の業務単価は把握しやすいものの、節約工数の見積もりは控えめに置きがちで、結果として投資判断のテーブルに乗らないからです。代わりに使えるのが「判断到達時間」です。「類似案件の見積を回答できるまでの時間」「設計変更通知のインパクト範囲を特定できるまでの時間」「FMEAの過去類似事例を参照するまでの時間」を、それぞれストップウォッチで実測し、Before／Afterで比較します。判断到達時間が短くなると、案件あたりの「設計者待ち時間」が縮み、調達・営業・品質の後工程に与える波及効果のほうが、節約工数より大きいことが多いためです。

図面検索に費やす時間は、設計者個人の生産性問題ではなく、案件あたりの判断到達時間を遅らせる業務全体のボトルネックです。年間1,200時間という数字は、検索作業そのものよりも、検索を待っている間に止まっている調達・営業・品質の判断時間を加算した姿として捉えるべきです。

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

4. 反論への先回り——「ChatGPTで足りる」「内製で十分」と言われたら

反論①「個人でChatGPTを使えば十分では？」

個人が自分の作業の補助としてChatGPTやClaudeを使うのは、引き続き有効です。むしろ会社として禁止しても、シャドーAIとして広がるため止められません。論点は別にあります。設計エージェントが解こうとしているのは「個人の作業時短」ではなく、「設計者の判断が、業務上の意思決定として組織に乗る」状態です。誰がいつどの図面を参照したか、誰の判断で設計変更を承認したか、品質不具合の対策が次の設計に反映されているか——これらの業務イベントと結びついて初めて、エージェントは品質保証や監査の対象になります。個人利用のChatGPTでは、業務記録としての残り方が個人裁量となり、組織の意思決定としては機能しません。

反論②「内製で十分では？」

内製で十分にやり切れるケースは確かにあります。具体的には、(a) 業務範囲を1つの部署に絞り、(b) データ層の前処理を6ヶ月かけてやれる人員がおり、(c) MCP層の権限管理を社内のセキュリティポリシーに合わせて自前で設計できる、の3条件が揃った場合です。逆に言えば、この3条件のうち1つでも欠ける場合は、内製と外部実装の役割分担を最初に設計するほうが結果的に早く本番に届きます。データ層の前処理は外部に出さず社内で握る、オーケストレーション層とMCP層は外部実装、L1の業務UIは設計者と一緒に内製で作る——のような層別役割分担が、製造業の中堅企業では現実解になることが多いと考えています。

5. 自社の準備度を5項目で自己診断する

設計エージェント実装の準備度を、次の5項目で確認できます。3つ以上「Yes」が付くなら、外部の実装パートナーと層別役割分担の議論ができる段階です。1つ以下なら、まず業務分解とデータ層の整理から始めるほうが投資効率が高くなります。

• 図面・部品表・設計変更通知が、それぞれ「どこに置かれているか」を1枚に書ける（データ層の見取り図がある）
• 設計者の「困った業務イベント」を3つ以上、具体名で挙げられる（業務分解の起点がある）
• PLM／ERP／3D CADへの読み・書きの権限ポリシーが、文書として存在する（MCP層の設計に必要）
• 過去に内製PoCで止まった経験があり、止まった理由を業務文脈で説明できる（同じ罠を回避できる）
• 設計エージェントの「成功」を、節約工数ではなく業務指標（判断到達時間／案件あたり待ち時間）で定義し直す覚悟がある

6. よくある質問（FAQ）

Q1. RAGとMCPは何が違いますか？

RAGは「社内文書を意味で検索して回答に使う仕組み」、MCPは「既存システムにエージェントが安全に接続するための共通規約」です。役割が異なり、片方だけでは設計エージェントは成立しません。RAGは検索層（L3）、MCPは統合層（L4）に位置します。

Q2. オープンソースで全部組めますか？

技術的には可能ですが、業務イベントとの結びつけと運用設計が自前負担になります。最大コストは「LLMの利用料」ではなく「データ前処理」と「業務側の運用設計」です。オープンソース化で減るのは前者ですが、後者は内製でも外部実装でも避けられません。

Q3. 投資の総額はどれくらい見込めばよいですか？

業務範囲とデータ層の現状で大きく変わります。設計部単独で社内データが概ね整理済みなら、初期1,000〜1,500万円規模が目安です。データ層から整理する場合は、前処理だけで500〜800万円の追加投資が必要なケースもあります。本番運用後の運用費は、月額50〜150万円の範囲が中堅製造業での実勢感です。

Q4. 既存PLMがあるのにエージェントが必要ですか？

PLMは記録の保管庫として完成しており、エージェントとは競合しません。PLMが「記録の場所」、設計エージェントが「業務イベントごとに記録を意味で繋ぎ直して判断を支援する層」、という関係です。PLM導入後も設計者の業務が変わらなかった原因の多くは、この「業務イベントとの結びつけ」の層が存在しなかったことに起因します。

Q5. 受託と内製、どちらで始めるのが現実的ですか？

5層のうちL1業務UIとL5データ層は社内が握り、L2オーケストレーション・L3 RAG・L4 MCPは外部実装に任せる層別役割分担が、中堅製造業では現実的な選択肢です。社内人員のスキル習熟と並走で外部実装を進めれば、本番後の運用も社内に残せます。

7. 次のアクション——業務分解から始める実装相談

設計エージェントの実装は、技術スタック選定ではなく業務分解から始まります。どの業務イベントを起点にし、どのデータ層を最初に整理するか——を90分の業務分解セッションで言語化すれば、その後の見積精度が桁違いに上がります。社内で内製を進めるか、層別役割分担で外部実装を併用するかの判断も、その時点で見えてきます。設計エージェントの実装相談は、業務分解の同席から始めることをおすすめします。

関連記事

• 業務OSとは何か——製造業ERPでもPLMでもない、第3の業務基盤の正体
• 設計OSとは——図面・部品表・設計変更を一気通貫させる業務エージェント基盤
• 設計部のAI内製化が失敗する5パターン——よくある罠と、4日間ブートキャンプが解く理由