<?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="..." />

私、以前は、日本語の楽曲の中に、英語が入ってくるのが好きではありませんでした。
I used to dislike it when English appeared in Japanese songs.

最近は、気にならなくなりました。
Recently, it no longer bothers me.

楽曲の中に入っているのは「英語」ではないからです。
That is because what appears in the songs is not “English.”

あれは「英語」のように聞こえる「日本語」です ―― 正確には、"Japanese-English"です。
It is “Japanese” that sounds like English — more precisely, “Japanese-English.”

(この辺については、このコラムで論じています)。
(I discuss this point in more detail here: https://eetimes.itmedia.co.jp/ee/articles/1311/26/news011_4.html)

あれは、音楽で言うところの「転調」のようなものであり、ときどき差し込まれる「第2日本語」として受け入れれば、それなりに味わい深いものになります。
It is like a “key change” in music, and if you accept it as a kind of intermittently inserted “second Japanese,” it becomes quite rich and engaging.

その証拠に、楽曲の中に入ってくる「第2日本語」には、私たちの多くに理解可能な、簡易なフレーズが使用されています。
As evidence of this, the “second Japanese” that appears in songs uses simple phrases that many of us can understand.

―― と、竹内まりやさんの『人生の扉 [Live Version / 2014]』を、コメント欄を読みながら、聞いています。
— as I listen to Mariya Takeuchi’s “Inochi no Tobira [Live Version / 2014]” while reading the comments section.

-----

まあ、殆どの場合、英語の部分にはサブタイトルも表示されますので、それを読むこともできます。
Well, in most cases, subtitles are displayed for the English parts so that you can read them as well.

で、試しに、英語の部分を「第1日本語」に翻訳して楽曲に当ててみると、『曲の外枠（イメージ）が壊れる』感じがします。
And if you try translating the English parts into “first Japanese” and fitting them into the song, you get the feeling that “the outer frame (the image) of the song breaks down.”

つまり、英語のように聞こえる『第2日本語』は、最初から『第2日本語』を使うことを前提として、楽曲が設計され、演奏されていると考えるのが正しいと思います。
In other words, it is only natural to think that what sounds like English as “second Japanese” is designed and performed from the outset on the premise that “second Japanese” will be used.

楽曲に挟まれるフレーズに対して、「発音がメチャクチャだ」とか、「文法が不自然だ」という人は、あれを"英語"だと思っているからです。
People who say things like “the pronunciation is a mess” or “the grammar is unnatural” about those phrases think of them as “English.”

違います。
That’s not the case.

あれは「第2日本語」です。
That is “second Japanese.”

不自然に感じる人は、「第2日本語」に慣れていないだけです。あれを"英語"だと思うから、アカンのです。
If it feels unnatural, it is simply because they are not used to “second Japanese.” Thinking of it as “English” is what makes it wrong.

-----

私、ここ3年間くらい、部屋の半分が国際留学生からなる大学のゼミに所属していましたが、"英語"をしゃべっているという意識は、ほとんどありませんでした。
For the past three years, I have been in a university seminar where about half the class was international students, but I was hardly aware of speaking “English.”

私が使ってきたのは、「第2日本語」です。
What I was using was “second Japanese.”

そして、留学生のみんなも、「第2中国語」「第2マレーシア語」「第2ベトナム語」「第2インドネシア語」「第2タイ語」「第2韓国語」という風に、それぞれの国で使われている"母国語"をベースにしゃべっています。
And all international students, in the same way, talk in their own native languages — “second Chinese,” “second Malaysian,” “second Vietnamese,” “second Indonesian,” “second Thai,” or “second Korean.”

で、この"第2"は、なかなか"美味しい"ですよ。なんたって、文法や発音でマウンティングを取ってくる人を、黙らせることができるからです。
And this “second” is actually quite convenient, because it can shut up people who try to assert superiority based on grammar or pronunciation.

「実際に会話が成立している」という現実で、逆にそういう人に対して、マウンティングを取りにいけます。
In other words, with the reality that “the conversation is actually working,” you can apply a kind of “reverse mount” to those people.

こうなってくると、もう英語が「できる」とか「できない」とかいう次元の話ではなくなります。

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に頼んでみました。

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

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

私は政治に関しては素人です ―― というつもりはありません。
I am not claiming to be a novice in politics.

社内における力関係を計って仕事をすることは「政治」ですし、町内会のもの分かりの悪いジジイを諫めるのも「政治」です。
Measuring power relations within a company to get work done is “politics,” and so is admonishing a stubborn old man in a neighborhood association.

極端なことを言えば、「いじめ」ですら、集団力学における政治と言っても過言ではないと思っているくらいです。
To take it to an extreme, I even think it is not an exaggeration to call bullying itself a form of politics within group dynamics.

もちろん、「政治」は「正義」ではなく、大抵の場合、無茶なロジックを通すという点においては、「悪」とか「インモラル」に近い観念として具体化します。
Of course, “politics” is not “justice,” and in most cases it takes concrete form as something closer to “evil” or “immoral,” in that it forces unreasonable logic through.

当然ですが、「政治家」というのは、その政治のプロフェッショナルですので、無茶なロジックを通すことにかけては、実に上手いのです。
Naturally, “politicians” are professionals of politics, so they are extremely skilled at forcing unreasonable logic through.

-----

高市総理大臣の発言に対して、中国政府が激怒（か、あるいは激怒に見せる演出、または、それに付随する政策による攻撃）をしているという話をしました。
I talked about how, in response to remarks by Prime Minister Takaichi, the Chinese government has become enraged (or staged a display of rage, or launched policy attacks in support of that stance).

（で、以前、私は、この我が国の総理の「理非」については判断できない、とも言いました）。
(And earlier, I also said that I could not judge the right or wrong of our country’s prime minister on this matter.)

この事件、中国政府は内外に「激怒」を示し続けなければならないし、我が国の政府は「発言撤回はしない」というスタンスを維持しなければなりません。
In this incident, the Chinese government must continue to display “rage” both domestically and internationally, while our country must maintain the stance that “the remark cannot be retracted.”

いわゆる、現在「スタック」または「デッドロック」している状態です。
In other words, the situation is currently “stuck,” or in a “deadlock.”

ちなみに、私たちのようなプログラマにとっては、プログラムにおける「デッドロック」というのは日常的に発生し、かつ、それを解決する方法が恐ろしく難しいものです。
For programmers like us, a “deadlock” in a program is something that occurs on a daily basis, and the methods for resolving it are terrifyingly difficult.

政治の世界における「デッドロック」は、それとは比較にならないほど難しいでしょう。
A “deadlock” in the world of politics is likely incomparably more difficult than that.

-----

現時点で、以下がファクトとして真実かどうかは分かりませんが、
At this point, I do not know whether the following is factually true or not,

―― トランプ大統領が、高市首相に対して、「台湾問題については『言い方』に留意せよ」というアドバイスをした
"There is a report that President Trump advised Prime Minister Takaichi to “be careful about the wording” regarding the Taiwan issue."

という話がニュースソースとして流れています。
And this story is circulating as news.

私、この話を聞いた瞬間、
The moment I heard this story,

「上手い！ 座布団一枚！！」
“Brilliant! One cushion for you!!”

と叫んでしまいました。
I couldn’t help but shout that out.

-----

トランプ大統領なんて、ドラえもんの中のジャイアンみたいな立ち位置じゃないですか（というか、ジャイアンそのもの）。
President Trump is like Gian from Doraemon in terms of his position (or rather, he is Gian through and through).

ジャイアンが、スネオに対して「『言い方』に気をつけろよ」というアドバイスをしたようなものですよ。
It’s like Gian advising Suneo to “be careful about how you say things.”

「それ、お前のキャラじゃねぇーよ」と思いませんか？
Doesn’t that make you think, “That’s not his character”?

ただ、これは政治的に上手い。本当に上手い。
Still, this is politically clever—really clever.

米国の属国……ではなくて、同盟国である日本の首相である高市首相が、米国大統領から注意を受けた、ということは、
The fact that Prime Minister Takaichi of Japan—an ally of the United States, not a vassal state—was cautioned by the U.S. president means that

―― 子分の不始末を、親分が叱責した
— the boss reprimanded the subordinate for a blunder,

という形で、世界に流布するという構図になっているわけですよ。
And that structure is what gets disseminated to the world.

これは、デッドロックを解除するに至らなくても、デッドロックを「緩める」という効果としては、抜群です。
Even if it does not go so far as to解除 the deadlock, it is outstanding in its effect of “loosening” the deadlock.

デッドロックが緩まれば、あとは時間解決モードに持ち込める可能性もあります。
Once the deadlock is loosened, there is also the possibility of shifting into a time-based resolution mode.

-----

それにしても、
Even so,

―― この図面を描いたのは、誰だろう？
— Who drew this blueprint?

と考えています。
I found myself wondering that.

まず、米国政府ではないと思う。あそこはデッドロックを、軍事力と関税で強制解除する手段(ハードアプローチ)を持っているからです。
First of all, I don’t think it was the U.S. government, because they have the means to forcibly break a deadlock through military force and tariffs (a hard approach).

と考えると、中国政府の可能性もあるけど、一番可能性が高いのは日本政府ではないか ? と、私は思っているんですけどね。
Thinking that way, the Chinese government is also a possibility, but I personally think the most likely candidate is the Japanese government.

あるいは、この3つの国が同時にこの絵図を描いた、という可能性もある、とも思っています。
Or perhaps all three countries drew this picture simultaneously—that is another possibility I consider.

政治家ではなくて、政府官僚が上手くコントロールした、という可能性も高いと思います。
I also think there is a strong possibility that it was skillfully controlled not by politicians, but by government bureaucrats.

-----

まあ、ここまで偉そうに「図面を描いたのは誰か」などと論じておいた挙句、明日、このニュースがフェイクだったと分かれば、私は恥をかくのだろうけど、それもまた政治というものだと思っています。
Well, after going on so grandly about “who drew the blueprint,” if it turns out tomorrow that this news was fake, I’ll probably be embarrassed, but I think that, too, is part of politics.

だって政治の世界では、「事実」より先に「もっともらしい話」が走り、その後から慌てて現実が追いかけて来る、ということが日常茶飯事ですから。
After all, in the world of politics, it is commonplace for “plausible stories” to run ahead of the “facts,” with reality scrambling to catch up afterward.

フェイクかどうかは、明日以降の新聞かテレビで分かるでしょう。
Whether it is fake or not will likely be known in the coming days through newspapers or television.

ただ一つ確かなのは、
The one thing that is certain is this:

―― デッドロックを解いたのが誰であれ、解けた瞬間には、たぶん誰も「俺がやった」とは名乗らない、
— whoever actually untied the deadlock, at the moment it is resolved, probably no one will step forward and say, “I did it.”

ということくらいですね。
That is about it.

真相は、10年後くらいの「NHKスペシャル」を待つしかないのかもしれません(私は、まだ生きているかな)。
As for the truth, we may have no choice but to wait for an “NHK Special” about ten years from now (if I’m still alive then).

だからこそ、今回ばかりは、私も胸を張ってこう言えます。「分からんものは、分からん」――と。

故小松左京先生の「日本沈没」が成立しない理由は、
The reason why the late Sakyo Komatsu’s “Japan Sinks” cannot be realized in reality is

―― 日本列島の質量が軽過ぎるから
— because the Japanese archipelago is far too light.

と、私は解釈しています。
That is how I interpret it.

日本列島は（というか全世界の国土は）めちゃくちゃに軽くて、年間数センチから十数センチ動きつづけるプレート（太平洋プレートとかフィリピン海プレート）の上に浮んでいる「発泡スチロール板」のようなものです。
The Japanese archipelago—actually all landmasses on Earth—are extremely light and float on tectonic plates such as the Pacific Plate or the Philippine Sea Plate, which move several to more than ten centimeters per year, much like a sheet of Styrofoam floating on water.

プールの水面に巨大な発泡スチロールが浮いているとします。
Imagine a huge sheet of Styrofoam floating on the surface of a swimming pool.

これを水中に沈めるなんて、簡単にできると思いますか？
Do you think you could push it underwater easily?

それ故に、私は、小松左京先生の『日本列島全部が水面下に沈む「日本沈没」』はSFであり、現実には起こり得ないと考えているわけです。
That is why I consider Komatsu’s “the entire Japanese archipelago sinks below sea level” scenario to be pure science fiction and impossible in reality.

あ、もちろん部分的には沈みますよ。で、沈んだ結果、もとに戻ろうとする力が発生するので、地震や津波が発生するのです。
Oh, parts of it do sink. And when they try to return to their original position, that rebound triggers earthquakes and tsunamis.

津波とは、簡単に言えば、沈めた巨大な発泡スチロールから「手を離した瞬間」に浮き上がってくる力で水面が押し上がる、あれです。
A tsunami is basically what happens when you push a huge piece of Styrofoam underwater and then let go—the upward force lifts the water surface.

-----

当然のことながら、故小松左京先生もこの程度の物理は承知していて、小説『日本沈没』では、全沈没を成立させるために以下の仮説を入れています。
Needless to say, Komatsu understood this level of physics, and in the novel, he added several hypotheses to make total submergence possible.

(1) 伊豆・小笠原から東海地域の下部地殻が破壊・崩落
(1) The lower crust from the Izu–Ogasawara area to Tokai collapses and breaks apart.

(2) 日本弧の基盤プレートが滑り落ちる
(2) The base plate of the Japanese arc slips downward.

(3) 地下深部での異常熱流による広域的溶融・弱層化
(3) Abnormal deep heat flow causes widespread melting and weakening.

(4) その結果、列島全体がプレート境界へ引き込まれる
(4) As a result, the entire archipelago is dragged into the plate boundary.

一言で言うなら、「発泡スチロールがバラバラに破砕・溶解して、プールの底に沈む」という、新しい前提を小説内に導入したわけです。
In short, he introduced a new premise in which the Styrofoam itself shatters, softens, and sinks.

で、ここから本題に無理なくつなげるために、一言だけ前置きしておきますが、
Before connecting this to the main topic, let me add a small preface:

―― 私は「浮力」とか「復元力」という言葉に妙に敏感なんですよ。
— I have an odd sensitivity to words like “buoyancy” and “restoring force.”

-----

さて本題。
Now, the main point.

私、タバコも酒もやっていましたが、タバコは20歳から1年後に止めましたし、酒は現在も断酒継続中です。
I used to smoke and drink, but I quit smoking a year after turning twenty, and I’m still abstaining from alcohol today.

大抵の仕事は納期を守りますし、自分でコントロールできるノルマなら基本的に達成します。
I usually meet deadlines, and if a task is under my control, I generally complete it.

世間的には、こういう状態を『鋼の意志』などと呼ぶらしいのですが、私はそんな殊勝な評価をいただくのが、正直イヤなんですよ。
People apparently call this sort of behavior “an iron will,” but frankly, I hate receiving such noble praise.

というのも、私は「人の顔色を伺いながら、ビクビクしながら、他人や自分との約束を守っているだけ」であって、信念も信条もポリシーも（全部同じ意味だが）ありません。1mmもないと断言できます。
Because in reality, I’m just keeping promises while anxiously watching others’ reactions; I have no conviction, creed, or policy (all of which mean the same thing). Not even a millimeter of it.

で、考えたのですよ。
So I thought about it.

私のこの情けない状態を、もっと的確に言い表せる比喩がないかと。
Isn’t there a better metaphor to describe this pitiful state of mine?

昨夜、ふと、小松左京先生の『日本沈没』が頭に浮かんだんです。
Then last night, Komatsu’s “Japan Sinks” suddenly came to mind.

他人の顔色に流され、ビクビクし、沈みそうで沈まない――そんな私を形容する言葉として、私はこれが最適解だと思いました。
When I considered how I am easily swayed by others’ moods, frightened, and almost sinking yet never fully submerged, I realized this is the perfect description:

―― プールに浮ぶ発泡スチロールのような意志
— A will like Styrofoam floating in a swimming pool.

世間という『重い』流体の上に、フラフラ流されながら、時々沈むものの、完全に沈めるのは案外難しい。それが発泡スチロールであり、そして私の“意志”そのものなのだ、と。
Drifting atop the heavy fluid called society, sometimes sinking, yet strangely hard to push completely under—that is Styrofoam, and that is my so-called “will.”

結局、今日ここまで長々と「日本沈没」の話をしたのも、この一言を言いたかった ―― それだけのことです。
In the end, the whole long discussion about “Japan Sinks” was just to say this one line — That’s all it was.

毎日100～200の地震が発生しているのですから、「大地震が起きませんように(もし起きるなら、私の関係のない場所でヨロシク)」と祈っても、多分、無駄でしょう。

社内の管理部門の書類、行政から送付されてくる書類、そして保険会社の保険商品の説明書は
The documents from internal management departments, the documents sent by government agencies, and the brochures for insurance products are

―― 意図的に内容が分からないように書いているんじゃないか
— almost written deliberately to make the content incomprehensible,

と思えるほどの、困難さです。
to the point where I genuinely feel that way.

というか、あれは"不親切"を超えて、"悪意"を感じるほどです。
Honestly, they go beyond “unfriendly” and verge on feeling “malicious.”

-----

私、新人のころから今に至るまで、『読み手が分からない資料を書くと、叱られる』という仕事をしてきたので、こういう資料を見ると、腹が立つのです。
Since my rookie days, I have worked in an environment where “you get scolded if you write documents the reader cannot understand,” so seeing documents like these really irritates me.

『テクニカルライティングが、常に正義』とは言いませんが、"背景"→"目的"→"狙い(依頼事項)"、と、短文で明解に書かないと、上司に叱られました。
I won’t say “technical writing is always justice,” but unless I clearly summarize “background → purpose → intent (requested action)” in short sentences, my boss would reprimand me.

もちろん、"正確"で"網羅性"を担保していることが、必要ではあるのですが、それは主文の後に回すとか、付録に回すとか、そういう工夫をしないと、叱られました。
Of course, ensuring “accuracy” and “completeness” was required, but we were told to move that content to the later sections or appendices; otherwise, we were scolded again.

-----

で、最近の私が何をやっているかというと、
So, what I have been doing recently is this:

―― 生成AI(ChatGPT)に書類を読ませて、その後に質問をする
— letting a generative AI (ChatGPT) read the document and then asking it questions afterward.

という形式を取っています。
That is the approach I use.

スキャナか写真でキャプチャして、そこからドローソフトを使って「ヤバい情報(個人情報とか組織名称)」を削除した後に、ChatGPTに投げてから、ChatGPTに質問をするわけです。
I scan or photograph the document, delete the “dangerous information” (personal data, organization names, etc.) using a drawing tool, send it to ChatGPT, and then ask ChatGPT questions.

『この書類は何を言っているのか、1フレーズで記載して』
“Tell me what this document is saying in one phrase.”

『で、私の場合は、どこにどう書けばいいの？』
“And what exactly should I write, and where?”

というような質問をすれば、不明なことはChatGPTが逆に尋ねてくるので、それに答えれば、大体作業が終わります。
If I ask questions like these, ChatGPT asks for clarification on unclear points, and by answering them, the task is mostly finished.

-----

無論、これは正確さにおいて怪しいです。実際に、これで痛い目にあったこともあります。
Of course, the accuracy is questionable, and in fact, I have gotten into trouble because of this.

(ChatGPTの言うとおりに書類を提出したら、自分の意図せぬ業務形態になっていて、上司のチェックで助かった、という事件など)
(For example, I submitted a document exactly as ChatGPT suggested, only to end up committed to a work arrangement I never intended—my supervisor’s review saved me.)

それでも、『分けが分からんまま、書類を書く』よりはストレスはないですし ーー とにかく早い。
Even so, it’s far less stressful than “writing documents without understanding them,” and—above all—much faster.

こういう風にChatGPTを使っている人は多いと思います。
I imagine many people use ChatGPT this way.

なるほど、これからは「恐しく分かりにくいけど、全部内容を突っ込んだ書類」を提出してくる管理部門または行政や保険会社は、
I see—in the future, management departments, government agencies, and insurance companies that submit “horrifyingly obscure but fully stuffed documents.”

―― エンドユーザが生成AIの使用を前提とする
— will assume that end users rely on generative AI,

として、これから平気で理由の分からない書類を作成できる時代になる、という流れですね。
and thus freely produce documents whose logic is unfathomable.

まあ、多くの人が助かるのであれば、それはそれで良いことだと思います。
Well, if this ends up helping many people, that’s not entirely bad.

-----

しかし、
However,

―― エンドユーザが、そういうこと(キャプチャ、画面修正、生成AIの投入等)をしなくてすむように、最初から簡潔かつ明瞭な資料を作れよ
— make the documents clear and concise from the beginning so that end users don’t have to do scanning, redaction, and AI processing!

とは思うんですよね。
That’s honestly how I feel.

テクニカルライティングを、現役中に、ずっとうるさく言われ続けた私としては、なんか釈然としないんですよ。
As someone who was constantly harassed about technical writing during my career, I can’t help but feel unsatisfied.

せめて、『分かりにくい資料を作った部署や本人』に対して、ペナルティが科せられる、というくらいの仕組みはないものか、と思います。
At the very least, I wish there were a system in which “the department or person who produced the incomprehensible document” is penalized.

ChatGPTが、
If ChatGPT were to output something like,

『あなたの貼付した書類と同じものと思われるものが、あなたの他にも1000人近い人が、私に説明を求めていました』
“Nearly 1,000 other people have asked me to explain what appears to be the same document you just uploaded.”

てコメントを出して貰って、そのコメントを、書類の送付元に連絡してやる、くらいの、クレームは付けてやりたいなぁ、と思います。
I would love to take that comment and send it straight back to the document’s issuer as a complaint.

-----

というか、「行政文書の可読性評価」をChatGPTにやらせてみるのはどうでしょうか。
Actually, how about letting ChatGPT evaluate the readability of government documents?

―― この書類、普通の人に可読可能な文章になっていると思う？
— “Do you think this document is written in a way that an ordinary person can read?”

とか
or

―― この書類の『読み易さ』に対して点数をつけて下さい。あとで発送元に知らせますので。
— “Please assign a readability score to this document. I will inform the sender later.”

とかを、ChatGPTに聞いて、そのChatGPTの点数を発送元に送りつけてやればいい。
Ask ChatGPT these questions and send the scores back to the sender.

-----

比較対象として、過去の税金関係の部署ごとに得点を付けて、『あんたんところ、他の部署より劣っているぜ』と明示的に教えてやれば効果抜群でしょう。うん、私のブログで公開してもいいな。
If I assigned scores to past tax-related departments and explicitly told them, “Your department is worse than the others,” it would be highly effective. I could even publish it on my blog.

企業(保険会社を含む)、政府機関等が、民間から"定量値(得点)"をつけて批判される"くらいの脅威を与えないと、「意図的に内容が分からないように書いているんじゃないか」と思われるような書類は、これから増えるばかりです。
Unless companies (including insurance firms) and government agencies feel the threat of being criticized by the public through “quantitative scores,” documents that seem “deliberately incomprehensible” will only continue to increase.