【第3弾】Claude Code × Claude Coworkで、結合テスト項目・受け入れテスト項目の試験項目書を自動生成する

この記事は、AIエージェントを段階的に構築していくシリーズの第3弾です。
第1弾・第2弾では、Claude Codeを使ったレビュー、修正、ビルド確認、テスト項目作成までを扱いました。
第3弾では、Claude Coworkと連携し、結合テスト項目・受け入れテスト項目を試験項目書として成果物化する流れを扱います。

第2弾はこちら：
【第2弾】【初心者向け】VS CodeのClaude Codeで「iOSコードレビュー → 修正 → Xcodeビルド確認 → テスト項目作成」を自動化する

はじめに

前回の記事では、VS Code上のClaude Codeから「レビュー → 修正 → ビルド確認 → テスト項目作成」を一気通貫で実行する方法を紹介しました。

今回はその続きです。

Claude Codeが生成したテスト項目のMarkdownファイルを、Claude Coworkに渡して、実務で使えるExcelのテスト項目書（結合テスト・受け入れテスト）に仕上げるところまでを自動化します。

前回の記事で作成したカスタムコマンドにはテスト項目のファイル保存機能がなかったため、まず review-and-fix.md を更新するところから始めます。

更新後、Claude Codeはレビュー実行時にgitのコミットメッセージからチケット番号を自動抽出し、そのチケット番号をファイル名としてMarkdownを保存するようになります。今回の例では、コミットメッセージに含まれていた 408408 がチケット番号として抽出され、408408.md というファイルが生成されています。

Claude Code（レビュー・修正・ビルド・テスト項目MD生成）
  │
  │  ~/Documents/test-cases/408408.md
  │
  ▼
Claude Cowork（MDを読み込み → Excel試験項目書を生成）
  │
  │  ~/Documents/test-cases/408408_テスト項目書.xlsx
  │
  ▼
結合テスト項目書 + 受け入れテスト項目書（2シート構成）

ポイントは、2つのエージェントがファイルシステムを介して連携するということです。Claude Codeが書き出したファイルをClaude Coworkが読み取る。人間が間に入ってコピペする必要はありません。

Claude Coworkとは

Claude Coworkは、Anthropicが提供するデスクトップ向けのツールです。ファイルやフォルダを作業対象として指定し、Claudeに直接タスクを実行させることができます。

コードエディタを使わない業務——ドキュメント整理、ファイル変換、レポート作成など——に適しており、今回のように「Markdownを読み込んでExcelを生成する」といった作業に向いています。

Claude Coworkは現在ベータ版として提供されています。利用するにはClaude Pro / Team / Enterpriseのいずれかのプランが必要です。詳細はAnthropicの公式サイトをご確認ください。

前提条件

項目	条件
前回記事の環境	Claude Codeでレビュー〜テスト項目作成が実行できる状態
Claude Cowork	インストール済み
Anthropicアカウント	Claude Pro / Team / Enterprise いずれか

手順

1. カスタムコマンドの更新（review-and-fix.md）

前回の記事で作成した review-and-fix.md には、テスト項目を画面に出力するところまでしか含まれていません。Claude Coworkと連携するためには、テスト項目をファイルとして保存するステップが必要です。

以下のコマンドで review-and-fix.md を更新します。

cat << 'EOF' > ~/.claude/commands/review-and-fix.md
あなたは熟練した iOS コードレビュー担当です。
Swift / Objective-C / SwiftUI / UIKit / Xcode / 署名 / 依存関係管理 / 配布 / App Store 審査まで理解している前提で対応してください。

以下の手順を順番に実行してください。

## Step 1: コードレビュー
- $ARGUMENTS の2番目の要素（コミット範囲）の差分を取得してレビューする
- 問題点を以下のリスク評価基準で分類し、日本語で報告する
- 入力に存在しない事実を前置しない
- 不明な項目は「未確認」、推測は「(推測です)」と明記する

### リスク評価基準
- 🔴 重大: 起動不能、重大クラッシュ、署名や Bundle ID の重大不整合、重大な審査リスク
- 🟠 高: 権限設定不備の可能性が高い、広範囲回帰、依存関係の破壊的変更
- 🟡 中: 局所的回帰、保守性低下、異常系の懸念、運用リスク
- 🟢 低: 影響範囲が限定的で、入力上は重大な懸念が確認できない

## Step 2: コード修正
- 🔴 重大 または 🟠 高 の問題について修正を実施する
- 元のコード意図を尊重し、最小限の変更にする
- 修正内容を日本語で報告する

## Step 3: ビルド確認
- Xcodeでビルドを実行する
- ビルドエラーがあれば修正し、再度ビルドする
- 最終的なビルド結果を報告する

## Step 4: テスト項目作成
改修内容に基づき、以下の観点でテストケースを作成する：

### 正常系
- 改修で追加・変更された機能が期待通り動作するケース

### 異常系
- 不正な入力、ネットワークエラー、未認証状態など異常条件でのケース

### 回帰テスト
- 改修の影響範囲にある既存機能が壊れていないことを確認するケース

### 出力形式
テストケースは以下の形式で出力する：

| # | 分類 | テスト項目 | 操作手順 | 期待結果 | 優先度 |
|---|------|-----------|---------|---------|-------|

- 優先度は 🔴 P0（必須）/ 🟡 P1（重要）/ 🟢 P2（推奨）で分類する
- 改修差分から読み取れる範囲のみ記載し、推測は「(推測です)」と明記する

## Step 5: 最終レポート
以下の形式で最終結果を出力する：
- レビューで見つかった問題の一覧（🔴🟠🟡🟢 で分類）
- 実施した修正の一覧
- ビルド結果（✅ 成功 / ❌ 失敗）
- テストケース一覧
- 残課題があれば記載

## Step 6: テスト項目をファイルに保存
- $ARGUMENTS の最初の要素をチケット番号、2番目をコミット範囲として扱う
- チケット番号が指定されていない場合（コミット範囲のみの場合）は、コミット範囲の `git log` からチケット番号を抽出する
- チケット番号が複数ある場合は、最初に見つかったものを使用する
- チケット番号が見つからない場合は test-cases-YYYYMMDD-HHmmss をファイル名にする
- 保存先: ~/Documents/test-cases/
- ファイル名: {チケット番号}.md（例: 408408.md）
- 同名ファイルが既に存在する場合は {チケット番号}-YYYYMMDD-HHmmss.md にする
- 保存先ディレクトリが存在しない場合は `mkdir -p` で作成する
- ファイルの冒頭にチケット番号とコミット範囲を記載する
- 保存完了後、ファイルの絶対パスを報告する
EOF

前回からの変更点

変更箇所	内容
Step 6（新規）	テスト項目をMarkdownファイルとして ~/Documents/test-cases/ に保存

Step 6 が追加されたことで、Claude Codeは以下の順でチケット番号を解決します。

引数にチケット番号あり → それを使う
  ↓ なし
git log からチケット番号を抽出 → 最初に見つかったものを使う
  ↓ 見つからない
test-cases-YYYYMMDD-HHmmss をファイル名にする

実行例

# チケット番号を明示（最も確実）
408408 a64d7c776..4a209d66a レビューして

# コミット範囲のみ（コミットメッセージから自動抽出を試みる）
a64d7c776..4a209d66a レビューして

2. Claude Coworkの起動と作業フォルダの指定

Claude Coworkを起動し、作業フォルダを指定します。

1. Claude Coworkを開く
2. 作業フォルダとして ~/Documents/test-cases/ を指定する

これでClaude Coworkはこのフォルダ内のファイルを読み書きできるようになります。

3. プロンプトの投入

Claude Coworkに以下のプロンプトを入力します。

冒頭の「指定されたMarkdownファイル」の部分は、実行時に対象のファイル名（例: 408408.md）に読み替えて入力してください。

指定されたMarkdownファイルを読み込み、iOSアプリ向けの試験項目書をExcelファイルとして作成してください。
# 目的
以下2種類の試験項目書を1つのExcelファイルにまとめて作成する
1. 結合テスト項目書
2. 受け入れテスト項目書
---
# 入力
- Markdownファイルにはテストケースが記載されている
- テスト項目 / 操作手順 / 期待結果 / 分類 / 優先度 などを含む
---
# 出力要件
## ファイル形式
- Excel（.xlsx）
## シート構成
- シート1: 結合テスト項目書
- シート2: 受け入れテスト項目書
---
# 列定義
## 結合テスト項目書
- No
- 機能分類
- サブ機能
- テスト観点
- テスト項目
- 事前条件
- 操作手順
- 入力値／条件
- 期待結果
- 確認方法
- 分類（正常系／異常系／回帰）
- 優先度
- 備考
## 受け入れテスト項目書
- No
- 業務観点
- 利用シナリオ
- テスト項目
- 事前条件
- 操作手順
- 期待結果
- 判定基準
- 分類（正常系／異常系／回帰）
- 優先度
- 備考
---
# 作成ルール
## 共通
- 1行 = 1テストケース
- ヘッダー行は固定
- フィルタが使えるように整形
- 日本語で記載
- 不明点は「要確認」と記載
---
## 結合テスト項目書（重要）
内部仕様・連携・技術観点を重視して再構成する
### 必須観点
- 初期化処理
- データ連携
- 状態遷移（ログイン／ログアウトなど）
- 通知処理
- 画面遷移／URL処理
- 異常系（不正値・通信断）
- 回帰影響
### 表現
- ログ確認や内部処理を含める
- 技術者が実行可能な粒度
---
## 受け入れテスト項目書（重要）
利用者・業務観点で再構成する
### 必須観点
- ユーザー操作で正しく動くか
- 画面表示が正しいか
- 通知や遷移が期待通りか
- 利用上問題がないか
- 既存機能への影響
### 表現
- 内部ログは禁止
- ユーザー視点で記述
- 判定しやすい結果
---
# 重要制約（最重要）
- Markdownの内容をそのまま転記しない
- 必ず「結合テスト用」「受け入れテスト用」に再設計する
- 不足している観点は補完する
- 追加した項目は備考に「追加提案」と明記する
---
# 整形ルール
- 優先度：P0 / P1 / P2 に統一
- 分類：正常系 / 異常系 / 回帰 に統一
---
# 最終出力
- 完成したExcelファイルを生成すること
- ダウンロード可能な形式で出力すること

品質が低い場合は出力せず、構造を見直してから再生成してください

4. 実行結果

Claude Coworkが以下を自動で実行します。

1. 408408.md を読み込む
2. テストケースの内容を解析する
3. 結合テスト観点で再設計・補完してシート1を作成
4. 受け入れテスト観点で再設計・補完してシート2を作成
5. 408408_テスト項目書.xlsx として保存

生成されるファイル：

~/Documents/test-cases/
  ├── 408408.md                  ← Claude Codeが生成
  └── 408408_テスト項目書.xlsx     ← Claude Coworkが生成

Claude Codeが生成した 408408.md と、Claude Coworkが生成した 408408_テスト項目書.xlsx が同じフォルダに並ぶ

なぜ「そのまま転記しない」が重要なのか

Claude Codeが生成するMarkdownのテストケースは、コード差分に基づく技術寄りの視点で書かれています。

| # | 分類 | テスト項目 | 操作手順 | 期待結果 | 優先度 |
|---|------|-----------|---------|---------|-------|
| 1 | 正常系 | ログインAPIが200を返す | 正しいID/PWを入力しログインボタンタップ | ホーム画面に遷移する | 🔴 P0 |

これをそのままExcelに転記しても、実務では使いにくいものになります。

結合テストでは、このケースに加えて「トークン保存の確認」「ログ出力の確認」「セッション管理」といった内部仕様の観点が必要です。

受け入れテストでは、「ユーザーが正しいIDとパスワードでログインすると、ホーム画面が表示される」のように、技術用語を排除した記述が求められます。

プロンプトに「そのまま転記しない」「再設計する」と明記することで、Claude Coworkは入力のMarkdownを素材として扱い、それぞれのテスト種別にふさわしい形に再構成します。

エージェント連携のポイント

ファイルシステムが接点になる

Claude Code  ──書き出し──▶  ~/Documents/test-cases/408408.md
                                       │
Claude Cowork ◀──読み込み──┘
              ──書き出し──▶  ~/Documents/test-cases/408408_テスト項目書.xlsx

2つのエージェントは直接通信しません。ファイルシステムが共有インターフェースです。

これはシンプルですが、実用上は利点があります。

• Markdownを手動で確認・編集してからCoworkに渡すこともできる
• Claude Code側の出力フォーマットを変えても、Cowork側のプロンプトは影響を受けない
• 途中で止めて、別のツールに渡すことも可能

役割分担が明確

エージェント	役割	得意なこと
Claude Code	コードレビュー・修正・ビルド・テスト項目抽出	ターミナル操作、git、Xcode連携
Claude Cowork	ドキュメント変換・再構成・Excel生成	ファイル操作、ドキュメント整形

1つのエージェントにすべてをやらせるより、得意な領域で分担する方が出力品質が安定します。

Excelの品質が不十分な場合

生成されたExcelを確認して不足があれば、同じ会話内で追加指示を出せます。

結合テスト項目書に「メモリリーク確認」の観点が不足しています。追加してください。

受け入れテスト項目書の操作手順をもう少し具体的にしてください。

Claude Coworkは既存のExcelを更新して再保存します。

まとめ

開発者の操作                             エージェントの動作
───────────────────────────────────────────────────────────
408408 a64d7c776..4a209d66a レビューして → Claude Code: レビュー→修正→ビルド→MD生成
                                              │
                                         408408.md が保存される
                                              │
Coworkでプロンプト入力                    → Claude Cowork: MD読み込み→Excel生成
                                              │
                                         408408_テスト項目書.xlsx が保存される

人間が行うのは2回の指示だけです。

1. Claude Codeに 408408 a64d7c776..4a209d66a レビューして
2. Claude Coworkに「408408.md からテスト項目書を作成して」

コードレビューからExcelのテスト項目書完成まで、2つのエージェントがファイルを介してリレーする形で、一連の品質管理フローを自動化できます。

すべてローカル環境に閉じた運用のため、チームの開発フローに影響を与えず、個人の作業効率化として導入できます。

関連記事

本記事は、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を組み込む