Anthropic GitHub、LangChain 1.5.3の潜在的な2つの障害を修正
LangChainが2026年7月28日にバージョン1.5.3をリリースしたことで、Anthropic連携には2つの的を絞った修正が加わった。このAnthropic GitHubアップデートは、HTTP 400エラーによってClaudeエージェントループを停止させ得る障害に対応する。どちらの変更も目に見えるモデル機能を追加するものではないが、エージェントが依存するメッセージ履歴を保護する。
1つ目の修正は、LangChainがストリーミングされた署名データを処理する際に、空のthinkingフィールドを維持する。このフィールドがない場合、有効なClaude応答が、次回のモデル呼び出しで再生されたときに無効なメッセージへ変わる可能性があった。2つ目の修正は、Anthropicへ送信する前に、システムメッセージのコンテンツブロックからLangChain固有の識別子を削除する。
この組み合わせにより、これは単なる定例パッチ以上の意味を持つ。このリリースは、エージェント基盤で繰り返し生じる衝突を浮き彫りにしている。フレームワークは移植可能な1つのメッセージ形式を求める一方、モデルプロバイダーはより狭いAPIスキーマを強制する。OpenAI、Google、Anthropicなどのプロバイダーは、それぞれ最終的なリクエスト境界で異なるルールを課している。
LangChainはこれらの形式の間に位置する。その抽象化は開発者がモデルを切り替え、ツールを組み合わせる助けになるが、変換のたびに有効な状態が失われる箇所が増える。バージョン1.5.3は、空文字列が1つ欠けることや余分な識別子が1つあることだけで、正常に動作していたエージェントを停止させ得ることを示している。
LangChain Anthropic 1.5.3で変更された点
LangChain Anthropic 1.5.3は、Claude APIに拒否されるリクエストを生成していた2つのメッセージ変換経路を修正する。
公式のAnthropicリリースノートには、バージョン1.5.2以降の2つの修正が記載されている。1つはストリーミングされたthinkingブロックを対象とし、もう1つは送信前にシステムメッセージのコンテンツをサニタイズする。
ストリーミングの修正は、適応型thinkingに関わる限定的なイベントシーケンスを対象とする。適応型thinkingでは、Claudeがプロバイダー設定の上限内で、どの程度の内部推論を適用するかを決定できる。APIは、表示される回答とともに、構造化されたthinkingコンテンツと暗号学的署名を返す場合がある。
ストリーミング中、こうした結果は必ずしも1つの完全なオブジェクトとして届くわけではない。LangChainは複数のイベントを受け取り、それらをモデル応答の正規化表現であるAIMessageへ結合する。その組み立てられたメッセージは、後続の別のリクエストの一部になる可能性がある。
報告された障害は、thinkingブロックに空文字列が含まれているにもかかわらず、signature_deltaを受け取った場合に発生した。署名デルタは、thinkingブロックの署名データを運ぶストリーミングされた断片である。追加する推論テキストがなかったため、その後にthinking_deltaは続かなかった。
LangChainは当初、空のブロック状態を破棄していた。その後、署名イベントからブロックを再構築し、typeとsignatureフィールドを持つオブジェクトを生成した。しかし、必須のthinkingキーが欠けていた。
このメッセージは、アプリケーション内に保存されている間は問題がないように見える可能性がある。エージェントがその履歴をClaudeへ再生したときにのみ失敗した。Anthropicは、thinkingブロックに必須フィールドがないためリクエストを拒否した。
ストリーミング修正では、署名デルタを処理する際にsetdefault("thinking", "")を使用する。この操作は既存の値を保持し、キーが存在しない場合には空文字列を挿入する。そのため、推論テキストを捏造することなく、プロバイダーが期待するオブジェクト形状を維持する。
システムメッセージの修正は、反対の問題に対処する。必要なフィールドが失われるのではなく、LangChainがサポートされていないフィールドを転送していた。
LangChain v1のコンテンツブロックには、内部的なidを含めることができる。この識別子は、フレームワークがコンテンツを一貫して表現・追跡するのに役立つ。Anthropicのシステムメッセージスキーマは、同じ場所でこのフィールドを受け付けない。
バージョン1.5.3以前は、_format_messagesがリストベースのSystemMessageコンテンツを転送する際、各テキストブロックを絞り込まない場合があった。そのため、create_text_block()で作成したブロックが内部識別子を送信ペイロードに含める可能性があった。
Anthropicは、余分な入力は許可されないというエラーでこのリクエストを拒否した。同じフォーマット経路は、get_num_tokens_from_messagesによるトークン数計算にも影響した。アプリケーションは、リクエストサイズを見積もるだけで生成前に失敗する可能性があった。
システムブロック修正は、システムテキストブロックに共通のフォーマットヘルパーを適用する。type、text、cache_control、引用などのサポートされたプロパティは維持しつつ、サポートされないメタデータを削除する。
これらの変更はコード量としては小さい。しかし、どちらもエージェントアプリケーションで繰り返し使われる境界で発生するため、運用上の効果はより大きい。一方はストリーミング中の応答状態を保護し、もう一方は送信前にアプリケーション状態をクリーンアップする。
Anthropic GitHubの修正がエージェントループに重要な理由
重要な障害は遅れて現れた。LangChainはClaudeの応答を受け入れて保存できたものの、破損を検出したのは次のターンになってからだった。
基本的なチャットボットは、1つのプロンプトを送信して1つの回答を表示できる。エージェントループはより長いシーケンスを実行する。モデルがツールを選択し、アプリケーションがそれを実行し、モデルは自身の過去のメッセージとツール結果の両方を受け取る。
この再生要件により、メッセージの忠実性は極めて重要になる。アプリケーションは表示用の文章だけを安全に保持できるとは限らない。会話を正しく継続するには、構造化されたツール呼び出し、thinkingブロック、署名、プロバイダー固有のメタデータが必要になる場合がある。
Anthropicの拡張thinkingガイダンスでは、thinkingブロックが署名を保持できることが説明されている。これらのブロックが後続のリクエストに入る場合、アプリケーションは関連する構造を維持しなければならない。したがって、フレームワークは単なるテキストラッパーではなく、状態シリアライザーとして機能する。
元のバグ報告には、実際のAPI呼び出しを必要としない決定的な再現手順が含まれていた。空のコンテンツを持つthinkingブロックの開始後に、署名デルタが続くケースをシミュレートした。集約結果にはthinkingキーがなかった。
この欠落は、最初のストリーミング回答を必ずしも壊すわけではなかった。ユーザーは通常の応答を受け取れ、エージェントは選択したツールを実行できた。障害が現れたのは、次のリクエストに不正な過去メッセージが含まれたときだった。
このタイミングは、バグの診断を難しくする。開発者はツール出力、2つ目のプロンプト、あるいはチェックポイントの復元を疑うかもしれない。実際の欠陥は1ターン前、LangChainがストリーミングメッセージを組み立てている間に会話へ入り込んでいた。
永続的なチェックポイントは、さらに影響を大きくした。チェックポインターは、ワークフローが中断後に再開したり、プロセスをまたいで継続したりできるようエージェント状態を保存する。不正なブロックが保存されると、ワーカーを再起動しても会話は修復されない。
不正なオブジェクトが履歴に残るため、エージェントは同じ拒否に繰り返し遭遇する可能性がある。復旧には、失敗したリクエストを単に再試行するのではなく、保存済み状態の削除または変換が必要になる場合がある。
リポジトリを調査するようClaudeに依頼するコーディングエージェントを考えてみよう。Claudeは検索ツールを選択し、フレームワークはアシスタントのストリーミングメッセージを保存する。ツールは一致するファイルを返すが、Claudeがそれらを分析する前にフォローアップ呼び出しが失敗する。
検索操作に問題はない。代わりにエージェントは、再生されたthinkingブロックに空のthinkingフィールドがなく、署名だけがあるため失敗する。バージョン1.5.3は、その2回目の呼び出しに必要な形状を再構築する。
サポートエージェントでも同じパターンが起こり得る。顧客レコードの取得には成功しても、結果をClaudeに解釈させようとして失敗する。モデルとデータソースが利用可能なままでも、この欠陥は不安定な業務ワークフローとして現れる。
システムメッセージの問題は、より早く表面化する可能性がある。多くのアプリケーションは、再利用可能なコンテンツブロックからシステム指示を構築する。これらのブロックは、一般的なLangChain APIを通過した後にフレームワーク識別子を持つことがある。
Anthropicがそのメタデータを拒否した場合、モデルは生成を開始できない。同じフォーマットロジックを使用するため、トークン見積もりも失敗する可能性がある。したがって、計画コードはアプリケーションが意図した完了リクエストを送信する前に停止する場合がある。
Anthropicのストリーミング修正とシステムサニタイズの変更は、異なる移動方向に対応している。ストリーミングはプロバイダーイベントをLangChainオブジェクトへ変換する。メッセージフォーマットはLangChainオブジェクトをプロバイダーリクエストへ戻して変換する。
両者は合わせて往復を保護する。Claudeが構造化状態を生成し、LangChainがそれを保存し、アプリケーションが後で返す。エージェントの信頼性は、必要な箇所では損失なく、必要な箇所では厳格に、このサイクルが維持されることに依存している。
1つのフレームワークスキーマと、より厳格なプロバイダー境界
LangChainは意味のあるプロバイダー状態を維持しながらフレームワークのメタデータを削除しなければならず、その目標は同じ会話の中で衝突する可能性がある。
主な緊張関係は、LangChain対Anthropicではない。移植性と厳密なスキーマ準拠の間にある。LangChainは共通のメッセージ抽象化を提供する一方、AnthropicはAPIが期待するリクエスト形状を検証する。
正規化されたコンテンツブロックには、フレームワーク全体で有用な情報を含められる。開発者は識別子、引用、ツール情報、キャッシュ制御を付加できる。プロバイダーアダプターは、その一般的な表現をより狭いワイヤ形式へ変換する。
この設計は、アプリケーションが統合を切り替える助けになる。チームはClaude、OpenAIモデル、Googleモデルで類似したオーケストレーションパターンを利用できる。しかし、最終ペイロードは依然として各プロバイダー固有の契約に従わなければならない。
バージョン1.5.3は、アダプターで起こり得る2種類のミスを示している。
1つ目は、過剰なフィルタリングまたは不完全な再構築である。LangChainは、通常のアプリケーションロジックでは空文字列と欠損値が同等に見えることが多いため、空フィールドの存在を失った。Anthropicのスキーマでは、これらの状態は異なるものとして扱われた。
空のthinking値は、そのフィールドが存在しテキストを含まないことを伝える。キーの欠落は、オブジェクトが期待される構造を満たしていないことを伝える。意味的なコンテンツは空でも、構造上の区別は重要なままである。
2つ目のミスは、フィルタリング不足である。LangChainは、内部的なidがシステムテキストブロックを通じてフレームワークの外へ出ることを許していた。この識別子はLangChain内では有効であっても、Anthropicの境界では無効になり得る。
したがって、正しいアダプターの動作は非対称に見える。一見空に見えるプロバイダーフィールドを保持しながら、一見有用に見えるフレームワークフィールドを削除しなければならない。「空の値を削除する」や「すべてのメタデータを保持する」といった一般的なルールでは、どちらか一方で失敗する。
これが、プロバイダーアダプターが依然として重要なエンジニアリングコンポーネントである理由だ。単にプロパティ名を変更する以上の役割を持つ。アイデンティティ、状態、ストリーミング、検証、ツール、会話再生に関する異なる前提を調整する。
直接SDKを使うユーザーは、1つのプロバイダーのネイティブ型に対してリクエストを構築するため、変換層が少ない。このより狭いアプローチは曖昧さを減らせる。一方で、より多くのアプリケーションロジックが単一のAPI表現に結び付く。
フレームワークのユーザーは構成性と移植性を得るが、アダプターのリスクも引き受ける。各プロバイダーがモデル、ストリーミングイベント、コンテンツタイプ、検証動作を変更するたびに、フレームワークは更新しなければならない。
OpenAIやGoogleの統合も、正確なフィールドが異なる場合でも、関連する圧力に直面する。各プロバイダーは、受け付けるコンテンツブロックとツールメッセージのルールを独自に定義している。共有抽象化は、ネットワーク境界におけるそれらの違いを消し去ることはできない。
このリリースは、直接 SDK を使う方が常に安全だと証明するものではありません。直接実装でも履歴を破損させたり、サポートされないフィールドを送信したりする可能性があります。ただし、抽象化は責任をなくすのではなく、移すものだという点を示しています。
LangChain は、どの詳細が移植可能で、どれがプロバイダー固有かを判断する責任を負うことになります。アプリケーション側には引き続き、アップグレード、回帰テスト、保存済み状態との互換性、可観測性に対する責任があります。
LangChain Anthropic のリリースは、スキーマエラーが本番環境で注意を払うべき理由も浮き彫りにしています。HTTP 400 レスポンスは、多くの場合、開発者の誤用を示しているように見えます。しかし今回のようなケースでは、アプリケーションが文書化されたフレームワークオブジェクトを使用していても、拒否されるペイロードを生成する可能性があります。
この違いはインシデント対応に影響します。構造を変えずに無効なリクエストを再試行しても時間を浪費し、キューの滞留を悪化させかねません。監視では、プロバイダーの検証メッセージを保持し、影響を受けたコンテンツブロックのインデックスを特定すべきです。
チームは、初回呼び出しの失敗とリプレイ時の失敗も区別する必要があります。最初のリクエストでのエラーは、プロンプト構築やシステムメッセージの書式設定を示唆します。ツール実行後のエラーは、保存済みのアシスタント状態やツール結果のシーケンスを示唆します。
この分類はデバッグの代わりになるものではありません。探索範囲を絞り込むものです。バージョン 1.5.3 では、構造化メッセージ周辺で Anthropic リクエストが失敗した場合に、開発者が確認できる具体的な変換経路が 2 つ提供されます。
パッチの対象は限定的で、既存の状態にはなおリスクが残る
アップグレードにより文書化された変換は防げますが、保存済みのすべての会話が有効であることや、すべてのデプロイ経路で新しいパッケージが使われていることを自動的に証明するわけではありません。
ストリーミング修正の対象は特定のシーケンスです。thinking delta を伴わない署名データの後に、空の adaptive-thinking ブロックが続くケースです。関連する thinking 動作を有効にしていないアプリケーションでは、この問題に遭遇しない可能性があります。
システムメッセージの修正にも明確な対象範囲があります。システムメッセージ内のテキストブロックをサニタイズし、サポートされるプロパティを保持します。マージされた変更によれば、テキスト以外のシステムブロックは変更されずに通過します。
この限定的な範囲はパッチリリースとして適切です。広範なメッセージ書き換えは、正常に動作しているアプリケーションを変更したり、別の経路で必要となるメタデータを削除したりする可能性があります。焦点を絞った修正は、その互換性リスクを低減します。
ただし、焦点を絞ったコード変更には、焦点を絞った検証が必要です。チームは、パッケージのインストール成功を十分な根拠とみなすのではなく、自社のメッセージパターンを再現すべきです。
最初のテストでは、実際のエージェントループを通じて Claude のレスポンスをストリーミングします。ワークフローでは少なくとも 1 回ツールを実行し、その後に別のモデル呼び出しへ進む必要があります。これにより、thinking フィールドの不具合を露呈させたリプレイ経路を検証できます。
開発者は、次のリクエスト前に組み立てられたアシスタントコンテンツを確認すべきです。署名を持つ thinking ブロックは、値が空でも thinking キーを保持する必要があります。ログでは、機密性の高い推論内容やユーザーデータを露出させないようにしなければなりません。
2 番目のテストでは、本番環境と同じヘルパーを使ってリストベースのシステムメッセージを構築します。内部識別子と、キャッシュ制御などのサポートされるプロパティを含めるべきです。送信される Anthropic ペイロードでは、サポート対象のデータを保持しつつ識別子が削除される必要があります。
トークン数の計算には、独自のアサーションが必要です。システムメッセージに関する報告では、get_num_tokens_from_messages が同じ不具合のあるフォーマッターを共有していたことが示されました。生成テストだけでは、予算管理、ルーティング、事前検証での失敗を見逃す可能性があります。
保存済みチェックポイントには別の不確実性があります。マージされたプルリクエストは、新しいストリームイベントの組み立て方を変更します。アプリケーションがすでに保存している不正な AIMessage をすべて移行するとは主張していません。
永続的なエージェント状態を利用するチームは、アップグレード前に作成された会話をサンプリングすべきです。署名は含むものの thinking が欠けている thinking ブロックを特定できます。これらの記録には、管理された修復または新規会話が必要になる可能性があります。
移行は保守的に進めるべきです。空の値を追加することは文書化されたバグ修正と一致しますが、本番データには他のブロック形状が含まれている可能性があります。チームは、自身の正確なパッケージバージョンとプロバイダー設定に対して検証する必要があります。
依存関係の解決もアップデートを見えにくくする可能性があります。アプリケーションが広いバージョン範囲を宣言していても、ロックファイルが 1.5.2 を保持していることがあります。別のサービスでは、異なるロックファイルやキャッシュされたコンテナレイヤーからビルドされる場合があります。
ランタイムテレメトリーでは、インストール済みの langchain-anthropic バージョンを記録すべきです。この証拠は、ソースマニフェストだけを確認するより信頼できます。分散ワーカーは、運用担当者がインシデントを終了する前に、同じ解決済みバージョンを報告する必要があります。
リリースページでは、バージョン 1.5.3 は 1.5.2 の後にリリースされ、列挙された 2 件の修正を含むとされています。パフォーマンスベンチマーク、レイテンシ改善、新しいモデル品質に関する主張は示されていません。開発者は、それらの成果を推測すべきではありません。
また、これらの修正が Claude ストリーミングのすべてのエッジケースを解消するという証拠もありません。対象となるのは、再現可能な経路を持つ報告済みの失敗です。その他のイベント組み合わせ、コンテンツタイプ、またはプロバイダー側の変更には、引き続きテストが必要です。
このパッチのテスト証拠は有望ですが、範囲には限りがあります。システムメッセージのプルリクエストは、提出時の説明で 241 件のユニットテストが成功したと報告しています。GitHub はその後、マージプロセス中により広範なチェック状態を表示しましたが、これは本番環境での普遍的な検証と読むべきではありません。
ストリーミングの変更にも、欠落フィールドに対する回帰テストが含まれています。決定的なテストは、プロバイダーの可用性に依存せずフレームワークの動作を分離できるため有用です。ただし、すべてのライブエージェント構成を表現できるわけではありません。
したがって、慎重な解釈は明快です。バージョン 1.5.3 は確認済みの 2 件の不具合を修正しますが、信頼性はメッセージライフサイクル全体に依存します。ストレージ層、カスタムシリアライザー、ミドルウェア、古いチェックポイントによって、不正な状態が再び導入される可能性があります。
Anthropic ストリーミング修正後に開発者が変更すべきこと
最も安全な対応は、慎重なアップグレードの後に、実際の本番トラフィックに合わせたリプレイ、システムメッセージ、チェックポイントのテストを行うことです。
まず、Claude リクエストを送信するすべてのプロセスで、インストール済みパッケージのバージョンを確認します。ローカル開発環境、継続的インテグレーション、バックグラウンドワーカー、デプロイ済みコンテナを確認してください。バージョンが混在すると、会話履歴に一貫性がなくなる可能性があります。
次に、署名のみを持つ thinking delta の回帰ケースを追加します。期待される集約済みブロックには thinking: "" が含まれていなければなりません。その後、テストではそのメッセージをリプレイし、ペイロード構築が成功することを確認します。
現在のモデルがこのシーケンスをほとんど出力しない場合でも、このケースは重要です。エージェントが継続的に動作する場合、まれな構造イベントが信頼性を大きく左右する可能性があります。低頻度の不具合でも、数千回のツール呼び出しを通じて顕在化します。
LangChain の v1 ヘルパーを通じて作成されるシステムテキストブロックについて、2 番目のテストを追加してください。内部ブロック識別子、サポート対象のテキスト、およびアプリケーションで使用するキャッシュ制御フィールドを含めます。最終的なプロバイダーペイロードに対してアサートしてください。
ユニットテストだけで終わらせてはいけません。完全なエージェントグラフを通じてステージング会話を実行します。ストリーミング、ツール呼び出し、チェックポイント永続化、プロセス再開、さらにもう一度の Claude リクエストを含めてください。
このシーケンスは、データの所有権が変わる境界を検証します。Anthropic クライアントがイベントを出力し、LangChain がそれを集約し、チェックポイントが保存し、その後のワーカーが再びフォーマットします。
可観測性では、機密コンテンツを記録せずに構造情報を取得すべきです。有用なフィールドには、ブロックタイプ、フィールドの有無、メッセージ位置、パッケージバージョン、プロバイダーエラーのカテゴリが含まれます。thinking の全文を通常のアプリケーションログに記録すべきではありません。
HTTP 400 レスポンスでは、可能であればプロバイダーのフィールドパスを保持してください。messages.1.content.0 のような位置は、リプレイされたアシスタント状態を示唆します。system.0 配下の位置は、システムコンテンツのフォーマットを示唆します。
アプリケーションは、スキーマ検証エラーに対する無差別な再試行を避けるべきです。同じ無効なペイロードは通常、再び失敗します。再試行ポリシーでは、一時的な転送エラーと決定的なリクエストエラーを分ける必要があります。
チェックポイントの管理者は、復旧戦略を定義すべきです。1 つの選択肢は、影響を受けた会話を無効化して新しく始めることです。別の選択肢は、特定された thinking ブロックの欠落した空フィールドを復元する、レビュー済みの移行です。
正しい選択は、保持要件と監査要件に依存します。サポートワークフローでは会話の履歴を保存する必要があるかもしれません。短期間のコーディングセッションなら、要約されたコンテキストで安全に再開できます。
フレームワークを評価するチームも、評価基準を調整すべきです。モデルサポートは、利用可能なクラスのチェックリストだけではありません。ストリーミング、ツール、メッセージリプレイ、トークン数計算、キャッシュ、永続化を通じた忠実性も含まれます。
直接 SDK 統合は、依然として有用な比較対象です。アプリケーションが Claude のみを使い、ネイティブメッセージ型を厳密に制御する必要がある場合、変換が少ないことでデバッグが簡素化される可能性があります。その選択では、フレームワークレベルの移植性やオーケストレーションの一部を犠牲にします。
アプリケーションが共通インターフェース、モデルルーティング、グラフ実行、既存のフレームワークコンポーネントから恩恵を受ける場合、LangChain 統合はより理にかなっています。バージョン 1.5.3 はその判断を決着させるものではありません。そこに伴うアダプターの責務を明確にするものです。
今後数か月で、3 つのシグナルに注意を払うべきです。
まず、thinking ブロック、署名、またはリプレイされたツール会話に関する新たな報告を確認してください。問題トラッカーが静かであれば、anthropic ストリーミング修正が観測されたシーケンスをカバーしているという信頼が高まります。関連する失敗は、より広範な再構築上の問題を示すでしょう。
次に、LangChain のクロスプロバイダー向けコンテンツブロック正規化の変更を注視してください。システムメッセージの不具合は、内部識別子とプロバイダースキーマの不一致から生じました。共有サニタイズ処理がさらに進めば、保守担当者が統合全体でこのパターンに対処していることを示します。
3 番目に、受け入れ可能な thinking またはシステムコンテンツに関する変更について、Anthropic のスキーマおよびストリーミングドキュメントを確認してください。フレームワークコードが変わらなくても、プロバイダー側の進化によって前提が無効になる可能性があります。
現在 Anthropic GitHub 統合を使用している開発者にとって、実務上の対応は明確です。アップグレードし、解決済みバージョンを確認し、実際のツール呼び出しワークフローをリプレイしてください。そのうえで、パッチが保存済み状態を修復したと判断する前に、古いチェックポイントを検査します。エージェントが長い会話に依存するなら、メッセージ形状の回帰テストをすべてのプロバイダーアップデートに組み込んでください。
