日本ソフトウェア科学会第 35 回大会 (2018 年度) 講演論文集

ブロックチェーン上のアプリケーション移植性に向けて
首藤 一幸

神田 伶樹斉藤 賢爾

本稿で我々は，経済的なインセンティブに支えられたパブリックブロックチェーンが抱える根本的な問題，インセンティブ不整合を論じる．これは未解決問題であるが，アプリケーション移植性が暫定解となる．移植性はプライベートブロックチェーンのアプリケーションにとっても望ましい性質である．本論文で，アプリケーション移植性，特にブロックチェーン間移行をサポートするミドルウェアの設計を示す．

We discuss the issue of what we call incentive mismatch, a fundamental problem with public blockchainssupported by economic incentives. This is an open problem, but one potential solution is to make application portable. Portability is desirable for applications on private blockchains. Then, we present examplesof middleware designs that enable application portability and, in particular, support migration between
blockchains.

1 はじめにブロックチェーンは、政府といった中央的な存在なしに（図 1）ある種の信頼を提供し，その応用は暗号通貨以外にも広がりつつある．

ノード群のpeer-to-peer(P2P) ネットワーク= アプリケーションレベル
ネットワークノード(マイナー = 採掘者)

インセンティブ不整合は，パブリックブロックチェー
ブロックのハッシュチェーンンが抱える根本的な問題である．ブロックチェーンを支えるノード群のインセンティブは経済的なもの，ブロックつまりコインの取得であり，ブロックチェーン上アプハッシュ値ハッシュ値取引

取引

取引

取引

取引

取引

リケーションのそれとは異なる．経済的な魅力が消

暗号学的ハッシュ関数

ブロック失してブロックチェーンが機能不全に陥った場合，そTowards Application Portability on Blockchains.
Kazuyuki Shudo, Reiki Kanda, 東京工業大学 情報理工学院 数理・計算科学系, Dept. of Mathematical andComputing Science, Tokyo Institute of Technology.
Kenji Saito, 慶應義塾大学 SFC 研究所, Keio ResearchInstitute at SFC, Keio University.
c 2018 IEEE. Personal use of this material is permit⃝
ted. Permission from IEEE must be obtained for allother uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers orlists, or reuse of any copyrighted component of thiswork in other works.

図1

分散システムとして見たブロックチェーンの上のアプリケーションも機能不全に陥る．ブロック
チェーンとアプリケーションのインセンティブを揃えることは容易ではなく，未解決の課題である．
それでも，もしアプリケーションに移植性があれば，ブロックチェーンの機能不全に際してもアプリケーションは守ることができる．移植性は，プライベートブロックチェーン上のアプリケーションにとっても望ましい性質である．ミドルウェアへの依存を最小限とすることは知られたベストプラクティスの１つ

日本ソフトウェア科学会 第35回 大会講演論文集, 2018年 8月

る．2018 年 5 月には実際に，暗号通貨を支えるパブであろう．
しかし，今日，各ブロックチェーンミドルウェア

リックブロックチェーンへの攻撃が立て続けに成功しはそれぞれ固有の API を提供しており，あるミドルた．Monacoin の場合，攻撃者は，block withholding

ウェア向けに書かれたアプリケーションは他のミドル攻撃によって，一度は承認された 20 ブロック以上をウェアでは動作しない．各ブロックチェーンは，例え無効化した．Bitcoin Gold の場合，攻撃者は，22 ブ

ば Ethereum の Solidity 言語のように，独自の抽象ロック以上を無効化し，コインの二重使用に成功し化を行っているため，機能する共通 API を策定できた．これは，ブロックチェーン上のアプリケーションるかどうかも定かではない．

は，その基礎となる承認能力に対して何の制御もでき

本論文にて我々は，インセンティブ不整合問題を提起し，暫定解としてアプリケーション移植性を論じず，経済環境が原因で機能不全に陥り得るということである．

る．続いて，アプリケーションのミドルウェア間移行

ブロックチェーンを支えるノード群とブロックチェーを可能とするソフトウェアアーキテクチャと技法を述

ン上アプリケーションの動機を揃えることは可能だ

べる．

ろうか？あるパブリックブロックチェーンを支える貨

本論文は我々の以前の論文 [10] の日本語版である．

幣システムは，それ自体が，ブロックチェーンの承認能力を活用するアプリケーションである．この場合，

2 アプリケーション移植性の恩恵

動機は整合しているが，しかし，これは特殊ケースで移植性は，パブリックとプライベートブロックチェーある．同一の人や組織がブロックチェーンノード群とン，双方のアプリケーションにとって，それぞれ理由アプリケーションの両方を配備，運用すれば，動機はは異なれど，望ましい性質である．

整合する．こうなると，それはプライベートブロックチェーンである．

2. 1 パブリックブロックチェーンのアプリケー
ション

さもなくば，パブリックブロックチェーンとその上のアプリケーションは一般には共通の動機は持たなパブリックブロックチェーンは我々がインセンティい．それらをどう整合させるか，換言すると，アプリブ不整合と呼ぶ根本的な問題を抱えている．ブロック

ケーション群が自ら承認能力を支える機構を作れる

チェーンを支えるノード群とブロックチェーン上のアのか否か，は未解決問題である．アプリケーション移プリケーションに，共通の動機がないのである．パブ植性は，この問題への暫定解となる．もし，移植性，リックブロックチェーンでは，トランザクションの承特に移行可能性（3 章）があれば，ブロックチェーン

認は Proof of Work [2] やその派生形である Proof ofが機能不全に陥りそうな状況でも，アプリケーション

Stake [8]，Proof of Elapsed Time [5] 等によって達を他のブロックチェーンに移行できる．

成されており，そうした機構はノード群の経済的な動機に基づく．ノード群はただコインを稼ごうとしているだけであり，アプリケーションを支えるという動機は持たない．

2. 2 プライベートブロックチェーンのアプリケーション
移植性は，プライベートブロックチェーン上のアプ

パブリックブロックチェーンは，ノード群に対してリケーションにとっても望ましい性質である．移植性充分な経済的動機を与えそこねると，トランザクショが低いと，いわゆるベンダロックインを被ることとなンを安全に承認することができなくなる．例えば，コる．例えば，アプリケーションとその利用者は，よりイン価値の低下はノード群の離脱を招き，安全な承良い他のミドルウェアの恩恵を受けられない．悪い認を行う能力が低下する．ブロックチェーンは，支と，ミドルウェアと共にアプリケーションも死んでしえるノードが少ないほど，majority (51%) attack やまう．ここで言う死とは，古さが原因でミドルウェア

eclipse attack [4] [6] といった攻撃に対して脆弱になを実行できくなる，という意味である．

日本ソフトウェア科学会 第35回 大会講演論文集, 2018年 8月

$QDSSOLFDWLRQFDQUXQRQERWK$QDSSOLFDWLRQFDQPLJUDWH

$SSOLFDWLRQ$$SSOLFDWLRQ$$SSOLFDWLRQ$$SSOLFDWLRQ$%ORFNFKDLQ$%ORFNFKDLQ%%ORFNFKDLQ$%ORFNFKDLQ% 5XQQDEOH
図2 0LJUDWDEOH
アプリケーション移植性の 2 レベル

ど意味がない．“移行可能” レベルの移植性が，プラ

3 アプリケーション移植性

イベートブロックチェーンミドルウェアの喪失（2. 2

アプリケーション移植性にはいくつかのレベルがあ節）やパブリックブロックチェーンの機能不全（2. 1る．以降，次の 2 レベル（図 2）を区別して扱う．

1. “動作可能（runnable）”：

アプリケーション節）を乗り越えてのアプリケーションの生存を可能にする．

は異なるブロックチェーンの上で動作し得る．あるブロックチェーンから他への移行はできない．

2. “移行可能（migratable）”：

アプリケーションとそのデータをあるブロックチェーンから異なるブロックチェーンへ移行できる．
ブロックチェーン群に共通する API があれば，“動4 アプリケーションのブロックチェーン間移行
本章は，どのようにしてアプリケーションのブロックチェーン間移行を達成するかを論じ，移行を可能にするミドルウェアの設計案を示す．

作可能” レベルの移植性が達成される．また，同一のミドルウェアで運用される別ブロックチェーンの間で4. 1 移行対象データ移植性があることは自明であろう．一方，異種ミドル

どういったデータをブロックチェーン間移行の対象ウェアに対して，機能する共通 API を策定できるかとすべきか？アプリケーションがブロックチェーンにどうかは定かではない．各ミドルウェアはそれぞれの依存しないものであって，ミドルウェア間で移行する抽象化を採用しているからである．例えば，あるミ場合，たいていは，アプリケーションの最新状態，例

ドルウェアはブロックのハッシュチェーンの代わりにえば関係データベース中のレコード，さえ移行すれば有向非巡回グラフ（DAG）を採用しているし，各ミ充分である．しかし，ブロックチェーンを採用する強ドルウェアはそれぞれ自身のスマートコントラクト

い動機の１つは，過去のある時点であるデータが存在機構—例えば Ethereum の Solidity 言語—を持ってしたことを証明できることや，状態（データ）の変化いる．しかし，もし，アプリケーションが利用するブを検証できること，である．この場合，最新状態だけロックチェーンの機能を限定し，限定した機能に対しを移行したのでは不足である．存在証明や検証に必要て共通 API を用意できたなら，移植性を達成できる．

なログの移行も必要である．

どのようなブロックチェーンもハッシュ値をタイムスタンプ付きで格納する程度の機能は持っており，このための共通 API くらいは用意できる．
移植性が “動作可能” レベルにとどまる場合，別ブロックチェーンへ移行するアプリケーションはその初つまり，移行の対象となるデータには次の 2 つのクラスがある．

1. アプリケーションの最新状態
2. ログ – 状態についてのメタデータであり，状態変化とそのタイムスタンプから成る．

期状態での再起動しかできず，蓄積したデータは捨

例えば，Bitcoin のような貨幣アプリケーションでは，てざるを得ない．データの存在証明と状態変化の検前者は口座残高である．もっとも，これは，Bitcoin

証はブロックチェーンの特徴的な機能であり，それをでは明には記録されず関連するトランザクションを集可能にするログ（4. 1 節）を伴わない移行ではほとん

計することで算出できる．後者はトランザクションで日本ソフトウェア科学会 第35回 大会講演論文集, 2018年 8月

$SSOLFDWLRQ
0LGGOHZDUH

HQDEOLQJDSSOLFDWLRQPLJUDWLRQ
 'DWDLWHP
 7LPHVWDPS%ORFNFKDLQWKDWVWRUHVDEOREZLWKDWLPHVWDPS

D $EORFNFKDLQVWRUHVGDWD

図3$SSOLFDWLRQ
0LGGOHZDUH

HQDEOLQJDSSOLFDWLRQPLJUDWLRQ
 ,QGH[LQWKHGDWDEDVH
 +DVKHGYDOXHRIWKHGDWDLWHP
 7LPHVWDPS 'DWDLWHP'DWDEDVH%ORFNFKDLQWKDWVWRUHVDSDLURILQWHJHUVZLWKDWLPHVWDPSE $QH[WHUQDOGDWDEDVHVWRUHVGDWD

ブロックチェーンへの依存を制限することでアプリケーション移植性を向上させるソフトウェアアーキテクチャ

あり，口座残高の変化とタイムスタンプから成る．

 ືసྍ⬟ 䠄5XQQDEOH䠅
ඹ㏻ $3,䛚䜘䜃ඹ㏻ゝㄒ䛻䜘䛳䛶䚸ྍ⬟䛸䛺䜛

4. 2 移行を可能とするミドルウェア設計移行を可能にするミドルウェアを設計するにあたり，次の方針を採る．

• 特定のブロックチェーンミドルウェアへの依存を最小限にする．
単純なデータ，つまり数値の組やバイト列等をタイムスタンプと共に記録する機能だけを前提とする．

• 移行元ブロックチェーンを信用し続けられると ⛣⾜ྍ⬟ 䠄0LJUDWDEOH䠅≧ែ䠄䝕䞊䝍䠅ኚ໬䛾᳨ド䜎䛷 ᚲせᅗ D 䠖 ⛣⾜ඖ䝤䝻䝑䜽䝏䜵䞊䞁䜢ಖᏑ䛧䚸⥔ᣢ䛩䜛ᚲせ䛜䛒䜛ᅗ E 䠖 ᭦᪂᫬䛻䝕䞊䝍䛾඲䝞䞊䝆䝵䞁䜢ಖᏑ䛧䛶䛔䛟ᚲせ䛜䛒䜛 ୙せᅗ D 䠖 䝕䞊䝍䛾Ꮡᅾド᫂䛻ᚲせ䛺䝯䝍䝕䞊䝍䜢䝁䝢䞊䛧䛯ᚋ䚸⛣⾜ඖ䝤䝻䝑䜽䝏䜵䞊䞁䛿ᤞ䛶䜛䛣䛸䛜䛷䛝䜛ᅗ E 䠖 䝕䞊䝍䛿ୖ᭩䛝䛧䛶䜘䛔

図4

アプリケーションの移行を可能にするブロックチェーンの設計選択肢は期待しない．
あるブロックチェーンから脱出しようとタベースに保存する，という設計もあり得る．ブロッいう理由の１つは，そのブロックチェー

クチェーン上ミドルウェア Beyond Blockchain Oneンの差し迫った機能不全である．例えば，(BBc-1) [9] がこうした設計を採っている．この設計

パブリックブロックチェーンは，ノードはブロックチェーンのサイズを削減する．ブロックを失い過ぎるとそうした機能不全に陥チェーンは全ブロックチェーンノードにコピーされる（2. 1 節）．この場合，そのブロックて，全ノード上のストレージを占有するため，サイズチェーンに依拠し続けることはできない．の削減にはメリットがある．加えて，もしアプリケー

図 3 に設計の候補を示す．図中の “middleware” がションが状態（データ）変化の検証までは必要としなブロックチェーン間移行を行う．上述の依存を最小いという場合，データベース上のデータをただ上書き限にするため，設計案では，ブロックチェーンにはすれば済み，ストレージ専有量はさらに減る．

いくつかの値とタイムスタンプの組を検索キー（例：

図 3 (b) の設計では，充分なデータ可用性を達成す

Bitcoin アドレスといったアカウント ID）とともにるためには，データベースの耐故障性が充分に高い必記録する機能しか求めない．それ以上を求める場合要がある．このためには，たいていの分散データベーも，せいぜいブロブ（バイト列）の記録までとする．

スがサポートしている複製や消失訂正符号（erasure

それ以上の機能をサポートしつつの移行は今後の課coding） [3] を用いることができる．耐故障性の程度

題である．

は，複製数や消失訂正符号のパラメータを設定するこ移行のために必要ではないものの，図 3 (b) のようとで調整できる．このように調整できる柔軟性は，全に，データはブロックチェーン内ではなく外部のデーブロックチェーンノードへの単純なコピー（図 3 (a)）

日本ソフトウェア科学会 第35回 大会講演論文集, 2018年 8月

,PPXWDEOH
DQGWUXQFDWHGDIWHUWKHH[SLUDWLRQWLPH

5XQQLQJ%ORFNFKDLQ%ORFNFKDLQ«([SLUDWLRQWLPH
RIWKLVEORFNFKDLQ

6WRUH
 +DVKHGYDOXH
 ([SLUDWLRQWLPH$KDVKIXQFWLRQ
0LJUDWLRQ
図5

ブロックチェーン間でアプリケーションを移行させる方法に対する利点であろう．現在，そうした可用性の高いを自身のストレージに保存し，有効期限以降を切りデータベースがパブリッククラウドのサービスとして捨て，それをアクセスする．ミドルウェアは，移行直提供されており，さらには我々自身でクラウド提供者

前の時刻を移行元ブロックチェーンの有効期限と設定をまたいで複数のデータベースに記録することもでする．タイムスタンプはある程度操作できてしまう

きる．

ので，有効期限はブロック高で指定することとなろ

図 3 (b) の設計では，アプリケーションが状態（デーう．静的保存によって，ブロックチェーンミドルウェタ）変化の検証までは必要としない場合は，更新時にア実行の必要性をなくせる．切り捨てによって，有効データをデータベース上で上書きしてしまうことも期限以降にそのブロックチェーンを信用する必要をなできる．これによって，ストレージの占有量をさらにくせる．

減らすことができる．
図 4 に，アプリケーションの移行を可能にするブロックチェーン設計の選択肢をまとめる．

ミドルウェアは，図 5 の通り，保存されたブロックチェーン群からハッシュチェーンを構成する．ハッシュチェーンによって，我々は保存されたブロックチェーンへの改ざんを検知でき，改ざんされていない

4. 3 移行の手順ことを信じられる．ハッシュチェーンによって，次のアプリケーションが移行元ブロックチェーン中のブロックチェーンに格納された有効期限が正しいことログ（4. 1 節）へのアクセスを必要とするなら，ミドの確認もできる．

ルウェアはアクセスを提供する必要がある．しかし

ここで，パブリックブロックチェーンではいったん

我々は，セキュリティ的な理由から，移行元ブロック承認されたブロックも無効化される可能性があるこ

チェーンを信用し続けられると期待するわけにはいとを思い出さねばならない．それは，攻撃（2. 1 章）

かない（4. 2 節）．さらに，移行元ブロックチェーンによっても，また，自然にも発生する．そのブロックのミドルウェアが実行を続けていてアクセスできる

チェーン上のアプリケーションは，そうした無効化をとは期待しない方が安全である．なぜなら，一般に単に無視できるように思われる．なぜなら，アプリパブリックブロックチェーンを制御できないのである

ケーションは，実行を続けている古いブロックチェー

し，プライベートブロックチェーンのミドルウェアをンではなく，静的に保存したブロックチェーン群にの実行させ続けるためには手間と CPU 能力が要る．つ

み依拠するからである．とはいえ，そうしたブロックまり，移行元ブロックチェーンを信用することなく，無効化を考慮せねばならない状況もあるかもしれな実行が続いていることを仮定することなく，その中のい．その場合，静的に保存したブロックチェーンもログにアクセスする方法が必要である．

更新する必要がある．最低でも、保存したブロック

図 5 はこれらの要求を満たす移行手順である．ミド

チェーンの有効期限を，未だ有効なブロックまで巻きルウェアは，移行元ブロックチェーンの静的なコピー戻す必要はある．ともあれ，そうした更新は時間を食

日本ソフトウェア科学会 第35回 大会講演論文集, 2018年 8月

かし，このコピーを行う設計では，コピー先メタデー
タは元データと明示的な関係を持たず，検証ができな
い．アプリケーションはそもそもコピーを行うミドルウェアを信用しているという前提ではあるが，そうしたソフトウェアの正しさに依拠する信用は検証可能データによる信用より弱い．なぜなら，例えばソフトウェアは人的誤りを含むからである．次善の策は，コピーを行うプログラムの検証であろう．コピーを行うプログラムとそのハッシュ値をどこかに保存しておくことで，検証可能にできるだろう．
図6

Bitcoin の約 10,000 ノードを表したネットワーク
座標系（単位はミリ秒）

5 まとめ
ブロックチェーンのアプリケーションには，通常のい，その間アプリケーションを止めてしまうので，避アプリケーションと同様に移植性への動機がある一

けたい．我々は，自然発生するブロック無効化の原因方，パブリックブロックチェーン上ではインセンティである，ノード間ブロック遅延を減らそうと試みていブ不整合という特有の動機もある．つまり，パブリッる．削減のための手法は，隣接ノード選択か経路選択

クブロックチェーンはアプリケーションとは異なる経[7] となるだろう．そうした，性能のための隣接ノー済的なインセンティブで駆動されており，アプリケード選択や経路選択には，ノード間の近接性情報が必ションから制御できるものではない．そのため，移要である．そのために我々はまず，Vivaldi [1] といっ植性，もっと言うと移行可能性がない限り，ブロックたネットワーク座標系を用いてノード間の通信遅延をチェーンが機能不全になるとアプリケーションも機能見積もる手法を確立しようと試みている．図 6 は，2不全に陥ってしまう．

次元ユークリッド平面上で Vivaldi を用いて推測した

ブロックチェーンアプリケーションの生存能力を高Bitcoin ノード間の通信遅延である．この取り組みにめるべく，移植性と移行について論じた．ブロックおける次の一歩は，精度の向上である．

チェーン間移行を可能にするミドルウェアの設計を示

このミドルウェアはすべての移行元ブロックチェーンを解釈できる必要がある．それらブロックチェーンし，要求の少ないアプリケーション向けにはより効率的な代替案を示した．

は，それぞれが自身の形式を持っているだろう．そう

アプリケーション移植性と移行は，一般に望ましした解釈機能の開発は大きな労力を要し，また，ソフい機能ではあると同時に，パブリックブロックチェートウェアは複雑で多くの誤りを含みがちとなる．もしンのインセンティブ不整合問題に対する暫定解となアプリケーションが許すなら，移行元ブロックチェー

る．それでも，ブロックチェーンは，ノードの経済的ンは単純に捨てることが望ましい．アプリケーションインセンティブではなく，アプリケーション群自身にが，存在証明は必要とするけれど状態（データ）変化よって支えられることが望ましい．もし，パブリックの検証までは必要としないという場合，存在を証明すブロックチェーンが常にアプリケーション群だけに支るメタデータ（と図 3 (a) ならデータ自体）を次のブえられるなら，それはインセンティブ整合ブロックロックチェーンにコピーし，移行元ブロックチェーンチェーンであると言える．しかし，そうした機構をどは捨てることができる．この場合，コピー元メタデーう作るかは未解決問題である．

タなしにコピー先メタデータが正しいことをどう信ISO 等で分散台帳分野の標準化が始まっている．

じたらよいだろうか？ブロックチェーンが提供する信IETF や W3C もすでに議論を持った．機能する共用は，データが検証可能であることに基礎を置く．し通 API の策定でさえ挑戦的であり，ブロックチェー

日本ソフトウェア科学会 第35回 大会講演論文集, 2018年 8月

ン間移行はそのさらに先にある．今日，まずソフトを受けたものです．

ウェアが実装され，仕様書の作成はソフトウェアが多大な人気を得た後で行われる．実際，最初の Bitcoin

参 考 文 献Improvement Proposal（BIP）は Bitcoin ネットワー[ 1 ] Dabek, F., Cox, R., Kaashoek, F., and Morris,
R.: Vivaldi: A Decentralized Network Coordinate
System, Proc. ACM SIGCOMM 2004, September
2004.
[ 2 ] Dwork, C. and Naor, M.: Pricing via Processing or Combatting Junk Mail, Proc. CRYPTO’92,August 1992, pp. 139–147.
[ 3 ] Ford, D., Labelle, F., Popovici, F. I., Stokely, M.,
Truong, V.-A., Barroso, L., Grimes, C., and Quinlan, S.: Availability in Globally Distributed Storage
Systems, Proc. OSDI’10, October 2010.
[ 4 ] Gervais, A., Ritzdorf, H., Karame, G. O., andČapkun, S.: Tampering with the Delivery of Blocks
and Transactions in Bitcoin, Proc. ACM CCS 2015,
October 2015.
[ 5 ] : Hyperledger Sawtooth. https://sawtooth.hyperledger.org/.
[ 6 ] Heilman, E., Kendler, A., Zohar, A., and Goldberg, S.: Eclipse Attacks on Bitcoin’s Peer-to-Peer
Network, Proc. USENIX SEC’15, August 2015,pp. 129–144.
[ 7 ] Miyao, T., Nagao, H., and Shudo, K.: A Methodfor Designing Proximity-aware Routing Algorithms
for Structured Overlays, Proc. IEEE ISCC’13,2013.
[ 8 ] QuantumMechanic: Proof of stake instead ofproof of work. https://bitcointalk.org/?topic=27787.0.
[ 9 ] Saito, K. and Kubo, T.: BBc-1 : Beyond
Blockchain One – An Architecture for PromiseFixation Device in the Air –. Available electronically at https://beyond-blockchain.org/public/bbc1design-paper.pdf.
[10] Shudo, K., Kanda, R., and Saito, K.: Towards
Application Portability on Blockchains, Proc. IEEE
HotICN 2018, August 2018.

クの立ち上げから 2 年半以上後だった．本論文に続く
実効性のある次の一歩は，移植性のある，もしくは，移行可能なアプリケーションのデモンストレーションだろう．
あまり論じなかったものの，スマートコントラクトのプログラムコードとデータの移植性も今後の課題である．同一ミドルウェア上でさえ，既存データを維持したままでのデータ形式やプログラムコードの更新は困難である．

謝辞
インセンティブ不整合問題，インセンティブ整合した将来のパブリックブロックチェーンなど多くのトピックを議論した竹井悠人氏，北條真史氏，鈴木茂哉氏に感謝します．プライベートブロックチェーンにおける移植性の意義を指摘してくれた小出俊夫氏に感謝します．本研究はカウラ (株) の支援を受けたものです．本研究は（公財）セコム科学技術振興財団 一般研究助成の支援を受けたものです．本研究の一部は，国立研究開発法人新エネルギー・産業技術総合開発機構（NEDO）の委託業務として行われました．本研
究は JSPS 科研費 25700008 および 16K12406 の助成

日本ソフトウェア科学会 第35回 大会講演論文集, 2018年 8月