ICLR 2026 のワークショップ論文として発表

QuanBench+: LLM（大規模言語モデル）ベースの量子コード生成のための統合型多フレームワークベンチマーク

Ali Slim, Haydar Hamieh, Jawad Kotaich, Yehya Ghosn, Mahdi Chehimi, Ammar Mohanna, Hasan Abed Al Kader Hammoud, Bernard Ghanem — American University of Beirut & KAUST

大規模言語モデルは、コード生成においてますます利用されるようになっていますが、量子コード生成は依然として、主に単一のフレームワーク内で評価されています。QuanBench+ は、Qiskit、PennyLane、および Cirq を網羅する、統合されたベンチマークを紹介しており、量子アルゴリズム、ゲート分解、および状態準備をカバーする42のタスクが含まれています。実行可能な機能テスト、KLダイバージェンスに基づく受容基準、およびフィードバックに基づく修正を使用することで、本研究は、信頼性の高いマルチフレームワーク量子コード生成が、依然として未解決の課題であることを明らかにしました。

59.5% Best Pass@1 (Qiskit)

83.3% フィードバック後の最高スコア

42 整合タスク数

LLM Quantum Programming Benchmarking Qiskit PennyLane Cirq

Read on arXiv ↗

はじめに

LLM（大規模言語モデル）は、HumanEvalのような従来のコード生成ベンチマークにおいて目覚ましい成果を上げていますが、量子コード生成は独自の課題を提示します。 従来のプログラムが決定的な出力をもたらすのに対し、量子プログラムは確率的な測定統計をもたらします。量子ビットは重ね合わせの状態 \(|\psi\rangle = \alpha|0\rangle + \beta|1\rangle\) で存在し、正確な値ではなく、出力分布の観点から正しさが定義される必要があります。

量子コードが他のコードと異なる点は何ですか？

従来のプログラミングでは、同じ入力で関数を2回実行すると、同じ出力が得られます。量子プログラムは異なります。量子プログラムは、固定された答えではなく、確率分布を生成します。これは、特別に重み付けされたサイコロを振るようなものです。プログラムは重みを定義しますが、各実行で異なる結果が得られます。つまり、単純に出力と期待される出力が等しいかどうかをチェックすることはできません。代わりに、結果の分布が期待される値に十分に近いかどうかを検証するために、統計的な手法が必要です。

いくつかの量子コードのベンチマークが存在します (Qiskit HumanEval, QHackBench, QCircuitBench, QuanBench)。しかし、ほとんどが単一のフレームワーク内でのみモデルを評価します。これにより、失敗が量子計算の理解不足によるものなのか、特定のAPIに慣れていないことが原因なのかを判断することができません。

マルチフレームワークのベンチマークは、2つの異なる種類の失敗モードを明らかにするために不可欠です。(i) 量子計算の概念的な誤り—例えば、誤ったアルゴリズム構造や測定ロジックなど—と、(ii) フレームワーク固有のAPIエラー—例えば、存在しないメソッドの呼び出しや、パラメータの不適切な使用など—です。

主な貢献

統合されたマルチフレームワークベンチマーク — Qiskit、PennyLane、およびCirqにまたがる42のタスクを連携させ、各フレームワークで同一の量子問題をテストできるように設計されています。
実行可能な機能テスト — Pass@1、Pass@5、およびKLダイバージェンスに基づく許容度を利用した自動評価による、確率的な出力に対する評価。
フィードバックに基づくモデルの評価方法 — モデルが、実行時エラーメッセージや誤った回答フィードバックを受け取った際に、どの程度改善されるかを測定する方法。
12種類の最先端LLMを評価 — GPT 5.1、DeepSeek R1、Claude 3.7 Sonnet、Gemini 3 Proなどをはじめ、その他も含まれます。

方法論

正確性評価指標

Pass@k は、機能的な正しさを評価する指標です。モデルは k 個のコードサンプルを生成し、そのうち少なくとも1つが正しい出力を生成した場合に合格となります。Pass@1 は、単一回の試行での精度をテストし、Pass@5 は、モデルに5回の試行回数を与えます。

KL-Divergence Acceptance は、確率的な量子出力を取り扱います。量子測定は本質的に確率的であるため、正確な出力の一致は機能しません。代わりに、QuanBench+ は、参照分布とモデルの出力分布との間の KL ダイバージェンス \(D_{KL}(P_{\text{ref}} \| P)\) を計算します。ダイバージェンスが閾値 \(\tau = 0.05\) (ヌル分布の 0.997 分位数で調整) を下回る場合、出力は受け入れられます。

KL-ダイバージェンスの平易な説明

KL-ダイバージェンスは、2つの確率分布がどれだけ異なるかを測る指標です。例えば、あるコインが表が出る確率が60%であるとします。もしモデルの量子プログラムが表が出る確率を58%にした場合、KL-ダイバージェンスは非常に小さく（一致度が高い）、良い結果です。しかし、表が出る確率が90%の場合、KL-ダイバージェンスは大きくなり（一致度が低い）、良い結果ではありません。QuanBench+では、0.05ナッツの閾値を使用しており、その差がこのレベルを下回る場合、出力は正しいと見なされます。この閾値は慎重に調整されており、たとえ全く同じ正しいプログラムを2回実行しても、サンプリングノイズによりわずかな違いが生じる可能性があります。その自然な変動範囲をわずかに上回る位置にこの閾値が設定されています。

なぜ忠実度ではないのか？ 状態忠実度（state fidelity）は、完全な量子状態ベクトルへのアクセスを必要としますが、これは実際の量子ハードウェアでは利用できません。QuanBench+は、意図的に実際の量子デバイスでも機能する、測定に基づく正確性の基準を使用しています。

QuanBench+ benchmarking workflow — **図1:** QuanBench+ のベンチマークワークフロー — フレームワークを選択し、OpenRouter 経由で API リクエストを送信し、コードレスポンスを解析し、隔離されたサンドボックスで実行し、標準的なソリューションに対して検証します。

タスクのカテゴリ

31 量子アルゴリズム

6 ゲート分解

5 状態準備

Qiskit、PennyLane、およびCirqの42個すべてのタスクは、標準化されたプロンプトと出力正規化によって整合性が保たれています。タスクには、Groverの探索アルゴリズム、Shorのアルゴリズム、量子フーリエ変換、VQEなどの古典的なアルゴリズム、ゲート分解の課題、および量子状態準備の問題が含まれます。各タスクは、決定的なシード制御を備えた、隔離されたサンドボックス環境で評価されます。

結果

なぜ、同じAIが異なるフレームワークで異なるスコアを示すのか？

こう考えてみてください。Qiskit、PennyLane、そしてCirqは、すべて同じ量子演算を記述する、しかし異なるプログラミング言語のようなものです。Qiskitのコード例から主に量子プログラミングを学んだAIは、Qiskit APIをよく理解しているでしょうが、PennyLaneの異なる関数名や規約には苦労するでしょう—たとえ同じ量子アルゴリズムであっても。

例えば、単純な量子NOTゲートを作成する場合、Qiskitではqc.x(0)ですが、PennyLaneではqml.PauliX(wires=0)です。概念は同じですが、コードは全く異なります。Qiskitのスコア（59.5%）とPennyLaneのスコア（42.9%）の差は、LLMがAPIのパターンを単に暗記しているだけで、量子コンピューティングを真に理解しているわけではないことを示唆しています。

クロスフレームワークパフォーマンス（RQ1）

最高のワンショットスコア： Qiskit 59.5% (GPT 5.1), Cirq 54.8% (Gemini 3 Pro), PennyLane 42.9% (DeepSeek R1)
Qiskitは、常に最も使いやすいフレームワークであり、PennyLaneは、テストされたすべてのモデルにおいて最も難しいことがわかった。
パフォーマンスはフレームワークによって大きく異なります。あるフレームワークで優れた性能を発揮するモデルでも、別のフレームワークでは性能が低下することがあり、これは、量子コンピューティングの理解だけでなく、APIの知識も重要であることを示唆しています。
GPT 5.1は、QiskitおよびCirqにおいてトップの性能を示していますが、DeepSeek R1はCirqおよびPennyLaneにおいて競争力があり、特にフィードバックを利用することでその性能を発揮します。

Pass@1 scores across frameworks — **図2:** Qiskit、Cirq、およびPennyLaneにおける12種類のLLMのPass@1スコア — QiskitからPennyLaneへの移行に伴い、パフォーマンスが大幅に低下していることが示されています。

Pass@1 と Pass@5 とは何ですか？

Pass@1 は、モデルがちょうど 1 回の試行しか与えられないことを意味します。これは、リテイクが一切ないテストを受ける学生のようなものです。Pass@5 は、モデルに 5 回の試行を与え、そのうちどれか 1 つでも成功すれば、成功とカウントします。実際の開発では、複数の候補を生成し、その中から最適なものを選択することが多いため、Pass@5 はより実用的な状況を反映しています。Pass@1 と Pass@5 の差は、モデルの一貫性を示します。差が小さいほど、モデルは信頼性の高いコードを生成していることを意味し、差が大きいほど、モデルが「運が良かった」場合があることを意味します。

フィードバックに基づく修復 (RQ3)

モデルが、実行の失敗によるエラーメッセージや、誤った回答に対するフィードバックを受け取ると、コードを最大5回まで修正することができます。このフィードバックループは、すべてのフレームワークにおいてパフォーマンスを大幅に向上させます。

Qiskit 59.5% → 83.3%

Cirq 54.8% → 76.2%

PennyLane 42.9% → 66.7%

Pass@1 after feedback repair — **図3:** フィードバックに基づく修正後のPass@1 — DeepSeek R1は、Qiskitにおいて83.3%に達し、反復的なデバッグの有効性を示しています。

詳細な結果

Model	Qiskit Pass@1	Qiskit Pass@1 (FB)	Cirq Pass@1	Cirq Pass@1 (FB)	PennyLane Pass@1	PennyLane Pass@1 (FB)
GPT 5.1	59.5	73.8	54.8	76.2	40.5	66.7
DeepSeek R1	57.1	83.3	52.4	73.8	42.9	66.7
GLM 4.7	50.0	71.4	45.2	61.9	33.3	52.4
Gemini 3 Pro	47.6	69.0	38.1	57.1	26.2	38.1
Claude 3.7 Sonnet	45.2	57.1	35.7	59.5	26.2	47.6
Kimi K2 Thinking	50.0	57.1	33.3	57.1	23.8	45.2
GPT 4.1	45.2	42.9	28.6	40.5	31.0	45.2
DeepSeek Chat	42.9	69.0	38.1	61.9	23.8	64.3
Llama 4 Maverick	40.5	61.9	35.7	50.0	23.8	40.5
Gemini 2.5 Flash	38.1	54.8	28.6	42.9	19.0	38.1
MiniMax M2.1	28.6	57.1	23.8	47.6	31.0	47.6
Qwen 2.5 7B	16.7	19.0	4.8	7.1	11.9	19.0

エラー分析

すべてのモデルとフレームワークにおける977件のタスク失敗事例を分析した結果、エラーの種類に明確な階層構造が見られました。最も一般的な失敗は、誤った答えを生成すること (46.7%) で、これはコードが実行されるものの、誤った量子状態や測定結果が得られることを意味します。論理エラー (25.0%) は、回路の設計に問題がある場合に発生し、メソッド/ゲートの欠落エラー (11.8%) は、モデルが実際には存在しないAPI関数を生成してしまうことを示しています。

エラーの種類を理解する

6つのエラーカテゴリは、AIが量子コードで苦戦する箇所を明らかにしています。

誤った答え (46.7%): コードはクラッシュせずに実行されますが、誤った量子状態を生成します。これは、ロジックが妥当に見えるため、最も修正が難しい種類のものです。
論理エラー (25.0%): 量子回路が正しく構築されていません — ゲートの順序が間違っている、エンタングルメントが不足しているなど。
メソッド/ゲートの欠落 (11.8%): モデルが、存在しないAPI関数を「幻覚」します — 例えば、正しいメソッドがqc.ccx()であるにもかかわらず、qc.toffoli()を呼び出すなど。
形状の不一致 (8.0%): 出力が誤った次元を持っています — 例えば、テストが4個を期待しているのに、3個の量子ビットを測定するなど。

フィードバックの後、構文エラーはほぼ消滅します (4.7% → 1.5%)。しかし、誤った答えの割合は増加します (46.7% → 53.4%)。これは、深い概念的なエラーは単純な修正では解決できないことを示しています。

Error distribution before feedback — **図4：** フィードバック前のエラー分布 — 977件の誤ったタスクのうち、誤った回答が46.7%を占め、論理的なエラーが25.0%を占めていました。

Error distribution after feedback — **図5：** フィードバック後のエラー分布 — 665件の未解決エラーのうち、正解以外の選択肢を選んでしまう傾向が53.4%にシフトしています。これは、修正しやすいエラーが優先的に解決されるためです。

フィードバックに基づく修正後、未解決のタスクは665件となりました。注目すべき点として、構文エラーは4.7%から1.5%に減少し、欠落したメソッド/ゲートエラーは11.8%から3.8%に減少しましたが、誤った解答の割合は53.4%に増加しました。これは、フィードバックが表面的な問題を効果的に解決する一方で、量子論におけるより深い概念的なエラーには対応しにくいことを示しています。

プリフィル (Prefill) と、プリフィルしない場合 (No-Prefill)

プレフィル実験は、モデルに解答の冒頭部分（インポート文や関数シグネチャ）を与えることで、コード生成が改善されるかどうかを検証するものです。これは、開発者がすでに基本的な構造を構築し、モデルがその実装を完了させるという状況をシミュレートするものです。

「プレフィル」とは？

「プレフィル」とは、学生にエッセイの最初の数行を与え、それを続けて書いてもらうようなものです。コード生成においては、これは、import ステートメントと関数のシグネチャを提供し、モデルが実際のロジックのみを書くようにすることです。例えば、最初から生成する代わりに、モデルは以下を受け取ります: from qiskit import QuantumCircuit def solve(): そして、そこから続きを書きます。これにより、「定型的な記述の負担」が軽減され、純粋な問題解決能力がテストされます。

Prefill vs No-Prefill in Cirq — **図6：** Cirqにおける、プリフィルありとプリフィルなしの比較 — Gemini 3 Proは、プリフィルありの場合、51.2%から62.5%へと、最も大きな改善が見られます。

結果は、事前入力の効果が、モデルとフレームワークによって大きく異なることを示しています。一部のモデルは大幅な改善が見られます（Gemini 3 Pro は Cirq で +11.3% の向上が見られる）、一方、他のモデルではほとんど変化が見られなかったり、わずかに性能が低下したりします。この効果は、最も複雑なフレームワークである PennyLane で最も顕著であり、これは、モデルが API に慣れていない場合に、インポートヒントが最も効果的であることを示唆しています。

タスクごとのパフォーマンス

これらのヒートマップは、各フレームワークにおける、すべてのモデルとタスクの組み合わせにおけるPass@1の結果を示しています。各行はLLM（大規模言語モデル）を表し、各列はタスクを表し、青色のセルは成功を示し、白色のセルは失敗を示します。このパターンから、いくつかのタスクは普遍的に難しく、一方で他のタスクはほとんどのモデルにとって容易であることがわかります。

Qiskit Pass@1 heatmap — **Qiskit** — Pass@1 のヒートマップで、最も成功しやすいパターンを示しています。

Cirq Pass@1 heatmap — **Cirq** — Pass@1 のヒートマップ。明らかに白色（失敗）のセルがより多く見られます。

PennyLane Pass@1 heatmap — **PennyLane** — Pass@1 のヒートマップ。最も疎な成功パターンを示しています。

フィードバック学習曲線

これらのグラフは、各モデルが、より多くのフィードバック試行（1～5回）を受けるにつれて、どれだけのタスクを解決できるかを示しています。最も改善が見られるのは、最初の2～3回の試行回数であり、その後は改善の効果が薄れます。GPT 5.1とDeepSeek R1は、すべてのフレームワークにおいて、最も速く収束します。

Qiskit feedback curves — **Qiskit** — フィードバック学習曲線。初期段階での急速な改善を示しています。

Cirq feedback curves — **Cirq** — フィードバック学習曲線。類似した収束パターンを示します。

PennyLane feedback curves — **PennyLane** — フィードバック学習曲線。最も改善が見られる部分を示しています。

議論

主要な知見

複数のフレームワークを用いた評価から、あるフレームワークで高い性能を発揮しても、別のフレームワークでも必ずしも高い能力を発揮するとは限らないことが明らかになりました。モデルは、量子コンピューティングの本質的な理解を深めるのではなく、フレームワーク固有のAPIパターンを記憶しているように見えます。Qiskit（最も人気があり、おそらくトレーニングデータで最も多く使用されている）とPennyLane（それほど一般的ではない）との間の大きな性能差は、この解釈を裏付けています。フィードバックに基づく改善は非常に効果的であり、最も優れたモデルはQiskitで83.3%の精度を達成しました（59.5%から）。これは、LLMがリアルタイムでエラー信号から学習できる可能性を示唆しています。

妥当性の脅威

ベンチマークの規模： 42のタスクは、一定の範囲をカバーする上で有効ですが、量子プログラミングの多様性全体を十分に反映することはできません。
APIの非決定性： LLM APIの応答は、実行ごとに異なる場合がありますが、Pass@5はこれを軽減するのに役立ちます。
フレームワークのバージョン： 結果は特定のフレームワークのバージョンに依存しており、アップデートによって変動する可能性があります。

制限事項と今後の課題

以下の3つのフレームワークのみを扱います（Q#、Amazon Braket、その他の新興プラットフォームは扱いません）。
評価はすべてシミュレータベースで行われます。実際の量子ハードウェアを使用すると、追加のノイズや制約が発生します。
今後の展望としては、より多くのフレームワークへの対応、ハードウェアを考慮したタスクの追加、そして、Few-shotやRetrieval-augmentedといった手法の研究などが挙げられます。

結論

AIと量子コンピューティングの全体像

この研究には、実用的な意味合いがあります。もし、プロジェクトのためにAIツールを使って量子コードを書いているのであれば、単一のフレームワークの結果を鵜呑みにしないでください。あるモデルがQiskitで59.5%のスコアを獲得したとしても、PennyLaneでは42.9%にしか達成できない可能性があります。良いニュースは、フィードバックループが非常に効果的であるということです。コードを繰り返し実行し、エラーメッセージを読み、修正することで、精度を約60%から80%以上に向上させることができます。これは、人間の開発者が行う作業と似ています。コーディング、テスト、デバッグ、そして繰り返します。この分野の課題は、AIがAPIドキュメントを単に記憶するだけでなく、真に量子概念を理解するAIを構築することです。

QuanBench+ は、初のマルチフレームワーク量子コード生成ベンチマークであり、Qiskit、PennyLane、およびCirqの42の関連タスクを対象としています。 12の最先端LLM（大規模言語モデル）の評価から、進歩と依然として存在する重要な課題の両方が明らかになりました。

最も優れた単発精度は59.5% (Qiskit) であり、これは量子コード生成がLLMにとって依然として困難な課題であることを示しています。
フレームワーク間のパフォーマンス格差は大きい。優れたモデルであっても、馴染みのないフレームワークでは大幅に性能が低下し、これはAPIの暗記によるものであり、量子力学の深い理解によるものではない可能性を示唆している。
フィードバックに基づく修正により、最高スコアが83.3%に向上しました。 これは、反復的なデバッグが量子コード生成のための強力な戦略であることを証明しています。
信頼性の高い、複数のフレームワークに対応した量子コードの自動生成は、依然として未解決の問題であり、量子計算の原理だけでなく、フレームワーク固有の知識に大きく依存している。

参考文献

Chen et al. (2021). Evaluating Large Language Models Trained on Code. arXiv:2107.03374.
Aleksandrowicz et al. (2019). Qiskit: An Open-source Framework for Quantum Computing.
Bergholm et al. (2018). PennyLane: Automatic differentiation of hybrid quantum-classical computations. arXiv:1811.04968.
Cirq Developers (2021). Cirq: A python framework for creating, editing, and invoking quantum circuits.
Nielsen & Chuang (2010). Quantum Computation and Quantum Information. Cambridge University Press.
Vishwakarma et al. (2024). Qiskit HumanEval: An Evaluation Benchmark For Quantum Code Generation.
Basit et al. (2025). QHackBench: Benchmarking Quantum Computing Code Generation.
Wang et al. (2024). QCircuitBench: A Benchmark for Quantum Circuit Generation.
Guo et al. (2025). QuanBench: Benchmarking LLMs on Quantum Computing.
Achiam et al. (2023). GPT-4 Technical Report. OpenAI.
DeepSeek-AI (2024). DeepSeek-R1. Technical Report.
Google (2025). Gemini 3 Pro. Technical Report.
Anthropic (2025). Claude 3.7 Sonnet. Model Card.