Windows タスクバー／スタートメニュー検索に独自 Web 検索エンジンを統合したい方へ ― 実現可能な範囲と安全な設計、代替策まで徹底解説
「Windows 標準の検索ボックス（タスクバー／スタートメニュー）から、社内専用の検索バックエンドを呼び出したい」――エンタープライズや教育機関からよく届く相談です。本記事では、uap3:AppExtension による “web search provider” 拡張の仕組みと制約、現実的な統合パターン、認証要件を伴う場合のアーキテクチャ設計、そして組織向けの代替案までをまとめて解説します。実装時の落とし穴や検証チェックリスト、サンプルのマニフェスト断片（疑似スキーマ）も掲載しています。
結論（最初に要点）
- uap3:AppExtension の Name 属性は変更不可です。
com.microsoft.windows.websearchproviderは予約済み識別子で、これを別名にしてタスクバー／スタートメニュー検索を完全置換することはできません。 - 本拡張でできるのは「検索クエリの転送 URL を差し替え、JSON で結果を返す」ところまで。UI は Windows 側が保持し、独自 UI・独自認証フローは注入できません。
- 認証・セッション共有（クッキーや Kerberos/SPNEGO）は仕様上サポート外。呼び出しは匿名の Web リクエストとして扱われ、ブラウザーの 1st パーティ文脈ではありません。クッキーはサードパーティ扱いとなり保持されない／遮断される可能性が高く、社内向けの要認証検索 API とは直接連携困難です。
- 提供地域はEU 圏限定機能として実装されています。他地域では利用できない点に注意してください。
- 組織内の検索体験を強化したい場合は、Edge サイドバー／WebView2 ウィジェット／Teams アプリ／既定ブラウザーの検索エンジン切替（ポリシー）などの代替策を検討するのが現実的です。
前提と課題認識
企業内で横断検索（ナレッジベース、ドキュメント管理、チケット、ソースコード、データカタログなど）を提供する際、「どこからでも即座に引ける」導線は UX の決定要素です。その最短動線が Windows の検索ボックスですが、OS 組み込みの領域であるがゆえにセキュリティとプライバシーの制約が厳格です。特に SSO を伴う社内検索や、ユーザーごとのパーソナル化（アクセス制御付き）を行う場合は、セッションの受け渡し不可という仕様が大きな壁になります。
仕組みの概要：AppExtension「websearchprovider」の役割
UWP/MSIX パッケージに組み込む uap3:AppExtension を用いると、Windows 検索が扱うクエリ文字列を事前に登録した URL へ転送させ、決められた JSON 構造で結果を返すことができます。ここで重要なのは、拡張が差し替えるのはバックエンドへの参照先（URL）に限られるという点です。表示のコントロール、イベント処理、認証 UI の組み込みなどは許可されません。
<div class="wp-block-table">
<table>
<thead>
<tr>
<th>観点</th>
<th>できること</th>
<th>できないこと</th>
</tr>
</thead>
<tbody>
<tr>
<td>クエリ転送</td>
<td>検索語を GET パラメータに付与して自前のエンドポイントへ送る</td>
<td>POST や複雑なボディ形式での送信、クエリ前処理のスクリプト注入</td>
</tr>
<tr>
<td>結果返却</td>
<td>既定スキーマの JSON を返し、Windows 側 UI に列挙させる</td>
<td>UI レイアウトのカスタマイズ、独自レンダリング、JS 実行</td>
</tr>
<tr>
<td>認証</td>
<td>（原則）認証なしの公開エンドポイントとして応答</td>
<td>Kerberos/SPNEGO、既定資格情報の自動送信、クッキー継続</td>
</tr>
<tr>
<td>識別子</td>
<td>予約名 <code>com.microsoft.windows.websearchprovider</code> を使う</td>
<td>Name を別名にして完全オリジナルのプロバイダーとして登録</td>
</tr>
<tr>
<td>提供地域</td>
<td>EU 圏ロールアウトの環境で有効</td>
<td>EU 以外の地域での同様の統合</td>
</tr>
</tbody>
</table>
</div>マニフェスト記述のイメージ（疑似スキーマ）
以下は概念を掴むための疑似例です。実際のスキーマ名・要素は OS のバージョンや SDK に依存します。発行前には必ず貴組織の検証環境で挙動をご確認ください。
<pre><code><Packagexmlns:uap3=”[http://schemas.microsoft.com/appx/manifest/uap/windows10/3](http://schemas.microsoft.com/appx/manifest/uap/windows10/3)” …>
<!-- 結果取得エンドポイント（JSON） -->
<ResultEndpoint
Url="https://search.contoso.example/api/results?q={query}&client=windows"
MaxItems="10" />
<!-- 応答フォーマットのバージョン -->
<Format Version="1" />
</uap3:Properties>
</uap3:AppExtension>
</Extensions>
</Application><p>ポイントは、<strong>Name を変更できない</strong>こと／<strong>URL を宣言するだけ</strong>で UI は OS に任されることです。検索体験の「見た目」を作り込みたい場合、この方式は適しません。</p>結果 JSON のイメージ（疑似スキーマ）
Windows 側の UI が解釈しやすいコンパクトなカードリストを返す前提で、以下のような構造を想定します（あくまで例）。
<pre><code>{“query”: “vpn 設定”, “items”: [ { “title”: “社内 VPN クライアント設定ガイド”, “subtitle”: “Windows 11 / Split Tunnel / Always On”, “url”: “[https://kb.contoso.example/vpn/setup-win11](https://kb.contoso.example/vpn/setup-win11)”, “deeplink”: “contoso-vpn://open/howto/setup-win11”, “type”: “doc”, “lastModified”: “2025-09-12T08:31:00Z” }, { “title”: “VPN 接続トラブルシュート”, “subtitle”: “よくある 10 の原因と対策”, “url”: “[https://kb.contoso.example/vpn/troubleshoot](https://kb.contoso.example/vpn/troubleshoot)”, “type”: “kb” } ], “paging”: { “next”: null } }
<ul>
<li><code>title</code> と <code>subtitle</code> は UI 表示の主要テキストへ。</li>
<li><code>url</code> はブラウザーを開く標準リンク、<code>deeplink</code> は任意のアプリ連携（存在すれば優先）。</li>
<li><code>type</code> はアイコンや並べ替えのヒントとして用いられる想定。</li>
</ul>認証・セッションの現実解：なぜ難しいのか、どう設計するか
タスクバー／スタートメニュー検索からの呼び出しは、ブラウザーの 1st パーティ コンテキストではない匿名リクエストと考えるのが安全です。ここでは SSO の自動成立を前提にできず、認証クッキーも SameSite/Lax/Strict の影響で送られない可能性が極めて高い。Kerberos/SPNEGO のネゴシエーションも行われません。
<h3>要認証 API と直接つなげない場合の方針</h3>
<ol>
<li><strong>匿名インデックスの整備</strong>：要認証のソースから、公開可能なメタデータ（タイトル・サマリ・公開リンク）だけを<strong>別途匿名で検索可能</strong>なインデックスに複製。クリック時にブラウザーへ遷移し、そこで SSO を成立させる。</li>
<li><strong>一時トークンの発行（署名付き URL）</strong>：検索結果の URL に短命の署名（例：数十秒〜数分）を付与し、<strong>閲覧直前のブラウザー側で本人性を確認</strong>。ただし、<strong>検索 API 応答自体は匿名</strong>であることに注意。</li>
<li><strong>ネットワークレベルの閉域</strong>：VPN／ZTNA の内側からのみ検索 API を到達可能にし、<strong>API 自身は匿名応答</strong>とする。端末健全性と所属をネットワークで担保。</li>
<li><strong>ローカルプロキシ（実験的）</strong>：<code>https://localhost</code> の自己アプリでトークン管理・署名付与を行い、検索エンドポイントとしてローカルを指定。<em>ただし証明書配布・ゼロトラスト適合・OS 側の呼び出し制約</em>の壁が高く、運用負荷も大きい。</li>
</ol>
<div class="wp-block-table">
<table>
<thead>
<tr>
<th>方式</th>
<th>利点</th>
<th>懸念点</th>
<th>適合シナリオ</th>
</tr>
</thead>
<tbody>
<tr>
<td>匿名インデックス</td>
<td>検索は常に成功。UI との親和性が高い</td>
<td>非公開情報の漏洩防止に要配慮。同期パイプラインが必要</td>
<td>公開できるメタデータが多いナレッジ系</td>
</tr>
<tr>
<td>署名付き URL</td>
<td>クリック直前で厳格な検証が可能</td>
<td>署名生成の秘匿、時刻同期、リプレイ対策が必要</td>
<td>監査要件があるドキュメント参照</td>
</tr>
<tr>
<td>閉域（VPN/ZTNA）</td>
<td>検索 API を外部から不可視化できる</td>
<td>常時接続の運用、端末要件の維持</td>
<td>モバイルワークが限定的な組織</td>
</tr>
<tr>
<td>ローカルプロキシ</td>
<td>SSO/トークン連携の余地がある</td>
<td>導入・保守コスト大。OS 仕様変更の影響大</td>
<td>PoC や限定配布</td>
</tr>
</tbody>
</table>
</div>EU 限定提供の注意点
この拡張はEU 圏限定の提供です。IT 管理者視点では、展開リージョンによる挙動差が出やすく、同一イメージの端末でも「機能が現れない」ケースが発生します。グローバル展開の企業は、リージョン別のグループポリシー／配布リングを分け、サポートに負担をかけない設計にしましょう。
導入の現実的な選択肢（代替策）
1. Edge サイドバー（企業内検索パネル）
- Web アプリのまま常駐パネル化。SSO（Entra ID 等）も通常のブラウザー文脈で成立。
- 管理テンプレート（ポリシー）で既定表示・固定が可能。ホットキー起動で「すぐ引ける」を実現。
<h3>2. WebView2 ウィジェット（タスクトレイ／ミニ検索）</h3>
<ul>
<li>社内検索の軽量ランチャーを自作。<strong>UI／認証フローを自由設計</strong>できる。</li>
<li>更新は自前だが、<strong>UX の完全コントロール</strong>が可能。</li>
</ul>
<h3>3. 既定ブラウザーの「アドレスバー検索エンジン」切替（組織ポリシー）</h3>
<ul>
<li>ユーザーに <kbd>Ctrl</kbd>+<kbd>L</kbd>／<kbd>Ctrl</kbd>+<kbd>E</kbd> を案内し、<strong>アドレスバー＝社内検索</strong>を習慣化。</li>
<li>Edge/Chrome のポリシーでカスタム検索エンジンを配布し、<strong>クエリを社内検索へ転送</strong>。</li>
</ul>
<h3>4. Teams アプリ／Outlook アドインとして提供</h3>
<ul>
<li>Microsoft 365 の日常導線に組み込み、<strong>Entra ID 認証・ロールによるアクセス制御</strong>を活用。</li>
<li>検索の起点を「会話」や「メール」から作ることで、<strong>業務文脈に沿った検索</strong>が可能。</li>
</ul>
<div class="wp-block-table">
<table>
<thead>
<tr>
<th>比較軸</th>
<th>Edge サイドバー</th>
<th>WebView2 ウィジェット</th>
<th>既定検索エンジン切替</th>
<th>Teams/Outlook アプリ</th>
</tr>
</thead>
<tbody>
<tr>
<td>導線の近さ</td>
<td>常駐パネルで即時</td>
<td>タスクトレイで即時</td>
<td>アドレスバーへ一手</td>
<td>業務アプリ内から</td>
</tr>
<tr>
<td>認証/SSO</td>
<td>◎（既存ブラウザー文脈）</td>
<td>◎（実装次第）</td>
<td>◎（既存ブラウザー文脈）</td>
<td>◎（Entra ID 連携）</td>
</tr>
<tr>
<td>UI の自由度</td>
<td>○</td>
<td>◎</td>
<td>△（検索結果はサイト側）</td>
<td>○</td>
</tr>
<tr>
<td>展開の容易さ</td>
<td>○（ポリシー配布）</td>
<td>△（自作・配布要）</td>
<td>◎（ポリシー一発）</td>
<td>○（M365 配布）</td>
</tr>
<tr>
<td>OS 依存度</td>
<td>低</td>
<td>中</td>
<td>低</td>
<td>低</td>
</tr>
</tbody>
</table>
</div>「Windows 検索拡張」で実現する際の設計ポイント
- Latency 予算を 200〜500msに：Windows 側 UI は待機時間に敏感。キャッシュ・CDN・エッジ配置で遅延を削る。
- 匿名応答を前提：検索 API はユーザーコンテキストに依存しない設計に。パーソナライズはクリック先で。
- 安全なフィールドのみ返却：内部メタデータ（権限制御フラグ等）は返さない。漏洩時の影響を最小化。
- URL の寿命管理：署名付き URL を用いる場合は有効期限・ワンスショット・オーディットを実装。
- 障害時のフェールオープン：バックエンドが 500/タイムアウト時は空結果を返し、OS のデフォルト検索（Bing など）へスムーズに回帰。
サンプル：高速に応答する匿名検索 API（設計例）
// GET /api/results?q={query}&client=windows
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: public, max-age=15
{
"query": "ワークフロー",
"items": [
{
"title": "人事ワークフロー申請ポータル",
"subtitle": "休暇・経費・住所変更",
"url": "[https://portal.contoso.example/workflow](https://portal.contoso.example/workflow)",
"type": "portal"
}
]
} 検索 API 自体は匿名で高速応答、クリック後にブラウザーで SSO させるのがポイントです。
セキュリティ設計の観点
- 最小公開原則：API の返却は公開前提の情報に限定。内部 ID／ACL／タグを返さない。
- クリック先の認可：URL 先で本人確認（SSO）し、権限がない場合は「見出しのみ公開」方針に。
- 監査証跡：検索クエリは個人情報を含みうるため、匿名化と集計単位の制御を設計。
- DDoS/濫用対策：レート制限・bot 判定・CDN を活用。Windows 検索 UI のアクセスパターンをホワイトリスト化。
運用・監視・SLO 提案
| 指標 | 目標 | 理由 |
|---|---|---|
| P50 レイテンシ | < 150 ms | 入力中の逐次クエリに追従するため |
| P95 レイテンシ | < 400 ms | UI の体感を維持 |
| エラー率 | < 0.1% | フェールオープンを阻害しない |
| 可用性 | >= 99.9% | 業務時間帯の安定性 |
FAQ（よくある質問）
Q. com.microsoft.windows.websearchprovider を別名にして登録できませんか？ A. できません。予約済み識別子であり、置換ではなく転送先 URL の宣言のみが許容されます。
<dt>Q. 既存の社内 SSO（Kerberos/NTLM/Entra ID）を自動で使えますか？</dt>
<dd>A. いいえ。検索呼び出しは<strong>匿名コンテキスト</strong>であり、ブラウザーの 1st パーティ セッションを流用できません。</dd>
<dt>Q. どうしてもユーザー別の結果を返したいです。</dt>
<dd>A. OS 制約上困難です。<strong>匿名インデックス＋クリック後の認可</strong>か、<strong>Edge サイドバー／Teams アプリ</strong>等の代替導線を推奨します。</dd>
<dt>Q. 画像やリッチカード（プレビュー）を返せますか？</dt>
<dd>A. UI は OS 側が管理するため、<strong>提供できるメタ情報は限定的</strong>です。リンク先での表現に寄せるとよいでしょう。</dd>
<dt>Q. EU 以外でも使いたいのですが？</dt>
<dd>A. 現状は対象外です。<strong>地域差を前提とした代替策</strong>（Edge サイドバー等）の設計が安全です。</dd>
</dl>実装と検証の手順（推奨）
- 要件の棚卸し：匿名検索で十分か／パーソナライズ必須か／応答 SLA／リージョン。
- インデックス設計：公開可能メタデータの抽出、脱機密化、更新パイプライン。
- API 設計：軽量 GET、短い TTL、キャッシュ戦略、障害時フェールオープン。
- AppExtension パッケージング：MSIX 化、署名、配布リング（EU 小規模から段階展開）。
- 観測性：トレース ID 付与、CDN ログ、遅延ヒートマップ。
- 品質検証：入力中クエリ、言語・市場パラメータ、ネットワーク断・高遅延、障害注入。
- セキュリティレビュー：漏洩テスト、URL 署名強度、監査・保存期間。
- 運用 Runbook：障害時の切替手順、ロールバック、連絡フロー。
落とし穴とアンチパターン
- 「Bing を置き換えられる」と誤解：できるのは URL の転送。UI やランキングの乗っ取りではありません。
- クッキーや Kerberos への依存：仕様上送られない前提に。
- 大量のリッチデータ返却：UI が解釈しないフィールドは無駄。帯域と遅延の悪化につながる。
- 長寿命の署名付きリンク：漏洩時のリスク増大。署名は短命・ワンスショットに。
- グローバル同時展開：地域差によるサポートコスト増。まず EU で小さく検証。
サンプル：ポリシーで「既定の検索エンジン」を社内に切り替える（Edge/Chrome）
ブラウザーのアドレスバーを社内検索に向けるだけでも、実利用の 8 割の検索導線を取り込めます。管理テンプレートで次のようなプレースホルダーを配布します（表記は概念例）。
<pre><code>{“Name”: “Contoso Enterprise Search”, “Keyword”: “@contoso”, “URL”: “[https://search.contoso.example/search?q={searchTerms}](https://search.contoso.example/search?q={searchTerms})”, “SuggestURL”: “[https://search.contoso.example/suggest?q={searchTerms}](https://search.contoso.example/suggest?q={searchTerms})”, “IsDefault”: true }
<p>ユーザーは <kbd>Ctrl</kbd>+<kbd>L</kbd> → 検索語 と打つだけで、<strong>社内検索が第一候補</strong>になります。SSO も通常通りに機能します。</p>チェックリスト（実装前・本番前）
| 項目 | 確認内容 | 状態 |
|---|---|---|
| 地域要件 | EU 展開端末での動作確認／他地域は代替策 | □ |
| 匿名設計 | 検索 API は匿名で機密を返さない | □ |
| 遅延 | P95 < 400ms、タイムアウト時は空集合 | □ |
| 可観測性 | CDN・アプリログ・トレース ID の相関 | □ |
| 障害訓練 | 500/タイムアウト注入で UX 崩れない | □ |
| セキュリティ | 署名 URL の TTL・失効・監査 | □ |
| ガバナンス | 検索ログの保持期間・匿名化方針 | □ |
まとめ：OS 組み込み検索との「適切な距離感」を設計しよう
Windows のタスクバー／スタートメニュー検索は、あくまで OS 管理の UX であり、独自 UI・認証・完全置換はできない領域です。com.microsoft.windows.websearchprovider で許されるのはバックエンド URL の宣言と、軽量な JSON 応答のみ。認証やパーソナライズを必要とする企業内検索は、Edge サイドバー／WebView2／Teams アプリ／ブラウザー検索エンジン切替などの導線と組み合わせることで、セキュアかつ使いやすい「全社検索」を実現できます。
本記事のポイントは次の 4 つです。
- Name 属性は変更不可。予約済み識別子であり、Bing の完全置換はできない。
- URL 置換＋JSON 応答のみ可能。UI/認証は OS 側で固定。
- 認証・セッション共有は非対応。匿名設計とクリック後の認可で設計する。
- EU 限定提供。グローバルは代替導線を用意する。
「検索をどこからでも、すぐに」。その要件は、OS 組み込みの仕様を尊重しつつ、最短導線 × セキュリティ × 運用容易性のバランスでデザインするのが成功の近道です。
コメント