技術要約：Web API統合コード生成のベンチマーク

問題提起

Web APIの統合は現代のソフトウェアインフラストラクチャにおける基本要素であるが、これらのAPIを呼び出すための正しいコードを記述することは、開発者にとって依然として困難かつ退屈な作業である。大規模言語モデル（LLM）はソフトウェア開発の自動化において大きな可能性を示しているが、Web API呼び出しコードの生成における具体的な有効性は、これまでほとんど調査されてこなかった。ローカルの関数呼び出しとは異異なり、Web APIの呼び出しには、特定のHTTPメソッド、パラメータ化されたURL、リクエストボディ、ヘラダー、およびクエリパラメータを含む複雑な構文が伴う。これらは外部仕様（OpenAPIなど）に記載されているが、モデルのコンテキストウィンドウ内で必ずしもアクセス可能であるとは限らない。

本研究が取り組む中心的な問いは、「LLMが生成したWeb API呼び出しコードはどの程度正確であり、どのような種類の誤りが一般的に含まれているのか？」というものである。

手法

この問いに答えるため、著者らは、この領域におけるLLMの能力を体系的に評価するために設計された、新しいデータセットおよび評価パイプラインであるWAPIIBenchを導入する。

1. データセットの作成 (WAPIIBench)

このデータセットは、OpenAPI標準に準拠した4つの実世界のAPI（Asana、Google Calendar、Google Sheets、Slack Web）から派生した395個のタスクと構成のペアで構成されている。

• 合成: 既存のリポジトリからソースを取得する場合（多くの場合、曖昧でないタスク記述が欠如している）とは異なり、著者らはGemini 1.5 Proを使用してタスクを合成した。モデルには完全なOpenAPI仕様と詳細な指示が提供され、自然言語によるタスク記述（$t$）と、対応するグラウンドトゥルース（正解）のリクエスト構成（$c$）を生成させた。
• 検証: 生成されたデータは、すべてのタスクが一意で解決可能な構成を持ち、引数が正しく反映されていることを保証するために、厳格な自動および手動によるキュレーションが行われた。
• 構造: 各サンプルは、HTTPメソッド、URL、および引数（ボディ、ヘッダー、クエリパラメータ）を捉えたAPIエンドポイントを表している。

2. 評価パイプライン

評価は以下の4段階のプロセスに従う：

1. コード生成: LLMは、タスク記述に基づいてスターターコード（Axiosライブラリを使用したJavaScript）を完成させるよう求められる。2つの設定がテストされた：
   • フル補完 (Full Completion): モデルはHTTPメソッド、URL、およびすべての引数を生成しなければならない。
   • 引数補完 (Argument Completion): モデルには正しいメソッドとURLが提供され、引数のみを生成しなければならない。
2. コード実行: 生成されたコードは、外部へのリクエストをインターセプトする制御されたサンドボックス環境（Mock）内で実行される。このアプローチは、構文的な類似性よりも機能的な正確性を優先し、コードによって実際に送信されたリクエスト構成（$c'$）を捕捉する。
3. 正確性分析: 捕捉された構成（$c'$）は、グラウンドトゥルース（$c$）と比較され、API仕様（$s$）に対して検証される。
4. メトリクス: 本研究では、以下の詳細なメトリクスを採用している：
   • 正しい実装 (Correct Implementations): グラウンドトゥルースと一致する実行可能なコードの割合。
   • 不正な実装 (Illegal Implementations): API仕様に違反しているコード。
   • URL/メソッドの正確性: エンドポイントおよびHTTPメソッドの正確性。
   • 引数の適合率/再現率 (Argument Precision/Recall): パラメータ名および値の正確性。

3. 評価されたモデル

このベンチマークでは、性能のベースラインを確立するために、21の最先端のオープンソースLLM（StarCoder、DeepSeek-Coder、Qwen-Coder、Code Llama、Llama 3.1を含む）とともに、商用モデル（GPT-4oおよびGPT-4o mini）を評価した。

主な結果

実験の結果、Web API呼び出しの正しいコードを生成することは、最も有能なオープンソースモデルにとってさえ、現在のLLMにとって大きな課題であることが明らかになった。

• 全体的な正確性: 評価されたオープンソースモデルの中で、40%以上のタスクを解決できたものはない。
  • フル補完の設定では、最良のオープンソースモデル（Code Llama 70B）は**30%の正確性を達成し、GPT-4oは60%**に達した。
  • 引数補完の設定（エンドポイントが既知の場合）では、Code Llama 70Bは**40%に向上し、GPT-4oは77%**に達した。
• エラーの種類:
  • ハルシネーションによるエンドポイント: 主要な失敗モードは、不正確または存在しないURLの生成である。フル補完の設定では、最大**39%**のURLが不正であった。
  • 引数のエラー: モデルは頻繁にパラメータ名をハルシネーション（最大**31%**の不正な引数）したり、必須の引数を欠落させたりする。
  • 実行失敗: いくつかのモデル（例：Qwen2.5-Coder、Llama 3.1）は、構文エラーやコードの補完拒否により、フル補完の設定において実行不可能なコードを生成し、その結果、それらのモデルの正確性メトリクスは0%となった。
• モデルの挙動:
  • モデルは一般に、HTTPメソッド（GET/POST）の予測には優れているが、URLや引数の制約のない性質に対しては苦戦する。
  • 大きなモデルが必ずしも小さなモデルよりも優れているわけではない。一部のファミリーでは、中規模のバリアントが、より小さいバリアントおよびより大きいバリアントの両方よりも性能が低い場合があった。
  • パフォーマンスは異なるAPI間で大きく異なり、これはおそらくモデルのトレーニングデータにおける特定のAPIの普及率と相関している。

重要性と貢献

本論文は、ソフトウェアエンジニアリングおよびAIの分野に対して、主に3つの貢献を行っている：

1. WAPIIBenchデータセット: 4つの実世界のAPIにわたる、約400組のWeb API呼び出しタスクと期待される結果を含む、この種では初のデータセットであり、実行ベースの正確性分析のために特別に設計されている。
2. オープンソース評価パイプライン: 構文的な正確性、仕様への準拠、および機能的な成功を区別する詳細なメトリクスを用いて、Web APIタスクに関するコード生成モデルを評価するための、新しく安全で自動化されたパイプライン。
3. 経験的な洞察: 本研究は、LLMがAPI仕様に関する記憶された知識をある程度持っている一方で、外部コンテキストなしでは、この知識を正しく仕様に準拠した呼び出しへと合成することに苦労しているという、最初の体系的な証拠を提供している。エンドポイントや引数のハルシネーション率の高さは、現在のモデルの信頼性における決定的なギャップを浮き彫りにしている。

著者らは、LLMには有望な点があるものの、重大な限界が残っていると結論づけている。彼らは、Web API統合コードの正確性と信頼性を確保するために、AI駆動のコード生成ワークフローに品質保証技術（検索拡張生成、ファインチューニング、または制約付きデコーディングなど）を統合する必要性を強調している。このベンチマークは、これらの能力を向上させるための将来の研究の基礎となるものである。