MENU

Word Online アドインでタスクペインを文書オープン時に自動表示する方法｜manifest検証エラー（Package Type Not Identified / Wrong Package）の原因と対策

Word

Word Online（Word for the web）向けのタスクペイン アドインで「文書を開いた瞬間にタスクペインを自動表示したい」という要件は現場でも頻出します。しかし manifest.xml の書き方を少しでも誤ると、検証ツールで Package Type Not Identified や Wrong Package といった不可解なエラーに直行しがちです。本記事は、Angular 製のタスクペイン アドインを題材に、エラーの正体と確実に自動表示を実現するための manifest 設計・検証・テスト手順を、豊富なサンプルとチェックリストで徹底解説します。

目次

背景と悩みどころ

Word Online 用タスクペイン アドイン（TaskPaneApp）において、文書オープン直後にユーザー操作なしでタスクペインを表示するには、manifest の VersionOverrides 節に <AutoShowTaskpane>true</AutoShowTaskpane> を定義します。ところが、VersionOverrides の型や要素の置き場所、OfficeApp/Host 定義との整合性が崩れると、アドインの「種別」が認識できず、検証段階で落ちてしまいます。

特に、VersionOverridesV1_1 を採用したまま AutoShowTaskpane を有効化すると、検証ツールや配布チャネル側の判定仕様と噛み合わず、以下のようなエラーが出る事例が多く報告されています。本記事では、VersionOverrides を V1_0 に戻し、AutoShowTaskpane を正しい階層へ配置することで解消する道筋を、再現性のある形でまとめます（2025年11月時点の知見）。

典型的な検証エラーと原因の対応表

主なエラー発生しやすい原因具体的な確認ポイント
Package Type Not IdentifiedVersionOverrides の型が検証仕様と非互換／要素の階層崩れxsi:type="VersionOverridesV1_1" を使っていないか／AutoShowTaskpane の置き場所が誤っていないか
Wrong Package提出種別（TaskPane）とパッケージ定義が不整合<OfficeApp xsi:type="TaskPaneApp"> か／Hosts/Host が xsi:type="Document" か
Unknown attribute/element ～スキーマ バージョンに存在しない要素を使用V1_1 の要素を V1_0 の空間に混在させていないか
Resource not found（resid 参照エラー）resid で参照したリソースが未定義<Resources> 節で URL/文字列/画像の定義が揃っているか
URL/HTTPS 関連の警告SourceLocation が HTTP / 相対パスの誤用Word Online では HTTPS 必須（相対 URL はホストと配置の整合が必要）

結論：VersionOverrides を V1_0 に戻し、AutoShowTaskpane を正しい階層へ

最短で安定化する手順は次の二点です。

  1. VersionOverrides の型を VersionOverridesV1_0 に戻す
    V1_1 は検証系での判定が揺らぎやすく、Package Type Not Identified を誘発します。TaskPane 型での自動表示用途は V1_0 で堅実に通します。
  2. AutoShowTaskpane は AllFormFactors → ExtensionPoints → ExtensionPoint xsi:type="Taskpane" の直下に置く
    「ShowTaskpane」はボタン押下時に表示する “Action” 側の概念であり、AutoShowTaskpane を置く場所ではありません。置き場所の取り違えがエラーの温床です。

正しい manifest スニペット（最小構成）

以下は、Word Online のタスクペインを文書オープン時に自動表示させるための最小構成例です。ポイントにコメントを付けています。

<OfficeApp
  xmlns="http://schemas.microsoft.com/office/appforoffice/1.1"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:bt="http://schemas.microsoft.com/office/officeappbasictypes/1.0"
  xmlns:ov="http://schemas.microsoft.com/office/taskpaneappversionoverrides"
  xsi:type="TaskPaneApp">

00000000-0000-0000-0000-000000000000  
1.2.0.0
Contoso
ja-JP







  






ReadWriteDocument




<ov:Hosts>
  <ov:Host xsi:type="Document">
    <ov:AllFormFactors>
      <ov:ExtensionPoints>

        <!-- リボン（任意）：ボタンでタスクペインを開く -->
        <ov:ExtensionPoint xsi:type="PrimaryCommandSurface">
          <ov:OfficeTab id="TabHome">
            <ov:Group id="Contoso.Group">
              <ov:Label resid="Contoso.Group.Label" />
              <ov:Control xsi:type="Button" id="Contoso.Taskpane.Button">
                <ov:Label resid="Contoso.Taskpane.Label" />
                <ov:Supertip>
                  <ov:Title resid="Contoso.Taskpane.Label" />
                  <ov:Description resid="Contoso.Taskpane.Desc" />
                </ov:Supertip>
                <ov:Icon>
                  <ov:bt:Image size="16" resid="Icon.16" />
                  <ov:bt:Image size="32" resid="Icon.32" />
                </ov:Icon>
                <ov:Action xsi:type="ShowTaskpane">
                  <ov:TaskpaneId>Contoso.Taskpane</ov:TaskpaneId>
                  <ov:SourceLocation resid="Taskpane.Url" />
                </ov:Action>
              </ov:Control>
            </ov:Group>
          </ov:OfficeTab>
        </ov:ExtensionPoint>

        <!-- ★ 自動表示の要：Taskpane 拡張ポイントの直下に AutoShowTaskpane -->
        <ov:ExtensionPoint xsi:type="Taskpane">
          <ov:TaskpaneId>Contoso.Taskpane</ov:TaskpaneId>
          <ov:Title resid="Contoso.Taskpane.Label" />
          <ov:SourceLocation resid="Taskpane.Url" />
          <ov:SupportsPinning>true</ov:SupportsPinning>
          <ov:AutoShowTaskpane>true</ov:AutoShowTaskpane>
        </ov:ExtensionPoint>

      </ov:ExtensionPoints>
    </ov:AllFormFactors>
  </ov:Host>
</ov:Hosts>

<ov:Resources>
  <ov:bt:Images>
    <ov:bt:Image id="Icon.16" DefaultValue="https://example.com/assets/icon-16.png" />
    <ov:bt:Image id="Icon.32" DefaultValue="https://example.com/assets/icon-32.png" />
  </ov:bt:Images>
  <ov:bt:Urls>
    <ov:bt:Url id="Taskpane.Url" DefaultValue="https://example.com/taskpane/index.html" />
  </ov:bt:Urls>
  <ov:StringResources>
    <ov:String id="Contoso.Group.Label" DefaultValue="Contoso Add-in" />
    <ov:String id="Contoso.Taskpane.Label" DefaultValue="Taskpane" />
    <ov:String id="Contoso.Taskpane.Desc" DefaultValue="Open the task pane" />
  </ov:StringResources>
</ov:Resources>

要点

  • xsi:type="ov:VersionOverridesV1_0" に固定する。
  • AutoShowTaskpane は ExtensionPoint xsi:type="Taskpane" の直下に置く。“ShowTaskpane” ではない。
  • TaskpaneId はボタン アクション側とタスクペイン定義側で一致させる。
  • SourceLocation は HTTPS。Angular/SPA の場合は最終生成物（例：/taskpane/index.html）の実 URL と合わせる。

なぜ V1_1 だと失敗しやすいのか

VersionOverridesV1_1 自体は新機能（Runtimes 定義の詳細化・パフォーマンス改善など）に対応する一方、配布先や検証ツールの解釈が完全ではない環境が残るため、「アドインの種別を特定できない」「提出種別とパッケージが一致しない」といったエラーが表出しやすくなります。
特に AutoShowTaskpane のように UI 挙動に直結する要素は、VersionOverrides の解釈が揺らぐと真っ先に巻き込まれます。タスクペインの起動を確実にするという観点では、V1_0 に固定して検証の通り道を一本化するのが堅実です。

Angular（SPA）ならではの落とし穴と対策

Base Href とルーティング

  • Angular でハッシュレス ルーティング（PathLocationStrategy）を使う場合、<base href="/"> が SourceLocation と噛み合わず 404 を誘発することがあります。
    対策：ng build --base-href /taskpane/ のようにビルド時にベースを合わせるか、ハッシュ ルーティング（useHash: true）に切り替える。
  • Word Online の iframe 配下で動くため、リダイレクトや Service Worker のスコープが想定どおりに届いているかも確認します。

開発証明書と HTTPS

  • Word Online は HTTPS が前提。ローカル開発時は自己署名証明書の信頼登録を済ませる。
  • Angular の dev-server を使う場合は --ssl true --ssl-cert --ssl-key を設定し、manifest の URL と一致させる。

パフォーマンスと初期描画

  • AutoShowTaskpane は「表示のトリガー」を与えるだけで、描画の速さはホスト ページ次第。初期ロードが重いと「自動表示されたのに真っ白」という見え方になります。
  • 初期描画を軽くするため、Angular 側は 遅延ロード（Lazy Loading）、プリレンダ/SSR 不要化（タスクペインは CSR で十分な場合が多い）、アイコン・フォント圧縮 などを取り入れると安定します。

manifest 設計のチェックリスト

項目期待値確認メモ
OfficeApp タイプxsi:type="TaskPaneApp"Outlook など別プロダクト用の型が紛れ込んでいないか
Host 定義Hosts/Host Name="Document"Word Online は Document ホスト。型指定（xsi:type="Document"）の整合も確認
VersionOverridesV1_0名前空間プレフィックスの付け替え漏れに注意（ov:）
AutoShowTaskpane の位置ExtensionPoint xsi:type="Taskpane" 直下“ShowTaskpane” はボタンの Action。混同しない
TaskpaneIdAction 側と一致片側だけ定義/命名が違うと起動不可
SourceLocationHTTPS の絶対 URL（または厳密な相対）Angular ビルド成果物へのパスが正しいか
Resources/Strings/Imagesresid が全て解決不要なリソースを削ぎ、参照漏れをゼロに
Permissions最小権限（例：ReadWriteDocument）不要な権限を削ると審査も通りやすい

バージョン番号・GUID（Id）の運用指針

  • GUID（Id）はプロダクトの同一性を表すため、基本は固定。機能更新や manifest 修正は Version を上げることで配布・差し替えを行います。
  • ローカル開発で 同じ GUID・同じ Version のままサイドロードを繰り返すと、キャッシュが原因で検証・動作が不安定になることがあります。Version を必ずインクリメントし、既存のサイドロード アドインは削除してから再登録します。
  • GUID を変えた場合、ホスト側には「別アドイン」として認識され、並存や残骸キャッシュがエラーの母集団になります。検証の前には旧版の掃除を徹底しましょう。

検証ツールとローカル検証のすすめ

CI/CD の中で manifest の構文/論理チェックを自動化すると、人的ミスでの後戻りが激減します。代表的には以下のフローが有効です。

  1. 静的検証：manifest の XSD に基づく構文検査、VersionOverrides 型チェック、未参照の resid 検出。
  2. 論理検証：OfficeApp.TaskPaneApp と Hosts/Host=Document の整合、AutoShowTaskpane の階層、HTTPS/URL の到達性。
  3. 起動検証（ヘッドレス）：E2E で Word Online を自動起動 → サイドロード → 文書オープン → iframe 内のタスクペイン DOM 生存検査。

実機確認ではブラウザーのプロファイル差・拡張機能の影響も無視できません。専用プロファイル／シークレット ウィンドウでの再現確認を習慣化しましょう。

キャッシュの掃除と「反映が遅い」問題

Office 365（Microsoft 365）の配信環境やテナント設定により、manifest の差し替えが反映されるまで一時的にタイムラグが出ることがあります。経験則では 5〜10 分程度。以下を順に実施して観測します。

  • Word Online 側：サインアウト → ブラウザー キャッシュ/ストレージ削除 → シークレット再試行
  • 開発側：manifest の Version を上げる／旧サイドロードの削除／~\AppData\Local\Microsoft\Office\16.0\Wef（デスクトップ検証時）等のローカル キャッシュをクリア
  • CDN を使っている場合はファイル名ハッシュやキャッシュ バスターを有効化（?v=xxxx でなく、ビルドでファイル名にコンテンツ ハッシュを埋め込む）

Word Online と Word デスクトップの差分

観点Word Online（Web）Word デスクトップ
ホストブラウザー（iframe 埋め込み）WebView2/EdgeHTML 等（バージョン依存）
HTTPS 要件必須ローカルループバック/自己署名の扱いに差あり
AutoShowTaskpaneV1_0 で安定（本記事の主題）挙動は概ね同等だが、キャッシュの影響を受けやすい
デバッグブラウザー DevToolsWebView2 DevTools（CTRL+SHIFT+I 等）

よくある質問（FAQ）

Q. AutoShowTaskpane を true にしたのに出ません。

A. 次を順に確認してください。

  • VersionOverridesV1_0 になっているか。
  • AutoShowTaskpane が Taskpane 拡張ポイント直下にあるか。
  • TaskpaneId が Action 側と一致しているか。
  • SourceLocation の URL に実体があり、HTTPS で配信されているか。
  • 文書を 開き直しているか（既に開いている場合はトリガーされません）。
  • キャッシュをクリアし、別プロファイル/シークレットでも再現するか。

Q. VersionOverridesV1_1 をどうしても使いたいです。

A. UI 自動表示の確実性を優先するなら V1_0 が無難です。V1_1 の恩恵（Runtimes の詳細化など）を活かす場合でも、AutoShowTaskpane だけは V1_0 側の定義に寄せる構成（複合運用）は避け、まずは V1_0 で検証と配布を安定化させてから移行計画を立てるのが現実的です。

Q. manifest の改行やインデントで本当に壊れますか？

A. XML 自体は空白に寛容ですが、タグ欠落・閉じ忘れ・名前空間プレフィックスの混在は即座に構文破綻を招きます。特に ov: プレフィックスの付け忘れに注意してください。

トラブル再発防止のためのテンプレート運用

チームでの属人化を防ぐため、以下のようなテンプレート運用が有効です。

  • ひな型 manifest（V1_0 固定、AutoShowTaskpane あり／なしを切り替え可能）をリポジトリに同梱
  • pre-commit フックで manifest の XSD 検証を自動実行
  • CI で E2E（Word Online 自動起動 → 文書オープン → タスクペイン DOM 検査）を毎ビルドで実施
  • 配布前に リグレッション シナリオ（既存文書／新規文書／テンプレート文書）で AutoShow の有無を網羅

もう一度：最短で直すための実践手順

  1. manifest を開く（manifest.xml）。
  2. VersionOverrides の型を修正：
    <VersionOverrides … xsi:type="VersionOverridesV1_1"> → xsi:type="VersionOverridesV1_0"
  3. AutoShowTaskpane の位置を修正：
    AllFormFactors → ExtensionPoints → ExtensionPoint xsi:type="Taskpane" の直下に <AutoShowTaskpane>true</AutoShowTaskpane>
  4. OfficeApp/Host の整合性：
    <OfficeApp xsi:type="TaskPaneApp">、Hosts/Host Name="Document"／ov:Host xsi:type="Document" を確認
  5. SourceLocation の URL を本番/検証いずれかに合わせて HTTPS で記述
  6. Version をインクリメント（例：1.2.0.0 → 1.2.1.0）。GUID は据え置き。
  7. 旧サイドロードの削除 → 再サイドロード。
  8. Word Online で新規文書を開く → タスクペインが自動表示されることを確認。

参考：よくある誤ったスニペット（やってはいけない）

以下は NG 例です。いずれも検証エラーの温床になります。

<!-- NG: VersionOverrides が V1_1 のまま -->
<ov:VersionOverrides xsi:type="ov:VersionOverridesV1_1"> … </ov:VersionOverrides>



true

テスト戦略：自動表示の「見え方」を評価する

自動表示が機能するだけでなく、ユーザー体験を損なわないことが重要です。次の観点を評価に含めましょう。

  • ファースト ペイント時間：文書オープンからタスクペインの主要 UI が表示されるまでの時間。
  • 干渉検証：文書テンプレートが別アドインを呼ぶ場合、競合やフォーカス奪取が起きないか。
  • 再オープン挙動：同じ文書を閉じて再度開いた場合に自動表示が安定するか。
  • 切替検証：Word Online とデスクトップ間の切替（同一ファイル）で自動表示の状態が破綻しないか。

セキュリティとプライバシーの留意点

  • タスクペインはドキュメントのコンテキストで動作します。必要最小限の権限（ReadWriteDocument 等）に抑え、個人情報・機密データの扱いを最短経路に留めます。
  • 外部通信（API コール）は CSP（Content Security Policy） と HTTPS を徹底。iframe 内のサードパーティ スクリプトは最小に。
  • Telemetry 収集時はユーザー通知・同意・オプトアウト動線を manifest の説明や UI 内に明記します。

まとめ

Word Online 用タスクペイン アドインで「文書オープン時に自動表示」を安定して実現する鍵は、次の 3 点に集約されます。

  • VersionOverrides は V1_0（2025年11月時点の実務的ベストプラクティス）。
  • AutoShowTaskpane は Taskpane 拡張ポイント直下に正しく配置。
  • OfficeApp/Host/SourceLocation/TaskpaneId の整合性と、キャッシュ運用の徹底。

上記を守れば、検証ツールでの Package Type Not Identified／Wrong Package を回避し、ユーザーが文書を開くたびにタスクペインが自動で立ち上がる、期待どおりの体験を提供できます。

付録：チェック用ショートリスト（現場貼り紙用）

Yes/Noチェック項目
□xsi:type="TaskPaneApp"／Hosts/Host=Document を確認した
□VersionOverridesV1_0 に統一した
□AutoShowTaskpane を Taskpane 拡張ポイント直下に置いた
□TaskpaneId を Action 側と一致させた
□SourceLocation を HTTPS の最終 URL にした
□Version を上げ、旧サイドロードを削除してから再登録した
□Word Online で新規文書を開き、自動表示を確認した

付録：Angular 側の実装ヒント（最小）

アドイン初期化は Office.onReady() の完了を待って開始します。AutoShowTaskpane は「表示のトリガー」であり、アプリ側の初期化は従来どおり必要です。

// main.ts
import { platformBrowserDynamic } from '@angular/platform-browser-dynamic';
import { AppModule } from './app/app.module';

Office.onReady().then(() => {
platformBrowserDynamic().bootstrapModule(AppModule)
.catch(err => console.error(err));
});

初期表示を軽くするなら、AppModule 側で初期ロードに不要なモジュールは遅延ロードへ回し、アドインの「最初に見える要素」を最優先で描画してください。

実運用のコツ

  • 機能フラグ（Feature Flag）で AutoShow の ON/OFF を切り替えられるようにしておくと、ユーザー要望や A/B テストにすぐ応じられます。
  • 「文書を開くたびに開くと邪魔」という声に備え、最初の起動時のみ自動表示し、以降はユーザーのピン状態に追随するポリシーも実務的です。
  • テナントや言語ごとの差異を吸収するため、manifest の文字列リソースは最小にし、動的文言はアプリ側でローカライズする構成が保守しやすいです。

おわりに

manifest の数行を整えるだけで、ユーザー体験は見違えるほど改善します。今回のポイント（V1_0 固定、Taskpane 直下の AutoShow、整合性チェック、キャッシュ対策）をテンプレート化してチームの標準に落とし込めば、同種のトラブルはほぼ撲滅できます。明日からの開発・運用にぜひお役立てください。

Word
Word Online Office アドイン manifest AutoShowTaskpane

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次