AIエージェントが誤った回答をした場合、問題の原因はモデルにあるわけではないでしょう。問題は、システム間で整合性を取るよう設計されていないデータにあるのです。
パイロット運用では完璧に見えるかもしれません。それは、パイロット運用が成功するのは、誰かが手作業でデータを精選し、管理可能な範囲に限定しているからに他なりません。
本番環境では、そのような条件は整っていません。
エージェントがサプライヤー、製品、財務、市場のデータを同時に処理しなければならない場合、5つの具体的な失敗要因が浮き彫りになります。
これらはそれぞれ単独ではよく知られた問題です。しかし、これらを総合的に見ると、多くのAIプログラムが好調なスタートを切った後に停滞してしまう理由が説明できます。そこで、エージェント型AIをスケールさせるために、それぞれの問題点とその解決策について簡単に見ていきましょう。
1. 古い、または矛盾したマスターレコード
まず、最も基本的な失敗例から見ていきましょう。エージェントが、すでに古くなっている記録を信頼してしまうというものです。
企業のデータが1か所に集約されていることはめったにありません。ある製品について、さまざまなERP（企業資源計画）インスタンス、PIM（製品情報管理）システム、地域別データベース、サプライヤーポータルなどに、5つのバージョンが存在する可能性があります。それぞれが独自のスケジュールに従い、それぞれのチームによって更新されます。
エージェントは、どのバージョンが最新かを知りません。接続されているシステムにクエリを実行し、その回答を事実として扱います。
そのため、価格設定エージェントは、同じ製品について、同じ日に、ある地域では12％の値上げを推奨し、別の地域では現行価格の維持を推奨してしまうことになるのです。どちらの結果も、それ自体としては間違っているわけではありません。それぞれが、同じレコードの異なる、古いバージョンを反映しているに過ぎないのです。
この差異が明らかになると、どちらの地域もその結果を信用しなくなります。
2. ドメイン間の定義の不一致
組織内の誰に尋ねるかによって、「レコード」の意味が異なってくることがある。
調達、財務、営業の各チームは、同じ対象をそれぞれ独自の方法で定義していることがよくあります。製品ライフサイクル管理システムにおける「製品」は、価格設定における「製品」と一致しない場合があり、あるシステムでのサプライヤー分類が、別のシステムでのリスク評価と矛盾することもあります。
複数のドメインにまたがって推論を行うエージェントには、これを独自に解決する方法がありません。エージェントは単に一つの定義を選び、それに基づいて行動するだけです。
ドメイン間で定義が共有されていなければ、エージェントは信頼できる知見を生み出すことはできません。エージェントが生み出せるのは、たまたまあるシステムの見解と一致する推測に過ぎないのです。
3. 追跡可能な系譜の欠如
エージェントの出力が間違っているように見える場合、次に浮かぶ疑問は常に同じである。「なぜその判断に至ったのか？」
決定の経緯がなければ、その問いには答えがありません。誰もその推奨事項を次のように遡って追跡することはできません：
- ソースレコード
- それらの間の関係性
- その過程で適用された業務ルール
その決定には出所が不明であるため、再現や正当化が不可能となります。
これはデータチームをはるかに超えた影響を及ぼします。EUのAI法では、高リスクのAIシステムに対し、解釈可能、文書化可能、かつ追跡可能な出力を生成することが求められています。
規制対象の業界において、来歴情報が欠如していると、説明のつかないエージェントの意思決定のすべてが、コンプライアンス上のリスク要因となってしまいます。
4. 明確なデータ所有権や説明責任の欠如
製品データはあるチームが管理し、サプライヤーデータは別のチームが管理しており、多くの企業では、両者の関係性を管理する担当者が存在しない。
人間がそれぞれの領域内で個々の意思決定を行う分には、この仕組みは問題なく機能します。しかし、エージェントが行動するために領域をまたぐ整合されたデータを必要とする瞬間、この仕組みは機能しなくなります。
各システムの境界で所有権が途切れるため、製品レコードとサプライヤーレコードの間の矛盾を解決する権限を持つ者は誰もいない。
明確な責任体制がなければ、ドメイン横断的なガバナンスは機能しません。
5. エージェントの行動に関する信頼性の閾値やエスカレーション手順がない
意思決定を推奨することと、それに基づいて行動を起こすことは、リスクのレベルが異なります。ほとんどのガバナンス・フレームワークは、前者のケースのみを想定して構築されています。
信頼性の閾値が定義されていないエージェントは、あらゆる決定に対して同程度の自律性を適用することになる。
基礎となるデータがどれほど不確実であっても関係ありません。システムが一時停止し、代わりに人間に決定を委ねるような時点は存在しないのです。
つまり、たった1つの誤った入力がシステム全体のエラーへと発展してしまう。エージェントは、誰にも気づかれる前に、処理するすべてのレコードに対して、機械の速度で同じ過ちを繰り返してしまう。
これら5つのデータ障害を修正し、エージェント型AIを信頼性の高いものにする方法
これらの不具合はいずれも、同じ根本原因に起因しています。データは、高速で動作する機械のためではなく、報告目的のために管理されていたのです。
これを解決するには、以下の手順を実行してください：
- ドメインを横断して責任者を割り当て、製品レコードとサプライヤーレコード間の不一致を解決する権限を持つ担当者を確保してください。チーム間の対立にエスカレートさせないようにしてください。
- ガバナンスルールをデータインフラ自体に組み込み、不良データがエージェントに到達する前に（数週間後のレビューの段階ではなく）検出されるようにします。
- 各ドメインを個別に管理するのではなく、共有されたリレーションシップモデルを通じてドメインを連携させます。サプライヤー、製品、市場のデータを横断して作業する担当者は、一貫性のある全体像を把握できる必要があります。
- データリネージを、コンプライアンスチームが後から断片的に組み立てる必要のあるものではなく、すべてのレコードがデフォルトで持つものとして扱います。
あまりにも多くの企業が、これを一度にではなく段階的に進めています。例えば、所有権から始め、次にガバナンスを行い、その後でドメインを連携させます。データリネージは、他の部分を適切に処理した結果として副次的に得られるものです。
当社の信頼性の高いインテリジェンスプラットフォーム「STEP」は、これらすべてを1つの連携したシステムで処理します。
Stibo Systemsがこれらの課題を一度に解決する方法
STEPは、ガバナンスが施されたマルチドメインのマスターデータ基盤を、5つの独立した問題としてではなく、1つの統合されたシステムとして扱うことで、これらの課題に対処します。
所有権の問題は、共有メタデータモデルによって解決されます。製品、サプライヤー、顧客、および拠点のデータは、単一のガバナンスフレームワークを備えた単一のプラットフォーム上に集約されるため、どのドメインも誰の管理下にも置かれないという事態は発生しません。
ガバナンスルールはデータそのものに組み込まれます。ロールベースのアクセス制御と監査ログは、変更を行ったのが人間の管理者であれエージェントであれ、すべてのレコードに適用されます。
エージェントの権限範囲は、プラットフォームの「グラウンデッド・エージェント層」を通じて定義されます。この層は、エージェントが自律的に行動する前に遵守すべき信頼性の閾値やエスカレーションルールを設定します。
そして、データリネージが標準となります。人間によるものであれ機械によるものであれ、あらゆる決定にはバージョンが管理され、その決定を生み出したレコード、関係性、ルールまで遡って追跡可能です。
まとめると
不具合を修正すれば、エージェントは推測に頼ることをやめる。エージェントは、明確な所有者、追跡可能な意思決定経路、そして人間の確認なしに実行できる範囲が定義された、単一の管理された記録に基づいて動作する。それが、エージェントが行動を起こす段階における「信頼できる知能」の姿である。
なぜこうしたデータの不具合が企業のAIプログラムでこれほど頻繁に発生するのか、その詳細については、アクセンチュアと共同で作成したホワイトペーパー『AI at Scale』をダウンロードしてご覧ください。このホワイトペーパーでは、パイロットプロジェクトと大規模に稼働するAIを分けるデータ環境について詳しく解説しています。
よくある質問
なぜ私のAIは同じ製品や顧客について一貫性のない回答をしているのですか？
エージェントはそのレコードの複数のバージョンから情報を取得している可能性があります。
ERP、PIM、または地域データベースのような異なるシステムは、同じ製品や顧客に対して異なる値を保持していることがよくあり、エージェントにはどれが最新のものであるかを知るための組み込みの方法がありません。 それは単に、たまたま問い合わせたソースから回答するだけです。
基礎となるモデルが良好であっても、なぜAIエージェントは間違いを犯すのでしょうか？
有能なモデルでも、次のような不適切な入力に対してはまだ対応できます：
- 古い記録
- ドメイン間での定義の不一致
- 系譜が欠落している
- 所有権が不明確
これらはすべて、一見するとモデルの失敗のように見えるエラーを引き起こします。 ほとんどの場合、根本的な原因はエージェントに与えられたデータにあり、モデルがそれをどのように推論したかにはありません。
再訓練やモデルの交換では、データ基盤自体の上流で発生した問題はほとんど解決しません。
エージェントAIはデータリスクの観点から、AIの推奨とどのように異なりますか？
推薦は何かが起こる前に人間のチェックを受けます。 エージェントはそのステップをスキップするので、悪い入力がすぐに悪い行動に変わり、それが誰かに気づかれる前に同様の記録全てに繰り返される可能性があります。
大部分のAIが大規模言語モデルで動作するようになった今、マスターデータ管理はまだ重要ですか？
より関連性が高く、少なくはない。 大規模言語モデル（LLM）は言語をうまく処理しますが、それでも管理されたマスターデータに依存して、次のことを知る必要があります：
- どのサプライヤーレコードが最新か
- 製品をどのように分類すべきか
- どの顧客記録が市場全体で権威あるものか
その基盤がなければ、LLMは間違った事実に基づいた流暢な回答を生成します。
グラウンデッド・エージェンティック・レイヤーとは何ですか？
それは、エージェントが自分で決定できることと、いつ人に決定を委ねる必要があるかを定義するプラットフォームのアーキテクチャの一部です。
それはデータインフラストラクチャに直接信頼度の閾値とエスカレーションルールを設定するため、不確実または低品質のデータで作業しているエージェントは推測に基づいて行動するのではなく、人間にルーティングされます。
これらのデータの失敗を修正することは、AIのロードマップを遅らせますか？
必ずしもそうではありません。 所有権、ガバナンス、系譜の作業は、他のすべてを遅らせる別のフェーズとしてではなく、AI開発と並行して行うことができます。
このステップを飛ばすチームは、後で生産中に目に見えるミスを犯したエージェントの信頼を再構築するのにより多くの時間を失う傾向があります。 早期に基盤を修正することが通常はより早い道です。
