トランプ関税に引き続き、米国によるベネズエラ大統領の身柄拘束の件で、私は、かなりガックリきています。
Following the Trump tariffs, I am feeling quite disheartened by the case of the Venezuelan president being taken into custody by the United States.

無論、これについても正当理由はいくらでも挙げられます。
Of course, there are several justifications for this.

麻薬対策、人権侵害、政権犯罪、地域の安全保障――私自身、それらが全くの虚構だとは思っていません。
Drug control, human rights violations, regime crimes, and regional security — I myself do not think these claims are complete fabrications.

ただし、この件が、事前に国連安保理の決議を得た形で実施されたとは報じられていません。
However, it has not been reported that this action was carried out after obtaining a prior resolution from the UN Security Council.

そういう意味では、これまで繰り返されてきた米国の単独行動の延長線上にある出来事に見えます。
In that sense, it appears to fall within the pattern of unilateral actions repeatedly taken by the United States.

-----

思い出されるのは、2003年のイラク戦争です。
What comes to mind is the Iraq War of 2003.

当時、イラクには大量破壊兵器が存在するとされ、それを根拠に軍事行動が開始されましたが、結果として核兵器を含む大量破壊兵器の決定的証拠は見つかりませんでした。
At the time, Iraq was said to possess weapons of mass destruction, and military action was initiated on that basis. Yet, ultimately, no decisive evidence of such weapons, including nuclear arms, was found.

日本国政府が、そのイラク戦争に対して資金面を中心とする形で協力したという事実も、忘れてはならないと思います。
I also believe we must not forget the fact that the Japanese government cooperated in that Iraq War, primarily through financial support.

-----

ベネズエラ大統領の身柄拘束については、個人的な心情としては、正直なところ支持できる部分もあります。
Regarding the detention of the Venezuelan president, speaking purely from a personal emotional standpoint, there are honestly aspects I can support.

また、大国のエゴであれ何であれ、各国（主に大国）が介入するという選択肢が現実に取られていれば、カンボジアやルワンダといった大量虐殺を、止められた可能性があったのではないか、とも思うからです。
This is because I also think that, regardless of whether the ego of great powers drove it, if the option of intervention by countries (mainly major powers) had actually been taken, there might have been a chance to stop mass genocides such as those in Cambodia and Rwanda.

「主権」や「内政不干渉」を盾に、国際社会が事実上手をこまねいていた結果として、ああした惨事が起きた、という側面があることも否定できません。
It cannot be denied that such tragedies occurred in part because the international community, shielding itself behind “sovereignty” and “non-interference in internal affairs,” effectively stood by and did nothing.

-----

私が、これからの子どもたちに残す言葉があるとすれば、
If there is one message I would leave for the children of the future,

―― 国際法の勉強や研究だけは、やめておけ
— I would say: stop studying or researching international law alone.

と言いたくなります。
That is what I feel compelled to tell them.

非常に虚しい気分になるからです。
Because it leads to a highly hollow feeling.

国際法そのものを否定したいわけではありません。
I do not wish to deny international law itself.

ただ、国際法"だけ"を信じ切る設計は、あまりにも危うい。
However, a framework that places absolute faith in international law *alone* is far too precarious.

国際法を勉強する時間があるなら、軍事力の定量化や、戦争・紛争をどうすれば短時間かつ局地的に、最小被害で終わらせられるのか――そうした運用やシミュレーションの研究に時間を使った方が、この果てしない無力感を感じずに済むのではないかと思うのです。
If there is time to study international law, I think it would be better spent on research into quantifying military power, and on operations and simulations that examine how wars or conflicts can be concluded quickly, locally, and with minimal damage — thereby avoiding this endless sense of helplessness.

勉強してきたことが、現実の前でまったく役に立たず、
When what one has studied turns out to be utterly useless in the face of reality,

―― なんだ、バカみたいだな
— making one think, “What was the point of all this?”

と思うような学びは、できればさせたくありません。
I would prefer not to make anyone undergo such an education.

まあ、唯一の明るい面があるとすれば、国際法に比べれば、数学や英語の勉強は、実に有用だという事実を、身をもって実感できることでしょう(個人的には、地図を睨み続けて、政治や文化を考える「地政学」がお勧めですが)。
Well, if there is one bright side, it is that compared to international law, one can truly feel through experience how helpful the study of mathematics and English is (personally, I would also recommend geopolitics — staring at maps and thinking about politics and culture).

少なくとも、それらは、世界を動かす側の言語と道具ではあると、私は思うのです。
At the very least, I believe they are languages and tools used by those who actually move the world.

正直言って、『何のために、あんなに苦労して国際条約の条文の暗記をしてきたのか』と腹が立ちます。私の怒りはどこに持っていけば良いでしょうか？ ーー とChatGPTに愚痴ってみた件

『仕事を続けている人は、認知症になりにくい』――
“People who continue working are less likely to develop dementia.”

という風に私には見えていたのですが、どうやらこれは幻想のようです。
That is how it appeared to me, but it seems to be an illusion.

これは因果関係が逆で、「認知症になっていない人が、仕事を続けられている」という状態が、そのような幻想を見せているようです。
The causality appears to be reversed: it is not that working prevents dementia, but rather that people who have not developed dementia can continue working, which creates this illusion.

仕事を続けることは、認知症の「発病リスクを下げる可能性」はありますが、「確実に防ぐ」ことはできないそうです。
Continuing to work may reduce the risk of developing dementia, but it cannot prevent it with certainty.

ただし、科学的には「仕事を続けることには、一定の抑制効果がある」とは考えられているようです。
However, scientifically, it is believed that continuing to work does have a specific suppressive effect.

―― と、ChatGPTに教えてもらったのですが、
This is what ChatGPT told me, but

『結局どっちなんだ？』と聞きたくなるような答えです。で、『はっきりしろ』と言ってみました。
It is the kind of answer that makes you want to ask, “So which is it, in the end?” So I told them, “Be clear.”

---

### ChatGPTの回答ここから

### ChatGPT’s response begins here

結論からはっきり言います。
I will state the conclusion clearly from the outset.

「仕事を続けると認知症を防げるのか？」という問いに対する科学的な答えは、『防げないが、発症を遅らせる・確率を下げる方向には働く』です。
The scientific answer to the question “Does continuing to work prevent dementia?” is: “It does not prevent it, but it does work in the direction of delaying onset and reducing probability.”

これ以上でも以下でもありません。
Nothing more, nothing less.

なぜ「どっちつかず」に聞こえるのかは、問いが二つのレベルを混同しているからです。
The reason this sounds ambiguous is that the question conflates two different levels.

① 因果関係は逆か？

1. Is the causal relationship reversed?

→ 部分的にYES
→ Partially, yes.

認知症になっていない人が、結果として仕事を続けられている。
People who have not developed dementia can continue working.

これは事実です。特に「高齢までフルタイムで働いている人」は、もともと認知機能・健康・社会的資源が高い人が多い。
This is a fact. Especially among those who work full-time into old age, many already have higher cognitive function, better health, and greater social resources.

このため、
For this reason,

「働いている → 認知症にならない」
“working → not developing dementia.”

に見える現象の一部は、
Some of what appears to be this relationship is actually

「認知症にならない人 → 働ける」
“People who do not develop dementia → can work.”

という『選別効果(サバイバー・バイアス)』です(江端注釈："幻想"という意味でしょう)。
This is a “selection effect (survivor bias)” (Ebata’s note: essentially what is meant by “illusion”).

ここを無視すると、「幻想」になります。
Ignoring this point leads directly to an illusion.

② では、仕事は“無意味”なのか？
2. Then, is work “meaningless”?

→ NO
→ No.

縦断研究・介入研究を総合すると、
When longitudinal and intervention studies are considered together,

・認知的負荷
・cognitive load
・社会的交流
・social interaction
・生活リズム
・daily rhythm
・役割意識・目的意識
・a sense of role and purpose

を伴う活動は、『認知予備能(cognitive reserve)』を高め、病理が進んでも症状の表出を遅らせることが示唆されています。
activities involving these factors are suggested to increase “cognitive reserve” and delay the manifestation of symptoms even as pathology progresses.

仕事は、これらをパッケージで満たしやすい活動です。
Work is an activity that tends to package these factors together.

だから、「発症リスクを下げる／発症時期を遅らせる可能性はある」という表現になります。
That is why it is said to “reduce risk” or “delay onset.”

③ なぜ「確実に防げない」のか？
3. Why can it not “certainly prevent” dementia?

→ 認知症は多因子疾患だからです。
→ Because dementia is a multifactorial disease.

アルツハイマー病理(アミロイドβ・タウ)、血管因子、遺伝要因(APOE ε4)、炎症・代謝・加齢。これらは、仕事をしていようが、していまいが、進行する場合があります。
Alzheimer’s pathology (amyloid-β and tau), vascular factors, genetic factors (APOE ε4), inflammation, metabolism, and aging these can progress regardless of whether one is working or not.

したがって、効果は「確率的」であり、個人差が極端に大きい。
Therefore, the effect is probabilistic, with extremely large individual differences.

予防というより「遅延」という位置づけになります。
It is better described as “delay” rather than prevention.

④ 「はっきり言え」と言われたら、こう言う
4. If asked to “state it clearly,” this is what to say

あなたの問いに対する一文での答えです。
This is the one-sentence answer to your question.

仕事を続けることは、認知症を防ぐ保証にはならないが、発症を遅らせる方向には統計的に働く。
Continuing to work does not guarantee the prevention of dementia, but it statistically helps delay the onset.

ただし、その効果は個人差が大きく、因果を単純化すると誤解が生じる。
However, the effect varies significantly among individuals, and simplifying causality leads to misunderstanding.

これが、科学的に誠実で、かつ最も「はっきりした」答えです。
This is the most scientifically honest and “clear” answer.

### ChatGPTの回答ここまで

### ChatGPT’s response ends here

---

このあともChatGPTには、
After this, I also asked ChatGPT,

「どんな種類の仕事・活動が、どの段階で、どの程度効くのか？」
“What kinds of work or activities are effective, at what stages, and to what extent?”
「仕事を辞めた後、何を代替すれば同等の効果が得られるのか？」
“And after quitting work, what can substitute to achieve similar effects?”

を聞いてみたところ、ざっくり以下の回答を貰いました。
and received roughly the following answers.

(1) 「仕事」が重要なのではなく、4つの要素が重要
(1) It is not “work” itself that is important, but four elements

(a) 認知的負荷(考える・判断する・学習する)
(a) Cognitive load (thinking, judging, learning)
(b) 社会的相互作用(他人とのやり取り)
(b) Social interaction (engaging with others)
(c) 主体性・役割(自分が必要とされる感覚)
(c) Agency and role (the feeling of being needed)
(d) 生活リズムの固定(起床・外出・予定)
(d) Fixed daily rhythm (waking, going out, scheduled activities)

(2) 上記(1)が満たされやすい仕事
(2) Jobs that tend to satisfy the above conditions

(a) 技術職、研究職、設計、教育
(a) Technical professions, research, design, education
(b) 管理職、調整役
(b) Management and coordination roles
(c) 接客・対人支援(高度なもの)
(c) Customer service and interpersonal support (at a high level)
(d) プロジェクト型業務
(d) Project-based work

(3) 上記(1)が満たされにくい仕事
(3) Jobs that tend not to satisfy the above conditions

(a) 単純反復作業のみ
(a) Purely repetitive tasks
(b) 孤立した軽作業
(b) Isolated light work

とのことでした。
That was the response.

リタイア後であっても、上記(1)の4条件が満たされるもの、例えば、語学学習、プログラミング・データ分析、楽器・作曲、大学院・公開講座などは、一定の効果が期待できるそうです。
Even after retirement, activities that satisfy the four conditions above, such as language learning, programming or data analysis, musical instruments or composition, graduate school, or public lectures, are said to offer certain benefits.

ただし、「脳トレ」は効果が弱いそうです。学習に一定のアウトプットが伴うことが重要、ということでしょう。(ぶっちゃけ、"収入"が発生するかどうか、という話に近いのかもしれません)。「脳トレ」を達成しても、対価は支払われませんからね。
However, “brain training” is said to be less effective. What matters is that learning involves some form of output, perhaps, bluntly speaking, whether income is generated or not. Completing brain training does not earn compensation, after all.

つまるところ、「参加者」では足りず、「担い手」となること。そして、失敗が許されない責任が(多少の差こそあれ)発生すること、が重要なようです。
In short, it is not enough to be a “participant”; one must be a “responsible actor.” And some degree of responsibility where failure is not easily forgiven must exist.

---

私の解釈ですが、
This is my interpretation,

(1) 『頭を使い、人と調整をし、ラクできない活動』
(1) “Activities that require thinking, coordination with others, and do not allow one to take it easy.”
(2) それが、結果として「評価や対価に晒される構造」を持っていること
(2) And that these activities are, as a result, exposed to evaluation and compensation

この2点が重要なのだと思います。
These two points are what truly matter.

多くの場合、それは「金を稼ぐ活動」という形を取りますが、本質は「逃げ場のない役割を引き受けているかどうか」なのでしょう。
In many cases, this takes the form of income-generating activities, but the essence is whether one has taken on a role with no easy escape.

さらにこれを纏めると、「引退しないこと」「現役であり続けること」そのものよりも、
Summing this up further, rather than “not retiring” or “remaining active” in itself,

―― 現役時代と同じ負荷構造を、引退後も自分で再構成できるかどうか
Can one reconstruct the same load structure after retirement?

が、発症を遅らせる方向に(確率的に)働く、と言えるのかもしれません。
May work probabilistically to delay onset.

---

つまり、私たちの年末年始休暇明けの、一年でもっとも辛い "今日" という仕事始めの日は、実は、
In other words, is the first workday after the year-end and New Year holidays the most painful day of the year? may actually be

―― 認知症の発症を遅らせるポジティブな一日(かもしれない)
a positive day that delays the onset of dementia (perhaps).

と考えれば、ほんのちょっとだけでも、憂鬱が消えるかもしれない、と言いたかったのです。
That was what I wanted to say: thinking this way might make the gloom fade just a little.

本当に、憂鬱ですよね。
It really is depressing.

皆さん、今年もよろしくお願い致します。
Wishing you all the best again this year.

『「認知症になれば、不安は解消する」という仮説について検討して下さい』とChatGPTに頼んでみた

この歌、いつ頃、流行ったかなぁ・・・私、学習塾で講師をやっていた時、子どもたちにこの歌を聞かせたことがあります。

今は、もう流せないのかなぁ？

最近のNHK大河ドラマには、興味深い挑戦が見られると思います。
I think recent NHK Taiga dramas present genuinely interesting challenges.

江戸時代のメディア王の話や、宮廷文学に乗せた恋愛話など、従来にない試みで楽しませてくれました（個人的には色恋ドラマにはあまり関心がありませんが）。
Stories about a media magnate of the Edo period, or romantic tales framed in court literature, have entertained us with approaches previously uncommon (although, personally, I am not particularly interested in romantic dramas).

日本史上の著名な権力者ではなく、それを取り巻く人物（黒田官兵衛、石田三成、明智光秀等）にクローズアップしたドラマなども面白いです。
It is also interesting to see dramas that focus not on the most famous power holders in Japanese history, but on the figures surrounding them (such as Kuroda Kanbei, Ishida Mitsunari, and Akechi Mitsuhide).

今後期待されるのは、松永久秀、三好義継、篠原長房、荒木村重、津田信澄あたりが題材になると面白いのでは、と思います。
Looking ahead, I think it would be interesting if figures such as Matsunaga Hisahide, Miyoshi Yoshitsugu, Shinohara Nagafusa, Araki Murashige, or Tsuda Nobuzumi were taken up as subjects.

明治維新後では、岩瀬忠震、川路聖謨、永井尚志などはどうでしょうか。ちょっとネームバリューと視聴率の面では難しそうですが。
For the period after the Meiji Restoration, how about Iwase Tadanari, Kawaji Toshiakira, or Nagai Naoyuki? Admittedly, their name recognition and potential ratings might be an issue.

そういう意味では、今年のNHKの大河ドラマ（豊臣秀長）には、少し期待しています。
In that sense, I have modest expectations for this year’s NHK Taiga drama (Toyotomi Hidenaga).

---

多分、現実的には、絶対に実施されないとは思うのですが――
Although I think that, realistically, this would almost certainly never be implemented—

GIS（Geographic Information Systems）を使った、ドラマとの同時進行
A system that runs in parallel with the drama using GIS (Geographic Information Systems)

が見たいなぁ、と思うのです。
is something I would really like to see.

簡単に言うと、地図上に戦場を再現して、ドラマに合わせて、軍隊の移動状況や主人公の立ち位置を変えていく、というものです。
Put simply, it would recreate battlefields on a map and change troop movements and the protagonist’s position in sync with the drama.

このようなシステムを、COP（Common Operational Picture：共通作戦状況図）といいます。
Such a system is called a COP (Common Operational Picture).

戦場・部隊配置・時間経過を、主にGIS上に統合表示し、指揮官や関係者が共通の状況認識を持つための仕組みです。戦場可視化(Battlefield Visualization)システムとも呼ばれます。
It is a mechanism that integrates and displays battlefields, troop deployments, and the passage of time—primarily in GIS—so that commanders and stakeholders can share everyday situational awareness. It is also referred to as a battlefield visualization system.

もちろん、このCOPを把握できるのは、当然、視聴者だけです――ドラマの登場人物が、このシステムを視聴していたら、ドラマになりませんから。
Of course, the only ones who can grasp this COP are the viewers—if the characters in the drama themselves could see it, there would be no drama.

川中島、関ヶ原、壇ノ浦――これらのフィールドでの状況が、ドラマと連動してWebサイトで見られたとしたら――これは、いわゆる「萌え」ではなく、純粋に「燃え」ますよ。
If the situations at Kawanakajima, Sekigahara, or Dan-no-ura could be viewed on a website in sync with the drama, this would not be “moe,” but something that genuinely fires you up.

川中島、関ヶ原、壇ノ浦が、現在の日本の何県の何市にあるか、ほとんどの日本人は知らないですよね。
Most Japanese people do not know which prefecture or city in present-day Japan Kawanakajima, Sekigahara, or Dan-no-ura are actually located in, do they?

この、大河ドラマ―COPリアルタイム連動放送が実現したら、地域活性政策として、半端ではない盛り上がり方をすると思います。「アニメの『聖地巡礼』」など目ではありません（と、私は思っていますが――そうでもないかな？）。
If this kind of real-time Taiga drama–COP linked broadcast were realized, I think it would generate an extraordinary level of excitement as a regional revitalization policy. It would far surpass so-called “anime pilgrimage” tourism (at least, that’s what I think—though perhaps not?).

私が、桶狭間合戦場の出身者であることは、何度もお話してきましたが、私、「大高城」も「沓掛城」も「鳴海砦」も、その場所を知らないのです（そもそも遺跡がちゃんとあるのかも怪しい）。
I have mentioned many times that I am from the area of the Battle of Okehazama. Yet, I do not actually know the locations of Odaka Castle, Kutsukake Castle, or Narumi Fort (and I am not even sure whether proper remains still exist).

桶狭間合戦の今川軍や織田軍が、私の元実家のあった場所で、行軍または戦闘していたと分かったら――そりゃ、燃えますよ。
If it turned out that the Imagawa or Oda forces at the Battle of Okehazama had marched or fought in the very place where my former family home stood—well, that would definitely fire me up.

---

そういう意味では、GISと言わないまでも、地図（または位置情報）というのは、過去と現在をタイムリープさせる超低コストの「タイムマシン」のような存在であり、そして、歴史と地理を連携させる有効な教材であると思うのです。
In that sense, even without explicitly calling it GIS, maps (or location information) function like an ultra-low-cost “time machine” that allows us to leap between the past and the present, and they are an effective educational tool that links history and geography.

なにより、「面白い」と思う――私は。
Above all, I find it interesting—that is what I think.

ただ、これを実現するには、「歴史学者」と「地理学者」の両方を兼ね備えた人物が必要でして、戦場可視化（Battlefield Visualization）にかなりのコスト、または、歴史＆地図オタクの存在が必要になると思います。
However, to realize this, one would need someone who combines the expertise of both a historian and a geographer, and it would require considerable cost for battlefield visualization—or the presence of a serious history-and-map enthusiast.

でまあ、「現実的には、絶対に実施されないとは思うのですが」と、先んじて逃げを打っておいた訳です。
So, by saying “realistically, it would almost certainly never be implemented,” I have already hedged my bets in advance.

---

この年末年始の休みは、毎日の歩行に、少しずつジョギングを加えながら、リハビリをしていたのですが、同時に、歩きながら、北朝鮮の資料を読み漁ってもいました。
During the year-end and New Year holidays, I was doing rehabilitation by gradually adding jogging to my daily walks. At the same time, I was voraciously reading materials on North Korea while walking.

私、今日、はじめて北朝鮮の地図をまじまじと見ました。そして、私が、これまで、北朝鮮を概念、または「点」として把握していたことに気がつきました。そして、この国の中に多くの人が生きていることを、漠然と感じることができました。
Today, for the first time, I closely examined a map of North Korea. I realized that until now I had perceived North Korea merely as a concept or a “point,” and I was able, albeit vaguely, to sense that many people actually live there.

地図を見てみると、その国の政治体制や国民の気質が見えてくる気がします――地政学というものではなくて、国を陸地で接している国々を見ると、それぞれの国が、早朝ラッシュ時の山手線に乗っている乗客のように見えてきて、なかなか示唆に富んでいて、面白いものです。
When you look at a map, you begin to feel that you can see a country’s political system and the temperament of its people—not in the sense of geopolitics, but rather as if the countries sharing land borders resemble passengers riding the Yamanote Line during the early-morning rush hour, which is quite thought-provoking and engaging.

もし「弔われていない戦死者の上に建つ土地」を事故物件と呼ぶのであれば、日本中の平野部は、ほぼ全滅です。

plans.xmlとoutput/output_plans.xml を記載します。変換の概要を教えて下さい。

[plans.xml]

<?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">
      </leg>
  
      <act type="w" link="10" dur="00:00:10" />
      <leg mode="walk">
      </leg>
	  
      <act type="w" link="11" dur="00:00:05" />
	  
      <leg mode="car">
		<!-- ここは書かない（MATSim に任せる） -->
      </leg>
	  
      <act type="h" link="11" />
	</plan>
  </person>

  <person id="2">
	<plan>
      <act type="h" link="10" end_time="06:00" />
      <leg mode="car">
		<route> </route>
      </leg>
	  
      <act type="w" link="11" dur="00:00:10" />
	  
      <leg mode="walk">
		<route> </route>
      </leg>
	  
      <act type="w" link="100" dur="00:00:05" />
	  
      <leg mode="car">
		<!-- ここは書かない（MATSim に任せる） -->
      </leg>
	  
      <act type="h" link="11" />
	</plan>
  </person>


</plans>

[output/output_plans.xml] # 正確には、output_plans.xml.gz を解凍して出てきます

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

<population>

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


<!-- ====================================================================== -->

	<person id="1">
		<attributes>
			<attribute name="vehicles" class="org.matsim.vehicles.PersonVehicles">{"car":"1"}</attribute>
		</attributes>
		<plan score="22.160614886406638" selected="yes">
			<activity type="h" link="1" end_time="06:00:00" >
			</activity>
			<leg mode="car" dep_time="06:00:00" trav_time="00:03:03">
				<attributes>
					<attribute name="routingMode" class="java.lang.String">car</attribute>
				</attributes>
				<route type="links" start_link="1" end_link="10" trav_time="00:03:03" distance="1911.1392376935653" vehicleRefId="1">1 2 86 242 74 72 60 58 56 52 719 554 216 214 628 626 624 622 301 174 172 424 437 10</route>
			</leg>
			<activity type="w" link="10" max_dur="00:00:10" >
			</activity>
			<leg mode="walk" dep_time="06:03:13" trav_time="00:21:34">
				<attributes>
					<attribute name="routingMode" class="java.lang.String">walk</attribute>
				</attributes>
				<route type="generic" start_link="10" end_link="11" trav_time="00:21:34" distance="1078.609916820958"></route>
			</leg>
			<activity type="w" link="11" max_dur="00:00:05" >
			</activity>
			<leg mode="car" dep_time="06:24:52" trav_time="00:00:00">
				<attributes>
					<attribute name="routingMode" class="java.lang.String">car</attribute>
				</attributes>
				<route type="links" start_link="11" end_link="11" trav_time="00:00:00" distance="0.0" vehicleRefId="1">11</route>
			</leg>
			<activity type="h" link="11" >
			</activity>
		</plan>

	</person>

<!-- ====================================================================== -->

	<person id="2">
		<attributes>
			<attribute name="vehicles" class="org.matsim.vehicles.PersonVehicles">{"car":"2"}</attribute>
		</attributes>
		<plan score="22.708654950989434" selected="yes">
			<activity type="h" link="10" end_time="06:00:00" >
			</activity>
			<leg mode="car" dep_time="06:00:00" trav_time="00:01:55">
				<attributes>
					<attribute name="routingMode" class="java.lang.String">car</attribute>
				</attributes>
				<route type="links" start_link="10" end_link="11" trav_time="00:01:55" distance="1253.9418184836827" vehicleRefId="2">10 414 317 319 171 173 175 177 179 11</route>
			</leg>
			<activity type="w" link="11" max_dur="00:00:10" >
			</activity>
			<leg mode="walk" dep_time="06:02:05" trav_time="00:18:06">
				<attributes>
					<attribute name="routingMode" class="java.lang.String">walk</attribute>
				</attributes>
				<route type="generic" start_link="11" end_link="100" trav_time="00:18:06" distance="905.5888853493962"></route>
			</leg>
			<activity type="w" link="100" max_dur="00:00:05" >
			</activity>
			<leg mode="car" dep_time="06:20:16" trav_time="00:01:14">
				<attributes>
					<attribute name="routingMode" class="java.lang.String">car</attribute>
				</attributes>
				<route type="links" start_link="100" end_link="11" trav_time="00:01:14" distance="877.1207180228002" vehicleRefId="2">100 98 92 22 20 18 16 14 12 11</route>
			</leg>
			<activity type="h" link="11" >
			</activity>
		</plan>

	</person>

<!-- ====================================================================== -->

</population>

変換の概要は、「入力 plans.xml の“骨格”（活動の場所・順序・滞在条件・モード）に対して、MATSim がシミュレーション実行時に“肉付け”（時刻の確定・経路・距離・所要時間・車両割当・スコア等）を付けたものが output_plans.xml」という理解になる。以下、入力→出力で何が起きたかを対応づけて説明する。

1. ルート未記載（または空）→ route が具体化される

car の場合

入力では leg mode="car" に route が無い／空だったが、出力では

<route type="links" start_link="1" end_link="10" ...>1 2 86 ... 10</route>

のように リンク列（link id の並び） が生成されている。

• type="links"：ネットワーク上のリンク列で経路を表現

• start_link, end_link：出発リンク／到着リンク

• distance：経路長（m）

• trav_time：その経路の所要時間（時刻依存の旅行時間に基づく）

つまり、入力 plans の「car で移動する」という指定に対して、MATSim が network.xml と travel time（初期は freespeed 等）を使って最短（一般には最小一般化費用）経路を計算し、具体的なリンク列として埋めた。

walk の場合

入力で <route> </route> があっても、出力では

<route type="generic" start_link="10" end_link="11" trav_time="00:21:34" distance="1078.60"/>

のように リンク列ではなく generic になっている。

• type="generic"：歩行をリンク列で保持しない（＝軌跡は残さない）扱い

• 代わりに distance と trav_time のみを保持

ここが、あなたが疑っている点（「ルートも追ってないのに正確な歩行時間が出るのはおかしい」）の“答え”で、MATSim は歩行を多くの場合「ネットワーク経路」ではなく「距離と速度による簡略モデル」で扱い、その結果として 時間だけは計算できるが、通過リンク列は残さない。

2. dur / end_time の表現が変わる（意味はほぼ同じ）

入力：

<act ... dur="00:00:10"/>

出力：

<activity ... max_dur="00:00:10"> </activity>

• dur が max_dur に変換されている

• 意味としては「この活動は最大でこの時間まで（計画上は固定に近い）」という扱い

一方で end_time="06:00" は出力で 06:00:00 に秒が補われているだけ。

3. dep_time（出発時刻）が埋められる

入力 plans.xml では leg に出発時刻は書いていないが、出力では

<leg mode="car" dep_time="06:00:00" trav_time="00:03:03">

のように dep_time が決まっている。

決め方は単純で、

• 直前の activity の終了時刻（end_time または開始＋max_dur）
  → 次の leg の dep_time

例（person 1）：

• home が 06:00:00 に終了
  → car の dep_time=06:00:00

• car trav_time=00:03:03
  → 次の activity 開始は 06:03:03

• work max_dur=00:00:10
  → 次の walk dep_time は 06:03:13（開始 06:03:03 + 10秒）

このように、行動の時間整合が実際に“確定値”として展開される。

4. trav_time（移動時間）と distance（距離）が付与される

各 leg に

• trav_time

• route の distance

が付く。これは MATSim がその反復（iteration）における travel time を使って計算した結果。

5. 車両の割当が追加される（vehicles / vehicleRefId）

出力では person ごとに

<attribute name="vehicles" ...>{"car":"1"}</attribute>

が入り、さらに car route に

vehicleRefId="1"

が付く。

これは「この person の car leg は、この person に割り当てられた vehicle を使う」という情報が、実行後の population として整備されたということ。

6. plan score と selected が付与される

<plan score="22.16..." selected="yes">

• score：その計画の効用（MATSim のスコアリング結果）

• selected="yes"：その person の中で採用された plan

入力 plans.xml は「計画の候補」だが、出力は「評価・選択された結果」を含む。

7. 「ゼロ移動」が発生している箇所がある（person1 の最後の car）

person 1 の最後の car leg が

start_link="11" end_link="11" distance="0.0" trav_time="00:00:00"
<route ...>11</route>

になっている。

これは入力上、

• w が link=11

• 次の h も link=11

で 同一リンク内の移動になっているため、経路計算の結果として移動がゼロになった。

8. ルートの“書き方”の差より、「実行後は MATSim が上書きする」ことが本質

あなたの入力では、

• route を完全に省略した leg

• <route> </route> の空タグがある leg

が混在しているが、出力を見る限り、少なくとも今回の実行では どちらも MATSim が結果で埋めるため、実務上の差はほとんど出ていない。

結論：変換とは何か

• 入力 plans.xml：
  行動の順序・場所（link）・活動の終了条件（end_time / dur）・移動モードだけを与える“骨格”

• 出力 output_plans.xml：
  骨格に対して MATSim が
  (1) 時刻展開（dep_time / trav_time）
  (2) 経路展開（car は links 列、walk は generic）
  (3) 距離付与
  (4) 車両割当
  (5) スコアと選択結果
  を付けた“結果の population”

以下のMATSimのplans.xmlの内容を説明して下さい。

<?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">
      </leg>
  
      <act type="w" link="10" dur="00:00:10" />
      <leg mode="walk">
      </leg>
	  
      <act type="w" link="11" dur="00:00:05" />
	  
      <leg mode="car">
		<!-- ここは書かない（MATSim に任せる） -->
      </leg>
	  
      <act type="h" link="11" />
	</plan>
  </person>

  <person id="2">
	<plan>
      <act type="h" link="10" end_time="06:00" />
      <leg mode="car">
		<route> </route>
      </leg>
	  
      <act type="w" link="11" dur="00:00:10" />
	  
      <leg mode="walk">
		<route> </route>
      </leg>
	  
      <act type="w" link="100" dur="00:00:05" />
	  
      <leg mode="car">
		<!-- ここは書かない（MATSim に任せる） -->
      </leg>
	  
      <act type="h" link="11" />
	</plan>
  </person>


</plans>

以下は、提示された MATSim の plans.xml の内容を、構造・意味・挙動の3点から整理して説明する。

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

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

<person id="X">
  <plan>
    <act ... />
    <leg mode="..." />
    <act ... />
    ...
  </plan>
</person>

• person
  → エージェント（個人）

• plan
  → その人の1日の行動シーケンス

• act（activity）
  → 滞在行動（自宅、職場など）

• leg
  → 活動間の移動

• act と leg は必ず交互に出現する

3. person id="1" の行動計画

(1) 最初の自宅活動

<act type="h" link="1" end_time="06:00" />

• type="h"
  → home（自宅）

• link="1"
  → network.xml の link id=1 上で活動

• end_time="06:00"
  → 06:00 に出発

(2) 自宅 → 職場（車）

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

• 移動手段：car

• <route> が書かれていない
  → MATSim が network.xml と travel time を使って経路を自動生成

(3) 職場活動①

<act type="w" link="10" dur="00:00:10" />

• type="w"：work（職場）

• link="10"

• dur="00:00:10"
  → 10秒だけ滞在

• end_time ではなく dur が指定されている点に注意
  → 開始時刻＋滞在時間で終了時刻が決まる

(4) 徒歩移動

<leg mode="walk">
</leg>

• 徒歩移動

• 経路は MATSim が内部で処理
  （多くの場合、距離÷歩行速度の単純計算）

(5) 職場活動②（短時間）

<act type="w" link="11" dur="00:00:05" />

• 別リンク（11）での職場活動

• 滞在時間は 5秒

(6) 再び車移動（経路指定なし）

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

• 車移動

• 経路は再計算対象

• replanning が有効なら、反復ごとに経路が変わりうる

(7) 帰宅

<act type="h" link="11" />

• 自宅活動（終了時刻なし）

• シミュレーション終了まで滞在

4. person id="2" の行動計画の特徴

person 2 は、person 1 と似ているが、route タグが明示的に存在する点が重要。

(1) 車移動（空の route）

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

• <route> タグは存在するが中身は空

• この場合：

  • 初期状態では意味のある経路情報はない

  • MATSim は 初回の routing で上書きする

• 実質的には <route> を書かない場合とほぼ同等

(2) 徒歩移動（空 route）

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

• 徒歩でも route を書けるが、

  • 多くのケースで MATSim は 詳細なリンク列を保持しない

  • travel time は内部計算

(3) 行動リンクの違い

<act type="w" link="100" dur="00:00:05" />

• person 1 とは異なるリンク構成

• network 上での空間的な差異を与えている

5. この plans.xml が意味する「本質」

(1) これは OD を完全に固定した計画ではない

• 出発時刻・滞在時間・モードは指定されている

• しかし：

  • 経路（link 列）は未確定

  • travel time はシミュレーション中に決定

(2) walk leg の扱い

• 多くの場合：

  • network を厳密に辿らない

  • link ベースの距離計算 or 直線近似

• そのため：

  • 正確な歩行経路ログは events.xml に残らないことが多い

(3) RCM / 共時空間解析への影響

• act の link と time は明示されている
  → 滞在の共時性は評価可能

• leg（特に walk）の詳細な軌跡は失われやすい
  → 移動中の「出会い」解析には不向き

6. まとめ（要点）

• この plans.xml は
  「行動の骨格だけを与え、移動の詳細は MATSim に委ねる」 設計

• route を書かない／空にするのは一般的

• 車移動はネットワークに基づくが
  徒歩移動は簡略化される

• 接触機会を「活動滞在ベース」で評価する用途向き

• 移動中の微細な接触解析には構造的制約がある

<attribute name="type" class="java.lang.String">residential</attribute> <attribute name="type" class="java.lang.String">primary</attribute> <attribute name="type" class="java.lang.String">tertiary</attribute> のアトリビュートの種類について説明をお願いします。
また、 <link id="203" from="1806698497" to="1806698523" length="159.5139984301562" freespeed="11.11111111111111" capacity="1000.0" permlanes="1.0" oneway="1" modes="car"> の各パラメータについても説明をお願いします。

以下、OSM → MATSim 変換後の network.xml を読むための実務向け説明として整理します。
定義論ではなく、「MATSim で何に使われ、どう効くか」を軸に書きます。

1. <attribute name="type"> とは何か

<attribute name="type" class="java.lang.String">residential</attribute>
<attribute name="type" class="java.lang.String">primary</attribute>
<attribute name="type" class="java.lang.String">tertiary</attribute>

結論

これは OSM の highway=* タグを、そのまま MATSim の link attribute として持ち込んだものです。

MATSim 標準の OsmNetworkReader は、

• OSM の highway タグ

• → MATSim link の attribute type

として保存します。

2. 各 type の意味（OSM 的・交通工学的）

以下は OSM の公式定義＋実務的な解釈です。

2.1 residential

• 住宅地内道路

• 生活道路

• 低速・低容量

• 交差点密度が高い

OSM 的には：

people live here

MATSim 的には：

• freespeed が低め

• capacity も控えめ

• 渋滞のボトルネックになりやすい

2.2 tertiary

• 地区幹線道路

• 住宅地と幹線をつなぐ役割

• 生活道路よりは速いが、主要幹線ではない

OSM 的には：

connects neighbourhoods

MATSim 的には：

• 中程度の freespeed

• 通過交通と生活交通が混在

2.3 primary

• 主要幹線道路

• 都市間・都市内の主要動脈

• 信号・交差点はあるが、通過交通向き

OSM 的には：

major roads between towns or important parts of a city

MATSim 的には：

• freespeed が高い

• capacity も高い

• 交通流を支配するリンクになりやすい

2.4 重要なポイント（研究用途的に）

• この type は MATSim の挙動に直接は使われない

• しかし：

  • 後処理

  • 可視化

  • フィルタリング

  • 分析（例：primary だけ抽出）

で 極めて重要

「MATSim が計算に使う値」ではなく
「人間が意味づけするための属性」

という位置づけです。

3. <link ...> 各パラメータの意味

対象：

<link id="203"
      from="1806698497"
      to="1806698523"
      length="159.5139984301562"
      freespeed="11.11111111111111"
      capacity="1000.0"
      permlanes="1.0"
      oneway="1"
      modes="car">

3.1 id="203"

• MATSim が内部的に振った link ID

• OSM の way ID ではない

• 識別子としてのみ使用

3.2 from, to

from="1806698497"
to="1806698523"

• MATSim network の node ID

• 今回は OSM node ID と一致

• 有向リンク（from → to）

3.3 length="159.51"

• リンク長 [m]

• CRS 変換後の座標距離から計算

• MATSim の移動時間・距離計算の基礎

重要：

• 現実の道路長と完全一致するとは限らない

• 曲線道路は直線近似されている

3.4 freespeed="11.11111111111111"

• 自由流速度 [m/s]

• 11.11 m/s ≒ 40 km/h

計算：

11.111... × 3.6 = 40 km/h

modes="car,bus"
modes="walk,bike"

4. MATSim 的に「効くパラメータ」「効かないパラメータ」

計算に直接効く

• length

• freespeed

• capacity

• permlanes

• modes

計算に直接は効かない（が超重要）

• attribute type（primary / residential など）

5. 全体の理解（重要）

この1本の link は、MATSim 的には：

「from node 1806698497 から to node 1806698523 へ
長さ約160m、自由流40km/h、容量1000veh/h、
車1車線の一方通行道路（住宅・幹線種別あり）」

という 完全に交通工学的な抽象道路です。

OSM の複雑な現実を、

• node

• directed link

• 数値パラメータ

に落とし込んだものが MATSim network です。

6. 次に自然な関心点

ここまで理解できたら、次は自然に：

• type ごとの freespeed / capacity の妥当性

• residential が速すぎないか？

• primary が遅すぎないか？

• bus を入れたらどう変わるか？

という **「モデルの現実性」**の話に進めます。

次はどこを見ますか？

• パラメータ調整？

• network の可視化？

• bus / pt network の追加？

network.xmlでは、全部、oneway="1"になっていますが、これで正しいのでしょうか？

結論から言います。

はい、現状の oneway="1" が並んでいるのは「異常ではない」が、
そのまま受け入れてよいかは「目的次第」です。

これは MATSim + OSM 変換で 非常によくある・意図された挙動です。
以下、理由と「何が起きているのか」を段階的に説明します。

1. まず重要な前提（誤解しやすい点）

❌ 誤解

OSM の道路は双方向が多い
→ network.xml も oneway="0" が多いはず

✅ 実際

MATSim の network は「有向リンク」が基本
→ 双方向道路でも「片方向リンク × 2本」で表現する

2. MATSim における「oneway」の意味

<link ... oneway="1" />

この oneway="1" は、

「この link オブジェクトは一方向リンクである」

という意味であり、

「この道路が現実世界で一方通行である」

という意味ではありません。

ここが最大の混乱ポイントです。

3. 双方向道路はどう表現されているか

OSM 側（例：residential, oneway 指定なし）

highway=residential
(oneway タグなし = 双方向)

MATSim 側では…

2本の link に分解されます

<link id="203" from="A" to="B" oneway="1" />
<link id="204" from="B" to="A" oneway="1" />

つまり：

👉 だから「全部 oneway=1」に見える

4. では「oneway=0」はいつ出るのか？

MATSim network では、実は：

• oneway="0" は ほぼ使われません

• 双方向性は link の本数で表現します

oneway="0" が出るケースは：

• 古い network

• 手書き network

• 特殊なカスタム実装

OSM → OsmNetworkReader → network.xml
という正統ルートでは、基本的に すべて oneway="1" になります。

5. OSM の oneway=yes はどう反映されているか

OSM が一方通行の場合

highway=primary
oneway=yes

MATSim では：

<link from="A" to="B" oneway="1" />

逆向きリンクは作られません

👉 結果として：

• 双方向道路：link が2本

• 一方通行道路：link が1本

どちらも oneway="1"

6. 正しいか？という問いへの答え

技術的に正しいか？

✅ 正しい

• MATSim の設計通り

• OsmNetworkReader の標準挙動

• 世界中の MATSim network がこうなっている

交通モデルとして正しいか？

✅ 目的次第で正しい

• 経路探索：問題なし

• 混雑生成：問題なし

• 方向制約：正しく表現されている

研究・説明的に誤解を招かないか？

⚠️ 説明は必要

論文・資料では必ずこう書くべきです：

「MATSim network は有向リンクで構成されており、
双方向道路は2本の一方向リンクとして表現されている」

7. 確認したい場合のチェック方法

(1) 同じ node ペアの逆向き link があるか

zgrep 'from="1806698497" to="1806698523"' output_network.xml.gz
zgrep 'from="1806698523" to="1806698497"' output_network.xml.gz

• 両方あれば → 双方向道路

• 片方だけ → 一方通行道路

8. まとめ（重要）

• oneway="1" が並ぶのは 正常

• MATSim は 有向リンク前提

• 双方向性は link の本数で表現

• OSM の oneway 情報は 逆向き link の有無に反映

• network.xml を見て不安になるのは 誰もが通る道

これはむしろ、

「network.xml をちゃんと読めている証拠」

です。

次に気になるのはたいてい：

• 「residential が速すぎないか？」

• 「capacity は現実的か？」

• 「bus を入れたらどうなるか？」

どれに進みますか？

network.xmlには、modes="car" になっています。エージェントで歩行をさせたい場合はどうすれば良いですか？

結論から言います。

いまの modes="car" の network.xml のままでは、歩行エージェントは動けません。
歩行をさせるには、network 側と設定（plans / config）の両方を整える必要があります。

以下、「何をどう変えるか」を 実務手順として説明します。

1. なぜ歩行できないのか（前提）

いまの network.xml では、各リンクが例えばこうなっています。

<link ... modes="car" />

MATSim の原則は：

エージェントは、自分の legMode が含まれるリンクしか通れない

つまり：

👉 歩行をさせるには、link に walk を含める必要がある

2. 方法は大きく3つある（重要）

方法A（最も正統・おすすめ）

network 作成時に walk を含める

あなたの Osm2NetworkCli は CLI で --modes を受け取れる構成です。

実行例

java -jar target/matsim-osm2network-1.0.0.jar \
  --osm hirohakama.osm \
  --out output_network.xml.gz \
  --toCRS EPSG:6685 \
  --modes car,walk

すると network.xml は：

<link ... modes="car,walk" />

になります。

✅ 車も歩行も同じ network を共有
✅ 最も MATSim 的
✅ 将来 bike / bus を足しやすい

方法B（歩行専用 network を作る）

--modes walk

• 歩行だけの network

• 車と完全に分離

これは：

• 歩行分析専用

• 車両流と干渉させたくない場合

に使います。

方法C（後処理で network.xml を書き換える）※非推奨

modes="car" → modes="car,walk"

を一括置換する方法。

❌ 再現性が低い
❌ 論文・研究向きでない
❌ 将来の自分が困る

3. network を直しただけでは「まだ足りない」

ここが重要ポイントです。

3.1 エージェント（plans.xml）側

歩行 leg はこうなっている必要があります。

<leg mode="walk">

3.2 config.xml 側（必須）

(1) qsim に walk を許可

<module name="qsim">
  <param name="mainModes" value="car,walk" />
</module>

(2) routing の設定

<module name="planscalcroute">
  <param name="networkModes" value="car,walk" />
</module>

(3) walk の速度（重要）

<module name="planscalcroute.walk">
  <param name="teleportedModeSpeed" value="1.34" />
</module>

※ 1.34 m/s ≒ 4.8 km/h（標準的歩行速度）

4. 歩行を「network 上で歩かせる」か「テレポート」にするか

MATSim では歩行に 2通りあります。

A. network walk（物理的にリンクを歩く）

• 渋滞・交差点を考慮

• 車と空間を共有

• 計算コスト高

👉 研究用途・都市スケール分析向き

B. teleported walk（距離÷速度）

• network を使わない

• 最短距離直線 or 軽量計算

• 計算コスト低

👉 大量人口・簡易分析向き

今の network を使うなら、あなたは A を選ぶ立場です。

5. 実務的なおすすめ手順（あなた向け）

① network を作り直す（最重要）

--modes car,walk

② config.xml に walk を追加

• qsim

• planscalcroute

• planscalcroute.walk

③ plans.xml に <leg mode="walk"> を入れる

6. まとめ（要点）

• modes="car" の network では歩行不可

• network 作成時に walk を含めるのが正道

• network / config / plans の3点セットが必要

• 歩行は MATSim では「特別扱い」されがちなので注意

• あなたの network 生成ツールは すでに walk 対応可能

Javaを使ったMATSim network.xml.gz 構築手順メモ（hirohakama）

1. 目的

OpenStreetMap から取得した OSM ファイルを入力として、
MATSim で利用可能な network.xml.gz を安定的・再現可能に生成する。

対象は以下。

• 入力：hirohakama.osm

• 出力：output_network.xml.gz

• 座標系：EPSG:6685（日本測地系・平面直角座標）

• 利用モード：car

2. なぜ Python プログラムではなく、MATSim 公式 API を使うのか

2.1 当初の疑問

• OSM → network 変換は Python でも書ける

• 実際、Python 版の変換スクリプトもすでに作成済み

• それでも MATSim の有効性を示すなら、公式ツールを使うべきではないか？ という疑問が生じた

2.2 結論

network.xml は「MATSim の内部仕様そのもの」であり、
MATSim 自身が生成した network.xml を使うことに意味がある

理由：

1. リンク属性（freespeed / capacity / lanes / allowedModes）の解釈が MATSim と完全一致

2. 将来 MATSim のバージョンが変わっても、
   network.xml の生成ロジックが MATSim 側で追従される

3. 論文・研究・再現性の観点で

   「MATSim 標準の OsmNetworkReader を用いて生成した network を使用した」
   と明記できる

結論として、

Python は補助・可視化・後処理に使う
network.xml の生成は MATSim に任せる

という役割分担にした。

3. 現在のディレクトリ構成（WSL）

/home/ebata/matsim-example-project/hirohakama/
├── hirohakama.osm
├── pom.xml
├── target/
│   ├── matsim-osm2network-1.0.0.jar
│   └── original-matsim-osm2network-1.0.0.jar
└── src/
    └── main/
        └── java/
            └── net/
                └── kobore/
                    └── matsim/
                        └── Osm2NetworkCli.java

補足（Windows から見たパス）

\\wsl$\Ubuntu\home\ebata\matsim-example-project\hirohakama\

4. 各ファイルの役割

4.1 hirohakama.osm

• OpenStreetMap からダウンロードした生の地図データ

• XML 形式

• 今後、エリアを変えればこのファイルだけ差し替える

4.2 Osm2NetworkCli.java

パス：

src/main/java/net/kobore/matsim/Osm2NetworkCli.java

役割：

• MATSim の OsmNetworkReader をラップした CLI（コマンドラインツール）

• 以下を担当：

  • OSM 読み込み

  • 利用 highway の限定

  • モード指定（car 等）

  • CRS 変換（EPSG:4326 → EPSG:6685）

  • network.xml.gz の出力

このファイルは：

• 今後 network の作り方を変えたくなった時に編集する

• 普段は直接触らない

• しかし 残しておく必要がある（再ビルド用）

4.3 pom.xml

役割：

• Maven のビルド定義

• 以下を明示的に設定している：

  • Java 17

  • MATSim 15.0

  • GeoTools EPSG 辞書（gt-epsg-hsql）

  • OSGeo リポジトリ

  • Shade Plugin（fat jar 作成）

  • 署名ファイル除外（Invalid signature file digest 対策）

  • Main class 指定

この pom.xml によって「java -jar で動く単一 JAR」が作られる

4.4 target/matsim-osm2network-1.0.0.jar

役割：

• 実行ファイル

• network.xml.gz を作るだけなら これだけあれば良い

• Java ソースを触らない限り、再ビルド不要

5. ビルド手順（必要な場合のみ）

Java ソースを変更した場合のみ実行。

cd /home/ebata/matsim-example-project/hirohakama
mvn -q -DskipTests clean package

成功すると：

target/matsim-osm2network-1.0.0.jar

が生成される。

6. network.xml.gz の生成手順（通常作業）

cd /home/ebata/matsim-example-project/hirohakama

java -jar target/matsim-osm2network-1.0.0.jar \
  --osm hirohakama.osm \
  --out output_network.xml.gz \
  --toCRS EPSG:6685 \
  --modes car

実行ログ例

[INFO] OSM      : hirohakama.osm
[INFO] OUT      : output_network.xml.gz
[INFO] toCRS    : EPSG:6685
[INFO] modes    : [car]
[INFO] highways : [motorway, motorway_link, trunk, ...]

成功すると、同ディレクトリに

output_network.xml.gz

が生成される。

7. 深いディレクトリ構造についての補足メモ

src/main/java/net/kobore/matsim/

という深さは、

• Maven の規約

• Java の package とディレクトリの 1 対 1 対応

• クラス名衝突防止（世界規模）

という Java の設計思想そのもの。

個人研究・小規模用途としては冗長だが、

• MATSim

• GeoTools

• Java エコシステム

と共存する以上、受け入れるのが最短ルート。

8. 今後の使い方方針（整理）

• OSM を変える
  → hirohakama.osm を差し替える

• network 条件を変える
  → Osm2NetworkCli.java を編集 → mvn package

• 普段の作業
  → jar を実行するだけ

9. まとめ（判断の記録）

• Python 版は「自分で制御できる」利点がある

• しかし MATSim network の正当性・再現性・説明責任を考え、

  • network 生成は MATSim API に委ねた

• この Java プログラムは
  「network.xml を作るためだけの専用工具」

• 一度作ってしまえば、運用は極めて単純

高齢者によるアクセルとブレーキの踏み間違いによる事故が後を断ちません。
Accidents caused by elderly drivers mistakenly pressing the accelerator instead of the brake continue unabated.

国内では、以下のような重大事故が実際に発生しています。
In Japan, the following serious accidents have actually occurred.

(1) 2019年4月19日、東京都豊島区池袋で、高齢ドライバーがアクセルとブレーキを踏み間違え、横断歩道に突入し、母子2人が死亡、複数人が重軽傷を負う事故が発生しました（池袋暴走事故）。
(1) On April 19, 2019, in Ikebukuro, Toshima Ward, Tokyo, an elderly driver mistakenly pressed the accelerator instead of the brake and crashed into a crosswalk, killing a mother and her child and injuring several others (the Ikebukuro runaway car accident).

(2) 2019年6月22日午後0時40分ごろ、福岡県北九州市八幡西区で、高齢男性が運転する車がスーパーマーケットの駐車場でアクセルを踏み続け、歩行者をはねる事故が発生しました。
(2) Around 12:40 p.m. on June 22, 2019, in Yahatanishi Ward, Kitakyushu City, Fukuoka Prefecture, a car driven by an older man continued accelerating in a supermarket parking lot and struck a pedestrian.

(3) 2021年11月25日午後2時30分ごろ、神奈川県横浜市戸塚区で、高齢ドライバーの車が国道沿いの歩道に突入し、バス停で待っていた歩行者が巻き込まれ、複数人が死傷する事故が起きました。
(3) Around 2:30 p.m. on November 25, 2021, in Totsuka Ward, Yokohama City, Kanagawa Prefecture, a car driven by an older adult veered onto a sidewalk along a national highway, hitting pedestrians waiting at a bus stop and causing multiple deaths and injuries.

(4) 2025年12月10日午後3時ごろ、福岡県宗像市で、高齢ドライバーがアクセルとブレーキを踏み間違え、スーパーマーケットの出入口に車が突っ込み、買い物客が負傷しました。
(4) Around 3:00 p.m. on December 10, 2025, in Munakata City, Fukuoka Prefecture, an elderly driver mistakenly pressed the accelerator instead of the brake, crashing into the entrance of a supermarket and injuring shoppers.

当然のことながら、海外でも同種の事故は発生しています。
Naturally, similar accidents have occurred overseas as well.

(5) 2003年7月16日、米国カリフォルニア州サンタモニカで、高齢ドライバー（86歳）の車がファーマーズマーケットの歩道に突入し、10人が死亡、60人以上が負傷しました（サンタモニカ・ファーマーズマーケット事故）。
(5) On July 16, 2003, in Santa Monica, California, USA, a car driven by an elderly driver (86 years old) crashed into a sidewalk at a farmers’ market, killing 10 people and injuring more than 60 (the Santa Monica Farmers Market crash).

これらの事故は低速域・日常空間で発生することが多く、被害者が歩行者である点に共通性があります。
These accidents often occur at low speeds in everyday spaces, and they share the common feature that the victims are pedestrians.

このような事故について『決定的な対策が打てない理由』については、こちらに記載しています。
The reasons why "decisive countermeasures cannot be implemented" for such accidents are described here.

(↑ Click on the column)

---

私が不思議に思っているのは、『このような事故は、現在の技術で簡単に止められるのではないか』ということなのです。
What I find puzzling is this: aren’t accidents like these easily preventable with current technology?

最近の自動車のブレーキやアクセルは、Webに表示されるスライダ(ボリューム)のように扱われています。ブレーキやアクセルにかかる負荷を信号に変えて、自動車のコンピュータ(ECU：Electronic Control Unit（電子制御ユニット）)に伝えられているだけです。
In modern cars, the brake and accelerator are treated much like sliders (volume controls) displayed on a web interface. The force applied to the brake or accelerator is converted into a signal and sent to the car’s computer (ECU: Electronic Control Unit).

もう少し正確に書きましょう。
Let me describe this a bit more precisely.

(1)アクセルペダルは、機械的にスロットルを直接引いておらず、踏み込み量をセンサで検出する入力装置に過ぎません。ECU が信号を解釈し電子制御スロットルを動かすという ドライブ・バイ・ワイヤ（Drive-by-Wire）方式を採用しています。
(1) The accelerator pedal does not mechanically pull the throttle directly; it is merely an input device that detects how far it is pressed via sensors. The ECU interprets the signal and moves the electronically controlled throttle, using a drive-by-wire system.

一方、
On the other hand,

(2)ブレーキは、ブレーキペダル → 油圧 → ブレーキという 機械系が依然として残っていますが、同時にABS、ESC、自動ブレーキ（AEB）などが ECUにより強制介入します。
(2) The braking system still retains a mechanical structure?brake pedal → hydraulic pressure → brakes?but at the same time, systems such as ABS, ESC, and automatic emergency braking (AEB) forcibly intervene under ECU control.

ペダル操作は電気信号として ECU（Electronic Control Unit）に送られ、実際の加速や減速はコンピュータが制御しているのです。
Pedal operations are sent to the ECU, which controls electrical signals and actual acceleration and deceleration.

つまり、ドライバーが踏んでいるのは「力」ではなく「意思」であり、その意思をどう反映させるかの最終判断は車両側に委ねられている ーー つまり、ブレーキやアクセルは、原則として「入力デバイス」であって、実際は、その駆動部の信号が処理されているだけなのです。
In other words, what the driver is applying is not "force" but "intent," and the final decision on how that intent is reflected is left to the vehicle, meaning that the brake and accelerator are, in principle, merely "input devices," and only the signals to the drive system are actually being processed.

最近、すっかり安くなったドライブレコーダと連携すれば、「人混み、店舗、歩道に対して、強いアクセルの信号を検知すれば、それをキャンセルする制御をすることなどは、造作もない」と思うのです。
By linking with dashboard cameras, which have become quite inexpensive recently, it would be trivial to implement control logic that cancels strong accelerator signals when people, shops, or sidewalks are detected.

少なくとも、私のような組み込み系も取り扱うエンジニアにとって、『ECUのプログラムを書き換える』というのは、十分に可能ではあります。実際にアフターマーケットや不正改造で行われています。当然、私程度の技術力でも可能です。
At least for an engineer like me who also works with embedded systems, "rewriting ECU programs" is entirely feasible. It is already done in the aftermarket and through illegal modifications. Naturally, it is possible even with my level of technical skill.

ただし「違法」です。
However, it is "illegal."

そりゃ違法に決まっています。こんなことが、合法であれば、
Of course, it is illegal. If such things were legal,

- 速度リミッターを解除した車や、
- cars with speed limiters removed, or

- 衝突回避機能を意図的に無効化した車や、
- cars with collision avoidance functions intentionally disabled, or

- アクセル入力と実際の駆動出力を乖離させた車
- cars where accelerator input is decoupled from actual drive output

を作るなど、造作もないことです。
Creating such vehicles would be trivial.

悪意で、他人の車のECUにハッキングすれば、簡単に大事故を誘発することも可能でしょう。
With malicious intent, hacking another person’s car ECU could easily trigger a significant accident.

---

しかし、私は、すでに上記の事故を起こし得る当事者となる年齢に至っております。
However, I have already reached an age at which I could become a party responsible for such accidents myself.

合法的に、販売店ディーラーで、ECUのプログラム書き換えをやってくれるのであれば、10万円単位の金を払ってでもお願いしたいです。人を殺傷するコストに比べれば、ゴミのようなコストと言えましょう。
If a dealer were to rewrite the ECU program legally, I would gladly pay tens of thousands of yen. Compared to the cost of killing or injuring someone, it is negligible.

-----

さて、ここから本論です。
Now, here is the main argument.

では、なぜ「この程度の改造ができないのか？」
So why is it impossible to make modifications of this level?

理由は、技術の問題ではありません。責任の問題です。
The reason is not a technical problem. It is a problem of responsibility.

もしディーラーが ECU を書き換え、「人混みでは強制的に加速しない車」を販売したとします。その結果、誤検知で車が止まり、後続車に追突され、事故が起きた場合――その責任は誰が負うのでしょうか。
If a dealer rewrote the ECU and sold a car that does not accelerate forcefully in crowded areas, and as a result, a false detection caused the vehicle to stop and be rear-ended, leading to an accident, who would bear responsibility?

運転者か。ディーラーか。自動車メーカーか。それとも ECU のソフトを書いた技術者か。
The driver? The dealer? The automaker? Or the engineer who wrote the ECU software?

現在の制度では、この問いに明確な答えを出せません。だから、自動車は「最後は人が操作する」という建前を崩せないのです。
Under the current system, there is no clear answer to this question. That is why the premise that "in the end, humans operate cars" cannot be abandoned.

技術的には車は止められます。しかし、止めた結果として起きた事故の責任を、誰も引き受けられない。
Technically, cars can be stopped. However, no one can be held responsible for accidents caused by blocking them.

---

この「責任を引き受けられないために改造できない」という構造は、主に以下の法令によって支えられています。
This structure," modifications cannot be made because responsibility cannot be assumed," is supported mainly by the following laws.

(1) 道路運送車両法および保安基準
(1) Road Transport Vehicle Act and safety standards

自動車は型式指定を受けた状態でのみ公道走行が認められており、ECU を含む制御系のプログラムを書き換えることは、原則として「構造等変更」に該当します。販売店やディーラーがこれを行えば、保安基準違反となり、車両の公道使用は認められません。
Vehicles are allowed on public roads only in their type-approved configuration, and rewriting control programs, including the ECU, generally constitutes a "structural modification." If dealers perform such changes, it violates safety standards, and the vehicle cannot legally be used on public roads.

(2) 製造物責任法(PL法)
(2) Product Liability Act (PL Act)

もしディーラーやメーカーが ECU を改変した車を提供し、その制御によって事故が起きた場合、「欠陥のある製品を提供した」として、メーカーや改変主体が無過失責任を問われる可能性があります。
If a dealer or manufacturer provides a vehicle with a modified ECU and an accident occurs due to that control, the manufacturer or modifier may be held strictly liable for providing a defective product.

このため、販売側は「人の操作に最終責任がある」構造を手放せません。
For this reason, sellers cannot let go of the structure in which final responsibility lies with human operation.

(3) 道路交通法
(3) Road Traffic Act

現行制度では、運転行為の主体はあくまで「人」であり、事故の第一次的責任も運転者に帰属します。車両側が運転判断を上書きする設計を前提にしていないため、強制的な加速キャンセルや停止を常時組み込むことは、制度上、想定されていません。
Under the current system, driving is strictly a human activity, and primary responsibility for accidents lies with the driver. Since vehicle designs do not assume overriding human driving decisions, constant forced acceleration cancellation or stopping is not envisioned institutionally.

これが、この程度の改造ができない理由です。
This is why modifications of this level cannot be implemented.

---

言い換えれば、私たちは「人が誤操作で事故を起こすリスク」よりも、「機械が判断して事故を起こす責任問題」を、まだ社会として受け入れられていないのです。
In other words, as a society, we have not yet accepted responsibility when machines make decisions and cause accidents, even though we take greater risks from human error.

技術はすでにあります。
The technology already exists.

足りないのは、プログラムではなく、覚悟と制度なのです。
What is lacking is not programming, but resolve and institutions.

---

現行の法令のままであれば、基本的に、このような事故はこれからも発生しつづけ、多くの人が死傷することになります。
If current laws remain unchanged, accidents like these will continue to occur, and many people will be killed or injured.

これを回避する手段は、私から見れば『チョロイと言えるほど簡単』なのにそれができません。
From my perspective, the means to avoid this are "so easy they are trivial," yet they cannot be implemented.

まあ、他人のことはどうでもいいです。
Well, other people’s matters don’t really concern me.

取り敢えず、嫁さんと私の為に、違法上等で、確信犯的にECUのハッキングをやってやろうか、と(不穏なことを)考え始めています。
For now, for the sake of my wife and myself, I have even started thinking "dangerously" about deliberately hacking an ECU, legality be damned.

というか、
Or rather,

――私なら本当にやりかねない
"I might really do it."

地元のお巡りさんは、私の家の巡回を頻繁に行った方が良いです。
The local police would do well to patrol around my house frequently.

もし私が、機材やパソコンを、私の自宅の自動車のガレージに展開しながら、車の下に潜っているのを見つけたら、即座に職務質問、任意同行を求めることを、強くお勧めします。
If they find me spreading equipment and computers in my home garage while crawling under my car, I strongly recommend that they immediately conduct a stop-and-question and request voluntary accompaniment.

―― N-BOXには「改造したい」という気持ちが湧いてこない