第 10 章「AIに任せる仕事を見極める」の主張を裏付ける。

章のどの主張に対応するか

Linux コマンドラインでの一括処理:
for f in *.jpg; do convert "$f" -resize 1200 "${f%.jpg}.webp"; done
1,000 ファイルを 約 3 秒で処理。AI 利用料ゼロ。同じ処理を AI エージェントに頼むと、ファイル名・サイズ・変換結果を毎回判断、約 60 分(LLM の応答待ち主因)、AI 利用料約 $5。1,200 倍の速さ。

(章本文「実例: 数字で見る」より)

実測 ── 1,000 枚を 13 秒 で WebP 化。サイズは 272.7 MB → 4.4 MB(61.7 倍小さく)。 AI 利用料は コードを 1 回書いてもらった分だけ。実行時の API 呼び出しはゼロ。

やること

入力を作る: 1,200×800 の PNG を 1,000 枚生成(計 272.7 MB)
変換する: cwebp を xargs -P 8 で 8 並列実行、800px にリサイズして WebP 化
計測する: サイズ削減比、実行時間
コスト試算する: 同じ処理を AI エージェントで毎日回したらいくらか

make all 一発で全部。

構成

example-1/
├── README.md
├── generate_images.py   ── PNG 1,000 枚を生成(標準ライブラリのみ)
├── Makefile
├── results.md
├── src/                 ── 入力 (PNG, .gitignore で除外)
└── out/
    ├── webp/            ── 変換結果 1,000 枚 (.gitignore で除外)
    └── sample/          ── 50 枚だけサンプルコミット

実行

sudo apt install webp imagemagick
make clean && make all

なぜこれが「実例」になるのか

「画像を一括 WebP 化」── これは AI エージェントに頼むべきではない代表例。

エージェント方式:

あなた: 1,000 枚の画像を WebP に変換して
エージェント: ファイル一覧を取得します...
エージェント: img_0001.png を変換します... 完了
エージェント: img_0002.png を変換します... 完了
...
エージェント: img_1000.png を変換します... 完了

各ファイルで LLM が「ファイル名はこれ」「変換コマンドはこれ」「結果はこう」と推論する。1 ファイル当たり 3 秒以上、合計 60 分。1 回 5 ドル。

シェル方式:

find src -name "*.png" -print0 | xargs -0 -n1 -P 8 cwebp ...

LLM は呼ばない。CPU が直接走る。13 秒で完了。コスト 0 ドル。

毎日この処理を回すなら:

	エージェント	シェル
1 日の時間	60 分	13 秒
1 日のコスト	$5	$0
年間コスト	$1,825	$0
365 日の総時間	365 時間	約 1.3 時間

これが章で言う「コードに凍結する」の意味。

LLM は コードを書く能力 で使う。実行する能力 ではない。書いてもらったコードは、その後何百回・何千回も無料で動く。

ただしエージェントが妥当な場合もある

このパターンが妥当なケースもある:

判断が必要:「画像の主題が花か建物かで処理を変えて」── これは画像認識(LLM の Vision)が要る、シェルでは無理
一回限り: 「この 5 件だけ確認したい」── コードを書く方が高くつく
不定形: 「メールから請求番号を取り出して」── 毎回違う形式

判断と一回性があるなら AI、繰り返しと自動化ならコード。境界はそこ。

エージェントは魅力的に見える。でも、コードに凍結できるものをエージェントに任せ続けるのは、毎日タクシーに乗って同じ道を通うのと同じ。

計測結果 — 第 10 章 example-1

実行環境: Linux 6.18 / cwebp 1.x / 8 並列

処理時間とサイズ削減(主目的)

=== 1,000 ファイルを WebP に変換 (cwebp + xargs -P 8) ===
real    0m13.117s
user    0m46.694s
sys     0m5.098s

=== サイズ削減 ===
  入力 (PNG) : 272.7 MB
  出力 (WebP): 4.4 MB
  削減        : 61.7 倍

項目	数値
ファイル数	1,000
入力合計	272.7 MB(PNG, 1200×800)
出力合計	4.4 MB(WebP, 800px 縮小, 品質 80)
サイズ削減	61.7 倍
実行時間(8 並列)	13.1 秒
1 ファイルあたり	13 ms
AI API 呼び出し	0 回

CPU 使用は 46 秒(8 並列で実時間 13 秒)。

エージェント方式との比較(章本文の数字)

	エージェント	このシェル方式
1 回の所要時間	約 60 分(LLM 応答待ち)	13 秒
1 回の AI 利用料	約 $5	$0
1 回の比		約 280 倍速い、∞ 倍安い

年間で運用したら

頻度	エージェント	シェル	年間差額
毎日	$1,825 / 年	$0(初回コード生成のみ)	約 27 万円
週 1 回	$260 / 年	$0	約 4 万円
月 1 回	$60 / 年	$0	約 9,000 円

毎日同じ処理を AI エージェントに頼むのは、毎日タクシーに乗って同じ道を通うようなもの。1 度地図(コード)を作れば、あとは無料で歩ける。

サンプル出力(`out/sample/`)

WebP 1,000 枚は .gitignore で除外しているが、サンプルとして 50 枚を out/sample/ にコミット:

$ ls out/sample/ | head -5
img_0000.webp
img_0001.webp
img_0002.webp
img_0003.webp
img_0004.webp

$ du -sh out/sample/
388K    out/sample/

50 枚で 388 KB。1 枚あたり約 7.7 KB。元の PNG (272 KB) と比べると 約 35 倍 小さい(リサイズも効いている)。

コードを「凍結」する効果

このフォルダの Makefile 自体が、Claude が書いたコードの「凍結」例だ。最初の 1 回だけ Claude に「1,000 枚の PNG を 8 並列で WebP 化したい」と頼んだ。返ってきた find ... | xargs -0 -n1 -P 8 cwebp ... を Makefile に保存した。それ以降、AI には触らない。

毎日 cron で make all を回すなら:

0 2 * * * cd /home/me/photos && make all

LLM の月額契約は要らない。API 料金もゼロ。

これが「AI に任せていい仕事と、コードに凍結すべき仕事を見極める」の具体形。

再現手順

sudo apt install webp imagemagick
make clean && make all

13 秒で 1,000 枚処理。

1,000 枚の画像を WebP に変換(エージェント vs シェル)