Difyコミュニティ、OpenAPIパラメーターの継承不具合を報告　カスタムツールが誤ったパスを送信する可能性

Difyコミュニティは9月26日、カスタムツールにOpenAPIドキュメントをインポートする際、パスレベルで宣言された共通パラメーターが欠落すると報告した。事例はバージョン1.17.1と表示されたセルフホスト環境のソースコードからで、mainブランチのコミット情報と最小構成の再現用仕様も添えられている。確認時点で、このIssueは未解決のままだった。[問題報告](https://github.com/langgenius/dify/issues/42994)

この事例では、`user_id` はGET操作内ではなく、`/users/{user_id}` の下にある `parameters` に記述されていた。報告によると、生成されたツールには対応する入力フィールドがなく、リクエストのパスにも変数を囲む波括弧が残り、指定した値に置き換わらなかった。Swagger 2.0形式に切り替えると、今度は `parameters` が操作として誤認され、`operationId` がないためインポートが拒否された。[再現の詳細](https://github.com/langgenius/dify/issues/42994)

この記述方法はOpenAPI 3.0の仕様に沿っている。パスレベルのパラメーターは、そのパスにあるすべての操作に適用される。操作レベルではパラメーターを上書きできるが、削除はできない。同じパラメーターかどうかは名前と位置の両方で判定する必要があるため、修正では2つのリストを単純に連結するだけでなく、上書きと重複も処理する必要がある。[OpenAPI仕様](https://spec.openapis.org/oas/v3.0.0.html#path-item-object)

Dify 1.17.1のパーサーを確認すると、ツールの作成時に各HTTP操作内のパラメーターだけを取得し、パスレベルの定義を事前に統合していないことが分かる。一方、Swaggerの変換処理はパスオブジェクトのすべてのキーを走査し、各項目に操作識別子があることを要求している。この2つの実装は、報告内容と一致する。[バージョン1.17.1のソースコード](https://github.com/langgenius/dify/blob/1.17.1/api/core/tools/utils/parser.py)

Difyの公式ドキュメントによると、OpenAPI仕様をインポートするとツールのインターフェースが自動生成され、ワークフローやエージェントから外部サービスを呼び出せる。したがって、この不具合により、正規の企業向けAPI定義をエージェントに接続する際に必要な入力が失われる可能性がある。調査では、変換後のフィールドと実際のHTTPリクエストを確認する必要があり、モデルが適切なツールを選んだかどうかだけでは判断できない。[ツールのドキュメント](https://docs.dify.ai/en/cloud/use-dify/workspace/tools)

エンジニアリングチームは、まずテスト用エンドポイントを使い、パスレベルと操作レベルのそれぞれで宣言した場合に、フィールドの生成とパラメーターの置換が同じ結果になるかを比較できる。仕様に沿った回帰テストには、名前は同じでも位置が異なるパラメーターや、操作レベルの定義で共通定義を上書きした場合の型と必須設定も含めるべきだ。同じ仕様を複数のツールで共有する場合は、各操作を個別に検証する必要がある。単一のエンドポイントでテストに通っても、仕様全体に互換性があるとは限らない。

報告者は修正と回帰テストがすでにあると述べているが、今回の確認では、変更がマージされたか、正式版が公開されたかは確認できなかった。現時点の証拠では、影響を受けるすべてのバージョンやクラウド環境の範囲も特定できない。今後は、メンテナーによる確認、修正のテスト、リリース記録を追う必要がある。[Issueの状況](https://github.com/langgenius/dify/issues/42994)