共有ネットワークドライブ上に置いたWPFアプリが、PC起動後の初回だけ18秒かかる——この症状は「アプリが重い」よりも「ネットワークから直接実行している」ことが原因で起きがちです。差が出る仕組みを押さえたうえで、現実的に起動を速くする手段（配布は共有、実行はローカル）を具体手順つきで解説します。
現象：ローカルは3秒、共有ドライブは18秒。しかも“初回だけ”遅い
今回の前提は次のような状況です。
- WPFアプリ（.exe と複数の .dll）を共有ネットワークドライブに配置している
- ユーザーがPC起動後に最初に起動する1回だけ極端に遅い
- 体感の差が大きい（例：ローカルCドライブ約3秒／共有ネットワークドライブ約18秒）
ここで重要なのは、「2回目以降はそこそこ速い」＝「アプリのコードだけが遅いわけではない」可能性が高い、という点です。WPFの初期化最適化（遅延ロード、非同期化、リソース分割など）はもちろん有効ですが、“ネットワーク直実行”という土台がボトルネックだと、改善幅に天井ができます。
なぜ共有ドライブからの初回起動だけ遅くなるのか（仕組み）
共有ドライブからアプリを直接起動すると、起動時に発生する「小さな待ち」がいくつも積み重なります。ローカル実行だと数ミリ秒で終わる処理が、ネットワーク経由では一気に“秒”になります。
| 要因 | 起きること | 初回に効きやすい理由 |
|---|---|---|
| SMB接続のウォームアップ | 共有への最初のアクセスで認証・セッション確立・名前解決が走る | PC起動直後はDNS/AD/証明書周りも含めて“まだ温まっていない” |
| 多数ファイルの読み込み（exe/dll/設定/リソース） | .NETは複数アセンブリを順次ロードし、依存関係も探索する | ファイル数が多いほど往復回数が増え、遅延が積み上がる |
| ウイルス対策・セキュリティ検査 | 実行ファイル／DLLの読み込み時にスキャンが入ることがある | “初回アクセス”や“初回実行”でチェックが厚くなる構成が多い |
| OS/アプリのキャッシュ差 | 2回目以降はメモリ／ファイルキャッシュに乗って速くなる | 起動直後はキャッシュが空（コールド）で差が最大化する |
そして本質はここです。
共有ドライブから“実行”している限り、起動時には必ずネットワークI/Oと検査が絡むため、アプリ側の軽量化だけでは限界があります。実際、空に近いWPFプロジェクトでも「ネットワーク直実行だと遅い」ケースは珍しくありません。
結論：現実解は「配布は共有、実行はローカル」
起動時間の差を根本から詰めるなら、構成を変えるのが最短です。
- 共有ドライブ：配布場所（最新版を置く場所）
- クライアントPC：実行場所（ローカルに置いて起動）
この形を“少ない運用負荷で”実現しやすいのがClickOnceです。初回はインストール（コピー）を伴うので多少遅くなりますが、2回目以降はローカルから起動になるため、Cドライブ実行と同等の体感に寄せられます。
採用されやすい解決策：ClickOnceでローカルにインストールして実行する
ClickOnceの動き（何が嬉しいのか）
- 共有フォルダに発行した成果物（.application等）を置いておく
- ユーザーは共有上の.applicationを実行する
- 初回：必要ファイルがローカルPCへコピー（インストール）され、その後起動
- 2回目以降：ローカルにある実体を起動（共有は更新チェックや差分取得に利用）
つまり、ネットワーク直実行で発生する「起動のたびの大量I/O」を、ClickOnceが“初回（または更新時）にまとめて”吸収してくれます。
手順イメージ（運用まで含めた最短ルート）
- Visual StudioでWPFアプリをClickOnceとして発行する
- 発行先フォルダ（例：bin\publish 相当）一式を共有ネットワークドライブへコピー
- クライアントは共有上の.applicationを実行
- 初回：インストールが走る
- 以降：ローカル実行（高速）
発行設定で迷いやすいポイント（おすすめの考え方）
| 項目 | おすすめ | 理由 |
|---|---|---|
| インストールの形 | （業務アプリなら）スタートメニューに登録される形 | ユーザーが次回から迷わない／ショートカット運用しやすい |
| 更新チェック | 起動時チェック or 定期チェック | 起動が重要なら「起動時」、業務時間帯を避けるなら「定期」 |
| 署名（証明書） | 社内CA or 正式なコード署名証明書 | 警告を減らし、社内展開での信頼性・説明コストを下げる |
| 発行場所 | 共有フォルダ（読み取り可能な場所） | 配布の一元化ができる／更新反映が簡単 |
「とにかく早くしたい」場合、更新チェックを“毎回起動時”にすると更新検出は確実ですが、環境によっては共有アクセスの待ちが毎回少し乗ります。現場では起動パフォーマンスと更新確実性のバランスを見て決めるのがコツです。
ClickOnce導入でハマりがちな落とし穴と対処
共有フォルダ上のアプリが警告される／実行がブロックされる
企業環境では、共有パスが「インターネット扱い」になっていたり、ポリシーで厳しめに制御されていたりします。対処の方向性は主に次の3つです。
- 署名（マニフェスト署名）を正しく行い、信頼チェーンを通す
- 共有パスをローカルイントラネット相当として扱う（ポリシーやゾーン設定）
- 配布経路を共有フォルダから配布サーバー／ポータルに変える（後述）
セキュリティを下げる方向（ウイルス対策の無効化など）で解決しようとすると、後で必ず揉めます。「正しく信頼させる」設計に寄せるのが長期的にラクです。
初回インストールが遅い／失敗する
初回はネットワークからコピーするため、回線や共有の混雑、アクセス権、空き容量、プロキシ/証明書などの影響を受けます。以下のチェックが効きます。
| チェック項目 | 見方 | 対処例 |
|---|---|---|
| 共有フォルダ権限 | 読み取り・一覧・実行の権限が揃っているか | ユーザー/グループ単位で見直し、継承も確認 |
| クライアントの空き容量 | ユーザープロファイル領域が逼迫していないか | キャッシュ整理、別ドライブ運用、容量監視 |
| ネットワーク混雑 | 朝イチだけ遅い／拠点差が大きい | 差分更新の設計、配布拠点の分散、配布時間の調整 |
| セキュリティ製品のスキャン | 特定PCだけ極端に遅い | 署名・信頼設定の整備（除外は最終手段） |
「アプリの軽量化」で改善できる範囲と、限界
質問にあった「ファイルサイズ削減」「WPFアプリの最適化」でどれくらい効くかを、期待値がズレないように整理します。
効くこと（ただし“土台がローカル”のときほどではない）
- 依存DLLの数を減らす：ファイル数が減るほどネットワーク往復が減り、初回の遅さが少しマシになる
- 重い初期化を後回し：ウィンドウ表示を先に出し、データ取得や解析は後で行う（体感改善が大きい）
- 遅延ロード：使う画面・機能のDLLやリソースを必要時に読む
- スプラッシュスクリーン：待ち時間を“処理中”として正しく見せる（UX向上）
効きにくいこと（ネットワーク直実行が原因の場合）
- 「コードを速くする」だけで、共有ドライブ起動の初回18秒を3秒へ寄せる
- 画像やXAMLを多少削っても、ネットワークI/O + セキュリティ検査 + 接続確立の壁は残る
つまり、最適化は無駄ではありません。ただし、“共有から直接実行”という前提を変えない限り、期待するほど縮まらないことが多い、というのが現実です。
代替案：ClickOnce以外で「配布は共有、実行はローカル」を実現する方法
ClickOnceが組織のポリシーや要件に合わないケースもあります。その場合の現実的な選択肢を並べます。
| 方式 | 概要 | メリット | デメリット/注意 |
|---|---|---|---|
| ローカルコピー方式（自作ランチャー/スクリプト） | 起動前に共有からローカルへコピーして実行 | 自由度が高い／既存構成を崩しにくい | 更新判定・差分・ロールバックなどを自前実装する必要 |
| MSIX等のパッケージ配布 | パッケージ化して配布基盤からインストール | 管理・更新が強い／企業配布と相性が良い | 環境整備が必要／既存アプリの相性確認が要る |
| ソフト配布製品（SCCM/Intune等） | 社内の標準基盤で配布・更新 | 統制が効く／監査・レポートが強い | 運用コストが上がる／小規模には重い |
| 仮想化/リモート実行（Citrix/RDS等） | アプリをサーバー側で実行し画面転送 | クライアント依存が減る／データを外に出しにくい | 基盤コスト／設計が別物になる |
「とにかく手早く、しかも更新も含めてラクにしたい」なら、やはりClickOnceは強い選択肢です。逆に「配布の統制・監査が最重要」なら、配布基盤（Intune等）へ寄せると全体最適になりやすいです。
現場で効く：原因の切り分け（“本当にネットワークがボトルネック？”を確かめる）
対策の前に、どこで時間を食っているかを確認すると、打ち手がブレません。おすすめは次の観点です。
1) “ファイル読み込み”が遅いのか
- .exe起動直後に、.dll読み込みで待っていないか
- 特定の大きなファイル（画像・辞書・DBなど）で止まっていないか
ファイル単位で遅延が見えると、「DLL数削減」「遅延ロード」「ローカルキャッシュ」の効果見込みも判断しやすくなります。
2) “認証・接続確立”で遅いのか
- PC起動直後だけ共有ドライブが不安定（マップが未接続、再接続中）
- 朝イチやログオン直後に偏って遅い
この場合、アプリ最適化よりも配布方式の変更（ClickOnce等）が最短です。応急処置としては、ログオン時に共有へ軽くアクセスして“温める”運用（例：共有内の小ファイルにアクセスする）で改善することもありますが、根治ではありません。
3) “セキュリティ検査”が重いのか
- 特定端末だけ遅い、または同じ端末でも日によってブレる
- 実行ファイルを更新した直後ほど遅い
この場合は、署名の整備や信頼パスの設計が効くことが多いです。セキュリティチームと合意形成しやすい形で進めるのがコツです。
ClickOnce運用を失敗しないための設計メモ
ClickOnceは“設定すれば終わり”ではなく、運用の形を決めておくと安定します。
更新設計：どのタイミングで誰が更新するか
- 頻繁に更新するなら、差分更新とリリースノート（簡単で良い）をセットにする
- 業務時間に影響が出るなら、更新チェックを“起動時”ではなく“定期”へ寄せる
- トラブル時のために、ひとつ前の版へ戻せるように発行フォルダを世代管理する
データ保存：アプリフォルダに書かない
共有配布・ローカル実行に移ると、「アプリフォルダにログや設定を書いていた」設計が露呈しがちです。設定やログは、ユーザーごとの領域（例：AppData配下など）へ保存する設計に寄せるとトラブルが減ります。
サポート：問い合わせで最初に見るポイントを決めておく
- 「初回だけ遅い」なのか「毎回遅い」なのか
- 遅い端末に偏りがあるか（拠点・回線・セキュリティ製品の差）
- 直前にアプリ更新があったか
まとめ：起動速度の本命は“実行場所”をローカルに寄せること
- 共有ネットワークドライブからWPFアプリを直接実行すると、起動時にネットワークI/Oや検査が積み上がり、初回起動が極端に遅くなりやすい
- DLL遅延ロードや非同期化などの最適化は有効だが、直実行がボトルネックだと改善幅に限界がある
- 現実的な解決策は、「配布は共有、実行はローカル」へ構成変更すること
- その実現手段として、ClickOnceで発行 → 共有に配置 → .applicationからインストール＆ローカル実行が運用負荷と効果のバランスが良い
コメント