エージェントのための構造化データ活用

エージェント前提の設計が増えてきた中で、

データの作り方がボトルネックになる場面が増えている。

モデルの性能よりも、

「何をどう渡すか」の方が効く。

エージェントは構造で判断する

人間は曖昧でも判断できるが、

エージェントはそうではない。

属性が揃っているか
定義が一貫しているか
比較可能な形になっているか

ここが崩れると、まともに動かない。

具体例：商品推薦エージェント

例えば、スキンケア商品を選ぶエージェントを考える。

やりたいことはシンプルで、

「ユーザーに合う商品を選ぶ」

これをプロンプトで書くと、こうなる。

プロンプト例

あなたはスキンケア商品の推薦エージェントです。

以下のユーザー条件と商品リストをもとに、最適な商品を1つ選んでください。

【ユーザー条件】

年齢: 30代
肌質: 乾燥肌
悩み: 小じわ、ハリ不足
価格帯: 5,000円以内

【商品リスト】

[

{

“name”: “Aクリーム”,

“price”: 4800,

“features”: [“保湿”, “エイジングケア”],

“target_skin”: [“乾燥肌”]

{

“name”: “Bローション”,

“price”: 3200,

“features”: [“さっぱり”, “敏感肌向け”],

“target_skin”: [“脂性肌”]

}

]

理由とともに回答してください。

なぜこれで動くのか

このプロンプトが成立している理由はシンプルで、

比較のための構造が揃っているから。

priceが数値で統一されている
featuresが配列で整理されている
target_skinが明確に定義されている

比較に使う項目はそろう。ただし、構造をそろえても、推薦が正確になる保証はない。この商品情報は説明用の架空データであり、実商品の効能や適合性を確認した例ではない。価格条件や対象属性はプログラムでも検査し、出力が入力情報を取り違えていないかを確認する必要がある。

構造がない場合

逆に、これがこうなっていたらどうなるか。

「しっとり系でおすすめ」
「ちょっと高めだけど良い」
「乾燥気味の人向けかも」

人間なら理解できるが、

エージェントは判断に困る。

結果として、

一貫しない推薦
意味の薄い理由生成

が起きる。

本質はプロンプトではない

ここで重要なのは、

プロンプトの書き方ではない。

その前のデータ設計。

プロンプトは、構造を前提にして初めて機能する。

戦略としての構造化

設計の順番はこうなる。

エージェントに何をさせるか
どの軸で比較させるか
そのためのデータ構造を定義する
最後にプロンプトを書く

プロンプトは最後。

結論

エージェントを賢くしたければ、

プロンプトより先にデータを設計する。

構造化は、そのための基盤。

最後に

入力の構造を見直すことは、改善候補の一つになる。

ただし、モデルや検索結果、評価方法によって効果は異なる。

代表的な質問と期待する結果を用意し、変更前後の誤りを比較して判断する。

ここに気づくと、設計の視点が変わる。

※本記事はLLMを用いて執筆してます。記事のアイディアと構成については、筆者（人間）から出たものを使っています。