WindowsアプリのWeb化、しない方がいいケース ── 判断表と「分割」という現実解

「社内で使っているWindowsアプリを、そろそろWebにしたい」──この相談は年々増えています。もっともな動機であることも多い一方で、話を聞いてみると、Web化するとかえって使いにくく・高くつくアプリを、全面Web化しようとしているケースが少なくありません。

念のため先に書いておくと、この記事は「Web化はやめておけ」という話ではありません。複数拠点からの利用や端末管理の削減など、Web化が明確に正解になる状況はたくさんあります。問題は、Web化が合わない性質のアプリまで一括りに「モダン化=Web化」と決めてしまうことです。この記事では、Windows受託開発の現場で実際に判断に使っている「Web化しない方がいいケース」の見分け方と、全部Webか全部Windowsかの二択にしない分割という現実解を整理します。

1. まず結論(判断表)

アプリ全体ではなく、アプリが持っている機能・性質ごとに判断するのがポイントです。

そして結論を先に書きます。

• 「Web化したい」という要望には、たいてい3つの別の問題が混ざっています。 配布の手間・利用場所の制約・技術の陳腐化です。それぞれ解決策が違い、Web化でしか解決できないのはこのうち一部です(第2章)。
• 装置連携・ローカルファイル処理・オフライン運用のあるアプリは、その部分をWeb化しない方が安全です。 ブラウザはセキュリティ上、ローカル資源へのアクセスを意図的に制限しており、これはWebの欠陥ではなく設計思想です¹。回避策はあっても、対応ブラウザの制限や運用の複雑化という別のコストを持ち込みます(第3〜5章)。
• Web化は「移植」ではなく「作り直し」です。 既存の画面資産はそのまま持っていけず、完成後もサーバー運用という継続コストが新たに発生します。見積もりの前提をここに置かないと、途中で計画が崩れます(第7章)。
• 現実解は分割です。 閲覧・集計・帳票はWebへ、装置連携・現場入力はWindowsに残し、共通のAPIとデータベースでつなぐ。全面Web化より小さく始められ、効果の大きい部分から順に進められます(第8章)。

2. 「Web化したい」の中身を分解する

Web化の相談を受けたとき、最初にやるのは要望の分解です。「Webにしたい」という言葉の裏には、たいてい次の3つのどれか(または複数)があります。

(1) 配布・更新の手間をなくしたい。 「バージョンアップのたびに全端末を回ってインストールしている」という悩みです。これはWeb化で確かに解決しますが、Web化しなくても解決できます。ClickOnceやMSIXといった自動更新の仕組みを持つ配布方式に切り替えれば、Windowsアプリのままで配布作業をほぼゼロにできます。詳しくは「Windowsアプリの配布方法の選び方」で整理しています。配布の悩みだけが動機なら、Web化は過剰投資です。

(2) どこからでも・どの端末からでも使いたい。 複数拠点からの利用、営業先や自宅からのアクセス、タブレットでの参照──これはWeb化の本領です。ただしここでも、「全機能をどこからでも使いたい」のか「データをどこからでも見たいのか」は分けて確認します。実務では後者であることが多く、その場合は閲覧・集計部分だけをWebに出す分割構成(第8章)で足ります。

(3) 古い技術から脱したい。 「作った人が退職した」「.NET Frameworkのままで不安」という動機です。これは正当な問題意識ですが、解決策がWeb化とは限りません。同じ作り直すなら、業務の性質がデスクトップ向きであれば最新の.NETでWindowsアプリとして作り直す選択肢があります(WinForms / WPF / WinUIの使い分け判断表)。また、Webにすれば陳腐化から逃れられるわけではないことも押さえておくべきです。IE専用で作られた社内Webシステムが、IEの終了で行き場を失った事例は記憶に新しいところです(「IEモードによる社内Webシステムの延命と出口戦略」)。Webアプリもフレームワークやブラウザの変化に追従する保守は必要で、「Web化=保守からの解放」ではありません。

この分解をすると、「Web化でしか解決しないもの」「Web化以外でも解決するもの」「Web化しても解決しないもの」が見えてきます。そのうえで、以降の「Web化しない方がいいケース」に該当する機能がないかを確認していきます。

3. ケース1: 装置・周辺機器と直接つながっている

製造装置との通信、計測器・検査機からのデータ取り込み、シリアル(RS-232C)接続のはかり・バーコードリーダー、特殊プリンターの細かい制御──ハードウェアと直接会話する機能を持つアプリは、その部分のWeb化に構造的に向いていません。

理由は単純で、ブラウザ上のコードはサンドボックスという隔離環境で動くからです。Webページを開いただけで端末内のファイルや機器を勝手に触られては困るので、ブラウザはローカル資源へのアクセスを意図的に遮断しています。これはWebの欠陥ではなくセキュリティ設計そのものです。たとえばC#でWebクライアントを書けるBlazor WebAssemblyでも、コードはブラウザのセキュリティサンドボックス内で実行され、ファイルシステムへのアクセスや任意のネットワーク接続は PlatformNotSupportedException になります¹。できることはブラウザの機能の範囲に制限されます²。

「Web Serial APIやWebUSBでブラウザからシリアル通信できるのでは」という反論もあり得ます。確かに存在しますが、対応ブラウザが限られます。Web Serial APIはChrome / EdgeなどのChromium系に加えて、2026年5月リリースのFirefox 151でデスクトップ版Firefoxも対応しましたが、Safariは未対応(モバイルも、Android版ChromeがBluetooth経由のシリアルに部分対応しているにとどまります)で、WebUSBは今もChromium系限定です³。「どのブラウザからでも使える」というWeb化の最大の利点に制限を付けたうえで、装置の接続時には(少なくとも初回や機器追加のたびに)ユーザーがブラウザのダイアログで機器を選んで許可する操作が前提となるため、業務システムの装置連携手段としては割に合わないことが多いのが実情です。

また、「Webアプリ+各端末に常駐する連携エージェント」という構成で回避する手もありますが、これは配布・更新が必要なWindowsプログラムが結局残る構成です。それ自体が悪いわけではなく、むしろ第8章の分割構成の一形態なのですが、「Web化すれば端末に何も入れなくてよくなる」という当初の期待とは別物であることは、計画段階で共有しておく必要があります。

装置連携部分の設計は「外部装置の状態確認・表示のベストプラクティス」も参照してください。

4. ケース2: ローカルファイル・他のアプリと深く連携している

次に多いのが、端末内のファイルや他のアプリケーションとの連携が業務の中核になっているケースです。

• 共有フォルダーやローカルフォルダーを監視して、置かれたファイルを自動処理する
• 数百・数千のファイルを一括で変換・リネーム・振り分けする
• Excelを起動してCOM経由で帳票を組み立てる、既存のExcelマクロと連携する
• 他の業務アプリとファイル・プロセス間通信でデータを受け渡す

ブラウザのファイルアクセスは「ユーザーがその都度ダイアログで選んだファイル」に限定されるのが原則です。ユーザー操作なしの一括アクセスや、ブラウザを閉じていても動き続ける常駐型の監視はできません。近年のFile System Access APIはユーザーが選んだフォルダー単位のアクセスを可能にし、選んだフォルダー内の変更をページを開いている間だけ監視する実験的なAPI(FileSystemObserver)も登場していますが、これらはChromium系限定で⁴、装置連携と同じ「対応ブラウザを縛る」問題を抱えます。ローカルの他プロセス(Excelなど)をブラウザから起動して操作する手段は、そもそもありません。

この種の機能をWeb化しようとすると、「ファイルをサーバーにアップロードしてもらい、サーバー側で処理する」形への業務フローの変更が必要になります。それで業務が成立するなら選択肢ですが、ギガバイト級のファイルを日常的に扱う、社外に出せないデータをローカルで完結処理している、Excel資産と密結合しているといった事情があるなら、その部分はWindowsアプリ(フォルダー監視・一括処理のような無人処理ならWindowsサービス)として残す方が、作る側も使う側も無理がありません。ただしExcelとのCOM連携だけは置き場所に注意が必要です。Microsoftはサービスなどの無人・非対話環境からのOffice自動化を非推奨・非サポートとしているため⁵、Excelを自動操作する処理はユーザーがサインインして使うデスクトップアプリ側に置くか、Officeを起動しないOpen XML系ライブラリでの読み書きに置き換えます。Excel連携の作り方は「Excel帳票出力の作り方」、フォルダー監視は「FileSystemWatcherの安全な基本」で扱っています。

5. ケース3: ネットワークが不安定な現場で、止まれない業務に使う

Webアプリは、その構造上ネットワークが生きていることが前提です。サーバーサイドレンダリング型のWebアプリはもちろん、C#系で人気のBlazor Serverも、すべてのUI操作がサーバーとの常時接続越しに処理されるため、接続が切れるとアプリは動作を停止します。オフラインサポートはない、と公式ドキュメントに明記されています²。

これが問題になるのは、次のような環境です。

• 工場・倉庫・屋外現場: Wi-Fiの電波が金属棚や機械で遮られ、瞬断が日常的に起きる
• 止まれないライン: 記録・指示の画面が数分止まるだけで生産や出荷に影響する
• 回線が細い・不安定な拠点: モバイル回線頼みの仮設事務所、船上・山間部など

ネイティブのWindowsアプリは、ローカルにデータを持ってオフラインでも動作を継続し、回線復旧後に同期する構成が素直に作れます。オフライン動作はMicrosoft自身がネイティブアプリを選ぶ理由として挙げている項目でもあります⁶。PWA(Service Worker)やクライアント側にデータを持つ設計でWebアプリをオフライン対応させることも技術的には可能ですが、同期・競合解決まで含めて作り込むのは相応の追加投資で、「Web化すれば安くなる」という当初の期待とは逆方向に働きます。

判断のポイントは、「ネットワークが30分切れたとき、その業務は待てるか」です。待てないなら、少なくともその業務を担う画面はローカルで動くものにしておくべきです。

6. ケース4: キーボード主体の高速・大量入力が業務の中心

伝票入力、検品・出荷登録、コールセンターの応対画面──1日中その画面に向かって、キーボード中心に大量のデータを打ち込むタイプの業務です。この領域は、デスクトップUIの完成度が高く、Web化で体感品質が下がりやすい領域です。

• 応答の遅延: Blazor Serverのようなサーバー接続型では、すべてのユーザー操作にネットワーク往復が挟まり、UIのレイテンシが高くなります²。1操作あたり数十ミリ秒でも、1日数千操作の入力業務では「引っかかる感じ」として確実に体感されます。
• キーボード操作の再現: Enterでの項目移動、ファンクションキー割り当て、入力中の即時バリデーションといった「入力業務の当たり前」は、ブラウザの既定動作(Enterでフォーム送信、F1でヘルプ等)と衝突しながら作り込むことになります。できないわけではありませんが、デスクトップならフレームワークとグリッド部品が最初から持っている品質に、追加コストを払って追いつく構図です。
• 大量データのグリッド: 数万行を仮想スクロールで軽快に表示し、セル編集・列固定・コピー&ペーストまで対応するデスクトップ級のグリッドをWebで実現するには、高機能な商用コンポーネントの採用と相応のチューニングが必要です。

閲覧・承認・たまの登録程度ならWebのフォームで十分です。しかし入力速度そのものが業務の生産性に直結する画面は、Web化の効果(どこからでも使える)を実際に享受するのか──その画面は結局、事務所の固定席でしか使わないのではないか──を冷静に確認してください。使う場所が固定なら、Web化で得るものはなく、失うものだけがあります。

7. ケース5: 「移植」の見積もりで「作り直し」を始めてしまう

ここまでは機能・利用形態の話でしたが、最後はコスト構造の話です。Web化の計画が途中で崩れる典型パターンは、「今あるものをWebに移す」という移植のイメージで見積もり、実際には作り直しだったと後から判明することです。

• 画面資産は持っていけません。 WinFormsやWPFの画面定義・画面ロジックをWebへ自動変換する現実的な手段はなく、UIは全画面を設計し直して作り直します。画面数×複雑度がそのまま工数になります。
• 業務ロジックの棚卸しが先に必要です。 長年運用されたアプリは、仕様書にない業務ルールがコードの中にだけ存在することが珍しくありません。Web化はそれを全部掘り起こして再実装する作業を含みます。この点はVB6 / Access業務アプリの移行で書いた「いきなり全面リライトしない」原則がそのまま当てはまります。
• 完成後の運用コストが構造的に増えます。 デスクトップアプリの運用は端末の面倒を見ることでしたが、Webアプリではサーバー(またはクラウド)の構築・監視・バックアップ・証明書とセキュリティ更新が継続的な仕事として発生します。社内にその体制がなければ外部委託費が毎月かかります。Web化の費用比較は、初期開発費だけでなくこのランニングコストまで含めて行う必要があります。
• セキュリティの前提が変わります。 社内LANの中だけで動いていたアプリをWebにして社外アクセスを許した瞬間、認証・認可・通信暗号化・攻撃対策の要求水準は一段上がります。これも「Web化の費用」の一部です。

繰り返しますが、これらはWeb化を否定する材料ではなく、正しい前提で見積もるための材料です。作り直しとランニングコストを織り込んでもWeb化のメリットが上回るなら、進めるべきです。上回らないなら、Windowsアプリのままの近代化(最新.NETへの移行、配布方式の改善、UI刷新)という、より小さい投資で動機の大半を満たせないかを先に検討します。

8. 現実解: 全部Webか全部Windowsかの二択にしない

ここまでの判断を実務に落とすと、多くの場合、答えは「全面Web化」でも「現状維持」でもなく分割になります。

考え方は単純で、第1章の判断表をアプリ全体ではなく機能ごとに当てることです。

• Webに出すもの: 複数拠点・複数人から見たいデータの閲覧・検索・集計、帳票のダウンロード、承認などの軽い操作。マスタメンテナンスもたいていここに入ります。
• Windowsに残すもの: 装置・周辺機器との連携、ローカルファイルの監視・一括処理、オフラインでも止まれない現場業務、高速入力の画面。
• 共通にするもの: データベースと業務ロジックです。データを一元化し、WebアプリとWindowsアプリの両方が同じAPI(またはDB)を参照する形にします。ここを共通化しておけば、「現場はWindowsアプリで入力し、本社はブラウザで即座に確認する」という、Web化の動機の大半を満たす構成が成立します。

この構成には、全面Web化にない実務上の利点があります。一度に作り直す範囲が小さいこと、効果の大きい部分(閲覧系)から段階的に進められること、そして現場の使い勝手を落とさないことです。逆に、WindowsアプリとWebアプリの2系統を保守する体制は必要になるので、対象アプリが小さく機能も閲覧中心なら、素直に全面Web化した方がよいこともあります。ここも二択ではなく程度問題です。

なお、「画面はWeb技術で作りたいが、ローカル資源にも触りたい」という要件には、ElectronやBlazor Hybrid(WebView2)のようなハイブリッド型という選択肢もあります。ブラウザのサンドボックス制約を受けずにWeb技術のUIを使えますが、これは配布が必要なデスクトップアプリであり、「ブラウザだけで使いたい」という要望の答えにはならない点だけ注意してください。

9. Web化を決める前のチェックリスト

見積もり依頼や社内稟議の前に、次を確認しておくと手戻りが減ります。

1. 動機の分解: 配布の手間・利用場所・技術の陳腐化のどれが本当の課題か。配布だけなら配布方式の変更で足りないか。
2. ハードウェア連携の有無: シリアル・USB・計測器・特殊プリンターと直接通信する機能はあるか。あるなら、その部分の扱い(Windowsに残す/エージェント構成)を先に決める。
3. ローカル資源への依存: フォルダー監視、ファイル一括処理、Excel等とのプロセス連携はあるか。業務フローをサーバー処理型に変えられるか。
4. オフライン要件: ネットワークが30分切れたとき、その業務は待てるか。
5. 入力業務の比重: 1日中キーボードで打ち込む画面はあるか。その画面は本当に「どこからでも」使うのか。
6. 利用者と場所の実態: 誰が・どこから・何を見たい/入力したいのか。「全員が全機能を社外から」なのか「本社がデータを見たいだけ」なのか。
7. 運用体制: サーバーの構築・監視・セキュリティ更新を誰が担うか。その費用は月額でいくらか。
8. 業務ロジックの所在: 仕様書はコードと一致しているか。棚卸しにかかる期間を見積もりに含めたか。

このうち2〜5に該当項目があるなら、全面Web化ではなく分割構成を軸に検討することをおすすめします。発注前の整理全般は「Windowsアプリ 外注・受託開発を依頼する前に整理したいこと」も参照してください。

まとめ

Web化は道具であって目的ではありません。複数拠点からの利用や端末管理の削減にははっきり効く一方、装置連携・ローカルファイル処理はブラウザのセキュリティ設計に由来する制約のため、フレームワークの選定や作り込みで覆すことが難しく、オフライン運用・高速入力は技術的に対応し得ても、その作り込みと運用のコストが「Web化で楽になる」という当初の狙いと逆行しがちです。そして、Web化は移植ではなく作り直しであり、完成後にはサーバー運用という新しい継続コストが加わります。

だからこそ、実務の判断は「Web化するか、しないか」ではなく、「どの機能をWebに出し、どの機能をWindowsに残し、何を共通化するか」という設計の問題になります。既存アプリの棚卸しからWeb化の可否判断、分割構成の設計まで、コードと運用の実態を見ながらの判断が必要になることが多いので、迷ったらご相談ください。

関連記事

• Windowsアプリ 外注・受託開発を依頼する前に整理したいこと
• VB6 / Access業務アプリの延命と移行 ── 残す・包む・置き換えるの判断表
• WinForms / WPF / WinUIの使い分け判断表
• Windowsアプリの配布方法の選び方(MSI / MSIX / ClickOnce / xcopy / 自作アップデーター)
• IEモードによる社内Webシステムの延命と出口戦略
• 外部装置の状態確認・表示のベストプラクティス
• FileSystemWatcherの安全な基本
• Excel帳票出力の作り方

関連する相談領域

合同会社小村ソフトでは、既存WindowsアプリのWeb化可否の判断、Web+Windowsの分割構成の設計、装置連携・ローカル処理を含む業務アプリの開発・改修に関する技術相談を扱っています。

• Windowsアプリ開発
• 既存Windowsソフトの改修・保守
• 技術相談・設計レビュー
• お問い合わせ

参考リンク

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

古いWindowsアプリを更新するなら、ついでにWeb化した方がよいですか？

「古いから」だけを理由にWeb化するのはおすすめしません。Web化は移植ではなく作り直しに近い工数がかかるうえ、Webアプリにも技術の陳腐化はあります(社内WebシステムがIE専用のまま残った事例はその典型です)。判断の軸は技術の新旧ではなく、そのアプリの利用形態です。複数拠点から使う・端末管理を減らしたいならWeb化のメリットが出ますが、装置連携やローカルファイル処理が中心なら、.NETの新しいバージョンへの移行やUIの改修など、Windowsアプリのままの近代化の方が費用対効果に合うことが多いです。

Web化すれば、配布やインストールの手間はなくならないのですか？

クライアント側の配布作業はなくなりますが、「配布の手間をなくしたい」だけが動機なら、Web化より軽い解決策があります。ClickOnceやMSIXなど自動更新の仕組みを持つ配布方式に切り替えれば、Windowsアプリのままでも各端末を回ってのインストール作業はほぼ不要にできます。またWeb化した場合は、代わりにサーバー(またはクラウド)の構築・監視・セキュリティ更新という継続的な運用コストが新しく発生します。なくなるコストと増えるコストの両方を見て判断してください。

アプリの一部だけをWeb化することはできますか？

できますし、実務ではむしろその形が現実解になることが多いです。典型的なのは、データの閲覧・集計・帳票・複数拠点からの参照をWebに出し、装置連携・現場での高速入力・ローカルファイル処理はWindowsアプリとして残し、両者を共通のAPIとデータベースでつなぐ構成です。全面Web化に比べて一度に作り直す範囲が小さく、Web化の効果が大きい部分から段階的に進められます。

ElectronやPWA、Blazor Hybridのような中間的な選択肢はどうですか？

性質の異なるものが混ざっているので分けて考える必要があります。ElectronやBlazor Hybrid(WebView2)はデスクトップアプリとして動くため、ブラウザのサンドボックス制約を受けずにファイルや装置へアクセスでき、画面はWeb技術で書けます。ただし配布・更新が必要なデスクトップアプリである点は変わらず、「ブラウザだけで使えるようにしたい」という要望への答えにはなりません。一方PWAは、タスクバーへのピン留めなどインストールしたような使い勝手になっても、中身はブラウザ上のWebアプリのままで、ローカル資源へのアクセス制約も通常のWebアプリと同じです。何を解決したくてWeb化を検討しているのかを先に分解することが重要です。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。