(57)【要約】【課題】ブロックチェーン上で、データの履歴を容易に追跡することを可能とする。【解決手段】ブロックチェーンシステムであって、分散台帳１１は、スマートコントラクトのステートをトークン毎に記憶するステートデータベースを有し、利用者端末１は、トークンを更新するトランザクションを発行するトランザクション発行部１３を備え、承認端末２は、ステートデータベースのトークンを更新する更新部１５４と、トランザクションを含むブロックを生成し、当該ブロックおよび更新後のステートデータベースを分散台帳１１に反映させるブロック生成部１５３とを備え、更新部１５４は、ステートデータベースのトークンに、更新ブロック番号と、トークンのトークン情報とを含む追跡データを設定する。【選択図】図１
2020170296.tif 000002
【特許請求の範囲】
【請求項１】
利用者端末と、承認端末とを備えるブロックチェーンシステムであって、
前記ブロックチェーンシステムの分散台帳は、スマートコントラクトのステートをトークン毎に記憶するステートデータベースを有し、
前記利用者端末は、
トークンを更新するトランザクションを発行するトランザクション発行部、を備え、
前記承認端末は、
前記ステートデータベースの前記トークンを更新する更新部と、
前記トランザクションを含むブロックを生成し、当該ブロックおよび更新後の前記ステートデータベースを前記分散台帳に反映させるブロック生成部と、を備え、
前記更新部は、前記ステートデータベースの前記トークンに、前記トークンを更新したブロックの更新ブロック番号と、前記トークンのトークン情報とを含む追跡データを設定すること
を特徴とするブロックチェーンシステム。
【請求項２】
請求項１記載のブロックチェーンシステムであって、
前記トランザクション発行部は、複数のトークンを結合するトランザクションを発行し、
前記更新部は、複数の前記トークンを結合した結合トークンに、前記結合トークンを生成したブロックのブロック番号と、結合元の複数の前記トークンのトークンＩＤおよびスマートコントラクトのアドレスとを、前記追跡データとして設定すること
を特徴とするブロックチェーンシステム。
【請求項３】
請求項２記載のブロックチェーンシステムであって、
前記更新部は、前記ステートデータベースの結合元の複数の前記トークンに、消費済であることを示すフラグを設定すること
を特徴とするブロックチェーンシステム。
【請求項４】
請求項１記載のブロックチェーンシステムであって、
前記トランザクション発行部は、トークンを分割するトランザクションを発行し、
前記更新部は、前記トークンから分割された分割トークンに、前記分割トークンを生成したブロックのブロック番号と、分割元の前記トークンのトークンＩＤおよびスマートコントラクトのアドレスとを、前記追跡データとして設定すること
を特徴とするブロックチェーンシステム。
【請求項５】
ブロックチェーンシステムにおいてトランザクションを承認する承認端末であって、
スマートコントラクトのステートをトークン毎に記憶するステートデータベースを有する分散台帳と、
トークンを更新するトランザクションを受信する受信部と、
前記ステートデータベースの前記トークンを更新する更新部と、
前記トランザクションを含むブロックを生成し、当該ブロックおよび更新後の前記ステートデータベースを前記分散台帳に反映させるブロック生成部と、を備え、
前記更新部は、前記ステートデータベースの前記トークンに、前記トークンを更新したブロックの更新ブロック番号と、前記トークンのトークン情報とを含む追跡データを設定すること
を特徴とする承認端末。
【請求項６】
ブロックチェーンシステムにおける利用者端末であって、
スマートコントラクトのステートをトークン毎に記憶するステートデータベースを有する分散台帳と、
前記ステートデータベースからトークンが更新されたブロックの更新ブロック番号を含む追跡データを取得し、前記更新ブロック番号から算出される検索ブロック番号を指定して、前記検索ブロック番号の時点のブロックにおける前記トークンのステートおよび追跡データを前記ステートデータベースから取得する履歴検索部と、を備え、
前記追跡データは、前記更新ブロック番号と、前記トークンのトークン情報とを含むこと
を特徴とする利用者端末。
【請求項７】
ブロックチェーンの履歴を管理する履歴管理方法であって、
前記ブロックチェーンの分散台帳は、スマートコントラクトのステートをトークン毎に記憶するステートデータベースを有し、
利用者端末は、
トークンを更新するトランザクションを発行するトランザクション発行ステップを行い、
承認端末は、
前記ステートデータベースの前記トークンを更新する更新ステップと、
前記トランザクションを含むブロックを生成し、当該ブロックおよび更新後の前記ステートデータベースを前記分散台帳に反映させるブロック生成ステップと、を行い、
前記更新ステップは、前記ステートデータベースの前記トークンに、前記トークンを更新したブロックの更新ブロック番号と、前記トークンのトークン情報とを含む追跡データを設定すること
を特徴とする履歴管理方法。
【請求項８】
請求項５に記載の承認端末として、コンピュータを機能させることを特徴とする履歴管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、スマートコントラクト型のブロックチェーンの履歴を管理する技術に関する。
【背景技術】
【０００２】
中央集権的な管理を必要とせずに、信頼性を担保可能な仕組みがデジタル仮想通貨ビットコインを中心に普及しつつある。ブロックチェーンと呼ばれるこの仕組みにおいては、やり取りされる情報の信頼性が分散ネットワーク内の合意形成のプロセスによって担保され、かつ、改ざんや二重使用などの不正を系全体で防ぐことで健全性が保たれる。
【０００３】
ブロックチェーンでは、参加者間の取引情報（トランザクション）が「ブロック」という単位でまとめられ、各ブロックは数珠つなぎとなって時系列順に管理される。新たなブロックの承認は、Proof of Workなどの分散ネットワークにおける合意アルゴリズムによって形成される。新たなブロックの承認は、ブロック内部に記録された取引が系全体で合意されたことを示す。
【０００４】
このブロックチェーンを用いて管理される一連の取引情報の帳簿を「分散台帳」と呼び、ネットワークに参加する各端末は同一の分散台帳を保持している。近年では、分散台帳に高度なスクリプトコードを登録し、スクリプトコードの実行とその結果についても合意を得るブロックチェーン基盤技術も開発されている。例えばEthereumと呼ばれるブロックチェーン基盤は、トランザクションを入力としてスクリプトコードを実行し、その実行結果をツリー構造のキーバリュー型ストア（ステートDBと呼ぶ）に格納し、その時のストアの代表値もブロックに記録する分散台帳を持つ。このようにブロックチェーン上に登録され、各端末に登録および実行されるスクリプトコードは「スマートコントラクト」と呼ばれている。
【０００５】
スマートコントラクト型のブロックチェーンは、各ブロックと、そのブロック時点でスマートコントラクトのステートDBとが対応づけて管理されている（非特許文献１）。
【０００６】
また、ブロックチェーン基盤の１つであるEthereumを用いて、サプライチェーンのトレーサビリティを、スマートコントラクトを利用して強化する技術も研究されている（非特許文献２）。
【先行技術文献】
【非特許文献】
【０００７】
【非特許文献１】「JavaScript API・ethereum/wiki  Wiki・GitHub」、https://github.com/ethereum/wiki/wiki/JavaScript-API#contract-methods
【非特許文献２】KENTAROH TOYODA、「A Novel Blockchain-Based Product Ownership Management System (POMS) for Anti-Counterfeits in the Post Supply Chain」、IEEE Access
【発明の概要】
【発明が解決しようとする課題】
【０００８】
ブロックチェーンのデータ構造上、ブロック番号を指定し、そのブロック時点のステートを参照することは容易である。しかしながら、当該ブロックのステートの値が、過去のどのブロックでどのように遷移したのかを知ることは困難である。特に、情報のトレーサビリティを確保するという観点において、この問題は重要である。
【０００９】
例えば、サプライチェーンの商品の追跡においては、非特許文献２に示すように、その時点で最新のステートを参照することは可能であるが、過去のステートを参照するためにはブロック番号をキーとして総当りに探索する必要がある。
【００１０】
ステートのある値の変化を追跡する等の高度な探索・追跡を行う場合、RDBMS等の外部データベースを用意して、ブロックチェーンから抽出した全てのデータを外部データベースに落とし込み、外部データベース上でインデックスを構築し所望のデータを探索・追跡する方法が考えられる。しかしながら、外部データベースを用いた探索システムを構築および維持することは、一般ユーザにとって高いコストを要することになる。
【００１１】
また、非特許文献２では、より複雑なサプライチェーンのケースについて考慮されていない。例えば、材料同士を組み合わせて別の製品が完成するケース（結合）、あるデジタルコンテンツから別のコンテンツが生まれるケース（分割）などは、考慮されていない。このような複雑なユースケースの場合、外部データベースを利用したとしても、探索はより困難となる。
【００１２】
本発明は、上記課題を鑑みてなされたものであり、本発明の目的は、ブロックチェーン上で、データの履歴を容易に追跡することを可能とする技術を提供することにある。
【課題を解決するための手段】
【００１３】
上記目的を達成するため、本発明の一態様は、利用者端末と、承認端末とを備えるブロックチェーンシステムであって、前記ブロックチェーンシステムの分散台帳は、スマートコントラクトのステートをトークン毎に記憶するステートデータベースを有し、前記利用者端末は、トークンを更新するトランザクションを発行するトランザクション発行部、を備え、前記承認端末は、前記ステートデータベースの前記トークンを更新する更新部と、  前記トランザクションを含むブロックを生成し、当該ブロックおよび更新後の前記ステートデータベースを前記分散台帳に反映させるブロック生成部と、を備え、前記更新部は、前記ステートデータベースの前記トークンに、前記トークンを更新したブロックの更新ブロック番号と、前記トークンのトークン情報とを含む追跡データを設定する。
【００１４】
本発明の一態様は、ブロックチェーンシステムにおいてトランザクションを承認する承認端末であって、スマートコントラクトのステートをトークン毎に記憶するステートデータベースを有する分散台帳と、トークンを更新するトランザクションを受信する受信部と、前記ステートデータベースの前記トークンを更新する更新部と、前記トランザクションを含むブロックを生成し、当該ブロックおよび更新後の前記ステートデータベースを前記分散台帳に反映させるブロック生成部と、を備え、前記更新部は、前記ステートデータベースの前記トークンに、前記トークンを更新したブロックの更新ブロック番号と、前記トークンのトークン情報とを含む追跡データを設定する。
【００１５】
本発明の一態様は、ブロックチェーンシステムにおける利用者端末であって、スマートコントラクトのステートをトークン毎に記憶するステートデータベースを有する分散台帳と、前記ステートデータベースからトークンが更新されたブロックの更新ブロック番号を含む追跡データを取得し、前記更新ブロック番号から算出される検索ブロック番号を指定して、前記検索ブロック番号の時点のブロックにおける前記トークンのステートおよび追跡データを前記ステートデータベースから取得する履歴検索部と、を備え、前記追跡データは、前記更新ブロック番号と、前記トークンのトークン情報とを含む。
【００１６】
本発明の一態様は、ブロックチェーンの履歴を管理する履歴管理方法であって、前記ブロックチェーンの分散台帳は、スマートコントラクトのステートをトークン毎に記憶するステートデータベースを有し、利用者端末は、トークンを更新するトランザクションを発行するトランザクション発行ステップを行い、承認端末は、前記ステートデータベースの前記トークンを更新する更新ステップと、前記トランザクションを含むブロックを生成し、当該ブロックおよび更新後の前記ステートデータベースを前記分散台帳に反映させるブロック生成ステップと、を行い、前記更新ステップは、前記ステートデータベースの前記トークンに、前記トークンを更新したブロックの更新ブロック番号と、前記トークンのトークン情報とを含む追跡データを設定する。
【００１７】
本発明の一態様は、上記承認端末として、コンピュータを機能させることを特徴とする履歴管理プログラムである。
【発明の効果】
【００１８】
本発明によれば、ブロックチェーン上で、データの履歴を容易に追跡することを可能とする技術を提供することができる。
【図面の簡単な説明】
【００１９】
【図１】本発明の実施形態に係るブロックチェーンシステムの全体構成を示す図である。
【図２】ブロック発行部の構成を示す構成図である。
【図３】分散台帳の構成を示す図である。
【図４】トークンの遷移を示す遷移図の例である。
【図５】ステートの更新時の追跡データの設定を説明するための模式図である。
【図６】トークンの結合時の追跡データの設定を説明するための模式図である。
【図７】トークンの結合時のステートテーブルの一例を示す図である。
【図８】トークンの分割時の追跡データの設定を説明するための模式図である。
【図９】ブロック生成および履歴検索を示すシーケンス図である。
【図１０】トランザクションの一例を示す図である。
【発明を実施するための形態】
【００２０】
以下、本発明の実施の形態について、図面を参照して説明する。
【００２１】
（ブロックチェーンシステムの構成）
図１は、本実施形態のブロックチェーンシステムの全体構成を示す図である。本実施形態のブロックチェーンは、スマートコントラクト型ブロックチェーンであって、ブロックチェーン基盤技術の１つであるEthereumを用いる。Ethereumは、ブロックチェーンを、状態遷移を記録する分散台帳として用いるためのアプリケーション開発プラットフォームである。ただし、本発明は、Ethereumに限定されるものではなく、Ethereum以外のブロックチェーンに用いてもよい。
【００２２】
図１に示すブロックチェーンシステムは、利用者端末１と、承認端末２とを備える。これらの端末１、２は、P2Pネットワークであるブロックチェーンネットワーク４（以下、「ネットワーク」という）に自律分散的に接続される。なお、ネットワーク４には、図示する端末１、２の他にも、複数の端末が接続される。例えば、複数の利用者端末１、および、複数の承認端末２が接続されていてもよい。ネットワーク４に接続される端末は、後述する分散台帳１１、ブロックチェーン制御部１２およびトランザクション発行部１３を備え、分散台帳１１に記録されたデータおよびトランザクションを相互に検証し、系を維持している。
【００２３】
利用者端末１は、ブロックチェーンおよびスマートコントラクトを利用する利用者が使用する端末（ノード）である。利用者端末１は、分散台帳１１と、ブロックチェーン制御部１２と、トランザクション発行部１３と、履歴検索部１４とを備える。
【００２４】
分散台帳１１には、ブロックチェーン制御部１２を介して、ネットワーク４に接続された全ての端末と緩やかに同期することによって、リアルタイムに近い形で最新状態のブロックチェーンが記憶されている。本実施形態の分散台帳１１には、ブロックチェーンと、ブロックチェーンで管理されるデータ集合とが記憶されている。
【００２５】
ブロックチェーン制御部１２は、ネットワーク４に接続された端末と自律分散的に協調してブロックチェーンの系を維持する。ブロックチェーン制御部１２は、分散台帳１１にアクセスし、分散台帳１１のブロックチェーンおよびデータ集合を読み出し、または、更新する。
【００２６】
トランザクション発行部１３は、トランザクションをネットワーク４に発行する。本実施形態では、トランザクション発行部１３は、トークンを更新するトランザクションを発行する。具体的には、トランザクション発行部１３は、トークンのステートの値を更新するトランザクション、複数のトークンを結合するトランザクション、トークンを分割するトランザクションなどを発行する。
【００２７】
履歴検索部１４は、自身の分散台帳１１のステートDBからトークンが更新されたブロックの更新ブロック番号を含む追跡データを取得し、更新ブロック番号から算出される検索ブロック番号を指定して、検索ブロック番号の時点のブロックにおけるトークンのステートおよび追跡データをステートDBから取得する。履歴検索部１４は、ブロックチェーン制御部１２を介して、分散台帳１１にアクセスする。
【００２８】
承認端末２は、例えばマイナーと呼ばれるトランザクションの検証者が使用する端末であって、ネットワーク４に送信されたトランザクションを収集し、正当性を確認後に、承認作業を通じてブロックを生成する。承認端末２は、分散台帳１１と、ブロックチェーン制御部１２と、トランザクション発行部１３と、ブロック発行部１５とを備える。承認端末２の分散台帳１１、ブロックチェーン制御部１２およびトランザクション発行部１３は、利用者端末１の分散台帳１１、ブロックチェーン制御部１２およびトランザクション発行部１３と同様である。
【００２９】
ブロック発行部１５は、ネットワーク４上に発行されたトランザクションを検証し、Proof of Workなどのブロック生成のためのコンセンサスアルゴリズム（合意アルゴリズム）に従い、ブロックの生成を試みる。
【００３０】
図２は、承認端末２が備えるブロック発行部１５の構成を示す構成図である。図示するブロック発行部１５は、コンセンサス実行部１５１と、トランザクション検証部１５２と、ブロック生成部１５３と、更新部１５４とを備える。
【００３１】
コンセンサス実行部１５１は、ハッシュ演算などコンセンサス（合意）に必要な計算を実施する。コンセンサスアルゴリズムは、ビットコインで用いられているProof of Work以外にも、所持コイン量をリソースとしたProof of Stake、ビザンチン故障における合意アルゴリズムであるPBFTなど、その他のブロック生成のためのコンセンサスアルゴリズムを用いても良い。
【００３２】
トランザクション検証部１５２は、ネットワーク４よりトランザクションを受け取ると、受け取ったトランザクションの電子署名の正当性などのトランザクションの検証を行う。  
【００３３】
ブロック生成部１５３は、所定の時間内にネットワーク４上で発行されたトランザクションをまとめて１つのブロックを生成する。すなわち、ブロック生成部１５３は、トランザクション検証部１５２による検証に成功した場合、当該トランザクションを含むブロックを生成し、ネットワーク４に接続される全ての端末の分散台帳１１に生成したブロックを反映させる。
【００３４】
本実施形態のブロック生成部１５３は、トークンを更新するトランザクションを含むブロックを生成し、当該ブロックおよび更新部１５４により更新されたステートDBを分散台帳１１に反映させる。また、ブロック生成部１５３は、更新後のステートDBのハッシュ値を、生成するブロックのブロックヘッダに設定する。
【００３５】
更新部１５４は、トークンを更新するトランザクションに基づいて、自身の分散台帳１１のデータ集合の１つであるステートDBを更新する。本実施形態では、更新部１５４は、ステートDBのトークンに、当該トークンを更新したブロックの更新ブロック番号と、当該トークンのトークン情報とを含む追跡データを設定する。本実施形態のトークン情報には、トークンのＩＤと、トークンのスマートコントラクトのアドレスとを含む。
【００３６】
また、更新部１５４は、複数のトークンを結合した結合トークンに、結合トークンを生成したブロックのブロック番号と、結合元の複数のトークンのトークンＩＤおよびスマートコントラクトのアドレスとを、追跡データとして設定する。また、更新部１５４は、分割された分割トークンに、分割トークンを生成したブロックのブロック番号と、分割元のトークンのトークンＩＤおよびスマートコントラクトのアドレスとを、追跡データとして設定する。
【００３７】
また更新部１５４は、ステートDBの結合元の複数の前記トークン、または、分割元のトークンに消費済であることを示す消費フラグを設定する。
【００３８】
図３は、各端末の分散台帳１１の構成を示す。本実施形態の分散台帳１１は、複数のブロック１１１から構成されるブロックチェーンと、各ブロックに対応して管理されるデータ集合１１２とを備える。
【００３９】
ブロック１１１は、ブロックヘッダ１１３、トランザクションリスト１１４などを有する。ブロックヘッダ１１３には、当該ブロックの時点の分散台帳１１全体の要約が設定される。図示する例では、ブロックヘッダ１１３には、データ集合１１２のある時点のスナップショットとして、データ集合１１２の要約値（ステートDBのハッシュ値、トランザクション集合のハッシュ値など）が設定される。例えば、データ集合がマークルツリーなどのツリー構造で格納されている場合、要約値として、マークルツリーのルートハッシュが設定される。トランザクションリスト１１４は、当該ブロック１１１に含まれるトランザクションのリストである。 
【００４０】
データ集合１１２は、その用途および目的は限定されない。図示する分散台帳１１では、データ集合１１２として、ステートDBと、トランザクション集合DBとを備える。
【００４１】
ステートDBは、あるブロックの時点でのスマートコントラクトのステートの値または状態を管理するためのDBである。また、ステートDBには、スマートコントラクトのバイトコードが格納される。本実施形態では、トークンというデータ単位でステートDBに情報が記録されている。ここでトークンとはスマートコントラクトで表現されるデータ構造であり、ブロックチェーン上で管理されるデータを示す。すなわち、本実施形態のステートDBは、スマートコントラクトのステートをトークン毎に記憶する。
【００４２】
また、本実施形態のステートDBは、承認端末２の更新部１５４により、トークン毎に、トークンが更新されたブロックの更新ブロック番号を含む追跡データが設定される。ステートDBは、Key-Value Store(KVS)として機能し、トークンを一意に指定する識別情報（例えば、トークンID）が入力されると、当該トークンのステートの値および追跡データを出力する。
【００４３】
なお、Ethereumでは、スマートコントラクトのバイトコードを、分散台帳１１（ステートDB）に登録すると、当該スマートコントラクトを示す識別情報が付与される。識別情報に対して、トランザクションを送信することができるため、スマートコントラクトの識別情報はアドレスとも呼ばれる。ユーザのアドレスへの送金との違いは、スマートコントラクトのアドレス宛てにトランザクションを送信すると、当該スマートコントラクトが実行されることである。
【００４４】
トランザクション集合DBは、あるブロックの時点でのトランザクションの集合を示すDBである。トランザクションの集合は、あるブロックの時点での全てのトランザクションによって構成されるマークルツリーを意味する。
【００４５】
（トークンのステートの遷移）
図４は、本実施形態におけるトークンの遷移を示す遷移図の例である。
【００４６】
本実施形態のトークンは、ステートの更新だけでなく、トークンの分割およびトークンの結合が可能なトークンである。トークンの分割は、１つのトークンを複数のトークンに分割することである。トークンの分割には、分割元のトークンを分割して新たな複数のトークンを生成し、分割元のトークンは消費される場合と、分割元のトークンの一部を新たなトークンに切り出し、分割元のトークンは一部のみ消費されて存続する場合とがある。トークンの結合は、複数のトークンを１つのトークンに結合することである。
【００４７】
したがって、本実施形態のトークンの遷移は、図示するようにDAG（Directed acyclic graph：有向非巡回グラフ）を用いて、表現することができる。DAGは、グラフ理論における閉路のない有向グラフである。
【００４８】
図示する例では、各トークンの追跡データを、Si（更新ブロック番号、トークンID、コントラクトアドレス）で表している。追跡データについては、後述する。i=1,…,Nは、異なる一意のステートの追跡データであることを示す添字である。例えば、S2のトークンでは、更新ブロック番号は「1699」、トークンIDは「5」、コントラクトアドレスは「0xA6214...」であることを示している。また、S4のトークンは、S2のトークンから分割されトークンである。S6のトークンは、S5のトークンとS3のトークンとが結合したトークンである。
【００４９】
（追跡データの設定）
次に、承認端末２が、ステートDBのトークンを更新する際に、当該トークンの履歴を追跡するための追跡データをステートDBに設定する処理を説明する。本実施形態では、トークンの更新には、ステートの更新だけでなく、他のトークンとの結合および分割も含まれる。そのため、本実施形態の追跡データは、トークンを更新した更新時点のブロックの更新ブロック番号と、トークンIDと、スマートコントラクトのアドレス（以下、「コントラクトアドレス」）とを含む。
【００５０】
これにより、１つのスマートコントラクト内の同じIDのトークンの履歴を追跡できるだけでなく、関連する他のスマートコントラクトの他のIDのトークンもついても紐付けが可能となり、複数のスマートコントラクト間のトークンの履歴を追跡することができる。
【００５１】
以下に、トークンの更新について、ステートの更新、トークンの結合、トークンの分割の３つのケースについて説明する。
【００５２】
１．ステートの更新
図５は、トークンのステート（状態、変数）を更新する場合において、追跡データをトークン（または、ステート）に付与する処理を説明するための模式図である。図示する例では、木材から家具を製作する過程で、木材のトークンのステートの更新について説明する。
【００５３】
分散台帳１１には、前述のとおり、ブロックと、ステートDBとが対応付けて保持されている。ステートDBは、スマートコントラクト毎に、トークンのステートを管理する。図５は、ステートDBに保持されるトークン管理コントラクトのステートテーブル５１Ａ、５１Ｂを示す。トークン管理コントラクトは、木材のトークンを管理するスマートコントラクトである。ステートテーブル５１Ａは、ブロック（#24768）のステートテーブルである。ステートテーブル５１Ｂは、ブロック（#25007）のステートテーブルである。
【００５４】
ステートテーブル５１Ａ、５１Ｂは、トークン毎に、トークンIDと、ステートデータと、消費フラグと、追跡データとを有する。本実施形態では、ステートのキーとしてトークンIDを用いるが、ステートのキーはトークンIDに限定されない。また、トークンは、代替不可能なトークン（Non-Fungible Token）であっても、代替可能なトークン（Fungible Token）であってもよい。
【００５５】
ステートデータは、ステートを示すデータであって、図示する例では所有者アドレスと、ロット数とが含まれる。所有者アドレスには、対応するブロックの時点における、トークンの所有者のアドレスが設定される。ロット数には、トークンが示す対象（ここでは木材）の製造または発注の単位が設定される。
【００５６】
消費（Consumed）フラグは、トークンが消費されたか否かを示すフラグである。トークンが結合または分割される場合には、元のトークンは消費され、消費フラグがTrue（消費済み）となる。トークンが結合および分割されていない場合には、トークンは消費されていなく、消費フラグはFalse（未消費）である。
【００５７】
追跡データは、トークンの履歴を追跡するためのデータ（追跡用データ）である。本実施形態の追跡データには、更新ブロック番号、トークンID、コントラクトアドレスが含まれる。更新ブロック番号には、ステートデータを更新したブロック番号が設定される。ここでは、ステートデータの少なくとも１つが更新された場合、更新ブロック番号には更新したブロックのブロック番号が設定される。
【００５８】
ブロック#24768のステートテーブル５１では、トークンID：1005のステートデータは、所有者は「0x13ae・・・」で、ロット数は「5」で、消費フラグは「False」（未消費）で、追跡データは、更新ブロック番号が「23027」で、トークンIDが「1005」で、コントラクトアドレスが「0xA6214・・・」である。
【００５９】
ブロック#24769〜#25006では、これらのブロックに含まれるトランザクションにより、トークンID：1005のステートデータは更新されないものとする。この場合、承認端末２は、図示しないブロック#24769〜#25006の各ステートテーブルにおけるトークンID：1005に、直前のブロックのステートテーブルのステートデータ、消費フラグおよび追跡データを引き続き設定する。すなわち、ブロック#24769〜#25006の各ステートテーブルにおけるトークンID：1005のデータは、ブロック#24768のステートテーブル５１Ａ のトークンID：1005のデータと同じである。
【００６０】
そして、ブロック#25007に含まれるトランザクションにより、トークンID：1005のステートデータ（所有者アドレス、ロット数）が更新される。この場合、承認端末２は、トークンID：1005のステートデータを更新するとともに、追跡データを更新する。具体的には、承認端末２は、当該ブロックのブロック番号（#25007）を、更新ブロック番号に設定する。また、承認端末２は、更新されたトークンのID（1005）、更新されたトークンのコントラクトアドレス（0xA6214…）を、追跡データに設定する。
【００６１】
このように、本実施形態では、キー（トークンID）に対するステート（ステートデータ）とともに、追跡データを設定する。これにより、本実施形態では、利用者端末１は、最新のブロック#25009のステートテーブルを参照すると、直近で更新が発生したブロックを示す追跡データを取得することができる。例えば、トークンID：1005の場合は、更新ブロック番号として#25007を取得することができる。
【００６２】
そして、利用者端末１は、更新ブロック番号から算出される検索ブロック番号を指定して、検索ブロック番号で指定されたステートデータおよび追跡データの更新ブロック番号を取得する。例えば、検索ブロック番号は、更新ブロック番号から１減算したブロック番号とする。トークンID：1005の場合、更新ブロック番号#25007から１減算した検索ブロック番号＃25006を指定して当該ブロック番号に設定されたステートデータおよび追跡データの更新ブロック番号（#23027）を取得する。このように、本実施形態では、ステートの値に変更があったブロックの付近のブロックのみを辿ることで、探索コストを大幅に低減し、容易にステートの値の変更履歴を取得することができる。
【００６３】
２．トークンの結合
図６は、複数のトークンを結合する場合において、追跡データをトークン（または、ステート）に付与する処理を説明するための模式図である。図示する例では、木材から家具を製作する過程で、木材トークンと接着剤トークンとを結合して、家具トークンを生成する結合について説明する。ここでは、前述した「１．ステートの更新」と異なる点を中心に説明する。
【００６４】
ステートDBは、スマートコントラクト毎に、トークンのステートを管理する。図６および図７では、木材のトークン管理コントラクトのステートテーブル６１Ａ、６１Ｂと、接着剤のトークン管理コントラクトのステートテーブル６２Ａ、６２Ｂと、家具のトークン管理コントラクトのステートテーブル６３と、を示している。
【００６５】
ステートテーブル６１Ａ、６１Ｂは、ブロック#25768のステートテーブルである。ステートテーブル６１Ｂ、６２Ｂ、６３は、ブロック#25999のステートテーブルである。ステートテーブルは、前述のとおり、トークン毎に、トークンIDと、ステートデータと、消費フラグと、追跡データとを有する。
【００６６】
例えば、木材のステートテーブル６１Ａでは、トークンID：1005のステートデータは、所有者は「0x92be・・・」で、ロット数は「10」で、消費フラグは「False」（未消費）で、追跡データは、更新ブロック番号が「25007」で、トークンIDが「1005」で、コントラクトアドレスが「0xA6214・・・」である。
【００６７】
接着剤のステートテーブル６２Ａでは、トークンID：0177のステートデータは、所有者は「0x12ac・・・」で、ロット数は「100」で、消費フラグは「False」（未消費）で、追跡データは、更新ブロック番号が「10283」で、トークンIDが「0177」で、コントラクトアドレスが「0xBE823・・・」である。
【００６８】
ブロック#25769〜#25998では、これらのブロックに含まれるトランザクションにより、ステートテーブル６１ＡのトークンID：1005のステートデータ、および、ステートテーブル６２ＢのトークンID：0177のステートデータは、更新されないものとする。この場合、承認端末２は、図示しないブロック#25769〜#25998の各ステートテーブルのトークンID：1005に、直前のブロックのステートテーブルのトークンID：1005のデータを引き続き設定する。すなわち、ブロック#25769〜#25998の各ステートテーブルにおけるトークンID：1005のデータは、ブロック#25768のステートテーブル６１Ａ のトークンID：1005のデータと同じである。
【００６９】
接着剤のステートテーブルについても同様に、ブロック#25769〜#25998の各ステートテーブルにおけるトークンID：0177のデータは、ブロック#25768のステートテーブル６１Ｂ のトークンID：0177のデータと同じである。
【００７０】
そして、ブロック#25999に含まれるトランザクションにより、ステートテーブル６１Ａのトークン（ID：1005）と、ステートテーブル６２Ａのトークン（ID：0177）とが結合され、家具トークンが生成される。
【００７１】
この場合、承認端末２は、木材トークンおよび接着剤トークンを結合した新たな家具トークンのデータを生成し、ブロック#25999の接着剤のステートテーブル６３に設定する。具体的には、承認端末２は、家具トークンのトークンIDには所定のID：0016を設定し、ステートデータにはトランザクションで指定された値を設定し、消費フラグには「False」（未消費）を設定し、追跡データには結合される木材トークン（ID：1005）および接着剤トークン（ID：0177）の２つの情報を設定する。
【００７２】
ここでは、木材トークンの追跡データとして、承認端末２は、家具トークンを生成した当該ブロックの更新ブロック番号（#25999）と、木材トークンのトークンID（1005）と、木材トークンのコントラクトアドレス（0xA6214・・・）とを設定する。接着剤トークンの追跡データとして、承認端末２は、家具トークンを生成した当該ブロックの更新ブロック番号（#25999）と、接着剤トークンのトークンID（0177）と、接着剤トークンのコントラクトアドレス（0xBE823・・・）とを設定する。
【００７３】
また、承認端末２は、ブロック#25999の結合元のトークンのステートテーブル６１Ｂ、６２Ｂを更新する。図７に示すように、承認端末２は、ステートテーブル６１Ｂの結合元の木材トークン（ID：1005）の消費フラグを「False」（未消費）から「True」（消費済み）に更新する。同様に、承認端末２は、ステートテーブル６２Ｂの結合元の接着剤トークン（ID：0177）の消費フラグを「False」から「True」に更新する。トークンが結合されることにより、結合元のトークンは消費され、消費フラグが「True」となる。結合トークン（家具トークン）は、結合元のトークンとは異なるスマートコントラクトに属し、異なるトークンIDを持つ。
【００７４】
また、承認端末２は、消費フラグを「True」に更新した場合、消費先（結合先）のトークン情報を消費フラグに設定する。本実施形態では、トークン情報は、コントラクトアドレスと、トークンIDとを含む。
【００７５】
また、承認端末２は、消費フラグを「True」に更新した場合、追跡データの更新ブロック番号を、消費（結合）されたブロック番号に更新してもよい。図７では、ステートテーブル６１Ｂの結合元の木材トークン（ID：1005）、および、ステートテーブル６２Ｂの結合元の接着剤トークン（ID：0177）の追跡データの更新ブロック番号には、消費フラグを更新したブロック番号（#25999）が設定されている。これにより、利用者は、消費フラグが「True」に更新されたブロックを、容易に知ることができる。
【００７６】
なお、消費フラグが「True」に更新されたトークンは、これ以降のブロックで、更新、結合および分割が行われず、したがって、当該トークの情報はこれ以降更新されない。
【００７７】
３．トークンの分割
図８は、トークンの分割において、追跡データをステートの値に付与する処理を説明するための模式図である。図示する例では、コンテンツの著作権から、一部の演奏権を切り出し、著作権を分割するケースについて説明する。ここでは、前述した「１．トークンの更新」および「２．トークンの結合」と異なる点を中心に説明する。
【００７８】
図示する例では、各ブロックに対応するステートDBは、「著作権」トークンを管理するトークン管理コントラクトのステートテーブル８１Ａ、８１Ｂと、「演奏権」トークンを管理するトークン管理コントラクトのステートテーブル８２とを示している。
【００７９】
ステートテーブル８１Ａは、ブロック#25768のステートテーブルである。ステートテーブル８１Ｂ、８２は、ブロック#25999のステートテーブルである。ステートテーブルは、前述のとおり、トークン毎に、トークンIDと、ステートデータと、消費フラグと、追跡データとを有する。
【００８０】
ブロック#25769〜#25998では、これらのブロックに含まれるトランザクションにより、ステートテーブル８１ＡのトークンID：40のステートデータは、更新されないものとする。この場合、承認端末２は、図示しないブロック#25769〜#25998の各ステートテーブルのトークンID：40に、直前のブロックのステートテーブルのトークンID：40のデータを引き続き設定する。すなわち、ブロック#25769〜#25998の各ステートテーブルにおけるトークンID：40のデータは、ブロック#25768のステートテーブル８１Ａ のトークンID：40のデータと同じである。
【００８１】
そして、ブロック#25999に含まれるトランザクションにより、著作権トークン（ID：40）から、著作権の一部の演奏権が切り出され、演奏権トークンとして分割される。この場合、承認端末２は、分割による新たな演奏権トークンを生成し、ブロック#25999の演奏権のステートテーブル８２に設定する。
【００８２】
具体的には、承認端末２は、演奏権トークンのトークンIDには所定のID：99を設定し、ステートデータにはトランザクションで指定された値を設定し、消費フラグには「False」（未消費）を設定し、追跡データには分割元の著作権トークン（ID：40）の情報を設定する。ここでは、承認端末２は、演奏権トークンを生成した当該ブロックの更新ブロック番号（#25999）と、著作権トークンのトークンID（40）と、著作権トークンのコントラクトアドレス（0xB7342・・・）とを、追跡データとして設定する。
【００８３】
また、承認端末２は、ステートテーブル８１Ｂの分割元の著作権トークン（ID：40）の消費フラグを、「True(一部消費)」に更新する。また、承認端末２は、消費フラグを「True（一部消費）」に更新した場合、消費先（分割先）のトークン情報を消費フラグに設定し、消費先と関連付ける。本実施形態では、トークン情報は、コントラクトアドレスと、トークンIDとを含む。
【００８４】
（ブロックの生成およびトークンの履歴検索）
図９は、本実施形態のブロック生成および履歴検索を示すシーケンス図である。
【００８５】
図示する処理では、利用者Ａがトークンを更新（結合および分割を含む）するトランザクションを発行し、利用者Ｂが利用者Ａにより更新されたトークンの履歴を探索する処理を示す。
【００８６】
利用者Ａの利用者端末１Ａは、例えば、所定のトークンを利用者Ａから利用者Ｂに移動するためのトランザクションを生成し、を発行する（Ｓ１１）。具体的には、利用者端末１Ａはトランザクションをネットワーク４上にブロードキャストする。これにより、トランザクションは、ネットワーク４に接続された全ての端末に伝搬される。
【００８７】
図１０は、Ｓ１１のトランザクションの一例を示す図である。図示するトランザクションは、宛先と、支払額と、データと、電子署名とを有する。宛先には、スマートコントラクトのアドレス（コントラクトアドレス）が設定される。支払額には、スマートコントラクトを実行するために支払われる金額（手数料）が設定される。
【００８８】
データには、例えば、スマートコントラクト内の「指定されたアドレスへ所定のトークンの所有権を移動する」機能を提供する関数を実行することを指定するデータが設定される。なお、引数としてトークンのIDと、移動先の利用者のアドレス等を指定する。電子署名には、トランザクションの発行者である利用者Ａの秘密鍵で当該トランザクションが署名された署名値が設定される。
【００８９】
そして、承認端末２（ブロック発行部１５）は、Ｓ１１で送信されたトランザクションを検証（マイニング）する（Ｓ１２）。そして、承認端末２は、当該トランザクションを、所定の時間内に発生した他のトランザクションとまとめて１つのブロックを生成する。当該ブロックは、ナンスのマイニングを経て自身の分散台帳１１のブロックチェーンに追加される（Ｓ１３）。承認端末２がブロックの生成に成功することにより、Ｓ１１で送信されたトランザクションが確定（承認）される。
【００９０】
ここで、承認端末２は、Ｓ１１のトランザクションに基づいて、自身の分散台帳１１のデータ集合の各DBを更新し、更新後の各DBのハッシュ値を、生成するブロックのブロックヘッダに設定する。
【００９１】
また、承認端末２は、データ集合のステートDBを更新する際に、Ｓ１１のトランザクションに従って、指定されたトークンを更新する。すなわち、承認端末２は、トークンのステートデータを変更、トークンを結合、または、トークンを分割する。また、本実施形態では、承認端末２は、トークンを更新した当該ブロックのブロック番号、トークンID、コントラクトアドレスを含む追跡データを、ステートDBに記憶する。
【００９２】
そして、承認端末２は、更新後のステートDBのハッシュ値を、生成するブロックのブロックヘッダに設定する。なお、Ｓ１３は、ネットワークに接続された全ての端末のうち、最も早くブロックの生成に成功した端末によって行われる処理である。
【００９３】
そして、端末間のゆるやかな同期により、Ｓ１１で送信されたトランザクションを含むブロックが、ネットワーク４に接続された全ての端末の分散台帳１１に反映される（Ｓ１４、Ｓ１５）。すなわち、全ての端末のブロックチェーン制御部１２は、自身が保持する分散台帳１１に、Ｓ１１のトランザクションを含むブロックを追加する。また、全ての端末のブロックチェーン制御部１２は、承認端末２と同様に、ブロックに含まれるトランザクションに基づいて、自身の分散台帳１１のデータ集合のステートDBを更新する。
【００９４】
次に、利用者Ｂが、利用者Ａが更新したトークンの過去の履歴を探索する場合、Ｓ１６以降の処理を行う。具体的には、利用者端末１Ｂは、最新のブロックにおける、前記トークンのステートデータを、自身の分散台帳に問合せ（Ｓ１６）、分散台帳から最新のブロックのステートデータと、追跡データとを取得する（Ｓ１７）。
【００９５】
例えば、最新ブロックが図５に示す#25009で、問い合わせ対象のトークンIDが1005の場合、利用者端末１Ｂは、自身の分散台帳のステートDB５１Ｂを参照し、ステートデータと、更新ブロック番号#25007を含む追跡データとを取得する。これにより、利用者Ｂは、現在のトークンのステートの値と、また、当該トークンの更新が#25007のブロックで行われたことを確認することができる。
【００９６】
そして、利用者Ｂは、当該トークンの過去の履歴を検索したい場合、Ｓ１８からＳ２０の処理を繰り返し行う。すなわち、利用者端末１Ｂは、Ｓ１７の追跡データから検索ブロック番号と、検索したいトークンのコントラクトアドレスおよびトークンIDとを取得する（Ｓ１８）。
【００９７】
具体的には、利用者端末１Ｂは、取得した更新ブロック番号に基づいて検索ブロック番号を算出する。ここでは、更新ブロック番号から「１」減算したブロック番号を検索ブロック番号とする。そして、利用者端末１Ｂは、検索ブロック番号と、コントラクトアドレスと、トークンIDとを指定し、検索ブロック番号における、指定したトークンのデータを自身の分散台帳に問合せ（Ｓ１９）、指定したブロックにおける指定したトークンのステートデータと、追跡データとを分散台帳から取得する（Ｓ２０）。
【００９８】
例えば、図５のステートDBにおいて、Ｓ１７取得した更新ブロック番号が#25007でトークンIDが1005の場合、利用者端末１Ｂは、#25007から「1」減算した検索ブロック番号#25006を指定して、分散台帳に問い合わせる。#25006のステートDBは、図５に示していないが、トークンID：1005に対する更新は#24769から#25006までは行われていないため、トークンID：1005に関する#25006のステートは、#24768のステートDB５１Ａと同じである。したがって、利用者端末１Ｂは、#25006のステートDBを参照し、ステートデータ、および、更新ブロック番号#23027を含む追跡データを取得する。
【００９９】
そして、利用者端末１Ｂは、それ以前の過去の履歴を検索したい場合は、Ｓ１８からＳ２０の処理を繰り返し行う。これにより、利用者Ｂは、トークンの過去の履歴を効率よく辿ることができる。
【０１００】
また、本実施形態の追跡データには、更新ブロック番号だけでなく、トークンIDおよびコントラクトアドレスも含まれる。これにより、本実施形態では、トークンが結合または分割されて、検索したいトークンが異なるスマートコントラクトの異なるトークンIDに変更された場合であっても、トークンの履歴を効率よく追跡することができる。
【０１０１】
次に、追跡データの消費フラグを用いたトークンの検索について説明する。
【０１０２】
ここでは、利用者が、あるトークンの結合先である結合トークン（消費先のトークン）の現在のステートを、消費フラグを用いて探索する処理を説明する。
【０１０３】
例えば、利用者端末１は、図７に示す木材のステートテーブル６１Ｂのトークン（ID:1005）の消費フラグを取得している場合、当該トークンの結合先である結合トークンを、消費フラグに設定されたコントラクトアドレス（0x2A119・・・）と、トークンID（0015）とを指定して、最新のブロックの指定したトークンのデータを自身の分散台帳に問合せ、分散台帳から最新のブロックの当該トークンのステートデータと、追跡データとを取得する。これにより、利用者は、所望のトークンの現在のステートを取得することができる。
【０１０４】
例えば、最新ブロックが図６に示す#26001の場合、利用者端末１Ｂは、自身の分散台帳の最新のブロックの家具のステートテーブル（#25999のステートテーブル６３と同じ）から、ステートデータと、追跡データとを取得する。これにより、利用者は、木材のトークン（ID:1005）の結合先である結合トークン（ID：0016）の現在のステートデータ（所有者、ロット数）を確認することができる。また、利用者が結合トークン（ID：0016）の過去の履歴を検索したい場合は、図９に示すＳ１６からＳ２０の処理を行うことで過去の履歴を取得することができる。
【０１０５】
利用者が、あるトークンの分割先である分割トークン（消費先のトークン）の現在のステートを、消費フラグを用いて探索する処理についても、結合トークンの処理と同様である。
【０１０６】
以上説明した本実施形態では、利用者端末１と、承認端末２とを備えるブロックチェーンシステムであって、ブロックチェーンシステムの分散台帳１１は、スマートコントラクトのステートをトークン毎に記憶するステートDBを有し、利用者端末１は、  トークンを更新するトランザクションを発行するトランザクション発行部１３を備え、承認端末２は、ステートDBのトークンを更新する更新部１５４と、トランザクションを含むブロックを生成し、当該ブロックおよび更新後のステートDBを分散台帳１１に反映させるブロック生成部１５３とを備え、更新部１５４は、ステートDBのトークンに、トークンを更新したブロックの更新ブロック番号と、トークンのＩＤと、トークンのコントラクトアドレスとを含む追跡データを設定する。
【０１０７】
このように、本実施形態では、各端末の分散台帳１１のステートDBには、トークンが更新された時点で、更新のあったブロックの更新ブロック番号、トークンIDおよびコントラクトアドレスを含む追跡データを、更新されたトークンに付与する。これにより、利用者は、更新ブロック番号を辿ることで、過去の全てのブロックおよびトランザクションを参照することなく、分散台帳（ブロックチェーン）上で、トークンの履歴を容易に追跡することができる。すなわち、本実施形態では、スマートコントラクトのステートの過去の履歴および変遷を、外部データベースやインデックスDBを保持することなく、容易および高速に取得することができる。
【０１０８】
また、本実施形態の追跡データは、トークンを更新したブロックの更新ブロック番号と、トークンのＩＤと、トークンのスマートコントラクトのアドレスとを含む。これにより、本実施形態では、トークンのステートの「更新」だけでなく、他のトークンとの「結合」および「分割」についても、トークンの履歴を容易に追跡することができる。すなわち、同じスマートコントラクト内の同じトークンIDのトークンの履歴を追跡するだけでなく、別のスマートコントラクトおよび別のトークンIDのトークンについても紐付けが可能となり、履歴を追跡することができる。したがって、本実施形態では、結合または分割などの複雑なトークンの更新が行われている場合であっても、トークンの履歴を追跡でき、追跡経路を表現することができる。
【０１０９】
また、本実施形態では、承認端末２は、トークンに消費フラグおよび消費先のトークンの情報を設定する。これにより、本実施形態では、結合または分割により消費されたトークンの消費先のトークンのステートを取得することができる。
【０１１０】
また、本実施形態では、スマートコントラクトの利用者に対して、トレーサビリティを向上することができる。従来のステートDBでは、過去のどのブロックでステートの値が更新または変更されたかの情報は保持されていなく、ステートの値がどのブロックの時点で遷移したのかを利用者は知ることは容易ではない。従来では、変更のあったブロック番号を知るためには、全てのブロックまたはトランザクションを探索する必要があり、利用者にとって大きな負荷となっていた。これに対して、本実施形態では、ステートDBにステートの値の変化点として、ブロック生成時点（採掘時点）のブロック番号を含む追跡データを、追跡したいステートの値に付加することで、当該ステートのトレーサビリティを向上することができる。
【０１１１】
なお、上記説明した利用者端末１および承認端末２は、例えば、CPU（Central Processing Unit、プロセッサ）と、メモリと、ストレージ（HDD：Hard Disk Drive、SSD：Solid State Drive）と、通信装置と、入力装置と、出力装置とを備える汎用的なコンピュータシステムを用いることができる。このコンピュータシステムにおいて、CPUがメモリ上にロードされた所定のプログラムを実行することにより、各装置の各機能が実現される。例えば、利用者端末１および承認端末２の各機能は、利用者端末１用のプログラムの場合は利用者端末１のCPUが、承認端末２用のプログラムの場合は承認端末２のCPUが、それぞれ実行することにより実現される。
【０１１２】
また、利用者端末１用のプログラムおよび承認端末２用のプログラムは、HDD、SSD、USBメモリ、CD-ROM、DVD-ROM、MOなどのコンピュータ読取り可能な記録媒体に記憶することも、ネットワークを介して配信することもできる。
【０１１３】
また、本発明は上記実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。
【０１１４】
例えば、本実施形態では、承認端末２は、更新ブロック番号として、ステートの値が更新されたブロックのブロック番号を更新ブロック番号としてステートDBに設定した。しかしながら、更新ブロック番号の代わりに、検索用ブロック番号をステートDBに設定することとしてもよい。すなわち、承認端末２は、更新ブロック番号の代わりに、更新ブロック番号から「１」減算した検索ブロック番号をステートDBに設定することとしてもよい。この場合、利用者端末１は、ステートの過去の履歴を取得する際（図９のＳ１８）に、更新ブロック番号から検索ブロック番号を算出することなく、分散台帳から取得した検索ブロック番号をそのまま用いて、過去の履歴を辿ることができる。
【０１１５】
また、本実施形態のステートDB（ステートテーブル）は、消費フラグを備えることとしたが、ステートDB（ステートテーブル）は、消費フラグを備えなくてもよい。
【符号の説明】
【０１１６】
１  ：利用者端末
２  ：承認端末
１１：分散台帳
１２：ブロックチェーン制御部
１３：トランザクション発行部
１４：履歴検索部
１５：ブロック発行部
１５１：コンセンサス実行部
１５２：トランザクション検証部
１５３：ブロック生成部
１５４：更新部
４  ：ブロックチェーンネットワーク
【図１】
2020170296.tif 000003
【図２】
2020170296.tif 000004
【図３】
2020170296.tif 000005
【図４】
2020170296.tif 000006
【図５】
2020170296.tif 000007
【図６】
2020170296.tif 000008
【図７】
2020170296.tif 000009
【図８】
2020170296.tif 000010
【図９】
2020170296.tif 000011
【図１０】
2020170296.tif 000012