LangChain構造化出力の実践 — Pydanticで型安全なLLMアプリを作る

LLMに「文章を書いて」と頼むだけでは、自動化の幅は限定される。JSONで構造化された出力を受け取れるようになると、出力をそのままデータベースに保存したり、他のプログラムに連携したりできるようになり、可能性が一気に広がる。LangChainの with_structured_output とPydanticを組み合わせることで「型安全」なLLMアプリを実現できる。素朴にLLMへ「JSONで出力して」と頼むと、余計な前置きが付いてパースに失敗したり、フィールド名が揺れたり、数値が文字列で返ってきたりする。Pydanticで出力の型そのものを定義し、LangChainに渡せば、これらの問題を構造で防げる。パースに成功した時点で「正しい型のデータ」が確保されるため、後続のコードは型の心配なしに書ける。ネスト構造やリスト、数値制約も宣言的に書くことができ、開発生産性が大きく向上する。

実運用で重要なのは「temperature=0」「description充実」「エラーフィードバック付きリトライ」の3点セットだ。temperatureを下げ忘れると、表記ゆれや余計なキーが発生しやすくなる。Field(description=...) を省略すると、LLMがフィールドの意図を推測で補うため、想定外の形式が返ってくることもある。priority という名前だけだと「1〜5の数値」が返ってくることもあり、候補値を明記することが安定の秘訣だ。LLMが型に沿わない出力を返した場合は、検証エラー内容をフィードバックして再リクエストするアプローチが効果的だ。失敗理由を明示するだけで成功率は大きく上がる。

実務経験から「1リクエスト当たり5〜10フィールド」が限界というのは、LLMの限界を知るプロの実感値だ。スキーマが大きすぎると失敗率とトークン消費が跳ね上がる。これは記事で述べたSchema設計と通底している。AIを「データ処理エンジン」として本気で使うなら、このレベルの実装工夫が必須なのだ。構造化出力なしに「AIを組織に組み込む」ことは難しい。出力の信頼性があれば、判断は人間に任せる形で、AIを本当の意味で「使いこなす」ことができるようになる。