クラウド会計公開APIの棚卸しと自動仕訳ルール戦略
公開APIのドキュメントを端から端まで読んで、欲しいエンドポイントが3つとも存在しないことを確認した。そこからChrome DevToolsのNetworkタブに切り替え、内部APIを1つずつ掘り当てていった。最終的に「自動仕訳ルールをクラウド会計サービスに置かず、ローカルGitで管理する」という方針にたどり着くまでの記録。
公開APIの壁：3つの不在
クラウド会計サービスの確定申告機能の公開API（v3）で、以下3つのデータが取得できるか調査した。結果は全滅。
未登録明細（仕訳化前の取引データ）
公開APIのスコープ一覧を確認すると、transaction.read というスコープ自体が存在しない。仕訳（journals）は取得できるが、仕訳化される前の「未登録明細」にアクセスする手段がない。
競合サービスには wallet_txns API（明細の取得・作成）があり、対照的だった。
連携明細（銀行・Amazon等のデータ）
銀行口座やAmazonなどの外部サービスから自動取得されたデータ。これも公開APIにエンドポイントがない。Chrome拡張では、会計サービスのHTML画面をスクレイピングして取得している。
自動仕訳ルール
仕訳を自動生成するためのルール管理機能。公開APIにCRUD操作は一切なし。
内部APIの発掘
公開APIに存在しないなら内部APIを探すしかない。Chrome DevToolsのNetworkタブでクラウド会計サービスの画面を操作しながら、飛んでいるリクエストを片っ端から確認した。
自動仕訳ルールのエンドポイント
自動仕訳ルール画面で検索操作をすると、以下のリクエストが飛ぶのを捕まえた。
POST /api/v1/office_journal_rules/search
レスポンスはJSON形式で、ルールの条件（摘要のキーワード、金額範囲）と適用する勘定科目・補助科目がセットで返ってくる。
もう1つ、CSVエクスポートも発見。
GET /journal_rules.csv
こちらはブラウザでそのままダウンロードできる。JSON APIとCSVの両方が使えるので、用途に応じて使い分けられる。
journalizing_configurations
仕訳化の設定に関するエンドポイントも見つけた。自動仕訳ルールとは別に、連携サービスごとの仕訳化設定を管理しているようだ。
Chrome拡張での実装パス
内部APIの呼び出しパターンは既にChrome拡張に実装済みの fetchMfApi 関数でカバーできる。会計サービスのセッションCookieを使って内部APIを叩き、レスポンスをパースしてスプレッドシートに書き込む流れ。
自動仕訳ルールの取得は、このパターンにそのまま載る。
// 既存パターンと同じ流れ
const rules = await fetchMfApi('/api/v1/office_journal_rules/search', {
method: 'POST',
body: JSON.stringify({ /* 検索条件 */ })
});
// → Google Sheets APIでスプレッドシートに書き込み
ローカルGit管理戦略
調査の過程で、自動仕訳ルールをどこに置くかという設計判断に至った。
クラウド会計サービス側に置かない理由
会計ソフトに蓄積したルールは、そのソフトへのロックインになる。税理士がクライアントの会計ソフトを切り替える場面では、ルールの移行コストが障壁になる。ルールを会計ソフトの外に持ち出しておけば、ソフトを切り替えてもルール資産が残る。
構想：ルールをGitリポジトリで管理
- ルールの取得: Chrome拡張で会計サービスの内部APIからルールをJSON/CSVで取得
- ローカル保存: GitリポジトリにYAMLまたはJSON形式でコミット
- Claude Codeが参照・更新: ルールファイルをコンテキストとして読み、新しい明細に対して適切なルールを提案
- 会計サービスへの反映: 必要に応じてChrome拡張経由で会計サービスに書き戻す
ルールの実体がGitにあるので、変更履歴が残り、ブランチで実験もできる。
仮勘定消し込みフローの構想
さらに踏み込んだ構想として、以下のフローを検討した。
- 未登録明細を全件取得し、まず全て「仮払金」で自動仕訳登録
- 領収書・請求書とのマッチングを実行
- マッチした明細を正しい勘定科目で消し込み（仮払金→実際の費目に振替）
これなら「未登録明細がいつまでも溜まる」問題を回避しつつ、正確な仕訳は後から確定できる。ただし仮払金が大量に積み上がる中間状態をどう管理するかは課題として残る。
内部APIの棚卸し結果
今回の調査で判明した「公開APIにないが内部APIで取得可能」なデータを、Chrome拡張のロードマップドキュメント（api-inventory-and-roadmap.md）に記録した。
| データ | 公開API | 内部API | Chrome拡張の実装状況 |
|---|---|---|---|
| 仕訳帳 | あり | あり | 実装済み |
| 勘定科目マスタ | あり | あり | 実装済み |
| 連携明細 | なし | HTMLスクレイピング | 実装済み |
| 未登録明細 | なし | 要調査 | 未実装 |
| 自動仕訳ルール | なし | あり（JSON/CSV） | 未実装 |
| 仕訳化設定 | なし | あり | 未実装 |
振り返り
公開APIのドキュメントを1時間読んで「ない」と確認するところから始めて、DevToolsのNetworkタブで内部APIを1つずつ拾い上げ、最後に「そもそもルールをどこに置くか」という設計判断にたどり着いた。
公開APIの不在は制約だが、内部APIが叩ける以上、Chrome拡張という既存の橋がそのまま使える。仕訳ルールをGitに持ち出す構想は、会計ソフトへの依存を1段下げる手段として筋が通っている。次のステップは、実際にルール取得をChrome拡張に組み込んで、JSONをリポジトリにコミットするところまで動かすこと。