LangChain langchain==1.4.3、エージェントが無視できない障害経路を修正

LangChainは、モデルフォールバック、構造化出力、不正なツール呼び出しの修正を含む7件の変更を加えたlangchain==1.4.3をリリースした。このパッチでは、フレームワークのモデル初期化機能にBedrock Mantleのサポートも追加された。この組み合わせにより、本リリースはパッチ番号が示す以上に重要なものとなっている。

中心にある課題は、信頼性と抽象化の両立だ。LangChainでは、開発者がモデルやプロバイダーをまたいで単一のエージェントインターフェースを利用できる。ただし、プロバイダー固有の設定、レスポンス形式、メッセージルールは、依然としてそのインターフェースを通じて露出する。

バージョン1.4.3は、こうした違いによってデプロイ後にエージェントが停止し得る複数の箇所に対処する。公式リリースは2026年9月28日に公開された。これは、以前のツール呼び出し修復に疑問を投げかけた2件の続報の翌日だった。

このアップデートで新しいエージェントアーキテクチャが導入されるわけではない。エージェントコードと変化するプロバイダーの挙動の間にある変換レイヤーを強化するものだ。OpenAI互換エンドポイント、Amazon Bedrock、Anthropic、Fireworks、Azure OpenAIをまたいでエージェントを運用するチームにとって、このレイヤーがフォールバックが実際に機能するかどうかを左右することは少なくない。

langchain==1.4.3で何が変わったのか

本リリースは、エージェントがプロバイダー境界を越える場合や、不完全な会話履歴を再生する場合に現れる障害に焦点を当てている。

LangChainのリリースノートには、バージョン1.4.2以降の7件のプルリクエストが記載されている。このうち4件はモデルまたはエージェントの挙動に直接影響する。残る変更は、ドキュメント更新、コメントアウトされたコードの削除、固定された依存関係の更新だ。

最初の挙動修正では、フォールバック時にキャッシュ関連のモデル設定をサニタイズする。フォールバックは、エラーや可用性の問題を受けて、エージェントが優先モデルから別のモデルへ切り替わる際に発生する。

この修正以前は、最初のプロバイダー向けの設定がリクエストとともに引き継がれる可能性があった。フォールバック先のプロバイダーは、リクエストを完了する代わりに、その見慣れない設定を拒否するおそれがある。すると、耐障害性のための機能そのものが新たな障害点となる。

2つ目の主要な変更では、Amazon Bedrock Mantleの2つのプロバイダーをinit_chat_modelに登録する。この関数は、チャットモデル統合を作成するための共通エントリーポイントをアプリケーションに提供する。

開発者は、プロバイダーとしてbedrock_mantle_openaiまたはbedrock_mantle_anthropicを指定できるようになった。LangChainはその後、リクエストをlangchain-awsが提供する対応クラスへ接続する。

3つ目の変更は、GPT-6 Sol、Luna、Astraに対する構造化出力の選択方法を調整する。構造化出力とは、制約のない文章ではなく、想定されたスキーマに一致するデータをモデルが返すことを指す。

モデルプロファイルが利用できない場合、LangChainは以前、これらのモデルをツールベースの戦略に送る可能性があった。この経路はBedrockでループまたは失敗するおそれがあった。バージョン1.4.3ではモデル名を認識し、デフォルトでプロバイダーネイティブの構造化出力を選択する。

4つ目の挙動変更は、エージェント履歴に保存された不正なツール呼び出しを修復する。ツール呼び出しとは、アプリケーションが関数を実行したり、データを取得したり、あらかじめ定義された別のアクションを実行したりするよう、モデルが生成する要求のことだ。

一部のプロバイダーでは、識別可能なすべてのツール呼び出しに対応する結果メッセージが必要となる。その結果がない不正な呼び出しは、元のターンがすでに終了していても、後続の再生を無効にする可能性がある。

LangChainは現在、識別可能な不正な呼び出しにエラー結果を追加しつつ、ツール呼び出しIDで一致する有効な結果は保持する。この修復は現在および過去のメッセージに適用され、モデルに呼び出しの再実行を求めることはない。

本リリースでは、固定されたAnyIOのバージョンも4.11.0から4.14.2へ変更された。AnyIOは、Pythonのイベントループ実装をまたぐ非同期互換性を提供する。リリースノートでは、これは新たなランタイム機能ではなく依存関係の更新として説明されている。

ドキュメント修正では、リポジトリのセットアップ手順とパッケージ詳細が更新された。別のメンテナンス変更では、コメントアウトされたCohere extraが削除されている。いずれもアプリケーションの挙動を変えるものではないはずだ。

これらを総合すると、バージョン1.4.3は互換性を重視したリリースだ。1つのプロバイダー経路を拡張するとともに、エージェントの継続性に影響する3つの障害経路を引き締めている。

モデルフォールバックで非互換のキャッシュ設定を除去

フォールバックが可用性を高めるのは、2番目のモデルが理解できるリクエストを受け取る場合に限られる。

モデルフォールバックは、ポリシーの観点では単純に聞こえる。アプリケーションはプライマリモデルを選び、1つ以上の代替候補を特定し、リクエストが失敗した際にそのリストを順に進む。

実際のリクエストには、メッセージ以外のものも含まれる。キャッシュキー、カスタムヘッダー、レスポンス形式の指示、ツール定義、タイムアウト、プロバイダー固有のオプションなどだ。

こうした設定が、隠れた互換性の問題を生む。あるプロバイダーが受け付けるキャッシュパラメーターは、別のプロバイダーでは意味を持たない、あるいは無効かもしれない。そのまま渡せば、代替モデルがトークンを生成する前にフォールバックリクエストが失敗する可能性がある。

フォールバック時のキャッシュ修正は、2つの設定を対象とする。フォールバック先がFireworksを使用しない場合はx-session-affinityを削除する。また、Fireworks、OpenAI、Azure OpenAI以外ではprompt_cache_keyを削除する。

セッションアフィニティは、関連するリクエストを同じ処理ロケーションへ誘導し、キャッシュ再利用を改善できる。この挙動はプロバイダーのインフラに依存しており、エンドポイント間で当然に期待できるものではない。

同様に、プロンプトキャッシュキーは、対応プロバイダーがリクエストをキャッシュ済みのプロンプト素材に関連付けるのを助ける。これはすべてのモデルAPIに共通するフィールドではない。

ミドルウェアは、選択されたフォールバック先が対応する場合にはこれらの設定を保持する。また、既存のAnthropicキャッシュマーカー処理を含め、無関係な設定やヘッダーはそのまま残す。

この区別は重要だ。任意の設定をすべて削除すれば一部の互換性エラーは避けられるが、対応するプロバイダーで有用な挙動まで失われる。

その代わりに実装は、フォールバックモデルの_llm_typeを使って、何を残すべきかを判断する。元のリクエストを変更せず、フォールバック呼び出し用にサニタイズ済みの設定を作成する。

この設計は後続処理を保護する。リクエストオブジェクトがミドルウェア間で共有される場合や、別経路で再試行される場合にも、1回のフォールバック試行によってその設定が恒久的に消去されるべきではない。

このプルリクエストには、同期・非同期の両方のテストカバレッジが含まれる。テストでは、ヘッダーのクリーンアップ、非対応のキャッシュキーの削除、フォールバック先プロバイダーが設定を受け付ける場合の保持を確認している。

これは狭い範囲の修正だが、運用上の教訓は広い。クロスプロバイダーのフォールバックは、単なるモデル名のリストではない。リクエストに付随するすべてのフィールドを含む変換の問題である。

チームは、デプロイする順序付きプロバイダーペアをそれぞれテストすべきだ。OpenAIからAzureへの経路が成功しても、OpenAIからAnthropic、あるいはFireworksからBedrockへの挙動が検証されたことにはならない。

このパッチがサニタイズするのは、プルリクエストで扱われた設定だけだ。モデルAPIの進化に伴い、ほかのプロバイダー固有パラメーターも依然として非互換性を生む可能性がある。

したがってアプリケーションチームは、フォールバックの完了をプライマリモデルの成功とは別に監視すべきだ。両経路をまとめたダッシュボードでは、利用可能なレスポンスに一度も到達しないフォールバックシステムが隠れてしまう可能性がある。

また、最終的に各リクエストを処理したモデルも記録すべきだ。このシグナルがなければ、チームは出力の変化やレイテンシーの上昇をプロバイダー移行に結び付けられない。

最も有用なテストは、ミドルウェアが強制された例外を捕捉するかどうかではない。本番環境で使う正確な設定で、下流のリクエスト全体が成功するかどうかだ。

これには、構造化出力、ツール、キャッシュ、メッセージ履歴が含まれる。バージョン1.4.3は既知の2つの罠を取り除くが、すべてのプロバイダーを交換可能にするものではない。

Bedrock MantleがLangChainの共通モデルエントリーポイントに加わる

LangChainはBedrock Mantleを共有イニシャライザー経由で公開するようになったが、アプリケーションはプロバイダーを明示的に指定する必要がある。

新しい統合では、init_chat_modelが認識するプロバイダーにbedrock_mantle_openaiとbedrock_mantle_anthropicが追加される。これらの名称はChatOpenAIMantleおよびChatAnthropicMantleに接続する。

両クラスはLangChain本体のパッケージではなく、langchain-awsに含まれる。Mantle統合には、実行時にバージョン1.7.9以降のlangchain-awsが必要となる。

マージされたプルリクエストによると、これらのクラスは地域別のMantleエンドポイントを自ら解決する。Bedrock APIキー、AWS_BEARER_TOKEN_BEDROCK環境変数、または標準AWS認証情報から導出される一時認証情報も処理できる。

これにより、通常のセットアップからカスタム作成関数を排除できる。開発者は、すでにほかのプロバイダーをルーティングしている同じ高レベルのイニシャライザーを使用できる。

ただし、名前に基づく推論は意図的に限定されたままだ。LangChainは引き続き、anthropic.*で始まるモデル識別子を既存のBedrockプロバイダーに関連付ける。

openai.*で始まるBedrockホストのOpenAI識別子は、Mantleを自動選択しない。開発者はMantleのプロバイダー名、または明示的なプロバイダープレフィックスを指定しなければならない。

メンテナーは、既存の推論を変更すればアプリケーションが別のエンドポイントへ密かにリダイレクトされるため、変更を避けた。現在の挙動を維持することで、すでにBedrock統合を使用するチームのアップグレードリスクを減らせる。

これは妥当なトレードオフを生む。明示的な設定には小さなセットアップ要件が加わるが、パッチリリースによって既存ワークロードのリクエスト送信先が変わることを防ぐ。

依存関係のインストールにも同様の注意が必要だ。プルリクエストの議論では、使用するモデルファミリー向けの複合extraを採用することで結論が出た。

ドキュメント化された組み合わせは、OpenAI互換Mantleモデル向けのlangchain[aws,openai]と、Anthropic互換モデル向けのlangchain[aws,anthropic]だ。このアプローチにより、一般的なAWS extraを軽量に保てる。

議論では、langchain-awsに残る依存関係上の懸念も記録されている。認証情報から導出される一時キーは、更新時に追加のトークン生成パッケージを遅延インポートする可能性がある。

つまり、インポートまたは起動テストの成功だけでは、すべての認証経路を網羅できない可能性がある。一時認証情報を使うチームは、最初のリクエストだけでなく、ステージング環境で更新時の挙動も検証すべきだ。

より広い圧力は、単一の競合企業ではなくフレームワークメンテナーにかかる。クラウドプラットフォームは、複数のAPIファミリー、認証システム、地域別エンドポイントを通じてモデルを公開するケースが増えている。

共通イニシャライザーは、アプリケーションコードを減らすために十分な差異を隠さなければならない。同時に、誤解を招く自動選択を避けるため、十分な差異を露出させる必要もある。

LangChainの判断は、プロバイダー境界での明示的なルーティングを優先している。同一のモデルファミリープレフィックスが異なるBedrockサービスに到達し得る場合、推測より安全だ。

開発者にとって実用的な利点は、構築方法の一貫性にある。アプリケーションは、別個のファクトリー関数を作らずに、設定を通じてMantleバックのモデルを選択できる。

制約も同様に重要だ。共通の構築方法は、プロバイダー間で同じ挙動を保証するものではない。認証、対応パラメーター、ストリーミングイベント、ツール呼び出し、構造化出力は依然として異なり得る。

この新経路を採用するチームは、実際のエージェントワークロードをテストすべきだ。基本的なプロンプトは接続性を確認できるが、ツール実行、スキーマ強制、フォールバック、認証情報更新までは検証できない。

本リリースによりMantleの利用開始は容易になる。実運用への準備は依然として、リクエストライフサイクル全体の検証にかかっている。

GPT-6の構造化出力、ツールエミュレーションから移行

GPT-6 の修正では、モデルプロファイルのメタデータが欠落している場合にネイティブのスキーマ処理を選択し、合成的なツール呼び出しへの依存を減らします。

エージェントフレームワークには、モデル出力を型付きのアプリケーションデータへ変換する戦略が必要です。ひとつはプロバイダーにネイティブの構造化出力を要求する方法です。もうひとつは、目的のスキーマを呼び出し可能なツールとして表現する方法です。

ツール戦略は、ネイティブのスキーマ制御機能を持たないモデルでも利用できます。一方で、ツール選択、引数生成、結果処理、会話履歴の再生を含む、もう一層のプロトコルレイヤーが加わります。

LangChain は通常、モデルがどの戦略をサポートするかを判断するためにモデルプロファイルを利用します。モデルプロファイルは、ネイティブ構造化出力などの機能を記述するメタデータです。

問題となるのは、そのメタデータが存在しない場合です。LangChain はモデル識別子や、ほかに利用可能な情報に基づいてフォールバック判断を行う必要があります。

GPT-6 Sol、Luna、Astra では、従来のフォールバックがツールベースの構造化出力を選択していました。GPT-6 の修正によると、この経路は Bedrock でループや失敗を引き起こす可能性がありました。

バージョン 1.4.3 では、これらのモデル識別子がネイティブ出力用フォールバックリストに追加されました。関連テストによれば、単体のモデル名と Bedrock 接頭辞付きの形式の両方を認識します。

影響範囲は限定的です。プロファイルなしでこれらの GPT-6 バリアントを使用するエージェントは、デフォルトでプロバイダーのネイティブ構造化出力を選択するようになります。

これは、すべてのモデルが同じ扱いを受けるという意味ではありません。期待される機能がすでに判明している特定モデルのための互換性ルールです。

この変更は、機能メタデータが重要なインフラになった理由も示しています。モデル名だけでは、エンドポイントの挙動を十分に説明できないことが少なくありません。

ひとつのプロバイダーが、複数のインターフェースを通じて同じモデルをホストする場合があります。こうしたインターフェースでは、スキーマ機能、受け入れ可能なフィールド、エラーの意味論が異なることがあります。

プロファイルベースのシステムは、その違いをフレームワークが一元的に記述できる場所を提供します。それでもアプリケーションには、プロファイルが欠落、遅延、利用不能な場合に備えた妥当な挙動が必要です。

LangChain のフォールバックリストは、その空白を埋めます。弱点は保守です。新たにサポートされる各モデルファミリーを正確に認識し、プロバイダーの挙動変化に合わせて更新しなければなりません。

偽陰性では、対応可能なモデルが不要なツールエミュレーションへ送られます。偽陽性では、正しく実装されていないエンドポイントにネイティブ出力を要求する可能性があります。

今回の修正は、既知の障害事例を優先しています。フレームワーク全体の構造化出力選択を再定義することなく、指定された GPT-6 モデルにおける問題のある経路を取り除きます。

開発者は引き続き、本番の契約に近いスキーマを検証すべきです。ネストされたオブジェクト、ユニオン、オプションフィールド、長い列挙型では、小さな例では見逃す差異が表面化する可能性があります。

また、バリデーションエラーとプロバイダーエラーは分けて調べるべきです。構造化出力リクエストが受理されても、返されたデータがアプリケーションのスキーマ検証に失敗することがあります。

リトライには慎重な上限設定が必要です。同一リクエストを再実行するスキーマ失敗は、特にフレームワークがエンドポイントの機能を誤分類している場合、高コストなループを生みかねません。

最も安全な展開では、プロバイダーによる受理、スキーマ検証、下流での利用という 3 つの結果を比較します。最初の段階だけを通過しても、信頼できる構造化出力が確立されたことにはなりません。

このリリースは、特定モデルにおける不要なツールエミュレーションを減らします。同時に、モデルカタログが拡大し続ける中で、正確なプロファイルの価値を改めて強調しています。

無効なツール呼び出しが露呈させる、最も困難なエージェント状態の問題

LangChain の修復は再生可能な履歴を保持しますが、その後の報告は、メッセージ正規化が依然としてプロバイダーのルールに左右されることを示しています。

エージェントの会話は、単なる文字起こしではありません。アシスタントのツール要求とツール結果が有効な組を成す必要がある状態機械です。

不正なツール呼び出しは、このシーケンスを壊す可能性があります。モデルが無効な引数を生成したり、必須の識別子を省略したり、フレームワークが解析できない構造を返したりすることがあります。

フレームワークがその呼び出しを一致する結果なしに保存すると、後続のリクエストでプロバイダーが再生された履歴を検証した際に失敗する可能性があります。エラーは、元の不具合から数ターン後に現れることもあります。

LangChain のツール呼び出し修復は、識別可能な無効ツール呼び出しごとにエラー ToolMessage を追加します。また、メッセージ状態を再構築する際に履歴上の呼び出しも確認します。

この修復では、ツール呼び出し ID を照合して既存の結果を保持します。不正なリクエストをリトライしないため、モデルに同じアクションを自動で繰り返させることを回避します。

この挙動は重要な回復目標を支えます。要求されたツールアクションが失敗したことを会話に記録しつつ、周辺の履歴を利用可能な状態に維持できます。

こうした記録がなければ、エージェントは再開不能になる可能性があります。アプリケーションは履歴を破棄するか、手作業でメッセージを書き換えるか、新しいスレッドを始める必要があります。

課題は、プロバイダーがツールメッセージ間の関係を同一の方法で解釈しないことです。あるメッセージプロトコルで有効な修復が、別のプロバイダーのより厳格な並び順ルールに違反する場合があります。

プルリクエストのタイムラインは、この不確実性を可視化しています。9 月 27 日、ユーザーは Anthropic のスレッドと修復済みツール結果に関する後続報告を起票しました。

ある報告では、生成された tool_result に対応する tool_use がなく、無効な呼び出しの後にプロバイダーエラーが発生したと主張されました。別の報告では、修復された呼び出しをすべてのペイロードで親子関係を維持した状態にすることが提案されました。

これらの報告はバージョン 1.4.3 の出荷前にクローズされ、修復はリリースに残りました。それでも、その存在はメッセージ正規化を解決済みとみなさないための有用な警告です。

このプルリクエストは、開発中にパフォーマンス警告も受けました。記録されたベンチマークのひとつでは、エージェント生成時間が 4.5 ミリ秒から 5.4 ミリ秒へ移行し、16.62 パーセントの回帰が示されました。

この数値は中間段階の比較によるものであり、最終リリースの独立したベンチマークとして扱うべきではありません。確定した本番影響ではなく、テストに値する領域を示しています。

大半のデプロイ済みエージェントでは、プロバイダーのレイテンシが 1 ミリ秒の生成差を大きく上回るでしょう。繰り返しエージェントを生成する高スループットサービスでは、異なるコスト特性に直面する可能性があります。

チームは最終パッケージを自社プロセス内でベンチマークすべきです。結果は、初期化パターン、ミドルウェア、ツール、モデル設定、オブジェクト再利用に左右されます。

依然として、正確性のほうが大きな問題です。修復済みの履歴は、実際に起きたことを正確に表現しながら、プロバイダーの要件を満たさなければなりません。

エラー結果は、外部アクションが実行されたことを示唆してはなりません。また、後続の推論中にエージェントが成功したと想定するよう促すべきでもありません。

重要な影響を持つツールを扱うアプリケーションでは、会話メッセージリストとは別に実行記録を保存すべきです。モデル向けの履歴だけでは、十分な監査証跡になりません。

その記録には、要求されたツール、検証済みの引数、実行状態、返されたデータ、副作用を含めるべきです。また、生成された文章に頼らずに障害を再構築する助けにもなります。

エンジニアリングチームは、検索可能なローカル技術文書のコレクションによって、この作業を支援できます。プロバイダーエラーが遅延した再生後に表面化する場合、ランブック、スキーマ、インシデントメモが特に重要になります。

より深い教訓は、エージェントの耐久性が状態修復に依存するという点です。より優れたモデルでも、不正なメッセージを正規化し、因果関係を保ち、試行されたアクションと完了したアクションを区別する必要性はなくなりません。

バージョン 1.4.3 は、この修復経路を改善しています。後続の議論は、開発者が再生対象とするすべてのプロバイダーでこれをテストすべき理由を示しています。

リリース後に開発者が注視すべき点

次の証拠は、クロスプロバイダーのワークロード、更新されたモデルプロファイル、実際の障害に基づく再生テストから得られるべきです。

最初の指標は、混在プロバイダー環境におけるフォールバックの完了状況です。チームは、キャッシュ設定、ツール、ストリーミング、構造化出力を同時に有効化して、プライマリモデルとフォールバックモデルをテストすべきです。

こうしたリクエストがプロバイダーごとの手動クリーンアップなしで完了するなら、新しいサニタイズロジックは役割を果たしています。新たに拒否されるパラメータが現れれば、現在のフィルターが十分に広いという前提は弱まります。

2 番目の指標は、継続的な認証下での Bedrock Mantle の挙動です。起動テストでは、一時的な認証情報の更新、長時間稼働するワーカー、リージョンエンドポイントの変更を検証できません。

サポート対象の両モデルファミリーで更新が成功すれば、統合の妥当性はより強く裏付けられます。更新中の依存関係エラーは、インストールガイダンスにまだ改善の余地があることを示します。

3 番目の指標は、修復済み履歴の移植性です。開発者は、本番で使用する各プロバイダーを通じて、不正なツール呼び出し履歴と部分的に修復された履歴を再生すべきです。

強い結果とは、エージェントがコンテキストを捨てることも、ツールの成功を捏造することもなく再開することです。プロバイダー固有の検証エラーは、共通の修復戦略にさらなる特化が必要であることを示します。

1.4.2 からアップグレードするチームは、広範な本番展開ではなく回帰テストから始めるべきです。最も価値が高いのは、以前に失敗した履歴やリクエスト設定です。

Mantle を使用する場合は、langchain-aws を互換バージョンに固定し、クリーンな環境で必要な extras を確認してください。既存の開発マシンでは、無関係なインストールによって不足している依存関係が隠される場合があります。

GPT-6 の構造化出力については、選択された戦略を確認し、現実的なスキーマを検証してください。単純なオブジェクトの成功が、ネストされた本番レスポンスまで保証すると想定してはいけません。

モデルフォールバックでは、選択されたモデルと、サニタイズされたリクエストカテゴリをログに記録してください。シークレット、生の認証情報、機密のプロンプト内容は記録しないでください。

ツール呼び出し修復では、機密データを除去したうえで、不正な呼び出しをテストフィクスチャとして収集してください。こうしたフィクスチャは、プロバイダーやフレームワークのバージョン変更時に回帰を防ぐことができます。

これらの変更は、アプリケーションレベルの制御の必要性をなくすものではありません。タイムアウト、上限付きリトライ、冪等性キー、実行記録、人によるレビューは、重要な影響を持つアクションに引き続き必要です。

このリリースはむしろ、プロバイダー間の差異がエージェント層に届いた際のフレームワークの挙動を改善します。そうした差異は減るどころか、より一般的になっているため、これは価値があります。

したがって langchain==1.4.3 は、ひとつの注目すべき統合追加を含む信頼性パッチとして理解するのが適切です。その重要性は、フォールバック、スキーマ生成、会話の再生、プロバイダールーティングという、維持しようとする状況にあります。

エージェントがこれらの経路を使用する場合は、アップグレード前に障害を再現し、アップグレード後に再実行してください。その後、個別の修正の境界を本番障害が尊重することはほとんどないため、組み合わせたワークフローをテストしてください。