Gradle KTS — その概要、Gradle向けKotlin DSLと構文

Gradle KTSとは？

Gradle KTSは、Gradle設定ファイルを記述するためのGroovyに代わるKotlin DSL（ドメイン特化言語）です。Groovy構文の代わりに、開発者はKotlinを使用します。Kotlinは、コンパイル時に設定の正確性を検証する厳密に型付けされた言語です。KTSは2018年にGradle 5.0で実験的機能として初めて導入され、Gradle 6.0で安定版となりました。

KTSの主な目的は、ビルドスクリプトにおけるGroovyの欠点を排除することです。Groovyは動的型付け言語であり、設定エラーはタスク実行時のランタイムでのみ現れます。KTSは、Kotlinの静的型付けにより、コード編集段階で同じエラーを検出できます。さらに、KTSは完全な型ドキュメントとともにGradle APIへのアクセスを提供し、複雑な設定ブロックの学習と使用を大幅に簡素化します。

KTSエコシステムは、すべての主要ツールでサポートされています：Android Studio、IntelliJ IDEA、Kotlinプラグイン付きVS Code、Gradle Build Tool。すべての最新プラグイン（Android Gradle Plugin、Kotlin Multiplatform、Protobuf、Compose）は、明示的な型を持つKotlin対応APIを提供しており、KTSは新規プロジェクトの推奨選択肢となっています。

Gradle KTSの仕組み

Gradle KTSはKotlinコンパイラを使用して.gradle.ktsファイルを処理します。Gradleは拡張子を認識し、スクリプトをKotlinスクリプティングエンジンに渡し、クラスにコンパイルします。これらのクラスは、プロジェクトモデルを構築するためにGradleによって実行されます。Groovyとの主な違い：KTSスクリプトは事前にコンパイルされ、動的に解釈されないため、タスク実行開始前にエラーを検出できます。

KTSアーキテクチャはkotlin-scriptingに基づいています。各.gradle.ktsファイルは、Gradle APIの暗黙的なインポートを持つKotlinスクリプトです。開発者は、拡張関数、ラムダ、データクラスなど、任意のKotlin構文を使用でき、ビルドスクリプト内でヘルパー関数を宣言することもできます。Gradleは、dependencies、android、kotlinなどのブロックの型付き設定のための拡張関数セットを提供します。

plugins {
    id("com.android.application") version "8.4.0"
    kotlin("android") version "2.0.21"
}

android {
    namespace = "com.itsectr.app"
    compileSdk = 34

    defaultConfig {
        applicationId = "com.itsectr.app"
        minSdk = 26
        targetSdk = 34
        versionCode = 1
        versionName = "1.0.0"
    }
}

dependencies {
    implementation(platform("androidx.compose:compose-bom:2024.06.00"))
    implementation("androidx.compose.ui:ui")
    implementation("androidx.core:core-ktx:1.13.1")
}

KTSの型変換

KTSとGroovyの主な違いの1つは型の扱いです。Groovyではすべての設定がObjectを受け入れますが、KTSでは特定のKotlin型を受け入れます。たとえば、compileSdkは文字列ではなくIntを受け入れます。これにより、不適切な型に関連するエラーが排除されます：GroovyではcompileSdk 34とcompileSdk "34"は同じように機能しますが、KTSでは最初の形式のみが有効です。この厳密さにより、設定がより予測可能で文書化されたものになります。

Gradle KTS vs Groovy：比較

GroovyはGradleのオリジナルDSLであり、現在も完全にサポートされています。ただし、KTSには新規プロジェクトで推奨されるいくつかの利点があります。静的型付け、IDEでの編集パフォーマンスの向上、より厳格な構文がKTSに切り替える主な理由です。同時に、Groovyは単純な設定の簡潔さという利点を保持しています。

スクリプトコンパイル後のKTSとGroovyのビルドパフォーマンスはほぼ同じです。KTSスクリプトは初回実行時またはキャッシュクリア後により長いコンパイル時間を要しますが、後続のビルドはGroovyスクリプトと同じ速度で実行されます。Gradleはコンパイル済みのKTSスクリプトをビルドディレクトリにキャッシュするため、スクリプトが変更された場合にのみ再コンパイルが発生します。

2026年のKTSとGroovyの選択は明確です：新規プロジェクトにはKTS。Google、JetBrains、Gradleはすべての新規プロジェクトにKTSを推奨しています。Groovyは、設定量やKTSと互換性のない特定プラグインのために移行が現実的でないレガシープロジェクトのメンテナンスに関連性を保っています。

コード例：KTSのビルドスクリプト

Android、Kotlin Multiplatform、Compose Multiplatform向けのKTSの典型的な設定ブロックを見てみましょう。KTSを使用したAndroidプロジェクトでは、buildTypesとproductFlavorsの設定で明示的な型指定が必要です。以下の例は、2つのフレーバーを持つアプリケーションのセットアップを示しています。

android {
    buildTypes {
        val release = getByName("release") {
            isMinifyEnabled = true
            proguardFiles(
                getDefaultProguardFile("proguard-android-optimize.txt"),
                "proguard-rules.pro"
            )
        }
        getByName("debug") {
            applicationIdSuffix = ".debug"
        }
    }

    flavorDimensions += "version"
    productFlavors {
        register("demo") {
            dimension = "version"
            versionNameSuffix = "-demo"
        }
        register("full") {
            dimension = "version"
        }
    }
}

Kotlin MultiplatformではKTSが必須です。Groovyはマルチプラットフォームモジュールの設定を正しくサポートしていません。KMMモジュールの設定には、ターゲットプラットフォームとソースセットの設定が含まれます。以下の例は、iOSとAndroidを使用した共有モジュールの設定を示しています。

kotlin {
    androidTarget {
        compilations.all {
            kotlinOptions {
                jvmTarget = "17"
            }
        }
    }

    listOf(
        iosX64(),
        iosArm64(),
        iosSimulatorArm64()
    ).forEach { iosTarget ->
        iosTarget.binaries.framework {
            baseName = "Shared"
            isStatic = true
        }
    }

    sourceSets {
        commonMain.dependencies {
            implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:1.9.0")
        }
        androidMain.dependencies {
            implementation("org.jetbrains.kotlinx:kotlinx-coroutines-android:1.9.0")
        }
    }
}

ヘルパー関数とカスタムタスク

KTSでは、ビルドスクリプト内でヘルパーKotlin関数を宣言できます。これは、署名設定やバージョン管理などの繰り返し設定に特に便利です。静的型付けのおかげで、これらの関数はコンパイル時にパラメータ検証を行って呼び出すことができ、Google Play公開前の署名設定のエラーを排除します。

fun Project.configureSigning() {
    android {
        signingConfigs {
            register("release") {
                storeFile = file("release.keystore")
                storePassword = System.getenv("KEYSTORE_PASSWORD")
                keyAlias = System.getenv("KEY_ALIAS")
                keyPassword = System.getenv("KEY_PASSWORD")
            }
        }
    }
}

// build.gradle.ktsでの使用法
configureSigning()

GroovyからKTSへの移行

GroovyからKTSへの移行は段階的に実行できるプロセスです。Gradleは、一部のモジュールがGroovy（build.gradle）を使用し、一部がKTS（build.gradle.kts）を使用する混合プロジェクトをサポートしています。settings.gradleとルートbuild.gradleはモジュールプラグインに依存しないため、最初に移行できます。Googleは、settings.gradle.kts、次にルートbuild.gradle.kts、最後にモジュールという順序での移行を推奨しています。

移行の主な手順は次のとおりです：クロージャ構文をラムダに置き換え、代入に=記号を追加し、文字列キーを型付き定数に置き換え、変数を明示的に型付けします。Android Studioは単純なブロックの自動Groovy→KTS変換を提供しますが、ネストされたクロージャを含む複雑な設定は手動での書き換えが必要です。

典型的な移行の問題には、Kotlinに相当するものがない暗黙的なGroovyメソッド呼び出しや、Kotlin対応APIを提供しないプラグインが含まれます。最初の問題については、GradleはwithGroovyBuilder（KTSからGroovyメソッドを呼び出せるメカニズム）を通じて互換性を提供します。2番目の問題については、プラグインの更新を待つか、完全移行までGroovyモジュールで使用する必要があります。

Kotlin Multiplatform向けGradle KTS

Kotlin Multiplatformは、KTSが必須要件である主要プロジェクトです。kotlin multiplatformプラグインは、ターゲットプラットフォーム、ソースセット、フレームワークバイナリの設定のための拡張機能を提供し、これらはKotlin DSLを介してのみ利用可能です。Groovyはマルチプラットフォーム設定を正しくサポートしていないため、KMMプロジェクトは排他的にKTSを使用します。

KTSでのKMM設定には、非標準ブロックが含まれます：プラットフォームを指定するkotlin.target、共通コードとプラットフォーム固有コードを整理するkotlin.sourceSets、CocoaPods統合のkotlin.cocoapods、JDK選択のkotlin.jvmToolchain。各ブロックにはAndroid Studioでのオートコンプリート付きの厳密に型付けされたAPIがあり、複数のプラットフォームを持つ複雑なKMMプロジェクト設定に特に価値があります。

kotlin {
    iosArm64()
    iosSimulatorArm64()
    iosX64()

    cocoapods {
        summary = "Shared Kotlin module"
        homepage = "https://itsectr.com"
        framework {
            baseName = "Shared"
            isStatic = false
        }
        pod("Alamofire") {
            version = "5.9"
        }
    }
}

KTSの静的型付けのおかげで、KMM開発者はソースセットと依存関係のオートコンプリート、フレームワーク設定の型チェック、プラットフォーム名のリファクタリング機能を得られます。KTSはデバッグも簡素化します：KMM設定のエラーは、Gradleタスクが実行されるまでエラーが隠れていた可能性があるGroovyとは異なり、明確なメッセージとともにKotlinコンパイルエラーとして表示されます。