「ChatGPTもCopilotも、設計者の手元に届いている。それでも、設計者一人あたりの工数は3年前と本質的に変わっていない」——中堅製造業の設計部長から、こうした声を聞く頻度が増えています。AI内製化を進めたはずなのに、図面検索の時間も、設計DRの議事録作成も、新人への暗黙知の引継ぎも、なぜか減らない。

本記事では、設計部のAI内製化が失敗する5つのパターンを業務分解の視点で整理し、それぞれを「ツール選定の問題なのか、人材設計の問題なのか、組織設計の問題なのか」で切り分けます。最後に、4日間のブートキャンプという形式が、この5パターンを構造的に回避する設計になっている理由を解説します。設計部長・情シス部長・DX推進担当の方を想定読者としています。

設計部AI内製化を「ツール導入」と捉えると、なぜ失敗するのか

設計部のAI内製化を「ツール導入の問題」と捉えている限り、失敗のパターンは繰り返されます。なぜなら、設計部のAI活用は3つの層を貫通する作業であり、ツール契約はその第1層にすぎないからです。

設計部AI内製化の3層構造

• 第1層：ツール契約層——ChatGPT Enterprise、Microsoft Copilot、Claude等のAIサービスを選定し契約する
• 第2層：業務アダプテーション層——設計部の図面、部品表、社内設計基準書、過去のDR議事録、FMEA記録等を、AIが参照可能な形で構造化する。プロンプトテンプレートを業務工程ごとに整備する
• 第3層：業務プロセス再設計層——DR会議の進め方、ECN（設計変更通知）の発行プロセス、新人OJTのカリキュラム自体を、AIを前提に組み直す

多くの中堅製造業は、第1層に投資して第2層・第3層を空白のまま放置しています。情シスはAIサービス契約を完了させ「あとは現場が使うだけ」と認識する。現場の設計者はChatGPTを開いてみるが、自分の手元の3面図を投げても部品表が出ない、過去の類似案件を聞いても「申し訳ありませんが、社内データへのアクセス権限がありません」と返される。3ヶ月後、ログイン頻度は導入直後の1/10になる——よくある光景です。

第1層から第3層まで通すには、ツールベンダー任せでは難しい。ベンダーは第1層の専門家ですが、御社の設計DR運用やECNフローの暗黙知までは持ち合わせていない。情シスは第2層・第3層に踏み込む業務知識がない。設計部は第2層・第3層を扱う技術スキルがない。この三方ねじれが、これから挙げる5つの失敗パターンを生みます。

設計部のAI内製化が失敗する5パターン

パターン1：全社AI導入後、設計者の利用頻度が3ヶ月で1/10に減る

最も多い失敗パターンです。情シス主導でChatGPT EnterpriseやCopilotを全社展開し、初週は設計部の利用率も80%を超える。しかし3ヶ月後、月間アクティブユーザーは1〜2割に落ち込む。原因は第2層（業務アダプテーション層）の不在です。設計者がAIに投げたい質問は「この3面図の類似品を5本出して」「2018年の客先A社向け案件の設計変更履歴を要約して」といった社内データ前提のものですが、汎用AIは社内図面・社内部品表・過去のDR議事録にアクセスできません。結局「ChatGPTは情報収集と英訳には使えるが、設計業務の本丸には使えない」という結論に落ち着く。これは「ツールが悪い」のではなく、社内データを構造化してAIに渡す第2層の作業が抜け落ちている結果です。

パターン2：情シスが共通プロンプトを整備するが、現場は使わない

第2層に手を入れた企業でも、主体が情シスだけだとここで止まります。情シス部門が「プロンプトテンプレート集」を整備し、設計部に配布する。しかし配布されたプロンプトは「業務の3割しかカバーしない一般論」になりがちです。設計部の業務は「DR資料作成」「ECN起票」「客先承認図の修正」「部品調達依頼の起票」「新人への図面指導」など細分化されており、それぞれに固有の業務文脈・社内ルール・例外処理が存在します。情シスが現場の暗黙知を知らないまま作ったテンプレートは、設計者にとって「使うより手で書いた方が早い」品質に留まる。第2層は、設計部の業務を肌で知る人材が主体的に作る必要があります。

パターン3：外部ベンダーに丸投げするが、PoCで止まる

「社内に詳しい人材がいないから、外部ベンダーに業務分析からPoC構築までお願いする」——よく選ばれる経路ですが、ここでも止まりやすい。外部ベンダーは技術提案には強いものの、御社の設計部の業務工程を聞き出す力にバラつきがあります。ヒアリングが浅いまま「とりあえず動くもの」を作ると、PoCはデモ環境では動くが実運用に耐えないものになる。「PoCは成功したが本番展開には至らなかった」という結末は、業務工程の言語化が先行投資されていなかったことの帰結です。本来は、設計部側で業務分解（DR・ECN・部品表メンテ・新人教育などの業務工程をフロー図で整理）を済ませてからベンダーと組むのが筋ですが、その業務分解能力が社内に育っていないことが多い。

パターン4：設計者の1人が個人プロトタイプを作るが属人化する

設計部内に技術好きな1人がおり、Pythonを書ける、APIも触れる、ノーコードツールも使える。彼が個人で「過去図面類似検索」「DR議事録自動要約」「部品表差分チェック」などのプロトタイプを作る。動く。便利だ。設計部内の評価も上がる。しかし——彼が異動した瞬間、すべて止まる。引き継ぎを試みても、業務OS（業務工程と技術スタックの対応関係）が文書化されていないため、後任には何が動いているか追えない。「個人の力技」と「組織の業務基盤」のあいだに大きな段差があります。第3層（業務プロセス再設計層）まで踏み込んでいないため、属人化が解けません。

パターン5：経営号令だけが先行し、現場が疲弊する

最後のパターンは、経営層が「AIで設計工数を半減させろ」と号令を出すケースです。号令自体は悪くないのですが、設計部にとっては「業務プロセス再設計の権限」と「組織横断の意思決定権」が同時に降りてこないと動けません。設計DRの進め方を変えるには品質保証部の合意が必要、ECN発行プロセスを変えるには製造部・購買部の同意が必要、社内データ構造を変えるには情シスの工数確保が必要。経営号令だけで権限と工数が下りないと、設計部はAI導入と既存業務の二重負担で疲弊し、結果として「AIは使えなかった」という総括に着地します。

5パターンと3層構造の対応関係

5パターンを3層構造で整理すると、共通する構造が見えてきます。パターン1は第2層の欠落、パターン2は第2層の主体ミス、パターン3は業務分解の不足、パターン4は第3層の欠落、パターン5は組織設計の問題——として並びます。共通項は第2層と第3層を担う人材が社内に育っていない、という1点です。第1層のツール契約はお金で買えますが、第2層・第3層を担える人材は、買うのも借りるのも難しい。ここが内製化の勝負所になります。

4日間ブートキャンプは、第2層と第3層を担う人材を一気に育てる装置

私たちが提案する4日間のブートキャンプは、ツール販売の付帯研修ではなく、業務変革のドライバー人材を育てる装置として設計されています。受講前後で何が変わるかを、職種別に整理します。

• 設計者：自部署の業務工程をフロー図で分解し、各工程を「AIで自動化すべき部分／半自動化する部分／人間が判断する部分」で切り分けられる。プロンプトテンプレートを自分で設計し、改修できる
• 情シス／DX推進担当：設計者からの業務ヒアリングを深く行い、社内データ構造の改修方針を提示できる。第2層・第3層を支えるアーキテクチャ判断ができる。内製と外注の境界線を業務単位で持てる
• 経営層・経営企画：投資対象としての評価軸を持つ。3年スパンの業務OSロードマップに対して、稟議で説明できる材料を持つ

4日間で「設計者×AIエンジニア」のペアを育成する形式を取るのは、第2層と第3層を一人の頭の中で接続できる人材が、現場では最もボトルネックになっているからです。ChatGPTのプロンプトの書き方だけ学んでも、ECN発行プロセスの再設計はできない。逆にプロセス改革論だけ学んでも、AIで何が技術的に可能かが分からない。両方を同時に手を動かして体得することが必要です。

投資対象としての評価軸

価格はここでは出しませんが、投資判断のフレームだけ示します。AI内製化への投資は、「ツール費用 × 人数」だけで考えると過小評価になります。本来は「業務OSを描ける人材を何人持てるか」「その人材が3年間でいくつの業務工程を再設計できるか」で評価する。ツール費用と人材育成費用が概ね同程度で、業務再設計の年間アウトプットが3〜5工程——という比率が一つの目安です。投資の本体はツールではなく人材、というのが業務OS時代のROI観です。設計OSの全体像と、各業務工程との接続関係は設計OSパッケージのページに整理しています。

自己診断：あなたの設計部はAI内製化の前提条件を満たしているか

本論の整理を踏まえ、貴社の設計部がAI内製化に踏み出す前提条件を満たしているか、5項目でセルフチェックしてみてください。

1. 設計部内で、AI活用の最終責任者が明確に1人定まっているか
2. 設計部の業務工程（DR・ECN・図面検索・新人教育等）が、文書化されているか
3. AI導入後の業務プロセス再設計の権限が、現場部長レベルに付与されているか
4. 情シスと設計部の合同会議が月1回以上の頻度で開催されているか
5. 過去1年で、設計部内のAIプロトタイプが2つ以上稼働しているか

3つ以下の場合、AI内製化に投資する前に、組織設計の見直しが先です。ツールは買い替えられますが、組織設計の不備はツールでは解けません。逆に4つ以上満たしている場合、ブートキャンプ型の人材育成への投資が、最も費用対効果の高い次の一手になります。

反論への先回り：「外注の方が早いのでは？」

「内製と言われても、外注の方が早いのではないか」——もっとも自然な反論です。確かに、最初の半年は外注の方が圧倒的に早く動きます。ベンダーは技術スタックも開発体制も持っており、社内人材を育てるよりも結果が出るまでの時間は短い。これは事実として認めるべきところです。

ただし、2年目以降の景色が分岐します。業務プロセスは毎年変わります。新製品の投入、客先要求の変化、品質基準の改訂、組織再編——その度に既存のAIワークフローを修正・拡張する必要があります。修正のたびに外注すれば毎回見積依頼から始まり、改修費が積み重なる。3年目には、初期構築費の2〜3倍の累積コストになっているケースを支援案件で複数見てきました。

外注を選ぶべきケースは、(1) 単発のPoCで終了することが明確、(2) 戦略的に技術投資をしない部署、(3) ツール選定だけで業務改革の意図がない、のいずれかです。内製を選ぶべきケースは、(1) 業務プロセスごと変えていく覚悟がある、(2) 設計部・情シスを横断する権限が経営層から降りている、(3) 3年以上の継続投資ができる、のいずれかです。ブートキャンプは、後者「内製を選ぶ」企業のための加速装置として位置づけてください。すべての企業に勧められる施策ではありません。

次のアクション：4日間で設計者×AIエンジニアを育てる

設計部のAI内製化が失敗する5パターンは、いずれも第2層（業務アダプテーション）と第3層（業務プロセス再設計）を担う人材の欠如に集約されます。逆に言えば、この人材を社内に持てれば、ツール選定はその後の問題です。

4日間のブートキャンプは、設計者・情シス・DX推進担当の三役を、自社の業務文脈で動けるレベルまで育成する設計になっています。受講後の到達点、カリキュラム詳細、推奨される受講者構成について、まずは説明会の資料をご覧ください。

該当する読者が次に読むべき記事

• 業務OSとは何か——製造業ERPでもPLMでもない、第3の業務基盤の正体（業務OS概念の入門。本記事の3層構造の前提知識）
• 設計OSとは——図面・部品表・設計変更を一気通貫させる業務エージェント基盤（内製化のターゲットとなる業務基盤の全体像）
• 設計DRが形骸化する5つの理由と、AIエージェントで補える部分・補えない部分（業務プロセス再設計の代表テーマである設計DRの構造）