会計事務所・税理士事務所の記帳代行と仕訳業務は、証憑の手入力と勘定科目の判断に時間が吸われ、繁忙期の残業の主因になりやすい領域だ。本記事は、所長1名規模の小規模事務所から記帳代行特化のBPOまでを想定し、Claude Code を「証憑OCR → 仕訳推論 → 月次試算表チェック → クライアント報告 → freee / マネーフォワード API 連携」の5手順で組み立てる実装パターンを、MCP・スキル・カスタムコマンドの技術詳細とプロンプトつきで解説する。なお本記事の事例・数値はすべて想定シナリオ（モデルケース）であり、実在の事務所の実測値ではない。
結論：Claude Code は会計事務所の記帳・仕訳の「下処理」を担う実装基盤として機能する。最終的な税務判断は税理士が担う前提を崩さなければ、証憑の構造化から仕訳ドラフト、試算表の異常検知までを自動化できる。
- 要点1：証憑OCRと仕訳推論は「ドラフト生成」までを Claude Code に任せ、確定処理は人間が承認する2段階に分ける（想定設計）。
- 要点2：freee / マネーフォワードへの書き込みは MCP サーバー経由でラップし、API スコープを read 中心に絞る。
- 要点3：マイナンバー・口座番号など要配慮情報はプロンプトに載せない前処理（マスキング）を必ず挟む。
対象読者：会計事務所・税理士法人の所長、記帳代行担当スタッフ、事務所の業務システムを内製したい補助者・エンジニア。
今日やること：まず1社分の証憑フォルダをサンプルに、Claude Code で「OCR → CSV 構造化」だけを動かして精度を体感する。
会計事務所の業務全体マップと、どこにClaude Codeが効くのか
会計事務所のスタッフをやったことがある人なら分かると思うが、記帳代行の現場は「華やかな税務コンサル」とはほど遠い。届いた領収書の山を眺めて、勘定科目を当てて、会計ソフトに打ち込む。この単純作業が、想像以上に時間を食う。
事務所の業務を俯瞰すると、おおむね5つのレイヤーに分かれる。
| 業務レイヤー | 主な作業 | 属人性 | Claude Code適性 |
|---|---|---|---|
| 記帳代行 | 証憑の入力・仕訳起票 | 低〜中 | ◎（下処理を自動化） |
| 月次決算 | 試算表作成・残高確認・増減分析 | 中 | ○（異常検知・コメント生成） |
| 年次決算 | 決算整理仕訳・財務諸表作成 | 高 | △（補助のみ・税理士判断必須） |
| 税務申告 | 申告書作成・電子申告 | 高（独占業務） | ×（税理士の独占業務） |
| コンサル | 資金繰り・経営助言 | 高 | △（資料下準備のみ） |
ここで重要なのは、税務代理・税務書類の作成・税務相談は税理士法第2条が定める税理士の独占業務であり、AIがどれだけ賢くなっても、その判断主体を税理士から奪うことはできないという点だ（日本税理士会連合会・参照日 2026-05-26）。だからClaude Codeの導入は「申告を自動化する」話ではなく、記帳代行と月次決算の下処理レイヤーを徹底的に薄くして、税理士の判断時間を確保する話になる。ここを取り違えると、後述する失敗パターンにまっすぐ突っ込む。
もう少し踏み込むと、Claude Code が他の「会計ソフト内蔵AI」と決定的に違うのは、ファイルシステムとコマンドを横断して動くエージェントだという点にある。freee やマネーフォワードのAI仕訳は、そのソフトのデータベースの中で閉じている。一方Claude Code は、ローカルに置いた証憑画像・前月のCSV・事務所独自のルール文書・複数社の試算表を「同じ作業空間」で扱える。つまり「先月のこのクライアントの仕訳パターンを参照して、今月の似た取引に同じ科目を当てる」「3社分の試算表を一括で異常チェックする」といった、ソフトの枠を越えた横断作業を一つの指示で回せる。これが、定型化しきれない記帳代行の“すきま作業”に効く理由だ。
導入前の状況｜証憑の手入力・仕訳の属人化・繁忙期の残業
記帳代行を回している事務所のボトルネックは、だいたい次の3つに集約される。これは想定シナリオだが、現場感覚としては多くの事務所に当てはまるはずだ。
- 証憑の手入力：クライアントから届く領収書・請求書の山を、日付・金額・取引先・摘要に分解して会計ソフトに打ち込む。1社あたり月数百枚という単位になることもある。
- 仕訳判断の属人化：「この支払いは消耗品費か事務用品費か」「交際費か会議費か」といった勘定科目の振り分けが、ベテランの頭の中にしかない。新人が入ると教育コストが跳ね上がる。
- 繁忙期の残業：確定申告期（2〜3月）や3月決算法人の申告期（5月）に作業が集中し、残業が常態化する。
多くの事務所は freee やマネーフォワードのAI仕訳機能、あるいはOCRサービスを既に使っている。ただ、それらは「ソフトの中で完結する仕訳推論」であって、「事務所独自のルールを横断的に当てる」「複数クライアントの試算表を一括でチェックする」「報告コメントを下書きする」といった、ソフトの枠をまたぐ作業は手作業のまま残る。この「枠をまたぐ部分」こそ、Claude Code のエージェント的な動き方が刺さるところだ。
Claude Codeの役割｜記帳・仕訳の実装5手順
ここからが本題。Claude Code を会計事務所の業務に組み込む実装を、5つの手順に分けて解説する。動作環境は Claude Code v2 系（2026年5月時点）+ macOS / Linux を想定し、ローカルの作業ディレクトリ内で完結させる前提で書く。
- 証憑OCR → 構造化 — 領収書・請求書の画像/PDFを読み取り、構造化データ（CSV/JSON）に変換
- 仕訳推論 — 構造化データから勘定科目を提案し、仕訳ドラフトを起票
- 月次試算表の異常検知 — 前月比・前年同月比で異常な増減を検出してフラグ立て
- クライアント向け月次報告コメント生成 — 試算表の数字を平易な日本語のコメントに変換
- freee / マネーフォワード API 連携 — MCP サーバー経由で会計ソフトに読み書き
手順1：証憑OCR → 構造化
最初の壁は、紙やPDFの証憑をどう構造化データにするか。Claude Code はファイルを直接読めるので、画像/PDFを作業ディレクトリに置いて読み取らせる。ここで意識すべきは「OCRの精度を上げる」より「出力フォーマットを固定して後工程で機械処理できる形にする」こと。
事務所のローカルに CLAUDE.md を置き、証憑処理の前提ルールを書いておくと、毎回プロンプトに書かずに済む。
# CLAUDE.md（証憑処理ルール）
## 出力フォーマット
証憑から以下のフィールドを抽出し、必ずCSV（ヘッダ付き）で出力する。
- date（YYYY-MM-DD形式）
- vendor（取引先名）
- amount（税込金額・数値のみ・カンマなし）
- tax_rate（10 または 8）
- invoice_no（適格請求書登録番号があれば。なければ空欄）
- description（摘要・原文ママ）
## 守ること
- 金額が読み取れない場合は amount を "UNREADABLE" とし、推測で埋めない。
- 仮定した点は必ず「仮定」と明記する。
- 不足している情報があれば、最初に質問してから作業を開始する。その上で、実際に走らせるプロンプトはこうなる。
【プロンプト①：証憑OCR → CSV構造化】
receipts/ フォルダ内の画像・PDFをすべて読み取り、CLAUDE.md の
出力フォーマットに従って一括でCSVに変換してください。
- 1ファイル = 1行とし、ファイル名を file_name 列に追加してください。
- 適格請求書の登録番号（T+13桁）が記載されていれば invoice_no に
「T」を含めて転記してください。判読できない桁は「?」で埋めてください。
- 読み取れなかったファイルは末尾に「要確認リスト」として
ファイル名だけ列挙してください。
- 数字と固有名詞は、読み取り元が不鮮明な場合その旨を添えてください。ポイント：「読めなかったものを推測で埋めない」を明示するのが効く。AIは空欄を嫌って“それっぽい数字”を作りがちなので、UNREADABLE と要確認リストで人間に投げ返す導線を作っておく。効果（想定）：1社月300枚の証憑入力が、確認・修正中心の作業に置き換わり、入力工数の体感負担が大きく下がる、という設計を狙う。
手順2：仕訳推論（勘定科目の自動提案）
構造化済みのCSVができたら、次は勘定科目を当てる。ここが仕訳業務のコアであり、最も属人化している部分だ。Claude Code に「事務所の仕訳ルール」を与えれば、ベテランの頭の中を文書化したものを当てさせられる。
事務所独自のルールは、Claude Code のスキル（再利用可能な手順書）として切り出すと管理が楽になる。.claude/skills/journal-rules/SKILL.md のような形で置いておく。
# .claude/skills/journal-rules/SKILL.md
## 勘定科目マッピング（事務所標準）
- スターバックス/ドトール等のカフェ → 単独なら「会議費」、
接待を伴う記載があれば「交際費」（要・人数確認）
- Amazon → 商品内容で「消耗品費」「事務用品費」「図書研究費」を判断
- ガソリン/ETC → 「旅費交通費」
- クラウドサービス月額 → 「支払手数料」または「通信費」（事務所ごとに統一）
## 判断に迷ったら
- 勘定科目が一意に決まらない場合は「候補」を複数提示し、
confidence（高/中/低）を付ける。
- 交際費/会議費の判定は税務リスクが高いため、低confidenceで人間に回す。【プロンプト②：仕訳ドラフトの起票】
structured.csv の各行について、journal-rules スキルに従って
借方勘定科目を提案し、仕訳ドラフトを作ってください。
出力は journal_draft.csv とし、以下の列を持たせてください。
- date / debit_account（借方科目）/ credit_account（貸方・デフォルト「未払金」）
- amount / tax_category（課税仕入10% / 軽減8% / 対象外）
- confidence（高/中/低）/ reason（科目選定の根拠を1行）
confidence が「中」「低」の行は、別途 review_needed.csv に
切り出してください。これは税理士の確認対象です。
最終的な税務判断はこのドラフトでは行いません。この「confidence で振り分けて、低いものは人間に回す」設計が肝になる。AIに全件任せるのではなく、機械が自信を持って当てられる8割を高速処理し、グレーな2割に人間の時間を集中させる。これが現実的な落としどころだ。効果（想定）：定型的な仕訳がドラフト化されることで、スタッフは「ゼロから起票」ではなく「ドラフトの承認・修正」に作業がシフトする。
confidence の運用で一つ補足しておきたい。最初のうちは「高」判定でも全件チェックすることを勧める。事務所のルールとClaude Code の解釈がどこでズレるかを観測する期間が必要だからだ。1〜2ヶ月運用して「高confidenceの誤りはほぼ出ない」と確認できてから、高判定のスポットチェック比率を下げていく。逆に、交際費と会議費の境界、福利厚生費と給与の境界、修繕費と資本的支出の境界といった税務リスクの高い論点は、精度が安定しても恒久的に低confidence扱いにしておくのが安全だ。AIの自信度と税務リスクの大きさは別物なので、ルール側で「この科目に触れたら必ず人間レビュー」と固定するのが効く。
また、勘定科目マッピングのスキルは一度書いて終わりではなく、レビューで人間が修正した結果をスキルに還元していく運用が前提になる。「Amazonの取引を消耗品費にしたが、内容を見たら図書だったので図書研究費に直した」といった修正ログを月次で振り返り、判断基準をSKILL.mdに追記する。こうしてベテランの暗黙知を少しずつ文書化していくと、新人の教育コストと判断のばらつきが同時に下がっていく。
手順3：月次試算表の異常検知
記帳が終わったら月次試算表をチェックする。ここでよくあるのが「先月は計上されていた家賃が今月抜けている」「広告費が前月の3倍に跳ねている」といった異常の見落とし。Claude Code に前月・前年同月のデータを渡して、差分を機械的に洗わせる。
【プロンプト③：試算表の異常検知】
trial_balance_2026-04.csv（当月）と trial_balance_2026-03.csv（前月）、
trial_balance_2025-04.csv（前年同月）を比較してください。
以下の観点で「要確認フラグ」を立て、anomalies.md に出力してください。
1. 前月まで毎月計上があったのに当月ゼロの科目（計上漏れの疑い）
2. 前月比 ±50% 超の増減がある科目
3. 通常マイナスにならない科目がマイナス残高になっている
4. 仮払金・仮受金・現金過不足など、清算されるべき科目の残高
各フラグには「数値（前月→当月）」と「想定される原因」を添えてください。
原因は仮説であることを明記し、断定しないでください。これは「決算を組む」のではなく「人間が見るべき場所をAIに先回りで指さしてもらう」用途。試算表全体を眺めて異常を探す作業は集中力を消耗するが、Claude Code がフラグを立ててくれれば、スタッフはフラグの当否を判断するだけで済む。
手順4：クライアント向け月次報告コメント生成
月次決算が固まったら、クライアントへ報告する。数字の羅列をそのまま送っても経営者には伝わらないので、平易なコメントを添えるのが付加価値になる。ただし、ここは事実の説明にとどめ、節税の断定や投資助言には踏み込まないのが鉄則だ。
【プロンプト④：月次報告コメントの下書き】
確定した trial_balance_2026-04.csv をもとに、クライアント（小売業・
従業員10名規模）向けの月次報告コメントを下書きしてください。
- 売上・粗利・営業利益の前月比・前年同月比を、数字とともに平易に説明。
- 大きく動いた科目があれば、その背景の「確認すべき問い」を投げる
形にしてください（例：「広告費が増えています。新規施策の効果は
いかがでしょうか？」）。
- 節税の断定・投資判断の助言は書かないでください。
最終的な経営判断はクライアントが行います。
- A4半ページ程度、です・ます調で。ポイント：「断定しない・助言しない・問いを返す」という制約を入れることで、税理士が最終チェックする前提のドラフトとして安全に使える。担当者は文章をゼロから書くのではなく、AIの下書きに事務所の見解を一筆足して仕上げる。効果（想定）：報告書作成の初稿時間が圧縮され、その分をクライアントとの対話に回せる。
手順5：freee / マネーフォワード API 連携
ここまでローカルのCSV・Markdownで完結させてきたが、最終的には会計ソフトと連携したい。freee の会計API（参照日 2026-05-26）は OAuth2.0 認証で、取引・振替伝票・勘定科目の作成や取得ができる。マネーフォワード クラウドも同様にAPIを公開している。
ただし、Claude Code から会計ソフトのAPIを直接叩かせるのは設計として危うい。本番データへの書き込み権限をエージェントに直渡しすると、誤った仕訳を一括登録するリスクがある。そこで、API を MCP（Model Context Protocol）サーバーでラップし、スコープと操作を制限する。
// .mcp.json（イメージ・スコープを read 中心に絞る例）
{
"mcpServers": {
"freee-accounting": {
"command": "node",
"args": ["./mcp-servers/freee-readonly/index.js"],
"env": {
"FREEE_OAUTH_SCOPE": "read",
"FREEE_COMPANY_ID": "********"
}
}
}
}MCP サーバー側では、get_trial_balance（試算表取得）や get_account_items（勘定科目一覧取得）など読み取り系ツールだけを公開し、書き込みは「ドラフトCSVを書き出すだけ」に留める。実際の登録は、人間が freee の画面でCSVインポートを確認しながら行う。エージェントに本番DBの直接書き込みをさせない、という線引きが安全運用の核だ。
【プロンプト⑤：freee連携での試算表突合】
freee-accounting MCP の get_trial_balance ツールで2026年4月の
試算表を取得し、ローカルで起票した journal_draft.csv の
計上額合計と突合してください。
- 科目ごとに「freee側残高」と「ローカルドラフト合計」を並べ、
差額があれば diff.md に出力してください。
- 書き込みは行わないでください（read スコープのみ）。
- 差額の原因は仮説として提示し、登録は人間が判断します。もうひとつ、定例作業はカスタムスラッシュコマンドにしておくと毎月の運用が安定する。.claude/commands/monthly-close.md に手順2〜5を一連でつなぐコマンドを書いておけば、/monthly-close 2026-04 の1行で月次処理のドラフトが流れる。
# .claude/commands/monthly-close.md
引数 $ARGUMENTS で受け取った対象月について、以下を順に実行する。
1. structured.csv から journal-rules スキルで仕訳ドラフトを起票
2. 試算表の異常検知（anomalies.md）
3. クライアント報告コメントの下書き
4. freee MCP（read）で試算表を取得し突合（diff.md）
各ステップの完了後に要確認件数を報告し、書き込み系の操作は一切行わない。実装スタックのまとめ
| レイヤー | 使うもの | 役割 |
|---|---|---|
| 前提ルール | CLAUDE.md | 証憑フォーマット・禁止事項を常時注入 |
| 仕訳ルール | スキル（SKILL.md） | 事務所独自の勘定科目マッピング |
| 定例処理 | カスタムコマンド | 月次クローズの一括実行 |
| 会計ソフト連携 | MCPサーバー（read中心） | freee/MF APIを安全にラップ |
| 承認フロー | confidence振り分け + 人間承認 | 税理士の最終判断を担保 |
このスタックの設計思想は「権限と判断を、内側から外側へ向かって段階的に開いていく」ことに尽きる。CLAUDE.mdとスキルはローカル文書なので外部への副作用がない。カスタムコマンドも内部処理の自動化にとどまる。唯一外部APIに触れるMCPサーバーだけ、read中心にスコープを絞り、書き込みは人間の手元に残す。この内→外の順番を守れば、エージェントが暴走しても実害が出る範囲を構造的に狭められる。逆に、最初から書き込み権限つきのMCPを与えてしまうと、便利さと引き換えに「誤った仕訳の一括登録」という最悪のシナリオに扉を開けることになる。
段階的導入のロードマップ（3フェーズ・想定）
Phase 1（1〜2ヶ月）：1社・1ヶ月分の証憑で「OCR → 構造化」だけを検証する。精度とフォーマットの安定を確認し、CLAUDE.md を事務所の実態に合わせて調整する。この段階では会計ソフト連携はしない。
Phase 2（3〜4ヶ月）：仕訳推論（手順2）と試算表異常検知（手順3）を追加し、confidence振り分けによる人間承認フローを定着させる。3〜5社に横展開し、スキルの勘定科目マッピングを磨き込む。
Phase 3（5〜8ヶ月）：MCP経由のfreee/MF連携（手順5）とカスタムコマンドによる月次クローズの半自動化に進む。read スコープでの突合から始め、書き込みは最後まで人間の手元に残す。
想定効果（モデルケース・実測値ではない）
以下は想定シナリオの試算値であり、実在事務所の実測ではない。Claude Code 導入による効果は事務所のクライアント構成・証憑の状態・運用体制で大きく変わるため、自事務所での検証を前提にしてほしい。
| 業務 | 導入前（想定） | 導入後（想定） | 性質 |
|---|---|---|---|
| 証憑入力 | 手入力中心 | OCRドラフトの確認・修正中心 | 作業がシフト |
| 仕訳起票 | 全件ゼロから起票 | ドラフト承認・低confidence集中対応 | 作業がシフト |
| 試算表チェック | 全件目視 | フラグの当否判断 | 論点が絞られる |
| 月次報告 | ゼロから執筆 | 下書きへの加筆 | 初稿時間圧縮 |
想定事例3パターン
以下はいずれも想定シナリオ（モデルケース）で、実在の事務所ではない。規模ごとに導入の重心が変わる点を示すために用意した。
事例A：所長1名＋補助3名の小規模事務所
クライアント30社前後、記帳代行が売上の柱。リソースが限られるため、いきなり全手順を入れず手順1（OCR）と手順2（仕訳ドラフト）だけを入れるのが現実的。所長がCLAUDE.mdと仕訳スキルを書き、補助スタッフはドラフト承認に専念する。会計ソフト連携（手順5）はPhase 3まで保留し、CSVインポートの手作業を残す。導入の主目的は「繁忙期の残業圧縮」。
事例B：スタッフ20名規模の中堅税理士法人
記帳代行・月次・申告を一気通貫で受ける中堅。クライアント数が多いため手順3（試算表異常検知）と手順4（報告コメント）の横展開効果が大きい。スキルを「業種別マッピング」（小売用・建設用・飲食用）に分割管理し、担当者ごとのレビューカルチャーを揃える。情報システム担当が1名いれば、MCPサーバーの内製も射程に入る。ガバナンス上、要配慮情報のマスキング前処理（後述）を全社ルール化する必要がある。
事例C：記帳代行特化のBPO事業者
税理士事務所から記帳代行を請け負うBPO。手順1〜2を大量・高速に回すことが収益に直結する。confidence振り分けによる「自動処理レーン」と「人間レビューレーン」の二層化を徹底し、低confidence比率をKPI管理する。ただしBPOは税理士の独占業務（税務判断）には踏み込めないため、出力は必ず委託元の税理士確認を通す建て付けにする。会計ソフト連携はクライアントごとにスコープを分離する。
BPO特有の注意点として、委託元ごとに勘定科目マッピングや摘要の付け方の流儀が違うのが厄介だ。ここはスキルを「委託元A用」「委託元B用」とディレクトリで分割し、処理開始時に対象の委託元スキルだけを読み込ませる運用が効く。共通ルールは上位のCLAUDE.mdに、個別ルールは委託元スキルに、と階層を切っておくと、ルールの衝突や取り違えを防げる。さらにBPOは扱う件数が多いぶん、要配慮情報のマスキング前処理の自動化と、処理ログ（いつ・どの証憑を・誰の指示で処理したか）の記録を仕組みとして組み込んでおくと、委託元への説明責任とトラブル時の追跡可能性を担保できる。スピードと信頼性を両立させる土台は、結局このガバナンス設計の丁寧さに尽きる。
【要注意】よくある失敗パターンと回避策
失敗1：仕訳をAI任せにして税理士確認を飛ばす
❌ Claude Code が起票した仕訳ドラフトを、確認なしでそのまま会計ソフトに登録する。
⭕ confidence振り分けで低・中信頼度は必ず人間（最終的には税理士）が確認する2段階フローにする。
なぜ重要か：税務代理・税務書類の作成・税務相談は税理士法上の独占業務であり、AIは判断主体になれない（日本税理士会連合会・参照日 2026-05-26）。AIは補助ツールであって、最終判断者ではない。所属事務所の規程とコンプライアンスに従って運用してほしい。
失敗2：個人情報・マイナンバーをプロンプトに投入する
❌ 顧客の氏名・住所・口座番号・マイナンバーが写った証憑画像を、そのまま外部AIサービスに渡す。
⭕ マイナンバー・口座番号などの要配慮情報は、AIに渡す前にマスキング／削除する前処理を必ず挟む。会話内容が学習データに使われ得る点を前提に運用設計する。
なぜ重要か：個人情報保護委員会は、入力した個人情報がAIの学習データとして利用される可能性などについて注意喚起している（個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について」・参照日 2026-05-26）。「ローカルだから安全」と断定せず、利用するサービスのデータ取り扱いとオプトアウト設定、所属組織の規程を必ず確認すること。
失敗3：電子帳簿保存法（電帳法）の保存要件を無視する
❌ Claude Code でOCRした証憑データを保存して満足し、原本データの保存要件を満たさない。
⭕ 電子取引データは「改ざん防止措置」と「日付・金額・取引先での検索性」を満たして保存する。OCRはあくまで仕訳補助であり、電帳法上の保存要件とは別管理にする。
なぜ重要か：電子取引で授受したデータ（請求書・領収書・契約書など）は、要件に従って電子データのまま保存する義務がある（国税庁「電子帳簿等保存制度特設サイト」・参照日 2026-05-26）。改ざん防止のための事務処理規程の整備や検索機能の確保が求められる。最新の保存要領は必ず公式サイトで確認してほしい。
失敗4：インボイス（適格請求書）の登録番号を誤認する
❌ OCRが読み取った登録番号をそのまま信用し、無効・誤った番号で課税仕入れの控除を起票する。
⭕ 登録番号（T+13桁）はOCRで桁を取り違えやすいため、国税庁の公表サイトでの照合を運用に組み込む。判読不能な桁は推測で埋めない。
なぜ重要か：登録番号は「T」＋13桁の数字で、国税庁の適格請求書発行事業者公表サイトで有効性を確認できる（国税庁インボイス制度適格請求書発行事業者公表サイト・参照日 2026-05-26）。仕入税額控除の可否に直結するため、OCRの読み取り誤りをそのまま会計処理に流すのは危険だ。
関連記事・ピラーページ
- AIエージェント活用完全ガイド — Claude Code をはじめとするAIエージェントの全体像
- AI導入戦略の進め方 — 段階的導入とガバナンス設計の考え方
- 士業・専門業務の他の実装事例も 事例ハブ から確認できる
よくある質問（FAQ）
Q1. Claude Codeで税務申告まで自動化できますか？
いいえ。税務代理・税務書類の作成・税務相談は税理士法上の税理士独占業務です。Claude Code が担えるのは記帳代行・月次決算の下処理（証憑構造化・仕訳ドラフト・異常検知・報告下書き）までで、最終的な税務判断は税理士が行う必要があります。
Q2. 顧客のマイナンバーや個人情報を入力しても大丈夫ですか？
マイナンバーや口座番号などの要配慮情報は、AIに渡す前にマスキング・削除する前処理を必ず挟んでください。個人情報保護委員会も生成AI利用時の個人情報の取り扱いに注意喚起しています。利用するサービスのデータ取り扱い・学習利用の有無を確認し、所属組織の規程に従ってください。
Q3. freeeやマネーフォワードと連携できますか？
はい。両社ともOAuth2.0認証のAPIを公開しており、MCPサーバー経由でラップして連携できます。ただし誤登録を防ぐため、書き込み権限はエージェントに渡さず、read中心のスコープにして実際の登録は人間が確認しながら行う設計を推奨します。
Q4. 電子帳簿保存法への対応はClaude Codeで完結しますか？
いいえ。OCRや構造化は仕訳の補助であり、電帳法上の電子取引データの保存（改ざん防止措置・検索性の確保）とは別管理が必要です。保存要件は会計ソフトや専用システム側で満たし、最新の要領は国税庁の公式サイトで確認してください。
Q5. 小規模事務所でも導入できますか？
できます。所長1名規模なら、まず手順1（証憑OCR）と手順2（仕訳ドラフト）だけを入れ、会計ソフト連携は後回しにするのが現実的です。1社・1ヶ月分の証憑で精度を体感してから横展開するのが安全です。
まとめ｜今日から始める3つのアクション
Claude Code は会計事務所の「記帳・仕訳の下処理」を薄くする実装基盤になる。申告を自動化する話ではなく、税理士の判断時間を確保するための土台づくりだ。最後に、今日から踏める3つのアクションを挙げる。
- 1社分の証憑でOCR→CSV構造化だけを試す — まず手順1だけ。精度と出力フォーマットの安定を確認する。
- 事務所の仕訳ルールをCLAUDE.md / スキルに書き出す — ベテランの頭の中を文書化する作業そのものが、属人化解消の第一歩になる。
- 要配慮情報のマスキングルールを決める — マイナンバー・口座番号をAIに渡さない前処理を、導入より先に固める。
記帳・仕訳の自動化を自事務所にどう組み込むか、実装の壁打ち相手が必要なら、Claude Code の個別導入支援で一緒に設計できる。まずは お問い合わせフォーム から、自事務所のクライアント構成と証憑の状況を教えてほしい。
Claude Code 導入を相談する（3つの入口）
- 個別導入支援を相談する — 自事務所の業務に合わせた実装設計
- 無料相談を申し込む — 「どこから手を付けるか」の整理から
- AIエージェント活用ガイドを読む — 全体像を先につかむ
著者プロフィール
佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援を展開。著書『AIエージェント仕事術』（SBクリエイティブ）。SoftBank IT連載を執筆。
出典
- 国税庁「電子帳簿等保存制度特設サイト」（参照日 2026-05-26）
- 国税庁インボイス制度適格請求書発行事業者公表サイト（参照日 2026-05-26）
- 日本税理士会連合会（税理士の独占業務・参照日 2026-05-26）
- freee Developers Community（会計API公式ドキュメント）（参照日 2026-05-26）
- 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について」（参照日 2026-05-26）
