おさらい
AWS 105万人 vs 量子エンジニア 1,300人：数字で見る“圧倒的格差”では、量子エンジニアが少ない理由として「技術成熟度の差・参入難易度の差・実行環境の差」という3つの要因で整理し、それら3要因が量子コンピュータをクラウドシステムに統合するにあたっての4つの壁につながることを書きました。
| 格差を生む3要因 | 量子×クラウドの4つの壁 |
|---|---|
| 技術成熟度の差 | 第1の壁：ハイブリッドアーキテクチャの複雑性 |
| 参入難易度の差 | 第2の壁：プログラミングモデルとAPIの分断 |
| 実行環境の差 |
第3の壁：量子時代のセキュリティ問題 第4の壁：量子クラウドの待ち行列問題 |
いよいよ今回、最後に取り上げるのは4つめの壁、 量子クラウドの待ち行列問題 です。
- 量子プロセッサ(QPU)が物理的に希少
- 極低温に冷却する装置や制御装置が必要
- 実行にはクラウド越しの予約が必要
- QPUに投げた実ジョブは待ち行列に入る
- 実機はノイズの影響を受けるため、計算の再実行が複数回必要になることが多い
上記、太字で示した事柄を出発点に課題を整理します。
量子コンピュータはクラウド経由で利用できる
量子コンピュータはクラウド経由で利用することができ、各社が量子コンピューティングサービスを提供しています。代表的なものとしてAWS (Amazon Web Services)、Microsoft、IBMのサービスを以下に整理します。
| サービス提供元 | 提供サービス名 |
|---|---|
| AWS | Amazon Braket |
| Microsoft | Azure Quantum |
| IBM | IBM Quantum |
Googleの量子クラウドサービス
この表では、クラウド主要ベンダの1つであるGoogleを含めていません。本来であれば、AWS、Azure、Google Cloudと並べたいのですが、量子計算ができる資源をクラウド経由で一般公開しているサービスに絞って整理しています。
Googleの量子コンピュータ関連で出てくる「Google Quantum AI」は、サービス名ではなく、Google社内の研究プロジェクト名という視点で捉えています。
この中に、SDK(Cirq)で書いた量子回路をGoogleの量子プロセッサに送ってジョブとして実行するためのQuantum Engine APIというものがあります。クラウド経由で利用するという構造に着目すれば、量子クラウドサービスとも言えますが、誰でもジョブを投げることができず、承認された人のみに利用が限定されているため、あえて含めない方針で整理しています。
クラウドに慣れたエンジニアやクラウドファースト・クラウドネイティブの観点で「計算リソース」とは、
- 必要になればインスタンスを増やせる
- ノードを追加すればスケールアウトできる
- マルチテナントで同時実行できる
といった具合にAmazon EC2(EC2)、Azure Virtual Machines(Azure VM)、Google Compute Engine(GCE)のような感覚で 「量子コンピュータもクラウド上の計算リソース」と考えたくなります。
しかし、実際のところ量子コンピュータ（QPU）は、この前提と異なる性質を持ちます。量子クラウドサービスの構造から、実際に異なる点を見ていきましょう。
量子クラウドサービスの構造
量子クラウドサービスをレイヤ構造で表してみましょう。まず、従来のクラウドコンピューティング（古典計算）を前提とした環境を整理します。本記事では便宜的にこれを「CPUクラウド」と呼ぶことにし、その構造をレイヤとして整理してみます。
CPUクラウドの構造
普段利用しているクラウドサービスを例に考えてみます。
自分がユーザーとして AWS を利用する場合、まずクラウドサービスの提供者として AWS があります。
その上で EC2 などのクラウドコンピューティングサービスが提供されています。
EC2 を利用するとき、コンソールや API を通して インスタンスタイプ を指定してインスタンスを起動します。
インスタンスタイプは、使用するCPU の種類や性能によって定義されており、例えば Intel や AMD、Arm などの CPU が使われています。
さらに CPU 自体も、x86 や ARM といった CPU アーキテクチャに基づいて設計・製造されています。
CPUクラウドのレイヤ
このように整理してみると、普段利用しているクラウドサービスは、
- ユーザー
- クラウドサービスプロバイダ
- クラウドコンピューティングサービス
- インスタンスタイプ（計算資源）
- CPU
- CPUアーキテクチャ
といような階層的な構造として捉えることができます。これを「CPUクラウド」としてレイヤと役割を整理すると、以下のようになります。
| CPUクラウドのレイヤ | 説明 |
|---|---|
| ユーザー | アプリケーションやワークロードを実行する利用者。API、CLI、コンソールなどを通してクラウドサービスを利用する。 |
| クラウドサービスプロバイダ | クラウドインフラを提供する事業者。代表的な例として AWS、Microsoft、Google がある。 |
| クラウドコンピューティングサービス | 仮想マシンなどの計算リソースを提供するサービス。例として Amazon EC2、Azure Virtual Machines、Google Compute Engine などがある。 |
| インスタンスタイプ | CPU・メモリなどのリソース構成を定義した仮想マシンの種類。ユーザーは用途に応じてこのタイプを選択する。 |
| CPU | 古典コンピュータのプロセッサ。提供する企業の代表的なものとして Intel、AMD、Arm などがある。 |
| CPUアーキテクチャ | CPUの命令セットアーキテクチャ。主に x86 や ARM などが使われている。 |
レイヤの上から下までの関係は、以下です。
- ユーザーは、クラウドサービスプロバイダと契約や利用登録をします。
- クラウドサービスプロバイダと契約・利用登録をすると、ユーザーは、クラウドサービスプロバイダが展開しているコンピューティングサービスにアクセスできるようになります。例えば、EC2をデプロイできるようになります。
- コンピューティングサービスをデプロイするにあたって、ユーザーはインスタンスタイプを選択します。
- インスタンスタイプには CPU・メモリ・ネットワークなどのリソース構成が定義されています。
- インスタンスタイプに応じて、クラウド基盤側で使用されるCPU（Intel / AMD / Arm など）が決まります。
- CPUは x86 や ARM といったCPUアーキテクチャ（命令セット）を実装したプロセッサです。
量子クラウドの構造
では、量子クラウドサービスの場合はどうでしょうか。
同じように構成要素を分解して考えてみます。
量子クラウドを利用する場合も、まずクラウドサービスの提供者として AWS、Microsoft、IBMなどのクラウドプロバイダがあります。
これらのプロバイダは、それぞれAmazon Braket、Azure Quantum、IBM Quantumといった量子クラウドサービスを提供しています。
ユーザーはこれらのサービスを通して量子コンピュータを利用しますが、従来のクラウドでインスタンスタイプを指定するのと同様に、量子クラウドでは 量子バックエンド と呼ばれる計算資源を選択して実行します。
量子バックエンドは、実際に計算を行うQPU（Quantum Processing Unit）に対応しており、例えばIBMのHeronやIonQの装置など、具体的な量子コンピュータが選択対象になります。
さらにQPUも、CPUと同様にハードウェアアーキテクチャに基づいて構成されています。量子コンピュータの場合、その実装方式として 超伝導方式、イオントラップ方式、中性原子方式、光量子方式 など、複数のアーキテクチャが存在します。
量子クラウドのレイヤ
従来のクラウドと対比するため、量子クラウドサービスについても同様にレイヤ構造で整理してみます。本記事では便宜的にこの構造を「QPUクラウド」と呼ぶことにします。
| QPUクラウドのレイヤ | 説明 |
|---|---|
| ユーザー | 量子アルゴリズムや量子回路を実行したい利用者。SDK（Qiskit、Cirq、Braket SDK など）やAPIを通して量子クラウドサービスにジョブを送信する。 |
| クラウドサービスプロバイダ | 量子クラウドサービスを提供するクラウド事業者。Amazon Braket は AWS、Azure Quantum は Microsoft、IBM Quantum は IBM が提供している。 |
| 量子クラウドサービス | 量子コンピュータをクラウド経由で利用するためのサービス。ジョブ送信、バックエンド選択、実行結果取得などのインターフェースを提供する。代表例はAmazon Braket / Azure Quantum / IBM Quantum。 |
| 量子バックエンド | 実際にジョブを実行する量子計算リソースへのエンドポイント。ユーザーは通常、このバックエンドを指定してジョブを送信する。バックエンドにはQPU本体だけでなく、量子回路コンパイルやジョブキュー管理などの実行基盤も含まれる。例としてIBMのHeron、IonQのAria、QuEraのAquilaなどがある。 |
| QPU | 量子コンピュータのハードウェア（QPU）。開発・提供する企業の代表的なものとして、IonQ、Rigetti、Quantinuum、QuEra、D-Wave、IBM などがあり、クラウドサービスを通して計算資源も提供する。 |
| QPUアーキテクチャ | 量子ビットをどの物理技術で実装するかというアーキテクチャ。代表的なものとして 超伝導方式、イオントラップ方式、中性原子方式、光量子方式、量子アニーリング方式などがある。 |
レイヤの上から下までの関係は、以下です。
- ユーザーは、クラウドサービスプロバイダと契約や利用登録をします。
- クラウドサービスプロバイダと契約・利用登録をすると、ユーザーは、クラウドサービスプロバイダが展開している量子クラウドサービスにアクセスできるようになります。
- 量子クラウドサービスへは、 量子バックエンド と呼ばれるエンドポイントを指定して、計算ジョブを送信します。
- 量子バックエンドの先にあるQPU(量子コンピュータ)で計算を実行します。
- QPUは各ベンダによって開発されており、それぞれ 超伝導・イオントラップ・中性原子 などの異なる物理方式（アーキテクチャ）を採用しています。
従来のクラウドと量子クラウドの共通している構造
ここまで、CPUクラウドと量子クラウドの構成要素を並べて比べてみました。両者を対応付けてみると、インスタンスタイプと量子バックエンド、CPUとQPUのように、役割の似た要素が存在していることがわかります。
すると、両者には対応する要素があり、共通する階層構造として整理できそうだということが見えてきます。
そこで、これらの対応関係がわかりやすくなるように、各層に名前を付けて整理してみました。
レイヤ名の整理
最上位のレイヤは、クラウドサービスを利用する主体があります。CPUクラウドでも量子クラウドでも最終的にサービスを利用するのはユーザーであるため、このレイヤを User としました。
次のレイヤはクラウドサービスを提供する事業者です。AWS、Microsoft、Google、IBM などの企業がこれに該当するため、Cloud Provider としました。
その下には、ユーザーが直接利用するクラウドサービスがあります。CPUクラウドでは EC2 や Azure VM、量子クラウドでは Amazon Braket や Azure Quantum などが該当するため、Cloud Service としました。
さらにその下には、実際に計算を実行するために選択する計算資源があります。CPUクラウドではインスタンスタイプ、量子クラウドでは量子バックエンドがこれに対応するため、Compute Resource としました。
その下には計算を行うプロセッサがあります。CPUクラウドでは CPU、量子クラウドでは QPU が該当するため、Hardware としました。
そして最下層には、プロセッサの実装方式があります。CPUでは x86 や ARM、量子コンピュータでは超伝導方式やイオントラップ方式などが該当するため、Hardware Architecture としました。
従来のクラウドと量子クラウドのレイヤ比較
ここまでの説明を図で整理すると、従来のクラウドコンピューティング（本記事で「CPUクラウド」と呼んでいるもの）と量子クラウドサービス（同様に「QPUクラウド」と呼んでいるもの）の関係は、次のようなレイヤ構造で表すことができます。特に、下位レイヤに進むにつれてハードウェアに近づく構造になっている点 に注目してください。
QPUベンダが直接提供しているサービス
この図では、主要なクラウドベンダを出発点に構造を整理しています。この図を見ると、主要な量子クラウドサービスからアクセスしないとQPUが使えないように見えますが、例えば、D-Wave社のQPUはAmazon Braket経由をしなくとも、D-Wave社のLeapと呼ばれるクラウドサービスから直接利用することも可能です。
量子コンピューティング業界のねじれ
この構造を見ると、量子クラウドには大きく2種類のプレイヤーが存在することがわかります。
AWS や Azure は、一般のクラウドサービスではトップクラスのシェアを持つクラウドサービスプロバイダですが、量子コンピュータのハードウェア（QPU）は自社で提供していません。一方で IBM は、量子コンピュータのハードウェアとクラウドサービスの両方を自社で提供する 垂直統合型のプロバイダです。このシリーズ記事の初回記事タイトルにもあったAWS 105万人 vs 量子エンジニア 1,300人で表現すれば、
- 105万人以上の認定資格者を携え、クラウドシェアが大きいクラウドサービスプロバイダ（AWS / Microsoft)
- たった1,300人の量子開発認定資格者を携え、量子ハードウェアとクラウドサービスを自社で統合して提供しているクラウドサービスプロバイダ（IBM）
という、少しねじれた構造になっています。この「クラウド vs ハードウェア」の分業構造は、量子コンピューティング業界のおもしろい特徴の一つと言えるでしょう。
量子クラウドの特徴
レイヤの構造を観察してみると、量子クラウドサービスも私たちが普段利用しているCPUベースのクラウドと同様に、クラウドサービス、計算ハードウェア、アーキテクチャといった階層的な構造を持っていることがわかります。つまり、Amazon EC2 などの従来のクラウドサービスとよく似た構造を持っていると言えます。
しかし、下位レイヤに目を向けると計算ハードウェアに相当するHardware、Hardware Architectureのレイヤでは、CPUを搭載した一般的なサーバーとは大きく異なる性質や特徴があります。
従来のクラウドでは、仮想化や抽象化によってハードウェアの違いが隠蔽されており、ユーザーはインスタンスタイプを選択するだけで計算資源を利用できます。一方、量子クラウドでは、QPUのアーキテクチャや特性がサービス利用に直接影響するため、計算ハードウェアの物理的制約が現れます。
その違いを理解するために、量子コンピュータ（QPU）のアーキテクチャに注目してみましょう。
量子コンピュータ(QPU)は、CPUを積んだ普通のサーバーとは異なる
「量子コンピュータ」と言っても、量子ビットの実装方法に応じて、複数の方式(アーキテクチャ)が存在します。一般的な方式とクラウド視点での特徴を以下に整理しました。
| 方式 | 主要企業 | 量子ビットの物理実装 | 物理環境の要件 | クラウド視点での特徴（設置・運用インフラの重さ） |
|---|---|---|---|---|
| 超伝導方式 | IBM, Google, Rigetti, 富士通 | 超伝導回路 | 極低温（希釈冷凍機） | 極低温インフラ前提で設備が大型・重量級。データセンター側は電力・冷却・振動対策を含めた専用設計になりがち |
| イオントラップ方式 | IonQ, Quantinuum | 真空中のイオン | 超高真空＋精密レーザー制御 | 真空＋レーザー光学で装置が大型化しやすい。温度は極低温ほど厳しくないが、光学調整・安定化の運用負荷が重い |
| 中性原子方式 | QuEra, Pasqal | レーザーで捕捉した中性原子 | 真空環境＋光ピンセット制御 | 真空＋多ビーム光学で中〜大型になりやすい。配線は比較的軽いが、光学系の拡張と安定化がボトルネックになりやすい |
| 光量子方式 | Xanadu, PsiQuantum, NTT | 光子 | 高精度光学系・光子源 | 極低温は不要だが、光学ベンチ／配線が嵩張り大型化しやすい。環境安定化（温度・振動・位相）が運用課題 |
| 量子アニーリング方式 | D-Wave | 超伝導回路 | 極低温（希釈冷凍機） | 超伝導同様に極低温インフラで設備は大型。クラウド提供はしやすいが、用途は最適化系に限定される |
「量子アニーリング方式」という用語は、本来は計算モデルを指す用語
この表に「量子アニーリング方式」を含めることに違和感があるかもしれません。しかし、記事執筆時点でアプリケーションが存在し、事業としての活用事例があるので、本記事では一つの方式として整理しています。量子アニーリング方式も超伝導回路を用いますが、汎用的にさまざまな計算を行うタイプではなく、組合せ最適化問題を解くことに特化した方式です。
理科の授業に出てくるような単語がありますが、量子コンピュータをクラウドの資源として扱うエンジニアとしての視点で重要なのは、「どの方式が優れているか」とか「どういう物理現象を応用しているか」よりも、いずれの方式も通常のサーバーとはまったく異なる物理環境の要件(物理的制約)の上に成り立っているという点です。
物理環境の要件(物理的制約)の違い
私は、量子コンピュータに対して、IBMの量子コンピュータを挙げて、「量子コンピュータは巨大な冷凍庫だ」と捉えています。これは、超伝導方式のことを指しています。超伝導方式では、量子ビットを安定させるために、約10mK（絶対零度に極めて近い温度）まで冷却する必要があります。これはデータセンターの空調設備でどうにかなるレベルではなく、希釈冷凍機と呼ばれる専用の冷凍機が必要になります。
一方、他の方式でも物理環境の要件が異なります。
- イオントラップ方式では、超高真空装置と高精度レーザー制御が必要
- 中性原子方式でも真空環境とレーザーによる原子捕捉が必要
- 光量子方式は常温動作が可能だが、極めて高精度な光学系や光子源が必要
- 量子アニーリング方式 は実用レベルで稼働しているが、極低温環境が必要
どこかの実験室みたいな要件が並んでいますが、方式が異なっていても、次の点が共通しています。
- 物理的制約が大きい（極低温、超高真空、光学系など）
- 製造コストが高い
- キャリブレーションやメンテナンスの調整時間がある
- 提供ベンダーが限られている
つまり、QPUは「ラックに積めるサーバー」ではなく、高度に制御された実験装置に近いものと言えます。
量子コンピュータをクラウドシステムに統合する際に物理的制約を起因として発生する問題
ここからが本題です。このような物理的制約がある量子コンピュータ従来のクラウドと統合すると、以下のような問題が出てきます。
ポイント1. 量子コンピュータは「スケールアウト」できない
クラウドの世界では、
- 負荷が増えたらインスタンスを増やす
- ノードを追加して水平スケールする
という発想が自然です。
これはオンプレミス環境と比べて、インフラをすばやくデプロイ・増設できるという点で、クラウド技術の強みとして、ずっと言われていることです。具体的なものとしては、
- 必要になったらサーバーをどんどん増やせる（スケールアウト）
- コンテナやサーバーレスで自動でふくらませられる
といったことが挙げられます。
しかし QPU は、1台あたりの環境コストが高く、物理的な制約も強いため、台数が少なくなりがちで、CPUと比べて「どんどん台数を増やす」という考え方が取りづらいです。
そのため、QPU は「世界中のユーザーで共有して使う、高級な計算装置」という扱いになりやすく、
- 「QPUをラックに差して増設する」
- 「オートスケールで台数を増やす」
ということが、記事執筆時点では現実的ではありません。物理的に巨大で、繊細で、高価で、調整に時間がかかる装置ですから、量子コンピュータはクラウド的なスケールアウト前提の設計になっているリソースではない ということになります。
ポイント2. QPUは「単一リソース」として扱われる
物理的に巨大で、繊細で、高価で、調整に時間がかかる装置で、スケールアウトができないことを踏まえると、QPUは 世界中のユーザーが共有して使う「希少な単一リソース」 という扱いになります。
このため、クラウドの仮想マシンのように 好きなだけ起動して捨てるという使い方はできません。例えば、AWSのEC2はコンソールを使ってユーザー側でON/OFFしたり、リソースを破棄することができますが、IBM Qの量子コンピュータは、ON/OFFできません。共有資源ですので、ユーザーの一人が勝手にOFFにしてしまったら、他に使っている人が使えなくなってしまいます。
システム開発において、システムの価値の根幹となる機能に加えて、システムの運用方法も見据えて開発を進めるDevOpsという考え方の中では、開発の実践内容(プラクティス)として、クラウドシステムを構成するインフラやリソースの使い捨てを前提とする設計パターンがあります。例えば、「Disposable Infrastructure」や「Immutable Infrastructure」と呼ばれるパターンです。その目的は、クラウドシステムを構成するリソースの設定内容の差異を防ぎ、インフラの一貫性と再現性を高めるためにですが、量子コンピュータのリソースは、使い捨てを前提に使用することができないのが現状です。
以上のように、CPUサーバーのように「各ユーザーに専用マシンを割り当てる」ことは難しく、ジョブは一旦キューに入り、順番待ちをすることになります。ここで発生するのが、量子コンピュータ特有の待ち行列問題です。
ポイント3. 順番待ち時間の原因が複数ある
待ち行列が発生する理由は、「希少な単一リソース」だから、だけではありません。物理的な性質からさまざまな原因があります。
ポイント3-1. QPU上では基本的にジョブを同時実行できない
CPUサーバーであれば、
- マルチコア
- マルチスレッド
- VM／コンテナ分離
といった技術によって、複数ユーザーのジョブを同時に実行できます。
しかし量子コンピュータでは、原則として1つの量子回路がQPU全体を専有する仕組みになっています。これらを分割してマルチテナントのような形で実行することは技術的に研究段階であり、CPUのように
- 空いているコアに別ジョブを載せる
- 時間分割でスケジューリングする
といった発想は取りにくく、同一QPU上で同時にジョブ実行ができないのが現状です。
その結果、ジョブは物理的に順番待ちになってしまいます。
ポイント3-2. 1ジョブあたりの実行が重い
量子計算は、CPU上での通常の計算とは異なり、確率的な結果を出力します。
1回のジョブ実行で得られるのは1つの測定結果のみであり、統計的に意味のある結果を得るのに、同じ回路を1ジョブ内で何百回〜何万回も繰り返し実行します。
つまり、1ジョブ = 同じ回路の大量ループ実行ということになります。このため、1ユーザーのジョブがQPUを占有する時間は自然と長くなります。そして、オンプレミスとは異なり、クラウドサービスでは、
- 他人のジョブの内容
- そのジョブがどれくらいで終わるか
- ジョブの優先度やスケジューリング
といった実行キューの情報は公開されておらず、ユーザーから見ればブラックボックスとなっています。
これに加えて、量子ビットごとに特性が異なり、誤り率もそれぞれ異なります。大規模な計算をする場合、誤り率が高ければ高いほど、量子コンピュータが出力する確率分布は、発散してしまい、理想結果から大きくずれるため、意味のある結果を出力することが困難になります。このため、誤り率が低く、精度のよい量子ビットを持つ特定のQPUにジョブが集中し、混雑することも考えられます。
量子回路の繰り返し実行
量子コンピュータでは、1回の実行だけでは結果が確率的にしか得られません。そのため同じ量子回路を多数回実行し、測定結果の確率分布を統計的に推定します。この繰り返し実行の回数は ショット数（shots） と呼ばれます。1ショットは、量子装置上で次のようなサイクルとして実行されます。
- 初期化
- 量子回路の実行
- 測定
- リセット
このサイクルを1回実行することが 1ショット です。量子計算ではこのショットを何百〜何万回も繰り返し、結果の分布を得ます。
量子クラウドでは、ユーザーはこれらの実行を ジョブ(job) として送信します。ジョブには実行する量子回路やショット数などの設定が含まれ、クラウド側でキューイングされてQPU上で実行されます。
クラウドの観点で言えば、量子コンピュータ上の計算の実行単位は次のように整理できます。
- ジョブ (job)：クラウドに送信する実行リクエスト
- 量子回路 (circuit)：実行する量子プログラムを表す回路
- ショット数 (shots)：同じ量子回路の繰り返し実行回数
量子計算は、単にアルゴリズムを一度実行するというより、制御された物理実験を多数回繰り返して統計的な結果を得る計算モデルになっています。
ポイント3-3. 再実行とパラメータ探索
記事執筆時点の量子コンピュータはノイズが多く、
- パラメータを変えて何度も実行する
- エラーを確認するために再実行する
といった試行錯誤が必要になります。結果として、1つのアルゴリズム実行が、実質的には多数のジョブ投入になることもあります。
ポイント3-4. キャリブレーションという「見えない停止時間」
量子コンピュータは非常に繊細なハードウェアのため、
- 計算ユニットや処理操作のエラー率を継続的に測定
- 制御パラメータ（信号や光など）を調整
- 装置の動作環境（温度など）を安定化させる
といった運用作業やキャリブレーションが定期的に必要になります。これらの作業中はユーザーのジョブが実行できない場合があります。クラウド的に言えば、定期的にノードがメンテナンスモードに入るような状態です。
まとめ
量子コンピュータの待ち行列は、
- 台数が少ない
- スケールアウトできない
- 同時実行が難しい
- 1ジョブが重い（ショット）
- キャリブレーションによる停止がある
という物理的制約を起因として発生します。
そして、量子コンピュータはCPUサーバーの延長線上にあるクラウドリソースではなく、世界中のユーザーが共有する、希少で排他的な装置であるとして、整理しました。
待ち行列を解消するために量子コンピュータを買う
クラウド上の量子コンピュータは便利ですが、待ち行列の長さに悩まされるとすれば、「手元で自由に使える環境が欲しい」と考えるのも自然でしょう。生成AI分野では「ローカルLLM」という流れが生まれましたが、同様に自社内にQPUを設置する「ローカルQPU」や「オンプレQPU」といった流れが今後現れるかもしれません。
おわりに
2025年の10月初旬にQiskitの量子開発者認定資格のバージョンアップがありました。
この出来事をきっかけに、本シリーズ最初の記事タイトルにもあるAWS 105万人 vs 量子エンジニア 1,300人という、クラウドエンジニアと比べて量子エンジニアが少ないという構造が浮き彫りになりました。
この構造を出発点に、量子コンピュータを従来のクラウドと統合し、従来のクラウド上のリソースで扱うとどのような課題があるのかを技術、組織、環境の3点(TOEフレームワーク)から俯瞰し、「4つの壁」として整理していきました。
その結果、私は今回の「第4の壁」に行きつきました。
量子コンピュータの活用が始まりつつある一方で、昨今は生成AIの活用が大きなトレンドになっています。将来、量子コンピュータで解いたほうが速い問いを生成AIへ投げるようになれば、生成AIを経由して量子コンピュータを使うという形で、活用が一気に広がるかもしれません。
今回のシリーズ記事を書きながら、考えを整理していく中で、量子コンピュータの議論は、アルゴリズムやハードウェア性能に焦点が当たることが多いと感じました。プレスリリースも、「量子ビット数が拡大」や「誤り訂正が改善」といった話題から始まるものをよく目にします。
一方で、クラウドアーキテクチャの視点から量子コンピュータをクラウド上のリソースとして捉え、どのように利用するかを考えてみると、また別の論点があることにも気づきました。
「クラウド」という言葉から連想される柔軟性とは異なり、現時点の量子クラウドは物理的制約(実行環境)があり、 従来のクラウドファーストやクラウドネイティブにおける設計の延長線上では扱いにくい 部分がある、というのが整理してみた中での率直な印象です。
こうした特性を踏まえた量子クラウドリソースの利用モデルやアーキテクチャについては、今後もう少し議論が広がっていくのではないかと思っています。
この記事が「壁」シリーズ、最後の記事となります。今回も連載記事に対するフィードバックとして、興味を持ってくださった方、いいねやストックしてくださった方がいらっしゃることが励みになり、「第4の壁」まで記事を書ききることができました。これからも、どうぞよろしくお願いします。ありがとうございました。