• #Chrome拡張機能
  • #クラウド会計
  • #データ検証
  • #インポート機能
  • #UIデザイン
開発misc-devメモ

Chrome拡張クラウド会計連携 - エクスポート整合性検証と一括インポート機能

エクスポートデータに検証関数を3つ追加してテストを162から200に増やした後、一括インポート機能を一から組み上げ、UIを2回作り直した。朝はバリデーションのテストを黙々と書き、昼にインポートの骨格を通し、夕方からUIの設計方針を変えて「使い捨てURL方式」に着地するまでの記録。


エクスポートデータの整合性検証

3つの検証関数を lib.js に追加

エクスポート処理は動いていたが、壊れたデータがそのままスプレッドシートに流れ込むリスクがあった。行単位→ブロック単位→全体の3段階でバリデーションを入れた。

  • validateJournalRow: 仕訳1行の必須フィールド存在チェックと型チェック。借方・貸方金額が数値であること、日付フォーマットが正しいことを検証
  • validateJournalBlock: 仕訳ブロック(1取引を構成する複数行)の貸借一致を検証。借方合計と貸方合計が一致しなければエラー
  • validateExportData: エクスポート対象の全データを走査し、上記2つを順に呼び出す。エラーがあれば行番号と理由を配列で返す
// 貸借一致の検証(核心部分)
const validateJournalBlock = (rows) => {
  const debitSum = rows.reduce((s, r) => s + (r.debit || 0), 0);
  const creditSum = rows.reduce((s, r) => s + (r.credit || 0), 0);
  return Math.abs(debitSum - creditSum) < 0.01
    ? { valid: true }
    : { valid: false, reason: `貸借不一致: 借方${debitSum} / 貸方${creditSum}` };
};

テスト 162 → 200

検証関数のテストを38件追加。正常系(全フィールド揃い、貸借一致)だけでなく、金額が文字列で入ってくるケース、日付が空のケース、貸借が1円ずれるケースなど、前日までに踏んだ型の罠をそのままテストケースに変換した。200件全パス。


事業者データ一括取得の進捗表示改善

複数事業者のデータを順繰りに取得する処理で、進捗表示が「処理中...」としか出ていなかった。5社あるうちの3社目で止まっているのか、1社目で詰まっているのか分からない。

N/M 形式に変更して、「3/5 社目を処理中」のように表示するようにした。content.jsのDOM更新箇所は1行の変更で済んだが、lib.js側でコールバックを受け取れるようにシグネチャを修正する必要があった。


一括インポート機能の初期実装

lib.js に新関数を追加

エクスポートの逆方向。スプレッドシートから仕訳データを読み取り、会計サービスのインポート用CSVフォーマットに変換してアップロードする流れを組んだ。

主要な関数:

  • fetchSheetData: Sheets APIで指定範囲のデータを取得
  • transformToMfCsv: スプレッドシートの列構造を会計サービスのインポートCSVの列順に変換。勘定科目コードのマッピングもここで処理
  • uploadImportCsv: 会計サービスのインポートエンドポイントにCSVをPOST

content.jsにはインポートパネルのUIを追加。この時点ではシンプルなテキストボックス1つとボタン1つの構成だった。

テストは既存200件に追加分を入れて全パス。


インポートパネルUIの大幅リデザイン

最初のUIの問題

シンプルに作った最初のUIは、スプレッドシートURLを設定テーブルに永続保存する方式だった。しかし実際に使ってみると問題が見えた。インポートは月に1回程度の作業で、URLも毎回変わることがある。永続保存する意味が薄い上に、古いURLが残っていると誤ったデータを取り込むリスクがある。

「使い捨てURL方式」への転換

URLを永続化せず、インポートパネルを開くたびに空のURL入力欄を表示する方式に切り替えた。パネルを閉じればURLは消える。

新しいUIの構成

インポートパネル
┌──────────────────────────────────────┐
│ 年度選択:  ○ 2023  ○ 2024  ● 2025  │
├──────────────────────────────────────┤
│ 事業者A  [スプレッドシートURL入力欄]  │
│ 事業者B  [スプレッドシートURL入力欄]  │
│ 事業者C  [スプレッドシートURL入力欄]  │
├──────────────────────────────────────┤
│ [一括インポート実行]                  │
│ 進捗: 2/3 社目を処理中...            │
└──────────────────────────────────────┘

設計のポイント:

  • 全事業者を一覧表示: エクスポート側と同じく、登録済み事業者を全て並べる。インポートしない事業者はURL欄を空のままにすればスキップされる
  • 年度はラジオボタンで単一選択: インポートは1年度ずつ確認しながら進めたい。複数年度を一気にインポートすると、途中でエラーが出たときの切り分けが面倒になる
  • 事業者ごとのURL入力欄: インポート元のスプレッドシートは事業者ごとに異なる。URLが入っている事業者だけを対象に順繰り処理する
  • 進捗表示: エクスポート側と同じ N/M 形式

仕訳インポートCSVサンプルフォーマットへのリンク

インポート時に会計サービスが期待するCSVフォーマットを確認できるよう、サンプルフォーマットのダウンロードリンクを追加した。会計サービスの内部URL /imports/mf_journals/sample_format にCTI(事業者コンテキスト)パラメータを付けてリンクする。事業者ごとにCTIが異なるため、各事業者の行にリンクを配置した。


設定テーブルのUI改善議論

エクスポート・インポートの両方でスプレッドシートURLを扱うようになり、設定テーブルが横に長くなってきた。特にスプレッドシート名称(「2025年度_仕訳帳_事業者A」のような長い文字列)がテーブルを圧迫する。

名称をツールチップに逃がしてURLだけ表示する案、名称を15文字で切って末尾に「...」を付ける案などを検討した。この日は方針を決めるところまでで、実装には入っていない。


振り返り

一日の流れを並べると、「壊れたデータを検知する仕組みを作る → 逆方向の機能を組む → UIを実際に触って設計を変える」という段階を踏んでいた。検証関数を先に作ったのは正解で、インポート機能の開発中にバリデーションの考え方をそのまま転用できた。

UIを2回作り直すことになったのは無駄に見えるが、最初のシンプル版を実際に触ってみなければ「URLを永続化する必要がない」という判断には至らなかった。手を動かしてプロトタイプを触り、違和感に気づいてから設計を変える方が、机上で完璧なUIを考え続けるより速く正解にたどり着く。