Jira Service Management向けChatGPT:本当に機能する4つのルート

まず、ChatGPTとJSMについて多くの人が誤解していること

私は毎日の大半を統合の構築に費やしており、受信トレイに届く質問はほぼ常に同じだ。「ChatGPTを自社のサービスデスクにどう組み込めばいいか」。もっと有益な質問は別にある。実際に何を手に入れようとしているのか、ということだ。

答えが「JSM内でエージェントを助けるGPTモデル」であれば、あなたはすでにそれを持っているかもしれない。Atlassian自身の透明性ページには「Jira Service Management内のAI提案は、OpenAIが開発した大規模言語モデルによって動いている」とあり、その背後にあるモデルとしてOpenAIのGPTシリーズを挙げている。仮想サービスエージェントはその範囲をGoogleとLlama、さらにオープンソースのLlamaモデルにまで広げる。Rovo全体はさらに込み入っていて、Atlassianは自社ホストのLlamaとMixtralが「OpenAIのGPTシリーズによるサードパーティホストのLLMと並んで」動作し、シナリオごとに選択する動的ルーティングがあると説明している。

つまりGPTはすでにあなたのサービスデスクの中にいる。手に入らないのはそれをコントロールする部分だ。bring-your-own-keyもモデル選択もない。そしてAtlassianが提供する唯一のモデル関連の選択は逆方向に働く。Cloud Enterpriseの組織はAtlassianホストのモデルのみを要求でき、処理をAtlassian Cloudの境界内に留められるが、その代わり「パフォーマンスとレイテンシのわずかな変動」というコストを払うことになる。この内蔵オプションについては、私のJSM AI評価記事や、Atlassianサービスデスクのレビューで他の選択肢と比較している。

この記事の残りの部分は、質問のもう一つの読み方、つまりChatGPTクライアント自体をあなたのサービスデスクに向ける方法を扱う。それを実現する4つの方法があり、それぞれ大きく異なる場所にたどり着く。

ルート1:ChatGPT内の公式Atlassianコネクタ

これは正面玄関であり、確かに存在する。AtlassianのRovo MCPサーバーページには、Claude、Cursor、VS Code向けのものと並んで「Add to ChatGPT」のディープリンクがある。導入ガイドはさらに踏み込み、サーバーは"MCPをサポートするあらゆるアプリ"をサポートすると述べ、そのリストの筆頭にOpenAIのChatGPTを挙げている。以前にChatGPTコネクタを設定したことがある人なら、その流れに見覚えがあるだろう。

このページには立ち止まる価値のある2つの詳細がある。まず、無料であること。Rovo MCPサーバーにRovoの購読は不要で、Freeを含むあらゆるAtlassian Cloudプランで動作する。Atlassianはこれをそれ自体をAI製品ではなく統合レイヤーとして扱っているからだ。レート制限はFreeで1時間あたり500コール、Standardで1,000コールで、PremiumとEnterpriseはユーザー1人あたりの割り当てを追加し、最大10,000まで増える。ただしCloud限定だ。Data CenterとServerのサイトにはここへの道が一切ない。

次に、Atlassianが書いたChatGPTタイルの文言を読んでほしい。「ChatGPTから直接、Jiraの課題を検索、要約、作成」。Jiraの課題だ。リクエストでもチケットでもない。Jira Service Managementはそのページの4つのクライアント文言のどこにも登場しない。それは書き方が雑だからではない。実際に手に入るものを正確に描写しているのだ。

それで実際に何ができるか

JSMプロジェクトはJiraプロジェクトなので、汎用のJiraツールグループは依然としてかなりの範囲をカバーする。getVisibleJiraProjects、getJiraIssue、searchJiraIssuesUsingJql、transitionJiraIssue、editJiraIssue、addCommentToJiraIssueが使え、そのどれもがサービスデスクにたまたま存在するワークアイテムに対して喜んで動作する。JQL検索、そしてトランジション、そしてコメント。それは本物のワークフローだ。「このチケットを要約して何が変わったか教えて」がほとんどの要望である社内ITデスクにとっては、十分なことが多い。

全体では、13の権限グループにまたがって約46のツールがある。getAccessibleAtlassianResourcesは最初に必須となる呼び出しで、他のすべてが必要とするcloudIdを返す。Confluenceには読み取り、書き込み、検索の独自のグループがあり、ナレッジベースがConfluenceにある場合は大きな意味を持つ。すでにConfluenceの自動化を運用しているチームは、Jiraグループよりもそちらのグループから多くを得るだろう。

実際にぶつかるセットアップの落とし穴

紙の上で機能するコネクタと、プロンプトの中で機能するコネクタは別物であり、Atlassianのコミュニティフォーラムにはそれについての長い記録がある。何かにたどり着く前に、2つのことが噛みつく。アプリはChatGPT Businessのワークスペースではデフォルトでオンだが、EnterpriseとEduではデフォルトでオフになっており、管理者がまず有効化し、次にディレクトリから公開する必要がある。複数の管理者は、Atlassianのツールが表示される前に、ルート2が必要とするのと同じ設定である開発者モードもオンにしなければならなかったことに気づいた。症状は繰り返される。認証は問題なく通るのに、そのまま単にグレーアウトして座っているコネクタだ。

FWIW we're having the same issue as Blake: the connection is configured and shows "Works with Chat, Deep research" but when trying to use it in a prompt, the option is grayed out.

Alexander Corradini, MCP Not working with ChatGPT OpenAI Spec, Atlassian Community

そのスレッドでの解決策は、ドキュメントからではなく別の管理者からもたらされた。コネクタをワークスペースに公開する必要がある。それを書き記した人はそれまで誰もいなかった。

Thanks Jose! That was it for me: I needed to publish the connector. Now I can use the Atlassian connector in prompts.

Alexander Corradini, MCP Not working with ChatGPT OpenAI Spec, Atlassian Community

その手順はコネクタ自体ではなくワークスペース設定の中にある。ChatGPT TeamsやBusinessのワークスペースを管理しているなら知っておく価値がある。

誰もがそこにたどり着けるわけではない。あるChatGPT for Businessのオーナーは、10月から2月にかけて3つの別々のスレッドで同じ問題を報告した。その要約は、この記事全体で最も率直なデータポイントだ。

I'm approaching month 4 and have no way of getting this to work.

Travis Polland, MCP Server 99% does not work in ChatGPT, Atlassian Community

彼はまた、同じセットアップでClaudeとCursorは問題なく動くとも報告しており、それはサーバーよりもクライアント側を疑わせる。同じ期間の前には、ChatGPTが「search action not found」というエラーでサーバーを完全に拒否したこともあり、Atlassianのプロダクトチームのメンバーはそのスレッド上で、ChatGPTのdeep researchツールサポートがまだ開発中であることをスレッド上で認めている。可用性もばらつきがある。ある管理者はフォーラムで報告した、公式コネクタが「英国拠点であるため、まだ利用可能になっていない」ということを。

私の見解: チームがすでにChatGPTを日常的に使っていて、Jiraのワークアイテムを読んで要約するだけでいいなら、10分かける価値はある。サービスデスクのワークフローをこれ中心に組み立ててはいけない。

ルート2:開発者モードでのカスタムMCPコネクタ

パッケージ化されたコネクタにツールが不足している、あるいは自分の地域にコネクタが存在しない場合はどうするか。次のステップは、MCPエンドポイントを自分で追加することだ。OpenAIはこれを開発者モードと呼び、完全なMCPクライアントサポートとして「読み取りも書き込みもすべてのツール向け」と説明しつつ、同じ文の中で「強力だが危険」とも呼んでいる。

その道は設定、次にセキュリティとログイン、次に開発者モードとたどる。それがどこにあるかに注目してほしい。ラボメニューではなく、セキュリティの下にある。そこからChatGPTのプラグインページでアプリを作成し、名前と説明を付け、/mcpパスを含むMCPサーバーのURLを貼り付ける。現在のAtlassianエンドポイントはhttps://mcp.atlassian.com/v1/mcp/authv2だ。https://mcp.atlassian.com/v1/sseを指す古い設定が残っていないだろうか。そのルートは2026年6月30日以降に廃止され、今では認証エラーのように見える形で確実に失敗する。

利用資格は多くの人が想定するよりも広い。利用資格の記載によれば、開発者モードはPro、Plus、Business、Enterprise、Educationの各アカウントで利用可能であり、これはEnterprise限定ではない。ただし2つの注意点がある。ウェブ限定であること、そしてワークスペースのポリシーがそれでも無効化できることだ。

この方法で構築したものは何であれ、ChatGPTアプリの他の部分と並んでドラフトアプリとして着地し、同じApps SDKの基盤の上に乗る。そこからチャットとdeep researchの両方で選択可能になるが、実際にはモデルがそれを使う前に、プロンプトの中でツール名を指定しなければならないことが多い。

書き込みアクションはここでは実際に機能する。それぞれデフォルトで確認を求め、OpenAIはこれをreadOnlyHintアノテーションに結び付けている。開発者モードガイドは「このヒントのないツールは書き込みアクションとして扱われる」と明言している。承認は会話の中では記憶される。新しい会話を始めれば再び尋ねられる。サービスデスクにとってはおそらくそれが正しい挙動であり、この方法で無人トリアージを行う人が誰もいない理由でもある。

2日目に現れる摩擦

Atlassian MCPのすべてのスレッドを支配する不満が一つあり、それはツールとは何の関係もない。トークンの寿命だ。

twice a day? Try every 30 minutes or so. Sometimes I have to re-authenticate multiple times in the same session. I don't know why the auth can't persist for 7 days or something normal.

Liam Hall, The MCP Auth expires too fast, Atlassian Community

同じスレッドで、あるCommunity Championがその仕組みを説明している。現在のプレビューでは、サーバーは短命なOAuthトークンを発行し、外部クライアントにはそれを自動更新する手段がない。そのため、明白な回避策は開発者たちが求め続けても得られないものだ。

Atlassian MCP is unusable due to the longevity of their auth tokens. Needing to reauthenticate twice a working day is horrible. Why can;t I inject my personal access token into it; that is longlived and properly in control. This is worthless.

Jochem Berends, The MCP Auth expires too fast, Atlassian Community

その疑問はこの記事全体の要となるものだ。独自のセクションでそれを扱う。

JSMツールを手の届かない場所に置く認証のミスマッチ

これは私が信じるまでに3回読み返した部分だ。

Atlassianのサポート対象ツールリファレンスにはJira Service Managementツールグループがある。その中にはちょうど4つのツールがある。getJsmOpsAlerts、getJsmOpsScheduleInfo、getJsmOpsTeamInfo、updateJsmOpsAlertだ。この4つすべてがOperationsとオンコール、つまり旧Opsgenie側の製品に属する。リクエスト、リクエストタイプ、キュー、SLA、承認、ポータル顧客、組織のいずれに対しても公開されたツールは存在しない。

そして扉を完全に閉じる一文が続く。Atlassianは「Jira Service Managementツールは、APIトークンによる認証のみをサポートする」と述べ、組織管理者がAPIトークン認証を有効にした後にのみ利用可能になるとしている。このグループにはOAuthの経路は存在しない。

これをChatGPT側と並べてみよう。OpenAIの開発者モードはサポートする認証としてOAuth、認証なし、混合認証を挙げている。プラグイン認証仕様ではツールごとのスキームタイプはnoauthとoauth2の2つしかなく、認証が必要なものはすべてOAuth 2.1を要求する。コネクタのフォームにはAPIキーの入力欄がない。ヘッダーの行もない。

ここで一つ落とし穴を指摘しておく価値がある。それが人を痛い目に遭わせるからだ。開発者モードのドキュメントには確かに「静的な認証情報が提供されれば、それが使われる」とあり、その一文はOAuthの箇条書きの中にある。それが意味するのは、動的登録の代わりに事前登録されたOAuthクライアントIDとシークレットのことだ。APIキーの入力欄ではない。だからこの経路にこだわるなら、回避策はトークンの手前に立つOAuthフロントのプロキシであり、どこかに忍ばせるヘッダーではない。

実際的な結論は短い。ChatGPTをAtlassianに接続すると、Jira、Confluence、Rovo検索、Platformツールが手に入る。4つのJSMツールは手に入らない。仮に何らかの方法で手に入れたとしても、それらはオンコールアラートツールなので、サポートリーダーがキューに以前より少しでも近づくことはない。管理者にとっては、これにはもう一つ皮肉がある。Atlassianは管理者向けガイダンスの中で、「OAuth 2.1を使用するAIツールについてはドメインをブロックできるが、組織へのアクセスにAPIトークンを使用する場合はできない」と述べている。ブロックもオール・オア・ナッシングで、個々のドメインを一つだけブロックすることはできず、パートナーリスト全体を許可するかブロックするかしかできない。すべてのOAuthクライアントを一度に締め出しても、JSMに実際に到達する認証方式は、あなたのドメインポリシーが統制できないままだ。

ルート3:サービスデスクAPIに向けたGPT Action

これは/rest/servicedeskapi/に実際に到達する最初のルートだ。また、もし顧客からChatGPTを本当にサービスデスク対応にしてほしいと頼まれたら、私が構築するルートでもある。

GPT ActionはカスタムGPT、OpenAPIスキーマ、認証設定から成り、通常のChatGPTエージェントのセットアップより一歩先を行く。なぜMCPが機能しない場所でこれが機能するのか。それは認証メニューだ。GPTエディタはなし、APIキー、またはOAuthを提供し、APIキーはさらにBasic、Bearer、カスタムヘッダーに分岐する(actionsの設定記事より)。JSMのスクリプト認証はHTTP Basic上でのemail:api-tokenであり、そのBasicサブモードにそのまま収まる。

それが解き放つのは本物のJSMリクエストAPIだ。リクエストの一覧表示と作成、承認の読み取りと応答、添付ファイル、参加者、通知購読。何より重要なのはコメントエンドポイントを解き放つことで、そのコメントエンドポイントこそ汎用Jiraツールが正しくできない唯一のことだ。

JSMにおける顧客可視性はPOST /rest/servicedeskapi/request/{id}/comment上のたった一つのブール値だ。addCommentToJiraIssueには対応するパラメータが存在しない。つまり、MCPで接続されたChatGPTは、たった今書いた言葉がリクエスト送信者に届いたのか、内部に留まったのかを教えることができない。サービスデスクにおいて、それは些細な粗さではない。それが仕事のすべてだ。

ぶつかる制限

• 45秒の往復。 OpenAIの本番稼働に関するガイダンスによれば、それが上限であり、忙しいデスクに対するJQL重めの検索はそこに触れる。
• 10万文字。 リクエストとレスポンスの両方で。説明文付きの200件のリクエストのリストは切り詰められる。
• 構築には有料プランが必要。 OpenAIはGPTの作成または編集に購読が必要だと述べており、管理されたワークスペース内ではあなたの役割もそれを左右する。
• ActionsはProモードでは動かない。 ヘルプセンターは「Actionsは Proモードでは利用できない」とはっきり述べており、最も強力な推論設定を選択肢から外す。
• Enterprise管理者は静かにそれを止められる。 Actionのドメインは管理者によって許可リストに登録され、許可されたドメインがないワークスペースはどのActionも実行できない。*.atlassian.netはそのリストに載っている必要がある。
• すべての書き込みが確認を求める。 x-openai-isConsequentialフラグはGET以外の操作をデフォルトでtrueに設定するため、明示的にfalseに設定しない限り、作成やコメントの呼び出しはすべて確認を求める。

私の見解: 本物の自前JSMヘルパーを求める、オペレーション寄りのチームに適した経路だ。顧客向けの返信に使うなら、コメント呼び出しのたびにpublicフラグを明示的に設定し、Jiraのコメントエンドポイントに決してフォールバックさせないようにしなければならない。いずれにせよ、あなたは今やOpenAPIスキーマとトークンローテーションポリシー、そしてすべての書き込みにおける確認プロンプトを抱えることになる。

ルート4:OpenAI APIと自前のコード

ChatGPTクライアントを完全に飛ばせば、すべてが手に入る。モデルを自分で選ぶ。AtlassianのMCPエンドポイントをResponses API呼び出しのtoolsエントリとして組み込むか、自前のサービスから直接JSMのREST APIを呼び出す。ChatGPTのUIが決して許さないrequire_approval: "never"を設定でき、ブラウザフローの下で期限切れになることのない長寿命のAPIトークンを保持できる。

同時に他のすべても引き継ぐことになる。認証のローテーション、リトライロジック、レート制限、評価のフレームワーク、変更が本番のキューに触れる前にテストする何らかの手段、加えて自分が今構築したもののオンコール当番だ。チームがこれに手を伸ばすのは、ワークフローが狭く高価値な場合で、重複インシデントの自動リンクがその典型例だ。本当に欲しかったのがサポートエージェントだった場合、これは悪い取引になる。なぜならその時点で、あなたは統合ではなく製品を構築していることになるからだ。Jira向けAIプラグインについてのガイドで、その境界線が通常どこに落ちるかを扱っている。

これらの経路のどれをとっても、はっきりさせておくべき一つのことがある。データは外に出るということだ。OpenAIはMCPガイドの中で、どんなMCPサーバーも「ChatGPTが提供するあらゆるデータにアクセスできる」と明言しており、そのリスクガイダンスはカスタマーサポートを攻撃対象として名指しし、「攻撃者はプロンプトインジェクション攻撃を含むカスタマーサポートリクエストをあなたに送りつけるかもしれない」と警告している。Atlassian自身のAIはOpenAI、Anthropic、Googleとのゼロデータ保持契約の下で動いている。それは、チャットクライアントを自分のデスクに直接向けるのとは実質的に異なる構成だ。ビジネス向けChatGPTの概要記事では、その境界線がどこにあるかをさらに掘り下げている。営業の電話では、このギャップが絶えず話題に上る。あるハードウェア企業の技術評価担当者は、何かを知らないときにAIがChatGPTにフォールバックするのか、そしてそれをオフにできるのかを率直に私に尋ねた。妥当な質問だ。正直な答えが、どの経路を選ぶべきかを形作る。

どのルートが自分に合うか

これらのルートのどれもサービスデスクに与えないもの

認証の詳細を取り除くと、そのギャップには形が見えてくる。上記のどのルートも、チャットウィンドウにJiraへのある程度のアクセスを与える。そのどれも、あなたのサービスデスクにエージェントを与えることはない。

本物のリクエストを取り巻くものを見てほしい。キュー、顧客、チャネル、承認者リスト、リクエストタイプ、リンクされた資産。ChatGPTコネクタが見えるのは説明フィールドとコメントだけだ。その右側パネルにある他のすべては、読み取るツールを持たないコンテキストだ。

キューは見えない。SLAの時計も同様であり、それは重要だ。なぜならJSMの3つのステータスカテゴリはカスタマイズできず、「顧客の返答待ち」は3つのうちのどれかに扮するしかなく、すべてのレポートがその歪みを引き継ぐことになる。リクエストチャネルも見えず、つまりSlackから届いたリクエストは、ポータルから届いたものと見分けがつかない。リクエストタイプも見えない。Atlassian自身のリクエストタイプに関するドキュメントは、それなしで作成されたワークアイテムは「Jira Service Managementのすべての機能にアクセスできなくなる」と警告している。つまり汎用Jiraツールを通じてチケットを作成するモデルは、静かに二流のチケットを作り出している。

私が最も懸念するギャップはコメントの可視性であり、それは理論上の話ではない。あるサポートマネージャーは、明示的な指示とConfluence上の正解ソースを使ってRovoエージェントを制約しようとした。

Despite this, the Rovo Agent continues to add public or externally visible comments to test tickets.

Vince Murphy, How can I get a Rovo Agent to only add internal comments, Atlassian Community

あるCommunity Championがそれを検証したところ、その限界はプロンプトの問題ではなく構造的なものだと判明した。エージェントが利用できる唯一のアクションは、顧客に見える形のコメントしか追加できなかったのだ。欠けているパラメータはプロンプトエンジニアリングでは修正できない。だからこそ私たちはあらゆるロールアウトを、実際のキューに触れる前に過去のチケットに対してシミュレーションする。私は自信ありげな口調のボットが間違った答えを出すのを見てきたし、それが内部メモとして着地するか顧客への返信として着地するかは、肩をすくめる程度で済むかインシデントになるかの違いだ。

専用に作られたオプションが代わりに何をするかについては、JSMへのAI追加についてのウォークスルーや、JSMチャットボットガイドがそれをカバーしている。

これらのルートのどれにも、事前のドライランはない。「これが先月の400件のリクエストに何をしていただろうか」と尋ねる方法はなく、それこそすべてのサービスデスクリーダーがAIをキューに近づける前に自問する質問だ。JSM向け最良のAIのまとめではそれを重く評価しており、より広いAIヘルプデスクソフトウェアの比較でも同様だ。それがロールアウトが2か月目を乗り切るかどうかの、単独では最良の予測因子だからだ。

プランの壁と各ルートの実際のコスト

Atlassian側の2つの壁がそれに加わる。Rovo検索、チャット、エージェントはすべてStandard以上が必要で、AIはPremiumとEnterpriseでのみ自動的に有効化される。仮想エージェントはPremiumの背後にある。月あたり1,000件のアシスト会話が含まれ、それを超えると1件あたり0.30ドルの超過料金がかかり、意図にマッチしてからエスカレーションされた会話も同様に課金される。Rovoクレジットは、Standardでユーザー1人あたり月25、Premiumで70、Enterpriseで150という具合に動く。

ここでのコストは過小評価されやすい。JSM自体の料金は、1〜15人の階層でStandardのエージェント1人あたり25ドルから始まり、リクエスト送信者は無料だが、そのすべてはAIをそもそも有効化するために必要なRovoの階層の手前にある。OpenAI側では、ChatGPTの料金が、チームの誰が何かを構築できるかの下限を決めている。

内蔵のAIがうまくいかないなら、次の行き先は代替案のまとめ、それからFreshserviceとの比較だ。

Jiraそのものを見直しているチームは、たいていJiraの代替案のリストから始める。今年何が変わったかは、JSMのAIを再検証する記事で扱っている。

Jira Service Management向けeeselを試す

上記のすべては、チャットクライアントをサービスデスクに向けるものだ。eesel AIは逆方向に動き、あなたのサービスデスクにエージェントとして加わる。30分未満でJira Service Managementに接続し、過去のリクエスト、あなたのConfluence、あなたのリクエストタイプを自動的に読み込む。その後、返信を下書きし、内部メモを追加し、優先度を設定し、フィールドを更新し、人間のエージェントがするようにチームへルーティングする。ウィジェットは不要。別の受信トレイも不要、そしてあなたが保守しなければならないOpenAPIスキーマも不要だ。

これまで見てきたことを踏まえると、私が指摘したい差別化要因は事前のドライランだ。AIエージェントを、実際のリクエストに触れる前に過去のJSMリクエストに対して実行し、テーマ別のカバレッジを確認し、ギャップを見つけ、数字が納得できるものになってから初めて開始できる。ドラフトモードで始まるため、人間がすべての返信を承認し、準備ができたら簡単なリクエストタイプについてはオートパイロットに切り替える。

InDebtedのHead of ITであるJason Loyola氏は、その形を端的に言い表した。"We use it to be the first responder to our Helpdesk tickets in Jira. It essentially acts just like an agent would." InDebtedの事例によれば、彼のチームは社内ITデスクで15%の解決率(デフレクション)に達しており、55%を目標にしている。料金は使用量ベースで、処理したチケット1件あたり40セント、シート単位の料金なし、さらに50ドル分の無料利用枠があり、決める前に自分たちのリクエストで試すことができる。

まず全体像を見たいなら、チケットトリアージの比較がその分野をカバーしており、Jira向けAIアドオンのまとめも同様だ。そしてツールよりもクライアントを比較検討しているなら、この記事のClaude版が同じ4つのツールグループを反対側から扱っており、そこでは認証の話が異なる形で落ち着く。