IBMは、統一されたCインターフェースを通じて、Rustで記述された高性能コアにアクセスし、Fortran、C++、JuliaからQiskitを利用できるようにすることで、Python以外からQiskitへアクセスする入口を拡大した。同社によると、この設計により、Pythonインタープリターを組み込んだり、データをPythonオブジェクトへ移したりすることなく、既存のアプリケーション内で量子回路を直接構築・実行できる。
この取り組みは、開発パッケージの基盤データモデル向けCインターフェースを公開したQiskit 2.0から始まった。3つの言語向けバインディングは同じ共有Qiskitライブラリを使用するため、ある言語で作成した回路は、原則として、同じオブジェクトを保持したまま、C++やFortranなど別の言語に渡すことができる。
Qiskitへの3つの経路
Fortran向けには、IBMが回路の構築と操作のためのqiskit-fortranインターフェースを提供しており、標準のiso_c_binding機構を利用してCインターフェースを呼び出す。回路は派生型を使用し、変数がスコープを離れる際にメモリを解放する。また、既存の量子化学アプリケーションのFortranメモリ内にあるHamiltonianなどのデータを、Pythonへコピーしたり再割り当てしたりすることなく、回路構築用の手続きへ直接渡すこともできる。
IBMが前年に初めて発表したqiskit-cppは、ヘッダーファイルのみで動作するC++インターフェースである。プログラムはQiskit Cライブラリにリンクでき、回路オブジェクトのメモリはスコープを離れる際に自動的に管理される。IBMは、qiskit-ibm-runtimeのCクライアント、またはQRMIとSQCを介して回路を送信できるとしている。
Qiskit.jlとQiskitIBMRuntime.jlは、Jupyterノートブック内での作業やIBM Quantumのハードウェアへのアクセスなど、Juliaユーザー向けのインタラクティブな経路を提供する。両パッケージはCポインターの詳細を隠蔽し、Python版Qiskitに近いスタイルで回路を作成・実行できるようにする。ただし、Juliaは量子ビットの番号付けを1から開始するのに対し、Pythonは0から開始する点に注意が必要である。
実際に何が変わるのか
新しいインターフェースは、科学アプリケーションがFortran、C++、Juliaに依存している研究者、特にシミュレーション、物理学、化学、工学、高性能コンピューティングの分野を対象としている。Qiskitを別プロセスとして実行したり、各手順の調整にPythonを使用したりする代わりに、既存の古典アプリケーション内でリンクされた手続きとして量子回路を呼び出せる。これには、回路の構築、特定のハードウェア向けの最適化、ハードウェアへの送信、結果の処理が含まれる。
IBMは、最大100量子ビットのシステム上で横磁場イジングモデルをシミュレーションするJuliaの例を通じて、この経路を説明している。この例には、Trotterizationを用いたシュレーディンガー方程式の時間発展の近似、回路の最適化、ハードウェア上での実行、サイト磁化の計算が含まれる。例の概念的な結果は、Trotterステップのサイズを小さくすると近似誤差は減少する一方、回路の深さが増大し、最終的には精度向上による利益を上回るハードウェアノイズにつながる可能性があることを示している。
制約と未解決の問題
IBMは、Python以外のすべてのバインディングが依然として活発な開発段階にあるため、今回の発表では最終的に安定したインターフェースや、詳細な比較性能結果は提示していないと強調している。また、100量子ビットの例は量子コンピューティングの実際的な制約を克服したことを意味しない。テンソルネットワークによる古典シミュレーションのリファレンスは、もつれの増加に伴って信頼性が低下し、実行精度は依然としてTrotter誤差とハードウェアノイズに左右される。
ここでの基本的な価値は、それ自体が新たな量子能力を提供することではなく、既存のHPCコードへ量子リソースを統合する際のソフトウェア上の摩擦を減らすことにある。インターフェースの影響は、パッケージの成熟度、既存の研究環境との統合、そして量子ハードウェアが古典的な代替手段を上回る結果を提供できるかどうかに左右される。