「暗黙知を言語化して生成AIに渡そう」という話、最近よく聞きます。至るところで暗黙知の言語化が語られています。 エキスパートの経験知を引き出してプロンプトに込め、AIの精度を上げる。方向性としては理解できますし、進めないといけない側です。
でも、その「暗黙知」って何なんでしょうか？
「形式知になっていないもの全般」という暗黙の了解が漂っています。あるいは「まだドキュメント化されていない情報」。 気持ちはわかるんですが、それだと定義が反転してる。「Xでないもの」によって定義しているだけで、Xの中身が空のまま。
この曖昧さを引きずったまま議論を進めると、「言語化できれば全部解決する」という楽観論になっちゃって、言語化できない部分が静かに見落とされ、「なんかAIに渡してみたけどうまくいかない」という結果に着地してしまいそう。
順を追って考えましょう。まず暗黙知とは何か。それを踏まえて、生成AIへ渡すとはどういうことなのか。
私たちは「言えること以上のことを知っている」
暗黙知という概念を体系化したのは、英国の哲学者マイケル・ポランニー（Michael Polanyi）と言われています。彼はこう言いました。
We can know more than we can tell. 「私たちは言えること以上のことを知っている」
たった一文ですが、この命題の射程は想像より広い。
ポランニーが指摘したのは、知識には2種類あるということです。言語や数式で表現できる形式知（explicit knowledge）と、言語化が困難または原理的に不可能な暗黙知（wikipedia:tacit knowledge）。そして重要なのは、すべての形式知も暗黙知に根ざしているという点です。書き言葉で伝えられた知識でさえ、読み解きに活用するためには暗黙的な理解が前提になる。
暗黙知は「まだ言語化されていないだけの情報」ではありません。書くのが面倒で後回しにしているとか、必ずしもそういう話ではない。暗黙知とは、本人が逐語的に説明できない形で保持されている知の形態そのものです。「言語化の手間」の問題ではなく、「知の構造」の問題です。
暗黙知には地形がある
暗黙知を一枚岩の概念として扱うと、議論がかみ合わなくなります。暗黙知には「地形」があるとされていて、言語化の可能性が地形によって大きく異なるからです。
- 関係的暗黙知（Relational tacit knowledge）は、原則として言語化できるが、知識の性質や人間の認知的・社会的な制約から難しいものです。「そう言われれば説明できる」けれど、日常的に意識せずに使っているような知識。経験を積んだエンジニアが「なんか変だな」と感じるコードへの直感は、うまく掘り起こせば言語化できることが多い。
- 身体的暗黙知（Somatic tacit knowledge）は、身体に刻まれたスキルです。自転車の乗り方を言葉で説明するとどうなるか、想像してみてください。「ハンドルを握り、重心を意識しながらペダルを…」。乗れるようになった人には伝わりますが、乗れない人への説明としてはほぼ役に立たない。乗ってみて転んで、ある瞬間にわかる。そういう種類の知識です。
- 集合的暗黙知（Collective tacit knowledge）は、社会や組織に埋め込まれた知識です。言語の文法規則がその典型で、ネイティブスピーカーは正しい文を生成できるのに、なぜ正しいかをうまく説明できません。
「暗黙知を言語化する」という一言は、実は難易度がまったく異なる複数の問題を束ねています。掘り起こせば言語化できる部分と、どうがんばっても無理な部分がある。後者を「できた」と誤認した瞬間、知の移転は失敗します。
暗黙知を実務上で観察する4つの側面
コリンズの3地形は理論として整合している一方で、現場でエキスパートから話を聞く場面で使いやすいかどうかは別の話です。「あなたの身体的暗黙知を教えてください」と聞いて答えが返ってくる気はしない。ここでは知識を引き出す側の視点から、もう少し粒度を落とした4つの側面を整理します。
- 熟達した知覚は「何を重要な手がかりとして見るか」です。ベテランのSREが障害対応で「まずキューを確認する」というとき、なぜ見たのかを本人に聞いても「なんとなく」か「経験です」しか返ってこないことが多い。「なんとなく」は答えではないものの、嘘でもない。非専門家には見えていないシグナルが、エキスパートには背景として自明に見えています。たぶんな。暗黙知の中では、比較的言語化できる側面。
- 状況判断のパターンは、裏から言えば「何を最初に捨てるか」です。エキスパートは全候補を網羅的に評価しません。「この条件下ではDB問題はまず考えない」というルールを無意識に持っていて、「なぜその選択肢を考えなかったのか」を明示的に問わないと、まず浮かび上がってこない。知覚に根ざした判断作法、と言い換えてもいいかもしれません。
- 身体化された技能は、言語インタビューで最も回収しにくい部分です。デバッグの手順、コードレビューの視線の動き。「どこを最初に見ますか」と聞いたところで、「まあ、全体を見てから…」という答えしか返ってこない。見ている最中、横で聞いていないと捉えられない。これだけ言葉数を使っても説明できないのが、身体化された技能です。
- 価値観・審美眼は少し性質が異なります。「この設計は将来の変更耐性を壊す」という判断の背後にある品質基準は、個人の頭の中だけにあるというより、グループ・チームの中で作られた規範を内面化したものです。コリンズのいう集合的暗黙知と重なる部分が大きい。「なぜ悪いか」を説明させるだけでは「どんな場合に例外か」という条件が抜け落ちるため、成果物と突き合わせながら聞かないと引き出せない。
この4側面は唯一の正解ではありません。ただ、「エキスパートに何を聞けばいいか」を整理するフレームとしては機能するでしょう。しかし問題は、引き出した知識をそのままLLMへの説明文として書き下そうとしても詰まることです。観察フレームと実装設計は別の問題で。
SECIモデルと「完全言語化」という幻想
野中郁次郎のwikipedia:SECIモデルを知っている人は多い。暗黙知→形式知（表出化）、形式知→暗黙知（内面化）、暗黙知同士（共同化）、形式知同士（連結化）の4モードです。よく引用されるのは「表出化すれば移転できる」という読み方ですが、そこには肝心なことが省かれています。
「知識を表出化すれば移転できる」という読み方があり得ますが、ポランニーはそれに同意しないはずです。「暗黙知は原理的には言語化しきれない」が彼の立場でした。SECIモデル自身も、共同化（訓練や共同作業でしか移れない部分）を別枠で設けています。「書き出せば知識移転できる」という読み方は、正しくないと思います。
「とにかく書き出す」アプローチが壁にぶち当たるのは、身体化された技能や深い価値観の部分が根本的に欠落したまま、知識移転が完結したと誤認されるからです。Wikiが充実しているのに新人がいつまでも育たない、というよう感じの正体がここにあります。ドキュメントは形式知の入れ物であって、暗黙知の移転ルートではない。
では、言語化しきれない部分があるとして、そこに渡せるものは何なのか。「知識を書き下してください」という依頼が詰まるなら、渡すべきは内容ではなく、条件なのではないでしょうか。エキスパートがどこで切り、何を捨て、どこまで踏み込むか。その判断の構造を、AIが動ける形に再設計する。
では、生成AIへの移植はどこで詰まるか
前節の話を踏まえれば、「プロンプトに書き下す」アプローチがなぜ詰まるかは自明です。言語化しきれない部分がある以上、どれだけ丁寧に書いても、プロンプトは欠けた知識のままAIに渡される。「書き方の問題」ではなく、「設計の問題」です。
PoliPoliによる政策議事録の自動分析は、国会・省庁の長大な議事録からスタンスを抽出しようとする試みです。ドメインエキスパートには当たり前に見えている「読み方」をLLMに実装しようとしたとき、4種類の詰まり方をしました。
- 分類の粒度ではなく、分類の目的がずれていたことです。ドメインエキスパートの8分類は「会議の性質」を説明するための概念であり、パイプラインが必要としていた「後続処理の分岐単位」ではなかった。実質2パターンで足りた。数が減ったのではなく、設問が変わった。
- 検索単位と読解単位の不一致。1発言チャンクのベクトル検索では、政策会議特有の婉曲表現や留保つきの賛否を安定して拾えなかった。専門家はその一文だけでなく、話者がその日を通じて何を繰り返し強調しているかまで含めて読んでいる。必要だったのは単発言の近傍検索ではなく、話者の累積発言という単位で文脈ごと推論すること。
- ノイズの多さそのものではなく、選別規則が実装されていなかったことです。15万文字の議事録には重みの低い発言が大量に含まれ、専門家はそれらを「読む前から」無意識に捨てている。でもその捨て方は誰もプロンプトに書かなかった。それだけのことです。
- 曖昧な表現をどこまでスタンスとして確定してよいかという裁量基準が未定義だったことです。「方向性には賛同するが、段階的導入が必要」を留保つき賛成と読むかどうかには、ドメイン固有の裁量が要る。その判断ルールが渡されていなかった。
この4つの詰まり方を並べると、パターンが見えてきます。「何をシグナルとして読むか（観点）」「何を判断の単位にするか（判断単位）」「何を読む前に捨てるか（省略と編集）」「どこまで推定してよいか（裁量のルール）」——この4種類の設計判断が、ずっと暗黙のままだった。
詰まり方の4パターンをさっきの4側面に重ねてみると、2番目（検索単位）は「熟達した知覚」、1・3番目（分類と選別）は「状況判断のパターン」、4番目（裁量基準）は「価値観・審美眼」にハマりそうです。唯一の例外が「身体化された技能」で、これだけ設計判断に変換できない。その非対称性が、「暗黙知の言語化」という一括りの言葉を怪しくしている。
つまり詰まったのは、LLMの能力ではなく、専門家の「当たり前」がシステムに渡されていなかったからです。
念のため言うと、4種類の判断を1本のプロンプトに詰め込んでも解決しない。指示が過密になった瞬間、モデルはどこで何を判断すればいいかわからなくなる。経験談です。
必要なのは、「知識を書く」ことではなく、「判断が働く位置を分解する」ことなのでしょう。何を先に除去するのか。どの単位で分類するのか。どこから先を推定として扱うのか。そうした設計判断を、プロンプトの説明文ではなく、処理段階そのものに埋め込んでいく。
最後に
最初の問いは「暗黙知」って何ですか、でした。
「まだドキュメント化されていない情報」という答えが間違っているのは、言語化すれば終わりだという錯覚を生むからです。暗黙知は、本人が逐語的に説明できない形で保持されている知の形態そのもの。言語化できる部分と、できない部分がある。そしてLLMへの移植を考えるなら、その先にまだ設計があります。
何を捨てるか、何を単位にするか、どこまで推定を許すか。そういった設計を誰かがやらないと、暗黙知はずっと暗黙のままです。「書いたからOK」は、たぶんまだ半分も来ていない。
