ベテランの暗黙知をLLMで解凍する：属人化の壁を突破するエンジニアリング

深夜の障害対応、あるいは複雑なレガシーシステムの改修現場で、我々エンジニアが最も絶望するのは「ドキュメントの空白」に直面した瞬間だ。目の前のシステムは悲鳴を上げているのに、WikiやConfluenceを検索しても、そこにあるのは数年前に更新が止まった「表層的な手順書」だけ。ベテランの先輩に聞けば「ああ、そこはなんとなくの勘で調整してるよ」と返される。この「なんとなく」こそが、組織の生産性を根底から蝕む暗黙知の正体だ。なぜ、我々はこれほどまでに文書化に執着し、そして失敗し続けるのか。

暗黙知とは、単に「難しい知識」ではない。本人があまりに熟練しすぎていて、もはや意識すらしていない「判断の自動化プロセス」そのものだ。これを文書化しようとすると、必ず以下の3つの構造的欠陥に突き当たる。

• 認識のレイヤー不一致：本人が自覚しているのは判断の「結果」だけであり、その背後にある膨大なコンテキスト（なぜその選択肢を捨てたのか、どのリスクを許容したのか）は言語化の対象外となっている。
• 静的ドキュメントの死：システムやビジネス環境は日々デプロイされ、変化し続ける。しかし、一度書かれたドキュメントは「書いた瞬間に陳腐化」する。更新コストを誰が払うのかという問いに対し、現場は常に沈黙する。
• アクセシビリティの欠如：最も知りたい「トラブルの最中」に、分厚いマニュアルを読み解く余裕など誰にもない。結局、現場で頼りになるのは「あの人に聞く」という属人化されたコミュニケーションだけだ。

我々エンジニアは、コードのドキュメント化にはうるさいが、肝心な「判断のロジック」をコード化することには極めて無頓着だった。この「文書化しても継承できない」という構造的な限界は、これまで熟練インタビュアーによるヒアリングという、極めてコストの高い手法でしか突破できなかった。しかし、それはスケールしない。一人分を抽出するのに数十時間を費やし、しかもその成果物が静的なテキストで終わるなら、それは投資対効果としてあまりに低い。我々が直面しているのは、知識の継承という名の「終わりのないデッドロック」なのだ。

今、生成AI（LLM）の登場によって、この「暗黙知の抽出」というボトルネックが劇的に解消されようとしている。重要なのは、AIに「すべてを代行させる」という幻想を抱かないことだ。AIの真価は、熟練インタビュアーが担っていた「問いを立てる」という作業を、低コストかつ高頻度でスケールさせる点にある。具体的には、日々の業務履歴や判断の差分をAIが監視し、「なぜこのケースではいつもと違う判断をしたのか？」という鋭い問いを、適切なタイミングで本人に投げかける仕組みだ。

このアプローチが従来の文書化と決定的に異なるのは、それが「静的な記録」ではなく「動的な対話」であるという点だ。週に10分、AIからの問いに答えるだけで、その人の判断ロジックがコンテキストとして蓄積されていく。これはモデルをファインチューニングして固定化するような重い作業ではない。個人の判断の軌跡を、組織の共有知として「積み上げていく」プロセスだ。これにより、マニュアルは「書くもの」から「対話を通じて勝手に育つもの」へと変貌を遂げる。

ただし、ここでエンジニアとして冷静な線引きが必要だ。この手法が有効なのは、あくまで「脳内知（判断やロジック）」の領域に限られる。機械の異音や温度、あるいは職人の手の感触といった「身体知」は、LLMのテキストベースの対話では到底カバーできない。これらはセンサーデータやIoTデバイスによる計測など、物理的なアプローチと組み合わせる必要がある。技術の適用範囲を正しく理解し、脳内知と身体知を切り分けて設計することこそが、シニアエンジニアに求められるアーキテクチャの視点だ。

結局のところ、我々が目指すべきは「AIによる代替」ではなく「AIによる拡張」だ。ベテランの判断を組織の資産として残すことは、単なるナレッジマネジメントではない。それは、組織が抱える「属人化という名の技術的負債」を、AIというレバレッジを使って返済し続けるプロセスそのものだ。明日から我々が取り組むべきは、自らの業務の中で「言語化できていない判断」を特定し、それをAIに問い直させるためのパイプラインを構築することである。あなたは、自分の判断をAIに説明できるだろうか？その問いに答えられない限り、あなたの知識は組織にとってのブラックボックスであり続けるだろう。