Microsoft QDK（Quantum Development Kit）とは？対応言語やCopilot連携、使い方を解説

Microsoft QDK（Quantum Development Kit）は、量子プログラムを書き・シミュレートし・実機に投入するまでを1つの環境で完結させる、Microsoft公式の無料オープンソース（MITライセンス）SDKです。

2023年9月のプレビュー公開・2024年1月のv1.0リリースでClassic QDKからModern QDKへ骨格が刷新され、2026年に入ってからは1月にドメインライブラリと開発ツールが強化、4月のQDK v1.27.0でGitHub Copilotに /qdk-programming の専用スキルが追加されました。

本記事では、QDKの構成要素・対応言語（Q#・OpenQASMをVS Code拡張で、Qiskit・CirqをqdkパッケージのextrasからPython経由で扱える形）・Copilot連携・インストール手順・実践フロー・ドメインライブラリ・料金・導入で判断が分かれる論点までを、2026年8月時点の公式情報をもとに体系的に整理します。

Microsoft QDK（Quantum Development Kit）とは？量子プログラム開発を1つの環境で完結させる公式SDK

Microsoft QDK（Quantum Development Kit）とは、量子プログラムを書き・シミュレートし・デバッグし、実際の量子コンピュータに投入するまでを1つの環境で完結させる、Microsoft公式の無料オープンソース量子SDKです。

正式名称は「Microsoft Quantum Development Kit」で、Visual Studio Code拡張機能とPythonパッケージを中心に構成され、Azure Quantumにそのまま接続してIonQ・Quantinuum・Rigettiなど各プロバイダーの実機・シミュレータへジョブを投入できます。

QDKが従来の量子SDKと異なるのは、特定の量子言語や特定の量子ハードウェアに閉じず、Q#とOpenQASMはVS Code拡張で直接、Qiskit・CirqはqdkパッケージのextrasからPython経由で相互運用できる中立レイヤーとして設計されている点です。

Microsoftは公式ドキュメントでQDKを「量子プログラムを書き、シミュレートし、デバッグし、実行するために必要なすべてを1つのツールキットにまとめたもの」と説明しており、開発フローの入り口から実機投入までを単一SDKでカバーする方針が明確に示されています。QDKが位置づけられるMicrosoft Quantum全体のスタックについては別記事で扱います。

Classic QDKからModern QDKへ——2023年プレビューから2026年の機能拡張まで

QDKは長らく「Classic QDK」として.NET・PowerShell・Visual Studio拡張を前提に提供されていましたが、Modern QDKへの刷新は2023年9月にVS Code拡張のプレビュー公開で始まり、2024年1月にModern QDK v1.0が発表されました。2026年に入ってからは、1月22日にドメインライブラリと開発ツールを大幅に強化するアップデートが公開され、続く4月のQDK v1.27.0でGitHub Copilotに /qdk-programming の専用スキルが追加されています。

Modern QDKへの流れで押さえておくべき変化は以下の3点に集約されます。

• 配布方式のオープンソース化（2023〜2024年）
  Modern QDKはGitHub（microsoft/qdk）上でソースコードが公開され、拡張機能もqdk Pythonパッケージも自由に改変・再配布できる形になりました。Classic時代の.NET依存が外れ、macOS・Linux・Windowsで同じインストール手順が使えます。
  
  

• マルチ言語・Copilot連携の強化（2026年1月）
  VS Code拡張ではQ#・OpenQASMを直接編集でき、qdkパッケージのextrasを介してQiskit・CirqのPython資産を相互運用できる形が公式に強化されました。開発ツール群にもドメインライブラリ（Chemistry・Error Correction）が追加されています。
  
  

• GitHub Copilotの専用スキル追加（2026年4月／QDK v1.27.0）
  Copilotに /qdk-programming というQDK専用スキルが加わり、Q#イディオムや qsharp Python APIについて、QDK固有知識を踏まえた文脈認識アシスタンスが得られるようになりました。

Classic QDK時代の既存プロジェクトやサンプルは、Modern QDKへ移行する際に .csproj からのプロジェクト構造変更・NuGet依存の入れ替え・C#連携の書き直しなどの移植作業が必要です。新規プロジェクトはModern QDK前提で始めるのが公式推奨路線になっています。

QDKの構成要素——4コンポーネントと3つの柱

QDKは単一の実行ファイルではなく、用途ごとに独立した4つのコンポーネントで構成されています。全部を一度に入れる必要はなく、自分のワークロードに合わせて必要な部分だけを取り込む形が公式推奨です。

Microsoftは公式ドキュメントでQDKの構造を「Core foundation・Productivity and tools・Domain libraries」の3つの柱として整理しており、コンポーネントはこの柱にそれぞれ紐づいています。

Microsoftの公式overviewページでは、この構造を以下の1枚で示しています。

QDKの3つの柱（Core Foundation・Productivity & Tools・Domain Libraries）と主要要素の全体像（出典：Microsoft Learn）

Core Foundation層にはLanguages & Frameworks・Resource Estimator・Libraries・Compilersが配置され、Productivity & Tools層にはVS Code and Copilot・Debugging & Testing・Visualization・Simulationが並びます。Domain Libraries層にはQDK for ChemistryとQDK for Error Correctionが挙がり、末尾の「More to come」で今後の拡張余地も示唆されています。

QDKを構成する4コンポーネント

以下の表で、QDKを構成する4コンポーネントとそれぞれの用途・配布先を整理しました。

この4つは独立して使うこともできますし、組み合わせて使うこともできます。たとえばVS CodeでQ#を書きつつPython側でリソース見積りを回す、あるいはqdk-chemistryで生成した量子化学ハミルトニアンをQ#の量子アルゴリズムから呼び出す、といった構成が想定されています。

QDKの機能を支える3つの柱

これらのコンポーネントを機能面で整理すると、以下の3層に分解できます。

• Core foundation
  Q#コンパイラ・QIR（Quantum Intermediate Representation）生成器・target profile管理といった、量子プログラムを実機に投入する基盤層。QDK拡張機能とqdk Pythonパッケージの両方に組み込まれています。
  
  

• Productivity and tools
  シミュレータ・回路エディタ・リソースエスティメータ・デバッガ・IntelliSense・Copilotスキルなど、開発者体験を支える層。VS Code拡張の目に見える機能はほとんどこの層に含まれます。
  
  

• Domain libraries
  量子化学向けのqdk-chemistry、誤り訂正向けのQDK-ECなど、特定領域に踏み込んだ専用ライブラリ層。2026年1月のアップデートで強化された部分です。

この3層構造は、QDKが「Q#言語だけを提供するSDK」ではなく「量子開発ワークフロー全体を束ねるプラットフォーム」として設計されていることを示しています。導入時は「まずCore foundation＋Productivity and toolsから入り、必要になった時点でDomain librariesを追加する」順序も選択肢となります。

QDKが対応する量子プログラミング言語

QDKが2026年に大きく評価を変えた最大の理由は、Q#に閉じずマルチ言語で量子プログラムを扱える中立SDKになった点です。ここでは、QDKが対応する主要言語と、それぞれの位置づけを整理します。

Modern QDKが同一環境から扱える言語・フレームワーク・中間表現は、Q#・OpenQASM・Python・QIR・Qiskit・Cirq・PennyLaneです。厳密にはQIRは中間表現、Qiskit・Cirq・PennyLaneは他社量子SDK・量子機械学習フレームワークで、Q#・OpenQASMはVS Code拡張で直接編集でき、Qiskit・CirqはqdkパッケージのextrasからPython経由で相互運用、PennyLaneはOpenQASM／QIRへの変換を介した投入経路という構造になっています。それぞれ役割が異なるため、どれか1つに絞るのではなく用途で使い分ける前提で設計されています。

対応言語の全体像と、周辺のコンパイラ・シミュレータ・ドメインライブラリまで含めたエコシステムを、Microsoftの公式ブログでは1枚の拡張ビューで示しています。

Modern QDKが対応する量子言語・コンパイラ・シミュレータ・ドメインライブラリの全体マップ（出典：Microsoft Azure Quantum Blog）

Languages列にQ#・Qiskit・Cirq・OpenQASMが並び、Compilers列にはQ# to QIR・OpenQASM to QIR・Python to QIR・Circuit compilerが揃います。Simulators & visualizers列にはSparse・Clifford・Full state CPU・Full state GPU・Circuit visualizer・Neutral atom visualizerが並び、複数のシミュレータで異なる粒度の検証ができる構成です。VS Code experience側にはGitHub Copilot・Intellisense・Quantum unit tests・Quantum debugging・Sample library・Resource estimatorが配置されます。ただしVS Code拡張が直接編集対象として扱うのはQ#とOpenQASMで、Qiskit・Cirqは以降のH3で触れるようにqdkパッケージのextras経由でPythonから呼び出す前提です。

Q#——Microsoftが設計した量子ネイティブ言語

Q#はMicrosoftが2017年に発表した高レベル量子プログラミング言語で、量子ビット・量子ゲート・測定といった概念を型システムに組み込んでいます。

Q#の強みは、Azure Quantumのリソースエスティメータや局所シミュレータと密結合で動く点です。同じソースを書き換えずに、開発中はローカルシミュレータ・提出時はIonQ・Quantinuum・Rigetti等の実機、と切り替えられます。QDKユーザーが最も自然に選ぶ第一言語になります。

Python + qdkパッケージ——相互運用の中心

qdk Pythonパッケージは、Q#・OpenQASMをPython関数として呼び出す相互運用のハブになります。Jupyter Notebookで量子アルゴリズムの結果を可視化しながら、classical処理と量子処理を織り交ぜて記述できます。

たとえば量子回路をQ#で定義し、その結果をPandas DataFrameで統計処理して、matplotlibで可視化する、といった実験フローが1つのノートブックで完結します。研究者・データサイエンティスト層がQDKに入る最短の入り口です。

OpenQASM——ハードウェア中立の記述言語

OpenQASM（Open Quantum Assembly Language）は、IBMが主導して策定された量子ゲートレベルの記述言語で、業界ではハードウェア中立の中間表現として広く使われています。

Modern QDKは.qasmファイルをVS Code上で自動認識し、Run/Histogram/Estimate/Debug/Circuitの各コードレンズを表示します。ローカルシミュレータで実行し、そのままQIRに変換してAzure Quantum実機へ投入する、という流れが1画面で完結する仕様です（詳細は公式ドキュメント参照）。

QIR——マルチベンダー時代の量子中間表現

QIR（Quantum Intermediate Representation）は、LLVM IRの量子版に相当する低レベル中間表現で、QIR Allianceがオープン仕様として策定しています。Q#やOpenQASMで書いたコードは、最終的にQIRに変換されて実機やシミュレータに渡されます。

QDKは「compile」関数でOpenQASMやQ#をQIRに変換する機能を提供しており、パラメータ化された回路をQIRに落として実機投入することも可能です。「ソースはQ#で書くが、実行対象を切り替えたい」場面での中間層として機能します。

Qiskit・Cirqとの互換——既存資産を持ち込める

QDKは「qdk[qiskit]」extraをインストールすると、Qiskit 1系・2系の量子回路をそのまま扱えるようになります。CirqについてもPython経由で読み込み・実行が可能です。

これにより、IBM Quantum向けにQiskitで書き溜めた資産や、Google Quantum AI向けにCirqで書いた回路を、QDKのシミュレータ・リソースエスティメータ・Azure Quantum投入機構からそのまま扱える形です。VS Code拡張が直接編集対象にするのはあくまでQ#とOpenQASMで、Qiskit・CirqはPython側からそれぞれqdk[qiskit]・qdk[cirq] extras経由で読み込んで使う構造ですが、SDKを乗り換えるコストが下がったのはModern QDKの大きな成果の1つです。

QDKのGitHub Copilot連携でできること

Modern QDKの目玉機能の1つが、GitHub Copilotとの公式統合です。従来のCopilotはQ#やOpenQASMに対して「一般的な補完」しか行えず、存在しない関数名を生成する（ハルシネーション）ケースがありました。Modern QDKはQDK固有知識を踏まえたガイダンスをCopilotに与えることで、こうしたハルシネーションを抑制する形で改善しています。

Microsoftの公式ブログは、この統合を「QDK固有の知識に基づく文脈認識アシスタンス」と位置づけています。

/qdk-programming スキルの導入

Modern QDKでは、Copilot Chat内で 「/qdk-programming」 コマンドを叩くとQDK専用のプログラミングスキルが呼び出され、以下の3つのプログラミングインターフェイスをカバーしたガイダンスが返るようになりました。

• Q# の量子アルゴリズム記述
• OpenQASM のゲートレベル記述
• qsharp / qdk Python APIの操作

これはQDK拡張機能をVS Codeに入れた瞬間から自動的に有効になり、追加設定は不要です。GitHub CopilotのライセンスとQDK拡張が両方入っている環境なら、そのまま呼び出せます。

Copilotが加速する典型ワークフロー

Copilot連携でQDK開発者が受け取るメリットは、以下のように整理できます。

• コード生成
  Q#でBell状態を作る回路、OpenQASMでQFT（量子フーリエ変換）を書く、qdk Python APIでノイズ付き量子シミュレーションを回す、といった典型ワークフローをコメントベースで呼び出せます。
  
  

• ユニットテストの下書き
  Q#の「@Test()」アトリビュートやqdk Pythonの「run」関数を使ったテストコードを、対象operationから自動生成できます。
  
  

• Azure Quantumジョブ投入コードの雛形
  「from qdk.azure import Workspace」を起点にしたAzure接続コード・ジョブ投入コード・結果取得コードの雛形を、自然言語プロンプトから引き出せます。
  
  

• ハルシネーション抑制
  Q#の標準ライブラリ関数名・qdk Python APIのシグネチャ・OpenQASMの標準gate名について、実在しない関数名の提案がQDK固有知識で抑制されるように改善されています。

Copilot連携は「単に書くのが早くなる」以上に、量子開発の学習コストを下げる効果があります。Q#やOpenQASMを触ったことがないエンジニアでも、Copilotに「Bell状態を作って測定する回路をQ#で書いて」と入力すれば、動作確認しながら学習を始められるサンプル候補が返ります。関連するGitHub Copilotの機能全体像もあわせて押さえておくと、AI補完全体の設計が理解しやすくなります。

QDKのインストールとセットアップ手順

QDKを触り始める最短経路は、VS Code拡張のインストール1つです。Q#のローカル開発だけならAzureアカウントすら不要で、10分程度で動くところまで到達します。

Microsoftのインストール公式ドキュメントは、VS Code拡張・qdk Pythonパッケージ・Azure CLIの3層でセットアップ手順を提示しています。順に見ていきます。

前提条件

最小構成の前提は次のとおりです。

• VS Code
  最新版のVisual Studio Code（Desktop版推奨。Web版vscode.dev/quantumでも一部機能は利用可能）。
  
  

• Python 3.10以上
  Python連携を使う場合、3.10以上（3.11推奨）が必要。
  
  

• Azureアカウント（Azure Quantumへジョブを投入する場合）
  ローカルシミュレータでの実行だけなら不要。Azure Quantumの実機・プロバイダー提供シミュレータ／エミュレータへ投入する場合はAzure Quantumワークスペースが必要になります。

VS Code拡張のインストール

VS Codeの拡張機能ビュー（Ctrl+Shift+X／Cmd+Shift+X）で「Microsoft Quantum Development Kit (QDK)」を検索し、インストールします。マーケットプレイスの拡張機能IDは「quantum.qsharp-lang-vscode」です。

拡張機能が入った時点で、.qs（Q#）と.qasm（OpenQASM）ファイルが自動認識され、シンタックスハイライト・コードレンズ・IntelliSense・デバッガ・ローカルシミュレータが全て有効になります。ここまでで、Q#とOpenQASMを書いて動かすところは完結します。

qdk Pythonパッケージのインストール

Python連携を追加する場合は、以下のコマンドで用途別のextrasを指定してインストールします。

# Azure Quantum接続込みの基本セット
python -m pip install "qdk[azure]"

# Qiskit互換を追加
python -m pip install "qdk[qiskit]"

# Jupyter Notebookで可視化するための一式
python -m pip install "qdk[jupyter]" ipykernel ipympl jupyterlab

extrasは併用可能で、たとえば「qdk[azure,jupyter,qiskit]」のようにまとめてインストールすることもできます。プロジェクトの用途に応じて、必要な部分だけを取り込む設計です。

Azure CLIの追加（オプション）

VS Codeターミナルから直接Azure Quantumにジョブを投入したい場合は、Azure CLIも入れておきます。

az extension add --upgrade -n quantum

これでVS CodeのUIとCLIの両方からAzure Quantumワークスペースを操作できるようになります。CI/CDパイプラインに量子ジョブ投入を組み込む場合、CLI経由が扱いやすい選択肢です。

QDKで量子プログラムを書く実践フロー

インストールが完了したら、実際にコードを書いて動かしてみるフェーズに入ります。ここでは、Q#とOpenQASMで最も基本的な「Bell状態」を作る例を通じて、ローカルシミュレータ→リソース見積り→Azure Quantum投入までの実践フローを追います。

Bell状態は、2つの量子ビットを最大限にエンタングルさせる基本回路で、量子プログラミングの「Hello World」に相当します。QDKはこのレベルの回路であれば、ローカルシミュレータで即座に結果を確認できます。

Modern QDKの統合開発体験を象徴するのが、以下のVS Code画面です。

VS Code上でqdk-chemistryを使ったPythonコードと、分子軌道・量子回路の可視化ペインが一画面に並ぶModern QDKの統合開発体験（出典：Microsoft Azure Quantum Blog）

左のエディタペインではqdk_chemistryをimportしてハミルトニアン構築・CASCI計算・状態準備回路の生成を行うPythonコードが動き、下部には分子軌道の3D可視化と、多量子ビットの量子回路が同時に表示されています。以降のBell状態例ではQ#とOpenQASMを扱いますが、Python側からqdk-chemistryやqdk.openqasmを呼び出して、同じVS Code内でclassical処理と量子処理を織り交ぜる形も選べます。

Q#でBell状態を書く

Q#では、以下のような形でBell状態を作って測定できます。

namespace BellSample {
    open Microsoft.Quantum.Intrinsic;
    open Microsoft.Quantum.Measurement;

    @EntryPoint()
    operation BellPair() : (Result, Result) {
        use qs = Qubit[2];
        H(qs[0]);
        CNOT(qs[0], qs[1]);
        let r0 = MResetZ(qs[0]);
        let r1 = MResetZ(qs[1]);
        return (r0, r1);
    }
}

VS Codeでこのファイル（.qs）を開くと、@EntryPoint() の上にRun・Debug・Histogram・Estimate・Circuitのコードレンズが表示され、クリックするだけで対応する動作が走ります。Histogramを選ぶと指定したショット数の測定結果分布が可視化され、「00」と「11」がほぼ50%ずつ現れるBell状態の性質がその場で確認できます。

OpenQASMで同じ回路を書く

同じBell状態をOpenQASMで書くと、次のようになります。

OPENQASM 3.0;
include "stdgates.inc";
qubit[2] q;
bit[2] c;
h q[0];
cx q[0], q[1];
c = measure q;

.qasmファイルとして保存すれば、Q#とまったく同じコードレンズが使えます。既にQiskitやIBM Quantum向けにOpenQASM資産がある場合、そのままQDKに持ち込んで実行できるということです。

Python + qdkパッケージから呼び出す

Jupyter NotebookやPythonスクリプトから同じ回路を扱う場合は、以下のようにqdk Pythonパッケージ経由で実行します。

from qdk.openqasm import run

qasm_code = """
    include "stdgates.inc";
    qubit[2] q;
    bit[2] c;
    h q[0];
    cx q[0], q[1];
    c = measure q;
"""

results = run(qasm_code, shots=1000)
print(results)

この「run」関数はローカルシミュレータで実行しますが、「BitFlipNoise」のようなノイズモデルを追加すれば、実機に近い揺らぎを含めたシミュレーションも可能です。研究フェーズで「実機に投げる前にどこまでノイズ耐性があるか」を先に確認できる仕組みです。

Azure Quantumターゲットへの投入

ローカルシミュレータでの検証が済んだら、Azure Quantumのワークスペースに接続してターゲットに投入します。VS Code側であればサイドバーの「Microsoft Quantum」アイコンからワークスペースを選び、プロバイダー（IonQ・Quantinuum・Rigetti等）とターゲットを指定するだけです。

Python側からは、以下のような流れになります。

from qdk.azure import Workspace
from qdk.openqasm import compile

qir_compilation = compile(qasm_code)

workspace = Workspace(resource_id="/subscriptions/...")
target = workspace.get_targets("ionq.simulator")  # 実機なら "ionq.qpu.aria-1" など
job = target.submit(qir_compilation, shots=1000)
results = job.get_results()

ここまでで、開発→シミュレーション→Azure Quantumターゲット投入の1サイクルが完結します。Azure Quantum側の詳しいプロバイダー構成や料金体系は、後段の料金セクションで概観したうえで、Azure Quantumの専用記事に整理しています。

QDKのドメインライブラリ——ChemistryとError Correction

Modern QDKのもう1つの目玉が、特定領域に踏み込んだドメインライブラリの拡充です。従来のQDKは汎用的な量子開発ツールに寄っていましたが、2026年1月のアップデートで、量子化学と誤り訂正の2領域に対して専用ライブラリを整備しました。

Microsoftの公式ブログは、QDK for Chemistryを近未来の量子ハードウェア向けのEnd-to-Endソリューションとして、QDK for Error Correctionを符号化量子プログラムの特性評価・検証・デバッグを支援するツール群として説明しています。

QDK for Chemistry——分子シミュレーション向け

qdk-chemistryは、量子化学計算に特化したPythonライブラリです。Microsoft公式は「化学者による、化学者のための設計」と表現しており、古典計算による化学手法と、近未来の量子ハードウェア向けアルゴリズムを組み合わせたEnd-to-Endソリューションを提供します。

QDK for Chemistryが提供するワークフロー全体を、Microsoftの公式ブログでは1枚のフロー図にまとめています。

QDK for Chemistryが提供する分子→アクティブ空間選択→量子回路→測定のエンドツーエンドフロー（出典：Microsoft Azure Quantum Blog）

入力分子（Input molecule）から相関軌道（Correlated Orbitals）でアクティブ空間を選択し、量子回路（H・R・S・CNOTゲートに加えてQPE = Quantum Phase Estimation）を組み立て、最後にシミュレーション測定を行う4段構成です。下部には「Designed by chemists／Built to empower community／Optimized for today's quantum hardware／Focused on real-world applications」の4つの設計原則が並び、研究者コミュニティに開かれた実用重視の設計思想を示しています。

想定される具体ユースケースは以下です。

• 分子ハミルトニアンの構築と量子回路への変換
• QPE（量子位相推定）とサンプリングによるエネルギー推定
• 状態準備回路の生成と検証
• 触媒・電池材料の候補分子スクリーニング

これらは製薬・化学メーカー・材料研究機関の量子研究チームが取り組み始めている領域で、量子コンピュータの初期実用ドメインとして最有力候補と目されています。QDKに専用ライブラリが載ったことで、分子入力からハミルトニアン構築・量子回路生成・エネルギー推定までのワークフローを、Q#とqdk-chemistryだけで一気通貫に組めるようになりました。

QDK-EC——フォールトトレラント研究向け

QDK-EC（QDK for Error Correction）は、量子誤り訂正コードの実装・検証を支援するソフトウェアスイートです。Microsoft社内の量子誤り訂正研究で使われてきたツール群を、GitHub（microsoft/qdk-ec）上でオープンソース公開したものです。

公開資料から確認できる主な機能は次のとおりです。

• Pauli代数・Cliffordゲートを使ったスタビライザーシミュレーション
• 量子回路の合成と検証
• シンドローム抽出とデコーディングの検証
• 論理エラー率と物理量子ビット数の関係の分析

誤り訂正は、量子コンピュータが実用フェーズに入る最大のボトルネックです。IBM・Google・IonQ・Quantinuum・Microsoft自身のMajorana 2など、複数の主要プレイヤーが論理量子ビットの実装と誤り訂正を今後数年の重要なマイルストーンに位置づけています。QDK-ECはその研究を、社内ツールに閉じずコミュニティで加速させる意図で公開されました。ハードウェア各社の比較記事は関連ページで別途整理しています。

QDKの料金とAzure Quantum接続時のコスト

QDKに関して最も誤解が多いのが料金の話です。結論から言うと、**QDK本体は完全無料で、QDK起因で費用が発生するのはAzure Quantumを利用する場面（実機ジョブに加え、一部のシミュレータ／エミュレータ、関連するAzureインフラを含む）**です。

Microsoft公式ドキュメントは、QDKを明確に「free open-source software development kit」と定義しており、拡張機能・qdk Pythonパッケージ・qdk-chemistry・QDK-ECはいずれもMITライセンスで配布されています。ローカルシミュレータの実行やCopilotスキル /qdk-programming の呼び出しについて、QDK側で追加料金は発生しません（Copilot側の契約料金・AI Credits消費・超過課金は別途Copilotのプランに従います）。

費用が発生するポイント

QDK関連で費用が発生するのは、次のポイントに限定されます。

• Azure Quantum実機ジョブのプロバイダー従量課金
  IonQ・Quantinuum・Rigettiなどの量子プロバイダーに実機ジョブを投げると、プロバイダーごとの単価に応じた従量課金が発生します。単価はプロバイダー・ターゲット・qubit数・ショット数に依存し、料金体系はAzure Quantumワークスペース側で管理されます。プロバイダー別の課金単位はAzure Quantumの専用記事にまとめています。
  
  

• 一部シミュレータ／エミュレータの利用料
  ハードウェア提供元によっては、ハードウェアと同じ挙動をエミュレートするシミュレータやエミュレータターゲットが有料で提供されます。ローカルで走るQDKシミュレータとは別枠のため、投入先ターゲットを選ぶ段階で料金表を確認する必要があります。
  
  

• 関連するAzureインフラ
  Azure Quantumワークスペースが依存するストレージアカウント（ジョブ入出力の保存）や、ジョブ管理に伴うAzure標準リソースの利用料が発生します。金額は少額でも、長期運用するとワークスペース維持コストとして積み上がります。
  
  

• GitHub Copilotのライセンス
  Copilot連携を使うには、IDEでCopilot Chat skillsが利用できるGitHub Copilotのプラン（現行のFree枠を除くPro／Pro+／Max／Business／Enterpriseなど）と、そのプランに紐づくAI Credits消費・超過課金の枠が別途必要になります。これはQDKの費用ではなく、Copilot側の契約に含まれます。

QDKを常時運用するのではなく高価値領域に絞る

Azure Quantum実機ジョブは、プロバイダー・ターゲット・実行時間・qubit数に応じて課金されるため、汎用クラウドの計算リソースと比較すると単価が高くなる傾向にあります。常時稼働させるようなワークロードには向かず、実機投入は狙いを絞って走らせる運用が現実的です。

現実的な運用は、以下のような**「人手やクラシカル計算では到底届かない一方、当たれば大きい」領域に絞る**方向です。

• 新素材・触媒候補分子のスクリーニング
• 特定領域の組合せ最適化問題の実験検証
• 量子誤り訂正コードの実機ベンチマーク
• 教育・研修目的の実機体験

QDK本体は無料なので、社内の量子開発人材の育成にはローカルシミュレータだけで十分機能します。実機投入は「明確な仮説と検証コストの見合いが取れる」タイミングに絞り、そこからAzure Quantumのワークスペース設計に踏み込む段取りが定石になります。

QDK導入で判断が分かれる3つの論点

QDKは無料オープンソースで敷居は低いものの、組織として量子開発に踏み込むかどうかは別の判断になります。ここでは、実際に導入検討を進める際に決まって出てくる3つの論点を整理します。

これらはQDK本体の機能というより「量子開発をどう社内に位置づけるか」の話で、経営層・R&D責任者・情報システム部門で認識を揃えておく必要があります。

論点1：既存Qiskitユーザーの移行判断

Modern QDKがQiskit互換を備えたことで、Qiskit派の開発者にとってQDKが選択肢に入るようになりました。ただし完全な代替ではありません。

Qiskit独自のエコシステム（Qiskit Runtime・Qiskit Aer・Qiskit Nature等）はQDKから直接呼び出せないため、既にIBM Quantumで研究資産を積み上げたチームがQDKに全面移行するメリットは限定的です。Q#の型システムやAzure Quantumのリソースエスティメータに強い価値を見出せるか、あるいはOpenQASMとの相互運用がクリティカルかで判断が分かれます。「Qiskitで書いた回路をVS Codeで統一的にデバッグしたい」程度の動機なら、Modern QDKの併用が現実的です。

論点2：QIR target profileの選択

QDKでQ#やOpenQASMからQIRを生成する際、target profile（Base・Adaptive RI・Adaptive RIF・Adaptive・Unrestricted）を選ぶ必要があります。QDKが対応先に応じてプロファイルを自動選択するケースもありますが、実機投入時にプロバイダーが要求するプロファイル要件を満たしていないと、ローカルシミュレータでは動くのに実機で動かない問題が発生します。

Baseは古典制御を含まない静的量子回路のみ対応する最小プロファイル、Adaptive RI／Adaptive RIFは測定結果に応じた分岐や中間測定など動的機能を段階的に拡張したプロファイル、Adaptiveはより広範な動的機能をカバーし、Unrestrictedは制約なしで主にシミュレータ向けに使われます。プロバイダーごとに対応プロファイルが異なるため、実機投入前に投入先ターゲットのtarget profile対応状況を公式ドキュメントで確認する運用が定石です。

論点3：Azure Quantumワークスペースの準備

QDK本体は無料ですが、実機投入に必要なAzure Quantumワークスペースの用意は、通常のAzureサブスクリプション以上に手順が増えます。プロバイダーごとの利用契約・料金体系の把握・IPアドレス制限などのセキュリティ設計を、事前にAzure管理者と揃えておく必要があります。

特に金融・製薬・材料メーカーなど機密情報を扱う組織では、「量子ジョブに投入する分子構造やアルゴリズムが機密情報に該当するか」の判断が入り、法務・情報セキュリティ部門との協議が発生します。技術検証をPoC範囲で回している間はいいですが、業務プロセスに近づくほど組織側の準備コストが増えます。実装の前に自社のQuantum Ready段階（量子時代の対応準備レベル）を評価しておくと、順序立てて進めやすくなります。ここまでの前提を踏まえたうえで、続くセクションで社内展開の実務論を整理します。

QDK導入から業務プロセスへの接続まで一気通貫で伴走するなら

QDKはR&D領域のSDKとして完成度が高い一方、量子開発の成果を業務プロセスに接続するには量子チームと業務側を橋渡しするAIエージェント基盤が並行して必要になります。QDKで書いたQ#モジュールやqdk Pythonの計算結果を、業務システム側でどう受け取り、誰が権限を持ち、監査ログをどう残すか——このレイヤーが整っていないと、量子PoCの成果が組織横断で活きません。

AI総合研究所のAI Agent Hubは、自社Azureテナント内で動くエンタープライズAIエージェント基盤として、この橋渡し層を担う設計になっています。R&D側のQDK検証と業務側のAgent実装を、1つのダッシュボードで統合管理できます。

• 量子R&D検証と業務Agentを同一基盤で運用
  qdk Pythonの計算結果を業務Agent（Teams上から呼び出せる特化Agent）にそのまま渡し、業務プロセスへの接続を1画面で設計。R&D成果の業務展開を早められます。
  
  

• Azure Quantumワークスペースとの整合設計
  Azure Quantum・Azure OpenAI・Azure Foundryを同一テナントに集約する構成をサポート。量子ジョブと業務Agent呼び出しのアクセス統制を統一設計できます。
  
  

• Agent単位でセキュリティ統制
  QDKで扱う分子構造やアルゴリズムを含むワークフローは、Agent単位で権限を絞り、誰がどのAgentで何を照会したかを不変ログで残せます。監査対応をそのまま提出できる形で保管されます。
  
  

• データは100%自社Azureテナント内
  量子計算入力・計算結果・業務データはAIの学習対象から完全除外。Azure Managed Applicationsとして自社テナント内で動作が完了する設計です。

AI総合研究所の専任チームが、QDK導入評価から業務Agent基盤の統合設計・PoC実装まで一貫して支援します。量子×業務Agentの導入検討をされている方は、AI Agent Hubのサービスページで実装例をご確認ください。

量子×業務Agentの導入検討を伴走支援

量子SDK評価から社内AIエージェント基盤まで一気通貫で整える

QDKのようなR&D領域SDKを社内の業務プロセスに接続するには、Agent実行層・権限管理・監査ログを担うエンタープライズAIエージェント基盤が並行して必要です。AI Agent Hubは、Teams上から呼び出せる業務特化Agent群を1つのダッシュボードで統合管理し、量子開発チームの技術評価と業務側の実装を1つの基盤で運用できるように設計されています。

▶ ▶ AI Agent Hubの詳細を見る

まとめ

本記事では、Microsoft QDK（Quantum Development Kit）について、構成要素・対応言語・Copilot連携・インストール手順・実践フロー・ドメインライブラリ・料金・導入判断論点までを、2026年8月時点の公式情報で解説しました。

QDKを検討する際に押さえておくべきポイントは、次の3つに集約されます。

• Modern QDKは2023年プレビュー・2024年v1.0を経て、2026年1月にドメインライブラリと開発ツールが強化された量子SDKで、Q#・OpenQASMはVS Code拡張で直接、Qiskit・CirqはqdkパッケージのextrasからPython経由で相互運用しAzure Quantum実機投入まで完結する
• 2026年4月のQDK v1.27.0でGitHub Copilotに /qdk-programming スキルが追加され、Q#・OpenQASM・qsharp Python APIのハルシネーションを抑制したガイダンスが得られるようになった
• QDK本体は無料オープンソース（MITライセンス）で、QDK起因の費用が発生するのはAzure Quantum利用時のプロバイダー従量課金・一部シミュレータ／エミュレータ・関連インフラ——Copilot利用時はCopilot側の契約・AI Credits消費が別途発生し、常時運用ではなく高価値領域に絞る運用が現実的
  
  

量子コンピュータの実用化はまだ先ですが、開発環境の敷居はModern QDKで大きく下がりました。まずはVS Code拡張だけを入れてローカルシミュレータでQ#やOpenQASMを触るところから始め、社内での量子人材育成と、Azure Quantumのワークスペース設計・自社のQuantum Ready評価を並行で進めるのが、実用フェーズを待たずに動き出す最も現実的な入り方になります。