📕

Tagamie — オンチェーン取引を法定 6 要件 PDF にする

に公開
ブロックチェーン
Model Context Protocol
JPYC
経理
x402
tech

シリーズ第 4 回
「エージェント経済で 4 つ作ってたら気づいたら線が見えた話」

前回、yen402-mcp で「エージェントが JPYC を払う」 までを書きました。

今回は、 払った後に来る「...で、経理どうするんだ？」 の話です。

取引が終わった、 では適格請求書は?

agent が paylog で店を見つけて、 yen402-mcp 経由で yen402 を呼んで、 JPYC で 1,500 円分のコーヒーを買った。 ここまでは前 3 回でやりました。

日本では、 2023-10 にインボイス制度が施行されています。 大雑把に言うと、 適格請求書 (法定 6 要件を満たす書面) が無いと、 buyer は仕入税額控除を取れません。 課税事業者にとっては死活問題で、 これが満たされない取引は経理上扱いにくい。

具体例 (¥1,500 仕入 → ¥3,300 売上 → 納税額 ¥164、 適格請求書が無いと ¥300)

ステーブルコインで B2B 取引が成立した時、 適格請求書をどうするのか? on-chain には金額と相手アドレスしか載っていません。 「取引内容」 「相手方の氏名」 「税率別の対価」 「税率別の消費税額」 ... これらは on-chain には無い。

Tagamie はこの問題を on-chain 取引から自動で適格請求書 PDF を発行する SaaS として書いています。 ライブは https://tagamie.vercel.app (Phase 0-A、 営業前)。

法定 6 要件のおさらい

適格請求書は、 消費税法 57 条の 4 (適格請求書等保存方式) に基づき、 以下 6 要件を満たす必要があります:

  1. 発行者の氏名 + 適格請求書発行事業者登録番号 (T 番号)
  2. 取引年月日
  3. 取引内容 (軽減税率対象なら明記)
  4. 税率別に区分した合計対価
  5. 税率別の消費税額等
  6. 受領者の氏名

このうち、 on-chain transfer から自動で取れるのは 2 (取引年月日 ≈ block timestamp) と 4 / 5 (金額から計算可) のみ。 1, 3, 6 は別途解決する必要があります。 これが Tagamie の中核の難しさです。

解決策: 両側 wallet 登録 + cross-layer context

Tagamie が採用した解は 2 つです:

① 両側 wallet 登録

seller と buyer が両方 Tagamie に wallet を SIWE (Sign-In With Ethereum) で事前登録します。 登録時に T 番号、 法人名、 連絡先を入れてもらうと、 法定 6 要件の 1 (発行者) と 6 (受領者) が wallet address から自動で引けるようになります。

「seller と buyer 両方が登録している場合だけ自動」 という制約がありますが、 これが将来のネットワーク効果になります (= 登録が増えるほど自動化率が上がる)。

② cross-layer context

法定 6 要件 3 (取引内容) は、 「コーヒー注文」 「API 利用料」 みたいな人間可読のテキストで、 on-chain にも wallet registration にも乗らない。 これをどう取るか。

ここで前回までの伏線が回収されます。 paylog の Discovery 出力に乗っていた context envelope が、 yen402-mcp 経由で seller の x402 endpoint に渡り、 seller が yen402 facilitator の settle body に流し、 facilitator が Tagamie の webhook に同梱して送ってきます。

Tagamie はこの context の description を取引内容として、 service.name を相手方識別子として、 PDF に 転記 します。 推論や手入力ではなく、 上流の Discovery 層が知っていた情報をそのまま運んでくる、 という仕組みです。

詳しいパイプラインの話は次回 (シリーズ最終回) に。

確定ゲートと発行者責任

適格請求書の発行者責任は seller 本人にあります (消費税法 57 条の 4)。 「Tagamie が勝手に発行した」 では責任の所在が曖昧になります。

ここで Tagamie は 確定ゲート という設計を入れました:

月初 1 日 02:00 JST: cron で月次集計 → draft invoice 自動作成
                    (この時点では PDF 未生成、 buyer 側に未表示)
                              ↓
                    seller が dashboard で内容確認
                              ↓
                    1 クリック「確定・交付」
                              ↓
                    PDF 生成 (法定 6 要件) → SHA-256 hash →
                    Supabase Storage 保存 → buyer に通知

つまり「自動発行」 ではなく「自動 draft + 手動確定」 です。 seller の確定意思を技術設計レベルで強制することで、 発行者責任 を seller に明示帰属させます。

これは法令の建て付け (誰が発行者として責任を負うか) と code layer (実装の制約) を一致させようとした設計です。 弁護士確認はまだ取れていないので、 現時点はあくまで自分の読みです (オピニオン取得は Phase 0-C 予定、 後述)。 PDF が即時に出ると見栄えはいいですが、 法務的には「誰が発行したのか」 がぼやけるので、 1 クリック挟む方が強い構造だと考えています。

マイクロペイメントの一括インボイス化

Tagamie は 1 つの (seller, buyer) ペアで月内に発生した複数の JPYC transfer を、 月初 02:00 JST の cron でまとめて 1 通の適格請求書に集約します。 たとえば agent が 1 ヶ月で 80 回小額 (¥50, ¥120, ...) で x402 経由のマイクロペイメントを払ったら、 翌月 1 日に 1 通の invoice に 80 件の明細が並ぶ形で出る、 という挙動です。

これは Tagamie が「x402 マイクロペイメント特化」 として作ったのではなく、 月次の (seller, buyer) generic 集計を、 マイクロペイメント時代に当てはめた結果です (facilitator agnostic、 ただし現状 yen402 webhook 経由の集計を先行実装中、 Alchemy 直接 indexer への移行は Phase 1 残作業)。 税率別 split + ¥10,000 未満マークも同じ集計の中で扱います。

1 万円未満マーク

少額特例 (消費税法 30 条の 2) という、 1 万円未満の課税仕入については適格請求書の保存なしで仕入税額控除できる経過措置があります。 2023-10 から 2029-09-30 までの 6 年間限定です。

ここで重要なのは、 これは buyer 側の特例 で、 buyer が課税売上高 1 億円以下 / 特定期間 5,000 万円以下の事業者である場合に限る、 という条件付きです。 seller 側の自動判定はできません (buyer の課税売上高を seller は知らない)。

Tagamie は当初「少額特例自動判定」 という機能名で実装していましたが、 これは概念混在でした。 現在は 「1 万円未満マーク」 として再定義しています。 PDF と dashboard に「1 万円未満該当 N 件 (※)」 とマークが付き、 注釈で「買い手が課税売上高 1 億円以下の事業者の場合は少額特例で保存不要 (期限 2029-09-30)、 適用判断は買い手側」 と添えます。

判定主体を seller から buyer に正しく戻す、 という小さな修正ですが、 法律論的には大事な区別です。

電帳法との関係

2026/01 から電子帳簿保存法の宥恕措置が終了し、 電子取引データの電子保存が完全義務化されました。 これは Tagamie 構造と相性がよく:

  • PDF を Supabase Storage に保存 (改ざん不能ストレージ)
  • SHA-256 hash を DB 保存 (改ざん検知)
  • on-chain settle event を別途記録 (取引の真実性裏付け)

電帳法の「真実性 / 可視性 / 検索可能性」 の 3 要件を、 上記 3 つの保存方式で満たせる構造です。 「訂正・削除防止の事務処理規程」 と組み合わせて、 認定タイムスタンプ事業者を使わなくても電帳法要件を満たす建て付けにしています。

会計ソフト連携 (ロードマップ)

現状 Tagamie のアウトプットは、 適格請求書 PDF と dashboard 上のデータまでです。 その PDF を会計ソフトに取り込んで仕訳に起こす最後の一手は、 まだ利用者側に残っています。

ここを詰める拡張として、 freee などの会計ソフトへの自動仕訳投稿 も Tagamie のスコープに入れています。 発行済 invoice を API 経由で freee に売上仕訳として流し込む、 という連携です。 現時点では未実装で後続フェーズの項目という位置づけですが、 「on-chain 取引 → 適格請求書 → 会計ソフト」 を手作業ゼロで繋ぐところまでを射程にしています。

規制適合性のスタンス

Tagamie がカバーするのは以下:

  • 資金移動業 / 暗号資産交換業 / 電子決済手段等取引業 = すべて非該当の見込み (JPYC は預からない、 P2P 直接送金構造)
  • インボイス制度 = 適格請求書の自動発行 (seller 確定ゲート挟みで発行者責任明確)
  • 電帳法 = PDF + hash + Supabase で真実性要件カバー、 規程併用で運用要件カバー
  • 消費税法 57 条の 4 = 確定ゲートで発行者責任が seller に明示帰属

Phase 0-C で弁護士レターオピニオン 1 通取得を予定しています。 法務 layer の証跡として持っておくため。

privacy 普及シナリオへの設計余地 (stealth address)

Tagamie の moat の根幹は「両側 wallet 登録 + Alchemy 自動集計」 ですが、 これは on-chain transfer が public ledger 前提で成立する設計です。

法人が JPYC で B2B 取引する未来を素直に想像すると、 1 つアドレスを取引先に教えた瞬間に 全取引先・全金額・全残高が露出する という構造的問題に当たります。 「privacy 不要層」 はおそらく存在せず、 全セグメントが「守れるなら守りたい」 になるはずです。

ここで来る確度が高いのは stealth address (ERC-5564) — Ethereum で 2023 に標準化済の技術。 wallet が default 採用すると、 on-chain は「使い捨てアドレス間の transfer」 だらけになり、 amount は plaintext のままですが、 受取人がどの法人かは viewing key を持つ本人しか分からない状態になります。

ここで Tagamie の 1 entity = N wallets 設計が効きます。 stealth address 世界で生成される使い捨てアドレス群は、 受取人の viewing key で「これは法人 B 宛」 と復元できる。 つまり Tagamie の wallets table を viewing key registry に進化させれば:

  1. seller オンボード時に SIWE 認証 + viewing key 登録
  2. Alchemy webhook で stealth announcement を監視
  3. Tagamie が viewing key で復号 → seller B 宛と判明 → 集計
  4. 法定 6 要件 PDF 生成 (amount は public、 受領者は entity registry から)

「1 entity = N wallets」 という現在の registry 設計は、 「事前登録モデル」 から「key derivation モデル」 への自然な進化パスを内包しています。 stealth address 普及時にも自動集計 moat は維持され、 むしろ「stealth だらけの on-chain を法人別に集計できる」 = 素朴な集計屋にできない位置を取れます。

これは別世界の話ではなく、 yen402 で実装した「1 API key = N payTo allowlist」 も近い構造です。 mameta_zk さん打診経由で yen402 / dashboard に allowlist 化を入れた時、 同じ問題 (「1 法人が N アドレスを持つ世界をどう扱うか」) を facilitator 層で解いていました。 Tagamie の両側 wallet registry はその経理層版と言えます。

⚠️ 完全 privacy 系 (zkERC20、 amount + 受取人両方暗号化) が普及した場合は別問題で、 seller 確定ゲート時に proof key で reveal するモデルになります。 ただし zkERC20 は規制 (travel rule / 監査要件) + 発行体協力 + UX 障壁で普及確度は低く、 当面は stealth address 観測を優先します。

「Tagamie は public ledger 期にしか成立しない短期 product では?」 という質問が来そうですが、 答えは No。 entity ↔ wallets 1:N の registry 設計は、 privacy 機構 (stealth) の上に乗せても自然に動き、 むしろ「on-chain を法人別に解読する SaaS」 として価値が上がる、 と見ています。

次回予告: 4 つを線で繋ぐ

ここまで 4 回かけて、 paylog (Discovery)、 yen402 (決済)、 yen402-mcp (層間プロトコル)、 Tagamie (経理) を 1 つずつ書いてきました。

これらが「個別に並んでいる」 のではなく、 「ある特定の順序で繋がっている」 ことを次回でまとめます。 cross-layer context というものを各回でちょこちょこ匂わせてきましたが、 それが何のためにあって、 何を運んでいて、 どこから来てどこへ戻るのか。

これは「3 つの SaaS と 1 つの MCP server」 と言うより、 もう少し奇妙な構造をしている、 ということが見えてくる回です。

リポジトリ: github.com/Tagamie-Lab/Tagamie-apps (MIT)

※ Tagamie だけ別アカウント (Tagamie-Lab) に置いてあるのは、 個人事業主としての屋号 (Tagamie) で別組織アカウントを作成したためです。 他 3 プロジェクト (paylog / yen402 / yen402-mcp) は私個人 (kakedashi3) の管理下にあり、 身分・経理を分離して管理しています。

Discussion