AI技能継承が現場に定着しない3つの理由と、導入前に決める設計

2026-09-13 • 技能継承

AI技能継承システムを導入して半年、あなたの工場ではこんな状況になっていないだろうか。

現場を回ってみると、ベテランの段取りノウハウを収録したはずのタブレット端末が棚の隅に置かれている。使い方を確認すると「一応見られるんですけど、急いでる時に開く余裕はなくて」という答えが返ってくる。ダッシュボードのログを見ると、導入から3ヶ月目を境にアクセス数がほぼゼロになっている。

システムは動いている。データも入っている。でも現場は使っていない。

これは現場の担当者の「意識の問題」ではない。導入前の設計が足りなかったという問題だ。

「使える状態」と「使われている状態」は別物だ

「使える状態」と「使われている状態」は別物だ

AI技能継承が定着しない3つの根本原因

製造業のAI導入障壁を調査したレポートは、共通して「組織側の設計」を挙げている。Manufacturing Todayは、AIを別プロジェクトではなく日常のワークフローの一部にすること、そしてAI施策のオーナーを明確に割り当てることを改善策として挙げる(2025年7月)。Imubitも、多くのAIがPoC(概念実証)で止まる要因としてチェンジマネジメントの欠如を指摘している。

これを技能継承AIに当てはめると、定着しない原因は3つに絞られる。

原因①:使う場面が設計されていない。「困ったら参照する」という設計では使われない。「このステップで必ず開く」という強制動線がないと、急いでいる現場担当者は自分の経験で動く。

原因②:メンテナーが決まっていない。システムを最新状態に保ち、追加情報を入力し、質問を受け付ける担当者がいない。データが古くなると信頼性が下がり、さらに使われなくなる悪循環に入る。

原因③:評価に組み込まれていない。AI技能継承システムを使うことが、どの業務指標にも紐付いていない。使っても使わなくても評価が変わらない環境では、慣れた方法を選ぶのが人間の本能だ。

この3つのいずれかが欠けていれば、どれだけ優れたシステムでも「棚の隅」に追いやられる。

定着した事例から逆算する——ARUMCODEに見る参照型と生成型の違い

国内で技能継承AIが実際に定着している事例として、アルム株式会社のARUMCODEがある。3D CADデータからNCプログラムを自動生成するAIソフトで、月額制クラウドサービス「ARUM Factory365」経由で国内200社超の製造業が自社のマシニングセンタに組み込んでいる(出典:Microsoft Source Asia、2026年3月)。

アルムでソフトウェア開発を率いるゼネラルマネージャーは、20年以上前に精密部品の設計を始めた当時、先輩の仕事を見ながら図面・材料・工具を自分で判断できるようになるまで7年かかったと振り返る。そのうえで自らの役割を「職人の勘を、それを数値に落とし込むプログラマーに向けて翻訳すること」と語る(出典:Microsoft Source Asia)。NCプログラムの自動生成ツールに見えるが、開発側はこれを技能継承として設計している。

ここから読み取れるのは、参照型ではなく生成型だという違いだ。ARUMCODEは「見てもいい資料」ではなく「NCプログラムという成果物を出す道具」である。使えば工程が一つ終わる。技能継承AIが棚の隅に行くのは、多くが「読むだけ」で成果物を生まないからだ。自分の設計しているシステムが、使った結果として何を出力するか——これが定着を分ける。

さらにアルムは、ARUMCODEやTTMC Brainが「ユーザーが操作すべきボタンが多く、未経験者では使いこなせない」という課題を抱えていたことを踏まえ、LLM(大量の文章を学習した対話型AI)を実装したマシニングセンタ「TTMC Origin」の開発に進んでいる。2025年8月にプロトタイプが完成し、2026年7月に予約販売を予定している(出典:Microsoft Customer Stories)。「工程に組み込む」だけでなく「使う人を選ばない」ところまで設計を進めている例だ。

逆に言えば、「困ったときに参照してください」という位置づけのシステムは、ARUMCODEのようには定着しない。

使えば成果物が出る——工程の中に置かれたARUMCODEの立ち位置

使えば成果物が出る——工程の中に置かれたARUMCODEの立ち位置

設計①——「いつ使うか」を工程に埋め込む

技能継承AIを導入する前に答えるべき最初の問いはこれだ。「担当者は何をしているときにこのシステムを開くか」。

「困ったとき」「わからないとき」は正解ではない。急いでいる現場では、その「困ったとき」に過去の先輩の経験が頭に浮かべば、システムを開く前に判断を終える。

正解は「〇〇の工程チェックリストの第3ステップで、必ずこの画面を開く」のような強制動線だ。

具体的には以下の問いを導入前に設計チームで答える。

  • トリガー:どの業務ステップでシステムを開くか(例:段取り変え前・初回ロット確認時・トラブル初動対応時)
  • 所要時間:1回あたり何分以内で使えるか(筆者の実感では、3分を超えると現場は開かなくなる)
  • 出力形式:システムが出した回答を誰がどう使うか(口頭確認か、記録に転記か)

この3点が決まらないまま導入しても定着しない。

設計②③——メンテナーと評価の仕組みをセットで作る

「使う場面」を設計しても、もう2つが欠けると半年で形骸化する。

設計②:メンテナーの指名と役割定義

技能継承AIの中身(ノウハウデータ)は生き物だ。製品が変わり、機械が変わり、人が変わる。それに合わせてデータを更新し続ける担当者がいなければ、2年後には古いデータのシステムになる。

メンテナーは「AIに詳しい人」である必要はない。その業務に詳しく、現場に信頼されている人であることの方がはるかに重要だ。「ノウハウが正しいかどうかを判断できる人」と「システムに入力できる人」が別でも構わない。大切なのはどちらの役割も空席にしないことだ。

メンテナーに割り当てる最低限の責任は2つだけでいい。「四半期に1回、データの鮮度チェックを行うこと」「現場から『この情報が古い』という指摘を受け付ける窓口になること」。

設計③:評価指標への組み込み

定着を確認する指標は、月次のアクセス数だけでは不十分だ。「システムを使った上で判断した件数」「システム参照後のトラブル発生率」といった業務成果と紐付いた指標を設ける。

さらにチームリーダーの目標管理にひとつだけ「AI技能継承システムの月次活用件数 ○件以上」を加えると、リーダーが自然と活用を促すようになる。

国内調査では、製造業がAIを導入しない理由の1位が「AIの効果がよく分からないから」28.4%だった(出典:ソフトクリエイト「製造業界の課題に関する調査」2025年3月)。効果が見えないものは、導入前も導入後も後回しにされる。だからこそ、定着させたいなら「使った結果どうなったか」が見える指標を先に決めておく。

まとめ:最初の一手は「3つの設計問いに答えること」

技能継承AIが「導入したけど使われない」状態を防ぐために必要なのは、啓発活動でも追加トレーニングでもない。導入前に3つの設計問いに答えることだ。

  1. 「このシステムは、どの業務ステップで必ず開くか」(使う場面の設計)
  2. 「データを更新し続ける責任者は誰か」(メンテナーの設計)
  3. 「活用状況はどの指標で評価するか」(評価の設計)

明日の朝礼で、DX推進担当として一つだけ確認してほしい。「うちのメンテナーは誰か」。この問いに即答できるプロジェクトは定着する。答えがないプロジェクトは、半年後に棚の隅のシステムになる。

技能継承AIは道具だ。道具は使われて初めて価値を生む。使われる設計こそが、導入の本当の仕事だ。

CONTACT

「これ、AIでできない?」

業務の流れに落とし込みます。

相談内容をもとに、
AIで支援できそうな工程と、
人が確認すべきポイントを整理します。

まずは、分かる範囲で構いません。

まずは、できそうな業務を教えてください

送信後、業務フロー・AI支援箇所・確認ポイントを整理してお返しします

※ 箇条書き・未整理のメモでも構いません

送信後にお返しする内容

業務フロー整理 AI支援できる工程 人が確認すべき点 初期導入の進め方
送信しました。 お問い合わせありがとうございます。

参考・出典