クラウド会計のUI不満ログにスクショとX引用を足して本番デプロイまで通した

開発mdx-playground

スクリーンショットを1枚貼って「これ、前にまとめてなかったっけ」と聞くところから始まった。

会計ソフトAの年次推移表で、売上高の2022年に見えるリンクを押すと、飛び先は2025年になる。2023年も2024年も同じで、行のどこを押してもいま選んでいる年度へ戻ってくる。全部が同じ場所を指すなら、リンクを付けている意味がない。

この手の不満は前にまとめて公開したはずだった。ただ、どの記事だったかを思い出せない。

7月に書いた定点観測の記事

7月に書いた、不満と改善要望を並べたログ記事だった。Xの投稿から発生日と解決状況を記録していく定点観測の記事で、そこに年次推移表の件が入っていたかどうかを確かめてもらった。

入っていなかった。「推移表」「年次」「リンク」のどれで検索してもヒットしない。8件目として足してもらった。

ついでに、<br> の連結で詰まって見えていた段落を2つに割り、「上の7件」という件数表記も直させた。件数を本文に直書きすると、1件足すたびにズレる。

どの画面の話かをスクショで示す

文章だけだと、どのリンクの話なのかが伝わらない。せっかく自分で貼った画像があるので、そのまま記事へ入れてもらった。786×539の画像が本文幅734pxに収まり、横のはみ出しはゼロ、lintも通った。画面はデモ環境のものなので、中身を隠す必要もない。

記事のタイトルも実態に合わせて直させた。

改善要望リストのAPI自動化の項目

改善要望リストには「APIで自動化できない」という項目が残っていた。これが今の実態と食い違う。APIはあるし、仕訳のアップロードもできる。できないのは一括登録のほうで、連携は1件ずつしか受け付けない。300件あれば300回叩くことになる。

ここは書き方に迷った。「APIがない」と書けば嘘になり、「APIで自動化できる」と書けば実務の体感とずれる。

実測は3日前に自分で済ませてあって、比較データも残っていた。未確認だったのは、仕訳帳APIのフィルターが効くかどうかだった。認証は取ってあるので、そこは実際に叩いて確かめてもらった。

  • 期間のフィルターは効く
  • 摘要とタグは400で弾かれる
  • 絞り込めるのは7つだけ

一括投入のAPIが用意されているかどうかも、最新のOpenAPI仕様で確認させた。3件とも記事に反映し、数字は条件付きで明記した。いま自分がやっている回避策は、書くと語弊が出そうなので記事には入れていない。

同じ不満をポストしている人がいるか

新しく足した項目について、同じことをポストしている人がいないかを x-search で探させた。Grok経由、2023年1月以降。3件出てきた。

この記事には「引用は元ポストを開いて本文と日時を直接確認する」というルールを敷いてある。検索結果の要約をそのまま貼ると、日付や文言が少しずつずれるからだ。3件とも元ポストを開いて確認してから入れてもらった。1件は引用の中の流れ図が1行に連結されていたので、原文の改行を再現させた。

あわせて、一括登録と一括削除はAPIが別々に分かれている。1項目にまとまっていたのを2つに割り、チェックマークも付け直した。

コミットしてから本番へ

デプロイの前に確認が1つ返ってきた。このリポジトリは作業ツリーがそのまま本番になるので、記事のコミットだけでなく、他のセッションが触っている未コミットの変更も一緒に出る。中身を見せてもらい、それで問題ないと答えた。

事前検証はpathリンター、非公開リンクの漏れ、evalsの3本で、どれも error 0 / warn 0 だった。そこからビルドが流れた。

  • プリレンダー 6,881ルート / 349秒
  • postgenerate 9ステップ / 50.2秒（非公開記事がdistに混ざっていないかの検査だけで39.6秒）
  • 本番ヘルスチェックでJSアセット1,366個を照合
  • 合計 13.6分

pushは素直に進まなかった。履歴はリニアなので --rebase で取り込むつもりが、他セッションの未コミット変更があるとrebaseは走らない。stashで退避すると他セッションを巻き込む。マージコミットが1つ増えるのを承知でmergeにした。

自分のポストを記事に取り込む

記事を出したあと、一括登録の話と一括削除の話をXにポストした。せっかくなので、これも他の項目と同じ体裁（元ポストへのリンク、日時、引用ブロック）で記事に入れてもらった。

そのとき指摘が1つ返ってきた。一括削除の項目は、引用と本文で同じ説明が2回続く。ポスト本文に実測値まで書いてあるためで、引用は「約3秒で終えた」、本文は「2.4〜2.7秒で終えた」になる。読み比べると同じ話をもう一度読まされる。今回はこのままにして、コミットとpushだけ済ませ、デプロイは保留にした。

デプロイのたびにdevが500を返す

ポストを入れている途中で、devサーバーが500を返した。

原因はさっきのデプロイだった。デプロイスクリプトの nuxt prepare が、稼働中のdevが使っている .nuxt/ を丸ごと消す。9月11日にissueとして記録してあり、ステータスは未解決のまま残っていた。症状が完全に一致した。

デプロイを1回打つたびに、裏で開いているdevが死ぬ。issueに書いてあった暫定対処どおりdevを再起動して、その場はしのいだ。

そのうえで直してもらった。ただし、コミット前のCodexレビューが5回続けてhighで止めた。

  1. Test-Path 単発では、dev起動直後でまだ tsconfig.app.json が無い瞬間にデプロイすると判定がfalseになり、prepareが走ってdevを壊す。ポート検出を足した
  2. dev停止中に古い tsconfig.app.json が残っていると、設定を変えてもprepareが省略され、古い生成設定でビルドされる。ビルドが落ちるならまだしも、気づかないまま誤った成果物が出る
  3. 3000番を別プロセスが握っている場合。自分の判定はmediumで、dev停止、tsconfig残存、別プロセスの占有、設定変更の4つが重ならないと起きない。それでも対応が軽いので直した
  4. 2と3の直しで新しく作り込んだリスクが2件。修正前は毎回prepareしていたのでtsconfigは常に新鮮だった。省略を入れた自分が開けた穴なので、highに同意した
  5. apps/web-backup 側のdevが3000を握っているケース。これもmedium判定だが、1行で消えるので直した

重要度はCodexの言い値をそのまま受け取らず、毎回こちらで判定し直した。mediumと判定した2件も、結局はコストの低さで直している。

判定ロジックは実データで裏を取らせた。dev起動が 11:33:57、tsconfigの書き込みが 11:34:17 という実データで、時刻比較はきちんと効いた。サブコマンド判定は dev でTrue、preview でFalse、dev --port 3000 でTrueになる。web-backup と web2 は弾かれ、実プロセスだけがTrueになった。

効いたかどうか

最後に、計測スクリプト付きでデプロイをもう一度回した。

[r2-sync-images] sync 完了: 2208 件 / 41.1 秒

合計は約12分で、前回より1.4分縮んだ。そして肝心のところ、devのプロセスがデプロイを挟んで生き残っていた。PID 42048、起動時刻は 11:33:57 のまま、HTTP 200。

スキップした旨のログ行が deploy.log に見当たらず（出力先が別だった）、最初は状況証拠だけの報告が来た。そのあと自分の手元に出ていたログを貼ったら、探していた行がそこにあった。

学び

  • 自分で貼ったスクショを記事に入れておくと、「どの画面の話か」の説明が1行で済む
  • 「できない」と書いた不満は、あとで一部だけできるようになる。何ができて何ができないかまで分解しておかないと、記事のほうが先に嘘になる
  • 引用は検索結果の要約で済ませず、元ポストを開いて本文と日時を確認する。日付と文言が静かにずれる
  • レビューの重要度は指摘の数ではなく、その経路で実際に何が壊れるかで決める。mediumと判定しても、1行で消えるなら直したほうが早い

明日やること

  • 一括削除の項目で、引用と本文に同じ説明が2回出ているのを片方へ寄せる
#クラウド会計#UI#API#デプロイ#Cloudflare