【第5弾】Claude Codeが「そのAPI、非推奨ですよ」と教えてくれる ― Redmine連携フローにContext7を組み込む

この記事は、AIエージェントを段階的に構築していくシリーズの第5弾です。
第5弾では、レビュー前にContext7の利用要否を自動判定するステップを追加し、外部ライブラリやSDKに関わる変更を公式ドキュメントベースで検証できるようにします。
これまでの記事を順に読むことで、レビュー、修正、テスト項目作成、試験項目書化、チケット連携、そしてドキュメント検証までを段階的に理解できます。

第4弾はこちら：
【第4弾】Claude Code × Redmine × Claude Coworkで、チケット確認からExcel試験項目書作成まで自動化する

はじめに

前回の記事では、Claude Code × Redmine × Claude Coworkを組み合わせて、チケット確認からExcel試験項目書作成・Slack通知までを自動化する方法を紹介しました。

今回はその発展版です。

前回までのレビューは、コード差分とRedmineのチケット情報を元に判断していました。しかし、外部ライブラリやSDKのバージョン更新・API変更が絡む差分では、公式ドキュメントを確認しないと正しいレビューができない場面があります。

たとえば、Swift PackageのメジャーバージョンアップでAPIが非推奨になっていたり、SDKの初期化方法が変更されていたりするケースです。こうした変更をコード差分だけで判断すると、「コードとしては動くが、推奨されていない実装」を見逃す可能性があります。

本記事では、レビュー開始前にContext7の利用要否を自動判定するステップを追加します。外部依存に関わる変更が含まれる場合のみContext7で公式ドキュメントを参照し、そうでない場合はスキップして無駄なAPI呼び出しを避けます。

Claude Code（Context7判定 → Redmine確認 → レビュー → 修正 → ビルド → テスト項目/レポート/受け入れ基準MD生成 → Slack通知）
  │
  │  Context7（要利用の場合のみ、公式ドキュメント確認）
  │  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シート構成）

ポイントは、Context7の利用を常に行うのではなく、差分の内容に応じて判定することです。文言修正やUI調整だけの差分にまでContext7を使うのは過剰であり、レビュー時間の増加やAPIコストの無駄につながります。判定ステップを設けることで、必要なときだけ公式ドキュメントを参照する運用になります。

Context7とは

Context7は、ライブラリやフレームワークの公式ドキュメントをMCP経由で参照できるツールです。Claude Codeと連携することで、レビュー中に「このAPIの使い方は公式ドキュメントに沿っているか」を確認できます。

たとえば、FirebaseのSDKを更新した差分があった場合、Context7を通じてFirebase公式ドキュメントから最新のAPI仕様を取得し、実装が正しいかを検証できます。

Context7のセットアップ方法については、Context7の公式ドキュメントを参照してください。本記事ではClaude CodeからMCP経由でContext7に接続済みであることを前提とします。

前提条件

項目	条件
前回記事の環境	Claude Code × Redmine × Slack × Claude Coworkが動作する状態
Context7 MCP連携	Claude CodeからContext7にMCP経由で接続済み
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 にContext7利用要否判定のステップを追加します。差分レビュー（Step 2）の前に判定を行い、結果に応じてContext7を使い分ける構成です。

⚠️ 以下の 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: Context7 利用要否判定
差分レビューを開始する前に、まず「この差分が Context7 を使うべき対象か」を判定すること。

### 判定ルール
以下のいずれかに該当する場合は、Context7 を利用すること。
- 外部ライブラリ、SDK、Swift Package、ツールチェーンに関わる変更が含まれる
- ライブラリの import、初期化、設定、依存関係に変更がある
- API変更、非推奨化、削除の可能性がある
- ビルドエラーや警告の原因がライブラリ仕様変更の可能性がある
- 実装方法の正しさを公式ドキュメントで確認しないと危険な変更である
- 差分に package 更新、SDK 更新、設定ファイル変更が含まれる

以下のみで構成される差分は、原則として Context7 を使わなくてよい。
- 文言修正
- コメント修正
- ローカル変数名や関数名の単純なリネーム
- 既存ロジックを変えない軽微な整形
- 社内固有ロジックのみの修正
- 画面文言、定数値、表示順などの軽微な変更
- テストデータやモックの軽微な修正
- 外部ライブラリやSDKに影響しないUI調整

### 判定手順
1. 差分を見て、外部ライブラリ・SDK・Swift Package・ツールチェーンへの依存有無を判定する
2. Context7 利用要否を「要利用」または「不要」で明記する
3. 「要利用」の場合のみ Context7 を使って根拠確認を行う
4. 「不要」の場合は Context7 を使わず、そのままレビューと修正を進める

### 出力形式

#### Context7利用判定
- 判定: 要利用 / 不要
- 理由: 1〜3行で簡潔に記載

#### Context7確認結果
※ 要利用の場合のみ記載
- 確認対象
- 確認内容
- 修正根拠

## Step 3: コードレビュー
- $ARGUMENTS のコミット範囲の差分を取得し、以下の必須チェック観点で必ず全てチェックしてレビューする
- Step 1 で取得したチケットの目的・受け入れ条件と照らし合わせてレビューする
- Step 2 で Context7 を利用した場合は、その確認結果もレビューの根拠に含める
- 入力に存在しない事実を前置しない
- 不明な項目は「未確認」、推測は「(推測です)」と明記する

### 必須チェック観点
以下の観点を全てチェックし、各観点について「該当なし」の場合も「該当なし」と明記すること。
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 対応への影響
11. **外部ライブラリ準拠**: Step 2 の Context7 確認結果がある場合、公式仕様に準拠しているか

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

## Step 4: コード修正
- 🔴 重大 または 🟠 高 の問題について修正を実施する
- 元のコード意図を尊重し、最小限の変更にする
- Step 2 で Context7 確認結果がある場合は、公式ドキュメントに準拠した修正を行う
- 修正内容を日本語で報告する

## Step 5: ビルド確認
- Xcodeでビルドを実行する
- ビルドエラーがあれば修正を試み、再度ビルドする
- **ビルド試行は最大3回まで**。3回失敗した場合は以下を報告して次のStepに進む：
  - 最後のエラーメッセージ全文
  - 試した修正内容の履歴
  - 推測される原因（「(推測です)」と明記）
  - 人間によるデバッグが必要である旨
- 最終的なビルド結果を報告する

## Step 6: テスト項目作成
改修内容およびStep 1のチケット情報に基づき、以下の観点でテストケースを作成する：

### 正常系
- 改修で追加・変更された機能が期待通り動作するケース
- チケットの受け入れ条件を満たすケース

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

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

### 外部依存テスト（Step 2 で「要利用」の場合のみ追加）
- 外部ライブラリ・SDKのバージョン更新に伴う互換性確認ケース
- API仕様変更による影響範囲のケース

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

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

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

## Step 7: 受け入れ基準の作成
Step 1 のチケット情報と Step 3 のコード差分に基づき、このチケットの受け入れ基準を作成する。

### 作成ルール
- チケットに既存の受け入れ基準がある場合は、それをベースに不足分を補完する
- 既存の受け入れ基準がない場合は、新規に作成する
- 実装内容から確認すべき動作条件を箇条書きで列挙する
- 技術的な補足が必要な項目には「Note:」を付記する
- 確認方法が未確定の項目には「[TBD]」を付記する
- Redmineのチケットにそのまま貼り付けられる形式で出力する

### 観点
- 改修で追加・変更された機能が正しく動作すること
- アプリの状態別（フォアグラウンド／バックグラウンド／プロセス無し）の動作
- 既存ユーザーへの影響（アップデート時の挙動）
- 異常系での動作（通信断、不正値など）
- 既存機能への回帰影響

## Step 8: 最終レポート
以下の構成で最終結果をMarkdownとしてまとめる：

- 見出し「最終レポート」
- セクション「チケット情報」: チケット番号、タイトル、コミット範囲
- セクション「Context7利用判定」: 判定結果と理由、確認結果（要利用の場合）
- セクション「レビュー結果」: 以下の表形式で出力する

  | # | リスク | 観点カテゴリ | ファイル:行 | 問題内容 | 推奨対応 | 修正実施 |
  |---|--------|------------|-----------|---------|---------|---------|

  - 「観点カテゴリ」は Step 3 の必須チェック観点(1〜11)のいずれかを記載する
  - 「修正実施」は ✅ / ❌ / - (対象外)で記載する
  - 問題が1件もない場合は表の代わりに「該当なし」と明記する

- セクション「実施した修正」: 修正内容の一覧（Before/After のコード差分を含む）
- セクション「ビルド結果」: ✅ 成功 / ❌ 失敗（失敗の場合は最後のエラーメッセージを併記）
- セクション「残課題」: あれば記載、なければ「なし」と明記

## Step 9: テスト項目をファイルに保存
- Step 6 で作成したテストケースをMarkdownファイルとして保存する
- Step 1 で特定したチケット番号を使用する
- チケット番号が見つからなかった場合は test-cases-YYYYMMDD-HHmmss をフォルダ名・ファイル名にする
- 保存先: ~/Documents/test-cases/{チケット番号}/
- ファイル名: {チケット番号}.md（例: ~/Documents/test-cases/408408/408408.md）
- 同名ファイルが既に存在する場合は {チケット番号}-YYYYMMDD-HHmmss.md にする
- 保存先ディレクトリが存在しない場合は `mkdir -p` で作成する
- ファイルの冒頭にチケット番号とコミット範囲を記載する
- 保存完了後、ファイルの絶対パスを報告する

## Step 10: 最終レポートをファイルに保存
- Step 8 で構成した最終レポートを別ファイルとして保存する
- 保存先: ~/Documents/test-cases/{チケット番号}/
- ファイル名: {チケット番号}_レポート.md（例: ~/Documents/test-cases/408408/408408_レポート.md）
- 同名ファイルが既に存在する場合は {チケット番号}_レポート-YYYYMMDD-HHmmss.md にする
- 保存完了後、ファイルの絶対パスを報告する

## Step 11: 受け入れ基準をファイルに保存
- Step 7 で作成した受け入れ基準を別ファイルとして保存する
- 保存先: ~/Documents/test-cases/{チケット番号}/
- ファイル名: {チケット番号}_受け入れ基準.md（例: ~/Documents/test-cases/408408/408408_受け入れ基準.md）
- 同名ファイルが既に存在する場合は {チケット番号}_受け入れ基準-YYYYMMDD-HHmmss.md にする
- 保存完了後、ファイルの絶対パスを報告する
- 「内容を確認の上、Redmineのチケットに貼り付けてください」と案内する

## Step 12: Slackへの完了通知
- MCP経由でSlackに以下のメッセージを送信する
- 送信先チャンネルID: D3225KYB1
- メッセージ形式:

<{RedmineのベースURL}/issues/{チケット番号}|#{チケット番号}「{チケットタイトル}」> のレビューが完了しました。

成果物:
• {チケット番号}.md（テスト項目）
• {チケット番号}_レポート.md（最終レポート）
• {チケット番号}_受け入れ基準.md（受け入れ基準）

- RedmineのベースURLは Step 1 でチケット情報を取得した際のURLから組み立てる
- チケット番号・タイトルは Step 1 で取得した情報を使用する
- 取得できなかった項目は省略し、取得できた情報のみで構成する
- 送信完了後、送信先と送信内容を報告する
- 送信に失敗した場合は「Slack通知の送信に失敗しました」と報告し、手動での通知を案内する
EOF

前回からの変更点

変更箇所	内容
Step 2（新規）	Context7利用要否を差分内容に基づいて自動判定
Step 3（旧Step 2）	Context7確認結果をレビューの根拠に含めるように変更
Step 4（旧Step 3）	Context7確認結果がある場合は公式ドキュメント準拠の修正を行うように変更
Step 6（旧Step 5）	外部依存テストの観点を追加（Context7が要利用の場合のみ）
Step 8（旧Step 7）	最終レポートにContext7利用判定セクションを追加
Step 9〜12（旧Step 8〜11）	ステップ番号の繰り下げ（内容は同一）

Step 2 で判定した結果は、Step 3のレビュー、Step 4の修正、Step 6のテスト項目作成、Step 8の最終レポートに反映されます。

差分を取得
  ↓
外部ライブラリ・SDK・Swift Packageの変更あり？
  ├── あり → Context7で公式ドキュメント確認 → 結果をレビューに反映
  └── なし → Context7スキップ → そのままレビュー

2. 実行例

実行方法は前回と同じです。Context7の利用判定はClaude Codeが差分を見て自動的に行うため、追加の引数は不要です。

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

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

実行すると、Step 2 で以下のような判定結果が出力されます。

外部ライブラリの変更が含まれる場合：

#### Context7利用判定
- 判定: 要利用
- 理由: Package.resolved の更新と FirebaseAnalytics の import 追加が含まれるため、SDK仕様の確認が必要

#### Context7確認結果
- 確認対象: firebase-ios-sdk 10.x → 11.x
- 確認内容: Analytics.logEvent() のパラメータ仕様変更の有無
- 修正根拠: 公式ドキュメントでパラメータ型が Dictionary<String, Any> のまま変更なしを確認

文言修正のみの場合：

#### Context7利用判定
- 判定: 不要
- 理由: 画面文言の修正のみで、外部ライブラリやSDKへの依存変更なし

3. Claude Coworkの操作

Claude Coworkの起動、作業フォルダの指定、プロンプトの投入は前回と同じ手順です。Context7の判定結果は最終レポート（408408_レポート.md）に含まれるため、Claude Coworkはその情報もテスト項目書の生成に活用します。

Context7 判定で何が変わるのか

前回の記事では、すべての差分に対して同じレビュー手順を適用していました。Context7の利用要否判定を追加したことで、レビューの精度とコストのバランスが改善されます。

外部ライブラリの変更がある場合：Context7で公式ドキュメントを参照し、APIの非推奨化や仕様変更を確認した上でレビューします。「コードとしては動くが、次のバージョンで削除されるAPI」といった問題を検出できます。

外部ライブラリの変更がない場合：Context7の呼び出しをスキップし、レビュー時間とAPIコストを節約します。文言修正にまで公式ドキュメントを参照する必要はありません。

テスト項目への反映：Context7が「要利用」と判定された場合、テスト項目に「外部依存テスト」の観点が自動で追加されます。SDKバージョン更新による互換性確認など、外部依存に特有のテストケースが生成されます。

前回（全差分に同一手順）
  Redmine + git diff → レビュー → テスト項目 + 受け入れ基準 → Slack通知

今回（Context7判定あり）
  git diff → Context7要否判定
    ├── 要利用 → Context7で公式ドキュメント確認
    └── 不要 → スキップ
                ↓
  Redmine + git diff + Context7結果 → レビュー → テスト項目 + 受け入れ基準 → Slack通知

なぜ「常に使う」ではなく「判定する」のか

Context7はMCP経由で外部APIを呼び出すため、利用にはコストと時間がかかります。すべての差分に対してContext7を使うと、以下の問題が発生します。

レビュー時間の増加：文言修正だけの差分でもContext7の応答を待つことになり、レビュー全体が遅くなります。

不要な情報の混入：外部ライブラリと無関係な差分に対してContext7が返す情報は、レビューのノイズになります。

APIコストの無駄：Context7の呼び出し回数が増えるほど、コストが積み上がります。

判定ルールを明示的に定義することで、Claude Codeは「この差分にContext7が必要かどうか」を差分の内容から自律的に判断します。判定結果と理由が出力に含まれるため、人間が判断の妥当性を確認することもできます。

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

前回からの変更

                        Context7 ◀──MCP経由──（要利用の場合のみ）
                                                │
Redmine ◀──MCP経由──  Claude Code ◀─────────────┘
                        │
                        ├──書き出し──▶  408408.md（テスト項目）
                        ├──書き出し──▶  408408_レポート.md（最終レポート）※ Context7判定結果含む
                        ├──書き出し──▶  408408_受け入れ基準.md（受け入れ基準）
                        │                           │
                        ├──MCP経由──▶  Slack チャンネル（完了通知 + チケットURLリンク）
                        │                           │
                        │              Claude Cowork ◀──読み込み──┘
                        │              ──書き出し──▶  408408_テスト項目書.xlsx

Context7との通信はMCP経由で行われます。Step 2の判定で「不要」となった場合はContext7への通信自体が発生しません。ファイルシステムやSlackとの連携は前回と同じです。

判定結果の活用先

Step 2の判定結果	影響するステップ
要利用	Step 3: Context7確認結果をレビュー根拠に追加
要利用	Step 4: 公式ドキュメント準拠の修正を実施
要利用	Step 6: 外部依存テスト観点をテスト項目に追加
要利用	Step 8: 最終レポートにContext7確認結果を記載
不要	上記のステップでContext7関連の記載なし

さらに効率化するには

Context7の判定を上書きしたい場合

自動判定の結果に関わらず、Context7の利用を強制したい場合は、引数にキーワードを追加する運用も可能です。たとえば、Step 2の判定ルールに以下を追記します。

- $ARGUMENTS に「context7」「c7」が含まれている場合は、判定に関わらず Context7 を利用する

これにより、以下のように実行できます。

# Context7の利用を強制
408408 a64d7c776..4a209d66a c7 レビューして

判定ルールをプロジェクトに合わせてカスタマイズする場合

判定ルールの「Context7を利用する条件」「利用しなくてよい条件」は、プロジェクトの特性に合わせて調整してください。

たとえば、特定のライブラリ（例：Alamofire、Realm）が頻繁に更新されるプロジェクトでは、それらの import が差分に含まれるだけでContext7を利用する条件を追加できます。

- Alamofire、Realm、Firebase のいずれかに関わる変更が含まれる場合は、バージョン更新の有無に関わらず Context7 を利用する

まとめ

開発者の操作                             エージェントの動作
───────────────────────────────────────────────────────────
408408 a64d7c776..4a209d66a レビューして → Claude Code: Context7判定→Redmine確認→レビュー→修正→ビルド→MD生成
                                              │
                                         Context7判定: 要利用 / 不要（差分内容で自動判定）
                                              │
                                         408408/408408.md（テスト項目）
                                         408408/408408_レポート.md（最終レポート）
                                         408408/408408_受け入れ基準.md（受け入れ基準）
                                              │
                                         Slack チャンネルにリンク付き完了通知 + 成果物一覧
                                              │
受け入れ基準を確認 → Redmineに貼付         （人間が確認する唯一のポイント）
                                              │
Coworkでプロンプト入力                    → Claude Cowork: MD読み込み→Excel生成
                                              │
                                         408408/408408_テスト項目書.xlsx

人間が行う操作は前回と同じ3つです。Context7の利用判定はClaude Codeが自動で行うため、追加の操作はありません。

1. Claude Codeに 408408 a64d7c776..4a209d66a レビューして
2. 受け入れ基準ファイルを確認し、Redmineのチケットに貼り付ける
3. Claude Coworkに作業フォルダを指定してプロンプトを入力

今回追加したContext7利用要否判定により、外部ライブラリやSDKの変更が含まれる差分では公式ドキュメントに基づいた精度の高いレビューが行われ、それ以外の差分では不要な処理をスキップして効率的にレビューが完了します。

判定結果は最終レポートに記録されるため、レビューの根拠としてチーム内で共有・確認できます。

関連記事

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