私のメインPCはWindowsです。そこで毎朝いちばん雑に使う道具は、凝ったアプリではなく、小さなCLIです。ダウンロードフォルダの更新ファイルを新しい順に5件だけ出すだけのものですが、こういう道具ほど配り方で寿命が決まると感じます。
自分だけが使うなら、多少重くても、依存関係が多くても、その場では困りません。けれど、別のPCへ持っていくことを考えた瞬間に、話が変わります。展開してすぐ動くか、余計なランタイム説明がいらないか、いらなくなったらすぐ消せるか。そのあたりまで含めて道具の使いやすさだと思っています。
配る前提で見ると、便利さの意味が変わる
最近あらためて思うのですが、小さな補助ツールは機能の多さより後始末の軽さが効きます。高機能でも置き場所に迷ったり、更新方法を毎回思い出したりするものは、数日は触ってもそのうち消えます。逆に、zipを展開してexeを置けば終わり、嫌になったらそのまま消せるものは残ります。
私は以前、ダウンロードフォルダの更新ファイルを5件だけ出すGo製CLIを30分ほどで書いて、朝の作業前に叩くようになりました。やっていることは地味です。それでも残っています。たぶん、機能がすごいからではありません。自分のWindows環境へ置く手順が雑なくらい単純だからです。
この感覚は、Electron製の便利なアプリを入れるときに余計にはっきりします。画面が出て、すぐ使えるだけでは、もう納得しにくいです。便利さの請求書は最後に自分のPCへ届きます。メモリの重さや更新の面倒さまで含めて、自分で持てるもののほうが長く残ります。
Dockerで確かめた最小バイナリ
言いっぱなしにしたくなかったので、今日あらためて docker run –rm で最小のGoバイナリを作って確かめました。コンテナの中で fmt.Println(“hello”) だけのプログラムをビルドすると、Linux向けが1.5MB、Windows向けの hello.exe が1.6MBでした。大きなアプリの話ではありませんが、この雑さの少なさはやはり強いです。
確認に使ったコードはこれです。
package main
import "fmt"
func main() {
fmt.Println("hello")
}ビルドはこの2行で済みました。
docker run --rm -v "$PWD":/work -w /work golang:1.25-bookworm \
go build -trimpath -ldflags='-s -w' -o hello-linux main.go
docker run --rm -v "$PWD":/work -w /work golang:1.25-bookworm \
env GOOS=windows GOARCH=amd64 go build -trimpath -ldflags='-s -w' -o hello.exe main.go私がGoをかなり現代のC言語として見ているのは、こういうところです。コードが変に飾られにくいですし、最後に残る配布物の説明も短くて済みます。OSに近い層を触る道具でも、変な儀式を増やさずに持ち運べます。
AIに任せる場所と、自分で持つ場所
最近は、こういう小道具の最初の骨組みだけAIに出させることがあります。flag定義や設定読み込みの下書きくらいなら、そのほうが早いです。ただ、そのまま採用はしません。毎日使う道具は、エラーメッセージの出し方や出力件数みたいな癖の部分で手触りが決まるからです。
フレームワークの儀式や定型文まで全部手で打ちたいわけではありません。そこはもうAIへ渡していいです。でも、何を削るか、どこまで雑に持てる形へ落とすかは自分で決めたいです。そこまで丸投げすると、動いていても自分の道具ではなくなります。非エンジニアがバイブコーディングで一気に形にしても、少し崩れた途端に手が止まるのは、たぶんその境目を自分で持っていないからです。
配る前提で考えると、私は結局Goへ戻ってきます。速いからだけではありません。書いたあとに削りやすく、配るときの説明が短く、消すときも軽いからです。AIで下書きがいくら速くなっても、最後に残るのはその道具を自分で持てるかどうかだと思っています。