未分類

SW-121取扱説明書

未分類

私は、11:30の特急に乗る予定だったのですが、10:30の列車が動いていません。

I planned to take the 11:30 express train, but the 10:30 train is not running.

強風で止まるとは聞いていたのですが、何時間も止まるとは思いませんでした。

I had heard it would stop in strong winds, but I didn't think it would stop for hours.

地震、豪雨、豪雪、人身事故は分かりますが「強風」です。

I understand earthquakes, torrential rain, heavy snowfall, and personal injury, but “strong winds.”

これには困りました。

This was a problem.

常磐線は代替交通手段がありません。

There is no alternative transportation on the Joban Line.

上野からピクリとも動かない特急電車の中で、待機していたのですが「架線にビニールがひっかった」とか、「倒木」とか、さらに不穏な車内放送が響きました。

I was waiting in the express train, which hadn't moved an inch from Ueno, when I heard an even more disturbing announcement over the loudspeaker: “There's a piece of plastic caught in the overhead wires” and “A fallen tree”.

『こりゃ、運転開始後も、到着時間が見込めないな』と判断して、出張を断念する旨を、先方に連絡しました。

I decided that I couldn't estimate the arrival time even after the drive started, so I contacted the other party to inform them that I would have to cancel the business trip.

今回の仕事は、機材持ち込んで、6～8時間くらい、ぶっつづけでシステム構築作業&実験の予定だったからです。

This time, I planned to bring in my equipment and work on system construction and experiments for 6 to 8 hours straight.

仕方なく、上野から自宅に帰宅中しました。そんでもって、自宅でシステムを組み立てて、システムチューニングをしていました。

I had no choice but to go home from Ueno. Then, I set up the system at home and performed system tuning.

-----

何が痛いって、失った時間が痛い。

What hurts is the time I've lost.

待機時間を含めると、本日、上野までの往復と、止った電車の中での時間併わせて、貴重な5時間が吹っ飛びました。

If you include the waiting time today, the time spent on the train to Ueno and back, and the time spent on the stopped train, a precious 5 hours have flown by.

出張には時間のリスクはつきものとはいえ、それにしても痛い。

Even though business trips are always risky, this is still painful.

-----

最近、30分多く時間がかかっても、新宿駅を回避するルートを選ぶようにしています。

Recently, even if it takes 30 minutes longer, I try to choose a route that avoids Shinjuku Station.

小田急新宿駅の、到着時間がアテにならないからです。

Because the arrival time at Odakyu Shinjuku Station is unreliable.

新宿駅は人が多く、相対的にバカとの遭遇率が高くなる、というのも、理由の一つですが。

One reason is that Shinjuku Station is very busy, and the rate of encounters with idiots is relatively high.

私、人生でナンパをしたこと一度もないので分かりませんが、ナンパする奴の知能や知性って、こんなにレベル低いんですか？

小田急は新宿駅周辺で、人身事故でもないのに、普通に遅延が発生します。

Odakyu trains are regularly delayed in Shinjuku, even when no accident occurs.

今や、小田急に限らず、今や都内の電車の到着時刻が、あてになりません。

Now, not just with Odakyu, but the arrival times of trains in the Tokyo area are unreliable.

今日も、わざわざ回避ルートを使ったのに(川崎駅経由)、こともあろうに、そのルートで人身事故の影響をくらいました。

Today, even though I took the detour (via Kawasaki Station), I was affected by a personal injury accident on that route.

「飛び込み自殺だけはやめとけ」と、私がこんなにも言い続けているのに、なぜ分かってくれないのだろう。

Why don't they understand me when I keep saying, “Don't do a suicide dive”?

(↑コラムに飛びます)

(Jump to the column)

いや、分かっています。私も危なかったこと、ありましたから(遠い目)。

No, I know. I've been in danger, too (looking far away).

-----

最近、ホームゲートが次々と設置されています。データからも、ホームゲートによる人身事故の防止は明らかですが、それでも、私の調べた範囲で、ホームゲートを飛び越えて自死した人も二人います。

Recently, more and more platform gates have been installed. The data clearly shows that platform gates prevent accidents involving people, but even so, within the scope of my research, there have been two people who have jumped over the platform gates and killed themselves.

ホームゲートを飛び越える気力が残っているなら、私なら、もっとラクで確実な自死方法をアドバイスできると思います(こっちにも書いてあります)。

If you still have the energy to jump over the home gate, I think I can advise you on a more comfortable and reliable method of suicide (it's also written here).

-----

強風、豪雨、豪雪、列車過密、信号機トラブル、車内設備トラブル、人身事故、乗客トラブル、人身事故....

High winds, heavy rain, heavy snow, overcrowded trains, signal trouble, in-train equipment trouble, personal injury, passenger trouble, personal injury...

「世の中思い通りにならない」ということは、当たり前なのですが、その当たり前が、なかなか、受け入れがたいものです。

It's evident that “the world doesn't always go how you want it to,” but it's not easy to accept that obvious fact.

2025,江端さんの忘備録

私が町内会の役員をやらされていた時、町内会でWeb管理担当していた人が、突然引越ししてしまって、その役が私に回ってきたことがありました。

When I was appointed an officer of the neighborhood association, the person in charge of web management suddenly left, and I took on the role.

私は、従来のWebシステムを全部廃棄して、WordPressでスクラッチから作り直しました。

I scrapped the existing web system and rebuilt it from scratch using WordPress.

その上で、町内会館の予約管理システムは、Googleスプレッドシートだけを使用するものにして、3ページくらいの運用手順マニュアルだけを残して、退任しました。

After that, I left the management system for the community center's reservation system using only Google Spreadsheets. I left behind only a three-page operational procedure manual and retired.

頼まれれば、Web管理くらいサポートするつもりはあったのですが、誰一人として私に頼まなかったので、私もそのままにしてきました。

I was willing to help with web management if asked, but since no one asked, I left it as it was.

私が任期満了で退任した後も、同じ仕様のまま稼動し続けているようです。

It seems it still operates with the exact specifications even after I left office at the end of my term.

町内会のWebシステムは、『予約システム』と『町内会報表示システム』があれば、十分で、これ以上の機能を実装してはダメだと思っています。

A neighborhood association's web system is sufficient if it has a 'reservation system' and a 'neighborhood association newsletter display system,' it should not have any more functions than that.

下手な機能を入れると、役員の入れ替え時に、運用継承に失敗してコケます。

If you add a poorly designed function, it will fail to inherit operations when the board of directors is replaced, and you will look foolish.

-----

どの会社も、新システムの構築を簡単に提案しますが ―― 私は、新システム導入に対してはネガティブです。

Every company will easily propose building a new system, but I am pessimistic about introducing a new system.

旧システムを、チマチマと部分リプレースをし続けていく方が、ラクなんじゃないかな、と思うことがあります。

Sometimes, I think it would be easier to continue replacing parts of the old system bit by bit.

私の考える、システムの最優先課題は「動くこと」「停止しないこと」、さらに加えるのであれば「ユーザインターフェースを極力変えないこと」です。

The top priorities for the system, in my opinion, are “working” and “not stopping,” and if I could add one more, it would be “not changing the user interface as much as possible.”

『新しいことに飛びつかない』『必要最低限必要なサービスを、これから100年も続ける』という、サウスウエスト航空のポリシーに、古都(京都)の和菓子屋、呉服屋、伝統工芸の精神を垣間みる思いでした。

そんなことを、最近のNHKと日本IBMの事件(*)のニュースを見ながら考えていました。

I was thinking about this while watching the news about the recent NHK and IBM Japan incident (*).

(*)NHKは、受信料契約などを管理する新しい営業基幹システムの開発を日本IBMに委託していましたが、納期の大幅な遅延が見込まれるとして、2024年8月に契約を解除しました。これに伴い、NHKは既に支払った約30億円の返還と損害賠償を求め、総額約54億7千万円の訴訟を東京地方裁判所に提起しました。

(*) NHK had commissioned IBM Japan to develop a new core business system to manage subscription contracts, but in August 2024, it canceled the contract due to the expected significant delivery delay. In response, NHK filed a lawsuit in the Tokyo District Court seeking the return of the approximately 3 billion yen it had already paid and compensation for damages, for approximately 5.47 billion yen.

『どっちの言い分も、よく分かるなぁ』というのが、私の感想です。

My impression is that I can understand both sides of the argument.

そもそも、この手の事件は、私にとって、他人事ではありません。

To begin with, this kind of incident is not someone else's problem for me.

-----

企業が旧システムを使い続けるデメリットは、沢山あります。

There are many disadvantages to companies continuing to use old systems.

■コードのスパゲッティ化や互換性の問題が蓄積し、運用・保守が困難、かつ高くなる。技術者もいなくなる。パフォーマンスも悪くなる。

■The accumulation of code spaghetti and compatibility issues makes operation and maintenance difficult and expensive. There will also be a shortage of engineers. Performance will also deteriorate.

■セキュリティリスクが残り続ける

■Security risks continue to persist

の他に、企業として致命的なデメリットは、

In addition, there are also fatal disadvantages for companies, such as

■競争力のあるビジネス基盤にならない

■ It will not become a competitive business base.

■モバイル対応やシングルサインオン（SSO）など、時代のニーズに答えられない

It does not meet the needs of the times, such as mobile support and single sign-on (SSO).

があります。

そもそも、町内会のシステムと、企業の基幹システムでは、「モノ」が違います。町内会には、競争も競合も新サービスも必要ありません。

To begin with, the systems of neighborhood associations and core corporate systems are different. Neighborhood associations do not need competition, rivalry, or new services.

企業は「のんきに、旧システムのリプレースを続ける」などとは言ってられないのかもしれません。

Companies may not say, “We'll just continue replacing old systems without a care in the world.”

-----

システムとは『"動かない"が"デフォルト"で、動いたら"ラッキー"』なものであり、そのラッキーの上に、次のラッキーが詰み重なってできているものです。

A system is “unmoving by default, and if it moves, it's ‘lucky,’” and any system of one lucky thing piled on top of another.

私たちの世界を支えているものが「ラッキー」でできている、という事実は、あまり理解されていないです。

The fact that the things that support our world are made of “lucky” is not well understood.

例えば、高村薫さんの著書『神の火』の中では、原子炉の制御システムが経験値を踏襲しているものがほとんどで、そのパラメタに論理的な根拠がない(ものが多い)、という事実が記載されています ―― これをフィクションとして読み流せる人は、たぶんエンジニアではありません(エンジニアなら、この恐しさに震えなければなりません)。

For example, in the book “Kami no Hi” by Takamura Kaoru, it is stated that most of the control systems for nuclear reactors are based on empirical values and that many of these parameters have no logical basis - people who can read this as fiction are probably not engineers (engineers should be trembling with fear).

社会インフラのシステムも同様です。今、流行のDDOS攻撃なんぞは、システムの入口への攻撃に過ぎません。

The same is true of social infrastructure systems. DDOS attacks, which are popular at the moment, are just attacks on the entrance to the system.

一度、攻撃者にシステムの侵入を許したら、もう、そのシステムは死に体も同然です。

Once an attacker has gained access to a system, it is as good as dead.

システムを作った人間や、あるいはシステムの内部の運用者が攻撃者になれば、システムの破壊は防ぎようがありません。

If the person who created the system or the operator of the system becomes the attacker, there is no way to prevent the destruction of the system.

そう考えていくと、私たちの社会システムは、結構な「性善説」で成りたっているのです。

When you consider it, our social system is based on a somewhat optimistic view of human nature.

-----

ところで、町内会のWebサイトのトップページに『退会届け』のメニューを作り込んだのは、私です。

By the way, I was the one who added the “Withdrawal Form” menu to the top page of the neighborhood association website.

まだ、Webデザインの変更はされていないようです。

It seems that the web design has not been changed yet.

変更できる人がいないだけかもしれませんが。

It may just be that no one can make the change.

未分類

🔷 まとめ

移行方法 確実にデータを移行できるか？ リスク
docker commit + docker save/load ❌ データがボリュームにあると移行できない データが失われるリスクあり
Docker Volume を使う ✅ どの環境でも確実に移行できる リスクなし（安全）

✅ 「どちらか分からないなら、Docker Volume を使うのが安心！」

ボリュームを使っていれば確実にバックアップされるし、もしコンテナの中にデータがあっても問題なく移行できるので、安全な方法！ 🎯

2025,江端さんの忘備録

11日の休日は、

On the 11th, my holiday,

(1)午前中に、Docker Desktopからコンテナをエクスポートして、別のマシンのWindowsのWSLにDocker環境を構築してインポートし、

(1) in the morning, I was going to export a container from Docker Desktop, build a Docker environment on Windows WSL on another machine, and import it,

(2)午後からは日本語のドラフトを英文カンファレンスペーパーにする

(2) in the afternoon, I was going to turn a Japanese draft into an English conference paper

つもりでした。

スマートに、エレガントに、コーヒーカップを片手にしながら。

Smartly and elegantly while holding a cup of coffee in my hand.

なのに、なんでどうしてこうなる？

But why did it turn out like this?

―― 翌日の深夜午前4時まで、連続18時間格闘し続けて、上記『午前中』の処理が、まだ完了していない(継続中)

I continued to fight for 18 hours straight until 4 am the next day, and the above 'morning' process is still incomplete (still ongoing).

複数のマシンにばらまいていたDockerのデータベースの中身がスカスカで、バックアップのほぼ全部が「ザル」であったことが分かり、心底青さめています。

I was disappointed to find that the contents of the Docker database, which had been spread across multiple machines, were very sparse and that almost all of the backups were “sieve-like.”

今やれることは、何でもやっている、という感じです。

I feel like I am doing everything I can right now.

イントラネットの実験用のマシンとして使うために、Windowsのセキュリティを全解除したいです(pingとか、ポートオープンとか面倒くさい）。設定方法を教えてください。

バックアップが不安な状態が続く状態が怖くて、1秒も早くこの作業を完了したいのですが、定例と出張で、そんな時間取れません。

I'm scared that the uncertainty about the backup will continue, and I want to complete this task as soon as possible, but I can't find the time to do it with my regular work and business trips.

なんか体調も悪くなってきました(喉が痛い)。

I'm starting to feel unwell (my throat hurts).

こんな気持ちと体調のまま、週末に突入するのか、と考えるだけで、死ぬほど憂鬱(ゆううつ)です。

Just thinking about entering the weekend with these feelings and physical condition is enough to make me feel depressed to the point of death.

だれか、私に「大丈夫だよ。なんとかなるよ」と、耳元でささやいて欲しい。

I want someone to whisper in my ear, “It's okay. You'll manage somehow.”

嘘でもいいから。

Even if it's a lie.

未分類

Windowsのセキュリティを全解除する方法を説明します。ただし、これはセキュリティリスクが極めて高いため、イントラネット内での実験用に限定し、外部ネットワークに接続しないことを強く推奨します。

1. Windows Defender ファイアウォールを完全無効化

方法1: コマンドで無効化

管理者権限のPowerShellを開いて、以下のコマンドを実行してください。

powershell
Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False

これで、全ネットワークプロファイルのファイアウォールを無効化します。

とりあえず、ここまででいいかな。

方法2: GUIで無効化

  1. ファイアウォールとネットワーク保護 を開く
  2. ドメイン ネットワーク、プライベート ネットワーク、パブリック ネットワーク の3つ全てを「オフ」にする

2. Windows Defenderのリアルタイム保護を無効化

管理者権限のPowerShellで以下を実行：

powershell
Set-MpPreference -DisableRealtimeMonitoring $true

GUIで行う場合：

  1. Windows セキュリティ → ウイルスと脅威の防止
  2. ウイルスと脅威の防止の設定 → リアルタイム保護 をオフにする

3. Windows SmartScreenを無効化

管理者権限のPowerShellで以下を実行：

powershell
Set-ItemProperty -Path "HKLM:\Software\Microsoft\Windows\CurrentVersion\Explorer" -Name SmartScreenEnabled -Value Off

GUIで行う場合：

  1. Windows セキュリティ → アプリとブラウザーコントロール
  2. SmartScreen の全項目をオフにする

4. UAC（ユーザーアカウント制御）を無効化

レジストリを変更することで完全無効化できます。

powershell
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" -Name EnableLUA -Value 0

変更後、再起動が必要です。

5. Pingを許可

ICMP（ping）を許可するには、以下のコマンドを実行：

powershell
New-NetFirewallRule -DisplayName "Allow ICMPv4" -Protocol ICMPv4 -IcmpType 8 -Action Allow -Direction Inbound

6. すべてのポートを開放

方法1: 特定のポートをすべて開放

以下のコマンドで全ポートを開放：

powershell
New-NetFirewallRule -DisplayName "Allow All Ports" -Direction Inbound -Action Allow -Protocol Any -Enabled True

方法2: ファイアウォールを完全無効化

上記の**「1. ファイアウォールを無効化」**を実施すれば全ポート開放されます。

7. Windows Updateの無効化

Windows Updateを完全に無効化したい場合：

powershell
Stop-Service -Name wuauserv -Force
Set-Service -Name wuauserv -StartupType Disabled

8. 共有フォルダの制限解除

管理者権限のPowerShellで、SMBの制限を解除：

powershell
Set-SmbServerConfiguration -EnableSMB1Protocol $true -Force
Set-SmbServerConfiguration -EnableSMB2Protocol $true -Force

さらに、ファイル共有を完全開放するには以下を実行：

powershell
New-SmbShare -Name "Shared" -Path "C:\Shared" -FullAccess Everyone

"C:\Shared" を共有フォルダとして、全ユーザーにフルアクセスを付与します。

9. リモートデスクトップを有効化

RDPを有効にするには、以下のコマンドを実行：

powershell
Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Terminal Server" -Name fDenyTSConnections -Value 0
Enable-NetFirewallRule -DisplayGroup "Remote Desktop"

10. 自動ログインの設定

特定のユーザーで自動ログインしたい場合、以下のレジストリ設定を変更：

powershell
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" -Name AutoAdminLogon -Value "1"
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" -Name DefaultUserName -Value "YourUserName"
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" -Name DefaultPassword -Value "YourPassword"

注意点

  • 外部ネットワークには絶対に接続しないこと
  • 一度無効化したら、戻すのも手間がかかるため慎重に
  • Windows Updateを止めると脆弱性が残るので要注意

イントラネット環境での実験用なら問題ありませんが、セキュリティリスクを理解した上で行ってください。

2025,江端さんの技術メモ

DockerのPostgreSQLデータベースをWindows→WSLのDockerへ移行する方法

Windows上のDockerで動作するPostgreSQLデータベースを、WSL（Windows Subsystem for Linux）のDockerに移行する 手順を説明します。

🔷 方法 1: Dockerボリュームごと移行する（推奨）

Windowsでは grep や busybox は不要 で、標準的な PowerShellコマンド を使用して移行できます。

📌 ① ボリューム名を確認

まず、PostgreSQLのデータが保存されているボリューム名を確認します。

powershell
docker volume ls

出力例：

DRIVER VOLUME NAME
local hakata_db-data

この hakata_db-data がPostgreSQLのデータが格納されているボリュームです。

📌 ② ボリュームをtarファイルにバックアップ

PowerShellを管理者権限で開き、以下のコマンドを実行します。

docker run --rm -v hakata_db-data:/data -v C:\Users\tomoi\backup:/backup ubuntu tar czf /backup/hakata_db_backup.tar.gz -C /data .

重要なポイント

  • C:\Users\tomoi\backup はWindows側のバックアップ保存先（任意のフォルダを指定）
  • ubuntu イメージを使用（busybox は不要）
  • hakata_db_backup.tar.gz という圧縮ファイルが作成される

この hakata_db_backup.tar.gz をUSBやネットワーク経由で 移行先のマシンへコピー します。

📌 ③ WSLのDocker環境にファイルをコピー

WSLのファイルシステムにバックアップを移動します。

powershell
wsl

WSL内で以下のコマンドを実行して、WindowsのバックアップファイルをWSLの /home/ ディレクトリにコピー。

cp /mnt/c/Users/tomoi/backup/hakata_db_backup.tar.gz /home/

📌 ④ WSLのDockerでボリュームを作成

WSL内で以下を実行し、新しいボリュームを作成します。

docker volume create hakata_db-data

作成したボリュームにデータを展開します。

docker run --rm -v hakata_db-data:/data -v /home:/backup ubuntu tar xzf /backup/hakata_db_backup.tar.gz -C /data

📌 ⑤ WSLのDockerでPostgreSQLコンテナを起動

WSL内で以下を実行し、データをマウントしたPostgreSQLコンテナを起動。

docker run -d --name postgres_hakata -p 15432:5432 -v hakata_db-data:/var/lib/postgresql/data postgres:16

📌 ⑥ データが正しく復元されたか確認

PostgreSQLコンテナに接続してデータを確認。

docker exec -it postgres_hakata psql -U postgres

データベース一覧を表示：

\l

2025,江端さんの技術メモ

音声を無視して、最も一般的な webm → mp4 変換コマンドは以下のようになります。

ffmpeg -i input.webm -vf "scale=640:360" -r 5 -c:v libx264 -preset slow -crf 23 -an output.mp4

説明：

  • -i input.webm：入力ファイルの指定
  • -vf "scale=640:360"：解像度を640x360に変更
  • -r 5：フレームレートを5fpsに変更
  • -c:v libx264：H.264コーデックでエンコード
  • -preset slow：エンコード速度と圧縮率のバランスをとる（品質優先）
  • -crf 23：品質を指定（数値が低いほど高品質）
  • -an：音声を削除（無音にする）
  • output.mp4：出力ファイルの指定

このコマンドで、音声なしの mp4 に変換できます。

2025,江端さんの忘備録

技術の世界は、

The world of technology is a strange world where

(1)先頭を走らなければ負け

(1) if you don't run at the front, you lose

と

and

(2)先頭を走ったら負け

(2) if you do run at the front, you lose

が併存する、不思議な世界です。

coexist.

-----

まず「(1)先頭を走らなければ負け」というのは、新技術に対して大胆に挑戦し続けなければ、技術で生きている会社は生き残れない、という現実があります。

Firstly, “(1) If you don't run at the front, you lose” is a reality that companies that survive on technology cannot survive unless they continue to take on new technology boldly.

スマートフォン市場におけるAppleの事例がわかりやすいと思います。

I think the example of Apple in the smartphone market is easy to understand.

Appleは2007年にiPhoneを発表し、スマートフォン市場の覇権を握りました。

Apple announced the iPhone in 2007 and took control of the smartphone market.

それまでの携帯電話市場はNokiaやBlackBerryが支配していましたが、タッチスクリーンを中心とした新しいUIを導入し、アプリストアというエコシステムを作ったことで、新たな市場を開拓し、技術革新をリードすることで市場を支配するチャンスを得ました。

Until then, Nokia and BlackBerry had dominated the mobile phone market. However, by introducing a new UI centered around touch screens and creating an app store ecosystem, they were able to develop a new market and seize the opportunity to dominate it by leading technological innovation.

技術の進化が激しい分野では、先行しなければ市場において埋もれてしまうのです。

In fields where technology is evolving rapidly, we will be left behind in the market if we don't keep up.

例えば、日本の家電メーカーは液晶テレビやスマートフォン市場でかつて強かったが、新しい技術トレンドに適応できず、海外メーカーに市場を奪わるに至っています。

For example, Japanese home appliance manufacturers used to be strong in the LCD TV and smartphone markets. However, they have not adapted to new technological trends, and overseas manufacturers have dominated the market.

-----

次に「(2)先頭を走ったら負け」というのは、新技術を業界デファクトスタンダードにできなければ、結局、後発技術の方に足並みをそろえなければならなくなって、先行投資のお金をドブに捨てることになる、という現実です。

Next, “(2) If you run at the front, you lose” refers to the reality that if a new technology can't become the industry standard, you'll have to adopt the latecomer's technology, which will result in throwing away the money you invested in advance.

Google Glassの失敗が挙げられるかと思います。

I think the failure of Google Glass can be cited.

Googleはウェアラブルデバイスの未来を見据えて、2013年にGoogle Glassを発表しましたが、市場はまだその技術を受け入れる準備ができておらず、プライバシーの問題などもあって普及しませんでした。

Google announced Google Glass in 2013 with an eye to the future of wearable devices. Still, the market was not yet ready to accept the technology, and it did not become popular due to privacy concerns.

結果として、Googleはこのプロジェクトを一旦終了し、後発のARグラスやVR市場に歩調を合わせる形として継続しています。

As a result, Google has ended this project for the time being and is continuing it in a way that keeps pace with the later AR glasses and VR markets.

日本人にとって最も有名なケースは、ソニーのベータマックスです。

The most famous case that Japanese people know of is Sony's Betamax.

ベータマックスは、VHSよりも技術的に優れていましたが、業界の標準を獲得できなかったため、結果的に市場で敗北しました。

Betamax was technically superior to VHS but failed to gain industry-standard status and was ultimately defeated in the market.

このケースは、技術的に先行していても、業界全体の流れを作ることができなければ、競争に勝てないことを、日本のエンジニアに骨の髄まで思い知らせた超有名な事例です。

This famous case made Japanese engineers realize to the bone marrow that even if we are technically ahead and cannot create a trend for the whole industry, we will not be able to win the competition.

-----

昨日も記載しましたが、私は、PostgreSQL + PostGISを使い倒しています(日本一のヘビユーザではないか、と自負しています)。

As I mentioned yesterday, I use PostgreSQL + PostGIS to the full (I'm proud to say that I'm probably the biggest PostGIS user in Japan).

これなら「プログラムを一切変更せずに」金の力だけで解決できます！

高速のデータベースがあれば、飛び付きたい気持ちがありますが、ここに、「(1)先頭を走らなければ負け」と「(2)先頭を走ったら負け」の現実が立ち塞がります。

If there were a high-speed database, I would be tempted to jump at the chance, but here is the reality of (1) “If you don't run at the front, you lose” and (2) “If you run at the front, you lose” stands in the way.

どんなに良いデータベースであったとしても、それを他の人に使いこなして貰えないのであれば、それを組み込んだ私の作ったシミュレータは死蔵し、そして、私の死後に完全に消滅します。

No matter how good the database is, if other people can't use it, the simulator I made incorporating it will gather dust and completely disappear after my death.

まあ、それはそれで良いのですが ―― 開発現場の人間の一人としては、世界中の人が使っているデータベースは、問題が発見しやすく、トラブル対応が早くすむ、という利点は見逃せません。

Well, that's O.K., but as someone working in development, I can't ignore the advantages of a database that is used by people all over the world, such as the fact that it makes it easier to find problems and respond to issues quickly.

RTNETLINK answers: No such file or directory と言われます。

-----

まあ、技術の現場の人間の一人としては、この「(1)先頭を走らなければ負け」と「(2)先頭を走ったら負け」の二律背反にどう対処していくか、と問われれば、

Well, as someone working in the field of technology, I'm wondering how to deal with the two opposing ideas of “(1) If you don't run at the front, you lose” and “(2) If you run at the front, you lose”, and  I think the answer is

―― 『デカイ技術革新』の一発勝負ではなく、『セコイ技術革新』のチマチマした継続

'Rather than a single shot at a “major technological innovation,” a steady continuation of multiple “minor technological innovations”'

ということになるかなぁ、と思っています。

この話、特許明細書を考えるときのプロセスと同じです。

This is the same process as when thinking about a patent specification.

「創作だけは機械にできない」と言われていますが、私がChatGPTを使い倒している日々において、私は、"これ"すらも"否定"できます。

 

未分類

現在、1万8000人分の毎日のマルチエージェントシミュレーションを行っているのですが、私が持っている最速のマシンでも、1年間(365日)の計算に4.2日かかることが分かりました。

これ、お金で解決するなら、なんとかしたいと思います(とは言え、10万円くらいを上限でお願いします)

現状の条件は下記の通りです。

(1)Postgresql + PostGISで、おそらく数百万回以上のダイクストラ計算をしている。

(2)準備しているエージェントは約22万、で、この大半が条件エラーでオミットされている。

(2)DBの負荷を下げるために、1台のホストと2台のDBコンピュータを並列で使っている。但し、DBははDockerで動かしている。

で、私の要求仕様は以下の通りです。

(1)プログラムを1行も改造したくない。プログラムだけで、現在200を超えている。これらを改造している時間はない。

(2)プログラム言語はGo言語。スレッドや並列処理は使っていない(使わないようにコーディグしました)。

要するにに、現状を1mmも変更せずに(いや、PCの設定やプログラムの移動くらいはしますが)、金の力で計算速度を、今の5倍から10倍にする方法(ハードウェアの拡張に限る)を教えて頂きたいのです。

当面の目標は「1年間365日シミュレーション/24時間以内」です。

-----

因みに、クラウドを使い倒すとか、PC買うとか、そういうことは、もう検討済みです。プログラムも改造の余地はありますが、そんな時間はなく面倒くさいです。そういう提案でしたら、ご遠慮申し上げます。

「ハードウェア(物品)の購入だけで、計算の高速化ができる方法」のみ歓迎いたします。

よろしくお願い致します。

 

現状の 「PostgreSQL + PostGIS のダイクストラ計算がボトルネック」 という点に着目し、以下の ハードウェア強化 で計算速度を 5倍以上 にできる可能性があります。

1. ストレージの劇的な高速化（最優先）

NVMe SSD (PCIe 4.0または5.0) に換装

  • PostgreSQL + PostGIS のダイクストラ計算は、ランダムアクセス I/O が大量発生 するため、最も効果があるのは ストレージの超高速化 です。
  • SATA SSD → PCIe 4.0 NVMe SSD に変更するだけで 4倍～10倍の高速化 が可能。
  • 可能なら PCIe 5.0対応の高性能SSD にするとさらに高速化。

【推奨ストレージ】

  • Samsung 990 PRO (PCIe 4.0, 2TB)
    • 読込 7,450MB/s, 書込 6,900MB/s（実測ランダムIOPSも超高速）
    • 価格：約2.5万円
  • Crucial T700 (PCIe 5.0, 2TB)
    • 読込 12,400MB/s, 書込 11,800MB/s
    • 価格：約4万円
  • Micron 9400 Pro (PCIe 4.0, 3.84TB, Enterprise向け)
    • ランダムIOPS特化、DB用途向け
    • 価格：約8万円

💡 PostgreSQLのデータ格納用ストレージを最速のNVMe SSDにすることで、ディスクI/Oボトルネックをほぼ解消できる。

2. メモリ増設（DBのキャッシュヒット率向上）

  • PostgreSQL の shared_buffers と OS の page cache が十分に働くようにメモリを増設
  • 現在のメモリが 32GB 以下なら、128GB まで増設することを推奨。
  • PostgreSQLはデフォルトでは shared_buffers が小さいため、メモリ増設後、postgresql.conf で以下のように設定変更：
    conf
    shared_buffers = 32GB # 現状の8倍くらいを目安
    work_mem = 256MB # 一時計算用メモリを増やす
    effective_cache_size = 96GB # OSのキャッシュ利用を最大化
  • 64GB～128GBのメモリを積めば、DBキャッシュヒット率が爆上がりし、ディスクアクセスが激減する。

【推奨メモリ（DDR4/DDR5）】

  • Corsair Vengeance LPX 64GB (2 x 32GB, DDR4-3200)
    • 価格：約2.2万円
  • Kingston FURY Beast DDR5 64GB (2 x 32GB, DDR5-5600)
    • 価格：約2.8万円
  • 128GBに増設する場合、4 x 32GBで対応可能。

💡 DBのキャッシュヒット率が上がれば、ダイクストラ計算の待ち時間が大幅に短縮される。

3. DB専用マシンの強化（CPUとPCIeバンド幅の最適化）

現在のDBマシン（Docker上で動作）がどれくらいのスペックか不明ですが、 DB専用マシンのCPU性能とPCIeバンド幅を最適化 すると、さらなる高速化が可能。

【推奨DBサーバー構成】

  • CPU：Ryzen 9 7950X3D (16コア, 5.7GHz, 3D V-Cache 128MB)
    • DBのインデックスキャッシュに3D V-Cacheが爆効く
    • 価格：約7万円
  • マザーボード：ASUS PRIME X670-P
    • PCIe 5.0 NVMeスロット搭載
    • 価格：約2万円
  • メモリ：64GB DDR5
    • 価格：約2.8万円
  • ストレージ：Micron 9400 Pro 3.84TB (PCIe 4.0)
    • 価格：約8万円（ただし、予算オーバーのためSamsung 990 PROで妥協可）

💡 DB専用機を組むなら、3D V-Cache搭載のRyzen 9 7950X3D が最強選択肢。

4. Dockerのチューニング（不要ならネイティブ動作へ）

  • DockerがI/Oボトルネックになっている可能性あり。
  • 「直接ホストOS上でPostgreSQL + PostGISを動かせるなら、Dockerをやめる」 ことで、数%～20%のパフォーマンス向上。

💡 ただし、プログラム改造なしの方針なので、無理に変えなくてもOK。

結論（予算内で最強の選択肢）

✅ 必須購入

項目 製品 価格
ストレージ Samsung 990 PRO 2TB (PCIe 4.0) 2.5万円
メモリ 64GB DDR4/DDR5 (32GB x 2) 2.2万円
CPU (オプション) Ryzen 9 7950X3D (16コア, 128MB 3D V-Cache) 7万円
  • 最優先はSSD換装（NVMe PCIe 4.0以上）
  • 次にメモリ64GB化
  • 余裕があればDB専用マシンを Ryzen 9 7950X3D に更新（3D V-Cacheでダイクストラ爆速化）

💡 SSD & メモリ増設だけでも、計算時間 4.2日 → 1日以下 に短縮できる可能性大。

最適化後の期待値

改善項目 速度向上の目安
NVMe PCIe 4.0 SSD 2倍～4倍
メモリ 64GB 1.5倍～2倍
CPU Ryzen 9 7950X3D 1.2倍～2倍

💡 合計で「5倍以上」の高速化が可能。目標の24時間以内も見えてくる。

✅ 10万円以内で可能な最強のハードウェア高速化策

  • Samsung 990 PRO (2TB, PCIe 4.0) に換装
  • メモリ64GB（可能なら128GB）に増設
  • 余裕があれば Ryzen 9 7950X3D 搭載のDB専用機を構築

この3つの施策で、 「4.2日 → 24時間以内」 が実現できる可能性が極めて高い。

💰 これなら「プログラムを一切変更せずに」金の力だけで解決できます！