量子力学100周年とOSS──コミュニティが支える量子コンピューティングの進化
記事執筆にあたり
12/25のアドベントカレンダー最終日の担当はNTTテクノクロスの森川です。OSSやクラウド基盤をメインに扱う部署に所属しています。
これまでの業務では、OSSのPaaS製品であるCloud FoundryやKubernetesなどのコンテナ技術、そしてそれらと連携するさまざまなOSSプロダクトに触れてきました。
その経験を通じて、OSSのコミュニティが持つ活気や、コードから直接学びを得られる文化に強く魅了され、過去のアドベントカレンダーではクラウドネイティブに関連した記事をいくつか投稿してきました。
2025年が量子力学誕生から100年という節目の年だと知り、数年ぶりにアドベントカレンダーの記事を書くにあたり、せっかくなので量子コンピュータをテーマにしようと決めました。
この100年の間に量子理論は半導体やレーザーなど現代技術の基盤となり、最近では次世代計算機「量子コンピュータ」に関する話題も増えています。
実用化に向けては、古典コンピュータの発展がそうだったように、ハードウェアだけでなくソフトウェアの進化も欠かせません。
特に標準化やリファレンス実装を通じたユースケースの検証が重要で、量子コンピュータの分野でもOSS（オープンソースソフトウェア）がその鍵になると感じています。
節目の年を象徴する企画：量子コンピュータ関連の展示
2025年は、節目の年ということもあり様々な場所で企画展示などが開催されていました。
期間限定の展示が多くを占めているものの、常設展示として現在も公開が継続しているものも存在しています。
1. 日本科学未来館で量子コンピュータの常設展示が開始（2025年4月～継続展示）
東京・お台場の日本科学未来館で、2025年4月に一般公開が始まりました。
超伝導量子コンピュータに使われる144量子ビットのチップが展示されているほか、
まるでDJのような操作で量子プログラミングを学ぶ「量子コンピュータ・ディスコ」など、
楽しみながら体験できるコンテンツが常設展示として新たに追加されています。
これらの展示からは、未来の科学技術へのメッセージが込められているように感じます。
URL：https://www.miraikan.jst.go.jp/exhibitions/future/qcdisco/
2. 大阪・関西万博で量子コンピュータ関連展示が実施（2025年）
2025年の大阪・関西万博では、企画展「エンタングル・モーメント ―［量子・海・宇宙］×芸術」が開催され、
アートとのコラボレーション展示や、複数の研究機関・企業による国産量子コンピュータの展示などが行われました。
一般的なコンピュータと比べてまだ知名度の低い量子コンピュータに触れることで、
その未来の可能性を一般の人々に伝える重要な場となりました。
URL：https://www.expo2025.or.jp/
3. 国立科学博物館で企画展「量子の世紀」を開催（2025年10月～11月）
東京・上野の国立科学博物館で、量子力学誕生から100年という節目を記念した企画展「量子の世紀」が、2025年10月21日から11月30日まで開催されました。
展示は二部構成となっており、第I部「量子力学の誕生」では、ハイゼンベルクやディラックらの研究資料を通じて理論形成の過程をたどります。
第II部「量子力学の挑戦」では、量子ビットやスピン波など、量子理論が100年の時を経てどのように現代の量子技術へと発展したかを、体験的に理解できる展示が行われていました。
URL: https://www.kahaku.go.jp/plan/2025/10quantumcentury/
量子コンピュータシステムのアーキテクチャと課題
ハイブリッドシステムとしての量子コンピュータ
量子コンピュータは、従来のコンピュータ（古典コンピュータ）とまったく別の原理で動作しますが、実際に計算を行う際には、古典コンピュータの助けが欠かせません。
たとえば、量子コンピュータで実行する計算の内容を設計したり、
その動作を指示する「量子回路」を作成・最適化したりする処理は、まず古典コンピュータ側で行われます。
また、量子計算の結果を読み取り、統計的に整理して意味のある答えにまとめる作業も、
古典コンピュータが担当します。
このように、量子コンピュータの前後で必要となる「回路のコンパイル」「最適化」「測定結果の後処理」などの工程には、
GPUを含む高性能な古典計算リソースが不可欠です。
そのため、現在開発が進められている量子コンピュータの多くは、
古典コンピュータと連携して動作するハイブリッドシステムとして構成されています。
オンプレミス環境での二つのアーキテクチャパターン
量子コンピュータシステムをオンプレミス環境で構築する場合、主に以下の二つのアーキテクチャパターンが考えられます。
1. HPC（High Performance Computing）ベースの構成
現状、量子コンピュータシステムの多くは HPCベースのアーキテクチャ を採用しています。
これは以下の特徴を持ちます：
| 項目 | 内容 |
|---|---|
| ジョブ／リソース管理 | HPCでよく使われるSlurm、PBS、Torqueなどのワークロードマネージャを使用 |
| アクセス方法 | ユーザはSSHでログインノードに接続し、ジョブスクリプトを投入 |
| ユーザ管理 | OSレベルのユーザアカウントが必要で、LDAPやActive Directoryと連携 |
| ストレージ | 共有ファイルシステム（NFS、Lustre等）で結果を保存 |
この構成は、大学や研究機関の既存インフラと親和性が高く、セキュリティ要件が厳しい環境でも運用しやすいメリットがあります。
2. Kubernetes基盤のGPUクラスタ構成
もう一つの選択肢として、 Kubernetes基盤のクラウドネイティブアーキテクチャ も考えられます：
| 項目 | 内容 |
|---|---|
| ジョブ／リソース管理 | Kubernetes、KubeflowなどのMLOpsツールを利用 |
| アクセス方法 | REST APIやSDK経由 |
| ユーザ管理 | アプリケーションレベルの認証 |
| ストレージ | オブジェクトストレージ（S3互換等） |
AI/ML分野でのGPU利活用の文脈でKubernetesベースのインフラが急速に普及しており量子コンピュータも古典計算リソース（特にGPU）と密接に連携するため、同じインフラ基盤上で共存する構成は技術的に考えられます。例えば：
- 量子回路シミュレーションをGPUクラスタで実行
- 量子-古典ハイブリッドアルゴリズム（VQEなど）での反復計算
- 量子機械学習における前処理・後処理
このような用途では、KubernetesベースのMLOpsプラットフォーム（Kubeflow、MLflow等）と量子計算基盤が同一のアーキテクチャ上で動作することで、計算資源や開発・運用の効率化が期待できます。
ただし、量子コンピュータ特有の要件（極低温環境の制御、リアルタイム性、専用ハードウェアとの密結合）や、既存の量子デバイスの多くがHPC環境で運用されている現状から、現時点ではHPCベースの構成が主流となっています。今後、量子デバイスの安定性向上やクラウドサービス化が進むにつれ、こちらのアーキテクチャや共存するアーキテクチャが台頭してくるかもしれません
実際に論文『Qubernetes: Towards a Unified Cloud-Native Execution Platform for Hybrid Classic-Quantum Computing』などではKubernetesと組み合わせて構築した事例も出てきています。
ユースケース拡大のための外部ユーザへの公開における課題
量子コンピュータの実用化に向けては、具体的な問題解決のユースケースを積み重ねていくことが極めて重要です。
そのためには、外部の研究者や企業ユーザが容易にアクセスし、実際に試行できる環境の整備が欠かせません。
しかし、前述のHPCベースの構成では、外部ユーザに公開する際に以下のような課題があります。
- SSHアクセスの開放や認証情報の管理はセキュリティリスクを伴う
- 外部ユーザごとにOSレベルのアカウント管理が必要で、認証・権限設定の運用負荷が発生する
- 外部接続点のネットワーク機器（ファイアウォール等）の設定・メンテナンスやセキュリティポリシー管理が必要
- 利用者ごとに実行環境（依存ライブラリやジョブ設定など）の構築・管理が必要
- 利用状況の可視化や課金・利用制限の管理が難しい
多くのユーザを受け入れる場合、アカウント管理やセキュリティ対策、環境構築などを含む運用コストは無視できない負担 となります。
クラウドサービスとの比較
一方、商用クラウドサービスでは、これらの課題を解決したアーキテクチャが既に実装されています。Amazon Web Services（AWS）が提供する量子コンピューティングサービス Amazon Braket はその代表例です：
- API駆動: ユーザは AWS SDK（Amazon Web Services Software Development Kit） を通じてジョブを投入（SSH不要）
- 結果の保管: 計算結果はS3バケットに自動保存され、SDKでPull
- マネージドサービス: 実行用のJupyter環境が利用可能でインフラ管理が不要
といった特徴を持ち、クラウドネイティブな設計思想に基づくサービスとなっています。
国内OSSの動き：ハードウェアを待たずに進むソフトウェア開発
日本国内でも、ハードウェアの成熟を待たずにソフトウェアレイヤーから量子技術を進める動きがあります。
量子クラウド基盤向けのツールやアルゴリズムSDKなど、いくつかのOSSプロジェクトがすでに公開されており、その一部を紹介します。
| プロジェクト名 | 公開元 | ライセンス | 主な機能・目的 | リポジトリ |
|---|---|---|---|---|
| OQTOPUS Cloud | 大阪大学・富士通・TIS・セック | Apache License 2.0 | 量子クラウド基盤（ジョブ管理、キャリブレーション） | oqtopus-team/oqtopus-cloud |
| quri-sdk | QunaSys | QURI Parts は Apache License 2.0、QURI Algoは MIT License、QURI VM は MIT License のもとで公開。 | モジュール型量子SDK。アルゴリズム開発・シミュレーション・クラウド連携を統合的に提供。 | QunaSys/quri-sdk |
| Qulacs | QunaSys・大阪大学 | MIT License | 量子コンピュータの動作を高速にシミュレーションするためのライブラリ | qulacs/qulacs |
| Blueqat | blueqat | Apache License 2.0 | Pythonベースの量子コンピューター向けSDK | blueqat/blueqatSDK |
OQTOPUS Cloud：HPCの壁を越えるOSS
先ほど挙げた国産のOSSその中でも OQTOPUS Cloud は、HPCベース構成の課題をOSSとして解決する可能性を持つプロジェクトで、論文も『A Practical Open-Source Software Stack for a Cloud-Based Quantum Computing System』というタイトルで公開されています。
HPCとクラウドのブリッジアーキテクチャ
OQTOPUS Cloudの構成は3つのパートに分かれており、以下のようになっています。
- クラウド：外部に量子計算用のジョブのAPIを提供
- バックエンド：HPC内で量子計算を実行
- 運用層：運用ダッシュボードや実行履歴のUIなどを提供
処理の流れとしては、HPC環境とクラウドに構築したAPIを介して橋渡しする構成を採用しています。※実際のシーケンスから一部省略して記載しています
このような構成をとることで、回路を実行したいユーザはREST API経由でジョブを投入（SSH不要）することが可能になります。
OQTOPUS Cloudのソフトウェアには、実行エンジンであるOQTOPUS Engineのほか、Tranqu Serverと呼ばれる複数の量子プログラミングライブラリや形式に対応するためのトランスパイラ用の実装も含まれています。
これにより、ユーザ側のメンテナンス負荷だけでなく、HPC基盤側の運用負荷も軽減できる可能性を秘めています。
これまでの説明にあったように、OQTOPUS CloudはOSSとして量子クラウド基盤を構築するための要素を包括的に提供している点に大きな魅力があります。
ジョブ管理、実行エンジン、トランスパイラ、運用UIといった機能群が統合的に設計されており、量子クラウド環境の設計や運用を検討する際のリファレンス実装として非常に参考になる構成となっています。
まとめ
今回紹介した OQTOPUS Cloud に加え、国内のOSSの動きの中で登場しているさまざまなプロダクトをはじめ、ローカル環境で動作する量子シミュレータなどの実行基盤の開発も進んでおり、量子技術のエコシステムはますます広がっています。
こうした環境の整備により、実用化を待たずとも量子計算を体験できる機会が増え、試してみるハードルも着実に下がっています。
こうした標準的な構成になりうるツールがOSSとして公開され、実用化に向けて進んでいる流れにとても魅力を感じています。
この記事では、その面白さや可能性を少しでも多くの方に知ってもらいたいと思い執筆しました。
今後も、より多くのOSSやそれらを活用した量子コンピュータの新しい応用事例が生まれていくことを期待しながら、私自身も何らかの形で貢献していきたいと思っています。