JP2020170342A - 分散台帳装置、分散台帳システム、及び分散台帳管理方法 - Google Patents

Abstract

【課題】或る分散台帳装置における分散台帳に対する運用処理の状況を、他の分散台帳装置で容易且つ適切に確認できるようにする。【解決手段】所定の対象のトランザクションについての分散台帳７００を管理する複数のＢＣノード３００を備えるＢＣシステムにおけるＢＣノード３００において、ＢＣノード３００は、記憶デバイス３３０と、プロセッサ３１０とを備え、記憶デバイス３３０は、分散台帳７００を記憶し、プロセッサ３１０を、分散台帳７００に関わる処理を実行した場合に、処理の内容を示す内容情報を、分散台帳７００を管理する他のＢＣノードで管理させるために送信するように構成する。プロセッサ３１０を、分散台帳７００を管理する複数のＢＣノードが管理する他の分散台帳に内容情報を登録させる指示を送信するようにしてもよい。【選択図】図３

Description

本発明は、分散台帳を管理する技術に関する。

ブロックチェーン（ＢＣ）は、複数の主体者間で共有される分散システムを実現する技術である。ＢＣシステム上では、主体者間で合意のとられたトランザクションのみを受領し、トランザクションにより生成・更新されたデータを主体者間で複製・保持し、またトランザクションの履歴をブロックチェーンと呼ばれる改竄困難なデータ構造に格納する。ＢＣ技術の適用により，利用者は中央集権機関の介在なしに、利用者間での取り引きやデータの共有を可能とするシステムが構築可能となるため、取り引きの迅速化やコスト低減が見込まれ、金融や産業などの多くの分野での活用が期待される。

ＢＣシステムでは、参加する主体者がそれぞれにシステムを構成するノード（分散台帳装置）を提供するために、ノードにより管理者が異なってくる。そのため、こうした複数主体者間で共有されるシステムでは、システム全体でのデータの保有状況を管理することが難しい。例えば、システムに参加するノードからデータバックアップを行うケースでは、参加ノードに対し管理者がそれぞれにバックアップを実施するため、全バックアップデータから個人情報を削除することが難しくなる。近年では、法制度により利用者にシステム上からの個人情報の削除を請求する権利が認められているため、ＢＣシステムにおいても確実にデータ削除を遂行できる仕組みが必要になる。

ＢＣシステムの参加ノード間でポリシーやタイミングを揃えて運用処理を実施する技術が特許文献１に開示されている。特許文献１に記載の技術では、運用オペレーションをＢＣシステムのトランザクションとして扱うことで、ノード間で合意形成しながら統一的なポリシーやタイミングでのオペレーション実行を可能とする。

特開２０１９−２８５２５号公報

例えば、特許文献１に記載の技術をデータ削除の処理へ適用することで、複数の主体者がそれぞれに管理するノードでタイミングをそろえたデータ削除の実施要求が可能となる。しかしながら、特許文献１の技術においては、ＢＣシステムの参加ノードに対して統一的なポリシーでのデータ削除要求が可能だが、例えば、参加ノードにおいて、すべてのバックアップデータが確実に削除されたかを他のノードにおいて確認することは困難である。また、データ削除の処理に限らず、参加ノードが個別に行った処理について、他のノードが確認等することは困難である。

本発明は、上記事情に鑑みなされたものであり、その目的は、或る分散台帳装置における分散台帳に対する運用処理の状況を、他の分散台帳装置で容易且つ適切に確認できるようにする技術を提供することにある。

上記目的を達成するため、一観点に係る分散台帳装置は、所定の対象のトランザクションについての第１分散台帳を管理する複数の分散台帳装置を備える分散台帳システムにおける分散台帳装置であって、分散台帳装置は、記憶デバイスと、プロセッサ部とを備え、記憶デバイスは、第１分散台帳を記憶し、プロセッサ部は、第１分散台帳に関わる処理を実行した場合に、処理の内容を示す内容情報を、第１分散台帳を管理する他の分散台帳装置で管理させるために送信する。

本発明によれば、或る分散台帳装置における分散台帳に対する運用処理の状況を、他の分散台帳装置で容易且つ適切に確認できるようになる。

図１は、一実施形態の概要を説明する図である。 図２は、一実施形態に係るブロックチェーン（ＢＣ）システムの全体構成図である。 図３は、一実施形態に係るＢＣノードと、ストレージとの構成図である。 図４は、一実施形態に係る分散台帳の第１の構成例を示す図である。 図５は、一実施形態に係る分散台帳の第２の構成例を示す図である。 図６は、一実施形態に係るスマートコントラクト管理テーブルの構成図である。 図７は、一実施形態に係るシステム構成管理テーブルの構成図である。 図８は、一実施形態に係る周辺コンポーネント管理テーブルの構成図である。 図９は、一実施形態に係る運用処理ステップ管理テーブルの構成図である。 図１０は、一実施形態に運用処理ステップ遷移管理テーブルの構成図である。 図１１は、一実施形態に係る運用トランザクション管理テーブルの構成図である。 図１２は、一実施形態に係る運用ログテーブルの構成図である。 図１３は、一実施形態に係る運用管理処理のフローチャートである。 図１４は、一実施形態に係るトランザクション処理のフローチャートである。 図１５は、一実施形態に運用処理実行要求に対応する運用ＳＣプログラムによる処理のフローチャートである。 図１６は、一実施形態に係る運用処理のフローチャートである。 図１７は、一実施形態に係るログ登録処理のフローチャートである。 図１８は、一実施形態に係る運用処理実行完了確認要求に対応する運用ＳＣプログラムによる処理のフローチャートである。

実施形態について、図面を参照して説明する。なお、以下に説明する実施形態は特許請求の範囲に係る発明を限定するものではなく、また実施形態の中で説明されている諸要素及びその組み合わせの全てが発明の解決手段に必須であるとは限らない。

以下の説明では、「ＡＡＡテーブル」の表現にて情報を説明することがあるが、情報は、どのようなデータ構造で表現されていてもよい。すなわち、情報がデータ構造に依存しないことを示すために、「ＡＡＡテーブル」を「ＡＡＡ情報」と呼ぶことができる。

また、以下の説明では、「プロセッサ部」は、１以上のプロセッサを含む。少なくとも１つのプロセッサは、典型的には、ＣＰＵ（Central Processing Unit）のようなマイクロプロセッサである。１以上のプロセッサの各々は、シングルコアでもよいしマルチコアでもよい。プロセッサは、処理の一部または全部を行うハードウェア回路を含んでもよい。

また、以下の説明では、「プログラム」を動作の主体として処理を説明する場合があるが、プログラムは、プロセッサ部によって実行されることで、定められた処理を、適宜に記憶部及びインターフェース部のうちの少なくとも１つを用いながら行うため、処理の主語が、プロセッサ部（或いは、プロセッサ部を有する装置又はシステム）とされてもよい。プログラムは、プログラムソースから計算機にインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバ又は計算機が読み取り可能な記録媒体であってもよい。また、以下の説明において、２以上のプログラムが１つのプログラムとして実現されてもよいし、１つのプログラムが２以上のプログラムとして実現されてもよい。

まず、一実施形態の概要について説明する。

図１は、一実施形態の概要を説明する図である。

本実施形態に係る分散台帳システムの一例であるブロックチェーンシステム（ＢＣシステム）１００においては、ＢＣシステム１００を構成しているＢＣノード３００は、分散台帳のバックアップのデータを削除するデータ削除処理を含む運用処理を実施した場合に、運用処理についてのログ（内容情報の一例）を生成し、生成したログに対して、バックアップデータを格納していたストレージ４００（周辺コンポーネントの一例）が有する秘密鍵４２５による署名を付与して、ＢＣシステム１００に登録し、保管する。

ＢＣノード３００は、システム構成情報として、例えば、ＢＣシステム１００の構成情報を管理するシステム構成管理テーブル９００（図７参照）と、ＢＣシステム１００のストレージ４００の構成情報を管理する周辺コンポーネント管理テーブル１０００（図８参照）を格納する。また、ＢＣノード３００は、運用処理の処理内容を示す運用ログを管理する運用ログテーブル１４００（図１２参照）を格納する。ＢＣノード３００では、運用処理を実行する運用エージェント３２１が稼働する。運用エージェント３２１は、ストレージ４００が関わる運用処理の実行後に、ストレージ４００から秘密鍵４２５による署名が付与された運用ログを取得する。次いで、運用エージェント３２１は、ＢＣプログラム６００を介して、運用ログを複製して他の全てのＢＣノード３００に送信し、運用ログテーブル１４００に登録させて保管させ、自ＢＣノード３００においても、運用ログを運用ログテーブル１４００に登録する。

［ＢＣシステム構成］
次に、一実施形態に係るブロックチェーン（ＢＣ）システムについて詳細に説明する。

図２は、一実施形態に係るブロックチェーン（ＢＣ）システムの全体構成図である。

ＢＣシステム１００は、１つ以上のクライアント２００と、複数のＢＣノード３００と、１以上のストレージ４００と、１以上の管理端末５００とを備える。クライアント２００と、ＢＣノード３００と、ストレージ４００と、管理端末５００は、ネットワーク１２０等を介して相互に接続されている。ネットワーク１２０は、例えばＷＡＮ(Wide Area Network)、ＬＡＮ(Local Area Network)、インターネット等を含む通信回線により構成することができる。

ＢＣシステム１００においては、例えば、クライアント２００、ＢＣノード３００、ストレージ４００、及び管理端末５００は、複数の組織１１０（図２の例えは、組織１１０−０、１１０−１、１１０−２の３つの組織）により分散されて管理されている。

［クライアント２００］
クライアント２００は、例えば、プロセッサ、メモリ、入出力装置、ネットワークインタフェース等を有する計算機により構成される。クライアント２００では、トランザクションを分散台帳で管理するためのＢＣサービスを活用する業務アプリケーションプログラムなどが実行される。クライアント２００は、アプリケーションプログラムをプロセッサにより実行することにより、トランザクションを生成し、ＢＣノード３００へ発行する。なお、アプリケーションプログラムをＢＣノード３００で実行させるようにして、ＢＣノード３００をクライアント２００として機能させるようにしてもよい。

［管理端末５００］
管理端末５００は、例えばプロセッサ、メモリ、キーボード及びディスプレイ等の入出力装置、ネットワークインタフェース等を有する計算機により構成される。管理端末５００では、ＢＣサービスの管理を行うための運用管理アプリケーションプログラムが実行される。管理端末５００は、入出力装置を介して、管理者からのＢＣノード３００、ストレージ４００に対する設定の指示を受け付ける。また、管理端末５００は、入出力装置を介して、ＢＣノード３００やストレージ４００の状態を示す情報を表示する。なお、管理端末５００の機能を、クライアント２００やＢＣノード３００を構成する計算機に内蔵するようにしてもよい。

［ＢＣノード３００］
図３は、一実施形態に係るＢＣノードと、ストレージとの構成図である。

ＢＣノード３００は、分散台帳装置の一例であり、クライアント２００に対してＢＣサービスを提供する計算機である。ＢＣノード３００は、プロセッサ３１０と、メモリ３２０と、 記憶デバイス３３０と、ネットワークインタフェース３４０とを有する。これら構成要素３１０，３２０，３３０，３４０は、バス３５０により相互接続されている。

プロセッサ３１０は、プロセッサ部の一例であり、ＣＰＵ(Central Processing Unit)などを含む演算処理装置として構成されており、メモリ３２０に格納されているプログラム、演算パラメータ等に従って、ＢＣノード３００の動作を制御する。

ネットワークインタフェース３４０は、例えば、有線ＬＡＮカードや無線ＬＡＮカードなどのインターフェースであり、ネットワークを介して、他の装置（例えば、クライアント２００、ストレージ４００、他のＢＣサーバ３００等）と通信する。

メモリ３２０は、例えば、ＲＡＭ（Random Access Memory）等であり、ＢＣノード３００がクライアント２００にＢＣサービスを提供するためのＢＣプログラム６００と、運用エージェント３２１と、運用処理プログラム３２３等を記憶する。また、メモリ３２０は、記憶デバイス３３０から読み出された各種情報を記憶するための記憶領域や、プロセッサ３１０のワークメモリとして用いられる。

記憶デバイス３３０は、例えば、ＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）などであり、各種プログラムや管理情報などのデータを格納する。なお、ＢＣプログラム６００、運用エージェント３２１、運用処理プログラム３２３などのプログラムを記憶デバイス３３０に格納しておき，これらのプログラムをプロセッサ３１０によって実行する際に記憶デバイス３３０からメモリ３２０に読み出すようにしてもよい。

また、記憶デバイス３３０は、ＢＣサービスで管理する各種データとして、データベース３３２と、分散台帳７００と、ＢＣ管理情報３３１とを格納する。データベース３３２は、ＢＣサービスが受領したトランザクションの実行の結果として得られた最新状態を保持するデータベースである。データベース３３２は、後述するスマートコントラクト管理テーブル８００と、システム構成管理テーブル９００と、周辺コンポーネント管理テーブル１０００と、運用処理ステップ管理テーブル１１００と、運用処理ステップ遷移管理テーブル１２００と、運用トランザクション管理テーブル１３００と、運用ログテーブル１４００と、を含む。

分散台帳７００は、ＢＣサービスが受領したトランザクションのログについて、改竄が困難な構造で格納したデータである。分散台帳７００としては、業務用（業務処理用）の分散台帳（第１分散台帳）と、運用用（運用処理用）の分散台帳（第２分散台帳）とがある。

ＢＣ管理情報３３１は、ＢＣサービスの管理情報であり、登録されたＳＣ、各データベース３３２や分散台帳７００のＢＣノード３００間での共有範囲、ユーザの認証情報やアクセス権等を管理する。データベース３３２、分散台帳７００、ＢＣ管理情報３３１は、記憶デバイス３３０に格納し、ＢＣプログラム６００が参照する際に必要に応じてメモリ３２０にロールインしてもよい。

次に、ＢＣノード３００で実行されるプログラムについて説明する。

ＢＣプログラム６００は、ＳＣプログラム６１０を含み、クライアント２００から取引データであるトランザクションを受領し、ＢＣシステム１００に参加する他のＢＣノード３００とトランザクションの受領に関する合意形成を行い、トランザクションの指定するスマートコントラクト（SC）の実行し、トランザクションの結果をデータベース３３２へコミットし、またトランザクションのログを分散台帳７００に登録し、クライアント２００へトランザクションの処理結果を通知する。

ＳＣプログラム６１０は、各ＳＣの動作が記述されたプログラムである。ＢＣプログラム６００は、トランザクションのＳＣ指定から複数のＳＣプログラム６１０の中から適切なプログラムを選択して実行し、その結果に基づきデータベース３３２の値を更新する。

ＳＣプログラム６１０は、業務用のＳＣプログラムである業務ＳＣプログラム６１１と、運用用のＳＣプログラムである運用ＳＣプログラム６１２との２種類を含む。業務ＳＣプログラム６１１は、クライアント２００における業務アプリケーションからのトランザクションで指定されるＳＣプログラム６１０である。運用ＳＣプログラム６１２は、クライアント２００における運用管理アプリケーションからのトランザクションで指定されるＳＣプログラム６１０である。

運用エージェント３２１は運用ＳＣプログラム６１２より実行通知を受領し、通知内容に基づき運用処理プログラム３２３を選択して実行する。また、運用エージェント３２１は、運用処理の実行状況を示す運用ログを随時ＢＣサービスに登録する。なお、運用エージェント３２１に対して、運用ＳＣプログラム６１２以外からの運用処理の実行通知を許容してもよい。例えば、組織１１０−１の管理端末５００が、組織１１０−１内でのみ行う運用処理の実行通知を発行してもよい。この場合、各組織１１０固有の運用処理の運用ログが、証跡としてＢＣサービスに登録される。運用エージェント３２１は、秘密鍵３２２を保持し、運用ログに対して秘密鍵３２２による署名を付与する。

運用処理プログラム３２３は、運用エージェント３２１が実行する運用処理内容を記述したプログラムである。運用処理プログラム３２３としては、例えば、ストレージ４００と連携して記憶デバイス３３０のデータをバックアップするバックアッププログラムや、ストレージ４００の記憶デバイス４３０のバックアップデータ４３１を削除するバックアップデータ削除プログラムや、ストレージ４００に格納したデータをリストアするリストアプログラム、ストレージ４００のバックアップデータ４３１から個人情報などのデータを削除する削除プログラムなどがある。

［ストレージ４００］
ストレージ４００は、ＢＣノード３００のバックアップデータ４３１を格納する。ストレージ４００は、プロセッサ４１０と、メモリ４２０と、記憶デバイス４３０と、ネットワークインタフェース４４０とを有する。これら構成要素４１０，４２０，４３０，４４０は、バス４５０を介して相互接続されている。

プロセッサ４１０は、ＣＰＵなどを含む演算装置として構成されており、メモリ４２０に記憶されているプログラム、演算パラメータに従ってストレージ４００を制御する。

メモリ４２０は、例えば、ＲＡＭ（Random Access Memory）等であり、ＢＣノード３００の運用処理プログラム３２３と連携して動作するバックアッププログラム４２１、リストアプログラム４２２、データ削除プログラム４２３とを記憶する。また、メモリ４２０は、記憶デバイス４３０から読み出された各種情報を記憶するための領域や、プロセッサ４１０のワークメモリとして用いられる。

また、メモリ４２０は、ログ提供プログラム４２４を記憶する。ログ提供プログラム４２４は、バックアップ、リストア、データ削除の処理の実行時のログを出力し、ＢＣノード３００に提供する。また、ログ提供プログラム４２４は、秘密鍵４２５を有し、これを用いてログへの署名付与を行う。

記憶デバイス４３０は、例えば、ＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）などであり、各種プログラム、管理情報、バックアップデータ４３１などのデータを格納する。なお、記憶デバイス４３０に、バックアッププログラム４２１、リストアプログラム４２２、データ削除プログラム４２３を格納しておき、これらのプログラムをプロセッサ４１０が実行する際に記憶デバイス４３０からメモリ４２０に読み出すようにしてもよい。

［分散台帳７００］
図４は、一実施形態に係る分散台帳の第１の構成例を示す図である。

分散台帳７００は、ＢＣサービスのトランザクションのログデータを、ログデータの改竄を困難とするデータ構造により管理する。分散台帳７００は、ログデータを含む複数のブロック７２０を接続したチェーン状のデータ構造となっている。ブロック７２０は、１以上のトランザクション７２１と、同一の分散台帳７００内の一つ前（直前）に生成されたブロック７２０から算出されたハッシュ７２２とを含む。ハッシュ７２２は、ハッシュ関数によって算出される固定長の値である。ハッシュ関数は、出力であるハッシュから入力値を推定することが困難であり、また衝突耐性によって同一の出力値を得る異なる入力値を得ることが困難であるという特性を持つ関数である。

ブロック７２０間はハッシュ７２２により依存関係を持っており、分散台帳７００内の１つのブロック７２０のトランザクション７２１が改竄されると、そのブロック７２０から算出されるハッシュ７２２は、次のブロック７２０のハッシュ７２２と一致しなくなり、不整合が生じる。ハッシュ関数の特性上、同一のハッシュ７２２を得る改竄データを生成することは難しく、ブロック７２０内の情報の変更には同一の分散台帳７００内の以降の全ブロック７２０に変更が必要となり、改竄が困難となる。

例えば、ブロック７２０からトランザクション７２１における個人情報を削除することがある場合においては、分散台帳７００を図４に示すデータ構造とすると、データの不整合を防ぐことが困難である。このため、ブロック７２０からトランザクション７２１における個人情報を削除することがある場合においては、分散台帳７００を、例えば、図５に示すようなデータ構造としてもよい。

図５は、一実施形態に係る分散台帳の第２の構成例を示す図である。

図５に示す分散台帳７００では、依存関係を持つブロック７２０に直接トランザクション７２１を格納せずに、１以上のトランザクション７２１を含むデータブロック７３０から算出されたハッシュ７３１を格納するようにする。そして、ブロック７２０には、ハッシュ７３１と、直前のブロック７２０から算出されるハッシュ７２２とを格納する。この分散台帳７００では、データ削除時にデータブロック７３０を削除し、フラグによりブロック７２０内のハッシュ７３１に対応するデータブロック７３０が削除されたことを管理することで、分散台帳７００に不整合を生じることなくデータの削除が可能となる。一方で、データブロック７３０の改竄時には、データブロック７３０から算出されるハッシュ７２１と、対応するブロック７２０内のハッシュ７３１が一致せず，改竄検知が可能である。

なお、分散台帳７００のデータ構成は、図４及び図５の例に限らず、例えば、トランザクション７２１に対して改竄が発生した時に、不整合を生じさせるデータ構造であればよい。例えば、図４の分散台帳７００において、各トランザクション７２１の代わりに、各トランザクション７２１から算出するハッシュ値をブロック７２０に格納するようにしたデータ構造としてもよい。

［データベース３３２］
次に、本実施形態におけるデータベース３３２に含まれる各種テーブルの構成例を説明する。

［スマートコントラクト管理テーブル８００］
図６は、一実施形態に係るスマートコントラクト管理テーブルの構成図である。

スマートコントラクト管理テーブル８００は、ＢＣサービスに登録されたＳＣを管理するテーブルであり、ＳＣごとのエントリを有する。スマートコントラクト管理テーブル８００のエントリは、ＩＤ８０１、種別８０２、及び実行プログラム８０３の項目を有する。

ＩＤ８０１には、エントリに対応するＳＣの識別子が格納される。ＳＣの識別子としては、数値であってもよく、“backup_sc”、“restore_sc”などの文字列であってもよい。種別８０２には、エントリに対応するＳＣの種類が格納される。種類としては、例えば、業務アプリケーションにより使用される業務ＳＣと、運用管理アプリケーションにより使用される運用ＳＣとがある。実行プログラム８０３には、エントリに対応するＳＣの内容が記述されたプログラムを特定する情報が格納される。プログラムを特定する情報としては、例えば、エントリに対応するＳＣを実行する際に使用されるプログラムの格納パスがある。

［システム構成管理テーブル９００］
図７は、一実施形態に係るシステム構成管理テーブルの構成図である。

システム構成管理テーブル９００は、運用処理を実行するＢＣノード３００の構成を管理するためのテーブルである。システム構成管理テーブル９００は、運用処理を実施するＢＣノード３００に対応するエントリを格納する。システム構成管理テーブル９００のエントリは、組織ＩＤ９０１、ノードＩＤ９０２、及び公開鍵９０３の項目を有する。

組織ＩＤ９０１には、エントリに対応するＢＣノード３００を管理する組織の識別子（組織ＩＤ）が格納される。ノードＩＤ９０２には、エントリに対応するＢＣノード３００の識別子（ノードＩＤ）が格納される。例えば、組織ＩＤと、ノードＩＤとは、それぞれ数値によって表現してもよいし、組織ＩＤとして“org01”、ノードＩＤとして“svr01”のような文字列を割り当ててもよい。また、組織ＩＤとノードＩＤとの組を、“svr01.org01”のような単一の識別子としてもよい。本実施形態では、ＢＣノード３００は、組織ＩＤ及びノードＩＤの値によって一意に識別可能となっている。公開鍵９０３には、エントリに対応するＢＣノード３００内の運用エージェント３２１が保有する秘密鍵３２２に対応する公開鍵が格納される。公開鍵は、運用エージェント３２１により運用処理の運用ログに付与される署名を検証するために使われる。

［周辺コンポーネント管理テーブル１０００］
図８は、一実施形態に係る周辺コンポーネント管理テーブルの構成図である。

周辺コンポーネント管理テーブル１０００は、運用処理でＢＣノード３００が連携する周辺コンポーネントを管理するためのテーブルである。周辺コンポーネント管理テーブル１０００は、ＢＣノード３００と連携する周辺コンポーネントごとのエントリを格納する。周辺コンポーネント管理テーブル１０００のエントリは、組織ＩＤ１００１、コンポーネントＩＤ１００２、種別１００３、及び公開鍵１００４の項目を有する。

組織ＩＤ１００１には、エントリに対応する周辺コンポーネントを管理する組織の識別子（組織ＩＤ）が格納される。組織ＩＤは、システム構成管理テーブル９００の組織ＩＤ９０１の組織ＩＤと共通した値をとる。コンポーネントＩＤ１００２には、エントリに対応する周辺コンポーネントの識別子（コンポーネントＩＤ）が格納される。組織ＩＤと、コンポーネントＩＤとは、数値であってもよく、２つのＩＤを組合わせた“storage0.org0”のような単一の文字列としてもよい。本実施形態では、周辺コンポーネントは、組織ＩＤ及びコンポーネントＩＤの値によって一意に識別可能となっている。種別１００３には、エントリに対応する周辺コンポーネントの種類が格納される。種類としては、例えば“ストレージ”などの値がある。公開鍵１００４には、エントリに対応する周辺コンポーネントが保有する秘密鍵４２５に対応する公開鍵が格納される。公開鍵は、周辺コンポーネントにより運用処理の運用ログに付与される署名を検証するために使われる。

［運用処理ステップ管理テーブル１１００］
図９は、一実施形態に係る運用処理ステップ管理テーブルの構成図である。

運用処理ステップ管理テーブル１１００は、運用ＳＣに基づき実施する各運用処理の工程（処理ステップ）を管理するテーブルである。運用処理ステップ管理テーブル１１００は、運用処理を構成する工程（処理ステップ）ごとのエントリを格納する。運用処理ステップ管理テーブル１１００のエントリは、ＳＣＩＤ１１０１、組織ＩＤ１１０２、ノードＩＤ１１０３、ステップＩＤ１１０４、実行プログラム１１０５、ログ登録要否１１０６、ログ形式１１０７、連携先ＩＤ１１０８、連携先ログ取得１１０９、及び署名発行者１１１０の項目を有する。

ＳＣＩＤ１１０１には、エントリに対応する処理ステップが実行契機となるＳＣの識別子（ＳＣＩＤ）が格納される。ＳＣＩＤ１１０１のＳＣＩＤは、スマートコントラクト管理テーブル８００のＩＤ８０１のＩＤと対応する。組織ＩＤ１１０２には、エントリに対応する処理ステップを実行するＢＣノード３００が属する組織ＩＤが格納される。ノードＩＤ１１０３には、エントリに対応する処理ステップを実行するＢＣノード３００のノードＩＤが格納される。組織ＩＤ１１０２及びノードＩＤ１１０３の値は、システム構成管理テーブル９００の組織ＩＤ９０１とノードＩＤ９０２の値に対応する。例えば、組織ＩＤ１１０２が１であり、ノードＩＤ１１０３が１であるエントリは、システム構成管理テーブル９００の組織ＩＤ９０１が１であり、ノードＩＤ９０２が１であるエントリに対応するＢＣノード３００が実行する処理ステップを示す。なお、組織ＩＤ１１０２と、ノードＩＤ１１０３との値が指定されていないエントリは、処理を実行するＢＣノード３００が任意であるデフォルトの処理を記述しているとしてもよい。ステップＩＤ１１０４には、エントリに対応する処理ステップの識別子（処理ステップＩＤ）が格納される。運用処理ステップ管理テーブル１１００のエントリに対応する処理ステップは、ＳＣコントラクトＩＤ１１０１、組織ＩＤ１１０２、ノードＩＤ１１０３、及びステップＩＤ１１０４の値によって一意に識別される。

実行プログラム１１０５には、エントリに対応する処理ステップで実行する処理内容が格納される。処理内容としては、例えば、エントリに対応する処理ステップで実行されるコマンドと、その引数とを含んでもよい。ログ登録要否１１０６には、エントリに対応する処理ステップの実施後にＢＣサービスへログを登録するか否かの要否（ログ登録要否）が格納される。ログ形式１１０７には、エントリに対応する処理ステップで出力される運用ログの出力フォーマットが格納される。例えば、出力フォーマットは、フォーマット指定子による記述であってもよい。連携先ＩＤ１１０８には、エントリに対応する処理ステップで連携する周辺コンポーネントの識別子（コンポーネントＩＤ）が格納される。コンポーネントＩＤは、周辺コンポーネント管理テーブル１０００のコンポーネントＩＤ１００２の値と対応する。連携先ログ取得１１０９には、ＢＣサービスに登録する運用ログを、周辺コンポーネントが発行するか否かを示す情報が格納される。署名発行者１１１０には、運用ログに付与する署名の発行者が格納される。例えば、発行者としては、ＢＣノード３００や連携先を指定してもよいし、空欄としてもよい。ここで、空欄は、署名を付与しないことを示す。

［運用処理ステップ遷移管理テーブル１２００］
図１０は、一実施形態に運用処理ステップ遷移管理テーブルの構成図である。

運用処理ステップ遷移管理テーブル１２００は、処理ステップ間の遷移条件に関する情報を管理するテーブルである。運用処理ステップ遷移管理テーブル１２００は、処理ステップから別の処理ステップへの遷移（処理ステップ間遷移）に対応するエントリを含む。運用処理ステップ遷移管理テーブル１２００のエントリは、ＳＣＩＤ１２０１、組織ＩＤ１２０２、ノードＩＤ１２０３、ステップＩＤ１２０４、遷移条件１２０５、次ステップＩＤ１２０６、及び登録状態１２０７の項目を有する。

ＳＣＩＤ１２０１には、エントリに対応する処理ステップが実行契機となるＳＣの識別子（ＳＣＩＤ）が格納される。ＳＣＩＤ１２０１の値は、スマートコントラクト管理テーブル８００のＩＤ８０１の値と対応する。組織ＩＤ１２０２には、エントリに対応する処理ステップを実行するＢＣノードが属する組織ＩＤが格納される。ノードＩＤ１２０３には、エントリに対応する処理ステップを実行するＢＣノードのノードＩＤが格納される。組織ＩＤ１２０２及びノードＩＤ１２０３の値は、システム構成管理テーブル９００の組織ＩＤ９０１とノードＩＤ９０２の値に対応する。ステップＩＤ１２０４には、エントリに対応する処理ステップの識別子（処理ステップＩＤ）が格納される。ＳＣＩＤ１２０１、組織ＩＤ１２０２、ノードＩＤ１２０３、及びステップＩＤ１２０４の値の組と対応する、運用処理ステップ管理テーブル１１００のＳＣＩＤ１１０１、組織ＩＤ１１０２、ノードＩＤ１１０３、及びステップＩＤ１１０４の値の組を持つエントリを参照することにより、運用処理ステップ遷移管理テーブル１２００のエントリに対応するステップ間遷移の遷移元処理ステップを特定できる。

遷移条件１２０５には、エントリに対応する処理ステップの遷移条件が格納される。運用処理ステップ遷移管理テーブル１２００の各エントリは、ＳＤＩＤ１２０１、組織ＩＤ１２０２、ノードＩＤ１２０３、ステップＩＤ１２０４、及び遷移条件１２０５の値によって識別される。次ステップＩＤ１２０６には、エントリに対応するステップ間遷移での遷移先処理ステップの識別子が格納される。次ステップＩＤ１２０６の値は、運用処理ステップ管理テーブル１１００のステップＩＤ１１０４と対応し、エントリに対応する処理ステップ間遷移における遷移先処理ステップを特定できる。登録状態１２０７には、エントリに対応する遷移条件に該当した時に、ＢＣサービスに登録する運用処理の実行状態が格納される。実行状態としては、例えば、実行中、異常終了、実行完了等がある。

［運用トランザクション管理テーブル１３００］
図１１は、一実施形態に係る運用トランザクション管理テーブルの構成図である。

運用トランザクション管理テーブル１３００は、運用処理実行要求をしたトランザクションの情報を管理するテーブルである。運用トランザクション管理テーブル１３００は、運用処理実行要求をしたトランザクション毎のエントリを格納する。運用トランザクション管理テーブル１３００のエントリは、ＩＤ１３０１、ＳＣＩＤ１３０２、状態１３０３、パラメータ１３０４、発行者１３０５、登録時タイムスタンプ１３０６、及び最終更新時タイムスタンプ１３０７の項目を有する。

ＩＤ１３０１には、エントリに対応する運用処理実行要求をしたトランザクションの識別子が格納される。ＳＣＩＤ１３０２には、エントリに対応する運用処理実行要求をしたトランザクションが指定したＳＣの識別子（ＳＣＩＤ）が格納される。ＳＣＩＤ１３０２のＳＣＩＤは、スマートコントラクト管理テーブル８００のＩＤ８０１の値に対応する。状態１３０３には、エントリに対応するトランザクションが要求した運用処理の実行状態が格納さえる。実行状態としては、“実行開始”や“実行終了”などがある。パラメータ１３０４には、エントリに対応するトランザクションが指定したパラメータが格納される。パラメータとしては、例えばバックアップの対象データなどの情報がある。発行者１３０５には、エントリに対応するトランザクションを発行したユーザが格納される。登録時タイムスタンプ１３０６には、エントリに対応するトランザクションの受領時のタイムスタンプが格納される。最終更新時タイムスタンプ１３０７には、エントリに対応するトランザクションが要求した運用処理の実行状態の最終更新時のタイムスタンプが格納される。

［運用ログテーブル１４００］
図１２は、一実施形態に係る運用ログテーブルの構成図である。

運用ログテーブル１４００は、各ＢＣノード３００の運用エージェント３２１が登録する運用処理の運用ログ（内容情報の一例）を管理するためのテーブルである。運用ログテーブル１４００は、運用エージェント３２１が登録する運用処理の各処理ステップでの運用ログに対応するエントリを格納する。運用ログテーブル１４００のエントリは、トランザクション（Ｔｘ）ＩＤ１４０１、組織ＩＤ１４０２、ノードＩＤ１４０３、状態１４０４、タイムスタンプ１４０５、完了ステップＩＤ１４０６、ログ１４０７、署名１４０８、及び次ステップＩＤ１４０９の項目を有する。

ＴｘＩＤ１４０１には、エントリに対応する運用ログの運用処理を要求したトランザクションの識別子が格納される。ＴｘＩＤ１４０１のトランザクションＩＤは、運用トランザクション管理テーブル１３００のＩＤ１３０１の値と対応する。組織ＩＤ１４０２には、エントリに対応する運用ログの処理ステップを実行するＢＣノードが属する組織ＩＤが格納される。ノードＩＤ１４０３には、エントリに対応するログの処理ステップを実行するＢＳＣノードのノードＩＤが格納される。組織ＩＤ１４０２及びノードＩＤ１４０３の値は、システム構成管理テーブル９００の組織ＩＤ９０１とノードＩＤ９０２の値に対応する。

状態１４０４には、エントリに対応する運用ログの登録時のトランザクションに要求された運用処理の実行状態が格納される。状態１４０４の実行状態は、運用処理ステップ遷移管理テーブル１２００の登録状態１２０７の値に対応する。タイムスタンプ１４０５には、エントリに対応する運用ログの登録時のタイムスタンプが格納される。完了ステップＩＤ１４０６には、エントリに対応する運用ログを出力した処理ステップの識別子が格納される。完了ステップＩＤ１４０６の処理ステップＩＤは、運用処理ステップ管理テーブル１１００のステップＩＤ１１０４の値と対応する。ログ１４０７には、エントリに対応する運用エージェント３２１により登録された運用ログが格納される。署名１４０８には、エントリに対応する運用ログに付与された電子署名が格納される。次ステップＩＤ１４０９には、エントリに対応する運用ログの処理ステップの次に実行する処理ステップの識別子が格納される。次ステップＩＤ１４０９の処理ステップＩＤは、運用処理ステップ管理テーブル１１００のステップＩＤ１１０４の値と対応する。

次に、本実施形態に係るＢＣシステム１００における処理について説明する。

図１３は、一実施形態に係る運用管理処理のフローチャートである。

運用管理処理は、大別すると、運用処理の実行要求を行う工程（ステップＳ００１）と、運用処理を実行する工程（ステップＳ００２）と、運用処理の実行完了の確認を行う工程（ステップＳ００５）との３つの工程から構成される。

クライアント２００又は管理端末５００は、ＢＣプログラム６００を介して各ＢＣノード３００へ業務用の分散台帳７００に対する運用処理の実行要求処理を行う（ステップＳ００１）。運用処理実行要求は、トランザクションの実行要求の一例である。次いで、運用処理実行要求に起因して、通知を受けた各ＢＣノード３００の運用エージェント３２１が運用処理を実行する（ステップＳ００２）。

次いで、運用エージェント３２１は、処理の中断や中止の要求が発生したか否かを判定し（ステップＳ００３）、中断や中止の要求が発生していない場合（ステップＳ００３；Ｎｏ）には、処理をステップＳ００５に進める。

一方、中断や中止の供給が発生している場合（ステップＳ００３：Ｙｅｓ）には、運用エージェント３２１は、再開要求があったか否かを判定し（ステップＳ００４）、再開要求があれば（ステップＳ００４：Ｙｅｓ）、処理をステップＳ００１に進める一方、再開要求がなければ（ステップＳ００４：Ｎｏ）、運用管理処理を中止する。

ステップＳ００５では、運用エージェント３２１は、運用管理処理の実行完了の確認処理（運用処理実行完了確認処理）を行い、処理を終了する。運用処理実行完了確認処理では、運用エージェント３２１が各ＢＣノード３００での運用処理の実行状況から、ＢＣシステム１００全体で運用処理が完了したことを確認する。

［トランザクション処理］
図１３の示す運用管理処理の各処理を説明する前に、ＢＣシステム１００でのトランザクション処理について説明する。

図１４は、一実施形態に係るトランザクション処理のフローチャートである。

トランザクション処理は、ＢＣシステム１００を構成するＢＣノード３００のＢＣプログラム６００によって実行される。トランザクション処理は、ＢＣシステム１００を構成する全てのＢＣノード３００で実施してもよいし、一部のＢＣノード３００で実施して、実施した処理結果を他のＢＣノード３００へ配信するようにしてもよい。

トランザクション処理は、クライアント２００や管理端末５００から発行されるトランザクションを、ＢＣノード３００のＢＣプログラム６００が受領することを契機として開始される。ここで、トランザクションには、例えば、実行するＳＣを特定するための識別子や、ＳＣ実行時に指定する引数、ユーザ認証のための署名などが含まれる。

まず、ＢＣプログラム６００は、トランザクションが指定しているＳＣプログラムを特定する（ステップＳ１０１）。具体的には、ＢＣプログラム６００は、スマートコントラクト管理テーブル８００を参照し、受領したトランザクションに含まれるＳＣの識別子と一致する値がＩＤ８０１に格納されているエントリを取得し、このエントリからトランザクションの指定するＳＣプログラムを特定する。

次に、ＢＣプログラム６００は、受領したトランザクションの内容を検証する（ステップＳ１０２）。具体的には、ＢＣプログラム６００は、例えば、トランザクションに含まれる署名の検証、トランザクションの処理内容とデータベース３３２との整合性確認、ＢＣノード３００間でのトランザクションの処理結果の一致確認などである。この検証結果に問題ない場合（ステップＳ１０２：Ｙｅｓ）には、ＢＣプログラム６００は、トランザクションを分散台帳７００とデータベース３３２へと反映するために処理をステップＳ１０３に進める一方、検証結果に問題がある場合（ステップＳ１０２：Ｎｏ）には、トランザクションの結果を反映せずに、トランザクション処理を完了する。

ステップＳ１０３では、ＢＣプログラム６００は、ステップＳ１０１で受領したトランザクションを含むブロック７２９を生成する。なお、受領したトランザクションの数が、ブロック７２９に格納するトランザクションの数に満たない場合には、トランザクションをメモリに格納等してこれ以降の処理を行わない。ブロック７２９の生成においては、ＢＣノード３００のＢＣプログラム６００は、ステップＳ１０１で受領したトランザクションであって、分散台帳７００のブロック７２０に組み込まれていない所定数（ブロック７２９への格納数）のトランザクション７２１を選択するとともに、分散台帳７００の末尾に位置するブロック７２０に基づいて、ブロック７２０に対応するハッシュ７２２を算出し、所定数のトランザクション７２１と、ハッシュ７２２とを含むブロック７２０を生成する。

次に、ステップＳ１０４では、ＢＣプログラム６００は、ＳＣプログラム６１０を実行することにより、生成したブロック７２０を分散台帳７００へ登録するとともに、登録したブロック７２０に含まれるトランザクション７２１を実行し、その結果をデータベース３３２に反映する。このステップにおいて、登録するブロック７２０の整合性を確認してもよい。整合性の確認は、例えばブロック７２０に含まれるハッシュ７２２が分散台帳７００の末尾のブロック７２０から算出したハッシュ７２２と一致するか否かにより確認することができる。整合しないと判定した場合には、例えば、他のＢＣノード３００により、分散台帳７００に新たなブロック７２０が追加されていた等が考えられるので、ＢＣブロック６００は、ＳＣプログラム６１０の実行、分散台帳７００とデータベース３３２の更新はせずに処理をステップＳ１０３に進め、受領したトランザクションを含む別のブロック７２０を新たに生成して、後続の処理を実行する。なお、ステップＳ１０３と、ステップＳ１０４で実施するブロック７２０の生成と検証との方法は、ＢＣシステム１００が採用する合意形成アルゴリズムにより異なる。合意形成アルゴリズムには、例えばＰｏＷ（Proof of Work）やＰＢＦＴ（Practical Byzantine Fault Tolerance）などがある。

ステップＳ１０４の実行が終了すると、ＢＣプログラム６００は、処理をステップＳ１０５に進める。

ステップＳ１０５では、ＢＣプログラム６００は、完了した処理の結果を、トランザクションを発行したクライアント２００や管理端末５００に返送し，トランザクション処理を完了する。返送する内容は、例えば実行したトランザクションの識別子や、トランザクションの実行により更新されたデータベース３３２の値などである。

［運用処理実行要求処理］
次に、運用処理実行要求処理（図１３のＳ００１）について説明する。運用処理実行要求処理においては、クライアント２００や管理端末５００から運用処理の開始要求（実行要求：トランザクション）の通知を受領したＢＣプログラム６００は、各ノード３００へ運用処理実行要求を送信する。運用処理実行要求のトランザクションを受領したＢＣプログラム６００は、図１４に示すトランザクション処理により、受領した運用処理実行要求のトランザクションを処理する。この場合におけるトランザクション処理では、ステップＳ１０１では、ＢＣプログラム６００は、運用処理実行要求に対応する運用ＳＣプログラム６１２を選択し、ステップＳ１０４では、運用ＳＣプログラム６１２が処理を実行する。

図１５は、一実施形態に運用処理実行要求に対応する運用ＳＣプログラムによる処理のフローチャートである。

運用処理実行要求に対応する運用ＳＣプログラム６１２は、運用処理実行要求のトランザクションを運用トランザクション管理テーブル１３００へ登録する（ステップＳ２０１）。具体的には、運用ＳＣプログラム６１２は、トランザクションに関する情報を設定し、状態１３０３を“実行要求”に設定したエントリを運用トランザクション管理テーブル１３００へ新規登録する。運用トランザクション管理テーブル１３００のエントリのＩＤ１３０１は、運用処理の実行要求ごとに異なる値であり、ＢＣプログラム６００がトランザクションごとに与える分散台帳７００内で固有の識別子としてもよく、運用ＳＣプログラム６１２が管理する固有の値としてもよい。

次に、運用ＳＣプログラム６１２は、運用エージェント３２１へ運用処理の要求（処理要求）を通知する（ステップＳ２０２）。運用エージェント３２１へ処理要求を通知する方法としては、例えばシグナルを運用エージェント３２１に送信してもよく、運用エージェント３２１が監視するフラグを更新するようにしてもよい。

この通知が完了した後、運用ＳＣプログラム６１２は、処理を終了する。

この運用ＳＣプログラム６１２による処理によると、運用処理実行要求がＢＣプログラム６００を介して全ＢＣノード３００に反映され、各ＢＣノード３００の運用エージェント３２１へ実行要求が通知される。

［運用処理中断処理・再開要求処理］
ステップＳ００３で判断される中断の要求を行う運用処理中断処理や、ステップＳ００４で判断される再開要求を行う再開要求処理についても、運用処理要求処理と同様な流れで実行される。なお、運用処理中断処理や再開要求処理においては、ステップＳ２０１においては、中断や再開の対象のトランザクションのエントリの状態１３０３を、中断や再開に更新し、また、ステップＳ２０２においては、運用エージェント３２１へ運用処理の中断や再開に関する要求を通知する。

［運用処理］
ステップＳ００２における運用処理について説明する。運用処理では、ＢＣシステム１００内の全ＢＣノード３００の運用エージェント３２１が、ＢＣプログラム６００からの通知内容に対応する運用処理プログラム３２３を選択して実行する。

図１６は、一実施形態に係る運用処理のフローチャートである。

運用エージェント３２１は、ＢＣプログラム６００から運用処理要求が通知されたことを契機に運用処理の実行を開始する。ここで、運用処理要求の通知には、運用処理要求の契機となったトランザクションの識別子や通知を発行したＳＣプログラムの識別子、処理実行に必要な引数などが含まれる。

まず、運用エージェント３２１は、通知のあった運用処理に関する処理ステップについての情報を取得する（ステップＳ３０１）。例えば、運用エージェント３２１は、運用処理ステップ管理テーブル１１００から、通知元のＳＣプログラム６１０の識別子とＳＣ ＩＤの値が一致し、且つＢＣノード３００のもつ識別子が組織ＩＤ１１０２やノードＩＤ１１０３の値と一致するエントリを取得する。このときＢＣノード３００の識別子がノードＩＤ１１０３の値と一致するエントリがなければ、デフォルトの処理ステップを表すノードＩＤ１１０３の指定がないエントリを取得する。

また、運用エージェント３２１は、運用処理ステップ遷移管理テーブル１２００から通知元のＳＣプログラム６１０の識別子と、ＳＣ ＩＤ１２０１のＩＤとが一致し、且つＢＣノード３００の識別子がノードＩＤ１２０３に含まれるエントリを取得する。このとき、ＢＣノード３００の識別子がノードＩＤ１２０３のＩＤと一致するエントリがなければ、デフォルトの処理ステップ間の遷移条件を表すノードＩＤ１２０３の指定がないエントリを取得する。このステップＳ３０１の処理による情報取得により、運用エージェント３２１は運用ＳＣプログラム６１２により通知された運用処理の各工程（処理ステップ）を把握することができる。

次に、運用エージェント３２１は、通知された運用処理で実行する最初の処理ステップを設定する（ステップＳ３０２）。具体的には、エージェント３２１は、ステップＳ３０１で取得したエントリのうち、ステップＩＤ１１０４の値が最初の実行処理ステップを表す１となっているエントリを選択し、このエントリに対応する処理ステップを対象処理ステップとして設定する。

次に、運用エージェント３２１は、運用処理の実行開始の情報をＢＣプログラム６００へ通知する（ステップＳ３０３）。具体的には、運用エージェント３２１は、運用処理の実行契機となった運用処理実行要求で受領したトランザクションの識別子やＢＣノード３００の識別子、及び運用処理が実行開始状態に遷移する内容をエントリに記載し、ＢＣプログラム６００に運用ログテーブル１４００へのエントリの登録のためのトランザクションを発行する。但し、運用処理開始時には、エントリ内のログ１４０７や署名１４０８を空欄として登録してよい。なお、ステップＳ３０２で取得した処理ステップに関する情報から、ＢＣノード３００にて実施すべき処理がない場合には、状態１４０４には、実行完了状態を登録する。これに対して、トランザクションを受領したＢＣプログラム６００は、受領したトランザクションについての応答として、エントリ登録の成否と、運用処理の実行契機のトランザクションの実行状態を示す運用トランザクション管理テーブル１３００の状態１３０３の値に基づいた以降の運用処理の実施可否を返送する。

次に、運用エージェント３２１は、運用処理を終了するか否かを確認する（ステップＳ３０４）。この結果、ステップＳ３０１において取得した次の処理ステップの識別子に関して値が取得できていれば、次の処理ステップがあり、運用処理を終了しないので（ステップＳ３０４：Ｎｏ）、運用エージェント３２１は、処理をステップＳ３０５に進める一方、値が取得できていなければ、次の処理ステップがなく、運用処理を終了することを意味しているので（ステップＳ３０４：Ｙｅｓ）、運用処理を完了する。

ステップＳ３０５では、運用エージェント３２１は、実行中の運用処理の以降の処理ステップを継続して実行してよいか否かを判定する。具体的には、運用エージェント３２１は、ステップＳ３０３や、後述するステップＳ３０８におけるトランザクションに対するＢＣプログラム６００からの応答として、処理実行中断の通知を受けた場合や、運用トランザクション管理テーブル１３００を参照して、運用処理の契機となったトランザクションの実行状態１３０３の値が中止となっていることを確認した場合には、運用処理中止要求があったと把握して、運用処理の継続を実行しないと判定する。また、運用エージェント３２１は、運用トランザクション管理テーブル１３００に実行中の処理の契機となったトランザクションのエントリが存在しない場合には、正常に実行されている処理ステップではないと考えられるので、運用処理を中止する、すなわち、運用処理の継続を実行しないと判定してもよい。

この結果、運用処理継続と判定した場合（ステップＳ３０５：Ｎｏ）には、運用エージェント３２１は、処理をステップＳ３０６に進める一方、運用処理中止と判定した場合（ステップＳ３０５：Ｙｅｓ）には、運用処理を終了する。

ステップＳ３０６では、運用エージェント３２１は、対象処理ステップの処理を実行する。具体的には、運用エージェント３２１は、運用処理ステップ管理テーブル１１００の対象処理ステップのエントリの実行プログラム１１０５の値を対象処理ステップの実行コマンドとして取得し、この実行コマンドを実行する。また、運用エージェント３２１は、運用処理の実行要求に引数の指定がある場合には、指定に準じて実行コマンドに引数を付与し、対象処理ステップの処理を実行する。

次に、運用エージェント３２１は、次に実行する処理ステップを確認する（ステップＳ３０７）。具体的には、運用エージェント３２１は、ステップＳ３０１で取得した運用処理ステップ遷移管理テーブル１２００からステップＩＤ１２０４の値が対象処理ステップのステップＩＤと一致するエントリを選択する。そして、運用エージェント３２１は、選択したエントリの中から遷移条件１２０５の値が対象処理ステップの実行結果と一致するエントリを選択する。選択されたエントリの次ステップＩＤ１２０６の値を次の処理ステップの識別子として取得する。

次に、運用エージェント３２１は、対象処理ステップ実行時のログの登録要求をＢＣプログラム６００に発行することで、運用ログをデータベース３３２へ登録するログ登録処理（図１７参照）を実行する（ステップＳ３０８）。ログ登録処理により、運用処理結果のログ（運用ログ）がデータベース３３２と分散台帳７００に登録される。

次に、運用エージェント３２１は、次の処理ステップを対象処理ステップに設定し、処理をステップＳ３０４に進める（ステップＳ３０９）。具体的には、運用エージェント３２１は、ステップＳ３０１で取得した運用処理ステップ管理テーブル１１００のエントリの中から、ステップＩＤ１１０４の値がステップＳ３０７で取得した次の処理ステップの識別子と一致するエントリを選択し、このエントリの処理ステップを対象処理ステップとして設定する。

上記したように、運用処理によると、ＢＣシステム１００を構成するＢＣノード３００で運用処理が実行され、運用処理結果のログがデータベース３３２と分散台帳７００へ登録される。これにより、各ＢＣノード３００の管理者は、管理対象のＢＣノード３００から運用処理結果を容易且つ適切に把握することができる。

［ログ登録処理］
次に、ログ登録処理（図１６のステップＳ３０８）について説明する。

図１７は、一実施形態に係るログ登録処理のフローチャートである。

まず、運用エージェント３２１は、対象処理ステップでのログ登録が必要かを確認する（ステップＳ４０１）。具体的には、運用エージェント３２１は、運用処理ステップ管理テーブル１１００の対象処理ステップに対応するエントリのログ登録要否１１０６の値を確認する。ここで、ログ登録要否１１０６が“必要”であれば、ログ登録が必要であることを示し、”不要”であれば、ログ登録が不要であることを示す。

この結果、ログ登録が必要である場合（ステップＳ４０１：Ｙｅｓ）には、運用エージェント３２１は、処理をステップＳ４０３に進める一方、ログ登録が不要である場合（ステップＳ４０１：Ｎｏ）には、処理を終了する。

ステップＳ４０２では、運用エージェント３２１は、登録するログの取得先が、ＢＣノード３００か、周辺コンポーネント（周辺機器）であるかを判定する。ここで、運用エージェント３２１は、運用処理ステップ管理テーブル１１００の対象処理ステップのエントリの連携先ログ取得１１０９の値が“−”である場合には、ＢＣノード３００からログを取得すると判定し、連携先ログ取得１１０９の値が“ＯＮ”である場合には、周辺コンポーネントからログを取得すると判定する。

この結果、ＢＣノード３００からログを取得すると判定された場合（ステップＳ４０２：Ｎｏ）には、運用エージェント３２１は、処理をステップＳ４０３に進める一方、周辺コンポーネントからログを取得すると判定された場合（ステップＳ４０２：Ｙｅｓ）には、処理をステップＳ４０４に進める。

ステップＳ４０３では、運用エージェント３２１は、対象処理ステップにより生成されるログを取得する。運用エージェント３２１によるログの取得方法としては、例えば、対象処理ステップのコマンド実行時の出力から取得してもよく、対象処理ステップのコマンドが生成するログファイルを参照して取得してもよい。

次に、運用エージェント３２１は、登録するログへの署名が必要であるか否かを判定する（ステップＳ４０５）。具体的には、運用エージェント３２１は、運用処理ステップ管理テーブル１１００の対象処理ステップのエントリの署名発行者１１１０に、署名の発行者が設定してあれば、署名が必要であると判定し、署名の発行者が設定していなければ、署名が不要であると判定する。

この結果、署名が必要であると判定した場合（ステップＳ４０５：Ｙｅｓ）には、運用エージェント３２１は、処理をステップＳ４０８に進める一方、署名が不要であると判定した場合（ステップＳ４０５：Ｎｏ）には、処理をステップＳ４１０に進める。

一方、ステップＳ４０４では、運用エージェント３２１は、対象処理ステップにより生成されるログを周辺コンポーネント（例えば、ストレージ４００）から取得する。運用エージェント３２１によるログ取得方法としては、例えばストレージ４００のログ提供プログラム４２４にコマンドを発行してログを取得してもよく、また、コマンド実行時に出力されるテキストをログとして取得してもよい。

次に、運用エージェント３２１は、登録するログへの署名が必要であるか否かを判定する（ステップＳ４０６）。具体的には、運用エージェント３２１は、運用処理ステップ管理テーブル１１００の対象処理ステップに対応するエントリの署名発行者１１１０に署名の発行者が設定してあれば、署名が必要であると判定し、署名の発行者が設定していなければ、署名が不要であると判定する。

この結果、署名が必要であると判定した場合（ステップＳ４０６：Ｙｅｓ）には、運用エージェント３２１は、処理をステップＳ４０７に進める一方、署名が不要であると判定した場合（ステップＳ４０６：Ｎｏ）には、処理をステップＳ４１０に進める。

ステップＳ４０７では、運用エージェント３２１は、ログへの署名を生成するのが、ＢＣノード３００であるか、周辺コンポーネントであるのかを判定する。具体的には、運用エージェント３２１は、運用処理ステップ管理テーブル１１００の対象処理ステップのエントリの署名発行者１１１０の値を確認し、署名発行者１１１０の値がＢＣノードである場合（ステップＳ４０７：Ｎｏ）には、ＢＣノード３００が署名を生成するとして処理をステップＳ４０８に進める一方、署名発行者１１１０の値が連携先である場合（ステップＳ４０７：Ｙｅｓ）には、周辺コンポーネントが署名を生成するとして処理をステップＳ４０９に進める。

ステップＳ４０８では、運用エージェント３２１は、登録するログに対して署名を生成する。具体的には、運用エージェント３２１は、登録するログに対して、保持している秘密鍵３２２を用いて署名を作成する。

ステップＳ４０９では、運用エージェント３２１は、周辺コンポーネントから署名を取得する。具体的には、運用エージェント３２１は、例えばコマンドを発行するなどの方法で、ストレージ４００のログ提供プログラム４２４に署名の生成を依頼する。この結果、ログ提供プログラム４２４は保持する秘密鍵４２５を用いて、対象処理ステップ実行時のログに対する署名を生成して、運用エージェント３２１に返送する。運用エージェント３２１は生成された署名をストレージ４００から受領する。このように、周辺コンポーネント側で署名を生成するようにすると、運用ログに対するＢＣノード３００側での不正改変を適切に発見することができる。

ステップＳ４１０では、運用エージェント３２１がデータベース３３２へ登録するエントリを作成する。具体的には、運用エージェント３２１は、ステップＳ４０３またはステップＳ４０４で取得したログと、ステップＳ４０８又はステップＳ４０９で取得した署名（このステップを実施した場合）と、運用ログテーブル１４００のエントリに必要な値とを含むテーブル用のエントリを作成する。例えば、ステップＳ３０９で取得した次ステップＩＤ１２０６のステップＩＤと、登録状態１２０７の状態とを、エントリにおける次ステップＩＤ１４０９や状態１４０４に設定する。

次に、運用エージェント３２１は、データベース３３２（運用ログテーブル１４００）及び分散台帳７００へ運用ログを登録する（ステップＳ４１１）。具体的には、運用エージェント３２１は、ステップＳ４１０で作成したエントリをデータベース３３２及び分散台帳７００に登録するためのトランザクションを生成して、ＢＣプログラム６００に送付する。この結果、ＢＣプログラム６００は、運用ログをデータベース３３２に登録するとともに、分散台帳７００に登録し、トランザクションに対する完了通知を運用エージェントに返す。

この後、運用エージェント３２１は、ＢＣプログラム６００からトランザクションに対する完了通知を受け取ると、ログ登録処理を完了する。

このログ登録処理によると、ＢＣシステム１００を構成する各ＢＣノード３００のデータベース３３２と分散台帳７００とに運用ログが格納される。これにより、各ＢＣノード３００の管理者は、管理対象のＢＣノード３００から運用ログを容易且つ適切に把握することができる。また、運用ログに対して署名を付している場合には、署名により運用ログが改竄されていないかを適切に把握することができる。

［運用処理実行完了確認処理］
次に、運用処理実行完了確認処理（図１３のＳ００５）について説明する。この運用処理実行完了確認処理では、ＢＣプログラム６００は、各ＢＣノード３００での運用処理の実行完了を確認する。具体的には、クライアント２００や管理端末５００から運用処理の実行完了確認要求（運用処理実行確認要求：トランザクション）の通知を受領したＢＣプログラム６００は、各ノード３００へ運用処理の実行完了確認要求を送信する。運用処理実行完了確認要求のトランザクションには、実行完了を確認したい運用処理実行要求処理のトランザクションの識別子などの情報を含む。実行完了確認要求のトランザクションを受領したＢＣプログラム６００は、図１４に示すトランザクション処理により、受領した運用処理実行完了確認要求のトランザクションを処理する。この場合におけるトランザクション処理では、ステップＳ１０１では、ＢＣプログラム６００は、運用処理実行完了確認要求に対応する運用ＳＣプログラム６１２を選択し、ステップＳ１０４では、運用ＳＣプログラム６１２が処理を実行する。

図１８は、一実施形態に係る運用処理実行完了確認要求に対応する運用ＳＣプログラムによる処理のフローチャートである。

運用処理実行完了確認要求に対応する運用ＳＣプログラム６１２は、ＢＣシステム１００を構成するＢＣノード３００の情報と、完了確認するトランザクションの情報とを取得する（ステップＳ５０１）。具体的には、運用ＳＣプログラム６１２は、システム構成管理テーブル９００を参照して、ＢＣシステム１００に参加するＢＣノード３００のリストを生成する。加えて、運用ＳＣプログラム６１２は、運用トランザクション管理テーブル１３００からＩＤ１３０１の値が、運用処理実行完了確認要求のトランザクションで完了確認対象として指定されるトランザクションの識別子と一致するエントリを取得する。

次に、運用ＳＣプログラム６１２は、運用ログを確認する対象とするＢＣノード３００（対象ＢＣノード）を１台選択する（ステップＳ５０２）。具体的には、運用ＳＣプログラム６１２は、ステップＳ５０１で生成したＢＣノード３００のリストから、処理中のトランザクションにおいてログを確認していないＢＣノード３００の１台を、対象ＢＣノードとして選択する。

次に、運用ＳＣプログラム６１２は、対象ＢＣノードでの運用処理の完了を確認し（ステップＳ５０３）、実行完了である場合（ステップＳ５０３：Ｙｅｓ）には、処理をステップＳ５０５に進め、実行完了でない場合（ステップＳ５０３：Ｎｏ）には、処理をステップＳ５０４に進める。具体的には、運用プログラム６１２は、運用ログテーブル１４００から、実行完了確認対象のトランザクションの識別子とＴｘＩＤ１４０１の値とが一致し、且つ対象ＢＣノードと、組織ＩＤ１４０２の値及びノードＩＤ１４０３の値が一致するエントリを取得し、それらエントリの中でタイムスタンプ１４０５の値に基づいて最新のログのエントリを選択し、選択したエントリの状態１４０４の値により、実行完了であるか否かを確認する。加えて、運用プログラム６１２は、運用処理完了として、運用処理ステップ管理テーブル１１００のログ形式１１０７の値に基づいて運用ログテーブル１４００のログ１４０７の値を解釈し、運用処理に対する運用ログの内容の正しさや、参加ノード間でのログ内容の一致を確認するようにしてもよい。

ステップＳ５０４では、運用ＳＣプログラム６１２は、運用処理の未完了フラグを立てる。なお、未完了フラグはＢＣノード３００ごとに管理してもよく、参加ＢＣノード３００全体で１つのフラグを管理してもよい。その後、運用ＳＣプログラム６１２は、処理をステップＳ５０３に進める。

ステップＳ５０５では、運用ＳＣプログラム６１２は、署名確認の対象処理ログを設定する。具体的には、運用ＳＣプログラム６１２は、ステップＳ５０３で運用ログテーブル１４００から取得したエントリから、署名未検証のエントリを選択し、これを対象処理ログとして設定する。

次に、運用ＳＣプログラム６１２は、ログの署名確認が必要か否かを判定する（ステップＳ５０６）。具体的には、運用ＳＣプログラム６１２は、運用処理ステップ管理テーブル１１００から、ステップＳ５０１で取得した完了確認対象のトランザクションのＳＣＩＤがＳＣＩＤ１１００の値と一致し、ＢＣノード３００の識別子が、組織ＩＤ１１０２の値及びノードＩＤ１１０３の値と一致し、さらに、ステップＳ５０５で取得した対象ログのエントリの完了ステップＩＤ１４０６の値と、ステップＩＤ１１０４の値が一致するエントリを、対象処理ステップの情報として取得する。次に、運用ＳＣプログラム６１２は、取得したエントリから署名発行者１１１０の値に基づき署名確認の要否を判断する。

この結果、署名確認が必要な場合（ステップＳ５０６：Ｙｅｓ）には、運用ＳＣプログラム６１２は、処理をステップＳ５０７に進める一方、署名確認が不要な場合（ステップＳ）には処理をステップＳ５１３に進める。

ステップＳ５０７では、運用ＳＣプログラム６１２は、対象ログの署名発行者がＢＣノード３００であるか、連携先であるかを判定する。具体的には、運用ＳＣプログラム６１２は、ステップＳ５０６で取得した対象処理ステップのエントリの署名発行者１１１０の値を確認し、その値がＢＣノード３００であるか、周辺コンポーネントであるかを判定する。

この結果、署名発行者がＢＣノード３００である場合（ステップＳ５０７：Ｎｏ）には、運用ＳＣプログラム６１２は、処理をステップＳ５０８に進める一方、署名発行者が周辺コンポーネントである場合（ステップＳ５０７：Ｙｅｓ）には、処理をステップＳ５０９に進める。

ステップＳ５０８では、運用ＳＣプログラム６１２は、署名を検証するための対象ＢＣノード３００の秘密鍵に対応する公開鍵を取得する。具体的には、運用ＳＣプログラム６１２は、システム構成管理テーブル９００から対象ＢＣノード３００に対応する組織ＩＤ９０１の値及びノードＩＤ９０２の値を持つエントリを選択し、選択したエントリの公開鍵９０３に設定されている公開鍵を取得する。ステップＳ５０８の終了後、運用ＳＣプログラム６１２は、処理をステップＳ５１１に進める。

ステップＳ５０９では、運用ＳＣプログラム６１２は、署名を生成した周辺コンポーネントを特定する。具体的には、運用エージェント６１２は、ステップＳ５０７で運用処理ステップ管理テーブル１１００から取得した対象処理ステップのエントリの連携先ＩＤ１１０８の識別子を取得することにより、署名を生成した周辺コンポーネントを特定する。

次に、運用ＳＣプログラム６１２は、署名を生成した周辺コンポーネントの秘密鍵に対応する公開鍵を取得し（ステップＳ５１０）、処理をステップＳ５１１に進める。具体的には、運用ＳＣプログラム６１２は、周辺コンポーネント管理テーブル１０００から、対象ＢＣノード３００が所属する組織の識別子と組織ＩＤ１００１の値が一致し、ステップＳ５１０で取得した周辺コンポーネントの識別子とコンポーネントＩＤ１００２の値とが一致するエントリを選択し、このエントリの公開鍵１００４から公開鍵を取得する。

ステップＳ５１１では、運用ＳＣプログラム６１２は、対象ログに付与される署名の検証を行う。具体的には、運用ＳＣプログラム６１２は、ステップＳ５０８又はステップＳ５１０で取得した公開鍵を用いて、署名の検証を行う。署名の検証方法は、署名の生成方式に依存し、例えば署名を公開鍵で復号した値が、ログのハッシュ値と一致することを確認して行うなどの方法である。

この結果、署名が正しければ（ステップＳ５１１：Ｙｅｓ）、運用ＳＣプログラム６１２は、処理をステップＳ５１３に進める一方、署名が正しくなければ（ステップＳ５１１：Ｎｏ）、処理をステップＳ５１２に進める。

ステップＳ５１２では、運用ＳＣプログラム６１２は、運用処理の署名の改竄フラグを立てる。フラグは、ＢＣノード３００ごとに管理してもよく、参加ＢＣノード３００全体で１つのフラグを管理してもよい。ステップＳ５１２の後、運用ＳＣプログラム６１２は、処理をステップＳ５１４に進める。

ステップＳ５１３では、運用ＳＣプログラム６１２は、全てのログの署名の検証が完了したか否かを確認する。具体的には、運用ＳＣプログラム６１２は、ステップＳ５０３で運用ログテーブル１４００から取得した各エントリを対象処理ステップとして設定して、署名の検証処理を実施したか否かを確認する。この結果、全てのエントリが処理済みであれば（ステップＳ５１３：Ｙｅｓ）、運用ＳＣプログラム６１２は、処理をステップＳ５１４に進める一方、未処理のエントリがあれば（ステップＳ５１３：Ｎｏ）、処理をステップＳ５０３に進める。

ステップＳ５１４では、運用ＳＣプログラム６１２は、全てのＢＣノード３００に対して処理が完了したか否かを確認する。具体的には、運用ＳＣプログラム６１２は、ステップＳ５０１で生成したリストの全エントリに対応するＢＣノードを対象ＢＣノードに設定して運用処理の実行状態を確認したか否かを判定する。

この結果、全ＢＣノード３００での実行状態確認済みでない場合、すなわち、未確認のＢＣノード３００がある場合（ステップＳ５１４、Ｎｏ）、運用ＳＣプログラム６１２は、処理をステップＳ５０１に進める一方、未確認のＢＣノード３００が存在しない（ステップＳ５１４：Ｙｅｓ）場合には、処理をステップＳ５１５に進める。

ステップＳ５１５では、運用ＳＣプログラム６１２は、運用処理の実行状況確認結果をまとめて、データベース３３２を更新する。具体的には、運用ＳＣプログラム６１２は、未完了フラグと改竄フラグとに基づいて、トランザクションの実行状況を決定する。例えば、未完了フラグや改竄フラグが立っている場合には、トランザクションの実行状況は、実行中又は未完了となる。そして、運用ＳＣプログラム６１２は、決定した実行状況に基づき、ステップＳ５０１で運用トランザクション管理テーブル１３００から取得した完了確認対象のトランザクションのエントリの実行状態１３０３を更新する。その後、運用ＳＣプログラム６１２は、処理を終了する。

上記した処理によると、全ての組織１１０での運用処理の実行時の運用ログのチェックと、ログに付与された署名の検証を行って、運用ログに改竄がないかを確認でき、運用処理の実行状況を確認できる。

なお、本発明は、上述の実施形態に限定されるものではなく、本発明の趣旨を逸脱しない範囲で、適宜変形して実施することが可能である。

例えば、上記実施形態では、運用ログを、データベース３２３（運用ログテーブル１４００）と、運用用の分散台帳７００との両方で管理するようにしていたが、本発明はこれに限られず、データベース３２３と、分散台帳７００との少なくともいずれか一方で管理するようにしてもよい。

また、上記実施形態において、プロセッサが行っていた処理の一部又は全部を、ハードウェア回路で行うようにしてもよい。また、上記実施形態におけるプログラムは、プログラムソースからインストールされてよい。プログラムソースは、プログラム配布サーバ又は記憶メディア（例えば可搬型の記憶メディア）であってもよい。

１００：ＢＣシステム、２００：クライアント、３００：ＢＣノード、３２１：運用エージェント、３３１：ＢＣ管理情報、３３２：データベース、４００：ストレージ、５００：管理端末、６００：ＢＣプログラム、７００：分散台帳

Claims (11)

1. 所定の対象のトランザクションについての第１分散台帳を管理する複数の分散台帳装置を備える分散台帳システムにおける分散台帳装置であって、
   前記分散台帳装置は、
   記憶デバイスと、プロセッサ部とを備え、
   前記記憶デバイスは、前記第１分散台帳を記憶し、
   前記プロセッサ部は、前記第１分散台帳に関わる処理を実行した場合に、前記処理の内容を示す内容情報を、前記第１分散台帳を管理する他の分散台帳装置で管理させるために送信する
   分散台帳装置。
2. 前記プロセッサ部は、
   前記内容情報を、前記第１分散台帳を管理する複数の分散台帳装置が管理する第２分散台帳に登録させる指示を送信する
   請求項１に記載の分散台帳装置。
3. 前記プロセッサ部は、
   前記内容情報を、前記第１分散台帳を管理する複数の分散台帳装置のそれぞれの前記記憶デバイスにおけるデータベースに登録させる指示を送信する
   請求項１又は請求項２に記載の分散台帳装置。
4. 前記プロセッサ部は、
   前記内容情報に対して前記分散台帳装置の秘密鍵を用いた署名を付して送信する
   請求項１から請求項３のいずれか一項に記載の分散台帳装置。
5. 前記分散台帳装置は、前記第１分散台帳の処理に関与可能な周辺コンポーネントと接続されており、
   前記プロセッサ部は、前記内容情報を、前記処理に関与した前記周辺コンポーネントから取得する、
   請求項１から請求項３のいずれか一項に記載の分散台帳装置。
6. 前記プロセッサ部は、
   前記周辺コンポーネントから、前記内容情報に対する、前記周辺コンポーネントの秘密鍵を用いた署名を取得し、
   前記内容情報に対して、取得した署名を付して送信する
   請求項５に記載の分散台帳装置。
7. 前記プロセッサ部は、
   前記内容情報に付された署名に使用した秘密鍵に対応する公開鍵を取得し、前記公開鍵を用いて前記署名が正しいか否かを判定し、
   判定の結果に基づいた前記内容情報に対応する処理の実行状態を、前記他の分散台帳装置で管理させるために送信する
   請求項４又は請求項６に記載の分散台帳装置。
8. 前記プロセッサ部は、
   前記第１分散台帳に関わる処理の実行要求を受け取った場合に、前記実行要求をデータベースに登録するとともに、前記実行要求に対応する前記第１分散台帳に関わる処理を実行させるための処理要求を発行し、
   処理要求に対応する処理を実行する場合には、前記データベースに、前記処理要求の基となる実行要求が存在するか否かを判定し、
   前記データベースに、処理要求の基となる実行要求が存在していない場合に、前記処理要求に対応する処理の実行を行わないようにする
   請求項１から請求項７のいずれか一項に記載の分散台帳装置。
9. 前記第１分散台帳に関わる処理は、前記第１分散台帳のバックアップデータを削除する処理である
   請求項１から請求項８のいずれか一項に記載の分散台帳装置。
10. 所定の対象のトランザクションについての第１分散台帳を管理する複数の分散台帳装置を備える分散台帳システムであって、
    前記分散台帳装置は、
    記憶デバイスと、プロセッサ部とを備え、
    前記記憶デバイスは、前記第１分散台帳を記憶し、
    前記プロセッサ部は、前記第１分散台帳に関わる処理を実行した場合に、前記処理の内容を示す内容情報を、前記第１分散台帳を管理する他の分散台帳装置に対して送信する
    分散台帳システム。
11. 所定の対象のトランザクションについての第１分散台帳を管理する複数の分散台帳装置を備える分散台帳システムにおける分散台帳装置による分散台帳管理方法であって、
    記憶デバイスに記憶された前記第１分散台帳に関わる運用処理を実行し、
    前記第１分散台帳に関わる運用処理の内容を示す内容情報を、前記第１分散台帳を管理する他の分散台帳装置に対して送信する
    分散台帳管理方法。