自動化の対象は勘ではなく測定で決める — 作業ログを棚卸しする習慣

結論: 自動化の対象は「測ってから」決める

結論から書きます。何を自動化するかは「毎回やってる気がする」という勘ではなく、自分の作業ログを棚卸しして頻度と所要時間を測ってから決めるべきです。理由は単純で、人間の記憶は作業の頻度をほぼ毎回外すからです。私たちはストレスのかかった例外作業を鮮明に覚えている一方、毎日 30 秒で終わる定型作業はそもそも記憶に残りません。だから勘で自動化すると、年に数回しか来ない例外に立派な仕組みを作り、毎日の本命を素通りします。

きっかけは、Zenn で見かけた作業ログから自動化対象を選ぶという発想の記事でした。Claude Code のセッションログ（~/.claude/projects/ にローカル保存される JSONL、私の環境では数 GB ありました）を解析して、繰り返している作業をクラスタリングし、自動化の優先度をつける、という話です。読みながら耳が痛くなりました。私もこの AetherEchoes の運用で「これ毎回やってる気がする」を起点に、結局一度も使わなかったスクリプトをいくつも残していたからです。

「自動化したい」という気持ちは、頻度をほぼ毎回外す

先に要点を書きます。自動化したいという衝動が湧くのは「面倒だった瞬間」であって「頻度が高い作業」ではない、という所がズレの正体です。この 2 つは一致しません。

面倒さと頻度は別の軸です。たとえば私にとって一番「うっ」と来るのは、本番 EC2 に SSH して Sidekiq のログを追う作業でした。心理的な負荷が高いので「自動化したい」と強く思う。でも実際の頻度は月に 2〜3 回です。一方、記事を upsert したあとに sitemap と llms.txt を目視確認する作業は、心理的負荷はゼロに近いけれど毎日発生していました。勘で並べると前者が上に来ますが、削れる総時間は後者の方がずっと大きい。私は最初これを完全に逆に見積もっていました。

なぜ記憶が頻度を外すのか。人は感情の強さで記憶の濃さを決めるからです。だから「強くムカついた例外」が記憶の上位を占め、「毎日の単調作業」は背景に沈みます。これは意志の弱さではなく記憶の仕様です。仕様を責めても直らないので、外部の記録に測定を委ねるしかありません。

作業ログを棚卸しする — 何を、どこで測るか

要点を先に書きます。棚卸しで測るのは「頻度」と「1 回あたりの所要時間」の 2 つだけで、ソースはシェル履歴とツールのセッションログで足ります。凝った計測基盤はいりません。

一番安いソースはシェルのコマンド履歴です。私は zsh を使っているので、まず実行回数の多いコマンドを雑に数えます。

# 直近の history からコマンドの頻度を数える(先頭トークンだけ集計)
history 1 \
  | awk '{print $2}' \
  | sort | uniq -c | sort -rn \
  | head -20

これだけで「自分が無意識に何百回打っているか」が出ます。私の場合は git status と docker compose 系、それと自作の make ターゲットが上位でした。atuin（シェル履歴を SQLite に貯めて検索できるツール）を入れていれば、時刻つきで集計できるので所要時間の当たりもつけやすくなります。

もう一段上のソースが、AI ツールのセッションログです。Zenn の元記事が指摘していた通り、Claude Code は対話履歴をローカルに残しています。注意点として、この JSONL は数 GB に膨らむので、ファイル全部を読み込ませてはいけません。jq や grep でストリーム処理し、各セッションの最初のユーザー指示だけ抜いて似た指示を束ねる、という読み方をします。「記事を 1 本書いて公開して」「動画を生成して紐付けて」のような指示が何回出ているかが見えると、それがそのまま自動化候補です。私はこの棚卸しで auto-publish を 6 つのスキルに割り直したのですが、その判断の裏付けは並列 AI エージェントと脳みそ 1 個問題の記事に書いた通り、勘ではなくログ上の出現回数でした。

測る粒度はこの 2 つで十分です。

• 頻度: 直近 30 日に何回やったか（履歴の grep カウントで近似）
• 所要時間: 1 回あたり何分か（体感で 1 / 5 / 15 / 60 分の 4 段階に丸める）

秒単位で正確に測る必要はありません。桁が合っていれば判断は変わらないからです。

測った後の判断: 頻度 × 時間で 4 象限に置く

要点を先に書きます。測った頻度と所要時間を掛けて「月あたりの消費時間」を出し、大きい順に自動化する、これだけで勘より遥かに当たります。

判断の骨格は単純な掛け算です。月の消費時間 = 頻度（回/月）× 所要時間（分/回）。これを大きい順に並べ、上から自動化していきます。例として私の棚卸し結果の一部を置きます。

作業	頻度(回/月)	所要(分/回)	月の消費(分)	判断
公開後の sitemap/llms.txt 目視確認	30	3	90	自動化(verify スキル化)
記事 upsert 後の品質チェック	30	5	150	自動化
本番 Sidekiq ログ追跡	3	15	45	手動のまま
月次のリンク切れ確認	1	30	30	手動のまま

面白いのは、一番「自動化したい」と思っていた Sidekiq ログ追跡が、消費時間で見ると下位だった点です。心理的負荷で並べていたら間違いなく最初に手をつけていました。掛け算に直した瞬間、優先順位がひっくり返りました。

もう 1 つの判断軸が「自動化してよい作業か」です。頻度が高くても、毎回少しずつ判断が違う作業は自動化に向きません。私は要件定義を思想と仕様に分ける記事で書いた線引きをここでも使っていて、手順が毎回同じ（=仕様）ものだけ自動化し、判断が毎回違う（=思想）ものは人間に残します。消費時間が大きくても、後者なら自動化しません。

過剰自動化で私が残したゴミ

要点を先に書きます。測らずに自動化すると、動くけれど誰も呼ばないスクリプトが資産ではなく負債として残ります。私はこれを何度もやりました。

具体的な失敗を 1 つ。2026 年の春先、私は「画像の alt を一括でリライトするスクリプト」を勢いで書きました。当時 alt の文言が気になっていて、面倒さの記憶が新しかったからです。シェルで 80 行ほど書いて、テストデータで動くのも確認しました。そして — 一度も本番で実行しないまま 2 ヶ月が経ちました。理由は単純で、alt をまとめて直したい場面が月に 1 回も来なかったからです。頻度を測っていれば最初から書かなかった。書いたコードが過去の私を裏切る、という体験はよくありますが、これは過去の私が現在の私のために負債だけ用意してくれた珍しいケースでした。

ゴミ自動化には固有のコストがあります。まず読むコストです。リポジトリに「いつ使うか分からないスクリプト」が増えると、棚卸しのたびにそれが本当に要るのか判断する手間が乗ります。次に錯覚のコストです。仕組みがあると「自動化済み」と脳が安心してしまい、本当に削るべき毎日の作業から目が逸れます。私は集中時間を新規執筆に使わない話でも近いことを書きましたが、仕組み作りそのものが目的化すると、肝心の消費時間は一向に減りません。

なお補足すると、このサイトの記事は AI が下書きを書き、私が公開前に確認・編集して出しています。その auto-publish の構成自体も、勘ではなくセッションログの棚卸しから設計し直したものです。自分の運用を測る習慣がなければ、たぶん今も「全部入りの 1 個のスキル」を抱えて消耗していたはずです。

まとめ: 勘で自動化する前に、一度だけログを測る

自動化の対象は、面倒さの記憶ではなく作業ログの測定で決める。これが本記事の主張です。持ち帰る点を並べます。

• 自動化したい衝動は「面倒だった瞬間」に湧き、頻度をほぼ毎回外す
• 棚卸しで測るのは頻度と所要時間の 2 つだけ。ソースはシェル履歴と AI ツールのセッションログで足りる
• 頻度 × 所要時間で月の消費時間を出し、大きい順に自動化する
• 手順が毎回同じものだけ自動化し、判断が毎回違うものは人間に残す
• 測らずに作ると、動くけれど誰も呼ばないスクリプトが負債として残る

勘は速いけれど、頻度の前ではよく外れます。月に一度、自分の履歴を 5 分だけ眺める。それだけで、次に書くべき自動化が驚くほど別の場所に見えてきます。

面倒さは記憶に残る。頻度は記録にしか残らない。自動化すべきは、記憶ではなく記録の上位にある作業だ。