量子×クラウドはなぜ難しい？第2の壁：プログラミングモデルとAPIの分断

おさらい

AWS 105万人 vs 量子エンジニア 1,300人：数字で見る“圧倒的格差”では、量子エンジニアが少ない理由を「技術成熟度の差・参入難易度の差・実行環境の差」という3つの要因で整理し、それら3要因が量子コンピュータをクラウドシステムに統合するにあたっての4つの壁につながることを書きました。

格差を生む3要因	量子×クラウドの4つの壁
技術成熟度の差	第1の壁：ハイブリッドアーキテクチャの複雑性
参入難易度の差	第2の壁：プログラミングモデルとAPIの分断
実行環境の差	第3の壁：量子時代のセキュリティ問題 第4の壁：量子クラウドの待ち行列問題

今回の記事では、上記4つの壁のうち、2つめの壁、 プログラミングモデルとAPIの分断 について、課題を整理します。

2つめの壁、 プログラミングモデルとAPIの分断は、
量子コンピュータを扱うにあたって、クラウドとは必要な知識の素地が違うこと、SDKの学習が必要であることが量子技術への参入ハードルを高くしており、「参入難易度の差」となって、現れてくるものです。

本記事では、1つめの壁であるハイブリッドアーキテクチャの複雑性では触れなかった下記の課題とも関連づけて、整理します。

• SDK の標準化が未完了
• ベンダーごとにAPIが異なる
• 開発ワークフローが確立していない

数値でみる量子コンピュータのプログラミングモデルとAPIの分断

量子コンピュータのプログラミングモデルとAPIの分断が、進んでいると捉えることができる研究や調査データが存在します。

学術的な視点から

Manuel De Stefanoらの研究グループがソフトウェア工学/システムソフトウェア分野の学術誌にて2022年に発表した論文からです。GitHubにおける量子ソフトウェア関連のリポジトリを対象に、量子技術がなぜ利用されるのかを評価することを目的に、「広く使われているフレームワーク」として Qiskit、Cirq、Q#の3つを主要な評価の対象としています。以下のグラフは論文内に掲載されている結果の抜粋になりますが、評価参加者の属性ごとに(オープンソース開発者(OSSDev)、個人開発者(IndDev)、研究者(Resercher)など)使用しているフレームワーク(Qiskit、Cirq、Q#)の分布が示されています。

開発者コミュニティの実態・感覚から

Unitary Fundationという団体が量子技術関連のOSSについて定期的にサーベイを行っており、サーベイの回答者が使用しているフレームワークを調査した結果が掲載されています。
（リンク先のページ内の「Show all」をクリックすると、この調査で回答のあったフレームワークの全項目が表示されます。）

2025年のサーベイでは、回答者の約70%がQiskit、29%がPennyLane、17%がCirqを利用しており、AWS Braket SDKは10％以上使われているとあります。

最近の開発現場の悩みから

Stack Exchangeと呼ばれる質疑応答形式のWebサービスのプラットフォーム（Quantum Computing、Stack Overflow、Software Engineering、Code Review）から収集した量子技術関連の投稿を分析し、主要な議論トピック、トレンド、ツール／フレームワーク、実践者の課題を特定することを目的とした(調査結果)[https://arxiv.org/abs/2503.05240]があります。
下図は、その調査結果に掲載されている調査結果の抜粋になります。この調査では、9つの量子ソフトウェアのSDKが実務者に使われていることが示されており、その中ではQiskitに関するトピックが最も多く、その一方で、Forest、PennyLaneなどに関するトピックもある、ということが報告されています。

各種の調査結果からわかること

調査の視点が異なっているのにも関わらず、以下のような傾向が読み取れるかと思います。

• 学術的な視点では、Qiskit / Cirq / Q# といった複数のフレームワークが最も広く使われている
• 開発者コミュニティの実態・感覚の視点では、Qiskit以外の他SDKも無視できないシェア
• 開発現場の視点では9つの量子フレームワークが実務者に使われている

加えて、ここまで記事を読んでいただいた時点で、量子ソフトウェアのSDKの名前がいくつあったでしょうか。以下のように数えるだけでも6つ以上あります。

• Qiskit
• Cirq
• Q#
• Braket
• Forest
• PennyLane

このことから、複数の量子ソフトウェアSDKが存在し、かつそれらのSDKにユーザーがいることが言えます。

これは、共通言語となるSDKがまだ存在せず、APIが実質的に分断された状態にあることを裏付けたデータであるとも捉えることができます。本記事で挙げた調査結果ではいずれも、Qiskitが最も多く使用されていることが示されていますが、「Qiskitさえ覚えておけばよい」という状況にはならず、場合によっては、複数のSDKをまたぎながらコードやAPIを覚え直さなければならないような構造になっています。

量子ソフトウェアのSDK分断が進む理由

「SDKとハードウェアが密結合している」ことがポイントになります。そして「ベンダーがどのように量子コンピュータをユーザーに提供するか」がその結合をより密にしています。

量子コンピュータのベンダーの代表例として、IBM、Rigetti、IonQ、OQCを挙げて考えてみます。以下の表より、量子コンピュータはベンダーによって、物理方式が異なります。

ベンダー	方式
IBM、Rigetti	超伝導
IonQ	イオントラップ
OQC	光学

今回の記事では、それぞれの方式のメリット、デメリットは割愛しますが、物理方式が違えば、

• 利用できる量子ゲート
• 動作可能な量子回路の深さ
• エラー率
• 量子の結合関係

といった物理的な特性が異なってくるため、最適に量子コンピュータを制御する方法が変わってきます。このため、各ベンダーは自社ハードウェアに最適化したSDKを維持せざるを得ません。

これに加えて「ベンダーがどのように量子コンピュータをユーザーに提供するか」に応じて、サポートしている「SDK」が異なります。

ベンダー	サポートしているSDK	ユーザーへの提供手段
IBM	Qiskit	IBM Quantum / Qiskit Runtime を中心にエコシステムを構築
Rigetti	Forest / pyQuil（Quil）	独自言語（Quil）と周辺SDKでスタックを形成
IonQ	IonQ Quantum Cloud（API）、Qiskit / Cirq	複数SDK（Qiskit / Cirq）のサポートを案内しつつ、自社クラウドの独自APIも提供
OQC	Amazon Braket	Amazon Braket 上での提供

ここまでで、「どのSDKを学習すべきか」という問いに対して、答えが一意に定まらないと思われます。

クラウド最大手のAWSを見てみましょう。AWSは、IBMのように自社開発の量子ハードウェアを持っておらず、他社開発の量子ハードウェアを使って量子技術を利用できるクラウドサービスAmazon Braketを提供しています。

この記事で、量子コンピュータのベンダーの代表例を挙げた4つのうち、IonQ、Rigetti、OQC は Amazon Braket経由でも利用可能です。

Braket SDKにより、それぞれのベンダのSDKをブラックボックスにすることで、ユーザーにとって利便性を高めることができる一方、

• IonQ、Rigetti、OQCが持つネイティブSDK
• ネイティブSDKの差異を吸収するためのクラウドSDK（Braket SDK）

の2層構成となるため、 複数のAPI層を同時に理解する必要がある状態 になりうる環境が生まれます。

同じ“量子回路”でも書き方が違う

SDKが異なると、量子回路を表現する文法・書き方も異なるというは、自明ではありますが、例として、Qiskit、Braket、Cirqでベル状態(量子もつれ)を生成する量子回路のプログラムを示しておきます。

Qiskit

qc = QuantumCircuit(2)
qc.h(0)
qc.cx(0, 1)

Braket

circ = Circuit()
circ.h(0)
circ.cnot(0, 1)

Cirq

q0, q1 = cirq.LineQubit.range(2)
circuit = cirq.Circuit(
	cirq.H(q0),
	cirq.CNOT(q0, q1)
)

量子コンピュータをクラウドシステムに統合しようとすると何が難しい？

ここからが本題です。
量子技術関連の「プログラミングモデルとAPIの分断」によって、クラウドシステムのアーキテクチャを設計をする上で、何が難しくなるのかを見ていきます。

分断に関する課題が量子コンピュータとクラウドシステムを統合する点においてどのような問題に発展するでしょうか。

ポイント1. SDK再学習と検証へのコスト発生

クラウドでは、「マルチクラウド」と呼ばれるリソースの使い方があります。

例えば、クラウドベンダAでは、機能Bがサポートされていないけれど、クラウドベンダBでは機能Bがサポートされているから、どっちも使いたいというケースが考えられます。

クラウドベンダAの障害でQPUが使えない状態を避けたいので、クラウドベンダBのQPUも使えるようにしたいというケースだったり、計算する問題に応じて使用するハードウェアを変える、といったことも考えられます。

以上のようなケースに対応するため、複数のクラウドベンダに跨ってクラウドのリソースを使いたいということがでてきます。

SDKや量子リソースを提供するベンダが異なると、提供される機能や仕様も変わってきますので、各SDKの学習が必要になってきます。

また、同じパフォーマンスを得られるかどうかも考えなけれなりません。

もちろんクラウドベンダも、SDKの互換性が保てるよう、移植することなく他の言語で開発したプログラムを自ベンダの環境で動かせるような、サービスもありますが、互換元の最新バージョンに追従するためのタイムラグだったり、「完全互換」とはいっているものの、実は一部の機能はサポートしていなかったということも起こりえます。

マルチクラウドで量子コンピュータを利用するシステム形態をとると、SDKの再学習や性能検証が必要であるということが、量子コンピュータをクラウドシステムに統合することにおいても、クラウド技術の活用と同様に発生するということを気に留めておく必要がありあそうです。

ポイント2. ベンダーロックインに陥りやすい

クラウドでは、「ベンダーロックイン」という現象があります。
ベンダーの独自技術に大きく依存した製品、サービス、システム等を採用すると、他ベンダーの提供する同種の製品、サービス、システム等への乗り換えが困難になる現象のことです。

サービス提供側から見れば、差別化要素としてのユーザに届ける「価値」になりますが、将来的に乗り換えがあると、必ずしも「価値」になるとは言い難くなります。

現在(記事執筆時点)の量子コンピュータでは、「SDKとハードウェアが密に結合している」ことから、実装したプログラムを他社ベンダーの量子コンピュータで使用できないケースが考えられます。そうなると、プログラムの再利用性が低下が、他ベンダーへの移行難易度を上げることとなり、結果として、他のベンダーへの乗り換えが困難になると言えます。

ポイント3. 開発ワークフローが確立していない

クラウドシステムを使用するにあっての開発（AWS / Azure / Google Cloud）では、

• 設計
• 実装
• テスト
• デプロイ
• 運用・監視

という一連の 標準的な開発ワークフロー が「DevOps」、「DevSecOps」、「CI/CD」と呼ばれる概念の中で、ほぼ共通認識として存在します。

一方で、クラウド上で動作する量子ソフトウェアの開発では、 この「一連の流れ」についての共通認識がまだ定まっていません。

結果として、

• プロジェクトやチームごとに開発手順が異なる
• 別のSDKやQPUに移った場合、開発ワークフローを作り直す必要がある
• 前例を多く持っている経験者の暗黙知に依存しやすくなる

ということが起こり、「コードを書く以前に、どう進めるかを毎回考えて、試行錯誤しながら進める必要がある」という状態になります。

量子コンピュータをクラウドシステムに統合するにあたり、最適なシステムの構造というのは、アプリケーションによって変わってくると思いますが、試行錯誤を前提としたクラウドシステムの設計が必要になると考えられます。

まとめ

量子×クラウドの“第2の壁”である 「プログラミングモデルとAPIの分断」 では、
「参入難易度の差が大きい」ことを起点として、量子コンピュータを統合したクラウドシステムのアーキテクチャを設計するにあたって、以下のような課題が潜んでいると整理できます。

• 量子コンピュータのSDKはすでに複数存在する
  • 「SDKとハードウェアが密に結合している」ため
    • 量子コンピュータのマルチクラウドでの使用は、各SDKの学習が必要であり、同等の性能が得られるかの確認も必要
    • ベンダーロックインに陥りやすく、現時点(記事執筆時点)では移行の難易度が高い
• 量子コンピュータを用いたクラウドシステムの開発フローの共通認識が現時点(記事執筆時点)では出現していない
  • 開発内容に応じて、その都度開発フローを決める必要がある

量子ソフトウェア工学
ちなみに、こういった量子ソフトウェアに関する工学的な事柄を扱う分野として量子ソフトウェア工学(Quantum Software Engineering：QSE)という学問があります。新しい分野も登場していることから、量子技術は高いポテンシャルを秘めていますね。

第2の壁を克服したクラウド技術
クラウド技術が成熟している証のひとつとして、「AI Gateway」という考え方があります。生成AIのLLMサービスへアクセスするインターフェースがサービスを提供するベンダごとにあるため、ユーザーとサービス間にそれぞれのインターフェースの差異を吸収するAPIを挟んで、各種生成AIのLLMサービスに対して、共通のアクセス手段を提供し、クラウドやユーザから簡単にサービスへアクセスできるようにします。

生成AIのLLMサービスが量子APIと同じく分断しているとまでは言い切れませんが、クラウドと生成AIを統合しやすくするため、標準的なアクセス手段が出現している点で、見事、第2の壁を克服していると捉えることができます。

システムのアーキテクチャパターンとしては「Adapter」や「Wrapper」と呼ばれるパターンの特徴がある事例で、オープンソースソフトウェアの実装例としてEnvoy AI Gatewayがあります。Envoy AI Gatewayにご興味がある方は、ぜひこちらの解説記事もご参照ください。

次回予告

次回は、「実行環境の差」を要因として発生する、量子×クラウドの 第3の壁：量子時代のセキュリティ問題 について、整理していきます。