MAS のためのフレームワーク

本節では，MASを構築するためのフレームワークについて述べる．MASは複雑な システムであり，一から構築しようとした場合には大きな労力が必要とされる．その

2.5 MASのためのフレームワーク ため，MASに共通に必要となる機能をあらかじめ用意し，一貫性のあるフレームワー クとしてまとめ上げることで構築を容易にしようという試みが為されてきた．

MASのフレームワークとしては，大きく分類するとライブラリ型とアプリケーショ ン型が存在する．ライブラリ型は，MASの構築に必要な機能がライブラリとして提供 されているもので，開発者はライブラリを組み合わせてプログラムを作成することで MASを構築するものである．必然的に開発者にはプログラミングスキルが要求される．

一方のアプリケーション型は，フレームワークそのものが独立したアプリケーショ ンとなっており，開発者は主としてGUIによる操作によってMASを構築するもので ある．そのため，ライブラリ型に比べて開発を始めるのは容易であるが，予め用意さ れた以外の機能を利用する際には，プログラミング言語またはフレームワークが用意 するスクリプト等によってその機能を記述する必要がある．

以下に，ライブラリ型及びアプリケーション型の主要なフレームワークについて紹 介する．また，MASフレームワークについてはその双方の特徴を備えたものも存在し ているため，そのようなフレームワークの分類については，どちらの要素がより大き いと考えられるかで判断している．

2.5.1 ライブラリ型フレームワーク

既存のMASフレームワークのうち，ライブラリ型に分類されるものとしてはRepast [69]，Swarm [27]等が挙げられる．Delta3D [26]，MATSim等はプログラミングが前提 という点でライブラリ型に分類されるが，シミュレーション用途が限定されている点 で，高い汎用性を特徴とする他のライブラリ型フレームワークとは性格を異にする．ま た，GPGSiM [28]のようにアプリケーション型とライブラリ型の双方の特徴を取り入 れることを試みているフレームワークも存在する．

RepastはJavaによるライブラリ型のフレームワークであり，原則としてプログラム

コードを記述することを前提としている．ただし，開発環境としてEclipseが指定され ており，一部の機能に関してはEclipseのプラグインを利用したGUIによる設計も可能 となっている．例えば，エージェントの振舞いを定義する部分はGUIによってフロー チャートを描くことができる．Repast Symphony [24]は，Repastをベースに開発環境 までを包含した枠組みに拡張したものである．

Swarmはライブラリ型のシミュレーションフレームワークを代表するソフトウェア

であり，MASに関する多くの研究に利用されている．シミュレーションに必要な機能 は小さな粒度で設計されており，開発者はObjective C及びJavaのプログラムを記述

し，Swarmの機能を取捨選択して利用することができる．その一方で，自由度と引き

2.

換えにシミュレーションを実行するための枠組みが最初から構築されているわけでは ないため，初学者にとってのハードルは低いとは言えない．

2.5.2 アプリケーション型フレームワーク

アプリケーション型フレームワークには，AnyLogic, artisoc [25]，GAMA [70]，

Net-Logo [71]，SOARS等が存在する．NetLogoは教育用としての意味合いが大きく，初学

者が取り組みやすいようにGUIを中心とした設計ができるよう工夫されている．artisoc は国内において広く用いられ，金融問題から交通，都市の人口動態から農業普及等の 様々な事例が研究されている．

artisocはJava言語で作成されたソフトウェアであり，GUIによって基本的な設定を

行い，行動ルール等の詳細な設定は独自に用意されたスクリプト言語を利用する形式 となっている．本論文においては第3章で実際にartisocを利用してシミュレーション を実施した．artisocはエージェントを画面に表示するまでの操作を非常に容易に実現 できる．その一方で，標準で用意されていない機能はスクリプトによって実現するこ とになる．artisocのスクリプト処理はインタープリター型であり，実行性能は追及さ れていないため，複雑な処理を行う多数のエージェントを動作させるケースには必ず しも適さない場合がある．

2.5.3 本研究におけるフレームワーク型の選択

ライブラリ型とアプリケーション型はそれぞれ長所と短所があり，一般にライブラ リ型は汎用性が高いがMASの構築にプログラミングの知識が必要とされ，アプリケー ション型はプログラミングの知識がそれほど必要とされない代わりにライブラリ型ほ どの汎用性を持つのは難しくなる．アプリケーション型には商用製品が多いためにプ ログラムのソースコードの編集を認めていない場合が多いが，一つのアプリケーショ ンとして多くの機能が密接に連携しているため，ソースコードの編集が可能であって も適切に改変するには相応の作業量を要求すると考えられる．

また，汎用性のために独自のスクリプトと処理系を搭載している場合もあるが，そ の処理速度については直接的にプログラムコードを実行できるライブラリ型には及ば ないことが多い．既存の主なMASフレームワークの特徴を図2.1に示す．

また，フレームワークはシミュレーションのための様々な機能を提供するが，様々な シミュレーションへの応用を考慮した場合，それぞれの機能は独立性が高いことが望 ましい．特に可視化機能については，シミュレーションの中核機能と密接に結びつい