Claude Codeでできる業務自動化7選｜非エンジニア部署の実例

「Claude Codeで業務が自動化できると聞いたが、うちの経理や総務で、具体的に何ができるのか」

法人導入のご相談で、最も多い質問です。そして、この答えを探してネットを検索すると、活用事例をまとめた記事がたくさん出てきます。ただ、そのほとんどに共通する問題があります。

「作り方」は書いてあるのに、「動かし続け方」が書いていない。

実際に上位の事例記事をいくつか読んでみました。10個の事例を挙げた記事も、7つの活用パターンを挙げた記事も、どちらも具体的で参考になります。ですが、エラーが出たときにどうするか、いつ動いて何をしたかをどう記録するか、止まったことにどうやって気づくか、担当者が辞めたら誰が引き継ぐか——この4点に触れているものは、ほとんど見当たりませんでした。

これは、実務では致命的です。自動化は「動いた日」がゴールではありません。「3か月後も動いていること」がゴールです。そして自動化が壊れるとき、たいていエラーは画面に出ません。黙って止まります。

この記事では、当社が自社のバックオフィス業務で実際に動かしている7つの自動化を、作り方と運用の両方で公開します。効果を「◯◯%削減」といった数字で書くことはしません。当社が測っていない数字を書いても意味がないですし、他社の記事から数字を借りてくるのは、もっと意味がないからです。代わりに「どういう仕事が一続きになったか」を書きます。

この記事に出てくる7つの自動化は、いずれも当社（AIスキル）が自社のバックオフィス業務で実際に運用しているものです。他社の事例や公開情報からの引用ではありません。ソフトウェアの仕様・機能名は更新されるため、コマンドや設定の正確な書式は実行時点の公式ドキュメントでご確認ください。連携先サービスの提供状況・利用条件は各社の公式情報をご確認ください。

「自動化」には3つの層がある

7つの事例に入る前に、前提を1つ揃えさせてください。「業務を自動化する」という言葉は、3つの違う層をまとめて指しています。 ここを分けないと、社内の議論がかみ合いません。

1. 人が判断を決める層……何をやるか、どういう基準で判断するか。ここは自動化しません。会社の方針そのものだからです
2. AIが成果物を作る層……材料を集めて、読んで、形にする。Claude Codeが受け持つのはここです
3. 機械が決まった時刻に回す層……毎朝6時に起動する、月曜の朝に集計する。これはAIではなく、OSの定期実行の機能です

多くの会社が「自動化がうまくいかない」と言うとき、実際には1の層を決めないまま2を作ろうとしていることがほとんどです。「いい感じにまとめておいて」では、AIも同じ品質を再現できません。

逆に、1をきちんと言語化できていれば、2と3は素直に組めます。当社が業務ルールを文章で書き出し、AIがそれを毎回読む形にしているのは、この1の層を固定するためです。

自動化7選：当社で動いているもの

以下の7つは、当社のバックオフィス（経営・営業・経理・総務）で日々動いているものです。共通しているのは、どれも「材料を集めて、読んで、決まった形に整える」仕事だという点です。判断そのものは人が持っています。

① 毎朝の工程表を1枚にまとめる

何が一続きになったか

朝、その日の予定を把握するために、以前はカレンダーを開き、タスク管理を開き、メールの未読を確認し、頭の中で順番を組むという作業をしていました。それぞれ数分でも、切り替えのたびに集中が切れます。

いまは、朝に一言「おはよう」と打つと、その日のカレンダーの予定、未完のタスク、優先順位をつけた1枚の工程表が出てきます。 さらに「最初の一手」——つまり今すぐ着手すべき1件——を提案するところまで含めています。

作り方の勘所

• 読む先を絞る。 タスク管理は「受信箱だけを見る」と決めています。全プロジェクトを読ませると情報量が増えるだけで、朝の判断には邪魔になります
• 出力の形を固定する。 「工程表」の項目と順番を、あらかじめ文章で決めてあります。毎日形が違うと、比較ができません
• 読み取りだけの権限でつなぐ。 カレンダーもタスクも、書き換えの権限は渡していません

非エンジニア部署への応用

これはどの職種でもそのまま使えます。 営業なら訪問予定と商談の準備状況、経理なら締め日までの残タスク、人事なら面接予定と対応待ちの候補者。「毎朝、複数の画面を開いて状況を把握している」仕事は、全部この形に置き換わります。

② メールの下書きを、立場ごとに作り分ける

何が一続きになったか

「この件、返信しておいて」と頼むと、元のメールのやり取りを読んで、返信の下書きを作るところまでが一続きになりました。

ここで実務的に効いているのは、「どの立場で書くか」を毎回確認する仕組みです。当社の代表は複数の事業に関わっており、署名も、名乗り方も、「弊社」と言ってよいかどうかも、案件によって変わります。 ここを間違えると、単なる誤字より重い事故になります。

そこで、立場ごとの署名を文章で定義し、下書きを作る前に必ず「今回はどの立場か」を確認する手順を組み込みました。「メールの下書き」という作業に、この確認をセットで埋め込んであります。

作り方の勘所

• 絶対に送信させない。 これは運用ルールではなく権限で固定しています。送信の権限そのものを渡していないので、間違って送ることが構造的に起きません
• 機密は下書きにも書かせない。 顧客名・金額・個人情報は、外に出る文面には含めない、と決めてあります
• 下書きはファイルに保存する。 日付・相手・用件が分かる名前で保存し、あとから探せるようにしています

③ 商談の記録を、管理表とお礼の下書きに変える

何が一続きになったか

商談が終わったあとの作業は、地味に多いです。記録を残し、顧客管理の表に転記し、社内に共有し、お礼のメールを書く。 1件あたりの時間は短くても、件数が積み上がると無視できません。そして「あとでまとめてやる」と決めた瞬間に、精度が落ちます。

いまは、商談の記録が入ると、顧客管理表への転記、社内チャットへの共有、お礼メールの下書きまでが自動で並びます。 人がやるのは、内容を確認して送ることだけです。

作り方の勘所

• お礼メールは「下書き」まで。 商談の温度感は人にしか分からないので、送信は人が判断します
• 転記先の列を固定する。 「どの情報がどの列に入るか」を決めておかないと、毎回違う形になります
• 失敗したら通知する。 転記に失敗したことに気づかないと、管理表に穴が空きます。これが後述する3点セットの話です

この事例のいちばんの学び

「自動化した結果の品質が、人がやるより高くなった」点です。理由は単純で、人は疲れると省略するからです。1日に何件も商談があった日の最後の1件は、記録が短くなります。機械は同じ密度で書きます。

④ 経費一覧の空欄を、カレンダーから埋める

何が一続きになったか

確定申告や経費精算の時期に、「この飲食代は、誰と、どこで、何の目的だったか」を思い出して書く作業があります。数か月前の記録を思い出すのは、ほぼ不可能です。

この情報は、実はカレンダーに残っています。日付と時間帯が一致する予定を探せば、参加者も場所も目的も分かる。この突き合わせを自動でやるようにしました。

作り方の勘所

この事例には、他の6つにはない工夫が入っています。「確かな情報」と「推測」を色で分けるという設計です。

• 赤字＝カレンダーの予定と日時が一致して、裏が取れたもの
• 青字＝候補が複数あるなどで、AIが推測して提案したもの

そしてすでに人が書き込んである欄は、絶対に上書きしない。 このルールは強く効いています。

⑤ アンケートの自由記述を分類する

何が一続きになったか

研修後のアンケートやお客様の声には、自由記述欄があります。数十件なら読めますが、数百件になると「全部読んで、傾向を掴む」作業が現実的に回らなくなります。

いまは、自由記述をまとめて読ませて、内容ごとに分類し、件数を集計し、代表的な意見を抜き出すところまでを一続きにしています。

作り方の勘所

• 分類の軸を、こちらから与える。 「いい感じに分類して」だと、実行するたびに分類が変わって比較できません。軸を固定すると、前回との差分が見られるようになります
• 件数の集計は、AIに数えさせない。 ここは重要です。分類はAI、集計は計算処理と分けます。AIに数を数えさせると、それらしい数字が出てきてしまうことがあります
• 元の文章へ戻れるようにする。 「この分類に入った意見を全部見たい」と言われたときに、原文をたどれる形にしておきます

「分類はAI、集計は機械」——この線引きは、数字を扱う自動化すべてに当てはまります。 AIが得意なのは「意味を読み取ること」であって、「正確に数えること」ではありません。

⑥ 週次レポートを決まった時刻に作る

何が一続きになったか

当社は自社サイトのアクセス状況を毎週確認しています。以前は、複数の管理画面にログインして、期間を指定して、数字を控えて、前週と比べるという作業でした。

いまは毎週月曜の朝、先週と先々週を比較したレポートが、社内チャットに自動で流れます。 人がやるのは、それを読んで判断することだけです。

作り方の勘所：ここは徹底的にAIを使わない

この事例は、「AIを使わない判断」がいちばんの勘所です。

数字の取得と集計は、AIではなく決まった手順のプログラムでやっています。 アクセス解析の管理画面から、読み取り専用の権限で数字を直接取ってきて、そのまま計算する。AIには一切集計させません。

理由は数字の幻覚を防ぐためです。AIに「先週のアクセス数をまとめて」と頼むと、もっともらしい数字が返ってくることがあります。それが正しいかどうかは、元データを見ないと分かりません。毎週見るレポートで、毎週元データを検算するなら、自動化する意味がありません。

非エンジニア部署への応用

売上の週次集計、問い合わせ件数の推移、在庫の状況、勤怠の集計。「毎週決まった場所から数字を取ってきて、前週と比べる」仕事は、すべてこの形に置き換えられます。 ポイントは繰り返しになりますが、数字はプログラムに取らせて、AIには「何が変わったか」の説明だけを書かせることです。

⑦ 定型文書の下書きを、毎日決まった数だけ作る

何が一続きになったか

これは、いまあなたが読んでいるこの記事そのものの話です。

当社は、記事のテーマを優先順位つきの待ち行列として1つのファイルに並べています。毎日決まった時刻に処理が起動して、行列の先頭から未着手のテーマを取り、上位記事を実際に読んで論点を確認し、原稿と図解を作り、下書きとして投入し、行列の状態を「下書き済み」に更新する——ここまでを自動で行います。

作り方の勘所

• 公開は絶対に自動化しない。 作るのは下書きまで。公開するかどうかは、人が目で見て判断します。これは品質の問題であると同時に、対外的な責任の問題です
• ネタが尽きたら、水増しせずに知らせる。 行列の残りが少なくなったら「補充が必要」と通知します。行列が空になったときに、無理に薄い記事を作らせない——これが最も重要な設計判断でした
• 数字は必ず一次情報で裏を取る。 料金や助成率のような数字は、他社の記事から写さず、公式の情報源で確認したものだけを書く、というルールを組み込んであります

非エンジニア部署への応用

「毎日／毎週、決まった形の文書を、決まった数だけ作る」仕事は、広報以外にもあります。採用の求人票、商品説明文、社内向けのお知らせ、定型の報告書。 どれも「元になる情報」と「形の決まり」があれば、この形に乗ります。

ただし、⑦は7つの中で最もリスクが高い自動化です。 外に出る文章を機械が作るからです。だからこそ、公開の一歩手前で必ず人が止まる設計にしています。

「動いた」で終わらせない3点セット

ここからが、他の事例記事に書かれていない部分です。当社は、新しく自動化を作るときに必ず入れる3点セットを決めています。 これが無い状態は「未完成」と扱います。

1. エラーを握りつぶさない

プログラムには、エラーが起きても何事もなかったように進む書き方があります。これは絶対に使いません。 握りつぶすと、動いていないのに動いている顔をする状態になるからです。

想定できる失敗——通信のタイムアウト、認証の期限切れ、データが空だった——は、それぞれ個別に受け止めて、何が起きたかを記録します。

2. いつ動いて何をしたかを記録する

開始時刻、終了時刻、処理した件数、エラーの内容。これを日時つきでファイルに残します。

この記録があると、「先週から様子がおかしい」に気づけます。 件数が急に減っていれば、どこかで取りこぼしている。処理時間が伸びていれば、データが増えすぎている。記録が無いと、完全に止まるまで誰も気づけません。

3. 失敗したときの通知先を決める

記録は、見に行かないと気づけません。 だから、失敗したときは人が必ず見る場所——当社の場合は社内チャット——に流します。

そのとき書くのは2行だけです。「何が失敗したか」と「次に何をすればいいか」。 エラーの詳細をそのまま貼っても、非エンジニアには判断できません。

実際に「静かに止まった」話

3点セットの必要性を、当社は実際の事故から学びました。恥をさらしますが、いちばん役に立つ部分だと思うので書きます。

事故1：通知の設定が、そもそも間違っていた

自動化を作り、失敗したらチャットに通知する仕組みも入れました。手動でテストして、通知が届くことも確認しました。ところが定期実行に登録したあと、通知だけが飛ばなくなりました。

原因は、通知に必要な設定を「どのフォルダから実行したか」によって読めたり読めなかったりしたことでした。手動テストのときは正しいフォルダにいたので届き、自動実行のときは別のフォルダから起動されたので届かない。

本体の処理は成功していたので、誰も異常だと思いませんでした。 通知が来ないのは「問題が起きていないから」だと解釈していたのです。

学び：通知の仕組み自体を、実際の自動実行の条件でテストする。 手動テストが通ったことは、自動実行が通ることを意味しません。

事故2：外部と通信する権限が、承認されていなかった

別の自動化で、処理が途中で止まっているのに、エラーが何も出ないことがありました。調べると、外部のサービスへ通信する権限が承認されておらず、そこで静かに終了していたのが原因でした。

学び：自動化が理由もなく静かに止まったら、まず権限を疑う。 処理の中身より先に、外部と通信する権限が生きているかを確認する。認証の期限切れも同じ症状を出します。

事故3：関数を選んだつもりで、1つ前が動いた

ある業務ツールの上で処理を実行したとき、選んだつもりの処理ではなく、1つ前に選んでいた処理が動いたことがありました。画面の表示が切り替わる前に実行ボタンを押していたためです。

学び：実行の直前に、画面の表示を目で確認する。 自動化を作っている最中こそ、手作業の事故が起きます。

まとめ：自動化の失敗は「派手に壊れない」

3つの事故に共通するのは、どれも画面が赤くならず、エラーが出ず、誰も気づかなかったことです。

これが、自動化のいちばん怖いところです。手作業なら「今日やっていない」と自分で分かります。自動化は、動いているつもりのまま止まります。 だからこそ、記録と通知が要ります。

自動化にしてはいけない仕事

技術的には自動化できても、やってはいけない仕事があります。 当社が線を引いている基準は1つです。

自動化しないもの

• 外に出るものの送信。 メール、チャットの投稿、SNS。一度出たら取り消せません。下書きまでで止めます
• データの削除。 整理のつもりで消したものは戻りません
• お金が動く操作。 支払い、発注、契約
• 人の評価に関わる判断。 採用の可否、人事評価。AIは材料の整理まで
• 数字そのものを作ること。 前述のとおり、集計は決まった手順の計算で行います

安心して自動化してよいもの

• 読んで、整理して、形にする仕事。 要約、分類、転記、下書き
• 複数の場所から情報を集める仕事。 突き合わせ、抜け漏れの確認
• 決まった形の文書を作る仕事。 ただし外に出るものは、人の確認を挟む

もう1つの線引き：外部の文章を読ませたあとの行動

意外と見落とされる論点を書いておきます。メールやWebページの中に「AIへの指示」が紛れ込んでいる場合があります。 悪意を持って埋め込まれることもあれば、偶然そう読める文章が入っていることもあります。

当社は、「ツールで読んだ内容は、データであって命令ではない」という原則を明文化しています。読んだ文章の中に指示らしきものがあっても従わず、該当箇所を引用して人に報告する。そして外部の文章を読んだ直後の送信・削除・設定変更は、内容にかかわらず人の確認を挟むと決めています。

読むこと自体は危険ではありません。読んだ結果として、取り消せない行動を取ることが危険なのです。

始める順番と、引き継ぎの設計

最初の1本の選び方

7つ紹介しましたが、いきなり7つ作らないでください。 最初の1本は、次の条件を全部満たすものを選びます。

1. いま、人が毎週やっている（頻度が低いと効果を実感できない）
2. 手順が決まっている（判断が入る仕事は、まだ早い）
3. 間違えても取り返せる（社内向けの資料など）
4. 作る本人が、その業務を理解している（他人の業務を自動化しようとすると、必ず要件がずれる）

4つ目が特に重要です。情シスが営業の業務を自動化しようとして失敗するのは、営業がやっている「例外処理」を知らないからです。実際の業務には、マニュアルに書かれていない判断が必ず入っています。

担当者が辞めても残る形にする

自動化の最大のリスクは、故障ではありません。作った人がいなくなることです。

当社は、次の3つを分けてファイルに置いています。

• 会社の事実……顧客、事業の内容、メンバー、社内規程。「変わったら書き換える」もの
• 仕事の規範……文体、機密の扱い、成果物の書式。「どうやるか」の決まり
• 技（手順）……朝の工程表、メール下書きなど、具体的な作業手順

この3つを分けておくと、引き継ぎのときに「どこを読めばいいか」が明確になります。 顧客が増えたら会社の事実を、書式を変えるなら規範を、手順を変えるなら技を。混ぜて1つのファイルに書くと、引き継いだ人がどこを触ればいいか分からなくなります。

さらに、すべての変更を履歴として残すようにしています。区切りごとに自動で保存されるので、「いつ、何を、なぜ変えたか」が後から追えます。これは非エンジニアの業務ファイルにこそ効きます。「最終版_修正_v3.xlsx」という名前のファイルが並ぶ状態から抜け出せます。

3か月後に必ずやること

• まだ使われているか確認する。 作ったのに使われていない自動化は、止めた方がいい
• つないでいる権限を棚卸しする。 権限は放っておくと必ず溜まります
• 手順を見直す。 業務が変わっているのに、自動化だけ古い手順のまま動いていることがあります

よくある質問

プログラミングができないと作れませんか？

作れます。当社の自動化も、日本語で「こうしたい」と伝えて作ってもらったものが大半です。ただし、「何をどういう順番でやるか」を言葉にする力は必要です。これはプログラミングの能力ではなく、業務を分解する能力です。最初の一歩は非エンジニアのためのClaude Code入門にまとめています。

自動化を作るのに、どれくらい時間がかかりますか？

作業自体は、単純なものなら1回のやり取りで形になります。時間がかかるのは、作ることではなく「何を自動化するか決めること」と「動かし続ける仕組みを整えること」です。前者は業務の棚卸し、後者は前述の3点セット。当社の感覚では、作る時間より、この前後の設計に時間をかけた自動化の方が長生きします。

社内のツールとつなぐには、何が必要ですか？

MCPという共通規格を使って接続します。カレンダー、メール、チャット、表計算などの主要なサービスがつながります。つなぐ作業自体は数分ですが、「どこまで読ませ、何を書き込ませないか」の設計に時間をかけてください。 詳しくはMCPの記事で解説しています。

費用はどれくらいかかりますか？

定期実行の自動化は、人が座っている時間とは無関係に動くため、「1人が使う量」ではなく「仕組みが消費する量」として見積もる必要があります。プランの選び方と費用の考え方は料金の記事で整理しています。

失敗したときのリスクが心配です

その心配は正しいです。だからこそ、取り消せない操作を権限として持たせない設計にしてください。送信できない、削除できない、支払えない。この状態を作っておけば、AIが間違えても事故になりません。「気をつける」ではなく「できないようにする」——これが当社の設計の中心にある考え方です。

どこから相談すればいいですか？

「いま人が毎週やっている、手順の決まった作業」を1つ挙げていただければ十分です。 そこから、自動化できる範囲、必要な権限、動かし続けるための仕組みまでご提案します。ご相談・お見積りは無料です。

まとめ

Claude Codeでできる業務自動化を、当社が実際に動かしている7つで紹介しました。どれもバックオフィスの仕事で、コードを書く作業は1つも入っていません。

• 朝の工程表……複数の画面を開いて状況を把握する仕事は、1枚に畳める
• メールの下書き……立場ごとの名乗り方まで固定して、送信は権限ごと外す
• 商談記録の転記……人は疲れると省略するが、機械は同じ密度で書く
• 経費の空欄補完……裏が取れたものと推測を色で分けると、確認精度が上がる
• アンケートの分類……分類はAI、集計は機械。軸を固定すると前回と比較できる
• 週次レポート……数字はプログラムに取らせる。気づけない場所にAIを置かない
• 定型文書の下書き……公開は自動化しない。ネタが尽きたら水増しせず知らせる

そして、この記事でいちばん伝えたいのは事例そのものではありません。

エラーを握りつぶさない。いつ動いて何をしたかを記録する。失敗したら人が見る場所に通知する。そして、成功したことも通知する。この4つが無い自動化は、いつか静かに止まり、誰も気づかないまま業務に穴が空きます。

最初の1本は、毎週やっていて、手順が決まっていて、間違えても取り返せる仕事から選んでください。小さく作って、記録と通知を付けて、3か月動かす。 そこまでやり切れば、2本目からは同じ型を配るだけになります。

当社では、Claude Codeの研修と法人導入支援を行っています。「うちの業務のどこから自動化すべきか」「動かし続けるために何を整えるべきか」といった設計から、実際の構築・社内展開・引き継ぎの仕組みづくりまで、まとめてご相談いただけます。この記事で紹介した7つは、いずれも当社自身が日々の業務で使っているものです。ご相談・お見積りは無料です。

御社の業務で、まず何から自動化すべきかご提案します
ご相談・お見積もりは無料です

無料で相談する →