AI分析スタートアップ：8週間でAIデータ分析プロトタイプを稼働。SQLクエリ精度80%以上を達成。

課題

本格的な製品開発に着手する前に、同社は根本的な問いに答える必要がありました。それは、「この技術的アプローチは実現可能なのか？」という点です。構想から製品化可能な状態に至るまでには、2つの具体的な課題が存在しました。 第一の課題は、データモデルの統合でした。エージェントがクエリを実行するデータソースとなるERPシステムには、ベンダーや実装によって大きく異なるスキーマで構成された大量のデータが含まれています。これらのスキーマ全体で確実に動作するAIエージェントを構築するには、AIが推論できるほど構造化されつつ、実際のERPの多様性に対応できる柔軟性を兼ね備えたモデルスキーマ設計が必要でした。テーブル記述は、エージェントを適切にガイドできるほど正確であると同時に、製品の進化に合わせて変更可能である必要がありました。 第二の課題は、精度でした。自然言語からSQLへの翻訳器として機能するLLMは、デフォルトでハルシネーションのリスクを伴います。これは、構文的には正しいが誤った結果を返すSQLを生成したり、ビジネス用語を誤解釈して問題が静かに拡大したりする可能性があるためです。信頼性の高いデータ分析を核とする製品にとって、精度は二次的な懸念事項ではなく、主要な障壁でした。一貫性のない、あるいは不正確なSQL結果を生成することは、インターフェースがいかに直感的であっても、製品を使い物にならなくするでしょう。 クライアントは、本格的な製品開発に投資する前に、このアプローチが有効であることを示すプロトタイプを必要としていました。

アプローチ

Gradionは、テクニカルアドバイザー1名、PM/PO1名、AIエンジニア1名を含む3名体制のチームで、8週間の探索・プロトタイプ開発スプリントを実施しました。 チームはまず、IS現状分析から着手しました。これにより、既存のデータ環境を評価し、ERPスキーマ構造を理解し、精度と一貫性に関するリスクが最も高い箇所を特定しました。 データアーキテクチャは、プライマリSQLデータベースとセカンダリベクトルデータベースを組み合わせたものでした。匿名化されたデータはプロトタイプSQL DBに移行されました。ベクトルデータベースは、LLMの一般的な推論のみに依存するのではなく、クエリ生成時にエージェントが参照できる例を保存し、コンテキストを通じて精度を向上させるという特定の目的を果たしました。 精度は多層的なファインチューニングアプローチによって対処されました。ベクトル例はコンテキストに基づいた根拠を提供し、テーブル記述は特定スキーマに対するエージェントの正確な語彙を確立し、構造化されたプロンプトはクエリ構築におけるエージェントの段階的な推論を導きました。この組み合わせは、SQL生成におけるハルシネーションを低減し、ビジネスユーザーが重視する意味論的な区別、例えば、基盤となるデータモデルにおいて「注文（orders）」と「購入（purchases）」を異なる概念として正しく区別するといった処理に対応するために設計されました。 完成したプロトタイプは、自然言語クエリを受け付け、基盤となるスキーマに対して正確なSQLを構築し、必要に応じて結果を編集（リダクション）した上で、非技術系ユーザーにも分かりやすい形式で提示できるチャットインターフェースを備えていました。