LLM任せにしない
UIテストワークフローを、
Koogの型付き戦略グラフで設計する

自己紹介

このセッションのゴール

アジェンダ

このトークで e2e テストと呼ぶもの

変更が増えるにつれて、リリース前の確認が増えた

LLMにデバイスを触らせるテストは、どこまで頼れるか

LLM に渡したプロンプト

結果は PASS でも、中では3つの問題が起きていた

この経験から決めた、3つの要件

Koogとは

Koogで作ったものを動かしてみる

対象プラットフォーム

インターフェース

CLI ／ MCP

出力

CLI logs ／ Web Dashboard

$ e2e generate markor_create_note  # LLM が実機を探索して、シナリオを作る

$ e2e run-release 1.0.0             # 保存したシナリオを、LLM なしで再生する

$ e2e dashboard                     # 証拠付きの結果と、Langfuse のトレース

テスト1本の6つの段階と、LLM とコードの担当

型付き戦略グラフでワークフローを定義する

テストハーネスのグラフ設計をKoog の DSLで書く

strategy<RunRequest, Reported>("koog-e2e-run") {

    val resolve by resolveNode.asNode()

    val attempt by attemptSubgraph.delegate()

    val report  by reportNode.asNode()

    edge(nodeStart forwardTo resolve)

    edge(
        resolve forwardTo attempt

        onCondition { it is Resolved.Ready }

        transformed { (it as Resolved.Ready).attempt }
    )

    edge(
        resolve forwardTo report

        onCondition { it is Resolved.Blocked }

        transformed { (it as Resolved.Blocked).outcome }
    )

    edge(attempt forwardTo report)

    edge(report forwardTo nodeFinish)

}

試行サブグラフはブラックボックス

入力は、人が書くテスト仕様

試行のサブグラフ

シナリオは、再生して検証できたものだけを保存する

命令を抽象化する DeviceDriver

interface DeviceDriver {

    val backend: Backend

    val operations: Set<String>   // モデルに提示してよい操作

    suspend fun observe(): Readiness

    suspend fun useLocale(locale: DeviceLocale): LocaleCheck

    suspend fun perform(steps: List<FlowStep>): StepOutcome

    suspend fun execute(scenario: Scenario, attemptDir: Path, listener: ExecutionListener): ExecutionResult

    suspend fun capture(name: String, directory: Path): CheckpointEvidence?

}

LLM は番号を選び、コードがステップに変える

中間シナリオを実行シナリオに変換する

状態はノードの戻り値として次のノードに渡る

interface GraphNode<In, Out> {

    suspend fun run(input: In): Out

}

class ExecuteNode(…)  : GraphNode<AttemptState, AttemptState>

class ValidateNode(…) : GraphNode<AttemptState, Validated>

class RetryNode(…)    : GraphNode<Validated, AttemptDecision>

edge(execute forwardTo validate)    // 戻り値が、そのまま次の入力になる

edge(validate forwardTo retry)

edge(retry forwardTo execute

    onCondition { it is AttemptDecision.Retry }

    transformed { (it as AttemptDecision.Retry).next })    // 次の試行の状態だけを渡す

// サブグラフも、状態は入力と出力の型だけで持つ

subgraph<AttemptState, AttemptOutcome>("attempt")

subgraph<LocateRequest, LocateResult>("locate")

data class AttemptState(

    val scenario: Scenario,

    val attemptNumber: Int,

    val retriesRemaining: Int,

    val recoveriesRemaining: Int,

    val previousAttempts: List<AttemptRecord>,

    …

)

data class Validated(

    val state: AttemptState,

    val record: AttemptRecord,

)

sealed interface AttemptDecision {

    data class Retry(val next: AttemptState)

    data class Recover(val request: LocateRequest)

    data class Finish(val outcome: AttemptOutcome)

}

要素が見つからない時だけ、LLM で回復する

// 判定の順序を示す簡略版

fun decide(record: AttemptRecord, … ): NextAttempt {

    val verdict = record.verdict

    if (verdict.overall == PASS || verdict.overall == FAIL)

        return Finish(rules.outcomeOf(verdict, warnings))

    val failure = record.execution.failure

    if (failure is ElementNotFound)

        return if (recoveries > 0) 
            Recover(failure) 
        else 
            Finish(ReviewRequired(…))

    if (retries > 0 && timeLeft) {
　　　　return Retry(reason)
　　}

    return Finish(Inconclusive(reason))

}

結論が出たら終わる

見つからない時だけ回復

それ以外はやり直す

分岐は、すべて sealed な型で書く

要素が見つからない時はどんな時？

UIツリーが膨大でトークンが積み上がる

UIツリーを圧縮し、押せるものに番号を振って渡す

元々のUIツリー

圧縮したUIツリー

テスト1本がグラフを流れる様子

試行のサブグラフ

端末ごとにワーカーを立て、LLM の同時実行だけを絞る

キューは Channel、結果は channelFlow

fun results(testIds: List<String>): Flow<ResultLine> = channelFlow {

    val waiting = produce { testIds.forEach { send(it) } }        // キュー

    devices.slots.forEach { slot ->

        launch { for (id in waiting) send(runOne(id, slot)) }  // 端末ごとのワーカーに送る

    }

}

共有している LLM をSemaphore で制御する

class ModelPermits(limit: Int) {

    private val permits = Semaphore(limit)  // 同時に limit 本のリクエストまで

    // Semaphoreが空くまで suspend して待つ

    suspend fun <T> holding(call: suspend () -> T): T = permits.withPermit { call() }

}

// LLM を呼ぶ所は、すべてここを通る

permits.holding { executor.executeStructured<JudgedRun>(prompt, model, fixingParser = fixingParser) }

ログを整える

OpenTelemetry Kotlin SDK

OpenTelemetry で、テスト1本を1本のトレースに

テストハーネスそのものを検証する

構成のテストは Koog の testGraph で担保する

判定が安定し、時間も費用も下がった

モデルを賢くしたのではなく、手順を先に固めた効果

このハーネスと mobile-mcp（Opus）

同じモデルで比べると

GOAP で手順を柔軟に計画させる

手動確認の時間は、まだ劇的には減っていない

Koog を使って良かったことと、気をつけること

持ち帰ってほしい3つのこと

安定したセレクタを作る、testTag の自動生成

Koog の Persistence は数行で入る

install(Persistence) {

    storage = JVMFilePersistenceStorageProvider(runDirectory.resolve("checkpoints"))

    enableAutomaticPersistence = true

    rollbackToolRegistry = RollbackToolRegistry {

        registerRollback(createItem, deleteItem)    // 副作用のあるツールと、それを取り消すツールの組

    }

}

端末の状態は巻き戻らない：再開方針の候補（未検証）

data class AttemptState(…, val createdResources: List<ResourceRef> = emptyList())

// 再開時：作ったリソースを、その状態のまま直接開く

FlowStep.OpenLink("myapp://items/${ref.id}")

e2eのハーネスは肥大化されやすい

学び：e2e は重いので、1つ1つの処理の速さが効く

1テストで10秒縮めるだけでも、テストの数と回数を掛ければ大きな差になる

テストフローを速くするために、工夫したこと

柔軟さが要る所だけ、グラフの中に LLM のループを置く

準備

判定

報告

未実装の構成案

その場で判断させるなら、GOAP で手順を計画する

今の状態

残りの条件と回数

プランナー

A* で計画する

A* は、ゴールに近そうな所から調べる

f = g + h

Koog の GOAP では、状態の上を A* で探す