本記事は「判断エンジニアリング」シリーズ（全3回）の第3回です。
判断エンジニアリングとは、判断そのものをAIに置き換えるのではなく、人とAIが質の高い判断を速く行い、その判断が再利用される条件を設計することです。
はじめに
これまで、AI時代の知識とコミュニケーションについて、二つの記事を書きました。
一つ目の記事では、会議やインタビューを文字起こししただけでは、暗黙知は残らないと書きました。
人の頭の中にある暗黙知そのものを、AIが直接取り出せるわけではありません。
AIが扱えるのは、発言、行動、修正、選択、例外対応などに現れた暗黙知の痕跡です。
そこから、状況、兆候、解釈、根拠、適用条件、対象外条件、例外、反例などの「判断文脈」を整理し、専門家によるレビューを経て、初めて他者やAIが再利用できる知識になります。
一つ目の記事では、こうした知識を発見し、整理し、レビューし、利用し、更新していく活動を「暗黙知AIマネジメント」と呼びました。
本稿では、その中でも特に、
作られた知識を、どのように利用し、業務成果へ変えるのか
を掘り下げます。
二つ目の記事では、AIによって個々の作業が速くなっても、プロジェクト全体が同じ倍率では速くならないと書きました。
必要な情報が存在するだけでは、仕事は前へ進みません。
必要なタイミングで情報が浮上し、関係者が意味を理解し、判断し、次の行動を始められる状態にする必要があります。
AIが使う知識についても、同じことが言えます。
暗黙知の痕跡を構造化する。
専門家がレビューする。
人がRAGやAI検索で利用できるようにする。
AIエージェントも、その知識を参照できるようにする。
さらに、専門家のデジタルツインのようなAIエージェントを作る。
ここまで実現できれば、業務成果は生まれるのでしょうか。
残念ながら、それだけでは十分ではありません。
AIエージェントが知識を参照できることと、組織の中で実際に働いていることは別だからです。
本稿で伝えたいことは、一つです。
暗黙知をAI資産に変えることと、AI資産を業務成果に変えることは、別の設計問題である。
暗黙知
↓ 抽出・構造化・レビュー
AI資産
↓ 業務への組み込み
業務成果
1. 暗黙知をAI資産に変える
暗黙知をAI資産に変えることは、非常に重要です。
熟練者は、常に自分の判断理由を言葉にしているわけではありません。
問い合わせを見た瞬間に、「これは通常の案件ではない」と気づく。
プロジェクトの報告を聞いて、「このままでは来月問題になる」と感じる。
設計内容の一部分を見て、「ここは将来の障害につながる」と判断する。
そこには、過去の経験から身につけた、兆候の捉え方、判断基準、適用条件、例外の見分け方があります。
しかし、それらが本人の頭の中にしかなければ、他の担当者やAIエージェントは利用できません。
そこで、発言、行動、修正、過去の事例、例外対応などに現れた痕跡から、判断の背景を整理します。
本稿でいう「AI資産」
「AI資産」は、さまざまな意味で使われ得る言葉です。
本稿では、考えを整理するため、次のように限定して使います。
人やAIエージェントが業務上の回答、判断、行動に再利用できるように、判断の背景、適用条件、例外、過去の事例と結果、手順や行動方法などが構造化され、必要なレビューを経た知識。
会議音声、文字起こし、議事録、チャット、チケット履歴などは、AI資産そのものというより、暗黙知の痕跡を含む原材料です。
原材料を集めただけでは、現在の業務に適用できる知識にはなりません。
専門家の経験
↓
発言・行動・修正・事例に現れた痕跡
↓
AIによる知識候補の生成
↓
判断の背景・条件・事例・手順として構造化
↓
専門家によるレビュー
↓
人やAIエージェントが再利用できるAI資産
このAI資産を使えば、組織に蓄積された経験や判断基準を利用して、さまざまな業務を支援するAIエージェントを作れます。
たとえば、次のようなものです。
- 業務上のリスクや見落としを検出するAIエージェント
- プロジェクトの進捗や課題を確認するAIエージェント
- 設計内容を専門的な観点からレビューするAIエージェント
- 問い合わせの初期判断を支援するAIエージェント
- 障害対応時の確認やエスカレーションを支援するAIエージェント
これは、専門家の知識や判断を再現・支援するデジタルツインに近づくための、重要な土台です。
ただし、ここまでで実現したのは、
知識や能力を持ったAIエージェントを用意したこと
です。
まだ、そのAIエージェントが組織の中で働いているとは限りません。
2. AIエージェントを作ることと、AIエージェントが働く業務を作ることは別
非常に優秀な人を採用したとします。
しかし、その人に、
- 担当業務を与えない
- いつ仕事を始めるか伝えない
- どの会議に参加するか決めない
- 誰に報告するか決めない
- 必要な情報を渡さない
- 判断や実行の権限を与えない
- 他の担当者との役割分担を決めない
という状態であれば、その人は能力を発揮できません。
AIエージェントも同じです。
大量の知識を参照でき、質問すれば優れた回答を返すとしても、次のことが決まっていなければ、実際の業務では働けません。
- どの業務を担当するのか
- 何をきっかけに動くのか
- 何を確認するのか
- どの情報と知識を使うのか
- 誰に何を伝えるのか
- どの行動を促すのか
- どの会議やレビューで利用するのか
- どこまで自動実行してよいのか
- 実行結果をどこへ記録するのか
- 誰が最終責任を持つのか
AIエージェントへのチャット画面を用意し、
何かあれば、このAIに質問してください
と案内するだけでは、利用は現場の自発性に委ねられます。
経験の浅い人ほど、自分が何を知らないのか分かりません。
問題が起きていることに気づいていない人は、AIエージェントへ質問しません。
忙しい担当者は、新しい画面をわざわざ開きません。
その結果、AIエージェントは優れた知識を参照できるにもかかわらず、ほとんど呼ばれない状態になります。
知識へのアクセス権を与えるだけでは、
- どの場面でその知識を使うのか
- 現在の案件に適用してよいのか
- 情報が不足している場合に誰へ質問するのか
- 提案だけに留めるのか
- 人の承認を求めるのか
- そのまま処理を実行するのか
までは決まりません。
この違いを、端的に表すと次のようになります。
AI資産化
＝ AIエージェントが「何を知っているか」を設計する
業務設計
＝ AIエージェントが「いつ、何をするか」を設計する
暗黙知のAI資産化は、AIエージェントに知性を与えます。
業務設計は、AIエージェントに仕事を与えます。
この二つは連続していますが、同じものではありません。
3. プロジェクト管理を支援するAIエージェントを例に考える
たとえば、プロジェクト管理を支援するAIエージェントを作るとします。
このAIエージェントは、次のような情報を参照できます。
- プロジェクト計画
- プロジェクト管理ツールやチケット
- 定例会議の議事録
- 過去のリスクと対応履歴
- 関係者との合意事項
- 経験者の判断基準
- 過去に発生した失敗事例
質問すれば答える状態
チャットで質問すると、適切な回答を返します。
このプロジェクトで注意すべきリスクは何ですか。
期限超過の可能性があるタスクを教えてください。
関係者へ確認すべき事項はありますか。
これだけでも便利です。
しかし、誰も質問しなければ、業務は変わりません。
AIエージェントに「仕事」を与えた状態
では、次のように実際の業務へ組み込んだらどうでしょうか。
1. 定例会議の前に情報を確認する
AIエージェントが、プロジェクト管理ツール、議事録、リスク管理表などを自動的に確認します。
2. 問題候補を見つける
たとえば、次のような状態を検出します。
- 期限を過ぎているが、状況が更新されていないタスク
- 担当者が決まっていない課題
- 会議では決まったものの、担当者や期限が設定されず、タスクとして記録されていないアクション
- 関係者への確認が必要なまま放置されている事項
- 過去の失敗事例と似た兆候
- プロジェクト管理の観点から確認すべき不足情報
3. 担当者へ自動的に確認する
AIエージェントが、チャットツールなどを通じて担当者へ質問します。
このタスクは期限を過ぎていますが、現在の状況を教えてください。
前回の会議で決まった対応に、担当者と期限が設定されていません。タスクとして登録しますか。
この事項は関係者への確認が必要と考えられます。次回の定例会議までに確認しますか。
4. 定例会議の議題へ載せる
未解決のリスクや、担当者から回答がなかった項目を、定例会議のアジェンダへ追加します。
会議では、AIエージェントが出した問題候補を確認します。
5. 決まった行動を記録する
人が承認した内容を、担当者と期限を持つタスクとして登録します。
6. 実施状況を追跡する
期限までに対応されていなければ、AIエージェントが再度確認します。
7. 人の修正から学ぶ
AIエージェントの指摘が誤っていた場合は、人が理由を記録します。
AIエージェントが見落としていた問題があれば、それも新しい知識候補として残します。
プロジェクト情報を確認する
↓
問題候補を見つける
↓
担当者へ確認する
↓
定例会議の議題へ載せる
↓
対応をタスクとして記録する
↓
期限まで追跡する
↓
結果と人の修正から学ぶ
ここまで組み込まれて、初めてAIエージェントはプロジェクトの中で「働いている」と言えます。
価値を生んでいるのは、AIエージェントが知識を参照できることだけではありません。
その知識を、
- いつ使うか
- 誰へ働きかけるか
- どの会議で確認するか
- どの行動へつなげるか
- どこまで追跡するか
が設計されているからです。
4. AIエージェントを実際の業務に組み込む二つの方法
AIエージェントに「仕事」を与えるには、単に知識を参照できるようにするだけでは足りません。
AIエージェントを、実際の業務の流れへ組み込む必要があります。
その方法は、大きく二つに分けられます。
一つは、業務上の出来事を捉えて動けるようにする、システムへの組み込みです。
もう一つは、会議、レビュー、承認などで継続的に利用されるようにする、業務運用への組み込みです。
システムへの組み込み
一つ目は、AIエージェントを業務システムやデータへ接続し、業務上の出来事をきっかけに動けるようにすることです。
たとえば、次のようなものです。
- 問い合わせが登録されたら、自動的に内容を確認する
- 障害の兆候を検知したら、担当者へ通知する
- タスクやチケットの更新漏れを検知する
- チャットツールで不足情報を質問する
- 承認後にタスクやチケットを作成・更新する
- 期限までに対応されなければ再度確認する
- 実行結果をログとして残す
これは、利用者が自分からAIエージェントへ質問するのを待つのではなく、AIエージェントが業務上の出来事を捉え、必要な人へ働きかけるための組み込みです。
ただし、自動的に通知や質問を行えば、必ず利用されるわけではありません。
重要でない通知を大量に送れば、担当者はAIエージェントからの連絡を無視するようになります。
そのため、次のような点も設計する必要があります。
- どのような出来事をきっかけに動くか
- どの条件を満たした場合に通知するか
- 誰へ通知するか
- どの情報を伝えるか
- いつまでに反応を求めるか
- 未対応の場合に再度確認するか
- どの条件で責任者へエスカレーションするか
- 通知だけで終えるか、質問やタスク登録まで行うか
大切なのは、通知の数を増やすことではありません。
人の判断や行動が必要になる場面を捉え、次に何をすべきかが分かる形で働きかけることです。
業務運用への組み込み
もう一つは、AIエージェントの利用を、会議、レビュー、承認、報告などの業務運用へ組み込むことです。
たとえば、次のようなものです。
- 定例会議で、AIが検出したリスクを確認する
- 設計レビューのチェックリストに、AIの指摘確認を加える
- 承認前に、関連する判断基準を確認する
- AIの提案を採用したか、採用しなかったかを記録する
- 採用しなかった場合は、その理由を残す
- 定期的に、AIの誤りや見逃しを振り返る
- 新しく見つかった知識候補を専門家がレビューする
AIエージェントを業務システムへ接続しても、誰も提案を確認しなければ、業務成果にはつながりません。
反対に、システム連携が十分でなくても、定例会議でAIの分析結果を確認する運用から始めることはできます。
システムへの組み込みと、業務運用への組み込みは、どちらか一方でよいわけではありません。
AIエージェントをシステムへ接続するだけではなく、組織の日々の仕事の進め方へ組み込む。
この二つがそろうことで、AIエージェントは、単に質問へ回答するだけの存在ではなく、組織の中で継続的に仕事をする存在になります。
5. 導入初期は、利用機会を意図的に作る
新しいAIエージェントを公開し、
便利なので、必要に応じて使ってください
と案内するだけでは、なかなか利用されません。
利用されなければ、AIエージェントが本当に役立つのか分かりません。
誤りや不足も見つかりません。
現場からのフィードバックが集まらないため、改善も進みません。
利用されない
↓
フィードバックが集まらない
↓
改善されない
↓
価値を感じられない
↓
さらに利用されない
この循環を避けるには、導入初期に、利用機会を意図的に作る必要があります。
たとえば、一定期間は次のような運用を行います。
- 毎週の定例会議で、AIの分析結果を一度確認する
- 対象となるレビューでは、AIの指摘を確認したか記録する
- AIの提案を採用しなかった場合は、理由を残す
- AIが検出したリスクへの対応状況を、次回の会議で確認する
- 定期的に、誤検知、見逃し、有効だった提案を振り返る
ここで必須にするのは、AIの提案に従うことではありません。
AIの提案を確認し、採用するかどうかを人が判断し、その結果を残すことです。
AIの提案が誤っていれば、採用しないことが正しい判断です。
重要なのは、採用しなかった理由が記録され、知識や業務設計の改善に使われることです。
導入初期に利用機会を作る目的は、利用回数を増やし、見かけ上のKPIを良くすることではありません。
次のことを確かめるためです。
- AIエージェントは本当に役立つか
- どの場面で役立つか
- どの通知や質問が不要か
- どの知識が不足しているか
- どの情報を参照できていないか
- どこまで自動化してよいか
- 人はAIの提案をどのように修正したか
導入初期は、会議やレビューで利用機会を作る。
利用状況が分かってきたら、必要な場面で自動的に動くようにする。
成熟したら、既存の業務画面やワークフローへ溶け込ませる。
| 段階 | AIエージェントの使い方 |
|---|---|
| 導入初期 | 会議やレビューで確認し、利用結果を集める |
| 定着期 | 業務上の出来事に応じて、自動的に通知・質問・依頼を行う |
| 成熟期 | 既存業務へ自然に埋め込み、承認された範囲を実行する |
最終的には、利用者が「AIを使っている」と意識しなくても、必要な場面でAIエージェントが働いている状態を目指します。
6. 「どんな暗黙知を抽出できるか」ではなく、「どの業務成果を変えたいか」から始める
ここまで、暗黙知をAI資産に変える設計と、AIエージェントを業務へ組み込む設計を分けて説明してきました。
ただし、この二つを、別々に進めればよいという意味ではありません。
出発点は、暗黙知でもAIエージェントでもなく、改善したい業務成果です。
暗黙知のAI資産化に取り組むとき、
社内の暗黙知を、できるだけ多く集めよう
と考えがちです。
しかし、暗黙知を大量に抽出しても、それだけでは業務成果になりません。
先に決めるべきなのは、改善したい業務です。
たとえば、次のような目標です。
- 問い合わせの初回割当を正確にする
- 重大障害の兆候を早く発見する
- プロジェクトの記録漏れを減らす
- 確認待ちのまま放置される事項を減らす
- 設計レビューの手戻りを減らす
- 新任担当者の立ち上がりを速くする
そのうえで、次の順番で逆算します。
どの業務成果を改善したいか
↓
どの判断や行動を変える必要があるか
↓
その判断には、どの知識が必要か
↓
必要な知識をAI資産として整備する
↓
AIエージェントに、どの仕事を与えるか
↓
システムと業務運用へどう組み込むか
↓
結果をどう測り、知識と運用を改善するか
たとえば、「プロジェクトの記録漏れを減らす」ことが目標なら、必要なのは単なるプロジェクト管理の知識ではありません。
- どの情報が記録されるべきか
- どのタイミングで記録漏れを確認するか
- 誰へ確認するか
- 定例会議でどう扱うか
- いつまでに記録されなければ再度確認するか
- 記録漏れが減ったかをどう測るか
まで設計する必要があります。
評価も、次のような活動量だけでは不十分です。
- 100時間の音声を文字起こしした
- 1,000件の知識候補を生成した
- 500件を専門家が承認した
- AIエージェントがすべての知識を参照できるようになった
- AIエージェントを10個作った
これらは重要な進捗ですが、業務価値そのものではありません。
見るべきなのは、その先です。
- 必要な場面でAIエージェントが動いたか
- AIエージェントの提案は実際に確認されたか
- 人の判断や行動は変わったか
- 対応時間や手戻りは減ったか
- 見落としは減ったか
- 特定の経験者への依存は下がったか
- 利用結果から知識や運用が改善されたか
AI資産の価値は、保有している知識の件数ではなく、業務への寄与で測る。
暗黙知のAI資産化と、AI資産の業務価値化は、別の設計問題です。
だからこそ、両者を分断せず、業務成果から逆算して一続きで設計する必要があります。
7. この考え方を支える先行研究
本稿の考え方を、そのまま検証した単一の研究があるわけではありません。
一方で、知識マネジメント、意思決定支援、実装科学、生成AIの職場利用という隣接領域には、重要な示唆があります。
知識を作ることと、行動へ移すことは別である
GrahamらのKnowledge-to-Action Frameworkでは、知識を作るプロセスと、その知識を実践へ移すプロセスが分けて整理されています。[1]
知識を作った後にも、
- 現場の文脈へ適応する
- 利用を妨げる要因を確認する
- 実際に利用する
- 利用状況を観察する
- 成果を評価する
- 継続利用につなげる
といった活動が必要です。
これは、AI資産を作ることと、それを業務成果へ変えることを分けて考える、本稿の問題意識と重なります。
支援は、判断する場面の業務フロー内で提供する
Kawamotoらは、医療分野の意思決定支援システムに関する70件のランダム化比較試験をレビューしました。[2]
実務上の改善と関連していた特徴として、次のような点を挙げています。
- 通常の業務フローの中で自動的に提供される
- 判断を行う時点と場所で提供される
- 単なる評価ではなく、具体的な推奨を示す
- コンピューターを通じて提供される
四つの特徴をすべて持つ32システムのうち、30システムで実務上の改善が報告されました。
対象は医療分野であり、この結果を一般企業のAIエージェントへそのまま当てはめることはできません。
それでも、
必要な判断の瞬間に、通常の業務フローの中で、次の行動が分かる形で支援を届ける
という原則は、企業業務におけるAIエージェントの設計にも示唆を与えます。
新しい仕組みは、日常業務へ埋め込まれて初めて定着する
MayらのNormalization Process Theoryは、新しい技術や仕事の進め方が、日常業務の中へ実装され、埋め込まれ、継続的な実践として維持される過程を説明する理論です。[3]
新しい仕組みが日常業務へ定着するためには、単に技術を導入するだけではなく、人々がその仕組みの意味を理解し、参加し、実際に使い、評価し続ける必要があります。
AIエージェントを公開するだけでなく、会議、レビュー、承認などへ組み込む必要があるという本稿の主張とも重なります。
業務の流れに組み込まれた生成AIの事例
Brynjolfssonらは、5,172人のカスタマーサポート担当者を対象に、生成AIによる会話支援ツールの効果を分析しました。[4]
このAIは、担当者が別画面を開いて検索するだけの仕組みではありません。
実際の顧客対応中に会話を確認し、リアルタイムで応答案を提示していました。
担当者は、その提案を採用することも、無視・修正することもできました。
研究では、AI支援へのアクセスによって、1時間当たりの問題解決件数が平均15％増加しました。特に、経験やスキルが相対的に低い担当者で、効果が大きくなりました。
これは一社における事例であり、すべての業務やAIエージェントに同じ効果が出るとは言えません。
ただし、
現在の業務文脈に応じた支援を、実際の仕事の流れの中で、その場で届ける
という設計が、現実の職場で成果を生んだ一例として参考になります。
これらの先行研究に共通するのは、知識やAIを用意するだけではなく、
- 現場の文脈へ適応する
- 実際の業務フローへ組み込む
- 利用機会を作る
- 人の判断と行動へつなげる
- 結果を評価し、改善する
ことが必要だという点です。
まとめ
暗黙知の痕跡を発見する。
判断の背景や条件を構造化する。
専門家がレビューする。
人やAIエージェントが再利用できるAI資産にする。
専門家の判断を支援する、デジタルツインのようなAIエージェントを作る。
これらは、どれも重要です。
しかし、それだけでは業務成果は生まれません。
AIエージェントが組織の中で働くためには、
- どの業務を担当するのか
- 何をきっかけに動くのか
- 何を確認するのか
- どの知識を使うのか
- 誰に働きかけるのか
- どの会議で確認するのか
- どこまで実行するのか
- 結果をどこへ記録するのか
- どのように改善するのか
を設計する必要があります。
そして、AIエージェントを業務システムへ接続するだけでなく、会議、レビュー、承認など、組織の日々の仕事の進め方へ組み込む必要があります。
導入初期には、AIの提案に従うことを強制するのではなく、提案を確認し、採否と理由を残す機会を意図的に作ることも必要です。
暗黙知のAI資産化は、AIエージェントに知性を与える。
業務設計は、AIエージェントに仕事を与える。
利用結果からの改善は、AIエージェントを組織の中で育てる。
暗黙知のAI資産化は、ゴールではありません。
それは、業務成果を生み出すための重要な土台です。
暗黙知をAI資産に。
AI資産を業務成果に。
その二つを分けて考え、業務成果から逆算してつなげることで、AIエージェントは初めて組織の中で働き始めるのだと考えています。
参考文献
-
Ian D. Graham, Jo Logan, Margaret B. Harrison, Sharon E. Straus, Jacqueline Tetroe, Wenda Caswell, Nicole Robinson, “Lost in Knowledge Translation: Time for a Map?”, Journal of Continuing Education in the Health Professions, Vol. 26, No. 1, pp. 13–24, 2006. DOI: 10.1002/chp.47
-
Kensaku Kawamoto, Caitlin A. Houlihan, E. Andrew Balas, David F. Lobach, “Improving Clinical Practice Using Clinical Decision Support Systems: A Systematic Review of Trials to Identify Features Critical to Success”, BMJ, Vol. 330, No. 7494, p. 765, 2005. DOI: 10.1136/bmj.38398.500764.8F
-
Carl R. May, Frances Mair, Tracy Finch, Anne MacFarlane, Christopher Dowrick, Shaun Treweek, Tim Rapley, Luciana Ballini, Bie Nio Ong, Anne Rogers, et al., “Development of a Theory of Implementation and Integration: Normalization Process Theory”, Implementation Science, Vol. 4, Article 29, 2009. DOI: 10.1186/1748-5908-4-29
-
Erik Brynjolfsson, Danielle Li, Lindsey R. Raymond, “Generative AI at Work”, The Quarterly Journal of Economics, Vol. 140, No. 2, pp. 889–942, 2025. DOI: 10.1093/qje/qjae044
シリーズについて
本記事で、「判断エンジニアリング」シリーズ（全3回）はひとまず完結です。
第1回では、暗黙知から「判断文脈」を取り出し、再利用可能な知識へ形成する方法を扱いました。
→ 会議を文字起こししただけでは、暗黙知は残らない ― SECIモデルから考える「判断文脈」のナレッジ化
第2回では、AIで作業が速くなった後にプロジェクトを止める、文脈・判断・責任の「同期」の構造を扱いました。
→ AI時代のプロジェクトコミュニケーション構造を考える
知識を形成し（第1回）、同期を設計し（第2回）、業務へ接続する（第3回）。
この三つがそろって、判断エンジニアリングの全体像になります。