<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には「改造したい」という気持ちが湧いてこない

\\wsl$\Ubuntu\home\ebata\matsim-example-project\scenarios\equil2

output/output_events.xml.gzと、output/output_network.xml.gzを生成したら、
$ go run matsim_events_to_geo_csv.go
で、agent_positions_geo.csv ができたら、999.9_merged_type1.csvにリネームして、

go run server22-1.go → http://localhost:8080
で、
go run pm_proxy_single_socket.go
でエージェントが歩き出す

(続きは明日)

インパール作戦とは、1944年（昭和19年）に日本陸軍がビルマ（現ミャンマー）から英領インドのインパール方面へ侵攻した作戦です。

目的は、英印軍の拠点であるインパールを攻略し、英軍の戦力を分断・弱体化させること、あわせてインド独立運動への影響を期待する点にありました。

主力は第15軍（司令官：牟田口廉也中将）で、険しい山岳地帯と未整備の補給路を越えて進攻したのでうが、補給の破綻、英軍の反攻、モンスーンの到来により壊滅的損害を被り、作戦は失敗に終わりました。

戦後の研究において、このインパール作戦と、それを指揮した牟田口中将は、今なお、批判され続けています。

主な批判点は、以下の通りです。

(1)補給計画の欠如
食糧・弾薬・医療物資の補給が現実的に成り立たず、「現地調達」への過度な依存が兵の大量餓死・病死を招いた。

(2)非現実的な作戦立案
地形・気候（雨季）・敵戦力の分析が甘く、成功可能性の低い作戦を強行した点が批判されている。

(3)上層部の独断と精神主義
現場の反対意見や中止進言が無視され、「精神力で克服できる」とする非合理な判断が続いた。

(4)指揮統制の混乱
作戦途中でも方針が一貫せず、撤退判断が遅れ、被害を拡大させた。

(5)兵士の生命軽視
戦略的成果に比して犠牲が極端に大きく、日本軍史上でも最悪級の失敗例として位置づけられている。

このインパール作成は、ミッドウェイ開戦より、酷い扱いを受けています。で、その理由が

―― 牟田口廉也中将は、戦後においてもインパール作戦の根本的な誤りを認めず、一定の正当化を続けた

という点が挙げられます。

ただ、私は、このことに対して、理非を論じたい訳ではありません。

当時の日本陸軍全体が「精神主義」「上意下達」「兵站軽視」だったのは事実でしたし、その場(戦場)にいなかった私が、軽々しく「戦争責任を内面化できなかった指揮官」と評することはできません。

ーー と、ここまでが前置きです。

-----

私が、このインパール作成のことを覚えているのは、

―― 雨が降りしきり、道行く先には腐敗が進む死体の山

―― 死んでるのは兵士や軍属ばかり

―― 将校と下士官は死んでいない

という内容のメモと、

『小休止後、立ち上がらない兵士が、その場で死んでいた』

という内容を覚えていたからです。

言うまでもないことですが、「小休止が兵士を殺した」というのは、当然ながら「ミスリーディングのロジック」です。

これは、インパール作戦の酷さを語る一節であれば良いのです。

『"部下"のほとんどが餓死している真っ最中にあって、"上司"には食事が与えられ、食べることができる』

-----

昨日から、私がPCとバトルを繰り返しているのは、『PCに小休止を与えないことによる、カーネルパニックを避ける処理』です。

「Windows + Radeon iGPU が“完全アイドル”に入る瞬間を作らない」ことで、負荷が高い時ではなく、何もしていない時に起きるカーネルパニックを回避する方法を、ChatGPTと相談しながら進めています。

不安定な省電力復帰を「起こさせない」ための保険として、"GPU keep-alive 常駐"という処理を組み込んでいます。

つまり、『PCに小休止を与えない』ことで、PCの連続稼働率を上げる作戦です。

-----

で、まあ、このようなPCのセッティングを行っている私(江端)は、牟田口廉也中将みたいなのかな ーー などと思ったりしています。

MINISFORUM HM90 / Windows 11 放置中フリーズ対策・検証メモ

MINISFORUM HM90 / Windows 11 放置中フリーズ対策・検証メモ

背景

• HM90（Ryzen / Vega iGPU）で 頻繁なフリーズ

• 画面が真っ黒、pingも通らない

• GStreamer使用時に顕在化するが、未使用時でも発生

• Windows 11 は継続使用が前提

1. 原因の切り分け結果（結論）

❌ 原因ではなかったもの

• GStreamerそのもの

• GPU描画（D3D11 / OpenGL）

• VAAPI（※Windows版GStreamerには存在しなかった）

• デコード＋表示の連続負荷

✅ 真の原因

• CPU / GPU が完全アイドルに入る際の電源遷移（C-State / ACPI系）

• 典型的な 「放置中フリーズ」

• HM90 + Windows 11 + Vega世代iGPUの構造的相性問題

2. BIOS 側対策（可能な範囲）

※ HM90 の BIOS は OEM 最小構成（Chipset / ACPI 詳細なし）

設定した項目

意味

• OS に「C1までしか使えない」と申告

• 深い C-State（C6 / PC6 / S0ix）への遷移を抑制

3. Windows 11 側対策（必須）

電源設定

• 電源プラン：高パフォーマンス

• 最小のプロセッサの状態：100%

• スリープ：無効

• 高速スタートアップ：無効（確認済み）

確認場所

• コントロールパネル → 電源オプション

• 電源ボタンの動作 → 高速スタートアップOFF

4. GStreamer 環境確認

使用環境

• GStreamer 1.26.10

• MSVC x86_64

• PATH 混在なし

VAAPI 状況

• vaapi / vaapih264dec / vaapipostproc すべて存在しない

• → Windows では VAAPI は前提にしない

5. GStreamer による検証結果

表示のみテスト（安定）

→ 両方とも安定

デコード＋表示（実ファイル）

→ 正常再生

長時間相当テスト（sync無効）

→ 30分以上安定、フリーズなし

結論

• GStreamer実行中は落ちない

• 落ちるのは「完全放置時」のみ

6. 最終結論（重要）

• HM90 の不安定性は
  「完全アイドル状態への遷移」がトリガ

• 軽い負荷がある限り 非常に安定

• よって 常時 keep-alive が最も現実的な根本回避策

7. 実運用向け最終対策（推奨）

keep-alive（最小・確実）

方法A：GStreamer keep-alive（推奨）

• 表示なし

• 極小負荷

• 放置フリーズをほぼ100%防止

方法B：Windows汎用 keep-alive

※ タスクスケジューラ or スタートアップ登録で常駐可

8. 運用方針まとめ

• ❌ Windows 11 をやめる必要なし

• ❌ GStreamer 構成を疑う必要なし

• ❌ ハード故障ではない

• ✅ 軽い常時処理を入れて安定運用

残っている“有効な手段”は2つだけです。

【必須】① TDR（GPUリセット）無効化

※ これはまだ「結果報告」をもらっていません

もう一度確認させてください。

質問

以下は すでに実行しましたか？

• 実行済み / 未実行

• 実行済みなら 再起動済みか も教えてください

👉 **これが最後の“ソフト側の本丸”**です。

【必須】② keep-alive を「常時GPU描画」に固定

これも 最終形にします。

実運用用 keep-alive（これを基準に）

• 起動したら 最小化

• 作業中も 終了しない

• Radeon Software の GPU 使用率が
  2〜5%で常時張り付く → 正常

ここからの判断基準（重要）

この 2点を両方満たした状態で：

• ✔ 落ちない
  → HM90 は「縛れば使える」個体

• ✖ まだ落ちる
  → 電源（ACアダプタ / VRM）起因

  • ソフトでは止められない

  • この場合「役割限定運用」が現実解

正直な話（隠しません）

ここまで切り分けて：

• GStreamer ❌

• Windows設定 ❌

• GPUドライバ設定 ❌

• ユーザ操作 ❌

が全部消えました。

**残るのは「HM90の設計限界」か「TDRだけ」**です。

TDR 無効化の確認方法（確実）

方法①：PowerShell で確認（最も確実）

手順

1. スタート

2. PowerShell を右クリック

3. 管理者として実行

以下を そのままコピー＆ペースト してください。

確認ポイント（ここが重要）

表示結果の中に、以下の行があるかを見てください。

正常（TDR 無効化済み）の場合

• TdrLevel = 0x0 → TDR 無効

• TdrDelay = 0x3c → 60秒（10進数で60）

👉 この2行があれば「実行済み」かつ有効です。

未設定 or 無効の場合

• TdrLevel が 表示されない

• または

• TdrLevel REG_DWORD 0x3

などの場合

👉 未実行 or TDR 有効のまま

方法②：レジストリエディタで確認（GUI）

手順

1. Win + R

2. regedit → Enter

3. 以下へ移動：

右ペインを確認

• TdrLevel

• TdrDelay

が存在するかを確認。

値の意味

• TdrLevel = 0 → 無効

• TdrDelay = 60 → OK

注意点（重要）

• 設定しただけではダメ

• 必ず再起動が必要

再起動前は、

設定されていても 実際には効いていません

次のアクション（これだけ）

1. 上記どちらかで確認

2. 結果を そのまま書いてください

例：

• TdrLevel = 0x0, TdrDelay = 0x3c

• TdrLevel が存在しない

• TdrLevel = 0x3

👉 その1行で次の判断が確定します。

確認結果の評価（確定）

これは何を意味するか

• TdrLevel = 0x0

  • ✅ GPU TDR（自動リセット）完全無効

• TdrDelay = 0x3c（60秒）

  • ✅ 仮に TDR が有効でも最大猶予

👉 Windows 側が GPU を原因に OS を巻き添えで落とす経路は、これで完全に遮断されています。

ここまでで“消えた容疑者”

これで以下は 全て除外されました。

• ❌ GStreamer

• ❌ GPU ドライバの TDR

• ❌ Windows 電源管理

• ❌ Radeon Software 設定

• ❌ C-State / OS 省電力

• ❌ ユーザー操作ミス

今すぐ取れる“現実的な最終対策”

【最重要】GPU keep-alive を「常駐・常時」に

すでに何度か出していますが、これは“最終形”です。

運用ルール

• Windows 起動直後に必ず起動

• ウィンドウは最小化

• 作業中は絶対に終了しない

👉 GPU 使用率が 常時 2〜5% で張り付く状態を維持。

【強く推奨】AC アダプタの確認

確認してください：

• 付属 AC アダプタの W数（例：90W / 120W）

• 他の 同規格・高W数のアダプタがあれば試す

👉 電圧降下が一瞬でも起きると 即死します。

【切り札】役割分離運用（現実解）

もし：

• keep-alive 常駐

• TDR 無効

• 電源確認

全部やっても落ちる場合

👉 HM90 を

• 映像処理専用

• 常時一定負荷専用

として使い、

• ビルド

• 重い IDE

• 同時多アプリ

を 別マシンに逃がす

これが 現場ではよく使われる解です。

次の一手（ここから選択）

ここからは「技術」ではなく「判断」です。

次に進むなら、どれにしますか？

1. keep-alive 常駐を前提に運用手順を固める（スタートアップ化）

2. ACアダプタ／電源起因を切り分ける具体手順

3. ここまでの対策を“技術メモ”として整理

番号で答えてください。
どれを選んでも、ここまでの切り分けは正解です。

以下は Windows 11 上で GPU keep-alive（GStreamer）を「常駐・常時」運用にする具体手順です。
（GStreamer は C:\Program Files\gstreamer\1.0\msvc_x86_64\bin に入っている前提で書きます）

結論（最短ルート）

👉 gpu_keepalive.bat を直接実行してはいけません
👉 必ず「非表示起動ラッパー（VBS）」経由にします
👉 タスクスケジューラも VBS を起動対象に変更します

これで 画面は一切出ません。

手順①（必須）VBS ラッパーを作る

ファイル作成

C:\scripts\gpu_keepalive.vbs

内容をそのまま貼り付けて保存：

重要ポイント

• 0 → 完全非表示

• False → 呼び出し元に制御を戻さない

• .vbs は wscript.exe で実行され、cmd.exe を出しません

手順②（最重要）タスクスケジューラを修正

いまの状態を見ると：

❌ 起動対象

になっています（しかも綴りも間違い）。

「GPU keep-alive 常駐」の意義を再度説明して下さい

結論（先に要点）

GPU keep-alive 常駐の意義は 1 つです。

「Windows + Radeon iGPU が“完全アイドル”に入る瞬間を作らない」

これだけです。

HM90 の不安定さは
負荷が高い時ではなく、何もしていない時に起きる
──ここが本質です。

HM90 + Windows 11 + Radeon iGPU で起きていること

① 問題が起きるタイミング

あなたの観測通り：

• 放置中にフリーズ

• 画面ブラックアウト

• ping 不通

• 電源は入っている

• 再起動しか回復手段がない

これは アプリクラッシュではありません。
OS レベルで GPU / PCIe / 電源管理が死んでいます。

② なぜ「何もしていない時」に落ちるのか

Windows 11 では、以下が同時に働きます：

• CPU：C6 / PC6 への深い C-State 遷移

• GPU：D3cold（完全電源断）へ遷移

• PCIe：ASPM L1.2

• Radeon ドライバ：省電力優先ロジック

• TDR：GPU が応答しないと OS が強制リセット

👉 この遷移の組み合わせが HM90 では不安定

特に Ryzen 4000 系 iGPU は
「復帰時のタイミングズレ」に弱い。

③ keep-alive がやっていること（技術的に）

あなたの keep-alive パイプラインは：

これが意味することは：

• Direct3D11 コンテキストを維持

• GPU コマンドキューを定期的に使用

• VRAM / shared memory を触り続ける

• GPU を D0（動作状態）から落とさない

つまり：

GPU に「生きてるぞ」という脈拍を打ち続けている

なぜ「表示なし」でいいのか

重要なのは 描画結果ではありません。

• 描く → 不要

• 見せる → 不要

• GPU に仕事を与える → 必須

fakesink は
「仕事はさせるが、何も表示しない」
という最も合理的な選択です。

「負荷をかけている」のではないのか？

いいえ。

実際の負荷は：

• GPU 使用率：0.5〜3%

• 消費電力：ほぼアイドル

• 温度上昇：誤差レベル

これは **省電力遷移を避けるための“最小刺激”**です。

なぜ BIOS やレジストリだけでは足りないのか

あなたはすでに：

• 高パフォーマンス電源プラン

• C-State 制限

• TDR 無効化

• ドライバ設定の最適化

をやっています。

それでも落ちる理由：

「最後に残るのは、実際に GPU が使われているかどうか」

OS は
「設定」ではなく
「実際の利用状況」 を見て判断します。

keep-alive を入れた世界線

• 放置しても落ちない

• ブラックアウトしない

• ping が途切れない

• リモート接続が生き続ける

• 実験・検証を止めなくていい

これは 回避策ではなく、運用上の現実解です。

一言でまとめると

GPU keep-alive 常駐とは、
不安定な省電力復帰を「起こさせない」ための保険である

EC2-1からEC2-2のUDPトンネリングは、現時点で上手く動いていない。

WSL2（EC2-1）への映像転送・表示確認メモ（SRT版）

2026年1月2日

背景と動機

本メモは、RTSP／SRT を用いた映像転送系を、Windows 10 + WSL2 環境上で段階的に構築・検証する過程で得られた知見を整理することを目的として作成したものである。WSL2 が NAT 構成で動作することにより、LAN 上の別ホストから WSL2 へ UDP/SRT を直接到達させにくいという制約があり、Windows ホストを明示的な中継点として扱う構成に整理する必要があった。本メモは、SRT での転送と、WSL（EC2-1）側での映像表示が成立した最小構成を、今後の多段転送（EC2-1 → EC2-2）や実環境展開に再利用できる形で記録するものである。

1. 環境概要

ネットワーク構成

• 送信元（RTSP / mediamtx）

  • 192.168.0.23

• Windows ホスト（中継点）

  • 192.168.0.3

• WSL2（EC2-1）

  • eth0: 172.29.8.198

• OS / バージョン

  • Windows 10

  • WSL2（Ubuntu 24.04）

  • WSL バージョン: 2.6.3.0

前提条件

• mediamtx.exe は 192.168.0.23 上で起動済み

• RTSP は以下で配信中
  rtsp://127.0.0.1:8554/stream1

• WSL2 は NAT 構成（172.29.0.0/20）

2. 課題と結論

課題

• LAN 上の別ホスト（192.168.0.23）から、WSL2（EC2-1）へ直接 SRT（UDP）を到達させにくい

• 一方で Windows ホスト（192.168.0.3）は LAN と WSL2 の両方に接続点を持つ

原因

• WSL2 は Windows 内部 NAT 配下であり、LAN 側から WSL2 の listener へ直接到達する前提が成立しないケースがある

• そのため、SRT の受信点（listener）は Windows 側に置き、WSL 側へは caller で接続する構成が安定する

結論

• Windows ホスト（192.168.0.3）を明示的な中継点にする

• 構成は以下に固定する

192.168.0.23（RTSP）
   ↓ RTSP→SRT
192.168.0.3（Windows：SRT中継）
   ↓ SRT
172.29.8.198（EC2-1 / WSL：表示）

3. 今回確認したゴール

• SRT 経由で EC2-1（WSL）に映像を到達させ、EC2-1 で映像が表示されること
  → 成功

4. 実行コマンド（成功構成：SRT）

ポートは以下で統一する。

• Windows（中継）受信: 9999（listener）

• EC2-1（WSL）受信: 10000（listener）

4.1 EC2-1（WSL）側：SRT受信・映像表示（listener）

※ 先に起動して待ち受け

gst-launch-1.0 -v  srtsrc uri="srt://0.0.0.0:10000?mode=listener" !  tsdemux ! decodebin ! videoconvert ! autovideosink sync=false

要点：EC2-1 側は listener とし、Windows 側から caller で接続させる。

4.2 Windows ホスト（192.168.0.3）：SRT 中継（受信 listener → 再送 caller）

gst-launch-1.0 -v srtsrc uri="srt://0.0.0.0:9999?mode=listener" ! srtsink uri="srt://172.29.8.198:10000?mode=caller"

役割：

• 192.168.0.23 からの SRT を 9999 で受信（listener）

• EC2-1（172.29.8.198）の 10000 へ caller で接続して再送

4.3 送信側（192.168.0.23）：RTSP → SRT 送信

gst-launch-1.0 -v rtspsrc location="rtsp://127.0.0.1:8554/stream1" latency=0 !  rtph264depay ! h264parse ! mpegtsmux ! srtsink uri="srt://192.168.0.3:9999"

要点：RTSP（mediamtx）を受けて、MPEG-TS 化した上で SRT で Windows（192.168.0.3）へ送る。

5. 結果

• EC2-1（WSL）上で映像表示を確認

• 構成：

  • RTSP → SRT → Windows中継 → SRT → WSL

• ネットワーク経路・GStreamer パイプラインともに正常

6. 補足事項

• SRT は UDP 上で動作するため、疎通確認は UDP ポートで行う

  • Windows 側受信: UDP/9999

  • EC2-1 側受信: UDP/10000

• Windows Defender Firewall により、上記 UDP ポートが遮断される場合がある（必要に応じて許可ルールを追加する）

• 実通信に使用される WSL 側インタフェースは eth0（172.29.8.198）とする

7. 次のステップ（予定）

1. EC2-1 → EC2-2 の UDP / socat 転送確認（WSL 内部の 172.29.x.x 間で実施）

2. 制御系（戻り通信）の追加

3. ビットレート制御・制御パケット注入

昨日、
Yesterday,

まあ、この件については、色々議論して貰えば良いとは思いますが ―― 私は、私の母校となった大学で、勉学と研究に取り組んでいる留学生を守るためなら、何だってします。

という日記をアップしました。
I uploaded a diary entry titled the above.

私は、平時は自宅に閉じ籠って、せっせとプログラムかコラムを書いているので、あまり外出はしません。
In my daily life, I tend to stay shut inside my home, diligently writing programs or columns, so I rarely go out.

しかし、嫁さんや娘たちは、外に出て働いているので、多分、日本国内で働いている外国の人に接する機会が多いのだと思います。
However, my wife and daughter go out to work, so I assume they have far more opportunities to interact with foreigners working in Japan.

で、彼女らの話を聞いてみると、いわゆる新興の保守系政治団体と近い感想を持っていることが分かります。
And when I listen to what they have to say, I realize that their impressions are pretty close to those of so-called emerging conservative political groups.

---

彼女らの見解を一言でまとめると ――
To summarize their views in a single phrase

在留外国人の「文化的な振る舞いのギャップ」が、日常の中で無視できないレベルに達している、ということになります。
The "gap in cultural behavior" among resident foreigners has reached a level that cannot be ignored in everyday life.

はっきり言えば、「インモラルと受け取られてしまう行動が目に付く」という感覚です。
To put it plainly, it feels as though behaviors that are perceived as immoral are increasingly noticeable.

ここで言われているのは、宗教や価値観の違いといった抽象的な話ではありません。
What is being discussed here is not abstract differences in religion or values.

ゴミ出し、時間厳守、順番待ち、業務上の責任の所在、注意されたときの態度――ごく基礎的な社会的ルールの話です。
It concerns fundamental social rules: trash disposal, punctuality, waiting in line, responsibility in one’s work, and one’s attitude when corrected.

彼女らが強い違和感を覚えるのは、「知らなかった」「慣れていない」という段階を超えて、「分かっていて守らない」ように見える行動に遭遇したときらしいです。
What makes them feel intense discomfort, it seems, is encountering behavior that appears to go beyond "not knowing" or "not being accustomed" and instead looks like knowingly ignoring the rules.

どうも、昨日お話した、私の所属していた研究室の留学生たちとは、日本社会への適応意識や、自分が"客"であるという自覚の点で、次元が違うようです。
Apparently, this is on a different level from the international students in the lab I once belonged to, particularly in terms of their awareness of adapting to Japanese society and recognizing themselves as "guests."

---

実は、これ、高度成長時代、またはバブル期の日本人が、世界中で言われたことと、酷似しています。
In fact, this closely resembles what was said about Japanese people worldwide during the period of rapid economic growth or the bubble era.

当時、日本人は世界のあちこちで、似たような視線を向けられていました。
At that time, Japanese people were viewed in much the same way across the world.

経済力だけを武器に海外へ出て行き、その土地の文脈や空気を理解しないまま振る舞う存在としてです。
They were seen as people who went abroad armed only with economic power, behaving without understanding the local context or atmosphere.

象徴的なのが、いわゆる「売春ツアー」でした。
A symbolic example was the so-called "sex tours."

アジア諸国において、日本人男性が団体で訪れ、現地の貧困や制度の歪みの上に成立した性産業を、消費する側として無自覚に利用していた。
In various Asian countries, groups of Japanese men visited and unconsciously consumed sex industries that existed atop local poverty and distorted systems.

それは「合法か違法か」という線引き以前に、露骨なモラルの欠如として受け止められていました。
This was perceived as an overt lack of morality, even before questions of legality.

また、ブランド品の買い漁りも同様です。
The mass buying of luxury brands was similar.

免税店や高級ブティックで、行列を無視し、店員を呼びつけ、札束で順番をねじ曲げる。
At duty-free shops and high-end boutiques, they ignored lines, summoned clerks, and bent the order of things with bundles of cash.

当人たちは「金を払っているのだから問題ない」という感覚だったかもしれませんが、現地の人々には、露骨な傲慢さとして映っていました。
They themselves may have felt that paying money made it acceptable, but to locals, it appeared as blatant arrogance.

さらに言えば、レストランや公共の場での振る舞いもそうです。
The same applied to behavior in restaurants and public spaces.

大声で騒ぎ、空間の雰囲気を壊し、周囲の客や店の文化を意に介さない日本人観光客や駐在員は、決して珍しい存在ではありませんでした。
Japanese tourists or expatriates who spoke loudly, disrupted the atmosphere, and paid no heed to other patrons or the establishment's culture were by no means rare.

---

私は、『だから、在日／在留外国人や、インバウンド需要の外国人をおおめに見ろ（相殺しろ）』などという気は、サラサラありません。
I have absolutely no intention of saying, "Therefore, we should overlook or offset the behavior of resident foreigners or inbound tourists."

原則として、日本にいる以上、日本国の法律に従うことは当然として（この部分（法律）については、まだ顕著な問題にはなっていないと思っていますが）、日本での常識とされることに従うことは、"モラル"とか"道徳"とか"常識"とか、そういう言葉を使うまでもなく、
As a matter of principle, anyone in Japan must, of course, follow Japanese law (and in that regard, I believe there are not yet any conspicuous problems), and following what is regarded as standard practice in Japan does not even require invoking words like "morality," "ethics," or "common sense."

―― 双方が気持ち良く生きるための、必須ルール
it is an essential rule for both sides to live comfortably.

であるからこそ、そのルールを守らなければならないのです。
That is precisely why those rules must be observed.

---

ここからは個人的な所感ですが、日本人であれ、外国人であれ、「群れる奴らは、インモラルになりやすい」という傾向はあります。
From here on, this is my personal impression, but whether Japanese or foreign, people tend to become more immoral when they form groups.

一人で行動している時には、きちんとしているのに、群れになると、いきなり騒ぎ出したり、周囲に迷惑をかけたり、責任の所在を曖昧にするようになります。
When acting alone, they behave correctly, yet once in a group, they suddenly start making noise, causing trouble for others, and blurring responsibility.

これは、日本人には特に多かったかと思います（私は、一人で海外をさまよっていたことがあるので、こういう見苦しい日本人を沢山みる機会が多かったのです）。
I think this was particularly common among Japanese people (I once wandered abroad on my own, so I had many opportunities to see such unsightly Japanese behavior).

問題なのは国籍ではなく、「集団化することで、自分の行動に責任を持たなくなる構造」なのだと思います。
The problem is not nationality, but the structure that leads people to stop taking responsibility for their actions once they become part of a group.

どの国であれ、同じ言語が使えて、意思疎通ができて、それが集団化して、インモラルな振る舞いをしている他の国の人間たちは、その国にとって、十分な脅威です。
In any country, foreigners who share a language can communicate easily, form groups, and engage in immoral behavior, posing a sufficient threat to that society.

---

逆に、私のように、一人旅で現地を放浪していた人間に、他の国の人は、基本的に「優しい」です。
Conversely, people in other countries are generally "kind" to someone like me who wandered around alone as a solo traveler.

それは、私が生き残るためには「良い外国人を演じなければならなかった」ことと、「言葉も通じずに、一人で困っている外国人には、どの国の人間であれ、無碍（むげ）にはできない」という2つの特性が発揮される結果です。
This results from two factors: that I had to "play the role of a good foreigner" to survive, and that people of any nationality find it hard to be cruel to a foreigner who is alone, struggling, and unable to communicate.

で、まあ、思うわけです。
So, this is what I end up thinking.

―― 外国人であれ日本人であれ、他国にいるなら、まず一人の人間として振る舞え
Whether you are a foreigner or a Japanese person, if you are in another country, first act as an individual.

と。
That is.

もっとも、こういう一人が「怖くて」「不安で」「危険で」あることは分かっているのですが、群れることで、その国の国民から嫌われることになったら、だれも幸せにはなれないはずです。
Of course, I understand that being alone can be "frightening," "anxious," and "dangerous," but if forming groups leads to being disliked by the host country, no one can end up happy.

私、ここ3年間ほど社会人大学生として、大学に在籍していました。
For the past roughly 3 years, I have been enrolled at a university as a working adult student.

研究室の半分の学生が国際留学生でした。アジア（東南、中央、中東）の地域の学生が多く――確信を持って言えますが――基本的に勤勉で熱心な学生でした。
About half of the students in the laboratory were international students. Many were from Asia (Southeast Asia, Central Asia, and the Middle East), and I can say with confidence that, in general, they were diligent and highly motivated students.

彼らの多くは、JICA（国際協力機構）が関与する奨学・研修スキームを通じて日本にやってきて、都市工学や交通工学の勉学および研究に勤しんでいました。
Many of them came to Japan through scholarship and training programs funded by JICA (the Japan International Cooperation Agency) and devoted themselves to studying and researching urban and transportation engineering.

私が印象を受けたのは、研究室の教授陣の言葉でした。
What left a strong impression on me were the professors' words in the laboratory.

■留学生たちは、めちゃくちゃ熱心で、知識を吸収することに「ギラギラ」している点では、日本の学生の比ではないこと。
- The international students were highly enthusiastic; in terms of their “hunger” for absorbing knowledge, they were on a completely different level from Japanese students.

さらに、
Moreover,

■研究の目的が明確で、自分の国の課題を持ち込んで研究しているため、研究テーマがなかなか決まらない日本の学生とは異なる、という点です。
- Their research objectives were clear because they brought issues from their own countries into their research, which set them apart from many Japanese students who struggle to settle on a research topic.

私も、概ね同じ見解を持っていました。
I broadly shared the same view.

ゴミ問題、タイフーン災害、交通事故、渋滞、代替交通、人口爆発など、各国の課題が凝縮した問題のラインナップが並びます。
Issues such as waste management, typhoon disasters, traffic accidents, congestion, alternative transportation, and population explosion formed a lineup of problems that encapsulated the challenges faced by each country.

大学での全体ゼミ発表を聴講しているだけで、アジアの各国の問題が、各国の「点」ではなく、アジア全体の「面」として俯瞰できる、という印象を持ったものです。
By simply attending the university-wide seminar presentations, I felt I could view the issues of Asian countries not as isolated “points,” but as a broader “surface” spanning Asia as a whole.

---

いわゆる「JICA留学生」と呼ばれる学生たちは、開発途上国の政府職員・公共機関職員・大学教員・研究者など、すでに社会人経験を持ち、現在進行形で自国の課題と向き合っている人たちです。
The students commonly referred to as “JICA scholars” are individuals with professional experience, such as government officials, public-sector employees, university faculty members, and researchers from developing countries, who are actively confronting the issues facing their own nations.

専攻分野も、都市工学、交通工学、インフラ、環境、防災、公共政策などに集中しています。
Their fields of specialization are also concentrated in areas such as urban engineering, transportation engineering, infrastructure, environment, disaster prevention, and public policy.

プログラムにもよりますが、多くの場合、学費・渡航費・生活費相当はJICA側が支援し、目的は「個人の学位取得」そのものより、むしろ帰国後に母国の政策や実務へ還元することに置かれています。
Depending on the program, in many cases, tuition, travel expenses, and living costs are covered by JICA, and the objective is not so much on “obtaining a degree for personal advancement” as on contributing to policy and practice outcomes in their home countries after returning.

つまり、彼らは、「成果を母国に持ち帰ること」が強く期待された立場なのです。
In other words, they are in positions where they are strongly expected to deliver tangible outcomes for their home countries.

つまるところ、彼らは、少なくとも自国の行政や研究の中核を担うことが期待されている人材であり、将来的に国家運営に深く関わっていく存在なのだろう、という印象を持ちました。
Ultimately, I came away with the impression that they are individuals expected to play central roles in administration or research in their own countries, and to be deeply involved in national governance in the future.

---

そもそも、JICAという組織は、戦後の国際協力拡大の流れの中で、技術協力など複数の機能を統合する形で1974年に設立され、その後2008年に、より包括的な国際協力を担う組織として再編された政府機関です。
To begin with, JICA is a government agency established in 1974 amid the postwar expansion of international cooperation, integrating multiple functions, including technical cooperation, and was later reorganized in 2008 into an organization responsible for more comprehensive international cooperation.

その役割を、少し踏み込んで言えば、戦前／戦中に、我が国がアジア（主に東南アジア）に対して行ってきた、植民地支配や戦争行為、ならびに軍事的・政治的介入に対して、そのお詫びを、単なる損害賠償や謝罪だけでなく、「人材育成・制度構築・技術移転を通じて、相手国が自立的に発展できる基盤を作ること」で果たそうとする――そういう、ある種“上手い”装置なのだと思います。
If I may go a step further, I see its role as a kind of “clever” mechanism: an attempt to respond to Japan’s prewar and wartime colonial rule, acts of war, and military and political interventions in Asia (mainly Southeast Asia), not merely through compensation or apologies, but by contributing through human resource development, institution building, and technology transfer to create foundations for the partner countries’ self-reliant development.

ぶっちゃけて言えば、表向きは「善意の国際支援」ですが、裏側には「国際秩序の安定」と「日本自身の長期的利益」を同時に成立させようとする、かなり計算された国家戦略装置としての顔も持っている組織です。
To put it bluntly, while it presents itself outwardly as “goodwill-based international assistance,” it also has the face of a carefully calculated national strategic apparatus aimed at simultaneously maintaining international order and securing Japan’s own long-term interests.

---

昨年、JICAが発表した国際交流プロジェクト（いわゆる2025年の「JICAアフリカ・ホームタウン構想」）について、「移民政策ではないか」という誤解に基づく情報がSNSや一部報道で拡散し、国内で大きな混乱が生じました。
Last year, information based on the misunderstanding that an international exchange project announced by JICA (the so-called 2025 “JICA Africa Hometown Initiative”) was an immigration policy spread on social media and in some media outlets, causing significant confusion domestically.

私自身、日本は移民政策どころか、「外国人の労働力を吸い取った挙げ句、その後、国に半ば強制的に送り返す」という仕組みを長年続けてきた国だ、という内容のコラムを書いたこともあります。
I myself have previously written a column arguing that Japan, far from pursuing an immigration policy, has long maintained a system that absorbs foreign labor and then sends those workers back to their countries in a semi-coercive manner.

(↑Jump to the Column)

ですので、この話(「移民政策ではないか」)を聞いたとき、私は「あ、それは誤情報だ」と直感的に思いました。
When I heard about this, my immediate reaction was, “Ah, that’s misinformation.”

この保守的で排他的な我が国において、この段階で政府や地方自治体が移民政策のようなものを本気で実行できるとは、どう考えても思えなかったからです。
In a country as conservative and exclusionary as Japan, I could not imagine that the government or local authorities would seriously implement something like an immigration policy at this stage.

そして実際に、それは誤情報でした。
And in fact, it turned out to be misinformation.

ただ、この一件についてJICAは計画を取り消す判断を行いました。
Nevertheless, in this case, JICA decided to withdraw the plan.

そして、少なくとも私が確認できる範囲では、誤情報に基づいて騒ぎが拡大した側から、「明確な訂正」や「自己批判の声」は見当たりませんでした。
And at least within the scope of what I was able to confirm, there were no precise corrections or expressions of self-criticism from those who had amplified the uproar based on misinformation.

---

昨年の参政党の躍進を見ていると、日本人の「外国人」に対する見方が変わりつつあることを感じます。良し悪しは別として、少なくとも無関心ではいられなくなった、という点は確かです。
Looking at the recent surge in support for the Sanseito party last year, I feel that Japanese people’s views toward “foreigners” are changing. Whether this is good or bad is another matter, but it is clear that indifference is no longer an option.

ネガティブな面から言えば、生活が苦しくなったとき、人は分かりやすい原因を探しがちです。その矛先が「外国人」に向くと、本来向き合うべき、賃金や制度、行政の問題は置き去りになります。
From a negative perspective, when life becomes difficult, people tend to look for simple causes. When the blame is directed at “foreigners,” the issues that should really be addressed, wages, systems, and administration, are left aside.

感情的には理解しやすいですが、解決にはあまり役に立ちません ーー というか、正直、『日本国民も他の国と同じような考え方で、外国人を取り扱う(排除や排斥)のだなぁ』と、正直ガッカリしました。
Emotionally, this is easy to understand, but it does little to solve the problem. In fact, I was disappointed to realize that Japanese citizens, like those in many other countries, also tend to deal with foreigners through exclusion and rejection.

また、SNSでは正確さより「気持ちに合うかどうか」で情報が広がります。誤解や誇張が事実のように受け取られ、JICAの件のような混乱を招くこともあります。
Moreover, on social media, information spreads based on whether it “feels right” rather than whether it is accurate. Misunderstandings and exaggerations can be mistaken for facts, leading to confusion as seen in the JICA case.

一方で、ポジティブな面もあります。これまで曖昧にされてきた外国人受け入れの実態が、ようやく議論の対象になったことです。誰を、どんな目的で、どう受け入れるのか。責任は誰が持つのか。そうした当たり前の問いが、やっと表に出てきました。
On the other hand, there is also a positive aspect: the reality of accepting foreigners, which had long been left vague, has finally become a subject of discussion. Who should be accepted, for what purpose, and how? Who bears responsibility? These obvious questions have at last come to the surface.

この流れが排除に向かうのか、制度の整理に向かうのかは、これから次第です。感情で拒むのか、冷静に決めるのか。今、日本社会は、その分かれ道に立っているように思います。
Whether this trend leads toward exclusion or toward the orderly design of systems will depend on what happens next. Will decisions be driven by emotion, or made calmly? It seems to me that Japanese society is now standing at that crossroads.

---

まあ、この件については、色々議論して貰えば良いとは思いますが――
Well, I think people are free to debate this issue however they see fit.

私は、私の母校となった大学で、勉学と研究に取り組んでいる留学生を守るためなら、何だってします。
But if it comes to protecting international students who are studying and conducting research at the university that became my alma mater, I will do whatever it takes.

彼らの勉強と研究を邪魔するものであれば、ロジックを超えても闘う所存です。
If something interferes with their studies and research, I am prepared to fight it, even beyond the bounds of pure logic.

私のポリシーには反しますが、私の行動が「誤情報に基づいて、安直にデモに参加する程度の軽薄なロジック」を起動することになるとしても、私は、彼らの人生(の一部)を守る側に、必ず立ちます。
Even though this goes against my own policy, even if my actions end up triggering the same kind of shallow logic that leads people to join demonstrations based on misinformation, I will always stand on the side of protecting their lives, or at least a part of them.

『今回の選挙では、参政党という政党が躍進しました。彼らは簡単に「愛国心」という言葉を使い、正直、私は怖いです』とChatGPTに相談してみた件