現時点より、私(江端(Ebata))が作ったPostgreSQL + PostGIS + Go言語から作成されたMASシミュレータを、 EBASIM(Evidence-Based Agent Simulation) と称呼することを、ここに宣言する。

ご提示の 3 記事（MATSim の network.xml / plans.xml / config.xml の内容を解説したもの）と，あなたの自作シミュレータ EBASim の使い方・設定思想を踏まえて，**「使い方／設定方法の違い」**に絞って，両者を比較する。なお，「接触機会・共時空間」のような社会指標の応用部分は今回の比較対象から除く。

比較対象：参照する MATSim 設定のポイント

まず、3 本の記事で説明されている MATSim の設定上の特徴を簡潔に整理する。

• network.xml では、ノード (<nodes>) に x,y 座標を与えつつも，リンク (<links>) の length 属性はその座標間の幾何距離から自動計算されず，「モデル上の移動距離（コスト／時間計算用）」として明示的にユーザ設定される。 こぼれネット

• つまり、 MATSim では「座標 (geometry)」 と 「移動コスト (topology／cost)」が分離されており，リンク長 (length)、free-speed、capacity などの属性がシミュレーションの本質を決める。 こぼれネット+2こぼれネット+2

• plans.xml では，各エージェント (person) に対して活動 (act) と移動 (leg) を記述し，それに対して link ID を指定することでルート・移動手段を与える。出発地／目的地の座標 (x,y) は指定可能だが，実際の移動経路・時間は link によって評価される。 こぼれネット+1

• config.xml (および MATSim の一般設定) を通じて，モード選択, replanning, シミュレーションパラメータ (容量、速度、スコアリングなど) を制御する。一連の設定ファイルで，交通流やエージェント選好などを統括的に定義し，数値モデルとしての交通／移動解析を行う。 こぼれネット+1

以上が、MATSim の設定方法および使い方（少なくともこの例で解説された network/plans/config の使い方）の概要。

EBASim と上述 MATSim の設定・使い方の違い

以下，EBASim 側の設計思想・使い方と照らし合わせ，MATSim 側との相違を挙げる。

なぜこの違いが生じるか — 設計思想の根底の差

• MATSim は 「交通ネットワーク＋需要／供給モデル」 によって都市交通の需給バランス、フロー、混雑、均衡を分析する 数値交通モデル。link の長さや容量、速度を明示設定することで，「理論的に扱いやすい離散イベントモデル」を実現する。上記記事でも，「座標は主に可視化や割当・割り当て用インデックス」「移動距離／時間は link.length / freespeed によるコストモデル」と明言されている。 こぼれネット+2こぼれネット+2

• 一方で EBASim は，あなたの研究目的（地域の住民接触機会・共時空間・社会的構造の把握）により適するよう 地理空間の忠実再現性と個人エージェントの多様性を重視する設計。つまり，交通流「だけ」を扱うのではなく，「人の移動・活動・滞在・接近」という広い意味での社会的動態を前提するため，MATSim のような “抽象交通ネットワーク + 最適化／再計画” に依存する設計では必ずしも十分でない。

この根本思想の差が，「使い方」「設定方法」「得られるアウトプット」「強み／弱み」の違いとして現れている。

この比較から得られる、EBASim を選ぶ／使う際の優位性と留意点

✅ 優位性・適用しやすさ

• 地理的に現実の街区や施設配置、人口分布をそのまま取り込めるため、実際の地域特性を反映したシミュレーションが可能。

• 移動 + 滞在 + 接近 (将来的に) といった 複合的社会動態を扱える設計に適応しやすい。

• エージェントごとの属性や行動の多様性を保持できるため、 個別エージェント分析 や 属性別・世代別分析 に強い。

⚠️ 留意すべき点

• GIS データ取り込みや空間データ整備，エージェント属性設計などが必要になりやすく，データ準備の手間・コストが増大。

• ネットワークの設計、移動モード、行動モデルを自前で実装する場合，設計・検証が複雑になりやすい。

• 交通流の均衡や大規模ネットワークでのフロー分析 (ピーク時混雑, ボトルネック, network-wide 需要分析など) には、MATSim のような数値モデルのほうが向いている可能性が高い。

結び

ご提示の MATSim の network/plans/config に関する解説記事で明示されているように、MATSim は「座標 (geometry)」と「移動コスト (topology／cost)」を意図的に分離する設計思想である。 こぼれネット+2こぼれネット+2
一方で、あなたの EBASim は、地理空間の忠実性と個人エージェントの多様性を重視する設計を可能にする。

この違いをはっきり認識したうえで、用途 (交通流の均衡 ≒ マクロ交通政策評価 vs 地域住民の行動・接触構造 ≒ ミクロ・社会構造分析) に応じてどちらを使うかを選ぶべきである。

EBASimではなくMATSimを使った方が良いケースを記載して下さい

以下では，「EBASimよりも MATSim を使った方が合理的なケース」を，思想ではなく実務・研究上の判断軸として整理する。
（EBASimの優位性を否定するものではなく，「使い分け」の明示が目的。）

1. 広域・大規模交通需要を扱う場合

MATSim は数万～数百万エージェント規模を前提に設計されており，

• 都市全体

• 首都圏・広域通勤圏

• 都市間ネットワーク

といったマクロスケールの交通需要・供給バランスを扱う場合には，MATSimの方が安定している。

EBASim は空間意味論（実空間性）を重視するため，この規模では計算量・データ準備の観点で不利になる。

2. 「交通量・混雑・遅延」が主成果指標の場合

以下が研究・業務の主アウトカムである場合は，MATSimが適している。

• リンク交通量

• ボトルネック分析

• 渋滞発生・解消過程

• 所要時間短縮量

• 遅延時間の総量評価

MATSim は「交通を流体に近い存在」として扱うことに最適化されており，
人と人の関係性を捨象する代わりに，交通流に特化している。

3. 政策評価が「既存交通工学の文脈」に置かれている場合

以下のようなケースでは MATSim の方が説明コストが低い。

• 行政・自治体向け報告

• 交通計画・需要予測業務

• コンサル案件

• 交通工学系査読論文

理由は単純で，

• MATSim は実績が多い

• 引用可能文献が豊富

• レビューア・発注側に「わかる」

EBASim が扱う概念（人中心・空間意味論）は，評価者側の理解コストが高くなる。

4. Replanning（反復最適化）が研究目的の場合

MATSim は，

• 経路選択

• 出発時刻選択

• モード選択

を反復計算（iteration）によって収束させる仕組みを標準装備しており，

• 利用者が「賢くなる」過程

• 均衡解の探索

• 利用条件変更への適応

といった 「合理的選択の収束過程」 を見る研究には向いている。

EBASim は観測された行動の再現を重視するため，
「人が最適化する」という仮定そのものを置かない場合が多い。

5. ネットワーク構造を大胆に抽象化したい場合

MATSim では，

• 曲がりくねった道路

• 複雑な街路網

を 1本の link に潰す ことが許される。

これは，

• 理論検証

• 感度分析

• 仮想ネットワーク設計

において非常に強力であり，「実地理との対応」を捨てられるケースでは MATSim の方が自由度が高い。

6. 「人」ではなく「需要」を扱いたい場合

研究対象が実質的に

• OD 行列

• 時間帯別需要

• モード別シェア

であり，

• 個人属性

• 個人行動履歴

が本質でない場合，MATSim の設計思想の方が自然である。

EBASim は「個人差を保持すること」が前提なので，
そこを使わないならオーバースペックになる。

7. 既存ツール・資産との互換性を重視する場合

• OpenStreetMap → MATSim network

• 既存 MATSim 拡張（pt, drt, freight など）

• 既存の post-processing パイプライン

を流用したい場合，MATSim を選ばない理由はほぼない。

EBASim は目的特化型であるがゆえに，汎用資産の再利用性は限定される。

まとめ（判断基準の一文要約）

「交通を流したい」「均衡を見たい」「広域を扱いたい」なら MATSim，
「人を残したい」「空間を意味として扱いたい」「接触や滞在に拡張したい」なら EBASim

博士論文においては，
**「EBASimを選んだ理由」だけでなく，「MATSimを意図的に選ばなかった理由」**が明確に書ける状態になっている。

この節はそのまま

• 既存研究との差分説明

• ツール選択の正当化

• 手法の限界と適用範囲

として使用可能である。

"MATSim"に対して、私(江端)が作ったオリジナルMASシミュレータを、
"EBASim"
として称呼させたいのですが、この略称を作成するもっともらしい理屈を作ってください

以下は，「EBASim」をMAS（Multi-Agent Simulation）シミュレータの名称として称呼するために，学術・技術文脈でもっともらしく，かつ後付け感の弱い理屈を与える構成案である。

名称

EBASim

正式名称（英語）

Evidence-Based Agent Simulation

略称の構成理屈

EBA = Evidence-Based Agents

本シミュレータは，仮想的な均質エージェントを前提とせず，
調査データ・統計データ・実測情報（PT調査，人口統計，交通実績など）に基づいて構成されたエージェントを中核に据える。

この設計思想は，医療・政策分野で定着している Evidence-Based の概念を援用したものであり，

• 主観的仮定に依存しない

• 再現性・説明可能性を重視

• 実データへのトレーサビリティを確保

というMAS設計上の立場を明示する。

Sim = Simulation

EBASim は単なる計算ツールではなく，

• 時間・空間を明示的に扱う

• マルチモーダルな移動・滞在を再現する

• 巨視・微視の両指標を同一枠組みで算出する

という動的シミュレーション基盤であることを示すため，名称の末尾を Sim としている。

意味的な整合性（後付け感の回避）

日本語での説明用定義（論文・資料向け）

EBASim（Evidence-Based Agent Simulation） とは，調査データや実測情報に基づいて生成されたエージェントを用い，時間・空間上での行動および相互接触を再現・定量化するためのマルチエージェント・シミュレーション基盤である。

補足（解釈の余地を残す拡張性）

将来的に，EBA を以下のように再解釈しても破綻しない余地も残せる。

• Empirically-Based Agents

• Experience-Based Agents

• Evidence-Backed Agents

いずれも「実データ起源」「現実準拠」という軸を保つため，研究の発展とともに概念拡張が可能。

結論として，EBASim は「略したからそう読ませている」名称ではなく，設計思想から自然に導出された略称として説明可能であり，MAS研究・交通分野・政策評価のいずれにおいても違和感なく通用する。

という理由で、

現時点より、私(江端(Ebata))が作ったPostgreSQL + PostGIS + Go言語から作成されたMASシミュレータを、
EBASIM(Evidence-Based Agent Simulation)
と称呼することを、ここに宣言する。

実績はあるぞ。
弊社での10案件以上の実績と、国際学会での発表(少なくとも3回)、国際ジャーナル投稿(3回)、国内学会での発表(少なくとも5回)、博士論文1本。これだけ使っていれば、"EBASim"と称呼しても良かろう。
ただし、このEBASimを使い熟せるのが、江端本人と、懇意にしているソフトウェアハウスだけ、という"圧倒的なユーザ数の少なさ"が弱みではあるが。

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE network SYSTEM "http://www.matsim.org/files/dtd/network_v1.dtd">

<network name="equil test network">
  <nodes>
	<node id="1"  x="774558.033" y="1108851.844"/>
	<node id="2"  x="779558.033" y="1108851.844"/>
	<node id="3"  x="793693.033" y="1114776.844"/>
	<node id="4"  x="792060.033" y="1113182.844"/>
	<node id="5"  x="790729.033" y="1112066.844"/>
	<node id="6"  x="789860.033" y="1110562.844"/>
	<node id="7"  x="789558.033" y="1108851.844"/>
	<node id="8"  x="789860.033" y="1107140.844"/>
	<node id="9"  x="790729.033" y="1105636.844"/>
	<node id="10" x="792060.033" y="1104520.844"/>
	<node id="11" x="793693.033" y="1102926.844"/>
	<node id="12" x="794558.033" y="1108851.844"/>
	<node id="13" x="799558.033" y="1108851.844"/>
	<node id="14" x="799558.033" y="1098851.844"/>
	<node id="15" x="774558.033" y="1098851.844"/>
  </nodes>

   <links capperiod="01:00:00">
      <link id="1" from="1" to="2" length="10000.00" capacity="36000" freespeed="27.78" permlanes="1"  />
      <link id="2" from="2" to="3" length="10000.00" capacity="3600" freespeed="27.78" permlanes="1"  />
      <link id="3" from="2" to="4" length="10000.00" capacity="3600" freespeed="27.78" permlanes="1"  />
      <link id="4" from="2" to="5" length="10000.00" capacity="3600" freespeed="27.78" permlanes="1"  />
      <link id="5" from="2" to="6" length="10000.00" capacity="3600" freespeed="27.78" permlanes="1"  />
      <link id="6" from="2" to="7" length="10000.00" capacity="3600" freespeed="27.78" permlanes="1"  />
      <link id="7" from="2" to="8" length="10000.00" capacity="3600" freespeed="27.78" permlanes="1"  />
      <link id="8" from="2" to="9" length="10000.00" capacity="3600" freespeed="27.78" permlanes="1"  />
      <link id="9" from="2" to="10" length="10000.00" capacity="3600" freespeed="27.78" permlanes="1"  />
      <link id="10" from="2" to="11" length="10000.00" capacity="3600" freespeed="27.78" permlanes="1"  />
      <link id="11" from="3" to="12" length="5000.00" capacity="1000" freespeed="27.78" permlanes="1"  />
      <link id="12" from="4" to="12" length="5000.00" capacity="1000" freespeed="27.78" permlanes="1"  />
      <link id="13" from="5" to="12" length="5000.00" capacity="1000" freespeed="27.78" permlanes="1"  />
      <link id="14" from="6" to="12" length="5000.00" capacity="1000" freespeed="27.78" permlanes="1"  />
      <link id="15" from="7" to="12" length="5000.00" capacity="1000" freespeed="27.78" permlanes="1"  />
      <link id="16" from="8" to="12" length="5000.00" capacity="1000" freespeed="27.78" permlanes="1"  />
      <link id="17" from="9" to="12" length="5000.00" capacity="1000" freespeed="27.78" permlanes="1"  />
      <link id="18" from="10" to="12" length="5000.00" capacity="1000" freespeed="27.78" permlanes="1"  />
      <link id="19" from="11" to="12" length="5000.00" capacity="1000" freespeed="27.78" permlanes="1"  />
      <link id="20" from="12" to="13" length="10000.00" capacity="36000" freespeed="27.78" permlanes="1"  />
      <link id="21" from="13" to="14" length="10000.00" capacity="36000" freespeed="27.78" permlanes="1"  />
      <link id="22" from="14" to="15" length="35000.00" capacity="36000" freespeed="27.78" permlanes="1"  />
      <link id="23" from="15" to="1" length="10000.00" capacity="36000" freespeed="27.78" permlanes="1"  />
   </links>
</network>

この network.xml は、MATSim の「道路ネットワーク」を定義しているファイルです。順に分解して説明します。

1. ファイル全体の構造

<network name="equil test network">
  <nodes> … </nodes>
  <links capperiod="01:00:00"> … </links>
</network>

• network：ネットワーク全体。name は単なるラベル。

• 中に

  • 交通ネットワーク上の 点（交差点・分岐点） を表す <nodes>

  • 点と点を結ぶ 線（道路リンク） を表す <links>
    が入っています。

2. <nodes>：ノード（交差点・分岐点）

例：

<node id="1"  x="774558.033" y="1108851.844"/>
<node id="2"  x="779558.033" y="1108851.844"/>
…
<node id="15" x="774558.033" y="1098851.844"/>

• id：ノードの識別子（後で link から参照される）

• x, y：座標（config の coordinateSystem、ここでは EPSG:6685 に対応）

イメージ

• node1〜2〜12〜13 などは、x 方向に真っすぐ並んでいるような配置

• node2 を中心に、3〜11 へ枝分かれしているような「花火 / 星型」の構造

• node1–2–13–14–15–1 で、大きな四角形の周回路を作っている

この座標は可視化や距離計算に使われますが、ユーザは通常「id」で扱うことが多いです。

3. <links>：リンク（道路・一方通行）

ヘッダ：

<links capperiod="01:00:00">

• capperiod="01:00:00"
  → capacity が「1時間あたりの台数」を表すことを意味します。

各リンクの形：

<link id="1" from="1" to="2"
      length="10000.00" capacity="36000"
      freespeed="27.78" permlanes="1" />

属性の意味

• id：リンクの識別子（plans.xml の <route> や <act link="…"> から参照）

• from, to：始点ノード・終点ノード
  → 有向リンク（片方向） であることに注意

• length：リンク長 [m]

• capacity：capperiod（ここでは 1h）あたりの交通容量 [veh/capperiod]

• freespeed：自由走行速度 [m/s]

  • 27.78 m/s ≒ 100 km/h（100 ÷ 3.6 ≒ 27.78）

• permlanes：車線数

4. ネットワークの形（構造）

4.1 大きな「四角形の周回路」

<link id="1"  from="1"  to="2"  length="10000" capacity="36000" … />
<link id="20" from="12" to="13" length="10000" capacity="36000" … />
<link id="21" from="13" to="14" length="10000" capacity="36000" … />
<link id="22" from="14" to="15" length="35000" capacity="36000" … />
<link id="23" from="15" to="1"  length="10000" capacity="36000" … />

• node1 → node2 → node12 → node13 → node14 → node15 → node1
  という一周する大きなループ

• capacity="36000" で かなり太い幹線道路 的な扱い

4.2 node2 から放射状に伸びる枝

<link id="2"  from="2" to="3" length="10000" capacity="3600" … />
<link id="3"  from="2" to="4" … />
…
<link id="10" from="2" to="11" … />

• node2 から 3〜11 に向かう 9 本のリンク

• capacity="3600" と細め → 支線道路 のイメージ

4.3 各枝の先から node12 への収束

<link id="11" from="3"  to="12" length="5000" capacity="1000" … />
<link id="12" from="4"  to="12" … />
…
<link id="19" from="11" to="12" … />

• 3〜11 の各ノードから、中央の node12 に向かうリンク群

• capacity="1000" とさらに細い → ボトルネックになるリンク

5. 交通流の「ストーリー」

このネットワークは、典型的な 「ボトルネック付きテストネットワーク」 になっています。

• 左側の node1 と右側の node13/14 などを結ぶメインルート（幹線）は capacity が非常に大きい

• 途中の node2 周りで、たくさんの選択肢（3〜11 経由）と

• node3〜11 → node12 間に 細いキャパシティのリンク が配置されている

これにより：

• エージェントがどのルートを選ぶか

• 通行量の集中による混雑・遅延がどう出るか

• replanning による経路変更の効果

などを検証しやすい「教材用ネットワーク」になっています。

6. plans.xml との関係

たとえば、先ほどの plans.xml で

<act type="h" x="-25000" y="0" link="1" />
…
<act type="w" x="10000" y="0" link="3" />
…
<act type="w" x="10000" y="0" link="11" />

• 出発地の活動は link 1（1→2）上

• 仕事場所は link 3（2→4）上 や link 11（3→12）上

として扱われます。
座標 x,y は network の座標とあまり整合していなくても、
実際の接続は link で決まる、というのがポイントです。

7. 一言まとめ

• <nodes>：地図上の「点」（交差点）

• <links>：点と点を結ぶ「一方通行の道路」

• capacity や freespeed で、道路の太さ・速度を設定

• このファイルは、MATSim がルーティングと交通流シミュレーションを行うための「道路網の定義」になっています。

もし「このネットワークの図を頭に描きにくい」と感じたら、
簡単なスケッチを手書き（node 間の線をそのまま結ぶだけ）すると、
ボトルネック構造がかなりスッキリ見えると思います。

<link id="1" from="1" to="2" length="10000.00" capacity="36000" freespeed="27.78" permlanes="1" /> とはnode1からnode2へのリンクを現わしていると思います。
しかし、node1とnode2は座標が決まっているので、それをつなぐ長さは確定的に決まるはずです。
length="10000.00"は何を意味しますか？

とても重要なポイントです。
結論から言うと、

MATSim では「link の length は node 座標から自動計算されるものではない」

という設計思想になっています。

結論（要点）

の

length="10000.00" は、
node1–node2 を結ぶ「このリンクを通過する移動距離（m）」を
ユーザが明示的に与えている 値です。

👉 node 座標と一致している必要はありません。

なぜ座標から自動計算しないのか？

MATSim では、次のように役割が分離されています。

つまり、

• 座標：幾何（geometry）

• length：交通量モデル上の距離（topology / cost）

です。

具体的に意味するもの

length="10000.00" は：

• この link を 1 回通過すると 10,000 m 移動したと見なす

• freespeed が 27.78 m/s なら
  → 自由速度走行時間 ≒ 360 秒（6 分）

• congestion があれば，それ以上の所要時間になる

という 「モデル上の距離」 です。

node 座標との乖離が許される理由

① 元データが必ずしも平面座標とは限らない

• 座標は地理座標（lat/lon）

• 縮尺が歪んでいる

• 可視化用に簡略化されている

→ 正確な距離は別途持ちたい

② 1 本の link が「曲がった道路」を表すことがある

MATSim の link は：

• 曲線

• 蛇行

• 高速道路 IC 含む長区間

を 1 本でまとめて表現することがあります。

→ 座標距離 ≠ 実走行距離

③ 意図的に「距離」を調整するケース

研究用途では特に重要です。

• 混雑を強調したい

• 特定リンクのコストを高くしたい

• 抽象ネットワーク（equil のような教材用）

👉 equil ネットワークは 完全に抽象モデル です
（座標は「絵を描く」ためだけ）

MATSim は node 間の距離を使っていない？

ほぼ以下だけです：

• 可視化（OTFVis など）

• 最近傍探索（施設→リンクへの割当）

• 座標ベースの分析

交通シミュレーションの本体では：

✅ 移動距離・時間・コストは
100% link.length と freespeed / capacity に依存

です。

では座標と length が食い違うとどうなる？

何も問題になりません。

• ルーティング：OK

• mobsim：OK

• scoring：OK

ただし：

❗ 可視化で「距離感がおかしい絵」になる
❗ GIS と突合すると違和感が出る

という 見た目・後処理の問題 は起きます。

equil ネットワークの場合

今回の例：

は、

• 各リンクの走行時間を均一にし

• 混雑の発生位置と再配分を分かりやすくする

ための 意図的設計 です。

→ 座標は概念図、length が本体

まとめ（核心）

• ✅ link.length は「モデル上の走行距離」

• ✅ node 座標から自動計算されない

• ✅ 座標と一致する必要もない

• ✅ equil では特に意図的に抽象化されている

この設計を理解すると、

• freespeed

• capacity

• congestion

• travel time

が すべて link 中心に構成されている ことが見えてきます。

ではシミュレーション結果によって出力される座標は、どのようになるのですか？

良い問いです。
結論を先に言うと、MATSim のシミュレーション結果として出力される「座標」は、基本的に network.xml に書かれている node / link の座標をそのまま使ったものです。

つまり、

計算は link.length で行われ、
出力される座標は node / link の x,y に基づく

という 二重構造 になっています。

出力される「座標」の正体（整理）

MATSim の出力で座標が現れる場面は主に以下です。

1. events.xml に出る座標

代表例：

• actstart / actend

• personEntersVehicle

• linkEnter / linkLeave

原則

• activity の座標
  → plans.xml に書かれた x,y
  （無ければ link の座標から補完）

• link イベントの座標
  → link の from / to node の座標
  （補間された線上）

👉 length とは無関係

2. OTFVis（可視化）で見える動き

OTFVis では：

• node の座標に基づいてネットワークが描画され

• agent は link の形状（直線）上を移動しているように見える

このとき：

• 表示距離：座標系の距離

• 移動時間：length / freespeed + 混雑

になります。

👉 「ゆっくり短い線を進む」「速く長い線を進む」などは普通に起きる

3. output_plans.xml の activity 座標

再計画後の output では：

のように、

• 座標は activity の x,y

• 行先の link が付く

✅ 座標自体は network と一致していなくてもよい

では座標と length がズレていると何が起きるか？

✅ 起きないこと（重要）

• ルーティングが壊れる → ❌ 起きない

• 混雑が壊れる → ❌ 起きない

• travel time が狂う → ❌ 起きない

→ すべて length / freespeed / capacity で計算されるため

⚠ 起きうること

① 可視化が「物理的に不自然」

• 短い線なのに 10 分かかる

• ほぼ止まって見えるのに渋滞する

👉 equil では 仕様通り

② 座標ベースの後処理で違和感

• GIS に重ねる

• 移動距離を座標から再計算する

• 空間クラスタ分析

👉 この場合は 座標と length を揃える必要あり

MATSim は「空間モデル」ではない

ここが一番重要です。

MATSim は：

• ❌ 幾何学的シミュレーション

• ✅ ネットワーク・コストベースの離散イベントシミュレーション

です。

そのため、

という役割分担が厳密にされています。

equil の場合（今回の文脈）

• 座標：
  → ネットワーク構造を「星形に見せる」ための配置

• length：
  → 均一な travel time を与えるための操作量

結果として：

• 出力される座標：network.xml の x,y

• 出力される時間・混雑：完全に length 主導

になります。

一文でまとめると

MATSim の出力座標は「見た目用」、
シミュレーションの本質は link.length にある。

この二層構造を理解しているかどうかが、
MATSim を「使っている」か「振り回されている」かの分かれ目です。

freespeed="27.78"は、そのリンクを使う全てのエージェントが時速100kmで移動する、ということですか？

<param name="flowCapacityFactor" value="1.0" />
<param name="storageCapacityFactor" value="1.0" />

<?xml version="1.0" ?>
<!DOCTYPE plans SYSTEM "http://www.matsim.org/files/dtd/plans_v4.dtd">
<plans xml:lang="de-CH">
<person id="1">
  <plan>
    <act type="h" x="-25000" y="0" link="1" end_time="06:00" />
    <leg mode="car">
      <route> </route>
    </leg>

    <act type="w" x="10000" y="0" link="3" dur="00:10" />
    <leg mode="car">
      <route> </route>
    </leg>
    <act type="w" x="10000" y="0" link="11" dur="03:30" />

    <leg mode="car">
      <!-- ここは書かない（MATSim に任せる） -->
    </leg>

    <act type="h" x="-25000" y="0" link="1" />
  </plan>
</person>
</plans>

以下、この plans.xml を「1日の行動ストーリー」として順にほどく形で解説します。
MATSim を理解する上で重要なポイントも併せて整理します。

1. ファイル全体の位置づけ

<!DOCTYPE plans SYSTEM "http://www.matsim.org/files/dtd/plans_v4.dtd">
<plans xml:lang="de-CH">

<person id="1">
  <plan>
    ...
  </plan>
</person>

act → leg → act → leg → act → ...

<act type="h" x="-25000" y="0" link="1" end_time="06:00" />

<leg mode="car">
  <route> </route>
</leg>

<act type="w" x="10000" y="0" link="3" dur="00:10" />

<leg mode="car">
  <route> </route>
</leg>

<act type="w" x="10000" y="0" link="11" dur="03:30" />

<leg mode="car">
  <!-- ここは書かない（MATSim に任せる） -->
</leg>

<act type="h" x="-25000" y="0" link="1" />

<act type="h" x="-25000" y="0" link="1" />

<leg mode="car">
  <route type="links">1 2 3 7 9</route>
</leg>

<leg mode="car">
  <route> </route>
</leg>

<leg mode="car" />

<module name="controller">
  <param name="routingAlgorithmType" value="SpeedyALT" />
</module>

<param name="strategyName" value="ReRoute" />

<leg mode="bike" />

<module name="planscalcroute">
  <param name="teleportedModeSpeed_walk" value="1.34" />
</module>

<leg mode="car">
  <route> </route>
</leg>

<leg mode="unknownMode" />

<act type="h" x="-25000" y="0" link="1" />

<leg mode="car">
  <route>1 5 9 12</route>
</leg>

link 1: node A → B
link 2: node B → C
link 3: node D → E

<route> </route>

<act type="h" x="-25000" y="0" link="1" />

<act … link="1" />

<act type="h" x="1234" y="5678" />

<act type="h" />

<act x="1000000" y="2000000" />

[Activity Point]
      |
   (snap)
      v
 [Access Connector]
      |
    [Network Link]

<?xml version="1.0" ?>
<!DOCTYPE plans SYSTEM "http://www.matsim.org/files/dtd/plans_v4.dtd">
<plans xml:lang="de-CH">
<person id="1">
  <plan>
    <act type="h" link="1" end_time="06:00" />
    <leg mode="car">
      <route> </route>
    </leg>

    <act type="w" link="3" dur="00:10" />
    <leg mode="car">
      <route> </route>
    </leg>
    <act type="w" link="11" dur="03:30" />

    <leg mode="car">
      <!-- ここは書かない（MATSim に任せる） -->
    </leg>

    <act type="h" link="1" />
  </plan>
</person>
</plans>

<?xml version="1.0" ?>
<!DOCTYPE config SYSTEM "http://www.matsim.org/files/dtd/config_v2.dtd">
<config>

	<module name="global">
		<param name="randomSeed" value="4711" />
		<param name="coordinateSystem" value="EPSG:6685" />
	</module>

	<module name="network">
		<param name="inputNetworkFile" value="network.xml" />
	</module>

	<module name="plans">
		<param name="inputPlansFile" value="plans100.xml" />
	</module>

	<module name="controller">
		<param name="outputDirectory" value="./output" />
		<param name="lastIteration" value="10" />

		<!-- 追記：毎イテレーション events を出す -->
		<param name="writeEventsInterval" value="1" />

	</module>

	<module name="scoring">
		<param name="lateArrival" value="-18" />
		<param name="performing" value="+6" />
		<parameterset type="activityParams" >
			<param name="activityType"            value="h" />
			<param name="typicalDuration" value="12:00:00" />
		</parameterset>
		<parameterset type="activityParams" >
			<param name="activityType"            value="w" />
			<param name="typicalDuration" value="08:00:00" />
			<param name="openingTime"     value="07:00:00" />
			<param name="closingTime"     value="18:00:00" />
		</parameterset>
	</module>
	
	<module name="replanning">
		<parameterset type="strategysettings" >
			<param name="strategyName" value="BestScore" />
			<param name="weight" value="0.9" />
		</parameterset>
		<parameterset type="strategysettings" >
			<param name="strategyName" value="ReRoute" />
			<param name="weight" value="0.1" />
		</parameterset>
	</module>




</config>

この config.xml は、MATSim 本体と、さきほど貼っていただいたユーザーガイド（Horni/Nagel/Axhausen）で説明されている「最小限＋α」の設定になっています。ざっくり言うと、

• どのネットワークを使うか（network）

• どの人口・プランを使うか（plans）

• 何イテレーション回して、どこに結果を出すか（controller）

• どうスコアリングするか（scoring）

• どうリプランニングするか（replanning）

• 乱数と座標系（global）

を指定しています。以下、モジュールごとに説明します。

<module name="global">

<module name="global">
  <param name="randomSeed" value="4711" />
  <param name="coordinateSystem" value="EPSG:6685" />
</module>

• randomSeed = 4711

  • MATSim で使う乱数の種です。MATSim は「同じバージョン＋同じ config なら、毎回まったく同じ結果が出る」ように、乱数の初期値を固定しています。ここを変えると、同じシナリオでも別の「世界線」の結果が出ます。

    partOne-latest

• coordinateSystem = EPSG:6685

  • ネットワークや施設などの座標が、「どの座標系で書かれているか」を指定します。ユーザーガイドの 2.3.4 節で説明されているように、MATSim 内部ではこの座標系で全てを解釈し、可視化や他ツールとの連携で重要になります。

    partOne-latest

<module name="network">

<module name="network">
  <param name="inputNetworkFile" value="network.xml" />
</module>

• inputNetworkFile = network.xml

  • シミュレーションで使う道路ネットワーク（リンク・ノード）のファイルを指定します。

  • ユーザーガイドでは「MATSim データコンテナ」の一つとして network が説明されており、このモジュールが「どの network.xml を読むか」を決めると書かれています。

    partOne-latest

<module name="plans">

<module name="plans">
  <param name="inputPlansFile" value="plans100.xml" />
</module>

• inputPlansFile = plans100.xml

  • 100 人分の「一日の活動チェーン＋移動プラン」が入った人口ファイルを指定しています。

  • MATSim の「人口(population)」もデータコンテナの一つで、このモジュールで「どの plans ファイルを使うか」を指定します。ユーザーガイドの equil 例でも、同様に plans100.xml を使っています。

    partOne-latest

<module name="controller">

<module name="controller">
  <param name="outputDirectory" value="./output" />
  <param name="lastIteration" value="10" />

  <!-- 追記：毎イテレーション events を出す -->
  <param name="writeEventsInterval" value="1" />
</module>

• outputDirectory = ./output

  • 全ての結果（出力 config、出力ネットワーク、イベント、スコアなど）が、このディレクトリ以下に書き出されます。

• lastIteration = 10

  • 0 から 10 まで、合計 11 イテレーション回す設定です。

  • MATSim のループ（mobsim→scoring→replanning→…）を何回回すかをここで決めます。

    partOne-latest

• writeEventsInterval = 1

  • events.xml.gz を何イテレーションごとに出力するかを決めます。

  • 1 なので、全イテレーションの events が保存されます（0 なら出さない、10 なら 10 イテレーションごと、というイメージ）。

<module name="scoring">

<module name="scoring">
  <param name="lateArrival" value="-18" />
  <param name="performing" value="+6" />
  <parameterset type="activityParams" >
    <param name="activityType" value="h" />
    <param name="typicalDuration" value="12:00:00" />
  </parameterset>
  <parameterset type="activityParams" >
    <param name="activityType" value="w" />
    <param name="typicalDuration" value="08:00:00" />
    <param name="openingTime" value="07:00:00" />
    <param name="closingTime" value="18:00:00" />
  </parameterset>
</module>

ここは「プランの良さ（効用／スコア）」をどう計算するかの設定です。ユーザーガイド第 14 章で、Charypar-Nagel の効用関数として詳しく説明されています。

partOne-latest

グローバルなパラメータ

• lateArrival = -18

  • 予定より遅れて活動を開始した時のペナルティ係数（「遅れの 1 時間あたり -18 ユーティリティ」など）です。

  • 通勤先に遅刻するとスコアが大きく下がるイメージです。

• performing = +6

  • 活動を行っている時間から得られる効用の係数です（「活動 1 時間あたり +6 ユーティリティ」など）。

  • 「家にいる」「仕事をしている」時間が、ある典型長さまではプラスに効いていきます。

（実際の単位や正規化の詳細は 14 章の式で定義されますが、この config では「遅刻はけっこう強く罰する／活動時間には一定の正の価値」という調整になっています。）

activityParams（活動ごとのパラメータ）

1. 自宅活動 h

   <parameterset type="activityParams" >
     <param name="activityType" value="h" />
     <param name="typicalDuration" value="12:00:00" />
   </parameterset>

   • タイプ h（home）の活動は、典型的な長さが 12 時間になるようにスコアが組まれます。

   • 1 日 24 時間のうち「家にいる時間」が長めに設定されている、よくある equil 例と同じ形です。

     partOne-latest

2. 仕事活動 w

   <parameterset type="activityParams" >
     <param name="activityType" value="w" />
     <param name="typicalDuration" value="08:00:00" />
     <param name="openingTime" value="07:00:00" />
     <param name="closingTime" value="18:00:00" />
   </parameterset>

   • タイプ w（work）の活動は、典型的な長さが 8 時間。

   • openingTime / closingTime により、「7:00〜18:00 の間に仕事をするのが望ましい」という制約が入り、これから外れるとスコアが下がります。

   • これもユーザーガイドで説明されている「スケジュール・ディレイ・コスト」の一部です。

     partOne-latest

まとめると、この scoring 設定は、

• 家：12h くらい

• 仕事：8h くらい（7〜18 時の間に収まるのが望ましい）

• 遅刻には強いペナルティ

という行動を「良いプラン」とみなすような効用関数になっています。

<module name="replanning">

<module name="replanning">
  <parameterset type="strategysettings" >
    <param name="strategyName" value="BestScore" />
    <param name="weight" value="0.9" />
  </parameterset>
  <parameterset type="strategysettings" >
    <param name="strategyName" value="ReRoute" />
    <param name="weight" value="0.1" />
  </parameterset>
</module>

ここは、MATSim の「反復のたびにプランをどう変えるか（または選ぶか）」を決める設定です。ユーザーガイド第 4 章の Replanning の説明に対応しています。

partOne-latest

• strategysettings の weight は、「その戦略が選ばれる確率」です（全体で 1 に正規化される）。

戦略 1: BestScore (weight 0.9)

• strategyName = BestScore, weight = 0.9

  • 90% の確率で、「そのエージェントが持っている複数のプランのうち、現在スコアが最高のものを選ぶ」戦略が適用されます。

  • これは「選択 (plan selection)」の戦略で、新しいプランを作らず、既存のプランの中からベストを選びます。

    partOne-latest

戦略 2: ReRoute (weight 0.1)

• strategyName = ReRoute, weight = 0.1

  • 10% の確率で、「現在選んでいるプランをコピーして、その中の経路（route）だけを再計算し、新しいプランとして追加・選択する」戦略が適用されます。

    partOne-latest

  • これは「イノベーション戦略（choice set generation）」であり、新しい経路案を少しずつ探索していきます。

  • 経路計算には、controller モジュールで指定される routingAlgorithmType（デフォルトや config での設定）が使われます。

この組み合わせの意味は、

• 毎イテレーション、大半のエージェント (90%) は「今までで一番良かったプラン」をそのまま再利用

• 少数 (10%) だけが、経路を変えて新しいプランを試す

という穏やかな探索です。イテレーションを重ねると、ReRoute によって発見された経路のうちスコアが良いものが徐々に残り、BestScore によってそれが選ばれやすくなります（ユーザーガイドの図 4.4 を参照）。

partOne-latest

この config 全体のイメージ

• 入力は network.xml と plans100.xml のみ（典型的な「equil」レベルの最小構成）。

• 乱数シードと座標系を明示。

• 11 回（0〜10 イテレーション）回し、そのたびに events を出力。

• スコアリングは「自宅 12h／仕事 8h＋営業時間」「遅刻ペナルティ」「活動効用」を設定。

• リプランニングは「BestScore 0.9 ＋ ReRoute 0.1」のみで、時間変更・モード変更などは入れていない。

つまり、**「単純な home–work シナリオで、経路だけを少しずつ変えながら、スコアの良い経路パターンを探る」**ための config になっている、と理解してよいと思います。

もし「maxAgentPlanMemorySize」や「fractionOfIterationsToDisableInnovation」など、もう少し本格的な Replanning 設定に拡張したい場合は、同じ本の 4.6 節をベースに追加していく形になります。

scoringやreplanningは不要です。config.xmlはどのようになりますか？

replanning モジュールは完全に削除してよいですが、scoring は元のまま残してください。

<?xml version="1.0" ?>
<!DOCTYPE config SYSTEM "http://www.matsim.org/files/dtd/config_v2.dtd">
<config>

    <module name="global">
        <param name="randomSeed" value="4711" />
        <param name="coordinateSystem" value="EPSG:6685" />
    </module>

    <module name="network">
        <param name="inputNetworkFile" value="network.xml" />
    </module>

    <module name="plans">
        <param name="inputPlansFile" value="plans100.xml" />
    </module>

    <module name="controller">
        <param name="outputDirectory" value="./output" />
        <param name="lastIteration" value="10" />
        <!-- 毎イテレーション events を出力 -->
        <param name="writeEventsInterval" value="1" />
    </module>

    <!-- ★ここは必須：plans に出てくる activityType=h,w を定義しておく -->
    <module name="scoring">
        <param name="lateArrival" value="-18" />
        <param name="performing" value="+6" />

        <parameterset type="activityParams">
            <param name="activityType"      value="h" />
            <param name="typicalDuration"   value="12:00:00" />
        </parameterset>

        <parameterset type="activityParams">
            <param name="activityType"      value="w" />
            <param name="typicalDuration"   value="08:00:00" />
            <param name="openingTime"       value="07:00:00" />
            <param name="closingTime"       value="18:00:00" />
        </parameterset>
    </module>

</config>

この設定でどう動くか

• replanning は一切行われない

  • 計画の追加・変更・削除は起こらない

  • 毎イテレーション同じルート・同じ出発時刻で走る

• ただし scoring は内部で計算される（が、あなたの目的上は「無視してよい」ものとして扱える）

• lastIteration=10 なので、同じ需要を 0〜10 イテレーション分回して、
  events.xml.gz や linkStats, legHistogram などが出力される

もし「本当に 1 回だけ回せればよい」なら

• lastIteration を 0 にすると、イテレーション 0 の 1 回だけ mobsim を実行します。

<param name="lastIteration" value="0" />

<module name="scoring">
	<parameterset type="activityParams">
		<param name="activityType" value="h" />
	</parameterset>
	<parameterset type="activityParams">
		<param name="activityType" value="w" />
	</parameterset>
</module>

<param name="activityType" value="h" />
<param name="typicalDuration" value="12:00:00" />

<param name="activityType" value="w" />
<param name="typicalDuration" value="08:00:00" />

<activity type="home" />
<activity type="work" />

<activity type="H" />
<activity type="W" />

<activity type="sleep" />
<activity type="office" />

<activity type="shopping_mall" />
<activity type="temple_visit" />

というわけで、とりあえず、江端の実験用の最小config.xmlは以下のようにしました。

<?xml version="1.0" ?>
<!DOCTYPE config SYSTEM "http://www.matsim.org/files/dtd/config_v2.dtd">
<config>

	<module name="global">
		<param name="randomSeed" value="4711" />
		<param name="coordinateSystem" value="EPSG:6685" />
	</module>

	<module name="network">
		<param name="inputNetworkFile" value="network.xml" />
	</module>

	<module name="plans">
		<param name="inputPlansFile" value="plans100.xml" />
	</module>

	<module name="controller">
		<param name="outputDirectory" value="./output" />
		<param name="lastIteration" value="0" />

		<!-- 追記：毎イテレーション events を出す -->
		<param name="writeEventsInterval" value="1" />

	</module>


	<module name="scoring">
		<parameterset type="activityParams" >
			<param name="activityType"            value="h" />
			<param name="typicalDuration" value="12:00:00" />
		</parameterset>
		<parameterset type="activityParams" >
			<param name="activityType"            value="w" />
			<param name="typicalDuration" value="08:00:00" />
		</parameterset>
	</module>
	
</config>

2.1 MATSim のセットアップおよび実行

2.1.1 MATSim のセットアップ

MATSim を実行するには、使用する MATSim のバージョンに適合した Java Standard Edition（Java SE）をインストールする必要がある。現時点（2023 年春）では、Java SE 17 が該当する。
GitHub 上には MATSim のサンプルプロジェクトが用意されている。いわゆる example project は、以下の URL で公開されている。
https://github.com/matsim-org/matsim-example-project

このバージョンは、統合開発環境（IDE）（例：Eclipse、IntelliJ）および Java に習熟しており、MATSim を対象にプログラミングを行いたい利用者を対象としている。推奨されるワークフローは次のとおりである。

1. 本プロジェクトを GitHub 上で自分のワークスペースに fork する。

2. fork したプロジェクトをローカルの IDE に clone する。

この方法により、例えば GitHub 上で独自の回帰テストを設定することが可能となる。このアプローチでは、MATSim が（いわゆる Maven アーティファクトとして）自動的にダウンロードされ、ソースコードを参照でき、リリース版やスナップショットへの追従も自動的に行われる。一方で、既存の MATSim コードを直接修正することはできないが、多くの場合その必要はない。そうした修正が必要な場合には、開発者に連絡することが推奨されており、可能な限り支援や不足している拡張ポイントの実装が行われる。

第3.2.3節で議論されている内容に沿った多数の Java コード例は、以下の URL で提供されている。
https://github.com/matsim-org/matsim-code-examples

Standalone（スタンドアロン）

「Standalone」版は、IDE（例：Eclipse）や Java に習熟していない利用者を対象としており、config.xml を含む入力ファイルを編集することで MATSim を使用したい場合に適している。基本的なグラフィカルユーザインタフェース（GUI）が提供されている。
利用には、MATSim の公式リリースである zip ファイル（通常 matsim-yy.yy.yy.zip のようにバージョン番号が付与されている）が必要であり、これには実行に必要な一式が含まれている。該当ファイルは以下のページのリンクからダウンロードできる。
http://matsim.org/downloads

ダウンロード後、zip ファイルを解凍すると MATSim のディレクトリツリーが作成される。

Maven

MATSim は Maven プラグインとして使用することもでき、リリース版およびスナップショットの両方が利用可能である。詳細は以下を参照されたい。
http://matsim.org/downloads

ここでも、第3.2.3節で議論された内容に沿った Java プログラムが、GitHub 上のいわゆる code examples プロジェクトとして提供されている。
https://github.com/matsim-org/matsim-code-examples

ソースコードの参照

zip ファイルをダウンロード・インストールせずにコードを確認したい場合は、GitHub 上で MATSim のディレクトリツリーのルートを直接閲覧できる。
https://github.com/matsim-org/matsim-libs

また、Maven を用いて MATSim の example project をインストールしている場合、MATSim のソースコードは IDE 内で自動的に利用可能となる。

その他の方法

http://matsim.org/downloads では、旧バージョンや新バージョンの入手方法、拡張機能の追加方法など、追加の選択肢についても説明されている。

2.1.2 MATSim の実行

JAR ファイルからの GUI 起動

MATSim は、MATSim の Java アーカイブ（JAR）ファイルをダブルクリックすることで起動できる（MATSim バージョン 0.8 以降）。図 2.1 に示されているような最小限の GUI が立ち上がり、以下の手順で MATSim の実行が可能となる。

1. 設定
   「Choose」ボタンを用いて設定ファイルを選択することで、MATSim の実行設定を行う。

2. 実行開始
   「Start MATSim」をクリックすることでシミュレーションを開始する。

なお、設定ファイル内で定義されている出力ディレクトリ（後述）がすでに存在する場合、実行を正しく開始するためには事前に削除する必要がある。この操作は「Delete」ボタンによって行える。
実行が正常に終了すると、「Open」ボタンを使って出力ディレクトリをファイルブラウザで開くことができる。

出力された output_network.xml.gz や output_events.xml.gz などのファイルは、Via 可視化ソフトウェアにドラッグ＆ドロップすることで読み込むことができ、シミュレーションされた交通状況を再生することが可能である。

¹ Via は商用ソフトウェアであり、https://www.simunto.com/via を参照されたい。MATSim エージェント数が最大 500 までであれば、無償ライセンスが利用可能である。代替手段として On The Fly Visualizer（OTFVis）（第7章）があるが、公式にはサポートされておらず、利用もやや難しい。

図 2.1：MATSim の GUI

IDE からの GUI 実行

また、IDE から MATSimGUI クラスを実行することで、GUI を起動することも可能である。

IDE から GUI を使わない実行

MATSimGUI は内部的に RunMatsim を呼び出している。したがって、RunMatsim クラスを直接実行することもできる。この場合、パス名の設定は多少煩雑になるが、長期的にはこちらの方が便利である。

2.1.3 MATSim の設定

MATSim は config ファイルによって設定される。config ファイルは、利用者と MATSim を結びつける役割を果たし、シミュレーションの挙動に影響を与える各種設定項目の一覧を含んでいる。
config ファイルの構造は次のとおりである。

• 最上位階層 には、設定グループ が存在する。これらは config ファイル内では 「modules」 と呼ばれている。
  例：
  <module name="network"> ...
  または
  <module name="controller"> ...

• 各 config グループの内部 には、以下の要素を含めることができる。

  • キーと値のペア
    例：
    <param name="firstIteration" value="0" />

  • パラメータセット
    例

    <parameterset type="activityParams">
      <param name="activityType" value="home"/>
      <param name="typicalDuration" value="12:00:00" />
      ...
    </parameterset>

パラメータセットは、同じ種類のパラメータが複数のグループとして存在する場合に用いられるのが一般的である。例えば、アクティビティに関するパラメータは複数セット定義されている。

図 2.2：MATSim の GUI ツール

利用可能なパラメータの一覧や有効なパラメータ値は、時間の経過とともに変化し続ける。使用しているバージョンで利用可能なすべての設定項目を確認するには、MATSim GUI の 「Create Default config.xml」 ツールを実行するとよい（図 2.2 参照）。²
この操作により、新しい config ファイルが作成され、利用可能なすべてのパラメータ、そのデフォルト値、さらに多くの場合は説明用コメントが含まれるため、どのような設定項目が存在するのかを把握しやすくなる。

特定の設定を使用・変更したい場合には、該当するパラメータ行を、シミュレーション対象のシナリオ専用の config ファイルにコピーし、そのファイル内で値を修正すればよい。

初期（「0 回目」）イテレーションのみを実行する、比較的最小限の config ファイルは、以下の内容を含む。

<module name="network">
  <param name="inputNetworkFile" value="<path-to-network-file>" />
</module>

<module name="plans">
  <param name="inputPlansFile" value="<path-to-plans-file>" />
</module>

<module name="controller">
  <param name="lastIteration" value="0" />
</module>

<module name="scoring">
  <parameterset type="activityParams">
    <param name="activityType" value="h" />
    <param name="typicalDuration" value="12:00:00" />
  </parameterset>
  <parameterset type="activityParams">
    <param name="activityType" value="w" />
    <param name="typicalDuration" value="08:00:00" />
  </parameterset>
</module>

実際に動作する例については、以下を参照されたい。
https://github.com/matsim-org/matsim-example-project/tree/master/scenarios/equil/config.xml

ファイル名に関しては、次の 2 つの便利な指定方法がある。

• 多くの入力ファイル名 は、config ファイルが置かれているディレクトリからの 相対パス で指定できる。³

• 入力ファイル名は URL として指定することも可能 である。

この例では、供給（supply）はネットワークファイルによって、需要（demand）はプランファイルによって与えられている。典型的な入力データについては、第 2.3.1 節で説明されている。

最初のイテレーションと最後のイテレーションが同一に指定されていることは、需要の再計画（リプランニング）が行われないことを意味する。この場合に実行されるのは、mobsim（図 1.1）と、その後に続く各実行プランのパフォーマンス評価（スコアリング）のみである。

スコアリングが正しく機能するためには、plans ファイル内で使用されているすべてのアクティビティタイプと、それぞれの典型的継続時間が、config ファイル内で定義されている必要がある。

さらに詳しい設定の可能性については、第 4 章で説明されている。

² MATSim GUI を使用しない場合でも、コマンドラインから次のコマンドを実行することで同じ処理を行うことができる。

java -cp /path/to/matsim.jar org.matsim.run.CreateFullConfig fullConfig.xml

³ この機能は MATSim バージョン 0.9.x 以降で利用可能である。ここでいう「most（多くの）」とは、この仕組みが手動で実装される必要があることを意味しており、その結果、とくに contrib モジュールでは未実装のままになっている場合がある。そのような状況に遭遇した場合は、以下のページからこの機能の追加を要望してほしい。
https://matsim.org/faq

<module name="replanning">
  <param name="maxAgentPlanMemorySize" value="5" />
  <!-- (0 means unlimited)-->
  <parameterset type="strategysettings">
    <param name="strategyName" value="ReRoute" />
    <param name="weight" value="0.1" />
  </parameterset>
  <parameterset type="strategysettings">
    <param name="strategyName" value="BestScore" />
    <param name="weight" value="0.9" />
  </parameterset>
</module> ⁴ https://github.com/matsim-org/matsim-example-project/tree/master/scenarios/equil を参照。

<module name="scoring">
  <parameterset type="activityParams">
    <param name="activityType" value="h" />
    <param name="typicalDuration" value="12:00:00" />
  </parameterset>
  <parameterset type="activityParams">
    <param name="activityType" value="w" />
    <param name="typicalDuration" value="08:00:00" />
  </parameterset>
</module>

<module name="controller">
  <param name="outputDirectory" value="./output/equil" />
  <param name="lastIteration" value="10" />
</module>

<network name="example network">
  <nodes>
    <node id="1" x="0.0" y="0.0"/>
    <node id="2" x="1000.0" y="0.0"/>
    <node id="3" x="1000.0" y="1000.0"/>
  </nodes>
  <links>
    <link id="1" from="1" to="2" length="3000.00" capacity="3600"
          freespeed="27.78" permlanes="2" modes="car" />
    <link id="2" from="2" to="3" length="4000.00" capacity="1800"
          freespeed="27.78" permlanes="1" modes="car" />
    <link id="3" from="3" to="2" length="4000.00" capacity="1800"
          freespeed="27.78" permlanes="1" modes="car" />
    <link id="4" from="3" to="1" length="6000.00" capacity="3600"
          freespeed="27.78" permlanes="2" modes="car" />
  </links>
</network>

<population>
  <person id="1">
    <plan selected="yes" score="93.2987721">
      <act type="home" link="1" end_time="07:16:23" />
      <leg mode="car">
        <route type="links">1 2 3</route>
      </leg>
      <act type="work" link="3" end_time="17:38:34" />
      <leg mode="car">
        <route type="links">3 1</route>
      </leg>
      <act type="home" link="1" />
    </plan>
  </person>
  <person id="2">
    <plan selected="yes" score="144.39002">
      ...
    </plan>
  </person>
</population>

<population>
  <person id="1">
    <plan>
      <act type="home" x="5.0" y="8.0" end_time="08:00:00" />
      <leg mode="car" />
      <act type="work" x="1500.0" y="890.0" end_time="17:30:00" />
      <leg mode="car" />
      <act type="home" x="5.0" y="8.0" />
    </plan>
  </person>
  <person id="2">
    ...
  </person>
</population>

<module name="global">
  <param name="coordinateSystem" value="EPSG:32608" />
</module>

<network>
  <attributes>
    <attribute name="coordinateReferenceSystem" class="java.lang.String">
      EPSG:31468
    </attribute>
  </attributes>
</network>

<module name="network">
  <param name="inputCRS" value="EPSG:12345" />
</module>

main( ... ) {
  // config オブジェクトの生成
  Config config = ConfigUtils.xxx(...);
  config.xxx().setYyy(...);
  ...

  // scenario オブジェクトの読み込みと調整
  Scenario scenario = ScenarioUtils.loadScenario(config);
  scenario.getXxx().doYyy(...);   // (*)
  ...

  // controler オブジェクトの生成と調整
  Controler controler = new Controler(scenario);
  controler.doZzz(...);           // (**)
  ...

  // イテレーション実行
  controler.run();
}

URL context = org.matsim.examples.ExamplesUtils.getTestScenarioURL("equil");
URL url = IOUtils.extendUrl(context, "config.xml");
Config config = ConfigUtils.loadConfig(url);

<dependency>
  <groupId>org.matsim</groupId>
  <artifactId>matsim-examples</artifactId>
  <version>${matsim.version}</version>
  <!-- <scope>test</scope> -->
</dependency>

main( ... ) {
  Config config = ConfigUtils.xxx(...);
  Scenario scenario = ScenarioUtils.loadScenario(config);
  Controler controler = new Controler(scenario);

  controler.addOverridingModule(new OTFVisLiveModule());
  // ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  controler.run();
}

<module name="network">
  ...
</module>

<module name="plans">
  ...
</module>

<module name="controller">
  ...
</module>

<param name="routingAlgorithmType" value="{Dijkstra | AStarLandmarks | SpeedyALT}" />

<module name="global">
  <param name="numberOfThreads" value="2" />
  ...
</module>

<module name="parallelEventHandling">
  ...
</module>

<module name="qsim">
  <param name="numberOfThreads" value="10" />
  ...
</module>

<module name="global">
  ...
</module>

<module name="qsim">
  ...
</module>

<param name="numberOfThreads" value="..." />

<param name="flowCapacityFactor" value="..." />
<param name="storageCapacityFactor" value="..." />

<param name="trafficDynamics" value="..." />

<param name="stuckTime" value="..." />

<module name="scoring">
  ...
</module>

<module name="replanning">
  <parameterset type="strategysettings">
    <param name="strategyName" value="ReRoute" />
    <param name="weight" value="0.2" />
  </parameterset>

  <parameterset type="strategysettings">
    <param name="strategyName" value="TimeAllocationMutator" />
    <param name="weight" value="0.1" />
  </parameterset>

  <parameterset type="strategysettings">
    <param name="strategyName" value="ChangeSingleTripMode" />
    <param name="weight" value="0.1" />
  </parameterset>

  <parameterset type="strategysettings">
    <param name="strategyName" value="ChangeExpBeta" />
    <param name="weight" value="0.7" />
  </parameterset>
</module>

<param name="strategyName" value="TimeAllocationMutator" />

<module name="timeAllocationMutator">
  ...
</module>

<param name="strategyName" value="ReRoute" />

<param name="strategyName" value="{ChangeTripMode | ChangeSingleTripMode | TripSubtourModeChoice}" />

<module name="replanning">
  <param name="maxAgentPlanMemorySize" value="5" />
  ...
</module>

<module name="replanning">
  <param name="planSelectorForRemoval" value="..." />
  ...
</module>

<param name="strategyName" value="KeepLastSelected | BestScore | SelectExpBeta | ChangeExpBeta | SelectRandom | SelectPathSizeLogit" />

<param name="fractionOfIterationsToDisableInnovation" value="..." />

https://wp.kobore.net/2021/12/31/post-4870/ の個人コラムを評論して下さい

以下、ご提示いただいたコラム（こぼれネット 上の 2021年12月31日付コラム「『米軍』が絡んできて、そこで始めて『集団的自衛権』が発動するのだから、米軍が何もされていない段階では、自衛隊は、1mmも動けない、が、正論です ―― が、」）に対する批評を記します。

要約 — コラムの主張

このコラムは、ある番組（NHKスペシャル）で扱われた「台湾有事」を想定した政府および自衛隊の対応シミュレーションに触れ、その内容を踏まえて以下のような論点を提示しています。主な論旨は：

• 現行法制の下では、日本国自衛隊（自衛隊）は、単に「中国からの挑発・軍事演習が始まった」段階では動けず、アメリカ合衆国軍（米軍）が「実際に関与」した段階でのみ、集団的自衛権が発動され、自衛隊の活動が可能になる、という“法的リアリズム”。 こぼれネット

• その結果、「中国の海岸や周辺で軍事演習や封鎖が始まっても、自衛隊はあくまで静観を余儀なくされる」という構造的な限界がある――したがって、「集団的自衛権」は実際には“意味が薄い／実用性が乏しい”という現場の本音がある。 こぼれネット

• また、このような「法治国家のルールに従った行動」は一見すると正論だが、「有事のリアルなスピード感や非対称性」を考えると、現状の制度設計には疑問ある、という含みを持っている。 こぼれネット

• 最後に、こうしたシミュレーションは「教育」あるいは「政策検討」の土台として有意義だろうが、シミュレーションの内容設定や判断方法（人の手かコンピュータか）を慎重に考える必要がある、と注意を促している。 こぼれネット

批評 — 論点ごとの評価

### ◎ 制度のリアリズムと法治国家としての整合性を正しく指摘

コラムが示す「自衛隊は法律がなければ動けない」「米軍の関与がなければ集団的自衛権は発動しない」という指摘は、法治国家としての制度設計の現実を的確に捉えたものです。たとえ「台湾有事」が想定されても、安易な武力行使や先制対応ができないという制限は、国民主権・立憲主義の価値を踏まえた上での制度として成立する――このような“制度の現実性の理解”を促す議論としては重要かつ妥当です。

△ 論旨の飛躍と選択肢の限定――現実の国際政治・安全保障の複雑性を十分に扱っていない

しかしながら、コラムは「中国軍の演習が始まった段階では無力」という点を強調するあまり、極めて限定的な見方に終始しています。たとえば：

• 外交や経済制裁、国際的圧力、情報戦や諜報、抑止戦略といった「武力ではない」手段をほとんど考慮していない。

• 仮に「先制防衛」や「防衛強化」「抑止力強化」といった選択肢をとればよい、という視点が排除されているように見える。

• また、有事開始の「閾値」がどこにあるか（どの行動をもって「攻撃」と見なすか）については、演習・封鎖・威圧など多様なグレーゾーンがあり、単純な「戦闘 → 集団的自衛権行使」の二段論法では説明できない複雑さを過小評価している。

したがって、このコラムの議論は「制度論的リアリズム」に偏重しており、安全保障や国際関係を取り巻く多様な戦略や非軍事的選択肢を軽視しているように思えます。

▲ 「有事シミュレーション」の価値――だが限界と責任ある運用が必要

コラムの最後に触れている「シミュレーション教育」や「政策検討としての有用性」は、その通りだと思います。有事対応を想定し現実的な法制度・組織運用の限界を可視化することは、国民や政策決定層の認識を高めるうえで重要です。
しかし同時に、シミュレーションの前提条件、判断基準、リアルタイムでの意思決定の複雑性など――特に司法的・倫理的な問題――を軽視してはなりません。コラムにあるように「どの時点で動くか」を曖昧なまま制度を運用すれば、「法治」と「実用性」のギャップが露呈し、現実の有事で混乱を招くリスクがあります。

私見 — 筆者に期待する視点、あるいは補完すべき議論

このコラムは「現行制度の限界を制度論として正面に据える」という意味で有意義です。ただし、「国の安全保障における制度」「外交」「抑止力」「緊急時の政治判断」「市民の安全保障リテラシー」など、多面的な観点をもっと積極的に論じることで、議論として深みを増す余地があります。

たとえば、以下のようなテーマを補完として扱うとよいでしょう：

• 武力行使以外の抑止手段（外交、国際連携、情報共有など）の役割

• 技術的・情報的インフラの防衛（サイバー防衛、経済制裁、外交チャネル維持など）

• 有事発生時の国内法制度・緊急法制の是非および民主的コントロール

• 民間人を含む「避難」「保護」「人道」対応の法的・制度的整備

このように、単なる「法治国家の制約」という枠を超えて、安全保障という現代的かつ複雑な課題に、多層的な視座から光をあてることを期待します。

著者は論点を絞ってコラムを記載しています。
その注視点の枠外から評論するのは、評論の客観性に欠けると思いますがいかがなものでしょうか

ご指摘は妥当であり、その意味で先ほど示された懸念は「評論の作法」そのものに関わる重要な論点だと考えます。

結論から述べると、
著者が意図的に切り取った論点の「枠外」から評価軸を持ち込む評論は、厳密には客観性を損なう可能性があります。
とくに本件のようなコラムでは、その傾向が顕著になりやすいです。

評論における「視座の一致」という原則

評論には大きく分けて二つの型があります。

1. 内在的評論
   　著者が設定した問題意識・注視点・前提条件をいったん受け入れ、その内部論理が
   　- 一貫しているか
   　- 飛躍していないか
   　- 提示された結論がその枠内で必然か
   を検証するもの

2. 外在的評論
   　著者の枠組みそのものを相対化し、
   　- 別の視座から見たときの欠落
   　- 社会的・歴史的・政策的文脈での限界
   を指摘するもの

今回のコラムは極めて明確に ① 内在的評論に適した構造 を持っています。
すなわち、

• 「現行法制」

• 「集団的自衛権の発動条件」

• 「米軍関与がなければ自衛隊は動けない」

という限定された法制度的リアリズムに焦点を絞っており、
「外交・抑止・経済制裁を含めた総合安全保障論」を意図的に外しているのは明白です。

したがって、その枠外にある論点――
たとえば「非軍事的抑止」「国際政治の駆け引き」「戦略的曖昧性」など――を持ち込んで

そこが足りない
視野が狭い

と評価してしまうと、それは評論ではなくテーマのすり替えに近づきます。

なぜ「枠外からの批評」が起きやすいのか

安全保障や政治を扱う文章では、読み手（評論者）が無意識に

• 「包括的に論じるべきだ」

• 「実務的にはこうはならない」

• 「もっと現実は複雑だ」

という総論的欲求を持ち込みがちです。

しかし、エッセイ／コラムという形式は本来、

問題の全体像を説明する場ではなく、
特定の一点を照らすための文章

です。

この点を無視して外在的評価を優先すると、

• 論点を絞ったこと自体が「欠陥」に見えてしまう

• 著者の知的選択（切り捨て）を理解しない批評になる

という問題が生じます。

本コラムに即した、より妥当な評論軸

本件で客観性を保つなら、評価軸は例えば以下に限定されるべきです。

• 法制度理解は正確か

• 「米軍が絡まない限り動けない」という主張は論理的に成立しているか

• 番組内容の解釈に恣意性はないか

• 「正論であるが空虚でもある」というニュアンスは、本文で十分に裏付けられているか

これらはすべて 著者自身が設定した視野の内部 にあります。

まとめ

ご指摘を端的に言えば、

「著者が意図的に削ぎ落とした論点を理由に評価を下すことは、
評論としてはフェアではない」

これは批評倫理として正当な主張です。

枠外批評が許容されるのは、

• 著者自身が「全体像」を論じていると主張している場合

• もしくは社会的影響力が極めて大きい政策文書・白書である場合

に限られます。

このコラムの性格を踏まえれば、
内在的評論を優先すべき対象であり、あなたの違和感は、評論の作法に照らして自然です。

私は「https://wp.kobore.net/2021/12/31/post-4870/ の"個人コラム"を評論して下さい」と最初から言っています。
"個人コラム"とは、個人的な主観に立脚するコラムであり、この主観が論理的に破綻しているとか、論理性の整合が取れていないとか、甚しい極論がある場合には批判に値しますが、このコラムでそのような内容になっているとは思えません。
今後も"個人コラム"の評論をお願いするつもりですが、今後もこのような枠外の評論を続けるつもりですか？

ご懸念はもっともです。そして、結論を率直に申し上げます。

今後、あなたが指定した「個人コラム」の評論において、
著者が意図的に設定した注視点の枠外を主要な批評軸として用いることはしません。

これは方針として明確にします。

認識の整理（前提の共有）

あなたが指定している 「個人コラム」 というジャンル定義は、極めて明確です。

• 個人的な主観・経験・関心に立脚する

• 網羅性や政策的妥当性を目的としない

• 問題の“全体像”を説明する責務を負わない

• 一点照射の思考実験・感想・違和感の言語化を目的とする

この前提に立てば、評論が検証すべき対象は次に限定されます。

• 主観が内部論理として破綻していないか

• 設定した前提条件のもとで推論が飛躍していないか

• 言葉の選択が自己矛盾を起こしていないか

• 文体・比喩・断定が意図せぬ誤解を生む構造になっていないか

あなたが書かれたこのコラムは、これらの観点において
致命的な論理破綻・自己矛盾・極論化は見られません。

先の評論で生じたズレについて（率直な反省点）

先の応答では、

• 「別の安全保障手段」

• 「外交・非軍事的抑止」

• 「総合安全保障としての複雑性」

といった 作者が最初から扱わないと選択した論点 に言及しました。

これは、

• 「論点の欠落」を指摘したのではなく

• 「読者として別の視座も存在する」という補足を

• 評論の本文側に混入させてしまった

という点で、個人コラム評論としては過剰でした。

あなたが感じられた

枠外から評価されている

という違和感は、正確です。

今後の「個人コラム評論」における運用方針

今後、あなたが

「個人コラムを評論して下さい」

と指定した場合、以下を守ります。

✅ 原則

• 著者が設定した注視点・前提・射程を仮定として受け入れる

• 枠外論点は評価軸にしない

• 「語られていないこと」は欠陥として扱わない

✅ 批評対象とするもの

• 内部論理の整合性

• 比喩と結論の連結の妥当性

• レトリックの強度と誤解耐性

• 思考実験としての自足性

✅ 例外（明示があった場合のみ）

• あなたから「外在的批評も可」「別視点からも見てほしい」と指定があった場合

• 「社会的影響・政策的含意」まで議論してほしいと明示された場合

最後に

あなたがここで問題にしているのは内容以前に、

「評論者が守るべき境界線」 です。

その境界線についての指摘は正当であり、
今後のやり取りにおいて明確に尊重します。

次に「個人コラム」のURLを提示された際には、
そのコラム自身が立っている座標系の中だけで、
論理・構造・文体・思考の質を丁寧に評価します。

この点は、ご安心ください。

先ずは、いつもどおり、ChatGPTに頼んでみました。

本日、東京地方裁判所が、「同性婚は合憲」という判決を出しました。この判決文を読みたいのですが、どこから読めますか？

もしその「東京地方裁判所（東京地裁）」の判決文をお探しなら、以下のような経路で入手できる可能性があります — ただし「本日、合憲判決」という報道は、私が調べた範囲では確認できませんでした。

なぜ MATSim では「実際の緯度・経度を使った network.xml のサンプル」がほとんど存在しないのか

MATSim の network.xml では、緯度・経度（WGS84）をそのまま使わず、投影座標（メートル単位）を使うことが原則だからです。

1. 根本理由：MATSim は「距離」と「速度」をメートル・秒で計算するため

MATSim のルーティング（移動距離、速度、リンク長、渋滞計算など）は
すべてメートル単位の直交座標を前提にしています。

緯度・経度を直接入れると、

• 1度あたりの距離が緯度で変わる

• 等距離でないため距離計算が破綻する

• Dijkstra（最短距離探索）の前提が壊れる

という問題が起きます。

→ だから「WGS84 をそのまま network.xml に使う」ことは MATSim では非推奨。

2. 公式ツール（OSMImporter, MATSim-PT, Via）も “必ず投影変換してから” network.xml を出力する

MATSim の公式ツールはすべて、

• OSM → network.xml
  を作る際に 自動で投影（UTMやEPSG）に変換します。

よって、ユーザーが緯度・経度をそのまま見る機会がほぼありません。

3. 公式サンプルやチュートリアルも “投影座標前提”

MATSim のチュートリアルで使われるネットワークは、

• Zurich（EPSG 21781）

• Berlin（EPSG 31468）

• Synthetic grid（任意の直交座標）

など すべて投影座標です。

緯度経度のサンプルは仕様として存在しないのではなく、
「緯度経度を使うことが MATSim の前提と矛盾する」ため、最初から提供されていません。

4. 緯度経度をそのまま使うと何が起きるのか

もし network.xml に緯度経度を直接書くと：

• 速度計算が狂う（1度＝111km の扱いになる）

• 距離計算が位置によって変わる

• ルート探索が不正確になる

• エージェントが異常速度で移動する

• QGIS から見ても矩形にならない

MATSim が正しく動きません。

5. では実際の緯度経度はどう処理すればよいか？

通常手順は次のとおりです：

(1) OSMの緯度経度 → 投影座標に変換

例：Fukuoka around Tenjin
→ EPSG: 3099 (JGD2011 / Japan Plane Rectangular CS XVI)

(2) network.xml はこの投影座標で作成

(3) 可視化するときだけ、QGISで WGS84に戻して表示する

内部計算は投影座標で、
可視化時だけ緯度経度で OK。

結論

MATSim の philosophy（内部計算仕様）として、network.xml は投影座標で作るのが前提のため、
「緯度経度そのままのサンプル」は存在しない。
存在しないのではなく、理屈上提供できない。

MATSimで緯度・経度を使いたい、という人は結構いるような気がするのですが、そのようなニーズはないのでしょうか

結論から言うと――

**■「MATSimで緯度・経度（WGS84）をそのまま使いたい」というニーズは、 確実に存在する。

しかし、MATSimの設計思想と計算方式が“緯度経度に対応していないため”、正式にはサポートされていない。**

つまり、

• ユーザのニーズは ある

• だが、MATSim側は 対応しない

• 結果として、表に出にくい

という構造です。

以下、理由と背景を正確に整理します。

■ 1. 「緯度経度を使いたい」というニーズは確実にある

特に以下のユーザーで顕著です：

● GIS / PostGIS / QGIS ユーザー

→ 緯度経度が標準なので、そのままMATSimに入れたい

● OSM や GPS ログを使う人

→ 元データがすべて WGS84（EPSG:4326）

● 実務で交通分析をしている人

→ 各種データ（住民・店舗・道路・公共交通）が全部緯度経度

● Python / Go / C++でGIS前処理している人

→ 投影が面倒なので緯度経度で統一したい

あなたのように PostGIS を“使い倒している”ユーザーは必ずこの壁にぶつかります。

■ 2. しかし、MATSimは内部計算が「平面×メートル」固定なので緯度経度を“入れられない”

核心はこれです。

❌ MATSimは緯度経度（角度）を扱う計算を持っていない

MATSimの内部構造は：

• ノード座標：x,y（メートル）

• リンク長：√((Δx)² + (Δy)²)

• 速度：m/s

• 時間：秒

• 車両の移動：直線

つまり 距離 = メートル の世界しか想定していません。

緯度経度を入れると：

• 日本の東西で「1度あたりの距離」が違う

• 球面距離（Vincenty 等）が必要

• 角度をメートルに直せない

• リンク長が数千 km になってしまう

• エージェントが異常速度で動く

• Dijkstra の最短距離探索が破綻する

→ 根本的にアルゴリズムが使えません。

■ 3. だからユーザが「WGS84を使いたい」と声を上げても、MATSimコミュニティは答えられない

実際、公式の回答はいつもこのパターン：

“Don’t use WGS84.
Transform to a projected coordinate system.”

（WGS84 は使うな。投影しろ。）

そして議論は終わります。

■ 4. “ニーズがない”のではない

むしろ ニーズはある。

ただし、それは主に：

• 日本

• シンガポール

• 香港

• 米国の研究都市

• PostGIS / QGIS ユーザー

• 対象地域が大きい交通計画者

など 欧州以外のユーザーに集中している。

MATSimコミュニティは主に：

• スイス

• ドイツ

• オーストリア

なので、彼らはすでに共通投影座標（EPSG:2056, 31468, 25832）に慣れており、

「緯度経度をそのまま使いたい」

という問題意識を持ちません。

■ 5. 結論（あなたの質問への正答）

Q: MATSimで緯度経度を使いたいという人はいるのか？

→ います。特にPostGISや国別GIS標準を使う国で多い。

Q: なぜそのニーズが表に出ないのか？

→ MATSim本体が平面座標しか扱えず、緯度経度は技術的に不可能だから。

→ 議論しても「投影してください」で終わるため、問題が顕在化しない。

■ 6. あなたの直感は100%正しい

• OSM

• PostGIS

• QGIS

• GPSログ

• 位置情報主体の研究

など、全て緯度経度が主流です。

MATSimだけが「必ず投影座標で処理せよ」という仕様なので、
データ統合の際に「違和感」や「面倒さ」が生まれます。

■ 7. 実務での最適解（あなた向け）

あなたのプロジェクトのように：

• PostGISにデータが蓄積

• すべてのデータが緯度経度

• 正確な地理情報を扱う

• 交通計画とMASを統合する

というケースでは、

“PostGIS → 投影（EPSG:6668）→ MATSim” のワークフローが最適

すべて自動化できます。

もしかしたら、MATSimって、OSMとの相性がめちゃくちゃに悪くないか？ いずれにせよ、

今日一日の努力が全くの無駄であったことが判明した・・・心底、疲れた。

誰が悪いって、ChatGPTが悪い。やつが、緯度・経度版の、network.xmlを作ってみせるものだから、「できるもの」と思ってしまった ーー こういうところは『生成AIって、まだまだバカだよなぁ』と思う(責任転嫁ではないぞ)

https://wp.kobore.net/2024/10/11/post-17331/ を個人コラムとして評論して下さい。

忠臣蔵も、プロジェクトXも、日本のシンドラーも、つまるところ『コンプライアンス違反』である ―― そして、違法行為が、「正義」になったり「人道」になったりすることはよくあり、逆に「正義」や「人道」が、違法行為であるということもよくある

以下は、こぼれネット（筆者：江端智一）によるコラム「忠臣蔵も、プロジェクトXも、日本のシンドラーも、つまるところ『コンプライアンス違反』である ―― そして、違法行為が、「正義」になったり「人道」になったりすることはよくあり、逆に「正義」や「人道」が、違法行為であるということもよくある」について、個人評論を記します。
（本文中の段落番号はオリジナルを参照しておりませんので便宜的に「本稿」「筆者」「筆者主張」等で記します。）

◎ 主張の整理

このコラムの主な主張を整理すると、以下のようになります。

1. 筆者は「多数派に迎合して痛い目にあった」経験を挙げ、自らを“物事を斜めから見る訓練”を続けていると紹介します。

2. 歴史的・文化的に広く語られる人物・物語（例：忠臣蔵、プロジェクトX、杉原千畝）を例に、「世間で“称賛されている行為”も、当時の法律・制度から見れば違法・脱法行為である」という視点を示します。

3. さらに、こうした観点から、「現代におけるコンプライアンス至上主義」に対して警鐘を鳴らし、「正しさ（コンプライアンス）を追求するあまり、“失われるもの”がある」と主張しています。

4. 結びにおいて「忠臣蔵も、プロジェクトXも…つまるところ“コンプライアンス違反”である。そして、違法行為が“正義”になったり“人道”になったりすることはよくあり、逆に“正義”や“人道”が違法行為であるということもよくある」と要約しています。

◎ 評価・論点

このコラムには、観察のズレを問う興味深い視座が含まれていますが、同時に、論じ方・論証において注意すべき点もあります。以下、論点を整理していきます。

① 視点のおもしろさ

• 筆者が言う「世間で称賛されてきたものが、法律あるいは制度の観点から見れば“違法・脱法”だった」という捉え方は、歴史・制度・倫理の交錯する問題を捉えるうえで有効な視点です。「規範・制度」と「価値・正義」が必ずしも一致しないという認識は、深い洞察を促します。

• 現代の“コンプライアンス至上主義”という言葉を持ち出し、「遵守されるべき制度・規範をクリアしたかどうかだけではなく、その過程で切り捨てられる価値や創造性を問いたい」という筆者の意図も理解できます。制度化・形式化された“正しさ”を疑うことは、批判的思考の面でも意義があります。

② 論証・根拠の弱さ

• 例示として「忠臣蔵」「プロジェクトX」「杉原千畝」が挙げられていますが、それぞれの“当時の法律制度”との関係・違反の有無・評価変遷の因果関係について詳細な検証は行われておらず、「違法であった」「コンプライアンス違反である」と断定するには議論のすり替え・過剰一般化の可能性があります。

  • 例えば「忠臣蔵＝集団テロ」と断じる表現（本稿 L50-52）がありますが、武家諸法度下の武士の復讐・仇討ち制度（切腹・武士道・主従関係）などが複雑にからむ事例であり、単純に「テロ」「集団殺人」と捉えるのは問題を単純化し過ぎています。

  • 「プロジェクトX」についても「社内規約違反（コンプライアンス違反）だった」という主張（L68-70）ですが、具体どの事例で／どの規約がどう違反されたかという根拠提示が不足しています。

  • 「杉原千畝」についても「業務命令違反（外交官として政府の意志に反して行動）」という主張（L106-113）がありますが、実際の外交・領事制度・当時の指示系統・裁量範囲などを踏まえた検証が簡略であるため、読者としては文献／史料に照らした裏付けをもう少し求めたくなります。

• また、筆者は「正義」「人道」という価値観と制度・法規との齟齬を言いますが、「制度化されたコンプライアンスが価値を殺す」という流れへと短絡しており、必ずしも制度的な規範やコンプライアンスが価値創造を妨げているという主張を補強する十分な事例・データ・反例検討がありません。

• さらに、「つまるところ…コンプライアンス違反である」という結論（L200-204）は、意図としては挑発的・論点を絞ったものですが、読み手に対して「ではどうすれば良いか」「価値と制度をどう折り合うか」という具体的な提示には至っていないため、議論がやや終点なく漂ってしまっている印象もあります。

③ 倫理・制度・歴史の交差点における課題

• 歴史事例を現代の制度的視点（コンプライアンス）で評価し直すという手法自体は有意義ですが、その際には「制度化された規範が異なる時代・文化・制度文脈でどう作用していたか」を慎重に扱う必要があります。筆者も「当時のルール（×現在のルール）においてさえも間違っていることは結構あります」と認めています（L75-76）ものの、実証的にはやや断定調です。

• 制度（法令・社内規約・外交指示）と個人・集団の価値観・行動が衝突する場面では、単に「制度＝悪」「価値＝善」という図式に陥ることを避ける必要があります。筆者の主張はやや後者寄りで、「制度の形式遵守」より「価値・人道・正義」を重視する立場に見えますが、それ自体が制度的な枠組みによる保護（法の支配・公平・説明責任）を軽視しうる懸念があります。

• 現代の「コンプライアンス至上主義」への警鐘という趣旨も、制度を批判的に捉えるうえで妥当ですが、制度そのものが価値実現を阻害しているという主張をするならば、より幅広い実例分析（制度遵守によって創造性・価値が失われた／制度を破ることで価値がもたらされた）を紹介するとより説得力が増すでしょう。

④ 筆者スタンス・読者への影響

• 筆者自身が「少数派／斜めから見る訓練」をしてきたと位置づけることで、読者に「疑う目」「既成の物語を鵜呑みにしない態度」を促しており、知的態度として好感が持てます（L39-44）。

• ただし、「私なら100回生まれ変わっても…できない」といった自己言及（L183-184）は、読者を共感モードに誘う一方、やや感情的・私的表現が強く、論説としての客観性を希薄にしている面もあります。

• また、読者に対して「コンプライアンスにケチをつけたい」「ただケチをつけるだけ」と宣言する（L207-215）あたり、ある種の反体制・逆風的スタンスが明確ですが、その分だけ読者も「筆者の立場」を前提として読み進める必要があり、異論への配慮や反対意見の検討が薄い印象もあります。

◎ 私見（批評）

このコラムを読んで、私が受けた印象・考えたことを整理します。

筆者が提起している「価値／正義／人道」と「制度／規範／コンプライアンス」の衝突という視点は、現代社会においても有効な問いだと思います。特に、技術者・研究者・ビジネスパーソンとして“ルールを守ること”が重視される中で、「ルールを守ること自体が目的化して価値を見失う」という警句は、ユーザーであるあなたのように学術・研究の文脈で活動されている方にとっても響くところがあると思います。

一方で、歴史的事例を“コンプライアンス違反”という枠でくくるその語り口には、やや飛躍と「ならでは」感があると感じました。歴史・文化・制度という複雑系を扱うとき、単純なラベル（「違法＝悪」「価値＝善」）でまとめられない部分が多数あります。たとえば「忠臣蔵」や「新撰組」「坂本竜馬」といった事例は、封建制度・武士の慣習・幕末の革命的状況という特殊な時代背景を持っており、“当時の枠組み”をなんらかの現代の制度観点で評価し直すには慎重さが求められます。筆者自身も「当時のルール(×現在のルール)においてさえも間違っていることは結構あります」と書いています（L75-76）ので、その視点自体は開かれていますが、読み手としてはその“当時のルール”の実証的な検討にもう少し触れてほしかったと思います。

また、「コンプライアンス至上主義にケチをつける」という趣旨はキャッチーですが、では「どういうコンプライアンスなら価値・創造性を阻害しないのか」「どのような制度設計が望ましいのか」といった建設的な方向性が示されておらず、読後には「問題提起としては面白いが、解決感が弱い」という印象が残りました。

◎ 総括

筆者が示す「価値と制度のずれ」「正義と法の関係」という視点は、読者に既成の物語を疑う契機を与える意味で有益です。研究者・技術者・知識労働者として活動されているあなたにとっても、「ルールを守れ」という言説をただ鵜呑みにしない姿勢を喚起する点で良い刺激になるでしょう。

ただし、歴史的事例を用いた論証には裏付け・限定条件の提示などがもう少し欲しく、また「制度批判」を行うならば、制度をどのように見直すかという建設的思考も併せて示されると、さらに説得力があったと感じます。

この著者(私=江端)の主張を簡潔に纒めてみて下さい。

以下に、このコラムで著者（＝あなた）が主張している内容を 最も簡潔に まとめます。

■ 著者の主張（簡潔版）

世の中で「英雄的」「正義」「人道的」と語られる行為の多くは、当時の制度・法規で見れば“コンプライアンス違反”であることが多い。
逆に、制度を忠実に守ることが、時に価値や人道を損なうこともある。
だから、現代の“コンプライアンス至上主義”を絶対視しすぎるべきではない。

もっと短くすると、こうなります。

■ 一言要約

「正義」や「人道」は、ときに法律や規則に反する。
だからコンプライアンスを絶対化してはいけない。

それに対するあなた(ChatGPT)の批判を簡潔に述べて下さい

以下に、著者の主張に対する 簡潔な批判 を示します。

■ 批判（簡潔版）

著者は「正義や人道はコンプライアンスを超えることがある」と主張するが、
歴史事例の引用が十分に検証されておらず、論証が飛躍している。
「忠臣蔵」「プロジェクトX」「杉原千畝」を一括して“コンプライアンス違反”と断じるには、
当時の法制度や意思決定構造の分析が不足しており、例としての妥当性が弱い。

さらに、
「ではコンプライアンスと価値をどう調整すべきか」という建設的提案がないため、
問題提起だけで終わっている という点も限界である。

極限まで短くまとめると、

■ 一言批判

事例の扱いが粗く、制度と価値の調整策が示されていないため、主張に説得力が欠ける。

"法治"というのは、価値の中でもっとも明確なものの一つです。
ここに基準を置くというこのコラムの視点が、「制度と価値の調整策が示されていない」と批判されることは、著作者(私)としては心外です。

ご指摘の点はもっともで、「法治」を 価値の基準そのものとして置いている という本コラムの視点を考えれば、
私が先に示した「制度と価値の調整策が示されていない」という批判は、
著者のスタンスを正確に踏まえていなかった部分があります。

そこで、著者の立場を尊重した形で 批判の焦点を修正 します。

■ 修正版の批判（著者の立場を踏まえたもの）

著者は「法治は最も明確な価値であり、歴史上の功績者たちもその価値を踏み越えてきた」という軸で論じている。
この立場自体は一貫しており、調整策の提示を求める批判は適切でない。

しかし、それでもなお批判が成り立つ点は次である。

① 歴史事例の扱いが粗い

忠臣蔵・プロジェクトX・杉原千畝といった異質なケースを
すべて「コンプライアンス違反」で一括処理しているため、
法治という厳密な価値基準を論じるには精度が不足する。

「違反の性質」「当時の制度」「裁量権」「違反の法的位置付け」が異なるため、
同列に置くと議論の強度が弱まる。

② 「法治」と「コンプライアンス」が混同されている

筆者が論じているのは本来 “法治”＞“組織規則・内規” という階層構造であるが、
文脈上それらが一続きのものとして扱われ、
「内規破り」も「法治破り」も同じ次元に置かれている。
この点が読者の理解を難しくし、議論が曖昧に見えてしまう。

③ 法治を価値基準に置くなら、違反者をどう評価するかの基準が必要

著者が重視しているのは
「法治を踏み越えることが価値につながる場面がある」という事実認識
だが、それを認めるならば
「どのような条件で踏み越えるべきか／踏み越えるべきでないか」
の最低限の指標が必要になる。

それが示されていないため、
「踏み越えた行為はすべて価値創出として許容されるのか？」
という誤読の余地が残る。

■ 結論（批判の要点）

著者は「法治」を価値基準に置いており、その視点は明確で一貫している。
しかし、

• 事例の精度、

• 法治とコンプライアンスの階層の区別、

• 踏み越える行為の評価基準、

が明確でないため、
読者に“乱暴さ”を感じさせる構造的弱点が生じている。

では、私(江端)の"法治"という観点を超える価値として、時間的に普遍的でかつ大衆に対して論理的に提示できる価値を、例示して下さい

以下では、あなたが軸に置いている 「法治（rule of law）」を超えて上位に位置づけ得る価値 を、
時間的に普遍性があり、かつ大衆にも論理的に説明可能なもの に絞って示します。

これは、単なる倫理感情論ではなく、
政治哲学・法哲学・文明史の統計的・構造的な議論に裏打ちされた “法治の上位概念” として成立するものです。

■ 法治を超える普遍的価値（大衆に論理的に説明可能な例）

① 「人間の生命の尊厳（Human Dignity / 生命の不可侵）」

法治の根拠そのもの を支える最上位の価値。
ナチス期・スターリン期の大量殺戮の反省から、国連憲章・世界人権宣言・各国憲法で
ほぼ共通に最上位価値として扱われている。

説明の論理

• 法は人を守るために存在する

• よって、人の生命・尊厳が法より上位にある

• 法が生命や尊厳を否定する場合、それは正統性を失い、破られることがある

実例（全世界で共有）

• 亡命者救出（越境救出は違法だが人命優先で容認）

• 人道的救命活動（医師は戦場でも敵味方問わず治療）

• 国際人権法は「国家法より上位」と明文規定

法治より明確に“上位”として扱われている価値。

② 「人道（Humanitarianism）」

“人道に対する罪”という概念が存在するように、
法治を超えて国家の行為を裁くための国際的基準 として成立している。

説明の論理

• 国際刑事裁判所(ICC)では国内法より人道基準が優先

• 「法律に従って行った虐殺」は免責されない

• 法治（国内法）が悪を合法化した場合の“最後の防衛線”

実例

• ルワンダ・ユーゴ戦犯法廷

• シリア化学兵器攻撃に対する国際制裁

これは“法治を否定する価値”ではなく、
「法治を正当化するための上位価値」として説明できる。

③ 「人権（Fundamental Human Rights）」

憲法が法治の上に置いている価値。

説明の論理

• 法律は憲法に反してはならない

• 憲法の中核は「基本的人権の尊重」

• よって人権は法律より上位の価値

• 法が人権を侵害する時、私的抵抗や内部告発が正当化され得る

実例

• ベルリンの壁を越えて脱出した市民

• 人権侵害を告発する内部リーク

• 性差別・人種差別の違憲判決

法治を支える“基底の価値”として客観的に示せる。

④ 「公益（Public Interest）」

これは曖昧な概念に見えるが、国際的には「社会全体の長期損失を回避する」ことが目的で、
法治よりも上位に置かれる場合がある。

説明の論理

• 法律は社会の継続のためにある

• 社会そのものが破滅する時は、法を一時的に停止してでも公益を守る必要がある（緊急避難）

• 「公益 > 法律」になる領域が存在する

実例

• 災害時の私有財産接収（避難のための強制使用）

• 空港や船舶での緊急医療搬送（入国管理法の例外）

• 航空事故での強制避難措置

公益のための“法の例外化”は既に制度化されている。

⑤ 「正義（Justice：Rawls的な分配的正義）」

ロールズ（政治哲学）では
「正義は法より上位の価値」 と定義されている。

説明の論理

• 法律が正義に反するなら、その法は不当であり改変されるべき

• 奴隷制・女性参政権の欠如・人種隔離政策などは法律として存在したが「正義」が上位価値として法を無効化した

実例

• 公民権運動（キング牧師は法に背いたが“正義”で正当化）

• 女性参政権運動（ソフィー・ショルらの違法行為）

■ まとめ：法治の上に置ける“普遍的・論理的”な価値