ワークフロー分析による建築生産の効率性向上手法−業務モデルと関連基準類との相互参照を可能としたシステムの活用−
建築生産研究グループ

目
Ⅰ

はじめに

Ⅱ

研究の背景

Ⅲ

ワークフロー

主任研究員

眞方山

次

１）ワークフローとは
２）ワークフローの定義
３）ワークフローで用いられる用語
Ⅳ

建築生産を対象とした業務のモデル化
１）モデルの必要性
２）モデルの表現方法
３）モデル化の方法論
４）本研究でモデル化の対象としたプロジェクト
５）IDEF0 概説

Ⅴ

各種基準類等の構造化
１）ワークフローモデルにおける基準類等の現れ方
２）構造化文書
３）構造化の利点
４）構造化文書の実用例・応用例
５）ワークフローモデルと基準類等における相互参照関係の解析支援システム

Ⅵ

業務モデルと関連基準類との相互参照を可能としたシステムの活用−サッシ設計プロセスの事例から−
１）サッシ設計プロセスを対象としたシステムの事例
２）サッシ設計の業務モデルの作成
３）関連基準類等文書の構造化
４）IDEFO から見たサッシ周りの典型的トラブル例の原因
５) IDEFO 形式による記述の利点、活用方法等
６）サッシ設計プロセスを対象とした事例検討からの課題

Ⅶ

おわりに
参考文献

−1−

美穂

Ⅰ はじめに支援 IT ツールなども利用しやすい環境が整ってきたため、建築生

本報告は、平成 14 年度より 3 ヶ年計画で取り組んでいる「建築産のような、従来適用が難しいとされてきた可変部分の多い組織に生産におけるワークフロー分析・計画技術の研究開発−建築生産の対してもワークフロー分析が可能になりつつあると考えられる。建合理化を目指して−」の成果の一部をとりまとめたものである。こ築生産のワークフロー分析により、ワークフローの改良や新たなワ

こでは、課題名にあるワークフロー分析・計画技術の概要を述べる

ークフローの構築なども可能となると考えられ、また、建築生産にと共に、ワークフローを適用した事例について紹介し、業務の効率おけるワークフロー計画は、成果品である建築物の価値に関する化など、これによって期待される効用について報告する。

様々な評価を交えて検討されるべきであり、これらをパッケージとして組み上げる価値はたいへん大きい。

Ⅱ 研究の背景
建築生産における「国際化」は、単に資材等が海外から輸入されるという部分だけではなく、設計行為や工事の労務にまで至ってお

Ⅲ ワークフロー１）ワークフローとはり、従来の日本型の発注方式のままでプロジェクトを遂行できるとワークフローの定義はあいまいで、旧来のオペレーションリサー

いう環境は、大きくかわりつつある。また、国内でもこれまでの発チの各種の手法や現在一般的に使用されているグループウエアな

注方式において問題とされるコスト管理をより透明化することがどと重複する観念も多く含まれ、これらとの違いを正確に記述する

望まれるようになり、さらには地球環境問題が意識され始めるようのは難しい。ここでは、標準化団体による定義を紹介するにとどめになってからは、建築プロジェクトそのものに対する取り組みが事る。

業の当事者だけではなく、一般市民なども参画するようになるなど、
プロジェクトの運営方法にも変化が見られるようになっている。

２）ワークフローの定義

このような状況の中にあって、外資の日本進出により、従来の日

ワークフロー(WORKFLOW)の標準化団体である Workflow

本型発注方式から発注者自らコスト管理などを実行する欧米型のManagement Coalition(WfMC) は、ワークフローを以下のように定プロジェクト運営スタイルが徐々に浸透してくるのは確実な趨勢義している。

にあり、プロジェクトマネジメントという言葉も頻繁に耳にするよ
うになってきている。

ビジネスプロセス全体あるいはその一部の自動化であり、これによってドキュメント・情報・タスクが、手続き

今後、公共ならびに民間の建築プロジェクトにおいては、欧米型規則に則って、担当者から担当者へと引き継がれる。

のノウハウをそのまま受け入れるのではなく、日本的解釈（もちろ

この定義では直接的に表現されていないが、ワークフローとは単ん付加価値増加の方向で）を加えた管理技術の創造が期待される。

なる「仕事の流れ」という意味ではなく、仕事の流れの「自動化」

そのためには、建築生産全般にわたって製品を作るプロセスとそのの意図までを含むと考えられる。

マネジメントとの両方とを分析し、計画する技術を開発する必要がある。

ワークフロー管理に関しても同様に、複数の担当者がネットワークを経由して仕事をする際

この一つの方法として、ワークフロー分析技術というものがある。
ワークフローとは、狭義では（決済）文書の流れを意味する。ここに、作業を円滑に進めるために、担当者間で受け流すドキュメントや情報の流れを管理し、自動化すること。

数年、文書の流れをモデル分析することにより組織の構造や仕事のと定義している。そしてワークフロー管理を実現するシステムをワ

手順を解析するために利用されている。この技術は、IT 分野におークフロー管理システムと呼び次のように定義している。

けるモデル表現・分析技術の向上と、それらを可能にする計算処理

１つまたは複数のワークフロー・エンジンの上で動作す能力の向上により可能となっている。これまでは、主としてオフィ

るソフトウエアにより実行されるワークフローを定義し、スや一部の工場などでの適用事例の報告がある。

生成し、運用するシステムである。それはプロセス定義デ

建築プロジェクトは、
通常、単独組織により営まれることはなく、ータを解釈し、ワークフローの担当者と相互採用し、必要

また、生産現場が特定されないことなど組織構成そのものが可変的に応じてアプリケーションを起動する。同時に、ワークフ

で一般化しにくい傾向があり、ワークフロー分析が適用しにくい分

ローの実行を監視し、その履歴を記録する。

野であるとされてきた。しかし、ワークフロー技術の普及に伴い、−2−

建築プロジェクトに参画する受注者には、発注者の提示する個別

３）ワークフローで用いられる用語
建築生産研究においてなにげなく使われる用語には「（ビジネス）

的な制約条件や法律等をはじめとする社会的な制約条件等のもとプロセス」、「サブプロセス」、「アクティビティ」、「ワークアイテム」

で、発注者のニーズを実現することが求められている。従って建築などが多く見られる。図１に、ワークフロー関連用語の概念構成を

プロジェクトの適切な管理には、コスト、品質、環境、安全等の配示す。同図ではそれぞれの関係がツリー構造で示されている。本報

慮事項をプロジェクトの制約条件に収めるとともに、発注者のニー

告では、これらの用語の上位下位の関係性を常に意識して出来るだズを最大限に実現する最も合理的なプロジェクト運営の選択が不け混乱が生じないような記述に努めている。ただし、スコープ設定

可欠と言える。このため、設計者や施工者など建築技術の専門家だ

や分析粒度を変えれば、モデルのある局面では単一のアクティビテ

けではなく、発注者にもプロジェクトにおけるニーズ と制約条件

ィにすぎないものが、別の局面では独立したビジネスプロセスとしをバランスさせ、合理的なゴールを設定する責任があり、この責任てみなされるべき詳細さを持つに至ることも十分にありえる。実際、の重要性は従来に比べてより増してきている。

本研究で採用している IDEF0 モデル化手法では、モデルの詳細レ

一方、ユーザーである一般市民らの参画など、建築プロジェクト

ベルを階層構造で管理する手法がとられている。したがって、混乱にコミットする主体の多様化も進みつつある。例えば、環境問題等を避けるためには、異なる詳細レベル間をまたがるような視点でモが深刻さを増す中で、建築プロジェクトを実施すること自体が環境

デルを議論することはできるだけしないように心がけた。

や社会に与える影響についても議論されるようになった。この傾向

Business Process

は、公共の建築プロジェクトにおいて特に顕著である。このように、(i.e.. what is intended to happen)

is managed byais defined in a
Process Definition

Workflow Management System(controls automated aspectsof the business process)(a representation of what
is intended to happen)

Activities

整すべき事柄はあきらかに増大してきている。

via

composed of

Sub‑Processes

建築プロジェクトの実施において発注者が積極的に関与し検討・調used to create& manage

Process Instances(a representation of whatis actually happening)which may be

include one
or moreor

Manual Activities
Automated Activities
Activity Instances
during execution(which are not managed as
which
are
representedbypart of the Workflow System)
include発注者は一般に建築の専門家ではない場合がほとんである。そのため、前述のようにプロジェクトが複雑さを増すに従って発注者に課せられる役割が大きくなっていく現状にあっては、これを支援するしくみが必要である。近年、国内の建築プロジェクトで適用されている PM（Project Management）方式は、発注者の代理人として専

and/orInvoked Applications

門知識を持った PMr（Project Manager）を配置し、プロジェクトを(computer tools/applications
used to support an activity)

運営するものであり、これも発注者を支援する方法の一つと考えらWork Items(tasks allocated to aworkflow participant)② モデルの効用

れるが、これとは別に、発注者の役割を明確なモデルとして整理し、
１

そのモデルを適宜参照し利用するためのフレームワークの構築が

図１ ワークフローの用語望まれている。
Ⅳ 建築生産を対象とした業務のモデル化

また、発注方式そのものも多様化しているため、伝統的な建築生

１）モデルの必要性

産プロセスに基づく契約規範が必ずしも適用しなくなるケースも① 建築プロジェクトにおける発注者の役割

増えてきつつある。このような観点においても、発注者の積極的な

建築プロジェクトは一品生産であり、プロジェクト毎に生産組織関与が要求されるこのような環境下においてプロジェクトを成功が編成される点で製造業などと比較して特殊である。生産の仕組み

させるためには、プロジェクトで実現されねばならない業務内容をに着目しただけでも、以下のような特徴をあげることができる。

担当各主体が確実に把握・実施できるようにすることが必須である。
これらのためには、「プロジェクトの可視化」が有効な手段とな

1. 一品生産・注文生産である。

る。業務モデルは、言葉のみでは表現が困難な複雑な業務の構造を、

2. 属地的生産であり、永続的な生産拠点を持ちにくい。

図表現を主に言葉による補足説明を交えて表現するものである。製

3. 設計・製造・施工・維持段階が企業的に分離している。

造業における製品の製造プロセスの管理（Product Oriented Process:4. 請負契約によって施工される。

POP）モデルの開発事例は多いが、建築生産における POP モデル−3−

は、建築生産の一回性もあってほとんどない。さらにプロジェクト

1. 業務内容を明確に表現できる

マネジメントのプロセス管理（Project Management Process: PMP）モ

2. 役割分担（各主体の業務範囲や責任分担）を明確に表現デルとなると皆無と言ってもよい状況と言える。

できる

本研究では、ワークフロー分析の結果から、建築生産における3. 業務を実行する目的及び根拠を明確に表現できる

PMP(+POP)モデルを提示することを一つの目標としている。業務
モデルを活用することで、プロジェクトの計画を短期間で精度良く業務モデルを図的に表現する手法は数多く存在している。プロジ

立案することが可能となる。また、業務モデルの表記方法を統一化ェクトマネジメントに用いられている一般的なモデル表記手法とすることで、過去のプロジェクト事例の経験を活かすことが可能としては WBS（Work Breakdown Structure）と OBS(Organization

なり、従来は埋もれて伝達されることのなかった知識や経験の蓄積

Breakdown Structure)のマトリックスがある。これは、上記の 1.及びや活用を促進し、よりよいプロジェクト管理、ひいては建築物の品

2.を充足している。また、市販のプロジェクト管理ツールとの親和質確保等に資すると考えられる。

性も高く、WP（Work Package）の記述を工夫すればノウハウ等の蓄積にも対応可能と思われる。

③ リファレンスモデル

しかしながら、建築プロジェクトにおいては、プロジェクトの全

建築生産の効率化において業務モデルの活用は有効であるが、フェーズにおける参画主体が当初から明確になっているケースは個々のプロジェクト毎にモデルをいちから作成するのはコストも希であり、制約条件や資源が当初段階で明確に規定されていないこ

大きく現実的でない。汎用性の高い雛形があれば効率がよい。このとが多い。最終的な労務や資材の調達まで視野に入れると、当初計「汎用性の高い雛形」の集合をリファレンスモデルと呼ぶこととし、画で想定した能力を有する主体が地域に存在していない場合もあ

本研究の最終的な目的はリファレンスモデルをできるだけ充実しる。そこで、プロジェクトの進捗と参加者の能力に応じて当初設定た形でツールも含めて提示することとした。

した役割と責任の分担を、発注者と受注者も含めて動的に変更でき

リファレンスモデルをベースとしたツールは、発注者あるいはそる構造を有する必要がある。

の代理である PMr の計画立案を支援するものとなる。このツール

役割と責任の分担を変更する場合においては、プロジェクトの活により、プロジェクトの各アクティビティにおける制約条件、要す

動単位であるアクティビティの分割・結合・加除も含めた検討が必る人的物的資源および成果物等の情報を可視化することが可能と要となる。アクティビティの分割等がプロジェクト全体にもたらすなり、プロジェクトの各主体の役割を明確化すると共に、情報の蓄影響を正確に把握するには、アクティビティの目的・根拠を明確に

積・共有・再利用も促進される。

表現できることが必須であり、WBS は上記 3.の表現力に乏しいとまた、リファレンスモデルにノウハウに相当する明文化されてこ考えられる。

なかった情報を蓄積することで、発注組織に所属する個人の経験や一方、建築生産における代表的なモデルとして、業務手順を表現

過去の情報を蓄積して組織的に利用することも可能となる。発注者するプロセス記述手法がある。先の 1.〜3.の内容は PERT や CPMがプロジェクトに適したリファレンスモデルを予め整備し、契約し等のプロセス記述系言語で表現することが可能である。しかしながた PMr に提供することにより、PMr の資質によりにくい安定したら、建築プロジェクトの環境は千差万別であり、各主体の役割が錯

プロジェクト管理の品質を実現することができる。

綜している場合には、必要な業務におちがないように「どの役割がどの業務を分担しなければならないか」そして、「その業務がどう

２）モデルの表現方法

して必要なのか」を確認することが重要であり、ある特定のプロジ

リファレンスモデルは、建築プロジェクトの全容、特に PMP にェクト環境下での手順を表したモデル（プロセスモデル）が、別のおける業務内容の把握を支援することを目標に、業務の目的と内容

プロジェクト環境でも有効であるとは限らず、再利用性の点で疑問が明確かつわかりやすく表現されている必要がある。さらに、プロが残り適当ではない。

ジェクトにおけるノウハウや経験の蓄積を可能とするため、これまで具体的に記述されることがなかった知識を形式化して表現でき
ると望ましい。この様な条件を満たすため、モデルの記述手法には以下の機能が要求される。

３）モデル化の方法論
モデル表記手法の備えるべき条件を整理した結果、本研究におけるモデル表記手法として IDEF0 を採用することとした。前節で述−4−

べたように、最近の建築プロジェクトは、参画主体やプロジェクト考えられることから、部分的に実務担当者に対するヒアリング等を運営形態が多様化し、加えて建築プロジェクトの目的自体も複雑化実施した。最終的には公共建築プロジェクトを対象に、全てのフェしている。このような中で、効率的なプロジェクト運営を可能にすーズのモデル化を目標として、検討作業を進めた。

るため、モデルはプロジェクト全体を俯瞰する視点から作成される必要がある。モデルを記述するにあたり視点を明確にする方法をとる IDEF0 は、この点で適切な手法と言える。

５）IDEF0 概説
本研究では把握した業務を表記する方法として、図 2 に示す

本研究は建築生産における PMP のモデル化を目標としているが、IDEF0 による標記ルールを使用している。IDEF0 は行為を表すアクモデル作成のアプローチとしては、建築生産の POP の分析から着ティビティ、それに関連するインプット、アウトプット、コントロ

手することとした。ただし、あくまで PMP の管理対象としてのール、メカニズムにより業務プロセスをモデルとして表現する手法

POP の分析を対象とし、POP をモデルとして不必要に詳細に分析である。以下に、それぞれの用語の概要を示す。

することは研究目的とはしていない。

(1)インプット・アウトプット（Input / Output）
ある行為を行う上での用いた情報や資材をインプット、ある行為を行った結果としての成果物をアウトプットとして、モデル化する。

４）本研究でモデル化の対象としたプロジェクト
背景・目的のところで述べたように、本研究では、ワークフロー

今回の業務のモデル化においては、インプットとアウトプットは情分析・技術を、発注者または発注者の代理人である PMr を支援す

報（文書）であることが多いと予測された。業務項目の分析・検討るためのツール開発につなげるたいと考え、基本的に発注者の視点作業において参照した文献等に記載されているものを中心にこれでの業務モデルの検討を進めることとした。

らの情報を抽出した。

通常、IDEF0 でモデルを作成する際には、as is モデルと呼ばれ(2)コントロール（Control）

る実際の業務のモデルの作成から着手する。しかし、PMr はまだ国コントロールとは、ある行為を行う上での制約条件である。今回

内で職能として確立しているとは言いがたく、サンプルの収集が困のモデル化においては、基準類をコントロール情報として取り扱っ難であった。そこで、「意識の高い発注者」や「献身的な設計者」ている。一般に IDEF0 のモデルにおいて、コントロールの存在し等が実際には PMr の役割を担っているものと考え、その様な役割ないアクティビティは存在する意味が無いとされているが、実際のを担う担当者の事を、「発注者」もしくは、発注者から選任された業務においては過去のプロジェクトの経験等に基づく、文書化されPMr と位置づけ、その担当者の視点での機能モデルを作成するこていないコントロールが存在している可能性が否定できないため、ととした。対象としては、国や地方公共団体等が発注者となる公共検証を行うまではコントロールの存在しないアクティビティを許建築工事を選定し、調査・モデル化を試行することとした。公共の容することとした。

建築プロジェクトにおいては発注側に建築の技術者がおり、そこでまた、基準類等であっても、「標準詳細図」等の様に図面への記

プロジェクトのマネジメントが行われているため、「意識の高さ」

載を簡略化するために用いる資料等は、メカニズムに含めることがが期待できるからである。公共建築プロジェクトの業務をモデル化妥当と考えられるため、内容を含めて検討することとした。

することにより、発注者として具体的になすべき行為を把握でき、(3)メカニズム（Mechanism）

また、事業化から維持管理にわたる一連のプロセスを一つの組織がメカニズムは、ある行為を行う主体、また、用いた解析ソフト等一貫して携わっていることから、PM 方式等へ展開する場合の検討もメカニズムに分類される。今回検討対象としている公共建築プロも可能になると想定した。

ジェクトにおいては、担当者の業務が定型的でなく、組織によってまた、発注者の視点による機能モデルの作成あたっては、法や基業務が担保されているケースが多いことから、今回のモデルでは必

準類に記述されている業務について、それらを実行することの目ず組織をメカニズムとして設定することとした。

的・根拠を明確にしながら各行為を抽出した。さらに、それぞれの(4)アクティビティ（Activity）

行為を実行する際に用いた資機材や図書類など入力となるもの、実アクティビティは、粒度の小さい複数のアクティビティを階層化行した結果である成果物（出力）、各行為を実行した人やツールなして包含することにより、煩雑な表記を避けることが可能である。

どのリソース等についてもあわせて抽出・整理した。また、業務ルールの中には基準類等に記述されていないものも多数存在すると−5−

Ｃｏｎｔｒｏｌ

Ｉｎｐｕｔ

ように、文書は構造を有しているのにあえてそれを構造化するとす

Activity

るのは屋上屋を架すかのようであるが、ここではまず、本研究におＣｏｎｔｒｏｌ
A1
Mechanism

ける構造化文書の定義を述べることからはじめる。

Output→ＩｎｐｕｔActivity
A2"
Mechanism

Ｃｏｎｔｒｏｌ
Output→ＩｎｐｕｔActivity

OutputA3① 計算機により処理が可能な文書について
一般に、コンピュータによる文書処理においては文書の電子化がMechanism

前提となる。本研究では、計算機処理に適した電子文書として文書

図２ IDEF0 によるプロセスの表記を構成しなおすことを構造化と定義する。この定義において、構造Ⅴ 各種基準類等の構造化

化には次の二つの目標が与えられる。
1 .文（コンテンツ）と書式（スタイル）の分離

１）ワークフローモデルにおける基準類等の現れ方
前章のモデル図において見られたように、法律を含む基準類等は2. 意味の まとまり の管理

Activity への Control や Mechanism として参照（結合）される（図 3参照）。現状ではいずれも紙面上に構成される情報であるため、対文と書式の分離

応関係の確認の効率化には制約がある。ワークフローモデルの評文とはいわゆるテキストであり、書式とは文字フォント、行間、

価・分析において、これらのアロー（ICOM）が指示する基準類等

段落構成等々を意味する。本文、見出し、注といった論理的なカテの記述内容を手早く確認できれば効率的であると考え、このようなゴリーも書式である。文と書式が分離してそれぞれを独立して操作パターンを抽象化し電算システムとしての実装を検討してきた。

可能とすることが第一の目標である。たとえば、同じテキストに対システムとして実装するためには、ワークフローモデルと基準類して異なる書式を適用することにより複数文書の作成を省力化す等の両者を電子化し、これらを相互に関連づける手段が必要となる。

ることが出来るし、その反対に同じ書式に対して異なるテキストを本研究では、実際の業務を IDEF0 によりモデル化したものと電子適用することで文書作成の効率を同様に向上させられる 。

化された基準類等を複合・連携させ、相互参照可能なシステムの開。次節以発を行った（プロトタイプの名称を BRI IDEF0 と命名 ）降に構造文書化に関する解説ならびにこの相互参照を可能とする

意味の まとまり の管理
意味的まとまりが明確であることにより、文書の情報伝達性が向システムについて簡単に紹介する（このシステムの詳細については、上する。本研究のモデル化作業においても、たとえば「○章□節参

参考資料４を参照）。

照」のように、文書中の特定の一部を指示する記述が多くあった。
この場合、参照元での表現「○章□説」そのものは位置を示す情報

基準類への参照
コントロール

基準類等でしかないが、参照先の節にはテキストがあり意味的に有意義なまとまりを形成している（そのように記述されている）はずである。

インプット

アクティビティ

章や節といった文書の構成要素は意味を形成するテキストを包みアウトプット

こむ入れものに例えられ、これらを活用することにより情報伝達性が高まる。さらに情報伝達性の向上を目的として、書式をテキストから独立して設計しておくことで汎用的な管理手法の適用も可能

メカニズムとなる。これが構造化の第二の目標である。

② 構造を伴わない文書への処理方法

図３ IDEF0 アローの参照情報概念図

一方、前節で述べた二つの目標や思想とは無縁に電子化された文

２）構造化文書
文書はもともとなんらかの構造を保有しているものである。起承書も数多く存在し、現在ではこちらの方が主流である。Microsoft ®

転結のように物語の構成も構造の一種であるし、学術論文の基本的WORD などは構造化文書として文書を構成することもでき、日常な体裁「アブストラクト＋本文」も同様である。論理的構成、意味的な WORD の使用に十分な配慮があれば外部プログラムを用いて的構造、物理的書式等々、これらはすべて文書の構造である。この付加価値の高い計算機処理をさせることも可能だが、たいていの−6−３）構造化の利点
前節でも簡単に述べたが、構造化の利点は計算機処理が自在になるということである。これをより具体的に説明する。
まず、構造化文書は単一のソースから多様様な出力を得ることが出来るため、例えば仕様書の類であれば構造化により、(1)HTML
形式に変換して Web ブラウザに対しオンラインで供給することで配布コストを下げかつ常に最新版を提供することが出来る、(2)eXtensible Stylesheet Language Formatting Object(XSL-FO)に変換して組版用の出力を得ることもできる、(3)全文検索システム管理下に配置して任意の属性、キーワードによる閲覧を可能とする、などが可能となり、これらはすべてソースを改変することなく実現することができる。版下の作成に現在投じている手間を文書構造化に投入すれば、多彩な応用が可能となり、また、構造化に掛かるコスト
は版下作成のそれと変わらないと予想され、資源効率も大変良くな
図４ CAD 図面に対する全文検索システム

ると思われる（図 5 参照）。

場合このような配慮はなされていないために構造化を前提として適用可能な文書処理のノウハウは役に立たない。

さらに、書式をもとにした文書管理が実現できる。たとえば、意
味的なまとまりで範囲を限定した上で、(4)部分の強調表示やユー

では、構造化文書とはいえないがパソコンのディスク上に存在すザの権限に応じた閲覧の許可／不許可、(5)同じく特定部分を編集る膨大な電子文書に対して有意義な計算機処理手法は存在しない

対象あるいは禁止とする、(6)記述の変遷を履歴情報として文書中かといえばそうではなく、GoogleTM などの代表的な検索サイトでに残し必要に応じて参照可能にする、などが可能となる。

はインターネット空間の膨大な文書に対するキーワード検索を可能としている。このようなシステムを一般に全文検索システムという。
全文検索システムを用いれば、構造化されていない文書に対しても自動的に検索用のインデクスを生成し対応表を作成できるので、文書のキーワード検索が可能となる。AutoCAD®の DWG ファイルに対してもキーワード検索を実行することは可能となっている。図4 に示すシステムは Namazu とよばれるフリーの全文検索システム
図５ 単一ソースから多様な出力を得る５に AutoCAD®の DWG ファイル用のインデクサ を追加して実現している。建築分野において、図面内の注釈（寸法なども含む）に対するキーワード検索は 2004 年現在あまり一般的ではないが、いずれはあたりまえのことのように利用されるようになるであろう４。
全文検索システムの手法は非構造化文書のみでなく構造化文書にも当然有効なので、事前に定義された構造を活用するアルゴリズ
ムへの補完機能として有効である。書庫に蓄えられた文書から適切なものを手早く探し出せるメリットは全文検索システムの運用から学べるが、ここでの経験を踏まえて個々の業務に特化したより高４）構造化文書の実用例・応用例
前節のとおり、構造化により得られる恩恵は数多いが、すでに応用例もいくつか報告されている。ここでは代表的な事例を数例紹介する。
① 法令・条例のシステム
総務省のホームページ や東京都のホームページ では、条文間の参照関係をトラバースできるように、初歩的ではあるが構造化が施

機能・高性能な検索を可能とするニーズが明らかとなり、構造化をされているとみなせる機能を有している 。これらは HTML で記述含めた新技術の適用が試みられるようになると予想される。

されているが、HTML という規格そのものも XML による再定義（XHTML）へと移行しつつあり、法令・条例システムでもより多−7−ワークフロー定義
情報はすべてデータベースで管理

様な使い方を可能とする構造化へと発展していく可能性は高い。

基準図書・マニュアル等

ワークフロー② 医療用ＸＭＬ（Medical Markup Language, MML）
データベースMML は異なる医療機関（異なる電子カルテシステム）の間で、診療データを正しく変換するために設計された規格である。建築分
野でも異なる CAD システム間でデータを共有するために中間ファワークフロー情報の授受

イル形式を用いることがあるが、MML も同様の考えにもとづいて構成（ ブックマーク） 情報の自動更新

XML形式で記述

XSLT付きで文書を参照

チームウエア版ではクライアントÙ
データベースサー
バ間はLAN上にそれぞれ独立して配置される。

いる。各電子カルテシステムは MML の読み書き用のサブシステムを増設するだけで、他の電子カルテシステムとデータのやり取りが可能となり、医療機関間で医療情報を共有することが可能となる。

クライアント

また、XML 文書は興味のある任意の部分を自動処理するのに適し

図６ ワークフローモデルと基準類等におけるているため、診療履歴情報データベースへの蓄積に生かすなどのよ相互参照関係解析支援システムの構成り進んだ応用も考えられている。
告する。

③ 公共建築工事の電子納品
電子納品は、国土交通省直轄の業務および一部の業務を対象に平成 13 年度から開始されているが、今後は地方公共団体や民間発注の工事への普及が見込まれている。ごく簡単に言えば、電子納品とは調査、設計、工事などの各業務段階での最終成果を電子データで納品することであり、これの要領・基準は国土交通省のホームペー

これまでの研究により、IDEF0 によるワークフローモデルの分析結果を用いて、アローが指示する基準類等の記述内容を手早く確認できれば効率的であることが分かっている。このためワークフロー
モデルと基準類等の両者を電子化し、これらを相互に関連付ける手段について、開口部・サッシ設計を対象として、ワークフローモデ
ルのパターンを抽象化すること、ならびに電算システムとしての実ジ で公開されている。

装について検討した。
５）ワークフローモデルと基準類等における相互参照関係の解析
２）サッシ設計の業務モデルの作成

支援システム
前節までの要素技術をトータルシステムとしてくみ上げると、図6 に示すシステムを構築することができる。このシステムでは、ワークフローモデルと基準類等の構成情報が、RDB により一元的に管理される点が特色である。これにより、相互の参照関係をインタ
ラクティブに確認することができ、OJT 的な用途から業務モデルの系としての整合性確認まで、幅広い用途が期待できるシステムとなっている。このシステムを用いれば、ワークフローモデル表示から
URI をたどって基準類等の該当部分を呼び出した結果を示すこと① モデル化の方法
サッシ設計に関わる主な生産関与者は、建築設計者、総合工事業者、専門工事業者、材料供給業者などである。具体的に扱われる主な部品には、サッシ、ガラス、シーリング材、グレイジングガスケ
ットなどがあるが、サッシメーカーはサッシを供給する材料供給業者であると同時に施工も行う専門工事業者である。一方で、グレイジングガスケットなどは材料供給業者によって供給されるのみとなっている。
サッシ設計は、建築設計者が設計図書や仕様書に設計内容を記述も可能となる。

していく設計段階から、専門工事業者による現場でのサッシ取付け
Ⅵ 業務モデルと関連基準類との相互参照を可能としたシステム

といった施工段階まで、複数の生産関与者によって比較的長期に渡って実施される設計プロセスとなっている。しかしながら、これらの活用 −サッシ設計プロセスの事例から−の関与者は、互いの仕事を完全に理解しているという訳ではなく、

１）サッシ設計プロセスを対象としたシステムの事例
ここで開口部・サッシ設計を対象として、建築生産におけるワー
クフローについて、過去 2 年間の研究において蓄積したモデル化技
術および構造化文書に関する知見の適用を試みた事例について報−8−

実際には自分の担当する設計プロセスのみを理解しているというのが現状である。
このような状況のため、サッシ設計のプロセス全体を一つの視点

で記述するには適当な視点が不在であった。また、業務モデルの記

なお、本項では省略するが、４）項においてモデルの活用事例説

述のために、プロセス全体を把握している特別な視点を想定して記明と併せて、建築設計者による基本設計段階の業務モデルの例を示述を進めたとしても、関与者が多いこともあり複雑なモデルになるす。

ことが予想された。

表１ 対象とした注文品サッシ設計の業務モデル

そこで、サッシ設計を複数の業務段階に分解して捉えることとし、それぞれの段階で中心的な役割を発揮している生産関与者をモデルの視点として、複数の業務モデルを作成することでサッシ設計の基本設計段階発注･契約段階

実施設計段階

生産段階

施工段階

建築設計者

○

−

○

−

−

総合工事業者

−

○

○

−

○

専門工事業者

○

○

○＊

○

○

全体像を把握することとした。
３）関連基準類等文書の構造化② モデルの視点と対象業務① 関連基準類等文書リスト

サッシ設計の業務モデルを作成するにあたって、モデルの視点を、サッシ設計の業務モデルにおいて「コントロール」として記述さサッシ設計の意志決定に特に関わる者、すなわち建築設計者、専門れていた関連基準類等文書及び、サッシに関連する基準類等文書(

工事業者（サッシメーカー）の 2 者に限定して業務モデルを作成す国土交通省告示、JIS、業界団体で定めた設計指針など多数）を抽ることにした。

出し、それらが何を決めるものであるのかという視点で整理した。

サッシ設計のプロセスについては、サッシ・カーテンウォールの
注文品の設計経験が豊富なサッシメーカーの技術者に対してヒア

その結果、これらの基準類等文書には以下の 5 つのタイプがあることがわかった。

リングを行い、その結果をもとに IDEF0 形式で業務モデルの記述

1．強制力のあるもの （例：法規）を行った。なお、サッシには大きく分けて標準品と注文品があり、

2．強制力はないが、多くの場合使用されるもの

さらにサッシの開閉方式によってもそれぞれ設計プロセスは大きく異なってくる。ここでの業務モデルの記述においては、注文品と標準品の場合のそれぞれについて、引き違い窓を事例として検討を進めることとした。

（例：業界自主基準）
3．契約によっては使用されるもの（例：公共建築工事標準仕様書、次世代省エネルギー基準）
4．性能・寸法等の決定の際、参考となるもの（例：各種性能の目安、強制力のない法規（騒音基準））③ 作成した業務モデルの概要

5．その他 （JIS A 4706 サッシ(2000)5.性能（性能項目・等級・

ここでは建築設計者が各種性能値・等級、必要寸法を全て決定し、等級との対応値（等級の区分と表記方法を示したもの。
）、

サッシを発注するという、理想的な場合を想定している。実際の注JIS の各種試験方法（性能を検証するためのもの。一般的

文品の設計業務では、各種性能値や必要寸法等が未定のまま作業がな注文品の設計では行われない。
））

進んだり、それが原因で建築設計者への確認、建築設計者による各種条件・寸法の再検討など様々な手戻りが発生する場合が多く、こここでは、上記の関連基準類等文書のなかから代表的なものについて、構造化の試行を行った。

れら全てをモデルに表現する事は難しい。従ってここではサッシ設計の全体像を把握することを主眼と考え、最も理想的な状態をモデル化することとした。

② 構造化文書化の有効性の評価
IDEF0 によって記述されたワークフローに従って業務を行う場

今回作成した業務モデルの一覧を表 1 下記に示す。前述の様に、合、構造化文書化の利点としては以下の点が挙げられる

サッシ設計を複数の業務段階に分解して捉えることとし、それぞれ

1．基準類等文書の構造化によって、そのアクティビティに必要の段階で中心的な役割を発揮している生産関与者をモデルの視点な部分だけを参照することが可能であり、設計作業の効率化

として、複数の業務モデルを作成した。 表中「○」は、その生産を図ることができる。

関与者がその段階で主要な役割を発揮していることを示している。
「＊」はサッシ設計の特に中心的な業務を行っている段階であり、今回 IDEF0 形式で記述をしたものを示している。
「−」はその段階
で主要な役割ではない事を示している。

2．関与者はそのアクティビティ基準類等文書を漏れ落ちなく参照ができるため、設計品質の確保に有効である。
3．基準類等文書がオンライン供給されるシステムが構築されれば、常に最新版を参照できる。

−9−

の所在をより明確に表現することができれば、すなわちトラブルに対する対策を前章で説明した「相互参照シス
テム」の中に組み込むことができれば、経験の浅い実務者の教育や事前のト
ラブル防止対策を講じることができるため、有効である。
ここで、サンプルとして「[開口部]解体新書 脱クレーム!![窓設計]おさらいゼミナール／最終回 不具合に学ぶ応用知識」（建築知識、2003 年
12 月号、エクスナレッジ）に掲載された典型的トラブル 32 例を取り上げ、業務モデルと対応させて表示される効果等について検討した。ここで取り

図７ 建築設計者による基本設計段階の業務モデル「Ａ０ 標準品サッシを設計する」

上げた事例は、大きく(1)サッシのト
ラブル、(2)ガラスのトラブル、(3)シーリングのトラブル、(4)グレイジン
グガスケットに関するものに整理することができるが、ここではその中の一例として、サッシのトラブル事例について、
2)項で作成した IDEF0 のモデルと併せて以下に紹介する。

① サッシのトラブル事例１（図 7 参照 Activity；Ａ０）(1)取付け後に防火設備対応製品でないことが分かった
原因：延焼のおそれのある部分の判断ミス及び、網入りガラスを入れれば全て防火設備対応となると勘違いし
図８ 建築設計者による基本設計段階の業務モデル「Ａ２３ その他の性能について検討する」 Ａ２３１−Ａ２３５ていた。
「建築設計者による基本設IDEF0 上：

4．構造化文書化の応用として、各種性能値の計算プログラムとの連携も考えられる。

計段階の業務モデル」中、「A0 標準品サッシを設計する」のインプ
ット「居室に対する要求」の判断が間違っていた事による。

特に 1、2 は経験の浅い設計者にとって有効な手段となり得る。

(2)非常用進入口に替わる窓の寸法が確保できなかった
原因：非常用進入口を設けなければならない箇所が FIX 窓となっ

４） IDEFO から見たサッシ周りの典型的トラブル例の原因
ワークフロー分析の活用事例として、サッシ回りで生じる典型的なトラブル事例を業務モデルと対応させることで、その原因・責任−10−ており、後から可動サッシに変更しようとしても、必要寸法が確保できなかった。

標準品サッシを設計する」のインプッ
ト「居室に対する要求」の判断が間違っていた事による。
(4)有効排煙面積が足りなくなった
原因：排煙面積の算定で、有効開口寸法ではなく、サッシの幅・高さの寸法を用いていたため。
「建築設計者による基本設IDEF0 上：
計段階の業務モデル」中、「A0 標準品
サッシを設計する」のインプット「居室に対する要求」のうち、「開口部の大きさ」の検討が間違っていた事による。
② サッシのトラブル事例２
図９ 建築設計者による基本設計段階の業務モデル「Ａ３ 開閉方式を決定する」Ａ３１−Ａ３４（図８ Activity；Ａ２３）(5)騒音が大きくうるさい
原因：外部騒音レベルを測定せずに、設計を行った。
「建築設計者による基本
IDEF0 上：
設計段階の業務モデル」中、「A2312
外部騒音を測定する」を行わなかった
ことによる。
(6)アルミサッシが腐蝕した
原因：室内温水プールで、サッシに水が溜まりサッシの一部が強アルカリ状態となった。
「建築設計者による基本設IDEF0 上：
計段階の業務モデル」中、「A233 水密性について検討する」のインプット「開口部の性能に対する要求」の検討が間違っていた事による（プールとい

図１０ 建築設計者による基本設計段階の業務モデル「Ａ４ サッシの仕様を決定する」Ａ４２１−Ａ４２５
IDEF0 上：「建築設計者による基本設計段階の業務モデル」中、「A0
標準品サッシを設計する」のインプット「居室に対する要求」の判う環境を考慮し、水が滞留しないディテールとすべき）。また、「A425 仕上を決定する」の判断が間違っていたことによる（適切な表面処理を選択すべき）。
(7)防火設備としての制限サイズを超えた

断が間違っていた事による。

原因：防火設備が必要な開口部に、防火設備とはならないサッシを(3)梁・床などのたわみによりたて部材が湾曲した使った（このサッシは基本的には防火設備の適合品であったが、あ

原因：梁のクリープ現象。
「建築設計者による基本設計段階の業務モデル」中、「A0
IDEF0 上：−11−

る一定以上の大きさでは、防火設備とはならない仕様であり、その確認を怠った）。

われなかった事による。
(11)窓が結露し壁や床を濡らした
原因：居住者が高い湿度になるよ
うな室内環境設定としていた。
IDEF0 上：防露性を設定するための判断基準がないことが最も大きな問題であると言える。敢えて言えば、「建築設計者による基本設計段階の業務モデル」中、「A0 標準品サッシを設計する」のインプッ
ト「居室に対する要求」の判断が間違っていた事による。もしくは、「A424商品のデザインや取付け金物を確認する」で、結露受けの確
図１１ 建築設計者による基本設計段階の業務モデル「Ａ５ 収まりを設計する」Ａ５１−Ａ５４

認が行われなかった事による。

⑤ サッシのトラブル事例５ (図「建築設計者による基本設計段階の業務モデル」
中、「A235
IDEF0上：11 Activity;Ａ５)

その他の性能について検討する」のうち、防火設備のチェックを怠(12)枠廻りから漏水し、室内を汚したっていた事による。

原因：壁体内の水切板とサッシ枠のメタルタッチ部分の止水に不備があった。

③ サッシのトラブル事例３（図９ Activity；Ａ３）「建築設計者による基本設計段階の業務モデル」中、「A52
IDEF0 上：(8) 窓の開閉の際に障害物があたる

枠まわりの納まりを検討する」、「A53 枠まわりの納まりを確認す

原因：検討不足る」において、正しく検討・確認が行われなかったことによる。

「建築設計者による基本設計段階の業務モデル」中、「A33
IDEF0 上：可動部の移動空間が確保されているか確認する」の確認が行われな不足したかった事による。

原因：標準品（枠見込 70mm）のサッシに、厚い 典型的トラブルの原因としては、施工上の原因によるものも少なくないが、多くの④ サッシのトラブル事例４（図 10 Activity;Ａ４２）

場合が検討不足や、検討のミスによるものである。
また、
今回 IDEF0(9)サッシ溝幅・掛かり代・エッジクリアランスなどがガラスや複で表現したレベルより細かいレベルで行われるべき検討事項にか層ガラスを入れようとした（枠見込 100 ㎜であれば、ガラス溝にもかわるようなトラブルも見られた。

余裕があり、問題はなかった）。
「建築設計者による基本設計段階の業務モデル」中、ガIDEF0 上：トラブル事例の分析は、IDEF0 の表現の妥当性を検討する上で、ラスの仕様をもとに決定する「A421 枠見込寸法を決定する」の検有効な手段と言える。しかし、どこまで細かいレベルを表現するか討に不備があった事による。

は、業務モデルの表記の目的にもよるため、それに応じた表現を行(10)特殊金具の未指示により製作期間が延長した

うことが必要である。

原因：外部からの解錠装置が必要な開口部であったにもかかわらず、解錠装置の設定がないサッシ生を選んでしまった。

５) IDEF0 形式による記述の利点、活用方法等「建築設計者による基本設計段階の業務モデル」
中、「A424
IDEF0上：
商品のデザインや取付け金物を確認する」で、解錠装置の確認が行−12−

IDEF0 形式によって記述することで生じる利点と、その活用方法を考察した。結果を以下に示す。

(1)一品生産と言われる設計行為でも、対象を限定し条件を整理

図面等、様々な資料を参考にしている。これらの参考資料もこすることで、設計プロセスをある程度一般化する事が可能であのシステムに組み込むことで、実際の業務での資料参照ツール

り、その結果、統一した視点から設計行為全般を捉えることがとして用いることが可能となる。

できる。
(2)IDEF0 形式で表現する事によって生じる基本的利点としては、

６）サッシ設計プロセスを対象とした事例検討からの課題

各アクティビティで参考にすべき情報が「コントロール」とし注文品サッシの設計プロセスは、設計対象であるサッシが異なるて表記されているので、作業時に何を参考にすればよいかがわ

設計条件下で行われる一品生産の開発行為であるため、その設計プ

かりやすくなる。さらに、実際の業務の中でははっきりと認識

ロセスが必ずしも一様に定まっていない。特に各部の仕様を検討、されていなかったアクティビティの優位性が整理される。また、決定していく設計行為は、設計で何を重視するかによってアクティ

他の生産関与者がその時点で何をしているのか、今まで見えにビティの優位性が大きく変わり、IDEF0 形式の記述が困難であった。

くかった点が見えてくる。

今回は、建築設計者が必要な意思決定を行い、サッシメーカーに必(3)必要不可欠なアクティビティを把握できるため、業務形態を変

要な情報を全て提供するという理想的な状況で、かつ設計内容も一更する場合の検討資料として、活用することが出来ると思われ般的な引き違い形式を想定してモデルの記述を行っているが、このる。

点で様々な状況が起こり得る実際の業務との不整合が指摘される(4)異なる主体間でやりとりする情報は、これまで明確化されていかもしれない。今後は、実際の業務で起こり得る様々な設計条件やなかった部分があった。IDEF0 で表現する事で、アウトプット

設計対象に対応したモデルの記述も必要と思われる。但し、設計プとして、「どこまで細かい情報を入れればよいか」、「だれが意志ロセスを一般化して表記するという点では今回の手法は有効であ決定するのか」等が明らかになる。そのため、作業の手戻りや、ったといえる。

責任範囲を超えて、相手の作業を肩代わりするような問題がよ

また、今回はサッシ設計の業務モデルの記述にあたって、アクテ

り明確になるため、それらの解決に役立つ可能性がある（今回ィビティやデータの抽出を経験豊富なサッシ設計者からのヒアリ

は主要な情報のみについて記したが、更に細かく検討すること

ング調査によって実施したが、アクティビティが暗黙知化していても必要であろう）。また、今回は理想的な作業の流れを想定した

今回の業務モデルの記述から洩れてしまったアクティビティがあが、実際の作業順序を IDEF0 で詳細に表現し、上記の点を検討ることも予想される。より精度の高いモデルを作成するにあたってすることで、より効率的なワークフローを作ることも可能とな

は、経験値の異なるサッシ設計者や営業・見積担当といった機能のると思われる。

異なる関与者への調査も必要と思われる。

(5)インプット情報、変換プロセス、アウトプットが機械的に決ま

さらに、特殊な条件や、通常とは異なる仕事の進め方でやる場合っているアクティビティを、コンピュータのプログラム等によは、このモデルから外れてしまう。あくまで標準的なプロセスしかって自動化することが可能である。

表現できないという問題がある。ある程度汎用性のあるワークフロ(6)IDEF0 では、アクティビティを実行する条件（実行するタイミ

ーの表現方法についても検討する必要があろう。

ング）や、所要時間等が表現されないが、実際の業務に要した時間を調査し、各ボックスにアクティビティの所要時間、矢印に伝達の所要時間を記入することで、どの部分で作業が滞っているか、どのアクティビティが必要以上に時間が掛かっているかが分かり、業務効率の改善等に応用する事が可能である。
(7)トラブル、クレームの発生原因が、業務モデルのどこで発生しているかを分析することによって、責任所在が明らかになる。

Ⅶ おわりに
ワークフロー分析・計画技術を適用することによる効用として、大きく以下のような項目をあげることができる。
1. 業務内容を明確に表現できる
2. ネットワークシステム化による自動化・視覚化の向上
3. コントロールと基準類等の協調

また、原因となるアクティビティで注意すべき事項が分かるた
め、設計者への注意を促すことが可能となる。

1．に示すように業務内容をモデル化し、明示化することにより、(8)今回は比較的重要度の高いコントロールを取り扱ったが、サッOJT（技術の継承）に活用できるほか、これまで実施してきた業務

シ設計では色見本等の見本類や、過去の建築作品のディテールの目的や根拠が明らかになること、ならびに役割分担（担当と責任）−13−

が明確化されるというメリットがある。また、業務の中に重複して

デモ６）トラブル事例を IDEF0 モデル上のマップする（OJT 用

いるものなどを発見することが易しくなるため、現状業務の改善にツールの例）

役立つことが挙げられる。さらに、一貫性のあるモデル表現がなされるため、によるスタッフ間の意識統一もはかれるという効果が期待される。

本研究課題は間もなく終了する。先に紹介したデモシステムとして提示したものが、将来、実際のシステムとして開発され、建築プ

2. としては、リファレンスモデルからの各業務の定義、業務の運用、監視、記録を自動化するためのシステム検討が可能になる。

ロジェクトの各段階での検討に有効活用されるよう、いろいろな観点から建築生産に関する検討を進めて行きたいと考えている。

このほかにも、業務の進捗・履歴情報の視覚化が図れ、トレースも可能となることが挙げられる。

参考文献

3.のコントロールと基準類等の協調については、業務をモデル化

１ Workflow Handbook “The WfMC Glossary – Feb 99”

し、併せて各種文書の構造化を行い、相互参照可能なシステムを活２ ｢建築生産におけるワークフロー分析・計画技術の研究開発｣

用することによって、アクティビティと基準類間の参照関係の双方
向的な確認（正引き・逆引きともに可能）ができるようになる。さらにこのシステムにより、基準類等の個々の記述に絡むワークフロ

平成 15 年度報告書 独立行政法人建築研究所
３ ｢建築生産におけるワークフロー分析・計画技術の研究開発｣
平成 14 年度報告書 独立行政法人建築研究所

ー（アクティビティ）の確認なども出来るようになる。また、基準

４ 平沢岳人、｢設計図書管理システムのためのキーワード抽出の類等の影響範囲を把握した上での円滑で、間違いのない改訂作業の自動化に関するノート｣、日本建築学会技術報告集第 17 号

支援も容易にできるようになるため、多くの人が活用する技術書の489-492、2003 年 6 月
５ アンテナハウス（株）公開資料より抜粋

改訂などには有効である。
このほか、多様な発注・調達形態に応じたリファレンスを準備し、

６ ｢サッシ設計の業務モデルの作成及び関連基準類文書等の構造

それを下敷きとしたマネジメントの企画立案や、モデルに属人的な化に関する業務 成果報告書｣ 平成 16 年 社）建築研究振興

ノウハウを持たせる仕組みを考えることで、これまでなかなか伝達協会が困難であった慣習的管理手法、属人的ノウハウの明示化も出来るようになると考えられる。
ワークフロー分析・計画技術による効用はこのようにいろいろなことが列挙されるが、それらを実効のあるものとするためには、電子化、ネットワークの利用というのがその前提条件としてある。本
研究課題においては、ワークフロー（アクティビティ）とそれらが参照する基準と書類との相互参照システムを実際に開発したが、活用方法としてあげたもの全てが開発された訳ではなく、それらについては、デモとして示すにとどまっている。
現在、成果の活用イメージを効果的に表現できるように、報告書等と併せてデモシステムの作成を進めている。その一例を、以下に示す。
デモ１）IDEF0 により表現された業務モデルを参照する
デモ２）業務モデルに関連づけられた基準類図書を参照する
デモ３）基準類図書の履歴管理
デモ４）基準類図書の特定箇所を参照するワークフロー（アクティビティ）一覧の取得
デモ５）ワークフロー全アクティビティが参照する基準類図書類
一覧（書名・章・節）の取得−14−