本記事は「判断エンジニアリング」シリーズ（全3回）の第1回です。
判断エンジニアリングとは、判断そのものをAIに置き換えるのではなく、人とAIが質の高い判断を速く行い、その判断が再利用される条件を設計することです。
はじめに
AIプロダクト開発に関わるなかで、会議記録や既存文書を生成AIから検索できるようにしても、熟練者の判断をうまく再現できないことがありました。
たとえば、ある会議で経験豊富なメンバーが、次のように発言したとします。
この案件、少し危ない気がします。
会議を文字起こしすれば、この発言自体は記録できます。
しかし、後から別のメンバーやAIが記録を読んでも、次のことは分かりません。
- 何を見て「危ない」と判断したのか
- 過去のどの経験と似ていたのか
- 何が起きると予想していたのか
- 次に何を確認すべきなのか
- どの条件なら、心配しなくてもよいのか
文字起こしに残っているのは、判断の結論です。
その人が結論へ至るまでに使った、観察、経験、解釈、例外条件といった判断文脈は、ほとんど残っていません。
この経験から、暗黙知をAIで扱うためには、会話や文書を集めるだけでは足りないと考えるようになりました。
本記事では、暗黙知と形式知の違いを整理し、SECIモデルを手掛かりにしながら、次の問いを考えます。
人の経験に基づく判断を、AIや他のメンバーが再利用できる知識として扱うには、何が必要なのか。
そして、そのための実務上の考え方を、本稿では暗黙知AIマネジメントと呼びます。
なお、これは現時点で確立された学術用語ではなく、AIを用いた知識管理の実務を整理するための作業概念です。
この記事で伝えたいこと
本記事の主張は、次の3点です。
- AIが直接扱えるのは、人の頭の中にある暗黙知そのものではなく、発言や行動に現れた痕跡である
- 残すべきなのは結論だけではなく、結論に至った判断文脈である
- AIが作るのは確定した知識ではなく、人間がレビューすべき知識候補である
1. 暗黙知とは何か
暗黙知を考えるうえで、よく知られているのがマイケル・ポランニーの言葉です。
We can know more than we can tell.
日本語にすると、「私たちは、語ることができる以上のことを知っている」という意味です。
人間は、自分が知っていることや、実際にできていることのすべてを、言葉や手順として完全に説明できるわけではありません。ポランニーは、この言語化しきれない知の側面を論じました。[1]
身近な例は、自転車の運転です。
自転車に乗れる人は、車体の傾き、速度、視線、ハンドルへ加える力などを、ほぼ無意識に調整しています。
しかし、その調整を文章で完全に記述し、まだ自転車に乗れない人へ渡しても、その人がすぐ乗れるようになるわけではありません。
知っていることと、説明できることの間には差があります。
実務における暗黙知
本稿では、実務における暗黙知を次のように捉えます。
業務上の判断や行動へ影響しているものの、本人が十分には言語化できず、他者が再利用できる形でも残っていない知識。
たとえば、次のような知識です。
- 設計書のどこを見れば問題の兆候を発見できるか
- 顧客の発言のどこに違和感を覚えたか
- 標準手順から外れるべき状況は何か
- どの段階で責任者へ相談すべきか
- 似た障害の中から、本当に緊急性が高いものをどう見分けるか
- 相手や状況によって説明の順番をどう変えるか
これらは単なる「勘」ではありません。
多くの場合、過去の経験から学習したパターン、注意すべき兆候、状況ごとの判断、失敗を避けるための補正行動が組み合わされています。
ただし、その処理が本人の中で高速化されているため、本人自身にも、すぐには説明できません。
2. 「文書にない知識」をすべて暗黙知と呼ばない
実務では、「文書化されていない知識」が一括して暗黙知と呼ばれることがあります。
しかし、文書にないからといって、すべてが暗黙知とは限りません。
たとえば、
この顧客の最終決裁者は事業部長です。
という情報が文書に残っていなくても、担当者がすぐ説明できるなら、それは厳密には暗黙知というより、単に未記録の知識です。
一方、
この顧客は、提案内容よりも社内で説明しやすいことを重視しているように感じる。
という判断には、過去の会話、反応、社内事情、提案への修正依頼などが複雑に関係している可能性があります。
さらに、
いつもと機械の音が違う。
という熟練者の感覚は、本人にも完全には説明できないかもしれません。
これらを分けて考えると、AIで扱える範囲が見えやすくなります。
| 種類 | 状態 | AIによる扱いやすさ |
|---|---|---|
| 未記録知 | 本人は説明できるが、文書に残っていない | 比較的扱いやすい |
| 暗黙的な判断知 | 具体的な出来事をたどれば、判断の一部を説明できる | 対話とレビューが必要 |
| 深い暗黙知 | 身体感覚や熟練した統合判断など、十分には言語化できない | 完全な形式知化は難しい |
本稿で主に対象とするのは、2番目の暗黙的な判断知です。
暗黙知のすべてを文章へ変換しようとするのではありません。
具体的な出来事を振り返ることで、部分的に説明でき、他者やAIが再利用できる部分を対象とします。
3. 形式知とは何か
形式知とは、言葉、数値、図、記号などで表現され、他者が参照できる知識です。
たとえば、次のようなものです。
- 手順書
- 設計書
- 仕様書
- FAQ
- チェックリスト
- 規程
- テンプレート
- データベース
- ソースコード
形式知は、保存、検索、複製、共有が比較的容易です。
生成AIやRAGも、基本的には、何らかの形で外部化された情報を入力として利用します。
「文字になったこと」と「形式知になったこと」は同じではない
ここで重要なのは、文字起こしされた発言が、ただちに再利用可能な形式知になるわけではないことです。
次の発言を考えてみます。
このスケジュールでは危ない。
これは文字になっているため、外部化された記録ではあります。
しかし、別の人が判断へ利用するための情報は不足しています。
- 何が危ないのか
- どの兆候からそう判断したのか
- どの程度の遅延を想定しているのか
- 何を変更すべきなのか
- どの条件なら問題ないのか
つまり、次の3段階は区別する必要があります。
| 段階 | 例 |
|---|---|
| 出来事の記録 | 「このスケジュールでは危ない」と発言した |
| 判断の意味付け | 要件が未確定なのに、実装期間が固定されている |
| 再利用可能な知識 | 要件の不確実性が高い段階では、実装期間を固定する前に検証期間を設ける。ただし、変更範囲が限定されている場合は除く |
会話を記録することは、知識化の入口です。
しかし、記録しただけでは、その発言の背後にある判断は再利用できません。
4. SECIモデルを簡単に整理する
暗黙知と形式知の関係を、組織的な知識創造へ広げた代表的な理論が、野中郁次郎氏によるSECIモデルです。
SECIモデルでは、組織の知識は暗黙知と形式知の継続的な相互作用を通じて生まれるとされ、4つの知識変換モードが示されています。[2]
| モード | 英語 | 知識の動き | 例 |
|---|---|---|---|
| 共同化 | Socialization | 暗黙知から暗黙知 | OJT、同行、観察、共同作業 |
| 表出化 | Externalization | 暗黙知から形式知 | 対話、振り返り、文章化、概念化 |
| 連結化 | Combination | 形式知から形式知 | 文書の比較、分類、統合、体系化 |
| 内面化 | Internalization | 形式知から暗黙知 | 実践、訓練、経験を通じた習得 |
たとえば、設計レビューを考えてみます。
- 若手がベテランのレビューへ参加し、着眼点を観察する
- ベテランが、なぜその箇所を問題視したのか説明する
- 複数のレビュー結果を整理し、チェックリストへまとめる
- 若手が実際のレビューで使い、経験として身につける
知識は、文書にして終わるのではありません。
人から人へ伝わり、言葉になり、他の情報と結びつき、再び実践を通じて人の能力になります。
暗黙知をすべて形式知へ変換できるわけではない
SECIモデルを、暗黙知をすべて文書へ変換する工程として理解するのは危険です。
暗黙知の中には、身体性や状況、他者との関係に深く埋め込まれ、完全には言語化できないものがあります。暗黙知を単に「まだ言葉になっていない知識」と捉えることには、知識研究の中でも批判があります。[3]
そのため、本稿の目標は次のように限定します。
暗黙知そのものを完全に移し替えるのではなく、判断に現れた一部を、再利用可能な形で外部化する。
5. 生成AIはSECIのどこを支援できるのか
生成AIは、SECIモデルの各プロセスを置き換えるものではありません。
一方で、特に表出化と連結化を支援できます。
| SECI | AIが支援できること | 人間に残る役割 |
|---|---|---|
| 共同化 | 会話や作業記録の整理、ケースの再現 | 共同経験、観察、関係構築 |
| 表出化 | 振り返りの質問、要約、構造化、言い換え | 意味の確認、経験の内省、承認 |
| 連結化 | 複数事例の比較、分類、共通点や矛盾の整理 | 重要性の判断、組織方針との整合 |
| 内面化 | ケース演習、対話型の振り返り | 実践、責任ある意思決定、経験学習 |
たとえば、「この案件は危ない」という発言に対して、AIは追加の問いを提示できます。
- 最初に違和感を覚えた発言や出来事は何でしたか
- 過去のどの事例と似ていますか
- 放置すると、何が起きると考えましたか
- 実際にどのような対応を取りましたか
- この判断が当てはまらないケースはありますか
こうした質問は、本人が自分の判断を振り返るきっかけになります。
ただし、AIが暗黙知を自動的に正しく取り出しているわけではありません。
AIが扱えるのは、発言、行動、修正、選択、例外対応といった、暗黙知が外部へ現れた痕跡です。
6. AIが作るのは「知識」ではなく「知識候補」
会議記録をAIへ渡すと、次のような文章を生成するかもしれません。
決裁者が会議に参加していない案件は、プロジェクトリスクが高い。
もっともらしい説明です。
しかし、これをそのまま組織のルールにすることはできません。
- 代理権を持つ参加者がいれば問題ないのではないか
- 企画段階と契約段階では重要度が異なるのではないか
- 一部の案件だけに当てはまった経験ではないか
- 業界や顧客規模によって事情が違うのではないか
- 決裁者が参加しないこと自体ではなく、合意経路が不明なことが問題なのではないか
AIは、個別事例から過度に一般化する可能性があります。
また、発言されていない理由を、自然な文章で補ってしまう可能性もあります。
したがって、AIが生成した内容は、確定した知識ではなく、次のように扱うべきです。
AIが作るのは、専門家が検討するための知識候補である。
知識候補には、少なくとも次の状態を持たせる必要があります。
未確認
↓
レビュー中
↓
承認済み
↓
修正・更新
↓
非推奨・廃棄
AIが生成したことではなく、人間がどの根拠と条件で承認したかによって、その知識を利用できる範囲が決まります。
7. 残すべきなのは「答え」だけではなく「判断文脈」
暗黙的な判断知を再利用するためには、結論だけを保存しても十分ではありません。
残すべきなのは、結論に至った判断文脈です。
本稿では、判断文脈を次の要素で捉えます。
| 項目 | 残す内容 |
|---|---|
| 状況 | どの業務、顧客、工程、時点で起きたか |
| 兆候 | 何を見たり聞いたりして違和感を覚えたか |
| 解釈 | その兆候をどのように意味付けしたか |
| 根拠 | 過去の経験や、どの事実と結びつけたか |
| 判断 | 何をリスク、機会、例外と判断したか |
| 推奨行動 | 次に何を確認、変更、依頼すべきか |
| 適用条件 | どの状況でこの判断が使えるか |
| 対象外条件 | どの状況では使うべきでないか |
| 反例 | 似ているが、同じ判断をすべきでない例 |
| 結果 | 判断を使った結果、何が起きたか |
結論だけを残した場合
この案件は危ない。
この情報だけでは、次の案件で何を確認すべきか分かりません。
判断文脈を残した場合
【状況】
提案段階。顧客の要望は大きいが、成果物と対象範囲が確定していない。
【兆候】
実質的な意思決定者が会議に参加しておらず、
会議のたびに前提条件が変わっている。
【解釈】
参加者間で期待する成果が一致していない可能性がある。
契約後に対象範囲が拡大するリスクが高い。
【推奨行動】
次回の会議で、目的、成果物、判断者、対象外事項を確認する。
提案書には前提条件と対象外事項を明記する。
【対象外条件】
参加者が十分な代理権を持ち、
意思決定者との合意内容が文書で共有されている場合は、
同じリスク判断をそのまま適用しない。
後者であれば、別のメンバーが類似案件の確認へ利用できます。
AIも、提案書レビューや会議準備で、
- 意思決定者は明確か
- 成果物は合意されているか
- 前提条件が変化していないか
- 対象外事項は明記されているか
といった確認を支援できます。
AIが必要としているのは、単なる正解集ではありません。
どの状況で、何を見て、なぜそう判断し、次に何をするのか。
この判断文脈が、人とAIの両方にとって再利用可能な知識になります。
8. 暗黙知AIマネジメントという考え方
ここまでの内容を、実務上の作業概念として定義します。
暗黙知AIマネジメントとは、人や業務の中に現れる暗黙知の痕跡を発見し、AIを用いて知識候補へ整理し、人間のレビューを経て業務で利用し、その結果から継続的に更新・廃棄するマネジメント活動である。
重要なのは、暗黙知AIマネジメントが、単発の「暗黙知抽出」ではないことです。
一度インタビューして、ナレッジを作って終わりではありません。
暗黙知AIマネジメントには、次の一連の活動が含まれます。
- 判断が発生した出来事を見つける
- 判断の背景を具体的な経験から振り返る
- AIが判断文脈の候補を整理する
- 専門家が正確性や適用条件を確認する
- 承認された知識を業務で使う
- 利用結果から修正や反例を追加する
- 古くなった知識を非推奨または廃棄する
RAGとの関係
暗黙知AIマネジメントは、RAGと対立する概念ではありません。
RAGは、既に存在する文書やデータを検索し、回答生成へ利用するための技術です。
一方、暗黙知AIマネジメントが扱うのは、その前後です。
出来事や経験
↓
判断文脈の表出化
↓
人間によるレビュー
↓
再利用可能な知識
↓
RAGやAIエージェントによる利用
↓
利用結果からの更新
RAGの検索精度を上げるだけでは、文書に存在しない判断知は取得できません。
まず、何を知識として残すのかを設計する必要があります。
そして、登録された知識が現在も正しいか、利用後にどう更新するかを管理する必要があります。
9. ボトルネックは「生成」から「レビュー」へ移る
生成AIを利用すると、会議や文書から多くの知識候補を作れるようになります。
一方で、専門家が確認できる時間は急には増えません。
AIが作れる知識候補：増やしやすい
専門家が確認できる時間：増やしにくい
そのため、すべての候補を同じ粒度で専門家へ確認させる運用は持続しにくくなります。
レビューを、専門家の善意や空き時間に依存させてはいけません。
専門家が確認すべきこと
知識候補をレビューするときは、文章の言い回しだけではなく、次の点を確認します。
| 観点 | 確認すること |
|---|---|
| 正確性 | 内容は事実や経験と一致しているか |
| 根拠 | どの発言、出来事、資料に基づくか |
| 適用条件 | どの状況で利用できるか |
| 対象外条件 | どの状況では利用すべきでないか |
| 反例 | この判断が外れた事例はあるか |
| 一般化の範囲 | 個人の経験か、チーム標準か、組織標準か |
| 責任者 | 誰が承認し、今後更新するか |
| 有効期限 | いつ見直す必要があるか |
すべてをレビューしない
レビュー対象には優先順位が必要です。
たとえば、次の候補を優先します。
- 顧客や社外へ提示されるもの
- AIエージェントが自動的に利用するもの
- 誤った場合の影響が大きいもの
- 複数の案件で再利用されそうなもの
- 既存知識と矛盾しているもの
- 根拠が弱い、または一人の経験に依存しているもの
レビューは、AI出力に丸を付ける品質検査ではありません。
専門家が修正した理由を、次回以降も使える判断基準へ変える活動です。
10. 収集できることと、収集すべきことは違う
会議、チャット、メール、チケット、成果物の修正履歴には、判断知の痕跡が含まれます。
しかし、技術的に収集できるからといって、すべてを収集してよいわけではありません。
暗黙知AIマネジメントは、設計を誤ると、社員の発言や行動を監視する仕組みに見えてしまいます。
知識を提供する人が安心して参加できなければ、率直な会話や失敗の共有が減り、結果的に集まる知識の質も下がります。
最低限、次の原則が必要です。
- 何のために情報を利用するのかを明示する
- 収集対象を目的に必要な範囲へ限定する
- 必要な説明や同意を行う
- 知識の出典と提供者を記録する
- 誰が閲覧・利用できるかを制限する
- 提供者が内容を修正できるようにする
- 一人の判断を、そのまま組織標準にしない
- 個人評価や監視へ安易に転用しない
- 顧客情報、個人情報、機密情報を適切に除外する
また、知識を提供した人の貢献が見えなくなることにも注意が必要です。
組織知として共有することと、知識を生み出した人の貢献を消すことは同じではありません。
11. 最初の一件を知識化する
暗黙知AIマネジメントを、最初から全社規模で始める必要はありません。
まずは、最近起きた一つの判断を選びます。
対象にしやすいのは、次のような出来事です。
- 誰かが「少し気になる」と発言した
- 標準手順とは異なる対応を取った
- レビューで大きな修正が入った
- 問題が起きる前にリスクを回避できた
- 同じ資料を見たのに、人によって判断が分かれた
- 後から「なぜ気づけなかったのか」が議論になった
最小の実践手順
- 一つの出来事を選ぶ
- 結論ではなく、最初に気づいた兆候を確認する
- その兆候をどう解釈したか確認する
- 過去のどの経験や事実と結びつけたか確認する
- 実際に取った行動と理由を整理する
- この判断が使えない条件や反例を一つ挙げる
- 本人または別の専門家が内容を確認する
- 次の類似案件で使い、結果に応じて修正する
判断文脈の簡易テンプレート
## 判断の概要
### 状況
どのような業務・工程・条件だったか。
### 観察した兆候
何を見たり聞いたりして違和感を覚えたか。
### 解釈
その兆候を、どのような意味だと考えたか。
### 判断
何をリスク・機会・例外と判断したか。
### 推奨行動
次に何を確認・変更・依頼すべきか。
### 適用条件
どの状況でこの判断を利用できるか。
### 対象外条件・反例
似ているが、同じ判断を適用すべきでない状況は何か。
### 根拠
関連する発言、資料、過去事例は何か。
### 結果
実際に利用した結果、何が起きたか。
このテンプレートをすべて埋める必要はありません。
重要なのは、「結論をきれいな文章にすること」ではなく、判断を再利用するために不足している情報を見つけることです。
まとめ
会議を文字起こしすれば、発言は残せます。
しかし、発言の背後にある観察、経験、解釈、適用条件まで、自動的に残るわけではありません。
AIが直接扱えるのは、人の頭の中にある暗黙知そのものではなく、発言、行動、修正、例外対応など、暗黙知が外部へ現れた痕跡です。
その痕跡から、AIが判断文脈の候補を整理する。
人間が内容、根拠、適用条件、反例をレビューする。
承認された知識を業務やAIで利用し、結果を見ながら更新する。
古くなった知識は、非推奨または廃棄する。
この循環を、本稿では暗黙知AIマネジメントと呼びました。
暗黙知AIマネジメントとは、暗黙知を一度だけ抽出することではない。
組織の経験から判断文脈を発見し、人とAIが利用できる形で育て続けることである。
次に誰かが、
なんとなく危ない気がする。
と発言したとき、その言葉だけを議事録へ残すのではなく、こう問いかけてみる。
何を見て、そう感じたのですか。
暗黙知を組織の知識として扱う取り組みは、そこから始まります。
参考文献
- Michael Polanyi, The Tacit Dimension, University of Chicago Press, 2009, with a new foreword by Amartya Sen. Originally published by Doubleday in 1966.
- Ikujiro Nonaka, “A Dynamic Theory of Organizational Knowledge Creation,” Organization Science, Vol. 5, No. 1, pp. 14–37, 1994. DOI:
10.1287/orsc.5.1.14 - Haridimos Tsoukas, “Do We Really Understand Tacit Knowledge?”, in Complex Knowledge: Studies in Organizational Epistemology, Oxford University Press, pp. 141–161, 2004. DOI:
10.1093/oso/9780199275571.003.0007
シリーズの続き
本記事は「判断エンジニアリング」シリーズ（全3回）の第1回です。
第2回では、知識や実装がAIで速くなった後もプロジェクトを止め続ける、人と人の「同期」の構造を扱います。
→ AI時代のプロジェクトコミュニケーション構造を考える
第3回では、本記事で形成した判断知を、実際の業務上の判断と行動へ接続する設計を扱います。
→ 暗黙知をAI資産に。AI資産を業務成果に。― AIエージェントに「仕事」を与える業務設計