JP7473911B2 - 施工情報管理システム、及び施工情報管理方法 - Google Patents

Description

特許法第３０条第２項適用 （１）令和１年１０月３０日公開 「ｉ－Ｃｏｎｓｔｒｕｃｔｉｏｎシステム学」寄付講座 成果報告会 （２）令和１年１１月２０日公開 ウェブサイト ｈｔｔｐ：／／ｗｗｗ．ｉ－ｃｏｎ．ｔ．ｕ－ｔｏｋｙｏ．ａｃ．ｊｐ／ （３）令和１年１２月１０日公開 ウェブサイト ｈｔｔｐ：／／ｗｗｗ．ａｒｃｈｉｆｕｔｕｒｅ－ｗｅｂ．ｊｐ／ｍａｇａｚｉｎｅ／４６５．ｈｔｍｌ （４）令和２年２月１７日公開 ブロックチェーンを活用した立会検査システムの実証試験、国土交通省関東地方整備局北首都国道事務所

本発明は、施工情報管理システム、及び施工情報管理方法に関する。

従来、建設工事の施工において、施工の段階に応じて、対応する事業者（請負業者）に対して施工の依頼を行っている。
すなわち、建設工事は、それぞれの専門の施工の作業を行う多くの事業者により実行される。このため、発注者が元請（最上位の請負業者）に建設工事を発注した際、この元請が建設工事における施工種類毎の作業を下位の下請、すなわち一次下請に発注し、さらに一次下請が二次下請に、また二次下請が三次下請に対して作業を発注するという複雑な多重層の請負い形態となっている（後述する図１参照）。

また、作業を発注した依頼側が、作業を請け負った請負側の作業をチェックするため、施工状況を確認可能な予め設定された所定の施工段階毎に、この施工状況を示す施工状況データが取得され、所定のストレージに対して蓄積されていく。
すなわち、施工状況の検査が行われ、請負側が依頼側に対して、施工状況を示す施工状況データとして、検査対象の施工の現場を撮像した写真、計測データなどの履歴情報を残している（例えば、特許文献１参照）。

特開２０１０－１０１１５８号公報

しかしながら、ストレージに対して記憶された施工状況データが改竄されてしまうと、工事の品質に問題が生じた際に、いずれの施工が原因であるかの判定が行えず、施工の各々の品質、出来形や進捗の管理、さらには施工された後の構造物の維持管理を行うためのトレーサビリティが低下してしまう。
また、依頼側においては、施工管理情報により現場の出来形や品質などの検査を行うが、施工状況データが改竄されると、検査の結果の信頼性が低下する。
上述したように、施工状況データのトレーサビリティが低いため、施工の出来形や品質などを確認するために工事において多くの立会検査を含めた検査が必要であり、請負の発注側及び受注側の双方の負担となっている。

本発明は、上記の事情を考慮してなされたものであり、建設工事における施工の各々の品質及び出来形や進捗の管理及び検査が容易に行なえ、さらには施工された後の構造物の維持管理を行なうトレーサビリティを向上させる施工情報管理システム、及び施工情報管理方法を提供することを目的とする。

上記課題を解決するため、本発明の施工情報管理システムは、建設工事における施工の各々の重層の請負い関係の注文者と受注者との間における電子契約書に基づき、前記施工の状況を示す施工状況データの管理を行う施工情報管理システムであり、ブロックチェーンに実装されており、当該ブロックチェーンに前記電子契約書を作成するスマートコントラクトと、前記電子契約書を識別するコントラクトＩＤに対応させて、前記施工の状況を示す施工状況データをストレージに書き込んで記憶させ、当該施工状況データの第１ハッシュ値を前記コントラクトＩＤに対応させて前記ブロックチェーンに書き込むデータ保存用アプリケーションプログラムインターフェース（ＡＰＩ）と、を備え、前記スマートコントラクトが、前記重層において層毎の請負いの前記電子契約書の間における前記コントラクトＩＤの関連付を行うことにより、当該重層の請負い関係における前記電子契約書の示す契約のツリー構造を形成することを特徴とする。

本発明の施工情報管理システムは、前記電子契約書に記載された検査ルールに対応し、前記施工状況データの検査を行ない執行条件データとして、前記コントラクトＩＤに対応させて前記ブロックチェーンに書き込む検査システムをさらに含むことを特徴とする。

本発明の施工情報管理システムは、前記検査システムが、前記施工状況データを用いて施工に対する検査を行う際、前記ストレージから読み出した前記施工状況データの第２ハッシュ値を求め、当該第１ハッシュ値と前記第１ハッシュ値とを比較し、前記施工状況データの改竄の有無を判定することを特徴とする。

本発明の施工情報管理システムは、前記スマートコントラクトが、前記電子契約書の執行条件における支払ルールにより、前記施工状況データに応じた前記施工の対価を支払うことを特徴とする。

本発明の施工情報管理方法は、建設工事における施工の各々の重層の請負い関係の注文者と受注者との間における電子契約書に基づき、前記施工の状況を示す施工状況データの管理を行う施工情報管理方法であり、スマートコントラクトが、ブロックチェーンに実装されており、当該ブロックチェーンに前記電子契約書を作成する電子契約書作成過程と、データ保存用アプリケーションプログラムインターフェース（ＡＰＩ）が、前記電子契約書を識別するコントラクトＩＤに対応させて、前記施工の状況を示す施工状況データをストレージに書き込んで記憶させ、当該施工状況データの第１ハッシュ値を前記コントラクトＩＤに対応させて前記ブロックチェーンに書き込む施工状況データ書込過程と、を含み、前記電子契約書作成過程において、前記スマートコントラクトが、前記重層において層毎の請負いの前記電子契約書の間における前記コントラクトＩＤの関連付を行うことにより、当該重層の請負い関係における前記電子契約書の示す契約のツリー構造を形成することを特徴とする。

本発明によれば、建設工事における施工の各々の品質及び出来形や進捗の管理、さらには施工された後の構造物の維持管理を行なうトレーサビリティを向上させる施工情報管理システム、及び施工情報管理方法を提供することができる。

工事における施工の各々の請負の形態の一例を示す施工契約関係の図である。 本発明における工事の施工情報管理、施工情報データに対する検査、検査に対応した施工の対価の支払を説明する概念図である。 本発明の一実施形態である施工情報管理システムの構成例を示すブロック図である。 本発明の一実施形態である施工情報管理システムの実用例を示すブロック図である。

図１は、工事における施工の各々の請負の形態の一例を示す施工契約関係の図である。
図１に示されるように、工事の施工においては、例えば、工事を発注する発注者と、発注者からの工事を受注する請負（元請）と、請負から下請とされる工事における施工種類の各々を、それぞれの施工を専門に行う事業者とが存在する。すなわち、本実施形態において、施工契約における注文者は、工事の施工を注文する側の事業者を示している。また、この注文者において、自らが施工における実際の作業を行なわない事業者を発注者としている。受注者は、工事の施工を受注する側の事業者である。
また、施工種類の各々においては、さらに複数の細分化された施工種類があり、請負から直接に施工を依頼されるのが一次下請、一次下請から施工を依頼されるのが二次下請として、工事における施工の重層の請負い関係かに対応したツリー構造が形成される。

そして、発注者から元請に対し、元請から一次下請に対し、一次下請から二次下請へと、対応する施工種類の施工が請負われて、施工に対応した契約書がそれぞれ発行される。
この契約書に対応した施工の検査を行ない、検査結果に基づいて、契約書に記述されている執行条件により、施工を発注した注文者から、施工を受注した受注者に対して、施工に対する対価の支払が行われる。

図２は、本発明における工事の施工情報管理、施工情報データに対する検査、検査に対応した施工の対価の支払を説明する概念図である。
本発明の施工情報管理システムは、近年、盛んに各分野で用いられているブロックチェーンの技術を用いて、建設現場の施工に関する契約書を電子データの電子契約書として、発注側である発注者及び注文者と、受注（請負）側の受注者との各々が建設工事における施工の何れを請け負っているかの情報に基づき、施工に対する執行条件における検査ルールに対応して施工の品質（例えば、管理値に対する品質）、出来形を管理し、執行条件における支払ルールにより出来高に応じて施工に対する対価の支払を行う構成を備えている。

発注者及び注文者の各々は、注文側（発注者または注文者）、受注側（受注者）、施工の検査に対する管理値、請負金額及び支払の執行条件を含む、施工の契約内容を示す契約書のデータをユーザ端末に対して入力する。
これにより、ユーザ端末（Ｗｅｂブラウザ）は、電子契約書の発行依頼を行うアプリケーションを介して、注文側（発注者または注文者）、請負金額（施工の対価として支払う金額）、受注側（受注者）、施工の検査に対する管理値、及び支払の執行条件（執行条件データ）を含む電子契約書を書き込む処理を、ブロックチェーンノード（後述するブロックチェーンノード２１）が生成するブロックチェーンのスマートコントラクト３０に対して依頼する。

そして、ブロックチェーンに実装されているスマートコントラクト３０が、注文側から入力されるデータに基づいて、このブロックチェーン上に電子契約書を生成する。ブロックチェーンに、施工の請負いに対応した電子契約書が書き込まれることにより、この電子契約書の改竄を抑止することができる。
また、設計計画・施工管理システム（後述する施工管理システム２２０）は、施工を行なう施工者（例えば、受注者）から入力される、当該受注者が請負った施工における出来形の情報（施工状況データ）を、データストレージ（不図示、後述するデータストレージ５０）に対して出力する。
データストレージは、設計計画・施工管理システムから供給される、当該受注者が請負った施工における出来形の情報（施工状況データ）を自身のストレージ（後述するストレージ５２）に格納し、この施工状況データのハッシュ値をブロックチェーンに対して書き込む処理を行う。

これにより、施工の出来形を示す施工状況データの実データの各々がデータストレージに時系列に蓄積され、この施工状況データのハッシュ値それぞれが対応してブロックチェーンに書き込まれているため、データストレージにおける施工状況データが改竄されることを抑止することができる。
すなわち、検査システム６０が検査を行う際、データストレージに蓄積された施工状況データのハッシュ値を求め、ブロックチェーンに記載されたハッシュ値とを比較し、検査に用いるデータストレージにおける施工状況データの改竄の有無を確認するため、データストレージに対して時系列に蓄積される施工状況データの各々の信頼性を担保し、施工状況データのトレーサビリティを向上させることができ、施工毎に対応して行われる検査の結果の品質を担保することができる。

また、検査システム６０が施工状況データが管理値に対応した品質であるか、また施工の出来形がどの程度であるかを解析グラフィック処理などの手法を用いて検査し、検査結果をブロックチェーンに対して執行条件データとして書き込む処理を行う。
施工の出来形に対する検査の結果が執行条件データとしてブロックチェーンに書き込まれることにより、上記スマートコントラクト３０が執行条件データと、執行条件とを比較して、対価の支払を行うか否かの判定を行ない、対価の支払の処理、例えば、発注側のウォレットアドレスから受注側のウォレットアドレスへの対価としてのバリューの移行処理を行う。

上述した構成により、ブロックチェーン技術を用いて安価に構築された施工情報管理システムにおいて、建設工事の施工の各々において、施工状況データのトレーサビリティを向上させ、検査の自動化による発注側と受注側の負担となる立会検査を低減するとともに、検査の結果を示す執行条件データに基づいて随時、施工の対価の支払を行うことができる。

図３は、本発明の一実施形態である施工情報管理システム１の構成例を示すブロック図である。
図３において、施工情報管理システム１は、アプリケーション１０、ＰｔｏＰネットワーク２０、スマートコントラクト３０、データベース４０、データストレージ５０、検査システム６０の各々を備えている。
また、アプリケーション１０は、Ｗｅｂ（World Wide Web）サーバー上に実装されており、アプリケーションソフトウェアとして、フロントエンド１１及びスマートコントラクト実行用ＡＰＩ（Application Programming Interface）１２の各々を備えている。
また、ＰｔｏＰ（Peer to Peer）ネットワーク２０は、ブロックチェーンの生成／管理を行うソフトウェアを実装し、ＰｔｏＰネットワーク構成により接続された複数のブロックチェーンノード２１を備えている。

スマートコントラクト３０は、ブロックチェーン上に配置するソフトウェア（プログラムコード）であり、ブロックチェーンにおける各ブロックにおける電子契約書の生成及び執行条件に対応した施工の対価の支払を所定のバリュー（例えば、仮想通貨）により行う。外部の支払システム２１０は、スマートコントラクト３０がブロックチェーンノード２１から供給されるバリュー値に対応して、所定の通貨によって発注者、注文者及び受注者の各々の間における施工の対価の支払処理を行う。
データベース４０は、例えば、施工状況データのメタデータなど、ブロックチェーンに対する処理の履歴が書き込まれる記憶部であり、特定のデータモデル専用に設計されたスキーマレスのＮｏＳＱＬ (非リレーショナル) データベースである。

データストレージ５０は、施工状況データの実データを蓄積するデータベースであり、データ保存用ＡＰＩ５１及びストレージ５２の各々を備えている。
データ保存用ＡＰＩ５１は、外部装置（例えば、後述する施工管理システム２２０）からストレージ５２に対するアクセス、施工状況データのメタデータの作成、作成したメタデータのデータベース４０への書き込み、施工状況データのハッシュ値（後述するハッシュ値Ｈ１）の作成、作成したハッシュ値のブロックチェーンへの書き込みなどの処理を実行する。
ストレージ５２には、所定のテーブル形式でデータが蓄積される記憶部であり、外部装置から供給される施工状況データの実データがデータ保存用ＡＰＩ５１により書き込まれて記憶されている。

検査システム６０は、品質及び出来形確認用プログラム６１、結果閲覧用ビューワー６２のそれぞれを備えている。これら品質及び出来形確認用プログラム６１、結果閲覧用ビューワー６２の各々は、例えば、Ｗｅｂサーバー上に実装されているアプリケーションソフトウェアである。
品質及び出来形確認用プログラム６１は、ストレージ５２に記憶されている施工状況データにおける、執行条件に記載された検査項目のデータと管理値とを比較する検査を行ない、検査結果を執行条件データとして、ブロックチェーンノード２１を介して、ブロックチェーンに書き込む。
結果閲覧用ビューワー（viewer）６２は、検査結果である執行条件データ、施工対象の計測された出来形の実測値（施工状況データの一例）、施工対象の設計データに対応した３次元形状モデルの画像などの閲覧に用いられるビューワーである。

以下、図３を用いて、施工情報管理システムにおける電子契約書の生成処理、施工状況データの管理、施工状況データに基づく検査、及び検査結果の執行条件データによる対価の支払の動作例を、建設工事における土工事を一例として説明する。
＜処理＃０：ブロックチェーンに対するスマートコントラクトの実装＞
ステップＳ０：スマートコントラクト３０は、ブロックチェーン上に電子契約書の生成を行ない、施工状況データの検査結果を含む執行条件データに対応して、施工の対価の支払を行うアプリケーションソフトとして、そのプログラムコードがブロックチェーンノード２１により、ブロックチェーン上にソフトウェアエージェントとして実装（配置）される。

＜処理＃１：発注者（ユーザ５０１）によるサイトＩＤの生成＞
ステップＳ１＿１：発注者は、工事（土工事）の発注先である元請（元請負）に対して支払う対価のバリュー値（例えば、仮想通貨による金額）を、フロントエンド１１が表示するユーザ端末（Ｗｅｂブラウザが実装）の表示画面から入力する。

ステップＳ１＿２：フロントエンド１１は、入力された施工の対価のバリュー値を、スマートコントラクト実行用ＡＰＩ１２に対して出力する（リクエスト）。

ステップＳ１＿３：スマートコントラクト実行用ＡＰＩ１２は、対価の金額が供給された場合、ブロックチェーン（ＢＬＣ）のスマートコントラクトに対して、この供給された対価の金額を出力する（ＢＬＣリクエスト）。

ステップＳ１＿４：スマートコントラクト３０は、対価の金額の支払元（発注者）のクリエーターアドレス（例えば、発注者のウォレットアドレス）と、対価の金額の支払先（受注者、例えば元請）のサイトアドレス（例えば、受注者のウォレットアドレス）と、サイトＩＤ（identifier）とを生成する。このサイトＩＤは、受注者（元請）に発注する土工事の工事全体を識別する識別情報である。
そして、スマートコントラクト３０は、生成したクリエーターアドレス、サイトアドレス及びサイトＩＤを、アプリケーション１０に対して出力する（ＢＬＣレスポンス）。

上記ウォレットアドレスは、それぞれが互いに干渉しない数値で事業者毎に設定されてお、施工における作業の対価の支払先のアドレスを示している。そして、ウォレットアドレスは、他と干渉しないため、事業者の各々が固有の数値であるため、施工を請け負った事業者それぞれの識別に用いられる。

ステップＳ１＿５：スマートコントラクト実行用ＡＰＩ１２は、ブロックチェーンのスマートコントラクトから供給されるクリエーターアドレス、サイトアドレス及びサイトＩＤをフロントエンド１１に対して出力する（レスポンス）。

ステップＳ１＿６：フロントエンド１１は、入力されたクリエーターアドレス、サイトアドレス及びサイトＩＤを、Ｗｅｂブラウザを介してユーザ端末の表示画面に対して表示し、ユーザ＃１（発注者）に対して通知する。

＜処理＃２注文者から受注者に対する契約書の作成＞
以下の説明においては、例えば、注文者が元請であり、受注者が一次下請である。
ステップＳ２＿１：注文者は、コントラクトＩＤ（ＩＤ＃１１１１）と、自身（すなわち、工事の発注元である請負）のサイトアドレスと、一次下請に対して支払う対価の金額と、注文する工事の施工種類と、施工状況データにおいて検査対象とされるデータ項目（施工情報管理項目）と、対価の支払の執行条件とを、フロントエンド１１が表示するユーザ端末における契約書の作成用の表示画面から入力する。コントラクトＩＤは、スマートコントラクト３０が生成する電子契約書を識別するための識別情報である。

ここで、執行条件とは、施工の対価を支払う期日や、対価を支払うか否かを判定する施工情報管理項目に対する管理値などが含まれている。
例えば、土工事における造成の転圧を行う施工の場合、転圧を行う際のローラにより予め同様の土を用いた実験により求めた締固め回数が管理値となる。

ステップＳ２＿２：フロントエンド１１は、コントラクトＩＤ（ＩＤ＃１１１１）と、サイトアドレスと、支払う対価の金額と、施工種類と、施工情報管理項目と、執行条件とのデータを、スマートコントラクト実行用ＡＰＩ１２に対して出力する（リクエスト）。

ステップＳ２＿３：スマートコントラクト実行用ＡＰＩ１２は、コントラクトＩＤ（ＩＤ＃１１１１）と、サイトアドレスと、支払う対価の金額と、施工種類と、施工情報管理項目と、執行条件とのデータが供給された場合、ブロックチェーンにおけるスマートコントラクト３０に対して、入力されるコントラクトＩＤ（ＩＤ＃１１１１）と、サイトアドレスと、支払う対価の金額と、施工種類と、施工情報管理項目と、執行条件とを出力する（ＢＬＣリクエスト）。

ステップＳ２＿４：これにより、スマートコントラクト３０は、受注者（一次下請）のサイトアドレスを生成し、コントラクトＩＤ（ＩＤ＃１１１１）に対応させて、注文者のサイトアドレスと、受注者のサイトアドレスと、支払う対価の金額と、施工種類と、施工情報管理項目と、執行条件とを含む電子契約書を生成する。
そして、スマートコントラクト３０は、コントラクトＩＤ（ＩＤ＃１１１１）と、注文者のサイトアドレスと、受注者のサイトアドレスと、支払う対価の金額と、施工種類と、施工情報管理項目と、執行条件とを、アプリケーション１０に対して出力する（ＢＬＣレスポンス）。

ステップＳ２＿５：スマートコントラクト実行用ＡＰＩ１２は、ブロックチェーンのスマートコントラクト３０から供給されるコントラクトＩＤ（ＩＤ＃１１１１）と、注文者のサイトアドレスと、受注者のサイトアドレスと、支払う対価の金額と、施工種類と、施工情報管理項目と、執行条件とを、フロントエンド１１に対して出力する（レスポンス）。

ステップＳ２＿６：フロントエンド１１は、コントラクトＩＤ（ＩＤ＃１１１１）と、注文者のサイトアドレスと、受注者のサイトアドレスと、支払う対価の金額と、施工種類と、施工情報管理項目と、執行条件とを表示画面に対して出力し、注文者（元請）に対して通知する。
また、注文者である発注者から、受注者である元請に対しても、上述した注文者である元請から受注者である一次下請に対して、施工の請負に関する電子契約書（コントラクトＩＤがＩＤ＃１１１０）を生成する。

＜処理＃３：受注者による電子契約書の関連付＞
以下、注文者である元請と、受注者である一次下請との間の施工の請負の電子契約の関連付について説明する。
ステップＳ３＿１：受注者（一次下請、ユーザ＃１）は、コントラクトＩＤ（ＩＤ＃１１１０）と、関連するコントラクトＩＤ（ＩＤ＃１１１１）とを、ユーザ端末における契約書の関連付用の表示画面（実装されたＷｅｂブラウザが表示）における契約書の関連付の欄に入力する。

ステップＳ３＿２：フロントエンド１１は、契約書の関連付の欄に入力された、コントラクトＩＤ（ＩＤ＃１１１０）と、コントラクトＩＤ（ＩＤ＃１１１１）とのデータを、スマートコントラクト実行用ＡＰＩ１２に対して出力する（リクエスト）。

ステップＳ３＿３：スマートコントラクト実行用ＡＰＩ１２は、コントラクトＩＤ（ＩＤ＃１１１０）と、コントラクトＩＤ（ＩＤ＃１１１１）とのデータが供給された場合、ブロックチェーンにおけるスマートコントラクト３０に対して、供給されたコントラクトＩＤ（ＩＤ＃１１１０）と、コントラクトＩＤ（ＩＤ＃１１１１）と、コントラクトＩＤ（ＩＤ＃１１１１）の発行元のアドレス（すなわち、注文者である元請のクリエータアドレス）とのデータを出力する（ＢＬＣリクエスト）。

ステップＳ３＿４：スマートコントラクト３０は、コントラクトＩＤ（ＩＤ＃１１１０）と、コントラクトＩＤ（ＩＤ＃１１１１）とのデータが供給された場合、供給されたコントラクトＩＤ（ＩＤ＃１１１０）と、コントラクトＩＤ（ＩＤ＃１１１１）と、コントラクトＩＤ（ＩＤ＃１１１１）の発行元のアドレス（すなわち、注文者である元請のクリエータアドレス）と、コントラクトＩＤ（ＩＤ＃１１１１）の発行先のアドレス（すなわち、受注者である一次下請のクリエータアドレス）とを、アプリケーション１０に対して出力する（ＢＬＣレスポンス）。

ステップＳ３＿５：スマートコントラクト実行用ＡＰＩ１２は、ブロックチェーンのスマートコントラクト３０から供給されるコントラクトＩＤ（ＩＤ＃１１１０）と、コントラクトＩＤ（ＩＤ＃１１１１）と、サイトＩＤの発行先のアドレスとを、フロントエンド１１に対して出力する（レスポンス）。

ステップＳ３＿６：フロントエンド１１は、コントラクトＩＤ（ＩＤ＃１１１０）と、コントラクトＩＤ（ＩＤ＃１１１１）とのデータとを、コントラクトＩＤ（ＩＤ＃１１１０）の発行元のアドレスに対応した注文者のユーザ端末の表示画面に対して出力し、コントラクトＩＤ（ＩＤ＃１１１０）の電子契約書と、コンラクトＩＤ（ＩＤ＃１１１１）の電子契約書との関連付に対する承認（すなわち、元請の一次下請に対する施工の発注の承認）を促す通知を、ユーザ＃１（注文者である元請）に対して行う。

＜処理＃４：注文者による契約書の承認＞
ステップＳ４＿１：注文者（元請であるユーザ＃１）は、コントラクトＩＤ（ＩＤ＃１１１０）と、このコントラクトＩＤ（ＩＤ＃１１１０）に関連するコントラクトＩＤ（ＩＤ＃１１１１）とを、ユーザ端末におけるＷｅｂブラウザの表示画面において確認し、表示画面における電子契約書の承認の欄に対して、承認を示すデータ（承認データ）を入力する。

ステップＳ４＿２：フロントエンド１１は、電子契約書の承認関連付の欄に入力された、コントラクトＩＤ（ＩＤ＃１１１０）及びコントラクトＩＤ（ＩＤ＃１１１１）の各々の電子契約書の承認データを、スマートコントラクト実行用ＡＰＩ１２に対して出力する（リクエスト）。

ステップＳ４＿３：スマートコントラクト実行用ＡＰＩ１２は、コントラクトＩＤ（ＩＤ＃１１１０）及びコントラクトＩＤ（ＩＤ＃１１１１）の各々の電子契約書の関連付に対する承認データが供給された場合、ブロックチェーンにおけるスマートコントラクト３０に対して、コントラクトＩＤ（ＩＤ＃１１１０）、コントラクトＩＤ（ＩＤ＃１１１１）それぞれの電子契約書の関連付の承認データを出力する（ＢＬＣリクエスト）。

ステップＳ４＿４：これにより、スマートコントラクトは、コントラクトＩＤ（ＩＤ＃１１１０）及びコントラクトＩＤ（ＩＤ＃１１１１）の各々の電子契約書の関連付の承認データが供給された場合、コントラクトＩＤ（ＩＤ＃１１１１）の電子契約書を有効化し、コントラクトＩＤ（ＩＤ＃１１１０）、コントラクトＩＤ（ＩＤ＃１１１１）それぞれの電子契約書の関連付が行われたことを示す確認データをアプリケーション１０に対して出力する（ＢＬＣレスポンス）。

ステップＳ４＿５：スマートコントラクト実行用ＡＰＩ１２は、コントラクトＩＤ（ＩＤ＃１１１０）及びコントラクトＩＤ（ＩＤ＃１１１１）の各々の電子契約書の関連付の確認データを、フロントエンド１１に対して出力する（レスポンス）。

ステップＳ４＿６：フロントエンド１１は、コントラクトＩＤ（ＩＤ＃１１１０）及びコントラクトＩＤ（ＩＤ＃１１１１）の各々の電子契約書の関連付が行われたことを示す確認データを、ユーザ＃１（発注者）のユーザ端末のＷｅｂブラウザによる表示画面に対して出力し、コントラクトＩＤ（ＩＤ＃１１１０）、コントラクトＩＤ（ＩＤ＃１１１１）それぞれの電子契約書の関連付けが行われたことを示す通知を、ユーザ＃１（発注者）に対して行う。

上述した処理＃２、処理＃３及び処理＃４により、元請（注文者）から一次下請（受注者）との間の電子契約書（ＩＤ＃１１１１）を、発注者（注文者）と元請（受注者）との間の電子契約書（ＩＤ＃１１１０）との関連付けが、ブロックチェーンに実装されたスマートコントラクト３０により処理され、図１における電子契約書のツリー構造に示すように、コントラクトＩＤ（ＩＤ＃１１１０）とコントラクトＩＤ（ＩＤ＃１１１１）との紐付け（対応付け）が行われる。

また、一次下請が注文者となり、二次下請が受注者となる場合、二次下請が上記処理＃２を行ない、例えば、ＩＤ＃１１１２のコントラクトＩＤの電子契約書を、スマートコントラクト３０により作成する。
そして、処理＃３において、二次下請がコントラクトＩＤ（ＩＤ＃１１１１）とコントラクトＩＤ（ＩＤ＃１１１２）との関連付けの処理を、コントラクトＩＤ（ＩＤ＃１１１１）の電子契約書における注文者である一次下請に対して依頼する。

これにより、一次下請が処理＃３を行ない、コントラクトＩＤ（ＩＤ＃１１１１）とコントラクトＩＤ（ＩＤ＃１１１２）との関連付けの承認（スマートコントラクト３０による承認）の処理を行う。
これにより、元請によるコントラクトＩＤ（ＩＤ＃１１１１）とコントラクトＩＤ（ＩＤ＃１１１２）との関連付けが行われる。
そして、上述した処理を注文者と受注者とが行なうことにより、図２に示しているように、コントラクトＩＤ（ＩＤ＃１１１０）－コントラクトＩＤ（ＩＤ＃１１１１）－コントラクトＩＤ（ＩＤ＃１１１２）との、サイトＩＤが示す施工の請負い関係（電子契約書の各々における注文者と受注者との対応関係）を示すツリー構造が生成される。

＜処理＃５：施工状況データのデータベースへの書き込み＞
ステップＳ５＿１：注文者あるいは受注者（実際に施工を行っている施工者）の事業者により、各電子契約書における施工の施工状況データが、施工管理システム２２０からデータストレージ５０に対して入力される。
ここで、例えば、施工の種類が土工事における造成である場合、施工者（事業者）は、電子契約書に記載された施工の作業として、現場における盛土の転圧の処理を行う。
施工者は、実際の現場において、ダンプトラックが運搬（運土）してきた土をブルドーザにより敷均して盛土を生成し、ローラによる盛土の締固め（転圧）を行う。

そして、施工者は、盛土の材料の情報と、ローラの締固め回数を求める情報、及び計測器によって施工される盛土の出来形を示す計測データの各々が取得される。
すなわち、施工状況データとしては、例えば、ローラーなどの重機の移動経路を示すＧＮＳＳ（Global Navigation Satellite System）による位置座標の時系列データ、造成の盛土として用いた土の材料情報、出来形を示す３次元点群、施工対象を撮像した撮像画像や施工対象の施工図などの電子データなどである。

ステップＳ５＿２：データストレージ５０において、データ保存用ＡＰＩ５１は、施工者が施工管理システム２２０から供給される施工状況データのハッシュ値Ｈ１を所定のハッシュ関数により作成する。
そして、データ保存用ＡＰＩ５１は、作成した施工状況データのハッシュ値Ｈ１と、施工に対応するコントラクトＩＤとをブロックチェーンノード２１に対して送信する。
ブロックチェーンノード２１は、データ保存用ＡＰＩ５１から供給されるハッシュ値Ｈ１を、コントラクトＩＤに対応付けて所定のブロックに書き込み、このブロックＩＤをデータストレージ５０に対して送信する。

ステップＳ５＿３：データ保存用ＡＰＩ５１は、施工管理システム２２０から入力された施工状況データ（実データ）を、コントラクトＩＤ、及びブロックチェーンノード２１からのブロックＩＤの各々に対応付けて、ストレージ５２に対して書き込んで記憶させる。
これにより、ブロックチェーンのブロックに、ストレージ５２に格納される施工状況データのハッシュ値Ｈ１が書き込まれているため、このハッシュ値Ｈ１と検査を行う際にストレージに記憶されている実データである施工状況データのハッシュ値Ｈ２とを比較すること改竄の有無が判るため、検査で用いる施工状況データの信頼性を向上させ、コントラクトＩＤにより電子契約書毎の施工における品質のトレーサビリティが可能となる。

また、施工状況データの実データをデータストレージ５０に書き込んで記憶させ、ブロックチェーンに施工状況データのハッシュ値を書き込むことにより、ブロックチェーンのブロックの各々にデータ量の大きい施工状況データが蓄積されず、ブロックチェーンのデータ量を低減することができる。
そのため、本実施形態によれば、上述した施工状況データの改竄を抑止し、かつデータ量を低減させたブロックチェーンにより、品質のトレーサビリティを向上させることができる。

＜処理＃６：施工状況データにおける施工情報管理項目に対する検査＞
ステップＳ６＿１：施工状況の検査を行う検査者であるユーザ＃２が（例えば、発注者）は、ユーザ端末からＷｅｂブラウザを介して検査システム６０に対して、検査対象の施工に対応する電子契約書のコントラクトＩＤを入力する。

ステップＳ６＿２：検査システム６０において、品質及び出来形確認用プログラム６１は、入力されたコントラクトＩＤに対応した施工状況データの検索の依頼を、データストレージ５０に対して行う。

ステップＳ６＿３：データ保存用ＡＰＩ５１は、施工状況データの検索依頼がユーザ端末から供給された場合、コントラクトＩＤに対応した施工状況データをストレージ５２において検索する。
そして、データ保存用ＡＰＩ５１は、検索された施工状況データをストレージ５２から読み出し、読み出した施工状況データを検査システム６０に対して出力する。

ステップＳ６＿４：品質及び出来形確認用プログラム６１は、データ保存用ＡＰＩ５１が使用したハッシュ関数と同一のハッシュ関数を用いて、データストレージ５０から供給された施工状況データのハッシュ値Ｈ２を求める。

ステップＳ６＿５：品質及び出来形確認用プログラム６１は、ブロックチェーンの最新のブロックから、検査対象の施工の電子契約書のコントラクトＩＤに対応したハッシュ値Ｈ１を読み込む。
そして、品質及び出来形確認用プログラム６１は、読み込んだハッシュ値Ｈ１と自身が作成したハッシュ値Ｈ２とを比較し、同一である（一致している）か否かの判定を行う。ここで、品質及び出来形確認用プログラム６１は、ハッシュ値Ｈ１とハッシュ値Ｈ２とが同一である場合、データストレージ５０における施工状況データが改竄されていないと判定する。
一方、品質及び出来形確認用プログラム６１は、ハッシュ値Ｈ１とハッシュ値Ｈ２とが同一である場合、データストレージ５０における施工状況データが改竄されたと判定する。

ステップＳ６＿６：品質及び出来形確認用プログラム６１は、検査対象の施工の電子契約書に記載された施工情報管理項目や、施工状況データにおける施工情報管理項目の検査対象データを評価する管理値などを読み込む。
そして、品質及び出来形確認用プログラム６１は、施工状況データにおける検査対象データが、管理値（品質、規格など）を満たしているか否かの評価を行い、満足しているか否かを示すＯＫ（品質を満たしている）／ＮＧ（品質を満たしていない）の品質フラグを、ブロックのコントラクトＩＤに対応させて、ブロックチェーンノード２１へ出力する。

例えば、品質及び出来形確認用プログラム６１は、施工状況データと管理値とを比較して、施工における出来形から、管理値に対応した施工誤差を算出する。
例えば、施工が造成工事における土工事である場合、施工における品質は、施工対象の出来形検査において、検査により取得された出来形の３次元点群により得られた実測値と、設計より得られた３次元形状モデルとで算出される誤差が、管理値の誤差範囲に入っているか否かにより判定される。
品質及び出来形確認用プログラム６１は、算出された誤差が管理値の誤差範囲に入っている場合、品質フラグをＯＫとする。一方、品質及び出来形確認用プログラム６１は、算出された誤差が管理値の誤差範囲から外れている場合、品質フラグをＮＧとする。

また、品質及び出来形確認用プログラム６１は、施工が造成工事における土工事である場合、造成された出来形の面積が依頼された面積のどの程度の割合かを示す％を出来高、あるいはローラーによる締固めの回数が依頼した回数に対してどの程度の割合かを示す％を出来高として求める。
そして、品質及び出来形確認用プログラム６１は、品質フラグ及び出来高を、執行条件データとしてブロックチェーンノード２１に対して送信する。
ブロックチェーンノード２１は、コントラクトＩＤ及び執行条件データが検査システム６０から供給された場合、ブロックチェーンのブロックに対して、このコントラクトＩＤに対応させて執行条件データを書き込む。

ステップＳ６＿７：検査者は、例えば、受注者に依頼した施工の出来形を確認するため、この施工の電子契約書のコントラクトＩＤを、ユーザ端末からＷｅｂブラウザを介して検査システム６０に対して出力する。
品質及び出来形確認用プログラム６１は、検査者が入力したコントラクトＩＤに対応する品質フラグ及び出来高を結果閲覧用ビューワー６２に対して出力する。

ステップＳ６＿８：結果閲覧用ビューワー６２は、施工対象の出来形の撮像画像（撮像装置などにより撮像された画像）の画像データを、コントラクトＩＤに対応して読み出す。
そして、結果閲覧用ビューワー６２は、Ｗｅｂブラウザを介してユーザ端末の表示画面に、品質フラグ及び出来高の執行条件データや、施工対象の出来形の撮像画像を表示する。
ここで、結果閲覧用ビューワー６２は、例えば、施工が造成工事である場合、上述したように、出来形の３次元点群による実測面の３次元形状と、設計データから生成した出来形の３次元モデルとを仮想空間において重畳させ、重畳させた３次元形状を任意の角度から観察した画像を表示画面に対して表示させ、設計における形状に対する出来形の形状を検査者に対して鑑賞させる。

上述したように、注文者が施工者である受注者の入力した施工状況データにおける施工情報管理項目に対応した計測データに対し、執行条件に記載された管理値と比較することにより、執行条件データをブロックチェーンに書き込むため、建設工事における施工の各々の品質及び出来形や進捗の管理を行なうトレーサビリティが向上し、ネットワークを介した検査が可能となるため、施工状況に対応して建設工事における施工の注文者及び受注側の双方が揃って行う立会検査の回数を低減することができ、リアルタイムに施工の出来形や品質の検査を行うことができる。

＜処理＃７：スマートコントラクトによる施工の対価の支払処理＞
スマートコントラクト３０は、ブロックチェーンのブロックにおけるコントラクトＩＤ毎に、執行条件データが電子契約書における執行条件を満たしているか否かの判定を行う。
そして、スマートコントラクト３０は、執行条件データが電子契約書における執行条件を満たしている場合、そのコントラクトＩＤに対応する電子契約書に記載された注文者のサイトアドレスから、受注者のサイトアドレスに対して、支払う対価のバリュー値を移動させる（すなわち、施工に対する対価の支払を行う）。
また、スマートコントラクト３０は、施工に対する対価の支払を行う毎に、コントラクトＩＤに対応するトランザクションを生成する。

上述したように、スマートコントラクト３０が検査システム６０が求めた執行条件データと、電子契約書における執行条件とを比較し、例えば、施工対象の出来高に対する、あるいは予め設定された支払日に対する対価の支払として、注文者のサイトアドレスから受注者のサイトアドレスに、電子契約書に記載された対価としてのバリュー値を移行させるため、任意の段階（あるいは、タイミング）における施工状況の検査結果により、所定の施工状況における工事の対価の出来高払いが可能となる。

従来においては、発注者の検査などにおいて、施工に対する出来形や品質が契約書に記載された執行条件に適合している場合に、受注者は施工の対価の支払を受けていた。
しかしながら、発注者が施工状況の検査を随時行う訳ではなく、施工の完了の検査とともに施工の対価が支払われたり、長い周期毎に行われる検査の結果に対応して対価の支払が行われる場合がほとんどである。
規模の大きな事業者は、施工の作業に必要な資金を銀行などから受けることが可能であるため、所定の施工段階毎に支払を受ける形態でも施工が可能である。

一方、一次下請、二次下請及び三次下請などの下請となる事業者のなかで、所定の作業に特化した小さな事業者は、施工に対する対価の支払の周期が長い場合、工事の規模によっては請け負った作業の資金を準備できず、建設工事に参加できない恐れがある。
しかしながら、本実施形態によれば、施工の任意の段階において施工状況に対応した対価の支払ができるため、二次下請及び三次下請などの下請となる事業規模が小さく、資金力がない、または資金の調達が困難な事業者であっても、施工を請負うことが可能となる。

＜処理＃８：データベース４０への施工処理の履歴の書込処理＞
データベース４０には、コントラクトＩＤ及びブロックＩＤに対応して、施工状況データのメタデータ、あるいは電子契約書の作成におけるログデータが書き込まれる。
すなわち、スマートコントラクト実行用ＡＰＩ１２は、フロントエンド１１からのリクエストにおけるリクエストのデータと、ブロックチェーンのスマートコントラクト３０から供給されるレスポンスのデータとを、作成した電子契約書を作成したブロックのブロックＩＤ及びこの電子契約書のコントラクトＩＤに対応させて、データベース４０に対して書き込んで記憶させる。

また、データ保存用ＡＰＩ５１は、ブロックチェーンのブロックにハッシュ値を書き込んだ際、このときブロックチェーンノード２１から供給されるブロックＩＤと、このハッシュ値を作成した施工状況データのコントラクトＩＤとに対応させて、当該施工状況データにおいて予め指定されているメタデータをデータベース４０に対して書き込んで記憶させる。

＜処理＃９：維持管理時におけるデータストレージ５０からの情報取得処理＞
ステップＳ９＿１：維持管理者（ユーザ＃３）は、例えば、コントラクトＩＤをユーザ端末におけるＷｅｂブラウザに入力し、このコントラクトＩＤに対応するデータベース４０における履歴を参照する処理を行う。

ステップＳ９＿２：維持管理者は、データベース４０のコントラクトＩＤに対応した履歴の中から、このコントラクトＩＤに対応する電子契約書の施工における施工状況データが記載された処理を行ったブロックのブロックＩＤを抽出する。

ステップＳ９＿３：維持管理者は、コントラクトＩＤ及びブロックＩＤに対応する施工状況データを検索する検索依頼を、ユーザ端末のＷｅｂブラウザを介してストレージ５２に対して送信する。
データストレージ５０において、データ保存用ＡＰＩ５１は、ユーザ端末から供給されるコントラクトＩＤ及びブロックＩＤに対応する施工状況データを、ストレージ５２において検索する。

ステップＳ９＿４：
データ保存用ＡＰＩ５１は、ストレージ５２にコントラクトＩＤ及びブロックＩＤにより検索した施工状況データを、ユーザ端末に対して送信する。
維持管理者は、データストレージ５０から供給される、コントラクトＩＤ及びブロックＩＤに対応する施工状況データを、ユーザ端末の表示画面により閲覧する。

上述したように、維持管理者は、データベース４０におけるコントラクトＩＤに対応するメタデータにより、データストレージ５０において検索する施工状況データのブロックＩＤを抽出することができ、データストレージ５０における施工状況データの検索を容易とすることができる。
また、上述した構成により、データストレージ５０における施工状況データの改竄の有無をブロックチェーンの当該施工状況データのハッシュ値により検出することが可能となるため、建設工事における進捗の管理とともに、施工された後における施工に対する品質及び出来形に対応した構造物の維持管理を行なうトレーサビリティを向上させることができる。

＜処理＃１０＿１：発注者による設計データのデータストレージ５０への書込処理＞
ステップＳ１０：ユーザ＃１（発注者）は、検査に用いる施工箇所の設計図や三次元ＣＡＤ（computer aided design）のデータなどを、ユーザ端末におけるＷｅｂブラウザに入力する。
これにより、検査に用いる施工箇所の設計図や三次元ＣＡＤのデータなどが、Ｗｅｂブラウザを介してデータストレージ５０に対して入力される。

ステップＳ１０＿２：データストレージ５０において、データ保存用ＡＰＩ５１は、発注者のユーザ端末のＷｅｂブラウザから供給される検査に用いる施工箇所の設計図や三次元ＣＡＤのデータなどのハッシュ値Ｈ１を所定のハッシュ関数により作成する。
そして、データ保存用ＡＰＩ５１は、作成した検査に用いる施工箇所の設計図や三次元ＣＡＤのデータのハッシュ値Ｈ１と、施工に対応するコントラクトＩＤとをブロックチェーンノード２１に対して送信する。
ブロックチェーンノード２１は、データ保存用ＡＰＩ５１から供給されるハッシュ値Ｈ１を、コントラクトＩＤに対応付けて所定のブロックに書き込み、このブロックＩＤをデータストレージ５０に対して送信する。

ステップＳ１０＿３：データ保存用ＡＰＩ５１は、発注者のユーザ端末におけるＷｅｂブラウザから入力された、検査に用いる施工箇所の設計図や三次元ＣＡＤのデータなどの実データを、コントラクトＩＤ、及びブロックチェーンノード２１からのブロックＩＤの各々に対応付けて、ストレージ５２に対して書き込んで記憶させる。

また、上述した構成により、データストレージ５０における検査に用いる施工箇所の設計図や三次元ＣＡＤのデータなどの実データの改竄の有無を、ブロックチェーンの当該検査に用いる施工箇所の設計図や三次元ＣＡＤのデータなどの実データのハッシュ値により検出することが可能となるため、検査に用いる施工箇所の設計図や三次元ＣＡＤのデータなどを用いた検査結果の信頼性を向上させることができる。

上述した本実施形態においては、スマートコントラク３０がブロックチェーンに書き込まれた検査結果に基づいて、執行条件データに対応させて、注文者のウォレットから受注者に対するウォレットに対するバリュー（仮想通貨）の移動により対価の支払を行なっている。
しかしながら、スマートコントラクト３０がブロックチェーンに施工状況の検査結果が記載された場合、検査結果が記載されたことを、そのコントラクトＩＤに対応した施工の請負関係における注文者及び受注者のユーザ端末に送信する構成としてもよい。

この場合、注文者は、ユーザ端末から施工の検査結果を対応するブロックチェーンにおいて確認し、施工の受注者に対して対応するコントラクトＩＤの電子契約書の金額に対応して施工の請求書の発行を促す。
そして、注文者は、受注者の発行した請求書に対応して、契約書に記載された金額において施工の対価の支払（支払うバリューとしては、法定通貨、例えば日本銀行券（円）により銀行振込あるいは手形の決済）を行なう。

注文者が、ユーザ端末から対価の支払を行なった金額と、この施工のコントラクトＩＤとを、データストレージ５０に書き込む処理を行なう。
これにより、データ保存用ＡＰＩ５１は、ブロックチェーンノード２１を介して、支払のハッシュ値をトランザクションとしてブロックチェーンに対して書き込み、支払に関する実データをストレージ５２に対して書き込んで記憶させる。

また、スマートコントラクト３０がブロックチェーンに施工状況の検査結果が記載された場合、検査結果が記載されたので、コントラクトＩＤに対応した施工の対価の支払を行なっても良いか否かの確認依頼を、注文者のユーザ端末に送信する構成としてもよい。
この場合、確認依頼の画面に支払を行なうことを許可するボタンが設けられており、施工の検査結果を対応するブロックチェーンにおいて確認し、支払って良い状態であれば、許可するボタンをクリックする。
そして、スマートコントラクト３０は、施工の対価の支払を許可するボタンがクリックされた場合、注文者のウォレットから受注者に対するウォレットに対するバリュー（仮想通貨）の移動により対価の支払を行なう。

図４は、本発明の一実施形態である施工情報管理システムの実用例を示すブロック図である。
図４において、発注者ユーザ端末パソコン１０１＿１は、図３における発注者であるユーザ＃１が使用するユーザ端末に対応しており、Ｗｅｂブラウザのアプリケーションソフトウェアがインストールされている。
注文者ユーザ端末パソコン１０２＿２は、図３における注文者であるユーザ＃２が施工状況データによる検査及び出来形を確認するコンピュータであり、Ｗｅｂブラウザのアプリケーションソフトウェアがインストールされている。

元請ユーザ端末パソコン１０２は、図３における注文者であり受注者であるユーザ＃１（元請）が使用するユーザ端末に対応しており、Ｗｅｂブラウザのアプリケーションソフトウェアがインストールされている。
Ｘ次下請ユーザ端末パソコン１０３は、図３における注文者であり受注者であるユーザ＃１（元請以降における施工を請負う一次下請を含むＸ次下請）が使用するユーザ端末に対応しており、Ｗｅｂブラウザのアプリケーションソフトウェアがインストールされている。

維持管理者ユーザ端末パソコン１０４は、施工を実際に行なった受注者であるユーザ＃３が、記憶部データベース５０１をアクセスする処理を行なう、また施工の状況を示す施工状況データを施工管理システム２２０を介して、記憶部（施工データ用）ストレージ５０２に書き込む処理を行なうコンピュータであり、Ｗｅｂブラウザのアプリケーションソフトウェアがインストールされている。

ブロックチェーンノード２０１の各々は、それぞれがコンピュータ（パーソナルコンピュータ（所謂、パソコン）を含む）あるいはサーバーなどであり、ＰｔｏＰの形態で各々が接続され、ＰｔｏＰネットワーク２００を形成している。このＰｔｏＰネットワーク２００は、図３におけるＰｔｏＰネットワーク２０に対応している。
スマートコントラクト実行用アプリケーションサーバー３０１は、図３におけるアプリケーション１０の機能に対応しており、フロントエンド１１及びスマートコントラクト実行用ＡＰＩ１２の各々の機能を有するアプリケーションソフトウェアがインストールされている。

スマートコントラクトプログラム用端末パソコン３０２は、図３に示すスマートコントラクト３０のアプリケーションソフトウェアのプログラムを生成し、ＰｔｏＰネットワーク２００のブロックチェーンノード２０１に送信する。これにより、ブロックチェーンノード２０１は、生成するブロックチェーンに対して、スマートコントラクト３０を搭載させる。

データベース及びデータストレージアクセス用サーバー３０３は、図３におけるストレージ５２と、データベース４０とにアクセスするサーバーであり、データ保存用ＡＰＩ５１のアプリケーションソフトウェア、及びデータベース４０をアクスするためのアプリケーションソフトウェアがインストールされている。
また、記憶部データベース５０１は、図３におけるデータベース４０に対応している。
記憶部（施工データ用）ストレージ５０２は、図３におけるストレージ５２に対応し、このストレージ５２における施工状況データが書き込まれる記憶部である。
同様に、記憶部（設計データ用）ストレージ５０３は、図３におけるストレージ５２に対応し、このストレージ５２における検査に用いる施工箇所の設計図や三次元ＣＡＤのデータなどが書き込まれる記憶部である。

グラフィック・数値処理実行用アプリケーションサーバー３０４は、図３における品質及び出来形確認用プログラム６１（アプリケーションソフトウェア）がインストールされているサーバーであり、このアプリケーションソフトウェアが起動することにより、図３の出来形確認用プログラム６１の動作が実行される。
ビューワー用サーバー３０５は、図３における結果閲覧用ビューワー６２のアプリケーションソフトウェアがインストールされ、このアプリケーションソフトウェアが起動することにより、図３の結果閲覧用ビューワー６２の動作が実行される。

なお、本発明における図３のアプリケーション１０、スマートコントラクト３０及びデータストレージ５０の機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより、ブロックチェーンを利用した建設工事の施工情報管理を行う処理を行ってもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳ（Operating System）や周辺機器等のハードウェアを含むものとする。また、「コンピュータシステム」は、ホームページ提供環境（あるいは表示環境）を備えたＷＷＷ（World Wide Web）システムも含むものとする。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ（Read Only Memory）、ＣＤ－ＲＯＭ（Compact Disc - Read Only Memory）等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバーやクライアントとなるコンピュータシステム内部の揮発性メモリ（ＲＡＭ（Random Access Memory））のように、一定時間プログラムを保持しているものも含むものとする。

また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように情報を伝送する機能を有する媒体のことをいう。また、上記プログラムは、前述した機能の一部を実現するためのものであっても良い。さらに、前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であっても良い。

１０…アプリケーション １１…フロントエンド １２…スマートコントラクト実行用ＡＰＩ ２０…ＰｔｏＰネットワーク ２１…ブロックチェーンノード ３０…スマートコントラクト ４０…データベース ５０…データストレージ ５１…データ保存用ＡＰＩ ５２…ストレージ ６０…検査システム ６１…品質及び出来形確認用プログラム ６２…結果閲覧用ビューワー １０１＿１…発注者ユーザ端末パソコン １０１＿２…注文者ユーザ端末パソコン １０２…元請ユーザ端末パソコン １０３…Ｘ次下請ユーザ端末パソコン １０４…維持管理者ユーザ端末パソコン ３０２…スマートコントラクトプログラム用端末パソコン ３０１…スマートコントラクト実行用アプリケーションサーバ ３０４…グラフィック・数値処理実行用アプリケーションサーバー ３０５…ビューワー用サーバー

Claims (5)

1. 建設工事における施工の各々の重層の請負い関係の注文者と受注者との間における電子契約書に基づき、前記施工の状況を示す施工状況データの管理を行う施工情報管理システムであり、
   ブロックチェーンに実装されており、当該ブロックチェーンに前記電子契約書を作成するスマートコントラクトと、
   前記電子契約書を識別するコントラクトＩＤに対応させて、前記施工の状況を示す施工状況データをストレージに書き込んで記憶させ、当該施工状況データの第１ハッシュ値を前記コントラクトＩＤに対応させて前記ブロックチェーンに書き込むデータ保存用アプリケーションプログラムインターフェース（ＡＰＩ）と、
   を備え、
   前記スマートコントラクトが、
   前記重層において層毎の請負いの前記電子契約書の間における前記コントラクトＩＤの関連付を行うことにより、当該重層の請負い関係における前記電子契約書の示す契約のツリー構造を形成する
   ことを特徴とする施工情報管理システム。
2. 前記電子契約書に記載された検査ルールに対応し、前記施工状況データの検査を行ない執行条件データとして、前記コントラクトＩＤに対応させて前記ブロックチェーンに書き込む検査システムをさらに含む
   ことを特徴とする請求項１に記載の施工情報管理システム。
3. 前記検査システムが、前記施工状況データを用いて施工に対する検査を行う際、前記ストレージから読み出した前記施工状況データの第２ハッシュ値を求め、当該第１ハッシュ値と前記第１ハッシュ値とを比較し、前記施工状況データの改竄の有無を判定する
   ことを特徴とする請求項２に記載の施工情報管理システム。
4. 前記スマートコントラクトが、
   前記電子契約書の執行条件における支払ルールにより、前記施工状況データに応じた前記施工の対価を支払う
   ことを特徴とする請求項１から請求項３のいずれか一項に記載の施工情報管理システム。
5. 建設工事における施工の各々の重層の請負い関係の注文者と受注者との間における電子契約書に基づき、前記施工の状況を示す施工状況データの管理を行う施工情報管理方法であり、
   スマートコントラクトが、ブロックチェーンに実装されており、当該ブロックチェーンに前記電子契約書を作成する電子契約書作成過程と、
   データ保存用アプリケーションプログラムインターフェース（ＡＰＩ）が、前記電子契約書を識別するコントラクトＩＤに対応させて、前記施工の状況を示す施工状況データをストレージに書き込んで記憶させ、当該施工状況データの第１ハッシュ値を前記コントラクトＩＤに対応させて前記ブロックチェーンに書き込む施工状況データ書込過程と、
   を含み、
   前記電子契約書作成過程において、
   前記スマートコントラクトが、前記重層において層毎の請負いの前記電子契約書の間における前記コントラクトＩＤの関連付を行うことにより、当該重層の請負い関係における前記電子契約書の示す契約のツリー構造を形成することを特徴とする施工情報管理方法。

Images