はじめに こんにちは、WEAR開発部Androidブロックの青木です。普段はファッションコーディネートアプリWEARのAndroidアプリ開発を担当しています。 私たちWEAR Androidチームでは、設計や実装の規約をテストとして実行し、違反をCIで止める自作のテストモジュール「archtest」を運用しています。本記事では、規約ができる前からの違反を数百件抱えたコードベースに、この仕組みを後から入れた方法を紹介します。中心となるのは、既存の違反をどう扱ったかと、Kotlinのソースをどう検査しているかの2点です。導入後は、ルールで検出できる新しい違反が入るときにCIで必ず気づけるようになり、一度直した箇所に気づかないまま違反が戻ることもなくなりました。 目次 はじめに 目次 背景・課題 規約が守られているかはレビュアーに依存 既存のコードには386件の違反 求めた条件 archtestの全体像 既存の違反は凍結し、新しい違反だけを止める baselineに既存の違反を書き出す 直した違反がbaselineに残っていても失敗にする PSIでKotlinのソースを読むテストを自作した 既存のツールを見送った理由 PSIでソースを構文木にする 型解決はしない 構文木は保持せず、軽いモデルに要約する ルールの実装とテスト ルールの例 コード例のテストをルールの仕様書にする 違反メッセージだけで直せるようにする 運用 CIでユニットテストより先に実行する ルールを追加する つまずきと限界 ルールが自分自身を違反として凍結していた Kotlinの更新にはコンパイラAPIへの追従が要る 型推論でimportが消えると検出できない baselineのキーの粒度で検出範囲が変わる 導入してみて まとめ 最後に 背景・課題 規約が守られているかはレビュアーに依存 WEAR Androidでは、設計や実装の規約をAGENTS.mdなどの文書にまとめています。UiStateの組み立て方、APIクライアントの呼び出し経路、テストに使うライブラリなどです。どれもWEAR Android固有の規約で、古いAPIからの移行のような方針が決まるたびに増えていきます。規約が守られているかは、コードレビューで確かめるしかありませんでした。 AGENTS.mdなどはAIエージェントにコードを書かせる際の指針ですが、必ず守られるとは限りません。例えば、古いAPIのモデルクラスは新しく使わない、という規約があります。しかし、既存のコードを参考にして書くと、人とAIエージェントのどちらも、古いモデルクラスをそのままimportしてしまいます。実際に、archtestの導入後にも、新しく書いたコードが古いモデルクラスをimportし、CIで止まったことがありました。AIエージェントの書くコードが増えるほど、レビューだけで確かめるのは難しくなります。 規約をテストにすれば、この確認はCIに任せられます。しかし、既存のコードが障害になりました。 既存のコードには386件の違反 WEAR Androidは長く開発が続いているアプリで、規約の多くは後から決めたものです。そのため、既存のコードには違反が残っています。CIで動かし始めたとき、13の規約への違反は386件ありました。例えば、古いAPIやそのモデル、RxJavaのimportが187件、UiStateを組み立てる関数に古い命名を使っている箇所が73件です。 違反を1件でも見つけたら失敗するチェックを入れると、導入した時点ですべてのPRのCIが通らなくなります。かといって、386件を直してから導入するのも現実的ではありません。古いAPIからの移行のように、直すのに設計の判断や大きな作業が必要な違反も含まれているためです。直している間にも、新しい違反は入ってきます。 求めた条件 そこで、次の3つを満たす仕組みを作ることにしました。 既存の違反はいったん許し、新しい違反だけを止める 違反を直したら、同じ箇所に違反を戻せないようにする 規約が増えるたびに、プロジェクト固有のルールを手軽に追加できる archtestの全体像 archtestは、JUnitのテストだけを持つGradleモジュールです。独自のGradleプラグインやタスクは作らず、通常のテストとして ./gradlew :archtest:test で実行します。 archtest/ ├── baselines/ # ルールごとの既存の違反の一覧（baseline） └── src/test/kotlin/ # パッケージのディレクトリは省略 ├── infra/ # ソースの読み込みやbaselineとの照合など、全ルールで共有する部品 └── rules/ # 1ルール1ファイル（ルール本体とそのテスト） テストは次の順に動きます。 リポジトリ内のKotlinファイルを集める ファイルごとに構文木を作り、ルールの判定に必要な情報だけを抜き出す 各ルールが、抜き出した情報から違反の一覧を作る（ルールによってはMarkdownなどのファイルも読む） 違反の一覧をbaselineと照合し、テストの成否を決める ルールごとに書くのは3だけで、1、2、4は全ルールで共通の処理です。 以降では、まず4の照合を説明します。既存の違反を許しつつ新しい違反を止め、直した箇所に違反を戻させないのは、この照合の役割です。そのあとで、ルールを手軽に追加するための1〜3の実装を紹介します。 既存の違反は凍結し、新しい違反だけを止める baselineに既存の違反を書き出す archtestでは、導入時点で見つかった違反をルールごとのテキストファイルに書き出し、そこに載っている違反だけを許します。このファイルをbaselineと呼んでいます。 # R005-hilt-viewmodel の既存違反リスト(archtestが管理)。 # このリストは減らす一方とし、新規の違反を追加してはならない。 # 再生成: ./gradlew :archtest:test -PupdateBaseline=true feature/foo/src/main/kotlin/com/example/FooViewModel.kt|FooViewModel ... 1行が違反1件で、 相対パス|識別子 の形式です。識別子にはクラス名など、違反した宣言を指す名前を使います。行番号は含めていません。違反と関係のない編集で行がずれただけで、既存の違反が新しい違反として扱われてしまうためです。 baselineは、既存の静的解析ツールであるAndroid Lintやdetektにもある考え方です。しかし、直した違反がbaselineに載ったままでも、detektは何も報告せず、Android Lintも情報レベルの通知にとどまるため、どちらもデフォルトでは失敗しません。archtestで変えたのはこの点です。 直した違反がbaselineに残っていても失敗にする archtestのテストは、現在のコードで見つかった違反とbaselineを照合し、次の2つのどちらかに当てはまると失敗します。 状況 結果 baselineに載っていない違反がある 失敗（新しい違反を止める） 直した違反がbaselineに残っている 失敗（baselineから行を消すよう求める） どちらでもない 成功 違反を直してもbaselineの行が残っていると、その箇所には再び違反を書けてしまいます。2つ目の条件で行の削除を強制すれば、一度直した箇所に違反は戻りません。ルールごとのbaselineの件数は、レビューで合意して行を足さない限り、減る方向にしか動かなくなります。 どちらの経路でもbaselineは増えず、右の経路では減ります。 照合の処理は次のとおりです。 val baselineKeys = readBaseline(file) val currentKeys = violations.map { it.baselineKey }.toSet() val newViolations = violations.filter { it.baselineKey !in baselineKeys } val staleKeys = baselineKeys - currentKeys if (newViolations.isEmpty() && staleKeys.isEmpty()) return newViolations が新しい違反、 staleKeys が直したのに残っている行です。後者で失敗したときは、次のように行の削除を促します。 解消済みの違反がbaselineに残っています (1件): - feature/foo/src/main/kotlin/com/example/FooViewModel.kt|FooViewModel 違反の解消ありがとうございます。archtest/baselines/R005-hilt-viewmodel.txt から上記の行を削除するか、 ./gradlew :archtest:test -PupdateBaseline=true で全baselineを再生成してください。 新しい違反をbaselineに足して通せるのは、PRのレビューで合意した場合だけです。baselineを再生成したときは差分を必ず確認し、行が増えていないことを確かめます。 違反がまだ1件もない規約は、baselineが空のルールとして追加できます。例えば、WEAR Androidでは、APIクライアントをOpenAPIの定義からOpenAPI Generatorで生成しています。この生成したAPIクライアントをinfrastructureモジュールの外からimportさせないルールは、導入時点で違反が0件でした。こうしたルールは最初の1件から止められるので、良い状態に気づいた時点で追加しています。 PSIでKotlinのソースを読むテストを自作した 既存のツールを見送った理由 最初に検討したのは、Kotlin向けのアーキテクチャテストライブラリであるKonsistでした。しかし2026年8月の時点で、Konsistのリリースは1年8か月ほど止まっており、Kotlin 2.4系のWEAR Androidでは将来コードを正しく読めなくなるおそれがありました。 1 次に、静的解析ツールのdetektの導入を検討しました。しかし、ルールをWEAR Androidに合わせて調整し続けるコストと、detekt 1.xから2.0への移行のコストが見合わないと判断し、見送りました。 導入時には検討していませんでしたが、「 AIエージェント向けコーディングルールをArchUnitで機械的に検証する運用 」で紹介されたArchUnitも、規約をテストにするためのライブラリです。ArchUnitはコンパイル後のバイトコードを検査するため、実行の前にビルドが必要です。 archtestのルールには、import文や、Markdownのようなソース以外のファイルを使うものがあります。例えば、画面の一覧をまとめたMarkdownの記載が、実際のコードにある画面と一致しているかを確かめるルールです。OpenAPI Generatorが出力するファイル一覧と、生成用のディレクトリにあるファイルを突き合わせ、手書きのファイルが紛れ込んでいないかを確かめるルールもあります。Markdownなどのファイルはテストコードから読み、ソースの解析結果と突き合わせています。ソースを直接読むので、ビルドを待たずに検査できます。archtestでは、Konsistやdetektが内部で使っている構文解析の仕組みであるPSIを直接使って、ソースを読んでいます。 ツールごとの違いをまとめると、次のとおりです。 Konsist detekt ArchUnit archtest 検査するもの ソース ソース バイトコード ソース ビルド 不要 不要 必要 不要 プロジェクト全体のファイルの突き合わせ ○ × ○ ○ import文そのものの検査 ○ ○ × ○ 型推論で決まる依存の検出 × △ △ × 既存違反の凍結 × ○ ○ ○ import文はバイトコードに残らないため、ArchUnitでimport文そのものは検査できません。ただし、バイトコードに残る参照から依存を検査でき、パッケージへの依存の禁止はArchUnitの中心的な機能です。型推論で決まる型への依存も、その型のメソッドを呼ぶなどバイトコードに参照が残れば検出できます。戻り値を受け取るだけの場合やローカル変数の型は、参照が残らないため検出できません。 detektのルールでも、型解決を有効にすれば、別ファイルの宣言をたどったり、型推論で決まる依存を検出したりできます。ただし、プロジェクト全体のファイルを集めて突き合わせる仕組みや、Kotlin以外のファイルを入力にする仕組みはありません。 既存違反の凍結は、直した違反の行が残ったときの扱いが違います。detektは、行が残っても失敗しません。ArchUnitは行をファイルから自動で消しますが、更新されたファイルをコミットしなければ、リポジトリには行が残ります。archtestは、行を消すまで失敗させることで、行の削除をPRに必ず含めます。 自作するといっても、実装はほぼすべてAIエージェントのClaude Codeが書きました。調査や設計の計画からパーサの基盤、baselineの仕組み、13のルールとそれぞれのテスト、READMEまでです。ルールが意図どおりに判定するかは、次の章で紹介するコード例のテストを読んで確かめました。 PSIでソースを構文木にする PSI（Program Structure Interface）は、IntelliJ Platformがソースコードを木構造として表す仕組みです。IntelliJ IDEAやAndroid Studioもコードの理解にPSIを使っていて、リネームや使用箇所の検索はPSIの上で動いています。Kotlin向けの実装はKotlinコンパイラのライブラリ版である kotlin-compiler-embeddable に含まれていて、テストの依存に加えるだけで使えます。 archtestでは、ソースの文字列を次のようにして構文木（ KtFile ）にしています。 fun parse(fileName: String , content: String ): KtFile { val virtualFile = LightVirtualFile(fileName, KotlinFileType.INSTANCE, content) return psiManager.findFile(virtualFile) as KtFile } psiManager は、Kotlinコンパイラの内部向けのAPIである KotlinCoreEnvironment で構文解析用の環境を作り、そこから取得しています。 構文木にしてから調べるので、文字列検索と違って、コメントや文字列リテラルの中の単語には反応しません。ネストしたクラスやimportのエイリアスも区別できます。 型解決はしない archtestは構文木を作るだけで、型解決はしません。型解決とは、コードに書かれた名前が実際にどのクラスを指すのかを確定させる処理です。この処理にはプロジェクト全体の依存関係が必要です。コンパイラの型推論を使わない点は、Konsistと同じです。 型解決をしないので、archtestはクラスパスを必要とせず、ビルドを待たずに動きます。リポジトリ全体の約3,000ファイルを検査しても、CIでは全ルールの照合が6秒ほどで終わります。 その代わり、判定に使える情報はコードに書かれた表記とimport文に限られ、表記に現れない依存は検出できません。実例は後の章で紹介します。 構文木は保持せず、軽いモデルに要約する 構文木はソースの数倍のメモリを使います。3,000ファイル分を保持したまま全ルールで使い回すのは負担が大きいため、archtestではファイルごとに必要な情報だけを抜き出し、軽いモデルに要約しています。 data class ScannedFile( val relativePath: String , val sourceSet: SourceSet, val packageName: String , val imports: List < String >, val classes: List <ScannedClass>, // 関数やobjectの情報なども持つ ) 各ルールは、この ScannedFile の一覧に対するフィルタとして書きます。ルールはPSIのAPIに触れないので、ルールを書くのにPSIの知識は要りません。 ルールの実装とテスト ルールの例 ルールの例として、「ViewModelには @HiltViewModel を付け、 ViewModel を直接継承する」という規約を取り上げます。ルール本体は次のとおりです。 fun check(files: List <ScannedFile>): List <Violation> = files .filter { it.sourceSet == SourceSet.MAIN } .flatMap { file -> file.classes .filter { it.isConcreteClass && it.name.endsWith( "ViewModel" ) } .mapNotNull { scannedClass -> val problems = buildList { if ( "HiltViewModel" !in scannedClass.annotationNames) { add( "@HiltViewModelがない" ) } when { "AndroidViewModel" in scannedClass.superTypeNames -> add( "AndroidViewModelを継承している" ) "ViewModel" !in scannedClass.superTypeNames -> add( "ViewModelを直接継承していない" ) } } if (problems.isEmpty()) null else Violation( baselineKey = " ${ file.relativePath } | ${ scannedClass.nestedName } " , detail = " ${ file.relativePath } の ${ scannedClass.nestedName } : ${ problems.joinToString( "、" ) } " , ) } } 名前が ViewModel で終わる具象クラスを取り出し、アノテーションと継承先を表記で確かめています。 baselineKey が、baselineの1行になる値です。 コード例のテストをルールの仕様書にする 各ルールのテストクラスは、2つの部分でできています。1つ目は、違反する例と違反しない例をコードの文字列で書いたユニットテストです。 @Test @DisplayName ( "@HiltViewModel無し・間接継承・AndroidViewModel継承・名前だけViewModelのクラスを違反として検出する" ) fun detectsViolatingViewModels() { val file = SourceScanner.toScannedFile( relativePath = "feature/foo/src/main/kotlin/com/example/Foo.kt" , content = """ class NoHiltViewModel : ViewModel() @HiltViewModel class IndirectViewModel @Inject constructor() : BaseViewModel() // AndroidViewModel継承・名前だけViewModelのケースは省略 """ .trimIndent(), ) HiltViewModelRule.check(listOf(file)).map { it.baselineKey } shouldBe listOf( "feature/foo/src/main/kotlin/com/example/Foo.kt|NoHiltViewModel" , "feature/foo/src/main/kotlin/com/example/Foo.kt|IndirectViewModel" , ) } 違反しない例のテストも同じ形で書き、違反が0件になることを確かめます。このテストはルールの仕様書を兼ねています。PSIを知らなくても、どのコードが違反になり、どのコードが違反にならないかを読み取れます。誤検知が見つかったときは、まずこのテストに再現するコードを足してから判定を直します。 2つ目は、リポジトリ全体を検査してbaselineと照合するテストです。 @Test fun repositoryHasNoNewViolations() { Baselines.check( baselineName = HiltViewModelRule.BASELINE_NAME, ruleTitle = HiltViewModelRule.TITLE, fixGuide = HiltViewModelRule.FIX_GUIDE, violations = HiltViewModelRule.check(SourceScanner.allFiles), ) } SourceScanner.allFiles は、リポジトリ全体のKotlinソースを読んだ一覧です。この一覧にルールを適用した結果を、 Baselines.check が前の章の処理でbaselineと照合します。 ruleTitle と fixGuide は、照合に失敗したときのメッセージに使います。 違反メッセージだけで直せるようにする 違反が見つかると、テストは次のようなメッセージで失敗します。 [R005-hilt-viewmodel] ViewModelは@HiltViewModelを付け、androidx.lifecycle.ViewModelを直接継承します(AndroidViewModelは使わない) 新規違反 (1件): - feature/foo/src/main/kotlin/com/example/FooViewModel.kt の FooViewModel: @HiltViewModelがない 修正方法: - @HiltViewModel を付与し、@Inject constructor で依存を受け取ってください - 独自基底クラスを挟まず ViewModel() を直接継承してください - AndroidViewModel は使わず、Applicationが必要な場合は @ApplicationContext でContextを注入してください - androidx ViewModelでないクラスに ViewModel サフィックスの名前を付けないでください 参照実装: feature/template/src/main/kotlin/com/example/template/TemplateViewModel.kt 新規の違反は archtest/baselines/R005-hilt-viewmodel.txt に追加せず、コード側を修正してください。 メッセージには、違反した箇所と直し方を必ず書き、参照できる実装があればそのパスも書きます。人とAIエージェントのどちらもメッセージを読むだけで直せることを、ルールの完成条件にしています。導入前には、起きそうな違反をわざと入れて、対応するルールが修正方法付きで失敗することを確かめました。 導入後のPRには、archtestで止まったあとにAIエージェントが違反メッセージを読んでコードを直したコミットがいくつもあり、コミットメッセージにはルール名が書かれています。例えば、XMLのリスト部品をJetpack Composeに書き直したPRでは、新しい部品が古いAPIのモデルクラスをimportして止まりました。AIエージェントは部品用のデータクラスを作り、古いモデルからの変換を呼び出し側に移して、部品から古いモデルへの依存をなくしました。ほかにも、テストファイルの命名規約や、純JVMのテストにAndroidの依存を持ち込まない規約で止まり、メッセージの「修正方法」のとおりに直したコミットがあります。 運用 CIでユニットテストより先に実行する archtestは、PRが作成・更新されるたびにGitHub Actionsで実行しています。同じジョブの中でユニットテストより前の独立したステップとして動き、違反があればその時点でジョブを失敗させます。時間のかかるユニットテストの完了を待たず、軽い検査の失敗を先に返すためです。ステップ全体の所要時間は、Gradleのキャッシュの状態によって30秒〜2分半ほどです。 ルールを追加する ルールを追加する目安は、次の3つとしています。 コードレビューで同じ指摘を2回以上したとき 新しい規約や移行方針を決めたとき 違反が0件の良い状態に気づいたとき 新しい規約は、文書化する前に、まずルール化できないかを考えます。 ルールの実装は、AIエージェントに頼むことが多いです。PSIから読み取れる情報で判定できるルールなら、「こういうルールを書けるか」と頼むと、たいてい書き上げます。 導入後もルールは増えていて、導入時の13個から現在は18個です。例えば、ComposeにFragmentを載せるときに共通の部品を使うルールは、クラッシュを修正したメンバーが追加しました。修正の後続の作業で共通の部品を作り、同じPRで、その部品を全員に使わせるルールを入れています。 つまずきと限界 ルールが自分自身を違反として凍結していた テスト用のFakeの命名を検査するルールは、当初「 Fake で始まる名前」を検査対象にしていました。そのため、ルール自身のクラス名（ FakesConvention... ）も違反として検出し、そのままbaselineに凍結していました。導入PRのAIレビューの指摘で気づき、判定を「 Fake の直後が大文字で始まる名前」に直しています。 baselineは既存の違反を機械的に書き出すので、誤検知もそのまま凍結してしまいます。baselineを生成したときは、件数だけでなく中身も確認する必要があります。 Kotlinの更新にはコンパイラAPIへの追従が要る 導入から1週間ほどたったころ、Kotlinを2.4.20に上げるRenovateのPRで、archtestのテストコードがコンパイルできなくなりました。原因は、構文解析用の環境を作るのに使っている KotlinCoreEnvironment です。2.4.20では、このAPIを使うために必要なopt-inの種類と設定の作り方がともに変わり、従来の書き方ではコンパイルエラーや実行時エラーになりました。 対応は、opt-inの追加と、設定を公式のファクトリ関数で作る形への書き換えで、変更は10行ほどでした。そのRenovateのPRに修正のコミットを追加し、翌日にマージしています。 Konsistを見送った理由の1つは、パーサがKotlinの更新に追いつかないおそれでした。archtestが使うKotlinコンパイラのライブラリは、アプリ本体と同じKotlinのバージョンを参照しているため、パーサだけが古くなることはありません。その代わりに、Kotlinを上げたときにコンパイラの内部向けのAPIが変わっていれば、自分たちで追従する必要があります。なお、続く2.4.21への更新では、archtestの変更は要りませんでした。 型推論でimportが消えると検出できない 新しく書いたテストが古いAPIのモデルクラスをimportし、archtestで止まったことがありました。このテストは、違反で止まったあと、ほかのUiStateのテストと同じく型引数を省く形へ書き換えられ、archtestを通過しました。 // 書き換え前：import文に古いAPIのモデルが現れるので検出できる import com.example.legacy.ItemDetailList // ... itemDetailListFlow = MutableStateFlow<ItemDetailList?>( null ), // 書き換え後：型は渡し先の引数の型から推論されるので、import文が消えて検出できない itemDetailListFlow = MutableStateFlow( null ), 古いAPIのモデルクラスへの依存は残ったまま、importだけが消えています。ただし、この依存はテストの側だけではなくせません。テスト対象のUiStateが古いモデルを引数に取っていて、そのファイル自体がbaselineに載っているためです。依存をなくすには、テスト対象のコードを移行する必要があります。それでも、表記とimport文だけで判定する割り切りの代償として、archtestがこの種の依存を見落とすことに変わりはありません。 baselineのキーの粒度で検出範囲が変わる 古いAPIやRxJavaのimportを禁止するルールでは、baselineのキーを 相対パス|グループ名 にしています。グループ名は、 rxjava のように、禁止対象の種類をまとめた名前です。baselineに載っているファイルは、古いAPIからの移行の際にファイル単位でまとめて解消する前提です。そのため、クラスごとではなくファイルとグループの単位で進捗を管理しています。 baselineに載っていないファイルへのimportによる持ち込みは、すべて検出できます。ただし、baselineに載っているファイルでは、同じグループの古いAPIを新しくimportしても検出できません。キーを細かくすれば検出できる範囲は広がりますが、baselineの行数が増え、直したときに消す行も増えます。どの粒度にするかは、ルールごとに決める必要があります。 導入してみて archtestは2026年8月末からCIで動いています。導入して変わったのは、ルールで検出できる新しい違反が入るときに、CIで必ず気づけるようになったことです。気づいたうえで、直すか、合意してbaselineに追加するかをレビューで決めています。baselineに追加した場合も、その理由がレビューに残ります。 導入から2か月あまり（2026年11月10日時点）の数字は次のとおりです。 項目 値 ルール数 13個 → 18個 導入時の13ルールのbaseline 386件 → 341件 導入後に追加したルールのbaseline 161件 CIがarchtestのステップで失敗した回数 31回 新しい違反で止まったPR 10件 直した違反がbaselineに残っていて止まったPR 9件 CIがarchtestのステップで失敗した31回のうち、12回は新しい違反で止まったものです。そのほかは、直した違反の行が残っていて止まったものが10回、Kotlinの更新でコンパイルできなかったものが5回、ルールと関係のないビルドやネットワークの失敗が4回でした。「直した違反がbaselineに残っている」で止まったPRは9件ありました。そのうち5件は、古いAPIの置き換えを中心に、直した人がそのPRの中でbaselineの行を消しています。残る4件のうち3件は、同じ違反を別のPRが先に直して行を消していたため、その変更を取り込んで解消しました。残りの1件は、マージせずに閉じたPRです。 導入時の13ルールのbaselineは、386件から341件に減りました。減った45件は、古いAPIを新しいAPIに置き換える作業など、別の作業の中でついでに消えたものです。baselineを減らすための作業は、画面一覧のMarkdownの記載修正や、命名規約に合わせたテストファイルのリネームのように、アプリの動作に影響しないものから小さく進めていく想定です。 導入後に追加した5つのルールのうち2つは、追加した時点の既存の違反、合わせて161件をbaselineに凍結して始めています。違反を抱えたコードにも、新しいルールを同じ手順で後から足せます。 まとめ 本記事では、WEAR Androidに規約のチェックを後から入れた方法を紹介しました。 既存の違反はbaselineに書き出して凍結し、新しい違反だけをCIで止める 直した違反がbaselineに残っていれば失敗にして、baselineを減る一方にする Kotlinのソースは型解決をせずにPSIで構文木にして、ビルドを待たずに検査する ルールごとに、違反する例と違反しない例のテストを仕様書として書き、違反メッセージには直し方を書く 型解決をしないため、表記に現れない依存は検出できません。それでも、ビルドを待たずに全ファイルを検査でき、ルールを手軽に追加できることは、プロジェクト固有の規約を守るうえで大きな利点でした。違反を抱えたコードベースに規約のチェックを入れようとしている方の参考になれば幸いです。 最後に ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com その後、Konsistは2026年10月にKotlin 2.4系に対応したv0.18.0を公開し、リリースを再開しました。現在は、Kotlin 2.4系のプロジェクトでも使えます。 ↩

本記事は 2026 年 11 月 12 日に Kiro ブログで公開された「 Introducing Kiro for Android 」を翻訳したものです。 Kiro for Android を Google Play で提供開始しました。 エンジニアリングの作業を進めるために、ノート PC の前に戻る必要はありません。外出中にアイデアがひらめくこともあれば、通勤中にセッションが変更を終えることも、進行中の作業があなたの入力を待って止まっていることもあります。Android のユーザーは、スマートフォンから新しい作業を始め、すでに動いているクラウドの作業を引き継ぎ、そのまま進められるようになりました。 図 1: Kiro for Android の新しいセッションの画面 どこにいても作業を進められる クラウドセッション を使うと、同じ作業を Kiro CLI、Web、IDE、Android のどこからでも扱えます。会話とセッションの履歴がそろった状態で Android からクラウドセッションを開くことも、Android で始めて、あとで別の場所から再開することもできます。 Kiro の設定を同期 していれば、その設定もクラウドセッションで使えます。 使うクライアントを切り替えても、スマートフォンをしまっても、セッションはクラウドのサンドボックスで動き続けます。Android では、まだ動いているセッション、終わったセッション、あなたの対応が必要なセッションを確認できます。 アイデアがひらめいたときに始める すぐに始めたほうがよいアイデアもあります。移動中に機能を思いついたとき、本番環境のバグに気づいたとき、デスクに戻る前に始められる調査があると気づいたときなどです。 Android から新しいセッションを始め、必要なリポジトリを接続し、何を作りたいか、何を直したいか、何を調べたいかを Kiro に伝えます。見せたほうが早いときは、スクリーンショットを添付できます。あなたがほかの用事に移っている間も、Kiro はコードを調べ、ツールを使い、変更を加え、テストを実行し、クラウドで作業を続けられます。 あなたの判断が必要になったら 先に進む前に判断が必要なセッションもあります。ブランチの選択、実装の細部の確認、予想外のことが見つかったあとの方針転換などを、Kiro があなたに求めることがあります。Android でセッションを開き、質問に答えるか補足を伝えれば、Kiro はそこから作業を続けます。作業を止めないためだけに、ノート PC の前にいる必要はありません。 スマートフォンでレビューして仕上げる 変更の準備ができたら、スマートフォンで差分を直接開けます。ファイルの変更はモバイル向けのカードで表示されるので、小さな画面でデスクトップ向けのレイアウトを操作しなくても、ファイルごとに実装をレビューできます。 直すところがあれば、Kiro にもう一度作業を頼みます。変更に問題がなければ、Kiro がプルリクエストを作成でき、PR の状態はセッションと一緒に表示されます。 図 2: 2 つのリポジトリのプルリクエストとテスト結果を表示したセッション 使い始める Kiro for Android は Kiro の有料プランで利用できます。 Google Play から Kiro for Android をダウンロードし、Kiro CLI、Web、IDE で使っているのと同じアカウントでサインインしてください。クラウドセッション、接続したリポジトリ、モデルの選択、同期した設定は自動的に引き継がれます。IAM Identity Center を使っている企業では、ユーザーが Kiro for Android を使う前に、管理者が クラウドセッション を有効にする必要があります。クラウドセッションは現在 us-east-1（バージニア北部）で利用できます。 Kiro for iOS は引き続きプレビュー中です。 早期アクセスをリクエスト していただければ、利用できるようになった時点でお知らせします。 スマートフォンで始めれば、戻ったときには PR ができています。 原文の著者 Kyle Seaman（Product Lead）、Alex Jia（Product Marketing） 翻訳者について 稲田 大陸 – いなりく AWS Japan で働く Kiro をこよなく愛すソリューションアーキテクト。普段は製造業のお客様を支援しています。その活動の傍ら、最近は AI 駆動開発ライフサイクル (AI-DLC) の日本のお客様への布教活動もしつつ、 Kiro のブログ などを執筆しています。

Kotlin Multiplatform(KMP)撤退の意思決定と得られたもの はじめに この記事で ...