今日、多くのAIシステムは質問に答えることができます。
しかし、実際に企業の中で有用な作業を行えるシステムははるかに少ないです。
一見すると、それはモデルの問題に見えます。たぶん推論力が十分ではない。たぶんプロンプトが弱い。たぶんツール層が不完全なのかもしれません。
ですが、構造化された企業データの周りにエージェントのワークフローを構築する時間を費やした結果、私は別の結論に至りました：
最も難しいのは、しばしば推論ではありません。それはデータの接続性です。
ギャップが本当に見えるのは、エージェントがシステムをまたいで作業しなければならないときです。
デモでは、エージェントは通常きちんと整った環境で動作します。つまり、データベースは1つ、スキーマは1つ、ツールは1つ、明確に定義されたタスクは1つです。
しかし、実際の企業システムはそんなものではありません。
簡単な業務上の問いを例にしましょう：
「48時間経ったのに、すでに出荷済みだが、まだ請求されていない注文はどれですか？」
これは簡単そうに見えますが、実際にデータがどこにあるのかを追跡すると、簡単ではなくなります。
・ 注文は販売システムにあるかもしれない
・ 出荷ステータスはロジスティクスにあるかもしれない
・ 請求ステータスはファイナンスにあるかもしれない
・ 顧客の文脈はCRMにあるかもしれない
そして、これらのシステムにまたがると、名前、キー、スキーマはめったに揃いません。
あるシステムは order_no を使っているかもしれません。
別のシステムは source_id を使っているかもしれません。
ファイナンスは直接リンクしていない可能性もあり、途中のレコードを介してのみ結びついているかもしれません。
エージェントはそれでもSQLを生成できます。
それでもツールを呼び出せます。
それでも正しそうに見えるものを出力できます。
しかし、それは何が実際にどこと接続されているのかを理解していることを意味しません。
そして、企業システムでは最も危険な失敗モードは、明白なエラーではありません。誤った結合パスに基づいて作られた、筋の通った回答です。
ここが、私が考える「現在のエージェントスタックがまだ弱い」ところです。
今日の多くの作業は、エージェントが質問をどう理解するかの改善に向けられています：
・ 推論の改善
・ より良いプロンプト
・ より良いツール利用
・ より良いオーケストレーション
・ より良いRAG
それらはすべて重要です。
ですが、構造化された企業環境では、別の欠けている層があります。
エージェントには、システムをまたいでデータ関係が実際にどう機能するかを、確実に理解する必要があります。
単なるメタデータではありません。
単なる系譜（リネージ）でもありません。
単なる意味の命名規則でもありません。
必要なのは、より実務的な理解です：
・ どのオブジェクトがシステム間で対応しているのか
・ どのフィールドが本当に関連しているのか
・ そのパスが直接なのか間接なのか
・ どの結合が信頼できるのか
・ どの関係候補を除外すべきか
それがなければ、エージェントは基本的にレコメンドシステムのままです。タスクについて語ることはできますが、その下にある実データ層を安全に通して動作することはできません。
なぜArisynが私の目に留まったのか
私がArisynについて面白いと感じたのは、ラベルから始めていないことです。データ自体から始めています。
その中核のアプローチは、命名規則や人手でキュレーションされたメタデータに主に頼るのではなく、値のパターンを分析して、フィールドやテーブル間の包含（inclusion）、同値（equivalence）、階層（hierarchical）関係を特定することです。さらに、Oracle、MySQL、PostgreSQL、SQL Serverのような異種のシステムにも対応しており、安定した関係が見つかると、実行可能なSQLのJOINパスを生成できます。
名前は、企業データにおいてしばしば最も信頼できない部分だから、これは重要です。
レガシーシステムに十分長く触れてきた人なら、すでにご存じでしょう：
・ スキーマがずれていく（ドリフトする）
・ ドキュメントが古びる
・ チームが入れ替わる
・ 業務上の意味は、ラベルではなくデータそのものに保たれていることが多い
もう一つ重要なのは、これが単なる可視化の取り組みではないという点です。
Arisynの基盤となる出力は、構造化されたリレーションシップデータとして表現できます。たとえば、その包含分析は、あるテーブル-カラムの組が別のものの中に含まれている様子を記録しており、JSONのような形式で source_column と target_column のスタイルによるリンク情報を含むテーブル間エッジを返すことができます。これにより結果は、人が読めるだけでなく機械が消費できるものになります。
そして、一度関係の発見が機械が消費できる形になると、それはエージェントのためのインフラのようなものに見えてきます。
なぜ「分析」だけでなく「アクション」に重要なのか
私がこれを重要だと感じる理由は、問いに答えることと実行することの境界が変わるからです。
答えるシステムには、言語理解が必要です。
実行するシステムには、接続の確実性が必要です。
エージェントが実際の仕事を行うのなら――遅延を診断する、レコードを突合する、下流への影響を追跡する、あるいはワークフローの意思決定を行う――それには流暢な出力だけでは足りません。データ世界の基盤を確実に辿れる必要があります。
だから私は、Arisynを単にデータ関係分析ツールだと見なすべきではないと考えています。
より良い捉え方は、次のとおりです：
これは、エージェント向けのマルチソース・データリレーションシップ・パイプラインのように振る舞います。
隠れていて断片的で、人手で再発見されがちな関係を、再利用可能な能力層へと変えるのに役立ちます：
・ 関係を自動的に発見する
・ それらを実行可能なパスへ変換する
・ 構造化された形で公開する
・ 分析、業務運用、ガバナンス、移行、その他のエージェントのシナリオで再利用する
私の現時点の見解
次の段階のエージェントは、最良のモデルや最良のプロンプトスタックを持っている人だけで定義されるわけではありません。
それはまた、言語理解を実際の企業の実行（実務）につなげられる人によっても定義されます。
そして、それを行うには、スタックは推論以上のものが必要です。
企業データが実際にどのように接続されているかをマッピングするための、信頼できる方法が必要です。
より多くの人が注目すべき「欠けている層」は、ここだと思います：
データ関係パイプライン、あるいはより広く言えば、データ関係インテリジェンス層です。
なぜなら、エージェントが本当に行動する前に、自分が動作するデータ世界の構造を理解していなければならないからです。
