会計サービス内部APIリファレンス作成とビジネスモデル調査
Chrome拡張の会計サービス連携で蓄積してきたAPI知識を、全13セクションのリファレンスドキュメントにまとめた。その過程で勘定科目マスタのAPI取得、年度切替の仕様検証、公式API（v3）の制限調査に手を広げ、最終的に会計サービスのビジネスモデル構造を掘り下げることになった一日の記録。
内部APIリファレンスの整理
これまでChrome拡張の実装過程でバラバラに発見してきた会計サービスの内部APIを、1つのドキュメントに集約した。全13セクション構成。
- 認証とセッション管理
- リクエストヘッダー
- CSRFトークン取得
- 仕訳API（journals）
- 連携明細API
- 勘定科目マスタAPI
- 補助科目API
- 税区分API
- 口座API（walletables）
- 部門API
- 事業者管理（offices/CTI）
- 年度切替（TID/PATCHリクエスト）
- CSVエクスポートAPI
DevToolsのNetworkタブで拾い集めた断片を、エンドポイント・リクエスト形式・レスポンス例・注意点の4点セットで記述した。特にCSRFトークンの取得方法やRails UJSのPATCH擬似リクエストなど、ハマりどころは実際のコード例を添えた。
勘定科目マスタをAPI経由でスプレッドシートに書き出す
勘定科目・補助科目・税区分がすべて内部APIで取得できることを確認し、会計サービスのCSVエクスポートと同じ列構成でスプレッドシートに書き出した。
CSVエクスポートの列構成
会計サービスから手動エクスポートしたCSVは9列構成になっている。
| 列 | 内容 |
|---|---|
| 帳票 | BS/PL |
| 分類 | 資産・負債・収益・費用など |
| 決算書科目 | 決算書上の表示名 |
| 勘定科目 | 実際の科目名 |
| 補助科目 | 補助科目名（空の場合あり） |
| 税区分 | 課税区分 |
| 検索キー | 科目の検索用キー |
| 使用 | 使用中かどうか |
| 並び順 | 表示順 |
gws CLIスキルを使い、166行×9列をGoogle Sheetsに一括書き込みした。APIレスポンスのJSON構造とCSVの列構成の対応関係を整理しながらマッピングを組んだ。
年度切替の仕様を検証して躓く
ここで一つ、想定外の挙動にぶつかった。
日付範囲指定で年度を跨げるか試す
仕訳APIにfrom_dateとto_dateを渡せば、年度をまたいでデータが取れるのではないか――そう考えて2024年度の日付範囲を指定してリクエストを送った。
GET /api/v1/journals?from_date=2024-04-01&to_date=2025-03-31
返ってきたのは2025年度のデータだった。日付パラメータを無視して、セッションの現在年度のデータだけが返る。何度パラメータを変えても結果は同じ。
年度切替PATCHが必須という結論
この挙動を見て腑に落ちた。会計サービスの内部APIはセッションに紐づいた事業者年度（CTI/TID）のコンテキスト内でしか動作しない。日付範囲でフィルタはできるが、年度の壁は越えられない。
つまり2024年度のデータが欲しければ、先にPATCHリクエストで年度を2024年度に切り替え、その後にデータ取得APIを叩く必要がある。「パラメータで何とかなるだろう」という楽観は通用しなかった。
公式API（v3）の制限を調べる
内部APIの調査と並行して、会計サービスの公式API（v3）がどこまで使えるのかも調べた。
仕訳APIは「会計Plus」限定
結論から書くと、公式v3 APIの仕訳エンドポイントは「会計Plus」プランでしか利用できない。会計Plusは上場企業やIPO準備企業を対象としたプランで、料金は要問合せ（公開されていない）。
一般的なプランでの位置づけ:
| プラン | 月額（税抜） | 仕訳API |
|---|---|---|
| パーソナルミニ | 1,280円 | 使えない |
| パーソナル | 1,680円 | 使えない |
| パーソナルプラス | 3,280円 | 使えない |
| 法人スモールビジネス | 4,378円 | 使えない |
| 法人ビジネス | 6,578円 | 使えない |
| 法人ゴールド | 約24万円/年 | 使えない |
| 法人プラチナ | 約50万円/年 | 使えない |
| 会計Plus | 要問合せ | 使える |
ゴールド（年24万円）でもプラチナ（年50万円）でも仕訳APIは開放されない。会計Plusだけが別枠になっている。公認メンバー制度のランク特典（ゴールド・プラチナ・ダイヤモンド）とは完全に独立した枠組みだった。
配布リスク評価
Chrome拡張として内部APIを叩くツールをどう配布するか。リスクを整理した。
Chromeウェブストア公開のリスク
Chromeウェブストアに公開すると、会計サービスの利用規約に抵触する可能性がある。内部APIへのアクセスは正式にサポートされた利用方法ではないため、公式から指摘を受ければ取り下げざるを得ない。ストアの審査プロセスでも引っかかる可能性がある。
ZIP配布+開発者モードという現実解
ZIPファイルで配布し、利用者に開発者モードでインストールしてもらう方式であれば、ストア審査を経由しないため現実的に問題が起きにくい。導入時にサポートが必要になるが、そこは時間単価でカバーする形が妥当。
会計サービスのビジネスモデル構造を読み解く
APIの調査を進めるうちに、「なぜこの会計サービスはUIの改善が遅いのか」「なぜAPIを閉じているのか」という疑問が浮かんだ。決算資料を読み込んで見えてきた構造がある。
UIの不便さはバグではなく設計
会計サービスの確定申告・記帳まわりのUIが改善されないのは、技術力が足りないからではない。仕訳の一括操作、明細の柔軟なフィルタ、APIの開放――技術的にはどれも実装可能なはずだが、意図的に閉じている。
理由はアップセル構造にある。基本プランで不便を感じたユーザーが上位プランへ移行する、あるいは税理士に依頼する。その税理士が会計サービスの公認メンバーとして契約している。不便さがビジネスの駆動力になっている。
ユーザー側プランと税理士側プランは別世界
会計サービスのプラン体系を整理してみると、2つの全く異なる軸が見えた。
ユーザー（事業主）側のプラン:
- パーソナルミニ / パーソナル / パーソナルプラス
- 法人スモールビジネス / 法人ビジネス
- 機能制限でアップセルを促す構造
税理士側のプラン:
- 公認メンバー制度（ゴールド / プラチナ / ダイヤモンド）
- 記帳代行プラン（月額固定で顧問先のデータを管理）
- 顧問先数に応じた従量課金
この2軸が独立して存在し、それぞれ別の営業チームが別のKPIで動いている。ユーザーが感じる「UIの不便さ」は、税理士チャネルへの導線として機能している。
競合サービスとの比較調査
会計サービスの構造が見えたところで、対照として競合サービスのプラン体系も調べた。
競合サービスはAPIを公開している
当該会計サービスとの最大の違いは、競合サービスが公式APIを広く公開している点。競合サービスのAPIは無料プランでも仕訳の読み書きができる。開発者向けドキュメントも整備されており、エコシステムを広げる方針が明確に見える。
プラン体系の違い
競合サービスも個人向け・法人向け・税理士向けの3軸があるが、APIの開放度が根本的に異なる。当該会計サービスが「閉じて囲い込む」戦略なのに対し、競合サービスは「開いてエコシステムで囲い込む」戦略を採っている。どちらが正しいかではなく、ビジネスモデルの設計思想が違う。
損益分岐点の試算
税理士側の記帳代行プランについて、月額固定プランと個別契約のミックスでどこが分岐点になるかを試算した。具体的な数字は省略するが、顧問先の件数と1件あたりの仕訳量によって最適な契約形態が変わる。固定プランは仕訳量が多い顧問先が集中すると割安になり、少量の顧問先が多いと個別契約のほうが有利になる。
振り返り
一日かけて、散在していた会計サービス内部APIの知識を1つのリファレンスにまとめ、その過程で会計サービスのビジネスモデル全体像を掘り下げた。
年度切替の検証で「日付パラメータを指定すれば年度をまたげるだろう」と甘く見て、返ってきたデータを見て手が止まった瞬間が一番の学びだった。会計サービスの内部APIはセッションの年度コンテキストに強く依存しており、パラメータだけでは壁を越えられない。この仕様を理解していないと、Chrome拡張で過去年度のデータ取得を実装するときに確実にハマる。
公式API（v3）の仕訳エンドポイントが会計Plus限定という制限も、ビジネスモデルを理解すると納得がいく。APIの開放は「便利になる」と同時に「上位プランへの移行動機を失わせる」。この会計サービスはそのトレードオフで後者を選んでいる。競合サービスが逆の選択をしていることも含め、会計SaaS2社の戦略の違いが鮮明に見えた一日だった。