让 GitHub Copilot 完成全部报税工作 ― 从837条记账分录到申报提交

将报税的所有实际工作全部交给 GitHub Copilot 的 Agent Mode 处理，结果从837条分录的分类到申报表的制作和验证都在 VS Code 内完成。最后只需通过手机应用使用个人编号卡认证提交，即完成了报税。

本文将如实记录“哪些工作交给了 Copilot”以及“人类做了什么”。

前提：MF 云的数据对接是基础

首先要明确的是，这次成功的最大原因是平时就设置好了 Money Forward 云的数据对接。

不是到了报税季才慌忙收集明细，而是全年自动对接以下服务，记账数据自然而然地积累起来：

• 事业用银行账户 — 营收入账、转账手续费
• 个人银行账户 — 房贷、J-Coin Pay、生活费分类
• 网络银行 — 社会保险费的账户划扣记录
• 事业用信用卡 — 通信费、广告宣传费、差旅费、图书费
• 移动 Suica — 电车、公交的交通费（采用预付金方式防止重复记账）
• 电商网站 — 消耗品费的购买记录
• My Number Portal — 养老金和人寿保险费的扣除证明

得益于这些对接，到决算时点已有 837条分录 积累在云端。Copilot 的工作就是将这些原始数据正确分类并制作成申报表。

使用的环境

编辑器·AI

• VS Code — 编辑器兼浏览器兼终端兼聊天。一切都在这里完成
• GitHub Copilot Agent Mode（Claude Opus 4.6） — 本次的主力模型。自主地组合文件编辑（Markdown 读写）、终端命令执行以及通过 Simple Browser 的 Web 操作
• Simple Browser（VS Code 内置浏览器） — Copilot 通过 MCP（Model Context Protocol）工具读取 DOM，使用 click_element 点击按钮和链接，使用 type_in_page 输入表单，使用 read_page 获取整页文本。相当于 Copilot 的“眼睛和手”

Web 服务

• Money Forward 云报税 — 记账簿、决算报表、申报表的管理
• Money Forward 云 Box — 收据和凭证的文档管理
• Money Forward ME — 个人资产管理（跨多个账户查看收支）

为什么选择 GitHub Copilot 而非 Computer Use

如果要让 AI 操作屏幕，Anthropic 的 Computer Use 等基于截图的工具也是选项。但这次报税所需要的不仅仅是“操作屏幕”，而是在读写文件的同时做出判断，并将记录与人类共享。

选择 GitHub Copilot Agent Mode 的原因：

• 人类登录、AI 操作的分工成为可能 — 银行和会计软件由人类登录并打开页面。之后的操作（搜索、输入、确认）由 Copilot 通过 Simple Browser 执行。Computer Use 的设计是将整个桌面交给 AI，无法实现“只有登录由人类完成，其余交给 AI”这样在同一屏幕上的分工
• 文件编辑和浏览器操作在同一环境中完成 — 读取方针.md 判断分录正误，将结果写入不一致检查.md，然后直接在 Simple Browser 中修正账簿。这一系列流程在 VS Code 内不会中断
• Markdown 文件成为人类和 AI 的共享工作空间 — Computer Use 基于截图，不适合积累和参考结构化知识。Copilot 可以通过 .md 文件双向交流“基于什么做出了什么判断”
• 对话日志直接成为工作记录 — “这个扣除要加上吗？”“没有原始凭证就算了”这样的对话全部留在聊天记录中。能够追溯判断经过，对于报税尤为重要

总之，仅靠屏幕操作其他工具也能做到，但人类和 AI 共享同一屏幕和文件并进行分工是 Copilot Agent Mode 的优势。

工作流程的核心：Markdown 文件群

在与 Copilot 的协作中，最重要的是通过 Markdown 文件将知识和任务结构化。本次使用的文件构成：

文件	作用
方针.md	摘要模式 → 会计科目的映射规则（共16个章节）。Copilot 分类分录时的判断标准
タスク.md	报税整体的进度管理中心。以表格✅管理38份凭证的获取状态
申請タスク.md	申报表输入阶段的未解决课题和调查笔记。将事实和推论分开记录
申請タスク_完了・保留.md	将已完成/暂缓的项目转移出来，防止工作文件膨胀
不整合チェック.md	方针 vs 记账簿的核对结果报告。通过§编号引用方针.md 的修改位置
MFレビューレポート.md	BS/PL 的数值审核。通过问题 ID（A1、B1等）和严重程度进行体系化管理
仕訳帳対応表.md	将 MF 记账簿的全部837条按类别以表格整理的台账

Copilot 读取这些 .md 文件来判断，写入记录。人类也阅读完全相同的文件来掌握情况。也就是说，Markdown 文件作为人类和 AI 的共享工作空间在发挥作用。

基本用法是同时打开5~6个 Simple Browser 标签页，一边与 Copilot 商量一边推进。

Phase 1：与 Copilot 一起制定分录方针

分录方针的制定

首先做的是将分录分类规则文档化到 方针.md 中。一边与 Copilot 商量“这笔交易归哪个科目？”“这是事业用还是个人用？”，一边按交易模式整理会计科目。

这份方针文档的结构很重要。每个章节采用 ### 摘要模式 → 会计科目 的格式，在 Markdown 表格中定义摘要、内容和科目。对于判断困难的情况，用 > 注: 块引用附上依据。由于 MF 云的摘要栏使用半角片假名记录（例如：ﾃｽｳﾘｮｳ），方针文档中也照原样转录，方便搜索时复制粘贴。

制定的分类规则共有15个章节：

类别	科目	具体示例
客户入账	营收	每月转账入金
房贷扣款	事业主贷	个人账户自动扣款
QR码支付充值	事业主贷/借	个人账户充值·退还
账户间转账	普通预金	事业账户 ↔ 个人账户
ISP·SaaS	通信费	GitHub、Cloudflare、ChatGPT、Canva 等
网络广告·SNS运营	广告宣传费	Google Ads、X Premium、SocialDog 等
交通费	差旅费	新干线、出租车、远程工作空间
Suica 使用	差旅费	采用预付金方式记录电车·公交的明细
电商购物	消耗品费	电脑外设、工具

Phase 2：837条分录的分类与不一致检查

Copilot 全量核对

方针文档完成后，就顺理成章地进入了与记账簿实际数据的核对。

具体做法：Copilot 在 Simple Browser 中打开 MF 云的记账簿画面，使用 read_page 获取页面内容。通过摘要关键词筛选，与方针.md 的表格进行核对。发现不一致时，在 不一致检查.md 中添加表格行，同时直接编辑方针.md 的对应章节（如 §13）。由于在 不一致检查.md 开头声明了“以记账簿为准，修正方针.md”的规则，Copilot 会毫不犹豫地修改方针侧。

结果，检出了8处不一致：

摘要	方针上的科目	实际分录	处理
SNS Premium	事业主贷（个人使用）	广告宣传费	事业用 SNS，广告宣传费正确
设计工具	事业主贷（个人使用）	通信费	事业用工具，通信费正确
AI 聊天服务	事业主贷（个人使用）	通信费	事业用工具，通信费正确
移动电源租赁	通信费	事业主贷	个人使用，事业主贷正确
应用内购（多个应用混合）	统一归为通信费	按应用拆分	换乘查询→通信费，广告屏蔽→事业主贷等
视频广告（阈值计费）	放置在个人使用章节	广告宣传费	修正方针文档的位置错误
电商购物（电脑外设）	图书费	消耗品费	修正科目错误
SNS 管理工具	通信费	广告宣传费	SNS运营目的，广告宣传费正确

“制定方针文档，与账簿核对，发现差异则修正方针”——这一工作由 Copilot 在编辑文件的同时自动推进，与目视对照837条相比效率完全不在同一层次。

分录的全貌

最终整理的分录大致如下：

• 银行对接（事业用账户·个人账户·网络银行共4行）— 营收入金、房贷、账户间转账
• 信用卡对接（三井住友卡 本人名义 + Apple Pay 分离部分）— 通信费116条、广告宣传费21条、差旅费24条、图书费27条、个人使用29条等
• 移动 Suica 对接 — 电车248条、公交130条、充值21条、商品购买4条
• 电商对接 — 消耗品费5条
• AI-OCR·发票 — 16条

Phase 3：云端 Box 的凭证整理

上传与自动识别

然后将收据和信用卡明细通过 Copilot 上传到云会计的 Box 功能。AI-OCR 自动识别交易日期、交易方和金额，不足部分由 Copilot 手动补充。

单据凭证（逐张收据）已补充完交易日期、交易方和金额。明细类文档（信用卡使用明细、Suica 使用记录、银行交易明细等）采用仅上传作为参考资料保留的方针。

Phase 4：社会保险费的核对 ― 跨多服务操作的精华

从“社保金额怎么确定？“的商量开始，与 Copilot 讨论后确定了同时打开5个 Web 服务进行核对的方针。

国民年金保险费

仅靠 My Number Portal 对接的自动导入数据可能不够充分。例如，配偶的年金从另一个账户缴纳的情况下，不会出现在对接数据中。

在这种情况下，与 Copilot 商量后推进的流程：

1. “看看信用卡明细中有没有年金缴费”→ 在 Simple Browser 中打开并搜索“日本年金机构”，提取缴费金额
2. “可能还从其他账户缴费”→ 在家计簿应用中确认其他账户的出金记录，发现未对接的扣款
3. “看看前后月份”→ 掌握缴费模式（季度缴费·月缴等）
4. “那就核对一下算出总额吧”→ 核对多个数据源的金额，确定全年缴费总额

关键在于一个服务无法完结。与 Copilot 一边交流“接下来看哪里？”“那边也确认一下吧”一边在多个标签间切换进行交叉验证，这是本阶段的基本模式。

健康保险费

在 Simple Browser 中打开网络银行标签页，搜索账户划扣记录中的保险费扣款。根据参加的制度（协会健保·国民健康保险等）更换关键词搜索，确认全年的缴费次数和金额。

地方政府缴费（陷阱）

即使家计簿应用中有地方政府的缴费记录，仅凭记录可能无法区分是“国民健康保险”“住民税”还是“固定资产税”。

与 Copilot 一起调查“这笔是什么缴费”的流程：

1. “查一下地方政府的缴费时间表吧”→ 在广报或网站上确认各税种的普通征收缴费期
2. “看看缴费月份是否对得上”→ 核对后缩小税种候选范围
3. “同一时期有没有缴过其他保险？”→ 验证是否存在制度重叠

如果仍然没有缴费单原件无法确定税种，不计入扣除（偏向保守） 是较为稳妥的做法。这个“计入还是不计入”的判断由人类做出，调查材料的准备由 Copilot 负责——这种角色分工非常重要。

误分类的发现

家计簿应用的自动分类并非万能。实际上，某笔支出被自动分类为“年金保险费”，但让 Copilot 通过信用卡明细交叉验证后，发现实际上是完全不同的公共事业费。如果照单全收，就会高估社会保险费。

务必要做的事：不要信任家计簿应用的分类，而是与 Copilot 一起通过信用卡明细进行交叉验证。跨服务的核对正是 Copilot × Simple Browser 的真正价值所在。

Phase 5：各项扣除的输入

接下来，社会保险费以外的扣除也与 Copilot 一起通过 Simple Browser 输入到表单中。

已输入的扣除

扣除类型	概要	Copilot 的工作
人寿保险费扣除	My Number Portal 对接部分 + 手动输入部分	操作表单的下拉框逐一输入
地震保险费扣除	共济·损保的地震保险费	将金额输入表单
配偶扣除	根据配偶收入计算总所得金额	计算应用工资所得扣除后的所得金额，确认扣除额
社会保险费扣除	养老金 + 健康保险（Phase 4 中确定的金额）	在申报表的社保画面选择种类→输入金额
抚养扣除（16岁以下）	不影响扣除额但与住民税相关	在基本信息 → 家族或亲属画面确认登记状态

经讨论后搁置的项目

与 Copilot 讨论“这个也能计入扣除吗？“后，判断”这次先搁置“的项目：

• 住房贷款扣除 — 手头没有年末贷款余额证明，因此搁置
• 医疗费扣除 — 确认了 My Number Portal 对接数据，但金额对扣除影响不大，判断优先级低
• 电费按比例分摊 — 虽然自家服务器用于事业，但分摊依据的整理未来得及，搁置
• 故乡纳税·iDeCo — 当年无相关项目

Phase 6：ISP 费用的事业比例分摊

ISP（互联网线路）的月费全额作为通信费记入了记账簿，但由于是居家办公，100%事业使用无法通过审查。

问 Copilot“这个怎么分摊？“后，给出了几个选项，经过商量确定了以下方法：

1. 从记账簿搜索所有 ISP 相关条目 → 计算年度总额
2. 确定事业使用的分摊比例（居家办公一般以50%为参考）
3. 不逐条修改个别分录，而是通过12/31日期的一次性调整分录添加一条“事业主贷 / 通信费”
4. Copilot 将分录录入账簿

“是逐条明细改为50%，还是在年末一次性调整”这样的实务选择也由 Copilot 提出，这也是与 Copilot 对话的优势。

Phase 7：申报表的输入与验证

Simple Browser 中的表单操作

在 Simple Browser 中打开云会计软件的申报表画面，一边与 Copilot 对话一边推进表单输入。

Copilot 实际执行的操作：

1. 通过 read_page 获取当前页面结构，判断应该点击哪个菜单
2. 通过 click_element 点击侧边菜单或“社会保险”等链接进行页面跳转
3. 下拉框通过 click_element 打开后，再次 click_element 选择选项
4. 通过 type_in_page 在输入框中填入金额。直接转录 申请任务.md 中记录的金额
5. 通过 click_element 点击“保存”按钮提交表单

人类的对话只是“开始输入社保部分吧”“先从国民年金开始”“还有一条”“合计对不对，看看第一表”之类。不需要指定具体的选择器或操作步骤，Copilot 会读取 DOM 自主判断。

这不仅比自己手动操作浏览器更轻松，这些对话交流本身会留在聊天日志中才是一大优势。之后可以追溯确认按什么顺序输入了什么。

第一表与第二表的交叉核验

输入完成后，让 Copilot 检查整合性：

• 第一表 — 所得金额、所得扣除合计、课税所得金额、税额
• 第二表 — 社会保险费扣除明细、人寿保险费扣除、配偶扣除、抚养信息

让 Copilot 读取两个标签页的内容，确认“第二表的明细合计与第一表的扣除额是否一致”。如有不一致会当场指出，对于及早发现输入错误非常有效。

需要注意的是，Money Forward 中住民税·事业税的画面没有16岁以下抚养的输入栏。抚养信息在“基本信息 → 家族或亲属”画面中管理，需要确认该处的登记状态。

Phase 8：申报提交

最终提交通过 Money Forward 云报税的手机应用进行。通过个人编号卡的 NFC 读取进行身份认证，直接提交申报数据。无需另外打开 e-Tax，从 MF 云直接完成提交。

提交后的确认要点：

• 受理日期是否已记录
• 受理编号是否已发放
• 是否显示“已受理提交的数据”的消息

让 Copilot 读取提交完成画面来确认这些内容。

机密信息的处理

银行和会计软件的画面中自然会显示个人信息。需要认识到 Copilot 的聊天记录中会包含这些内容。GitHub Copilot for Business 的策略是不使用代码补全数据进行学习训练，但请与您组织的安全策略进行对照判断。

人类做了什么

回顾起来，人类做的事情少得令人惊讶：

1. 方针决策 — “这个计入经费/不计入”“分摊比例定为50%”“没有原始凭证就不计入扣除”
2. 与 Copilot 商量 — “接下来做那个吧”“那边也确认一下？”“怎么办？”
3. 最终审批 — “这个数字 OK”“可以提交了”
4. 物理操作 — 个人编号卡的 NFC 读取（仅在手机提交时）

几乎不需要打开特定画面或指示具体的操作步骤。只要指出“接下来做这个吧”的方向，Copilot 就会自主推进画面跳转、搜索、输入和验证。

使这一切成为可能的是 Markdown 文件的存在。因为方针.md 中有分类规则，Copilot 才能判断分录的正确性；因为申请任务.md 中有调查笔记，才能追溯金额的来源。人类只需说“接下来做这个”就能运转，是因为判断标准和工作记录作为 .md 文件被共享着。

回顾：下次这样做

基于这次的经验，可以改善的要点：

• 将扣除证明也上传到云端 Box 会更方便 — 这次只有纸质保管，虽然 Copilot 从收支记录中确定了金额所以没有问题，但如果有电子数据，Copilot 可以直接读取会更顺畅
• 对地方政府的缴费要留下税种备注 — 没有原始凭证就无法区分国保、住民税和固定资产税
• 保持提供给 Copilot 的方针文档最新 — 方针文档越准确，Copilot 的工作精度就越高
• 进一步整理 .md 文件的结构 — 这次是一边工作一边增加文件的，如果一开始就确定文件的职责分工和格式，Copilot 的读取精度和人类的状况把握都会更好

总结

在这次报税中深刻体会到的是，“数据积累”与“AI 代行实际工作”的组合非常强大。

通过 Money Forward 的数据对接，全年自动积累银行、信用卡、Suica 的交易数据。到了报税季，与 GitHub Copilot Agent Mode 一边对话“接下来做这个吧”“那边也确认一下？“一边共同推进。人类只需做方针决策和最终审批，但这个过程不是甩手不管，而是持续的对话。

编写代码并非 Copilot 的唯一用途。“跨多个 Web 服务，收集数据，整理，输入，验证”——这种日常办公工作都可以通过聊天对话一起完成。Agent Mode × Simple Browser 在编程以外的场景也完全适用。