コンパイルとトランスパイル: 内部の仕組み

1. パイプラインの全体像¶

Transpiler.transpile()はqamomile/circuit/transpiler/transpiler.pyに、10個のパスの合成として記述されています。各ステージはフロントエンド → インライン化 → 解析 → emissionという4つの帯に分かれ、**BlockKind**の遷移で区切られます:

QKernel
   │  to_block                    (トレーシング: Python AST → IR)
   ▼
Block [HIERARCHICAL]
   │  substitute                  (ルールベースの置換、オプション)
   │  resolve_parameter_shapes    (Vectorのshape次元を具体化)
   │  inline                      (CallBlockOperationsを展開)
   ▼
Block [AFFINE]
   │  unroll_recursion            (inline ↔ partial_evalの反復)
   │  affine_validate             (アフィン型のセーフティネット)
   │  partial_eval                (定数畳み込み + コンパイル時if)
   │  analyze                     (依存グラフ + I/O検証)
   ▼
Block [ANALYZED]
   │  validate_symbolic_shapes    (未解決のVector次元を拒否)
   │  plan                        (C→Q→Cにセグメント化)
   ▼
ProgramPlan
   │  emit                        (バックエンド固有のコード生成)
   ▼
ExecutableProgram[T]

どのパスも冪等で、Transpilerの公開メソッドとして公開されています。そのため1つずつ実行して、間でBlockを出力できます。これがQamomileで最も役立つデバッグ手法です。

2. IRの用語¶

パスを実行する前に、出力することになる対象に名前を付けておきましょう。

Block¶

Block (qamomile.circuit.ir.block) はパイプラインを流れるコンテナです。以下を保持します:

• operations: Operationインスタンスの順序付きリスト

• input_values / output_values: カーネルのシグネチャに対応するSSAのValue

• parameters: 未バインドのパラメータ名からValueへの辞書

• kind: どの不変条件が現在成立しているかを示すBlockKindタグ（TRACED、HIERARCHICAL、AFFINE、ANALYZED）

BlockKind¶

BlockKindはパイプラインのステートマシンです。各パスはkindに対する事前条件を持ち、成功時にkindを進めます。進行は単調です:

TRACED  →  HIERARCHICAL  →  AFFINE  →  ANALYZED

余談: なぜ「AFFINE」と呼ぶのか¶

プログラミング言語の型理論では、ある値を何回使ってよいかで型を3種類に分けます:

量子の場合、no-cloning theorem（量子状態は複製できない）によって「同じ値を2回使う」のは物理的に不可能です。つまりqをqmc.h(q)で消費したら、その古いqはもう使えず、新しい版q'が生まれる — これがまさにaffine（高々1回）の定義に一致します。

ちなみに「使わずに捨てる」ことは許容されます（q = qmc.h(q)のあとqを返さず捨ててもエラーにはならない。最終的には測定で消費されるのが健全ですが、型制約としては"linear"ほど厳しくない）。そのためQamomileは"linear"ではなく"affine"という呼び方を選んでいます。

BlockKind.AFFINEは、このaffine型不変条件（「各量子値は高々1回だけ使われている」）が検証可能な状態でブロックが仕上がっていることを意味します。実際の検証はAffineValidationPassが担当し、違反するとAffineTypeErrorが送出されます。

Value とOperation¶

Value (qamomile.circuit.ir.value) はSSAスタイルの型付き値です。Qubitに限らずFloat、UInt、Bitなどすべての値がValueとして表現されます。ゲート適用や古典演算でその値が更新されるたびに、Value.next_version()が新しいValueを生成します。このときversionとuuidは新しくなりますが、logical_idと型・メタデータは保たれます。

logical_idは「SSAのバージョンをまたいで同じ論理的な変数を指す」ための安定した識別子です。たとえばq = qmc.h(q)で新しいValueが作られても、元のqと同じlogical_idを持ちます。これは物理量子ビットへのマッピングではなく、IR上で「同じ変数の別バージョン」を結びつけるためのもので、FloatパラメータやBitなどにも同じ仕組みが使われます（バックエンドの物理量子ビット割り当ては後段のemitでResourceAllocatorが決めます）。

メタデータで値をパラメータ（with_parameter("theta")）や定数（with_const(2.0)）としてタグ付けできます。

Operationはオペレーション階層の基底クラスです。サブクラスには以下があります:

制御フロー系のOperationはすべてHasNestedOpsプロトコル（nested_op_lists() / rebuild_nested()）を実装しているので、パスは各Operationの型を特別扱いせず、ループや分岐の本体へ統一的に踏み込めます。

どのOperationもoperation_kind（QUANTUM、CLASSICAL、HYBRID、CONTROL）を報告します。これはplanステージがブロックを古典・量子・期待値のステップへセグメント化する際に使います。

3. 題材となるカーネル¶

出力できる程度に小さく、複数のステージを動かせる程度に豊かなカーネルが必要です:

• ヘルパーとなる@qkernel（inlineを動かすため）

• qmc.range(n)を駆動するUIntパラメータ（partial_evalを動かすため）

• 未バインドのまま残すFloatパラメータ（emitのパラメータ処理を動かすため）

n=3をコンパイル時にバインドし、thetaはバックエンドパラメータとして保持してトランスパイルします。

1行サマリーでは十分でないときのために、qamomile.circuit.ir.pretty_print_blockがBlockのMLIR風テキストダンプを返します。各パスの前後で何がどう変わったかを目で確認するには、こちらが最速です。depth引数でCallBlockOperationの展開深さを制御できるので、たとえばdepth=1なら「inlineが実行したら何が起こるか」を先取りして眺められます。

4. ステージごとのウォークスルー¶

各パスを手動で実行していきます。上のsummariseヘルパーがステージごとに1行ずつ出力するので、BlockKindとOperationの内訳を比較しやすくなります。pretty_print_blockはステージの詳細を追いたいタイミングで差し込んでください。

4.1 to_block — Python関数のトレーシング¶

to_blockはデコレート済み関数をトレーサコンテキスト下で実行します。qmc.h(...)、qmc.range(...)、entangle_pair(...)の各呼び出しはOperationとしてBlockに記録されます。他の@qkernelへの呼び出しはCallBlockOperationになり、本体はまだインライン展開されません。

ブロックの中身を実際にテキストで眺めてみましょう。pretty_print_blockはBlockをMLIR風のインデント付きテキストへ整形します。for本体にcall entangle_pair(...)がまだ生きていることが確認できます。

depth=1を付けると、CallBlockOperationの先が呼び出し行のブレース内にインライン展開された形で表示されます。これは「inlineを1回通したらどうなるか」を先読みしているのと同じ見た目で、次の節の内容を予習できます。

ブロックはHIERARCHICALです。他のブロックへの呼び出しや複合ゲートをまだ含む可能性があります。block.parametersは渡した引数parameters=["theta"]を反映しています。parametersにない入力は、bindingsでバインドする（nのように）か、トレース時のPythonコードで消費されなければなりません。

4.2 inline — ネストしたブロック呼び出しの平坦化¶

inlineはすべてのCallBlockOperationを対象ブロックのOperationで置き換え、結果がwell-formedであり続けるようSSA値を置換します。CallBlockOperationが残らなくなるとブロックはAFFINEへ遷移します。

再度pretty_print_blockで眺めると、call entangle_pair(...)が消え、h/cxが直接for本体に並んでいることが確認できます。ブロックのkindはAFFINEへ進みました。

inlineはループをアンロールしないことに注目してください。ForOperationの本体には、元のentangle_pair本体内にあったforの各反復に対応するGateOperationが1つずつ入っています。インライン化は制御フローを保ちます。アンロールは次です。

4.3 partial_eval — 定数畳み込みとコンパイル時ifの除去¶

partial_evalは2つのサブパスから構成されます:

1. ConstantFoldingPass — オペランドがすべて定数（またはバインド済みパラメータ）のBinOp/CompOpを具体値へ畳み込みます。n=3をバインドしたので、qmc.range(n - 1)のn - 1は2に畳み込まれ、ForOperationの境界はリテラル値になります。

2. CompileTimeIfLoweringPass — 条件がコンパイル時に解決可能なIfOperationを、選ばれた分岐のOperation列で置き換えます。測定結果に依存するIfOperationはここでは触りません。

なお、ForOperation自体はこのパスではアンロールされません。ループ展開は必要であれば後段のemitでLoopAnalyzerが判定します（詳しくは5章）。そのためここでForOperationsの個数は減りません。

UIntを未バインドのまま残してループ境界に使うと、下流のvalidate_symbolic_shapesパスが該当する値の名前とともにQamomileCompileErrorを送出します。これは「このカーネルは実はコンパイル時に構造化されていない」という状況を、後段での分かりにくいクラッシュではなく読みやすいエラーへ変換することを担当するパスです。

4.4 analyze — 依存グラフとI/O検証¶

analyzeは値の依存グラフを構築し、2つの不変条件をチェックします:

1. ブロックの入出力が古典であること（量子I/Oはエントリポイントではなくサブルーチンブロックでのみ許可されます）。

2. OperationKind.QUANTUMのOperation が、古典型オペランドとして測定由来の古典値を受け取らないこと。より具体的には、rx(q, theta)のthetaのようなゲートの古典引数が、測定結果から計算された値であってはいけません（rotation角などの古典計算をJITする必要が出るため）。

この規則は動的量子回路を禁止するものではありません。IfOperation/WhileOperationはOperationKind.CONTROLなのでこのチェック対象外で、測定結果Bitを条件とする制御フロー（if bit: ... / while bit: ...）は通ります。また、Phiで合流した量子型の値も明示的に例外扱いです。動的量子回路と禁止パターンの具体的な違いは5章で扱います。

成功するとブロックはANALYZEDへ遷移します。

4.5 plan — ProgramPlanへのセグメント化¶

planは解析済みブロックを辿り、OperationKindごとにOperationをグループ化し、ClassicalStep / QuantumStep / ExpvalStepのエントリからProgramPlanを組み立てます。デフォルトのトランスパイラが使うNisqSegmentationStrategyは**QuantumStepを多くても1つ**に制限します。これが典型的なC→Q→Cパターンです。

量子セグメントはqubit_valuesとnum_qubitsも持ちます。これによりemitはゲートを配置する前に、バックエンド回路が必要とする量子ビット本数を把握できます。

4.6 emit — バックエンド固有のコード生成¶

emitはプランを対象バックエンドのEmitPassに渡します。emitパスは具体的な量子ビットインデックスを割り当て、量子セグメントを辿ってバックエンドのGateEmitterプロトコルのメソッド（emit_h、emit_rx、…）を呼び出してネイティブ回路を構築します。

残ったパラメータはまさに保持したもの（theta）です。量子ビット数、ループのアンロール、どのCXがどこに入るかといった構造的な決定はすべてコンパイル時に解決されました。

4.7 スキップしたパス¶

transpile()の一部でありながら明示的に呼ばなかったパスが5つあります:

• substitute — ユーザーが設定したSubstitutionRuleを適用してブロックのターゲットを置換したり、複合ゲートの戦略を上書きします。TranspilerConfigにルールがない場合はno-opです。

• resolve_parameter_shapes — bindingsが具体的なVectorやMatrix値を提供する場合、{name}_dim{i}のshape次元を埋めます。これにより下流でarr.shape[0]が具体的なUIntとして解決されます。

• unroll_recursion — 自己再帰の@qkernel（例: Suzuki–Trotter、チュートリアル07参照）に対するinline ↔ partial_evalの固定点ループです。再帰が底まで展開されると終了し、bindingsでベースケースに到達できない場合はエラーになります。

• affine_validate — フロントエンドのチェックをすり抜けたアフィン型違反を捕まえるセーフティネットです。

• validate_symbolic_shapes — 未解決のVectorshape次元がForOperationの境界に到達した場合、実行可能なエラーメッセージで拒否します。

いずれも冪等かつ安価なので、transpile()は常にこれらを実行します。パスを書く側としては順序に注意するだけで十分です: substituteとresolve_parameter_shapesはinlineの前、affine_validateはinlineの後、validate_symbolic_shapesはanalyzeの後（依存グラフが使えるように）に実行されます。

5. 制御フロー (if / for / while) の取り扱い¶

パイプラインが制御フローをどう扱うかは、フロントエンドで何を受け付けるかから、各パスがそれをどう変形するか、そしてバックエンドが実行時分岐をサポートするかまで、複数のレイヤーに関わります。ここではその全体像を整理します。ユーザー向けの書き方はチュートリアル05にあり、本章はコンパイラ側の視点に絞ります。

5.1 フロントエンドで受け付ける形¶

@qkernelはトレース前にASTを書き換えます（qamomile/circuit/frontend/ast_transform.pyのControlFlowTransformer）。ここで以下のように変換されます:

• Pythonのif文 → emit_if(cond, true_branch, false_branch, ...)呼び出し

• for文 → for_loop(start, stop, step)またはfor_items(dict)コンテキストマネージャ

このため、実行時に決まる量子レジスタ・測定結果・未バインドの値を素のPythonのif/forで使ってもトレース時に両分岐・各反復を実行する、という直感的な動作になります。対応するループ記法は:

• qmc.range(n) — シンボリックなループ境界。nがコンパイル時に定まらなくてもForOperationとしてIRに残せます。

• qmc.items(d) — 辞書・スパースデータ用。常にコンパイル時にアンロールされます（ForItemsOperation）。

• 直接のfor i in <runtime_value>: — 拒否されます。必ずqmc.range(...)かqmc.items(...)を経由してください。

whileはwhile_loopコンテキストマネージャで書きます。条件は測定結果 (Bit) でなければならず、古典変数や定数を条件にすると後段のValidateWhileContractPassで拒否されます。

5.2 IR表現¶

qamomile/circuit/ir/operation/control_flow.pyに以下が定義されています:

4つともHasNestedOpsを実装しているので、パスはnested_op_lists() / rebuild_nested()経由で本体へ再帰的に入れます。isinstanceのチェーンは書かないのが流儀です。

IfOperationには値をマージするPhiノード (PhiOp) が付きます。両分岐で同じ論理量子ビット・古典変数を異なるバージョンで更新した場合、分岐後に使う側はPhi経由でどちらのバージョンなのかを参照します。

5.3 パスごとの挙動¶

制御フローは各パスで次のように扱われます:

LoopAnalyzer.should_unroll() （transpiler/passes/emit_support/loop_analyzer.py）の判定基準は:

1. ループ境界が外側のループ変数に依存する（動的入れ子）

2. 本体で配列をloop_varでインデックスしている（例: q[i]）

3. loop_varがBinOpに現れる（例: i + 1、2 * i）

本チュートリアルのdemo_kernelはq[i]とq[i + 1]の両方を使うので、条件1, 2, 3に該当してemit時にアンロールされます。これがexecutable.quantum_circuitがフラットな2量子ビット分のCX列になっている理由です。上記のどれにも該当しないループは、バックエンドが対応している限り実行時ループとして回路に残ります。

5.4 量子と古典の依存関係ルール (analyze)¶

analyzeパスは、量子Operationは測定から派生した古典値に依存してはならないという不変条件を強制します。

# OK: 測定結果Bitを条件に量子ゲートを実行
b = qmc.measure(q)
if b:
    q = qmc.x(q)

# NG: 測定結果から計算した古典値を量子ゲートの引数に使う
b = qmc.measure(q)
x = some_classical(b)
q = qmc.rx(q, x)   # analyzeで拒否

前者は測定結果BitをIfOperationの条件として直接使うだけで、量子オペランドの型は変わりません（位相キックバック的な制御は行いません）。後者はJITコンパイルが必要になり、現時点ではサポートしていません。planステージが量子セグメントを1つに制限することがこの保証の裏返しです。

5.5 バックエンドの実行時分岐サポート¶

実行時のif/while（=測定結果に依存する分岐）が回路まで落ちてくるかはバックエンドのMeasurementModeに依存します（qamomile/circuit/transpiler/gate_emitter.py）:

非対応モードのバックエンドでIfOperation/WhileOperationを含むカーネルをtranspileしようとすると、emitパスがエラーを送出します。モードを意識してカーネル側で実行時分岐を書くかどうか決めるのがコントリビュータの責任です。

5.6 よくあるエラー¶

• ValidationError (analyze) — 測定から派生した古典値を量子ゲートの引数に使った。パターンを書き換えるか、測定の代わりに状態を保つように設計を見直してください。

• ValidateWhileContractPassエラー — whileの条件が測定結果Bitでない。Pythonの古典変数や定数条件でのループは未サポートです。

• QamomileCompileError (validate_symbolic_shapes) — ForOperationの境界に未解決のVector shape次元が届いた。該当するVectorをbindingsで具体化するか、qmc.itemsを使う設計に変えてください。

• emit時エラー — MeasurementMode.STATICのバックエンドに実行時ifが到達した。バックエンドを変えるか、カーネルを別の等価表現で書き直します。

6. ケーススタディ: MeasureQFixedはどうコンパイルされるか¶

量子位相推定 (QPE) の結果のように、量子ビット列を固定小数点の数値として読み出したい場面があります。QamomileはVector[Qubit]をQFixed型へ再解釈し、それをqmc.measureに渡すとFloatが返る、という1行APIを提供しています:

qf = qmc.cast(q, qmc.QFixed, int_bits=0)   # Vector[Qubit] -> QFixed
phase = qmc.measure(qf)                     # QFixed -> Float

これがパイプラインを通るとき、IRレベルで何が起きているのかを追います。MeasureQFixedOperationはOperationKind.HYBRID（量子測定 + 古典デコードを1つにまとめた論理操作）として登場し、後段で量子部分と古典部分に分解される、というのが要点です。

6.1 小さなデモカーネル¶

3量子ビット分のHadamard重ね合わせをQFixedとして測定するだけの最小例を用意します。

analyzeまでパスを進めて、直後の状態を見てみます。

末尾はmeasure_qfixedという1行です — Vector[Qubit]をQFixed型へcastした値にそのままmeasureが掛かっています。このOperationはoperation_kind=HYBRIDを持っていますが、実際のバックエンドには量子測定命令しかないので、どこかで「量子側の測定」と「古典側のデコード」に切り分ける必要があります。

6.2 どこで切り分けるか — plan段の事前ローワリング¶

この分解を担当するのがplan段が呼び出すlower_operations()（qamomile/circuit/transpiler/passes/separate.py）です。MeasureQFixedOperationを見つけるたびに:

1. MeasureVectorOperation — QFixedが持つ全量子ビットをVector[Qubit]として測定しVector[Bit]を得る（OperationKind.HYBRIDだが、セグメント化の観点では量子セグメントの末尾に置かれる）

2. DecodeQFixedOperation — 得られたビット列を固定小数点でデコードしてFloatにする（OperationKind.CLASSICAL）

という2つのOperationに置き換えます。planの本題であるセグメント化は、このローワリング結果をそのまま「量子セグメント終わりに測定、その後に古典セグメントでデコード」として並べるだけです。

内部挙動を目で見たいときはlower_operationsを直接呼べます。

measure_qfixedが消え、measure_vector(...) → decode_qfixed(...)の2行に展開されています。同じFloatがresult側のlogical_idで繋がったままなので、後段の依存解析や値バインドは影響を受けません。

6.3 emit と実行への反映¶

ローワリング後、ProgramPlanは概念的に以下のようなステップを並べます:

• QuantumStep（量子セグメント）: 回路本体のゲート列 + MeasureVectorOperation。バックエンドのemit_measure_vectorが展開し、各量子ビットごとにemit_measureが呼ばれてビットがクラシカルレジスタに書かれます。

• ClassicalStep (role=post)（古典セグメント）: DecodeQFixedOperationが1つだけ。qamomile/circuit/transpiler/classical_executor.pyのランタイムが、量子実行で得たビット列を受け取ってFloatに変換します。

つまり量子ハードウェア側に届くのはあくまで通常の測定命令です。「QFixed測定」というAPIはコンパイル時の抽象化であって、実行時のバックエンドが何か特殊な命令を解釈するわけではありません。

6.4 どのパスがどのIRを触るかのまとめ¶

この構図は、CastOperation（型の再解釈だけで物理量子ビット割り当てを変えない）と合わせて、「量子リソースを触らずに古典的意味付けだけを変える」Qamomileの型設計パターンの良い例になっています。

7. バックエンドemission: Qiskit vs QURI Parts¶

どのバックエンドも、qamomile/circuit/transpiler/で定義された2つのプロトコルを実装することでパイプラインに接続します:

• GateEmitter[T] (gate_emitter.py): 「ゲートをどう描くか」のAPIです。create_circuit(num_qubits, num_clbits) -> T、create_parameter(name) -> Any、ゲートごとの約40個のエントリポイント（emit_h、emit_rx、emit_cx、…）を持ちます。加えてmeasurement_mode: MeasurementModeを告知します:

  モード	意味	利用バックエンド
  NATIVE	emitパスが呼ぶ明示的な測定命令をバックエンドが持つ。	Qiskit
  STATIC	バックエンドは測定前の状態ベクトル・演算子を受け取り、samplerが測定を外部で処理する。	QURI Parts
  RUNNABLE	バックエンドがランタイム制御フロー付きのmid-circuit測定をサポートする。	CUDA-Q (cudaq.run()経由)

• CompositeGateEmitter[C] (passes/emit.py): オプションです。バックエンドが複合ゲート（QFT、QPE、…）をネイティブ実装でショートカットできるようにします。can_emit(gate_type) -> bool / emit(...) -> boolのコントラクトで、オプトアウトするにはFalseを返します。その場合emitパスはライブラリレベルの分解にフォールバックします。

Transpilerのサブクラスは_create_segmentation_passと_create_emit_passをオーバーライドし、ランタイム側のためにexecutor()も実装することでこれらを接続します。qamomile/qiskit/transpiler.pyは約50行の標準的なリファレンス実装です。

では同じカーネルをQURI Parts経由でトランスパイルして比較してみましょう。QURI Partsはオプション依存です。ローカルで再現するにはpip install 'qamomile[quri_parts]'でインストールしてください。

指摘すべき違いは3つあります:

1. 回路の型。 QiskitはParameterオブジェクトを埋め込んだQuantumCircuitをemitします。QURI PartsはパラメータがQURI PartsのParameterインスタンスであるLinearMappedParametricQuantumCircuitをemitします。どちらもQamomileのparameter_namesを同じ形で往復します。

2. 測定。 Qiskitの回路はmeasure命令で終わります（measurement_mode=NATIVE）。QURI Partsの回路は測定ゲートを持ちません。サンプリングは実行時にexecutorが処理します（measurement_mode=STATIC）。

3. 複合ゲート。 カーネルがqmc.qft(...)を使う場合、QiskitのQiskitQFTEmitterはQFTGateボックスを配置しますが、QURI Partsバックエンドはライブラリパス経由で分解します。IRは同じですが、実現される回路は異なります。カーネルごとにTranspilerConfig.with_strategies({"qft": "approximate"})で上書きできます。

8. コントリビュータ向けのポインタ¶

カスタムパスの記述。 qamomile/circuit/transpiler/passes/に配置し、Blockを受け取りBlockを返すようにして、入力kindの事前条件を冒頭でアサートしてください。Operationを辿るときはisinstance(op, ForOperation)のチェーンではなくHasNestedOpsを使ってください。そうすれば将来の制御フローOperationも自動的に扱えます:

def rewrite(ops):
    new_ops = []
    for op in ops:
        if hasattr(op, "nested_op_lists"):
            op = op.rebuild_nested([rewrite(child) for child in op.nested_op_lists()])
        new_ops.append(transform(op))
    return new_ops

新しいバックエンドの追加。 最低限のチェックリスト:

1. 対象SDK向けにGateEmitter[T]を実装します（TはSDKの回路型）。qamomile/qiskit/emitter.pyから始めるとよいでしょう。

2. Transpiler[T]をサブクラス化し、_create_segmentation_pass（他に必要がなければNisqSegmentationStrategyを使用）と、StandardEmitPass(your_emitter)を返す_create_emit_passを実装します。

3. ユーザーがexecutor()を呼べるようにQuantumExecutor[T]のサブクラスを実装します。

4. オプション: emitされた回路で高レベル構造を保つため、QFT/QPEなどのCompositeGateEmitterを追加します。

transpileエラーのデバッグ。 パスを1つずつ実行し、その間にsummarise(block)で件数の変化を追い、気になるところはpretty_print_block(block)で中身を覗きます。BlockKindが進まない、Operation数が爆発する、例外が送出される、というステージが最初に見るべき場所です。pretty_print_block(block, depth=N)でCallBlockOperationの展開深さを変えながらinline前後を比較すると、どこで値が切れたか・どのPhiが漏れたかが読み取りやすくなります。

9. まとめ¶

パイプラインは4つのkindを遷移していくSSAスタイルのIRです:

• HIERARCHICAL — 生のトレース、ブロック呼び出しが未展開

• AFFINE — フラットなOperationと制御フロー、ブロック呼び出しなし

• ANALYZED — 検証済み、依存グラフ化済み、セグメント化可能

• ProgramPlan → ExecutableProgram[T] — セグメント化されemit済み

各パスは限定的な仕事を持ち、BlockKindに対する事前条件を持ちます。Transpilerのステップ実行用APIはすべてのパスを公開しています。カーネルが期待通りに動かないときの主たるデバッグツールとして、またパスやバックエンドを追加するときの拡張点として活用してください。

制御フローの要点:

• if/forはトレース時にASTが書き換えられ、IfOperation / ForOperation / ForItemsOperation / WhileOperationというIRに変換される

• partial_evalはコンパイル時ifを除去するが、forのアンロールはemitのLoopAnalyzerが判定する

• analyzeは「量子Operationが測定由来の古典値に依存しないこと」を保証する

• 実行時分岐を回路まで落とせるかはバックエンドのMeasurementMode次第（NATIVEかRUNNABLEが必要）