特開 2023-107825 ブロックチェーンを利用するシステム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2023107825

(43)【公開日】2023-08-03

(54)【発明の名称】ブロックチェーンを利用するシステム

(51)【国際特許分類】

   G06Q 10/00 20230101AFI20230727BHJP

   G06F 21/64 20130101ALI20230727BHJP

【ＦＩ】

G06Q10/00

G06F21/64

【審査請求】有

【請求項の数】3

【出願形態】ＯＬ

(21)【出願番号】P 2023090985

(22)【出願日】2023-06-01

(62)【分割の表示】P 2019112105の分割

【原出願日】2019-06-17

(71)【出願人】

【識別番号】000155469

【氏名又は名称】株式会社野村総合研究所

(74)【代理人】

【識別番号】100076428

【弁理士】

【氏名又は名称】大塚 康徳

(74)【代理人】

【識別番号】100115071

【弁理士】

【氏名又は名称】大塚 康弘

(74)【代理人】

【識別番号】100112508

【弁理士】

【氏名又は名称】高柳 司郎

(74)【代理人】

【識別番号】100116894

【弁理士】

【氏名又は名称】木村 秀二

(74)【代理人】

【識別番号】100130409

【弁理士】

【氏名又は名称】下山 治

(74)【代理人】

【識別番号】100134175

【弁理士】

【氏名又は名称】永川 行光

(74)【代理人】

【識別番号】100177390

【弁理士】

【氏名又は名称】大出 純哉

(72)【発明者】

【氏名】大塚 紳一郎

(57)【要約】

【課題】ライブラリアンに代表される業務ワークフローベースの仕事を担う事務担当者の機能を、ブロックチェーンを用いたシステムで実現することにより省人化を図りつつ、悪意の開発者による改ざん行為を抑制または除去する。
【解決手段】システムは、開発されたプログラムの本番環境へのリリースを管理するシステムであって、ブロックチェーンが実装された複数のサーバと、プログラムのリリースに関するイベントを検出する手段と、イベントを検出したときのプログラムの一意性を担保する一意性情報と、検出されたイベントを特定する特定情報と、を含む、ブロックチェーンのブロックを生成する手段と、を備える。
【選択図】図１

【特許請求の範囲】

【請求項1】

ブロックチェーンが実装された複数の仮想サーバを備えるシステムであって、
複数の仮想サーバによる多数決を用いた判定結果に応じて、前記システムの稼働の状況を示す情報を含む、ブロックチェーンのブロックを生成する手段を備えるシステム。

【請求項2】

前記生成する手段は、前記多数決の結果を利用して仮想サーバの障害またはリソースの過不足を検出した場合にブロックを生成する請求項１に記載のシステム。

【請求項3】

前記システムは監査用のシステムであり、
前記システムは、
前記システムで実行される監査関連プログラムの正当性を示す情報を含む、ブロックチェーンのブロックを生成する手段をさらに備える請求項１または２に記載のシステム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ブロックチェーンを利用するシステムに関する。

【背景技術】

【0002】

大規模システムの開発においては、完成した多数のプログラムモジュールを本番環境に移設する作業が不可欠であり、これに多くの手間と時間を取られることはもちろんであるが、新旧バージョンの取り違い等、様々な人為的ミスの温床ともなっていた。このような状況を改善するために、本出願人は特許文献１に記載されるプログラムリリース管理システムを提案した。

【0003】

特許文献１に記載のプログラムリリース管理システムでは、承認者は承認者端末からネットワーク接続ストレージの開発側領域にアクセスし、開発済みのプログラムファイルに不正なロジックが混入されていないこと等を確認し、ライブラリアンにプログラムファイルの移送に関し承認を与える。この際、承認者はプログラムファイルのファイル名やファイルサイズ、タイムスタンプ等の特定情報をライブラリアンに伝達する。

【0004】

これを受けたライブラリアンは転送サーバにアクセスし、開発側領域に格納されているプログラムファイルの一覧情報をライブラリアン端末のディスプレイ上でチェックし、ファイル名やファイルサイズ、タイムスタンプに基づいて承認の下りたプログラムファイルを特定し、その移送を求めるコマンドを発行する。

【0005】

このように、承認者が開発側領域に格納されたプログラムファイルの特定情報をライブラリアンに伝達し、ライブラリアンがこの情報に基づいて転送対象となるプログラムファイルを選択することにより、承認者による承認直後から本番側領域への転送完了までの僅かな間に、開発側領域に格納されたプログラムファイルに対し、開発者がファイルサイズやタイムスタンプの変更を伴う改ざん行為を行うことを牽制することができる。

【0006】

ここでライブラリアンとは、開発者や承認者の属する部署からは完全に独立した、利害関係の無い第三者機関に属する専門職を意味している。特許文献１に記載のプログラムリリース管理システムでは、組織内にライブラリアンを確保し、プログラムの改ざんチェックや、本番環境への適用により内部統制を担保している。

【先行技術文献】

【特許文献】

【0007】

【特許文献1】特許第５２５３３３６号

【特許文献2】特開２０１９－０２９０１９号公報

【発明の概要】

【発明が解決しようとする課題】

【0008】

近年、システムの大規模化、複雑化が進み、またモジュール更新の頻度も高まっており、それに伴ってライブラリアンの作業量が増大している。書類確認においては複数のライブラリアンでの複眼チェックが行われるので人員が必要となり、その人員稼動率を向上させるためのチーム化がなされるなど、ライブラリアン組織の構成も大きくなってきている。監査時には監査人が企業を訪問し、機密部屋に入って紙面で証跡を確認する。この監査人への対応、紙面の提供などもライブラリアンの仕事である。そして、ライブラリアンの仕事内容は比較的単純であるが、ミスは許されないといったことから、人員のモチベーション維持も一苦労である。

【0009】

そこで、ライブラリアンをシステム化することが検討されている。特許文献１には、ライブラリアンによる書類の突き合わせ及び転送依頼コマンドの発行を自動化することが記載されているが、結局最終の確認はライブラリアンによりなされるので、ライブラリアンの支援に留まっている。ライブラリアンをシステムで置き換えるという概念は、特許文献１には記載されていない。

【0010】

ライブラリアンをシステムで置き換えた場合、人の目による監視が無くなる分、事前であれ事後であれ、セキュリティを強化する施策を講じる必要がある。例えば、承認者による承認直後からシステムによる本番側領域への転送完了までの間に、開発側領域に格納されたプログラムに対し悪意の開発者が改ざん行為を行う可能性があることへの対応が必要である。

【0011】

システムが転送を指示する前に、転送対象のプログラムのファイルサイズやハッシュ値を、ログに残されている当該ファイルの開発完了時または承認時のファイルサイズやハッシュ値と比較することによりセキュリティを担保することが考えられる。しかしながら、悪意の開発者がログまでも書き換えてしまうと、上記の改ざん行為をシステムが検知することは困難である。

【0012】

本発明はこうした課題に鑑みてなされたものであり、その目的は、ライブラリアンの機能をシステムで実現することにより省人化を図りつつ、悪意の開発者による改ざん行為を抑制または除去できるプログラムリリース管理技術の提供にある。

【課題を解決するための手段】

【0013】

本発明のある態様は、システムに関する。このシステムは、ブロックチェーンが実装された複数の仮想サーバを備えるシステムであって、複数の仮想サーバによる多数決を用いた判定結果に応じて、前記システムの稼働の状況を示す情報を含む、ブロックチェーンのブロックを生成する手段を備える。

【0014】

なお、以上の構成要素の任意の組み合わせや、本発明の構成要素や表現を装置、方法、システム、コンピュータプログラム、コンピュータプログラムを格納した記録媒体などの間で相互に置換したものもまた、本発明の態様として有効である。

【発明の効果】

【0015】

本発明によれば、ライブラリアンに代表される業務ワークフローベースの仕事を担う事務担当者の機能を、ブロックチェーンを用いたシステムで実現することにより省人化を図りつつ、悪意の開発者による改ざん行為を抑制または除去できる。

【図面の簡単な説明】

【0016】

【図1】第１の実施の形態に係るライブラリアンシステムを含むプログラム管理システムの全体構成を示す模式図である。

【図2】図１の内部サーバのハードウエア構成図である。

【図3】図１の内部サーバの機能および構成を示すブロック図である。

【図4】図３の台帳保持部の一例を示すデータ構造図である。

【図5】図３のユーザ情報保持部の一例を示すデータ構造図である。

【図6】図１のライブラリアンシステムにおける一連の処理の流れを示すチャートである。

【図7】開発者端末のディスプレイに表示される登録画面の代表画面図である。

【図8】承認画面の代表画面図である。

【図9】管理画面の代表画面図である。

【図10】監査支援部により提供される選択画面の代表画面図である。

【図11】リリース申請回数確認画面の代表画面図である。

【図12】本番適用遅延回数確認画面の代表画面図である。

【図13】開発者変更回数確認画面の代表画面図である。

【図14】省人化の効果を表すイメージ図である。

【図15】第２の実施の形態に係る監査システムの模式図である。

【図16】サーバダウン時に不正な作業が行われていないことの証明（要件１）に関する処理の流れを示すチャートである。

【図17】発砲タイミングの一例を示す図である。

【図18】ＣＰＵ高騰によるリソース不足の解消の正当性担保（要件１）に関する処理の流れを示すチャートである。

【図19】ＣＰＵ高騰によるリソース不足の解消後の縮退の正当性担保（要件１）に関する処理の流れを示すチャートである。

【図20】図１５の稼働証明台帳の一例を示すデータ構造図である。

【図21】監査に関連するプログラムが稼働中に不正に改ざんされていないことの証明（要件２）に関する処理の流れを示すチャートである。

【図22】図１５の正当性証明台帳の一例を示すデータ構造図である。

【発明を実施するための形態】

【0017】

以下、各図面に示される同一または同等の構成要素、部材、処理には、同一の符号を付するものとし、適宜重複した説明は省略する。また、各図面において説明上重要ではない部材の一部は省略して表示する。

【0018】

ブロックチェーンとも呼ばれる分散管理台帳技術が知られている。ブロックチェーンは、ノードにデータをブロックという単位でまとめて記録し、同じブロック情報を分散して管理する技術である。ブロックが時系列でつながっていることから、「ブロックチェーン」と呼ばれる。

【0019】

ブロックチェーンには主に以下の５つの特徴がある。
１．全員で情報共有
ブロックチェーンでつながっている、すべてのノードは、同じデータを保存する仕組みになっている。ブロックチェーンにデータが投入されると、初めにどのノードがブロックを追加するか、が決まる。どのように決まるかは、ブロックチェーンの設計によるが、一般的に、計算力に応じて決めるproof of work（PoW）、特定の管理者グループによって決めるPBFT等がある。次にブロックを追加したノードが、他のすべてのノードにブロックを送る。全ノードがブロックの内容を検証したうえで、問題なければ、それぞれのノードにブロックが追加される。その結果、全ノードに同じデータが保存されることとなる。問題があれば、ブロックは消え、最終的に問題のないブロックのみが追加される仕組みになっている。つまり、検証された正しいデータのみがブロックとして保存されることになる。２．無停止(ゼロダウンタイム)
従来のシステムでは、リーダの役割を持つコンピュータが存在したが、ブロックチェーンには、中央集権的なノードがないことが多い。ただし、一部のブロックチェーンでは、中心的役割を持ったノードが存在する。すべてのノードが平等につながっていて、全く同じ機能を有している。したがって、一部のノードが故障しても、他のノードが正常であれば、ブロックチェーン全体が停止することがなく、すべての処理が続行される。
３．改ざん不可能
ブロックチェーンでは、ブロックは時系列順に追加される。そして、過去のデータを改ざん（変更）すると、後に続く全データを変更しないと改ざんが成立しない。やりとりの妥当性が全ノードによって検証される。すなわち、ブロックには１つ前のブロックの情報を含んだハッシュ値が格納される。少しでもデータが異なると、ハッシュ値は全く異なる値となり、以降のブロックすべてを改ざんしないと整合性が取れない仕組みとなっている。また、５１％以上のノードが協調して改ざんを実施しない限り、改ざんしたデータが正しいブロックとして保存されない。このようなことから事実上、改ざんは不可能である。
４．トレーサビリティ
ブロックチェーンでは、全ノードによって正しいと認められた、改ざん（変更）が不可能なデータがブロックとして保存されている。また、冗長化によりデータが失われることもない。加えて、時系列順に格納されているため、過去にさかのぼってデータを参照することができ、高いトレーサビリティがある。
５．低コスト
データベース製品やクラスタ製品が不要であり、低コストで構築が可能である。

【0020】

本発明者は、上記のブロックチェーンの特徴に鑑み、ライブラリアンを置き換えるためのシステムとブロックチェーンとの親和性が高いことを独自に見出した。特に、本発明者は、開発されたプログラムの本番環境へのリリースに係る監査の記録をブロックチェーンで管理することにより、当該システムに求められる、より高度なセキュリティを実現できることを見出した。監査の記録がブロックチェーンで残されることにより、悪意の開発者はその記録を改ざんすることができない。したがって、仮に承認後に改ざんが行われたとしても、システムはブロックチェーン上の記録を参照することで、その改ざんを容易に検知することができる。

【0021】

（第１の実施の形態）
図１は、第１の実施の形態に係るライブラリアンシステム１００を含むプログラム管理システム１０の全体構成を示す模式図である。プログラム管理システム１０は、ライブラリアンシステム１００と、開発者が操作する開発者端末１２と、承認者が操作する承認者端末１４と、開発者が操作するリリース端末１８と、開発中の業務プログラムを保持、管理する開発機２０と、代理サーバ（プロキシサーバ）２２と、転送サーバ２４と、ネットワーク接続ストレージ（ＮＡＳ）２６と、アクセス監視サーバ２８と、ファイアウォール３０と、リリースサーバ３２と、開発済の業務プログラムがインストールされる本番機３４とを備える。リリース端末１８はガラス張りのリリース端末室４９内に設置されている。

【0022】

ネットワーク接続ストレージ２６は、制御部３６と、開発側領域３８と、本番側領域４０と、を備える。制御部３６は、ネットワーク接続ストレージ２６のＣＰＵが、ＲＯＭやＲＡＭに格納されたＯＳ及び制御プログラムに従って動作することにより、実現される。開発側領域３８及び本番側領域４０は、ネットワーク接続ストレージ２６に搭載されたハードディスクや揮発性メモリや不揮発性メモリなどからなり、制御部３６によって論理的に仕切られている。開発側領域３８は、制御部３６を介して開発セグメント４２と接続される。また、本番側領域４０は、制御部３６を介してＤＭＺ（DeMilitarized Zone／非武装地帯）セグメント４４されている。

【0023】

ライブラリアンシステム１００はライブラリアンセグメント４１上に設置されている。
開発者端末１２、承認者端末１４、および開発機２０は、開発セグメント４２上に設置されている。
代理サーバ２２、転送サーバ２４、およびアクセス監視サーバ２８は、ＤＭＺセグメント４４上に設置されている。
リリース端末１８は、本番アクセスセグメント４８上に設置されている。
リリースサーバ３２及び本番機３４は、本番セグメント５１上に設置されている。

【0024】

業務プログラムの開発者は、開発者端末１２を用いて業務プログラムのコーディングを行い、開発機２０上で単体テストや結合テストを完了する。開発者は、テスト等が完了した業務プログラムのオブジェクトファイルを、ライブラリアンシステム１００とのやりとりを介してネットワーク接続ストレージ２６の開発側領域３８に格納する。

【0025】

つぎに開発者は、ライブラリアンシステム１００とのやりとりを介して、直属の上司等である承認者に対して、開発済の業務プログラムをネットワーク接続ストレージ２６の開発側領域３８に格納した事実を伝達する。これを受けた承認者は、承認者端末１４からネットワーク接続ストレージ２６にアクセスし、開発側領域３８に格納された業務プログラムを読み出す。

【0026】

つぎに承認者は、この業務プログラムの中身をチェックし、仕様書通りの機能を備えていることや、規定のテスト項目を全てクリアしていること、不正なモジュールが含まれていないことを確認する。この結果、問題がないと判断した承認者は、ライブラリアンシステム１００とのやりとりを介して開発者に対して承認した旨を伝達する。

【0027】

ライブラリアンシステム１００は、業務プログラムの登録や承認などのイベントが発生するたびに、そのときの業務プログラムのハッシュ値や位置やパスなどのスナップショットデータを取得し、取得したデータをブロックチェーンで管理する。

【0028】

ライブラリアンシステム１００は周期的に、例えば５分に１回などの所定の時間間隔で、承認されたが移動されていない業務プログラムを特定する。ライブラリアンシステム１００は、特定された業務プログラムの現在のハッシュ値と、ブロックチェーンに保持されている当該業務プログラムのハッシュ値と、が一致していることを確認した後、業務プログラムの転送依頼を行う。

【0029】

ライブラリアンシステム１００は代理サーバ２２にアクセスし、転送依頼コマンドを発行する。この転送依頼コマンドには、ライブラリアンシステム１００のＩＰアドレス、転送対象となる業務プログラムのファイル名、格納場所が含まれる。

【0030】

これを受けた代理サーバ２２は、転送依頼コマンドに含まれるＩＰアドレスが、予め設定されたライブラリアンシステム１００のＩＰアドレスと一致することをチェックした後、転送依頼コマンドを転送サーバ２４に転送する。

【0031】

代理サーバ２２に対しては、ライブラリアンシステム１００のみが認証可能となり、承認者端末１４および承認者端末１４からアクセスしても代理サーバ２２によって認証不可と判定される。

【0032】

転送依頼コマンドを受け取った転送サーバ２４は、転送依頼コマンドに含まれるＩＰアドレスが、予め設定された代理サーバ２２のＩＰアドレスと一致することをチェックした後、転送依頼コマンドをネットワーク接続ストレージ２６に発行する。

【0033】

これを受けたネットワーク接続ストレージ２６の制御部３６は、この転送コマンドに含まれるＩＰアドレスが、予め設定された転送サーバ２４のＩＰアドレスと一致することをチェックした後、該当の業務プログラムを開発側領域３８から本番側領域４０に転送する。転送完了後、転送完了通知がネットワーク接続ストレージ２６→転送サーバ２４→代理サーバ２２→ライブラリアンシステム１００へと送信される。

【0034】

本番側領域４０に一旦転送された業務プログラムに対しては、後述のようにリリースサーバ３２からの転送コマンド以外は受け付けられず、開発者端末１２や承認者端末１４、ライブラリアンシステム１００からのアクセスは制御部３６によって一切拒絶される。このため、悪意の開発者が本番側領域４０に保持されるリリース前の業務プログラムに不正なモジュールを組み込むことはできない。

【0035】

プログラム管理システム１０における業務プログラムのリリース手順を説明する。
開発者は、リリース端末室４９に移動し、そこに設置されたリリース端末１８からアクセス監視サーバ２８にアクセスし、リリース依頼コマンドを発行する。これを受けたアクセス監視サーバ２８は、リリース依頼コマンドに含まれるＩＰアドレスが予め設定されたリリース端末１８のＩＰアドレスと一致することをチェックした後、リリース依頼コマンドをリリースサーバ３２に転送する。アクセス監視サーバ２８はリリース端末１８との間におけるデータのやり取りを、ログファイルに記録する。

【0036】

アクセス監視サーバ２８からのリリース依頼コマンドを受けたリリースサーバ３２は、リリース依頼コマンドに含まれるＩＰアドレスが、予め設定されたアクセス監視サーバ２８のＩＰアドレスと一致することをチェックした後、該当の業務プログラムの転送依頼をネットワーク接続ストレージ２６に送信する。

【0037】

これを受けたネットワーク接続ストレージ２６の制御部３６は、プログラム転送依頼に含まれるＩＰアドレスが予め設定されたリリースサーバ３２のＩＰアドレスと一致することをチェックした後、該当の業務プログラムを本番側領域４０から取り出し、リリースサーバ３２に転送する。

【0038】

これを受けたリリースサーバ３２は、本番機３４の予め決められたディレクトリに、業務プログラムを転送する。この結果、本番機３４に対する業務プログラムのリリースが完了する。この後、リリースサーバ３２からライブラリアンシステム１００に、リリース完了通知が送信される。

【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】

図９は、管理画面５１０の代表画面図である。管理画面５１０は、業務プログラムの番号および名前が表示されるプログラム特定情報表示領域５１２と、業務プログラムのステータスが表示されるステータス表示領域５１４と、を有する。ステータス表示領域５１４には、イベントごとに、イベントを検出したか否か、イベントを検出した時刻、行為者、イベントを検出したときの業務プログラムのハッシュ値、が表示される。図９の例では、承認イベントを検出したときのハッシュ値と転送イベントを検出したときのハッシュ値とが異なることから、承認完了から転送が発生するまでの期間に業務プログラムが書き換えられたことを検知することができる。

【0073】

監査においては、ある業務プログラムについて、登録、承認、転送、リリースのフローに抜けが無いことがひとつの重要な監査指標である。ライブラリアンシステム１００ではブロックチェーンのトレーサビリティを活かして図９のような一覧性の高い画面を提供できるので、監査を効率化できる。さらに、監査サーバ１０４がライブラリアンシステム１００に含まれる場合は、監査人が企業（プログラム管理システム１０を管理する主体）を訪問しなくても、図９に示されるような管理画面５１０を自己の端末のディスプレイに表示できるので、さらなる効率化が図られる。

【0074】

上記の通り、監査サーバ１０４を含むライブラリアンシステム１００により、監査人が監査対象の企業へ来社する必要が無くなり、監査の負荷低減を行うことができる。さらに、監査支援部１４６が、台帳保持部１３０に保持されるブロックを参照することによって、業務プログラムのリリースに関する統計情報を表示する各種画面を生成し、監査サーバ１０４のディスプレイに表示させることによって、さらに効率的かつ効果的な監査を実現できる。

【0075】

従来、監査は、何万本となる監査対象プログラムの中から抜き打ちで、その内部統制が確保できているかどうか確認を行う場合が多い。しかしながら、これでは統制が担保されているかどうかの確認確度を一定のレベルに保つことは難しい。内部統制の場合、統制が懸念されるのは以下のような業務プログラム（またはモジュール）である。
●一定期間内に、同一開発者からの申請回数が非常に多い場合。
●本番適用が滞りがち（例えば、１週間以上経過しても、稼動しない。もしくは本番稼動する前に再度のリリース申請）。
●同一業務プログラムであるにも関わらず、一定期間内に開発者がたびたび変更される。

【0076】

ライブラリアンシステム１００では、ブロックチェーンのトレーサビリティを用いることで、上述のような特性を統計的な数字として記録することができる。具体的には、監査支援部１４６は、１日おきに、上記の統計的な数字を業務プログラムごとに積算する。この積算は、１年間を通して行われる。監査は毎年行われるからである。監査時においては、監査支援部１４６が監査人のＰＣにその情報を含む支援画面を表示することで、統制が担保されているかどうかの確認確度を一定のレベルに保つことができる。

【0077】

図１０は、監査支援部１４６により提供される選択画面５１６の代表画面図である。選択画面５１６は、監査人に、表示する支援画面を選択させるための画面であり、リリース申請回数確認ボタン５１８と、本番適用遅延回数確認ボタン５２０と、開発者変更回数確認ボタン５２２と、を有する。

【0078】

選択画面５１６においてリリース申請回数確認ボタン５１８が押し下げられると、監査支援部１４６は、監査人のＰＣのディスプレイにリリース申請回数確認画面５２４を表示させる。図１１は、リリース申請回数確認画面５２４の代表画面図である。

【0079】

選択画面５１６において本番適用遅延回数確認ボタン５２０が押し下げられると、監査支援部１４６は、監査人のＰＣのディスプレイに本番適用遅延回数確認画面５２６を表示させる。図１２は、本番適用遅延回数確認画面５２６の代表画面図である。

【0080】

選択画面５１６において開発者変更回数確認ボタン５２２が押し下げられると、監査支援部１４６は、監査人のＰＣのディスプレイに開発者変更回数確認画面５２８を表示させる。図１３は、開発者変更回数確認画面５２８の代表画面図である。

【0081】

上述の実施の形態において、保持部の例は、ハードディスクや半導体メモリである。また、本明細書の記載に基づき、各部を、図示しないＣＰＵや、インストールされたアプリケーションプログラムのモジュールや、システムプログラムのモジュールや、ハードディスクから読み出したデータの内容を一時的に記憶する半導体メモリなどにより実現できることは本明細書に触れた当業者には理解される。

【0082】

本実施の形態に係るライブラリアンシステム１００によると、これまでライブラリアンが人手で行っていた作業をライブラリアン機能部１３６が自動で行うので、省人化を図ることができる。そして、セキュリティの担保に関しては、イベントごとに生成されるスナップショットデータをブロックチェーンで管理することで、非改ざん性およびトレーサビリティを併せ持つ証跡を提供することができる。そして、監査人もブロックチェーンに参加することで、監査を効率化することができる。

【0083】

図１４は、省人化の効果を表すイメージ図である。特許文献１に記載されるシステムを用いる場合、図１４の左側に示すように比較的大きなライブラリアン組織が必要であった。これに対して、本実施の形態に係るライブラリアンシステム１００を採用した場合、ライブラリアンシステム１００の管理者が１名いればよく（図１４の右側）、後はライブラリアンとしての業務、セキュリティの担保、監査人への対応など全てライブラリアンシステム１００が自動で対応する。

【0084】

第１の実施の形態では、ライブラリアンシステム１００において、イベントごとに業務プログラムのスナップショットデータを取得して、そのスナップショットデータのフローをブロックチェーン化する場合を説明した。この技術的思想はＪ－ＳＯＸ法対応のプログラムリリース管理システムに適用可能であり、さらには、業務ワークフローベースで仕事をしている事務処理全般にも適用可能である。

【0085】

（第２の実施の形態）
第１の実施の形態では、ブロックチェーンのトレーサビリティを利用して監査への対応を効率化することを説明した。第２の実施の形態では、監査システムとしての完全性を担保する機能の実装を説明する。

【0086】

第１の実施の形態のライブラリアンシステム１００は監査システムとも言いうるものである。このように監査をシステム化する際の重要な要件は以下の２つである。
要件１．サーバダウン時に不正な作業が行われていないことの証明
障害等により、サーバが停止した際に、復旧作業にあわせて不正な操作をしていないかなどの証明が必要である。従来では、作業者を、利害関係の無い第三者組織にするなど、組織面での統制をふまえた担保をしていた。
要件２．監査に関連するプログラムが稼働中に不正に改ざんされていないことの証明
監査を統括するプログラムが稼働中に不正に書き換えられていないかといった証明が必要である。従来では、定期的にプログラムコードを印刷して監査時に証明していた。

【0087】

従来では、上記２つの要件を充たすことの証明は基本的に書面の提出により行われており、多くの手間がかかっている。そこで、本実施の形態では、ブロックチェーンを採用する監査システムが自らの正常稼働記録を自らのブロックチェーンの台帳に記録することで、これらを証明する。すなわち、自らの正常稼働記録を改ざん不可能なブロックチェーンで証明する。

【0088】

図１５は、第２の実施の形態に係る監査システム８００の模式図である。監査システム８００は、第１の実施の形態で説明した業務プログラムのリリース作業の監査などの監査を行い、その記録を管理するシステムである。監査システム８００は、ブロックチェーンが実装された複数（図１５の例では５つ）のサーバ８０２、８０４、８０６、８０８、８１０を備える。

【0089】

第２の実施の形態では、ブロックチェーンにおいて複数の台帳の管理が可能であることを利用する。監査システム８００は、それぞれがブロックチェーンのプロトコルにしたがい管理される３つの台帳を備える。３つの台帳は、（１）メインの台帳である監査記録の台帳（監査台帳８１２という）と、（２）サーバの稼働証明記録の台帳（稼働証明台帳８１４という）と、（３）監査関連プログラムの正当性証明記録の台帳（正当性証明台帳８１６という）と、からなる。監査台帳８１２は、例えばＪ－ＳＯＸ法に準拠するための情報を保持する台帳であり、第１の実施の形態の台帳保持部１３０に対応してもよい。稼働証明台帳８１４は、監査システム８００自らの稼働の正常性証明情報を保持する。正当性証明台帳８１６は、主要機能の非改ざん証明情報を保持する。

【0090】

監査システム８００は一台のサーバ装置上に構築される複数の仮想サーバにより構成される。すなわち、複数のサーバ８０２、８０４、８０６、８０８、８１０のそれぞれは仮想サーバである。監査システム８００では後述の通りサーバ間の多数決を用いるので、監査システム８００のブロックチェーンに参加する仮想サーバの数は３を最小とし奇数とする。図１５の例では５である。サーバの仮想化は、コンピュータのリソース（ＣＰＵ、メモリ、ネットワークインタフェース、記録装置など）を抽象化、プール化して、１つの物理サーバ上で複数の仮想サーバを動作可能とする公知の技術である。監査システム８００の仮想サーバはこの公知のサーバ仮想化技術を用いて実現される。

【0091】

サーバの仮想化において、物理リソースはハイパーバイザによって管理され、抽象化される。仮想サーバの各ＯＳには仮想リソースが割り当てられる。したがって、ソフトウエアにより実行される比較的簡単な作業により、仮想サーバを削除したり複製したりすることができる。

【0092】

図１６は、サーバダウン時に不正な作業が行われていないことの証明（要件１）に関する処理の流れを示すチャートである。監査システム８００のサーバ８１０は、所定の発砲タイミングで、他のサーバ８０２、８０４、８０６、８０８に対して生死の確認を行う（Ｓｔｅｐ１）。発砲タイミングの具体例については後述する。「発砲」は複数のサーバに情報を実質的に同時にまたは順番に送信することである。

【0093】

他のサーバ８０２、８０４、８０６、８０８の全てが正常に応答した場合、確認元のサーバ８１０は次のサーバ８０２に処理を渡す。次のサーバ８０２はＳｔｅｐ１の生死確認を行う。このように生死確認を順番に行い、全て正常のまま一周すると、監査システム８００はそのサイクルが終了した時点で監査システム８００の正常性を稼働証明台帳８１４に記録し、次のサイクルに移行する。

【0094】

Ｓｔｅｐ１の生死の確認に対して応答しないサーバ８０４があった場合、または所定時間（例えば３秒）まっても返事が無い場合、確認元のサーバ８１０は生死監視プログラムを停止し、他のサーバ８０２、８０４、８０６、８０８のうち応答が無かったサーバ８０４以外のサーバ８０２、８０６、８０８に対してサーバ回復依頼を発砲する（Ｓｔｅｐ２）。

【0095】

Ｓｔｅｐ２で送信されたサーバ回復依頼を受信したサーバ８０２は、自分以外のサーバ８０４、８０６、８０８、８１０に対して生死の確認を行う（Ｓｔｅｐ３）。当該確認に対して全てのサーバ８０４、８０６、８０８、８１０が応答した場合（応答が無いサーバが無い場合）、サーバ８０２は回復作業の否決を依頼元のサーバ８１０に返却または送信する。当該確認に対して応答が無いサーバ８０４を発見した場合、サーバ８０２は、回復作業承認と応答が無いサーバ８０４のサーバ名とを依頼元のサーバ８１０に返却する。「返却」は、返送、送信とも言い換えることができる。

【0096】

依頼元のサーバ８１０は、依頼先のサーバ８０２、８０６、８０８からの返事を集計する（Ｓｔｅｐ４）。この集計の際の集計対象は、依頼元のサーバ８１０が発見した障害の疑われる（応答が無かった）サーバ８０４のみとする。集計の結果、多数決で否決された場合、依頼元のサーバ８１０は回復作業を取りやめ、誤検知として扱い、生死監視プログラムを再開する。集計の結果、多数決で可決された場合、依頼元のサーバ８１０は回復作業を開始する。

【0097】

Ｓｔｅｐ５の回復作業は以下のフローで行われる。
（１）依頼元のサーバ８１０は、特定した障害の疑われるサーバ８０４をブロックチェーンから切り離し、削除する。依頼元のサーバ８１０は、切り離し時刻と構成サーバ台数と切り離したサーバ名と理由（＝障害切り離し）と状態（＝異常）とを含むブロックを稼働証明台帳８１４に追加する。
（２）依頼元のサーバ８１０は、自ら（サーバ８１０）の仮想マシンの複製を生成し、生成されたサーバ８１８のサーバ名を削除したサーバ８０４のサーバ名とする。
（３）サーバの複製が完了すると、依頼元のサーバ８１０は、生成されたサーバ８１８をブロックチェーンのネットワークに参加させる。依頼元のサーバ８１０は、回復時刻と構成サーバ台数と生成されたサーバ名（＝切り離したサーバ名）と理由（＝回復完了）と状態（＝異常）とを含むブロックを稼働証明台帳８１４に追加する。
（４）依頼元のサーバ８１０は、生死監視プログラムを、現在時刻に最も近い時刻から再開させる。

【0098】

図１７は、発砲タイミングの一例を示す図である。構成サーバ数に応じて１分間に繰り返すサイクル数が異なる。例えば、構成サーバ数が３のときは１分間に３サイクル繰り返すが、構成サーバ数が７のときは１分間に１サイクルとなる。

【0099】

図１８は、ＣＰＵ高騰によるリソース不足の解消の正当性担保（要件１）に関する処理の流れを示すチャートである。監査システム８００のサーバ８１０は、毎秒自らのＣＰＵおよびメモリの利用率を確認する（Ｓｔｅｐ１）。他のサーバ８０２、８０４、８０６、８０８も同様な確認を行う。全てのサーバ８０２、８０４、８０６、８０８、８１０において、ＣＰＵの利用率がしきい値すなわち９０％未満であり、かつメモリの利用率が９０％未満である状態が１分間継続した場合、監査システム８００はその１分間のサイクルが終了した時点で監査システム８００の正常性を稼働証明台帳８１４に記録し、次のサイクルに移行することで繰り返し確認を継続する。

【0100】

サーバ８１０のＣＰＵの利用率およびメモリの利用率の少なくともひとつが９０％以上である状態が２分間継続した場合、サーバ８１０は生死監視プログラムおよびリソース監視プログラムを停止する。サーバ８１０は、他のサーバ８０２、８０４、８０６、８０８に対して、リソース増強依頼を発砲する（Ｓｔｅｐ２）。

【0101】

Ｓｔｅｐ２のリソース増強依頼を受信したサーバ８０２、８０４、８０６、８０８は、依頼元のサーバ８１０のＣＰＵの利用率およびメモリの利用率を確認する（Ｓｔｅｐ３）。確認の結果、ＣＰＵの利用率もメモリの利用率も９０％未満の場合、依頼先のサーバ８０２、８０４、８０６、８０８はリソース増強作業の否決を依頼元のサーバ８１０に返却する。確認の結果、ＣＰＵの利用率およびメモリの利用率の少なくともひとつが９０％以上の場合、依頼先のサーバ８０２、８０４、８０６、８０８は依頼元のサーバ８１０にリソース増強承認を返却する。

【0102】

依頼元のサーバ８１０は、依頼先のサーバ８０２、８０６、８０８からの返事を集計する（Ｓｔｅｐ４）。集計の結果、多数決で否決された場合、依頼元のサーバ８１０はリリース増強作業を取りやめ、誤検知として扱い、生死監視プログラムおよびリソース監視プログラムを再開する。集計の結果、多数決で可決された場合、依頼元のサーバ８１０はリソース増強作業を開始する。

【0103】

Ｓｔｅｐ５のリソース増強作業は以下のフローで行われる。
（１）依頼元のサーバ８１０は、現在の構成サーバ台数を稼働証明台帳８１４から取得する。構成サーバ台数が最大数の１１台に達していなければ、依頼元のサーバ８１０は２台ずつ増強すると決定する。なお、物理的なサーバ装置の性能や増強の見込みなどにより、最大数の１１台は可変であってもよい。
（２）依頼元のサーバ８１０は、自らを複製することで、２台の仮想サーバ８２０、８２２を生成する。ここで、サーバの名称には連続番号を設定する。監査システム８００では多数決方式を採用しているので、多数決が成立するために合計して奇数の台数を維持する。
（３）サーバの複製が完了すると、依頼元のサーバ８１０は、生成された２台のサーバ８２０、８２２をブロックチェーンのネットワークに参加させる。依頼元のサーバ８１０は、増強時刻と増強後の構成サーバ台数と生成されたサーバ名と理由（＝ノード追加）と状態（＝異常）とを含むブロックを稼働証明台帳８１４に追加する。
（４）依頼元のサーバ８１０は、生死監視プログラムおよびリソース監視プログラムを、現在時刻に最も近い時刻から再開させる。

【0104】

図１９は、ＣＰＵ高騰によるリソース不足の解消後の縮退の正当性担保（要件１）に関する処理の流れを示すチャートである。監査システム８００のサーバ８１０は、毎秒自らのＣＰＵおよびメモリの利用率を確認する（Ｓｔｅｐ１）。他のサーバ８０２、８０４、８０６、８０８も同様な確認を行う。全てのサーバ８０２、８０４、８０６、８０８、８１０において、ＣＰＵの利用率が５％より大きく９０％未満であり、かつメモリの利用率が５％より大きく９０％未満である状態が１分間継続した場合、監査システム８００はその１分間のサイクルが終了した時点で監査システム８００の正常性を稼働証明台帳８１４に記録し、次のサイクルに移行することで繰り返し確認を継続する。

【0105】

サーバ８１０のＣＰＵの利用率およびメモリの利用率の少なくともひとつが５％以下である状態が２分間継続した場合、かつ、構成サーバ台数が５以上である場合、サーバ８１０は生死監視プログラムおよびリソース監視プログラムを停止する。サーバ８１０は、他のサーバ８０２、８０４、８０６、８０８に対して、リソース縮退依頼を発砲する（Ｓｔｅｐ２）。

【0106】

Ｓｔｅｐ２のリソース縮退依頼を受信したサーバ８０２、８０４、８０６、８０８は、依頼元のサーバ８１０のＣＰＵの利用率およびメモリの利用率を確認する（Ｓｔｅｐ３）。確認の結果、ＣＰＵの利用率もメモリの利用率も５％より大きく９０％未満の場合、依頼先のサーバ８０２、８０４、８０６、８０８はリソース縮退作業の否決を依頼元のサーバ８１０に返却する。確認の結果、ＣＰＵの利用率およびメモリの利用率の少なくともひとつが５％以下の場合、依頼先のサーバ８０２、８０４、８０６、８０８は依頼元のサーバ８１０にリソース縮退承認を返却する。

【0107】

依頼元のサーバ８１０は、依頼先のサーバ８０２、８０６、８０８からの返事を集計する（Ｓｔｅｐ４）。集計の結果、多数決で否決された場合、依頼元のサーバ８１０はリリース縮退作業を取りやめ、誤検知として扱い、生死監視プログラムおよびリソース監視プログラムを再開する。集計の結果、多数決で可決された場合、依頼元のサーバ８１０はリソース縮退作業を開始する。

【0108】

Ｓｔｅｐ５のリソース縮退作業は以下のフローで行われる。
（１）依頼元のサーバ８１０は、現在の構成サーバ台数を稼働証明台帳８１４から取得する。構成サーバ台数が最小数の３台に達していなければ、依頼元のサーバ８１０は２台ずつ削除すると決定する。
（２）依頼元のサーバ８１０は、サーバ名称の番号の数字が大きいものから２台を削除の対象として特定し、特定されたサーバ８０４、８０６を削除する。監査システム８００では多数決方式を採用しているので、多数決が成立するために合計して奇数の台数を維持する。
（３）サーバの削除が完了すると、依頼元のサーバ８１０は、削除時刻と削除後の構成サーバ台数と削除されたサーバ名と理由（＝ノード削除）と状態（＝異常）とを含むブロックを稼働証明台帳８１４に追加する。
（４）依頼元のサーバ８１０は、生死監視プログラムおよびリソース監視プログラムを、現在時刻に最も近い時刻から再開させる。

【0109】

図２０は、図１５の稼働証明台帳８１４の一例を示すデータ構造図である。稼働証明台帳８１４は、ブロックチェーンのブロックを保持する。稼働証明台帳８１４では、起源ブロック（不図示）から時系列に並んだ複数のブロック８３０、８３２、８３４、８３６、８３８が保持されている。ブロック８３０は、前のブロックのハッシュ値８４０と、監査システム８００の稼働の状況を示す稼働データ８４２と、を含む。他のブロックも同様の構成を有する。

【0110】

図２１は、監査に関連するプログラムが稼働中に不正に改ざんされていないことの証明（要件２）に関する処理の流れを示すチャートである。監査システム８００のサーバ８１０は、毎秒、他のサーバ８０２、８０４、８０６、８０８に対して監査関連プログラムの行数およびファイルサイズ（バイト数）の比較確認を要求する（Ｓｔｅｐ１）。なお、行数およびファイルサイズはいずれか一方でもよく、これに代えてまたは加えて、監査関連プログラムのハッシュ値が用いられてもよい。監査関連プログラムの行数およびファイルサイズに差分が無い状態が１分間継続した場合、監査システム８００はその１分間のサイクルが終了した時点で監査関連プログラムの正常性を正当性証明台帳８１６に記録し、次のサイクルに移行することで繰り返し確認を継続する。

【0111】

差分があった場合（ここで、返事が無い場合は前述の障害／リソース過不足対応で対処済みであるから想定しない）、サーバ８１０は、他のサーバ８０２、８０４、８０６、８０８のそれぞれから返信されてきた監査関連プログラムの行数およびファイルサイズを確認する。サーバ８１０は、自己の監査関連プログラムの行数およびファイルサイズと、他のサーバの監査関連プログラムの行数およびファイルサイズと、を比較し、それらに相違が生じている監査関連プログラムを有するサーバ８０４を改ざん可能性のあるサーバとして特定する。サーバ８１０は、他のサーバ８０２、８０４、８０６、８０８のうち改ざん可能性のあるサーバ８０４以外のサーバに対してプログラム改ざん対応依頼を発砲する。サーバ８１０は、生死監視プログラム、リソース監視プログラムおよび改ざん監視プログラムを停止する（Ｓｔｅｐ２）。

【0112】

Ｓｔｅｐ２のプログラム改ざん対応依頼を受信したサーバ８０２は、他のサーバ８０４、８０６、８０８、８１０に対して監査関連プログラムの行数およびファイルサイズの比較確認を要求する（Ｓｔｅｐ３）。改ざん可能性のあるサーバが無い場合は、サーバ８０２はプログラム改ざん対応作業の否決を依頼元のサーバ８１０に返却する。改ざん可能性のあるサーバを発見した場合、サーバ８０２はプログラム改ざん対応作業の承認と、発見したサーバ名と、を依頼元のサーバ８１０に返却する。

【0113】

依頼元のサーバ８１０は、依頼先のサーバ８０２、８０６、８０８からの返事を集計する（Ｓｔｅｐ４）。この集計の際の集計対象は、依頼元のサーバ８１０が発見した改ざん可能性のあるサーバ８０４のみとする。集計の結果、多数決で否決された場合、依頼元のサーバ８１０はプログラム改ざん対応作業を取りやめ、誤検知として扱い、生死監視プログラム、リソース監視プログラムおよび改ざん監視プログラムを再開する。集計の結果、多数決で可決された場合、依頼元のサーバ８１０はプログラム改ざん対応作業を開始する。

【0114】

Ｓｔｅｐ５のプログラム改ざん対応作業は以下のフローで行われる。
（１）依頼元のサーバ８１０は、特定した改ざん可能性のあるサーバ８０４をブロックチェーンから切り離し、削除する。依頼元のサーバ８１０は、切り離し時刻と構成サーバ台数と切り離したサーバ名と理由（＝改ざん検知）と状態（＝異常）とを含むブロックを正当性証明台帳８１６に追加する。
（２）依頼元のサーバ８１０は、自ら（サーバ８１０）の仮想マシンの複製を生成し、生成されたサーバ８４４のサーバ名を削除したサーバ８０４のサーバ名とする。
（３）サーバの複製が完了すると、依頼元のサーバ８１０は、生成されたサーバ８４４をブロックチェーンのネットワークに参加させる。依頼元のサーバ８１０は、回復時刻と構成サーバ台数と生成されたサーバ名（＝切り離したサーバ名）と理由（＝回復完了）と状態（＝異常）とを含むブロックを正当性証明台帳８１６に追加する。
（４）依頼元のサーバ８１０は、生死監視プログラム、リソース監視プログラムおよび改ざん監視プログラムを、現在時刻に最も近い時刻から再開させる。

【0115】

図２２は、図１５の正当性証明台帳８１６の一例を示すデータ構造図である。正当性証明台帳８１６は、ブロックチェーンのブロックを保持する。正当性証明台帳８１６では、起源ブロック（不図示）から時系列に並んだ複数のブロック８４６、８４８、８５０、８５２が保持されている。ブロック８４６は、前のブロックのハッシュ値８５４と、監査関連プログラムの状況を示す状況データ８５６と、を含む。他のブロックも同様の構成を有する。

【0116】

本実施の形態に係る監査システム８００によると、監査台帳８１２の他に稼働証明台帳８１４および正当性証明台帳８１６を有することで、自らの正常稼働の記録および監査関連プログラムの正当性の記録を改ざん不可能なブロックチェーンで証明することができる。さらに、監査人のサーバをブロックチェーンに参加させることにより、稼働証明台帳８１４および正当性証明台帳８１６を監査人と共有することができる。これにより、監査人の側でいつでも稼働証明台帳８１４および正当性証明台帳８１６を参照できるので、監査を効率化できる。

【0117】

以上、実施の形態に係るシステムの構成と動作について説明した。これらの実施の形態は例示であり、各構成要素や各処理の組み合わせにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解される。

【0118】

第１の実施の形態では、業務プログラムのハッシュ値の検査を開発側領域３８から本番側領域４０への移動時に行う場合について説明したが、これに限られず、例えば承認画面を生成する際にハッシュ値の検査を行ってもよいし、リリース完了後にハッシュ値の検査を行ってもよい。

【0119】

第１の実施の形態では、業務プログラムを開発してリリースする場合を説明したが、これに限られず、プログラムは任意のプログラムであってもよく、プログラムのモジュールであってもよい。

【0120】

第１および第２の実施の形態では、ブロックが前のブロックのハッシュ値を保持するタイプのブロックチェーンを説明したが、これに限られず、ブロックが前のブロックの一部のハッシュ値を保持するタイプなどの他のタイプのブロックチェーンが用いられてもよい。

【0121】

第２の実施の形態では監査システム８００の稼働証明および監査関連プログラムの正当性証明をブロックチェーンにより行う場合を説明したが、これに限られず、第２の実施の形態に係る技術的思想は、ブロックチェーンを用いる任意のシステム、例えばブロックチェーンを用いる（仮想）暗号通過システムやトレーサビリティシステム、事務処理全般の業務ワークフローをブロックチェーンにより管理するシステムなどにも適用可能である。

【0122】

第２の実施の形態の技術的思想を第１の実施の形態のライブラリアンシステム１００に導入してもよい。この変形例では、ライブラリアンシステム１００は、台帳保持部１３０に加えて、稼働証明台帳８１４に対応する台帳および正当性証明台帳８１６に対応する台帳を備える。

【符号の説明】

【0123】

１０ プログラム管理システム、 １２ 開発者端末、 １４ 承認者端末、 １８ リリース端末、 １００ ライブラリアンシステム。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】