AI に会計データを渡す前に——ZDR と MCP、二つの「データの行き先」を分けて考える

「AI に会計データを渡して大丈夫か」を考えるとき、ひとくくりに「AI は危ない／安全」と論じても答えは出ません。データがどこに残り、誰の管理下へ行くのか——行き先を分けて見ると、判断の軸がはっきりします。会計まわりでは、押さえるべき行き先が二つあります。一つは Anthropic 側にデータが残るかどうか（ZDR）、もう一つは MCP 経由で第三者にデータが渡るかどうかです。渡す情報そのものを最小化する基本はこちら、freee の MCP を繋ぐ権限設計はこちらにまとめました。

ZDR は「Anthropic に残さない」話

ZDR（ゼロデータ保持）は、商用組織や Enterprise 向けに用意されている仕組みで、API でやり取りしたデータを保持しないようにできます。前提として、Anthropic の商用 API に渡したデータは、同意なくモデルの学習に使われることはありません。そのうえで ZDR を使えば、保持もしない、という整理になります。ただし、適用される対象や契約形態は決まっているので、「自社の使い方がその範囲に入っているか」は、一度確認しておく価値があります。

でも ZDR は「Anthropic との間」しかカバーしない

ここが見落とされがちな点です。freee や マネーフォワード と連携する MCP サーバを噛ませると、データはその MCP サーバ——つまり提供元の第三者のサーバ——を経由します。これは Anthropic ではありません。ZDR が守るのは Anthropic との経路であって、第三者のサーバに渡ったデータは、その対象外です。便利な連携を足すたびに、この「Anthropic の外側の信頼境界」が一段ずつ増えていきます。MCP を使うなら、その提供元が、渡したデータをどう扱うのかを、別途確かめる必要があります。

渡るのは「Claude が読んだものだけ」

もう一つ、軸として持っておきたいのが、モデルに渡るのは「Claude がそのセッションで実際に読んだ内容だけ」だということです。ローカルのファイルが勝手に全部送られるわけではありません。裏を返せば、入り口——何を読ませるか——を絞れば、ZDR や MCP の議論をする前に、そもそも渡るデータの量が減ります。口座明細を丸ごと開かせるのか、マスクした摘要だけを見せるのか。この入口の設計が、いちばん効きます。

渡す前のチェックリスト

• 商用利用なら、ZDR の適用範囲に自社が入っているか確認したか
• MCP サーバを挟むなら、その提供元（=Anthropic 外の信頼境界）の扱いを確かめたか
• AI に読ませているのは、丸ごとの実データでなく、マスクした最小限か
• 機密（トークン等）を、AI のプロセスが触れる場所に置いていないか

結局は「入口を絞る」が効く

ZDR は Anthropic 側の保持を抑え、MCP の精査は第三者側の扱いを抑える。どちらも大事ですが、両方の手前にあるのが「そもそも渡す量を減らす」ことです。私たちが RuleHub で一貫してやっているのも、これです。AI に渡すのは記帳に必要な最小限の情報だけにして、トークン・口座・明細は統制下に置いたままにする。渡る量が小さければ、どの行き先を経由しても、リスクの絶対量が小さく済みます。

この「入口を絞る」を実際の記帳で徹底しているのが、田村直大公認会計士・税理士事務所です。AIに渡すのは正規化済みの摘要だけ、口座番号やトークンはサーバー側に残したまま、約500件の共通ルールで仕訳を判定する設計で、記帳の自動化率を段階的に最大95%まで引き上げています（導入インタビュー）。

「AI に会計データを渡して大丈夫か」への答えは、データの行き先を分けて、入口を絞ることで設計できます。怖いから使わない、でも全部投げる、でもない。渡すものを決めてから渡す——それが、いちばん現実的な落としどころです。