← ishizakahiroshi.com
失敗談 2026-08-17

Microsoft Store の更新を CI 化しようとしたら、公式手順の画面が存在しなかった

閉じたシャッターで途切れる通路と、机の上の書類の山

Microsoft Store に出しているアプリの掲載版が、6 日間止まっていました。修正版は GitHub にも npm にも出ているのに、Store にだけ届いていない。2 回目以降の提出を自動化しようとして、その下準備が終わらなかったからです。今日その続きをやって、公式手順が指している設定画面が自分の管理画面には存在しないことが分かりました。自動化は諦めて、手動で出し直しています。

Qiita で読む → note で読む →

この記事のテーマ

Store の更新を GitHub Actions に載せるには、提出用の API を叩く資格情報が要ります。公式手順はその取得先として「ユーザー管理の Microsoft Entra applications タブ」を指していますが、個人の開発者アカウントで開くとそのタブがありません。ページ内のタブ要素を全部列挙しても返るのは 1 つだけで、権限を割り当てる先が無い。ここで自動化は詰みました。

詰むまでに踏んだものが、どれも次に同じことをやる人が引っかかりそうなものでした。テナント管理ページの URL、読み込み完了まで押せないボタン、「無料で作れる」はずのテナントに要る支払い登録、住所フォームの国を後から切り替えると戻らなくなる Next、作った直後のテナントが拒否される中間状態、そしてアカウント切り替えの導線がページによって表示されないこと。順番に記録しました。

記事の要約

記事全体の要約。左が公式ドキュメントと実際の管理画面の乖離、中央がセットアップで踏んだ 3 つの落とし穴、右が配布物の出どころを 1 本に決める運用です。

配布物の出どころを 1 本に決める

手動提出に切り替えたあとで効いたのが、この線引きでした。同じソースから作っても、手元でビルドした実行ファイルと CI が作ったものはバイト列が違います。Store に出したものと GitHub で配っているものが別のバイナリになると、後から追跡できません。提出用のパッケージは必ず GitHub Release の成果物から作り、中に入った実行ファイルのハッシュを照合しています。

ローカルビルドと CI 成果物のバイト数の違いと、提出物の作り方

手元でビルドしたものは動作確認用、CI が作ったものが配布用。この線を引いておかないと、手動提出のときに手近な実行ファイルを掴んでしまいます。

note 版もあります

note 版では、この話の入口になった「ファイルを右クリックして選んでも起動しない」という不具合そのものを扱っています。原因は、配布用にパッケージし直したときだけ必要になる宣言の入れ忘れで、開発中は要らないものなので手元では最後まで気づけませんでした。技術的な運用の話は Qiita 版、症状と直した中身は note 版に分けています。