AIエージェントが別のエージェントにデータを渡す際、人間が実際にどの程度確認を行うかは、ワークフローの構築方法によって異なります。現在でも多くの企業では、どこかの段階で人間が関与していますが、あるエージェントの出力が別のエージェントの入力となる具体的な時点において、その引き継ぎは通常、リアルタイムで誰も監視していない状態で行われています。
そのため、予兆もなく、そのデータに不整合があれば、誤った判断が下されてしまうことになります。
これはリレー競技のようなものです。世界最高のスプリンターを揃え、コーチがすべてのバトンタッチを監視していたとしても、バトンタッチそのものが設計上適切に管理されていなければ、バトンが地面に落ちるのを防ぐほど迅速に介入できる人は誰もいないのです。
エージェント間のAIワークフローも同様に失敗します。つまり、データがシステム間やドメインを越えて移動する際、それを一貫して統制するガバナンスが欠如している時点で、問題が生じるのです。
そのガバナンスはどこかから提供されなければなりません。つまり、人間がバトンタッチを確認するか、システムが自らをチェックするように構築されているかのどちらかです。バトンタッチのたびに人間の確認に依存するガバナンスはボトルネックとなり、ワークフローの速度を、その中にいる人々の作業速度まで遅らせてしまいます。
このブログ記事では、エージェント間ワークフローがデータ層で機能不全に陥る理由と、それを防ぐためにガバナンスが施されたデータインフラストラクチャがどのようなものであるべきかについて解説します。
なぜエージェント間ワークフローでは、単一エージェントのシステムでは発生しないようなデータ上の問題が生じるのでしょうか？
1つのシステム内で動作する単一のAIエージェントが抱えるデータの問題は、その範囲内に収まります。読み込んだデータに不整合があったとしても、エラーは局所的なものに留まります。人間や下流のプロセスがそれを検知することができます。
マルチエージェントのワークフローでは、その局所性が低下し、完全自律型の構成では、それが完全に解消されます。
各エージェントは、単一の「真実」を共有するよう設計されていないシステムやドメインを横断して、前のエージェントの出力に基づいて動作します。したがって、ステップ1で発生したエラーは、ステップ1にとどまることはありません。
典型的なエージェント型コマースワークフローがどのような領域を横断するかを考えてみましょう：
- 商品データ（説明、属性、分類）
- 倉庫や地域をまたぐ在庫状況
各ドメイン内ではガバナンスが機能しているかもしれません。問題は、あるドメイン向けに構築されたエージェントが、もともとその構造を想定していなかったコンテキストにデータを渡す際の引き継ぎの段階で発生します。
これらのドメインにまたがるガバナンスがなければ、不整合はサプライチェーン全体で気づかれることなく伝播し、やり取りが行われるたびに悪化していきます。
リレー競技において、バトンを落とした場合、そのランナーだけが遅くなるわけではありません。その後に続くすべてのランナーにとって、レースはそこで終わってしまうのです。
エージェントチェーン全体にわたるデータ障害は、どのようなものになるのでしょうか？
商品レコメンデーション・エージェントが在庫管理エージェントに情報を提供し、在庫管理エージェントがサプライヤー・エージェントに情報を提供する、というエージェント型コマース・ワークフローを例に挙げてみましょう。
各エージェントは、設定されたとおりに正確に動作しています。
ここで、1つの不整合を導入してみましょう：
ステップ1の商品データには分類エラーが含まれています。つまり、SKUが誤った商品カテゴリに割り当てられているのです。
その結果、次のようなことが起こります：
- レコメンデーションエージェントがこれに基づいて処理を行います
- 在庫エージェントはその出力を受け取り、それに応じて在庫を割り当てます
- サプライヤーエージェントはその割り当てに基づいて発注を行う
エラーが明らかになる頃には、すでにいくつかの自律的な決定が実行されている。どのエージェントも、自身のロジックにおいてミスを犯したわけではない。各エージェントは、単に受け取ったデータを信頼していたに過ぎない。
マルチエージェントシステムの障害は、単一エージェントシステムの障害とは大きく異なります：
- エラーは遅延し、発生源の地点では表面化しない
- 下流のエージェントが問題を捕捉するのではなく、問題を悪化させるため、引き継ぎが行われるたびに影響範囲が拡大する
- どのエージェントも異常を報告しないため、ワークフローは正常に実行されたように見える
- エージェントの再トレーニングでは問題は解決しません。なぜなら、問題はエージェントの下層にあるデータ層に存在しているからです
これらのエージェントを結びつける管理されたデータ層がなければ、各エージェントがどのデータ状態に基づいて動作したのか、あるいはチェーンのどの段階で問題が発生したのかを特定する仕組みは存在しない。
なぜ、データガバナンスは特にエージェント間の引き継ぎの段階で機能しなくなるのでしょうか？
企業のデータガバナンスの多くは、指示を待つシステムを中心に構築されてきました。
- ユーザーがデータベースにクエリを実行する
- レポートがデータウェアハウスからデータを抽出する
- アプリケーションがレコードを読み取る
データは、確認ができるだけの十分な時間、静止した状態にある。
エージェントは、アクションを実行し、出力を渡して次のステップをトリガーするように設計されるケースが増えています。そして、それは多くの場合、中間チェックポイントなしで、同じワークフローの実行内で発生します。
静的な利用を想定して設計されたガバナンスは、データがシステム間で自律的に移動し始めると機能しなくなります。
エージェントは、ガバナンスの対象外となっているソースシステムからデータを取得します
多くの企業では複数のソースシステムが存在し、それぞれ独自のデータ標準、定義、更新サイクルを持っています。あるシステムでガバナンスが適用された製品レコードであっても、別のエージェントが別の場所でそれを利用する場合、そのガバナンスは引き継がれません。
ドメインをまたぐと、共有コンテキストが失われる
あるドメイン内では正確なデータであっても、別のドメインのエージェントが共有された定義なしにそれを解釈すると、整合性が失われます。製品レコードにおける「アクティブ」の意味は、サプライヤー関係におけるその意味とは異なります。
引き継ぎポイントには監査証跡が存在しない
問題が発生した場合、各担当者が意思決定を行った時点で、どのようなデータ状態に基づいて行動したかという記録が残っていないことがよくあります。
その可視性がなければ、複数のエージェントが連なるチェーンを通じて障害の原因を遡って特定することはほぼ不可能です。結果自体は確認できても、どの引き継ぎが原因だったのか、あるいはその境界を越えた時点でデータがどのような状態だったのかは分かりません。
エージェント間AIをサポートするために、データ層には何が必要でしょうか？
答えは「より多くのデータ」ではありません。ほとんどの企業はすでに十分なデータを持っています。問題は、エージェント間で引き継ぎが行われるポイントにおいて、データが管理されていないことです。必要なのは、以下の4つの要素です。
1. ドメインを横断する単一の管理されたレコード
チェーンを構成するすべてのエージェントは、同じガバナンスが適用されたレコードを利用する必要があります。製品、サプライヤー、顧客、パートナー、および拠点に関するデータは、相互に関連付けられ、一貫性が保たれている必要があります。これらは、たまたまインフラを共有しているだけの別々のサイロとして管理することはできません。
2. データと共に移動するガバナンス
取り込み時に適用され、最初の引き継ぎで放棄されてしまうガバナンスは、エージェントのためのガバナンスとは言えません。データレコードに付随するルール、定義、および標準は、そのレコードがエージェント間やドメイン間を移動する際にも、それに追随する必要があります。
3. すべての段階における監査可能性
エージェントチェーンが予期せぬ結果を生み出した場合、各エージェントがいつ、どのデータ状態に基づいて処理を行ったかを正確に特定する必要があります。それができなければ、監査証跡はワークフローのログで途絶えてしまい、障害が発生したデータ層まで追跡できなくなります。
また、監査可能性は、事前のガバナンス設計の在り方にも影響を与えます。すべてのデータ状態を事後的に追跡可能にする必要がある場合、それを支える構造を最初から組み込んでおく必要があります。
4. チェーン向けに構築された構造
従来のデータガバナンスは、要求に応じてデータを消費する個々のアプリケーションを中心に設計されていました。
マルチエージェント・ワークフローでは、ドメインの境界を越えて順次かつ自律的にデータが消費されることをサポートするように設計されたレイヤーが必要となります。この場合、ガバナンス・レイヤーが先にそれを捕捉しない限り：
- 引き継ぎのたびに人間によるレビューが行われるとは限らない（自律的な構成では、そもそも存在しない）
- ガバナンス層が最初にそれを捕捉しない限り、不整合を検知するシステムは存在しない
Stibo Systemsは、エージェント間ワークフローの信頼性をどのように確保しているのでしょうか？
Stibo Systemsの信頼性の高いインテリジェンスプラットフォームであるSTEPは、業界をリードするマスターデータ管理（MDM）プラットフォームです。このプラットフォームを活用することで、製品、顧客、パートナー、サプライヤー、および拠点のデータを、それぞれ個別の基準を持つ独立したドメインとしてではなく、相互に連携した全体として管理することができます。
マルチエージェントAIにとって、これは次のような意味を持ちます：
- 引き継ぎのたびに単一のガバナンス対象レコード
- ガバナンスルールがデータと共に移動する
- チェーン全体を通じてドメイン間の関係性が維持される
- すべてのドメインにわたる継続的なデータ検証
- すべてのデータ状態は事後的に追跡可能
- 一貫性を損なうことなく、ドメイン間の横断がネイティブにサポートされる
エージェント間AIがパイロット段階から本番環境へと移行するにつれ、その基盤となるデータ層が決定的な要因となります。
リレー競技において、バトンタッチゾーンが管理されていないと、最速のチームでさえ敗北します。ここでも同じことが言えます。エージェントが適切に構成され、特定の目的に合わせて設計されていても、それらを接続する管理されたデータ層がなければ、バトンタッチの段階でパフォーマンスが低下してしまうのです。
Stibo Systemsは、信頼性の高いエージェント間インテリジェンスを実現するために、お客様のビジネス体制を構築します。
よくある質問
従来のソフトウェアのデータガバナンスとAIエージェントのデータガバナンスの違いは何ですか？
従来のデータガバナンスは、データを要求に応じて消費するシステムのために設計されていました：ユーザーがクエリを実行し、アプリケーションがレコードを読み取ります。 AIエージェントは自律的にデータを消費し、途切れることなく次に渡します。
最初のモデルのために構築されたガバナンスは、ステップ間に人間のレビューがなく、不整合が検出される自然なチェックポイントもないため、二番目のモデルでは崩壊します。
何か問題が発生したときに、AIエージェントのワークフローをどのように監査しますか？
マルチエージェントワークフローの監査には、データレイヤーでの可視性が必要です（ワークフローログだけでは不十分です）。 各エージェントが決定を下した瞬間にどのデータ状態で行動したかを知る必要があります。 それがなければ、何かが間違ったことを特定することはできますが、どのチェーンのどこでそれが発生したのか、または何のデータがそれを引き起こしたのかを特定することはできません。
ガバードマスターデータはAIエージェントの展開にとって何を意味しますか？
管理されたマスターデータとは、ワークフロー内のすべてのエージェントが単一の権威あるレコードから読み取ることを意味します。このレコードは、関わるすべてのドメインにわたって一貫した定義、分類、および関係を持っています。
AIエージェントにとって、管理されていないマスターデータは単なる品質の問題ではありません。 それは、すべての自律的な意思決定の時点での信頼性の問題です。
マルチドメインマスターデータ管理とは何ですか？
マルチドメインマスターデータ管理は、製品、顧客、パートナー、サプライヤー、ロケーションなどの複数のデータドメインを、別々のシステムで別々の標準を持つのではなく、つながった全体として管理します。 ビジネス機能全体にAIエージェントを展開する企業にとって、それはエージェントチェーンが信頼性高く機能するために必要な一貫したデータ基盤を提供します。
データの質はAIエージェントのパフォーマンスにどのように影響しますか？
データの質は、エージェントが自律的に行動することを信頼できるかどうかを決定します。 不整合または不完全なデータで動作するエージェントは、その不整合を反映した出力を生成します。 マルチエージェントワークフローでは、それらの出力が次のエージェントの入力となります。
