Outlookアドインをこれから作る、または社内展開の手順を見直すなら、2026年5月13日に更新された公式情報「Build your first Outlook add-in – Office Add-ins」は最初に確認すべきクイックスタートです。結論から言うと、今回押さえるべきポイントは「既存アドインが突然壊れる変更」ではなく、Yo Officeでの開発開始、マニフェスト選択、HTTPS・WebView・サイドロード、管理センターでの展開判断を最新の前提でそろえることです。公式ページでは、選択したOutlookメッセージの件名を読み取るタスクペイン型アドインを作成する流れが整理されています。 (Microsoft Learn)
Outlookアドインは「作れたら終わり」ではありません。実務では、どのOutlookクライアントで動かすのか、manifest.jsonとmanifest.xmlのどちらを使うのか、管理者がどの範囲に展開するのか、必要な権限を過剰にしていないかまで確認する必要があります。この記事では、公式クイックスタートの内容を要約しつつ、管理者・開発者が確認すべき設定、移行、展開上の注意点を実務目線で整理します。
Outlookの「Build your first Outlook add-in – Office Add-ins」で分かること
「Build your first Outlook add-in – Office Add-ins」は、Outlook向けのタスクペイン型アドインを初めて作るための公式クイックスタートです。内容は、Yeoman generator for Office Add-ins、通称Yo Officeを使ってプロジェクトを作成し、Office JavaScript APIで選択中のメール件名をタスクペインに表示する流れです。 (Microsoft Learn)
このページで学べる中心は、次の4点です。
| 項目 | 内容 | 実務での意味 |
|---|---|---|
| 開発環境 | Node.js、Yeoman、Officeアドイン用ジェネレーターを準備する | 新規メンバーでも同じ手順で開発を始められる |
| プロジェクト作成 | yo officeでOutlook向けタスクペインアドインを作る | 雛形作成に時間を使わず、API実装に集中できる |
| マニフェスト選択 | Unified manifest for Microsoft 365またはAdd-in only manifestを選ぶ | 将来の展開方法や対応クライアントに影響する |
| テスト実行 | npm startでローカルサーバーを起動し、Outlookにサイドロードする | 本番公開前に個人環境で動作確認できる |
重要なのは、クイックスタートの目的が「完成品の業務アドインを作ること」ではなく、Outlookアドイン開発の最小構成を理解することにある点です。実際の業務アドインでは、認証、Microsoft Graph連携、権限、エラーハンドリング、複数クライアント対応、管理者展開まで別途設計する必要があります。
今回の更新で確認すべき変更点
今回の公式更新は、大規模なAPI仕様変更というより、クイックスタートの説明・導入・手順の整理が中心です。GitHub上の差分では、説明文が「Office JS APIを使った単純なタスクペイン」から「メッセージプロパティを読み取るOutlookタスクペインアドイン」に整理され、導入文も「選択したメッセージから件名を読み取る」内容へ明確化されています。 (GitHub)
実務上の確認ポイントは次のとおりです。
| 確認ポイント | 変更・整理された意味 | 影響を受けやすい人 |
|---|---|---|
| サンプルの目的 | 選択中メッセージの件名を読むタスクペインアドインとして明確化 | 初学者、教育担当、社内ハンズオン担当 |
| Yo Officeの位置づけ | プロジェクト雛形作成に使い、Office JavaScript API実装へ進む流れを明示 | 開発者、リードエンジニア |
| マニフェスト選択 | 統合マニフェストとアドイン専用マニフェストの選択が初期手順に含まれる | 開発者、管理者、IT企画担当 |
| 初回実行時の認証 | サイドロードやログインタイムアウト時にatk auth login m365を使う案内がある | 開発者、検証担当 |
| クライアント別UI | Outlook on the web、新しいOutlook、クラシックOutlook、Outlook on Macでボタン位置が異なる | ヘルプデスク、展開担当 |
既存の本番アドインを運用している組織では、この更新だけを理由に即時移行が必要になるとは限りません。ただし、社内標準手順が古いままの場合は、Node.js、Yo Office、マニフェスト、サイドロード、展開方法のドキュメントを見直す良いタイミングです。
対象者と影響範囲
開発者は「最初の雛形」ではなく「将来の展開」まで見ておく
開発者にとって最も重要なのは、yo officeで動くサンプルを作るだけで満足しないことです。初期作成時に選ぶマニフェスト形式は、後の展開方法、対応クライアント、Microsoft 365アプリとの統合方針に影響します。
たとえば、Outlookだけで使う小規模な業務アドインなら、アドイン専用マニフェストで始める方が分かりやすい場合があります。一方、Teamsアプリや他のMicrosoft 365拡張とまとめて管理したい場合は、統合マニフェストを検討する価値があります。統合マニフェストはOfficeアドインとTeamsアプリなどを1つのMicrosoft 365アプリとしてまとめられる一方、すべてのプラットフォームで利用できるわけではありません。 (Microsoft Learn)
管理者は「サイドロード」と「組織展開」を分けて考える
管理者が見るべきポイントは、開発者のローカル検証と、ユーザーへの本番展開を混同しないことです。
クイックスタートではnpm startによるローカル実行とサイドロードが中心ですが、組織展開ではMicrosoft 365管理センターや統合アプリポータルを使った一元展開を検討します。Microsoftは、多くの組織に対して統合アプリポータルを推奨しており、Microsoft 365管理センターからユーザーやグループへOfficeアドインを展開できます。 (Microsoft Learn)
エンドユーザーへの影響はUI案内に出やすい
エンドユーザーにとっての影響は、アドインの内部構造よりも「どこから起動するのか」に出ます。Outlook on the webと新しいOutlookではメッセージのアクションバーから「Apps」を開く流れ、クラシックOutlookではリボン、Outlook on Macではリボンや省略記号メニューを確認する流れになります。 (Microsoft Learn)
展開後の問い合わせを減らすには、「アドインが見つからない場合はどこを見るか」をスクリーンショット付きで社内FAQに載せておくと効果的です。
開発者が確認すべき前提条件
公式クイックスタートでは、Node.jsの最新Active LTS、最新のYeomanとOfficeアドイン用Yeomanジェネレーター、Microsoft 365サブスクリプションに接続されたOffice、Outlook on the web・新しいOutlook on Windows・クラシックOutlook・Outlook on Macなどが前提として示されています。 (Microsoft Learn)
まずは次のコマンドで、開発環境をそろえます。
npm install -g yo generator-office
yo office
cd "My Office Add-in"
npm start初回実行時にMicrosoft 365へのサインイン画面が出ない、またはサイドロードやログインのタイムアウトが出る場合は、次のコマンドを実行してから再度npm startを実行します。
atk auth login m365
npm start開発環境で特に失敗しやすい点は次のとおりです。
| 確認項目 | 見落とすと起きる問題 | 対処 |
|---|---|---|
| Node.jsのバージョン | 依存パッケージのインストール失敗、ビルドエラー | Active LTSを使い、古いNode.jsを残さない |
generator-officeの更新 | 旧形式の雛形や古い依存関係で始めてしまう | 既に入っていても最新版へ更新する |
| Microsoft 365アカウント | サイドロードやOutlook接続で失敗する | 開発用テナントや検証用アカウントを用意する |
| HTTPS証明書 | localhostのアドインが開けない | 開発時でもHTTPSを使い、証明書の信頼を確認する |
| Edge WebViewのループバック | ローカルアドインをWebViewが開けない | 初回プロンプトで許可し、必要に応じて管理者権限で実行する |
マニフェスト選択は最初に決めるべき重要ポイント
Outlookアドイン開発では、マニフェストがアドインの名前、ID、起動条件、権限、UI、読み込むURLなどを定義します。Officeアドインには、XML形式のアドイン専用マニフェストと、JSON形式のMicrosoft 365統合マニフェストがあります。 (Microsoft Learn)
| 比較項目 | Add-in only manifest | Unified manifest for Microsoft 365 |
|---|---|---|
| 形式 | XML | JSON |
| 主な用途 | Officeアドイン単体の開発・展開 | Officeアドイン、Teamsアプリなどを1つのMicrosoft 365アプリとして扱う |
| 向いているケース | Outlookアドイン単体で使う、既存のOfficeアドイン資産を活かす | Microsoft 365全体でアプリを統合管理したい |
| 注意点 | Teamsなど他の拡張と1つのアプリ単位にはしにくい | すべてのOutlookクライアントで対応しているわけではない |
| 展開時の注意 | アドインポータルや管理センターでの扱いを確認 | 統合アプリポータルでの展開が必要になる場合がある |
統合マニフェストは便利ですが、Outlook on MacやOffice on mobileではサポートされないなど、対応プラットフォームに制約があります。統合マニフェストの利点を使いつつ未対応環境にも提供したい場合、公式ドキュメントでは統合マニフェスト版とアドイン専用マニフェスト版の2種類を作成・展開する考え方が示されています。 (Microsoft Learn)
判断基準はシンプルです。Outlookだけで完結し、幅広いクライアント対応を優先するならAdd-in only manifestを検討する。TeamsやMicrosoft 365アプリ全体との一体運用を重視するならUnified manifestを検討する。 ただし、実際の選択は利用クライアント、展開方法、管理ポリシーをセットで判断してください。
Office.js、要件セット、権限は早めに確認する
OutlookアドインはOffice JavaScript APIを通じてOutlookとやり取りします。Microsoft Marketplaceへ提出するアドインでは、Office.jsをMicrosoftのCDNから参照する必要があり、ローカル参照は使えません。また、Office.jsはページのhead内で読み込むことが推奨されています。 (Microsoft Learn)
要件セットも重要です。Outlook APIはMailbox requirement setに属し、マニフェストで最低要件バージョンを指定すると、その要件を満たさないOutlookクライアントにはアドインが表示されません。つまり、要件セットは「どの機能を使えるか」だけでなく、「どのOutlookに表示されるか」にも影響します。 (Microsoft Learn)
権限は、最小権限で設計してください。Outlookアドインの権限には、restricted、read item、read/write item、read/write mailboxの4段階があります。read/write mailboxは強力ですが、不要な場合に指定すると管理者レビューやセキュリティ審査で止まりやすくなります。 (Microsoft Learn)
実務では、次の順で確認します。
| 確認順 | 確認内容 | 判断基準 |
|---|---|---|
| 1 | アドインが読む情報 | 件名、差出人、本文、添付ファイルなど、必要なデータを洗い出す |
| 2 | 書き込みの有無 | 件名変更、本文挿入、宛先変更などが必要か確認する |
| 3 | APIの最小要件 | 利用APIに必要なMailbox requirement setを確認する |
| 4 | 権限レベル | 必要最小限の権限をマニフェストへ設定する |
| 5 | 管理者レビュー | なぜその権限が必要か説明できる状態にする |
サイドロード時の注意点
開発中はnpm startでローカルWebサーバーを起動し、Outlookにアドインをサイドロードしてテストします。自動サイドロードできない場合は手動サイドロードを行いますが、マニフェストの種類やOutlookクライアントによって手順が変わります。Outlookモバイルではアドインを直接サイドロードできず、Outlook on the web、Windows、Macなどでサイドロードしてからモバイルで確認する流れになります。 (Microsoft Learn)
特に注意したいのは、手動サイドロードで「Add from URL」が使えない点です。現在の案内では、URLから直接追加するのではなく、ブラウザーでマニフェストファイルを取得し、「Add from File」で追加する回避策が示されています。 (Microsoft Learn)
| 症状 | よくある原因 | 対処 |
|---|---|---|
npm start後にアドインが出ない | サインイン未完了、サイドロード失敗 | atk auth login m365を実行して再試行 |
| localhostから開けない | HTTPS証明書、WebViewループバック、信頼設定の問題 | 証明書を信頼し、WebViewループバックを許可 |
| リボンにボタンがない | Outlookクライアントごとに表示位置が違う | Apps、リボン、省略記号メニューを確認 |
| 手動追加できない | マニフェスト指定方法が古い | Add from Fileでマニフェストを指定 |
| クラシックOutlookで反映が遅い | キャッシュの影響 | 最大24時間程度の遅延を想定し、別クライアントでも確認 |
本番化するときの展開手順
ローカルで動いたアドインを本番化するには、localhost前提を外す必要があります。公式の発行手順では、Webアプリをホスティング環境へ展開し、マニフェスト内のhttps://localhost:3000のようなURLを本番のHTTPS URLへ置き換え、npm run buildで本番用ファイルを作成する流れが説明されています。 (Microsoft Learn)
ただし、Visual Studio CodeとAzure Storageを使う発行手順は、Yo Officeで作成されたアドイン専用マニフェストのプロジェクト向けです。統合マニフェストを使う場合やAgents Toolkitで作成した場合は、その手順がそのまま適用できない点に注意してください。 (Microsoft Learn)
本番化の基本ステップは次のとおりです。
| 手順 | 作業内容 | 注意点 |
|---|---|---|
| 1 | ホスティング先を決める | Azure Storage、App Service、社内Web基盤など。HTTPS必須で考える |
| 2 | 本番URLを確定する | 後からURLを変えるとマニフェスト更新が必要になる |
| 3 | マニフェストを書き換える | localhostを本番URLに置換する |
| 4 | npm run buildを実行する | distなどの成果物を展開対象にする |
| 5 | 検証環境へ展開する | まず自分または小規模グループに限定する |
| 6 | 管理センターで展開する | 対象ユーザー、グループ、権限説明を確認する |
| 7 | 反映確認とFAQ配布 | 表示場所、利用手順、問い合わせ先を明記する |
Webアプリ側の更新だけであれば、ホスティング先へ新しいファイルを展開すれば反映されます。一方、マニフェストを変更した場合は、利用者へマニフェストを再配布する必要があります。 (Microsoft Learn)
管理者が確認すべき展開・設定ポイント
組織内にOutlookアドインを展開する場合、Microsoft 365管理センターの一元展開を使うのが基本です。公式ドキュメントでは、最初に小規模な業務関係者やIT部門へ展開し、問題がなければ対象を広げ、最終的に全ユーザーへ展開する段階的ロールアウトが推奨されています。 (Microsoft Learn)
展開対象は「全員」ではなく、原則としてグループ単位で管理するのが実務では扱いやすいです。部署追加や異動があっても、グループメンバーシップを変更すればアドインの利用範囲を調整できます。 (Microsoft Learn)
管理者は次の点を確認してください。
| 確認項目 | 確認する理由 |
|---|---|
| 統合アプリポータルを使えるか | 統合マニフェストや組織展開の管理に影響する |
| 対象ユーザーのライセンス | 一元展開には対象ライセンスやExchange Onlineメールボックスが必要 |
| Exchange Onlineメールボックス | オンプレミスExchangeメールボックスへの展開はサポート外 |
| 管理者権限 | 一元展開には組織のExchange管理者権限などが必要 |
| AppsForOfficeEnabled | Falseの場合、アドインが表示されない原因になる |
| ユーザー・管理者ロール | 誰がアドインを追加・管理できるかを制御する |
| Marketplace利用方針 | ユーザーによる任意アドイン追加を許可するか決める |
一元展開の要件では、ユーザーに対象ライセンス、Exchange Onlineメールボックス、Microsoft Entra IDまたはフェデレーションされたディレクトリが必要とされています。また、Exchangeオンプレミスメールボックスへの展開や、COM/VSTOアドインの展開はサポートされません。 (Microsoft Learn)
Outlookアドインの管理で見落としやすい権限
Outlookアドインでは、Microsoft 365管理センター側の設定だけでなく、Exchange Online側のロールも関係します。管理者向けには、組織のOffice Storeアドインを管理するOrg Marketplace Apps、カスタムアドインを管理するOrg Custom Appsがあります。ユーザー向けには、My Marketplace Apps、My Custom Apps、My ReadWriteMailbox Appsなどがあります。 (Microsoft Learn)
特にReadWriteMailbox権限を要求するアドインは、メールボックスへの影響が大きいため、導入前にセキュリティ部門や情報システム部門でレビューしてください。
また、アドインが表示されない場合は、最初の切り分けとして次のPowerShell確認が有効です。
Get-OrganizationConfig | fl AppsForOfficeEnabled値がFalseの場合は、次のようにTrueへ変更することで表示問題の原因を解消できる場合があります。
Set-OrganizationConfig -AppsForOfficeEnabled:$True公式ドキュメントでも、AppsForOfficeEnabledをFalseにすることは推奨されていません。Falseにすると管理ロールやユーザーロール設定を上書きし、組織内の新しいアプリ有効化を妨げる可能性があります。 (Microsoft Learn)
移行・展開で失敗しやすいポイント
localhostのまま展開してしまう
開発中のマニフェストには、https://localhost:3000のようなURLが入ります。本番展開前にこれを実際のHTTPS URLへ置き換えないと、ユーザー環境ではアドインが読み込めません。
検証時は、マニフェスト内のURLを検索して、localhostが残っていないか確認してください。
grep -R "localhost" .統合マニフェストを選んだあとに未対応クライアントへ展開しようとする
統合マニフェストは便利ですが、Outlook on MacやOffice on mobileではサポート外とされています。Macやモバイルの利用者が多い組織では、統合マニフェストだけで全利用者をカバーできるか事前に確認してください。 (Microsoft Learn)
権限を広く取りすぎる
「将来使うかもしれない」という理由で強い権限を設定すると、管理者承認やセキュリティレビューで問題になりがちです。件名を読むだけのアドインと、メールを送信・変更できるアドインでは、必要な権限がまったく違います。
まずは実装するAPIを一覧化し、APIリファレンスで必要な最小権限を確認してください。
反映時間を考慮せずリリース日を決める
管理センターから展開しても、ユーザーのリボンに即時表示されるとは限りません。Microsoft 365管理センターの展開記事では、アドインのアイコン表示に24〜72時間かかる場合があると説明されています。 (Microsoft Learn)
本番リリース日は、展開日と利用開始日を分けて設計するのが安全です。たとえば、月曜日に管理者展開し、水曜日に利用開始アナウンスを出すといった運用が現実的です。
開発者向けチェックリスト
Outlookアドインを作る前に、次の項目を確認してください。
| チェック | 内容 |
|---|---|
| 開発環境 | Node.js Active LTS、npm、Yeoman、generator-officeを最新化したか |
| アカウント | Microsoft 365サブスクリプションに接続された検証用アカウントがあるか |
| クライアント | Outlook on the web、新しいOutlook、クラシックOutlook、Macなど検証対象を決めたか |
| マニフェスト | Add-in onlyかUnifiedかを、展開方針込みで選んだか |
| API | 利用するOffice JavaScript APIとMailbox requirement setを確認したか |
| 権限 | 必要最小限の権限にしているか |
| HTTPS | 開発・本番ともHTTPSで提供できるか |
| ドメイン | アドイン内で遷移するドメインをマニフェストに反映したか |
| サイドロード | 自動・手動どちらの検証手順も用意したか |
| 本番URL | localhostを本番URLへ置換したか |
管理者向けチェックリスト
組織展開前に、管理者は次の項目を確認してください。
| チェック | 内容 |
|---|---|
| 展開方式 | 統合アプリポータル、管理センター、Marketplace、LOB展開のどれを使うか |
| 対象範囲 | 全員ではなく、まず検証グループから始めるか |
| ライセンス | 対象ユーザーが必要なMicrosoft 365ライセンスを持つか |
| メールボックス | Exchange Onlineメールボックスが有効か |
| 管理ロール | Exchange管理者など必要な権限があるか |
| ユーザーロール | ユーザーが自分で追加できる範囲をどう制御するか |
| セキュリティ | アドインの要求権限、外部通信先、データ利用を確認したか |
| 反映時間 | 展開から表示までの遅延を利用開始計画に入れたか |
| FAQ | 起動場所、トラブル時の連絡先、利用停止方法を案内したか |
まず取るべき行動
これからOutlookアドインを作るなら、最初に公式クイックスタートどおりyo officeでタスクペイン型アドインを作り、選択中メッセージの件名を読み取るところまで動かしてください。そのうえで、すぐに本番実装へ進むのではなく、次の3点を先に決めることが重要です。
まず、対応するOutlookクライアントを決めます。Outlook on the web、新しいOutlook、クラシックOutlook、Mac、モバイルのどこまで対象にするかで、マニフェストや検証範囲が変わります。
次に、マニフェスト形式を決めます。Outlook単体で広く対応するのか、Microsoft 365アプリとしてTeamsなどと統合するのかを判断してください。
最後に、展開方法を決めます。開発中はサイドロードで十分ですが、本番ではMicrosoft 365管理センターや統合アプリポータルを使い、グループ単位で段階的に展開するのが安全です。
「Build your first Outlook add-in – Office Add-ins」は、Outlookアドイン開発の入口として有用です。ただし、実務で成功させるには、サンプルを動かすだけでなく、権限、マニフェスト、HTTPS、本番URL、管理者展開、ユーザー案内まで含めて設計することが欠かせません。
コメント