RedmineUPの新しいプラグイン AI Agent の開発は本格的に進んでいます。毎週新しいMCPツールを追加しており、リリースはもう目前です。その間、私たち自身のサポートチームがすでにこのプラグインを使っており、その成果に私たちも驚いています。 .
このプラグインにはMCPサーバーが組み込まれているため、AIアシスタントがRedmineのデータを直接扱えます。チケットを読み、注記を追加し、レポートを作成できます。本記事では、AIエージェントがチームに加わるとヘルプデスクで何が変わるのかを、一歩ずつご紹介します。
チームがRedmineでサポートを運用しているなら、AIにとって最も価値のある素材をすでにお持ちです。長年にわたって解決してきたチケット、Wikiページ、ナレッジベース記事、顧客プロフィールです。現状、その知識の大半はただ保存されているだけです。AIエージェントを使えば、チームも顧客も、その知識を実際に活用できるようになります。
RedmineUPのサポートチームは、AI Agentを実際のチケット対応に初めて導入したチームであり、そこで目にした成果こそがこの記事を書いた理由です。以下では、AI Agentがヘルプデスクにもたらす変化と、それを導入する順序を説明します。
ここが、私たちのアプローチが他のAIソリューションと異なる点です。RedmineUPのプラグインはすべて互いに連携しています。Helpdesk などは、同じチケット、連絡先、プロジェクトを扱います。そのため、小さくても便利なMCPツールのアイデアが毎週寄せられ、私たちはそれをひとつずつAI Agentに追加しています。プラグイン同士の連携を基盤とするこれらのツールこそが、他のAIソリューションに対するAI Agentの最大の強みになります。
- そもそもなぜヘルプデスクを変革するのか
- ステップ1:RedmineのWikiでナレッジベースを構築する
- ステップ2:トリアージと返信の下書き
- ステップ3:サポートチームが依頼できるレポート
- ステップ4:自ら動く一次対応エージェント
- ステップ5:ビジネスの他のシステムとつなぐ
そもそもなぜヘルプデスクを変革するのか
AIはすでにカスタマーサポートで成果を上げています。Boston Consulting Groupは2025年12月のレポート Agentic AI Is the New Frontier in Customer Service Transformation の中で、あるグローバルなテクノロジー企業がサービスリクエストの解決時間を50%短縮したと報告しています。1件あたりの対応時間が減ればサポートコストが下がり、同じチームでより多くの顧客に対応できます。

ただし注意点があります。生成AIから測定可能なビジネス価値を引き出せている企業は、現時点でわずか28%にすぎません。成功している企業は、チャットボットをオンにするだけでなくワークフローそのものを再設計しています。そこで本記事では、ヘルプデスクを段階的に変革していきます。効果は初日から追跡できる数値に表れます。初回応答時間、解決時間、人手を介さずに解決したチケットの割合、そしてエンジニア1人あたりの負荷です。
5月には、Redmine 7.0がトラッカーをAI対応にする と書きました。Redmine 7.0は2026年6月30日にネイティブWebhookを備えてリリースされ(Redmine 7の新機能 で紹介しています)、Helpdeskプラグイン はREST APIを通じてチケットと顧客情報を提供しています。必要な構成要素はすでに揃っています。
本記事では、Redmineヘルプデスクの変革が実際にどのようなものかを段階的にご紹介します。履歴から答えを見つけるアシスタントから、定型的なチケットを自力でクローズするエージェントまで。各ステップはそれ単体で効果があり、次のステップへ進むかどうかは期待ではなく数値で判断します。
ステップ1:RedmineのWikiでナレッジベースを構築する

最初のステップは、自社の履歴をもとに質問に答え、それぞれの回答の出典を示すアシスタントです。まだ何も自動化せず、顧客にも何も送信しません。
アシスタントの質は、見つけられる情報の質で決まります。まずはコンテンツから始めましょう。ハウツー記事や既知の解決策はプロジェクトのWikiにまとめ、チケットをクローズする前に解決方法をチケットに記録してください。
この手法はRAG(検索拡張生成)と呼ばれます。モデルが文章を書く前に、システムがRedmine内の関連ページやチケットを検索し、モデルに渡します。モデルは見つかった情報に基づいて回答し、そのリンクを示します。たとえば「チケット #4521 とWikiページ『SSOの設定』を参照」のように示されるので、担当者が出典を確認できます。
RedmineUP AI Agentプラグインでの仕組み
- 検索。 エージェントはWikiページとチケットに対してRedmine標準の検索を使います。別途インデックスを構築したり同期したりする必要はありません。1分前に保存したページもすでに検索対象です。
- 権限。 すべての検索は質問したユーザーとして実行されます。エージェントが見つけるのは、そのユーザーがRedmineで閲覧できるプロジェクト、チケット、Wikiページだけです。そのため、ある顧客の非公開チケットが別の顧客への回答に紛れ込むことはありません。
- 読み込み。 エージェントは見つかったページやチケットを開き、検索結果の抜粋だけでなく本文まで読みます。
- 下書き。 モデルが出典へのリンク付きで下書きを作成します。下書きはレビューのために注記欄または説明欄に挿入され、自動的に保存されることはありません。
このプラグインにはMCPサーバーも含まれています。Claude、ChatGPT、その他のMCPクライアントを接続すれば、Redmineについて自然な言葉で質問できます。各クライアントはOAuthでサインインし、管理者が許可したスコープのみを取得します。

キーワード検索では足りないとき
Redmineの検索は単語の一致で動きます。顧客とエンジニアが同じ言葉で問題を説明している限りは、これで十分機能します。しかし大規模なアーカイブの場合や、顧客が「ログインできない」と書いているのに解決策が「SSO証明書の期限切れ」として登録されている場合には、次の段階としてセマンティック検索が必要になります。
- Wikiページと解決済みチケットを短い断片に分割し、それぞれをベクトル(埋め込み)に変換します。
- ベクトルをベクトルデータベースに保存します。RedmineがPostgreSQLで動いていれば、pgvector拡張を使って既存データと同じ場所に保存できます。
- Redmine 7のWebhookを使い、チケットのクローズやWikiページの変更時にインデックスを更新します。
注意:独自のインデックスを持つ場合、権限管理はご自身の責任になります。各断片のプロジェクトと公開範囲を保存し、モデルに渡す前に、質問したユーザーの権限で検索結果をフィルタリングしてください。
セマンティック検索はプラグインの設定項目ではなく、個別の開発プロジェクトです。標準の検索では答えられない質問が見えてきた段階で構築する価値があります。
チームでの活用例
- 返信の下書き。 エンジニアがチケットを開き、注記エディタのAgentボタンをクリックして要点をいくつか入力します。エージェントはチケットを読み、Wikiや類似チケットを検索して、リンク付きの下書きを返します。
- スマート検索。 MCPクライアントを通じて、自然な言葉で質問できます。「昨年、ACMEのインポートの問題はどうやって解決した?」
- オンボーディング。 新しいメンバーが業務プロセスについて質問し、社内Wikiから回答を得られます。
- セルフサービスポータル。 個別の連携を構築すれば、顧客がポータル上で質問し、チケットが作成される前に回答を得られます。
測定すべきこと:エンジニアが提案された回答をどのくらいの頻度で使っているか、そしてリンクされた出典が実際にどのくらい関連していたか。これがステップ4に必要なデータです。
ステップ2:トリアージと返信の下書き


ステップ2では、エージェントが新しいチケットすべてに取り組み始めます。チケットを分類し、振り分け、返信の下書きを用意しますが、返信を送信するのは引き続き人間です。
Helpdeskプラグインでは、すべてのチケットが通常のRedmineチケットです。メールがチケットになった瞬間にチケットのWebhookが発火し、エージェントサービス(REST APIまたはAI AgentプラグインのMCPサーバーを通じてRedmineに接続されたスクリプトやワークフロー)が動き出します。
- チケットと顧客を読み込みます。
GET /helpdesk_tickets/は、連絡先とメールのやり取りを含むチケットを返します(ドキュメント)。.json?include=journal_messages - カテゴリ、優先度、製品、担当者を、Redmineに実在する値の中からのみ選びます。あわせて言語と顧客の感情も判定します。
- ステップ1の検索を使って類似の解決済みチケットを探し、返信の下書きを作成します。
- 通常のチケットREST APIへの1回の呼び出しで、フィールドを保存し、下書きをプライベート注記として追加します。
PUT /issues/4812.json
{
"issue": {
"category_id": 7,
"priority_id": 4,
"assigned_to_id": 23,
"notes": "AI triage: billing, EN, customer frustrated (3rd ticket this month). Similar: #3310.\n\nDraft reply:\nHi Anna, thanks for the details. The duplicate charge on invoice #1045 ...",
"private_notes": true
}
}
注意:サポートチームは複数の顧客セグメントを担当していることがあります。セグメントごとに、支払い、トラブルシューティング、機能要望、サービス停止など、独自の問い合わせが発生します。エージェントサービスはこれらの問い合わせをトリアージして優先順位を付け、SLAの対象となるチケット(サービス停止など)についてはSlackやTelegramで追加の通知を送ることもできます。その結果、時間とともに回答の精度がますます高まっていきます。
エンジニアはすでに分類済みのチケットを開き、下書きを編集して、いつもどおり 注記を送信 にチェックを入れて送信します。このチェックがない注記は チーム内でのみ表示 されるため、顧客がレビュー前の下書きを目にすることはありません。サポートキューをすでにボードで管理している場合は、分類されたチケットが アジャイルヘルプデスク の適切な列に自動的に配置されます。
安全に運用するためのルール
- 選択肢を限定する。 カテゴリ、優先度、担当者の正確なIDをモデルに渡し、それ以外の回答はすべて却下します。
- まだ自動送信はしない。 このステップでは、エージェントサービスは通常のチケットAPIを通じてプライベート注記を書き込むだけです。Helpdeskの返信エンドポイントは一切呼び出さないため、メールが送信されることはありません。
- ループを防ぐ。 エージェント自身の更新によっても別のWebhookが発火します。チケット作成イベントのみを購読するか、ボットユーザーによるイベントをスキップしてください。
注意:ステップ4へのゲート。このモードで2〜4週間運用し、すべての下書きを記録してください。カテゴリごとに、エンジニアが下書きを修正なし、または軽微な修正のみで送信した割合を記録します。この数値が、どこまで自動化しても安全かを決めます。
ステップ3:サポートチームが依頼できるレポート
ステップ3では、エージェントがサポートを統括する人たちのために働きます。ヘルプデスクの履歴をマネージャー向けの答えに変え、引き続き顧客には何も送信しません。そのため、自動化の前の安全なステップです。
標準のレポートが答えられるのは、誰かが事前に想定した質問だけです。AI AgentプラグインのMCPサーバーを通じてRedmineに接続したAIアシスタントがあれば、サポートリーダーは必要なレポートを自然な言葉で説明するだけで、アシスタントがHelpdeskのデータからクエリ、数値、グラフまで作成します。
例:「RedmineSaaSプロジェクトの初回応答時間と解決時間を表示して。中央値とP90、4時間以内に回答したチケットの割合、1回の返信で解決した件数、そして初回応答時間が年ごとにどう変化したか。」


結果は一度きりの回答ではなく、実際に使えるレポートです。
- サポートにとって重要な 主要指標:初回応答の中央値とP90、4時間以内の回答率、解決時間の中央値、1回の対応での解決率。
- 平均値だけでなく 分布 も。48時間以上待たされたチケットや、何週間も未解決のままのチケットといったロングテールが見えます。
- 時系列の推移。新しいプロセスやAIエージェントが本当に数値を動かしたかを確認できます。
- プロジェクト、期間、集計間隔による フィルター。チームが条件を変えて再実行できます。
さらにエージェントは、見えたことを説明します。どの顧客やカテゴリが遅いロングテールの原因になっているか、どこで初回応答時間が急増しているか、どの繰り返し寄せられる質問がナレッジベース記事にする価値があるか。こうしてレポートが翌週のToDoリストになります。
注意:AIが作成するレポートも、他のすべての機能と同じRedmineの権限に従います。マネージャーに表示されるのは、Redmineでアクセス権のあるプロジェクトだけです。
ステップ4:自ら動く一次対応エージェント
ステップ4では、エージェントが受信したチケットの一部を自力で解決します。ただし対象は、ステップ2で正確さが証明されたカテゴリに限ります。
注意:ステップ4はまだ設計段階です。何を、いつ構築するかは、ステップ1〜3のテスト結果によって決まります。
エージェントの役割
- Helpdeskプラグインが集約するチャネル、つまりメールと Helpdeskウィジェット からの問い合わせを読み取ります。Telegramなどのメッセンジャーは、Helpdesk APIでチケットを作成する個別の連携を構築すれば追加できます。
- ステップ1の検索を使ってナレッジベースから典型的な質問に回答し、Helpdesk API(
POST /helpdesk/email_note.json、ドキュメント。 - APIを通じて簡単な操作を実行します。注文やライセンスの状況確認、ダウンロードリンクの送付、試用期間の延長などです。
- 確信が持てない場合や問い合わせが通常と異なる場合は、短い要約を添えて人間に引き継ぎます。例:「お客様はすでにAとBを試しています。考えられる原因はCです。」
3段階で展開する
- 下書きのみ。 これがステップ2です。カテゴリごとの正確性の統計をここで蓄積します。
- 正確性が証明された限定カテゴリでの自動返信。 パスワードのリセット、「請求書はどこ?」、「インストール方法は?」など。
- カテゴリごとに拡大する。 毎回、数値に基づいて判断します。
次の場合は必ず人間に引き継ぐ
- エージェントの確信度が低い、または質問が既知のどのカテゴリにも当てはまらない場合
- 顧客が不満を抱いている、または返金、法的問題、セキュリティインシデントについて書いている場合
- 顧客がVIPに指定されている、またはプレミアムSLAを契約している場合
- 顧客が「回答が役に立たなかった」と返信した場合。このときチケットは、全履歴とともに人間に引き継がれます。
定型的な質問には昼夜を問わず数分で回答が届き、エンジニアは本当に人の手が必要な問題により多くの時間を使えるようになります。
ステップ5:ビジネスの他のシステムとつなぐ
ステップ5では、エージェントはチケットだけでなく顧客の全体像を把握します。契約、請求書、SLA、監視アラート、Redmineの周辺システムに残る過去のやり取りまで含めてです。
顧客ストーリー
CRM とHelpdeskのプラグインがあれば、1回の呼び出しで全体像の大部分を取得できます:GET /contacts/(ドキュメント。
実際の例をご紹介します。MCPサーバーを通じてRedmineに接続したAIアシスタントが、顧客とのやり取りを読み、連絡先カードに業種、国、社内での役職などのタグを追加します。これらの項目を手作業で入力する人はいません。アシスタントは、接続したユーザーの権限の範囲内で、CRMプラグインの連絡先ツールを使ってタグを保存します。そのため、すぐにタグで連絡先を絞り込み、セグメントを作成できます。
現在、アクセス権を分離する仕組みに取り組んでいます。エージェントが各ユーザーに、そのユーザーがRedmineで閲覧を許可されている顧客データだけを表示できるようにするためです。これが完成すれば、次のことが可能になります。
- 顧客の簡潔な概要を数秒で取得する
- 顧客のLTVを確認する
- 顧客を自動的にセグメント化する
- 顧客ストーリーを導入事例に仕上げる
スコアとLTVは、チケットの傾向、未解決の緊急チケット、ステップ2で記録した顧客の感情、商談のステージ、支払期限を過ぎた請求書といった明確なルールに基づいてコードで計算してください。そのうえで、モデルにわかりやすい言葉で説明させます。数値は再現可能なまま保たれ、説明は担当者が次に何をすべきかを示します。DataCycleがCRMとAgileを組み合わせた事例 では、顧客を一元的に把握する方法をご覧いただけます。
始めるために必要なもの
AI Agentプラグインには、Redmine 6.1以上とRuby 3.2以降が必要です。お使いのRedmineがそれより古い場合は、アップデートの良い機会です。サポート対象の最新バージョンのトラッカーと、上記のステップの前提となるRedmine 7のWebhookが手に入ります。
アップグレードで問題が発生した場合は、メッセージをお送りください。専門チームがお客様のRedmine環境を確認し、ヘルプデスクのAI変革に最適な進め方をご提案します。
パイロットグループに参加する
近いうちに、Helpdeskを積極的に活用し、同じ方法でサポート指標を改善したいお客様のグループを立ち上げます。目指すのは、初回応答の高速化、解決時間の短縮、そしてエンジニアが対応する定型チケットの削減です。貴社のチームに当てはまるようでしたら、ご連絡ください。参加方法をご案内します。