未分類

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

2026,江端さんの忘備録

昨日、
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.

2026,江端さんの忘備録

私、ここ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に相談してみた件

未分類

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」
    の順で確認

 

未分類

wslでtsubame のdocker compose およびtsubame/src のserver.pyで支援頂きました。この環境を使って、これを外部(とりあえずLANに繋がったリモートマシンのブラウザからアクセスできるようにして下さい。

WSL 上の Web サーバ(tsubame)を LAN 内から公開する手順

前提

  • Windows + WSL2 環境

  • ~/tsubame/docker compose(DB 等)と
    ~/tsubame/src/server.py(HTTP サーバ)を WSL 上で稼働

  • 公開ポート:18080

  • 公開範囲:同一 LAN 内のみ


1. WSL 側:server.py を外部待受にする

WSL 内で、HTTP サーバが 0.0.0.0:18080 で待受するようにする。

Flask 例

if __name__ == "__main__":
app.run(host="0.0.0.0", port=18080)

起動:

python3 server.py

待受確認

ss -lntp | grep 18080

期待結果:

LISTEN ... 0.0.0.0:18080 ...

2. Windows 側:ファイアウォールで 18080/TCP を許可

管理者 PowerShell で実行。

New-NetFirewallRule `
-DisplayName "tsubame 18080" `
-Direction Inbound -Action Allow `
-Protocol TCP -LocalPort 18080 `
-Profile Any

3. Windows → WSL のポート転送(portproxy)を設定

WSL2 環境では自動転送されない場合があるため、明示的に設定する。

3.1 WSL の IP を確認

ip -4 addr show eth0 | grep inet

例:

172.29.11.141

3.2 portproxy を追加(管理者 PowerShell)

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

確認:

netsh interface portproxy show all

4. アクセス方法(これが正解)

LAN 内の別PCのブラウザから

http://<WindowsのLAN IP>:18080/

今回の環境では:

http://192.168.0.3:18080/

5. docker compose について

  • PostgreSQL 等の 内部サービスは LAN 公開不要

  • server.py が WSL 内 DB に接続できていれば OK

  • docker compose 側のポート公開設定は不要


全体構成(最終形)

別PCブラウザ

Windows (192.168.0.3:18080)
↓ portproxy
WSL (172.29.x.x:18080)

server.py

docker compose(DB 等)

まとめ(要点だけ)

  • WSL の Web サーバは 0.0.0.0 で待受

  • LAN 公開の入口は Windows の IP

  • WSL2 では portproxy を使うのが確実

  • netsh必ず Windows の管理者 PowerShell で実行


HTTPS 化の最終手順(mkcert+nginx+Windows/WSL 構成)

1. mkcert によるサーバ証明書の作成(Windows)

本環境では、mkcert は以下の実行ファイルを直接使用している。

C:\Users\tomoi\Downloads\mkcert-v1.4.1-windows-amd64.exe

証明書は、IP アドレス・localhost・loopback を SAN に含めて生成する。

cd C:\Users\tomoi\Downloads
.\mkcert-v1.4.1-windows-amd64.exe 192.168.0.3 localhost 127.0.0.1 ::1
生成されるファイルは以下の 2 つである。
192.168.0.3+3.pem
192.168.0.3+3-key.pem
この証明書には、SAN として以下が含まれている。
DNS:localhost
IP Address:192.168.0.3
IP Address:127.0.0.1
IP Address:::1

2. 証明書を WSL(nginx)側へ配置

WSL(Ubuntu)上で、nginx 用のディレクトリを作成し、Windows 側から証明書をコピーする。

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

3. nginx 設定(192.168.0.3 用 HTTPS)

設定ファイル名は IP アドレスで統一する。

/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;
    }
}

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

有効化と反映。

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

sudo nginx -t
sudo systemctl reload nginx

4. Windows → WSL への 443 番ポート転送

PowerShell を 管理者権限で実行する。

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

併せてファイアウォールを許可する。

netsh advfirewall firewall add rule name="Allow HTTPS 443" `
  dir=in action=allow protocol=TCP localport=443

172.29.11.141 は WSL 側の eth0 の IP。


クライアント側(LAN 内 PC)の信頼設定


5. mkcert CA の実体(あなたの環境)

mkcert が使用している CA の実体ディレクトリは以下である。

C:\Users\tomoi\AppData\Local\mkcert

この中にある

rootCA.pem

を、HTTPS アクセスを行うクライアント PC(例:192.168.0.25)へコピーする。


6. クライアント PC(Windows 11)への CA インストール

重要:必ず「ローカル コンピューター」ストアに入れる。

  1. Win + R

  2. certlm.msc を実行

  3. 信頼されたルート証明機関
    └ 証明書
  4. 右クリック →「証明書のインストール」

  5. ローカル コンピューター

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

  7. 完了(UAC は許可)

certmgr.msc(現在のユーザー) では Chrome/Edge に効かない点に注意。


7. ブラウザ再起動と確認

Chrome / Edge を完全終了(タスクマネージャでプロセス消滅を確認)後、再起動。

https://192.168.0.3

🔒 鍵アイコンが表示され、
「信頼されていない通信」は解消される。


まとめ

  • mkcert による SAN 付き証明書生成

  • nginx による TLS 終端

  • Windows → WSL の 443 転送

  • ローカル コンピューター証明書ストアへの CA 登録

この 4 点が揃うことで、
LAN 内 IP アドレス指定でも、警告なしの HTTPS が成立する。