JiraやTrelloをAIで自動化する前に潰すべき3つの落とし穴

JiraやConfluence、TrelloといったAtlassian製品にAIエージェントを繋いで自動化したいと考えているチームに向けた内容です。MCP（Model Context Protocol、AIモデルと外部ツールを繋ぐための共通規格）経由でチケット管理を自動化する構成が広がっていますが、思ったより早い段階でつまずくケースがあります。何を確認しておけば事故を防げるか整理しました。

Atlassianの共同創業者兼CEOであるMike Cannon-Brookes氏は、The VergeのPodcast「Decoder」でAIが企業ソフトウェアをどう変えるかについて語っています。同氏はAIによって既存のSaaS（Software as a Service、月額課金で使うクラウドソフトウェア）が丸ごと不要になる、いわゆる「SaaSpocalypse（SaaS終焉論）」に懐疑的な立場を取りつつ、AIツールがAtlassianの各種ツール利用そのものを増やしているとも述べています。この「AIがツール利用を増やす」という現象は、実際の開発現場ではAIエージェントがJiraやConfluenceのデータに直接アクセスし、読み書きする構成が急増していることの裏返しでもあります。ここに落とし穴が潜んでいます。

何が起きるか

典型的な事故は次のようなものです。AIエージェントにJiraのMCPサーバーを繋ぎ、「このスプリントの未完了チケットを整理して」と指示したところ、意図しないチケットのステータスを一括変更してしまう、あるいは関係のないプロジェクトのIssueまで書き換えてしまう、というケースです。

AtlassianはIssue（課題・チケット）、Confluenceページ、権限管理がすべて単一の共通プラットフォーム上に乗っている構造を持っています。Cannon-Brookes氏も番組内で、Atlassianの各製品は実は一つのコアプラットフォームの異なる表現形にすぎないと説明しています。つまりJira、Confluence、Trelloは見た目こそ違いますが、内部的には同じ権限モデル・同じデータベース基盤を共有しています。

これが意味するのは、AIエージェントがJira用に与えられたAPIトークンで、実はConfluenceの編集権限も持っているケースがあるということです。スコープを絞ったつもりが、思ったより広い範囲に影響が及ぶ構造になっています。

なぜ起きるか

原因は大きく3段階に分解できます。

まず1段階目は、認証トークンのスコープ設計です。AtlassianのAPIトークンやOAuth 2.0（外部サービスへのアクセス権限を安全に委譲する認可の仕組み）のスコープは、プロジェクト単位ではなくサイト単位・製品単位で発行されることが多く、細かい権限分離が難しい構成になりがちです。

2段階目は、MCPサーバー側の実装です。MCPはAIモデルとツールの間で「何ができるか」を定義する仕組みですが、サーバー実装によっては書き込み系のツール（update_issue、delete_pageなど）が読み取り系と同列に並んでいて、AIが読み取りのつもりで書き込み系ツールを呼び出してしまう設計のものがあります。

3段階目は、プロンプト側の曖昧さです。「整理して」「片付けて」のような指示は、人間には自然でもAIエージェントには解釈の幅が広すぎます。エージェントが「整理」を「ステータス変更」や「クローズ」と解釈し、実行してしまう余地が生まれます。

自分のプロジェクトが該当するか確認する

以下の観点で、現状の構成を点検してみてください。

使っているAtlassian用MCPサーバーが公式提供か、コミュニティ製かをまず確認する（npm や pip のパッケージ名、GitHubのリポジトリ元を見る）
MCPサーバーの提供するツール一覧に、書き込み・削除系の関数（update、delete、transition、archiveなど）が含まれているかを確認する
発行しているAPIトークン・OAuthアプリのスコープ設定画面（Atlassian管理コンソールの「API tokens」「OAuth 2.0 (3LO) apps」）を開き、読み取り専用スコープになっているかを見る
AIエージェントに渡しているシステムプロンプトや指示文に、「変更前に確認を取る」「破壊的操作は実行しない」といった制約が明記されているかを見る
過去のJira監査ログ（Issue履歴の「Activity」タブや管理者向けの監査ログ機能）で、想定外のステータス変更がすでに起きていないかを遡って確認する

これらのうち1つでも「わからない」「未設定」がある場合は、対策を先に済ませてから自動化を広げる方が安全です。

対策の手順

対応は次の順番で進めると抜け漏れが少なくなります。

# 1. 現在のAPIトークン・OAuthアプリのスコープを棚卸しする
# Atlassian管理コンソール > セキュリティ > API tokens / OAuth 2.0 apps で一覧を確認

# 2. 読み取り専用のテスト用トークンを別途発行する
# スコープは read:jira-work / read:confluence-content のみに絞る

# 3. MCPサーバーをテスト用トークンで起動し、書き込み系ツールが
#    呼び出せないことを確認する（エラーになれば設計通り）

書き込み権限が本当に必要な場合は、対象プロジェクトを限定したサービスアカウントを別途作成し、本番の管理者アカウントとは分離しておく方法が現実的です。

さらにエージェント側の対策として、破壊的操作（削除・一括ステータス変更・クローズ）を実行する前に、必ず変更内容を人間に提示して承認を求めるステップをワークフローに組み込む方法があります。Claude CodeやCursorのようなAIコーディングツールでは、ツール呼び出し前に確認プロンプトを挟む設定や、特定のツール名を許可リストから除外する設定が用意されているものもあるため、使用しているツールの設定ドキュメントで「approval」「confirmation」「allowlist」といったキーワードを検索してみてください。

最後に、AtlassianのMCP連携をテストする際は、本番のJiraサイトではなく、サンドボックス用のインスタンスやテスト用プロジェクトで一度動作確認を挟むことをおすすめします。Atlassianはトライアル用のCloudサイトを無料で追加作成できるため、そこで一通りのシナリオ（Issue作成・更新・削除・ページ編集）を試してから本番接続に進む流れが安全です。

まとめ

AIエージェントとJira・Confluence・Trelloを繋ぐ構成は、Cannon-Brookes氏が語るようにツール利用そのものを増やす方向に働いていますが、その分だけ事故の起きる面積も広がっています。

まずはAPIトークンとOAuthアプリのスコープを棚卸しし、読み取り専用と書き込み可能な構成を分離してください。次にMCPサーバーの提供ツール一覧を確認し、書き込み系・削除系の関数が無条件で呼び出せる状態になっていないかを見てください。

そのうえで、破壊的操作の前に人間の承認を挟む設定を、使っているAIコーディングツールのドキュメントで確認してみてください。サンドボックス環境での事前検証を挟むだけでも、想定外の一括変更を未然に防げる可能性が高くなります。