「設計OSを内製したいが、どこまで自社で開発すべきか分からない」「外注に出すと言語化されない業務知識が失われる」「PoCの試作は社内でできたが、本番運用は外注先がいないと進まない」——中堅製造業の設計部・情シス部から最も多く挙がる悩みが、内製と外注の境界線をどこに引くかという論点である。

本稿は「全部内製」「全部外注」の二択ではなく、設計OS構築を4層モデルに分解し、3つの判断軸で内製・共同・外注を仕分ける考え方を提示する。情シス部長・DX推進担当・経営企画が稟議や外注選定の判断軸として使える実務枠組みを目指す。

設計OS構築を「全部内製」か「全部外注」かで考えると失敗する4つの理由

設計OS（設計者の業務を図面・部品表・設計変更まで一気通貫させる業務エージェント基盤）の構築では、初期段階で「全部内製で行く」「全部外注で行く」のどちらかに振れる組織が多い。だがいずれも次の4つの失敗パターンに陥りやすい。

• 全部内製の落とし穴1：LLM・GPU・運用基盤の重さに人材が消耗する。業務改善のための開発時間が、外部技術の追従に削られる。1年経っても業務に貢献する機能が立ち上がらない。
• 全部内製の落とし穴2：技術の進化速度から取り残される。RAGアーキテクチャ・MCP・モデルAPIは半年単位で標準が変わる。自社開発した方式が陳腐化する。
• 全部外注の落とし穴1：業務知識が外注先に流出する。設計DR基準・図面検索の業務文脈・品質判断軸など、競争力の核となる暗黙知が外部に蓄積される。撤退時に再構築不可能になる。
• 全部外注の落とし穴2：業務の制御権を失う。仕様変更のたびに見積・契約交渉が必要で、現場の改善サイクルが月単位に伸びる。設計者の業務改善速度が決定的に遅れる。

4つに共通するのは、「業務知識の集約度」「データ・APIの統制」「改善サイクルの速度」の3軸を区別せず、技術スタック全体を一括で内製／外注の判断にかけてしまう点である。設計OSは複数のレイヤから構成され、各レイヤで内製・外注の最適解が異なる。

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

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

設計OSは記録ではなく業務そのものを実行する層を含むため、業務知識の集約は外注化できない。一方でLLMやGPU運用は記録層に近く、外注化が合理的だ。この線引きを言語化することが、本稿の目的である。

自社の内製・外注分けが健全か——5つのチェック（自己診断）

まず現状の分け方が健全かを下記5項目で確認する。3つ以上「いいえ」がつく組織は、内製と外注の境界線が再設計フェーズにある。

1. 設計DR基準・図面検索の業務文脈など、業務知識の集約は社内のドキュメント・コード・人にしか存在しない状態か。
2. 外注先に渡しているデータの種類・量・頻度を、情シスが台帳で管理しているか。
3. 外注先で開発したエージェントの業務ルール（プロンプト・判定基準）を、自社が読み取り・修正できる形式で保持しているか。
4. LLM API・GPU・ベクターDB等のインフラ層は、自社で内製せずSaaS／パッケージ調達で済ませているか。
5. 業務改善の優先順位を決める権限（次に何を作るか）は、外注先ではなく自社の業務オーナーが握っているか。

設計OSを4層モデルに分解する——内製・共同・外注の境界線

設計OSは技術スタックを単に積み上げたものではなく、業務知識の濃度に応じた4つの層に分解できる。L4が最も業務に近く、L1が最も技術基盤に近い。

L4 業務知識・暗黙知層——必ず自社で握る

設計DR基準・図面検索の業務文脈・品質判断軸など、長年の業務蓄積から生まれた暗黙知が集まる層。ここを外注すると、競争力の核を外部に蓄積させてしまう。撤退時に外注先のデータベースから取り戻すことができず、過去20年分の業務継承が断絶する。L4は必ず社内のドキュメント・コード・人で保持する。

L3 業務エージェント・ワークフロー層——共同実装が現実解

業務ルール（プロンプト・判定基準）と汎用的な技術実装（RAG・MCP・エージェント設計）が交わる層。業務ルールは自社が定義し、技術実装はAI受託パートナーと共同で進める。PoCの段階から業務オーナーが要件定義に参加し、テストケースは自社で書く。受託パートナーは技術側の品質を担保するが、業務側の判定は自社が握る。

L2 AI基盤・モデル層——パッケージ調達で十分

LLM API・推論エンジン・ベクターDBの層。技術進化速度が半年単位で速く、自社開発しても陳腐化する。図面バンク（株式会社New Innovations提供）のような特化型パッケージや、Anthropic・OpenAI・Google等のLLM API調達で十分。ここで自社開発に時間を割くと、業務改善が止まる。

L1 インフラ・データ基盤層——SaaS／クラウドで委ねる

クラウド・GPU・監視・SLA管理の層。専門事業者に任せた方が安く、安定する。ただし、データの主権（どのデータをどこに置くか、APIキーは誰が持つか）は必ず自社が握る。インフラの運用は外注、データの管理権限は自社、という分業が原則。

設計OSは、CADやPLMの代替ではなく、その上で図面・部品表・設計変更を業務として一気通貫で動かす業務エージェント基盤

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

内製・外注を分ける3つの判断軸

4層モデルの各レイヤをさらに細かく仕分けるには、次の3軸でスコアリングする。3軸とも「高」なら内製必須、2軸が「高」なら共同実装、2軸以上が「低」なら外注で問題ない。1軸でもデータ主権の軸が「高」のときは、データ管理権限を譲ってはならない。

軸1 業務知識の集約度——「暗黙知の濃度」

その機能が動くために必要な業務知識が、どれだけ自社固有で言語化困難か。設計DRの判定基準は組織ごとに違い、新人に教えるにも数年かかる。これが「高」の領域は、外注しても要件定義に半年以上かかり、結局自社で書き直すことになる。

軸2 データ・APIの統制——「情報主権」

業務データが外部に渡る経路を、自社が管理できるか。設計図面・部品表・サプライヤー情報は競争力の核であり、APIキーの管理・データの保存場所・学習への利用可否は自社が握らなければならない。クラウドベンダーやLLMプロバイダの規約変更でデータの取り扱いが変わるリスクがある以上、軸2は「高」固定で扱うべき領域が多い。

軸3 改善サイクル速度——「イテレーション頻度」

そのレイヤを月次・日次・週次のどの頻度で更新したいか。業務ルールやプロンプトは日次〜週次で改善したい。基盤モデルやインフラは四半期〜年次の改善で問題ない。改善頻度が高い領域を外注すると、見積・契約交渉が改善速度を律速する。日次改善が必要な領域は必ず自社の手元に置く。

レイヤ／構成要素	軸1 業務知識	軸2 データ主権	軸3 改善速度	判定
L4 設計DR基準・図面検索の業務文脈	★★★ 高	★★★ 高	★★★ 高	内製必須
L3 業務エージェント・プロンプト	★★ 中	★★ 中	★★ 中	共同実装
L2 LLM／推論モデル／ベクターDB	★ 低	★ 低	★ 低	外注／SaaS
L2-α 図面バンク／業務OSパッケージ	★★ 中	★★ 中	★ 低	パッケージ調達
既存PLM／ERP／CAD API連携	★★ 中	★★★ 高	★★ 中	共同実装（APIキー自社）
L1 クラウド・GPU・監視	★ 低	★★ 中	★ 低	SaaS／受託運用

境界線の引き直しが起きるタイミング

4層モデルと3軸の枠組みは一度決めて終わりではない。次の3つのトリガで境界線を引き直す機会が来る。

• 業務イベント量の増加：図面検索が月100件から1,000件に増えるなど、業務イベント量が10倍を超えると、L3層の業務ルールの設計責任が共同から内製寄りにシフトする。
• 規制・コンプライアンスの変更：輸出管理・GDPR・IATF 16949等の規制改定で、データ取り扱いの責任が外注先から自社に移ると、軸2の重みが急上昇する。
• 外注先の人材入れ替え：受託先のキープレイヤーが退職した場合、業務知識が外注先で再構築されるまで内製比率を上げて補完する。

「現場発のAI内製依頼」を全部やる／全部止めるの二択で捌くと、シャドーAI繁殖か業務停滞のどちらかが起きる

情シス部長が現場から殺到する「AI内製依頼」をどう捌くか

よくある反論への先回り

「全部内製しないと自社のノウハウにならない」への回答

L4の業務知識・暗黙知層は必ず自社で握るべきだが、L1のクラウドインフラ・L2のLLMモデルまで自社開発する必要はない。ノウハウとして残すべきは「業務をどう動かすか」のルールであり、「LLMをどう動かすか」のインフラ知識ではない。インフラ層の内製は人材消耗の原因になり、本来注力すべき業務知識の集約に手が回らなくなる。

「業務OSパッケージを買えば判断不要では」への回答

業務OSパッケージはL2-α層を埋めるが、L4の業務知識・L3の業務エージェントの構成は必ず個社別になる。パッケージは選択肢を狭めるためのものではなく、L1・L2を委ねた上で、L3・L4に集中投資するための土台と捉えるべきだ。「業務OSを買えば全部解決」と考える組織は、自社で書くべき業務ルールまでパッケージに丸投げし、業務に合わない使い方を強いられる。

よくある質問

Q1. 中小製造業（売上50億円未満）にも4層モデルは適用できますか

レイヤ分解の考え方は適用できるが、人材面でL2-αのパッケージ調達と L1のSaaS委託の比率を高めることをすすめる。社内エンジニアが2-3名以下なら、L3も受託パートナーとの共同実装に振り、L4の業務ルール定義に注力する。

Q2. 既に全部外注で始めてしまった場合、内製化への移行手順は

3段階の移行が現実的。第1段階：外注先からL4業務ルールのドキュメント・テストケース・プロンプトを自社形式で受領する権利を契約に追記する。第2段階：L3の業務エージェントのレビュー権限を自社に集約し、業務オーナーが改善優先順位を決める。第3段階：L4の業務ルール改修を内製ペアプロで実施し、徐々に内製比率を上げる。9〜18ヶ月の移行期間が現実的。

Q3. AI受託パートナー選定で見るべき項目は何ですか

業務分解能力（業務ルールを引き出すヒアリング力）、引き継ぎ可能性（自社で読める形式でコード・プロンプトを残せるか）、改善速度（PoCから本導入までのリードタイム）の3点。技術スタックの新しさよりも、業務側の解像度と引き継ぎ容易性を優先する。

Q4. 業務OSパッケージとAI受託の使い分けは

業務OSパッケージはL2-α（汎用業務基盤）を埋め、AI受託はL3（個社業務エージェント）を埋める。両者は競合ではなく補完関係にある。L2-αをパッケージで埋めることで、AI受託の費用と期間をL3・L4の業務固有部分に集中させられる。

Q5. 内製チームのスキルを上げる方法は

L3層の業務エージェント構築を、AI受託パートナーと自社エンジニアのペアプロで進めるのが最短経路。座学研修だけでは業務エージェントの設計感覚は身につかない。実装ブートキャンプ（4日間集中型）と業務OS共同実装の組み合わせで、3〜6ヶ月でL3を内製化できるチームを育てた事例がある。

次のアクション

設計OS構築の内製・外注配分は、4層モデルと3軸のフレームを使えば30分で初期案を作れる。自社の現状を診断し、外注比率の見直しを開始するために、業務OS導入戦略相談（無料30分）を活用いただきたい。

次に読むべき記事

• 情シス部長が現場から殺到する「AI内製依頼」をどう捌くか——5つの失敗パターンとガバナンス設計
• 設計OSとは——図面・部品表・設計変更を一気通貫させる業務エージェント基盤
• 業務OSとは何か——製造業ERPでもPLMでもない、第3の業務基盤の正体