この記事は、AIエージェントを段階的に構築していくシリーズの第4弾です。
第4弾では、Claude Code × Redmine × Claude Cowork を組み合わせ、チケット確認からExcel試験項目書作成までを自動化する流れを扱います。
これまでの記事を順に読むことで、レビュー、修正、テスト項目作成、試験項目書化までを段階的に理解できます。第3弾はこちら：
【第3弾】Claude Code × Claude Coworkで、結合テスト項目・受け入れテスト項目の試験項目書を自動生成する
はじめに
前回の記事では、VS Code上のClaude Codeから「レビュー → 修正 → ビルド確認 → テスト項目作成」を一気通貫で実行する方法を紹介しました。
今回はその発展版です。
前回の記事ではコード差分のみを見てレビューしていましたが、実際の開発ではチケットに書かれた要件を満たしているかが重要です。本記事では、RedmineとMCP連携し、チケット内容を踏まえたレビューを行い、さらにClaude CoworkでExcelのテスト項目書まで仕上げ、最後にSlack通知でチームに完了を知らせる構成を紹介します。
前回の記事で作成したカスタムコマンドにはRedmine連携・ファイル保存・Slack通知の機能がなかったため、まず review-and-fix.md を更新するところから始めます。
更新後、Claude Codeはレビュー実行時にRedmineのチケット内容を確認した上でレビューを行い、gitのコミットメッセージからチケット番号を自動抽出してファイル名としてMarkdownを保存し、完了後にSlackで通知するようになります。今回の例では、コミットメッセージに含まれていた 408408 がチケット番号として抽出され、テスト項目・最終レポート・受け入れ基準の3ファイルが生成されています。
Claude Code（Redmine確認・レビュー・修正・ビルド・テスト項目/レポート/受け入れ基準MD生成・Slack通知）
│
│ Redmine（MCP経由でチケット情報取得）
│ ~/Documents/test-cases/408408/408408.md（テスト項目）
│ ~/Documents/test-cases/408408/408408_レポート.md（最終レポート）
│ ~/Documents/test-cases/408408/408408_受け入れ基準.md（受け入れ基準）
│ Slack（MCP経由でチャンネルに完了通知 + チケットURLリンク付き）
│
▼
Claude Cowork（MDを読み込み → Excel試験項目書を生成）
│
│ ~/Documents/test-cases/408408/408408_テスト項目書.xlsx
│
▼
結合テスト項目書 + 受け入れテスト項目書（2シート構成）
ポイントは、3つのシステムがファイルとMCPを介して連携するということです。Claude CodeがRedmineからチケット情報を取得してレビューし、書き出したMarkdownをClaude CoworkがExcelに変換する。ファイル保存が完了するとSlackでチームに通知される。人間が間に入ってコピペする必要はありません。
受け入れ基準は別ファイルで出力されるため、内容を確認してからRedmineのチケットに貼り付ける運用になります。
Claude Coworkとは
Claude Coworkは、Anthropicが提供するデスクトップ向けのツールです。ファイルやフォルダを作業対象として指定し、Claudeに直接タスクを実行させることができます。
コードエディタを使わない業務——ドキュメント整理、ファイル変換、レポート作成など——に適しており、今回のように「Markdownを読み込んでExcelを生成する」といった作業に向いています。
Claude Coworkは現在ベータ版として提供されています。利用するにはClaude Pro / Team / Enterpriseのいずれかのプランが必要です。詳細はAnthropicの公式サイトをご確認ください。
前提条件
| 項目 | 条件 |
|---|---|
| 前回記事の環境 | Claude Codeでレビュー〜テスト項目作成が実行できる状態 |
| Redmine MCP連携 | Claude CodeからRedmineにMCP経由で接続済み |
| Slack MCP連携 | Claude CodeからSlackにMCP経由で接続済み |
| Claude Cowork | インストール済み |
| Anthropicアカウント | Claude Pro / Team / Enterprise いずれか |
手順
1. カスタムコマンドの更新（review-and-fix.md）
前回の記事で作成した review-and-fix.md には、Redmine連携・テスト項目のファイル保存・Slack通知の機能が含まれていません。以下のコマンドで更新します。
⚠️ 以下の
cat << 'EOF' >コマンドはファイルを上書きします。既存のreview-and-fix.mdに独自のカスタマイズを加えている場合は、必要な部分だけを手動で追記・編集してください。
cat << 'EOF' > ~/.claude/commands/review-and-fix.md
あなたは熟練した iOS コードレビュー担当です。
Swift / Objective-C / SwiftUI / UIKit / Xcode / 署名 / 依存関係管理 / 配布 / App Store 審査まで理解している前提で対応してください。
以下の手順を順番に実行してください。
## Step 1: チケット番号の特定とRedmineチケット内容の確認
- $ARGUMENTS からコミット範囲（`..` を含む要素）を特定する
- チケット番号が引数に含まれていればそれを使用する
- チケット番号が含まれていない場合は、コミット範囲の `git log` からチケット番号を抽出する（レンジの開始コミットは基点のため対象外。レビュー対象のコミットメッセージのみから抽出する）
- チケット番号が複数ある場合は、最初に見つかったものを使用する
- 特定したチケット番号でMCP経由でRedmineからチケット情報を取得する
- 以下の内容を確認し、日本語で要約する
- チケットのタイトル・概要
- 改修の目的・背景
- 受け入れ条件（記載がある場合）
- 関連チケット（記載がある場合）
- チケット番号が見つからない場合、またはRedmineからの取得に失敗した場合は「チケット情報の取得に失敗しました」と報告し、Step 2 以降はコード差分のみで判断する
## Step 2: コードレビュー
- $ARGUMENTS のコミット範囲の差分を取得し、以下の観点で必ず全てチェックしてレビューする
- Step 1 で取得したチケットの目的・受け入れ条件と照らし合わせてレビューする
- 入力に存在しない事実を前置しない
- 不明な項目は「未確認」、推測は「(推測です)」と明記する
### 必須チェック観点
以下の観点を全てチェックし、各観点について「該当なし」の場合も「該当なし」と明記すること。
1. **チケット要件との整合性**: Step 1 のチケット目的・受け入れ条件を満たしているか
2. **クラッシュリスク**: force unwrap、配列範囲外アクセス、nil 参照、メインスレッド違反
3. **メモリリスク**: retain cycle、weak/unowned の使い分け、Combine の sink 解放漏れ
4. **iOSバージョン互換**: iOS 15 で動作するか、@available 漏れがないか
5. **既存コードへの影響**: 呼び出し元・呼び出し先への影響範囲
6. **テスタビリティ**: 単体テストが書ける構造か
7. **命名・可読性**: Swift API Design Guidelines への準拠
8. **エラーハンドリング**: do-catch の網羅性、Result 型の活用
9. **非同期処理**: async/await の適切な使用、Task のキャンセル考慮
10. **アクセシビリティ**: VoiceOver、Dynamic Type 対応への影響
### リスク評価基準
問題点を以下のリスク評価基準で分類し、日本語で報告する。
- 🔴 重大: 起動不能、重大クラッシュ、署名や Bundle ID の重大不整合、重大な審査リスク
- 🟠 高: 権限設定不備の可能性が高い、広範囲回帰、依存関係の破壊的変更
- 🟡 中: 局所的回帰、保守性低下、異常系の懸念、運用リスク
- 🟢 低: 影響範囲が限定的で、入力上は重大な懸念が確認できない
## Step 3: コード修正
- 🔴 重大 または 🟠 高 の問題について修正を実施する
- 元のコード意図を尊重し、最小限の変更にする
- 修正内容を日本語で報告する
## Step 4: ビルド確認
- Xcodeでビルドを実行する
- ビルドエラーがあれば修正を試み、再度ビルドする
- **ビルド試行は最大3回まで**。3回失敗した場合は以下を報告して次のStepに進む：
- 最後のエラーメッセージ全文
- 試した修正内容の履歴
- 推測される原因（「(推測です)」と明記）
- 人間によるデバッグが必要である旨
- 最終的なビルド結果を報告する
## Step 5: テスト項目作成
改修内容およびStep 1のチケット情報に基づき、以下の観点でテストケースを作成する：
### 正常系
- 改修で追加・変更された機能が期待通り動作するケース
- チケットの受け入れ条件を満たすケース
### 異常系
- 不正な入力、ネットワークエラー、未認証状態など異常条件でのケース
### 回帰テスト
- 改修の影響範囲にある既存機能が壊れていないことを確認するケース
### 出力形式
テストケースは以下の形式で出力する：
| # | 分類 | テスト項目 | 操作手順 | 期待結果 | 優先度 |
|---|------|-----------|---------|---------|-------|
- 優先度は 🔴 P0（必須）/ 🟡 P1（重要）/ 🟢 P2（推奨）で分類する
- 改修差分から読み取れる範囲のみ記載し、推測は「(推測です)」と明記する
## Step 6: 受け入れ基準の作成
Step 1 のチケット情報と Step 2 のコード差分に基づき、このチケットの受け入れ基準を作成する。
### 作成ルール
- チケットに既存の受け入れ基準がある場合は、それをベースに不足分を補完する
- 既存の受け入れ基準がない場合は、新規に作成する
- 実装内容から確認すべき動作条件を箇条書きで列挙する
- 技術的な補足が必要な項目には「Note:」を付記する
- 確認方法が未確定の項目には「[TBD]」を付記する
- Redmineのチケットにそのまま貼り付けられる形式で出力する
### 観点
- 改修で追加・変更された機能が正しく動作すること
- アプリの状態別（フォアグラウンド／バックグラウンド／プロセス無し）の動作
- 既存ユーザーへの影響（アップデート時の挙動）
- 異常系での動作（通信断、不正値など）
- 既存機能への回帰影響
## Step 7: 最終レポート
以下の構成で最終結果をMarkdownとしてまとめる：
- 見出し「最終レポート」
- セクション「チケット情報」: チケット番号、タイトル、コミット範囲
- セクション「レビュー結果」: 以下の表形式で出力する
| # | リスク | 観点カテゴリ | ファイル:行 | 問題内容 | 推奨対応 | 修正実施 |
|---|--------|------------|-----------|---------|---------|---------|
- 「観点カテゴリ」は Step 2 の必須チェック観点(1〜10)のいずれかを記載する
- 「修正実施」は ✅ / ❌ / - (対象外)で記載する
- 問題が1件もない場合は表の代わりに「該当なし」と明記する
- セクション「実施した修正」: 修正内容の一覧（Before/After のコード差分を含む）
- セクション「ビルド結果」: ✅ 成功 / ❌ 失敗（失敗の場合は最後のエラーメッセージを併記）
- セクション「残課題」: あれば記載、なければ「なし」と明記
## Step 8: テスト項目をファイルに保存
- Step 5 で作成したテストケースをMarkdownファイルとして保存する
- Step 1 で特定したチケット番号を使用する
- チケット番号が見つからなかった場合は test-cases-YYYYMMDD-HHmmss をフォルダ名・ファイル名にする
- 保存先: ~/Documents/test-cases/{チケット番号}/
- ファイル名: {チケット番号}.md（例: ~/Documents/test-cases/408408/408408.md）
- 同名ファイルが既に存在する場合は {チケット番号}-YYYYMMDD-HHmmss.md にする
- 保存先ディレクトリが存在しない場合は `mkdir -p` で作成する
- ファイルの冒頭にチケット番号とコミット範囲を記載する
- 保存完了後、ファイルの絶対パスを報告する
## Step 9: 最終レポートをファイルに保存
- Step 7 で構成した最終レポートを別ファイルとして保存する
- 保存先: ~/Documents/test-cases/{チケット番号}/
- ファイル名: {チケット番号}_レポート.md（例: ~/Documents/test-cases/408408/408408_レポート.md）
- 同名ファイルが既に存在する場合は {チケット番号}_レポート-YYYYMMDD-HHmmss.md にする
- 保存完了後、ファイルの絶対パスを報告する
## Step 10: 受け入れ基準をファイルに保存
- Step 6 で作成した受け入れ基準を別ファイルとして保存する
- 保存先: ~/Documents/test-cases/{チケット番号}/
- ファイル名: {チケット番号}_受け入れ基準.md（例: ~/Documents/test-cases/408408/408408_受け入れ基準.md）
- 同名ファイルが既に存在する場合は {チケット番号}_受け入れ基準-YYYYMMDD-HHmmss.md にする
- 保存完了後、ファイルの絶対パスを報告する
- 「内容を確認の上、Redmineのチケットに貼り付けてください」と案内する
## Step 11: Slackへの完了通知
- MCP経由でSlackに以下のメッセージを送信する
- 送信先チャンネルID: D3225KYB1
- メッセージ形式:
<{RedmineのベースURL}/issues/{チケット番号}|#{チケット番号}「{チケットタイトル}」> のレビューが完了しました。
成果物:
• {チケット番号}.md（テスト項目）
• {チケット番号}_レポート.md（最終レポート）
• {チケット番号}_受け入れ基準.md（受け入れ基準）
- RedmineのベースURLは Step 1 でチケット情報を取得した際のURLから組み立てる
- チケット番号・タイトルは Step 1 で取得した情報を使用する
- 取得できなかった項目は省略し、取得できた情報のみで構成する
- 送信完了後、送信先と送信内容を報告する
- 送信に失敗した場合は「Slack通知の送信に失敗しました」と報告し、手動での通知を案内する
EOF
前回からの変更点
| 変更箇所 | 内容 |
|---|---|
| Step 1（新規） | チケット番号の特定とMCP経由でRedmineチケット内容を確認 |
| Step 2（旧Step 1） | チケットの目的・受け入れ条件と照らし合わせてレビューするように変更 |
| Step 5（旧Step 4） | チケットの受け入れ条件を満たすケースをテスト項目に追加 |
| Step 6（新規） | チケット情報とコード差分から受け入れ基準を作成 |
| Step 7（旧Step 5） | 最終レポートをMarkdown構造として構成し、ファイル保存に対応 |
| Step 8（新規） | テスト項目をMarkdownファイルとして ~/Documents/test-cases/ に保存 |
| Step 9（新規） | 最終レポートを別ファイルとして ~/Documents/test-cases/ に保存 |
| Step 10（新規） | 受け入れ基準を別ファイルとして ~/Documents/test-cases/ に保存 |
| Step 11（新規） | MCP経由でSlackのチャンネルにリンク付き完了通知と成果物一覧を送信 |
Step 1 でチケット番号の特定からRedmine確認までを一括で行い、特定したチケット番号はStep 2以降のレビューやStep 8〜11のファイル保存・通知でも使い回されます。
引数にチケット番号あり → それを使う
↓ なし
git log からチケット番号を抽出 → 最初に見つかったものを使う
↓ 見つからない
test-cases-YYYYMMDD-HHmmss をファイル名にする
チケット番号が特定できた場合は、Redmineからチケット情報を取得し、改修の目的や受け入れ条件を把握した上でレビューを行います。
実行例
# チケット番号を明示（最も確実）
408408 a64d7c776..4a209d66a レビューして
# コミット範囲のみ（コミットメッセージから自動抽出を試みる）
a64d7c776..4a209d66a レビューして
実行すると、Claude Codeが Step 1〜11 を順に処理し、完了後にテスト項目・最終レポート・受け入れ基準のファイルパスが表示され、SlackにチケットURLリンク付きの完了通知が送信されます。
チケット情報の確認からテスト項目・最終レポート・受け入れ基準のファイル保存、Slack通知まで、全ステップが自動で完了する
Slack通知の表示イメージ
Step 11 で送信されるSlackメッセージは以下のように表示されます。
#408408「○○機能の実装」 のレビューが完了しました。
成果物:
• 408408.md（テスト項目）
• 408408_レポート.md（最終レポート）
• 408408_受け入れ基準.md（受け入れ基準）
チケット番号部分がRedmineへのリンクになるため、通知を受け取った人がワンタップでチケットを開けます。
2. Claude Coworkの起動と作業フォルダの指定
Claude Coworkを起動し、作業フォルダを指定します。
- Claude Coworkを開く
- 作業フォルダとして
~/Documents/test-cases/408408/を指定する（チケット番号に合わせて変更）
これでClaude Coworkはこのフォルダ内のファイルを読み書きできるようになります。
3. プロンプトの投入
Claude Coworkに以下のプロンプトを入力します。
作業フォルダにはそのチケットのファイルしか入っていないため、ファイル名を個別に指定する必要はありません。同じチケットに対して複数回レビューを実行して .md が複数ある場合もまとめて取り込めます。
あなたは超一流のiOSアプリQAエンジニアです。
（大規模商用アプリの品質保証経験を持つ前提で振る舞ってください）
全てのmdファイルを読み込み、以下を作成してください。
---
## 【1. 結合テスト項目書】
### ■ 出力形式
- Excel形式（表形式）
### ■ 観点（必ず網羅すること）
- 画面遷移（Navigation / DeepLink / Modal）
- API連携（正常系 / 異常系 / タイムアウト / リトライ）
- データ整合性（表示データとAPIレスポンスの一致）
- 状態管理（ログイン状態 / キャッシュ / セッション）
- 非同期処理（ローディング / race condition）
- エラーハンドリング（通信エラー / 業務エラー）
- 外部連携（LINE連携 / WebView / 外部ブラウザ）
- 端末依存（iOSバージョン差異 / ダークモード / 回転）
- パフォーマンス影響（画面表示遅延 / APIレスポンス）
### ■ 要件
- テストケース単位で具体的に記載する
- 前提条件 / 操作手順 / 期待結果 を明確に分離する
- 正常系・異常系を必ず含める
- ユーザー操作ベースで記述する（実装依存NG）
---
## 【2. 受け入れテスト項目】
### ■ 出力形式
- Excel形式（表形式）
### ■ 観点（ビジネス視点で記載）
- ユーザーが目的を達成できるか
- UXとして違和感がないか
- 主要シナリオが一連で成立するか
- クリティカルパス（課金・登録・ログインなど）が成立するか
### ■ 要件
- シナリオ単位で記載する（テストケース単位ではなく）
- エンドツーエンドの流れで記載する
- ユーザー視点で自然な操作フローにする
- 技術用語ではなく、ユーザー行動ベースで書く
---
## 【3. 受け入れ基準】
### ■ 出力形式
- 表形式ではなく、リスト形式
### ■ 粒度
- 個別テストケースではなく「機能単位・体験単位」で記載
### ■ 要件
- 実装詳細には触れない
- 判断可能な表現にする（OK/NGが明確）
- 1項目1行で簡潔に記載
例：
・ユーザーがログインからホーム画面表示まで問題なく完了できること
・通信エラー時にユーザーが再試行できること
・主要な画面遷移に違和感がないこと
---
## 【重要制約】
- iOSアプリ特有の挙動（ライフサイクル / バックグラウンド復帰）を考慮すること
- 「抜け漏れがないか」という観点でセルフレビューしてから出力すること
4. 実行結果
Claude Coworkが以下を自動で実行します。
-
408408.md、408408_レポート.md、408408_受け入れ基準.mdを読み込む - テストケースの内容を解析し、最終レポートのチケット情報やレビュー結果を文脈として活用する
- 受け入れ基準の条件をもとに、受け入れテスト項目の網羅性を確認する
- 結合テスト観点で再設計・補完してシート1を作成
- 受け入れテスト観点で再設計・補完してシート2を作成
-
408408_テスト項目書.xlsxとして保存
生成されるファイル：
~/Documents/test-cases/
└── 408408/
├── 408408.md ← テスト項目（Claude Code）
├── 408408_レポート.md ← 最終レポート（Claude Code）
├── 408408_受け入れ基準.md ← 受け入れ基準（Claude Code）→ 確認後Redmineに貼付
└── 408408_テスト項目書.xlsx ← Excel試験項目書（Claude Cowork）
Claude Codeが生成したMarkdownファイル群と、Claude Coworkが生成した 408408_テスト項目書.xlsx がチケット番号のフォルダにまとまる
Redmine連携で何が変わるのか
前回の記事では、コード差分だけを見てレビューしていました。これだと「コードとして正しいか」は判断できても、「チケットの要件を満たしているか」は判断できません。
Redmine連携を追加したことで、Claude Codeのレビューに以下の視点が加わります。
レビュー時：チケットに記載された目的・受け入れ条件と照らし合わせて、実装漏れや要件との乖離を検出できるようになります。
テスト項目作成時：コード差分から読み取れる技術的なテストケースに加えて、チケットの受け入れ条件を満たすテストケースも生成されます。
受け入れ基準作成時：チケット情報とコード差分の両方を踏まえて、実装内容に即した受け入れ基準が生成されます。既存の受け入れ基準がある場合は不足分の補完、ない場合は新規作成を行います。
前回（コード差分のみ）
git diff → レビュー → テスト項目
今回（Redmine + Slack連携あり）
Redmine（要件・受け入れ条件）
＋ → レビュー → テスト項目 + 受け入れ基準 → Slack通知
git diff（コード差分）
なぜ「そのまま転記しない」が重要なのか
Claude Codeが生成するMarkdownのテストケースは、コード差分とチケット情報に基づく技術寄りの視点で書かれています。
| # | 分類 | テスト項目 | 操作手順 | 期待結果 | 優先度 |
|---|------|-----------|---------|---------|-------|
| 1 | 正常系 | ログインAPIが200を返す | 正しいID/PWを入力しログインボタンタップ | ホーム画面に遷移する | 🔴 P0 |
これをそのままExcelに転記しても、実務では使いにくいものになります。
結合テストでは、このケースに加えて「トークン保存の確認」「ログ出力の確認」「セッション管理」といった内部仕様の観点が必要です。
受け入れテストでは、「ユーザーが正しいIDとパスワードでログインすると、ホーム画面が表示される」のように、技術用語を排除した記述が求められます。
プロンプトに「そのまま転記しない」「再設計する」と明記することで、Claude Coworkは入力のMarkdownを素材として扱い、それぞれのテスト種別にふさわしい形に再構成します。
エージェント連携のポイント
ファイルシステムとMCPが接点になる
Redmine ◀──MCP経由── Claude Code
│
├──書き出し──▶ 408408.md（テスト項目）
├──書き出し──▶ 408408_レポート.md（最終レポート）
├──書き出し──▶ 408408_受け入れ基準.md（受け入れ基準）
│ │
├──MCP経由──▶ Slack チャンネル（完了通知 + チケットURLリンク）
│ │
│ Claude Cowork ◀──読み込み──┘
│ ──書き出し──▶ 408408_テスト項目書.xlsx
Claude CodeはMCP経由でRedmine・Slackと通信し、ファイルシステム経由でClaude Coworkと連携します。それぞれの接点が異なりますが、人間が介在するのは指示を出すところだけです。
Slack通知にはRedmineのチケットURLがリンクとして含まれるため、通知を受け取ったメンバーはワンタップでチケットの詳細を確認できます。
役割分担が明確
| エージェント | 役割 | 得意なこと |
|---|---|---|
| Claude Code | チケット確認・コードレビュー・修正・ビルド・テスト項目抽出・レポート生成・受け入れ基準生成・Slack通知 | ターミナル操作、git、Xcode連携、Redmine連携、Slack連携 |
| Claude Cowork | ドキュメント変換・再構成・Excel生成 | ファイル操作、ドキュメント整形 |
1つのエージェントにすべてをやらせるより、得意な領域で分担する方が出力品質が安定します。
ファイルを分ける理由
テスト項目・最終レポート・受け入れ基準を別ファイルにすることで、それぞれの用途が明確になります。
テスト項目（408408.md）はClaude CoworkがExcel変換する際の主な入力データです。テストケースだけが記載されているため、Claude Coworkがテスト項目の再設計に集中できます。
最終レポート（408408_レポート.md）はレビュー結果・修正内容・ビルド結果・残課題をまとめた記録です。チケットの対応状況を振り返る際や、チーム内で共有する際に使います。Claude Coworkもこのファイルを読み込むため、テスト項目の背景情報として活用されます。
受け入れ基準（408408_受け入れ基準.md）は実装内容に基づいて生成された受け入れ条件です。内容を確認した上でRedmineのチケットに貼り付けます。Claude Coworkもこのファイルを読み込むため、受け入れテスト項目が受け入れ基準を網羅しているかの確認に活用されます。
さらに効率化するには
別のチケットで実行する場合
Claude Coworkの作業フォルダを別のチケット番号のフォルダ（例: ~/Documents/test-cases/408512/）に切り替えて、同じプロンプトをそのまま入力するだけです。プロンプトの内容を書き換える必要はありません。
Excelの品質が不十分な場合
生成されたExcelを確認して不足があれば、同じ会話内で追加指示を出せます。
結合テスト項目書に「メモリリーク確認」の観点が不足しています。追加してください。
受け入れテスト項目書の操作手順をもう少し具体的にしてください。
Claude Coworkは既存のExcelを更新して再保存します。
Slack通知先をカスタマイズする場合
通知先を変更したい場合は、Step 11 の送信先チャンネルIDを書き換えてください。
## Step 11: Slackへの完了通知
- 送信先チャンネルID: C01XXXXXXXX（別のチャンネルに変更）
複数宛先への同時通知や、レビュー結果のサマリーを含めるといった拡張も、Step 11 の記述を追加するだけで対応できます。
Slack通知のリンクをカスタマイズする場合
RedmineのベースURLは Step 1 のチケット取得時に自動で組み立てますが、環境が固定の場合はStep 11に直接埋め込むこともできます。
- メッセージ形式:
<https://redmine.yourcompany.com/issues/{チケット番号}|#{チケット番号}「{チケットタイトル}」> のレビューが完了しました。
まとめ
開発者の操作 エージェントの動作
───────────────────────────────────────────────────────────
408408 a64d7c776..4a209d66a レビューして → Claude Code: Redmine確認→レビュー→修正→ビルド→MD生成
│
408408/408408.md（テスト項目）
408408/408408_レポート.md（最終レポート）
408408/408408_受け入れ基準.md（受け入れ基準）
│
Slack チャンネルにリンク付き完了通知 + 成果物一覧
│
受け入れ基準を確認 → Redmineに貼付 （人間が確認する唯一のポイント）
│
Coworkでプロンプト入力 → Claude Cowork: MD読み込み→Excel生成
│
408408/408408_テスト項目書.xlsx
人間が行うのは3つの操作です。
- Claude Codeに
408408 a64d7c776..4a209d66a レビューして - 受け入れ基準ファイルを確認し、Redmineのチケットに貼り付ける
- Claude Coworkに作業フォルダを指定してプロンプトを入力
Slack通知は自動で送信されるため、レビュー完了をチームに知らせる手間もなくなります。通知にはRedmineのチケットURLがリンクとして含まれるため、受け取った人はそのままチケットを確認できます。
Redmineのチケット内容を踏まえたコードレビューから、受け入れ基準の生成、Excelのテスト項目書完成、Slack通知まで、エージェントがMCPとファイルを介してリレーする形で、一連の品質管理フローを自動化できます。
すべてローカル環境に閉じた運用のため、チームの開発フローに影響を与えず、個人の作業効率化として導入できます。
関連記事
本記事は、AIエージェントを段階的に構築していくシリーズの一部です。
- 【第1弾】【初心者向け】VS CodeのClaude Codeで「iOSコードレビュー → 修正 → Xcodeビルド確認」を自動化する
- 【第2弾】【初心者向け】VS CodeのClaude Codeで「iOSコードレビュー → 修正 → Xcodeビルド確認 → テスト項目作成」を自動化する
- 【第3弾】Claude Code × Claude Coworkで、結合テスト項目・受け入れテスト項目の試験項目書を自動生成する
- 【第4弾】Claude Code × Redmine × Claude Coworkで、チケット確認からExcel試験項目書作成まで自動化する
- 【第5弾】Claude Codeが「そのAPI、非推奨ですよ」と教えてくれる ― Redmine連携フローにContext7を組み込む