同じバージョンなら、同じ中身 — だと思っていた。自作アプリを4か所に配って5時間溶かした話
小さな CLI を 4 か所に配るだけのつもりが、5 時間溶けた。溶けたのは全部 npm だった。そして溶かしている途中で「この 4 か所、本当に同じものを配れているのか？」というぞっとする問いに足を止められた——という記事の、設計側の整理メモ。
4 つの配り先と、つまずいたのは 1 つだけだった話
配り先は GitHub Releases、winget、Homebrew、npm の 4 つ。利用者の入口に合わせて並べる発想で、タグを 1 つ打てば自動で揃うはずだった。実際には 3 つは綺麗に通り、最後の npm だけが何度も赤く止まった。原因はレート制限（429 Too Many Requests）。焦って間隔を詰めると窓がリセットされてむしろ悪化する。
そして詰みかけだったのは、レート制限よりも「やり直しが効かない」構造のほうだった。最後の npm だけ直して流し直したいのに、流れ作業の頭から走るので、もう公開済みの GitHub Release に「それはもう在るよ」と弾かれて全体が止まる。3 つは公開、npm だけ宙ぶらりん、しかも素直にやり直せない。
最初の答え「npm を先に出す」は、自分の足を撃つ案だった
最初に思いついたのは順番の入れ替えだった。一番こけやすく不可逆な npm を「先に」出せば、こけても他は何も公開していないからやり直しが効く。発想自体は悪くない（不可逆なものを先に確定させる、はリリース設計の定石）。
でも、ここで手が止まった。「npm を先に出す」には、ほかの 3 つより先に npm 用のバイナリが要る。つまり 正本ができる前にもう一回ビルドして、それを npm に詰めることになる。npm の中身は「1 回目のビルド」、GitHub たちの中身は「2 回目のビルド」。二度焼いたパンは別のパンだ。やり直しを楽にしたくて入れた案が、いちばん守りたかった「全部が一組から出ている」を壊していた。
「同じバージョン」って、同じ中身なんだっけ？
ここで根本の問いに行き当たる。4 か所に v0.3.1 として並べる。番号は同じ。でも番号が同じだからって、配っているバイナリまで同じだと、誰が保証しているんだろう。
調べてみると、配り先ごとに「同じであることの担保のされ方」がまるで違った。整理するとこうなる。
- GitHub Releases：1 回だけビルドした zip を並べる。これが 正本。
- winget / Homebrew：zip を再ビルドしない。「あの住所のこの指紋（ハッシュ値）の箱を持ってこい」という案内札を更新するだけ。利用者が入れるときに指紋を照合する。中身は原理的に正本と同じ。これが ポインタ。
- npm：zip を指すのではなく、中のバイナリを取り出して npm 用の別の箱に詰め替えて出す。唯一、再梱包する窓口だった。
再梱包する以上、「どこから取り出したバイナリを詰めたか」次第で、同じ番号なのに違う中身を配れてしまう。これが急所だった。
同一性と、やり直しは、別々の問題として別々に解く
ここでようやく、ごちゃ混ぜにしていた 2 つの問題が分かれて見えた。
- 全部が同じ中身であること（同一性）：正本を先に作って、npm はその正本から取り出して詰める。順番はむしろ「正本が先、npm が後」でなければ成立しない。最初の直感とは逆。
- npm だけこけたとき、やり直せること（再実行）：順番では解かない。npm だけを、公開済みの正本から取り直して出し直す専用の小さな入口 を別に用意する。流れ作業の頭から走らせないから「それは在る」と弾かれず、取り直す先は正本そのものなので中身も揃う。
1 個の打ち手で 2 つ片付けようとすると、だいたいどこかに無理が出る。同一性は「ビルドは 1 回だけ・正本から取り出す」で、再実行は「チャネル別の専用入口」で、別の道具で解くのが正しかった。
ついでに、WSL 経由をやめられた話
もうひとつ引っかかっていた違和感。npm に出すときだけ、わざわざ Linux 環境（WSL）を経由して箱詰めしていた。Windows で完結しないのが気持ち悪かった。
掘ると理由はたった一点。Linux と Mac ではファイルに「実行していい」という小さな印（実行ビット）が要る。Windows で箱詰めするとこの印を付けられない。印のない実行ファイルは相手の環境で「権限がない」と弾かれる。だから印を付けられる Linux 環境を経由していた、というだけだった。
気づきはここ。印は箱詰めのときに焼き込まなくても、ツールを起動する瞬間に付け直せばいい。起動役の小さなスクリプトが、実行ファイルを呼ぶ直前に「実行していい」と付けてから呼ぶ。そうすれば、どこで箱詰めしようと関係ない。WSL を経由する理由そのものが消える。回避策をひとつ覚えるより、回避する必要をなくすほうがいい。
結局ぜんぶ「手で踏む手順」が腐っていた
並べてみて、はっとした。WSL を経由していたのも、レート制限を手で待って何度も叩いていたのも、リリースノートが空なら手で貼り直していたのも、認証トークンを 2 か所に書き写していたのも——ぜんぶ「人がその場で踏む手順」だった。
事故は、賢い手順を覚えていないから起きるんじゃない。手順が人の手に残っている限り、いつか誰かが（だいたい自分が）踏み外す。本当の直しは、手順をうまくすることじゃなくて、手順から人を抜くこと だった。
トークンの話も根は同じで、固定の鍵を 2 か所で手管理している限りいつかズレる。だったら鍵そのものを置かず、その場で発行する仕組み（OIDC / trusted publishing 系）に寄せる。置き場所が増えるほどズレる という当たり前に、遅れて気づいた。
持ち帰り：次のプロジェクトに最初から敷く 6 行
この記事の打ち手は、このツール 1 本の話で終わらせないことにした。次に作るどのプロジェクトでも初期設定として敷く基準として、別ファイルに書き起こしてある。
- 1 回だけ焼く：ビルドは 1 回。全チャネルがその 1 セットから出る。
- 正本から取り出して指紋で照らす：再梱包する窓口は正本 zip から取り出し、ハッシュ照合してから詰める。
- 順序は「正本 → repackager」：不可逆な npm を先に出す案を採用しない。同一性が先、再実行は別解。
- チャネル別の専用入口：npm だけ・winget だけ、を流れ作業の頭から走らせず単独で再実行できる小さな入口を持つ。
- 手で踏む手順を残さない：人がやるのは「タグを打って push する」まで。後は機械の仕事。
- 鍵もバージョンも置き場所は 1 つ：トークンは固定で持たず OIDC で都度発行。版数はタグを単一ソースに。