Deck BridgeをChrome・Firefoxのストアに提出するまでに用意したもの

Deck Bridgeはデッキ画像やDuel Simulatorのリプレイから取り込んだカードを確認し、遊戯王ニューロンのデッキへ入力するブラウザ拡張です。 開発中の拡張を手元で動かすところから、ストアへ提出するまでには、配布用ファイルのほかにも用意するものがありました。

Chrome Web StoreとFirefox Add-onsへ提出した0.1.3では、掲載文や画像、権限の説明、プライバシーポリシーをそろえました。 Firefox向けには審査用ソースも作り、そのZIPだけから同じ拡張を再ビルドできることを確かめています。 この記事は2026年10月13日から15日に行った提出準備と、0.1.3の提出時点の記録です。 インストール方法や利用手順はDeck Bridgeの使い方にまとめています。

配布するZIPと、審査用ソースを分ける

Deck BridgeではWXTを使い、同じソースからブラウザごとの拡張をビルドしています。 Chromeではサイドパネル、Firefoxではサイドバーを使うため、ブラウザに合わせたmanifestを含むZIPをそれぞれ作りました。

用意したもの	Chrome Web Store	Firefox Add-ons
インストール用ファイル	Chrome向けの拡張ZIP	Firefox向けの拡張ZIP
説明・掲載画像	Chrome用の掲載文と画像	Firefox用の掲載文と共通画面の画像4枚
権限・データ利用の説明	管理画面の申告欄とポリシー	manifestの申告、掲載情報、審査メモとポリシー
審査用ソース	今回の提出では別途添付せず	ソースZIPとビルド手順を添付

インストール用ZIPには、ブラウザがそのまま使うJavaScriptやCSS、manifestなどが入ります。 一方、審査用ソースにはTypeScriptやビルド設定など、配布物を作る前のファイルを入れます。 この2つは用途が違うため、同じZIPを名前だけ変えて提出するものではありません。

Mozillaの説明では、バンドルや圧縮などでコードが読みづらくなる場合、元のソースとビルド手順の提出が必要とされています。 Deck Bridgeもビルド時にファイルをまとめる構成なので、審査用ソースを用意しました。

権限名を、利用者の操作と結び付けて説明する

Chromeの申告欄では、拡張の目的や、権限を使う理由を記入します。 権限の名前だけでは何のためにその機能を使うのかが伝わりません。 Deck Bridgeでは説明を実際の操作に対応させました。

たとえば、scriptingは公式データベースのページでカードの入力・保存・照合を行うために使います。 ChromeのsidePanelは、公式データベースのページを見ながら取り込んだカードを確認する画面に使います。 接続先の権限についてもDuel Simulatorのデータを取得する操作と、公式データベースのページを扱う操作を分けて説明しました。

データ利用の説明も拡張の通信と、ログイン済みの公式サイトで行う操作を分けています。 拡張自身がCookieを読み取らなくても、公式サイトのページで保存を押せば、そのサイトの通常の通信が発生します。 「画像を端末内で処理する」という説明だけでは、デッキを保存するところまでの動作を説明しきれません。

そこで、何を端末内に保存するか、どの場面で外部へ接続するか、保存を始める操作は何かを、掲載文とプライバシーポリシーに記載しました。 Chromeの入力欄は公式のプライバシー欄の説明も参照し、実装と申告が食い違わないように確認しています。

ストア用画像は、操作の順に用意する

Chrome向けには、1280×800のスクリーンショット5枚と、440×280の小型プロモーション画像を用意しました。 拡張のアイコンには128×128のPNGを使っています。 これらの寸法と画像の種類は、Chrome Web Storeの画像仕様に合わせたものです。

掲載画像は、取り込み、区分の確認、カード一覧、1枚の修正、全体の確認という操作の順に並べました。 最初から結果画面だけを見せるより、何を入力し、どこで直せるかが分かる構成です。

撮影では、サンプルのカード名と画像を使い、拡張の実画面を表示しました。 パネルの幅は388pxで、その画面を説明とともに1280×800へ配置しています。 掲載文でも説明用のサンプルであることを明示しました。

画像の大きさだけでなく、文字のはみ出しや操作順も確認しました。 Firefox向けには、Chromeビルドで撮影した共通画面の画像4枚を流用しました。 Chrome専用の「サイドパネル」という見出しを含む取り込み画面は除き、掲載文ではFirefoxのサイドバーとして説明しています。

審査用ソースだけで再ビルドする

審査用ソースには、アプリのソース、ビルド用モジュール、設定ファイル、依存バージョンを固定するlockfile、ビルド手順書などを含めました。 開発用のテストやそのデータ、内部の設計資料は含めていません。 必要なファイルがそろっているかは、ZIPを作れたことだけでは判断できないので、空の一時ディレクトリへ展開して確かめました。

手順書には、Node.jsとpnpmのバージョン、対応する環境、実行するコマンド、生成先を書きました。 ソースを展開した場所で実行する中心のコマンドは次の2つです。

pnpm install --frozen-lockfile
pnpm zip:firefox

pnpm zip:firefoxはDeck Bridge側で定義したコマンドです。 Firefox向けのManifest V3の拡張を作り、.outputへ出力します。 lockfileを使って依存関係をそろえることで、審査する人が別の依存バージョンでビルドしてしまう違いを減らします。

再ビルドのあとは、提出用の拡張ZIPと作り直したZIPのファイル一覧を比較しました。 さらに、展開した各ファイルのSHA-256を計算し、内容が一致するかを確かめています。 ZIPファイル全体のハッシュだけでは、格納時の時刻などの差まで含まれるため、ここでは中のファイルを照合しました。

0.1.3では、Firefox向け拡張の全18ファイルが一致しました。 この確認によって、手元の作業ディレクトリにしかないファイルへ依存せず、提出したソースから配布物を再現できることを確かめています。 Mozillaも再ビルドした内容と提出物に差がないことを確認する手順を説明しています。

自動検査の結果と、提出後の状態を残す

Firefoxへの0.1.3提出では、自動検査はエラー0件・警告9件でした。 警告にはAndroidの最低バージョンに関するものや、同梱ライブラリ内のコードに関するものがあり、対象環境や該当箇所の説明を審査メモに記載しました。 警告の数だけを見て、すべて無視してよいと判断したわけではありません。

掲載文や審査メモは管理画面へ入力したあと、保存された内容を読み直しました。 Firefoxに添付したソースも取得し直し、アップロードしたZIPと内容が一致することを確認しています。 手元に正しいファイルがあることと、管理画面にそのファイルが保存されていることは、別々に確認しました。

0.1.3は日本時間2026年10月15日に両ストアへ提出し、その時点の状態を審査待ちとして記録しました。 ZIPの生成、自動検査の通過、審査への提出、一般公開は、それぞれ別の段階です。 管理画面にバージョン番号が表示されていても、それだけを公開済みの根拠にはしていません。

Chrome版はその後公開されました。現在の入手方法はDeck Bridgeの使い方を参照してください。

今回の提出準備でそろえたのは、配布物と、その内容を利用者・審査担当者へ説明する材料です。 とくに審査用ソースの再ビルドは手順書を実行できるかと、提出するコードが同じかを一度に確かめる作業になりました。