税理士事务所如何安全使用Claude Code：客户数据匿名化与权限设置

在日本的税理士事务所里，如果把客户的试算表或工资CSV交给Claude Code之前，只删除公司名称，之后通常还得返工确认。法定代表人姓名、电子邮箱、银行账号、交易对象名称以及个人编号（My Number），可能仍留在其他列或文件名里。别人仍有可能据此推测资料属于哪位客户。因此，最先要修改的不是提示词，而是原始数据文件夹与AI工作文件夹之间的边界。

例如，制作月度评语时，没有必要让Claude Code打开原始CSV。可以把公司名替换为“客户A”，把准确销售额改为“1000万日元至1500万日元”这样的区间，再生成工作用JSON。凭这些信息就能整理确认问题。税额、申报判断和实际发送仍由人负责。

本文将建立一套适合日本税理士事务所的流程：先将客户数据与原件隔离，只把匿名化后的工作副本交给Claude Code。我们不会把权限设置本身当成安全证明，而是叠加输入前检查和人工批准。主要后续行动是通过培训与咨询明确事务所内部的职责和审批步骤。

本文要点

原件放在 raw-client-data/，交给AI的副本放在 ai-work/，并设置为Claude Code无法读取原件。
匿名化不只是删除姓名，还要检查联系方式、银行账户、识别号码、交易对象、过于精确的金额和自由填写内容。
让Claude Code处理匿名化后的分类、差异表、确认问题和评语草稿。税务判断、发送、保存期限和例外批准由人决定。
三个Use case分别是月度评语、缺少资料提醒邮件和申报前检查清单。
ROI用每件准备时间、返工次数、输入前检查拦截次数和审批所需分钟数衡量。

工作流程：打开原件前先制作工作副本

把税理士事务所的工作目录分成四个区域：原件、转换处理、AI工作和已批准输出。会计CSV、工资台账、申报资料、客户邮件放入原件区域。AI工作区域只放为当前目的保留必要字段的JSON、Markdown或CSV。已批准输出另行保存，并记录负责人姓名和确认日期。

文件夹	存放内容	Claude Code的处理权限
`raw-client-data/`	从客户处收到的原件	拒绝读写
`transform/`	匿名化脚本和字段表	由人确认内容后执行
`ai-work/`	已使用假名并将数值区间化的工作副本	允许读写
`approved-output/`	人工批准的文案和检查表	由人保存和发送

第一步是用一句话写明把资料交给AI的目的。“撰写月度报告”范围太大。可以缩小为：“根据销售额区间、毛利率与上月之差、未回收款项件数，列出三个需要向公司负责人确认的问题。”目的越窄，需要交出的字段就越少。

下一步制作字段表。公司名称、姓名、住址、电话、邮箱、银行账户和个人编号都属于删除对象。交易对象名称、少见行业、准确销售额和自由填写内容，也要替换为假名或区间。同时记录由谁、在何时、按照哪套规则完成了转换。

日本个人信息保护委员会在关于云服务使用可能构成委托处理个人数据等情形的注意提醒中列出了注意事项。前提是事务所一方确认所用服务的安全管理措施、合同责任和对受托方的监督。包含个人编号的“特定个人信息”还必须另外查阅日本面向经营者的指南。本文的设置示例不能替代法律或合同审查。

交给Claude Code的范围与必须由人判断的范围

可以交给Claude Code的工作，到整理匿名化资料、发现缺项、提出确认问题和制作草稿为止。例如，根据“销售额区间比上月上升，但毛利率下降”“未回收件数增加2件”这些事实，让它生成负责人向客户确认的问题。这里不需要原始公司名称或准确银行余额。

税务结论、数值、询问客户时的措辞、收件人、保存期限、删除和例外处理必须由人判断。不能把AI的断言直接发送。税理士应确认依据资料和适用条件后再批准。

权限也要分成两层考虑。Claude Code的Read/Edit拒绝规则针对内置工具。官方权限设置文档说明，Bash的子进程不一定会以同样方式被阻止，因此还应同时使用操作系统级别的沙盒进行限制。权限规则的评估顺序是 deny、ask、allow。先拒绝原件，再只允许工作文件夹。

三个Use case

Use case 1：为月度评语制作确认问题

输入：客户ID、销售额区间、毛利率与上月之差、未回收件数、负责人添加的事实备注。
输出：三个需要向客户确认的问题、月度评语草稿、作为依据使用的输入字段。
人工确认：批准会计数值、税务评价、客户特有情况、发送文案和收件人。

即使不提供准确销售额和公司名称，也能建立评语结构。请指示Claude Code：“不要断言增减原因，不要补充输入中没有的原因，而要把不确定之处改写成确认问题。”负责人一边查看原件，一边决定问题的优先顺序。月度报告整体结构另见税理士事务所月度报告文章。

Use case 2：起草缺少资料提醒邮件

输入：客户A、对象月份、未提交资料的种类、期望回复日期、可选提交方式。
输出：邮件主题、正文、缺少资料的项目列表、回复时的注意事项。
人工确认：核对实际缺少的资料、期限、收件人、附件以及是否混入其他公司名称。

在缺少资料提醒邮件中，比文笔更危险的是收件人错误和客户名称残留。AI工作副本中不要放真实姓名，批准后再由邮件系统插入。客户邮件与确认清单介绍的是文案制作，而本流程应当先在它之前建立输入边界。

Use case 3：查找申报前检查清单的遗漏

输入：匿名化后的法人分类、对象手续、资料类别、已收取标记、确认人员的职责。
输出：尚未收取的资料、退回负责人确认的问题、含批准栏的检查清单草稿。
人工确认：判断申报义务、期限、必要文件、适用条件、电子申报和最终提交。

这里也不能让Claude Code决定是否可以申报。让它将检查清单项目与现有流程对照，并列出可能的遗漏。人要根据原件确认税种、事业年度、申报或备案状态以及特例条件。输出中要保留“确认人”“确认日期”“依据资料”三栏。

可直接复制的提示词

下面的提示词以只读取 ai-work/ 中已匿名化资料为前提。不要把真实姓名或准确识别号码追加到提示词中。

你负责协助税理士事务所进行月度确认。
只读取 ./ai-work/client-C017.json，并按以下顺序输出。

1. 输入中写明的事实
2. 仅凭输入无法判断的事项
3. 三个需要向客户确认的问题
4. 月度评语草稿
5. 人工必须根据原件确认的项目

限制：
- 不得断言税务判断
- 不得补充输入中没有的公司名、人名、金额或原因
- 不得发送邮件、删除文件或进行外部通信
- 如果发现疑似个人信息的值，停止处理，只报告字段名
- 在输出末尾写明“税理士确认前・禁止发送”

使用提示词之前，先用程序检查工作副本是否只包含预期字段。与本文配套的 scripts/check-tax-accountant-ai-input.mjs 会扫描JSON、CSV、Markdown和文本；一旦发现疑似姓名或联系方式的字段名、邮箱、电话、12位识别号码或邮政编码，就以退出码1停止。

node scripts/check-tax-accountant-ai-input.mjs
node scripts/check-tax-accountant-ai-input.mjs ./ai-work
if ($LASTEXITCODE -ne 0) { throw "AI输入前检查已停止处理" }

这项检查不能保证防止数据泄露。它无法判断自由填写内容的全部含义，也无法判断多个字段组合后产生的再识别风险。因此，检查完成后仍要由人打开并查看工作副本。

可运行的权限设置

在项目的 .claude/settings.json 中，先拒绝原件，再只允许AI工作文件夹。/raw-client-data/** 开头的 / 在Claude Code设置中以项目根目录为基准。从电脑文件系统根目录开始的绝对路径使用 //，不要混淆。

{
  "permissions": {
    "deny": [
      "Read(/raw-client-data/**)",
      "Edit(/raw-client-data/**)",
      "Read(/secrets/**)",
      "Edit(/secrets/**)",
      "Bash(git push *)"
    ],
    "allow": [
      "Read(/ai-work/**)",
      "Edit(/ai-work/**)",
      "Bash(node scripts/check-tax-accountant-ai-input.mjs *)"
    ]
  },
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "filesystem": {
      "denyRead": ["./raw-client-data", "./secrets"],
      "denyWrite": ["./raw-client-data", "./secrets"]
    }
  }
}

官方沙盒说明指出，沙盒无法启动时，默认行为是在警告后继续以非沙盒方式运行。这里用 failIfUnavailable: true 让程序停止，并用 allowUnsandboxedCommands: false 禁用绕过路径。沙盒支持以macOS、Linux或WSL2为前提。使用Windows的事务所应当在WSL2中运行；如果某台终端上的设置无效，就不要在该终端处理客户数据。

设置后还要测试“确实会被拒绝”。只在放有虚构数据的验证文件夹中，确认读取 raw-client-data/ 会被拒绝，而只有 ai-work/ 中的工作副本可读。不能因为设置文件存在就判定测试合格。Claude Code权限设置指南还说明了deny规则的设计方法。

Pitfall：匿名化和权限设置失效的场景

第一个陷阱，是认为只删除公司名称就完成了匿名化。原因在于法定代表人姓名、少见交易、准确金额和自由填写内容可能仍然暴露客户。修正方法是针对每个目的确定允许字段，只把转换后的文件输出到 ai-work/。

第二个陷阱，是以为拒绝Read后Bash也会停止。内置Read/Edit规则与对子进程的限制是两套控制。应叠加沙盒的 denyRead 与 denyWrite；沙盒无法启动时，用 failIfUnavailable 停止处理。

第三个陷阱，是扫描结果为0就断定安全。正则表达式会漏掉图片、PDF内文字、写法差异，以及只有结合语义才能识别的个人信息。修正方法是同时采用字段允许清单、输入前检查、人工目视、处理日志和删除期限。

第四个陷阱，是使用真实数据测试。测试日志和截图里可能留下值。请用虚构数据测试拒绝与允许，并把发生事故时的停止步骤写在一张纸上。

从小范围衡量ROI

最初两周，只选一家客户的一种月度评语进行测量。导入前记录5次“从确认原件到草稿完成的分钟数”“负责人修改次数”“所长退回次数”。导入后继续记录相同项目，并增加输入前检查拦截的次数。

例如，每月处理20件，每件准备时间从18分钟降到11分钟，则每月缩短140分钟。不过，如果审批时间增加，必须扣除增加的部分。除了换算成销售额，还要记录事前阻止的误发送、混入其他公司名称和访问原件的件数。只追求速度，会形成省略匿名化的压力。

导入前后比较 件数 x（准备分钟 + 审批分钟 + 返工分钟），并把拦截件数放在旁边，从而同时观察速度和安全性。

常见问题

Q. 把客户名称改成假名后，就能直接使用吗？

不能。还要查看法定代表人姓名、住址、邮箱、银行账户、个人编号、交易对象、准确金额和自由填写内容。最后由人确认多个值组合后是否仍能推测出客户。

Q. 在本地运行就安全吗？

不能只凭运行地点判断。要确认服务的数据处理、认证、终端、日志、外部通信、权限和合同。先建立一个无法访问原件的边界。

Q. 检查脚本能查看PDF和图片吗？

本文脚本只处理JSON、CSV、Markdown和文本。PDF和图片应作为不支持的格式被拦截，并通过另行批准的转换流程。不要默默放行不支持的格式。

Q. 可以把个人编号匿名化后交给AI吗？

本文不作个案判断。原则上不要把个人编号放入工作副本。事务所负责人必须确认日本个人信息保护委员会的指南、合同、利用目的和内部规定。

通过培训与咨询确定边界

税理士事务所使用Claude Code时，只制作设置文件还不够。如果谁负责匿名化、谁批准例外、输出保存到哪里都不明确，流程会在实际运用中失效。原件、工作副本、AI输出和已批准文案需要分别指定负责人。

培训与咨询会在不带入真实数据的情况下，设计客户数据字段表、文件夹边界、权限设置、输入前检查和批准表。第一次沟通只确认现有文件夹名称和希望制作的成果物，不共享原件本身。

实际测试结果

本文只使用虚构客户JSON，运行了 scripts/check-tax-accountant-ai-input.mjs 的自测。安全侧样本设计为检出0件；包含法定代表人姓名字段、邮箱和12位识别号码的危险侧样本设计为停止处理。代码、命令、内部链接、官方URL、CTA、frontmatter和题图也列入了发布前检查。

今天的第一项工作，是建立空的 raw-client-data/ 和 ai-work/，使用虚构文件测试“原件区域会被拒绝，只有工作副本区域可读”。测试合格后，也仍然从匿名化后的工作副本开始。