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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

税理士事務所がAIに顧問先データを渡す前の3ステップ分離設計

「AIが便利なのはわかるが、顧問先Aのデータが顧問先Bに混線する事故を起こしたくない」——税理士事務所が最初に突き当たる壁です。この章では、AIに顧問先データを安全に渡すための具体的な設計手順を整理します。

ステップ1：データ分離の3層を明確化する

顧問先データの混線は、「どの層で分離するか」が曖昧なまま運用を始めたときに起きます。以下の3層を明確に定義します。

ステップ2：freee・マネーフォワードの「事業所」単位でトークンを分離する

freeeでは1ユーザーが複数の「事業所」（顧問先）にアクセスできます。この仕組みを使って作業するとき、最も多い事故のパターンは「スコープを絞らずにAPIトークンを使い回す」ことです。

安全な設計：

• 顧問先ごとに専用の連携アカウント（freee事業所メンバー）を作成し、そのアカウントのトークンのみ使用
• スコープは最小権限（仕訳読み取りのみ必要なら journal:read のみ付与）
• トークンは事業所ごとにシークレットストアで別管理（AWS Secrets Manager等）
• AIへの受け渡しは「当該顧問先分のみ取得して渡す」1アクション単位で完結させる

マネーフォワード クラウドも同様に、顧問先法人ごとにAPIアクセス権限を設定できます（ただし事務所向けMFクラウドの仕様はMFクラウドの公式ドキュメントを確認してください）。

ステップ3：AI（Claude/ChatGPT等）への渡し方ルール

大規模言語モデルは「コンテキスト内にある情報」を参照します。顧問先Aの会話の後に顧問先Bの質問をすると、残っているAのデータをBに使ってしまうリスクがあります。

実務ルール：

1. 顧問先が変わるたびに新しいチャットセッションを開始する：Claude.ai・ChatGPTとも、前の会話の文脈を引き継がないよう新規チャットで開始
2. 「この会話では顧問先〇〇社のデータのみを扱う」とシステムプロンプトに明記する：Claude APIやClaude Codeを使う場合、プロンプトに事業所IDや顧問先名を冒頭で指定
3. バッチ処理では顧問先単位でループを分ける：複数顧問先を一括処理するコードでは、顧問先ごとにAPI取得→AI処理→結果保存をセットで完結させ、顧問先をまたいでデータをメモリに保持しない

説明責任を果たすための記録：AIが何を見てどう判断したかを残す

「速くなった」だけでは、顧問先からのクレーム対応や税務調査で説明責任を果たせません。AIが自動化した処理には、以下の記録を残すことを事務所ポリシーとして明文化します。

• 入力データの記録：AIに渡した仕訳データ・請求書の期間・件数
• AI判断の記録：AIが提案した勘定科目・摘要の根拠（ログファイル等に保存）
• 人間の確認記録：担当者がAI提案を承認/修正した日時とその内容

これはクライアントへの説明責任だけでなく、AI判断の品質を継続的に改善するための材料にもなります。AurantのRuleHubでは、このような「AI判断ログの管理と事務所ポリシー設定」をMCPプロトコル経由でfreee/MFと統合する仕組みを提供しています。

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

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

実際にこの形で記帳代行を回しているのが、田村直大公認会計士・税理士事務所です。AIに渡すのは正規化済みの摘要だけ、口座番号や実明細はサーバー側に置いたまま、約500件の共通ルールで仕訳を判定する——顧問先のデータを預かる立場のまま、記帳の自動化率を段階的に最大95%へ、月次決算を5営業日から0.5営業日へと縮めています（導入インタビュー）。

渡す前のチェック

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

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