TL;DR
LLMエージェントが業務APIを多段で呼ぶ際は、正しいエンドポイントだけでなく「次に何をするか」「どのキー・コード値が有効か」が重要になる。本論文はODataメタデータとBPMNを型付きプロパティグラフに統合し、密検索の候補をプロセス辺で展開、値ヘルプやカーディナリティを実行時に渡す。低語彙重複クエリでRecall@3を5.7ポイント改善（n=74）、81件の多段タスク完了率38.7%（チャンク基線10.3%）、型付き文脈で無効呼び出し3%（101回中3回）を報告。ただしBPMNと活動対応付けは人手で、プロセス層のないAPIには効かず、完了率も限定的。
既存手法との違い
原論文の比較は主に2系統ある。検索では密埋め込み検索を基準に、プロセス辺による展開を追加評価し、語彙重複が低いクエリでRecall@3が5.7ポイント改善（n=74）、それ以外では密検索と同等、プロセス層のないOpenAPIサービスでは改善なしと報告する。実行ではチャンクベースのベースラインに対し、81件の多段クエリで完了率38.7%対10.3%。また値リストを平文で与える条件ではコードの捏造は消えるが書き込み実行の46%で不正キーが残り、型付き文脈全体では無効呼び出し3%（101回中3回）だった。Discovery Agentなど既存研究はエンドポイント検索止まりで、実行やプロセス鎖の正解評価がない、との位置づけ。
使える条件
ODataの$metadataとBPMN 2.0の参照プロセスがあり、活動とEntitySetの対応付けを人手で用意できることが前提。評価はSAP Business Accelerator Hubの公開記述を用いた42サービス・14 BPMNプロセス・288クエリ（OData-Proc）と81件の多段クエリで、実SAP環境ではなくモックHTTP層で検証している。FalkorDBとFAISS、複数の埋め込みモデルを使用。実運用のSAP接続、他ERP・他API標準、BPMN自動生成、大規模カタログでの構築コストは提示本文からは確認できない（未知）。
限界と未検証の範囲
プロセス層と活動→EntitySet対応は人手で、14プロセス・51タスク活動・45対応辺に限定される。10活動は意図的に未対応。BPMNのゲートウェイ・イベント・プールは無視している。プロセス層のないOpenAPIサービスでは改善せず、汎用グラフ構造だけでは検索改善がない。無効呼び出しは型付き文脈でも3%（101回中3回）残り、完了率38.7%で失敗も多い。評価は公開メタデータとモックHTTPで、実SAPや他業界・他標準への一般化、運用時の構築・保守コストは未検証。
解説
ねえ智也くん、この論文って結局なにがうれしいの？ 業務APIをLLMエージェントが呼ぶ話らしいけど。
ざっくり言うと、正しいエンドポイントを選ぶだけじゃ足りないって話。業務APIは順番と、使えるキーやコード値まで守らないと失敗する。
そっか。フライト予約してからホテル、みたいに次の操作が決まってるやつだね。
そう。既存の検索はエンドポイントを独立に見るから、プロセスの順番やスキーマ制約を取りこぼす。
論文の出発点はそこなんだ。
うん。ODataのメタデータとBPMNの参照プロセスを、型付きプロパティグラフにまとめてる。
ODataは項目の説明、BPMNは作業の順番。それを一つのグラフに入れると。
そう。検索は密埋め込みで候補を出して、プロセス辺をたどって次のエンドポイントを展開する。取得した各エンドポイントには値ヘルプやカーディナリティも付く。
ReActエージェントがそれを使ってGETやPOSTを組み立てるんだね。
検証はモックHTTP層でやってる。実SAPにつないでるわけじゃない。
比較はどうなってるの？
検索は密検索が基準。低語彙重複のクエリでRecall@3が5.7ポイント改善、n=74。ほかのクエリでは密検索と同等で、プロセス層のないOpenAPIサービスでは改善なし。
じゃあグラフ一般がすごいんじゃなくて、プロセス構造があるときが効くんだ。
そこは論文も明確にしてる。汎用のグラフ構造だけでは検索は改善しない、と。
実行の比較は？
81件の多段クエリで、完了率が38.7%。チャンクベースのベースラインは10.3%。
38.7%でもまだ失敗が多いんだ。
値リストを平文で渡すと、コードの捏造は消えるけど、書き込み実行の46%で不正キーが残る。型付き文脈全体だと無効呼び出しは3%、101回中3回で、捏造コードはゼロ。
そこはかなり効いてるね。値ヘルプとカーディナリティを実行時に渡すのがポイントか。
意義は、検索の精度だけでなく、実行時の制約を文脈として渡して信頼性を上げたこと。既存研究はエンドポイント検索止まりだったり、単発や短い連鎖が中心だったりする。
Discovery Agentはランキングまでで実行しないし、プロセス鎖の正解評価もない。今回は検索と実行の両方を見てる点が違う。
使える条件も気になる。
ODataの$metadataとBPMN 2.0の参照プロセスがあって、活動とEntitySetの対応付けを人手で用意できるのが前提。評価は公開カタログの42サービス、14 BPMNプロセス、288クエリで、FalkorDBとFAISS、複数の埋め込みモデルを使ってる。
制限は？
BPMNと活動対応は人手で、14プロセス・51タスク活動・45対応辺に限定。10活動は意図的に未対応。ゲートウェイ、イベント、プールは無視してる。
プロセス層のないAPIには効かないし、完了率も限定的なんだね。
あと実SAP接続や他ERP・他API標準への一般化、BPMN自動生成、大規模カタログの構築コストは、提示された本文からは確認できない。
記事の解釈としても、実装や追試をしたわけじゃなくて、論文の報告を読んでるだけだよね。
そう。原論文の報告と、ここでの会話上の整理は分けて見る必要がある。
じゃあ、私の予定管理APIにも『次はこれ』ってプロセス辺を付けてほしいな。
その前に自分のタスクをBPMNで書け。