WO2020170656A1 - 構成変更管理方法、構成変更管理システム、およびノード - Google Patents

Abstract

ブロックチェーンシステムたる構成変更管理システム１において、当該ブロックチェーンシステムを構成するノード１００が、当該ブロックチェーンシステムに対する構成変更リクエストに関して、当該ノードの所属組織の構成情報に基づいた影響確認項目の抽出処理を行い、当該影響確認項目について他ノードとの間で互いに共有および再帰処理を行い、前記ブロックチェーンシステム全体として確認すべき影響確認項目を抽出する演算装置１０１を含む構成とする。

Description

構成変更管理方法、構成変更管理システム、およびノード

　本発明は、構成変更管理方法、構成変更管理システム、およびノードに関する。

　従来、金融機関や政府等の中央集権機関を経由して実施されてきた関係者間の取引を、関係者間のＰ２Ｐ（Ｐｅｅｒ　ｔｏ　Ｐｅｅｒ）による直接的な取引に代替する技術として、分散台帳技術（いわゆる、ブロックチェーン（ＢＣ：Ｂｌｏｃｋｃｈａｉｎ）が活用されている。当該技術の一例としては、仮想通貨の一種であるＢｉｔｃｏｉｎに関するものが提案されている（非特許文献１参照）。

　こうした分散台帳技術は、信頼できるデータの管理及び共有並びに、契約に基づく取引の執行及び管理を非中央集権的に行う仕組みとして、金融分野やＩｏＴ（Ｉｎｔｅｒｎｅｔ　ｏｆ　Ｔｈｉｎｇ）等、幅広い分野での応用が検討されている。

　例えば、非特許文献１に記載の技術を用いた仮想通貨では、Ｐ２Ｐネットワーク上において、取引データ（以下、トランザクションあるいはＴＸとも称する）を、マイナーと呼ばれるノードが正当性を判定した後、プルーフオブワークと呼ばれる特定のハッシュ値を算出する作業で確定処理を行っている。ここで確定処理されたトランザクションは、１つのブロックにまとめられ、ブロックチェーンの形式で分散台帳に記録される。

　分散台帳技術は、その構成に応じて、いくつかの種類に分類することが可能である。その分類としては、不特定多数のノード間で分散台帳ネットワークが構成される「パブリック型（Ｐｕｂｌｉｃ）分散台帳」、複数の特定組織でコンソーシアムを形成し、それぞれの組織が所有するノード間で分散台帳ネットワークが構成される「コンソーシアム型（Ｃｏｎｓｏｒｔｉｕｍ）分散台帳」、１つの特定組織内でのノード間で分散台帳ネットワークが構成される「プライベート型（Ｐｒｉｖａｔｅ）分散台帳」が挙げられる。

　特に、エンタープライズ用途等として提案されているコンソーシアム型分散台帳により、組織間にまたがるビジネスプロセスを効率化することが期待されている。

　近年では、上記の非特許文献１に記載の技術を用いた仮想通貨で実装されたＢＣをベースにして、ＢＣおよび分散台帳に関して様々な派生技術が提案され、進化を続けている。

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

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

　ＢＣを導入したシステム（以下、ＢＣシステムと称する）では、複数の参加組織がリソースを持ち寄り、そのリソースは各自が管理しつつ、全体として１つのシステムを構成する。そのため、システム全体を把握している参加組織は存在しないという特徴がある。

　このような構成上の特徴を持つＢＣシステムに対して、ＢＣネットワークへの参加組織の追加や離脱、ＢＣ上で動作するスマートコントラクトの新規追加や更新などの目的で、ＢＣシステムの構成変更が発生する。

　ここでは、ＢＣシステムの構成変更をＢＣシステムに関わる設定項目を変更することと定義する。ＢＣシステムの構成変更は、具体的にはＢＣシステムの管理に関する設定情報を変更目的に合わせて更新し、その設定をシステムに適用することで実現される。

　上記のようなＢＣシステムの構成変更が正しく行われない場合、構成変更後にシステムエラーやシステム停止のような障害／異常が発生する可能性が考えられる。これを防ぐためには、一般的には構成変更の要求に対し、事前に変更内容や他の設定項目への影響を確認する手法を用いることが考えられる。

　そこで構成変更時の影響範囲を確認する従来技術として、例えば、ネットワークの構成変更による影響の評価をコンピュータに実行させるネットワーク構成変更評価プログラムであって、前記構成変更前のネットワークのトポロジを表すトポロジ情報と前記ネットワーク内の機器の設定変更の情報である機器設定変更情報とを取得する構成変更情報取得ステップと、前記構成変更情報取得ステップにより取得されたトポロジ情報と機器設定変更情報とに基づいて、前記構成変更の影響を受けるサービスの情報を抽出する影響範囲抽出ステップとをコンピュータに実行させるネットワーク構成変更評価プログラム（特許文献１参照）などが提案されている。

特開２００７－２４３８５５号公報

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

　上述の従来技術においては、構成変更の影響を事前評価するが、単一の管理組織がネットワークトポロジ情報を管理・閲覧できるという前提をおいている。ところがＢＣシステムにおいては、設定情報やその管理構造が階層化・グループ構造化されている。

　その構成単位を管理範囲と定義すると、それぞれの管理範囲で管理権限を持つ組織が異なるため、前述したとおり誰も管理の全体像を認識していない。さらに、ＢＣシステムの構成変更においては、設定変更箇所が複数の管理範囲に跨がる場合が多く、構成変更の際に複数管理範囲間の組織の管理者が連携を取る必要がある。

　上記を踏まえると、上述の従来技術を用いた影響範囲の確認は、１組織の権限内でしか行うことができず、複数組織によって管理されるＢＣシステムには適用できない。また、これを複数の組織で分担し確認する場合においても、それぞれが確認するべき箇所を全て認識し適切に割り振りを行う組織が存在しないため、各組織が確認すべき箇所が不明確となる。そのため、確認の抜け漏れや過剰な重複が発生し得るという問題が発生する。
　そこで本発明の目的は、ＢＣシステムの構成変更に際し、各組織の権限内で、システム全体として効率的な確認を精度良好に行う技術を提供することにある。

　上記課題を解決する本発明の構成変更管理方法は、ブロックチェーンシステムを構成する各ノードが、当該ブロックチェーンシステムに対する構成変更リクエストに関して、当該ノードの所属組織の構成情報に基づいた影響確認項目の抽出処理を行い、当該影響確認項目についてノード間で互いに共有および再帰処理を行い、前記ブロックチェーンシステム全体として確認すべき影響確認項目を抽出することを特徴とする。

　また、本発明の構成変更管理システムは、複数のノードから構成されるブロックチェーンシステムであって、前記複数ノードのそれぞれが、当該ブロックチェーンシステムに対する構成変更リクエストに関して、当該ノードの所属組織の構成情報に基づいた影響確認項目の抽出処理を行い、当該影響確認項目についてノード間で互いに共有および再帰処理を行い、前記ブロックチェーンシステム全体として確認すべき影響確認項目を抽出するものであることを特徴とする。

　また、本発明のノードは、ブロックチェーンシステムを構成するノードであって、当該ブロックチェーンシステムに対する構成変更リクエストに関して、当該ノードの所属組織の構成情報に基づいた影響確認項目の抽出処理を行い、当該影響確認項目について他ノードとの間で互いに共有および再帰処理を行い、前記ブロックチェーンシステム全体として確認すべき影響確認項目を抽出するものであることを特徴とする。

　本発明によれば、ＢＣシステムの構成変更に際し、各組織の権限内で、システム全体として効率的な確認を精度良好に行うことが可能となる。

実施例１におけるＢＣシステムでの処理概要を説明する図である。 実施例１における各ノードが備える機能の一例を示す図である。 実施例１におけるＢＣシステムの管理構造の一例を示す図である。 実施例１における管理範囲における設定項目を表すテーブルである。 実施例１における構成変更リクエストを表すテーブルである。 実施例１における影響判定ルールを表すテーブルである。 実施例１における影響確認項目を表すテーブルである。 実施例１における構成確認リクエストを表すテーブルである。 実施例１における確認項目リストを表すテーブルである。 実施例１におけるシステム全体で構成変更を行う際のフローである。 実施例１における確認画面を表す図である。 実施例１における個々のノードで確認項目抽出処理を行う際のフローである。 実施例２における影響判定ルールを表すテーブルである。 実施例２における確認項目リストを表すテーブルである。 実施例２における確認項目抽出処理を行う際のフローである。

 [実施例１]
－－－システムの概要－－－

　図１は、実施例１における構成変更管理システムたるブロックチェーンシステム１（以後、ＢＣシステム）での処理概念を説明する図である。本実施例では、説明の簡便化のため、企業等の組織がＢＣシステム１にてノードを１つ運用し、組織とノードとを１対１対応させている構成を例示している。ただし実際はその限りではなく、１つの組織が複数ノードを運用する構成も想定可能である。

　ＢＣシステム１を構成するノードのひとつであるノード１００は、例えば、所定組織が運用する他ノードから、構成変更リクエストＴ１０を入力として受け取った場合、確認項目抽出部１１０において、ＢＣ構成情報Ｔ１５０の中から、自ノードが管理権限を持つ管理範囲の設定項目を取得し、構成変更リクエストＴ１０によって影響され得る影響確認項目Ｔ３０を出力する。影響確認項目Ｔ３０は、ノード１００の確認項目リストＴ１６０に追加される。

　またノード１００は、出力されたそれぞれの影響確認項目Ｔ３０について、その設定項目を保有する管理範囲（例：コンソーシアム全体、業務グループ、スマートコントラクト等の各階層、各グループなど。図１の場合には“範囲Ｂ”）に対して管理権限のある管理者ノード（本実施例ではノード２００）に対し、該当する影響確認項目を構成確認リクエストＴ２０として送信・共有する。

　ノード２００は、ノード１００から送信された構成確認リクエストＴ２０を受信する。ノード２００は、ノード１００と同様に、自ノードの保有するＢＣ構成情報Ｔ１５１の中から自ノードが管理権限を持つ管理範囲の設定項目を取得し、構成確認リクエストＴ２０によって影響され得る設定項目を影響確認項目として出力する。またノード２００は、出力した影響確認項目を自身の確認項目リストＴ１６１に追加する。

　その後、ノード２００は、上述のように出力した各影響確認項目を保有する管理範囲（図１の場合には“範囲Ｃ”）に対して管理権限のある他ノード（ここではノード３００とノード４００）に対し、該当する影響確認項目を構成確認リクエストＴ２０として共有する。

　このように、構成変更リクエストＴ１０を起点に、再帰的に構成確認リクエストＴ２０を共有・伝搬することで、ＢＣシステム１における各管理範囲を跨いで、確認すべき項目すなわち影響確認項目が抽出される。またその結果は、ノードごとの確認項目リストに追加される。この一連の処理をもって、ＢＣシステム全体として確認すべき影響確認項目が網羅されるのである。

　なお、ＢＣシステム１はまた、ノードごとの確認項目リストを表示する入出力装置１４０、２４０と通信可能に接続されている。入出力装置１４０、２４０は、確認項目リストを表示させるディスプレイ等の出力機器と、各ノードの管理者が当該確認項目リストの内容に関する承認動作等を行うためのキーボード等の入力機器とから構成される。

　なお、各ノードにおける確認項目リストに関する管理者の承認結果は、承認結果共有部１３０を通して、同じ影響範囲内すなわち業務等が同じグループのノード間で共有され、それが予め定めた条件を満たした場合、ＢＣシステム１に対する構成変更が反映される。

　ここでは、構成変更リクエストＴ１０と構成確認リクエストＴ２０を役割上別のデータとして定義しているが、実際のデータ構造は同じである。よって同じテーブルとして定義してもよい。
－－－ノード構成－－－

　図２は実施例１における各ノードが備える機能の一例を示す図である。以後、特段の断りを入れない限り、各ノードを代表してノード１００について説明するものとする。

　ノード１００は、ＣＰＵなどの演算装置１０１、ハードディスクドライブ等の記憶装置１０２、および、ネットワークインターフェイスカード等の通信装置１０３で構成される。

　このうち演算装置１０１は、リクエスト受信部１２０、リクエスト送信部１２１、確認項目抽出部１１０、影響確認項目管理部１９０、承認結果共有部１３０、および構成変更実行部１８０を実装する。これら各部の機能は、演算装置１０１が所定のプログラムを実行することで実装される。

　また記憶装置１０２は、構成情報Ｔ１５０、確認項目リストＴ１６０、および影響判定ルールＴ１７０、を保持する。このうち構成情報Ｔ１５０は、ＢＣ構成情報のうち自身が管理権限をもっている管理範囲の設定項目リストＴ１５０Ｘの集合である。

　また、確認項目リストＴ１６０は、ノードごとに出力される影響確認項目の集合である。また、影響判定ルールＴ１７０は、構成情報の設定項目間の影響を記述したルールの集合である。

　さらに、当該ノード１００には、これに紐づく形で入出力装置１４０が備わる。入出力装置１４０は、ノード１００の管理者とのインターフェースとしての役割を備える。

　以下、上述の各部の詳細について説明する。リクエスト受信部１２０は、ＢＣシステム１の外部（例：他ノード）から、ＢＣシステム１に関する構成変更の要求すなわち構成変更リクエストＴ１０や、ＢＣシステム１の内部すなわち既存のノードから構成変更において確認すべき影響確認項目を記載した構成確認リクエストＴ２０を受信する。

　本実施例では、ノード１００は、自身が管理権限を持つ管理範囲に対して発行されたリクエストのみ閲覧可能であり、構成変更リクエストＴ１０や構成確認リクエストＴ２０は適切な権限を持った組織間すなわち管理範囲でのみ共有されるものとする。

　確認項目抽出部１１０は、リクエスト受信部１２０から、構成変更リクエストや他ノードから共有された構成確認リクエストを受け取り、自ノードが保有しているＢＣ構成情報Ｔ１５０の中から、自ノードが管理権限を持つ管理範囲の設定項目Ｔ１５０Ｘを取得した後、影響判定ルールＴ１７０を用いて影響分析を行い、リクエストに対して影響され得る個設定項目のリストである影響確認項目Ｔ３０を抽出する処理部である。ここでは、ノードが保有している構成情報は、ノードの参加している管理範囲やノードの権限に拠るため、影響確認項目Ｔ３０はノードごとに異なる結果となる。

　リクエスト送信部１２１は、確認項目抽出部１１０によって抽出された影響確認項目を、その項目を保有する管理範囲に対し管理権限を持つ他のノード（すなわち管理者ノード）に送信する処理部である。

　このリクエスト送信部では、影響確認項目の管理範囲に対し管理権限を持つノードを、管理範囲の設定項目リストＴ１５０Ｘに記載されている管理者ノード情報Ｔ１５３Ｘ（後述の図４に記載）を参照して取得し、該当ノードに影響確認項目を構成確認リクエストＴ２０として送信する。

　影響確認項目管理部１９０は、確認項目抽出部１１０によって抽出された影響確認項目Ｔ３０を、確認項目リストＴ１６０に追加する他、他ノードから共有された構成変更リクエストＴ１０や構成確認リクエストＴ２０に対して、確認項目リストＴ１６０の内容と比較して既にあるか否か判定する処理部である。

　承認結果共有部１３０は、各ノードの管理者が入出力装置１４０を介して確認項目リストＴ１６０を承認した結果を、他ノードと共有する処理部である。ここでは、承認結果だけでなく、承認に必要な署名情報も共有される場合がある。承認結果が一定の条件を満たした場合、後述の構成変更処理が実行される。
　構成変更実行部１８０は、上述の承認結果を受けてＢＣシステム１の構成変更を実際に行う処理部である。
－－－ＢＣシステムにおける管理構造－－－

　図３は、本実施例におけるＢＣシステム１の管理構造を示す。本実施例のＢＣシステム１における管理構造は、コンソーシアムレイヤー、業務レイヤー、ＳＣレイヤーの３階層にそれぞれ配置された管理範囲の集合としてＢＣシステム１を定義したものとなる。

　ここでは、業務グループは、Ａ、Ｂの２グループに分けられ、さらに業務Ａグループでは取引ＳＣ（スマートコントラクト。以下ＳＣ）とユーザ管理ＳＣの２つのＳＣが稼働し、また、業務Ｂグループでは取引ＳＣが稼働している。

　また、本実施例の既存のノード構成としては、コンソーシアムに参加している組織Ｏｒｇ１～Ｏｒｇ８のうちＯｒｇ１，２，５，６の各ノードが、本コンソーシアムの管理者ノードとなっている。

　また、業務Ａに参加しているＯｒｇ１～Ｏｒｇ６のうちＯｒｇ１～４が業務Ａグループの管理者ノード、業務Ｂに参加しているＯｒｇ１，２，Ｏｒｇ５～８のうちＯｒｇ５～８が業務Ｂグループの管理者ノードである。

　また、業務Ａグループで実行されるＳＣのうち、取引ＳＣを実行するのはＯｒｇ１～４で、そのうちＯｒｇ１，２が管理者ノード、ユーザ管理ＳＣを実行するのはＯｒｇ１～４で、そのうちＯｒｇ３，４が管理者ノードとする。
　また、業務Ｂグループで実行される取引ＳＣを実行するのはＯｒｇ５～８で、そのうちＯｒｇ７，８が管理者ノードとする。

　また、図示するように、既存のノード構成に対する構成変更リクエストＴ１０として、ｎｅｗＯｒｇをコンソーシアムと業務Ｂグループ、その下のレイヤーの取引ＳＣにメンバノードとして追加することに関して、以降の実施例では想定する。ただし説明の簡便化のため、業務Ｂグループ以下への構成変更リクエスト、影響項目抽出処理、確認項目リストなどの本発明に関わる処理は、以降の図や説明では省略する。

　なお、本実施例では、各管理範囲において、その管理範囲の構成情報を変更するための条件である構成変更ポリシーが定義されており、それによれば、各管理範囲において、管理者ノード全体のうちｎ個のノードの承認によって構成変更処理が実行可能、となっているものとする。このポリシーを「ｎ－ｏｆ－管理者ノード」と表す。

　なお、こうした模式図は、説明上、ＢＣシステム構成の把握を容易化するために作成した図であり、実運用上ではＢＣシステム１の全体像を知る者は存在しない。よって、このように各ノードがどのグループに属しているかを全て把握できるようなテーブルは存在しないことに留意する。

　続いて、上述の管理範囲の概念について図４に基づき説明する。図４は、或る管理範囲Ｘにおける設定項目を表すテーブルＴ１５０Ｘを示す図である。この管理範囲Ｘにおける設定項目はリスト形式として定義され、管理範囲の名前Ｔ１５１Ｘ、管理範囲に所属するメンバノードＴ１５２Ｘ、管理範囲に対して管理権限を持つ管理者ノードＴ１５３Ｘ、管理範囲の設定項目に対する構成変更ポリシーＴ１５４Ｘ、および各管理範囲固有の設定項目Ｔ１５５Ｘで構成されている。

　ここでは、管理範囲固有の設定項目Ｔ１５５Ｘとして、取引ＳＣの設定項目であるＳＣのバージョン、ＳＣ記述言語、ＳＣ承認ポリシー、およびブロック取得実行権限が定義されている。
　以降では、メンバノードや管理者ノードを構成する組織の名称として、ＯｒｇＸという表記を用いる。

　上述のＳＣ承認ポリシーとは、ＳＣを実行したノードのうちいくつのノードから承認が返ってきたら、ＳＣの実行結果が正しい結果だとしてブロックに記載されるかを表すポリシーである。構成変更ポリシーＴ１５４Ｘと同様にｎ－ｏｆ－ノードの形で表される。

　また、ブロック取得実行権限とは、ブロックチェーンのブロックをＡＰＩを通じて取得する権限を表しており、図の例ではＯｒｇ１かＯｒｇ２の管理者のみがブロック情報を取得できることを条件式で表現している。
－－－テーブル類の構成等－－－

　図５は、本実施例における構成変更リクエストＴ１０を示す。本実施例において構成変更リクエストＴ１０は、外部からＢＣシステム１に与えられる。構成変更リクエストＴ１０はリスト形式になっており、リクエストＩＤ（Ｔ１１）、構成変更対象である管理範囲Ｔ１２、項目名Ｔ１３、変更前情報Ｔ１４、変更後情報Ｔ１５、および概要Ｔ１６で構成される。

　本実施例では説明の簡便化のため、構成変更リクエストＴ１０を１つのみ例示するが、実際には業務Ｂグループ以下に対しても同様の構成で構成変更リクエストが発行されている。

　上述のうち管理範囲Ｔ１２は、図３のＢＣシステム１の管理構造における管理範囲と対応している。ここではコンソーシアム、業務グループＡ，Ｂ、取引ＳＣ、ユーザ管理ＳＣ、のいずれかの値となる。

　また、項目名Ｔ１３は、管理範囲Ｔ１２における１つの設定項目を指し示す名称である。これは、図４における項目名と対応しており、本例では管理範囲「コンソーシアム」における「メンバノード」を指し示している。

　また、変更前情報Ｔ１４は、構成変更項目Ｔ１３の現在の内容を表す。本実施例では管理範囲「コンソーシアム」の項目名「メンバノード」として、「Ｏｒｇ１～Ｏｒｇ８」の値が定義されている。

　また、変更後情報Ｔ１５は、構成変更リクエストＴ１０によって変更された場合の、構成変更項目Ｔ１３の変更後の内容を表す。本実施例では管理範囲「コンソーシアム」の項目名「メンバノード」として、既存の「Ｏｒｇ１～Ｏｒｇ８」に加えて「ｎｅｗＯｒｇ」が追加された状態を示している。
　また、概要Ｔ１６は、構成変更リクエストＴ１０を自然言語で記述したものである。この項目は構成変更の意図を表すものとして記述された値となる。

　続いて図６に、影響判定ルールＴ１７０の例を示す。本実施例における影響判定ルールＴ１７０とは、ＢＣシステム１において、或る設定情報を変更したときに、他の設定項目に影響があることを示すルールや規則性を表したテーブルである。

　本実施例における影響判定ルールＴ１７０は、業務Ａグループや取引ＳＣなどの管理範囲単位で記述されるものではなく、より一般的な業務レイヤーやＳＣレイヤーなどの階層間における共通のルールを記述したものである。

　こうした影響判定ルールＴ１７０は、複数階層にまたがり、例えば図６では業務レイヤーへのメンバノード追加に対して、ＳＣレイヤーのメンバノードやＳＣ承認ポリシーへの影響が定義されている。

　また、影響判定ルールＴ１７０は、ＩＤ（Ｔ１７１）、影響元の設定項目Ｔ１７２、および影響先の設定項目Ｔ１７５で構成されるリストである。このうち影響元の設定項目Ｔ１７２と影響先の設定項目Ｔ１７５は、それぞれ管理レイヤー（Ｔ１７３，Ｔ１７６）と設定項目名（Ｔ１７４，Ｔ１７７）が定義されている。

　本実施例における影響判定ルールＴ１７０は、あらかじめ同一基盤の別ＢＣシステムにおける構成情報Ｔ１５０内の設定項目同士の相関をとることで作成された、静的な情報であるとする。

　具体的には、スマートコントラクトやコンソーシアム設定情報などに含まれる組織情報や他の情報について、同一ワードで記述された箇所を抽出し、人または自動的なシステムが適切な抽象化を行った上で、相関関係として影響判定ルールＴ１７０に記載したものである。

　また、他の影響判定ルールＴ１７０の作成手法としては、ＢＣシステム１における過去の構成変更の履歴から、同時に変更された設定項目を抽出し、影響判定ルールＴ１７０に動的に追加していく方法が考えられる。
　また、上流工程等で決定された業務要件から決定されるネットワークトポロジー情報などを、影響判定ルールＴ１７０として定義する方法も考えられる。

　なお、本実施例では影響判定ルールＴ１７０はＢＣシステム１の参加者に共有されているが、ノード１００のもつ管理権限に基づいてアクセスに制限があってもよい。

　また図７は、確認項目抽出部１１０によって、構成変更リクエストＴ１０または構成確認リクエストＴ２０を入力として構成情報Ｔ１５０の中から抽出された影響確認項目Ｔ３０を表す。

　この影響確認項目Ｔ３０は、リクエストＩＤ（Ｔ３１）、構成変更対象である管理範囲Ｔ３２、項目名Ｔ３３、変更前情報Ｔ３４、変更後情報Ｔ３５、および概要Ｔ３６で構成される。

　このうち変更前情報Ｔ３４は、影響確認項目の現在の値が記載される。また、変更後情報Ｔ３５は空欄である。また概要Ｔ３６は、構成変更リクエストＴ１０の概要Ｔ１６を継承したものであり、構成変更の意図を表すものとして記述されている。
　また図８は、影響確認項目Ｔ３０を他ノードに共有するために、管理者ノードごとに送信する影響確認項目をまとめた構成確認リクエストＴ２０を表す。

　この構成確認リクエストＴ２０は、リクエストＩＤ（Ｔ２１）、構成変更対象である管理範囲Ｔ２２、影響確認項目の項目名Ｔ２３、変更前内容Ｔ２４、変更後内容Ｔ２５、および概要Ｔ２６で構成される。

　この構成確認リクエストＴ２０は、形式としては影響確認項目Ｔ３０と同様であるが、影響確認項目Ｔ３０が構成変更リクエストに対し抽出された影響確認項目を表すのに対し、構成確認リクエストＴ２０は、それを送信する管理者ノードごとに分けたリクエストとして定義される。そのため、構成確認リクエストＴ２０において、各行の管理範囲は同一である。
　続いて図９に、本実施例における構成変更リクエストＴ１０の影響確認終了後に、各ノードに対して出力される確認項目リストＴ１６０の例を表す。

　この確認項目リストＴ１６０は、構成変更リクエストＴ１０や構成確認リクエストＴ３０、影響確認項目Ｔ２０をノードごとに格納するリストとして定義される。
　その構成は、ＩＤ（Ｔ１６１）と管理範囲Ｔ１６２、項目名Ｔ１６３、変更前情報Ｔ１６４、変更後情報Ｔ１６５、および概要Ｔ１６６で構成される。

　本実施例では、Ｏｒｇ１の確認項目リストＴ１６０として、コンソーシアムの設定に変更がある構成変更リクエストＴ１０に加え、業務Ａグループの設定項目であるメンバノードと、取引ＳＣの設定項目であるＳＣ承認ポリシーが、確認項目リストＴ１６０として出力される。

　また、本実施例においては、構成変更リクエストＴ１０に関して参照権限のないＯｒｇ３の場合、確認項目リストＴ１６０としては自ノードが権限を持つ業務Ａグループ、ユーザ管理ＳＣに関する確認項目のみが表示される。
－－－構成変更管理方法（実施例１）－－－

　続いて、本実施例における構成変更管理方法の実際手順について図に基づき説明する。以下で説明する構成変更管理方法に対応する各種動作は、構成変更管理システムたるブロックチェーンシステム１における各ノード１００が実行するプログラムによって実現される。そして、このプログラムは、以下に説明される各種の動作を行うためのコードから構成されている。

　図１０は、本実施形態における構成変更管理方法のフロー例１を示す図である。ここではまず、ＢＣシステム１の外部から、構成変更リクエストＴ１０が発行されたとする。所定の管理ノードが当該構成変更リクエストＴ１０を受信し、この構成変更リクエストＴ１０に記載された管理範囲Ｔ１２に権限を持つ他ノードに対し、当該構成変更リクエストを配信して共有を図る（ｓ１）。

　次に、上述の構成変更リクエストＴ１０を受け取ったノードを起点とした各ノード（すなわち管理範囲Ｔ１２に権限を持つ該当ノードら）は、確認項目抽出処理（図１２で詳細を解説）を再帰的に実行し、ＢＣシステム１内の管理範囲を跨いで確認すべき影響確認項目を抽出し、各ノードで確認項目リストＴ１６０を生成する（ｓ２）。本ステップの詳細については後述する。
　その後、ＢＣシステム１における各ノードは、上述の確認項目リストＴ１６０を当該ノードの管理者向けに入出力装置１４０で表示する（ｓ３）。

　図１１に、上述のように入出力装置１４０で表示された確認項目リストＴ１６０の画面１０００の具体例を示す。上述の管理者は、この画面１０００を閲覧して確認項目リストＴ１６０の内容確認し、影響確認項目を踏まえた構成変更の承認または訂正の判断を行う。

　そのため画面１０００は、確認項目リストＴ１６０を表示したものに加え、構成変更を承認する承認ボタン１００１、構成変更に対する修正を他ノードに送信する修正ボタン１００２、構成変更を却下する却下ボタン１００３を含んでいる。ただし、これは一例であって、修正ボタン１００２と却下ボタン１００３に関しては、どちらか一方のみが実装されていてもよい。

　こうした画面１０００は、入出力装置１４０におけるディスプレイ等を介してノードの管理者に表示される。図１１では、一例して「Ｏｒｇ１」の管理者に表示される画面例を表す。このＯｒｇ１の管理者は、画面内の確認項目リストＴ１６０における「変更前情報」と「変更後情報」とを比較することで、構成変更を行った際の影響を調べることができる。

　これで問題なければ構成変更を承認する承認ボタン１００１を押下することとなる。一方、問題がある場合、構成変更を却下する却下ボタン１００３を押下するか、確認項目リストＴ１６０内の「変更後情報」の値を修正することができる。上述の管理者が「変更後情報」を修正した場合、この修正後に修正内容を送信する修正ボタン１００２を押下する。するとこれを受けたノード１００は、修正後の確認項目情報を、該当設定項目の管理範囲に権限のある他のノードに、構成変更リクエストとして送信する（本実施例の場合Ｏｒｇ２，Ｏｒｇ３，Ｏｒｇ４、の各ノードに対し送信）。

　一方、各ノードは、管理者により上述の確認項目リストＴ１６０に対して行われた承認処理の結果を取得する（ｓ４）。ここでの承認処理とは、確認項目リストＴ１６０を承認するか、却下するか、あるいは修正するかであり、上述の画面１０００で押下されたボタンに応じた「結果」が該当ノード間で共有される。すなわち各ノードの承認結果は、承認結果共有部１３０で共有される。

　上述の共有の結果、管理範囲Ｔ１２に権限を持つ全ノードの管理者が承認処理を行った場合（ｓ５：ｙｅｓ）、該当各ノードは構成変更リクエストＴ１０に沿って構成変更処理を構成変更実行部１８０で一括実行する（ｓ６）。

　一方、管理範囲Ｔ１２に権限を持つ全ノードのうち１以上のノードの管理者が承認処理を行わなかった場合（ｓ５：ｎｏ）、且つ或るノードが、構成変更に対して管理者による修正処理を受けた場合（ｓ７：ｙｅｓ）、当該修正を構成変更リクエストとして、管理範囲Ｔ１２に権限を持つ各ノードに送信し（ｓ８）、ｓ１から再び処理を行う。

　他方、構成変更に対し修正処理を受けておらず（ｓ７：ｎｏ）、構成変更の却下処理がなされていた場合は（ｓ９）、該当各ノードは構成変更が棄却されたとして構成変更処理を行わず、処理を終了する。

　本実施例では、承認結果共有部１３０において、すべてのノードが承認した場合に構成変更処理を行うとしたが、実際にはその限りではなく、所定の条件を満たした場合に構成変更処理を行うとしてもよい。

　ここでの所定の条件とは、各管理範囲においてｎ－ｏｆ－管理者ノード形式で設定されている構成変更ポリシーを全管理範囲において満たすようなノードの承認を得るなどが挙げられる。

　また、本実施例では構成変更処理を各ノードが行うとしたが、これもその限りではない。例えば、各管理範囲を代表するノードが承認結果を受けて構成変更トランザクションをＢＣシステム１に発行することが考えられる。
　ここで、上述のフローにおけるステップｓ２すなわち確認項目抽出処理の詳細について、図１２のフローに基づき説明する。

　この場合、本フローは、ＢＣシステム１に参加しているノードのうち１ノード（ここではノードＸとする）が主体となって、構成変更リクエストＴ１０または構成確認リクエストＴ２０（以下、これらを総称し「リクエスト」とする）を入力とする処理である。
　まず、ノードＸは、入力であるリクエストが、すでに確認項目リストＴ１６０に記載されているかチェックする（ｓ１０）。

　上述のチェックの結果、当該リクエストが確認項目リストＴ１６０に記載済みであった場合（ｓ１０：ｙｅｓ）、ノードＸは処理を終了する。この条件分岐処理により、再帰処理の終了条件を明確化するとともに、重複した処理を行わないことで全体としての処理を高速・軽量化させる。

　一方、上述のチェックの結果、当該リクエストが確認項目リストＴ１６０に記載されていなかった場合（ｓ１０：ｎｏ）、ノードＸは、当該リクエストをノードＸの確認項目リストＴ１６０に追加した後（ｓ１１）、影響判定ルールＴ１７０の中から、ノードＸが管理権限をもつルールを抽出し、取得する（ｓ１２）。

　また、ノードＸは、ｓ１２で得た各ルールを参照し、本ノードが保有する構成情報Ｔ１５０内の管理範囲の設定情報Ｔ１５１Ｘから、入力であるリクエストに影響される設定項目を影響確認項目Ｔ３０として抽出する（ｓ１３）。

　続いて、ノードＸは、上述のリクエストとｓ１３で抽出された影響確認項目Ｔ３０を、本ノードＸにて管理者が承認処理を行う影響確認項目として、確認項目リストＴ１６０に追加する（ｓ１４）。

　また、ノードＸは、ｓ１３で抽出した影響確認項目Ｔ３０の管理範囲に対し管理権限のある他のノードのリストを、構成情報Ｔ１５０の管理者ノードリストＴ１５２Ｘを参照し取得する（ｓ１５）。

　その後、ノードＸは、ｓ１５で取得したノードリストに対し、ｓ１３で抽出した影響確認項目Ｔ３０を構成確認リクエストＴ２０として入力し、確認項目抽出処理を実行する（ｓ１６）。

　こうした処理を繰り返すことで、構成変更リクエストＴ１０を入力としてノードＸの権限の範囲内で抽出した影響確認項目Ｔ３０を他のノードに構成確認リクエストＴ２０として共有し、共有先のノードがその構成確認リクエストＴ２０を入力として再び影響確認項目を抽出し、それを他ノードに構成確認リクエストＴ２０として共有するという、連鎖が発生する。
　以上の処理により、構成変更リクエストＴ１０に権限のあるノードだけでなく、ＢＣシステム全体で構成変更に対して影響確認を行うこととなる。

　なお、本実施例では、リクエスト送信部１２０、リクエスト受信部１２１、承認結果共有部１３０などの他ノードと通信する処理部が別個に定義されていたが、これは他ノードとの通信機能をまとめた処理部として定義されていてもよい。

　これを実現する実装のひとつとして、スマートコントラクトを用いた方法が考えられる。具体的には、業務とは別に全組織が参加するスマートコントラクトを作成し、その中で各管理範囲権限の下で構成変更リクエストや構成確認リクエスト、承認結果をステート情報（ブロックチェーン上で保持されるデータ）として共有する。

　また、プライベートグループ（スマートコントラクト内で特定の組織間のみに情報を共有可能）を用いてこれを実現する方法（Ｈｙｐｅｒｌｅｄｇｅｒ　Ｆａｂｒｉｃ”，　［ｏｎｌｉｎｅ］、［平成３０年２月２７日検索］、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｈｙｐｅｒｌｅｄｇｅｒ－ｆａｂｒｉｃ．ｒｅａｄｔｈｅｄｏｃｓ．ｉｏ／ｅｎ／ｌａｔｅｓｔ／＞）も考えられる。

　また、本実施例において、管理構造がツリー状であったが、実際にはその限りではない。例えばＳＣ間連携や業務グループ間連携を行う場合であっても、問題なく確認項目抽出処理を行うことができる。

　また、本実施例の適用範囲はＢＣシステムのみに限らない。ＢＣシステムと連携するアプリや運用管理ツールについても、管理権限が複数の組織にまたがる場合があり、このとき、アプリやツールを新しい管理範囲として定義することによって本手法を適用することができる。ＢＣシステムと完全に独立した分散システムであっても、複数の管理範囲が存在する場合には適用可能である。

　以上により、非中央集権であるＢＣシステム１の構成変更に際し、個々の組織による権限の範囲内でＢＣシステム全体として抜けもれのない影響確認項目の確認が可能である。

　また、組織ごとに影響確認項目をまとめて出力し、ノードごとに管理者が承認または訂正することにより、ＢＣシステム全体としての確認工数を削減することが可能である。

　また、管理者らが承認した結果をノード間で共有し、所定ルールの下、一括して構成変更処理を行うことにより、個別に構成変更処理を行うよりもエラーやシステム停止のリスクを低減することも可能となる。更に、確認項目抽出処理を再帰的に行うことによって、処理の終了条件を明確化させることができる。

　また、スマートコントラクトを用いて構成変更リクエストや構成確認リクエスト、承認結果の共有を行うことで、実施例１の処理をＢＣシステム上で自動化し、かつ影響確認項目を抽出した証跡を残すことができる。

　また、他ノードから共有された構成変更リクエストや構成確認リクエストを、自ノードの確認項目リストと一致しているかを検索し、一致していた場合に処理を終了する再帰処理方法によって、再帰処理にかかる計算量や時間を削減することができる。
[実施例２]

　実施例１においては、各組織の確認項目リストに対し、入出力装置１４０を通じてノード１００の管理者が承認または訂正の指示を行っていた。しかし、影響確認項目の修正を行う場合は、ノード管理者が修正内容を考える必要があった。そのため、ノード管理者はＢＣシステム１の設定についてある程度の知識を要していることが前提となる。

　そこで本実施例では、条件式を付与した影響判定ルールを適用することで、確認項目抽出処理の際に、重要な影響確認項目については、影響確認項目とともにその修正案が出力され、これがノード管理者に提示される形態について示す。これにより、ノード管理者が修正内容を考える必要なく、影響確認項目の修正が可能となる。

　本実施例では、例えば、図９に記載のノードごとの確認項目リストＴ１６０に対し、要修正項目としてのフラグ（以下要修正フラグと称する）と修正案を付与することができる。ノード管理者は入出力装置１４０を通して要修正フラグ付きの確認項目とその修正案を確認することができることとなる。

　この場合、影響判定ルールＴ１７０は、図２で既に例示したものとは異なり、条件式付きのテーブルとして定義されたものとなる。また、影響確認項目管理部１９０で確認項目に要修正フラグを付与する処理が行われる。

　また処理の流れとしては、確認項目抽出部１１０で抽出された影響確認項目Ｔ３０には実施例１と異なり変更後情報が付与される。その後、変更後情報は構成確認リクエストＴ２０や確認項目リストＴ１６０にも継承され、ノード管理者には修正案として表示される。また、確認項目リストＴ１６０には前述の要修正フラグも付与される。

　ここで、本実施例における影響判定ルールＴ１７０Ｐを図１３に示す。本実施例における影響判定ルールＴ１７０Ｐは、ＢＣシステム１の構成上の必要条件を記述したルールの集合として定義される。

　そうした必要条件としては、例えば、ＳＣレイヤーのＳＣ承認ポリシーにＯｒｇＸが入っているならば、その直属の業務グループにおいてＯｒｇＸはメンバノードである必要がある、といったものを想定できる。また、例えばグループ内の役割を示す固有の設定項目であるＲｏｌｅについて、業務要件から導き出されるルールとして、ある組織がＲｏｌｅ＝Ｙとして定義されているならば、ユーザ管理ＳＣの管理者ノードである必要がある、などいったものも考えられる。

　本実施例の影響判定ルールＴ１７０ＰはＩＤ（Ｔ１７１Ｐ）、影響元Ｔ１７２Ｐ、影響先Ｔ１７５Ｐ、および条件式Ｔ１７８Ｐで構成される。このうち、影響元Ｔ１７２Ｐと影響先Ｔ１７５Ｐは、それぞれ管理レイヤー（Ｔ１７３Ｐ、Ｔ１７６Ｐ）と項目名（Ｔ１７４Ｐ、Ｔ１７７Ｐ）で構成される。

　これは、実施例１の影響判定ルールＴ１７０に条件式Ｔ１７８Ｐが加わったものである。条件式Ｔ１７８Ｐは、影響元Ｔ１７２Ｐと影響先Ｔ１７５Ｐの関係性を条件式で表したものである。例えばＩＤ１の行では、影響元（ＳＣ承認ポリシーに所属しているノード）のＯｒｇＸは必ず、その親の業務グループのメンバノードに含むことを表す。

　構成変更リクエストＴ１０に対して本影響判定ルールＴ１７０Ｐを用いた場合、出力される影響確認項目Ｔ３０には、条件式Ｔ１７８Ｐに基づき計算された変更後情報Ｔ３５が付与される。変更後情報が付与された影響確認項目Ｔ３０は、実施例１における「確認したほうがよい項目」ではなく、「具体的にこう変更することが必要な項目」であることを示している。これは、ノード管理者にとっては通常の確認項目よりも注視すべき確認項目である。

　なお、条件式Ｔ１７８Ｐが空欄の場合、実施例１と同様の影響判定ルールであることを示しており、これは実施例１と互換性を保っていることを表している。（例：ＩＤ３の行）。

　本実施例における確認項目リストＴ１６０を図１４に示す。確認項目リストＴ１６０は、実施例１と同様のＩＤ（Ｔ１６１）、管理範囲Ｔ１６２、項目名Ｔ１６３、変更前情報Ｔ１６４、変更後情報Ｔ１６５、概要Ｔ１６６に加えて、要修正フラグＴ１６７で構成されている。

　要修正フラグＴ１６７は、条件付き影響判定ルールＴ１７０Ｐによって変更後情報が付与された影響確認項目について、影響確認項目管理部１９０が付与するフラグである。

　要修正フラグがＴｒｕｅのとき（図の行３）、その確認項目は、あらかじめ与えられた構成変更リクエストＴ１０ではなく、かつ変更後情報が記載されている。この変更後情報は、ノード管理者には影響確認項目の修正案として表示される。つまり、要修正フラグは修正案とセットでノード管理者に通知される。
－－－構成変更管理方法（実施例２）－－－

　本実施例における確認項目抽出処理のフローを図１５に示す。前提として、全体フローは実施例１と同様（図１０）である。一方、確認項目抽出処理で異なるのは、入力が変更後情報付き構成確認リクエストであった場合、確認項目リストに要修正フラグを立てて追加することである。

　確認項目抽出処理フローの詳細を以下に示す。まず実施例１と同様に、ノードＸは、入力（構成変更リクエストＴ１０あるいは構成確認リクエストＴ２０）と確認項目リストＴ１６０との照合による、既存の影響確認項目との一致検索（ｓ１０）を行う。

　入力が既存の影響確認項目と一致しない場合（ｓ１０：ｎｏ）、ノードＸは、実施例２特有の処理として、入力が変更後情報付き構成確認リクエストであるか識別する（ｓ２０）。

　入力が変更後情報付き構成確認リクエストでなかった場合（ｓ２０：ｎｏ）、ノードＸは、実施例１と同様に、当該リクエストをノードＸの確認項目リストＴ１６０に追加する（ｓ１１）。

　一方、入力が変更後情報付き構成確認リクエストであった場合（ｓ２０：ｙｅｓ）、ノードＸは、当該リクエストを優先度高の修正すべき影響確認項目として、要修正フラグ付きで確認項目リストＴ１６０に追加する（ｓ２１）。

　ノードＸは、上述のリクエストを確認項目リストＴ１６０に追加後、実施例１と同様に自ノードが権限を持つ影響判定ルールを抽出し（ｓ１２）、当該影響判定ルールから影響確認項目を抽出する（ｓ１３）。
　その後、ノードＸは、実施例２に特有の処理として、ｓ１３で抽出した影響確認項目それぞれについて変更後情報に記載があるか判定する（ｓ２２）。

　この判定の結果、影響確認項目に変更後情報の記載がない場合（ｓ２２：Ｎｏ）、ノードＸは、実施例１と同様に影響確認項目を自ノードの確認項目リストＴ１６０に追加する（ｓ１４）。

　一方、影響確認項目に変更後情報が記載されていた場合（ｓ２２：Ｙｅｓ）、ノードＸは、この影響確認項目は条件式付き影響判定ルールＴ１７０Ｐから導出された影響確認項目だと判定できるため、ｓ２１と同様に要修正フラグを付与して確認項目リストＴ１６０に追加する（ｓ２３）。

　以降は実施例１と同様に、各影響確認項目に管理権限のある他のノードのリストを取得し（ｓ１５）、そのノードに対し影響確認項目を確認項目リストＴ１６０として入力する確認項目抽出処理を実行する（ｓ１６）、といった再帰処理を行う。

　上述の再帰処理の終了後、ノードごとの管理者は入出力装置１４０を介して、ノードごとの確認項目リストＴ１６０を確認することとなる。このとき、ノードＸは、ｓ２０において要修正フラグ付きで確認項目リストＴ１６０に追加された変更後情報付き構成確認リクエストを、修正すべき確認項目として、修正案が表示された状態でノードの管理者向けに表示する。このとき、要修正フラグがある場合は色付きで表示を行うなどが考えられる。

　こうした形態を採用することで、ノード管理者は、優先度の高い影響確認項目を区別できることに加えて、表示された修正案を承認することで、自身が修正内容を考えなくても影響確認項目の修正を行うことができる。

　また、ノード管理者がＢＣシステム１に関して一定レベル以上の知識を持っていなかったとしても、ＢＣシステム１の構成変更において要修正項目を効率良く発見し、適宜に修正することができる。

　以上、本発明を実施するための最良の形態などについて具体的に説明したが、本発明はこれに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。

　こうした本実施形態によれば、ＢＣシステムの構成変更において、組織ごとに知り得る情報のみを用いつつ、ＢＣシステム全体として抜け漏れない設定項目の確認が効率的に実施可能となる。これにより、ＢＣシステムの特徴である非中央集権性を維持したまま正確な構成変更処理を可能にする。すなわち、ＢＣシステムの構成変更に際し、各組織の権限内で、システム全体として効率的な確認を精度良好に行うことが可能となる。

　本明細書の記載により、少なくとも次のことが明らかにされる。すなわち、本実施形態の構成変更管理方法において、前記各ノードが、前記影響確認項目の抽出に際し、事前定義された影響判定ルールを用いて、当該ノードにおける前記構成情報から影響確認項目を抽出する、としてもよい。

　これによれば、影響確認項目の抽出を効率化すること可能となり、ひいては、ＢＣシステムの構成変更に際し、各組織の権限内で、システム全体としてさらに効率的な確認を精度良好に行うことが可能となる。

　また、本実施形態の構成変更管理方法において、前記各ノードが、前記影響確認項目の抽出に際し、前記影響判定ルールとして、スマートコントラクトないし前記構成情報の各間において共通するキーワードに基づく相関関係の特定により生成した前記影響判定ルールを用いて、当該ノードにおける前記構成情報から影響確認項目を抽出する、としてもよい。

　これによれば、知見ある者等による過去実績に基づくルールにて、影響確認項目の抽出を精度良く行うことが可能となり、ひいては、ＢＣシステムの構成変更に際し、各組織の権限内で、システム全体としてさらに効率的な確認を精度良好に行うことが可能となる。

　また、本実施形態の構成変更管理方法において、前記各ノードが、前記ブロックチェーンシステムにおける構成変更履歴に基づき、同時に変更された項目を特定し、当該項目を影響確認項目として規定する前記影響判定ルールの生成ないし更新を行う、としてもよい。

　これによれば、ＢＣシステムにおける管理者ノード等で合意形成を経た構成変更に基づき、影響判定ルールの生成や更新が可能であり、スキルや経験を有した者による判断結果を踏まえたルール下での影響確認項目の抽出が可能となる。ひいては、ＢＣシステムの構成変更に際し、各組織の権限内で、システム全体としてさらに効率的な確認を精度良好に行うことが可能となる。

　また、本実施形態の構成変更管理方法において、前記各ノードが、前記構成変更リクエスト、前記影響確認項目、および前記影響確認項目に関する承認結果、の少なくともいずれかをスマートコントラクトを使用して他ノードと共有する、としてもよい。

　これによれば、ノード間での影響確認項目等の共有が効率的なものとなり、ひいては、ＢＣシステムの構成変更に際し、各組織の権限内で、システム全体としてさらに効率的な確認を精度良好に行うことが可能となる。

　また、本実施形態の構成変更管理方法において、前記各ノードが、前記構成変更リクエストまたは前記影響確認項目に関する他ノードからの構成確認リクエストによって他ノードから共有された影響確認項目について、自ノードで保持する影響確認項目のリストと比較を行い、当該項目についての影響確認項目の抽出が完了している場合、後続の再帰処理を省略するとしてもよい。

　これによれば、再帰処理の無駄を排除することが可能となり、ひいては、ＢＣシステムの構成変更に際し、各組織の権限内で、システム全体としてさらに効率的な確認を精度良好に行うことが可能となる。

　また、本実施形態の構成変更管理方法において、前記各ノードが、前記ブロックチェーンシステム全体として確認すべき影響確認項目を抽出した後、当該組織ごとの影響確認項目のリストをノードの管理者宛てに表示し、当該管理者による確認結果である構成変更の承認または訂正または却下、に対応する所定処理を実行するとしてもよい。

　これによれば、ＢＣシステムにおける管理者ノードのユーザすなわち管理者が影響確認項目を適宜に認識し、その判断の材料として利用ことが可能となり、また、そうした判断の結果を踏まえた処理が自動実行されることになる。ひいては、ＢＣシステムの構成変更に際し、各組織の権限内で、システム全体としてさらに効率的な確認を精度良好に行うことが可能となる。

　また、本実施形態の構成変更管理方法において、前記各ノードが、組織ごとの前記影響確認項目の承認結果をノード間で共有し、当該承認結果が予め定めた合意条件を満たしたことを契機に、一括して構成変更処理を行う、又は合意条件を満たさなかった場合に構成変更処理を棄却する、としてもよい。

　これによれば、管理者ノード間での合意形成を経た上で、構成変更処理を包括的に実行／棄却可能となり、ひいては、ＢＣシステムの構成変更に際し、各組織の権限内で、システム全体としてさらに効率的な確認を精度良好に行うことが可能となる。

　また、本実施形態の構成変更管理方法において、前記各ノードが、組織ごとの前記影響確認項目の承認結果をノード間で共有し、当該承認結果が予め定めた合意条件を満たさず、前記影響確認項目のリストの一部に対する前記管理者による修正処理を受けた場合、当該修正処理の内容を構成変更リクエストとして他ノードと共有し、当該構成変更リクエストに関して、前記影響確認項目の抽出処理、当該影響確認項目についてノード間での互いの共有および再帰処理、および前記ブロックチェーンシステム全体として確認すべき影響確認項目の抽出、の各処理を再実行する、としてもよい。

　これによれば、構成変更リクエストに関する修正が管理者から提議された状況に対応し、これを新たな構成変更リクエストとして処理対象とすることができる。ひいては、ＢＣシステムの構成変更に際し、各組織の権限内で、システム全体としてさらに効率的な確認を精度良好に行うことが可能となる。

　また、本実施形態の構成変更管理方法において、前記各ノードが、前記影響確認項目の抽出に際し、所定の条件式付き影響判定ルールを用いて、当該ブロックチェーンシステムで優先して確認ないし修正すべき影響確認項目を抽出する、としてもよい。

　これによれば、知見が得られている特定の事象等について上述の条件式により効率良く特定し、これに応じた影響確認項目の抽出が可能となる。ひいては、ＢＣシステムの構成変更に際し、各組織の権限内で、システム全体としてさらに効率的な確認を精度良好に行うことが可能となる。

１　　　ＢＣシステム（構成変更管理システム）
１００　ノード
１０１　演算装置
１０２　記憶装置
１０２　プログラム
１０３　通信装置
１１０　確認項目抽出部
１２０　リクエスト受信部
１２１　リクエスト送信部
１３０　承認結果共有部
１４０　入出力装置
１８０　構成変更実行部
１９０　影響確認項目管理部
Ｔ１０、Ｔ２０　構成変更リクエスト
Ｔ３０　影響確認項目
Ｔ１５０　ノード保有ＢＣ構成情報
Ｔ１５１　ノード保有ＢＣ構成情報
Ｔ１５２　ノード保有ＢＣ構成情報
Ｔ１５０Ｘ　管理範囲Ｘ設定項目リスト
Ｔ１６０、Ｔ１６１　確認項目リスト
Ｔ１７０　影響判定ルール
２００　ノード
３００　ノード

Claims (12)

1. 　ブロックチェーンシステムを構成する各ノードが、
   　当該ブロックチェーンシステムに対する構成変更リクエストに関して、当該ノードの所属組織の構成情報に基づいた影響確認項目の抽出処理を行い、当該影響確認項目についてノード間で互いに共有および再帰処理を行い、前記ブロックチェーンシステム全体として確認すべき影響確認項目を抽出することを特徴とする構成変更管理方法。
2. 　前記各ノードが、
   　前記影響確認項目の抽出に際し、事前定義された影響判定ルールを用いて、当該ノードにおける前記構成情報から影響確認項目を抽出する、ことを特徴とする請求項１に記載の構成変更管理方法。
3. 　前記各ノードが、
   　前記影響確認項目の抽出に際し、前記影響判定ルールとして、スマートコントラクトないし前記構成情報の各間において共通するキーワードに基づく相関関係の特定により生成した前記影響判定ルールを用いて、当該ノードにおける前記構成情報から影響確認項目を抽出する、ことを特徴とする請求項２に記載の構成変更管理方法。
4. 　前記各ノードが、
   　前記ブロックチェーンシステムにおける構成変更履歴に基づき、同時に変更された項目を特定し、当該項目を影響確認項目として規定する前記影響判定ルールの生成ないし更新を行う、ことを特徴とする請求項２に記載の構成変更管理方法。
5. 　前記各ノードが、
   　前記構成変更リクエスト、前記影響確認項目、および前記影響確認項目に関する承認結果、の少なくともいずれかをスマートコントラクトを使用して他ノードと共有する、ことを特徴とする請求項１に記載の構成変更管理方法。
6. 　前記各ノードが、
   　前記構成変更リクエストまたは前記影響確認項目に関する他ノードからの構成確認リクエストによって他ノードから共有された影響確認項目について、自ノードで保持する影響確認項目のリストと比較を行い、当該項目についての影響確認項目の抽出が完了している場合、後続の再帰処理を省略することを特徴とする請求項１に記載の構成変更管理方法。
7. 　前記各ノードが、
   　前記ブロックチェーンシステム全体として確認すべき影響確認項目を抽出した後、当該組織ごとの影響確認項目のリストをノードの管理者宛てに表示し、当該管理者による確認結果である構成変更の承認または訂正または却下、に対応する所定処理を実行することを特徴とする請求項１に記載の構成変更管理方法。
8. 　前記各ノードが、
   　組織ごとの前記影響確認項目の承認結果をノード間で共有し、当該承認結果が予め定めた合意条件を満たしたことを契機に、一括して構成変更処理を行う、又は合意条件を満たさなかった場合に構成変更処理を棄却する、ことを特徴とする請求項７に記載の構成変更管理方法。
9. 　前記各ノードが、
   　組織ごとの前記影響確認項目の承認結果をノード間で共有し、当該承認結果が予め定めた合意条件を満たさず、前記影響確認項目のリストの一部に対する前記管理者による修正処理を受けた場合、当該修正処理の内容を構成変更リクエストとして他ノードと共有し、当該構成変更リクエストに関して、前記影響確認項目の抽出処理、当該影響確認項目についてノード間での互いの共有および再帰処理、および前記ブロックチェーンシステム全体として確認すべき影響確認項目の抽出、の各処理を再実行する、ことを特徴とする請求項７に記載の構成変更管理方法。
10. 　前記各ノードが、
    　前記影響確認項目の抽出に際し、所定の条件式付き影響判定ルールを用いて、当該ブロックチェーンシステムで優先して確認ないし修正すべき影響確認項目を抽出する、ことを特徴とする請求項２に記載の構成変更管理方法。
11. 　複数のノードから構成されるブロックチェーンシステムであって、前記複数ノードのそれぞれが、当該ブロックチェーンシステムに対する構成変更リクエストに関して、当該ノードの所属組織の構成情報に基づいた影響確認項目の抽出処理を行い、当該影響確認項目についてノード間で互いに共有および再帰処理を行い、前記ブロックチェーンシステム全体として確認すべき影響確認項目を抽出するものである、ことを特徴とする構成変更管理システム。
12. 　ブロックチェーンシステムを構成するノードであって、当該ブロックチェーンシステムに対する構成変更リクエストに関して、当該ノードの所属組織の構成情報に基づいた影響確認項目の抽出処理を行い、当該影響確認項目について他ノードとの間で互いに共有および再帰処理を行い、前記ブロックチェーンシステム全体として確認すべき影響確認項目を抽出するものである、ことを特徴とするノード。

Images