Claude Media
ClaudeとRequest Trackerを連携する方法 — TicketSQL検索と返信の設定
ClaudeClaude連携チュートリアル

ClaudeとRequest Trackerを連携する方法 — TicketSQL検索と返信の設定

RT(Request Tracker)のコネクタは自社のRTにREST2 APIで接続し、TicketSQL検索・コメント・返信を会話から行えます。認証トークンの作り方と、返信を安全に任せる設定をまとめます。

読了目安 約10分

RTコネクタでできること

RTコネクタは、Request Trackerの開発元であるBest Practical Solutionsが提供するMCPサーバーです。Claudeのコネクタ一覧では「Anthropic verified」の表示が付き、追加時期は2026年3月と載っています。

自社で動かしているRTにREST2 APIで接続し、会話の中からチケットを扱えます。できることは次のとおりです。

  • TicketSQLでのチケット検索
  • チケットの詳細と履歴の閲覧
  • チケットの作成と更新(カスタムフィールド、カスタムロール、リンク、日付項目を含む)
  • 内部コメントの追加と、依頼者への返信
  • キューとユーザーの参照

SaaS型のヘルプデスクと違い、接続先はあなたの組織のRTサーバーです。READMEには、Best Practicalや第三者へデータを送らず、通信はAIクライアントと自社のRTの間だけで行われると書かれています。

検索だけでなく、返信の送信とステータス変更まで届く点が要です。何を任せて何を人が確認するかを、接続の前に決めておくと運用が安定します。

接続に必要な条件

READMEが挙げる要件は3つです。

要件内容
RT内容6.0以降。REST 2.0 APIが有効であること(標準で含まれる)
Node.js内容18以降
認証内容RTの認証トークン

キューのライフサイクルや権限を扱うツールは、RT 6.0.3以降が前提です。これらのREST 2.0エンドポイントが6.0.3で追加されたためです。

トークンの作成には、RT側でManageAuthTokensの権限が要ります。この権限がないユーザーには、後述の「Auth Tokens」メニュー自体が表示されません。

動作確認済みのクライアントとしてREADMEが挙げるのは、Claude DesktopとClaude Codeです。ほかのMCPクライアントも、stdioサーバーを登録できれば動くはずとされています。

認証トークンを作る

RTにログインし、右上の「Logged in as」から「Settings」→「Auth Tokens」→「Create」と進みます。名前にClaudeなど用途が分かる語を付けると、あとで失効させるときに迷いません。生成されたトークン文字列は、コピーして安全な場所に保管します。

注意したいのは、トークンがユーザーアカウントに紐づく点です。READMEによると、Claudeからの操作はすべてそのユーザーの操作としてRTに記録されます。コメントや返信で送られるメールも、そのユーザー名義です。

選択肢として、専用のRTユーザーを作ってトークンを発行し、必要な権限だけを与える方法があります。個人のアカウントで発行すると、Claudeの操作と本人の操作が履歴上で区別できません。

REST2の疎通をcurlで確かめる

Claudeにつなぐ前に、トークンとURLがREST2で通るかを確かめておくと、不具合の切り分けが速くなります。REST2のドキュメントにある確認方法は次のとおりです。

curl -H 'Authorization: token XX_TOKEN_XX' \
  'https://rt.example.com/REST/2.0/queues/all'

XX_TOKEN_XXは発行したトークンに、URLは自社のRTに置き換えます。見えるキューの一覧がJSONで返れば成功です。{"message":"Unauthorized"}が返るときは、トークンを受け付けられていません。ヘッダーのAuthorization:と文字列の間に、tokenという語が入っているかを見てください。

Claudeに接続する

接続は2通りあります。どちらも、RTのURLとトークンを渡す点は同じです。

手順

Claude Desktopでの接続

  1. 1

    拡張パッケージを入手する

    READMEのリンク先であるリリースページから、.mcpbの拡張パッケージを入手してインストールします。

  2. 2

    コネクタの設定を開く

    Claudeアプリで「Customize」→「Connectors」を開き、一覧からRTを探します。

  3. 3

    URLとトークンを入力する

    RTのURL(例: https://rt.example.com)と、先ほどのトークンを入力します。

  4. 4

    読み取りだけで試す

    最初は「SupportキューのオープンなチケットをID順に5件」のような読み取りの依頼で、見える範囲を確かめます。

READMEは、claude_desktop_config.jsonに手書きする方法も併記しています。Claude Codeでは、プロジェクト直下の.mcp.jsonに次のように書きます。

{
  "mcpServers": {
    "rt": {
      "type": "stdio",
      "command": "npx",
      "args": ["mcp-server-rt"],
      "env": {
        "RT_URL": "https://rt.example.com",
        "RT_TOKEN": "your-auth-token"
      }
    }
  }
}

設定に使う環境変数はRT_URLとRT_TOKENの2つだけです。.mcp.jsonをリポジトリで共有する運用では、RT_TOKENに実際のトークンを直書きしたままコミットしないよう注意してください。チーム共有の設定には値を入れず、各自の環境で設定する形が安全です。

npm install -g mcp-server-rtで先にインストールしておくことも、npxでその場で起動することもできます。このサーバーはstdioで動き、Claudeを使う端末の上でプロセスとして起動します。stdioとHTTPの違いはMCPのstdioトランスポート仕様にまとめています。

TicketSQLでの検索を任せる

検索はsearch_ticketsが受け持ちます。サーバーは薄い中継役で、Claudeが組み立てたTicketSQLをそのままREST2のGET /tickets?query=に渡します。複雑な検索の前には、get_ticketsql_grammarでTicketSQLの文法リファレンスを引けます。

RTのドキュメントに載っている基本の型を、依頼文と対応させると次のようになります。

依頼の例TicketSQL
担当者のいないオープンなチケットTicketSQLOwner = 'Nobody' AND Status = '__Active__'
自分が持っている対応中のチケットTicketSQLOwner = '__CurrentUser__' AND Status = '__Active__'
期限切れの対応中チケットTicketSQLDue < 'today' AND Status = '__Active__'
完了済みのSupportキューのチケットTicketSQLStatus = '__Inactive__' AND Queue = 'Support'

__Active__は、そのキューのライフサイクルで「対応中」にあたる状態すべてに置き換わるプレースホルダです。Status = 'open'と書くより、独自のライフサイクルを使うキューでも取りこぼしが出にくくなります。

カスタムフィールドで絞るときの手順

カスタムフィールドはCF.{Category} = 'Bug'のように、波括弧の中に名前を書きます。名前を取り違えると検索が通りません。READMEの例では、先にget_queue_fieldsでキューのカスタムフィールド定義を確認してから検索しています。

依頼文にもその順序を入れておくと、推測での検索を避けられます。

GeneralキューのCategoryがBugのオープンなチケットを探してください。
先にキューのカスタムフィールド名を確認し、実行したTicketSQLも示してください。

実行したTicketSQLを示させておけば、結果が妙なときに条件の誤りを人が読めます。

コメントと返信は別のツール

返信の取り違えが、RT連携でいちばん痛い失敗になります。ツールは2つに分かれています。

くらべる

add_commentとadd_reply

内部向け

add_comment

依頼者には見えない内部コメントを追加します。担当者同士のメモや調査結果の共有に向きます。

依頼者に届く

add_reply

依頼者への返信を送ります。READMEの説明では、メールが送られる経路にあたります。

READMEの例では、add_replyにステータスを渡し、返信と同時にチケットをresolvedにする使い方が載っています。便利ですが、1回の操作で依頼者への通知まで進むため、下書きを確認する工程を飛ばさないことが大切です。

返信を人が確認する設定

依頼文で「返信文案だけを会話に出し、add_replyは呼ばない」と指定する方法があります。より確実なのは、Claude側でツールの権限を絞ることです。

Teamプランとエンタープライズプランでは、OwnerがコネクタのTool permissionsで、ツールごとに「Always allow」「Needs approval」「Blocked」を選べます。サポートページによると、読み取りは許可し書き込みは止める、といった制限も組織全体にかけられます。add_replyとupdate_ticketは「Needs approval」にし、検索系は「Always allow」にしておく構成が考えられます。

個人プランなど組織の設定がない環境では、このボタンに頼れません。その場合は、前に述べた専用ユーザーのRT権限が最後の防波堤になります。

落とし穴

トークンのユーザーに広い権限があると、Claudeにも広い権限が渡る

Claudeの到達範囲は、トークンを発行したRTユーザーの権限と一致します。管理者のトークンをそのまま渡すと、検索のつもりの依頼でも、書き込みや管理系のツールまで届きます。権限の絞り込みはClaudeの設定ではなく、RT側のユーザー設計で行います。

ツール数の違いに注意する

コネクタの紹介ページに載るツールは17個です。チケット・キュー・ユーザーの参照、作成と更新、コメントと返信、添付ファイルの取得と保存が並んでいます。

一方、GitHubのREADMEには、これに加えて「キュー管理」のツールが26個載っています。キューの作成と更新、ユーザー定義グループ、カスタムフィールドの作成、ライフサイクルの定義、権限の付与と取り消しなどです。grant_rightsのように、RTの権限そのものを変えられるツールも含まれます。

紹介ページとREADMEで数が違う理由は、どちらにも書かれていません。どのツールが使えるかは、インストールした版によって変わる可能性があります。接続後にClaudeのツール一覧を開き、create_queueやgrant_rightsが並んでいるかを自分の目で見てください。

管理系のツールが見える環境では、検索と返信のために接続しただけでも、権限の変更まで依頼できてしまいます。これらは「Blocked」にするか、権限の小さいユーザーのトークンで運用すると安心です。READMEには、キュー構成を聞き取って設計するcreate-queueプロンプトも用意されています。新しいキューを作る場面では便利ですが、本番のRTで試す前に検証用のRTで動きを見ておくと安全です。

つながらないときの切り分け

症状見る場所
Unauthorizedが返る見る場所curlの確認で、Authorization: token ...の形になっているか
「Auth Tokens」メニューがない見る場所RT側でそのユーザーにManageAuthTokens権限があるか
キューやチケットが見えない見る場所トークンのユーザーが、そのキューを見る権限を持っているか
グループや権限のツールが失敗する見る場所RTが6.0.3以降か
コネクタが起動しない見る場所Node.jsが18以降か(node --version)

curlが通るのにClaude経由で失敗するなら、RT_URLの末尾やトークンの貼り付けミスを疑います。RTのURLには、/REST/2.0/より手前の、RTのベースURLを入れます。

他のチケット系コネクタとの違い

ClaudeのチケットまわりのコネクタはRTだけではありません。ServiceNow、Freshservice、Zoho Deskの記事でも、それぞれの接続を扱っています。RTの特徴は、次の3点です。

  • 接続先が自社運用のサーバーで、RT自体のバージョンが接続可否を左右する
  • 認証がRTユーザーの認証トークンで、サインイン画面でアクセスを許可する形ではない
  • 検索言語がTicketSQLで、依頼文からクエリへの翻訳をClaudeが担う

オンプレのRTを情報システム部門や学内ヘルプデスクで使っている組織では、クラウド型の製品向けの記事がそのまま当てはまりません。接続前に、RTのバージョンとトークンの権限を確認するところから始めてください。

Claude Codeで使う場合の基本は、Claude Codeの総合ガイドにまとまっています。

この記事を共有:XはてブLinkedIn

関連する記事

Claude をもっと見る →