LangChain DeepSeek 1.1.1、エンドポイント切り替えを修正し、strict モードのツール呼び出しを Beta API へ

LangChain は9月22日に langchain-deepseek 1.1.1 をリリースし、strict モードのツール呼び出しに関するエンドポイントの修正を正式パッケージに組み込んだ。PyPI にも同日アップロードされたファイルが掲載されている。パッチは9月7日にマージされており、今回の新たな動きはパッケージのリリースとなる。[リリースノート](https://github.com/langchain-ai/langchain/releases/tag/langchain-deepseek==1.1.1)、[PyPI](https://pypi.org/project/langchain-deepseek/1.1.1/)

問題は、設定オブジェクトと実際の接続が同期していなかったことにある。従来の実装では、ツールのバインドや構造化出力で strict を有効にすると、モデルをコピーして API URL を書き換えていた。しかし、コピー処理ではバリデーターが再実行されず、内部のクライアントは元のエンドポイントを参照し続けていた。メンテナーによると、その結果、設定上は有効に見えても、サーバーでは想定された厳格なスキーマ検証が行われていなかった。[修正に関する議論](https://github.com/langchain-ai/langchain/pull/40249)

現在公開されている実装では、コピー内の同期・非同期クライアントとルートクライアントをクリアし、環境検証処理を呼び出して接続を再構築する。これにより、URL の変更が実際にリクエストを送信するオブジェクトに反映される。元のモデルは自身の設定を保持できる。ただし、自動切り替えが行われるのは URL がパッケージのデフォルト値と一致する場合のみで、企業のゲートウェイや独自に指定した URL には別途対応が必要だ。[クライアント実装](https://raw.githubusercontent.com/langchain-ai/langchain/master/libs/partners/deepseek/langchain_deepseek/chat_models.py)

DeepSeek の公式ドキュメントでは、strict モードで Beta エンドポイントを使用し、各ツール関数に strict を設定することが求められている。各階層のオブジェクトのフィールドをすべて必須にし、追加フィールドを禁止する必要がある。サポートされていないスキーマは拒否される。そのため、アップグレード前には成功していたリクエストが、アップグレード後にはスキーマエラーを返す可能性がある。これは検証が機能し始めたことで生じる差異として確認すべき点だ。[API 仕様](https://api-docs.deepseek.com/guides/tool_calls/)

同バージョンでは、プロンプトキャッシュのヒット量を共通のキャッシュ読み取りフィールドにマッピングし、オブザーバビリティツールがこの部分の入力使用量を識別できるようにした。これは使用量の計測データに関する修正だ。このデータをもとにレポートを読み解く際は、まずフィールドの補完による差異を切り分け、そのうえでリクエストのコストが実際に下がったかを評価する必要がある。後から確認できるよう、パッケージのバージョン、エンドポイント設定、生のレスポンスを一緒に保存しておくとよい。[バージョンの変更点](https://github.com/langchain-ai/langchain/releases/tag/langchain-deepseek==1.1.1)

ツールの出力をデータベースやワークフローに渡すチームにとって、今回の修正はフォーマット制約の信頼性を高めるものとなる。受け入れテストでは、実際のリクエスト先 URL を確認し、同期呼び出しと非同期呼び出しをそれぞれテストしたうえで、サポートされていないスキーマを使ってサーバーが拒否するかを確かめるべきだ。カスタムクライアントを注入している場合は、プロキシ、ヘッダー、トランスポート設定も再検証する必要がある。また、再試行によって構造の不一致が見えなくなることを防ぐため、受け入れテストでは解析エラーも記録として残すべきだ。フォーマットが制約を満たしていても、フィールドの内容が正しいとは限らない。業務ルールと権限のチェックはアプリケーション側が担う必要がある。