ROI 設計と自分の業務への移植
ここまで自律性の 5 段階と偽本の見分け方を扱った。最後に 「自分の業務にどう持ち込むか」 という実装の話に着地させる。
これは抽象論ではなく、読み終わった後にあなたが何を自動化するか を選ぶための章。
自動化の真実 ─ 80/20/60 の法則
副業煽りが見せない、本物のプラクティスが必ず触れる現実：
80% は AI が書くが、残り 20% に時間の 60% がかかる
これは Web 制作副業 180 日記録 の core insight だが、Anthropic 内部の事例とも一致する。Inference チームの「リサーチ時間 80% 短縮」も、「残り 20% を人間が深く判断する」という構造を前提にしている。
graph LR
Total[業務 100%] --> AI[AI が書ける 80%]
Total --> H[人間が判断する 20%]
AI -.時間消費.-> T1[時間 40%]
H -.時間消費.-> T2[時間 60%]
Note1[人間判断の 20% に<br/>時間の 60% がかかる]
style T2 fill:#ffe1e1
style AI fill:#e1ffe1この構造を理解すると、ROI 設計は明快になる：
- AI 化の余地は「機械的に書ける 80%」に集中する（人間判断の 20% を AI 化しようとすると破綻）
- 時間消費は人間判断 60% にあるので、ここを「短縮」ではなく「集中環境を作る」方向で改善する
- 「全自動」は嘘。20% の人間判断を消すと品質が崩壊する
ROI 評価の 3 軸
自動化候補を見つけたら、3 軸で評価する：
軸 1：頻度
週 5 回以上 → 強く自動化候補
週 1-3 回 → 自動化の効果あり
月 1 回以下 → 自動化のコストが上回る可能性軸 2：型化可能性
8 割以上同形 → 型化容易
5-8 割同形 → 部分的に型化（パラメータ化）
5 割未満 → 型化に向かない軸 3：失敗時の被害
失敗しても何ともない（draft 生成など） → 高自律レベル OK
失敗で時間損失（CI で気付く） → L1-L3 まで
失敗で本番影響・金銭損失 → 慎重に、L1-L2 中心3 軸のスコアを掛け合わせて優先順位を決める。
quadrantChart
title 自動化の ROI 象限
x-axis "頻度低い" --> "頻度高い"
y-axis "型化困難" --> "型化容易"
quadrant-1 "L4 / L5 候補"
quadrant-2 "型化を磨く価値あり"
quadrant-3 "自動化しない"
quadrant-4 "L1 で十分"
"PR レビュー準備": [0.8, 0.7]
"週次トレンド記事": [0.4, 0.85]
"月次インボイス処理": [0.2, 0.95]
"顧客個別の要件分析": [0.6, 0.2]
"DB schema 変更": [0.3, 0.4]
"コミットメッセージ": [0.95, 0.9]右上は L4-L5 候補、右下は L1 で十分、左下は自動化対象から外す。
「副業」より先に「本業の繰り返し作業」を見る
L1 の章でも触れたが、自動化は時間を生む装置 であって金を生む装置ではない。だから始めるべきは 本業の繰り返し作業 だ：
graph TB
Now[現在の業務] --> Find[繰り返し作業の発見]
Find --> Auto[自動化]
Auto --> Free[時間が浮く]
Free --> Use1[本業の深掘り]
Free --> Use2[副業に挑戦]
Free --> Use3[休息 / 学習]
Wrong[「副業のために<br/>新規で自動化」] -.失敗多し.-> X[コスト先行]
style Free fill:#e1ffe1
style X fill:#ffe1e1副業のために何か新しい自動化を一から作るのは ROI が遠い。今やっている本業の繰り返し作業 は既に「自分にとっての価値」が確定しているので、そこを自動化するのが最短。
4 ステップの移植プロセス
ここからが本章の core。自分の業務を 4 ステップで自動化候補に変換するプロセス。
Step 1：作業の棚卸し（30 分）
過去 1-2 週間を振り返り、「繰り返している作業」を 10-20 個リストアップする。
具体例（私のケース）：
- 毎朝の Slack を読んで未対応に反応する（30 分/日）
- PR レビュー前に diff と関連 issue を確認（15 分/PR）
- 週次の進捗 report を Notion に書く（45 分/週）
- 議事録から TODO を抽出して assignee に振る（10 分/会議）
- コミットメッセージを書く（1 分/commit × 10/日）
- 障害対応時に過去の類似事例を検索する（20 分/障害）
- 新規ライブラリを評価する（README 読 + サンプル動作確認）（30 分/件）
- バグレポートをトリアージする（5 分/件 × 数件/日）Slack や git log や calendar を見て、機械的に拾う。記憶に頼らない。
Step 2：3 軸スコアリング（30 分）
各作業に 3 軸のスコアを付ける：
| 作業 | 頻度 | 型化 | 失敗影響 | 候補 Level |
|---|---|---|---|---|
| Slack 未対応反応 | 高 | 中 | 低 | L1-L2 |
| PR レビュー前の diff/issue 確認 | 高 | 高 | 低 | L3 |
| 週次進捗 report | 中 | 高 | 中 | L4 |
| 議事録 → TODO 抽出 | 中 | 中 | 低 | L1 |
| コミットメッセージ | 高 | 高 | 低 | L1 |
| 障害対応の類似事例検索 | 低 | 中 | 中 | L1 |
| ライブラリ評価 | 低 | 低 | 低 | 自動化しない |
| バグトリアージ | 高 | 高 | 中 | L3 |
これで どこから手を付けるか が見える。「頻度高 × 型化高 × 失敗影響低」が最優先。
Step 3：最初の 1 つを L1 で実装（半日）
最優先の 1 つを 必ず L1 から 始める。Skill / Slash Command で 30 分-2 時間で動くものを作る。
# 例：コミットメッセージの自動生成
$ mkdir -p .claude/commands
$ vim .claude/commands/commit-msg.md最初から L4 / L5 を狙わない。L1 で 1 週間使ってみて：
- 本当に毎日使うか
- 改善したい点は何か
- 上の段（L2, L3）に進む価値はあるか
を観察する。多くの作業は L1 で十分 だと気付く。
Step 4：観察に基づいて段階を上げる（数週〜数ヶ月）
L1 で運用して見えるもの：
graph LR
L1[L1 で運用] --> O[1 週間観察]
O --> Q1{改善ポイントは?}
Q1 -->|忘れる / ルール違反| L2[L2 に上げる]
Q1 -->|手動起動が面倒| L3[L3 に上げる]
Q1 -->|時間軸でやりたい| L4[L4 に上げる]
Q1 -->|複雑すぎる| L5[L5 に上げる]
Q1 -->|十分機能してる| Stay[L1 で固定]
style Stay fill:#e1ffe1「改善ポイントが見えてから上に登る」のが鉄則。逆に登ってから「あ、L1 で十分だった」と気付くと、設計コストの無駄。
移植ワークシート
実際に書き出すためのシートを置いておく。コピペして使える：
# 私の自動化ロードマップ
## Step 1：棚卸し（10-20 個）
1. [作業名] - [頻度: ]/[型化: ]/[失敗影響: ]
2. ...
## Step 2：優先 3 つ
### 優先 1：[作業名]
- 現在の所要時間：N 分/回 × M 回/週 = X 時間/週
- 開始 Level：L?
- 期待効果：N 時間/週の節約
### 優先 2：...
### 優先 3：...
## Step 3：実装計画
### Week 1：優先 1 を L1 化
- [ ] Slash command 作成
- [ ] 1 週間運用
- [ ] 改善点リストアップ
### Week 2-3：観察と調整
- [ ] 改善点を反映
- [ ] 必要なら L2 化
## Step 4：上位レベルへの判断
- [ ] L2 が要るか？（ルール違反が頻発するか）
- [ ] L3 が要るか？（手動起動が負担か）
- [ ] L4 が要るか？（時間軸が欲しいか）
- [ ] L5 が要るか？（1 体では捌けないか）アンチパターン：3 つの落とし穴
移植プロセスでよくやらかすこと：
アンチパターン 1：「全部 L5」志向
「Multi-agent でかっこいいシステムを作りたい」── 結果、設計に 1 ヶ月かけて、L1 で済むタスクを L5 で実装する。複雑性のコストが ROI を消す。
対策：必ず L1 から。L5 が本当に必要な場面は実は少ない。
アンチパターン 2：「自動化のための自動化」
「業務改善！」と意気込んで、月 1 回しかやらない作業を自動化する。設計時間 8 時間 vs 浮いた時間 月 30 分 = ROI 大幅マイナス。
対策：3 軸スコアで頻度の低い作業は除外。
アンチパターン 3：「観察フェーズを飛ばす」
L1 で動かした次の日に「もう L4 に上げよう」と判断する。数日では型の良し悪しが見えない。
対策：最低 1 週間、できれば 1 ヶ月の運用後に判断。
副業に持ち込むときの考え方
本業の繰り返し作業を自動化して時間が浮いたら、副業に使うのは選択肢の一つ。その時の指針：
指針 1：自分が責任を取れる範囲を超えない
Claude Code で受託案件を速くこなすのは健全。だが「Claude が勝手に書いたコードを納品」は危険。最終確認の責任は人間 が取る。
指針 2：時間を売る vs 成果を売る
副業の課金体系は 2 つに分けて考える：
| タイプ | Claude Code との相性 |
|---|---|
| 時間チャージ（時給） | 速くこなすほど自分の時給が下がる ── 自動化の意味薄い |
| 成果報酬（プロジェクト） | 速くこなすほど自分の時給が上がる ── 自動化が直接効く |
成果報酬型の副業 に Claude Code は最も効く。
指針 3：「自分の専門領域」を絡める
完全に未経験の領域で Claude に任せて稼ぐのは難しい（Claude の出力を評価できない）。自分の専門領域 × Claude の高速化 が組み合わさると初めて効く。
例：
- フロントエンド 5 年経験 + Claude Code = 受託 LP 制作で 2 倍速
- データ分析専門 + Claude Code = リサーチレポートの量産
- セキュリティ専門 + Claude Code = 脆弱性レポート自動化
「自分の知識は何で、そこを Claude でどう速くするか」を起点にする。
ROI が出ない人の典型像
逆に、Claude Code で ROI が出ない人もいる。共通する特徴：
- 繰り返し作業がない仕事：毎回内容が大きく違う仕事は型化できない
- 責任と判断のみが価値の仕事：意思決定者の業務は AI 化の余地が小さい
- 学習意欲が低い：YAML / shell / GitHub Actions の最低限すら学べないと L1 すら回らない
- 「自動化したらラクになる」と期待する：実態は 「自動化のために最初は労力が要る、その後ラクになる」
このどれかに該当しても、それは「Claude Code が悪い」ではない。ROI が出る作業を持っているか を冷静に評価する。
この章の要点
- 80/20/60 の法則：AI が書ける 80% / 人間判断 20% / 時間消費 60% の構造
- ROI 評価の 3 軸：頻度 / 型化可能性 / 失敗影響
- 副業の前に本業の繰り返し作業から始める
- 4 ステップ：棚卸し → スコアリング → L1 実装 → 観察と段階移行
- アンチパターン：全部 L5 / 自動化のための自動化 / 観察フェーズ飛ばし
- 副業の指針：責任範囲 / 成果報酬型と相性 / 自分の専門領域と組み合わせる
- ROI が出ない人の特徴も知っておく
次章への問いかけ
移植プロセスは整理した。だが自律性には天井がある。
全自動は嘘、しかし大きく前進している。最終章では自律性の天井を直視しつつ、これから何を任せ、何を残すかを考える。参考文献も整理する。