本稿の立場
本稿は、暗黙知の学術的な定義に最終的な決着をつけることを目的としたものではありません。評価・監査・審査・チェックシート対応を支援するAIソリューション「AskDona Batch Assessment」を提供する事業者として、実際の評価業務をAIと人で分担する中から得られた実務上の見解を整理したものです。
私たちが重視するのは、「何を暗黙知と呼ぶか」という言葉の争いではなく、組織内にある知識の属性を見分け、それぞれに適した記録・標準化・継承・レビューの方法を選ぶことです。
「ベテランの暗黙知を形式知化したい」
製造業の技能継承、営業ノウハウ、問い合わせ対応、監査、審査、評価業務など、さまざまな場面で聞く言葉です。
担当者しか知らない。マニュアルに書かれていない。退職すると失われる。だから、暗黙知を収集し、文書化し、AIに活用させたい。
この問題意識自体は自然です。しかし、企業の現場で「暗黙知」と呼ばれているものを細かく見ていくと、性質の異なる情報が一つの言葉にまとめられていることに気づきます。
本当に言葉にしにくい熟練技能もあれば、単に記録されていない事実もあります。組織として決めていないルールもあれば、必要な資料の所在を一部の担当者しか知らないだけの場合もあります。
これらをすべて暗黙知と呼んでしまうと、課題の原因も、取るべき対策も見えなくなります。
AI時代に必要なのは、あらゆる暗黙知を一括して「形式知化」することではありません。
まず、「書かれていない知識」が何であるかを、もう一段細かく見分けることです。
暗黙知は、単に「文書化されていない知識」とは限らない
「暗黙知」は、企業実務では「担当者の頭の中にあり、まだ文書化されていない知識」という意味で使われることがあります。しかし、関連する研究をたどると、暗黙知はそれよりも広く、単純には言語化できない知識まで含む概念として論じられてきたことが分かります。
マイケル・ポランニーの『The Tacit Dimension』では、人は自らが言葉で説明できる以上のことを知っている、という考え方が示されています。たとえば、人の顔を見分けることや自転車を操作することはできても、その認識や身体調整のすべてを、第三者がそのまま再現できる規則として説明することは容易ではありません。この議論からは、暗黙知が単なる文書不足ではなく、人が知覚し、判断し、行動する過程に含まれる、完全には明示しにくい知識を扱う概念だと理解できます。[1]
その後、野中郁次郎氏の研究や、野中・竹内による知識創造論では、個人が持つ経験的な知識と、言語や文書によって共有可能な知識との相互作用が、組織の知識創造を説明する枠組みとして整理されました。[2][3] これらの研究を踏まえると、企業における知識の共有は、単に既存の情報を文書へ転記するだけではなく、経験や対話を通じて意味を共有し、組織で利用できる形へ変えていく過程を含むと考えられます。
一方、暗黙知を「まだ言語化されていないだけの知識」と捉え、適切な手順を踏めばすべて明示化できると考えることには、異なる見解もあります。Haridimos Tsoukasは、暗黙知を独立した情報の塊として取り出し、そのまま明示知へ変換できるものとして扱うことは、ポランニーの議論を単純化する可能性があると論じています。[4] この指摘からは、暗黙知の中には、文章として切り出すことよりも、実践の中で他の知識を理解し、使うことを支える性質のものがあると読み取れます。
Harry Collinsは、暗黙知を一種類のものとして扱わず、関係的暗黙知、身体的暗黙知、集合的暗黙知という類型に分けています。[5] この整理では、情報の伝達方法や関係者間の事情によって明示されていない知識と、身体的な技能に根差す知識、特定の社会や組織への参加を通じて身につく知識が区別されています。したがって、「担当者しか知らない」という同じ状態に見えても、文書やデータとして整理できるものと、実践や組織的な文脈を通じなければ十分に共有しにくいものが含まれていると考えられます。
これらの議論を踏まえると、暗黙知を単に「文書化されていない知識」と同義に扱うことは適切ではありません。企業で暗黙知と呼ばれているものには、未記録の事実、未明文化のルール、資料や担当者の所在に関する知識、経験に基づく判断、身体的な技能など、性質の異なるものが混在している可能性があります。
本稿では、暗黙知について一つの学術的定義を提示するのではなく、これらの研究で示された違いを手掛かりに、企業実務で「暗黙知」と呼ばれている問題を、より具体的に分類して考えます。
製造業には、本当に身体的な暗黙知がある。しかし、そこでも混在している
製造現場には、言葉や文書だけでは十分に伝えにくい知識が実際に存在します。
熟練者が設備の音や振動のわずかな違いから異常を察知する。材料の状態を手触りで見極める。加工中の抵抗を感じ取り、力や速度を微調整する。
こうした技能は、手順書に情報が不足しているというだけでは、十分に説明できない場合があります。熟練者による音や振動の捉え方、力加減の調整、作業状況に応じた判断などには、身体感覚、反復経験、実際の環境との相互作用を通じて身につく要素が含まれるためです。
LeonardとSensiperは、組織で利用される知識を、完全に明示された知識と完全に暗黙的な知識に単純に二分するのではなく、その間に連続性があるものとして論じています。また、問題解決やイノベーションにおいて、経験に根差し、必ずしも言葉だけでは十分に表現されていない知識が利用されることを示しています。[6] この議論を踏まえると、製造現場の熟練技能には、手順として記述できる部分だけでなく、実践を通じて獲得される部分も含まれると考えられます。
ただし、製造現場で「職人しか知らない」とされている情報のすべてが、このような身体的・経験的な暗黙知に当たるとは限りません。担当者しか知らないという状態だけを見れば同じでも、その中には、設備ごとの設定値、過去の不具合履歴、作業条件、変更理由など、本来は記録や標準書に残せる情報も含まれている可能性があります。
- 設備ごとの調整値が記録されていない
- 実際の許容値が標準書へ反映されていない
- 不具合と原因の対応関係が整理されていない
- 過去の変更理由が残されていない
- 現行の作業標準が古い
これらは、本質的に言語化できない技能ではなく、データ管理、標準管理、変更管理、知識整理の問題である可能性があります。
Paul Adlerは、製造容易性に関する知識を例に、暗黙知と明示化された知識の関係を、固定的な二分法ではなく、時間とともに変化するものとして捉えています。彼の整理では、熟練者が経験的に持っていた判断の一部は、生産可能性に関するガイドラインや設計ルールとして明示化され、比較的単純な問題の回避や、業務の標準化に利用できるようになります。[7]
一方で、Adlerは、こうした明示化を進めても、製造に関する知識のすべてをルールへ取り込めるわけではないと述べています。さらに、作成されたガイドラインをどの場面で信頼し、どの場面で上書きするべきかを判断するには、製造現場への理解や経験に基づく文脈的な知識が必要になるとしています。[7]
この例から読み取れるのは、暗黙知を明示化すれば、元の暗黙知がそのまま消えるわけではないということです。知識の一部はルールや標準へ移せても、それを適切に運用し、例外を見極め、環境の変化に応じて更新する過程には、別の経験的な判断が残る場合があります。
したがって、実践の中でしか十分に獲得しにくい知識が存在することと、未記録の事実や未整備のルールを一括して暗黙知と呼ぶことは、分けて考える必要があります。
後者は、必ずしも本質的に言語化できない知識ではありません。設定値が記録されていない、判断基準が定められていない、資料間の関係が整理されていないといった状態であれば、暗黙知の継承というより、情報管理や業務設計の課題として扱う方が適切です。
「本当の暗黙知がある」ことと、「未整理な情報をすべて暗黙知と呼ぶ」ことは、別の話です。
Batch Assessmentを提供する中で見えてきたこと
Batch Assessmentは、評価項目ごとに組織内の文書や証跡を確認し、AIエージェントが一次評価、判断理由、引用箇所、参照元、不足情報を整理するソリューションです。人はその結果を根拠と照らし合わせ、必要な補足・修正・最終判断を行います。
このような仕組みを設計すると、「担当者なら分かる」で済んでいた部分を、AIが実行可能な形へ分解する必要が生じます。
- 何を評価対象に含めるのか
- どの資料を検索すべきか
- 何を十分な証拠として認めるのか
- 規程と実施記録をどう区別するのか
- 複数の条件をどう集約するのか
- 情報不足を未対応と判断不可のどちらで扱うのか
- どこまでをAIが一次評価し、どこからを人が判断するのか
この分解を進めると、従来「暗黙知」と呼ばれていた問題の多くが、実は別の属性を持っていることが分かります。
「暗黙知」と呼ばれているものを、六つに分ける
企業の中にある「書かれていない知識」は、実務上、少なくとも次の六つに分けられます。
| 種類 | 具体例 | 本来の対策 |
|---|---|---|
| 未記録の事実 | 使用中の設定、対象機器、例外運用、実施日、承認状況 | 台帳・設定情報・実施記録として残す |
| 未明文化のルール | 用語の範囲、対象外条件、証拠要件、判定の優先順位 | 規程・評価仕様・判定基準として定義する |
| 未整理の関係知 | 正式名称と通称の対応、資料と対象の関係、責任部署、現行版と旧版 | メタデータ・対応表・責任分界として整理する |
| 未標準化の手順知 | どの順序で確認するか、どこを検索するか、誰に照会するか | 手順・検索設計・ワークフローとして標準化する |
| 経験的な判断知 | 証拠の弱さを見抜く、例外や代替統制の妥当性を判断する | 判断事例を蓄積し、人のレビュー対象として残す |
| 身体化・集合的な暗黙知 | 音、振動、手触り、力加減、タイミング、現場共同体の作法 | OJT、実演、映像、センサー、訓練、共同実践で継承する |
この分類は、暗黙知に関する学術的な標準分類を提案するものではありません。Batch Assessmentを提供する立場から、組織が実際に取るべき対策を区別するための運用上の分類です。
重要なのは、最初の四つは、少なくとも原理的にはかなりの部分を記録・定義・構造化できるという点です。
担当者の頭の中にしかないからといって、本質的に言語化できないとは限りません。
評価業務で見えてきた問題の多くは、本当は暗黙知ではない
セキュリティ対策の実施状況を確認する評価を例にすると、違いがよく分かります。
「このシステムでは自己署名証明書を使っている」
これは担当者しか知らなかったとしても、狭い意味での暗黙知ではありません。
対象固有の未記録の事実です。本来は構成資料、証明書台帳、設定情報などに記録されるべきものです。
「自己署名証明書は、公的証明書として扱わない」
これは経験者だけが知るべき勘ではありません。
組織として明示すべき用語定義・判定ルールです。
「この管理表が、設問にある全社台帳に該当する」
管理表の正式な位置づけや名称対応が整理されていないなら、それは未整理の関係知です。
「この情報は設計書ではなく、変更チケットを探す必要がある」
これは評価者の熟練として現れやすいものですが、少なくとも一部は探索手順や文書マップとして外在化できます。
「この代替統制なら、指定された対策と同等のリスク低減を実現している」
ここには、技術、業務、リスク、過去事例を統合する経験的な判断知が含まれます。すべてを固定ルールへ変換するのではなく、人が根拠と文脈をレビューすべき領域です。
このように分けると、評価業務の課題は「暗黙知が多い」というより、次の状態にあると捉えた方が正確です。
本来は記録・定義・構造化できる事実やルールまで暗黙化し、本当に人に残る判断知との区別がついていない。
「暗黙知」という言葉の解像度が低いと、対策を間違える
異なる問題を一括して暗黙知と呼ぶ最大の問題は、施策を誤ることです。
| 実際の問題 | 誤った対策 | より適切な対策 |
|---|---|---|
| 未記録の事実 | ベテランへのヒアリングだけを行う | 記録項目、台帳、設定取得を整備する |
| 未明文化のルール | 事例を大量に集めるだけ | 定義、適用条件、証拠要件、判定ルールを決める |
| 未整理の関係知 | マニュアルを増やす | メタデータ、対応表、文書所有者、版管理を整備する |
| 未標準化の手順知 | 個人の工夫に任せる | 検索順序、確認フロー、照会先を標準化する |
| 経験的な判断知 | 単一の正解ルールへ固定する | 判断事例、理由、例外を蓄積し、人がレビューする |
| 身体的暗黙知 | 文章だけで伝える | 実演、反復、映像、センサー、シミュレーションを使う |
すべてを「暗黙知の形式知化」という同じ施策で解決しようとすると、本来データ化すべき事実がヒアリングメモに残り、本来ルール化すべき基準が事例集の中に埋まり、本当に身体で学ぶべき技能をマニュアルだけで伝えようとすることになります。
AIが補完しているものを、暗黙知と混同しない
生成AIは、文書に明記されていない背景や関係を補っているように見えることがあります。しかし、AIが担当者の頭の中にある暗黙知を直接取り出しているわけではありません。
LLMは、学習時に得た一般的な知識と、入力された質問や資料の文脈に基づいて、もっともらしい出力を確率的に生成します。そのため、資料に書かれていない対象固有の事実を知っているわけではありません。
AIは、知識整理を大きく支援できます。
- 大量の資料から関連箇所を探す
- 表記の異なる用語を対応付ける
- 過去の判断理由を分類する
- 共通ルールの候補を抽出する
- 文書間の矛盾や不足を示す
- 一次評価とレビュー対象を整理する
しかし、AIが支援できることと、AIに事実を推測させてよいことは異なります。
一般的な製品知識から、資料にない設定を補う。組織で決めていない判定ルールを、もっともらしい一般論から作る。対象固有の事実を、周辺情報から断定する。
これらは暗黙知の活用ではなく、証拠のない事実補完です。
評価業務では、次の三つを明確に分ける必要があります。
-
解釈知識
用語、組織固有の意味、適用範囲、過去事例など、評価項目と資料を読むための知識。 -
判定根拠
対象の構成、設定、契約、運用、実施記録など、今回の判定を直接裏付ける情報。 -
判定ルール
確認した事実を、対応済・未対応・対象外・判断不可などの結果へ変換する条件。
解釈知識は、判定根拠を読むために必要です。しかし、解釈知識そのものを、対象で対策が実施されている証拠として使ってはいけません。
Batch Assessmentの設計に、この見解をどう反映しているか
この区別は、Batch Assessmentの設定思想にも反映されています。
Batch Assessmentでは、AIが参照するRAGデータベース、固定参照文書、メタデータによる検索範囲を設定できます。また、評価選択肢には判定名だけでなく、何を確認した場合にその判定とするか、どの証拠が必要か、情報不足をどう扱うかを定義できます。
プロンプト設計では、次の点を明示することを重視しています。
- 判定より先に要求事項を分解する
- 方針証跡と実施証跡を区別する
- 評価対象と評価時点を確認する
- 判定順序を固定する
- 一般知識による資料外の事実補完など、禁止する推論を定める
AIは、文書と証跡を探索し、確認できた事実、判断理由、引用箇所、参照元、不足情報を一次整理します。人は、曖昧な証拠、例外、代替統制、組織固有の解釈、リスク受容をレビューし、最終判断を行います。
ここで目指しているのは、担当者の頭の中を丸ごとAIへ複製することではありません。
AIが扱える形へ整理すべき知識と、人の専門判断として残すべき知識を切り分けることです。
AIの誤りは、組織の知識構造の空白を教えてくれる
AIが誤った判定をしたとき、単に「モデルの精度が低い」と考えるだけでは不十分です。
なぜ誤ったのかを分解すると、業務側の不足が見えてきます。
- 用語の定義がなかった
- 対象固有の情報が記録されていなかった
- 資料同士の対応関係が整理されていなかった
- 十分な証拠の条件が決まっていなかった
- 複数条件の集約方法がなかった
- 例外判断の過去事例が残されていなかった
この意味で、AIは暗黙知を自動的に吸い上げる装置というより、組織の知識構造の空白を可視化する装置として捉える方が適切です。
人は経験で空白を埋められるため、業務設計上の不足が見えにくくなります。AIはその空白を別の方向へ補完したり、判断できなかったりするため、どの前提が共有されていなかったのかが表面化します。
「暗黙知か」を判断するための六つの問い
担当者しか知らない情報が見つかったとき、すぐに暗黙知と呼ばず、次の順序で確認すると整理しやすくなります。
-
特定の対象や時点についての事実か
そうであれば、資料、台帳、設定、データとして記録すべき情報です。 -
安定した条件として文章化できるか
できるなら、用語定義、業務ルール、評価仕様として管理すべき知識です。 -
何と何が対応するかという関係情報か
そうであれば、メタデータ、対応表、文書管理、責任分界で整理できます。 -
どこを探し、誰に聞くかという進め方か
そうであれば、検索設計やワークフローとして標準化できます。 -
過去事例と理由を示せば、判断を説明できるか
できるなら、事例知として外在化し、人とAIのレビューに利用できます。 -
身体感覚や共同体への参加がなければ習得できないか
この場合は、狭義の暗黙知である可能性が高く、文書化だけでは継承できません。
「暗黙知の形式知化」から、「知識の属性を見分ける」へ
企業に暗黙知が存在しないわけではありません。
経験によって培われた診断力、例外を見抜く感覚、状況に応じて規則を上書きする判断、身体に根差した技能、共同体へ参加することで身につく作法は、確かに存在します。
しかし、企業が「暗黙知」と呼んでいる問題のすべてが、そのような知識ではありません。
少なくとも、私たちがBatch Assessmentを提供する中で向き合ってきた評価業務では、本当に担当者固有の暗黙知と呼べる部分は限定的でした。
多くは、書けない知識ではなく、まだ書かれていない知識でした。
知られていない知識ではなく、記録されていない事実でした。
形式化できない判断ではなく、組織として定義していないルールでした。
評価業務の課題は、暗黙知が多いことだけではありません。
本来は記録・定義・構造化できる情報まで暗黙化し、本当に人に残る判断知との区別がついていないことにあります。
AI時代に必要なのは、あらゆる暗黙知を無理に形式知へ変えることではありません。
何をデータとして残すのか。何をルールとして定めるのか。何を関係情報として整理するのか。何を事例として蓄積するのか。何を人の判断として残すのか。何を身体を通じて継承するのか。
「暗黙知」という便利な一語を一度ほどいてみる。
そこから初めて、知識継承、業務標準化、AI活用のそれぞれに、適切な方法を選べるようになります。
参考文献
- Polanyi, M. (1966). The Tacit Dimension. Doubleday. Reprinted by the University of Chicago Press. Publisher page
- Nonaka, I. (1994). “A Dynamic Theory of Organizational Knowledge Creation.” Organization Science, 5(1), 14–37. https://doi.org/10.1287/orsc.5.1.14
- Nonaka, I., & Takeuchi, H. (1995). The Knowledge-Creating Company: How Japanese Companies Create the Dynamics of Innovation. Oxford University Press. Publisher page
- Tsoukas, H. (2003). “Do We Really Understand Tacit Knowledge?” In M. Easterby-Smith & M. A. Lyles (Eds.), The Blackwell Handbook of Organizational Learning and Knowledge Management, 411–427. Blackwell. Author manuscript
- Collins, H. (2010). Tacit and Explicit Knowledge. University of Chicago Press. Publisher page
- Leonard, D., & Sensiper, S. (1998). “The Role of Tacit Knowledge in Group Innovation.” California Management Review, 40(3), 112–132. Harvard Business School record
- Adler, P. S. (1995). “The Dynamic Relationship Between Tacit and Codified Knowledge: Comment on Nonaka.” In J. Allouche & G. Pogorel (Eds.), Technology Management and Corporate Strategies: A Tricontinental Perspective, 110–124. North-Holland. Author publication list and manuscript