【個人開発】インボイスT番号照合ツールをNext.js + Supabaseで作った話【前編：企画〜設計】
はじめに
こんにちは、初めまして。
タスクルといいます。
元インフラエンジニアで、現在はITコンサルタントと個人で事業を行っています。
2023年10月にインボイス制度が始まり、フリーランスや小規模事業者の経理負担が一気に増えました。特に面倒なのが 取引先のT番号（適格請求書発行事業者登録番号）の確認作業 です。
国税庁の公表サイトで1件ずつコピペして検索して、結果をメモして…取引先が15社あると毎月45分かかっていました。
「これ、自動化できたら楽かもなー」
と思って作ったのが インボイスチェッカー です。
この記事では前後編に分けて、個人開発でSaaSプロダクトを企画・設計・リリースするまでの全体像をお伝えします。
| 記事 | 内容 |
|---|---|
| 前編（この記事） | 課題発見 → 企画 → 技術選定 → アーキテクチャ設計 |
| 後編 | 実装の詳細 → ハマったポイント → コスト → 運用 |
解決したかった3つの課題
① とにかく面倒
国税庁の公表サイトにアクセスして、T番号を入力して、結果を確認して、スクショを撮って…
1件3分 × 10件 = 30分/月 × 12ヶ月 = 年間6時間
まあめんどくさい作業です。
② 証跡が残らない
「いつ、誰が、どの番号を確認して、結果がどうだったか」を記録する仕組みがなく。スクショやら写真をフォルダに溜めていくのも管理が煩雑です。
税務調査では確認の証跡を求められることがあります。「確認しました」だけでは不十分な場合もあります。
③ 変化に気づけない
一度確認したT番号が、後から取り消されるケースがあります。事業廃止や免税事業者への戻りなど、理由は様々です。定期的に再チェックしないとリスクがあるのに、手動では現実的に気づけない。
既存ツールでは解決できなかった
法人向けの業務システムには同様の機能がありますが、月額数万円〜のサービスが多く、フリーランスにはオーバースペックかつ高額でした。
月1,000円以下で、必要十分な機能を提供するツール が欲しかった。
なかったのでclaude codeで作りました。
個人開発やバイブコーディングに興味のある方、私と同じような悩みがある事業者に届けばよいなと思っています。
プロダクトの全体像
コンセプト
| 項目 | 内容 |
|---|---|
| ターゲット | フリーランス・個人事業主・小規模法人の経理担当 |
| コアバリュー | T番号照合の自動化 + 改変不可の証跡管理 |
| 価格設計 | 無料枠あり（月5件）、有料は月額¥980 |
機能マップ
┌──────────────────────────────────────────────┐
│ インボイスチェッカー │
├──────────────┬────────────────┬───────────────┤
│ 照合機能 │ 取引先管理 │ 証跡管理 │
├──────────────┼────────────────┼───────────────┤
│ PDF/画像 │ CRUD │ INSERT ONLY │
│ アップロード │ アラートON/OFF │ 改変不可 │
│ ↓ │ 定期再チェック │ CSV出力 │
│ OCR(Claude) │ ステータス監視 │ HTML証跡 │
│ ↓ │ │ │
│ 国税庁API照合 │ │ │
└──────────────┴────────────────┴───────────────┘
ユーザーフロー
請求書(PDF/画像)
↓ アップロード
Claude Vision API (OCR)
↓ T番号を自動抽出
国税庁 Web API
↓ 有効性を照合
照合結果を自動記録 (INSERT ONLY)
↓
取引先として登録 → 毎月自動再チェック + アラート通知
技術選定
技術スタック一覧
| レイヤー | 技術 | 選定理由 |
|---|---|---|
| フロントエンド | Next.js 14 (App Router) + TypeScript + Tailwind CSS | SSR + APIルートが1プロジェクトで完結 |
| バックエンド | Next.js API Routes | 別途サーバー不要、Vercelで完結 |
| データベース | Supabase (PostgreSQL) | 無料枠が充実、Auth・Storage・RLSが統合 |
| 認証 | Supabase Auth | メール/パスワード + Google OAuth |
| ストレージ | Supabase Storage | RLSで自分のファイルのみアクセス可 |
| OCR | Claude Vision API | 日本語の請求書に対する精度が高い |
| 決済 | Stripe | Checkout + Customer Portal + Webhook |
| メール | Resend | DKIM/SPF対応、無料枠あり |
| ホスティング | Vercel (Hobby) | 無料、Cron対応、GitHub連携 |
| ドメイン | お名前.com | taskru.jp |
「自作する / 任せる」の線引き
個人開発では コアロジック以外を全て外部サービスに委譲する のが鉄則。これにより開発期間を大幅に短縮できます。
🔨 自作する部分:
├── T番号の抽出ロジック（Claude API呼び出し）
├── 国税庁API連携
├── 証跡管理（INSERT ONLYの仕組み）
├── 取引先管理 + 定期再チェック
└── UI/UX
🔌 外部サービスに任せる部分:
├── 認証 → Supabase Auth
├── DB → Supabase PostgreSQL
├── Storage → Supabase Storage
├── 決済 → Stripe
├── メール → Resend
└── ホスティング → Vercel
この分け方のおかげで、 開発は実質1人月程度 で完了しました。
アーキテクチャ設計
全体構成図
[ユーザー]
│
▼
[Next.js on Vercel]
├── フロントエンド (React + Tailwind)
├── API Routes
│ ├── /api/check/verify ← T番号照合
│ ├── /api/partners/* ← 取引先管理
│ ├── /api/stripe/* ← 決済Webhook
│ ├── /api/contact ← お問い合わせ
│ └── /api/cron/recheck ← 月次バッチ
│
├──→ [Claude Vision API] ← OCR
├──→ [国税庁 Web API] ← T番号照合
├──→ [Supabase] ← DB + Auth + Storage
├──→ [Stripe] ← 決済
└──→ [Resend] ← メール通知
セキュリティ設計
扱うデータが税務関連のため、セキュリティは特に注意を払いました。
RLS（Row Level Security）
全テーブルにRLSを適用。ユーザーは自分のデータしか読み書きできません。
-- 例: verification_records のRLS
CREATE POLICY "Users can only read own records"
ON verification_records FOR SELECT
USING (auth.uid() = user_id);
INSERT ONLYの証跡テーブル
verification_recordsテーブルはINSERT権限のみ。UPDATE/DELETEは一切不可。これにより照合結果の改変を防止しています。
-- INSERT のみ許可（UPDATE, DELETE のポリシーは意図的に作成しない）
CREATE POLICY "insert_own" ON verification_records
FOR INSERT
WITH CHECK (auth.uid() = user_id);
UPDATE/DELETEのポリシーを作成しないことで、RLSレベルで改変を防止。たとえ管理者であっても、通常のSupabaseクライアント経由では変更できません。
レートリミット
エンドポイントごとにIPベースのレートリミットを実装。
| エンドポイント | 制限 |
|---|---|
/api/check/verify（T番号照合） |
5回/分 |
/api/contact（お問い合わせ） |
3回/分 |
| その他 | 10回/分 |
reCAPTCHA v3
ログイン、サインアップ、お問い合わせフォームに導入。ボットからの不正アクセスを防止しています。
料金設計
| プラン | 料金 | 内容 |
|---|---|---|
| 無料 | ¥0 | 月5件まで、請求書保存なし |
| 月額 | ¥980 | 無制限、請求書保存あり |
| 年額 | ¥9,800 | 無制限、請求書保存あり（2ヶ月分お得） |
無料枠を設けた理由は 「まず使ってもらわないと価値がわからない」 から。月5件あれば主要取引先のT番号を一通り確認でき、価値を実感してから有料プランを検討してもらえます。
DBスキーマ設計
主要テーブルの関係は以下の通りです。
users (ユーザー)
│
├── partners (取引先)
│
├── verification_batches (照合バッチ)
│ └── verification_records (照合結果) ★INSERT ONLY
│
├── alert_logs (アラートログ)
│
└── promotion_codes (プロモーションコード)
設計で意識したポイント
-
verification_recordsはINSERT ONLYにして証跡の信頼性を担保 -
partnersテーブルに`ステータスを持たせ、変化検知を効率化 - プロモーションコードで柔軟なトライアル運用を可能に
- 全テーブルにRLSを適用し、ユーザー間のデータ分離を実現
前編まとめ
| フェーズ | 内容 |
|---|---|
| 課題 | T番号確認が面倒、証跡が残らない、変化に気づけない |
| 解決策 | PDFアップロード → OCR → 国税庁API照合 → 証跡自動記録 |
| 技術選定 | コアロジック以外は全て外部サービスに委譲 |
| セキュリティ | RLS + INSERT ONLY + レートリミット + reCAPTCHA |
| 開発期間 | 約1人月 |
後編では、 実装のコード詳細・ハマったポイント5選・ランニングコスト・個人開発で学んだこと をお伝えします。
サービスURL: https://invoice.taskru.jp
Threads: @taskru.tools ── インボイス制度のTipsを毎日発信中