Jira Service Management向けClaude:チケット向けではない4つのJSMツール

Atlassianは他社がまだ約束しているだけのことを実現した

私はeeselでAIエージェントを構築しており、実質的には他社のツール仕様を読むのが仕事のようなものだ。「Claudeを自社のヘルプデスクに接続できるか」という質問は、今年私の受信箱に届いた中で圧倒的に多かった。答えは大抵、何らかの形の「いいえ」だった。

Claude for Zendeskを調べたとき、Zendeskが出していたのはMCPサーバーではなくMCPクライアントだった。Freshdeskは早期アクセスプログラムの向こう側にある。Gorgiasにはマーケットプレイスの掲載すら存在しない。Help Scoutは本物のサーバーを出したが、意図的に読み取り専用にした。

Atlassianはただそれを作った。Rovo MCPページにはAIクライアントのタイル一覧があり、Claudeは4つのうちの一つとして、CursorやVS Code、ChatGPTと並んで掲載されている。本文には直接こう書かれている。「AtlassianからのコンテキストがClaudeで必要な場合でも」フローの中に留まれる、と。他社のモデルに自社の顧客を意図的に誘導するベンダーが、自社のマーケティングページ上でそれをやっている。

アクセスモデルも異例なほど寛大だ。Atlassian自身のFAQには「すべてのAtlassian Cloud顧客がアクセス可能」とある。プランが変えるのはスループットだけで、Freeサイトは1時間あたり500回、Standardは1,000回、PremiumまたはEnterpriseはユーザーあたり20回追加された1,000回から最大10,000回の上限まで得られる。Rovoのサブスクリプションも不要で、Atlassianの言葉を借りれば、このサーバーは「AIモデルではなく統合レイヤーだ」からだ。

というわけで、この記事は糾弾記事ではない。サービスデスクを期待していたのに、代わりに作業トラッカーを手にするまでに午後を丸々費やしてしまう前に、誰かに教えてほしかったことをまとめたものだ。

ClaudeをJira Service Managementに接続する4つの方法

道は4つある。それらは、他のすべてを合わせたよりも重要な一つの軸に沿って分かれる。チケットを起票した本人の前に言葉を届けられるかどうかだ。

このチャートの形こそが議論のすべてだ。即座に使え、公式で、無料なルートが、まさに依頼者に返信できないルートだ。これはHelp Scoutで見つけたのと同じトレードオフだが、Atlassianは別の方向からそこにたどり着いている。Help Scoutは意図的に読み取り専用として出した。Atlassianは書き込み機能を出しながら、それを一度もサービスデスクには向けなかった。

ルート1:公式サーバー、はじめから終わりまで

エンドポイントは1本の文字列だ。

https://mcp.atlassian.com/v1/mcp/authv2

どこかから古い設定をコピーしてくる前に、一つ警告がある。Atlassianはレガシーな SSEトランスポートを廃止した。2026年6月30日以降、https://mcp.atlassian.com/v1/sseはサポートされない。その日付はすでに過ぎている。春先の同僚のブログ記事から設定を引き継いだのであれば、それはすでに死んでおり、症状は廃止というより認証エラーのように見えるだろう。

Claude Code向けには単一のコマンドで済む。

claude mcp add --transport http atlassian https://mcp.atlassian.com/v1/mcp/authv2

その後/mcpを実行してOAuthフローを走らせる。Claude Desktopでは、Settings、Extensions、Browse extensions、PluginsからAtlassianを検索する経路になる。そしてclaude.aiでは、Atlassianの掲載がコネクタディレクトリにあり、Atlassianが構築した読み書き両対応のものとして説明されている。

実装上のある詳細が、まさに最初の呼び出しでつまずきの原因になる。すべてのツールがcloudIdを要求し、それを得る方法はgetAccessibleAtlassianResourcesであり、Atlassianはこれをあらゆるツールで必須の最初の呼び出しと説明している。これを飛ばしてsearchJiraIssuesUsingJqlをClaudeに直接叩かせると、返ってくるエラーは権限の問題のように見える。しかし実際はそうではない。

初日に知っておく価値のあるもう一つのこと。ClaudeはあなたのMCPサーバーに、決して手元のノートパソコンからではなく、Anthropicのインフラから到達する。これはClaude Desktopでも同様だ。したがって、AtlassianサイトがIP許可リストの背後にある場合、OAuthの同意画面は問題なく表示され続ける一方でツール呼び出しは失敗する。これはおそらく最も紛らわしい失敗モードだろう。

ルート2:4つのJSMツールと、その手前にあるトークンの壁

さて、私を立ち止まらせ、ページを二度読み直させた部分に進もう。

Atlassianは約46個のツールを公開しており、13の権限グループに分かれている。Jiraは14個。Confluenceは12個、Bitbucketも12個、Compassは10個。Jira Service Managementは4個だ。

これらはすべてオンコールアラートに由来するJSMの運用側に属している。サービスデスクそのものには一つも触れない。リクエスト、リクエストタイプ、キュー、SLA、承認、ポータル顧客、ポータル設定のいずれに対しても、公開されているツールは一つもない。

そしてその4つの手前にすら、第二の壁が立ちはだかる。Atlassianのサポート対象ツールのページには、JSMツールは「APIトークンによる認証のみをサポートする」とあり、「組織管理者によってAPIトークン認証が有効にされている場合にのみ利用可能」だと書かれている。一方でOAuthはデフォルトのフローであり、推奨されているフローでもある。したがってほとんどの人にとっての実際の結果は、通常のClaudeログインではJSMツールが一切表示されないということであり、インターフェース上にはその理由を説明するものが何もない。

ちなみにCompassは逆のルールで動いている。OAuthのみで、APIトークンはない。Bitbucketは APIトークンとリンクされたワークスペースの両方を要求する。3つのプロダクトに3つの異なる認証ルールがあり、それらすべてが一つのサーバーの中に共存している。

サービスデスクで実際に何ができるか

とはいえ、Claudeがあなたのチケットに対して完全に無力なわけではない。JSMプロジェクトは内部的にはJiraプロジェクトなので、汎用のJiraツールはその上で機能する。getVisibleJiraProjects、getJiraIssue、searchJiraIssuesUsingJql、getTransitionsForJiraIssue、transitionJiraIssue、editJiraIssue、addCommentToJiraIssueはいずれもJSMの作業項目に対して問題なく動作する。

この区別は見た目以上に重要だ。Atlassian自身のドキュメントは、リクエストタイプが何をもたらすかについて率直に書いている。「リクエストタイプなしで作業項目を作成すると、そのリクエストはJira Service Managementの全機能にアクセスできなくなります」と。Claudeが見ているのはサービスデスクの下にあるJiraレイヤーであって、サービスデスクそのものではない。あなたのエージェントがSLAの時計、キュー、ポータル、紐づいた顧客を伴うリクエストを見ているところで、Claudeが見ているのはただの作業項目だ。

このギャップの最も鋭い現れがコメントだ。サービスデスクAPIでは、顧客への可視性はコメント本文にある一つのブール値だけに集約される。

POST /rest/servicedeskapi/request/{issueIdOrKey}/comment
{ "body": "Hello there", "public": true }

public: trueは依頼者がポータル上で目にする返信であり、public: falseはエージェントだけが見る内部メモだ。別のエンドポイントも可視性オブジェクトもなく、ただこのフラグだけがある。そしてMCPツールのaddCommentToJiraIssueは、公開されている説明の中に相当するパラメータを持っていない。つまりClaudeには、自分が書く言葉が依頼者向けなのかどうかを示す手段が一切ない。ITデスクにおいてこれは些細な欠落ではない。同僚へのメモと、役員へのメールの違いに等しい。

後でAPIの道を選ぶ場合に知っておく価値がある点として、サービスデスクのコメントリソースはGETとPOSTしか公開していない。PUTもDELETEもない。コメントを取り消すには、/rest/api/3/issue/{id}/comment/{id}にあるJiraプラットフォームAPIまで降りる必要があり、自分のコメントを編集または自分のコメントを削除のいずれかの権限を保持している必要がある。必要になる前に、取り消しの方法を計画しておこう。

ルート3:自分で構築する場合のサービスデスクREST API

キューを認識し、SLAを認識し、顧客に見える形の挙動が欲しいなら、自分で/rest/servicedeskapi/に対して実装することになる。それは週末で終わる仕事ではなく本物のプロジェクトであり、想像以上に設計を左右する3つのことがある。

レート制限は同時に3つのシステムだ。Atlassianは、あなたの連携は「この3つすべてに対応しなければならない」と述べている。ポイントベースの1時間あたりのクォータ、秒あたりのバーストリミット、そしてその上に課題ごとの書き込み制限が乗る。デフォルトのグローバルプールはテナント間で共有される1時間あたり65,000ポイントで、テナントごとのプールはFreeの65,000からEnterpriseのユーザーあたり30ポイント加算された150,000まであり、上限は500,000に達する。バーストのデフォルトはGETとPOSTで秒あたり100リクエスト、PUTとDELETEで50リクエストだ。課題ごとの書き込みは2秒で20回、30秒で100回が上限になる。そして一つのエンドポイントだけが他と比べて劇的に狭い。GET /servicedeskapi/servicedesk/{id}/customerは秒あたり5リクエストに制限されており、これは顧客データの一括取り込みで最初にぶつかる壁になるだろう。

**静かな権限エラー。**AtlassianはGET /request/{id}/commentについて、「例えばユーザーがサービスデスクやリクエストへのアクセス権を持っていない場合でも権限エラーは提供されず、このメソッドは単に空のレスポンスを返す」と文書化している。コメントを一つも読み取れず、そこから「コメントは存在しなかった」と結論づけたエージェントは、結果として完全な自信を持って間違った質問に答えることになる。

ナレッジベースへのアクセスは検索のみ。GET /rest/servicedeskapi/knowledgebase/articleはクエリに一致する記事を、サービスデスクごとまたは全サービスデスク横断で返し、queryは必須だ。この名前空間の中には記事の本文全体を取得できるものが一つもないため、ナレッジベースに基づいた回答を生成するには、Confluence APIへの二度目のアクセスが必要になる。良い点として、この2つのKBエンドポイントはアプリのアクセスルールの適用対象外であり、これはリクエストやコメントのエンドポイントとは異なる扱いだ。

JSMへの1件の返信が実際に何を要するか

ここで読み取り専用という制限が、財務的に興味深い意味を持ち始める。トークンは安く、それが買うものは限られている。

根拠のある回答は、チケット、遷移情報、Confluenceのページ2件を取得した時点でおよそ12,000の入力トークンに達し、さらに戻りに約700の出力トークンがかかる。Claude Sonnet 5で100万トークンあたり2ドルと10ドルの料金の場合、これは約3.1セントになる。プロンプトキャッシュが機能し、キャッシュされた読み取りが100万トークンあたり0.20ドルになれば、1.3セントに近づく。Claude Opus 5で100万トークンあたり5ドルと25ドルの場合、同じ回答は7.8セントに近くなる。

次に比較だ。Atlassian自身のバーチャルエージェントは月あたり1,000件のアシスト付き会話を含み、それを超えると1件あたり0.30ドルから課金される。あるインテントにマッチした後に人間へエスカレーションされた会話であっても課金される。Rovoクレジットはまったく別の課金メーターであり、Standardはユーザーあたり月25、Premiumは70、Enterpriseは150となっている。MCPサーバーのベータ版であるTeamwork Graphツールは現在は無料だが、Atlassianは一般提供の際には「1呼び出しあたり最低1 Rovoクレットで課金される」と述べており、90日前の告知が行われる予定だ。

会話単位のどんな数字も鵜呑みにする前に、この問題を直接製品チームへ持ち込んだあるITマネージャーからの一つの注意点がある。

"One example: virtual agent will count a ticket as "successfully deflected" if the user gives up responding and it auto closes. That's not a successful deflection, that's an awful user experience."

u/Goose-tb, r/ITManagers

これは、私たちのツールも含めて選ぼうとしているどのツールについても照らし合わせて確認する価値がある。放棄を成功として数える偏向率は間違ったものを測定しており、それは更新の商談の場で最も引き合いに出されやすい数字でもある。

自分自身の数字を当てはめてみてほしい。

この3つの数字を素直に読むと、トークンの列が最も安いのは、それが最も少ないものしか買わないからだ。返信パイプラインも、可視性フラグも、キューへのルーティングも、SLA意識も存在せず、実際の依頼者に出会う前に自分自身をテストする方法もない。それをリクエスト単位の価格と比較するのは、リサーチアシスタントとエージェントを比較するようなものだ。有用ではあるが、同じ仕事ではない。

管理者側の話、そしてなぜ「アクセス拒否」と表示されるのか

一つのツール呼び出しが届くまでに、4つの独立した条件がすべて満たされている必要がある。それぞれが異なる形で失敗する。

1. **AIドメインが許可されている必要がある。**AtlassianはClaudeとChatGPTを含むAIパートナードメインのデフォルトリストを提供している。管理者はそれを許可またはブロックできるが、Atlassianは明確に「個々のドメインをブロックすることはできません。ドメインリスト全体を許可またはブロックすることしかできません」と述べている。これによりClaudeだけを許可して他を拒否する方法は存在しない。
2. IPが許可リストを通過する必要があり、これは厄介だ。というのも「ブロックされたIPから接続するユーザーに対してもOAuth 2.1の同意画面は表示され続ける可能性があるが、ツール呼び出しは失敗する」からだ。接続は、何もしなくなるその瞬間まで成功しているように見える。
3. **認証方式が許可されている必要がある。**APIトークン認証は組織全体のスイッチであり、まさにこのスイッチがJSMツールがそもそもあなたに存在するかどうかを決める。ちなみにドメインブロックはAPIトークン接続には適用されない。
4. **ネットワークの送信経路が*.atlassian.netに到達する必要がある。**これは、サーバーがiframeを介してAIクライアント内にインタラクティブなJiraとConfluenceのウィジェットを描画するためだ。

これらすべてに加えて、権限タブによって組織管理者は今やアプリごとに読み取り、書き込み、検索を個別に許可またはブロックできるようになっており、Atlassianはこれが「Connected Appsの設定より優先される」と述べている。「今後の追加項目に適用する」というトグルもある。これはひっそりと、新たに追加された権限が誰もレビューしないまま許可を継承しうることを意味する。アクセスレビューを承認する立場にいるなら、このトグルは一度確認しておく価値がある。

セキュリティチームが尋ねる前に伝えておくべきコンプライアンス上の事実が2つある。サーバーはJiraやConfluenceのコンテンツを一切保存もキャッシュもせず、ログインユーザーの権限内で厳密に動作しており、これはほとんどのコネクタよりも優れたデフォルトだ。しかしAtlassianは「現時点でFedRAMPまたはHIPAAの要件をサポートしていない」と述べており、Cloud限定でData CenterやServerの経路は公開されていない。多くの規制対象のIT サービスデスクにとって、この2つの文はその場で評価を終わらせるものだ。

実際に人々が直面していること

最も声の大きい不満は、ツールやクレジットに関するものではない。トークンが絶えず期限切れになることだ。「The MCP Auth expires too fast」というタイトルのAtlassianコミュニティのスレッドは2025年10月から2026年3月まで続き、約16,500回の閲覧があり解決には至っておらず、Claude Codeユーザーの声で溢れている。

"Bump! I need to reauthenticate sometimes once an hour, sometimes once every 10-20 minutes. This morning I authenticated the MCP connection then sent my prompt, 12 minutes later claude code was getting a 401 response and I only had a single terminal session open. This is basically unusable, I guess I'll just need to build some custom tools to utilize the API."

Aaron Kirn, Atlassian Community

同じスレッドのCommunity Championが原因を明確に指摘している。サーバーは短命なOAuthトークンを発行し、外部クライアントはそれを自動的に更新できず、長命なトークンはまだ提供されていない。チャットするだけでなくエージェントを動かしている場合、そこから2つのことが導かれる。

並行するセッションは互いに干渉し合う。あるウィンドウで認証すると、他のウィンドウが静かに認証解除されると複数の人が報告しており、これはマルチエージェントのワークフローを苦痛なものにする。そして新しい/mcpエンドポイントは古いものよりも静かに失敗する。あるユーザーは、/sseは少なくとも捕捉可能な401を返していたが、その後継は「単に静かに失敗する」と指摘している。リトライを実装するなら、エラーコードだけでなく空の結果も捕捉すべきだ。

ツールの品質にはそれ自体のスレッドがあり、これは私が予想していなかった部分だ。MCPサーバーに携わるAtlassianのPMがRedditで公式に返信している。

"Tool quality - the problem you mention where the Jira create tool doesn't respect required fields is something we just need to fix. We've been moving quickly to release a broad range of tools, and now we need to go back and fix some of those pain points. Tool descriptions included. You'll see some improvements here soon Context bloat - we acknowledge this is a problem as well. There are many more tools we want to provide but the current design is already at it's limit."

u/atlassiadam, Atlassian PM, r/mcp

クレジットへの不安はもう一つの大きなテーマであり、これは主にMCPではなくRovoに関するものだ。あるBitbucketユーザーは、たった一つのプルリクエストレビューが月次割り当ての半分近くを消費したと報告している。

"Rovo had a look at the PR and made a few suggestions and in doing so appeared to use 965 of my 2000 credits with 760 being marked as 'Code review in Bitbucket', I'm not sure where the other 205 went?? Either I'm doing something amazingly wrong or that's not value for money at all."

Chris Mingay, Atlassian Community

そのスレッドではAtlassianのプロダクトマネージャーが返信し、その計算が重いことを認めている。これは公正であり、異例なほど率直だ。同じ懸念はRedditにも表れており、Standardプランのあるユーザーがその比較を声に出している。

"advertised ($0.01 per credit after the initial 2000), copilot is a mere $10 for 300 claude 4.5 requests why is it so expensive? the free tier..."

Rovo Dev credits, r/RovoDev

同じ投稿者は、2,000クレジットの4分の3をわずか数時間、30件に満たないリクエストで使い切ったと述べている。

まさにこの文脈があるからこそ、MCPサーバーの価格モデルは今日、懸念というより安堵として読める。そしてまさにそれゆえに、Teamwork Graphの課金に関する注記はカレンダーにリマインダーを入れておく価値がある。あなたのプランに含まれて無料であることと、クレジット制で課金されることはまったく別の製品であり、Atlassianはこれら4つのツールのうち2つがどちらの方向へ向かっているかをすでに教えてくれている。

私なら実際にどう判断するか

目的が分析、QA、インシデントの記録、あるいはJiraとConfluenceを横断して一箇所で質問することであれば、今日すぐにこのコネクタをインストールしよう。今年私がテストした中で最良の無料のJira向けAIプラグインだ。無料で公式であり、権限モデルはしっかりしていて、実質的に読み取り専用であることは、本番のデスクに初めてAIを向ける際にはむしろ利点になる。このカテゴリで最も強力な無料のものであり、誰にも使うのをやめさせるつもりはない。

目的がオンコールであれば、4つのJSMツールはその価値に見合っており、管理者とAPIトークン認証を有効にする話をする価値がある。チャットウィンドウから直接アラートを確認しエスカレーションできるのは、本物のワークフローだ。

目的がチームが同じVPNの質問に何度も答えるのをやめられるよう、ティア1のリクエストを片付けることであれば、このコネクタはそのためのツールではなく、どれだけプロンプトを工夫してもそうはならない。必要なのは、/rest/servicedeskapi/を話し、公開の返信と内部メモの違いを理解し、あなたがすでに設定しているキューとSLAポリシーを尊重し、エスカレーションをきれいに処理し、まだ起きていないリクエストに出会う前に、すでに起きたリクエストに対してテストできるものだ。きちんと比較検討したいなら、ITSM向け最良のAIのまとめがこの分野をカバーしている。

Jira Service Management向けeesel AI

その最後の仕事こそ、私たちが構築しているものだ。eeselは横に取り付けられたウィジェットではなく、本物のAIエージェントとしてあなたのサービスデスクに参加する。リクエストを読み、返信を下書きして送信し、内部メモを追加し、リクエストのフィールドを更新し、優先度を設定し、チームへ振り分ける。それらすべてが、あなたがすでに持っている割り当てルールとSLAポリシーの範囲内で行われる。

これを実際のデスクで評価するなら、私が最も気にかけるのはシミュレーションだ。実際のリクエストに何かが触れる前に過去のリクエストを再生し、テーマ別に内訳された カバレッジ率を得て、その実行で明らかになったギャップを埋め、数字が十分良くなってから初めて公開する。私たちがこれを作ったのは、自信ありげに聞こえるボットが他人のキューで間違った回答をするのを見てきたからであり、自分自身の履歴に対する試運転こそが、それを事前に知るための唯一の誠実な方法だからだ。

社内サポートデスクでこれがどのように見えるかの一例として、InDebtedは5つの市場にまたがる数百人の従業員を支える5〜10人規模のIT部門のためにJSMを運用している。彼らのナレッジはConfluenceとSlackボットから供給されている。

"We use it to be the first responder to our Helpdesk tickets in Jira. It essentially acts just like an agent would."

Jason Loyola, IT Team, InDebted, eesel case study

現在、彼らは受信するJiraチケットの15%を偏向させており、ナレッジベースが充実するにつれて55%を目標にしている。デモの数字ではなく、実際のデスクから得られた実際の数字だ。そして正直な部分は、それが55%からではなく15%から始まったということだ。

料金は処理したリクエスト1件あたり0.40ドル。返信単位ではなくリクエスト単位で課金されるため、15往復のやり取りであっても1回分の課金として数えられる。開始時にはカード登録なしで50ドル分の無料利用枠があり、これは125件のリクエストに相当し、すべての機能が解放された状態で使える。

サービスデスクがJSM以外の場所にある場合でも、同じエージェントはZendeskと他の6つのヘルプデスク上で動作する。

考えるためにはAtlassianのコネクタを使おう。回答するためには、サービスデスクAPIを話せるものを使おう。仕事の種類は違うが、良いニュースは、2026年にはもうどちらか一つだけを選ぶ必要がないということだ。