Chrome拡張 会計ソフト連携 - statusCallback未渡しバグ修正・インポート検証強化・繰越処理API調査

会計ソフトAのChrome拡張で仕訳インポートを実行したら、進捗表示が一切動かなかった。ステータスバーが「処理中...」のまま固まり、でもネットワークタブを覗くとリクエスト自体は飛んでいる。原因を追うと、コールバック関数の渡し忘れが4箇所見つかった。そこから芋づる式にインポートのレスポンス検証不足、繰越処理APIの調査へと一日が流れた。

statusCallback未渡しバグの発見と修正

症状: 進捗表示が動かない

仕訳インポートの一括処理を走らせたとき、ポップアップUIの進捗バーが0%のまま止まっていた。コンソールにエラーは出ない。リクエストは正常に飛んで200が返ってくる。処理自体は走っているのに、UIだけが更新されない。

原因の特定

switchAndConfirmCti関数のシグネチャを確認すると、第3引数にstatusCallbackを受け取る設計になっている。呼び出し元を洗い出すと、4箇所中4箇所すべてで第3引数が省略されていた。

// Before: statusCallbackを渡し忘れ
await switchAndConfirmCti(page, targetCti);

// After: 第3引数にコールバックを渡す
await switchAndConfirmCti(page, targetCti, statusCallback);

コールバックがundefinedで入ってきても関数内部でstatusCallback?.()のようにオプショナルチェーンで呼んでいたため、エラーにならず黙って握りつぶされていた。エラーが出ないバグは発見が遅れる。4箇所すべてに第3引数を追加して修正完了。

教訓

オプショナルチェーンは安全だが、必須のコールバックまでオプショナルにすると「動いているのに何も起きない」状態になる。今後、進捗系のコールバックは引数から落ちたらTypeScriptの型で弾けるようにしたい。

仕訳インポートのレスポンス検証不足

症状: 「完了」と表示されるがデータが入っていない

statusCallbackの修正後、インポート処理は進捗表示も含めて最後まで走るようになった。ステータスが「完了」と表示される。しかし会計ソフトA側で仕訳帳を開くとデータが入っていない。

Chrome DevToolsで実機検証

DevToolsのNetworkタブでインポートリクエストのレスポンスを確認した。HTTPステータスは200。ここで「200だから成功」と判定していたのが問題だった。

レスポンスのHTMLボディを覗くと、alert-dangerクラスのdivが入っている。会計ソフトAのインポートAPIは、バリデーションエラーでもHTTP 200を返し、エラー情報をHTML内のアラートクラスで返す設計だった。

修正: HTML内のアラートクラスを検証

レスポンスHTMLをパースして、alert-dangerとalert-successの存在をチェックするようにした。

• alert-successが含まれる → インポート成功
• alert-dangerが含まれる → インポート失敗、アラート内のテキストをエラーメッセージとして表示
• どちらもない → 不明な状態としてワーニング

HTTPステータスだけでなく、レスポンスボディの中身まで見に行く必要がある。REST APIであればステータスコードで判定できるが、フォーム送信ベースのWebアプリはHTMLの中にエラーを埋め込んでくることがある。

繰越処理APIの調査

背景

複数事業者の年度末繰越処理を手作業で回すのは面倒で、自動化したかった。Chrome DevToolsで繰越処理の通信を傍受してAPIの構造を把握した。

エンドポイント

POST /term/close?cti={cti}

リクエストボディにterm[journal_lock]=0を含めると、仕訳制限なしで繰越が実行される。ctiは事業者と年度を特定するIDで、既に他のエクスポート処理で取得済みの値がそのまま使える。

繰越処理の前提条件

DevToolsで繰越画面の挙動を追いかけた結果:

• 繰越前に仕訳帳の貸借一致チェックが走る（ここで不一致があると繰越不可）
• 繰越実行後、新年度のctiが発行される
• 旧年度のctiは閲覧専用になる

一括自動化の計画策定

調査結果をもとに、複数事業者の繰越を一括で自動実行する計画を策定した。

フロー:

1. 事業者一覧から繰越対象を抽出
2. 各事業者のctiを使って/term/closeをPOST
3. レスポンスのHTML内でエラーがないか検証（インポートと同じパターン）
4. 成功した事業者と失敗した事業者をレポートとして出力

Codexレビューにかけて計画を確認。エラーハンドリングの粒度と、繰越失敗時のロールバック手段について指摘を受けた。繰越にはロールバックAPIが存在しないため、実行前の確認ステップを厚めに入れる方針で着地した。

add-taskスキルのJSON生成バグ修正

症状: タスク登録が失敗する

計画をGoogleタスクに登録しようとしたら、JSON解析エラーで落ちた。Windows環境固有の問題だった。

原因

add-taskスキルは内部でcat <<HEREDOCを使ってJSONを生成していた。Windowsのファイルパスに含まれるバックスラッシュ（C:\Users\...）が、HEREDOCの中でJSONのエスケープシーケンスと衝突する。\Uが\u（Unicodeエスケープ）として解釈されてしまう。

# 生成されるJSON（壊れる）
{"title": "C:\Users\numbe\..."}  
# \U がUnicodeエスケープと衝突

修正: Python生成方式に変更

HEREDOC方式を捨てて、Pythonのjson.dumps()でJSONを生成するように書き換えた。Pythonの文字列リテラルではバックスラッシュが適切にエスケープされるため、Windowsパスが含まれていても壊れない。

Windows環境でシェルスクリプトからJSONを生成するときは、HEREDOCを避けてプログラミング言語のJSON生成関数を使う方が安全。この手の環境依存バグは、macOSでは再現しないので見つけにくい。

一日の振り返り

statusCallbackの渡し忘れから始まって、インポートのレスポンス検証、繰越APIの調査まで、1つのバグが次の課題を掘り起こす一日だった。進捗バーが動かない原因を追いかけたら、インポート成功の判定ロジックに穴が見つかり、そこを直したら「次は繰越も自動化したい」という欲が出てきた。

HTTP 200でもエラーを返すAPIパターンは、フォームベースのWebアプリでは珍しくない。ステータスコードを信じず、レスポンスボディの中身まで検証する習慣を染み込ませたい。

add-taskのHEREDOCバグは、Windows環境でのシェルスクリプトあるあるとして記憶に刻んでおく。バックスラッシュが2つの文脈で意味を持つ場面では、シェルに任せずプログラミング言語のJSON生成に逃がす。