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

2025年2月12日未分類

🔷 まとめ

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

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

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

Dockerコンテナのイメージをセーブして先方に送る方法

2024年8月28日未分類

docker images をやったのですが、同じ名前のdocker imagesが出てくるのですが、どれが最新なのか見分ける方法を教えて下さい。

↓

同じ名前のdocker imagesが出てくるのですが、どれが最新なのか見分ける方法を教えて下さい。

↓

CREATED も同じく"2months"になっていて見分けがつきません。ですので、例えば、Dockerコンテナを動かして確認する方法はありませんか。現在、私は "docker-compose start" をした後にシェルでDocker内部に入っているのですが、この状況からの確認方法を教えて下さい

Dockerの外側（ホストOS）から稼働中のDockerコンテナを確認するには、いくつかの方法があります。以下は、その代表的な方法です。

1. `docker ps` コマンドで稼働中のコンテナを確認

ホストOS上で、現在稼働中のコンテナを一覧表示するために、以下のコマンドを使用します。

docker ps

cam@cam-desktop:~$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
c928a6ab4e6b u2404b-dev-environment "/bin/bash" 4 days ago Up About an hour u2404b-dev-environment-1

という表示がでてきました。
このイメージをsaveする方法を教えてください。

1. イメージを保存する
まず、docker save コマンドを使用してイメージをファイルに保存します。以下のコマンドを実行してください。

$ docker save -o u2404b-dev-environment.tar u2404b-dev-environment

このコマンドは、u2404b-dev-environment という名前のイメージを u2404b-dev-environment.tar というファイルに保存します。

2. 保存されたファイルを確認する
保存が完了したら、ファイルが正しく作成されたか確認します。

$ ls -lh u2404b-dev-environment.tar

このコマンドで、保存されたファイルが存在し、適切なサイズであることを確認できます。

あとは、zip等で固めて、先方に送付すればO.K.

-----

保存したイメージを他の環境でロードするには、どうしたら良いですか。

もし他の環境に移動してこのイメージを使用したい場合、docker load コマンドを使用してイメージをロードします。

ファイルを解凍して、

$ docker load -i u2404b-dev-environment.tar

これにより、保存されたイメージが再びDockerにインポートされ、使用可能になります。

ところが、この方法では、自力で設定した環境などが全く引き継がれないらしいです。

送付いただいたものはgstreamer、コンパイル環境が入っていない状態でした。
お手数ですが、コンテナをcommitしてsaveしたものを送付願います。
(参考:https://sagantaf.hatenablog.com/entry/2018/09/04/190801)

上記の参考資料の通りにやってみることにしました。

(Step.1) まず、ゲストOSを立ち上げておいて、ホストOSから以下のコマンドを投入します
cam@cam-desktop:~$ sudo docker ps

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
c928a6ab4e6b u2404b-dev-environment "/bin/bash" 4 days ago Up 3 hours u2404b-dev-environment-1

(Step.2) 次に、このc928a6ab4e6bを使って、20240828_shajyoという名前(名前は好きなように)でコミットします

cam@cam-desktop:~$ sudo docker commit c928a6ab4e6b 20240828_shajyo
sha256:ac3405c474d294e5b5d0bd9a8cdc51a600f8cd3d04685877cecfb772e284b17e

# コミットしている最中、ゲストOSにアクセスできなくなるようですが、恐れず、じっと我慢しましょう。

(Step.3) コミットに成功しているかを確認します

cam@cam-desktop:~$ sudo docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
20240828_shajyo latest ac3405c474d2 4 minutes ago 2.5GB ← できている
u2404b-dev-environment latest 48248de5e524 2 months ago 1.23GB
<none> <none> dcb4a05fb5a5 2 months ago 1.23GB
<none> <none> 132165fbb602 2 months ago 986MB
u2404_dev-environment latest 940f87bcbccf 2 months ago 986MB
<none> <none> a4252fdea034 2 months ago 988MB
u2404-dev-environment latest a042684decc4 2 months ago 971MB
ubuntu 24.04 ffb64c9b7e8b 2 months ago 101MB
hello-world latest ee301c921b8a 16 months ago 9.14kB

(Step.3) 20240828_shajyoをセーブします

cam@cam-desktop:~$ docker save 20240828_shajyo -o 20240828_shajyo.tar

あとは、これをzip等で圧縮して、先方にお送りすれば良いです。

cam@cam-desktop:~$zip 20240828_shajyo.tar.zip 20240828_shajyo.tar

-----

これを展開するのは、多分、以下のようになると思います(というのは、私が試していないからです)

(Step. 1) 一旦、ホストOSからイメージを削除する
$ docker images

REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
20240101_shajyo          latest              3c053ce8d919        25 minutes ago      193MB

$ docker rmi 20240101_shajyo

(Step. 2) ホストOSから、ファイルからイメージを作成する

$ sudo docker load < 20240828_shajyo.tar

これでイメージが復活する(ハズ)とのことです。

ご対応ありがとうございました。
コンパイル環境と各プログラムがイメージに入っていることを確認しました。

というコメントをいただいたので、多分大丈夫です。

=======

今回イメージを受けとる側になりましたので、イメージの作成方法を追記します。

cam@cam-desktop:~/u2404b$ docker-compose start
service "dev-environment" has no container to start
と言われてしまいました。

解決手順

1. 現在のコンテナ状況を確認

まず、docker-compose.ymlのディレクトリに行きます。

現在のコンテナ状況を確認するため、以下のコマンドを実行します：

出力が空の場合、まだコンテナが作成されていないことを意味します。

2. コンテナを作成・起動

$ sudo docker load < 20241016_shajyo_latest.tar
でつくったもので
20241016_shajyo latest bf4a5d825daa 13 months ago 3.15GB
となっています。

もし 20241016_shajyo:latest を docker-compose.yml 内で使用する予定がある場合、以下の手順を考慮してください。

1. `20241016_shajyo:latest` を使用する場合

docker-compose.yml に以下のようにイメージ指定を追加します。

version: '3'

services:
  dev-environment:
    image: 20241016_shajyo:latest  # ロード済みのイメージを使用
    environment:
      DISPLAY: ${DISPLAY}
      XDG_RUNTIME_DIR: /tmp/xdg
    volumes:
      - /tmp/.X11-unix:/tmp/.X11-unix
      - /home/cam/u2404:/home/cam/u2404
    stdin_open: true
    tty: true
    network_mode: host

docker-compose up コマンドで、コンテナを作成して起動します：

--build は、新しいビルドが必要な場合に使用します。
-d は、デタッチモード（バックグラウンドで実行）を有効にします。

このコマンドで新しいコンテナが作成され、サービスが開始されます。

ところが、これでもDockerで作ったデータベース本体丸ごとでの移行はしないみたいです(ちょっと待った。現在これ検証中)。

結論：docker commit ではデータは移行されない可能性が高い！
データベースごと移行するなら docker volume をバックアップするか、pg_dump を使うべき

データベース本体と丸ごと持っていきたい場合は(も、あてにならないので、現在検証中)

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

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

2025年2月11日未分類

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

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

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

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

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

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

方法2: GUIで無効化

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

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

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

GUIで行う場合：

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

3. Windows SmartScreenを無効化

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

GUIで行う場合：

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

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

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

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

5. Pingを許可

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

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

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

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

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

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

7. Windows Updateの無効化

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

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

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

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

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

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

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

10. 自動ログインの設定

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

注意点

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

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

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

2025年2月10日未分類

現在、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時間以内」 が実現できる可能性が極めて高い。

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

国家と国民は別の主体

2007年9月28日未分類

これはコロラドに住んでいた時の話です。

デパートの階段の前で、嫁さんが、まだベビーカーに乗っていた当時二歳の娘をベビーカーから抱きかかえて、階段を上がろうとしていた時のことです。

はるか遠くから、全力疾走で走ってくるアメリカ人の男性二人。

娘の入ったベビーカーをガシっと掴むや否や、どどどどどーーとベピーカごと、娘を階段の上に運んでしまい、嫁さんが礼を言うまえに、ぱぱっと走って消えていってしまったそうです。

この話を聞いたとき、私は感動で背筋が震えたのを覚えています。

「『かっこいい』とは、こういうことだな」と、嫁さんと二人で頷きあっていました。

米国の生活の中で、ちょっと日本では味わえないような、(言い方は良くないのですが)数多くの「暴力的な好意」に出会いました。

-----

しかし、、、、

私が分からんのは、このような親切の塊でできているような(と私には見えることが多い)多くの米国人を代表する政府が、頼みもしないのに、他の国に出かけてまで戦争なんぞをしに行くのだろう、ということなのです。

もの凄い違和感を感じます。

-----

私の出会ったいわゆる米国の人は、自国の戦争方針に凄い嫌悪感を持っており、大統領の政策を批判して憚らない方が多かったようです。

例えば『ブッシュの中東政策は間抜けだ』というような意見です。

確かに、私も、政府の政策が、我々の意図と同一と思われたらかなわんと思うようなことが沢山あります。

「国家の人格」と「国民の人格」は完全に独立である、と考えないと、我々は大切なものを「国際的」に失なってしまうかもしれません。

私の趣味を、業務が奪っていく ――

2019年11月21日未分類

私の趣味を、業務が奪っていく ――

"Business takes my hobby."

20年ほど前に、私がLinuxのカーネルコンパイルをしていた時、「江端ぁ! オモチャのOSで、遊んでんじゃねーぞ!!」と叱られた話は、ここでしました。

Here is the story of how, about twenty years ago, I was beaten while compiling a Linux kernel: "Ebata! Don't play with the toy OS!"

大手自動車メーカが正式採用したEtherCATは、たまたま、私が、自宅のジャンクボックスに入っていたEtherCATスレーブを見つけて、人感センサのスレーブとして使いたかったからシステムを組んだだけです。

According to EtherCAT, which a significant automobile manufacturer officially adopted, the reason why I just built a system with EtherCAT is that I happened to find an EtherCAT enslaved person in my home junk box, and I wanted to use it as a human sensor enslaved person.

私が、ラズパイを使い始めたのは、私のこずかいで購入できる「サーバ運用ができるコンピュータ」が、ラズパイしかなかっただけです。

I only started using Raspberry Pi because it was the only "computer that can operate a server" that I could purchase on my own.

-----

私が、個人的な趣味で始め、そのプロセスで取得した技術(プログラムや電子回路)が、

The technology (programs and electronic circuits) that I started with my hobby and acquired through that process is

「会社の業務で使いまくられている」という現実に、

"used in the business of my company".

なんとなく、釈然としない思いをしています。

Somehow, I can't be convinced.

一般的にTCには2つのethのNICがあります。これを便宜的にeth1, eth2とします。上記のコマンドは、どの方向の帯域制限になりますか

2025年2月4日未分類

tc コマンドの帯域制限 (tbf や netem) は 送信（アウトバウンド, egress） に適用されます。したがって、上記のコマンドは eth0 から外部に送信されるトラフィック に対して帯域制限が適用されます。

eth1, eth2 の場合の制限方向

eth1 と eth2 がある場合、それぞれのインターフェースに tc を適用すると、次のようになります。

tc qdisc add dev eth1 root tbf rate 5mbit burst 10kb latency 1ms
- eth1 から外部へ送信するトラフィック（egress） に 5Mbps の帯域制限
tc qdisc add dev eth2 root tbf rate 5mbit burst 10kb latency 1ms
- eth2 から外部へ送信するトラフィック（egress） に 5Mbps の帯域制限

つまり、各インターフェースから送信される通信に適用される ため、受信（ingress）には影響しません。

受信（ingress）側の帯域制限をしたい場合

tc は基本的に送信 (egress) に適用されるため、受信 (ingress) の帯域制限を行うには ingress qdisc を利用するか、ifb (Intermediate Functional Block device) を使います。

eth1 の受信帯域を 5Mbps に制限する場合

これにより、eth1 への受信トラフィック を 5Mbps に制限できます。

まとめ

tc のデフォルトの動作では 送信（egress） のみ帯域制限される。
tc を eth1 に適用すると、eth1 から出ていく通信に制限がかかる。
受信（ingress）を制限したい場合は ifb デバイスを使う。

したがって、最初のコマンドは eth0 の送信（egress）方向 に適用される帯域制限になります。

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

2025年2月2日未分類

「『もうすぐやってくるぞ』詐欺」というもの一つとして、「シンギュラリティ」というものがあります。

One example of the “It's coming soon” scam is the concept of “singularity.”

この「シンギュラリティ」って、面白いんですよ。

This “singularity” is interesting.

第一に、「シンギュラリティ」なる"モノ"が数値で定義されておらず、未だに概念のみの存在であること。

Firstly, the concept of “singularity” is not defined by a numerical value and still only exists as a concept.

第二に、その発生予想時期が「現在から数年または数十年後」に、常に更新され続けていること。

Secondly, the expected time of occurrence is constantly being updated to “a few years or decades from now.”

まさに「永遠のシンギュラリティ」です。

It is truly the “Eternal Singularity”.

(↑コラムに飛びます)

(Jump to the column)

現在の私が、生成AI(ChatGPT等)を使い倒していることはご存知の通りです。

As you know, I am using generative AI (such as ChatGPT) to the fullest.

そして、生成AIが、完全に無知性であり、文章の作り方(単語の選択、文字の並び、文章の心地良さ)だけを、計算した結果を表示しているものであることは、こちらで説明しています。

I explain here that the generated AI is completely unintelligent and only displays the results of calculations on how to make sentences (choosing words, arranging letters, and determining how pleasant the sentence is).

(↑コラムに飛びます)

(Jump to the column)

人間の心とか知性とか呼ばれるものは、「しょせん、機械によって作らされる程度のものである」と、私は、人間の能力を『下方修正』しています。

I am 'downwardly revising' human abilities, saying that the human mind or intellect is “only something that is created by machines.”

私たち人間が考える「心」とか「知性」とか言うものは、単語の選択、文字の並び、文章の心地良さ程度の"モノ"や"コト"で、その大部分が決まる、といってもいいんじゃないか、と思うんです。

I think that the “mind” and “intelligence” that humans feel about are primarily determined by word choice, the letters' order, and the sentence's pleasantness.

この辺りについては、すでに、これまでも論じてきた通りです。

I have already discussed this area.

―― 私たちは、心地の良いコミュニケーションだけがあればいい

つまり、「『シンギュラリティ』なんて言葉は、もういらない」ということです。

In other words, “we don't need the word ‘singularity’ anymore.”

-----

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

It is said that “only creative work cannot be done by a machine,” but in my daily use of ChatGPT, I can even “deny” this.

多くの人は、「創作」というのが、「まっしろなキャンパスの中から、突然湧き上がる発想」みたいな考え方をしているかもしれませんが ―― これ、素人の考え方です。

Many people may think that “creation” is something like “an idea that suddenly springs up from a blank canvas,” - but this is the way of thinking of amateurs.

私のような、「特許明細書製造マシン」から見れば、「創作」とは、『既往技術の組み合わせによって、単なる組み合わせ以上の価値を生じさせるモノまたはコト』です。

From the perspective of a “patent specification manufacturing machine” like me, “creation” is “something or something that creates value beyond mere combination by combining existing technologies.”

つまり、発明とは「既存技術の足し算」と「その足し算以上の価値の生成」です。

In other words, the invention is “adding to existing technology” and “creating value greater than the sum of the additions.”

そして、ChatGPTは、この「組み合わせ」がビックリするくらい上手い。

And ChatGPT is surprisingly good at this “combination.”

「どうやって、その組み合わせを思いついた？」と尋ねたくなるくらいです。

I can't help but ask, “How did you come up with that combination?”

-----

例えば、私、昨夜、「人の交流度を上げる式の定式化の手法として、交流する場所の『粘性(動きにくさ)』を入れることができるか？」と、ChatGPTに尋ねたら、以下のように解答されて、度肝を抜かれました。

For example, last night, I asked ChatGPT, “Can the ‘viscosity (difficulty of movement)’ of the place of interaction be included in a formula to increase the degree of human interaction? "The following answer blew me away.

=====

「交流する場所の粘性が高いと親密度が高まる」という仮説を表現するのに適した物理法則として、以下が挙げられます。

The following are suitable physical laws for expressing the hypothesis that “the viscosity of a place for interaction increases intimacy.”

ハーゲン・ポアズイユの法則（粘性が高いと流動性が低下 → 人の移動が減り、親密度が増加）
Hagen-Poiseuille's law (when viscosity is high, fluidity decreases → human movement decreases, intimacy increases)
万有引力の法則（移動が制限されることで距離が縮まり、相互作用が強くなる）
Universal Law of Gravitation (distance is shortened, and interaction becomes stronger when movement is restricted)
ボルツマン因子（粘性が高くても、ストレスが大きいと親密度が下がる影響を考慮）
Boltzmann factor (even if viscosity is high, the effect of a large amount of stress lowering intimacy is taken into account)
粘性応力の関係（粘性が高いと流速勾配が小さくなり、固定的な関係が強まる）
Viscous stress relationship (when viscosity is high, the flow velocity gradient decreases, and the fixed relationship becomes stronger)

最も単純なモデルとしては、「親密度 $I$ は粘性 $η$ に比例する」という関係が適用でき、ハーゲン・ポアズイユの法則や万有引力の法則の変形で表現できる。

The simplest model is one in which “proximity I am proportional to viscosity η” can be expressed as a variant of the Hagen-Poiseuille law or the law of universal gravitation.

(以下、定式モデルの記述については、割愛)

(The following description of the formula model is omitted.)

=====

で、昨夜遅くまでChatGPTと議論して、この"粘性"について一般式に落し込むところまで完了しました。

So, I was discussing with ChatGPT until late last night, and we completed reducing this “viscosity” to a general formula.

この作業は『ChatGPTと一緒に「創作」をした』と断言できる内容です。

This content can be asserted as “creative work” done with ChatGPT.

少なくとも上記の私の「創作」の定義は、100%満たしています。

At the very least, my definition of “creation” above is 100% fulfilled.

-----

私たちは、シンギュラリティなど待っている必要はありません。

We don't need to wait for things like Singularity.

今、私たちに必要なのものは、生成AIの「使い倒し方」(あるいは、「引き出しの見付け方」)の一択だと思います。

I think that what we need right now is a way to “get the most out of” (or “find the best way to use”) generative AI.

まあ、正直に言えば、私は、この「使い倒し方」を、できるだけ長い間、誰にも知られたくないですが。

I want to keep the max” secret for as long as possible.

「まだChatGPTを使ってない人は『人生を悔い改めた方がいい』」 ―― と言った、ソフトバンクの孫社長に申し上げます。『いらんこと言うな』と。