• #tax-assistant
  • #claude-code
  • #codex-review
  • #planning
開発tax-assistantメモ

概要

2026年1月26日、税務アシスタントの主要な3つの計画書を策定し、Codexによるレビューを経てplanned状態へ移行した。

  • 帳票タイプマスター管理機能: Codexレビュー9回
  • 重複チェック機能拡充: Codexレビュー1回
  • クレカ明細確定ステータス追加: Codexレビュー1回

帳票タイプマスター管理機能

計画の背景

帳票(領収書、クレカ明細、銀行明細など)ごとにデフォルトの勘定科目を設定する機能が必要になった。CSVインポート時に自動的に借方・貸方の勘定科目を適用するための基盤となる。

ミラーカラムUIでの帳票一覧表示

帳票の設定画面はミラーカラムレイアウトを採用。3階層で構成される。

┌─────────────┬──────────────┬─────────────────────────────┐
│ 大分類      │ 中分類        │ 帳票カード                   │
├─────────────┼──────────────┼─────────────────────────────┤
│ ● 支出      │ 領収書/レシート │ ┌─────────────────────────┐ │
│   収入      │ クレカ明細     │ │ 領収書・レシート           │ │
│   入出金    │              │ │ ┌──────────┬────────────┐ │ │
│             │              │ │ │ 借方      │ 貸方        │ │ │
│             │              │ │ │ (グレー)  │ 仮払金      │ │ │
│             │              │ └─┴──────────┴────────────┴─┘ │
└─────────────┴──────────────┴─────────────────────────────┘

借方・貸方の仕訳形式カード表示

各帳票カードは仕訳形式で左右に分割表示される。

  • 左側(借方): レシート/CSV明細から決まる場合はグレーアウト
  • 右側(貸方): 設定可能な勘定科目・補助科目・税区分

収支区分の設計

中カテゴリとして3つの収支区分を設定。

収支区分説明
支出費用が発生する帳票領収書、クレカ明細
収入収益が発生する帳票売上伝票
入出金入金・出金の両方がある銀行口座

銀行口座の入金時・出金時の設定分離

銀行口座は入金と出金で異なるデフォルト勘定科目を設定できる。

┌────────────────────────────────────────────┐
│ 住信SBIネット銀行                           │
├────────────────────────────────────────────┤
│ 【入金時】                                  │
│   借方: 普通預金/住信SBI    貸方: (グレー)   │
├────────────────────────────────────────────┤
│ 【出金時】                                  │
│   借方: (グレー)           貸方: 普通預金/住信SBI │
└────────────────────────────────────────────┘

相手勘定科目はCSV明細から決まるため、変更不可(グレーアウト)としている。

WebUIでの設定変更対応

当初はCLIでの対話形式を検討していたが、以下の理由でWebUI中心に変更。

  • 勘定科目・税区分は表記ゆれを防ぎたい
  • ドロップダウン選択の方が入力ミスが少ない
  • CLIはJSON一括インポートの補助用途のみ

Codexレビューのポイント(9回)

主な指摘対応
1-2回direction(収支区分)とデフォルト勘定科目の整合性バリデーションルール明記
3-4回銀行口座の入金/出金判定ルールdirection=bothの設計追加
5-6回初期データ(シード)のバリデーションsales_slipのdebit_account追加
7-8回APIの必須チェック(422エラー)Pydanticバリデーション追加
9回FK参照による勘定科目の整合性担保account_categoriesテーブル参照

重複チェック機能拡充

duplicate_group_idによる正規化

重複グループを一意に識別するためのIDを導入。

ALTER TABLE receipts ADD COLUMN duplicate_group_id TEXT;

同じグループに属する帳票は同一のgroup_idを持ち、重複関係を正規化して管理する。

有効件数ルール(1件以上有効)

重複グループ内で、少なくとも1件は有効(is_active = true)である必要がある。

  • 重複して両方有効のパターン: 許可
  • 重複して両方無効のパターン: 禁止(バリデーションエラー)

帳票タイプマスターとの連携

重複チェック後の未紐付けレシートの貸方科目は、帳票タイプマスターの設定に従う。

帳票タイプマスター
  ↓ デフォルト勘定科目
重複チェック結果
  ↓ 紐付け
仕訳出力

Codexレビューのポイント(1回)

  • duplicate_group_idの正規化基準の明確化
  • 有効件数ルールのバリデーション設計
  • 帳票タイプマスターとの依存関係の明記

クレカ明細確定ステータス追加

状態遷移設計

クレカ明細の確認状態を3状態で管理。

状態説明
unchecked未確認(初期状態)
ok確認済み(仕訳変換対象)
ng確認NG(仕訳変換対象外)

確定済みは再突合せ時に除外

クレカ明細とレシートの突合せ処理において、確定済み(ok/ng)の明細は再処理対象から除外する。

# 突合せ対象のフィルタ
target_records = [r for r in records if r.status == 'unchecked']

これにより、一度確認した内容が再突合せで上書きされることを防ぐ。

Mermaid形式の状態遷移図

計画ドキュメントの可読性向上のため、ASCII形式からMermaid形式に変換した。

さらに、plansページにMermaidレンダリング機能を追加。クライアントサイドでMermaid.jsを読み込み、コードブロックを図として表示できるようにした。

Codexレビューのポイント(1回)

  • 再突合せ時の除外ルールの明確化
  • 状態遷移のトリガー条件の明記
  • プライベート確定(private_ok)の設計検討

その他の作業

デザインシステムのリファクタリング

  1. SortableHeader/SortIndicatorコンポーネント追加: ソートインジケーターの統一
  2. ゴミ箱アイコンの統一: 絵文字からTrashIconコンポーネントへ移行
  3. ナビゲーションコンポーネントの共通化: useKeyboardNav + NavigationBar

勘定科目マスターの実装完了

帳票タイプマスターの依存先である勘定科目マスターDB化をPhase 1-5まで実装完了。

  • CSVインポート(MF形式対応)
  • API(CRUD + フィルタ)
  • ミラーカラムUI(BS/PL → 中カテゴリ → MF分類 → 勘定科目)
  • 削除機能(物理削除)
  • キーボードナビゲーション

まとめ

3つの計画書がplanned状態となり、依存関係も整理された。

計画状態依存Codexレビュー
帳票タイプマスター管理planned勘定科目マスター(完了)9回
重複チェック機能拡充planned帳票タイプマスター1回
クレカ明細確定ステータスplannedなし1回

次のステップは、依存解決済みの「帳票タイプマスター管理」または「クレカ明細確定ステータス」の実装着手となる。