AI活用の再設計 16｜申告書の提出で終わりにしない。格納から社内共有までを工程にする

電子申告を送信すると、そこで一息ついてしまう。 ダウンロードした申告書の控えはダウンロードフォルダに溜まったままになり、共有ドライブへの格納も、進捗表の更新も、完了報告も後回しになる。 繁忙期にはこの「送信したあとの事務」がまるごと抜けて、あとから控えを探し回ることになる。 控えを探す手間や、進捗表の空欄に気づいて慌てて埋める作業は、繁忙期のいちばん忙しい時間を静かに奪っていく。

この記事は、税理士向けの生成AI活用をまとめた書籍の事例をお題に借りて、自分の実運用を書いてきたシリーズの続きである。 ここからの数本は、お題を書籍ではなく2025年分の確定申告の現場から取る。

提出後の事務をコマンドで固定する

固定したのは、送信のあとに残る事務そのものである。

電子申告のあとにダウンロードする提出済みファイルには、PDF、XML、HTMLの3形式が同時に残る。 このファイル名にはもともと顧問先コードが入っていたので、そこから顧問先を自動判別し、共有ドライブの規定フォルダ（提出版_日付）へ移動するコマンドを作った。 コマンドを1回実行すれば、ファイルを1つずつ開いて宛先を目で確かめる作業がなくなる。 申告書PDFからは納付額や還付額を読み取り、社内専用のチャットスペースに提出完了メッセージを自動投稿する。 投稿されるメッセージには、判別した顧問先と、読み取った納付額や還付額がそのまま載る。 格納したPDFへのリンクは、別のコマンドで業務管理スプレッドシートに書き込み、案件のステータス管理につなげる。

送信、格納、報告、記録の4つが、送信した瞬間から順につながっている。

命名規則という資産があったから、設計で縛れた

この工程化がすぐにできたのは、ファイル名の命名規則が先に存在していたからである。 顧問先コードをファイル名に含める運用は、電子申告の控えを整理するために前から続けていた。 命名規則という地味な資産があったから、あとから来たコマンドはそこに乗るだけで済んだ。 規則がなければ、まずファイル名の統一から着手する必要があっただろう。

もう一つ固定したのは、投稿先である。 手順書には「絶対にクライアントに直接メッセージを送らないこと」と明記し、投稿先は社内専用のチャットスペース1つに絞ってある。 送信先を運用者の注意力に預けると、繁忙期の誤操作でクライアントに税額の下書きが届く事故が起こり得る。 その事故は、繁忙期のさなかに人の注意力だけで防げるものではない。 宛先を設計で塞いでおけば、投稿先を選び間違える余地そのものがなくなる。 手順書に書いた禁止事項は、コマンドが投稿できる宛先そのものを1つに絞る設計と対になっている。 AIに任せる工程が増えるほど、こうした宛先のガードレールを手順書に書いておく価値は上がる。

会計事務所の定型事務に置き換える

申告完了報告、控えの格納、進捗表の更新は、会計事務所であればどこにでも存在する定型事務である。 顧問先コードのようなファイル名の命名規則さえ先に用意しておけば、同じ型で自動判別から社内報告までをつなげられる。 担当するスタッフが変わっても、命名規則とコマンドを引き継げば、格納と報告の質はそのまま保たれる。

提出は業務の終わりではなく、記録の始まりにすぎない。 終わったあとの事務ほど、毎回まったく同じ手順を繰り返しているのだから、真っ先に工程にできる。 判断の余地がほとんどない工程は、人間の裁量を残しておく理由も薄い。

提出後の格納も、送信先のガードも、頭の中の運用ではなく、作法としてファイルに固定する。