🌟

Claude Code + MCPサーバーでJIRAの一次対応と棚卸しを自動化した話

に公開

はじめに

生成AIを業務に導入する際、多くの方がまず「とにかくAIツールを触ってみよう」と考えるのではないでしょうか。しかし実際には、この進め方ではなかなか期待した効果が得られないケースが多いのです。

私たちのチームでは、JIRAのチケット対応業務に生成AIを活用する検証を進めてきました。その過程で学んだ重要な教訓は、AIを導入する前に人間側がしっかり準備を行う必要があるということです。

詳細については以下のブログで述べています。
https://zenn.dev/mixi/articles/28c9ec7a5ed00f

AIよりも先に、業務そのものを見直す

生成AIで期待した効果が出ない最大の原因は、導入前の準備不足にあります。私たちが重視したのは、以下の2つのステップです。

1. 現状のワークフロー分析と可視化

既存の業務プロセスを詳細に分析し、可視化することから始めました。どこにボトルネックがあり、どの部分がAI化に適しているかを明確にする必要があります。業務の流れを整理せずにAIを導入しても、既存の非効率な部分をそのまま自動化してしまうだけで、真の効率化にはつながりません。

2. データの整備とAI-Ready化

AIが適切に機能するためには、データが整理され、アクセス可能な状態になっている必要があります。構造化され、アクセス可能なデータが不可欠です。単にAIツールを導入するだけでなく、AIが利用できる形でデータを準備することが重要です。

対象業務の現状分析

私たちが効率化の対象としたのは、JIRAで管理している社内のAIツール利用相談窓口です。起票されるチケットの内容を分析したところ、以下のことが明らかになりました。

  • 約8割:各種AIツールやサービスの利用相談で法務確認チケットを起票する定型対応
  • 約2割:報告者にヒアリングを行って個別に対応方針を決定する必要がある相談

定型対応フローの整理

定型対応のフローを図式化すると、以下のような流れになっていました。

  1. チケットの種別を判定
  2. 必要事項の記載有無を確認
  3. 未記載の場合→記載を依頼
  4. 記載済みの場合→法務確認チケットを起票

この定型処理が全体の8割を占めており、ここを自動化できれば大幅な効率化が期待できることがわかりました。

もう一つの課題:チケットの棚卸し

また、長期間更新されずに滞留するチケットの棚卸し作業も定期的に発生していました。最終更新日時を確認し、リンクされている他部門のチケットを確認し、報告者に状況を確認するという作業です。これも効率化の余地がある業務として特定しました。

このように業務を可視化することで、AIを組み込むべきポイントが明確になりました。

検証プロセス:複数アプローチの評価

準備が整ったところで、いよいよAIツールの検証に入ります。私たちは3つの異なるアプローチを評価しました。

アプローチ1:Google Agentspaceの検証

最初に検証したのは、Google AgentspaceとJIRAの連携でした。社内で「生成AI × JIRA連携」といえば、まず想起されるのがAgentspaceです。

メリット:

  • 社内の各種データソースと既に連携済み
  • 初期コストをかけずに検証を開始できる
  • ノーコードでカスタムエージェントを作成可能

検証結果:

実際にJIRA連携を設定してチケット検索を行ったところ、基本的な検索や詳細表示は問題なく動作しました。しかし、実運用を想定すると3つの課題が見えてきました。

  1. 同期のタイムラグ:JIRAからAgentspaceへのデータ同期が定期的に行われるため、最新情報の反映に遅延が発生
  2. 現時点での制約:検証時点では、コメント情報が正しく取得できず「コメントはありません」と誤った回答が提示される
  3. 双方向性の欠如:AgentspaceからJIRAへのコメント投稿ができない

同期遅延については要件次第で許容できる可能性がありましたが、コメントの読み書きができないことは双方向運用の大きな阻害要因となります。リアルタイム性と双方向性を要する今回の用途には不適と判断しました。

また、検証時点では自作カスタムエージェントを他ユーザーへ共有する機能が確認できておらず、チーム横展開の観点でも課題がありました。

アプローチ2:Claude WebアプリのAtlassianコネクタ

次に検証したのは、Claude Webアプリケーションにデフォルトでコネクタが用意されているAtlassianとの連携です。

メリット:

  • 視覚的にわかりやすい
  • プロンプトやエージェント設定をプロジェクト機能で共有可能

制約:

プロジェクト機能を利用してプロンプトなどを共有する場合、Team/Enterpriseプランの契約が必要でした。検証期間中はこれらのプランを契約していなかったため、この方法は見送ることになりました。

適用シーン:

より実践的に活用する予定があり、かつ視覚的にわかりやすいツールが必要な非エンジニアチーム向けの場合は、このプランを契約して進めるのが最も手っ取り早い選択肢だと考えています。

アプローチ3:Claude Code + MCPサーバー(採用)

今回は開発部門での検証であり、利用ユーザーの想定もエンジニアであったため、Claude WebアプリではなくMCPサーバーを簡単に利用可能なClaude Codeを用いて検証を進めることにしました。

メリット:

  • JIRAとの双方向連携が可能
  • プロンプトやテンプレートをGitで管理できる
  • バージョン管理とチーム共有が容易
  • CLIベースでエンジニアチームに適している
  • リアルタイムでの情報取得・更新が可能

決定理由:

MCPサーバーを使うことで、Agentspaceで課題となった双方向性とリアルタイム性の問題を解決できました。また、プロンプトやテンプレートをコードと同様にGitで管理できるため、継続的な改善とチーム共有が容易という点も決め手となりました。

アプローチ比較(要約)

観点 Google Agentspace Claude Webアプリ Claude Code+MCP(採用)
導入コスト 低(既存連携が活用可) 中(プロジェクト共有は有料プラン) 低〜中(CLI で迅速に開始)
リアルタイム性 △(同期タイムラグ) ○(都度呼び出し) ○(都度呼び出し)
双方向(読み/書き) ×〜△(制約あり) ○(読み書き可能) ○(読み書き可能)
共有・運用 △(共有方法に制約) ○(プロジェクト共有) ○(Git でプロンプト/テンプレ管理)
想定読者 ノーコード中心 非エンジニア含む エンジニア中心(CLI 親和性)

採用の決め手(要約)

  • リアルタイム性/双方向性:一次対応の自動投稿や棚卸し通知の一括投稿が要件どおり。
  • チーム運用:プロンプトやテンプレートを Git でレビュー・履歴管理。
  • 再現性:CLI/MCP で環境差分を抑え横展開しやすい。

実装:Claude Code + MCPサーバー

セットアップ

MCPサーバーの追加は非常にシンプルで、以下のコマンド一つで完了します。

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

このコマンド実行後、Claude Codeを起動して認証を済ませれば、すぐに利用を開始できます。

実装した機能

1. チケットの一次対応自動化

起票されたチケットを定型対応と個別対応の2つに自動分類します。

定型対応の場合:

  1. チケットの内容を分析して必要な情報が記載されているかを確認
  2. 記載済み→法務確認チケットを自動起票
  3. 未記載→報告者に必要情報の記載を依頼するコメントを自動投稿

個別対応の場合:

  • 詳細を確認した上で報告者に詳細ヒアリングを促すコメントを作成・投稿
  • チケット内容を把握した上で、適切なヒアリング項目を提案できるため、対応の質も向上
一次対応のサンプル例
⏺ 一次対応:ステータスが「未着手」のチケット

  親プロジェクトキー「ABCD」でステータスが「未着手」のチケットは 2件 見つかりました。

  ---
  📋 定型対応(1)

  1. Claude Code利用相談

  - 報告者: 田中 一郎
  - 担当者: 佐藤 二郎
  - 作成日: 2025-09-30
  - 内容: プロダクト開発でClaude Codeを活用したい
  - 分類理由: Claude Codeという明確なツールの利用相談

  ---
  🔍 個別対応(1)

  1. 生成AIを利用した業務効率化の相談

  - 報告者: 鈴木 三郎
  - 担当者: 山田 四郎
  - 作成日: 2025-09-29
  - 内容: バックオフィス業務における生成AI活用の可能性の議論を行いたい。
  - 分類理由: 利用したいツールが明確でなく、要件ヒアリングや技術検討が必要

  ---

⏺ どのチケットから対応しますか?それとも特定のチケットについて詳細を確認しますか?

2. チケット棚卸しの自動化

一定期間(例:2ヶ月以上)更新のないチケットを自動で検出し、報告者に状況確認を促すコメントを一括投稿します。

処理フロー:

  1. 長期滞留チケットの自動検出
  2. テンプレートを参照してチケットの状況確認コメントを作成
  3. 該当する全てのチケットに対して一括投稿

これまで手作業で行っていた棚卸し作業がほぼ自動化されました。

棚卸しのサンプル例
⏺ 棚卸し対象チケット一覧(1-10件目)

  2か月以上更新がないチケットを10件取得しました:

  | No | チケット    | 要約          | ステータス | 最終更新       | 報告者   | 担当者   |
| -- | ------- | ----------- | ----- | ---------- | ----- | ----- |
| 1  | TKT-001 | 【仮要約】テスト案件A | 作業中   | 2024-08-29 | 山田 太郎 | 佐藤 花子 |
| 2  | TKT-002 | 【仮要約】テスト案件B | 確認中   | 2024-09-27 | 鈴木 次郎 | 未割当   |
| 3  | TKT-003 | 【仮要約】テスト案件C | 確認中   | 2024-10-22 | 佐藤 花子 | 山田 太郎 |
| 4  | TKT-004 | 【仮要約】テスト案件D | 確認中   | 2025-02-14 | 高橋 花子 | 鈴木 次郎 |
| 5  | TKT-005 | 【仮要約】テスト案件E | 確認中   | 2025-02-14 | 田中 一郎 | 山田 太郎 |
| 6  | TKT-006 | 【仮要約】テスト案件F | 確認中   | 2025-04-02 | 山本 二郎 | 佐藤 花子 |
| 7  | TKT-007 | 【仮要約】テスト案件G | 確認中   | 2025-04-03 | 小林 三郎 | 鈴木 次郎 |
| 8  | TKT-008 | 【仮要約】テスト案件H | 確認中   | 2025-04-03 | 鈴木 一郎 | 高橋 花子 |
| 9  | TKT-009 | 【仮要約】テスト案件I | 確認中   | 2025-04-03 | 渡辺 四郎 | 松本 久美 |
| 10 | TKT-010 | 【仮要約】テスト案件J | 確認中   | 2025-04-08 | 加藤 二郎 | 小林 五郎 |


  次のステップについて
  これらのチケットに対して、以下のいずれかの方法で対応を進めることができます:

  1. 個別に詳細確認してから対応 - 各チケットの詳細(コメント、関連チケット等)を確認してから個別に対応
  2. 一括で確認コメントを投稿 - テンプレートを使用して全チケットに状況確認コメントを一括投稿し、担当者を報告者に変更

  どちらの方法で進めますか?

実装のポイント:Gitによる一元管理

全ての設定、システムプロンプト、利用する各種テンプレートをGitリポジトリで一元管理することにしました。

Gitによる管理のメリット:

  • バージョン管理による変更履歴の追跡
  • チームメンバー間での設定共有
  • プロンプトの継続的な改善とレビュープロセス
  • 他部門への横展開が容易

また、AIに任せる部分と人間が判断する部分を明確に分けました。定型的な情報確認や標準的なコメント投稿はAIに任せつつ、最終的な判断は必ず人間が行う設計としています。

テンプレートを充実させることで、AIの回答品質を安定させることができました。特定のケースに対する対応方針や、コメントの文面例を事前に用意することで、一貫性のある対応が可能になります。

成果と効果

今回の取り組みを通じて、以下の成果が得られました。

業務効率の向上

JIRA対応における一次対応の定型化とチケット棚卸しの自動化をClaude Code + MCPサーバーで実現できることが確認できました。従来は手作業に頼っていた初動や棚卸しが効率化され、担当者がより付加価値の高い業務に注力できるようになりました。

対応品質の向上

  • 対応漏れや遅延の防止:JIRA上のコメントや起票を自動化できるため、人為的なミスを削減
  • 一貫性のある対応:テンプレートベースの対応により、対応品質のバラつきを抑制
  • 適切なヒアリング:個別対応でも、チケット内容を分析した上で適切な質問を提案

ナレッジ共有の促進

テンプレートやプロンプトをGitで一元管理することで、再利用性とナレッジ共有が促進されました。新しいメンバーが加わった際も、既存のナレッジをすぐに活用できます。

技術的な学び

  • MCPサーバーの有効性:エンタープライズツールとAIエージェントのシームレスな連携が実現可能
  • 比較検証の重要性:複数のアプローチを比較することで要件に最適なソリューションを選択
  • IaCのアプローチ:Git管理によるインフラストラクチャ・アズ・コードのアプローチがAI活用においても有効

他部門への展開可能性

今回構築した仕組みは、エンジニアリング業務に限定されません。繰り返し発生するタスクがある部門であれば、同様のアプローチで効率化が期待できます。

展開例

  • プロジェクトマネージャー:進捗管理やステータス更新の自動化
  • カスタマーサポート:問い合わせ対応の初動対応や定型回答の自動化
  • 営業チーム:案件管理や定期フォローアップの自動化
  • 人事部門:社内問い合わせ対応や手続き案内の自動化

小さな効率化の積み重ねが、組織全体の生産性向上につながります。

まとめ

生成AIを業務に導入して真の効果を得るためには、「まずAIツールありき」ではなく、業務プロセスの可視化と整理が先決です。

成功の3つのポイント

  1. 現状分析から始める

    • 業務フローを可視化し、ボトルネックとAI化に適した部分を特定
    • データを整備し、AIが活用できる状態(AI-Ready)にする
    • この準備なくしてAI導入しても、非効率な業務を自動化するだけに終わる
  2. 複数のアプローチを比較検証する

    • 要件に応じて最適なツールは異なる
    • 今回の場合:リアルタイム性・双方向性・エンジニアチームという条件でClaude Code + MCPを選択
    • ノーコード中心ならGoogle Agentspace、非エンジニアチームならClaude Webアプリという選択肢もある
  3. 継続的に改善できる仕組みを作る

    • プロンプトやテンプレートをGitで管理することで、バージョン管理とチーム共有を実現
    • AIに任せる部分と人間が判断する部分を明確に分離
    • 小さく始めて段階的に拡張していくアプローチが重要

今回の取り組みで得られた成果

  • JIRA対応業務の8割を占める定型処理の自動化を実現
  • 一次対応とチケット棚卸し作業の効率化により、担当者がより付加価値の高い業務に集中可能に
  • テンプレートベースの対応により、対応品質の一貫性が向上
  • Git管理によるナレッジ共有の仕組みが確立され、他部門への横展開の基盤が整備

これから生成AIを導入する方へ

生成AIの活用は、単なるツールの導入ではなく、業務プロセス全体を見直す絶好の機会です。以下のステップで進めることをお勧めします。

  1. まず立ち止まる: AIツールを触る前に、現在の業務プロセスを徹底的に分析する
  2. 小さく始める: 全体の8割を占める定型業務など、効果が見込めるところから着手
  3. 比較検証する: 複数のアプローチを試し、要件に最も合ったものを選択
  4. 継続的に改善する: Git管理などの仕組みで、プロンプトやテンプレートを進化させ続ける

既存業務の一部を置き換える部分的な導入ではなく、AI前提で業務プロセス全体を再設計する全面的なアプローチが、組織にとって真の価値を生み出します。

ぜひ、皆さんの業務でも「AIに任せられる定型処理」を見つけて、効率化にチャレンジしてみてください。小さな一歩から始めることで、組織全体の生産性向上につながるはずです。

MIXI DEVELOPERS Tech Blog

Discussion