はじめに

こんにちは、大阪大学量子情報・量子生命研究センター^[1]特任研究員の宮永(@orangekame3)です。

当研究センターでは、量子コンピュータの研究開発を推進するとともに、クラウド量子コンピュータやその運用に関連するソフトウェアをOSSとして公開しています。本記事では、超伝導量子コンピュータの運用に欠かせない「キャリブレーション」と、その効率化を目指したソフトウェア「QDash」について説明します。

量子ビットとキャリブレーション

量子コンピュータは、量子ビットを情報単位として演算を行います。しかし、量子ビットの特性は安定せず、正確な動作のためには「キャリブレーション」と呼ばれる調整工程が不可欠です。
ここでは、量子ビットとキャリブレーションについて簡単に説明します。

超伝導量子ビットとは？

現在主流の量子ビットの一つが、超伝導量子ビットです。これは、超伝導体と非線形素子「ジョセフソン接合」により実現されています。

RQC_BB
国産初号機の叡のQPU (Copyright: RIKEN Center for Quantum Computing)

超伝導量子ビットの物理については以下の記事が詳細かつわかりやすくまとめてありますので、興味のある方はご参照ください。

キャリブレーション

超伝導量子ビットは製造後そのままでは利用できません。動作特性を調べ、特性に応じたマイクロ波パルスを調整する必要があります。この工程をキャリブレーションと呼びます。
高い精度で量子コンピュータを演算させるためにはこのキャリブレーションが欠かせません。キャリブレーションは複数の実験を組み合わせて行われ、実験を経るごとに量子ビットの制御を高精度に調整していきます。

以下は典型的なキャリブレーションフローを示した図です。

calibration-flow
典型的なキャリブレーションフロー

キャリブレーションは、前段階の結果に基づいて次のステップを進めるため、実験結果のパラメータ間には依存関係が発生します。さらに、量子ビットの特性は時間とともに変化（ドリフト）するため、定期的な再調整が必要です。

例えば、以下の図はIBMが公開しているデータをもとに量子ビットのT1特性を時系列にプロットしたものです。T1は量子ビットの寿命を示す指標であり、量子ビットの質に直結するパラメータです。図からもわかるように、量子ビットのT1特性が時間とともに変化しています。

図は「Error rate reduction of single-qubit gates via noise-aware decomposition into native gates」^[2]より引用、量子ビットの特性を示すT1の時系列データに揺れがあることがわかる

パラメータに依存関係があり、かつ時間的に変化する量子ビットの特性を考慮すると、キャリブレーションは非常に複雑な作業であることがわかります。

キャリブレーションの課題

先述した通り、キャリブレーションは複数の実験を組み合わせて行われるため、多くの時間が費やされます。例えばGoogleが開発しているSycamoreプロセッサの場合、希釈冷凍機^[3]のクーリングダウン後36時間をかけてキャリブレーションを行い、その後毎日4時間をかけてキャリブレーションを行っていると報告されています^[4]。Sycamoreプロセッサの場合、高精度な制御を行うために1量子ビットあたり100を超えるパラメータを保持、活用しているとのことから複雑な運用が日々行われていることが想像できます。

実用的な量子コンピュータが実現するには数百万量子ビットが必要とされていることから、これらのキャリブレーションを効率的に行うための仕組みが量子コンピュータを実現する上で必要不可欠であるということがお分かりいただけるかと思います。

図は「量子コンピュータの誤り耐性量子計算を解説！エラー訂正とエラー緩和の最新トレンドを紐解」^[6]より引用、量子コンピュータの実用化までの道のり

キャリブレーションとクラウドサービスの運用

以上のような超伝導量子ビットのキャリブレーションを考慮すると、クラウド量子コンピュータの運用は一般的なソフトウェアサービスとは異なるライフサイクルで行われることがわかります。

通常のソフトウェアサービスは以下のように「要件定義」、「設計」、「実装」、「テスト」、「デプロイ」、「運用」のライフサイクルを繰り返しますが、クラウド量子コンピュータの場合は運用フェーズの中でさらにキャリブレーションやその評価、サービスの公開といったライフサイクルが必要です。

cloud-service-lifcycle
クラウド量子コンピュータサービスのライフサイクル

キャリブレーションは量子ビットの質そのものに直結するため、サービスの信頼性に多大な影響を及ぼします。キャリブレーションの自動化や監視の仕組みは量子コンピュータの実現において重要な要素であることがわかります。

先行事例の紹介

ここまで説明してきたように現状の超伝導量子ビットにおいては、量子ビットひとつひとつの特性に合わせてソフトウェア面からマイクロ波パルスのキャリブレーションを行います。加えて、サービス公開前と（可能であれば）サービス公開中も継続的にキャリブレーションを行う必要があります。

ここでは、IBMやGoogleなどのビッグテックがどのようにクラウドサービスと運用を行っているのか、また大規模なプロセッサにおいてどのようにキャリブレーションを管理しているのかを紹介します。

IBMの例

クラウドサービスをいち早く開始したIBMでは毎日1回の定期的なキャリブレーションと、1時間に1回の簡易的なキャリブレーションが行われています^[7]。通常のジョブにキャリブレーションジョブを混ぜ込むことでサービスを継続的に提供するような仕組みを構築しています。

Googleの例

Googleはクラウドサービスを一般公開はしていないものの、複雑なキャリブレーションをDAGで管理することでキャリブレーションの効率化を図っています^[8]。

Googleのキャリブレーション自動化の取り組み

DAGを用いたキャリブレーションの管理は、各実験に依存関係があることを考慮すると非常に合理的な方法であると言えます。GoogleがDAGを用いたキャリブレーションシステム「Optimus」を発表後、他の研究機関でも同様の取り組みが行われています^[9]^[10]。

私たちが直面していた課題

ここまでの説明から、超伝導量子ビットのキャリブレーションは非常に複雑であることがわかります。クラウドサービスとして提供する場合、キャリブレーションの自動化や監視の仕組みが必要であることもわかりました。2023年に大阪大学がクラウドサービスを公開^[11]した直後、キャリブレーションの自動化や監視の仕組みを構築することが求められました。以下に、私たちが直面していた課題を整理します。

課題1 - キャリブレーションの実行状況の監視・自動化
課題2 - キャリブレーション結果の管理

先のビッグテックの例からすると、大分手前の課題かもしれませんが、私たちの環境ではこれらの課題を解決するためのソフトウェアが存在していませんでした。そこで、まずはこれらの課題を解決するためのソフトウェアを開発することにしました。

課題1 - キャリブレーションの実行状況の監視・自動化

解像度を上げるために、2023年12月時点で抱えていた課題について説明します。

サービス開始直後、私たちはJupyter Notebookを用いてキャリブレーションを行っていました。Jupyter Notebookはインタラクティブにコードを実行できるため、パラメータを調整しながらキャリブレーションを行うのに適しています。新しい実験コードを書く際には、実行結果を確認しつつデバッグできるので非常に強力なツールです。

Jupyter Notebookによるキャリブレーション管理の課題

一方で定型的な実験を繰り返す場合、Jupyter Notebookを使った運用は以下のような問題があります。

再現性の確保が難しい: Jupyter Notebookは便利ですが、ノートブック内のセルを順不同で実行した場合、同じ結果が得られない可能性があります。このため、キャリブレーションの一連の流れを確実に再現する仕組みが必要です。
長期実行に向かない: キャリブレーションでは時間のかかる処理が含まれるため、Notebookのインタラクティブ性が逆に負担となる場合があります。特に長時間実行するジョブにおいては、自動化されたパイプラインが適しています。
監視やエラー処理が困難: NotebookのUIでは実行中のタスクをリアルタイムで監視したり、エラー発生時に適切なリカバリー処理を行う仕組みを組み込むことが難しいです。

課題2 - キャリブレーション結果の管理

キャリブレーションの結果は量子ビットの特性を示す重要なデータですが、これを適切に管理する仕組みが不足していました。

主な問題点

データの一元管理がない: キャリブレーションの結果は個々の研究者のローカル環境に保存されることが多く、これにより結果の共有や過去のデータ参照が困難でした。
履歴管理の欠如: キャリブレーション結果が時系列で変化するため、変更履歴を管理し、以前の結果と比較する必要がありますが、その仕組みがありませんでした。
検索性の低さ: 多くのキャリブレーションデータが保存されていても、特定の条件下でのデータを簡単に検索・取得するのは困難でした。

これらの問題を解決するため、キャリブレーション結果を効率的に管理・可視化するためのデータ管理システムが必要でした。

ワークフローエンジンを用いたキャリブレーション管理

以上の課題解決をするうえで、MLOpsの事例が非常に参考になりました。MLOpsは機械学習のモデル開発から運用までを支援するための手法であり、ワークフローエンジンをモデルの学習パイプラインに組み込む事例が豊富にあります。

MLOpsの取り組みをキャリブレーションにあてはめる場合、学習パイプラインの各工程をキャリブレーションの各実験に対応させると良さそうです。このようなアプローチを取ることで、キャリブレーションの進捗状況を可視化し、複雑だったキャリブレーションを構造化することができます。

OSSの活用

多くのワークフローエンジンがOSSで提供されています。PrefectやApache Airflow、Luigiなどに加えて、AWSのStep Functionsなどもワークフローエンジンとして利用できます。潤沢な開発リソースがある場合には、スクラッチで超伝導量子ビットのキャリブレーションに特化したワークフローエンジンを開発することも考えられますが、ワークフローの仕組み自体には特に独自性が求められるわけではないため、OSSを活用することで開発効率を向上させることができます。

今回ワークフローエンジンを採用するうえで重視したのは、以下の点です。

実行環境を柔軟に指定できる
Pythonで記述できる
開発が活発に行われている

実行環境を柔軟に指定できる

キャリブレーションはソフトウェアだけで完結する作業ではありません、当然ハードウェアも必要です。キャリブレーションはハードウェア(マイクロ波発生装置)に接続されたPC上で行われるため、ワークフローエンジンが実行環境を柔軟に指定できることが重要です。

wiring of experimental setup
実行環境(サーバー）と制御装置、QPUの配線図

Pythonで記述できる

キャリブレーションの実験コードは多くの場合Pythonで記述されるため、ワークフローエンジンもPythonを用いて記述できることが望ましいです。Pythonで記述できることで、既存の実験コードを流用しやすくなります。

開発が活発に行われている

活発に機能追加やバグ修正が行われているOSSを選定することで、将来的なメンテナンスのリスクを軽減することができます。

Prefectの導入

上記の条件を踏まえ、私たちはPrefectをワークフローエンジンとして採用することにしました。PrefectはPythonで記述できるワークフローエンジンであり、実行環境を柔軟に指定できるため、キャリブレーションの自動化に適していると考えました。

from prefect import flow, task

@task(log_prints=True)
def say_hello(name: str):
    print(f"Hello, {name}!")

@flow
def hello_universe(names: list[str]):
    for name in names:
        say_hello(name)

if __name__ == "__main__":
    hello_universe(['Marvin', 'Trillian', 'Ford'])

Prefectでのワークフローの実装例、Pythonで簡潔に記述できる

Prefectと他のワークフローエンジンの比較については以下の記事が参考になります。

ワークフローエンジンとの連携

Prefectは強力なツールですが、これだけではキャリブレーションの自動化には不十分です。データ管理を行うためのデータベースや、キャリブレーション結果を適切に表示するUIが必要です。

今回は以下の構成でシステムを構築しました。

qdash-architecture
キャリブレーション管理システムのアーキテクチャ

バックグラウンドにPrefectをキャリブレーションタスクのワーカーとして動作させ、キャリブレーション結果をデータベースに保存し、Webアプリケーションで表示するという構成です。このアプリケーションをQDashと名付けました。

QDashの特徴

先に記述した通り、従来Jupyter Notebookで実行していたキャリブレーションタスクをPrefectに移植することにしました。これにより、以下のような特徴を持つシステムを構築することができました。

ログの一元管理: キャリブレーションの実行ログを一元管理することができます。PrefectのUIを利用することで、実行状況をリアルタイムで確認できます。また、共有URLを発行することで他の研究者とログを共有することも可能です。
再現性の確保: Prefectのワークフローはコードとして記述されるため、再現性を確保することができます。また、ワークフローの実行状況をリアルタイムで確認でき、各タスク毎にログが構造化されるため、エラー発生時のデバッグも容易です。
長期実行に対応: Prefectは長時間実行するジョブにも対応しており、ジョブの再開やリトライ、スケジューリングなどを柔軟に設定することができます。

qcflow-example
QDashのワークフローの一例、量子ビット毎にログが構造化されており、各実験の詳細なトレースが可能

また、課題2に記述したようなキャリブレーション結果の管理についても、QDashを用いることで以下のような特徴を持つシステムを構築することができました。

データの一元管理: キャリブレーション結果をデータベースに保存することで、データの一元管理が可能です。また、キャリブレーション毎に実行IDを払い出す仕組みにしているため、過去のデータを参照することができます。
検索性の向上: データベースに保存されたキャリブレーション結果は、検索条件を指定して簡単に取得することができます。また、Webアプリケーションを用いて、キャリブレーション結果を直感的に表示することができます。

qdash-ui
QDashのUI、キャリブレーション結果を直感的に表示

QDashの実運用と今後の課題

QDashの導入により、キャリブレーションの運用に関する課題をいくつか解決することができました。ここでは、現在の実運用状況と、さらに改善が必要な点について説明します。

現在の実運用状況

QDashは、大阪大学のクラウド量子コンピュータサービスで実際に運用されています。主な使用例として以下が挙げられます。

キャリブレーションの自動化

定期的に必要となるキャリブレーション作業をPrefectのスケジューリング機能で自動化しました。これにより、従来は運用者が手動で行っていた作業を大幅に削減することができました。

キャリブレーション結果のリアルタイムモニタリング

キャリブレーション結果は、QDashのUIでリアルタイムに確認することができます。これにより、異常検知やパラメータの変動傾向を素早く把握できるようになりました。

量子ビットの性能の履歴管理

キャリブレーションデータがデータベースに保存されているため、過去のデータを基にした分析が可能です。例えば、特定の量子ビットのパフォーマンスがどのように変化したかを時系列で確認することができます。

今後の課題

QDashは運用を開始したばかりで、さらなる進化が求められています。今後取り組みたい課題は以下の通りです。

課題1 - 自律的なキャリブレーションシステムの実現

現在は、あらかじめ設定したワークフローに従ってキャリブレーションを行っています。しかし、量子ビットの状態や環境の変化に応じて、最適なタスクを自動で選択・実行できる「自律的なキャリブレーションシステム」を目指したいと考えています。これにより、効率と精度のさらなる向上が期待できます。

課題2 - データの活用による性能向上

キャリブレーションで得られたデータを活用し、量子ビットの性能向上やエラー率低減につながる新しい分析手法を開発したいと考えています。蓄積したデータを機械学習などに活用することで、これまで気づけなかった洞察を得られる可能性があります。

課題3 - クラウドサービスとの連携強化

クラウドサービスの運用中にダウンタイムが発生しないよう、キャリブレーションのスケジューリングをサービスの稼働状況に合わせて柔軟に調整する仕組みを構築したいと考えています。これにより、ユーザーへの影響を最小限に抑えつつ、効率的な運用を実現します。

まとめ

本記事では、超伝導量子ビットのキャリブレーションとクラウドサービス運用における課題、その解決に向けた取り組みについて解説しました。

前半では、キャリブレーションが量子コンピュータの性能を左右する重要な工程であり、複雑かつ多大な労力を必要とすることを紹介しました。特に、量子ビットの特性が時間とともに変化することや、多くのパラメータが依存関係を持つことが、効率的な運用を妨げる主な要因であることを解説しました。

後半では、これらの課題を解決するために開発したソフトウェア QDash を紹介しました。QDashは、キャリブレーションの自動化、データの一元管理、リアルタイムの監視機能を実現し、運用効率の向上を達成しています。また、量子ビット性能の履歴管理や可視化によって、データ駆動型の意思決定が可能となり、今後の研究開発に貢献することが期待されます。

おわりに

ここまで読んでくださった方はお気づきの通り、量子コンピュータのシステムを構築するといっても必ずしも量子力学の知識が必要というわけではありません。今回紹介したような課題はどれも、一般的なシステム開発で遭遇する課題と共通しています。もちろん、開発に取り組むうえでの多少のドメイン知識は必要ですが、それはどんなシステム開発にも共通することです。

本記事を読んで、量子コンピュータのシステム開発に少しでも興味を持った方はぜひ、一緒に量子コンピュータのシステム開発をしましょう！ @orangekame3 までお気軽にご連絡ください。

最後までお読みいただき、ありがとうございました。本記事が、超伝導量子ビットのキャリブレーションやクラウドサービス運用に興味を持つきっかけとなれば幸いです。

脚注

大阪大学量子情報・量子生命研究センター ↩︎
Error rate reduction of single-qubit gates via noise-aware decomposition into native gates ↩︎
超伝導量子ビットは極低温環境で動作するため、希釈冷凍機と呼ばれる装置で冷却されます。希釈冷凍機は、ヘリウムを用いて数ミリケルビンまで冷却することができる装置です。 ↩︎
Quantum supremacy using a programmable superconducting processor | Nature ↩︎
Quantum error correction below the surface code threshold | Nature ↩︎
量子コンピュータの誤り耐性量子計算を解説！エラー訂正とエラー緩和の最新トレンドを紐解く | 富士通 ↩︎
About calibration jobs | IBM Quantum Administration ↩︎
[1803.03226] Physical qubit calibration on a directed acyclic graph ↩︎
Universal Graph-Based Scheduling for Quantum Systems | IEEE Journals & Magazine | IEEE Xplore ↩︎
[2105.10730] Origin Pilot: a Quantum Operating System for Effecient Usage of Quantum Resources ↩︎
大阪大学に設置した超伝導量子コンピュータ国産３号機のクラウドサービスを開始 - ResOU ↩︎

Discussion