Kotlin・KSP・Compose Compiler を安全に更新する Renovate 設定術(developブランチ運用編)

Jetpack Compose Compiler が Kotlin に強く依存していた時代を経て、
今では少しずつ依存関係が緩やかになってきました。
それでも Kotlin・KSP・Compose Compiler の3つは依然として密接に関係しており、
バージョンのズレひとつでビルドが崩壊するリスクがあります。

この記事では、develop ブランチをメインに運用しつつ、
それらを安全かつ一貫性を保って更新するための Renovate 設定を紹介します。

 

🧩 Kotlin・KSP・Compose Compiler の三位一体更新

Compose Compiler は Kotlin コンパイラと深く結びついて動作するため、
Kotlin のメジャーアップデートが入ると、それに対応した Compose Compiler が必要になります。

さらに、KSP(Kotlin Symbol Processing)も Kotlin バージョンに追随するため、
この3つは基本的に「セットで更新する」のが鉄則です。


{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["config:base"],
  "baseBranches": ["develop"],
  "packageRules": [
    {
      "groupName": "Kotlin, KSP and Compose Compiler",
      "groupSlug": "kotlin",
      "matchPackagePrefixes": [
        "com.google.devtools.ksp",
        "org.jetbrains.compose.compiler"
      ],
      "matchPackagePatterns": [
        "org.jetbrains.kotlin.*"
      ]
    },
    {
      "description": "Do not automerge without CI",
      "matchUpdateTypes": ["minor", "patch", "digest"],
      "automerge": false
    }
  ]
}

 

⚙️ 設定の意図を読み解く

この設定は、単に自動更新を行うだけでなく、
Kotlin 界隈の依存を安全に、かつチームの開発フローに合わせて管理することを意識しています。


baseBranches: ["develop"]

Renovate のデフォルトは main や master に対して PR を作りますが、
実際の開発フローでは「開発用ブランチ(develop)」に更新を入れたいケースが多いですよね。

"baseBranches": ["develop"] を指定しておくことで、
更新 PR が常に develop ブランチに向けて作成されるようになります。

本番リリース前にテストや検証を挟める安全設計です。

 

🔗 groupName: 三つ巴のアップデートを1つにまとめる

groupName は、関連する依存をひとまとめにするためのグループ名。
ここでは "Kotlin, KSP and Compose Compiler" としており、
3つのパッケージを同時に1つの PR にまとめてくれます。


"matchPackagePrefixes": [
  "com.google.devtools.ksp",
  "org.jetbrains.compose.compiler"
],
"matchPackagePatterns": [
  "org.jetbrains.kotlin.*"
]

この指定で次のような依存が同時更新対象になります:


- Kotlin (org.jetbrains.kotlin)

- KSP (com.google.devtools.ksp)

- Compose Compiler (org.jetbrains.compose.compiler)

以前は androidx.compose.compiler でしたが、
現在の Compose Multiplatform では org.jetbrains.compose.compiler に移行しているため、この設定がより正確です。

 

🚫 automerge: false の哲学

Renovate には更新を自動マージする機能がありますが、
Kotlin 系の更新はそれに向きません。

理由は単純で、CI でのビルド確認が欠かせないからです。


{
  "description": "Do not automerge without CI",
  "matchUpdateTypes": ["minor", "patch", "digest"],
  "automerge": false
}

「CI による確認を通らない限り、自動マージさせない」というルールです。

特に Kotlin の minor アップデートでは内部 API が変わることもあり、
Compose Compiler や KSP が対応していない可能性があります。

PR を作成したあと CI を通し、問題なければ手動でマージする。

これが最も安全な流れです。

 

🧭 運用のヒントとまとめ

この設定は、いわば「Kotlin エコシステム用 Renovate セーフティモード」。

自動化の恩恵を受けつつも、壊れやすい依存を慎重に扱うための現実的な妥協点です。

項目 意図
baseBranches 更新PRをdevelop向けにして安全確認を確保
groupName Kotlin / KSP / Compose Compiler を同時に更新
automerge: false CI確認なしでの自動マージを防止
matchPackagePrefixes / matchPackagePatterns 最新の Compose 構成(Compose Multiplatform 等)に対応

 

🪶 まとめ:安全第一の Renovate 運用へ

Renovate は「ただの自動更新ボット」ではなく、
チームのアップデート戦略をコード化できるツールです。

Kotlin、KSP、Compose Compiler のような密接な関係を持つ依存こそ、
グルーピングとマージ制御で慎重に扱うべき対象。

develop ベースで CI を通すこの設定は、
自動化と安全性のバランスを取る最適解のひとつと言えます。

👉 Renovate Docs


Jetpack Compose 1.7+ でクリップボードコピーをどう書く?

 

🧑🏻‍💻 LocalClipboard と suspend 関数の組み合わせ

Compose 1.7 以降では、従来の ClipboardManager が非推奨になり、代わりに LocalClipboard + 非同期コピー が公式に推奨されています。

以下はシンプルなサンプルです。rememberCoroutineScope を使い、クリックイベントで非同期コピーを行っています。


val clipboard = LocalClipboard.current
val scope = rememberCoroutineScope()

Box(modifier = Modifier.clickable {
    scope.launch {
        val clipData = ClipData.newPlainText(uuid, uuid)
        clipboard.setClipEntry(clipData.toClipEntry())
    }
})

👉 Jason Ernst: Android ClipboardManager Deprecated: How to fix

 

🧑🏻‍💻 ViewModel 側でコピー処理をまとめる

世界的に著名な Android 開発者 Chris Banes や Jake Wharton のサンプルコードでは、UI 層から直接 Clipboard を操作せず、ViewModel に処理をまとめる パターンが多く見られます。

このアプローチを取ることで、UI の再コンポーズと Clipboard 操作が分離でき、よりテストしやすい設計になります。


class NoteViewModel : ViewModel() {
  fun copy(block: suspend () -> Unit) {
    viewModelScope.launch {
      block()
    }
  }
}

UI 側では以下のように呼び出せます:


IconButton(
  onClick = { 
    viewModel.copy {
      clipboard.setText(item.text)
    }
  }
) {
  Icon(Icons.Default.ContentCopy, contentDescription = null)
}

Clipboard 拡張関数を定義しておくと便利です。


suspend fun Clipboard.setText(text: String) { 
    val clipData = ClipData.newPlainText(text, text).toClipEntry() 
    setClipEntry(clipData)
}

 

🧑🏻‍💻 まとめ

ClipboardManager は非推奨 → LocalClipboard + suspend が公式推奨。

UI 層はイベントを投げるだけ、コピー処理は ViewModel で完結。

Coroutine scope を ViewModel 内で扱うことで UI の再コンポーズに影響しない。

ViewModel が clipboard を直接握るのは避けたほうがベター。
(非 UI 層に UI 依存を持ち込むことになるため)

拡張関数で共通処理化すれば再利用性が高まる。

つまり、

「UI はシンプルに」「コピー処理は ViewModel に集約」

これが現代的な Compose + Clipboard のベストプラクティスです。


Gradle ビルドキャッシュや KSP キャッシュを消すとき Gradle デーモン止めないと意味がない件

Android 開発をしていると、Git 操作後や依存関係を変更したあとに KSP(Kotlin Symbol Processing)やビルドキャッシュの問題 に遭遇することがあります。


java.lang.IllegalStateException: Storage for [C:\...\symbolLookups\id-to-file.tab] is already registered

この記事では、Gradle デーモンとキャッシュの関係を整理し、「キャッシュを消したのにビルドが直らない」問題 を回避する方法を解説します。

 

🤔 Gradle デーモンとは何か

Gradle はビルドの高速化のために デーモン と呼ばれるバックグラウンドプロセスを使います。

常駐プロセスとして、次回のビルドでキャッシュを再利用

複数プロジェクトやターミナルで同時に動作可能

Android Studio 再起動だけでは停止しない場合がある

デーモン状態の確認方法


./gradlew --status


No Gradle daemons are running

→ デーモン未起動


PID STATUS INFO
3494 IDLE 8.11.1

→ デーモン起動済み、待機中


PID STATUS INFO
3494 BUSY 8.11.1

デーモン停止は以下で可能:


./gradlew --stop

 

🤔 キャッシュを消しても直らない理由

KSP や Gradle のキャッシュを削除しただけでは、既に動作中のデーモンが古いキャッシュ情報を保持している場合があります。

典型的なケース


1. git rebase でコミットを整理

2. KSP が参照する Room の型情報や生成コードが変更

3. Gradle デーモンが古いキャッシュを保持 → ビルド失敗

つまり、キャッシュを消しても、デーモンが古い情報を持っている限り意味がありません。

 

🤔 解決手順まとめ

① Gradle デーモンを止める


./gradlew --stop

すべての Gradle デーモンを終了

次回ビルド時に新しいデーモンが起動

② KSP キャッシュを削除する


rm -rf .ksp/ */build/kspCaches */build/generated/ksp/

KSP が持つ生成キャッシュを完全に削除

再ビルド時に最新のコードから生成される

③ Android Studio のキャッシュをクリア


File → Invalidate Caches / Restart → Invalidate and Restart

IDE 側のキャッシュもクリア

デーモン再起動時に正しい情報を読み込む

④ KSP のインクリメンタルコンパイルを無効化(必要に応じて)

gradle.properties に追加:


ksp.incremental=false

キャッシュ競合によるエラー(例:java.lang.IllegalStateException: Storage for [C:\...\symbolLookups\id-to-file.tab] is already registered)を回避

 

🤔 Git Rebase 後の KSP ビルドフロー


Git Rebase
    ↓
ソースコード変更
    ↓
KSP キャッシュ古いまま
    ↓ (Gradle デーモン生きている場合)
ビルド失敗 → Storage already registered など
    ↓
./gradlew --stop でデーモン停止
    ↓
KSP キャッシュ削除
    ↓
再ビルド
    ↓
成功

 

🤔 まとめ

Gradle デーモンは Android Studio 再起動だけでは必ずしも止まらない

KSP やビルドキャッシュを消すときは必ずデーモンを止める

典型的な手順:


./gradlew --stop

rm -rf .ksp/ */build/kspCaches */build/generated/ksp/

Android Studio キャッシュクリア

ビルド再実行

これで Git 操作後や依存関係変更後のビルド失敗を防げる

Gradle デーモンの挙動を理解しておくと、「キャッシュ消したのに直らない」問題 に悩まされずに済みます。

ビルド高速化の恩恵を受けつつ、必要なときにはデーモンを適切に制御しましょう。

android - java.lang.IllegalStateException: Storage for [C:\...\symbolLookups\id-to-file.tab] is already registered - Stack Overflow


【macOS】「Toggle Sticky Selection」を設定したい!

JetBrains系IDE(Android Studio、IntelliJ IDEA、PyCharm、WebStorm など)では、「Sticky Selection(固定選択)」という便利なモードがあります。これは、カーソルを移動するだけでテキスト選択を継続できるモードで、範囲選択を効率化できます。

通常は「Toggle Sticky Selection」にショートカットを割り当てて使いますが、デフォルトでは設定されていないため、手動でキーを割り当てる必要があります。たとえば、筆者は Control + Space に割り当てようとしました。しかし、ここで問題が発生しました。

 

🤔 Control + Space を設定しようとすると、IMEが切り替わってしまう

ショートカット設定画面で「Toggle Sticky Selection」に Control + Space を登録しようとすると、なぜか入力欄が反応せず、MacのIME(日本語入力)が英語に切り替わってしまいます。

つまり、IDEのエディタがそのキー入力をキャッチする前に、macOSのシステムが先に反応してしまっているのです。

これは macOS のデフォルト設定で、Control + Space は「入力ソースの切り替え」に使われているからです。Macで複数の言語(たとえば日本語と英語)を切り替えている人にはおなじみのショートカットですね。

このままでは、IDEエディタ側でショートカット登録ができません。そこで、macOS側の設定を変更する必要があります。

 

🤔 macOSのショートカット設定を変更して回避する

macOS のシステム環境設定から、ショートカットの競合を解消しましょう。


1.「システム設定」アプリを開く

2. サイドバーから 「キーボード」 を選択

3. 右側にある 「キーボードショートカット…」 をクリック

4. サイドメニューから 「入力ソース」 を選択

5. 「前の入力ソースを選択」 に割り当てられている ^ スペース(Control + Space) をクリック

表示されたチェックを外す、もしくは他のショートカットに変更

これで macOS 側が Control + Space を使わなくなるため、IDE側の設定画面で正しくこのキーを登録できるようになります。

 

🤔 無事にショートカット登録が可能に!あとは設定するだけ

macOS 側の干渉がなくなれば、IDE側の設定画面で Control + Space を「Toggle Sticky Selection」に自由に割り当てられるようになります。


1. IDE の「設定(Preferences)」を開く

2. Keymap(キーマップ) を選択

3. 検索バーに「Sticky Selection」と入力

4. 「Toggle Sticky Selection」を右クリック → Add Keyboard Shortcut

5. Control + Space を入力 → OK

設定後、エディタ上で Control + Space を押すと Sticky Selection モードに入り、矢印キーなどでカーソルを動かすたびに選択範囲が伸びていくことを確認できます。

 

🧑🏻‍💻 まとめ:macOSの干渉を避ければ自由にカスタムできる

Control + Space は便利なショートカットですが、macOS のデフォルト設定でIME切り替えに使われているため、IDEのエディタではそのままでは登録できません。

しかし、macOS の「キーボードショートカット」設定から「入力ソースの切り替え」を無効化または変更すれば、競合を回避できます。

この一手間を加えることで、自分の作業スタイルにあったショートカット環境が整います。エディタをもっと快適に使うためにも、こうした細かい調整はぜひ試してみてください 🎉


【AppleCare に未加入】クレカ付帯の保険でiPhone画面ひび割れをAppleで5000円で修復する方法

iPhoneの画面をうっかり割ってしまったとき、高額な修理代にため息をついたことはありませんか?実は、クレジットカードに付帯している保険を活用すれば、Appleの正規修理でも実質5000円で済むことがあります。

この記事では、「クレカの保険でiPhone画面をお得に修理する方法」について、仕組み・対応カード・実際の流れを解説します。

 

🤔 これで私も、実質19400円 → 5000円 となりました。

手が滑って画面がひび割れてしまった iPhone が、

Apple 作業にて、実質支払5000円で復活。

 

🤔 スマホの画面割れは「クレカの保険」でカバーできる

多くのクレジットカードには「ショッピング保険」や「スマートフォン保険」が付帯しており、購入後一定期間内の破損や盗難などを補償してくれます。中でも注目すべきは、アメリカン・エキスプレス(AMEX)のスマートフォン・プロテクションです。


🔹 AMEXスマートフォン・プロテクションの主な特徴

対象機種          購入後36ヶ月以内のスマートフォン
補償額	        年間最大5万円(自己負担5,000円)
対象となる損害	破損、火災、水濡れ、盗難
条件             スマホの通信料をAMEXカードで3ヶ月以上連続して支払っていること
対象カード        AMEXゴールド・プラチナ・ANAプレミアムなど

この保険を利用すれば、Apple公式で修理しても5,000円の自己負担で済み、残りはAMEXが補償してくれます。たとえば、iPhoneの画面修理に30,000円かかったとしても、あなたの負担は5,000円で済むというわけです。

 

🤔 他にも使える「ショッピング保険付きクレカ」とその条件

スマートフォン・プロテクション以外にも、ショッピング保険があるクレカで補償できる場合があります。ポイントは、「スマホをそのカードで購入したかどうか」と「支払方法(リボ・分割など)」です。

以下は代表的なクレジットカードと補償内容の比較です:


カード名                  補償条件         年間補償額  自己負担額  備考
JCBゴールド               90日以内の購入品  500万円    3,000円    通常の支払いOK
三井住友カード(ゴールドNL) リボ・分割払いのみ 300万円    3,000円    一括払いは対象外
楽天プレミアムカード        購入90日以内     300万円    3,000円    通常カードは対象外
エポスゴールドカード        90日以内         300万円   3,000円    招待で年会費無料も可能

注意点
購入日から90日以内であることが多い

修理費を出しても実際に補償されるのは“クレカで払った分の修理”

キャリア一括払いやApple Store以外の購入は対象外になることもある

 

🤔 実際の流れ:iPhoneの画面割れを5000円で修理するまで

では、実際にAMEXのスマートフォン・プロテクションを使って修理する手順をまとめます。


🔧 ステップ①:AMEXの補償条件を満たしているか確認

  - iPhone購入から36ヶ月以内
  - 通信料をAMEXカードで3ヶ月以上支払っている
  - AMEX対象カードを持っている(ゴールドやプラチナ等)


🔧 ステップ②:Apple公式で修理(または正規修理プロバイダ)

  - Apple StoreまたはApple正規サービスプロバイダで画面修理を行う
  - 修理費の領収書を保管


🔧 ステップ③:AMEXに保険金請求

  以下のものを用意し、所定のフォームから申請します:

  - 修理の領収書 or 見積書
  - 損害の状況を記載した説明書
  - 通信料のAMEXカード支払い履歴
  -(盗難時)警察の届け出番号

申請が認められると、AMEXから修理費用のうち5,000円を超えた分が口座に振り込まれます。

 

🤔 まとめ:クレカ保険を知っていれば、画面割れも怖くない

iPhoneの画面が割れたとき、修理費が高くて悩む人は多いですが、クレカの保険を知っていれば5,000円で済む可能性が十分にあります。

特にAMEXスマートフォン・プロテクションは、通信料支払いという条件さえ満たせば、iPhoneを購入してから3年間はいつでも補償が受けられる強力なサービスです。

AppleCare+に入っていない人でも、AMEXカードを持っていれば安心して修理できます。これを機に、あなたのクレカに保険が付いているか、ぜひ一度確認してみてください。

👉 スマートフォン・プロテクション | クレジットカードはアメリカン・エキスプレス(アメックス)