台湾の後工程テスト4社の月次売上まとめを、毎朝のコマンドチェーンから自動生成する
台湾の後工程テスト4社の月次売上まとめを、毎朝のコマンドチェーンから自動生成する
外部のブログで、台湾のテスト会社の月次売上をまとめた記事を見かけた。 会社ごとに月次売上の推移を並べ、その下に前月からの増減を置く構成だった。
読んでいるうちに、これは自分のところで毎月作れるのではないかと思った。
毎朝走らせている /make-diary のチェーンには、台湾の月次売上を取り込むステップがすでにある。
そこで金額が更新されているなら、まとめ記事まで続けて作れるはずだった。
その記事を Chrome DevTools で開かせて、構成を確認させた。
あわせて、手元のデータとも突き合わせてもらった。
aseMonthlyRevenue.ts は 2026年7月の 737.8億NT$ まで入っていて、外部記事の数字とそのまま一致した。
Powertech 82.7億、KYEC 39.9億、Ardentec 17.7億も同じだった。
材料は揃っていた。 決めることは、どの範囲を取るか、どう図にするか、どこに出すか、の3つだけだった。 結果から言えば、この3つでそれぞれ一度ずつつまずいた。
4社まとめて1本にする
分割するか1本にまとめるかを聞かれたので、1本にまとめると答えた。 対象は元の記事と同じ、後工程のテスト系4社に絞った。
- ASE（日月光投控）：パッケージングとテストのフルライン世界最大手
- Powertech（力成科技）：DRAM や NAND などメモリ後工程に特化
- KYEC（京元電子）：テスト専業。AI / HPC 向けのバーンインが主戦場
- Ardentec（欣銓科技）：テスト専業。大手 IDM からの受託が主力
図の型も元の記事を踏襲して、1社につき3段にした。 上から月次売上、前月差、勢いの3つを縦に積む。
水準を並べても記事にならない
売上高そのものを並べるだけだと、書けることは「今月も過去最高」で終わってしまう。 前月差を取ると、増え方のペースが見える。 その前月差がさらに増えたかどうか（2次差分）まで取ると、加速しているのか失速し始めたのかが分かる。
7月の ASE は、前月差が +80.0億で勢いが +52.5 だった。 増えているのではなく、増え方そのものが広がっている状態を指す。
スクリプトとテストを先に書かせた
チャートは毎月作り直すので、手で SVG を置く選択肢は最初から無かった。 13ヶ月 × 3段 × 4社の座標を毎月手で置けば、どこかで必ずズレが混入する。 生成スクリプトを書かせて、あわせてテストも書かせた。 スクリプトが405行、テストが123行になった。
テストは図の見た目ではなく、数字の意味を守るところに置いた。 2次差分は3点目から出ること、軸の上限は必ず入力以上を返すこと（バーが枠から飛び出さない）、そして最新月を過去最高と呼べるかどうかの判定。 このうち過去最高の判定は、書かせたその日のうちに効いた。
「過去最高」が嘘になりかけた
図ができた時点で、4社とも最新月が過去最高だった。 ところが手元の TS データは 2024年1月以降しか入っていない。 つまりここで言う「過去最高」は、「2024年以降で最高」でしかなかった。
ASE は 2022年9月に 666.5億、Powertech は 2022年6月に 80.9億を付けている。 この2つをスクリプトの判定に織り込ませて、データ範囲内で最高かつ過去のピークも超えている場合だけを過去最高と呼ぶようにした。 判定し直しても7月の ASE と Powertech は過去最高のままで、2022年のピークを4年ぶりに超えたことになった。
中身は変わらなかったが、直さないまま書いていたら、正しい結論を間違った根拠で出すところだった。 図の崩れは目で気づける。 データの範囲は目では気づけない。
数えずに書くと外れる
記事の主張のひとつに、4社そろって前月差も勢いもプラスになった、というものがあった。 図に出している直近13ヶ月の範囲では、今回が初めてに見えた。
機械的に数えさせたら、2024年以降で春節明けの反動増が出る3月を除いて、2025年8月と今回の2回あった。 「13ヶ月ぶり」ではなく「2回目」。 図に映っている期間と、事実を数える期間は別物だった。
コマンドの手順書には、「N ヶ月ぶり」「〜で最大」と書く前に必ず数える、という一文を厳守事項として入れさせた。 数えずに書かない、と明記しておかないと来月また同じことをやる。
13ヶ月より長くできない
最初は4社を1枚に並べた俯瞰図も作らせていた。 これが縦に潰れた。 一度は目盛りと注記の位置を直させて読める状態にしたものの、期間を延ばすたびに同じ問題が戻ってくる。
原因は図の作り方そのものにあった。 このサイトの図はホバーに頼らず、数値を図の中に直接描く。 ホバーに逃がすと、スマホで見たときに読めなくなるからだ。 720px の幅では1ヶ月あたり48px が下限で、それ以上詰めるとバーの上の数値ラベルが重なって潰れる。
長い期間を見たいなら、置き場所を変えるしかない。 そう考えたところで、2024年からの推移は各社のモニタリングページにあるのではないかと思い当たった。 確認させたら、直近31ヶ月の月次売上と前年同月比の折れ線がすでにあった。 記事の俯瞰図と完全に重複していた。
俯瞰図は削除させて、記事からモニタリングページへ片方向のリンクだけ張った。 逆向きは張らない。月次記事は毎月増えるので、モニタリング側にリンクを足していくと保守が破綻する。 記事に残った図は、各社1枚、直近13ヶ月の3段図が4枚だけになった。
作ったものの居場所を見失った
記事ができたあと、図と記事がどこに入ったのか分からなくなった。 記事ページを開いたら404が出たこともあって、スクリーンショットを撮り、「今どこに入ってますか」と聞いた。 404のほうは編集中の HMR による一時的なもので、curl では 200 が返っていた。
記事に「未分類」のバッジが出ていたのが引っかかっていた。
調べさせたら、トップの「記事」カードから /blog に入って、8月12日のセルに他の記事と並んでいた。
移動させる必要は無かった。
つまり、「未分類」のバッジを、記事がどこにも入っていない印だと読み違えていた。 バッジが付いているかどうかと、一覧に載っているかどうかは別だった。
月に1回だけ走らせる
最後に、この一連の作業を /tw-test-monthly-report として切り出させた。
台湾の上場企業は毎月10日までに前月の単月売上を開示する。 記事を作れるのは月に1度、10日前後だけになる。 毎朝走るチェーンに入れる以上、残りの日は何もせずに即座に終わってほしい。
判定は最初のステップに置いた。
node scripts/generate-tw-test-charts.mjs --check
# MISMATCH=... → 4社の最新月が不一致。まだそろっていないので SKIP
# LATEST=2026-07 → その月の記事が既にあれば SKIP、無ければ生成に進む
呼び出し位置は、台湾の月次売上を更新するステップの直後にした。 失敗してもチェーン全体は止めない。 月次まとめが数日遅れても困らないので、警告だけ残して先へ進ませる。
この日つまずいた3箇所
材料が揃っていたぶん、この日の作業は最初から最後まで見せ方の話だった。
どの範囲を取るか（13ヶ月で切って、長期はモニタリングへ振る）。
どう図にするか（水準ではなく差と勢いを主役にする）。
どこに出すか（/blog に載せて、月に1回だけ走らせる）。
一番危なかったのは、そのどれでもない。 2024年より前のデータが手元に無いことに気づかないまま、「過去最高」と書きかけたところだった。