• #Chrome DevTools MCP
  • #クラウド会計
  • #API解析
  • #自動化
  • #React
開発misc-devアクティブ

クラウド会計 未登録明細の一括自動登録 調査記録

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件の明細がそのまま登録された。手が止まった。

ここからリカバリ手順の調査に切り替えた。結果として、明細のステータス遷移サイクルを実地で確認できた。


明細ステータスの遷移サイクル

調査の結果、明細は以下のサイクルで遷移することが分かった。

未入力 → 取引完了 → 対象外 → 未入力

遷移の詳細

  1. 未入力 → 取引完了: 登録APIを呼ぶと遷移
  2. 取引完了 → 対象外: 登録済み仕訳を削除すると「対象外」に移動(「未入力」には戻らない)
  3. 対象外 → 未入力: 「未入力に戻す」操作で復元

誤登録した5件は、仕訳を削除して「対象外」にした後、「未入力に戻す」で元の状態に復元できた。データは消えていなかった。

テスト時のリカバリフロー

自動登録の開発中、テストデータを元に戻す手順:

  1. 登録済み仕訳を削除(対象外に遷移)
  2. 対象外タブで該当明細を選択
  3. 「未入力に戻す」を実行

この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エンドポイント、必須ヘッダー、ステータス遷移、リカバリ手順が揃ったので、次回は実装に手を付けられる。