平成 11 年度 修士論文 建設 CALS/EC 実証フィールド実験 を支援するウェブ技術について 平成 12 年 2 月 10 日 熊本大学大学院自然科学研究科 博士前期課程環境土木工学専攻 関 宏一郎 建設 CALS/EC 実証フィールド実験 を支援するウェブ技術について STUDY OF WEB-TECHNOLOGY SUPPORTED BY PILOT TRIALS FOR CONSTRUCTION CALS/EC 大学院自然科学研究科博士前期課程環境土木工学専攻 関 宏一郎 Presently, the Ministry of Construction (MOC), Government of Japan is introducing and accomplishing the construction CALS/EC in Architecture, Engineering and Construction ( AEC ) industry. This paper discusses and investigates the important issues of the construction CALS/EC. A new system is tried to develop to solve their problems, which is supported by the Web-technology, it is not to use special hardware and software. In this paper, two pilot trials are implemented to examine and to confirm it. They are: the Daido-riv. dam construction project in Shiga and the Sashiki bridge construction project in Kumamoto, Japan. 1. 序論 現在、建設省を中心に建設業界の情報化として建設 CALS/EC の導入が推進されている 1）。建設 CALS/EC とは、「公共事業支援統合情報システム」のことで、これまで紙でやり取りされていた公共事業に関する情報 を標準に基づいて電子化し、情報機器をネットワークに接続することにより、特定の機器、システムに縛ら れることなく、組織を超えて情報の伝達、共有、処理、加工、検索、連携を可能とする環境の総称である。 その実現に向け、必要不可欠な技術的問題として挙げられのが、各種電子データの標準化である。これま で建設各社は、それぞれの会社内で独自に OA 化・情報化を進め、多くの情報を電子化し、業務を効率的な ものにしようと努力してきた。しかし、建設各社それぞれ使用するコンピュータの機種やソフトウェアの種 類が違うために、組織や会社の枠を超えたオープンな電子データの交換・共有を目指す建設 CALS/EC の実 現において、電子データの互換性・汎用性といった点で大きな障害となっているのである。その問題を踏ま え、本論文では既存のウェブ技術を用いることで、コンピュータの機種やソフトウェアの種類に依存しない システムの構築を試みる 2）3）。 本論文は、まず第 2 章で建設 CALS/EC の現状を述べ、それが抱えているいくつかの問題点を指摘する。 第 3 章では、システム構築に必要不可欠となる既存のウェブ技術について紹介する。第 4 章では、既存のウ ェブ技術を組み合わせて構築したシステムの実証フィールド実験として、黄ノ瀬管理用地概略設計業務と佐 敷大橋（仮称）建設工事の 2 つを紹介し、適用により明らかとなったシステムの有効性や問題点などについ て考察を加える。 1 2. 建設 CALS/EC の現状 2.1 建設 CALS/EC 建設 CALS/EC とは、建設省が推進して いる「公共事業支援統合情報システム」の ことである。これまで「紙」でやり取りさ れていた公共事業に関する情報を「標準」 に基づいて「電子化」し、情報機器をネッ トワークに接続することにより、特定の機 器、システムに縛られることなく、組織を 超えて情報の伝達、共有、処理、加工、検 索、連携を可能とする環境の実現を目指し ている（図−1 参照）。 建設 CALS/EC の実現に向けては、建設 省が 1995 年 5 月に設置した「公共事業支 援統合情報システム研究会（建設 CALS/EC 研究会）」が中心となり実際の活 図−1 建設 CALS/EC のイメージ 動が行われている。1996 年 4 月に「建設 CALS/EC 整備基本構想」を策定し、これを基に翌年 6 月には、 実際に整備すべき具体的な内容を明らかにした「建設 CALS/EC アクションプログラム」を策定した。その 中では、1996 年度から 1998 年度までをフェーズ１、1999 年度から 2001 年度までをフェーズ２、2002 年 度から 2004 年度までをフェーズ３として３段階に分けて、それぞれに整備目標、実施内容、実現のために 不可欠な措置・技術を設定している。今年度はフェーズ２の初年度にあたり、実現のために不可欠な措置・ 技術として、①国際標準等に基づく電子データの基準化、②電子認証システムの導入、③電子データによる 成果納入の実施などが挙げられている（表−1 参照）。 また、実際の公共事業へ建設 CALS/EC を適用することによる効果と問題点を把握することを目的とし、 併せて現場への建設 CALS/EC の普及・教育のために、1996 年度より数多くの実証フィールド実験が実施さ れている。1996 年度は 35 事務所、1997 年度は 119 事務所、1998 年度は 176 事務所（全数 252 ）と、増加 傾向にある。 表−1 建設省直轄事業における建設 CALS/EC アクションプログラム（要約） フェーズ１ フェーズ２ フェーズ３ 1996∼1998年度 1999∼2001年度 2002∼2004年度 建設省全機関において電子データの受発 一定規模の工事等に電子調達システムを 建設省直轄事業の調査・ 計画、設計施工、 導入 管理に至る全てのプロセスにおいて電子 整備目標 信体制の構築 データの交換、共有、連携を実現 事業に関連する情報の伝達・ 交換を電子 電子調達システムの導入 全ての事業に電子調達を活用 メール化 電子媒体又は電子メールによる申請・届出 事業に関する情報の伝達・ 交換の電子メー EDIによる契約事務の執行 ル化（認証あり） 電子媒体又は電子メールによる申請・届出 全ての公共事業執行に係る申請・届出の 実現内容 調達関連情報のホームページ掲載 （ 認証あり） オンライン化 調達情報に関するクリアリングハウスの構 資格審査申請のオンライン化 事業に関する情報の統合データベース化 ネットワーク型自動積算システムの導入 GISを利用した情報の連携・統合 電子データ成果の再利用・ 加工・ 統合によ STEPの活用による施設のライフサイクル るデータの有効活用 サポート インターネットの利用環境の整備 国際標準等に基づく電子データの基準化 既存情報システムとの連携 電子認証システムの導入 STEPの一部国際標準化 実現のため 実証フィールド実験の推進 電子データによる成果納品の実施 電子データによる契約事務の標準化 に不可欠な 電子調達に必要な技術の開発 措置・ 技術 電子データ標準化に関する研究 情報インフラの整備（ 光ファイバー網等、空間データ基盤） 2 2.2 共有サーバーの在り方 前節で述べたように、実際の公共事業へ建設 CALS/EC を適用することによる効果と問題点を把握するこ とを目的として、1996 年度より現在に至るまで数多くの実証フィールド実験が工事規模の大小を問わず実施 されてきた。そこで、受・発注者間でやり取りされる情報を蓄積し、効率的な情報の交換・共有を実現する ために必要不可欠となるのが、共有サーバーの導入である。 次に、共有サーバーの在り方として、発注者および受注者の管理下に共有サーバーがある場合の問題点を それぞれ指摘し、それらの問題点を踏まえて、第三者機関によって管理される外部共有サーバーの導入を提 案する 4）。 （1）発注者側の管理下にある場合（図−2 参照） 建設省などの発注者側主導で行われる建設 CALS/EC 実証フィールド実験では、主に発注者機 関が所有しているサーバーを共有サーバーとして、 受・発注者間での情報の交換・共有に使用する場合 が多い。しかし、この場合には共有サーバーが発注 者側の管理下にあることで、受・発注者双方が対等 な立場を維持することが難しく、提出情報の「改竄」、 「なりすまし」 、 「しらばくれ」といった不正行為が 行われる可能性がでてくる。 また、受注者側の立場としても、発注者ネットワ ーク内ということや、提出情報の秘守を徹底する必 要性があるということで、工事終了後での提出情報 の再利用といったことが困難となってくる。 （2）受注者側の管理下にある場合（図−3 参照） 施工者に代表されるように現場事務所に設置した 図−2 発注者側の管理下にある場合 図−3 受注者側の管理下にある場合 サーバーや、また大手建設会社になってくると自社 サーバーを現場用にパーティションを切って用意し た場合など、受注者側が準備した共有サーバーを 受・発注者間での情報の交換・共有に使用する場合 もある。共有サーバーが受注者側の管理下にあるこ とから、前項（1）と同様に受・発注者双方が対等 な立場を維持することが難しく、情報管理の信頼性 が問題となる。またこの場合においては、工事毎に 専門職員を配置する必要もあるため、運用・保守管 理、それにかかる費用の負担も大きくなってくる。 この他にも工事現場の特性から、共同企業体（JV） などのような企業間での情報の交換・共有において、 情報セキュリティーや所有権などの問題が存在して いる。 3 （3）第三者機関に委託する場合（図−4 参照） 前述した（1）（2）の問題点を考慮し、本論文で は、発注者でも受注者でもない第三者機関に共有サ ーバーの管理を委託することを提案する。この外部 共有サーバーを導入することで、受・発注者双方の 立場を対等なものにし、情報管理の相互信頼を維持 することが可能になると考える。またサーバーを一 ヶ所に集約することで、運用・保守管理、それにか かる費用の負担を軽減することが可能になると考え る。このことによってシステムやアプリケーション の一元管理ができるため、工事毎に異なったシステ ムやアプリケーションを使用することによる弊害が 避けらる。 この他にも、現場事務所の事情によっては、現場 事務所のサーバーに置くべき情報の代替サーバーと して外部共有サーバーを利用することも可能である 図−4 第三者機関に委託する場合 と考える。 2.3 電子データの標準化 現在、建設 CALS/EC の実現に向けて最大の問題とされているのが、各種電子データの「標準化」である。 この各種電子データの「標準化」の問題は、特に技術的に新しいことが必要なこともなく、現時点でも十分 に実現可能だと考えられている。しかし、多くのソフトウェアベンダーが自由競争の中で独自性を発揮しよ うと開発を進め、自社製ソフトウェアのシェアを拡大しようと努力している中、この動きに「標準化」が対 応できていないのが現状である。 また、建設 CALS/EC が推進される以前から、これまで建設各社は、それぞれで独自に OA 化・情報化を 進め、多くの情報を電子化し、業務を効率的なものにしようと努力してきた。当然、そこで建設各社それぞ れ使用するコンピュータの機種やソフトウェアの種類は違ってくる。このことが組織や会社の枠を超えたオ ープンな電子データの交換・共有を目指す建設 CALS/EC の実現において、電子データの互換性・汎用性と いった点で大きな問題となっている。 このような状況の中では電子データを効率良く交換・共有することは困難である。建設 CALS/EC ではこ のような問題を解決するために、コンピュータの機種やソフトウェアの種類に依存しない共通の標準的なル ール作りを進めているところである。次に、本論文では、各種電子データの標準化への動きについて、工事 規模の大小を問わず交換・共有されるであろうデータとして、（1）文書データ、 （2）写真データの 2 つに着 目し、以下にまとめる。 4 （1）文書データの標準化 建設省が 1998 年 5 月に発表した「電子納品要領（案）」の中では、業務の属性情報（業務名称、受注者名 など）を管理項目として XML（eXtensible Markup Language）で記述することとなっている。XML とは、 HTML（HyperText Markup Language）と同じくインターネット上での利用を目的とした記述言語で、階 層と属性を規定することで文書を構造化することができる 5）。その他にも、XML は別途策定されている「デ ジタル写真管理情報基準（案）」や「CAD 製図基準（案）」などでも採用されている。 同じく「電子納品要領（案）」の中で、業務報告書の本文の電子ファイル形式として PDF（ Portable Document Format）形式が採用されている。PDF とは、アドビシステムズ社が開発したデータ形式のこと である 6）。Adobe Acrobat を使用することで、ほとんどのファイル形式を PDF 形式に変換し、元の書類のデ ザインやレイアウトをそのまま再現することが可能となる。ここで最大の利点として挙げられるのは、PDF ファイルは無償で配布されている Acrobat Reader を利用して閲覧・印刷することが可能だということであ る。このことから、業務報告書のような加工・修正することが少なく、閲覧・印刷のみ可能であれば良い場 合などでの利用が考えられる。この場合、報告書のオリジナルファイルもあわせて提出する必要がある。 （2）写真データの標準化 建設業界においてもデジタルカメラはここ数年で急速に普及し、デジタルカメラによる工事写真の撮影お よび電子媒体による編集・整理が定着しつつある。デジタルカメラを導入することにより、現像コストの削 減やアルバム作成作業の省力化、保管スペースの縮小といった効果を得ることができる。それに合わせるよ うに、複数のソフトウェアベンダーが開発した写真管理ソフトが発売されているが、それらの規格が違うた め、文書データ同様に互換性・汎用性の問題が生じ、利便性が損なわれているのが現状である。 そこで、建設省は 1998 年 12 月そして 1999 年 3 月に建設省が発注する土木工事・建築工事の一部を対象 として工事写真を電子媒体で提出する場合の仕様をまとめた 「デジタル写真管理情報基準（案） 」 を発表した。 これには、ある一定のガイドラインを設定することで、それに基づいてソフトウェアベンダーが写真管理ソ フトを開発できるようにとの意図が含まれている。 本論文では建設 CALS/EC の標準化の動向とは若干異なる視点から、文書の作成ツールとして一般的なワ ープロソフトを一切使用せず、また、デジタル工事写真の編集・整理用として市販されている工事写真管理 ソフトを一切使用せずに、既存のウェブ技術を用いることで、コンピュータの機種やソフトウェアの種類に 依存しないシステムの構築を試みることとする。 3. 構成ウェブ技術 ユーザーがクライアント側のパソコンにおいて、無償で配布されている Internet Explorer や Netscape Communicator などに代表される一般的なブラウザ・ソフトのみでネットワークに参加できるシステムを構 築する。そのためにサーバー側のパソコンに必要不可欠となるソフトウェアやそれらの機能について、ここ では総称してウェブ技術として以下にまとめる。 3.1 Windows NT Server 5 本論文ではシステム構築において、マイクロソフト社から発売されている Windows NT Server 4.0 をサー バーOS として採用した 7）。これまでの UNIX などを中心としたネットワークでは、構築コストや運用コス トが高いだけでなく、ネットワークの構築に専門的な知識が必要であった。その点では、Windows NT Server はサーバーOS として格段に低価格であり、また Windows 95 や Windows 98 と同様のユーザーインターフ ェイスを備えているため操作性も高く、初心者でも比較的簡単に本格的なネットワークの構築・管理が可能 となる。最近では Linux のようなフリーのサーバーOS が注目されているが、操作性や各種アプリケーショ ンとの連携といった点ではまだまだである。 3.2 IIS（Internet Information Server） Windows NT Server 4.0 には、インターネットサーバーとして IIS（Internet Information Server）が標 準装備されている。この IIS は、WWW サーバーと FTP（File Transfer Protocol）サーバー、その他にも Gopher サーバーなどの各機能を併せ持っている。OS としてサーバーに Windows NT Server 4.0 をインス トールした段階では、IIS のバージョンは 2.0 だが、マイクロソフト社の修正・追加モジュール集である Service Pack 2 または Service Pack 3 を追加インストールすることで、バージョン 3.0（IIS 3.0）にアップ グレードすることができる。更に Windows NT 4.0 Option Pack をインストールすることで、IIS 4.0 にバー ジョンアップすることができ、HTTP 1.1 対応など機能の方も大幅に拡張される。IIS 3.0 以降からは、ASP （Active Server Pages）というアドオンモジュールを組み込むことで、WWW サーバー上で VBScript や JScript などのスクリプトプログラムを稼動させることが可能となる 8）。ここで紹介した各種 Service Pack や Windows NT 4.0 Option Pack は、マイクロソフト社のホームページから無償でダウンロードすることが 可能であり、また雑誌・書籍などの付録 CD−ROM からも入手可能である。 3.3 NTFS （Windows NT File System） （File Allocation Table ）と NTFS （Windows Windows NT Server で利用可能なファイルシステムには FAT NT File System）の 2 つがある。Windows 95 や Windows 98 で利用可能なファイルシステムは FAT のみ で、Windows NT Workstation および Windows NT Server だけで利用可能なファイルシステムとして NTFS が位置付けられている。この NTFS は FAT と異なり、ファイルやフォルダに対してアクセス権を設 定することが可能となる。通常のデフォルト設定では、ネットワーク上のすべてのユーザーに対して匿名ユ ーザーとしての情報の参照が許可されているが、一部の限られたユーザーだけでしかファイルやフォルダを 参照できないようなアクセス権の設定も可能となる。その際、ユーザー単位でアクセス権を設定するのでは なく、ユーザーをそれぞれグループに属させ、 そのグループ単位でアクセス権を設定すること で、後々での管理負荷を低減させることができ る。実際にアクセス権を設定したファイルやフ ォルダを参照すると、認証のためのユーザー名 とパスワードの入力を要求するダイアログが表 示される（図−5 参照） 。ここにドメインユーザ ーマネージャーであらかじめ登録しておいたユ ーザー名とパスワードを入力することで、ファ イルやフォルダの参照が許可される。 図−5 3.4 ASP（Active Server Pages） 6 パスワードの入力ダイアログ ASP とは Windows NT Server 4.0 の Service Pack に標準搭載されたインターネットサーバーである IIS 3.0 以降で動作可能なアドオンモジュールのことで、WWW サーバー上で VBScript や JScript、PerlScript などのスクリプトプログラムを稼動させるための仕組みのことである。その実体は、サーバー側のパソコン からクライアント側のパソコンへデータを送信する際のプリプロセッサである。通常は、サーバー側のパソ コンからクライアント側のパソコンへ送信するファイルの拡張子は、「＊.html」および「＊.htm」である HTML 形式のファイルを用いるが、拡張子を「＊.asp」とすることで自動的に ASP エンジンを経由し、そ こでファイルがスクリプト処理され、その処理結果が HTML 形式のデータとして送信することが可能とな る。その際に、クライアント側のパソコンが受信するのはあくまで HTML 形式のデータであり、このため クライアント側のパソコンを選ばないのも ASP の特徴の 1 つとなっている（図−6 参照） 。その ASP は、 HTML タグと ASP スクリプトで構成されるテキストベースのファイルであるため、メモ帳などのテキスト エディタを使って作成することが可能である。ファイル中では ASP スクリプトを HTML タグおよび通常の 内容と区別するために、<% と%>という区切り記号を使用して記述する。 ASP が登場する以前からも、このようなサーバーサイドスクリプト技術は存在していた。代表的なもので は、UNIX 上の WWW サーバーを中心として最も頻繁に利用されている CGI（Common Gateway Interface） などがある。CGI は一般に Perl（Practical Extension and Reporting Language）などのスクリプト言語で 書かれるが、C 言語などで書かれたバイナリファイルも利用することができる。しかし、CGI にはウェブア プリケーションなどシステムを開発する上で、いくつかの問題点が存在する 9）。具体的には、 ①データベースとの連携が初心者には困難である。 ②クライアント側のパソコンからの要求を複数ページ間で関連付けて処理することが困難である。 ③複数のユーザーからの同じ要求に対してサーバー資源を極端に浪費する。 ④スクリプトとファイルが別々であるためソース管理の煩雑さが増加する。 といった問題点が挙げられる。 それに対して、本論文でシステム構築の際に使用する ASP には、以下のような利点が挙げられる。 ②要求されたページを呼び出す ③コンポーネントが呼び出された 場合はコンポーネントを実行する ①ページを要求する ④処理結果のみをクライアントに返す 無駄なデータが 流れない クライアント環境 に依存しない 図−6 Active Server Pages の動作機構 7 コンポーネント の再利用が可能 （1）技術の互換性、汎用性 ASP スクリプトは全てサーバー側のパソコンで処理されるため、クライアント側のパソコンに返される 処理結果は、基本的に HTML 形式のデータである。よってシステム開発者はクライアント側の環境のこ とを考慮せずに、サーバー側の処理だけに専念することができる。 （2）ネットワーク負荷の軽減 クライアント側のパソコンに返される処理結果はあくまで要求された分だけで、余計なデータやプログ ラムは一切ネットワーク上に流れることはない。つまり、ネットワークへの負荷は最低限に抑えることが できる。 （3）技術習得の容易さ ASP のスクリプト言語の一つである VBScript は、マイクロソフト社が提供している開発言語である Visual Basic のサブセットである。その Visual Basic は BASIC を元にした言語であるため、初心者にも 比較的容易に習得することができる。 （4）豊富な開発、実行環境 ASP は、Windows 95 や Windows 98 に標準で付属している PWS（Personal Web Server）でも動作確 認が可能である。そのため、サーバー・マシーン以外の普段から使用しているパソコン環境でも手軽に開 発および動作確認ができる。 （5）ソース管理の効率化 「＊.asp」という拡張子のファイルの中に、HTML タグによる表示部分と ASP スク ASP ファイルは、 リプトによる処理部分とが一体化した形で記述されている。そのため、スクリプトファイルを別管理しな ければならない CGI とは異なり、大規模なアプリケーションになるに従い、ソース管理の負荷を軽減する ことができる。 （6）サーバー資源の有効利用 CGI では複数のユーザーから同じ処理を要求された場合、その数だけ起動させなければならずサーバー 資源の消費に対して配慮が必要となる。しかし、ASP では各コンポーネントが DLL という一つの塊とな っているため、同じ処理の要求に対しては 1 つのコンポーネントが呼び出されるだけで済み、非常に効率 的である。 （7）豊富なコンポーネント群 ASP では、アクセスカウンターをはじめとする誰が記述しても大きな違いがないような定型化された処 理については、一般化された共通のコンポーネントとして広く公開されている。最近では、CGI でもソー スの提供が進んでいるが、ソースの開発環境の違いが大きく影響を及ぼすため、実用的なものとは言えな い。 3.5 ファイルアップロード 8 ASP を用いることで、クライアント側のパソコンのブラウザ画面で入力したテキストや選択した項目など を、サーバー側のパソコンに送信することが可能となる。それ以外にもクライアント側のパソコンのローカ ルディスクにあるファイルをサーバー側のパソコンに送信したい場合がある。 そこで考えられたのが、HTML タグの<FORM>を拡張してファイルのアップロードを可能にする仕組みで ある。この仕組みは、Internet Explorer 4.0 以降や Netscape Navigator 2.02 以降のブラウザ・ソフトに組 み込まれていたが、これにサーバー側が対応していなかったために Windows NT Server では利用できなか った。現在では、 追加コンポーネントとして Windows NT 4.0 Option Pack に含まれる Microsoft Site Server Express 2.0 の一部として提供されている Posting Acceptor コンポーネントをインストールすることで、 Windows NT Server でもこの仕組みが利用できるようになった 10）。 Posting Acceptor コンポーネントを使ったファイルのアップロードでは、クライアント側で<FORM>タグ に含まれる<INPUT>タグの TYPE 属性に FILE を指定することで、フォームにファイル名を指定するフィ ールドが表示される。このフィールドを利用して、クライアント側のパソコンのブラウザ画面からファイル 名を入力してサーバー側のパソコンに送信する。次にサーバー側のパソコンでは、送信されたファイルを 。 Posting Acceptor コンポーネントが受け取り、送られたファイルを指定された場所に保存する（図−7 参照） Posting Acceptor コンポーネントの他にも、馬場達夫氏によって開発された BASP21 コンポーネントなど、 ファイルアップロード機能を持つ追加コンポーネントは広く一般に公開されている 11）。 図−7 Posting Acceptor コンポーネントによるファイルアップロード 3.6 OpenPix ImageIgniter 9 OpenPix ImageIgniter とは、ヒューレット・パッカード社によって開発されたサーバー・ソフトウェア のことで、オーサリング、サーバー、ビューイングの各コンポーネントを備えたインターネット対応のイメ ージ配送システムである 12）。動作環境としては、Windows NT Server 4.0 上の IIS 3.0 または IIS 4.0 にイ ンストールすることができる。 現在では、インターネット上でイメージ・ファイルを使用したウェブ・ページは当たり前となっているが、 ネットワーク回線や通信インフラなどの問題によって、データ量の大きなイメージ・ファイルや大量のイメ ージ・ファイルを同時に表示させるには、ダウンロードに時間がかかったり、サーバーに大きな負荷を与え たりと実用的ではない。しかし、サーバー側のパソコンに OpenPix ImageIgniter を導入することで、クラ イアント側のパソコンには Internet Explorer や Netscape Communicator などの一般的なブラウザ・ソフ トのみで、ウェブ・ページ上のイメージ・ファイルと高い対話性を得ることができる。 通常の HTML 形式のファイル内では、イメージ・ファイルを表示させるためにイメージ・タグ<img>を 記述する。そのイメージ・タグは、表示するイメージ・ファイルの名前やサイズ、位置などといった属性を 指定するものである。OpenPix ImageIgniter は、その HTML 標準のイメージ・タグに新しい属性を追加す ることができる。それらの属性について必須項目を中心に以下にまとめる。 （1）ソース属性および OpenPix ソース属性 ソース属性（Src）と OpenPix ソース属性（OPXSrc）によって、表示対象のイメージ・ファイルの名 前が指定される。イメージ・タグには、どちらか最低 1 つの属性が含まれなければならない。 （2）タイプ属性 タイプ属性（OPXVType）によって、ウェブ・ページに表示される OpenPix ビューアーの種類が決定 される。通常は、デフォルト値の Auto を指定することで、ImageIgniter サーバーの最適化配送機能 （Adaptive Delivery ）がそれぞれブラウザの種類に応じて、自動的にビューアーを選択し配送してくれる。 この属性も必須項目である。 （3）ビューアーの幅属性およびビューアーの長さ属性 ビューアーの幅属性（Width ）とビューアーの長さ属性（Height）によって、ビューアーの幅と高さを ピクセル単位で指定することができる。この属性も必須項目である。 （4）スタイル属性 スタイル属性（OPXVStyle ）によって、OpenPix ツールバーの位置と動作を指定することができる。 そのウェブ・ページに表示されたツールバーによって、イメージの操作が可能となる。ツールバーには、 ズーム・イン、ズーム・アウト、パン、印刷、リセット、ヘルプのボタンがある。 この他、初期画面表示属性（Coords） 、名前属性（Name）、背景色属性（BGColor）、代替文属性（Alt）、 水平方向のスペース属性（Hspace）および垂直方向のスペース属性（Vspace ）、配置属性（Align）などが ある。 4. 適用事例 10 この章では、前章で紹介した既存のウェブ技術を用いてシステムを構築し、そのシステムの実証フィール ド実験として、文書データおよび写真データの 2 つの適用事例を紹介する。最後に、それらの適用事例を通 して明らかになった有効性や問題点について考察を加える。 4.1 文書データに関する適用事例 文書データについての適用事例としては、滋賀県大津市で行 われている大戸川ダム建設事業の関連業務である黄ノ瀬管理用 地概略設計業務において実証フィールド実験を行った。以下、 岐阜県 福井県 詳細を述べる。 （1）大戸川ダム建設事業の概要 大戸川ダムは、「淀川水系工事実施基本計画」に基づく上流ダ ム群のひとつとして、大戸川はもとより下流宇治川・淀川本川 の洪水被害を軽減することを柱に、大津市、京都府および大阪 の水道用水の供給、河川が本来持っている機能の維持、さらに はクリーンエネルギーである水力発電を目的とし、滋賀県大津 市上田上牧町および上田上桐生町に多目的ダムとして建設予定 である（図−8 参照）。その中で黄ノ瀬管理用地概略設計業務は、 ダム本体および付替県道等で発生する残土処理と、100 年間の 貯砂ダムでの堆砂処理を考慮して、黄瀬管理用地での残土処理 計画の概略検討を行い、地元に対するプレゼンテーション資料 を作成するものである 13）。 滋賀県 大戸川ダム ■ 大津市 京都府 図−8 三重県 大戸川ダムの建設位置 （2）システムの適用 黄ノ瀬管理用地概略設計業務において、構築したシステムを適用し、建設 CALS/EC の実証フィールド実 験を行った。本業務の期間は、平成 11 年 1 月から平成 11 年 3 月までの 3 ヶ月間で、発注者である建設省近 畿地方建設局大戸川ダム工事事務所と、受注者である鳳コンサルタント株式会社との間で、本システムを用 いて業務が行われた。ここで重要なことは、発注者および受注者以外の第三者機関にサーバー管理を委託し たことである。このことで受・発注者間が対等な立場で業務を行うことができ、情報管理の信頼性を確保す ることが可能となるのである。今回の実証フィールド実験では、熊本大学工学部附属工学研究機器センター 5 階の画像データ解析機器室に設置した実験用サーバーを使用し、業務関係者のみがアクセスできるウェ ブ・ページ（URL：http://gdp1.erec.kumamoto-u.ac.jp/daidogawa/kinose/）を開設した。 （3）システムの機能詳細 今回の実証フィールド実験で使用した文書は、設計段階において受・発注者間で頻繁に交換される「打合 せ記録簿」である。設計および工事段階で扱う文書の様式は各地方建設局で規定されているため、建設省近 畿地方建設局が採用している様式に基づいてウェブ・ページ上に再現した。受・発注者はそれぞれウェブ・ ページにアクセスしブラウザ画面を通じて、必要な情報の入・出力および参照を行うこととなる。次に、実 際の文書の作成および交換手順について図を用いて説明する。 （a）「打合せ記録簿」新規作成手順（図−9 参照） 11 ①発議者 この項目は、新規「打合せ記録簿」の作成者を、発 注者と受注者のどちらかいずれかからチェックする単 数選択（ラジオボタン）の入力形式である。 ②発議年月日 この項目は、新規「打合せ記録簿」の作成年月日を 記入するテキスト入力フィールドである。ここでは、 作成時の日付が自動的に入力されるようになっている。 ① ③ ④ ② ⑤ また、業務期間中での「打合せ記録簿」の追加・補足 分の差替えにも対応できるようになっている。 ③発議事項 この項目は、「指示」、「協議」、「通知」、「承諾」、 ⑥ 「提出」 、 「報告」、「届出」 、 「その他」のいずれかをチ ェックする単数選択（ラジオボタン）の入力形式であ る。 「その他」を選択した場合には、補足説明を追記で きるテキスト入力フィールドが準備されている。 ④業務名 この項目は、業務名を記入する 1 行のテキスト入力 フィールドである。ここでは、今回の業務名である「黄 ノ瀬管理用地概略設計業務」が自動的に入力されるよ ⑦ ⑧ 図−9 「打合せ記録簿」新規作成画面 うになっている。 ⑤内容 この項目は、 「打合せ記録簿」の本文（内容）を記入する複数行のテキスト入力フィールドである。ここで は、テキスト入力フィールド内での改行が反映されるようになっている。 ⑥添付図書 この項目は、 「打合せ記録簿」といっしょに送信したい添付図書の部数を記入するテキスト入力フィールド である。今回の実験では、 「打合せ記録簿」1 部につき、添付図書 5 部（1~5）までの送信が可能なように設 定している。また、添付図書が無い場合でも、0（ゼロ）と入力する必要がある（この場合のみ、次項の（b） が省略される）。 ⑦削除用パスワード この項目では、送信後、上記内容を削除する場合に必要となるパスワードを設定することができる。それ ぞれウェブ・ページにログインした際の（ドメインユーザーマネージャーに登録している）パスワードが自 動的に入力される。パスワードは画面上では表示されず、伏せ字になるようになっている。 ⑧送信ボタンおよび取消ボタン 上記の項目をすべて記入し、最後に送信ボタンをクリックすることで、上記内容がサーバーに送信され、 データベースに格納される。また、取消ボタンをクリックすることで、入力されたすべての項目をリセット することができる。 （b）添付図書ファイル送信手順（図−10 参照） 12 ⑨ファイル選択 添付図書として「打合せ記録簿」と一緒に送信した いファイルを選択するフィールドである。前項 1）⑥ で記入した部数分のフィールドが自動的に表示される ようになっている。 「参照」ボタンをクリックすること ⑨ ⑩ で、ファイルの選択ダイアログが開く。 ⑩送信ボタンおよび取消ボタン 上記の項目をすべて記入し、最後に送信ボタンをク リックすることで、上記のファイルがサーバーに送信 され、データベースに格納される。また、取消ボタン をクリックすることで、入力されたすべての項目をリ セットすることができる。 図−10 添付図書ファイル送信画面 （c） 「打合せ記録簿」処理・回答手順（図−11 参照） ⑪追記 （a）−⑤の内容に追記する場合に内容を記入する 複数行のテキスト入力フィールドである。追記が無い 場合は空欄のままで省力して良い。 ⑫添付図書 （b）−⑨で「打合せ記録簿」と一緒に送信された 添付図書は、それぞれのアイコンをクリックすること で別ウィンドウを開き、表示・閲覧することが可能で ある。 ⑬処理・回答事項 この項目は、「指示」、「協議」、「通知」、「承諾」、 「提出」、「報告」、「届出」、「受理」、「了解」、「その 他」の中から処理・回答事項をチェックする単数選択 （ラジオボタン）の入力形式である。ここでは、受・ 発注者それぞれに対して処理・回答事項が異なってい る。また（a）−③と同様に、「その他」を選択した場 合には、補足説明を追記できるテキスト入力フィール ⑪ ⑫ ⑭ ⑬ ⑮ ドが準備されている。 図−11 「打合せ記録簿」処理・回答画面 ⑭処理・回答年月日 この項目は、 「打合せ記録簿」に対する処理・回答年月日を記入するテキスト入力フィールドである。ここ でも、（a）−②と同様に、処理・回答時の日付が自動的に入力されるようになっている。 ⑮送信ボタンおよび取消ボタン 上記の項目をすべて記入し、最後に送信ボタンをクリックすることで、上記内容がサーバーに送信され、 データベースに格納される。また、取消ボタンをクリックすることで、入力されたすべての項目をリセット することができる。 以上の作業手順を踏むことで、1 枚の「打合せ記録簿」が完成し、打合せ業務が成立したこととなる。 4.2 写真データに関する適用事例 13 写真データについての適用事例としては、 福岡県 熊本県芦北郡芦北町で行われている佐敷大橋 （仮称）建設工事において実証フィールド実 験を行った。以下、詳細を述べる。 （1）佐敷大橋（仮称）建設工事の概要 佐敷大橋（仮称）建設工事は、熊本県最南 部の水俣市および芦北町他２町からなる芦北 熊本県 長崎県 地域の、流通と輸送の改善による地域農業の 発展と経営の安定を目的とした広域農道整備 事業の一環であり、当地域の中心である芦北 町佐敷地区の佐敷川と湯浦川の合流河口であ 田浦町 ■ 佐敷大橋（仮称） 津奈木町 芦北町 水俣市 る女島（左岸）計石（右岸）地内に建設中の、 九州で初のエクストラドーズド橋である（図 −12参照） 。なお、工事の正式名称は、芦北地 区広域営農団地農道整備事業第1号工事であ 宮崎県 鹿児島県 図−12 る14）。 佐敷大橋（仮称）の建設位置 （2）システムの適用 佐敷大橋（仮称）建設工事において、構築したシステムを適用し、実証フィールド実験を行った 15）。工事 期間は、平成 10 年 3 月から平成 12 年 11 月（予定）までで、発注者である熊本県と、施工者である株式会 社鴻池組、オリエンタル建設株式会社、佐藤工業株式会社の工事共同企業体（佐敷 JV）との間で、本シス テムを用いて実証フィールド実験を行った。本適用でも、発注者および施工者以外の第三者機関にサーバー 管理を委託することで、両者が対等な立場で施工（管理）を行い、情報管理の信頼性を確保した。実験用サ ーバーは、熊本大学工学部附属工学研究機器センター5 階の画像データ解析機器室に設置し、ウェブ・ペー ジ（URL：http://gdp.erec.kumamoto-u.ac.jp/sashiki-bridge/）を開設した。次項では、システムの詳細に ついて述べる。 （3）システムの機能詳細 本適用において構築したシステムは、OpenPix ImageIgniterの最適化配送機能とASPのファイルアップロー ド機能とを組み合わせた工事写真管理用アルバムである。JV職員によってデジタルカメラで撮影された工事 写真を、現場事務所のパソコンからウェブ・ページにアクセスし、ブラウザ画面を通してサーバーにファイ ル送信することで、施主および施工会社の本社や支店などのパソコンから工事関係者が自由に表示・閲覧す ることができる仕組みである。次に、実際に工事写真をファイル送信および表示・閲覧する場合の作業手順 について説明する。 （a）工事写真のファイル送信手順（図−13参照） 14 ①送信者氏名 工事写真の送信者氏名を記入するテキスト入力フィ ールドである。デフォルト設定として、工事写真の管 理を担当する者の氏名が予め記入されている。 ②撮影年月日 ① ③ ④ ⑤ 工事写真の撮影年月日を記入するテキスト入力フィ ールドである。ここでは、送信時の日付が自動的に入 力されるようになっている。 ③ファイル選択 送信する工事写真ファイルを選択するフィールドで ある。 「参照」ボタンをクリックすることで、ファイル の選択ダイアログが開く。ここでは、ファイル名を一 図−13 ② 工事写真のファイル送信画面 定のルールに従って変更しておく必要がある。 ④ファイル説明 工事写真の説明コメントを記入する1行のテキスト入力フィールドである。ここでは、25文字以内という 字数制限を設けている。 ⑤送信ボタンおよび取消ボタン 上記の項目をすべて記入し、最後に送信ボタンをクリックすることで、上記内容と工事写真ファイルがサ ーバーに送信され、データベースに格納される。また、取消ボタンをクリックすることで、入力されたすべ ての項目をリセットすることができる。 （b）工事写真サムネイル一覧表示（図−14参照） 送信された工事写真ファイルが、降順でソートされ て一覧表示される。その際に、テキスト形式の工事写 真管理項目の属性情報と一緒に、送信された工事写真 をOpenPix ImageIgniterで自動的にダウンサイジング し、サムネイル・イメージ形式に変換してから表示す るように設定している（ここでは、幅80ピクセル×高 さ60ピクセルに設定）。 そのサムネイル・イメージ上で右クリックすること で、コマンド・ダイアログが表示され、ズーム・イン、 ズーム・アウト、パン、領域選択、初期画面、保存、 印刷、ヘルプといった各種コマンドが実行できる。ま た、アイコンをクリックすることで、サーバーに格納 されている原寸大の工事写真を表示することができる。 4.3 考察 15 図−14 工事写真の一覧表示画面 2つの実証フィールド実験を通して、明らかになったシステムの有効性や問題点について、以下に文書デ ータと写真データそれぞれについてまとめる。 （1）文書データ ①「打合せ記録簿」の文書作成において、できるだけ選択式の項目や自動的に入力される項目を増やすこ とによって、記入ミス・記入漏れなどの防止や操作性の向上といったデータの入力支援ができた。 ②サーバーのドメインユーザーマネージャーで登録しているユーザー名やパスワードといった個人情報 がそのままウェブ・ページ内でも使用することが可能となった。そのため、ユーザー、つまり「打合せ 記録簿」の文書作成者の特定が可能となり、 「改竄」「なりすまし」 「しらばくれ」といった不正行為の 防止策として有効であった。 ③添付図書のファイル送信に関しては、今回は同時に複数部の添付図書を送信可能なように設定していた が、ファイルサイズの大きな場合にタイムアウトなどのエラーが発生することがあった。また、添付図 書の有無や部数によってファイル選択するためのフィールドの数も決定されるため、記入ミス・記入漏 れなどの防止や操作性の点で有効であった。 ④本システムでは電子メールを補助的手段として使用し、新規の「打合せ記録簿」がサーバーに送信され たのと同時に、受・発注者双方に電子メールで同内容が送信されるように設定しているため、より迅速 な情報の共有・交換に有効であった。 ⑤現段階の建設 CALS/EC 実証フィールド実験では、従来型の業務と併行させながらでの実証フィールド 実験となることが多いため、業務終了時の検査での文書への押印行為は必要不可欠な作業である。その ため、今回の業務でも紙面としての提出が義務付けられたが、ブラウザ画面からすべての「打合せ記録 簿」を直接印刷することで、この問題には十分対応することが可能であった。 （2）写真データ ①文書データの場合と同様に、工事写真のファイル送信において、できるだけ選択式の項目や自動的に入 力される項目を増やすことによって、記入ミス・記入漏れなどの防止や操作性の向上といったデータの 入力支援ができた。 ②工事写真管理項目の属性情報は、一緒にサムネイル・イメージ形式の工事写真を表示することによって、 今回の実証フィールド実験で設定したような、送信者氏名、撮影年月日、ファイル名、ファイル説明コ メントといった必要最小限の項目で効率的な工事写真管理の支援が行えた。 ③工事写真の整理・編集方法に関して、今回の実証フィールド実験では、全ての工事写真がサーバー上の 同一のフォルダに保存・格納されるように設定した。これは、フォルダを階層化して整理することによ る検索作業の複雑化を防ぐためであり、ここではファイル名を一定のルールに従って付けてさえいれば、 工種別や撮影年月日別などのフォルダの作成作業も必要なくなり、また工事終了後での再利用といった 観点でも、非常に効率的な工事写真管理が行えた。 5. 結論 16 本論文は、建設業界において建設 CALS/EC の導入が進む中、共有サーバーの在り方についての提案を行っ た。更に、電子データの「標準化」について問題提起を行い、その解決のため、文書データと写真データの 2 つの側面からアプローチを試みた。以下に本論文で明らかとなったことをまとめる。 （1） 第 2 章では、建設業界の情報化として現在、建設省を中心に導入・推進が検討されている建設 CALS/EC について、その概要と具体的な活動状況を述べた。その中で、受・発注者双方の管理下にある場合の 共有サーバーを導入することによる情報管理上の問題点を指摘し、その代替案として第三者機関に管 理を委託する外部共有サーバーの導入を提案し、その必要性を述べた。 （2） 第 3 章では、建設 CALS/EC における各種電子データの標準化の問題点を踏まえて、コンピュータの 機種やソフトウェアの種類に依存しないシステムの構築に必要となる既存のウェブ技術について、そ の機能や設定方法など具体的に説明を加えた。それらの既存のウェブ技術は、すべてサーバー側のパ ソコンでインストールおよび設定を行うことによって、クライアント側のパソコンには無償で配布さ れている Internet Explorer や Netscape Communicator などの一般的なブラウザ・ソフトのみで参加 可能にするシステムの構築を実現した。 （3） 第 4 章では、既存のウェブ技術によって構築したシステムの実証フィールド実験として 2 つの適用事 例を紹介した。大戸川ダム建設事業への適用では文書データについて、佐敷大橋（仮称）建設工事へ の適用では写真データについてそれぞれ着目し、これらの実証フィールド実験を通して、構築したシ ステムが実業務に十分に耐えうることを確認した。 謝辞 17 本論文を進めるにあたって、終始、適切な御指導を下さいました熊本大学環境システム工学科の小林一郎 教授には心からお礼申し上げます。また、株式会社鴻池組土木本部技術企画部情報課の福地良彦氏、近畿地 方建設局大戸川ダム工事事務所の山本一浩氏には、現場サイドから広い範囲での意見や助言を頂きましたこ とに深く感謝致しております。 学生生活を振り返ってみれば、施設設計工学研究室に配属されてからの 3 年間は非常に有意義なものでし た。熊本大学環境システム工学科の星野裕司助手、熊本大学大学院博士課程の緒方正剛氏、橋本淳也氏、山 下真樹氏には公私共に御指導頂きました。また、熊本大学大学院博士前期課程の平田誠君、本田泰寛君、村 岡哲君をはじめとした研究室の仲間とは、共に楽しく充実した時間を過ごすことができました。深く感謝致 しております。特に、熊本大学大学院博士前期課程の吉村真一君、熊本大学工学部環境システム工学科の松 永正大君には先輩らしいこともできず、非常に申し訳なく思っております。あわせて、平成10 年度修士課程 卒業で現在、西松建設株式会社に勤務されている大村祐司氏をはじめとした研究室の先輩方にも深く感謝致 しております。 最後になりましたが、大学・大学院 6 年間の学生生活を全面的に支援してくれた両親をはじめ家族全員に 心から感謝して、本論文を終えたいと思います。 平成 12 年 2 月 10 日 参考文献 18 1）公共事業支援統合情報システム（建設 CALS/EC）：http://www.moc.go.jp/tec/cals/index.htm 2）山本一浩、小林一郎、緒方正剛、関宏一郎：Web 技術を用いた CALS/EC 実証フィールド実験、第 54 回年次学術講演会講演概要集第 6 部、pp.294-295、1999.9 3）松永正大、山本一浩、小林一郎、関宏一郎：建設 CALS/EC 実証フィールド実験を支援するウェブ技術 について、平成 11 年度土木学会西部支部研究発表会講演概要集、2000.3. 4）吉村真一、山本一浩、小林一郎、関宏一郎：ウェブ技術を用いた第三者工事確認システム、平成 11 年度 土木学会西部支部研究発表会講演概要集、2000.3. 5）松永正大：ウェブ技術における XML の利用の可能性について、平成 11 年度熊本大学卒業論文、2000.2. 6）アドビ システムズ株式会社：http://www.adobe.co.jp/ 7）マイクロソフト株式会社：http://www.microsoft.com/japan/ 8）寺田祐司、知北直宏、中島一慶：Windows NT 4.0 インターネットサーバー構築ガイド、ソフトバンク 株式会社、1998.3. 9）山田祥寛：今日からつかえる Active Server Pages 2.0 実用サンプル集、株式会社 秀和システム、1998.12. 10）升屋正人：Active Server Pages 構築術 −Windows Web サーバー構築ガイド 活用編−、ソフトバン クパブリッシング株式会社、1998.9. 11）BASP21 コンポーネント：http://www.hi-ho.ne.jp/babaq/ 12）日本ヒューレット・パッカード株式会社：http://www.jpn.hp.com/ 13）建設省近畿地方建設局大戸川ダム工事事務所：大戸川ダム建設事業概要、1999.6. 14）熊本県芦北事務所：明日へつなぐオレンジベルト ORANGE BELT （芦北地区・芦北 2 期地区広域営 農団地農道整備事業）、1997.4. ）平井裕二郎、小林一郎、星野裕司、福地良彦：ウェブ技術を用いた施工管理支援システムの構築と 15 その運用、土木学会第 24 回土木情報システムシンポジウム論文集、pp.49-56、2000.10. 19
© Copyright 2024 Paperzz
