クラウド会計 未登録明細の一括自動登録 調査記録
Chrome DevTools MCPでクラウド会計の「連携サービスから入力」画面を開き、DOM構造・APIリクエスト・ステータス遷移を一つずつ掘り下げた。確認ダイアログを誤ってAcceptして本番データを触ってしまう場面もあったが、そのおかげでリカバリ手順まで含めた全体像を掴めた。
画面構造の把握: React + CSSモジュール
DevToolsでDOMツリーを開くと、/transaction_journals 画面はReactコンポーネントとCSSモジュールで構成されていた。クラス名にハッシュが付く styles_xxx__yyy 形式で、セレクタでの要素特定にはdata属性やARIAロールを併用する必要がある。
テーブルの各行は「未登録明細」を表し、行をクリックすると展開フォームが開く。ここで2種類の「登録」ボタンが存在することに気づいた。
2つの「登録」ボタン
| ボタン | 場所 | 挙動 |
|---|---|---|
| 通常行の「登録」 | テーブル行の右端 | 推定された勘定科目でそのまま即時登録 |
| 展開フォームの「登録」 | 行展開後のフォーム内 | 勘定科目・補助科目・税区分を編集してから登録 |
一括登録のチェックボックスを選択して「一括登録」を押すと、確認ダイアログが出現する。この後の挙動をNetworkタブで追った。
APIキャプチャ: 個別登録API
Networkタブでリクエストを捕捉すると、個別登録は以下のエンドポイントを叩いていた。
POST /api/v1/account_transactions/{transactionId}/journalize
Content-Type: application/json
ヘッダー
CSRFトークンとバージョン情報が必須:
X-CSRF-Token: {token}
X-MF-Version: {version}
リクエストボディ
{
"journal_candidate_id": "...",
"sub_account_item_id": "...",
"tax_category_code": "..."
}
journal_candidate_id はサーバー側が推定した仕訳候補のIDで、展開フォームで勘定科目を変更すると別のIDに差し替わる。sub_account_item_id は補助科目、tax_category_code は消費税区分を指す。
一括登録の実体
一括登録ボタンを押しても、裏側では個別APIを順次呼び出しているだけだった。Networkタブに journalize リクエストが選択件数分並ぶのが見えた。バッチAPIは存在しない。
確認ダイアログの誤Accept
一括登録の確認ダイアログ構造を調べようとして、DevTools MCPの dialog_action でAcceptを送ってしまった。テスト用に選択していた5件の明細がそのまま登録された。手が止まった。
ここからリカバリ手順の調査に切り替えた。結果として、明細のステータス遷移サイクルを実地で確認できた。
明細ステータスの遷移サイクル
調査の結果、明細は以下のサイクルで遷移することが分かった。
未入力 → 取引完了 → 対象外 → 未入力
遷移の詳細
- 未入力 → 取引完了: 登録APIを呼ぶと遷移
- 取引完了 → 対象外: 登録済み仕訳を削除すると「対象外」に移動(「未入力」には戻らない)
- 対象外 → 未入力: 「未入力に戻す」操作で復元
誤登録した5件は、仕訳を削除して「対象外」にした後、「未入力に戻す」で元の状態に復元できた。データは消えていなかった。
テスト時のリカバリフロー
自動登録の開発中、テストデータを元に戻す手順:
- 登録済み仕訳を削除(対象外に遷移)
- 対象外タブで該当明細を選択
- 「未入力に戻す」を実行
この3ステップで元に戻せるため、テスト→リセットのサイクルを回せる。
勘定科目マスタ
API経由の取得
勘定科目のID解決には fetchJournalMasters() を使う。このAPIは勘定科目・補助科目・税区分のマスタデータを一括で返す。Chrome拡張側では既に実装済みで、登録APIのボディに渡すIDをこのマスタから引く。
CSV経由のエクスポート/インポート
勘定科目の一覧は、会計ソフト標準機能でCSVエクスポート・インポートできる。勘定科目体系のバックアップや、別事業者への横展開に使える。
未調査: 補助科目の作成API
補助科目をAPIで新規作成する方法はまだ調べていない。画面上では手動追加できるが、自動登録フローに組み込むなら作成APIが必要になる。次回の調査対象。
次回セッション向けの実装計画
- 一括登録フローの実装: 未登録明細の取得 → 勘定科目マッピング → 順次journalize API呼び出し
- CSRFトークンの取得方法を確立(ページDOM or cookieから抽出)
- エラーハンドリング: 途中で失敗した場合のリトライ・ロールバック戦略
- 補助科目の作成API調査
- 勘定科目マッピングルールの設定UI(どの明細パターンにどの科目を割り当てるか)
振り返り
DevTools MCPで画面を操作しながらNetworkタブを監視する方法で、ドキュメントのないAPIの構造を一通り抜き出せた。確認ダイアログの誤Acceptで一瞬背筋が冷えたが、仕訳削除→対象外→未入力に戻すという3ステップで復元できることを身をもって確認した。APIエンドポイント、必須ヘッダー、ステータス遷移、リカバリ手順が揃ったので、次回は実装に手を付けられる。