私、ここ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冊でした。

冒頭のフレーズ、

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

に、衝撃を受けました。

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

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

背景

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

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

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

• Windows 11 は継続使用が前提

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

❌ 原因ではなかったもの

• GStreamerそのもの

• GPU描画（D3D11 / OpenGL）

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

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

✅ 真の原因

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

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

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

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

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

設定した項目

意味

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

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

3. Windows 11 側対策（必須）

電源設定

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

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

• スリープ：無効

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

確認場所

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

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

4. GStreamer 環境確認

使用環境

• GStreamer 1.26.10

• MSVC x86_64

• PATH 混在なし

VAAPI 状況

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

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

5. GStreamer による検証結果

表示のみテスト（安定）

→ 両方とも安定

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

→ 正常再生

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

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

結論

• GStreamer実行中は落ちない

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

6. 最終結論（重要）

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

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

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

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

keep-alive（最小・確実）

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

• 表示なし

• 極小負荷

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

方法B：Windows汎用 keep-alive

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

8. 運用方針まとめ

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

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

• ❌ ハード故障ではない

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

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

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

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

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

質問

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

• 実行済み / 未実行

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

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

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

これも 最終形にします。

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

• 起動したら 最小化

• 作業中も 終了しない

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

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

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

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

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

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

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

正直な話（隠しません）

ここまで切り分けて：

• GStreamer ❌

• Windows設定 ❌

• GPUドライバ設定 ❌

• ユーザ操作 ❌

が全部消えました。

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

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

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

手順

1. スタート

2. PowerShell を右クリック

3. 管理者として実行

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

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

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

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

• TdrLevel = 0x0 → TDR 無効

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

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

未設定 or 無効の場合

• TdrLevel が 表示されない

• または

• TdrLevel REG_DWORD 0x3

などの場合

👉 未実行 or TDR 有効のまま

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

手順

1. Win + R

2. regedit → Enter

3. 以下へ移動：

右ペインを確認

• TdrLevel

• TdrDelay

が存在するかを確認。

値の意味

• TdrLevel = 0 → 無効

• TdrDelay = 60 → OK

注意点（重要）

• 設定しただけではダメ

• 必ず再起動が必要

再起動前は、

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

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

1. 上記どちらかで確認

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

例：

• TdrLevel = 0x0, TdrDelay = 0x3c

• TdrLevel が存在しない

• TdrLevel = 0x3

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

確認結果の評価（確定）

これは何を意味するか

• TdrLevel = 0x0

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

• TdrDelay = 0x3c（60秒）

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

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

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

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

• ❌ GStreamer

• ❌ GPU ドライバの TDR

• ❌ Windows 電源管理

• ❌ Radeon Software 設定

• ❌ C-State / OS 省電力

• ❌ ユーザー操作ミス

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

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

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

運用ルール

• Windows 起動直後に必ず起動

• ウィンドウは最小化

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

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

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

確認してください：

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

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

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

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

もし：

• keep-alive 常駐

• TDR 無効

• 電源確認

全部やっても落ちる場合

👉 HM90 を

• 映像処理専用

• 常時一定負荷専用

として使い、

• ビルド

• 重い IDE

• 同時多アプリ

を 別マシンに逃がす

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

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

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

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

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

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

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

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

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

結論（最短ルート）

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

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

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

ファイル作成

C:\scripts\gpu_keepalive.vbs

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

重要ポイント

• 0 → 完全非表示

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

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

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

いまの状態を見ると：

❌ 起動対象

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

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

結論（先に要点）

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

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

これだけです。

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

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

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

あなたの観測通り：

• 放置中にフリーズ

• 画面ブラックアウト

• ping 不通

• 電源は入っている

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

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

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

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

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

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

• PCIe：ASPM L1.2

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

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

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

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

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

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

これが意味することは：

• Direct3D11 コンテキストを維持

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

• VRAM / shared memory を触り続ける

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

つまり：

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

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

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

• 描く → 不要

• 見せる → 不要

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

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

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

いいえ。

実際の負荷は：

• GPU 使用率：0.5〜3%

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

• 温度上昇：誤差レベル

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

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

あなたはすでに：

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

• C-State 制限

• TDR 無効化

• ドライバ設定の最適化

をやっています。

それでも落ちる理由：

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

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

keep-alive を入れた世界線

• 放置しても落ちない

• ブラックアウトしない

• ping が途切れない

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

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

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

一言でまとめると

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

了解しました。
以下は ご提示の
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

curl -kI https://127.0.0.1/

Windows 自身

https://192.168.0.3/

LAN 内別 PC

https://192.168.0.3/

🔒 が表示されれば成功。

11. よく壊れる原因（実体験ベース）

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

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

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

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

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

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

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

リライト方針（前提）

• 統計・検証はしない

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

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

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

リライト案（本文）

見出し

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

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

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

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

読売新聞

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

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

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

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

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

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

朝日新聞

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

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

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

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

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

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

毎日新聞

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

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

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

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

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

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

日本経済新聞

「数字がすべて」型

日経は感情を排する。

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

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

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

産経新聞

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

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

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

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

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

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

赤旗

「構造が悪い」型

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

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

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

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

聖教新聞

「人は変われる」型

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

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

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

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

結び

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

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

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

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

コメント（なぜこうリライトしたか）

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

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

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

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

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

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

追補リライト（追加分）

前進（中核派）

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

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

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

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

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

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

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

解放（革マル派）

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

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

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

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

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

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

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

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

ここまで含めた全体像（整理）

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

コラムとしての「落ち」

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

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

は、ほぼ YES になる。

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

• 誰に怒れと言われるか

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

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

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

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

補足的に言うと（個人コラムらしく）

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

違いは、

• 自覚しているか

• 無自覚か

それだけだ。

私がこれまで生きてきた中で、人生のパラダイムを変えるイノベーションを挙げろと言われたら、まよわず、
If I were asked to name the innovations that have changed the paradigm of my life so far, without hesitation,

(1) パソコン
(1) Personal computers

(2) 生成AI
(2) Generative AI

の二つを挙げます。
These two would be my choices.

この二つには、驚くほど共通した評価が与えられてきました。
These two have received surprisingly similar evaluations.

―― これらのものは、人間を"バカ者"にする
"These things make humans stupid."

というものです。
That is the claim.

---

生成AIについては、まだ十分な時間が経っていませんが、パソコンについては、すでに数十年分の結果が出ています。
As for generative AI, not enough time has passed yet, but for personal computers, we already have several decades of results.

パソコンが普及する前には、次のような「弊害」が語られていました。
Before personal computers became widespread, the following "harmful effects" were often discussed.

- 計算を機械に任せることで、思考力や計算力が低下する
- Delegating calculations to machines would weaken thinking and arithmetic skills

- 文字を書かなくなり、漢字や表現力が衰える
- People would stop writing by hand, leading to a decline in kanji and expressive ability

- 情報を覚えなくなり、調べれば済むという姿勢が広がる
- People would stop memorizing information and rely solely on looking things up

- 対人コミュニケーションが減る
- Face-to-face communication would decrease

- 機械に依存し、人間が主体性を失う
- Humans would become dependent on machines and lose their autonomy

そして実際、普及後には、
And in fact, after widespread adoption,

- 暗算や手書き能力の低下
- A decline in mental arithmetic and handwriting ability

- 漢字が書けない、電話番号を覚えない
- Inability to write kanji and failure to memorize phone numbers

- 検索前提の行動様式
- Behavior based on the assumption of constant search access

- 試行錯誤の浅さ
- Shallowness in trial-and-error processes

- 画面越し中心のやり取り
- Communication centered around screens

といった現象が確認されました。
Such phenomena were indeed observed.

この点だけを見れば、
Looking only at these points,

■ パソコンは、人間の一部の能力を弱めた
■ Personal computers weakened specific human abilities

という予測は、かなり正確だったと言えます。
This prediction was reasonably accurate.

しかし、当時の議論には決定的に欠けていた視点がありました。それは、「失われる能力」ばかりを見て、「移動する能力」を見ていなかったことです。
However, a crucial perspective was missing from the discussions at the time: they focused only on abilities that would be lost, not on those that would shift.

現実に起きたのは、
What actually happened was,

■ 人間が全面的に劣化した、という事態ではない
■ Humans did not deteriorate across the board

■ 能力の総量が減ったわけでもない
■ The total amount of ability did not decrease

■ 知性の使われ方と配置が変わった
■ The way intelligence is used and allocated has changed

という変化でした。
These were the changes.

暗算や記憶は弱まりました。その代わり、設計・編集・判断・統合・抽象化といった能力は、むしろ要求水準が上がりました。
Mental arithmetic and memorization weakened, but in exchange, abilities such as design, editing, judgment, integration, and abstraction faced higher demands.

したがって、より正確に言えば、
Therefore, more precisely speaking,

■ 弊害の予測は当たった
■ The prediction of harm was correct

しかし、
However,

■ 影響の評価は外れた
■ The evaluation of the impact was incorrect

という整理になります。
That is the most accurate way to frame it.

そして、何より重要なのは、
And most importantly,

―― 『弊害があるからパソコンを止めよう』という人が、現実には一人もいなかった
No one actually said, "Because there are harmful effects, we should stop using computers."

という事実です。
That is the reality.

---

この構図は、生成AIでもほぼそのまま再現されています。
This same structure is almost perfectly reproduced with generative AI.

生成AIについて語られているのも、
What is said about generative AI is also

―― 考えなくなる
- People will stop thinking

―― 書けなくなる
- People will lose the ability to write

―― 創造性が失われる
- Creativity will be lost

―― 判断力が衰える
- Judgment will deteriorate

といった、どこかで聞いた話ばかりです。
all familiar arguments we have heard somewhere before.

おそらく将来、これらの多くは「また当たっていた」と言われるでしょう。
In the future, many of these will probably be said to have been "right again."

生成AIは、人間の一部の能力を確実に弱めます。思考の初動を、AIに委ねる場面が増えるからです。
Generative AI will certainly weaken some human abilities, because the initial stage of thinking is increasingly delegated to AI.

文章を書く前にAIに聞く。コードを書く前にAIに出す。構成を練る前にAIに要約させる。
We ask AI before writing sentences. We give code to AI before writing it. We have AI summarize before planning the structure.

この時点で、すでに手を動かす前の仕事は、人間の手を離れています。
At this point, the work done before actually using our hands has already left human control.

では、その先に待っているのは、人間の劣化でしょうか ―― パソコンの歴史を見る限り、答えは否です。
So does that mean human degradation awaits us? Judging from the history of computers, the answer is no.

---

失われる能力がある一方で、人間に求められる能力の重心は、確実に移動します。
While some abilities are lost, the center of gravity of abilities demanded of humans clearly shifts.

生成AI時代に残るのは、
What remains in the age of generative AI is,

- 任せる／任せないを決める判断
- Judgment about what to delegate and what not to delegate

- 出力の妥当性を見抜く評価
- The ability to evaluate the validity of outputs

- 文脈に合わせた修正
- Adjustments aligned with context

- 複数結果の統合と意味づけ
- Integration and meaning-making across multiple results

- 問いそのものを設計する力
- The ability to design the questions themselves

といった、外部化しにくい知性です。
These are forms of intelligence that are difficult to externalize.

それにもかかわらず、
Nevertheless,

―― 弊害があるのだから、生成AIを止めよう
"Because there are harmful effects, we should stop generative AI."

という主張が、世界に通用する訳がない。
It is a claim that has no chance of being accepted by the world.

そういうことを言っている人や新聞の論評を見る度に、私は『この人、時間を無駄使いしているなぁ』と思っています。
Whenever I see people or newspaper editorials making such claims, I think, "This person is wasting their time."

(ちなみに、このコラムのネタは、頼みもしないのに、サービスとしてここ2～3日我が家のポストに投函された、朝日新聞をパラパラと読んだ時に、思い至りました。)
(By the way, the idea for this column came to me while casually flipping through the Asahi Shimbun, which was delivered to my mailbox as a "service" over the past few days without my asking.)

---

この考えに至ったのは、技術の話だけを見てきたからではありません。
I did not arrive at this conclusion by looking only at technology.

東京2020オリンピックは、開催前まで反対意見が圧倒的でしたし、大阪万博2024も、廃止論の方が目立っていました。
Before the Tokyo 2020 Olympics, opposition was overwhelming, and for Expo 2024 Osaka, abolition arguments were more prominent.

ところが、開催が始まった途端、あるいは終わった途端に、反対の声は、驚くほどきれいに消えました。
However, as soon as the events began or ended, the opposing voices disappeared with surprising cleanliness.

賛成に転じたわけではありませんし、是非が解決されたわけでもありません。
It was not that people switched to supporting them, nor that the issues were resolved.

ただ、「もう戻らない」と認識された瞬間に、話題にされなくなっただけです。
They stopped being talked about once it was recognized that there was no going back.

ですので、今なお、「東京2020は中止すべきだった」「大阪万博2024はやるべきではなかった」と声高に言っている人がいるなら、ぜひ紹介して下さい。
So if there are still people loudly insisting that "Tokyo 2020 should have been canceled" or "Expo 2024 Osaka should not have happened," please introduce them to me.

---

まあ、つまり、こういうことです。
In short, this is what it comes down to.

―― 一度走り始めてしまえば、私を含めて、世間なんぞ、実にチョロい
"Once something starts moving, society, including myself, is remarkably easy to sway."

あれほど、問題だ、危険だ、人間がダメになると言っていたはずなのに、気がつけば、文句を言いながら、全員が普通に使っている。
Despite all the talk about problems, dangers, and human decline, before we realize it, everyone is using it anyway while complaining.

パソコンもそうでした。生成AIもきっと同じです。
That was the case with computers, and generative AI will surely be the same.

「本当は反対だった」「危険性は理解している」「使うべきではないと思っている」そう言いながら、今日も検索し、今日もコピペし、今日もAIに聞いています。
Saying "I was actually against it," "I understand the risks," or "I don't think it should be used," we still search, copy-paste, and ask AI every day.

人間というのは、信念より便利さを、主張より締切を、思想より効率を、だいたい優先します。私も含めて。
Humans tend to prioritize convenience over beliefs, deadlines over principles, and efficiency over ideology, myself included.

だから、パソコンも生成AIも、出現してしまった以上、もう止まりません。
That is why neither computers nor generative AI will stop once they have appeared.

「慎重に議論すべきだ」という正論は、「明日の会議に間に合わせたい」という現実に、ほぼ確実に負けます。
The correct argument that "we should discuss this carefully" almost always loses to the reality of "we need to be ready for tomorrow's meeting."

批判している人たちが間違っているとは思いません。正しいことを言っている場合も多いでしょう。
I do not think those who criticize are wrong; they often say correct things.

ただ、その横を、何事もなかった顔で、ただ世界が進んでいくだけです。
But beside them, the world moves on as if nothing happened.

パソコンが使えない人や生成AIを拒否する人を、責める必要はありません。責めなくても、世界の方が、彼等を勝手に置いていきます。
There is no need to blame people who cannot use computers or who reject generative AI; even without blame, the world will leave them behind on its own.

---

私が、何が言いたいかというと、
What I want to say is this:

―― 世間の流れに「批判」だけで逆らうのは、コストパフォーマンスが、恐ろしく悪い
"Resisting the flow of society with nothing but criticism has a terribly poor cost-performance ratio."

ということです。
That is the point.

流れることには、面倒も苦労も伴います。納得できないことも、腹の立つことも、山ほどあります。それでも結局、私たちは流れます。
Going with the flow involves hassle and hardship, and there are countless things we cannot accept or that anger us. Still, in the end, we flow along.

文句を言いながら、自分は違う顔をしながら、「仕方がない」と言いながら。
While complaining, while pretending we are different, while saying "it can't be helped."

---

要するに、
In short,

―― 世間はチョロい
"Society is easy."

のです。
That's how it is.

私を含めて。
Including myself.

ーー 私は、権力に逆らわない。場を読んで、常に強い側に寝返る。必要なら何度でも寝返り続ける

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

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

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

―― びっくりしました

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

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

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

=====

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

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

セスキ炭酸ソーダとは

• 弱アルカリ性の洗浄剤

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

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

何に使うものか

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

• 皮脂汚れ・手垢

• 軽い焦げ付き

• 消臭（生ゴミ周り、布製品など）

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

重曹との違い（簡単に）

• 重曹：弱アルカリ（穏やか、研磨向き）

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

• 炭酸ソーダ：さらに強い（扱い注意）

注意点

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

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

• ゴム手袋推奨（手荒れ防止）

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

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

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

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

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

実体は次の混合物です。

• 食用油（トリグリセリド）

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

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

• 微粒子の煤（すす）

時間が経つほど、

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

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

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

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

灯油は非極性溶媒です。

• 新しい油（非極性） → よく溶ける

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

結果として：

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

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

さらに灯油は：

• 表面を濡らすだけ

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

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

という欠点があります。

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

セスキ炭酸ソーダは 弱アルカリ性（pH ≈ 9.8）。

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

(1) 脂肪酸の中和反応

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

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

つまり、

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

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

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

生成した石けんは：

• 油を包み込む

• 水中に分散させる

結果：

• 「剥がす」ではなく

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

という挙動になります。

だから、

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

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

セスキ水では、

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

• 酸化油の内部まで拡散

• 内部から中和・乳化

これにより、

• 表層から剥がす灯油

• 内部から崩すセスキ

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

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

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

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

6. 一言でまとめると

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

この違いです。

=====

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

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

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

ーーーーー

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

―― 人間、若ければ若いほど、自分のメンツとかプライドに拘るものございます
―― Generally speaking, the younger a person is, the more they tend to cling to their pride and sense of face.

と、まあ落語の一席のような切り口上ではありますが、まあ、これ、大きくは外れていないと思うのです。
It may sound like the opening line of a rakugo performance, but I don't think it's far off the mark.

私の場合、実際に、若い頃の方が、プライド高くて、他人にマウントとってナンボ、という感じで振る舞っていたものです。
In my case, I was actually much more prideful when I was younger, behaving as if gaining the upper hand over others was everything.

年齢を重ねると、比較的、物事が"遠く"、または"広く"見えてくるもので、自分の立ち位置や限界のようなものが、少しずつ分かってきます。
As one grows older, things tend to be seen from a more distant or broader perspective, and one gradually comes to understand one's own position and limitations.

その結果として、『自分が、そんなに大したものではない』という事実を、感情的な抵抗なく受け取れるようになるのだと思います。
As a result, I think one can accept the fact that "I'm not really all that special" without emotional resistance.

いや……ちょっと違うか。
No… that might not be quite right.

---

正確には、『自分が拘っていることに、そこまで拘り続けるエネルギーを使うのが、面倒になってくる』という感じでしょうか。
More precisely, it's that continuing to pour energy into things I'm fixated on starts to feel bothersome.

■他人と比較せずに、自分の好きなことを、好きなようにやれていれば、それで十分。
- It's enough if you can do what you like, the way you like, without comparing yourself to others.

■他人と比較して悩む時間があるなら、その分を自分のために使った方がいい。
- If you have time to worry by comparing yourself with others, you'd be better off using that time for yourself.

■その「好きなようにやれている時間」が、可処分時間の10％も確保できていれば、人生としては、もう大勝利
- If that "doing what you like" time makes up even 10% of your disposable time, then life is already a huge win

なのではないか。
Or so I think.

そんなふうに考えるようになり、徹底して『世間と比較するのが面倒くさい』という境地に、落ち着いてきたように思います。
Thinking this way, I feel I've settled into a state where I thoroughly find it tiresome to compare myself with society.

ただ、これがティーンエイジャーの段階で、このような達観に至ってしまっていると、それはそれで困りものだ、ということも分かります。
However, I also understand that if someone reaches this kind of detachment at a young age, it would be problematic in its own way.

ですので、『自分のメンツとかプライドに拘る』という気持ちは、若い時期には確かに必要で、しかしそれが年齢とともに、自然に減衰していくのであれば、自分にとっても、社会にとっても、悪くないことなのだろう、と思っています。
So I think that caring about one's pride and face is certainly necessary when one is young. Still, if it naturally diminishes with age, that's probably not a bad thing for either the individual or society.

---

小学生の頃、夏休みの家庭科の宿題(たしか、衣服を縫うという内容だったと思います)を、母が勝手にやってしまい、酷く腹を立てたことがあります。
When I was in elementary school, my mother once did my summer vacation home economics homework (I think it involved sewing clothes) without asking, and I got furious.

自分の宿題は自分でやる、というのが、小学生の頃の私なりの矜持だったからです。
That was because, for elementary-school-aged me, doing my own homework was a matter of personal pride.

(ちなみに、嫁さんの場合は、『夏休みの終了3日前から、両親を起動して、一家総出で一気に片づける』というのが家風だったそうです。『宿題は7月中に自力で完了させる』という私の方針との差に、お互いが驚いたものです)
(By the way, in my wife's family, the custom was to "activate the parents three days before the end of summer vacation and finish everything at once as a family." We were both surprised at how different that was from my policy of "finish all homework on your own by July.")

その私が今や、ChatGPT頼みで、生きています。
And now, that same person is living by relying on ChatGPT.

3年間、問題を抱え続けていたシステムを、昨夜、一気に片づけてしまいました。
Last night, I resolved a system that had been plagued with problems for three years in one go.

もちろん、解決の方針や考え方は私がChatGPTに提案したものですが、実際にコードを書いたのはChatGPTです。
Of course, I proposed the solution approach and ideas to ChatGPT, but ChatGPT wrote the actual code.

生成AIに指示されるがままにコードを書き、エラーを報告し、デバッグを繰り返して、3年越しに、システムをサーバ起動できるようにしました。
Following the generative AI's instructions, writing code, reporting errors, and repeating the debugging process, I finally managed, after three years, to get the system running on a server.

---

―― 生成AIに顎(あご)で使われてシステムを動かしてもらって、お前の誇りは傷つかないのか？
"Doesn't it hurt your pride to have a generative AI boss you around and run your system for you?"

と問われたとしても、
Even if I were asked that,

『動くなら、それでいいじゃん』
"If it works, that's good enough, right?"

と思っている今の私は、きっと小学生の頃の私から、盛大に説教されるのだろうな、とは思います。
I'm sure the elementary-school version of myself would give me a massive lecture.

『他人の力に頼ることも立派な能力なんだよ』と語りたいのですが、ただ、ちょっと"それ"は言えないんですよ。
I'd like to say, "Relying on others' strength is also a fine ability," but I can't quite say that.

生成AI以外のモノ(人間)には、あまり頼ってこなかったからです。
Because I haven't relied much on things other than generative AI, namely, people.

それはプライドというより、頼った結果として、その人の言動に腹が立てることがが多かったから、というのが正直なところです。
That's less about pride and more about the fact that relying on people often made me angry at their words or actions.

---

ともあれ ーー
In any case,

今の私がやっていることは、英語や数学の問題を読んで、速攻で解答を見て、「なるほど、なるほど」と頷いているのと、ほぼ同じです。
What I'm doing now is almost the same as reading English or math problems, checking the answers immediately, and nodding while saying, "I see, I see."

学校の勉強についてはともあれ、少なくともITシステムは「動けば、それでいい」のです。
Whatever the case may be with school studies, at least for IT systems, "if it works, that's enough."

https://c-anemone.kobore.net:8080/の過負荷テストにご協力下さい。

公共交通オープンデータセンタを通じて横浜市交通局が提供しているバスのリアルタイム情報を用いたバス位置把握システムについて、昨夜、全面的な改修を行いました。

これまで、本システムには「ユーザごとに表示内容が異なる」という問題がありました。そこで、バスのリアルタイム位置情報の収集処理をサーバ側に集約し、クライアント側は表示機能のみを担う構成へと変更しました。現在、この仕組みはサーバ化されています。

つきましては、過負荷テストを実施したく、皆様のご協力をお願いできればと思います。

ここ↓をクリックするだけです(お１人、1回で結構です)。

https://c-anemone.kobore.net:8080/

下記のような画面がでてきたら、拡大や縮小させて見て下さい。30秒毎に画面が自動更新されます。
(出てこない場合は、サーバが落ちたということになります。ご容赦下さい)。

「Protocol Buffersって何？ 」から、「公共交通オープンデータ」を攻略する

横浜市交通局 バス停情報のJSONパーサー

横浜市交通局 バス路線情報の取得方法 golangによるJSONパーサー

[ubuntu:~/yoko_bus/PruneMobile$more index.html]

<!DOCTYPE html>
<html lang="ja">
<head>
  <meta charset="utf-8" />
  <title>PrimeMobile Bus Monitor</title>

  <link rel="stylesheet"
        href="https://cdnjs.cloudflare.com/ajax/libs/leaflet/1.0.0-beta.2.rc.2/leaflet.css" />
  <script src="https://cdnjs.cloudflare.com/ajax/libs/leaflet/1.0.0-beta.2.rc.2/leaflet.js"></script>

  <!-- ★クラスタリング（以前の方式） -->
  <script src="scripts/PruneCluster.js"></script>

  <link rel="stylesheet" href="styles/style.css" />

  <style>
    html, body { height: 100%; margin: 0; }
    #bar {
      height: 44px;
      display: flex;
      align-items: center;
      gap: 12px;
      padding: 0 12px;
      border-bottom: 1px solid #ddd;
      font-family: sans-serif;
      font-size: 14px;
      box-sizing: border-box;
    }
    #map { height: calc(100% - 44px); }
  </style>
</head>

<body>
  <div id="bar">
    <button id="reload" type="button">更新</button>
    <span id="status">起動中…</span>
  </div>

  <div id="map"></div>

  <script>
    const UPDATE_INTERVAL_MS = 30000;
    const API_BUSES = "/api/buses";

    const statusEl = document.getElementById("status");
    const reloadBtn = document.getElementById("reload");

    function setStatus(s) {
      statusEl.textContent = s;
    }

    // ★ ISO8601(UTC) → JST 表示
    function fmtTimeJST(iso) {
      if (!iso) return "";
      const d = new Date(iso);
      if (isNaN(d.getTime())) return String(iso);
      return d.toLocaleString("ja-JP", { timeZone: "Asia/Tokyo" });
    }

    // 地図
    const map = L.map("map", { zoomControl: true }).setView([35.45, 139.63], 12);
    L.tileLayer("https://{s}.tile.openstreetmap.org/{z}/{x}/{y}.png", {
      maxZoom: 19,
      attribution: "© OpenStreetMap contributors"
    }).addTo(map);

    // バスアイコン
    const busIcon = L.icon({
      iconUrl: "images/bus-icon.png",
      iconSize: [68, 27],
      iconAnchor: [34, 13]
    });

    // ★PruneCluster
    const leafletView = new PruneClusterForLeaflet(120, 20);
    map.addLayer(leafletView);

    leafletView.BuildLeafletMarker = function (marker, position) {
      const m = new L.Marker(position, { icon: busIcon });
      if (marker.data && marker.data.popup) {
        m.bindPopup(marker.data.popup);
      }
      return m;
    };

    // bus_id -> { marker, lastSeenUnix }
    const busMarkers = new Map();

    function fmtTime(iso) {
      if (!iso) return "";
      const d = new Date(iso);
      if (isNaN(d.getTime())) return String(iso);
      return d.toLocaleString("ja-JP", { timeZone: "Asia/Tokyo" });
    }

    function upsertBus(b) {
      const id = b.id;
      const lat = b.lat;
      const lng = b.lon;
      const lastSeenUnix = (typeof b.last_seen_unix === "number")
        ? b.last_seen_unix
        : Math.floor(Date.now() / 1000);

      let ent = busMarkers.get(id);

      const popup =
        "BUS " + id +
        (b.trip_id ? ("<br>trip: " + b.trip_id) : "") +
        (b.last_seen ? ("<br>last: " + fmtTime(b.last_seen)) : "");

      if (!ent) {
        const pm = new PruneCluster.Marker(lat, lng, { popup: popup });
        leafletView.RegisterMarker(pm);
        busMarkers.set(id, { marker: pm, lastSeenUnix: lastSeenUnix });
      } else {
        ent.marker.position.lat = lat;
        ent.marker.position.lng = lng;
        ent.marker.data.popup = popup;
        ent.lastSeenUnix = lastSeenUnix;
      }
    }

    // 古い車両を削除
    const STALE_SEC = 120;

    function gcStale() {
      const now = Math.floor(Date.now() / 1000);
      const removeList = [];
      for (const [id, ent] of busMarkers.entries()) {
        if (now - ent.lastSeenUnix > STALE_SEC) {
          removeList.push(ent.marker);
          busMarkers.delete(id);
        }
      }
      if (removeList.length > 0) {
        leafletView.RemoveMarkers(removeList);
      }
    }

    async function fetchBuses() {
      const t0 = Date.now();
      try {
        const r = await fetch(API_BUSES + "?ts=" + t0, { cache: "no-store" });
        if (!r.ok) throw new Error("HTTP " + r.status);

        const j = await r.json();
        if (!j || !Array.isArray(j.buses)) throw new Error("invalid json");

        for (const b of j.buses) {
          if (typeof b.id !== "number") continue;
          if (typeof b.lat !== "number") continue;
          if (typeof b.lon !== "number") continue;
          upsertBus(b);
        }

        gcStale();

        const dt = Date.now() - t0;
        setStatus(
          "更新: " + fmtTimeJST(j.ts) +
          " / buses=" + j.buses.length +
          " / " + dt + "ms"
        );
      } catch (e) {
        setStatus("更新失敗: " + e);
      }
    }

    reloadBtn.addEventListener("click", fetchBuses);

    fetchBuses();
    setInterval(fetchBuses, UPDATE_INTERVAL_MS);

    setInterval(function () {
      leafletView.ProcessView();
    }, 1000);
  </script>
</body>
</html>

[ubuntu:~/yoko_bus/PruneMobile$more server.py]

/*
再現シミュレーション用のサーバプログラム

// server.go
*/
package main

import (
	"flag"
	"fmt"
	"log"
	"m/routing"
	"math"
	"net/http"
	"net/http/httputil"
	"net/url"
	"os"
	"sync"
	"time"

	"github.com/gorilla/websocket"
)

var clients = make(map[*websocket.Conn]bool) // 接続されるクライアント

type key struct {
	*websocket.Conn
	id  int
	att string
}

// 配列宣言
var m1 = make(map[key]int) // このm1は、mmapと異なるクライアント(Webブラウザ単位のMap)

// Ebata: m1保護用のミューテックス
var m1Mutex sync.RWMutex

// ChartData
type ChartData struct {
	UserCnt int `json:"user_cnt"`
	JoinCnt int `json:"join_cnt"`
}

var addr = flag.String("addr", ":8080", "http service address") // テスト

var upgrader = websocket.Upgrader{
	CheckOrigin: func(r *http.Request) bool { return true },
} // use default options

var chan2_1 = make(chan routing.LocMessage)
var chan2_2 = make(chan routing.LocMessage)

// chan2_1用のミューテックス
var mutex sync.Mutex

// Enata: map保護用のミューテックス
var mmapMutex sync.RWMutex

//// Ebata: json read write用のmutex
var rwMutex sync.Mutex

// 2次元配列: 変数名は暫定。元々はmmと呼称。
var mmap = map[int]routing.LocMessage{}

// ----------------------
// 追加：gtfs_hub の /api/buses をプロキシ
// ----------------------
func apiBusesProxy() http.Handler {
	hubURLStr := os.Getenv("GTFS_HUB_URL")
	if hubURLStr == "" {
		hubURLStr = "http://127.0.0.1:18081"
	}
	target, err := url.Parse(hubURLStr)
	if err != nil {
		log.Fatalf("bad GTFS_HUB_URL: %v", err)
	}

	proxy := httputil.NewSingleHostReverseProxy(target)
	origDirector := proxy.Director
	proxy.Director = func(r *http.Request) {
		origDirector(r)
		r.URL.Path = "/api/buses"
		// クエリは維持（ts=... など）
	}
	proxy.ModifyResponse = func(resp *http.Response) error {
		resp.Header.Set("Cache-Control", "no-store")
		return nil
	}
	proxy.ErrorHandler = func(w http.ResponseWriter, r *http.Request, e error) {
		http.Error(w, "proxy error: "+e.Error(), http.StatusBadGateway)
	}
	return proxy
}

func echo2(w http.ResponseWriter, r *http.Request) { // 下からの受けつけ(e.g. Simulator/Hub)
	webConn, err := upgrader.Upgrade(w, r, nil) // cはサーバのコネクション
	if err != nil {
		log.Print("upgrade:", err)
		return
	}
	defer webConn.Close()

	for {
		locMsg := new(routing.LocMessage)

		err := webConn.ReadJSON(&locMsg) // クライアントからのメッセージの受信
		if err != nil {
			log.Println("74: read:", err)
			return // Readロック解除の為、goroutineの強制終了
		}

		mutex.Lock()         // chan2_1を守るミューテックス
		chan2_1 <- *locMsg   // here -> pub
		locMsg2 := <-chan2_1 // pub -> here
		mutex.Unlock()

		err = webConn.WriteJSON(locMsg2) // here -> bike, person
		if err != nil {
			log.Println("write:", err)
			return // Writeロック解除の為、goroutineの強制終了
		}

	}
}

func pub() {

	serialId := 1 // 表示マーカー区別用の通番の初期値

	for { // 番号の対応付け直しを行っている

		locMsg := <-chan2_1 // echo2(下) -> here
		if locMsg.ID == -1 {
			locMsg.ID = serialId
			serialId += 1 // 表示マーカー区別用の通番のインクリメント
		}

		mmapMutex.Lock() // map mmap のロック

		/// グローバルマップの作成(ここから)
		_, isThere := mmap[locMsg.ID]

		if isThere && (math.Abs(locMsg.Lat) > 90.0 || math.Abs(locMsg.Lng) > 180.0) { // レコードが存在して、ありえない座標が投入されたら
			delete(mmap, locMsg.ID) // レコードを削除して終了する

		} else if !isThere { // もしレコードが存在しなければ(新しいIDであれば)
			mmap[locMsg.ID] = locMsg // レコードを追加する

		} else { //レコードが存在すれば、要素を書き換える
			mmap[locMsg.ID] = locMsg // レコードの内容を変更する
		}
		/// グローバルマップの作成(ここまで)

		mmapMutex.Unlock() // map mmap のアンロック

		chan2_1 <- locMsg // here -> echo2(下)
		chan2_2 <- locMsg // here -> echo(上)
	}
}

// UI側(上)とのやり取り
func echo(w http.ResponseWriter, r *http.Request) { // JavaScriptとの通信
	webConn, err := upgrader.Upgrade(w, r, nil)
	if err != nil {
		log.Println("websocket connection err:", err)
		return
	}
	defer webConn.Close()

	// クライアントを新しく登録(だけ)
	m1Mutex.Lock()
	clients[webConn] = true
	m1Mutex.Unlock()

	for {
		fmt.Print(time.Now())
		fmt.Print(" 223 ")
		fmt.Println(clients)

		locMsg := new(routing.LocMessage)
		locMsg2 := new(routing.LocMessage)

		*locMsg = <-chan2_2

		var delete_client *websocket.Conn

		for client := range clients { // 全部のクライアントのサーチ

			delete_client = nil

			fmt.Println("231 ")
			// 変数を使って、キーの存在を確認する
			m1Mutex.Lock()
			value, ok := m1[key{client, locMsg.ID, locMsg.TYPE}]
			m1Mutex.Unlock()
			fmt.Println("236")

			if ok && (math.Abs(locMsg.Lat) > 90.0 || math.Abs(locMsg.Lng) > 180.0) { // レコードが存在して、ありえない座標が投入されたら
				fmt.Println("enter 1")
				fmt.Println("240")
				tmpId := locMsg.ID
				locMsg.ID = value

				fmt.Println("1:locMsg:", locMsg)

				rwMutex.Lock()

				err = client.WriteJSON(&locMsg)
				if err != nil {
					delete_client = client
				}
				err = client.ReadJSON(&locMsg2)
				if err != nil {
					delete_client = client
				}

				rwMutex.Unlock()

				m1Mutex.Lock()
				delete(m1, key{delete_client, tmpId, locMsg.TYPE})
				m1Mutex.Unlock()

				fmt.Println("1:locMsg2:", locMsg2)

			} else if !ok { // もしレコードが存在しなければ(新しいIDであれば)
				fmt.Println("enter 2")

				tmpId := locMsg.ID
				locMsg.ID = -1 // 空番号

				fmt.Println("2:locMsg:", locMsg)

				rwMutex.Lock()

				err = client.WriteJSON(&locMsg)
				if err != nil {
					delete_client = client
				}
				err = client.ReadJSON(&locMsg2)
				if err != nil {
					delete_client = client
				}

				rwMutex.Unlock()

				fmt.Println("2:locMsg2:", locMsg2)

				pm_id := locMsg2.ID
				_ = pm_id

				time.Sleep(time.Millisecond * 10)

				m1Mutex.Lock()
				m1[key{client, tmpId, locMsg.TYPE}] = locMsg2.ID
				m1Mutex.Unlock()

			} else { //レコードが存在すれば、その値を使ってアイコンを動かす

				locMsg.ID = value

				rwMutex.Lock()
				err = client.WriteJSON(&locMsg)
				if err != nil {
					delete_client = client
				}
				client.ReadJSON(&locMsg2)
				if err != nil {
					delete_client = client
				}
				rwMutex.Unlock()
			}

		}

		if delete_client != nil {
			fmt.Println("delete_client")
			delete_client.Close()
			delete(clients, delete_client)
		}
	}
}

func echo3(w http.ResponseWriter, r *http.Request) {

	fmt.Println("             Echo3() is starting..........")

	upgrader.CheckOrigin = func(r *http.Request) bool { return true }

	conn2, err := upgrader.Upgrade(w, r, nil) //conn2でwebsocketを作成
	if err != nil {
		log.Println("websocket connection err:", err)
		return
	}
	defer conn2.Close()

	for {

		chart := new(ChartData)
		joinCnt := 0

		mmapMutex.Lock()

		chart.UserCnt = len(mmap)

		for _, v := range mmap {
			dis, _ := routing.DistanceKm(v.Lng, v.Lat, 139.69978753816494, 35.664114318726675) // 北谷公園
			fmt.Println("dis:", dis)
			if dis < 0.10 { //100メートルに入ったらカウント
				joinCnt += 1
			}
		}

		mmapMutex.Unlock()

		chart.JoinCnt = joinCnt

		err := conn2.WriteJSON(&chart)
		if err != nil {
			log.Println("WriteJSON:", err)
			break
		}
		fmt.Println("echo3:", chart)
		time.Sleep(time.Second * 1)
	}
}

func main() {

	flag.Parse()
	log.SetFlags(0)

	log.Println(routing.LiPoint)
	go pub()

	// 追加：/api/buses を先に登録（"/"より前）
	http.Handle("/api/buses", apiBusesProxy())

	// アクセスされたURLから /static 部分を取り除いてハンドリングする
	http.Handle("/", http.FileServer(http.Dir(".")))

	http.HandleFunc("/echo3", echo3)
	http.HandleFunc("/echo2", echo2)
	http.HandleFunc("/echo", echo)

	log.Fatal(http.ListenAndServeTLS(*addr, "./fullchain.pem", "./privkey.pem", nil))
}

[ubuntu:~/yoko_bus/gtfs$ more gtfs_hub.go]

// https://gtfs.org/realtime/language-bindings/golang/

package main

import (
	"encoding/json"
	"flag"
	"log"
	"net/http"
	"strconv"
	"sync"
	"time"

	"github.com/MobilityData/gtfs-realtime-bindings/golang/gtfs"
	proto "github.com/golang/protobuf/proto"
)

var (
	// GTFS-RT取得周期（現状踏襲：30秒）
	pollInterval = 30 * time.Second

	// HTTPサーバ（server.go から http://127.0.0.1:18081/api/buses へプロキシする）
	httpAddr = flag.String("http", "127.0.0.1:18081", "http listen addr for /api/buses")

	// ODPT（現行コードのURLを踏襲）
	gtfsURL = flag.String("url",
		"https://api.odpt.org/api/v4/gtfs/realtime/YokohamaMunicipalBus_vehicle?acl:consumerKey=f4954c3814b207512d8fe4bf10f79f0dc44050f1654f5781dc94c4991a574bf3",
		"gtfs realtime url",
	)
)

// ---- 返却JSON ----
type Bus struct {
	ID           int     `json:"id"`
	Lat          float64 `json:"lat"`
	Lon          float64 `json:"lon"`
	TripID       string  `json:"trip_id,omitempty"`
	Bearing      float32 `json:"bearing,omitempty"`
	Speed        float32 `json:"speed,omitempty"`
	LastSeen     string  `json:"last_seen"`
	LastSeenUnix int64   `json:"last_seen_unix"`
}

type BusesResponse struct {
	TS   string `json:"ts"`
	Buses []Bus `json:"buses"`
}

// ---- 内部保持 ----
type hubState struct {
	mu    sync.RWMutex
	ts    time.Time
	buses map[int]Bus
}

var st = hubState{
	ts:    time.Time{},
	buses: map[int]Bus{},
}

func main() {
	flag.Parse()
	log.SetFlags(0)

	// HTTP
	http.HandleFunc("/api/buses", handleAPIBuses)
	go func() {
		log.Printf("gtfs_hub http listening on %s", *httpAddr)
		log.Fatal(http.ListenAndServe(*httpAddr, nil))
	}()

	// Poll
	for {
		pollOnce()
		time.Sleep(pollInterval)
	}
}

func handleAPIBuses(w http.ResponseWriter, r *http.Request) {
	w.Header().Set("Content-Type", "application/json; charset=utf-8")
	w.Header().Set("Cache-Control", "no-store")

	st.mu.RLock()
	defer st.mu.RUnlock()

	out := BusesResponse{
		TS:   st.ts.Format(time.RFC3339),
		Buses: make([]Bus, 0, len(st.buses)),
	}
	for _, b := range st.buses {
		out.Buses = append(out.Buses, b)
	}

	enc := json.NewEncoder(w)
	enc.SetEscapeHTML(false)
	_ = enc.Encode(out)
}

func pollOnce() {
	client := &http.Client{Timeout: 15 * time.Second}
	req, err := http.NewRequest("GET", *gtfsURL, nil)
	if err != nil {
		log.Println("new request:", err)
		return
	}

	// ODPT（横浜市営バス）では不要とのことなので、ダミーを踏襲
	req.SetBasicAuth("xx@gmail.com", "xx")

	resp, err := client.Do(req)
	if err != nil {
		log.Println("http do:", err)
		return
	}
	defer resp.Body.Close()

	if resp.StatusCode/100 != 2 {
		log.Println("bad status:", resp.Status)
		return
	}

	feed := gtfs.FeedMessage{}
	body, err := readAll(resp)
	if err != nil {
		log.Println("read:", err)
		return
	}
	if err := proto.Unmarshal(body, &feed); err != nil {
		log.Println("proto unmarshal:", err)
		return
	}

	now := time.Now()

	next := map[int]Bus{}

	for _, entity := range feed.Entity {
		if entity == nil || entity.Vehicle == nil || entity.Vehicle.Vehicle == nil || entity.Vehicle.Position == nil {
			continue
		}

		// vehicle.id
		vidStr := entity.Vehicle.Vehicle.Id
		if vidStr == nil {
			continue
		}
		vid, err := strconv.Atoi(*vidStr)
		if err != nil {
			continue
		}

		latp := entity.Vehicle.Position.Latitude
		lonp := entity.Vehicle.Position.Longitude
		if latp == nil || lonp == nil {
			continue
		}

		b := Bus{
			ID:           vid,
			Lat:          float64(*latp),
			Lon:          float64(*lonp),
			LastSeen:     now.Format(time.RFC3339),
			LastSeenUnix: now.Unix(),
		}

		// trip_id
		if entity.Vehicle.Trip != nil && entity.Vehicle.Trip.TripId != nil {
			b.TripID = *entity.Vehicle.Trip.TripId
		}

		// bearing / speed（入っていれば）
		if entity.Vehicle.Position.Bearing != nil {
			b.Bearing = *entity.Vehicle.Position.Bearing
		}
		if entity.Vehicle.Position.Speed != nil {
			b.Speed = *entity.Vehicle.Position.Speed
		}

		next[vid] = b
	}

	st.mu.Lock()
	st.ts = now
	st.buses = next
	st.mu.Unlock()

	log.Printf("polled: buses=%d at %s", len(next), now.Format(time.RFC3339))
}

func readAll(resp *http.Response) ([]byte, error) {
	// Go1.17+ なら io.ReadAll でよいが、環境差を避けるため手書きしないで最小にする
	// （標準の io.ReadAll が使えるならそちらに置換してもよい）
	type reader interface{ Read([]byte) (int, error) }
	b := make([]byte, 0, 1<<20)
	tmp := make([]byte, 32*1024)
	for {
		n, err := resp.Body.Read(tmp)
		if n > 0 {
			b = append(b, tmp[:n]...)
		}
		if err != nil {
			if err.Error() == "EOF" {
				return b, nil
			}
			return b, err
		}
	}
}

[実行方法]

cd PrumeMobile
go run server.go

cd ..
cd gtfs
go run gtfs_hub.go