Skip to content

RFC 016: 量子ネイティブサポートとマルチバックエンド統合 ​

拒否理由: 前提依存が不足。Primitive::Extension 機構が未実装、言語コンパイラが完成しておらず、実際のユーザーニーズもない。量子サポートは言語成熟後に Extension 機構のコンシューマとして再評価すべきである。

依存関係:

概要 ​

本文書は YaoXiang 言語の量子ネイティブサポートおよびマルチバックエンド統合方案を定義する。核心思想:YaoXiang の既存設計(デフォルト Move、所有権回帰、不透明型、DAG スケジューラ、ジェネリック定数パラメータ)は量子プログラミング言語の完全な基礎を自然に構成しており、新しい量子専用構文を導入する必要は一切ない。少量の組み込み型(Qubit、Complex、Topology)と組み込み関数(量子ゲート、測定、トポロジ制約)を追加し、既存の言語機構を利用することで、量子ネイティブセマンティクス、量子利用率を最大化する自動並列化、古典プログラミングとのハイブリッド、およびマルチバックエンドサポートを実現する。

動機 ​

なぜ量子ネイティブサポートが必要なのか? ​

現在の量子プログラミングエコシステムには深刻な断絶がある:

  • 低級言語(QCIS、OpenQASM):物理量子ゲートを直接操作するが、型システムや抽象化機構が欠如しており、複雑なアルゴリズムの記述が困難。
  • 高級フレームワーク(Qiskit、Cirq、Q#):古典言語(Python、C#)の拡張として構築され、量子セマンティクスはライブラリで実装されているため:
    • 量子状態の非クローンング規則をユーザが手動で遵守する必要がある(または線形型システムで事後補完)。
    • 量子ゲート操作と古典コードの構文が分断されており、学習コストが高い。
  • ハイブリッド計算:量子部分と古典部分を明示的に分離する必要があり、統一データフローモデルが欠如。

現状の問題点 ​

YaoXiang の既存設計はまさにこれらの問題を解決するための完全な基礎を提供している:

量子計算の要件YaoXiang の既存設計説明
量子状態の非クローンングデフォルト Move セマンティクス代入は即ち所有権の移動、暗黙的コピーなし、自然に no-cloning 定理に適合
量子ゲートとしてのユニタリ変換所有権回帰q = H(q) で元の qubit を消費し、新しい qubit を返す、ゲートセマンティクスに正確に対応
エンタングル状態不透明型BellPair は全体操作のみ可能、コンパイラがライフサイクルを追跡し、誤分解を防止
物理トポロジ制約ジェネリック定数パラメータQubit(Topology, N) でコンパイル時に隣接性を検査
測定による収縮空状態再利用測定後の qubit は空になり、再初期化可能、量子状態の収縮を模擬
量子回路の自動並列化DAG スケジューラ関数内の文はデータ依存関係に基づき自動並列化、依存関係のないゲートは自然に並列実行
古典-量子ハイブリッド制御フロー統一構文量子操作と古典操作は同じ name: type = value 形式を使用

YaoXiang は「量子サポートを追加する」のではなく、自身の設計が既に量子ネイティブであることを発見した。

セマンティクス説明:本文書は YaoXiang の所有権セマンティクスを用いて量子操作を表現する。コンパイラ層で no-cloning を保証する(所有権安全性)。言語レベルの「消費-作成」は所有権移転の構文表現である——消費 = 所有権取得、返却 = 所有権移交。底层の実装は真に可逆な量子ゲート(量子状態をその場で変更)であり、本当に「新しい量子状態を作成する」わけではない。

設計目標 ​

  1. 新構文ゼロ:quantum、circuit などのキーワードを導入せず、すべての量子特性は既存の言語機構で表現する。
  2. 型安全性:コンパイラが量子状態がコピーされず、不正に使用されないことを保証する。
  3. トポロジ制約のコンパイル時検査:ジェネリック定数パラメータ Qubit(T, N) を介してコンパイル時に 2 量子ビットゲート操作が物理トポロジに適合するかを検証する。
  4. マルチバックエンド透過性:同一の量子コードをコマンドラインパラメータで切り替え、QIR(汎用エコシステム)または QCIS(国産量子命令セット)にコンパイル可能。
  5. 古典とのシームレスなハイブリッド:量子計算は古典関数を自由に呼び出し、古典コードも量子データを操作可能(ref 共有によるが、所有権制約を受ける)。

提案 ​

中核設計 ​

1. 量子型システムのマッピング ​

基本型:

yaoxiang
Qubit: Type0 = primitive_qubit
Complex: Type0 = { re: Float, im: Float }
  • Qubit は第一級市民型であり、所有権規則(Move、RAII)に従う。
  • Complex は振幅表現用であり、コンパイラはインライン化最適化可能。

関数としての量子ゲート:

yaoxiang
# 組み込み関数シグネチャ
H: (Qubit) -> Qubit = builtin_hadamard
X: (Qubit) -> Qubit = builtin_pauli_x
Y: (Qubit) -> Qubit = builtin_pauli_y
Z: (Qubit) -> Qubit = builtin_pauli_z
CNOT: (control: Qubit, target: Qubit) -> { Qubit, Qubit } = builtin_cnot
  • すべてのゲートは入力 qubit を消費し、新しい qubit(またはエンタングルペア)を返す。所有権回帰構文 q = H(q) は数学的セマンティクスに直接対応する。
  • 複数 qubit ゲートは構造体を返し、パターンマッチングまたはフィールドアクセスにより結果を取得する。

測定:

yaoxiang
measure: (Qubit) -> Int = builtin_measure   # qubit を消費し、古典ビットを返す
measure_all: (List(Qubit)) -> List(Int) = builtin_measure_all
  • 測定後 qubit は消費される(空になる)、ユーザは空状態再利用により再初期化可能。

初期化:

yaoxiang
qubit: (Int) -> Qubit = builtin_qubit   # 0 または 1 で基底状態を初期化

2. エンタングルメントと不透明型によるカプセル化 ​

エンタングルペアを不透明型としてカプセル化し、組み合わせ操作のみを提供、分解を禁止する:

yaoxiang
# 組み込み不透明型
BellPair: Type0 = primitive_bell_pair

# 組み込み関数 - 全体操作のみ可能
CNOT: (Qubit, Qubit) -> BellPair
measure_bell: (BellPair) -> { Int, Int }
split_bell: (BellPair) -> { Qubit, Qubit }  # エンタングルペアを分解(注意して使用すること)
apply_cnot_to_bell: (BellPair, Qubit) -> BellPair

中核設計:

  • フィールドアクセサを提供せず、組み込み関数を介した全体操作のみ許可
  • measure_bell(bp) はエンタングルペア全体を一度に消費し、古典ビットを返す
  • コンパイラはエンタングルペアの完全なライフサイクルを追跡可能

Python/Qiskit との比較:

Python (Qiskit): 実行時に回路を構築、エラーは送信後に発覚する可能性あり
YaoXiang:       コンパイル時にほとんどの論理エラーを捕捉

残りの 10%(物理的デコヒーレンス、ゲート誤差など)はハードウェアの問題であり、言語で解決できるものではない。

3. 物理トポロジ制約 ​

量子チップは制約付きトポロジグラフであり、任意の 2 つの qubit が 2 量子ビットゲートを実行できるわけではなく、隣接している必要がある。YaoXiang はジェネリック定数パラメータを使用してコンパイル時にトポロジ制約を保証する。

トポロジ型定義:

yaoxiang
# トポロジは型であり、隣接行列を含む
Topology: Type0 = primitive_topology

# 組み込みトポロジ定数
Linear8: Topology = topology(8)          # 線形 8 ビット: 0-1-2-3-4-5-6-7
Grid3x3: Topology = topology(3, 3)        # 3x3 グリッド
Ring16: Topology = topology(16, ring)    # リング型 16 ビット

Qubit へのトポロジと位置のバインド:

yaoxiang
# Qubit(T, N) - T はトポロジ型、N は定数位置パラメータ
q0: Qubit(Grid3x3, 0)   # Grid3x3 トポロジ、位置 (0,0)
q1: Qubit(Grid3x3, 1)   # Grid3x3 トポロジ、位置 (0,1)
q2: Qubit(Grid3x3, 2)   # Grid3x3 トポロジ、位置 (0,2)
q3: Qubit(Grid3x3, 3)   # Grid3x3 トポロジ、位置 (1,0)

ゲート操作の自動制約:

yaoxiang
# CNOT 型シグネチャはトポロジ制約を含む
CNOT: (T: Topology, I: Int, J: Int) -> (
    (Qubit(T, I), Qubit(T, J)) -> { Qubit(T, I), Qubit(T, J) }
) when adjacent(T, I, J)

# コンパイル時検査
CNOT(q0, q1)  # ✅ Grid3x3 において (0,0) と (0,1) は隣接
CNOT(q0, q2)  # ❌ コンパイルエラー:(0,0) と (0,2) は隣接していない

adjacent コンパイル時制約:

  • adjacent はコンパイル時関数であり、トポロジの隣接行列を利用して静的検査を行う
  • 定数インデックスの場合 100% コンパイル時検証
  • 動的インデックスの場合、実行時検査コードを生成

仮想から物理へのマッピング:

yaoxiang
# コンパイル時に具体的な物理位置が不明?型推論を使用
q = qubit(Grid3x3)  # 自動的に位置 0 を割り当て、後続の推論

4. 所有権と量子状態の線形フロー ​

すべての量子操作は Move セマンティクスに従い、qubit がコピーされないことを保証する:

yaoxiang
q = qubit(0)
q2 = q          # ❌ コンパイルエラー:q は既に移動済み、再使用不可
q = H(q)        # ✅ q を消費し、新しい q を返す
measure(q)      # ✅ q を消費、その後 q は空になる
q = qubit(0)    # ✅ 空状態再利用

4. 自動並列化と DAG スケジューリング ​

Standard または Full Runtime において、DAG スケジューラは量子プログラムを自動的に解析する:

yaoxiang
apply_two_qubit_gates: () -> {Qubit, Qubit} = () => {
    q1 = H(qubit(0))
    q2 = H(qubit(0))
    # 上記 2 行はデータ依存関係なし、DAG により自動並列実行
    CNOT(q1, q2)   # q1 と q2 に依存、自動的に待機
}
  • スケジューラは num_workers 設定(物理量子プロセッサ数)を利用して真の並列化を実現。
  • ユーザはゲート順序を手動で配置する必要はなく、データフローを記述するだけでよい。

5. 古典計算とのハイブリッド ​

古典コードと量子コードは完全に融合する:

yaoxiang
grover_search: (target: Int) -> Int = () => {
    n = 4
    qubits = List(Qubit)()
    for i in 0..n {
        qubits.append(H(qubit(0)))
    }
    # 古典ループと量子操作のハイブリッド
    oracle(qubits, target)   # oracle は量子ゲートシーケンス
    qubits = diffusion(qubits)
    results = measure_all(qubits)
    return decode_result(results)   # 古典後処理
}
  • 同一関数内で量子ゲートと古典制御フローを任意に混在可能。
  • 所有権システムは量子変数が古典分岐で誤ってコピーされないことを保証する。

6. マルチバックエンドサポートアーキテクチャ ​

┌─────────────────┐     ┌─────────────────┐     ┌─────────────────┐
│   YaoXiang 源   │     │   型検査        │     │   DAG 中間表現  │
│   (統一構文)     │────▶│   + 所有権分析  │────▶│   (データフローグラフ) │
└─────────────────┘     └─────────────────┘     └────────┬────────┘
                                                          │
                                                          ▼
                          ┌─────────────────────────────────────────────┐
                          │           コード生成バックエンド (プラガブル)   │
                          ├─────────────────┬───────────────────────────┤
                          │  QIR バックエンド │  QCIS バックエンド        │
                          │  (汎用エコシステム)│  (国産量子命令セット)     │
                          ├─────────────────┼───────────────────────────┤
                          │  - .ll ファイル出力│  - .qcis テキスト出力   │
                          │  - 多種 QPU 対応 │  - 中科院/国盾ハード対応 │
                          └─────────────────┴───────────────────────────┘
  • コンパイルフロー:フロントエンド統一 → DAG 構築 → バックエンド選択 → ターゲットコード生成。
  • QIR バックエンド:DAG ノードを QIR の量子ゲート intrinsic にマッピングし、LLVM bitcode を生成、LLVM 最適化をさらに活用可能。
  • QCIS バックエンド:DAG を QCIS 命令(H q0 など)にシリアライズし、量子チップ制御コンソールへの直接送信をサポート。

例 ​

ベル状態生成と測定 ​

yaoxiang
bell_measure: () -> {Int, Int} = () => {
    q1 = H(qubit(0))
    q2 = H(qubit(0))
    bell = CNOT(q1, q2)  # BellPair 不透明型を返す
    result = measure_bell(bell)  # 2 ビットを一度に測定
    return result
}

量子テレポーテーション(簡略版) ​

yaoxiang
teleport: (msg: Qubit, bell: BellPair) -> Qubit = (msg, bell) => {
    # エンタングルペアを分解して 2 つの独立した qubit を取得
    (alice_qubit, bob_qubit) = split_bell(bell)

    # Alice の操作
    (msg, alice_qubit) = CNOT(msg, alice_qubit)
    msg = H(msg)
    a1 = measure(msg)
    a2 = measure(alice_qubit)

    # 古典情報伝送(スケジューラが自動的に依存関係を処理)
    # Bob の操作
    if a2 == 1 { bob_qubit = X(bob_qubit) }
    if a1 == 1 { bob_qubit = Z(bob_qubit) }
    return bob_qubit
}

詳細設計 ​

組み込み型と関数の定義 ​

compiler/builtins モジュールに追加:

rust
builtins.insert("Qubit", Ty::Primitive(Primitive::Qubit));
builtins.insert("Complex", Ty::Record(vec![
    ("re", Ty::Primitive(Primitive::Float)),
    ("im", Ty::Primitive(Primitive::Float)),
]));

// 量子ゲート
for (name, sig) in GATES {
    builtins.insert(name, Ty::Function(vec![Ty::Qubit], Ty::Qubit));
}
builtins.insert("CNOT", Ty::Function(
    vec![Ty::Qubit, Ty::Qubit],
    Ty::Record(vec![
        ("q0", Ty::Qubit),
        ("q1", Ty::Qubit)
    ])
));
builtins.insert("measure", Ty::Function(vec![Ty::Qubit], Ty::Primitive(Primitive::Int)));
builtins.insert("qubit", Ty::Function(vec![Ty::Primitive(Primitive::Int)], Ty::Qubit));

Qubit に対する所有権チェッカーの特殊処理 ​

  • Qubit は !Copy とマークされ(デフォルト Move)、暗黙的コピーを禁止。
  • 測定関数 measure の引数は Qubit(値渡し)であり、所有権を消費する。
  • 複数 qubit ゲートが返すレコード型では、フィールドはすべて Qubit であり、引き続き所有権規則に従う必要がある。

量子ゲートに対する DAG スケジューラの最適化 ​

  • 量子ゲートノードは純関数(副作用なし)として扱われ、スケジューラは依存関係のないゲートを任意に並び替え可能。
  • スケジューラが「量子命令シーケンス」を出力する際、データ依存関係を保持し、並列ゲートをグループ化する(マルチ量子プロセッサに適応)。
  • 設定 --target-num-qubits および --target-topology をサポートし、後続のレイアウトとルーティングに使用(将来の拡張)。

QIR バックエンド詳細マッピング ​

YaoXiang 操作QIR 命令
H(q)call void @__quantum__qis__h__body(%Qubit* %q)
CNOT(q1, q2)call void @__quantum__qis__cnot__body(%Qubit* %q1, %Qubit* %q2)
measure(q)%result = call i1 @__quantum__qis__mz__body(%Qubit* %q)
qubit(0)%q = call %Qubit* @__quantum__rt__qubit_allocate()

QIR バックエンドは LLVM の -O2 をさらに活用して最適化し、QIR Alliance 互換の bitcode を出力する。

QCIS バックエンド詳細マッピング ​

YaoXiang 操作QCIS 命令
H(q) (q は物理ビット 2 に対応)H 2
CNOT(q1,q2) (q1→ビット 0, q2→ビット 1)CNOT 0 1
measure(q) (ビット 0)M 0
qubit(0) 初期化最初に使用する命令に暗黙的に含まれ、追加命令不要
  • 仮想 qubit(YaoXiang 変数)から物理ビットへのマッピングテーブルを維持する必要がある。
  • トポロジ制約検査をサポート(将来実装)。

ハイブリッド古典コード生成 ​

  • 古典部分(ループ、条件、整数演算など)は通常通りネイティブコード(x86/ARM)を生成し、FFI または埋め込み呼び出しを介して量子バックエンドと対話する。
  • QIR バックエンドでは、古典部分を LLVM IR に降格でき、QIR と混合コンパイル可能。

型システムへの影響 ​

  • Qubit および Complex プリミティブ型を追加。
  • Qubit は自動的に Move セマンティクスを有し、コピーを禁止。
  • 量子ゲート関数シグネチャを型システムに登録する必要がある。

後方互換性 ​

  • ✅ 完全後方互換
  • 新規組み込み型と関数を追加するが、既存コードに影響なし
  • 量子特性はオプションであり、有効化しない場合は余分なオーバーヘッドなし

トレードオフ ​

利点 ​

  • 新構文なし:開発者は少数の組み込み関数を学習するだけで量子プログラムを記述可能。
  • 型安全性:所有権システムが自動的に qubit のコピーを防止し、一般的な量子プログラミングエラーを回避。
  • 自動並列化:DAG スケジューラがゲートレベルの並列化を無償提供、追加のコンパイラ最適化不要。
  • エコシステム互換性:QIR バックエンドにより YaoXiang は複数の量子クラウドプラットフォームで実行可能;QCIS バックエンドにより自主可控を保証。
  • ハイブリッド能力:古典量子の融合が自然であり、複雑な量子アルゴリズム(Shor、Grover などの古典制御を含む)の記述に適する。

欠点 ​

  • Qubit 数の静的性:現在の設計は qubit 数がコンパイル時に既知と仮定している、動的割り当ては List(Qubit) 経由で行う必要があるが、List のヒープ割り当ては余分なオーバーヘッドを生む可能性がある(最適化で緩和可能)。
  • 測定後の再利用:空状態再利用により qubit の再初期化が可能だが、物理量子ビットは緩和時間を持つ可能性があり、ランタイムシステムが処理する必要がある(現状はユーザ責任)。
  • 動的トポロジマッピング:ランタイムで初めて物理トポロジが判明する場合、コンパイル時検査が機能しない、実行時検査コードを生成する必要がある(現行バージョンは静的検査のみサポート)。

代替案 ​

方案選択しない理由
quantum キーワードと circuit 型の導入新構文の増加、学習コスト高、YaoXiang の簡潔設計原則に反する
量子サポートをライブラリとしてのみ実装コンパイラの量子状態安全性保証を活用不可、DAG スケジューラとの深い統合不可
量子ハードウェア成熟を待ってからサポート量子プログラミング言語設計の重要なウィンドウを逃す
既存量子フレームワーク(Qiskit など)の再利用量子セマンティクスがライブラリで実装され、型システムと所有権システムの安全保障を得られない
量子サブ言語の個別設計言語複雑度の増加、保守コスト高

実装戦略 ​

段階区分 ​

フェーズ時間内容
Phase 11 ヶ月基本量子型と組み込み関数:コンパイラに Qubit、Complex 型を追加、組み込み関数の型検査を実装、所有権チェッカーを拡張
Phase 21 ヶ月DAG スケジューラの量子ゲート認識:DAG 構築ロジックを変更、量子ゲートを純関数としてマーク、並列ゲートグループ化出力を実装
Phase 32 ヶ月QIR バックエンドプロトタイプ:DAG から QIR コード生成器を実装、LLVM を統合、QIR シミュレータ接続検証
Phase 42 ヶ月QCIS バックエンドプロトタイプ:DAG から QCIS 命令への翻訳を実装、仮想-物理ビットマッピングを設計、国産量子プラットフォーム接続検証
Phase 52 ヶ月ハイブリッド古典強化:古典制御フローと量子ゲートの交差コード生成が正しいことを保証、List(Qubit) サポート、サンプルプログラム追加
Phase 62 ヶ月最適化とドキュメント:基本レイアウトとルーティングを実装、ユーザガイドと量子プログラミングチュートリアルを執筆、プレビュー版リリース

リスク ​

  1. 量子ハードウェア可用性:外部量子シミュレータと実際の QPU の可用性に依存。

    • 緩和策:オープンソースシミュレータ(QIR runner、Qiskit Aer)への接続を優先、実際の QPU は長期目標とする。
  2. バックエンド実装の複雑性:QIR および QCIS 仕様が変更される可能性。

    • 緩和策:コード生成インターフェースを抽象化し、バックエンド差異を隔離し、後続の適応を容易にする。
  3. 性能不確実性:量子プログラムの性能特性は古典プログラムと異なる。

    • 緩和策:性能プロファイリングツールを提供し、ユーザにゲートレベル並列化効果の理解を促す。

オープン問題 ​

  • [x] トポロジ制約:Qubit(Topology, N) ジェネリック定数パラメータによるコンパイル時検査を実装済み。
  • [ ] 動的量子レジスタ:List(Qubit) を QCIS バックエンドでどうマッピングするか?対応する数の物理ビットを生成可能だが、ランタイム割り当て機構が必要。
  • [ ] エラー緩和:動的デカップリングなどの組み込みエラー緩和構造を提供するか?まずライブラリとして実装可能。
  • [ ] 既存量子 SDK との相互運用性:QASM または QIR モジュールをインポート可能か?将来的に FFI を検討。
  • [ ] 自動レイアウトとルーティング:仮想 qubit 数が物理 qubit 数を超える場合、自動的にマッピングする方法?

参考文献 ​


ライフサイクルと帰結 ​

┌─────────────┐
│   草稿      │  ← 著者作成
└──────┬──────┘
       │
       ▼
┌─────────────┐
│  審査中     │  ← コミュニティ議論
└──────┬──────┘
       │
       ├──────────────────┐
       ▼                  ▼
┌─────────────┐    ┌─────────────┐
│  受理       │    │  拒否       │
└──────┬──────┘    └──────┬──────┘
       │                  │
       ▼                  ▼
┌─────────────┐    ┌─────────────┐
│   accepted/ │    │    rfc/     │
│ (正式設計)  │    │ (原位置保持) │
└─────────────┘    └─────────────┘

状態説明 ​

状態位置説明
草稿docs/design/rfc/draft/著者草稿、提出審査待ち
審査中docs/design/rfc/オープンなコミュニティ議論とフィードバック
受理docs/design/accepted/正式設計文書となり、実装段階へ進む
拒否docs/design/rfc/RFC ディレクトリに保持、状態を更新