LangChainコミュニティ、ストリーミングへのフォールバックに不具合を報告　構造化出力が通知なく失われる可能性

2026年9月27日、LangChainコミュニティが構造化出力の不具合を報告した。モデルがストリーミングインターフェースから通常の呼び出しにフォールバックした後、生成済みのツールデータが解析されず、下流で結果を受け取れない場合があるという。処理中に例外は発生しない。報告環境では langchain-core 1.6.5 が使われており、現時点でイシューはオープンのままだ。[コミュニティの報告](https://github.com/langchain-ai/langchain/issues/40858)

再現コードは外部モデルに接続せず、名前と年齢を含むツール呼び出しを返すカスタムモデルに、Pydanticのツールパーサーを接続するだけで実行できる。同じ入力でも、`invoke` では人物オブジェクトを取得できる一方、`stream` または非同期の `astream` を使うと、結果を集めても空の配列になる。このため、モデルの生成品質やネットワーク障害とは切り分けて問題を調べられる。[再現コードと結果](https://github.com/langchain-ai/langchain/issues/40858)

公式ドキュメントによると、モデルがネイティブストリーミングに対応していない場合、ストリーミングインターフェースは通常の呼び出しにフォールバックできる。また、`disable_streaming=True` を設定するとストリーミングが無効になる。値を `"tool_calling"` にした場合の切り替え条件は、リクエストに `tools` パラメーターが含まれることだ。モデルが実際にツール呼び出しを生成するまで待つわけではない。この互換機構により、アプリケーションは同じインターフェースを使い続けられるが、後続の解析ではメッセージ型を保持する必要がある。[公式APIドキュメント](https://reference.langchain.com/python/langchain-core/language_models/chat_models/BaseChatModel)

ソースコードを照合すると、累積型パーサーは完全なメッセージを汎用の `BaseMessageChunk` でラップする。一方、ツールパーサーはまずそのメッセージが `AIMessage` かどうかを判定してから、標準のツールフィールドを読み取る。型が一致しない場合は旧式の追加フィールドを調べ、見つからなければ空の結果を返す。このコード経路から推測すると、問題の核心は変換後に正しいデータ読み取り分岐へ進めないことにある。表面上の現象だけで、モデルが応答しなかったと判断することはできない。[メッセージ変換の実装](https://github.com/langchain-ai/langchain/blob/master/libs/core/langchain_core/output_parsers/transform.py)、[ツール解析の実装](https://github.com/langchain-ai/langchain/blob/master/libs/core/langchain_core/output_parsers/openai_tools.py)

ツール呼び出しをフォーム、情報抽出、エージェントの中間結果に使うシステムでは、この種のサイレントな失敗によって、下流が解析失敗を「データなし」と誤認するおそれがある。エンジニアリングチームは固定の応答を使い、通常の呼び出し、同期ストリーミング、非同期ストリーミングの3経路を比較するとよい。結果の件数と必須フィールドも確認し、例外が発生しないことだけを成功の条件にしないようにしたい。

報告者は、元のメッセージ型に応じたブロックへ変換する修正案を提示した。しかし確認時点で、イシューから修正PRへのリンクはなく、メンテナーによる影響範囲全体の確認も見当たらない。現時点の証拠から、すべてのモデルプロバイダーやあらゆる構造化出力方式に影響すると一般化することはできない。このケースの調査では、当面は通常の呼び出しを使う方法があるが、実際のサービスでの検証は必要だ。今後は正式な修正と回帰テストを追跡し、特にツールのストリーミングを無効にした場合でも構造化結果が完全に届くかを確認する必要がある。[イシューの状況と修正案](https://github.com/langchain-ai/langchain/issues/40858)