自動化 on 或る阿呆の記

「誰にでも出来る仕事」は生物の叡智

Sat, 12 Sep 2026 00:20:06 +0900

「誰にでも出来る仕事」という言い回しがあります。これは基本的にはネガティブな意味を伴うものです。実際、そんなことを言う人は、明確に侮蔑の意図をもっていいます。

ですので当然ながら人に向かって言っていいことではありません。しかしそれとは別に、 「誰にでも出来る仕事」はほとんどの場合非常に高度で難しい仕事だ、という認識も必要です。

別に大した話ではありません。多くの鳥が空を飛ぶからといって、空を飛ぶのが簡単だとは言えない、という当たり前の話です。同様に、多くの人間が歩くからといって、歩くことが簡単とは言えません。本当に当たり前です。実際、このように言われれば誰だってそりゃそうだと言うでしょう。

しかし現実世界に適用されたとき、その当たり前を面白いほど忘れます。もしかすると、あなたも。

人手不足はAIとロボットによる自動化で解決と思ってませんか

たとえば、人手不足が問題だというとき、皆簡単にロボットによる自動化、機械化、AIによる置き換え、といいます。言ってますよね。出来るんですか、機械に。

奇妙な話です。空飛ぶクルマは難しいとわかるのに、なかなか配膳ロボットはそのように考えられない。それは結局のところ、誰にでもできる仕事は簡単だと思っているからではないのでしょうか。だって、誰でも出来るから。

ここで、 「簡単」とは誰にとってなのか、が問題になります。鳥にとって簡単なことは人間にとって簡単ではない。同様に、人間にとって簡単なことは、機械にとって簡単ではない。極めて単純な道理です。

注文の機能はタッチパネルで実現できると思ってませんか

この単純な道理を、社会は忘れても、少なくともエンジニアは忘れません。さすがに。それが仕事なので。しかしそれにも関わらず、結局エンジニアも同じ間違いをします。ここが厄介なところです。

エンジニアは人間の得意分野と機械の得意分野を明確に分けます。たとえば騒音の中で自分の名前を呼ぶ声をきき、人混みをかき分けて障害物を避けながら声の方向に向かう、などは人間にとって簡単ですが機械にとっては地獄です。ついでに行く途中にゴミのポイ捨てを見つけたら、拾ってゴミ箱に捨てるなども人間はしてくれるかもしれません。しないかもしれませんが。ま、とにかくこれは機械には難しい。

ですので、たとえば店の中で注文をしようとする客の、なにかしらの合図を察知し、そこに向かい、注文をきき、厨房に戻る、というのはこれはロボットには難しいわけです。

しかし、ここでエンジニアは考えます。客がテーブルの上にあるタッチパネルを入力すればどうだろうか？それならば完全にシステム化が可能です。間違いは客の責任だし、精算や経理にも直結して効率的。なんなら客が自分のスマホで注文してくれたらタッチパネルもいらない。ええやん。

ということで、現在に至ります。

さて、これはどうでしょう、問題がなさそうでしょうか。もし問題がないと思うならば、誰にでも出来る仕事を簡単だと考えている、少なくともその亜種の考え方をしています。どういうことか。

これの問題は、注文を受けるという仕事を、単に一つの機能だと解釈していることです。しかし実際はそうではありません。注文を受ける間に、店内の様子を見て、困っている客がいればあとできき、注文の際には客の要望をきいたり、特別メニューの存在を教えたり、注文のついでに食べ終わった皿を片付けたりします。客とコミュニケーションを取ります。存在自体が店の雰囲気になり、また防犯になります。タッチパネルはそれらすべてを削ぎ落とします。

「誰にでも出来る仕事は簡単」の言い換えに陥らない

どうでしょう、世の中案外、「誰にでも出来る仕事は簡単」の言い換えが多いとわかるんじゃないでしょうか。みんなそうではないと知っているはずなのに、実際には適用を間違える。

無理もない話で、現実はゼロイチではなくグラデーションなので、ケースバイケースなんですよね。実際、機械化・システム化がうまくハマるケースもたくさんあります。タッチパネル一つとっても、ラーメン屋や定食屋で、特に安さがウリのチェーン店だったら、全然問題ないんじゃないでしょうか。何を食べるか最初から決まってますし、だいたい一品物ですし。メリデメでメリットのほうが大きそうです。でも夜の飲みまで考えているなら、それはちょっとどうでしょうね。まして居酒屋、これはもう全然合わないんじゃないでしょうかね。

それでも世の中導入されています。店員の仕事を単に一つの機能とみなすのは、エンジニアやシステム化を生業とするものが陥りがちな誤りですが、この誤りは経営者にとっても非常に魅力的にうつるはずです。だってそんなに簡単なら、機械にできる。機械にできるなら、人を使わなくていい。機械はコストカットである以上に、絶対に逆らわず黙々と働き続けるのが最高です。特に人間不信、あるいは自分が従業員から信用されると信じられない経営者にとって最高です。

まぁそんなわけで、恐らくこの適用範囲を間違えたDXは今後も続くかと思いますが、結局コストをかけて無駄なことをしているだけなので、そのうちに破綻するでしょう。セルフレジはもう既に揺り戻しが始まっているとも聞きますしね。

しかし何も破綻するまで待つ必要はないので、我々としては、誰もが出来る人類が身につけた叡智を、誇りをもってやっていきましょう。

AndroidでLAN内DNS(AdGuard Home)にIPv4アドレスでアクセスする

Tue, 11 Aug 2026 00:00:00 +0900

うちのプロバイダは楽天ひかりなのだが、楽天ひかりはIPv6必須となっている。で、LAN内DNSとしてAGHを利用しているのだが、最近のOSだとIPv6が優先されてLAN内ドメインの名前解決がうまくいかない。多分ルータとAGHでそれぞれIPv6の設定をきちんとやればうまくいくのだろうけれど1ミリもやる気が起きない。

なのでクライアント側でWi-fiネットワークの設定からIPv6を切っているのだが、PCはそれでよくてもスマホで詰まった。IPv6切れない。どうしてそういうことするの…。

環境

ルータ: TP-Link AX5400
サーバ: Linux Mint Xfce 22.3
- DNS: AdGuard Home(AGH)
- リバースプロキシ: Caddy
Android 15 (Pixel 7)
- RethinkDNS
- MacroDroid

やりたいことは、Android側でDNSをIPv4でAGH入れたサーバに向ける。

標準のDNSサーバ指定じゃいかんのか？

Androidには一応静的IPでDNSサーバを指定する機能もある。一見これでおしまいに見えるが、実際にはIPv4のサーバアドレスしか指定できないうえに、IPv6は切れないし、IPv6で名前解決失敗したらIPv4で試すとかするわけでもない、中途半端な無能。

なので標準の機能では無理。

RethinkDNSで強制する

RethinkDNSをダウンロード＆インストールする。

タブバーから「構成」を選択
「DNS」を選択
「その他のDNS」
「DNS 53」
＋ボタンで追加してチェックを入れる

IPアドレスとポート番号だけ記述。ポートは普通は53

最初の画面に戻って「開始」

これでLAN内ドメインの名前解決できるか試す。いけたらOK。

MacroDroidでネットワークを検知してOn/Off

これだけだとネットワークから離脱したり入ったりするたびにRethinkDNS起動してOn/Offしないといけないめんどくさい。

なのでマクロアプリを入れて自動化。ここではMacroDroidをインストール＆ダウンロード

まず開始のトリガを作る。

+でマクロの追加
トリガー

+を長押し
「Wi-fi状態の変化」
「ネットワークに接続時」より指定

アクション

「アプリ」「アプリを起動」より「RethinkDNS」を選択
「待機」で検索「1秒」
「機器の操作や動作」「UI画面操作」より「クリック」で「テキスト」の「開始」

これでネットワークに参加したとき、自動で開始したらOK。

同様に停止のマクロも作成。

+でマクロの追加
トリガー

+を長押し
「Wi-fi状態の変化」
「ネットワークに切断時」より指定

アクション

「アプリ」「アプリを起動」より「RethinkDNS」を選択
「待機」で検索「1秒」
「機器の操作や動作」「UI画面操作」より「クリック」で「テキスト」の「停止」

ネットワークから離脱したときに自動で停止したらOK。

なにもかも違ってますか

なにか間違っているような気がして仕方ないが、とりあえずこれで運用している。起動しながら移動していれば問題ないのだが、画面OFFにしたまま移動すると動いてない感じ。まぁでも他にやりようもなく。自分は割と外に出るときはスマホいじりながら出るので…。

以上。

荷物をバラして積み直す

Fri, 24 Jul 2026 00:00:00 +0900

興味を惹かれたツイートがあった。

https://twitter.com/okenokig/status/2078393251539935729?s=20

高校の時に派遣バイトでこの手の荷卸しやったなぁ。港湾の倉庫で40ftコンテナからパレットへ。「パレットごと積み込めよ…」と思っていたものの、よくよく考えれば我々の給料(日給6千円)よりもパレットの体積分の荷物の売上利益の方が大きいことに気付いて、世界の不条理さを噛み締めたのでした。

さすがに人手不足の現在6,000円からは上がっているのではないかと思われるが…どうなんだろう。まぁでも、今でもあまり高くはないのだろうし、同じことをやっているのだろうということは、ツイートのさらに元ツイートまで遡ると示唆される。これは、労働者が安すぎることによって効率化がすすまない、とは言えるだろう。

昔の自分なら、それを前提に本来のあるべきだった姿みたいなのを考察したような気もするんだが、今は少し思うことが違う。

たしかに資本効率の観点から言えば、バラして積み直すよりも、容積効率を犠牲にしてでもパレットごと積んだほうが良さそうだし、というかそうあるような仕組みにすべきだ、となる。

一方で、資源効率の観点から言えば、より少ないエネルギーで大きな仕事をしていると言えて、これは積み直したほうが正しい。決して不条理ではなく、極めて合理的で意義のあることで、本来は誇るべき仕事だと思う。

まぁ元ツイートの環境は、資源効率を考えているわけではなく、単に資本効率の結果エネルギー資源よりも人的資源のほうが安かった結果と思われる。扱いが低いと仕事に尊厳も感じられず、単に搾取されているような気分になるであろうし、実態としてそうだったのだろうと思う。

しかしやっていることは、省エネルギーな我々がその筋力と空間能力と器用さによって、限りある化石燃料でより大きな仕事をするお膳立てをしているのであって、もし世界で本当にSDGsと呼べるものがあるならば、これがそうなのではないか。少なくとも、SDGsの講演をするために鉄の塊を飛ばすより明らかに化石燃料を節約しているといえる。チャリで来い。

化石燃料には限りがあること自体は、左派の思想信条ではなく物理的な事実でしかないのだから、その節約は地球上で我々の文明を延命させるのに必要なことで、意味がある。問題はそのように考えられておらず、単に搾取になってしまっていることだ。

現実として我々の社会は資源主義ではなく資本主義だし、SDGsは資本主義をさらに蛸壺化させた欺瞞でしかなかった。なので本当に持続可能に繋がる人のちからは今なお軽んじられたままだ。

ただ先のとおり資源は有限であるから、資本主義の理屈においても、いつかはエネルギー資源と人間は資本効率において逆転することにはなるだろう。多くの人はロボットやAIによるディストピアを想像するのが好きだが、現実にはロボットもAIも少なくとも省エネルギーの観点で人類にボロ負けしているし、熱力学の法則を捻じ曲げる力は持っていないので、基本的な未来予想図は変わらない。できるできないの前に、機械を動かす燃料が足りない。

ただそこまで資本主義がわからされるまで待つことになると、相当追い込まれていることが予想される。自動化どころではない。人間ができることを機械にやらせるのはもったいない、となっているだろう。といっても資源主義的にはそのほうが本質ではある。

できるだけ早い目に考え方を転換すべきだとは思うものの、とはいえ短期的には資源を持っているならそれを燃やしまくってミサイル撃ちまくって支配者になるほうが、その時点における人々にとっては有利なので、無理なのかなぁ。結局人は相対的な生き物で、文明を維持するために生きているわけではないからねぇ。

現状、僕は社会的にはもはやどうにもならないので、個々人が出来る範囲で対策を打つしかない、となってしまうのだけれど、その対策というのも具体的に考えるとけっこうなことになってしまうのだよね。難しい。

このままいくと、想定より早く、少なくとも僕が生きている間に目に見えて崩壊が進み、けっこうな人が認めざるを得ないところまでいくだろうと思っている。まぁどうなったとしても、その答え合わせはしたいので、できれば長く生きたいなぁという気持ちだ。その間は、今の文明の中でやりたいことをやるしかない。

WordPress(Docker)をコンテナとボリュームごと別マシンに移行するスクリプト

Sun, 14 Jun 2026 15:37:33 +0900

以下の記事の自動化スクリプト。

やることとやらないこと

やること
- 移行元からボリュームをバックアップして、移行先で復元する
やらないこと
- 移行後のルーティング

スクリプトでやっていることについて図示する。バックアップ中はダウンタイムとなるので注意。

flowchart TD
subgraph Local["ローカルマシン (移行元)"]
direction TB
A[YAMLからボリューム一覧を取得] --> B[移行対象のボリュームを選択]
B --> C[元マシンのコンテナ停止]
C --> D[選択ボリュームのバックアップvackup export]
D --> E[元マシンのコンテナ再開ダウンタイム短縮]
E --> F[設定ファイル一式とバックアップを転送rsync]
end
subgraph Remote["リモートマシン (移行先) SSH経由で自動実行"]
direction TB
G[作業ディレクトリに移動]
H[ボリュームのリストアvackup import]
I[ネスト構造の解消vackup-volumeを直下へ移動]
J[移行先コンテナ起動docker compose up -d]
K[リモートの一時バックアップ削除]
end
F -->|ネットワーク転送| G
G --> H
H -.各ボリュームごとにループ.-> I
I --> J
J --> K
subgraph Local_Cleanup["ローカルマシン (完了後)"]
L[ローカルの一時バックアップ削除]
end
K -->|処理完了| L

準備

移行元から移行先に、sshで転送できるようにしておく。
- 移行元はLAN内のマシンで、移行先はVPSとする。
移行元と移行先にdockerとdocker composeとvackupを入れる。

vackupについては以下。

スクリプトと実行

スクリプトは以下。AIが書いた。

#!/bin/bash

# エラー発生時にスクリプトを終了
set -e

# 引数のチェック
if [ "$#" -ne 3 ]; then
 echo "Usage: $0 <dir_name> <user@ip> <remote_base_path>"
 echo "Example: $0 site1 user@192.168.1.50 /home/user/wordpress"
 exit 1
fi

DIR_NAME=$1
REMOTE_TARGET=$2
REMOTE_BASE_PATH=$3

LOCAL_DIR="./$DIR_NAME"
REMOTE_DIR="$REMOTE_BASE_PATH/$DIR_NAME"

# ローカルディレクトリの存在確認
if [ ! -d "$LOCAL_DIR" ]; then
 echo "Error: Local directory '$LOCAL_DIR' does not exist."
 exit 1
fi

echo "=== 1. ボリューム名の取得 ==="
cd "$LOCAL_DIR"

# docker compose config を使ってボリューム名一覧を取得
VOLUMES=$(docker compose config --volumes)

if [ -z "$VOLUMES" ]; then
 echo "Error: No volumes found in docker compose config for $DIR_NAME."
 exit 1
fi

echo "対象ボリューム:"
echo "$VOLUMES"

echo "=== 2. 元マシンのコンテナ停止 ==="
docker compose stop

echo "=== 3. ボリュームのバックアップ (vackup) ==="
mkdir -p volume-backups
for vol in $VOLUMES; do
 echo "Exporting volume: $vol"
 vackup export "$vol" "volume-backups/$vol.tar.gz"
done

echo "=== 4. 元マシンのコンテナ再開 (ダウンタイム短縮) ==="
docker compose up -d

echo "=== 5. 移行先へのファイル転送 (設定ファイル一式 + バックアップ) ==="
cd ..

# 移行先にターゲットディレクトリを作成
ssh -o ServerAliveInterval=60 "${REMOTE_TARGET}" "mkdir -p ${REMOTE_DIR}"

# フォルダごとリモートへ同期
rsync -avz --progress -e "ssh -o ServerAliveInterval=60 -o ServerAliveCountMax=10" \
 "$DIR_NAME/" "${REMOTE_TARGET}:${REMOTE_DIR}/"

echo "=== 6. 移行先でのボリュームリストアと起動 ==="

# 変数内の改行をスペースに変換する
VOLUMES_ONELINE=$(echo "${VOLUMES}" | tr '\n' ' ')

REMOTE_SCRIPT=$(cat << EOF
cd "${REMOTE_DIR}"

for vol in ${VOLUMES_ONELINE}; do
 echo "----------------------------------------"
 echo "Processing volume on remote: \$vol"
 
 # リストアを実行
 vackup import "volume-backups/\$vol.tar.gz" "\$vol"
 
 # vackup-volume のネスト構造を修正
 echo "Fixing nested directory structure for \$vol..."
 docker run --rm -v "\$vol":/volume alpine sh -c "
 if [ -d /volume/vackup-volume ]; then
 mv /volume/vackup-volume/* /volume/ 2>/dev/null || true
 mv /volume/vackup-volume/.[!.]* /volume/ 2>/dev/null || true
 rmdir /volume/vackup-volume 2>/dev/null || true
 fi
 "
done

echo "----------------------------------------"
echo "Starting containers on remote host..."
docker compose up -d
EOF
)

# 移行先マシンでリストア処理を実行
ssh -o ServerAliveInterval=60 "${REMOTE_TARGET}" "${REMOTE_SCRIPT}"

echo "=== 7. ローカルの一時バックアップを削除 ==="
rm -rf "$DIR_NAME/volume-backups"

echo "=== 移行プロセスが完了しました ==="

使い方は以下。

./migrate-wp.sh site1 VPSのユーザ@VPSのIPアドレス /home/VPSのユーザ/wordpress

これを実行すると、移行先に~/wordpress/site1ができる。すでにコンテナの実行までされている。

なので、あとはDNSなどを操作して移行元から移行先に向けるとか、ルーティングで必要なことをやれば移行完了。

以上。