同じAIでも結果が変わる理由 — 「判断の優先順位」という見えない設計

以前、Light DTM(decision Trace Model)を使って
異なる2つの現場にAIを導入したことがありました。

1つは 製造業の現場、
もう1つは ITのカスタマーサポート です。

使っていたAIは、ほぼ同じ構成でした。

・LLMベースの分類モデル（GPT系 / BERT系）による意図・カテゴリの判定
・AutoEncoderなどを用いた異常検知モデルによる逸脱検出
・ルールベース＋統計モデルによるリスクや重要度のスコアリング

これらを組み合わせて、

分類・異常・スコア

といった形で出力を得ていました。

いずれも、

LLMや機械学習モデルによって「Signal」を生成する部分

であり、

使っていたAIは、ドメインが違っても本質的には同じでした。

いわゆる「Signal」を出す部分は、ほぼ共通です。

しかし、実装を進める中で、
あることに気づきました。

同じAIを使っているにもかかわらず、最終的に設計される「判断」がまったく違っていたのです。

製造業では、こうなりました。

if anomaly_score > threshold:
 → stop_machine
 → human_review
判断の中心は「止めるかどうか」

一方、ITサポートでは、こうなりました。

if severity == high:
 → human
else:
 → auto_reply
判断の中心は「人に回すかどうか」

モデルは同じように、

・異常を検知し
・分類し
・スコアを出す

ことができます。

しかしその後に求められるのは、

・止めるのか
・人に回すのか
・そのまま処理するのか

という意思決定です。

同じAIなのに、
まったく異なる判断構造になった。

このとき、はっきり理解しました。

問題はAIではない
問題は「判断」だった

そしてさらに言えば、

何を優先して判断するかが、ドメインごとに違っていたのです。

本質：違っていたのは「判断の優先順位」

この違いをもう少し整理してみると、
さらに重要なことが見えてきます。

まず、製造業の現場では、判断の基準は明確です。

安全 > 品質 > コスト > 効率
最優先されるのは「安全」です。

多少コストが増えても、
効率が落ちても、

安全が最優先される

そのため、

・異常があれば止める
・不確実であれば人に確認する

という判断が選ばれます。

ここでは、

判断を間違えると事故につながる

という前提があるからです。

一方で、IT / カスタマーサポートでは事情が異なります。

SLA > 顧客満足 > コスト
ここで重要なのは、

・対応の速さ（SLA）
・顧客体験

です。

すべてを人に回していては、
対応が遅れ、顧客満足が下がってしまいます。

そのため、

・自動で処理できるものは自動化する
・重要なものだけ人に回す

という判断になります。

ここでは、

判断ミスはクレームや離脱につながる

という構造になっています。

この2つを比べると、明確な違いが見えてきます。

同じAIを使っていても、
「何を優先するか」が業界ドメインによってまったく違う

そして、この「優先順位」こそが、

意思決定（Decision）の本質

でした。

AIは分類や予測を行うことはできますが、
何を優先すべきかまでは決めてくれません。

その部分を設計することこそが、
本来の意味での「意思決定設計」なのです。

ドメイン別「判断の優先順位」

この「判断の優先順位」という視点で整理すると、
各業界における意思決定の違いは非常に明確になります。

重要なのは、単に優先順位が違うだけではなく、

その優先順位が、そのまま意思決定の形を決めている

という点です。

■ 製造業（Manufacturing）

安全 > 品質 > コスト > 効率
製造業では、最も重要なのは「安全」です。

設備の異常や不確実な状態を見逃すことは、
事故や重大な損失につながる可能性があります。

そのため、多少効率が落ちても、
コストが増えても、

まず止めることが優先される

Decision→止めるかどうか

■ リテール / マーケティング

顧客体験 > 売上 > 効率
リテールやマーケティングでは、

顧客との関係性が最も重要です。

短期的な売上よりも、

・顧客満足
・ブランド体験

が優先されます。

そのため、

どのように対応するか（対応の質）が意思決定の中心になる

Decision→どう対応するか

■ IT / カスタマーサポート

SLA > 顧客満足 > コスト
ITサポートでは、

「迅速かつ適切に対応すること」が求められます。

すべてを人が対応していては遅くなり、
すべてを自動化すると品質が落ちます。

そのため、

どこまで自動化し、どこで人に渡すか

というバランスが重要になります。

Decision→人に回すか自動か

■ 医療（Healthcare）

安全（患者） > 倫理 > 正確性 > 効率
医療の現場では、

最も重要なのは患者の安全です。

さらに、

・倫理的な配慮
・責任の所在

も非常に重要になります。

そのため、

AIが判断すべきでない領域を明確にし、人間が介入するポイントを設計する必要がある

Decision→人が介入すべきか

■ 教育（Education）

成長 > 理解 > 効率
教育の目的は、単なる正解の提供ではなく、

学習者の成長と理解です。

そのため、

・効率的に答えを出すこと
よりも
・どのように理解を深めるか

が重要になります。

最適な支援は一つではなく、状況に応じて変わる

Decision→どの支援をするか

■ まとめ

これらをまとめると、以下の様になります

各業界で何を優先して判断するか

が大きく異なっていることがわかります。

そしてその優先順位が、

意思決定（Decision）の形そのものを決めている

のです。

Light DTMがやっていること

Light DTMは、この問題に対して非常にシンプルなアプローチを取ります。

それは、

判断の優先順位を、モデルの外に明示すること

です。

従来のAIシステムでは、
分類・予測・スコアリングといった Signal は生成されても、
その後にどう判断するのかは、現場の暗黙知や個別実装の中に埋もれてしまいがちです。

その結果、

・なぜその判断になったのか分からない
・担当者によって対応が変わる
・改善したくても、どこを直せばよいか分からない

といった問題が起こります。

Light DTMは、そこを複雑にせず、
まず最小構成で外に出します。

例えば、製造業であれば、

if anomaly_score > 0.7:
 → stop_machine
という形になります。

これは単なる条件分岐に見えるかもしれません。
しかし実際には、

「安全を最優先し、異常の兆候があれば止める」

という、その現場の判断原則を明示したものです。

同じように、IT / カスタマーサポートであれば、

if severity == high:
 → human

という形になります。

これも単なるルールではありません。

ここで表現されているのは、

「重大な問い合わせは、自動処理よりも人の対応を優先する」

という、サポート業務における判断の優先順位です。

つまり、Light DTMがやっているのは、
if文を書くことそのものではありません。

そのドメインで何を守り、何を優先して判断するのかを、構造として取り出すこと

です。

このとき重要なのは、
モデル自体を変える必要はないということです。

異常検知モデル、LLM分類モデル、スコアリングモデルはそのまま使える。
その上で、

・どのSignalを使うか
・どの閾値で分けるか
・どこで人に戻すか
・どこで止めるか

を明示するだけで、
意思決定は「暗黙知」から「設計可能なもの」に変わります。

Light DTMは、複雑なフレームワークをいきなり導入するものではありません。

まずは、

判断の優先順位を、最小のルールとして外に出す

そこから始めるアプローチです。

その意味で、これらのルールは単なる実装詳細ではなく、

ドメインの意思決定を明示した最小単位

なのです。

その先にあるもの：フルバージョンのDTMでできること

Light DTMでは、まず

・どのSignalを使うのか
・どの閾値で分けるのか
・どこで人に戻すのか
・どこで止めるのか

を、最小限のルールとして外に出します。

これは、判断の優先順位を明示するための最初の一歩として非常に有効です。

しかし実際の現場では、意思決定はしばしばそれほど単純ではありません。

最初は

if anomaly_score > 0.7:
 → stop_machine
のような単純なルールで始められても、運用を続けるうちに、次のような要求が出てきます。

・異常度だけではなく、設備の状態も見たい
・過去に同様の事象があったかも考慮したい
・生産計画や納期への影響も見たい
・安全、品質、コストのバランスを取りたい
・単純停止ではなく、段階的な対応にしたい

ここから先は、Light DTMだけでは表現しきれない領域です。

そして、そこを扱うのがフルバージョンのDecision Trace Modelです。

フルDTMでは、判断を「単一ルール」ではなく「構造」として扱う

Light DTMでは、判断は主にシンプルな条件分岐として表現されます。

一方でフルDTMでは、意思決定をより豊かな構造として扱います。

例えば、次のようなことが可能になります。

1. 複数のSignalを統合して判断する

現実の意思決定では、1つのスコアだけで決まることはあまりありません。

製造業であれば、

・異常検知スコア
・設備の稼働条件
・過去の故障履歴
・作業員の報告
・品質検査結果

を合わせて見たいことがあります。

ITサポートであれば、

・問い合わせカテゴリ
・緊急度
・感情分析結果
・顧客ランク
・過去の対応履歴

をまとめて判断したくなります。

フルDTMでは、こうした複数のSignalを明示的に組み合わせ、どの情報がどの判断に影響したのかを構造として保持できます。

2. 判断の流れそのものを制御できる

Light DTMでは、判断は1つの分岐に近い形で表現されます。

しかし実際には、判断は一回で終わらないことが多いです。

例えば、

・まず異常度を見る
・高ければ安全条件を確認する
・次に人の承認を通す
・承認が取れなければ待機する
・追加データが来たら再開する

といった流れが必要になります。

フルDTMでは、こうした意思決定の流れをBehavior TreeやDecision Contractとして扱うことができます。

これにより、判断は単なるif文ではなく、

👉 順序
👉 分岐
👉 停止条件
👉 再開条件
👉 人間の介入ポイント

を持つ実行可能なプロセスになります。

3. HumanやBoundaryを明示的なレイヤーとして扱える

Light DTMでも「人に回す」「止める」といったことはできます。
しかしフルDTMでは、それをさらに明確な構造として扱えます。

例えば、

・どの条件で自動判断を止めるのか
・どの権限を持つ人が承認するのか
・どの判断はAIに任せてよいのか
・どの領域は必ず人が責任を持つべきか

を、BoundaryやHumanレイヤーとして明示できます。

これは特に、

・製造業の安全判断
・医療における人間の責任
・金融や公共領域での監査
・企業における承認フロー

のような場面で重要になります。

つまりフルDTMでは、判断の精度だけでなく、

👉 誰が
👉 どこまで
👉 どの条件で
👉 責任を持つのか

まで設計できます。

4. ドメイン知識そのものを判断に組み込める

Light DTMでは、優先順位をルールとして表現します。
しかし、現場の判断はルールだけでは十分でないことがあります。

例えば医療であれば、

・症状の意味
・患者属性
・禁忌
・治療方針

製造業であれば、

・設備の構成関係
・部品の依存関係
・故障モード
・運転条件

といったドメイン知識が重要になります。

フルDTMでは、Ontologyや知識構造を組み込むことで、

「どの言葉が何を意味するか」
「何と何がどう関係しているか」

まで扱えるようになります。

これにより、単なるルールベースではなく、意味を伴った判断設計が可能になります。

5. 複数の観点を持つMulti-Agent化ができる

実務では、1つの観点だけで判断できない場面が多くあります。

例えば製造業では、

・安全の観点
・品質の観点
・コストの観点
・納期の観点

が競合することがあります。

教育なら、

・理解度
・学習意欲
・到達目標
・支援負荷

が同時に関係します。

フルDTMでは、こうした異なる観点をそれぞれAgentとして分担させ、複数のSignalを生成し、それをOrchestratorが統合する形が取れます。

これにより、

👉 単一スコアによる単純判断ではなく
👉 複数視点を明示した上での意思決定

が可能になります。

6. 判断を記録し、再現し、改善できる

Light DTMでもルールは明示されます。
しかしフルDTMでは、その実行過程全体をDecision Traceとして記録できます。

例えば、

・どのEventから始まったのか
・どのSignalが生成されたのか
・どのDecisionが選ばれたのか
・どこでBoundaryに当たったのか
・どこでHumanが介入したのか

を一連の流れとして追跡できます。

これは単なるログではありません。

👉 なぜその判断になったのか
👉 どこで止まったのか
👉 どのルールが適切でなかったのか

を後から振り返り、改善可能にするための基盤です。

つまりフルDTMでは、意思決定は「その場限りの処理」ではなく、

👉 再現可能で
👉 監査可能で
👉 改善可能な資産

になります。

Light DTMとフルDTMの関係

重要なのは、Light DTMとフルDTMが別物ではないということです。

Light DTMは、

判断の優先順位を最小構成で外に出す段階

です。

一方、フルDTMは、

その判断を複雑な現実に耐えられる構造へ拡張したもの

です。

言い換えれば、

  • Light DTM は入口
  • フルDTM は本格運用のための拡張形

です。

最初からOntologyやMulti-AgentやBehavior Treeをすべて入れる必要はありません。
しかし、最初に「判断を外に出す」という設計をしておくことで、後から自然にそこへ拡張できます。

以下にクレーム問い合わせケースでのlightとフルの比較を示しておきます

Conclusion

同じAIを使っても、結果は揃わない。

それは、モデルの精度の問題ではありません。

どのアルゴリズムを使うかでもありません。

違っていたのは、
「何を優先して判断するか」
という設計でした。

AIは、分類し、予測し、スコアを出すことはできます。

しかし、

・止めるのか
・進めるのか
・人に委ねるのか

といった「意思決定」は、

モデルの外に存在しています。

多くの現場では、この部分が暗黙のまま運用されています。

その結果、

・判断が人によって変わる
・なぜそうなったのか説明できない
・改善しようとしても、どこを直せばいいかわからない

という状態が生まれます。

Light DTMがやっているのは、非常にシンプルです。

判断の優先順位を、外に出すこと。

たったそれだけです。

しかしそれだけで、

意思決定は「属人性」から「設計可能なもの」に変わります。

そして、その先にあるのがフルDTMです。

判断は単なるルールではなく、

・構造として設計され
・プロセスとして実行され
・履歴として記録される

ものになります。

そのとき初めて、

意思決定は

その場の判断ではなく、
再現できるものになり、
改善できるものになり、
組織の資産になります。

AIは「答え」を出すことはできます。

しかし、

意思決定をつくることはできません。

意思決定は、設計するものです。

そしてその設計は、

モデルの中ではなく、
私たちの側にあります。

タイトルとURLをコピーしました