未分類

インパール作戦とは、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」
    の順で確認

 

未分類

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 が成立する。

未分類

以前、こんな日記を書いたことがあります。

記事だけで新聞を判別できるか

これをChatGPTに読ませて批評させたら、「やや一面的で雑然としているということも否めません」と言われたので、『じゃあ、お前(ChatGPT)が書いてみろ』と言ったら、以下のようなものを出してきました。

あなただったら、このコラムの内容をどのようにリライトしますか? 新聞ごとに私のやったような特徴付けをして下さい

 

了解しました。
ここでは 「私がこのコラムを書き直すなら」 という立場で、あなたの元の観察姿勢(直感的・皮肉・新聞文化への距離感)を維持したまま、構成と表現を整理し、かつ 新聞社ごとの特徴付けをより明確にしたリライト案を示します。

※「正しさ」よりも「読み物としての切れ味」「個人コラムとしての納得感」を優先しています。


リライト方針(前提)

  • 統計・検証はしない

  • あくまで「長年読んできた人間の体感」に基づく

  • 評価軸は 文体・語尾・読者への姿勢

  • 各新聞を「人格」に見立てる


リライト案(本文)

見出し

記事を読めば、どの新聞かはだいたい分かる


新聞というのは不思議なもので、
社名を伏せられても、記事を数行読めば「どこだな」と分かってしまう。

主張の内容ではない。
書いてある事実でもない。
決定的なのは、語尾と態度だ。

以下は、私が長年新聞を読んできて身についた、
いわば「文体による新聞判別法」である。


読売新聞

「だから、こうすべきだ」型

読売の記事は、結論が早い。
そして迷いがない。

○○は問題である。
政府は速やかに対応すべきだ。

という調子で、
「正解はこれだ」 と教えてくる。

教科書というより、
学級委員長の意見書に近い。

読者に考えさせるというより、
「まあ、そうだよな」と頷かせにくる新聞である。


朝日新聞

「我々はどう考えるべきか」型

朝日は、とにかく問いかける。

○○という現実を、
私たちはどう受け止めるべきなのだろうか。

事実は書く。
ただし、結論は読者に委ねる

いや、正確には
「委ねているように見せて、方向は示している」。

倫理・理念・歴史を背負った
道徳の先生のような新聞だ。


毎日新聞

「現場の声を聞いてみよう」型

毎日は、少し距離が近い。

取材した○○さんは、こう語った。

人の顔が出てくる。
生活感がある。

大きな主張は控えめで、
「まあ、現場はこうですよ」 という立ち位置。

新聞というより、
真面目な週刊誌に一番近い。


日本経済新聞

「数字がすべて」型

日経は感情を排する。

市場は△%反応した。
○○社の株価は××円。

倫理も正義もほとんど出てこない。
あるのは 数字と因果関係 だけ。

人間臭さを求めると裏切られるが、
経済という無慈悲な現実は一番よく分かる。


産経新聞

「言いたいことははっきり言う」型

産経は、感情を隠さない。

看過できない。
断じて容認できない。

語気が強く、
敵と味方がはっきりしている。

論調は一貫しており、
ブレない代わりに、揺れもしない

読み手を選ぶが、
姿勢は最も分かりやすい。


赤旗

「構造が悪い」型

赤旗は、必ず構造に行き着く。

問題の背景には、
資本主義の矛盾がある。

個別の事件は、
常にシステムの問題として語られる。

好き嫌いは分かれるが、
論理の首尾は一貫している。


聖教新聞

「人は変われる」型

聖教は、語調が柔らかい。

希望を持ちたい。
明日はきっと良くなる。

政治記事でさえ、
最終的には人の成長に着地する。

新聞というより、
人生相談欄が拡張された媒体である。


結び

こうして見ると、
新聞は「事実を伝える装置」ではなく、
世界の見方を提供する文体だと分かる。

どれが正しいかではない。
どの眼鏡で世界を見るかの違いである。

そして怖いことに、
毎日読んでいると、
その眼鏡が「自分の視力」だと思い込んでしまう。

だから私は、
新聞を読むとき、
まず語尾を見ることにしている。


コメント(なぜこうリライトしたか)

  • 元コラムの「直感的分類」を
    人格・態度の違いとして明確化

  • 揶揄ではなく
    距離を取った観察者の皮肉に寄せた

  • 「どれも一理ある」構図にして
    → 読者が自分の立ち位置を考えられるようにした

前進(中核派機関紙)とか、解放(革マル派機関誌)もお願いします。

了解しました。
では、先ほどのリライト案に自然に接続する形で、
**前進(中核派機関紙)/解放(革マル派機関誌)**を同じ作法――
「文体・語尾・世界の切り取り方=人格」――で書き足します。

※あくまで個人コラムとしての観察であり、思想の正誤判定はしません。


追補リライト(追加分)


前進(中核派)

「情勢は革命を要請している」型

前進は、とにかく世界が常に臨界状態にある。

情勢は新たな段階に突入した。
今こそ決起の時である。

昨日も今日も、
そしておそらく明日も、
**「歴史の分岐点」**にいる。

語彙は硬く、熱量は高い。
感情というより、使命感で書かれている。

個人はほとんど出てこない。
出てくるのは「労働者階級」「大衆」「闘争」だ。

新聞というより、
永遠に続く作戦会議の議事録である。


解放(革マル派)

「敵の本質を暴露する」型

解放は、まず敵を定義する。

これは偶然ではない。
敵の戦略的意図によるものである。

陰謀論、ではない。
全てが計画的だと仮定して世界を見る

前進が「行け」と叫ぶなら、
解放は「なぜそうなったか」を延々と説明する。

文章は長く、
一文が重い。

読み終える頃には、
読者は世界を信頼する能力をかなり削られる

新聞というより、
疑念を訓練するための教材に近い。


ここまで含めた全体像(整理)

この二紙を加えると、新聞・機関紙は
次の軸で綺麗に並ぶ

位置
結論を出す 読売・産経・前進
問いを投げる 朝日
現場を見る 毎日
数字を見る 日経
構造を見る 赤旗
意味を見る 聖教
敵を定義する 解放
行動を要請する 前進

コラムとしての「落ち」

この2紙を並べたことで、
最初の問い――

記事だけで新聞を判別できるか

は、ほぼ YES になる。

なぜなら、
事実は同じでも、

  • 誰に怒れと言われるか

  • 何を信じろと言われるか

  • いつ行動せよと言われるか

が、文体にすべて出ているからだ。

新聞とは、
情報ではなく
世界との向き合い方の訓練装置なのだと思う。


補足的に言うと(個人コラムらしく)

前進と解放を
「極端だから特別」と切り分けるのは簡単だが、
実は他の新聞も、
その方向性を弱めた同型に過ぎない。

違いは、

  • 自覚しているか

  • 無自覚か

それだけだ。

未分類

年末の換気扇の掃除は、憂鬱でした。

私は、換気扇を分解して、屋外にもっていて、石油を使って洗い流すことにしていたのですが、石油の匂いは臭いし、外は寒いし、手は冷たいしで ーー まあ、結構辛い作業だったのです。

嫁さんに相談したところ、嫁さんが、いわゆる「大掃除用の各種の物品」を購入していたので、それを試してみました。

―― びっくりしました

洗剤でも灯油でも落ちなかった10数年来の油汚れが、嘘のように落ちました。

50~60度の温度のお湯に溶かした溶液に、換気扇のパーツを突っ込んで、2時間くらい放置しておいたら、水が真っ黒になって、ブラシで擦ったらボロボロと油の塊が剥れていいました。

この「セスキ」とは何だ? と、思い調べてみました。

=====

この「セキス」とは何ですか?

写真の「セキス」は、**「セスキ(炭酸)」**のことで、正式には セスキ炭酸ソーダ(英:sodium sesquicarbonate)を指します。

セスキ炭酸ソーダとは

  • 弱アルカリ性の洗浄剤

  • 炭酸ナトリウム(ソーダ灰)と重曹の中間的な性質

  • 合成界面活性剤を含まない、比較的安全性の高い洗剤

何に使うものか

  • 油汚れ(換気扇、グリル、フライパン、写真のような金属フィルター)

  • 皮脂汚れ・手垢

  • 軽い焦げ付き

  • 消臭(生ゴミ周り、布製品など)

写真では、換気扇やレンジフードの油汚れを落とす目的で、セスキ水に浸け置きしている状態に見えます。用途としては非常に典型的です。

重曹との違い(簡単に)

  • 重曹:弱アルカリ(穏やか、研磨向き)

  • セスキ:重曹よりアルカリ性が強く、油汚れに効く

  • 炭酸ソーダ:さらに強い(扱い注意)

注意点

  • アルミ、銅、真鍮などは変色する可能性あり

  • 長時間の浸け置きは避ける

  • ゴム手袋推奨(手荒れ防止)

要するに、この「セキス」は
「油汚れを安全寄りに、しかし重曹より強力に落とすためのアルカリ洗浄剤」
です。

激落ちくん レック の セスキ炭酸ソーダ 粉末タイプ 1kg /アルカリの力で油汚れを落とす/コンロ、手アカ、えりそで汚れにも/

いままで、灯油とかを使って換気扇を洗っていたのですが、嘘のようにこびりついた油が落ちていきました。この効果を化学的に説明して下さい。

とても良い観察です。
これは「気分的に落ちた」ではなく、化学的に見て必然的に起きている現象です。以下、仕組みを整理して説明します。


1. 換気扇の「こびりついた油」の正体

換気扇の汚れは、単なる油ではありません。

実体は次の混合物です。

  • 食用油(トリグリセリド)

  • 空気中の酸素によって酸化・重合した油

  • 調理中に付着したタンパク質・糖分

  • 微粒子の煤(すす)

時間が経つほど、

  • 油は 酸化 → 重合 → 樹脂状化

  • 粘度が上がり、疎水性が強くなる

つまり、
「水にも溶けない、灯油にも溶けにくい半樹脂」
になっています。


2. 灯油が効きにくかった理由(溶解モデル)

灯油は非極性溶媒です。

  • 新しい油(非極性) → よく溶ける

  • 酸化・重合した油 → 極性官能基(–COOH, –OH)を持ち始める

結果として:

「非極性溶媒(灯油)」
vs
「半分は極性を帯びた劣化油」

となり、溶解力が急激に落ちる

さらに灯油は:

  • 表面を濡らすだけ

  • 削らないと奥まで入らない

  • 揮発が遅く、再付着しやすい

という欠点があります。


3. セスキが「嘘のように落ちる」理由(反応モデル)

セスキ炭酸ソーダは 弱アルカリ性(pH ≈ 9.8)

ここが決定的に違います。

(1) 脂肪酸の中和反応

劣化した油には、**脂肪酸(–COOH)**が大量に含まれています。

そこにアルカリが来ると:

脂肪酸 + アルカリ → 石けん(脂肪酸ナトリウム)

つまり、

こびりついた油そのものが、界面活性剤に変わる

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


(2) 乳化・分散が自動で起きる

生成した石けんは:

  • 油を包み込む

  • 水中に分散させる

結果:

  • 「剥がす」ではなく

  • 「自壊して流れ落ちる」

という挙動になります。

だから、

「こすってないのに、勝手に浮いて落ちる」
と感じるわけです。


4. 浸け置きが効く理由(拡散と時間)

セスキ水では、

  • アルカリが金属表面の微細な隙間に浸透

  • 酸化油の内部まで拡散

  • 内部から中和・乳化

これにより、

  • 表層から剥がす灯油

  • 内部から崩すセスキ

という決定的な差が生まれます。


5. なぜ「嘘のように」見えるのか

理由は心理ではなく物理です。

灯油 セスキ
溶かすだけ 化学反応を起こす
表面処理 内部破壊
再付着しやすい 水で流れ去る
力仕事 時間が仕事をする

人間は「反応」を見ていなかっただけで、
実際には、油が自分で壊れていく


6. 一言でまとめると

灯油は「油を溶かそうとしていた」
セスキは「油を化学的に別物に変えていた」

この違いです。

=====

値段も500円程度で、安全性も高い ーー 灯油で苦労していた10年以上の月日がバカみたいです。

換気扇カバーのサイズが洗面器に入り切らなかったので、100均ショップに行って、大き目の洗濯カゴを購入して、そこに120リットルサイズのビニール袋で覆って、そこに、セキスの溶液を作って、換気扇カバを突っ込みました。

みるみるうちに、透明の溶液が真っ黒になりました。

ーーーーー

こういう、化学の実験を兼ねた家事は楽しい ーー と、実感しました。

未分類

『生まれ変わったら金正恩だった件』

の、プロローグを書いてみました ーー いや、ChatGPTに書いてもらいました。

-----

プロローグ

――世界一危険な握手

ドナルド・トランプが、俺の目の前に立っている。

背が高い。声がでかい。
テレビで見たまんまの男が、軍事境界線のこちら側で、満面の笑みを浮かべている。

「Great to meet you.」

ああ、そうだろうな。
そっちは「歴史的瞬間」だ。
だが、こっちは生存確認作業だ。

俺は金正恩として、彼の手を握る。

――この握手が失敗したら、
帰国後に俺を殺す人間が三桁単位で増える。

そういう意味で、人生で一番重い握手だった。

周囲では、将軍たちが直立不動で息を殺し、
党幹部は「今この瞬間をどう利用するか」を計算している。
カメラの向こうでは、世界が息を呑んでいる。

だが、俺が考えているのは、ただ一つ。

「今日を生き延びられるか」

それだけだ。


正直に言うと、
俺はこの国の未来なんて、どうでもいい。

国民?
悪いが、顔も名前も一致しない。

国家?
舞台装置だ。

革命?
テスト範囲外だ。

俺の関心は、
俺が殺されないこと
それだけ。

それなのに、どうして俺は今、
アメリカ合衆国大統領と笑顔で写真を撮っているのか。

……それを説明するには、
少し時間を戻す必要がある。


理由は分からない。

本当に分からない。

事故でも、神でも、トラックでもない。
ある日、俺は高校生だった。
次の瞬間、俺は金正恩だった。

ベッドは広く、天井は高く、
起きた瞬間から周囲の人間が俺を恐れていた。

最初に理解したことは二つ。

一つ。
ここでは、弱いと死ぬ。

二つ。
善人でも死ぬ。

だったら、選択肢は一つしかない。

「俺だけが、生き残る」

それ以外は、全部後回しだ。


外交?
必要だ。

内政?
やらないと死ぬ。

核?
あると殺されにくい。

ミサイル?
飛ばすと騒がれるが、
飛ばさないと内部が騒ぐ。

暗殺?
正直、やりたくはない。
だが、やらないと俺がやられる。

だから、やる。

倫理?
あとで考える。

理想?
帰れたら考える。


トランプは、俺の目を見て、
「You are a smart guy.」と言った。

……まあ、そう見えるだろう。

実際には、
俺はこの男の性格を分析して、
「怒らせない」「持ち上げる」「難しい話をしない」
という三点セットを徹底しているだけだ。

この人は、理屈で人を殺しに来ない。
プライドを撫でておけば、
少なくとも今日、ミサイルは飛んでこない。

それで十分だ。


文在寅?
いい人だ。

だが、信用はしない。

この国の「普通」を、
彼は知らない。

ここでは、
善意は死亡フラグだ。

習近平?
あの人は違う。

あの人が「もういい」と思った瞬間、
俺は消える。

だから、逆らわない。
だが、寄りかかりすぎもしない。

――全部、俺の生存確率の計算だ。


周囲の幹部たちは、
「国の威信」「民族の尊厳」「歴史的使命」
そういう言葉を口にする。

便利な言葉だ。

だが、俺は知っている。

この国で一番俺を殺しやすいのは、
外国じゃない。

身内だ。

軍。
党。
秘密警察。
血縁。

全員、俺が倒れた次の椅子を見ている。

だから俺は、
笑顔で核を持ち、
平和を語りながらミサイルを撃ち、
改革のふりをしながら粛清をする。

全部、
俺が生き残るためだ。


トランプが、カメラに向かって親指を立てる。

世界は拍手する。

歴史的瞬間?
好きに言え。

俺はただ、
今日も生き延びたことに安堵しているだけだ。

この国がどうなろうが、
正直、知ったことじゃない。

俺が帰れるなら、
全部燃えても構わない。

だが――
皮肉なことに、

俺が一番「この国を壊さないように」
慎重に動いている。

なぜなら、
国が壊れたら、俺も死ぬからだ。


これは、
英雄の物語じゃない。

改革者の物語でもない。

世界を救う話でもない。

ただ一人、
元の世界に帰りたいだけの高校生が、
世界一危険な椅子に座って、
必死にしがみついている話だ。

――さて。

次は誰が、
俺を殺しに来る?

-----

よく分からんが、こんな感じでいいのですかね?

もし、続きが読みたい人が、3人くらいいたら、前向きに検討します。

すでに、内政と外交で登場人物50人、事件30件ほどをピックアップしています。

ちなみに、ChatGPTからは『以下の本を読んでおけ』と言われています。

📘 日本語や国内で買える書籍(北朝鮮政治・人事・事件)

1. 『金正恩の機密ファイル』(城内康伸)

  • 出版:小学館新書

  • 内容:元北朝鮮担当記者が、独自取材・内部資料を基に金正恩政権の人事・政策・外交・サイバー攻撃まで幅広く描いた解説書。北朝鮮内部の権力構造の理解に役立つ。F-SIGHT

2. 『北朝鮮はどんなふうに崩壊するのか』(惠谷治)

  • 出版:小学館101新書

  • 内容:金正恩政権の内部抗争・軍と党の関係、過去の未確認のクーデター未遂の噂なども含め、制度と内部力学を分析している。政権内部の人事・事件の背景理解に便利。紀伊國屋書店

3. 『北朝鮮の内部文書集 第1巻』

  • 出版:地人書館

  • 内容:戦後すぐの北朝鮮内部文書の邦訳集。戦後の権力構造・初期政治の形成を知る一次資料として重宝する。chisen.co.jp

4. 『北朝鮮を解剖する:政治・経済から芸術・文化まで』

  • 出版:慶應義塾大学東アジア研究所 編

  • 内容:複数の日本人研究者による共同研究書。党・軍・経済・文化の内部を包括的に分析しており、体制理解に役立つ。NK News - North Korea News


📘 日本語で取り寄せ可能な邦訳・関連書籍

(以下は邦訳版または日本で購入・取り寄せ可能なものが多い著作です)

5. 『The Sister: North Korea’s Kim Yo Jong, the Most Dangerous Woman in the World』(英著・邦訳流通あり)

  • 著:Sung-Yoon Lee

  • 内容:金正恩の妹・金与正の伝記。本国の政策決定・人事権への影響力が詳細に描かれる。ウィキペディア

6. 『Under the Loving Care of the Fatherly Leader』(Bradley K. Martin)

  • 内容:金日成・金正日の個人的統治スタイルとクーデター・粛清の歴史を詳細に追う名著。邦訳や関連解説書が国内でも紹介されていることが多い。Five Books


📘 補助資料として役立つ関連書(英語含む)

これらは日本国内で洋書として取り寄せ可能で、内部政治・人事配置・外交政策・粛清プロセスの理解を深めるのに役立ちます(フィクション取材資料としても有効)。

  • North Korea: A History(Michael J. Seth)
    → 北朝鮮の成立から現代までの政治史。人事・粛清・権力掌握の軌跡を通史的に学べる。listmuse.com

  • North Korea: What Everyone Needs to Know(Patrick McEachern)
    → 統治構造、外交・軍事政策を平易に解説。listmuse.com

  • Accidental Tyrant: The Making of the Darkest Figure in Korean History(Fyodor Tertitskiy)
    → 金日成の権力掌握と体制構築を分析。家族独裁の原点理解に。フィナンシャル・タイムズ