Atlassian MCPとは｜公式Rovo MCP Serverの使い方・認証方式で変わる対応製品を解説

Atlassian MCP——正式名称 Atlassian Rovo MCP Server は、Jira・Confluence・Jira Service Management・Bitbucket Cloud・Compass を、Claude や Cursor などのAIツールから直接読み書きさせるための公式の接続口です。GitHubリポジトリ atlassian/atlassian-mcp-server は2026-07-29時点でスター914・Apache-2.0。ただしこのリポジトリを git clone してもサーバーは起動しません。サーバー本体はAtlassianのクラウドにしか存在せず、リポジトリに入っているのはドキュメントとスキルとマニフェストだけだからです。その代わりにこの構造は、「認証方式の選択が、触れる製品そのものを決める」という他のMCPサーバーではあまり見ない挙動を生みます。本記事は公式リポジトリと公式サポートドキュメントの記述だけを根拠に、その仕組みと設定手順を整理します。

MCPというプロトコル自体の全体像から押さえたい方は、まず MCPサーバーの作り方2026年完全ガイド：TypeScript・Python両対応チュートリアル を参照してください。本記事はその応用として「ベンダーがホストを握っているMCPサーバーを、どう設定しどこまで権限を渡すか」に絞って扱います。

Atlassian MCPとは——Rovo MCP Serverが繋ぐ5製品

公式READMEは、Atlassian Rovo MCP Server を「AtlassianクラウドサイトとMCP互換の外部ツールの間に立つクラウドベースのブリッジ」と定義しています。設定を済ませると、外部ツールが Jira・Confluence・Jira Service Management・Bitbucket・Compass のデータをリアルタイムに操作できるようになります。

用語について1点補足しておきます。検索では「Jira MCP」「Confluence MCP」という呼び方も見かけますが、公式には製品ごとに別々のサーバーが存在するわけではありません。Atlassian MCP サーバーは1本で、Jiraのツール群もConfluenceのツール群も同じエンドポイントから提供されます。製品ごとに分かれているのはサーバーではなく、後述する権限グループ（read_jira / write_confluence など）です。

READMEが挙げるできることは3つに集約されています。

・要約と検索：Jira・Confluence・Jira Service Management・Bitbucket のコンテンツを、ツールを切り替えずに横断して探し、要約する
・作成と更新：自然言語の指示から課題やページを起票・編集する
・反復作業の自動化：議事録や仕様書からチケットを生成するような、定型の手作業を代行させる

ここで押さえるべきは、MCPがAtlassian APIの能力を拡張しているわけではないという点です。認証はOAuth 2.1またはAPIトークンで行われ、READMEは「すべての操作はユーザーの既存のアクセス制御を尊重する」と明記しています。閲覧できるのは、その人がブラウザでログインしても見られるデータだけです。MCPが足しているのは、モデルが選択できる形式のツール定義と、権限グループという単位の認可境界、そしてMCP対応ホストなら同じ手順で繋がるという接続の標準化です。

対応クライアントは7種類が明記されている

READMEには対応クライアントの表があり、OpenAI ChatGPT、Claude（claude.ai・デスクトップ・Claude Code）、Cursor、Visual Studio Code（GitHub Copilot）、GitHub Copilot CLI、Google Gemini CLI、Amazon Quick Suite の7つが並んでいます。加えて「localhost で動作し mcp-remote プロキシ経由で接続できるローカルMCP互換クライアント」もサポート対象と書かれており、独自実装や第三者製の統合もここに含まれます。

つまり「セルフホストできない」ことと「ローカルのクライアントから使えない」ことは別問題です。サーバーはAtlassianのクラウドに固定されるが、クライアント側はローカルでもよい——この区別を最初に押さえておくと、後述の設定手順が理解しやすくなります。

何を置き換え、何を置き換えないのか

Rovo MCP Server が消すのは、「AIにAtlassianの文脈を渡すための人間の作業」です。Jiraの課題をブラウザで開いてコピーし、Confluenceのページをテキストに落として貼り付ける——この往復が不要になります。

一方で置き換わらないものもはっきりしています。Jiraの自動化ルールやWebhookのようなイベント駆動の仕組み、REST APIを直接叩くバッチ処理、既存のAtlassian Marketplaceアプリは、MCPの守備範囲ではありません。MCPが担うのは対話の中でその都度発生する読み書きであり、無人で回り続ける自動化とは層が違います。

なおベンダー自身が自社データのMCPサーバーを公式提供する動きは、Atlassianに限りません。デザイン領域の代表例が Figma MCP使い方｜Dev ModeのデザインをClaude/Cursorにコード化させる で、いずれも「ベンダーがツール定義の仕様を握る」という同じ構図です。この構図は追随の速さと引き換えに、利用者側が仕様変更に対して受け身になるという性質を伴います。

GitHubリポジトリにサーバー本体は入っていない

atlassian/atlassian-mcp-server を初めて開くと、ファイル数の少なさに戸惑います。リポジトリサイズは154KB、GitHubが判定する主要言語はJavaScriptですが、.mjs ファイルは scripts/validate-template.mjs の1本だけ——これはIssueテンプレートの検証スクリプトであって、MCPサーバーの実装ではありません。

SECURITY.mdが構造をそのまま書いている

推測する必要はありません。リポジトリの SECURITY.md に「このリポジトリはAtlassian Rovo MCP Serverの公開部分——ドキュメント、クライアントマニフェスト（.mcp.json とClaude・Cursor・Geminiのプラグインマニフェスト）、MCPレジストリのエントリ（server.json）、そしてスキル——を保持する」と明記されています。さらに「サーバー自体は mcp.atlassian.com 上のホストされたサービス」であり、「Atlassianがホストされたサーバーを保守・更新するので、あなたの側でパッチを当てるものは何もない」と続きます。

この一文は運用上の含意が大きく、脆弱性報告の宛先も分岐します。同じ SECURITY.md は、ホストされたサービス・認証・Atlassian製品の問題は公開Issueではなく Atlassian の脆弱性報告プロセスへ、と誘導しています。

バージョンはGitHub Releasesではなく server.json にある

GitHub APIで確認すると、このリポジトリの Releases は0件、タグも0件です。ではバージョンはどこにあるのか——server.json の version フィールドです。

{
  "$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json",
  "name": "com.atlassian/atlassian-mcp-server",
  "title": "Atlassian Rovo MCP Server",
  "version": "1.1.3",
  "remotes": [
    { "type": "streamable-http", "url": "https://mcp.atlassian.com/v1/mcp" },
    { "type": "streamable-http", "url": "https://mcp.atlassian.com/v1/mcp/authv2" }
  ]
}

このファイルはMCPレジストリへの登録エントリで、コミットメッセージにも「Add server.json as source of truth for the MCP Registry entry」（2026-06-17）と残っています。リポジトリのリリース履歴を追ってもサーバーの更新は分かりません。ホスト側が更新されれば、利用者は何もしなくても新しい挙動になる——これはセルフホスト型MCPサーバーとの決定的な運用差です。

配布されているのはクライアント向けマニフェスト

リポジトリのもう一つの役割が、各AIクライアント用の設定ファイルの配布です。中身は素直で、.mcp.json は次の6行だけです。

{
  "mcpServers": {
    "atlassian": {
      "type": "http",
      "url": "https://mcp.atlassian.com/v1/mcp/authv2"
    }
  }
}

これに .claude-plugin/plugin.json（mcpServers に上記を、skills に ./skills/ を指す）、.cursor-plugin/plugin.json、gemini-extension.json が並びます。Claude Code向けには .claude-plugin/marketplace.json も用意されており、プラグインマーケットプレイスとして参照できる形になっています。つまりこのリポジトリは、サーバーのソースではなく「接続情報とスキルのパッケージ」として設計されています。

コミット履歴を見ると初期コミットは2025-08-04、以降の総コミット数は108件で、上位コントリビューターは lsosa1（32件）と jatinkrmalik（31件）です。直近の変更もドキュメントとマニフェストの整備に集中しており、リポジトリの性格と一致しています。

Atlassian MCPの設定手順——Claude Code・Cursor・VS Codeへの接続

セルフホストが無い分、導入はシンプルです。READMEはワンクリック設置のリンク（Cursor・VS Code・ChatGPT・Claude）を用意していますが、設定ファイルを直接書く場合の要点を押さえておくと、トラブル時に切り分けやすくなります。

前提条件

READMEは接続方法ごとに前提条件を分けています。

・対応クライアントから使う場合：Jira・Confluence・Jira Service Management・Bitbucket・Compass のいずれかを含むAtlassian Cloudサイト、対象クライアントへのアクセス、OAuth 2.1認可フローを完了できるモダンブラウザ（またはヘッドレス認証用のAPIトークン）
・IDEやローカルクライアントから使う場合：上記に加えて、ローカルMCPプロキシ mcp-remote を動かすためのNode.js v18以上

つまりCloud版のAtlassianが前提で、Data Center／Server版は対象外です。この点は導入前に確認しておく必要があります。

エンドポイントは3種類あるが、選ぶのは1つ

接続先URLは公式に3種類が登場します。混同しやすいので整理します。

SSEエンドポイントは、2026-07-07のコミット「chore: remove SSE remote endpoint from server.json」でレジストリ登録からは外されました。READMEでは引き続き「サポートされている」と書かれているものの、カスタムクライアントを /sse に向けたまま運用している場合は移行を検討する段階と読めます。

Claude Code・VS Code・Cursorの設定

Claude Code でプロジェクトに追加する場合は、リポジトリ同梱の .mcp.json をそのまま流用できます。プロジェクトルートに次の内容で .mcp.json を置きます。

{
  "mcpServers": {
    "atlassian": {
      "type": "http",
      "url": "https://mcp.atlassian.com/v1/mcp/authv2"
    }
  }
}

初回接続時にブラウザが開き、OAuth 2.1（3LO）の同意画面が表示されます。同意すると認可が完了し、以降はツールが利用可能になります。VS Code（GitHub Copilot）は同じURLを type: "http" として登録し、Cursor は url のみを与える形式です。README のワンクリックリンクは、いずれもこのJSONをBase64で埋め込んだものになっています。

mcp-remote プロキシ経由で繋ぐローカルクライアントの場合は、コマンド側で同じURLを指定します。

# Node.js v18 以上が必要
npx -y mcp-remote https://mcp.atlassian.com/v1/mcp/authv2

初回に必ず呼ばれるツールがある

公式ドキュメントは共有プラットフォームツールの getAccessibleAtlassianResources について、「すべてのツール呼び出しが cloudId を必要とするため、あらゆるツールにとって必須の最初の呼び出し」と説明しています。つまり接続直後の1往復は、必ずサイト一覧の取得に費やされます。

READMEはこのオーバーヘッドを減らす手として、AGENTS.md に既定値を書いておく方法を挙げています。プロジェクト側で cloudId・Jiraのプロジェクトキー・Confluenceの spaceId・検索の maxResults を固定しておけば、探索のためのツール呼び出しを省けます。トークン消費の観点からMCPの往復を削る発想は、Serena MCPの使い方｜セマンティック解析でClaude Codeのトークンを削る が扱う問題意識と同じ方向を向いています。

認証方式で使える製品が変わる——対応ツール55件の内訳

ここが Atlassian MCP でもっとも誤解されやすい部分です。多くのMCPサーバーでは、認証方式は「どう繋ぐか」の違いにすぎません。しかしRovo MCP Serverでは、認証方式が「どの製品に届くか」を決めます。

製品 × 認証方式のマトリクス

公式の「Supported tools」ページは、権限グループごとに「Available using」として利用可能な認証方式を明記しています。それを製品単位でまとめると次のようになります。

この表から読み取れる帰結は明快です。Bitbucket Cloud と Compass は、1つの接続で同時に扱えません。Bitbucketに届くのはAPIトークン認証だけ、Compassに届くのはOAuth 2.1だけだからです。「Jiraが動いたから全製品いけるはず」と考えて設定すると、Bitbucketのプルリクエストを取りに行く段階で初めて詰まります。

APIトークンは管理者の許可が前提

APIトークン認証はヘッドレス用途——バックエンドや自動化のような非対話型の構成——のために用意されていますが、勝手には使えません。READMEは3つの条件を並べています。

・管理者による有効化：組織管理者が Atlassian Administration → Rovo → Rovo MCP server → Authentication でAPIトークン認証を有効にする必要がある
・スコープ付きトークン：必要なツールとデータに対応するスコープを持つ個人APIトークンを作成する
・Bitbucketの追加条件：公式ドキュメントは、Bitbucketツールについて「スコープ付きAPIトークンによる認証が管理者に有効化されており、かつBitbucketワークスペースが組織にリンクされている場合にのみ利用可能」と記載している

ここで実務的な注意点があります。個人でAPIトークンを発行しても、組織側で有効化されていなければ Jira Service Management も Bitbucket も見えません。ツール一覧に出てこない場合、まず疑うべきはトークンのスコープではなく組織設定です。

スコープは製品ごとに細かく分かれている

公式ドキュメントは各ツールに「Required scopes」を併記しています。Jiraは read:jira-work / write:jira-work / search:jira-work と粗い粒度ですが、Confluenceは read:page:confluence・read:comment:confluence・read:space:confluence・read:hierarchical-content:confluence のようにリソース単位に分かれています。

とくに注意したいのが Bitbucket の書き込み系です。bitbucketEnvironment の書き込み（create / delete / update）に必要なスコープは admin:pipeline:bitbucket で、他の書き込みツールが write:* で済むのに対し管理者相当のスコープを要求します。デプロイ環境の作成・削除をAIに任せる構成は、トークンの権限設計として一段重い判断になります。

ツールは55件——権限グループとBitbucketだけ違う設計

公式ドキュメントはツールの総数を明示していません。そこで2026-07-29時点の「Supported tools」ページに掲載されているツールを数えると、重複名を除いて55件、権限グループへの登録エントリとしては59件になります。以下は当サイトによる集計です。

製品別の内訳

Jiraの読み取り側は getJiraIssue・getVisibleJiraProjects・getTransitionsForJiraIssue・lookupJiraAccountId など8件、書き込み側は createJiraIssue・editJiraIssue・addCommentToJiraIssue・transitionJiraIssue・addWorklogToJiraIssue の5件。検索は searchJiraIssuesUsingJql 1件のみで、JQLをそのまま投げる設計です。Confluenceも同様に、検索は searchConfluenceUsingCql の1件でCQLを受け取ります。

Bitbucketだけツールの粒度が違う

内訳表で「名前は read と重複」と注記した箇所が、このサーバーの設計上もっとも特徴的な部分です。Jira・Confluence・Compassは1操作＝1ツール（createConfluencePage と updateConfluencePage は別ツール）ですが、Bitbucketは1リソース＝1ツール＋アクション引数という形を取っています。

・bitbucketPullRequest は read_bitbucket グループでは list / get / comments / diff、write_bitbucket グループでは create / merge / approve / comment のアクションを持つ
・bitbucketRepoContent は読み取りで branch.get / commit.get / files.get、書き込みで branch.create / commit.create
・bitbucketPipeline は読み取りで list / get / steps / step.get / step.log、書き込みで run
・bitbucketEnvironment は読み取りで list / get、書き込みで create / delete / update

同じツール名が読み取りグループと書き込みグループの両方に現れ、実行できるアクションだけが変わる構造です。ツール定義の数を抑えられる一方、モデルに見えるツール名からは「これが書き込み系かどうか」が判別しづらいという副作用があります。権限グループで write_bitbucket を外していない限り、bitbucketPullRequest はマージまで実行しうるツールだという前提で扱うべきです。

Teamwork Graphは将来課金される予告つき

Atlassianプラットフォームの read_teamwork_graph グループには、getTeamworkGraphContext（Beta）・getTeamworkGraphObject（Beta）・addTeamworkGraphContext の3件があります。getTeamworkGraphContext は「単一エンティティのフィールドではなく、エンティティ間の接続が答えに必要なとき」に使うツールで、Jiraの課題・スプリント、Confluenceのページ・ホワイトボード、DevOpsのPR・リポジトリ・デプロイ、Loomの動画・ミーティング、Compassのコンポーネントまでを入口として横断できます。

このグループには2つ、見落とすとまずい注記が付いています。

後者は権限設計の観点で重要です。Limited access の場合、GitHub側で見えないはずのものが、Jira課題に紐づいていればMCP経由で読める可能性があるという説明になっています。逆に言えば、Jiraの権限がそのままDevOpsデータの露出範囲になるということです。

さらにもう1点、グループ名だけを見て判断すると取り違える箇所があります。read_teamwork_graph に含まれる3件目の addTeamworkGraphContext は、説明が「Teamwork Graph上の2つのオブジェクト間に関係を追加する」で、必要スコープも write:all:twg です。名前が read_ で始まるグループの中に、書き込みツールが1件入っているわけです。権限グループ単位で付与する運用では、グループ名を読み取り専用と信じて許可すると、意図せず書き込みまで渡すことになります。次節で見るとおりAtlassian側の絞り込み単位はこのグループなので、許可の判断はグループ名ではなく、各ツールの必要スコープ（read: か write: か）を確認したうえで行うのが確実です。

管理者側の統制——JITインストール・ドメイン制御・監査ログ

セルフホストできない代わりに、Atlassianは組織管理者向けの統制機能を用意しています。ここを理解しないまま導入すると、「なぜか自分だけ繋がらない」「誰が何をしたか分からない」という状態になります。

インストールはMarketplace経由ではない

READMEは「Marketplaceアプリではない」とはっきり書いています。Atlassian Marketplaceからも「アプリの管理」画面からもインストールできず、最初のユーザーがOAuth 2.1（3LO）の同意フローを完了した時点で自動的に登録される（ジャストインタイム、いわゆるlazy loadingインストール）方式です。

この方式には条件が付きます。サイトで最初に3LO同意を完了するユーザーは、MCPのスコープが要求するAtlassianアプリ（たとえばJiraやConfluence）へのアクセスを持っている必要があります。これが「MCPアプリが正しい権限でサイトに登録される」ことを保証しているためです。初回の登録が済んだ後は、1つのアプリにしかアクセスできないユーザーでも3LOを完了してそのアプリを使えます。

READMEのトラブルシューティングには「Your site admin must authorize this app」というエラーが挙がっており、これはサイト管理者が先に3LO同意を完了していないことを示します。導入初日に一般ユーザーから先に試すと、この壁に当たります。

4層の統制ポイント

管理者が握れるレバーは、大きく4つに分かれます。

・ドメイン制御：Atlassian Administration の「Rovo MCP server」設定ページで、接続を許可する外部AIツールとドメインを制御する。既定ではAtlassianがサポートするドメインが許可されており、信頼するドメインの追加やサポート済みドメインのブロックができる。この制御はOAuth 2.1接続に適用される
・認証方式の有効化：APIトークン認証を組織として有効にするかどうか。前述のとおり、これが Jira Service Management と Bitbucket Cloud への到達可否を直接決める
・権限グループ単位の許可：公式ドキュメントは「組織管理者が権限グループのレベルでアクセスを付与または取り消し、各ツールは親グループのアクセスを継承する」と明記している。個別ツール単位ではなくグループ単位である点が、CLIフラグで絞るタイプのMCPサーバーとの違い
・IP許可リスト：組織がAtlassian Cloud製品にIP許可リストを使っている場合、Rovo MCP Server経由のリクエストも該当アプリの許可リストで許されたIPから発信される必要がある

監査ログでツール呼び出しを追える

READMEは「Rovo MCP Server経由でツールが使われるたびに、組織の監査ログにイベントが記録される」と記載しています。確認場所は Atlassian Administration の Insights → Audit log で、Rovo MCP User Actions でフィルタするか MCP で検索します。

セルフホスト型のMCPサーバーでは、ツール呼び出しのログを残すかどうかは運用者の実装次第です。Rovo MCP Server の場合はホスト側が一律に記録するため、利用者が意図的にログを消すことはできない代わりに、記録の粒度もAtlassianの実装に委ねられます。統制の観点ではトレードオフのある構造です。

なお、ユーザー自身もプロフィール設定から自分のアプリ認可を取り消せます。管理者側は「Connected apps」一覧からMCPアプリのアクセスを管理・レビュー・剥奪できます。

プロンプトインジェクションへの言及

READMEの Security セクションは、この種のサーバー特有のリスクにも触れています。LLMがプロンプトインジェクションや間接プロンプトインジェクション、ツールポイズニング攻撃に対して脆弱であり、「明示的に依頼していないのにデータを持ち出したり、意図しない変更を加えたりするようエージェントに指示しうる」と明記されています。

対策として挙げられているのは、信頼できるMCPクライアント／サーバーのみを使うこと、各エージェントがアクセスできるツールとデータを精査すること、最小権限（スコープ付きトークン・最小のプロジェクト／ワークスペースアクセス）を適用すること、高影響・破壊的な操作には人間の確認を要求すること、そして異常な活動がないか監査ログを監視することです。MCPサーバーそのものの安全性については、Claude Codeを含むホスト側の設定も併せて点検する価値があります。

公式スキル6本と、GitHub公式MCPサーバーとの構造比較

このリポジトリのもう一つの見どころが skills/ ディレクトリです。MCPサーバーを提供するベンダーが、その使い方をAgent Skillの形で公式に同梱している例は多くありません。

6本のスキルが何を自動化するか

・spec-to-backlog：Confluenceの仕様書を読み、実装タスクに分解してJiraのEpicと子チケットを作る。SKILL.mdは「Epicを先に作ってキーを確保する」順序を必須と定め、逆順だと親のいない孤児チケットになると警告している
・triage-issue：バグ報告やエラーメッセージからキーワードを抽出し、Jiraで重複を検索してから新規起票するか既存にコメントするかを判断する
・generate-status-report：JQLでJira課題を集計してステータスレポートを作り、Confluenceに公開する。スコープ（期間・対象読者・公開先）の確認を必須とし「Confluenceへの公開を黙って省略しない」と明記している
・search-company-knowledge：Confluence・Jira・社内ドキュメントを並列に検索し、引用付きで回答を合成する
・capture-tasks-from-meeting-notes：議事録からアクションアイテムと担当者を抽出し、アカウントIDを引いてJiraタスクを作る
・jira-sprint-dashboard：Jiraのスプリント状況を可視化ダッシュボードとして描く。既定で読み取り専用と宣言されており、ユーザーが明示的に書き込みを求めるまで課題の作成・更新・遷移・アサイン・コメントを行わない

generate-status-report には scripts/jql_builder.py が同梱されており、JQL値のサニタイズ関数が実装されています。英数字・空白・ハイフン・アンダースコア・ドット・アットマークのみを許可する正規表現で検証し、条件を満たさなければ例外を投げ、ダブルクォートは二重化してエスケープする——という内容です。LLMが生成した文字列をそのままJQLに埋めないという設計判断が、スキル側のコードとして明示されている点は参考になります。

比較表：配布物・統制・更新の3点が違う

同じ「ベンダー公式のMCPサーバー」でも、Atlassianとの差は大きくあります。

スター数の差は人気の差というより、公開されているものの性質の差として読むのが妥当です。実装コードが公開されているリポジトリと、接続情報とドキュメントの配布リポジトリでは、スターが付く動機が違います。

ツールの絞り込みに関する思想の違いは、より実務的です。GitHub側の設計を詳しく知りたい場合は GitHub MCPとは｜公式MCPサーバーの使い方・86ツール・リモート/ローカル版と権限設計を解説 を参照してください。利用者が自分で絞るのがGitHub、管理者が組織として絞るのがAtlassian——同じ「公式MCPサーバー」でも、統制の主体が違います。

どういうチームに向くか

以上を踏まえると、向き・不向きははっきりします。

・向く：Atlassian Cloudを使っており、組織としてAI利用を統制したいチーム。監査ログとドメイン制御が最初から用意されているため、統制の仕組みを自作しなくてよい
・向く：Jira・Confluenceが情報の中心にあり、AIに文脈を渡すコピー＆ペーストを減らしたいチーム。同梱スキルがそのまま定型作業の雛形になる
・向かない：Data Center／Server版のAtlassianを運用しているチーム。前提条件がAtlassian Cloudサイトのため対象外
・向かない：MCPサーバーを自社ネットワーク内に閉じたいチーム。サーバー本体はAtlassianのクラウドにしか存在しない
・要検討：BitbucketとCompassの両方をAIから触りたいチーム。認証方式が排他のため、接続を分けるなどの設計が必要になる

なお「要検討」に挙げた排他の問題は、接続プロファイルを2つ用意して使い分ければ回避できます。OAuth 2.1で繋いだ接続と、APIトークンで繋いだ接続を別のMCPサーバー登録として並べる形です。ただしその場合、Jiraのように両対応の製品はツールが二重に見えることになるため、どちらの接続を主に使うかをAGENTS.mdなどで明示しておく必要があります。

まとめ——導入前に決めるべき3点

Atlassian Rovo MCP Server は、公式が提供するMCPサーバーの中でも「ホストをベンダーが完全に握る」タイプの代表例です。そのぶん導入は接続先URLを1本登録するだけで済みますが、代わりに次の3点が設定作業の中心になります。

1. 認証方式の選択——OAuth 2.1かAPIトークンかで、Jira Service Management・Bitbucket Cloud・Compass への到達可否が分岐する
2. 組織管理者の設定——APIトークン認証の有効化、ドメイン制御、権限グループの付与。個人のトークン設定だけでは解決しない
3. 統制の前提理解——JITインストール、監査ログ、IP許可リストがどう効くか。とくに初回の3LO同意はサイト管理者から行う

そして、リポジトリを見に行くときは「サーバーのコードを探さない」ことです。atlassian/atlassian-mcp-server にあるのはドキュメントとスキルとマニフェストであり、それは不足ではなく設計です。実装が非公開である以上、挙動の根拠は公式サポートドキュメントの記述に置くしかなく、本記事もその範囲で整理しました。仕様は今後も更新されるため、権限やツールの詳細は必ず公式の「Supported tools」で最新の記載を確認してください。

参照ソース

・atlassian/atlassian-mcp-server（GitHub 公式リポジトリ） — README・SECURITY.md・server.json・.mcp.json・各クライアントマニフェスト・skills/ 配下のSKILL.md。スター数・コミット数・Releases件数はGitHub APIの2026-07-29時点の実測値
・Supported tools（Atlassian サポートドキュメント） — 権限グループごとのツール一覧・必要スコープ・認証方式の対応、Teamwork Graphツールの課金予告とサードパーティデータの到達範囲
・Getting started with the Atlassian Remote MCP Server（Atlassian サポートドキュメント） — 対応クライアントとセットアップの正典
・Understand Atlassian Rovo MCP Server（Atlassian サポートドキュメント） — セキュリティモデルと管理者向けコントロールの概要