業務自動化の効果の測り方【2026年10月】— 自動化の前後で何を記録し、どう比べるか（記録表の雛形つき）

Claude Code や Google Apps Script で問い合わせの仕分けや毎朝の集計を自動化したあと、必ず聞かれるのが「で、どれだけ効果があったの？」です。答えに詰まる理由はほぼ一つで、導入前の数字を取っていないからです。導入後にいくら丁寧に集計しても、比べる相手が無ければ効果は示せません。

この記事では、自動化の効果を「導入前に取る基準値」「導入後に増える記録」「前後の比べ方」の3段階に分け、公式ドキュメント（2026年10月時点）で確認できる計測手段だけを使って整理します。社内で使う記録表と月次レポートの雛形、前後比較で起きやすい錯覚、判定のぶれの測り方も載せました。読者は、社内の業務改善・DX・情報システムの担当者と、投資の判断をする経営者を想定しています。数字の例はあえて載せていません。自社の業務で記録した値だけが、自社の効果だからです。

1. 効果は「導入前の基準値」が無いと測れない。 件数・所要時間・手戻り・確認件数の4つを、導入前の数週間、同じ表で記録しておきます
2. 導入後は「実行の記録」と「費用の記録」が自動で取れる。 Claude Code は JSON 出力と OpenTelemetry、Apps Script は実行一覧で、人が手で数えなくても残ります
3. 費用は API の利用料だけではない。 作る時間・直す時間・確認する時間を、人の記録として別に足します
4. 前後比較は錯覚が起きやすい。 時期の差、件数の変動、確認の手間の見落とし、「採用率」を効果と取り違える、の4つを先に潰します
5. 判定のぶれは別に測る。 同じ入力に同じ答えが返るかを確かめないと、削減した時間の裏で品質が落ちていても気づけません

自動化の効果は一つの数字に収まりません。先に「どの軸で測るか」を決めないと、都合のよい数字だけを拾うことになります。社内で合意しやすいのは次の4軸です。

上の3軸は人が書き、下の1軸はツールが残します。ここを混ぜると、API 利用料だけを費用と呼んで「安く済んだ」と結論づける失敗が起きます。

逆に、記録で測れないものも先に認めておきます。担当者の安心感、残業が減ったことによる離職の防止、問い合わせ対応が早くなったことによる顧客の印象は、記録表には載りません。効果の報告では「測れた効果」と「測っていない効果」を分けて書くと、数字の信頼が保てます。

基準値の記録は、自動化を作り始める前に始めます。期間は、業務の山と谷が一回ずつ入る長さが目安です。週次で回る業務なら数週間、月次で回る業務なら数か月分が要ります。

記録表はスプレッドシートで足ります。列は増やさず、次の7列に絞ると続きます。

記録のコツは3つです。

• 推定と実測を分ける。 ストップウォッチで測った時間と「だいたいこのくらい」を同じ列に混ぜない。推定には印を付けます
• 件数ゼロの日も書く。 空欄は「記録し忘れ」と区別できません。ゼロはゼロと書きます
• 担当者ごとに書く。 平均だけ残すと、慣れた人と新しい人の差が消え、導入後の比較で誤差になります

この表は、導入後もそのまま使います。列を変えないことが、前後を比べられる唯一の条件です。

自動化を動かし始めると、人の記録表に加えて、ツール側の記録が自動で増えます。ここは手で数えず、仕組みに残させます。

ヘッドレスモード（claude -p）に --output-format json を付けると、応答の本文に加えて session_id や total_cost_usd、モデルごとの費用の内訳が返ります。公式ドキュメントは、この費用を「クライアント側の見積もり」であり実際の請求と差が出ることがある、と明記しています。また --continue や --resume で会話を続けた場合は、それまでの実行分を含む合計が返ります。

※ 出典: Claude Code Docs — Run Claude Code programmatically（取得 2026-10）

実行のたびに、この JSON を日付付きのファイルに残しておけば、月末に「何回動いて、いくらかかったか」を集計できます。終了コードは成功で 0、失敗で 0 以外なので、ラッパーのスクリプトで成功・失敗の回数も同時に数えられます。記録の雛形は、前回の監視の記事に載せたものがそのまま使えます。

複数のジョブや複数の担当者の分をまとめて見るなら、OpenTelemetry で監視基盤に送ります。公式ドキュメントが挙げるメトリクスのうち、効果測定に使うのは次の4つです。

イベントとしては claude_code.tool_result に success と duration_ms、claude_code.api_error にエラーの種別と状態コードが入るので、失敗の内訳も取れます。プロンプトの本文や応答の本文、ツールの引数は既定では送られず、環境変数で明示的に有効にした場合だけ含まれます。効果測定には件数と費用と成否があれば足りるので、既定のままで始めます。

※ 出典: Claude Code Docs — Monitoring（取得 2026-10）

Google Apps Script で組んだ自動化は、Apps Script のダッシュボードにある「マイ実行」（My Executions）に、関数名・所要時間・状態・開始時刻・種別（時間主導型トリガーなど）が残ります。一覧に出るのは実行を開始した最初の関数だけで、その中から呼ばれた関数は出ません。

※ 出典: Google Apps Script — Dashboard（取得 2026-10）

所要時間を見るときは、割り当ての上限と並べて読みます。公式の割り当て表では、スクリプトの実行時間は1回あたり 6分、トリガーの合計実行時間は Google Workspace アカウントで 1日あたり 6時間（一般のアカウントは 90分）です。所要時間が上限に近づいているジョブは、効果が出ていても近いうちに止まります。公式ドキュメントは、割り当ては予告なく変わることがあると注記しています。

※ 出典: Google Apps Script — Quotas for Google Services（取得 2026-10）

Claude for Teams・Enterprise で Claude Code を配っている場合は、管理者向けの分析ダッシュボードに、日ごとのアクティブユーザー数とセッション数、採用された行数、提案の採用率が出ます。GitHub 連携を有効にすると、Claude Code が関わったプルリクエストの数と行数も出ますが、公式ドキュメントはこれらを「意図的に控えめな推定」であり実際の影響を下回る、と説明しています。

※ 出典: Claude Code Docs — Track team usage with analytics（取得 2026-10）

費用の目安としては、公式の費用管理ページに、企業での導入全体で開発者1人あたりの平均が稼働日1日あたり約 13ドル、月あたり 150〜250ドル、利用者の 90% は稼働日1日あたり 30ドル未満、という記載があります。これは開発者が対話で使う場合の値で、無人で回す業務自動化の費用とは性質が違います。予算の上限を置くときの参考値にとどめ、自社の値は JSON 出力と OpenTelemetry で取ります。

※ 出典: Claude Code Docs — Manage costs effectively（取得 2026-10）

導入後の費用で見落とされるのが、人の時間です。次の3つを記録表に足します。

「確認する時間」は、導入前の記録表の「確認に回した件数」と対になります。自動化のあとに確認の件数が増えていれば、作業の一部が人から人へ移っただけで、減ってはいません。この列が無いと、削減した時間の見かけだけが残ります。

同じ表で前後を記録しても、比べ方を間違えると効果を誤ります。報告の前に次の4つを確かめます。

1. 時期の差。 導入前が繁忙期、導入後が閑散期なら、所要時間は自動化と無関係に減ります。同じ時期の前年、または件数あたりの時間で比べます
2. 件数の変動。 合計時間が減っても、対象の件数が減っていただけかもしれません。必ず「一件あたり」に直します
3. 確認の手間の見落とし。 自動処理の結果を見直す時間を数えていないと、削減量を過大に見ます。確認の列を入れてから比べます
4. 採用率を効果と取り違える。 提案の採用率や採用された行数は「どれだけ使われたか」の指標で、「業務がどれだけ早くなったか」ではありません。公式ドキュメントも、貢献の指標は控えめな推定だと注記しています。業務の効果は、自社の記録表の時間と手戻りで示します

4つを潰したうえで、報告には「比べた期間」「対象の件数」「除外したもの」を必ず書きます。数字そのものより、この3行があるかどうかで、報告の信用が決まります。

問い合わせの分類や請求書の読み取りのように、Claude に判定を任せる自動化では、時間の削減とは別に「答えが安定しているか」を測ります。ぶれが大きいと、確認の時間が増えるか、見逃しが起きるかのどちらかになります。

測り方は単純です。

1. 過去の実データから、答えが分かっているものを一定数選ぶ（正解を人が付ける）
2. 同じ入力を同じ設定で複数回流し、答えが毎回一致するかを数える
3. 一致しなかったものを一覧にし、「どちらに転んでも困らない」「人に回すべき」「設定を直すべき」に分ける
4. モデルや設定を変えたときは、同じ一覧で再び流して比べる

この一覧は、効果測定の「手戻り」と「確認に回した件数」の原因を説明する材料にもなります。判定の答えのぶれをどう測り、どこまでを人に回すかの決め方は、企業向けの有料の実務書でも章を分けて扱っています。

経営者や上長への報告は、毎月同じ形で出します。項目を固定すると、良い月も悪い月も同じ重さで伝わります。

# 業務自動化 月次レポート（YYYY年MM月）

## 対象
- 業務: （例: 問い合わせの一次仕分け）
- 比べた期間: 導入前 YYYY-MM-DD〜 / 導入後 YYYY-MM-DD〜
- 除外したもの: （例: 繁忙期の臨時案件）

## 人の記録（記録表から）
| 指標 | 導入前 | 今月 | 備考 |
|---|---|---|---|
| 件数 | | | |
| 一件あたりの所要時間 | | | 推定／実測 |
| 手戻りの回数 | | | |
| 確認に回した件数 | | | |
| 確認にかけた時間 | | | |

## ツールの記録（JSON 出力・OpenTelemetry・実行一覧から）
| 指標 | 今月 | 先月 | 備考 |
|---|---|---|---|
| 実行回数（成功／失敗） | | | |
| API 利用料（米ドル） | | | 見積もり値 |
| 1回あたりの所要時間 | | | |

## 人の時間（費用側）
| 項目 | 今月 |
|---|---|
| 直す時間 | |
| 確認する時間 | |

## 判定のぶれ
- 同じ入力で答えが一致しなかった件: （件数と主な理由）

## 測っていない効果・懸念
- （例: 担当者の心理的な負担、顧客からの反応）

## 来月の判断
- 続ける／範囲を広げる／範囲を狭める／止める（理由）

「来月の判断」を毎月書くのが要点です。止める選択肢を最初から表に入れておくと、効果が出ないときに惰性で続ける失敗を防げます。

自動化を作り始める前に、次の10項目を確かめます。印刷して、記録表の横に置いておく使い方を想定しています。

• 対象業務の「件数」「所要時間」「手戻り」「確認件数」を、同じ表で記録し始めた
• 推定の時間と実測の時間を、列または印で区別している
• 件数ゼロの日もゼロと書く運用になっている
• 担当者ごとに記録している（平均だけを残していない）
• 業務の山と谷が一回ずつ入る期間を、基準値の記録期間にしている
• 自動化の実行ごとに、成否と費用が自動でファイルか監視基盤に残る設計になっている
• プロンプトや社内データの本文は、既定どおり監視基盤に送らない設定にしている
• 「作る時間」「直す時間」「確認する時間」を人の記録として足す列がある
• 判定を任せる自動化では、正解付きのサンプルを用意し、同じ入力を複数回流して一致を数える手順がある
• 月次レポートの雛形に「止める」の選択肢と「測っていない効果」の欄がある

1. 導入後に基準値を思い出で作る。 「前はこのくらいかかっていた」という思い出は記録ではありません。推定として明記しない限り、報告に使わないのが安全です
2. API 利用料だけを費用として報告する。 直す時間と確認する時間を足すと、評価が変わることがあります
3. 良い月だけ報告する。 雛形を固定し、悪い月も同じ形で出します
4. 採用率や行数で業務の効果を語る。 それらはツールの利用量であり、業務の所要時間ではありません
5. 判定のぶれを測らずに範囲を広げる。 件数が増えると見逃しの件数も増えます。広げる前に、同じ入力での一致を数えます

• Claude Code Docs — Run Claude Code programmatically: --output-format json の内容、終了コード、費用が見積もり値である旨
• Claude Code Docs — Monitoring: メトリクスとイベントの一覧、既定で送られない内容、管理設定での一括配布
• Claude Code Docs — Manage costs effectively: 費用の目安、Team・Enterprise・API・クラウドごとの支出の見方と上限
• Claude Code Docs — Track team usage with analytics: 管理者向けダッシュボードの指標と、貢献の指標が控えめな推定である旨
• Google Apps Script — Dashboard: 実行一覧（マイ実行）の列と制約
• Google Apps Script — Quotas for Google Services: 実行時間・トリガー合計時間などの割り当て

対象業務の件数、一件あたりの所要時間、やり直しが発生した回数、人の判断に回した件数の4つです。導入前の数週間を同じ表で記録しておくと、導入後に同じ表で比べられます。基準値が無いまま始めると、あとから効果を示す手段がありません。

分かりません。API の利用料は費用の一部で、作る時間、止まったときに直す時間、結果を確認する人の時間が残ります。Claude Code の JSON 出力や OpenTelemetry で取れるのは API 側の費用とトークン数なので、人の時間は記録表で別に取る必要があります。

換算の前提を明記すれば構いません。ただし「浮いた時間が全部ほかの仕事に回った」とは限らないので、換算した金額は上限の目安として扱い、確認や手戻りに使った時間を差し引いた値も並べて示すのが誠実な見せ方です。

すぐには判断できません。繁忙期と閑散期の差、対象業務の件数の変動、確認の手間を数えていなかった、などの錯覚が先に疑われます。同じ時期・同じ対象で比べ直し、それでも改善が無ければ、自動化の範囲を狭めるか止める判断を記録に残します。

まず、この記事の記録表を自社の対象業務に合わせて作り、今日から記録を始めてください。自動化の設計はそのあとで足ります。基準値が数週間分たまった時点で、どの業務から自動化するかを決めると、効果を示せる順に着手できます。

「どの業務を自動化すべきか」「記録表をどう設計すればよいか」を一緒に整理したい場合は、お問い合わせから対象業務と現在の記録の状況を書いて送ってください。業務の内容に合わせた記録項目と、自動化に向く順番を書面で返します。Claude 導入全体の進め方は Claude 導入支援に、無料で使える点検ツールはツール一覧にまとめています。

• 2026-10-02: 初版公開

• Claude Code で作った自動化が止まっていないか確かめる — 実行ログ・失敗の通知・やり直しの最小セット
• Claude Code を決まった時刻に動かす — ヘッドレスモードの定期実行と、無人で許す操作の決め方
• Claude Code の法人導入ガイド — 管理者が先に決める設定配布・権限・利用上限・監査
• 問い合わせメールの一次仕分けを Apps Script と Claude で自動化
• AI自動化の導入費用と投資回収のリアル
• Claude 導入支援