申告が終わったあと、税理士事務所の中では地味な作業が続きます。e-TaxやeLTAXから届いた申告書の控え・受信通知・納付情報を、顧問先ごとのフォルダに保存し、「保存しました。納付はこちらの番号で」と連絡する仕事です。

当法人でも以前は、ダウンロードした書類が1つのフォルダに山積みになり、担当者がファイル名から会社を見分けて共有ドライブの各社フォルダへ移し、ペイジー（Pay-easy）の納付番号をBacklogに書き写していました。件数が多い時期は、この作業だけで半日消えます。

このシリーズでは、当法人がAIコーディングツール「Claude Code」と一緒に社内の業務システムを作り替えてきた過程を、実際の数字と失敗談を含めてお伝えします。第1回は、この作業をGoogle共有ドライブ×Backlog×GASで自動化した仕組みの話です。速さと同じくらい重視したのが、別の顧問先へ書類や納付情報が届く「誤送信・誤共有」を構造的に起こさないことでした。あわせて、その延長で作った「会議の議事録から次のタスクを起こす」仕組みも紹介します。

当法人の代表はSE出身の公認会計士・税理士です。「税理士事務所がなぜ自前でシステムを」と思われるかもしれませんが、自分たちの業務を自分たちで作り替えた経験が、そのままお客様のバックオフィスDX支援の土台になっています。

できあがった流れ

担当者の操作は、スプレッドシートのメニューから「書類振り分け」を選ぶだけです。

移動元フォルダ（e-Tax/eLTAXから落とした書類が溜まる場所）
   └→ GAS がファイル名から顧問先を判定
        ├→ 対象会社の共有ドライブの、指定のフォルダへ移動
        ├→ 納付情報のHTMLからペイジーの番号・金額を抽出
        └→ 対象会社の Backlog プロジェクトに、1件の課題で報告
              （保存先リンク＋税目ごとの納付情報）

対象にしているのは、償却資産申告書・給与支払報告書・法定調書・所得税徴収高計算書・確定申告書・各種届出の6種類です。書類の種類ごとに保存先の階層が違うので、それぞれ判定ルールを持たせています。

顧問先には、Backlogの課題として「控えを保存しました」と、保存先へのリンク、納付が必要な税目と金額・番号が届きます。書き写しがなくなったので、転記ミスも構造的になくなりました。

誤送信・誤った情報共有が「起きない」構造にする

この仕組みで、速さよりも優先したのが「別の顧問先の書類が、別の顧問先に届かない」ことです。税務書類には金額も納付番号も入っています。メールなら宛先の打ち間違い・CCの付け忘れで一瞬で起きる事故を、構造として起きないようにしました。

1. 宛先を、実行のたびに人が選ばない

送り先は、あらかじめ設定シートに顧問先ごとに登録しておきます。

設定シートに持っている情報（顧問先ごと）
対象会社の共有ドライブ上の保存先フォルダ（書類の種類ごとに階層まで）
報告先のBacklogプロジェクト
課題の担当者・期限のルール
判定に使う会社名の表記

実行時に担当者が「どこに保存するか」「誰に送るか」を選ぶ画面はありません。選ぶ操作がなければ、選び間違いも起きません。新しい顧問先が増えたときも、設定シートに1行足すだけで、以後は同じルールで動きます。

2. 判定できないファイルは、動かさない

ファイル名に含まれる会社名は正式名称どおりとは限りません。「株式会社」が前に付いたり後ろに付いたり、そもそも付いていなかったり、全角・半角が混ざったりします。

判定は2段階にしました。

  1. 文字を正規化して、一番長く一致した会社を採用する
  2. それで決まらなければ、空白と法人格（株式会社・有限会社・医療法人社団など）を取り除いてもう一度比べる

そして、同じ長さで複数の会社に一致したら「判定不能」として処理しないと決めています。誤った会社のフォルダに移して誤った会社に報告するより、移さずに残して人が見るほうが、ずっと安全だからです。「うまく判定して自動化率を上げる」より、「迷ったら止まる」を優先しました。

3. 保存先も報告先も、顧問先ごとにアクセス権で閉じている

書類の保存先は、顧問先ごとに用意した共有ドライブです。共有ドライブのアクセス権はその顧問先の担当者と当法人だけに設定してあり、部外者はもちろん、他の顧問先からも見えません。ファイルはこの共有ドライブの中の、あらかじめ決めたフォルダに入ります。

報告先も同じ考え方で、Backlogの顧問先ごとのプロジェクトに届きます。プロジェクトはユーザー単位でアクセス権を設定してあり、招待されたユーザー以外は課題の存在も内容も確認できません。A社のプロジェクトに届いた課題をB社が見ることはできません。（Backlogの運用はこちらの記事で紹介しています。）

判定ミスが仮に起きても、届く先は「その顧問先と当法人しか入れない場所」に限られる——設定シートで送り先を固定すること（1）と、送り先自体をアクセス権で閉じておくこと（3）の二重の壁で守っています。

4. 中途半端な報告をしない「保留」

受信通知には税目ごとの税額が入っています。税額があるのに、対応する納付情報のファイルが見当たらない場合、その会社についてはファイルの移動も報告も止めて、担当者のGoogle Chatに「納付情報が足りない」と知らせます。

「控えは保存しました」とだけ報告して納付情報が後から届くと、顧問先は2回確認することになりますし、間違った番号を伝えるリスクも増えます。報告は揃ってから1回、と決めました。

5. 本番の前に「試運転」、テストは社内向けに固定

移動も報告も、実行前に「何を、どこへ、誰に」の一覧だけを出すドライランを用意しました。ファイルを動かす処理には必ず入れています（そう決めるきっかけになった事故は、第3回で詳しく書きます）。動作確認のためのテスト送信は、送り先が社内用のプロジェクトに固定されていて、顧問先のプロジェクトへ試しに送ることはできない作りです。

共通しているのは、人の注意力に頼る場所を減らすことです。「気をつけて送る」ではなく、「送り先が最初から決まっていて、迷ったら止まる」。誤送信対策として一番効くのは、送信の瞬間の確認ではなく、送信の前に選ぶ余地をなくすことでした。

そのほかの設計

重複ファイルの退避

同じ書類を2回ダウンロードすると「(1)」付きのファイルができます。中身のハッシュ値（MD5）で重複を検出し、正本だけを通常処理、重複分は保存先の「重複」フォルダへ移します。捨てずに退避するのは、「消してよかったのか」を後から確認できるようにするためです。

51件が1件も見つからなかった話

この仕組みにも、動かして初めて分かったことがあります。

「各種届出」の保存先フォルダを、顧問先ごとに自動で見つけて登録する処理を作ったときのことです。フォルダ名に「税務届出」を含むものを探す、というルールで実行したところ、51件すべてが0ヒットでした。

原因は、実際のフォルダ名が「税務関係届出」で、語順が違っていたことです。「税務」と「届出」の両方を含めばよい、という判定に変えて再実行し、38件が登録、18件はスキップ（フォルダ自体が未作成）に落ち着きました。

日本語のフォルダ名は、同じ意味でも人によって書き方が違います。「完全一致で探す」は、人が付けた名前に対してはほぼ通用しない、というのが実感です。

もう1つ。設定はスプレッドシートに持たせているのですが、途中で列を挿入するたびに、コード側の「最後の列」の番号がずれて修正が必要になりました。スプレッドシートを設定ファイルにするのは手軽ですが、列の位置に依存しない書き方を最初からしておくべきでした。

延長線：会議の議事録から、次のタスクを自動で起こす

ファイルを動かす仕組みができると、次に欲しくなるのが「動かしたことをきっかけに何かをする」ことです。

当法人では顧問先との定例のWeb会議で、Geminiが議事録を自動生成し、Googleドキュメントとしてメールで届く運用をしています。この議事録を、次のように処理しています。

  1. Gmailを検索し、本文に含まれるGoogleドライブのリンクを拾う
  2. リンク先のドキュメントを、その顧問先のフォルダへ移動する
  3. 移動が成功したら、顧問先管理の中核システム（第2回で紹介します）に「この会社の議事録がここにある」と通知する
  4. 中核システム側が議事録を読み、「次のステップ」として書かれた項目を抽出して、担当者ごとのサブタスクをBacklogに起票する

会議で「来月までに○○を確認」と話した内容が、翌朝にはBacklogの課題になっている、という状態です。

ここでの設計判断も2つ記録しておきます。

  • 移動する側は「会社コード」しか知らない：どの会社がBacklogのどのプロジェクトかは、中核システムの顧客マスタだけが持ちます。小さなスクリプトが対応表を持ち始めると、必ずどちらかが古くなるからです
  • 通知に失敗してもファイルの移動は止めない。ただし黙らない：中核システムへの通知は「できれば」の扱いですが、失敗したら「権限が切れている可能性があります。手動で再認可してください」と対処法まで含めてログに残します。静かに失敗する仕組みが一番怖い、というのは第3回で書く事故から学んだことです

Claude Codeとの分担で効いたこと

この2つのプロジェクトで特徴的だったのは、テストの回し方です。

GAS（Google Apps Script）は本来、Googleのエディタ上でしか動きません。しかしClaude Codeにテストを書かせ、判定ロジックの部分だけを手元のNode.jsで動く形に切り出したことで、「株式会社が後ろに付いた名前」「同じ長さで2社に一致する名前」といった境界ケースを、Googleにアップロードせずに何十通りも試せるようになりました。

もう1つは、CLAUDE.md（AIに渡すルールブック）に日付付きの変更履歴を残していることです。「7月9日、51件0ヒット、原因は語順、対策は両方を含む判定に変更」という記録があるので、半年後に似た処理を作るときに、同じ穴に落ちません。

顧問先にとって何が変わったか

  • 申告後の控えが、自社のフォルダに、決まった階層で届く
  • 納付が必要な税目・金額・番号が、Backlogの1件の課題にまとまって届く
  • 会議で決めた「次にやること」が、担当者ごとのタスクとして翌朝には見える
  • 送り先が事前登録されているので、他社の書類が紛れ込む・自社の書類が他社に届くことがない

「連絡を待つ」時間が減り、同時に「届いた情報が正しいか」を疑う必要も減る変化です。

次回：顧問先管理とタスク起票の中核システム

第2回は、この記事で報告先として登場したBacklogの課題を「誰が、いつ起票しているのか」の側——AppSheet・スプレッドシート・Backlogをつないだ、顧問先管理と定期タスク自動起票の中核システムを紹介します。「自動タスク登録」というスプレッドシートが33個並んでいたところから始まります。

シリーズ

  1. e-Taxの控えを共有ドライブへ自動振り分けし、Backlogで報告する仕組み（本記事）
  2. AppSheet×スプレッドシート×Backlogで顧問先管理とタスク起票を自動化した話（近日公開）
  3. 自動化で起きた3つの事故と、壊れにくい設計に変えるまで（近日公開）
  4. 月次監査・決算監査ツール：マネーフォワード連携スプレッドシート＋AIの2階建て（近日公開）