「設計部から図面要約AIを試したいと相談された矢先、品質保証から不適合報告書の分類ツールの話が来て、調達部はもう独自にChatGPT Enterpriseを契約していた」——中堅製造業の情シス部長から、こうした相談がここ半年で急増しています。経営からは「AIで全社的に何かやれ」と指示が下り、現場各部署からは個別最適の依頼が同時多発し、シャドーAIの兆候も見え始める。本記事では、製造業の情シス・DX推進担当が直面する「AI内製依頼の捌き方」を、現場で観察される5つの失敗パターンと、ガバナンス設計のフレームから整理します。

課題の構造化——なぜAI内製依頼は情シスに集中するのか

AI内製依頼が情シスに殺到する理由は、組織構造に根ざしています。第一に、経営層が「AI活用」を経営方針に掲げると、執行責任は多くの場合で情報システム部門に降ります。AIはツールであり、ツールは情シスの管轄、という1990年代からの整理が今も生きています。

第二に、現場各部署はベンダー営業や業界メディアから日々AI事例を浴び、「便利そう」「他社が使っているらしい」を理由に個別検討を始めます。設計部はCAD連携系のツール、品質保証は外観検査系、調達は見積もり生成系、人事は採用面接の議事録整理系——それぞれが独立した文脈で動き、情シスへ「契約していい？」「ガバナンス的にOK？」と確認が殺到します。

第三に、社員個人レベルでも生成AIサービスの個別契約が起きます。月3,000円の個人サブスクリプションは経費精算で通り、社内データを誤って外部AIに投げるリスクが顕在化します。情シスがすべてを把握することは現実的に不可能です。

既存の対応策——「全社一括でChatGPT Enterpriseを契約する」「禁止令を出す」「ガイドラインを配布する」のいずれも単独では機能しません。一括契約は業務文脈に合わない汎用ツールを押し付けることになり、現場が使わない・別の個別契約に流れる。禁止令はシャドーAIを地下に潜らせるだけ。ガイドラインは読まれません。

業務に応じてAI活用の形を分解し、内製・外注・購買の境界を引き直す作業が、情シス部門の新しい主業務として浮上しています。下図のように、依頼の発生源は経営層・各業務部署・社員個人と多層化しており、情シスはそれらを単一のキューで捌くのではなく、業務ドメインの深さに応じて3層に仕分ける機能を担う構造になります。

本論——5つの失敗パターンと、ガバナンス設計のフレーム

現場で観察される失敗パターンは大きく5つに整理できます。それぞれ「なぜ起きるか」「初期症状」「悪化したときの姿」「回避するための着眼点」を順に見ていきます。下のグラフは、5パターンそれぞれが時間経過とともにどのように工数浪費を累積させるかを示したものです（観察ベースの推定値）。

パターン1：情シス丸投げ型

経営層が「DX推進担当はあなたですよね」と情シス部長を指名し、現場の業務分解は丸ごと情シス側に降ろされるパターン。情シス側は業務ドメインの知見が薄いため、設計部の図面検索の業務フローや、調達部の見積もり集約の現場運用を、ヒアリング1時間で把握しきることはできません。結果としてベンダー営業の提案資料がそのまま稟議に上がり、業務適合度の検証なく導入される。半年後、現場が「使い物にならない」と告げて、ツールは静かに塩漬けになります。

設計部単体で「現場の困りごとから入ったAI内製化」は、業務分解の解像度が経営目線に届かず、ガバナンス不在のまま個別最適に終わる傾向が観察されます。

引用元：設計部のAI内製化が失敗する5パターン——よくある罠と、4日間ブートキャンプが解く理由

パターン2：シャドーAI分散型

各部署が独自にベンダーと契約し、社内に類似機能のAIサービスが3つも4つも並列稼働するパターン。設計部はCAD連携AIサービス、品質保証はNotion AI、調達はマイクロソフトのCopilotで、それぞれ部門予算で月10万円ずつ支出している。情シスは契約把握すらできず、データガバナンスも分散します。3年経つと「どの部署が何を使っているか分からない」状態に陥り、棚卸しコストだけで数百人月の負債が積み上がります。

パターン3：要件未定外注型

「うちには分かる人材がいないので、要件込みで全部任せたい」と外注すると、委託先のSIerは契約上業務分解の責任を負わないため、汎用パッケージをカスタマイズして納品します。納品後3ヶ月で「現場で使われていない」と報告が上がり、追加要件の都度カスタマイズ費が積み増し、当初予算の2倍3倍に膨らみます。要件定義をできる人材が社内に育たないため、5年経っても同じ構造を繰り返します。

パターン4：ツールだけ揃えて人材ゼロ型

経営判断で全社にChatGPT Enterpriseを配布したが、現場の業務にどう組み込むかを設計する人材が育っていないパターン。アカウントの利用率は配布3ヶ月で30%を切り、半年後には10%以下に落ちます。「使い方が分からない」「業務とつながらない」が現場の声として上がりますが、研修を外注すると一般的なプロンプト集の配布に終わり、自社業務の文脈に落とせません。

製造業の業務OSは、ERPやPLMの上位レイヤーとして設計・調達・品質・生産技術の業務そのものを駆動するものであり、汎用AIツールの寄せ集めとは射程が異なります。

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

パターン5：PoC無限ループ型

「まずはPoCから」と小さく始めるが、PoC終了時の判定軸を事前に決めていないため、本導入の意思決定が先送りされ続けるパターン。半年に1回ベンダーを変えてPoCを繰り返し、3年経過しても本導入記録がゼロという事例も観察されます。組織内に「PoCをやった経験」だけが蓄積し、業務側のリーダーは疲弊して離脱、情シス側は「またPoCか」と冷めていきます。

解決フレーム——3層に分けて捌く

5パターンに共通する根本原因は、「AI内製依頼を1つのカテゴリとして扱っている」点にあります。実際には依頼の性質を3層に分けて捌く設計が必要です。

第1層は「個社別エージェント受託で外部委託する業務」。設計OSや調達OSのように業務ドメインの深い知識が必要で、長期的に基幹システムと連携する案件。情シスが要件整理の事務局となり、業務部署のリーダーと外部パートナーで個社別エージェントを設計・実装します。

第2層は「ブートキャンプで内製人材を育てる業務」。日常業務に近く、現場リーダーが自ら手を動かしてカスタマイズしたほうが定着率が高い領域。設計者がCADのプリ／ポスト処理を自動化したい、調達担当が見積もり比較をスクリプト化したい、といった依頼は、4日間程度の集中研修と1ヶ月のメンタリングで内製の足場が組めます。

第3層は「全社一括契約で済ませる業務」。議事録整理、メール下書き、ドキュメント要約のような汎用業務は、ChatGPT EnterpriseやCopilot for Microsoft 365などの一括契約で十分です。情シスはガイドラインとログ監査体制を作ることに集中します。

設計OSは図面・部品表・設計変更を一気通貫させ、PLMやCADの上位レイヤーとして設計業務全体を駆動する業務エージェント基盤として位置づけられます。

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

依頼を受けた時点で「これは何層の話か」を仕分けるルールを明文化すれば、5つの失敗パターンの大半は事前に回避できます。

自己診断ミニチェックリスト

以下5項目のうち3項目以上が該当する場合、AI内製依頼の捌き方を再設計する段階にあります。

1. 過去1年で、現場部署から情シスへのAI関連相談が月3件以上発生している
2. 経営層から「AIで全社的に何か」と方針が下りているが、具体的なKPIが定まっていない
3. 部門予算で個別契約されているAIサービスを、情シスが全数把握できていない
4. PoCを実施したが、本導入に至らず終了した案件が過去2年で3件以上ある
5. 全社一括契約したAIツールの利用率が、配布後半年で30%を切っている

ガバナンス設計の3アプローチ比較

アプローチ	主体	強み	弱み
現場直行型	各部署が独自にベンダー契約	業務適合度は高いが部署内に閉じる	シャドーAI化・データ分散・ガバナンス不能
情シス丸投げ型	情シスが全案件を巻き取り	統制は効くが業務理解が浅い	現場が「使えない」と評価し定着しない
業務OS統合型	業務リーダー＋情シス＋外部パートナーの三者で層別に整理	業務適合度とガバナンスを両立	初期の体制構築に3〜6ヶ月の投資が必要

業務OS統合型は、第1層を外部パートナーと共同実装、第2層を内製人材育成、第3層を一括契約という分業設計を前提とします。情シス部門が事務局を担い、各業務部署のリーダーが層別の判定を主体的に行う構造です。

反論への先回り——「ChatGPT Enterpriseで十分では」

「全社一括でChatGPT EnterpriseやCopilot for Microsoft 365を契約すれば、それで十分ではないか」という反論があります。汎用業務の効率化という第3層の射程では、その通りです。議事録整理、メール下書き、ドキュメント要約、社内検索の補助といった用途では、一括契約のSaaSが最もコストパフォーマンスに優れます。

ただし、図面検索の業務改善、設計変更通知の伝達漏れ対策、見積もり比較の自動化、品質トラブルの原因分類のような業務ドメインに深く食い込む課題は、汎用AIツールの「便利な機能」では届きません。これらは業務フローと社内データへの理解を前提に、エージェント側で工程設計や判断ロジックの一部を担う設計が必要で、第1層・第2層の領域に属します。

「ChatGPT Enterpriseで満たせる範囲」と「個社別エージェントが必要な範囲」を仕分ける目利きが、情シス部門の新しい主業務になります。仕分けが甘いと、汎用AIで実現できる業務に過剰投資する一方、本来エージェント化すべき業務が放置される、という二重の機会損失が起きます。

もう一つの反論として「外部パートナーに丸投げすれば情シスは関わらなくて済むのでは」がありますが、要件未定外注型の失敗パターン3でみたように、業務分解の責任を委託先に丸投げできない構造があります。外部パートナーと組む場合も、業務側のリーダーと情シスの事務局が「何を内製・何を委託する」の境界線を握る必要があります。

次のアクション

AI内製依頼の3層仕分けと、第2層の内製人材育成を同時に進める方法として、4日間集中型の実装ブートキャンプが選択肢になります。設計者・調達担当・品質保証担当などの業務リーダー1〜3名を派遣し、自社業務に即したエージェント実装の足場を作る構成です。情シス部門は事務局として参加し、層別の仕分けルールも同時に整備します。

実装ブートキャンプの内容と、自社の業務にどう当てはまるかを確認するには、こちらから詳細をご覧ください。

FAQ

Q1. AI内製依頼を3層に仕分ける判定軸はどう作ればよいですか

業務ドメインの深さ、社内データへの依存度、定着までの期間の3軸で評価する方法が運用しやすいです。ドメインが浅く社内データ依存も低い案件は第3層（一括契約）、ドメインが深く長期運用が必要な案件は第1層（個社別エージェント）、その中間で業務リーダーが手を動かせる案件は第2層（内製育成）となります。

Q2. 情シス部門の体制は今のままで対応できますか

情シス部門単独では難しいケースが多く、業務部署のリーダーを兼任で巻き込む座組が現実的です。事務局を情シスが、業務分解を各部署リーダーが、実装を内製人材または外部パートナーが担う三者構造を作るのが定石です。

Q3. ブートキャンプの効果はどのように測れますか

ブートキャンプ受講後3ヶ月時点で、受講者が自社業務に即したエージェントのPoCを1本以上完成させているかが第一の指標です。次に、PoCから本導入に至った件数、内製で対応した依頼の比率、外部委託に回した依頼の比率を半年単位で観察します。

Q4. 経営層から「全社一括契約で十分」と言われた場合の説明軸は

第3層（汎用業務）と第1〜2層（業務ドメイン特化）の射程の違いを、自社の業務カテゴリで列挙して示すのが説明しやすい方法です。例えば「議事録要約は一括契約で十分／図面検索の業務改善は個社別エージェントが必要」のように、業務ごとに層を仕分けたマトリクスを提示することで、機会損失の可視化が可能になります。

関連記事

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