LASSIC Media らしくメディア
MantisBTとRedmineの違い｜不具合管理ツールの選び方
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- MantisBTは、PHPで動くGPL第2版のオープンソースの不具合管理システムです。
- 標準の7つの状態とメール通知が中心で、Redmineとは用途と状態の流れの決め方が違います。
- 自社で置くなら、状態の移り方・通知の宛先・バックアップを導入の前に決めておきます。
※ 本記事は2026年10月時点の公式情報（省庁・公的機関、および製品やサービスを提供する事業者が公開している資料）に基づきます。
不具合の報告がメールと表計算のファイルに散らばり、どれが直ったのか分からない。担当者が決まったのか、報告した人に確かめているところなのか、誰に聞けばよいか分からない——。不具合を管理している現場では、こうした食い違いが起こりがちです。MantisBT（マンティスビーティー）は、こうした不具合の記録と進み具合をWebの画面で管理する、オープンソースの不具合管理システムです。
不具合ごとに状態を付け、変化を関係者にメールで知らせます。ただし万能ではなく、初期の設定のままでは状態の移り方に決まりが無く、運用に合わせた設計が要ります。本記事では、不具合管理の仕組みづくりを任された情報システムの担当者に向けて、MantisBTの特徴、不具合の状態の流れ、メール通知の仕組み、Redmineとの違い、そして外部に頼むときに確認したい点を整理します。
目次
MantisBTとは
MantisBTは、管理者向けの公式ガイドで「Webベースの不具合管理システム」と説明されているオープンソースのソフトウェアです。2000年11月に公開され、開発言語はPHPです。*2 画面はWebブラウザで開き、報告された不具合を1件ずつ記録して、担当者・状態・やり取りの履歴をまとめて追えるようにします。
- ライセンスはGPL（GNU General Public License）の第2版です。使うことも改変することも自由で、配る場合はGPLの条件に従います*3
- サーバーのOSはWindows・Linux・macOSなど、PHPが動くものを選べます
- データベースはMySQL（MariaDBを含む）かPostgreSQLを使います。Microsoft SQL ServerとOracleへの対応は試験的な扱いです
- 公式サイトは、メール通知・プロジェクトごとの権限管理・項目や状態の流れの変更を主な機能に挙げています*1
ソフトウェアの利用料はかかりませんが、自社のサーバーに置く場合は、サーバーの用意や更新を受け持つ人が要ります。導入の前に、誰が保守を受け持つかを決めておきます。
不具合の状態の流れ
MantisBTでは、1件の不具合が「報告された」から「完了した」まで、決まった状態を順に進みます。標準で用意されている状態は7つで、どれも「未解決」「解決済み」「完了」の3つの段階のどれかに当てはめられます。*2 状態の名前と数は、自社の運用に合わせて変えられます。
| 状態 | 意味 |
|---|---|
| new（新規） | 報告されたばかりの不具合 |
| feedback（情報待ち） | 報告者に追加の情報を求めている。完了後に再び開いたときもこの状態に戻る |
| acknowledged（受付） | 開発側が内容を受け付けたが、まだ再現は試していない |
| confirmed（確認） | 開発側が再現を確かめた |
| assigned（担当決定） | 担当者が決まり、対応している |
| resolved（解決） | 修正済み・重複・対応しないなどの結論が出た |
| closed（完了） | これ以上の対応が要らない。一覧からは通常隠れる |
注意したいのは、初期の設定では状態の流れが決まっていない点です。公式ガイドには、どの状態からどの状態へも、誰でも移せると書かれています。*2 「解決」にできるのは開発の担当者だけ、「完了」にできるのは管理者だけ、といった決まりは、管理者の画面で状態の移り方と必要な権限を設定して初めて効きます。
メール通知の仕組み
MantisBTは、不具合が登録された・担当者が変わった・状態が変わった・コメント（MantisBTでは「ノート」）が付いた、といった出来事ごとにメールを送ります。標準で送られる相手は次のとおりです。*2
- その不具合を報告した人と、担当している人
- その不具合を「モニター」（ウォッチ）している人
- その不具合にノートを書いたことのある人
- プロジェクトのメンバーのうち、指定した権限の範囲に入る人
送る相手は出来事ごとに変えられ、たとえば新しい不具合の通知は管理者だけに送る、といった設定ができます。利用者の側でも、出来事ごとに通知を止めたり、重大度が一定以上のものだけ受け取ったりできます。送信の方法は、サーバーの標準の送信機能のほかSMTP（メールを送る仕組み）を選べ、公式ガイドは、ページを開くたびに送るのではなく定期実行でまとめて送る設定を勧めています。
MantisBTとRedmineの違い
自社のサーバーに置ける課題管理の仕組みとして、MantisBTと並んで名前が挙がるのがRedmineです。どちらもGPL第2版のオープンソースですが、もともとの用途と状態の流れの決め方が違います。次の表は、両者の公式の資料に書かれている事実だけを並べたものです。
| 観点 | MantisBT | Redmine |
|---|---|---|
| 公式の説明 | Webベースの不具合管理システム | 柔軟なプロジェクト管理のWebアプリケーション |
| 開発言語 | PHP | Ruby on Rails |
| データベース | MySQL（MariaDB）・PostgreSQL。SQL ServerとOracleは試験的 | MySQL・PostgreSQL・SQLite・SQL Server |
| 状態の流れの決め方 | 初期は制限なし。管理者が移り方と必要な権限を設定する | 役割（ロール）と課題の種類（トラッカー）の組み合わせごとに移り方を設定する |
| メールからの起票 | 標準では対応していない | 機能の一覧に含まれる |
表は両者の公式の資料によります。*2*4*5*6 不具合の記録と通知を中心に据えるか、ガントチャートやWikiも含めた案件の管理まで1つにまとめるかで、候補は変わります。Redmineでの構築はRedmineで課題管理基盤を外注構築、ほかの選択肢との比べ方はOpenProjectとRedmineの違いで扱っています。
外部に頼むときに確認しておきたい点
MantisBTを自社のサーバーに置くと、ライセンス費用はかからなくても、構築と保守の手間は自社で持つことになります。構築や設定を外部に頼むときは、次の点を見積もりの前に確かめておきます。
- どこまで頼むか：サーバーの用意、インストール、状態と通知の設定、利用者への説明のうち、どれを任せるか
- 状態の流れ：誰がどの状態に移せるかを、社内の役割に合わせて設計してもらえるか
- 通知の宛先：出来事ごとに誰へメールを送るか。送りすぎて読まれなくなる事態をどう防ぐか
- ログインの方法：社員はLDAP（社内の利用者情報をまとめた仕組み）でログインし、取引先は別のパスワードで入る、という混在の形は公式ガイドで未対応とされています*2
- 更新とバックアップ：データベースだけでなく、添付ファイルと設定も含めて保存し、版を上げる前に取るか
特にインストールの直後は、公式の手順で、設置用の管理フォルダを消すよう求められています。インターネットから開けるサーバーにこのフォルダが残ったままにならないよう、引き渡しの前に確かめてもらいます。
まとめ：MantisBTで確かめておきたい3つの点
MantisBTで不具合管理を始めるうえで、確かめておきたい点は3つに整理できます。第一に、標準の7つの状態を使うか自社の言葉に合わせて変えるかを決め、誰がどの状態に移せるかを設定すること。第二に、出来事ごとにメールを送る相手を絞り、通知が読まれる量に収めること。第三に、自社のサーバーに置くなら、データベース・添付ファイル・設定のバックアップと版の更新を誰が受け持つかを導入の前に決めることです。この3点を踏まえておけば、「入れてはみたが、結局だれでも状態を変えられて記録が当てにならない」という事態を避けやすくなります。構築や設定の進め方に迷いがあれば、外部の手を借りるのも一つの選択肢です。
よくある質問
MantisBTの画面やメールは日本語で使えますか
使えます。公式ガイドでは、利用者ごとに使う言語を選べ、その言語が画面とメール通知の両方に使われると説明されています。*2 データはUTF-8で保存されるため、画面の言語と入力する文章の言語が違っていても扱えます。
取引先の担当者にも不具合を報告してもらえますか
報告してもらえます。MantisBTにはプロジェクトごとに権限を分ける仕組みがあり、*1 取引先には特定のプロジェクトだけを見せる、といった分け方ができます。ただし、社員と取引先で別々のログインの方法を混在させる形には対応していないため、アカウントの持ち方を最初に決めておきます。
ほかのシステムから自動で不具合を登録できますか
登録できます。公式ガイドでは、Webの画面のほか、APIを通じたアプリケーションからの自動の登録が挙げられ、夜間のビルドが失敗したときに自動で報告する例が示されています。*2 つなぐ範囲と、自動で登録された不具合を誰が確かめるかを、あわせて決めておきます。
不具合管理の仕組みづくりのご相談
MantisBTなどの不具合管理システムの構築から、状態の流れと通知の設計、更新とバックアップの運用まで、元請（プライムベンダー）としてご提案します。
2006年の創業以来、一次請けのシステムインテグレーターとして、企業のシステム開発と保守・運用を受託してきました。
出典
- *1 参考：MantisBT Team「Mantis Bug Tracker」公式サイト（https://mantisbt.org/）。出典：オープンソースの不具合管理システムという説明、メール通知・プロジェクトごとの権限管理・項目や状態の流れの変更の機能、PHPで動くこと、GPLで公開されていることの記述を参照（2026年10月確認）
- *2 参考：MantisBT「Admin Guide」（管理者向け公式ガイド）（https://mantisbt.org/docs/master/en-US/Admin_Guide/html-desktop/）。出典：1章（概要・公開時期・ライセンス）、2章（動作環境・データベース・バックアップ・インストール後の作業）、4章（不具合の作成方法・標準の状態・状態の移り方）、3章と5章（利用者の設定・メール通知と送信方法）、8章（認証）の記述を参照（2026年10月確認）
- *3 参考：mantisbt/mantisbt（GitHub）doc/LICENSE（https://github.com/mantisbt/mantisbt/blob/master/doc/LICENSE）。出典：GNU General Public License Version 2 の全文を参照（2026年10月確認）
- *4 参考：Redmine 公式サイト「Overview」（https://www.redmine.org/）。出典：自社のサーバーに置けるプロジェクト管理のWebアプリケーションという説明、Ruby on Rails、GPL v2、メールからの課題の作成を含む機能一覧の記述を参照（2026年10月確認）
- *5 参考：Redmine「Installing Redmine」（https://www.redmine.org/projects/redmine/wiki/RedmineInstall）。出典：対応するデータベース（MySQL・PostgreSQL・SQLite・SQL Server）の記述を参照（2026年10月確認）
- *6 参考：Redmine「Issue tracking system」（課題管理の設定）（https://www.redmine.org/projects/redmine/wiki/RedmineIssueTrackingSetup）。出典：役割とトラッカーの組み合わせごとに状態の移り方を設定するワークフローの記述を参照（2026年10月確認）
