CADのための設計知識管理の研究 - Design Engineering Laboratory

平成十三年度博士論文
CAD のための設計知識管理の研究
指導教官冨山哲男教授
東京大学工学系研究科
精密機械工学専攻
工 97098
野間口大
概要
家電リサイクル法の施行に代表される環境問題に対する消費者の関心の高まりや PL 法な
ど，近年の製造業をとりまく環境はますます複雑化している。設計者に必要な知識の量は増
大する一方であり、その知識の管理は効率的な設計活動のための重要な課題の一つとなって
いる。知識を共有、再利用する試みは企業においては一般に設計の最終結果としての図面の
設計文書と共に設計者の持っているノウハウや設計事例を記録・管理することによって行わ
れ、その支援を行う研究が行われている。
本研究における著者らの目的は，特に設計活動を支援する立場で知識管理を実現する方法
を明らかにし、計算機システムへの実装および例題の実行を通してその検証を試みることで
ある。そこでまず設計知識および知識管理に関するこれまでの研究について概観し、設計知
識管理を実現する際の問題点について述べる。
次に、本研究で提案する設計文書を中心とする知識管理の枠組みについて述べる。具体的
には設計過程の情報および情報間の関係を表現するために本研究で提案するメタプロセスモ
デルについて述べ、メタプロセスモデルを利用した設計知識管理について述べる。
次にメタプロセスモデルを用いて設計知識の獲得を実現する手法について述べる。ま
ずハイパーテキスト文書による設計情報の記述を行い、さらに統合設計支援環境である
KIEF(Knowledge Intensive Engineering Framework) と文書作成ツールを統合することに
より、KIEF で設計作業を行いながら設計過程における情報を文書上に記述することを可能
とする。KIEF における設計作業のログを元に自動的に設計過程を獲得し、メタプロセスモ
デルを作成することが可能である。
次に設計の文脈を考慮した検索手法を提案する。この手法ではまず、検索対象となる文書
を、設計の部分的なサブ問題の解決に必要な知識を記述した小部分に構造化することを考え
る。これを文書知識と呼ぶ。設計作業中に知識を検索する際には、KIEF における設計作業
で作成されるメタモデルと文書上における設計対象の記述から現在進行中の設計作業に関す
る文脈情報モデルを自動生成する。検索の対象となる文書知識にもインデックスとして文脈
情報モデルを付与しておき、両者のマッチングにより検索を行う。この手法により、知識と
しての文書を共有・再利用することが可能となる。
次に、本研究で提案する方法論に基づいて DDMS(Design Documentation Management
System) と呼ぶシステムの作成を行い、例題を実行してその結果を検討することにより方法
論の妥当性の検証を行う。さらに本研究で提案する方法論と関連研究との比較を通じて、本
i
研究で提案する方法論の利点について考察を加える。
最後に本研究の結論および展望を述べる。
ii
目次
第 1 章序論
1
1.1
本研究の背景 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.2
設計知識管理の現状
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.2.1
知識を共有・再利用する試み . . . . . . . . . . . . . . . . . . . . . .
3
1.2.2
知識管理と文書 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.2.3
設計支援における知識管理 . . . . . . . . . . . . . . . . . . . . . . . .
5
1.3
本研究の目的 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
1.4
本論文の構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
第 2 章設計知識の管理に関する関連研究
2.1
2.2
9
知識管理一般に関する研究 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.1
DARPA における知識共有の枠組み . . . . . . . . . . . . . . . . . . . 11
2.1.2
協調作業支援における情報の共有・再利用 . . . . . . . . . . . . . . . 15
2.1.3
計算機ネットワークの利用 . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.4
文書管理に関する研究 . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.1.5
現状の知識管理の問題点 . . . . . . . . . . . . . . . . . . . . . . . . . 21
設計知識に関する研究 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2.1
幾何情報を中心とする製品情報管理 . . . . . . . . . . . . . . . . . . . 22
2.2.2
設計の背景情報 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2.3
設計根拠に関する研究 . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.4
設計知識研究における課題 . . . . . . . . . . . . . . . . . . . . . . . . 26
iii
2.3
2.4
2.5
KIEF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.3.1
知識集約型工学の基本概念 . . . . . . . . . . . . . . . . . . . . . . . . 28
2.3.2
計算機システムとしての実装 . . . . . . . . . . . . . . . . . . . . . . 29
2.3.3
KIEF における設計過程 . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.3.4
知識集約型工学環境における課題 . . . . . . . . . . . . . . . . . . . . 33
シンセシスのモデルと推論フレームワーク . . . . . . . . . . . . . . . . . . . 34
2.4.1
知識操作と設計の基本語彙 . . . . . . . . . . . . . . . . . . . . . . . . 34
2.4.2
設計過程の知識 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.4.3
システムの実装 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.4.4
課題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
本研究における設計知識管理 . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.5.1
設計知識管理における課題 . . . . . . . . . . . . . . . . . . . . . . . . 40
2.5.2
本研究におけるアプローチ . . . . . . . . . . . . . . . . . . . . . . . . 41
第 3 章知識管理のための設計文書に関する理論
3.1
3.2
3.3
3.4
43
設計文書のモデリング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.1.1
設計過程 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.1.2
知識操作による設計文書記述 . . . . . . . . . . . . . . . . . . . . . . 46
設計文書の生成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.2.1
メタプロセスモデルの導入 . . . . . . . . . . . . . . . . . . . . . . . . 51
3.2.2
記述のパターンと文書モデル . . . . . . . . . . . . . . . . . . . . . . 51
3.2.3
設計文書生成のプロセス . . . . . . . . . . . . . . . . . . . . . . . . . 53
設計文書における思考過程の分析 . . . . . . . . . . . . . . . . . . . . . . . . 55
3.3.1
分析対象とその収集 . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.3.2
分析方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.3.3
文書生成実験 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
iv
第 4 章設計過程における知識の獲得
4.1
設計過程獲得の課題
61
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.1.1
設計作業による設計過程獲得 . . . . . . . . . . . . . . . . . . . . . . 63
4.1.2
統合的設計支援環境の必要性 . . . . . . . . . . . . . . . . . . . . . . 63
4.1.3
まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.2
統合設計支援環境との統合 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.3
知識操作に基づく文書の自動生成 . . . . . . . . . . . . . . . . . . . . . . . . 68
4.4
4.3.1
メタプロセスモデルにおける設計情報と KIEF の概念との対応付け . 68
4.3.2
KIEF のログから情報の導出関係の生成
4.3.3
自然言語への変換 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
. . . . . . . . . . . . . . . . 68
ハイパーテキストによる設計文書の記述 . . . . . . . . . . . . . . . . . . . . 71
4.4.1
設計過程の記述 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.4.2
セクションの導入 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.4.3
設計過程管理グラフ . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.4.4
多様な情報の記述 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.5
設計情報の管理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.6
本章のまとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
第 5 章設計の文脈情報を利用した知識検索
5.1
5.2
5.3
知識検索と設計文書
81
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.1.1
課題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.1.2
文書知識の導入 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
文書知識の検索 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.2.1
検索要求の記述 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.2.2
設計の文脈 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.2.3
設計文脈情報のモデリング . . . . . . . . . . . . . . . . . . . . . . . . 87
設計行為を考慮した文脈情報モデル . . . . . . . . . . . . . . . . . . . . . . . 90
v
5.4
5.5
5.3.1
文脈情報モデルの課題 . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.3.2
設計行為を考慮した設計文脈情報のモデル化 . . . . . . . . . . . . . . 90
設計文脈情報を利用した検索結果のランキング . . . . . . . . . . . . . . . . . 92
5.4.1
グラフマッチングによる文脈情報モデルの類似度の定量化 . . . . . . 92
5.4.2
ランキング手法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
本手法の利点と限界
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
第 6 章設計知識管理のための CAD システムの実装
6.1
6.2
6.3
システム構成・実装
97
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
6.1.1
設計文書作成管理システムの実装 . . . . . . . . . . . . . . . . . . . . 99
6.1.2
システムの機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6.1.3
KIEF の外部モデラ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
実行例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
6.2.1
レーザーリソグラフィーの設計例 . . . . . . . . . . . . . . . . . . . . 106
6.2.2
加工機の設計例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
6.2.3
建築基礎構造物の設計例 . . . . . . . . . . . . . . . . . . . . . . . . . 118
システムの検証 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
6.3.1
DDMS における知識獲得
6.3.2
従来研究との比較 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
第 7 章考察
137
. . . . . . . . . . . . . . . . . . . . . . . . 130
7.1
設計作業と同時に行う知識獲得について . . . . . . . . . . . . . . . . . . . . 138
7.2
メタプロセスモデルのコーディングの自動化について . . . . . . . . . . . . . 139
7.3
7.2.1
手法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
7.2.2
実験と結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
設計知識管理と設計のモデル化について . . . . . . . . . . . . . . . . . . . . 142
vi
第 8 章結論
143
8.1
本研究の結論 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
8.2
展望 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
謝辞
146
参考文献
149
発表論文
158
付録
164
A. 情報導出生成ルール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
B. 情報導出から自然言語への変換ルール . . . . . . . . . . . . . . . . . . . . . . . 171
C. DDMS により生成された文書 . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
D. シンセシス推論フレームワークのログ . . . . . . . . . . . . . . . . . . . . . . . 178
vii
第 1 章序論
1.1
本研究の背景
一般に工業活動は、ある要求を実現する製品やサービスを創り出す行為と考えることがで
きる。設計作業はこの工業活動全体を企画・立案する重要な作業であり、設計者が持ってい
る知識を駆使して、製品やサービスを実現するために必要な情報を創る知的作業である。
産業革命以前の手工業時代では、設計から生産まで工業活動における全ての工程が職人一
人一人によって行われていた。製品に関する情報および知識は全て職人の頭の中にあったと
言って良い。こうした状況では設計情報や設計知識を共有する必要性は深刻な問題とはなら
なかった。
ところが、産業革命以後の近代的な製造業においては状況が一変する。まず、工業活動の
分業化が始まり、設計と生産に携わる技術者の分化が進んだ。次に製造業が発展し、製品が大
型化、複雑化するにつれて、一人で製品全体を把握することは不可能になり、設計作業の分業
化も進んだ。さらに、吉川が「現代の邪悪」と呼ぶ地球環境問題が深刻化し [Yoshikawa93]、
また PL 法の制定、知的所有権保護の強化など政治的、社会的な要因も加わり、製品設計時
に単に製品が仕様を満たすかどうかだけではなく、その製品が外部に与える影響や政治的、
社会的な制約条件も考慮する必要が出て来ると、様々な分野の技術者が設計に参加し、多様
な観点からの評価を行わなければならなくなった。
このように近年の工業活動においては、職人的な一人の技術者によって全ての作業を行う
ことは難しく、多数の技術者が協調することによって作業を行う必要がある。一般にある作
業を複数の人間で行う場合、作業に参加する者全員がお互いに意思の疎通をし、作業に関す
る知識、情報を共有することが、全体の作業の効率化につながるだけでなく、新規なアイデ
アの発想を促すことにもなる。このために、作業に携わる全ての設計者の間で共有・再利用
するために知識や情報を管理しておく必要が生じるのである。
2
設計知識管理の現状
1.2
1.2.1
知識を共有・再利用する試み
複数の人間の間で知識や情報を共有する一般的な手段はコミュニケーションを密に取るこ
とである。特に日本においては、業務上のミーティングなどよりも仕事帰りの居酒屋で酒を
酌み交わしながらお互いの持つ情報や知識を交換し合う傾向が強く「ノミニケーション」な
どという言葉が生まれる所以でもある。
一方で、企業の規模が大きくなり、企業の国際化も進むと、一つの製品を作る際に様々な
国の様々な企業が関わるようになってきている。このため、設計作業も全世界的に行われる
ようになってきており、技術者同士が実際に会合してコミニュケーションを行うことが難し
くなっている。こうした状況の中で、80 年代後半に始まった CSCW(Compurter Supported
Cooperative Work)(例えば [Matsushita93]) に代表されるように、設計情報を共有するため
の研究が盛んに行われるようになった。また、近年爆発的に普及したインターネットに代表
される計算機ネットワークを使って遠隔地の設計者間での情報のやり取りを行う試みも多数
行われている。例えばボーイング社の開発した 777 型旅客航空機は、アメリカや日本、ヨー
ロッパに散らばる設計者、技術者が協力して、全ての設計情報が最初からコンピュータ上で
定義、記述されながら作業が進められていった (例えば [Okada99])。電子メールや Web を
用いて、必要な情報の収集や，クライアントとの交渉に役立てることも可能であるし，マル
チメディア・ベースの電子会議システム (例えば，[PM96]) やインターネットを利用した知
識ベース共有システム (例えば，[Bok99]) は，地理的，時間的に分散した設計者間での協調
作業やネット上に散在する知識源へのアクセスを実現する。知識管理を実現する上で計算機
ネットワーク技術を利用した環境構築は欠かせない要件の一つと言ってよいだろう。
企業活動が地球規模で拡大するにつれ、知識を共有・再利用する試みが工学的に重要な課
題として認識されるようになってきている。こうした流れを受けてここ数年、知識管理ある
いはナレッジマネジメントと呼ばれる研究課題が注目され始めている。この分野における研
究は多岐にわたり、以下に示すように多種多様な研究が見受けられる。
• 知的所有権や知的資本の管理強化など、企業経営および政策の面から知識管理につ
いて論じたもの (例えば [Fruin97])。
• 知識を複数の人間で共有するために人間がコミュニケーションを取りやすくなるよ
うな環境を提供すべきであるとの考えから、組織論を論じたもの (例えば [Nonaka95])。
3
• 計算機による代行・支援を行うことにより、知識管理を実現しようと試みるもの
[Dieng00]。具体的には計算機ネットワークを利用した知識ベース統合システム、XML(eXtensible Markup Language) 等を用いたデータ記述形式の統一、蓄積された文書をオ
ントロジーを利用して整理する手法などが挙げられる。
知識管理に関する研究はいまだ揺籃期にあり、試行錯誤が続いていると言える。
1.2.2
知識管理と文書
日本の企業が実際にどのような知識管理をしているか、インターネット、ニュースメール、
新聞、雑誌等を調査して得られた 86 事例を分析した報告がある [Ishida00]。この 86 件には、
営業部門やコールセンターにおけるカスタマーマネジメント、設計・開発部門におけるプロ
ダクトマネジメント、部品調達や製造部門におけるプロセスマネジメントなど多種多様な事
例を含んでいる。これらの事例において知識管理実施に適用されたツールは 126 件であり、
その分類は以下の通りである。
1. インターネット／イントラネット (35%)
計算機ネットワーク技術を利用した電子メールシステムやファイル共有システムなどを
利用したものである。
2. グループウエア (31%)
Lotus Notes1 などの統合環境を利用して様々な情報を管理したものである。
3. 文書管理／検索エンジン (17%)
2.1.4 節で述べるシステムなどを利用したものである。
4. Business Intelligence(11%)
一般にデータマイニングと呼ばれる統計処理に基づいたデータ処理技術 (例えば [Fukuda01]）
を利用したものである。
5. その他 (6%)
この調査結果によると文書管理／検索エンジンが 3 位にランクされている。1 位にランク
されたインターネット／イントラネット上でやりとりされる情報が主に HTML 文書である
ことを考えると、一般に管理の対象となっている知識は文書の形態で記録、管理されると考
1
Lotus Notes は Lotus Development 社の登録商標である。
4
えられる。
また設計業務において文書作成作業に費やされる所要時間について分析した研究もある。
Crabtree は設計事例の分析に基づいて設計作業を「問題解決」や「文書作成」など 6 つの
カテゴリーに分類した上で、各作業に費やされている平均時間が全作業時間に占める割合を
表 1.1 に示すようにまとめている [Crabtree97]。表 1.1 が示すように設計者は文書作成作業
に比較的長い時間を費やしているが、これは設計知識や設計情報を文書化することにより、
その共有・再利用を促進するためと思われる。
つまり知識管理を実現する上で、文書作成の支援および文書管理の実現は欠かせない技術
であることが分かる。
表 1.1: 設計活動の分類と平均所要時間の割合 [Crabtree97]
設計活動
情報収集
問題解決
文書作成
計画
交渉
支援
その他
1.2.3
平均所要時間 (%)
13.7
28.0
23.5
7.8
7.7
17.1
2.2
設計支援における知識管理
設計研究の分野においては主に製品の寸法や形状などといった幾何情報を中心として様々
な製品情報や知識を管理し、設計作業を支援しようとする試みが行われている。
幾何情報を中心とする CAD と設計知識ベースを統合することにより知識管理を実現する
システムの例として CATIA2 を挙げることができる。CATIA にはフィーチャーモデリング
や公差情報の取り扱いなど一般的な CAD の機能に加えて、部品の機能および属性情報を扱
う枠組みや例題を蓄積した知識ベースが用意されており、例えば「何らかのパラメータを減
らす」といったカテゴリで検索すると「ノイズを減らす方法」などの例題を参照できる仕掛
けになっている [Kizaki01]。しかしこのシステムで扱うことのできるのは幾何情報を中心と
した知識に留まる．
一般に、設計に関する情報は 2 種類の情報を含むと考えられている [Suzuki96]。一つは設
2
CATIA は Dassault Systemes 社の登録商標である．
5
計作業の明確な結果である図面や CAD データおよび製品仕様といった情報である。もう一
つは要求仕様や、設計結果としての情報を生成するために使われた知識あるいは参照された
情報などの情報である。前者は明示的に記録、管理され、設計者間で共有・再利用されてい
ることが多いが、後者の情報に関しては、個々の設計者が個人的・非明示的に処理している
事が多く、通常は設計終了後に設計者が記憶していることもないので明示的な記録、管理の
対象となるのが難しい。たとえメモなどの形で残されることはあっても、あくまでも私的な
ものであり、共有・再利用の対象であるという意識が薄いのが現状である。しかし設計者の
知識やノウハウを含んでいるのは後者であり、本来は文書化して管理の対象とすべきもので
ある。
設計者が持っている知識やノウハウの文書化を支援する枠組みとして、前述した Lotus
Notes などのグループウエアを用いてワードプロセッサと CAD との統合環境を構築するこ
とが考えられる。これにより CAD 上で設計作業を行いながら設計者のコメントなどを文書
に記述していくのは可能となるが、文書作成作業自体は人間が手作業で行う他なく、計算機
による十分な支援が行われているとは言い難い。このため、設計者にとっては大変負担の大
きい作業となっている。
このように現実問題として管理の対象となる文書の獲得が困難であることが、設計知識に
おける大きな課題である。
6
1.3
本研究の目的
本研究の目的は特に設計活動を支援する立場で知識管理を実現する方法を明らかにし、計
算機システムへの実装および例題の実行を通してその検証を試みることである。このため、
• 管理の対象として、設計結果の情報だけでなく設計意図や設計中に参照した情報を考
える。このため設計過程中の多様な形態の設計情報およびそれらの間の関連を表現す
るための枠組みを提案する
• 設計後では収集が困難な設計過程の情報を容易に獲得し、管理する手法を提案する
• 設計知識を効果的に検索し、その共有・再利用を行うための手法を提案する
ことを試みる。さらに本研究で提案する手法に基づいてシステムを実装し、手法の妥当性
について検討を加える。
7
1.4
本論文の構成
本論文は 8 つの章から構成される。
まず 2 章では設計知識および知識管理に関するこれまでの研究について概観し、設計知識
管理を実現する際の問題点について述べる。
3 章では、本研究で提案する設計文書を中心とする知識管理の枠組みについて述べる。具
体的には設計過程の情報および情報間の関係を表現するために本研究で提案するメタプロセ
スモデルについて述べ、メタプロセスモデルを利用した設計知識管理について述べる。
4 章では、3 章で述べたメタプロセスモデルを用いて設計知識の獲得を実現する手法につ
いて述べる。まずハイパーテキスト文書による設計情報の記述を行い、さらに統合設計支援
環境である KIEF(Knowledge Intensive Engineering Framework)[Sekiya99] と文書作成ツー
ルを統合することにより、KIEF で設計作業を行いながら設計過程における情報を文書上に
記述することを可能とする。KIEF における設計作業のログを元に自動的に設計過程を獲得
し、メタプロセスモデルを作成することが可能である。
5 章では、設計の文脈を考慮した検索手法を提案する。この手法ではまず、検索対象とな
る文書を、設計の部分的なサブ問題の解決に必要な知識を記述した小部分に構造化すること
を考える。これを文書知識と呼ぶ。設計作業中に知識を検索する際には、KIEF における設
計作業で作成されるメタモデルと文書上における設計対象の記述から現在進行中の設計作業
に関する文脈情報モデルを自動生成する。検索の対象となる文書知識にもインデックスとし
て文脈情報モデルを付与しておき、両者のマッチングにより検索を行う。この手法により、
知識としての文書を共有・再利用することが可能となる。
6 章では、本研究で提案する方法論に基づいて DDMS(Design Documentation Management System) と呼ぶシステムの作成を行い、例題を実行してその結果を検討することによ
り方法論の妥当性の検証を行う。
7 章では、本研究の考察を行う。
最後に 8 章で、本研究の結果ならびに展望について述べる。
8
第 2 章設計知識の管理に関する関連研究
本章では、設計知識管理に関してこれまでに行われてきた研究について概観する。
まず知識工学や人工知能、計算機科学などの各分野で行われている知識管理に関する研究
一般について概略を述べる。次に設計研究の分野で行われている CAD を中心とする製品情
報や設計知識管理研究の現状、および設計作業における意思決定の理論的根拠である設計根
拠を取り扱う研究について述べる。次に冨山らによって研究されている統合設計支援環境で
ある KIEF および設計者の思考過程モデル基づく設計知識の共有の試みについて述べる。最
後に、本研究の位置付けを行う。
10
2.1
知識管理一般に関する研究
本章では設計に限らず知識の共有に関する研究について概観する。まず、知識共有を目的と
した代表的な研究である米国防総省高等研究プロジェクト機関 (DARPA; Defence Advanced
Research Project Agency) における知識共有活動 (Knowledge Sharing Effort) について述
べる。
2.1.1
DARPA における知識共有の枠組み
DARPA の知識共有活動ワーキンググループでは、ソフトウェアモジュールの入出力を共
通言語を用いて統一する枠組みを作り、相互の運用性を高める試みをしてきた [Neches91]。
共通のプロトコルと情報表現言語を用いたメッセージ交換によって相互作用するソフトウェ
アモジュールは、仮想知識ベースまたはエージェントと呼ばれる。ここでは、各エージェン
ト間で用いられる言語や通信プロトコルの共通を図ることでエージェント間での知識の共有
を目指す。
この実現のため、エージェント通信言語として KQML(Knowledge Query and Manupi-
lation Language)[T. Finin et al.92] が、知識交換用言語として KIF(Knowlege Interchange
Format)[Genesereth92] が、共通オントロジー記述用言語として Ontolingua[Gruber92] が、
それぞれ提案されている。
KQML
KQML は人間同士の対話を分析した発話行為理論に基づいた通信言語である。KQML に
よるメッセージを理解し、然るべき応答を返すエージェントは KQML エージェントと呼ば
れる。
KQML のメッセージは、
( <メッセージ行為タイプ> { :<キーワード> <LISP の S 式>} )
という形式を持っている。例えば図 2.1 の KQML 式では、メッセージ行為は tell、内容記述
言語は 2.1.1 節で述べる KIF で、motors と名付けられたモータに関するオントロジーを参
照し、内容は (fastens frame3 motor5) つまり「台 frame3 にモータ motor5 が取りつけられ
11
ている」を意味する記述である。また、in-reply-to というキーワードによってこのメッセー
ジが q1 というタグの付けられた質問への回答であることが示されている。
(tell
:language KIF
:ontology motors
:in-reply-to q1
:content(fastens frame3 motor5))
図 2.1: KQML 式の例
KQML には 30 種類余りのタイプのメッセージ行為が定義されている。それらは、情報
伝達 (tell, deny, untell)、質問 (ask-if, ask-all, stream-all, reply, sorry など)、依頼 (achieve,
unachieve など)、生成器関係 (standby, ready, next, discard など)、通知 (subscribe, monitor)、ネットワーク処理 (register, unregister など)、仲介処理 (broker-one, recommend-one,
recruit-one など) などに分類できる。ユーザは新しいメッセージ行為を所定の形式で定義す
ることによって拡張することもできる。
また、キーワードには content, in-reply-to など電子メールと同様のキーワードを与える
ことができる。
KIF
KIF は、一階述語論理を拡張して、項の定義、メタ知識 (知識に関する知識)、集合、非単
調論理などを記述可能にした知識交換フォーマットである。表 2.1 のように、KIF の表現は
一階述語論理の表現を Lisp 風に表したものである。
一階述語論理の最小限の表現に加えて、setof や listof のように集合、リストを外延的に表
現する記述子や、the や setofall のように内包的な表現を作り出す記述子、lambda や kappa
のように関数や関係を作り出すための記述子、if や cond による条件記述子などが用意され
ている。また、後述する Ontolingua でオブジェクトや関数、関係を KIF 表現の式を用いて
定義するための形式も用意されている。
Ontolingua
知識工学においては、対象領域の概念のモデル化とその表現の仕方を明示的に記述するた
めの枠組みをオントロジーと呼んでいる。Ontolingua は、DARPA の知識共有ワーキング
12
表 2.1: KIF の表現の例
述語論理および数式の表記
(1) 項
(2) 命題
x+y
(a, b, c, d)
{ x | wheel(x) ∧ made-in-japan(x)}
;「日本製の車輪の集まり」
ι x [ wheel(x) ∧ made-in-japan(x) ]
;「その日本製の車輪」
λ x [ founded-year(vender(x)) ]
;「x の製造者の設立年」
p(a,b)
KIF の表記
(+ ?x ?y)
(setof a b c d)
(setofall ?x(and (wheel ?x)
(made-in-japan ?x)))
(the ?x (and (wheel ?x)
(made-in-japan ?x)))
(lambda ?x
(founded-year (maker ?x))
(p a b)
グループにおけるオントロジーの記述言語である。先ほど述べた KIF を用いて、対象領域
をオブジェクト、関数、関係の集まりとして形式化して定義することによって対象領域のオ
ントロジーを記述する。
Ontolingua によるオントロジー記述の基本となっているのは、フレーム形式の表現である。
「?author
図 2.2 に、AUTHOR オブジェクトの定義を示す。ここでは、KIF の表現式を用いて、
が AUTHOR であるとは、author は person つまり人間であり、値のタイプが biblio-name
である AUTHOR.NAME 属性を 1 つ持ち、1 個以上の値を取る AUTHOR .DOCUMENT
属性を持ち、?author の author.name と person.name が同一値となることを意味する。」と
いう定義を行っている。
(define-class AUTHOR(?author)
:def(and (person ?author)
(= (value-cardinality ?author AUTHOR.NAME) 1)
(value-type ?author AUTHOR.NAME biblio-name)
(>= (value-cardinality ?author AUTHOR.DOCUMENTS) 1)
(<=> (author.name ?author ?name)
(person.name ?author ?name))))
図 2.2: Ontolingua におけるオブジェクトの定義
オントロジー O に定義された語彙の集合を用いた記述を認識し、操作するプログラムは、
O にコミットしたプログラムと呼ばれる。与えられたプログラムがコミットしているオン
13
トロジーには、そのプログラムが操作するオブジェクトや関係の定義が与えられているの
で、このオントロジーを理解することによってプログラムの共有・再利用が可能になる。ま
た、Ontolingua にはオントロジー定義をいくつかの知識表現言語の定義に変換するトラン
スレータが用意されているので、共通オントロジーを実際に自分の知識ベースシステムの定
義の中に組み込んで使用することができる。共通するオントロジーにコミットしたプログラ
ムの間では、内容レベルで整合性が保証されたメッセージ交換を行うことができる。
PACT
この DARPA における知識共有のアプローチの適用例として PACT(Palo Alto Collabora-
tive Testbed) プロジェクト [Cutkosky93] が良く知られている。これは、スタンフォード大
学、ロッキード人工知能研究センターなど複数の研究機関による分散協調設計を行う実験的
プロジェクトである。具体的には NEXT-Cut(機械設計)、Designworld(デジタル回路設計)、
DME(モデル生成とモデルベース推論)、Nvisage(設計用ツールの統合環境) の 4 つの異なる
システムを用いて行われている。このプロジェクトでは、例題としてロボットマニピュレー
タの設計を用いており、実際に Ontolingua で定義されたオントロジーを用いて分散協調設
計するためのテストケースとして行われている。
まとめ
本節で概観した DARPA の知識共有作業ワーキンググループはエージェント間で知識の
共有を行うために、通信プロトコルや知識の表現形式、交換形式などを定めている。また、
エージェントで用いる対象領域の概念をオントロジーとして体系化している。これらはエー
ジェントで利用される知識を管理するための枠組みを提供している。
しかしこのアプローチには知識の獲得や保守に問題がある。つまり、DARPA のワーキン
ググループでは、オントロジー収集にあたって、その記述の正確性についての明確な指針を
打ち出してはいない。一般に、我々人間の持っている知識を定形的な式として正確に記述す
るのは困難であるという問題がある。またたとえ人間の持つ知識を定形的な式として獲得
できたとしても、知識の数が増大するに従ってそれらの知識を矛盾無く保守するのは困難に
なる。
こうした問題を解決するためには知識を闇雲に集めるのではなく、知識の背景理論に基づ
14
いて体系的に集める必要があることが指摘されている [Tomiyama94]。
2.1.2
協調作業支援における情報の共有・再利用
前節で述べた研究は主に計算機が処理するための知識を管理する枠組みであり、計算機
ツール間での協調作業に主眼が置かれたものであった。一方、人間の協調的な活動を計算機
で支援することを目的とした CSCW と呼ばれる研究分野が 80 年代後半から 90 年代初頭に
かけて脚光を浴びてきた (例えば [Matsushita93])。
CSCW とは、その言葉が表す通り Computer Support(計算機支援) と Cooperative Work(共
同作業) の両方の立場から研究を進めようとする試みである。両者の研究対象は次のように
分類することができる。
• 共同作業に関する研究
人間の協調活動のモデル化、グループウェアの設計概念・理論の構築
• 計算機支援に関する研究
共同作業を支援する基盤環境、システムの構築
このように CSCW においては単に計算機科学や情報処理の分野からのアプローチに留ま
らず協調活動のモデル化や協調作業における組織形態、社会慣行など認知科学的なアプロー
チも積極的に取り入れている。
CSCW における前者のアプローチはマルチメディア技術を利用して多種多様な知識・情報を
扱うグループウェアの開発である。例えば、Intermedia[Meyrowitz86]、Hoopertext[Berlin90]、
SEPIA[Haake92] は計算機ネットワーク上に構築された電子会議システムであり、会議の出
席者達は発言者のログや会議に必用な資料などの情報を共有することにより、会議の進行を
促進させることができる。これらのシステムでは会議で利用されるの情報としてテキストや
画像、音声などを扱うことが可能であり、各情報がハイパーリンクされることにより議論の
進行を表現することができる。
CSCW におけるもう一つのアプローチは、計算機上で進められる議論を支援するために
議論の認知モデルを構築することである。例えば gIBIS[Conklin88] や rIBIS[Rein91] は伝統
的な議論モデルである IBIS(Issue Based Information Systems)[Kunz70] をベースとして開
発されたグループウェアである。これらのグループウェアはユーザに議論の進行状況を視覚
15
的に提示することができる。IBIS モデルは議論の進行を色付ノード (問題、問題に対する立
場、議論など) および色付アーク (賛成/反対、質問、一般化/個別化など) によるグラフとし
て表現する。議論の参加者はグラフを通じて、議論における対話の構造を理解することが可
能である。
一方で設計研究の分野においても、製品の設計、生産などの製品製造にかかわる一連の諸
過程の並列化によって各作業を協調的に行い、品質の向上、リードタイムの短縮などを系統
的に図るとともに、設計の初期の段階から製品を様々な観点から評価する環境を実現する試
みが行われている。これは一般にコンカレント・エンジニアリングと呼ばれている。
例えば岩田および薮崎らの研究 [Iwata95]、[Yabusaki95] では、設計者間の相互作用を会
話モデルとしてモデル化し、設計者同士のコミュニケーションを支援するシステムの開発を
試みている。このシステムでは、設計対象に関して決定すべき情報の項目からなる記述の枠
組みをあらかじめ用意しておき、枠組みの各項目の値を複数の技術者がコミュニケーション
を通じて決定していく。このために、形状データ、非形状データ、データの相互関係といっ
た設計対象の情報の表現に必要な計算機ツールがネットワークに接続され、利用できるよう
になっている。
2.1.3
計算機ネットワークの利用
近年の計算機ネットワーク技術の発達はめざましく、特に WWW(World Wide Web) の
爆発的な普及によってインターネット技術を手軽に扱うことが可能となった。このインター
ネット技術を利用して、知識管理システムを実現する研究も盛んである。例えば Bok は、分
散オブジェクト環境の標準仕様である CORBA[Siegel96] を利用した知識ベース共有システ
ムを開発している [Bok99]。図 2.3 に示すように、各クライアントはインターネット上に構
築された CORBA/HTTP 環境を通じてサーバに蓄積された CAD データを参照したり、エ
キスパートシステムを利用したパラメトリック設計により CAD データを修正したりするこ
とができる。こうしたシステムにより地理的、時間的に分散した設計者間での協調作業や
ネット上に散在する知識源へのアクセスが実現される。
実際の企業においても計算機ネットワークを利用した情報交換を行って業務を進めている
例が見られる。例えばボーイング社において 1986 年から始まった 777 型旅客機の開発では、
3 次元形状モデラを中心とした統合的設計支援環境である CATIA のデータをリアルタイム
で共有するために世界中にネットワークを構築し、アメリカや日本、ヨーロッパに分散する
16
CAD
Data
Expert
System
Knowledge
Base
Expert
System
Object Implementation
Knowledge
Base
CAD
Data
Object Implementation
Expert
System
Knowledge
Base
Object Implementation
CORBA/HTTP
CAD
System
Client
Expert Knowledge
System
Base
Client
CAD
System
CAD
System
Client
Knowledge
Base
図 2.3: 分散設計支援環境のアーキテクチャ[Bok99]
設計者、技術者が協力して、全ての設計情報を最初からコンピュータ上で定義、記述しなが
ら作業が進められた [Ueda96]。図 2.4 に日本とアメリカの間で構築されたデータ交換ネット
ワークの概略を示す。図 2.4 に示すように日本国内にセンターコンピュータを一台設置し、
これをハブとして国内の各機体メーカのホストコンピュータを接続することにより、各端末
で同じ CAD データを共有することが可能となった。
日本
シアトル
センターコンピュータ
センターコンピュータ
F社
ウィチタ
プロッタ
K社
フィラデルフィア
リソースデータ
CATIA
CATIA
リソースデータ
プロッタ
図 2.4: ボーイング 777・データ交換ネットワーク [Ueda96]
しかし計算機ネットワークはあくまでも知識管理システムのインフラストラクチャーなの
であって、それだけで知識管理が実現するわけではない。Dieng は計算機ネットワーク上で
実現される知識管理に関して解決すべき課題として、
17
1. 共有・再利用すべき知識を如何に作成し、また更新するか。(知識獲得)
2. インターネットやイントラネットに存在する情報を如何に探索するか。(知識検索)
3. 知識を組織内に如何に広めるか。(知識配布)
の 3 点を挙げている [Dieng00]。これらの課題のうち、知識配布の問題に関しては計算機ネッ
トワークの効果が強力に発揮されるだろう。これに加えて知識獲得や知識検索の課題を解決
することにより、初めて知識管理システムのソリューションとなるのである。
2.1.4
文書管理に関する研究
特に企業においては、設計者・技術者の知識やノウハウを文書として記録、その共有・再
利用を図るのが一般的である。このためそれらの文書をいかに管理し、また必要な時に有効
に検索するかが問題となる。
本節では文書管理に関する研究のうち代表的な 2 件を概観する。
KIDS
中山らは電子機器製造メーカーにおける事務手続きのやり方、書類の書き方、研究関連
のノウハウ、計算機や周辺機器の使い方、福利厚生や日常生活に関わるノウハウ、役に立つ
ページへのリンク、用語集など多種多様な知識を共有するシステムとして KIDS(Knowledge
and Information on Demand System) を開発している [Nakayama98, Nakayama01]。
KIDS では各ノウハウは自然言語で記述されたテキスト情報として獲得され、形態素解析
と簡単な構文ルールを用いることにより検索キーワードを抽出したり、知識の条件部にあた
る部分と知識本体を分割するなど、構造化された知識に変換される。ノウハウデータの構造
化処理の例を図 2.5 に示す。KIDS は、入力された単位文ごとに文脈推定知識を参照して文
脈を特定し、語彙知識を参照して主要キーワードを抽出する。文脈推定知識は図 2.5 に示す
ように、形態素パターンを重み付けで関係付けたものである。語彙知識は対象分野の語彙体
「発表する (動詞)」＋「場合」
系を記述したものである。図 2.5 の例では、前半の単位文は、
という表現を含むため、文脈を「状況」と推定し、キーワードとして「国際学会」、
「英語」、
「発表」を抽出する。後半の単位文については文脈を「コツ」と推定し、キーワードとして
「口頭発表原稿」、「ネイティブ」、「録音」を抽出し、これらを構造情報としてノウハウベー
スに蓄積する。こうして自然言語で記述されたノウハウを構造化された知識として管理する
18
ことが可能となる。
入力
国際学会などで英語で発表する場合、口頭発表原稿を準
備してネイティブに読んでもらって録音するとよい。
文脈推定知識
形態素パターン
形態素解析
（動詞）＋場合
（助詞）＋よい
文脈推定
＋
構造化
語彙知識
上位／下位語
同義語
重要語／不要語
意味要素
重み
状況
コツ
1
1
構造情報
文脈要素
状況
国際学会などで英語で発表する場合、
キーワード：国際学会、英語、発表
コツ
口頭発表原稿を準備してネイティブに読んでもらって録音するとよい。
キーワード：口頭発表原稿、ネイティブ、録音
図 2.5: ノウハウデータからの構造抽出 [Nakayama01]
ただし KIDS 自体は知識の基となるテキスト情報の獲得を支援するものではなく、ユーザ
各自が自分の知識を外在化する労力を払ってシステムに入力する必要がある。中山らの研究
ではユーザにアンケートに答えてもらう形でノウハウを収集し、利用された知識の提供者に
褒賞を与えることで知識提供のモチベーションを高めるなどの工夫が為されている。
19
ConceptBase
ConceptBase はジャストシステム社が開発する商用の文書管理・検索システムである
[Justsystem]。キーワードのブーリアン式を用いる従来の検索システムでは、ユーザが指
定したキーワードが文書中に入っているかどうかを論理的に判定するため部分的にキーワー
ドが含まれていれば真となるのでノイズが大きい。またブーリアン検索になんらかの重みを
反映したとしても、妥当な類似度順位を得ることは難しいので基本的には検索結果をフラッ
トに出すことになり絞り込み作業を何度も繰り返して、欲しい文書を集約する必用がある。
図 2.6: ConceptBase の語彙空間 [Justsystem]
こうした従来の検索システムとは異なり、ConceptBase は検索したい内容を自然言語で記
述した検索文を用いて検索を行う。まず検索文や検索対象となる文書からまとまって意味を
持っている語句を自動的に見つける。次に各語句の文書群における重要度を判定し、文書毎
にこのような語句の語彙空間を抽出する。そして語彙空間同士の類似性を判定する。語彙空
間のイメージを図 2.6 に示す。ここでは一例として 3 次元の語彙空間モデルを提示している
が、実際には n 個の単語からなる文書群の場合は n 次元の語彙空間を構成する。
こうして文書に記述されている内容の類似度で判定するので、検索結果が妥当な順番に出
てくる。また検索結果の上位にランクされた文書を新たな検索文として再度検索を行うこと
が可能なので、求める文書の検索作業を非常に早いサイクルで収束できる。
ConceptBase は非常に強力な検索エンジンであるが、検索対象の文書のインデックスとな
る語彙空間はテキスト情報のみから作成されるので、テキスト以外の情報は考慮されないと
20
いう問題がある。
2.1.5
現状の知識管理の問題点
本節では知識管理一般について様々な研究を概説した。2.1.3 節で述べたように、知識管
理における主要な課題として、
1. 知識獲得
2. 知識検索
3. 知識配布
の 3 つが挙げられる。しかし現状の知識管理の研究では、知識を表現する枠組みおよび知識
検索や知識配布に関して様々な取り組みが為されているものの、管理されるべき知識の存在
を a priori に仮定しており、知識獲得に関して正面から取り組んでいる研究は見受けられな
い。2.1.1 節で述べたように知識獲得は一つの非常に大きな問題であり、知識管理の研究に
おいても避けては通れない問題である。そこで本研究では特に知識獲得に焦点を置いて知識
管理研究を進めていくものとする。
21
2.2
設計知識に関する研究
設計は人間の知的創造行為であり、計算機による自動化は難しい。しかし設計者は日々
の業務において、大量の図面を正確に記述したり、膨大な設計データの一貫性をチェックし
たりするなど多大な労力を要する作業に追われており、計算機による支援に対する要望が
強いのも事実である。そこで設計作業を部分的に計算機に肩代わりさせるために、CAD や
CAE(Computer Aided Engineering) 等の計算機ツールの研究・開発が行われている。これ
らの計算機ツールを使用して設計を行うことにより、設計を効率的に進めることができるだ
けでなく、設計情報を計算機で利用可能なデータとして扱うことができるために情報の共
有・再利用という観点から見ても有効である。
本節では設計知識に関する研究を通して、計算機を使用した設計支援システムによる情報
の共有・再利用の現状について述べる。
2.2.1
幾何情報を中心とする製品情報管理
計算機による設計支援の先駆けとなったのは MIT の Sutherland による SketchPad の提案
である [Sutherland63]。これは計算機に CRT ディスプレイとライトペンを備えたシステム
を構築し、幾何情報を計算機内に保持することによって、製図作業の支援を行うものであっ
た。ここで提案された概念は、設計者は製図板の前に座るかわりに計算機の前に座り、計算
機の中に設計対象の幾何的な情報を保持させ、CRT に表示された幾何情報を見ながらその
情報を操作することができる、というものであった。
その後、計算機のグラフィック表示能力や CPU の処理速度が急速に向上し、計算幾何学
やデータベース理論などの発展も伴って、CAD は高度に発展していった。現在の CAD の多
くは 3 次元形状を扱い、幾何拘束処理やフィーチャーベーストモデリング、挙動シミュレー
ションを行なうものが実用化されつつある。
一方設計行為で用いられる情報には、設計対象の幾何的情報の他にも製品の仕様、部品カ
タログ、NC データなどのように製品の設計・生産に直接的に関わる情報や、製品コスト見
積り、開発スケジュールなどといった設計・生産活動そのものに関する情報がある。このよ
うな広範な製品情報を計算機上に表現することを目的としたプロダクトモデリングの研究
が行われており、製品情報を管理するシステムは一般に PDM(Product Data Management
system) と呼ばれる (例えば [Takahashi92])。PDM は、製品立案、開発、生産などの分野の
22
間で交換・生成される様々な情報を集めて管理するシステムであり、製品開発プロセスを再
利用するための中心的技術と考えられている。1.2.3 節で述べた CATIA は、こうした製品
情報を管理する枠組みと種々の幾何情報処理機能を統合したハイエンド CAD である。
設計対象に関する多様な情報を計算機内に保持することの最大の利点は、一度作ったデー
タを何度も利用することが可能なことである。こうして過去の情報の蓄積、管理および修正
が簡単に行え、情報の再利用を可能とする。
設計に関する情報量が膨大になってくるに従い、様々な設計情報を計算機によって管理しよ
うという要請はますます増えてくる。このため、製品や製造の品質向上・経費削減・時間短縮を
目指すために、企業活動全体の情報基盤整備により、設計・生産活動を含む様々な企業活動に
おける情報の電子化を図る諸活動である CALS(Commerce At Light Speed)[Kojima96] が、
各企業で取り組まれている。CALS は元来は調達の支援を意味する言葉 (Computer Aided
Logistic Support) であったが、製品・製造のライフサイクル全般にわたる各種ビジネス情報
や技術情報の統合を対象領域とするものに発展し、現在の定義に至っている。
この CALS の実現には情報の標準規格化が欠かせない。例えば種々の計算機ツール間で
データを交換するには、データ形式の標準化が問題となるが、このため STEP(STandard for
the Exchange of Product model data, ISO10303) と呼ばれる、データ形式の標準化を検討
する取り組みが行われている [Kimura93]。STEP の目的は、製品ライフサイクル全般にお
ける技術情報を計算機で処理するための体系を作り、異なるシステム間の情報交換や技術情
報の蓄積を実現することにある。STEP では形状情報や加工情報に関する標準化が中心であ
り、それに設計意図や製品の持つ機能などの情報を付加する方法を模索する方向で研究され
ているが、これらの製品情報のデータ形式の標準規格を策定するためには基本的な表現 (例
えば「ものの接続」) に関する概念のコンセンサスを取る必要性が指摘されている [Ito98]。
コンセンサスの取られた概念に基づいて製品の持つ情報を計算機上にモデル化することで、
表層的なデータ管理に留まらない、製品情報のモデルを通じた知識の管理を実現することが
今後必要となる。
2.2.2
設計の背景情報
2.2.1 節で述べた CAD で管理している知識や情報は、主に設計対象、特に幾何情報を中
心とするものであり、設計を行なった結果として得られる情報である。一方で標準的な設計
方法や設計変更履歴、あるいは設計過程における設計者の意図などといった、従来の研究
23
では扱われることの少なかった情報が設計行為において重要な役割を果たすことが鈴木ら
[Suzuki96] によって指摘されている。そのような情報は、設計が「どのようにして」あるい
は「なぜ」行なわれたのかを表すもので、一般に設計情報として陽には現れて来ない。なぜ
ならば、多くの場合、それらの情報は明示的に記録されるものではなく、またたとえ文書と
して記録されたとしても個人的なメモとして書かれる事が多いので管理の対象とはならず、
共有や再利用が困難だからである。
鈴木らは図 2.7 のように設計情報を分析して現在の PDM で取り扱われているか否かに分
類した上で、設計が「どのようにして」あるいは「なぜ」行なわれたのかを表す現在の PDM
で扱われていない情報を、背景情報 (DBI; Design Background Information) と定義した。
そして、設計作業の中で参照された部品のカタログやテキストなどから DBI を収集し、適
切なモデリングを行なってデータベースに蓄積した。収集した DBI はテキスト情報の他、
画像や音声などいった多様な形態を持った情報であったので、HTML(Hyper Text Markup
Language) を使用してハイパーテキスト化している。このため、設計者は HTML ブラウザ
を通じて、製品に関する DBI を参照できるようになっている。
この研究では DBI の獲得のため、設計終了後に設計者へのインタビューを行っている。し
かし、設計者の記憶が曖昧であったり、参照した情報が散逸していることも考えられるので、
DBI を十分に獲得できない可能性もある。
また 1.2.2 節で述べた LotusNotes を利用した商用グループウェアである Millemasse1 は
CAD データとともにワープロソフト、表計算ソフト等のアプリケーションで作成した文書、
オフィスに存在する紙書類などを電子化することで、各種の文書データを統合的に管理し、
スキャナや多機能 OA 機器で簡単にイメージ化してイメージ文書として、保管・検索・再利
用を可能とするシステムである。設計者が残したコメントや参照した情報などを CAD デー
タに添付してイメージ化することによって、設計結果として CAD データだけでなく、背景
情報を共有・再利用することができる。しかしやはり背景情報そのものの獲得は個々のユー
ザのモチベーションに依存せざるを得ない。
2.2.3
設計根拠に関する研究
一般に、製品がなぜ、あるいはどのようにして設計されたのか、という情報は設計意図あ
るいは設計根拠 (Design Rationale) と呼ばれる (例えば [Moran96])。
1
Millemasse は日立システム社の登録商標である。
24
Reference
design standard
drawing standard
assessment reference
design verification standard
standard part sample
standard material
standard structure
standard test
standard process
standard process time
Geometry
planning drawing
drawing
part drawing
product drawing
final drawing
Technology
product/tool specification
design specification
prototype
prototype test report
prototype trouble report
part catalog
process/operation plan
NC data
test specification
design calculation form
cost estimation
standard process time
design change history
R & D report
design know-how
trouble report
manufacturing method
facility capacity
process capability
Quality
product/part quality
prototype quality
market claim
Cost & Delivery
product cost estimation
part cost estimation
tool cost estimation
procurement cost
development schedule
Information not
satisfactorily covered
by today's PDM
Today's PDM
図 2.7: 設計情報と PDM [Suzuki96]
25
Garcia[Garcia92] は設計根拠に関する研究を、主にその記述・獲得方法の観点からモデル
ベース、議論ベース、行為ベースの 3 つに分類した。SHARE[Toye94]、SHADE[McGuire93]
はモデルベースの設計根拠記述を扱うことのできる協調設計支援システムである。これら
のシステムでは設計対象を表現するための知識モデルを備えているため設計作業およびそ
の根拠の再利用が容易であるが、設計者にとっては知識モデルの枠組みで設計対象を操作し
たり設計根拠の記述を行うのは困難であるという問題がある。2.1.2 節で述べた議論モデル
IBIS に基づいて構築された PHIDIAS[ShipmanIII97] は議論ベースのシステムである。モデ
ルベースの設計根拠記述に比べると設計根拠を記述しやすいものの、設計者にとっては IBIS
モデルにそってノードやアークのタイプを指定しながら設計根拠を記述するのはそれほど簡
単なことではないことが指摘されている。これら 2 つのアプローチは、設計終了後に設計を
振り返って説明を行うための枠組みを提案するものである。しかし一般に、議論終了後に議
論の説明を行うのは困難である、という問題がある。一方で行為ベースの設計根拠記述シス
テムである Electronic-Notebook[Lakin89] や岡田らの研究 [Okada93] では CAD などの設計
支援環境と接続されており、この環境下での作業のログを設計と同時に自動的に記録するこ
とができるため、設計根拠獲得は非常に容易である。しかしそれはあくまでも CAD 操作の
ログでしかなく、設計者にとってはその共有・再利用が難しいという問題がある。
2.2.4
設計知識研究における課題
現在の CAD システム、および設計情報の共有・再利用に関する研究について概観してき
た。これら既存の研究における問題点を以下にまとめる。
• 設計結果としての製品情報だけでなく、設計の背景情報、設計根拠を管理する必要が
ある。
いわゆる CAD とよばれる計算機システムでは製品の寸法や形状など幾何情報を中心
とし、製品コストや開発スケジュールといった製品情報の管理も可能なように拡張さ
れているものである。しかしこの枠組みで管理される製品情報は主に設計結果として
の製品の情報が中心である。鈴木らが指摘しているように [Suzuki96]、設計結果を生
み出すに至った背景情報や設計根拠を扱う枠組みとしては不十分である。
• 設計過程を表現するためのモデルを構築する必要がある。
STEP に関して伊藤らが指摘しているように [Ito98]、データ形式の標準規格を策定す
26
るだけではなく、表現に関する概念をモデル化することによって、製品情報を通じて、
表層的なデータ管理に留まらない知識の管理の実現が可能となる。設計根拠を計算機
上で扱う研究を概観したが、IBIS を始めとする議論モデルにより設計過程を記述する
試みも行われているものの、設計過程の表現モデルとしては不十分である。
• 設計過程の獲得を支援する必要がある。
設計根拠に関する研究では、その獲得方法については特に論じられていない。設計根
拠に関する情報は獲得そのものが難しく、また如何にして獲得すればよいのかも明確
ではないことが問題である。この問題は主に次の 2 点が原因と考えられる。
– 設計過程を記述する枠組みと設計支援環境とは統合されていない。
設計過程における設計根拠を獲得するのが困難である理由の一つは設計根拠を記
述する枠組みと設計支援環境が統合されていないからであると考えられる。2.2.3
節で述べたように行為ベースのアプローチでは CAD との統合が図られているが、
設計作業で利用される計算機ツールは多種多様であり、それら各ツールの統合環
境と設計根拠記述の枠組みとの統合が求められる。
– 設計過程獲得の容易さと、その共有・再利用の容易さの間にトレードオフがある。
2.2.3 節で述べたように行為ベースのアプローチでは CAD 操作のログを自動的に
記録することにより、設計過程の獲得が容易に行える。しかしあくまでも CAD
操作のログでしかなく、設計者にとってはその共有・再利用は困難である。一方
でモデルベース、議論ベースのアプローチでは設計根拠を表現するためのモデル
が備えられているために設計者にとってはその共有・再利用が容易であるが、獲
得を自動化することは困難である。
27
2.3
KIEF
冨山らは、設計、生産、保全、廃棄などの製品ライフサイクルの各段階において、製品や
作業プロセスに関する知識を統合的に管理し、設計者に提供することによって製品に付加価
値を与えるとともに、作業の高能率化を図ることを目的とする知識集約型工学を提唱してお
り [Tomiyama94]、知識集約型工学の概念に基づいた計算機システムを開発している。本節
ではその概要について述べる。
2.3.1
知識集約型工学の基本概念
知識集約型工学とは、設計や保全などの製品のライフサイクル全般における知識や情報を
計算機上に集約し、様々な観点から製品を評価するための枠組みを提唱するものである。
知識集約型工学においては、図 2.8 に示すように設計、生産から保全、修理および再利用
に至る工学的活動において、知識を柔軟かつ統合的に用いることで作業の高能率化を図るこ
とができると考えている。例えば、製品設計の段階でその対象を計算機上に形状モデル等と
して表現すると、その製品の生産や修理の段階でこのモデルから必要な情報を得て、各々の
段階に応じたモデルを構築したり、逆にこのモデルに対して情報を付加することで次回の設
計に役立てることが出来る。このように設計者から現場の技術者までが相互に情報を交換し
て作業を進めることで、作業の高能率化を可能とする。
このような知識集約型工学を実現するためには次の 3 つの技術の確立が必要である。
1. 大規模知識ベース (VLKB; Very Large Knowledge Base) の実現
工学的活動で使用される様々な知識を大規模知識ベースに蓄積し、その共有・再利用を
可能とする。これにより、多様なモデルの構築、修正、評価などの操作に必要な知識を
提供する。
2. 複数の工学モデルの管理
ライフサイクル全般を考慮した製品を設計するためには、形状モデル、有限要素モデ
ル、ブロック線図など、一つの製品を様々な観点から評価するための工学モデルが必要
であり、更にこれら複数の工学モデルの一貫性を管理する。
3. 設計過程および設計意図の管理
複数のモデルを使いわけながら進められる設計作業における過程の管理、およびモデル
操作に対する意図を獲得・管理する。
28
VLKB
Electrical
Model
Thermodynamic
Model
Geometric
Model
Strength
Model
Engineering Models
Kinematic
Model
Model Modification
Model Validation
Model Operations
Model Building
Simulation
Recycling
Design
Model-based Reasoning
Repair
Product Life Cycle
Manufacturing
Maintenance
Operation
図 2.8: 知識集約型工学環境
2.3.2
計算機システムとしての実装
2.3.1 節で述べた基本概念に基づき、吉岡、関谷らによって計算機システムの実装が行われ
ており、この計算機システムを KIEF と呼んでいる [Yoshioka96, Sekiya99]。図 2.9 に KIEF
のシステム構成を示す。
概念辞書
KIEF は計算機上に設計対象を表現する複数の工学モデルを統合するため、後述するメタ
モデル機構と呼ばれる仕組みを持っている。メタモデルは各モデルで使用される概念間の関
係を表現するモデルであり、モデルのモデルと考えることができる。メタモデルを中心モデ
ルとして各モデルを統合することにより、2.2.1 節で述べたように表層的なデータ管理に留
まらない、製品情報のモデルを通じた知識管理を実現することができる。
KIEF では、メタモデルを構築する際に使用される語彙を概念辞書の知識として提供して
いる [Sekiya95]。概念辞書は物理世界を背景としたオントロジーであり、メタモデルを構成
29
VLKB of
Engineering Knowledge
The Pluggable Metamodel Mechanism
Physical Feature KB
Catalogue
Conceptual models of
mechanisms
3D Solid
Modeler
Parts
Selecter
Spreading
Earthquake
Watar
Strength
Liquefied
2D Draw
Modeler
Metamodel
provide
vocabulary
n-value
Soft
Strata
Layer
Mass
provide
building blocks
provide vocabulary
Concept Base
Definition of concepts
Density
correspondence
Q+: Strata N
Liquefied degree
i = r1 / r2
I = (Pi * l * r ^ 4) / 32
FBS Modeler
QP
Reasoner
Formulae
Modeler
provide
appropriate
model
fragments
Model Library
Representation by
design object models
Qualitative Equations
Design Object Modelers
Function Model
Knowledge about Modelers
3D Solid Model
Interface of Modelers
図 2.9: KIEF のシステム構成
する概念の基本セットを提供するものである。概念辞書に入らない領域依存の概念は各領域
のオントロジーを用意することで提供し、概念知識の整合性は各オントロジー内で保つこと
を考えている。このために、2.1 節で述べた、全ての知識を一つのオントロジーで記述する
アプローチと比べて、その知識の獲得および保守が容易である、という利点がある。
概念辞書の知識には以下の 5 つのタイプがある。
• 実体概念
「モータ」や「歯車」といった、ものに関する概念である。
• 関係概念
伝導体同士の「電気的接続」や歯車間の「噛合い」といった、複数の実体概念間の関
係を表現する概念である。
• 物理現象概念
「回転」や「発熱現象」など自然界の物理的現象に関する概念である。
30
• 属性概念
「半径」や「質量」、「距離」などの物理量を表現する概念である。
• 物理法則概念
一般に物理世界における法則や定理として、物理現象の背景に存在しその現象に関わ
る属性間の関係を定義する概念である。
これらの概念を組み合わせることで、各モデルで利用される概念のネットワークをメタモ
デル内に構築することができる。例えば、実体概念と関係概念とで設計対象の構造が表現さ
れ、さらに物理現象概念を加えることで設計対象の挙動が表現される。
また、各概念は抽象・具体関係に基づく階層構造で管理されており、上位の概念が持つ性
質は下位の概念にも引き継がれる。
他にも VLKB に蓄えられた知識としては、これらの物理世界の概念を元に構築され設計
解のビルディングブロックとして利用されるフィジカル・フィーチャや設計解の機能に関す
る知識などがある。
プラガブル・メタモデル機構
設計過程の進行に伴い、形状モデル、有限要素モデル、ブロック線図といった様々なモデ
ルが作られると、これらの各々のモデルで表現される設計対象の情報を統合的に管理する必
要が生じる。KIEF においては、モデルを統合するための中心的役割を果たすものとして、
プラガブル・メタモデル機構 [Yoshioka98] を利用している。
一般に設計対象のモデルは、特定の観点から見てその観点に関連のある情報を抽出して表
現したものである。モデルを作成する過程では、そのモデルが扱うことができる諸概念を定
義している背景理論に従って、設計対象の特定の属性や挙動を記述する。たとえば、2 次元
や 3 次元の形状モデルは代数幾何学を背景理論としており、変形量を計算するため有限要素
モデルは材料力学を背景理論としている。
これらのモデルを統合するものとして、冨山らはメタモデル機構を提案した [Tomiyama90]。
メタモデル機構では、各背景理論で用いられる概念がお互いにどう関係するのかを知識とし
て持ち、背景理論レベルでの関係付けを行なうことで、モデルの一貫性を管理している。各
モデルの概念間の依存関係のモデルをメタモデルと呼ぶ。
31
更にプラガブル・メタモデル機構は、機構に接続するモデラで用いる概念と、メタモデ
ル上で表現される概念との関係（変換方法など）を記述することにより、メタモデル機構自
体の変更を伴わずに、設計対象モデラの接続が可能 (pluggable) であるメタモデル機構であ
る。このために、メタモデル機構におけるモデルの一貫性の管理をより柔軟に行なうことが
できる。
2.3.3
KIEF における設計過程
KIEF の設計過程はメタモデルに対する操作の列として表現される。一方で，メタモデル
は製品情報の論理モデルとして表現されているので，メタモデルを直接操作することは設
計者にとって難しい作業である。このためメタモデルへの直接操作である論理操作に加え、
KIEF は以下の 2 つの操作をサポートしている。これらの操作は、図 2.10 で示すようにプラ
ガブル・メタモデル機構を通じて、最終的にメタモデルに対する操作に変換される。
モデル操作：「モデルの構築」や「修正」など、特定のモデルに依存しない、モデルに対す
る一般的な操作である。プラガブル・メタモデル機構に対して行われる。
モデラ操作：特定のモデルに依存する操作である。たとえば、FEM における「要素の選択」、
機能モデリングシステムにおける「機能分解」などである。
図 2.10: メタモデル操作の対応関係
32
2.3.4
知識集約型工学環境における課題
KIEF は複数のモデルを統合することによって、形状情報だけでなく各モデルで表現され
る様々な情報を用いて進められる設計作業を支援することができる。しかし現状の KIEF シ
ステムは次のような課題を抱えている。
• 統合環境における設計指針が不明確である。
KIEF はプラガブル・メタモデル機構に接続された各モデラによって設計対象を様々
な観点から表現することが可能である。しかしながら種々のモデラの統合環境を用意
したに止まり、この環境の下で設計者がどのように設計を行えばよいのかという指針
が不明確である。
• 設計意図や設計過程を表現する枠組みが不足している。
メタモデルへの操作として設計過程を自動的に記録することはできるものの、獲得で
きるのはあくまでもログに過ぎず、設計の理論的根拠を獲得したとはいえない。また
試行錯誤が度々行われる設計過程を管理する機構として十分な機能を持っていない。
33
シンセシスのモデルと推論フレームワーク
2.4
KIEF は物理世界に関する様々な知識をデータベースに蓄え、また様々な設計対象モデラ
を統合することによって統合設計支援環境を提供するものであるが、この環境下での設計過
程に関する知識が不充分であり、設計者を十分に支援することができない。
一般に設計者の思考過程はシンセシス志向のものとアナリシス志向のものとに分類する
ことができる。人間の創造行為においてシンセシスは重要な役割を果たすと思われるが、ア
ナリシスと比較するとその科学的解明は十分でないのが現状である。例えばドイツの研究者
達によって提案された設計方法論では設計者の思考のモデルとして、与えられた要求仕様を
分解して機能の階層構造を構築し、カタログとして集められた物理原理の中から各機能を実
現するのに適したものを選択、それらをまとめあげることによって設計解の提案を行うとさ
れている [Pahl88]。しかしこのモデルでは設計者の思考過程を後から説明することはできて
も、設計者の思考過程自体のモデルではないため、実際に設計者の思考を支援することは難
しい。それゆえ、設計者の思考過程のモデルを構築することが設計支援において重要な課題
である。
我々のグループでは 1996 年から 2001 年にかけて日本学術振興会未来開拓学術研究推進
事業の下、「シンセシスのモデル論」プロジェクトを行った。このプロジェクトでは、設計
過程における設計者の知識操作を分析し、その分析に基づいて、前節で述べた KIEF をベー
スとして設計の推論フレームワークを実装した [Yoshioka01a]。本節ではこの推論フレーム
ワークについて簡単に説明する。
2.4.1
知識操作と設計の基本語彙
「シンセシスのモデル論」プロジェクトでは設計は設計者の知識操作によって進められる
としている。そこで実際の設計者の活動を観察することにより、まず以下の 7 つの知識操作
を確認した。またこれらの知識操作はいろいろな順番で行わている事から、設計における知
識操作は、単純な問題解決過程の繰り返しではないことが分かった。
1. 知識/情報の獲得
問題解決のためにその問題に関連した知識や情報を獲得するための知識操作である。
2. 知識/情報の再構成
すでに獲得した知識や情報を問題解決のために再構成するための知識操作である。
34
3. 情報の確認
ある知識源における情報を他の知識源の情報と照らし合わせて確認を取る知識操作で
ある。
4. 矛盾の解消
情報の間に発生した矛盾を解消する知識操作である。
5. 知識/情報の修正
知識や情報を他の知識と統合するために修正する知識操作である。
6. 解のシンセシス
ある問題に対する新たな解を提案する知識操作である。
7. 解の分析
評価のために解を分析する知識操作である。
これらの知識操作は設計を分析して得られたものであるが、必ずしも設計に限らずその他
の様々な知的活動における知識操作に共通しているものと考えられる。
一方で、この知識操作を用いて設計事例における設計過程を記述しようと試みたところ、
実験や試作などといった設計における個々の活動と一対一に対応付けることが難しいことも
分かった。そこで設計事例から抽出された個々の設計活動について、設計に関する語彙を用
いてより一般的かつ詳細な形で表現し、それを設計過程との対応付けに利用することにし
た。表 2.2 に知識操作と語彙との対応関係を示す。これらの語彙は、シンセシスの過程に関
わる語彙として、ブレインストーミングによって得られた 112 種類の語彙リストを基にして
いる。
これらの語彙を用いて例えば、
• 接触面のずれや移動に伴うへこみのゆがみは上面が動くことに起因している
• 上面（X-Y）テーブルを固定すればよい
• X-Y テーブルを樹脂タンク下側とし、樹脂タンク上面はタンクと一体化する
という一連の設計活動のプロトコルは、以下のように解釈することにした。
”接触面のずれや移動に伴う…”という設計活動で、その前に行われた実験での矛盾を受
けて「推定」と「知識獲得」が行われ、この原因を解決する手法の「調査」によって情報を
35
収集した。その「情報の整理」の過程で、”上面（X-Y）テーブルを固定すればよい”という
「発想」がされた。このアイデアに従って「知識獲得」し、さらに得られた「知識の再構成」
を行って”X-Y テーブルを樹脂タンク下側とし、…”という「提案」が出されている。
表 2.2: 知識操作と設計語彙の対応
知識操作
対応語彙
知識・情報の獲得
調査、知識獲得、問題点指摘
知識・情報の再構成
知識・情報の整理、知識・情報の再構成、具体化、製図
情報の確認
確認
矛盾の解消
矛盾解消
知識・情報の修正
制約の操作、知識・情報の修正
解のシンセシス
提案、選択、発想、問題分割、詳細化、改良、
連想、具体化、決定
解の分析
評価、実験、試作、推定、数値解析、導出
このようにして、各々の設計活動に対して 1∼数個の語彙を用いて説明する。上の例では 3
個の設計活動が８個の語彙によって表現されている。これにより、例えば”上面（X-Y）テー
ブルを固定すればよい”という設計活動は、”手法の調査を行う”、”調査で得られた知識を整
理する”、”上面テーブルを固定するという発想がされる”という 3 つに詳細化することがで
きた。
2.4.2
設計過程の知識
次に、知識操作を元に KIEF における設計過程の知識を定式化した。設計過程の知識は、
論理レベルで設計過程を定式化し論理推論によって設計作業のシミュレーションが可能であ
る設計シミュレータ [Takeda92] の行為レベル知識に準拠した。設計シミュレータにおける
行為レベル知識は、設計対象の状態を条件とし、設計対象に対する操作列を行為とする優先
順位つきのルールで記述されている。これらの行為レベルの知識を 2.4.1 節で述べた知識操
作と対応付けて整理すると以下のようになる (ルール適用の優先順に記述)。
1. 設計仕様の入力
36
条件設計仕様が与えられていない。
操作設計仕様を入力する (知識/情報の獲得)。
2. 矛盾の解消
条件矛盾が存在する。
操作矛盾を特定し (知識/情報の再構成、情報の確認)、矛盾の解消を行い (矛盾の解
消)2 、知識、情報の修正を行う (知識/情報の修正)。
3. 設計解の展開・評価
条件新しい設計解が提案された。
操作新しい設計解に関連する知識ベースを導入し（知識/情報の獲得）、演繹を行う
(解の分析)。さらに矛盾がないかを確認する (情報の確認)。
4. 設計解の提案
条件必要とされる機能が実体により具体化されていない場合。
操作実現されていない機能を問題点として確認し (情報の確認)、問題点に関連する知
識ベースを導入する (知識/情報の獲得)。さらに、問題点に対してアブダクションによ
り解を提案する (解のシンセシス)。
これらの知識を実際の KIEF の操作で記述することにより、KIEF における設計過程知識
を実装する。設計過程知識の記述フォーマットは論理プログラミング言語 Lisp の形式に準
拠した形で作成されている。図 2.11 に設計過程知識「設計仕様の入力」の記述を示す。
2.4.3
システムの実装
図 2.12 に示すように、設計過程知識およびその推論エンジンを KIEF 上に構築すること
により、設計の推論フレームワークシステムを実装した。設計過程知識の推論部は KIEF に
おける設計対象レベルの推論のメタ推論となっており、設計対象の状態が条件部にマッチす
る設計過程知識を設計者に提示する。設計者は提示された設計過程知識を選択することによ
り、設計対象の状況に応じて適切な設計を進めることができる。
2
設計シミュレータの実装ではサーカムスクリプション [McCarthy80] を用いて、矛盾を生じた知識に例外を
示す節を付与することにより行っている。
37
条件：
(isEmpty: (getCurrentRequirement))
；設計仕様が与えられていない場合
操作：
(setq #RelatedModelers (#relatedModelers:type: () #requirement))
；要求仕様に関連する推論システムの提示
(setq #SelectedModeler (#selectOneFrom:message: (#RelatedModelers ’=’
(<modelers>))
’select one modeler for requirement.’) )；推論システムを一つ選択
(setq #NewModeler (#makeModelerOn: (#SelectedModeler ’=’ <modeler>)))
；選択した推論システムでモデルを構築
(setq #NewRequirements (#getModelerInformation: (#NewModeler ’=’ <modeler>)))
；要求仕様をモデラに記述
(addInformation: (#NewRequirements ’=’ (<specifications>)))
；記述された要求仕様を設計情報に追加
図 2.11: 設計過程知識「設計仕様の入力」
設計者
設計過程知識DB
設計過程知識の
選択
行為レベル推論
Ka
C O
Ka：設計仮定知識
C：設計対象の状態
O：操作
KIEFに対する
操作
条件
操作
KIEF
対象レベル推論
Length
Shaft
Thickness
メタモデル
Connected
Table
Inertia
Density
Radius
Radius
Density
i = r1 / r2
I = (Pi * l * r ^ 4) / 32
各種設計対象モデラ
図 2.12: 推論フレームワークの構成
38
2.4.4
課題
シンセシスのモデルに基づく推論フレームワークにより、KIEF における設計過程知識を
実装することが可能となったため、統合環境における設計指針が明確になり、設計者をナビ
ゲートすることができるようになった。またシンセシス推論フレームワークのログを記録す
ることにより、2.2.3 節で述べたように設計根拠を獲得することは容易である。しかしそれ
はあくまでもログであり、人間にとっては理解しがたいだけでなく、知識としての利用価値
もそのままでは低いと言わざるをえない。
39
本研究における設計知識管理
2.5
2.5.1
設計知識管理における課題
本章では、設計知識管理に関してこれまでに行われてきた研究について概観した。
まず知識工学や人工知能、計算機科学などの各分野で行われている知識管理に関する研究
一般について概略を述べ、その課題として
1. 知識獲得
2. 知識検索
3. 知識配布
の 3 点を挙げた。
次に設計研究の分野で行われている CAD を中心とする製品情報や設計知識管理研究の現
状、および設計作業における意思決定の理論的根拠である設計根拠を取り扱う研究について
述べ、その課題として、
• 設計結果としての製品情報だけでなく、設計過程における背景情報、設計根拠を管理
する必要がある
• 設計過程を表現するためのモデルを構築する必要がある
• 設計過程の獲得を支援する必要がある
の 3 点を挙げた。
次に我々のグループがこれまでに研究してきた知識集約型工学環境およびシンセシスのモ
デルに基づく推論フレームワークにおいても、
• 設計過程のログは記録できるが、設計意図や設計過程を表現する枠組みが不足
• 記録される設計過程は人間にとって理解し難い
という問題点があった。
40
2.5.2
本研究におけるアプローチ
本研究では設計支援のための知識管理実現を目指し、知識管理における 3 つの主要な課
題、その中でも特に知識獲得の問題に焦点を置いてその解決を図る。
知識獲得とは設計者の経験を獲得することであると考えられる。そこで、設計作業と同時
に設計文書を作成することによって設計過程の情報をできるだけ欠落無く獲得することを考
える。このため、2.4 節で述べた知識操作モデルを元に情報導出に基づく設計過程記述の枠
組みを提案し、KIEF と統合することによって、KIEF で作業を行いながら設計作業を知識
操作の履歴として獲得する。またこの枠組みのインターフェースは HTML 文書のエディタ
として構築するので、設計者が設計作業中に参照した情報、構築したモデルをハイパーリン
クしたり、自由にコメントを書き込んだりすることで設計者の知識の外在化を促すことがで
きると考えられる。
次に知識検索のために、通常のキーワード検索ではなく、設計文脈情報を考慮した方法を
提案する。
最後にこうした方法論を実装したシステムを計算機ネットワーク上で構築することにより
知識配布を実現する。
41
42
第 3 章知識管理のための設計文書に関する
理論
本研究は知識管理における主要な課題の一つである知識獲得に特に焦点を置く。そのため
に設計者が持っている知識を文書の形態で獲得することを考える。本章では、設計者の知識
を設計文書として獲得するための方法論について述べる。
まず設計文書についてのモデリングを行う。本研究では設計文書は何らかの目的を持って
記述されるものであり、またその記述には目的に応じて一定のパターンがあるものであると
考える。次に設計文書が作成されるプロセスを考察する。基本的に設計文書は設計に関す
る文書なのであり、設計過程で考慮された情報に基づいて記述されるはずである。また一方
で、実際の設計過程では考慮されず設計文書作成の際に追加される情報もあると考えられ
る。このような設計文書作成に必要な情報を網羅的に記述したものとしてメタプロセスモデ
ルを導入する。メタプロセスモデルでは情報導出という考えに基づいて、どの設計情報がど
の設計情報が導出されたかで設計過程を記述する。次に実際に設計作業で作成された設計文
書を分析することにより、本研究で提案する設計文書に関する理論の妥当性について検討を
加える。
44
設計文書のモデリング
3.1
本節では本研究で提案する設計文書のモデルについて概略を述べる。2.5 節で述べたよう
に設計知識管理の課題として
1. 設計結果としての製品情報だけでなく、設計過程における背景情報、設計根拠を管理す
る必要がある
2. 設計過程を表現するためのモデルを構築する必要がある
3. 設計過程の獲得を支援する必要がある
という点が課題となっていた。このうち 1 および 3 については次章で述べることとし、本章
では設計文書のモデリングによって 2 の課題を解決することを考える。ここで設計文書をモ
デリングする際に次の 3 点を留意する。
1. 設計文書の記述を知識操作の過程とみなす。
2. 設計文書に記述される情報は設計過程で操作された情報が元になっている。
3. 報告書や特許申請書など、設計文書が記述される目的に応じて記述のパターンが存在
する。
以下でその詳細について述べる。
3.1.1
設計過程
設計文書に限らず文書は、それを読むことによって記述者の思考を読者に再現させること
で、記述者の主張を伝えることを狙う媒体である。また設計文書は小説や詩などと違い科学
的な主張に基づく文書であるから、そこに記述されているのは科学的な思考である。設計に
おける思考を文書として記述するためにはどのような枠組みが必要だろうか。この点を議論
するために、まず設計過程の特質について確認しておく。
設計に限らず複雑な問題を解く際には、各部分問題に対して一つ以上の解候補を求め、各
候補が本当に問題の条件を満たすかどうかを評価するプロセスが存在することは、容易に想
像される。また、最終的に導き出された解を第三者が十分に理解するためには、単にその最
終解を知るだけでなく、採用されずに破棄された設計解も含めて最終解に至った過程を知る
必要がある。このために、設計情報の共有を実現するためには、最終設計解に至るまでの試
45
行錯誤の過程の情報が必要である。
設計作業は一方向に進むのではなく、複数の案を同時に検討したり、以前の案に戻って検
討し直すなど、試行錯誤を繰り返しながら進んでいくプロセスである。武田らは設計作業の
分析を行い、設計対象の変化と設計者の思考の推移に注目した分析を行っている [Takeda91]。
図 3.1 は、たばこの自動販売機の搬送機構を例題とした設計実験の分析の一部である。ここ
では、連結された矩形の集合の一つ一つがある段階での設計対象の記述を示している。設計
対象の記述が推移する様子を黒色の矢印で、また設計者の視点の変化の様子を灰色の矢印で
示している。
(1)
(3)
Cam mechanism
A design object
Roller mechanism
(5)
Transition of an object
Crank mechanism
(4)
(2)
Cam mechanism
Transition of a designer's viewpoint
Roller mechanism
(6)
motor
Pins on the roller
Discard
Crank mechanism
Flexible bar
(7)
Roller mechanism
Stepping motor
Pins on the roller
(8)
(9)
Roller mechanism
Roller mechanism 2
Stepping motor
Pins on the roller
Stepping motor
Pins on the roller
1/3 cycle for a cigarette
1/3 cycle for a cigarette
図 3.1: 設計対象の記述および設計者の視点の推移 (一部)[Takeda91]
このように設計作業は必ずしも順に繰りされるだけではない。一度に複数の案を検討した
り、元の案に戻って検討し直したり、また同時に進めていた作業を一つの作業にまとめるな
ど、設計は複雑に分岐や融合、後戻りを繰り返す過程を含んでいる。
3.1.2
知識操作による設計文書記述
このような特質を持つ設計過程を記述するためには、記述される各々の情報、およびどの
情報からどの情報が導かれるのかという情報の導出関係が必要である。情報の導出関係に関
する考察として、Peirce の研究を挙げることができる。Peirce は人間の科学的な思考を、演
繹 (deduction)、帰納 (induction)、アブダクション (abduction) の 3 つに分類した [Inoue92]。
46
各々を、例として次のような三段論法に沿って記号的に説明すると次のようになる。
• 大前提：A ならば B である (A ⊃ B)。
• 小前提：A である。
• 結論：ゆえに B である。
演繹大前提、小前提から結論を導き出す推論である。つまり A ⊃ B, A B という推論で
ある。
帰納小前提、結論から大前提を導き出す推論である。つまり A, B A ⊃ B という推論で
ある。
アブダクション大前提、結論から小前提を導き出す推論である。つまり、A ⊃ B, B A と
いう推論である。
このような推論形式によって分類される各推論タイプを用いて情報の導出関係を記述する
ことが出来そうであるが、しかし Peirce が行った推論の分類は、設計文書をコーディング
する枠組みとしては抽象的すぎると思われる。
一方で我々のグループでは、設計における思考過程を記述する枠組みとして 2.4.1 節で述
べた知識操作を開発している。知識操作は設計における思考過程に則した物であるため、設
計文書のコーディングに適していると考えられる。そこで本研究では、設計文書の記述を知
識操作に基づいてコーディングすることを考える。
ところで知識操作は推論形式に基づいた分類を行っていないため、設計における思考を分
類することは出来るが、各知識操作によって発生する情報の導出関係を記述する能力が不十
分である。そこで各知識操作に対応した情報の導出関係を明らかにするために、まず操作の
対象となる設計情報を分類する。
本研究では吉岡らの研究 [Yoshioka00] に基づき、この世の中に存在する情報を、設計者
が知っていて利用可能な内部情報と、設計者がすぐには利用可能ではない外部情報に分類す
る1 。外部情報は、カタログや参考書、Web 上のサイトなど設計者の外部にある情報源から
得られる情報である。内部情報はさらに以下の 4 種類に分類される。
1
この分類は、設計のある時点における設計者の知識操作の観点から分類したものであって、2.2.2 節で述べ
た Design Background Information および Design Foreground Information の分類と直行する。
47
• 設計知識
設計者が持つ一般性の高い情報。
• 要求仕様記述
設計する製品の機能や求められる属性、解決すべき問題点、中間目標に関する情報。
• 設計対象記述
形状、材質、トポロジーなどといった設計対象の直接的な属性となっている情報である。
• 設計対象関連情報
特定環境における設計対象の挙動や設計対象に起こりうる物理現象などといった、設
計対象記述から得られる 2 次的な情報である。
さらに人工物全体の集合を設定し、人工物も設計情報の一種とする。人工物は設計対象記
述を元に試作されたプロトタイプなどである。
これらの各々の設計情報を含む集合に対する基本的な操作として以下の 3 種類を設定する。
追加：新たな情報を各々の要素が属する情報の集合に付け加える操作である。
修正：既存の情報を変更する。ある情報を集合から削除して関連する情報を追加するとい
う操作や単なる削除もこれに含める。
参照：その情報を含む集合自身に追加・修正などの操作を行うのではなく、その情報を利用
して、他の情報の集合への追加・修正などの操作を行う。
各設計情報を情報導出における導出元および導出先に割り当て、その意味を分析すること
によって情報導出と知識操作の対応付けを行う。この時に情報導出の意味を捉えやすくする
ために、各情報導出を一旦 2.4.1 節で述べた設計の基本語彙レベルに対応付け、表 2.2 に基
づいて基本語彙を知識操作に読み替えることによって、最終的に知識操作へと対応付ける。
この対応関係を図 3.2 に示す。図 3.2 では情報導出の導出元となっている情報タイプに対し
て「参照」、導出先となっている情報タイプに対して「追加」および「修正」の各基本操作
を割り当てている。これは先ほども述べたように情報導出の意味を分析する際に捕らえやす
くするためである。
48
内部情報
知識操作
基本語彙
外部情報
要求仕様記述
設計対象記述
参照
調査
参照
追加
知識獲得
知識情報の再構成知識・情報の再構成
修正
追加or修正
参照
製図
追加or修正
参照
参照／修正
矛盾解消
知識・情報の修正
参照
具体化
確認
矛盾の解消
参照
参照／修正
知識・情報の整理
情報の確認
人工物
追加
追加
知識・情報の獲得問題点指摘
設計対象関連情報設計知識
参照／修正
制約の操作
修正
参照
提案
参照
追加
発想
参照
追加
参照
参照／修正
知識・情報の修正
解のシンセシス
連想
参照／追加
選択
参照／修正
決定
参照
参照／追加
改良
参照
修正
参照
評価
参照
参照
参照
解の分析
追加
追加
実験
数値解析
参照
試作
参照
導出
参照
参照
参照
追加
参照
追加
追加
図 3.2: 設計情報に対する操作と基本語彙・知識操作との対応関係
例えば、「知識・情報の再構成」に対応する「具体化」は内部情報を参照して、修正ある
いは追加された設計対象記述を導出する操作に対応する。
知識操作によって設計文書をコーディングした例を図 3.3 に示す。
文書の記述
基本語彙知識操作
情報の導出関係
冷却時のメカニズムとして冷却状態では固体モノマーはほと
んど光重合反応をしておらず、希釈モノマーが主に反応する
という結果を得た。
実験
解のシンセシス
従って、冷却固化した状態の樹脂を光硬化させても体積収縮
はほとんど起こらず、
導出
知識・情報の再構成
参照：D2(冷却状態では固体モノマーはほとんど光重合反応をし
ておらず、希釈モノマーが主に反応する)、追加：D2(冷却固化し
た状態の樹脂を光硬化させても体積収縮はほとんど起こらない）
内部応力の問題を解消できる可能性があることが分かった。
評価
解の分析
参照：R(内部応力を防ぐ）、参照：D2(冷却固化した状態の樹脂
を光硬化させても体積収縮はほとんど起こらない）、追加：（問
題を解決できる）
参照：Ａ（樹脂)、追加：D2(冷却状態では固体モノマーはほとん
ど光重合反応をしておらず、希釈モノマーが主に反応する)
図 3.3: 知識操作によるコーディングの例 (一部)
49
3.2
設計文書の生成
本節では設計過程の情報を元に設計文書を生成するプロセスを提案する。その概略を図
3.4 に示す。まず設計過程における設計者の思考過程を網羅的に表現したモデルの存在を考
え、これをメタプロセスモデルと呼ぶ。メタプロセスモデルは設計過程を記述したバルク
データを知識操作によってコーディングすることにより得られる。このメタプロセスモデル
に適当な変換処理を施すことで、目的の文書の記述パターンに適応した文書モデルが得られ
る。そして文書モデルに変換辞書を適用して自然言語で書かれた文書を得る。生成された文
書に対して必要に応じて情報を追加記述することも考えられる。追加された情報はモデルへ
フィードバックされることによって別の文書の生成の際に利用されることになる。またこの
文書は 4.4.1 節で述べるようにハイパーテキストによって記述されるものである。
なお本研究で行う実装では図の網掛け部分の実装を行っておりその詳細については後の章
で述べるが、本章では文書生成プロセスの全容について説明し、3.3 節で述べる簡単な実験
によりモデルの妥当性の検証を行う。
感光性樹脂を用いて立体的な造形物を形
成する。
文書記述辞書
知識操作辞書
設計過程の
ログデータ
I
MPMの
自然言語によ
思考パターンる文書の記述
....
....
....
メタプロセスモデル(MPM)
I
D1
D1
D1
D1
A
A
R
その結果、造形物のオーバーハング
状部分に反りなどの変型が生じるこ
とがわかった。
知識操作
R
R
造形機の設計を行い、試作機を造っ
て実験を行った。
D2
D2
R
造形物のオーバーハング状部分の反りな
どの変形を防ぐ必要がある。....
D2
D2
文書
R
文書のマクロパターン
1 従来の技術の課題
D1
MPMの
思考パターン
2 発明が解決する課題
....
文書思考パターン変換辞書
MPMの
DMの
思考パターン記述パターン
....
....
文書テンプレート
情報のフィードバック
A
D2
R
感光性樹脂を用いて立体的な造形物を
形成する光造形法において、造形物の
オーバーハング状部分の反りなどの変
形を防ぐ必要がある。
R
DMの
記述パターン
R
この問題に対しては、オーバーハング状
部分の下部にこれを支持する柱状のサポ
ート部分を形成することが考えられる。
R
R
D1
しかしサポート部分の設計は煩雑であ
り、熟練を要するものである。
R
文書モデル(DM)
文書
文書記述辞書
DMの
自然言語によ
思考パターンる文書の記述
....
....
図 3.4: 文書生成プロセスのリファレンスモデル
50
浮遊部分の造形ができないことが分
かった。
3.2.1
メタプロセスモデルの導入
本手法で設計文書を作成するにあたり、文書に記述する内容の情報源として設計者の思考
過程を直接利用することが望ましい。しかし、現実的な問題として設計者の思考過程をその
まま観測・モデル化することは困難であるため、文書を生成する前段階として中間表現的な
モデルを考える必要がある。このモデルをメタプロセスモデルと呼ぶ。メタプロセスモデル
は、各文書で記述される情報の導出関係を統合するモデルであり、設計過程における設計者
の思考を網羅的に記述したものである。
メタプロセスモデルは設計者の思考を網羅的に記述したものであるから、設計過程におけ
る知識操作を全て含んでいる。メタプロセスモデルの作成は、設計過程を全て記録したデー
タを 2.4.1 節で述べる知識操作でコーディングし、データ中に含まれる知識操作のインスタ
ンスの集合を得ることによって行われる。文書モデルにおける記述パターン同様、メタプロ
セスモデルにおける知識操作および設計情報によって設計過程のパターンを記述することが
可能となる。これを思考パターンと呼ぶ。思考パターンの BNF 表記を図 3.5 に示す。
メタプロセスモデルは 3.1.2 節で述べた文書モデル同様、知識操作によりコーディングさ
れるため設計情報間の導出関係を表現できるとともに、設計の内容および文書の種類に関わ
らない統一的なモデルの記述が可能となる。
思考パターン::=記述の主題, 操作, 操作*
記述の主題::=外部情報|内部情報|要求仕様記述|設計対象記述|設計対象関連
情報|設計知識|人工物
操作::=知識操作|基本語彙
図 3.5: 思考パターンの BNF 表記
3.2.2
記述のパターンと文書モデル
一般に、ある特定の目的をもった文書に関しては内容に関わらない一定の記述パターン
が存在し、そのパターンに則って文書を記述・構成することで読者にとって分かりやすい文
書を容易に作成できるとされる [Moriarty00]。本研究における設計文書モデリングにおいて
も、各設計文書固有の記述パターンの存在を仮定することで比較的容易に設計文書を管理す
ることが可能であると考えられる。そこで本節では設計文書における記述のパターンについ
て考察を行う。
51
本研究では設計文書の記述パターンを 2 つに分類する。ひとつは文書内容の見出しを明示
する各項目である。例えば学術論文では「序論」「関連研究」「研究のアプローチ」「考察」
「結論」、特許文書では「発明に関する技術分野」「従来の技術」「発明によって解決される
課題」などの項目がこれに該当する。もう一つは、この各項目内で展開される論理的記述の
パターンである。例えば論文の「序論」や特許申請書の「従来の技術」では従来の関連研究
における課題を列挙し、各課題を整理するように記述が進行し、
「研究のアプローチ」では、
整理した課題に対して解を提示する方向で記述が進行すると考えられる。本研究では前者を
マクロレベルの記述パターンと呼び、後者をミクロレベルの記述パターン、あるいは単に記
述パターンと呼ぶ。
本研究ではミクロレベルの記述パターンを 3.1.2 節で述べた知識操作に基づき、記述の主
題となっている情報およびその情報に対して行われる操作の組により図 3.6 に示すように記
述する。
ミクロレベル記述パターン::=記述の主題, 操作, 操作*
記述の主題::=外部情報|内部情報|要求仕様記述|設計対象記述|設計対象関連
情報|設計知識|人工物
操作::=知識操作|基本語彙
図 3.6: ミクロレベル記述パターンの BNF 表記
例えば「要求仕様記述, 解のシンセシス, 解の分析」という記述パターンは、要求仕様に対
して提示された設計解およびその分析についての記述を表すものである。なお、記述パター
ンの抽象度に応じて、知識操作および基本語彙を操作として利用することができるので、こ
の記述パターンは「要求仕様記述, 改良, 実験」や「要求仕様記述, 提案, 評価」など、より具
体的な記述パターンを内包するものである。
ミクロレベルの記述パターンは実際の時系列的な思考過程に沿うものと、この時系列情報
を並べ替え、情報間の論理的な関係を理解するための思考に沿うように加工されたものが存
在する。ミクロレベルおよびマクロレベルの記述パターンにより表現される目的別の文書の
形態を文書テンプレートと呼ぶ。文書テンプレートに基づいて記述される情報を並び替えた
ものを文書モデルと呼ぶ。文書テンプレートと文書モデルとの関係は、オブジェクト指向プ
ログラミング言語におけるクラスとインスタンスの関係である。文書モデルはその文書に記
述される思考のプロセスを表現したものである。表 3.1 に特許申請書のマクロレベル記述パターンの一部を示す。特許申請書の記述には「発
52
明の属する技術分野」、
「従来の技術」等の項目があることを示している。また表 3.2 にメタ
プロセスモデルの思考パターンと特許申請書における記述パターンの対応関係の例を示す。
この対応関係では、設計対象記述を分析しその問題点を指摘する思考パターンが、特許申請
書の「従来の技術」の項目では、詳細な分析過程を省いて設計対象記述から直接その問題点
を指摘する記述パターンに変換され、一方で「発明の評価」の項目では詳細な分析過程を省
かずに元の思考パターンの内容を記述されることを示している。このように、メタプロセス
モデルにおけるある思考パターンが、文書モデルではマクロレベル記述パターンの各項目に
おいて異なる記述パターンに対応することがある。
表 3.1: 特許申請書のマクロレベル記述パターン
記述順
1
2
3
4
5
6
7
項目
発明の属する技術分野
従来の技術
発明が解決しようとする課題
課題を解決するための手段
本発明の説明
実施例
発明の効果 (評価)
表 3.2: 思考パターンと記述パターンの対応関係
3.2.3
思考パターン
設計対象記述, 解の分析*, 問題点指摘
特許申請書における
記述パターン (従来の技術)
設計対象記述, 問題点指摘
特許申請書における
記述パターン (発明の評価)
設計対象記述, 解の分析*, 問題点指摘
設計文書生成のプロセス
メタプロセスモデルは設計過程における設計者の思考パターンを網羅的に記述したもので
あり、これから文書を生成するにはメタプロセスモデルにおける情報を取捨選択し、また変
換することにより、各文書モデルにおける情報との対応関係を取る。文書モデル生成のため
53
に、3.2.1 節で述べたメタプロセスモデルにおける思考パターンと文書モデルにおける記述
パターンを関連付けた変換辞書、および文書内における記述パターンの並びを表すマクロレ
ベルの記述パターンを、文書テンプレートとして文書種ごとに用意しておく。これによりメ
タプロセスモデルにおける思考パターンの一部を文書モデルにおける記述パターンに変換
し、それら記述パターンがマクロレベルの記述パターンに応じた順序で並び替えられ、文書
モデルが生成されることになる。
その後に文書モデルにおける記述パターンを自然言語の記述に変換することで文書が最終
的に出力される。
ところで、メタプロセスモデルは設計過程において操作された情報を記述したものであ
り、設計文書も基本的にはこれらの情報を元に作成されると考えられるが、設計文書を作成
する際に新たに追加される情報も考えられる。例えば、特許申請書や学術論文を作成する際
には、行った設計との比較のため関連研究に関する記述が行われるが、こうした調査は必ず
しも設計過程で行われているとは言いがたい。しかし設計作業の範囲を広く解釈すれば、こ
うした調査も設計作業の一部と言える。つまり、何らかの目的を持った設計文書を記述する
際に新たに利用される情報もメタプロセスモデルに含まれるべきである。図 3.7 に示すよう
に文書生成を行うに伴って、メタプロセスモデル自体も情報量が増え、進化していくものと
考えられる。メタプロセスモデルが進化することによって共有・再利用すべき情報の量を増
やせると考えられる。
メタプロセスモデル
設計文書のインスタンス
追加された設計情報
設計文書の生成
設計文書の生成に利用される設計情報
メタプロセスへの設計情報の追加
メタプロセスの進化
図 3.7: メタプロセスモデルの進化
54
設計文書における思考過程の分析
3.3
本章で述べた設計文書についての理論を確かめるために、実際の設計で記述された設計文
書を分析した。
3.3.1
分析対象とその収集
本研究では、大学院研究室で 5 年間にわたって行われた光造型機の設計事例 [Kamimura00]
に関する研究会報告書、週報、学位論文、および特許申請書を収集した。これらの文書は同
一の設計事例に対して異なる観点から作成されたものであり、図 3.4 上に示した文書生成プ
ロセスを考える上で適切な事例と判断した。
本研究ではメタプロセスモデル作成のため週報、研究会報告書を利用することとした。本
来メタプロセスモデルとしては設計者の思考過程を網羅的に記述したものであることが望ま
しい。しかしながら、現実問題としてそのような資料を入手するのは困難である。週報・研
究会報告書は、厳密な意味で設計者の思考過程を網羅したものではないが、研究の進捗状況
が把握できるためメタプロセスとして扱っても差し支えないと判断した。
3.3.2
分析方法
次に収集した資料の分析方法について述べる。
3.2.2 節で述べたように研究会資料・報告書を情報導出、および情報導出を意味付けるた
めの知識操作によってコーディングし、メタプロセスモデルを作成する。この手順を図 3.8
に示す。
1. まず図 3.2 に示した設計の基本語彙を用いて文書の記述を切り分ける。
2. 次に、図 3.2 に示した基本語彙と情報の導出関係との対応表により、各基本語彙に対応
する情報導出を明示化する。
3. 最後に各基本語彙を知識操作に抽象化する。
以上の手順によりメタプロセスモデルを得る。
分析した文書のうち、実験に利用した部分を図 3.9 に示す。また図 3.10 に知識操作でコー
ディングしたメタプロセスモデルを示す。なお、図中の情報導出において示された記号は
3.1.2 節で分類された設計情報タイプの略記号であり、その意味は表 3.3 に示す通りである。
55
1. 基本語彙による記述の切り分け
2. 情報導出の明示化
3. 知識操作への抽象化
設計文書
提案
R
試作
解のシンセシス
D1
解の分析
A
実験
導出
解の分析
D2
D2
図 3.8: メタプロセスモデル作成手順
表 3.3: 設計情報タイプの略記号
記号
設計情報タイプ
E
I
R
D1
D2
K
A
外部情報
内部情報
要求仕様記述
設計対象記述
設計対象関連情報
設計知識
人工物
56
解の分析
3.3.3
文書生成実験
メタプロセスモデルは設計における設計者の思考過程を記述したものであるから、設計で
考慮された様々な情報を含んでいる。実験では例として、このメタプロセスモデルから樹脂
の凍結方法についての報告書を生成する事にした。ここでこの報告書の文書テンプレート
において、ミクロレベルの記述パターンを「要求仕様記述 (樹脂を凍結する), 解のシンセシ
ス, 解の分析*」とした。さらに、この記述パターンに対応するメタプロセスモデルの思考パ
ターンを「要求仕様記述 (樹脂を凍結する), 解のシンセシス, 解の分析*」とした。この対応
関係により、メタプロセスモデルの中から要求仕様記述「樹脂を凍結する」に関して解のシ
ンセシスを行い、さらに解の分析を行う知識操作に対応する記述を抽出し、記述の変更無し
に報告書における文書モデルに加える。要求仕様記述「樹脂を凍結する」に関連しない他の
設計情報は文書モデルに加えられないため、必要な情報だけを記述した要約文書が得られる
ことになる。
実験の被験者を、冨山研究室に在籍する修士課程 1 年の学生に依頼した。学生にメタプロ
セスモデルのデータと報告書の文書テンプレートを与え、3.2.3 節で述べた文書生成のプロ
セスを理解させて、報告書を生成するよう指示した。
図 3.11 が生成した文書である。要求仕様記述 (樹脂を凍結する) に関する記述のみが抽出
され、樹脂を凍結する方法についての検討を記述した報告書が生成された。
この実験により、メタプロセスモデルにおいて文書モデルの記述パターンにマッチする部
分 (図 3.10 において下線を付した部分) が抽出され、本章で提案した文書モデルで報告書を
作成することが可能であることが分かった。
一方、文書作成に当たってドライアイスが樹脂を凍結するためのものであること、などの
追加した情報もあった (図 3.10 において※印が付された部分)。これは報告書を作成する際
に、報告書の記述パターンを利用して必用な情報が追加され、メタプロセスモデルが進化し
たものと考えることができる。
57
1995年度冷却凝固式光造形法に関する研究のまとめ
まず、ドライアイスを用いて積層の実験を行った。実験は、ドライアイス上にアルミ板を
置き、その上に樹脂を伸ばし、マスクした紫外線を照射し、樹脂を垂らすということを厚さ
1.5cmまで続けた。光硬化樹脂は熱伝導性が悪く、これ以上層が厚くなると樹脂の凍結に時
間がかかり実用的でなくなる。下から冷やす限り、ドライアイスもペルチェ素子も同じ効果
となる。そこで、上部から冷却ガスを吹きかけるか、全体を冷却するという方法にする。樹
脂面の平坦化について、テフロン膜を介して上から平面に押さえつけ、剥すという方法があ
る。だめなら、ピストンのようなもので空気を介して圧縮し平面を出すという方法もある。
孤立の場合に関して、サポートがいらないことが確認できた。
次に冷却方法としてペルチェ素子を用いた。ペルチェ素子の熱面温度を一定に保つ水冷装
置と樹脂を積層するための装置を製作した。水冷装置により冷面温度を一定に保つことがで
きた。積層実験を行ったが、ペルチェ素子の熱容量が低いため凍結まで時間がかかった。樹
脂の粘性が低い場合、へらで均すことは表面張力の影響で無理だとわかった。テフロン膜で
平面を押し付ける方法は、樹脂内部の構造を破壊しないため完全凍結させる必要がある。樹
脂の冷却方法として低温恒温槽を用いることにした。熱容量は樹脂を凍結させるには十分で
ある。
非接触式の樹脂冷却方法は、より大きな冷却能力が必要で、表面張力により平坦化できな
い。接触式では平面規制も同時にできる。そこで接触式を採用した。接触式冷却法に関し
て、樹脂の凝固点を調べ、それを目安に低温恒温槽を用い冷却装置を試作した。冷却装置表
面に霜がつくことがわかったのでシリカゲルで乾燥させた空気を当てるようにした。
そこで実際に、実験により孤立部分やオーバーハング部分の形状の造形実験を行った。樹
脂をしたからも冷却できるように積層していく台の周りに冷却液を循環させた。マスクは造
形物の断面形状を描いたものを何枚か用意し、それを通して紫外線を照射し一層ずつ造形し
た。結果ほぼ目的形状が得られた。しかし、孤立部分が外側へ広がる、上平面が歪んでい
る、下に固化部分がないところは固化層が厚くなる、といった問題が得られた。また紫外線
ランプが発する熱をうまく放熱することも重要である。
ところで、これまで樹脂を完全に冷却凝固させるためには、約-20℃まで冷却する必要が
あった。この温度に保つのは困難で、霜の影響もあることから、常温で固体の樹脂を用いる
こととした。この樹脂を用いて実験を行ったところ、かなり目的形状に近いものが造形でき
た。しかし、孤立部分が外側に広がってしまうのは、完全には解消されなかった。これは樹
脂層を十分冷却できれば解消できると考えられる。
図 3.9: 分析対象となった文書
58
文書の記述
基本語彙
知識操作
提案
解のシンセシス
試作
まず、ドライアイスを用いて積層の実験を行った。実験
は、ドライアイス上にアルミ板を置き、その上に樹脂を伸ば
し、マスクした紫外線を照射し、樹脂を垂らすということを
厚さ1.5cmまで続けた。
情報の導出関係
参照：R(樹脂を凍結する）、追加：D1（ドライアイスを用いた冷
却装置）
※
解の分析
参照：D1（ドライアイスを用いた冷却装置）、追加：A（ドライア
イスを用いた冷却装置）
※
実験
解の分析
参照：A(ドライアイスを用いた冷却装置)、追加：I(実験方法：ドラ
イアイス上にアルミ板を置き、その上に樹脂を伸ばし、マスクした
紫外線を照射し、樹脂を垂らすということを厚さ1.5cmまで続け
た)、追加：D2(実験結果)
※
光硬化樹脂は熱伝導性が悪く、これ以上層が厚くなると樹脂
の凍結に時間がかかり
導出
解の分析
参照：D2(樹脂の熱伝導性が悪い)、追加：D2（樹脂の凍結時間が
長くなる）
※
実用的でなくなる。
評価
解の分析
追加・参照：R（実用性）、参照：D2（樹脂の凍結時間が長くな
る）、追加：I（実用的で無い）
※
問題点指摘
知識・情報の再
構成
参照：D2（樹脂の凍結時間が長くなる）、参照：I（実用的でな
い）、追加：R（樹脂の凍結時間を短くする）
提案
解のシンセシス
参照：R（樹脂を凍結する）、追加：D1（ぺルチェ素子を用いた方
法）
※
導出
解の分析
参照：D1(ペルチェ素子を用いた方法)、追加：D2(樹脂の凍結時間
が長い) ※
問題点指摘
知識・情報の再
構成
参照：D2(樹脂の凍結時間が長い)、追加：R(樹脂を下から冷却しな
い)
提案
解のシンセシス
参照：R（樹脂を下から冷却しない）・R(樹脂の凍結時間を短くす
る)、追加：D1(上部から冷却ガスを吹きかける方法)/D1（全体を冷
却する方法）
樹脂面の平坦化について、テフロン膜を介して上から平面に
押さえつけ、剥すという方法がある。
提案
解のシンセシス
追加・参照：R(樹脂面を平板化する)、追加：D1(テフロン膜を使う
方法)
だめなら、ピストンのようなもので空気を介して圧縮し平面
を出すという方法もある。
提案
解のシンセシス
参照：R(樹脂面を平板化する)、追加：D1(空気で圧縮する方法)
確認
情報の確認
追加・参照：R(孤立部のサポートをしない)、参照：D2（実験結
果）、追加：D２（孤立部のサポート不要）
下から冷やす限り、ドライアイスもペルチェ素子も同じ効果
となる。
そこで、上部から冷却ガスを吹きかけるか、全体を冷却する
という方法にする。
孤立の場合に関して、サポートがいらないことが確認でき
た。
図 3.10: メタプロセスモデルと報告書の文書モデル (一部)
樹脂を凍結するために、まずドライアイスを用いて積槽の実験を行った。実験は、ドライ
アイス上にアルミ板を起き、その上に樹脂を伸ばし、マスクした紫外線を照射し、樹脂を
垂らすということを厚さ1.5cmまで続けた。光硬化樹脂は熱伝導性が悪く、これ以上層が厚
くなると樹脂の凍結に時間がかかり実用的でなくなる。下から冷やす限り、ドライアイス
もペルチェ素子も同じ効果となる。樹脂の冷却方法として低温恒温槽を用いることとし
た。熱容量は樹脂を凍結させるには十分である。非接触式の樹脂冷却方法は、より大きな
冷却能力が必要で、表面張力により平坦化できない。接触式では平面規制も同時にでき
る。そこで接触式を採用した。樹脂を下からも冷却できるように積槽していく台の周りに
冷却液を循環させた。
図 3.11: 生成された文書
59
3.4
まとめ
本章では設計文書に関して本研究で提案する理論について説明し、設計文書に記述する内
容およびその作成方法についてモデル化した。またその理論を検証するために行った実験に
より以下の点が分かった。
• 設計文書を知識操作によりコーディングすることができた。
• 設計文書には記述パターンが存在することを確認した。
• メタプロセスモデルの情報から設計文書を生成することが可能であることが分かった。
今回の実験では報告書の生成を通じて本研究で提案する設計文書理論の妥当性を検証し
たが、特許申請書や学位論文なども同様の手法により生成できるかどうか検討を加えること
で、より検証の精度が向上すると思われる。
一方メタプロセスモデルは文書作成に伴って進化していくものであるが、設計過程を可能
な限り網羅的に記述したメタプロセスモデルを文書生成の前段階としてどのようにして作成
するかが問題である。次章でその方法論について述べる。
60
第 4 章設計過程における知識の獲得
本章では 3 章で述べたメタプロセスモデルを中心とする設計文書理論に基づいて設計過程
を獲得する際の課題を整理し、本研究が採用する手法について述べる。
この手法の基本的なアイデアは、設計者に大きな負担をかける事なく設計情報の欠落無し
に設計文書化を容易に行うために、設計の副産物として設計過程を記述した設計文書および
設計文書をコーディングするメタプロセスモデルを作成することである。その実現方法につ
いて以下に詳しく述べる。
このアプローチを用いることにより、3 章で述べたメタプロセスモデルを作成することが
可能となる。
62
4.1
設計過程獲得の課題
本節では、設計過程を獲得する際の課題について述べる。
4.1.1
設計作業による設計過程獲得
図 4.1 に示すのは、ある建設会社において、高層建築物を建設する際に設計者と地盤の専
門家との間に交された会話を記録したものである。
この事例における設計者は、地盤の挙動に詳しくないため、地盤の専門家にアドバイスを
求めている。その結果、地盤の調査データから判断して地震時に地盤が液状化し建築物に損
害を与える可能性が高いこと、そのための対策として杭基礎の補強や地盤の改良工事を行う
必要があることなどを知識として得ている。
こうした地盤の調査データや調査データに対する専門家の意見、あるいは対策として挙げ
られたいくつかの解候補などの情報は設計を進める上で重要な役割を果たしているが、設計
対象を直接表現する情報ではないために図面や文書として記録されにくい。
通信手段として電子メールやファックスなどを使用した場合には、交換された情報を記録
として残すことも可能である。しかし、そうした通信手段を使用せずに交された会話の中で
交換された情報を、設計が終了した時点以後のインタビューなどで追跡することなどは不可
能ではないにしても、記憶に不確かな点があるなど情報獲得の手段としては確実とは言えな
い。また、実際の設計の際には、設計対象の大まかなイメージや簡単な計算式などをメモ書
きのような形で記述する場合も多い。こうしたメモを設計後に全て収集することは一般には
困難である。
このように、設計の背景情報を含んだ設計過程は設計後では獲得が困難であるが、設計作
業を進める途上には確かに存在する情報である。そこで、本研究では設計作業中に獲得・生
成される情報を可能な限りその場で獲得することを考える。
4.1.2
統合的設計支援環境の必要性
4.1.1 節で述べたように設計作業と同時に設計過程の獲得を考える場合、設計の本来の目
的ではない文書作成作業をいかに負担なく設計者が行えるかが一つのポイントになると考え
られる。しかし設計過程の獲得は単に作業負担だけの問題ではない。それは設計において用
いられる情報は多種多様でそれらを統合的に扱う枠組みが現状では欠けているために、十分
63
設計…本事例の担当設計者研究…土壌解析の研究者
設計重要な建築物のため高層評定にかける必要があり、最新の技術的検討をしたい。杭基礎支持を考えているが
（基礎の計画図を提示）、液状化に対する安全性評価がよくわからない。どのようにしてやればいいか教え
て欲しい。
研究まず第一に液状化に対する検討の必要があるかどうかが重要である。地盤に関連した評価は、医者の診断と
同じで、まず個別の地盤の状態を評価しないと、どのような問題点があり、どのような検討を行えば良いの
か分からない。まず地盤調査の結果を見せて欲しい。
設計地盤調査のデータとして何が必要なのか。
研究以下の物が欲しい。敷地地盤の推定断面、敷地図、表層地層図、ボーリング柱状図、主要な地盤のくり返し
変形試験、粒度分布、最大・細小密度、地盤の密度などである。
設計表層地層図、繰り返し変形試験、最大・最小密度はない。（地盤調査結果を提示）
研究（調査結果を概観して）常識的に考えて液状化の可能性は高いと思う。まず第一に、杭基礎で設計するな
ら、埋立地層部分の地盤改良を行わないとだめでしょう。
設計地盤改良の方法は？
研究液状化に対する対策工法としては、サンドコンパクションパイル（SCP）工法、バイブロフローテーション
工法、バイブロロッド工法、グラベルドレイン工法、地下水位低下工法、動圧密工法、プレッシャーバック
ル工法、ALPSなどがあるけれど、今回の場合はSCPがいいでしょう。なぜいいのかというと、この場所は騒
音、振動を気にしなくて良いし、コストが安いし、実績もあるから。
設計地盤の液状化の解析を行った結果、こんなふうになりました。地盤の変位が40cmも出ているが、これは妥当
でしょうか？
研究（結果を見て、解が発散していることがわかる。これを防ぐには時分割を細かくとれば良いが、それ以前の
問題がありそうである。）液状化解析のパラメータを見てみると、液状化対象層の相対密度を30%としてい
る。このため、変形が異常に大きく出ている。通常の地盤では、相対密度が50%以下ということはまず考え
られない。ここでパラメータとして用いている相対密度はどのようにして求めたのか。
設計標準貫入試験のN値から、換算式（マイヤホッフの提案式）で換算して求めた。
研究それも一つの方法だが、細粒分を多く含むとこの方法は誤差が多い。第一、常識的に考えて、相対密度が30
%以下の地盤なんてあるわけないだろう。しいていえば、現在河口で堆積している最中の中洲くらいしか考
えられない。通常は、軟弱な埋立地盤といえど相対密度は60%くらいである。東京都の地質調査官のA氏の博
士論文に、東京都の埋立地盤の相対密度の記述があったと思うが？（調べてみると、東京湾の埋立地の相対
密度は50%∼60%くらいであることがわかる。）埋立地盤のしたの沖積低地（有楽町層）は、堆積年が1000年
くらいとして、堆積年と堆積環境（海成砂）から考えて、相対密度の関係から65%くらいとみなせば良いだ
ろう。
設計他のパラメータで何か問題はありますか？初期の減衰はいくらにすれば良いですか？
研究初期減衰は、本来は必要無いはずだが、解析を安定させるために1%くらい入れておいた方が良さそうであ
る。その他、注意事項については、考え方をまとめたメモがあるので読んで下さい。
図 4.1: 設計者と専門家との会話の記録 (抜粋)
64
な情報が獲得できないことが考えられるのである。
1.2.3 節で紹介した Crabtree の研究でも述べられているように、一般に設計作業には様々
な種類の作業が含まれている。たとえば作図作業に限って見ても、アイデアの詳細化のため
の簡単なラフスケッチから、詳細な幾何情報を生成するための製図作業まで様々である。一
般に、設計作業はその時点での設計情報の詳細度のレベルによって次の 4 段階に分類できる
とされている [Tomiyama85]。
• 概念設計
方針設計、基本計画立案や機能設計と呼ばれるものを含み、設計解の基本方式や構造
を決定する。
• 基本設計
設計解の全体の配置や構造を決定し、計画図あるいは組立図を作成する。
• 詳細設計
設計解を構成する部品の詳細な諸元を決定し、部品図を作成する。
• 生産設計
部品製作のためのデータ（NC データ、加工・組立・検査・手順指示書など）を作成
する。
設計作業と同時に設計過程の獲得を考える場合、こうした全てのレベルの設計作業を記録
する必要がある。なぜならば、設計の当事者は重要ではないと思って記録しなかった設計初
期の情報が、別の設計者にとっては必要な情報であり得るからである。
そのためある設計作業を行うための計算機ツールが無いために、その設計作業に関する設
計情報が記録として残らない事態をさけるために、設計者が計算機上で滞り無く設計作業を
行うための各種ツールを統合した支援環境を実現することが必要である。設計中に設計過程
の獲得を行うためには、このような統合的設計支援環境の実現が前提となり、かつそこでの
設計作業を可能な限り記録するためにその統合インターフェースを開発する必要がある。
また各種計算機ツールで利用される多種多様な情報を柔軟に取り扱う枠組みも必要である
と考えられる。
65
4.1.3
まとめ
本節では設計過程獲得のために、
• 設計作業と同時に設計文書を作成すること
• 設計文書作成ツールと統合設計支援環境を統合することが必要であること
• 各種計算機ツールで利用される多種多様な情報を柔軟に取り扱う枠組みが必要なこと
を述べた。次節以降で、これらの問題を解決するために本研究で提案する具体的な方法論
について述べる。
66
4.2
統合設計支援環境との統合
様々な計算機ツールを用いて進行する設計過程を獲得するためには、統合設計支援環境と
設計文書作成システムの統合が必要でる。そこで本研究では、2.3 節で述べた KIEF を統合
設計支援環境として利用することを考える。
具体的には、設計作業に必要なモデラをプラガブル・メタモデル機構に組み込むことで統
合設計支援環境の実現を行う。本研究で接続するモデラについては 6.1.3 節で述べる。
さらに、KIEF における統合インターフェースとしての設計文書作成システムを実現する。
図 4.2 が本研究で実装したシステムである。基本的にこのシステムは自由に文書を編集でき
る設計文書エディタ (図 4.2 左側のウインドウ) であるが、設計者はこのエディタを通して、
KIEF に接続された様々モデラを用いることができる。また、KIEF の統合インターフェー
スとして実現するので KIEF 上で作業を行いながら、コメントを記述するなどして可能な限
りの設計作業を設計文書として記録することができる。図 4.2 右側のウインドウが、KIEF
のコンソールである。
本章でこれから述べる各機能は、全て設計文書作成システムの機能として実装されるもの
である。
図 4.2: 本研究で実装したシステム
67
知識操作に基づく文書の自動生成
4.3
先に述べたように設計知識獲得を困難にしている原因は背景情報と非明示的に行われる思
考過程の存在である。
この問題の最も効果的な解決策は、設計者の中で進行している思考過程の全てを観察し記
録することであろう。しかし残念ながらこのアプローチの実現は難しいと言わざるをえない。
本研究で統合設計支援環境として用いる KIEF はメタモデルを中心モデルとして種々の設
計対象モデルを統合するものである。さらにシンセシスのモデルに基づく推論フレームワー
クにより、KIEF における設計過程をメタモデルへの操作に基づいた知識操作としてコーディ
ングし記録することができる。そこで KIEF における知識操作を記録することで情報の欠落
の無い設計過程の獲得を実現することを目指す。これは本研究で文書作成支援を行うために
KIEF を利用するもう一つの理由である。
4.3.1
メタプロセスモデルにおける設計情報と KIEF の概念との対応付け
3.1.2 節で述べたようにメタプロセスモデルは 7 種に分類された設計情報に対する知識操
作としてコーディングされている。KIEF 上の操作からメタプロセスモデルを構築するにあ
たって、まず 2.3 節で述べた KIEF に蓄積されている概念とメタプロセスモデルにおける設
計情報との対応関係を取っておく必要がある。本研究ではこの対応関係を表 4.1 に示すよう
に取る。
4.3.2
KIEF のログから情報の導出関係の生成
KIEF における設計作業から情報の導出関係の生成するために 2.4.2 節で述べたシンセシ
ス推論フレームワークの各設計過程知識が生成するログの情報を元に情報導出関係を生成す
ることによってメタプロセスモデルを生成する。この手順を図 4.3 に示す。
1. まずシンセシス推論フレームワークのログ L1 (dp1 ), L2 (dp2 ), . . . , Ln (dpn ), . . . に対し、
情報導出へ変換するためのルールを適用して、基本語彙に対応するログのチャンク
l11 , l12 , . . . , l21 , l22 , . . . , lnm , . . . に切り分ける。ここで Ln (dpn ) は設計過程知識 dpn に
よって生成されたログ、lnm は Ln (dpn ) から切り分けられた m 番目のチャンクを意味
する。
68
表 4.1: KIEF の概念とメタプロセスモデルの設計情報
KIEF における概念・情報
実体
関係
属性
物理現象
フィジカルフィーチャー
機能
属性的要求仕様
設計対象モデラ
試作機
その他の情報
(図表、Web ページのリンク先等)
メタプロセスモデルの情報タイプ
設計対象記述
設計対象記述
設計対象記述
設計対象関連情報
設計対象記述
要求仕様記述
要求仕様記述
設計知識
人工物
外部情報
2. 次に基本語彙に対応するログのチャンクの情報導出 I11 , I12 , . . . , I21 , I22 , . . . , Inm , . . . を
生成する。ここで Inm は lnm から生成された情報導出である。
3. 最後に、各情報導出に対応する知識操作 KO11 , KO12 , . . . , KO21 , KO22 , . . . , KOnm , . . .
を明示化することによりメタプロセスモデルが生成される。KOnm は Inm に対応する
知識操作である。
1. 基本語彙によるログの切り分け
2. 情報導出の明示化
提案
試作
3. 知識操作への抽象化
R
解のシンセシス
D1
解の分析
A
実験
導出
シンセシス推論フレームワークのログ
解の分析
D2
D2
ログ解析知識
図 4.3: メタプロセスモデル生成手順
69
解の分析
ここで情報導出生成のために利用するルールは図 4.4 に示すように、シンセシス推論フ
レームワークの設計過程知識が生成するログと情報導出関係および基本語彙、知識操作との
対応を記述したものである。情報導出の生成によりメタプロセスモデルが生成される。
付録に情報導出生成ルールの一覧を付す。なお、設計過程知識と基本語彙および知識操作
は一般に 1 対多対応となる。
行為 Set specification によって生成されるログ
(setq RelatedModelers (relatedModelers:type: () requirement))
；要求仕様に関連する推論システムの提示
(setq SelectedModeler (selectOneFrom:message: RelatedModelers
’select one modeler for requirement.’) ) ；設計者が推論システムを一つ選択
(setq NewModeler (makeModelerOn: (SelectedModeler)))
；設計者が選択した推論システムでモデルを構築
(setq NewRequirements (getModelerInformation: (NewModeler )))
；モデルに付加された情報から要求仕様(NewRequirements)を抽出
(addInformation: (NewRequirements)))
；記述された要求仕様を設計情報に追加
ログ中の設計情報から生成される
情報導出
基本語彙：問題点指摘
知識操作：知識・情報の獲得
情報導出：
参照：追加：NewRequirements
各変数の意味
RelatedModelers: 要求仕様に関連する推論システム
SelectedModeler: 設計者が選択した推論システム
NewModeler: モデルを構築中の推論システム
NewRequirements: 要求仕様
図 4.4: 情報導出生成ルール
4.3.3
自然言語への変換
次に生成された情報導出関係を文書上の自然言語の記述に変換するためのルールを用意す
る。変換ルールは各基本語彙ごとに用意され、基本語彙に対応する情報導出に関して自然言
語でその説明を記述したものである。本論文の付録 A に、全ての変換ルールを掲載する。
設計文書作成システムを介して KIEF で操作を行う度にこの変換ルールによって自動的に
現在作成中の設計文書にその内容を記述することにより、KIEF の設計作業を自動的に文書
化できる。ただし本研究における本来の目的は設計者が持っている背景知識や設計者が考え
ている設計根拠を獲得することであるので、設計者を妨げることなく設計者がいつでも文書
に記述できる自由度は保つべきであり、そのためには本研究で開発する設計文書作成システ
ムはワードプロセッサとしての機能を持つ必要がある。その上で設計作業を逐一自動的に記
録することによって設計者にかかる文書化作業の負担を軽減し、その分設計者が自らの知識
を文書に記述することを促すことが可能であると考えられる。
70
ハイパーテキストによる設計文書の記述
4.4
3.1.2 節で述べたように本研究では設計過程を表現する枠組みとして情報導出関係に基づ
くメタプロセスモデルの導入を提案するが、本節ではメタプロセスモデルに表現される設計
過程をハイパーテキストの設計文書として記述する枠組みについて議論する。この枠組みに
より作成されるハイパーテキスト設計文書はメタプロセスモデルのブラウザとして機能する
ことになる。
4.4.1
設計過程の記述
3.1.2 節で述べたように実際の設計作業における設計過程は一般に試行錯誤の過程である。
つまり設計者は要求仕様から設計解を直接導出するのではなく複数の設計解候補の間で試行
錯誤を繰り返したり、途中で元の段階へ後戻りしたりすることが指摘されている。他者がそ
の設計根拠を理解するためには、途中の試行錯誤過程も含めて記述されていることが望まし
い。このため、設計過程を記述する枠組においては試行錯誤過程を扱う事を考慮しなければ
ならない。
設計根拠の研究グループの間では、ハイパーテキスト技術を用いて設計過程の論理的依存
関係を記述することが一般に受け入れられている (例えば，[ShipmanIII97])。3.1.2 節で述
べた情報導出によってこうした試行錯誤過程を表現することが可能であるが、文書上で明確
に表現するために本研究でもハイパーテキストを採用することとする。
本研究では設計過程を表現する枠組みとしてメタプロセスモデルを導入したが、このメタ
プロセスモデルの情報を、ハイパーテキストによって設計文書上でどのように記述するかを
考える必要がある。そこで図 4.5 に示すように、ハイパーテキストによる記述とメタプロセ
スモデルとの対応関係を付けることとする。以下の各節で詳細を述べるが、ここで考慮する
のは次の 2 点である。
1. メタプロセスモデルの知識操作および基本語彙に対応する記述を、ハイパーリンクされ
る文書チャンクとし、これをセクションと呼ぶ。この記述の内容は 4.3 節で述べた手法
によって KIEF 上での設計作業に基づいて自動的に生成されるものであるが、設計者が
適宜コメントなどを書き加えることもできる。
2. セクション間のハイパーリンクはメタプロセスモデルの情報導出関係に基づいて設定さ
れる。また作業中に参照された図表や構築されたモデルなどはセクション上にハイパー
71
地盤の断面図
ハイパーテキスト
による記述
地盤データ
地下水位: -20m
.........
設計過程に
関する情報
（メタプロセス
モデル）
セクション
ハイパーリンク
1. 埋込型.
建物の要求仕様
この地盤へ建築する建物は
商用である.
.........
建物の基礎構造に関して
検討する.
この地盤は液状化
の恐れがある....
参照した図表・モデル
提案
情報獲得
E
設計対象に関する
情報
（メタモデル、各
モデル）
知識操作
基本語彙
解の分析
D2
D1
具体化
問題点指摘
D1
2. 埋込杭型.
R
R
提案
D1
情報導出
設計対象の情報
KIEFにおける操作
・モデラ操作
・モデル操作
・論理操作
図 4.5: ハイパーテキストによる設計過程記述
リンクされる。
4.4.2
セクションの導入
3.1.2 節で述べた知識操作および基本語彙で記述された設計過程をハイパーテキストで表
現するために、文書上の記述で一つの知識操作および基本語彙に対応する部分をハイパーリ
ンクされる文書チャンクとし、これをセクションと呼ぶ。一つのセクションのデータ構造を
次のように定める。
• セクション番号
文書の章立ての構造に基づいて自動的に与えられる番号である。
• セクション ID
作成された順番に基づいて自動的に与えられる番号である。内部的に保持される情報
であり、文書上には現れない。
• タイトル
セクションのタイトルである。ユーザが記述する。
72
• 知識操作
セクションに対応する設計作業に対して与えられた知識操作の名前である。
• 基本語彙
セクションに対応する設計作業に対して与えられた基本語彙の名前である。
• 情報導出
セクションに対応する設計作業における情報導出の記録である。導出先および導出元
の設計情報とともに記録される。
• シンセシス推論フレームワークのログ
セクションに対応する設計作業においてシンセシス推論フレームワークによって生成
されたログである。このログをシンセシス推論フレームワークへ入力することにより、
文書に記録した設計作業を再実行させることが可能となる。
• 本文
設計作業に対応する自然言語の記述である。4.3 節で述べたように KIEF の作業と同
時に自動的に記述されるだけでなく、ユーザが自由にコメントなどを記述することも
可能である。また 4.4.4 節で述べるように、参照された図表や構築されたモデルなど
がセクションの本文中にハイパーリンクされる。
• セクション間の接続関係
情報導出に基づいて記述されるセクション間の接続関係である。
図 4.6 にセクションに記述された内容の例を示す。
4.4.3
設計過程管理グラフ
設計過程をハイパーテキストで表現するために、セクションをノード、セクション間の接
続関係をアークとする有向グラフを考え、これを設計過程管理グラフと呼ぶ (図 4.7 参照)。
設計過程管理グラフにおいては、情報導出で記述される設計過程の特徴をふまえ、一つの
セクションから複数のセクションへの派生、および複数のセクションから一つのセクション
への統合といった構造を許す。
73
セクション番号
本文
セクション終了記号
モデルへのリンク
参照した情報へのリンク
図 4.6: セクションの例
図 4.7: 設計過程管理グラフ
74
図 4.8: 設計過程管理グラフの表示モード
セクション間の論理的な接続関係はメタプロセスモデルにおける情報導出に基づいてシス
テムが自動的に接続を行うことができる。例えば、あるセクションで発生した問題を解決す
るためにユーザがシステムを用いて解候補を検索し複数の解候補が提示された場合を考え
る。この時、各々の解候補の評価は並列して行われるので、提示された各情報に対して元の
セクションから派生する子セクションを作成し、子セクションの中にシステムが情報を記述
することとする。また、後述する文書知識を用いて計算機が自動的に接続関係を設定する場
合もある。
設計過程管理グラフはメタプロセスモデルのブラウザとして機能するものであるので、本
研究ではユーザの利便性を考慮し次の 2 つの表示モードを用意する。
時系列表示モードセクション ID に基づき、設計作業の時系列順にセクションを並び替えて
表示するモードである。グラフ構造は直列となる (図 4.8 上)。
論理関係表示モード情報の導出関係に基づき、設計作業の論理的関係を表示するモードで
ある。グラフ構造は並列および直列が並存したものとなる (図 4.8 下)。
75
4.4.4
多様な情報の記述
ハイパーテキストによって試行錯誤の過程を表現できるだけでなく、ハイパーリンク機能
により設計過程で参照される多様な種類のメディア情報や対応する設計行為において構築さ
れるモデルを文書上に記述することができる。
4.3.1 節で述べたシンセシス推論フレームワークのログを自然言語での記述に変換する際、
操作された設計情報としてログ中に設計対象モデルや図表などの情報があった場合には、自
動的にそれらの設計情報へのハイパーリンクが文書上に置かれる。図 4.9 に示すように、構
築されたモデル (図 4.9 右上) や参照した図表 (図 4.9 右下) へのリンクが、文書中 (図 4.9 真
中) に置かれる。もちろん、ユーザが任意に参照した情報などを文書上にハイパーリンクし
て記録することもできる。
図 4.9: 設計文書にハイパーリンクされた情報
76
4.5
設計情報の管理
設計の試行錯誤の過程を記述するメリットは単に他者が設計を理解するためだけではな
い。設計作業の間、各々の選択肢の設計情報を管理することは設計者が選択肢を同時並列的
に評価するのに役立つし、また一旦破棄された解に後戻りして評価をやり直すこともでき
る。これらは設計過程の情報を記述することで設計者自身が受けることができるメリットで
ある。
各セクションにおける設計作業には、セクションに対応する知識操作によって初めて作成
された情報だけでなく、以前に作成された情報も影響していると考えられる。従って設計情
報を管理するにあたっては、以前の設計単位における情報も参照できるようになっているこ
とが望ましい。ところが、そのような情報を各セクションごとに全てに記述することは得策
ではない。これは同じ情報が複数の設計単位に影響していると考えられるので、個々のセク
ションに記述して各々で編集可能にすると一貫性がとれなくなるからである。
ところで、実際の設計過程について考えてみると、ある行為に影響を及ぼす情報は、その
行為の時点で始めて意識されたものを除いては、過去の行為から伝播してきたものと考えら
れる。そこで、このような情報の伝播を表現する機能をシステムに用意すれば、記述の効率
化や入力負荷の軽減に有効であると考えられる。
そこで、セクション間の論理的接続関係を示す設計過程管理グラフを使って、現在作業中
のセクションからグラフを逆向きにたどり、影響を及ぼすセクションを全て求める。それら
のセクションで生成・修正あるいは削除された情報を全て求めることで、作業中のセクショ
ンで利用可能な情報を得ることができる。
例えば、セクションが分岐する場合は、分岐前の情報は分岐した全てのセクションで利用
可能だが、分岐した各セクション以降で作成された情報は他のセクションでは無効とする。
セクションが統合される場合は、統合前のそれぞれのセクションで利用可能であった情報が
統合先のセクションで全て利用可能になる。ただしこの場合には、統合前の各セクションの
属性の整合性が問題となるが、このチェックはユーザが行うこととし、ここでは考えない。
このような情報の管理を行う仕組みとして KIEF のメタモデル機構に実装されている
ATMS(Asumption-based Truth Maintenance System)[de Kleer86] を利用する。ATMS は
外部の推論システムから伝えられる情報とその情報を正当化する情報の記録を元に、各情報
がどのような仮説に基づいているかという関係を計算しておくことによって矛盾のないデー
タ管理を行うための機構である。具体的には、各セクションで生成・修正あるいは削除され
77
た情報を仮説として保持し、設計過程グラフをたどって過去の仮説を全て集めることで、現
在のセクションにおける仮説の集合を構成し、ATMS に与えることによって、現在のセク
ションで有効な情報のみを得る。
例えば、図 4.10 に示すように各セクションが仮説を保持していたとする。ここで、作業
中のセクションが S2 であった場合は N1∼N3 および N7 が (図左下)、作業中のセクション
が S3 であった場合には N1、N4∼N6、N8 が (図右下)、それぞれアクティブになる。
N7
ATMSのノードリスト
ノードラベル
正当化
N1
{{A1}}
N2
{{A2}}
N3
{{A3}}
N4
{{A4}}
N5
{{A5}}
N6
{{A6}}
N7
{{A2}}
{(N1)}
N8
{{A4,A5}}
{(N4,N5)}
N8
N1
N2
N3
N4
A1
A2
A3
A4
and
N5
N6
A5
A6
S2
S1
各セクションが保持する仮説
セクション仮説
S1
{A1}
S2
{A2,A3}
S3
{A4,A5,A6}
S3
N7
N7
N8
N8
N1
N2
N3
N4
N5
N6
N1
N2
N3
N4
N5
N6
A1
A2
A3
A4
A5
A6
A1
A2
A3
A4
A5
A6
S1
S2
S1
S2
S3
S3
図 4.10: ATMS による設計情報管理
このような設計情報の管理を行う機構を実装することにより、設計の試行錯誤の過程を記
述するメリットを単に他者が設計を理解するためだけに留めるのではなく、設計者にもメ
リットを与えることになる。つまり設計作業の間、各々の選択肢の設計情報を管理すること
により、設計者が選択肢を同時並列的に評価するのに役立つし、また一旦破棄された解に後
戻りして評価をやり直すことも可能となる。
78
4.6
本章のまとめ
本章では設計過程の知識を獲得するための課題および方法論について述べた。まず課題と
して、
• 設計作業と同時に設計文書を作成すること
• 設計文書作成ツールと統合設計支援環境を統合することが必要であること
• 各種計算機ツールで利用される多種多様な情報を柔軟に取り扱う枠組みが必要なこと
を述べた。次にこれらの課題を解決するために本研究で採用する方法として、
• 統合設計支援環境と文書作成ツールとの統合
• 文書記述内容を知識操作に基づいて自動生成
• ハイパーテキストを用いた設計過程の明示的記述
• ハイパーリンクによる多様な設計情報の取り扱い
• ATMS による設計情報の管理
を挙げた。これらは本研究で開発する設計知識管理システムに対する主要な要求仕様と
なる。
79
80
第 5 章設計の文脈情報を利用した知識検索
本論文の 3 章および 4 章で、設計者が持っている知識やノウハウを設計文書の形態として
獲得する方法について議論してきた。多くの企業においても、設計・製造の基本知識やノウ
ハウの継承を支援しようとそれらを文書化し、大量の文書として蓄積してきたが、そのねら
いとは裏腹に、設計・製造の知識やノウハウが伝わっている実感が得られない企業は多いと
いう。その理由は、たとえ文書が残っていたとしても大量の文書の中から必要な情報を効率
的に見つけることができないからである [Tomioka00]。このため、せっかく獲得した知識を
共有・再利用することができないのである。
本節では知識検索における課題を明らかにしつつ、獲得した文書の中から知識を効率的に
検索するための方法論について述べる。
82
知識検索と設計文書
5.1
本節では、設計文書に記述された知識を検索する場合の課題およびその解決方法について
述べる。
5.1.1
課題
設計者は設計作業において様々な情報を、その時点での作業の状況に応じて求めている。
図 4.1 で挙げた建築基礎の設計の例を見ても、設計者が設計にあたって必要な様々な情報を
地盤研究者から状況に応じて聞き出しているのが分かる。
例えば、液状化の解析手法に関して、地盤密度、地下水位、N 値など解析を行なうために
必要なパラメータ、および解析の行い方に関する知識を得ている。その後、液状化の可能性
の高い土壌に対して施工される土壌改良工法に関する知識を得ている。
また、解析結果評価のノウハウも知識として得ている。この設計事例において設計者は解
析によって得られた結果を研究者に見せ、その評価を依頼している。研究者は、不適切なパ
ラメータの設定のために、誤った解析結果が得られていることを指摘し、どのように対処す
べきかを指示している。
設計文書はある設計事例における様々な知識・情報を含んでいるものであるが、上記の例
のような設計の部分的なサブ問題の解決に必要な知識を過去に蓄積された設計文書から検索
する場合、文書全体ではなく、断片的に利用可能である方が効率的と考えられる。なぜなら
一般に設計作業は過去の設計事例を部分的に再利用し、それを修正して行うことが多いから
である。例えば、Pahl および Beitz は設計を次の 3 つに分類している [Pahl88]。
• 独自設計
同一、類似あるいは新しい役割を有するシステム (プラント、機械組立部品) について
の独自の設計解原理を作り上げることに関する設計活動である。
• 適応設計
設計解原理は同じままで、既知システムを目的の異なった役割に適応させるための設
計である。この場合には部品や組立部品について独自設計が必要となることが多い
• 代替設計
83
機能や設計解原理は変更することなく、選択したシステムの部分の寸法や配置を変更
する設計である。
この分類に基づきドイツ機械工業協会の協会員によって行われた調査によると、機械工業
における製品設計の 55% が適応設計、25% が独自設計、20% が代替設計であることが分
かった。つまり、過去の設計事例全体をそのまま流用する設計は全体の 2 割しかないという
ことになる。
このために設計文書を多くの事例で使用可能な汎用的な情報とするためには、設計文書
を、サブ問題を解決するのに必要な情報を持った小部分群に構造化することが必要である。
5.1.2
文書知識の導入
設計文書を構造化するためには、サブ問題を解決するのに利用した知識・情報を記述した
部分を抽出する必要がある。このために本研究では、3.2.2 節で述べた思考パターンを利用
する。本研究で獲得される設計文書はメタプロセスモデルによるコーディングが行われてい
るので、思考パターンに基づいて文書を構造化することができる。本研究ではこうして構造
化された文書を文書知識と呼んでいる。文書知識を再利用することにより、過去に行った設
計対象モデルの部分的な構築や計算などといった設計作業を再現すると共に、その設計作業
に関する文書作成の負担を軽減することができる。
84
5.2
文書知識の検索
前節では、設計文書を知識として利用するための方法について述べた。次に本節では文書
知識を効率的に検索するための課題について明らかにし、本研究における方法論について議
論する。
5.2.1
検索要求の記述
2.1.4 節で述べたように、文書を検索する際の最も一般的な手法はブーリアン式のキーワー
ド検索である。しかし単純なキーワード検索はしばしば本来の意図とは無関係ないくつもの
検索結果をもたらすことになり、実際には効率が悪い場合が多い。
例えば、設計者が治具の表面の精度を評価する方法を検索する場合を考える。一般的な
Web ベースの検索エンジンに、キーワードとして「精度」と「治具」を与えてみる。ブール
演算子 AND で 2 つのキーワードを接続すると効果的であると考えられる。しかし設計者が
知りたいと要求している情報の内容を表現するにはこれでは不十分である。なぜなら、文書
内にこの 2 つのキーワードさえ含んでいれば、必ずしも治具の精度に関する文書だけではな
く、例えば治具の取付け方と加工精度に関する文書などが含まれる可能性があるのである。
つまり設計者は無関係な何千もの検索結果を扱わなければならず、効率的な検索への大きな
障害となる。これは、検索要求として与えられた 2 つのキーワード「精度」と「治具」の間
の関係が明確でないからである。
またキーワードの選び方でも検索される情報の量はまちまちである。キーワードが抽象
的すぎれば大量の情報が検索されるだろうし、逆に具体的すぎれば必要なものが入ってこ
ないということもあり得る。あるいはちょっとした表記のぶれで必要な情報が検索できなく
なることもあり得る。例えばアクチュエータに関して調査したい場合、検索エンジンにキー
ワード「アクチュエータ」を与えたと仮定する。この場合、検索対象となる文書に「アク
チュエータ」と記述されていれば良いが、実際には「アクチュエーター」であったり「モー
タ」であったり「発動機」であったりする可能性もある。
情報検索研究の分野では、キーワード間の関係を表現するためにネットワークグラフによ
る検索要求の表現や、膨大な量の検索結果をランク付けするために単語の出現頻度の情報な
どから適当な重み付けを行う手法の提案も行われている [Ingwersen95]。またキーワードの
表記のぶれを防ぐために、類義語辞書やオントロジー辞書を用意したり、また 2.1.4 節で述
85
べたように語彙空間モデルを導入する研究もある。
ここでの課題は次のようにまとめられる。
• 検索要求としてのキーワード間の関係を表現するための枠組みを複雑にすればする
ほど検索の精度は上がるが、ユーザにとっては使いづらいものとなる。このトレード
オフを解決する必要がある。
• 検索結果のランキングを行う必要がある。
• 類義語辞書やオントロジーの収集を行っておく必要がある。
5.2.2
設計の文脈
では知識の検索要求として何を記述すれば良いのであろうか。この議論におけるヒント
を、ソフトウェア開発のデザインパターン研究においてしばしば利用される文脈の概念に
求めることができる。デザインパターンとは、「オブジェクト指向システムにおいて繰り返
し発生する問題を解決する一般的な設計に対して名前を付け、説明を行ったものであり、問
題、解決策、解決策を適用する時期、およびその結果を記述したもの」と定義されるもので
あり、こうしたパターンを共有・再利用することによりソフトウェア開発の効率を上げよう
とするものである。さらにデザインパターンの文脈 (context) として「繰り返し発生する一
群の状況のことを指し、その状況にパターンを適用する」ものであるとの定義がなされてい
る [Gamma95]。
デザインパターンは一種の知識であるので、知識検索においても「繰り返し発生する一群
の状況」としての文脈を導入し、これを検索要求とすることが考えられる。具体的に設計に
ついて考えてみると、同じ機構要素の問題を取り扱っていてもその文脈にしたがってその解
決方法が異なる場合が考えられる。例えば、歯車による回転伝達機構の設計を考えた場合
に、それがカメラなどの精密機械に使われるのか、フォークリフトのような建築機器で使わ
れるのか、おもちゃに使われるのかで、設計時に考慮しなければいけない点は大きく異なっ
てくる。そのため、設計者にとって最も役に立つ設計文書とは、検索時の設計の状況と似た
状況を持つ過去の設計事例の設計文書であると考える。
本研究では設計の文脈を、
「ある時点における製品の情報および設計者の要求」と定義し、
設計の文脈によって知識の検索要求を記述することにする。
86
ところで本研究では KIEF を用いた設計支援環境と文書作成ツールとの統合環境におい
て設計を進めながら設計知識を獲得していくことを考えている。この環境を利用する設計者
は、設計の間、テキストおよび対象モデルによって設計したい製品の情報を記述しており、
そのような情報は製品の情報だけでなく、製品情報として具体化されていない設計者の要求
も表現している。そこで本研究では、設計文書に記述されたテキスト情報とメタモデルにお
ける製品情報から設計文脈情報をモデル化する。
このような設計文脈によって検索対象となる文書をインデックス付けすることを考える
と、進行中の設計における設計文脈情報モデルと検索対象の文書にインデックスとして与え
られた各設計文脈情報のモデルとのパターンマッチによる効果的な検索が期待できる上、そ
の類似度を比較することにより、最も似た状況を持った設計文書を高くランク付けすること
ができると考えられる。
設計文書
Specification
This building is for
commercial use
設計文脈情報モデル
Commercia
l
設計対象のメタモデル
Building
Basement
Use
Building
Connection
Basement
Connection
図 5.1: 設計文脈情報モデルの例
5.2.3
設計文脈情報のモデリング
本研究では、暫定的な設計解であるメタモデルおよびそのメタモデルに至るまでに作成し
た設計文書から、以下の手順により設計の文脈情報モデルを作成する。
先に述べたように、メタモデルは設計対象を構成する実体概念、関係概念、物理現象概念
などをネットワークとして表現したモデルであり、各々の概念については、概念辞書と呼ぶ
知識ベース中で抽象具体の概念階層などのオントロジカルな定義が与えられている。各概念
には当該概念を表現する代表語を名前として与えてあるが、以下の手順中のステップ 4 にお
ける単語のマッチングで、同じ概念を指すにも関わらず設計文書中に記述されている単語と
代表語とが一致しない可能性がある。この表記の振れを類義語辞書を定義することで解決す
87
る。このために、各概念には、代表語以外の単語も類義語として登録してある。
次に、設計文脈情報モデルを生成するためのアルゴリズムを説明する。本研究では、製品
および製品を構成する部品に関して記述している一つの文に含まれる単語の集合により一
つの文脈が形成されると考える。図 5.1 に示した例で説明すると、「この建築物は商用であ
る。」という文が文書に記述されていたとする。この文からは、
「商用」が「建築物」を特徴
づける条件として抽出され、「建築物」に関する文脈を形成する。
設計文脈情報モデルの生成アルゴリズムをプログラム言語 Smalltalk で記述した例を図 5.2
に示し、以下で詳しく解説する。
Step1: セクションの論理的接続関係に基づき、現在のメタモデルおよびメタモデルを作成
するのに直接関係した設計作業の文書のみを取り出す。
Step2: 形態素解析ツールを用いて文章中の単語に形態素タグを付与する。また、一つの文
ごとに単語の集合を形成する。この単語の集合が文脈の単位となる。この時、助詞な
どの情報は使わない情報として削除する。
Step3: 各文中の単語とメタモデル中の実体概念の名前を比較する。この比較時に各々のメ
タモデル中の実体概念については概念辞書を参照して、それをより抽象化した概念の
名前についてもマッチするかどうかを調べる。例えば、メタモデルに実体概念「ステッ
ピングモータ」が含まれていた場合、
「ステッピングモータ」と「モータ」は抽象具体
関係にあることが定義されているので、文中に記述された単語「モータ」は上記のメ
タモデルで「ステッピングモータ」に対応付けられる。
Step4: 各文中の単語がメタモデルの実体概念とマッチした場合は、マッチした単語および
マッチした単語と同じ文中にあるその他の単語は、マッチしたメタモデル中の概念に
関係ある語としてメタモデルに加えて実体概念とリンク付けし、設計文脈情報モデル
とする。
なお、本研究では形態素解析ツールとして「茶筅」[Matsumoto99] を用いている。
こうして生成された設計文脈モデルと、各文書知識にインデックスとして与えられた設計
文脈情報モデルを次節で述べる方法で比較、評価することにより、関係のない文書をフィル
タリングすることが可能になる。
88
contextModelingFor: currentSection
|
currentSection
oe
activeSentences
activeConcepts
activeEntities
answer
|
"currently active design section"
"Ontology of entity"
"Set of sentences"
"Set of concepts in metamodel"
"Set of entities"
answer := OrderedCollection new.
oe := VLKB getEntityOntology.
activeSentences := currentSection getActiveSentences.
activeConcepts := currentSection getActiveConcepts.
answer addAll: activeConcepts.
activeEntities := activeConcepts selectEntities.
activeSentences do:
[:sentence|
activeWords := sentence morphologicalAnalysis.
activeEntities do:
[:entity|
|entitySynonyms|
entitySynonyms:= oe getSynonymsOf: entity.
(activeWords includesOneOf: entitySynonyms)
ifTrue:
[
entity connect: activeWords.
]
]
]
ânswer
"Step 1"
"Step 2"
"Step 3"
"Step 4"
図 5.2: 設計文脈情報モデル生成アルゴリズム
89
設計行為を考慮した文脈情報モデル
5.3
5.3.1
文脈情報モデルの課題
設計文脈情報モデルを用いた検索手法を建築物の基礎構造物の設計例に適用し、その有効
性を検討したところ、前節で述べた設計文脈情報モデルの生成手順はシンプルな枠組みで頑
健性の高いものである一方で、設計行為に関する概念を考慮していなかったために検索の精
度に問題があることが分かった。
例えば設計の文脈として、
「テーブル上面の加工精度について提案」している場合と、
「テー
ブル上面の加工精度を評価」している場合を考える (図 5.3)。各文脈で本来要求されている
文書は、それぞれ「テーブル上面の加工精度を高める方法に関する設計文書」、
「テーブル上
面の加工精度を検証するための方法に関する設計文書」等であると考えられるが (図 5.3 で
黒色の矢印でその対応関係を示す)、前節で述べた手法では両文書を分別する手だてはなく、
検索結果にまぎれてしまうので検索の精度が低下する (図 5.3 の灰色の矢印)。
評価
提案
加工精度
加工精度
テーブル上面
テーブル上面
テーブル上面の加工精度を高める
方法に関する設計文書
テーブル上面の加工精度を評価する
ための方法に関する設計文書
図 5.3: 検索精度の低下
5.3.2
設計行為を考慮した設計文脈情報のモデル化
そこでメタプロセスモデルに記述された設計過程に関する情報設計を設計文脈情報のモデ
ルに利用してこの課題の解決を試みることとする。具体的には、5.2.3 節で述べた文脈モデ
ル生成手順において、以下の手順をステップ 3 とステップ 4 の間に追加する。
• 各セクションに対して、そのセクションにおける基本語彙をメタプロセスモデルに問
い合わせる。
90
知識検索の要求
テーブル上面の加工精度を評価したい。
テーブル上面の加工精度が要求されて
いる。要求に対する解を提案したい。
評価
提案
加工精度
加工精度
テーブル上面
テーブル上面
テーブル上面の加工精度を高める
方法に関する設計文書
テーブル上面の加工精度を評価する
ための方法に関する設計文書
図 5.4: 基本語彙を用いた設計文脈情報モデルによる検索
また、以下の手順をステップ 5 以降に追加する。
• 設計文脈情報モデルにおいて、各セクションから得られた概念および単語に対して、
各セクションの基本語彙名を設計行為に関する情報としてリンク付けする。
これにより図 5.4 のように設計行為を考慮した設計文脈情報モデルを生成可能であり、適
切な設計文書のフィルタリングが可能である。
91
5.4
設計文脈情報を利用した検索結果のランキング
本節では設計文脈情報を利用して文書知識を検索した結果のランキングを行う方法につい
て述べる。具体的には、設計文脈情報モデルの類似度の定量化方法、およびその類似度に基
づいたランキング手法について述べる。
5.4.1
グラフマッチングによる文脈情報モデルの類似度の定量化
5.2.3 で述べたアルゴリズムによって生成される設計文脈情報モデルはメタモデルの概念
ネットワークに文書から抽出された単語が付加されたものであるので、2 つのモデル間の類
似度は、メタモデル部分でマッチする概念 (設計行為を表現する基本語彙も含む) の数 Mm
および、実体概念にリンク付けされた単語集合の中でマッチする単語の数 Mw によって定
量的に表現される。メタモデル部分のマッチングは概念をカラードノードとするネットワー
クグラフの部分マッチングにより実現される。単語のマッチングは、メタモデル部分でマッ
チした実態概念にリンクされた単語同士で行う。なお、メタモデル部の概念に対しては「否
定」を与えることができる。これはマッチした場合に逆に減点することで、モデル間の類似
度を下げるためのものである。
図 5.5 にマッチングの例を示す1 。図の左上に示されているのが「打込杭工法を選択する
際の注意事項」に関する文書にインデックスとして付加された設計文脈情報モデル (以下、
「インデックス」と呼ぶ) である。「騒音・振動を避けるべき建築物」があってはいけないこ
と、
「杭」の「経済性」を考慮していること、
「杭」の「選択」に関するものであること、な
どがモデル化されている。このインデックスに対し、図下に示した 3 つの設計文脈情報モデ
ルでマッチした概念の数、単語の数がそれぞれ示されている。
まず設計文脈 1 について説明するが、概念辞書の定義の中で「病院」は「騒音・振動を避
けるべき建築物」の下位概念として定義されていることに留意する。
「地盤」、
「杭」、
「選択」
の 3 つの概念がマッチしているものの、インデックスでは否定されている「騒音・振動を避
けるべき建築物」と「病院」がマッチするので、Mm = 1 となる。
「地盤」、
「杭」、
「選択」の 3 つの概念が
次に設計文脈 2 について説明する。設計文脈 1 同様、
マッチし、さらに「杭」にリンクされた単語「経済性」がマッチするので、Mm = 3, Mw = 1
となる。5.4.2 節で述べるランキング手法の取り方にもよるが、図 5.5 に示した 3 つの設計
1
この図では簡潔に説明を行うためにメタモデルの概念として実体概念のみを示している。
92
文脈の中では最も高い類似度を得る設計文脈である。
最後に設計文脈 3 について説明する。「地盤」、「杭」の 2 つの概念、がマッチしているの
で Mm = 2 である。単語「経済性」は「建築物」にリンク付けされているものなのでイン
デックスの単語「経済性」とはマッチせず Mw = 0 となる。
なお類似度の定量化の際に、概念の種類に応じて重み付けを行うことも考えられる。例え
ば、基本語彙はメタモデルにおける他の概念に比べると数が少ないが、5.3 節で述べたよう
に知識検索の際には設計行為に関する情報が重要な役割を果たしているため、マッチした基
本語彙の数に適当な重み w をかけて Mm に加えるのが適当と考えられる。本研究の実装で
は w = 10 としている。
打込杭工法を選択する際の注意事項
に関する文書
実体概念
騒音・振動を避けるべき建築物
基本語彙
地盤
テキスト情報から抽出された単語
選択
否定
経済性
杭
マッチした概念・単語
設計文脈２
設計文脈１
設計文脈３
病院
建築物
経済性
地盤
環境
地盤
選択
経済性
杭
Mm = 1
Mw = 0
選択
地盤
杭
杭
Mm = 3
Mw = 1
Mm = 2
Mw = 0
評価
図 5.5: 設計文脈情報モデルのマッチング例
5.4.2
ランキング手法
設計文脈情報モデルの類似度は、メタモデル部分でマッチする概念 (設計行為を表現する
基本語彙も含む) の数 Mm および、実体概念にリンク付けされた単語集合の中でマッチする
単語の数 Mw によって定量的に表現されることは述べたが、類似度のランキングの手法とし
ては以下の 4 つが考えられる。
93
1. マッチした実体概念の数
2. マッチした実体概念の割合
3. マッチした実体概念にリンクされた単語の中で、マッチした単語の数
4. マッチした実体概念にリンクされた単語の中で、マッチした単語の割合
これらの 4 つの方法は状況に応じて使い分けるべきであり、統合された 1 つの評価式を使
用することは不適当であると考える。例えば、設計者が特定のサブ問題に関する文書を検索
したい時には 2 の方法が有効であろうし、設計事例全体に興味を持っている場合は 1 の方法
が有効であろう。システムを開発する際には設計者が状況に従ってこれらの方法を選択でき
るようにすべきである。
94
5.5
本手法の利点と限界
本章で提案した手法は、設計文脈情報をグラフとしてモデル化することにより、設計文脈
の類似度をグラフのマッチ度によって定量化し、設計文脈を利用した知識検索を実現するも
のである。本手法の利点および限界について考察する。
まず、キーワード間の関係を設計文脈情報モデルにより記述しているため、検索の精度が
上がることが考えられる。例えば図 5.5 において、インデックスおよび設計文脈 2、設計文
脈 3 に共通して存在している単語「経済性」について考える。通常のキーワード検索であれ
ば、設計文脈 2、3 いずれもインデックス中の単語「経済性」とマッチする。しかしグラフ
の構造で判断すると、設計文脈 3 の単語「経済性」はマッチしないことが分かるため、両者
を峻別することが可能となる。これは通常のキーワードマッチではできないことである。
次に、設計文脈情報モデルは設計対象のメタモデルと文書に記述されたテキスト情報から
自動的に生成されるが、これらは KIEF を利用して設計を行った場合、設計作業と同時に作
成されている情報であるため、検索の際に逐一設計者が作成する必要が無いことである。こ
のため、設計作業の中での検索作業がよりスムーズに行えると考えられる。
一方で、検索対象となる文書に対して、インデックスとして設計文脈情報モデルを付加し
ておく必要がある、という問題がある。KIEF で作成した文書から文書知識を抽出する場合
は、5.2.3 節で述べたアルゴリズムにより設計文脈情報モデルを生成することができるが、既
存の文書に対しては手動で設計文脈情報モデルを付加せざるを得ない。この作業を支援する
枠組みは今後の課題である。
95
96
第 6 章設計知識管理のための CAD システム
の実装
本論文ではこれまでに、設計知識の管理を実現するための方法論について述べてきた。ま
ず 3 章では本研究で提案する設計文書を中心とする知識管理の枠組みについて述べた。具体
的には設計過程の情報および情報間の関係を表現するために本研究で提案するメタプロセ
スモデルについて述べ、メタプロセスモデルを利用した設計知識管理について述べた。4 章
ではメタプロセスモデルを用いて設計知識の獲得を実現する手法について述べた。具体的
にはハイパーテキスト文書による設計情報の記述を行い、さらに統合設計支援環境である
KIEF(Knowledge Intensive Engineering Framework)[Sekiya99] と文書作成ツールを統合す
ることにより、KIEF で設計作業を行いながら設計過程における情報を文書上に記述するこ
とが可能となった。さらに KIEF における設計作業のログを元に自動的に設計過程を獲得
し、メタプロセスモデルを作成することが可能となった。5 章では設計の文脈を考慮した知
識検索手法を提案した。この手法ではまず、検索対象となる文書を、設計の部分的なサブ問
題の解決に必要な知識を記述した小部分に構造化することを考え、これを文書知識と名づけ
た。この手法では、設計作業中に知識を検索する際に、KIEF における設計作業で作成され
るメタモデルと文書上における設計対象の記述から現在進行中の設計作業に関する文脈情
報モデルを自動生成する。検索の対象となる文書知識にもインデックスとして文脈情報モデ
ルを付与しておき、両者のマッチングにより検索を行うことにより、知識としての文書を共
有・再利用することが可能となった。
本章ではこれらの方法論を実際に計算機システムとして実装し、その検証を行う。具体的
には、実際の設計事例を元に、その設計を行った設計者の協力を得て模擬的な設計作業の進
行シナリオを与え、システムを使って設計作業を進める。システムによって作成された情報
と実際の設計事例での最終設計文書との情報量の比較を行うことによってシステムの検証を
行う。
98
システム構成・実装
6.1
6.1.1
設計文書作成管理システムの実装
本論文でこれまでに述べた方法論に基づいて、CAD のための設計知識管理システムとし
て設計文書作成管理システム (DDMS; Design Documentation Management System) を構
築した。DDMS は、Smalltalk 言語の開発・実行環境である VisualWorks 5i.21 上で開発さ
れている。また VisualWorks のアドオンツールであり Web アプリケーションの開発環境で
ある VisualWave を用いているので、Web ブラウザを通じて DDMS の文書および KIEF の
知識にアクセスすることが可能となっている。
DDMS のシステム構成を図 6.1 に示す。また DDMS での設計作業の大まかな流れは 6.2
に示すようなものとなる。
Document Base
Raw
Document
Document
Document
Search Engine
Document
Knowledge
Document Context
Knowledge model
Similality
Context
Grading
Modeler
Engine
Text
Text
HTML Document Editor
Design Document
Knowledge
Operation
Document
Converter
Knowledge
Operation
Graph
Spec1: It has to pass the rating for high building.
Spec2: It has to endure for 500 Gal earthquake.
Function decomposition and Behavior selection.
Please input required function: Make highbuilding.
Make highbuilding is divided to follwing sub
functions.
-To build building on basement
-To make basement
"To build building on basement" is divided to
following functions.
Metaprocess
Model
Concepts
Design Process Graph
ATMS
assumptions
Log Converter
Log
KIEF
VisualWorks Web server (VisualWave)
Result Operation
Browsing
Document
Composing
Document
Designer
図 6.1: DDMS のシステム構成
1
VisualWorks および VisualWave は Cincom Systems 社の登録商標である。
99
Start
Y
文書知識を
検索する
KIEF行為レベル推論
N
セクション作成
文書知識の検索
設計行為の選択
DDMS
KIEF対象レベル推論
推論システムの選択
文書知識の編集／再利用
設計作業の記録
推論システム内での作業
N
終了？
Y
システムのサポート
文書作成作業
End
設計作業
図 6.2: DDMS における設計作業の流れ
6.1.2
システムの機能
設計文書管理システムは、基本的には設計文書エディタとして実装されており、設計者が
自由に文書を記述し、編集することが可能である。それに加えて、以下の機能が実装されて
いる。
1. KIEF に接続されたモデラを設計文書管理システムを通じて利用することができる。ま
たシンセシス推論フレームワークにおける設計過程知識により状況に応じた設計行為の
提示を受けることができる。
2. KIEF 上で実行された操作を記録、リプレイすることにより過去の設計作業を部分的に
再利用することが可能である (図 6.3)。
3. KIEF 上で進められる設計作業の記録が自然言語で自動的に文書に記録される。
4. メタプロセスモデルにおいて設計情報間の導出関係を記録することにより、設計過程を
明示的に記録できる。記録された設計過程は設計過程グラフとして視覚的に表示される
(図 6.13)。
5. 設計者が文書上にコメントなどを記述するよう促す。具体的には以下の 2 つの方法で
行う。
100
• 設計者が設計過程知識を選択して計算またはモデラ操作を実行した時、ダイアロ
グを表示して設計者に自然言語でその意図を記述するように促す (図 6.4)。
• 検索された文書知識を選択する際、その文書知識にインデックスとして付けられ
た全ての設計文脈をリストアップして提示し、今回の設計の文脈として採用でき
「設計
るものを選択するよう促す。これは中公路 [Nakakoji98] が指摘するように、
者の作業状況に関連する情報をシステムが能動的に提示することにより設計者の
思考が呼び起こされ、設計者が当初気付いていなかった設計意図が言及される」と
いう立場に立った手法である。
6. メタプロセスモデルにおける情報導出関係に基づき、試行錯誤の過程のうち現在注目し
ている設計解候補に関連する情報のみをメタモデル上でアクティブにする。これにより
複数の案を同時並列的に検討したり、以前の案に戻って作業をやり直すことができる。
7. 設計の文脈情報をモデル化して設計者に明示的に示すことができる。
8. 必要に応じて文書知識を検索、利用して作業を進めることができる。検索の際、その時
点の設計の文脈に応じて適切な知識の提示を受けることができる。
9. Web サーバにアクセスすることによって、Web ブラウザを通じて世界中のどこの計算
機からでもシステムにアクセスし、設計知識を閲覧することができる。
6.1.3
KIEF の外部モデラ
KIEF では、プラガブル・メタモデル機構を通じて接続される工学モデラをまとめて外部
モデラと呼んでいる。現在、KIEF で利用可能な外部モデラを以下に示す。
1. FBS(Function Behavior State) モデラ
梅田が開発した、機能設計を支援するためのツールである [Umeda96]。
FBS モデラでは、機能を「動詞＋目的語」の形式で表現する。FBS モデラではドイツ
流設計方法論に基いて、要求仕様を抽象化した、設計対象全体が持つべき全体機能をモ
デラへの入力とし、
• 全体機能を、より具体的なレベルの機能へ分解し、
• 各機能の実現方法としての機構の物理的挙動を選択し、
• 各機能の実現方法を組み立てて、全体機能を実現する設計対象のモデルを構築する
101
1.リプレイしたい操作を選択
2.リプレイされた操作により
構築されたモデル
3.リプレイの結果を利用して作業を再開
図 6.3: 操作のリプレイ
102
コメントを取るためのダイアログ
図 6.4: 設計者にコメントの記述を促すダイアログ
103
ことで機能設計を支援する。このため、機能の分解方法、および実現方法を表現するた
めの知識として表 6.1 に示す機能プロトタイプ知識を持っている。
表 6.1: 機能プロトタイプの定義
名前
動詞＋目的語
展開方法
サブ機能プロトタイプのネットワーク
実現方法
実体・関係・物理現象の各概念のネットワーク
2. QPAS(Qualitative Process Abduction System)[Ishii93]
設計者が入力した挙動を実現するような機構を、後ろ向き定性推論により提示するシス
テムである。
3. 数式処理システム
数式を処理するためのシステムである。Mathematica2 を使用している。
4. 定性推論システム
定性推論は、人間が物理現象を把握するのに用いているのと同様な概念を計算機内に用
意し、その概念を用いてモデリングや推論を行なおうとするものである [Forbus84]。定
性推論システムによって、用意された概念知識に基づいて設計対象に起こり得る物理現
象を全て導出することができるので、設計者が予期していなかった副次的な現象を発見
することができる。
5. 3 次元ソリッドモデラ
Pro/ENGINEER3 を使用している。KIEF と Pro/ENGINEER の接続の技術として分
散オブジェクト環境の標準仕様である CORBA[Siegel96] を用いている。
以降の外部モデラは本研究で KIEF に追加したものである。
2 次元形状モデラ
概念設計など設計の上流の段階では、設計者は設計対象を表現するための簡単な作図をす
ることが多い。こうした簡単な作図作業を支援するための 2 次元の作図ツールである。
このモデラでは、単に 2 次元形状情報を扱うだけでなく、各形状に KIEF の実体概念を、
2
3
Mathematica は Wolfram Research 社の登録商標である。
Pro/ENGINEER は Parametric Thechnology Corporation 社の登録商標である。
104
形状間の関係に関係概念を割り当てることができる。このため、ツール上で描いた図面をそ
のままメタモデルシステムへの入力とすることができる。
部品選定システム
設計作業では、ある部品を特定するのに全ての属性値を決めてしまうのではなく、「荷重
は 2kg 以下」などといった属性的仕様を満たすような部品を標準品の中から探し出す、と
いった部品選定に関わる作業が存在する。部品選定システムはこうした作業を支援するため
のツールである。
部品選定システムには、必要な部品に関する情報がデータベースとしてあらかじめ用意し
てある。設計者はまずメタモデルの実体の中から、選定作業を行いたいものを選ぶ。次に選
定する条件をキーワードや属性概念を用いた不等式で表現する。システムは条件に合致する
部品をデータベースから検索し、設計者に提示する。提示される部品は複数であることもあ
るので、その場合は設計者が一つ選択する。
液面形状解析ツール
表面張力によって形成される液体の液面形状を解析するためのツールである。 105
6.2
実行例
本節では DDMS の実行例を示し、システムの有効性を示す。本研究で開発したシステム
が異種の設計対象に対しても同様に有効であることを示すため、機械設計と土木設計という
異なる設計領域における設計事例、具体的には、
1. レーザーリソグラフィーの設計
2. 加工機械の設計
3. 建築物基礎構造の設計
の 3 つの設計事例に適応した。
また本章で示す実行例は、実際の設計作業で作成された設計文書および設計作業で使用さ
れた資料と、作業を行った設計者から聴取したコメントを元に再現したものである。
6.2.1
レーザーリソグラフィーの設計例
本節では DDMS 上で行われたレーザーリソグラフィーの設計例を示す。この例では KIEF
に接続されている様々なモデル推論システムを使い分けながら設計を行い、なおかつ同時に
設計文書を作成する例について述べる。ここで行われる設計作業は図 6.5 のように DDMS
により自動的に文書化される。なお本節で示す DDMS のスクリーンコピーに、該当する設
計作業で生成された文書の記述内容を示す。
設計仕様の入力
まず最初に、要求仕様をシステムへ入力する。この時、機能的仕様 (レーザーリソグラフィ
による製品の造形) は KIEF に接続された FBS モデラを通じて入力され (図 6.6)、属性に関
する情報 (各層の厚さ 10µm 以下を実現) は制約として入力される (図 6.7)。
既存の案の検証
次に、ここで与えられた機能的仕様 (レーザーリソグラフィによる製品の造形) に対し、
FBS モデラの実体ライブラリを検索し、実体概念として既存のレーザーリソグラフィーシス
テム (規制液面方式) を初期の設計解として提案する (図 6.8)。しかし、この既存のレーザー
リソグラフィシステムを用いて実験を行うと、造形物を破壊する可能性がある事がわかった。
106
図 6.5: DDMS による文書生成
' 機能仕様:Stereo-Lithograph(product)1 'が
要求仕様として記述されました。
図 6.6: 機能的仕様の入力
107
' 属性仕様:AttributeRequirement32「
FabricatedProductのLayerThicknessが10以下で
あること。」 'が要求仕様として追加されまし
た。
図 6.7: 属性的仕様の入力
また、作成したモデルに対して物理法則に基づいた推論を行うことにより、窓板と造形物の
間に固着現象が発生する可能性があることが導出された。図 6.8 の網掛けになったノードが
推論により導出された現象である。
既存の解に対する問題点の発見 (矛盾の解消)
問題の原因を特定するために、FBS モデラを通じ、そのレーザーリソグラフィーシステ
ムの機能を発現させるために必要な挙動と、意図しない挙動を区別して表示し、液面との接
触による造形物と窓板の固着を問題の原因として特定した。既存の解に対しての問題の原因
を解消するために、液面との接触を行っている部分が問題であると考え、液面を制御する機
能を実現する機構の採用を取りやめた。
新しい解の提案（機能、挙動レベル）
次に、第 4 案の設計を例に取り、様々なレベルでのアブダクションについて検討を行った
例を示す。ここでは、新しい解を 2 つのモデルベース推論システムを用いて導出する。
1. FBS モデラの利用
まず、FBS モデラを利用し、この液位を制御する機能を実現する方法の検討を行い、液
位差方式を選択する。
108
設計者は、' FBSModeler 'の知識を選択しました。
利用した設計情報は ' 機能仕様:Stereo-Lithograph(product)1 ' です。
問題に対する解として、 ' LaserPhotoformingPF29 機能仕様:Flatten(surface)27 機能仕様:
Control(table)23 SimpleTableControllingPF31 ... 'が提案されました。
定性推論により、予期せぬ物理現象' Stick35 ' が設計対象に起こる可能性があることが導出され
ました。
これらの物理現象を詳しく解析するために、 ' Only in logic level BeamModeler
SurfaceTensionModeler ...'の知識を利用することが可能です。
図 6.8: 初期設計解の提案と設計解に発生する現象の導出
109
2. QPAS の利用
QPAS は挙動としてパラメータの変化を与えることにより、その挙動を実現する機構を
導出するシステムである。ここで、液位の調整に関する挙動を入力としてシステムを利
用する。まず、液位を調整するための物理現象として、液量の変化、液面の空気圧の変
化などが導出され、それを実現する機構として、第 1 案∼第 3 案の事例と共に液位差方
式の事例が導出される (図 6.9)。また、物理現象に関する単純なる組み合わせ的後ろ向
き推論を実行しているために、乱流を積極的に利用して制御するといった常識的ではな
い解などもそこに含まれる。
図 6.9: QPAS の利用
新しい解の提案（カタログ選択、数値演算）
この液位差方式の設計を詳細に進めていくと、モータの選定や数値解析に基づいた形状の
決定などの作業を行う必要がある。今回用意したカタログ検索システムには、XY ステージ
110
に関するカタログ情報が蓄積されており、今回の設計で用いる XY ステージについて、その
選択を行った (図 6.10)。
設計者は、 ' CatalogueWindow 'の知識を選択しました。
利用した設計情報は ' TableController2 ' です。
解析の結果として、設計情報' IDName34(='SGSP20-35(XY)') Travel35(=35) Stick32
PositionalAccuracy36(=0.005) 属性仕様:AttributeRequirement37「TableController2の'Travel3
5が30以上であること。」属性仕様:AttributeRequirement38「TableController2の'Travel35が5
0以下であること。」属性仕様:AttributeRequirement39「TableController2の
PositionalAccuracy36が0.01以下であること。」' が追加されました。
図 6.10: カタログの利用
また、今回の設計の一番の問題は、表面張力をうまく生かして、液面にくぼみを作り出
し、このくぼみを制御して層厚を制御するということである。このくぼみの形を計算するた
めに、表面張力計算システムが利用可能である (図 6.11)。また、この表面張力計算システム
で決めたノズル径の情報は、KIEF のモデル管理機構を通じてソリッドモデルへ伝播され、
ソリッドの情報が変更されることになる（図 6.12）。 111
設計者は、 ' SurfaceTensionModeler 'の知識を選択しました。
利用した設計情報は ' On32 ConnectionWithASpace26 Liquid12 SurfaceOf24 Surface6 Resin1
6 Contact30 SurfaceOf23 Surface20 Contain25 Hollow10 Liquid8 SurfaceTension38 In21 In28
' です。
解析の結果として、設計情報'Radius96(=0.0005) 'が追加されました。
図 6.11: 樹脂表面形状の数値計算
112
図 6.12: ソリッドモデルの変更
表示モードの変更
本例題は機能「液面を制御する」に関して 4 つの解を提示し、それぞれの解の評価を行う
ものであった。この過程は、設計過程管理グラフの表示モードを「時系列表示モード」から
「論理関係表示モード」に切り替えると図 6.13 に示すように明示的に見ることができる。
なお本例題で作成された文書およびシンセシス推論フレームワークのログは付録 B およ
び C に付す。
6.2.2
加工機の設計例
本節では DDMS 上で行われたレーザー加工機の設計例を示す。例題の実行に先立ち、著
者らは実際の設計活動によって作成された設計文書から 40 件程度の文書知識を抽出し、文
書知識ベースに蓄積した。ここで抽出した知識は，問題解決の方法および問題解決する際に
参照された情報、要求仕様に対して提案された設計解、解の評価のための計算式、解を評価
する方法、図面情報などである。本節で示す実行例において、これらの文書知識が実際の設
計事例における設計過程に沿った形で検索できれば、本研究における知識検索の手法は成功
していると考えることができる。文書知識の例を図 6.14 に示す。
113
図 6.13: 表示モードの変更 (図 4.8 の再掲)
Contents of the document knowledge
Context model
The position of a operation panel from
Security
the view point of security :
An operation panel should be at the
Operation panel
position where a worker operation without
Attached
opening a save cover of a machine
Machine
図 6.14: 文書知識の例
114
要求仕様の記述
最初に設計者は「セクション 1」で今回の設計に対する要求を文書上に記述した。この例
では、レーザー光線を用いたワーク加工機を設計することや、安全性を考慮する必要がある
ことなどを記述した (図 6.15)。
設計問題の分割
次に設計者はこの設計問題を 4 つのサブ問題、つまりワーク固定部の設計 (図 6.16 のセク
ション 2)、外部ケースの設計 (セクション 3)、レーザー受光部終端子の設計 (セクション 4)
そして安全性の評価 (セクション 5)、に分解した。
ワーク
図 6.15: 要求仕様の記述
これらの各問題は同時並列的に検討が可能であり、6.16 右側のウインドウ内の設計過程構
造グラフでは分岐の構造として示されている。各セクションを作成した時点ではまだ何も記
述されていないので、設計者は設計活動を通してその内容を記述していく。
設計対象のモデリング
セクション 2 において、設計者は製品に対する大まかな要求をテキストや各種モデルで表
現した。本例では今回の設計ではレーザー光線を用いたワーク加工機を設計することや、安
全性を考慮する必要があることなどを記述した。またプラガブル・メタモデル機構に接続さ
115
図 6.16: サブ問題への分解
れている 2 次元形状モデラを起動し、大まかなスケッチ作業を行った。このスケッチ上でス
ケッチにおける各部に対して概念名を対応付けた後、スケッチモデルの各データはメタモデ
ル機構へ伝搬される。ここで行われた作業は自動的に文書へ記録され、構築されたモデルは
文書の上へハイパーリンクされる (図 6.17)。
図 6.17: テキスト・スケッチによる要求記述
文書知識の検索
次に設計者は、設計を行う製品について詳しく調査するために文書知識の検索を行った。
DDMS は文書知識を検索するために、この時点でのメタモデルとテキストから設計文脈情
116
報モデルを生成する (図 6.18)。この例では、
「ワーク」が「レーザー」によって加工されるこ
と、
「安全性」を考慮する必要があること、などが文脈としてモデル化されている。また設計
行為として「提案」が文脈情報の中に記述されている。この文脈とマッチする文書知識が検
索され、類似度の高い順にランクを付けされて提示されるので、設計者は今回の設計に最も
適した文書知識を選択することができる。本例の場合、加工機の設計事例が検索され、その
中でもレーザーによる加工機の提案に関する文書知識に高いランクが付けられた (図 6.19)。
図 6.18: 設計文脈情報モデルの生成
文書知識の利用
選択された文書知識はその内容が現在編集中の設計文書にコピーされるので、設計者は文
書知識に記述されたテキスト情報やハイパーリンクされた図表モデルなどの設計情報を再利
用することができる。
このように DDMS を用いることによって適切な文書知識を検索・再利用しながら，設計
と同時に文書作成を行うことが可能である。
117
図 6.19: 文書知識の検索
6.2.3
建築基礎構造物の設計例
ある建設会社で実際に行われた建築物の基礎構造物 (以下、基礎構造と呼ぶ) の設計の一
部である。この設計の特徴は、設計対象の基本的な構造はいくつかの定型的パターンに分類
できるものであり、設計作業は建設地の地盤の解析が中心であることである。
要求仕様および設計条件の記述
本事例では、設計に先立って基礎構造に求められる要求仕様および建設地の地盤の情報が
設計条件として与えられている。設計者はまず文章上にセクションを作成し、その中に、基
礎構造の要求仕様として「構造安定性の基準を満たしつつできるだけ安くしたい」ことや
「表層の地盤は脆いこと」、また地盤の層構造を記述した 2 次元の形状モデルを地盤の情報と
して記述した。図 6.20 にこの時のシステムの様子を示す。このモデルへは自動的に文書か
らのハイパーリンクが構築される。また、このモデルはメタモデルへの最初の入力となる。
基礎構造のタイプの検索
次に設計者は、今回の設計事例の状況に則した基礎構造のタイプを決定する作業に移った。
設計者は仕様を記述したセクションに続くセクションを新たに作り、その中で基礎構造に関
する文書知識を検索するために”Base” というキーワードを設定して検索を開始した。この
際にシステムは、これまでに記述されているテキスト情報およびメタモデルから今回の事例
118
図 6.20: 要求仕様および設計条件の記述
119
の状況を示す設計文脈情報モデル (図 6.21) を生成し、このモデルとマッチした文書知識の
設計文脈情報モデルとの比較を行って各知識に点数付けを行った。その結果、図 6.22 に示
すように 4 つの知識が提示された。今回の場合は「表層の地盤は脆いこと」が文書上に記録
されているので、「地盤が脆い」という文脈にマッチしたタイプの基礎構造についての文書
知識が上位に表示されている。しかし、様々な基礎構造のタイプについて検討を加えること
を考え、ひとまず提示された 3 つのタイプを全て採用することにした (残りの 1 つの知識は
基礎構造の評価に関する知識であり、今回の検索意図にそぐわないので採用されなかった)。
また、このときに文書知識の文脈モデルによって設計者が意識していなかった設計意図が提
示されているので、設計者が適当と思うものを選択すると文書に自動的に記述される。
図 6.21: 文書検索時に構築された設計文脈情報モデル
120
図 6.22: 検索によって提示された文書知識
121
図 6.23 の様に各文書知識には基礎構造の形状モデルがハイパーリンクされており、今回
の設計にも使用できる。また、基礎構造に関する説明のための図もハイパーリンクされてお
り、参照可能である。
図 6.23: 基礎構造タイプの形状モデルと参照情報
評価項目の検索
次に各基礎構造タイプの比較検討を行うために、提示された 3 つのタイプの中の 1 つの
基礎構造の評価を開始した。基礎構造の評価に関する文書知識を検索すると、図 6.24 のよ
うに一件の文書知識が提示された。この知識は基礎構造を評価するには構造健全性、機器の
搬入、許認可、製造可能性、コストの各項目について検討する必要があり、構造健全性に関
しては常時および地震時の検討が必要であることを示している。この知識を選択すると、図
122
6.25 のようにこの文書知識が持っていたセクションの論理的構造が自動的に構築される。
図 6.24: 提示された文書知識
基礎構造の評価の開始
システムが文書上に自動的に作成したセクションに従い、まず基礎構造の構造健全性につ
いての評価を開始した。評価にあたっては、基礎構造の情報だけではなく、基礎構造が構築
される地盤の情報も必要である。メタモデルにはそれぞれの形状モデルが入力されている
が、分離した 2 つの形状モデルとして存在しているのでこれらを 1 つの形状モデルにまとめ
る。この作業は 2 次元作図モデラ上でユーザが行う (図 6.26)。また、この形状モデルは保存
されモデルは文書上にハイパーリンクされる。この形状モデル上での変更はメタモデルに伝
搬される。
123
図 6.25: 自動的に構築されたセクションのツリー
124
図 6.26: 地盤および基礎構造のモデルの結合
125
基礎構造の定性的挙動の評価
地盤と基礎構造が一つに統合されたモデルの定性的な挙動を調べるため、定性推論システ
ムを用いて推論を行った。この推論によって地盤と基礎構造のモデルに発生する可能性のあ
る物理現象をすべて導出できる。導出された物理現象は図 6.27 のようにリストとして提供
される。リスト内の物理現象の中から、設計者は検討すべき物理現象を選択することができ
る。このように定性推論を用いることによって、検討すべき物理現象のリストを推論を行っ
た時点でモデルに応じて作成することができる。この例では、設計者は上部構造物の圧密沈
降を検討する必要があるとして選択した。システムはメタモデルの中の物理現象概念間の因
果関係をたどって、各地盤間での圧密現象を検討する必要があることを提示した。設計者が
これら全ての現象を検討することを受け入れると、システムは各物理現象を検討するための
セクションを新たに構築する。
数式による評価
物理現象を検討するために作成された各セクションでは、設計者は物理現象を定量的に評
価する。圧密現象を検討するための知識を検索すると、数式による評価法が提案されたの
で、これを採用した。設計者は必要な属性値を文書中に記述し、数式処理システムを起動し
てセクション内の数式の処理を行う。数式処理の結果は図 6.28 のように文書に自動的に記
録される。ここで使用した属性値はメタモデル機構で管理されることになる。以降同様に、
検討する物理現象の決定とその定量評価というサイクルで基礎構造の評価作業を行う。
他の基礎構造タイプの評価
他の基礎構造タイプの評価も同様に行われる。図 6.29 のように、基礎構造タイプの検索時
に分岐したセクションまで戻ると、このセクションの直前のセクションであるセクション’1’
の情報のみが有効となり、最初の基礎構造タイプの評価において設定された情報は参照され
なくなる。つまり、セクション’1’ の地盤のモデルのみが他の基礎構造の評価セクションと共
有でき、各基礎構造における属性値などは参照されなくなるのである。ここであらためて、
2 番目のタイプの基礎構造のモデルを構築し、その評価を開始することができる。
126
図 6.27: 物理現象リスト
127
図 6.28: 数式による評価
128
図 6.29: 別のタイプの評価の開始
129
システムの検証
6.3
6.3.1
DDMS における知識獲得
本章では、DDMS の持つ特徴の一つである情報獲得能力について考察する。DDMS によっ
て作成される文書は、可能な限り多くの設計過程の情報を含む。この情報獲得能力を評価す
るために、著者らは 6.2.3 節で述べた建築物基礎構造設計事例で実際の設計活動において設
計者が作成した文書に含まれる情報量と、DDMS によって作成される文書の情報量の比較
を行った。この事例を利用したのは、比較の対象となる設計文書が実際の事例で作成されて
おり、DDMS を利用した場合と利用しなかった場合とで情報量の比較が可能であると考え
られるからである。
表 6.2 に、この比較の結果を示す。具体的に比較を行ったのは、文書中に記述された文字
数、属性値の数、図表の数およびモデルの数である。
この結果によれば、DDMS によって行われる文書化作業は、通常の文書化作業よりも多
くの情報を獲得することができることが分かる。この理由は、DDMS の以下の特徴によっ
て説明できると考えられる。
表 6.2: 文書に記述された情報量の比較
情報種
文字
属性値
図表
モデル
手動作成の文書
約 720
21
4
0
DDMS によって作成された文書
DDMS によって記録された情報設計者が記述した情報
約 3300
約 700
18
78
4
0
3
4
1. 結果の情報だけでなく、設計過程の情報も記録している
2. 途中で破棄された設計案の情報も記録している
3. 設計中にユーザが計算機を通じて得た参照情報を、ハイパーリンクで文書中に記録して
いる
4. 設計作業で構築されたモデルを、ハイパーリンクで文書中に記録している
特に 4 は、通常の紙を用いて整理される設計文書では困難であり、本システムで作成した
設計文書の特徴的な点である。過去の設計において構築されたモデルに簡単にアクセスする
130
ことができるために、過去の設計を部分的に編集するような設計を容易に行うことができる
と考えられる。またこのような設計文書の作成は、通常の CAD システムを用いた設計では
困難である。DDMS におけるこうした設計過程の情報を獲得する能力は統合設計支援環境
である KIEF の持つ強力な機能に拠っていることも指摘できる。つまり、KIEF には種々の
設計作業を支援するためのモデル推論システムが統合されているので、設計作業全体を計算
機上で行うことができ、設計作業で利用される情報を獲得することが容易となっている。ま
た、KIEF はメタモデルという論理モデルを中心に複数のモデル推論システムを統合してい
るため、これらのモデル推論システムを利用して進められる設計作業をメタモデルへの操作
として表現、獲得することができる。通常の CAD システムは幾何モデルを中心にしている
ため、DDMS を接続したとしても幾何操作しか獲得することができず、全ての設計過程の
情報を獲得することは難しいと言わざるを得ない。
企業で設計業務に従事している技術者に、本システムの評価をしてもらったところ、設計
作業と同時に種々の設計情報を記録できる点を評価された。しかし同時に、設計者が設計の
間に情報を大量に記録するのを退屈であると感じるかもしれない点を指摘された。このオー
バーヘッドの評価については、今後の検討課題であると考えている。
一方で、DDMS で作成している文書は通常企業で作成する文書とは異なっていることも
指摘された。通常の企業の業務で作成、利用される文書は業務報告書や特許申請書など特定
の目的をもって記述されるものである。これらの文書は設計過程で生成された情報を利用し
て作成されるものであるが、設計過程で利用されている情報以外の情報、例えば特許申請書
では比較対照となる従来の技術に関する情報なども記述されている。特定の目的に応じて情
報を追加することによって共有・再利用すべき情報を補完的に獲得するために、DDMS で
獲得した設計過程の情報から特定の文書を生成することを支援する枠組みが有用であると考
えられる。
6.3.2
従来研究との比較
次に従来研究との比較を表 6.3 のようにまとめ、DDMS の特徴を考察する。
CATIA など、1.2.3 節で述べた 2 次元および 3 次元の幾何モデルを中心とした設計知識管
理システムはあくまでも幾何情報が中心であり、その他の製品情報を付加的に扱うことはで
きても、設計の背景情報を十分に扱うことができない。この種のシステムで設計知識管理を
実現するためには、DDMS で利用した KIEF システムにおけるメタモデルのように位相的
131
接続情報や各種属性、生起する可能性のある物理現象などを扱うモデルを幾何モデルの背後
に用意し、また設計過程を扱う枠組みを用意する必要があると思われる。またこの種のシス
テムには一般に、知識獲得や知識検索を支援する枠組みが不足しており、その支援を考慮す
べきである。
Lotus Notes などのグループウエアを用いれば、ワードプロセッサと CAD との統合環境
を構築し、CAD 上で設計作業を行いながら設計者のコメントなどを文書に記述していくの
は可能となる。またグループウェアのファイルサーバ機能を活用することにより、収集した
文書を複数の設計者間で共有することも可能である。しかし、文書作成作業自体は人間が手
作業で行う他なく、計算機による十分な支援が行われているとは言い難い。このため、設計
者にとっては大変負担の大きい作業となっていた。DDMS は統合設計支援環境 KIEF のフ
ロントエンドとして機能することで製品に関する種々のモデルを扱うことができるだけでな
く、KIEF における設計過程の情報を扱うことができる。また KIEF における知識操作を自
動的に文書に記録することで知識獲得を支援することが可能である。これらの点で DDMS
は従来の CAD システムおよびグループウェアを利用したシステムとは大きく異なるもので
ある。
設計根拠の研究に関してはその獲得方法の観点から DDMS との比較を行うことができる。
2.2.3 節で述べたように Garcia[Garcia92] は設計根拠の獲得方法を、モデルベース、議論ベー
ス、行為ベースの 3 つに分類したが、DDMS のアプローチはこれら 3 つのアプローチを統合
し、各利点を取り入れたものと言える。つまり、DDMS ではメタモデルを中心として進め
られる設計作業の設計根拠を扱っているためモデルベースであり、Web 上で設計文書を配布
することにより地理的あるいは時間的に離れた設計者間でのコミュニケーションを実現する
点で議論ベースであり、その設計文書を設計作業と同時に獲得するので行為ベースである。
次に、2.1.4 節で述べた文書管理システム ConceptBase および KIDS との比較を行う。
ConceptBase は自然言語処理技術を用いた強力な検索エンジンであり、大量に蓄積された
文書から必要な知識・情報を取り出すのに有効である。しかし ConceptBase そのものは知
識・情報の獲得を支援するものではない。また ConceptBase は、設計支援環境と統合され
ていないため設計知識を管理する枠組みとしては不十分であると考えられる。
KIDS では各ノウハウはテキスト情報として獲得され、形態素解析と簡単な構文ルールを
用いることにより検索キーワードを抽出したり、知識の条件部にあたる部分と知識本体を分
割するなど、構造化された知識に変換される。一方 DDMS では文書知識の条件部にあたる
132
設計文脈情報をより正確にモデル化するために、単に文書に記述された情報のみを知識とし
て扱うのではなく、製品のメタモデルと文書のテキスト情報から設計文脈情報モデルを自動
的に生成している。また KIDS 自体は知識の基となるテキスト情報の獲得を支援するもので
はなく、ユーザ各自が自分の知識を外在化する労力を払ってシステムに入力する必要がある
のに対し、DDMS では設計作業と同時に文書を作成し知識を獲得することができる。
表 6.3: 従来研究との比較
LotusNotes
モデルベース
Design Rationale 研究議論ベース
行為ベース
ConceptBase
KIDS
DDMS
設計過程の情報
設計対象のモデル
設計過程のモデル
×
○
×
○
○
×
○
○
○
○
×
○
○
×
×
○
×
×
○
×
×
○
○※
○
知識獲得
統合設計支援環境
設計作業と同時に獲得
多様な設計情報を管理
×
×
×
×
×
○
×
×
×
×
×
○
×
○
×
×
×
×
×
×
×
○※
○
○
知識検索
知識の構造化
検索要求記述の的確さ
検索要求記述の容易さ
×
×
×
×
×
×
○
×
×
×
×
×
×
×
×
×
○
○
○
○
○
○
○
○
× ○ × × ×
※：KIEF の機能を用いることにより実現
○
○
○
知識配布
文書管理システム
CATIA
管理の対象
ところで設計知識管理に関する研究は、設計対象および設計過程のモデルを持っているか
否かによって大きく 2 つに大別される。この 2 つの研究アプローチの違いを Devlin の会話モ
デルによって説明する。Devlin の会話モデル (図 6.30) は、会話に参加している 2 人の人間
133
(A と B) がある議題 (S) について議論するために知識を共有する様子をモデル化したもので
ある [Devlin01]。A および B はそれぞれ固有の知識やスキル (Delvin はこれを background
と呼んでいる) を持っているが、会話を成立させるためには議題に関する共通の background
つまり common ground を足場にし、common ground に基づいてお互いの知識を提供し合
う必要がある。
例えば、飛行機のパイロットと飛行場の管制官との間の会話を考える。飛行機を飛行場
に誘導するため、管制官がパイロットに Are you holding? と質問し、パイロットが Roger,
we’re holding. と答えたとする。しかしこれだけでは、飛行機が安全に着陸するために交わ
されるべき会話としては不充分である。なぜなら holding という言葉が「高度を維持する」
ことを意味するのか、「高度降下を維持する」ことを意味するのか合意が取れていなければ
ならないからである。
S
about
BA
A
G
BB
B
A, B : participants of conversation
BA : background (indivisual knowledge, skills,
experience) for A
BB : background for B
S : focal situation (being discussed)
G : common ground (common knowledge)
図 6.30: 会話モデル
設計知識管理研究におけるモデルの役割は common ground を提供することにあると考え
られる。つまり、CATIA、あるいは Design Rationale 研究では設計対象および設計過程の
モデルを用意することによってユーザが提供する情報の自由度は落ちるものの、知識共有の
ための common ground を提供するものと考えることができる。一方、一般のグループウェ
アや文書管理システムは、モデルを用意しないことによって管理する情報の自由度を高め、
134
システムのユーザが common ground を構築する場を提供するものである。
DDMS は KIEF やシンセシス推論フレームワークを利用して、文書作成を支援し、設計
者が様々な情報を文書上に記録する枠組みを提供している。つまり、モデルによる common
ground を提供しながら、ユーザによる common ground 形成の自由度も残したものである
と考えられる。
135
136
第 7 章考察
7.1
設計作業と同時に行う知識獲得について
本研究では知識獲得を設計者の経験を獲得することであるととらえ、設計後では獲得が困
難な設計過程における様々な情報の獲得方法として、設計作業と同時に設計情報を獲得する
方法を提案した。この方法によって、設計結果の情報だけではなく、設計過程における様々
な情報を獲得することができた。このため実際に設計作業を行った設計者の知識やノウハウ
を獲得、管理し、他の技術者との間で共有・再利用可能になるものと考えられる。
ここで本研究における情報獲得方法を一般の設計文書作成作業と比較して考える。通常は
設計文書の作成は設計作業が終了した後に行われるものである。設計作業中に同時並列的に
文書化作業を行う場合、例えば 3 次元ソリッドモデラを用いながら、ワープロで設計対象に
関する説明の文書を作成することも当然考えられるが、その場合でもあくまでも主となる作
業はソリッドモデリングであり、文書作成作業は副次的な作業である。このために、文書に
記録される情報にはどうしても欠落が生じるのは致し方のないことである。これに対して、
本研究においては文書作成作業の結果として設計作業が進行している。つまり従来の考え方
とは基本的に異なるものであり、このために設計過程における情報を可能な限り獲得できる
可能性がある。
しかし設計過程における情報を可能な限り獲得することで従来の設計作業よりも時間がか
かり、設計作業の効率が落ちる可能性がある。このため、獲得する情報量の増加と情報獲得
にかかる時間の増加との間のトレード・オフについて十分に検討する余地は残されている。
また本研究では統合設計支援環境における設計作業を自動的に文書化し、設計者の負担を
軽減することにより、設計者が自らコメントなどを記述する機会を増やそうと試みた。これ
は設計者が文書に記述するモチベーションを上げるための試みであったが、この他の方法に
ついても検討する余地がある。例えば、3.2.3 節で述べたメタプロセスモデルの進化による
情報獲得を実装することも有効であろう。またシステムと設計者との間の対話性を上げるこ
とも考えられる。
また設計中に獲得する情報は熟練した設計者にとっては必要のない情報ばかりで、設計作
業中に文書を作成することがかえって設計作業の効率を落す可能性もある。この点の検証に
ついては本研究で開発したシステムを実際の設計作業で使用してもらって、設計者に感想を
求めなければ確認できないが、少なくとも情報の共有・再利用という観点からは、設計過程
における情報が不十分なために知識やノウハウの管理ができない、という事態を避けること
はできると考えられる。
138
7.2
メタプロセスモデルのコーディングの自動化について
本研究で構築した設計知識管理システムでは設計作業と同時に知識操作でコーディングさ
れた設計文書を作成することによりメタプロセスモデルを構築し、設計過程の知識を獲得す
る。ところで実際に企業では文書の形態ですでに大量の知識が蓄積されているものと考えら
れる。これらの知識を本研究で構築したシステムを用いて管理するためには、すでに記述さ
れた文書からメタプロセスモデルをコーディングする必要があり、その自動化が求められる
ところである。そこで形態素解析や構文解析など自然言語処理技術を用いてメタプロセスモ
デルのコーディングを行うことが考えられる。その試みについて簡単にふれる。
7.2.1
手法
設計文書から人の手によって知識操作モデルを構築する際にキーとなるのは、文書中の記
述のチャンクに対して設計の基本語彙を割り当てる作業である。これができれば、節で述べ
た変換ルールを逆向きに使うことによって情報の導出関係が得られる。
ここで各基本語彙が割り当てられる記述中の単語の出現頻度には何らかの特徴があると考
えられるので、形態素解析および tf·idf 法 [Ingwersen95] による重み付けにより、各設計語
彙に対する単語の出現頻度表を生成することを考える。
tf· idf 法は情報検索において検索語の適合性に重み付けする手法の代表的なもので、ある
単語 t が出現する文書におけるその語の相対出現頻度 tf(d,t) と文書集合における単語 t の逆
文書頻度 idf(t) の積であらわされる。tf(d,t) および idf(t) は以下の式で計算される。
tf
M (d)
log N
n +
tf (d, t) =
idf (t) =
1
ここで、
tf:ある語 t がある文書 d 中に現れる頻度
M(d):文書内の形態素数
N:データベース中の文書数
n:単語 t が現れる文書数
である。
idf(t) はある語 t が一部の文書に集中している度合を表しているので，tf·idf はある語 t が
ある文書 d を弁別する能力を表している。そこでまず上記式における d を設計の基本語彙
139
が対応付けられた設計文書上の記述のチャンクとし、各基本語彙に対する単語の出現頻度表
を生成する。次に、別の文書における各記述のチャンク内に出現する単語を調べることによ
り、対応する基本語彙を推定することとする。
7.2.2
実験と結果
手動によるコーディングが終わっている設計文書を元に単語の出現頻度表を作成し、これ
を別の設計文書に適用することによってコーディングを行ってみた。実験には、3.3.1 節で
述べた光造型機の設計事例に関する二つの特許申請書を用いた。まず基本語彙を対応付ける
記述のチャンクを決定する。特許文書には、あらかじめ段落番号が振られているので、この
各段落を一つのチャンクとした。次に一方の特許文書 (特許文書 1) を手動で分析した結果を
元に、特許文書 1 を形態素解析して各基本語彙に対する単語の出現頻度表を生成し、さらに
この事例に関する別の特許文書 (特許文書 2) に適用してみた。適用結果と、人間が手動で分
析した場合に対応付けられる結果とを比較することにより、この手法の妥当性を判断する。
「できる」や
図 7.1 に特許文書 1 から生成された出現頻度表を示す。例えば「評価」では、
「十分」といったものが特徴的な単語であることが分かる。また図 7.2 にこの出現頻度表を元
に特許文書 2 の各記述チャンクに対応する可能性のある基本語彙のランキングを示す。ラン
キングの元となっている数値は図 7.1 の出現頻度表に示された単語の頻度値の合計である。
この結果によれば、本手法によって基本語彙の対応付けを自動的に行うことが概ね可能であ
ることが分かる。しかし出現頻度表に現れる単語には「インクジェット」「マスク」など事
例固有の語も多く、他の事例に適用可能かどうかは不明である。より正確な出現頻度表の作
成のためにはもっと大量の文書が必要であると思われ、今後の研究課題である。
図 7.1: 各基本語彙に対応する記述における単語の出現頻度表
140
図 7.2: 基本語彙を対応付けた特許文書
141
7.3
設計知識管理と設計のモデル化について
本研究では設計過程を記述する際のモデルとして知識操作および設計の基本語彙に基づい
た枠組みを利用した。この枠組みにより、設計過程の明示的な記述や知識検索のための設計
文脈情報モデリングなど、知識管理を有効に行うことができた。2.4 節で述べたように知識
操作および基本語彙は、設計作業に関する一般的なモデルを構築して、設計者の知的創造行
為を支援する CAD を実装しようとする研究から生み出されたものである。しかし Blessing
が述べているように、このような設計のモデル化は様々なグループによって試みられている
ものの、いまだ一般的に受け入れられるモデルの構築にはいたっていない [Blessing95]。そ
の理由の一つとして、設計のモデルは物理学や機械工学などのモデルとは違って数学的な定
式化が困難であり、客観的にモデルを評価することができないことが上げられる。
この問題を解決するため、吉岡らは設計作業における設計者の知識操作を数学的に定式化
する試みを行っている [Yoshioka01b]。この研究は吉川ら一般設計学 [Yoshikawa79] の流れ
を受けており、設計者が持つ知識を実体概念の分類としてとらえ、実体概念を要素とする集
合によってモデル化した上で、集合に対する操作として知識操作を定式化している。このよ
うな定式化によって知識操作や設計の基本語彙が裏付けられれば、設計知識管理の研究にも
大いに貢献されるものと考えられる。
142
第 8 章結論
8.1
本研究の結論
本研究の目的は特に設計活動を支援する立場で知識管理を実現する方法を明らかにし、計
算機システムへの実装および例題の実行を通してその検証を試みることであった。このため
本研究は以下の点を行った。
• 管理の対象として、設計結果の情報だけでなく設計意図や設計中に参照した情報を考
える。このため設計過程中の多様な形態の設計情報およびそれらの間の関連を表現す
るための枠組みとしてメタプロセスモデルを提案した。メタプロセスモデルは知識操
作によってコーディングされ、どの情報からどの情報が導き出されるのかという情報導
出を記述したものである。メタプロセスモデルによって思考錯誤の過程を含む設計過
程を記述できた。また、メタプロセスモデルのブラウザとしてハイパーテキストを採
用することにより、多様な設計情報をハイパーリンクで記録することが可能であった。
• 設計後では収集が困難な設計過程の情報を容易に獲得、管理するために、設計を行い
ながら設計文書を作成する枠組みを提案した。具体的には、統合設計支援環境である
KIEF とハイパーテキスト文書作成ツールとを統合して KIEF 上で設計作業を行いな
がら設計者が設計文書を作成することを可能にした上で、KIEF の操作からメタプロ
セスモデルを自動生成し、自然言語への変換ルールを適用することで KIEF 上の設計
作業から自動的に設計文書を生成し、設計者の文書作成作業にかかる負担を軽減する
ことを可能とした。
• 設計知識を効果的に検索し、その共有・再利用を行うための手法として、設計文脈情報
モデルを利用した検索を提案した。設計文脈情報モデルは KIEF のメタモデルと文書
上に記述されたテキスト情報とから生成されるグラフとして表現される。検索対象と
なる知識にも、設計文脈情報モデルをインデックスとして付与しておくことで、設計
文脈を考慮した知識検索をグラフのマッチングによって実現することが可能となった。
• 提案した手法に基づいてシステムを実装、例題の実行を通して本研究で提案した手法
の有効性を検証した。さらに関連研究において開発された各システムとの比較を通じ
て、本研究の特徴を明らかにした。
以上の手法を実装したシステムとして DDMS を開発した。DDMS 上で実際に設計を行っ
てみることにより、上記の各手法の検証を行い、その有効性を確認した。
144
8.2
展望
最後に本研究の展望について述べる。
• 既存の設計文書からの知識獲得
本研究で開発した DDMS を用いて設計作業を行えば設計と同時にその過程で利用さ
れる知識やノウハウを獲得することが可能である。しかし実際の企業には、すでに通
常のワープロソフト等で作成された設計文書が大量に蓄積されているものと考えらえ
れる。これらの文書を DDMS で管理可能な形態に変換することで、より柔軟な知識
管理が実現可能であると考えられる。
• 設計のモデル化に関する研究との連携
本研究で提案した設計知識管理の方法論は、知識操作モデルに立脚したものであった。
設計知識管理の実現のためには、こうした設計のモデル化に関する研究との連携が欠
かせないと考えられる。
• 複数の設計者が協調して進める設計作業の支援
本研究で開発した DDMS は Web ブラウザ上で動作可能なアプリケーションとして実
装されている。サーバに蓄積された文書知識を利用して設計作業を進め、またその設
計作業で作成された文書から文書知識を作成することによって複数の設計者の知識を
共有・再利用することができた。しかし、現在は同時にサーバにアクセスすることが
できる設計者は一人に限られているために、本研究の共有・再利用は静的なものにと
どまっている。そこで、複数の設計者が協調して進める設計作業の支援を行って、知
識の動的な共有・再利用を目指すことが考えられる。
145
146
謝辞
本研究を進めるにあたり、多くの方々から御協力と御助言を頂きました。特に指導教官で
あられる冨山哲男教授には、卒業論文の指導から６年にわたり厳しくも温かい御指導を頂き
ました。ここに深く感謝致します。
下村芳樹助教授には研究上の数々の貴重な助言を頂いただけでなく、普段の学生生活にお
いてもお世話になりました。大変感謝しております。
東京都立大学の梅田靖助教授には、研究会やミーティングを通じて、多くの御助言を頂き
ました。大変感謝しております。
北海道大学の吉岡真治助教授には、システム開発の方針から研究の進め方まで様々なアド
バイスを頂きました。大変感謝しております。
「シンセシスのモデル論」プロジェクトにおける議論は、本研究を進める上で大変有意義
なものでした。プロジェクトのメンバーであった東京大学の村上存助教授、桐山孝司助教授、
Ralf Lossack 氏、Ken Pin Hew 氏、大阪大学の鷲尾隆助教授、蔵川圭氏、妻屋彰氏、国立
情報学研究所の武田英明助教授、東京都立大学の近藤伸亮氏には大変感謝しております。
東京大学の木村文彦教授、西田豊明教授、鈴木宏正助教授には本論文をまとめるにあたっ
て貴重な御助言を頂きました。大変感謝しております。
情報基盤センターの関谷貴之氏には本研究に関する議論にお付き合い頂いたばかりか、研
究の進め方や計算機に関することなどささいな質問にも丁寧に答えて頂き、お世話になりま
した。大変感謝しております。
清水建設の社本康広氏には、6.2.3 節で述べた建築物の基礎構造の設計事例やデータを提
供して頂いたばかりでなく、卒業論文および修士論文に取り組む間、数々の貴重なアドバイ
147
スを頂きました。どうも有難うございました。
住友電工の布施雅義氏、西出裕氏、三宅秀一氏、藤崎正一郎氏には 6.2.2 節で述べた加工
機の設計事例に関する資料を提供していただきました。どうも有難うございました。
研究室の同期である村井章人君、佐藤ロベルト清君および野々村彰君には、研究生活の合
間の雑談や息抜きにつきあって頂きました。彼らとは今後も良き友人でありたいと思ってお
ります。
坂井宏充君には本論文 3 章で述べた設計文書の分析を手伝って頂きました。どうも有難う
ございました。
最後になりましたが、研究生活を陰で支えて下さった秘書の辻口るみさん、立入菜生子さ
ん、横山ルミ子さん、小笠原由紀さん、片桐淳子さん、腰塚みなこさん、藤本麻里子さんに
は大変感謝しております。みなさん、本当に有難うございました。
148
参考文献
149
関連図書
[Berlin90]
L. Berlin and V. O’Day: Platform and Application Issues in MultiUser Hypertext, In in Gibbs S., and Verrijin-Stuart, A. A. (eds.), pp.
293–309, Proceedings for the IFIP WG 8.4 Conference on Multi-User
Interfaces and Applications (1990).
[Blessing95]
L. T. Blessing: Comparison of Design Models Proposed in Prescriptive
Literature, In The role of design in the spaping of technology, COST
A3/COST A4 Internatinal research workshop, pp. 187–212 (1995).
[Bok99]
K. Bok, S. Myung, and S. Han: Lens Barrel Design Based On Distributed Knowledge-Base, In T. Tomiyama, M. Mäntylä, and S. Finger(eds.): Knowledge Intensive CAD-3, pp. 255–271, Chapman & Hall
(1999).
[Conklin88]
J. Conklin and M. Begeman: gIBIS: A Hypertext Tool for Exploratory
Policy Discussion, ACM Transaction on Office Information Systems,
Vol. 6, No. 4, pp.303–331 (1988).
[Crabtree97]
R. A. Crabtree, M. Fox, and N. K. Baid: Case Studies of Coordination Activities and Problems in Collaborative Design, Research in
Engineering Design, Vol. 9, No. 2, pp.70–84 (1997).
[Cutkosky93]
M. R. Cutkosky, R. S. Engelmore, R. E. Fikes, M. R. Genesereth, T. R.
Gruber, W. S. Mark, J. M. Tenenbaum, and J. C. Weber: PACT:
An Experiment in Integrating Concurrent Engineering Systems, IEEE
COMPUTER, Vol. 26, No. 1, pp.28–37 (1993).
150
[de Kleer86]
J. de Kleer: An assumption-based TMS, Artificial Intelligence, Vol. 28,
pp.127–162 (1986).
[Devlin01]
K. Devlin:
Infosense – Turing information into knowledge,
W.H.Freeman and Company (2001).
[Dieng00]
R. Dieng: Knowledge Management and the Internet, IEEE Intelligent
Systems, pp. 14–17 (2000).
[Forbus84]
K. Forbus: Qualitative Process Theory, Artificial Intelligence, Vol. 24,
No. 3, pp.85–168 (1984).
[Fruin97]
W. M. Fruin: Knowledge works : managing intellectual capital at
Toshiba, New York : Oxford University Press (1997).
[Fukuda01]
福田剛志, 森本康彦, 徳山豪: データマイニング, 共立出版 (2001).
[Gamma95]
E. Gamma, R. Helm, R. Johnson, and J. Vlissides: デザインパターン,
本位田真一／吉田和樹訳、Soft Bank (1995).
[Garcia92]
A. C. B. Garcia and H. C. Howard: Acquiring Design Knowledge
Through Design Decision Justification, Artificial Intelligence for Engineering Design, Analysis and Manufacturing, Vol. 6, No. 1, pp.59–71
(1992).
[Genesereth92]
M. Genesereth: Knowledge Interchange Format, In J. Allen, R. Fikes,
and E. Sandwall(eds.): Proceedings of the Conference of the Principles of Knowledge Representation and Reasoning, Morgan Kaufmann
Publishers (1992).
[Gruber92]
T. R. Gruber: Ontolingua: A mechanism to support portable ontlogies,
Technical report KSL91-66, Knowledge Systems Laboratory, Stanford
University, Stanford (1992).
[Haake92]
J. Haake and B. Wilson: Supporting Collaborative Writing of Hyperdocuments in SEPIA, In Proceedings of the Conference on ComputerSupported Cooperative Work (CSCW’92), pp. 138–146 (1992).
151
[Ingwersen95]
P. イングベルセン: 情報検索研究−認知的アプローチ−, トッパン (1995).
[Inoue92]
井上克巳: アブダクションの原理, 人工知能学会誌, Vol. 7, No. 1, pp.48–
59 (1992).
[Ishida00]
石田厚子: ナレッジマネジメント, ビジネスオブジェクト推進協議会ニュー
ス 2000 年 10 月号 (http://www.cbop.gr.jp/Kaiho/200010/Kaitop.htm)
(2000).
[Ishii93]
石井理貴: 物理現象の定性的因果関係に注目した概念設計支援, 東京大学
工学部精密機械工学科修士論文 (1993).
[Ito98]
伊藤聡, 山口高平: オントロジーとエンタープライズモデル, 人工知能学
会誌, Vol. 13, No. 6, pp.870–879 (1998).
[Iwata95]
岩田一明, 荒井栄司, 小野里雅彦, 薮崎清ヒベルト: 設計・生産における
コンカレントエンジニアリングのためのコミュニケーションシステムに
関する研究 (第 1 報; 複数ユーザ間での会話モデルに基づくコミュニケー
ションシステムの表現), 日本機械学会論文集 (C 編), Vol. 61, No. 584,
pp.1734–1735 (1995).
[Justsystem]
ジャストシステム:
ConceptBase
サイト
(http://www.justsystem.co.jp/cb/).
[Kamimura00]
神村: 冷却個化式光造型法に関する研究, 東京大学大学院工学系研究科産
業機械工学専攻平成 12 年度博士論文 (2000).
[Kimura93]
木村文彦, ほか: 特集プロダクトモデルと CAD データ交換標準 STEP,
精密工学会誌, Vol. 12, pp.1917–1954 (1993).
[Kizaki01]
木崎健太郎: CATIA V5, 2001 年に V4 機能を整備, 日経エンジニアリン
グ, No. 37, pp.28–29 (2001).
[Kojima96]
小島俊雄, 川端清三: STEP と CALS のかかわり, 精密工学会誌, Vol. 62,
No. 12, pp.1675–1678 (1996).
152
[Kunz70]
W. Kunz and H. Rittel: Issues as elements of information systems,
Working Paper No. 131, Berkeley, University of California, Berkeley,
Institute of Urban and Regional Development (1970).
[Lakin89]
F. Lakin, J. Wambaugh, L. Leifer, D. Cannon, and C. Sivard: The Electronic Design Notebook: Performing Medium and Processing Medium,
Visual Computer, International Journal of Computer Graphics, Vol. 5,
pp.214–226 (1989).
[Matsumoto99]
松本裕治, 北内啓, 山下達雄, 平野善隆: 日本語形態素解析システム『茶
筅』 version 2.0 使用説明書, 松本研究室, 奈良先端科学技術大学院大学
(1999).
[Matsushita93]
松下温: グループウェア実現のために, 情報処理, Vol. 34, No. 8, pp.984–
993 (1993).
[McCarthy80]
J. McCarthy: Circumscription — A Form of Non-Monotonic Reasoning, Artificial Intelligence, Vol. 13, pp.27–39 (1980).
[McGuire93]
J. McGuire, D. Kuokka, J. Weber, J. Tenenbaum, T. Gruber, and
G. Olsen: SHARE: A Methodology and Environment for Collaborative
Product Development, International Journal of Intelligent and Cooperative Information Systems, Vol. 3, No. 2, pp.129–153 (1993).
[Meyrowitz86]
N. Meyrowitz: Intermedia: The Architecture and Construction of an
Object-Oriented Hyper-Media System and Applications Framework,
pp. 186–201, OOPSLA ’86 (1986).
[Moran96]
T. P. Moran and J. M. Carroll: Design Rationale – Concepts, Techniques, and Use, Lawrence Erlbaum Associates (1996).
[Moriarty00]
M. F. Moriarty: 「考える」科学文書の書き方, 朝倉書院 (2000).
[Nakakoji98]
中公路久美代, 高田真吾: 設計における暗黙的根拠の明示化に関する一考
察, 日本機械学会第 8 回設計工学・システム部門講演会講演論文集, pp.
596–599 (1998).
153
[Nakayama98]
中山康子, 真鍋俊彦, 竹林要一: 知識情報共有システム (Advice/Help on
Demand) の開発と実践：知識ベースとノウハウベースの構築, 情報処理
学会論文誌, Vol. 39, No. 5, pp.1186–1194 (1998).
[Nakayama01]
中山康子, 真鍋俊彦, 笹氣光一, 鈴木優: 知識情報共有システム (KIDS) の
開発と実践, 人工知能学会誌, Vol. 16, No. 1, pp.64–68 (2001).
[Neches91]
R. Neches, R. Fides, T. Finin, T. Gruber, R. Patil, T. Senator, and
W. R. Swartout: Enabling technology for knowledge sharing, AI Magazine, Vol. 12, No. 3, pp.36–56 (1991).
[Nonaka95]
野中郁次郎, 竹内弘高: 知識創造企業, 東洋経済新報社 (1995).
[Okada93]
岡田公治, 荒井栄司: 機械設計における設計意図伝達のための形状特徴,
日本機械学会論文集 (C 編), Vol. 59, No. 9, pp.2890–2897 (1993).
[Okada99]
岡田久豊: 設計支援システムの軌跡 –コンピュータグラフィックスから知
的設計へ, 精密工学会誌, Vol. 65, No. 1, pp.7–12 (1999).
[Pahl88]
G. Pahl and W. Beitz: Engineering Design: Systematic Approach,
Springer-Verlag, Berlin (1988) (設計工学研究グループ訳,『工学設計–
体系的アプローチ–』, 培風館, 1995 年).
[PM96]
F. Pena-Mora, K. Hussein, and R. D. Sriram: CAIRO: A system for
facilitating communication in a distrubuted collaborative engineering
environment, Computers in Industory, Vol. 29, pp.37–50 (1996).
[Rein91]
G. Rein and C. Ellis: rIBIS: a Real Time Group Hypertext System,
In in S. Greenberg (eds.), Computer-Supported Cooperative Work and
Groupware, chapter 12, pp. 223–241, Academic Press (1991).
[Sekiya95]
関谷貴之, 石井理貴, 冨山哲男: 知識集約型エンジニアリング環境の構築
(第 2 報) – 知識ベースの構成の提案 –, 1995 年度精密工学会秋季大会学
術講演会講演論文集, pp. 11–12 (1995).
154
[Sekiya99]
関谷貴之, 吉岡真治, 冨山哲男: オントロジーを用いた統合的設計支援環
境の実現, 人工知能学会誌, Vol. 14, No. 6, (1999).
[ShipmanIII97]
F. M. ShipmanIII and R. J. McCall: Integrating different perspectives
on design rationale: Supporting the emergence of design rationale from
design communication, Artificial Intelligence for Engineering Design,
Analysis and Manufacturing, Vol. 11, No. 2, pp.141–154 (1997).
[Siegel96]
J. Siegel: CORBA Fundamentals and Programming, John Wiley &
Sons, Inc., New York (1996).
[Sutherland63]
I. Sutherland:
SKETCHPAD-A man-machine graphical commu-
nication system, In Proc. of Sprint Joint Computer Conference,
IEEE/ACM, pp. 329 (1963).
[Suzuki96]
H.Suzuki, F.Kimura, B.Moser, and T.Yamada: Modeling Information
in Design Background for Product Development Support, In Annals of
the CIRP, pp. 141–144 (1996).
[T. Finin et al.92] T. Finin et al.: Specification of the KQML Agent-Communication Language, Technical report EIT TR 92-04, Enereprise Integration Technologies, Palo Alto, California (1992).
[Takahashi92]
高橋: Approaches to CIM for an Engineering Development Department,
Unisys Technology Review, Vol. 11:4, pp.725–744 (1992).
[Takeda91]
武田英明, 冨山哲男, 吉川弘之: 知的 CAD の開発のための設計過程の分析
と論理による形式化, 精密工学会誌, Vol. 57, No. 6, pp.115–120 (1991).
[Takeda92]
武田英明, 冨山哲男, 吉川弘之: 設計過程の計算可能モデルと設計シミュ
レーション, 人工知能学会誌, Vol. 7, No. 5, pp.877–887 (1992).
[Tomioka00]
富岡恒憲: ノウハウが危ない, 日経デジタルエンジニアリング, No. 30,
pp.70–89 (2000).
[Tomiyama85]
冨山哲男: CAD 構成論, 東京大学工学部精密機械工学科博士論文 (1985).
155
[Tomiyama90]
T. Tomiyama, T. Kiriyama, H. Takeda, D. Xue, and H. Yoshikawa:
Metamodel: A Key to Intelligent CAD Systems, Research in Engineering Design, Vol. 1, No. 1, pp.19–34 (1990).
[Tomiyama94]
T. Tomiyama, Y. Umeda, and T. Kiriyama: A Framework for Knowledge Intensive Engineering, In Proceedings of the Fourth International
Workshop on Computer Aided Systems Technology (CAST’94), University of Ottawa, Ont.,Canada (1994).
[Toye94]
G. Toye, M. Cutkosky, L. Leifer, J. Tenenbaum, and J. J. Glicksman:
SHARE: A Methodology and Environment for Collaborative Product
Development, International Journal of Intelligent and Cooperative Information Systems, Vol. 3, No. 2, pp.129–153 (1994).
[Ueda96]
上田俊彦: 航空機業界における CALS 開発・適用の取組み, 精密工学会
誌, Vol. 62, No. 12, pp.1698–1701 (1996).
[Umeda96]
Y. Umeda, M. Ishii, M. Yoshioka, Y. Shimomura, and T. T. omiyama:
Supporting Conceptual Design Based on the Function-Behavior-State
Modeler, Artificial Intelligence for Engineering Design, Analysis and
Manufacturing, Vol. 10, No. 4, pp.275 – 288 (1996).
[Yabusaki95]
薮崎清ヒベルト, 岩田一明, 荒井栄司, 小野里雅彦: 設計・生産における
コンカレントエンジニアリングのためのコミュニケーションシステムに
関する研究 (人間中心コンカレントエンジニアリングのための対象表現),
日本機械学会論文集 (C 編), Vol. 61, No. 584, pp.1734–1735 (1995).
[Yoshikawa79]
吉川弘之: 一般設計学序説 —一般設計学のための公理的方法—, 精密機
械, Vol. 45, No. 8, pp.906–912 (1979).
[Yoshikawa93]
吉川弘之: テクノグローブ, 工業調査会 (1993).
[Yoshioka96]
吉岡真治: 設計知識操作論, 東京大学工学部精密機械工学科博士論文
(1996).
156
[Yoshioka98]
吉岡真治, 冨山哲男: 設計支援のための統合モデリング環境の研究−プラ
ガブル・メタモデル機構の提案, 人工知能学会誌, Vol. 13, No. 2, pp.312–
319 (1998).
[Yoshioka00]
吉岡真治, 武田英明, 妻屋彰, 村上存, 冨山哲男: 設計活動を表現する語
彙に関する研究 (第 3 報) −情報操作の観点から見た語彙の整理と意味付
け−, 2000 年度精密工学会秋季大会学術講演論文集, pp. 259 (2000).
[Yoshioka01a]
M. Yoshioka, Y. Nomaguchi, and T. Tomiyama: Proposal of an integrated design support environment based on the model of synthesis,
In Proceedings of DETC’01, pp. –, ASME 2001 Design Engineering
Technical Conference and Computers and Information in Engineering
Conference (2001).
[Yoshioka01b]
吉岡真治, 冨山哲男: 設計対象知識操作論, 精密工学会誌, Vol. 67, No. 9,
pp.1490–1496 (2001).
157
158
発表論文
159
関連図書
投稿論文他（査読付）
[1] Y. Nomaguchi and T. Sekiya and Y. Umeda and T. Tomiyama: A Hypertext-based
Design Documentation System for the Knowledge Intensive Engineering Framework.
CIRP 1997 International Design Seminar Proceedings : Multimedia Technologies for
Collaborative Design and Manufacturing, pp.230–239, 1997.
[2] Y. Nomaguchi, T. Tomiyama, and M. Yoshioka:
Document-based Design Process
Knowledge Management for Knowledge Intensive Engineering.
In S. Finger, T.
Tomiyama, and M. Mantyla (eds.): Knowledge Intensive Engineering Computer Aided
Design, Kluwer Academic Publishers, Dordrecht, The Netherlands, 2001.
[3] Masaharu Yoshioka and Yutaka Nomaguchi and Tetsuo Tomiyama: Proposal of an
Integrated Design Support Environment Based on the Model of Synthesis. Proceeding
of the 2000 ASME Design Engineering Technical Conference & Computers and Information in Engineering Conference, The American Society of Mechanical Engineers
(ASME), DETC2001/DAC-21155 (CD-ROM), 2001.
[4] A. Tsumaya, Y. Nomaguchi, M.Yoshioka, H. Takeda, T. Murakami, and T. Tomiyama:
Verification of Synthesis - The Methods for Verification and Results Proceedings of 13th
International Conference on Engineering Design (ICED01), pp. 229–236, 2001.
[5] 野間口大，吉岡真治，冨山哲男: 設計知識管理のための CAD アーキテクチャーの提案.
人工知能学会誌, 第 17 巻 1 号, pp.104–113, 2002.
160
関連図書
講演論文他
[1] 野間口大，関谷貴之，梅田靖，冨山哲男: ハイパーテキストを利用した設計計算書エ
ディタの作成. 1997 年度精密工学会春季大会学術講演会講演論文集. pp.887–888, 1997.
[2] 野間口大，梅田靖，冨山哲男: 設計支援のための設計計算書エディタの実現. 総合試験
所年報，第 56 巻，東京大学工学部総合試験所，pp.73–80, 1997.
[3] 野間口大，関谷貴之，梅田靖，冨山哲男: 設計過程文書化システムの展開. 1997 年度精
密工学会秋季大会学術講演会講演論文集. p.124, 1997.
[4] 野間口大，冨山哲男: 設計文書からのキーワード抽出によるメンタルモデルの構築. 日
本機械学会第 8 回設計工学・システム部門講演会論文集，pp.149–152, 1998.
[5] 野間口大，冨山哲男: Web を利用した設計支援システムのインターフェースの開発. 日
本機械学会第 8 回設計工学・システム部門講演会論文集，pp.309–312, 1998.
[6] Y. Nomaguchi and M. Yoshioka and T. Tomiyama: Knowledge Acquisition by Documenting Design for the Knowledge Intensive Engineering Framework. Alan Bradshaw
and John Counsell (Eds.): Computer Aided Conceptual Design ’99, Proceedings of the
1999 Lancaster International Workshop on Engineering Design, pp.135–163, 1999.
[7] 野間口大，冨山哲男: 設計知識の共有と再利用のための設計文書管理システムの開発.
1999 年人工知能学会全国大会 (第 13 回) 論文集，pp.120–121, 1999.
[8] 野間口大，冨山哲男: 設計過程情報の共有と再利用のための設計文書管理システムの開
発. 第 17 回設計シンポジウム講演論文集，pp.109–112, 1999.
161
[9] 野間口大，冨山哲男: 設計知識の共有・再利用のための設計ドキュメンテーションシス
テムの開発. 1999 年度精密工学会秋季大会学術講演会講演論文集，p.18, 1999.
[10] 野間口大，吉岡真治，冨山哲男: 設計文書からの知識の構造化の手法の提案. 日本機械
学会第 9 回設計工学・システム部門講演会論文集，pp.100–103, 1999.
[11] 吉岡真治，野間口大，冨山哲男: 設計文書作成管理システムの研究. 情報処理学会研究
報告 (SIG-GW)，Vol. 99, No.88, pp.63–68, 1999.
[12] 妻屋彰，野間口大，吉岡真治，武田英明，村上存，冨山哲男: 設計事例分析による設計
過程モデルの比較 (第 1 報) - 設計事例記録の整理 -. 2000 年度精密工学会春季大
会学術講演会講演論文集，p.19, 2000.
[13] 野間口大，H. Kunze，R.S. Lossack，冨山哲男: XML を用いた機能モデリングシステ
ムの統合. 第 18 回設計シンポジウム講演論文集，pp.29–33, 2000.
[14] 野間口大，妻屋彰，吉岡真治，武田英明，村上存，冨山哲男: 設計事例分析による設計
過程モデルの比較 (第 2 報) - 設計過程の情報モデルの提案 -. 2000 年度精密工学
会秋季大会学術講演会講演論文集，p.260, 2000.
[15] 野間口大，妻屋彰，吉岡真治，鷲尾隆，武田英明，村上存，冨山哲男: 設計知識に注目
した設計の推論モデルの提案 (第 4 報) - 設計の推論モデルの計算机上への実装と検
証 -. 日本機械学会第 10 回設計工学・システム部門講演会論文集，pp.285–288, 2001.
[16] 妻屋彰，野間口大，吉岡真治，武田英明，村上存，冨山哲男: 設計知識に注目した設計
の推論モデルの提案 (第 5 報) - 異なる設計過程のモデルとの比較 -. 日本機械学会
第 10 回設計工学・システム部門講演会論文集，pp.289–292, 2001.
[17] 野間口大，冨山哲男，吉岡真治: 設計シミュレータを用いた設計文書作成支援. 2001 年
度精密工学会春季大会学術講演会講演論文集，p.318, 2001.
[18] Y. Tan, Y. Nomaguchi, T. Kiriyama, T. Tomiyama: A Design Information Threading
System based on Concurrent XML and Multimedia Representation. 2001 年度精密工
学会秋季大会学術講演会講演論文集，p.320, 2001.
162
[19] Y. Nomaguchi, T. Tomiyama, and M. Yoshioka: Document-based Design Process
Knowledge Management for Knowledge Intensive Engineering. U. Cugini and M.
Wozny (eds.): Proceedings of the Fourth IFIP Working Group 5.2 Workshop on
Knowledge Intensive CAD, pp.163–185, 2000.
[20] 野間口大，吉岡真治，冨山哲男: 設計知識管理のための CAD アーキテクチャーの提案.
第 19 回設計シンポジウム講演論文集，, 2001.
[21] 野間口大，坂井宏充，下村芳樹，冨山哲男: 設計者の思考過程モデルを用いた設計文書
の自動生成. 2001 年度精密工学会秋季大会学術講演会講演論文集，p.34, 2001.
[22] 坂井宏充，野間口大，吉岡真治，下村芳樹，冨山哲男: 人工物工学研究の展開 (第 15
報) - 設計者の思考パターンの発見による知識獲得 -. 日本機械学会第 11 回設計工
学・システム部門講演会論文集，pp.204–206, 2001.
163
164
付録
165
A. 情報導出生成ルール
設計過程知識を実行した際にシンセシス推論フレームワークが出力するログを元に情報導
出を生成するためのルールである。このルールは各設計過程知識ごとに生成される情報導出
を記述したものである。ログ中で、設計情報が代入されている変数を太字で示してある。
Resolve conflict
ログ
(setq ConflictNodes (add:with: (detectConflictNodes:
(getCurrentDesignObjectDescription)) (detectConflictNodes:
(getCurrentDesignObjectRelated))))
(setq RelatedModelers (relatedModelers:type:ConflictNodes representation))
(setq SelectedModeler (selectOneFrom:message:
RelatedModelers ’select one modeler for represent conflict.’))
(setq NewModeler (makeModelerOn: SelectedModeler))
(interactive(useModeler: NewModeler))
(setq UsedInformation (getUsedInformation: NewModeler))
(setq NewInformation (getModelerInformation: NewModeler))
(addInformation:removeInformation: (difference:from: UsedInformation
NewInformation) (difference:from: NewInformation UsedInformation))
(makeNewWorld: conflict)
1
基本語彙
知識操作
情報導出
2
基本語彙
知識操作
情報導出
3
基本語彙
知識操作
情報導出
4
基本語彙
知識操作
情報導出
5
基本語彙
知識操作
情報導出
問題点指摘
知識・情報の獲得
参照
CurrentDesignObjectDescription, CurrentDesignObjectRelated
追加
ConflictNodes
知識・情報の再構成
知識・情報の再構成
参照
ConflictNodes
修正
RelatedModelers
決定
解のシンセシス
参照
RelatedModelers
追加
SelectedModeler
知識・情報の整理
知識・情報の整理
参照
SelectedModeler
追加
UsedInformation
提案
解のシンセシス
参照
ConflictNodes
追加 (修正) NewInformation
166
Experiment
ログ
(setq Prototype (makePrototype:(getCurrentDesignObjectDescription)))
(experiment: Prototype)
(setq RelatedModelers (relatedModelers:type: nil experiment))
(setq SelectedModeler (selectOneFrom:message:
RelatedModelers ’select one modeler for input experiment data.’))
(setq NewModeler (makeModelerOn: SelectedModeler))
(interactive (useModeler: NewModeler))
(setq UsedInformation (getUsedInformation: NewModeler))
(setq NewInformation (getModelerInformation: NewModeler))
(addInformation:removeInformation: (difference:from: UsedInformation
NewInformation) (difference:from: NewInformation
UsedInformation))
(makeNewWorld: experiment)
1
基本語彙
知識操作
情報導出
2
基本語彙
知識操作
情報導出
試作
解の分析
参照 CurrentDesignObjectDescription
追加 Prototype
実験
解の分析
参照 Prototype
修正 NewInformation
167
Solution analysis
ログ
(setq DeducedInformation (deduction))
(setq AddedInformation (add:with: (getNewAddedDesignObjectDescription)
(getNewAddedDesignObjectRelated)))
(setq RelatedModelers (relatedModelers:type: AddedInformation analysis))
(setq SelectedModeler (selectOneFrom:message: RelatedModelers ’select one modeler for analysis.’))
(setq NewModeler (makeModelerOn: SelectedModeler))
(interactive (useModeler: NewModeler))
(setq UsedInformation (getUsedInformation: NewModeler))
(setq NewInformation (add:with: DeducedInformation
(getModelerInformation: NewModeler)))
(addInformation:removeInformation: (difference:from: UsedInformation
NewInformation) (difference:from: NewInformation
UsedInformation))
(makeNewWorld: analysis)
1
基本語彙
知識操作
情報導出
2
基本語彙
知識操作
情報導出
3
基本語彙
知識操作
情報導出
4
基本語彙
知識操作
情報導出
5
基本語彙
知識操作
情報導出
導出
解の分析
参照 CurrentDesignObjectDescription
追加 DeducedInformation
知識・情報の再構成
知識・情報の再構成
参照 DeducedInformation
追加 RelatedModeler
決定
解のシンセシス
参照 RelatedModeler
追加 SelectedModeler
知識・情報の整理
知識・情報の再構成
参照 SelectedModeler
追加 UsedInformation
数値解析
解の分析
参照 UsedInformation, SelectedModeler
追加 NewInformation
168
Solution synthesis
ログ
(setq CandidateProblems (add:with: (reject:by: (getCurrentRequirement)
isJustified:) (reject:by: (getCurrentDesignObjectDescription)
isManufacturable:)))
(setq RelatedModelers (relatedModelers:type:
CandidateProblems synthesis))
(setq SelectedModeler (selectOneFrom:message:
RelatedModelers ’select one modeler for synthesis.’))
(setq NewModeler (makeModelerOn: SelectedModeler))
(interactive (useModeler: NewModeler))
(setq UsedInformation (getUsedInformation: NewModeler))
(setq NewInformation (getModelerInformation: NewModeler))
(addInformation:removeInformation: (difference:from: UsedInformation
NewInformation) (difference:from: NewInformation
UsedInformation)) (makeNewWorld: synthesis)
1
基本語彙
知識操作
情報導出
2
基本語彙
知識操作
情報導出
3
基本語彙
知識操作
情報導出
4
基本語彙
知識操作
情報導出
知識・情報の再構成
知識・情報の再構成
参照 CandidateProblems
追加 RelatedModelers
決定
解のシンセシス
参照 RelatedModelers
修正 SelectedModeler
知識・情報の整理
知識・情報の再構成
参照 SelectedModeler
追加 UsedInformation
提案
解のシンセシス
参照 UsedInformation, SelectedModeler
追加 NewInformation
169
Add specification
ログ
(setq RelatedModelers (relatedModelers:type: nil requirement))
(setq SelectedModeler (selectOneFrom:message:
RelatedModelers ’select one modeler for requirement.’))
(setq NewModeler (makeModelerOn: SelectedModeler))
(interactive (useModeler: NewModeler))
(setq NewRequirements (getModelerInformation: NewModeler))
(addInformation: NewRequirements)
(makeNewWorld: specified)
1
基本語彙
知識操作
情報導出
問題点指摘
知識・情報の獲得
参照追加 NewRequirements
170
B. 情報導出から自然言語への変換ルール
4.3.3 節で示した、情報導出から自然言語への変換ルールの全部を掲載する。斜体で記し
た部分に操作の対象となる設計情報が記述される。なお、設計過程知識によって生成された
情報導出に対して適用される場合は、それぞれの設計過程知識に特化したルールが利用され
具体的な記述を生成する。このルールも合わせて掲載する。
171
基本語彙
生成される文
(対応する設計過程知識があればその名前)
調査
問題点指摘
参照：外部情報により追加：内部情報であることが分かりました。
参照：設計対象関連情報には追加：要求仕様記述という問題があります。
設計情報参照：設計対象関連情報と追加：要求仕様記述の間に矛盾があります。
(Resolve Conflict)
追加：要求仕様記述が要求仕様として追加されました。(Add specification)
参照：内部情報により追加：設計知識であることが分かりました。
参照：内部情報において、利用した情報は修正：内部情報です。
参照：内部情報の問題を解くために修正：設計知識が利用可能です。
参照：設計対象記述は修正：設計対象記述です。
参照：設計対象記述を追加：設計対象記述と図示しました。
参照：要求仕様記述に関して、追加：設計対象関連情報であることを確認した。
矛盾の原因となっている参照：内部情報を修正：内部情報と修正しました。
参照：設計対象記述の参照：設計対象関連情報を修正：要求仕様記述としました。
参照：内部情報を修正：内部情報と修正しました。
参照：設計知識の知識を利用して、参照：要求仕様記述に対する解として
追加:設計対象記述を提案しました。
矛盾を解消するために、設計情報の追加:設計対象記述の修正が提案されました。
(Resolve conflict)
問題に対する解として、追加:設計対象記述が提案されました。(Solution synthesis)
参照：要求仕様記述に対する解として追加:設計対象記述を発想しました。
参照：設計対象記述記述から追加:設計対象記述を連想しました。
参照：設計対象記述を選択し、それ以外の修正：設計対象記述を削除しました。
参照：内部情報に関して追加：内部情報と決定しました。
設計者は、追加：設計知識の知識を利用することを決定しました。
(Resolve conflice, Solution analysis, Solution synthesis, )
参照：設計対象関連情報は参照：要求仕様記述を満たすように、
修正：設計対象記述と改良しました。
参照：要求仕様記述という観点からは、参照：設計対象記述
の参照：設計対象関連情報は追加：内部情報です。
実験結果は追加:設計対象関連情報です。
参照：設計知識により参照：設計対象記述
を解析した結果、追加：内部情報を得ました。
解析の結果として、設計情報追加：内部情報が追加されました。
(Solution analysis)
追加:人工物が実験のために試作されました。
参照：設計知識により参照：設計対象記述なの
で追加：設計対象関連情報を導出しました。
定性推論により、予期せぬ物理現象追加：設計対象関連情報
が設計対象に起こる可能性があることが導出されました。
(Solution analysis)
知識・情報の獲得
知識・情報の整理
知識・情報の再構成
具体化
製図
確認
矛盾解消
制約の操作
知識・情報の修正
提案
発想
連想
選択
決定
改良
評価
実験
数値解析
試作
導出
172
C. DDMS により生成された文書
6.2.1 節で示したレーザーリソグラフィーの設計事例において DDMS が生成した文書の一
部である。なお、設計作業中に構築されたモデルへのリンクは下線で示されている。
1 set specification
’ 機能仕様:Stereo-Lithograph(product)1’ が要求仕様として記述されました。
2 solution synthesis
’ 機能仕様:Stereo-Lithograph(product)1 ’ が問題となっています。この問題を解くため
に、’ FBSModeler ’ の知識の利用が可能です。
設計者は、’ FBSModeler ’ の知識を利用することを決定しました。利用した設計情報は ’
機能仕様:Stereo-Lithograph(product)1 ’ です。
問題に対する解として、 ’ LaserPhotoformingPF29 機能仕様: Flatten(surface)27 機能仕
様:Control(table)23 SimpleTableControllingPF31 機能仕様:Photoform(resin)to(product)26
機能仕様:Control(surface)22 SurfaceLevelingPF30 ’ が提案されました。.
3 add specification
’ 属性仕様:AttributeRequirement32「FabricatedProduct の LayerThickness が 10 以下で
あること。」 ’ が要求仕様として追加されました。
4 experiment
試作機 ’ Prototype ’ が実験のために作成されました。
実験結果は’ LayerThickness34(=400) ’ です。
5 solution analysis
定性推論により、予期せぬ物理現象’ Stick35 ’ が設計対象に起こる可能性があることが導
出されました。
173
これらの物理現象を詳しく解析するために、’ Only in logic level BeamModeler Pro/ENGINEER
QPReasoner 2DDrawModel QParameterAnalyzer QuantitativeMathematicsModel PrimaryModeler SurfaceTensionModeler CatalogueWindow FBSModeler ExperimentalDataAcuqisition ’ の知識を利用することが可能です。
設計者は、 ’ Only in logic level ’ の知識を利用することを決定しました。
解析の結果として、設計情報’ Stick35 ’ が追加されました。
6 resolve conflict
設計情報’ 属性仕様:AttributeRequirement32「FabricatedProduct の LayerThickness が
10 以下であること。」 LayerThickness34(=400) ’ の間に矛盾があります。この矛盾を新た
な設計問題とします。
この問題を解くために、 ’ BeamModeler Pro/ENGINEER QPReasoner 2DDrawModel
QParameterAnalyzer QuantitativeMathematicsModel PrimaryModeler SurfaceTensionModeler CatalogueWindow FBSModeler ExperimentalDataAcuqisition ’ の知識が利用可能
です。
設計者は’ FBSModeler ’ の知識を利用することを決定しました。
利用した設計情報は ’ 機能仕様:Control(table)23 FabricationPlatform9 Stick35 機能仕
様:Stereo-Lithograph(product)1 機能仕様: Photoform(resin)to(product)26 機能仕様:Control(surface)22
Controlling17 ConnectionWithASpace14 SurfaceOf15 HorizontalMovement21 Surface5 LaserEmission16 Resin8 TableController3 Photopolymerization19 FabricatedProduct7 LaserUnit4
Movement18 On13 機能仕様: Flatten(surface)27 In12 Blade6 SurfaceLeveling20 Contact11
MechanicalConnection10 ’ です。
矛盾を解消するために、設計情報 ’ SurfaceLeveling20 Stick35 機能仕様:Flatten(surface)27
Blade6 Contact11 HorizontalMovement21 ’ の修正が提案されました。
7 solution synthesis
’ 機能仕様:Control(surface)22 属性仕様:AttributeRequirement32 「FabricatedProduct の
LayerThickness が 400 以下であること。」 ’ が問題となっています。この問題を解くために、’
FBSModeler ’ の知識の利用が可能です。
174
設計者は、’ FBSModeler ’ の知識を利用することを決定しました。
利用した設計情報は ’ 機能仕様:Stereo-Lithograph(product)1 機能仕様: Photoform(resin)to(product)26
機能仕様:Control(surface)22 SurfaceOf15 ConnectionWithASpace14 ... ’ です。
問題に対する解として、 ’ LiquidLevelControl61 DynamicPressureChange54 SurfaceOf44
GasFlow57 HollowForming50 Connection45 Controller38 Control49 機能仕様:Control(hollow)on(surface)58
Air40 On46 機能仕様: Measure(liquid surface)60 ... ’ が提案されました。.
8 experiment
試作機 ’ Prototype ’ が実験のために作成されました。
実験結果は’ LayerThickness63(=300) ’ です。
9 solution analysis
定性推論により、予期せぬ物理現象’ GasPressureChange65 TemperatureChange64 Tur-
bulence66 Pressing67 ’ が設計対象に起こる可能性があることが導出されました。
これらの物理現象を詳しく解析するために、’ Only in logic level BeamModeler Pro/ENGINEER
QPReasoner 2DDrawModel QParameterAnalyzer QuantitativeMathematicsModel PrimaryModeler SurfaceTensionModeler CatalogueWindow FBSModeler ExperimentalDataAcuqisition ’ の知識を利用することが可能です。
設計者は、 ’ Only in logic level ’ の知識を利用することを決定しました。
解析の結果として、設計情報’ GasPressureChange65 TemperatureChange64 Turbulence66
Pressing67 ’ が追加されました。
10 resolve conflict
設計情報’ LayerThickness63(=300) 属性仕様:AttributeRequirement68「FabricatedProduct
の LayerThickness が 10 以下であること。」 ’ の間に矛盾があります。この矛盾を新たな設
計問題とします。
この問題を解くために、 ’ BeamModeler Pro/ENGINEER QPReasoner 2DDrawModel
QParameterAnalyzer QuantitativeMathematicsModel PrimaryModeler SurfaceTensionModeler CatalogueWindow FBSModeler ExperimentalDataAcuqisition ’ の知識が利用可能
175
です。
設計者は’ FBSModeler ’ の知識を利用することを決定しました。
利用した設計情報は ’ 機能仕様:Control(table)23 Connection45 LaserEmission51 Tur-
bulence66 FabricationPlatform9 LaserEmission16 On46 LaserCollection56 Surface43 Surface5 Liquid37 SurfaceTension55 機能仕様:Measure(liquid surface)60 ....’ です。
設計情報 ’ DynamicPressureChange54 SurfaceOf44 GasFlow57 HollowForming50 Con-
nection45 Controller38 Control49 GasPressureChange65 Turbulence66 Pressing67 Air40
On46 ... ’ の修正が提案されました。
矛盾を解消するために、’In80 Surface75 CylindricalPair82 Air71 Hollow69 Surface76
Piston74 SurfaceTension90 PistonCompression92 GasPressing91 CylindricalPair84 ... ’
が解として提案されました。
13 experiment
試作機 ’ Prototype ’ が実験のために作成されました。
実験結果は’ LayerThickness96(=200) ’ です。
22 solution synthesis
’ 機能仕様:Cancel(noise)25 機能仕様:Operate(liquid level defference)30 ... ’ が問題と
なっています。この問題を解くために、’ FBSModeler ’ の知識の利用が可能です。
設計者は、’ ‘FBSModeler ’ の知識を利用することを決定しました。
利用した設計情報は ’ 機能仕様:Cancel(noise)25 機能仕様: Operate(liquid level deffer-
ence)30 ... ’ です。
問題に対する解として、 ’ 機能仕様:Control(table)52 機能仕様: Operate(liquid quan-
tity)45 機能仕様:Control(hollow)on(surface)51 LiquidAspiration58 LaserPhotoformingPF57
SimpleTableControllingPF60 ... ’ が提案されました。
23 solution analysis
定性推論により、予期せぬ物理現象’ GasPressureChange63 TemperatureChange62 ’ が
設計対象に起こる可能性があることが導出されました。
176
これらの物理現象を詳しく解析するために、’ Only in logic level BeamModeler Pro/ENGINEER
QPReasoner 2DDrawModel QParameterAnalyzer QuantitativeMathematicsModel PrimaryModeler SurfaceTensionModeler CatalogueWindow FBSModeler ExperimentalDataAcuqisition ’ の知識を利用することが可能です。
設計者は、 ’ Only in logic level ’ の知識を利用することを決定しました。
利用した設計情報は ’ ’ です。解析の結果として、設計情報’ GasPressureChange63 Tem-
peratureChange62 ’ が追加されました。
24 solution analysis
定性推論を実行しましたが、予期せぬ物理現象の発生は導出されませんでした。
これらの物理現象を詳しく解析するために、’ Only in logic level BeamModeler Pro/ENGINEER
QPReasoner 2DDrawModel QParameterAnalyzer QuantitativeMathematicsModel PrimaryModeler SurfaceTensionModeler CatalogueWindow FBSModeler ExperimentalDataAcuqisition ’ の知識を利用することが可能です。
設計者は、 ’ SurfaceTensionModeler ’ の知識を利用することを決定しました。
利用した設計情報は ’ On32 ConnectionWithASpace26 Liquid12 SurfaceOf24 Surface6
Resin16 Contact30 SurfaceOf23 Surface20 Contain25 Hollow10 Liquid8 SurfaceTension38
In21 In28 ’ です。
解析の結果として、設計情報’Radius96(=0.0005) ’ が追加されました。
177
D. シンセシス推論フレームワークのログ
6.2.1 節で示したレーザーリソグラフィーの設計事例においてシンセシス推論フレームワー
クが生成したログデータの一部である。前掲の DDMS によって生成された文書の元となっ
たものである。
1. Set specification
(setq RelatedModelers (relatedModelers:type: () requirement) )
(setq SelectedModeler (selectOneFrom:message: (RelatedModelers ’=’ (FBSModeler AttributeRequirementModeler)) ’select one modeler for requirement.’) )
(setq NewModeler (makeModelerOn: (SelectedModeler ’=’ FBSModeler)) )
(setq NewRequirements (getModelerInformation: (NewModeler ’=’ an InterfaceFBSModeler)) )
(addInformation: (NewRequirements ’=’ (a product2 a Stereo-Lithograph(product)1))
)
(makeNewWorld: specified )
2. Solution synthesis
(setq CandidateProblems (add:with: (reject:by: (getCurrentRequirement) isJustified:)
(reject:by: (getCurrentDesignObjectDescription) isManufacturable:)) )
(setq RelatedModelers (relatedModelers:type: (CandidateProblems ’=’ (a Stereo-Lithograph(product)1))
synthesis) )
(setq SelectedModeler (selectOneFrom:message: (RelatedModelers ’=’ (FBSModeler))
’select one modeler for synthesis.’) )
(setq NewModeler (makeModelerOn: (SelectedModeler ’=’ FBSModeler)) )
(setq UsedInformation (getUsedInformation: (NewModeler ’=’ an InterfaceFBSModeler)) )
(setq NewInformation (getModelerInformation: (NewModeler ’=’ an InterfaceFBSModeler)) )
(addInformation:removeInformation: (difference:from: (UsedInformation ’=’ (a prod-
uct2 a Stereo-Lithograph(product)1)) (NewInformation ’=’ (a SimpleTableControllingPF29
a table24 a SurfaceLeveling18 a Resin8 a On13 a In12 a Contact11 a MechanicalConnection10 a product2 a Photoform(resin)to(product)25 a SurfaceOf15 a TableController3 a
Blade6 a surface23 a LaserEmission19 a Photopolymerization20 a SurfaceLevelingPF31 a
Control(surface)28 a resin22 a Stereo-Lithograph(product)1 a Controlling16 a LaserPhotoformingPF30 a Movement17 a ConnectionWithASpace14 a FabricationPlatform9 a HorizontalMovement21 a Surface5 a FabricatedProduct7 a LaserUnit4 a Flatten(surface)27 a
Control(table)26))) (difference:from: (NewInformation ’=’ (a SimpleTableControllingPF29
a table24 a SurfaceLeveling18 a Resin8 a On13 a In12 a Contact11 a MechanicalConnection10 a product2 a Photoform(resin)to(product)25 a SurfaceOf15 a TableController3 a
Blade6 a surface23 a LaserEmission19 a Photopolymerization20 a SurfaceLevelingPF31 a
Control(surface)28 a resin22 a Stereo-Lithograph(product)1 a Controlling16 a LaserPhotoformingPF30 a Movement17 a ConnectionWithASpace14 a FabricationPlatform9 a HorizontalMovement21 a Surface5 a FabricatedProduct7 a LaserUnit4 a Flatten(surface)27 a
Control(table)26)) (UsedInformation ’=’ (a product2 a Stereo-Lithograph(product)1))) )
(makeNewWorld: synthesis )
3. Add specification
(setq RelatedModelers (relatedModelers:type: () requirement) )
(setq SelectedModeler (selectOneFrom:message: (RelatedModelers ’=’ (FBSModeler AttributeRequirementModeler)) ’select one modeler for requirement.’) )
(setq NewModeler (makeModelerOn: (SelectedModeler ’=’ AttributeRequirementModeler)) )
(setq NewRequirements (getModelerInformation: (NewModeler ’=’ an InterfaceAttributeRequirementModeler)) )
(addInformation: (NewRequirements ’=’ a AttributeRequirement32) )
(makeNewWorld: specified )
179
4. Experiment
(setq Prototype (makePrototype: (getCurrentDesignObjectDescription)) )
(experiment: (Prototype ’=’ Prototype) )
(setq RelatedModelers (relatedModelers:type: () experiment) )
(setq SelectedModeler (selectOneFrom:message: (RelatedModelers ’=’ (ExperimentalDataAcuqisition)) ’select one modeler for input experiment data.’) )
(setq NewModeler (makeModelerOn: (SelectedModeler ’=’ ExperimentalDataAcuqisition)) )
(setq UsedInformation (getUsedInformation: (NewModeler ’=’ an InterfaceExperimentalDataAcuqisition)) ) (setq NewInformation (getModelerInformation: (NewModeler ’=’
an InterfaceExperimentalDataAcuqisition)) )
(addInformation:removeInformation: (difference:from: (UsedInformation ’=’ (a On13 a
FabricationPlatform9 a FabricatedProduct7 a In12 a Contact11 a LaserUnit4 a MechanicalConnection10 a Blade6 a SurfaceOf15 a Surface5 a ConnectionWithASpace14 a Resin8 a
TableController3)) (NewInformation ’=’ (a Surface5 a SurfaceAccuracy34 a On13 a FabricationPlatform9 a FabricatedProduct7 a In12 a Contact11 a LaserUnit4 a MechanicalConnection10 a Blade6 a SurfaceOf15 a Surface5 a ConnectionWithASpace14 a Resin8 a TableController3))) (difference:from: (NewInformation ’=’ (a Surface5 a SurfaceAccuracy34 a
On13 a FabricationPlatform9 a FabricatedProduct7 a In12 a Contact11 a LaserUnit4 a
MechanicalConnection10 a Blade6 a SurfaceOf15 a Surface5 a ConnectionWithASpace14 a
Resin8 a TableController3)) (UsedInformation ’=’ (a On13 a FabricationPlatform9 a FabricatedProduct7 a In12 a Contact11 a LaserUnit4 a MechanicalConnection10 a Blade6 a
SurfaceOf15 a Surface5 a ConnectionWithASpace14 a Resin8 a TableController3))) )
(makeNewWorld: experiment )
5. Solution analysis
(setq DeducedInformation (deduction) )
(setq AddedInformation (add:with: (getNewAddedDesignObjectDescription) (getNewAddedDesignObjectRelated)) )
180
(setq RelatedModelers (relatedModelers:type: (AddedInformation ’=’ (a TableController3 a LaserUnit4 a Surface5 a Blade6 a FabricatedProduct7 a Resin8 a FabricationPlatform9 a MechanicalConnection10 a Contact11 a In12 a On13 a ConnectionWithASpace14 a SurfaceOf15 a Controlling16 a Movement17 a SurfaceLeveling18 a LaserEmission19 a Photopolymerization20 a HorizontalMovement21 a SurfaceAccuracy34 a Stick35))
analysis) ) (setq SelectedModeler (selectOneFrom:message: (RelatedModelers ’=’ (Only
in logic level BeamModeler Pro/ENGINEER QPReasoner 2DDrawModel QParameterAnalyzer QuantitativeMathematicsModel PrimaryModeler SurfaceTensionModeler CatalogueWindow FBSModeler ExperimentalDataAcuqisition)) ’select one modeler for analysis.’) )
(setq NewModeler (makeModelerOn: (SelectedModeler ’=’ Only in logic level)) )
(setq UsedInformation (getUsedInformation: (NewModeler ’=’ nil)))
(setq NewInformation (add:with: (DeducedInformation ’=’ (a Stick35)) (getModelerInformation: (NewModeler ’=’ nil))) )
(addInformation:removeInformation: (difference:from: (UsedInformation ’=’ ()) (NewInformation ’=’ (a Stick35))) (difference:from: (NewInformation ’=’ (a Stick35)) (UsedInformation ’=’ ())) )
(makeNewWorld: analysis )
6. Resolve conflict
(setq ConflictNodes (add:with: (detectConflictNodes: (getCurrentDesignObjectDescription)) (detectConflictNodes: (getCurrentDesignObjectRelated))) )
(setq RelatedModelers (relatedModelers:type: (ConflictNodes ’=’ (a AttributeRequirement32 a SurfaceAccuracy34)) representation) )
(setq SelectedModeler (selectOneFrom:message: (RelatedModelers ’=’ (BeamModeler
Pro/ENGINEER QPReasoner 2DDrawModel QParameterAnalyzer QuantitativeMathematicsModel PrimaryModeler SurfaceTensionModeler CatalogueWindow FBSModeler ExperimentalDataAcuqisition)) ’select one modeler for represent conflict.’) )
(setq NewModeler (makeModelerOn: (SelectedModeler ’=’ FBSModeler)) )
(setq UsedInformation (getUsedInformation: (NewModeler ’=’ an InterfaceFBSMod181
eler)) )
(setq NewInformation (getModelerInformation: (NewModeler ’=’ an InterfaceFBSModeler)) )
(addInformation:removeInformation: (difference:from: (UsedInformation ’=’ (a Movement17 a On13 a Resin8 a LaserUnit4 a table24 a Flatten(surface)27 a surface23 a ConnectionWithASpace14 a SurfaceOf15 a Contact11 a resin22 a LaserEmission19 a SurfaceLeveling18 a FabricatedProduct7 a Blade6 a FabricationPlatform9 a Control(surface)28 a Surface5 a TableController3 a In12 a Controlling16 a Control(table)26 a Photoform(resin)to(product)25
a HorizontalMovement21 a product2 a Stereo-Lithograph(product)1 a Stick35 a MechanicalConnection10 a Photopolymerization20)) (NewInformation ’=’ (a On13 a FabricationPlatform9 a FabricatedProduct7 a In12 a LaserUnit4 a Control(table)26 a product2 a Photoform(resin)to(product)25 a MechanicalConnection10 a LaserEmission19 a
Stereo-Lithograph(product)1 a Photopolymerization20 a SurfaceOf15 a Movement17 a
table24 a Controlling16 a Surface5 a ConnectionWithASpace14 a Control(surface)28 a
Resin8 a surface23 a TableController3 a resin22))) (difference:from: (NewInformation
’=’ (a On13 a FabricationPlatform9 a FabricatedProduct7 a In12 a LaserUnit4 a Control(table)26 a product2 a Photoform(resin)to(product)25 a MechanicalConnection10 a
LaserEmission19 a Stereo-Lithograph(product)1 a Photopolymerization20 a SurfaceOf15
a Movement17 a table24 a Controlling16 a Surface5 a ConnectionWithASpace14 a Control(surface)28 a Resin8 a surface23 a TableController3 a resin22)) (UsedInformation ’=’
(a Movement17 a On13 a Resin8 a LaserUnit4 a table24 a Flatten(surface)27 a surface23 a ConnectionWithASpace14 a SurfaceOf15 a Contact11 a resin22 a LaserEmission19 a SurfaceLeveling18 a FabricatedProduct7 a Blade6 a FabricationPlatform9 a Control(surface)28 a Surface5 a TableController3 a In12 a Controlling16 a Control(table)26 a
Photoform(resin)to(product)25 a HorizontalMovement21 a product2 a Stereo-Lithograph(product)1
a Stick35 a MechanicalConnection10 a Photopolymerization20))) )
(setq NewKnowledgeSet (getDesignKnowledge) )
(addKnowledge: (NewKnowledgeSet ’=’ ()) )
(makeNewWorld: conflict )
182
7. Solution synthesis
(setq CandidateProblems (add:with: (reject:by: (getCurrentRequirement) isJustified:)
(reject:by: (getCurrentDesignObjectDescription) isManufacturable:)) )
(setq RelatedModelers (relatedModelers:type: (CandidateProblems ’=’ (a Control(surface)28))
synthesis) )
(setq SelectedModeler (selectOneFrom:message: (RelatedModelers ’=’ (FBSModeler))
’select one modeler for synthesis.’) ) (setq NewModeler (makeModelerOn: (SelectedModeler ’=’ FBSModeler)) )
(setq UsedInformation (getUsedInformation: (NewModeler ’=’ an InterfaceFBSModeler)) )
(setq NewInformation (getModelerInformation: (NewModeler ’=’ an InterfaceFBSModeler)) )
(addInformation:removeInformation: (difference:from: (UsedInformation ’=’ (a Controlling16 a MechanicalConnection10 a FabricatedProduct7 a table24 a TableController3 a
Movement17 a LaserUnit4 a On13 a LaserEmission19 a surface23 a Stereo-Lithograph(product)1
a Control(table)26 a Resin8 a In12 a Surface5 a SurfaceOf15 a FabricationPlatform9 a
Photopolymerization20 a Photoform(resin)to(product)25 a Control(surface)28 a resin22 a
ConnectionWithASpace14 a product2)) (NewInformation ’=’ (a Control(hollow)on(surface)74
a Air36 a LiquidAspiration76 a FabricationPlatform9 a Surface39 a LiquidLevelMeasuringPF77 a Air47 a LiquidLevelMeasuringInstrument41 a Stereo-Lithograph(product)1 a
table24 a LiquidLevelDifferencePF78 a product2 a LightReflection63 a Case45 a Liquid40 a
LiquidConnection56 a ConnectionWithASpace14 a In12 a SurfaceOf50 a Vat48 a LaserEmission59 a LaserUnit4 a Photoform(resin)to(product)25 a liquid leve difference71 a
LiquidPressureChange67 a Contain53 a Surface37 a LaserEmission19 a MechanicalConnection10 a Tube42 a Liquid38 a Control(surface)28 a SurfaceTension64 a ConnectionWithASpace55 a surface23 a On58 a Contain49 a Hollow43 a hollow69 a On13 a Cancel(noise)75 a LaserCollection65 a FabricatedProduct7 a SurfaceOf15 a Operate(liquid
level difference)70 a Top52 a GravityForce61 a GasPressing62 a Form(hollow)by(liquid
level difference)73 a Resin8 a Control(table)26 a Contact57 a Liquid44 a Measure(liquid
surface)72 a Nozzle46 a TableController3 a resin22 a noise68 a Surface5 a Movement17 a
183
GasPressing60 a HollowForming66 a Contain51 a Photopolymerization20 a Controlling16
a In54))) (difference:from: (NewInformation ’=’ (a Control(hollow)on(surface)74 a Air36
a LiquidAspiration76 a FabricationPlatform9 a Surface39 a LiquidLevelMeasuringPF77
a Air47 a LiquidLevelMeasuringInstrument41 a Stereo-Lithograph(product)1 a table24 a
LiquidLevelDifferencePF78 a product2 a LightReflection63 a Case45 a Liquid40 a LiquidConnection56 a ConnectionWithASpace14 a In12 a SurfaceOf50 a Vat48 a LaserEmission59 a LaserUnit4 a Photoform(resin)to(product)25 a liquid leve difference71 a LiquidPressureChange67 a Contain53 a Surface37 a LaserEmission19 a MechanicalConnection10
a Tube42 a Liquid38 a Control(surface)28 a SurfaceTension64 a ConnectionWithASpace55
a surface23 a On58 a Contain49 a Hollow43 a hollow69 a On13 a Cancel(noise)75 a LaserCollection65 a FabricatedProduct7 a SurfaceOf15 a Operate(liquid level difference)70 a
Top52 a GravityForce61 a GasPressing62 a Form(hollow)by(liquid level difference)73 a
Resin8 a Control(table)26 a Contact57 a Liquid44 a Measure(liquid surface)72 a Nozzle46 a TableController3 a resin22 a noise68 a Surface5 a Movement17 a GasPressing60 a
HollowForming66 a Contain51 a Photopolymerization20 a Controlling16 a In54)) (UsedInformation ’=’ (a Controlling16 a MechanicalConnection10 a FabricatedProduct7 a table24
a TableController3 a Movement17 a LaserUnit4 a On13 a LaserEmission19 a surface23 a
Stereo-Lithograph(product)1 a Control(table)26 a Resin8 a In12 a Surface5 a SurfaceOf15
a FabricationPlatform9 a Photopolymerization20 a Photoform(resin)to(product)25 a Control(surface)28 a resin22 a ConnectionWithASpace14 a product2))) )
(makeNewWorld: synthesis )
9. Solution analysis
(setq DeducedInformation (deduction) )
(setq AddedInformation (add:with: (getNewAddedDesignObjectDescription) (getNewAddedDesignObjectRelated)) )
(setq RelatedModelers (relatedModelers:type: (AddedInformation ’=’ (a Air36 a Surface37 a Liquid38 a Surface39 a Liquid40 a LiquidLevelMeasuringInstrument41 a Tube42
a Hollow43 a Liquid44 a Case45 a Nozzle46 a Air47 a Vat48 a Contain49 a SurfaceOf50 a
Contain51 a Top52 a Contain53 a In54 a ConnectionWithASpace55 a LiquidConnection56
184
a Contact57 a On58 a LaserEmission59 a GasPressing60 a GravityForce61 a GasPressing62 a LightReflection63 a SurfaceTension64 a LaserCollection65 a HollowForming66
a LiquidPressureChange67 a TemperatureChange79 a GasPressureChange80 a TemperatureChange81 a GasPressureChange82)) analysis) ) (setq SelectedModeler (selectOneFrom:message: (RelatedModelers ’=’ (Only in logic level BeamModeler Pro/ENGINEER
QPReasoner 2DDrawModel QParameterAnalyzer QuantitativeMathematicsModel PrimaryModeler SurfaceTensionModeler CatalogueWindow FBSModeler ExperimentalDataAcuqisition)) ’select one modeler for analysis.’) )
(setq NewModeler (makeModelerOn: (SelectedModeler ’=’ ExperimentalDataAcuqisition)) ) (setq UsedInformation (getUsedInformation: (NewModeler ’=’ an InterfaceExperimentalDataAcuqisition)) ) (setq NewInformation (add:with: (DeducedInformation
’=’ (a GasPressureChange80 a TemperatureChange79 a TemperatureChange81 a GasPressureChange82)) (getModelerInformation: (NewModeler ’=’ an InterfaceExperimentalDataAcuqisition))) ) (addInformation:removeInformation: (difference:from: (UsedInformation ’=’ (a On13 a FabricationPlatform9 a FabricatedProduct7 a In12 a Contact11
a LaserUnit4 a MechanicalConnection10 a Blade6 a SurfaceOf15 a Surface5 a ConnectionWithASpace14 a Resin8 a TableController3)) (NewInformation ’=’ (a On13 a FabricationPlatform9 a GasPressureChange80 a FabricatedProduct7 a LaserUnit4 a In12 a MechanicalConnection10 a TemperatureChange79 a GasPressureChange82 a SurfaceOf15 a
SurfaceAccuracy83 a SurfaceAccuracy34 a Surface5 a ConnectionWithASpace14 a Resin8
a TemperatureChange81 a TableController3))) (difference:from: (NewInformation ’=’ (a
On13 a FabricationPlatform9 a GasPressureChange80 a FabricatedProduct7 a LaserUnit4
a In12 a MechanicalConnection10 a TemperatureChange79 a GasPressureChange82 a
SurfaceOf15 a SurfaceAccuracy83 a SurfaceAccuracy34 a Surface5 a ConnectionWithASpace14 a Resin8 a TemperatureChange81 a TableController3)) (UsedInformation ’=’
(a On13 a FabricationPlatform9 a FabricatedProduct7 a In12 a Contact11 a LaserUnit4 a
MechanicalConnection10 a Blade6 a SurfaceOf15 a Surface5 a ConnectionWithASpace14
a Resin8 a TableController3))) )
(makeNewWorld: analysis )
185

Download Report