顧問先の会計データを AI に渡すとき、税理士事務所が先に決めること

記帳代行や顧問先を多く抱える事務所ほど、AI で記帳を速くしたい動機は強いはずです。月初の山を崩す、担当者ごとのばらつきを抑える、人手が足りない分を補う——どれも切実です。

ただ、事務所が扱っているのは自社のデータではなく、顧問先から預かったデータです。そこには法律上の守秘義務があり、「どう扱ったか」を顧問先に説明できる責任もあります。AI を記帳に挟むと、この二つ——守秘と説明責任——が、いちばん揺らぎやすくなります。速さの前に、ここをどう守るかを決めておきます。AI に渡す情報を絞るという土台の考え方は、こちらの記事で扱っています。

いちばんの問題は「顧問先データの混線」

ありがちな配線は、顧問先ごとのトークンと明細を一つの作業ディレクトリにまとめ、「この顧問先の今月分を分類して」と AI にそのまま渡す形です。速くはなります。けれど、複数の顧問先のトークンや明細が同じ場所・同じ AI のコンテキストに乗ると、二つの問題が出ます。

一つは、A 社の情報が B 社の判定の文脈に混ざり得ること。もう一つは、誰の・どの情報が・どこまで AI や連携先に渡ったのかを、後から説明できなくなることです。預かりものを扱う以上、「混ざらないこと」と「説明できること」は、速さと同じ重さで要求されます。

「速くなった」だけでは、説明責任を果たせない

税理士には、法律で守秘義務が課されています。顧問先に対して「あなたのデータは、こう扱いました」と言えることまでが、記帳代行の品質です。AI がブラックボックスのまま仕訳を返すと、速くても、この説明ができません。

ここで効くのが、「何を AI に渡し、何を渡さなかったか」を自分で説明できる状態にしておくことです。渡したのは正規化した摘要だけで、口座番号や取引先の正式名は渡していない——そう言い切れる設計なら、守秘義務とも両立します。逆に「とりあえず全部投げた」だと、説明のしようがありません。

渡す前に、三つを分けておく

預かったデータを AI に渡す前に、最低限この三つを分けます。

一つ、テナントの分離。顧問先ごとに、データ・ルール・権限・AI 予算を分ける。A 社の作業が B 社に影響しない構造を、運用ルールではなく仕組みで持ちます。

二つ、渡す情報の最小化。AI に必要なのは、たいてい「仕訳ルールを書くための摘要や構造」であって、顧問先の実取引行そのものではありません。マスクした最小限で足りないか、まず疑います。

三つ、証跡。どの明細を、どの段階（マスター／ルール／AI）で、なぜそう確定したかが残れば、顧問先への説明にも、内部のレビューにもそのまま使えます。

ありがちな失敗と、その直し方

ある事務所では、顧問先ごとの freee トークンと口座明細を一つの作業フォルダにまとめ、AI にそのまま渡していました。月次は速くなったものの、ある顧問先から「うちのデータはどこまで外部に渡ったのか」と問われたとき、誰の何がどこまで渡ったかを、記録から再構成できませんでした。守秘義務を負う立場で、これは速さの価値を打ち消します。

私たちが社内で記帳の自動化を整えたときは、顧問先ごとに環境を分け、AI に渡すのはマスク済みの摘要だけにしました。実明細はサーバー側に置いたまま、AI には判定だけをさせ、どの明細をどう確定したかのログを残す。「混ざらない」と「説明できる」を仕組みで担保すると、担当者の注意力に頼らずに守秘を保てます。

仕組みで守ると、属人化も消える

これを手作業の規律で守り続けるのは、顧問先が増えるほど難しくなります。だから私たちは RuleHub で、顧問先（テナント）と事業所ごとにデータ・ルール・権限・AI 予算を完全に分離し、AI に渡すのは最小限の摘要だけ、トークンや明細はサーバー側の統制下に置いたままにしています。どの明細をどの段階で確定したかの証跡も残るので、顧問先への説明にもそのまま使えます。「顧客の資産を AI に渡さない」を、提案の強みにできる——記帳代行を、ただの作業から事務所の資産に変える設計です。

渡す前のチェック

• 顧問先ごとに、データ・トークン・ルール・予算を分離しているか
• AI に渡しているのは、マスク済みの摘要など最小限か（実明細を丸ごと渡していないか）
• 「誰の・どの情報が・どこまで渡ったか」を後から説明できる記録が残るか
• 一つの AI コンテキストに、複数顧問先の情報が同時に乗っていないか
• 顧問先に「あなたのデータはこう扱った」と言い切れる状態か

速さは、説明できてはじめて価値になります。預かったデータをどう渡すかを先に決めておけば、AI の速さは、守秘や説明責任と無理なく両立します。