DevTools MCPでクラウド会計APIを直接操作
Chrome拡張の依存度を下げたいという議論から始まり、「そもそも拡張なしでAPIを叩けるのでは」という仮説を検証した。結論から言うと、DevTools MCPの evaluate_script でCSRFトークンを取り出し、会計サービスの内部APIを直接叩いてテスト事業者の全帳簿データを取得できた。Chrome拡張は一切使っていない。
発端: 3種類のトークンを整理する
Chrome拡張とDevTools MCPの役割分担を議論するうちに、「CSRFトークンとOAuthトークンの違いは？」という質問に即答できず手が止まった。話を進めるにはまず認証の仕組みを図に起こす必要があった。
- CSRFトークン: Rails UJSがmetaタグに埋め込む。同一セッション内のPOST/PATCH/DELETEリクエストで必要
- OAuthアクセストークン: 公式API（v3）用。外部アプリ連携のBearerトークン
- リフレッシュトークン: アクセストークンの更新用。長寿命
SVGを5つ作成してトークンのライフサイクルと取得フローを図にした。この整理で「DevTools MCPはCSRFトークンさえ取れれば内部APIを叩ける」という道筋が見えた。
核心: evaluate_scriptでCSRFトークンを取得する
DevTools MCPの evaluate_script は、開いているページ上で任意のJavaScriptを実行できる。つまりmetaタグからCSRFトークンを読み取るのは1行で済む。
document.querySelector('meta[name="csrf-token"]').content
取得したトークンを X-CSRF-Token ヘッダーに載せてfetchすれば、ブラウザのセッションCookieが自動で付与される。Chrome拡張のcontent script → background script → API呼び出しという3段リレーが丸ごと消える。
実験: テスト事業者の全帳簿データを取得
テスト事業者（個人・2025年度）を対象に、6種類の帳簿データを取得してスプレッドシートに転記した。
仕訳帳: REST APIで取得
最初にハードコードした期間（2025-01-01〜2025-12-31）で取得したところ、開始仕訳しか返ってこなかった。「データが少なすぎる」と首をひねってよく見ると、この事業者は2月決算だった。会計年度が2025-03-01〜2026-02-28。
期間を修正して再取得し、83件の仕訳が返ってきた。REST APIのレスポンスをパースしてスプレッドシートに流し込む処理は、拡張で使っていたロジックをほぼそのまま移植できた。
残高試算表: URLの推測ミスと拡張コードの見落とし
残高試算表はAPIではなくHTMLページのスクレイピングで取得する方式。URLを推測して叩いたが404が返った。
30分ほどURLパターンを試行錯誤した後、ふと拡張のソースコード export.js を開いたら、正しいURLがそのまま書いてあった。拡張コードは8割リファレンスとして使えるのに、それを見ずに推測で突っ走ったのは反省点。
正しいURLでページを取得し、HTMLテーブルをパースして転記した。
月次推移・年次推移: 同じパターンの繰り返し
月次推移（補助科目あり/なし）と年次推移（補助科目あり/なし）も、残高試算表と同じ「ページスクレイピング」方式。URLの構造が似ていたので、残高試算表での反省を踏まえて最初から拡張のコードを開いた。URLを一発で当てて、4帳簿とも1回の試行で転記まで完了した。
連携明細: サービス一覧の壁
連携明細はサービス一覧ページからデータを取得する方式。テスト事業者は6口座が登録されていたが、取得できたのは3口座のみだった。
原因を調べると、設定用のJSONレスポンスにサービス一覧の全件が含まれていなかった。ページネーションか別エンドポイントがあるはずだが、今回は深追いせずに残り3口座は保留とした。
Chrome拡張 vs DevTools MCP: 比較ドキュメントを作成
実験結果を踏まえて、両者の比較をまとめた。
| 観点 | Chrome拡張 | DevTools MCP |
|---|---|---|
| データ受け渡し | content script→background script→API。3段のメッセージパッシング | evaluate_scriptで直接取得。中継なし |
| 環境構築 | npm install、ビルド、拡張インストールが必要 | Chromeをデバッグモードで起動するだけ |
| Windows環境 | ビルドツールチェーンの問題が出やすい | 環境依存が少ない |
| 自動化 | バックグラウンドで実行可能 | ブラウザが前面に必要 |
| テスト | Jest/Vitestで単体テスト可能 | テストの仕組みは自前で用意 |
結論として、「対話的に帳簿データを引っ張ってくる」用途にはDevTools MCPのほうが軽い。一方で、定期実行やバッチ処理にはChrome拡張のほうが向いている。
ランブック整備と次のステップ
次回すぐ同じ操作を再現できるよう、手順書（ランブック）を作成した。Chromeのデバッグモード起動、DevTools MCPへの接続、CSRFトークン取得、各帳簿のエンドポイントとパラメータを一通り記載。
Playwright + 別プロファイル方式の検討
DevTools MCPはブラウザを手動で開く必要があるが、Playwrightなら別プロファイルでブラウザを起動してプログラマティックに操作できる。通常使用中のプロファイルのロックファイルと競合しないため、「作業しながらバックグラウンドでデータ取得」が実現できる可能性がある。ただし今回は検証まで至らず、次回の宿題として残した。
振り返り
- 拡張のコードは8割リファレンス: URLパターン、パラメータ構造、レスポンスの加工ロジックがそのまま使える。推測で動く前にまず拡張のコードを読む、というのを習慣にしたい
- 会計年度のハードコードは罠: 1月〜12月と決め打ちしていた。事業者の決算月は設定APIで取得してから期間を組み立てるべき
- 設定JSONに全件が入っていない問題: 連携明細の口座漏れは、拡張でも同じ問題を踏む可能性がある。ページネーション or 別エンドポイントの調査が必要
- DevTools MCPで試行錯誤が加速する: 拡張だとコード修正→ビルド→リロード→動作確認で毎回2〜3分かかっていた。DevTools MCPはevaluate_scriptを書き換えて再実行するだけなので、10秒で次の仮説を試せる