Tax Assistant：Claude Codeスラッシュコマンド設計

税理士業務の記帳作業をClaude Codeで効率化するためのスラッシュコマンド設計。Googleスプレッドシート + GASベースのワークフローを、Nuxt 3 + Python + SQLiteのローカルアプリ「Tax Assistant」に置き換える。

システム概要

解決したい課題

アーキテクチャ

┌─────────────────────────────────────┐
│  Nuxt（ブラウザ）                    │
│  ・取引一覧・仕訳候補を表示          │
│  ・バリデーション結果の確認          │
│  ・貸借一致・残高整合性チェック      │
│  ・処理の進捗をリアルタイム表示      │
│  ・操作ボタンなし（確認専用）        │
└─────────────────────────────────────┘
              ↑ 参照（リロードで最新反映）
┌─────────────────────────────────────┐
│  SQLite DB                          │
└─────────────────────────────────────┘
              ↑ 読み書き
┌─────────────────────────────────────┐
│  Claude Code CLI                    │
│  ・スラッシュコマンドで操作          │
│  ・仕訳提案・承認・修正              │
│  ・全ての変更操作はここで完結        │
└─────────────────────────────────────┘

ワークフロー:

1. Claude CodeがPython経由でDBにデータを書き込む
2. Nuxtダッシュボードをリロードして結果を確認
3. 問題があればClaude Codeに伝えて修正（入力データ or テストコード）

NuxtはSQLiteを直接読み込むため、Pythonが書き込んだデータが即座に反映される。ダッシュボードで問題を発見し、Claude Codeで修正するという分業。

仕訳候補提案の4層構造

層3について: 税務書籍（消費税の実務書等）をOCR・裁断してデータベース化したもの、および仕訳で誤りやすい事例を集めたTips集をマニュアルとして整備。これをClaude Codeのスキルまたはスラッシュコマンドとして登録し、判断の拠り所として参照する。

データ構造

顧問先ごとにDB分離

data/
├── clients.db              # メタDB（顧問先一覧）
├── client_001/
│   ├── client_001.db       # 顧問先の取引データ
│   ├── files/              # 証憑ファイル
│   │   └── 2026-01/
│   │       └── receipt_001.pdf
│   └── backups/            # 日次スナップショット
│       ├── 2026-01-07.db
│       └── 2026-01-08.db

機密性を確保しつつ、顧問先単位でバックアップ・移動が可能。

顧問先の自動判定

全てのコマンドはカレントディレクトリから顧問先を自動判定する。

# 顧問先ディレクトリに移動
cd data/client_001

# 以降のコマンドは顧問先IDの指定不要
/import-receipts ./receipts/2025-01/
/suggest
/status

判定ロジック:

1. カレントディレクトリが data/{client_id}/ 配下かチェック
2. 該当すれば {client_id} を自動設定
3. 該当しなければエラー（data/ 配下で実行してください）

スラッシュコマンド一覧

9つのコマンドを定義。現時点では仮説ベースの設計。

業務フローチャート

flowchart TD
    subgraph phase1["📥 Phase 1: データ取り込み"]
        start([開始]) --> input_type{入力データの種類}
        input_type -->|CSV| cmd_csv["/import-csv"]
        input_type -->|レシート画像| cmd_receipts["/import-receipts"]
        cmd_csv --> claude_csv["🤖 Claude Code処理<br/>・CSVパース<br/>・重複チェック<br/>・DB登録"]
        cmd_receipts --> claude_ocr["🤖 Claude Code処理<br/>・OCR実行<br/>・データ抽出<br/>・DB登録"]
        claude_csv --> human_check1["👤 人間確認<br/>・取り込み件数確認<br/>・重複候補の確認"]
        claude_ocr --> human_check1
    end

    subgraph phase2["✅ Phase 2: バリデーション"]
        human_check1 --> cmd_validate["/validate"]
        cmd_validate --> claude_validate["🤖 Claude Code処理<br/>・重複検出<br/>・日付連続性チェック<br/>・残高整合性検証<br/>・必須フィールド確認"]
        claude_validate --> human_check2["👤 人間確認<br/>・警告内容の確認<br/>・修正要否の判断"]
        human_check2 -->|修正必要| fix_data["データ修正"]
        fix_data --> cmd_validate
        human_check2 -->|OK| phase3_start
    end

    subgraph phase3["💡 Phase 3: 仕訳候補提案"]
        phase3_start([検証完了]) --> cmd_suggest["/suggest"]
        cmd_suggest --> claude_layer1["🤖 層1: ルールベース<br/>キーワードマッチング"]
        claude_layer1 --> claude_layer2["🤖 層2: 類似度検索<br/>過去取引との照合"]
        claude_layer2 --> claude_layer3["🤖 層3: 税務ルール参照<br/>スキル/コマンド経由で<br/>消費税DB・Tipsを参照"]
        claude_layer3 --> claude_layer4["🤖 層4: Claude判断<br/>上記で判定不可なものを<br/>AIが内容を見て判断"]
        claude_layer4 --> human_check3["👤 人間確認<br/>・提案内容の確認<br/>・未分類取引の確認"]
    end

    subgraph phase4["✍️ Phase 4: 承認・編集"]
        human_check3 --> cmd_status["/status"]
        cmd_status --> claude_status["🤖 Claude Code処理<br/>・状況サマリ表示<br/>・pending一覧表示"]
        claude_status --> human_review["👤 人間判断<br/>各仕訳候補を確認"]
        human_review -->|承認| cmd_approve["/approve"]
        human_review -->|却下| cmd_reject["/reject"]
        human_review -->|修正| cmd_edit["/edit"]
        cmd_approve --> claude_approve["🤖 Claude Code処理<br/>・仕訳として登録<br/>・ステータス更新"]
        cmd_reject --> claude_reject["🤖 Claude Code処理<br/>・却下理由を記録<br/>・学習データに追加"]
        cmd_edit --> claude_edit["🤖 Claude Code処理<br/>・フィールド更新<br/>・変更履歴記録"]
        claude_approve --> more_pending{未処理あり?}
        claude_reject -->|--reassign| cmd_suggest
        claude_reject -->|通常| more_pending
        claude_edit --> more_pending
        more_pending -->|Yes| human_review
        more_pending -->|No| phase5_start
    end

    subgraph phase5["📤 Phase 5: エクスポート"]
        phase5_start([承認完了]) --> cmd_export["/export-mf"]
        cmd_export --> claude_export["🤖 Claude Code処理<br/>・MF形式CSV生成<br/>・差分チェック"]
        claude_export --> human_final["👤 人間作業<br/>・CSVファイル確認<br/>・マネーフォワードで取込"]
        human_final --> finish([完了])
    end

    style phase1 fill:#e3f2fd
    style phase2 fill:#fff3e0
    style phase3 fill:#f3e5f5
    style phase4 fill:#e8f5e9
    style phase5 fill:#fce4ec

役割分担サマリ

/import-csv - CSV取り込み

マネーフォワードや銀行明細などのCSVをDBに取り込む。

/import-csv <CSVファイルパス> [--type <種別>]

処理内容

1. CSVファイルを読み込み
2. 種別に応じてパース（MF形式 / 銀行形式 / クレカ形式）
3. 重複チェック（日付 + 金額 + 摘要 で既存データと照合）
4. 取引データとしてDB登録

出力例

✓ 取り込み完了
  - 新規: 45件
  - 重複スキップ: 3件
  - エラー: 0件

重複候補:
  #123: 2025-01-15 ¥5,000 コンビニ（既存: #45 と類似）

/import-receipts - レシート一括OCR

レシート・領収書の画像を一括でOCR処理し、取引データとしてDB登録。

/import-receipts <画像ディレクトリ or ファイル> [--method <方式>]

処理方式

抽出データ

{
  "date": "2025-01-15",
  "amount": 5000,
  "store": "コンビニA",
  "description": "事務用品",
  "confidence": 0.95,
  "source_file": "files/2025-01/receipt_001.jpg"
}

出力例

✓ OCR処理完了
  - 処理: 20件
  - 成功: 18件
  - 要確認: 2件（信頼度低）

要確認:
  #15: receipt_015.jpg - 金額不明瞭
  #18: receipt_018.jpg - 日付読み取り失敗

/validate - バリデーション実行

取り込んだ取引データの重複・欠落・整合性チェックを実行。

/validate [--period <期間>] [--check <チェック種別>]

チェック項目

クロスチェック（突合）の詳細

複数データソース間の整合性を検証する。

1. クレカ明細 ↔ 領収書/レシート突合

クレカ明細                     領収書/レシート
┌──────────────────────┐      ┌──────────────────────┐
│ 日付: 2025-01-15     │ ←──→ │ 日付: 2025-01-15     │
│ 金額: ¥5,000         │ 一致 │ 金額: ¥5,000         │
│ 摘要: Amazon         │      │ 店舗: Amazon         │
└──────────────────────┘      └──────────────────────┘
         ↓ マッチ
   領収書添付済みフラグ = true
   → 仕訳: 借方 費用科目 / 貸方 未払金（補助: クレカ名）

• 日付 + 金額が一致: 重複候補としてフラグ
• マッチ時: 領収書をクレカ明細に紐付け、証憑添付済みとする
• クレカ明細のみ（領収書なし）: Web明細取引として独立処理（例: Google Cloud、サブスク）

2. クレカ締め日 ↔ 銀行引落突合

クレカ明細（楽天カード）           銀行引落
┌──────────────────────┐        ┌──────────────────────┐
│ 1/1〜1/31 利用分      │        │ 日付: 2025-02-27     │
│ 締め日: 1/31          │  ───→  │ 金額: ¥150,000       │
│ 引落日: 2/27          │  一致  │ 摘要: ラクテンカード  │
│ 合計: ¥150,000        │        └──────────────────────┘
└──────────────────────┘
         ↓ マッチ
   仕訳: 借方 未払金（補助: 楽天カード） / 貸方 普通預金（補助: 銀行口座名）

カード締め日マスタ

{
  "credit_cards": [
    {"name": "楽天カード", "closing_day": 31, "payment_day": 27, "payment_month_offset": 1},
    {"name": "三井住友カード", "closing_day": 15, "payment_day": 10, "payment_month_offset": 1},
    {"name": "アメックス", "closing_day": 19, "payment_day": 10, "payment_month_offset": 1}
  ]
}

仕訳パターン（事業形態別）

現金出金の場合

法人の場合: 代表者が立て替えた経費は一旦「代表者借入金」で処理。後日精算時に「代表者借入金 / 普通預金」で消し込む。

クレカ決済の場合

証憑チェック

出力例

✓ バリデーション完了（2025年1月）

【重複検出】OK - 0件
【クロスチェック】
  - クレカ↔領収書: 45件マッチ、3件未マッチ
  - クレカ締め↔銀行引落: 2件マッチ（楽天¥150,000、三井住友¥80,000）
【日付連続性】警告 - 1件
  - 2025-01-15 のデータがありません
【残高整合性】OK
【証憑チェック】警告 - 5件
  - #45: 現金支出 ¥3,000 証憑なし
  - #67: クレカ利用 ¥12,000 証憑なし（Web明細?）
【必須フィールド】警告 - 3件
  - #45: 摘要が空
  - #67: 勘定科目未設定

サマリ: 警告9件、エラー0件

次のアクション:
  - 証憑なし取引を確認: /status --view missing-voucher
  - Web明細取引をマーク: /edit 67 --field voucher_type=web

自動修正オプション

/validate --fix

明らかな重複は自動削除（確認付き）、空フィールドには「要入力」フラグを付与。

/suggest - 仕訳候補提案

取引データに対して、4層構造で仕訳候補を提案。

/suggest [--period <期間>] [--layer <層>] [--limit <件数>]

4層構造の詳細

層1: ルールベース

rules = [
    {"pattern": "Amazon", "debit": "消耗品費", "credit": "普通預金"},
    {"pattern": "電気代", "debit": "水道光熱費", "credit": "普通預金"},
    {"pattern": r"交通費|電車|バス", "debit": "旅費交通費", "credit": "現金"},
]

層2: 類似度検索

# 過去2年分の取引+仕訳データを参照
# 類似度閾値: 0.8 以上
similar = find_similar_transactions(
    query=current_transaction.description,
    history=past_transactions,
    threshold=0.8
)

層3: 税務ルール参照（スキル/スラッシュコマンド）

層1, 2で判定できなかった取引に対し、以下のナレッジベースを参照して判断:

• 消費税判定DB: 税務書籍（消費税の実務書等）をOCR・裁断してデータベース化。課税/非課税/不課税/輸出免税などの判定ルールを体系的に参照
• 仕訳Tipsマニュアル: 誤りやすい仕訳事例を集めた実務Tips集。よくある間違いパターンと正しい処理方法を参照

# スキルまたはスラッシュコマンドとして登録
# 例: /tax-rules consumption-tax "飲食代"
# 例: Skill("tax-rules")
tax_result = invoke_skill_or_command(
    name="tax-rules",
    query=current_transaction.description,
    context={"amount": amount, "vendor": vendor}
)

層4: Claude判断

層1〜3で判定できなかったものをClaudeが内容を見て判断・提案。

出力例

✓ 仕訳候補提案完了

【層1: ルールベース】32件マッチ
【層2: 類似度検索】45件マッチ
【層3: 税務ルール参照】12件マッチ
【層4: Claude判断】8件提案

未分類（提案できず）: 5件
  - #123: 2025-01-15 ¥50,000 振込 ヤマダ（詳細不明）

提案一覧を確認するには:
  /status --view pending

提案データ構造

{
  "id": 1,
  "transaction_id": 123,
  "status": "pending",
  "layer": 2,
  "confidence": 0.85,
  "debit_account": "消耗品費",
  "credit_account": "普通預金",
  "amount": 5000,
  "reason": "過去取引 #45 と類似（類似度: 0.92）"
}

/approve - 仕訳候補承認

提案された仕訳候補を承認し、正式な仕訳として登録。

/approve <対象> [--force]

使用例

# 単一承認
/approve 123

# 範囲承認
/approve 123-150

# 信頼度高いもの一括承認（confidence >= 0.9）
/approve high-confidence

# 全件承認（要確認）
/approve all

確認プロンプト

以下の仕訳候補を承認しますか？

#123: 2025-01-15 消耗品費 / 普通預金 ¥5,000（Amazon）
#124: 2025-01-16 旅費交通費 / 現金 ¥1,200（電車代）
#125: 2025-01-17 水道光熱費 / 普通預金 ¥8,500（電気代）

合計: 3件

承認しますか？ (y/n)

出力例

✓ 承認完了: 3件

#123 → 仕訳 J-456 として登録
#124 → 仕訳 J-457 として登録
#125 → 仕訳 J-458 として登録

/reject - 仕訳候補却下

提案された仕訳候補を却下。却下理由は学習データとして活用。

/reject <対象> [--reason <理由>] [--reassign]

使用例

# 理由付きで却下
/reject 123 --reason "勘定科目が違う、正しくは接待交際費"

# 却下して再提案依頼
/reject 123 --reassign

--reassign の場合

✓ 却下完了: #123

再提案中...

【Claude判断】
取引内容: Amazon ¥5,000 「贈答品」
推奨仕訳: 接待交際費 / 普通預金 ¥5,000
理由: 摘要に「贈答品」とあるため、消耗品費ではなく接待交際費が適切

新しい提案 #123-2 を作成しました。
承認する場合: /approve 123-2

学習への活用

却下理由は以下に活用:

• ルールベースの改善（誤マッチパターンの除外）
• 類似度検索の重み調整
• Claude判断時の参考情報

/edit - 仕訳編集

仕訳候補または確定済み仕訳を編集。

/edit <ID> [--field <フィールド>=<値>]

使用例

# 対話的に編集
/edit 123

# フィールド直接指定
/edit 123 --field debit=接待交際費

# 複数フィールド
/edit 123 --field debit=接待交際費 --field amount=6000

対話モード

現在の仕訳:
  日付: 2025-01-15
  借方: 消耗品費
  貸方: 普通預金
  金額: ¥5,000
  摘要: Amazon 贈答品

編集するフィールドを選択:
  1. 日付
  2. 借方勘定科目
  3. 貸方勘定科目
  4. 金額
  5. 摘要
  6. 完了（保存）
  0. キャンセル

編集可能フィールド

/status - 処理状況確認

現在の処理状況、仕訳候補の状態、集計情報を表示。

/status [--view <ビュー>] [--period <期間>]

ビュー: summary（デフォルト）

📊 ステータス（2025年1月）

【取引データ】
  取り込み済み: 150件
  仕訳済み: 120件
  未仕訳: 30件

【仕訳候補】
  提案中（pending）: 25件
  承認済み（approved）: 95件
  却下（rejected）: 5件

【未分類】
  層1-3で判定不可: 5件
  要確認（低信頼度）: 3件

次のアクション:
  /suggest --limit 30  # 未仕訳を処理
  /approve high-confidence  # 高信頼度を一括承認

ビュー: pending

📋 未承認の仕訳候補

#123 | 2025-01-15 | 消耗品費/普通預金 | ¥5,000 | Amazon | 信頼度:0.92 | 層2
#124 | 2025-01-16 | 旅費交通費/現金 | ¥1,200 | 電車代 | 信頼度:0.95 | 層1
#125 | 2025-01-17 | 水道光熱費/普通預金 | ¥8,500 | 電気代 | 信頼度:0.88 | 層2

合計: 25件

操作:
  /approve 123-125  # 範囲承認
  /approve high-confidence  # 高信頼度一括承認

ビュー: unclassified

❓ 未分類の取引

#201 | 2025-01-15 | ¥50,000 | 振込 ヤマダ | 詳細不明
#202 | 2025-01-20 | ¥3,000 | カード | 摘要なし

合計: 5件

これらはClaude判断が必要です:
  /suggest --layer 3  # Claudeに判断を依頼

/export-mf - マネーフォワード用CSV出力

承認済みの仕訳をマネーフォワード取込用のCSV形式で出力。

/export-mf [--period <期間>] [--status <ステータス>] [--output <出力先>]

MF取込CSV形式

取引日,借方勘定科目,借方補助科目,借方税区分,貸方勘定科目,貸方補助科目,貸方税区分,金額,摘要
2025-01-15,消耗品費,,課税仕入10%,普通預金,,,5000,Amazon 事務用品
2025-01-16,旅費交通費,,非課税,現金,,,1200,電車代 新宿-渋谷

出力例

✓ エクスポート完了（2025年1月）

出力ファイル:
  exports/mf_import_2025-01_20260108.csv

内容:
  仕訳件数: 95件
  合計金額: ¥1,234,567

取り込み手順:
  1. マネーフォワードにログイン
  2. 仕訳帳 → インポート → CSV取込
  3. 上記ファイルを選択
  4. プレビューを確認して取込実行

差分エクスポート

# 前回エクスポート以降の新規承認分のみ
/export-mf --diff

前回エクスポート日時を記録し、差分のみ出力（重複取込を防止）。

まとめ

このコマンド設計により、以下のワークフローが実現する:

1. /import-csv または /import-receipts でデータ取り込み
2. /validate で自動バリデーション
3. /suggest で4層構造の仕訳候補提案
4. /status で状況確認しながら /approve /reject /edit で処理
5. /export-mf でマネーフォワードに取り込み

全ての操作をClaude Code CLIで完結させることで、キーボードから手を離さずに記帳作業を進められる。