Agentic Jackal: Live Execution and Semantic Value Grounding for Text-to-JQL

この論文は、大規模な実稼働 Jira インスタンスに基づき自然言語から Jira 問い合わせ言語（JQL）への翻訳を評価する初のベンチマーク「Jackal」と、ライブ実行と意味的値の解決を組み合わせたエージェント型アプローチ「Agentic Jackal」を提案し、単一パスモデルの限界を克服する有効性を示したものです。

要約

この論文は、**「自然な言葉で指示すれば、自動的に複雑な検索クエリ（JQL）を作ってくれる AI」**をどうすればもっと賢く、正確にできるかという研究です。

まるで、**「注文した料理が厨房で正しく作られているか、実際に味見をして確認する」**ような仕組みを導入した話です。

以下に、専門用語を排して、身近な例え話で解説します。

---

🍽️ 物語の舞台：巨大なレストラン（Jira）

まず、Jiraというツールを想像してください。これは大企業が使う「プロジェクト管理ツール」で、まるで巨大なレストランの厨房のようなものです。

• ここには20 万個以上の注文（課題）があります。
• 料理の名前（「Bug」「機能追加」など）や、材料のバージョン（「Ver 6.5」など）は、お店（プロジェクト）によって全く異なる名前で呼ばれています。

JQLとは、この厨房から「Ver 6.5 のバグを全部出して！」と命令するための特殊な言語です。しかし、この言語は難しく、一般人には使いこなせません。

🤖 問題：「天才シェフ」の勘違い

研究者たちは、最新の AI（LLM）に「自然な言葉で注文して、JQL を作らせてみよう」と試しました。
しかし、従来の AI には2 つの大きな弱点がありました。

1. 「メニュー表」を見ていない
   • AI は「Ver 6.5」と言われても、そのお店に「6.5.0」という名前があるのか、「6.5.0 Beta」という名前があるのかを知りません。
   • 結果、AI は「たぶん 6.5 だろう」と勘で適当な名前を作ってしまい、厨房（Jira）に「そんな材料はありません」と言われて、何も見つからない（検索結果がゼロ）という失敗をします。
2. 「味見」をしない
   • AI が作った注文文を、厨房に実際に通して**「本当に正しい料理が出てくるか？」を確認しません**。
   • 間違った注文文でも、AI は「これで合ってるはずだ」と思い込んでしまい、失敗に気づきません。

これでは、複雑な注文や曖昧な指示（「あのバグっぽいもの」など）が出たときに、AI は全く役に立ちません。

---

🚀 解決策：「Agentic Jackal（アジェンティック・ジャッカル）」

そこで登場するのが、この論文が提案する**「Agentic Jackal」という新しい AI の仕組みです。
これは、AI に「実際に厨房に行って、試食して、間違っていたら直しに来る」**という能力を与えたものです。

1. 「味見係（Jira Search）」の導入

AI は JQL を作ったら、すぐに厨房（Jira）に投げかけます。

• 料理が出てきた？ → 「よし、正解！」
• 何も出てこなかった？ → 「あ、注文が厳しすぎるか、材料名が違うな。直そう。」
• エラーが出た？ → 「文法がおかしいな。直そう。」

このように、**「実際に試して、結果を見て修正する」**というループを回すことで、精度がぐっと上がります。

2. 「辞書係（JiraAnchor）」の導入

これが今回の最大のギミックです。
AI が「Ver 6.5」と言われたとき、厨房の**「実際のメニュー表（データベース）」を即座に検索して、「あ、このお店では『6.5.0 Beta』が正式名称なんだ」**と教えてくれる道具です。

• 以前： AI が「6.5」と勝手に推測して失敗。
• 今： AI が「JiraAnchor」に「6.5 に関連する正式名称は？」と聞き、**「6.5.0 Beta」**という正解を引き出して、正しい注文文を作ります。

---

📊 結果：どれくらい良くなった？

研究者は 9 種類の最先端 AI をテストしました。

• 従来の AI（味見なし）： 曖昧な注文だと、**43%**しか正解しませんでした。
• 新しい AI（味見＋辞書係）：
  • 全体の正解率が**64%**まで向上。
  • 特に「短い言葉で曖昧に指示された場合（Short NL）」では、**9%**も劇的に改善しました。
  • 部品（Component）の名前を特定するタスクでは、正解率が17%から66%へと4 倍近く跳ね上がりました！

つまり、「辞書係（JiraAnchor）」がいるだけで、AI の勘違いが激減し、厨房の混乱が防げることが証明されました。

---

💡 でも、完璧ではない（残りの課題）

しかし、このシステムも万能ではありません。
AI が失敗する原因の多くは、**「言葉の曖昧さ」**でした。

• 例： ユーザーが「バグ」と言ったとき、AI は「『Bug』というカテゴリの課題」を指しているのか、「『説明欄にバグと書いてある課題』」を指しているのか、文脈がないと判断できません。
• これは、どんなに優秀な「味見係」や「辞書係」がいても解決できない、人間の言葉の曖昧さに起因する問題です。

🌟 まとめ

この論文が伝えているのは、**「AI に『正解を推測させる』だけでなく、『実際に試して、失敗したら直させる』仕組み（エージェント）と、『現場の情報を即座に調べる道具（JiraAnchor）』を持たせること」**が、ビジネス現場での AI 活用には不可欠だということです。

まるで、**「勘で料理を作る見習い」を、「味見しながら、レシピ本（現場データ）を常にチェックする熟練のシェフ」**に変えたようなものですね。これにより、複雑な指示でも、確実に正しい結果が得られるようになりました。

技術概要

論文「Agentic Jackal: Live Execution and Semantic Value Grounding for Text-to-JQL」の技術的サマリー

この論文は、自然言語を Jira クエリ言語（JQL）に変換するタスクにおける課題を解決するため、ライブ実行と意味的値のグラウンディング（具体化）を組み合わせた新しいエージェント型アプローチ「Agentic Jackal」と、大規模な実行ベースのベンチマーク「Jackal」を提案したものです。

以下に、問題定義、手法、主要な貢献、結果、および意義について詳細をまとめます。

1. 背景と問題定義

自然言語からドメイン固有のクエリ言語への変換は、LLM の発展により進歩していますが、Jira などのエンタープライズ環境では以下の構造的な課題が存在します。

• 曖昧なフィールド参照と値の特定: JQL はプロジェクトやインスタンス固有のカスタムフィールド（コンポーネント名、修正バージョン等）を使用します。これらの値はインスタンスごとに異なり、モデルがトレーニングデータから推測することは不可能です。
• 単一パス生成の限界: 従来の単一パス（ワンショット）の LLM は、生成されたクエリが実際の Jira インスタンスで実行可能か、あるいは意図した結果を返すかを確認できません。
• 評価基準の欠如: 自然言語から JQL への変換を、ライブデータソースでの実行結果に基づいて評価するオープンなベンチマークが存在しませんでした。

これらの課題により、曖昧な表現や言い換えられたリクエストに対する精度が著しく低下していました。

2. 提案手法：Agentic Jackal と JiraAnchor

著者は、ツール拡張型マルチステップエージェント「Agentic Jackal」を提案しました。これは、Jira MCP サーバーと新しい検索ツール「JiraAnchor」を活用し、クエリの生成、実行、反復的改善を行うアーキテクチャです。

主要コンポーネント

1. Agentic Loop (エージェントループ):

   • LLM が JQL クエリを生成し、Jira MCP サーバー経由でライブインスタンスに対して実行します。
   • 実行結果（結果セットが空か、エラーメッセージがあるか、正常に返ってきたか）をフィードバックとして受け取り、クエリを修正・改善するループを回します。
   • これにより、モデルは推測ではなく、実際のデータに基づくフィードバックでクエリを最適化できます。

2. JiraAnchor (意味的フィールド値検索ツール):

   • 目的: 自然言語で言及されたカテゴリカル値（例：「バージョン 6.5」）を、実際の Jira インスタンスに存在する正確な値（例：「6.5.0」や「6.5.0 Beta1」）にマッピングします。
   • 仕組み: 指定されたフィールド（例：fixVersion）の全一意の値をライブ Jira から取得し、ユーザーの自然言語記述との類似性（埋め込みベクトルによるコサイン類似度、正規表現、近似文字列一致）に基づいて上位 K 個の候補を返します。
   • 特徴: 単一呼び出しで値を解決し、エージェントの複雑さを抑えつつ、値の曖昧さを解消します。

3. 主要な貢献

1. Jackal ベンチマークの公開:

   • 20 万以上のイシューを持つライブ Jira インスタンス上で検証された、10 万件の検証済み NL-JQL ペアを含む大規模な実行ベースベンチマーク「Jackal」を公開しました。
   • これには、1,000 クエリの層化された評価セット「Jackal-1K」も含まれます。

2. Agentic Jackal エージェントの提案:

   • Jira MCP サーバーと JiraAnchor を統合した、業界初のオープンなエージェント型ベースラインを確立しました。
   • 9 つの最先端 LLM に対して評価を実施し、すべてのエージェントのトランスクリプトと評価コードを公開しました。

3. JiraAnchor ツールの開発:

   • インスタンス固有のカテゴリカル値を解決するための新しい意味的検索ツールを提案し、テキストから JQL への変換における「値の曖昧さ解消」の失敗モードを直接解決しました。

4. エラー分類と分析:

   • 失敗原因を 6 つのカテゴリに分類し、値の解決エラーではなく、「問題タイプの解釈」「テキストフィールドの選択」「バージョンの混同」といった意味的解釈の曖昧さが主要な失敗要因であることを明らかにしました。

4. 実験結果

9 つの最先端 LLM（GPT-5, Claude, Gemini, Pixtral など）を用いた評価を行いました。

実験 1: 単一パス生成 vs エージェント型アプローチ (Jackal-1K)

• 全体精度: エージェント型アプローチは、9 つのモデル中 7 つで精度を向上させました。平均実行精度は 62.5% から 64.4% へ向上（+2.0%）。
• 言語的難易度: 最も言語的に曖昧なクエリ（Short NL）において、相対的に 9.0% の改善が見られました。
• 知見: 単一パスモデルは文字通りの翻訳では 90% 以上の精度を出しますが、言い換えられたクエリでは 30% 未満に低下します。エージェント型は、このギャップを埋めるのに有効です。

実験 2: JiraAnchor のアブレーション研究 (フィールド値評価セット)

• 値解決への影響: JiraAnchor を使用した場合、フィールド値解決の精度は 48.7% から 71.7% へ大幅に向上しました（+23.0%）。
• コンポーネントフィールド: 特に「コンポーネント」フィールドにおいて、JiraAnchor なしでは 16.9% だった精度が、使用により 66.2% へと劇的に改善しました。
• モデル別: 全 9 モデルが JiraAnchor によって精度向上を示しました。

エラー分析

• 主要な失敗原因は、ツールで解決できる「値の不一致」ではなく、自然言語の曖昧さに起因する「意味的解釈エラー」であることが判明しました。
  • Short NL: 失敗の 58% が意味的解釈エラー（問題タイプ、テキストフィールド、バージョンの混同）。
  • Semantically Similar: 失敗の 68% が同様の解釈エラー。
• これは、将来的な研究が「値の解決」だけでなく、「意図の曖昧さ解消（ユーザーによる明確化など）」に焦点を当てるべきであることを示唆しています。

コスト分析

• エージェント型アプローチは、単一パス生成に比べてレイテンシが約 7 倍、トークン使用量が約 15 倍増加します。
• しかし、多くのクエリは 1 回の生成 - 実行サイクルで解決され、実用的なトレードオフとして許容範囲内と判断されています。

5. 意義と結論

この研究は、テキストから構造化クエリへの変換において、**「ライブ実行によるフィードバックループ」と「実データに基づく値のグラウンディング」**の両方が不可欠であることを実証しました。

• 実用性: エンタープライズ環境における Jira 検索の自動化において、単なる生成モデルではなく、ツールを駆使して検証・修正を行うエージェント型アプローチの有効性を示しました。
• 将来展望: 現在の主要なボトルネックは値の解決ではなく、自然言語の曖昧さの解釈にあるため、今後の研究ではユーザーとの対話による意図の明確化や、より高度な文脈理解が重要であると結論付けています。

総じて、Agentic Jackal は、自然言語インターフェースのエンタープライズ適用における新たな基準（ベンチマーク）と技術的アプローチを提供し、実世界での複雑なクエリ生成タスクの精度向上に大きく寄与するものです。