AIリテラシー研修を全社員に展開した。受講後の理解度テストは7割が80点を超えた。それから半年経って、業務はほぼ何も変わっていない——。中堅製造業のDX推進担当からこの種の相談が、2026年に入って明らかに増えた。理由は単純で、研修は「個人のスキル」を変えるが、「組織が動かす業務」は変えないからだ。本稿では、80人規模（情シス4名／設計30名／調達・品質・生産技術30名／経営企画10名前後）の中堅製造業が、3ヶ月の研修プログラムを通じて「内製化の起点に立つ」ために必要な4つの設計原則を扱う。前提は、ツール操作の習熟ではなく、業務分解と運用の組み立てを、研修期間中の主成果物にすることだ。

「研修したのに業務は変わらなかった」が再生産される3つの構造

多くの中堅製造業で、AI研修プログラムが「受講したら終わり」で停止する。受講満足度は高い、テストの点数も悪くない、社内ニュースには「全80名がAI研修を修了」と載る。それでも半年後の業務工数や成果物の質はほぼ動いていない。これは個別の研修ベンダーの問題ではなく、研修を発注する側・受ける側・組織の三方に共通する構造の問題で、ほぼ確実に次の3つのいずれか（多くは複数）に該当する。

構造1：受講対象が決まる前に研修内容が決まっている

稟議が動く順番は、おおむね「情シス決裁者→外部研修ベンダー→現場部門」の順だ。情シスとベンダーの間でSOW（作業範囲記述書）と予算が固まったあとで、現場に「来月から研修が始まります」と通知される。この順番で進む限り、研修内容は「受講者が今困っている業務」ではなく「ベンダーがすでに持っている教材」で決まる。設計部の図面検索、調達の見積、品質のFMEA、いずれも研修中に名前すら出てこない。受講者は「自分の業務とは関係のないツールの話を90分聞く」体験を3ヶ月続けることになり、研修終了と同時に学習内容は記憶から消える。

構造2：研修の主成果物が「テスト点数」になっている

研修ベンダーは多くの場合、成果指標として「理解度テストの点数」「アンケートの満足度」を提示する。発注者側もそれを稟議の評価基準にしてしまう。すると研修設計は「テストで点が取れる教材」に最適化される。プロンプトの基礎構文、ハルシネーションの説明、社内データを使うときの注意点、といった一般論が中心になり、自社業務に固有の論点はテストに入れにくいため省かれる。結果、修了試験は通っても、自分の業務に持ち帰る成果物は何もない。

構造3：研修終了後の「受け皿プロジェクト」がない

受講後の翌週からどの業務でAIを試すか、誰がオーナーで、評価軸は何か、を研修開始前に決めていない組織が大半だ。受講者は意欲を持って戻るが、自分の業務時間の中で勝手に試すか、上司の判断で「とりあえず後回し」になる。3ヶ月後には、研修内容を試した受講者と試さなかった受講者の差は誤差レベルになる。これは研修ベンダー側からは観測できない領域で、受講後の現場側の運用設計がまるごと抜けていることが原因だ。

研修を「個人のスキル」ではなく「業務OSの設計図」に直結させる

上記3つの構造を踏まえると、80人組織が3ヶ月で「内製化の起点に立つ」ためには、研修プログラムの設計を「受講者がツールに慣れる」から「業務分解を成果物にする」へ転換する必要がある。研修のゴールはツールの理解ではなく、自社業務の構造を絵に起こし、そのうちの3つの工程をAIエージェントが動かす状態にすることだ。この観点を共有するために、過去の議論を1つ引いておく。

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

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

研修の主成果物は、この「業務そのもの」をどの粒度まで分解し、どこにエージェントを立てるかの設計図でなければならない。以下の4原則は、その設計図を3ヶ月で受講者と業務オーナーが共同で描き切るための骨格である。

原則1：「現場 × 情シス × 経営企画 × 外部講師」の4者編成チームから組む

研修の最小単位は「受講者個人」ではなく、4者で1チームにする。現場（業務を持っている人）、情シス（社内データとセキュリティを握っている人）、経営企画（稟議の評価軸を持っている人）、外部講師（業務分解と実装の方法論を持っている人）——この4者が同じ場で議論する状態を最初に作る。受講者個人が3ヶ月後に学習内容を業務に持ち帰ろうとしても、情シスの許可・経営企画の予算・業務オーナーの優先順位という3つの壁に止められる。研修期間中に4者がチームとして合意を作るなら、これらの壁は研修内で解ける。

80人組織なら、5チーム×16名（情シス各1名・経営企画各1〜2名・現場12〜14名・外部講師は2チーム掛け持ちで2名）の編成が現実的だ。チーム単位で扱う業務領域を分け（設計／調達／品質／生産技術／全社横断）、3ヶ月の終わりにチームごとに業務OSの設計図1枚＋稼働システム1つを持って終わる。

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

内製と外注の境界線——設計OS構築で「自社で握るべき層」「任せていい層」

原則2：研修の主成果物を「業務分解の図」にする

研修内の各セッションは、テスト点数や受講者アンケートではなく、業務分解図の更新版を成果物として提出する設計にする。第1段階は部門単位の業務マップ、第2段階は業務群、第3段階は業務ステップ、第4段階は動作単位（システムに代行させられる最小行動）。多くの組織は第2段階で止まる。「設計部の業務には、図面検索／部品表メンテ／設計変更／DR準備／顧客対応がある」までは10分で書けるが、その下のステップと動作単位まで降りるには現場の作業者にしか分からない情報が要る。研修内で4者チームが共同でここを書き切るのが核心だ。

動作単位まで降りた業務分解図は、そのまま実装の発注書になる。第4段階の動作（たとえば「過去3年の類似図面を発注番号と一緒に5件引いてくる」）まで降りていれば、研修中にPoCを動かすことが現実的になる。降りていなければ、研修後にベンダーに「AIで何か作って」と発注しても、要件が固まらず動かない。

原則3：3ヶ月の最後に「3つの稼働システム」を持って終わる

「3ヶ月後に修了証を配る」ではなく「3ヶ月後に3つの稼働システムを社内に残す」をゴールにする。具体的には、5チームのうち3チームが、業務分解図の中から1つの動作単位を選び、エージェントが社内データを参照しながらそれを実行する状態を作る。残りの2チームは設計図の完成度を上げるところで止めてよい——3ヶ月で全チームが稼働システムを作ろうとすると粒度が浅くなる。

稼働システムの実装は、研修期間中に外部講師が伴走する。受講者だけで書く必要はない。重要なのは「受講者が要件を書ける」「情シスがインフラに乗せる」「外部講師が実装の方法論を渡す」の役割分担を、研修内で訓練し終えることだ。3ヶ月終了時点で受講者がコードを書けるようになる必要はないが、「次の業務にエージェントを立てる際に、何を要件として渡せばよいか」が言語化できる状態には到達させる。

4日間で「設計者×AIエンジニア」を育てる構造は、受講者にコードを書かせることではなく、業務分解と実装方法論の役割分担を訓練することにある。

設計OS実装ブートキャンプ——4日間で「設計者×AIエンジニア」を育てる構造

原則4：経営企画が稟議の評価軸を研修開始前に決める

3ヶ月終了後に経営層に対して稟議が通る評価軸を、研修開始前に経営企画が確定しておく。よくある「受講者満足度」「修了率」「ROIの試算」ではなく、「3年後に社内に残る業務資産」「撤退時に失われるもの」「暫定運用のオーナー」の3項目で評価する。この3項目は、PoCを単発のイベントではなく、組織の業務基盤に積み上がる資産として扱うための最小評価軸である。研修中に作った業務分解図と稼働システム3本が、この3項目で評価できる形になっているかどうかが、3ヶ月後の判断点になる。

研修の終わりに経営企画が「稟議の評価軸が満たされた」と判断できれば、次の3ヶ月の予算（5チーム→8チーム展開、または既存3システムの本番化）が動く。満たされなければ、本研修が「個人スキル研修」に終わったことを早期に確定でき、撤退判断もしやすい。経営企画を「研修終了後に呼ぶ」のではなく「研修開始前に評価軸の設計者として呼ぶ」のがこの原則の運用上の核だ。

flowchart TD
    A[Month 0: 4者編成チーム x5本立ち上げ・経営企画が評価軸を確定] --> B[Month 1: 業務分解 第1〜3段階・各チーム業務マップ提出]
    B --> C[Month 2: 業務分解 第4段階＝動作単位・3チームを稼働システム化に選抜]
    C --> D[Month 3: 3チーム稼働システム実装・2チーム設計図完成度向上]
    D --> E{経営企画 評価: 3年後資産・撤退時損失・運用オーナー}
    E -- 評価軸を満たす --> F[次3ヶ月予算: 5→8チーム展開 or 本番化]
    E -- 満たさない --> G[個人スキル研修に終わったと判定・早期撤退]

    classDef start fill:#DBEAFE,stroke:#1D4ED8,stroke-width:2px,color:#1E3A8A;
    classDef phase fill:#EFF6FF,stroke:#1D4ED8,stroke-width:1px,color:#111827;
    classDef decision fill:#FEF3C7,stroke:#B45309,stroke-width:2px,color:#92400E;
    classDef pass fill:#D1FAE5,stroke:#065F46,stroke-width:2px,color:#064E3B;
    classDef fail fill:#FEE2E2,stroke:#B91C1C,stroke-width:2px,color:#7F1D1D;
    class A start;
    class B,C,D phase;
    class E decision;
    class F pass;
    class G fail;

失敗パターン3 vs 成功設計4——同じ予算と期間でなぜ差がつくか

自己診断ミニチェックリスト（5項目）

• 自社のAI研修プログラムでは、研修開始前に「受講後にどの業務で何を試すか」が部門別に決まっているか
• 研修の主成果物は「テスト点数」ではなく「業務分解図」または「稼働システム」になっているか
• 研修チームの構成に、現場・情シス・経営企画・外部講師の4者が含まれているか
• 業務分解の粒度は、第4段階（動作単位＝システムに代行させられる最小行動）まで降りているか
• 研修終了時の経営層への評価軸は「3年後に社内に残る業務資産」「撤退時に失われるもの」「暫定運用のオーナー」の3項目になっているか

5項目中3項目以上で「いいえ」が出る場合、現状の研修プログラムは「個人スキル研修」に止まっており、3ヶ月後に組織が動き出す保証はない。設計を見直す価値が十分にある。

「外部講師を呼ばず社内若手で十分」「ChatGPT Enterpriseで足りる」への先回り

本記事の論旨に対して、しばしば返ってくる2つの反論を扱う。

1つ目は「外部講師に頼まず、社内のAI得意な若手にやらせれば十分」。これは「業務分解の方法論」と「ツールへの習熟」を混同している反論で、後者は社内若手で代替可能だが、前者は中堅製造業の業務に分解の経験を持っている人材が社内に存在することがほぼない。動作単位まで降りた業務分解図を、現場の作業者と一緒に書ける人材は、AIエンジニアでもなければ業務コンサルでもない、「業務分解の方法論を持っている人」だ。社内若手にこれを任せると、研修期間が業務分解の手前——「ChatGPTの使い方研修」——で終わる確率が高い。

2つ目は「ChatGPT Enterpriseのライセンスを80人分配れば、研修は不要では」。これも個人スキル系の反論で、ツール提供と業務OS構築を混同している。Enterprise契約は社内データの安全な取扱を保証するが、「どの業務にエージェントを立てるか」の意思決定は契約に含まれない。配布後3ヶ月の利用ログを取ると、ヘビーユーザーが10%、たまに使うが20%、ほぼ未使用が70%という分布が典型で、組織として残る業務資産はゼロに近い。ライセンス配布と研修プログラムは補完関係であり、片方で他方を代替することはできない。

次のアクション

4日間で「設計者×AIエンジニア」を育てる構造を、自社の業務分解と組み合わせて設計するなら、ブートキャンプの設計図と実装方法論をまとめた資料を参照していただきたい。本記事で扱った4原則は、本質的にブートキャンプのスケール版で、最小単位は4日間の集中設計に圧縮できる。研修プログラムの開始前に、現場・情シス・経営企画の3者で「自社で内製化の起点をどこに置くか」を30分整理するだけでも、3ヶ月後の組織の景色は変わる。

FAQ

80人より小さい組織（30〜50人）でも同じ4原則は使えますか

使えます。4者編成チームの「4者」は人数ではなく役割であり、30〜50人規模では1人が複数役割を兼ねます。実際には2〜3チーム編成で十分機能し、稼働システム1〜2本でも経営判断には足ります。原則の本質は規模ではなく、研修の主成果物を「業務分解の図」と「稼働システム」に置く設計思想にあります。

外部講師の選び方の基準は何ですか

「業務分解の方法論」を持っているかが第一基準です。ChatGPTやPython、LangChainの知識は2番目以降の論点で、それらに長けていても業務分解ができない人を外部講師に置くと、研修は「ツール操作研修」に逆戻りします。面談時に「直近6ヶ月で第4段階（動作単位）まで降りた業務分解の事例を3つ見せてください」と聞くのが具体的な選別質問になります。

研修期間を1ヶ月に短縮できますか

条件付きで可能です。1ヶ月で稼働システム3本まで持っていくのは現実的ではないため、「業務分解図を第4段階まで降ろし、稼働システム1本のPoCを通す」までを成果ゴールにします。経営企画の評価判定は3ヶ月後ではなく1ヶ月後で行い、合格すれば追加2ヶ月で本格運用に進む二段階方式が安全です。

受講者の選定基準は何ですか

「自部門の業務に対して『どこを変えたいか』を3項目以上即答できる人」が第一の基準です。AIへの興味の有無は二の次で、業務の現状不満を構造的に持っている人ほど、業務分解の場で発言ができ、研修の進行を加速させます。各部門から「業務を3年やった現場担当」「情シスでデータの所在を知っている1名」「経営企画でROIの稟議を書ける1名」を最小編成として揃えるのが実務的です。

関連記事

• 設計OS実装ブートキャンプ——4日間で「設計者×AIエンジニア」を育てる構造
• 内製と外注の境界線——設計OS構築で「自社で握るべき層」「任せていい層」
• 業務OSとは何か——製造業ERPでもPLMでもない、第3の業務基盤の正体