2026年のWebヘルプデスク:料金、現状、代替案

「Webヘルプデスク」が今意味するもの

このフレーズをGoogleに入力する人には、2つのタイプがある。

1つ目は特定の製品を探している人だ。SolarWinds Web Help Desk、Javaベースのオンプレミス型チケット・資産管理ツールで、K-12(初等・中等教育)学区や中堅企業のITで昔からずっと定番になっている。この人はたいてい更新見積もりを目の前にしている。

2つ目は文字通りの意味で使っている人だ。重いクライアントをインストールせず、ブラウザで開くヘルプデスクという意味だ。この区別が意味を持っていたのは2011年頃までで、今はもう死んでいる。ブラウザが勝ったからだ。トップヘルプデスクソフトウェアのまとめ記事に載っているツールはすべてブラウザで動くので、「Webベースかどうか」はもう何も区別しない。

2026年にツールを区別しているのは、もっと地味でもっと高くつくものだ。誰がサーバーを運用するかと、AIメーターが何を数えるかである。セルフホストとは、OS、データベース、ランタイム、そこに降ってくるすべてのCVEを自分たちで抱えることを意味する。クラウドとはそれをベンダーが抱え、その対価を請求されることを意味する。そしてどちらの上にも2つ目のメーターが乗っており、その単位はベンダーごとに大きく異なる。ここがほとんどの購入者が誤解する部分だ。この層の分かれ方については、ヘルプデスクシステムが実際に何で構成されているかを書いた記事でより詳しく掘り下げた。

私は普段、AIとこうしたツールの間をつなぐコネクタを作る仕事をしている。だから、どのヘルプデスクを見るときも、マーケティングページより一段下から見る。実際に何と連携できるのか、APIで何ができるのかだ。Web Help Deskが興味深くなるのはここで、しかもあまり良い意味ではない。製品ページによると、連携リストはSolarWinds製品、NPM、NCM、SAM、Damewareのみ。SlackもTeamsもJiraもない。APIガイドはPDF形式で公開されている。

SolarWinds Web Help Deskの現状

これはSolarWinds自身の製品ページに掲載されている、Web Help Deskの定番のチケットキュー画面だ。デモデータの日付に注目してほしい。

そのサンプルチケットには10/24/16、11/4/16、6/6/17という日付が刻まれている。9年前のデモデータを使い続けて製品を宣伝しているベンダーは、意図せず何かを物語っている。

とはいえSolarWindsは実際に作り直しており、その点は公平に評価したい。バージョン2026.1は2026年1月28日に新しいフレームワークと新しいインターフェースを引っさげてリリースされ、2026.1のリリースノートはその理由を率直に語っている。このリリースでSolarWindsのCVEが6件修正され、そのうち4件は深刻度9.8のCriticalで、Horizon3.aiとwatchTowrの研究者が発見した未認証のリモートコード実行バグ2件も含まれていた。この作り直しはロードマップ上の項目ではなかった。対応措置だったのだ。

そしてリリースの流れは脱線した。

バージョン2026.2は2026年6月2日に一般提供が開始された。そのリリースノートページには今、追加の品質確認作業が完了するまでリリースポータルからWeb Help Desk 2026.2を削除したこと、最新のWHD機能を利用するにはWHD 2026.1をインストールする必要があることだけが記されている。システム要件のページは404を返す。

アップグレードがうまくいかなかった理由は、SolarWinds自身のTHWACKコミュニティのアップグレードスレッドで説明されている。これはベンダー自身のプロパティに顧客が投稿したものだ。

"We attempted to upgrade from 2026.1.21465 to 2026.2.0.77—twice—and both attempts ended in complete failure, forcing us to roll back each time. Even with support involved and additional changes implemented, the outcome didn't improve in the slightest. The upgrade doesn't just introduce minor issues; it fundamentally breaks core functionality, either severing the database connection or outright corrupting it."

vsharmamr, Sys Admin, THWACK

同じスレッドで、あるCTOはもっと厄介な壁にぶつかった。インストーラーがSQL Server 2017以降にしか存在しないSQL関数を必要とする一方、公開されている要件はいまだにSQL Server 2014対応を謳っているのだ。THWACKでの本人の言葉を借りれば、これは「ホットフィックスかバージョンの再リリースが出るまで、これを棚上げにするしかない」という状態だ。

ここに板挟みの状況がある。リリース履歴によると、12.4から12.8までのすべてのバージョンが、2026.2が一般提供された当日である2026年6月2日に終了アナウンスを受けた。5バージョンすべてが2026年7月4日にエンジニアリング終了を迎え、これはすでに過ぎている。5バージョンすべてが2026年11月30日にテクニカルサポートを終了する。

つまり、今12.xを使っているなら、すでにエンジニアリング終了を過ぎており、サポートの猶予はあと4カ月、しかもアップグレードできる唯一のバージョンは、その後継版が取り下げられたものだけという状況だ。これは製品終了ではない。正確を期すと、SolarWindsは製品ライン自体の終了日を公表していない。しかし今やすべてのドキュメントページに「クラウドへのアップグレードをお考えですか?Web Help DeskからService Deskへの移行について詳しく」というバナーが表示されており、5段階の移行ガイドと無料の移行ツールがそれを後押ししている。

2026年のWeb Help Deskの料金

料金表全体は、メインの製品ページからはリンクされていない価格ページに掲載されている。全階層、年払い、技術者単位、エンドユーザー数は無制限だ。

ライセンスモデルについて、SolarWinds自身は同じページでこう述べている。Web Help Deskは「年間サブスクリプションとしてのみ販売される。価格は技術者1人あたり、年単位」だ。資産検出、ハードウェアとチケットの紐づけ、ソフトウェアライセンス管理は追加費用なしで含まれており、これがこの契約の一番良いところだ。

問題は、その一文が何に取って代わったかだ。2025年8月1日までは永久ライセンス製品であり、それこそが多くの人がこの製品を選んだ理由そのものだった。

"We chose WHD because it was simple, on-prem, and didn't hit us with recurring costs every year. But now, with the switch to subscriptions, the long-term costs are significantly higher, and the timing couldn't be worse, with budget season already behind us and the new school year around the corner."

u/BeardyAssetGuy, r/sysadmin, Reddit

その8カ月後、別のK-12学区も同じ内容を投稿した。ユーザー数約1,400人、エージェント85人、1日あたり100〜150件のチケットという規模で、コスト上昇を理由に代替案を検討している。これが解約のパターンであり、今も続いている。

これについて階層計算機を公開している人は誰もいないので、ここに用意した。技術者数と月間チケット数を入力すると、どの階層に該当するかがわかる。さらに、メーターが座席ではなくチケットになった場合、同じ1年間のコストがどう変わるかも比較できる。

この2つの列は同等のものではなく、ウィジェットにそう思わせるより先に、はっきり言っておきたい。ライセンスはキューを買うものであり、解決件数単位の料金はその上にオートメーションを買うものだ。この2つを並べた意図は、単価そのものよりも単位のほうが請求額を大きく左右するということであり、座席メーターとチケットメーターはチームについてまったく異なる問いに答えるということだ。

Web Help Deskが得意なこと

ここでは公平さが重要だ。実際、この製品を満足して使っている人は多いからだ。私が見つけた中で最も的確なまとめは、10年来のユーザーが2026年6月に書いたものだった。

"In a large zoo environment where IT supports everything from traditional office systems to specialist operational infrastructure, reliability and ease of use are critical, and Web Help Desk consistently delivered on both. While there are more modern alternatives available today, it remains a solid solution for organisations looking for straightforward, cost-effective help desk and ticket management capabilities."

Craig M., IT Infrastructure Engineer, Capterra

G2では60件のレビューで3.9/5、Capterraでは124件のレビューで4.1/5。多くの人が「古い」と評するツールとしては、立派なスコアだ。

誰もが真っ先に挙げる機能は、チケットに溶接されたような資産管理だ。単に横に付いているのではない。資産レコードにはモデル、設置場所、部門、割り当てられたクライアント、サービス契約、保証情報が含まれ、チケット履歴に直接リンクする。

これこそが、学校や中堅企業のITでこの製品が生き残ってきた理由のすべてであり、モジュールとして別売りではなくライセンスに含まれている。資産管理が目的でここに来たのなら、資産管理向けAIとハードウェアリクエストについての記事で、オートメーションを加えたその層がどう見えるかを解説している。

設定の柔軟性が2つ目の本当の強みだ。リクエストタイプはツリー状にネストでき、それぞれに担当リードテクニシャンを割り当てられる。これがルーティングの組み立て方だ。

変更管理についても本格的な仕組みがあり、これには驚かされた。承認者数を設定できる2系統のChange Advisory Boardプロセスに加え、拠点・部門ごとの承認者ロールもある。この価格帯のツールの多くにはこれがまったく存在せず、WHDには変更管理がないというあるG2レビュアーの主張は単純に時代遅れだ。

3つ目はレポート機能だ。Capterraでレビューしたある社長は、レポート機能を「他のパッケージと比較して驚異的」と評した。実際、レポートビルダーではツールを離れることなく、拠点・モデル・ステータスをまたいで資産数やチケット数をピボットでき、これはいくつかのクラウド製品よりも優れている。他のレビュアーからの注意点も2つある。高度なレポートやカスタムレポートには相応の手間がかかること、そしてカスタム列を増やすとインターフェースが遅くなることだ。レポート層で苦労した経験があるなら、カスタマーサービスのトラッキングについての記事で、購入前に確認すべき質問をまとめている。

価格表に載っていないセルフホスティングの請求

セルフホスティングこそが、人々がこのツールを選んだ理由だ。そして同時に、去っていく理由でもある。どちらも本当のことであり、正直に言えば、オンプレミスはコストのコントロールを与える代わりに、メンテナンスという対価を課してきた。

更新前に印刷しておきたいのが2026.1のシステム要件だ。対応する最新のJavaはOpenJDK 11.0.28。最新のSQL Serverは2019で、2022を使っている場合は対応マトリクス外になる。最新のActive Directoryは2012 R2。最新のmacOSはMonterey。RAMは3GBに加え、技術者10人ごとに1GBが必要で、設定画面ではなくwhd.confを編集して調整する。RHEL 8または9はバンドルされたPostgreSQLをまったく使えないため、最新のRHEL環境では2台目のデータベースサーバーが必要になる。

次にポートの問題がある。8443と8080に加え、メール、LDAP、資産検出のために合計で25個ほどのポートが必要で、WMI検出は「ポート135を使い、その後さらなる通信のためにランダムなポートを選択する」。これはセットアップ作業ではなく、恒久的なファイアウォールとの折衝になる。

人々を離脱させた最大の要因はセキュリティの実績であり、それを最もよく言い表しているのは、本当は離れたくなかったあるシステム管理者の言葉だ。

"We are just not okay with the continuous stream of CVEs coming out of Web Help Desk lately, some for things as dumb as hardcoded credentials which have been there all along, and which tend to be public before patches exist, requiring us to remove remote users' access to the helpdesk without VPN (make it not web facing) until patched, and then when the patches are released, the first iteration of them breaks a lot of things, rinse and repeat. And they charge a substantial amount for this "maintenance"."

u/PowerShellGenius, r/sysadmin, Reddit

反論も紹介する価値がある。同じスレッドのシステム管理者たちが指摘していたことだ。そもそもこれをインターネットに公開すべきではなく、実際にいくつかのチームはゼロトラストトンネルの背後で運用している。それは結構なことだ。しかしCVE-2025-40551が発生したとき、あるインターネット全体のスキャンでは19,200件の露出インスタンスが確認されており、実際には多くの人が公開しているということになる。これは後にCISAの既知の悪用済み脆弱性リストに追加された。

アップグレードの痛みは、もっと静かな形の代償だ。PostgreSQLのバージョンはリリースごとに飛び、バックアップの復元経路を行き詰まらせる。r/Solarwindsに投稿したある管理者は、「アップグレードするとpgsql9フォルダが消え、pgsql13に置き換わってしまう」と気づき、元のデータベースを復元できなかった。

そしてG2で最も新しい批判的なレビュー、2026年4月にあるCTOがつけた2.5/5では、上位3つの問題としてUI、「インストール・アップグレード・メンテナンス」、外部システムとの連携不足が挙げられている。このレビューは作り直しの後に投稿されたもので、2026.1がこちらの半分の問題は解決していないことを示す最も明確な証拠だ。

頼り切る前に知っておくべきことがもう1つある。2026.1の新しいインターフェースはWindows限定で、バッチファイル経由のオプトイン、別のログインURLでの利用となり、SAML認証、Linux、macOS、FIPSインスタンス、そしてCAB・拠点・部門の承認機能が使えなくなる。SAMLを使っているなら、旧UIにとどまるしかない。

AIレイヤーはロードマップ項目であり、機能ではない

誰かにこのキューへAIを載せるよう頼まれたなら、ここが重要なセクションだ。

Web Help Deskのリリース済みバージョンにAIは一切存在しない。2026.1のリリースノートに挙げられている機能はちょうど2つ、作り直されたフレームワークと新しいインターフェースだけだ。AIによるチケット要約は2026年1月のローンチ投稿の「長期的な展望」の項目に登場し、将来予測に関する免責事項付きで書かれている。それが2026年6月の投稿で再び、新しいスタックが「実現する」ものとして登場する。4カ月の間隔をおいて、どちらも未来形のままだ。SlackやTeamsとの連携、リッチテキストのメモ、マルチタブ、Androidアプリも同じリストに載っている。SolarWinds AIはWeb Help DeskではなくService Deskの機能だ。

実際に出荷されているのは昔ながらのルールベースの自動化で、これは悪くない。IMAP・POP・Exchange経由のメールからチケットへの変換、部門別のルーティングルール、問題がクローズすると子インシデントも自動クローズする親子リンク、リマインダー間隔を設定できるSLAエスカレーション、そしてナレッジベース記事のサジェストだ。AIが登場する前にこれだけでどこまで対応できるか知りたいなら、自動化されたワークフローとSLA管理についてのガイドが実践的な参考になる。

ここが、誰かに教えておいてほしかった部分だ。**AIレイヤーを載せるために、ヘルプデスクを移行する必要はない。**これは私がチームがやりがちな間違いを見てきた点だ。「AIが欲しい」を9カ月がかりのプラットフォーム移行の理由にしてしまうが、実際にはAIは1つのレイヤーであり、キューも1つのレイヤーであり、両者は切り離せるものなのだ。

これは具体的な経験に基づいて言っている。eeselでは何年にもわたって、実際に稼働しているサポートキューでAIエージェントを運用してきており、公開している数字にはあまり格好の良くない側面も含まれている。ZendeskとShopifyで月間約1,000件のチケットを処理しているドイツのオンライン宝飾品小売業者での実トラフィック試験では、当社のエージェントは284件のチャットにわたり93%のトリアージ精度、100%のスパム検出(誤検知ゼロ)を達成した一方、同じ運用の中でそのまま送信されたドラフトはわずか12%で、事実誤認率は7%だった。この2つ目の数字のペアこそが、すべてのロールアウトが顧客に触れる前に過去のチケットに対してシミュレーションされる理由だ。

これは痛い目にあって学んだことだ。デンマークの太陽光発電事業者を含む当社の有料顧客のもとで、ナレッジベースに該当する回答がなかった際に、ボットが回答をでっち上げて実際の顧客に送ってしまったことがある。そこから、厳格な信頼度しきい値と「回答を拒否する」フォールバックが生まれた。だからこそ私は、そうした仕組みなしで語られるデフレクション数値を疑ってかかる。サポートにおけるAIハルシネーションについての記事に詳しい内容をまとめている。

うまくいったときはこうなる。許可を得た顧客レビューからの引用だ。

"In the first month, eesel is resolving 73% of our tier 1 requests. eesel offers easy Zendesk implementation and setup. Our team implemented and achieved results quickly during our 7-day trial. Responses are simple to fix and adjust. The platform even includes automations for ticket tagging, assignment, and status updates!"

AIをめぐるもう半分の問題は、メーターが何を数えているかであり、これについては誰も事前に警告してくれない。あるZendeskの顧客は、課金対象となる解決の定義が変わったときに、それを率直にこう言い表した。

"Complete trash lol, stuff I used to get free now counts as an AR. Most of the ARs are abandoned chats. There's no dispute resolution process."

u/Kerrick, r/Zendesk, Reddit

ここでの不満は価格ではなく単位そのものにあった。AI解決率とそれを改善する方法についての記事で、ベンダーに何を求めるべきかをまとめている。

Web Help Deskのチームが実際に向かっている先

r/sysadminの2026年3月の代替案スレッドが、現時点で最も新しい全体像を示している。移行先は、そのチームがまだサーバーを運用したいかどうかできれいに分かれる。

クラウドITSMの選択肢を比較検討しているなら、Freshservice対ServiceNowの比較記事がエンタープライズ寄りの視点をカバーし、Jira Service Managementについての記事がAtlassian系のルートをカバーしている。

AIの観点に絞るなら、まずITヘルプデスク向けベストAIから始め、次にZendeskとJSMの比較を見るとよい。

この表のすべての行に共通する警告が1つある。チケット履歴はきれいには移行できないということだ。

"We gave up on trying to export and port tickets from WHD to JIRA SM. Too many different fields that would have required A LOT of manual work to match up. There are paid services that we could have used but our budget is already thin so... Just ended up exporting all the tickets from WHD into PDFs and storing them on our file server if we ever need to search them."

u/gwig9, r/sysadmin, Reddit

ある学区は、チケットアーカイブ全体をPDF化してファイルサーバーに保存した。誰もデータのコストを見積もっていない移行予算とは、こういうものだ。そしてこれは以前よりも重要度が増している。過去のチケットは、後から追加するAIレイヤーの学習材料になるからだ。チケットの滞留を解消するについての記事が、キューではなくアーカイブから話を始めているのも同じ理由からだ。

もう1つ知っておく価値があるのは、そもそも移行を拒んだ顧客もいるということだ。あるショップは永久ライセンスを保持したままサポートを解約し、代替製品を探しながらアップグレードを見送った。これは、インスタンスが社内限定でパッチも適用されているなら正当な選択だが、インターネットに公開されているなら悪手だ。

次の1年を契約する前に確認すべきこと

私なら尋ねる順番で、5つの質問を挙げる。

1. 今使っているバージョンは何か? 12.xなら、サポートは2026年11月30日に終了し、アップグレード先は2026.1しかない。まずこれを確認すること。
2. インターネットに公開されているか? CVEの履歴とCISAのリストを踏まえると、これが残りの項目の緊急度を決める。
3. 実際のライセンス数はいくつか? エンドユーザーではなく技術者数を数え、どの階層に該当するかを確認すること。6人目の技術者を追加すると階層が変わる。
4. 実際にサポート対象のマトリクスにとどまれるか? Java 11、SQL Server 2019、Active Directory 2012 R2。インフラチームがこれらのいずれかを超えて移行しようとしているなら、それは更新ではなく矛盾だ。
5. キューを置き換える必要があるのか、それともレイヤーを追加すればよいのか? これらは予算の異なる別々のプロジェクトであり、実際に人々が本当に求めているのはたいてい後者だ。AIヘルプデスクについてのガイドが正直なスコープの目安になり、チケットデフレクションについての記事が数字面で期待できることをまとめている。

念のため私自身の見解を述べておくと、インスタンスが社内限定で、資産インベントリがそこに居続ける理由であり、技術者数も少ないなら、きちんと計画を立てながら2026.1をもう1年更新するのは十分に理にかなっている。一方、インターネットに公開されている、技術者数が30人を超えている、あるいはインフラチームがすでにSQL Server 2022に移行しているなら、11月30日が期限であり、私なら今四半期のうちに評価を始める。

すでに運用中のキューでeeselを試す

この決断を後押ししているのが「ITサポートにAIが必要だ」ということなら、ヘルプデスクに一切手を加えずにそれを試すことができる。eeselは、すでにあるキューに接続するAIレイヤーであり、過去のチケットと既存のドキュメントから学習し、送信ではなくドラフト作成から始めるので、誰かに回答が届く前に、eeselが何を答えていたはずかを確認できる。

この決断に特に合っている理由は2つある。1つ目は、本番稼働前に過去のチケットに対してシミュレーションを行うため、計画の前提になる解決率の数字がベンダーのベンチマークではなく、自分たちの実際のトラフィックで測定されたものになることだ。2つ目は、eeselの料金は処理したチケット1件あたり0.40ドルで、座席料金も最低利用料金もなく、キューの一部だけをルーティングできることだ。つまり、プラットフォーム移行ではなく、200件のパイロットなら80ドルで済む。

コネクタの面では、Jira Service Management、Microsoft Teams、Slackに接続でき、チケットキューと、実際にITリクエストが届く2つの場所の両方をカバーする。

適合性については率直に言っておきたい。Web Help Deskとの連携はないため、これはあなたが次に移行する先のためのレイヤー、あるいは今日チームに届いているTeamsやSlackのリクエストのためのレイヤーだ。あなたの課題が質問への回答ではなく資産インベントリなのであれば、AIレイヤーは必要なものではない。