#03：AIに聞く前に、社内に「正しい答え」はありますか？
ナレッジAIがあぶり出した、マニュアルの矛盾と「組織として学ぶ仕組み」
生成AIをフィールドサービスで活用するとしたら、何を期待するでしょうか。
過去の修理事例をすぐ探せる。
若手技術者でもベテランの知見を参照できる。
故障症状を入力すれば、考えられる原因や確認項目を提示してくれる。
人手不足や技能継承が大きな課題になっている今、どれも非常に魅力的です。
実際、企業内に蓄積されたマニュアルや技術資料、過去のサービス記録をAIに読み込ませ、「現場から自然な言葉で質問できるようにしたい」という話は、これからますます増えていくでしょう。
ただ、その前に一つ、考えておいた方がよさそうなことがあります。
AIに正しい答えを求める前に、そもそも社内に「正しい答え」は一つ存在しているでしょうか。
そんなことを考えさせられた海外記事がありました。
Emerjが2026年8月に公開した、医療機器メーカーCytiva社とBruker社のサービス責任者へのインタビューをもとにした記事です。
（なお、この記事はフィールドサービス特化型AI開発ベンダーのAquant社によるスポンサーコンテンツです。AIの効果を第三者的に検証した調査ではありませんので、その点は割り引いて読む必要があると思います）
実際にAIをサービス業務へ適用する過程で何が起きたのか、という経験談には非常に興味深いものがありました。
AIを入れたら、マニュアル同士が食い違っていた
Cytiva社では、AIを既存の企業内文書へ適用したところ、思わぬ問題が見えてきたそうです。
マニュアル、技術ブリテン、過去資料。
それぞれを読むと、一見きちんとした正式文書です。
ところが、作られた時期や作成者が違うため、内容が必ずしも一致していなかった。
AIが複数の資料を横断して参照するようになったことで、これまで見えにくかった矛盾が表面化したといいます。
これは、かなり重要な話だと思います。
人間が資料を探していた時代には、経験豊富な技術者が、
「このマニュアルは古い」
「この製品Revisionなら、こっちの技術ブリテンを見る」
「マニュアルにはこう書いてあるけれど、実際にはこのやり方が正しい」
と、頭の中で補正していたのかもしれません。
つまり、文書そのものが完全に整合していなくても、熟練者の経験が“最後の整合性チェック”を担っていたわけです。
ところがAIは、会社の暗黙の事情までは知りません。
正式に参照させた情報に矛盾があれば、その矛盾も含めて処理しようとします。
そう考えると、AIの問題というより、
AIによって、これまで人の経験で吸収していたナレッジ管理上の問題が可視化された
と見る方が近いのではないでしょうか。
「文書をためる」と「ナレッジを作る」は違う
企業には、たくさんの情報があります。
マニュアル
作業標準書
技術ブリテン
品質情報
過去の作業報告
故障履歴
FAQ
メール
ベテラン技術者のメモ
しかし、情報がたくさん存在することと、それが組織として使えるナレッジになっていることは同じではありません。
今回の記事でBruker社のRyan Makely氏が指摘しているのも、まさにこの問題です。
実際の現場で得られた知見は、担当者の頭の中や個人のメモ、あるいはCRMの記録など、さまざまな場所に散らばりがちです。そのため、別の地域や別の担当者が同じような問題に直面しても、過去の経験を再利用できないことがあります。
これはフィールドサービスでは珍しい話ではありません。
作業報告書は大量に保存されている。
でも、似た故障を検索できない。
ベテランは知っている。
でも、その人が休みだと分からない。
過去に同じ問題があった。
でも、どの案件だったか見つからない。
これでは、「記録」はあっても「組織知」にはなっていません。
第2作で書いた「標準化」の意味
拙著第2作『なぜ、現場は忙しいのに生産性が上がらないのか？』第6章では、
標準化とは、現場を縛るためではなく、現場が判断しやすくなる状態を作ること
だと書きました。
そのためには、判断基準をそろえるだけでなく、判断材料、相談先、エスカレーションルート、ケースレビュー、そしてナレッジ更新まで含めた仕組みが必要です。
例えば、現場で新しい故障パターンが見つかったとします。
その技術者が自分だけの経験として持って帰れば、個人の知識のままです。
作業報告に書いただけでも、まだ十分ではありません。
その内容を誰かが確認し、
「これは今後も使える知見なのか」
「既存のマニュアルと矛盾していないか」
「正式な判断基準を変える必要があるのか」
を判断する。
必要であれば標準やナレッジを更新し、その変更を現場へ戻す。
ここまでつながって初めて、現場で得た経験が組織の能力になります。
拙著第2作でも、標準化と現場裁量を両立させるには、短いケースレビューやナレッジ更新を通じて、現場の判断を組織の学びに変える必要があると整理しました。
今回のCytiva社の事例は、この考え方とかなり重なります。
AI導入プロジェクトだと思ったら、実はナレッジ・ガバナンス改革だった
ここが、今回の記事で最も考えたいところです。
ナレッジ検索AIのプロジェクトを始める時、議論はどうしても、
「何件の文書を読み込ませるか」
「回答精度は何％か」
「どのLLMを使うか」
「検索速度はどうか」
といったテクノロジーの話に向かいがちです。
もちろん、それらも重要です。
でも実運用では、その前後にもっと地味な仕事があります。
AIが間違った回答をした時、誰がそれを判断するのか。
二つの正式文書が矛盾していたら、どちらを正解にするのか。
現場が新しい知見を見つけたら、誰がレビューするのか。
承認された変更を、いつAIが参照するナレッジへ反映するのか。
古い情報は、誰が廃止するのか。
ここが決まっていなければ、AIを導入しても、時間とともに回答品質が落ちていく可能性があります。
拙著第2作の巻末付録の”フィールドサービス生産性向上チェックリスト”でも、「ナレッジ管理は情報を貯めることではなく、現場が必要な時に使える状態を作る活動になっているか」と問いかけています。AIについても、熟練者を置き換えるのではなく、判断材料へのアクセスを助けるものとして使うことを重視しています。
言い換えれば、
AIを賢くするだけでは足りない。AIが参照する“組織の正解”を育て続ける仕組みが必要
ということです。
「便利なAIを渡せば使う」でもなかった
Cytiva社の事例でもう一つ興味深いのは、導入後の現場定着です。
当初は、便利なAIツールを提供すれば技術者は自然に使ってくれる、と考えていたそうです。
ところが、実際にはそうならなかった。
技術者はすでに忙しく、日々多くの情報や手順に対応しています。新しいツールが一つ増えたからといって、それだけで仕事のやり方を変えるわけではありません。
そこで、現場技術者を早い段階から開発やテストへ参加させ、実際のトラブルシューティングで使う質問を試してもらう。
AIの回答がどの情報源に基づいているのかを見せる。
間違った回答を簡単に指摘できるようにする。
その指摘がどう処理され、いつ反映されたのかを現場へ返す。
こうした仕組みが必要だったとされています。
ここでも、問題はAIの機能ではありません。
現場がその答えを信頼できるか。
そして、
現場自身がナレッジを改善する仕組みに参加できるか。
という運用設計の問題です。
出典が見えることは、意外に重要
個人的に、今回の記事で特に重要だと感じたのが「出典の透明性」です。
現場技術者からすれば、
「AIがそう言っています」
だけでは、クリティカルな設備の判断根拠としては弱いでしょう。
どのマニュアルの、どの章を参照したのか。
どの技術ブリテンを根拠にしているのか。
過去のどの事例と類似しているのか。
それが確認できれば、技術者はAIの回答を判断材料の一つとして扱えます。
これは拙著第2作第7章「テクノロジーは、制約を外すために使う」で書いた、
AIは熟練者を置き換えるのではなく、現場が判断材料にたどり着くのを助ける
という位置づけそのものです。
最終判断までAIへ丸投げするのではなく、
AIによって、判断に必要な材料へ速くアクセスできる。
その方が、フィールドサービスでのAI活用としては現実的ではないでしょうか。
ナレッジの質は、訪問前に効いてくる
Bruker社の事例は、もう一つ大事な点を示しています。
ナレッジの品質は、現場に到着してからだけ効くものではありません。
むしろ、訪問前の診断に大きく影響します。
顧客から症状を聞き、過去の類似事例や正しい技術情報を参照しながら、ある程度原因を絞り込めれば、
どの技術者を派遣するか。
どの部品を持っていくか。
どれくらい作業時間がかかるか。
を、より正確に判断できます。
逆に訪問前の診断が不十分なら、現場へ行ってから改めて問診・診断し、真因を調べることになります。
必要な部品がなければ再訪問。
必要なスキルが違えば別の技術者を再派遣。
結果として、設備停止時間もCost-to-Serveも増えていきます。今回のEmerjの記事でも、Bruker社側の経験として、遠隔診断の質が部品準備や再訪問に直結することが説明されています。
拙著第2作第5章では、現場が一回で問題を解決できる条件として、
Right TechnicianRight PartsRight Information
を、
Right Timing
でそろえることを挙げました。
正しいナレッジは、そのRight Informationの一部です。
そしてRight Informationがあるからこそ、Right PartsやRight Technicianも判断しやすくなる。
ナレッジは単なる検索効率化の話ではなく、フィールドサービス全体のFLOWに影響するものです。
日本企業でAIを入れるなら、先に一つ確認したい
日本企業でも、今後「社内マニュアルを生成AIで検索できるようにしたい」というプロジェクトは増えていくでしょう。
その取り組み自体には大きな可能性があります。
ただ、導入前あるいは導入と並行して、一度確認してみてもよいと思います。
最新版はどれなのか。
マニュアルと技術ブリテンで判断が食い違った場合、どちらが優先されるのか。
現場で見つかった新しい知見を、誰が正式なナレッジへ変えるのか。
古くなった情報を、誰が廃止するのか。
AIが出した回答に現場が異議を唱えた時、その声はどこへ行くのか。
ここが曖昧なまま大量の文書をAIへ読み込ませても、
これまで人間が抱えてきた矛盾を、AIがより速く提示するだけ
になるかもしれません。
一方で、AIによってその矛盾が初めて見えるようになったのであれば、それは失敗とも限りません。
むしろ、
自社のナレッジ管理を見直す絶好の機会
とも考えられます。
AIに「正解」を教える仕組みを作る
今回のCytiva社とBruker社の事例から、私が最も興味深いと感じたのは、AIがナレッジ問題を解決したことではありません。
AIを使おうとしたことで、ナレッジをどう作り、維持し、更新するのかという組織側の問題が表面化したこと
です。
AIにマニュアルを読ませる。
それだけなら、技術的にはますます簡単になっていくでしょう。
難しいのは、その後です。
現場の経験をどう拾うか。
誰が正しいかを判断するか。
標準をどう更新するか。
変更をどう現場へ戻すか。
そして、そのサイクルを忙しい現場でも続けられるか。
そこまで設計して初めて、AIは「検索ツール」から、組織のサービス能力を高める仕組みに変わっていくのではないでしょうか。
AIに正しい答えを求める前に、あなたの会社では「正しい答え」を誰が作り、誰が更新していますか？
YMG Advisoryでは、AIやFSMなど個別のテクノロジー導入ありきではなく、現場の判断、ナレッジ、部品、情報がどのようにつながり、顧客課題解決までのFLOWのどこが詰まっているのかを整理するところから、フィールドサービス改革を考えています。
参考
Emerj, Solving for the Medical Device Field Service Knowledge Gap, August 28, 2026.※Aquant社によるスポンサーコンテンツ。Cytiva社およびBruker社のサービス責任者へのインタビューをもとに構成