特開2023-98662工程管理方法、工程管理システム、及び、コンピュータプログラム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023098662
(43)【公開日】2023-07-10
(54)【発明の名称】工程管理方法、工程管理システム、及び、コンピュータプログラム
(51)【国際特許分類】
G05B 19/418 20060101AFI20230703BHJP
G06F 21/64 20130101ALI20230703BHJP
G06Q 50/04 20120101ALI20230703BHJP
【ＦＩ】
G05B19/418 Z
G06F21/64
G06Q50/04
【審査請求】未請求
【請求項の数】12
【出願形態】ＯＬ
(21)【出願番号】P 2022203217
(22)【出願日】2022-12-20
(31)【優先権主張番号】P 2021214681
(32)【優先日】2021-12-28
(33)【優先権主張国・地域又は機関】JP
(71)【出願人】
【識別番号】517040102
【氏名又は名称】ＰｗＣコンサルティング合同会社
(74)【代理人】
【識別番号】100145403
【弁理士】
【氏名又は名称】山尾 憲人
(74)【代理人】
【識別番号】100131808
【弁理士】
【氏名又は名称】柳橋 泰雄
(74)【代理人】
【識別番号】100135703
【弁理士】
【氏名又は名称】岡部 英隆
(74)【代理人】
【識別番号】100163902
【弁理士】
【氏名又は名称】市川 奈月
(72)【発明者】
【氏名】田中 宗英
(72)【発明者】
【氏名】丸山 智浩
(72)【発明者】
【氏名】林 力一
(72)【発明者】
【氏名】小川 博美
【テーマコード（参考）】
3C100
5L049
【Ｆターム（参考）】
3C100AA29
3C100AA34
3C100AA57
3C100AA68
3C100BB04
3C100BB05
3C100BB13
3C100BB15
3C100BB17
3C100BB33
3C100CC02
3C100CC07
3C100DD22
3C100DD25
3C100EE20
5L049AA00
5L049CC03
(57)【要約】
【課題】製品の製造及び製造後の管理における製品及び部品のトレーサビリティを実現する。
【解決手段】第１の情報処理部が、各情報処理部でそれぞれ管理する工程について、製造する製品の数量毎に各工程のツリー構造を生成し、各情報処理部が、数量毎に管理する工程に関するアカウントを取得し、第１の情報処理部が、ツリー構造における複数の第２の情報処理部のうち最上位の第２の情報処理部の各アカウント宛てに製品の製造に関する依頼データを生成し、第２の情報処理部は、他の第２の情報処理部に宛てた依頼データを生成し、又は、工程の実行を管理し、実行した工程の完了の履歴情報を追加して依頼データの生成元に宛てて依頼データを更新した証明データを生成し、第１の情報処理部が、各情報処理部によって各工程の実行後に送信された一連の工程に関する証明データを管理データとして記憶装置に記憶させる工程管理方法。
【選択図】図４
【解決手段】第１の情報処理部が、各情報処理部でそれぞれ管理する工程について、製造する製品の数量毎に各工程のツリー構造を生成し、各情報処理部が、数量毎に管理する工程に関するアカウントを取得し、第１の情報処理部が、ツリー構造における複数の第２の情報処理部のうち最上位の第２の情報処理部の各アカウント宛てに製品の製造に関する依頼データを生成し、第２の情報処理部は、他の第２の情報処理部に宛てた依頼データを生成し、又は、工程の実行を管理し、実行した工程の完了の履歴情報を追加して依頼データの生成元に宛てて依頼データを更新した証明データを生成し、第１の情報処理部が、各情報処理部によって各工程の実行後に送信された一連の工程に関する証明データを管理データとして記憶装置に記憶させる工程管理方法。
【選択図】図４
【特許請求の範囲】
【請求項1】
第１の情報処理部から、複数の第２の情報処理部のうち少なくとも１に宛てた工程の実行を依頼する依頼データが生成され、各情報処理部は、各工程を実行するユーザと関連付けられ、各ユーザによる操作にしたがって前記各情報処理部においてそれぞれ異なる工程の完了が順に証明され、最終的に製品の製造を管理するシステムにおいて、前記各情報処理部における各工程を管理する工程管理方法であって、
前記第１の情報処理部が、前記各情報処理部でそれぞれ管理する工程について、製造する前記製品の数量毎に各工程のツリー構造を生成し、
前記各情報処理部が、前記数量毎に管理する前記工程に関するアカウントを取得し、
前記第１の情報処理部が、前記ツリー構造における複数の前記第２の情報処理部のうち最上位の前記第２の情報処理部の前記各アカウント宛てに製品の製造に関する前記依頼データを生成し、
前記第２の情報処理部は、自処理部宛ての前記依頼データで示される工程が前記ツリー構造における他の第２の情報処理部で管理する工程である場合、前記他の第２の情報処理部に宛てた前記依頼データを生成し、
前記第２の情報処理部は、自処理部宛ての前記依頼データで示される工程が自処理部で管理する工程である場合、前記工程の実行を管理し、
前記第２の情報処理部が、管理した前記工程の実行の完了を検出すると、工程の管理の主体として当該第２の情報処理部のアカウントを追加し、実行した前記工程の完了の履歴情報を追加して前記依頼データの生成元に宛てて前記依頼データを更新した証明データを生成し、
前記第１の情報処理部が、前記各情報処理部によって各工程の実行後に送信された一連の工程に関する証明データを管理データとして記憶装置に記憶させる、
工程管理方法。
前記第１の情報処理部が、前記各情報処理部でそれぞれ管理する工程について、製造する前記製品の数量毎に各工程のツリー構造を生成し、
前記各情報処理部が、前記数量毎に管理する前記工程に関するアカウントを取得し、
前記第１の情報処理部が、前記ツリー構造における複数の前記第２の情報処理部のうち最上位の前記第２の情報処理部の前記各アカウント宛てに製品の製造に関する前記依頼データを生成し、
前記第２の情報処理部は、自処理部宛ての前記依頼データで示される工程が前記ツリー構造における他の第２の情報処理部で管理する工程である場合、前記他の第２の情報処理部に宛てた前記依頼データを生成し、
前記第２の情報処理部は、自処理部宛ての前記依頼データで示される工程が自処理部で管理する工程である場合、前記工程の実行を管理し、
前記第２の情報処理部が、管理した前記工程の実行の完了を検出すると、工程の管理の主体として当該第２の情報処理部のアカウントを追加し、実行した前記工程の完了の履歴情報を追加して前記依頼データの生成元に宛てて前記依頼データを更新した証明データを生成し、
前記第１の情報処理部が、前記各情報処理部によって各工程の実行後に送信された一連の工程に関する証明データを管理データとして記憶装置に記憶させる、
工程管理方法。
【請求項2】
前記依頼データ及び前記証明データは、ブロックチェーンシステムで利用されるデータであって、
前記完了の履歴情報は、書き込みが１回のみ可能な領域に追加される
請求項１に記載の工程管理方法。
前記完了の履歴情報は、書き込みが１回のみ可能な領域に追加される
請求項１に記載の工程管理方法。
【請求項3】
前記各情報処理部は、
前記アカウント毎の秘密鍵及び公開鍵を取得し、
前記秘密鍵で電子署名をしたデータを他の情報処理部宛てに生成する
請求項１に記載の工程管理方法。
前記アカウント毎の秘密鍵及び公開鍵を取得し、
前記秘密鍵で電子署名をしたデータを他の情報処理部宛てに生成する
請求項１に記載の工程管理方法。
【請求項4】
製造された前記製品が販売される場合、
前記第１の情報処理部は、前記製品の販売者と関連付けられる第３の情報処理部のアカウント宛てに、前記記憶装置に記憶された一連の工程に関する前記証明データを送信する
請求項１に記載の工程管理方法。
前記第１の情報処理部は、前記製品の販売者と関連付けられる第３の情報処理部のアカウント宛てに、前記記憶装置に記憶された一連の工程に関する前記証明データを送信する
請求項１に記載の工程管理方法。
【請求項5】
前記第３の情報処理部は、受信した前記証明データを第２の記憶装置に記憶させ、
前記製品に変更がある場合、前記第３の情報処理部は、前記第２の記憶装置に記憶される一連の工程に関する前記証明データを、前記変更に関する工程の実行を管理した主体のアカウントと、前記変更に関する履歴情報とで更新する
請求項４に記載の工程管理方法。
前記製品に変更がある場合、前記第３の情報処理部は、前記第２の記憶装置に記憶される一連の工程に関する前記証明データを、前記変更に関する工程の実行を管理した主体のアカウントと、前記変更に関する履歴情報とで更新する
請求項４に記載の工程管理方法。
【請求項6】
前記製造が薬品の製造であって、製造された前記薬品が使用される場合、
前記薬品の使用を管理する第４の情報処理部が、前記第１の情報処理部で管理された前記薬品の製造に関する一連の証明データに、前記薬品の使用を実行した主体のアカウントと、前記使用に関する履歴情報と含む新たな証明データを生成し、第３の記憶装置に記憶させる
請求項４に記載の工程管理方法。
前記薬品の使用を管理する第４の情報処理部が、前記第１の情報処理部で管理された前記薬品の製造に関する一連の証明データに、前記薬品の使用を実行した主体のアカウントと、前記使用に関する履歴情報と含む新たな証明データを生成し、第３の記憶装置に記憶させる
請求項４に記載の工程管理方法。
【請求項7】
一連の工程で得られる薬品は所定回数の使用が可能であって、製造された前記薬品が使用される場合、
前記第４の情報処理部は、一連の工程で得られた前記薬品の使用毎に、新たな証明データを生成し、一連の工程に関する前記証明データに追加して前記第３の記憶装置に記憶させる
請求項６に記載の工程管理方法。
前記第４の情報処理部は、一連の工程で得られた前記薬品の使用毎に、新たな証明データを生成し、一連の工程に関する前記証明データに追加して前記第３の記憶装置に記憶させる
請求項６に記載の工程管理方法。
【請求項8】
前記第２の情報処理部は、前記工程で関連して排出された物質の排出量を含む証明データを生成する
請求項１に記載の工程管理方法。
請求項１に記載の工程管理方法。
【請求項9】
前記第２の情報処理部は、各工程と、当該工程に関連して排出される物質の排出量を関連付けるデータから、実行を管理した前記工程と関連付けられる排出量を抽出し、抽出した前記排出量を含む証明データを生成する
請求項８に記載の工程管理方法。
請求項８に記載の工程管理方法。
【請求項10】
前記証明データに含まれる情報の少なくとも一部が、所定のハッシュ関数を用いてハッシュ化されている
請求項１に記載の管理方法。
請求項１に記載の管理方法。
【請求項11】
第１の情報処理部と、複数の第２の情報処理部とを含み、前記各情報処理部と関連づけられる各ユーザの管理において異なる工程の完了が順に管理され、最終的に製品の製造を実行するシステムにおいて、前記各情報処理部における各工程を管理する工程管理システムであって、
前記各情報処理部は、
製造する前記製品の数量毎に管理する前記工程に関するアカウントを取得し、
前記第１の情報処理部は、
前記各情報処理部でそれぞれ管理する工程について、前記数量毎に各工程のツリー構造を生成し、
前記ツリー構造における複数の前記第２の情報処理部のうち最上位の前記第２の情報処理部の前記各アカウント宛てに製品の製造に関する依頼データを生成し、
前記各情報処理部によって生成された一連の工程に関する証明データを管理データとして記憶装置に記憶させ、
前記第２の情報処理部は、
自情報処理部宛ての前記依頼データで示される工程が前記ツリー構造における他の第２の情報処理部で管理する工程である場合、前記他の第２の情報処理部に宛てた前記依頼データを生成し、
自情報処理部宛ての前記依頼データで示される工程が自処理部で管理する工程である場合、前記工程の実行を管理し、
管理した前記工程の実行の完了を検出すると、工程の管理の主体として自情報処理部のアカウントを追加し、実行した前記工程の完了の履歴情報を追加して前記依頼データの生成元に宛てて前記依頼データを更新した証明データを生成する、
工程管理システム。
前記各情報処理部は、
製造する前記製品の数量毎に管理する前記工程に関するアカウントを取得し、
前記第１の情報処理部は、
前記各情報処理部でそれぞれ管理する工程について、前記数量毎に各工程のツリー構造を生成し、
前記ツリー構造における複数の前記第２の情報処理部のうち最上位の前記第２の情報処理部の前記各アカウント宛てに製品の製造に関する依頼データを生成し、
前記各情報処理部によって生成された一連の工程に関する証明データを管理データとして記憶装置に記憶させ、
前記第２の情報処理部は、
自情報処理部宛ての前記依頼データで示される工程が前記ツリー構造における他の第２の情報処理部で管理する工程である場合、前記他の第２の情報処理部に宛てた前記依頼データを生成し、
自情報処理部宛ての前記依頼データで示される工程が自処理部で管理する工程である場合、前記工程の実行を管理し、
管理した前記工程の実行の完了を検出すると、工程の管理の主体として自情報処理部のアカウントを追加し、実行した前記工程の完了の履歴情報を追加して前記依頼データの生成元に宛てて前記依頼データを更新した証明データを生成する、
工程管理システム。
【請求項12】
工程管理システムに、請求項１乃至３のいずれか１に記載の工程管理方法を実行させるコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、製品のライフサイクル全般における製品、部品、作業、責任のトレーサビリティに係る工程管理方法、工程管理システム、及び、コンピュータプログラムに関する。
【背景技術】
【0002】
ブロックチェーンは、元来、電子情報の改ざん等を防止する強固なセキュリティを備えた、金融取引をコンピュータで処理させる技術である。ブロックチェーンはセキュリティが強固であるため、近年、金融取引以外にも、種々の行為を記録し、必要な時にその行為を証明するクレデンシャルとして利用する例もある（例えば、特許文献１及び２参照）。
【0003】
例えば、特許文献１では、対象の移動をブロックチェーンに記録することができるが、対象の仕入れや加工等については記録されず、部品レベルでトレースすることはできない。また、特許文献２においても、各工程において、２次請け、３次請け等の下層に工程を依頼することは想定されず、製品の製造全体での各工程に関してトレースすることはできない。
【先行技術文献】
【特許文献】
【0004】
【特許文献1】米国特許第９６４１３４２号公報
【特許文献2】米国特許出願公開第２０１９／１５８２７０号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
上記に鑑み、本発明は、製品のライフサイクル全般における利用しやすい製品、部品、作業、責任のトレーサビリティに係る工程管理方法、工程管理システム、及び、コンピュータプログラムを提供する。
【課題を解決するための手段】
【0006】
本開示に係る工程管理方法は、第１の情報処理部から、複数の第２の情報処理部のうち少なくとも１に宛てた工程の実行を依頼する依頼データが生成され、各情報処理部は、各工程を実行するユーザと関連付けられ、各ユーザによる操作にしたがって前記各情報処理部においてそれぞれ異なる工程の完了が順に証明され、最終的に製品の製造を管理するシステムにおいて、前記各情報処理部における各工程を管理する工程管理方法であって、前記第１の情報処理部が、前記各情報処理部でそれぞれ管理する工程について、製造する前記製品の数量毎に各工程のツリー構造を生成し、前記各情報処理部が、前記数量毎に管理する前記工程に関するアカウントを取得し、前記第１の情報処理部が、前記ツリー構造における複数の前記第２の情報処理部のうち最上位の前記第２の情報処理部の前記各アカウント宛てに製品の製造に関する前記依頼データを生成し、前記第２の情報処理部は、自処理部宛ての前記依頼データで示される工程が前記ツリー構造における他の第２の情報処理部で管理する工程である場合、前記他の第２の情報処理部に宛てた前記依頼データを生成し、前記第２の情報処理部は、自処理部宛ての前記依頼データで示される工程が自処理部で管理する工程である場合、前記工程の実行を管理し、前記第２の情報処理部が、管理した前記工程の実行の完了を検出すると、工程の管理の主体として当該第２の情報処理部のアカウントを追加し、実行した前記工程の完了の履歴情報を追加して前記依頼データの生成元に宛てて前記依頼データを更新した証明データを生成し、前記第１の情報処理部が、前記各情報処理部によって各工程の実行後に送信された一連の工程に関する証明データを管理データとして記憶装置に記憶させる。
【0007】
本開示に係る工程管理システムは、第１の情報処理部と、複数の第２の情報処理部とを含み、前記各情報処理部と関連づけられる各ユーザの管理において異なる工程の完了が順に管理され、最終的に製品の製造を実行するシステムにおいて、前記各情報処理部における各工程を管理する工程管理システムであって、前記各情報処理部は、製造する前記製品の数量毎に管理する前記工程に関するアカウントを取得し、前記第１の情報処理部は、前記各情報処理部でそれぞれ管理する工程について、前記数量毎に各工程のツリー構造を生成し、前記ツリー構造における複数の前記第２の情報処理部のうち最上位の前記第２の情報処理部の前記各アカウント宛てに製品の製造に関する前記依頼データを生成し、前記各情報処理部によって生成された一連の工程に関する証明データを管理データとして記憶装置に記憶させ、前記第２の情報処理部は、自情報処理部宛ての前記依頼データで示される工程が前記ツリー構造における他の第２の情報処理部で管理する工程である場合、前記他の第２の情報処理部に宛てた前記依頼データを生成し、自情報処理部宛ての前記依頼データで示される工程が自処理部で管理する工程である場合、前記工程の実行を管理し、管理した前記工程の実行の完了を検出すると、工程の管理の主体として自情報処理部のアカウントを追加し、実行した前記工程の完了の履歴情報を追加して前記依頼データの生成元に宛てて前記依頼データを更新した証明データを生成する。
【発明の効果】
【0008】
本開示の工程管理方法、工程管理システム、及び、コンピュータプログラムは、製品のライフサイクルにおける製品、部品、作業、責任のトレーサビリティを利用しやすくすることができる。
【図面の簡単な説明】
【0009】
【図1】工程管理システムの構成を示す概略図である。
【図2】工程管理システムにおける製品の製造の依頼データの流れを示す概略図である。
【図3】工程管理システムにおける製品の製造の工程の証明データの流れを示す概略図である。
【図4】工程管理システムにおけるデータのループバックを示す概略図である。
【図5A】工程管理システムで送信される依頼データの構成図である。
【図5B】工程管理システムで送信される証明データの構成図である。
【図6A】工程管理システムの端末の構成を示すブロック図である。
【図6B】工程管理システムのブロックチェーンシステムの構成を示すブロック図である。
【図6C】工程管理システムの依頼記録装置の構成を示すブロック図である。
【図7】依頼元の情報処理部における依頼データの生成の処理を示すフローチャートである。
【図8】工程管理システムで利用されるＢＯＭデータの構成図である。
【図9】工程管理システムで生成される製品の製造の全工程に関わる主体のツリー構造である。
【図10】依頼元の情報処理部による依頼先の情報処理部への依頼データの生成の一例を示す概略図である。
【図11】依頼先の情報処理部における依頼データの生成の処理を示すフローチャートである。
【図12】上位の依頼元の情報処理部による下位の依頼先の情報処理部への依頼データの生成の一例を示す概略図である。
【図13】上位の依頼元の情報処理部による下位の依頼先の情報処理部への依頼データの生成の他の例を示す概略図である。
【図14】依頼先の情報処理部における証明データの生成の処理を示すフローチャートである。
【図15】下位の情報処理部から上位の情報処理部への証明データの生成の一例を示す概略図である。
【図16】依頼元の情報処理部における管理データの生成の処理を示すフローチャートである。
【図17】管理データの一例を示す概略図である。
【図18】情報のブラックボックス化の一例を示す概略図である。
【図19】航空機の構成の一例を示す概略図である。
【図20A】航空機の補助翼の交換前の管理データの一例を示す概略図である。
【図20B】航空機の補助翼が交換された管理データの一例を示す概略図である。
【図21A】航空機のスポイラの交換前の管理データの一例を示す概略図である。
【図21B】航空機のスポイラが交換された管理データの一例を示す概略図である。
【図22】補修部品及び補修作業を管理する管理データの一例を示す概略図である。
【図23A】薬品の製造において生成される依頼データの一例を示す概略図である。
【図23B】薬品の製造において生成される証明データの一例を示す概略図である。
【図24A】実施例５の工程管理システムで利用されるＢＯＭデータの構成図である。
【図25】実施例５の工程管理システムで送信される証明データの構成図である。
【図26】実施例５の工程管理システムにおけるデータのループバックを示す概略図である。
【発明を実施するための形態】
【0010】
以下に、図面を参照して本開示に係る工程管理方法、工程管理システム、及び、コンピュータプログラムについて説明する。本開示に係る工程管理方法、工程管理システム、及び、コンピュータプログラムは、製品の製造及び流通の一連の工程を管理するために用いられる。
【0011】
本開示に係る工程管理方法、工程管理システム、及び、コンピュータプログラムは、そのような製品の製造に関する複数の連続する工程を記録し、それらの工程に関するトレーサビリティを実現することができる。具体的には、本開示の工程管理方法、工程管理システム、及び、コンピュータプログラムは、製品の部品、製品の加工の作業工程の親子関係、作業工程の責任者のツリー構造を生成し、このツリー構造を保持するデータを記録することで、部品及び製品の移動や、製造後の部品等の変更をトレースすることができる。なお、以下の説明では、同一の構成について、同一の符号を付して説明を省略する。
【0012】
以下では、「工程」は、製品の製造を行う際に実行される各段階を意味する。例えば、製品の製造を行う際の部品の調達、一の部品の加工、複数の部品の加工である。また、部品の一の加工場所から次の加工場所への移動や、最終製品の納品の移動等も工程としてもよい。
【0013】
「責任者」は、各工程の実行が委託された主体を意味する。例えば、ある部品Ａの加工作業者は、部品Ａの加工に関する責任者となる。また、部品Ａを、工場Ｂから工場Ｃへ運ぶ運送業者は、その輸送に関する責任者となる。「最終責任者」は、目的となる製品全体の責任者である。
【0014】
「証明」は、責任者が責任の所在を記録する行為及び記録したデータを意味する。
【0015】
〈工程管理システム〉
図１を用いて、実施形態に係る工程管理システム１について説明する。工程管理システム１は、最終責任者となる製品の製造を依頼した依頼元であるユーザに利用される端末１０と、依頼元によって工程の実行の依頼を受ける複数の依頼先であるユーザに利用される端末２０Ａ乃至２０Ｆとがネットワーク３０を介して接続される。なお、以下の説明において、複数の端末２０Ａ～２０Ｆのうち、いずれであるかを特定しない場合、単に端末２０として説明する。
図１を用いて、実施形態に係る工程管理システム１について説明する。工程管理システム１は、最終責任者となる製品の製造を依頼した依頼元であるユーザに利用される端末１０と、依頼元によって工程の実行の依頼を受ける複数の依頼先であるユーザに利用される端末２０Ａ乃至２０Ｆとがネットワーク３０を介して接続される。なお、以下の説明において、複数の端末２０Ａ～２０Ｆのうち、いずれであるかを特定しない場合、単に端末２０として説明する。
【0016】
また、工程管理システム１に含まれる各端末１０，２０は、例えば、ネットワーク３０を介してブロックチェーンシステム４０と接続される。各端末１０，２０は、ブロックチェーンシステム４０が備えるアプリケーションを利用して、Ethereum、Hyper Ledger等の一般的なブロックチェーンを利用することができる。
【0017】
さらに、工程管理システム１では、依頼元であるユーザからの工程の依頼の履歴を記録する依頼記録装置５０がネットワーク３０を介して各端末１０，２０及びブロックチェーンシステム４０と接続される。
【0018】
以下の説明において、依頼元は、各依頼先にハンドバッグの製造に関する一工程を依頼する例で説明する。ここでは、ハンドバッグは、ハンドルとバッグ本体とで構成されるとする。また、ハンドルは、ハンドル本体及び留め金具で構成され、バッグ本体は、第１側面皮革、第２側面皮革、正面皮革及び背面皮革で構成されるとする。以下の説明において、端末１０は、最終的な製品であるハンドバッグに関する最終責任者であるユーザが利用する端末である。端末２０Ａは、ハンドルに関する責任者であるユーザが利用する端末である。端末２０Ｂは、バッグ本体に関する責任者が利用する端末である。端末２０Ｃは、ハンドル本体に関する責任者であるユーザが利用する端末である。端末２０Ｄは、ハンドルの留め具に関する責任者であるユーザが利用する端末である。端末２０Ｅは、バッグ本体の第１及び第２の側面の皮革の責任者であるユーザが利用する端末である。端末２０Ｆは、バッグ本体の正面及び背面側面の皮革の責任者であるユーザが利用する端末である。
【0019】
図２に示す工程管理システム１では、各ユーザは、自身の利用可能な端末１０，２０を操作して自身の担当する工程の実行を記録する。ここで、各工程に関するデータは、工程管理システム１において各ユーザに割り当てられた「領域」を利用して、必要なアカウントの取得やデータの生成等を実行し、自身の担当する工程の実行を記録する。ここでは、各ユーザの端末１０，２０を介した操作によってアクセスされ、利用されるブロックチェーンシステム４０の領域を「情報処理部」として説明する。
【0020】
依頼元が上位であり、依頼先が下位であるため、図２に示す例では、情報処理部４００を利用する依頼元であるユーザが最上位であり、情報処理部４０１～４０６を利用する依頼先のユーザが下位である。また、情報処理部４０１を利用するユーザの下位がその依頼先の情報処理部４０３及び４０４のユーザであって、情報処理部４０２のユーザの下位がその依頼先の情報処理部４０５及び４０６のユーザである。
【0021】
ここでは、図２に示すように、上位のユーザが利用する依頼元の情報処理部４００から下位のユーザが利用する依頼先の情報処理部４０１乃至４０６に宛てて順に、工程の実施に関する依頼データが生成される。また、各責任者で各工程が完了すると、依頼された工程により得られた成果物である部品又は製品が上位のユーザに受け渡しされる。このとき、成果物の受け渡しとともに、図３に示すように、各工程の責任者の利用する依頼先の情報処理部４０１乃至４０６において下位から上位に宛てて順に工程の完了を証明する証明データが生成される。
【0022】
したがって、工程管理システム１においては、図４に示すように、最上位のユーザである依頼元の情報処理部４００は、下位のユーザである依頼先の情報処理部４０１に宛てた工程の依頼データＴ２と、依頼先の情報処理部４０２に宛てた依頼データＴ３を生成する。各依頼先の情報処理部４０１，４０２もそれぞれ下位のユーザである依頼先の情報処理部４０３～４０６宛てに依頼データＴ４～Ｔ７を生成する。また、各工程が完了すると、ユーザによる端末２０の操作に応じて、下位のユーザである依頼先の情報処理部４０６～４０３は、上位のユーザである依頼先の情報処理部４０１，４０２に宛てて依頼データＴ７～Ｔ４を更新して工程の証明データＴ７’～Ｔ４’を生成する。各依頼先の情報処理部４０１，４０２も、対象の工程が完了すると、ユーザによる端末２０の操作に応じて、最上位である依頼元の情報処理部４００宛てに、依頼データＴ２，Ｔ３を更新して工程の証明データＴ２’，Ｔ３’を生成する。これらの依頼データＴ２～Ｔ７は、一般的に作業工程等の依頼に利用される「発注書」としての役割を持つデータである。また、証明データＴ７’～Ｔ２’は、一般的に製品とともに納品される「納品書」としての役割を持つデータである。このように工程管理システム１の各情報処理部４００～４０６では、上位から下位に宛てて工程の依頼データＴ２～Ｔ７が生成され、これらが更新された工程の証明データＴ２’～Ｔ７’が、下位から上位に宛てて生成される。
【0023】
工程管理システム１では、「依頼データ」を「発注書」として考えたとき、発注書には納品された際に納品者がサインする欄（以下、「オプショナルフィールド」という。）が設けられている。納品がまだ行われていない時点（例えば、発注時）には、オプショナルフィールドは白紙の状態である。オプショナルフィールドが白紙の状態の「用紙」である発注書を最上位から各層でサインして分割して各最下層まで渡し、最下層から各層でオプショナルフィールドが記入された「納品書」となって最上位まで戻る、発注書と納品書を１枚の「用紙」で済ませる使い方と考えることができる。このように１枚の用紙に相当するデータが最上位から順に最下位に宛てて生成され、再び最上位に戻る一連の発注から納品の連鎖を、ここで「ループバック」として説明する。
【0024】
工程管理システム１において送受信されるデータは、ブロックチェーンのトランザクションで使用するトランザクションデータと同様の形式のデータである。例えば、図５Ａに一例を示すように、工程を依頼する依頼データは、ブロックチェーンシステム４０によってトランザクション毎に一意に付与された「トランザクションＩＤ」、ブロックチェーンシステム４０によって付与された依頼データ送信時のタイミングを記録する「タイムスタンプ」、送信先を示す「受信者名」、送信元を示す「送信者名」、及び、依頼の数を示す「数量」の各欄を含む。
【0025】
「受信者名」には、ブロックチェーンシステム４０と、ユーザとの契約に基づき、当該ユーザのリクエストによって当該主体が利用する情報処理部の領域にブロックチェーンシステム４０を利用して生成されたブロックチェーンのアカウントのアドレスが用いられる。「送信者名」には、ブロックチェーンシステム４０と、ユーザとの契約に基づき、当該主体のリクエストによって当該ユーザが利用する情報処理部の領域にブロックチェーンシステム４０を利用して生成されたブロックチェーンのアカウントがもつ秘密鍵を用いて生成される電子署名が用いられる。
【0026】
「送信者名」と関連付けられるユーザは、「受信者名」と関連付けられるユーザに工程の実行を依頼した依頼者であることを意味し、「受信者名」で識別されるユーザに工程の実行を委託した委託者であることを意味する。したがって、この場合、依頼データは、発注書、及び／又は、委託契約書としての役割も併せ持つ。
【0027】
「数量」には、例えば、ロット番号の数が用いられる。
【0028】
また、依頼データは、Ethereum、Hyper Ledger等のブロックチェーンで使用されるデータであって、図５Ａに示すように、依頼元端末１０からの送信時には空欄である「オプショナルフィールド」を含む。このオプショナルフィールドは、情報の書き込みが１回のみ許される領域であり、情報が１回書き込みされるとそれ以降は、書き換えが不可となっている。したがって、オプショナルフィールドは、依頼先での工程が完了したタイミングで、その工程の内容を記述することで、工程の証明として記録される。
【0029】
図５Ｂに工程を証明する証明データの一例を示す。図５Ｂに示すように、証明データは、図５Ａに示す依頼データと比較して、オプショナルフィールドの領域に「工程の完了の履歴情報」が書き込みされた点で異なる。「工程の完了の履歴情報」は、完了した工程で製造された製品又は部品の品目を識別する「品目コード」、製造された製品又は部品の識別情報である「シリアル番号」等の情報である。上述したように、オプショナルフィールドは書き込みが１回に制限された領域であるため、一度書き込みされた情報が改ざんされることはない。したがって、工程管理システム１においては、証明データの「送信者名」で識別される端末１０，２０のユーザが、オプショナルフィールドに書き込みされた履歴情報の工程を実行した主体である、すなわち、工程の責任者であるとの証明に利用する。なお、オプショナルフィールドに記録される情報は、依頼元からの依頼によって異なり、工程の内容を特定する情報が含まれていればよい。例えば、「シリアル番号」に代えて、製造のロットを識別する「ロット番号」を含んでもよい。なお、製品複数を含む箱単位でロット番号が付与され、製品の個々にロット番号が付与されない製品の場合、その箱単位で付与されるロット番号を利用してもよい。また、「品目コード」及び「シリアル番号」の組み合わせに代えて、加工作業を特定する「加工作業ID」及び作業固有の識別情報である「作業シリアル」の組み合わせであってもよい。
【0030】
〈第１端末〉
図６Ａを用いて、実施形態に係る端末１０について説明する。ここでは、依頼元となるユーザに利用される端末１０を第１端末とする。例えば、端末１０は、図６Ａに示すように、演算装置１１、記憶装置１２、入力装置１３、出力装置１４及び通信装置１５を備えるパーソナルコンピュータ（ＰＣ）等の情報処理装置によって実現される。端末１０は、依頼元であるユーザに利用される端末であって、依頼元のユーザと関連付けられる。端末１０は、同時に依頼元の情報処理部４００と関連付けられるとともに、依頼元の情報処理部４００のアカウントとも関連付けられる。なお、後述するように、依頼元は、複数のアカウントと関連付けられることがあり得るため、端末１０も複数のアカウントと関連付けられることがある。
図６Ａを用いて、実施形態に係る端末１０について説明する。ここでは、依頼元となるユーザに利用される端末１０を第１端末とする。例えば、端末１０は、図６Ａに示すように、演算装置１１、記憶装置１２、入力装置１３、出力装置１４及び通信装置１５を備えるパーソナルコンピュータ（ＰＣ）等の情報処理装置によって実現される。端末１０は、依頼元であるユーザに利用される端末であって、依頼元のユーザと関連付けられる。端末１０は、同時に依頼元の情報処理部４００と関連付けられるとともに、依頼元の情報処理部４００のアカウントとも関連付けられる。なお、後述するように、依頼元は、複数のアカウントと関連付けられることがあり得るため、端末１０も複数のアカウントと関連付けられることがある。
【0031】
演算装置１１は、端末１０全体の制御を司るコントローラである。演算装置１１は、記憶装置１２に記憶されるコンピュータプログラムを実行することにより各種の処理を実行する。また、演算装置１１は、所定の機能を実現する専用に設計されたハードウェア回路でもよい。例えば、演算装置１１は、ＣＰＵ、ＭＰＵ、ＧＰＵ、ＦＰＧＡ、ＤＳＰ、ＡＳＩＣ等、種々のプロセッサであってもよい。
【0032】
記憶装置１２は、種々の情報を記録する記憶媒体である。記憶装置１２は、例えば、ＲＡＭ、ＲＯＭ、フラッシュメモリ、ＳＳＤ（Solid State Drive）、ハードディスクドライブ、その他の記憶デバイス又はそれらを適宜組み合わせて実現される。記憶装置１２は、工程管理の処理で用いられるデータ及び工程管理の処理で得られたデータ等が格納されうる。
【0033】
入力装置１３は、ユーザに操作され、製造依頼のリクエストやデータの入力に利用される操作ボタン、キーボード、マウス、タッチパネル、マイクロフォン等の入力手段である。また、出力装置１４は、処理結果やデータの出力に利用されるディスプレイ、スピーカ等の出力手段である。
【0034】
通信装置１５は、外部の装置（例えば、データ群を記憶する記憶媒体）とのデータ通信を可能とするための通信手段である。通信装置１５は、入力装置１３を利用する操作にしたがって、作業工程を依頼するため操作信号をブロックチェーンシステム４０に送信することができる。データ通信は、無線及び／又は有線による公知の通信規格にしたがって行われ得る。例えば、有線によるデータ通信は、イーサネット（登録商標）規格、及び／又はＵＳＢ（登録商標）規格等に準拠して動作する半導体集積回路の通信コントローラを通信装置１５として用いることによって行われる。また無線によるデータ通信は、ＬＡＮ（Local Area Network）に関するＩＥＥＥ８０２．１１規格、及び／又は移動体通信に関する、いわゆる４Ｇ／５Ｇと呼ばれる、第４世代／第５世代移動通信システム等に準拠して動作する半導体集積回路の通信コントローラを通信装置１５として用いることによって行われる。
【0035】
〈第２端末〉
また、実施形態に係る工程管理システム１において依頼先のユーザに利用される端末２０（２０Ａ～２０Ｆ）について説明する。ここでは、依頼先となるユーザに利用される端末２０を第２端末とする。端末２０の構成は、上述した端末１０の構成と同一であるため、再び図６Ａを参照して説明する。例えば、端末２０は、図６Ａに示すように、演算装置１１、記憶装置１２、入力装置１３、出力装置１４及び通信装置１５を備えるＰＣ等の情報処理装置によって実現される。端末２０Ａ～２０Ｆは、依頼先であるユーザに利用される端末であって、それぞれ依頼先のユーザと関連付けられる。また、端末２０Ａ～２０Ｆは、それぞれ依頼先の情報処理部４０１～４０６と関連付けられるとともに、依頼先の情報処理部４０１～４０６のアカウントとも関連付けられる。なお、後述するように、依頼先の情報処理部４０１～４０６は、複数のアカウントと関連付けられることがあり得るため、端末２０Ａ～２０Ｆも複数のアカウントと関連付けられることがある。
また、実施形態に係る工程管理システム１において依頼先のユーザに利用される端末２０（２０Ａ～２０Ｆ）について説明する。ここでは、依頼先となるユーザに利用される端末２０を第２端末とする。端末２０の構成は、上述した端末１０の構成と同一であるため、再び図６Ａを参照して説明する。例えば、端末２０は、図６Ａに示すように、演算装置１１、記憶装置１２、入力装置１３、出力装置１４及び通信装置１５を備えるＰＣ等の情報処理装置によって実現される。端末２０Ａ～２０Ｆは、依頼先であるユーザに利用される端末であって、それぞれ依頼先のユーザと関連付けられる。また、端末２０Ａ～２０Ｆは、それぞれ依頼先の情報処理部４０１～４０６と関連付けられるとともに、依頼先の情報処理部４０１～４０６のアカウントとも関連付けられる。なお、後述するように、依頼先の情報処理部４０１～４０６は、複数のアカウントと関連付けられることがあり得るため、端末２０Ａ～２０Ｆも複数のアカウントと関連付けられることがある。
【0036】
端末２０では、入力装置１３がユーザに操作されることにより、通信装置１５によって、作業工程を終了した通知信号をブロックチェーンシステム４０に送信することができる。
【0037】
〈ブロックチェーンシステム〉
図６Ｂを用いて、実施形態に係るブロックチェーンシステム４０について説明する。ブロックチェーンシステム４０は、ユーザが利用する各端末１０，２０からの操作信号にしたがって、アカウントの生成、各種データの生成、各種データの更新等の処理を実行する。例えば、ブロックチェーンシステム４０は、図６Ｂに示すように、演算装置４１、記憶装置４２、入力装置４３、出力装置４４及び通信装置４５を備えるサーバ装置等の情報処理装置によって実現される。なお、演算装置４１、記憶装置４２、入力装置４３、出力装置４４及び通信装置４５は、図６Ａを用いて上述した演算装置１１、記憶装置１２、入力装置１３、出力装置１４及び通信装置１５と同等の構成であってもよい。図６Ｂでは、ブロックチェーンシステム４０は、１台の情報処理装置で構成される例を図示するが、これに限定されず、複数の情報処理装置により構成されてもよい。また例えば、入力装置４３及び出力装置４４が必要ない場合、ブロックチェーンシステム４０は、入力装置４３及び出力装置４４を備える必要はない。ブロックチェーンシステム４０では、全ての構成は必須ではない。上述した各情報処理部４００～４０６は、例えば、当該ブロックチェーンシステム４０によって実現される。例えば、各情報処理部４００～４０６は、同一の情報処理装置で実現されてもよいし、別々の情報処理装置によって実現されてもよい。
図６Ｂを用いて、実施形態に係るブロックチェーンシステム４０について説明する。ブロックチェーンシステム４０は、ユーザが利用する各端末１０，２０からの操作信号にしたがって、アカウントの生成、各種データの生成、各種データの更新等の処理を実行する。例えば、ブロックチェーンシステム４０は、図６Ｂに示すように、演算装置４１、記憶装置４２、入力装置４３、出力装置４４及び通信装置４５を備えるサーバ装置等の情報処理装置によって実現される。なお、演算装置４１、記憶装置４２、入力装置４３、出力装置４４及び通信装置４５は、図６Ａを用いて上述した演算装置１１、記憶装置１２、入力装置１３、出力装置１４及び通信装置１５と同等の構成であってもよい。図６Ｂでは、ブロックチェーンシステム４０は、１台の情報処理装置で構成される例を図示するが、これに限定されず、複数の情報処理装置により構成されてもよい。また例えば、入力装置４３及び出力装置４４が必要ない場合、ブロックチェーンシステム４０は、入力装置４３及び出力装置４４を備える必要はない。ブロックチェーンシステム４０では、全ての構成は必須ではない。上述した各情報処理部４００～４０６は、例えば、当該ブロックチェーンシステム４０によって実現される。例えば、各情報処理部４００～４０６は、同一の情報処理装置で実現されてもよいし、別々の情報処理装置によって実現されてもよい。
【0038】
ブロックチェーンシステム４０の記憶装置４２は、例えば、ＢＯＭ（Bill of Material）データ４２１、アカウントデータ４２２、階層データ４２３及び管理データ４２４を記憶する。また、記憶装置４２は、ブロックチェーンシステム４０に関連するブロックチェーンプログラムＰを記憶する。ブロックチェーンプログラムＰは、例えば、アカウント生成処理、階層データ生成処理、トランザクションデータ生成処理等の実行に利用されるコンピュータプログラムである。ブロックチェーンプログラムＰは、これらの各処理を実行する複数のコンピュータプログラムを含んでもよいし、一部の処理は、外部のコンピュータプログラムによって実行されてもよい。
【0039】
ＢＯＭデータは、図８に一例を示すように、目的の製品の製造に使用する部品表（ＢＯＭ）を示すデータである。図６Ｂでは、ブロックチェーンシステム４０の記憶装置４２にＢＯＭデータ４２１が記憶される一例を示すが、ブロックチェーンシステム４０は、他の記憶装置に記憶されるＢＯＭデータ４２１を読み出して使用してもよい。
【0040】
アカウントデータ４２２は、各端末１０，２０からのリクエストに従って各端末１０，２０と関連付けられる情報処理部４００～４０６に対して生成されたアカウントを含むデータである。具体的には、アカウントは、演算装置４１によって情報処理部４００～４０６の工程毎に生成される。したがって、各アカウントは、各工程と関連付けて生成された「秘密鍵」、「公開鍵」、「公開鍵から生成されたアドレス」とを含む。このとき、演算装置４１は、同一の主体であっても、製品のロット番号毎に、異なる工程として扱うため、１の情報処理部と関連付けられる複数の異なるアカウントを生成しうる。
【0041】
階層データ４２３は、製造に必要な工程の親子関係のツリー構造を示すデータである。この階層データ４２３は、例えば、依頼元の情報処理部４００として機能する演算装置４１により生成される。アカウントデータ４２２と同様に、階層データ４２３においても、製造する製品のロット番号毎に情報をツリー構造として扱うことができる。
【0042】
管理データ４２４は、トランザクションデータ生成処理によって後述するように得られた一連の工程に関する依頼データ及び証明データを含むデータである。
【0043】
演算装置４１は、アカウント生成処理において、各端末１０，２０からアカウントの生成を要求するリクエスト信号を受信すると、受信したリクエスト信号に応じたアカウントを生成し、アカウントデータ４２２に登録する。アカウントは、製品のロット番号毎に生成されるため、演算装置４１は、各端末１０，２０から製品のロット番号毎の複数のアカウントの生成を依頼されうる。この場合、演算装置４１は、各端末１０，２０に対し、複数のアカウントを生成する。
【0044】
演算装置４１は、階層データ生成処理において、ＢＯＭデータ４２１を参照して、階層データ４２３を生成する。例えば、演算装置４１は、端末１０からリクエスト信号を受信したタイミングで、階層データ４２３を生成する。
【0045】
演算装置４１は、トランザクションデータ生成処理において、各端末１０，２０から受信したリクエストにしたがって、トランザクションデータを生成する。具体的には、依頼元のユーザが利用する端末１０から受信したリクエストにしたがって、演算装置４１が依頼元情報処理部４００として機能する場合、依頼データであるトランザクションデータを生成する。また例えば、依頼先のユーザが利用する端末２０から受信したリクエストにしたがって、演算装置４１が依頼先の情報処理部４０１～４０６として機能する場合、依頼データ又は証明データであるトランザクションデータを生成する。
【0046】
〈依頼記録装置〉
図６Ｃを用いて、実施形態に係る依頼記録装置５０について説明する。依頼記録装置５０は、依頼元の情報処理部４００で発生した依頼データと関連付けて、依頼の履歴情報を記録する。例えば、依頼記録装置５０は、図６Ｃに示すように、演算装置５１、記憶装置５２、入力装置５３、出力装置５４及び通信装置５５を備えるサーバ装置等の情報処理装置によって実現される。なお、演算装置５１、記憶装置５２、入力装置５３、出力装置５４及び通信装置５５は、図６Ａを用いて上述した演算装置１１、記憶装置１２、入力装置１３、出力装置１４及び通信装置１５と同様の構成であってもよい。図６Ｃでは、依頼記録装置５０は、１台の情報処理装置で構成される例を図示するが、これに限定されず、複数の情報処理装置により構成されてもよい。また、依頼記録装置５０は、入力装置５３及び出力装置５４が必要ない場合、備える必要はなく、全ての構成を必須とするものではない。
図６Ｃを用いて、実施形態に係る依頼記録装置５０について説明する。依頼記録装置５０は、依頼元の情報処理部４００で発生した依頼データと関連付けて、依頼の履歴情報を記録する。例えば、依頼記録装置５０は、図６Ｃに示すように、演算装置５１、記憶装置５２、入力装置５３、出力装置５４及び通信装置５５を備えるサーバ装置等の情報処理装置によって実現される。なお、演算装置５１、記憶装置５２、入力装置５３、出力装置５４及び通信装置５５は、図６Ａを用いて上述した演算装置１１、記憶装置１２、入力装置１３、出力装置１４及び通信装置１５と同様の構成であってもよい。図６Ｃでは、依頼記録装置５０は、１台の情報処理装置で構成される例を図示するが、これに限定されず、複数の情報処理装置により構成されてもよい。また、依頼記録装置５０は、入力装置５３及び出力装置５４が必要ない場合、備える必要はなく、全ての構成を必須とするものではない。
【0047】
依頼履歴データ５２１は、最上位のユーザである依頼元からの依頼の内容を含むデータである。例えば、依頼履歴データ５２１は、依頼元の識別情報、依頼日、目的物及び個数等の依頼内容を含み、管理データ４２４に記憶される最上位の依頼の識別情報と関連付けられる。この依頼履歴データ５２１は、例えば、依頼元の端末１０からの操作にしたがって、依頼元の情報処理部４００において依頼データが生成されるタイミングで、同時に記憶される。
【0048】
〈依頼元の情報処理部における依頼の処理〉
図７に示すフローチャートを用いて、ブロックチェーンシステム４０が依頼元の情報処理部４００として機能する際に依頼先の情報処理部に製品の製造を依頼する処理の流れを説明する。
図７に示すフローチャートを用いて、ブロックチェーンシステム４０が依頼元の情報処理部４００として機能する際に依頼先の情報処理部に製品の製造を依頼する処理の流れを説明する。
【0049】
まず、演算装置４１は、アカウント生成処理において、自処理部４００のアカウントを取得する（Ｓ０１）。ここで、演算装置４１は、生成されたアカウントをアカウントデータ４２２として記憶装置４２に記憶させる。
【0050】
続いて、演算装置４１は、階層データ生成処理において、ＢＯＭデータ４２１を解析する（Ｓ０２）。また、演算装置４１は、階層データ生成処理において、ステップＳ０２の解析結果を用いて、製品の製造の工程及び主体のツリー構造を表す階層データ４２３を生成し、記憶装置４２に記憶させる（Ｓ０３）。このとき、演算装置４１は、工程の各主体と関連付けるアカウントの取得をリクエストし、アカウントが生成されたことを確認する。具体的には、演算装置４１は、各主体と関連付けられる情報処理部に各工程と対応するアカウントの取得のリクエスト信号を生成する。このリクエスト信号に応じて、図１１に示すフローチャートを用いて後述するように、依頼先の情報処理部４０１～４０６として機能する演算装置４１は、各工程と対応させたアカウントを生成する。演算装置４１は、各リクエスト信号に応じてアカウントが生成されたか否かを判定する。仮に、アカウントが生成されていないとき、演算装置４１は、再度、リクエスト信号を送信する。
【0051】
このとき、演算装置４１は、製造工程に関わる主体に、製造が依頼された製品の数量、すなわち、ロット数の枝番を付すことで、製品の数量のアカウントを生成することができる。ロット数が「３」である場合、図９に示すように、３つのアカウントが生成される。図９に示す例では、例えば、「最終責任者」に付与されたアカウントは、“１－１”～“１－３”、であり、「ハンドル責任者」に付与されたアカウントは、“２－１”～“２－３”である。なお、以下の説明について、これらのアカウント“１－１”～“１－３”等を、アドレスとして使用することもあり得る。
【0052】
また、演算装置４１は、製品製造の依頼である最初の依頼データＴ１１～Ｔ１３を生成する（Ｓ０４）。具体的には、図１０に示すように、演算装置４１は、ステップＳ０２で生成した製品の数量の自処理部４００の各アカウント“１－１”～“１－３”宛の依頼データＴ１１～Ｔ１３を生成し、記憶装置１２に記憶させる。
【0053】
さらに、演算装置４１は、自処理部４００の各アカウントから、次の階層の依頼先の主体のアカウントのそれぞれに対して、秘密鍵で暗号化して電子署名を付与し、製品の製造の依頼データを生成する（Ｓ０５）。図１０に示す例では、演算装置４１は、アカウント“２－１”～“２－３”の依頼データＴ２１～Ｔ２３を次の階層である依頼先の情報処理部４０１宛てに生成し、アカウント“３－１”～“３－３”の依頼データＴ３１～Ｔ３３を依頼先の情報処理部４０２宛てに生成する。このとき、演算装置４１は、ブロックチェーンの分割機能を用いて、依頼データＴ１１～Ｔ１３を依頼データＴ２１～Ｔ２３，Ｔ３１～Ｔ３３に分割し、電子署名を付与して複数の依頼先の情報処理部４０１，４０２宛てに依頼データを生成する。
【0054】
〈依頼先の情報処理部における依頼の処理〉
図１１に示すフローチャートを用いて、ブロックチェーンシステム４０が依頼先の情報処理部として機能する際に、下位の依頼先の情報処理部へ工程を依頼する処理の流れを説明する。
図１１に示すフローチャートを用いて、ブロックチェーンシステム４０が依頼先の情報処理部として機能する際に、下位の依頼先の情報処理部へ工程を依頼する処理の流れを説明する。
【0055】
まず、演算装置４１は、依頼元の情報処理部４００にアカウントの取得がリクエストされたタイミングで、自処理部のアカウントを取得する（Ｓ１１）。ここで、演算装置４１は、生成されたアカウントを記憶装置４２に記憶されるアカウントデータ４２２に追加する。ここでも、依頼元のアカウントの場合と同様に、製品の数量のアカウントが生成される。
【0056】
上位の情報処理部で生成された自処理部宛ての依頼データを取得すると（Ｓ１２）、演算装置４１は、自処理部で実行を管理する作業がある場合（Ｓ１３でＹＥＳ）、自処理部宛の依頼データを生成する（Ｓ１４）。自処理部で実行を管理する作業とは、例えば、単に納入された部品を検品するだけでなく、納入された複数の部品を組み合わせる加工等の作業である。例えば、この場合も、依頼先の情報処理部は、秘密鍵で電子署名を付与し、図１２及び図１３に示すように、ブロックチェーンの分割機能を用いて自処理部宛ての依頼データを生成する。
【0057】
残りの依頼があれば（Ｓ１５でＹＥＳ）、ステップＳ１６に進む。また、自処理部で実行を管理する作業がない場合も（Ｓ１３でＮＯ）、ステップＳ１６に進む。
【0058】
階層データ４２３において自処理部が最下位でない場合（Ｓ１６でＮＯ）、演算装置４１は、下位の情報処理部に宛てた依頼データを生成する（Ｓ１７）。下位の情報処理部が複数ある場合、演算装置４１は、秘密鍵で電子署名を付与し、図１２及び図１３に示すように、ブロックチェーンの分割機能を用いて、依頼データを分割して複数の依頼データを生成する。
【0059】
一方、階層データ４２３において自処理部が最下位である場合（Ｓ１６ＹＥＳ）、演算装置４１は、図１１に示すフローチャートの処理を終了し、ステップＳ１２で受信した依頼データの依頼を管理する工程を実行する。
【0060】
〈依頼先の情報処理部における工程完了の処理〉
図１４に示すフローチャートを用いて、ブロックチェーンシステム４０が依頼先の情報処理部として機能する際に、管理する工程完了の処理の流れを説明する。
図１４に示すフローチャートを用いて、ブロックチェーンシステム４０が依頼先の情報処理部として機能する際に、管理する工程完了の処理の流れを説明する。
【0061】
演算装置４１は、自処理部と関連付けられるユーザが管理する工程の検査の完了を受け付ける（Ｓ２１）。例えば、自処理部と関連付けられるユーザが管理する工程が製品の末端の部品を調達である場合、その工程の検査は、「調達した部品の検品」である。また例えば、自処理部と関連付けられるユーザが管理する工程が、部品の調達及び部品の加工である場合、その工程の検査は、「調達した部品の検品」及び「加工した部品の検品」である。又は、例えば、自処理部と関連付けられるユーザが管理する工程が、部品の加工である場合、その工程の検査は、「加工した部品の検品」である。
【0062】
演算装置４１は、証明データのオプショナルフィールドに工程の完了の履歴情報を記入する（Ｓ２２）。例えば、図５Ｂを用いて上述したように、工程の情報として、検品した製品又は部品の品目コードやシリアル番号等の情報を記入する。
【0063】
その後、演算装置４１は、上位の依頼先の情報処理部又は依頼元の情報処理部に宛てて、証明データを生成する（Ｓ２３）。ここでも、演算装置４１は、秘密鍵を用いて電子署名を付与し、証明データを生成する。なお、下位の情報処理部において、自処理部宛ての一連の工程に関する証明データを受信していたとき、演算装置４１は、その証明データとステップＳ２３で生成した証明データを合わせて上位の情報処理部に送信する。また、演算装置４１による証明データの生成は、自処理部と関連付けられるユーザによる、工程を完了した部品又は製品を上位の情報処理部と関連付けられるユーザへの納品とともに行われる。このように電子署名を利用して工程の証明データを生成することで、部品又は製品に関して実行された工程の責任の所在が、電子証明書と関連付けられるユーザであることを証明することができる。
【0064】
また、製品が納品されたユーザと関連付けられる情報処理部においても、上述したようステップＳ２１～Ｓ２３の処理が実行される。具体的には、図１５に一例を示すように、情報処理部４０１に宛てて、下位の情報処理部４０３からハンドル本体に関する証明データＴ４１’～Ｔ４３’が生成され、下位の情報処理部４０４から留め金具に関する証明データＴ５１’～Ｔ５３’が生成される。また、情報処理部４０１は、ハンドル本体と留め金具の取り付けに関する証明データＴ８１’～Ｔ８３’を生成し、秘密鍵で電子署名を付して依頼元の情報処理部宛てとする。
【0065】
〈依頼元の情報処理部における工程完了の処理〉
図１６に示すフローチャートを用いて、ブロックチェーンシステム４０が依頼元の情報処理部として機能する際に、管理する工程完了の処理の流れを説明する。
図１６に示すフローチャートを用いて、ブロックチェーンシステム４０が依頼元の情報処理部として機能する際に、管理する工程完了の処理の流れを説明する。
【0066】
演算装置４１は、自処理部と関連付けられるユーザが管理する工程の検査の完了を受け付ける（Ｓ３１）。例えば、自処理部と関連付けられるユーザが管理する工程が、部品の加工である場合、その工程の検査は、「加工した部品の検品」である。
【0067】
その後、演算装置４１は、自処理部宛に生成され一連の工程の複数の証明データを関連付けて管理データ４２４を生成し、例えば、記憶装置４２に記憶させる（Ｓ３２）。例えば、各情報処理部において、図５Ａを用いて上述した一連の証明データが生成された場合、図１７に一例を示すように各情報処理部で生成された各工程の証明データを関連付けた管理データ４２４を生成して記憶装置４２に記憶させる。なお、最終責任者である依頼元の端末１０の記憶装置１２において、管理データ４２４の各証明データのコピーを記憶してもよい。
【0068】
図１７によれば、例えば、情報処理部４０３によって“ハンドル本体１”～“ハンドル本体３”の工程の責任者として、それぞれアカウント“４－１”～“４－３”が関連付けられた証明データが生成されたことがわかる。また、情報処理部４０４によって“留め金具１”～“留め金具３”の工程の責任者として、それぞれアカウント“５－１”～“５－３”が関連付けられた証明データが生成されたことがわかる。さらに、情報処理部４０５によって“ハンドル本体と金具の取り付け１”～“ハンドル本体と金具の取り付け３”の工程の責任者として、それぞれアカウント“２－１”～“２－３”が関連付けられた証明データが生成されたことがわかる。そして、情報処理部４０６によって、“バッグ本体へのハンドルの取り付け１”～“バッグ本体へのハンドルの取り付け３”の工程の責任者として、それぞれアカウント“１－１”～“１－３”が関連付けられた証明データが生成されたことがわかる。
【0069】
上述したように、工程管理システム１では、製品の製造・検品・輸送等の各工程、各工程の責任者のアカウント、製品番号・部品番号・シリアル番号、ロット番号等の複数の異なる情報を、ブロックチェーンの情報構造を利用して、上下関係を把握しやすいツリー構造で管理することができる。これにより、工程管理システム１では、多様な検索や証明を容易に実現することができる。例えば、工程管理システム１では、最終製品が純正品で構成されたことを容易に証明することができ、また、製品のトレーサビリティを容易に実現することができる。また、製品が故障した際には、工程管理システム１で生成した管理データを用いて、故障の原因となる部品の出どころや加工作業者を遡ってトレースし、同様のリスクがある他の製品に迅速にリコールをかけることができる。
【0070】
このとき、工程管理システム１では、製品の最終責任者から下層へ、具体的には、１次請け、２次請け、３次請け、中小企業、ファミリー企業等、各工程の権限を階層構造に委託し、記録及び契約する。また、工程管理システム１では、各工程が委託された主体から、その階層構造を逆戻りに、各主体の責任において完成した部品等の納品とともに、工程に関する履歴情報を、最終責任者に戻すことができる。したがって、最終責任者は、製品を証明し、問題に対して速やかに調査することが可能となる。
【0071】
〈実施例１：情報のブラックボックス化〉
工程管理システム１は、管理データ４２４を利用して工程を管理する際、具体的な情報を秘匿したい一部の証明データについてハッシュ関数を用いてブラックボックス化してもよい。例えば、化学製品や食品等、大まかな原料を公開することは出来るが、より詳細な成分割合や製造方法を秘匿にしたい場合もある。このような場合、工程管理システム１では、対象の証明データの一部をハッシュ値としてブラックボックス化してもよい。図１８は、ある製品を、原料「成分１」、「成分２」及び「秘密成分３」により、「製造方法Ａ」で製造する各段階での証明データの一例である。図１８では省略しているが、製造責任者の左側には、成分１，２及び秘密成分３を生成する依頼先や、製造方法Ａで製造を実行する依頼先が存在し、図１８は、これらの実施によって得られた製品が製造責任者に存在する状態を示す。また、図１８では、依頼元である製造管理者は、「秘密成分３」及び「製造方法Ａ」を秘匿情報としたい一例である。この図１８は、複数の依頼先に宛てた依頼データが生成され（図示せず）、その結果として、製品の製造とともに得られた証明データＴ１と、その後、製品の流通と同時に生成された各証明データＴ２，Ｔ３を示す。なお、実際には、異なる枝番毎の証明データが利用されるが、図面の簡易化のため、図１８では、１の枝番の証明データのみを示す。この場合、工程管理システム１は、出荷責任者は、「秘匿成分」及び「製造方法Ａ」の証明データを、「ブラックボックス」とする。具体的には、証明データを「ハッシュ値」とすることで、「ブラックボックス」とする。これにより、製造責任者は、依頼元である流通責任者や、後に流通責任者から製品が渡るユーザ（図示せず）等に秘匿情報を公開する必要がなくなる。また、工程管理システム１では、秘匿情報を「ハッシュ値」として管理データ４２４で有しているため、トラブルの発生時等のトレーサビリティが要求されるタイミングにおいて、秘匿情報を閲覧することができる。したがって、ハッシュ値を利用することで、工程管理システム１は、いわゆる、トネリングと同等の機能を得ることができる。なお、出荷責任者ではなく、製造責任者において証明データをハッシュ値としてもよい。また例えば、製造責任者、出荷責任者及び流通責任者は、それぞれ同一会社・関連会社の別部門等であっても良い。
工程管理システム１は、管理データ４２４を利用して工程を管理する際、具体的な情報を秘匿したい一部の証明データについてハッシュ関数を用いてブラックボックス化してもよい。例えば、化学製品や食品等、大まかな原料を公開することは出来るが、より詳細な成分割合や製造方法を秘匿にしたい場合もある。このような場合、工程管理システム１では、対象の証明データの一部をハッシュ値としてブラックボックス化してもよい。図１８は、ある製品を、原料「成分１」、「成分２」及び「秘密成分３」により、「製造方法Ａ」で製造する各段階での証明データの一例である。図１８では省略しているが、製造責任者の左側には、成分１，２及び秘密成分３を生成する依頼先や、製造方法Ａで製造を実行する依頼先が存在し、図１８は、これらの実施によって得られた製品が製造責任者に存在する状態を示す。また、図１８では、依頼元である製造管理者は、「秘密成分３」及び「製造方法Ａ」を秘匿情報としたい一例である。この図１８は、複数の依頼先に宛てた依頼データが生成され（図示せず）、その結果として、製品の製造とともに得られた証明データＴ１と、その後、製品の流通と同時に生成された各証明データＴ２，Ｔ３を示す。なお、実際には、異なる枝番毎の証明データが利用されるが、図面の簡易化のため、図１８では、１の枝番の証明データのみを示す。この場合、工程管理システム１は、出荷責任者は、「秘匿成分」及び「製造方法Ａ」の証明データを、「ブラックボックス」とする。具体的には、証明データを「ハッシュ値」とすることで、「ブラックボックス」とする。これにより、製造責任者は、依頼元である流通責任者や、後に流通責任者から製品が渡るユーザ（図示せず）等に秘匿情報を公開する必要がなくなる。また、工程管理システム１では、秘匿情報を「ハッシュ値」として管理データ４２４で有しているため、トラブルの発生時等のトレーサビリティが要求されるタイミングにおいて、秘匿情報を閲覧することができる。したがって、ハッシュ値を利用することで、工程管理システム１は、いわゆる、トネリングと同等の機能を得ることができる。なお、出荷責任者ではなく、製造責任者において証明データをハッシュ値としてもよい。また例えば、製造責任者、出荷責任者及び流通責任者は、それぞれ同一会社・関連会社の別部門等であっても良い。
【0072】
〈実施例２：ＭＲＯ情報の管理〉
工程管理システム１は、上述した製品の製造に関する各工程の管理の他、製造後のＭＲＯ（Maintenance Repair Overhaul：整備・補修・オーバーホール）に関する各工程も管理することができる。例えば、航空機は、図１９に示すように、「翼」、「エンジン」、「胴体」、「艤装・電子機器」、「降着装置」等の複数のパーツで構成される。また、「翼」、「主翼」と「補助翼」等の複数の下位のパーツで構成される。さらに「主翼」と「補助翼」もそれぞれ複数の下位のパーツで構成され、最終的には「ビス」等の末端部品を含めてオーバーホールや交換等の各工程を管理することが困難であった。工程管理システム１は、これらの多量のパーツで構成される製品のＭＲＯの各工程に関する「証明データ」を、製造時に生成された管理データ４２４において、各工程と関連付けて追加する。
工程管理システム１は、上述した製品の製造に関する各工程の管理の他、製造後のＭＲＯ（Maintenance Repair Overhaul：整備・補修・オーバーホール）に関する各工程も管理することができる。例えば、航空機は、図１９に示すように、「翼」、「エンジン」、「胴体」、「艤装・電子機器」、「降着装置」等の複数のパーツで構成される。また、「翼」、「主翼」と「補助翼」等の複数の下位のパーツで構成される。さらに「主翼」と「補助翼」もそれぞれ複数の下位のパーツで構成され、最終的には「ビス」等の末端部品を含めてオーバーホールや交換等の各工程を管理することが困難であった。工程管理システム１は、これらの多量のパーツで構成される製品のＭＲＯの各工程に関する「証明データ」を、製造時に生成された管理データ４２４において、各工程と関連付けて追加する。
【0073】
図１９に示したような複数のパーツで構成される航空機のオーバーホールにおいて、「補助翼」を、別の「補助翼（２）」に交換するとする。この場合、オーバーホールにおける補助翼の交換とともに、工程管理システム１では、対象の航空機に関する管理データ４２４において、図２０Ａに示すように「補助翼」に関連付けられていた「証明データ」を、図２０Ｂに示すように「補助翼（２）」に関連付けられる「証明データ」と交換する。
【0074】
また、航空機のオーバーホールにおいて、「主翼」の一部である「スポイラ」を、別の「スポイラ（２）」に交換するとする。この場合、オーバーホールにおけるスポイラの交換とともに、工程管理システム１では、対象の航空機に関する管理データ４２４において、図２１Ａに示すように「スポイラ」に関連付けられていた「証明データ」を、図２１Ｂに示すように「スポイラ（２）」に関連付けられる「証明データ」と交換する。
【0075】
なお、工程管理システム１では、交換で取り外されたパーツ（図２０Ａの「補助翼」と図２１Ａの「スポイラ」）と関連付けられる証明データについては、パーツと関連付けて記憶装置４２において記憶させることができる。これにより、修理等によってパーツを再利用する場合に、パーツの証明データも再利用することができる。
【0076】
図２０Ａ乃至図２１Ｂに示したように、パーツの交換とともに、パーツに関連付けられる「証明データ」を、交換前のパーツ証明データから交換後のパーツの証明データに変更することで、実空間の航空機の情報を、記憶装置４２の管理データ４２４として管理することが可能となり、いわゆる、デジタル・ツインを実現することができる。また、各パーツの交換と合わせて証明データも交換された管理データ４２４を参照することで、パーツが交換された場合であっても、各パーツ、具体的には各工程の責任主体を特定することが可能となることで、各パーツの品質を証明することが可能となるとともに、製品全体としての品質も証明することができる。
【0077】
また、例えば、工程管理システム１は、ＭＲＯに関する各工程を記録するＭＲＯ記録データ（図示せず）を記憶装置４２に記憶させてもよい。ＭＲＯ記録データは、例えば、ＭＲＯの各工程で得られたセンサ値の記録、ＭＲＯの工程に関するテキスト形式の記録等を含む。センサ値の記録により、その時点での対象部品の状態を把握することができる。工程に関するテキスト形式の記録により、証明データに含まれない工程に関する情報を記録することができる。
【0078】
〈実施例３：補修用の部品の製造及び補修作業の管理〉
図２２は、図１７の管理データ４２４に対応し、補修用の部品を予め製造した場合の管理データの一例である。例えば、留め金具の交換が必要になることが多い場合、留め金具責任者は、留め金具の製造と同時に、補修用の部品も製造することができる。この場合、図２２に示すように、留め金具責任者と関連付けられる情報処理部４０４は、自装置宛ての依頼データのいずれかを分割し、補修部品に関するアカウント（５－ｘ）を取得し、補修部品に関する証明データを生成する。また、このとき、図２２に示すように、ハンドル責任者と関連付けられる情報処理部４０１は、自装置宛ての依頼データを分割し、ハンドルの取付の補修に関するアカウントを取得（２－ｘ）し、ハンドルの取付の補修に関する証明データを生成する。その後、修理が必要になったタイミングで、例えば、依頼元である最終責任者と関連付けられる情報処理部４００により修理作業のアカウント（ｘ－ｘ）が生成され、修理作業の依頼データが生成されると、補修部品の証明データと、ハンドル取付の補修に関する証明データと、修理作業の証明データとが関連付けられて、各作業が証明される。
図２２は、図１７の管理データ４２４に対応し、補修用の部品を予め製造した場合の管理データの一例である。例えば、留め金具の交換が必要になることが多い場合、留め金具責任者は、留め金具の製造と同時に、補修用の部品も製造することができる。この場合、図２２に示すように、留め金具責任者と関連付けられる情報処理部４０４は、自装置宛ての依頼データのいずれかを分割し、補修部品に関するアカウント（５－ｘ）を取得し、補修部品に関する証明データを生成する。また、このとき、図２２に示すように、ハンドル責任者と関連付けられる情報処理部４０１は、自装置宛ての依頼データを分割し、ハンドルの取付の補修に関するアカウントを取得（２－ｘ）し、ハンドルの取付の補修に関する証明データを生成する。その後、修理が必要になったタイミングで、例えば、依頼元である最終責任者と関連付けられる情報処理部４００により修理作業のアカウント（ｘ－ｘ）が生成され、修理作業の依頼データが生成されると、補修部品の証明データと、ハンドル取付の補修に関する証明データと、修理作業の証明データとが関連付けられて、各作業が証明される。
【0079】
〈実施例４：薬品製造情報及び利用情報の管理〉
工程管理システム１は、薬品の一例であるワクチンの製造から接種の証明までの各工程の管理に利用してもよい。例えば、図２３Ａは、ワクチンを製造する各段階での依頼データの一例である。例えば、製薬会社が依頼元となり、必要に応じて分割されて依頼先である製造受託会社、原料製造会社等に宛てて生成される。図２３Ｂは、図２３Ａで各主体の情報処理部によって各依頼データが生成された後、各依頼データに応じて工程が終了し、再び各主体の情報処理部によって生成される証明データの一例である。製造受託会社の情報処理部では、各依頼データに応じて生成された証明データに加え、自処理部で管理する工程を証明する証明データを自処理部宛てに生成する。また、製薬会社の情報処理部でも、自処理部で管理する工程を証明する証明データを自処理部宛てに生成するとともに、一部の証明データを、ハッシュ関数を用いてブラックボックス化する。
工程管理システム１は、薬品の一例であるワクチンの製造から接種の証明までの各工程の管理に利用してもよい。例えば、図２３Ａは、ワクチンを製造する各段階での依頼データの一例である。例えば、製薬会社が依頼元となり、必要に応じて分割されて依頼先である製造受託会社、原料製造会社等に宛てて生成される。図２３Ｂは、図２３Ａで各主体の情報処理部によって各依頼データが生成された後、各依頼データに応じて工程が終了し、再び各主体の情報処理部によって生成される証明データの一例である。製造受託会社の情報処理部では、各依頼データに応じて生成された証明データに加え、自処理部で管理する工程を証明する証明データを自処理部宛てに生成する。また、製薬会社の情報処理部でも、自処理部で管理する工程を証明する証明データを自処理部宛てに生成するとともに、一部の証明データを、ハッシュ関数を用いてブラックボックス化する。
【0080】
製薬会社は、図２３Ｃに示すように、その後、卸売業者を介して薬品を病院に納入する。この場合、卸売業者及び病院において、自身の管理する端末を介してブロックチェーンシステム４０にアクセスし、アカウントを取得する。また、アカウントの取得により、ブロックチェーンシステム４０内で利用可能な領域が設定され、卸売業者の情報処理部と病院の情報処理部が形成される。なお、図２３Ａ及び図２３Ｂは、３つのアカウントで納入が管理される一例である。図２３Ｃは、図２３Ｂで生成された３つのロット番号の製品に関する証明データのうち、１つのロット番号の製品に関する証明データのみ示す。ブロックチェーンシステム４０では、病院に納入された時点では、１つのロット番号の製品に関する証明データは、１つのアカウントで管理される。これに対し、病院でワクチンを使用する段階では、１つのアカウントで管理される証明データは、ワクチンを利用可能な人数である所定数の証明データに分割することができる。図２３Ｃに示す例では、病院の情報処理部は、１つの証明データを５つの証明データに分割する。またこのとき、病院の処理部は、各証明データに対応するアカウントを取得する。これにより、各証明データを接種者の識別情報と関連付けて管理し、各接種者のワクチンの接種を証明することも可能となる。例えば、空港やホール等の施設において、利用者のワクチンの接種の有無を確認する必要がある場合、この証明データを利用することで、ワクチンの接種を確認することができる。また、ワクチンの接種後に、副反応が生じたりワクチンの効果がない等の問題が発生した場合にあっては、証明データをたどり、製造の各工程を遡って調査することが可能となる。
【0081】
なお、ここでは、１つのロット番号を用いてワクチンを生成し、その後に分割する例で説明したが、工業製品の部品等についても同様の例が考えられる。例えば、複数の小部品（例えば、ネジ等）については、製造時において複数入りの箱を１つのロットとして管理することがある。このような場合、当該部品の製造までは上述した例と同様に１つのアカウントの証明データで管理するが、小分けにして使用する場面で、複数のアカウントの証明データに分割して管理する。
【0082】
〈実施例５：ＧＨＧ（Greenhouse Gas：温室効果ガス）排出量の管理〉
工程管理システム１は、工程を管理する際に、全工程に関わって排出された物質である二酸化炭素やメタンを含むＧＨＧの量（以下、「ＧＨＧ排出量」とする）を管理してもよい。例えば、製品の製造においては、製品及びその各部品の梱包、運搬、据付及び製造のための作業等、各工程でＧＨＧを排出する。一般的には、独立して実施される各工程を統一して管理することはなかったため、製品が生産されるまでの全工程で排出されたＧＨＧ排出量を把握することは困難であった。これに対し、工程管理システム１では、全ての工程を最終的に管理データ４２４により管理することができる。したがって、工程管理システム１は、各工程で排出されたＧＨＧ排出量を各段階で証明データに含めることで、最終的に得られた管理データ４２４により、全工程で排出されたＧＨＧ排出量を管理することができる。
工程管理システム１は、工程を管理する際に、全工程に関わって排出された物質である二酸化炭素やメタンを含むＧＨＧの量（以下、「ＧＨＧ排出量」とする）を管理してもよい。例えば、製品の製造においては、製品及びその各部品の梱包、運搬、据付及び製造のための作業等、各工程でＧＨＧを排出する。一般的には、独立して実施される各工程を統一して管理することはなかったため、製品が生産されるまでの全工程で排出されたＧＨＧ排出量を把握することは困難であった。これに対し、工程管理システム１では、全ての工程を最終的に管理データ４２４により管理することができる。したがって、工程管理システム１は、各工程で排出されたＧＨＧ排出量を各段階で証明データに含めることで、最終的に得られた管理データ４２４により、全工程で排出されたＧＨＧ排出量を管理することができる。
【0083】
図２４Ａ及び図２４Ｂは、実施例５の工程管理システム１で利用されるＢＯＭデータ４２１の一例を示す。実施例５の工程管理システム１は、ＢＯＭデータ４２１において、各部品に、ＧＨＧ排出量を予め関連付け、これらの部品に関わる工程の証明データの生成の際に、工程に関わるＧＨＧ排出量を含めることができる。例えば、ＢＯＭデータ４２１は、ブロックチェーンシステム４０の記憶装置４２に記憶されていてもよい。また、例えば、ＢＯＭデータ４２１は、各工程の実行に関わるユーザ毎に管理する記憶装置１２に記憶されていてもよい。すなわち、工程の実行に関わるユーザによって排出されるＧＨＧ排出量が異なる事情がある場合、工程の実行に関わるユーザ毎にＧＨＧ排出量を管理することもあるためである。なお、図２４Ａ及び図２４Ｂに示す例では、各項目について１つのＧＨＧ排出量の値のみが関連付けられるが、１つの項目であっても条件に応じて異なるＧＨＧ排出量となる場合、ＢＯＭデータ４２１は、１つの項目にそれぞれ異なる条件と関連付けられる複数のＧＨＧ排出量を含んでもよい。さらに、ＢＯＭデータ４２１がＧＨＧ排出量を含まず、各情報処理部において、作業等に応じてあらかじめ定められる方法で演算されたＧＨＧ排出量を利用してもよい。
【0084】
図２４Ａは、製品Ａの製造において使用される各部品の製造に生じるＧＨＧ排出量を含むＢＯＭデータ４２１を示す。具体的には、図２４Ａは、製品Ａの製造に使用される部品１、２自体の製造において排出されるＧＨＧ排出量は、それぞれＸ１、Ｘ２であることを示す。また、図２４Ａは、部品１の製造に使用される部品１．１、１．２自体の製造において排出されるＧＨＧ排出量は、それぞれＸ３、Ｘ４であり、部品２の製造に使用される部品２．１、２．２自体の製造において排出されるＧＨＧ排出量は、それぞれＸ５、Ｘ６であることを示す。なお、各部品の素材自体がＧＨＧの排出値を有する場合、各部品と関連付けられるＧＨＧ排出量は、部品自体のＧＨＧの排出値を加算した値である。
【0085】
また、図２４Ｂは、製品Ａの製造の各工程の作業に要するエネルギーに関連して排出されるＧＨＧ排出量を含むＢＯＭデータ４２１を示す。図２４Ｂにおいて、親部品に関連する作業として実行される作業を子部品として表される。具体的には、図２４Ｂは、据付後の梱包は、複数の部品の据付後に梱包、運搬及び据付が実行されることを示す。排出されるＧＨＧ排出量は、Ｙ１であることを示す。また、図２４Ｂは、製品Ａに対して行われる作業１、部品１に対して行われる作業１．１及び部品２に対して行われる作業２．１のＧＨＧ排出量は、それぞれ、Ｙ２、Ｙ３、Ｙ４であることを示す。なお、各ＧＨＧ排出量は、単位製品当たりの排出量である。図２４Ａ及び２４Ｂでは、各排出量は、数量「１」と関連付けられるが、例えば、仮に数量「２」が関連付けられる場合、オプショナルフィールドに書き込まれるＧＨＧ排出量は、ＢＯＭデータ４２１に関連付けられる値の２倍の値がＧＨＧ排出量として書き込まれる。
【0086】
これらの部品や作業を証明する各情報処理部は、証明データを生成する際に、これらのＧＨＧ排出量をオプショナルフィールドに含める。例えば、図２５に示すように、各工程の証明データのオプショナルフィールド内に、ＧＨＧ排出情報として、ＧＨＧ排出量を含めることができる。これにより、一度書き込みされたＧＨＧ排出量は書き替えられることが無いため、信頼性の高いＧＨＧ排出量の管理をすることができる。ＧＨＧ排出情報は、製品の製造に関連して排出したＧＨＧ排出量の他、排出したＧＨＧに関連する電力、燃料等の消費量を示す数値を含むことができる。この場合も、各値は、単位製品当たりの値である。ＧＨＧ排出量は、製造に直接的に関連する排出量だけでなく、間接的に関連する排出量も含むことができる。直接的に関連する排出量には、例えば、製造作業において、部品同士を組み合わせる作業や、各部品自体を製造する作業で発生したＧＨＧ排出量を含むことができるが、これらに限定しない。また、間接的に関連する排出量には、例えば、製造作業の通勤で発生するＧＨＧ排出量を含むことができるが、これに限定しない。また、ＧＨＧ排出情報は、設備の効率化等に応じて、ＧＨＧ排出量が削減された場合、削減されたＧＨＧ排出量（ＧＨＧ削減量）や、消費電力量が削減された場合、削減された消費電力量（電力削減量）を含むこともできる。さらにＧＨＧ排出量や消費電力量が削減されて所定の認証団体において認証された場合、ＧＨＧ削減量や電力削減量に加え、これら削減に対して付与された認証を示すＩＤ等を含むことができる。
【0087】
図２６を用いて、図２４Ａ及び図２４ＢのＢＯＭデータで表される製品Ａを製造する場合に、生成される依頼データ及び証明データについて説明する。図２６に示すように、最上位のユーザである依頼元の情報処理部４１０は、情報処理部４１１に、製品Ａの依頼データＲを送信し、情報処理部４１１は、情報処理部４１２、４１３に、それぞれ部品１、２の依頼データＲを送信する。また、情報処理部４１２は、情報処理部４１４、４１５に、それぞれ部品１．１、１．２の依頼データＲを送信し、情報処理部４１６、４１７に、それぞれ部品２．１、２．２の依頼データＲを送信する。これにより、各依頼先では、依頼された工程を実行し、工程を実行した証明データＶを送信する際に、オプショナルフィールドにＧＨＧ排出情報としてＧＨＧ排出量を書き込みする。
【0088】
具体的には、最下位のユーザである依頼先の情報処理部４１４、４１５、４１６、４１７は、それぞれ、部品１．１のＧＨＧ排出量「Ｘ３」、部品１．２のＧＨＧ排出量「Ｘ４」、部品２．１のＧＨＧ排出量「Ｘ５」、部品２．２のＧＨＧ排出量「Ｘ６」を含む証明データＶを、上位の情報処理部４１２、４１３に送信する。また、情報処理部４１２は、部品１のＧＨＧ排出量「Ｘ１」と、部品１に関する作業１．１のＧＨＧ排出量「Ｙ３」とを含む証明データＶを、上位の情報処理部４１１に送信する。さらに、情報処理部４１３は、部品２のＧＨＧ排出量「Ｘ２」と、部品２に関する作業２．１のＧＨＧ排出量「Ｙ４」とを含む証明データＶを、上位の情報処理部４１１に送信する。加えて、情報処理部４１１は、製品Ａに関する作業１のＧＨＧ排出量「Ｙ２」と、製品梱包、運搬及び据付のＧＨＧ排出量「Ｙ１」とを含む証明データＶを最上位の情報処理部４１０に送信する。また、情報処理部４１２、４１３は、それぞれ、下位の情報処理部から受信した証明データＶを上位の情報処理部４１１に送信し、情報処理部４１１も情報処理部４１２、４１３から受信した証明データＶを依頼元の情報処理部４１０に送信する。これにより、依頼元の情報処理部４１０は、全ての証明データＶによって生成される管理データ４２４に含まれるＧＨＧ排出量の合計から、製品Ａの１個毎の製造で排出されたＧＨＧ量を把握することができる。図２６の例では、Ｘ１～Ｘ６及びＹ１～Ｙ４のそれぞれを合計した値が、１個の製品Ａの製造で排出されたＧＨＧ量である。
【0089】
上述したように、工程管理システム１では、製品の製造から流通、販売後のメンテナンスに至るまで、最終責任者の契約に始まり、すべてのサプライチェーン参加社隅々にスマートコントラクト契約をもって配分された後で、今度はその隅々から、権限に基づいてスマートコントラクトを返送して組み上げていき、市場ローンチ後もその情報、デジタル・ツインをもって、克明にメンテナンス情報をアップデートし、予防的メンテナンスを提案できる、ブロックチェーンによるループバック多次元トレーサビリティが実現する。
【産業上の利用可能性】
【0090】
本開示は、製品の製造及び製造後の管理における製品及び部品のトレーサビリティの実現に有用である。
【符号の説明】
【0091】
１ 工程管理システム
１０ 依頼元端末
２０Ａ～２０Ｆ 依頼先端末
１１ 演算装置
１２ 記憶装置
１３ 入力装置
１４ 出力装置
１５ 通信装置
１０ 依頼元端末
２０Ａ～２０Ｆ 依頼先端末
１１ 演算装置
１２ 記憶装置
１３ 入力装置
１４ 出力装置
１５ 通信装置
【図1】
【図2】
【図3】
【図4】
【図5A】
【図5B】
【図6A】
【図6B】
【図6C】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20A】
【図20B】
【図21A】
【図21B】
【図22】
【図23A】
【図23B】
【図23C】
【図24A】
【図24B】
【図25】
【図26】
