この記事は Hacobu Advent Calendar 2025 の 4日目の記事です。
Hacobu では今年、AI を活用した PoC サービスを展開する「MOVO AI Lab」を立ち上げた。現在までに、以下の 2 つのサービスを開発している。
-
プロダクトデータを読み込み、対話形式で分析できるサービス
-
物流関連法規について質問すると、RAG による関連文書の検索・要約を返すサービス
本記事では、これらのサービスを実装するにあたり、どのようにテーブル設計を進化させていったのかについて、実例をもとに紹介する。
初期フェーズ：最小構成によるチャット永続化
開発初期は、Bedrock API の構造に揃える形で、以下の ER 図のような最小構成を採用した。
- chats：チャットセッション単位の管理
- messages：ユーザー発言、AI 応答、Tool Use すべてを記録
- contents：LLM へ添付するデータ（例：CSV 形式の取得データ）
messages は Bedrock API の入出力形式とほぼ一致しているため、実装・フロント連携の両面で効率が良かった。また、Tool Use の入力・出力も messages に格納することで、対話ログ全体を一元的に扱えるようにした。この段階では「1 ユーザー発話 → 1 AI 応答」という単純な対話モデルを前提にしていた。
課題：複数ステップ推論への対応
物流関連法規の質問サービスでは、1 回の応答生成に複数ステップの推論が必要となった。具体的には以下を含む。
- ユーザーメモリを加味した RAG 用クエリ生成
- 最終的な応答生成
- LLM as a Judge による品質評価
このような処理は「1 メッセージ＝1 推論」とは対応しないため、messages テーブルだけでは推論過程を十分に表現できないという課題が顕在化した。
拡張：LLM リクエスト管理テーブルの導入
上記の課題に対応するため、チャット単位に紐づく形で llm_requests テーブル を新設した。各推論ステップを独立したエンティティとして扱い、ユーザー入力から最終応答までの一連の処理を明確に追跡できるようにした。
これにより、複雑化する推論チェーンをデータベース上で正確に永続化できるようになった。
ユーザーメモリ管理の追加
物流関連法規では、企業規模や業態によって適用される義務が異なる。そのため回答にあたり質問フェーズを設け、基本情報のヒアリングを行うようにしている。この時、毎回同じ内容を尋ねるのはユーザー体験として不適切である。そこで、セッションを跨ぎユーザー単位で文脈を保持するために user_memories テーブル を導入した。
結果：AI エージェントのワークフロー永続化
以上の拡張を踏まえ、最終的な ER 図は以下の通りとなった。
この構成により、AI エージェントの推論ワークフロー全体を永続化できるようになった。
Discussion