未分類

結論から先に言うと『MATSimは歩行のルート再現をしてくれず、私の博士論文の研究"共時空間、RCM"には直接使えん、ということが、本日判明』

(歩行は、交通全体から見ると、"瑣末"なものなので、MATSimのターゲットではないんだ、とか)

# 正確に言うと、歩行ルートも計算しているそうだが、それを出力する機能がないんだとか (『オプションメニューで、歩行軌跡も出力できるように作っておけよ』と腹を立てています)

ODと経過時間は分かっているのだから、そこはお前がローカルで経路計算しろ?』ということらしいが ーー
そんな面倒くさいことさせるなーーー! 

問題意識(出発点)

  • MATSim を用いてエージェントシミュレーションを実施。

  • <leg mode="car"> では LinkEnter/Leave が出力され、軌跡(リンク列)が復元可能。

  • <leg mode="walk"> では departure / arrival / travelled は出るが、LinkEnter/Leave が一切出ない。

  • その結果、歩行エージェントの軌跡が可視化できず、接触(出会い)解析が不可能に見える。


2. 技術的事実の整理(MATSimの挙動)

2.1 walk は「動いていない」のではない

  • walk モードでも以下は正しく出力される:

    • 歩行開始:PersonDepartureEvent (legMode=walk)

    • 歩行終了:PersonArrivalEvent (legMode=walk)

    • 距離:TravelledEvent (mode=walk, distance=…)

  • 歩行時間は
    arrival.time − departure.time
    として明確に算出可能。

walk はシミュレーションされていないのではなく、「逐次シミュレーションされていない」


2.2 MATSim における移動の2レイヤ構造

MATSim には移動に関する2つの処理段階がある。

  1. ルーティング(plans / routing)

    • 出発リンク → 到着リンク

    • ネットワーク上で最短経路探索

    • 距離・所要時間を計算

  2. 逐次シミュレーション(QSim / mobsim)

    • リンクに入る・出る

    • 渋滞・相互干渉

    • LinkEnter / LinkLeave イベント生成

car / pt
→ 1 + 2 の両方を実施
walk(デフォルト)
→ 1 のみ実施、2 は実施しない(teleported leg)


2.3 「テレポート」の正確な意味

  • teleported = 瞬間移動ではない

  • ルーティングは実施する

  • ただし、リンク単位の逐次挙動を保持・出力しない

つまり、

  • 歩行ルートは内部的には計算されている

  • しかし リンク列として保存されず、events にも出ない


3. なぜ歩行時間は「正確」に出るのか

  • walk の所要時間は

    • network.xml 上で最短経路探索

    • リンク長合計 ÷ 歩行速度
      により算出されている。

  • 「ルートを調べずに時間を出している」のではなく、
    「調べたが、結果(経路)を捨てている」


4. 徒歩→バス→徒歩はどう出力されるか

4.1 徒歩区間

  • departure / arrival / travelled のみ

  • 途中経路は存在しない

4.2 バス区間

  • 車両(vehicle)がネットワークを走行

  • vehicle に対して LinkEnter / LinkLeave が出力

  • person は PersonEntersVehicle / LeavesVehicle で紐づく

events には「バスの軌跡」はあるが「徒歩の軌跡」はない


5. 研究上の重大な問題点

5.1 接触・出会い解析が不可能

  • エージェント同士の出会いには、

    • 同じリンク

    • 同じ時間帯
      の情報が必要。

  • walk ではリンク列が出ないため、
    歩行中の共時空間・接触が定義不能


5.2 後処理での経路再計算の問題

  • departure / arrival から最短経路を再計算すれば、
    MATSim と同一の経路になる理屈ではある。

  • しかし、

    • 本当に同じアルゴリズムか?

    • tie-break や実装差はないか?
      という 再現性・保証の問題が残る。


6. なぜ MATSim は経路を保存しないのか(設計思想)

  • MATSim は本来、

    • 交通需要

    • 混雑

    • 政策評価
      を目的とした MAS。

  • 都市スケールで数十万〜数百万人を扱うため、

    • 全 walk 経路保存はメモリ・容量的に非現実的。

  • そのため、

    歩行の詳細な空間挙動は捨象する
    という設計判断がなされている。


7. 評価と所感(研究者視点)

  • ODを完全に算出しない MAS に、接触解析の観点で意味はあるのか?
    → 交通政策評価には意味がある。
    → 出会い・共時空間解析には不十分。

  • 「スケーラビリティのために経路を捨てる」という説明は、
    研究目的によっては 逃げ・卑怯に見える

  • 結論として、

    MATSim は接触機会・出会いを一次情報として扱う研究には、そのままでは使えない


8. 現実的な選択肢

  1. MATSimを使わない

    • 自前 MAS

    • 経路・接触を一次情報として設計

  2. MATSimを割り切って使う

    • 時間構造・OD生成器として使用

    • 空間経路・接触は別エンジンで再構成

    • 限界を論文中で明示

  3. MATSim拡張

    • walk を network mobsim に載せる

    • 実装負荷大だが独創性は高い


9. 最終的な整理

  • MATSimは「使えない」のではなく、
    研究対象に対して抽象化レベルが合っていない

  • あなたの研究テーマ(共移動・共滞在・出会い)は、
    MATSimの想定用途を明確に超えている

  • その違和感は、技術的にも学術的にも正当。


※このメモは、そのまま

  • 研究ノート

  • 博士論文の「関連研究・手法選定の限界」節

  • 指導教員への説明資料

として使用可能です。

未分類

<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 重要なポイント(研究用途的に)

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

  • しかし:

    • 後処理

    • 可視化

    • フィルタリング

    • 分析(例: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

意味:

  • 混雑していないときの理論最大速度

  • MATSim の travel time 計算に直接使われる


3.5 capacity="1000.0"

  • リンク容量 [veh/hour]

  • 1時間あたりに流せる車両数の目安

注意:

  • 現実の道路容量の厳密再現ではない

  • MATSim の渋滞生成モデル用のパラメータ


3.6 permlanes="1.0"

  • 車線数

  • 実数なのは MATSim の内部仕様

意味:

  • 容量計算や queue spillback に影響

  • ただし capacity の方が効くことが多い


3.7 oneway="1"

  • 一方通行

  • 1 = true

  • 0 = 双方向(※ 双方向の場合は逆向き link も生成される)

OSM の oneway=yes を反映


3.8 modes="car"

  • このリンクを通行可能な交通手段

  • 今回は --modes car で生成したため car のみ

他の例:

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" />

つまり:

視点 意味
現実世界 双方向道路
MATSim network 有向リンク2本
各 link 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 が含まれるリンクしか通れない

つまり:

エージェントの mode link の modes 通れる?
car car
walk car
walk walk
walk car,walk

👉 歩行をさせるには、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 を作るためだけの専用工具」

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

 

未分類

\\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 放置中フリーズ対策・検証メモ

 

未分類

これまで、私、「出世」したり、「上長」になることの意義が、さっぱり分からない、と、何度か記載してきたのですが、
Up to now, I have described it several times, but I do not fully understand the significance of becoming a "career advance" or becoming a "superior". However, I could appreciate the importance last night from the bottom of my heart.

昨夜見た、
after watching the TV program,

「NHKスペシャル インパール作戦」
NHK Special "Battle of Imphal"

で、ようやく肚に落ちました。

------

In this program, the new memo has been released,
―― 雨が降りしきり、道行く先には腐敗が進む死体の山

- It is raining, and there are enormous corrupt dead bodies on the load.
―― 死んでるのは兵士や軍属ばかり

- the dead bodies are only soldiers and warriors
―― 将校と下士官は死んでいない

- Officers and noncommissioned officers are not dead
という、新しいメモが、今回、公開されました。

-----

なるほど、
I see. It means,

『"部下"のほとんどが餓死している真っ最中にあって、"上司"には食事が与えられ、食べることができる』
"When most of subordinates are in the midst of starvation, all bosses are given meals and they can eat them"

ということです。

なるほど、これは凄い。色々と凄い
Well, this is amazing for several meanings.

―― 「出世」とか「上司」には、死んでも構わない人間と、そうでない人間を、区別しうるという概念が、内挿されているのだ、と。
"Promotion" and "boss" include the concept of distinguishing between persons who have no problem to be killed, and persons who don't that.

「付託エキスパート」である私であっても、さすがに「命」までは差し出せない。
Even if I am a "commitment expert", I have no intention to give my life to a boss."

-----

心の底から『出世しなければ』という想いと、『もう手遅れだ』と悔悟する想いが錯綜する、終戦記念日の夜でした。
It was a night of the end of war anniversary, to get confused two feelings that "I have to promote" from the bottom of my heart, and "it is too late" with regrets.

未分類

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 詳細なし)

設定した項目

Advanced
└ AMD CBS
└ CPU Common Options
項目 設定
Global C-State Control Disabled
ACPI _CST C1 Declaration Enabled

意味

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

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


3. Windows 11 側対策(必須)

電源設定

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

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

  • スリープ:無効

  • 高速スタートアップ:無効(確認済み)

確認場所

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

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


4. GStreamer 環境確認

使用環境

  • GStreamer 1.26.10

  • MSVC x86_64

  • PATH 混在なし

C:\Program Files\gstreamer\1.0\msvc_x86_64\bin

VAAPI 状況

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

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


5. GStreamer による検証結果

表示のみテスト(安定)

gst-launch-1.0 -v videotestsrc ! videoconvert ! d3d11videosink
gst-launch-1.0 -v videotestsrc ! videoconvert ! glimagesink

両方とも安定

デコード+表示(実ファイル)

gst-launch-1.0 -v filesrc location="video1.mp4" ! decodebin ! videoconvert ! d3d11videosink

正常再生

長時間相当テスト(sync無効)

gst-launch-1.0 -v videotestsrc is-live=true ! videoconvert ! d3d11videosink sync=false

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

結論

  • GStreamer実行中は落ちない

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


6. 最終結論(重要)

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

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

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


7. 実運用向け最終対策(推奨)

keep-alive(最小・確実)

方法A:GStreamer keep-alive(推奨)

gst-launch-1.0 -q videotestsrc is-live=true ! fakesink
  • 表示なし

  • 極小負荷

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

方法B:Windows汎用 keep-alive

@echo off
:loop
ping -n 60 127.0.0.1 > nul
goto loop

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


8. 運用方針まとめ

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

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

  • ❌ ハード故障ではない

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

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


【必須】① TDR(GPUリセット)無効化

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

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

質問

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

reg add "HKLM\SYSTEM\CurrentControlSet\Control\GraphicsDrivers" /v TdrLevel /t REG_DWORD /d 0 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\GraphicsDrivers" /v TdrDelay /t REG_DWORD /d 60 /f
  • 実行済み / 未実行

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

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


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

これも 最終形にします。

実運用用 keep-alive(これを基準に)

gst-launch-1.0 -q ^
videotestsrc is-live=true pattern=ball ^
! videoconvert ^
! d3d11videosink sync=false
  • 起動したら 最小化

  • 作業中も 終了しない

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


ここからの判断基準(重要)

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

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

  • ✖ まだ落ちる
    電源(ACアダプタ / VRM)起因

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

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


正直な話(隠しません)

ここまで切り分けて:

  • GStreamer ❌

  • Windows設定 ❌

  • GPUドライバ設定 ❌

  • ユーザ操作 ❌

が全部消えました。

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

TDR 無効化の確認方法(確実)

方法①:PowerShell で確認(最も確実)

手順

  1. スタート

  2. PowerShell を右クリック

  3. 管理者として実行

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

reg query "HKLM\SYSTEM\CurrentControlSet\Control\GraphicsDrivers"

確認ポイント(ここが重要)

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

正常(TDR 無効化済み)の場合

TdrLevel REG_DWORD 0x0
TdrDelay REG_DWORD 0x3c
  • TdrLevel = 0x0TDR 無効

  • TdrDelay = 0x3c60秒(10進数で60)

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


未設定 or 無効の場合

  • TdrLevel表示されない

  • または

  • TdrLevel REG_DWORD 0x3

などの場合

👉 未実行 or TDR 有効のまま


方法②:レジストリエディタで確認(GUI)

手順

  1. Win + R

  2. regedit → Enter

  3. 以下へ移動:

HKEY_LOCAL_MACHINE
└ SYSTEM
└ CurrentControlSet
└ Control
└ GraphicsDrivers

右ペインを確認

  • TdrLevel

  • TdrDelay

が存在するかを確認。

値の意味

  • TdrLevel = 0 → 無効

  • TdrDelay = 60 → OK


注意点(重要)

  • 設定しただけではダメ

  • 必ず再起動が必要

再起動前は、

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


次のアクション(これだけ)

  1. 上記どちらかで確認

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

例:

  • TdrLevel = 0x0, TdrDelay = 0x3c

  • TdrLevel が存在しない

  • TdrLevel = 0x3

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

確認結果の評価(確定)

TdrLevel REG_DWORD 0x0
TdrDelay REG_DWORD 0x3c

これは何を意味するか

  • TdrLevel = 0x0

    • ✅ GPU TDR(自動リセット)完全無効

  • TdrDelay = 0x3c(60秒)

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

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


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

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

  • ❌ GStreamer

  • ❌ GPU ドライバの TDR

  • ❌ Windows 電源管理

  • ❌ Radeon Software 設定

  • ❌ C-State / OS 省電力

  • ❌ ユーザー操作ミス

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

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

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

gst-launch-1.0 -q ^
videotestsrc is-live=true pattern=ball ^
! videoconvert ^
! d3d11videosink sync=false

運用ルール

  • 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

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

Set shell = CreateObject("WScript.Shell")
shell.Run """C:\scripts\gpu_keepalive.bat""", 0, False

重要ポイント

  • 0完全非表示

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

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


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

いまの状態を見ると:

❌ 起動対象

C:\scrips\gpu_keepalive.bat

になっています(しかも綴りも間違い)。

「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 パイプラインは:

videotestsrc
→ d3d11upload
→ d3d11download
→ fakesink

これが意味することは:

  • 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. ビットレート制御・制御パケット注入

未分類

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

今朝から実験コマンドを変えて、4時間のロングランのテストを実施中 ーー システムダウンは現時点で確認されなくなりました ーー ああ、よかった。

「根本的に直す」は可能か?

正直に言います。

❌ 完全な根治(BIOS更新で解決)は 難しい

  • HM90 の OEM BIOS は

    • ACPI / SoC / GPU 電源制御がブラックボックス

  • Windows 11 + Vega 世代 iGPU の組み合わせは

    • アイドル遷移不具合が 構造的に残りやすい

👉 設計上の限界に近い

今さらそんなこと言われてもなあ ーー まあ、大学入学前に購入して、Windows11との端境(はざかい)期だったとは言え、ちょっとついてなかったかなぁ。

-----

ロングランの時間中、リハビリのウォーキングをしていました(パソコンの前にいると、色々手を出しそうになるから)。

本を読みながらのウェーキングは、結構長いこと歩けます。

一気に読み切りました。非常に興味深い1冊でした。

冒頭のフレーズ、

―― あのソ連(ソビエト社会主義連邦共和国)すら潰れたのに、何で北(朝鮮民主主義人民共和国)は、まだ延命しているのか?

に、衝撃を受けました。

この素朴で完結な疑問に、私は、私なりのやり方で、ちゃんと立ち向かってみたいと思います。

未分類

了解しました。
以下は ご提示の
https://wp.kobore.net/2025/12/28/post-23393/

前提知識として固定し、その上で

EC2-2(WSL2 上)で動いている Web サービスを、
同一 LAN 内の他ホストから
https://192.168.0.3/ で安定的にアクセス可能にするための実運用メモ

を、抜け・省略なし/再現可能/将来読み返しても壊さない形でまとめます。

(※「なぜその手順が必要か」もすべて明示します)


EC2-2(WSL2)を LAN 内から

https://192.168.0.3/ で公開するための確定メモ


0. ゴールと非ゴール

ゴール

  • 同一 LAN 内の別 PC から
    https://192.168.0.3/
    にアクセスできる

  • 証明書警告なし(🔒表示)

  • Windows / WSL 再起動後も 復旧可能

非ゴール(今回はやらない)

  • インターネット公開

  • EC2(AWS)移行

  • 認証・WAF 等の高度な公開制御


1. 全体構成(完成形)

[LAN 内の別PC ブラウザ]
        |
        | https://192.168.0.3
        v
[Windows ホスト]
  443 / 80
        |
        | portproxy
        v
[WSL2: ubuntu-ec2-2]
  nginx (TLS終端)
        |
        | http://127.0.0.1:18080
        v
[docker compose]
  reverse-proxy (18080)
        |
        +--> api (FastAPI)
        +--> EC2-1 media (HLS / thumbs)

2. 前提条件(成立していること)

Windows 側

  • Windows 11

  • LAN IP が 192.168.0.3

  • mkcert により証明書作成済み

  • rootCA.pem を ローカルコンピューターにインストール済み

WSL 側

  • WSL2 使用

  • 対象ディストリビューション:
    ubuntu-ec2-2

  • docker / docker compose 稼働

  • http://localhost:18080/
    Windows からは表示できている


3. mkcert による証明書(既存前提の整理)

3.1 作成済み証明書

mkcert 192.168.0.3 localhost 127.0.0.1 ::1

生成物:

  • 192.168.0.3+3.pem

  • 192.168.0.3+3-key.pem

SAN 含有:

  • IP: 192.168.0.3

  • localhost

  • 127.0.0.1

  • ::1

LAN IP 直接指定に完全対応


4. 証明書を ubuntu-ec2-2 に配置

(※ 既定 Ubuntu ではなく ubuntu-ec2-2

wsl -d ubuntu-ec2-2
sudo mkdir -p /etc/nginx/ssl/192.168.0.3

sudo cp /mnt/c/Users/tomoi/Downloads/192.168.0.3+3.pem \
        /etc/nginx/ssl/192.168.0.3/cert.pem

sudo cp /mnt/c/Users/tomoi/Downloads/192.168.0.3+3-key.pem \
        /etc/nginx/ssl/192.168.0.3/key.pem

sudo chmod 644 /etc/nginx/ssl/192.168.0.3/cert.pem
sudo chmod 600 /etc/nginx/ssl/192.168.0.3/key.pem

5. ubuntu-ec2-2 に nginx を導入・常駐化

sudo apt update
sudo apt install -y nginx
sudo systemctl enable nginx

6. nginx(TLS 終端)設定

6.1 設定ファイル作成

/etc/nginx/sites-available/192.168.0.3.conf

server {
    listen 443 ssl;
    server_name 192.168.0.3;

    ssl_certificate     /etc/nginx/ssl/192.168.0.3/cert.pem;
    ssl_certificate_key /etc/nginx/ssl/192.168.0.3/key.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;

    location / {
        proxy_pass http://127.0.0.1:18080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
    }
}

server {
    listen 80;
    server_name 192.168.0.3;
    return 301 https://$host$request_uri;
}

6.2 有効化

sudo ln -sf /etc/nginx/sites-available/192.168.0.3.conf \
           /etc/nginx/sites-enabled/

sudo nginx -t
sudo systemctl restart nginx

7. Windows → WSL の portproxy 設定

7.1 ubuntu-ec2-2 の IP を取得

wsl -d ubuntu-ec2-2 -- hostname -I

例:

172.29.11.141

7.2 portproxy 設定(管理者 PowerShell)

netsh interface portproxy delete v4tov4 listenaddress=0.0.0.0 listenport=443
netsh interface portproxy delete v4tov4 listenaddress=0.0.0.0 listenport=80

netsh interface portproxy add v4tov4 `
  listenaddress=0.0.0.0 listenport=443 `
  connectaddress=172.29.11.141 connectport=443

netsh interface portproxy add v4tov4 `
  listenaddress=0.0.0.0 listenport=80 `
  connectaddress=172.29.11.141 connectport=80

確認:

netsh interface portproxy show all

8. Windows ファイアウォール

New-NetFirewallRule -DisplayName "Allow HTTPS 443" `
  -Direction Inbound -Action Allow -Protocol TCP -LocalPort 443 -Profile Any

New-NetFirewallRule -DisplayName "Allow HTTP 80" `
  -Direction Inbound -Action Allow -Protocol TCP -LocalPort 80 -Profile Any

9. LAN 内クライアント側(重要)

CA インストール(1回だけ)

  • rootCA.pem をクライアントにコピー

  • certlm.msc

  • ローカル コンピューター

  • 信頼されたルート証明機関

certmgr.msc(現在のユーザー)では不可


10. 動作確認

ubuntu-ec2-2 内

curl -kI https://127.0.0.1/

Windows 自身

https://192.168.0.3/

LAN 内別 PC

https://192.168.0.3/

🔒 が表示されれば成功。


11. よく壊れる原因(実体験ベース)

原因 症状
WSL IP 変更 無言で https が死ぬ
portproxy が旧IP curl が通らない
nginx が別ディストリ 設定が反映されない
CA を Current User に入れた Chrome/Edge が警告

12. 固定化(強く推奨)

WSL IP 変動対策

PowerShell スクリプト:

# C:\scripts\wsl_https_fix.ps1
netsh interface portproxy delete v4tov4 listenaddress=0.0.0.0 listenport=443
netsh interface portproxy delete v4tov4 listenaddress=0.0.0.0 listenport=80

$wsl_ip = wsl -d ubuntu-ec2-2 -- hostname -I
$wsl_ip = $wsl_ip.Trim().Split(" ")[0]

netsh interface portproxy add v4tov4 `
  listenaddress=0.0.0.0 listenport=443 `
  connectaddress=$wsl_ip connectport=443

netsh interface portproxy add v4tov4 `
  listenaddress=0.0.0.0 listenport=80 `
  connectaddress=$wsl_ip connectport=80
タスクスケジューラ:
  • システム起動時

  • 最上位権限


13. 最終まとめ(要点だけ)

  • 入口は https://192.168.0.3/

  • TLS 終端は ubuntu-ec2-2 の nginx

  • Windows は単なる 転送役

  • mkcert / CA は 一度入れたら触らない

  • 壊れたら
    「WSL IP → portproxy → nginx」
    の順で確認