【ITニュース解説】Data Preparation for AI Agents

AIエージェントは、自然言語で問いかけるだけで、企業が持つ大量のデータから必要な情報を引き出し、瞬時に答えを導き出すことを目指す技術だ。これは、社内の誰もがSlackなどのプラットフォームに質問を入力するだけで、データに基づいた回答が得られる未来を約束する。しかし、最先端の大規模言語モデル（LLM）を、既存の企業データが蓄積されたデータウェアハウスに安易に導入するだけでは、この未来は実現しない。むしろ、信頼性の低いシステムになってしまう。

AIエージェントは、データの欠陥、データ同士を結びつけるための情報（データ結合）の不足、あるいはどのような情報が格納されているか説明されていない（文書化されていない）カラムといった問題を自力で修正できない。もし、基盤となるデータインフラストラクチャが、バラバラに管理されたデータの塊（サイロ）や、あいまいなデータの構造（スキーマ）で整理されていない状態であれば、AIエージェントは組織内の全員に対して、間違った回答をより迅速に、そして自信満々に提供してしまう。間違った情報でも自信を持って出力してしまうのは、AIの設計上起こり得ることであり、この問題はさらに深刻になる。

データ基盤をしっかり構築することが、AIエージェントの性能を大きく左右する。例えば、Runpodという企業が、社内のチームがインフラの利用状況に関する指標をSlackで直接問い合わせられるAIエージェントを開発した際、最も重要な教訓は、モデルそのものの改善よりも、データの基盤となるアーキテクチャの改善だった。モデルに少し手を加えても小さな改善しか得られなかったのに対し、データ基盤を根本的にアップグレードしたところ、エージェントの応答の品質と実用性が劇的に向上したのだ。この経験は、「今日、何台のGPUがメンテナンスで稼働したか？」や「過去1時間で何台のGPUが停止したか？」といった質問に対し、正確で行動につながる回答を得るためには、データ基盤こそがAI戦略の核となるべきであることを示した。

多くの企業のリーダーは、AIモデルの微調整や複雑なカスタムプロンプト（AIへの指示）層の開発に多額の予算を割り当てがちである。しかし、このアプローチは根本的な問題解決とは異なる方向を向いている。AIエージェントを信頼できるものにするためには、まず堅牢なデータ基盤を確立することから始めるべきだ。企業で安心して利用できるAIへと移行するためには、技術リーダーはデータ基盤における3つの基本的な柱、すなわちセキュリティ、品質、可観測性に注力しなければならない。これらの領域に焦点を当てることで、信頼性の高いAI導入に必要な構造が提供される。

最初の柱は、データセキュリティと明確性である。AIエージェントがアクセスするデータのセキュリティを確保するには、プロンプトによる指示に頼るのではなく、データベースそのものにセキュリティを組み込む根本的な変更が必要だ。多くのチームは現在、「テーブルを削除するな」といった指示をAIエージェントに与えることで、データシステムを保護しようとしているが、この方法は重大なセキュリティ上の弱点となる。なぜなら、悪意を持ったユーザーは、プロンプトインジェクションという手法を使って、これらの指示を迂回するようなプロンプトを作成できる可能性があるからだ。

現実的な解決策はシンプルだ。プロンプトエンジニアリングを主要なセキュリティ機構として使用することをやめる。AIエージェントを、まるで人間のジュニアアナリストのように扱うべきだ。つまり、読み取り専用のデータベース接続情報だけを与え、ビジネス利用のために厳選され、十分にテストされた「ゴールドレイヤー」と呼ばれる特定のテーブル群にのみ、役割ベースでアクセスを厳しく制限する。もし、データベースの役割自体が、DELETE（削除）やDROP（テーブル破棄）のようなコマンドを実行できないようになっていれば、どのような敵対的な指示を受けたとしても、エージェントが引き起こす可能性のある損害はほぼゼロになる。

セキュリティに加えて、データテーブル内の曖昧さを排除することも、AIエージェントが不正確な情報、しばしば「ハルシネーション」（幻覚）と呼ばれるものを生成するのを防ぐために非常に重要である。人間のアナリストにとって、「latency」（遅延）や「revenue」（収益）のような曖昧なカラム名でも、組織内の知識があればその意味を理解できることが多い。しかし、AIエージェントにとって、このような曖昧さはハルシネーションのリスクを大幅に高めてしまう。厳密なガイドラインがなければ、エージェントは推測を強いられることになる。時には正しく推測できることもあるが、ミリ秒と秒を混同したり、粗利と純利益を取り違えたりして、重大なエラーにつながることがある。

これを解決するためには、データスキーマ全体で厳格で自己記述的な命名規則を導入することが必要だ。例えば、データ結合に使用される識別用のカラムには「id_」のような標準化されたプレフィックスを、真偽値（はい/いいえ）を表すカラムには「is_」を、金額を表すカラムには「amt_」を使用する。さらに、ミリ秒には「_ms」、米ドルには「_usd」、ギガバイトには「_gb」のような明示的な単位を示すサフィックス（接尾辞）を使用する。曖昧な「latency」というカラム名が「dur_latency_ms」（遅延時間_ミリ秒）や、「revenue」が「amt_gross_revenue_usd」（総収益金額_米ドル）のように変われば、データは完全に自己文書化される。エージェントは名前を読み取るだけで、データの種類や単位を即座に理解できるようになり、推測する必要がなくなるため、精度と信頼性が大幅に向上する。

最後の柱は、データ整合性のための自動可観測性の実装である。データパイプラインは、問題が発生してもすぐに通知されないまま失敗することがある。例えば、データをデータベースに取り込む処理（インジェクションジョブ）が音もなく停止し、データベーステーブルは正常に見えるが、実際には数時間、あるいは数日前の古いデータしか含まれていない、という状況が起こり得る。AIエージェントは古くなったテーブルを盲目的に参照し、リアルタイムの情報が必要な経営者に対して、自信満々に古い数値を提供してしまうだろう。これはビジネス運営に深刻な結果をもたらす可能性がある。

これに対処するためには、組織は自動化された可観測性モニターを開発し、それをAIエージェントシステムにとって不可欠な安全装置として機能させる必要がある。異常の検出、データの欠落の特定、データ量の変化の監視を行う自動チェックを設定する。さらに、データパイプラインがデータの鮮度に関するメタデータ（データについてのデータ）をデータベース内で直接公開するようにする。これにより、AIエージェントはテーブルが最後に更新された日時を正確に判断し、そのタイムスタンプをユーザーに提示するか、パイプラインエラーが検出された場合には回答を完全に差し控えることができるようになり、不正確な情報や古い情報が広まるのを防ぐことが可能になる。

何年もの間、データエンジニアリングのコミュニティでは、AIがデータモデリングやスキーマ、分析エンジニアリングといった概念を不要にするだろうという懸念が広がっていた。しかし、現実はまさにその逆であることが証明されている。AIエージェントは、綿密なデータモデリング、網羅的なテスト、そして厳格なパイプライン管理をこれまで以上に重要にしているのだ。人間は整理されていないデータウェアハウスの中をある程度操作し、解釈することができるが、ソフトウェアシステムにはこのような直感的な能力がなく、明示的で構造化されたデータを必要とする。

企業レベルでAIが広く採用される上での主要な障害は、計算能力やAIモデル自体の能力ではない。むしろ、それは組織が持つデータの基本的な状態にある。もし企業が、AIエージェントが提供する真の競争優位性を手に入れたいと考えるのであれば、次の画期的なAIモデルを追い求めるのをやめるべきだ。最も効果的な行動は、データテーブルを徹底的にクリーンアップし、構造化することに焦点を当てることである。これらの基盤となるデータの問題に対処することが、AIの成功と信頼性のある展開への道を開くだろう。