エージェントのための構造化データ活用
エージェント前提の設計が増えてきた中で、
データの作り方がボトルネックになる場面が増えている。
モデルの性能よりも、
「何をどう渡すか」の方が効く。
エージェントは構造で判断する
人間は曖昧でも判断できるが、
エージェントはそうではない。
- 属性が揃っているか
- 定義が一貫しているか
- 比較可能な形になっているか
ここが崩れると、まともに動かない。
具体例：商品推薦エージェント
例えば、スキンケア商品を選ぶエージェントを考える。
やりたいことはシンプルで、
「ユーザーに合う商品を選ぶ」
これをプロンプトで書くと、こうなる。
プロンプト例
あなたはスキンケア商品の推薦エージェントです。
以下のユーザー条件と商品リストをもとに、最適な商品を1つ選んでください。
【ユーザー条件】
- 年齢: 30代
- 肌質: 乾燥肌
- 悩み: 小じわ、ハリ不足
- 価格帯: 5,000円以内
【商品リスト】
[
{
“name”: “Aクリーム”,
“price”: 4800,
“features”: [“保湿”, “エイジングケア”],
“target_skin”: [“乾燥肌”]
},
{
“name”: “Bローション”,
“price”: 3200,
“features”: [“さっぱり”, “敏感肌向け”],
“target_skin”: [“脂性肌”]
}
]
理由とともに回答してください。
なぜこれで動くのか
このプロンプトが成立している理由はシンプルで、
比較のための構造が揃っているから。
- priceが数値で統一されている
- featuresが配列で整理されている
- target_skinが明確に定義されている
この状態なら、エージェントは迷わない。
構造がない場合
逆に、これがこうなっていたらどうなるか。
- 「しっとり系でおすすめ」
- 「ちょっと高めだけど良い」
- 「乾燥気味の人向けかも」
人間なら理解できるが、
エージェントは判断に困る。
結果として、
- 一貫しない推薦
- 意味の薄い理由生成
が起きる。
本質はプロンプトではない
ここで重要なのは、
プロンプトの書き方ではない。
その前のデータ設計。
プロンプトは、構造を前提にして初めて機能する。
戦略としての構造化
設計の順番はこうなる。
- エージェントに何をさせるか
- どの軸で比較させるか
- そのためのデータ構造を定義する
- 最後にプロンプトを書く
プロンプトは最後。
結論
エージェントを賢くしたければ、
プロンプトより先にデータを設計する。
構造化は、そのための基盤。
最後に
エージェントの精度を上げる一番早い方法は、
モデルを変えることではなく、
入力を変えること。
ここに気づくと、設計の視点が変わる。
※本記事はLLMを用いて執筆してます。記事のアイディアと構成については、筆者（人間）から出たものを使っています。