Blazor WebAssembly（Blazor WASM）でExcelアドイン（Office Add-ins）を作ると、「配布のときはPartner Centerにmanifestだけ？それともアプリ本体も？」で迷いがちです。結論は、先にBlazorアプリをHTTPSでホストし、配布・提出するのは基本的にmanifest.xmlのみ。この記事では社内展開とAppSource公開の手順、運用で詰まりやすい点までまとめます。
結論：アップロードするのは「manifest.xml」、Blazor WASMアプリ本体は“ホスト先URL”で配布する
ExcelのWebアドイン（Office Add-ins）は、インストールされた瞬間にPCへ「実行ファイル」を配る仕組みではありません。ユーザーがExcelでアドインを開くと、Excel内のタスクペイン（埋め込みブラウザー）に指定URLのWebアプリが読み込まれて動きます。つまり、配布の最小構成は次の2つです。
| 構成要素 | 中身 | どこに置くか | 配布のときに何を“アップロード”するか |
|---|---|---|---|
| manifest.xml（マニフェスト） | アドインのID、名称、権限、表示アイコン、起動URL（SourceLocation）などの定義 | （配布方式に応じて）管理センター／Partner Center／SharePointのカタログ等に登録 | これをアップロード |
| アドイン本体（Webアプリ） | Blazor WASMの静的ファイル（index.html、.wasm、.js、css、画像など）＋必要に応じてAPI | 自社のWebホスティング環境（例：Azure Static Web Apps、IIS、Nginx、Azure Storageの静的Webサイトなど） | 管理センターやPartner Centerへ“丸ごとアップロード”は通常しない（URLで参照させる） |
GitHubサンプルでよく見るlocalhostや開発用証明書はあくまで開発・テスト向けです。実運用（社内配布でも社外公開でも）では、Excelから到達できる常時アクセス可能なHTTPS URLにアプリを置き、そのURLをmanifestに書いて配布します。
まず押さえる：Officeアドインの配布経路は「社内（テナント内）」と「社外（AppSource）」で別物
同じmanifest.xmlでも、誰にどう届けるかで使う管理画面が変わります。迷ったら、あなたのゴールがどれかを先に決めると整理しやすいです。
| 配布パターン | 対象 | 主な操作場所 | アップロードするもの | よくある用途 |
|---|---|---|---|---|
| 開発・個人テスト（サイドロード） | 自分／少人数 | Excel（デスクトップ/WEB）側の「Upload My Add-in」 | manifest.xml | 動作確認、検証、PR前のテスト |
| 社内配布（テナント内の集中展開） | 自社ユーザー全体／部門／グループ | Microsoft 365 管理センター（Integrated Apps など） | manifest.xml（またはmanifestのURL） | 社内向けアドインの本番展開 |
| 社外配布（一般公開） | 不特定多数／外部顧客 | Partner Center（Microsoft Marketplace / AppSource 提出） | manifest.xml＋説明文・画像・ポリシー等 | AppSource掲載、商用提供 |
ここで重要なのが、「Microsoft 365 Developer Program（MDP）」と「Partner Center」は用途が違うことです。MDPは主に開発用のテナントや検証環境を用意するための枠組みで、社内展開の“配布先”ではありません。社内へ届けるなら管理センター、社外へ届けるならPartner Centerが主戦場になります。
Blazor WebAssemblyアプリ本体を“先に”公開する手順
配布の前に、アドイン本体（Blazor WASM）が動くURLを用意します。Officeアドインはmanifestが指すURLへアクセスして画面を表示するため、URLが不安定だと「真っ白」「読み込み失敗」「証明書エラー」で詰まります。
公開（publish）の考え方
- Blazor WASMは基本的に静的ファイルとして配布できます（APIが別に必要ならAPIも用意）。
- 公開先は「静的ホスティング」でも「ASP.NET Core Hosted」でもOK。運用都合で選びます。
- Office on the webやMarketplace公開を視野に入れるなら、URLはHTTPS必須と考えて設計します。
ホスティング先の選び方（社内向けでも最初に決めたい）
| 候補 | 向いているケース | メリット | 注意点 |
|---|---|---|---|
| Azure Static Web Apps | Blazor WASM単体（SPA）を手早く公開したい | 静的サイトに最適化、CI/CDと相性が良い | サーバー処理が必要なら別途API（Functions等）設計 |
| Azure Storage（静的Webサイト） | とにかく軽く・安く静的配信したい | コストが低い、シンプル | ルーティング書き換えやMIME/圧縮設定で詰まることがある |
| Azure App Service / IIS | SSOやサーバーサイドAPIと同居させたい、企業標準がIIS | 企業運用に乗せやすい、ログや認証が組みやすい | WASM単体ホストの方式やOSによって制約がある |
| 社内Webサーバー（Nginx/Apache） | オンプレで閉じたい、既存基盤がある | ネットワーク制御・社内認証と合わせやすい | 社外から使う場合の到達性（VPN等）と証明書が課題 |
「Azure Static Web Appsが推奨されがち」と言われる理由は、Blazor WASMが静的ホスティングと相性がよく、公式のBlazorデプロイガイドでも静的ホスティング（Standalone deployment）やAzure Static Web Appsが選択肢として整理されているためです。社内の運用ルール（ドメイン、証明書、監査、WAF、ログ）に合うホストを選びましょう。
“Excelから見える”URLにするためのチェック
- HTTPSでアクセスできる（社内CAでもよいが、端末が信頼している証明書であること）。
- Excelデスクトップ/Excel for the webの両方で使うなら、社内外の到達性（VPN必須か、分割DNSか）を事前に決める。
- Blazorの静的ファイル配信で、.wasmや圧縮済みファイル（br/gz）が正しく返る。
- アドインの開始ページ（例：taskpane.html / index.html）が200 OKで返る。
manifest.xmlでやること：URLを書き換え、必要なドメインを登録する
manifest.xmlの役割は「アドインをどう起動し、どのURLを開き、どんな権限で動くか」を定義することです。Office Add-insのmanifestは、ID/バージョン/表示名/権限/アイコン/コマンド/起動URLなどを持ちます。
最重要：SourceLocation（起動URL）
タスクペインアドインの場合、Excelが最初に開くページがSourceLocationです。多くのサンプルでは開発時に~remoteAppUrlやhttps://localhost:xxxxが入っているため、公開URLへ置き換えます。
<SourceLocation DefaultValue="https://addin.example.com/taskpane.html" />ここで指定するURLは、原則HTTPSです。また、画像をCDNに置く、APIが別ドメインにある、認証ページを別ドメインで開く、といったケースでは、manifest内で許可するドメイン（AppDomainなど）の登録が必要になることがあります。まずは「アドイン開始ページと同一ドメインに集約する」設計にすると運用が楽です。
manifestの種類にも注意（XML manifest と unified manifest）
Officeアドインには大きく2系統のmanifestがあります。Blazor WASMのExcelアドインは、現場ではXMLの「add-in only manifest」を使うケースがまだ多い一方、Microsoft 365の統合マニフェスト（unified manifest）を採るケースも増えています。配布画面や手順が違うため、プロジェクトがどちらかを最初に確認してください。
| 観点 | add-in only manifest（XML） | unified manifest（Microsoft 365） |
|---|---|---|
| ファイル形式 | manifest.xml | （JSONベースの統合マニフェスト） |
| 主な用途 | 従来のOffice Web Add-ins（Excel/Word/PowerPoint等） | Microsoft 365全体で統一的に扱うアプリ/アドイン |
| 管理センターでの展開 | アドインの展開が可能（画面/機能が段階的に整理されている） | Integrated Apps（統合アプリ）側での展開が基本 |
いずれの方式でも共通なのは、ホスト先URLは自分で用意し、manifestはその参照情報という点です。
社内向け：Microsoft 365 管理センターでmanifestを展開する（集中展開）
社内配布の王道は、Microsoft 365 管理センターから組織へ展開する方法です。管理者がmanifestを登録すると、対象ユーザーはExcelの「アドイン」から利用できるようになります。
手順（Integrated Apps での展開イメージ）
- 管理者アカウントで Microsoft 365 管理センター（admin.microsoft.com）へサインインします。
- 左メニューから設定 → 統合アプリ（Integrated apps）を開きます。
- カスタムアプリをアップロード（Upload custom apps）を選び、manifestファイル（.xml）をアップロードします（またはmanifestのURLを指定します）。
- 展開対象を全員／特定のユーザー/グループ／自分のみから選びます。まずは小さなグループで段階展開が安全です。
- 権限要求や設定を確認してDeployします。反映後、対象ユーザーのExcelにアドインが表示されます。
ポイントは「アップロードするのはmanifestだけ」「アプリ本体はすでにホストされていて、manifestのURLがそれを指している」ことです。社内展開で詰まる場合の多くは、manifestではなくURL到達性と証明書が原因です。
管理者が押さえるべき運用ポイント
- 最初は限定配布：特定グループでテスト → 問題なければ全社展開、がトラブルを最小化します。
- 更新手順を決める：通常は「ホスト先を更新」だけで機能追加できますが、URLや権限、コマンド定義が変わるならmanifestの再展開も必要です。
- セキュリティ審査の観点：どのドメインへ通信するのか（API、CDN、認証）を棚卸しして、必要最小限に保ちます。
開発・検証向け：Excelからmanifestをサイドロードして動作確認する
管理センターに載せる前に、開発者がExcelから直接manifestを読み込む「サイドロード」は便利です。特に、アドインの開始ページURLを切り替えた直後の疎通確認に向きます。
Excel for the web（ブラウザー版）の例
- Office on the webでExcelを開き、任意のブックを開きます。
- Home（ホーム） → Add-ins（アドイン） → More Settingsを開きます。
- Upload My Add-inからmanifest.xmlを選んでアップロードします。
- リボンやタスクペインにアドインが表示されることを確認します。
サイドロードは“配布”の代替ではなく、あくまでテスト手段です。社内の一般ユーザーに使ってもらうなら管理センター展開に切り替えましょう。
社外向け：Partner CenterからMicrosoft Marketplace / AppSourceへ提出する
社外（一般公開）で配布したい場合は、Partner CenterでMicrosoft Marketplace（AppSource）へ提出します。ここでも「アプリ本体をPartner Centerへ丸ごとアップロードする」発想になりがちですが、基本はmanifestと審査に必要な情報を提出し、実体はあなたのホスト先URLで動く設計です。
提出前に準備しておくもの
| 準備物 | 内容 | チェックポイント |
|---|---|---|
| manifest.xml | 製品版URLを指すもの | HTTPS、表示名/ID/バージョン、アイコン、権限、要件セット |
| ホスト先（本番環境） | 審査担当がアクセスして動作確認できる環境 | 外部から到達可能、認証が必要なら審査用アカウントの用意 |
| ストア素材 | 説明文、スクリーンショット、ロゴ、サポートURLなど | 実態と一致、誇大表現の回避、問い合わせ窓口 |
| ポリシー類 | プライバシーポリシー等 | 収集データ、利用目的、第三者提供、保持期間の明記 |
Partner Center提出の流れ（概略）
- Partner CenterでMicrosoft 365 and Copilot系のプログラム/タブが利用可能な状態にします（組織アカウント、発行者情報など）。
- 新規オファー（Office Add-in等）を作成し、アプリ名・発行者・カテゴリを設定します。
- manifest.xmlをアップロードし、ストア掲載情報（説明文、画像、サポート情報）を入力します。
- 検証・認証プロセスに提出し、指摘があれば修正して再提出します。
- 承認されると、AppSource/Office内の入手画面からインストール可能になります。
審査は「manifestの整合性」と「実際にURLへアクセスして機能するか」が重要になります。特に、manifest内のPublisher/Identity情報と、Partner Center側の発行者情報がズレると手戻りになりやすいので、早い段階で合わせ込んでおくとスムーズです。
運用でハマりやすいポイント（Blazor WASMならではも含む）
HTTPS証明書と到達性が最重要
- Office on the webやMarketplaceを絡めるなら、HTTPS必須です。社内限定でも、端末が証明書を信頼していないと「コンテンツがブロックされる」系のエラーになります。
- 社内だけで使う場合でも、在宅勤務やモバイル利用を想定するなら「VPN前提」なのか「社外からも到達させる」なのかを決めておきます。
Blazor WASMの配置パス（/ 直下かサブパスか）
- アドイン用URLを
https://example.com/addins/excel/のようにサブパスで切りたいことがあります。 - その場合、Blazorの
<base href="/">やルーティング、静的ファイルの相対パスが原因で“真っ白”になりがちです。 - 最初のリリースは専用サブドメイン（例：
https://excel-addin.example.com/）にすると、パス問題を回避しやすく運用も楽です。
キャッシュ（特にService Worker）と更新手順
- Blazor WASMはリソースをキャッシュする設計になっているため、更新直後に端末側に旧版が残り「更新されない」ように見えることがあります。
- 運用ルールとして、静的ファイルはファイル名ハッシュでキャッシュバスティング、開始ページ（taskpane.htmlなど）は短めのキャッシュ、など方針を決めます。
- 「manifestのURLは変えない」運用にすると、管理センター再展開を最小化できます（URLを変えた場合だけmanifest更新）。
ドメインまたぎ（API/CDN/ログイン）
- デスクトップ版Officeでは、タスクペイン開始ページと異なるドメインへ遷移しようとすると、外部ブラウザーで開かれる挙動になる場合があります。
- 「開始ページと同一ドメインに寄せる」「必要なドメインはmanifestで宣言する」「認証はポップアップ/リダイレクト方式を設計する」など、早期に方針を固めると後戻りが減ります。
“manifestだけ配ったのに動かない”ときの切り分け
| 症状 | 原因の当たり | 最初に確認すること |
|---|---|---|
| アドインが一覧に出てこない | 展開対象／反映待ち／権限不足 | 管理センターで対象ユーザー/グループ、状態（Deploy済み）を確認 |
| タスクペインが真っ白 | URL 404、証明書、Blazorのパス/ルーティング、MIME | ブラウザーで開始URLを直接開いて200 OKか、開発者ツールでネットワークエラーがないか |
| 「安全でないコンテンツ」警告 | HTTP混在、証明書不備 | 開始URL/リソースURLがすべてHTTPSか、証明書が信頼されているか |
| 一部ボタンだけ動かない | 要件セット不足、権限不足、Office.jsのロード失敗 | manifestのRequirementSets、Office.js参照、権限（Read/Write）を再確認 |
実務で使える：配布・更新のおすすめ設計（小さく始めて事故を減らす）
最後に、社内アドインでよく採られる「事故りにくい設計」をまとめます。Blazor WASMはリリース頻度が高くなりやすいので、運用の“手間”を最初に潰しておくのが大切です。
- URLを固定：manifestのSourceLocationは固定URL（例：
/taskpane.html）にして、リリースは静的ファイル差し替えで吸収する。 - 段階展開：テスト用グループ → 部門 → 全社、の順で展開。影響範囲をコントロールできる。
- 環境を2つ用意：staging（検証）とproduction（本番）でホスト先を分け、manifestも環境別に用意（またはホスト側で切替）。
- 障害時のロールバック手順：ホスト先を前バージョンへ戻すだけで復旧できるように、ビルド成果物を保管しておく。
公式ドキュメント（最短で迷子にならないリンク集）
細部の仕様や画面項目は更新されることがあるため、最後は公式ドキュメントで確認するのが確実です。特に「どこにmanifestを置くか」「HTTPS要件」「提出手順」は頻繁に改訂されます。
- Office Add-ins manifest（manifestの役割とHTTPS要件）
- SourceLocation（起動URL）の仕様
- Microsoft 365 管理センターでのアドイン展開（Deploy add-ins in the admin center）
- サイドロード（Upload My Add-in）手順
- Deploy and publish Office Add-ins（配布方式の全体整理）
- Microsoft Marketplace/AppSource への公開
- Partner Center 経由での提出（Make your solutions available…）
- Microsoft Marketplace submission guide（提出手順の詳細）
- Blazor WebAssemblyのホストとデプロイ
- Visual Studioでのパッケージ/公開（manifestとWebアプリは別で公開する）
「manifestだけでいいのか？」という問いへの答えは、“配布物としてはmanifestが主役だが、実際に動く本体は必ずどこかにホストしておく”です。ホスト先URLとmanifestの整合性さえ固めてしまえば、Blazor WASMでもExcelアドインの配布はぐっとシンプルになります。
コメント