Alphakt InsightsAI×BPR / 現場知見の継承をAIでどう設計するか|暗黙知を4種類に分けて手段を選ぶ
AI×BPR

現場知見の継承をAIでどう設計するか|暗黙知を4種類に分けて手段を選ぶ

公開日:2026年8月13日 / 最終更新:2026年8月13日

「技能継承」が進まないのは、継承する対象を定義していないから

熟練技能者の退職時期が見えている工場では、技能継承は先送りできない課題になっています。人手不足が構造化するなかで、若手が同じ年数をかけて同じ経験を積む前提はもう成り立ちません。この認識自体は、ほとんどの現場で共有されています。

それでも継承が進まないのは、多くの場合「何を継承するのか」が定義されていないためです。会議で挙がる手段は毎回似ています。作業を動画で撮る、マニュアルを整備する、ベテランに勉強会を開いてもらう、社内文書を生成AIに読ませて質問できるようにする。どれも間違いではありませんが、これらは向いている対象がまったく違う手段です。対象を定義せずに手段を並べると、「とりあえず動画を撮る」で止まり、撮った動画は誰も見ないまま残ります。

本記事では、現場知見を4種類に分解し、種類ごとに継承手段を選び分ける枠組みを整理します。あわせて、暗黙知を引き出す具体的な方法と、作った知見が更新され続ける状態をどう作るかを扱います。

この記事が扱う範囲と、扱わない範囲

扱う扱わない(別記事)
深さ知見の分解と、手段の選び分けの判定問い合わせ応答の実装の勘所 → RAG実装のベストプラクティス
事例の重複判断知を制約と選好に割り直す考え方(一般形)輸配送での具体的な分解手順 → 配車最適化AIとベテランの暗黙知
前段知見継承領域に絞った設計論製造業でどの領域から着手するかの判断 → 製造業のAI×BPRはどこから始めるか
定着知見が更新され続ける運用設計定着一般の打ち手と抵抗への対処 → BPRは「設計」より「定着」で決まる

現場知見を4種類に分解する ― 手順知・判断知・例外知・関係知

「熟練者のノウハウ」と一括りにされているものは、性質の異なる4種類に分けられます。分けると、どの手段が向くかがほぼ自動的に決まります。

手順知:決まった順序で決まった動作を行う知識。段取りの手順、点検のルート、装置の立ち上げ手順。判断知:状況を読んで選ぶ知識。この音は異常か、この材料なら送り速度をどう変えるか、この摩耗の痕跡から何を疑うか。例外知:普段起きないことへの対応。特定の不良が出たときの切り分け、装置が想定外の挙動をしたときの復旧。関係知:誰が何を知っているか、どこに何があるか。この件は誰に聞けば早いか、この図面はどのフォルダにあるか。

4種類の性質と、失われ方の違い

種類文書化の難しさ失われ方
手順知段取り替えの手順、点検ルート低い。書けば書ける書かれないまま人が抜ける
判断知音・振動・見た目からの異常判定、条件の微調整高い。本人が理由を説明できない若手が同じ状況を経験しないまま抜ける
例外知特定不良の切り分け、想定外挙動の復旧中〜高。事象が散在している記録が個人のメモに残り共有されない
関係知誰に聞けば早いか、どこに資料があるか低いが陳腐化が速い組織変更で一気に無効化する

失われ方が違うため、打ち手の緊急度も違います。手順知は「書く工数を確保すれば解ける」問題で、難しさは技術ではなく優先順位の付け方にあります。一方判断知は、書く工数を確保しても解けません。本人が「なんとなく分かる」としか言えないため、引き出す方法そのものを設計する必要があります。

実際のプロジェクトでも、この構造は同じ形で現れます。ある製造業の大手で金型修正指示の業務を調べたところ、修正指示の履歴が部署内に分散していて過去の経緯を追えず、そのためにノウハウが組織に蓄積されない状態になっていました。ここで失われていたのは個人の記憶ではなく、記録の置き場です。この違いは打ち手を変えます。属人化の原因を「ベテランが教えてくれない」に置くと教育の問題として扱うことになりますが、置き場が無いのであれば、書く意思があっても組織には溜まりません。棚卸しの初期に「この知見はどこに置かれるのか」を決めていないと、引き出した内容が個人のファイルに戻っていきます。この現場で実際に何が起きていたかと、工程のどこから直すかは手戻りが発注件数を超える現場で、どこから直すかで扱っています。

分解しないまま動画を撮ると、資産にならない

技能継承の入口として動画撮影が選ばれることは多いのですが、分解せずに撮ると手順知の記録に偏ります。手を動かしている様子は映りますが、そのとき何を見て何を判断したかは映りません。結果として、「ベテランの作業が見られる動画」はできても、若手が判断できるようにはなりません。

動画が判断知の継承に効くのは、作業者に語らせながら撮る場合だけです。この違いは撮影方法の工夫ではなく、対象を判断知だと定義したかどうかの違いです。

手段の使い分け ― 手順書/動画/チェックリスト/検索応答/モデル化

知見の種類が決まれば、手段は絞られます。

知見の種類 × 手段の対応

知見の種類第一に取る手段AIの役割向かない手段
手順知手順書・チェックリスト・作業動画音声からの下書き生成、動画の工程分割検索応答(そもそも探す前に手順が必要)
判断知実況による言語化 → 判断基準の明文化 → 数値化できるものはモデル化言語化の補助、基準の一貫性チェック、センサー値からの判定文書を集めるだけの検索応答
例外知事例の構造化(事象・原因・対処・再発防止)過去事例の検索応答、類似事例の提示手順書(事象が多様で網羅できない)
関係知所在情報の整備(文書・担当・権限)横断検索、リンク切れの検知動画

この表の要点は、検索応答(社内文書に質問できる仕組み)が効くのは主に例外知と関係知だという点です。過去のトラブル事例や文書の所在は、量が多く構造化しづらく、必要になる時期が予測できません。まさに検索に向いた性質です。実装の勘所はRAG実装のベストプラクティスにまとまっています。

一方、判断知は検索で解けません。文書化されていないものは検索できないためです。判断知にまず必要なのは、検索基盤ではなく言語化の工程です。ここを混同して「文書を全部AIに読ませれば継承できる」と設計すると、質問しても「該当する記載がありません」と返る仕組みができあがります。

なお、判断知のうち数値で表せるものは、モデル化に進める余地があります。設備の異常判定であればセンサーデータからの異常検知と対象設備の選定、外観の良否判定であれば外観検査AIの評価指標と運用設計が、それぞれ判断知をモデルに移す具体的な設計になります。逆に言えば、判断知の一部は「継承」ではなく「置き換え」で解くのが早いという判断もあり得ます。

生成AIが効くのは「引き出す」と「取り出す」であって「決める」ではない

生成AIの役割を整理すると、3つに分かれます。引き出す:ヒアリングの音声を文字にし、構造化された下書きにする。抜けている観点を指摘する。取り出す:蓄積された事例や文書から、必要なときに必要な部分を返す。決める:判断そのものを代替する。

このうち「決める」は、判断知をモデル化した場合に限られ、対象も範囲も限定されます。継承のプロジェクトで生成AIを使う価値が最も大きいのは「引き出す」です。従来、暗黙知の言語化が進まなかった最大の理由は、ヒアリングして文章にまとめる工数が誰も取れなかったことにあります。ここが軽くなったこと自体が、技能継承の前提を変えています。

暗黙知を引き出す3つの方法

判断知と例外知を引き出す実務的な方法は、3つに整理できます。

① 作業しながら語らせる(実況による言語化)

作業中に「いま何を見ているか」「なぜその選択をしたか」を口に出してもらい、記録します。後からのインタビューでは「経験です」で終わる内容が、作業中は具体的な対象として出てきます。ポイントは、手が動いている最中に聞くことと、聞き手が同じ作業をできない人であることです。分かる人が聞くと、双方が当たり前だと思っている前提が省略されます。

② トラブル事例から逆に引く

例外知は、事象から逆引きするのが最短です。過去のトラブル記録を並べ、それぞれについて「どこで気づいたか」「最初に何を疑ったか」「なぜそれを疑ったか」を確認します。「なぜそれを疑ったか」の部分が判断知で、事象と切り離して聞くと出てきません。集めた事例は「事象・観察・仮説・対処・再発防止」の型に揃えておくと、後から検索できる資産になります。

③ 判断を「制約」と「選好」に割り直す

判断知が最終的に何かの選択に帰着する場合、条件を2つに割り直せます。違反が許されない条件(制約)と、守れると望ましい条件(選好)です。この分解は輸配送の計画づくりで確立している方法で、ベテランの判断を制約と選好に分けていく具体的な手順がそのまま参照できます。対象が設備でも品質でも構造は同じで、「これは絶対か、それとも望ましいだけか」という問いを1件ずつ当てていく作業になります。

割り直しの副産物として、現場のルールに矛盾があることが見つかります。矛盾は解消しなければならない論点で、これは継承ではなく業務ルールの再設計です。実際、知見の棚卸しは業務の棚卸しと重なるため、業務プロセスの棚卸しの進め方と同じ枠組みで進めると重複作業を避けられます。

知見を「更新され続ける状態」にする運用設計

技能継承の取り組みが失敗する二番目の理由は、作った資産が更新されないことです。設備も製品も工程も変わるため、更新されない手順書は数年で「見ると間違える資料」になります。

誰が書き、誰が直すのかを決める

書く人と直す人を役割として定義します。ベテラン本人に書かせる設計は、たいてい機能しません。書く作業が本業に上乗せされ、優先順位が下がるためです。現実的なのは、聞き取って書く担当を置き、ベテランはレビューに専念する分担です。この担当を誰の工数で置くかは、継承プロジェクトの成否を決める資源配分の判断になります。

陳腐化を検知する仕組みを埋め込む

更新のトリガーを、人の善意ではなく業務イベントに紐づけます。設備の改造、工程の変更、不良の再発、作業者の交代。これらが起きたときに関連する知見を見直す、という接続をルールにします。加えて、最終更新日と参照回数を可視化しておくと、「誰も見ていない資産」と「古いまま参照されている資産」を切り分けられます。後者が最も危険です。

現場が既に見ている場所に置く

新しい専用システムを立てて「ここを見てください」と案内する設計は、ほぼ定着しません。現場が既に開いている画面や既に使っている端末の導線に置きます。この観点は定着一般の論点でもあるため、現場に根づかせる5つの打ち手、および工場をまたいで広げる段階では抵抗が生まれる構造と推進体制の設計を併せて確認してください。

なお、社内文書を生成AIに読ませる構成を採る場合は、扱える情報の範囲と持ち出しのルールを先に決めておく必要があります。生成AI利用ガイドラインの作り方が該当します。

継承の進捗をどう測るか

技能継承は成果が見えづらく、予算が続かない典型的な領域です。測る指標を先に決めておきます。

指標測り方注意点
対象知見のカバー率棚卸しした知見のうち、文書化・記録が済んだ割合分母(棚卸し)を先に作らないと測れない
単独で実施できる作業の数若手が指導なしで完了できる作業項目の数資格・認定の仕組みがあればそれを流用する
問い合わせの内容変化ベテランへの質問のうち、資料で解決できたものの割合質問件数の減少を目標にしない。質問の質が上がるのが正常
資産の鮮度最終更新日が一定期間を超えた知見の割合参照回数と組み合わせて見る
立ち上がり期間新規配属から一人立ちまでの期間効果が出るまで時間がかかる。前後比較の設計が必要

問い合わせ件数の削減を目標に置かないことが実務上のポイントです。継承が進むと、若手が資料で解ける範囲が広がる一方で、より踏み込んだ質問をするようになります。件数だけを見ると成果が出ていないように見えます。

まとめ:技能継承は「記録」ではなく業務プロセスの再設計

技能継承は、ベテランの知識を記録に残す作業ではありません。判断の根拠を組織が読める形にし、若手が判断できる業務プロセスへ組み替える取り組みです。着手の第一歩は、いま失いかけている知見を4種類に分けて棚卸しし、そのうち判断知にだけ「引き出す方法」を設計することから始まります。

工程全体を通しで確認したい場合は製造業のAI×BPRはどこから始めるかから、該当領域を選び直してください。

次に読む記事

知りたいこと記事
製造業ではどの領域から着手するか製造業のAI×BPRはどこから始めるか
問い合わせ応答をどう実装するかRAG実装のベストプラクティス
判断知をモデルに移す設計予知保全AI導入の進め方
現場に根づかせる打ち手BPRは「設計」より「定着」で決まる
JOIN ALPHAKT

Alphaktで働くことに興味はありますか?

応募の前に、まず話すところから。「提言して終わり」ではなく実装まで走り切る現場で、いま何が起きているかをお伝えします。カジュアル面談から受け付けています。

話を聞いてみる →