「所得税徴収高計算書の提出、あの会社は今月だっけ」 「年末調整の案内、全社に送り終わったか誰か把握してる？」
税理士法人の中は、顧問先ごとに少しずつ違う定期タスクであふれています。当法人も例外ではなく、数年前まで「自動タスク登録（○○社）」という名前のスプレッドシートが顧問先の数だけ並び、それぞれに紐づいたGAS（Google Apps Script）がBacklogに課題を起票していました。起票そのものは自動でしたが、ルールがクライアントごとに分かれていたのです。
このシリーズでは、当法人がAIコーディングツール「Claude Code」と一緒に社内の業務システムを作り替えてきた過程を、実際の数字と失敗談を含めてお伝えしています。第1回は、e-Taxの控えを共有ドライブへ振り分けてBacklogで報告する仕組みを紹介しました。第2回は、その報告先でもある顧問先管理（CRM）と定期タスクの自動起票を担う中核システムの全体像です。
作り替える前の状態
作り替える前に、まず現状を数えました。Claude Codeにスプレッドシート群を読ませて棚卸ししたところ、次のことが分かりました。
- 「自動タスク登録」シートが顧問先の数だけバラバラに存在
- 全社共通のタスクが、各社のシートに丸ごとコピーされていた（その大半が実質的な重複）
- 1社にしか存在しないタスクも相当な数
つまり「起票は自動だが、同じルールがクライアントごとに分かれて書かれていて、直すときは全部の場所を直す」構造でした。1か所だけ直し忘れると、その会社だけ古いルールで起票され続けます。自動化していなかったのではなく、自動化の置き場が散らばっていたのが問題でした。
これは税理士法人に限らず、Excelやスプレッドシートで管理を始めた組織が必ず通る道だと思います。
なぜ仕組み化するのか——品質と生産性は、漏れの前ではトレードオフになる
作り替えの目的をはっきりさせておきます。
税理士の仕事で、タスクの漏れはそのままサービス品質の低下です。納付書の案内が1社だけ抜ける、年末調整の案内が1社だけ遅れる——全体で見ればわずかな件数でも、その顧問先にとっては重大な出来事です。
かといって、漏れを防ごうと「何か抜けていないか」を人が都度確認して回ると、今度は生産性が落ちます。確認そのものは成果を生む仕事ではありませんし、「漏れていないこと」の確認には終わりがありません。担当者の記憶とチェックリストに頼るほど、確認の回数は増え、それでも不安は消えない。つまり人力で漏れ対策をする限り、品質を上げようとすれば生産性が落ち、生産性を上げようとすれば品質が危うくなるというトレードオフから抜けられません。
このトレードオフを断ち切るのが、定期タスクの登録の仕組み化です。「起票されるべきタスクは、ルールどおり必ず起票されている」と仕組みの側で保証できれば、人は漏れの心配から解放され、確認に使っていた時間は本来の仕事に戻ります。サービス品質と生産性を同時に上げる——このシステムの目的はこの一点です。
そしてこの構造は、規模が増えても壊れません。担当者の記憶に頼る運用では、顧問先が増えるほど確認の量と漏れのリスクが積み上がります。この仕組みでは、顧問先が1社増えてもやることはAppSheetのマスタに1行足すだけで、翌朝からは既存の顧問先とまったく同じルールでタスクが起票されます。クライアントが増えても、ほぼ同じ品質でサービスを提供できる体制が整いました。
作り替えた後の全体像
新しい仕組みは、役割をはっきり分けた4つの部品でできています。
AppSheet（唯一の入力口）
└→ Googleスプレッドシート（データ25シート＋ダッシュボード8シート）
└→ 変更を検知 → Google Apps Script（処理エンジン）
├→ Backlog（顧問先ごとのプロジェクトに課題を起票）
├→ Google Chat（担当者への通知）
└→ Google Drive（添付ファイルの保存）
←─ Backlog側の変更（完了・期限変更・削除）は即時にシートへ戻る
| 部品 | 役割 |
|---|---|
| AppSheet | 顧問先の新規登録・情報変更を受け付ける唯一の入力口。スマホからも使える |
| スプレッドシート | データの置き場。人は直接編集しない（シート保護で物理的に止めている） |
| Google Apps Script（GAS） | シートの変更を検知して、Backlogへの起票・マスタ更新・通知を行う |
| Backlog | タスクを実行する場。顧問先とのやり取りもここで行う（Backlogの使い方はこちら） |
ポイントは「入力はAppSheetだけ、実行はBacklogだけ」という一方通行にしたことです。スプレッドシートは真ん中にありますが、人が触る画面ではありません。
毎朝、何が自動で動いているか
GASは時間をトリガーに、毎朝ほぼ同じ順番で動きます。
| 時刻 | 処理 |
|---|---|
| 7:00 | ダッシュボード8シートを更新 |
| 7:30（月曜） | 週次のデータ整合性チェック（顧客とプロジェクトの対応、重複、孤立データ） |
| 8:10 | 期限超過タスクの通知 |
| 8:30 | 全体のダイジェスト |
| 8:40 | 担当者ごとの「今日の未了タスク」朝レポート |
| 9:00 | その日が起票日の定期タスクを、該当する全顧問先のBacklogに一斉起票 |
| 以後60分ごと | Backlog側の変更の取り込み（即時同期の取りこぼしを拾う安全網） |
定期タスクは、顧問先ごとのシートに散っていたものをわずかな数のテンプレートに集約しました。「決算月の2か月前に決算前確認を起票」「毎年11月に年末調整の案内を起票」のように、テンプレートに条件を書いておけば、顧問先の決算月や契約内容を見て、GASが該当する会社にだけ起票します。
顧問先の決算月が変わったら、AppSheetで1か所直すだけです。翌朝からは新しい決算月で計算されます。
タスクを「3つの軸」で眺められるようにした
この仕組みの設計を一言でいうと、すべてのタスクに3つの座標を持たせたことです。
税理士法人のタスクは、「どの業務か（源泉・決算・年末調整…）」「どの顧問先か」「いつやるか」の3つが決まって初めて実行できます。紙のチェックリストや1枚のスプレッドシートは、縦と横の2軸を使った時点で満杯になるため、3つめの軸は「シートを分ける」ことでしか表せません。私たちのシートが顧問先の数だけ増殖していたのは、まさに時間軸をシートの複製で表現していたからでした。
作り替えた後の形は、AppSheetのマスタが「業務 × 顧問先」の2次元の組み合わせを定義し、そこへ毎朝GASが、その日の分のタスクをBacklogに流し込む、というものです。イメージとしては、業務 × 顧問先の平面から、1年の時間軸に向かってタスクが流れていく3次元の空間です。
流れは一方通行ではありません。Backlogはお客様とのやり取りと実行の場で、そこでのステータス変更やコメントの動きは即時にAppSheetへ同期されます（万一取りこぼしても、前の表の60分ごとの取り込みがフォローします）。起票はAppSheet→Backlog、実行の結果はBacklog→AppSheet。だからタスク全体の一括管理はAppSheetの画面ひとつでできます。
3次元にした価値は、同じデータをどの方向からでも輪切りにできることです。すべてのタスクが顧問先・業務の種類・期限の3つの座標を持ってAppSheetに集まっているので、ビューの切り口を変えるだけで済みます。
- 顧問先で切る … A社の今月のタスクは何が残っているか。担当者の記憶ではなく、一覧を開けば全部並ぶ
- 業務の種類で切る … 年末調整は全顧問先のうちどこまで終わったか。進捗が横断で見える
- 時間で切る … 今週締切のタスクは全社で何件あるか。そのまま朝会の資料になる
この輪切りは、管理者だけのものではありません。入力口をAppSheetにしたことで、この仕組みをチームメンバー全員にクラウドシステムとして展開できます。メンバーはスプレッドシートを直接触るのではなく、スマートフォンやブラウザからアプリとして開くだけです。そしてメンバーはそれぞれ、自分用のフィルタを複数作れます。「自分の担当先の今週のタスク」「自分が受け持つ年末調整だけ」のように、切り口を自分の仕事に合わせて用意しておけば、アプリを開いた瞬間に自分のタスクだけに集中できます。全体を貫く3つの軸は同じまま、見る人ごとに最適な断面を持てるわけです。
以前は、切り口ごとに別の表を作って転記していました。表同士がズレた瞬間に「どれが正か」の確認作業が発生し、それがまたタスクを増やす——という悪循環です。軸を増やす代わりに、データは1か所。 これが顧問先の数だけあったシートを1つのマスタに畳み込めた理由であり、この記事のシステム構成そのものです。
Backlogを軸にしたもう一つの理由——AIとの相性
Backlogは、課題（タスク）ごとにやり取りがスレッドとしてまとまる構造です。「この件について、誰が・いつ・何を言ったか」が課題単位で閉じているので、人が経緯を追いやすいだけでなく、AIにとってもコンテキストを管理しやすい形をしています。1つの課題を読ませれば、その仕事に必要な文脈がそこに揃っているからです。加えてBacklogはMCP（Model Context Protocol。AIがツールに接続するための共通規格）も公開しており、AIから課題を直接読み書きできます。
当法人ではこれを活かして、Claude CodeとGemini Notebook（旧NotebookLM）を組み合わせた運用をしています。税務・会計の専門資料を分野別に読み込ませたGemini Notebookを社内の知識ベースとして用意しておき、Backlogの課題スレッドをClaude Codeに読ませて、質問の内容に合う分野のNotebookへ自動で振り分け、タスクへの回答案を用意してもらうという流れです。担当者はゼロから書き始めるのではなく、AIの下書きを確認して直すところから始められます。タスク管理ツールとしての使いやすさに加えて、このAIとの相性の良さも、Backlogを仕組みの軸に据えてよかった点です。
設計で決めた「やらないこと」
このシステムを作るときに、機能よりも先に決めたのが「やらないこと」でした。Claude Codeに渡すルールブック（CLAUDE.md）の禁止事項として書いてあります。
1. スプレッドシートを人が直接編集する設計にしない 入力はAppSheetのフォームだけ。フォーム側で入力チェックをかけ、シート自体は保護します。「ちょっと直しておいた」が一番の事故原因だからです。
2. 顧問先とBacklogプロジェクトの対応表は1か所にしか持たない 「どの会社がどのプロジェクトか」は顧客マスタだけが知っています。周辺の小さなスクリプト（第1回で紹介したファイル移動など）は、会社コードだけを渡してマスタに問い合わせます。対応表を2か所に持つと、必ずどちらかが古くなります。
3. 削除は自動でやらない これは第3回で詳しく書きますが、自動処理に「消す」権限を持たせて痛い目を見ました。今は、削除はBacklog側で人が行い、その通知を受けてシートを更新する一方向だけです。
Claude Codeとどう分担したか
「AIが全部作った」わけではありません。分担はおおむね次のとおりです。
| 工程 | 人（当法人） | Claude Code |
|---|---|---|
| 業務の棚卸し | 何が問題かを言語化 | 全シートを読んで集計・分類 |
| 設計 | 「やらないこと」と優先順位を決める | 設計案を出す。別のAIにレビューさせて穴を探す |
| 実装 | 動作確認・受け入れ | コードを書く。テストを書く |
| 運用 | 事故対応の判断 | 原因調査、修正案、再発防止策の文書化 |
やってみて分かった実務上の工夫を3つ挙げます。
ルールブックを育てる
CLAUDE.md というファイルに、設計上の前提・禁止事項・過去の事故を書き足していきます。新しい機能を頼むとき、Claude Codeはこれを先に読むので、「前に決めたこと」を毎回説明しなくて済みます。今では事故の日付と原因まで書かれた、事務所の設計台帳になっています。
いきなり本番で動かさない 一回きりのデータ修正でも、必ず「変更予定の一覧を出すだけ」の試運転を先に走らせ、件数を人が見てから本番実行します。この手順自体をClaude Codeの「スキル」として保存し、毎回同じ手順を踏ませています。
レビューを2段にする 計画を立てたら別のAIにレビューさせ、指摘を反映してから実装に入ります。作ったコードも、人が見る前にもう一度レビューさせます。半年で265回のコミット（変更の記録）を重ねましたが、「レビュー指摘を反映」というコミットが何度も出てきます。
顧問先にとって何が変わったか
社内システムの話ですが、顧問先から見える変化もあります。
- ルールの取り残しが構造的に起きにくい：定期タスクのルールはテンプレート1か所にあるので、「その会社のシートだけ古いルールのまま」が起きません
- 進捗がBacklogで見える：起票された課題は顧問先のプロジェクトに入るので、「今、何がどこまで進んでいるか」を顧問先も同じ画面で確認できます
- 担当者が変わっても同じ：ルールはテンプレートにあるので、引き継ぎで「その会社だけの慣習」が失われません
次回：自動化で起きた3つの事故
ここまで読むと順調に見えますが、実際には自動処理が98件中64件の案件を誤って「削除済み」扱いにした事故もありました。第3回では、その顛末と、どう設計を変えたかを書きます。
シリーズ
- e-Taxの控えを共有ドライブへ自動振り分けし、Backlogで報告する仕組み
- AppSheet（スプレッドシート）×GAS×Backlogで顧問先管理とタスク起票を自動化した話（本記事）
- 自動化で起きた3つの事故と、壊れにくい設計に変えるまで
- 月次監査・決算監査ツール：マネーフォワード連携スプレッドシート＋AIの2階建て
