著者 Matt Connor
セルフホスト型ヘルプデスクの選び方
FreeScout、osTicket、Zammad、GLPI、iTopを比較し、メールのチケット化、エージェント数、SLA、資産管理の要件から最適な製品を絞り込めます。
セルフホスト型ヘルプデスクを選ぶための4つの質問
セルフホスト型ヘルプデスクは、インストールは簡単でも、選定は難しい製品です。この分野では要件が特に細かく分かれるためです。次の4つの回答だけで、約20個のプロジェクトを1つか2つまで絞り込めます。各製品の機能ページを見る前に決めてください。
- メールをチケットに変換する必要がありますか。それとも、利用者は Web フォームとログインを使いますか。
- 顧客向けのサポートですか。それとも、チケットからノート PC やサーバーを特定する社内 IT サービスデスクですか。
- ログインするエージェントは最大で何人ですか。2人で使う製品と20人で使う製品は異なります。
- 誰かがサービスレベル合意（SLA）の時間管理、資産台帳、公開ナレッジベース、承認手順を必要としますか。
以下のセクションでは、この順番で説明します。製品一覧は最後に示します。ここで行う選定では、製品そのものが最も重要な判断ではないためです。
メールをチケット化する必要がありますか？
答えが「はい」なら、導入するシステムではメール連携が中心になります。この連携には、異なる原因で障害が発生する2つの側面があります。
受信: チケットを実際に作成する仕組み
この投稿で扱うほぼすべての選択肢は、すでに所有しているメールボックスから、IMAP (internet message access protocol) または POP3 (post office protocol) でメールを読み取ります。ヘルプデスクは通常のメールクライアントと同じようにログインし、一定間隔でポーリングします。メールをヘルプデスクへプッシュする仕組みはないため、タイマーが停止するとチケットの作成も止まります。その場合、顧客にはエラーがまったく表示されません。例外は Request Tracker です。公式のインストールガイドでは、自分のメールサーバーにエイリアスを設定し、各メッセージを rt-mailgate へパイプする方法だけが説明されています。そのため、プロバイダーのメールボックスを読み取るには、前段で fetchmail などのフェッチャーを実行する必要があります。このフェッチャーが監視対象のタイマーになります。
osTicket では、この仕組みを確認しやすくなっています。管理画面でメールアカウントごとのフェッチ間隔を設定できますが、フェッチを有効にするだけでは不十分です。ポーラーは api/cron.php にあり、公式の設定方法では、これを実行する crontab エントリを追加します。通常は5分ごとに実行します。組み込みの代替機能である auto-cron は、ログイン中のエージェントが Web インターフェースを使用している間だけ実行されます。そのため、利用者の少ない週末には、誰かがログインするまでメールが取得されません。
GLPI では、同じ処理を2つに分けています。receiver は GLPI でのメールコレクターの呼び方で、メールボックスの認証情報を保持します。mailgate automatic action が、収集を実行する間隔を決定します。チケットが表示されなくなった場合は、メールボックスを調べる前に、この automatic action を確認してください。Zammad はチャンネル設定から IMAP または POP3 経由でメールを取得します。セルフホスト環境では、fetchmail からメールを渡すこともできます。この場合、各メッセージは Zammad 独自のメールドライバーへパイプされます。Sendmail オプションは送信メール専用です。そのため、受信用のメールサーバーパイプは公式には説明されていません。
次の落とし穴はスレッド処理です。顧客の返信は、新しいチケットではなく既存のチケットに紐付ける必要があります。メールスレッドは Message-ID、In-Reply-To、References ヘッダーを基に処理されます。ヘルプデスクはフォールバックとして件名にチケット参照番号を追加します。そのため、サポートメールの件名には [#123456] のような文字列が含まれます。見た目を整えるために送信テンプレートからこのトークンを削除すると、すべての返信が新しいチケットとして作成されます。
最後は自動返信です。ヘルプデスクは新しいメッセージごとに受領確認を送信します。返信先が自動返信を行うアドレス自身の場合、どちらかを停止するまで自動返信が繰り返される可能性があります。RFC 3834 では、Auto-Submitted: auto-replied ヘッダーを定義しています。自動応答システムはこのヘッダーによって相互に認識し、応答を停止できます。適切に実装されたシステムでは、このヘッダーが設定されます。メール転送先がメーリングリストになるエイリアスをヘルプデスクに指定する前に、実際のメールボックスでテストしてください。
送信: 返信が届くかどうかを決める側面
受信の問題は、チケットが表示されないため把握しやすいものです。送信の問題は見えにくくなります。返信は送信され、エージェントはチケットを終了しますが、顧客には届きません。チケットシステムは自分のドメイン名でメールを送信するため、そのドメインで送信元を承認する必要があります。
ドメインには、メールを送信するすべての仕組みを列挙した SPF (sender policy framework) レコードが必要です。また、DKIM (domainkeys identified mail) 署名と、両方との整合性を持つポリシーを設定した DMARC (domain-based message authentication, reporting and conformance) レコードも必要です。導入前に、現在公開されているレコードを確認してください。
dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT selector1._domainkey.example.com最初のコマンドは、v=spf1 で始まる行を出力するはずです。2番目のコマンドは、v=DMARC1 で始まる行を出力するはずです。3番目のコマンドは、署名システムが使用する selector 名だけを対象にします。そのため、結果が空の場合は、通常、DKIM が存在しないのではなく、誤った selector を検索しています。
VPS から直接送信すると、ここで問題が発生します。新しい IP アドレスには送信実績がなく、多くのホストでは、依頼して開放してもらうまで送信ポート 25 が閉じられています。代わりにメールプロバイダー経由でリレーしてください。これは、そのサーバー上の他のサービスにも当てはまる判断です。セルフホストアプリから迷惑メール扱いされずにメールを送信する方法で、すべてのサービスに共通する設定をまとめて説明しています。メールボックスも自分で管理したい場合は、VPS 上の Mailcow メールサーバーを使えば、ヘルプデスクがポーリングする受信トレイを用意できます。ただし、ヘルプデスク自体よりも大規模なプロジェクトになります。
顧客サポートか、社内 IT サービスデスクか
この 2 つは、似たインターフェースを持つ別のデータモデルです。この違いによって、候補製品が決まります。
顧客サポートでは、依頼者はメールアドレスです。身元情報は限定的で、問い合わせ量には波があります。成功とは、運用しているシステムにログインすることのない相手に返信が届くことです。Web フォーム、定型返信、部門別キューが重要になります。資産管理は重要ではありません。
社内サービスデスクでは、依頼者は従業員です。通常は LDAP（lightweight directory access protocol）経由でディレクトリから取得します。チケットは、ノート PC、ライセンス、仮想マシンなどの対象に関連付けられます。対象は CMDB（configuration management database）またはインベントリで管理されます。この種のツールの価値の半分は、どのチケットがどのマシンに関係したかを把握できることにあります。
GLPI と iTop は、後者のモデル向けに構築されています。FreeScout と osTicket は、前者のモデル向けです。Zammad は顧客サポートに適しており、資産レコードなしで社内サービスデスクとしても運用できます。この境界を後から越えることが、この分野で高くつく失敗です。移行が必要なのはデータモデルであり、テーマではないためです。
何人のエージェントがログインする予定ですか？
この投稿で紹介する製品には、エージェント数に応じた料金はありません。そのため、人数によって料金は変わりません。ただし、最初のチケットを受け付ける前に構築すべき運用構成の規模は変わります。
エージェントが2人の場合、構成は解決策ではなく問題になります。1つのメールボックスを共有して確認できること、誰がどの案件を担当しているかを示せること、検索可能な履歴があることが必要です。FreeScout はこの用途に適しています。顧客がサイトのフォームから問い合わせを送信する場合は、osTicket が適しています。
エージェントが10人または20人になると、キューまたは部門、割り当てルール、権限レベル、作業の滞留箇所を示すレポートが必要です。osTicket、Zammad、GLPI には、これらの機能がすべて用意されています。設定には1日かかります。設定を省くと、すべての問い合わせが1つのキューに入り、誰も担当しないという、よくある問題が発生します。
SLA、資産管理、ナレッジベース、承認のどれが必要ですか？
これらは 1 つずつ確認してください。要件を絞り込めるためです。
SLA の時計は、目標に対する応答時間と解決時間を測定します。そのため、営業時間、優先度の体系、エスカレーション経路が必要です。osTicket には SLA プランが含まれています。Zammad には SLA が含まれています。GLPI と iTop は、どちらもサービスレベル管理をモデルの中核機能として扱います。
資産管理が必要なら、GLPI または iTop が候補です。GLPI には、サービスデスクと併用できる独自のマシンインベントリが含まれています。iTop は、チケット管理を上位に構築した CMDB です。そのため、サービスとハードウェアの関係を管理することが目的なら、iTop が適しています。Znuny と OTOBO では、ITSM パッケージによって CMDB 機能を追加できます。
ナレッジベースは一般的ですが、すべての製品にあるわけではありません。Zammad にはナレッジベースが含まれていますが、管理者が有効にするまで無効になっています。osTicket には FAQ があります。GLPI にはサービスデスクと連携するナレッジベースがあります。FreeScout のナレッジベースは有料モジュールとして提供されています。
承認手順と変更管理に対応する製品は、iTop と OTRS の派生製品に限られます。誰かが承認するまで作業を開始できない場合は、まずこれらを確認してください。その分、運用の負荷が増える点も受け入れる必要があります。
ライブチャットはチケットとは別の業務です
Web サイト上のライブチャットを備えた共有受信トレイが必要なら、チケットシステムの比較を読むのはやめて、Chatwoot をサポートデスクとして運用するに進んでください。
違いは状態機械にあります。Chatwoot の会話は、担当者を紐付けたメッセージのストリームです。複数のチャネルで迅速に回答する用途に適しています。チケットは、ステータス、担当者、キュー、期限、レポート可能な履歴を持つ記録です。会話が終わった後も続く業務に適しています。4 日間にわたるハードウェア交換の追跡はチケット業務です。「注文はどこですか」という問い合わせに 90 秒で回答するのはチャット業務です。
両方を必要とするチームも少なくありません。両方を運用すると、受信トレイと通知のセットが 2 つ必要になります。そのため、受信量の大部分に合う方を選び、もう一方のチャネルからはメールで取り込んでください。
時間をかけて検討する価値のある選択肢
FreeScout: ヘルプデスクのように使える共有受信トレイ
AGPL-3.0 でライセンスされ、Laravel フレームワーク上の PHP で書かれており、継続的にリリースされています。バージョン 1.8.247 は 2026 年 10 月 10 日にリリースされました。ドキュメントには、CPU と RAM の最低要件はなく、共有ホスティングでも動作すると記載されています。コア機能は無料で、エージェント数とチケット数に制限はありません。ナレッジベース、ワークフロー、ライブチャット、タグなどの追加機能は、単一インスタンス向けの買い切り型ライセンスで提供される有料モジュールです。メールが主な窓口で、チームが小規模なら選択肢になります。
osTicket: 典型的なフォームとキューによるチケットシステム
GPL-2.0、PHP 8.2 から 8.4、MySQL に対応しています。バージョン 1.18.4 は 2026 年 6 月に公開されており、ゆっくりと安定したペースで保守されています。部門、ヘルプトピック、カスタムフォーム、定型返信、SLA プランを利用できます。インターフェースには古さが残っています。顧客がフォームからチケットを登録し、従来型のキューが必要で、サーバーを安価に用意したい場合に適しています。
Zammad: RAM を用意できるなら、フル機能のデスク
AGPL-3.0、Ruby on Rails で、7.2 系列が 2026 年 9 月 23 日から現行です。セルフホスト版は無料で運用できます。Zammad の料金ページにあるサブスクリプションはサポート契約であり、2026 年 10 月時点では Business ティアが年間 2,999 ユーロからです。Zammad 自身のハードウェア要件ページでは、2 CPU コアと 6 GB の RAM を求めています。Elasticsearch を同じサーバーで実行する場合は、さらに 4 GB が必要です。Elasticsearch は必須ではありませんが、数年分の古いチケットを横断検索する処理を高速化する機能でもあります。実際の処理量が多く、複数のチャネルがあり、それを処理できるサーバーを用意できる場合に Zammad を選びます。
GLPI: 資産管理を統合した IT サービスデスク
GPL-3.0 です。リリース 12.0.0 は 2026 年 10 月 7 日にリリースされ、PHP 8.3 以降が必要です。11.0 系列も引き続きパッチが提供されており、11.0.11 は 2026 年 10 月 1 日にリリースされました。PHP 8.2 以降、MySQL 8.0 または MariaDB 10.6 以降で動作します。受信処理と mailgate 自動アクションを使うと、メールをチケットに変換できます。ルーティングルールでメッセージを異なるエンティティへ振り分けることもできます。これは、1 つのインストールで別々のサイトや顧客組織をモデル化する仕組みです。キューと同じ程度に資産一覧が重要な社内 IT 用途に適しています。
iTop: チケット管理を上に載せた CMDB
AGPL-3.0 で、現在のバージョンは 2026 年 9 月 15 日の 3.3.0 です。公式のサイジング指針では、月間 200 チケット未満、コンソールユーザー 20 人未満の場合、RAM は 4 GB から始まります。月間 5,000 チケットまでなら 8 GB が必要です。サービス、契約、影響範囲をモデル化し、チケットが全体の中で最小の要素になる場合に選択します。
Znuny と OTOBO: 現在も保守されている OTRS 系列
どちらも、2020 年 12 月末にサポート終了となった OTRS Community Edition を起源としています。Znuny（GPL-3.0）は 6.0.30 のコードベースを引き継ぎ、7.3 系列になっています。OTOBO（GPL-3.0）は 2019 年にフォークし、11.0 系列になっています。どちらも Perl で、ITIL の実践に基づいて設計されています。また、どちらも重量級です。OTOBO のドキュメントでは、本番マシンに 8 GB の RAM と 40 GB のストレージを求めており、16 GB を推奨しています。プロセス自動化と、サービス組織向けに設計されたチケットモデルが必要で、チーム内に Perl を扱える人がいる場合に選択します。
追加で知っておきたい 2 つ
Request Tracker（GPL-2.0、Perl）は 2026 年 5 月に 6.0.3 をリリースしました。メールが追加機能ではなく標準のインターフェースであるため、メール中心のキューに現在も適しています。Frappe Helpdesk（AGPL-3.0）は 2026 年 10 月に 1.30.2 をリリースしました。この中では最も現代的なインターフェースを備え、SLA とナレッジベースにも対応しています。ただし、Frappe スタック全体を導入する必要があり、データベースとともに Redis とバックグラウンドワーカーも実行することになります。
小規模 VPS にそれぞれが求めるもの
公開されている最小要件は、正直な出発点です。ここに示すのは各プロジェクト自身が提示している数値であり、私が測定したものではありません。
このグラフのデータ
[
{
"tool": "OTOBO 11",
"min_ram_gb": 8,
"notes": "production minimum, 16 GB recommended, 4 GB for a test box"
},
{
"tool": "Zammad 7",
"min_ram_gb": 6,
"notes": "add 4 GB more to run Elasticsearch on the same server"
},
{
"tool": "iTop 3.3",
"min_ram_gb": 4,
"notes": "under 200 tickets a month, fewer than 20 console users"
}
]これらの 3 個の数値は、目標ではなく下限として扱ってください。どの数値も、問い合わせ件数が少ないことを前提としているためです。RAM だけで判断することもできません。ここで挙げる選択肢はすべてデータベースを必要とし、データベースにも専用のメモリ容量が必要です。そのため、Zammad を実行する 4 GB のサーバーは、実際には Zammad、PostgreSQL、さらに追加したソフトウェアを実行する 4 GB のサーバーです。
FreeScout と osTicket は、RAM の最小要件を公開していません。これはマーケティング上の理由ではありません。どちらも MySQL と通信する通常の PHP アプリケーションであり、必要な下限はヘルプデスクではなく PHP とデータベースによって決まります。その下限は、上記の数値を大きく下回ります。代わりにディスク容量を確認してください。顧客がスクリーンショットを送るため、添付ファイルは想定以上の速さで増加します。
プロジェクトが現在も保守されているかを確認する方法
機能一覧を見る前に、これを確認してください。顧客データを扱うヘルプデスクが放置されている場合、設定では解決できません。
- マーケティングページではなく、リポジトリでライセンスを確認します。UVdesk の community package は OSL-3.0 の下で提供されています。このライセンスを確認したことがないチームは少なくありません。最後のリリースは 2025年9月の v1.1.8 です。
- 最新の commit ではなく、最新のリリースの日付を確認します。commit は README の誤字修正にすぎない場合があります。
- リポジトリがアーカイブされていないか確認します、多くの一覧で見かけるオープンソースのヘルプデスク Peppermint は、所有者によって 2026年7月17日にアーカイブされました。最後のリリースは 2024年11月の 0.5.5 です。アーカイブされたリポジトリは読み取り専用のため、セキュリティ修正は提供されません。
- プロジェクトがすでに終了したプロジェクトから fork されたものなら、その fork が現在も保守されているか確認します。Znuny と OTOBO はどちらも保守されており、2026年までリリースがあります。
このシステムをセルフホストすべきでない場合
チームの規模を正直に見積もってください。1 日に数件のメッセージへ 2 人で対応するだけなら、チケットシステムは必要ありません。共有メールボックス、ラベル、担当範囲についての合意があれば十分です。ヘルプデスクを導入すると、バックアップ対象のデータベース、気付かないうちに停止するメール連携、継続的にパッチを適用するアプリケーションが増えます。しかし、チケットへの回答を自動で行ってくれるわけではありません。
セルフホストするのは、明確な理由がある場合にしてください。たとえば、管理下のインフラストラクチャに保持しなければならないデータがある場合や、エージェント単位の料金がツール予算の最大項目になった場合です。他社が提供していないカスタマイズも理由になります。これらは妥当な理由であり、上記のツールは実際に優れています。
小規模な環境では、コストだけを理由にセルフホストしないでください。チケットシステムには、顧客名、住所、注文の詳細、苦情の履歴が保存されます。そのため、パッチ適用は必須です。また、バックアップは少なくとも 1 回復元して、初めて有効性を確認できます。支払いを負担に感じているホステッドプランには、メールの到達性、アップグレード、他社のオンコール体制が含まれています。エージェントが 2 人なら、通常はこちらのほうが適切な選択です。キューが増えた時点で、判断を改めることも容易です。
導入前に引き受ける作業
インストール前にバックアップを計画します。データベースと添付ファイルのディレクトリが必要です。バックアップが機能することを確認するため、予備のサーバーで両方を1回復元します。
Compose で運用すると、アップグレードはバージョンの更新と再起動だけで済みます。Compose が初めての場合は、VPS 向け Docker Compose の基本でファイル構成と名前を付けるボリュームを確認してください。データベースはコンテナ内ではなく、名前付きボリュームに保存します。そうしないと、アップグレード時にチケットも失われます。
メール取得処理を監視してください。ここがひそかに失敗しやすい部分です。チケットが届かなければアラートも発生しません。最初の兆候は、返信がない理由を尋ねる顧客からの苦情になることがあります。毎週、サポートアドレス宛てにメッセージを送り、取り込まれたことを確認します。さらに、メール取得ジョブが停止したときに、自分の携帯電話へのプッシュ通知を送るよう設定すると、誰も開かないダッシュボードより確実です。
最後に、チケットの内容を確認します。異なる人から同じ質問が多数寄せられる場合は、自分でホストするフォーラムで公開回答すると、1回の回答で済みます。支払いと日付に関する問い合わせが大半なら、サポートデスクよりも記録を整備したほうが多くの問題を解決できる場合があります。その場合は、セルフホスト型の請求ツールのほうが適しています。
FAQ
2 GB の VPS でセルフホスト型のヘルプデスクを運用できますか？
PHP アプリケーションを選べば可能です。FreeScout のドキュメントには CPU と RAM の最低要件はないと記載されており、osTicket も最低要件を公開していません。そのため、必要な容量は利用する環境で PHP と MySQL が必要とする量が下限になります。一方、Zammad と OTOBO は要件が異なります。各プロジェクトのドキュメントでは、Elasticsearch を追加する前の時点で、それぞれ 6 GB と 8 GB の RAM を求めています。この 2 つには専用サーバーを割り当ててください。
メールをチケットに変換するために、自分のメールサーバーが必要ですか？
いいえ。ここで紹介するほとんどの選択肢は、すでに利用しているメールボックスへ IMAP または POP3 でログインし、SMTP で返信を送信します。Request Tracker はメールをパイプ経由で受け取る方式を想定しているため、メールボックスとの間に fetchmail などの取得ツールが必要です。現在のプロバイダーにあるメールボックスで十分です。ただし、送信アドレスの認証は必要です。メールを中継するサーバーを対象に含めた SPF レコード、DKIM 署名、そして両方と整合する DMARC レコードを設定してください。これらがないと返信が迷惑メールとして処理され、利用者側では返信済みに見えても、チケットは正しく処理されません。
Chatwoot とチケットシステムのどちらを使うべきですか？
作業の中心が会話であれば Chatwoot を使います。対象は、Web サイトのライブチャット、ソーシャルチャネル、数分以内に返信する共有受信トレイです。作業にステータス、担当者、期限があり、開始のきっかけとなった会話が終わった後も継続する場合は、チケットシステムを使います。エスカレーション、承認、SLA の時間管理はチケットに適しています。両方に該当する場合は、受信量の大部分に合う方から始め、もう一方のチャネルはメール経由で取り込んでください。
ヘルプデスクプロジェクトが現在も保守されているか確認するにはどうすればよいですか？
リポジトリを開き、最新リリースの日付を確認します。その後、リポジトリがアーカイブされていないことを確認してください。Peppermint は所有者によって July 2026 にアーカイブされ、最終リリースは November 2024 です。アーカイブされたリポジトリは読み取り専用のため、今後セキュリティ修正は提供されません。次に、Web サイトに記載されたライセンスではなく、リポジトリ内のライセンスファイルを確認してください。ここで扱うプロジェクトの中には、UVdesk の OSL-3.0 のように、事前に確認していない可能性がある条件を採用しているものがあります。
小規模チームが標準で選ぶなら、どれがよいですか？
チャネルがメールで、担当者が 5 人未満なら、まず FreeScout を選んでください。軽量で、リリース頻度が高く、小規模チームの既存の業務方法に合うためです。顧客がフォームからチケットを作成し、RAM をあまり使わずに部門と SLA プランを運用したい場合は、osTicket から始めてください。チケットが社内のハードウェアに関するものであれば、GLPI を選ぶと、資産インベントリとキューを 1 か所で管理できます。