JP7065751B2 - 分散データ管理方法及び分散データ管理装置 - Google Patents

Description

本発明は、ブロックチェーンを利用した台を、複数の事業者で共有する分散データ管理方法及び分散データ管理装置に関する。

サプライチェーンは、メーカーから最終消費者に至るまでの物やサービスの経路であり、材料、部品、組立、運搬、販売に至る様々な企業（または団体）間もしくは企業内の部門間での取引等の情報がやり取りされる。

サプライチェーン上では商流、金流、物流等の情報が伝達されるが、それぞれの企業間で情報の格差がある。例えば、より最終消費者に近い事業者は、需要変動等を早めに察知することができるのに対し、上流のサプライヤには情報伝達が遅れるため納期変更などの急な対応や、在庫枯渇もしくは過多といった状態が起こりうる。サプライチェーン内の情報流通においては、誰かが一方的に変更するのではなく、ステークホルダの合意形成が必要となる。

一方で、ブロックチェーン等の分散台帳技術は、安全かつ改ざんの防止を行いながら、情報共有を行うことができ、サプライチェーン内の情報格差を解消するという効果が期待されている。

特許文献１では、送り手が受け手に対して契約内容の合意を取り付けたい場合に、ブロックチェーンのトランザクションに契約内容とその承認依頼を、署名付きでブロックチェーンの参加者に一斉にブロードキャストする。そして、特許文献１には、受け手が自身の受信データのうち、自分自身が承認するレコードを取得し、署名付で承認済トランザクションをさらにブロードキャストする方法が開示されている。

特許文献１では、このような仕組みで１つのトランザクションに１つの電子署名という形態を保持しつつ、多人数であっても効率的に契約の証跡をブロックチェーンに残す。

特開２０１７－２２０７１０号公報

上記特許文献１の技術をサプライチェーン上の取引で活用すると、承認相手の選定方法、及び３者以上が同じ契約データ（レコード）を修正できないという課題が生じる。

１点目の承認相手の選定に関しては、サプライチェーンでは受け手が送り手を自動的に選定する必要がある。また、サプライチェーンではトランザクション数が膨大になる。例えば、商品の納期や発注量の変更を行う場合で、複数の業者に修正を依頼する場合、送り手が１件ずつ承認先を指定するのは膨大な手間が掛かる。

２点目は契約データを３者以上で共有する場合に、複数の変更を承認前に同時に行うことができないといった問題がある。例えばＡ社、Ｂ社、Ｃ社の３者が商品の納期や数量に関する契約を結んでいたとする。Ａ社がＢ社に対して納期に関する契約変更に関する依頼を行う。一方でＣ社がＡ社に同時または遅れて納期に関する契約変更を行ったとする。

しかしＣ社はＡ社からＢ社への変更内容を把握していないため、Ｃ社からＡ社への契約変更依頼が無駄になってしまう可能性がある。またこれを防ぐためには、Ａ社からＢ社への契約変更依頼を行う際に、その契約レコードに関する変更をロックすることになるが、ロックされた契約についてはＣ社の業務を無駄に停止することになる、という問題があった。

そこで本発明は上記課題を顧みて、サプライチェーンの膨大な取引において、データの追加、変更、削除に関する承認先を自動的に選択してトランザクションデータを発行することを目的とする。さらに複数の事業者が取引データを同時に修正しようとした場合も、承認前に修正内容を参加者全員で共有し、各修正内容に鑑みて各参加者がトランザクションデータを発行可能にすることを目的とする。

本発明は、プロセッサとメモリと台帳を格納する記憶部を有するサーバが、前記台帳を他のサーバと分散して管理するブロックチェーンシステムの分散データ管理方法であって、前記サーバが、項目と項目の値を含むデータを格納する前記台帳に対する修正内容と前記修正内容に対する承認条件を受け付ける第１のステップと、前記サーバが、前記項目と項目の値に応じて当該データにアクセス可能なサーバを承認グループとして予め設定されたアクセス権管理台帳を参照して前記修正内容の承認を依頼する承認グループのサーバを決定する第２のステップと、前記サーバが、前記修正内容と前記承認グループのサーバと前記承認条件を予め設定された仮更新台帳へ書き込む第３のステップと、前記サーバが、前記修正内容を含む承認申請を前記承認グループのサーバへ送信する第４のステップと、前記サーバが、前記承認グループのサーバから前記修正内容に対する承認結果を受け付けて、前記承認結果が前記承認条件を満たしているか否かを判定する第５のステップと、前記サーバが、前記承認条件を満たしていると判定した場合には、前記仮更新台帳の前記修正内容を前記台帳へ反映させる第６のステップと、を含む。

したがって、本発明は、サプライチェーン内の膨大な取引において、データの追加、変更、削除に関する承認先を自動的に選定したトランザクションデータを発行することが可能となる。さらに本発明は、複数の参加者が同一のデータを同時に修正しようとした場合、トランザクションの承認前に修正内容を参加者全員が共有し、各修正内容を鑑みて承認結果（トランザクションデータ）を発行することが可能となる。

本明細書において開示される主題の、少なくとも一つの実施の詳細は、添付されている図面と以下の記述の中で述べられる。開示される主題のその他の特徴、態様、効果は、以下の開示、図面、請求項により明らかにされる。

本発明の実施例を示し、台帳共同管理システムの一例を示すブロック図である。 本発明の実施例を示し、台帳共同管理サーバの機能要素の一例を示すブロック図である。 本発明の実施例を示し、台帳共同管理サーバの構成の一例を示すブロック図である。 本発明の実施例を示し、発注台帳の一例を示す図である。 本発明の実施例を示し、生産管理台帳の一例を示す図である。 本発明の実施例を示し、アクセス権管理台帳の一例を示す図である。 本発明の実施例を示し、進捗情報表示画面の一例を示す図である。 本発明の実施例を示し、進捗情報生成処理の一例を示すフローチャートである。 本発明の実施例を示し、修正依頼画面の一例を示す図である。 本発明の実施例を示し、警告が表示された場合の修正依頼画面の一例を示す図である。 本発明の実施例を示し、仮更新台帳の一例を示す図である。 本発明の実施例を示し、データ修正及び修正依頼処理の一例を示すフローチャートである。 本発明の実施例を示し、承認依頼画面の一例を示す図である。 本発明の実施例を示し、仮更新台帳に含まれる承認用レコードの一例を示す図である。 本発明の実施例を示し、承認処理の一例を示すフローチャートである。 本発明の実施例を示し、承認後のデータ反映処理の一例を示すフローチャートである。 本発明の実施例を示し、承認状況確認画面の一例を示す図である。

以下、本発明の実施例について図面を用いて詳細に説明する。

図１Ａは、本実施例の合意形成システムの一例を示すブロック図である。図１Ｂは、合意形成システムを構成する台帳共同管理サーバの機能要素の一例を示すブロック図である。

図１Ａにおいて、合意形成システムは、Ｈ社、Ｉ社、及びＪ社のように複数の取引企業の業務システム１０１－１～１０１－３と、各社の端末１１１－１～１１１－４に接続された台帳共同管理サーバ１００－１～１００－３と、台帳共同管理サーバ１００－１～１００－３を相互に接続するネットワーク２００を含む。

Ｈ社の業務システム１０１－１は、Ａ工場の端末１１１－１と調達部門の端末１１１－２とを含む。Ｉ社の業務システム１０１－２及びＪ社の業務システム１０１－３は、それぞれｗ端末１１１－３と１１１－４を含む。

なお、以下の説明では、台帳共同管理サーバの個々を特定しない場合には、「－」以降の符号を省略した符号「１００」を使用する。他の構成要素の符号についても、同様である。

各社の端末１１１では、発注システムデータベース１２１と生産管理システムデータベース１２２が稼働する。各社の業務システム１０１にはブロックチェーン（ブロックチェーンシステム）１０４を利用して、台帳を分散して管理する台帳共同管理サーバ１００がそれぞれ配置され、端末１１１と接続される。

端末１１１は、発注や、出荷、契約の依頼、変更、承認などの情報を台帳共同管理サーバ１００へ送信する。Ｈ社、Ｉ社、Ｊ社の台帳共同管理サーバ１００－１～１００－３は、各社の端末１１１から受け付けた情報を、後述するブロックチェーン１０４上の台帳に反映させて共有し、共同で管理する。

台帳共同管理サーバ１００は、ブロックチェーン１０４を利用して他社の台帳共同管理サーバ１００と台帳を共有管理する自動執行プログラム１０５を実行する。図１Ｂで示すように、各社の台帳共同管理サーバ１００で共有されるブロックチェーン１０４上の分散共有台帳としては、発注台帳１３１と、生産管理台帳１３２と、アクセス権管理台帳１３３と、更新用の仮発注台帳１４１と、更新用の仮生産管理台帳１４２と、仮更新台帳１４０及びアクセス権管理台帳１３３が含まれる例を示す。

発注台帳１３１と、生産管理台帳１３２はマスタとして機能し、仮発注台帳１４１及び仮生産管理台帳１４２は、発注台帳１３１と生産管理台帳１３２の複製であり、更新用の台帳として機能する。仮更新台帳１４０は、発注台帳１３１または生産管理台帳１３２に対する修正内容と、修正内容に対する承認の履歴が蓄積される。

アクセス権管理台帳１３３は、後述するように、サプライチェーンのグループ単位で承認を行うための承認グループが予め設定される。

ブロックチェーン１０４には、発注台帳１３１と、生産管理台帳１３２と、仮発注台帳１４１と、仮生産管理台帳１４２と、仮更新台帳１４０及びアクセス権管理台帳１３３のトランザクションが記録される。各台帳の内容については後述する。

台帳共同管理サーバ１００の自動執行プログラム１０５は、ブロックチェーン１０４のトランザクションを参照、更新に関するプログラムである。台帳共同管理サーバ１００は自動執行プログラム１０５を能動的に起動できる他、トランザクションの更新の度に自動執行プログラム１０５を実行することもできる。自動執行プログラム１０５は、スマートコントラクト等のブロックチェーン１０４が保有する機能を用いてもよい。

自動執行プログラム１０５は、データ結合部１５１と、データ登録部１５２と、データ収集部１５３と、合意形成部１５４と、承認部１５５と、更新部１５６のプログラムモジュールを含む。

図２は、本実施例の台帳共同管理サーバ１００の構成の一例を示すブロック図である。台帳共同管理サーバ１００は、ＣＰＵ２０２と、メモリ２０７と、ネットワークインターフェイス２０３と、入力装置２０４と、ストレージ装置２０５と、出力装置２０６を含む。これらの構成要素はバス（またはインターコネクト）２０１を介して接続されており、それぞれデータの入出力を行う。

ＣＰＵ２０２は、メモリ２０７にロードされた自動執行プログラム１０５を実行し、データ入力や、演算、データ出力等の様々な処理を実行する。

ネットワークインターフェイス２０３は、ネットワーク２００を介して他社の台帳共同管理サーバ１００等とデータの送受信を行う装置である。ネットワークインターフェイス２０３の送受信する内容はＣＰＵ２０２によって制御される。ネットワークインターフェイス２０３は、例えば、ＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）や無線ＬＡＮインターフェイスカードなどで構成される。

入力装置２０４は、台帳共同管理サーバ１００を使用するユーザの指示を受け取りＣＰＵ２０２へ伝達する。入力装置２０４は、例えば、キーボードやマウスやタッチパネル等で構成される。

メモリ２０７は、ＣＰＵ２０２で処理されるプログラム、及びデータなどが格納される。ストレージ装置２０５は、不揮発性の記憶媒体を含む。ストレージ装置２０５は、例えばＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）等の磁気ディスクやＤＶＤ等の光学ディスクや不揮発性メモリ等で構成される。

ストレージ装置２０５には、発注台帳１３１と、生産管理台帳１３２と、仮発注台帳１４１と、仮生産管理台帳１４２と、アクセス権管理台帳１３３及び仮更新台帳１４０が格納される。なお、図示の仮更新台帳１４０は、後述するように仮発注台帳１４１と仮生産管理台帳１４２の変更に対する承認内容を蓄積する情報である。

出力装置２０６は、ＣＰＵ２０２の指令に基づいてユーザインターフェイスの画面を表示する装置である。出力装置２０６は、例えば、液晶ディスプレイ等である。

ＣＰＵ２０２は、各機能部のプログラムに従って処理を実行することによって、所定の機能を提供する機能部として稼働する。例えば、ＣＰＵ２０２は、データ結合プログラムに従って処理を実行することでデータ結合部１５１として機能する。他のプログラムについても同様である。さらに、ＣＰＵ２０２は、各プログラムが実行する複数の処理のそれぞれの機能を提供する機能部としても稼働する。計算機及び計算機システムは、これらの機能部を含む装置及びシステムである。

以下の説明では、ユーザが端末１１１の入力装置と出力装置（図示省略）から台帳共同管理サーバ１００を介して各台帳へのデータの追加や修正を依頼する例を示すが、ユーザは台帳共同管理サーバ１００の入力装置２０４と出力装置２０６を利用して各台帳へのデータの追加や修正を依頼してもよい。

次に、図１Ｂに含まれる各種データについて説明する。図３は、発注台帳１３１の一例を示す図である。

発注台帳１３１は、企業間もしくは企業内組織（グループ会社）間での受発注に関するデータを管理する。発注台帳１３１は、例えば、注文番号３０１と、発注元３０２と、担当者３０３と、発注先３０４と、発注日３０５と、納期３０６、商品名３０７と、数量３０８を含む。

発注台帳１３１は、発注システムデータベース１２１や生産管理システムデータベース１２２で発生する注文情報を管理する。発注台帳１３１は、図３に示すとおり、自由形式のレコードの列であってもよいし、ＲＤＢ（Ｒｅｌａｔｉｏｎａｌ ＤａｔａＢａｓｅ）のような形式であってもよい。

注文番号３０１は、発注台帳１３１に含まれる注文履歴を区別する識別子を含む。よって注文番号３０１は、他のレコードと異なる番号もしくは記号が付与される。

発注元３０２は、発注元の企業の名称又は識別子を格納する。担当者３０３は、発注元３０２における発注担当者の氏名を格納する。発注先３０４は、発注先の企業の名称又は識別子を格納する。

発注日３０５は、発注元３０２と発注先３０４が注文内容に合意した日付を格納する。納期３０６は、注文内容の合意内容に含まれる納入予定日を格納する。

商品名３０７は、発注元３０２が注文した商品の名称又は識別子である。数量３０８は発注元３０２が注文した商品の数量を格納する。

なお図３に示した発注台帳１３１の構成はあくまで一例であり、必要に応じて項目の順番や追加および項目名の変更は行ってもよい。また特別契約が必要で、現状のテーブルでは表現しきれない場合は、契約書が紐づけられる情報を格納してもよい。

図４は、生産管理台帳１３２の一例を示す図である。生産管理台帳１３２は企業間もしくは企業内組織（グループ会社）間での生産進捗管理を行う。生産管理台帳１３２は、生産管理システムデータベース１２２と同様の構成を有する。

生産管理台帳１３２は、例えば、作業番号４０１と、注文番号４０２と、発注元４０３と、商品名４０４と、数量４０５と、受注日４０６と、要求納期４０７と、予定納期４０８と、作業内容４０９と、完了予定４１０を構成要素に含む。

生産管理台帳１３２は、本実施例の注文内容に対する生産、調達、作業などの業務計画を管理する。生産管理台帳１３２は、図４に示すとおり、自由形式のレコードの列であってもよいし、ＲＤＢのような形式であってもよい。

作業番号４０１は、生産管理台帳１３２に含まれる各作業を区別する識別子を格納する。作業番号４０１には、他のレコードと異なる番号もしくは記号が付与される。

注文番号４０２は、発注台帳１３１に含まれる注文番号３０１であり、発注台帳１３１の関連付け情報となる。本実施例においては、１つの注文番号４０２に対して作業番号４０１が複数存在することを想定する。

発注元４０３、商品名４０４、数量４０５は、発注台帳１３１に含まれる同名の情報である。受注日４０６は、生産管理台帳１３２に情報が書き込まれた日付を格納する。要求納期４０７は、注文内容（合意内容）に含まれる納入予定日を格納する。

予定納期４０８は、生産管理の内容や手動により更新される受注側からの予定納期である。予定納期４０８が要求納期４０７を超える場合には問題が発生するため、後述の合意形成が必要となる。

作業内容４０９は、生産管理に基づく実行予定の作業内容や作業の名称を格納する。完了予定４１０は、本作業番号４０１に含まれる作業が終わる予定日が記載される。作業の進捗に合わせて完了予定日は都度更新できるようにしてもよい。

なお図４に示した生産管理台帳１３２の構成はあくまで一例であり、必要に応じて項目の順番や追加および項目名の変更は行ってもよい。また特別契約が必要で、現状のテーブルでは表現しきれない場合は、契約書が紐づけられる情報を格納してもよい。

続いてブロックチェーン１０４を適用する台帳について説明する。ブロックチェーン１０４には発注台帳１３１と生産管理台帳１３２及びアクセス権管理台帳１３３と、仮発注台帳１４１と、仮生産管理台帳１４２及び仮更新台帳１４０が含まれる。

なお、仮発注台帳１４１は、発注台帳１３１を更新するための仮台帳である。また、仮生産管理台帳１４２は、生産管理台帳１３２を更新するための仮台帳である。仮更新台帳１４０は、上述のように修正内容と承認の履歴が蓄積される。

仮発注台帳１４１は図３の発注台帳１３１と同様の形式である。また仮生産管理台帳１４２も図４の生産管理台帳１３２と同様の形式となっている。本実施例では、ブロックチェーン１０４上のトランザクションとして図３や図４の発注台帳１３１や生産管理台帳１３２の各レコードが署名により暗号化されて各台帳に記録されている。

なお本実施例の合意形成システムにおいて、ブロックチェーン１０４で格納される発注台帳１３１と生産管理台帳１３２は、自動執行プログラム１０５のデータ収集部１５３により、定期的に発注システムデータベース１２１と生産管理システムデータベース１２２と同期されているものとする。

また、マスタとなる発注台帳１３１と、更新用の仮発注台帳１４１の関係は、次のとおりである。端末１１１が情報（トランザクション）を追加や更新（あるいは削除）する場合、まず、自社の台帳共同管理サーバ１００でマスタに対する修正内容を仮更新台帳１４０と仮発注台帳１４１に情報を書き込む。

台帳共同管理サーバ１００は、アクセス権管理台帳１３３を参照して、修正内容のデータに関係する企業５０４を承認先として特定する。

台帳共同管理サーバ１００は、端末１１１から承認条件（合意条件）を受け付けると、承認申請のトランザクションを仮更新台帳１４０に書き込んで、上記特定した承認先へ送信する。

承認を依頼された台帳共同管理サーバ１００は、それぞれ自社の端末１１１で承認を受け付けて、承認結果をブロックチェーン１０４を介して承認を要求した台帳共同管理サーバ１００へ応答する。

承認を要求した台帳共同管理サーバ１００は、他社の承認結果に基づいて所定の合意条件を満たしているかを判定し、合意条件を満たしていれば、発注台帳１３１と生産管理台帳１３２に修正内容を反映させる。また、台帳共同管理サーバ１００は、仮更新台帳１４０に合意が形成されたトランザクションとして記録する。

自動執行プログラム１０５は、マスタの発注台帳１３１へ書き込んだ内容を、発注システムデータベース１２１へ反映させることができる。

一方、合意条件を満たしていなければ、マスタの発注台帳１３１への書き込みは実施されず、仮発注台帳１４１の修正内容は元に戻され、仮更新台帳１４０には承認条件を満たしていなかったトランザクションとして蓄積される。

生産管理台帳１３２と仮生産管理台帳１４２の関係も、上記発注台帳１３１と仮発注台帳１４１の関係と同様であり、仮生産管理台帳１４２に対する追加や更新（あるいは削除）のトランザクションのうち、所定の合意条件を満たしたトランザクションがマスタである生産管理台帳１３２へ書き込まれる。

ブロックチェーン１０４上の発注台帳１３１、生産管理台帳１３２、仮発注台帳１４１と仮生産管理台帳１４２、仮更新台帳１４０及びアクセス権管理台帳１３３は、所定数のトランザクション毎にブロックが形成される。各ブロックは、少なくとも直前のブロックのハッシュ値と、トランザクションが含まれる。また、各ブロックは上述のように署名によって暗号化されてもよい。

ブロックの生成は、台帳共同管理サーバ１００で行ってもよいし、ネットワーク２００に接続された他の計算機で行ってもよい。また、ハッシュ値を生成する際のナンスの実装や、署名の採用は合意形成システムの運用に応じて適宜選択することができる。

また、手動によって発注台帳１３１及び生産管理台帳１３２が同期されてもよい。また発注台帳１３１と生産管理台帳１３２はデータベースシステムではなく、テキストや表計算ソフトウェアで生成されたファイルであってもよく、その場合は各業務システム１０１の担当者が手動でファイルをアップロードし、データ登録部１５２で更新できるようにしてもよい。

次に、アクセス権管理台帳１３３について説明する。図５は、アクセス権管理台帳１３３の一例を示すブロック図である。アクセス権管理台帳１３３は、管理者などによって予め生成される。なお、本実施例では、台帳共同管理サーバ１００がアクセス権管理台帳１３３を、承認先の管理台帳として利用する例を示す。

アクセス権管理台帳１３３は、ブロックチェーン１０４上のトランザクションに対するデータ参照や、編集権限を格納する。アクセス権管理台帳１３３はグループ番号５０１と、グループキー５０２と、グループ情報５０３と、所属企業５０４で構成される。

グループ番号５０１は、アクセス権のグループを識別する番号である。グループキー５０２は、発注台帳１３１や生産管理台帳１３２に含まれるカラムの名称が設定される。グループキー５０２は、アクセス権のグループを制御する単位（項目）を格納する。図５の例では、発注台帳１３１や生産管理台帳１３２の項目のうち「商品名」毎にグループを構成する場合を例示している。

グループ情報５０３は、グループキー５０２に対して実際に構成されるグループの中身（項目の値）を示す。図示の例では、発注台帳１３１や生産管理台帳１３２の商品名３０７，４０４という項目で、商品名が「部材Ｘ」という値を含むデータで、サプライチェーンのグループを設定する。

所属企業５０４は、グループ情報５０３で指定された値を有するレコードにアクセス可能な企業名が格納される。図５の例では、グループ情報５０３＝商品名が「部材Ｘ」に関する発注台帳１３１や生産管理台帳１３２は、Ｈ社、Ｉ社、Ｊ社が参照または編集できる。なお、所属企業５０４に設定されていない企業の台帳共同管理サーバ１００は、当該グループ番号５０１のデータへのアクセスが拒否される。

所属企業５０４に設定された企業名の台帳共同管理サーバ１００は、承認申請に対する承認グループとなる。例えば、図５の例では、商品名「部材Ｘ」を取り扱うＨ社、Ｉ社、Ｊ社の台帳共同管理サーバ１００で承認グループが構成される。承認グループでは、１社が修正内容の承認申請を提案すると、残りの企業の台帳共同管理サーバ１００で承認が実行される。

すなわち、Ｈ社が提案した修正内容に対する承認申請は、Ｉ社とＪ社の台帳共同管理サーバ１００によって承認処理が実行される。

台帳共同管理サーバ１００は、図５に示したアクセス権管理台帳１３３を参照することで、グループキー５０２（項目）とキーの値であるグループ情報５０３（商品名）に基づいて、承認申請を送信する承認先の企業名（台帳共同管理サーバ１００）を特定することが可能となる。

これにより、台帳共同管理サーバ１００は、発注台帳１３１と生産管理台帳１３２を多数の企業で共有して、合意の形成先（承認先）を迅速に特定することが可能となる。

これらのアクセス権は例えばサプライチェーン上の部材取引とその影響範囲で創生してもよい。

次に自動執行プログラム１０５を構成する各プログラムモジュールで行われる処理の一例を説明する。

自動執行プログラム１０５のデータ結合部１５１は、各社の端末１１１からの命令（修正要求や承認結果）に応じて、ブロックチェーン１０４に登録されている各トランザクションを呼び出して、最新の進捗情報を端末１１１（または台帳共同管理サーバ１００の出力装置２０６）へ出力することができる。

具体的には、データ結合部１５１のプログラムモジュールは、仮発注台帳１４１と仮生産管理台帳１４２から抽出したデータから進捗情報６０１を生成し、進捗情報６０１の要求を受け付けた端末１１１へ進捗情報表示画面６００を出力する。

データ収集部１５３は、所定の周期でブロックチェーン１０４に参加している企業の発注システムデータベース１２１及び生産管理システムデータベース１２２のデータを、発注台帳１３１及び生産管理台帳１３２へ同期させる。

また、データ収集部１５３は、所定の周期で発注台帳１３１及び生産管理台帳１３２のデータを、仮発注台帳１４１と仮生産管理台帳１４２へ同期させる。

合意形成部１５４は、修正依頼のあったトランザクションを仮発注台帳１４１と仮生産管理台帳１４２から取得して仮更新台帳１４０に追加し、承認を依頼する企業の台帳共同管理サーバ１００を自動的に選択し、修正依頼画面を出力装置２０６へ出力する。

承認部１５５は、設定された承認先の台帳共同管理サーバ１００へ承認申請を送信する。承認先の台帳共同管理サーバ１００は、承認申請を受け付けると、承認依頼画面を出力装置２０６または端末１１１へ出力する。

承認先の台帳共同管理サーバ１００では承認部１５５が、承認結果を端末１１１や入力装置２０４から受け付けるとブロックチェーン１０４上の仮更新台帳１４０に承認用レコードを書き込む。

更新部１５６は、仮更新台帳１４０に承認用レコードが書き込まれると、合意が形成されたか否かを判定する。更新部１５６は、アクセス可能な企業からの承認結果が揃い、合意が形成されていれば修正内容を、発注台帳１３１と生産管理台帳１３２及び仮発注台帳１４１と仮生産管理台帳１４２に反映させて、修正から合意形成の一連の処理を完了する。

一方、合意が形成されなかった場合、更新部１５６は、仮更新台帳１４０のステータス９０８に「却下」を書き込んで、合意の不成立を書き込んで、合意形成の履歴として蓄積する。なお、仮発注台帳１４１と仮生産管理台帳１４２に加えられた修正は元に戻される。

データ登録部１５２は、発注台帳１３１や生産管理台帳１３２のメインテンスの際に利用される。

図６は、進捗情報表示画面６００の一例を示す図である。進捗情報表示画面６００は、仮発注台帳１４１と仮生産管理台帳１４２から生成された進捗情報６０１と、ステータスの更新ボタン６０２と、データの修正依頼ボタン６０３を構成要素に含む。

進捗情報６０１には、自社が関係する最新の注文状況が表示される。進捗情報６０１の更新は、最初に進捗情報表示画面６００を開いた場合、もしくはステータスの更新ボタン６０２がクリックされた際に、自動執行プログラム１０５のデータ結合部１５１プログラムによって実行される。

進捗情報６０１は、注文番号６１１と、購買部署６１２と、購買担当者６１３と、発注先受付６１４と、サプライヤ受付担当６１５と、発注日６１６と、納期６１７と、商品名６１８と、数量６１９と、ステータス６２０をひとつのエントリに含む。

注文番号６１１には、発注台帳１３１の注文番号３０１が表示される。購買部署６１２には、発注台帳１３１の、発注元３０２が表示される。購買担当者６１３には、発注台帳１３１の担当者３０３が表示される。

発注先受付６１４には、発注台帳１３１の発注先３０４が表示される。サプライヤ受付担当６１５には、発注先３０４の担当者名が表示される。発注日６１６には、発注台帳１３１の発注日３０５が表示される。

納期６１７には、発注台帳１３１の納期３０６または生産管理台帳１３２の要求納期４０７が表示される。商品名６１８には、発注台帳１３１の商品名３０７が表示される。数量６１９には、発注台帳１３１の数量３０８が表示される。

ステータス６２０には、データ結合部１５１が算出したステータスが表示される。ステータス６２０としては、例えば、「受付」、「未納入」、「配送中」、「検収」、「納品完」を採用することができる。ステータス６２０が「受付」の場合、発注先が受け付けた段階で、生産管理台帳１３２の予定納期４０８が記載されていない状態を示す。

ステータス６２０が「未納入」の場合、商品が発注元４０３に到着していない状態を示す。ステータス６２０が「配送中」の場合、発注先から商品が出荷されたことを示す。ステータス６２０が「検収」の場合、発注元の企業に商品名が到着して、検収中であることを示す。

ステータス６２０が「納品完」の場合、発注元が発注先からの商品を受領して、検収に合格した状態を示す。

図７は、データ結合部１５１で行われる処理の一例を示すフローチャートである。この処理は、自動執行プログラム１０５が、端末１１１から進捗情報表示画面６００の要求を受け付けた場合に実行される。

データ結合部１５１は、進捗情報表示画面６００を要求した端末１１１のアドレスなどから、予め設定されたユーザ情報を取得する（Ｓ１）。ユーザ情報としては、端末１１１のアドレスと、企業名と、部署名（組織名）を含み、台帳共同管理サーバ１００のストレージ装置２０５に格納される。

データ結合部１５１は、上記ユーザ情報に基づいて、端末１１１を利用するユーザの企業名や部署名を特定し、特定された企業名や部署名に該当する注文情報を、ブロックチェーン１０４の仮発注台帳１４１から取得する。すなわち、進捗情報表示画面６００を要求した端末１１１のユーザ情報から、当該端末１１１の企業名または部署名に関係のあるデータを仮発注台帳１４１から取得する。

次に、データ結合部１５１は、取得した仮発注台帳１４１のレコードに含まれる注文番号３０１をキーに、仮生産管理台帳１４２から最新の情報を取得して、進捗情報６０１を生成する（Ｓ２）。

データ結合部１５１は、注文番号３０１をキーにして、仮発注台帳１４１と仮生産管理台帳１４２のデータを結合して進捗情報６０１の情報を含む進捗情報表示画面６００を生成し、進捗情報６０１を要求した端末１１１へ出力する（Ｓ３）。

上記処理によって、データ結合部１５１は、仮発注台帳１４１と仮生産管理台帳１４２から端末１１１を利用する企業に関連のある情報に絞り込みを行って表形式の進捗情報６０１を生成し、当該端末１１１に進捗情報表示画面６００を出力する。ユーザは、端末１１１の入力装置（図示省略）または入力装置２０４から進捗情報表示画面６００内の進捗情報６０１の各項目の値を修正することができる。

端末１１１（または台帳共同管理サーバ１００）のユーザが進捗情報表示画面６００で進捗情報６０１の値を修正してから、修正依頼ボタン６０３をクリックすると、自動執行プログラム１０５は、当該修正内容を他の台帳共同管理サーバ１００で承認を得るための承認依頼処理を開始する。

図８Ａは、修正依頼画面８００の一例を示す図である。修正依頼画面８００は、図６の進捗情報表示画面６００で修正依頼ボタン６０３がクリックされた際に合意形成部１５４で生成されて、端末１１１（または出力装置２０６）へ出力される画面である。修正依頼画面８００は、修正（または追加や削除）を行った進捗情報６０１（仮発注台帳１４１または仮生産管理台帳１４２）の内容について承認を得るための情報を設定することができる。

修正依頼画面８００は、承認の依頼先（図中承認先）を登録する承認先登録設定８０１、８０２、８０４、８０５と、修正内容のプレビューを示す修正内容エリア８１０と、承認依頼ボタン８０６と、キャンセルボタン８０７と、承認先追加ボタン８０３と、承認ルート追加ボタン８０８と、承認条件設定ボタン８１４、８１５を含む。

承認先登録設定８０１、８０２、８０４、８０５は、承認先を設定する入力項目である。ブロックチェーン１０４上のようにフラットに情報を共有する場合は一度に複数の承認先へ依頼することができる。ただし承認の内容によっては承認の順序を定めた方がよい場合は承認ルート追加ボタン８０８をクリックすることで、順序を追加することができる。

図示の承認ルートの例では、承認先登録設定８０１、８０２へ承認を依頼し、承認先登録設定８０１、８０２の承認結果を受け付けた後に、合意形成部１５４が承認先登録設定８０４、８０５の承認先に承認の依頼を送信することになる。

承認条件設定ボタン８１４は、承認先登録設定８０１、８０２、８０４、８０５の承認条件が「ＡＮＤ」の条件であることを設定する。承認条件設定ボタン８１５は、承認先登録設定８０１、８０２、８０４、８０５の承認条件が「ＯＲ」の条件であることを設定する。

修正内容エリア８１０には、修正内容の対象項目８１１と、当該項目の修正前の値が格納された修正前８１２と、当該項目の修正後の値が格納された修正後８１３の内容が表示される。

また承認先については、図６の進捗情報６０１の内容に応じて自動設定される。つまり購買部署や発注元などの情報に基づき、合意形成部１５４はアクセス権管理台帳１３３を参照して関連する承認先を自動的に選定する。これにより１件、１件承認先を設定する労力を低減することが可能となる。

承認先の自動選定については、合意形成部１５４がアクセス権管理台帳１３３を参照して設定してもよい。つまり当該レコード（データ）にアクセスできるユーザを、合意形成部１５４が自動的に承認先登録設定８０１、８０２となるように設定することができる。

承認依頼ボタン８０６をクリックして承認依頼処理を実行すると、合意形成部１５４が進捗情報６０１に対する修正内容を、一旦仮発注台帳１４１と、仮生産管理台帳１４２の両者に書き込む。仮更新台帳１４０は、修正内容に加えて、承認先からの承認や拒否などの合意形成の履歴を蓄積する台帳である。

仮更新台帳１４０の形式の一例を図９に示す。仮更新台帳１４０は、申請番号９０１と申請元９０２と、キー９０３と、修正内容９０４と、承認対象９０５と、承認条件９０６と、コメント９０７と、ステータス９０８の情報を含む。

申請番号９０１は、仮更新台帳１４０に含まれるレコードを区別する番号で、自動執行プログラム１０５によって付与される。申請元９０２は、承認ルートを実行する端末１１１（台帳共同管理サーバ１００）が所属する企業の名称（または識別子）である。

キー９０３は、修正対象の仮発注台帳１４１と仮生産管理台帳１４２のレコードを特定する情報である。キー９０３は、発注台帳１３１（仮発注台帳１４１）の注文番号３０１と、生産管理台帳１３２（仮生産管理台帳１４２）の注文番号４０２に対応する値である。

修正内容９０４は、キー９０３で指定されたデータに対する修正内容を示し、進捗情報６０１で修正された内容である。

承認対象９０５には、承認を依頼する企業名（または部署名）と、各企業の承認の結果が記録される。承認の結果は、「未承認」が承認待ちを示し、「承認」が修正内容９０４を承認したことを示し、「拒絶」が修正内容９０４を却下したことを示す。

承認条件９０６は、図８Ａに示した承認条件設定ボタン８１４または承認条件設定ボタン８１５で決定された、承認条件が設定される。

コメント９０７には、承認先の端末１１１（または入力装置２０４）で入力された情報が格納される。ステータス９０８には、仮更新台帳１４０の承認状態が格納され、承認状態の初期値は「未了」で、承認が行われると、「承認完了」または「却下」のいずれかの情報が設定される。「承認完了」は合意の成立を示し、「却下」は合意の不成立を示す。

本実施例の合意形成システムでは、一旦、修正内容９０４を仮更新台帳１４０に記録することで、他の端末１１１からの二重修正を防ぐ効果がある。つまり仮更新台帳１４０もブロックチェーン１０４により各端末１１１で共有されるため、端末１１１のユーザは、修正内容９０４の承認を実行する前に、同一のキー９０３に対して、既に変更申請が行われているかどうかを判別することが可能となる。

既に同一のキー９０３の仮更新台帳１４０に対して修正が行われている場合は、図８Ｂで示すように警告が表示される。図８Ｂは、警告が表示された場合の修正依頼画面の一例を示す図である。

図８Ｂの修正依頼画面８００では、上記図８Ａの修正依頼画面８００の構成に加えて、警告エリア８２０が追加される。警告エリア８２０には、仮更新台帳１４０のキー９０３が同一で先に提案された修正内容が表示される。

警告エリア８２０には、修正内容の対象項目８２１と、当該項目の修正前８２２と、修正後８２３の内容が表示される。

これにより、端末１１１のユーザは、既存の修正依頼を鑑みて承認申請を行うか否かを判別できる。また、警告エリア８２０を承認側の端末１１１（または台帳共同管理サーバ１００）へ出力することで、同一のキー９０３に対して重複する修正が行われるのを防ぐことができる。

図８Ａ、図８Ｂに示した修正依頼画面８００は合意形成部１５４によって生成されて、端末１１１へ出力される。図１０は、合意形成部１５４で行われる処理の一例を示すフローチャートである。この処理は、図６に示したデータの修正依頼ボタン６０３がクリックされた場合に実行される。

合意形成部１５４は、進捗情報表示画面６００の進捗情報６０１から、修正内容に対応する情報を読み込む（Ｓ１１）。修正内容に対応する情報は、例えば、注文番号６１１と、修正する項目（例えば、納期６１７）と、アクセス権管理台帳１３３を検索するための商品名６１８である。

合意形成部１５４は、続いて仮更新台帳１４０の内容をロードする（Ｓ１２）。合意形成部１５４は、商品名６１８と自社の企業名でアクセス権管理台帳１３３を検索し、グループ情報５０３が商品名６１８と一致し、所属企業５０４に自社が含まれるエントリを選択する。合意形成部１５４は、所属企業５０４から自社を除いた企業を、承認先として選択する（Ｓ１３）。

次に、合意形成部１５４は、図９に示した仮更新台帳１４０に新たなエントリを追加して、修正内容と承認先を書き込む（Ｓ１４）。なお、合意形成部１５４は、図８Ａに示した修正内容８１０に対象項目８１１を書き込み、修正後８１３に上記ステップＳ１１で取得した内容を書き込み、キー９０３と一致する発注台帳１３１または生産管理台帳１３２の該当項目の値を取得して修正前８１２に書き込む。

合意形成部１５４は、修正内容と承認先が書き込まれた仮更新台帳１４０をブロックチェーン１０４に登録する。合意形成部１５４は、仮更新台帳１４０の修正内容について、仮発注台帳１４１と仮生産管理台帳１４２のいずれかに書き込むかについては、修正項目を含む台帳を自動的に判定する。

次に、合意形成部１５４は、仮更新台帳１４０に今回修正するキー９０３と同一で承認待ちとなっているデータの有無を判定する（Ｓ１５）。合意形成部１５４は、仮更新台帳１４０に今回修正するキー９０３と同一で承認待ちとなっているデータがあればステップＳ１６へ進み、そうでない場合にはステップＳ１７へ進む。なお、承認待ちか否かの判定は、仮更新台帳１４０のステータス９０８が「未了」であれば、合意形成部１５４は承認待ちと判定することができる。

ステップＳ１６では、合意形成部１５４が、今回修正するキー９０３と同一で、かつ承認待ちとなっている仮更新台帳１４０を取得して、図８Ｂの警告エリア８２０に対応する対象項目８２１と、修正前８２２と、修正後８２３の情報を取得する。

次に、合意形成部１５４は、修正依頼画面８００を生成する（Ｓ１７）。合意形成部１５４は、上記ステップＳ１５の判定で、今回修正するキー９０３と同一で承認待ちとなっている仮更新台帳１４０が存在する場合には、図８Ｂに示す警告エリア８２０を含む修正依頼画面８００を生成し、そうでない場合には図８Ａに示した警告エリア８２０のない修正依頼画面８００を生成する。

合意形成部１５４は、生成された修正依頼画面８００を、修正を依頼した端末１１１へ送信する（Ｓ１８）。

上記処理によって、進捗情報６０１で修正された情報に基づいて、仮更新台帳１４０に新たなエントリが追加されて、修正を申請する端末１１１には修正依頼画面８００が出力される。

また、合意形成部１５４は、既存の申請内容に対して追加申請してもよい。また、承認先の自動選定は、図６の進捗情報６０１の内容から合意形成部１５４が自動的に提示してもよい。

修正を提案する端末１１１（または台帳共同管理サーバ１００）で、修正依頼画面８００の承認依頼ボタン８０６がクリックされると、台帳共同管理サーバ１００の合意形成部１５４が、承認先登録設定８０１、８０２、８０４、８０５に設定された企業の台帳共同管理サーバ１００へ承認申請が送信される。

承認申請には、申請番号９０１と、修正内容の対象項目８１１と、修正前８１２と、修正後８１３が含まれる。

続いて承認申請依頼に対して承認を行う承認部１５５で行われる処理の一例を説明する。承認部１５５は、他の端末１１１から承認申請が通知されると、承認依頼画面１０００を生成して、当該端末１１１（または出力装置２０６）に出力する。

承認依頼画面１０００の一例を図１１に示す。承認依頼画面１０００は、図１１に示すように承認実行エリア１１００と修正内容表示エリア１２００を含む。承認実行エリア１１００は、申請番号１１０１と、提案元１１０２と、承認状況１１０３と、アクション１１０４と、コメント１１０５をひとつのエントリに含み、各エントリには、選択スイッチ１１１０が設定される。

申請番号１１０１には、合意形成部１５４が付与したブロックチェーン１０４内でユニークな値が設定される。提案元１１０２には、承認申請を発行した台帳共同管理サーバ１００が所属する企業名が設定される。承認状況１１０３には、仮発注台帳１４１の承認対象９０５の値が設定される。

アクション１１０４は、当該端末１１１（または台帳共同管理サーバ１００）を操作するユーザが選択する承認結果のボタンが表示される。図示の例では、承認ボタンと拒絶ボタンが表示される。承認ボタンがクリックされると、当該承認申請が当該端末１１１（台帳共同管理サーバ１００）の企業で承認され、仮発注台帳１４１が更新される。拒絶ボタンがクリックされると、当該承認申請は、当該端末１１１の企業で却下され、仮発注台帳１４１が更新される。

コメント１１０５には、端末１１１の入力装置（または入力装置２０４）から入力された情報が格納され、仮発注台帳１４１のコメント９０７に反映される。

更に修正内容表示エリア１２００には、台帳共同管理サーバ１００が受信した承認申請の情報が反映され、修正内容の対象項目１２０１と、当該項目の修正前１２０２と、修正後１２０３の内容が表示される。

承認を行う端末１１１（台帳共同管理サーバ１００）のユーザは、承認対象の選択スイッチ１１１０を選択し、修正対象の申請番号１１０１の修正内容を確認する。ユーザは、問題がなければアクション１１０４で承認ボタンをクリックすることで、承認作業を終える。また問題があれば拒絶ボタンで承認を拒否することができる。また、承認状況１１０３では他社の承認の状況を閲覧することができる。また、承認の際にはコメントを残すことができる。

承認部１５５は、アクション１１０４で指示された承認（または拒否）を受け付けた後に、承認内容をブロックチェーン１０４上の仮更新台帳１４０の承認用レコードに書き込む。承認部１５５が、仮更新台帳１４０に書き込む承認用レコードの一例を図１２に示す。

図１２の承認用レコードは、図９に示した仮更新台帳１４０と同様の形式である。承認部１５５は、図１１のアクション１１０４の結果を承認対象９０５の内容に書き込む。また、承認部１５５は、承認依頼画面１０００でコメント１１０５に記載があれば、仮更新台帳１４０上の承認用レコードのコメント９０７へ反映させる。

図１３は、承認部１５５で行われる処理の一例を示すフローチャートである。この処理は、台帳共同管理サーバ１００が所定の周期で実行する。

承認部１５５は、最初に承認申請が届いているかをチェックし（Ｓ２１）、承認申請を受信していれば図１１に示した承認依頼画面１０００を端末１１１（出力装置２０６）の画面に提示する（Ｓ２２）。その後、端末１１１（台帳共同管理サーバ１００）のユーザが修正内容を確認した後に、承認実行エリア１１００のアクション１１０４で承認または拒絶を選択する。

承認部１５５は、承認もしくは拒絶（拒絶）の承認結果を受け付けると、図１２に示した承認用レコードに承認結果を反映して、ブロックチェーン１０４の仮更新台帳１４０に書き込む。

次に、自動執行プログラム１０５の更新部１５６で行われる処理について説明する。更新部１５６は、承認部１５５が実行するブロックチェーン１０４上の仮更新台帳１４０への書き込みのイベントが発生した場合に起動される。

図１４は、更新部１５６で行われる処理の一例を示すフローチャートである。更新部１５６は、ブロックチェーン１０４に書き込まれた仮更新台帳１４０の申請番号９０１と承認対象９０５を取得し、取得した申請番号９０１と承認対象９０５で仮更新台帳１４０の承認用レコードを検索する。

そして、更新部１５６は、申請番号９０１に対応する承認対象９０５が発行した全ての承認用レコードが揃っているか否かを判定する（Ｓ３１）。すなわち、更新部１５６は、承認対象９０５の企業の数と申請番号９０１に対応する承認用レコードの数が一致しているか否かを判定する。

更新部１５６は、承認対象９０５の全ての承認用レコードが揃っていない場合は処理を終了し、揃っている場合にはステップＳ３２へ進む。

ステップＳ３２では、更新部１５６が、承認対象９０５の全ての承認用レコードを読み込んで、承認対象９０５の内容が承認条件９０６を満たしているか否かを判定する。承認条件９０６を満たしていれば、ステップＳ３３へ進み、満たしていなければステップＳ３４へ進む。

ステップＳ３３では、承認対象９０５で合意が形成されたので、更新部１５６は、仮更新台帳１４０の修正内容９０４を、発注台帳１３１と生産管理台帳１３２に反映させる。さらに、更新部１５６は、仮更新台帳１４０のステータス９０８に「承認完了」を書き込んで処理を終了する。

ステップＳ３４では、承認対象９０５で合意が却下されたので、更新部１５６は、仮更新台帳１４０の修正内容９０４の反映は行わず、仮更新台帳１４０のステータス９０８に「却下」を書き込んで処理を終了する。

なお、発注台帳１３１や生産管理台帳１３２が各端末１１１の発注システムデータベース１２１や生産管理システムデータベース１２２と同期している場合には、台帳共同管理サーバ１００が発注システムデータベース１２１や生産管理システムデータベース１２２に修正された内容を書き込んでもよい。

合意形成部１５４、は更に各承認結果の内容を表示することもできる。承認結果の一覧を示す画面の一例を図１５に示す。

図１５の承認状況表示画面１５００は、図１１に示した承認依頼画面１０００とほぼ同様の構成を示すが、アクション１１０４の項目が、確認ボタンと再修正ボタンになっている点が図１１と相違する。

端末１１１のユーザが、承認内容を確認し、確認ボタンをクリックすると、承認状況表示画面１５００からは表示されなくなる。一方で、申請内容が却下されている場合は、コメント１１０５の拒絶理由などを鑑みて再申請することもできる。

本実施例では、サプライチェーン上の注文取引の変更に関する場合を示したが、必ずしもこの限りではない。例えばデータの種類を決済データや請求書データなどを追加すると決済日の変更や値段交渉等でも活用できる。

以上、本実施例によれば、取引の内容を記録する台帳（発注台帳１３１と生産管理台帳１３２、以下同様）を共有する台帳共同管理サーバ１００が、台帳の項目（グループキー５０２）と項目の値（グループ情報５０３）で、アクセス権管理台帳（承認グループ管理台帳）１３３を参照することで、当該データの修正内容について承認を行う参加者（事業者）を特定する。これにより、多数の企業が連携するサプライチェーンの中で、台帳を更新する際に承認申請を送信すべき参加者を容易に特定することができる。

台帳のデータの変更を行う際、台帳共同管理サーバ１００はアクセス権管理台帳１３３から承認申請を送信すべき参加者を自動的に選択することが可能となり、ブロックチェーン１０４を利用した台帳に対する修正の合意を、承認グループ内の参加者（台帳共同管理サーバ１００）で実現することができる。

なお、本実施例のアクセス権管理台帳１３３では、所属企業５０４で構成される承認グループを企業名で設定する例を示したが、これに限定されるものではなく、分散台帳管理に参加する台帳共同管理サーバ１００の識別子やアドレスを用いることができる。

したがって、サプライチェーンに参加している全ての企業が修正内容に対する承認を行うのではなく、修正要求のデータを利用する企業間で承認グループを形成することで、承認が必要な台帳共同管理サーバ１００のみへ承認申請を送信することができる。これにより、不要なトランザクションをブロックチェーン１０４から排除することが可能となる。

また、本実施例によれば、台帳共同管理サーバ１００が、台帳の修正内容と、承認の履歴を蓄積する仮更新台帳１４０で台帳のデータに対する修正要求（９０４）と、修正要求に対する承認（９０５）を管理する。

これにより、複数の参加者が同一のデータに対して同時に修正しようとした場合、各参加者は承認前に修正内容を全員で共有し、各修正内容に鑑みて承認結果（トランザクション）を発行することが可能となる。

また、台帳共同管理サーバ１００は、承認申請を発行する際に、承認条件（修正内容が承認される条件）を設定することができ、承認先の台帳共同管理サーバ１００が発行した承認結果が承認条件を満たす場合（合意の形成）には、修正内容を台帳に反映させることができる。

一方、承認結果が承認条件を満足しない場合には、台帳共同管理サーバ１００は、仮更新台帳１４０のステータス９０８に「却下」を書き込んで、保存する。これにより、仮更新台帳１４０は、修正要求から各参加者の承認結果に至る経緯を記録することができる。

また、データのマスタとなる台帳は、参加者の合意が形成された修正内容のみで更新されるため、各参加者は正当なデータとして台帳を利用することができる。なお、台帳共同管理サーバ１００は、合意が形成された修正内容を台帳に反映させてから、台帳と連携するデータ（発注システム１２１や生産管理システム１２２）に修正内容を適用することができる。

＜まとめ＞

以上のように、上記実施例に示した分散データ管理方法は、プロセッサ（２０２）とメモリ（２０７）と台帳を格納する記憶部（２０５）を有するサーバ（台帳共同管理サーバ１００）が、前記台帳（発注台帳１３１、生産管理台帳１３２）を他のサーバと分散して管理するブロックチェーンシステム（１０４）で、前記サーバ（１００）が、項目（５０２）と項目の値（５０３）を含む前記台帳（１３１、１３２）に対する修正内容（９０４）を受け付ける第１のステップと、前記サーバ（１００）が、前記項目（５０２）と項目の値（５０３）に応じて、前記修正内容の承認を行う承認先のサーバ（所属企業５０４）を予め設定した承認グループ管理情報（アクセス権管理台帳１３３）を参照して、承認先のサーバ（５０４）を決定する第２のステップと、を含む。

これにより、多数の企業が連携するサプライチェーンの中で、台帳を更新する際に承認申請を送信すべき参加者を容易に特定することができる。

また、サーバ（１００）が、前記修正内容（９０４）と前記承認先のサーバ（９０５）を仮更新台帳（１４０）へ書き込む第２のステップと、前記サーバ（１００）が、前記修正内容（６０４）に対する承認条件（９０６）を受け付けて仮更新台帳（１４０）へ書き込む第３のステップと、前記サーバ（１００）が、前記修正内容（９０４）を含む承認申請を前記承認先のサーバ（５０４）へ送信する第４のステップと、をさらに含む。

したがって、サプライチェーンに参加している全ての企業が修正内容に対する承認を行うのではなく、修正要求のデータを利用する企業間で承認グループを形成することで、承認が必要な台帳共同管理サーバ１００のみへ承認申請を送信することができる。これにより、不要なトランザクションをブロックチェーン１０４から排除することが可能となる。

そして、台帳のデータの変更を行う際、台帳共同管理サーバ１００はアクセス権管理台帳１３３から承認申請を送信すべき参加者を自動的に選択することが可能となり、ブロックチェーン１０４を利用した台帳に対する修正の合意を、承認グループ内の参加者（台帳共同管理サーバ１００）で実現することができる。

また、前記サーバ（１００）が、前記承認先のサーバ（５０４）から承認結果を受け付けて、前記承認結果が前記承認条件（９０６）を満たしているか否かを判定する第５のステップと、前記サーバ（１００）が、前記承認条件（９０６）を満たしている場合には、前記修正内容（９０４）を前記台帳（１３１）、１３２へ反映させる第６のステップと、をさらに含む。

また、台帳共同管理サーバ１００は、承認申請を発行する際に、承認条件（修正内容が承認される条件）を設定することができ、承認先の台帳共同管理サーバ１００が発行した承認結果が承認条件を満たす場合（合意の形成）には、修正内容を台帳に反映させることができる。

また、前記第１のステップは、前記台帳（１３１、１３２）のデータのうち、当該サーバ（１００）が関連するデータを抽出して進捗情報表示画面（６００）を出力し、当該進捗情報表示画面（６００）に対する修正を修正内容（９０４）として受け付ける。

これにより、台帳のデータのうち、当該サーバ（１００）が関連するサプライチェーンのデータのみを抽出することで、当該サーバが（１００）で承認を行わないデータを排除することが可能となる。

また、前記第６のステップは、前記台帳（１３１、１３２）が外部のデータ（１２１、１２２）と連携している場合には、前記修正内容（９０４）を前記外部のデータ（１２１、１２２）に反映させる。

これにより、台帳（１３１、１３２）は参加者の合意が形成された修正内容のみで更新されるため、各参加者は正当なデータとして台帳を利用することができ、連携する外部のデータ（１２１、１２２）にも合意された修正内容を反映させることができる。

なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に記載したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加、削除、又は置換のいずれもが、単独で、又は組み合わせても適用可能である。

また、上記の各構成、機能、処理部、及び処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、及び機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。

また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。

１００ 台帳共同管理サーバ
１０５ 自動執行プログラム
１５１ データ結合部
１５２ データ登録部
１５３ データ収集部
１５４ 合意形成部
１５５ 承認部
１５６ 更新部
１０４ ブロックチェーン
１３１ 発注台帳
１３２ 生産管理台帳
１３３ アクセス権管理台帳
１４０ 仮更新台帳
１４１ 仮発注台帳
１４２ 仮生産管理台帳
２０２ ＣＰＵ
２０３ ネットワークインターフェイス
２０４ 入力装置
２０５ ストレージ装置
２０６ 出力装置
２０７ メモリ

Claims (8)

1. プロセッサとメモリと台帳を格納する記憶部を有するサーバが、前記台帳を他のサーバと分散して管理するブロックチェーンシステムの分散データ管理方法であって、
   前記サーバが、項目と項目の値を含むデータを格納する前記台帳に対する修正内容と前記修正内容に対する承認条件を受け付ける第１のステップと、
   前記サーバが、前記項目と項目の値に応じて当該データにアクセス可能なサーバを承認グループとして予め設定されたアクセス権管理台帳を参照して前記修正内容の承認を依頼する承認グループのサーバを決定する第２のステップと、
   前記サーバが、前記修正内容と前記承認グループのサーバと前記承認条件を予め設定された仮更新台帳へ書き込む第３のステップと、
   前記サーバが、前記修正内容を含む承認申請を前記承認グループのサーバへ送信する第４のステップと、
   前記サーバが、前記承認グループのサーバから前記修正内容に対する承認結果を受け付けて、前記承認結果が前記承認条件を満たしているか否かを判定する第５のステップと、
   前記サーバが、前記承認条件を満たしていると判定した場合には、前記仮更新台帳の前記修正内容を前記台帳へ反映させる第６のステップと、
   を含むことを特徴とする分散データ管理方法。
2. 請求項１に記載の分散データ管理方法であって、
   前記仮更新台帳は、
   前記台帳の項目と項目の値を特定するキーを有し、
   前記第３のステップでは、
   前記仮更新台帳の前記台帳の項目と項目の値を特定するキーに対応づけて前記修正内容と前記承認グループと前記承認条件を書き込むことを特徴とする分散データ管理方法。
3. 請求項１に記載の分散データ管理方法であって、
   前記第６のステップでは、
   前記承認条件を満たしていないと判定した場合には、前記仮更新台帳に合意の不成立を書き込んで合意形成の履歴として蓄積することを特徴とする分散データ管理方法。
4. 請求項１に記載の分散データ管理方法であって、
   前記アクセス権管理台帳は、前記台帳の項目を特定するグループキーと、前記台帳の項目の値を特定するグループ情報と、承認グループを構成するサーバを格納し、
   前記第２のステップでは、
   前記修正内容の前記項目と項目の値で前記アクセス権管理台帳を参照して前記承認グループのサーバを取得することを特徴とする分散データ管理方法。
5. プロセッサとメモリと台帳を格納する記憶部を有し、前記台帳を他のサーバと分散して管理するブロックチェーンシステムの分散データ管理装置であって、
   前記プロセッサが、項目と項目の値を含むデータを格納する前記台帳に対する修正内容と前記修正内容に対する承認条件を受け付けて、
   前記プロセッサが、前記項目と項目の値に応じて当該データにアクセス可能なサーバを承認グループとして予め設定されたアクセス権管理台帳を参照して前記修正内容の承認を依頼する承認グループのサーバを決定し、
   前記プロセッサが、前記修正内容と前記承認グループのサーバと前記承認条件を予め設定された仮更新台帳へ書き込み、
   前記プロセッサが、前記修正内容を含む承認申請を前記承認グループのサーバへ送信し、
   前記プロセッサが、前記承認グループのサーバから前記修正内容に対する承認結果を受け付けて、前記承認結果が前記承認条件を満たしているか否かを判定し、
   前記プロセッサが、前記承認条件を満たしていると判定した場合には、前記仮更新台帳の前記修正内容を前記台帳へ反映させることを特徴とする分散データ管理装置。
6. 請求項５に記載の分散データ管理装置であって、
   前記仮更新台帳は、前記台帳の項目と項目の値を特定するキーを有し、前記キーに対応して前記修正内容と前記承認グループと前記承認条件を格納することを特徴とする分散データ管理装置。
7. 請求項５に記載の分散データ管理装置であって、
   前記プロセッサは、前記承認条件を満たしていないと判定した場合には、前記仮更新台帳に合意の不成立を書き込んで合意形成の履歴として蓄積することを特徴とする分散データ管理装置。
8. 請求項５に記載の分散データ管理装置であって、
   前記アクセス権管理台帳は、前記台帳の項目を特定するグループキーと、前記台帳の項目の値を特定するグループ情報と、前記承認グループを構成するサーバを格納し、
   前記プロセッサは、前記修正内容の前記項目と項目の値で前記アクセス権管理台帳を参照して前記承認グループのサーバを取得することを特徴とする分散データ管理装置。

Images