JP2019028525A - 運用管理方法、運用管理システム、および、運用管理プログラム - Google Patents

Abstract

【課題】分散台帳システムにおいて管理者が複数存在する状況下でも、ノード間でポリシーやタイミングを揃えた運用管理を可能とする。【解決手段】運用管理システム１０において、複数のノードで構成される分散台帳システム６において、前記複数のノード３のうち少なくとも所定の複数ノードは、それぞれ、分散台帳３７にて当該分散台帳システム６の運用管理用の運用スマートコントラクト３７２を管理し、前記所定の複数ノードのうち少なくとも１つのノードがトランザクションを受け取った場合、当該ノードは、当該トランザクションの種別が運用スマートコントラクト３７２か否かを判定し、当該判定結果に基づき運用スマートコントラクト３７２を実行する構成とする。【選択図】図２

Description

本発明は、分散台帳システムの運用管理方法、運用管理システム、および、運用管理プログラムに関するものであり、具体的には、分散台帳システムにおいて管理者が複数存在する状況下でも、ノード間でポリシーやタイミングを揃えた運用管理を可能とする技術に関する。

従来、各種取引の多くは、金融機関や政府などの信頼できる中央集権機関を経由して実施されてきた。ところが近年では、従来の取引形態と異なる、利用者間のＰ２Ｐ（Ｐｅｅｒ ｔｏ Ｐｅｅｒ）取引が提案され、その取引の実装手段として分散台帳技術が存在する。

こうした分散台帳技術の例として、ビットコインと呼ばれる仮想通貨を用いて、銀行などの中央集権機関を必要とせずに決済取引を行う技術（非特許文献１参考）がある。ビットコインでは、Ｐ２Ｐネットワーク上における取引データ（以下、トランザクションとも称する）について、マイナーと呼ばれるノードがその正当性を判定後、プルーフオブワークと呼ばれる特定の作業（ハッシュ値を算出）で確定処理を行っている。

上述のように確定処理されたトランザクションは、１つのブロックにまとめられ、各ノードにおいてブロックチェーン（以下、ＢＣとも称する）と呼ばれる分散台帳に記載される。
一方、上記のビットコイン技術で実装されたＢＣをベースにして、ＢＣおよび分散台帳に関して様々な派生技術も更に提案され、進化を続けている。

現状のＢＣの主な特徴としては、（１）ビジネスネットワーク上の参加者間の取引において、中央集権機関ではなく（任意ないしは特定の）参加者による合意形成や承認によって取引を確定させること、（２）複数のトランザクションをブロックとしてまとめ、これを数珠つなぎに分散台帳に記録し、連続するブロックにハッシュ計算を施すことにより、改ざんを実質不可能にすること、（３）参加者全員が同一の台帳データを共有することにより、参加者全員での取引の確認を可能とすること、などが挙げられる。

このような分散台帳を提供する基盤（以下、分散台帳基盤）を用いることで、中央集権機関による管理がなくとも、複数の主体間で情報共有や取引を行うことができる（例えば、特定業界のコンソーシアムやサプライチェーンに関係する複数企業等）。ここで、分散台帳に参加する参加者（およびそのノード）によって構成されるネットワークのことをビジネスネットワークと呼ぶ。

上述のＢＣをはじめとした分散台帳技術は、以上のような特徴から、信頼できるデータの管理／共有や、契約に基づく取引の執行／管理を行う仕組みとして、金融分野やＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇ）等、幅広い分野での応用が検討されている。

例えば、ビットコインのような単純な仮想通貨の取引だけでなく、複雑な取引条件や多様なアプリケーションにも適用可能とするために、分散台帳の中で（取引）データだけでなくロジックも管理できるようになってきている。このロジックはスマートコントラクト（以下、ＳＣとも称する）と呼ばれる。

一方、ＳＣの実行機能を有する分散台帳基盤（非特許文献２および非特許文献３参照）
では、ノード間で所定の合意水準で合意形成しながらトランザクション（以下、ＴＸとも称する）を受け入れて、各ノードでＴＸを実行することにより、複数ノード上で情報（台帳）を共有する。また、ＴＸに対して予め決めたロジックを実行するスマートコントラクト（ＳＣ）実行機能を備える。

"Ａ Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ Ｅｌｅｃｔｒｏｎｉｃ Ｃａｓｈ Ｓｙｓｔｅｍ"， ［ｏｎｌｉｎｅ］、［平成２９年３月３１日検索］、インターネット＜ＵＲＬ：ｈｔｔｐｓ：／／ｂｉｔｃｏｉｎ．ｏｒｇ／ｂｉｔｃｏｉｎ．ｐｄｆ＞ "Ｅｔｈｅｒｅｕｍ Ｗｈｉｔｅ Ｐａｐｅｒ"， ［ｏｎｌｉｎｅ］、［平成２９年３月３１日検索］、インターネット＜ＵＲＬ：ｈｔｔｐｓ：／／ｇｉｔｈｕｂ．ｃｏｍ／ｅｔｈｅｒｅｕｍ／ｗｉｋｉ／ｗｉｋｉ／［Ｅｎｇｌｉｓｈ］−Ｗｈｉｔｅ−Ｐａｐｅｒ＞ "Ｈｙｐｅｒｌｅｄｇｅｒ Ｆａｂｒｉｃ"， ［ｏｎｌｉｎｅ］、［平成２９年３月３１日検索］、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｈｙｐｅｒｌｅｄｇｅｒ−ｆａｂｒｉｃ．ｒｅａｄｔｈｅｄｏｃｓ．ｉｏ／ｅｎ／ｌａｔｅｓｔ／＞

上述の分散台帳技術を用いて構築したシステム（以下、分散台帳システム）を本番稼働させるためには、従来型システム（例：例えばＷｅｂサーバとＤＢサーバを用いたＷｅｂシステム）と同等にシステム運用管理（例：台帳のバックアップ／リストア、サービス停止など）が必要となる。

一方、分散台帳システムは、複数の主体でコンソーシアム等を構成してビジネスネットワークが構築／運用されるケースがある。言い換えると、分散台帳システムは複数の組織にまたがって構成されうる。

そのような分散台帳システムに対して従来型システムの運用管理手法を適用した場合、第一の方法として、すべてのノードを単独運用者が運用管理する方法と、第二の方法として、各ノードの運用者（例えば、各組織のノードの所有者）がそれぞれ個別に運用管理する方法が考えられる。

このうち第一の方法を用いた場合には、運用が中央集権化してしまい、ＢＣシステムの特徴であった非中央集権性の強みが薄れてしまうという問題点がある。また、マルチベンダでの運用には対応することができない課題も残る。一方、第二の方法を用いた場合には、管理者やポリシーが組織ごとに別々であるため、同じ取り決めやタイミングで運用できないという問題点がある。そもそも分散台帳システムでは、管理者が異なれば他組織のノードにアクセスできず、また運用方法やポリシーが組織間でバラバラで、同じ取り決めやタイミングで運用実行できない背景がある。

そこで本発明の目的は、分散台帳システムにおいて管理者が複数存在する状況下でも、ノード間でポリシーやタイミングを揃えた運用管理を可能とする技術を提供することにある。

上記課題を解決する本発明の運用管理方法は、複数のノードで構成される分散台帳システムにおいて、前記複数のノードのうち少なくとも所定の複数ノードは、それぞれ、分散台帳にて当該分散台帳システムの運用管理用の運用スマートコントラクトを管理し、前記
所定の複数ノードのうち少なくとも１つのノードがトランザクションを受け取った場合、前記トランザクションを受け取ったノードは、前記トランザクションの種別が前記運用スマートコントラクトか否かを判定し、当該判定結果に基づき、前記運用スマートコントラクトを実行することを特徴とする。

また、本発明の運用管理システムは、分散台帳システムの複数のノードで構成されるシステムであって、前記複数のノードのうち少なくとも所定の複数ノードは、それぞれ、分散台帳にて当該分散台帳システムの運用管理用の運用スマートコントラクトを管理し、前記所定の複数ノードのうち少なくとも１つのノードがトランザクションを受け取った場合、前記トランザクションを受け取ったノードは、前記トランザクションの種別が前記運用スマートコントラクトか否かを判定し、当該判定結果に基づき、前記運用スマートコントラクトを実行するものであることを特徴とする。

また、本発明の運用管理プログラムは、分散台帳システムを構成する複数のノードのうち少なくとも所定の複数ノードであって、分散台帳にて当該分散台帳システムの運用管理用の運用スマートコントラクトを管理するノード各々に、前記所定の複数ノードのうち少なくとも１つのノードがトランザクションを受け取った場合、前記トランザクションを受け取ったノードにおいて、前記トランザクションの種別が前記運用スマートコントラクトか否かを判定し、当該判定結果に基づき、前記運用スマートコントラクトを実行させることを特徴とする。

本発明によれば、分散台帳システムにおいて管理者が複数存在する状況下でも、ノード間でポリシーやタイミングを揃えた運用管理が可能となる。

本実施形態の運用管理方法における基本概念を示す図である。 実施例１における運用管理システムを模式的に示す図である。 実施例１における分散台帳ノードの物理的な構成を示すブロック図である。 本実施形態における分散台帳上のブロックチェーンのデータ構造例を示す図である。 本実施形態における分散台帳上のステート情報のデータ構造例を示す図である。 本実施形態におけるシステム運用ＳＣのデータ構造および関数の定義例を示す図である。 本実施形態におけるビジネスネットワークのメンバー新規登録処理の例を示すフロー図である。 本実施形態における業務ＳＣおよびシステム運用ＳＣのトランザクション処理例を示すフロー図である。 実施例１における運用管理システム全体としてのシステム運用ＳＣに従った運用作業実行の流れを示すフロー図である。 本実施形態におけるシステム運用ＳＣのデプロイＴＸの内部処理例を示すフロー図である。 本実施形態におけるシステム運用ＳＣのＳＣ関数「運用実行」呼び出し時の内部処理例を示すフロー図である。 本実施形態における運用管理アプリの画面例を示す図である。 実施例２における運用管理システム全体としてのシステム運用ＳＣに従った運用実行受付、作業実行、実行完了登録、リカバリ処理までの一連の流れを示すフロー図である。 本実施形態におけるシステム運用ＳＣのＳＣ関数「運用実行受付」呼び出し時の内部処理例を示すフロー図である。 本実施形態におけるシステム運用ＳＣのＳＣ関数「運用実行完了登録」呼び出し時の内部処理例を示すフロー図である。 本実施形態におけるシステム運用ＳＣのＳＣ関数「運用失敗リカバリ」呼び出し時の内部処理例を示す図である。 実施例３における運用管理システム全体としてのシステム運用ＳＣに従った運用実行受付、承認、作業実行処理までの一連の流れを示すフロー図である。 実施例３における運用実行受付処理として、システム運用ＳＣのＳＣ関数「運用実行受付」呼び出し時の内部処理例を示すフロー図である。 本実施形態におけるシステム運用ＳＣのＳＣ関数「運用実行承認」呼び出し時の内部処理例を示すフロー図である。 実施例４における運用管理システムを模式的に示す図である。 実施例４における運用作業の定期実行処理の例を示すフロー図である。 実施例５における運用作業の定期実行処理の例を示すフロー図である。 実施例６におけるシステム運用ＳＣ管理用のメタコントラクトにおけるシステム運用ＳＣの新規登録の受付処理例を示す図である。 実施例６におけるシステム運用ＳＣ管理用のメタコントラクトにおけるシステム運用ＳＣの新規登録の承認処理例を示す図である。 実施例７における運用管理システムとその管理対象たる分散処理システムのネットワーク構成例を示す図である。

−−−実施例１−−−

図１に本実施形態の運用管理方法における基本概念を示す。本実施形態では、システム運用作業を、分散台帳上で管理するＴＸあるいはＳＣとして取り扱うことで、分散台帳システム６を構成する分散台帳ノード３の間で合意形成しながらシステム運用作業を実施する。

また、この場合の分散台帳システム６は、各分散台帳ノード３において、システム運用作業のための運用スマートコントラクト３７２（以下、システム運用ＳＣ）を管理し、このシステム運用ＳＣに対応する運用実行機能（例えば、運用コマンドや管理ＡＰＩ機能、運用実行を行うプログラムやエージェント等）を備える（本発明ではこのような機能を提供するプログラムを運用実行プログラム３６と称する）。

ここでは一例として、分散台帳システム６を構成する分散台帳ノード３に対して、運用実行要求としてシステム運用ＳＣの実行ＴＸが発行されると、分散台帳ノード３の間でこのＴＸに対する合意形成がされる。また、この合意形成の後、各分散台帳ノード３上でこのシステム運用ＳＣにて定義された運用手順（例：運用コマンド群）に従って運用作業が実行される。このようにして、複数の分散台帳ノードの間で合意形成を行いながら、非中央集権的かつ同時並行的に運用作業を実行する。

続いて、上述の基本概念を実装するコンピュータシステム、すなわち運用管理システム１０の構成例について説明する。図２は、実施例１における運用管理システム１０を模式的に示す図である。

例示する運用管理システム１０は、１台以上の分散台帳ノード３、１台以上のクライアントノード４によって構成される（分散台帳システムとも言える）。これらの機器は、物理的な通信回線２を通してネットワーク１に接続される。

上述の構成のうち分散台帳ノード３は、コンセンサス管理部３１、スマートコントラクト実行／管理部３２（以下、ＳＣ実行／管理部３２とも称する）、メンバー管理部３３、トランザクション管理部３４、トランザクション発行部３５、分散台帳３７、参加メンバー管理情報３８によって構成される。

このうちコンセンサス管理部３１は、ネットワークプロトコル部３１１を備える。また、分散台帳ノード３は、トランザクション管理部３４の機能によりＴＸを受け付けて、コンセンサス管理部３１の機能によって、他のノードとの間でＴＸを受け入れてよいかの合意形成を行う。また、この分散台帳ノード３は、上述の合意形成がなされたら、ＳＣ実行／管理部３２の機能を介して、ＳＣのデプロイ、デプロイ済みのＳＣに対する実行を行い、ＴＸの履歴とその実行結果を分散台帳３７に記録する。

なお、分散台帳ノード３の各間の通信は、ネットワークプロトコル部３１１の機能によって行う。また、分散台帳ノード３のトランザクション管理部３４は、クライアントノード４等の各ノードからの要求に対して、ＴＸを受け付けたり、ＴＸの履歴情報を取得・閲覧したりする機能／インタフェースを提供する。本実施例では、分散台帳ノード３がＴＸ発行可能であることとし、トランザクション発行部３５を介して各種ＴＸを発行する。

また、分散台帳ノード３のメンバー管理部３３は、ビジネスネットワークに参加するメンバーの新規発行や認証機能を提供する。メンバー管理では、秘密鍵と公開鍵のペアを用いて、参加メンバーの認証やＴＸへの署名、ＳＣ実行権限の制御等を行うことを想定する。こうしたメンバー管理に関する鍵情報は、参加メンバー管理情報３８上に格納・管理される。

トランザクション管理部３４は、ＴＸを受け付けた際に、適宜、メンバー管理部３３の機能を介して、ＴＸの発行者が権限を持った正しい参加者かどうかを確認するが、こうした構成自体は適宜な公知技術を採用すればよく、詳細説明は省略する。

また、分散台帳３７では、業務に関するＳＣ（以下、業務ＳＣ３７１）およびシステム運用ＳＣ３７２に関わる台帳情報を格納・管理する。そのデータ構造としては、本実施例では、ＴＸの履歴をＢＣとして、ＴＸの実行結果に基づくステート情報をテーブル上で保持することを想定する。

なお、分散台帳ノード３における運用実行プログラム３６は、システム運用ＳＣ３７２内で定義された運用手順を実行するプログラムである。具体的には、運用コマンドや管理ＡＰＩ機能、それらの実行の組合せを記述したり、プラットフォーム依存部分を隠蔽したりした運用スクリプト、運用管理機能を実行するエージェント等を想定する。
この運用実行プログラム３６は、予め分散台帳ノード３上に配置されていても良いし、システム運用ＳＣ３７２をデプロイするタイミングで配置されても良い。

一方、クライアントノード４は、トランザクション発行部３５、業務アプリ４１、および、運用管理アプリ４２によって構成される。ＳＣの利用者もしくは提供者は、クライアントノード４のトランザクション発行部３５を介して各種ＴＸを発行し、これをそれぞれの分散台帳ノード３に対して送信する。

なお、ＴＸには発行者情報を付与するが、この情報としては参加メンバー管理情報３８によって発行された認証情報（秘密鍵）を利用する。業務アプリ４１は、トランザクション発行部３５を介して、業務ＳＣ３７１に関するＴＸを発行することで、業務処理を実行／管理するアプリである。運用管理アプリ４２は、トランザクション発行部３５を介して、システム運用ＳＣ３７２に関するＴＸを発行することで、システム運用作業を実行／管
理するアプリである。

本実施例では、例えば、それぞれ異なる主体によって管理される、複数台の分散台帳ノード３の存在を想定する。上述の主体は、例えば、事業者、組織、ベンダである。同様に、クライアントノード４も複数台存在し、複数のＳＣ利用者がそれぞれ別のクライアントノード４を利用することを想定する。なお、クライアントノード４に関しては、ＴＸに付与する認証情報をユーザ毎に切り替えることにより、複数のＳＣ利用者が共用することも可能である。

続いて、実施例１における分散台帳ノード３の物理的な構成について説明する。図３は、実施例１における分散台帳ノード３の物理的な構成例を示すブロック図である。

本実施例における分散台帳ノード３は、インタフェース（Ｉ／Ｆ）１００、演算装置たるプロセッサ１０１、および、記憶装置たるメモリ１０２を備える計算機である。
なお、これらＩ／Ｆ１００、プロセッサ１０１、および、メモリ１０２は、データバス１０３によって接続されている。

このような構成を備える分散台帳ノード３は、Ｉ／Ｆ１００を介して、ネットワーク１と通信する。プロセッサ１０１は、ＣＰＵ等の演算装置である。メモリ１０２は、プログラムおよびデータを保持するための記憶装置である。プロセッサ１０１は、メモリ１０２からデータバス１０３を介してプログラム１１０（運用管理プログラム）を読み出し、実行することで必要な機能を実装する。

次に、分散台帳３７の構成例について説明する。図４および図５は、分散台帳３７に格納するデータ構造の一例を示す図である。このうち図４は、分散台帳３７上で管理するデータ構造の一つであるＢＣの例を示す図である。

ＢＣを用いた分散台帳管理では、複数のＴＸをブロックとしてまとめて、各ブロックが前のブロックのハッシュ値を持つことでデータを数珠つなぎにして管理する。こうした構成において前段のブロックの値が１ビットでも変わると後続の全ブロックのハッシュ値が変化するため、改ざんを困難にすることができる。なお、本実施例では説明をシンプルにするために、１つのＴＸにつき１ブロックとするが、本発明は、複数ＴＸをまとめて１ブロックに格納した場合にも適用可能である。

図４におけるブロック３７１２〜ブロック３７２１、ブロック３７２１〜ブロック３７２２、および、ブロック３７１３は、一連のブロックの連なり、すなわちＢＣとなる。

各ブロックは、それぞれ業務ＳＣのデプロイ、実行、システム運用ＳＣのデプロイ、実行、いずれかのＴＸ情報を含む。また各ブロックはそのブロックの生成に関するタイムスタンプ情報を含む。さらに各ブロックは、前ブロックのハッシュ値を含み、後述のステート情報から生成したハッシュ値を含む。
上記のようなデータ構造により、業務ＳＣのデプロイ、実行、システム運用ＳＣのデプロイ、実行ＴＸがＢＣの中でデータの連鎖として管理されることとなる。

こうしたＢＣを構成するブロックのうちブロック３７１１は、業務ＳＣ３７１のデプロイＴＸを格納したブロックの一例である。この例では、貨物輸送に関するビジネスコントラクトの例を示している。

本実施例のデプロイＴＸは、コントラクトが業務かシステム運用かを特定するコントラクト種別、コントラクトを一意に識別するコントラクトＩＤ、コントラクトの実態（例え
ば実行可能なバイナリ）を含む。また、コントラクトが持つ関数名やその引数を利用者が把握するためのコントラクト入力仕様を含む。

さらに、デプロイ時に指定した入力引数にしたがって決めたパラメータ（例えばコントラクトの利用者や各種定義情報等）であるコントラクトメタ定義を含む。また、このデプロイＴＸの発行元、すなわち、提供者を識別するためのＩＤ情報を含む。さらに発行元とデータに改ざんが無いことを検証するために用いる電子署名を含む。この電子署名はメンバー管理部３３が発行した各ネットワーク参加メンバー（すなわちＳＣ提供者や利用者）の秘密鍵を用いて生成され、そのペアとなる公開鍵によって検証をすることが可能である。

また、ブロック３７１２は業務ＳＣ３７１の実行ＴＸを格納したブロックの一例である。本実施例の実行ＴＸは、呼び出し対象となるコントラクトのコントラクトＩＤ、呼び出し対象となるコントラクトの関数名と入力する引数の情報を含む。

さらにこの本番実行ＴＸの発行元、すなわち、利用者を識別するためのＩＤ情報を含む。さらに発行元とデータに改ざんがないことを検証するために用いる利用者署名を含む。なお、発行元だけでなく、合意形成に関わったネットワーク参加者の情報も管理／保持してもよい。

また、ブロック３７２１およびブロック３７２２は、システム運用ＳＣ３７２のデプロイＴＸおよび実行ＴＸを格納したブロックの一例である。本実施例のシステム運用ＳＣ３７２のデプロイＴＸおよび実行ＴＸは、大枠のデータ構造としては、業務ＳＣ３７１の同ＴＸと同様の情報を含む。単純に業務に関わるＳＣが記述されているか、システム運用に関するＳＣが記述されているかの違いしかない想定である。これにより分散台帳システム６の内部（具体的には分散台帳ノード３の３１〜３５の各機能）に手を加えなくとも、外側の機能として本発明を実装することが可能である。以降では、ＳＣが持つ関数のことをＳＣ関数とも称する。

図５は、本実施例の分散台帳３７上で管理するステート情報を示す図である。ＢＣを用いた分散台帳管理では、通常、（最新の）ステート（例えば、仮想通貨の場合にはアカウントの残高）を取得するためには、ＢＣを辿らなければならない。これでは処理効率が悪いため、ＢＣとは別に、最新のステート情報をキャッシュしておく方法が存在する（非特許文献３等）。よって本実施例でも最新のステート情報を保持することを想定する。
本実施例では、コントラクト毎にステートのデータ領域が用意されることとする。ステート情報は、コントラクトＩＤとそのコントラクトの実態を保持する。

これにより、分散台帳ノード３のＳＣ実行／管理部３２は、コントラクトＩＤをキーにして、コントラクトの実態を取得して実行することができる。また、ステート情報はＳＣの実行結果を保持するための内部テーブルを備える。ＴＸが実行される度にこの内部テーブルの内容を更新する。本ステート情報に関しても業務ＳＣ３７１とシステム運用ＳＣ３７２の両方のＳＣの情報が格納される。

続いて、本実施例におけるシステム運用ＳＣ３７２の具体例について説明する。図６は、システム運用ＳＣ３７２のデータ構造およびＳＣ関数の例を示す図である。

システム運用ＳＣ３７２におけるデータ構造は、ステート情報として管理・保持される。システム運用ＳＣ３７２内のデータ構造では、システム運用に関するポリシーとして、「合意形成ポリシー」、「運用内容定義」、「運用手順」が記述されている。

このうち「合意形成ポリシー」は、各運用作業に対応するシステム運用ＳＣ３７２をどのノード上で合意を取って、どのノード上で実行するかを管理する情報である。ここでは、合意形成ポリシーは、システム運用ＳＣ３７２の内部情報として管理されている想定だが、合意形成ポリシーはシステム運用ＳＣ３７２の外側で管理されていてもよい（その管理方法は基盤の実装にも依存する）。

また、「運用内容定義」は、運用作業の概要を示す情報である。「運用手順」には、本運用作業で行う運用プロセスや個々の運用操作（運用コマンド、管理ＡＰＩ等の呼び出し）が定義／管理されている。運用手順はソースコードベース（例えば、運用コマンドの羅列）で記述されていることが望ましい。ソースコードベースとすることで、運用作業を均一的に行うことができる。「運用実行履歴情報」は、システム運用ＳＣで定義した運用作業の実行履歴である。

なお、ＳＣ関数としては、「運用定義設定」、「運用定義参照」、「運用実行履歴参照」、「運用実行」が定義されることとする。システム運用ＳＣ３７２に対する実行ＴＸの発行時にこれらの各ＳＣ関数が指定されて実行される。

「運用定義設定」は、本ＳＣで定義した運用作業の定義変更を行うＳＣ関数である。基本的に、運用作業の定義は、デプロイ時（デプロイＴＸ発行時）に設定される想定だが、運用ポリシーの変更が必要な場合には、本ＳＣ関数を利用することで定義の更新も行えることとする。

また、「運用定義参照」と「運用実行履歴参照」は、システム運用ＳＣ３７２で定義された運用定義およびその実行履歴の情報を取得／参照するためのＳＣ関数である。

また、「運用実行」は、システム運用ＳＣ３７２で定義した運用作業を実行するＳＣ関数である。運用作業中で実行される運用手順は、主にデータ構造「運用手順」中に記述されている想定だが、「運用作業」のＳＣ関数中のコードとして記述されていてもよい。どちらの場合にも、コードベースにより、運用作業を共通化することが可能である。

ここで「運用実行」は単純な運用実行だけでなく、運用作業のパターンによって、いくつかのバリエーションが考えられる。例えば、「運用実行」処理を、受付処理を行う「運用実行受付」と、受け付けた運用実行の完了を登録する「運用実行完了登録」とに分けてもよい。

また運用実行が途中で失敗した場合に実行するリカバリ処理を、ＳＣ関数（例：「運用失敗リカバリ」）に定義しておいてもよい。さらには、運用実行前に管理者／管理組織による明示的な承認プロセスを設けたい場合には、ＳＣ関数「運用実行承認」を用意してもよい。実施例１では単純に運用実行処理を行うケースを示し、これらのバリエーションについては実施例２以降で述べる。

なお、図６に示したシステム運用ＳＣ３７２の例では、特定のシステム運用作業ではなく、システム運用作業の共通的な雛形を想定した記載となっている。実際には、この雛形に従って「バックアップ運用」等の具体的な運用作業が当てはめられる。

具体的な運用作業のあてはめ方（システム運用ＳＣの定義方法）としては、具体的な運用作業毎にシステム運用ＳＣを定義してもよいし、共通のシステム運用ＳＣを用意しておいて、デプロイ時引数などのパラメータ入力によって具体的な運用作業に関する情報を定義してもよい。また、一つのシステム運用ＳＣの中で単一の運用作業を管理してもよいし(その場合には例えば、コントラクトＩＤ毎に異なる種類の運用作業が管理される)、２種
類以上の運用作業を管理してもよい（その場合には例えば、図５の定義ＩＤ毎に異なる種類の運用作業が管理される）。

ここで、システム運用作業の例としては、分散台帳データのバックアップ／リストア作業、分散台帳システムに関するサービス停止作業、障害分析や監査を目的とした各ノードからのシステムログ取得作業、明示的な承認プロセスを伴うノード／リソース増減やＳＣ更新作業、システム緊急対策作業（セキュリティ対策、障害対策）等が挙げられる。こうした各種の運用作業のうち、以降の実施例の説明では、必要に応じて、分散台帳ノード３が管理する台帳データのバックアップ運用作業を具体例として説明を行っていく。

なお、図６中の右側の吹き出し３７２５では、台帳データのバックアップ運用を例とした運用手順の具体的なイメージを示す。ＳＣ関数「運用実行」中もしくはデータ構造「運用手順」中には、吹き出し３７２５中の“例１）”にて示す通り、運用作業のコマンド列が列挙されていてもよいし、“例２）”にて示す通り、呼び出し先となる運用実行プログラム３６（例えば、運用実行コマンド列を記載した外部プログラム）や関連する設定ファイルが示されていてもよい。

次に、実施例１における運用管理方法のフロー例について説明する。実施例１では、運用管理方法の基本形として、システム運用ＳＣ３７２で定義された運用作業を単純に実行する例を示す。

図７は、ビジネスネットワークに参加するメンバーの新規登録処理の例を示すフローチャートである。この場合、分散台帳ノード３のメンバー管理部３３は、クライアントノード４等の他ノードからメンバー登録要求を受け付ける（Ｓ１０１）。このメンバー登録要求には、要求メンバーを一意に識別するメンバーＩＤが含まれることとする。

続いて、メンバー管理部３３は、適宜なアルゴリズムにて秘密鍵と公開鍵の組を生成し、この組みを、Ｓ１０１で受け取ったメンバーＩＤと紐付ける（Ｓ１０２）。

次に、メンバー管理部３３は、Ｓ１０１得た新規登録対象となるメンバーＩＤと、Ｓ１０２で生成した公開鍵とを、他のノードにブロードキャストする（Ｓ１０３）。ここでブロードキャストされたメンバーＩＤおよび公開鍵の情報は、各ノード上で参加メンバー管理情報３８として保管する。

さらに、メンバー管理部３３は、メンバー登録要求を行ったノード（Ｓ１０１の契機となったノード）に対し、Ｓ１０２で生成した秘密鍵を返す（Ｓ１０４）。一方、この秘密鍵を受け取ったノードは、参加メンバー管理情報３８に自身の秘密鍵として保管する。

本実施例では、以上のようにして生成した秘密鍵と公開鍵のペアを用いて、ネットワーク参加メンバーの認証やＴＸへの署名、ＳＣ実行権限の制御等を行うことを想定する。

具体的には、例えば、クライアントノード４側は、発行された秘密鍵で電子署名したＴＸを発行し、検証ノード側が公開鍵を用いて電子署名を検証することで、本人確認を実現できる。

なお、公開鍵と秘密鍵の組を生成する手法や署名検証をする手法、鍵とＩＤを紐付ける手法については、公知または周知の技術を適用すれば良いので、本実施例１では詳述しない。また、本実施例では、メンバー管理部３３の機能を分散台帳ノード３中に機能として示したが、外部にメンバー管理専用のノードを立ててそのノードがメンバー管理部３３と同等の機能を提供するとしてもよい。

続いて、ＴＸ実行処理について説明する。図８は、ＴＸ実行処理、すなわち、業務ＳＣのデプロイ、実行、システム運用ＳＣのデプロイ、実行処理の例を示すフローチャートである。

この場合、分散台帳ノード３のトランザクション管理部３４が、クライアントノード４等のＴＸ発行元からＴＸを受け取り（Ｓ２０１）、これをコンセンサス管理部３１に渡すことで、ＳＣ／ＴＸの種別に応じて、業務ＳＣ３７１のデプロイ、実行、システム運用ＳＣ３７２のデプロイ、実行処理を行う。

コンセンサス管理部３１は、トランザクション管理部３４から受け取ったＴＸが、業務ＳＣ３７１のデプロイＴＸであった場合（Ｓ２０２：ＮＯ、Ｓ２０３：ＹＥＳ）、他の分散台帳ノード３との間で、受け取ったＴＸを実行してよいか、ブロックとして、ＢＣの末尾に追加してよいかの合意形成処理を行う（Ｓ２０４）。

具体的な合意形成処理方式としては、公知または周知の技術を適用すれば良い。具体的には、例えば、Ｐｌａｃｔｉｃａｌ Ｂｙｚａｎｔｉｎｅ Ｆａｕｌｔ Ｔｏｒｅｒａｎｃｅ（ＰＢＦＴ）と呼ばれるアルゴリズム等を採用することが考えられる。ＰＢＦＴは合意形成に参加するすべてのノード（すなわち検証ノード）の間で一定（３分の２）以上のノードによる合意を条件とするアルゴリズムである。

上述のＰＢＦＴをベースとした合意形成を簡単に説明すると、分散台帳ノード３は、受け取ったＴＸをネットワークに参加するすべての分散台帳ノード３に対してブロードキャストする。一方、各分散台帳ノード３では、ＴＸに対する署名検証を行って改ざんがされていないことやＴＸの内容の正当性を確認し、その確認結果を他の分散台帳ノード３に対してブロードキャストする。

一定数以上の分散台帳ノード３による確認が取れた場合、分散台帳ノード３は、ＴＸの承認準備が完了したことを他の分散台帳ノード３に対してブロードキャストする。そして、一定数以上の分散台帳ノード３による承認準備完了が確認できたことをもって合意形成が完了する。

こうして合意形成が完了したら、コンセンサス管理部３１は、ＳＣ実行／管理部３２を介して、ＴＸに含まれるＳＣを分散台帳３７に登録する（Ｓ２０５）。具体的には、ＴＸの内容に基づき、コントラクトＩＤやコントラクト実態を分散台帳３７上のステート情報として登録し、ＢＣの末尾にこのデプロイＴＸを含むブロックを追加する。
最後に、コンセンサス管理部３１は、デプロイＴＸの実行結果をＴＸ発行元に返す（Ｓ２０６）。

一方、トランザクション管理部３４から受け取ったＴＸが業務ＳＣ３７１の実行ＴＸの場合（Ｓ２０２：ＮＯ、Ｓ２０３：ＮＯ）、コンセンサス管理部３１は、デプロイＴＸと同様に合意形成処理を行う（Ｓ２０７）。この合意形成処理はＳ２０４と同様である。
この合意形成が完了したら、コンセンサス管理部３１は、ＳＣ実行／管理部３２を介して、ＳＣを実行して分散台帳３７の内容を更新する（Ｓ２０８）。

具体的には、実行ＴＸ内で指定されたコントラクトＩＤを持つＳＣ（登録済みであることを前提とする）に対して、実行ＴＸ内で指定された呼び出し関数と入力引数を与えて実行する。そして、その結果に基づき、分散台帳３７の内容を更新する。また、コンセンサス管理部３１は、実行結果に基づいて、本コントラクトに関するステート情報５０２を更新し、ＢＣの末尾のブロックとして実行ＴＸを追加する。
最後に、コンセンサス管理部３１は、この実行ＴＸの実行結果（例えば、関数の戻り値）をＴＸ発行元に返す（Ｓ２０９）。

他方、トランザクション管理部３４から受け取ったＴＸがシステム運用ＳＣ３７２のＴＸの場合（Ｓ２０２：ＹＥＳ）、コンセンサス管理部３１は、業務ＳＣ３７１の場合と同様にＳＣのデプロイもしくは実行処理を行う（Ｓ２１０〜Ｓ２１５）。

ただし、業務ではなくシステム運用ＳＣ３７２で指定された運用手順を実行する点が異なる（Ｓ２１４）。その運用作業の実行自体は運用実行プログラム３６の機能によって行われる。
ここで、実施例１におけるシステム全体としてのシステム運用ＳＣ３７２に従った運用作業実行の流れについて、図９に基づき説明する。

この場合、あるノードがシステム運用ＳＣ３７２のデプロイＴＸを発行すると（Ｓ１００１）、各分散台帳ノード３はそのＴＸを受け取り、ノード間で合意形成を行った上で、ＴＸに従ってシステム運用ＳＣ３７２をデプロイする（Ｓ１００２）。

システム運用ＳＣ３７２がデプロイされた後、運用作業実行のタイミングで、あるノードから、上記システム運用ＳＣ３７２に対する運用実行ＴＸとしてＳＣ関数「運用実行」の呼び出しが発行されると（Ｓ１００３）、各分散台帳ノード３はそのＴＸを受け取り、ノード間で合意形成を行った上で、運用実行ＴＸに従って運用作業を実行する（Ｓ１００４）。

ここで、運用作業実行のタイミングは、ＳＣで定義した運用作業の実行権限のあるいずれかの管理者によってシステム運用アプリ４２の表示画面上の操作をもって運用実行ＴＸが発行されたタイミングや、各ノードの直接操作によって運用実行ＴＸが発行されたタイミング、或いは、スケジューリングされた定期実行契機に運用実行ＴＸが自動発行されたタイミング、などを想定できる。

図１０はシステム運用ＳＣ３７２のデプロイＴＸの内部処理例を示すフローチャートである。各分散台帳ノード３は、合意形成済みのシステム運用ＳＣ３７２のデプロイＴＸを受け取る（Ｓ３０１）と、ＳＣ実行／管理部３２の機能によりシステム運用ＳＣ３７２のデプロイ処理を行う。
具体的には、分散台帳ノード３は、まずデプロイＴＸに従ってシステム運用ＳＣ３７２のコントラクト実態の配置を行う（Ｓ３０２）。

このコントラクトが外部で管理され、運用実行プログラム３６のインストールが不要の場合、すなわち、各分散台帳ノード３上に標準で導入済みであったり、コントラクト実態が必要な運用処理をすべて同梱している場合には（Ｓ３０３：ＮＯ）、分散台帳ノード３は、デプロイＴＸに従って、デプロイ対象となるシステム運用ＳＣ３７２の運用定義情報を分散台帳３７に登録し（Ｓ３０７）、デプロイ成功を返す（Ｓ３０８）。

一方、外部で管理された運用実行プログラム３６のインストールが必要な場合（Ｓ３０３：ＹＥＳ）、分散台帳ノード３は、システム運用ＳＣ３７２に対応する運用実行プログラム３６を外部リポジトリ等からダウンロードし、これを分散台帳ノード３上の所定のディレクトリ以下にインストールする（Ｓ３０４）。なお、このインストールは、処理フローとは別に予め実行されていてもよい。

次に、分散台帳ノード３は、運用実行プログラム３６が正しいものであるかどうかを確認する（Ｓ３０６）。この確認方法としては、例えば、分散台帳ノード３上にインストー
ルした運用実行プログラム３６のバイナリからハッシュ値を計算し、このハッシュ値と、予め別環境で別途計算してシステム運用ＳＣ３７２上の内部変数として保持したハッシュ値とを比較し、両者が一致するか否かに基づいて判定する。こうした判定に利用するハッシュ値は、別環境ではなく、他の分散台帳ノード３上の同バイナリから計算したハッシュ値を用いても良い。

上述の判定の結果、運用実行プログラム３６が正しいことが判明した場合（Ｓ３０６：ＹＥＳ）、分散台帳ノード３は、後続の正常系の処理（Ｓ３０７〜Ｓ３０８）を行い、もし、正しくないことが判明した場合（Ｓ３０６：ＮＯ）、デプロイ失敗を返す（Ｓ３０９）。

このように運用実行プログラム３６が正しいかどうかを判定することで、外部の運用実行プログラム３６を利用した場合に、プログラムの改竄、バージョンや設定の違い、配置忘れ等の発生により、想定外の運用作業が実行されることを抑止でき、運用作業の均一性をより高めることができる。
図１１は、システム運用ＳＣ３７２のＳＣ関数「運用実行」呼び出し時の内部処理例を示すフローチャートである。

各分散台帳ノード３は、合意形成済みの運用実行ＴＸとして、システム運用ＳＣ３７２のＳＣ関数「運用実行」呼び出しを受け取る（Ｓ４０１）と、ＳＣ実行／管理部３２の機能によって、本ＴＸに従ったシステム運用作業の実行を行う。具体的な内部処理を以下に示す。

分散台帳ノード３は、実行対象となるシステム運用ＳＣ３７２中で、定義された運用手順において別途インストールされた運用実行プログラム３６を含まない場合（Ｓ４０２：ＮＯ）の場合、システム運用ＳＣ３７２内に定義された運用手順に従って運用作業を実行する（Ｓ４０３）。台帳データバックアップ運用作業の場合には、例えば、予め定義された手順に従って、台帳バックアップデータ圧縮コマンド、バックアップデータ退避コマンドを順に実行する。

また、運用作業の実行が完了した後で、ＳＣ実行／管理部３２は、分散台帳３７中のステート情報の運用実行履歴に対して、今回の運用実行を追記／更新する（Ｓ４０８）。例えば、運用実行履歴のレコードとして、運用定義名、実行開始／終了時刻、および実行状態として「実行完了」を追加する。
最後に、分散台帳ノード３は、本システム運用ＳＣ３７２の実行結果（例：成功）を返す（Ｓ４０９）。

一方、実行対象となるシステム運用ＳＣ３７２中で、定義された運用手順において別途インストールされた運用実行プログラム３６を含まない場合（Ｓ４０２：ＮＯ）、分散台帳ノード３は、実行の度に運用実行プログラム３６の正しさの確認処理をしてもよい。

運用実行プログラム３６の正しさが必要な場合（Ｓ４０４：ＹＥＳ）、分散台帳ノード３は、Ｓ３０６と同様の方法で、インストールされた運用実行プログラム３６が正しいかどうか判定する（Ｓ４０５）。

この判定の結果、運用実行プログラム３６が正しい（Ｓ４０６：ＹＥＳ）、もしくは確認不要（Ｓ４０４：ＮＯ）の場合、分散台帳ノード３は、システム運用ＳＣ３７２内に定義された運用手順に従って運用実行プログラム３６を実行することで運用作業を行う（Ｓ４０７）。台帳データバックアップ運用作業の場合には、例えば、別途インストールされたバックアップ用プログラムやスクリプトを呼び出し、その内部で、リクエスト受付停止
、台帳バックアップデータ圧縮、バックアップデータ退避、リクエスト受け付け再開といった一連のバックアップ処理を行う。

運用作業の実行が完了した後で、ＳＣ実行／管理部３２は、分散台帳３７中のステート情報の運用実行履歴に対して、今回の運用実行を追記／更新し（Ｓ４０８）、本システム運用ＳＣ３７２の実行結果（例：成功）を返す（Ｓ４０９）。

なお、上述の判定の結果、運用実行プログラム３６が正しくなかった場合（Ｓ４０６：ＮＯ）、分散台帳ノード３は、運用作業の実行は行わず、本システム運用ＳＣ３７２の実行結果（例：プログラム不正による失敗）を返す（Ｓ４０９）。

なお、上述のような運用管理手順を実行するに際し、分散台帳ノード３がユーザに対して表示する画面例を図１２で示す。図１２は、運用管理アプリ４２の表示画面１２００の例である。

この表示画面１２００の画面上部には、システム運用ＳＣ３７２で定義した運用作業一覧１２０１が配置されている。この運用作業一覧１２０１における表示情報は、分散台帳ノード３がＳＣ関数「運用定義参照」を実行することで取得され、配置される。

この運用作業一覧１２０１の右部には、運用管理ボタン１２０２が示される。ＳＣで定義した運用作業の実行権限のある管理者は、運用管理アプリ４２の運用管理ボタン１２０２中の実行ボタン１２０２１を押下することで、指定したシステム運用ＳＣ３７２の運用実行ＴＸを発行できる。また、実行履歴参照ボタン１２０２２を押下することで、指定したシステム運用ＳＣ３７２の運用実行履歴一覧１２０３を参照できる。

こうした運用実行履歴一覧１２０３は、表示画面１２００の下部に配置されている。この運用実行履歴一覧１２０３における表示情報は、分散台帳ノード３がＳＣ関数「運用実行履歴参照」を実行することで取得できる。

運用管理アプリ４２を介して、特定の運用管理者によってシステム運用作業の要求がされた場合にも、バックエンドでは複数の管理者が管理する分散台帳ノード３間で合意形成がなされ、各分散台帳ノード３上で同一の運用手順に従って同一のタイミングで運用作業が実行される。

以上で示したとおり、本実施形態の運用管理方法を用いることで、分散台帳システムにおいて複数の管理者が存在した場合にも、ポリシーや実行タイミングについて合意を取った上で足並みを揃えて運用作業を実行することが可能となる。すなわち、運用作業を非中央集権かつ正常水準を担保しながら実行できる。

また、複数のベンダで構築した分散処理システムの運用にも対応可能である。さらに、運用手順をＳＣの中に埋め込んで手順書化あるいはスクリプト化しておくことで、複数（主体の所有する）ノード間での操作の均一性が担保できる。

加えて、分散台帳システムの合意形成アルゴリズムを活用する副作用として、実行した運用作業が分散台帳システムの正常基準を満たすことを担保できる（例：ＰＢＦＴではノード３ｆ＋１台中でｆ台が悪意のあるノードだった場合にも正常動作可能）。そのため、運用作業が失敗したり、悪意を持った運用者が存在したりする場合にも、理論上は分散台帳システムの合意アルゴリズムが保証する範囲で正常な運用水準を維持可能となる。

本実施例では、合意形成アルゴリズムとして、ＰＢＦＴを用いた例を示したが、本発明
はそれに限定されず、他のアルゴリズムも利用した場合にも適用可能である。例えば、Ｂｉｔｃｏｉｎの合意形成アルゴリズムであるＰｒｏｏｆ ｏｆ Ｗｏｒｋあるいはその代替アルゴリズムであるＰｒｏｏｆ ｏｆ Ｓｔａｋｅを用いてもよいし、Ｈｙｐｅｒｌｅｄｅｒ Ｆａｂｒｉｃの合意形成アルゴリズムであるＥｎｄｏｒｓｅｒ-Ｏｒｄｅｒｅｒ Ｍｏ
ｄｅｌを用いてもよい。さらに、本実施例の図８では、ＴＸ実行処理について、ＴＸの受け取り、ＴＸの識別/判定、合意形成、ＴＸに基づくＳＣの実行処理、ブロック追加の順
で行う場合を例に示したが、処理の順序はこれに限定されない。例えば、ＴＸの識別/判
定と合意形成の順番が逆であってもよい。

以降では、本発明の実施例の様々なバリエーションを示す。基本的には実施例１をベースとするため、共通部分の説明は省略する。また各実施例は複数組み合わせて適用することも可能である。
−−−実施例２−−−

実施例２では、システム運用ＳＣ３７２に従ったシステム運用作業に関して、これを運用実行の受付フェーズと運用実行の完了フェーズに分割し、さらには運用作業が途中で失敗した際にＳＣに従って自動リカバリも行う場合の例を示す。

本実施例を用いれば、システム運用ＳＣ３７２の中で実行される運用実行の完了を待つことがないため、運用作業に長時間を要する場合にも、次の別の実行ＴＸを早期に実行可能となり、業務ＳＣ３７１や他のシステム運用ＳＣ３７２への影響を低減できる。また、運用作業を行うべき全てのノードにおいて、運用作業が確実に実行されて処理が完了したことを管理できる。さらに、運用失敗時の処理もＳＣとして記述することでリカバリ処理の均一化を図ることもできる。

図１３には、実施例２におけるシステム全体としてのシステム運用ＳＣ３７２に従った運用実行受付、作業実行、実行完了登録、リカバリ処理までの一連の流れを示すフローチャートを示す。

この場合、各分散台帳ノード３は、システム運用ＳＣ３７２がデプロイ（Ｓ１１０１〜１１０２）された後、運用実行ＴＸとして「運用実行受付」の呼び出しを受け取ると、ＳＣ上では運用実行受付処理だけを行った後に、システム運用実行ＴＸの完了を返す（Ｓ１１０３〜Ｓ１１０４）。
次に、各分散台帳ノード３は、前述の運用実行受付処理を契機にして、システム運用ＳＣ３７２に従って運用作業を実行する（Ｓ１１０５）。
この運用作業の実行が完了したら、その完了を契機に、各分散台帳ノード３は、運用実行ＴＸとして「運用実行完了登録」呼び出しを行う（Ｓ１１０６）。

次に、各分散台帳ノード３は、受け取った運用実行ＴＸに従って運用実行完了処理を行う（Ｓ１１０７）。運用実行完了処理では、各分散台帳ノード３における運用実行完了状況を登録／管理し、運用実行完了の所定の条件（例えばすべての対象ノードにおける実行完了）を満たした場合に、システム全体としての運用作業が完了とする。

また、各分散台帳ノード３は、システム運用ＳＣ３７２において、運用実行が失敗した場合に、失敗に対するリカバリ処理を自動実行する。具体的には、あるノードでの運用作業失敗を検知したら、各分散台帳ノード３は、いずれかのノードによって運用実行ＴＸとして「運用失敗リカバリ」を発行し（Ｓ１１０８）、各分散台帳ノードは受け取った運用実行ＴＸに従って運用失敗リカバリ処理を行う（Ｓ１１０９）。失敗は、例えば、システム運用ＳＣ３７２で予め決めた実行タイムアウト時間を超過しても運用実行が完了しなかった場合に失敗とみなすこととする。
図１４は、運用実行受付処理として、システム運用ＳＣ３７２のＳＣ関数「運用実行受付」呼び出し時の内部処理例を示すフローチャートである。

この場合、各分散台帳ノード３は、合意形成済みの運用実行ＴＸとして、システム運用ＳＣ３７２のＳＣ関数「運用実行受付」呼び出しを受け取る（Ｓ５０１）と、ＳＣ実行／管理部３２の機能によって、本ＴＸに従ったシステム運用作業実行の受付処理を行う。具体的な内部処理を以下に示す。

本ＳＣ関数中で運用作業を非同期的に実行開始する場合（Ｓ５０２：ＹＥＳ）、分散台帳ノード３は、実施例１に示したＳＣ関数「運用実行」と同様に運用作業（Ｓ４０２〜Ｓ４０７）の実行を開始する（Ｓ５０３）。ただし、実施例１とは異なり運用実行は非同期処理で実行して、ＳＣ内部では運用作業の完了を待たない。

Ｓ５０３、もしくは、本ＳＣ関数中では運用作業を実行開始しない場合（Ｓ５０２：ＮＯ）の後続処理として、ＳＣ実行／管理部３２は、分散台帳３７中のステート情報の運用実行履歴に対して、今回の運用実行受付を追記／更新する（Ｓ５０４）。例えば、運用実行履歴に、運用定義名、実行開始時刻、および実行状態として「実行中」のレコードを追加する。
最後に、分散台帳ノード３は、本システム運用ＳＣ３７２の実行結果（例：成功）を返す（Ｓ５０５）。

本ＳＣ関数中では運用作業を実行開始しない場合には、例えば、運用実行プログラム３６がエージェントとして機能し、運用実行履歴を自律的かつ定期的に参照し、「実行中」の新規レコードの追加を契機に、本システム運用ＳＣ３７２に従った運用作業の実行を開始する。
図１５は、運用実行完了時の処理として、システム運用ＳＣ３７２のＳＣ関数「運用実行完了登録」呼び出し時の内部処理例を示すフローチャートである。

この場合、各分散台帳ノード３は、合意形成済みの運用実行ＴＸとして、システム運用ＳＣ３７２のＳＣ関数「運用実行完了登録」呼び出しを受け取る（Ｓ６０１）と、ＳＣ実行／管理部３２の機能によって、本ＴＸに従ったシステム運用作業実行に関する各ノードでの実行完了登録処理を行う。具体的な内部処理を以下に示す。

ここで、実行完了を管理するにあたり、各分散台帳ノード３における運用作業の完了を明示的に管理する上で、実行が完了したことを示す実行ログや実行結果 （例：バックアップファイル情報）、画面のスナップショットなど、それらのハッシュ値等をエビデンスとして登録／管理してもよい。

実行完了管理においてエビデンス管理を行う場合（Ｓ６０２：ＹＥＳ）、分散台帳ノード３は、実行完了エビデンスを取得／確認する（Ｓ６０３）。このエビデンスの取得方法としては、ＳＣ関数の入力引数に含めてもよいし、エビデンスをＳＣ関数内部から参照可能な場所に配置しておき、ＳＣ関数内部で取得してもよい。

エビデンス管理を行わない場合（Ｓ６０２：ＮＯ）やＳ６０３の後続処理として、分散台帳ノード３は、運用実行ＴＸを発行した分散台帳ノード３での運用作業の実行が完了したことをステート情報の運用実行履歴に対して追記する（Ｓ６０４）。
例えば、本運用実行を示すレコードの列に各ノードでの実行完了状況として、ノード名と完了時刻のペアを管理しておき、その情報を更新する。

さらに、分散台帳ノード３は、ステート情報を元に他のノードを含めた実行完了状況を
確認して、対象となる全ノードでの実行が完了かどうかを確認し（Ｓ６０５）、実行が完了していた場合（Ｓ６０５：ＹＥＳ）、ステート情報の運用実行履歴に対して本運用実行完了を追記／更新する。具体的には、例えば、本運用実行を示すレコードの実行状態を「実行中」から「実行完了」に変更して、実行完了時刻を登録する。
最後に、分散台帳ノード３は、本ＳＣの実行結果を返す（Ｓ６０７）。
図１６は、システム運用ＳＣ３７２のＳＣ関数「運用失敗リカバリ」呼び出し時の内部処理例を示すフローチャートである。

この場合、各分散台帳ノード３は、合意形成済みの運用実行ＴＸとして、システム運用ＳＣ３７２のＳＣ関数「運用失敗リカバリ」呼び出しを受け取る（Ｓ６５１）と、ＳＣ実行／管理部３２の機能によって、本ＴＸに従って運用失敗時におけるリカバリ処理を行う。具体的な内部処理を以下に示す。

まず、ＳＣ実行／管理部３２は、受け取った運用実行ＴＸに従ってシステム運用ＳＣ３７２内に定義された運用手順に従ってリカバリ作業を実行する（Ｓ６５２）。台帳データバックアップ運用の場合のリカバリ処理の例にあげると、ロールバック処理として、バックアップ失敗の中間データの削除を行い、バックアップ処理を再実行する。

次に、分散台帳ノード３は、ステート情報の運用実行履歴に対して本運用実行を追記・更新する（Ｓ６５３）。具体的には、本運用実行を示すレコードの実行状態を「実行中」から「運用失敗／リカバリ完了」に変更して、実行完了時刻を登録する。
最後に、分散台帳ノード３は、本ＳＣの実行結果を返す（Ｓ６５４）。

本実施例のリカバリ処理は、外部からのＳＣ関数の「運用失敗リカバリ」呼び出しを契機としているが、ＳＣ内部でタイムアウト等の契機を管理しておき、ＳＣ関数内の処理として実行してもよい。

また、実行完了待ち状態のときにＴＸの受け入れ制御をしていないが、実行完了待ちの状態の場合には同一ＴＸの受け入れをブロックしてもよい。そうすることにより、運用実行ＳＣの実行集中による負荷上昇や二重実行を抑止することができる。

本実施例におけるエビデンス情報の管理は必須ではなく、管理をしなくても構わない。また他の実施例１を含めた他の実施例においてエビデンス情報を管理してもよい。
−−−実施例３−−−

実施例３では、システム運用ＳＣ３７２に従ったシステム運用実行において、各実行前に明示的な承認処理プロセスを含む場合の例を示す。この承認は、ＴＸを受け入れるかどうかの合意形成処理（プロトコルレベル）よりも、上位概念（業務運用やシステム運用レベル）での承認処理を表し、例えば、運用作業実行前に各ノード上で前準備が必要な場合などに有効である。

図１７は、実施例３における、システム全体としてのシステム運用ＳＣ３７２に従った運用実行受付、承認、作業実行処理までの一連の流れを示すフローチャートである。

この場合、各分散台帳ノード３は、システム運用ＳＣ３７２がデプロイ（Ｓ１２０１〜１２０２）された後、運用実行ＴＸとして「運用実行受付」の呼び出しを受け取ると、ＳＣ上では運用実行受付処理だけを行った後に、システム運用実行ＴＸの完了を返す（Ｓ１２０３〜Ｓ１２０４）。

次に、各分散台帳ノード３は、前述の運用実行受付処理を契機にして、本システム運用
ＳＣ３７２に従って運用作業を実行してよいかどうかの承認処理を行う（Ｓ１２０５）。この承認処理は自動実行でも人手による判定でもよい。
上述の承認が完了したならば、その完了を契機に、各分散台帳ノード３は、運用実行ＴＸとして「運用実行承認」呼び出しを行う（Ｓ１２０６）。

次に、各分散台帳ノード３は、受け取った運用実行ＴＸに従って、運用実行承認処理を行う（Ｓ１２０７）。運用実行承認処理では、各分散台帳ノード３における運用実行承認完了状況を登録／管理し、運用実行承認完了の所定の条件（例えばすべての対象ノードにおける承認完了）を満たした場合に、実施例１や２と同様にシステム運用ＳＣ３７２に従った運用作業を実行する。

本実施例では、分散台帳ノード３ごとに承認用のＴＸ（ＳＣ関数「運用実行承認」呼び出し）を発行する例を示したが、ノードごとではなく、ビジネスネットワークに参加した組織ごとや管理者ごとに承認用のＴＸをまとめてもよい。

図１８は、本実施例における運用実行受付処理として、システム運用ＳＣ３７２のＳＣ関数「運用実行受付」呼び出し時の内部処理例を示すフローチャートである。

この場合、各分散台帳ノード３は、合意形成済みの運用実行ＴＸとして、システム運用ＳＣ３７２のＳＣ関数「運用実行受付」呼び出しを受け取る（Ｓ７０１）と、ＳＣ実行／管理部３２の機能によって、本ＴＸに従ったシステム運用作業実行の受付処理を行う。具体的な内部処理を以下に示す。

まず、ＳＣ実行／管理部３２は、分散台帳３７中のステート情報の運用実行履歴に対して、今回の運用実行受付を追記／更新する（Ｓ７０２）。例えば、運用実行履歴に、運用定義名、実行開始時刻、および実行状態として「承認中」のレコードを追加する。
最後に、分散台帳ノード３は、本システム運用ＳＣ３７２の実行結果（例：成功）を返す（Ｓ７０３）。
図１９は、運用実行承認時の処理として、システム運用ＳＣ３７２のＳＣ関数「運用実行承認」呼び出し時の内部処理例を示すフローチャートである。

この場合、各分散台帳ノード３は、合意形成済みの運用実行ＴＸとして、システム運用ＳＣ３７２のＳＣ関数「運用実行承認」呼び出しを受け取る（Ｓ７５１）と、ＳＣ実行／管理部３２の機能によって、本ＴＸに従ったシステム運用作業実行に関する各ノードでの実行承認処理を行う。具体的な内部処理を以下に示す。

まず、ＳＣ実行／管理部３２は、運用実行ＴＸを発行した分散台帳ノード３での運用実行の承認が完了したことをステート情報の運用実行履歴に対して追記する（Ｓ７５２）。例えば、本運用実行を示すレコードの列に各ノードでの承認完了状況として、ノード名と承認完了時刻のペアを管理しておき、その情報を更新する。

さらに、分散台帳ノード３は、ステート情報を元に、他のノードを含めた承認管理完了状況を確認して、対象となる全ノードでの承認が完了かどうかを確認する（Ｓ７５３）。この結果、承認が完了していることが判明した場合（Ｓ７５３：ＹＥＳ）、分散台帳ノード３は、ステート情報の運用実行履歴に対して本運用実行の承認完了を追記／更新する（Ｓ７５４）。具体的には、例えば、本運用実行を示すレコードの実行状態を「承認中」から「実行中」に変更する。

分散台帳ノード３は、上述のように承認完了したら、実施例１や２と同様にシステム運用ＳＣ３７２内に定義された運用手順に従って運用作業を実行し（Ｓ７５５）、本ＳＣの
実行結果を返す（Ｓ７５６）。

なお、システム運用作業には、オンデマンドではなく、予め決めたスケジュールや起動条件に従って実行するような運用作業も存在する。スケジュール／実行条件は、例えば、特定の日時や特定のシステム状態（データ量の上限到達）などがあげられる。運用作業を定期実行するパターンとして、実施例４では、外部に用意した運用管理ノード５が定期実行を管理する例を、実施例５では、各分散台帳ノード３の内部、具体的には、運用実行プログラムが定期実行を管理する例をそれぞれ示す。
−−−実施例４−−−

図２０は、実施例４における運用管理システム１０を模式的に示す図である。実施例１までの運用管理システムとは異なり、運用管理ノード５が追加され、また、クライアントノード４上に運用管理アプリ４２は不要となっている（それ以外については同様である）。

運用管理ノード５は、運用管理を実施するためのノードであり、本実施例では分散台帳ノード３と同様の立場で、ネットワークに参加し、システム運用ＳＣ３７２の合意形成処理に参加することを想定する。そのため、運用管理ノード５は、分散台帳ノード３と同様の機能を備える。

なお、運用管理ノード５は、システム運用ＳＣ３７２の処理にのみ参加して、業務ＳＣの処理には参加しないこととする。そのため、運用管理ノード５上の分散台帳３７では、システム運用ＳＣ３７２に関する情報のみ保持／管理するものとする。また、運用管理ノード５は運用管理アプリ４２を備える。この機能は実施例１と同様である。

このように運用管理用のノードがネットワークに参画するシステム構成は、業務に参加しない複数ベンダが、システム運用作業のみに参加する場合に有効である。業務に参加していないベンダも、業務を行う組織とともに合意形成を行いながら、運用作業を実施するため、マルチベンダでの運用を非中央集権的に実施することができる。

図２１は、実施例４における運用作業の定期実行処理の例を示すフローチャートである。ここでの前提として、各ノードには、定期実行を行うシステム運用ＳＣ３７２がデプロイされていることとする（Ｓ１３０１〜１３０２）。

続いて、システム運用ＳＣ３７２において定期実行のために取り決めた時間が経過したら（Ｓ１３０３）、運用管理ノード５は、システム運用ＳＣ３７２の運用実行ＴＸとしてＳＣ関数「運用実行」を発行する（Ｓ１３０４）。ここで、定期実行の頻度の情報は、例えば、デプロイ時の入力引数などで指定されて、ＳＣ内のステート情報として保持されることとする。
運用管理ノード５によって発行された運用実行ＴＸについては、合意形成に参加する分散台帳ノード３および運用管理ノード５間で合意形成処理が実行される。
この合意形成処理の後、各分散台帳ノード３は、受け取った運用実行ＴＸに従って運用作業を実行する（Ｓ１３０５）。
以降は、運用管理ノード５が定時実行の契機を待って、運用作業を繰り返し実行する（Ｓ１３０３〜１３０５）。

ここで、本実施例では運用管理ノード５が分散台帳ノード３と同等の立場で合意形成処理にも参画していたが、単にネットワーク参加者として運用実行ＴＸを発行するだけで、合意形成を行わなくてもよい。その場合には、運用管理ノード５上に、分散台帳ノード３と同様の機能３１〜３４等は不要である。
−−−実施例５−−−

実施例５では、定期運用実行を各分散台帳ノード３の内部、具体的には運用実行プログラム３６が管理する例を示す。本実施例における運用管理システム１０は実施例１と同様である。

図２２は、実施例５における運用作業の定期実行処理の例を示すフローチャートである。ここでの前提として、各分散台帳ノード３において、定期実行を行うシステム運用ＳＣ３７２がデプロイされていることとする（Ｓ１４０１〜１４０２）。従って、各分散台帳ノード３上の運用実行プログラム３６が、定期実行を管理する。

例えば、定期実行のスケジュールは、ＳＣ内のステート情報から取得してもよいし、ＳＣ外の情報、例えば、運用実行プログラム３６の設定情報に記述したものをつかってもよい。

この場合、運用実行プログラム３６は、システム運用ＳＣ３７２で取り決めた時間が経過したら（Ｓ１４０３：ＹＥＳ）、ネットワーク参加者として、システム運用ＳＣ３７２の運用実行ＴＸのＳＣ関数「運用実行」を発行する（Ｓ１４０４）。
また、各分散台帳ノード３は、受け取った運用実行ＴＸに従って運用作業を実行する（Ｓ１４０５）。

ここで本実施例では、運用実行プログラム３６がＳＣ関数「運用実行」を発行した後で運用作業を実行しているが、運用作業を実行した後でその結果をＳＣ関数「運用実行完了」経由で登録する形でもよい。
−−−実施例６−−−

実施例３では、実行時に承認処理を行う例を示したが、加えてシステム運用ＳＣ３７２を新規登録する際にも、承認処理を行いたい場合がある。そこで実施例６では、システム運用ＳＣ３７２の管理を行うメタコントラクトを用意し、システム運用ＳＣ３７２の新規登録における承認処理を行う例について示す。

メタコントラクトは、システム運用ＳＣ３７２とは別の独立したＳＣであり、ＳＣ関数として「運用定義登録受付」と「運用定義登録承認」が定義されていることとする。なお、基本的なＳＣデプロイ／実行処理や分散台帳上での管理方法は、業務ＳＣ３７１やシステム運用ＳＣ３７２と同様であるため、説明は省略する。
図２３は、システム運用ＳＣ３７２の管理を行うメタコントラクトにおけるシステム運用ＳＣ３７２の新規登録の受付処理を示す例である。
この場合、各分散台帳ノード３は、合意形成済みの実行ＴＸとして、メタコントラクトのＳＣ関数「運用定義登録受付」呼び出しを受け取る（Ｓ８０１）。

次に、各分散台帳ノード３は、ＳＣ実行／管理部３２の機能によって、本ＴＸに従ったシステム運用ＳＣ３７２の新規受付処理を行う。具体的な内部処理を以下に示す。

ＳＣ実行／管理部３２は、分散台帳３７中のステート情報の運用定義情報として、今回の新規受付を追記／更新する（Ｓ８０２）。例えば、運用定義情報およびその管理状態「承認処理中」をレコードとして追加する。
最後に、各分散台帳ノード３は、本ＳＣの実行結果を返す（Ｓ８０３）。
図２４は、上述のメタコントラクトにおけるシステム運用ＳＣ３７２の新規登録の承認処理例を示す図である。
この場合、各分散台帳ノード３は、合意形成済みの実行ＴＸとして、メタコントラクト
のＳＣ関数「運用定義登録承認」呼び出しを受け取る（Ｓ８５１）。

次に、各分散台帳ノード３は、ＳＣ実行／管理部３２の機能によって、本ＴＸに従ったメタコントラクトに関する各ノードでの実行承認処理を行う。具体的な内部処理を以下に示す。

ここでＳＣ実行／管理部３２は、実行ＴＸを発行した分散台帳ノード３で、システム運用ＳＣ３７２の新規登録に関する承認が完了したことをステート情報の運用適宜情報に対して追記する（Ｓ８５２）。例えば、新規登録対象となる運用定義を示すレコードの列に各ノードでの承認完了状況として、ノード名と承認完了時刻のペアを管理しておき、その情報を更新する。

さらに、ＳＣ実行／管理部３２は、ステート情報を元に他のノードを含めた承認管理完了状況を確認し、対象となる全ノードでの承認が完了か否か確認する（Ｓ８５３）。

その結果、承認が完了していた場合（Ｓ８５３：ＹＥＳ）、ＳＣ実行／管理部３２は、ステート情報の運用定義情報に対して承認完了を追記／更新する（Ｓ８５４）。具体的には、例えば、新規登録対象となる運用定義を示すレコードの状態を「承認済」に変更する。 上述のように承認完了となれば、ＳＣ実行／管理部３２は、メタコントラクト内にて、新規追加対象としたシステム運用ＳＣ３７２についてデプロイＴＸを発行する（Ｓ８５５）。この処理は他の実施例と同様である。
最後に、各分散台帳ノード３は、本ＳＣの実行結果を返す（Ｓ８５６）。
このようにして、メタコントラクトを用意することで、システム運用作業の新規追加や更新プロセスでも承認処理を行うことができる。

ここまで説明した各実施例では、システム運用作業を管理するビジネスネットワークは、業務ＳＣ３７１と同一ビジネスネットワーク上で管理する例を示したが、システム運用専用の別のビジネスネットワークを構築してもよい。

また各実施例では、システム運用ＳＣ３７２に定義された運用作業に関する各ノードにおける実行は、システム運用ＳＣ３７２内での実行を行う例（例えば、Ｓ４０３）、もしくは、運用実行プログラム３６が運用実行履歴を自律的かつ定期的に参照し「実行中」の新規レコードの追加を契機に実行を開始する例（例えば、図１４の説明）を示した。しかし、その方法に限定されるものではない。

別の方法としては、イベント駆動で行う方法が挙げられる。具体的には、分散台帳システム内で、分散台帳ノード３の間もしくはビジネスネットワーク参加者間で発行／通知を可能とするイベントを管理する機能を有している場合に、システム運用ＳＣ３７２の内部で運用作業の実行を促すイベントを発行し、各分散台帳ノード３における運用実行プログラム３６がイベントの通知を契機に運用作業を実行してもよい。その際には、運用作業内容を伝えるために、イベントの中に具体的な運用内容（例えば運用コマンド）や対象ノードを埋め込んでおき、運用実行プログラム３６はその情報に従って運用作業を実行してもよい。なお、イベント自体はＳＣ実行中ではなく、ＳＣ実行完了直後に発行されても構わない。また、イベント駆動で行う場合には、運用実行プログラム３６が、実行完了後にその結果をＳＣ関数「運用実行完了」を用いて登録してもよい。

本実施形態の運用管理方法は、主にシステム運用を想定したものであるが、方式そのものはシステム運用に限定されないため、業務運用（例えば，アプリ更新）を対象として適用してもよい。また、こうした運用管理方法は、分散台帳システムのシステム運用管理を主対象として説明したが、分散台帳システムだけに適用対象を限定するものではない。

例えば、分散処理システム全般で、複数の運用者によって、同一役割の複数ノード（分散処理ノード）に対して一括して運用作業を行いたい場合にも有効である。
図２５に、実施例７における運用管理システム１０とその管理対象たる分散処理システム５０のネットワーク構成例を示す。

この場合、本実施形態における分散台帳ノード３それぞれが、分散処理システム５０の運用管理用のスマートコントラクト５００を分散台帳３７で管理しているものとする。よって、分散台帳ノード３は当該スマートコントラクト５００を上述の実施例と同様に実行することで、分散処理ノード５５それぞれに対する運用作業を実行する。換言すれば、運用管理対象を、分散台帳システム６における各分散台帳ノード３の分散台帳３７ではなく、各分散台帳ノード３に接続された各分散処理ノード５５とした構成である。

以上、本発明の実施例について図面を参照して詳述してきたが、具体的な構成はこの実施例に限られるものではなく、この発明の要旨を逸脱しない範囲の設計なども含まれる。

こうした本実施形態によれば、分散台帳システムにおいて複数の管理者が存在した場合にも、ポリシーや実行タイミングについて合意を取った上で、足並みを揃えた運用作業を実行可能となる。すなわち、分散台帳システムにおける運用管理を非中央集権かつ正常水準を担保しながら実行できる。

また、複数のベンダで構築した分散処理システム（例：複数の分散処理ノードで負荷分担した分析システム）の運用管理にも対応可能である。この場合、運用管理対象が分散台帳ではなく、分散台帳システムの各ノードと接続された分散処理ノード、となる。さらに、運用手順をＳＣの中に埋め込んで手順書化あるいはスクリプト化しておくことで、複数（主体の所有する）ノード間での操作の均一性が担保できる。
すなわち、分散台帳システムにおいて管理者が複数存在する状況下でも、ノード間でポリシーやタイミングを揃えた運用管理が可能となる。

本明細書の記載により、少なくとも次のことが明らかにされる。すなわち、本実施形態の運用管理方法において、前記分散台帳システムにおける前記トランザクションを受け取ったノードが、運用作業の受付フェーズと実行完了の確認フェーズとを含む前記運用スマートコントラクトを実行するとしてもよい。

これによれば、運用スマートコントラクトの中で実行される運用実行の完了を待つことがないため、運用作業が長時間かかる場合にも、次の別の実行トランザクションを早期に実行可能となり、業務ＳＣや他のシステム運用ＳＣへの影響を低減できる。また、運用作業を行うべき、すべてのノードにおいて運用実行が確実に実行されて処理が完了したことを管理することができる。

また、本実施形態の運用管理方法において、前記分散台帳システムにおける前記トランザクションを受け取ったノードが、前記運用スマートコントラクトを実行して、前記実行完了の確認フェーズにおける前記トランザクションに完了エビデンスもしくは完了エビデンスと紐づく情報を含む構成とするとしてもよい。
これによれば、各ノードにおける運用作業の完了を明示的に管理することが可能となる。

また、本実施形態の運用管理方法において、前記分散台帳システムにおける前記トランザクションを受け取ったノードが、前記運用スマートコントラクトの実行の結果、前記実行完了の確認フェーズにおいて実行完了の失敗に至った場合、前記運用スマートコントラ
クトに従って所定のリカバリまたは再実行処理を行うとしてもよい。
これによれば、運用作業が途中で失敗した際にＳＣに従ってリカバリ等が自動実行され、リカバリ等の処理の均一化を図ることができる。

また、本実施形態の運用管理方法において、前記分散台帳システムにおける前記トランザクションを受け取ったノードが、スマートコントラクトの登録および実行の少なくともいずれかにおいて承認フェーズを含む前記運用スマートコントラクトを実行するとしてもよい。

これによれば、ＴＸを受け入れるかどうかの合意形成処理（プロトコルレベル）よりも、上位概念（業務運用やシステム運用レベル）での承認処理が可能となり、例えば、運用作業実行前に各ノード上で前準備が必要な場合などに有効となる。

また、本実施形態の運用管理方法において、前記所定の複数ノードのうち、業務用の業務スマートコントラクトの実行を担当しないノードが、前記分散台帳システムによって構成されるビジネスネットワークの参加者もしくは、前記運用スマートコントラクトの合意形成に参加するノードとして、ネットワークに参加し、前記運用スマートコントラクトを実行するとしてもよい。

これによれば、運用管理用ノードがビジネスネットワークに参画することで、業務に参加しない複数ベンダがシステム運用作業のみに参加する場合に有効である。業務に参加していないベンダも、業務を行う組織とともに合意形成を行いながら、運用作業を実施するため、マルチベンダでの運用を非中央集権的に実施することができる。

また、本実施形態の運用管理方法において、前記分散台帳システムにおける前記トランザクションを受け取ったノードが、前記運用スマートコントラクトに関して、当該運用スマートコントラクトの追加／更新を行うデプロイトランザクションと、前記運用スマートコントラクトで定義された運用作業を実行する運用実行トランザクションとを発行し、前記デプロイトランザクションおよび前記運用実行トランザクションの少なくともいずれかの発行時において、運用作業に利用する運用実行プログラムの正しさを検証する、としてもよい。

これによれば、運用作業プログラムの正しさ検証することで、外部の運用作業プログラムを利用した場合に、当該プログラムの改竄、バージョンや設定の違い、配置忘れ等の発生により、想定外の運用作業が実行されることを抑止でき、運用作業の均一性をより高めることができる。

また、本実施形態の運用管理方法において、前記分散台帳システムにおける前記トランザクションを受け取ったノードの保持する、あるいは当該ノードにアクセス可能な運用実行プログラムが、予め定められた前記運用スマートコントラクトに従い、運用作業を実行するとしてもよい。

これによれば、運用管理用のノードがネットワークに参画するシステム構成となり、業務に参加しない複数ベンダが、システム運用作業のみに参加する場合に有効である。業務に参加していないベンダも、業務を行う組織とともに合意形成を行いながら、運用作業を実施するため、マルチベンダでの運用を非中央集権的に実施することができる。

また、本実施形態の運用管理方法において、前記所定の複数ノードのうち前記運用スマートコントラクトを実行したノードは、前記運用スマートコントラクトの実行時において当該運用スマートコントラクトが実行されたことを示す運用作業に関するイベントを発行
し、前記イベントを受け取った前記所定の複数ノードの保持する、あるいは当該ノードにアクセス可能な運用実行プログラムが、前記イベントを契機に、予め定められた前記運用スマートコントラクトに従った運用作業を実行するとしてもよい。

これによれば、所定のノードにおける運用スマートコントラクトの実行を契機に、他ノードにおける運用スマートコントラクトも行われ、分散台帳システムを構成する各ノードで運用作業が的確に同期されることにつながる。

また、本実施形態の運用管理方法において、前記イベントには、実行されるべき具体的な運用作業手順が埋め込まれており、前記運用実行プログラムが、埋め込まれた運用作業手順に従って運用作業を実行するとしてもよい。
これによれば、運用管理用のスマートコントラクトが実行されることで、具体的な運用作業手順が自ずと実行されることとなる。

また、本実施形態の運用管理方法において、前記分散台帳システムにおける前記複数のノードは、前記分散台帳システムとは別の分散処理システムの運用管理用のスマートコントラクトを分散台帳で管理し、前記ノードが当該スマートコントラクトを実行して前記分散処理システムにおける分散処理ノードの運用管理を行うとしてもよい。

これによれば、分散処理システムにも本実施形態の運用管理を適用することが可能となり、広範な業種、業務に関して分散処理ノード間でポリシーやタイミングを揃えた運用管理が可能となる。

１ ネットワーク
２ 物理的な通信回線
３ 分散台帳ノード
１０ 運用管理システム
１００ Ｉ／Ｆ
１０１ プロセッサ
１０２ メモリ
１０３ データバス
１１０ プログラム
３１ コンセンサス管理部
３１１ ネットワークプロトコル部
３２ スマートコントラクト実行／管理部（ＳＣ実行／管理部）
３３ メンバー管理部
３４ トランザクション管理部
３５ トランザクション発行部
３６ 運用実行プログラム
３７ 分散台帳
３７１ 業務スマートコントラクト（業務ＳＣ）
３７２ 運用スマートコントラクト（システム運用ＳＣ）
３８ 参加メンバー管理情報
４ クライアントノード
４１ 業務アプリ
４２ 運用管理アプリ
５ 運用管理ノード
６ 分散台帳システム
５０ 分散処理システム
５５ 分散処理ノード

Claims (13)

1. 複数のノードで構成される分散台帳システムにおいて、前記複数のノードのうち少なくとも所定の複数ノードは、それぞれ、
   分散台帳にて当該分散台帳システムの運用管理用の運用スマートコントラクトを管理し、
   前記所定の複数ノードのうち少なくとも１つのノードがトランザクションを受け取った場合、前記トランザクションを受け取ったノードは、前記トランザクションの種別が前記運用スマートコントラクトか否かを判定し、
   当該判定結果に基づき、前記運用スマートコントラクトを実行することを特徴とする運用管理方法。
2. 前記分散台帳システムにおける前記トランザクションを受け取ったノードが、運用作業の受付フェーズと実行完了の確認フェーズとを含む前記運用スマートコントラクトを実行することを特徴とする請求項１に記載の運用管理方法。
3. 前記分散台帳システムにおける前記トランザクションを受け取ったノードが、前記運用スマートコントラクトを実行して、前記実行完了の確認フェーズにおける前記トランザクションに完了エビデンスもしくは完了エビデンスと紐づく情報を含む構成とすることを特徴とする請求項２に記載の運用管理方法。
4. 前記分散台帳システムにおける前記トランザクションを受け取ったノードが、前記運用スマートコントラクトの実行の結果、前記実行完了の確認フェーズにおいて実行完了の失敗に至った場合、前記運用スマートコントラクトに従って所定のリカバリまたは再実行処理を行うことを特徴とする請求項３に記載の運用管理方法。
5. 前記分散台帳システムにおける前記トランザクションを受け取ったノードが、スマートコントラクトの登録および実行の少なくともいずれかにおいて承認フェーズを含む前記運用スマートコントラクトを実行することを特徴とする請求項１に記載の運用管理方法。
6. 前記所定の複数ノードのうち、業務用の業務スマートコントラクトの実行を担当しないノードが、前記分散台帳システムによって構成されるビジネスネットワークの参加者もしくは、前記運用スマートコントラクトの合意形成に参加するノードとして、ネットワークに参加し、前記運用スマートコントラクトを実行することを特徴とする請求項１に記載の運用管理方法。
7. 前記分散台帳システムにおける前記トランザクションを受け取ったノードが、
   前記運用スマートコントラクトに関して、当該運用スマートコントラクトの追加／更新を行うデプロイトランザクションと、前記運用スマートコントラクトで定義された運用作業を実行する運用実行トランザクションとを発行し、
   前記デプロイトランザクションおよび前記運用実行トランザクションの少なくともいずれかの発行時において、運用作業に利用する運用実行プログラムの正しさを検証する、
   ことを特徴とする請求項１に記載の運用管理方法。
8. 前記分散台帳システムにおける前記トランザクションを受け取ったノードの保持する、あるいは当該ノードにアクセス可能な運用実行プログラムが、予め定められた前記運用スマートコントラクトに従い、運用作業を実行することを特徴とする請求項１に記載の運用管理方法。
9. 前記所定の複数ノードのうち前記運用スマートコントラクトを実行したノードは、前記
   運用スマートコントラクトの実行時において当該運用スマートコントラクトが実行されたことを示す運用作業に関するイベントを発行し、
   前記イベントを受け取った前記所定の複数ノードの保持する、あるいは当該ノードにアクセス可能な運用実行プログラムが、前記イベントを契機に、予め定められた前記運用スマートコントラクトに従った運用作業を実行することを特徴とする請求項１に記載の運用管理方法。
10. 前記イベントには、実行されるべき具体的な運用作業手順が埋め込まれており、前記運用実行プログラムが、埋め込まれた運用作業手順に従って運用作業を実行することを特徴とする請求項９に記載の運用管理方法。
11. 前記分散台帳システムにおける前記複数のノードは、
    前記分散台帳システムとは別の分散処理システムの運用管理用のスマートコントラクトを分散台帳で管理し、前記ノードが当該スマートコントラクトを実行して前記分散処理システムにおける分散処理ノードの運用管理を行うことを特徴とする請求項１に記載の運用管理方法。
12. 分散台帳システムの複数のノードで構成されるシステムであって、前記複数のノードのうち少なくとも所定の複数ノードは、それぞれ、分散台帳にて当該分散台帳システムの運用管理用の運用スマートコントラクトを管理し、前記所定の複数ノードのうち少なくとも１つのノードがトランザクションを受け取った場合、前記トランザクションを受け取ったノードは、前記トランザクションの種別が前記運用スマートコントラクトか否かを判定し、当該判定結果に基づき、前記運用スマートコントラクトを実行するものであることを特徴とする運用管理システム。
13. 分散台帳システムを構成する複数のノードのうち少なくとも所定の複数ノードであって、分散台帳にて当該分散台帳システムの運用管理用の運用スマートコントラクトを管理するノード各々に、前記所定の複数ノードのうち少なくとも１つのノードがトランザクションを受け取った場合、前記トランザクションを受け取ったノードにおいて、前記トランザクションの種別が前記運用スマートコントラクトか否かを判定し、当該判定結果に基づき、前記運用スマートコントラクトを実行させることを特徴とする運用管理プログラム。