製造現場の「根拠付き業務AI」を、Chinobaの応用として形にしてみました

🎥 YouTubeでも公開しています

製造現場の根拠付き業務AI｜保全・品質管理・Decision Trace デモ

Books: Knowledge Flow実践ガイド: 企業知識をAIが利用できる知識基盤へ変換する

製造現場でAIを使うと聞くと、「異常を予知する」「品質を自動判定する」「手順を自動化する」といったイメージが先に立つことが多い。

もちろん、それらは重要である。一方で、実際の現場でより頻繁に発生するのは、もっと日常的で、しかし判断を誤ると影響の大きい問いではないだろうか。

「この異音は、まず何を確認すればよいか」
「油温が上がっているが、運転を続けてよいか」
「校正期限が切れた検査機で測った結果は使えるか」
「指定部品がない。別メーカー品で代用してよいか」

答えの一部は、保全手順書、設備仕様書、社内基準、不具合報告書などに散らばっている。しかし、現場が本当に必要としているのは、文書検索の結果だけではない。このケースにどの文書が関係し、どの条件や例外を確認し、AIがどこまで答えてよく、誰に引き継ぐべきかまでを、一つの流れとして扱うことである。

そこで今回、Chinobaで考えてきた「根拠と判断をつなぐ」考え方を、一般的な製造現場の保全・品質・技術問い合わせに当てはめたデモを制作した。

動画では、すべて架空の文書・設備・数値を用いている。目的は、特定の工場の運用を再現することではなく、AIを現場の判断支援に組み込むための設計原則を、見える形にすることである。

AIは答える前に、判断できる範囲を確認する

このデモでは、現場から問い合わせを受けると、AIは次の流れで動く。

1. 関連する手順書、仕様書、社内基準、過去記録を探す
2. 対象設備、適用条件、例外、基準値を整理する
3. AIが回答してよい範囲を判定する
4. 根拠付きで回答する、または担当者・承認者へ引き継ぐ
5. 経緯と結果をDecision Traceとして記録し、知識を改善する

重要なのは、AIが常に「最ももっともらしい回答」を返すことを目標にしていない点である。AIには、答えるべき問いと、答えを確定してはならない問いがある。

たとえば、手順書に記載された一般的な点検方法であれば、AIは文書のページや項を根拠として示しながら案内できる。一方で、基準値を超えた状態での運転継続、出荷可否、不良品の処置、校正期限切れの計測器の扱い、指定外部品の使用などは、現場の責任者や専門担当者が判断すべき領域である。

ここでは、AIの対応範囲を四段階に分けている。

この境界を先に設計することで、AIを「自動判断機械」として扱うのではなく、現場の判断を安全に前進させるための役割として位置づけられる。

根拠は、引用ではなく判断の材料になる

生成AIと文書検索を組み合わせる取り組みでは、「出典を表示する」ことが一つの到達点になりがちである。しかし製造の問い合わせでは、単に関連文書を列挙するだけでは足りない。

例えば「射出成形機の油温が65℃まで上がっている。運転を続けてよいか」という問いに対して、AIが必要とするのは、温度の上限値だけではない。対象設備は何か、上限を超えた時間はどれくらいか、冷却水の流量や冷却器の状態はどうか、社内基準に承認要件はあるか、といった条件と例外も必要になる。

デモでは、仕様書の上限値、手順書の点検方法、社内基準の承認要件を結び付ける。そして、AIは「運転を続けてよい」と結論を出すのではなく、根拠と確認項目を示し、保全課長への承認依頼につなげる。

この違いは小さく見えて、実務上は大きい。根拠を回答の後ろに添えるのではなく、根拠・条件・例外が、回答または引継ぎの形を決めるようにするからである。

Decision Traceで、判断を組織の資産にする

もう一つの中心は、Decision Traceである。

AIが参照した文書、確認した条件、AIが確定していない事項、対応レベル、引継ぎ先、承認者、人が実施した結果までを、一つの判断の履歴として残す。

これにより、後から次のような問いに答えられるようになる。

• なぜAIは回答ではなく引継ぎを選んだのか
• どの版の文書を根拠にしたのか
• 誰が、いつ、何を確認し、どのように承認したのか
• 実施後の結果はどうだったのか
• 同じような事象に、次回どの知見を使えるのか

多くの現場では、判断の結果だけが記録され、途中の根拠や迷い、確認した条件は残りにくい。けれども、改善に使えるのは結果だけではない。どの時点で人に引き継いだか、どの情報が不足していたか、どの文書が古かったかもまた、組織にとって重要な知識である。

Chinobaで扱いたいのは、このような「情報」から「判断」、そして「次の知識」への循環である。

Human-in-the-Loopは、承認ボタンを置くことではない

AI活用においてHuman-in-the-Loopという言葉はよく使われる。しかし、最後に人が承認ボタンを押すだけでは、十分な設計とは言えない。

人がどのタイミングで関与するのか。人は何を確認すべきなのか。AIは何を根拠として提示するのか。誰が最終的な責任を持つのか。そして、その結果をどのように次の判断へ戻すのか。

これらが設計されて初めて、人とAIの役割分担が機能する。

今回のデモでは、AIが高リスクの判断を確定しないことを、画面上の注意書きだけで済ませていない。基準値超過、運転継続・停止・再稼働、品質合否、校正期限切れ、部品代用、安全に関わる語などを検知した際には、回答をL3に固定し、承認・専門担当へ引き継ぐ。根拠が足りなければL0として答えない。承認と実施結果は、人だけが記録できる。

ガードレールは、AIに「注意して」と指示することではない。AIがどの状態では何をしてはならないかを、業務の流れと記録の構造に組み込むことだと考えている。

製造業から始める、判断のインフラ

このデモは、設備保全や品質管理のためだけのものではない。同じ構造は、調達、見積査定、研究開発、顧客対応、金融、医療、公共領域など、根拠・条件・例外・承認が必要な多くの業務に応用できる。

AIの価値は、予測や回答を高速化することだけではない。人と組織が、何を根拠に、どこで判断し、どう結果を学びに変えるかを支えることにもある。

Chinobaは、AIを単なる検索窓やチャットボットとして置くのではなく、判断のプロセスそのものを扱うための基盤として考えている。今回の製造現場デモは、その応用の一例である。

現場にある手順書、仕様書、過去事例、そして人の判断を切り離さずにつなぐ。AIが答えられる範囲を明確にし、答えるべきでない場面では確実に人へ渡す。判断の経緯を残し、結果を次の知識に戻す。

そうした循環を実装することが、現場で信頼されるAIへの一歩になると考えている。

※ 本デモに登場する文書、設備、数値、人物、組織、事例はすべて架空です。実際の設備運転、安全、品質、出荷等の判断に使用するものではありません。

Chinoba

Chinoba

Intelligence as Relationship

Research Platform

founded by

Masao Watanabe

AI Systems Architecture
Decision Trace
Human–AI Coordination
Algorithmic Governance