未踏ターゲット事業成果報告会の参加メモ(2018年度+2019年度、1日目)
- はじめに
- RISC-V量子拡張の参照実装とマイクロ波制御量子ファームウェアの開発
- 量子敵対的生成ネットワークを用いた画像生成プログラムの開発
- 量子情報技術による分散型通貨決済システムの開発
- 時間依存密度行列繰り込み群法による量子アニーリングシミュレータの開発
- アニーリングマシンによるゲノム配列解析基盤の構築
- アニーリングマシンを用いた最適航路選択アプリケーションの開発
- 量子多体系の実時間発展シミュレーションプログラムの開発
- web開発向けオープンソース量子計算ライブラリの開発
- 量子コンピュータによる公平な抽選システムの開発
- 分散量子計算プラットフォーム
- 量子性を活かしたゲームの開発
- FPGAによる量子コンピュータシミュレーションシステムの開発
- おわりに
はじめに
2018年度、2019年度未踏ターゲット事業の成果報告会が2020/2/8~9に開催されました。(https://www.ipa.go.jp/jinzai/target/2019/seikahoukoku1st.html) 未踏ターゲット事業で初の公開イベントだそうです。
一般参加は40名程度で、あえなく漏れてしまった方もいますので、1日目(2/8)の参加メモを公開したいと思います。
私自身が不勉強なためほとんど理解できていませんので、このメモには多くの誤りが含まれていると思いますが、雰囲気だけ伝わればと思います。(YouTubeで動画公開されるという話もチラホラ聞こえてましたが)
RISC-V量子拡張の参照実装とマイクロ波制御量子ファームウェアの開発
- 山崎 清仁、新里 祐教、今村 謙之 / 担当PM:徳永 裕己
- メンバ:マイクロ波を扱うプロ(今村氏)、フルスタックエンジニア(新里氏)、OpenQL Project発足者 兼 運営(山崎氏)で構成
- オープンソースのプロとしての挑戦
- 課題:量子計算では高級言語がほとんど存在しない
- 取組:古典計算機の技術(RISC-V)を拡張し、量子計算機の開発環境を作る
- 公開情報
- https://quantum.siprop.org/
- OpenQLコミュニティ( https://openql.slack.com/ )
- ソースはGithubで、今はプライベートだが公開したい
- 実行できる規模は?
- (CUDAのように)QPUをAPIで直接叩かせず、敢えてCPU経由でアクセスする設計としたメリット・デメリットは?
- 1つの提案(参照実装)としているが、メリット・デメリットは正直まだ分からない
- 機械語はハードの違いを吸収できないといけないと思うが、どういう実装か?
- 高級言語って具体的にどう楽になるの?
量子敵対的生成ネットワークを用いた画像生成プログラムの開発
- 中井 慎、宮下 繁虎、種谷 望 / 担当PM:徳永 裕己
- メンバ:3人とも慶応大B2
- 敵対的生成ネットワーク(GAN)
- 新たなデータを生成する機械学習モデル
- 目的:GANによる画像の生成とWebアプリによる公開
- 意義:QCで画像を生成できる事を示す?
- 成果:Quantum Wasserstein GANを用いた4x4の正方白黒画像の生成
- 256階調のグレースケールを|0>→|1>へのπ回転(確率振幅)にエンコード
- Quantum Wasserstein GANは判別部でWasserstein距離を計算、生成部にフィードバック、Wasserstein距離が0になる事を目指して学習
- 今後の展望
- Webアプリの公開(デザイン、説明文)
- Quantum GANでたような出力を可能にする方法の模索
- 今回はデータ圧縮できる手法だが、複数画像から生成できる事が保証されていない
- リソース、計算時間共に古典より優位?
- リソースは削減できるが、計算時間は逆に遅くなる(pixel数分のゲート操作)
- 例えばハッシュ化すると速くなる
- カラー画像はできる?
- RGBだと元のデータが3倍になるが、今の実機で検証しようとすると難しい
- デコードはどうなるか?
- 座標と色のエンコードになっている
- 確率振幅に乗せているので測定を増やした方が精度が良くなる、今回10万shotくらいやった
- GANなの?むしろオートエンコーダーでは?
- 今回は1枚の画像から似た画像を生成するという実装だったが、複数の古典データからうまく画像生成できるかは検証する必要がある
量子情報技術による分散型通貨決済システムの開発
- 桝本 尚之 / 担当PM:徳永 裕己
- 課題:現在の仮想通貨は空間的計算量(すべての履歴)、時間的計算量が大きすぎる
- 取組:量子マネー(quantum lightning)の分散型決済プロトコルを開発し、両替時以外の計算量を落とした
- 量子マネーとは?
- 量子状態そのものを通過として利用するアイディア
- 任意の未知の量子状態は複製不可能である事(ノークローニング定理)を利用する
- 通貨のシリアル番号を量子状態にする
- quantum lightningでは、鋳造者ですら同じシリアル番号の量子状態を作れない
- 分散環境とは?
- 信頼できる中央銀行が存在しない環境
- 前提:
- 提案
- quantum lightningを分散化する
- 価値の移転(両替を伴わない送金)は量子状態を送るだけ(ブロックチェーンは使わない)
- 両替時のみブロックチェーン(分散台帳)を使う
- 両替時は台帳から元のシリアルを削除して、崩した2つのシリアルを登録する
- 手数料は取る
- 公開鍵暗号は使っていない
- 参加者のインセンティブは?(両替に関係しない人も全員台帳を更新する)
- 基本的にビットコインと同じ考え方
- 両替要求の検証時に、最も早く成功した人は量子マネー(手数料と、nonceに当たる価値)をもらえる
- 取引の確定にはどれくらい時間かかる?ビットコインは10分くらいだけど
- 両替する場合は変わらない(設計次第)、両替しない場合は瞬時に完了する
時間依存密度行列繰り込み群法による量子アニーリングシミュレータの開発
- 柚木 清司、曽田 繁利 / 担当PM:田中 宗
- 理研
- 量子アニーリングシミュレータQUARTZについて
- 目的:量子計算機の研究者やハードウェア開発者に有用なツールを開発
- 量子多体系と密度行列繰り込み群法
- 量子アニーリングは基底状態をトレースする
- →密度行列繰り込み群法を使うには理にかなっている
- 密度行列繰り込み群法、動的~、時間依存~、モンテカルロ法を使う
- 量子ゲートのシミュレーションにも有効な波及効果
- 方針:密度行列繰り込み群法を扱ったことがない利用者に向けた簡便な入力
- 時間発展のパラメータ
- 方法①:全体の時間と時間ステップ
- 方法②:始状態と終状態を与える
- 方法③:各自国の時間依存性を与える
- 量子アニーリングの基礎研究と応用研究も
- 4体まではそのまま扱える
- 縮退しているハミルトニアンだと確率が期待した分布にならない
- 密度行列繰り込み群法は弱いというか、外側でうまく考える必要があると思う
- いつ頃使える?
- マニュアルを作成している段階
- バイナリは公開、ソースも要望に応じて提供予定
アニーリングマシンによるゲノム配列解析基盤の構築
- 松本 悠希、中村 昇太 / 担当PM:田中 宗
- ゲノム配列解析は、DNA、RNA、たんぱく質を扱う
- マルチプルアラインメント
- 配列をきれいに並べて比較可能にする事(NP困難)
- ギャップを挿入して、最大一致するところを探す
- ゲノムアセンブリ
- 得られる配列は断片的な並びで、うまくオーバーラップさせながら繋ぎ合わせて元の配列にする
- 10^7くらいのサイズまでは既存コンピュータでも解けるが、それ以上(高等生物や種によって植物も)は解けない
- ruddiiゲノム(157kb)はアセンブリできた
- coliゲノム(4.64Mb)のアセンブリは...
- コードや方法論は2020年中にウェブに公開予定
- ハードに依存するレベルでゴリゴリ書いたものではなく高級なもの
- ハミルトニアンへの当てはめは未踏始める前からアイディアがあった?
- アセンブリはモデルあったが、マルチプルアラインメントは試行錯誤だった。使いながらというのは大切
- ClustalWを超えていくような方策はある?
- 評価方法を決めたら変わってくるので、何を見たいかを把握してから使ってもらう
アニーリングマシンを用いた最適航路選択アプリケーションの開発
- 船舶衝突回避アプリ
- 白井 菖太郎、八木 武尊、新保 潤 / 担当PM:田中 宗
- 東京理科大
- VWが陸、ドイツ航空宇宙センターが空の先行研究があったが海はまだない
- 海運業界の問題:マラッカ・シンガポール海峡など、混雑するところがある
- 今は航海士がレーダーの情報をもとに経験的な感覚で回避
- 最適化シナリオ
- 最終的には企業(商船三井、ShipDC)にヒアリングして方針を決定
- ①衝突を考慮しない航路の計算
- 定期便が多く、航路はほぼ固定のためNG
- ②港の入港順の最適化
- 各会社が管理しているため、港をまたいだ最適化はNG
- ③入港準を考慮して日程を最適化
- 衝突回避モデル
- 時空間グラフ(時間×座標)で衝突を定義
- 新たな操作で衝突しないようにマージン
- 速度を落とすことで入港日時を調整してもらう
- 既存のソルバ(CPLEX)との比較
- 40隻くらいならCPLEXで最適解が速く出せる
- 100隻までいくと、GPUアニーラやデジタルアニーラの方が良い解が出せた
- デモアプリ
- 遅延(評価関数)の定義は?
- 各船の遅れ時間の合計
- マラッカだと1日300隻という事だが計算できる?
- 既に入港しているものを先に計算しておく必要があり、そこで100隻までしか今回間に合わなかった
- GPUアニーラだと200隻くらいまではいけるのでは
- 現実的な時間で解けるかは別だが、スペック的に6万ビットの全結合くらいはいけると思う(Fixstars)
- 無理に離散にしているが混合整数問題で解けないか?組み合わせることでより大きな問題が解けるかもしれない
- 航空より難しい?
- 海のほうが衝突しやすいと聞いている(高さ方向がない)
量子多体系の実時間発展シミュレーションプログラムの開発
- 松澤 優太 / 担当PM:藤井 啓祐
- 量子位相推定アルゴリズムにより、分子の固有エネルギーの推定を行うプログラムの製作
- PySCFに接続し、結果を可視化
- 量子化学計算のボトルネック
- 電気は一はM個の分子軌道へのN個の電子(↑、↓)の入れ方
- 古典コンピュータで厳密解を計算できるのはN=16程度まで
- 関心をエネルギーに絞る(波動関数は置いておく)
- 位相推定で求めたい精度とTrotterの関係は?
- データを用意してこなかったが、1次のTrotterは刻み幅の2乗で増えるかと思う
- 公開しようとは思っている、Githubとか
- PySCFのフォーマットなら量子化学やってる人に使ってもらえると思うが、どれくらいの規模までできそう?
- 今は30qubitくらいが限界と思っていて、ベンゼンやフタレンのような小分子
- エネルギー以外のプロパティを計算しようと思った場合はどうする?
- 量子コンピュータが大きくなって高速になったとき、古典側の計算も大きい規模扱えるか?
- 扱えると思う
web開発向けオープンソース量子計算ライブラリの開発
- 山下 広嗣、熊田 圭佑、松崎 出愛、安田 京太 / 担当PM:藤井 啓祐
- TypeScript製量子計算器ライブラリ 'qramana'
- 量子計算をWebアプリ内で簡単に実行できる環境を作った
- モチベーション
- 量子コンピュータのゲームを作ろう
- ゲーム開発の試行錯誤(ユーザからのフィードバック)のサイクルを速くする
- 敷居を低く、簡単に始められるためには、ブラウザ上で動くのが良い
- 量子計算のロジックを1から書くのはしんどいが、科学計算ライブラリを使うのはヘビー
- JavaScriptやTypeScriptのライブラリがあれば
- 開発
- 量子ビットをどう記述するか
- ソフトウェア上の役割の記述とうまく馴染むように
- 量子もつれの管理(どことどこがもつれているか)まで開発者が管理するのはしんどい
- 量子状態の管理はライブラリで隠蔽
- 量子計算の複雑な処理はできるだけ隠蔽
- Githubで公開している(https://github.com/qramana/qramana)
- デモ:量子タワーディフェンス
- 今後も進歩させていくか?
- 今回は最適化等入れていないが、そういった技術の進歩に伴って取り込んでいきたい
- どれくらいの規模まで計算できる?
- ゲームでストレスなく、となると10qubitくらいまでか
- ゲームと称してユーザに計算させることも、技術的にはできてしまうと思う。捕まるかもしれないが
- 今後の展望は?
- ゲームとしてもよりストーリー性のあるものを作りたい
- 例では0,1だったがenum的な使い方ができるようになっているか?
- 量子的なところはサポートできているが、ゲームエンジン的なサポートはできていないのでエンジニアの力量による
量子コンピュータによる公平な抽選システムの開発
- 吉村 優 / 担当PM:藤井 啓祐
- リクルート
- 抽選とは(ここでの定義)
- 参加者が運営にお金を支払うと、確率的に景品を入手できる構造
- 表記される確率が正しいのかという疑惑は尽きない
- 抽選を公平にすることは社会的に重要
- 公平な抽選
- 参加者にとっても運営にとっても、確率が実装に基づいて明らかである事
- 参加者も運営も確率操作ができない事
- 1bitの抽選(古典コイントス)
- アリスが紙に裏表を書く(ボブは読めない:隠蔽)
- ボブがコイントス(アリスが操作できない:束縛)
- 隠蔽と束縛を完全に両立させることは無理
- 片方を完全にし、片方を計算量で担保
- 開発
- 量子コイントス
- 参加者と運営が同じ確率で不正ができる
- 実装
- まとめ
- 量子通信管路を前提としているのが課題
- 多人数化も今後の課題
- 不正出来る確率は?
- 計算能力が大きいと有利になる事はないか?
- 実機前提だと思うがNISQでも使えるか?
- 完全に誤り訂正がきいたものでないと、運営が間違って不正を指摘してしまうとまずい
- とはいえ量子暗号はけっこう実現できてきているし、抽選なら長距離でなくても良いかもしれない
- 通信途中で無くなっても耐性がある一方、ユーザはBANされてもアカウント作り直せてしまう
分散量子計算プラットフォーム
- 永山 翔太、中島 博敬 / 担当PM:藤井 啓祐
- フォルトトレラント量子計算
- エラー訂正しながら量子計算
- |A>を大量に必要
- 分散サーバで用意して量子インターネットで集めよう!
- 分散量子計算
- 耐量子セキュリティ
- 暗号スイートはTLSで、将来的に耐量子暗号に移行する
- 認証は通信が終わるまでに解かれなければよい
- スパコンの性能はFLOPSで評価されるが、量子コンピュータではAKEPS(A Ket Per Second)ではないか
- 量子状態のストレージがあれば、溜めておいて必要な時に出せる?
- それは可能
- あるいみ計算内容によらずに事前にためて置けるというのは量子計算の面白い一面
- エンタングルさせると量子コンピュータを繋いだ時に巨大な量子コンピュータになってしまうようにも思うが、シミュレーションの際に工夫した?
- 今回は量子状態までシミュレーションしてないが、実際は切り離せない、分散量子計算やってる人はみんな悩んでいる
- 実情は9割がA factoryなので、ほとんどが|A>に専念してもらうことになりそう
- |A>提供に対するインセンティブは必要なのでは?
- 貢献度を管理しているので、リソースを優先的に割り当てるとか、インセンティブを与える事はできると思う
量子性を活かしたゲームの開発
- 須郷 聖也 / 担当PM:藤井 啓祐
- 目標
- 量子の性質を面白さに結び付けたゲーム
- 量子を前面に出すより面白さを重視
- 成果
- 課題
- 量子=確率で運ゲーになってしまうとプレイヤーの納得感が得られない
- 量子ギミック以外の確率的な要素は極力減らす
- 仕様・ルールが複雑になる
- 極力シンプルなところからスタート
- 考慮するべき情報が多くなりすぎる
- 極力覚えるべき情報量を減らす
- イメージしやすいプレビューを用意する
- ルールに量子を入れるという順序より、量子ギミックを考えてから既存ゲームを選ぶ方が良いように思う
- Pythonで作った利点は?
- 自然にQiskit使えたというだけ、Unityで作るべきだった
- 他社の量子ゲームをどう評価した?
- 1人でやったのであまり詳細評価していない
- ただ、ゲートを直接意識しなくて良い事、他のゲームでも使えるような汎用的なギミックを作ることは意識して取り組んだ
- 量子性や量子状態の見せ方のアイディアとして他に何か考えたものは?
- 正直あまり良いものは出来ていない
- 対戦で1台のPCという事はあまりないが、今後どうしていきたいか?
- それぞれシンキングタイムを置いて同時に出してもらうのが良いと思っている
FPGAによる量子コンピュータシミュレーションシステムの開発
- 三好 健文 / 担当PM:藤井 啓祐
- 複素確率振幅に対する行列計算でシミュレーション
- FPGA
- メリット:データ型や演算器の構成をユーザが自由に決められる
- デメリット:メモリも動作周波数も既存プロセッサより低速
- 実装の鍵
- 専用演算器を作れる→複素数の専用演算
- 16GBps
- アドレス生成・アクセス管理
- 演算に必要なメモリのアドレスを先に計算
- 結果
- Qulacsに負けた
- 今後の展望
- 大規模化に向いているという話だったが、何qubitくらいまでいけそう?
- 帯域がどれだけとれるかがカギになると思う。パッと作れるのは16ノードまでじゃないか。そうすると40qubitくらいか
- もっと大きな演算、例えばQFTを乗せるとより有利なのでは?
- その通り
- 量子計算の回路が先に分かるので、特定のメモリを寄せておくと有利になるのでは?
- その通りですが、組み合わせが複雑すぎて難しく、ランタイムにやるのが良いのではという結論になった
- 量子コンピュータ以外にも今回の成果は応用できないか?
- 一番きついのはクロック数が遅いとこ?
- その通り、ただ丸めをさぼれるとかなり良くなるはず
- ASIC含めてつきつめればどこまで規模いけるだろうか?
- 究極的にはネットワーク帯域がネックになりそうで、16くらいじゃないか
おわりに
趣味で聞きに行ったというのもありますが、分からないなりに非常に楽しく聞かせて頂きました。ワクワクする内容が多かったと思います。量子コンピュータ、量子アニーリングが今後も盛り上がって行くと良いですね。