概要

OSやライブラリなどのメジャーアップデートに伴い、広範なコード修正が必要となる場面があります。本記事では、DeepResearchとNotebook LMで変更点を整理し、CursorのProject Rulesを通じてAIエージェントに効率的に伝える方法を紹介します。

流れ

DeepResearchでライブラリの差分を取得
Notebook LMにリソースを集約し、情報を精査
CursorのProject Rulesに明文化してコンテキストを定義
エージェントにルールを元にした修正指示を出す

1. Gemini DeepResearchで新旧バージョンにおける変更点を取得

DeepResearchは、新旧ライブラリバージョンにおける変更点などを効率的に情報収集できるツールです。

主な活用内容：

GitHubリポジトリのドキュメントやChangelogの自動比較
削除・非推奨API、引数変更の検出

これにより、調査段階での情報の取りこぼしを防ぎ、変更点を俯瞰できます。

2. Notebook LMにリソースを集約

DeepResearchで出力した差分情報に加え、以下の関連リソースを Notebook LMに追加しました：

公式ドキュメントの該当セクション
既存コードベースの使用箇所サンプル
GitHub Issue やブログ記事などの参考情報
動画やPDF、登壇資料などの情報

Notebook LMに集約することで、情報の横断検索が容易になり、判断の根拠を素早く確認できます。

3. CursorのProject Rulesで変更方針を明文化

Cursorでは、プロジェクトごとの修正方針を Project Rules として記述できます。

Cursor 0.4.5の新機能：Project Rulesの使い方 #AI - Qiita

ここにNotebook LMで整理して作成した内容をルールとして反映し、エージェントに正確な文脈を伝える準備を整えます。

例

# Rule: 移行 - Android APIレベル35対応

## 概要

Android API レベル 35（Android 15）への移行作業の際に守るべき変更のルールを以下にまとめます。

---

## 必須設定

- **compileSdk を 35 に設定する** アプリの `build.gradle` または `build.gradle.kts` ファイルで、`android { compileSdk = 35 }` のように設定する必要があります。
- **targetSdk を 35 に設定する** アプリの `build.gradle` または `build.gradle.kts` ファイルの `android { defaultConfig { targetSdk = 35 } }` のように設定することで、Android 15 の動作変更がアプリに適用されます。
- **Android Gradle Plugin (AGP) を 8.6.1 以降にアップグレードする** プロジェクトで古い AGP を使用している場合は、Android Gradle プラグイン Upgrade Assistant を実行して、少なくとも AGP 8.6.1 にアップグレードしてください。
- **Android 15 SDK をインストールする** Android Studio の SDK Manager を使用して、Android 15 SDK をインストールしてください。具体的には、[Tools] > [SDK Manager] をクリックし、[SDK Platforms] タブで [Android API 35] を選択し、[SDK Tools] タブで最新の [Android SDK Build-Tools 35] を選択します。

---

## フォアグラウンドサービスの変更に対応する

- `dataSync` タイプのフォアグラウンドサービスは、24 時間あたり合計 6 時間の実行時間制限が設けられます。
- メディアファイルのトランスコーディングなどの操作には、新しい `mediaProcessing` タイプのフォアグラウンドサービスを使用します。これも 6 時間のタイムアウト制限があります。
- `BOOT_COMPLETED` ブロードキャストレシーバーは、特定のフォアグラウンドサービス（`dataSync`, `camera`, `mediaPlayback`, `phoneCall`, `mediaProjection`, `microphone`）を起動することが制限されます。
- `SYSTEM_ALERT_WINDOW` 権限を持つアプリは、可視のオーバーレイウィンドウを持っている場合にのみ、バックグラウンドからフォアグラウンドサービスを開始できます。

---

## Do Not Disturb (DND) モードのグローバル状態を直接変更しない

API レベル 35 をターゲットとするアプリは、デバイスの DND モードのグローバル状態やポリシーを直接変更できなくなります。代わりに `AutomaticZenRule` を使用する必要があります。

---

## OpenJDK API の変更点に対応する

- `String.format()` および `Formatter.format()` API における引数の検証がより厳密になりました。
- `Arrays.asList(...).toArray()` の結果の配列のコンポーネントタイプは `Object` になります。
- `Locale API` において、特定の言語コードの処理が変更されました。ISO 639-1 コードを使用する必要があります。
- `Random.ints()` メソッドの返す数値シーケンスが変更されました。
- `SequencedCollection API` 関連で潜在的な衝突が発生する可能性があります。

---

## セキュリティ関連の変更に対応する

- TLS バージョン 1.0 および 1.1 の使用は許可されません。
- バックグラウンドアプリによるアクティビティの起動に関する制限が強化されました。`PendingIntent` の作成者はデフォルトでバックグラウンドアクティビティの起動をブロックします。
- インテントのセキュリティ対策が強化されました。特定のコンポーネントをターゲットとするインテントは、ターゲットのインテントフィルタと正確に一致する必要があります。アクションのないインテントは、どのインテントフィルタにも一致しなくなります。

---

## ユーザーエクスペリエンスとシステム UI の変更に対応する

- **エッジツーエッジが強制適用されます** `targetSdk` を 35 に設定すると、Android 15 以降のデバイスでアプリはデフォルトでエッジツーエッジで描画されます。コンテンツがステータスバーとナビゲーションバーの下に描画されるため、必要に応じて `WindowInsets` を使用してコンテンツがシステムバーに隠れないように調整する必要があります。以前の `android:windowLayoutInDisplayCutoutMode` 属性は無視されます。`R.attr#windowOptOutEdgeToEdgeEnforcement` を `true` に設定することで一時的にオプトアウトできますが、これは将来廃止されます。
- `Configuration` クラスは、画面の寸法を報告する際にシステムバーを除外しません。レイアウト計算には、`ViewGroup`, `WindowInsets`, `WindowMetricsCalculator` などの代替手段を使用する必要があります。
- `TextView` の `elegantTextHeight` 属性のデフォルト値が `true` になります。
- `TextView` は、複雑な文字形状に対応するために、より多くの幅を割り当てるようになります。
- `EditText` には、指定されたロケールの参照フォントに合わせて最小行の高さが予約されるようになります。

---

## カメラとメディアの変更に対応する

音声フォーカスをリクエストするには、アプリが最上位のアプリであるか、フォアグラウンドサービスを実行している必要があります。

---

## 非 SDK インターフェースの制限の更新を確認する

制限された非 SDK インターフェースのリストが更新されているため、パブリック SDK の代替手段に移行する必要があります。

---

## アプリを Android 15 デバイスまたはエミュレーターで徹底的にテストする

動作変更やレイアウト崩れがないか確認してください。特にエッジツーエッジによる UI の影響は注意が必要です。

---

## 非推奨 API の使用に対処する

Android Studio が警告を表示する可能性があるので、推奨される代替 API に移行してください。

ルールが具体的であるほど、エージェントの出力も正確になります。

4. Cursorエージェントで修正指示を出す

Project Rulesを有効にした状態で、Cursor上で以下のようなプロンプトを使って修正作業を行いました：

「このファイルで新しい書き方に書き換えてください」

ルールが明文化されているため、都度背景を説明せずに済み、短いプロンプトでも適切な出力が得られます。

効果

チームでルールを共有できる
変更内容の収集と整理が短時間で完了
エージェントへの指示がルールベースで一貫
長いプロンプトや逐次的な試行錯誤が不要に

特に Cursorにおいて、明文化されたルールでエージェントに文脈を効率よく伝達できたことで作業のスピードと精度を大きく高めました。

まとめ

今回の対応では、以下の3ステップがポイントでした：

DeepResearchで変更差分を可視化
Notebook LMで情報を整理・強化
CursorのProject Rulesでルールを明文化し、エージェントに伝える

このように、ツールごとに役割を分けて活用することで、複雑なアップデート対応もスムーズに進行できます。