量子ソフトウェア M&A: ハードウェアに依存しないアルゴリズムの評価

導入

量子ソフトウェアは、プログラミング言語、コンパイラー、回路最適化、エラー軽減、制御システム、シミュレーター、ワークフロー オーケストレーション、アプリケーション ライブラリ、リソース推定、ドメイン ソリューションに及びます。一部の製品は量子プロセッサの近くにあります。量子計算と古典計算を調整したり、実験を管理したり、化学、金融、最適化、機械学習のための科学的手法をパッケージ化したりする企業もいます。したがって、トランザクション境界には、コード、データ、特許、企業秘密、従業員、顧客契約、クラウド関係、ハードウェアへの将来のアクセスが含まれる可能性があります。

購入者の中心的な疑問は、ターゲットが永続的な機能を所有しているのか、それとも特定のデバイスに合わせて調整された一時的な実装を所有しているのかということです。 2 つのプラットフォームで実行される回路は、異なる精度、深さ、コスト、レイテンシを生成する可能性があります。コンパイラは、あるトポロジでゲートを削減しながら、別のトポロジでのルーティング オーバーヘッドを増やすことができます。アプリケーションは、プロバイダー独自のパルス アクセス、エラー軽減サービス、またはキューの優先順位に依存する場合があります。顧客との契約により、再現可能な製品ではなく研究に資金が提供される場合があります。

移植性が「はい」か「いいえ」の属性として扱われると、評価が難しくなります。ソフトウェアはソース レベルでは移植可能であり、パフォーマンス レベルでは依存性があります。共通の表現にコンパイルできますが、ターゲット固有の引き下げが必要です。商業上の主張を裏付ける速度、コスト、または精度を失いながら、数学的結果を再現する可能性があります。顧客との関係を優先プロバイダーに結び付けたまま、代替ハードウェアで実行できます。

このペーパーでは、ハードウェアの独立性という広範な主張を証拠の階層に置き換えます。何が移動するか、何を再構築する必要があるか、何を実行するか、誰が支払い、どの権利が移転するかが問われます。出力は、量子ソフトウェアの買収、組み合わせ、戦略的投資を評価する企業開発チーム、投資家、創設者、アドバイザー向けのトランザクション フレームワークです。

1 取得テーマを定義する

取引委員会は、所有権が必要な理由を説明する必要があります。購入者は、アルゴリズムのポートフォリオ、コンパイラまたは制御層、アプリケーション チーム、顧客アクセス、独自データ、特許、開発者コミュニティ、またはハードウェアとソフトウェアを統合するルートを求める場合があります。各論文は異なる勤勉さを必要とし、異なる評価ブリッジを生み出します。

ハードウェアの購入者は、使用率が向上し、デバイスの機能が公開され、ワー​​クロードが引き付けられるため、ソフトウェアを高く評価する場合があります。クラウドまたはプラットフォームの購入者は、抽象化、オーケストレーション、配布を重視する場合があります。産業バイヤーは、ドメインのワークフローとそれを理解している科学者を評価する可能性があります。金融投資家は、複数のハードウェア プロバイダーにわたるオプション性を重視する場合があります。委員会は、買収によって変化する収益、コスト、時間、または戦略的依存性を特定する必要があります。

論文には反事実も記載する必要があります。代替案には、ライセンス、パートナーシップ、内部構築、オープンソースの採​​用、買収、または待機などが含まれます。多くの場合、これまでの開発費よりも、交換時間と実行リスクの方が重要です。量子ハードウェアが商業的に関連性を持つようになる前に、信頼できる代替品が同じ顧客結果に達する場合、買収プレミアムを正当化するのは困難です。

ボードペーパーには、評価日、セキュリティ、対価、想定される資金および統合予算を明記する必要があります。どの値がクロージング時に存在し、どれが技術的、顧客、またはハードウェアのマイルストーンに依存するのかを特定する必要があります。この分離により、価格と保護が証拠に従うことが可能になります。

2 ハードウェアの独立性を分解する

ソースの移植性とは、コードまたは高レベルのアルゴリズムを移動または変換できることを意味します。セマンティック移植性とは、意図された数学的演算が同等のままであることを意味します。コンパイルの移植性とは、プログラムを受け入れられる中間表現とターゲット命令セットに落とし込めることを意味します。実行可能ファイルの移植性とは、完全なワークフローがサポートされている条件下でターゲット上で実行されることを意味します。

パフォーマンスの移植性により、ソリューションの品質、リソース使用量、待ち時間、スループット、コストが追加されます。商用移植性では、顧客がその出力を受け入れ、サポート モデルが存続し、経済性が存続するかどうかが問われます。これらのレイヤーは個別にテストする必要があります。前のレイヤーを通過しても、次のレイヤーは確立されません。

中間表現により、言語とコンパイラの結合を軽減できます。 Microsoft は、LLVM インフラストラクチャを共通インターフェイスとして使用し、言語やハードウェアに依存しない量子中間表現について説明しています。ターゲット環境によって、利用可能なゲート、制御フロー、測定、タイミング、およびランタイム サービスが決定されます。 Azure Quantum ターゲット プロファイルには、条件分岐、算術演算、ループのさまざまな機能が文書化されています。購入者は、価値のあるワークフローごとに必要なプロファイルをテストする必要があります。

OpenQASM 3 も同様に、量子プログラムとリアルタイムの古典的制御のための広範な言語を提供します。その仕様により、実装ではランタイム処理をハードウェアが効率的に実行できる操作に制限することができます。 Amazon Braket は、サポートされるステートメント、オペレーション、デバイス機能を文書化します。したがって、標準の存在により、実質的な実装の違いは残しながらも相互運用性が向上します。

3 アルゴリズムの証拠ラダーを構築する

最初のレベルは、問題、入力、出力、および正確さの基準が定義された数学的仕様です。 2 つ目は、再現可能な古典的なシミュレーションです。 3 番目は、名前付きターゲットのコンパイルです。 4 番目は、完全なリソースとエラーの記録を備えたハードウェアでの実行です。 5 つ目は、日付、デバイス、問題のインスタンス全体で繰り返されるパフォーマンスです。 6 番目は、顧客に受け入れられた結果です。

各レベルには凍結された証拠パッケージが必要です。これには、ソース コード、依存関係、環境ファイル、テスト ケース、データ、シード、コンパイラ設定、ターゲット識別子、キャリブレーション レコード、キュー時間、実行時間、ショット、後処理、コストおよび結果品質の尺度が含まれている必要があります。取得者は、要求された出力をクリーンな環境から再現できる必要があります。

アルゴリズムの新規性が自動的に商業的価値を生み出すわけではありません。ある方法は科学的に興味深い場合もありますが、古典的な代替方法は依然として高速、安価、またはより正確です。価値のあるアプリケーションでは、改善された意思決定、関連するベースライン、および量子または量子にインスピレーションを受けた計算が経済学を変える条件を定義する必要があります。

ラダーは、各製品で達成された最高の証拠レベルを特定する必要があります。ポートフォリオには、成熟したエラー診断ソフトウェア、実験的な最適化ルーチン、および資金のない研究が含まれる場合があります。 1 つの収益倍数を 3 つすべてに適用すると、違いが見えなくなります。評価では、達成値と条件付きオプション値を別々に割り当てる必要があります。

4 ベンチマーク品質を測定する

ベンチマークはトランザクションの質問に答える必要があります。 QED-C アプリケーション指向のベンチマークは、アルゴリズムと問題のサイズ全体で結果の忠実度、実行時間、リソース消費量を評価します。これらは、単一のハードウェア メトリックを超えて移動するため便利です。購入者は、ベンチマークがターゲットの顧客のワークロードを表しているかどうか、実装の選択肢がプラットフォームに有利であるかどうかを確認する必要があります。

ベンチマーク計画には、ホールドアウト インスタンス、従来のベースライン、および複数のターゲット構成を含める必要があります。コンパイル時間、回路の幅と深さ、2量子ビット操作、ショット、キュー時間、実行時間、従来の後処理、再試行、総コストを記録する必要があります。ソリューションの品質は、結果が判明する前に定義する必要があります。

ハードウェアとコンパイラのバージョンは重要です。ターゲット独自のアルゴリズムではなく、キャリブレーション、トランスパイル、またはエラー軽減によって結果が改善される可能性があります。購入者は、同じスタックを通じてベースライン実装を再実行し、アブレーションによるターゲットの寄与をテストする必要があります。アクセスと構成を制御した後も改善が持続する場合、独自の値がサポートされます。

ベンチマークガバナンスは、選択的な報告を防止する必要があります。試行されたすべてのインスタンス、除外、および失敗した実行は保持される必要があります。デリジェンス チームは、パラメータの調整と、顧客の導入に同様の専門家の介入が必要かどうかを理解する必要があります。創業者主導の手動チューニングに依存する結果は、スケーラブルなソフトウェア製品ではなく、サービスや人材の価値を表す可能性があります。

5 マップコンパイラと中間表現の依存性

量子コンパイルには、分解、マッピング、ルーティング、スケジューリング、最適化、パルス低減、およびランタイム統合が含まれます。アプリケーションは、価値を移動するパフォーマンスがサードパーティのパスまたはプロバイダー サービスにある一方で、高レベルのライブラリを呼び出すことがあります。バイヤーは、ソースから実行されたジョブまでの各変換を追跡する必要があります。

依存関係グラフでは、言語、ライブラリ、中間表現、コンパイラ、プラグイン、ターゲット バックエンド、シミュレータ、クラウド API、および従来のサービスを識別する必要があります。コンポーネントごとに、所有権、ライセンス、バージョン、メンテナンス、交換作業、および運用の重要性を記録する必要があります。オープンソースの可用性により、ガバナンスと互換性の義務が生じる一方で、買収リスクがある程度軽減されます。

コンパイラのパフォーマンスはターゲットごとにテストする必要があります。 1 つの接続グラフの深さを減らすパスは、他の場所では限定的な利点しか得られない可能性があります。ダイナミック回路、中間回路測定、リセット、パルスアクセス、およびエラー軽減機能により、利用可能なアルゴリズムが変更される場合があります。 QIR ターゲット プロファイルとプロバイダーのドキュメントは、ターゲットの実際の要件と一致している必要があります。

取得者は、創設者の資格情報、ローカル ファイル、または非公開のサービスを含まないクリーン ビルドを再現する必要があります。中間アーティファクトを再生成し、合意されたベンチマークを実行する必要があります。ビルドの再現性が移植性をサポートします。それ自体では、運営、規模、顧客価値の自由を確立するものではありません。

6 ハードウェア モダリティ間での移植性のテスト

ハードウェアのモダリティは、接続性、ネイティブ操作、測定、リセット、コヒーレンス、ゲート期間、制御、キューの経済性において異なります。超伝導、トラップイオン、中性原子、フォトニックおよびアニーリングシステムでは、異なる配合やコンパイルの選択が必要になる場合があります。移植性を主張するには、サポートされる問題のクラスとターゲットを指定する必要があります。

テスト マトリックスには、少なくとも 1 つの主要ターゲット、1 つの信頼できる代替ターゲット、および 1 つのシミュレータまたはエミュレータを含める必要があります。同じワークロードでは、定義された入力データと受け入れ基準を使用する必要があります。ソリューションの品質、深さ、実行時間、再試行、コストの違いを測定する必要があります。ターゲットごとにアルゴリズムが大幅に変更される場合、購入者は各実装を個別の保守製品として扱う必要があります。

プロバイダー アクセスは隠れた資産になる可能性があります。優先キュー、予約容量、校正情報、エンジニアリング サポート、および非公開機能により、通常の顧客が再現できない結果がサポートされる場合があります。契約は、譲渡、管理の変更、価格設定、データ、継続性についてレビューされる必要があります。評価では、ソフトウェアを特権アクセスから分離する必要があります。

移植性も差別化を弱める可能性があります。標準的な表現によって競合他社が同等のアルゴリズムを簡単に移行できる場合、データ、最適化、ワークフローの統合、または顧客関係に堀が残る可能性があります。ディリジェンスレポートには、プログラムがオープンインターフェイスを介して表現された後もどの層が独自仕様のままであるかを記載する必要があります。

7 勤勉な知的財産とオープンソース

購入者は、特許、著作権、企業秘密、データ権利、ライセンス、および貢献者契約を各製品にマッピングする必要があります。ソース リポジトリには、作成者、コミット履歴、サードパーティのコンポーネントとリリースが表示される必要があります。従業員と請負業者の割り当てが完了している必要があります。大学または政府の資金提供を受けた研究には、追加の権利と義務が伴う場合があります。

オープンソース ソフトウェアは導入を加速し、開発者コミュニティを構築できます。また、競合他社がコア機能を使用できるようになる可能性もあります。購入者は、どのリポジトリが公開されているか、どのコンポーネントが独占的なままであるか、ライセンスの変更が法的および商業的に現実的かどうかを理解する必要があります。コピーレフト、帰属、通知、特許および再配布の義務は、資格のある弁護士によって検討される必要があります。

トレーニング データ、分子データ、顧客データセット、ベンチマーク コーパスが重要となる場合があります。ターゲットは、出所、同意、契約上の使用権、保持および譲渡の権利を証明する必要があります。特定のプロジェクト用に取得したデータは、取得後に再利用できない場合があります。合成データまたは公開データは置き換え可能である可能性があり、サポートされていない希少価値を受け取るべきではありません。

営業秘密には運用管理が必要です。購入者は、アクセス、文書化、暗号化、オフボーディング、知識の集中を検討する必要があります。一人の研究者だけが知っている方法は、保持と移転のリスクを考慮して評価されるべきです。特許は数えるのではなく、実際の製品にマッピングする必要があります。

8 研究資金から製品収益を分離する

量子ソフトウェアの収益には、サブスクリプション、ライセンス、プロフェッショナル サービス、政府の賞、研究協力、マイルストーンの支払い、クラウドの使用などが含まれます。これらのカテゴリには、異なる再現性と粗利益があります。買い手は、顧客および製品ごとに契約、請求書、受領および現金を調整する必要があります。

経常収益には、継続的な義務と信頼できる更新基準が必要です。複数年の研究契約では、オーダーメイドの研究に資金を提供しながら、契約上の現金も提供される場合があります。パイロットでは、製品と市場の適合性を証明しなくても、予算とエンゲージメントを実証することができます。助成金は、制限や限られた商業的再発を伴う一方で、価値ある開発に資金を提供できます。

顧客コホートは、開設収益、更新、拡大、縮小、解約、サービス、繰延収益、および現金回収を示す必要があります。ハードウェアプロバイダー、ワークロード、製品バージョン、専門家によるサポートを特定する必要があります。初期の顧客は戦略的パートナーであるため、集中度が高くなる可能性があります。購入者は、これらの関係が制御またはハードウェア戦略の変更後も存続するかどうかをテストする必要があります。

収益予測では、ハードウェアの可用性が広がれば自動的に需要が生まれると想定すべきではありません。モデルは、各顧客セグメントを定義された機能、導入イベント、販売コストにリンクする必要があります。裏付けのない市場予測は、達成価値ブリッジの外側に留まるべきです。

9 勤勉な顧客の成果

顧客リファレンスでは、決定事項と受け入れられた結果に焦点を当てる必要があります。購入者は、どのような問題に対処したか、どのような従来のベースラインが存在したか、どの目標が使用されたか、結果がどのように検証されたか、どのようなリソースが消費されたか、顧客が運用上の決定を変更したかどうかを尋ねる必要があります。公開されたコラボレーションは、繰り返しの経済的価値を確立しなくても、戦略的に意味のあるものになる可能性があります。

受け入れ基準は、可能な限り契約上のものである必要があります。化学ソフトウェアは、予測精度と実験的検証によって判断される場合があります。最適化は、客観的な値、実現可能性、実行時間、再現性によって判断できます。エラー診断は、測定された削減または検証品質によって判断できます。指標は顧客の用途に一致する必要があります。

移植性は商業的にテストされる必要があります。元のプロバイダーが利用できない場合、またはターゲットが競合ハードウェア会社に買収された場合、顧客は継続できますか?購入者は、終了、独占性、データ、出力の所有権、監査およびサポートの義務を検討する必要があります。

最も強力な証拠は、安定した配信の経済性を伴って有料で繰り返し利用できることです。最も弱いのは、署名のない関心の表明です。評価では、すべてのロゴをパイプライン値に入れるのではなく、顧客証拠ラダーを使用する必要があります。

10 才能と科学的ノウハウを大切にする

量子ソフトウェア チームは、理論物理学者、応用数学者、コンパイラ エンジニア、ドメイン サイエンティスト、ソフトウェア エンジニア、製品リーダー、顧客科学者を組み合わせる場合があります。購入者は、各重要な機能を製品とマイルストーンにマッピングする必要があります。組織の肩書きだけでは、技術的な依存関係は明らかではありません。

ターゲットは、アルゴリズムの設計、顧客の信頼性、手動調整を創設者に依存している可能性があります。主要なエンジニアはコンパイラまたは展開システムを所有している場合があります。ドメインサイエンティストは、顧客の問題を解決可能な定式化に変換する場合があります。デリジェンス チームは、文書化されていない知識と現実的な交換時期を特定する必要があります。

保持率は、取引終了後の作業を反映する必要があります。サービスベースの特典は継続性をサポートします。マイルストーン賞では、再現可能な出力と顧客に受け入れられた結果を使用する必要があります。報酬は、ベンチマークの選択やサポートされていないパフォーマンスの主張に報酬を与えることを避けるべきです。

統合では、科学的な挑戦とソフトウェア配信の規律を維持する必要があります。購入者は、リポジトリ アクセス、リリース ガバナンス、セキュリティ、アーキテクチャ権限、および製品所有権を定義する必要があります。ハードウェアの買収者は、移植性と顧客価値をテストする前に、すべてのアプリケーションを独自のプラットフォームに強制的に導入することを避けるべきです。

11 サイバーセキュリティとソフトウェアサプライチェーンのリスクを評価する

量子ソフトウェア製品は、従来のソフトウェアのリスクを継承します。購入者は、ID、特権アクセス、シークレット、依存関係、パイプラインの構築、パッケージ署名、脆弱性管理、ロギング、インシデント対応およびリカバリを確認する必要があります。クラウド トークンとハードウェア認証情報には特別な制御が必要です。

ソフトウェアの部品表では、パッケージ、バージョン、ライセンス、既知の脆弱性を特定する必要があります。再現可能なビルドと保護されたリリース パイプラインにより、取得した製品が再構築できない、または信頼できないというリスクが軽減されます。購入者は、バックアップの復元と、クロージング時にすべての認証情報をローテーションする機能をテストする必要があります。

顧客データと実験データは機密性が高い場合があります。契約書とアーキテクチャでは、入力、回路、校正データ、出力がどこに保存されるかを示す必要があります。国境を越えた処理、輸出規制、および分野の要件は統合に影響を与える可能性があります。セキュリティ表現は、ログとインシデントに対してテストする必要があります。

修復コストは評価および統合計画に含まれます。ソフトウェア制御が弱い貴重なアルゴリズムは、規制対象の顧客に導入する前に、リポジトリ、クラウド、および ID の作業が必要になる場合があります。その支出は一般的な相乗効果の中に隠れてはなりません。

12 機種変更コストと回避時間

交換コストは、移行可能な機能を再現するために必要なチーム、データ、実験、ソフトウェア、および経過時間を見積もる必要があります。過去の支出は証拠ですが、失敗したパスや埋没コストも含まれます。購入者は、信頼できる代替品を短期間で提供できる現在のシステム、文書、および学習を評価する必要があります。

モデルはコード量と難易度を区別する必要があります。小さなコンパイラ パスで、まれな専門知識をエンコードできます。大規模なアプリケーション リポジトリには、置き換え可能な統合コードを含めることができます。専門家へのインタビュー、リポジトリの履歴、ベンチマークの再現は、ボトルネックの特定に役立ちます。

ハードウェアまたは産業ロードマップに固定枠がある場合、回避された時間は貴重になる可能性があります。取得者は、購入と統合にかかる時間を社内ビルドと比較する必要があります。主要な権利、顧客、スタッフが譲渡できない場合、利益は減額されるべきです。

オープンスタンダードとオープンソースフレームワークにより、交換コストを削減できます。また、市場を拡大し、補完的な独自レイヤーの価値を高めることもできます。評価では、相互運用性が向上するにつれてターゲットの堀が強化されるか弱まるかを特定する必要があります。

13 収入モデルを構築する

収入モデルでは、遠い量子市場予測ではなく、顧客の証拠を使用する必要があります。収益は、製品、サービス、補助金、その他のソースごとに分割する必要があります。粗利益には、クラウド実行、ハードウェア アクセス、専門家による提供、サポート、サードパーティ ライセンスが含まれる必要があります。研究者の給与と製品開発は可視化されたままでなければなりません。

予測ではコンバージョン イベントをモデル化する必要があります。パイロットは、受け入れ、調達、予算が満たされた場合に転換します。サブスクリプションは、製品がハードウェアやバージョンを問わず引き続き有用である場合に更新されます。サービス プロジェクトは、オーダーメイドの労力が少なく、納品が再現可能である場合にのみ製品収益となります。

モデルにはハードウェアの依存関係を含める必要があります。貴重なワークフローが 2 年以内に予想されるプロバイダーの能力を必要とする場合、収益は確率に重み付けされ、慎重に資産計上される必要があります。ターゲットが診断やシミュレーションから今日収益を得ている場合、その達成されたキャッシュ フローは従来の分析をサポートできます。

最終価値はテクノロジーの変化と競争を反映する必要があります。顧客コホートによってサポートされない長い成長期間は、誤った精度を生み出します。取引委員会は、収益アプローチを再調達コストおよびシナリオ価値と比較する必要があります。

14 移植性を調整したスコアカードを使用する

スコアカードには、アルゴリズムの証拠、移植性、ベンチマークの品質、知的財産、データ、顧客の成果、収益の質、チーム、セキュリティ、ランウェイが含まれている必要があります。各スコアは証拠と評価の意味にリンクしている必要があります。科学的スコアが高くても、所有権の欠如や顧客の受け入れの弱さを修復することはできません。

移植性は、ソース、セマンティクス、コンパイル、実行、パフォーマンス、商業的継続性に関して個別のサブスコアを受け取る必要があります。買い手は、買収理論で要求される最低レベルを特定する必要があります。ハードウェア購入者は、プラットフォームを強化する依存を受け入れる可能性があります。中立的なクラウド購入者は、広範なパフォーマンスの移植性を必要とする場合があります。

スコアカードは集中力を示す必要があります。 1 つのプロバイダー、科学者、または顧客に依存している場合、ターゲットは高い平均点を獲得する可能性があります。したがって、ゲートの失敗は加重スコアとは別に報告する必要があります。理事会はどの問題が論文を無効にする可能性があるかを知っている必要があります。

確認テストの後はスコアが変わるはずです。モデルは、各更新の証拠と理論的根拠を保存する必要があります。これにより、価格交渉と取引完了後の説明責任がサポートされます。

15 開示された組み合わせから学ぶ

Quantinuum の設立により、Honeywell Quantum Solutions と Cambridge Quantum が統合されました。公表では、ハードウェアとソフトウェアの統合会社と長期的な製造サポートについて説明されていました。この組み合わせは、ハードウェアのロードマップを制御しながらプラットフォーム全体でソフトウェアを開発できる機能など、垂直統合の理論を示しています。

キーサイトによるQuantum Benchmarkの買収により、より広範な量子ポートフォリオにエラー診断、エラー抑制、およびパフォーマンス検証ソフトウェアが追加されました。開示された理論的根拠は、ハードウェアを測定および改善するソフトウェアの価値を示しています。スタンドアロンのアルゴリズムの評価は開示されていません。

量子マシンは、量子制御機能をゲートレベルから量子ビットまで拡張するために QDevil を買収しました。 SandboxAQ は計算化学技術、顧客、人材を追加するために Good Chemistry を買収しました。これらのトランザクションは、制御スタックとドメイン アプリケーションのテーマを示しています。

これらの例は、価格、収益、権利、証拠の調整を行わずに直接比較できるものとして扱われるべきではありません。これらは、垂直統合、検証、制御、ドメイン ワークフロー、人材、顧客アクセスなどの戦略的価値ルートを特定するのに役立ちます。ターゲットは、その証拠によってサポートされるルートにマッピングされる必要があります。

16 仮説の評価を構築する

この実際の例では、完全に仮想的な量子ソフトウェア ターゲットを使用しています。年間収益の USD 18 million を報告します: USD 11 million 経常製品収益、USD 4 million サービス、USD 3 million 助成金およびその他の収益。無制限の現金使用量の USD 96 million と年間現金使用量の USD 38 million があります。これらの金額は、観察された企業を表すものではありません。

中心的な企業価値は USD 420 million です。 USD 105 million は検証済みのアルゴリズムとアプリケーション、USD 90 million はコンパイラーとオーケストレーション資産、USD 60 million は顧客関係と契約、USD 45 million は独自のデータとワークフロー、USD 70 million はチームとノウハウ、USD 50 million はロードマップ オプションに割り当てられます。各値は管理上の仮定です。

4 つのシナリオで移植性をテストします。主要アルゴリズムが 1 つのプロバイダーに関連付けられたままである制約付きケースの値は USD 140 million で、確率は 25% です。ソースは移植可能だがパフォーマンスが変動するケースの値は USD 360 million で、確率は 40% です。リピート顧客を持つパフォーマンスポータブル製品の価値は USD 820 million で、確率は 27% です。広範なハードウェア アクセスを持つカテゴリ プラットフォームの値は USD 1.80 billion で、確率は 8% です。例示的な確率加重値は、統合、資金調達および希薄化前の USD 508.4 million です。

中央割り当て値と確率加重シナリオ値の違いにより、仮定が明らかになります。購入者は、統合コスト、保持、顧客の同意、ハードウェア契約、資金を調整する必要があります。条件付きの考慮事項により、支払いとポータビリティ テストおよび顧客維持を調整できます。

17 証拠に関する構造の考慮

事前の支払いにより、制御されたコード、権利、キャッシュ フロー、および譲渡可能な機能を支払うことができます。後払いは、クリーン ビルド、継続的なマルチターゲット ベンチマーク、顧客維持、または承認された製品リリースに依存します。維持賞は、サービスと知識の伝達に報いる必要があります。

マイルストーンでは、ターゲット、バージョン、ワークロード、ベースライン、指標、および独立したレビューを指定する必要があります。ソフトウェアがハードウェアに依存しないという一般的な要件は、論争を引き起こします。より良いマイルストーンには、ソリューションの品質、時間、コストのしきい値を満たしながら、定義されたワークロードが合意された目標に基づいてコンパイルおよび実行されることが記載されています。

契約は技術的な変更に対応する必要があります。新しいハードウェアが元のターゲットを置き換える可能性があります。代替ルールは経済的同等性を維持し、どちらの当事者も人為的に簡単なテストや不可能なテストを選択することを防ぐ必要があります。資格のあるアドバイザーは、会計、税務、雇用、証券の影響に対処する必要があります。

購入者はデータと顧客の継続性も保護する必要があります。同意、移行サービス、クラウド アクセス、セキュリティ修復は、締結条件または誓約となる場合があります。エスクローは、特定された権利のギャップに対処できます。それぞれの保護は、価値を動かすリスクに対応する必要があります。

18 最初の100日間を計画する

最初の 30 日間は、リポジトリ、認証情報、クラウド アカウント、顧客データを保護し、パイプラインをリリースする必要があります。買い手は重要なスタッフを確認し、証拠ベースラインを凍結し、プロバイダーへのアクセスを維持する必要があります。顧客とのコミュニケーションでは、サポートされていないパフォーマンスを約束することなく、継続性を説明する必要があります。

30 日から 60 日以内に、ビルドを再現し、主要なベンチマークを再実行し、製品アーキテクチャをマッピングし、顧客の義務を検証します。統合チームは、共有サービスを保護された科学的研究から分離する必要があります。統合されたロードマップでは、どのプラットフォームがサポートされ続けるのか、そしてその理由が特定される必要があります。

60 ～ 100 日では、重複するツールを合理化し、製品とハードウェア マトリックスを承認し、セキュリティを修復し、知識の伝達をテストする必要があります。商業リーダーは、価格設定、サポート、更新プランを検討する必要があります。財務部門は、統合支出とマイルストーンの進捗状況を投資ケースと調整する必要があります。

取締役会は価値実現報告書を受け取る必要があります。達成された相乗効果、顧客の維持、ポータビリティの証拠、現金の使用、リスク、次の意思決定を示す必要があります。技術的な学習は、活動としてのみ報告されるのではなく、評価の前提を更新する必要があります。

結論

量子ソフトウェアの価値は、ハードウェアに依存しないラベルによって確立されるものではありません。それは、アルゴリズム、コンパイラー、ワークフロー、顧客の成果が実行環境の変化にどの程度耐えられるかによって決まります。ソースの翻訳、コンパイルの成功、および同等の商業的パフォーマンスは、証拠の状態が異なります。

買収者は、アルゴリズムの証拠ラダー、依存関係グラフ、移植性マトリックス、ベンチマーク計画、および顧客コホートを構築する必要があります。ビルドを再現し、プロバイダーの機能を制御し、品質と解決までの時間を測定し、権利を確認し、顧客の現金を照合する必要があります。達成された資産は、条件付きロードマップの値から分離する必要があります。

オープンな表現と標準は、ターゲット固有の機能制限を明らかにしながら、スイッチング コストを削減できます。戦略的な組み合わせは、ソフトウェアが垂直統合、診断、制御、およびドメイン アプリケーションを通じて価値を生み出すことができることを示しています。特定のターゲットの値には、依然としてトランザクション固有の証拠が必要です。

取締役会はこのフレームワークを使用して、買収、投資、ライセンス、提携、構築のいずれを行うかを決定できます。すべての重要な価値の構成要素は、管理された権利、再現可能なパフォーマンス、顧客に受け入れられた成果、または明示的に述べられた管理上の前提を示す必要があります。その証拠が変化した場合には、検討が移るはずです。

付録 A 移植性テストプロトコル

プロトコルは、ソース、依存関係、コンパイラのバージョン、ターゲット プロファイル、データ、シード、および受け入れ基準を凍結する必要があります。これには、主要なターゲット、信頼できる代替手段、およびシミュレータまたはエミュレータが含まれている必要があります。ターゲットは、文書化された認証情報とインフラストラクチャを使用して、クリーンな環境から構築する必要があります。

各実行では、コンパイル時間、回路の幅と深さ、ネイティブ操作、ショット、キューと実行時間、従来の後処理、再試行、総コスト、およびソリューションの品質を記録する必要があります。除外と失敗した実行は記録に残る必要があります。ベースライン実装では、同じアクセスと構成を使用する必要があります。

レポートでは、ソース、セマンティック、コンパイル、実行、パフォーマンス、商用移植性を分類する必要があります。どの変更が必要であったか、またそれらの変更が保守された製品ブランチを構成するかどうかを記載する必要があります。独立した査読者は、結論を再現するのに十分なアクセス権を持っている必要があります。

付録 B 顧客と収益の証拠

顧客のスケジュールでは、法的取引相手、製品、ワークロード、ハードウェアプロバイダー、期間、コミットメントバリュー、サービス、受領、請求、現金、更新および管理の変更を特定する必要があります。研究資金や補助金は、経常的な製品収益から切り離される必要があります。

コホート分析では、開始時の経常収益、新規顧客、拡大、縮小、解約、および成約時の経常収益を示す必要があります。会計記録と照合する必要があります。パイプラインは契約収益の範囲外に留まるべきであり、調達、技術、予算のゲートを特定する必要があります。

顧客のリファレンスは、サポートされる決定、ベースライン、受け入れられた出力、専門家の取り組み、および将来の意図を確認する必要があります。購入者は、ハードウェアまたは所有権が変更されても関係が存続するかどうかをテストする必要があります。

付録 C 評価データ室

技術データ室には、リポジトリ、ビルド手順、依存関係ロック、ソフトウェア部品表、ライセンス、寄稿者契約、特許、データ権利、ベンチマーク、生の実行記録、ターゲット構成、セキュリティ記録、およびインシデント履歴が含まれている必要があります。否定的な実験や失敗した実験も含める必要があります。

商業記録には、契約書、作業明細書、助成金、請求書、現金受領書、サポートログ、使用状況が含まれる必要があります。財務記録では、収益カテゴリ、粗利益、研究支出、現金、コミットメント、および毎月の現金使用を調整する必要があります。

ディリジェンスレポートでは、何が複製、サンプリングされたか、入手不可能か、または議論されているかを特定する必要があります。それぞれの未解決のギャップは、価格、構造、統合予算、または承認条件に現れるはずです。

付録D 積算値台帳

統合価値台帳では、収益、コスト、資本、および戦略的効果を区別する必要があります。収益効果には、顧客維持、クロスセル、新しいプラットフォームへのアクセス、パイロットからのより迅速なコンバージョンなどが含まれます。コスト効果には、重複したインフラストラクチャの削除、調達レバレッジ、外部ライセンス支出の削減などが含まれます。資本効果には、社内開発の回避や次の製品リリースまでの時間の短縮などが含まれます。戦略的効果には、重要なコンパイラ、ワークフロー、データ資産、または顧客インターフェイスの制御が含まれます。

各アイテムには、ベースライン、責任ある所有者、タイミング、必要な支出、および証拠ソースが必要です。総シナジーの見積もりは、顧客の減少、製品の中断、維持賞与、クラウド移行、セキュリティ修復、プラットフォームのサポートの重複、および税金を考慮して削減する必要があります。将来のハードウェアに依存する利点は確率で重み付けされ、短期的なアクションとは別に表示される必要があります。

台帳は二重計算を防止する必要があります。アルゴリズムの移植性は顧客維持をサポートし、再構築コストを削減できますが、調整がなければ両方のラインで同じ利点が得られるはずはありません。買い手はまた、別の事業部門から移転された価値と、統合されたグループのために生み出された価値を区別する必要があります。クラウドやエンジニアリングのコストを中央予算に組み込むこと自体は、企業価値を生み出しません。

クローズ後のレポートでは、実現された価値と承認されたケースを比較する必要があります。技術的な指標は商業的な成果につながる必要があります。マルチターゲット ベンチマークが成功しても、サポート コストの削減、顧客の維持、配布の拡大、または製品のロック解除が行われるまで、取引価値は制限されます。顧客の更新が売上、ハードウェアの進歩、または価格にも依存する場合は、慎重に判断する必要があります。

取締役会は、定義された間隔で元帳をレビューし、証拠が変化した場合には投資事例を修正する必要があります。未達成の価値は、製品、資本、または統合の決定を引き起こす必要があります。その目的は、買収理論、技術的証拠、現金、および責任ある執行の間の追跡可能な関係を維持することです。

付録 E 決定の図と表

提案された階層。各層には独自の証拠が必要です。

提案されたトランザクション ディリジェンス シーケンス。

ソフトウェア実行チェーンの最小限のレビューを提案。

完全に仮想的な管理上の仮定。企業データや取引データは観察されていません。

収益評価のための分類案。

完全に仮想的な管理上の仮定。 USD百万。

提案された意思決定枠組み。

情報源

1. 量子経済開発コンソーシアム、量子コンピューティングのアプリケーション指向のパフォーマンス ベンチマーク。 一次ソースを読む
2. 量子経済開発コンソーシアム、アプリケーション指向のパフォーマンス ベンチマークを使用した量子アルゴリズムの探索、2024 年。 一次ソースを読む
3. 量子経済開発コンソーシアム、標準およびパフォーマンス メトリクス技術諮問委員会。 一次ソースを読む
4. Microsoft Azure Quantum、量子中間表現。 一次ソースを読む
5. Microsoft Azure Quantum、Quantum Development Kit の QIR ターゲット プロファイル、2026。 一次ソースを読む
6. Microsoft Azure Quantum、量子プロバイダーのバックエンド量子シミュレーター、2026 年。 一次ソースを読む
7. OpenQASM、OpenQASM 3 ライブ仕様。 一次ソースを読む
8. クロスおよびコラボレーター、OpenQASM 3: より広範でより深い量子アセンブリ言語、量子コンピューティングに関する ACM トランザクション、2022 年。 一次ソースを読む
9. アマゾン ウェブ サービス、さまざまな Amazon Braket デバイスでの OpenQASM のサポート。 一次ソースを読む
10. アマゾン ウェブ サービス、Amazon Braket によってサポートされる OpenQASM 機能。 一次ソースを読む
11. IBM Quantum、Qiskit トランスパイラーのドキュメント。 一次ソースを読む
12. IBM Quantum、バックエンド、ターゲットのドキュメント。 一次ソースを読む
13. Google Quantum AI、Cirq ドキュメント。 一次ソースを読む
14. NVIDIA、CUDA-Q のドキュメント。 一次ソースを読む
15. NVIDIA、cuQuantum SDK ドキュメント、2026。 一次ソースを読む
16. ザナドゥ、ペニーレーンのドキュメント。 一次ソースを読む
17. Linux財団、QIRアライアンス。 一次ソースを読む
18. 米国国立標準技術研究所、量子情報科学。 一次ソースを読む
19. ISO、ISO/IEC 4879:2024 量子テクノロジー。語彙。 一次ソースを読む
20. ハネウェル、ハネウェル クアンタム ソリューションズ、ケンブリッジ クアンタムの事業統合が完了、2021 年。 一次ソースを読む
21. Quantinuum、Quantinuum の紹介、2021 年。 一次ソースを読む
22. Quantinuum、米国証券取引委員会に提出された登録届出書、2026 年。 一次ソースを読む
23. キーサイト・テクノロジーズ、キーサイト・テクノロジーズがQuantum Benchmarkを買収、2021年。 一次ソースを読む
24. 量子マシン、量子マシンが QDevil を買収、2022 年。 一次ソースを読む
25. SandboxAQ、SandboxAQ が Good Chemistry を買収、2024 年。 一次ソースを読む
26. IFRS財団、IFRS第3号企業結合。 一次ソースを読む
27. IFRS財団、IFRS第13号公正価値測定。 一次ソースを読む
28. IFRS財団、IAS第38号無形資産。 一次ソースを読む
29. 国際評価基準評議会、国際評価基準。 一次ソースを読む
30. 米国証券取引委員会、財務報告マニュアル。 一次ソースを読む
31. 米国国立標準技術研究所、安全なソフトウェア開発フレームワーク SP 800-218. 一次ソースを読む
32. 米国国立標準技術研究所、サイバーセキュリティ フレームワーク 2.0。 一次ソースを読む