従来のアプリとの量子コンピューティングの統合

一部の計算問題は、大規模なスーパーコンピュータであっても、古典的なコンピュータでは解決できない、または難解です。 これらの問題の一部では、量子アルゴリズムは、最もよく知られている古典的アプローチよりもはるかに少ないリソースを使用してソリューションに到達できます。 量子コンピューターは、重ね合わせやエンタングルメントなどの量子機械的効果を使用して、従来のコンピューターではできない方法で情報を表し、処理します。

量子プログラムは、ジョブを送信することによって到達する 量子プロバイダー で実行されます。 量子ターゲットは、異なる ターゲット プロファイルを公開します。 一部のプロファイルでは量子演算のみが許可され、それらに対して実行できる古典的なロジックは制限されています。 他のプロファイルを使用すると、量子操作と従来の操作の両方をプロバイダーで一緒に実行できます。

ターゲット プロファイルに関係なく、従来のコンピューティング コンポーネントは、周囲のアプリケーション統合を処理します。 量子ターゲットが従来の操作を受け入れた場合でも、ジョブを送信して結果を待機することでターゲットに到達します。 この記事では、量子作業を従来のアプリケーションと統合するための 2 つのオーケストレーション モデルについて説明し、比較します。

実際には、量子プログラムの実行はサービス呼び出しです。 従来のアプリケーションまたはクライアント コードは、ジョブをターゲットに送信し、ジョブの実行を待機して、結果を取得します。 1 つ以上の従来のコンピューティング コンポーネントは、次のアクティビティを実行して各量子ジョブを調整します。

• 入力データの準備
• ターゲット量子環境への量子コンピューティング ジョブ の送信
• ジョブ実行の監視
• ジョブ結果の後処理

量子統合モデル

量子作業を従来のアプリケーションと統合するには、次の 2 つのオーケストレーション パターンのいずれかを使用します。

• 直接量子統合。 クライアント アプリケーションまたは軽量クラシック ハーネスは、Azure Quantum ワークスペースと直接やり取りします。 クライアントは、入力の準備、ジョブの送信、監視、結果処理、量子実行を囲む古典的なロジックを所有しています。

• ワークフローで調整された量子統合。 ワークフロー オーケストレーターは、全体的な状態と遷移を所有します。 量子実行は、ハイ パフォーマンス コンピューティング (HPC) またはグラフィックス処理装置 (GPU) コンピューティングで実行されるステップと共に実行されるワークフロー ステップで発生します。

特定のアプリケーション統合境界の場合、これらのパターンは代替手段です。 クライアントがワークスペースと直接統合されているか、より広範なワークフローが量子ステップを所有しています。 この記事では、各パターンの実装について説明します。

統合の選択は、従来の計算の実行場所とは無関係です。 ターゲット プロファイルとワークロードに応じて、従来のロジックは、量子プログラム内、量子実行間のクライアント ハーネス、ワークフロー オーケストレーター内、または HPC または GPU コンピューティング上の従来のワークフロー ステップで実行できます。

デシジョン マトリックス

次の決定マトリックスを使用して、統合パターンの選択をガイドします。

ワークロードにこれらの特性がある場合	このアプローチを使用する
1 つのアプリケーションまたは軽量ハーネスが完全な量子ジョブ ライフサイクルを所有し、入力の準備と結果処理がそのクライアント内に収まります。	直接量子統合
手書きの量子コードを使用して量子ハードウェアのプロパティを調べ、1 つのアプリケーションまたは少数の関連アプリケーションが結果を使用します。	直接量子統合
古典側は処理負荷が大きく、量子処理を多段階パイプラインの多くの工程のうちの1つとして組み込みます。このパイプラインでは、各ステージがHPC、GPU、または量子ターゲットなど、それぞれに適したバックエンド上で実行されます。	ワークフローで調整された量子統合
量子実行が繰り返され、1 回の実行の結果によって次の量子プログラムが生成されるか、そのパラメーターが決定されます。	ワークフローで調整された量子統合

シナリオの詳細

どちらのワークフローも、非同期 Request-Reply パターンと、Azure Quantum ジョブのライフサイクルに対して定義されたステップを実装します。

量子ターゲット 、特に量子ハードウェアは限られたリソースです。 Azure Quantumは、ジョブ キューを介してこれらのリソースを割り当てます。 ジョブを送信すると、ジョブは選択したターゲットのキューに入り、そのターゲットが以前のエントリを完了した後に実行されます。 予想される待機時間を確認するには、 使用可能なターゲットを一覧表示します。 全体の応答時間は、キュー待機時間とジョブ実行時間の合計として計算します。

量子ターゲットの機能も異なります。 一部のターゲットは量子演算のみを受け入れ、他のターゲットは単一のジョブで量子演算を使用して古典的なロジックを実行します。 このモデルでは、実行中に適応するアルゴリズムがサポートされています。 ターゲットにコミットする前に、アルゴリズムに必要な操作がサポートされていることを確認します。 従来の命令と量子命令の連携の詳細については、「 ハイブリッド量子コンピューティングの概要」を参照してください。

直接量子統合

以降のセクションでは、量子作業を従来のアプリケーションと統合するための直接統合モデルについて説明します。

建築

このアーキテクチャのPowerPoint ファイルをダウンロードします

データ フロー

次のデータ フローは、前の図に対応しています。

1. サインインしているユーザーは、従来のクライアント アプリケーションを使用して量子ジョブの実行をトリガーします。

2. クライアント アプリケーションは、データをAzure Storageに入力します。

3. クライアント アプリケーションは、実行ターゲットまたはターゲットを指定して、Azure Quantum ワークスペースにジョブを送信します。

   クライアントは、構成からワークスペースを識別し、Microsoft Entra ID を使用してワークスペースに対して認証を行います。 Azureホストされているリソースで実行されるクライアントは、マネージド ID を使用できます。 ローカル クライアント アプリケーションは、サービス プリンシパルや対話型ユーザー サインインなどの別のMicrosoft Entra ID で認証します。

4. 量子プロバイダーは、ターゲット環境でジョブを実行します。

5. クライアント アプリケーションは、ジョブの状態をポーリングしてジョブの実行を監視します。

6. 量子ジョブが完了するとすぐに、クライアント アプリケーションは Storage からコンピューティング結果を取得します。

コンポーネント

• Azure Quantum は、Azure ポータルからアクセスできる workspace を提供します。これは、さまざまなターゲットでの量子ジョブの実行に関連する資産です。 ジョブは、選択したプロバイダーに応じて、量子シミュレーターまたは量子ハードウェアで実行されます。
• Microsoft Entra IDは、ユーザー認証を調整し、Azure Quantum ワークスペースへのアクセスを保護するのに役立ちます。
• Storage は、量子プロバイダーからの入力データと結果のストレージを提供します。

直接統合の潜在的なユース ケース

直接量子統合パターンは、次のユース ケースに適合します。

• 1 つのクライアント アプリケーションまたは軽量クラシック ハーネスは、より広範なワークフローなしで完全な量子ジョブ ライフサイクルを所有します。
• クライアントは、入力の準備や結果の処理などの周辺の従来型処理を実行できます。
• 量子ハードウェアのプロパティを調べるので、通常は動的に生成するのではなく、量子コードを手書きします。
• 量子コンポーネントの使用は、1 つのアプリケーションまたは少数の関連アプリケーションに限定されます。
• 量子ジョブは、分子シミュレーションなどの特殊なソリューションを表し、1 つの特殊な古典的アプリケーションのみが使用します。

ワークフローで調整された量子統合

以降のセクションでは、量子作業を従来のアプリケーションと統合するためのワークフローで調整されたモデルについて説明します。

建築

ワークフロー ロジックは、特定のホストまたはプロバイダーに依存しません。 次のフローチャートは、ステート マシンを示しています。1 つの入力、ステップのループ、ステップごとのフェーズです。 量子分岐には、従来の手順では使用しないオプションのプログラム生成と最適化フェーズを含めることができます。

前のフローチャートのバックエンド セレクターは、必須コンポーネントではなく論理フェーズであり、各ステップを固定バックエンドの種類にルーティングする構成参照にすることができます。

量子作業を送信して監視する一連の古典的なサービスを使用して、Azureでこのワークフローをホストできます。 次の図は、トポロジの例を示しています。

このアーキテクチャのPowerPoint ファイルをダウンロードします

データ フロー

次のデータ フローは、デプロイ トポロジに対応しています。

1. クライアント アプリケーションは API Management を介して要求を送信します。これにより、Microsoft Entra IDで呼び出し元が認証され、要求がコンピューティング レベルに到達する前に調整が適用されます。
2. API Management は、要求を検証してワークフロー オーケストレーターを開始する HTTP によってトリガーされる関数である Input API に要求を転送します。
3. 従来の手順では、オーケストレーターによって実行が従来のバックエンド (HPC クラスターや GPU コンピューティングなど) にルーティングされます。
4. 従来のバックエンドは、その結果と更新されたパイプラインの状態を Storage に書き込みます。
5. 量子上で実行されるステップの場合、オーケストレーターは量子パスを介して実行をルーティングします。 量子パスは、ステップのプログラムを準備し、ステップの入力から生成して最適化するか、固定実装を使用して、ジョブを Azure Quantum ワークスペースに送信します。 送信は マネージド ID を介して認証されます。
6. ワークスペースは、選択した量子ターゲットでジョブを実行します。
7. 量子ターゲットは、その結果を Storage に書き込みます。
8. オーケストレーターは、更新された状態ストレージを読み取り、パイプラインの遷移ロジックを評価します。 収束または反復条件で別の量子実行が必要な場合、オーケストレーターは結果を使用して、次の量子プログラムのパラメーターを決定するか、次のプログラムを生成する入力を提供します。 その後、パイプラインは適切な手順に戻ります。
9. クライアントは、API Management を介して Status API をポーリングして進行状況を追跡し、パイプラインが終了状態に達したときに最終的な結果を取得します。

コンポーネント

• Durable Functionsはワークフロー オーケストレーターとして機能し、パイプラインをステート マシンとして実行し、ステップを調整し、各ステップの実行に対して量子またはその他のコンピューティングの種類のバックエンドを選択します。 オーケストレーターは、Durable Functionsまたは別のワークフロー エンジンを使用して実装できます。
• HPC と GPU の従来のコンピューティング バックエンドAzure、非量子ステップを実行します。
• Azure Functionsは、ワークフローを開始および監視する HTTP API と、それを実行するオーケストレーターをホストします。
• API Management は、クライアント要求のエントリ ポイントです。 呼び出し元を認証し、スロットリングを適用します。 関数アプリが直接呼び出されないようにするには、受信アクセス制限やプライベート エンドポイントなどのAzure Functionsネットワーク オプションを使用して、API Management からのトラフィックのみを受け入れるようにします。
• Azure Quantumは、量子ジョブの実行に関連付けられている資産のワークスペースを提供します。 選択したターゲットに応じて、量子シミュレーターまたは量子ハードウェアでジョブが実行されます。
• Microsoft Entra IDは認証を調整し、Azure Quantum ワークスペースへのアクセスを保護するのに役立ちます。
• ストレージ には、入力データ、中間パイプラインの状態、および結果が格納されます。

選択肢

この記事のアーキテクチャでは、量子ターゲットでコンピューティング タスクの一部を実行します。 コンピューティングの課題によっては、 ハイ パフォーマンス コンピューティング を実行したり 、AI 機能 を提供したりするために構築された既存のサービスが代替になる場合があります。

科学研究開発のワークロード向けに、Microsoft Discovery は AI を使用して、モデル、ツール、コンピューティング リソースにまたがる複雑なタスクをオーケストレーションします。 Microsoft Discovery では、複数のステップにまたがるさまざまなツールを調整でき、拡張可能であるため、オーケストレーションを自分で構築して操作する代わりに、独自のツールとエージェントを接続できます。 量子ステップの実行を含む量子機能との統合では、AI を使用して、このパターンが手動で構築するオーケストレーションを実行できます。

ワークフローで調整されたシナリオの詳細

このパターンでは、ワークフロー オーケストレーターは、ステップのパイプラインとしてワークロードを実行します。 オーケストレーターは、終了または収束条件が満たされるまでステップを繰り返しループするステート マシンのように動作します。 各ステップは同じ図形に従います。入力を準備し、実行し、出力を処理します。

オーケストレーターは、各ステップを実行するバックエンドを選択します。 この選択は、個別のサービスではなくオーケストレーション ロジックの一部であり、構成から各ステップのターゲット バックエンドを読み取るのと同じくらい簡単です。 ステップは、量子バックエンドまたは HPC クラスターや GPU コンピューティングなどの従来のコンピューティングで実行されます。 軽量のクラシック ステップは、オーケストレーター自体で実行できます。 量子ステップが繰り返されると、ワークフローは 1 つの量子実行の結果を処理して、次の量子プログラムのパラメーターを決定するか、次のプログラムを生成する入力を提供します。

量子バックエンドで実行されるステップは、従来のステップにはない 1 つのフェーズを追加できます。 このフェーズでは、実行前に量子プログラムが生成され、最適化されます。 このフェーズは省略できます。 プログラムは、ステップの入力から動的に生成することも、このフェーズをスキップする固定実装から生成することもできます。 量子実行が可能なステップであっても、その方が入力により適している場合は、古典バックエンドで実行されることがあります。

量子化学は代表的な例です。 一般的なパイプラインでは、従来の手順を使用して、ジオメトリの最適化、自己一貫性のあるフィールド計算、アクティブ空間の選択という分子システムを準備します。 その後、パイプラインは、分子の基底状態エネルギーなどのターゲット プロパティを計算します。 エネルギー コンピューティングの手順は、古典的な近似または量子アルゴリズムのどちらで実行されるかに関係なく、同じ意図を保持します。 必要な精度と問題のサイズに基づいてバックエンドを選択します。

QDK/Chemistry ライブラリは、次のようなパイプラインをサポートしています。 このライブラリは、古典的な準備手順と、古典的に計算された波関数から状態準備回路を生成するためのモジュール式コンポーネントを提供します。これは、量子バックエンドが量子位相推定などのアルゴリズムを使用してエネルギーを推定するために使用します。 この回路生成機能は、ステップの入力から量子プログラムを動的に生成する具体的な例です。

潜在的なユース ケース

ワークフローで調整された量子統合パターンは、次のユース ケースに適合します。

• 古典的な側面は大規模で問題状態の論理を中心としており、量子的な能力は多くの処理工程の中の1段階または数段階として利用します。
• ワークロードは、多くの場合、ステート マシンのように反復的なマルチステージ パイプラインです。 各ステージは、HPC、GPU、または量子ターゲットに最適なコンピューティング バックエンドで実行されます。 量子コンピューティングは、1 つまたは複数のステージの 1 つのオプションです。
• 量子ステップは、分子特性を計算する科学的計算など、明確に定義された構成要素を表します。 正確な量子コードは、実際の入力に合わせて動的に生成および最適化される場合もあります。
• ワークフロー オーケストレーターは、複数の自己完結型量子実行とその間の古典的な処理を所有します。 1 回の実行の結果は、次の量子プログラムのパラメーターを決定するか、次のプログラムを生成する入力を提供します。 反復位相推定 は、変動量子固有ソルバ (VQE) や量子近似最適化アルゴリズム (QAOA) などの変動アルゴリズムと同様に、この構造に適合します。

考慮 事項

これらの考慮事項は、ワークロードの品質向上に使用できる一連の基本原則である Azure Well-Architected Framework の要素を組み込んでいます。 詳細については、「 Well-Architected Framework」を参照してください。

確実

信頼性は、アプリケーションが顧客に対して行ったコミットメントを確実に満たすことができるのに役立ちます。 詳細については、「信頼性の設計レビュー チェックリスト」を参照してください。

量子ジョブはリモートの共有ターゲットで実行されるため、ターゲット タイムアウトなどの一時的なエラーからジョブの実行が失敗する可能性があります。 選択した統合パターンに関係なく、ジョブの実行を監視して、ジョブの状態をユーザーに表示できるようにします。 一時的なエラーが原因でジョブが失敗した場合は、 再試行パターンを適用します。 非同期呼び出しでジョブを送信し、呼び出し元のクライアントをブロックせずに済むよう、結果をポーリングして確認します。

量子コンピューティング機能の可用性は、 量子コンピューティング プロバイダーの可用性と容量の特性に大きく依存します。 コンピューティング 先によっては、従来のクライアント アプリケーションで長い遅延が発生したり、ターゲットが使用できなくなったりする場合があります。

周辺のAzure サービスについては、通常の可用性に関する考慮事項が適用されます。 必要に応じて、冗長性Azure Storageレプリケーション オプションの使用を検討してください。

ワークフローで調整された統合の信頼性

• ワークフローで調整された統合で高可用性を実現するために、 可用性ゾーン または 複数のリージョンに API Management をデプロイします。 ゾーンの冗長性には Premium または Premium v2 レベルが必要であり、マルチリージョンのデプロイには Premium レベルが必要です。

• Durable Functionsを使用してオーケストレーターを実装する場合は、関数アプリとその状態を独立したサービスとして扱うのではなく、ディザスター リカバリーをユニットとして計画します。 Durable Functions は、すべてのオーケストレーション状態をストレージ バックエンド内のタスク ハブに永続化します。既定のストレージ バックエンドは Azure Storage です。 ランタイム状態とコンピューティングはそのタスク ハブを介して結合されるため、関数アプリを 2 番目のリージョンにプロビジョニングし、Storage を個別にレプリケートしても、安全なフェールオーバーは定義されません。 オーケストレーションは、トポロジに応じて、一時停止したり、最近のトランザクションを失ったり、リージョン間のタスク ハブを読み取ったりすることができます。

  安全なフェールオーバーの場合は、Azure Front DoorやAzure Traffic Managerなどのグローバル負荷分散サービスによって前面に配置された、セカンダリ リージョンにフェールオーバーするアクティブ/パッシブ構成を使用します。 アプリへのアクセスを API Management からのトラフィックのみに制限する制御によって、これらのサービス正常性プローブもブロックされる可能性があるため、ネットワーク制限下でもサービス正常性プローブが関数アプリにアクセスできることを確認してください。 データ損失とリージョン間待機時間の許容範囲に一致するトポロジを選択します。 調整されたオプションとそのトレードオフについては、Durable Functionsでのディザスター リカバリーと geo 分散に関する説明を参照してください。

セキュリティ

セキュリティは、意図的な攻撃や貴重なデータとシステムの誤用に対する保証を提供します。 詳細については、セキュリティ設計レビューのチェックリストを参照してください。

選択した統合パターンに関係なく、量子ジョブを囲む従来のサービスに次の強化プラクティスを適用します。

• Microsoft Entra ID を使用してAzure Quantumとその周辺サービスに対する認証を行い、サービスがサポートするローカル認証をオフにします。 マネージド ID は、 ホスティング環境でサポートされている場所であればどこでも使用してください。 マネージド ID を使用できないクライアントの場合は、サービス プリンシパルや対話型ユーザー サインインなど、別のMicrosoft Entra ID で認証します。

• ストレージにアクセスする各コンポーネントに対し、そのコンポーネントのスコープで、Microsoft Entra ID を使用した Azure ロールベースのアクセス制御 (Azure RBAC) を通じて、必要なデータ プレーンへのアクセスを付与します。 アプリケーション コードにストレージ アカウント キーを埋め込まない。

一般に、必要に応じて 、Well-Architected Framework のセキュリティに関する推奨事項を適用します 。

直接量子統合のセキュリティ

ワークフローで調整された量子統合とは異なり、このパターンでは、1 つのクライアントが Azure Quantum ワークスペースにアクセスすることを前提としています。 通常、クライアントは、ワークフロー全体の状態ではなく、ジョブの送信と運用に重点を置く軽量な従来型ハーネスです。 このシナリオでは、次の構成が行われます。

• クライアントは既知であるため、固定 ID を指定できます。 Azureホストされているリソースでクライアントを実行する場合は、マネージド ID をそれに関連付けます。 クライアントがAzure外で実行されている場合は、サービス プリンシパルまたは対話型ユーザー サインインを使用します。

• クライアント自体でリクエストのスロットリングと結果のキャッシュを実装できます。

ワークフローで調整された統合のセキュリティ

直接量子統合とは異なり、このパターンでは、従来のサービス レベルが量子作業の前に配置されます。 API Management はその層のフロント ドアであるため、セキュリティ構成では、エントリ ポイントと量子ワークスペースへのパスの保護が重視されます。

• クライアントは API に対して認証する必要があります。 認証ポリシーを使用して、この 認証を実装します。

• Azure関数の認証は、関数に関連付けられた 管理 ID を使用して実装できます。 これらの ID を使用して、Azure Quantum ワークスペースへの発信呼び出しを認証します。

• API Management では、要求調整を適用して量子バックエンドを保護し、量子リソースの使用を制限できます。 詳細については、「 API Management 要求の調整」を参照してください。

• 要求パターンによっては、API Management キャッシュ ポリシーを使用して、量子コンピューティングの結果のキャッシュを実装できる場合があります。

コストの最適化

コストの最適化では、不要な経費を削減し、運用効率を向上させる方法に重点を置いています。 詳細については、「コスト最適化の設計レビュー チェックリスト」を参照してください。

このソリューションの全体的なコストは、量子ジョブを実行するために選択した量子コンピューティング ターゲットによって異なります。 古典的なコンポーネントは簡単に推定できます。 ワークフローで調整されたパターンの代表的なデプロイについては、API Management、Azure Functions、Storage などの従来のコンポーネントを対象としたコスト見積もりの例を参照してください。 直接統合パターンは軽量ですが、従来のコストには、ストレージと、クライアント アプリケーションで使用されるホスティング、ネットワーク、監視が含まれます。

Microsoft Marketplace オファリングを介して、Azure Quantumの量子コンピューティング プロバイダーを使用できます。 価格は、リソースの種類 (シミュレーターまたはハードウェア)、SKU、使用状況によって異なります。 詳細については、Azure Quantum上の Quantum コンピューティング プロバイダーから、シナリオのプロバイダーのリファレンス ページにアクセスしてください。

貢献者

Microsoft では、この記事を保持しています。 次の共同作成者がこの記事を書きました。

主著者

• ザンダー・チョクロン |プリンシパル ソフトウェア エンジニア、Microsoft Quantum

公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。

次の手順

• Microsoft量子コンピューティング エコシステムの概要については、Microsoft Quantum の Web サイトを参照し、Quantum コンピューティング基盤のラーニング パスを完了します。
• Azure Quantum サービスの詳細については、「Azure Quantumとは」を参照してください。
• ジョブ管理のAzure Quantumに関する一般的な情報については、「work with Azure Quantum jobs」を参照してください。
• ジョブでの従来の命令と量子命令の組み合わせについては、「 ハイブリッド量子コンピューティングの概要」を参照してください。

関連リソース

• オペレーショナル エクセレンス設計の原則
• 非同期リクエスト・リプライパターン