ベテランの「形式知」は、すでに社内にある ― AIで技術承継を動かす4ステップ

1. はじめに：「マニュアルは、あるんですけどね」

「ベテランが来年で定年なんです。技術を残したいんですが、何から手をつければ…」

製造業のお客様から、いちばん多くいただく相談です。

そして現場を見せていただくと、ほぼ必ず同じ光景に出会います。棚に並んだ分厚いバインダー。作業標準書、点検記録、トラブル報告書、過去の是正処置報告。知識はもう、そこにあるのです。

ただ、誰も開いていない。若手に聞くと、決まってこう返ってきます。「あれ、どこに何が書いてあるか分からないので…結局ベテランの方に聞いちゃうんです」

技術承継の相談を受けるとき、多くの企業は「ベテランの頭の中にある暗黙知を、どう言葉にするか」から始めようとします。でも、正直に言うと、その前にやるべきことがあります。

2. 技術承継が止まる本当の理由

暗黙知の前に、形式知が死んでいる

知識には2種類あります。マニュアルや数値のように言葉で表せる形式知と、ベテランの勘や判断のように言葉にしにくい暗黙知です。この関係と、それを循環させるSECIモデルについては、SECIモデル×生成AIの記事で詳しく解説しました。

技術承継が進まない企業の多くは、実は暗黙知の手前でつまずいています。

苦労して形式知にしたはずの知識が、誰にも使われていない。

作業標準書はある。トラブル報告書も10年分ある。日報も毎日書かれている。それでも若手はベテランに聞きに行く。これでは、何十時間かけて新しいマニュアルを作っても、同じ棚にもう1冊増えるだけです。

形式知が「死ぬ」3つの理由

なぜ、せっかくの形式知が使われないのか。理由は3つあります。

理由①：探せない。 情報はあるのに、必要なときに見つけられません。「あの不具合、前にも似たのがあったはずだけど…」と思っても、10年分の報告書を1枚ずつめくる時間はない。結局「詳しい人に聞いた方が早い」となります。

理由②：文脈がない。 標準書には「トルク値を規定内に収める」と書いてあっても、「なぜその値なのか」「外れたときに何が起きるのか」は書かれていません。判断の背景が抜け落ちた手順書は、その通りにやることしかできず、応用が効きません。

理由③：古い。 設備が更新され、材料が変わり、より良いやり方が見つかっても、ドキュメントを更新する人がいない。静的なドキュメントは、作った瞬間から陳腐化が始まります。

この3つに共通するのは、いずれも「人の意志と努力」に依存していることです。だから続かない。そして、ここがまさに生成AIが得意とする領域なのです。

3. ステップ1：情報を「書かせる」のではなく「集まる」ようにする

最初のステップは、社内に散らばった形式知を1か所に集めることです。

ここで多くの企業が「では、みんなでナレッジをWikiにまとめましょう」と号令をかけます。そして、ほぼ確実に失敗します。書く側の負荷が高いからです。現場から戻って、作業記録を書いて、さらに「他の人にも役立つように」整理する。しんどいに決まっています。

発想を変えましょう。そもそも情報共有は、人の手でやるものなのでしょうか。

現場では、すでに大量の情報が日々生まれています。チャットでの「あの設備、朝から異音がするので様子見てます」というやり取り。日報の一言。トラブル対応後の口頭報告。生産管理システムに残る操作ログ。わざわざ報告書を書かなくても、情報はすでに生まれているのです。問題は、それが流れて消えていくことだけです。

だからまず、チャット・日報・既存の帳票・紙のバインダーをスキャンしたデータを、そのまま集める。きれいに整える前に、集めることを優先します。 整えるのは、次のステップでAIの仕事になります。

4. ステップ2：AIに「意味のラベル」を付けさせる

集めた生の情報は、そのままでは使えません。ここで生成AIの出番です。

生成AIは文脈を理解できるので、一つひとつの情報に自動でラベルを付けられます。「これは異音に関するトラブル対応のノウハウ」「これは特定の加工機の段取り替え手順」「これは品質不良の原因分析」といった具合です。

さらに、単なる分類にとどまりません。トラブル報告書をAIに読ませ、「発生事象・推定原因・実施した処置・再発防止策」という枠組みで構造化させる。バラバラの書式で10年分たまった報告書が、検索・比較できる形に変わります。

人が一つひとつ読んで分類する必要はありません。形式知を整理する仕事そのものを、AIに担わせる。 これがナレッジエンジニアリングの入口です。

5. ステップ3：現場から「聞ける」状態にする

構造化できたら、次は現場から引き出せるようにします。使うのはRAGという技術です。難しく聞こえますが、要するにAIに自社専用の参考書を持たせる仕組みだと思ってください。

若手が現場のタブレットから「このラインで異音がしたときの確認手順は？」と聞くと、AIが過去のトラブル報告と標準書を参照して答える。しかも「3年前に同じ症状があり、原因はベアリングの摩耗でした」という過去の実例つきで返ってきます。

現場のタブレットから、過去の報告書と標準書を参照したAIに手順を聞ける

ここで初めて、棚のバインダーが「生きた知識」になります。従業員300名ほどの精密部品メーカーであれば、まずは相談の多い設備1台、あるいは不具合の多い工程ひとつに絞って始めるのが現実的です。全社展開は、その後で構いません。

6. ステップ4：使われ方から、暗黙知の在り処を見つける

そして、ここからが本当に面白いところです。

AIへの質問ログが溜まっていくと、現場が何につまずいているかが、データとして見えてきます。

同じ工程について繰り返し質問が来ている。ある設備について、AIがうまく答えられていない。特定の手順書のページで、若手が何度も検索し直している。これらはすべて、「形式知が足りていない場所」を指し示すシグナルです。

どこで質問が集中しているかを見れば、形式知が欠けている工程が分かる

ここで初めて、ベテランに時間を取ってもらいます。「この工程について、若手から月に20回も質問が来ています。標準書にはこう書いてありますが、実際はどう判断されていますか？」

漠然と「ノウハウを言語化してください」とお願いするのと、この聞き方とでは、ベテランの負担も、出てくる情報の質もまったく違います。すでにある形式知を動かすことで、次に言語化すべき暗黙知が特定できる。 順序が逆なのです。

ベテランから引き出した答えは、そのままナレッジベースに追加されます。質問が減れば効果があった証拠。減らなければ、まだ何かが足りない。こうして知識が、静的なドキュメントではなく、更新され続ける生き物になっていきます。

7. 経営層が見るべきもの

この仕組みが回り始めると、経営層にも副産物が届きます。

すべての質問ログに目を通す必要はありません。AIに「経営判断が必要なシグナル」だけを抽出させればよいのです。同じ設備に関するトラブル質問が急増していれば、それは更新投資の検討シグナルかもしれません。特定の工程だけ質問が集中していれば、そこが人材配置のボトルネックです。

現場に降りなくても、何が起きているかの大枠が分かる。もちろん細かいニュアンスは現場との対話でしか掴めませんが、「何が起きているか分からない」という状態はなくなります。

8. まとめ

技術承継というと、どうしてもベテランの頭の中を覗き込む話から始めたくなります。でも、実際に効くのは逆の順序です。

• 技術承継が止まる原因は、暗黙知の前にある。すでに形式知になっている知識が、探せない・文脈がない・古い、という理由で死んでいる
• ステップ1：集める。人に書かせるのではなく、チャット・日報・既存帳票から自然に集まる仕組みを作る
• ステップ2：構造化する。生成AIに自動でラベル付けと構造化をさせ、整理そのものをAIの仕事にする
• ステップ3：引き出せるようにする。RAGで、現場から過去の実例つきで聞ける状態にする
• ステップ4：育てる。質問ログが「形式知の穴」を教えてくれる。そこで初めてベテランに時間を使ってもらう

ベテランの残り時間は有限です。だからこそ、その貴重な時間を「すでに書いてあることの説明」に使わせてはいけません。書いてあることはAIに任せ、ベテランにしか語れないことだけを聞く。 これが、限られた時間で技術承継を成立させる、いちばん現実的な道筋だと考えています。

まずは棚のバインダーを1冊、スキャンしてみるところから始めてみませんか。