Claude Code で JiraチケットからPRまでを完全自動化した話 〜考えないでコミット・PRできる世界〜

この記事は KINTOテクノロジーズ Advent Calendar 2025 の5日目の記事です🎅🎄

はじめに

KINTO開発部 FEチーム では、React/Next.jsを用いたフロントエンド開発を行っています。
開発タスクの管理にはJiraを使用しており、チケットベースでの開発フローを採用しています。

チーム規模が拡大する中で、「ブランチ名の命名規則」「コミットメッセージの形式」「PRテンプレートの選択」といった 開発フロー上の統一と認知コスト が課題と感じていました。

この記事では、Claude Code と Atlassian MCP を組み合わせることで、これらの「考えなくてもいいこと」を自動化し、開発者が本質的な問題解決に集中できる環境をどう構築したかを紹介します。

技術スタック

• Claude Code: AI駆動の開発アシスタント
• Atlassian MCP: Jira/ConfluenceとのAPI連携（チケット情報の自動取得）
• GitHub CLI (gh): PR操作の自動化
• CLAUDE.md: プロジェクト固有のルール定義

背景・課題：開発フローの「認知負荷」問題

開発者が本来集中すべきはコードの実装です。
しかし、実際の開発では以下のような 「本質的でない作業」 に認知リソースが奪われていました:

• 「このチケット番号なんだっけ？Jira開いて確認するか...」
• 「ブランチ名どうするんだっけ？feature/JIRAKEY-1234/の後は何を書けばいい？」
• 「このブランチ、developから切るんだっけ？プロジェクトブランチから切るんだっけ？」
• 「コミットメッセージの絵文字、:sparkles:と:wrench:どっちだっけ？」
• 「PRのタイトルは:m:付けるんだっけ？付けないんだっけ？」
• 「PRテンプレートどっち使うんだっけ？for_dev.md？デフォルト？」

これらは些細に見えますが、 1日に何度も発生する意思決定 です。積み重なると開発者の集中力を大きく削ぎます。

解決策：「考えない」開発フローの実現

「チケット番号を伝えるだけで、あとは全部自動化する」

これを実現するために、Claude Code と Atlassian MCP を組み合わせました。

開発者がやること

開発者: 「JIRAKEY-1234のブランチを作成して」

Claude Codeがやること（自動）

1. ✅ Jira APIでチケット情報を取得
2. ✅ エピック判定でプロジェクト所属を確認
3. ✅ 適切なブランチ名を自動生成（feature/JIRAKEY-1234/update_claude_docs）
4. ✅ 適切なベースブランチを自動判定（develop or プロジェクトブランチ）
5. ✅ ブランチ作成

開発者がやること

開発者: 「コミットして」

Claude Codeがやること（自動）

1. ✅ 変更内容を解析
2. ✅ 適切な絵文字ショートコードを選択（:pencil:, :bug:, :sparkles:など）
3. ✅ コミット実行

開発者がやること

開発者: 「PRを作成して」

Claude Codeがやること（自動）

1. ✅ ブランチ名からチケット番号を抽出
2. ✅ Jira APIでチケット件名を取得
3. ✅ PRタイトルを自動生成（JIRAKEY-1234: Claude Codeの運用ルールの標準化）
4. ✅ ベースブランチを自動判定（develop or プロジェクトブランチ）
5. ✅ 適切なPRテンプレートを自動選択
6. ✅ PR作成実行

開発者がやることは3つの指示を出すだけ。ブランチ作成、コミット実行、PR作成実行は、すべてClaude Codeが自動で行います。

実装方法：CLAUDE.mdという「AIが読むルールブック」

すべての自動化は CLAUDE.md というドキュメントに記述されたルールで実現されています。

### ブランチ命名規則
プロジェクトベースブランチ: `feature/プロジェクト名`
  - 例: `feature/simulation`
  - ベースブランチ: `develop`

機能ブランチ（プロジェクト配下）: `feature/JIRAKEY-チケット番号/説明`
  - 例: `feature/JIRAKEY-1234/add_simulation_list`
  - ベースブランチ: `feature/プロジェクト名`

通常の機能ブランチ（プロジェクト外）: `feature/JIRAKEY-チケット番号/説明`
  - 例: `feature/JIRAKEY-1234/fix_bug`
  - ベースブランチ: `develop`

親子チケットの場合:
  - 親ブランチ: `feature/JIRAKEY-親チケット番号/develop`
  - 子ブランチ: `feature/JIRAKEY-親チケット番号/JIRAKEY-子チケット番号/説明`

エピックとプロジェクトベースブランチの関係

- エピック判定: Jiraチケットの `parent.fields.issuetype.name` が「エピック」の場合、そのチケットはプロジェクトに属する
- 重要: エピック配下のタスクのブランチ作成時は、必ずユーザーにプロジェクトベースブランチ名を確認すること

### コミットメッセージフォーマット

- 必須形式: `:emoji: JIRAKEY-チケット番号: サブジェクト`
- 絵文字ショートコードは`.commit_template`を参照

- コミット例:
:bug: JIRAKEY-1234: ログイン時のクラッシュを修正
:sparkles: JIRAKEY-2345: ユーザープロフィール画像アップロード機能を追加
:robot: JIRAKEY-3456: ログインコンポーネントのテストを追加

### PR作成ルール

- タイトル形式:
  - プロジェクトベースブランチ → develop: `:m: JIRAKEY-チケット番号: チケット件名`
  - 親ブランチ → develop: `:m: JIRAKEY-親チケット番号: チケット件名`
  - 通常の機能ブランチ → develop: `JIRAKEY-チケット番号: チケット件名`
  - その他の PR: `JIRAKEY-チケット番号: チケット件名`

- テンプレート使用:
  - `:m:` 付きPR: `.github/for_dev_template.md`
  - `:m:` なしPR: `.github/pull_request_template.md`

これだけ です。コード変更は一切ありません。

実際の動作フロー

導入効果：「考えない」ことで得られた価値

認知負荷の劇的な削減

• ✅ ブランチ名を考える
• ✅ ベースブランチを確認する
• ✅ コミットメッセージの形式を思い出す
• ✅ PRタイトルをチケットからコピペする
• ✅ PRテンプレートを選択する

→ 「チケット番号を伝えるだけ」で完結

一貫性の担保

• ブランチ名・コミットメッセージ・PRタイトルがプロジェクトルールに100%準拠
• レビュワーが「これ命名規則違う」と指摘する手間が消滅

オンボーディング時間の短縮

• 新規メンバーが「ブランチ名のルール覚えなきゃ...」と悩む必要がない
• 「CLAUDE.mdを見て」ではなく「Claude Codeに聞いて」でOK

開発速度の向上

• 「Jira開いてチケット件名コピー」という往復が消滅
• 意思決定の回数が減ることでフロー状態を維持しやすい

今後の展望

サブエージェント活用によるコンテキストウィンドウ最適化

現在の実装では、Atlassian MCPを使用するとコンテキストウィンドウが圧迫される課題があります。この解決策として、 サブエージェント を活用した階層的なタスク分散を検討しています。

サブエージェントとは?

Claude Code のサブエージェントは、特定のタスクに特化したAIアシスタントで、独立したコンテキストウィンドウ を持ちます。
これにより

• ✅ メインエージェントのコンテキストを汚染しない
• ✅ 専門的なタスクを効率的に処理
• ✅ 大量の情報取得と処理を分離できる

実装計画: 3つの専門サブエージェント

1. Jira情報取得サブエージェント (jira-researcher)

**役割**:
- Atlassian MCPでチケット情報を取得
- 必要な情報のみを抽出(チケット番号、件名、エピック、ステータス)

2. ブランチ戦略判定サブエージェント (branch-strategist)

**役割**:
- チケット情報からブランチ名を生成
- 親子チケット関係を判定
- 分岐パターンからベースブランチを決定

3. PR作成サブエージェント (pr-creator)

**役割**:
- PR作成の分岐判定を実行
- 適切なテンプレート選択

まとめ：AIアシスタントは「考えない開発」を実現する

「チケット番号を伝えるだけで、ブランチ作成・コミット・PR作成が完了する」

これを実現したのは、CLAUDE.mdという「AIが読めるドキュメント」とMCP連携だけです。コード変更はゼロ。既存システムへの影響もゼロ。

重要なのは、 開発者が「考えなくていいこと」を明確にし、AIに任せた 点です。

AIアシスタントを「コード補完ツール」から「開発フロー全体のパートナー」に進化させることで、開発者は 本質的な問題解決にだけ集中できる 世界が実現できます。