ライフサイクルモデリング基盤の開発 ‐ビールゲー...

ライフサイクルモデリング基盤の開発

‐ビールゲームに基づいたエージェントベースシミュレーション‐

2011

修士（工学）

機械工学専攻

小出活三

１０５１１０

豊橋技術科学大学

平成24年 3月 9日

機械工学専攻学籍番号 105110

申請者氏名小出活三指導教員氏名 Rafael Batres

論文要旨(修士)

論文題目ライフサイクルモデリング基盤の開発

‐ビールゲームに基づいたエージェントベースシミュレーション‐

近年，持続可能社会の形成へ向けた生産システムの貢献が求められている．行政としても家電リサ

イクル法や自動車リサイクル法，エコポイント等の施策によって環境負荷の低減に取り組んできた

が，未だ根本的解決への糸口は見えていない．

一方，国内外における市場競争の拡大，激化により，より短い時間でより経済的に競争力のある製

品を開発し供給することが求められている．製品の環境性・経済性を両立した開発のためには製品に

関わる資源採掘から製造，使用，消費，廃棄等，製品に関わる全ての過程，ライフサイクルの改善が

必要である．

本研究室では環境調和型生産の実現に向けた取組みとしてライフサイクルを経済性，環境性，安全

性といった様々な評価指標の下で評価・設計支援を行うライフサイクル工学（LCE）の手法を提案し

てきた．先行研究であるオントロジーを用いたモデル検索の提案ではネットワーク上に分散したライ

フサイクルの構成要素のモデルである要素モデルの検索手法について提案された．LCE の研究の進展

のため，要素モデルを統合しライフサイクルモデルを構築する手法と作成したライフサイクルモデル

を経済性と環境性によって統合的に評価する手法が必要である．

そこで本研究では，ライフサイクルモデリング手法と，構築したライフサイクルモデルの評価手法

を統合し，LCE 研究を支援するためのライフサイクルモデリング基盤の開発を目的とする．

ライフサイクルモデリングにおいては企業や顧客といったライフサイクルにおける構成要素を，エ

ージェントを用いて要素モデルとしてモデル化し，それらをエージェントベースモデリングと呼ばれ

る手法により統合することによってライフサイクルモデルを構築する．統合した要素モデルが相互に

関係し，製品の生産や輸送，購入をすることにより生産活動や経済活動を行い，それらの活動を動的

シミュレーションすることによって，作成したライフサイクルモデルの活用を行う．ライフサイクル

評価においては，経済性と環境性の評価機能を実装する．環境性評価を行う際にはライフサイクルの

環境性を評価する手法であるライフサイクルアセスメントを用いる．

第１のケーススタディとして，開発したライフサイクルモデリング基盤を用い，ビールゲームのル

ールに基づいたエージェントベースシミュレーションを実装し，ライフサイクルモデリング基盤の基

本性能であるライフサイクルモデリング性能とライフサイクル評価性能の確認を行う．

第２のケーススタディとしてエージェントの注文意思決定モデルの変更を行いライフサイクルコ

ストの削減を図り，エージェントベースモデリングを用いたことによるシステムの拡張性を確認す

る．

以上のシステムをエージェントを用いたモデル開発及びシミュレーション実行環境を提供するエ

ージェントシミュレータ・Repast Simphony を用いて実装する．

Date Mar.9, 2012

Department ofMechanical Engineering

RegistrationNumber

105110

Name Katsuzo Koide

Graduate Adviser Rafael Batres

ABSTRACT

TitleDevelopment of Life Cycle Modeling Framework‐Agent-Based-Simulation based on Beer Game‐

ライフサイクルモデリング基盤の開発‐ビールゲームに基づいたエージェントベースシミュレーション‐

In recent years, we have seen an increasing need for developing production systems that guarantee asustainable society. The government has worked on reduction of the environmental impact through theintroduction of various policies, but effective solutions are yet to be found.

On the other hand, because of the intensification of global market competition company are motivated todevelop products in shorter time and less cost. In order to address both the economic and environmentalaspects, the whole life cycle of the product has to be considered, going from raw material extraction andproduction through use, consumption to disposal and recycling. LCE models are built in order to analyzeenvironmental, societal, and economic aspects of a product life-cycle.

Life-cycle engineering (LCE) is a set of engineering activities that include the application of engineering andscientific methods and tools to the design and manufacture of products, characterized as activities that areenvironmentally and economically efficient. Our laboratory has contributed with several research projectsaimed at the design and analysis of environment-conscious production systems. For example, in a previousresearch, a technique was developed in which users can search models distributed in the network that satisfycertain criteria by means of matchmaking their capabilities and constraints. However, a modeling environmentwas needed to develop life cycle models that could be simulated to analyze the economical and environmentalperformances.

Therefore this research aims at the development of a life cycle modeling platform that combines supplychain modeling with models for the evaluation of the total cost and environmental impact of a given life-cyclesystem.

In the proposed framework, LCE models can be created from scratch or by combining models of individualcomponents such as models of factories. Those are modeled using agent-based-modeling techniques.

The framework defines a basic agent that act as a building block for specific components. The basic agentcontains functions for information, currency as well as material and energy transfer. The user extends a basicagent to build agents for components such as end-customers, retailers, and factories. In doing so, the user addsspecific models for specific behaviors such as ordering policies, inventory, consumption, which can also beextended and modified without starting from scratch. The agents are models that are used in a dynamicsimulation environment. During the simulation, the economical and environmental performances areevaluated. Environmental performance is measured in terms of life-cycle impact calculated by means of alife-cycle assessment approach.

In order to illustrate the framework, an agent-based-simulation is carried out based on the so-called beergame. The results indicate that the model adequately predicts the bull-whip effect which verifies the model andthe efficacy of the proposed approach.

In a second case study, the ordering policies of the previous beer-game model are changed by reusing mostof the model components. Therefore, it is possible to show that the proposed approach allows for the reuse andextensibility of modeling components.

The framework was implemented using the agent simulator Repast Simphony which provides a library fordeveloping agents as well as a simulation environment for running the model.

1

目次

第 1章緒言 7

1.1 背景 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.2 研究目的 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.3 本論文の構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

第 2章循環型社会の実現に向けた取組み 10

2.1 行政によるアプローチ . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1.1 循環型社会形成推進基本法 . . . . . . . . . . . . . . . . . . . 10

2.1.2 第２次循環型社会形成推進基本計画 . . . . . . . . . . . . . . 11

2.2 消費者によるアプローチ . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3 生産者によるアプローチ . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3.1 ライフサイクルアセスメント（LCA） . . . . . . . . . . . . 15

2.3.2 LCAの実施 . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3.3 LCAの実施状況と課題 . . . . . . . . . . . . . . . . . . . . . 17

2.4 ライフサイクル工学（LCE） . . . . . . . . . . . . . . . . . . . . . 18

2.4.1 モデル・モデリング . . . . . . . . . . . . . . . . . . . . . . 19

2.4.2 ライフサイクルモデルとドメインモデル . . . . . . . . . . . 20

第 3章従来研究 22

3.1 情報公開の促進と柔軟運用に向けた展開 . . . . . . . . . . . . . . . 22

3.1.1 PLCE文書 . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.1.2 IDEF0を用いたライフサイクルのモデル化 . . . . . . . . . . 22

3.1.3 XMLによるモデル表現 . . . . . . . . . . . . . . . . . . . . 24

3.1.4 PLCE文書管理システム . . . . . . . . . . . . . . . . . . . . 25

3.1.5 XMLデータベース . . . . . . . . . . . . . . . . . . . . . . . 25

3.1.6 新規 PLCE 文書作成支援機能 . . . . . . . . . . . . . . . . . 26

3.1.7 PLCE 文書検証機能 . . . . . . . . . . . . . . . . . . . . . . 26

3.1.8 PLCE 文書インテグレーション機能 . . . . . . . . . . . . . . 26

3.2 セマンティック検索を用いたライフサイクルモデリング支援システムの開発 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2.1 セマンティック検索 . . . . . . . . . . . . . . . . . . . . . . . 27

3.2.2 キーワード検索との違い . . . . . . . . . . . . . . . . . . . . 27

2

3.3 本研究の特徴 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

第 4章ビールゲーム 30

4.1 ビールゲームの概要 . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.2 ルール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.2.1 基本ルール . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.2.2 進行手順 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.2.3 ビールゲームの実施における導入 . . . . . . . . . . . . . . . 32

4.3 ビールゲームの狙い . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.4 ライフサイクルモデリング基盤への適用 . . . . . . . . . . . . . . . 34

第 5章マルチエージェントシミュレーション 36

5.1 マルチエージェントシステム . . . . . . . . . . . . . . . . . . . . . 36

5.2 エージェント . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.3 エージェントベースモデリング . . . . . . . . . . . . . . . . . . . . 38

5.4 エージェントベースシミュレーション . . . . . . . . . . . . . . . . 38

第 6章ライフサイクルモデリング基盤 39

6.1 システム概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6.2 規定領域 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

6.2.1 ライフサイクルモデリング基盤フレーム . . . . . . . . . . . 40

6.2.2 エージェント . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6.2.3 評価機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6.3 拡張領域 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

6.3.1 拡張モデル . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

6.3.2 顧客 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

6.3.3 企業 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6.3.4 評価機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6.4 実装 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

6.4.1 Repast Simphony . . . . . . . . . . . . . . . . . . . . . . . . 48

6.4.2 ライフサイクルモデリングとライフサイクル評価の実施手順 49

第 7章ケーススタディ 52

7.1 実装 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

7.1.1 エージェント . . . . . . . . . . . . . . . . . . . . . . . . . . 52

7.1.2 シミュレーション環境の設定 . . . . . . . . . . . . . . . . . 56

7.1.3 評価機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

7.2 実験１：ビールゲーム . . . . . . . . . . . . . . . . . . . . . . . . . 56

7.2.1 問題設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

7.2.2 実験結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

3

7.2.3 考察 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

7.3 実験２：環境評価機能の確認 . . . . . . . . . . . . . . . . . . . . . 58

7.3.1 エージェント設定 . . . . . . . . . . . . . . . . . . . . . . . . 59

7.3.2 実験結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

7.3.3 考察 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

7.4 実験３：意思決定手法の改良 . . . . . . . . . . . . . . . . . . . . . 65

7.4.1 問題設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

7.4.2 実験結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

7.4.3 考察 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

7.5 実験を通しての考察 . . . . . . . . . . . . . . . . . . . . . . . . . . 72

7.5.1 今後の課題 . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

第 8章結言 74

第 9章謝辞 75

付録A プログラムソースコード 78

4

表目次

5.1 エージェント特性 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

7.1 パラメータ（実験２） . . . . . . . . . . . . . . . . . . . . . . . . . 60

7.2 積算在庫量，積算注文量，積算受注残量（実験２） . . . . . . . . . 65

7.3 パラメータ（実験３） . . . . . . . . . . . . . . . . . . . . . . . . . 66

7.4 積算在庫量，総注文量，積算受注残量（実験３） . . . . . . . . . . 71

7.5 積算在庫量（実験２，３比較） . . . . . . . . . . . . . . . . . . . . 71

5

図目次

2.1 循環型社会形成推進基本法 . . . . . . . . . . . . . . . . . . . . . . . 12

2.2 LCAの概念図 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3 LCAの構成段階 (ISO 14040より) . . . . . . . . . . . . . . . . . . . 17

2.4 LCE構成要素 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.5 ライフサイクルモデル . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1 IDEF0基本単位モデル (左)とActivityの階層化 (右) . . . . . . . . 23

3.2 ライフサイクルモデルの階層構造 . . . . . . . . . . . . . . . . . . . 24

3.3 キーワード検索 (左)とセマンティック検索 (右)の違い１ . . . . . . 28

3.4 キーワード検索 (左)とセマンティック検索 (右)の違い２ . . . . . . 28

4.1 ビールゲーム盤 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.2 ブルウィップ効果-在庫量 . . . . . . . . . . . . . . . . . . . . . . . . 33

4.3 ブルウィップ効果-注文 . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.1 マルチエージェントの概念図 . . . . . . . . . . . . . . . . . . . . . 36

6.1 ライフサイクルモデリング基盤の構成 . . . . . . . . . . . . . . . . 40

6.2 拡張モデル概念図 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

6.3 Repast Simphony：グラフィカルユーザーインターフェース . . . . 49

6.4 Repast Simphony：scoreファイル編集画面 . . . . . . . . . . . . . . 50

6.5 Repast Simphony：ＧＵＩ結果表示 . . . . . . . . . . . . . . . . . . 51

7.1 在庫推移 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

7.2 注文推移 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

7.3 環境負荷（実験２） . . . . . . . . . . . . . . . . . . . . . . . . . . 61

7.4 環境負荷の推移（実験２） . . . . . . . . . . . . . . . . . . . . . . . 62

7.5 コスト（実験２） . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

7.6 在庫の推移（実験２） . . . . . . . . . . . . . . . . . . . . . . . . . 63

7.7 注文の推移（実験２） . . . . . . . . . . . . . . . . . . . . . . . . . 64

7.8 受注残の推移（実験２） . . . . . . . . . . . . . . . . . . . . . . . . 64

7.9 環境負荷（実験３） . . . . . . . . . . . . . . . . . . . . . . . . . . 67

7.10 環境負荷の推移（実験３） . . . . . . . . . . . . . . . . . . . . . . . 68

7.11 コスト（実験３） . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

6

7.12 在庫の推移（実験３） . . . . . . . . . . . . . . . . . . . . . . . . . 69

7.13 注文の推移（実験３） . . . . . . . . . . . . . . . . . . . . . . . . . 70

7.14 受注残の推移（実験３） . . . . . . . . . . . . . . . . . . . . . . . . 70

7

第1章緒言

1.1 背景近年，国内外において拡大する競争市場の中，製品のライフサイクルの短期化により企業ではより短い時間と少ないコストで製品を生産することが重要となっている．一方，地球温暖化やオゾン層の破壊，異常気象といった環境問題の悪化，拡大が取りざたされ久しい．今後も中国，インドを初め多くの発展途上国の急速な経済発展とそれにより引き起こされる社会構造の変革により，生産活動や社会活動による環境への負荷と，それにり引き起こされる環境問題が増加していくことが懸念される．行政としても家電リサイクル法や自動車リサイクル法，エコポイント等の施策によって環境負荷の低減に取り組んできたが，根本的解決への糸口は見えていない．私たちの身の回りに環境問題の影響を実感する機会も多くなっている．東日本大震災やタイの大洪水等，世界各地において様々な自然災害が発生し，甚大な被害によって，持続可能社会というものや，プラントやサプライチェーン，製品といったものの環境調和性や持続可能性について考慮し配慮することが政府や企業に求められている．今後，環境調和型社会や循環型社会と呼ばれるものを実現していくために，企業や政府には環境を考慮し，なおかつ生産性や収益性を考慮したライフサイクル設計が不可欠である．このような相反するニーズに対応するため，原料の調達といった製品を製造する以前の段階から製造，使用，廃棄までの製品の関わる全ての過程であるライフサイクルをシミュレーションし，様々な評価指標に基づいてライフサイクルの設計を可能とする技術が必要である．従来，ライフサイクルの評価を行うための手法としてライフサイクルアセスメント（LCA）[1]が開発されてきた．しかし，LCAは環境性の評価のみに終止しており，他の指標と総合した評価・検証ができない，事後評価であり，ライフサイクルを事前に評価できない，といった問題点があった．こうした問題を解決するために LCAの概念を拡張した新しい枠組みが必要である．そこで製品のライフサイクルを的確かつ柔軟にモデル化する手法，そしてライフサイクルに関わる全ての企業・団体間での円滑な情報の共有，さらには環境性や経済性，安全性と言った様々な評価指標下において，ライフサイクルを評価・検

第 1章緒言 8

証しデザインの支援を行うライフサイクル工学 (LCE)の確立が不可欠である．

1.2 研究目的我々の研究室では，環境調和型生産に向けた取組みとしてライフサイクル工学

(LCE)の提案を行なってきた．LCEとは，既存の LCAのように環境負荷のみに着目するのではなく，安全性や経済性といった複数の評価指標の下でライフサイクルの評価を行ってライフサイクルデザインにおける意思決定を支援し，これに係る各種評価ツールや最適化手法，製品に関する情報共有・利用ツール，意思決定支援ツールなど LCEに関わる様々な情報・技術を統合するものである．従来の研究ではライフサイクルのモデルの構造や型式を定義した PLCE文書の提案が行なわれ [2]，こうして提案されたライフサイクルモデルを有効に活用する製品ライフサイクル支援システムとして，ネットワーク上に分散する外部アプリケーションやモデルとの連携を可能にするWebベースアーキテクチャと呼ばれる技術を基本とした統合環境の提案がなされてきた [3]．また，マルチエージェントシステムを用いた先行研究であるオントロジーを用いたモデル検索の提案 [4]ではネットワーク上に分散したライフサイクルの構成要素モデルの収集と有効利用のためのモデル化手法と検索手法について提案された．ここで，要素モデルとはライフサイクルを構成する各構成要素をモデル化したものである．本研究ではマルチエージェントシステムを用いて要素モデルを合成し実施するライフサイクルモデリング手法と，構築したモデルの評価手法を統合し，LCE研究を支援するためのライフサイクルモデリング基盤の開発を目的とする．ライフサイクルモデリングにおいては，企業や顧客等の複数の要素モデルをエージェントを用いてモデル化し，それらを統合することによってライフサイクルモデルを構築する．統合した要素モデルが相互に関係し，物品の生産や輸送，購入をすることによって生産活動や経済活動を行い人工社会としてのマルチエージェントシステムを構築し，それらの活動を一定時間シミュレーションすることによって評価を行う．また，本研究におけるライフサイクル評価においては，経済性と環境性を評価する．環境性評価を行うためにライフサイクルの環境性を評価する手法であるライフサイクルアセスメントを用いる．本システムを用いた実験の第１段階として，1960年代に開発されたサプライチェーンマネジメントの例題であるビールゲームに基づいたエージェントベースシミュレーションを実施する．ビールゲームのルールを拡張したシミュレーションのケーススタディとして，プリンターメーカーと商品一次卸，商品二次卸，小売業者からなるプリンターインクカートリッジのサプライチェーンを作成し，ライフサイクル評価を行う．ライフサイクルモデルの環境性を評価する際には，ライフサイクルアセスメントの手法の一つであるEco-Indicator-99[5]を用いる．また，

第 1章緒言 9

これを通し開発するライフサイクルモデリング基盤の基本性能であるモデリング性能と評価性能の評価・検証を行う．また，実験の第２段階として，エージェントの意思決定モデルの変更によるライフサイクルモデルの変更を実施し，エージェントベースシミュレーションを採用したことによる拡張性の高さについて検証を行う．

1.3 本論文の構成続く第２章では LCAを始めとする循環型社会に向けた取組みに触れ，LCAの問題点と LCE確立の必要性について明確にする．第３章ではこれまでに本研究室において提案されてきた枠組みやアプローチについて述べる．第４章では本研究で対象とするサプライチェーンの例題としてビールゲームについて紹介する．第５章では提案するモデリング基盤に用いるマルチエージェントシステムについて説明する．第６章では提案するライフサイクルモデリング基盤について詳述する．第７章のケーススタディでは開発したライフサイクルモデリング基盤を用いてエージェントベースシミュレーションを実行し，提案手法の性能を検証する．第８章を結言とする．

10

第2章循環型社会の実現に向けた取組み

循環型社会の実現に向けた取組みとして，大きく分けて行政，製品製造者，製品使用者それぞれのアプローチが考えられる．以下にそれぞれどのような取組みが行われているか挙げる．

2.1 行政によるアプローチ近年では製品に関する技術が飛躍的な進歩を遂げており，製品や各部品の電子化，モジュール化，小型化が進んでいる．これにより，以前は高級品とされていた製品の価格が下がり，我々にも身近なものとなった反面，故障時のユーザー自身での修理をほぼ不可能としてしまった．故障の際にはメーカーや，アフターサポートを担当する企業に修理を依頼するが，これによる修理もほとんどがモジュール，もしくは製品単位での交換となるのが現状である．修理を依頼するよりも，新規に購入した方が安価となるものはその際たるものである．こうした大量の製品を製造し，大量に廃棄してきた背景から，我々が豊かになるとともに廃棄物の量も増加の一途をたどり，最終処分場や廃棄物の処理方法，不法な投棄や処理など，廃棄物に関する問題が次第にクローズアップされてきた．行政も廃棄物の処理及び清掃に関する法律（廃棄物処理法）の改正により個別に対応してきたが，廃棄物の発生量が依然として減らないこと，埋め立て地の確保が年を追うごとに困難となっていること，不法処理，不法投棄が増加していることなどから根本的な解決策とはならなかった [3]．

2.1.1 循環型社会形成推進基本法

これを見て政府は平成 12年を循環型社会元年と位置づけて循環型社会についての基本的な枠組みの制定を行い，平成 12年 6月 2日，循環型社会形成推進基本法を交付し，大量生産，大量消費，大量廃棄の経済社会からの脱却と循環型社会の形成推進を目指した．この法律の概要は以下のとおりである [6]．


●形成すべき“循環型社会”を以下に示す要件により天然資源の消費を抑制し，環境への負荷が可能な限り低減される社会と定義

• 廃棄物の発生抑制

• 循環資源の循環利用

• 循環できない資源の適正な処分

●廃棄物のうち有用なものを“循環資源”と定義し，この有効利用を促進

●処理の優先順位を定義

• 廃棄物の発生抑制

• 再利用

• 再生利用

• 熱回収

• 適正処分

●国，地方公共団体，事業者，国民の役割分担を明確化

• 事業者，国民の排出者責任

• 製造者が使用後の廃棄に至るまで責任を負う拡大生産者責任

●平成 15年には政府が循環型社会形成推進基本計画を策定（5年ごと見直し）

●循環型社会形成のための国の施策を明示

• 排出者責任の徹底のための規制

• 拡大生産者責任を踏まえた措置（製品に関する事前評価）

• 再生品の使用の促進

• 原因事業者に原状回復等の費用を負担させる措置

更に，Fig.2.1に示すように個別の廃棄物，リサイクルに関係する法律をあわせて改正，整備，新規策定することにより，循環型社会に向けた実効ある取組みの推進を図った．

2.1.2 第２次循環型社会形成推進基本計画

循環型社会推進基本法により循環型社会形成推進基本計画が施行され 5年が経ち，平成 20年 5月には，第 2次循環型社会形成推進基本計画 [7]が策定された．この計画の概要は以下の通りである．


Fig. 2.1: 循環型社会形成推進基本法

●現状と課題

• 第１次計画に基づく関係主体の努力により，資源生産性の向上，循環利用率の増加，最終処分量の減少等，循環型社会の形成に一定の成果．

• 一方，世界的な資源制約，地球温暖化問題等への対応の必要性が増大．

• このため，国内・国際的に循環型社会の形成を一層推進する必要．

●循環型社会形成の中長期的なイメージ： 2025 年頃まで

• 低炭素社会や自然共生社会に向けた取組と統合した「持続可能な社会」が構築．

• 長期優良住宅の普及などにより，「ストック型社会」が形成．

• 地域特性や循環資源の性質等に応じた最適な規模の循環の形成による重層的な「地域循環圏」が構築される．具体的にはバイオマス系循環資源の利活用による食の地産地消の循環等．

• 「もったいない」の考え方に即したライフスタイルが定着し，修理してものを長く使うことや里山の恵みを活用することが広く行われる．

• この他，関係主体の連携・協働による取組の加速化，ものづくりなど経済活動における３Ｒの浸透，３Ｒと廃棄物処理システムの高度化，など．

●指標及び数値目標（目標年次：２０１５年度）


• 循環型社会への進捗状況の把握を目的とした物質フロー指標である，�「資源生産性」�「循環利用率」�「最終処分量」の数値目標を強化．

• 低炭素社会への取組との連携に関する指標（廃棄物分野の排出削減対策の目標）や，「隠れたフロー・TMR」をモニタリング指標として新たに設定．

• また，取組目標においても，１人１日あたりに家庭から排出するごみの量を 20％削減するといった数値目標の設定，モニタリング指標として「マイバッグ持参率」・「ごみ処理有料化実施自治体率」などを新たに導入．

• 熱回収

• 適正処分

●各主体の連携とそれぞれに期待される役割

• 目標の達成に向けて，国民，NGO/NPO，大学，事業者，地方公共団体など関係主体の連携と協働の下，それぞれの役割を果たすことが重要．

• 地方公共団体は地域の循環型社会形成推進の中核として，関係主体の連携・協力の推進，といった役割をそれぞれ期待．

●国の取組

• 基本的な方向として，自然の物質循環とその一部である社会経済システムの物質循環両方を視野に入れ，適正な循環を確保することとする．自然環境の保全，環境保全上健全な水循環の確保，適切な農林水産業の増進など．

• 国は，各主体とのパートナーシップを図りつつ，低炭素社会・自然共生社会との統合的な施策の推進，生活環境の保全を前提とした地域循環圏の構築，３R に関する国民運動等を推進．

• また，循環型社会ビジネスの推進や，３R の技術とシステムの高度化，施策の進捗状況を評価・点検するための情報把握や人材育成を推進．

• さらに，東アジア循環圏など，国際的な循環型社会の構築に向けた国際的な貢献を行うための施策を展開．

この計画では農村・中小都市・全国・国際といった地域の規模と特性に応じた循環圏を構築することを掲げており，なるべく小さい規模の地域循環圏で資源を循環することの必要性と各循環圏において最適な循環資源を示し，有効に地域循環を行うことを計画している．また，循環における”隠れたフロー”に着目している．”隠れたフロー”とは，例えば金属資源を輸入するためには，海外においてその21倍の重量の岩石が採掘されているという推計値がある．今後このようなフロー


をモニターし自然界から新たに採取する資源の量を少なくすし，国内における資源利用に伴う外での環境負荷を減少させることの重要性を示している．

2.2 消費者によるアプローチ循環型社会に向けた製品使用者からのアプローチとしては，必然的に製品の選択から使用段階以降，つまり積極的なリサイクル製品を始めとするグリーン購入，リサイクルへの参加，リユースがメインとなる．しかし，現段階では消費者側からの積極的なアプローチというものは多くは存在せず，行政の指導や行政との関わりの中で生まれた市民団体によるものがほとんどである．多くの製品ライフサイクルにおいて，環境負荷排出が最も高いのは使用段階であるため，真に環境について考えた場合，大きな鍵となるのは自分達である，といった意識啓蒙や風潮作りが重要となる．このような取組みのためには，行政による仕組みづくりに加え，市民団体や地域自治体による関係や協力が不可欠である．消費者側の参加するリサイクルへのアプローチとして現在では以下のようなものが行われている．

●沼津方式廃棄物を燃えるものや燃えないもの，資源物などの分別項目を作成し家庭から出るゴミを自治体などの定める集積場にあらかじめ分別された状態で収集することで，家庭からの回収率向上と回収後の分別コストの低減を目指したものである．現在広く行われているが，地域による分別項目の違いやみ分別のまま放置されるなど，モラル，地域帰属意識の低下や制度上の不備といった問題点もある．

●大阪方式

家電リサイクル法により，家電を廃棄する際には使用者の費用負担で販売者が処理業者に委託を定めたが，消費者が直接処理業者に持ち込むことにより使用者の費用負担を図り，不法投棄防止を目指したもの．

●平塚方式（日立方式）

資源物の回収に民間業者を参入させることでこの有効活用と回収コストの低減を目指したもの．

●高知方式

分別種別ごとの回収車を準備し，これが集積場を回りながら各担当種別のものを回収していくもので，回収後の分別コスト低減を目指したもの．

●カーブサイド・コレクション

分類種別ごとに各戸前の集積場におくもの．日本での分別収集制度を取入れた米国に多く見られるが，収集が行われるまでは集積場に置かれたままであ


ること，収集頻度が低い場合や集合住宅など住宅密集度が高い場合は往来脇に大量の収集物が出されることになるなどの問題がある．

2.3 生産者によるアプローチ

2.3.1 ライフサイクルアセスメント（LCA）

国際標準化機構（ISO)により規格化されたLCAは，1969年アメリカコカ・コーラ社が自社のリターナブル瓶と使い捨て瓶，どちらのライフサイクルがより環境に負荷を与えるかについての研究を，ミッドウェスト研究所に委託したのが始まりだといわれている．一般にリターナブル瓶はリユースされるため，環境負荷が小さいように思われがちだが，使い捨て瓶よりも丈夫に作る必要があるため重くなり，輸送距離が長くなったり，瓶自体が返還されないと，環境負荷が高くなる傾向がある．消費者に飲料を提供する，という同じ機能を実現する複数のものについて，環境に与える影響を定量的に評価するための手法として LCAが考えられた．現在では経済協力開発機構（OECD)や国連環境計画（UNEP)などでも分科会が設けられるなど国際的に注目を浴びている．日本では 1995年から通産省（現経済産業省）の外郭団体である産業環境管理境界が事務局となり，産学官のメンバーで構成される LCA日本フォーラムが，日本における LCAのあり方についての研究を進めている．この他にもグリーン購入ネットワークや日本環境協会，廃棄物再利用のための技術開発を目的とする Inverse Manufacturing Forumでも研究が進められている．国際的な合意の中で作成されてきた LCAの概念（Fig.2.2）とは，原材料調達から設計，製造，使用，リサイクル，そして最終的な廃棄処分まで，製品のライフサイクル全体にわたって，使用する資源やエネルギーと排出する環境負荷を定量的に推定し，評価し，製品の潜在的な環境負荷までをも評価する手法である [8]．簡単に言えば，LCAとは”環境への優しさを計る物差し”であると言える．しかしLCA

はそれだけに留まらず，研究を進めることにより科学性と客観的価値判断を基準とする標準的な評価手法の確立が可能であり，データの集積によって環境への影響のトレードオフ関係が理解できる，さらには産業界や各種団体によって蓄積された環境情報を公開するためのツールともなりうる，と言った有用性がある．

2.3.2 LCAの実施

ISO14040/44[10]では LCAは「目的・評価範囲の決定」，「インベントリ分析」，「ライフサイクル影響評価」，「ライフサイクル解釈」の四つの段階をへて実施される．以降に各段階の概略を述べ，LCAを実施する際の要点を把握する [1]．

Step1: 目的・評価範囲の決定


入力 (Input)

エネルギー

天然資源

再生資源

出力 (Output)

再生資源

固形廃棄物

大気汚染物質

水質汚濁物質

他の環境への廃棄物

製品ライフサイクル

原料・資源採取

廃棄・リサイクル

消費・使用

製品製造

部品製造

Fig. 2.2: LCAの概念図

最初にLCAを実施する目的を明確化する．具体的には”意図する用途”，”調査を実施する理由”，”結果を伝える相手”を決定する．目的を決定することで，評価範囲も決定される．評価範囲には LCAを行う対象製品の機能単位と境界，影響評価の手法や解釈の方法，前提条件，限界などがある．

Step2: インベントリ分析

LCAを実施する対象となる製品やサービスに関して投入される資源やエネルギー，および生産または排出される製品・排出物のデータを収集し，環境負荷項目に関連する入出力明細表を作成する．この入出力明細表をインベントリと呼び，インベントリ作成のためのデータ収集法・計算法には積み上げ法や産業関連表等がある．インベントリ分析では信頼性のあるデータをどれだけ収集できるかによって結果の信頼性が大きく異なるため，LCAを実施する目的に合わせて目的とする項目の詳細なデータが得られる計算法を選択する．

Step3: ライフサイクル影響評価

インベントリ分析で得られた結果から，地球温暖化，大気汚染などの各環境影響評価項目ごとに環境に与える影響の程度を分析・評価する．ライフサイクル影響評価は ISO14040，14044において規定され，どの環境問題に対して，どのような手法を用いて評価するのかという影響領域の設定，インベントリデータを関連する影響領域に振り分ける分類化，影響領域に対する環境負荷の評価の特性化が必須要素とされているが，それらは完全な合意には至っておらず，むしろ環境評価実施者の立場によって有効な手法を選択すべきであると考えられている．


Step4: ライフサイクル解釈

Step1で決定した目的・評価範囲に従ってインベントリ分析やライフサイクル影響評価の結論が合理的で在るかどうかを評価・解釈する．

LCAの実施は上記のように各段階を経て行われる．ただここでは便宜上 Step1

から Step4としたが，実際には何度も反復しながら調査する必要がある．Fig.2.3

に示すよう「目的・評価範囲の決定」，「インベントリ分析」，「ライフサイクル影響評価」，「ライフサイクル解釈」はお互いに反復しながら実施される．実際には情報を収集する段階で新たなデータが発見され目的を見直すことや，インベントリ分析の結果から資源消費の大きい箇所を探すため評価範囲を見直すといったことがありえる．

LCA の枠組み

目的・調査範囲

の設定

ライフサイクル

影響評価

インベントリ分析

ライフサイクル

解釈直接の用途

・製品の開発・改善

・戦略立案

・政府立案

・マーケティング

・その他

報告

クリティカル

レビュー

Fig. 2.3: LCAの構成段階 (ISO 14040より)

ISOではこうしたLCAの実施における枠組みを 1997年に ISO14040として発行した．その後各段階についての規格が発行されてきたが，社会情勢の変化や手法開発の発展等から再編が始まり，2006年に改定され ISO14040と ISO14044の二つの新規格が発行された．これらの規格は日本でも日本標準規格（JIS）JIS-Q-14040[9]

シリーズに規格化されている．

2.3.3 LCAの実施状況と課題

現在では環境負荷の低い製品を開発するため，設計段階から LCAを導入する企業が増えている．例えばトヨタ自動車では製造から使用，廃棄・リサイクルまでの自動車のライフサイクル全体でのCO2排出量目標を設定．そしてトヨタの工場から出るCO2排出量のほか，素材や部品製造時に排出される情報を取引先からも


集め，精度の高い LCAを実施している．また代表例としてトヨタ自動車を取上げたが，他の企業でも「エコリーフ」と呼ばれる環境ラベルの実施が行われている．エコリーフとは，製品の製造・使用・廃棄といったライフサイクルの全段階の環境負荷を定量的に占めすものであり，環境ラベルとも呼ばれ，製品ごとに環境負荷を定量的に開示することを目的としている．このエコリーフによる製品の環境負荷の情報を公開するという動きが企業でも行われている一方で，欧州 LCA普及団体 SPOLDや LCE日本フォーラムにより公共の LCAデータベースの公開なども行われているこれらの背景から従来の LCAを実施するうえでの問題であった“インベントリデータの収集”，“データの客観性”という問題が解決していくと考えられる．しかしLCAは環境影響評価ツールとしては優秀であるが，製品のライフサイクル設計において完全に対応しているというわけではない．研究背景で記述したように現実の生産においては環境負荷だけでなく，安全性，信頼性などの項目のほかに生産性，経済性など様々な評価項目の基で製品設計が行われている．そのため LCAにおける環境影響評価は，ライフサイクル決定において意思決定のうちの一つの基準としかなり得ない．また現在の LCAの多くは事後評価であり，評価結果を基にライフサイクル設計を行うという段階には至っていない．製品の製造やサービスの提供に際してその設計，企画段階において環境負荷を可能な限り低減させることを目指す設計として DfE(design for the environment)

やエコデザインと呼ばれる概念が提起されている．LCA自体は非常に有用なツールであり，この普及や展開は今後とも当然必要であるが，日々多様で複雑化していく，背品に関する工学的問題解決のための手法としては不十分な点がある環境調和型生産システム，ひいては循環型社会を実現するため，現在の LCAの枠組みを拡張し，多様な評価指標を設計開発の段階から考慮し，意思決定を可能とする新たな枠組みが必要不可欠である．

2.4 ライフサイクル工学（LCE）本研究室では前述した課題より，LCAの概念を拡張した新たな枠組であるライフサイクル工学（LCE）の考え方と，実施のための手法，支援システムを構築してきた．LCEとは製品を製造する以前の段階から，適正製造，廃棄のためにライフサイクルをシミュレーションし，経済性，環境性，安全性といった様々な評価指標の下でライフサイクルの設計を可能とする枠組みである．近年の製造業では開発スパンの短期化による迅速な意思決定と，更には規制等による適正製造，廃棄が求められている．これに加えて，行政・企業・消費者といった異なる立場の者が一体となった環境調和型生産に向けた取組みを行うため，製品と環境に対する啓蒙，行政や第三者機関，製品消費者に対しても公正な評価を可能とする情報提供や支援ツールが必要である．消費者が製品に対して求める


のは製品の供する“機能”であり，製造者に求められるのは社会で必要とされる機能を提供していくことである，と考えると，環境調和型生産とは，物を循環させ，環境負荷を低減しながら必要とされる機能を維持，更新していく生産システムである．このためには単純に排出後に廃棄物処理，製品のリサイクル，リユースを行う対処療法だけでは不十分であり，設計開発の段階からライフサイクル全体を考え，物が閉じたループを回り続けるような設計を行い，なおかつそれが社会において経済的，技術的にも受け入れられる必要がある．そのためには，製造企業側の努力だけでなく，第三者や行政による規制，監視，ユーザーによる製品の適正使用，適正廃棄といった三者の一体となった取組みが不可欠となる．製品ライフサイクルをシミュレーションし，経済性・環境性・安全性といった様々な評価指標の下ライフサイクルの設計を行うことを可能とすることにより製品のライフサイクル全体を考慮し，廃棄物が出ない，出にくい，あるいは出ても処理しやすいこと等の環境面を考慮しつつも経済的かつ技術的にも社会に受け入れられる製品ライフサイクルを製品開発・設計段階で導出することが LCEの目標である．LCEはFig.2.3に示すように，大きく分けて「ライフサイクルのモデル化技術」,

「多角的な製品評価最適化に基づいた意思決定支援」,「製品・プロセスに関する情報・技術の共有とこの有効利用」の三つから構成されている．「ライフサイクルのモデル化技術」とは，文字通りライフサイクルをモデル化する技術であり，多種多様な製品に対応できる柔軟性，またモデルに使用するデータの客観性といった点に考慮しながら研究を進める必要がある「多角的な製品評価最適化に基づいた意思決定支援」は，ライフサイクルモデルを用いて経済性や環境調和性など複数の観点から製品ライフサイクルを評価する技術であり，解析のためのシミュレーション技術や，複数の評価指標下での意思決定を支援するツールなどが必要とされる．「情報・技術の共有とこの有効利用」とは，こうした LCEに関連する様々な技術を統合して利用するための基盤を提供する要素である．ライフサイクル全体に及ぶ関連技術を単独の機関や組織で開発することは困難であるため，技術の公開を促す仕組み，また，公開された技術を組合わせて使用することが可能な統合環境の構築が求められる．

2.4.1 モデル・モデリング

システムの環境に与える影響を実際に調べるためには，ごく小さい規模で，対象とするシステムを作成し，その環境負荷を評価・検証することで最も正確に調査することができる．しかしその方法は，時間，コストがかかり，特にライフサイクルの評価において現実的とは言えない．そこでそのプロセスを処理したときにどの様に作用し環境や社会に影響がでるかを，コンピュータ上で動かして調べるといった方法をとる．この調査をシミュレーションと呼び，このときコンピュー


Fig. 2.4: LCE構成要素

タ上でプロセスを動かすものをモデル，対象のモデルを作成することをモデリング（モデル化）と呼ぶ．

2.4.2 ライフサイクルモデルとドメインモデル

製品のライフサイクルは Fig.2.5に示すように製品の製造，消費，リサイクル，廃棄といった一連の流れで構成されている．このように製品の一連の流れをモデル化したものがライフサイクルモデルである．また，このように製品の製造，消費，リサイクル，廃棄といった一連の流れをライフサイクルモデルと呼ぶとき，製造，消費，リサイクルといった個々の構成要素は要素モデルと呼ぶ．


Manufacture Consume Dispose

RecycleProcure Produce Shape Incinerate

Landfill

LC_model

process_model

Fig. 2.5: ライフサイクルモデルこのライフサイクルモデルを考えるとき，近年の産業のグローバル化もあり，一つの製品には原料調達から廃棄までの流れの中で複数の国や企業が関わることとなる．そのためライフサイクルに関わる全ての人間が各々のプロセスや物や情報のフローを共有し理解することは一般に困難である．しかしライフサイクルの構成要素である各プロセスの当事者にとって，各自のプロセスを理解し要素モデルとしてモデリングすることは比較的容易であるといえる．このようにして作成した要素モデルをウェブやネットワークを用いて検索し統合する手法が本研究室において提案されてきた．次章ではこのような課題に対し本研究室において行われてきた提案について述べる．

22

第3章従来研究

本研究室では，ＬＣＥへの取組みとして，技術や情報，システムの統合により，製品のライフサイクルにわたる環境配慮技術の評価と意思決定の支援に向けた研究を行ってきた．本章ではそれら先行研究について説明する．

3.1 情報公開の促進と柔軟運用に向けた展開LCEの確立には，ライフサイクルの最適化のためのライフサイクルのモデルが必要である．しかし，一般的にライフサイクルのモデルを自身，自社だけで作成することは困難であり，ライフサイクルの構成要素のモデル化，構成要素モデルの情報公開と柔軟運用が必要不可欠であった．本研究室では，XMLで記述されたモデル，PLCE文書を管理するためのデータベース，PLCE文書管理システムを開発し，それを柔軟に運用する製品ライフサイクル支援システム [3]を提案した．

3.1.1 PLCE文書

PLCE文書 [2]とは IDEF0を用いてモデル化した製品ライフサイクルをXMLを用いて文書化したものである．製品のライフサイクルつまり製品の原料調達から廃棄までを考えた場合，様々な分野をまたがり多くの人間が関わることになる．そのため，ライフサイクルモデルは複数の人間が各プロセスついての物や情報の流れを理解し，認識を共有する必要がある．こうした要求を満たすライフサイクルモデルの構築に機能構造モデル化手法である IDEF0を用いた．IDEF0を用いることでライフサイクルのモデル化を行えたが，IDEF0ではデータ構造を定義する機能を含んでいない．そこでライフサイクルのデータ構造の定義には人間，コンピュータにとってもデータの意味を理解しやすく，データの追加・変更などに柔軟に対応できるXML(eXtensible

Markup Language)を用いる．

3.1.2 IDEF0を用いたライフサイクルのモデル化

IDEF0[12]の基本単位におけるインプット，アウトプットにより各アクティビティ間のつながりと共に物の流れが表現できる．さらにメカニズム，コントロールを


活用することでアクティビティに関わる人や設備，または制約条件などの情報の流れが記述できる．この IDEF0の基本単位におけるアクティビティをを一つのプロセスとして考え，これを組合わせることで製品のライフサイクルモデルを構成する．以下に IDEF0の概要と，IDEF0によるライフサイクルのモデル表現法について説明する [11]．

IDEF0について

IDEF0とは機能モデリング手法とも呼ばれ，企業や組織内における経営や業務を機能という観点からモデル化しそれを分析するための手法である．IDEF0の基本単位はFig.3.1に示すように，動詞で表されれたアクティビティ(Activity)をボックスで表現し，アクティビティ間を結ぶ媒体である ICOM(Input，Control，Output，Mechanism)をボックスの上下左右に接続された矢印で表わし名詞で表現する．この基本単位を組み合わせることで業務プロセスを表現する．またFig.3.1のように階層化して表現することで複雑な業務でも表現することが出来る．アクティビティはボックス図形で表され，この中に”生産する”，”消費する”など動詞で表される機能を記述する．インプットは矢印で表され，処理される”もの”(データや物)を記述し，アクティビティの左側から入る．アウトプットには処理された結果の”もの”(データや物)を記述し，アクティビティの右側から出る．コントロールはアクティビティを制御する”もの”(条件やデータ)を記述する．メカニズムにはアクティビティに処理をさせる”もの”(人や施設，設備)を記述する．

ActivityInput Output

Control

Mechanisim

Activity A

Activity B

Activity a

Activity b

Activity c

Fig. 3.1: IDEF0基本単位モデル (左)とActivityの階層化 (右)

ライフサイクルの階層構造

IDEF0を用いて製品ライフサイクルのモデル化を行う．製造，消費などをプロセスとして捉えこれを基本単位とする．IDEF0を用いて表現した階層構造では上位レ


ベルには抽象的なプロセスを，そして下位レベルでは具体的なプロセスを記述する形となっている．階層構造は，Fig.3.2に示すようにTopレベル，Intermediateレベル，Userレベルに分かれている．TopレベルではManufacturing（製造），Consume

（消費），Recycle（リサイクル），Dispose（廃棄）の４つのプロセスが存在する．さらに IntermediateレベルではManufacturing（製造）の下位レベルにProcure（原料調達），Produce（生成），Machining（加工）といったプロセスが存在する．他の Consume，Recycleなどについても同様に下位レベルでプロセスを指定すること出来る．

Manufacture Consume

Recycle

Dispose

User Level

Intermediate Level

TOP Level

Procure Produce Shape OtherIncinerate Landfill

Process Process

Consume

MR

CR

TR

Fig. 3.2: ライフサイクルモデルの階層構造

3.1.3 XMLによるモデル表現

XMLについて

XML[13]とはタグを用いて文書の構造を定義するための言語であり，言語を記述するための言語であるからメタ言語であるといえる．ユーザが独自にタグを指定できるためデータに意味を持たせることが可能であり，階層構造になっているため複雑なデータ構造表現することが出来る．XMLの特長として，・テキスト形式・タグで記述される・ツリー構造である・コンピュータ上で扱いやすいなどが挙られる．またXMLは主に次の２つの部分からなり，これがXMLの基本的な構成要素といえる．

(1) XML宣言

XML文書の先頭行におかれ，XMLのバージョン宣言，文字コードの宣言等を行う．＜?xml version=”バージョン番号” encoding=”文字コード”?＞という形式で記述される．


(2) XMLインスタンス

実際のタグ付きデータを記述する部分である．要素（element）と属性（at-

tribute）を持ち，要素とは開始タグ＜要素名＞と終了タグ＜/要素名＞で囲まれた部分全体を呼び，属性とは要素に付加的な情報を与えるために存在し，開始タグに複数つけることが出来る．

3.1.4 PLCE文書管理システム

本システムは利用形態から実装には Java言語を用いた．Javaはインターネットへの親和性が高いこと，マルチプラットフォームであるという特徴を持つ．

• PLCE文書検索・登録機能

• 新規 PLCE文書作成支援機能

• PLCE文書検証機能

• PLCE文書インテグレーション機能

3.1.5 XMLデータベース

XML で表現された PLCE 文書の管理には，XML データベースであるXpriori

を使用する．これにより，検索の効率化，作業の簡略化を計る．本研究で使用するXpriori は，三井物産が国内販売しているXML データベース (NeoCore XMS 3.0)

の無償版である．データベースのサイズが 1GB 以内に制限されるなど，いくつかの機能的な制限が加えられているが，商用版とほぼ同等の機能が利用でき，以下のような特徴があげられる

• スキーマ定義が不要一般的にXMLデータベースは，XMLSchema やDTDなどのスキーマ定義言語を使って，あらかじめ格納できるXML文書の形式を定義しておく必要がある製品が多い．しかし，Xprioriではスキーマ定義の必要がなく，ソフトウェアをインストールした直後から，整形式の (Wellformedな)XML 文書なら，どんな文書でも格納できる．この特徴を持つことから，XML文書の形式が完全に決まっていなくても，システム開発を進めることができる．開発を進めていく中でXML 文書の形式が変更になった場合でも，XMLデータベースにスキーマ定義をする必要がないために手間がかからない．この特徴は，いったん開発したシステムの機能拡張に伴って，XML文書の形式を変更しなければならなくなった場合にも有効である


• フルオートインデックスデータベースは，XML データベースに限らず，インデックスによって検索性能を確保するのが一般的である．他のXML データベースではあらかじめデータベースにインデックスを定義しておく必要があるが，Xpriori ではインデックスの定義は不要で，格納されたXML 文書のすべての要素や値に自動的にインデックスが張られるために手間がかからない．また先にも述べたとおり，Xpriori のインデックスはDPP 技術を利用してコンパクトになっているため，ディスクやメモリなどのリソースも比較的少なくて済む．

• 一定のパフォーマンスこれもDPP 技術によって得られた特徴である．一般のインデックス技術では性能やリソースがデータ量に依存してしまうが，DPP ではパターン認識であるため，XML 文書の数，要素の名前や階層の深さ，データ量に依存せず，一定のパフォーマンスが得られる．

3.1.6 新規PLCE 文書作成支援機能

PLCE 文書作成支援機能では，ユーザがPLCE 文書の内部構造を知らなくてもモデルを作成できるように，GUI(Graphical User Interface) 上で作成できる機能を提供する．このソフトウェアは，ファイルからPLCE 文書を読み込み，その内容を変更して保存するという機能を備えているだけでなく，シミュレーションを行ない，その結果をグラフ表示するといった機能も備えている．

3.1.7 PLCE 文書検証機能

PLCE 文書検証機能とは，作成したPLCE 文書が正しく作成されているかを検証する機能である．全てのプロセスが相互に接続されているかを検証して，接続されていないプロセスが存在した場合，そのプロセス名を表示し，ユーザに修正を促す．

3.1.8 PLCE 文書インテグレーション機能

PLCE 文書インテグレーション機能とは，元となるPLCE 文書とデータベースより入手した部分的な PLCE 文書をサポートシステムに送信することにより，2

つを組み合わせたPLCE 文書を作成する機能である．これにより，ユーザは全てを自身で用意せずとも，公開されたPLCE 文書を利用してユーザ独自のPLCE 文書を作成することができる．


3.2 セマンティック検索を用いたライフサイクルモデリング支援システムの開発

一般にライフサイクルモデリングを行う際に，ユーザーが自身でライフサイクルの全ての構成要素のモデル・ドメインモデルを用意することは困難である．そこで，外部の企業や研究機関等と言った団体の提供する要素モデルを組み合わせてライフサイクルモデルを作成することが考えられる．しかし，その際に別々の企業や研究機関で作成されたモデル定義や構造が異なるということが問題となる．例えば”Woodybiomass”という情報を表す場合に場所により”Woodybiomass”，”Woody-biomass”のように異なる名称で記述していた場合は人間には意味が理解できてもコンピュータでは意味が理解できない．また同じ”Woodybiomass”という名称で記述されていてもその形状は，性質までは把握できないため．このため要素モデルを組合わせてライフサイクルモデルを作成する際に，結合した要素モデル間に整合性があるのかどうかが問題となる．この問題に対してセマンティック検索と呼ばれる情報の意味を検索する方法を用いることで，要素モデル間の整合性を取りながらライフサイクルモデルを作成するシステムが提案された．この研究により企業・団体ごとに開発された要素モデルの情報の共有が可能となった [4]．

3.2.1 セマンティック検索

セマンティック検索つまり情報の意味合いを考えた検索・検証を行うことでモデル間の整合性を確認する．そして各要素モデル間に整合性があるライフサイクルモデルの作成を目指す．セマンティック検索を用いたモデリング手法について説明し，その手法を実装したライフサイクルモデリング支援システムについて説明する．最後にバイオマスガス化発電を対象としてライフサイクルモデル作成を行い，提案したモデリング手法の有効性を確認する．

3.2.2 キーワード検索との違い

• 語彙間の意味を検索できる

最初に定義したようにセマンティック検索は情報の意味合いを考えた検索である. 情報の意味合いを考慮した検索の例をFig.3.3に示す．従来のキーワード検索ではキーワードが完全に，あるいは部分的に一致する情報を検索する.

このため人間には”木質系バイオマス”，”林地残材”という単語間に”林地残材”は”木質系バイオマス”であるという意味が推論できる場合でもキーワード検索では一致しないと判断してしまう.


これに対してセマンティック検索では語彙の意味から検索できる. ”木質系バイオマス”，”林地残材”この語彙間の関係を調べることで”木質系バイオマス”という条件で検索した場合でも”林地残材”という情報が検索される.

Fig. 3.3: キーワード検索 (左)とセマンティック検索 (右)の違い１

• 検索要件に意味を付加できる

別の特徴として検索要件に意味を付加することが出来るという特徴がある.

検索要件に意味を付加した例をFig.3.4示す. 従来のキーワード検索では「入力が木質系バイオマスのプロセス」このような情報を検索しようとしたなら”woody biomass”，”is input of”，というキーワードを全て含む，あるいはどれか一部を含むという検索を行う. すなわち”is input of”が動詞ではなく名詞として扱れ，「入力が木質系バイオマス」という意味を持つ情報を検索するのではなく単に”woody biomass”，”is input of”を含むという検索を行い指定したキーワード間には意味的な関係は存在しない.

これに対してセマンティック検索では”woody biomass”，”is input of”，”Pro-cessB”という単語間の主語，述語，目的語といった意味を認識できる. そのため”woody biomass”，”is input of”と指定することで「入力が木質系バイオマスの」という意味を持つ情報が検索できる.

is_input_of

verb

ProccesB

noun

woody_biomass

noun

is_input_of

noun

ProccesB

noun

woody_biomass

noun

Fig. 3.4: キーワード検索 (左)とセマンティック検索 (右)の違い２

3.3 本研究の特徴本研究室における従来の研究では，PLCE文書を用いたライフサイクルのモデル化，製品・プロセスの情報の共有，最適化による意思決定支援が行われた．


一方でエージェントを用いた先行研究「セマンティック検索を用いたライフサイクルモデリング支援システムの開発」[4]では，ライフサイクルに関わる全ての人間がライフサイクルに関わる全てのプロセスを共有し理解することは困難であるとし，プロセスのモデル情報そのものを共有するのではなく，ネットワーク上に起動したプロセスのエージェントを他者が検索し相互利用する手法を提案した．本研究ではこのようにして検索されたモデルを統合することによるライフサイクルモデリングの実行と，構築したライフサイクルモデルを用いたシミュレーションによるライフサイクル評価の実施を可能とするためのライフサイクルモデリング基盤の開発を行う．

30

第4章ビールゲーム

本章では，本研究において実装するシミュレーションモデルの基礎として用いるビールゲームについて説明する．

4.1 ビールゲームの概要ビールゲームとは，1960年代にマサチューセッツ工科大学スローン経営大学院においてサプライチェーンマネジメントの原理を学習するための例題として考案されたシミュレーションゲームである．考案当初は生産流通システムゲーム（Production

Distribution Game）と呼ばれていた．ビールゲームは各チームがビールゲーム盤と呼ばれるテーブルに向かい，各々がサプライチェーンの中の役割を担当することで，ビール樽に見立てたコインを流通させて顧客の需要に応え，在庫量と受注残の削減を図ることで勝敗を競うゲームである．しかし，このゲームの本当の目的は，勝敗にはない．ゲームの参加者が，一つのサプライチェーンについての意思決定を分担し，他のメンバーの圧力を相互に感じながら自らの意思決定を遂行するロールプレイングを行うことにより，「構造が行動を生む」というシステムダイナミックスの大原則を学習する．こうして，Systems

Thinkingとはどういうものかを体験的に学習し，システムダイナミックスへの入門的な役割を果たす [14]．

4.2 ルール

4.2.1 基本ルール

ビールゲームではFig.4.1に概略を示すビール盤を用いてゲームを進行する．チームメンバーが工場や卸，小売店といった役割を演じることで１チームで１つのサプライチェーンを構築し，ゲームを行う．在庫の量と受注残にはコストが発生し，最終的にはコストの総和が最も低いチームが勝者となる．ビールゲームの基本ルールは，次のとおりである．

1. 各チームはビール会社の名前を決め，記録シートに記入する．


2. 賭け金とし，一人１ドルあるいは適当な金額を集め，勝チームが全額獲得する．

3. 各チーム内で「工場」，「１次卸」，「２次卸」，「小売店」の役割を決める．

4. ゲームの目的は，チームの総費用の最小化にある．ゲーム終了時，在庫費用0.5ドル／ケース／週，受注残費用１ドル／ケース／週，として費用計算する．計算方法は，各チームの各役割担当者が各週ごとに記録した在庫および受注残を全週に渡って合計し，それぞれの合計数に 0.5ドルおよび１ドルを掛けて費用計算し，各役割ごとの総費用を求める．次に，これらをチームごとに集計し，各チームごとの総費用を求める．総費用最小のチームが，勝チームとなる．

5. チーム内においてもお互いにコミュニケーションはしない．これは，お互いに他人の活動は分からない，という実世界を反映するためである．ゲームボード盤を見渡すことだけが許される．

6. 顧客の受注量は「小売店」だけが知る．「小売店」は，他に言ってはならない．

Fig. 4.1: ビールゲーム盤

4.2.2 進行手順

Step1 物流の実行


向かって右側の「配送遅れ」の全てのコインを，在庫に進める．空になった「配送遅れ」には，その右側の「配送遅れ」の全てのコインを進める．但し，「工場」では，「生産遅れ」について同様に進める．

Step2 注文の受付

「注文中」に伏せてあるカードを開き，配送する（小売店は，「注文票」のカードを開き配送）．受注残があれば，注文数と受注残を合計し，配送する．もし，在庫が，注文数と受注残の合計よりも少なければ，在庫は全て配送し，不足数を受注残とする．開いたカードは，他人に見られないよう直ちにゲーム盤の下に隠す．

Step3 記録

在庫と受注残を記録する．

Step4 情報の進行

向かって右側の「発注」に伏せて置いてあるカードを，そのまま「注文中」に進める．「工場」では，「生産要請」に先週伏せて置いたカードを開き，その数のコインを「原材料」から最初の「生産遅れ」に進める．

Step5 注文の意思決定と発注手続き

注文数を意思決定し，記録する．注文数を記入したカードを「発注」に伏せて置く．但し，「工場」は，生産数を記入したカードを「生産要請」に伏せて置く．

4.2.3 ビールゲームの実施における導入

このようにビールゲームは複数のルール，ステップからなっており，初めてゲームを行うチームやメンバーにとっては難しく感じることが考えられる．そこで，ビールゲームを実施する導入の際には，伏せておく顧客の需要を定常とする．こうすることでサプライチェーンを流れる情報や物流は均衡状態となり，確認を容易にすることが可能である．このように初期の段階では各メンバーがゲームに慣れることができるよう促すことが有効である．

4.3 ビールゲームの狙い以上のようにビールゲームを実施し，総費用を計算することでチームの勝敗を決める．そしてビールゲームを行った後にはゲームの省察を行う．省察は，各チームの各役割ごとに毎週記録した在庫と受注残および注文をグラフに書いてもらい，壁に貼ることから始める．これらのグラフを相互に比較すると，数量的には異なっ


てはいても，全体の挙動のパターンは全チームともよく似ていることが一目瞭然となる．外生変数である顧客からの注文の変化に対し，各役割の担当者の意思決定は，いずれのチームにおいても，サプライチェーンの上流に行くにつれて増大し，在庫と受注残に大きな変動を引き起こしているのである．このようにFig.4.2，Fig.4.3に示すような現象をブルウィップ効果（Bullwhip Effect）という．変動する需要が，サプライチェーンの上流にさかのぼるにつれ，より大きな変動として拡大していく現象が鞭がしなる様に似ているため，このように呼ばれている．ここでゲームリーダは，参加者と会話し，なぜこの時点でこのような大量発注をしたか考察する．チームメンバーの圧力を感じたか，自分の失敗はチームメンバーの責任だと思ったか，顧客の注文は大きく変動するパターンだと思うか，などの確認をして，本当の原因を探索していく．在庫の減少や受注残の増大といった「事象」は，システムのプロセスからもたらされる行動であり，このような行動はシステムの「構造」から必然的に引き起こされることを，参加者に体験的に学習してもらうことがビールゲームの目的である．

Fig. 4.2: ブルウィップ効果-在庫量


Fig. 4.3: ブルウィップ効果-注文

4.4 ライフサイクルモデリング基盤への適用本研究においてライフサイクルモデルを作成するために，まず，ライフサイクルを構成する各要素をモデリングし要素モデルを作成する．次にそれら要素モデルを統合することで，最終的にライフサイクルモデルを構築する．本研究ではライフサイクルモデリングを実行するユーザーのモデリングの実施支援を目的とし，ビールゲームを参考としたライフサイクルのテンプレートを作成した．ビールゲームの「会社」の構成要素である「工場」，「１次卸」，「２次卸」，「小売店」そして，ビールゲームには無い要素である「顧客」をモデル化し，エージェントベースモデリングという手法により統合することで本研究において基本とするライフサイクルのモデルを構築する．また，ライフサイクル評価を実施するためにライフサイクルにおける物や情報の流れをエージェントベースモデリングにより作成したモデルを用い，エージェントベースシミュレーションを実行する．その際にどのような手順でシミュレーションを進行するかビールゲームの手順を参考としてライフサイクルモデリング基盤のフレームの 1つとして定義した．第 5章ではこのエージェントベースモデリングとエージェントベースモデリングによって作成するモデルを用いて実行するエージェントベースシミュレーショ


ンの特性について詳述する．

36

第5章マルチエージェントシミュレーション

本章ではマルチエージェントシステムを用いて実施するエージェントベースモデリングとエージェントベースシミュレーションについて説明する．

5.1 マルチエージェントシステムマルチエージェントシステム（MAS）[15]とは，複数の独立したソフトウェア・エージェントにより人工社会を構築するシステムである．MASの構成要素であるエージェントは，何者かの代理として何らかの動作をシステム内で行なう．エージェントは互いに協力的・非協力的な意思決定と挙動をとりつつも，相互作用を及ぼしあい人工社会としてのMASを構築する．複数のエージェントにより構築されるＭＡＳは構成するエージェント一つ一つの特性を生かしつつ社会現象や人間関係といった複雑で巨大な問題を解くことができるのが特徴である．

エージェント

エージェントエージェント

エージェント

エージェントエージェント

依存依存

依存依存依存

依存依存

依存

Fig. 5.1: マルチエージェントの概念図


一般的にマルチエージェントシステムは下記のような特性を持つ．

• 頑強性

ある特定のエージェントが故障・停止しても全体の停止につながらない

• 柔軟性

エージェントの拡張・削除が容易である

• 負荷分散

集中管理の仕組みを持たないため，負荷の分散が出来る

5.2 エージェントエージェントとはマルチエージェントシステムを構成する要素である．計算機科学の多くの分野，例えば人工知能，ネットワーク，ヒューマンインターフェース，ソフトウェアエンジニアリングなどの分野において，研究者や技術者が目指しているものは何らかの「知的」で「自律的」なソフトウェアやシステムである場合が大半である．エージェントは実社会における何者かのモデルとして，その者と同じように行動し，システム内やネットワークを跨ぎ，他のエージェントと通信することで人工社会を構築する．実際にシステムとして人間や設備といった社会の構成要素を完璧に再現することは非常に困難である．しかし，限られた条件下において，対象をモデル化し，対象の特性を表現することが可能である．このモデリング手法を使うことにより，各エージェントが持つ挙動モデルを実行することで対象とするシステム（マルチエージェントシステム）の全体的な挙動のシミュレーションを行うことが可能となる．エージェントとは一般的に以下のような特性のいくつかを持つオブジェクトである．


Table 5.1: エージェント特性

特性備考自律性自らの目標を達成するために，自らの意思決定原理に基づいて　環境を認識し，行動する．協調性環境内にいるほかのエージェントと共通の目標を達成するため

の共同作業ができる．持続性自己概念を継続的に保持する．適応性個々あるいは共同で，経験を通して自らの能力を高めていける．代理性ユーザから一定の権限を譲渡され，ユーザの代理人としてその

権限を行使する．分散性ネットワークを跨いで複数のエージェントが一連の処理を

分担して実行できる．移動性ネットワーク上でホストからホストへ移動できる．

5.3 エージェントベースモデリングエージェントベースモデリングとは，個々のエージェントという構成要素において行動モデルを定義することで，全体的な挙動をボトムアップ的にモデル化する手法である．このモデリング手法を使うことにより，各エージェントが持つ挙動モデルを実行することで対象とするMASの全体的な挙動のシミュレーションを行うことが可能となる．本研究ではライフサイクルにおける工場や卸，小売店，顧客といった構成要素の販売や輸送，生産といった挙動をエージェントにおいて定義し，MASとして統合しサプライチェーンのモデルを作成する．

5.4 エージェントベースシミュレーションエージェントシミュレーションとはこのように作成したモデルを用い，対象とするシステムのシミュレーションを行なう手法である．エージェントベースシミュレーションでは個々のエージェントの特性を活かしつつ，システム全体の挙動をシミュレーションし評価を実施できる特徴がある．本研究ではエージェントベースモデリングによって作成したサプライチェーンのモデルを用い，対象とするシステムの対象とする期間におけるシミュレーションを実行することでライフサイクルモデリングを実施し，ライフサイクルにおける評価を実施する．

39

第6章ライフサイクルモデリング基盤

本章では本研究において開発したライフサイクルモデリング基盤（LCM基盤）と，ライフサイクルモデリング基盤において用いるライフサイクルモデルリング手法とライフサイクルの評価手法について提案する．

6.1 システム概要ライフサイクルモデリング基盤の構成は下記の通りである．

• ライフサイクルモデリング基盤フレーム

エージェント間インターフェースとシミュレーションの規則が定義されている．

• エージェント

ライフサイクルモデルの構築を実施するためのドメインエージェント群である．

• 評価機能

経済性や環境性の評価を実施するための機能である．

ライフサイクルモデリング基盤の構成図をFig.6.1に示す．なお，拡張領域の各要素は本研究において行ったケーススタディで開発した一例である．このようにライフサイクルモデリング基盤はライフサイクルモデリング基盤フレームとエージェント，評価機能の３つの構成要素から成っている．また，これら構成要素はそれぞれ規定領域と拡張領域に区分される．


Fig. 6.1: ライフサイクルモデリング基盤の構成

規定領域ではモデルの作成や，評価機能の根幹となる部分を定義しており，ライフサイクルモデリングやライフサイクル評価の処理を適切に実行するために，変更することができない内容が含まれている．拡張領域の内容は，各ユーザーがライフサイクルモデリング基盤を用いてライフサイクルモデリングやライフサイクル評価を行う際に自由に変更できるものである．例えばライフサイクルモデルを構成する要素モデルであるエージェントの種類や数，意思決定モデルといった内容は自由に変更することが可能である．

6.2 規定領域

6.2.1 ライフサイクルモデリング基盤フレーム

ライフサイクルモデリング基盤フレーム（LCM基盤フレーム）では各エージェント間のインターフェースやシミュレーションの規則や手順といったものが定義


されている．これらはエージェントベースシミュレーションを実施する上で，全エージェント間において情報や物の流れが正常に行われ，評価機能によって各エージェントが適切に評価されるために定義されているものである．ライフサイクルモデリング基盤のユーザーはモデリングをする際に自由にエージェントの内容を変更し，評価方法等もユーザーの目的に合ったものに変更することが可能であるが，その際には，LCM基盤フレームにおいて定義されている以下の規則を守る必要がある．

エージェント間インターフェース

モデリングに用いる各エージェントは相互に情報や物を送り合い，エージェントベースシミュレーションを実行していく．このような処理は実際にはコンピュータ上におけるプログラムとして実行される．そのため，ユーザーがモデリングを行う際にエージェント間の情報が適正に処理されるようエージェント間の情報や，エージェントが所持する情報には一定の規則を定義した．大別して下記の項目について規則を定義した．

• 注文-受注規則

サプライチェーンの上流に注文を実行するための規定である．

• 発送-受取規則

サプライチェーンの下流に輸送を実行するための規定である．

• 評価規則

評価機能がコストや環境性の評価を実行するための規定である．

シミュレーション規則・手順

モデリングにおいて，各エージェントを定義する際に，エージェントの挙動は他のエージェントと同調し，決められた順序にて動作するよう定義する必要がある．ライフサイクルモデリング基盤フレームにおいてこの順番を下記の通り規定した．

Step０：初期設定フェーズ

各エージェントや評価機能の初期設定を行うフェーズである．

Step１：情報実行フェーズ

情報実行フェーズでは，主に注文の発注と，発注した注文の進行を実行することが可能である．注文を発注する際には注文量を決めるために注文意思決定モデルを用いる必要がある．


Step２：物流実行フェーズ

物流実行フェーズでは，輸送の発送や，発送した輸送の進行，生産の実施等の実際に物が動く挙動を実行することが可能である．

Step３：評価フェーズ

評価フェーズでは，各エージェントにおいてコスト等の計算を行い，評価機能による評価を実行する．

Step３実行後は Step１に戻る．シミュレーションでは Step１～Step３を1tick[day]とした．

このような Stepをシステムの全エージェントが同調し実行することで正常な情報や物の流れをシミュレーションし，適正な評価を実施する．

6.2.2 エージェント

ライフサイクルモデリング基盤において，ライフサイクルをモデリングするために第 5章において説明したエージェントベースシミュレーションを用いる．エージェントはエージェントベースシミュレーションにおいてライフサイクルの構成要素をモデル化した要素モデルであり，要素モデルを合成することによってライフサイクルモデルを構築することが可能である．

基礎モデル

基礎モデルとはライフサイクルモデリング基盤フレームにおいて定義されるエージェント間インターフェースや，ソフトウェアとしてエージェントを実装するために必要な最低限の機能や挙動を定義したものである．全てのエージェントはこの基礎モデルをベースとして開発することでエージェント間インターフェースを始めとするエージェントの基本的特性を適切に実装することが可能である．基礎モデルが実装している内容は下記の通りである．

• エージェント機能

コンピュータ上及びネットワーク上においてエージェント群の存在する空間であるエージェントコンテナーへの登録，エージェントコンテナーに存在する他のエージェントの認識，他のエージェントとのネットワークの作成，他のエージェントとの tickの同調といったエージェントとしての基礎的な機能を実装した．

これらの機能は後述するエージェントシミュレータ・Repast Simphonyを用いて実装した．


• エージェント間通信機能

注文・受注・物の発送・受取りの挙動が実装されている．拡張領域ではこのようなエージェント間のやり取りを実装できない．

• 被評価機能

評価機能によって適切に評価が実行されるための機能が実装されている．なお，現在定義されている評価項目はコスト推移，キャッシュフロー推移，環境影響評価推移である．

• ユーザーインターフェース機能

エージェントの挙動履歴や在庫推移，注文量といった内容をユーザーに提示する機能が実装されている．

6.2.3 評価機能

● Monitoring Service

Monitoring Serviceはシステム内のドメインエージェントの行動を随時監視し，製品の製造や使用，物質の使用，輸送等により発生する環境負荷や，在庫や受注残によって発生するコスト，キャッシュフローを計算する．環境負荷を算出する際には，ライフサイクルの環境性評価を行うための手法であるライフサイクルアセスメントを用いる．

これにより得られる環境性及び経済性データは当該のエージェントと次に紹介する Supply Chain Evaluation Serviceに送られる．

ドメインエージェント dの活動に対して発生する環境負荷 I(d)[mPt]はライフサイクルアセスメントによって以下のように求められる．

I(d) =N∑i=1

wix(d)i (6.1)

wi：環境負荷因子 iが単位量当たり環境に与える環境負荷x(d)i ：エージェント dにおける環境負荷因子 iの使用量．(i = 1, 2,…I)

ドメインエージェント dの活動によって発生するコストC(d)[＄]は以下である．なお，キャッシュフローの算出は同様である．

C(d) =N∑j=1

ujc(d)j (6.2)


uj：コスト発生要因 jの単位量あたりに発生するコストc(d)j ：エージェント dにおけるコスト発生要因 jの量

● Supply Chain Evaluation Service

Supply Chain Evaluation Serviceは各サプライチェーン毎のコストや環境負荷を監視し，評価するシステムである．サプライチェーン sにおける環境負荷 I(s)は以下．

I(s) =N∑d=1

I(d) (6.3)

サプライチェーン sにおけるコストC(s)は以下．なお，キャッシュフローの算出は同様である．

C(s) =N∑d=1

C(d) (6.4)

また，全てのサプライチェーンのコスト，キャッシュフロー，環境負荷を合計しシステム全体での評価を行う．システム全体における環境負荷 Iは以下．

I =N∑s=1

I(s) (6.5)

システム全体におけるコストCは以下．なお，キャッシュフローの算出は同様である．

C =N∑s=1

C(s) (6.6)

ライフサイクル設計においてはユーザーが直接操作するライフサイクルの環境負荷が低下してもシステム全体では負荷が増加するということが考えられる．これはライフサイクルとして定義する範囲の問題でもあるが，最終的に環境への影響を低減するためにはシステム全体の環境負荷を低減していく必要がある．

6.3 拡張領域拡張領域におけるエージェントと評価機能の内容はユーザーが自由に変更することが可能である．拡張領域におけるエージェントの拡張モデルや環境評価に用いるライフサイクルアセスメント，経済性評価手法の変更によってユーザーは多彩なライフサイクルモデリングとライフサイクル評価を実行することが可能となる．


6.3.1 拡張モデル

拡張モデルとは基礎モデルに加え，情報を内部的に処理するための挙動を追加したモデルである．この領域においてユーザーは自由にモデルを作成することが可能である．拡張モデルは複数の内部モデルからなる（Fig.6.2参照）．

Fig. 6.2: 拡張モデル概念図

内部モデル

内部モデルとは注文，在庫管理といったエージェントが内部的な処理を実行するための挙動を実行するための，拡張モデルの構成モデルである．ユーザーはこの内部モデルを，開発されたライブラリから選択し拡張モデルを実装することや，自身で開発することにより拡張モデルを実装することが可能である．また，内部モデルも複数のモデルから構築することが可能である．

次に，本研究の実験において実装した顧客と企業の拡張エージェントの一例の概要を紹介する．

6.3.2 顧客

本来のビールゲームでは顧客の需要量はカードに書かれ裏にして置かれている．しかし実際の社会では顧客は意思決定を行う個別の人間であり，その需要量の決


定は決められた通りのものでも，ランダムでもない．サプライチェーンマネジメントにおいては顧客の需要を予測することが重要となっているが，これは非常に困難である．また，顧客の行動プロセスが定義されない状態では顧客による環境への影響を評価することができない．そこで本研究では顧客を要素モデルとしてモデル化し顧客の需要や環境負荷を求めた．

消費者購買意思決定モデル

ライフサイクル評価においては，消費者の使用段階における環境負荷も大きいため，顧客の意思決定や行動をどのように解析するかが非常に重要である．また，本モデリング基盤はマルチエージェントシステムを用いることで，実社会における個別の構成要素をモデル化し，それらを統合することによって人工社会を構築することを可能としている．その人工社会においては個別の要素の特性が活かされていることから，顧客の購買プロセスを消費者意思決定モデルとして再現することがリアリティのあるモデリングを実現する上で有効である．以上の要求に基づき本研究では，顧客の製品の使用と購入のプロセスを購買意思決定モデルによって定義し，製品使用による環境負荷の算出とサプライチェーンにおける需要量の決定を行う．消費者購買意思決定モデルは下記のような流れで定義する必要があるが，より厳密なライフサイクルモデリングを実施するためには，製品の特性毎に十分に適切であると考えられるプロセスを設定し使用する必要がある．

Step1: 製品を消費する．

Step2: 製品の購入個数を決定する．

Step3: 発注を行う．

マルチコンシューマー

以上のように定義した顧客は複数存在し，個別に意思決定を行い購買行動を行う主体である．本ライフサイクルモデリング基盤においても顧客は複数設定することが可能であり，小売店における製品 kの需要量R(k)は顧客の発注量の総和である．

R(k) =N∑i=1

r(k)i (6.7)

r(k)i ：顧客 iの製品 kの発注量


6.3.3 企業

ライフサイクルモデリング基盤において実装するエージェントの構成の一例を以下に示す．これらは第 7章ケーススタディにおいて用いたものである．ライフサイクルの構成は無数に考えられるため，ユーザーが厳密なライフサイクルモデリングを実施するためには独自のエージェントを開発する必要があるが，下記のエージェントの製品，各段階において発生する環境負荷因子，初期設定パラメータ，意思決定モデル等を変更することでシンプルなライフサイクルをすぐにモデリングすることが可能である．

● Factory Agent

Factory Agentは工場をモデル化したエージェントである．サプライチェーンの最も上流に位置するエージェントであり，製品を製造し，Distributor Agentの注文を受けて製品を輸送する．

なお，本研究におけるグラフ等では製品の製造指示は「注文」として扱っている．

● Distributor Agent

Distributor Agent は１次卸をモデル化したエージェントである．Factory

Agentから輸送された製品を在庫として所持し， Wholesaler Agent からの注文を受け製品を輸送する．

● Wholesaler Agent

Wholesaler Agentは２次卸をモデル化したエージェントである．Distributor

Agentから輸送された製品を在庫として所持し， Retailer Agent からの注文を受け製品を輸送する．

● Retailer Agent

Retailer Agent は小売店をモデル化したエージェントである．Wholesaler

Agentから輸送された製品を在庫として所持し， Customer Agent からの注文を受け製品を販売する．

● Customer Agent

Customer Agentは顧客をモデル化したエージェントである．Retailer Agent

から販売された製品を消費し，無くなると製品を購入する．

6.3.4 評価機能

規定領域における評価機能として経済性評価の項目と環境性評価におけるライフサイクルアセスメントの使用を規定した．拡張領域においてユーザーが変更できる内容は下記の通りである．


経済性評価手法

経済性の評価項目であるコスト，キャッシュフローをどのように評価するかを変更することによって経済性評価機能を拡張することが可能である．

ライフサイクルアセスメント

ライフサイクルアセスメントは国，地域，産業，主義によって様々なものが提起されている．環境性の評価を行う際には，それぞれのケースによってライフサイクルアセスメントの種類を使い分けることが有効である．

6.4 実装ライフサイクルモデリング基盤を実装したプログラムについて説明する．本システムはエージェントシミュレータRepast Simphonyを用いて実装しており，エージェントの実装手順はRepast Simphonyの利用手順に準拠している．また，これらのプログラムは Javaを用いて作成されている．

6.4.1 Repast Simphony

Repast SimphonyはMichael North氏を中心とするRepast Development Team

によって開発されたエージェントベースシミュレータの 1つである [16]．Repast Simphonyの機能は下記のようになっている．

• エージェントベースモデリング

エージェントと，エージェント空間であるコンテナーを作成しエージェントベースモデリングの実施を支援している．

• エージェントベースシミュレーション

作成したモデルを用いたシミュレーションの実行を支援している．

• グラフィカルユーザーインターフェース機能

各エージェントのプロパティをグラフィカルユーザーインターフェース（GUI）に出力する（Fig.6.3参照）．


Fig. 6.3: Repast Simphony：グラフィカルユーザーインターフェース

6.4.2 ライフサイクルモデリングとライフサイクル評価の実施手順

Step1: パラメータ設定

ライフサイクルモデリングにおいて用いるエージェントとエージェント同士を接続するネットワークと呼ばれるインスタンスを拡張子.scoreのファイルを用いて登録する [17]．Fig.6.4はその編集画面である．このように上段において使用するエージェントを登録し，下段においてエージェントの名称や表示名，ソースファイルのアドレスを設定する．


Fig. 6.4: Repast Simphony：scoreファイル編集画面

Step2: Agent‐Factory Agent‐

エージェントの実装の紹介として Factory Agentのソースファイルを本論文の付録として付す．作成したエージェントはBNContextBuilder.javaにおいてインスタンスとして起動する．

Step3: Network

ネットワークとはエージェント空間コンテナーにおいてエージェント同士を接続するためのインスタンスである．各エージェントはネットワークを介して他のエージェントと通信を行う．

Step1において作成したネットワークは BNContextBuilder.javaにおいてインスタンスとして起動する．

Step4: シミュレーション

repast.simphony.runtime.RepastMainを実行しエージェントベースシミュレーションを行う．


Step5: 結果表示

結果は Fig.6.5に示す様に随時出力され，ユーザーはシミュレーションの経過を確認することが可能である．

Fig. 6.5: Repast Simphony：ＧＵＩ結果表示

Step6: シミュレーション結果の処理

コストや環境負荷の推移といったシミュレーション結果は csv形式で保存されるため，エクセル等で表示，編集し分析することが可能である．

52

第7章ケーススタディ

本章では第 6章において提案したライフサイクルモデリング基盤を用い，実際にいくつかのシミュレーションを行い結果を評価することで，ライフサイクルモデリング基盤としての基本性能であるモデリング性能とライフサイクル評価の性能を検証する．

7.1 実装本研究において実験の一環として実装した内容を説明する．

7.1.1 エージェント

実験において用いたエージェントの構成は下記の通りである．ただし，実験１ではCustomer Agentを用いず，需要量はランダムに生成した．

エージェント構成

● Factory Agent

Factory Agentは工場をモデル化したエージェントである．サプライチェーンの最も上流に位置するエージェントであり，製品を製造し，Distributor Agentの注文を受けて製品を輸送する．

なお，本研究におけるグラフ等では製品の製造指示は「注文」として扱っている．


Distributor Agent は１次卸をモデル化したエージェントである．Factory

Agentから輸送された製品を在庫として所持し， Wholesaler Agent からの注文を受け製品を輸送する．



Wholesaler Agentは２次卸をモデル化したエージェントである．Distributor

Agentから輸送された製品を在庫として所持し， Retailer Agent からの注文を受け製品を輸送する．

● Retailer Agent

Retailer Agent は小売店をモデル化したエージェントである．Wholesaler

Agentから輸送された製品を在庫として所持し， Customer Agent からの注文を受け製品を販売する．

● Customer Agent

Customer Agentは顧客をモデル化したエージェントである．Retailer Agent

から販売された製品を消費し，無くなると製品を購入する．

ドメインエージェントにおける注文意思決定モデル

本来のビールゲームにおいてチームの各メンバーが役割を演じる中で決定する注文数を，本モデリング基盤で作成するシミュレーションでは各エージェントが自動で行う．注文を決定する際には現在の在庫量の認識と今後の需要の予想をして注文量を決定するモデルを用いた．本シミュレーションでは予想需要 eと発注量 oを以下のように求めた．なお，この注文量式は文献 [18][19][20]を参考とした．

e = θd+ (1− θ)e (7.1)

o = max(e+ α(q − v − βs), 0) (7.2)

d：前回の受注量v：現在の在庫量s：前回輸送を行った量θ, α, q, β：パラメータ

ここで θは直近の需要と前回の需要をどの程度予想に反映させるかのパラメータである．αは理想的な在庫量からどの程度余裕を持つことを許容するかを示すパラメータである．qは理想在庫の量を示すパラメータである．βは既に輸送を行った分を発注量から減らすためのパラメータである．なおエージェントの初期設定について後述するが，初期状態における在庫量は qとした．


消費者購買意思決定モデル

消費者購買意思決定モデルを下記のように定義した．

Step1: 製品を消費する．

製品 kの使用個数m(k)は下記の範囲における整数の一様乱数である．

M(k)Min ≤ m(k) ≤ M

(k)Max (7.3)

M(k)Max,M

(k)Min : 製品 kの使用個数の上限，下限

ただし一年毎に，消費量が多い日を設定し，その日に限りmの範囲を下記の範囲における整数の一様乱数とした．

M(k)Min +M (k)

r ≤ m ≤ M(k)Max +M (k)

r (7.4)

M(k)r : 使用個数の増加数

なお，初期設定においては顧客はランダムに製品を選択する．使用によって在庫が無くなることで step2へ移る．

Step2: 製品の購入個数を決定する．

なお，購入個数 nは以下の範囲における整数の一様乱数である．

N(k)Min ≤ n ≤ N

(k)Max (7.5)

N(k)Max,N

(k)Min：製品 kを購入する際の上限，下限

Step3: 発注を行う．

エージェント初期設定内容

各エージェントにおける初期設定内容は下記の通りである．

● Factory Agent

• モデル名

• 製品名 k

• 製品 kの製造に必要な原材料名 iとその量 xi


• 製品 kの製造に必要な加工工程名 iと加工量 xi

• パラメータ


• モデル名

• 製品名 k

• 製品 kの輸送に使用する手段の種類 iと輸送距離 xi

• パラメータ


• モデル名

• 製品名 k


• パラメータ

● Retailer Agent

• モデル名

• 製品名 k


• パラメータ

● Customer Agent

• モデル名

• 毎日の使用製品と使用量の上限M(k)Max及び下限M

(k)Min

• 製品使用量の増加する日 h(k)とその量M(k)r

• 製品を消費する際に関連して使用する物質 iとその量 xi

• 製品を廃棄する方法 iと廃棄量 xi

• 製品購入個数の上限N(k)Max及び下限N

(k)Min


7.1.2 シミュレーション環境の設定

● シミュレーション期間

● 製品の耐用回数

製品の耐用回数 t(k)を決定する．

● 顧客数

上記方法で設定したCustomer Agentを起動する数を決定する．

7.1.3 評価機能

環境性の評価を行う際に用いるライフサイクルの評価手法であるライフサイクルアセスメントとして，Eco-Indicatorを実装した．

Eco-Indicator

Eco-Indicator は，製品等からの排出物質によって引き起こされる地球温暖化，オゾン層破壊，資源枯渇等の様々な環境影響を評価するための手法である．これらの環境影響は，人の健康への被害，生態系への被害，資源への被害という 3つの被害として計算される．これら 3つの被害は「重み付け」されて，物質１ [kg]当たり何ポイント [mPt]というように一つの指標で表される．

7.2 実験１：ビールゲーム本研究においてベースとしたビールゲームをモデルとして，ビールを供給するサプライチェーンのエージェントを定義し実験を行った．

7.2.1 問題設定

Factory Agent-Distributor Agent-Wholesaler Agent-Retailer Agentからなるビール会社のサプライチェーンに最小値 0，最大値 3 の一様分布から生成する乱数を需要として与えた．


7.2.2 実験結果

ビールゲームシミュレーションを実行したところ，Fig.7.1，Fig.7.2に示すように，サプライチェーンの上流に行くに従い在庫量及び注文数の変動が大きくなる現象・ブルウィップ効果を確認できた．

Fig. 7.1: 在庫推移


Fig. 7.2: 注文推移

7.2.3 考察

本実験ではブルウィップ効果を確認した．ブルウィップ効果はサプライチェーンマネジメントにおける基本的かつ重要な課題であり，実際のサプライチェーンにおいてはこのような現象が発生しないことが望まれる．しかし本モデリング基盤におけるシミュレーションによってこれを削減していく過程は，ビールゲームの本来の目的であるサプライチェーンマネジメントの教育や啓発といった点で有効であると言える．

7.3 実験２：環境評価機能の確認プリンターインクカートリッジを販売するサプライチェーンを作成し，5年間でプリンターインクカートリッジがシステムの環境に与える負荷を評価する．この実験を通し，本ライフサイクルモデリング基盤におけるライフサイクル評価機能の確認を行う．


7.3.1 エージェント設定

50人の顧客とインクカートリッジを供給する１つのサプライチェーンからなるシミュレーションを 5年間分実行する．各エージェントにおいて環境負荷因子を下記の通り設定した．

環境負荷因子

工場でインクカートリッジ１個を生産するために用いる資材は下記である．

• PET：0.05[kg]

• PP：0.45[kg]

• PS：0.5[kg]

また，加工工程は下記である．

• Injection moulding：1.0[kg]

１次卸，２次卸，小売店においては輸送の時にのみ環境負荷が発生するとした．Eco-Indicatorでは輸送を行う際にトラックの種類と輸送距離を指定する必要がある．実際に輸送する際にはインクカートリッジだけでなく他の製品も一緒に輸送されると考えられるが，今回はインクカートリッジのみが輸送の対象となるので，製品の重量をトラックの積載量で除し，インクカートリッジ１つあたりの環境負荷を算出した．工場から１次卸における輸送手法と輸送距離は下記とした．

• Truck 28t：100[km]

１次卸から２次卸における輸送手法と輸送距離は下記とした．


２次卸から小売店における輸送手法と輸送距離は下記とした．


使用段階において環境に影響を与える物として印刷に使う用紙が挙げられる．一回の印刷において使用する用紙の量を下記とした．

• Paper：0.01[kg]

廃棄段階において製品一個当たりに下記の物質を焼却することとした．

• Incineration PP ：1[kg]


パラメータ設定

サプライチェーンにおける各エージェントのパラメータ θ，q，α，βはそれぞれ下記のように設定した．

Table 7.1: パラメータ（実験２）

エージェント名 θ q α β

Factory 0.48 120 0.083 0.091

Distributor 0.22 140 0.060 0.059

Wholesaler 0.12 130 0.066 0.17

Retailer 0.10 90 0.28 0.16

顧客設定

顧客は毎日 m枚の印刷を行い，それによってインクが無くなると発注を行う．MMaxを 30,MMinを 1としたので，各Customer Agentにおける毎日の印刷枚数は下記の範囲における整数の一様乱数である．

1 ≤ m ≤ 30 (7.6)

ただしMr を 30と設定したので，その日に限りmの範囲は下記の範囲における整数の一様乱数である．

31 ≤ m ≤ 60 (7.7)

また，インクカートリッジの耐用回数を 100回とした．

7.3.2 実験結果

各エージェントにおける環境負荷とコストの総計，及び推移は以下のようになった．なお，環境負荷とその他の推移についてはシミュレーション起動直後は物流が乱れるため 1001日目から 1070日目までを基にしグラフを作成した．


環境負荷・コスト

Fig. 7.3: 環境負荷（実験２）


Fig. 7.4: 環境負荷の推移（実験２）

Fig. 7.5: コスト（実験２）


在庫・注文・受注残

Fig. 7.6: 在庫の推移（実験２）


Fig. 7.7: 注文の推移（実験２）

Fig. 7.8: 受注残の推移（実験２）


Table 7.2: 積算在庫量，積算注文量，積算受注残量（実験２）

エージェント名積算在庫量総注文量積算受注残量Factory 231758 41429 13879

Distributor 267120 41505 19953

Wholesaler 238008 41599 33661

Retailer 180199 41677 27500

Total 917085 166210 94994

7.3.3 考察

環境負荷のグラフを見ると Factoryにおける環境負荷が突出して高いことが分かる．次にCustomerであるが約 50倍の差がある．インクカートリッジのライフサイクル負荷を軽減するためには製造と使用における環境性負荷の低減を行っていく必要があるだろう．例えば，インクカートリッジのリユースやリサイクルにより環境負荷の低減を図ることが有効であると考えられる．また，本実験では電力や燃料の使用による環境負荷を考慮していない．より厳密な環境負荷を計測するためには LCAにおけるインベントリ分析において，各モデルにおけるより厳密な情報収集が必要となるだろう．本実験では作成したライフサイクルモデルを用い環境性及びその他の項目の評価を実施し，本ライフサイクルモデリング基盤が一定の環境性評価性能を有していることを確認した．

7.4 実験３：意思決定手法の改良主な問題設定は実験２の問題設定を引き継ぎ，注文意思決定モデルの改善の実験を下記の問題設定において行い，ライフサイクルモデリング基盤の拡張性の検証を行った．

7.4.1 問題設定

小売店の所持する顧客からの需要情報Rをサプライチェーンの全てのエージェントで共有する．また，注文量を求める際に需要量の移動平均Eを用い注文意思決定関数 oを下記のように変更し改良した．

E =50∑i=1

di (7.8)


e = (1− η)(θd+ (1− θ)E) + η ∗R (7.9)

o = max(e+ α(q − v − βs), 0) (7.10)

di：i日前の需要量R：小売店における顧客からの需要量η：パラメータηは小売店における需要と自身が受けた注文数を想定需要に反映させるための割合を示すパラメータである．

パラメータ設定

サプライチェーンにおける各エージェントのパラメータ θ，q，α，β，ηはそれぞれ下記のように設定した．

Table 7.3: パラメータ（実験３）

エージェント名 θ q α β η

Factory 0.13 64 0.15 0.089 0.068

Distributor 0.12 65 0.16 0.11 0.16

Wholesaler 0.095 67 0.17 0.082 0.14

Retailer 0.078 108 0.15 0.18 0

その他の設定は実験２と同様である．

顧客設定

顧客設定は実験２と同様である．

7.4.2 実験結果

各エージェントにおける環境負荷とコストの総計，及び推移は以下のようになった．なお，環境負荷とその他の推移については実験２と同様に 1001日目から 1070

日目までを基にしグラフを作成した．


環境負荷・コスト

Fig. 7.9: 環境負荷（実験３）


Fig. 7.10: 環境負荷の推移（実験３）

Fig. 7.11: コスト（実験３）


在庫・注文・受注残

Fig. 7.12: 在庫の推移（実験３）


Fig. 7.13: 注文の推移（実験３）

Fig. 7.14: 受注残の推移（実験３）


Table 7.4: 積算在庫量，総注文量，積算受注残量（実験３）

エージェント名積算在庫量総注文量積算受注残量Factory 108936 41417 30

Distributor 87357 41606 2854

Wholesaler 91199 41728 4071

Retailer 175681 41785 236

Total 477243 166178 5428

7.4.3 考察

Fig.7.13に示すように実験２（Fig.7.7参照）と比較し注文量が平準化していることが分かる．これにより，Fig.7.12に示すように実験２（Fig.7.6参照）に比較し在庫量も安定し，在庫量，受注残共に大幅に削減できた．本実験では在庫量，受注残の安定・減少により実験１に比べコストの大幅な削減に繋がっていることが確認できた．実験２，３のサプライチェーン全体でのコスト及び積算在庫量，積算受注残量の比較は下記の通りである．特に受注残の削減が大きくコストの削減に寄与していることが分かる．

Table 7.5: 積算在庫量（実験２，３比較）在庫量受注残量コスト

実験２ 917085 94994 1, 297, 059

実験３ 477243 5428 498, 954

本実験で行った注文意思決定モデルの改良は顧客の需要をサプライチェーンの全てのエージェントが共有し，顧客の需要予測として移動平均を用いるという簡易的なものであるが，在庫コスト及び受注残コストの削減効果が確認された．今後は本研究室において研究されているVMI（Vender Managed Inventory）のような手法を用い実験することで，より大きなコスト削減を実現することが可能であると予測される．また，実験２と実験３の環境負荷を比較すると殆ど差が無いことが分かる．これはEco-Indicatorによる環境評価が使用した環境影響因子に依存しており，使用した物質は製品一個あたりに定義されているためである．また，製造工程や輸送による環境負荷も，製品一個がトラックの最大積載量に占める割合によって定義したためである．今後はまとめて作ることによって製造工程において電力や燃料の使用を節約できるといったことや，反対に集中して生産することによって効率が下がる，というような仮定や，製品を 1個しか輸送しない場合も，その輸送に


よる環境負荷がその製品１個による環境負荷であると定義し評価をすることを可能にしていく等，利用者毎のケースに合わせた評価を可能としていくことを検討する必要があるだろう．本実験によって，ある程度のプログラミング知識によって簡単にドメインエージェントの意思決定モデルを改良することができ，ライフサイクルモデルの拡張が可能であることが確認できた．

7.5 実験を通しての考察実験を通し，ライフサイクルモデリング基盤によってライフサイクルモデルを開発し，ライフサイクル評価を実行することが可能であることが確認できた．また，意思決定モデルの変更によって独自のエージェントを作成することで，システムの拡張を行ない，ライフサイクルモデリングを実行することが可能であることが確認できた．一方で今後の課題も明確となった．

7.5.1 今後の課題

今後の課題は下記の通りである．

• エージェント間インターフェースの拡張

現在エージェント間で行われるやり取りは注文と輸送に限られている．より高度なエージェントの作成を支援するため，企業間や企業と顧客間における交渉や情報の請求，といったメソッドを規定する必要があるだろう．

• 各種意思決定モデルの提案

本研究では企業における注文・生産意思決定モデルや顧客における購買モデルの一例を実装した．今後はこれらのモデルの実用性の検証と共に，製品の値段設定や，製品の選択手法といった様々な意思決定モデルの実装を行い，ユーザーのモデリングを支援する必要があるだろう．

• 評価手法の拡張

現在，評価機能として，経済性評価として在庫コストと受注残コスト及びキャッシュフローを，環境評価手法としてライフサイクルアセスメントの 1

つである Eco-Indicatorを実装している．今後は，より柔軟で高度なライフサイクル評価を実装するために，経済性の評価においてコストやキャッシュフローだけではなく売上高や純資産といったものを対象とした評価を実装することや，環境性の評価として複数のライフサイクルアセスメントを実装し，


ライフサイクルモデリング基盤のユーザーがその中から自由に選択できるようにする必要があるだろう．

• ライフサイクルモデリング支援手法の提案

本研究では，ライフサイクルモデリング基盤としてユーザーがモデリングを行うための基盤を提案した．今後，ライフサイクルの評価を実際に誰しもが実行可能とするためには，ライフサイクルモデルの一部のみが分かっている場合や，製品のみが分かっている場合においても全体のライフサイクルモデリングを可能とする技術や，作成したモデルを基に，経済性や環境性，安全性においてより有効なライフサイクルモデリングを自動的に提案する手法の提案が求められる．

74

第8章結言

本研究では，ライフサイクルの構成要素をドメインエージェントとしてモデル化し，それらをマルチエージェントシステムとして合成することによりライフサイクルモデルを構築する手法と，作成したライフサイクルモデルを経済性と環境性の両面から用い評価する手法について提案し，それらを統合することにより，ライフサイクルモデリング基盤の開発を行った．また，作成したライフサイクルモデリング基盤を用いてビールゲームに基づいたシミュレーションを実施し，ライフサイクルモデリング基盤の LCE研究における実用性の検証を行い，開発したライフサイクルモデリング基盤がライフサイクルモデリングとライフサイクル評価において有効であることを確認した．シミュレーションの実施においては，ビールゲームにおけるサプライチェーンに基づきインクカートリッジを供給するサプライチェーンを作成し，環境性とコストの検証を行った．また，注文意思決定モデルを改善することでエージェントベースモデリングを採用したことによるライフサイクルモデリング基盤の拡張性を確認し，本ライフサイクルモデリング基盤を用いることで，ある程度の知識・経験があればライフサイクルのモデルを作成し，評価を行うことが可能であることを示した．本研究で開発したシミュレーションモデルは今後 LCE研究を検討するための基礎手段として新しい研究を形作ると予想される．今後の展開としては，ライフサイクルモデルの作成支援についての研究が期待される．現状では工場，卸，小売店，顧客というサプライチェーンを想定したが，例えば工場の前段階の原料採掘，また顧客が使用した後の段階である廃棄やリサイクルといった部分を考えていく必要があるだろう．本研究室において研究されているようなオントロジーを用いたセメンティック検索のような形で，ドメインエージェントが自律的に必要な物や情報を所持する他のエージェントを探索し関係性を持つことによりサプライチェーンの有機的な展開を行っていくことでライフサイクルモデリングを支援し，１つの製品のライフサイクルにおける正確な経済性や環境負荷，危険性の影響といったものを求めることを可能とする拡張が期待される．

75

第9章謝辞

本研究を行うにあたり，有益な御助言と励ましの言葉を頂きました豊橋技術科学大学機械工学系清水良明教授，Rafael Batres准教授，阪口龍彦助教に深く感謝致します．また，本論文の作成において，的確な助言をして頂きました鈴木新一教授に厚く感謝致します．また, 同じ研究室として, 研究を進める上での助言やサポートを頂いた安田君, 高田君, 藤原君, 辻岡君ならびに生産システム研究室在学生, 卒業生の皆様に心から御礼申し上げます.

76

参考文献

[1] LCA実務入門編集委員会：LCA実務入門，社団法人産業環境管理協会

[2] 稲葉庸介,製品ライフサイクル評価システムの分散アプリケーションとの連携を指向した展開,豊橋技術科学大学大学院,修士論文 (2005)

[3] 元木裕司,製品ライフサイクル支援のための要素技術有効利用に向けた情報基盤の構築,豊橋技術科学大学大学院,修士論文 (2006)

[4] 影山淳二,セマンティック検索を用いたライフサイクルモデリング支援システムの開発;豊橋技術科学大学大学院,修士論文 (2008)

[5] M. Goedkoop, S. Effting and M. Collignon. In: The eco-indicator 99. Manual

for designers, PRe Consultants BV (2000)

[6] 環境省,「循環型社会形成推進基本法」の概要，http://www.env.go.jp/

[7] 環境省,「第 2 次循環型社会形成推進基本計画」の概要について;政府広報オンライン (2008)

[8] 伊坪徳宏, 田原聖隆, 成田暢彦共著 ; 稲葉敦, 青木良輔監修; LCA概論; 産業環境管理協会 (2007)

[9] 日本規格協会，http://www.jsa.or.jp/

[10] ISO International Organization for Standaization，http://www.iso.org/

[11] 石原永貴,製品ライフサイクル支援のためのXMLモデルのWeb上への実装とその応用,豊橋技術科学大学大学院,修士論文 (2003)

[12] IDEF0 Overview，http://www.idef.com/idef0.html

[13] Extensible Markup Language (XML)，http://www.w3.org/XML/

[14] ビールゲームの説明，http://www.j-s-d.jp

[15] Agent Villageエージェントの里; http://mamezou.net/AgentVillage/index.html

[16] The Repast Suite，http://repast.sourceforge.net/

第 9章謝辞 77

[17] The Repast Tutorials，http://repast.sourceforge.net/repast 3/tutorials.html

[18] North, M.J., Macal, C.M. The Beer Dock: Three and a Half Implementations

of the Beer Distribution Game. SwarmFest (2002)

[19] Sterman, J. D. Testing Behavioral Simulation Models by Direct Experiment.

Management Science, 33, 1572-1592.(1987)

[20] Sterman, J. D. Modeling Managerial Behavior: Misperceptions of eedback

in a Dynamic Decision Making Experiment. Management Science,35, 321-

339.(1989)

78

付録A プログラムソースコード

本研究において実装したエージェント，Business Agentとそのサプグラスである Factory Agentのソースコードを紹介する．

Business Agent

package biosimple;

import information.Inventory;

public class BusinessAgent extends BasicAgent ｛

//***********財務定義***********

double current_asset = 10000;

double cost = 0;

double integratedCost;//積算コストdouble impact;//瞬間環境影響double integratedImpact;//積算環境影響

double putativeCost =0;

double BackOrderCost =0;

double InventoryCost =0;

//***********変数定義***********

protected String agentName;

Object MyMSCID;

ArrayList<String> salesName = new ArrayList<String>();

ArrayList<Double> salesAmount = new ArrayList<Double>();

int decisionType;

付録 A プログラムソースコード 79

Inventory inventory = new Inventory();

SimulatedAnnealing sa = new SimulatedAnnealing();

SimpleModelProfile modelProfile = new SimpleModelProfile();

//輸送受け取りpublic void acceptShipping(String prod_Name,

String prod_Category, double prod_Amount, Object agent_Name) ｛

if(agent_Name!=this)System.out.println

("エラー：他の人宛の品が届いています" + agent_Name + this);

System.out.println(this +" : 輸送受け取り " +

prod_Name + " " + prod_Amount);

inventory.addInventory(prod_Name,prod_Category,prod_Amount);

shippedTest = prod_Amount;

｝

//輸送　public void shipping() ｛

inventory.dealBackoder();

int i = 0;

while(inventory.getShippingHas(i))｛

if(inventory.getShippingCount(i) > 1)｛System.out.println(this +" : 輸送 " +

inventory.getShippingName(i) + " " +

inventory.getShippingAmount(i));

BusinessAgent bagent = (BusinessAgent)

inventory.getShippingAgentName(i);

bagent.acceptShipping(inventory.getShippingName(i),

inventory.getShippingCategory(i)

, inventory.getShippingAmount(i),

inventory.getShippingAgentName(i) );

inventory.removeShipping(i);


i--;

｝i++;

｝｝

double theta = 0.2;

double q = 150;

double alpha = 0.15;

double beta = 0.1;

double eta = 1;

public void acceptSetPara(double theta,

double q, double alpha,double beta, double eta)｛this.theta = theta;

this.q = q;

this.alpha = alpha;

this.beta = beta;

this.eta = eta;

｝

public void order() ｛

if (decisionType == 0 | decisionType == 1) ｛//orderを決定、環境影響項目を impactListに加えるimpactList.addAll(inventory.orderDecision(0,0,0,0,0));

｝else if(decisionType == 2)｛//orderを決定、環境影響項目を impactListに加えるimpactList.addAll(inventory.

orderDecision(theta,q,alpha,beta,eta));

｝

int i_S = 0;

while(inventory.getOrderHas(i_S))｛if(inventory.getOrderCount(i_S) > 0)｛

Context<BasicAgent> context =

ContextUtils.getContext(this);

Network<BasicAgent> network;

network = (Network)context.


getProjection("Network1");

Iterable<BasicAgent> it =

network.getPredecessors(this);

for (Iterator<BasicAgent> iter =

it.iterator(); iter.hasNext();) ｛BasicAgent bagent = iter.next();

if (bagent instanceof BusinessAgent) ｛BusinessAgent business = (BusinessAgent) bagent;

business.acceptOrder(inventory.getOrderName(i_S),

inventory.getOrderCategory(i_S),

inventory.getOrderAmount(i_S), 0,this);

｝｝

inventory.removeOrder(i_S);

i_S--;

｝i_S++;

｝｝

boolean contain = false;

//オーダー受信public void acceptOrder(String name,String category,

double amount,int orderID, Object agent) ｛

inventory.addBackoder(name,

category, amount,orderID, agent);

if(salesName.contains(name))｛salesAmount.set(salesName.indexOf(name),

salesAmount.get(salesName.indexOf(name)) + amount );

｝else｛salesName.add(name);

salesAmount.add(amount);

｝｝


//コスト等の計算public void zaimu(String name) ｛putativeCost=0;cost = 0 ;impact=0;

BackOrderCost = inventory.checkBackoderCost();

InventoryCost = inventory.checkInventoryCost();

putativeCost = BackOrderCost + InventoryCost;

impact = orderAssessment(impactList);

integratedImpact = integratedImpact + impact;

if(logOn)｛makeInventoryLog(name,"" + inventory.getInventoryTest());

makeOrderLog(name,"" + inventory.getOrderTest());

makeCostLog(name,"" + putativeCost);

｝

cost =InventoryCost;

current_asset = current_asset - cost;

if(decisionType == 1)｛inventory.setCostImpact(agentName, putativeCost, impact);

｝

zaimuReport(current_asset,putativeCost,cost,impact);

｝

private void zaimuReport(double current_asset2,

double putativeCost2,double cost2, double impact2) ｛

MasterOfSupplyChainAgent bagent =

(MasterOfSupplyChainAgent)MyMSCID;

bagent.acceptZaimuReport(agentName,current_asset2,

putativeCost2,cost2,impact2,inventory.getInventoryTest(),

inventory.getOrderTest(),inventory.getBackOrderTest());

｝

public void acceptSalesReport(ArrayList<String> salesName2,


ArrayList<Double> salesAmount2) ｛inventory.setRetailerSales(salesName2,salesAmount2);

｝

public String acceptCheckIndex() ｛return modelProfile.model_name;

｝

double inventoryTest = 0 ;

double backOrderTest = 0 ;

double orderTest = 0 ;

double costTest = 0 ;

double shippedTest = 0 ;

double impactTest = 0;

@Parameter (displayName = "在庫量", usageName = "inventoryTest")

public double getInventory() ｛inventoryTest = inventory.getInventoryTest();

return inventoryTest;

｝@Parameter (displayName = "オーダー量", usageName = "orderTest")

public double getOrder() ｛orderTest = inventory.getOrderTest();

return orderTest;

｝@Parameter (displayName = "遅延量", usageName = "backOrderTest")

public double getBackOrder() ｛backOrderTest = inventory.getBackOrderTest();

return backOrderTest;

｝@Parameter (displayName = "コスト", usageName = "costTest")

public double getCost() ｛costTest = putativeCost;

return costTest/10;

｝@Parameter (displayName = "輸送", usageName = "Shipped")

public double getShipped() ｛

return shippedTest;

｝


@Parameter (displayName = "環境影響", usageName = "impactTest")

public double getImpact() ｛impactTest = impact;

impact =0;

return impactTest/1000;

｝

public Object registMSCAgent(Object ID ,

SupplyChainModelProfile SCModel) ｛

Object myID = null;

if(SCModel.domainModel.contains(modelProfile.modelName))｛MyMSCID = ID;

myID = this;

System.out.println(this + ":MSCAgent登録完了");

｝return myID;

｝｝

Factory Agent

package biosimple;

import information.Inventory;

public class FactoryAgent extends BusinessAgent ｛protected static long agentIDCounter = 1;

Object agentID = this;

//***********変数定義***********

public FactoryAgent(int type ,String csvFileURI) ｛//初期設定modelProfile.parse(csvFileURI);


inventory.set(type, modelProfile);

decisionType = type;

agentName = modelProfile.model_name + (agentIDCounter++);

System.out.println(agentName + " Hello!!　" + agentID);

｝

//生産public void manufacture() ｛

if (decisionType == 0 | decisionType == 1) ｛//orderを決定、環境影響項目を impactListに加えるimpactList.addAll(inventory.orderDecision(0,0,0,0,0));

｝else if(decisionType == 2)｛//orderを決定、環境影響項目を impactListに加えるimpactList.addAll(inventory.orderDecision(theta,q,alpha,beta,eta));

｝

int i_S = 0;

while(inventory.getOrderHas(i_S))｛if(inventory.getOrderCount(i_S) > 1)｛

this.finishManufacture(inventory.getOrderName(i_S),

inventory.getOrderCategory(i_S),

inventory.getOrderAmount(i_S));

inventory.removeOrder(i_S);

i_S--;

｝i_S++;

｝｝

//生産終了public void finishManufacture(String name_FM,

String category_FM, double amount_FM) ｛


System.out.println(this +

" : 生産終了 " + name_FM + " " + amount_FM);

inventory.addInventory(name_FM, category_FM, amount_FM);

｝

@ScheduledMethod(start=0, interval=1, shuffle=false)

public void step()｛//ターン毎の挙動

if(tick < 3)｛//０ターン目の挙動if (tick == 0) ｛

｝｝else if( tick/2 == 1 )｛//前半　意思決定、発注、情報

inventory.count();//製造・輸送等のカウントを進める

manufacture();//製造

｝else｛//後半　輸送shipping();

zaimu(agentName);//コスト計算｝

tick++;

｝｝

ライフサイクルモデリング基盤の開発 ‐ビールゲー...

Documents

Transcript of ライフサイクルモデリング基盤の開発 ‐ビールゲー...