【ITニュース解説】I built three tools for Quantinuum's guppy stack. Along the way I found six real bugs.

ある開発者が、量子コンピューティングという最先端の分野で新しいツールの開発に取り組んだ話を紹介する。彼が作業したのは、「guppylang」というプログラミング言語だ。これは、Pythonという広く普及した言語に組み込まれており、書かれた量子プログラムは「HUGR」という中間表現に変換された後、「Selene」というシミュレータや、実際に「トラップ型イオン」と呼ばれる量子ハードウェアで実行される。この量子コンピューティングのエコシステムはまだ新しく、開発者は単なるデモンストレーションではない、本当に役立つツールを作りたかった。そのため、彼は「正確性」を最も重要な開発目標として掲げた。具体的には、プログラムの動作や計算結果が、参照している学術論文や数学的な根拠と本当に一致しているかを徹底的に検証する、という厳格な姿勢で開発を進めた。

この厳格な「正確性」へのこだわりが、予想以上の成果をもたらした。彼は三つの開発ツールを作り上げる過程で、合計で六つもの実際のバグを発見し、それらが本当に存在するものであることを確認したのだ。これらのバグのうち四つはguppylangそのものに、そして残りの二つは「Google Qualtran」という、量子コンピューティングのリソース推定に広く使われているライブラリに見つかった。これらのバグは、彼が意図的に探し求めていたものではなく、正確さを追求する中で自然と明らかになったものだった。

彼が開発した三つのツールについて説明する。 一つ目は「qshelf」だ。これは、guppylangやHUGRで実行できる量子アルゴリズムの実装を集めたパッケージレジストリ、つまり登録所のようなものだ。量子フーリエ変換（QFT）、グローバーのアルゴリズム、QAOA、VQE-H2といった、代表的な量子アルゴリズムの実装が含まれている。このツールの重要な特徴は、それぞれのアルゴリズム実装が、「ただ動いた」というだけでなく、厳密な線形代数の計算や、Pythonの科学計算ライブラリ「scipy.linalg.expm」などといった独立した数学的な参照と照らし合わせることで、その正確性が厳しく検証されている点だ。

二つ目は「Estimand」というツールだ。これは、guppyやHUGRで書かれた量子プログラムが、実行に必要とする物理的な量子ビットの数、プログラムの実行にかかる時間、そしてエラーが発生する確率を推定するためのものだ。この推定は「表面符号」という、量子コンピュータがエラーを修正するための仕組みを前提として行われる。Estimandは、自らがリソース推定の計算エンジンとなるわけではなく、guppyプログラム内の条件分岐、ネストされたループ、関数呼び出し、さらには間接的な呼び出しといった複雑な制御フローから、使われる基本的なゲートの数を数え上げる。そして、そのゲート数情報をQualtranという既存のライブラリに組み込まれているコスト計算モデルに渡す「アダプター」の役割を果たす。このツールも、既存のQFTやグローバーのアルゴリズムの実装に対して、入力から出力まで一貫して正確性が検証されている。

三つ目は「qmatchpoint」だ。量子コンピューティングにおいては、計算中に発生するエラーを修正する「量子誤り訂正（QEC）」が極めて重要だ。QEC回路は、エラーに関する情報である「シンドロームビット」を生成するが、このシンドロームビットを受け取って実際のエラーを特定・修正する「デコーディング」の機能が、guppylang、HUGR、Seleneという既存のシステムスタックにはまだ備わっていなかった。そこでqmatchpointは、「PyMatching」という、既に確立され、専門家からも高く評価されているデコーダーを、guppyのQEC回路が生成するシンドロームビットに接続する役割を担う。これにより、量子誤り訂正の一連のプロセスが完結できるようになる。

これらのツールを開発し、その正確性を検証する過程で、具体的なバグがいくつか発見された。 まず、qshelfの開発を通じて量子アルゴリズムの数学的な正確性を確認する中で、guppylangに四つの問題が見つかった。一つは、「iqft」という量子回路が、単独でコンパイルされた場合と「qft」という別の回路と組み合わせてコンパイルされた場合とで、実行結果の「ユニタリ変換」（量子状態の変化を表す数学的な操作）が異なっていたというものだ。これは、同じ回路であるにもかかわらず、その使われ方によって振る舞いが変わるという、重大な不整合を示していた。もう一つは、複数の量子ビットを同時に制御する「マルチ制御Zゲート」という操作が、誤ったユニタリ変換を行っていたという問題だ（この問題は後に、guppylangの開発元によって修正された）。その他には、汎用的な配列の長さを示す型が、プログラム内で正しく扱われない問題や、Pythonの科学計算ライブラリ「numpy.ndarray」を使った特定の機能が拒否される問題が見つかった（こちらは後に、バグではなく新しい機能の要望として再分類されている）。

さらに興味深いバグは、Estimandの開発中に見つかったものだ。Estimandの主要な役割は、guppyプログラムからゲートの数を抽出し、その後の表面符号を使ったリソース推定計算はQualtranというライブラリの数学モデルに委ねることだった。しかし、開発者はQualtranが参照している学術論文（Beverland et al. 2022やLitinski 2019など）の内容と、Qualtranに実装されている計算式を実際に詳細に比較検証した。その結果、二つの具体的な不一致が発見された。 一つは、「CompactDataBlock」というQualtranの内部コンポーネントにおける「タイル数」を計算する式だ。この式には、それが引用しているはずの論文に明確に記載されている「加算定数」が抜け落ちていた。この計算式の誤りはQualtranの開発者自身によっても確認され、開発者が修正に取りかかった時には、既にメインの開発ブランチには別の誤ったバージョンの式が取り込まれてしまっていたという状況だった。修正のためのプルリクエスト（コードの変更提案）は現在提出され、レビュー待ちとなっている。 もう一つは、「make_beverland_et_al()」という機能の「魔法状態ファクトリ」と呼ばれる部分のエラーモデルが、リツィンスキー氏の論文を忠実に再実装しているとされているにもかかわらず、リツィンスキー氏自身の閾値定数ではなく、サイレントにベヴァーランド氏の閾値定数を使用していたという問題だ。この発見は、この機能全体が、ベヴァーランド氏が提唱する本来のアーキテクチャ設計（データブロックや魔法状態ファクトリの配置など）をより忠実に再現すべきか、あるいはリツィンスキー氏のデフォルト設定を借り続けるべきか、というさらに大きな議論へと発展している。

これらのバグの発見は、開発者が最初から意図していた目的ではなかった。しかし、「このプログラムは、それが主張する機能を本当に正確に実装しているのか？」という問いを、選択的にではなく、常に必須の確認事項として扱った結果として、このような発見がもたらされたのだ。この経験は、開発された三つの個別のツールの価値以上に、非常に重要な教訓を私たちに示している。「厳密な検証という開発規律は、実際の、そして時として非常に重大な問題を発見する」ということだ。この教訓は、まだ初期段階の新しいエコシステムだけでなく、Google Qualtranのように成熟し、広く使われているライブラリにおいても当てはまる普遍的な真理である。プログラムやシステムの正確性を徹底的に検証する姿勢は、どのようなIT開発においても不可欠であり、予期せぬ形で、しかし確実にシステムの品質向上に貢献すると言えるだろう。