本研究は、OpenAPI仕様に基づきURL、HTTPメソッド、および各種パラメータ（path, query, header, body）を構成する必要があるWeb API呼び出しコード生成において、LLMが陥るハルシネーションや仕様違反を解決することを目的としている。評価には、AsanaやSlack等のAPIを含む395タスクからなる合成データセット「WAPIIBench」と、GitHubからAxiosベースの呼び出しを収集した11種類のAPIを含む新規の実世界データセットの2種類を用いている。実世界データセットでは、パラメータが変数や定数として渡される複雑な構造に対応するため、実行時に適切なデータ型を注入する手法などが導入されている。
第一に、OpenAPI仕様書からエンドポイント単位の情報を抽出し、TypeScriptの型宣言にインスパイアされたコンパクトなフォーマットでプロンプトに注入するRAGフレームワークを提案している。第二に、OpenAPI仕様から正規表現ベースの制約を自動生成し、生成プロセス中にHTTPメソッドやURL、パラメータの依存関係を強制するConstrained Decoding (CD) 手法を提案している。実験により、CDが合成データセットにおいて正解率を平均 $+209\%$ および $+143\%$ 向上させ、不正なURLや引数の生成をゼロに抑えることを示した。さらに、RAGとCDを組み合わせることで、合成データセットにおいてハルシネーションをゼロに抑制しつつ、大幅な正確性の向上を実現できることを明らかにした。
RAG手法では、`all-MiniLM-L6-v2`を用いた埋め込みとChromaによる近似最近傍探索を採用し、各チャンクが自己完結するように参照のインライン化等の前処理を施している。検索精度向上のため、エンドポイントの記述範囲を変えた5種類のバリエーションを保持することで、top-1精度 $75.7\%$、top-5精度 $95.2\%$ を達成している。CD手法では、開始・停止条件と本体を持つモジュール化された「生成ルール」の集合を構築し、正規表現のキャプチャグループや否定の先読み（negative lookahead assertions）を用いて、必須パラメータの欠落や二重定義を防止する。この制約は、JavaScript/Axiosの構文規則やパラメータのネストといった複雑な構造を階層的な正規表現として捉えるものである。
評価は、24のオープンソースLLMおよびGPT-4o/miniを用い、Full completionとArgument completionの2つのタスク設定で実施された。合成データセットのFull completionにおいて、Vanilla設定の平均正解率が13%と低迷したのに対し、CDは正解率を大幅に向上させた。実世界データセットの検証では、34個のOpenAPI仕様書のパースに成功し、125個のテストケースを用いたスイートですべての制約が意図通りに機能することを確認している。また、RAGとCDの併用により、合成データセットで最大 $+332\%$ の正解率向上を記録した。
RAGはエンドポイントの選択を助けハルシネーションを減少させるが、検索された不要なパラメータを過剰に生成してしまう傾向があり、正解率への影響はモデルや条件により一貫しない。CDは高い正確性を保証する一方で、モデルの次トークン確率分布を歪める可能性があり、一部のモデルでは実行可能性が低下するという限界がある。また、CDはAPI呼び出しの範囲内での局所的な制約に留まるため、引数として渡される変数（リテラルではない値）の型や値までは制御できない。今後の課題として、セキュリティ特性への拡張や、特定の言語・ライブラリに依存しない汎用的な手法の探求が挙げられている。
本研究では、LLMによるWeb API呼び出しコード生成の誤りを軽減するため、Retrieval-Augmented Generation (RAG) と Constrained Decoding (CD) という2つの補完的な手法を提案している。RAG手法では、OpenAPI仕様書を処理してコンパクトなエンドポイント表現を抽出・取得し、プロンプトに注入するリトリーバーを設計している。一方、CD手法では、OpenAPI仕様書から正規表現ベースの制約へと自動変換を行い、生成プロセス中に制約を強制する。評価は、既存の合成データセットであるWAPIIBenchおよびGitHubリポジトリから構築した新しい実世界のデータセットを用いて行われた。実験結果によれば、RAGは完全なAPI呼び出しの生成においてハルシネーションを抑制し正確性を向上させる一方で、エンドポイントが既に提供されている場合には不要なパラメータの生成を促してしまう。対照的に、CDは不正なURL、HTTPメソッド、および引数の生成を確実に防止し、スターターコードの有無に関わらず全体的な正確性を大幅に向上させることが示された。
本研究は、OpenAPI仕様に基づきURL、HTTPメソッド、パラメータ（path, query, header, body）を構成する必要があるWeb API呼び出しコード生成において、LLMが陥るハルシネーションや仕様違反を軽減することを目的としている。手法として、OpenAPI仕様から関連情報を抽出するRetrieval-Augmented Generation (RAG) と、仕様に準拠した生成を強制する正規表現ベースのConstrained Decoding (CD) を提案し、それらの相乗効果を調査している。評価には、WAPIIBenchの合成データセットと、GitHubからAxiosベースの呼び出しを収集した11種類のAPIを含む新規の実世界データセットの2種類を用いている。実験結果によれば、CDは合成データセットにおいて正解率を平均 $+209\%$ および $+143\%$ 向上させ、不正なURLや引数をゼロに抑える高い効果を示した。RAGはハルシネーションを減少させるものの、不要なパラメータを生成しすぎる傾向があり、正解率への影響はデータセットや条件により一貫しない。両者を組み合わせた手法は、合成データセットで最大 $+332\%$ の正解率向上を達成し、ハルシネーションをゼロに抑制できるが、CD単体と比較すると正解率の向上幅にばらつきが見られるという限界も示されている。
本セクションでは、Web API呼び出しの生成における背景知識として、APIの構造、評価ベンチマーク、RAG、および制約付きデコーディングについて述べている。Web APIはHTTPメソッドとURLの組み合わせで識別されるエンドポイントを持ち、OpenAPI仕様に基づき、パス、クエリ、ヘッダー、リクエストボディなどの多様なパラメータ構造を持つ。評価には、Asana、Google Calendar、Google Sheets、Slackの4つのAPIからなる395タスクを含むWAPIIBenchを使用し、コード生成、制御環境下での実行、および正解の構成（URL、メソッド、引数）との比較による正確性分析の3段階で評価を行う。RAGは、知識ベースから関連するチャンクを検索してプロンプトを拡張することで、モデルの記憶への依存を減らし信頼性を高める手法である。一方、制約付きデコーディング（CD）は、正規表現や文脈自由文法を用いて、LLMの次トークン予測時にコンプリーションエンジンがトークンマスクを適用することで、定義された制約に従うトークンのみをサンプリング可能にする技術である。
本手法は、OpenAPI仕様書から抽出したエンドポイント単位の情報をベクトルストアに格納し、タスク記述をクエリとして類似度検索を行うRAGフレームワークを提案している。API仕様の文脈依存性を考慮し、各チャンクが自己完結するように、参照のインライン化やセキュリティスキーム・パスレベルパラメータの各エンドポイントへのコピーを行う前処理を施している。検索精度向上のため、`all-MiniLM-L6-v2`を用いた埋め込みとChromaによる近似最近傍探索を採用し、さらにエンドポイントの記述範囲を変えた最大5種類のバリエーションを各チャンクに持たせることで、top-1精度 $75.7\%$、top-5精度 $95.2\%$（重複除去後）を達成している。LLMへの注入に際しては、コンテキスト長超過を防ぐための切り詰め処理を行うが、トークン効率を高めるためにJSONやYAMLではなく、TypeScriptの型宣言にインスパイアされた独自のコンパクトなフォーマットを採用している。
本セクションでは、OpenAPI仕様書から正規表現（regex）ベースの制約を自動生成し、LLMによるWeb API呼び出しの正確性を担保する制約付きデコーディング（Constrained Decoding）のフレームワークを提案している。提案手法の核心は、HTTPメソッド、URL、パラメータ間の相互依存性や、JavaScript/Axiosの構文規則、およびパラメータの順序やネストといった複雑な構造を、階層的な正規表現として変換する点にある。制約は単一の巨大な正規表現ではなく、開始条件（start condition）、停止条件（stop condition）、本体（body）を持つモジュール化された「生成ルール（generation rules）」の集合として構成され、複数のルールが重なり合うことで柔軟な制約のオーケストレーションを実現している。具体的には、正規表現のキャプチャグループを用いて定義済みパラメータを追跡し、条件付きパターンや否定の先読み（negative lookahead assertions）を用いることで、必須パラメータの欠落や二重定義を防止している。実験的な検証として、34個の実世界のOpenAPI仕様書のパースに成功し、さらに125個のテストケース（正例および負例）を用いたテストスイートにおいて、すべての制約が意図通りに機能することを確認している。
本研究では、従来の合成データセットであるWAPIIBenchを補完するため、GitHubのリポジトリから抽出した実世界のWeb API呼び出しに基づく新しいデータセットを構築した。BigQueryを用いてAxiosライブラリをインポートしているJavaScriptファイルを検索し、OpenAPI仕様が存在し、かつAPIの特定が可能なものを手動で選別した結果、11種類のAPIにわたる28個のタスク（18個のファイルから構成）を構築した。実世界データセットでは、スターターコードの長さが4行から163行と多様であり、合成データセットとは異なり、APIパラメータがリテラルではなく変数や定数として渡されるという特徴を持つ。この変数への対応として、実行時に適切なデータ型のランダムなインスタンスを注入する手法や、`ReferenceError`を最小化するために注入する定義集合を反復的に拡張する手法を導入している。また、サーバー変数やパスパラメータを含む複雑なURL構造に対応するため、生成されたURLの正規化や、文字列補完および結合を用いた制約付きデコーディングの拡張を行っている。この拡張により、WAPIIBenchは多様なファイルレベルのコンテキストやAPI固有の特性に対して、より柔軟かつ堅牢な評価が可能となった。
本セクションでは、Web API呼び出しコード生成における4つの生成設定（Vanilla, RAG, CD, RAG + CD）と2つのタスク設定（Full completion, Argument completion）を用いた評価実験が詳述されている。実験では24のオープンソースLLMとGPT-4o/miniを使用し、正解率（Correct implementations）、エンドポイントの幻覚（Hallucinated endpoints）、引数の幻覚（Hallucinated implementations）、実行可能性（Executable implementations）を指標とした。結果として、Vanilla設定では合成データセットのFull completionにおいて平均正解率が13%と低迷し、多くのモデルが構文エラーを起こすことが示された。RAGはエンドポイントの選択を助け幻覚を大幅に減少させるものの、モデルが検索された不要な引数を過剰に含めてしまう傾向があるため、正解率がモデルによって大きく変動し、場合によっては低下する。一方で、Constrained Decoding (CD) はすべてのモデルにおいて一貫して正解率を向上させ、合成データのFull completionでは正解率を209%向上させ、Argument completionではCode Llama (70B) が72%の正解率を達成してGPT-4oを上回る結果となった。ただし、CDはモデルの次トークン確率分布を歪める可能性があるため、一部のモデルでは実行可能性が低下するなどの限界も観察されている。
本研究では、RAG（Retrieval-Augmented Generation）とCD（Constrained Decoding）がWeb API呼び出しコードの生成におけるエラーやハルシネーションの抑制に有効であることを示したが、実装上の課題として、RAGはチャンクサイズやリトリーバル数などのパイプラインにおける膨大なハイパーパラメータの調整が必要であり、特定のモデルへの過学習のリスクがある。一方、CDは制約設計の難しさが課題であり、正規表現や文法で表現困難なルールへの対応や、モデルの柔軟性を損なう「過剰な制約」と、誤生成を許容する「不十分な制約」のトレードオフが存在する。評価の限界として、RAGの設計空間の広さがモデル間で非一様な影響を与えることや、OpenAPI仕様書の参照解決をチャンク肥大化防止のために限定的な深さに留めていることが挙げられる。また、CDはAPI呼び出しの範囲内での局所的な制約に留まるため、引数として渡される変数（リテラルではない値）の型や値までは制御できない。さらに、提案手法は実行不可能なコードをわずかに増加させる傾向があり、WAPIIBenchの実行ベースの評価指標では、これらが正解率やハルシネーションの数値に適切に反映されないという側面がある。
本研究は、OpenAPIで記述された一般的なRESTful web APIの呼び出し生成におけるエラー軽減を目的としており、既存研究が対象とするドメイン特化型API、SDKラップ型、ローカル関数、あるいはAIエージェント用のツール利用とは異なる、HTTPメソッドやエンドポイント、リクエスト構成要素（path, query, headers, body）を明示的に構築する必要がある複雑な設定を扱う。RAG（Retrieval-Augmented Generation）の観点では、OpenAPI仕様書からのドキュメント検索を導入しているが、エンドポイントによるスコープ設定や参照の解決といった、文脈を維持するための特殊なチャンク作成手法や、トークン効率と理解度を最適化するカスタム出力フォーマットを提案している点が、既存のローカル関数向けRAG研究と異なる。制約付きデコーディング（Constrained Decoding）においては、構文的な正当性や型システム、あるいは言語サーバーに基づく既存手法がローカルAPIに限定されているのに対し、本研究は外部仕様に基づき、Web API呼び出しの構造を捉えてハルシネーションを防ぐ制約を導入する初の試みである。手法の比較として、RAGは実装が容易だがプロンプトの肥大化のリスクがあり、制約付きデコーディングは保証を提供できる一方で柔軟性に欠け推論コストが増大する、ファインチューニングは計算コストが高くデータが陳腐化しやすい、反復的な洗練（Iterative Refinement）はトークン消費が激しいといった特性を挙げ、これらを代替ではなく補完的なものとして捉えるべきだと論じている。
本研究では、LLMによるWeb API呼び出しコード生成の課題に対し、OpenAPI仕様書からエンドポイント単位のチャンクを抽出・注入するRetrieval-Augmented Generation (RAG) と、仕様書から正規表現による制約を導出するConstrained Decoding (CD) を提案した。WAPIIBenchの合成データセットおよびGitHubリポジトリから構築した実データセットを用いた評価の結果、RAGとCDは共にエンドポイントや引数のハルシネーションを抑制し、生成の正確性を向上させることが示された。特にCDはハルシネーションの不在を保証できる一方で、RAGの有効性はモデルやタスクに強く依存するという特性がある。RAGとCDの併用は一部のモデルで正確性を高めるが、他のモデルでは逆に低下させる場合もあり、両手法の統合には注意が必要である。今後の展望として、これらの手法をセキュリティ特性などの広範な品質基準へ拡張することや、JavaScript/Axiosに限定されない言語・ライブラリに依存しない手法の探求が挙げられる。