AIエージェントがUI操作まで担う時代へ――Junie /demoで実現する動作確認とCI自動化

Java / Spring

コードを書いた後の「最後の確認」をAIに任せる

AIエージェントによるコード生成が開発現場に浸透しつつあります。一方で、プルリクエストの差分を確認し、テストを実行した後に、アプリを起動して画面を開き、実際にクリックして挙動を確かめる作業は、依然として人手に残りがちです。

JetBrainsのAIエージェント「Junie CLI」に追加された/demoモードは、このUIベースの確認作業を対象にします。開発者が確認したいシナリオを自然言語で指定すると、Junieがアプリケーションをビルドして起動し、画面を操作し、その過程をHTMLレポート、スクリーンショット、動画として記録します。

重要なのは、AIが「出荷してよい」と最終判断することではありません。人間がレビューできる証跡を作りながら、定型的な画面操作を委譲できる点に価値があります。

Junie /demoでできること

たとえば、Issue Trackerに一括ステータス更新機能を追加したケースを考えます。確認したい内容は次のようなものです。

  • PB-101とPB-102を選択する
  • 2件のステータスをDoneに変更する
  • Openの件数が3から1に減ることを確認する
  • Doneの件数が1から3に増えることを確認する
  • ページを再読み込みしても、2件がDoneのままであることを確認する

このように、操作、期待する画面状態、再読み込み後にも維持すべき条件を具体的に記述します。

Reset the sample data.
Select PB-101 and PB-102 and mark them Done.
Check that Open drops from 3 to 1 and Done rises from 1 to 3.
Reload the page and verify that both issues are still Done.

Junieは指定された変更をもとに実行し、画面上でクリックやキー入力を行います。実行中の操作はライブで確認でき、終了後には次の成果物をレビューできます。

  • 実行したステップ
  • 各チェックの成功、失敗、未完了の状態
  • 操作中に取得されたスクリーンショット
  • UI操作を収録した動画
  • 依頼内容や結果をまとめたHTMLレポート

動画とHTMLレポートがもたらす実務上の価値

自動テストの失敗時に、ログだけでは「どの画面で何が起きたのか」が分かりにくいことがあります。UI操作の動画とスクリーンショットがあれば、レビュアーやQA担当者は、実際にどの画面が開き、どの操作の後に何が変化したのかを視覚的に追跡できます。

Junie /demoの動画には、デモの概要を示すスライドが冒頭に入り、複数シナリオを扱う場合はシナリオごとの説明も追加されます。最後には結果をまとめるスライドが入り、説明用の字幕も利用できます。

HTMLレポートには、依頼内容、判定結果、動画、スクリーンショット、実行ステップがまとめられます。これにより、単なる「テスト成功」というステータスだけでなく、何を確認し、どのような証拠が得られたかを共有できます。

従来のE2Eテストとの違い

Junie /demoは、SeleniumやPlaywrightなどを使った従来のE2Eテストをそのまま置き換えるものではありません。両者には適した用途の違いがあります。

観点 従来のE2Eテスト Junie /demo
操作の定義 コードや専用DSLで明示 自然言語でシナリオを記述
再現性 高い。セレクターや条件を固定しやすい モデルや画面状態の影響を受ける可能性がある
判定 アサーションをコードで厳密に定義 プロンプトで期待結果を指定し、結果を記録
証跡 ログ、スクリーンショット、レポートなど 動画、スクリーンショット、HTMLレポートを生成
主な用途 回帰テスト、細かな仕様の継続検証 PRの動作デモ、探索的確認、スモークテスト
保守負荷 UI変更時にテストコードの修正が必要 プロンプトや起動設定の調整が必要

たとえば、決済処理や権限境界のように、毎回同じ条件を厳密に検証すべき処理は、既存の自動テストと明示的なアサーションを中心に設計するのが適しています。

一方で、画面遷移を含む新機能をプルリクエスト単位で確認したい場合や、レビュー担当者に挙動を動画で共有したい場合は、Junie /demoが有効です。テストの置き換えではなく、UI確認とレビュー証跡の自動化として位置付けるのが現実的です。

Docker環境でアプリを起動する仕組み

Junie /demoの実行環境は、Debian BookwormをベースにしたDockerコンテナです。Chromium、Node.js、仮想ディスプレイを提供するXvfb、ウィンドウマネージャー、スクリーンショット取得ツール、xdotool、ffmpegなどを利用して、GUIアプリケーションを起動し、画面操作と録画を行います。

アプリケーション固有の依存関係は、プロジェクト側のDockerfileに追加します。ビルド方法や起動方法は.junie/demo.mdに記述します。初めてリポジトリで利用する場合は、Dockerを起動した状態でJunieに/demoのセットアップを依頼すると、プロジェクトを分析してビルド・起動計画を提示し、確認後に設定ファイルを生成します。

Spring Bootアプリケーションであれば、たとえば次のような情報を起動設定として整理することになります。

  • Javaとビルドツールのバージョン
  • ./mvnwまたは./gradlewによるビルド方法
  • アプリケーションの起動コマンド
  • 利用するポート
  • テスト用データの初期化方法
  • 必要なデータベースや依存サービス
  • ブラウザーから最初に開くURL

モノレポのように複数のフロントエンドやバックエンドを含む場合は、.junie/vms/以下に複数のDocker環境を用意し、それぞれの用途を.junie/demo.mdに説明できます。デモ対象ごとに適切な環境と起動設定を選べるようにする設計です。

GitHub Actionsに組み込む

Junie /demoは、ローカルの確認だけでなく、GitHub Actionsから--demoオプションで実行できます。基本的な実行イメージは次のとおりです。

junie --auth="$JUNIE_API_KEY" \
  --demo -p . \
  --task "Open the app and demonstrate the bulk status update."

プルリクエスト向けのワークフローでは、次のような流れを構成できます。

  1. プルリクエストの変更内容を取得する
  2. UIで確認可能な変更かどうかを判定する
  3. 対象となる場合にJunie /demoを起動する
  4. 動画やHTMLレポートをGitHub ActionsのArtifactsへ保存する
  5. プルリクエストへ成果物へのリンクをコメントする

変更内容に応じてデモを実行するか判断できるため、すべてのバックエンド変更に無条件でUIデモを実行する必要はありません。画面操作が可能な機能に絞ることで、CI時間とAI利用コストを抑えられます。

リリースブランチでは、複数のスモークテストをプッシュや手動実行に連動させる構成が考えられます。たとえば、ログイン、主要画面の表示、代表的な更新操作、再読み込み後の状態維持といった独立したシナリオを用意します。

CIに導入する際は、次の点を押さえる必要があります。

  • リポジトリのSecretsにJUNIE_API_KEYを登録する
  • .junie以下の設定をリポジトリにコミットする
  • Docker上で再現できるビルド・起動手順を整備する
  • 動画やレポートをGitHub Artifactsに保存する
  • AIの判定結果とは別に、CI上の合否条件を明示する

特に重要なのが最後の点です。**Junieのプロセスが正常終了したことは、シナリオが成功したことを意味しません。**CIで合否を扱う場合は、プロンプト内で明示的な判定結果を書かせ、PASSだけを成功として扱う構成が紹介されています。FAIL、PARTIAL、結果がない場合や形式が不正な場合は失敗とし、実行証跡自体はArtifactsに残す、という分離が有効です。

AIによるUI検証で注意すべき点

自然言語で操作を指定できる反面、従来のテストコードと同じレベルの決定性を期待すると運用上の問題になります。導入時は次のリスクを把握しておくべきです。

期待結果を具体的に書く

「機能を確認する」とだけ書くと、どの操作を行い、何を成功とするかが曖昧になります。対象データ、操作、画面上の変化、再読み込み後の状態などを分けて記述すると、検証の目的が明確になります。

テストデータを初期化する

前回の実行結果が残っていると、AIの操作以前に期待値が崩れます。サンプルデータをリセットする手順や、実行ごとに独立したデータを用意する仕組みが必要です。

失敗を人間がレビューする

画面レイアウトの変更、ローディング時間、ポップアップ、認証状態などによって、操作が失敗したり、意図しない画面を確認したりする可能性があります。生成された動画とスクリーンショットを見て、仕様上の失敗なのか、環境や操作上の失敗なのかを切り分けます。

コストと実行時間を管理する

AIモデルの推論に加えて、ビルド、アプリ起動、ブラウザー操作、動画処理が必要になるため、通常のユニットテストより時間がかかります。ニュースで示された内部の22シナリオ比較では、GPT-5.6 SOLが測定対象の中で平均時間とコストが低く、全体で19.94ドルだったとされています。ただし、これは特定の社内シナリオでの結果であり、アプリケーションやプロンプト、ビルド手順によって変わります。

Junie /demoでは、Computer Useに対応し利用可能なモデルが必要です。利用中のモデルが対応していない場合は、利用可能なモデルから選択されます。したがって、CIの実行条件やモデルの利用可能性も、運用設計の一部として扱う必要があります。

どのようなチームに向いているか

Junie /demoの効果が出やすいのは、次のようなチームです。

  • プルリクエストごとにUI変更の動作をレビューしたい
  • QA担当者へ再現可能な動画を共有したい
  • リリース前の代表的な画面フローを定期的に確認したい
  • E2Eテストを書く前段階で、機能の操作フローを検証したい
  • Swagger UIなど、既存の画面を使ってバックエンド変更を確認したい

反対に、画面を持たない単純なライブラリや、厳密な境界値検証だけを目的とする処理では、従来のユニットテストやAPIテストの方が効率的です。観測できるUIや画面フローがあることが、この仕組みの前提になります。

導入時の現実的な進め方

いきなりリリース全体をAIベースのUI検証へ移行するのではなく、まずは人が普段クリックしている小さな確認から始めるのが適切です。

  1. Docker上でアプリをビルド・起動できるようにする
  2. Junieに/demoのセットアップを依頼する
  3. 生成されたDockerfileや.junie/demo.mdをレビューする
  4. 1つの機能について、操作と期待結果を具体的に記述する
  5. 動画、スクリーンショット、HTMLレポートを確認する
  6. 安定したシナリオだけをGitHub Actionsへ移す
  7. CIではPASSなどの明示的な判定を合否条件にする

この段階的な導入なら、AIの操作能力を評価しながら、既存の自動テストとの役割分担も決められます。

まとめ：AIは「動作確認の証拠作り」を自動化する

Junie /demoの本質は、AIがコードを書くだけでなく、アプリケーションを実際に操作し、その挙動を他の人が確認できる形で残すことにあります。差分だけでは伝わりにくい画面遷移や状態変化を、動画とレポートによって共有できます。

ただし、AIによるデモ実行を成功判定の唯一の根拠にするのは適切ではありません。厳密な回帰検証は従来のテストに任せ、Junie /demoは次の用途で活用するのが実務的です。

  • プルリクエストのUI変更を見える化する
  • 定型的な画面確認を自動化する
  • QAやレビュアーに操作結果を共有する
  • リリース時のスモークテストと証跡作成を効率化する

まずは、次の変更で自分が手作業で確認する予定だったフローを1つ選び、自然言語で操作と期待結果を記述してみる。その結果を人間がレビューし、価値のあるシナリオだけをCIへ組み込む。この進め方が、AIエージェントによるUI検証を開発プロセスへ無理なく取り入れる現実的な第一歩になります。

出典： JetBrains Blog

タイトルとURLをコピーしました