何を試しているか
自社（キッズプレート）の 見積・請求・支払・銀行管理・経理 の業務を、AI と統合した 1 つの社内アプリで完結させる試作。サーバー不要・ブラウザ内 SQLite で動くローカルファースト設計を採用し、AI を「経理の相棒」として組み込む方向性を検証している。
実装している主な機能
- 見積書・請求書・納品書の作成 / PDF 出力（@react-pdf/renderer）
- 他社フォーマットの PDF 取込（Gemini OCR で宛先・品目・税区分を自動抽出 → フォーム自動反映）
- 取引先マスターの自動生成（OCR 結果から会社名正規化 → 既存マッチ or 新規登録の自動判定）
- 内税 / 外税の自動判定（Gemini が「内消費税額」「税込」等の文言・金額レイアウトから推定）
- 通帳・銀行明細の取込（CSV / 写真 / PDF。Gemini OCR）
- 入金照合（未入金請求書と銀行入金の自動マッチング、カタカナ正規化・法人格除去含む）
- 弥生会計 CSV 出力（月指定で 25 列仕訳 CSV 生成、勘定科目・補助科目マッピング、UTF-8 BOM 付き）
- 月次パッケージ（請求書 / 支払い / 銀行取引 / 被請求書 PDF を一括ダウンロード + Chatwork 通知）
- Chatwork 連携（経理担当ルームへの自動通知）
主要画面
何が分かったか
- Gemini 2.5 Flash の請求書 OCR は実務で耐える精度（金額・宛先・税区分・登録番号の抽出を確認）。1 円単位で一致するケースが多い
- 会社名の正規化 は「株式会社 / （株） / ㈱」等の表記揺れを吸収する正規表現と lowercase で実用範囲。略称違い（「デジハリ」vs「デジタルハリウッド」）は人手介入が必要
- ローカルファースト + sql.js は経理データのプライバシー要件と運用シンプルさの両立に向く
- 「通帳の写真を撮る → OCR → 入金照合」のフローが回ると、月末作業の体感時間が大幅に減る
- Gemini API キーは プロジェクト別に分離 したほうが良い（経理データは他プロダクトのローテに巻き込まれたくない、課金も切り分けたい）
技術スタック
| 領域 | 採用 |
|---|---|
| フロントエンド | Next.js 16.1 (App Router, Turbopack) / React 19 / TypeScript / Tailwind CSS 4 |
| 状態管理 | Zustand |
| データベース | sql.js（ブラウザ内 SQLite WASM、ローカルファースト） |
| PDF 生成 | @react-pdf/renderer |
| バリデーション | zod |
| AI / OCR | Gemini 2.5 Flash（通帳・請求書 PDF・登録番号読取） |
| 連携 | Chatwork API（経理ルーム通知） |
制限・位置づけ
これは 社内自社業務用の R&D アプリ であり、外部公開・受託対応・SaaS 化の予定はない。経理データの取扱いと、API キーの個別管理が必要なため、安易な複製には向かない。本アプリで得た「Gemini OCR の業務統合」「ローカルファースト経理」「PDF 取込 + 自動マスター登録」の知見は、他の自社プロダクトや受託案件の AI 統合工程に還流させる想定。
リポジトリは private、本エントリでは設計思想と機能概要のみ記録する。